Re: Cuirass: "lint -c archival"?

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]


zimoun <zimon.toutoune@gmail.com> 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] <https://ci.guix.gnu.org/metrics>
>
> 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.
>
> WDYT?

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
package.

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]).

1: https://data.guix.gnu.org/gnu/store/5h4dz6ild4fkida5yfv5fhh59vfd8hvk-python-boolean.py-3.6-checkout

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.

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]