**** BEGIN LOGGING AT Wed Dec 07 03:00:00 2016 Dec 07 08:32:18 How do I set PREFERRED_VERSION for all things readline? bitbake -s shows readline, readline-native and nativesdk-readline. Must I set all three? Dec 07 09:12:27 No, but I must clean the recipes the previously preferred readline 6.2 :) Dec 07 11:11:52 I am actually really surprised there is no actively maintained qwt library recipe for qt5 in OE Dec 07 11:12:22 as I got the impression that qwt is very popular among OEMs doing measurement instruments Dec 07 11:36:11 no they all do react on chromium nowadays :> Dec 07 12:40:54 rburton: just noticed your remark on multilib.. we've been testing multilib on arm32/64 lately, and python3 doesn't seem to work fine. is that the same on x86 multilib? i can't find my pastebin with the trace, but basically python3 segfaults.. (so does gdb). Dec 07 12:51:48 ndec: not sure i've tried Dec 07 12:53:56 rburton: ah, found the trace https://bugs.linaro.org/show_bug.cgi?id=2666.. if you could try on x86 multilib, that would be nice.. Dec 07 13:02:39 quite, isn't that really overkill? Dec 07 13:03:14 I mean, what if you want to use a chip that does not have a GPU and OpenGL? Dec 07 13:03:49 qwt is still usable with framebuffer on such platforms, no? Dec 07 19:06:23 anyone looked at this: http://lists.openembedded.org/pipermail/openembedded-core/2016-December/129514.html Dec 07 19:20:37 marked for merging :) Dec 07 19:29:37 when a directory is under sstate control (talking about deploy/images), is there a way to know, say from some class or hook, what new files where put there so that I could copy these files to some other location? Dec 07 19:30:49 rburton, thanks Dec 07 19:30:54 mru can be cranky Dec 07 19:31:05 but not in -next yet? Dec 07 19:39:43 no Dec 07 19:56:02 any hints anyone? :) Dec 07 20:09:02 Jin^eLD: i'd examine the sstate manifest files Dec 07 20:09:16 they list what was written, though not what's new. i'd just use rsync to handle that part Dec 07 20:10:44 kergoth: I was looking for something within OE to avoid external scripts Dec 07 20:10:56 i don't understand the question Dec 07 20:11:04 if you're copying the files, then you're using cp, which is an external binary Dec 07 20:11:09 you can just as easily use rsync instead Dec 07 20:11:25 ok wait, rsync as from within a OE task or "after the build"? Dec 07 20:11:36 I thought you meant the latter Dec 07 20:12:25 but indeed hmm, it might be the easiest solution to create a .bbclass that runs at the very end and that just rsyncs the deploy dir to wherever the copy should be Dec 07 20:13:01 thank you :) not sure why I started to look into complicated solutions first... Dec 07 20:13:48 indeed, you could even build rsync-native if you don't want to depend on the host Dec 07 20:13:49 np Dec 07 20:14:16 <3 rsync :) Dec 07 20:15:16 was thinking exactly the same :) Dec 07 20:22:43 only time rsync sucks is if you're trying to rsync 3 terabytes of tiny files (i did that once.. ) Dec 07 20:23:26 heh :) I don't think I even have the space that would be large enough to hold that :) Dec 07 20:24:19 what would you suggest for a hook to make sure this rsync task is really the "last" in the chain? with [prefuncs] += I'd have to take care of order Dec 07 20:24:32 is it possible to addtask after do_image_complete? Dec 07 20:24:44 or does anything come even later? Dec 07 20:25:11 use a global inherit to addtask before do_build or before do_${BB_DEFAULT_TASK} Dec 07 20:25:22 when you 'bitbake foo' it's really building foo:do_build Dec 07 20:25:31 its the default task when one isn't specified Dec 07 20:25:43 but, a bitbake -c foo bar wouldn't trigger it Dec 07 20:25:50 a better bet might be to use a BuildCompleted event handler Dec 07 20:26:37 hmm Dec 07 20:27:15 btw, lets say I build rootfs images and device images (latter contains the rootfs image + u-boot + kernel, partitioned) Dec 07 20:27:47 if I inherit my class for the rootfs image and for the device image, it will run twice, but there's no way to define the task as, well, "build singleton"? Dec 07 20:28:26 if you addtask it before do_build, it'll only run once for each specified target, not for dependencies Dec 07 20:28:34 i.e. if 'bitbake foo' builds bar and baz, kit'll only run that task for foo Dec 07 20:28:41 but if you 'bitbake foo bar' then it'd run twice Dec 07 20:28:49 but an event handler would bypass that issue Dec 07 20:30:41 ok, so the event handler is global, no matter in how much recipes I inherit my class, the event handler will be run only once? Dec 07 20:31:26 your build only completes once per bitbake command, so yes Dec 07 20:32:06 I think this is exactly what I was looking for, thank you! Dec 07 20:33:20 np Dec 07 20:33:54 the event handlers have to be python, not shell? Dec 07 20:34:33 yep, but worst case you could just bb.build.exec_func('your_shell_function', d) in your event handler Dec 07 20:34:39 your call Dec 07 20:34:49 oh right, I did not think about that possibility Dec 07 20:55:09 grml that should be enough, no? Dec 07 20:55:10 addhandler rsync_build_complete_eventhandler Dec 07 20:55:10 rsync_build_complete_eventhandler[eventmask] = "bb.event.BuildCompleted" Dec 07 20:55:37 somehow its not being run, I must be missing something Dec 07 20:59:11 hmm, it is however if I remove the eventmask, I thought the mask is to make sure it only gets triggered on the event I want? Dec 07 20:59:36 if you don't specify event mask, it'll run for every event in the systems Dec 07 20:59:42 *thousands* of events across all recipes Dec 07 20:59:45 not what you want Dec 07 21:00:17 I wonder what I did wrong then Dec 07 21:00:59 first, add a bb.warn() so you really know if it's being run Dec 07 21:01:03 I should probably drop the isinstance check Dec 07 21:01:09 note that this runs on successful build, not failed Dec 07 21:01:13 yes, that's not needed with eventmask Dec 07 21:01:24 so if you're interrupting your build, it won't run Dec 07 21:01:26 yeah that's where I am not, with bbwarns, I think I messed up the isinstance Dec 07 21:01:51 s/not/now/ Dec 07 21:02:23 we should probably deprecate event handlers without eventmask at some point here Dec 07 21:02:39 not exactly performant to run handlers that then check if the event is the right one themselves, for thousands of events Dec 07 21:02:48 I guess they indeed make limited sense Dec 07 21:04:18 but thats indeed weird, I kicked out isinstance, added back the eventmask, but now the task is not run at all, just as I had it before removing the eventmask during the very first tyiout Dec 07 21:04:23 *tryout Dec 07 21:04:30 don't see my bbwarns either Dec 07 21:06:24 and well, I wonder... what if my isinstance was not messed? I start to get the feeling that I *never* receive the BuildCompleted event... Dec 07 21:08:31 tried chaning it to bb.event.BuildStarted - same, nothing Dec 07 21:16:36 ok I tropped the eventmask and I am printing all event names, I get only RecipePreFinalise and RecipeParsed events, no others... Dec 07 21:16:39 *dropped Dec 07 21:16:54 where are all the others?? Dec 07 21:17:43 are you only running bitbake -p or something? Dec 07 21:17:49 no... Dec 07 21:18:03 just "bitbake recipename" Dec 07 21:18:17 tried -c cleanall on that recipe too and rerun, but that had no effect Dec 07 21:18:45 I don't see anything special in the docs, was looking at 3.8 of the bitbake manual and my class looks the same... Dec 07 21:18:45 i'm fresh out of ideas, that doesn't make much sense Dec 07 21:19:12 does it workfor you? Dec 07 21:20:09 its basically a paste from the manual.. Dec 07 21:20:11 https://pastebin.mozilla.org/8950363 Dec 07 21:20:34 I put it in a class and I inherited it ina couple of packages, including the one that I am bitbaking Dec 07 21:22:45 that's wrong Dec 07 21:22:54 these events are global, config level Dec 07 21:23:02 trying to run them for a single recipe isn't going to do a whole lot Dec 07 21:23:05 add your class to INHERIT Dec 07 21:23:58 oh hmm.. my goal was to run the function only if one of those particular recipes gets bitbaked, i.e. add the handler only then.. Dec 07 21:24:08 so I got it all wrong again Dec 07 21:24:42 if you want that, a task is the only way to go Dec 07 21:24:49 or you can use the event handler but have the ahndler check PN Dec 07 21:25:05 that won't really perform? Dec 07 21:25:57 yeah, checking PN wouldn't work anyway, it runs in a context where it has no meaning Dec 07 21:26:02 buildcopmleted doesnt' know what you buit Dec 07 21:26:04 built Dec 07 21:26:33 ok let me try the task appraoch then.. Dec 07 21:27:59 honestly if i were you i'd just script it above the bitbake level, but it depends on the use case Dec 07 21:28:30 well, I kind of wanted to avoid rsyncing if none of the images was built... Dec 07 21:29:07 add a class to IMAGE_CLASSES which adds a task between do_image_complete and do_build, or a postfunc on do_image_complete Dec 07 21:29:10 would be my suggestion Dec 07 21:30:07 I have a bunch of functions that already do hook in as postfuncs on do_image_complete, but since those postfuncs are executed in the order how they were added, i did not want the rsync task depend on that Dec 07 21:30:17 because the other hooks actually also deploy some files that should be rsynced Dec 07 21:30:18 * kergoth nods Dec 07 21:30:41 that's why I was looking for the "after the recipe has *really* been built", something last in the chain.. Dec 07 21:31:02 but between complete and build should do that Dec 07 21:31:06 let me try... Dec 07 21:33:30 mhhh that runs way too often now Dec 07 21:34:26 I guess out of all suggested options I'll probably have to stick with the handler... it will run when not needed, but at least it will run only once per build... Dec 07 21:35:21 btw I did not really undestand what you said about do_${BB_DEFAULT_TASK} Dec 07 21:35:26 I looked it up in the manual Dec 07 21:35:32 that's what bitbake runs when you dont' specify a task Dec 07 21:35:32 but it was still not clear to me what your idea was Dec 07 21:35:43 BB_DEFAULT_TASK defaults to 'build' Dec 07 21:35:52 it's just do_build, but a more correct way to specify it Dec 07 21:36:06 wouldn't I be overriding do_build then? Dec 07 21:36:12 i don't understand the qeustion Dec 07 21:36:24 addtask before do_${BB_DEFAULT_TASK} and addtask before do_build are exactly the same in the end Dec 07 21:36:36 ooh, ok Dec 07 21:36:36 just one obeys a variable and one doesn't Dec 07 21:36:42 now I got you Dec 07 21:36:50 I was thinking something totally different Dec 07 21:37:04 I thought I Was supposed to override do_build by specifying my own BB_DEFAULT_TASK or something Dec 07 21:37:12 could prefunc/postfunc do_build too, as another option Dec 07 21:37:56 hmm, that would decopuple me from the image_complete postfuncs Dec 07 21:38:00 which is good Dec 07 21:38:03 let me try... Dec 07 21:43:25 hmm that does not seem to work, can't hook into the build postfuncs for whatever reason Dec 07 21:43:39 it does not get executed Dec 07 21:44:13 hmm, odd Dec 07 21:45:53 well, so seems I have to just INHERIT the class in site.conf and use handlers? Dec 07 21:46:14 not ideal, since it will rsync even if not needed, but all other options seemed to be worse so far Dec 07 21:48:11 hmmm, but actally I can try one more thing; hook all my image processing functions into do_image_complete[prefuncs] and hook the rsync function to do_image_complete[postfuncs] Dec 07 21:59:51 mhm, does not work quite as expected, I guess the handler is indeed the best option out of all for this Dec 07 21:59:59 thanks for the help and for your patience :) Dec 07 22:00:09 I'll go grab some food now, l8r Dec 07 22:00:45 np, good luck Dec 08 00:37:31 some people need to be different: git://github.com/mem/oe-meta-go Dec 08 01:37:50 Crofton: I am trying to unify all golang under oe-core Dec 08 01:37:56 there are so many variants Dec 08 01:38:02 out there its confusing Dec 08 01:38:18 I need to build meta-mender Dec 08 01:38:22 and it calls for that one Dec 08 01:38:31 and khem++ Dec 08 01:39:31 Crofton: I have sent out patches Dec 08 01:39:41 try to implant them on oe-core Dec 08 01:39:47 and punt other go layers Dec 08 01:39:52 see if meta-mender can build Dec 08 01:40:33 might prove with their docs, then test yours :) Dec 08 01:40:51 fischerm, demands results :) Dec 08 01:41:17 what is status of patches? Might point the mender guy sat them Dec 08 01:43:06 http://lists.openembedded.org/pipermail/openembedded-core/2016-November/128608.html Dec 08 01:44:43 heh, mender guy already replied Dec 08 01:46:16 Crofton: btw thanks for the link to the ELC videos - I watched Matt's talk on upgrade mechanisms, Koen's distro talk, and the one on ELBE Dec 08 01:46:29 Crofton: any others you'd recommend? Dec 08 01:47:14 oh and the "living in 2009" one as well Dec 08 01:58:16 do we have recipes for qmake on target ? Dec 08 01:58:17 shoragan's? Dec 08 01:58:29 there is one from bmw about their OE installation Dec 08 01:59:48 Continuous Integration and Testing of a Yocto Project Based Automotive Head Unit Dec 08 02:00:06 Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years Dec 08 02:01:25 http://elinux.org/ELC_Europe_2016_Presentations Dec 08 02:02:14 ah yes that's much easier than clicking around the playlist, thanks **** ENDING LOGGING AT Thu Dec 08 03:00:01 2016