This recent change simply didn't work, the ordering was bad and the window
function wasn't properly defined. It now should hopefully work, although
there's an interesting case where different versions are available for
different systems/targets, which isn't handled particularly well.
This is better than just deleting the entries that don't match up with the
remaining revisions, but also not very useful for local development (due to
the lack of data).
Previously, the select option label was empty that's not particularly
informative. These changes also fix the next page link behaviour for the
target parameter.
Actually check if fields can be NULL, and if they can be then include some
extra conditions for the comparison.
This will at least make the queries smaller, I'm not sure if it will have an
effect on performance.
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';
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.
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 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.
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.
