| 01:29.42 | *** join/#oe dqx (~dqx@unaffiliated/dqx) |
| 02:34.04 | *** join/#oe jpuhlman (~jpuhlman@45.19.219.178) |
| 04:38.23 | *** join/#oe davidlt (~davidlt@78-63-27-146.static.zebra.lt) |
| 05:11.12 | *** join/#oe armpit (~armpit@2601:202:4180:a5c0:cc84:c3a2:bb8c:e448) |
| 06:20.58 | *** join/#oe AndersD (~AndersD@h83-209-96-136.cust.a3fiber.se) |
| 06:22.40 | *** join/#oe AndersD_ (~AndersD@195-67-57-138.customer.telia.com) |
| 07:11.00 | *** join/#oe kroon (~kroon@37-247-29-68.customers.ownit.se) |
| 07:36.36 | *** join/#oe frsc (~frsc@i59F4B1FF.versanet.de) |
| 07:51.21 | *** join/#oe tnovotny (~tnovotny@nat-50.starnet.cz) |
| 08:07.46 | *** join/#oe cpriouzeau (~cpriouzea@164.129.115.76) |
| 08:08.51 | *** join/#oe ao2 (~ao2@87.18.228.219) |
| 08:13.57 | *** join/#oe leon-anavi (~Leon@78.130.197.211) |
| 08:40.54 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 09:05.37 | *** join/#oe marka (~marka@198-84-181-245.cpe.teksavvy.com) |
| 09:16.52 | *** join/#oe bencoh (~bencoh@unaffiliated/bencoh/x-184637) |
| 09:32.15 | *** join/#oe sstiller (~sstiller@p200300F07F0E460135C7F0B43EE06C28.dip0.t-ipconnect.de) |
| 09:46.35 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 10:10.39 | frsc | 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 |
| 10:12.11 | frsc | 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 |
| 10:13.06 | frsc | Doesn't match with the include search path when using "gcc -E" |
| 10:13.26 | frsc | 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 |
| 10:16.56 | frsc | Any ideas? |
| 10:24.12 | *** join/#oe bradfa (uid297668@gateway/web/irccloud.com/x-vdvjulwryfopccte) |
| 10:24.15 | *** join/#oe hpsy (~hpsy@85.203.15.120) |
| 10:53.40 | *** join/#oe rburton (~rburton@192.198.151.43) |
| 11:10.13 | *** join/#oe florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 11:30.21 | *** join/#oe rburton (~rburton@134.191.227.39) |
| 11:33.36 | *** join/#oe berton (~berton@181.220.114.167) |
| 11:37.48 | *** join/#oe berton (~berton@181.220.114.167) |
| 12:08.38 | *** join/#oe rburton (~rburton@134.191.227.39) |
| 12:11.05 | *** join/#oe stefan_schmidt (~stefan_sc@p200300E9D702D8892917872F4CAE5733.dip0.t-ipconnect.de) |
| 12:19.11 | *** join/#oe creich (~creich@p200300F6AF406710000000000000039B.dip0.t-ipconnect.de) |
| 12:25.13 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 13:19.09 | *** join/#oe rburton (~rburton@134.191.227.39) |
| 13:51.29 | *** join/#oe yann|work (~yann@91-170-159-152.subs.proxad.net) |
| 13:53.22 | *** join/#oe laplante (03da0270@ec2-3-218-2-112.compute-1.amazonaws.com) |
| 13:56.28 | *** join/#oe ericch (~ericch@pool-108-34-251-214.prvdri.fios.verizon.net) |
| 13:56.44 | laplante | 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? |
| 14:04.24 | RP | laplante: yes, definitely interest |
| 14:05.16 | laplante | 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 |
| 14:06.14 | RP | laplante: ok, no problem. This is the "the basehash value changed from " message right? |
| 14:07.07 | laplante | RP: correct. there are also some interspersed _setscene task failures, where it fails to fetch certain pieces of sstate |
| 14:07.35 | laplante | RP: it only affects recipes that use AUTOREV, but we have a lot of them |
| 14:08.13 | RP | 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 |
| 14:08.50 | RP | laplante: then to dump the sigs for that recipe, bitbake X -c fetch -S none |
| 14:09.28 | laplante | 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. |
| 14:09.47 | RP | 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) |
| 14:10.07 | RP | laplante: what we really need is the sig dump for both basehashes |
| 14:10.24 | RP | laplante: there could be other sigdatas from previous runs which might have the other bashhash |
| 14:10.48 | RP | laplante: failing that, you may be able to move bits of the cache out the way to cause it to generate the other sigdata |
| 14:11.36 | RP | laplante: its hard to be specific about how to get something for both hashes without knowing how they were caused :/ |
| 14:12.13 | laplante | 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. |
| 14:12.58 | RP | laplante: it should have generated the files though? |
| 14:13.16 | RP | laplante: if it didn't we may need to bypass that error :/ |
| 14:13.30 | JPEW | laplante: Yes, that's fine with me |
| 14:13.35 | laplante | RP: it generated locked-sigs.inc |
| 14:13.48 | RP | laplante: right, it should have generated sigdata too then |
| 14:13.48 | laplante | I will find the referrent sigdata |
| 14:13.54 | laplante | yep, looking now |
| 14:14.40 | laplante | JPEW: great :) |
| 14:15.17 | laplante | RP: locked-sigs.inc refers to luihelp-a:do_fetch:7727ec438d1107aac89d5d431f89eb8c44951a98259ac3a45c59504e2564b3b0, and I tried with no luck: find sstate-cache -name "*7727ec438d1107aac89d5d431f89eb8c44951a98259ac3a45c59504e2564b3b0*" |
| 14:15.32 | laplante | RP: is that the correct place to look? |
| 14:16.39 | RP | laplante: no, just look directly in tmp/stamps/core2-64-poky-linux/bash/5.0-r0.do_fetch.sigdata.X |
| 14:16.44 | RP | laplante: (bash as an example) |
| 14:17.56 | laplante | RP: gotcha. This is the only stamp: tmp/stamps/cortexa9t2hf-neon-linux-gnueabi/luihelp-a/1.0+gitAUTOINC+118e8bf1e6-r0.do_fetch.sigdata.356c3b09667adcfdcc31c9a86d5e706ecd3c0b63595720dab5bc28608a82f94c |
| 14:18.04 | laplante | RP: which is referenced in the error message (just emailed to you both) |
| 14:18.06 | laplante | Taskhash mismatch 356c3b09667adcfdcc31c9a86d5e706ecd3c0b63595720dab5bc28608a82f94c versus 7727ec438d1107aac89d5d431f89eb8c44951a98259ac3a45c59504e2564b3b0 for /home/laplante/yocto/sources/poky/../meta-agilent-app/recipes-ui/luihelp/luihelp-a_git.bb:do_fetch |
| 14:18.35 | RP | laplante: taskhash, not basehash ? |
| 14:19.08 | laplante | RP: for basehashes, it says this: The mismatched hashes were 9994a86f4217e76196822e3c051f382f4c07191f4c5d97f1840f0c2aea3d243d and 97650c4348785c4c33a6ee541c8a585dfccbc5a283850b163f5021a1b663d630 |
| 14:19.43 | RP | laplante: ok, the taskhash just follows the basehash, that makes sense |
| 14:20.51 | laplante | RP: should I try the printdiff now? |
| 14:20.55 | RP | laplante: can you send me the sigdata (or run bitbake-dumpsig on it and send that) ? |
| 14:21.04 | laplante | RP: will do |
| 14:21.29 | *** join/#oe yann|work (~yann@185.123.26.194) |
| 14:21.32 | RP | laplante: the key question is what has changed in that file which means the basehash isn't calculating correctly |
| 14:21.56 | RP | laplante: if you can diff two of them its easy. If not, you have to figure out which value is incorrect |
| 14:22.59 | laplante | RP: right. just sent the sigdata. It produces a very nice small bitbake-dumpsig, which should hopefully makes thing easier |
| 14:23.10 | RP | laplante: I'd also be interested in what you get from a clean build not showing this error |
| 14:24.10 | laplante | RP: I have another VM where I can produce the sigdata for fetch if you'd like. |
| 14:25.10 | RP | laplante: it'd be useful for comparison. As you say, the good news is that file is nice and short |
| 14:26.01 | RP | laplante: in fact the only thing that can really be changing is AUTOREV's value or maybe BRANCH |
| 14:26.35 | RP | laplante: what is very revealing is the value of AUTOREV vs what is in that filename |
| 14:27.01 | RP | laplante: I'm going to guess if we force AUTOREV to the value in the filename, we'd get the other basehash |
| 14:27.56 | RP | 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 |
| 14:28.54 | RP | laplante: sorry, need do sort the weekly status reports and meetings for a bit |
| 14:29.32 | RP | laplante: I wonder if this triggers when the remote repo updates |
| 14:30.27 | laplante | RP: OK, sent. In the working case, I am using BB_SRCREV_POLICY = "clear" |
| 14:30.55 | laplante | RP: no prob, I have a meeting at 11 anyway. |
| 15:13.37 | RP | laplante: I hexeditted that file and put the other SRCREV in |
| 15:13.48 | RP | laplante: when I run bitbake dumpsigs I then see Computed base hash is 9994a86f4217e76196822e3c051f382f4c07191f4c5d97f1840f0c2aea3d243d and from file 97650c4348785c4c33a6ee541c8a585dfccbc5a283850b163f5021a1b663d630 |
| 15:14.08 | RP | laplante: so the reason for the sig difference is now clear |
| 15:14.30 | RP | laplante: cause is unknown but you just have to work these things backwards :) |
| 15:14.35 | laplante | RP: interesting, good catch |
| 15:17.01 | laplante | RP: I will try to work on some concrete steps to reproduce. |
| 15:17.45 | RP | laplante: I'm guessing its something like "build remote repo with locked version; upstream moves forward; build rerun shows warnings" |
| 15:18.12 | RP | laplante: that would imply the cached data doesn't make it somewhere it should |
| 15:18.30 | laplante | RP: yes, agreed. |
| 15:18.33 | laplante | RP: that's the approach I will try |
| 15:18.56 | RP | laplante: we have no selftest for autorev so if you were to write this in the form of a new test... :) |
| 15:19.11 | RP | but any reproducer would be good |
| 15:19.41 | laplante | RP: good idea! I will attempt to reproduce manually, then try to write it as a selftest :) |
| 15:20.06 | laplante | RP: will prob need guidance, so please expect some emails haha |
| 15:20.25 | RP | laplante: np, as I said, I'd love to add coverage in this area |
| 15:20.35 | *** join/#oe tnovotny (~tnovotny@nat-50.starnet.cz) |
| 15:20.50 | laplante | RP: it's an easy sell for me since we use it extensively (for better or for worse) |
| 15:21.40 | RP | laplante: its also broken in master (see discussion on bitbake-devel) |
| 15:22.10 | laplante | RP: Ah yes, I have been following that discussion with furrowed brow |
| 15:24.27 | laplante | RP: I think I will write my self test assuming that commit is reverted |
| 15:25.51 | RP | laplante: I will likely revert it, it shoudn't have merged |
| 15:36.08 | laplante | 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? |
| 15:36.37 | RP | laplante: don't know :/ |
| 15:37.00 | laplante | RP: ah nvm, AUTOINC is handled in fetch2/__init__.py |
| 15:37.08 | laplante | if srcrev == "AUTOINC": |
| 15:38.12 | laplante | RP: kind of weird that AUTOINC is both used as a placeholder for PR and also for SRCREV |
| 15:39.26 | RP | laplante: this is very old and odd code :( |
| 15:46.57 | *** join/#oe JaMa (~martin@109.238.218.228) |
| 15:47.02 | *** join/#oe luismartins (~luis@213.205.68.220) |
| 15:47.58 | luismartins | 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=* |
| 16:04.00 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 16:32.42 | *** join/#oe hillct (~hillct@50.55.61.64) |
| 16:41.58 | *** join/#oe tafa (~ta20@5.202.108.168) |
| 17:24.16 | *** join/#oe rcw (~rcw@45.72.242.250) |
| 17:33.08 | *** join/#oe fray (~fray@kernel.crashing.org) |
| 17:33.24 | fray | I'm completely forgetting how to make the _git version of a recipe never preferred version |
| 17:34.30 | fray | finally found it.. DEFAULT_PREFERENCE = '-1' I think.. |
| 17:48.11 | *** join/#oe vesper11 (~ves@82.102.17.182) |
| 17:53.15 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 18:05.28 | *** join/#oe jaeckel (~jaeckel@unaffiliated/jaeckel) |
| 18:13.10 | *** join/#oe mauz555 (~mauz555@2a01:e0a:56d:9090:e9f4:57b2:ae91:a2c1) |
| 18:35.39 | *** join/#oe ao2 (~ao2@87.18.228.219) |
| 18:41.15 | *** join/#oe kroon (~kroon@37-247-29-68.customers.ownit.se) |
| 19:22.46 | *** join/#oe mauz555 (~mauz555@2a01:e0a:56d:9090:e9f4:57b2:ae91:a2c1) |
| 19:34.28 | *** join/#oe mauz555 (~mauz555@2a01:e0a:56d:9090:e9f4:57b2:ae91:a2c1) |
| 19:38.09 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 20:38.18 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 22:14.36 | *** join/#oe infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 22:14.36 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 23:21.46 | *** join/#oe troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |