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,That is probably unfortunately inevitable. If the output has changed (i.e. the
When using hash equivalency, since commits
scrambling a header in one of the gcc patches causes all target packages
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.
This is because the depsig.do_populate_sysroot in "libgcc"The dependent resolved hashes are used, as resolved by hashequiv which is a key
[jkroon@fedora work]$ diff -u i686-oe-linux/libgcc/11.3.0-r0/temp/depsig.do_populate_sysroot.1* Is it the case that it is the dependent task hashes that are added
--- 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 @@
above, and that the checksum of patches are included in the those task
So it is the outhashes that are listed above ? 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.
In order to solve the original problem that those patches were fixing,Since the resolved hashes should map to a single outhash, I don't think it would
would it not be possible to instead include the *outhashes* of the
dependent recipes ?