**** BEGIN LOGGING AT Wed Aug 21 02:59:59 2013 Aug 21 04:18:19 Hm, I'm having problems building the db package. :/ Aug 21 04:18:35 Getting a bunch of operation not permitted because it's trying to chown to root Aug 21 07:12:56 mewyn: bitbake runs under pseudo (like fakeroot), activating it for certain tasks (do_install, do_package, do_package_ipk, etc) Aug 21 07:13:11 mewyn: assuming oe-core/poky rather than oe-classic, anyway Aug 21 08:38:20 morning Aug 21 08:39:06 hi pb_ Aug 21 08:55:05 morning all Aug 21 08:56:04 hi eren Aug 21 13:30:16 hi. can i use COMPATIBLE_MACHINE in a .bbappend file? i have a .bbappend in one of our BSP layer who parsing should be skipped for all other BSP. Aug 21 13:40:36 you can use it, but it doesn't sound as though it will do quite what you want. Aug 21 13:41:13 .bbappend files are processed just as if they were textually appended to the .bb file that they're modifying, and there's no special handling for COMPATIBLE_MACHINE. Aug 21 13:41:51 so, if you define COMPATIBLE_MACHINE in a .bbappend, it will apply to the entire recipe. there isn't any mechanism to say "only apply this .bbappend for these machines, otherwise leave the recipe alone". Aug 21 13:42:46 pb_: hi there. Wrt klibc as you suspected the recreated symlinks in machine sysroot are broken... Aug 21 13:42:59 ant_work: ah, right. Aug 21 13:43:08 maybe you could just have klibc copy the files rather than linking them. Aug 21 13:43:47 a substitution happen so there is an initial ../../../ too much (or like that) Aug 21 13:44:57 that's probably due to make_relative_symlink() in sstate.bbclass, if you wanted to try to fix it. Aug 21 13:45:13 pb_: I'm still not yet exactly convinced about the install locations of klibc. I just kept it Aug 21 13:48:30 pb_: so, is there a solution to have .bbappend for some machine only? Aug 21 13:50:57 ndec: you can use COMPATIBLE_MACHINE_ = "^$" in .bbappend Aug 21 13:51:47 JaMa: sorry, i don't understand. Aug 21 13:52:11 ndec: and apply all changes to "base" recipe with _MACHINE overrides, this way your .bbappend won't influence other MACHINEs Aug 21 13:52:22 ndec: of course it means that recipe should be MACHINE_ARCH Aug 21 13:52:38 ndec: you know what override is? Aug 21 13:52:51 no , but i can certainly read about it ;-) Aug 21 13:53:02 also, the problem is with qt5, dylan branch. Aug 21 13:53:14 we have qt5 on several BSP, each in its own layer. Aug 21 13:53:24 and each BSP has a .bbappend which is BSP specific. Aug 21 13:53:55 ndec: you can imagine _ override as: if MACHINE == than... Aug 21 13:54:29 is there any example of that i can look into/ Aug 21 13:54:37 but it's more generic, you can use many things after '_' as overrides, see OVERRIDES variable in bitbake.conf Aug 21 13:54:42 ndec: i use it a lot :-) Aug 21 13:54:57 ah. good. ;-) Aug 21 13:55:13 so, i should look at your bsp layer... Aug 21 13:55:25 or any BSP layer in meta-smartphone repo Aug 21 13:55:36 ndev: no, there's no mechanism for machine-specific bbappends. Obviously you can make all the content in the .bbappend be machine-specific though. Aug 21 13:55:59 ndec: ^ Aug 21 13:56:09 thx Aug 21 13:57:14 JaMa: the old qt4 metadata, openembedded-core/meta/recipes-qt, contains a qt-apps directory which demonstrates how to build qt applications against OE's qt4 Aug 21 13:57:23 are there any such examples for the meta-qt5 layer? Aug 21 13:58:19 JaMa: i can build and run qt4 applications just fine, i can build qt5 apps, but i can't seem to get them to run Aug 21 14:00:08 JaMa: pb_: what i am trying to do is to have all BSP layers configured simulatenously (in bblayers.conf). that's just simpler in terms of CI/build server. do you think it's wrong, and that we should parse only 1 BSP layer at a time? to avoid mixing MACHINES, and .bbappend? or should we be able to split out things nicely? Aug 21 14:00:38 pb_: yes, should happen in def make_relative_symlink(). I'll have a look Aug 21 14:01:25 tlwoerner: no there isn't example as such, unless you consider other qt modules as examples Aug 21 14:02:36 ndec: you'll be interested in openembedded-core/scripts/sstate-diff-machines.sh script Aug 21 14:03:05 ndec: having all BSP layers in the same bblayers.conf is correct goal, meta-smartphone BSPs work this way Aug 21 14:03:34 JaMa: thanks. will have a look. Aug 21 14:15:42 JaMa: okay, thanks Aug 21 14:16:24 JaMa: is that the layer you mentioned: http://gitorious.org/shr/meta-smartphone? Aug 21 14:16:34 any reason it's not in the layer index? Aug 21 14:27:28 ndec: meta-smartphone itself is a repository containing layers, but is not a layer itself Aug 21 14:27:45 ah... Aug 21 14:28:42 I think one or two of the recently added sub-layers might not be in the layer index yet - tsk tsk JaMa Aug 21 14:28:51 most of them are in there though Aug 21 14:37:26 bluelightning: true I've splited DISTRO config and SHR apps into 2 layers and haven't added it to layer index yet Aug 21 14:37:51 JaMa: I can do it now if you like, or you can do it if you prefer Aug 21 14:40:16 I'm doing it already Aug 21 14:42:53 done Aug 21 14:44:36 ok what about meta-asus and meta-acer? Aug 21 14:45:41 ok will add them too (I thought they are already there) Aug 21 14:46:44 I have got an item on my todo to scan and warn about any new layers added to a repository, haven't implemented anything along those lines yet though Aug 21 15:29:56 bluelightning: may I send the patch to put ipaq stuff in /obsolete ? Aug 21 15:37:43 ant_work: I'd rather just delete it if it genuinely is obsolete Aug 21 15:38:19 but someone has to sit down and test building mainline (or linux-yocto) for these devices Aug 21 15:38:21 would really need buildtime and runtime testings Aug 21 15:38:24 right Aug 21 15:38:43 I'm sorry I have adopted enough orphans ;) Aug 21 15:38:46 I did kind of get back into things over the weekend, found a bunch of bitrot in opie which I've mostly fixed (but not committed) Aug 21 15:39:05 sure, I wouldn't expect you to take care of any of this, your plate is very full already :) Aug 21 15:39:32 maybe we can just test some on qemu... Aug 21 17:00:41 Is there a simple way to get the kernel installed in the rootfs ? Aug 21 17:02:20 kergoth: There's a chmod root:root in the recipe. I wonder if there's something in my layer config that's causing the fake stuff to not work. (I'm using the oe-core) Aug 21 17:14:36 mewyn: as long as its doing it in do_install, shoudl be fine Aug 21 17:29:50 kergoth: I forget (I'm picking up some old stuff from 6+ months back) is there a guide to setting up new layers? Aug 21 17:31:46 Wait-- I think I found the bug causing my COREBASE being changed with my layer. Aug 21 17:40:27 mewyn: all you need to have to be a layer is a layer.conf, really :) beyond that, its largely a free-for-all, though distro and bsp layers do have guidelines they should follow (namely, most changes should be opt-in, and distro or machine changes hsould use the distro or machine override, so including the layer doens't break other distros/machines) Aug 21 17:50:27 kergoth: I don't think I've been in here in a while. I've moved on from VMware. Aug 21 18:13:15 is there a task that cleans only the files in the "deploy" directory for a given recipe? (as in we don't want to do a clean or cleanall, just get rid of the produced images/hdinstalls/etc) Aug 21 18:13:45 I was going to do it by hand, but there's an ominous file telling me not to manually mess with anything in that directory :) Aug 21 18:19:18 mbroadst: go ahead, live dangerously, delete them by hand! Aug 21 18:19:26 heh, that's there to make it clear that the files won't automatically come back unless you re-run the deploy tasks Aug 21 18:19:34 there's no clean-deploy task, sorry Aug 21 18:20:27 hah okay, just checking.. not like I haven't been bit by not following the rules with this system before Aug 21 18:21:33 :) Aug 21 19:21:17 tab to indent shell? Aug 21 19:22:14 yep Aug 21 19:39:16 how do I figure out if a function is in my path and executbale in a doo_bar(0 functino Aug 21 19:39:33 Crofton|work: a function ? Aug 21 19:39:42 sorry command Aug 21 19:39:46 bootgen :) Aug 21 19:42:55 using which to find the binary blows up if it is not in the path Aug 21 19:43:47 Crofton|work: http://stackoverflow.com/questions/592620/check-if-a-program-exists-from-a-bash-script Aug 21 19:44:05 yeah which isn't particularly helpful Aug 21 19:45:46 command -v looks promising Aug 21 19:45:46 Crofton|work: or "type" Aug 21 19:45:56 is type bash only? Aug 21 19:46:08 not sure Aug 21 19:46:20 the link bluelightning agve suggests it is Aug 21 19:47:53 Oh, I see. Looks like "command" is the portable way Aug 21 20:08:21 urg Aug 21 20:08:34 function fials if commands exit status is bad Aug 21 20:13:56 Crofton|work: http://pubs.opengroup.org/onlinepubs/009695399/utilities/type.html Aug 21 20:14:18 Crofton|work: note that its output syntax is unspecified, but you could probably check the exit code Aug 21 20:14:30 i recommend bookmarking http://pubs.opengroup.org/onlinepubs/009695399/ Aug 21 20:15:02 not sure if thats the latest version of the standard, but its what i end up checking when i'm concerned about shell script portability Aug 21 20:15:43 but it seems like if the command isn't founc command returns something other than 0 and bitbake dies Aug 21 20:16:02 that's not correct, at least not in all contexts. Aug 21 20:16:14 do_bootbin() { Aug 21 20:16:14 BOOTGEN=`command -v bootgen` Aug 21 20:16:14 if [ ${BOOTGEN} != "" ] ; then Aug 21 20:16:15 if foo; then; fi; won't exit the shell if foo returns nonzero Aug 21 20:16:23 barfs if there is no bootgen in the path Aug 21 20:16:37 if type bootgen >/dev/null 2>&1; then echo problem solved; fi Aug 21 20:16:41 i expect would do the job Aug 21 20:16:44 yeah Aug 21 20:16:50 that was my next thought Aug 21 20:17:05 if you need the full path, i usually use which, but i don't think thats required by posix/sus Aug 21 20:17:14 its usually available anywhere we care about, though Aug 21 20:18:00 my shell has atropied :( Aug 21 20:20:58 isn't the common idiom something like 'if [ x${BOOTGEN} != x ]; then ...' ? Aug 21 20:21:12 for env avrs Aug 21 20:21:26 yeah I should have done that Aug 21 20:21:35 the 'x' thing is really only used by autoconf folks, who can't rely on having an sus/posix compliant shell, afaik Aug 21 20:22:03 if you'er going to check for a non-empty var, best to use [ -n "${foo}" ] Aug 21 20:22:49 or '[ -z "${foo}" ]' or is that a bashism? Aug 21 20:23:05 -n is not empty, -z is empty Aug 21 20:23:08 neither are bashisms Aug 21 20:23:27 thx Aug 21 20:23:47 http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html Aug 21 20:34:15 stupid question Aug 21 20:34:28 is this "true" only if both commands succeed? Aug 21 20:34:29 if `command -v bootgen` ; [ -e ${ZYNQ_FSBL} ; then Aug 21 20:34:52 that's broken in a number of ways Aug 21 20:35:06 first, if accepts a command to run, not a string Aug 21 20:35:11 so drop the `'s Aug 21 20:35:23 second, you can chain commands in a shell with the and and or operators Aug 21 20:35:28 if this && that; then :; fi Aug 21 20:35:33 gah Aug 21 20:35:34 :) Aug 21 20:35:58 if command -v bootgen && [ -e ${ZYNQ_FSBL} ] ; then Aug 21 20:36:08 so above, m skillz are ancient Aug 21 20:36:17 assuming command returns 0/1 based on its existence, sure Aug 21 20:36:22 but -v is rather pointless if you arent using its output Aug 21 20:45:49 ericben: ping Aug 21 21:01:58 JaMa, this is after core-image-base http://paste.debian.net/28181/ Aug 21 21:08:15 JaMa, same after building kexec-tools-klibc Aug 21 21:12:52 ant_home: that script would find files staged in sysroot without sstate code knowing about it, if it's caused by symlinks pointing to nowhere then sstate-sysroot-cruft won't help Aug 21 21:58:38 JaMa, I don't know now if it is broken... Aug 21 21:59:36 failing to build can IMHO be considered broken :) Aug 21 21:59:47 in sstate package of klibc the symlinks (linux-libc-headrrs) are the same as in eglibc-initial Aug 21 22:00:40 i.e. asm -> ../../../..//sysroots/qemuarm/usr/include/asm Aug 21 22:00:47 JaMa: You sent a patch in past to user proper gperf for systemd Aug 21 22:00:50 remember ? Aug 21 22:01:37 the patch is now upstream in systemd however we still hard code the exporting of GPERF Aug 21 22:01:58 which defeats the purpose of using AC_CHECK_TOOL at first place Aug 21 22:02:26 since variable GPERF is already defined configure wont touch it Aug 21 22:02:42 so I am punting this export from systemd recipe Aug 21 22:02:48 with upgrade to 206 Aug 21 22:03:00 do you have a usecase where this hard export is needed ? Aug 21 22:15:00 khem: there is even contrib branch with it http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/gperf Aug 21 22:15:40 khem: IIRC I haven't finished something in it, but I don't remember what it was, I can try to find it on oe-core ML Aug 21 22:16:56 ah there is a link to ML in one of those patches, please check it Aug 21 22:32:10 JaMa, so, maybe this: the symlink in the sstate is the same but in case of klibc it lacks one ../ Aug 21 22:32:34 in the ipk tmpdir is hardcoded, fwiw Aug 22 01:09:41 hi. i am seeing a libjpeg-turbo error: ERROR: Function failed: libjpeg-turbo: LIC_FILES_CHKSUM points to an invalid file: xxx/tmp/work/armv7ahf-vfp-neon-rdk-linux-gnueabi/libjpeg-turbo/8d+1.2.1-r2/trunk/cdjpeg.h Aug 22 01:10:07 it seems that a 'fresh' svn copy of the repo now creates trunk/trunk, hence it doesn't find the file. Aug 22 01:10:24 apparently, i am not alone ;-) https://groups.google.com/forum/#!msg/beagleboard/kTXnTZMFPLE/JTWs6696D8sJ, from 4 hours ago. Aug 22 01:10:39 chaning S to trunk/trunk in the .bb fixes the problem. **** ENDING LOGGING AT Thu Aug 22 02:59:58 2013