GNU bug report logs -
#55367
guix refresh fails. struct-vtable: Wrong type argument in position 1 (expecting struct)
Previous Next
Full log
Message #14 received at 55367 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, inline)]
This bug report was last modified 74 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.