14017 2020-08-20 03:06:32 +0000 buildhistory-collect-srcrevs wrongly outputs glibc SRCREV 2021-11-24 10:13:34 +0000 1 1 7 Build System, Metadata & Runtime OE-Core oe-core other unspecified x86 Multiple RESOLVED FIXED Medium normal 4.0 M1 1 ydirson richard.purdie ernstp randy.macleod richard.purdie --- --- Don't know oldest_to_newest 87990 0 ydirson 2020-08-20 03:06:32 +0000 In dunfell 3.1.2, buildhistory-collect-srcrevs notably outputs the following: SRCREV_pn-glibc = "109474122400ca7d60782b131dc867a5c1f2fe55" SRCREV_pn-nativesdk-glibc = "109474122400ca7d60782b131dc867a5c1f2fe55" However those are explicitly set (and this surely should not be output there), though not using a simple SRCREV but using SRC_URI naming: SRCREV_glibc ?= "109474122400ca7d60782b131dc867a5c1f2fe55" 87994 1 randy.macleod 2020-08-20 07:54:15 +0000 The hashes shown look correct. Can you explain the problem that you see in more detail? 88000 2 ydirson 2020-08-20 12:07:15 +0000 I expect to get only those SRCREV's that are determined at runtime through AUTOREV. In fact I was contemplating checking for buildhistory-collect-srcrevs output to ensure no AUTOREV gets into a release, for reproducibility purposes. I wouldnot be surprised to see it appear with "-a", but I can't see in what the glibc usecase is so special that it warrants listing its srcrev without "-a". I'm also suspecting that SRCREV_pn-glibc could be plain wrong, as setting it seems unlikely to override a variable named SRCREV_glibc. 88647 3 ernstp 2020-11-20 07:52:04 +0000 I have the same issue. This is because the main SRCREV in the glibc recipe is not set I think. I ran bitbake -e glibc > env-glibc.txt grep -E "^SRCREV" env-glibc.txt SRCREV="INVALID" SRCREV_glibc="6fdf971c9dbf7dac9bea552113fe4694015bbc4d" SRCREV_localedef="cd9f958c4c94a638fa7b2b4e21627364f1a1a655" Buildhistory.bbclass only looks for the main SRCREV when finding "orig_srcrev": with open(srcrevfile, 'w') as f: orig_srcrev = d.getVar('SRCREV', False) or 'INVALID' if orig_srcrev != 'INVALID': f.write('# SRCREV = "%s"\n' % orig_srcrev) buildhistory-collect-srcrevs then uses this commented "# SRCREV" line to determine if the package used an autorev or not (this is related to the --report-all option). So buildhistory-collect-srcrevs incorrectly thinks glibc was using AUTOREV when it was not. 88648 4 4750 ernstp 2020-11-20 08:19:04 +0000 Created attachment 4750 Patch to buildhistory.bbclass Here's one way to solve it 91972 5 steve 2021-11-11 16:16:07 +0000 Not enough time to make it into 3.1.12 91980 6 steve 2021-11-11 20:10:04 +0000 I can confirm that this issue is present in both master and dunfell 3.1.11 In both cases I did a checkout of the desired branch, enabled buildhistory in local.conf, and built core-image-minimal. I then ran the buildhistory-collect-srcrevs script: steve@hexa:~/builds/poky/build-master$ ../scripts/buildhistory-collect-srcrevs # core2-64-poky-linux SRCREV:pn-bzip2 = "f9061c030a25de5b6829e1abf373057309c734c0" SRCREV:pn-glibc = "ae37d06c7d127817ba43850f0f898b793d42aea7" steve@hexa:~/builds/poky/build-dunfell$ ../scripts/buildhistory-collect-srcrevs # core2-64-poky-linux SRCREV_pn-glibc = "4f0a61f75385c9a5879cbe7202042e88f692a3c8" I can also confirm the theory that the main SRCREV for glibc not being set is the source of the issue since we also now seem to have the same situation for glibc and bzip2 in master: steve@hexa:~/builds/poky/build-master$ bitbake -e glibc > env-glibc.txt steve@hexa:~/builds/poky/build-master$ grep -E "^SRCREV" env-glibc.txt SRCREV="INVALID" SRCREV_glibc="ae37d06c7d127817ba43850f0f898b793d42aea7" SRCREV_localedef="95c0221703ad970a52445e9eaf91c4aff35eebef" steve@hexa:~/builds/poky/build-master$ bitbake -e bzip2 > env-glibc.txt steve@hexa:~/builds/poky/build-master$ grep -E "^SRCREV" env-glibc.txt SRCREV="INVALID" SRCREV_bzip2-tests="f9061c030a25de5b6829e1abf373057309c734c0" 91981 7 steve 2021-11-11 22:11:46 +0000 The patch attached to this bug does seem to eliminate the glibc issue in both dunfell and master, however it does not fix the bzip2 case in master: steve@hexa:~/builds/poky/build-dunfell$ ../scripts/buildhistory-collect-srcrevs steve@hexa:~/builds/poky/build-dunfell$ steve@hexa:~/builds/poky/build-master$ ../scripts/buildhistory-collect-srcrevs # core2-64-poky-linux SRCREV:pn-bzip2 = "f9061c030a25de5b6829e1abf373057309c734c0" I haven't investigated this further, but wanted to leave a history of my research to date. 91982 8 steve 2021-11-11 22:28:26 +0000 So the bzip2 base package shouldn't have a SRCREV associated with it, since it is built from a tarball: SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz \ git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests;branch=master \ file://configure.ac;subdir=${BP} \ file://Makefile.am;subdir=${BP} \ file://run-ptest \ " SRC_URI[md5sum] = "67e051268d0c475ea773822f7500d0e5" SRC_URI[sha256sum] = "ab5a03176ee106d3f0fa90e381da478ddae405918153cca248e682cd0c4a2269" SRCREV_bzip2-tests = "f9061c030a25de5b6829e1abf373057309c734c0" So this is an odd case where the base package is being built from a tarball and the bzip2-tests are being built from a git repo. I'm not really sure what the right answer is here! It seems like a lot of machinations in build history to deal with two corner cases, but I have zero history (pun intended) with buildhistory so I would love to hear opinions from those more experienced. 92059 9 richard.purdie 2021-11-22 15:40:34 +0000 I have sent a couple of patches to the list which I believe should address this issue and put them in master-next 92063 10 richard.purdie 2021-11-24 10:13:34 +0000 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=96f552377a25f21f24aadb6f326f177d56aa9d73 4750 2020-11-20 08:19:04 +0000 2020-11-20 08:19:04 +0000 Patch to buildhistory.bbclass buildhistory.patch text/plain 1409 ernstp ZGlmZiAtLWdpdCBhL21ldGEvY2xhc3Nlcy9idWlsZGhpc3RvcnkuYmJjbGFzcyBiL21ldGEvY2xh c3Nlcy9idWlsZGhpc3RvcnkuYmJjbGFzcwppbmRleCAxNTYzMjRkMzM5Li4zZjQ0YzdjYWFiIDEw MDY0NAotLS0gYS9tZXRhL2NsYXNzZXMvYnVpbGRoaXN0b3J5LmJiY2xhc3MKKysrIGIvbWV0YS9j bGFzc2VzL2J1aWxkaGlzdG9yeS5iYmNsYXNzCkBAIC05NTAsNyArOTUwLDEyIEBAIGRlZiB3cml0 ZV9sYXRlc3Rfc3JjcmV2KGQsIHBrZ2hpc3RkaXIpOgogICAgICAgICAgICAgICAgICAgICAgICAg dmFsdWUgPSB2YWx1ZS5yZXBsYWNlKCciJywgJycpLnN0cmlwKCkKICAgICAgICAgICAgICAgICAg ICAgICAgIG9sZF90YWdfc3JjcmV2c1trZXldID0gdmFsdWUKICAgICAgICAgd2l0aCBvcGVuKHNy Y3JldmZpbGUsICd3JykgYXMgZjoKLSAgICAgICAgICAgIG9yaWdfc3JjcmV2ID0gZC5nZXRWYXIo J1NSQ1JFVicsIEZhbHNlKSBvciAnSU5WQUxJRCcKKyAgICAgICAgICAgIHBrZyA9IGQuZ2V0VmFy KCdQTicpCisgICAgICAgICAgICBvcmlnX3NyY3JldiA9IGQuZ2V0VmFyKCdTUkNSRVYnLCBGYWxz ZSkKKyAgICAgICAgICAgIGlmIG5vdCBvcmlnX3NyY3JldiBvciBvcmlnX3NyY3JldiA9PSAnSU5W QUxJRCc6CisgICAgICAgICAgICAgICAgb3JpZ19zcmNyZXYgPSBkLmdldFZhcignU1JDUkVWXyVz JyAlIChwa2cpLCBGYWxzZSkKKyAgICAgICAgICAgIGlmIG5vdCBvcmlnX3NyY3JldjoKKyAgICAg ICAgICAgICAgICBvcmlnX3NyY3JldiA9ICdJTlZBTElEJwogICAgICAgICAgICAgaWYgb3JpZ19z cmNyZXYgIT0gJ0lOVkFMSUQnOgogICAgICAgICAgICAgICAgIGYud3JpdGUoJyMgU1JDUkVWID0g IiVzIlxuJyAlIG9yaWdfc3JjcmV2KQogICAgICAgICAgICAgaWYgbGVuKHNyY3JldnMpID4gMToK QEAgLTk2NSw3ICs5NzAsNiBAQCBkZWYgd3JpdGVfbGF0ZXN0X3NyY3JldihkLCBwa2doaXN0ZGly KToKICAgICAgICAgICAgICAgICBmb3IgbmFtZSwgc3JjcmV2IGluIHNvcnRlZCh0YWdfc3JjcmV2 cy5pdGVtcygpKToKICAgICAgICAgICAgICAgICAgICAgZi53cml0ZSgnIyB0YWdfJXMgPSAiJXMi XG4nICUgKG5hbWUsIHNyY3JldikpCiAgICAgICAgICAgICAgICAgICAgIGlmIG5hbWUgaW4gb2xk X3RhZ19zcmNyZXZzIGFuZCBvbGRfdGFnX3NyY3JldnNbbmFtZV0gIT0gc3JjcmV2OgotICAgICAg ICAgICAgICAgICAgICAgICAgcGtnID0gZC5nZXRWYXIoJ1BOJykKICAgICAgICAgICAgICAgICAg ICAgICAgIGJiLndhcm4oIlJldmlzaW9uIGZvciB0YWcgJXMgaW4gcGFja2FnZSAlcyB3YXMgY2hh bmdlZCBzaW5jZSBsYXN0IGJ1aWxkIChmcm9tICVzIHRvICVzKSIgJSAobmFtZSwgcGtnLCBvbGRf dGFnX3NyY3JldnNbbmFtZV0sIHNyY3JldikpCiAKICAgICBlbHNlOgo=