**** BEGIN LOGGING AT Tue Nov 10 02:59:59 2015 Nov 10 08:04:14 good morning Nov 10 08:19:20 morning all Nov 10 08:46:41 hi bluelightning Nov 10 08:49:01 hi mckoan Nov 10 09:57:27 morning all Nov 10 10:57:05 hello Nov 10 11:05:52 hi Nov 10 11:07:46 how do I know which directory a bitbake task will execute in? Nov 10 11:07:53 (the CWD) Nov 10 11:08:29 or should I always start my tasks with a "cd", if it's important to run in the correct dir? Nov 10 11:27:10 mago_: it'll be the first directory specified in [dirs] for the task Nov 10 11:27:20 mago_: by default that's ${B} I think Nov 10 11:28:29 but you can set do_whatever[dirs] = "${WORKDIR}/your/desired/path" Nov 10 11:30:37 bluelightning: okay, thanks Nov 10 11:31:09 bluelightning: have you ever seen warnings like this? For some reason, bitbake spams them while building a recipe of mine. I suspect I have somehow messed up the license-stuff... Nov 10 11:31:20 WARNING: log_check: There is a warn message in the logfile Nov 10 11:31:21 WARNING: log_check: Matched keyword: [WARNING:] Nov 10 11:31:23 WARNING: log_check: WARNING: The license listed PSFv2 was not in the licenses collected for python Nov 10 11:31:36 i see similar warnings for udev, usbutils, screen, sysvinit etc.. Nov 10 11:31:45 BUT, there is no warn message in the logfiles Nov 10 11:31:52 (of none of these packages) Nov 10 11:32:12 that comes from the do_rootfs log for the image Nov 10 11:33:36 bluelightning: okay, and it seem to be coming from the license_create_manifest .. which in turn emits this if some files are missing; although none of this gives me any clues on what im doing wrong here to cause this error Nov 10 11:33:46 I don't think you've done anything wrong Nov 10 11:34:05 I think we changed something to trigger this warning, I don't know the details - but if do_populate_lic re-executes for those recipes I think it should go away Nov 10 11:34:21 my recipe manually sets up a dependency on another image using variable flag [depends] = myotherimage:do_rootfs Nov 10 11:34:33 bluelightning: well, it happens everytime i cleansstate and rm -rf tmp-glibc Nov 10 11:34:39 so for every clean build, this happens Nov 10 11:35:04 that's not going to be the cause Nov 10 11:35:54 so just to check , do you have a directory tmp/deploy/licenses/python ? if so what's in it? Nov 10 11:40:16 bluelightning: there's no python directory in there Nov 10 11:41:44 bluelightning: it's kind of funny. i have an image recipe X.bb. It builds fine, and afterwards, license-folders are populated properly. Then I have a normal recipe Z.bb which has a task that depends on X.bb do_rootfs. If I bitbake Z, it will correctly trigger and run do_rootfs for X, but for some reason no license files are populated? Nov 10 11:42:01 so perhaps i should depend on something other than do_rootfs to get the image AND all the license stuff in place? Nov 10 11:43:13 hmm, actually I'm wondering where we add the dependency on that task Nov 10 11:43:30 if you now "bitbake python" does it create that file? Nov 10 11:43:35 or rather the directory Nov 10 11:44:00 probably do_populate_lic ? Nov 10 11:44:16 if i bitbake python, the license dir shows up Nov 10 11:44:24 right, I think I know what's going on Nov 10 11:44:48 do_rootfs tries to use the data written by do_populate_lic for all of the recipes producing packages that go into the image Nov 10 11:45:22 which would be OK, as long as populate_lic runs before do_rootfs i suppose? Nov 10 11:45:23 but there doesn't appear to be an explicit statement somewhere ensuring that all those do_populate_lic tasks have run Nov 10 11:45:47 except for do_build of the image depending on do_build of all those recipes Nov 10 11:46:02 so most of the time it works, except if you run do_rootfs on its own Nov 10 11:46:07 this would be a bug Nov 10 11:46:18 can I depend on X:do_build instead then? Nov 10 11:46:28 (to work around the problem) Nov 10 11:54:05 you could yes Nov 10 11:58:39 bluelightning: but it's still a risk that rootfs will run before populate_lic, right? cause im just saying Z cannot run until X:do_rootfs and X:do_populate_lic has run,.. but i guess i can't say X:do_rootfs must run after X:do_populate_lic from the Z recipe? Nov 10 11:59:29 bluelightning: (if i were to add both do_rootfs and do_populate_lic to the depends?) Nov 10 12:02:13 the only way to properly fix this is add the dependency from do_rootfs on all the recipes that it depends on Nov 10 12:09:14 bluelightning: isn't that what IMAGE_INSTALL is? Nov 10 12:09:31 IMAGE_INSTALL is the source of the package list Nov 10 12:09:41 one moment Nov 10 12:10:00 depending on do_build of my image seem to at least fix my problem, no more warnings are emitted Nov 10 12:10:08 it might not be the correct fix, but at least it works (tm) :) Nov 10 12:10:18 in theory it should br as simple as do_rootfs[recrdeptask] += "do_populate_lic" Nov 10 12:10:32 do_rootfs fails a "* opkg_install_cmd: Cannot install package vlc." in the log, how am I supposed to debug that? :/ Nov 10 12:10:57 rburton: hello; I sent a u-boot patch with the patches included Nov 10 12:11:03 rburton: please queue it for mut Nov 10 12:11:33 already done Nov 10 12:11:44 funman: does the vlc recipe actually produce a package called "vlc"? I suspect it's not and that's the reason you're getting that error Nov 10 12:12:24 funman: hmm, it looks like it should though Nov 10 12:17:04 bluelightning: it's there Nov 10 12:17:51 looking at /var/lib/opkg/status, libvlc has Status: install ok not-installed Nov 10 12:18:00 and vlc Status: install user not-installed Nov 10 12:20:07 rburton: rburton thx Nov 10 12:21:16 http://chui-pas.net/~fun/log.do_rootfs.30522 Nov 10 12:24:22 funman: well, I have to say I have no idea what's going wrong there, but opkg should be telling you what the actual problem is and it doesn't seem to be doing that Nov 10 12:31:04 indeed not Nov 10 12:32:11 adelcast: don't suppose you can shed any light on this? ^ Nov 10 12:32:47 there also seems to be 2 logs pasted together Nov 10 12:33:05 maybe opkg is mixing stdout and stderr Nov 10 12:33:43 yes that did look a bit odd Nov 10 12:33:53 Hi, I'm wondering if someon could do a review on my gclient fetcher patch for bitbake? Nov 10 14:11:52 http://git.openembedded.org/meta-openembedded-contrib/log/?h=funman/vlc Nov 10 14:23:47 funman: strictly speaking when you introduce a new PACKAGECONFIG[] item to replace item(s) that were previously hardcoded in DEPENDS, you should be including the new item in the default PACKAGECONFIG value so that the effective default doesn't change Nov 10 14:24:34 understood, i asked Tim what he thought about that Nov 10 14:25:09 maybe i should keep the current defaults until I can propose and debate different defaults Nov 10 14:25:51 for example.. who uses firewire? Nov 10 14:31:44 that's a good question Nov 10 15:31:31 mago_: I just sent a fix for OE-Core for that issue btw Nov 10 15:31:42 thanks for prompting me to look into it Nov 10 15:31:57 bluelightning: cool :) thanks! i'll probably merge it in a year or so when we get to that rev Nov 10 15:32:37 FWIW in the mean time you can throw that one line in your image recipes if you want Nov 10 15:33:17 if you do that make sure you add a comment explaining what it's for so you know when it can be removed ;) Nov 10 15:41:28 great, i'll have a look Nov 10 16:14:09 funman: yeah, opkg error reporting could definitely use some love...to debug your specific problem I would try to run the opkg command that is trying to install one of the packages that fail directly (maybe just try to install one of the packages that fail). Then hopefully you will get a more descriptive error other than 255 Nov 10 16:14:39 if that gives you meaningless errors still, you can try to run opkg with -V4 and show/send me the log, I can try to look into what's going on Nov 10 16:16:07 adelcast: i entered the rootfs using chroot / qemu-user-arm but not sure where exactly it is getting the packages feed from Nov 10 16:16:51 I use the same build folder for a couple different machines (namely odroid-c1 and raspberrypi2), that might explain the failures. The opkg was failing for raspberrypi2, but suceeded when I built an odroid-c1 image Nov 10 16:19:00 I see, so the feed might be polluted...you can get the feed URL from /media/fun/WORK/angstrom/build/tmp-angstrom-glibc/work/raspberrypi2-angstrom-linux-gnueabi/systemd-image/1.0-r0/opkg.conf **** ENDING LOGGING AT Wed Nov 11 02:59:58 2015