--- Begin Message ---
|
Subject: |
[PATCH] Fixes init of #42162: gforge.inria.fr down Dec. 2020 |
|
Date: |
Wed, 16 Sep 2020 10:14:11 +0200 |
Dear,
The first message in [1] explains the concrete issue. To avoid to pollute the
already long thread discussing long term Tarball Archiving (which will not be
ready before the down), here is sent patches fixing the concrete issue.
Aside, note that the tarballs should be now ingested by Software Heritage via:
https://archive.softwareheritage.org/browse/search/?q=https%3A%2F%2Fguix.gnu.org%2Fsources.json&with_visit=true&with_content=true
but the issue is to reach them; well see [2].
>From [1], the non-archived packages (yet) are:
--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,pp (lset-difference eq? $7 $8)
$11 = (
#<package r-spams@2.6-2017-03-22 gnu/packages/statistics.scm:3931
7f632401a640>
#<package mpfi@1.5.4 gnu/packages/multiprecision.scm:158 7f632ee3adc0>
#<package gf2x@1.2 gnu/packages/algebra.scm:103 7f6323ea1280>
#<package gmp-ecm@7.0.4 gnu/packages/algebra.scm:658 7f6323eb4960>
#<package cmh@1.0 gnu/packages/algebra.scm:322 7f6323eb4dc0>)
--8<---------------cut here---------------end--------------->8---
However, some have migrated to gitlab:
- r-spams
<https://gitlab.inria.fr/thoth/spams-devel>
- gf2x
<https://gitlab.inria.fr/gf2x/gf2x>
- cmh
<https://prod-gitlab.inria.fr/cmh/cmh>
Note that repackage 'r-spams' from the Git checkout needs some love and is not
straightforward. (Not tried yet the 2 others).
The aim of switching the 2 packages from 'url-fetch' to 'svn-fetch' is
twofolds, test case for improving:
- "guix lint -c archival" (support 'svn' and 'hg')
- the fallback to SWH (for non-git VCS source)
WDYT?
[1]: <http://issues.guix.gnu.org/issue/42162>
[2] <https://forge.softwareheritage.org/T2430>
All the best,
simon
PS:
I am not sure how to deal with <control@debbugs.gnu.org> to "clone" (split)
the bug #42162. That's why this one. :-)
zimoun (2):
gnu: mpfi: Replace 'url-fetch' by 'svn-fetch'.
gnu: gmp-ecm: Replace 'url-fetch' by 'svn-fetch'.
gnu/packages/algebra.scm | 28 +++++++++++++++++++++-------
gnu/packages/multiprecision.scm | 13 ++++++++-----
2 files changed, 29 insertions(+), 12 deletions(-)
base-commit: f5163902d7c3cfed5a97033f38e92d7158b19fa8
--
2.28.0
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#43442: Code stored with Subversion (SVN) cannot be retrieved from SWH |
|
Date: |
Sat, 09 Mar 2024 23:34:24 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Ludovic Courtès <ludovic.courtes@inria.fr> skribis:
> The attached patch does that:
>
> scheme@(guile-user)> (lookup-subversion-revision
> "https://scm.gforge.inria.fr/anonscm/svn/mpfi"; 680)
> $12 = #<<revision> id: "72102de7605a2459ebcb016338ebbf1a997e8c8d" date:
> #<date nanosecond: 938388 second: 35 minute: 32 hour: 11 day: 6 month: 9
> year: 2018 zone-offset: 0> directory:
> "5c89c025a4cd9d16befdfec12dfc23f7318d0d5b" directory-url:
> "https://archive.softwareheritage.org/api/1/directory/5c89c025a4cd9d16befdfec12dfc23f7318d0d5b/";
> parents-ids: ("16da41f1848d77a93aec565320b72b460c429b61") extra-headers:
> (("svn_repo_uuid" . "e2f78e0c-bb60-4709-9413-9660a31d4696") ("svn_revision" .
> "680"))>
> scheme@(guile-user)> (lookup-subversion-revision
> "https://scm.gforge.inria.fr/anonscm/svn/mpfi"; 666)
> $13 = #<<revision> id: "148eb1e7206b111af4075c73c656e54c9efed6cb" date:
> #<date nanosecond: 654167 second: 2 minute: 52 hour: 12 day: 2 month: 8 year:
> 2018 zone-offset: 0> directory: "ed7b0bd7019fb85cd86d948a97c23b9d43aa8728"
> directory-url:
> "https://archive.softwareheritage.org/api/1/directory/ed7b0bd7019fb85cd86d948a97c23b9d43aa8728/";
> parents-ids: ("0ba2aa7e0d3fc0a1eb3ba72b32094515415ae47a") extra-headers:
> (("svn_repo_uuid" . "e2f78e0c-bb60-4709-9413-9660a31d4696") ("svn_revision" .
> "666"))>
>
> The implementation is pretty bad though, because it walks the revision
> history until it finds the right revision number—so you’re likely to
> reach the bandwidth rate limit before you’ve found the revision you’re
> looking for.
>
> More importantly, most svn origins cannot be found, or at least not
> by passing the URL as-is:
>
> https://sympa.inria.fr/sympa/arc/swh-devel/2023-03/msg00009.html
>
> This whole hack looks like a dead end.
>
> It would be ideal if SWH would compute nar hashes, as you proposed:
>
> https://gitlab.softwareheritage.org/swh/meta/-/issues/4538
Happy to report that this is solved with nar-sha256 ExtIDs at SWH, which
commit 0e73f933b291c7e154c7e019b6de1e2f3a97e4c1 uses to implement the
SWH fallback for Subversion checkouts. Wo0t!
Ludo’.
--- End Message ---