**** BEGIN LOGGING AT Tue Oct 21 02:59:59 2014 Oct 21 06:24:59 morning all Oct 21 06:37:35 otavio: by meta-oe you mean for meta-qt5? Oct 21 09:32:36 is there a neat way to tell runqemu that it shall not pass a rootfs? like, i want to test the builtin initramfs only? Oct 21 10:12:44 hi. any idea why i can't add "nfs-server" as an EXTRA_IMAGE_FEATURE? i get the error message: 'nfs-server' in IMAGE_FEATURES is not a valid image feature ...and then a list of the available features (which does not include nfs-server) Oct 21 10:13:46 so, to rephrase, how do i add nfs-server to the available features? i'm on daisy. Oct 21 10:16:02 ionte: maybe its just not a IMAGE_FEATURE, but a common recipe? Oct 21 10:17:39 LetoThe2nd: not according to the reference manual (http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html), section 9.3 Oct 21 10:17:46 ionte: looks like nfs-utils is your best bet Oct 21 10:18:48 ionte: agreed, but still there's always the possibility that docs are incorrect. did you try and grep your poky tree for "nfs-server"? Oct 21 10:21:06 LetoThe2nd: not yet Oct 21 11:17:03 JaMa: in meta-oe ml Oct 21 11:17:19 you mean oe-devel ml? Oct 21 11:17:31 yes sorry hehe Oct 21 11:18:28 feel free to merge that one + one from Anders (more libs in sdk) Oct 21 11:18:54 I'm still leaving this whole sdk business to you, because I don't have good test-case for it Oct 21 11:19:00 JaMa: the cmake fix needs to wait for oe-core fix to be merged first Oct 21 11:19:14 JaMa: I know Oct 21 11:20:08 does the qt5 SDK environment change in master mean that it won't work with daisy and older releases? Oct 21 11:20:10 JaMa: where is Anders patch marked for review? Oct 21 11:20:34 Net147: yes; dizzy changed completely the environment way Oct 21 11:20:40 Net147: so yes. Oct 21 11:21:12 otavio: meta-qt5 bundle Oct 21 11:21:14 otavio: seems unfortunate we can't maintain backward compatibility Oct 21 11:21:44 Net147: sorry but this is not something expected. We have branches for each release for that Oct 21 11:21:44 otavio: but there was v2 sent last week (not yet in bundles) Oct 21 11:22:16 Net147: and we cannot afford the backports as it'd change for existing users and products Oct 21 11:22:21 JaMa: ok Oct 21 11:31:08 JaMa: http://patches.openembedded.org/patch/81853/ this is the v2 Oct 21 11:31:22 JaMa: this is the one you meant to get merged? Oct 21 11:34:39 y Oct 21 11:36:12 otavio: also this one http://patchwork.openembedded.org/patch/81599/ from Net147 Oct 21 11:39:38 JaMa: good; applied. Oct 21 11:39:54 JaMa: I am not applying the cmake one as it depends on oe-core change Oct 21 11:42:20 ok Oct 21 11:42:45 what do you think about upgrading to 5.4-beta (in git recipe) before branching dizzy? Oct 21 11:43:38 JaMa: I think it'd be perfect Oct 21 11:43:49 JaMa: :) Oct 21 11:44:00 JaMa: when final is planned, do you know? Oct 21 11:44:04 JaMa: otavio: thoughts on http://patchwork.openembedded.org/patch/81603/ ? Oct 21 11:45:00 otavio: target is 2nd dec Oct 21 11:45:35 Net147: I am fine with http://patchwork.openembedded.org/patch/81603/; JaMa ? Oct 21 11:48:43 fine with me, I wanted to update meta-qt5/qtbase branches before applying that Oct 21 11:48:57 and I was also checking if some new QA issues are caused by this Oct 21 11:49:12 JaMa: I will let it for you than Oct 21 12:04:39 <_ccube> hey guys! I got an custom yocto image for the a10s board. can I assume, that its working kind of the same on a10 boards if I rebuild for a10 with the same yocto build scripts? Or are there major differences I have to be aware of? Hardware looks pretty much the same, isnt it? Oct 21 12:51:37 _ccube: usually each board has its own kernel and are not interchangeable Oct 21 14:49:56 So I've just tried building a daisy image (our custom image with some specific bsp parts) and the build fails on xserver-xorg Oct 21 14:51:08 It's an error I haven't come across before... here's a build log: http://paste2.org/9m42xHaE Oct 21 14:52:05 saying __aeabi_unwind_cpp_pr0 and _pr1 are missing during linking. Any suggestions? Oct 21 14:54:21 yes, something has floating dependency on libunwind, it was fixed in dizzy/master Oct 21 14:55:09 see oe-core 6b1418a2ba1544ea481fd4a89b5aa25111ca20e8 Oct 21 14:55:20 YPTM: armin is on Oct 21 14:57:07 YPTM: Ready-Access Number: 8007302996/9139049836 Access Code: 2705751 Oct 21 14:57:15 YPTM: Stephen is on Oct 21 14:58:40 YPTM: Tom Z on the call Oct 21 14:58:43 YPTM: Matthew on the call, as previously mentioned on the call :-P Oct 21 15:00:56 YPTM: Joe Mac is on the call Oct 21 15:01:03 YPTM: Denys is dialing in Oct 21 15:01:10 YPTM: Michael present. Oct 21 15:01:25 YPTM: Bruce Ashfield on the call Oct 21 15:01:40 sona on the call Oct 21 15:02:06 JaMa: thanks! Oct 21 15:02:08 YPTM: belen joined the call Oct 21 15:02:35 YPTM: RIchard joined Oct 21 15:03:05 I don't quite see why it would cause the build to fail though. Is it finding the library on the build host or something? Oct 21 15:03:10 YPTM: AlexG on the call Oct 21 15:03:15 * Jefro is on YPTM Oct 21 15:03:26 YPTM: Cristian joined the call Oct 21 15:03:30 YPTM: using Skype is easier to connect :) Oct 21 15:04:01 YPTM: Saul is on Oct 21 15:18:56 tomz2, will you be around later? I need to debug a wic issue, but headded out to lunch now Oct 21 15:20:09 yeah, I'll be around - did you see my reply on the list? Oct 21 15:20:09 YPTM is over Oct 21 15:20:38 RP, You were cut off a bit there. Thank you for the recognition. Oct 21 15:21:25 halstead: thank you for the help, you put quite some work into it :) Oct 21 15:33:38 no Oct 21 15:33:56 aoeu/leave Oct 21 16:59:19 is there any way to have a task depend on a sstate sstate_task_postfunc Oct 21 16:59:20 ? Oct 21 17:00:30 package.bbclass emit_pkgdata() is populating pkgdata during a build of a package Oct 21 17:01:04 but the pkgdata which package_write_rpm consumes via read_subpackage_metadata is the pkgdata installed in the staging dir Oct 21 17:01:22 via the do_packagedata sstate_task_postfunc Oct 21 17:01:25 that really doesn't make sense Oct 21 17:01:27 postfuncs run after the task Oct 21 17:01:33 if you dep on the task, then that'll be after the postfuncs ran Oct 21 17:02:18 so as long as do_package_write_rpm has a taskdep on do_packagedata I should be good? Oct 21 17:02:46 yes, as i said, prefuncs and postfuncs are essentially part of the task as far as the runqueue is concerned Oct 21 17:02:58 erm, to clarify, that is Oct 21 17:03:47 alright I will have a closer look at adding this dependency then Oct 21 17:04:07 it rarely happens but I have a situation I can 100% reproduce this Oct 21 17:04:30 and adding timestamps to when sstate_task_postfunc creates the staging pkgdata files Oct 21 17:05:02 and where they are comsumed by package_write_rpm I am getting them attempted to be consumed prior to the staging dir being populated Oct 21 17:05:36 which results in an exception"Exception: variable SUMMARY references itself!" Oct 21 17:05:50 since the pkgdata fails to be read, so no keys....exception Oct 21 17:10:31 tomz2, I do not see a reply to my wic email Oct 21 17:16:11 Crofton|work, hmm, I haven't seen anything form the oe-core mailing list lately either - I did send it and cc:ed you and Maciej Oct 21 17:16:23 hmmm Oct 21 17:16:47 Crofton|work, I wonder if there's something wrong with the list Oct 21 17:17:05 nothing direct either Oct 21 17:19:29 Crofton|work, ok, I just resent it, using a different account Oct 21 17:19:33 k Oct 21 17:20:54 tomz2, the account that has internet access ? :P Oct 21 17:22:14 Crofton|work, no, my other intel account, which may be the one subscribed to the list and not the other, though that wouldn't affect receiving it at your personal account Oct 21 17:22:36 yep Oct 21 17:22:39 I'll see Oct 21 17:23:10 why can't I get a serial login? Oct 21 17:32:56 kergoth: perfect, that helped me find an issue with my stuff Oct 21 17:33:05 nice Oct 21 17:33:11 it was an error on our side, upstream is in good shape Oct 21 17:33:34 thanks Oct 21 17:34:02 it was a good head scratcher Oct 21 17:34:04 np Oct 21 17:35:18 Crofton|work, ok, I just found out that we have an internal e-mail problem here so nothing is getting out, sorry Oct 21 17:35:28 bummer :) Oct 21 17:35:47 do you have a quick tip to make wic more verbose about what it is doing? Oct 21 17:36:13 Crofton|work, so let me just copy the contents here (not too much) Oct 21 17:36:46 If you think there's a problem in the way wic is creating the Oct 21 17:36:47 partitions, I'd suggest using the wic --debug option, which will show Oct 21 17:36:47 you all the details of the underlying commands used to create the Oct 21 17:36:47 partitions. Oct 21 17:36:59 If that doesn't show anything obvious, please create a bug report and be Oct 21 17:36:59 sure to include myself and Maciej, who added the new sdimage-bootpart Oct 21 17:36:59 functionality you're having trouble with, in case it turns out not to be Oct 21 17:36:59 some more generic problem in the tool. Oct 21 17:46:48 ok, Oct 21 17:46:54 I do not hthink help mentions --debug Oct 21 17:47:37 wic --debug create ../oe-core/scripts/lib/image/canned-wks/sdimage-bootpart.wks -e uhd-dev-image Oct 21 17:47:40 no suck option Oct 21 17:47:45 such :) Oct 21 17:51:46 tomz2, ^^^ Oct 21 18:06:27 moved --debug to the end of the line it it works Oct 21 18:15:20 Crofton|work, it is mentioned as the last option if you type 'wic create', but isn't in the usage string or 'wic help create'. I need to fix that Oct 21 18:15:35 yeah Oct 21 18:15:38 a little confusing Oct 21 18:15:46 I am working through the messages now Oct 21 18:16:01 boot vfat partition mounts fine on desktop Oct 21 18:16:12 jsut the root one fials with superblock like message Oct 21 18:16:23 if I amke the fs myself, it succeeds Oct 21 18:18:26 Crofton|work, curious whether that is only seen with the sdimage-bootpart plugin Oct 21 18:19:09 Crofton|work, sounds like it might make sense to open a bug for it, to at least collect info on how to reproduce it Oct 21 18:19:21 ok Oct 21 18:22:39 weird Oct 21 18:22:48 Copying files into the device: copy_file: Could not allocate block in ext2 filesystem Oct 21 18:23:06 i need to keep an eye on your progress. i'd absolutely love to stop using random mk*.sh scripts from bsp layers in favor of wic at some point Oct 21 18:23:14 yeah Oct 21 18:23:21 I'm in the same boat Oct 21 18:23:38 its not critical, but Would Be Nice Oct 21 18:23:39 this is not the fastest way to make a card, but I think it is the least erroir prone Oct 21 18:23:59 wtf, my build of Textual (irc client) has suddenly decided to start coloring the background of the lines i type purple. but only in this channel, none of the others Oct 21 18:24:01 hah Oct 21 18:24:07 thats what i get for buiilding from master :) Oct 21 18:24:13 * kergoth rolls eyes Oct 21 18:28:31 * Crofton|work wonders what the -F and -d options to mkfs.ext4 are for? Oct 21 18:28:36 not in help Oct 21 18:29:26 ok found -F in man page Oct 21 18:29:33 i'm guessing -d is the genext2fs equivalent, construction from a rootfs directory Oct 21 18:29:43 * kergoth shrugs Oct 21 18:29:45 would make sense,t hough Oct 21 18:30:48 yeah Oct 21 18:30:59 just wondering if funnay stuff is going on Oct 21 18:35:35 interesting Oct 21 18:35:35 [balister@thuvia ~]$ sudo mkfs.ext4 -F -i 8192 /var/tmp/wic/build/rootfs_root.ext4 -d /home/balister/src/oe-core/build/tmp-glibc/work/ettus_e300-oe-linux-gnueabi/uhd-dev-image/1.0-r0/rootfs Oct 21 18:35:35 mkfs.ext4: invalid option -- 'd' Oct 21 18:36:09 guessing e2fsprogs-native is newer? Oct 21 18:36:11 * kergoth shrugs Oct 21 18:36:21 checking the one in the sysroot now Oct 21 18:37:53 the one in the sysroot seems ok Oct 21 18:39:20 ok the command fails Oct 21 18:50:27 tomz2, I feel like the partition size is wrong Oct 21 18:51:07 Crofton|work, way wrong, or off-by-one type of wrong? Oct 21 18:51:27 is it trying to size it based on amount of stuff in the -d? Oct 21 18:51:33 directory Oct 21 18:51:54 running the command by hand gets a copy file error Oct 21 18:52:05 but it worked if I used a small directory Oct 21 18:55:40 Crofton|work, yeah, 'If --source ' is used, it tells the Oct 21 18:55:40 wic command to create a partition as large as Oct 21 18:55:40 needed and to fill with the contents of the Oct 21 18:55:40 partition Oct 21 18:55:59 hmm Oct 21 18:56:17 wic create ../oe-core/scripts/lib/image/canned-wks/sdimage-bootpart.wks -e uhd-dev-image --debug Oct 21 18:56:22 is what I used Oct 21 18:58:29 it makes a 707M file for a 697 rootfs Oct 21 18:58:32 Crofton|work, yeah, that's the kickstart syntax, not the command line ie. re --source Oct 21 18:58:37 I wonder if something makes that a bad size Oct 21 18:58:42 ok Oct 21 19:02:01 Crofton|work, it looks ok as a size, but that copy file error shouldn't happen - can you tell from the debug output whether it successfully copied a number of files before it hit that? Oct 21 19:02:46 if I run it by hand, it sits a copying file for a while Oct 21 19:02:59 but when it is done the fs is bad Oct 21 19:04:17 Crofton|work, yeah, it it runs into problems at any point, I'd expect the fs to be corrupt Oct 21 19:04:21 ok Oct 21 19:04:57 http://pastebin.com/5rX6dySa Oct 21 19:05:02 I remember very similar problems with the old populate-extfs stuff, but the mke2fs stuff was not supposed to have similar problems Oct 21 19:05:05 is what I see running manually against the file Oct 21 19:06:38 Crofton|work, yes, IIRC it's pretty much the same problem Oct 21 19:07:05 could it be I ahve smalkl files using one allloation unit Oct 21 19:07:13 so needing more space than calculated? Oct 21 19:07:37 Crofton|work, hmm, do you have a lot of small files? Oct 21 19:07:52 dunno :) Oct 21 19:08:14 Crofton|work, well, anyway I'd expect the -d to figure that out Oct 21 19:08:57 Crofton|work, I think this really does need a bug filed, not sure yet if the problem is in wic or mkfs -d Oct 21 19:09:36 ok Oct 21 19:11:53 trying another image that might be a little smaller Oct 21 19:12:09 I assume you need to resize the fs after writing to the card? Oct 21 19:19:15 tomz2, I did see success with core-image-minimal Oct 21 19:19:35 where success is deefiend as I can fsck the file on disk Oct 21 19:24:48 Crofton|work, yeah, and I also remember a separate bug for large partitions that was a dup of the other one. But I can't find either one at the moment Oct 21 19:39:01 man figuring out where to file bugs is painful Oct 21 19:43:12 tomz2, https://bugzilla.yoctoproject.org/show_bug.cgi?id=6863 Oct 21 19:43:13 Bug 6863: normal, Undecided, ---, richard.purdie, NEW , Wic fails to create a working image for a large file system Oct 21 19:43:31 We may need to adjust some of the settings and add the guy that did the sd card bit Oct 21 19:43:39 RP, get on this :) Oct 21 19:45:51 Crofton|work, thanks, I'll look into this, can you remind me how to create the uhd-dev-image? Oct 21 19:46:08 I was afraid you would ask Oct 21 19:46:18 it is from meta-sdr Oct 21 19:46:33 Crofton|work, sorry, but it's kind of important for this ;-) Oct 21 19:46:44 and a machien from meta-ettus, although that is close to something in meta-xilinx Oct 21 19:46:55 not the easiest to dupe Oct 21 19:47:13 although I think belen has :) Oct 21 19:47:22 I need to go look at my layer depends also Oct 21 19:47:23 Crofton|work, if it's documented in the layer, then it would be fine to just say that in the bug Oct 21 19:48:25 https://github.com/balister/meta-sdr/blob/master/README Oct 21 19:48:29 I need to update depends Oct 21 19:48:46 I suspect any machine should be abel to dupe the problem though Oct 21 19:49:13 Crofton|work: you mean you haven't updated those depends yet? Ah, the shame ;) Oct 21 19:49:18 yeah Oct 21 19:49:22 doing so now Oct 21 19:49:52 Crofton|work: thank you :) Oct 21 19:49:56 Crofton|work: I reassigned to tomz2 ;-) Oct 21 19:50:04 thanks. Oct 21 19:50:17 belen: its lovely to have someone who isn't me asking people things like that ;-) Oct 21 19:50:28 heh Oct 21 19:50:42 you didn't comment on the obsolete urls for oe-core and meta-oe Oct 21 19:52:18 RP: I wouldn't call it "ask". In my case, it's more like nagging … Oct 21 19:53:51 https://github.com/balister/meta-sdr/commit/d3bd38bc21017cf9f5e5b00774b209b7b628f472 Oct 21 19:55:20 Crofton|work, is this true, in the README? :And maybe some others. TBD. Oct 21 19:55:55 that means I might add others later Oct 21 19:56:00 the new list should be accurate :) Oct 21 19:56:15 Crofton|work, ok, that's good to know, thx ;-) Oct 21 19:56:39 the images go in boxes that customers will get Oct 21 19:56:48 and they request crazy things Oct 21 19:56:52 it may need meta-python Oct 21 19:57:34 although that may not happen until you add gnuradio Oct 21 19:57:40 I guess I better check :) Oct 21 19:57:43 Crofton|work: beautiful :) Oct 21 19:58:09 layer depends hades Oct 21 19:59:05 belen: I'm not sure I can do anything different ;-) Oct 21 20:00:25 Hi, I'd like to generate a recipe starting from a deb exploded package. I have the postinst, preinst and so on script Oct 21 21:12:58 Is there a way to tell bitbake my package (with BBCLASSEXTEND="cross") also supplies ${PN}-native? Adding PROVIDES_foo-cross += "foo-native" doesn't work (complains about nothing providing foo-native) Oct 21 21:14:04 there's no way you're going to get a single recipe to be both cross and native Oct 21 21:14:10 just have both native and cross listed in BBCLASSEXTEND Oct 21 21:14:17 that is, a single recipe can't provide both in a single build Oct 21 21:14:20 it can have both variants available Oct 21 21:14:26 BBCLASSEXTEND="cross native" Oct 21 21:14:45 kergoth: right, I can do that. It just means building essentially the same thing twice. Oct 21 21:15:14 kergoth: is the "can't" a bitbake restriction of some sort? Oct 21 21:15:21 How things get installed, perhaps? Oct 21 21:17:13 the sysroot is broken up intelligently, you can't install files into both the cross and native areas safely from a single recipe Oct 21 21:17:18 and if it's the same thing, why are you buliding -cross at all? Oct 21 21:17:29 the only time you need -cross is if something in how it's built is bound to the target Oct 21 21:18:06 kergoth: it's a compiler, but It either: targets native OR targets both native and target. Oct 21 21:18:17 kergoth: so it's kind-of "bound" to the target Oct 21 21:18:20 and kind-of not Oct 21 21:18:21 ah, interesting Oct 21 21:18:23 :) Oct 21 21:18:51 so -native and -cross packages won't clobber each other? Oct 21 21:18:58 (that was my real concern) Oct 21 21:19:17 Hmm, that does seem like a valid case for a recipe providing both. Honestly, I'd suggest double checking the staging path definitions inc ross.bbclass Oct 21 21:19:35 i'm going from memory, but iirc the cross binaries go into the native sysroot under ${STaGING_BINDIR}// Oct 21 21:19:40 so maybe it is doable to provide both, if that's the case Oct 21 21:19:49 but i wouldn't trust my memory enough to trust that :) Oct 21 21:19:53 * kergoth ponders Oct 21 21:20:50 looks like both cross.bbclass and native.bbclass have: prefix = "${STAGING_DIR_NATIVE}${prefix_native} Oct 21 21:21:02 so It appears I'll be clobbering Oct 21 21:22:02 hmm, indeed. sounds like you're right, you'd probably be best off trying to make it do both, but i've never seen it done, so you're blazing new ground there :) Oct 21 21:22:21 i'm guessing the key would be linking your binaries into both the cross STAGING_BINDIR and native one Oct 21 21:22:26 and then adding the PROVIDES Oct 21 21:22:44 but it could cause problems in the dependency graph, pulling cross into native deps, if a native recipe depends on your cross thing.. Oct 21 21:22:46 * kergoth shrugs Oct 21 21:47:34 the issue is that -cross gets built for each target so the second one will want to overwrite the native binaries Oct 21 21:47:51 good point Oct 21 21:59:03 RP: can you clarify what you mean by "target"? Do you mean that -cross is built once with target=host and once with target=target? Oct 21 21:59:28 no, he means multiple machines. cross is bound to target Oct 21 21:59:35 Generally: is there a reason PROVIDES_pkg-name-here doesn't work? Oct 21 21:59:42 if they both write to a common native area, there would be problems Oct 21 22:01:41 kergoth: In that case there will be issues anyway due the the binary name not containing the target triple Oct 21 22:01:58 no, the cross bindir already captures that information, afaik Oct 21 22:02:09 cross bindir != native bindir Oct 21 22:03:57 So then the .bb files that use a package need to somehow indicate whether they need to run the -native or -cross version? Oct 21 22:04:08 Does DEPENDS magically handle that? Oct 21 22:04:21 What about when a package needs both -cross and -native? Oct 21 22:04:37 no, the point is if you build cross, then it's bound to the machine/target'. if it writes binaries into the shared native area instead of just cross, it'll conflict with other builds of the cross for a different machine Oct 21 22:04:51 so if you provide both from one recipe, it'll conflict with other builds of itself for other machines Oct 21 22:04:53 thats what RP pointed out Oct 21 22:05:09 in other words, don't provide native from a cross recipe :) Oct 21 22:05:10 kergoth: but it isn't really -native Oct 21 22:05:19 I'm not using the -native bbclass Oct 21 22:05:22 it doesn't matter, if it writes to the native area of the sysroot, it'll step on other builds of itself Oct 21 22:05:45 if it doesn't, then it's not really a native, so shouldn't PROVIDES it Oct 21 22:06:35 And not all -cross packages will put things in the native sysroot? Oct 21 22:07:12 they put their binaries in the cross bindir, which is different than native Oct 21 22:07:42 i don't know about the bits other than binaries offhand, but cross is bound to the target, building a cross recipe for multiple machines is entirely safe and doesn't conflict Oct 21 22:08:12 So -cross won't overrite things then Oct 21 22:08:17 ? Oct 21 22:09:10 i dont know that native recipes would include the cross bindir in their PATH, since they're independent of target, so if you don't write binaries into the native area, then it won't be usable by native recipes Oct 21 22:09:16 and if you do, then you conflict hte way RP pointed out Oct 21 22:10:07 Ah, that makes a bit more sense. Oct 21 22:11:09 And if the sysroots are seperate-ish I won't have native vs cross conflicts if I just have both installed Oct 21 22:11:30 yeah, would think so Oct 21 22:11:34 if not i'd call that a bug Oct 21 22:11:43 great, thanks Oct 21 22:11:50 so, your build time will be slightly higher than is ideal, but at least things shouldnt explode :) Oct 21 22:11:53 could always revisit trying to optimize int he future Oct 21 22:11:58 :) Oct 21 22:12:28 i expect it'd be nice to have something to ahndle this sort of thing for clang/llvm, since it can have multiple targets Oct 21 22:12:30 in a single build Oct 21 22:12:34 * kergoth shrugs Oct 21 22:12:45 kergoth: yep, this is for rust (which uses llvm) Oct 21 22:13:13 i expect getting it to be shared between different *targets* would be easier than trying to use one recip efor both native and target, even though it can handle both cases in theory Oct 21 22:13:15 ah! cool Oct 21 22:13:36 i'd suggest opening a yocto bug about this if there isn't one already, as a potential enhancement request for after this release Oct 21 22:14:04 ack Oct 21 22:29:26 <_ccube> mckoan|away, if I rebuild with yocto, I get a new kernel, so this should not be the problem, should it? **** ENDING LOGGING AT Wed Oct 22 03:00:00 2014