**** BEGIN LOGGING AT Thu Dec 08 03:00:02 2016 Dec 08 07:09:02 khem: iirc it is part of regular qt Dec 08 07:09:27 khem: I'm sure we used to have one, but it has been a few years since I used qmake on the target Dec 08 08:47:01 morning Dec 08 09:33:22 bluelightning: ping Dec 08 09:33:42 hi Jin^eLD Dec 08 09:34:01 hey :) Dec 08 09:34:15 I have another question about sstate and the deploy/images directory Dec 08 09:35:19 Jin^eLD: sure, I'll try to answer - what's the question? Dec 08 09:35:33 I have a chain of recipes, a rescue initramfs, a rootfs (inherits image), kernel, u-boot, all that go to deploy/images directory, and then another recipe that sits on top of all that which packs it together to one partitioned flashable image Dec 08 09:36:15 now, those artefacts seem to work fine because they use default mechanisms, i.e. inherit kernel, inherit core-image, etc, I mean fine in terms of sstate control Dec 08 09:36:38 but my "overall" image is created on each new build no matter if things have changed or not Dec 08 09:36:49 I tried fiddling around with directories and sstate settings as described in the manual Dec 08 09:37:03 but I think I am missing something, probably something in understanding the process Dec 08 09:37:37 are the images first written to workdir and then copied to deploy? or are they generated right in deploy? I tried following the image.bbclass but it was still not clear to me Dec 08 09:37:55 the former Dec 08 09:38:14 but that in and of itself won't have any bearing on whether your task executes every time or not Dec 08 09:38:53 ultimately if your task is re-executing (assuming it's not marked nostamp) it's because one of the inputs is changing Dec 08 09:38:59 well I thought it would be related to mytask[sstate-xxdirs] = ... Dec 08 09:39:00 ? Dec 08 09:39:25 I don't believe that will have any effect on this Dec 08 09:39:39 well, you are for sure right,because it did not get me anywhere :) Dec 08 09:40:07 so I guess my simplified question is: how do I put my own image task under sstate control correctly? Dec 08 09:40:29 that's not the issue here though - the issue is it re-executing Dec 08 09:40:52 I thought re-executing happens because my custom task is not under sstate control? Dec 08 09:41:00 or is that a wrong assumption? Dec 08 09:41:10 I don't think that's a factor Dec 08 09:41:14 oh Dec 08 09:42:08 what goes into the signature for a task is the task function itself, the list of dependencies (tasks and variables) and the signatures of all of the dependencies Dec 08 09:42:26 one way to figure this out would be to compare sigdata files (as found under tmp/stamps) from two runs using bitbake-diffsigs and it will tell you what's different Dec 08 09:42:49 ok, so I was thinking in a completely wrong direction.. Dec 08 09:42:56 the sigdata files for your task, that is Dec 08 09:44:04 yeah, to avoid any confusion, a task can be stamped as being done (and thus not re-run next time) regardless of whether it's an sstate task or not Dec 08 09:44:20 an example is do_fetch - that's not an sstate task Dec 08 09:45:53 ok let me try to figure out what changes... Dec 08 10:26:23 bluelightning: uhm... the sstate hashes that I found in sstate-cache are the same between two runs, diffsig shows empty, but still the image is being generated Dec 08 10:26:40 is it possible that my custom task is ignored? Dec 08 10:27:11 I do see that the task is being run when I bitbake Dec 08 10:27:20 Jin^eLD: in stamps/ I said above, although it shouldn't make a difference Dec 08 10:27:57 unfortunately I have to get some sleep now, but hopefully someone else can walk you through this Dec 08 10:28:13 ok, thank you Dec 08 11:46:11 khem: hi! any progress on updating the systemd recipe? Dec 08 18:21:47 khem: is now a reasonable time to add a note to meta-musl in the layer index saying for the current release it's obsoleted by the musl support in OE-Core? is that now accurate? Dec 08 20:19:26 bluelightning: do you have some time to help me out with this "task runs each time" thing? my diffsig returned empty and actually, the hash of those sig files does not change either Dec 08 20:20:21 Jin^eLD: is a stamp being written for that task when it completes? Dec 08 20:21:07 I don't think so, probably this is the problem Dec 08 20:21:43 I see only two files, 1.0-r1.do_dssimg.sigdata.fcf1a9eda33f797c314067326b7eeadc and 1.0-r1.do_dssimg_setscene.fcf1a9eda33f797c314067326b7eeadc.dss11e Dec 08 20:22:01 and nothing that would have the name of the task in question in the filename Dec 08 20:22:09 oh no Dec 08 20:22:14 crap I am blind Dec 08 20:22:18 do_dssimg is actually the task :P Dec 08 20:22:29 so the answer then is yes.. Dec 08 20:22:34 which makes it even more odd Dec 08 20:23:18 hmm, then I can't explain it I'm afraid :( Dec 08 20:23:30 do you have any ideas on how I could debu git? Dec 08 20:23:36 *debug it Dec 08 20:23:47 you could try bitbake -DDD and see if that prints anything about the task Dec 08 20:24:17 is that the only task that's executing each time? you can pipe the output through cat or look at the cooker log to verify Dec 08 20:24:57 uhm actually no, I see some others too, but those others would be dependencies of the rootfs, but the rootfs is not being rebuilt which is OK Dec 08 20:26:01 every time? Dec 08 20:26:11 yes Dec 08 20:26:37 so why are those executing every time? it sounds to me like that would be part of the issue Dec 08 20:27:13 hmmm, ok let me try to figure that out then, I did not pay attention to them because they are dependencies of the rootfs and since the rootfs was not rerun/rebuilt I thought they would not matter Dec 08 20:27:42 if those are in your task's dependency tree, and it seems to me that they must be, then it would explain it I think Dec 08 20:27:54 perhaps those other tasks are marked nostamp? Dec 08 20:30:00 checking.. they come from a custom class so everythings possible :) Dec 08 20:30:39 no, its not marked as nostamp Dec 08 20:33:22 well, the weird thing is... those "other" tasks have the same behaviour... they get rerun, but the hashes are the same and diffsig between two builds shows empty Dec 08 20:35:54 Jin^eLD: exactly how are you determining the task is being run? Dec 08 20:36:58 kergoth: for once it prints a warning... and the image tasks is not only shown as "running do_dssimg" during bitbaking, but it also spits out a new image each time its being run... Dec 08 20:37:56 that's how it got my attention in the first place, back in the day when deploy/images was not under sstate control it always generated a new rootfs and my class combined them to a new image Dec 08 20:38:23 but now that the rootfs is only built when something changes, but my "combiner" class still spits out images each time I run bitbake - I noticed... Dec 08 20:43:56 my understanding was, that if the hash stays the same, its not supposed to be run? Dec 08 20:49:24 do you depend on a task that's marked nostamp? Dec 08 20:49:29 that's the only thing that comes to mind Dec 08 20:50:47 is there an easy way to check that? Dec 08 20:51:06 otherwise I'll try to grep through my classes Dec 08 20:52:01 honestly not sure Dec 08 20:52:29 not sure how nostamp is implemented re the checksums Dec 08 20:53:54 ok I'll try to grep through then and see if I can follow the deps Dec 08 21:13:38 kergoth: that was easier than I thought, grpe -r nostamp in my layer did not return any hits Dec 08 21:13:52 of course can't tell if there are some OE nostamp tasks that I do depend upon... Dec 08 21:19:48 that was my thought. grep oe-core/meta/classes? Dec 08 21:19:51 * kergoth shrugs Dec 08 21:21:42 uuh.. so you are suspecting something really deep Dec 08 21:21:54 but then.... why does the rootfs is correctly not being regenerated? Dec 08 21:22:17 since it contains all packgaes, it must have this dependency too, but it does not seem to be bothered by it? Dec 08 21:23:11 and actually now that I grepped poky/oe layers, there aren't that many nostamps there at all Dec 08 21:23:39 none of them rings a bell, I am pretty sure I am not explicitly depending on those tasks anywhere Dec 08 21:23:45 no, i'm sure the image is fine, i was thinking you were depending on an image task that was nostamp, i.e. do_image_complete or something, but it didn't run any of the actual tasks doing the work Dec 08 21:24:00 but just a guess, there aren't a lot of things that would cause a task to be re-run when the checksum doesnt' change Dec 08 21:24:09 taint, nostamp on it or its deps, etc Dec 08 21:24:29 Is there a straightforward way to make a SD card image from MLO,u-boot.img,uImage,rootfs.tar.gz without root permissions? Dec 08 21:24:45 ok wait hmm, I do depend on do_image_complete for the rootfs image, but the rootfs image is not causing me the problems; the "overall" image that uses the rootfs image, kernel and u-boot doe snot depend on do_image_complete Dec 08 21:25:43 oh hmm, I think I remember something Dec 08 21:25:49 it might be rm_work's fault Dec 08 21:26:05 yes, crap, now it comes to my mind Dec 08 21:26:29 I had something similar and somehow it turned out rm_work was wiping out stamps of custom tasks Dec 08 21:26:50 I did not think about it at all when I was looking at my image problem now Dec 08 21:26:52 ah, that'd explain it Dec 08 21:26:53 but it's pretty sure it Dec 08 21:27:00 * kergoth usually doesn't use rm_work, just wipes tmp on a regular basis Dec 08 21:27:07 doh... and afaik there is no workaround... Dec 08 21:56:16 I figured out how to work around it Dec 08 21:56:24 inherit deploy.bbclass and rename my task to do_deploy Dec 08 21:56:34 seems to work for this use case Dec 08 21:57:02 rm_work has some exceptions built in for tasks that it knows, so it won't wipe them Dec 08 22:34:46 night Dec 08 23:58:30 jstashluk: WIC may be helpful to do that Dec 09 00:37:11 bluelightning: yes, I think meta-musl is obsolete Dec 09 00:37:19 Should I add that to README Dec 09 00:37:25 will that reflect ? Dec 09 00:37:53 you could do that - it won't automatically in the index though no, but I can easily add a note Dec 09 00:38:04 yeah thats fine Dec 09 00:38:22 just mention that after 2.0 its obsolete Dec 09 00:41:26 I thought it wasn't until 2.1 (krogoth) that we got everything in .. ? Dec 09 00:41:47 I've now set the note: http://layers.openembedded.org/layerindex/branch/master/layer/meta-musl/ Dec 09 01:00:39 bluelightning: thats true yes 2.1 will be more conservative **** ENDING LOGGING AT Fri Dec 09 03:00:01 2016