bug#50118: Racket: `raco exe` can't find Racket executable for variant cs
Hi, the current racket package shows this behaviour: --8<---cut here---start->8--- raco exe main.rkt L3 #5172 find-exe: can't find Racket executable for variant cs context...: /gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/compiler/embed.rkt:1481:0: create-embedding-executable /gnu/store/vv430dla9xglhs35nzdyci5gcwbnqi2q-racket-8.2/share/racket/pkgs/compiler-lib/compiler/commands/exe.rkt:100:0 body of "/gnu/store/vv430dla9xglhs35nzdyci5gcwbnqi2q-racket-8.2/share/racket/pkgs/compiler-lib/compiler/commands/exe.rkt" /gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/raco/raco.rkt:41:0 body of "/gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/raco/raco.rkt" body of "/gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/raco/main.rkt" --8<---cut here---end--->8--- the same is true for `--cgc` --8<---cut here---start->8--- raco exe --cgc main.rkt L3 #5173 find-exe: can't find Racket executable for variant cgc context...: /gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/compiler/embed.rkt:1481:0: create-embedding-executable /gnu/store/vv430dla9xglhs35nzdyci5gcwbnqi2q-racket-8.2/share/racket/pkgs/compiler-lib/compiler/commands/exe.rkt:100:0 body of "/gnu/store/vv430dla9xglhs35nzdyci5gcwbnqi2q-racket-8.2/share/racket/pkgs/compiler-lib/compiler/commands/exe.rkt" /gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/raco/raco.rkt:41:0 body of "/gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/raco/raco.rkt" body of "/gnu/store/z8vb7cfcpknwvixcq788mrh1fchw9f7l-racket-minimal-8.2/share/racket/collects/raco/main.rkt" --8<---cut here---end--->8--- but `--3m` works. I suppose this is a bug because racket from the racket teams ppa (https://launchpad.net/~plt/+archive/ubuntu/racket) works in all cases. Malte
bug#50121: Deduplication breaks store item repair
Hi, I’ve been having issues with the filesystem that holds /gnu/store recently, causing corrupted/broken files. When trying to repair these broken files with `guix gc --verify=repair,contents` it properly detects that store items’ hashes do not match the ones recorded in the database and redownloads/rebuilds them. However, the corrupted store items are never actually repaired – not by `guix gc` and not by `guix build --repair`. Attached is a testcase showing that deduplication is the problem, because repairing will just hardlink the (broken) deduplicated file instead of replacing it with the downloaded/built file. I tried the daemon’s `--disable-deduplication` too with same results. Cheers, Lars testcase.sh Description: Bourne shell script /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello 0jxnp4f4rac2scvq9lhcvpr4n4w0zrx5wdhcqml4w7zfybbszswp -r-xr-xr-x 2 root root 0 19. Aug 13:54 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello reading the store... checking path existence... checking hashes... path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10' was modified! expected hash `9c61184c4b1af09639cee8148bc0c3d7aced4a671615a6e0a3e7ccb927848ffa', got `3330b928ba2d3cf6acfdb0ef3a359fb686eac7ee6e9d49a6515ef7b1701537cf' fetching path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10'... Downloading https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10... hello-2.10 51KiB528KiB/s 00:00 [##] 100.0% -r-xr-xr-x 2 root root 0 1. Jan 1970 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10' is corrupted or missing! Substituiere /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 … Lade von https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 herunter … hello-2.10 51KiB 482KiB/s 00:00 [##] 100.0% /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 -r-xr-xr-x 2 root root 0 1. Jan 1970 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10' is corrupted or missing! Substituiere /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 … Lade von https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 herunter … hello-2.10 51KiB 455KiB/s 00:00 [##] 100.0% /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 -r-xr-xr-x 2 root root 37K 1. Jan 1970 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello
bug#50122: [core-updates-frozen] Gtk documentation generation fails.
Hello, The generation of the documentation of the Gnome projects is broken on core-updates-frozen. Passing the "-Dgtk_doc=true" build option to evince or libhandy packages results in the following error: --8<---cut here---start->8--- Traceback (most recent call last): File "/gnu/store/6dk7w7g7kbr5cnp0kiym3f68l1g26xbx-python-3.9.6/lib/python3.9/shutil.py", line 806, in move os.rename(src, real_dst) FileNotFoundError: [Errno 2] No such file or directory: '/home/mathieu/libhandy/_build/doc/html/libhandy.devhelp2' -> '/home/mathieu/libhandy/_build/doc/html/libhandy-1.devhelp2' During handling of the above exception, another exception occurred: --8<---cut here---end--->8--- According to strace, xsltproc is called to generate the libhandy.devhelp2 document this way: --8<---cut here---start->8--- /gnu/store/5fy04b79bmzajbgz21jibkgmn38frkrx-libxslt-1.1.34/bin/xsltproc --path /home/mathieu/libhandy/doc:/home/mathieu/libhandy/_build/doc --nonet --xinclude --stringparam gtkdoc.bookname libhandy --stringparam gtkdoc.version 1.33.1 /gnu/store/vh5gjvlbns7s26r8x6282165xqrk137l-gtk-doc-1.33.2/share/gtk-doc/data/gtk-doc.xsl ../handy-docs.xml --8<---cut here---end--->8--- However the final document never shows up. The output log contains several errors such as this one: --8<---cut here---start->8--- Error: no ID for constraint linkend: "GtkDrawingArea". --8<---cut here---end--->8--- that should be harmless. Thanks, Mathieu
bug#49827: Error message for missing synopsis in opam importer
Hello, Thanks for your answer ! Le Tue, 17 Aug 2021 09:43:10 +0200, zimoun a écrit : > Hi, > > I am back from holidays. :-) > > … > > From my understanding, there is 2 issues: > > - gentle handler for error > - warn for incomplete metadata > Yes, absolutely, because currently understanding the cause of the error requires to delve into the source to understand what is going on. The warning part is more optional, but if this pattern matching is modified to handle that special case of a missing metadata instead of entirely crashing, I thought it could be useful not to be too permissive either, and to at least mention that a missing metadata was caught and should be filled by hand. This could take the form of a message above the output of the actual scheme code for the package declaration while the importer is running, or of an invalid value for that missing field in the generated scheme output, something like "" or such that would be invalid in scheme and would make guix build fail when trying to use the output directly without manually editing it to fill the missing metadata. > With Jérémy (jeko), we have started to work time to time using > experimental pair-programming to fix the former. Currently, each > importer uses its own error mechanism and obviously incoherence > between them happens; especially when ’--recursive’. We are trying > to unify that. > > Thanks for the report of this use case. :-) Glad to learn my report could help : ) > > > Cheers, > simon
bug#49985: bash-mesboot0: Inscrutable error in build phase
Hello Carl, > The error line is L1299: "make: stat:Makefile: sterror: unknown error” This reminds me of: https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00335.html. I never took the time to fix this issue. Bottom line is that building the bootstrap toolchain fails on NVME disks because some syscalls (stat64, lstat64 and fstat64) need to be implemented in GNU Mes. There's a small demonstration program that you can use to demonstrate this theory :). Thanks, Mathieu
