The hashes shown look correct. Can you explain the problem that you see in more detail?

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.

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.

Created attachment 4750 [details]
Patch to buildhistory.bbclass

Here's one way to solve it

Not enough time to make it into 3.1.12

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"

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.

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.

I have sent a couple of patches to the list which I believe should address this issue and put them in master-next

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=96f552377a25f21f24aadb6f326f177d56aa9d73