| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
Rather than just the native system. I'm not quite sure of the value here, as I
guess system tests should behave the same regardless of the way the software
is compiled, but this seems like it could be useful, and being explicit about
the system the derivation is for is good.
|
| |
|
|
|
| |
The switch away from catch broke this, I obviously still don't quite get how
with-exception-handler works. Therefore, use it twice as that seems to help.
|
| | |
|
| |
|
|
|
|
|
| |
I think there's still the potential for a race condition when working with the
cached checkout of the repository, but this lock was far too wide. The
sensitive section is just the latest-channel-instances call, as it adds the
relevant files to the store, and that's what's returned.
|
| |
|
|
| |
By including a backtrace.
|
| |
|
|
| |
So that the load-new-guix-revision tests work with Guile 3.
|
| | |
|
| |
|
|
|
| |
With Guile 3, there's a potential for mock to work in even fewer
circumstances. So, adapt the code to enable writing the tests without mock.
|
| |
|
|
| |
In the load-new-guix-revision module.
|
| | |
|
| |
|
|
| |
To simplify both procedures.
|
| |
|
|
|
|
| |
Switch to using a sequence for the ids in the log parts table, and spawn a
thread to listen for output from the inferior processes, and enter it in to
the database.
|
| | |
|
| | |
|
| |
|
|
| |
So that the tests don't require a store connection.
|
| | |
|
| |
|
|
|
| |
As this will enable registering temporary roots, to avoid store items being
garbage collected.
|
| |
|
|
| |
These are the ones that relate to Guix pull.
|
| |
|
|
| |
As this is neater.
|
| |
|
|
|
|
|
|
| |
Yet again...
This makes the channel-derivations for each system accessible within the
load-new-guix-revision procedure, in preparation for storing them in the
database.
|
| | |
|
| |
|
|
| |
These aren't stored yet, but this is a start.
|
| |
|
|
| |
To reduce the line length.
|
| | |
|
| |
|
|
|
| |
To avoid race conditions between jobs, have it happen after the call to
extract-information-from.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using the system values as targets, and remove package derivation entries
where this is the case.
Switch the non-cross derivation case to have a target of "", rather than
matching the system, as this makes more sense, and is more consistent now that
the target values no longer match the system values.
Hardcode some more correct target values, and use these instead. Hopefully
this can be better integrated with Guix in the future.
This commit also includes a migration attempting to shrink some indexes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In an attempt to stop the derivations from being garbage collected between the
time they're generated, and when they're potentially read by the Guix Data
Service.
|
| |
|
|
| |
Extract out a function to make the code slightly easier to read.
|
| |
|
|
|
|
|
|
|
|
| |
Previously this would just compare on the version if the name was the same,
but there are package definitions that share the name and version (itstool is
one example).
To try and make this more stable, to avoid weird errors, and unstable
comparisons between revisions, use the line number when deduplicating
packages.
|
| |
|
|
|
|
| |
I think this might be happening when packages are filtered out as
duplicates (by name and version), but then a reference to a duplicate occurs
somewhere, like in a lint warning.
|
| | |
|
| |
|
|
| |
To make it easier to see what recently happened.
|
| |
|
|
| |
To help identify what's taking the most time.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
That were missing them.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
... entries in to a separate module, to split the code up a little further.
|
| |
|
|
| |
This worked fine in a REPL, but here it seems the module needs to be passed.
|
| |
|
|
|
| |
As this will hopefully provide a faster way of associating derivations with
builds.
|
| |
|
|
|
|
|
| |
Previously, all the entries for the branch were deleted, but not, only the
entries for the branch, that are present in the revision that was loaded will
be deleted. This is more efficient, as it avoids deleting and recreating
entries in the table that shouldn't have changed.
|
| |
|
|
| |
If the channel-news-for-commit function is present.
|
| |
|
|
| |
To allow for using the guix-revision-id when inserting channel news entries.
|
| |
|
|
| |
To allow for passing the channel to channel-news-for-commit.
|