all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: Timothy Sample <samplet@ngyro.com>
Cc: guix-devel@gnu.org
Subject: Re: Preservation of Guix report for 2024-01-26
Date: Mon, 29 Jan 2024 18:16:11 +0100	[thread overview]
Message-ID: <87zfwokqlg.fsf@gnu.org> (raw)
In-Reply-To: <87a5oq8esg.fsf@ngyro.com> (Timothy Sample's message of "Sat, 27 Jan 2024 18:47:27 -0600")

Hi Timothy!

Timothy Sample <samplet@ngyro.com> skribis:

> The permalink is https://ngyro.com/pog-reports/2024-01-26, but you can
> link to the latest report, too: https://ngyro.com/pog-reports/latest/.

Yay!

> New in this edition is checking for Subversion sources and
> bzip2-compressed tarballs.  Subversion is well covered (98.5%), since it
> is basically asking, “is TeX Live in SWH?”.  The bzip2 sources are
> similar to other compressed tarballs.

Thumbs up on bzip2 support!  We should update Disarchive in Guix but
perhaps that’s already in your pipeline?  We’ll also have to sync the
disarchive.guix.gnu.org with ngyro.com.

How did you implement the Subversion check?

Until the recent addition of ‘nar-sha256’ ExtIDs¹, my understanding is
that there was no way to check whether a Subversion revision (and
actually, a specific sub-directory checkout) was in SWH.

¹ https://issues.guix.gnu.org/68741

>   Some of these (I didn’t check them all) are in SWH as content rather
>   than directories.  That’s kinda good, because Guix knows how to get
>   them, but also kinda mysterious.  I’ve asked swh-devel about it.
>   Depending on the answer, I might have to adapt the checks to deal with
>   the possibility of SWH having the tarball rather than its contents.
>   In fact, that might be an improvement either way, but it muddies the
>   data model quite a bit.

Back in the day, they told me that tarballs can sometimes be ingested,
for instance if they are committed to a VCS repo (that’s why our
fallback code tries that as well).  Maybe that’s what happened?

> The short-term road map for this is to send the historical sources to
> SWH and fix the Ruby gems, and then make a new report.  So expect a
> minor update with much better numbers soon-ish.

Awesome.

> The long-term road map is to make it work like an archive.  It will run
> continuously and store *all* Guix sources.  To make this easy data-wise,
> it will only store what’s not covered by SWH.

By “it”, you mean the Disarchive DB?

Thanks for the exciting news!

Ludo’.


  reply	other threads:[~2024-01-29 17:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-28  0:47 Preservation of Guix report for 2024-01-26 Timothy Sample
2024-01-29 17:16 ` Ludovic Courtès [this message]
2024-01-30 18:01   ` Timothy Sample
2024-02-06 14:44     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zfwokqlg.fsf@gnu.org \
    --to=ludovic.courtes@inria.fr \
    --cc=guix-devel@gnu.org \
    --cc=samplet@ngyro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.