**** BEGIN LOGGING AT Thu Nov 24 03:00:00 2016 Nov 24 13:27:59 I am still migrating to poky 2.2 and I have one question related to putting the images dir under sstate control... I have some classes that do postprocessing on the images, there I need to know the name of the generated image Nov 24 13:28:04 until now it was working with "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.${UPDATE_ROOTFS_TYPE}" Nov 24 13:28:23 although I guess I describe the problem the wrong way around Nov 24 13:28:40 how can I make sure that my postprocessing task is not always run? Nov 24 13:28:53 right now I have the situation that if there is nothing new in the image, the image will not be regenerated Nov 24 13:28:58 but my task runs always Nov 24 13:29:34 you know you can use the old compression support to chain arbitrary prostprocessing if its still like "generate a md5" or similar Nov 24 13:29:40 and since the image has DATETIME in its name, it does not work anymore, i.e. the image is not regenerated and has the old timestamp in the name, and my postprocessing task gets a new timestamp so it does not know the image name anymore Nov 24 13:30:03 rburton: hmm no, did not know that :) where do I look? Nov 24 13:30:26 we are doing several things, dd'in the filesystem images to full flash images with uboot and so on, gpg signing them, stuff like that Nov 24 13:38:55 image.bbclass: rename COMPRESS(ION) to CONVERSION Nov 24 13:39:20 and a load of commits earlier to improve it Nov 24 13:39:50 oh, conversion_cmd Nov 24 13:41:12 hmm, so I should drop the classes and define "commands" Nov 24 13:41:14 I'll try Nov 24 13:41:37 to be honest I liked the classes more, seemed cleaner to just to inherit them Nov 24 13:41:54 but if that's problematic now, let me try if I can get along withthe conversion thing,thank you Nov 24 15:37:47 how would one add a linux-firmware package to an image based on machine Nov 24 15:38:19 or append a machine configuration from a seperate layer Nov 24 15:39:10 jackmitch_work: if you have a "meta" recipe for the image (i.e. some packagegroup recipe) you could RDEPENDS_${PN}_append_YOURMACHINE = stuf, at least thats how I do it Nov 24 15:39:36 you might as well IMAGE_INSTALL_append_YOURMACHINE = Nov 24 15:39:54 Jin^eLD: hmm, I didn't try with _append but += didn't work, I'll give it a go Nov 24 15:40:20 append gives you more control in the sense of machine/architecture etc separation Nov 24 16:19:01 rburton: getting back to my original question, is it possible to still use the classes but just let OE remember if nothing has changed, so that my custom tasks are not run? because I Do not really need to rerun them if none of the images changed...? Nov 24 16:19:44 how did the classes work? did they addtask? Nov 24 16:20:02 yes Nov 24 16:20:03 via addtask Nov 24 16:20:16 addtask foo after do_rootfs before do_build? Nov 24 16:20:30 do_updateinfo[depends] += "${PN}:do_image_complete" Nov 24 16:20:30 addtask updateinfo before do_build Nov 24 16:20:49 try doing after do_image_complete instead of that depends thing Nov 24 16:21:01 oh..ok Nov 24 16:21:19 I never quite grasped the difference between those two Nov 24 16:21:37 especially since I thought after "complete" would be also after do_build? Nov 24 16:23:29 in general just use before and after to control task dependencies Nov 24 16:23:43 do_build is the default target, so if you do bitbake foo, it's actually running foo:do_build Nov 24 16:24:12 oooh, ok, thats what I was missing, so do_build is always the last Nov 24 16:24:28 anything after do_build you'll have to fire explicitly Nov 24 16:41:09 rburton: unfortunately changing the task dependeny to "after" did not help, the task is still being rerun although the image does not change Nov 24 16:41:30 bluelightning might now something about that, I think he put the images dir under sstate but I have not seen him around lately Nov 24 16:42:13 hes in new zealand so remember timezones Nov 24 16:42:29 ok so if the image hasn't changed, why does the task want to rerun? Nov 24 16:43:05 how do I find out? Nov 24 16:43:43 bitbake-diffsigs, bitbake -S, etc can help Nov 24 16:44:04 oh yes, the sigs, right Nov 24 16:44:29 or if the task is only little, carefully read it Nov 24 16:45:20 well, I am using do_updateinfo[vardepsexclude] += "DATETIME" Nov 24 16:45:26 because DATETIME is used in that task Nov 24 16:45:32 so thats probably the reason then? Nov 24 16:45:54 yeah, but if its being excluded then that should work Nov 24 16:47:43 ok wait, I lost it here :) Nov 24 16:48:07 so, you mean it will indeed always be executed because of DATETIME and I can't work around it? Nov 24 16:49:12 or what did you mean by "that should work"? the not executing? Nov 24 16:50:42 yeah that should work to stop it executing every time Nov 24 16:50:57 but maybe the value is ending up in another variable that it also sees changing? Nov 24 16:51:48 well, it is using a variable called ${IMAGE_NAME} which afaik also contains DATETIME Nov 24 16:51:58 but I would imagine that it gets vardepsexcluded elsewhere Nov 24 16:52:04 otherwise I'd get the hash difference error Nov 24 16:52:15 or do I need to additionally vardepexclude it in my class as well? Nov 24 16:52:29 it *should* be able to follow the usage Nov 24 16:53:01 ok let me try to add the IMAGE_NAME to excludes and see what happens.. Nov 24 16:53:58 that did not help hmm Nov 24 16:58:28 the sstate cache signature of the task does not change though Nov 24 17:01:58 really not sure how to figure this one out, obviously on a subsequent run of bitbake ${IMAGE_NAME} gets re-evaluated since it includes DATETIME, but then the image is not written because it had no changes, but my task is still being run Nov 24 17:02:22 but since the signature hash does not change for the task I am a bit puzzled on what to sigdiff it against... Nov 24 17:40:45 doh.. Nov 24 17:41:03 rburton: subsequent -S tells me "Nothing to do." Nov 24 17:41:09 you could have kept that quiet and nobody would know Nov 24 17:41:11 but running it without -S still causes my taks to run and to fail Nov 24 17:41:17 hm Nov 24 17:41:18 :) Nov 24 17:43:02 when I find/grep for the updateinfo hash its always the same, it does not change 3d2b95aed2da99c2df1f382625c542f4_updateinfo Nov 24 17:43:17 so what am I missing? how do I figure out why the task is being run? Nov 24 18:56:18 hi bluelightning Nov 24 18:57:26 I'm going to annoy you tonight so you may want to pretend being afk or something :) it's about sstate and images ;) Nov 24 19:05:32 hi Jin^eLD Nov 24 19:05:40 oops, too late :D Nov 24 19:05:47 what's up? Nov 24 19:07:39 ;) Nov 24 19:07:54 bluelightning: I have a problem with tasks that run althouth the image has no changes Nov 24 19:08:13 I have some classes that post process the image Nov 24 19:08:25 via addtask Nov 24 19:08:38 I know that IMAGE_NAME contains DATETIME Nov 24 19:09:05 when deploy/images was not under sstate, the image was recreated each time I bitbaked Nov 24 19:09:21 now, it works only for the first time Nov 24 19:09:31 a subsequent run of bitbake will not regenerate the image if there were no changes Nov 24 19:09:38 but will still run my postprocessing task Nov 24 19:09:56 and of course the task can't find the image anymore because the DATETIME does not match the one from the old image Nov 24 19:10:05 I was trying to figure out why the task is being rerun but I failed Nov 24 19:10:18 bitbake -S on the image was showing that there's nothing to do Nov 24 19:10:22 but still the task is executed Nov 24 19:11:41 any ideas how to approach this? or is there an easy way (or even a configuration) to take deploy/images out of sstate and restore the old behaviour? Nov 24 19:13:02 I don't believe there's any easy way to disable it, no Nov 24 19:14:09 bitbake-diffsigs should be able to be used to compare the signatures before and after to find if there are any other differences for your task beyond DATETIME Nov 24 19:14:24 well, there is no after... the signature of my task stays the same, but still its being run Nov 24 19:14:38 its very strange Nov 24 19:14:51 either I am missing something or, well, I'm not sure what to do Nov 24 19:14:54 that is indeed strange, and starts to sound like a bug Nov 24 19:15:14 do you have a simple enough reproducer for this? Nov 24 19:15:15 well, I am pretty sure I messed up somewhere ;) at least in most cases it was like that ;) Nov 24 19:15:53 on my end yes, I am not sure how to set up a "simple" generic reproducer Nov 24 19:16:44 the class does not have any significant dependencies though, all it does is - it checks if the image is in the deploy dir and write a simple update.conf file which contains some data for the firmware updater Nov 24 19:17:33 https://pastebin.mozilla.org/8931240 Nov 24 19:19:52 hmm, you're already setting vardepsexclude as well Nov 24 19:20:16 oh wait Nov 24 19:20:21 I added IMAGENAME but it should be Nov 24 19:20:23 IMAGE_NAME Nov 24 19:20:25 maybe thats the problem Nov 24 19:20:33 possibly, try it... Nov 24 19:28:14 mhm need to fix some other stuff first, so will take a while, image is no longer buildable at the moment due to other reasons ;) but still its weird that bitbake -S printdiff was saying "Nothing to do" Nov 24 19:31:25 yes, it definitely is Nov 24 19:31:59 but I suspect the issue there may not be with -S itself but with the fact that the signature doesn't change Nov 24 19:33:28 I of course was watching the signature of my task hmm Nov 24 19:34:22 maybe something else changed along the lines and caused my task to rerun, oh well... I'll first see if the IMAGE_NAME exclude fixes it, I as always was blind and did not notice the missing underscore Nov 24 19:51:35 bluelightning: ok, got it to build again, so... no, unfortunately adding IMAGE_NAME to vardepsexclude did not help Nov 24 19:54:07 Jin^eLD: hmm, ok Nov 24 19:54:09 Jin^eLD: you're enabling this via INHERIT += I take it? Nov 24 19:54:16 (about to test here) Nov 24 19:54:35 ehm.. no, just "inherit core-image updateinfo" Nov 24 19:54:55 whats the difference between INHERIT += and inherit someclass? Nov 24 19:56:09 inherit is for recipes, whereas INHERIT += is used in .conf files to inherit a class globally Nov 24 19:57:30 I inherit my class in the rootfs image recipe Nov 24 20:05:03 Jin^eLD: right, that's what I've done here Nov 24 20:05:44 Jin^eLD: so at the moment when I try to build the image again it doesn't rerun the task, so I guess I'm not triggering the behaviour you're seeing Nov 24 20:06:20 hmmm Nov 24 20:06:29 (of course when I added the class to be inherited it did fail because the image was already built and do_rootfs didn't rerun, but that's not quite the same issue) Nov 24 20:06:50 right, thats not the same Nov 24 20:06:59 hmm Nov 24 20:07:04 how can I debug this? Nov 24 20:12:15 well, that is strange Nov 24 20:12:23 oh, wait, no it isn't Nov 24 20:13:00 ? :) Nov 24 20:13:01 (I just noticed IMAGE_NAME and IMAGE_BASENAME went missing from the bitbake-dumpsig output between two runs, but then I remembered that I'd made the IMAGENAME -> IMAGE_NAME fix in between times) Nov 24 20:16:22 the hash of my task does not change, but how can I figure out if a hash of some dependent task is changing? Nov 24 20:17:00 if it were it would definitely change the signature of this task - hashes of dependencies are incorporated Nov 24 20:17:41 you can prove that by changing the value of some variable that triggers do_rootfs and then comparing the two do_updateinfo siginfo files Nov 24 20:19:10 but if it doesnt - why is it being rerun then?? Nov 24 20:20:59 that is a very good question Nov 24 20:21:35 you could try to see if bitbake -DDD has anything to say about that task but then bitbake's debug output isn't always particularly useful Nov 24 20:22:20 at face value I would have to say if a task is stamped as having run and the signature hasn't changed it should not be being rerun at all Nov 24 20:22:39 RP: anything I'm forgetting? ^ Nov 24 20:23:30 DEBUG: Stampfile /home/jin/dss-oe/poky-devel-nopkg-build/build/stamps/dss11e-poky-linux-gnueabi/digitalstrom-rootfs/1.0-r0.do_updateinfo.795ef995a5504dccc568bce5321ff90e not available Nov 24 20:24:02 and thats exactly the hash that stayed unchanged Nov 24 20:24:05 Computed task hash is 795ef995a5504dccc568bce5321ff90e Nov 24 20:24:16 is the stamp file for my task is missing Nov 24 20:24:17 but why? Nov 24 20:25:21 there's only a sigdata file there, i.e. 1.0-r0.do_updateinfo.sigdata.795ef995a5504dccc568bce5321ff90e Nov 24 20:27:47 ah, now we are getting somewhere Nov 24 20:28:07 if the stamp file is not there that explains why it would rerun Nov 24 20:28:14 but then why isn't it there? Nov 24 20:28:21 indeed... yes, why? Nov 24 20:28:34 the task definitely succeeded and you haven't cleaned in the mean time? Nov 24 20:29:45 well.... thats interesting Nov 24 20:29:49 there was no ERROR at the first run Nov 24 20:29:51 only a warning Nov 24 20:29:53 WARNING: digitalstrom-rootfs-1.0-r0 do_updateinfo: GPG signature /home/jin/dss-oe/poky-devel-nopkg-build/build/deploy/images/dss11e/digitalstrom-devel-rootfs-dss11e-20161124194553.rootfs.ext3.gpg not found, not adding to configuration. Nov 24 20:29:57 which is OK Nov 24 20:30:03 so that means the task did run Nov 24 20:30:13 but... the file that it was supposed to produce is not there Nov 24 20:30:15 right, I get that too, but the task is stamped and doesn't re-run in my case Nov 24 20:31:04 and you did have the .conf file then in the deploy directory? Nov 24 20:31:08 because thats the odd part, I don't have it Nov 24 20:31:36 I do it seems Nov 24 20:32:01 so maybe somehow it fails here for me without throwing a bitbake error? and is therefore not stamped because it actually failed? Nov 24 20:32:32 that would be some serious breakage - it sounds rather unlikely Nov 24 20:34:13 but I really don't see how the .conf could be missing... Nov 24 20:34:41 let me paste the expanded function from bitbake -e and run it in a shell Nov 24 20:34:49 just for the fun of it Nov 24 20:35:52 running it gives me the expected.conf file Nov 24 20:35:57 so the script as such is not broken Nov 24 20:37:02 ok well, the DATETIME expansion did not match of course Nov 24 20:37:26 and I got the .conf only because the shell did not exit with bbfatal ;) but still it does not look like there were errors in the script Nov 24 20:37:37 and it has been working just fine with the 2.0.2 Nov 24 20:37:53 who is responsible for stamping? can I add some debug output there? Nov 24 20:38:28 I believe the code is in lib/bb/build.py Nov 24 20:52:49 # Remove the file and recreate to force timestamp Nov 24 20:52:49 # change on broken NFS filesystems Nov 24 20:52:53 what is the idea here? Nov 24 20:53:10 its in the make_stamp function Nov 24 20:53:43 but thats probably not my problem, let me add some more debug output Nov 24 20:55:08 you aren't using NFS or another odd filesystem, right? Nov 24 20:55:27 I mean, as TMPDIR Nov 24 20:55:56 nope, no Nov 24 20:56:05 ok, just checking Nov 24 20:56:06 hence my question why it would want to remove and recreate the stamp file in the first place Nov 24 20:56:18 at least I found it suspicious that I entered that if clause Nov 24 20:58:46 make_stamp() is only going to run when it needs to stamp the task as having run, and it immediately creates the stamp file afterwards - so I'm not entirely sure what that bit is about but I can't see it doing any harm Nov 24 21:01:44 so shouild I go out of this function? I thought it would create the stamp file Nov 24 21:02:14 it does Nov 24 21:02:23 hmmmm Nov 24 21:02:25 open(stamp, "w").close() Nov 24 21:02:35 yeah thats supposed to touch it Nov 24 21:02:42 I did print "stamp" Nov 24 21:03:19 but when bitbake exits back to the shell, if I ls -all this "stamp" file - its not there Nov 24 21:03:26 so I guess something or someone else is removing it along the way Nov 24 21:03:31 hmm Nov 24 21:03:53 is bb.parse.siggen.dump_sigtask(file_name, task, stampbase, True) doing something related, should I dive into it our go out of make_stamp and rather continue outside of it? Nov 24 21:04:46 have you tried inserting a few bb.warn('stamp: %s' % os.path.exists(stamp)) in various places? Nov 24 21:05:59 hmm not yet, I was mostly logging output of the vars to trace the flow in make_stamp Nov 24 21:25:08 Jin^eLD: which release is this with? Nov 24 21:25:44 Jin^eLD: you haven't got nostamp tasks somewhere in the dependency change have you? Nov 24 21:26:30 RP: its 2.2, I did grep for nostamp but let me check again, at least I know I did not set nostamp for that task explicitly, that I know for sure Nov 24 21:26:50 Jin^eLD: and you pulled in my stamp fixes from the 2.2 branch? Nov 24 21:27:04 oops Nov 24 21:27:06 maybe not Nov 24 21:27:45 Jin^eLD: they don't sound quite like this but its possible they might help Nov 24 21:28:04 Jin^eLD: they are merged on the main release branch now Nov 24 21:28:53 oh, I should rather switch branches, I thought you merged these fixes to morty Nov 24 21:29:10 Jin^eLD: I did, I mean the morty branch Nov 24 21:30:48 git pull origin morty says I'm up to date Nov 24 21:31:17 my head is at commit 73454473d7c286c41ee697f74052fed03c79f9f5 Nov 24 21:32:29 oh crap Nov 24 21:32:33 actually I am on master now :) Nov 24 21:32:41 I guess I forgot to switch to morty after our last debugging session Nov 24 21:33:03 I was just not on latest master but on the one from last week Nov 24 21:36:36 ok now my build is broken after I pulled from master :) Nov 24 21:36:48 I'll switch back to morty, I understand you merged those fixes Nov 24 21:42:15 ok, os morty head leaves me only with a 1.0-r0.do_updateinfo.sigdata.795ef995a5504dccc568bce5321ff90e which I believe is not the task stamp Nov 24 21:42:56 my grep -r did not find any usage of nostamp in my whole layer Nov 24 21:57:51 RP: so right now... when I exit the _exec_task function in build.py, the stamp does exist, I'll continue to trace the flow, but of course if you have pointers what parts to look at, it would be very helpful Nov 24 21:58:30 Jin^eLD: are you using rm_work? Nov 24 21:58:51 yes, I do Nov 24 21:59:21 Jin^eLD: I'd put debugging in do_rm_work() then Nov 24 21:59:30 Jin^eLD: that does nasty things to stamps Nov 24 21:59:41 ok, let me see Nov 24 22:00:31 oh, rm_work Nov 24 22:00:37 gnargh Nov 24 22:01:26 let me actually do a quick counter check by removing rm_work from my local.conf and rerunning the rootfs image build Nov 24 22:01:33 someone once wrote it as a quick hack Nov 24 22:01:43 I've been trying to make it work ever since :/ Nov 24 22:01:53 rm_work really ought to bbdebug something out when it's removing stuff Nov 24 22:02:17 bluelightning: it removes some things, move or adds others, its quite nasty Nov 24 22:02:49 maybe like Crofton's famed zaurus buyback program we can send hard drives to people who enable it? ;D Nov 24 22:03:30 1.0-r0.do_updateinfo.67c2e5c8a2c734d5dd1209a5123074e5 Nov 24 22:03:32 thats my stamp Nov 24 22:03:33 without rm_work Nov 24 22:04:35 Jin^eLD: I'm guessing you added a stamp which rm_work doesn't understand and its therefore deleting it :/ Nov 24 22:04:45 and now building again does nothing as it should, it does not attemp to rerun my task.. Nov 24 22:05:00 RP: is the "understanding" hardcoded? Nov 24 22:05:01 I'm guessing you added a *task* Nov 24 22:05:05 yes Nov 24 22:05:06 :) Nov 24 22:05:09 exactly what I did Nov 24 22:05:47 addtask updateinfo after do_image_complete before do_build Nov 24 22:06:11 and I have a couple more of those, just deactivated the others for now because the problem was already reproducible just with one of them Nov 24 22:06:28 of course it worked fine as long as deploydir/images was not under sstate control Nov 24 22:06:47 then it was just always rebuilt and I never noticed the error that I am running into now Nov 24 22:07:47 so... what would you suggest? Nov 24 22:08:11 Jin^eLD: well, I'm mainly trying to help you find the source of your issue Nov 24 22:08:32 Jin^eLD: how to fix rm_work? Not sure Nov 24 22:08:57 RP: in that you did succeed :) we found it ;) Nov 24 22:09:29 bluelightning: why did you want to put the images dir under sstate control in the first place? ;) Nov 24 22:09:50 Jin^eLD: we put them under sstate control so we had a manifest of what was written out Nov 24 22:09:51 * Jin^eLD should be really more careful in following the mailing lists Nov 24 22:10:06 which is useful for UIs and other things that care about knowing what we build Nov 24 22:10:35 RP: well, this kind of "killed" my incremental build scenario where the deploy dir is exposed on a webserver and has all images for the release history Nov 24 22:11:01 Jin^eLD: It was discussed on the mailing list, the arch list and nobody objected Nov 24 22:11:03 I'll have to copy them to some other dir in order to maintain the old behaviour, but thats a different topic anyway Nov 24 22:11:16 RP: yes, bluelightning told me, I missed that completely Nov 24 22:11:32 that's what I meant by "/me should follow the lists more carefully" ;) Nov 24 22:12:01 but from what I can tell, right now the implication is that custom tasks for images are broken when rm_work is enabled... Nov 24 22:12:21 I'll see if I can patch rm_work somehow Nov 24 22:12:26 but not sure otherwise Nov 24 22:12:39 Jin^eLD: it depends what this task is doing and what behaviour you're expecting Nov 24 22:13:00 I have a number of tasks that do various things on built images Nov 24 22:13:13 Jin^eLD: adding your recipe to RM_WORK_EXCLUDE would be a simple solution Nov 24 22:13:24 some just do something on one image, others combine built images into yet another "full" image Nov 24 22:14:08 this particular class that I now have troubles with creates a simple text file for the firmware updater, i.e. file containing image description, build timestamp, nothing special Nov 24 22:14:35 RP: is there a mechanism to exclude tasks? Nov 24 22:14:42 Jin^eLD: and the issue is that it runs every build? Nov 24 22:15:09 RP: the issue is that its now not in sync with the image recipe, i.e. when both run its OK, because the image name contains DATETIME Nov 24 22:15:25 but if only one of them runs, i.e. the task runs but the image does not, then the task won't find the image Nov 24 22:15:34 because the task will use a newer DATETIME, but the image stays the same Nov 24 22:15:45 so that's the actual error that I ran into Nov 24 22:15:46 Perhaps it should be using the link rather than the version with DATETIME in it? Nov 24 22:16:22 we kind of wanted to avoid the case "what if the link does not show where it should" Nov 24 22:16:40 i.e. ensure it really processes what was built right now along with it Nov 24 22:16:46 and to that extent this check was successfull :) Nov 24 22:17:11 imho the "clean" solution now would be, not to run the task if the image has not changed Nov 24 22:17:14 Jin^eLD: surely you want to add before do_image_complete and put your output under sstate control like the other image tasks then? Nov 24 22:17:24 right Nov 24 22:17:33 imho that would be a clean solution Nov 24 22:17:39 but rm_work nuked me :) Nov 24 22:17:58 Jin^eLD: if you follow the way the other do_image_* tasks work, you'll be fine Nov 24 22:18:34 i.e. do_image_complete[sstate-inputdirs] = "${IMGDEPLOYDIR}" Nov 24 22:18:37 and things like that? Nov 24 22:19:12 or what part should I be following? I'm a bit lost Nov 24 22:19:45 does rm_work process SSTATETASKS += "do_image_complete" Nov 24 22:19:59 oh yeah Nov 24 22:20:04 I think I now know what you were referring to :) Nov 24 22:20:09 let me try that Nov 24 22:21:03 Jin^eLD: put your output into IMGDEPLOYDIR before do_image_complete Nov 24 22:21:31 before? but I need the image to be complete in order to do stuff with it Nov 24 22:22:27 in 2.0 I was using do_updateinfo[depends] += "${PN}:do_rootfs" Nov 24 22:23:22 and it seemed to work too, in 2.2 I had to switch to depending on do_image_complete, but again changed it to "after do_image_complete" after a hint from rburton, who suggested that the [depends] thing is a a bit weird and most tasks do it via the "after" line Nov 24 22:23:32 Jin^eLD: depend on the do_image_xxx task which generates what yoiu need Nov 24 22:24:05 addtask foo after do_image_ext4 before do_image_complete Nov 24 22:24:08 or whatever Nov 24 22:24:46 that would make my task depend on ext4/ext3/ubifs, but it does not care what the image is, it will take whatever image was configured for that machine, but it needs this image to be considered "final" or complete Nov 24 22:25:19 we have different hardware that requires different images, the task in question is very generic Nov 24 22:25:26 and works for all of them Nov 24 22:25:44 whats the difference between just "do_image" and "do_image_complete"? Nov 24 22:26:31 Jin^eLD: the process is do_rootfs -> do_image -> -> do_image_complete Nov 24 22:26:48 mhh, so I am actually depending on the "correct" task for my usecase Nov 24 22:28:31 Jin^eLD: if you don't need a separate task, make it a do_image_complete prefunc ? Nov 24 22:29:02 would it work if I have some interdependencies between those tasks? Nov 24 22:29:09 I have yet another two where one depends no the other Nov 24 22:29:29 for this particular one, that writes the info file for the firmware a prefunc would work I guess Nov 24 22:29:46 Jin^eLD: I have no idea, I'll probably suggest something and then you'll add yet another constraint Nov 24 22:29:59 Jin^eLD: prefuncs can be appended and prepended though and ordering is preserved Nov 24 22:30:44 RP: sorry :) those constraints have a life of their own :) Nov 24 22:30:50 but from what it sounds the prefuncs could do the trick Nov 24 22:30:59 I'd just have to take some care with ordering Nov 24 22:32:04 another option for this would be to use a conversion command Nov 24 22:32:49 rburton did suggest that too, but of course at that point I did not know the tasks would be such a problem and they did seem like a cleaner solution Nov 24 22:33:02 hmm, the prefuncs have to be python? or can they be shell? Nov 24 22:33:08 either Nov 24 22:33:58 ok let me try the prefunc approach... Nov 24 22:35:22 hmm that did not work somehow Nov 24 22:35:51 do_image_complete[prefuncs] += "do_updateinfo" Nov 24 22:36:07 Jin^eLD: don't call them do_, those are generally tasks Nov 24 22:36:17 and then do_updateinfo ran before the ext3 image got generated Nov 24 22:36:50 RP: ok.. was a quick hack in the class, I just removed the addtask line and added the proefuncs line Nov 24 22:37:37 Jin^eLD: that should work Nov 24 22:38:33 but it doesnt... Nov 24 22:38:48 it gets executed before the ext3 file is written Nov 24 22:39:29 I kind of need it "after everything else but just right before do_image_complete" Nov 24 22:39:38 Jin^eLD: where are you looking for it being written to? Nov 24 22:39:49 deloy image dir Nov 24 22:39:55 oh.. should I now change that to workdir? Nov 24 22:39:59 Jin^eLD: it goes to IMGDEPLOYDIR which is the staging area Nov 24 22:40:07 do_image_complete then moves into place Nov 24 22:40:11 oooh Nov 24 22:40:19 right, right, ok let me fix the class then Nov 24 22:43:47 cool :) Nov 24 22:43:49 now it works Nov 24 22:43:55 RP, bluelightning: thank you! Nov 24 22:44:06 I'll see that I rewrite all my other image postprocessing classes tomorrow Nov 24 22:44:20 Jin^eLD: glad we got there :) Nov 24 22:44:27 yes, thank you :) Nov 24 22:45:37 np Nov 24 23:08:42 nite **** ENDING LOGGING AT Fri Nov 25 02:59:59 2016