[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’.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Preservation of Guix report for 2024-01-26,
Ludovic Courtès <=