bug#57417: Emacs crashes due to symbol lookup error to rsvg_handle_set_stylesheet
Hey fellow Guix users, I’m trying to use Emacs on my system but it tends to crash unexpectedly. When launching it from a terminal, I get: > grokkingstuff@grokkingNoether ~$ emacs > (process:32402): Gtk-WARNING **: 22:59:14.455: Locale not supported by C > library. > Using the fallback 'C' locale. > /home/grokkingstuff/.guix-profile/bin/emacs: symbol lookup error: > /home/grokkingstuff/.guix-profile/bin/emacs: undefined symbol: > rsvg_handle_set_stylesheet Trying to use emacs -q, I get a similar message, but it just crashes quickly. > ^Cgrokkingstuff@grokkingNoether ~$ emacs-29.0.50 -q > (process:4018): Gtk-WARNING **: 23:08:35.207: Locale not supported by C > library. > Using the fallback 'C' locale. > /home/grokkingstuff/.guix-profile/bin/emacs-29.0.50: symbol lookup error: > /home/grokkingstuff/.guix-profile/bin/emacs-29.0.50: undefined symbol: > rsvg_handle_set_stylesheet I have librsvg installed, and a few Google searches seem to indicate that this is the issue. I’ve tried building from source using "guix install -S” but I don’t see any difference. If there’s anything I could do to assist with this bug report, please let me know. Thank you so much for your time and effort. Sincerely, Vishakh Kumar (grokkingstuff)
bug#57136: Snakemake cannot execute remote jobs
The other problem that Matthieu pointed out (but which is unrelated to the initial bug report) is fixed by the following two patches for snakemake-6 and snakemake-7: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57414 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57415 Cheers, Konrad
bug#57136: Snakemake cannot execute remote jobs
I have submitted a patch that fixes this problem: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57413 This is the patch that Matthieu referred to, and which he tested in a cluster environment. Cheers, Konrad
bug#57391: "error: connect*: Connection timed out" when using 6+ jobs to fetch substitutes
On 24-08-2022 22:42, Maxim Cournoyer wrote: It fails like the above when the number of jobs is 6 or higher, but proceeds without error when the number of jobs is 5 or less. I do not think the network to be at caused, as everything is cabled and the link is healthy and fast. I encounter less "connect*: Connection timed out" after setting -M5, but it still sometimes happens: /gnu/store/vifx9ajaa65624f412bqqcdk4k83v461-flite-2.2-checkout vervangen... guix substitute: waarschuwing: tijdens het binnenhalen van https://ci.guix.gnu.org/nar/lzip/vifx9ajaa65624f412bqqcdk4k83v461-flite-2.2-checkout: de server is een beetje traag guix substitute: waarschuwing: probeer ‘--no-substitutes’ als het probleem hardnekkig is guix substitute: fout: connect*: Verbinding is verlopen vervanging van /gnu/store/vifx9ajaa65624f412bqqcdk4k83v461-flite-2.2-checkout mislukt guix build: fout: beschadigde invoer tijdens het terugplaatsen van het archief uit # Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#57402: FreeCAD build fails to configure / Qt5WebKitWidgets related.
The freecad package fails to build. The following error is the relevant part from the log. I'm on powerpc64le, which is usually somewhat problematic in building. Not sure if that is relevant for this issue though. --8<---cut here---start->8--- CMake Error at cMake/FreeCAD_Helpers/SetupQt.cmake:28 (find_package): By not providing "FindQt5WebKitWidgets.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5WebKitWidgets", but CMake did not find one. Could not find a package configuration file provided by "Qt5WebKitWidgets" with any of the following names: Qt5WebKitWidgetsConfig.cmake qt5webkitwidgets-config.cmake Add the installation prefix of "Qt5WebKitWidgets" to CMAKE_PREFIX_PATH or set "Qt5WebKitWidgets_DIR" to a directory containing one of the above files. If "Qt5WebKitWidgets" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:69 (include) -- Configuring incomplete, errors occurred! --8<---cut here---end--->8---
bug#56322: [PATCH] gnu: ruby: regenerate parse.c
* gnu/packages/ruby.scm (baseruby, ruby-2.7): Use bootstrap baseruby to
regenerate parse.c
---
gnu/packages/ruby.scm | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index e98814da6d..8de6cda257 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -161,7 +161,16 @@ (define-public ruby-2.7
version ".tar.gz"))
(sha256
(base32
-"0nxwkxh7snmjqf787qsp4i33mxd1rbf9yzyfiky5k230i680jhrh"
+"0nxwkxh7snmjqf787qsp4i33mxd1rbf9yzyfiky5k230i680jhrh"))
+ (snippet `(begin
+ ;; Remove bundled libffi
+ (delete-file-recursively "ext/fiddle/libffi-3.2.1")
+ ;; Trigger bootstap
+ (delete-file "configure")
+ (delete-file "aclocal.m4")
+ ;; Trigger rebuild of parse.c from parse.y
+ (delete-file "parse.c")
+ #t
(arguments
`(#:test-target "test"
#:configure-flags '("--enable-shared") ;dynamic linking
@@ -181,7 +190,24 @@ (define-public ruby-2.7
"test/ruby/test_system.rb"
"tool/rbinstall.rb")
(("/bin/sh")
- (which "sh"))) #t)))
+ (which "sh"))) #t)
+(native-inputs (list autoconf automake baseruby bison
+
+(define baseruby ;; used to build ruby by parser generator
+ (package
+(inherit ruby-2.7)
+(name "baseruby")
+(source (origin
+ (inherit (package-source ruby-2.7))
+ ;; override snippet to not include deletion of bundled parse.c
+ (snippet `(begin
+ ;; Remove bundled libffi
+ (delete-file-recursively "ext/fiddle/libffi-3.2.1")
+ ;; Trigger bootstap
+ (delete-file "configure")
+ (delete-file "aclocal.m4")
+ #t
+(native-inputs (list autoconf automake
(define-public ruby-3.0
(package
--
2.37.2
bug#56322: Ruby packaging issues
2022/08/24 20:38, Maxime Devos: > We have a bunch of old rubies packaged, maybe it can be generated with > one of the old versions? Though possibly the old versions have the > same problem, I haven't checked. Older rubies need ruby to compile too, I checked. To totally getting rid of parse.c is not easy. > If not: fully properly generating it might not be possible, but > something in-between could be an option: > > 1. First, use the pre-generated parse.c. > 2. Once ruby is built, regenerate the parse.c, and verify that it is >the same as the old parse.c (ignoring the timestamp) > >> What's to gain by this? > > (1) I would assume it is much easier to hide malware in a generated > file like parse.c than in the real source code (*) (IIRC, the .c code > generated by bison is much longer than the .y). By generating the > parse.c, the potential issue is side-stepped; any security reviewers > wouldn't even have to look at parse.c because the pre-generated > parse.c isn't used, it's regenerated. By using one ruby to support compiling the others said security reviewer can focus on one particular parse.c. It's big but reviewing it seems doable but I am no security reviewer. > (2) Also: generators like Bison can have bugs, fixed in later > versions. Now imagine that Bison had, say, a buffer overflow bug, and > that distro's just used the pre-generated parse.c. Then once a fixed > version of Bison comes out, we would have to check every package to > see if it has a pre-generated parser. It would be much less stressful > to just always generate parsers from source, then once the version of > Bison in Guix is updated then all packages automatically get the > buffer overflow fix. > > I don't think my in-between proposal helps much with (1) in case of a > competent attacker (though it could stop some insufficiently > sophisticated attacks where the parse.c malware doesn't try to subvert > the later check), but it still helps with (2) -- it at least detects > if ruby used an old bison (and hence that a patch might be in order) The two phase build approach (first building with parse.c and then using that ruby as native-input for a package with parse.c removed) seems to work but with some notes. Rubies 2.7 and up work fine with bison current in guix (bison-3.7.6) but ruby-2.6 (and possibly down) don't because they trigger some incompatibility between bison-3.5.1 (stated as parse.c generator in ruby-2.6) and bison-3.7.6. I tried bison-3.0 from gnu/packages/bison for ruby-2.6 and it works but using that kinda defeats the ".. automatically get the buffer overflow fix" argument. I'd say, it doesn't really matter for ruby-2.6 and down since they are EOL anyway and should at some point be removed from guix. I'll post a patch after this message for feedback. In it a new package is introduced based on ruby-2.7 named baseruby which is compiled with the parse.c from the tarball, ruby-2.7 and up will delete parse.c before build and have extra native-inputs on baseruby and bison to support the magic. Cheers, Remco
bug#39490: [core-updates] fftw 3.3.8 test suite can hang
For me it build successfully with --cores=1. I'll try --keep-failed and try to determine which one of the --verify is the cause ... Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#39490: [core-updates] fftw 3.3.8 test suite can hang
Hangs have been noticed elsewhere: https://github.com/FFTW/fftw3/issues/131 (Alpine, on a s390x) Unknown if the cause is the same. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#39490: [core-updates] fftw 3.3.8 test suite can hang
On 07-02-2020 20:08, Maxim Cournoyer wrote: I encountered a single occurrence of this while building core-updates (2073b55e6b964cb8ca15e8c74cb32dac00f05f0d). I couldn't reproduce the hang a 2nd time, but in case it'd occur to someone else, I'm reporting the problem here. The build appears to be hung, peeking a single CPU core with no output. I've encountered the same here (*) -- I do not have access to the latest output (only in /var/log/..., but apparently due to the buffering for the compression, the 'Executing ...' is not available yet'), but the same command appears in 'htop'. (*) nthreads=2, running time=4 hours and 55 minutes and counting, available CPUs = 16 as counted by /sys/devices/system/cpu. The last output printed is: --8<---cut here---start->8--- Executing "/tmp/guix-build-fftw-3.3.8.drv-0/fftw-3.3.8/tests/bench -o nthreads=2 --verbose=1 --verify 'ofr39v157' --verify 'ifr39v157' --verify '//obc39v157' --verify '//ibc39v157' --verify '//ofc39v157' --verify '//ifc39v157' --verify 'obc39v157' --verify 'ibc39v157' --verify 'ofc39v157' --verify 'ifc39v157' --verify 'ok7e00x27o11v28' --verify 'ik7e00x27o11v28' --verify '//obr23232' --verify '//ibr23232' --verify '//ofr23232' --verify '//ifr23232' --verify 'obr23232' --verify 'ibr23232' --verify 'ofr23232' --verify 'ifr23232' --verify '//obc23232' --verify '//ibc23232' --verify '//ofc23232' --verify '//ifc23232' --verify 'obc23232' --verify 'ibc23232' --verify 'ofc23232' --verify 'ifc23232' --verify 'ok11e11x6bv16' --verify 'ik11e11x6bv16' --verify 'obr3x6v25' --verify 'ibr3x6v25' --verify 'ofr3x6v25' --verify 'ifr3x6v25' --verify '//obc3x6v25' --verify '//ibc3x6v25' --verify '//ofc3x6v25' --verify '//ifc3x6v25' --verify 'obc3x6v25' --verify 'ibc3x6v25' --verify 'ofc3x6v25' --verify 'ifc3x6v25' --verify 'ok10bx8e10x7bx5o01*8' --verify 'ik10bx8e10x7bx5o01*8'" ofr39v157 3.88346e-16 2.86256e-16 7.57002e-16 ifr39v157 3.47982e-16 2.86256e-16 7.02064e-16 //obc39v157 3.94083e-16 5.72513e-16 8.78504e-16 //ibc39v157 4.03859e-16 4.29385e-16 9.40757e-16 //ofc39v157 4.42394e-16 4.29385e-16 8.87713e-16 //ifc39v157 4.12348e-16 4.29385e-16 8.5851e-16 obc39v157 4.0602e-16 4.29385e-16 8.48734e-16 ibc39v157 3.73274e-16 4.29385e-16 8.9751e-16 ofc39v157 3.97926e-16 4.29385e-16 8.07659e-16 ifc39v157 4.07119e-16 4.29385e-16 7.61853e-16 ok7e00x27o11v28 3.41262e-16 4.83151e-15 3.96424e-16 ik7e00x27o11v28 3.94159e-16 4.37137e-15 3.94158e-16 (^) maybe the ik7e00x27o11v28 is responsible somehow? TBI ... Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
