GNU bug report logs -
#43442
Code stored with Subversion (SVN) cannot be retrieved from SWH
Previous Next
Reported by: zimoun <zimon.toutoune <at> gmail.com>
Date: Wed, 16 Sep 2020 08:15:01 UTC
Severity: important
Tags: patch
Done: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 09 Mar 2024 23:34:24 +0100
with message-id <87ttlfyqz3.fsf_-_ <at> gnu.org>
and subject line Re: bug#43442: Code stored with Subversion (SVN) cannot be retrieved from SWH
has caused the debbugs.gnu.org bug report #43442,
regarding Code stored with Subversion (SVN) cannot be retrieved from SWH
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
43442: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43442
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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 <at> 2.6-2017-03-22 gnu/packages/statistics.scm:3931 7f632401a640>
#<package mpfi <at> 1.5.4 gnu/packages/multiprecision.scm:158 7f632ee3adc0>
#<package gf2x <at> 1.2 gnu/packages/algebra.scm:103 7f6323ea1280>
#<package gmp-ecm <at> 7.0.4 gnu/packages/algebra.scm:658 7f6323eb4960>
#<package cmh <at> 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 <at> 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
[Message part 3 (message/rfc822, inline)]
Ludovic Courtès <ludovic.courtes <at> 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’.
This bug report was last modified 1 year and 71 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.