**** BEGIN LOGGING AT Wed Oct 19 02:59:58 2016 Oct 19 03:01:54 IT BUILT (bitbake -c compile pluginlib) !!!! Oct 19 03:02:28 bluelightning: Thanks a lot dude! Now to try the whole image.,, Oct 19 03:29:22 Still debugging why usb is not working on my Zedboard & wondering if it is because of the following changes from a few months ago -> https://github.com/Xilinx/meta-xilinx/commit/d82cef3dca9749f385a16f506ca285f963584e3c#diff-92b3235b5be6244e66bc78d1cb05afde Oct 19 03:30:01 In that commit the dts & dtsi header files got removed - those files contained some usb config. Oct 19 03:31:06 Looks like they're now using a kernel device tree instead of dts & dtsi. Oct 19 03:31:37 Anyone any idea which file I should look at to find the same configuration in the kernel device tree / how to debug this further? Oct 19 04:29:15 Found the dts file in the kernel source -> bitbake-glibc/work-shared/zedboard-zynq7/kernel-source/arch/arm/boot/dts/zynq-zed.dts - looks like the usb section is different from what was removed in https://github.com/Xilinx/meta-xilinx/commit/d82cef3dca9749f385a16f506ca285f963584e3c#diff-92b3235b5be6244e66bc78d1cb05afde Oct 19 04:33:41 Looks like the one in the kernel tree is wrong - will try patching... Oct 19 09:05:14 ndec: oe meeting? Oct 19 10:49:16 This is ldd output on the qmake from my sdk. Can someone tell me what is not right? http://pastebin.com/x31xAAj7 Oct 19 10:58:02 Managed to rebuild my 1.4 SDK on 16.04, but the problem with qmake was apparently something else. A bad match between the libc in 16.04 and libm in the sdk. Oct 19 10:58:17 But I'm not sure how the ldd output should look :) Oct 19 11:57:16 hi, I'm trying to debug an error in a bb file where this is done: SRC_URI[md5sum] = "${MD5SUM}", where MD5SUM is a string which is set earlier in the .bb file -- is this usage OK? Oct 19 11:57:43 I get a runtime error looking like this: "File: has md5 checksum 0c2cd954e4bacd79fadd45afc4acce4c when ${MD5SUM} was expected" Oct 19 11:58:02 which suggests to me that the string variable isn't evaluated at the point SCR_URI[md5sum] is set Oct 19 11:58:09 any tips/hints? Oct 19 12:05:12 koen: do you think it's possible to make 2.1 run on a Beagle C3 with systemd 204 and linux 2.6.39? I'm prepared to start crying when I work on it. Oct 19 12:11:28 tasslehoff: it should work, if it doesn't, try turning of thumb2 Oct 19 12:22:03 koen: thanks. Oct 19 12:28:33 hmmm fftw-dev is gone Oct 19 12:43:15 hmmm: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=fftw Oct 19 13:49:09 openjdk8-native has a funny thing in it's source where it's automake configuration is located in another subfolder ${S}/common/autoconf. How can I instruct inherit automake to go there instead? Oct 19 13:51:12 pompomJuice: AUTOTOOLS_SCRIPT_PATH = "${S}/common/autoconf/" Oct 19 13:51:18 thanks Oct 19 13:51:26 you do realise there's a openjdk-8-native recipe with that line in already right Oct 19 13:51:56 (http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/openjdk/openjdk-8-common.inc#n9) Oct 19 13:53:05 I am trying to build a java 1.7 compatible jre for my oe system. So far I am trying to use meta-java with PREFERRED_PROVIDER_virtual/javac-native = "openjdk-8-native" and DEPENDS="openjdk-8" and RDEPENDS="openjre-8" Oct 19 13:53:46 it is not going well Oct 19 13:54:49 I have no idea what I am doing and when I go read up on this stuff it's like they are trying very hard to make it impossible to understand what the hell is actually going on. I blame oracle Oct 19 13:55:08 blaming oracle sounds sensible Oct 19 13:55:20 paging maxin for meta-java assistance ^^^ Oct 19 13:55:21 It makes me feel better Oct 19 13:56:27 I could build OpenJDK-7 easy peasy as that is the default/stable config that meta-java provides. But alas, my code needs Java 1.7 not 1.6. Oct 19 13:57:22 pompomjuice: hi Oct 19 13:57:45 Hello. Oct 19 13:58:00 Sorry to bother, I have really tried to make this work. Oct 19 13:58:09 But this java stuff is a bit complicated Oct 19 13:58:48 Basically, I have some 3rd party software that wants to compile but it complains that the classes need (51) instead of (50) Oct 19 13:59:17 It works with Java 1.6, but with warning saying I should be upgrading to 1.7. Oct 19 13:59:18 pompomJuice: going through it.. Just curious about your configuration - like MACHINE Oct 19 13:59:44 My machine is home baked, based on a freescale wandboard bsp Oct 19 13:59:57 My distro is angstrom Oct 19 14:00:15 I removed the angstrom pre baked java settings in that meta Oct 19 14:00:44 They work fine for a standard java setup, I am trying to see if I can get a compiler that is 1.7 compatible. Oct 19 14:01:20 Using yocto1.7 branches Oct 19 14:01:38 pompomJuice: qemuarm for openjdk-8 build should work (tested this week) Oct 19 14:03:36 The recipes don't seem to be geared for my bitbake?, for example the openjdk-8-native checkout contains a script file "configuration" that is not executable that redirects to execute a bash ${S}/common/autoconf/configuration... which is not there since autotools did not run there. Oct 19 14:04:23 this is now openjdk-8-native 102b14-r0 Oct 19 14:06:32 like rburton said: There is a AUTOTOOLS_SCRIPT_PATH but my bitbake seems to ignore it. Oct 19 14:07:12 pompomJuice: ok, could you please share the error logs ? Oct 19 14:07:14 I mean, my openembedded-core does not understand that Oct 19 14:07:17 sure Oct 19 14:08:30 ERROR: no configure script found at /home/griftw/w/mongoose/setup-scripts/build/tmp-ctlab-glibc/work/x86_64-linux/openjdk-8-native/102b14-r0/jdk8u-bf0932d3e0f8/configure Oct 19 14:09:40 pompomJuice: just to be sure about your bitbake version .. can you share that ? Oct 19 14:09:55 then if I chmod +x configure it then errors out with: Could not find configure inside common/autoconf because obviously automake was not run there because my oe-core does not understand chaning automake config dir Oct 19 14:10:40 (bitbake 1.24), (oe-core dizzy) Oct 19 14:11:01 Those are not exactly new Oct 19 14:11:31 they are yocto 1.7 generation stuff started 2 years ago Oct 19 14:13:19 if I grep "AUTOTOOLS_SCRIPT_PATH" in my meta sources it only shows up in openjdk-8-common.inc Oct 19 14:13:29 so I guess I will have to manually get that part to work Oct 19 14:16:21 I need this: https://github.com/openembedded/openembedded-core/commit/fe506eddb0790e37ac1e50f37fa2e32ad81d5493 Oct 19 14:16:36 I am going to patch that in and see what happens Oct 19 14:17:34 pompomjuice: yes, we export that to AUTOCONF_DIR in that .inc file.. Oct 19 14:17:48 ok cool, let me see if I can get that stuff into my oe-core Oct 19 14:18:52 uugh patch does not apply.... oh the joy Oct 19 14:20:25 pompomjuice: it will be a lot easier if you are in relatively new branches (like krogoth) Oct 19 14:20:46 They guy that pays me the big bucks does not understand that Oct 19 14:21:27 I argue that if he claims going forwards in version is a bad idea, then why dont we just go backwards in version right? Oct 19 14:21:36 hehe Oct 19 14:22:24 This open source stuff really clashes with the way business thinks progress should be made Oct 19 14:22:31 They just dont get it Oct 19 14:24:53 pompomjuice: true.. Oct 19 14:28:23 time to work some git magix Oct 19 16:44:03 Configuring packagegroup-core-tools-debug-dCollected errors: Oct 19 16:44:04 * calculate_dependencies_for: Cannot satisfy the following dependencies for fft Oct 19 16:44:04 w-dev: Oct 19 16:44:04 * fftw (= 3.3.4-r0) * Oct 19 16:44:04 * opkg_solver_install: Cannot install package fftw-dev. Oct 19 16:44:04 bg. Oct 19 16:48:38 seems like fftw is an empty package and not created? **** ENDING LOGGING AT Thu Oct 20 02:59:59 2016