**** BEGIN LOGGING AT Mon Sep 28 02:59:58 2015 Sep 28 07:03:01 good morning Sep 28 08:46:03 morning all Sep 28 08:53:51 bluelightning: good morning :-) Sep 28 08:54:07 hi parrot Sep 28 09:01:46 bluelightning: I've no problems in yocto so far since I already got the beignet port job done and I've passed down that hard job of actually maintaining the recipes to someone else. What a relief :-) Sep 28 09:02:04 I guess you'll be happy to hear less issues from me as well lol Sep 28 09:02:30 parrot: glad to hear you're havving success :) Sep 28 09:02:42 so I'm just saying hi here which is a pleasure Sep 28 09:03:12 bluelightning: that actually took me like 5 months but I was still ahead of time which is surprising Sep 28 09:03:27 parrot: I don't mind helping with any issues you might have Sep 28 09:04:51 bluelightning: I know. And I'm glad of that. I wouldn't have achieved that without the you and yocto folks here. Sep 28 09:05:06 *omit "the" Sep 28 09:05:14 :) Sep 28 14:30:30 Does anyone have a link to the supported shell types? Sep 28 14:32:42 supported host shell types Sep 28 14:35:18 jedix: bash or dash Sep 28 14:36:19 rburton: I thought zsh was supported? Sep 28 14:36:45 nope Sep 28 14:37:14 sanity.bbclass explicitly checks that /bin/sh is either dash or bash Sep 28 14:38:44 but what about $SHELL checks? Sep 28 14:39:45 well, SHELL is unexported in the build Sep 28 14:40:17 so it can't impact your builds anyway Sep 28 15:06:46 rburton: actually, sanity.bbclass @ http://git.openembedded.org/openembedded/plain/classes/sanity.bbclass says "Using dash as /bin/sh causes various subtle build problems, please use bash instead." Sep 28 15:08:25 jedix: er, that's OE-Classic, which is ancient by now Sep 28 15:08:37 jedix: we've supported dash as /bin/sh for quite some time Sep 28 15:08:46 oh Sep 28 15:24:16 jedix: the user's shell is irrelevant to the build. it's /bin/sh that matters Sep 28 15:29:37 thanks Sep 28 16:12:53 linux-yocto tooling on master is causing some issues for me. I have two bbappends in two different layers adding patches to kernel and the kernel is upstream linux-stable using linux-yocto tooling only. All meta/ needed for kernel tooling is in recipe space as well. The problem I see is that it applies all the patches from first bbappend. Then it appends the remaining patches from layer2 to the series and then tries to start again instead of just trying Sep 28 16:12:53 to apply the remaining patches from layer2 Sep 28 16:13:10 * khem` pokes zeddii Sep 28 16:17:39 QA Issue: gstreamer1.0-plugins-base: The compile log indicates that host include and/or library paths were used. Sep 28 16:18:00 hmm. I'll set up something similar here. should be easy enough to fix. Sep 28 16:18:08 but puttin "INSANE_SKIP_gstreamer1.0-plugins-base += "compile_host-path"" in my local.conf doesn't fix Sep 28 16:18:25 tripzero1: better to fix the problem instead of turning off the warning Sep 28 16:18:56 rburton: the problem is a massive rabbit hole. It's the gobject-introspection doesn't crosscompile problem. Sep 28 16:19:12 why is it even touching introspection as it doesn't work at all Sep 28 16:19:45 I added the meta-gir layer. not even this works at all? Sep 28 16:20:57 in that case you get to fix meta-gir ;) Sep 28 16:21:50 the error might be a feature, not a bug. meta-gir doesn't crosscompile, it compiles the introspection native using qemu Sep 28 16:22:23 i suspect that the QA issue is somehow related, but I'm no expert on the dots inbetween Sep 28 16:39:20 zeddii: btw this works fine with 1.6 Sep 28 16:39:30 zeddii: currently seeing it with master Sep 28 16:39:36 not sure about fido Sep 28 16:39:42 I made some significant changes, they are only in master. Sep 28 16:39:52 ok Sep 28 16:40:13 zeddii: I tried SRC_URI += or _append Sep 28 16:40:17 same results Sep 28 16:40:18 I'm setting up a test case. I run tests like that (patches from multiple layers), but something may have slipped through. Sep 28 16:40:28 OK cool Sep 28 16:40:35 If I can't make my test blow up, I'll ping you for details. Sep 28 16:41:10 zeddii: sure Sep 28 16:41:36 its simple aditions to linux-yocto-custom.bb Sep 28 16:41:40 from meta-skeleton Sep 28 16:41:58 point to linux-stable Sep 28 16:42:10 and apply bunch of patches in different layers Sep 28 16:42:29 cool. I have layers that simply add a number to extra_version in the kernel Makefile, I stack them up to make sure things work. Sep 28 16:42:30 I have actually tried the scc method as well Sep 28 16:42:44 same result Sep 28 16:42:48 I'm updating them to run against 4.1 and stable. will see what I get. Sep 28 16:42:53 ok Sep 28 16:44:12 random comment: does anyone else think _ESSENTIAL_EXTRA_ is a bit silly, naming wise? (re the rdepends/rrecs vars) Sep 28 16:44:25 seems rather contradictory :) Sep 28 16:45:16 course we have bigger annoyances than that in our variable naming consistency, but still :) Sep 28 16:52:31 yeah change it Sep 28 16:58:19 i wish repo would summarize the errors at the bottom. it's easy to miss a failed checkout due to local modifications due to the parallel updating Sep 28 17:00:47 otavio: ping Sep 28 17:02:38 kergoth: pong Sep 28 17:03:30 * paulg wonders if anyone has successfully booted a powerpc systemd image recently... Sep 28 17:03:46 otavio: what's the status of the meta-fsl-{arm,ppc} to meta-freescale migration and the support status of the former? is there a timeline for deprecation of the former? Sep 28 17:04:36 fray : ELCE phone call? Sep 28 17:05:17 khem: I see breakage. fixing. Sep 28 17:05:22 otavio: also what about the freescale official sdks, are any releasing based on meta-freescale yet? Sep 28 17:05:23 :) Sep 28 17:05:42 * zeddii grumbles and gets coffee before editing a file. Sep 28 17:06:32 zeddii: always a good policy Sep 28 17:06:41 i should really follow it more.. Sep 28 17:06:42 :) Sep 28 17:06:46 kergoth: this is a complex question Sep 28 17:07:27 kergoth: the next qoriq sdk will be based on meta-freescale; the imx will not move to this until 2.1 release Sep 28 17:07:48 rough timeline on that? Sep 28 17:07:59 kergoth: meta-freescale will be the consolidation and likely stable for 2.1 timeline Sep 28 17:08:06 (sorry for the pestering, judging based on our own release schedule) Sep 28 17:08:25 kergoth: i want to discuss some issues with you Sep 28 17:08:53 kergoth: seems like a lot of fixes are merged in meta-mentor and I wish those in fsl-arm, fsl-ppc Sep 28 17:09:26 ah, yes, good point, i've been working through our oe-core backlog, but haven't pushed enough to the vendor bsp layers. we'll work on that Sep 28 17:11:17 you know how it is, easy to focus on release priorities and fall behind on upstream submissions, then have to play catchup on the backlog after release :) Sep 28 17:15:26 kergoth: yes but as I am active we could try upstream-first approuch and see if it works for fsl related layers Sep 28 17:15:34 agreed. Sep 28 17:15:52 I'll start rejecting fsl specific pull requests to meta-mentor :) Sep 28 17:29:32 configfs: no symbol version for in_group_p Sep 28 17:29:38 anyone run into this one with gcc 5.2? Sep 28 17:37:46 kergoth, have not seen that ; built powerpc and x86-64 on latest everything just yesterday... Sep 28 17:38:05 Hmm, k, thanks Sep 28 17:38:32 powerpc wouldn't run systemd, but it did _build_ Sep 28 17:40:58 we're getting it on bootup, configfs module fails to be inserted Sep 28 17:41:11 * kergoth checks kernel commits Sep 28 17:45:17 zeddii: cool Sep 28 17:45:42 zeddii: if you have patch to test I can help testing it out in our setup here Sep 28 18:00:38 khem: I see the problem. but it isn't as simple to fix as I'd like. I'm making a change now, and will ping you with a patch to test when I'm done. Sep 28 18:00:40 someday i'm going to remember the commands to connect to wifi with connman, i swear Sep 28 18:00:49 * kergoth has to look it up every damn time Sep 28 18:01:04 zeddi ok no worries Sep 28 18:01:10 if you dont see me here Sep 28 18:01:11 email it to me Sep 28 18:01:36 * zeddii nods Sep 28 18:01:44 kergoth, odd. kernel/groups.c has EXPORT_SYMBOL(in_group_p); Sep 28 18:01:49 weird Sep 28 18:02:03 * kergoth checks to see if mentor did something hokey in our kernel repo :) Sep 28 18:02:04 to be fair I'm building 4.2 via linux-yocto-dev now... Sep 28 18:02:33 evil vendor trees Sep 28 18:02:39 makes zeddii feel better knowing someone is using the dev tree. :) Sep 28 18:03:54 has been exported since 2009 according to git blame, so should be in all trees. Sep 28 18:30:05 bluelightning: hmm, just noticed appendfile will happily overwrite an existing file in the filesdir. e.g. if i'm appending two files in the rootfs with different destinations, but the same basename, they'll step on one another Sep 28 18:46:36 I've tried to set up PREMIRRORS in my poky/conf/local.conf, but how do I know bitbake is using local sources? Sep 28 18:49:56 poky/conf/local.conf? that's not where local.conf goes. local.conf is in your build directory Sep 28 18:50:07 beyond taht, you can examine any variable to make sure it's set the way you think it is by using bitbake -e Sep 28 18:51:45 I'm sorry, I meant to say build/conf/local.conf. Sep 28 18:51:53 Thanks for the bitbake tip, I'll use that. Sep 28 18:55:59 khem: sent a patch to your gmail inbox Sep 28 18:58:11 Hmm, I wonder if the headrevs dump/restore bits in meta-mel would be of interest for oe-core or meta-oe Sep 28 19:04:10 zeddii: yes testing the v2 Sep 28 19:38:33 <][Sno][> otavio: now I have OpenJDK running on all target's I have to support (no shark, zero only) - I can start tidy up meta-java & Co. tomorrow (will rebase to master on all affected repos) Sep 28 19:41:18 * ][Sno][ commutes Sep 28 19:48:50 Hi everybody out there - I am looking for some information how a "versioned firmware relaese" can be done with yocto. Did a lot of reading but didn't find anything really helpful, it seems the PREFERRED_VERSIONS could be my friend but this sounds really complicated Sep 28 19:49:03 Do you have any suggestions where to start reading? Sep 28 19:49:13 Many thanks in advance for your help! Sep 28 19:49:54 preferred version is used to pick between versions of a recipe, which is an upstream project. it doesn't sound like that would have anything to do with what you're doing Sep 28 19:50:02 but i'm guessing at that, since you haven't told us anything about what you're trying to accomplish Sep 28 19:51:24 The job what needs to be done, is to create a firmware package with consists of well known and defined (ideally documented as well) versions of each package Sep 28 19:52:07 you're using 'package' to mean two completely different things in one sentence Sep 28 19:52:09 I expect yocto will update / fetch new versions if there are any, for the next build if I didn't define this anywhere, right? Sep 28 19:52:14 i'd suggest getting the terminology righ tto avoid confusion Sep 28 19:52:30 ok, sorry for the confusion! Sep 28 19:52:58 also 'firmware' is a very fuzzy term, most folks around here consider firmware the binaries that are loaded on wifi adapters and whatnot, used by drivers Sep 28 19:53:05 that's if you're updating to current yocto on a regular basis. there's no need to do so Sep 28 19:53:17 either use a specific version of the metadata and bitbake, or stick to a stable branch which will only get bugfixes Sep 28 19:53:59 you shouldn't be basing on master and updating regularly if you expect to avoid version updates and possible breakage :) Sep 28 19:54:19 ok, but even if I get bugfixes, my linux distro (to avoid the term firmware in this context) will change, without getting me informed? Sep 28 19:54:55 with regards to e.g. medical approvals this sounds a bit dangerous? Sep 28 19:54:56 i don't understand the question Sep 28 19:55:04 your git checkouts aren't going to magically update themselves Sep 28 19:55:06 halstead: go ahead and take the snapshot. let me know when done so I can move on Sep 28 19:55:07 if you don't want it updated, don't update it Sep 28 19:55:44 challinan, Thank you. I'll let you know. Sep 28 19:55:58 <_taw_> Stripped down image.bbclass to paste below. Did the same to core-image-minimal, inherits image.bbclass directly now. Still rebuilds rootfs on every invocation Sep 28 19:56:09 <_taw_> http://pastebin.com/E2XL8fbC Sep 28 19:56:44 hmm, but some packages may be updated, others not - I am looking for a way to "pin" recipies to a fixed version and have control over this version Sep 28 19:56:49 can you get what I mean? Sep 28 19:57:00 dieter_: that's not going to happen, because yocto doesn't keep old versions around in the repo Sep 28 19:57:07 when versions are bumped, old recipes are deleted Sep 28 19:57:36 you could use preferred version for everything and also copy any removed recipes to your layer Sep 28 19:58:21 kergoth: Maybe I am completely wrong, but I guess this is an important issue for all embedded developers who want to have control over the content of the root file system? Sep 28 19:59:03 kergoth: ok, will dig into preferred version more in deep to see how this is working for my use case. Sep 28 19:59:18 _taw_: run bitbake -S none yourimage, then run it again, and there should be two sigdata files in tmp/stamps/ for it, with two different checksums. you can use bitbake-diffsigs to compare the two and see what it thinks changed Sep 28 19:59:19 kergoth: many thanks for your help! Sep 28 19:59:55 dieter_: if you don't want oe-core to update, don't update oe-core. this is what stable release branches are for. Sep 28 20:00:13 _taw_: of course, really old oe-core versions had the task flagged as nostamp, and it was intended that it always ran, so it depends on what version you're on Sep 28 20:00:23 <_taw_> 2.0 Sep 28 20:00:43 that version number doesn't even make sense. Sep 28 20:00:45 there is no 2.0 Sep 28 20:00:47 unless you mean master? Sep 28 20:00:51 2.0 is unreleased, in progress Sep 28 20:01:46 <_taw_> I guess master, we wanted to go 1.8, but since 2.0 is upcoming we probably skipped that Sep 28 20:02:10 in either case do_rootfs should only run if something it depends on changed, so you'll need to work out what it thinks changed Sep 28 20:02:54 _taw_, kergoth: i just hopped onto irc for help to determine why my image recipe is constantly rebuilding Sep 28 20:03:17 _taw_, kergoth: i am going to try the bitbake -S none ... command Sep 28 20:03:31 the most likely culprit is some task is using DATE/TIME/DATETIME vars without them being excluded from the checksums, and do_rootfs depends on that Sep 28 20:03:57 bitbake -S printdiff will print the delta between what it's building and what's available in sstate, but of course do_rootfs isn't in sstate, so that won't be helpful. i think none should still dump the sigdata for the task, though Sep 28 20:04:33 although, printdiff does check STAMPS_DIR too, so it might work. bitbake -S none yourimage, then bitbake -S printdiff yourimage Sep 28 20:06:08 bluelightning: would https://github.com/openembedded/openembedded-core/compare/master...kergoth:headrevs be of interest to populate_sdk_ext to avoid bitbake contacting upstream at parse time in the ext sdk? Sep 28 20:06:31 bluelightning: although, thinking about it, there probably aren't any autorev recipes in the layers in ships by default Sep 28 20:07:34 We use this for mel, as we ship downloads in our installers, like to use autorev while doing kernel development, and want to support BB_NO_NETWORK Sep 28 20:20:07 challinan, Export complete. Would you mind if I restarted your machine using the new snapshot to make sure it works as expected? Sep 28 20:20:32 not at all, that will be a good test ;) Sep 28 20:21:30 challinan, One minute. Sep 28 20:29:21 challinan, New machine is up. Same ports and everything. Let me know if anything is weird or missing. Sep 28 20:32:45 <_taw_> kergoth, thanks for your help, bitbake-dumpsig/diffsig is what I was looking for... Sep 28 20:33:09 np, cool Sep 28 20:37:54 halstead: thanks. will do Sep 28 21:28:00 Hmm, the convention for udev-extraconf seems to be to put it in MACHINE_EXTRA_RRECOMMENDS.. but isn't whether we want automount of storage both a distro *and* machine decision? the latter being whether we have internal media to automount (e.g. beaglebone black when booting off of sd, automount mounts the internal emmc partitions) or external ports which can connect storage devices, and the former being a matter of policy, whether we care about automatic Sep 28 21:28:01 mount of external media? actually, if the image provides a graphical environment that handles it at that level, it could arguably be an image decision, even. Sep 28 21:28:12 it definitely seems more distro than machine to me Sep 28 21:32:30 * kergoth just noticed meta-mel is appending systemd to force a dep on udev-extraconf, which is weird since we could have just put it in DISTRO_EXTRA_RRECOMMENDS, but then noticed it's more ofte in MACHINE_EXTRA_RRECOMMENDS by convention Sep 28 21:32:38 actually seems like a good candiate for packagegroup-base's feature handling Sep 28 21:32:41 candidate, even Sep 28 21:58:26 kergoth: machine recommends is certainly not the right place Sep 28 22:35:38 rburton: okay, that's what i was thinking too, thanks **** ENDING LOGGING AT Tue Sep 29 02:59:58 2015