bug#55367: guix refresh fails. struct-vtable: Wrong type argument in position 1 (expecting struct)

[Maxime Devos]

Ludovic Courtès schreef op wo 11-05-2022 om 15:49 [+0200]:
> The code at guix/gnu-maintenance.scm:188:20 checks a URI, so my guess is
> that the source of that package is not a valid URI, and thus
> ‘string->uri’ returns #false.

It's "gogdownloader://world_of_goo/en3installer0".

(string->uri "gogdownloader://world_of_goo/en3installer0")
$1 = #f
(string->uri "gogdownloader://worldofgoo/en3installer0")
$2 = #f

Apparently it doesn't like _ characters.  Makes some sense for http,
https and ftp, but what about other protocols?  Do the Internet RFCs
say anything about this?

Worse, looks like non-ASCII characters (that are valid DNS names, at
least ignoring punycode encodings and such) aren't supported:

(string->uri "https://www.étoile.fr";)
$3 = #f

though maybe that's due to the URI -- IRI distinction.  Even then, not
supporting IRIs (even if in a separate module or such) seems like quite
a limitation.  (What does Guile aim to implement -- the strict version
of URIs, or the more general IRIs, sometimes just named URIs?)

However, non-ASCII in 'path' is supported:

(string->uri "https://etoile.fr/étoile.html";)

#<<uri> scheme: https userinfo: #f host: "etoile.fr" port: #f path: 
"/étoile.html" query: #f fragment: #f>

Seems a bit arbitrary to me ...
I guess 'top-level-regexp' and 'domain-label-regexp' might need to be adjusted.

Though there's a comment

;; See RFC 3986 #3.2.2 for comments on percent-encodings, IDNA (RFC
;; 3490), and non-ASCII host names.

in the Guile module ... maybe we want IRIs instead?

Greetings,
Maxime.

signature.asc
Description: This is a digitally signed message part