This is better, as Cuirass will return a build for the derivation it built to
generate that output. This avoids having to query for multiple derivations
that generate a single output, until the one that Cuirass used is found.
Rather than expecting it always to be "guix", store the expected value in the
database, and use the value of the header to find the relevant repository.
This was copied over from Mumi, but I've noticed some styling issues with
lists, and I'm not sure how well it interacts with Bootstrap. Simpler is
better, so lets just try removing it.
The packages comparison was getting confused by differences in the
derivations, so split the data used to make the comparison more sensible.
This resolves an issue comparing 8dd723f5… and 365892e9… which coinsided with
the fix for importing foreign architecture derivations, meaning that a whole
lot of new derivations appeared in the database. Prior to these changes, it
appeared like every package was new, and with these changes, the list is more
sensible.
This seems to work better for both generating the non-cross and cross
derivations. Previously, using the package-transitive-supported-systems
approach didn't generate some cross derivations.
Use the second argument to package-transitive-supported-systems to correctly
identify the different bootstrap path for non x86_64 and i686-linux. The
previous implementation did work, but only up until a merge of core-updates
changed the bootstrap approach.
If the file exists in the local store, then read it and add an entry to the
derivation_source_file_nars table. This will help to fill in the missing
entries, as currently entries are only added when the derivation source file
isn't in the database when the load new revision job runs.
It's more accurate to describe the specifics of the relevant data here through
terms like "matching" and "not matching", as a statement that something built
reproducibility needs to be made alongside the test conditions. So just say
that build outputs matched, or didn't match, as this is more descriptive of
the data available.