**** BEGIN LOGGING AT Wed Sep 25 02:59:57 2019 Sep 25 05:25:28 I have a recipe question. In case of writing a manual do_install() do i really need to install each single file with an specific install command? I have a bunch of shared objects and also some xml-files that i like to install. Is there a way to use wildcards like: (install -m 0644 ${S}/libs/*.so ${D}/usr/lib/) and (FILES_${PN} += "/usr/lib/*.so") ? Sep 25 06:14:46 Domin1k you can use 'cp' instead of install Sep 25 06:25:52 thanks(y) Sep 25 06:28:12 tesaddict: thank you for your testimony, please tell others too, but if you have gripes then tell us first :) Sep 25 06:30:19 mischief: are you adding to rdep or to dep, dep on output package wont work, only rdep will work. Sep 25 07:07:46 yates: sdk sets up right env for pkg-config, so are you sourcing the env ? Sep 25 07:09:44 Domin1k: prefer to use install program to setup right username/groups install can do multiple files Sep 25 07:30:58 New news from stackoverflow: Node.js error "invalid opcode ip" on Yocto(rocko) Sep 25 08:31:07 New news from stackoverflow: Unable to show splashscreen using Yocto custom image for iMX6 Sep 25 08:44:03 I can't seem to find a way to specify a specific Git commit to use as a patch. Is this supported ? Sep 25 08:47:14 Smit-Tay: Why don't you use git format-patch to create a patch that you then can apply within your recipe? Sep 25 08:49:25 khem: was wondering is there any plans to upgrade the vboxguestdrivers to the 6.0.x release. see you blacklisted the old 5.2.18 one Sep 25 08:52:15 A patch already exists in a git repository. Ideally, I would specify the repo and commit ID and bitbake would do the rest. Seems like this ought to be pretty standard Sep 25 08:57:42 Smit-Tay: So you would like to cherry-pick a specific commit ontop of your SRCREV? Sep 25 09:21:31 Yes, My particular issue is building tags/yocto-2.7.1 - in this qemu-native doesn't build under Fedora 30 (current). It seems there's a compile error related to changes in kernel headers. So, I am thinking I need to apply a patch, which I think resides here: https://github.com/patchew-project/qemu tags/patchew/20190604071915.288045-1-borntraeger@de.ibm.com Sep 25 09:24:04 JPEW: sorry, I never got back to you with that data did I? :( Sep 25 09:24:48 smit-tay: oe-contrib branch thud-next has the fix waiting for you to cherry-pick Sep 25 09:29:17 rburton: OK, so, how do I find it ? And, how do I apply it via BitBake during the build ? I've looked through the docs, but don't see this covered Sep 25 09:32:56 Smit-Tay: apply http://git.openembedded.org/openembedded-core-contrib/patch/?id=fac2d3846dadfda256e94500bdf33f546a8d1fb4 to your tree Sep 25 09:33:16 if you're using a git checkout of the tag then you can just git am that, or fetch oe-contrib and cherry-pick it Sep 25 09:37:17 OK, but, that's a manual step which I would have to repeat each time I build. So, if I am automating a build which is going to be performed many times per day via a CI that's not a solution - at least as far as I can understand what you are talking about. What I *think* I need to do is to change the recipe for Qemu so that it automatically applies that patch. Right ? Sep 25 09:38:53 Smit-Tay: bbappend with the two patches in this commit in SRC_URI += Sep 25 09:40:10 or you force your whole layer to checkout this revision instead of the one you currently have (but then you have all patches in between your revision and the new one) Sep 25 09:40:18 OK, that sounds more like what I am thinking. Sep 25 09:40:25 exactly, which is what I don't want Sep 25 09:54:20 i'd personall branch 2.7.1 and cherry-pick that commit Sep 25 09:54:39 then when 2.7.2 is out, you can switch to that Sep 25 09:55:37 this is precisely why we endorse using a git clone over tarballs. you can grab fixes before they're released if you need them. Sep 25 09:57:27 D'Oh Sep 25 09:57:55 D' Oh, D'Oh..... god, how stupid I feel now Sep 25 10:03:24 But, wait - now I am confused. Yocto/tag 2.7.1 is just a bunch of recipies. It doesn't include the sources, they're downloaded at build time. So, how do I cherry pick a patch to a "dynamic" set of source files ? Sep 25 10:06:33 Thus the bbappend solution is basically mandatory Sep 25 10:16:44 do you have a git clone of poky/oe/yocto whatever? Sep 25 10:17:00 that commit i pointed to is a fix to the recipe to add a patch during the buid Sep 25 10:17:03 just cherry-pick that Sep 25 10:17:16 (or switch to thud-next, and contribute to the testing of that branch) Sep 25 10:22:09 ahhhh Sep 25 10:45:29 rburton: Can I ask why this patch is so complicated, and isn't just a bbappend file which applies the cherry pick ? Basically like qschultz has suggested ? Sep 25 10:47:24 Smit-Tay: why would oe-core need a bbappend to alter its own recipes? Sep 25 10:47:34 that patch is just the fix, and a one line change to qemu.bb to apply it Sep 25 10:47:53 feel free to use a bbappend if you don't want to pick this patch Sep 25 10:48:00 i was just pointing you to something easier than writing a bbappend Sep 25 10:48:49 Understood. Trying to get the mindset so I can make better decisions myself. Sep 25 13:01:42 jwessel: ping Sep 25 13:01:55 New news from stackoverflow: Yocto Initramfs Transaction Error adding cryptsetup package Sep 25 13:44:47 RP: No, you didn't. I would still like the AB hashequiv DB if you can. Sep 25 13:49:26 JPEW: its around 820MB. https://www.rpsys.net/wp/rp/hash/ Sep 25 13:50:06 JPEW: I think I know why I can't reproduce. Its because I'm using an "auto" hashserv whilst the autobuilder is a static address Sep 25 13:50:34 JPEW: I was wondering if we can just copy the bb_unihashes.dat file into the eSDK? Sep 25 13:50:48 Ya, thats what I was thinking Sep 25 13:59:56 Is it safe to remove build/cache/[bb_codeparser.dat,bb_unihashes.dat], in the sense that they will be recreated automatically ? Sep 25 14:00:44 kroon: Should be. You might end up rebuilding some things. Sep 25 14:01:06 RP: Is the eSDK querying the hash server? Sep 25 14:02:41 JPEW, or.. are those two files not forever-growing in the same way that the sstate-cache is ? Sep 25 14:07:34 kroon: Not sure about bb_codeparser.dat, but AFAIK, bb_unihashes.dat will grow indefinitely Sep 25 14:08:34 JPEW, ok Sep 25 14:09:06 JPEW: depends if it can find one. "auto" would start one locally :/ Sep 25 14:10:26 RP: Ah... the AB would find the one that you have set up though correct? Sep 25 14:10:35 JPEW: I suspect so Sep 25 14:11:22 RP: My current theory is that some other builder has changed the hashes after the eSDK is built but before it runs the tests (and thus reports different hashes in the test) Sep 25 14:12:29 RP: Haven't gotten to test this yet... running the eSDK test murders my under-powered desktop Sep 25 14:17:27 JPEW: how can another builder change the hashes? Sep 25 14:18:41 JPEW: you can reduce the tests to the ones that fail Sep 25 14:18:53 RP: Ya, I'll try that Sep 25 14:52:44 Hi all, could we backport https://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/machine/include/arm/arch-arm64.inc?id=29edc44efabf605c4ba1d7a5ca34d1a574e0e016 to thud maybe? Sep 25 15:20:42 Could someone review my patch (http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287342.html), please? :) Sep 25 15:22:54 JPEW: I'm going to try http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b346cb9f423ed271fe7fa966a42d3c23093e1a26 Sep 25 15:25:32 RP: Looks good. That sounds like a reasonable fix if that is indeed the problem (which I think seems likely) Sep 25 15:26:08 JPEW: there are two changes there, copy in the hashes db and fix the siggen mismatch warning for unihashes Sep 25 15:26:19 since with the latter, the fact they don't match doesn't surprise us Sep 25 15:27:26 RP: Makes sense, I think. I still don't fully grasp how the locked signatures are supposed to behave, but I'm slowing figuring it out :) Sep 25 15:29:00 JPEW: "The signature is X, ignore what else you think it may be" :) Sep 25 16:27:37 mranostay: I am open for someone sending a fix and unblacklist it Sep 25 16:45:10 halstead: I am seeing "ERROR: HTTP Error 500: OK" when trying to upload logs into errors.yp.org from oe builders Sep 25 16:45:18 any hints ? it use to work fine Sep 25 17:32:43 New news from stackoverflow: Modify Yocto image to use Systemd instead of SysVInit Sep 25 17:47:58 khem: that usually means something in the error report it can't cope with Sep 25 17:48:00 alessioigor: Pong Sep 25 17:48:43 jwessel: Could you review my patch (http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287342.html), please? Sep 25 17:48:59 I was doing more than that. I took a look at the patch, I was trying to test it. Sep 25 17:49:14 I setup a build a couple hours ago against it. Sep 25 17:49:40 I'll let you know the results. Sep 25 17:50:52 jwessel: It's kind of you. Sep 25 17:53:48 jwessel: It isn't first time that you test my patches... ;) Sep 25 17:53:53 I wanted to make sure it still works. I couldn't tell by just looking at the code that it still going to do the right thing or not for additional partitions which reference another directory for the content. Sep 25 17:54:47 JPEW: that didn't fix the AB failure FWIW but did quieten the warnings Sep 25 17:58:50 RP:hmm I wonder how we can debug it Sep 25 18:02:57 khem: I've setup a local server before to do it. You can also copy the error report file off the worker to test submission locally Sep 25 18:17:37 alessioigor: The build finally finished. It is back to the old behavior of using what ever the first computed volume for each partition, which is what the original commit changed. Sep 25 18:17:46 I suspected that would happen. Sep 25 18:20:28 If you try to set the IMAGE_ROOTFS_SIZE to be the empty string, then the tar image bit fails. Sep 25 18:22:49 alessioigor: What is the behavior you are seeking, or rather what is broken with wic? It does have the ability to use a fixed or suggested size for a partition. Sep 25 18:23:06 I think the IMAGE_ROOTFS_SIZE happens to be used for more than one purpose however. Sep 25 18:36:23 RP: Ok. I'll keep trying Sep 25 18:41:55 khem: re: dep or rdep, i'm using MACHINE_ESSENTIAL_EXTRA_RDEPENDS, which is pulled in via PACKAGE_INSTALL to my initramfs. Sep 25 18:45:47 JPEW: finally reproduced locally. Had to use a shared hashserv and ssate cache and two different build directories Sep 25 18:46:13 JPEW: no idea what is wrong but its a start Sep 25 18:46:21 RP: Interesting, is that with the bb_unihash.dat in the eSDK? Sep 25 18:46:34 JPEW: yes, that is with the patch in -next Sep 25 18:47:23 RP: Did the warnings appear? Sep 25 18:47:39 JPEW: no, warnings are silenced Sep 25 18:48:07 JPEW: looks like https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/1071 Sep 25 18:48:15 (step2c there failed) Sep 25 18:49:16 RP: Which means the locked hash matched the unihash (or taskhash) Sep 25 18:49:34 JPEW: yes Sep 25 18:55:19 mischief: you mean IMAGE_INSTALL Sep 25 18:56:18 Has anyone seen gnulib fail at do_install when being restored from sstate? Sep 25 19:17:46 tgoodwin: an old release? Sep 25 19:18:42 khem: no, im using PACKAGE_INSTALL. maybe thats my mistake? Sep 25 19:19:06 tgoodwin: I'm thinking of something else now I look... Sep 25 19:38:11 alessioigor: I sent you the fix, which makes your use case and mine work together. Sep 25 19:38:31 There is an explanation attached too. Sep 25 19:42:33 jwessel: are there extra tests we should have for this? Sep 25 19:42:49 RP: probably. Sep 25 19:43:01 I hadn't given it much thought about creating wic tests. Sep 25 19:43:12 jwessel: wic does have a lot of tests already Sep 25 19:43:25 jwessel: oe-selftest -r wic Sep 25 19:43:54 jwessel: see lib/oeqa/selftest/cases/wic.py Sep 25 19:44:14 My guess is that doesn't have any which test the size of the images using the dynamic partition sizing. Sep 25 19:44:27 jwessel: highly likely Sep 25 19:44:49 % oe-selftest -r wic Sep 25 19:44:49 2019-09-25 12:44:11,644 - oe-selftest - WARNING - meta-selftest layer not found in BBLAYERS, adding it Sep 25 19:44:49 2019-09-25 12:44:16,463 - oe-selftest - ERROR - Please unset SANITY_TESTED_DISTROS in order to run oe-selftest Sep 25 19:44:58 hmm... I am not even sure what that means. Sep 25 19:45:10 jwessel: put SANITY_TESTED_DISTROS="" in local.conf Sep 25 19:45:32 we do need to make it handle this kind of thing better but its harder than you'd think Sep 25 19:45:36 heh... probably ought to patch that. Sep 25 19:45:40 The message that is. Sep 25 19:45:57 * jwessel runs it to see what it does Sep 25 19:46:05 unset or clear would be more understandable Sep 25 19:46:41 I was going to send a patch that changes it literally to what you told me. Sep 25 19:47:13 Please add SANITY_TESTED_DISTROS="" to your local.conf in order to run oe-selftest Sep 25 19:47:21 jwessel: well, you could also unset it Sep 25 19:47:31 Where is it set? Sep 25 19:47:50 jwessel: probably in your distro config somewhere (poky sets it if you're using that) Sep 25 19:47:59 I was using the poky. Sep 25 19:48:13 it'll be poky.conf then Sep 25 19:48:24 In general that is what I use for all the oe submissions since everyone has it. Sep 25 19:49:27 hi all, is there a way to specify LICENSE_FLAGS_WHITELIST in an image recipe in a layer, instead of having it in build/local.conf? Sep 25 19:50:04 an related, how would one integrate with builders like jenkins when this var is specified in build/local.conf? inject it with a script? Sep 25 19:50:12 s/an related/and related/ Sep 25 19:50:47 marble_visions: CI systems usually generate some configuration into a conf/auto.conf which has similar behaviour to local.conf Sep 25 19:51:46 RP: yep, can definitely do that, was wondering if that was canonical, or there was some other way to incorporate license whitelists in image recipes Sep 25 19:52:49 RP: The existing tests are fairly comprehensive. It is simply the case there is no test for the dynamic partition sizing. I can add it to my backlog of things to look at, at some point. Sep 25 19:53:02 That is one way to stop it from breaking in the future :-) Sep 25 19:54:33 jwessel: wic has good tests which is why I'm a little surprised this isn't tested. Maybe you could file a bug for the fact its missing so we don't forget? Sep 25 19:55:06 marble_visions: I can't remember if that variable is an image level one or a global configuration one Sep 25 19:55:49 The reason there is no test has more to do with the fact I added the feature and didn't realize there was extensive tests already in place. Sep 25 19:56:25 There is also another test missing for adding a resizable fat partition at the end of the image. Sep 25 19:56:49 I am guilty of adding that feature as well and not realizing I could add a test for it. Sep 25 19:56:58 jwessel: hmm, I should have probably blocked merging on that! ;-) Sep 25 19:57:14 Most likely. Sep 25 19:57:39 You know I don't have an issue writing the test cases etc... Just didn't know they were there for wic. Sep 25 19:58:07 I took some notes down about it, and it will get fixed sometime after we get the release out. Sep 25 19:58:12 jwessel: right, I should have mentioned this before now so I'm partly to blame... Sep 25 19:58:30 jwessel: not everything has good tests but wic does Sep 25 19:58:31 Nah... fray was harping on oe-qa tests for a long time. Sep 25 19:58:43 I should have checked it had tests. Sep 25 19:58:52 Especially since I was adding stuff to it. Sep 25 19:59:04 jwessel: I do try and ensure where we have tests, we keep their coverage correct Sep 25 19:59:38 I like stuff not to break, makes it easier to justify reverts and keep thing working etc... I am a believer too. Sep 25 20:02:55 jwessel: with these tests we shouldn't really need reverts :) Sep 25 20:15:50 JPEW: this is starting to make my head hurt. The esdk that fails locally, repeatedly with testsdkext will externally install and work just fine Sep 25 20:17:23 RP: Ya... it's not very easy to figure out whats going on. Sep 25 20:17:32 RP: I have an idea though Sep 25 20:17:54 Need to check and see if it even makes sense Sep 25 20:26:37 RP: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/hash-equivalence&id=2d5fa1545f5531f4692f9dbcb6934c8d00c09291 Sep 25 20:27:22 RP: The theory is that lockedhashes isn't populate because no one is calling get_taskhash() anymore Sep 25 20:27:47 or at least not fully populated Sep 25 20:28:30 JPEW: I've wondered about that but that is a parameter error Sep 25 20:28:53 RP: Hah, ya it is Sep 25 20:28:53 JPEW: and wouldn't runqueue call get_taskhash ? Sep 25 20:36:43 RP: Hmm, yes. I see it also passes around lockedhashes in the taskdata, so it should all be in sync Sep 25 21:05:46 JPEW: right :/ Sep 25 21:08:51 JPEW: I have a bit more data on the failure case Sep 25 21:09:15 JPEW: myapp.bb:do_packagedata only depends on myapp.bb:do_package Sep 25 21:09:38 myapp.bb:do_package 83c471cb25be6a8f2859151654336c601449782719c6f222db0f178048adc85d Sep 25 21:09:38 Uni: myapp.bb:do_package 39805da03d7f02671cfe599936ec72ce08893de550c9c1660cfcd55acf32ab82 Sep 25 21:09:56 So do_package does have a different unihash to taskhash Sep 25 21:10:28 JPEW: the hash being used in the calc_taskhash is the taskhash, not the unihash Sep 25 21:11:34 JPEW: which suggests data['runtaskhashes'][dep] = self.get_unihash(dep) gets the wrong thing Sep 25 21:16:13 RP: do_package for that task shouldn't be locked? Sep 25 21:18:02 JPEW: no, since myapp is something its building with the sdk Sep 25 21:19:31 RP: Well, it's not setscene (AFAIK) so get_unihash() should return the taskhash Sep 25 21:20:56 JPEW: its hitting # If its not a setscene task we can return Sep 25 21:20:56 if self.setscenetasks and tid not in self.setscenetasks Sep 25 21:21:03 JPEW: so its my optimisation :( Sep 25 21:21:20 JPEW: do_package is a setscene task? Sep 25 21:21:35 Right... I suppose the question is why does a non-setscene task have a unihash? Sep 25 21:22:26 JPEW: it is a setscene task Sep 25 21:22:37 do_package? Sep 25 21:22:50 JPEW: well it has a setscene task Sep 25 21:23:00 Ah, OK, I missed that Sep 25 21:41:27 JPEW: This is looking to be a very silly mistake :/ Sep 25 21:50:19 JPEW: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=1e8ef4aed8d3030f43ac89870fa7858832532e9e Sep 25 21:50:26 maybe... Sep 25 22:03:22 * RP lets the autobuilder crunch that and aims for sleep Sep 25 22:30:44 RP: setting the setscene tasks sooner is the fix? Sep 25 22:31:59 RP: The stuff in set_unihash doesn't seem as critical. if that were even getting called I would expect the bb.fatal to trigger **** ENDING LOGGING AT Thu Sep 26 02:59:57 2019