bug#42601: Guix install bug: error: Unbound variable: ~S

[Jan Wielkiewicz]

Dnia 2020-08-05, o godz. 22:33:14
Ludovic Courtès  napisał(a):

> My bad, I believe this is fixed by
> 05f3d34094b23dc9612ff6641a0257bc4f7dcd12.
> 
> Thanks for reporting the issue!
> 
> Is this bug closed, though?
> 
> Ludo’.

I can close it if needed.

bug#42543: lint failure for packages on load path specified with -L

[zimoun]

Hi Ludo,

I confirm the bug and please consider the fix sent in this thread:

http://issues.guix.gnu.org/42543#2

Well, it tweaks using 'canonicalize-path' which is maybe not the right
thing. Let me know.

Cheers,
simon


On Wednesday, 5 August 2020, Ludovic Courtès  wrote:

> Hi,
>
> Jack Hill  skribis:
>
> > jackhill@alperton ~$ guix lint -L lint-test my-hello
> > Backtrace:y-hello@2.10 [formatting]...
> >8 (primitive-load "/home/jackhill/.config/guix/current/bi…")
> > In guix/ui.scm:
> >   1974:12  7 (run-guix-command _ . _)
> > In ice-9/boot-9.scm:
> >   1736:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> > In guix/store.scm:
> >631:22  5 (thunk)
> > In srfi/srfi-1.scm:
> > 634:9  4 (for-each # …)
> > In guix/scripts/lint.scm:
> >  60:4  3 (run-checkers _ _ #:store _)
> > In srfi/srfi-1.scm:
> > 634:9  2 (for-each # …)
> > 241:2  1 (for-each _ _)
> > In ice-9/boot-9.scm:
> >   1669:16  0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> > In procedure for-each: Wrong type argument: #f
>
> I can’t reproduce this problem:
>
> --8<---cut here---start->8---
> $ cat /tmp/t/my-hello.scm
> (define-module (my-hello)
>   #:use-module (guix build-system gnu)
>   #:use-module (guix download)
>   #:use-module (guix licenses)
>   #:use-module (guix packages))
>
> (define-public my-hello
>   (package
> (name "my-hello")
> (version "2.10")
> (source (origin
>   (method url-fetch)
>   (uri (string-append "mirror://gnu/hello/hello-" version
>   ".tar.gz"))
>   (sha256
>(base32
> "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
> (build-system gnu-build-system)
> (synopsis "Hello, GNU world: An example GNU package")
> (description
>  "GNU Hello prints the message \"Hello, world!\" and then exits.  It
> serves as an example of standard GNU coding practices.  As such, it
> supports
> command-line arguments, multiple languages, and so on.")
> (home-page "https://www.gnu.org/software/hello/;)
> (license gpl3+)))
> $ guix lint -L /tmp/t my-hello
> $ echo $?
> 0
> $ guix show -L /tmp/t my-hello
> name: my-hello
> version: 2.10
> outputs: out
> systems: x86_64-linux i686-linux
> dependencies:
> location: /tmp/t/my-hello.scm:8:2
> homepage: https://www.gnu.org/software/hello/
> license: GPL 3+
> synopsis: Saluton, mondo GNU: ekzemplo de pako GNU
> description: GNU Hello montras la mesaĝon "Hello, world!" kaj finiĝas.  Ĝi
> funkcias kiel ekzemplo de norma
> + kodumada tradicio de GNU.  Tiel, ĝi subtenas komand-liniajn argumentojn,
> plurajn lingvojn, kaj tiel plu.
>
> $ guix describe
> Generacio 152   Aug 04 2020 17:34:23(nuna)
>   guix abe3c5e
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: abe3c5ed7d04985c987e6c81aeb1284354ea0c77
> --8<---cut here---end--->8---
>
> Do you still have this problem?
>
> (Besides, ‘canonicalize-path’ should be used sparsely: it’s quite
> expensive and sometimes confusing for users.  With the proposed patches,
> “-L /does/not/exist” would now lead to an error.)
>
> Thanks,
> Ludo’.
>
>
>
>

bug#42543: lint failure for packages on load path specified with -L

[Jack Hill]

Hi Ludo’! Hope you've enjoyed your (short) time away from the keyboard :)

On Wed, 5 Aug 2020, Ludovic Courtès wrote:


Hi,

Jack Hill  skribis:


jackhill@alperton ~$ guix lint -L lint-test my-hello
Backtrace:y-hello@2.10 [formatting]...
   8 (primitive-load "/home/jackhill/.config/guix/current/bi…")
In guix/ui.scm:
  1974:12  7 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   631:22  5 (thunk)
In srfi/srfi-1.scm:
634:9  4 (for-each # …)
In guix/scripts/lint.scm:
 60:4  3 (run-checkers _ _ #:store _)
In srfi/srfi-1.scm:
634:9  2 (for-each # …)
241:2  1 (for-each _ _)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure for-each: Wrong type argument: #f


I can’t reproduce this problem:


[…]


$ guix lint -L /tmp/t my-hello
$ echo $?
0
$ guix show -L /tmp/t my-hello
name: my-hello
version: 2.10
outputs: out
systems: x86_64-linux i686-linux
dependencies:
location: /tmp/t/my-hello.scm:8:2
homepage: https://www.gnu.org/software/hello/
license: GPL 3+
synopsis: Saluton, mondo GNU: ekzemplo de pako GNU
description: GNU Hello montras la mesaĝon "Hello, world!" kaj finiĝas.  Ĝi 
funkcias kiel ekzemplo de norma
+ kodumada tradicio de GNU.  Tiel, ĝi subtenas komand-liniajn argumentojn, 
plurajn lingvojn, kaj tiel plu.


You've passed an absolute path to -L. Indeed, I don't don't see the 
problem when I do that, only when using a relative path. Can you try 
running `guix lint -L t my-hello` while your current working directory is 
/tmp?



Do you still have this problem?


Yes, confirmed just now with 05f3d34094b23dc9612ff6641a0257bc4f7dcd12


(Besides, ‘canonicalize-path’ should be used sparsely: it’s quite
expensive and sometimes confusing for users.  With the proposed patches,
“-L /does/not/exist” would now lead to an error.)


Perhaps this can be solved a different way. Could we propagate the 
knowledge of the current working directory, and construct absolute path 
when needed?


However, now that you, hopefully, better understand the problem, do we 
want to support relative paths passed to -L? It seems that they happen to 
work some places now, but not others (guix edit is another place where it 
doesn't work). I would be equally happy if we decided to not support 
relative paths, and warn the user when was was provided to -L.


I also think it might make sense for -L /does/not/exist to print a 
(friendly) error rather than silently not loading modules, but I'm open to 
arguments to the contrary.


Best,
Jack

bug#42601: Guix install bug: error: Unbound variable: ~S

[Ludovic Courtès]

Hi,

> I made a package named "qmk-cli" and it seems Guix doesn't like it.
> Running "./pre-inst-env guix install "qmk-cli"" results in this:
> guix install: error: Unbound variable: ~S

My bad, I believe this is fixed by
05f3d34094b23dc9612ff6641a0257bc4f7dcd12.

Thanks for reporting the issue!

Is this bug closed, though?

Ludo’.

bug#42543: lint failure for packages on load path specified with -L

[Ludovic Courtès]

Hi,

Jack Hill  skribis:

> jackhill@alperton ~$ guix lint -L lint-test my-hello
> Backtrace:y-hello@2.10 [formatting]...
>8 (primitive-load "/home/jackhill/.config/guix/current/bi…")
> In guix/ui.scm:
>   1974:12  7 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1736:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/store.scm:
>631:22  5 (thunk)
> In srfi/srfi-1.scm:
> 634:9  4 (for-each # …)
> In guix/scripts/lint.scm:
>  60:4  3 (run-checkers _ _ #:store _)
> In srfi/srfi-1.scm:
> 634:9  2 (for-each # …)
> 241:2  1 (for-each _ _)
> In ice-9/boot-9.scm:
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> In procedure for-each: Wrong type argument: #f

I can’t reproduce this problem:

--8<---cut here---start->8---
$ cat /tmp/t/my-hello.scm
(define-module (my-hello)
  #:use-module (guix build-system gnu)
  #:use-module (guix download)
  #:use-module (guix licenses)
  #:use-module (guix packages))

(define-public my-hello
  (package
(name "my-hello")
(version "2.10")
(source (origin
  (method url-fetch)
  (uri (string-append "mirror://gnu/hello/hello-" version
  ".tar.gz"))
  (sha256
   (base32
"0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
(build-system gnu-build-system)
(synopsis "Hello, GNU world: An example GNU package")
(description
 "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
(home-page "https://www.gnu.org/software/hello/;)
(license gpl3+)))
$ guix lint -L /tmp/t my-hello
$ echo $?
0
$ guix show -L /tmp/t my-hello
name: my-hello
version: 2.10
outputs: out
systems: x86_64-linux i686-linux
dependencies: 
location: /tmp/t/my-hello.scm:8:2
homepage: https://www.gnu.org/software/hello/
license: GPL 3+
synopsis: Saluton, mondo GNU: ekzemplo de pako GNU  
description: GNU Hello montras la mesaĝon "Hello, world!" kaj finiĝas.  Ĝi 
funkcias kiel ekzemplo de norma
+ kodumada tradicio de GNU.  Tiel, ĝi subtenas komand-liniajn argumentojn, 
plurajn lingvojn, kaj tiel plu.

$ guix describe
Generacio 152   Aug 04 2020 17:34:23(nuna)
  guix abe3c5e
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: abe3c5ed7d04985c987e6c81aeb1284354ea0c77
--8<---cut here---end--->8---

Do you still have this problem?

(Besides, ‘canonicalize-path’ should be used sparsely: it’s quite
expensive and sometimes confusing for users.  With the proposed patches,
“-L /does/not/exist” would now lead to an error.)

Thanks,
Ludo’.

bug#42162: Recovering source tarballs

[Timothy Sample]

Hey,

Ludovic Courtès  writes:

> Note that we have .  Last I checked,
> SWH was ingesting it in its “qualification” instance, so it should be
> ingesting it for good real soon if it’s not doing it already.

Oh fantastic!  I was going to volunteer to do it, so that’s one thing
off my list.

> One can easily write a procedure that takes a tarball and returns a
>  that builds its database entry.  So at each commit, we’d
> just rebuild things that have changed.

That makes more sense.  I will give this a shot soon.

> If we expose the database over HTTP (like over cgit), we can arrange so
> that (guix download) simply GETs db.example.org/sha256/xyz.  No need to
> fetch the whole database.
>
> It might be more reasonable to have a real database and a real service
> around it, I’m sure Chris Baines would agree ;-), but we can choose URLs
> that could easily be implemented by a “real” service instead of cgit in
> the future.

I got it working over cgit shortly after sending my last message.  :)  So
far, I am very much on team “good enough for now”.

> Timothy Sample  skribis:
>
>> I was imagining an escape hatch beyond this, where one could look up a
>> provenance record from when Disarchive ingested and verified a source
>> code archive.  The provenance record would tell you which version of
>> Guix was used when saving the archive, so you could try your luck with
>> using “guix time-machine” to reproduce Disarchive’s original
>> computation.  If we perform database migrations, you would need to
>> travel back in time in the database, too.  The idea is that you could
>> work around breakages in Disarchive automatically using the Power of
>> Guix™.  Just a stray thought, really.
>
> Seems to me it Shouldn’t Be Necessary?  :-)
>
> I mean, as long as the format is extensible and “future-proof”, we’ll
> always be able to rebuild tarballs and then re-disassemble them if we
> need to compute new hashes or whatever.

If Disarchive relies on external compressors, there’s an outside chance
that those compressors could change under our feet.  In that case, one
would want to be able to track down exactly which version of XZ was used
when Disarchive verified that it could reassemble a given source
archive.  Maybe I’m being paranoid, but if the database entries are
being computed by the CI infrastructure it would be pretty easy to note
the Guix commit just in case.

> I was thinking that it might be best to not use Guix for computations.
> For example, have “disarchive save” not build derivations and instead do
> everything “here and now”.  That would make it easier for others to
> adopt.  Wait, looking at the Git history, it looks like you already
> addressed that point, neat.  :-)

Since my last message I managed to remove Guix as dependency completely.
Right now it loads ‘(guix swh)’ opportunistically, but I might just copy
the code in.  Directory references now support multiple “addresses” so
that you could have Nix-style, SWH-style, IPFS-style, etc.  Hopefully my
next message will have a WIP patch enabling Guix to use Disarchive!


-- Tim

bug#42162: Recovering source tarballs

[Ludovic Courtès]

Hello!

Timothy Sample  skribis:

> Ludovic Courtès  writes:
>
>> Wooohoo!  Is it that time of the year when people give presents to one
>> another?  I can’t believe it.  :-)
>
> Not to be too cynical, but I think it’s just the time of year that I get
> frustrated with what I should be working on, and start fantasizing about
> green-field projects.  :p

:-)

>> Timothy Sample  skribis:
>>
>>> The header and footer are read directly from the file.  Finding the
>>> compressor is harder.  I followed the approach taken by the pristine-tar
>>> project.  That is, try a bunch of compressors and hope for a match.
>>> Currently, I have:
>>>
>>> • gnu-best
>>> • gnu-best-rsync
>>> • gnu
>>> • gnu-rsync
>>> • gnu-fast
>>> • gnu-fast-rsync
>>> • zlib-best
>>> • zlib
>>> • zlib-fast
>>> • zlib-best-perl
>>> • zlib-perl
>>> • zlib-fast-perl
>>> • gnu-best-rsync-1.4
>>> • gnu-rsync-1.4
>>> • gnu-fast-rsync-1.4
>>
>> I would have used the integers that zlib supports, but I guess that
>> doesn’t capture this whole gamut of compression setups.  And yeah, it’s
>> not great that we actually have to try and find the right compression
>> levels, but there’s no way around it it seems, and as you write, we can
>> expect a couple of variants to be the most commonly used ones.
>
> My first instinct was “this is impossible – a DEFLATE compressor can do
> just about whatever it wants!”  Then I looked at pristine-tar and
> realized that their hack probably works pretty well.  If I had infinite
> time, I would think about some kind of fully general, parameterized LZ77
> algorithm that could describe any implementation.  If I had a lot of
> time I would peel back the curtain on Gzip and zlib and expose their
> tuning parameters.  That would be nicer, but keep in mind we will have
> to cover XZ, bzip2, and ZIP, too!  There’s a bit of balance between
> quality and coverage.  Any improvement to the representation of the
> compression algorithm could be implemented easily: just replace the
> names with their improved representation.

Yup, it makes sense to not spend too much time on this bit.  I guess
we’d already have good coverage with gzip and xz.

>> (BTW the code I posted or the one in Disarchive could perhaps replace
>> the one in Gash-Utils.  I was frustrated to not see a ‘fold-archive’
>> procedure there, notably.)
>
> I really like “fold-archive”.  One of the reasons I started doing this
> is to possibly share code with Gash-Utils.  It’s not as easy as I was
> hoping, but I’m planning on improving things there based on my
> experience here.  I’ve now worked with four Scheme tar implementations,
> maybe if I write a really good one I could cap that number at five!

Heh.  :-)  The needs are different anyway.  In Gash-Utils the focus is
probably on simplicity/maintainability, whereas here you really want to
cover all the details of the wire representation.

>>> To avoid hitting the SWH archive at all, I introduced a directory cache
>>> so that I can store the directories locally.  If the directory cache is
>>> available, directories are stored and retrieved from it.
>>
>> I guess we can get back to them eventually to estimate our coverage ratio.
>
> It would be nice to know, but pretty hard to find out with the rate
> limit.  I guess it will improve immensely when we set up a
> “sources.json” file.

Note that we have .  Last I checked,
SWH was ingesting it in its “qualification” instance, so it should be
ingesting it for good real soon if it’s not doing it already.

>>> You mean like ?  :)
>>
>> Woow.  :-)
>>
>> We could actually have a CI job to create the database: it would
>> basically do ‘disarchive save’ for each tarball and store that using a
>> layout like the one you used.  Then we could have a job somewhere that
>> periodically fetches that and adds it to the database.  WDYT?
>
> Maybe  I assume that Disarchive would fail for a few of them.  We
> would need a plan for monitoring those failures so that Disarchive can
> be improved.  Also, unless I’m misunderstanding something, this means
> building the whole database at every commit, no?  That would take a lot
> of time and space.  On the other hand, it would be easy enough to try.
> If it works, it’s a lot easier than setting up a whole other service.

One can easily write a procedure that takes a tarball and returns a
 that builds its database entry.  So at each commit, we’d
just rebuild things that have changed.

>> I think we should leave room for other hash algorithms (in the sexps
>> above too).
>
> It works for different hash algorithms, but not for different directory
> hashing methods (like you mention below).

OK.

[...]

>> So it does mean that we could pretty much right away add a fall-back in
>> (guix download) that looks up tarballs in your database and uses
>> Disarchive to recontruct it, right?  I love solved problems.  :-)