bug#42740: Segfault in libssh during ‘guix copy’
Hello Ludovic,
please check if this branch will work without segfaults in Guix:
https://github.com/artyom-poptsov/guile-ssh/tree/wip-fix-segfaults-on-gc
Key changes:
- Channels are now protecting the parent session from GC'ing.
- Every channel procedure now ensures that the parent session is
connected before calling any libssh procedures upon a channel
instance. The idea is that a channel cannot be created when a session
is disconnected and when channel is present and the session is closed,
it means that the session is disconnected and freed.
- Artyom
On Fri, 7 Aug 2020 at 12:25, Ludovic Courtès wrote:
>
> Hi,
>
> I observe the following segfault:
>
> --8<---cut here---start->8---
> $ guix copy --to=olimex /gnu/store/… -v3 --debug=3
> sending 66 store items (166 MiB) to 'A20-OLinuXino.local'...
> exporting path `/gnu/store/als3v92k7l6ny44sci1x0p9x6d7z0ivp-mesa-20.0.8'
> Adres-eraro(nekropsio elŝutita)
> $ 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
> $ gdb $(type -P guile) core
>
> [...]
>
> [Current thread is 1 (Thread 0x7f947b084b80 (LWP 12777))]
> (gdb) bt
> #0 0x7f94751c0185 in deflate_fast ()
>from /gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib/libz.so.1
> #1 0x7f94751c253d in deflate () from
> /gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib/libz.so.1
> #2 0x7f9474a8db4a in gzip_compress (session=session@entry=0x1ff0b10,
> source=source@entry=0x1ff07e0,
> level=) at
> /tmp/guix-build-libssh-0.9.4.drv-0/source/src/gzip.c:91
> #3 0x7f9474a8de83 in compress_buffer (session=session@entry=0x1ff0b10,
> buf=0x1ff07e0)
> at /tmp/guix-build-libssh-0.9.4.drv-0/source/src/gzip.c:112
> #4 0x7f9474a6ab5f in packet_send2 (session=session@entry=0x1ff0b10)
> at /tmp/guix-build-libssh-0.9.4.drv-0/source/src/packet.c:1632
> #5 0x7f9474a6ac32 in ssh_packet_send (session=session@entry=0x1ff0b10)
> at /tmp/guix-build-libssh-0.9.4.drv-0/source/src/packet.c:1810
> #6 0x7f9474a54639 in channel_write_common (channel=0x1ff43a0,
> data=0x7f9477995020, len=65536, is_stderr=0)
> at /tmp/guix-build-libssh-0.9.4.drv-0/source/src/channels.c:1488
> #7 0x7f9474ad8a9e in write_to_channel_port ()
>from
> /gnu/store/vj92bd6lcknylwka9v4n4h0i360n6vn4-guile-ssh-0.13.0/lib/libguile-ssh.so.13
> #8 0x7f947b749edc in scm_i_write_bytes (port=# 7f9476af56c0> 7f9477c23e00>,
> src="#" = {...}, start=0, count=65536) at ports.c:2865
> #9 0x7f947b75186f in scm_put_bytevector (port=# 7f9476af56c0> 7f9477c23e00>,
> bv="#" = {...}, start=, count=)
> at r6rs-ports.c:676
> #10 0x7f94750be427 in ?? ()
> #11 0x7f947ad60d80 in ?? ()
> #12 0x7f947b7ee620 in ?? () from
> /gnu/store/0w76khfspfy8qmcpjya41chj3bgfcy0k-guile-3.0.4/lib/libguile-3.0.so.1
> #13 0x7f947ad60d80 in ?? ()
> #14 0x7f947b72743b in scm_jit_enter_mcode (thread=0x7f947ad60d80,
> thread@entry=0x28,
> mcode=0x7f94750c63a0 "I\211\314I)\304I\203\374\020\017\214k ") at
> jit.c:5852
> #15 0x7f947b7828e9 in vm_regular_engine (thread=0x28) at vm-engine.c:360
> #16 0x7f947b7835b5 in scm_call_n (proc=,
> argv=argv@entry=0x7fff14699b38, nargs=nargs@entry=1)
> at vm.c:1608
> #17 0x7f947b700c97 in scm_primitive_eval (exp=) at
> eval.c:671
> #18 0x7f947b7290fb in scm_primitive_load (filename=) at
> load.c:131
> #19 0x7f947b782151 in vm_regular_engine (thread=0x7f947ad60d80) at
> vm-engine.c:972
> #20 0x7f947b7835b5 in scm_call_n (proc=,
> argv=argv@entry=0x7fff14699d08, nargs=nargs@entry=1)
> at vm.c:1608
> #21 0x7f947b700c97 in scm_primitive_eval (exp=,
> exp@entry=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line)
> load/lang) "/home/ludo/.config/guix/current/bin/guix") (quit at eval.c:671
> #22 0x7f947b700cf3 in scm_eval (
> exp=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang)
> "/home/ludo/.config/guix/current/bin/guix") (quit))),
> module_or_state=module_or_state@entry="#" = {...}) at
> eval.c:705
> #23 0x7f947b7595a0 in scm_shell (argc=8, argv=0x7fff1469a378) at
> script.c:357
> #24 0x7f947b7186ad in invoke_main_func (body_data=0x7fff1469a210) at
> init.c:308
> #25 0x7f947b6fab2a in c_body (d=0x7fff1469a150) at continuations.c:430
> #26 0x7f947b782151 in vm_regular_engine (thread=0x7f947ad60d80) at
> vm-engine.c:972
> #27 0x7f947b7835b5 in scm_call_n (proc=,
> argv=argv@entry=0x7fff14699f10, nargs=nargs@entry=2)
> at vm.c:1608
> #28 0x7f947b6ffb2a in scm_call_2 (proc=, arg1= out>, arg2=)
> at eval.c:503
> #29 0x7f947b70132a in scm_c_with_exception_handler (type=type@entry=#t,
> handler=handler@entry=0x7f947b7787e0 ,
> handler_data=handler_data@entry=0x7fff1469a080,
> thunk=thunk@entry=0x7f947b778920 ,
>
bug#42301: [PATCH] gnu: solfage: fix build.
Hello,
Michael Rohleder writes:
> * gnu/packages/music.scm (solfage): fix build
> (http://issues.guix.gnu.org/42301).
> ---
> gnu/packages/music.scm | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
> index db2f1ff8d6..af65c40193 100644
> --- a/gnu/packages/music.scm
> +++ b/gnu/packages/music.scm
> @@ -1361,6 +1361,9 @@ re-sequencer LV2 plugin.")
> (substitute* '("solfege/parsetree.py"
> "solfege/presetup.py")
> (("#!/usr/bin/python") (string-append "#!" (which "python"
> + ;; fix build, see https://issues.guix.gnu.org/42301
> + (with-fluids ((%default-port-encoding "ISO-8859-1"))
> + (substitute* '("README") (("Malm.") "Malmoe")))
Thank you. Unfortunately, the build fails later on with the following
unrelated message, probably related to the latest Lilypond release:
fatal error: Uninitialized variable `write-performances-midis' in module
(lily)
Besides, you are adding this snippet to an unrelated phase, about Python
wrapping.
BTW, would it make sense to provide 3.23.4 release instead? It is
a development version, but development has stalled anyway. Also, it
relies on Python 3 intead of Python 2.
I tried to update it with the following source:
(origin
(method url-fetch)
(uri (string-append "http://alpha.gnu.org/gnu/solfege/solfege-";
version ".tar.gz"))
(sha256
(base32 "0sc17vf4xz6gy0s0z9ghi68yskikdmyb4gdaxx6imrm40734k8mp")))
but it fails in the same way.
WDYT?
Regards,
--
Nicolas Goaziou
bug#33488: Does not compile libtorrent-rasterbar
Znavko, I came across this old bug report. Would you be so kind to check if libtorrent-rasterbar-1.1.11 has errors? No errors; just a ‘modern C++ library’, I'm afraid. Building libtorrent-rasterbar@1.2.7 with 4 cores today still happily consumed 2 GiB of RAM. It's no wonder your system started thrashing but there's little we can do. Closing. Kind regards, T G-R signature.asc Description: PGP signature
bug#42342: Wine64 segfaults (5.12/staging)
Now that wine stable is 5.12, I can't use start 32-bit applications
anymore. I tried from a clean wine prefix and I only get this error:
--8<---cut here---start->8---
Segmentation fault
--8<---cut here---end--->8---
Here is the end of the strace:
--8<---cut here---start->8---
openat(AT_FDCWD,
"/gnu/store/fhxjkwnv9w8a283f5qaiqq8hcmfmdap9-wine64-5.12/bin/../lib/wine32/wine/ntdll.dll.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/ajyl64ycr9vv51q2np68agwz2ad9lxqs-wine-5.12/lib/wine32/wine/ntdll.dll.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\360\302{4\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=941360, ...}) = 0
mmap2(0x7bc0, 864996, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7bc0
mmap2(0x7bc1e000, 487424, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e000) = 0x7bc1e000
mmap2(0x7bc95000, 200704, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x95000) = 0x7bc95000
mmap2(0x7bcc6000, 49152, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc5000) = 0x7bcc6000
mmap2(0x7bcd2000, 4836, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7bcd2000
close(3)= 0
openat(AT_FDCWD,
"/gnu/store/ajyl64ycr9vv51q2np68agwz2ad9lxqs-wine-5.12/lib/wine32/libm.so.6",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/z4li262il798hbl0l1h1k3a5g7r6bffa-glibc-2.31/lib/libm.so.6",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\241\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=1109456, ...}) = 0
mmap2(NULL, 1048680, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7eeff000
mmap2(0x7ef09000, 774144, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7ef09000
mmap2(0x7efc6000, 229376, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0xc7000) = 0x7efc6000
mmap2(0x7effe000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xfe000) = 0x7effe000
close(3)= 0
mprotect(0x7effe000, 4096, PROT_READ) = 0
mprotect(0x7bc0, 122880, PROT_READ|PROT_WRITE) = 0
mprotect(0x7bc1e000, 487424, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x7bc95000, 200704, PROT_READ|PROT_WRITE) = 0
mprotect(0x7bc95000, 200704, PROT_READ) = 0
mprotect(0x7bc1e000, 487424, PROT_READ|PROT_EXEC) = 0
mprotect(0x7bc0, 122880, PROT_READ) = 0
mprotect(0x7bcc6000, 4096, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x30} ---
+++ killed by SIGSEGV +++
Segmentation fault
--8<---cut here---end--->8---
Are 32-bit applications really working for some of you?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
bug#42342: Wine64 segfaults (5.12/staging)
On Sun, Aug 09, 2020 at 04:03:07PM +0200, Pierre Neidhardt wrote: > OK, I think I got it. I had to have _both_ wine and wine64 (staging or > not) in my profile. Interesting. Perhaps we should merge the two packages, then? We'd need to take care to make it work right on i686-linux, but I don't think that's unsurmountable... > Previously, the "wine" executable (for 32-bit apps) used to work when > wine64 alone was in the profile. Now it looks like we need both. Any > idea what changed? Perhaps loading 32-bit programs with the wine64 wasn't supposed to work in the first place, and we were relying on some implementation quirk? Alternatively, cross-compiling from 64 to 32 bit is less tested by upstream than compiling natively on 64 or 32 bit, and we're hitting an upstream bug? Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#42301: [PATCH] gnu: solfage: fix build.
Hi!
Nicolas Goaziou writes:
> Thank you. Unfortunately, the build fails later on with the following
> unrelated message, probably related to the latest Lilypond release:
>
> fatal error: Uninitialized variable `write-performances-midis' in module
> (lily)
>
This is interesting, I can't reproduce this, it builds (and runs) fine here.
Are you using a newer version of lilypond? (here, its 2.20.0 from current
master)
> Besides, you are adding this snippet to an unrelated phase, about Python
> wrapping.
Added a phase 'patch-readme:
From 3e6a637fcacb990291fb8a8b7e03e18be15bd644 Mon Sep 17 00:00:00 2001
From: Michael Rohleder
Date: Sun, 9 Aug 2020 18:26:25 +0200
Subject: [PATCH] gnu: solfege: fix build.
* gnu/packages/music.scm (solfege): fix build (http://issues.guix.gnu.org/42301).
---
gnu/packages/music.scm | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index db2f1ff8d6..f788d93b65 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -1362,6 +1362,12 @@ re-sequencer LV2 plugin.")
"solfege/presetup.py")
(("#!/usr/bin/python") (string-append "#!" (which "python"
#t))
+ ;; fix build, see https://issues.guix.gnu.org/42301
+ (add-before 'build 'patch-readme
+ (lambda _
+ (with-fluids ((%default-port-encoding "ISO-8859-1"))
+ (substitute* '("README") (("Malm.") "Malmoe")))
+ #t))
(add-before 'build 'add-sitedirs
;; .pth files are not automatically interpreted unless the
;; directories containing them are added as "sites". The directories
--
2.28.0
>
> BTW, would it make sense to provide 3.23.4 release instead? It is
> a development version, but development has stalled anyway. Also, it
> relies on Python 3 intead of Python 2.
>
> I tried to update it with the following source:
>
> (origin
>(method url-fetch)
>(uri (string-append "http://alpha.gnu.org/gnu/solfege/solfege-";
>version ".tar.gz"))
>(sha256
> (base32 "0sc17vf4xz6gy0s0z9ghi68yskikdmyb4gdaxx6imrm40734k8mp")))
>
> but it fails in the same way.
>
> WDYT?
idk.
I haven't tried building it, because I think, we should first solve that
"fatal error: Uninitialized variable `write-performances-midis' in
module (lily)" error you get and I cant reproduce...
Regards,
--
Ein Hamsterrad sieht von innen aus
wie eine Karriereleiter.
signature.asc
Description: PGP signature
bug#42601: Guix install bug: error: Unbound variable: ~S
Hello,
I believe there's still something wrong here.
The bug (the new one, described below) occurs after adding
#:use-module (gnu packages avr) to the firmware.scm file.
Attached the diff file of my package below.
I'm packaging qmk-firmware and here's what happens running guix build:
error: binutils: unbound variable
hint: Did you forget a `use-modules' form?
error: googletest: unbound variable
hint: Did you forget a `use-modules' form?
error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?
error: gcc-4.9: unbound variable
hint: Did you forget a `use-modules' form?
error: perl-module-build: unbound variable
hint: Did you forget a `use-modules' form?
error: python2-numpy: unbound variable
hint: Did you forget a `use-modules' form?
error: gzip: unbound variable
hint: Did you forget a `use-modules' form?
error: xcb-proto: unbound variable
hint: Did you forget a `use-modules' form?
error: gnu-make: unbound variable
hint: Did you forget a `use-modules' form?
error: unzip: unbound variable
hint: Did you forget a `use-modules' form?
error: curl: unbound variable
hint: Did you forget a `use-modules' form?
error: binutils: unbound variable
hint: Did you forget a `use-modules' form?
error: pjproject: unbound variable
hint: Did you forget a `use-modules' form?
error: xorg-server: unbound variable
hint: Did you forget a `use-modules' form?
error: libdvdnav: unbound variable
hint: Did you forget a `use-modules' form?
error: perl: unbound variable
hint: Did you forget a `use-modules' form?
error: coreutils: unbound variable
hint: Did you forget a `use-modules' form?
error: libetpan: unbound variable
hint: Did you forget a `use-modules' form?
Throw to key `unbound-variable' with args `("resolve-interface" "no
binding `~A' in module ~A" (python (gnu packages python)) #f)'.
Backtrace: In ice-9/boot-9.scm:
1736:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
631:22 18 (thunk)
1299:8 17 (call-with-build-handler # …)
In guix/scripts/build.scm:
817:2 16 (_)
In srfi/srfi-1.scm:
673:15 15 (append-map _ _ . _)
586:17 14 (map1 ((argument . "qmk-firmware") (build-mode . 0) # …))
In guix/scripts/build.scm:
837:30 13 (_ _)
In gnu/packages.scm:
477:2 12 (%find-package "qmk-firmware" "qmk-firmware" #f)
362:6 11 (find-best-packages-by-name _ _)
292:55 10 (_ "qmk-firmware" _)
In unknown file:
9 (force #)
In gnu/packages.scm:
239:33 8 (fold-packages # …)
In guix/discovery.scm:
153:11 7 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
460:18 6 (fold # …)
In guix/discovery.scm:
143:19 5 (_ _ ())
In srfi/srfi-1.scm:
691:23 4 (filter-map # . #)
In guix/discovery.scm:
118:22 3 (_ . _)
In guix/ui.scm:
329:2 2 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
1669:16 1 (raise-exception _ #:continuable? _)
1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern"
(unbound-variable "resolve-interface" "no binding `~A' in module ~A"
(python (gnu packages python)) #f))'.
Jan Wielkiewicz
From 39b3791efd06c4895c844548937d421f8359b1e0 Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 9 Aug 2020 23:43:08 +0200
Subject: [PATCH] gnu: Add qmk-firmware.
* gnu/packages/firmware.scm (qmk-firmware): New variable.
---
gnu/packages/firmware.scm | 37 +
1 file changed, 37 insertions(+)
diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm
index 15a6725c67..a0c65752d4 100644
--- a/gnu/packages/firmware.scm
+++ b/gnu/packages/firmware.scm
@@ -7,6 +7,7 @@
;;; Copyright © 2018 Vagrant Cascadian
;;; Copyright © 2019 Mathieu Othacehe
;;; Copyright © 2020 Marius Bakke
+;;; Copyright © 2020 Jan Wielkiewicz
;;;
;;; This file is part of GNU Guix.
;;;
@@ -33,6 +34,8 @@
#:use-module (gnu packages)
#:use-module (gnu packages admin)
#:use-module (gnu packages assembly)
+ #:use-module (gnu packages autotools)
+ #:use-module (gnu packages avr)
#:use-module (gnu packages base)
#:use-module (gnu packages bison)
#:use-module (gnu packages cmake)
@@ -41,6 +44,7 @@
#:use-module (gnu packages gcc)
#:use-module (gnu packages linux)
#:use-module (gnu packages perl)
+ #:use-module (gnu packages pkg-config)
#:use-module (gnu packages python))
(define-public ath9k-htc-firmware
@@ -621,3 +625,36 @@ switching support).\n")
#t)
(native-inputs `(("cross-gcc" ,(cross-gcc "arm-none-eabi" #:xgcc gcc-7))
("cross-binutils" ,(cross-binutils "arm-none-eabi"))
+
+(define-public qmk-firmware
+ (package
+(name "qmk-firmware")
+(version "0.9.50")
+(source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/qmk/qmk_firmware";)
+ (commit version)))
+ (file-name (git-file-name name version))
+
bug#42789: Linux-libre 5.8 and beyond
On Sun, Aug 09, 2020 at 06:17:48PM -0400, Mark H Weaver wrote: > If the file name and hash matches a previously downloaded file in your > store, the guix daemon uses that one and skips the download, regardless > of the URL. That's why no error was reported. There's no version > number in the file name of the 'deblob-check' file. We should try to make these files include the version number to avoid this kind of mistake in the future. I've CC-ed bug-guix so that we don't forget.
