**** BEGIN LOGGING AT Mon Mar 13 03:00:01 2017 Mar 13 03:05:55 khem: i've been plugging away at my claim that openembedded-core HEAD (a47e64d985) is broken Mar 13 03:06:21 RP: the problem was introduced with: fa764a403d base/bitbake.conf: Filter contents of PATH to only allow whitelisted tools Mar 13 03:06:37 on a completely clean build, starting from scratch, the issue occurs Mar 13 03:06:59 if you have an already-working build, fa764a403d doesn't cause any problems Mar 13 03:07:41 i *think* it might be masked by a pre-existing conf/sanity_info file, or maybe it's something in cache/sstate-cache Mar 13 03:09:35 tlwoerner: I did a completely new build Mar 13 03:12:46 tlwoerner: for u-boot shouldnt you be adding dtc-native to DEPENDS Mar 13 03:13:43 khem: true, but building it by hand on the cmdline should then allow the u-boot recipe to succeed; it's how i prove missing DEPENDs normally Mar 13 03:14:57 can you check if dtc is available in recipe-native sysroot Mar 13 03:16:28 i doubt building by hand will do much with recipe specific sysroots, but *shrug* Mar 13 03:18:27 kergoth: true, this can happen if PATH is being molested to remove native sysroot from it Mar 13 03:18:38 wich the patch seems to not be doing Mar 13 03:31:02 http://lpaste.net/353474 Mar 13 03:31:11 seems everything is in order Mar 13 04:11:25 khem: kergoth: thanks so much for the help, seems i need to adjust my workflow Mar 13 04:14:22 sadly, dtc-native is already there, but without having it added to the bootloader's DEPENDS... :-) Mar 13 07:32:31 tlwoerner: the idea behind recipe specific sysroots is they only see what is in DEPENDS so this is consistent with that. There are of course ways of working about it but it sounds like the system is behaving deterministically (which is the intent) Mar 13 07:33:35 RP: yes, sounds good :-) Mar 13 07:46:29 good morning Mar 13 07:58:20 Im having trobles compiling gpsd i edited the EXTRA_OESCON so it contains libgpsmm='true' \. but i still get: C++ doesn't work, suppressing libgpsmm build. even after a -c cleanall -f Mar 13 10:28:44 hmw_: you'd need to check what kind of test it's performing to determine whether or not the compiler "works" Mar 13 10:29:19 hmw_: any logs in ${B} ? - if you aren't sure where that is: bitbake -e gpsd | grep ^B= Mar 13 10:43:27 is there a recommended way to install a complete directory hierarchy in do_install? Mar 13 10:43:44 cp -r Mar 13 10:44:20 seriously? i always was under the "do not use cp, use install"-impression Mar 13 10:48:15 that's how i do it at least :) Mar 13 11:25:19 bluelightning: the directory B= is not a existing one Mar 13 11:26:43 hmw_: have you enabled rm_work perhaps? Mar 13 11:26:44 it is using work/armv5e-linux-gnueabi/gpsd instead of work/cortexa8hf-vfp-neon-linux-gnueabi/gpsd Mar 13 11:27:31 bluelightning it is commented #INHERIT += "rm_work" in my local.conf Mar 13 11:33:07 bluelightning: the strange part is that if i run the build on the original machine is that it works. and there is no differencs between the two source directorys in the oe-core Mar 13 12:04:34 bluelightning: The only other things that are diferent in the source dir are a few .inc files ( linking to the wrong linaro website ) uboot a newer cpuset version ( 1.5.7 instead of 1.5.6 ) and the pysh tables.py Mar 13 22:12:12 how do people handle automounting of removable media. There is udev-extraconf, which I've used in past, but for some reason it does not seem to work with one system. Udev sends events for both /dev/sda and /dev/sda1, and its not clear how the mount script figures how what to do. Mar 13 22:14:42 if i wanted to do something for a product i'd use glib's mount abstraction stuff to add an automounter to the UI Mar 13 23:19:07 cbrake: systemd has mechanisms for automounting is it for systemd ? Mar 14 00:45:50 khem: yes, systemd, but a pretty old build. Need to upgrade this project to Morty, so may make sense to revisit then. Mar 14 01:22:50 cbrake: yeah i think that would be in order **** ENDING LOGGING AT Tue Mar 14 03:00:02 2017