| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
Store the location a package can be found at, and display this on the package
page.
If available, link off to the git repository containing the package.
|
| | |
|
| |
|
|
|
| |
Lower powered devices will have problems displaying all ~9000+ packages, so
return a smaller number by default.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, the routing layer handled the content negotiation, and the Accept
header was ignored. Now, the extension if one is provided in the URL is still
used, and more widely than before, but the Accept header is also taken in to
account.
This all now happens before the routing decisions are made, so the routing is
now pretty much extension independant (with the exception of the
/gnu/store/... routes).
|
| |
|
|
|
| |
This adds more query parameter validation, and uses form-horizontal-control to
neaten up the view code.
|
| |
|
|
|
|
| |
Add handling for some query parameters to the branch page. This takes
advantage of the improvements for building forms and query parameter
validation.
|
| |
|
|
|
|
|
|
|
| |
The query parameters feed in to the results shown, but also forms on
pages. Validation is important to avoid errors and security issues, but it's
also important to provide appropriate feedback to the user.
This module provides some utilities and structure around handling query
parameters.
|
| |
|
|
|
|
| |
Add some new pages /branches and /branch/... as well as a new git_branches
table. Also extend the email processing to enter the branch information in to
the database.
|
| |
|
|
|
|
| |
Rather than just storing the URL in the guix_revisions and
load_new_guix_revision_jobs tables. This will help when storing more
information like tags and branches in the future.
|
| |
|
|
| |
To show the total number of derivations, and guix revisions.
|
| | |
|
| |
|
|
|
| |
Add support for filtering the results, and add the system and target
to the output.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A large proportion of these changes relate to changing the way
packages relate to derivations. Previously, a package at a given
revision had a single derivation. This was OK, but didn't account for
multiple architectures.
Therefore, these changes mean that a package has multiple derivations,
depending on the system of the derivation, and the target system.
There are multiple changes, small and large to the web interface as
well. More pages link to each other, and the visual display has been
improved somewhat.
|
| | |
|
| | |
|
| |
|
|
| |
For showing more information about builds, revisions and derivations.
|
| |
|
|
| |
On the comparison page.
|
| | |
|
| | |
|
| |
|
|
|
| |
The primary use I have in mind for this is producing a list of strings
suitable for building a limited Cuirass job with.
|
| |
|
|
|
|
| |
Provide JSON versions of the existing HTML compare and
compare/derivations pages. Refactor the code and extract some
functions to make this a little less painful.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Previously, the connections were not closed, so eventually PostgreSQL
would run out. Using a pool of connections would be better, but as a
short term solution, just close the connection after each request.
|
|
|
This is a service designed to provide information about Guix. At the
moment, this initial prototype gathers up information about packages,
the associated metadata and derivations.
The initial primary use case is to compare two different revisions of
Guix, detecting which packages are new, no longer present, updated or
otherwise different.
It's based on the Mumi project.
[1]: https://git.elephly.net/software/mumi.git
|