| Commit message (Collapse) | Author | Age |
... | |
| |
|
|
|
|
| |
The ordering could flip around, so fix it better.
|
|
|
|
|
| |
The reset.css stylesheet led to this behaviour, so override Bootstrap here to
bring it back.
|
|
|
|
|
| |
This was useful with the reset.css stylesheet, but now that has been removed,
remove this too.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
In backfill-derivation-source-file-nars.
|
|
|
|
|
|
| |
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 nar file is available.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is useful as stexi->shtml uses *ENTITY* so handling this here means that
the HTML output for texinfo is better.
|
|
|
|
| |
For derivation_source_files.
|
|
|
|
| |
This means it returns ids properly.
|
| |
|
|
|
|
| |
In preparation for also handling derivation source files.
|
| |
|
|
|
|
| |
This'll allow serving nars for these derivation source files.
|
|
|
|
| |
This will allow serving the nars for derivation source files.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
| |
From the revision page.
|
| |
|
| |
|
|
|
|
| |
Show multiple builds, and link to the build page.
|
| |
|
| |
|
|
|
|
|
| |
This makes assumptions about the return value of the provided procedure, and
fails if it doesn't return a list.
|
|
|
|
| |
It should have been changed to 4 when the builds column was added.
|
| |
|
| |
|
|
|
|
| |
That were missing them.
|
| |
|
|
|
|
|
| |
This should be the last piece of the puzzle for providing substitutes for
derivations.
|
| |
|
|
|
|
|
| |
This replicates the store item references for the derivation, through looking
up the inputs which the derivation references, and also the sources.
|
| |
|
|
|
|
|
| |
They should be the same, but it seems more sensible to return the value from
the database.
|
|
|
|
|
|
| |
This is to aid rendering of narinfo files. They're requested with the path
/HASH.narinfo, so to quickly find the relevant derivation, this index can be
used.
|
| |
|
|
|
|
|
| |
In the same manor that Guix publish does. This is working towards being able
to serve substitutes for derivations.
|
| |
|
| |
|
|
|
|
|
|
| |
This effectively duplicates the behaviour in Guix for serializing derivations,
but this uses the database representation in the Guix Data Service, rather
than the records Guix uses.
|
|
|
|
| |
This affects the formatted derivation output.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, they were nix-base32-string encoded, but the representation in the
derivations is base16, so it doesn't make sense to use a different
representation in the database.
Therefore, add some code that runs before the start of each job to convert the
data in the database. It was easier to do this in Guile with the existing
support for working with these bytevector representations. After some
migration period, the code for converting the old hashes can be removed.
|
|
|
|
|
|
| |
Both in terms of the code fetching the data from the database, as well as the
formatted and detail outputs. This corrects an error in the formatted output
for derivations where inputs would be duplicated.
|