Package: guix;
Reported by: Fredrik Salomonsson <plattfot <at> posteo.net>
Date: Sun, 15 Jun 2025 01:55:02 UTC
Severity: normal
View this message in rfc822 format
From: Fredrik Salomonsson <plattfot <at> posteo.net> To: 78793 <at> debbugs.gnu.org Subject: bug#78793: sc-controller crashes after commit: 9bc97424d347901e6b70b5477a1066359f3d6f2c Date: Sun, 15 Jun 2025 01:54:02 +0000
Hi,
I've been using the sc-controller package for over a year — I had the
patches from https://issues.guix.gnu.org/58403 applied to my own channel
while I waited for it to be reviewed and merged in the main channel.
Which look like it was around three weeks ago. But it looks like
something broke between May 24 — commit
9bc97424d347901e6b70b5477a1066359f3d6f2c — and May 31 — commit
fd1d786e4574854093f31f52a7898560a609304a. As when I did a pull on May
31 I'm getting this when launching it:
```
guix shell sc-controller -- sc-controller
substitute: looking for substitutes on 'https://substitutes.nonguix.org'... 100.0%
substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 100.0%
2,1 MB will be downloaded
sc-controller-0.4.8.9 2.0MiB 1.4MiB/s 00:01 ▕██████████████████▏ 100.0%
** (.sc-controller-real:23465): WARNING **: 18:46:28.668: expected enumeration type void, but got PyGLibOptionArg instead
** (.sc-controller-real:23465): WARNING **: 18:46:28.668: expected enumeration type void, but got PyGLibOptionArg instead
** (.sc-controller-real:23465): WARNING **: 18:46:28.668: expected enumeration type void, but got PyGLibOptionArg instead
thread '<unnamed>' panicked at /tmp/guix-build-librsvg-2.58.5.drv-0/librsvg-2.58.5/guix-vendor/rust-glib-0.19.9.tar.gz/src/subclass/types.rs:999:9:
assertion `left == right` failed: Type RsvgHandle has already been registered
left: 911974304
right: 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at core/src/panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
0: 0x7f6a2b4179bd - <unknown>
1: 0x7f6a2b4424f3 - <unknown>
2: 0x7f6a2b4258b9 - <unknown>
3: 0x7f6a2b42915f - <unknown>
4: 0x7f6a2b428d88 - <unknown>
5: 0x7f6a2b429705 - <unknown>
6: 0x7f6a2b417d75 - <unknown>
7: 0x7f6a2b417bc9 - <unknown>
8: 0x7f6a2b4292e4 - <unknown>
9: 0x7f6a2b0c45d5 - <unknown>
10: 0x7f6a2b0c4662 - <unknown>
11: 0x7f6a2b0c47a6 - <unknown>
12: 0x7f6a2b0c71c9 - rsvg_handle_get_type
13: 0x7f6a4ebb7d0e - g_registered_type_info_get_g_type
14: 0x7f6a4ed4aebd - <unknown>
15: 0x7f6a4f5b95b2 - <unknown>
16: 0x7f6a4f563f32 - PyObject_Vectorcall
17: 0x7f6a4f5040dd - _PyEval_EvalFrameDefault
18: 0x7f6a4f669d71 - <unknown>
19: 0x7f6a4f5672e8 - <unknown>
20: 0x7f6a4f56469c - PyObject_CallOneArg
21: 0x7f6a4f5dc0c2 - <unknown>
22: 0x7f6a4f5bd7d7 - PyObject_GetAttr
23: 0x7f6a4f502b39 - _PyEval_EvalFrameDefault
24: 0x7f6a4f669d71 - <unknown>
25: 0x7f6a4f564b2e - _PyObject_Call_Prepend
26: 0x7f6a4f5dd947 - <unknown>
27: 0x7f6a4f5d4657 - <unknown>
28: 0x7f6a4f5631f5 - _PyObject_MakeTpCall
29: 0x7f6a4f5040dd - _PyEval_EvalFrameDefault
30: 0x7f6a4f669d71 - <unknown>
31: 0x7f6a4ed57c48 - <unknown>
32: 0x7f6a4eb3c931 - <unknown>
33: 0x7f6a4eb3d1e8 - <unknown>
34: 0x7f6a4eb5b929 - <unknown>
35: 0x7f6a4eb7063b - <unknown>
36: 0x7f6a4eb75b55 - g_signal_emit_valist
37: 0x7f6a4eb75c02 - g_signal_emit
38: 0x7f6a4d7d88f2 - g_application_register
39: 0x7f6a4d7d8d20 - <unknown>
40: 0x7f6a4d7d908e - g_application_run
41: 0x7f6a4eb3d052 - <unknown>
42: 0x7f6a4eb3bc85 - <unknown>
43: 0x7f6a4eb3c68e - ffi_call
44: 0x7f6a4ed5a537 - <unknown>
45: 0x7f6a4ed5c5ba - <unknown>
46: 0x7f6a4f5642f9 - PyObject_Call
47: 0x7f6a4f506b53 - _PyEval_EvalFrameDefault
48: 0x7f6a4f669c0f - PyEval_EvalCode
49: 0x7f6a4f6b7d7d - <unknown>
50: 0x7f6a4f6b9487 - _PyRun_SimpleFileObject
51: 0x7f6a4f6b9a9b - _PyRun_AnyFileObject
52: 0x7f6a4f6dae38 - <unknown>
53: 0x7f6a4f6db4cc - Py_BytesMain
54: 0x7f6a4f16bbf7 - __libc_start_call_main
55: 0x7f6a4f16bcac - __libc_start_main <at> GLIBC_2.2.5
56: 0x401071 - _start
57: 0x0 - <unknown>
thread caused non-unwinding panic. aborting.
```
It works fine before that, for example here is the generation I'm
currently running that works:
```
Generation 50 maj 24 2025 14:40:52 (current)
file name: /var/guix/profiles/system-50-link
canonical file name: /gnu/store/4y0vk93rgzwcvf4fjvz6c8djdxjwpg2r-system
label: GNU with Linux 6.14.7
bootloader: grub-efi
root device: label: "guix-root"
kernel: /gnu/store/hc2ksndxbar6n5vfi85hnm5b7kvpyfnd-linux-6.14.7/bzImage
channels:
plt:
repository URL: https://git.sr.ht/~plattfot/plt
branch: master
commit: 5ff3981e9e95160c86239f09617f6bdcb75a68c4
nonguix:
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 7152e92a13edf3e9a356e7b9b759b163aed3044c
guix:
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 9bc97424d347901e6b70b5477a1066359f3d6f2c
```
And one that triggers that error:
```
Generation 51 maj 31 2025 20:05:25
file name: /var/guix/profiles/system-51-link
canonical file name: /gnu/store/sqh0ryd7fds737z50sadgl1k5l2zpy52-system
label: GNU with Linux 6.14.8
bootloader: grub-efi
root device: label: "guix-root"
kernel: /gnu/store/540pf10pz1q557h6sr6p2k4czfpckjdy-linux-6.14.8/bzImage
channels:
plt:
repository URL: https://git.sr.ht/~plattfot/plt
branch: master
commit: a4f0fd42fcef34a7e4228ac82ffdf8e160fc7f51
nonguix:
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 0b9e1041aec581d5426adf5fa593e12cc4b75409
guix:
repository URL: https://git.guix.gnu.org/guix.git
branch: master
commit: fd1d786e4574854093f31f52a7898560a609304a
```
I tested to update to the latest version 0.4.8.13 and also the fork of
it at https://github.com/C0rn3j/sc-controller using version 0.5.2. As
https://github.com/Ryochan7/sc-controller has been archived.
Both of these are triggering the same panic. I haven't found any
reports upstream on a similar issue. So I'm not sure if it's a bug
upstream or in guix.
Anyone has any idea what could be the issue?
--
s/Fred[re]+i[ck]+/Fredrik/g
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.