guix-devel
[Top][All Lists]
Advanced

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

Re: Preservation of Guix report for 2024-01-26


From: Ludovic Courtès
Subject: Re: Preservation of Guix report for 2024-01-26
Date: Tue, 06 Feb 2024 15:44:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Hello!

Timothy Sample <samplet@ngyro.com> skribis:

> I sent https://issues.guix.gnu.org/68769.  Now I see that I didn’t have
> the newest Git hooks installed, so no change ID and no email to the
> relevant team.  Sorry!  (I use worktrees so the Makefile didn’t fix this
> for me automatically – I should have double checked.)

Impressive stuff.

>> We’ll also have to sync the disarchive.guix.gnu.org with ngyro.com.
>
> Hopefully our old system will work again, but I will have to consolidate
> my collection of Disarchive specifications, first.

Please let me/sysadmins know when and how we should run rsync to grab
new stuff from your database.

(We could also set up an infrequent rsync job if that makes sense.)

> I mean the PoG “project”.  Instead of just testing and reporting, it
> will preserve.  For instance, right now if it encounters a tarball that
> Disarchive can’t unpack, it shrugs and moves on.  I want it to store
> those so that we are guaranteed to be able to revisit it in the future.
> Same thing for sources not (yet) in SWH.  I want to store those so that
> SWH can ingest them later.  Because we are doing so well working with
> SWH, the storage requirements for this will be manageable (10s of
> gigabytes).  With that in place, the PoG report will simply explain what
> the archive needs to store and why.  Our goal, then, will be for it to
> store nothing.

That makes a lot of sense to me.  I’m not sure how to implement it but
you certainly have ideas.

Thanks,
Ludo’.



reply via email to

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