| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
Hopefully this will help with the pg_restore in the create-small-backup
script:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2875; 0 0 COMMENT EXTENSION plpgsql
pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql
Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
|
|
|
|
| |
This greatly improves the performance of the derivation-outputs page.
|
|
|
|
| |
Otherwise this table is empty.
|
|
|
|
| |
Otherwise this table is empty.
|
|
|
|
| |
This was redundant and slow, so don't do it.
|
|
|
|
|
|
| |
The derivation checker currently opens a store connection on its own, but by
passing the already open connection in, it won't have to do that, and
hopefully this will make checking all the packages faster.
|
|
|
|
| |
It's been replaced by the package_derivations_by_guix_revision_range table.
|
|
|
|
|
|
|
|
|
| |
Rather than having two big tables looking at the history, just use the
derivations table as it has all the information.
This will allow deleting the package_versions_by_guix_revision_range table
which should help save time when importing revisions, and reduce the size of
the database.
|
| |
|
|
|
|
|
| |
This might solve errors where the Guix Data Service is trying to insert a
lint_warning_message_set that already exists.
|
|
|
|
| |
Rather than having an empty table.
|
|
|
|
| |
Put the non-cross built derivations first.
|
|
|
|
|
|
|
| |
This complements the existing pages for the version history, and derivation
history. As well as the new page, the buttons and styling of the two existing
pages has been made to match better to enable easier navigation between the
pages.
|
|
|
|
|
| |
Similar to the one above for derivations, this just looks at outputs. This
filters out equivalent derivations, which can be useful.
|
| |
|
|
|
|
|
| |
These parts of the backup scripts are optional, so don't fail if they don't
work.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Move it after the output relating to narinfo signing, and include the host.
|
|
|
|
| |
As this could be a common problem.
|
|
|
|
| |
Render some HTML rather than the plain response.
|
|
|
|
|
| |
Adjust the previously unused error page code, and start to use it. Only show
the error if configured to do so, to avoid leaking secret information.
|
|
|
|
|
| |
To increase the likelyhood that all the builds and narinfo files for the
latest revisions are fetched.
|
|
|
|
| |
Pulling out the recent entries first.
|
|
|
|
| |
As it makes it clearer what tables will be truncated.
|
| |
|
| |
|
|
|
|
|
| |
Rather than looking for the oldest unknown outputs, as the new ones are
generally more useful.
|
| |
|
| |
|
|
|
|
| |
Update this by copying the code from Guix again.
|
| |
|
| |
|
|
|
|
|
| |
Some builds from Cuirass change status at the same timestamp, so use the id
for ordering instead.
|
| |
|
|
|
|
|
| |
This makes it possible to set a higher or lower value depending on what you
want.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
To help with getting them running on Guile 3.
|
|
|
|
| |
By including a backtrace.
|
|
|
|
| |
So that the load-new-guix-revision tests work with Guile 3.
|
|
|
|
|
| |
This is relevant, as it prevents the mock function used in tests working with
Guile 3.
|
| |
|
| |
|
|
|
|
| |
I think this might help with getting relevant stack traces.
|
| |
|
|
|
|
|
| |
As I forget why I even added it. I'm sure it was to try and make test failures
more understandable, but I'm not sure it worked.
|
| |
|