[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More progress with the Guix Data Service

From: Ludovic Courtès
Subject: Re: More progress with the Guix Data Service
Date: Mon, 20 May 2019 17:20:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)


Christopher Baines <address@hidden> skribis:

> Since then, I've made some more progress. There's a new statistics page
> [2]. I've got used to using Sqitch [3] to help manage the database
> schema, and I've added some basic tests.

The URL for [2] is actually:

(with an ‘s’.)  See, I paid attention!   ;-)

> As well as listening to the Guix Commits mailing list for emails about
> new revisions, more of the information in these emails is now stored, in
> particular, the time they were sent, and the branch the email applies
> to. This can be seen on the new Branches page [4].
> 4:

This is really nice.

This information could also be gathered directly from the repo though,

I would expect only patch submission info, and possibly commit
notifications, to be grabbed from email, while the rest would be
extracted from the repo, thereby hopefully limiting the risk of
misinterpreting email.  WDYT?

> There's now a basic search function on the packages page [5], and the
> location, and the licenses for packages is now being stored (which can
> be seen on the page for a package, for example [6]).
> 5: 
> 6: 


One thing that be great is a page similar to
but keyed by package, where you get a list of the recent package
versions (and/or derivations) and map them to specific commits.

> The URL is a bit long, but I think that is now close to being possible
> with the Guix data service. I haven't got something working yet to
> easily access data for the latest revision, but for a particular
> revision, you can request a JSON file containing all the information I
> think Repology currently gets about all packages. For example:

Awesome.  (I advise passing “limit_results=900” though, because the URL
above gives a pretty big result.  ;-))

> This is just the software side of the problem though. If this was to be
> used by Repology, it would have to be a more permanent thing, similar to
> the Cuirass and Mumi services that are currently setup around Guix. Does
> anyone have any thoughts on this?

I’d suggest having a Guix service for the whole thing, and making a
branch in guix-maintenance.git such that bayfront (say) can run the

Then we’ll have to reach consensus on guix-sysadmin as to which machine
to use depending on the resources it needs, but if you have the config,
I’d argue that we can happily run it on bayfront or perhaps berlin.  And
we can give you access to the machine so you can reconfigure once in a



reply via email to

[Prev in Thread] Current Thread [Next in Thread]