‘guix lint -c archival python-scikit-learn’ crashes

  • Open
  • quality assurance status badge
Details
2 participants
  • Antoine Lambert
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 12 Feb 11:11 +0100
‘guix lint -c archival python-sciki t-learn’ crashes
(address . bug-guix@gnu.org)
87v86uf0uw.fsf@inria.fr
Hi!

Starting from a couple of weeks ago, probably around the time SWH
deployed an updated version of their infrastructure, we get crashes like
this:

Toggle snippet (34 lines)
$ guix describe
Generation 290 Feb 11 2024 23:01:35 (current)
guix c4372f7
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: c4372f7ebfac17236299346fe60c6ca125336b1f
$ guix lint -c archival python-scikit-learn
Backtrace:ython-scikit-learn@1.3.2 [archival]...
12 (primitive-load "/home/ludo/.config/guix/current/bin/gu…")
In guix/ui.scm:
2324:7 11 (run-guix . _)
2287:10 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 8 (for-each #<procedure 7f45354e9400 at guix/scripts/lin…> …)
In guix/scripts/lint.scm:
65:4 7 (run-checkers _ _ #:store _)
In srfi/srfi-1.scm:
634:9 6 (for-each #<procedure 7f4535405d50 at guix/scripts/lin…> …)
In guix/scripts/lint.scm:
74:21 5 (_ _)
In guix/lint.scm:
1662:4 4 (check-archival _)
877:2 3 (call-with-networking-fail-safe _ _ _)
In ice-9/boot-9.scm:
1752:10 2 (with-exception-handler _ _ #:unwind? _ # _)
1685:16 1 (raise-exception _ #:continuable? _)
1683:16 0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" directory)'.

This can be reproduced by merely evaluating:

(lookup-origin-revision "https://github.com/scikit-learn/scikit-learn""1.3.2")

The crux of the problem is that ‘snapshot-branches’ used to return
either a “revision” or a “release”, but now it can also return a
“directory”:

Toggle snippet (19 lines)
$ wget -qO- https://archive.softwareheritage.org/api/1/snapshot/c405490b80fb35cc58b34260d9ec6add8248857f |jq
{
"id": "c405490b80fb35cc58b34260d9ec6add8248857f",
"branches": {
"1.3.2": {
"target": "e4a4be18fae8d9c6528abff3bc9088feb19a76c7",
"target_type": "directory",
"target_url": "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/"
},
"HEAD": {
"target": "1.3.2",
"target_type": "alias",
"target_url": "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/"
}
},
"next_branch": null
}

I’ll check with comrades at SWH whether this is intended.

(Note that this problem may vanish once

Ludo’.
L
L
Ludovic Courtès wrote on 12 Feb 17:04 +0100
No releases/revisions in /snapshot endpoints?
(address . swh-devel@inria.fr)(address . 69070@debbugs.gnu.org)
87il2td5yc.fsf@gnu.org
Dear SWH,

In https://issues.guix.gnu.org/69070 I stumbled upon what might be new
behavior from the /snapshot endpoint:

Toggle quote (22 lines)
> The crux of the problem is that ‘snapshot-branches’ used to return
> either a “revision” or a “release”, but now it can also return a
> “directory”:
>
> $ wget -qO- https://archive.softwareheritage.org/api/1/snapshot/c405490b80fb35cc58b34260d9ec6add8248857f |jq
> {
> "id": "c405490b80fb35cc58b34260d9ec6add8248857f",
> "branches": {
> "1.3.2": {
> "target": "e4a4be18fae8d9c6528abff3bc9088feb19a76c7",
> "target_type": "directory",
> "target_url": "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/"
> },
> "HEAD": {
> "target": "1.3.2",
> "target_type": "alias",
> "target_url": "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/"
> }
> },
> "next_branch": null
> }

Current documentation mentions the ‘target_types’ query parameter, which
I could use to restrict results to “revision” and “release”:


However, that’d be the empty list of the case above.

Other snapshots seem to be missing releases and revisions as well, such
as this one:


Did anything change here? Am I holding it wrong? :-)

Thanks in advance,
Ludo’.
A
A
Antoine Lambert wrote on 12 Feb 17:37 +0100
f11611f7-9f37-42b1-8e58-726d8223ffb0@inria.fr
Hello Ludovic,

The SWH data model also allows for snapshot branches to target simple directories.

The new loaders we implemented to ingest a tarball content (visit type: tarball-directory)
or a directory targeted by a CVS tag or commit (visit types: git-checkout, hg-checkout)
produce such snapshot with a single non alias branch targeting a directory.

We do not produce revisions or releases with these loaders as their purpose is to
archive a single directory (with extid mapping) without any development history.

Antoine Lambert

On 12/02/2024 17:04, Ludovic Courtès wrote:
Toggle quote (43 lines)
> Dear SWH,
>
> In <https://issues.guix.gnu.org/69070> I stumbled upon what might be new
> behavior from the /snapshot endpoint:
>
>> The crux of the problem is that ‘snapshot-branches’ used to return
>> either a “revision” or a “release”, but now it can also return a
>> “directory”:
>>
>> $ wget -qO- https://archive.softwareheritage.org/api/1/snapshot/c405490b80fb35cc58b34260d9ec6add8248857f |jq
>> {
>> "id": "c405490b80fb35cc58b34260d9ec6add8248857f",
>> "branches": {
>> "1.3.2": {
>> "target": "e4a4be18fae8d9c6528abff3bc9088feb19a76c7",
>> "target_type": "directory",
>> "target_url": "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/"
>> },
>> "HEAD": {
>> "target": "1.3.2",
>> "target_type": "alias",
>> "target_url": "https://archive.softwareheritage.org/api/1/directory/e4a4be18fae8d9c6528abff3bc9088feb19a76c7/"
>> }
>> },
>> "next_branch": null
>> }
> Current documentation mentions the ‘target_types’ query parameter, which
> I could use to restrict results to “revision” and “release”:
>
> https://archive.softwareheritage.org/api/1/snapshot/doc/
>
> However, that’d be the empty list of the case above.
>
> Other snapshots seem to be missing releases and revisions as well, such
> as this one:
>
> https://archive.softwareheritage.org/api/1/snapshot/55bda9214f962550baad25026fb3ac3ad12e3eb9/
>
> Did anything change here? Am I holding it wrong? :-)
>
> Thanks in advance,
> Ludo’.

--
Antoine Lambert
Software engineer for Software Heritage
Inria, Paris
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 69070@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 69070
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch