**** BEGIN LOGGING AT Tue Mar 24 02:59:57 2020 Mar 24 10:10:39 Hi, I changed my SDKPATH and now the build of nativesdk-libgcc-initial fails. The issue looks like this one: https://www.mail-archive.com/yocto@yoctoproject.org/msg30193.html Mar 24 10:12:11 It seems like the STAGING_INCDIR directory in which limits.h is created here: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc/libgcc-initial.inc#n47 Mar 24 10:13:06 Doesn't match with the include search path when using "gcc -E" Mar 24 10:13:26 configure: error: C preprocessor "x86_64-ktnsdk-linux-gcc -E --sysroot=/home/gitlab-runner/builds/37c36cdf/0/yocto-ktn/build-ktn-imx/builds/kontron-mx8mm/yocto-exceet/build-ktn-imx/tmp/work/x86_64-nativesdk-ktnsdk-linux/nativesdk-libgcc-initial/9.2.0-r0/recipe-sysroot " fails sanity check Mar 24 10:16:56 Any ideas? Mar 24 13:56:44 JPEW, RP: I seem to have gotten bitbake into the state I mentioned in email a month or so back. Every task is giving me a "The metadata is not deterministic and this needs to be fixed." error. This is with hash equiv on, and BB_SRCREV_POLICY = "cache". Any interest in investigating? Mar 24 14:04:24 laplante: yes, definitely interest Mar 24 14:05:16 RP: cool, let me know what you need. I will probably email most of it directly to you and JPEW (if he doesn't mind), since I don't want to leak anything potentially sensitive on IRC Mar 24 14:06:14 laplante: ok, no problem. This is the "the basehash value changed from " message right? Mar 24 14:07:07 RP: correct. there are also some interspersed _setscene task failures, where it fails to fetch certain pieces of sstate Mar 24 14:07:35 RP: it only affects recipes that use AUTOREV, but we have a lot of them Mar 24 14:08:13 laplante: there are a few tricks to debugging this. Firstly is to find a nice test target, one of those autorev recipes's do_fetch should be fairly minimal dependency wise Mar 24 14:08:50 laplante: then to dump the sigs for that recipe, bitbake X -c fetch -S none Mar 24 14:09:28 RP: I have a perfect one in mind. It's a recipe that simply fetches help documentation and packages it up. I will dump the sigs and send it to you. Mar 24 14:09:47 laplante: bitbake-dumpsig on the file in tmp/stamps/XXXX/do_fetch.sigdata should show a matching bashhash for the failure (note basehash, not taskhash) Mar 24 14:10:07 laplante: what we really need is the sig dump for both basehashes Mar 24 14:10:24 laplante: there could be other sigdatas from previous runs which might have the other bashhash Mar 24 14:10:48 laplante: failing that, you may be able to move bits of the cache out the way to cause it to generate the other sigdata Mar 24 14:11:36 laplante: its hard to be specific about how to get something for both hashes without knowing how they were caused :/ Mar 24 14:12:14 RP: I just tried the -S none and it gave me the "Bitbake's cached basehash does not match the one we just generated" error. Mar 24 14:12:58 laplante: it should have generated the files though? Mar 24 14:13:17 laplante: if it didn't we may need to bypass that error :/ Mar 24 14:13:30 laplante: Yes, that's fine with me Mar 24 14:13:35 RP: it generated locked-sigs.inc Mar 24 14:13:48 laplante: right, it should have generated sigdata too then Mar 24 14:13:48 I will find the referrent sigdata Mar 24 14:13:54 yep, looking now Mar 24 14:14:40 JPEW: great :) Mar 24 14:15:17 RP: locked-sigs.inc refers to luihelp-a:do_fetch:7727ec438d1107aac89d5d431f89eb8c44951a98259ac3a45c59504e2564b3b0, and I tried with no luck: find sstate-cache -name "*7727ec438d1107aac89d5d431f89eb8c44951a98259ac3a45c59504e2564b3b0*" Mar 24 14:15:32 RP: is that the correct place to look? Mar 24 14:16:39 laplante: no, just look directly in tmp/stamps/core2-64-poky-linux/bash/5.0-r0.do_fetch.sigdata.X Mar 24 14:16:44 laplante: (bash as an example) Mar 24 14:17:56 RP: gotcha. This is the only stamp: tmp/stamps/cortexa9t2hf-neon-linux-gnueabi/luihelp-a/1.0+gitAUTOINC+118e8bf1e6-r0.do_fetch.sigdata.356c3b09667adcfdcc31c9a86d5e706ecd3c0b63595720dab5bc28608a82f94c Mar 24 14:18:04 RP: which is referenced in the error message (just emailed to you both) Mar 24 14:18:06 Taskhash mismatch 356c3b09667adcfdcc31c9a86d5e706ecd3c0b63595720dab5bc28608a82f94c versus 7727ec438d1107aac89d5d431f89eb8c44951a98259ac3a45c59504e2564b3b0 for /home/laplante/yocto/sources/poky/../meta-agilent-app/recipes-ui/luihelp/luihelp-a_git.bb:do_fetch Mar 24 14:18:35 laplante: taskhash, not basehash ? Mar 24 14:19:08 RP: for basehashes, it says this: The mismatched hashes were 9994a86f4217e76196822e3c051f382f4c07191f4c5d97f1840f0c2aea3d243d and 97650c4348785c4c33a6ee541c8a585dfccbc5a283850b163f5021a1b663d630 Mar 24 14:19:43 laplante: ok, the taskhash just follows the basehash, that makes sense Mar 24 14:20:51 RP: should I try the printdiff now? Mar 24 14:20:55 laplante: can you send me the sigdata (or run bitbake-dumpsig on it and send that) ? Mar 24 14:21:04 RP: will do Mar 24 14:21:32 laplante: the key question is what has changed in that file which means the basehash isn't calculating correctly Mar 24 14:21:56 laplante: if you can diff two of them its easy. If not, you have to figure out which value is incorrect Mar 24 14:22:59 RP: right. just sent the sigdata. It produces a very nice small bitbake-dumpsig, which should hopefully makes thing easier Mar 24 14:23:10 laplante: I'd also be interested in what you get from a clean build not showing this error Mar 24 14:24:10 RP: I have another VM where I can produce the sigdata for fetch if you'd like. Mar 24 14:25:11 laplante: it'd be useful for comparison. As you say, the good news is that file is nice and short Mar 24 14:26:01 laplante: in fact the only thing that can really be changing is AUTOREV's value or maybe BRANCH Mar 24 14:26:35 laplante: what is very revealing is the value of AUTOREV vs what is in that filename Mar 24 14:27:01 laplante: I'm going to guess if we force AUTOREV to the value in the filename, we'd get the other basehash Mar 24 14:27:56 laplante: I've got meetings coming up but that is probably the next thing to test, hack that sigdata's AUTOREV value and see if the calculated hash matches Mar 24 14:28:54 laplante: sorry, need do sort the weekly status reports and meetings for a bit Mar 24 14:29:32 laplante: I wonder if this triggers when the remote repo updates Mar 24 14:30:27 RP: OK, sent. In the working case, I am using BB_SRCREV_POLICY = "clear" Mar 24 14:30:55 RP: no prob, I have a meeting at 11 anyway. Mar 24 15:13:37 laplante: I hexeditted that file and put the other SRCREV in Mar 24 15:13:48 laplante: when I run bitbake dumpsigs I then see Computed base hash is 9994a86f4217e76196822e3c051f382f4c07191f4c5d97f1840f0c2aea3d243d and from file 97650c4348785c4c33a6ee541c8a585dfccbc5a283850b163f5021a1b663d630 Mar 24 15:14:08 laplante: so the reason for the sig difference is now clear Mar 24 15:14:30 laplante: cause is unknown but you just have to work these things backwards :) Mar 24 15:14:35 RP: interesting, good catch Mar 24 15:17:01 RP: I will try to work on some concrete steps to reproduce. Mar 24 15:17:46 laplante: I'm guessing its something like "build remote repo with locked version; upstream moves forward; build rerun shows warnings" Mar 24 15:18:12 laplante: that would imply the cached data doesn't make it somewhere it should Mar 24 15:18:30 RP: yes, agreed. Mar 24 15:18:34 RP: that's the approach I will try Mar 24 15:18:56 laplante: we have no selftest for autorev so if you were to write this in the form of a new test... :) Mar 24 15:19:11 but any reproducer would be good Mar 24 15:19:41 RP: good idea! I will attempt to reproduce manually, then try to write it as a selftest :) Mar 24 15:20:06 RP: will prob need guidance, so please expect some emails haha Mar 24 15:20:25 laplante: np, as I said, I'd love to add coverage in this area Mar 24 15:20:50 RP: it's an easy sell for me since we use it extensively (for better or for worse) Mar 24 15:21:40 laplante: its also broken in master (see discussion on bitbake-devel) Mar 24 15:22:10 RP: Ah yes, I have been following that discussion with furrowed brow Mar 24 15:24:27 RP: I think I will write my self test assuming that commit is reverted Mar 24 15:25:51 laplante: I will likely revert it, it shoudn't have merged Mar 24 15:36:08 RP: weird, there is a test called test_gitfetch_localusehead in tests/fetch.py that does self.d.setVar("SRCREV", "AUTOINC"). How is that passing? Mar 24 15:36:37 laplante: don't know :/ Mar 24 15:37:00 RP: ah nvm, AUTOINC is handled in fetch2/__init__.py Mar 24 15:37:08 if srcrev == "AUTOINC": Mar 24 15:38:12 RP: kind of weird that AUTOINC is both used as a placeholder for PR and also for SRCREV Mar 24 15:39:26 laplante: this is very old and odd code :( Mar 24 15:47:58 Hi, I recently send some patches to oe-core, but I had to supersed them with v2. I guess something went wrong, only 1/5 was superseded, is there anything I can do to fix this ? https://patchwork.openembedded.org/project/oe-core/patches/?submitter=13375&state=* Mar 24 17:33:24 I'm completely forgetting how to make the _git version of a recipe never preferred version Mar 24 17:34:30 finally found it.. DEFAULT_PREFERENCE = '-1' I think.. **** ENDING LOGGING AT Wed Mar 25 02:59:57 2020