On Wed, 2022-04-27 at 12:39 +0200, Jacob Kroon wrote: > On 4/27/22 12:12, Richard Purdie wrote: > > On Wed, 2022-04-27 at 11:06 +0200, Jacob Kroon wrote: > > > Hi Richard and Joshua, > > > > > > When using hash equivalency, since commits > > > > > > https://git.openembedded.org/openembedded-core/commit/?id=d6c7b9f4f0e > > > https://git.openembedded.org/openembedded-core/commit/?id=1cf62882bba > > > > > > scrambling a header in one of the gcc patches causes all target packages > > > to rebuild. > > > > That is probably unfortunately inevitable. If the output has changed (i.e. > > the > > headers are different), it shouldn't be matching a previous build as we > > can't > > know what has changed. > > > > I don't think I was being clear enough. With "scrambling a header in a > gcc patch" I mean that I change something in the section before the > "---" line in a .patch file, like modifying the "Upstream-Status" line. > To me, hash equivalence should be able to optimize that scenario, since > the output from building gcc-cross is not changed.
That definitely wasn't clear! I now understand better what you mean and yes, we're supposed to be optimising that scenario. > > > > This is because the depsig.do_populate_sysroot in "libgcc" > > > changes: > > > > > > > [jkroon@fedora work]$ diff -u > > > > i686-oe-linux/libgcc/11.3.0-r0/temp/depsig.do_populate_sysroot.1* > > > > > > > > > > > > > > > > --- > > > > i686-oe-linux/libgcc/11.3.0-r0/temp/depsig.do_populate_sysroot.1589812 > > > > 2022-04-27 10:14:22.403251775 +0200 > > > > > > > > > > > > > > > > +++ > > > > i686-oe-linux/libgcc/11.3.0-r0/temp/depsig.do_populate_sysroot.1674014 > > > > 2022-04-27 10:26:45.329365448 +0200 > > > > > > > > > > > > > > > > @@ -1,7 +1,7 @@ > > > > > > > > > > > > > > > > > > > > OEOuthashBasic > > > > > > > > > > > > > > > > > > > > 12 > > > > > > > > > > > > > > > > > > > > glibc: > > > > 8feab297dd38b103daa4f26eeabb5690a74b8b5700d16e4eca7b56e6fd667a5e > > > > > > > > > > > > > > > > > > > > -libgcc: > > > > dfd38409a4cc5320b781edc14de2af8321180c3f194a58b798870ad7ff6a9226 > > > > > > > > > > > > > > > > > > > > +libgcc: > > > > 195f6a155dac8e450e72a7432ab91959a8e095e057d5b79e3adba41721dc7ea5 > > > > > > > > > > > > > > > > > > > > linux-libc-headers: > > > > 12a5aaf8aec9554ac3c778cdc6c65df4db52fc573e84b7110572d459a15c9d6a > > > > > > > > > > > > > > > > > > > > SSTATE_PKGSPEC=sstate:libgcc:i686-oe-linux:11.3.0:r0:i686:8: > > > > > > > > > > > > > > > > > > > > task=populate_sysroot > > > > > > Is it the case that it is the dependent task hashes that are added > > > above, and that the checksum of patches are included in the those task > > > hashes ? > > > > The dependent resolved hashes are used, as resolved by hashequiv which is a > > key > > difference. > > > > So it is the outhashes that are listed above? No, they are hash equiv resolved hashes which would have a one to one mapping with an outhash. > Then I don't understand > the diff above. libgcc depends on itself ? But apparently no files in > the sysroot changed, since the above is the only diff I get. To be honest, I don't remember/understand offhand either. I'd need to go and spend time trying to page in all the information. We have too few people with the knowledge in these areas and I'm rapidly burning out. I don't like this reply but I just don't have the time to dive into it and debug it right now and I can't really give much more of a helpful comment/reply without doing so. I agree there is some issue here which does need investigation. At least do file a bug so it doesn't get forgotten but we don't have many people taking on bugs either. This one would get triaged to me or Joshua. I'd also add that gcc is pretty horrific in that it bundles up a lot of it's build tree into the sysroot. It is possible those bundled files are varying somehow reproducibility wise causing some instability. I've worried about this kind of issue for a while but I don't scale and there are a load of other issues going on too :(. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1530): https://lists.openembedded.org/g/openembedded-architecture/message/1530 Mute This Topic: https://lists.openembedded.org/mt/90726763/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
