**** BEGIN LOGGING AT Thu Oct 03 02:59:58 2013 Oct 03 07:51:55 when I try to ssh into my unit running a fresh dylan-image I am prompted for a password. that is odd, since /etc/shadow shows that root has no password. Oct 03 08:36:14 I'm using OE to build an image for a Wanboard Solo, using the meta-fsl-arm-extra layer. Every git repo is using master branches. I'm getting build errors in eglibc, undefined references to __nss* and __nscd* functions. Anyone got an idea ? Oct 03 08:47:13 good morning Oct 03 08:50:18 jkroon_: AFAIK the suggeted repo is dora https://github.com/Freescale/fsl-community-bsp-platform Oct 03 08:50:32 s/suggeted/suggested Oct 03 08:51:57 mckoan, ah thanks.. will try that one instead Oct 03 08:52:25 jkroon_: you're welcome Oct 03 08:57:06 actually I think that will lead to the same bsp layers Oct 03 08:58:40 but it says I should use danny branches infact Oct 03 09:00:23 morning all Oct 03 09:08:36 hi silvio_l_, all Oct 03 09:09:28 jkroon_: README: Use 'dora' as adviced branch Oct 03 09:11:37 morning all Oct 03 09:12:56 mckoan, ok, but "dora" looks identical to "master" currently.. Oct 03 09:13:30 it is, but they will likely be diverging shortly Oct 03 09:57:57 hi mckoan, hi bluelightning Oct 03 10:29:19 is github out of service? Oct 03 10:29:54 https://status.github.com/ Oct 03 10:29:56 yes Oct 03 10:31:47 who would want to ddos github I wonder? Oct 03 10:32:14 me Oct 03 10:32:46 pb_: YOu will have a busy day I guess :) Oct 03 10:33:01 yeah, hitting that refresh button all the time is getting tiring Oct 03 10:33:25 haha Oct 03 10:33:29 bluelightning: the same people that DDoS raspberrypi constantly Oct 03 10:33:38 better get a GP appointment as well Oct 03 10:33:39 those poor guys at mythic beasts worked overtime on that Oct 03 10:35:10 how do we give a path to include dir in Bitbake recipe to point to another package headers? Oct 03 10:35:43 btw, is the OE GA set for the LinuxCon week? Oct 03 10:37:13 drasko: CFLAGS =+ "-I..." Oct 03 10:39:08 bluelightning, I have added CFLAGS += "-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__" Oct 03 10:39:24 and bitbake seems to be looking at my PCs /usr/xenomai/include Oct 03 10:39:35 not the one that is cross-compiled for the target Oct 03 10:39:53 drasko: yes, that will do that - gcc's -I takes a full path Oct 03 10:40:30 bluelightning, how to instruct it to look in cross-compiled package? Oct 03 10:40:37 This package lives in tmp/work/armv7ahf-vfp-neon-poky-linux-gnueabi/xenomai-head-r0/ Oct 03 10:41:24 And I gues that the same problem persist for LDFLAGS += "-L/usr/xenomai/lib -lxenomai -lpthread -lrt" Oct 03 10:41:27 it'll need to be staged, assuming it already is I'm guessing -I${STAGING_DIR_HOST}/usr/xenomai/include would be the correct thing to do Oct 03 10:42:11 bluelightning, what do you mean by staging? Included in image rootfs? Oct 03 10:42:44 drasko: no, staged into the sysroot Oct 03 10:43:02 drasko: normally this is automatic assuming your recipe installs the files within do_install Oct 03 10:43:18 hmmm... this is a new concept for me. I do not know how to do this... Oct 03 10:43:28 My Xenomai recipe installs files Oct 03 10:44:11 ok, so do bitbake -e | grep ^STAGING_DIR_HOST= Oct 03 10:44:34 and then look in usr/xenomai/ under that directory Oct 03 10:45:07 bluelightning, hmmm Oct 03 10:45:20 indeeed, /usr/xenomai does not exist Oct 03 10:45:31 only: bin include lib share src Oct 03 10:45:38 so, my xenomai recipe is wrong Oct 03 10:46:42 unfortunately this is because xenomai is installing stuff to /usr/xenomai... if it did what everything else does and put libraries in /usr/lib and headers in /usr/include it would all just work Oct 03 10:47:44 http://pastebin.com/KbT3L83D Oct 03 10:47:49 This is my Xenomai recipe Oct 03 10:49:35 so if you add this it should then stage the files: http://pastebin.com/6VMFqMx1 Oct 03 10:49:39 drasko: ^ Oct 03 10:50:14 (you may need to do bitbake -c cleansstate xenomai before building it again, since changing SYSROOT_PREPROCESS_FUNCS doesn't currently force a rebuild) Oct 03 10:50:46 FYI this is needed because when staging by default we only stage a small subset of installed files to the sysroot Oct 03 10:51:38 wow Oct 03 10:51:42 it worked Oct 03 10:51:54 did not even needed bitbake -c cleansstate xenomai Oct 03 10:52:01 ok, great :) Oct 03 10:52:39 what did we actually do here? We forced Bitbake to stage xenomai? Oct 03 10:58:25 bluelightning, when I have a line like this: LDFLAGS += "-L${STAGING_DIR_HOST}/usr/xenomai/lib -lxenomai -lpthread -lrt" Oct 03 10:58:56 will bitbake link to the -lpthread and -lrt from the PC Oct 03 10:59:16 or will it take one from the staging dir (i.e. for the target)? Oct 03 11:02:34 drasko: as long as there isn't a -L/usr/lib in the linker command line then it shouldn't take anything from the build host Oct 03 11:03:00 drasko: if it does link to host libraries you should get a warning at packaging time in any case Oct 03 11:03:12 OK, thanks Oct 03 11:19:50 pb_: http://www.itworld.com/cloud-computing/376551/where-world-are-github-users Oct 03 13:09:34 bluelightning, you said that only small subset is staged into sysroot Oct 03 13:09:44 drasko: by default yes Oct 03 13:10:07 how to know which files are in that category (default in sysroot) Oct 03 13:10:14 how is this decided? Oct 03 13:10:29 for example - for Xenomai it has to be explicit Oct 03 13:10:43 drasko: we have a set list... for details look at sysroot_stage_dirs() in meta/classes/staging.bbclass Oct 03 13:10:56 OK, thanks Oct 03 13:11:47 but it has nothing to with Xenomai's "strange" install destination? Oct 03 13:12:09 because in any case it would not be on the list, right? Oct 03 13:13:04 it does though Oct 03 13:13:31 as I said above if xenomai installed its libs/headers into the standard directories then they would be staged and picked up automatically Oct 03 13:16:21 In sysroot_stage_dirs() I can see: sysroot_stage_dir $from${includedir} $to${STAGING_INCDIR} Oct 03 13:17:03 yep Oct 03 13:17:10 ${includedir} defaults to /usr/include Oct 03 13:17:19 So if we add our /usr/xenomai/include/ to ${includedir} Oct 03 13:17:40 ${includedir} is a single path though Oct 03 13:17:46 ah... I see Oct 03 13:18:07 FYI you can see the defaults for vars like includedir in meta/conf/bitbake.conf Oct 03 13:18:41 Thanks a lot for these clarifications Oct 03 13:19:40 np Oct 03 14:03:04 bluelightning, thanks for taking care of FOSDEM stand Oct 03 14:03:21 I proposde a software radio devroom and it was accepted Oct 03 14:03:32 Crofton: np Oct 03 14:03:33 Crofton: nice Oct 03 14:03:49 we should probably try to have at least one OE-related talk submitted as well Oct 03 14:03:49 I'll be going crazy, but I have help Oct 03 14:03:52 yes Oct 03 14:54:24 Crofton: we need to add a note to the meta-zynq entry in the layer index as well Oct 03 17:03:08 wiki account requests has risen lately :) Oct 03 17:08:27 wmat: have any of these new accounts actually contributed anything? I haven't seen one yet that I can recall... Oct 03 17:59:13 I'm having some trouble with meta-java and building openjdk-7-jre -- getting QA issues for openjdk-7-vm-cacao contains bad RPATH under ubuntu 13.04, building for a freescale i.mx28 Oct 03 17:59:38 I've not found a fix, sorry if this is an amateur question Oct 03 18:07:07 blilly_ it works anyway Oct 03 18:07:28 I need to patch something in cacao to not use rpath at linking time Oct 03 18:07:31 it errors out though Oct 03 18:07:37 hm Oct 03 18:07:39 mom Oct 03 18:07:42 k Oct 03 18:07:46 you can workaround it Oct 03 18:08:10 will do so happily -- how? :) Oct 03 18:08:17 woglinde: IIRC I did a patch to fix this kind of issue in past for meta-java Oct 03 18:09:45 khem hm did I overwrite it when updating to openjdk 2.3 Oct 03 18:09:54 lets see the pull requests Oct 03 18:09:58 no idea didnt pay attention Oct 03 18:10:04 although my targets are building ok Oct 03 18:10:09 so I am relatively less worries Oct 03 18:11:46 hm ah maybe it is in 6 Oct 03 18:11:48 lets see Oct 03 18:13:24 khem can you search the patch? Oct 03 18:13:44 --with-libtool-sysroot seems not to work Oct 03 18:13:54 woglinde: I will try Oct 03 18:40:31 heh Oct 03 18:40:33 andrea@mizar /oe/oe-core/build $ emerge core-image-base Oct 03 18:40:33 emerge: superuser access is required Oct 03 18:41:07 don't do two similar things together in two screens... Oct 03 18:54:21 woglinde: You refer to khem's patch here: http://bit.ly/18TvQmO but unfortunately not specifically enough for me to track it down yet Oct 03 19:09:04 blilly_ no Oct 03 19:09:09 thats a diffrent problem Oct 03 19:09:17 naturally Oct 03 19:09:21 its inside cacao Oct 03 19:09:24 ok Oct 03 19:09:42 I am looking at it at the moment Oct 03 19:09:47 ok, thanks Oct 03 19:19:10 what do I need to add to local.conf to fix the opengl business? Oct 03 19:19:12 min set Oct 03 19:35:42 ka6sox: ping Oct 03 19:36:33 wmat: pong Oct 03 19:58:12 blilly_ found a solution now Oct 03 20:19:33 woglinde excellent. I'll pull it down and try it Oct 03 20:19:35 thanks! Oct 03 20:52:03 blilly_ does it work for you? Oct 03 21:08:09 i moved a project from a coworker's /home folder to my own. `make clean` is now giving me errors about TMPDIR being inconsistent, but I can't figure out where it is seeing the old reference Oct 03 21:10:44 tworkin: you can't move TMPDIR from one directory to another Oct 03 21:10:48 woglinde confirmed, it does work now Oct 03 21:11:15 tworkin: you can however use the sstate-cache from the first build to accelerate your build in a different TMPDIR Oct 03 21:11:19 woglinde thank you again, it's a beautiful thing when a build finishes :) Oct 03 21:13:12 bluelightning: i dont mind a totally fresh build / cache delete. Oct 03 21:13:25 bluelightning: deleting the tempdir and starting over seems to be a fix. thanks Oct 03 21:13:48 tworkin: that's the other option of course Oct 03 21:13:51 tworkin: np **** ENDING LOGGING AT Fri Oct 04 02:59:58 2013