**** BEGIN LOGGING AT Mon Dec 16 03:00:01 2013 Dec 16 06:44:04 \o everyone Dec 16 06:44:16 I have been in here complaining about core-image-minimal failing on thursday Dec 16 06:44:43 I have been able to track it down a bit. Standard oe-core build works. But if I add DISTRO_FEATURES += "opengl" to local.conf, eglibc fails to build Dec 16 06:44:48 I have no clue why Dec 16 06:45:01 once I rmeove it, eglibc builds again Dec 16 09:06:00 good morning Dec 16 10:20:18 I have pasted the error messages I get here: http://jm0.eu/oecore-opengl-build.log Dec 16 10:41:03 koen: just curious... why should R* variables go after do_install? Dec 16 10:43:00 ndec: variable are grouped by the task they belong to Dec 16 10:43:14 ndec: and tasks are ordered in execution order where possible Dec 16 10:43:33 ndec: it just helps readability Dec 16 10:43:35 ok. that makes sense. it's something i never realized... Dec 16 10:43:45 so output package things like FILES, RDEPENS and friends go next to do_package Dec 16 10:44:06 but since do_package is nearly always 'missing' from a recipe -> below do_install Dec 16 10:44:16 is that mentioned in any doc? Dec 16 10:44:31 it used to be in the oe style guide Dec 16 10:44:44 i don't remember seeing it, and i think it should be. quite useful for whoever writes a recipe Dec 16 10:45:06 there's contrib/oe-stylize.py in meta-oe that gets things mostly right Dec 16 10:45:21 * koen doesn't have time to improve oe-stylize.py Dec 16 10:46:43 and in the bash-completion discussion, I don't get why a PE is needed Dec 16 10:47:18 PE have been removed from nearly all recipes when moving them over, so I don't see why bash-completion should be different Dec 16 10:47:49 koen: he's already removed it in v3 Dec 16 10:47:52 since core packages have different names (dbus for example) you can't update from classic to oe-core anyway Dec 16 10:48:07 it helps to keep in mind that new contributors don't necessarily know all the details ;) Dec 16 10:48:46 well Dec 16 10:48:52 sgw_ said a PE was needed Dec 16 10:49:07 i'm not convinced it's needed when moving from classic either Dec 16 10:50:14 koen: hmm, not sure why he would say that Dec 16 10:50:23 it definitely isn't Dec 16 10:50:58 * koen notices the test script ran on the production server and heads down for more coffee before more accidents happen Dec 16 12:52:47 Hello everybody. I generated an image for my Raspberry-PI using the OpenEmbedded framework. However, all .debug binaries don't work and I have this message when I try to run them I have this => /usr/bin/.debug/iconv: line 1: syntax error: unexpected "&" (expecting ")")... Any idea? Dec 16 13:28:41 Hello everybody. I generated an image for my Raspberry-PI using the OpenEmbedded framework. However, all .debug binaries don't work and I have this message when I try to run them I have this => /usr/bin/.debug/iconv: line 1: syntax error: unexpected "&" (expecting ")")... Any idea? Dec 16 13:28:47 I am not sure those really are bianries Dec 16 13:29:20 they are binaries, but not executables Dec 16 13:29:31 they contain the debug symbols Dec 16 13:29:40 I guess gdb knows to load them Dec 16 13:29:40 you run the regular ones in /bin Dec 16 13:29:50 yes, gdb knows how to load them Dec 16 13:32:41 Artox, gdb maginally knows about them Dec 16 13:32:54 it always does when I isntall teh debuginfo packages on opensuse Dec 16 13:33:25 I dont suppose tehres anybody around whod like to debug why oe-core fails on core-image-minimal when confronted with distro_feature opengl? Dec 16 13:42:01 Artox: pastebin an error and it might be obvious Dec 16 13:42:16 I dont htink it is Dec 16 13:42:17 but Dec 16 13:42:25 http://jm0.eu/oecore-opengl-build.log Dec 16 13:42:26 there Dec 16 13:42:38 magically, when I remove opengl as distrofeature again, it builds fine Dec 16 13:42:45 and it rebuilds as I add opengl again Dec 16 13:42:48 and fails Dec 16 13:43:21 how are you adding the opengl feature? Dec 16 13:43:31 i guess +=? Dec 16 13:45:25 Artox: the correct line you're looking for is DISTRO_FEATURES_append = " opengl". using += breaks the expansions, so you get eglibc failures. Dec 16 13:45:40 oh Dec 16 13:45:46 the space before opengl intentional and required. if that's not the problem then it will have to wait until after my lunch. Dec 16 13:45:59 it sounds very possible Dec 16 13:46:04 check in progress Dec 16 13:48:08 if a package start s installing binaries and tests in /usr/lib/uhd, should I compalin to upstream? Dec 16 13:48:16 used to be in /usr/share Dec 16 13:49:15 hmm Dec 16 13:49:29 non arch independent though Dec 16 13:50:43 Crofton|work: that's reasonable for non-user-executable binaries and stuff Dec 16 13:50:49 yeah Dec 16 13:50:53 (all the ptest tests go into there too) Dec 16 13:50:55 these are user executbale Dec 16 13:51:03 but not every day :) Dec 16 13:51:18 i'm fine with /usr/lib/[subdir] for that Dec 16 13:51:20 we used to keep them in /usr/share Dec 16 13:51:28 it works! Thanks rburton Dec 16 13:51:38 so obvious now Dec 16 13:51:49 Artox: said it would be simple. += vs _append isn't obvious at all. Dec 16 13:52:11 well I had no space Dec 16 13:52:13 and no _append Dec 16 13:52:22 rburton: heh, that's a pitfall indeed Dec 16 13:52:42 now to see if I get mesa to build Dec 16 14:33:47 Hi all, I am trying to compile netsniff-ng package, I am getting: mac80211.c:21:38: fatal error: libnl3/netlink/genl/genl.h: No such file or directory Dec 16 14:39:37 drasko: you need libnl-dev Dec 16 14:44:28 not libnl-dev, just libnl in DEPENDS Dec 16 14:44:33 drasko: ^ Dec 16 14:47:23 (and send a patch if that fixes it) Dec 16 14:52:08 bluelightning: that header file is in libnl? Dec 16 14:53:12 wmat: on the build system side, there is no such thing as -dev Dec 16 14:53:22 ah Dec 16 14:53:33 in terms of build-time dependencies Dec 16 14:53:46 bluelightning, I have libnl in DEPENDS Dec 16 14:53:55 must be some path to set Dec 16 14:54:01 but I do not know which... Dec 16 14:54:16 let me paste mt recipe Dec 16 14:55:09 http://pastebin.com/2znBqLCY Dec 16 14:59:05 drasko: oh great, a makefile-only piece of software Dec 16 14:59:28 drasko: you're going to need to specify a bit more than what you are specifying e.g. in EXTRA_OEMAKE Dec 16 15:03:44 bluelightning, what should be added to EXTRA_OEMAKE? Dec 16 15:03:55 I thought that configure-make is enough... Dec 16 15:04:18 drasko: as far as I can tell this piece of software has no configure script Dec 16 15:04:26 it's just a bare makefile Dec 16 15:05:19 bluelightning, it seem to have Dec 16 15:06:24 oh, sorry... there it is Dec 16 15:06:44 drasko: right now you're not actually running it though Dec 16 15:06:57 drasko: well, not properly anyway Dec 16 15:07:18 drasko: your recipe inherits autotools, it should not - this is not an autotools-based piece of software as clearly stated in the configure script Dec 16 15:07:25 how to force configure? I thought that actuall inherit autotools is enough... Dec 16 15:08:08 OK, so what should I add then? I guess that explicit commands to do_configure are not needed? Dec 16 15:08:52 you need to define your own do_configure Dec 16 15:08:59 and you need to work out what options to send it Dec 16 15:09:16 I'll note that this configure script seems to have no way of specifying any kind of sysroot Dec 16 15:09:49 maybe you could inject it by way of setting CC in do_configure (which you may need to do anyway) Dec 16 15:11:14 later you'll also need to define do_install Dec 16 15:21:52 bluelightning, why do_configure() is not automatically called? Dec 16 15:22:38 Actually I did not define do_configure(), but I do not understand when is it called automatically and when we have to call it explicitly Dec 16 15:23:42 On the other hand, when I put inherit autotools Dec 16 15:23:52 then do_configure() is called automatically... Dec 16 15:34:42 drasko: do_configure is automatically called; configure isn't though because for something that's not autotools we have no idea what arguments to supply to it or if there is even a configure script at all Dec 16 16:23:56 bluelightning, after changes I have made to recipe, I still have compilation error. Compiler looks for genl.h in the tmp/sysroots/socfpga_cyclone5/usr/include/libnl3 and it is in /home/drasko/yocto/build/tmp/sysroots/socfpga_cyclone5/usr/include/libnl3/netlink/genl/genl.h Dec 16 16:24:45 How should I instruct compiler for this include path? Dec 16 16:24:51 drasko: right, presumably you need to ensure the appropriate -I option is passed to the compiler (perhaps via CFLAGS?) Dec 16 16:26:16 you'll probably need to specify -L so that linking happens properly as well Dec 16 16:26:19 bluelightning, can it be done via EXTRA_OEMAKE ? Dec 16 16:26:43 drasko: you can pass in values of variables into make that way, yes - see the make documentation Dec 16 16:27:18 thanks Dec 16 22:21:09 hi, when using SSTATE_MIRROR, when/where is bitbake trying to see if the sstate file exists on the mirror? when the file exist on my mirror, i can see bitbake runs setscene tasks, but when it doesn't exist, it directly builds without setscene. so it must be making the decision to run setscene 'somewhere'. Dec 16 22:22:47 it's done up front, while bitbake is constructing its task runqueue. it has to, otherwise it'd end up scheduling execution fo tasks that shouldn't be run Dec 16 22:30:36 kergoth: hmm. is it using the sstate.bbclass to do that? Dec 16 22:32:56 yes, it defines vars/flags to tell bitbake which of its def'd python functions to run to check and see if the sstate archives exist, and try to fetch if not Dec 16 22:34:15 kergoth: ok. thanks. what is PREMIRROR is set too? does it come into play for SSTATE_MIRROR? Dec 16 22:35:46 PREMIRRORS/MIRRORS should be irrelevent, those are used to fetch sources for do_fetch. just read sstate.bbclass, you can see where it pulls SSTATE_MIRRORS and wipes mirrors/premirrors Dec 16 22:36:24 pstaging_fetch, called around line 226,defined around line 493 Dec 16 22:51:08 kergoth: many thanks. that helps a lot... **** ENDING LOGGING AT Tue Dec 17 02:59:59 2013