bug#41437: build-system-asdf errors if a system name is too short

Katherine Cox-Buday skribis: > #+BEGIN_EXAMPLE > 10:06 katco says: guix --version > guix (GNU Guix) c660779722f4130e95cda89c0eb0cff534a89ef2 > #+END_EXAMPLE > > I am packaging a system called ~sbcl-1am~, and I discovered that unless > I make the package name longer, I receive this cryptic error

bug#48225: Wrong result of package-name->name+version

Ludovic Courtès skribis: > Hi Guillaume, > > Guillaume Le Vaillant skribis: > >> From 1e37a89b943a818b5274c1d5f31143ca48bad40a Mon Sep 17 00:00:00 2001 >> From: Guillaume Le Vaillant >> Date: Thu, 6 May 2021 10:32:56 +0200 >> Subject: [PATCH] build-system:

bug#46424: Use load-systems or load-systems*

In the case of quri, it looks like the problem comes from the "(asdf:clear-system c)" call at the end of "quri-test.asd". When removing it, the build succeeds even without the custom 'asd-systems' argument in the Guix package definition. So it looks like the lazy loading of system definitions is

bug#48282: CI fails to build opencv on x86-64

Hi, It looks like the build farm fails to build the opencv package on x86-64. The build log (see [1] or [2]) indicates that the build "timed out after 3600 seconds of silence" in the test phase, more precisely in the 'opencv_test_aruco' test. What is strange is that on my machine the build

bug#48225: Wrong result of package-name->name+version

WDYT? From 1e37a89b943a818b5274c1d5f31143ca48bad40a Mon Sep 17 00:00:00 2001 From: Guillaume Le Vaillant Date: Thu, 6 May 2021 10:32:56 +0200 Subject: [PATCH] build-system: asdf: Work around package-name->name+version bug. This patch modifies how the name of the main Common Lisp system is ex

bug#48225: Wrong result of package-name->name+version

Hi, The 'package-name->name+version' function defined in "guix/build/utils.scm" returns a wrong result if there is a '-' followed by a number in the package name: --8<---cut here---start->8--- (use-modules ((guix build utils))) (package-name->name+version

bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)

The cl-environments and generic-cl packages are currently in Guix (36d4877041e0651d1af56b47127b8566c0fd0259). Closing. signature.asc Description: PGP signature

bug#42726: bigloo 4.3f test fail

Fixed in commit 041d62f7cc244d7f6c0bd6d60cdf08e72d400313. signature.asc Description: PGP signature

bug#47654: electron-cash fails to start

Fixed in c901ec27d7e437c200f04263c1cdccdcd864956c. signature.asc Description: PGP signature

bug#47654: electron-cash fails to start

The electron-cash program fails to start and prints the following error: --8<---cut here---start->8--- Traceback (most recent call last): File "/gnu/store/34h2k23x2yzm8gycbxkjmq7aqnlzmi7x-electron-cash-4.2.4/bin/.electron-cash-real", line 96, in from

bug#47628: webkitgtk-2.32.0 is broken on my system

Mark H Weaver skribis: > retitle 47628 webkitgtk-2.32.0 is broken on my system > thanks > > Mark H Weaver writes: > >> FYI, since updating to webkitgtk-2.32.0 (commit >> 3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no >> window appears, although GNOME Shell shows an

bug#33848: Store references in SBCL-compiled code are "invisible"

Pierre Neidhardt skribis: > Hi Guillaume! > >> A store reference to a C library in a standalone Lisp binary can come >> either from the current package or from some dependencies >> (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source >> code of all the Lisp dependencies recursively

bug#33848: Store references in SBCL-compiled code are "invisible"

Pierre Neidhardt skribis: > If we are going for a SBCL-specific solution, I believe that all > references are stored in plain text files at some points (the .asd files > and the .lisp files) which are often encoded in ASCII / UTF-8, so > searching these files without having to deal with their

bug#47201: sbcl-cl-webkit doesn't protect webkitgtk from garbage collection

Leo Famulari skribis: > On Tue, Mar 16, 2021 at 11:40:05PM +, pkill9 wrote: >> I have nyxt installed, which has sbcl-cl-webkit as an input, which has >> webkitgtk as an input, and recently it produced an error which was >> fixed by building webkitgtk, so it wasn't in the store. >> >>

bug#46624: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SEC

Sharlatan Hellseher skribis: > Hi, > > Yes it looks like issue on my end only. > I've doped my local branch pull upstream and I could rebuild it now. > Issue could be closed. > > Thanks > > hellseher@guix-base-20210210 ~/code/guix [env]$ ./pre-inst-env guix > build sbcl-cffi > ;;; note: source

bug#46624: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SEC

Sharlatan Hellseher skribis: > ./pre-inst-env guix build sbcl-cffi ;;; note: source file > /home/hellseher/code/guix/gnu/packages/lisp-xyz.scm ;;; newer than > compiled /home/hellseher/code/guix/gnu/packages/lisp-xyz.go Too many > heap sections: Increase MAXHINCR or MAX_HEAP_SECS > Aborted

bug#46461: [core-updates] fldigi missing source tarball

Danny Milosavljevic skribis: > building > /gnu/store/h293gw17xn750v7sbhxrjkrq99h4mbn3-fldigi-4.1.17.tar.gz.drv... > > Starting download of > /gnu/store/7y7xa4ks27s0i77bcllxypakl2fcivlv-fldigi-4.1.17.tar.gz > From http://www.w1hkj.com/files/fldigi/fldigi-4.1.17.tar.gz... > download failed

bug#46424: ASDF build system sometimes fails to load .asd files properly

Pierre Neidhardt skribis: > Yesterday I pushed 3aba721da73fbdc3382cc098c41596d5cfbb29eb > "gnu: sbcl-quri: Update to 20200209", which fixes the tests for sbcl-quri. > > I noted: > > --8<---cut here---start->8--- >;; Test system must be loaded before,

bug#46365: Build fails for clementine 1.3.1-2.4619a4c

Hi, Clementine has been updated to version 1.4.0rc1-450 on the master branch. If you 'guix pull' and 'guix upgrade', it should work. I'm closing this bug, but feel free to open a new bug if you get an issue with version 1.4.0rc1. signature.asc Description: PGP signature

bug#46294: python-arrow timezone test failure

Hi, The python-arrow package currently fails to build because the "test_parse_tz_name_zzz" test is failing. This is with Guix at eae865c134ebb8b7432572288e8721794d6a9b87. I'm not very familiar with Python, so does someone know how to fix this? Here's the relevant part of the build log:

bug#44112: SBCL is not reproducible

zimoun skribis: > Hi, > > On Wed, 21 Oct 2020 at 14:41, Guillaume Le Vaillant wrote: >> zimoun skribis: >> >>> Using Guix 58af4c9, the package ’sbcl’ seems not-reproducible. > > [...] > >> Removing this source file timestamp from compiled files w

bug#45826: SBCL / Common Lisp packages fail to build on aarch64

Leo Famulari skribis: > On Wed, Jan 13, 2021 at 10:03:47PM +0100, Guillaume Le Vaillant wrote: >> I tried to bootstrap sbcl using ecl instead of clisp, using >> "guix build -s aarch64-linux sbcl" on a x86-64 machine because I don't >> have any arm64 hardware, but

bug#45826: SBCL / Common Lisp packages fail to build on aarch64

Leo Famulari skribis: > I noticed that many Common Lisp or SBCL-related packages are failing to > build on the aarc64 platform on our build farm, due the failure to build > SBCL: > > From the log of : > > -- > //entering make-target-2.sh >

bug#45236: Xboard doesn't work.

zimoun skribis: > Hi, > > On Tue, 15 Dec 2020 at 12:26, Ludovic Courtès wrote: >>> I think this is not about you but Xboard game is not working for so long, I >>> wait until update but is not coming. >> >> What do you mean by “not working”? I’ve tried: >> >> guix environment --ad-hoc xboard

bug#45017: asdf-build-system packages have priority over user ones

Pierre Neidhardt skribis: > Guillaume Le Vaillant writes: > >> Updated patches in attachment. >> Do you see something else to fix or improve? > > Tested and approved! > > I suggest we merge on master since this is not very disruptive and it > fixes a regression

bug#45017: asdf-build-system packages have priority over user ones

Updated patches in attachment. Do you see something else to fix or improve? From 757b4f4a84fdbcbd26148f2a170d84ba8c128c7a Mon Sep 17 00:00:00 2001 From: Guillaume Le Vaillant Date: Thu, 3 Dec 2020 14:52:02 +0100 Subject: [PATCH 1/6] gnu: cl-asdf: Improve priorities of configuration file search

bug#45017: asdf-build-system packages have priority over user ones

Pierre Neidhardt skribis: > Tested! > > I've installed sbcl to my "common-lisp" profile along quri. > I've also cloned quri to ~/common-lisp. > > Then: > > --8<---cut here---start->8--- > $ sbcl > * (asdf:locate-system :quri) > T > NIL >

bug#45017: asdf-build-system packages have priority over user ones

Pierre Neidhardt skribis: > A few comments: > >> @@ -603,7 +603,8 @@ statistical profiler, a code coverage tool, and many >> other extensions.") >> "0x4bjx6cxsjvxyagijhlvmc7jkyxifdvz5q5zvz37028va65243c") >> (_ >>

bug#45017: asdf-build-system packages have priority over user ones

Guillaume Le Vaillant skribis: > The Lisp systems of sbcl-* and ecl-* packages installed in a profile are > supposed to be already compiled and immutable, so recompiling them > anyway would require tweaking the ASDF configuration from inside SBCL to > remove the output

bug#45017: asdf-build-system packages have priority over user ones

Pierre Neidhardt skribis: > Guillaume Le Vaillant writes: > >> SBCL and ECL are patched to use our cl-asdf because it is necessary to >> build the sbcl-* and ecl-* packages. Also patching ABCL, CCL, and Clisp >> sounds like a good idea. At least all the compilers would

bug#45017: asdf-build-system packages have priority over user ones

Pierre Neidhardt skribis: > Thanks for taking a shot at this, looks great! > > I'll test later, but for now one question: we patch sbcl to use our > cl-asdf, but what about the other compilers? Seems to me that the other > compilers are going to have the same problem, aren't they? SBCL and

bug#45017: asdf-build-system packages have priority over user ones

f0d16 Mon Sep 17 00:00:00 2001 From: Guillaume Le Vaillant Date: Thu, 3 Dec 2020 14:52:02 +0100 Subject: [PATCH] gnu: cl-asdf: Improve priorities of configuration file search. * gnu/packages/patches/cl-asdf-config-directories.patch: New file. * gnu/local.mk (dist_PATCH_DATA): Add it. * gnu

bug#45017: asdf-build-system packages have priority over user ones

Pierre Neidhardt skribis: > Since staging was merged a few days ago, I've noticed an undesirable > side-effect of our revamped asdf-build-system: the systems packages have > priority over the user-local ones. > > Here is the default list of registries: > > --8<---cut

bug#44925: gdm boot up failure

I had a similar problem today. I booted with a system configured with Guix at 275fcffc9b5f4deb516c510b26b07c13d6e47307 and everything worked fine. Then I reconfigured with Guix at commit 04b83678653fda3c66e600e88f54f5108290ec1c, removed a few dozen old generations and did a 'guix gc'. At the

bug#41631: broken asdf-build-system on some CL source packages

Jiří Špaček skribis: > This problem manifests when installing cl-stumpwm package from > gnu/packages/wm.scm but other cl-* packages are likely to be affected > as well. > > guix build cl-stumpwm fails with: > > ... > phase `unpack' succeeded after 0.0 seconds > starting phase

bug#36504: asdf build system: Add support for component-less .asd

This is now fixed in the master branch (since 4dadb4977908028bb0651d43ed4813cc988db92d). signature.asc Description: PGP signature

bug#44769: [staging] gst-plugins-bad fails tests on aarch64, armhf, i686

Guillaume Le Vaillant skribis: > Marius Bakke skribis: > >> Hello Guix, >> >> gst-plugins-bad fails its test suite on anything other than x86_64-linux. >> >> Upstream issues: >> >> i686: >> https://gitlab.freedesktop.org/gstreamer

bug#44769: [staging] gst-plugins-bad fails tests on aarch64, armhf, i686

Marius Bakke skribis: > Hello Guix, > > gst-plugins-bad fails its test suite on anything other than x86_64-linux. > > Upstream issues: > > i686: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1463 > aarch64: >

bug#44612: Read standard input in `guix repl'

Guillaume Le Vaillant skribis: > It looks like you can get rid of the welcome message by using the '-s' > option: > > $ echo '(display "Hi.\n")' | guile -s /dev/stdin > Hi. Or: $ echo '(display "Hi.\n")' | guix repl /dev/stdin Hi. signature.asc Description: PGP signature

bug#44612: Read standard input in `guix repl'

Tobias Geerinckx-Rice via Bug reports for GNU Guix skribis: > Pierre, > > Pierre Neidhardt 写道： >> and... it works! O.o > > Don't you hate it when that happens? Ban bug suicide. > > (Does that mean this one can be closed? Or retitled, if we want to debug > Nyxt? :-) > >> For future reference,

bug#44558: Mesa isn't update to date

Marius Bakke skribis: > Guillaume Le Vaillant writes: > >> Tobias Geerinckx-Rice via Bug reports for GNU Guix >> skribis: >> >>> Romulasry, are you suffering from specific Mesa 20.0.7 problems that 20.2.2 >>> might fix? Please let us kno

bug#44558: Mesa isn't update to date

Tobias Geerinckx-Rice via Bug reports for GNU Guix skribis: > Romulasry, are you suffering from specific Mesa 20.0.7 problems that 20.2.2 > might fix? Please let us know. An otherwise working package not being at the > latest upstream version isn't a bug. > > romulasry via Bug reports for GNU

bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?

Pierre Neidhardt skribis: > Pierre Neidhardt writes: > >> It failed with "5Gb", it worked with "6000". >> I'm testing with "5000" since upstream said it worked for them. > > Nope, it does not :p > > So which value should we set? It's not because 6000 passes on my > machine that it will

bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?

Pierre Neidhardt skribis: > Guillaume Le Vaillant writes: > >> I guess we could increase the default max space size to 4 or 5 GB >> without causing swapping issues on users' machines (at least on x86-64). >> And users wanting a smaller one can use the "dynamic-spa

bug#44552: Extra dynamic-space-size for asdf-build-system/sbcl?

Pierre Neidhardt skribis: > See https://github.com/alex-gutev/generic-cl/issues/6 > > The space size of our current SBCL package is 2Gb. > Shall we increase it to 5Gb? > > What about adding an option to the build system to pass extra parameters > to SBCL? Then we could pass

bug#44548: Acknowledgement (SBCL build system fails to pacakge cl-environments, generic-cl.)

It looks like the files in "src/common/" must be compiled in a specific order because some files depend on others, but the system definition has neither the ":depends-on xyx" nor the ":serial t" indications. It causes the functions defined in "src/common/util.lisp" not being available when

bug#44112: SBCL is not reproducible

zimoun skribis: >> Removing this source file timestamp from compiled files would simplify >> things. Maybe nothing really depends on it and it would be possible... > >Thanks for the explanation. A developer of SBCL agrees that the timestamp should be removed [1], but currently Slime has a

bug#44112: SBCL is not reproducible

zimoun skribis: > Using Guix 58af4c9, the package ’sbcl’ seems not-reproducible. > > [...] > > I do not know if the patches in ’staging’ will fix this. > > Note that this issue does not imply that the build system > ’asdf-build-system/sbcl’ is or will be not reproducible. However, this >

bug#42667: opencv fails to build

This was fixed by 8bf704262d672ae0735f0685bfd1c9ddcb1d8484, closing. signature.asc Description: PGP signature

bug#42667: opencv fails to build

When trying to build the opencv package , I get the following error: --8<---cut here---start->8--- [ 27%] Building CXX object modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/src/grfmt_pxm.cpp.o cd /tmp/guix-build-opencv-3.4.3.drv-0/build/modules/imgcodecs &&

bug#42321: qgis PyQgsExpressionBuilderWidget test fails

Wiktor Żelazny skribis: > For some time, I’ve been getting the stuff below while trying to build > qgis. Once the test is added to the list of omitted tests (there’s > already a substantial list of tests that fail for unknown reasons in the > package definition), the qgis build completes and

bug#40952: gnuradio-osmosdr: no hook into gnuradio block directory?

Christopher Howard skribis: > Works now, thanks! Am able to feed data in from HackRF using osmosdr > source block. > > (As a side note to posterity reading this: I have the hackrf system > service set in my config.scm, as described in the hackrf package > description.) Ok, closing the bug.

bug#40952: gnuradio-osmosdr: no hook into gnuradio block directory?

Christopher Howard skribis: > I can see the osmosdr sink, insert it into the flow graph, and change > the settings. However, when trying to build the flow graph, I receive > the following error. Apparently you need to also update whatever > environment variable controls the python module load

bug#40952: gnuradio-osmosdr: no hook into gnuradio block directory?

Christopher Howard skribis: > Hi, I installed gnuradio and gnuradio-osmosdr, but when I open > gnuradio, none of the osmosdr blocks are available from gnuradio blocks > list. Specifically, I was looking for osmosdr source block, which I am > familiar with from using gnuradio under Debian. I

bug#40652: #36924 way solves the problem for me

Ludovic Courtès skribis: > ‘%gdm-activation’ would throw an exception if the “gdm” user didn’t > exist, so apparently it’s run before the activation snippet of > ‘account-service-type’ (the ordering guarantee is not explicit.) > > Hmm I wonder what I’m missing then. Would you like to try

bug#40652: #36924 way solves the problem for me

Guillaume Le Vaillant skribis: > Ludovic Courtès skribis: > >> Hi Guillaume, >> >> Guillaume Le Vaillant skribis: >> >>> I don't know if it's related, but recently I had GDM crashes at boot >>> after reconfiguring a system using gdm-service-typ

bug#40652: #36924 way solves the problem for me

Ludovic Courtès skribis: > Hi Guillaume, > > Guillaume Le Vaillant skribis: > >> I don't know if it's related, but recently I had GDM crashes at boot >> after reconfiguring a system using gdm-service-type (generation n) to >> make it use slim-servic

bug#40652: #36924 way solves the problem for me

R Veera Kumar skribis: > The solution in bug #36924 solved the problem in my system. > > Remove /var/lib/gdm and make a empty one instead. > > Thanks Rene! > > Regards, > Veera I don't know if it's related, but recently I had GDM crashes at boot after reconfiguring a system using

bug#39477: sbcl-serapeum yields sbcl loading error in guix environment container

Martin Flack skribis: > Hello, > > This command: > > guix environment --container --no-cwd --ad-hoc sbcl sbcl-serapeum -- \ > sbcl --eval '(require :asdf)' --eval '(require :serapeum)' --quit > > ...yields an error from SBCL: > > ... > ASDF could not load serapeum because > Component

bug#38829: XmlListModel QML missing from qtdeclarative 5.12.x

Guillaume Le Vaillant skribis: > Guillaume Le Vaillant skribis: > >> In version 5.12.6 of the 'qtdeclarative' package, the >> 'lib/qt5/qml/QtQuick/XmlListModel' directory is missing (qtdeclarative >> 5.11.3 had it). >> >> It causes run time issues; for exampl

bug#38829: XmlListModel QML missing from qtdeclarative 5.12.x

Guillaume Le Vaillant skribis: > In version 5.12.6 of the 'qtdeclarative' package, the > 'lib/qt5/qml/QtQuick/XmlListModel' directory is missing (qtdeclarative > 5.11.3 had it). > > It causes run time issues; for example the 'monero-gui' > package builds fine but it fai

bug#38829: XmlListModel QML missing from qtdeclarative 5.12.x

In version 5.12.6 of the 'qtdeclarative' package, the 'lib/qt5/qml/QtQuick/XmlListModel' directory is missing (qtdeclarative 5.11.3 had it). It causes run time issues; for example the 'monero-gui' package builds fine but it fails to run: --8<---cut

bug#38469: guix gc should keep around recent intermediate build ingredients by default

Robert Vollmert skribis: > [ This is a user/developer friendliness feature request. I’m not arguing > that `guix gc` should do anything differently on a technical level, I’m > just trying to argue that the default experience should be different. ] > > Current situation: > I use a forked

bug#38435: BTRFS open_ctree failed

raingloom skribis: > On Sat, 30 Nov 2019 15:53:11 +0100 > Guillaume Le Vaillant wrote: > >> raingloom skribis: >> >> > This is what I get after a recent `guix system reconfigure` : >> > Scanning for Btrfs filesystems >> > [2.3427

bug#38435: BTRFS open_ctree failed

Guillaume Le Vaillant skribis: > raingloom skribis: > >> This is what I get after a recent `guix system reconfigure` : >> Scanning for Btrfs filesystems >> [2.342790] BTRFS error (device sda1): open_ctree failed >> >> Previous profiles work, I haven't m

bug#38435: BTRFS open_ctree failed

raingloom skribis: > This is what I get after a recent `guix system reconfigure` : > Scanning for Btrfs filesystems > [2.342790] BTRFS error (device sda1): open_ctree failed > > Previous profiles work, I haven't modified anything about my config.scm > between them. > > [...] > > > Contents

bug#38256: Packages sources in '.tar.lz' archives

Hi, Currently, when package sources are in a '.tar.lz' archive (e.g. ed, wget, ddrescue, etc.), the 'lzip' package must be explicitly put into the 'native-inputs' of the package definition, or building the package fails. Would it be possible to make the 'lzip' package available by default in the

bug#37977: Mount options ignored for root file system

f0fda6f6a13bf1fdab0fcde4f72ece688d93 Mon Sep 17 00:00:00 2001 From: Guillaume Le Vaillant Date: Sun, 17 Nov 2019 14:15:21 +0100 Subject: [PATCH] linux-boot: Don't ignore options when mounting root file system. * gnu/build/linux-boot.scm (mount-root-file-system): Add the 'options' keyword argumen

bug#37977: Mount options ignored for root file system

Guillaume Le Vaillant skribis: > The filesystem options declared for the root file system are apparently > ignored. This happens for a btrfs root filesystem on a LUKS volume. This also happens on a basic btrfs root file system (without LUKS). I tried adding "rootflags=defaults

bug#37977: Mount options ignored for root file system

The filesystem options declared for the root file system are apparently ignored. This happens for a btrfs root filesystem on a LUKS volume. Exerpt from '/etc/config.scm": --8<---cut here---start->8--- (mapped-devices (list (mapped-device (source

<    1   2