[Top][All Lists]

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

Re: Cuirass: "lint -c archival"?

From: Christopher Baines
Subject: Re: Cuirass: "lint -c archival"?
Date: Thu, 24 Sep 2020 20:06:00 +0100
User-agent: mu4e 1.4.13; emacs 26.3

zimoun <> writes:

> Does it make sense to add "lint -c archival" when a package is built
> by Cuirass?  Or on the Guix Data Services?
> The idea behind is then to ask SWH folks to increase the rate limit
> for a specific IP (or couple of IPs).  Today, the SWH rate is 10 save
> requests per hour, i.e., 240 per day (more or less).  And the new
> chart [1] shows that there are ~2000 builds per day.  Ouch! :-)
> [1] <>
> If it is not possible, then instead does it make sense to add a script
> to etc/?  If SWH accepts to increase the rate for a specific machine,
> the script (fold-packages+save-origin) could run with some delay and
> save all the missing Git references.
> Well, I do not know what the GitLab CI in Bordeaux is doing?  About
> Guix packages because there are already some things saving requests
> automatically, I guess.

So, my understanding is that Software Heritage is a potential store for
source material for Guix packages. I think the majority of builds
Cuirass does are because inputs change, rather than the source of a

I'm not sure hooking this up to Cuirass would make the most sense,
because of the above point.

Also, unfortunately, the Guix Data Service doesn't have the ideal data
for this, as it doesn't really store the package source information in
the way that would be useful for this.

Personally though (and I'm rather biased), I think the Guix Data Service
might still be an approach. If you take the view on this that the
Software Heritage is a means to a store item (which I think is right?),
the Guix Data Service knows about those store items (like [1]).


It's already storing if substitute servers have a nar for that store
item, so I don't think storing if it's available elsewhere is
particularly out of place.

To make the information actionable though, it would be necessary to
store more information about the sources for packages in the Guix Data
Service database.

This is much more work than just using the existing linter, but it does
have the advantage that you'd be able to look at coverage statistics and
things like that, which the checker doesn't really afford.


Attachment: signature.asc
Description: PGP signature

reply via email to

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