GNU bug report logs -
#52651
syncthing-gtk fails to run (librsvg error)
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52651 in the body.
You can then email your comments to 52651 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Sun, 19 Dec 2021 03:07:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
John Kehayias <john.kehayias <at> protonmail.com>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 19 Dec 2021 03:07:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Guixers,
Looks like syncthing-gtk broke sometime just before/during/after the big core-updates-frozen merge. It was working for me at least before the merge, but I was slightly out of date. I don't think it is the syncthing-gtk package itself (no changes other than input style change), but it fails due to librsvg or how it uses it. Not sure what has changed here to cause this.
Running with RUST_BACKTRACE=full syncthing-gtk (as suggested by syncthing-gtk after shorter error messages), the output is:
I StatusIcon Using backend StatusIconGTK3 (primary)
I App
I App Syncthing-GTK started and running in notification area
(.syncthing-gtk-real:3861): Gdk-CRITICAL **: 17:05:06.225: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed
thread '<unnamed>' panicked at 'Type RsvgHandle has already been registered', /tmp/guix-build-librsvg-2.50.7.drv-0/librsvg-2.50.7/guix-vendor/rust-glib-0.9.3.tar.gz/src/subclass/types.rs:485:13
stack backtrace:
0: 0x7fb2b7bab67d - <unknown>
1: 0x7fb2b7c6969c - <unknown>
2: 0x7fb2b7b9ff75 - <unknown>
3: 0x7fb2b7ba591b - <unknown>
4: 0x7fb2b7ba54fb - <unknown>
5: 0x7fb2b7ba605e - <unknown>
6: 0x7fb2b7bac317 - <unknown>
7: 0x7fb2b7bab7bc - <unknown>
8: 0x7fb2b7ba5b72 - <unknown>
9: 0x7fb2b772e70b - <unknown>
10: 0x7fb2b7741cbb - <unknown>
11: 0x7fb2b772e538 - <unknown>
12: 0x7fb2b7733351 - rsvg_rust_handle_get_type
13: 0x7fb2d23e4463 - g_registered_type_info_get_g_type
14: 0x7fb2d25610ed - _wrap_g_registered_type_info_get_g_type
15: 0x7fb2d2d94317 - <unknown>
16: 0x7fb2d2d007c8 - _PyEval_EvalFrameDefault
17: 0x7fb2d2e3c03c - <unknown>
18: 0x7fb2d2d47e1e - _PyFunction_Vectorcall
19: 0x7fb2d2d4ae48 - <unknown>
20: 0x7fb2d2db9642 - <unknown>
21: 0x7fb2d2cfdf0e - _PyEval_EvalFrameDefault
22: 0x7fb2d2cf968b - <unknown>
23: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
24: 0x7fb2d2e3c03c - <unknown>
25: 0x7fb2d2d47e1e - _PyFunction_Vectorcall
26: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
27: 0x7fb2d2cf968b - <unknown>
28: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
29: 0x7fb2d2cf968b - <unknown>
30: 0x7fb2d2d4adc4 - <unknown>
31: 0x7fb2d256a7b1 - pyg_closure_marshal
32: 0x7fb2d23904af - g_closure_invoke
33: 0x7fb2d23a1fcb - signal_emit_unlocked_R.isra.0
34: 0x7fb2d2556f21 - pygobject_emit
35: 0x7fb2d2d52020 - <unknown>
36: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
37: 0x7fb2d2cf968b - <unknown>
38: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
39: 0x7fb2d2cf968b - <unknown>
40: 0x7fb2d2d4adc4 - <unknown>
41: 0x7fb2d2cff09a - _PyEval_EvalFrameDefault
42: 0x7fb2d2cf968b - <unknown>
43: 0x7fb2d2d4adc4 - <unknown>
44: 0x7fb2d256cb78 - _pygi_closure_handle
45: 0x7fb2d2375446 - <unknown>
46: 0x7fb2d23758d0 - <unknown>
47: 0x7fb2d21bf919 - g_task_return_now
48: 0x7fb2d21c040b - g_task_return.part.0
49: 0x7fb2d218a2e5 - read_bytes_callback
50: 0x7fb2d218b807 - async_ready_callback_wrapper
51: 0x7fb2d21bf919 - g_task_return_now
52: 0x7fb2d21bf959 - complete_in_idle_cb
53: 0x7fb2d246136f - g_main_context_dispatch
54: 0x7fb2d24616e8 - g_main_context_iterate.constprop.0
55: 0x7fb2d246178f - g_main_context_iteration
56: 0x7fb2d21ed4c5 - g_application_run
57: 0x7fb2d237573d - <unknown>
58: 0x7fb2d23744ec - <unknown>
59: 0x7fb2d256f376 - pygi_invoke_c_callable
60: 0x7fb2d25710ea - pygi_function_cache_invoke
61: 0x7fb2d2d47b69 - PyObject_Call
62: 0x7fb2d2cff09a - _PyEval_EvalFrameDefault
63: 0x7fb2d2e3c03c - <unknown>
64: 0x7fb2d2d47e1e - _PyFunction_Vectorcall
65: 0x7fb2d2d00310 - _PyEval_EvalFrameDefault
66: 0x7fb2d2e3c03c - <unknown>
67: 0x7fb2d2e3c37d - PyEval_EvalCode
68: 0x7fb2d2e816f5 - <unknown>
69: 0x7fb2d2e82f4d - PyRun_SimpleFileExFlags
70: 0x7fb2d2ea1ae7 - <unknown>
71: 0x7fb2d2ea20f8 - Py_BytesMain
72: 0x7fb2d28fd7dd - __libc_start_main
73: 0x40107a - _start
74: 0x0 - <unknown>
fatal runtime error: failed to initiate panic, error 5
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Sun, 19 Dec 2021 03:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52651 <at> debbugs.gnu.org (full text, mbox):
I should have specified it worked on core-updates-frozen before the last big changes (input style, etc.) and merge into master.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Sun, 19 Dec 2021 19:59:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 52651 <at> debbugs.gnu.org (full text, mbox):
On Sat Dec 18, 2021 at 9:38 PM CST, John Kehayias via Bug reports for GNU Guix wrote:
> I should have specified it worked on core-updates-frozen before the last
> big changes (input style, etc.) and merge into master.
I've just ran some updates and I'm on
guix (GNU Guix) b3a0db7a0e5fa7186c090647cfd5666e2b9287ff
syncthing-gtk appears to launch fine for me
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Sun, 19 Dec 2021 20:10:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52651 <at> debbugs.gnu.org (full text, mbox):
Hi,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, December 19th, 2021 at 2:57 PM, bdju wrote:
> On Sat Dec 18, 2021 at 9:38 PM CST, John Kehayias via Bug reports for GNU Guix wrote:
>
> > I should have specified it worked on core-updates-frozen before the last
> > big changes (input style, etc.) and merge into master.
>
> I've just ran some updates and I'm on
> guix (GNU Guix) b3a0db7a0e5fa7186c090647cfd5666e2b9287ff
> syncthing-gtk appears to launch fine for me
Thanks for checking. I'm on the same Guix commit. Are you sure syncthing-gtk is up to date? I'm running on just a WM (XMonad) on Xorg, perhaps that is a difference? My path for syncthing-gtk is:
/gnu/store/nlslvhw9sqgiwjh036zh66rcs0zgh97s-syncthing-gtk-0.9.4.4-1.c46fbd8
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Sun, 19 Dec 2021 20:16:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 52651 <at> debbugs.gnu.org (full text, mbox):
On Sun Dec 19, 2021 at 2:09 PM CST, John Kehayias wrote:
> Thanks for checking. I'm on the same Guix commit. Are you sure
> syncthing-gtk is up to date? I'm running on just a WM (XMonad) on Xorg,
> perhaps that is a difference? My path for syncthing-gtk is:
>
> /gnu/store/nlslvhw9sqgiwjh036zh66rcs0zgh97s-syncthing-gtk-0.9.4.4-1.c46fbd8
I'm using Sway, which is as close to just running a WM as you can get on
Sway.
My path according to the `whereis syncthing-gtk` output is:
/gnu/store/3li6xh09g5w0ychn2b7jknglqg3pmyl8-profile/bin/syncthing-gtk
When launched, I can go to About and see the version says "unknown
(Daemon v1.16.1)
Oh, I get a path more like yours if I run an ls on the whereis output:
/gnu/store/nlslvhw9sqgiwjh036zh66rcs0zgh97s-syncthing-gtk-0.9.4.4-1.c46fbd8/bin/syncthing-gtk
It looks like we're both on 0.9.4.4-1.c46fbd8 in that case.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Sun, 19 Dec 2021 20:18:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 52651 <at> debbugs.gnu.org (full text, mbox):
On Sun Dec 19, 2021 at 2:10 PM CST, bdju via Bug reports for GNU Guix wrote:
> I'm using Sway, which is as close to just running a WM as you can get on
> Sway.
Meant to say "on Wayland"!
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Sun, 19 Dec 2021 21:08:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 52651 <at> debbugs.gnu.org (full text, mbox):
Thanks for the details, and I figured out the problem, though not sure of the fix. A similar issue was reported upstream some time ago: https://github.com/kozec/syncthing-gtk/issues/428 and https://gitlab.gnome.org/GNOME/librsvg/-/issues/210
The answer was that multiple librsvg were being used. I checked our syncthing-gtk (the wrapper around .syncthing-gtk-real) and there are two different librsvg store paths in GI_TYPELIB_PATH. Removing the first one fixes the problem for me, but not removing the second one.
Looking at guix gc --references for both of them shows an identical list of references (other than themselves). Any idea what is going on here?
This is the variable from the wrapper script:
export GI_TYPELIB_PATH="/gnu/store/8g4rvram1vmir3kbmizbdkbzyvfx6rqh-gtk+-3.24.30/lib/girepository-1.0:/gnu/store/qsdlm238an63wb765ldd04kn1ac3z8wc-libappindicator-12.10.0/lib/girepository-1.0:/gnu/store/q4ys65dcqg8bvndh2260h1zhydv46n1f-libnotify-0.7.9/lib/girepository-1.0:/gnu/store/wh2j9mz03vx3x6kajv0mdqgf6igd6r0j-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/3pim1cxlfw07r08wsbkx35w6i2xj46i6-pango-1.48.10/lib/girepository-1.0:/gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/agd34525iczpyzn27zdhghy10yfiby6n-atk-2.36.0/lib/girepository-1.0:/gnu/store/pjp4d4sl00nzfdbh27qkvb47c1fb525s-libdbusmenu-16.04.0/lib/girepository-1.0:/gnu/store/a8dljzmb4w921bz3pxvfp0d2v7yzw1bb-gdk-pixbuf-2.42.4/lib/girepository-1.0:/gnu/store/dswp2mfwb56xg57903cvhwcjj1fpdhqi-harfbuzz-2.8.2/lib/girepository-1.0:/gnu/store/6p5vr2dbvrcg5yd7frjhkbm1q5mapcs0-at-spi2-core-2.40.0/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Mon, 20 Dec 2021 01:12:02 GMT)
Full text and
rfc822 format available.
Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sun, Dec 19, 2021 at 09:06:55PM +0000, John Kehayias via Bug reports for GNU Guix wrote:
> Thanks for the details, and I figured out the problem, though not sure of the fix. A similar issue was reported upstream some time ago: https://github.com/kozec/syncthing-gtk/issues/428 and https://gitlab.gnome.org/GNOME/librsvg/-/issues/210
>
> The answer was that multiple librsvg were being used. I checked our syncthing-gtk (the wrapper around .syncthing-gtk-real) and there are two different librsvg store paths in GI_TYPELIB_PATH. Removing the first one fixes the problem for me, but not removing the second one.
>
> Looking at guix gc --references for both of them shows an identical list of references (other than themselves). Any idea what is going on here?
>
> This is the variable from the wrapper script:
>
> export GI_TYPELIB_PATH="/gnu/store/8g4rvram1vmir3kbmizbdkbzyvfx6rqh-gtk+-3.24.30/lib/girepository-1.0:/gnu/store/qsdlm238an63wb765ldd04kn1ac3z8wc-libappindicator-12.10.0/lib/girepository-1.0:/gnu/store/q4ys65dcqg8bvndh2260h1zhydv46n1f-libnotify-0.7.9/lib/girepository-1.0:/gnu/store/wh2j9mz03vx3x6kajv0mdqgf6igd6r0j-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/3pim1cxlfw07r08wsbkx35w6i2xj46i6-pango-1.48.10/lib/girepository-1.0:/gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/girepository-1.0:/gnu/store/agd34525iczpyzn27zdhghy10yfiby6n-atk-2.36.0/lib/girepository-1.0:/gnu/store/pjp4d4sl00nzfdbh27qkvb47c1fb525s-libdbusmenu-16.04.0/lib/girepository-1.0:/gnu/store/a8dljzmb4w921bz3pxvfp0d2v7yzw1bb-gdk-pixbuf-2.42.4/lib/girepository-1.0:/gnu/store/dswp2mfwb56xg57903cvhwcjj1fpdhqi-harfbuzz-2.8.2/lib/girepository-1.0:/gnu/store/6p5vr2dbvrcg5yd7frjhkbm1q5mapcs0-at-spi2-core-2.40.0/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"
Thanks for the report. I believe this is fixed with commit
99f290bf5ba59e3218b95d7505ac27f989250aad
Please let us know if this bug is closed in error.
Reply sent
to
Leo Famulari <leo <at> famulari.name>
:
You have taken responsibility.
(Mon, 20 Dec 2021 01:12:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
John Kehayias <john.kehayias <at> protonmail.com>
:
bug acknowledged by developer.
(Mon, 20 Dec 2021 01:12:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52651
; Package
guix
.
(Mon, 20 Dec 2021 01:40:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 52651 <at> debbugs.gnu.org (full text, mbox):
Thanks for pushing and closing Leo!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 17 Jan 2022 12:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 152 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.