bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant  skribis:
>
>> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>> I fixed a few C/C++ related issues,
>
> Thanks for fixing those!  After <https://issues.guix.gnu.org/49990#10>
> Julien mentioned on IRC that using an older GCC allowed us to work
> around those C++ issues, but your approach looks nicer to me.
>
>> but then I get this error:
>>
>> Preload failed: checksum of class list was incorrect.
>> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>
> Woow, never seen that.  Julien, Ricardo, does that ring a bell?
>
> Java is the main stumbling block on core-updates-frozen; making
> progress!
>
> Thanks,
> Ludo’.

It looks like the checksum failure is caused by the miscompilation of
a multiplication in the function computing the checksum.
I added a workaround to the other fixes in
f8cff361245cc0c546211ff51100cbaf869d15eb, which makes the build succeed.


signature.asc
Description: PGP signature

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Guillaume Le Vaillant]

I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
I fixed a few C/C++ related issues, but then I get this error:

--8<---cut here---start->8---
Preload failed: checksum of class list was incorrect.
make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
--8<---cut here---end--->8---

Does someone know how to solve that?

Here's the patch I'm using to get to this point:
From 6767793eccffea3bfddca5c4a0c0cff21abb965b Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant 
Date: Mon, 13 Sep 2021 14:37:40 +0200
Subject: [PATCH] WIP: gnu: icedtea-6: Fix build.

* gnu/packages/java.scm (icedtea-6)[arguments]: Add 'fix-openjdk' phase.
---
 gnu/packages/java.scm | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 51fc5c60a1..374a9d9cba 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -17,6 +17,7 @@
 ;;; Copyright © 2021 Vincent Legoll 
 ;;; Copyright © 2021 Mike Gerwitz 
 ;;; Copyright © 2021 Pierre Langlois 
+;;; Copyright © 2021 Guillaume Le Vaillant 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -907,6 +908,19 @@ machine.")))
 "patches/hotspot/hs23/drop_unlicensed_test.patch")
(("#!/bin/sh") (string-append "#!" (which "sh"
  #t))
+ (add-after 'unpack 'fix-openjdk
+   (lambda _
+ (substitute* "openjdk/jdk/make/common/Defs-linux.gmk"
+   (("CFLAGS_COMMON  = -fno-strict-aliasing" all)
+(string-append all " -fcommon")))
+ (substitute* "openjdk/hotspot/src/share/vm/code/relocInfo.hpp"
+   (("inline friend relocInfo prefix_relocInfo\\(int datalen = 0\\);")
+"inline friend relocInfo prefix_relocInfo(int datalen);"))
+ (substitute*
+ '("openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c"
+   "openjdk/jdk/src/solaris/native/java/net/PlainDatagramSocketImpl.c")
+   (("#include ")
+"#include "
  (add-after 'unpack 'patch-paths
(lambda* (#:key inputs #:allow-other-keys)
  ;; buildtree.make generates shell scripts, so we need to replace
-- 
2.33.0



signature.asc
Description: PGP signature

bug#49949: [core-updates]: Blender fails to build

[Guillaume Le Vaillant]

Hi,

I got a similar issue on core-updates-frozen with opencv.

I solved it in 463a47f4d737ad645639ed32a1c97cfc3bf00ff0 with:

--8<---cut here---start->8---
-(search-input-directory inputs "include/OpenEXR")
+(string-drop-right
+ (search-input-file inputs "include/OpenEXR/ImathVec.h")
+ 11)
--8<---cut here---end--->8---

It guess this will also work for bender, but I can't test right now
because openvdb which bender depends on fails to build.

I suspect it happens because there are several inputs with
a "include/OpenEXR" directory and 'search-input-directory' doesn't
return the one we're looking for.


signature.asc
Description: PGP signature

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Guillaume Le Vaillant]

Sarah Morgensen  skribis:

> gpredict@2.2.1
> transcode@1.1.7

gpredict and transcode fixed in bd8013ab33159a41a94f6a6cd023d585c91ae2ed
and 92d04bcab34ef7145bd18e5a7d242e38d01d3922.


signature.asc
Description: PGP signature

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Guillaume Le Vaillant]

Sarah Morgensen  skribis:

> The remaining packages have a total of 19 dependents, 7 of which belong
> to ocl-icd@2.2.12.  As soon as ocl-icd's website is back online, updating
> it to 2.2.13 should fix the build.

I just saw that on the master branch ocl-icd has been deprecated and
replaced by opencl-icd-loader. However I've not tried merging master
into core-updates-frozen to see if it the build works.


signature.asc
Description: PGP signature

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Guillaume Le Vaillant]

Sarah Morgensen  skribis:

> opencpn@5.0.0

Hi,
I fixed opencpn in 79edda38742b37603ccd48dd8660ff7fcfca293e.


signature.asc
Description: PGP signature

bug#50014: [core-updates] QtWebKit build failures

[Guillaume Le Vaillant]

Hi Leo,

I found the cause of the "error adding symbols: Malformed archive".
It happens because the maximum number of open file descriptors is too
low. I pushed a fix (f3152cf3021892ba7e2f3d837207eb1ee64bfdb6) raising
the limit from 1024 to 4096 in the build phase on top of your 4 patches,
and the build succeeds.


signature.asc
Description: PGP signature

bug#49611: Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`

[Guillaume Le Vaillant]

Katherine Cox-Buday  skribis:

> Thank you both! I was not aware that this belonged in the firmware
> field and not the packages field. This has solved the error message
> during boot. Further, adding the kernel argument successfully sets my
> region as US on boot.
>
> tags 49611 notabug
> close 49611
>
> This is not part of the bug per-say, but a question around this space:
> despite all of this, I still cannot broadcast on US approved channels.
> I think this is because the EEPROM on the card is set as global. What
> am I missing? Do you know how Linux intend for people to notify the
> stack that this is an OK thing to do? I know projects like OpenWRT
> carry patches to the driver, but I keep thinking surely this is not
> the only way.

Some WiFi devices can have extra EEPROM-based restrictions if they don't
implement some features.
I have a WiFi card that I can't use as access point on the 5 GHz band
because it doesn't implement radar detection, which is apparently
mandatory on this band to avoid causing interference.
Luckily I have another device based on a different chipset where it just
works.


signature.asc
Description: PGP signature

bug#49611: Despite wireless-regdb being installed in my operating-system, dmesg indicates it can't find `regulatory.db`

[Guillaume Le Vaillant]

Brice Waegeneire  skribis:

> Hello Katherine,
>
> TL;DR: “iw reg set US” correctly set the regulatory region from userland
> but Guix can't set it just from the kernel.
>
> Katherine Cox-Buday  writes:
>
>> #+BEGIN_EXAMPLE
>> [8.280462] cfg80211: Loading compiled-in X.509 certificates for
>> regulatory database
>> [8.282686] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
>> [8.284394] platform regulatory.0: Direct firmware load for
>> regulatory.db failed with error -2
>> [8.284415] cfg80211: failed to load regulatory.db
>> #+END_EXAMPLE
>
> There is three way to make the module cfg80211 load a regulatory
> database:
> 1. Baking the DB into the kernel at build time by replacing the kernel's
>   limited DB with the one from 'wireless-regdb' via the option
>   CONFIG_CFG80211_INTERNAL_REGDB¹.
> 2. Loading the DB at boot time as a signed firmware file
>   (lib/firmware/regulatory.db from 'wirerless-regdb') via the module
>   'cfg80211'.
> 3. Doing it in userland with the helper 'crda' trough the utility
>   'iwd' or its predecesor 'wpa_supplicant'.²
>
> From what I understand and what I tested, only the third method works in
> Guix System ATM.  It could be usefull to also support the first or
> second method to not depend on the userland setting the wireless
> regulatory settings.

Hi,

You could also try adding "cfg80211.ieee80211_regdom=US" to the
'kernel-arguments' field of your 'operating-system' definition.


signature.asc
Description: PGP signature

bug#49307: clisp: build failure: failing tests

[Guillaume Le Vaillant]

Christopher Howard  skribis:

> Attempting to build clisp from source results in these test failures:
> ```(echo *.erg | grep '*' >/dev/null) || (echo "Test failed:" ; ls -l
> *erg; echo "To see which tests failed, type" ; echo "cat
> "`pwd`"/*.erg" ; exit 1)Test failed:-rw-r--r-- 1 nixbld nixbld 188 Jun
> 30 21:15 path.erg-rw-r--r-- 1 nixbld nixbld 658 Jun 30 21:15
> streams.erg-rw-r--r-- 1 nixbld nixbld 500 Jun 30 21:15
> streamslong.ergTo see which tests failed, typecat /tmp/guix-build-
> clisp-2.49-92.drv-0/source/src/tests/*.ergmake[2]: *** [Makefile:34:
> compare] Error 1make[2]: Leaving directory '/tmp/guix-build-clisp-2.49-
> 92.drv-0/source/src/tests'make[1]: *** [Makefile:2216: check-tests]
> Error 2make[1]: Leaving directory '/tmp/guix-build-clisp-2.49-92.drv-
> 0/source/src'make: *** [Makefile:28: check] Error 2
> Test suite failed, dumping logs.command "make" "check" "-j" "1" failed
> with status 2
> ```
> I did a pull about one or two hours ago.
> ```christopher@theoden ~/Repos/guix$ neofetch --stdoutchristopher@theoden 
> --- OS: Guix System 364db4fdf664d7987693a6935b76f34258041865 
> x86_64 Host: OptiPlex 9020 00 Kernel: 5.12.8-gnu Uptime: 6 days, 2 hours, 44 
> mins Packages: 93 (guix-system), 111 (guix-user) Shell: bash 5.0.16 
> Resolution: 1920x1080 DE: GNOME Theme: Adwaita [GTK2/3] Icons: Adwaita 
> [GTK2/3] Terminal: kitty CPU: Intel i5-4570 (4) @ 3.600GHz GPU: Intel HD 
> Graphics GPU: AMD ATI Radeon HD 8490 / R5 235X OEM Memory: 4062MiB / 
> 7869MiB```

It builds successfully on my machine (with Guix
at 460392d1f0d0ef5484df8834452cf94f211bf346).
Do you get this test failure every time?


signature.asc
Description: PGP signature

bug#49161: kicad-5.1.6 fails to build

[Guillaume Le Vaillant]

Patches pushed as e22a711c97e0501b398467733164da4ee140036e and
following.
Thanks.


signature.asc
Description: PGP signature

bug#49161: kicad-5.1.6 fails to build

[Guillaume Le Vaillant]

Vinicius Monego  skribis:

>> In particular the /gnu/store/...-libngspice-34/include/config.h
>> seems suspicious.
>
> Good catch. Indeed, that file should be removed.
>
> Kicad takes a long time to build on my machine. I am attaching a diff
> that removes config.h and should fix the compilation if anyone can
> confirm.

I tried applying your diff and with it kicad compiles fine and works.
Could you send a formatted patch?


signature.asc
Description: PGP signature

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

[Guillaume Le Vaillant]

Sharlatan Hellseher  skribis:

> I played with cl-jupyter:install but it heavily depends on Quicklisp
> but what basically does - generates simple JSON with CL implementation
> https://github.com/yitzchak/common-lisp-jupyter/issues/78
>
> First I tried to do the same during build phase by evaluationg
> arbitrary Lisp but could not manged it to work.
> Then after checking the kernel.json I just simply formated it with
> right %lispt-type path and copied with the same evaluation as R
> Jupyter package, but I've got some error during coping into Jupyter
> directory:
>
> --8<---cut here---start->8---
> phase `generate-kernelspec' succeeded after 0.0 seconds
> starting phase `install-kernelspec'
> command "jupyter" "kernelspec" "install" "--name" "cl-jupyter"
> "--prefix" 
> "/gnu/store/xjqxskiqjlzirlg478gnlp7x6w2jcz63-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7"
> "/gnu/store/xjqxskiqjlzirlg478gnlp7x6w2jcz63-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7/share/cl-jupyter/kernelspec"
> failed with status 127
> builder for 
> `/gnu/store/azl65q1bl2pv920fmgw6d8k0brsx6hdg-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7.drv'
> failed with exit code 1
> build of 
> /gnu/store/azl65q1bl2pv920fmgw6d8k0brsx6hdg-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7.drv
> failed
> [...]
> --8<---cut here---end--->8---

I think this error comes from the fact that the jupyter package is
missing as native input, therefore the 'jupyter ...' command can't work.

It lools like the 'install-kernelspec' phase just copies the kernel you
generated in "share/cl-jupyter/kernelspec/" to
"share/jupyter/kernels/cl-jupyter/". Wouldn't it be easier to generate
the kernel in the final directory directly? Then the
'install-kernelspec' phase would not be necessary.


signature.asc
Description: PGP signature

bug#48336: kicad cannot see libngspice

[Guillaume Le Vaillant]

Christopher Howard  skribis:

> In Kicad Eeschema, if I try to use the Tools >> Simulator menu entry, I
> get an error in a pop-up window that libngspice cannot be found, and
> then the whole Kicad application closes. I see that libngspice is a
> dependency of kicad so I'm not quite sure what is wrong.
>
> I asked at #kicad at they said that Kicad does not have any gui-
> adjustable path settings for ngspice or libngspice, so I don't think I
> have the application configured wrong.

Fix pushed as f7d2ae57543ae6afe14434877d7480b15dcbb5b7.
I checked that the libngspice library is detected and that the
simulation window opens correctly, but I have not tried making
simulations of electronic circuits.
Please open another bug if you find a problem.


signature.asc
Description: PGP signature

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

[Guillaume Le Vaillant]

Hi Jack,

I guess it will be easier to just add a phase writing the "kernel.json"
file in the right place. In this build phase, to know if the package is
being built for SBCL or ECL, the '(%lisp-type)' function that will
return "sbcl" or "ecl" can be used. There's an example in the
sbcl-trivial-backtrace package.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

Leo Famulari  skribis:

> On Sat, May 08, 2021 at 07:34:26AM +0000, Guillaume Le Vaillant wrote:
>> 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.
>
> Are you using Intel or AMD?
>
> I ask because of this upstream bug report about ArUco not working on AMD
> processors:
>
> https://github.com/opencv/opencv_contrib/issues/2736
>
> The build farm is AMD.

The machine I used to build opencv (successfully) also has an AMD
processor (AMD Ryzen 9 5950X).


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 when
> issuing ~guix build -L. sbcl-1am~:
>
> #+BEGIN_EXAMPLE
> Backtrace:
>1 (primitive-load "/home/katco/.config/guix/current/bin/g…")
> In guix/ui.scm:
>   1936:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:1936:12: In procedure run-guix-command:
> Value out of range 0 to 4: 5
> #+END_EXAMPLE

Fixed in 2fa8fd4af59af0de392352915fa50fc21a4cf98a.
Closing.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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: asdf: Work around package-name->name+version
>>  bug.
>>
>> This patch modifies how the name of the main Common Lisp system is extracted
>> from the full Guix package name to work around bug#48225 concerning the
>> 'package-name->name+version' function.
>>
>> Fixes <https://issues.guix.gnu.org/41437>.
>>
>> * guix/build-system/asdf.scm (asdf-build): Fix 'systems' function.
>> * guix/build/asdf-build-system.scm (main-system-name): Fix it.
>
> If it works for you, sounds good to me.  Please do rebuild as many CL
> packages, with different CL implementations, to make sure we do not
> overlook any corner case.
>
>> +  (let* ((lisp-prefix (string-append lisp-type "-"))
>> + (package-name (hyphen-separated-name->name+version
>> +(if (string-prefix? lisp-prefix name)
>> +(string-drop name
>> + (string-length 
>> lisp-prefix))
>> +name
>> +`(quote ,(list package-name)))
>
> I’d like to see a FIXME in there: this is all guesswork and we should
> eventually replace guesses with known-good info.
>
> What would it take to pass the right package name and implementation
> name upfront from the package?
>
> Thanks,
> Ludo’.

I tried rebuilding all the sbcl-*, cl-* and ecl-* packages, as well as
stumpwm, uglify-js and nyxt, and I didn't see new failures.
I pushed the patch as 2fa8fd4af59af0de392352915fa50fc21a4cf98a.

When 'package-name->name+version' returns a bad result leading to an
incorrect default Lisp system name being computed, it can be overridden
using the '#:asd-systems' parameter of 'asdf-build-system', which should
work around the problem in almost all cases.

However I suppose other build systems could have issues if they make use
of 'package-name->name+version' on a package with a name like
"abc-123-def-1.2.3" (depending how they use the result).


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 working in
asdf-build-system after all. I guess it's the default behaviour of
'load-asd'.

However I don't know why this 'clear-system' call messes up the ASDF
configuration in asdf-build-system, but it doesn't seem to cause
problems in Quicklisp...


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 succeeds and this
'opencv_test_aruco' test takes less than 1 second.

Does someone see the test phase getting stuck when building opencv
locally?


[1] https://ci.guix.gnu.org/build/323874/log/raw
[2] https://ci.guix.gnu.org/build/323859/log/raw


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> [...]
> A better fix would be to not guess and instead pass #:name and #:version
> to all the build phases, with the value taken from the  object.
> (That’s a world-rebuild fix though.)
>
> WDYT?
>
>> This is related to issue #48208, and also probably to issue #41437.
>
> Perhaps we can find a workaround for these?

Sharlatan Hellseher  skribis:

> If chaining  `package-name->name+version` function  may affect a large
> layer of infrastructure here is could a quick adhoc workaround:
>
> sbcl-3d-vectors -> sbcl-cl3d-vectors
> sbcl-3d-vectors -> sbcl-three-d-vectors
> sbcl-3d-vectors -> sbcl-iiid-vectors
>
> Or use any predictable common prefix which could be use and replaced
> after the function is reviewed.

I agree that having '#:name' and '#:version' available in the build
phases would be ideal.
Meanwhile I found a workaround for the asdf-build-system that fixes
bug#41437 and allows building the 'sbcl-3d-vectors' and
'sbcl-3d-matrices' packages of bug#48208 without having to mangle the
package names. It rebuilds all the Common Lisp packages, but that
doesn't take too much time.
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 extracted
from the full Guix package name to work around bug#48225 concerning the
'package-name->name+version' function.

Fixes <https://issues.guix.gnu.org/41437>.

* guix/build-system/asdf.scm (asdf-build): Fix 'systems' function.
* guix/build/asdf-build-system.scm (main-system-name): Fix it.
---
 guix/build-system/asdf.scm   | 15 +++
 guix/build/asdf-build-system.scm | 12 ++--
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/guix/build-system/asdf.scm b/guix/build-system/asdf.scm
index 28403a1960..8f9d63337f 100644
--- a/guix/build-system/asdf.scm
+++ b/guix/build-system/asdf.scm
@@ -291,16 +291,15 @@ set up using CL source package conventions."
   (imported-modules %asdf-build-system-modules)
   (modules %asdf-build-modules))
 
-;; FIXME: The definition of 'systems' is pretty hacky.
-;; Is there a more elegant way to do it?
 (define systems
   (if (null? (cadr asd-systems))
-  `(quote
-,(list
-  (string-drop
-   ;; NAME is the value returned from `package-full-name'.
-   (hyphen-separated-name->name+version name)
-   (1+ (string-length lisp-type) ; drop the "-" prefix.
+  (let* ((lisp-prefix (string-append lisp-type "-"))
+ (package-name (hyphen-separated-name->name+version
+(if (string-prefix? lisp-prefix name)
+(string-drop name
+ (string-length lisp-prefix))
+name
+`(quote ,(list package-name)))
   asd-systems))
 
 (define builder
diff --git a/guix/build/asdf-build-system.scm b/guix/build/asdf-build-system.scm
index 6ad855cab2..5a4fc44aef 100644
--- a/guix/build/asdf-build-system.scm
+++ b/guix/build/asdf-build-system.scm
@@ -52,12 +52,12 @@
   (string-append %source-install-prefix "/systems"))
 
 (define (main-system-name output)
-  (let ((package-name (package-name->name+version
-   (strip-store-file-name output)))
-(lisp-prefix (string-append (%lisp-type) "-")))
-(if (string-prefix? lisp-prefix package-name)
-(string-drop package-name (string-length lisp-prefix))
-package-name)))
+  (let* ((full-name (strip-store-file-name output))
+ (lisp-prefix (string-append (%lisp-type) "-"))
+ (package-name (if (string-prefix? lisp-prefix full-name)
+   (string-drop full-name (string-length lisp-prefix))
+   full-name)))
+(package-name->name+version package-name)))
 
 (define (lisp-source-directory output name)
   (string-append output (%lisp-source-install-prefix) "/" name))
-- 
2.31.1



signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 "sbcl-3d-vectors-3.1.0-1.29bb968")

$1 = "sbcl"
$2 = "3d-vectors-3.1.0-1.29bb968"
--8<---cut here---end--->8---

It should be:

--8<---cut here---start->8---
$1 = "sbcl-3d-vectors"
$2 = "3.1.0-1.29bb968"
--8<---cut here---end--->8---

Can someone think of an elegant modification for
'package-name->name+version' so that it finds where the version is
even if there are several hyphens before of after it (as in
"sbcl-3d-vectors-3.1.0-1.29bb968" or "nyxt-2-pre-release-6")?

This is related to issue #48208, and also probably to issue #41437.

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

[Guillaume Le Vaillant]

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

[Guillaume Le Vaillant]

Fixed in commit 041d62f7cc244d7f6c0bd6d60cdf08e72d400313.


signature.asc
Description: PGP signature

bug#47654: electron-cash fails to start

[Guillaume Le Vaillant]

Fixed in c901ec27d7e437c200f04263c1cdccdcd864956c.


signature.asc
Description: PGP signature

bug#47654: electron-cash fails to start

[Guillaume Le Vaillant]

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 electroncash import bitcoin, util
  File 
"/gnu/store/34h2k23x2yzm8gycbxkjmq7aqnlzmi7x-electron-cash-4.2.4/lib/python3.8/site-packages/electroncash/__init__.py",
 line 5, in 
from .network import Network, pick_random_server
  File 
"/gnu/store/34h2k23x2yzm8gycbxkjmq7aqnlzmi7x-electron-cash-4.2.4/lib/python3.8/site-packages/electroncash/network.py",
 line 45, in 
from .interface import Connection, Interface
  File 
"/gnu/store/34h2k23x2yzm8gycbxkjmq7aqnlzmi7x-electron-cash-4.2.4/lib/python3.8/site-packages/electroncash/interface.py",
 line 38, in 
from pathvalidate import sanitize_filename
ModuleNotFoundError: No module named 'pathvalidate'
--8<---cut here---end--->8---

This is with Guix at commit 14392c77896561c5846c0f3a0588720792d61e95.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 empty outline in overview
>> mode, as if there's a window but it has never been painted.
>>
>> When running 'epiphany' from the command line, I see the followin
>> warning from 'bwrap', which indicates that it's looking in /usr/bin:
>
> I see exactly the same behavior with 'eolie': the window never appears,
> (except for an outline in GNOME Shell's overview mode), and I see the
> same warning:
>
>   "bwrap: Can't find source path /usr/bin: No such file or directory"
>
> In both cases, if I try to close the phantom window from overview mode,
> it informs me that the application is not responding, and I have to
> force quit to make the phantom window go away.
>
>Mark

On my Guix system, epiphany with webkitgtk-2.32.0 seems to work fine
(with Guix at commit 14392c77896561c5846c0f3a0588720792d61e95).
The window appears and I can browse websites, and it doesn't print any
error about 'bwrap'.
I'm using StumpWM and not Gnome Shell; I don't know if it has an impact
on epiphany's behavior.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 to get the full list of
>> store refrences.
>
> I don't think there is need to scan recursively: if package A depends on
> B which depends on C, then A can lists the dependency on B in a file,
> and B can do the same for C.  This way the relationship between A and C
> is properly stored.
>
> Am I missing something?

Oh, you say this file would be created for every Lisp package. I thought
it would only be for the standalone binary case, because the "regular"
asdf-build-system/sbcl used for Lisp libraries ships the sources and its
make-asdf-configuration phase creates links to the required Lisp
dependencies in '/gnu/store/...', so there should not be missing
references.


>> And as Mark wrote below, with the current grafting code, this list of
>> store references will not solve grafting for paths that are in UTF-32 or
>> both in ASCII and UTF-32 in the binary file.
>
> Indeed, and that's the core of the issue here I believe, since grafting
> is what breaks Nyxt in practice.
>
> Cheers!

I just wondered: does the grafting code take '.fasl' files into
consideration?
If yes, I guess a Lisp library could also end up in a strange
half-grafted state if the grafting code modifies ASCII references and
not UTF-32 ones...


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 encoding might
> be enough.  But of course this is less general and more brittle.

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 to get the full list of
store refrences.
And as Mark wrote below, with the current grafting code, this list of
store references will not solve grafting for paths that are in UTF-32 or
both in ASCII and UTF-32 in the binary file.


Ludovic Courtès  skribis:

> Mark H Weaver  skribis:
>
>> Pierre Neidhardt  writes:
>>> - The main recommendation for an easy fix without updating the scanner
>>>   is that we tweaked our build system to dump the store reference to a
>>>   separate ASCII file.
>>
>> Sounds good.  I made a similar proposal in Dec 2018, earlier in this
>> thread .  I wrote:
>>
>>   If you don't want to change the daemon, it could be worked around in our
>>   build-side code as follows: we could add a new phase to certain build
>>   systems (or possibly gnu-build-system) that scans each output for
>>   UTF-16/32 encoded store references that are never referenced in UTF-8.
>>   If such references exist, a file with an unobtrusive name would be added
>>   to that output containing those references encoded in UTF-8.  This would
>>   enable our daemon's existing reference scanner to find all of the
>>   references.
>>
>>   Our grafting code would then need to be extended to recognize and
>>   transform store references encoded in UTF-16/32 as well as UTF-8.
>
> Oh thanks for the reminder.
>
> The separate ASCII file doesn’t solve it all because, as you write, we’d
> need to change the grafting code as well.
>
> Then it might be simpler to use a “byte vector” data type for those
> strings.  We’ll have to wait for Pierre’s patches to get a better idea.
> :-)

I'm not sure what you mean with the "byte vector" data type here. Could
you explain what you're thinking about with a few more details?


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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.
>> 
>> sbcl-cl-webkit won't be deleted by `guix gc`, however webkitgtk will
>> be, so it seems it's not protected from garbage collection by
>> sbcl-cl-webkit. Am I wrong in this?
>
> You can check on this with the `guix gc` tool.
>
> Specifically, like this:
>
> $ guix gc --references $(guix build sbcl-cl-webkit)
>
> That will show you the "store references" of the built sbcl-cl-webkit
> package. These store references are strings that refer to files in
> /gnu/store, found by scanning the result of building sbcl-cl-webkit. 
>
> These references are recorded in the Guix database at
> '/var/guix/db/db.sqlite'.
>
> The built package must keep references to its runtime dependencies, or
> they will be subject to garbage collection, and that would represent a
> bug in the package definition.
>
> Does that make sense?

I think this issue is identical to what has been reported a few years
ago in bug#33848 (https://issues.guix.gnu.org/33848) which is still
open.
The binaries created by SBCL store some pathnames as UTF-32 strings, and
the reference scanner of Guix doesn't support that, so it misses some
references.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 file /home/hellseher/code/guix/gnu/packages/lisp-xyz.scm
> ;;;   newer than compiled 
> /home/hellseher/code/guix/gnu/packages/lisp-xyz.go
> ;;; note: source file /home/hellseher/code/guix/gnu/packages/emacs-xyz.scm
> ;;;   newer than compiled
> /home/hellseher/code/guix/gnu/packages/emacs-xyz.go
> ;;; note: source file /home/hellseher/code/guix/gnu/packages/games.scm
> ;;;   newer than compiled /home/hellseher/code/guix/gnu/packages/games.go
> ;;; note: source file /home/hellseher/code/guix/gnu/packages/telegram.scm
> ;;;   newer than compiled 
> /home/hellseher/code/guix/gnu/packages/telegram.go
> /gnu/store/x9ainb8phlprackcdwl1a8w0xh1bh18g-sbcl-cffi-0.23.0

Ok, closing.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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

With Guix at 5fccdbc079402eee345684bcbd1b1d0306cab1e8 I don't reproduce
this issue.
From the warning and error messages you get, it looks like you changed
something in 'lisp-xyz.scm' and Guix fails to compile it.
Is it the case? If yes, there is probably a bug in the changes you made.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 "http://www.w1hkj.com/files/fldigi/fldigi-4.1.17.tar.gz"; 404 
> "Not Found"
>
> [...]
>
> I've checked upstream, http://www.w1hkj.com/files/fldigi/ , they have only a 
> fldigi 4.1.18 tarball.
>
> The git repository I could find, https://github.com/w1hkj/fldigi , has only 
> tags
> up to 4.1.14.
>
> So if we used git (and thus swh) instead, we could only carry version 4.1.14.
> As it is now, upstream removing tarballs from their website will randomly 
> break
> the build of the guix derivation--as it did here.

The git repository on Sourceforge has all the tags. I pushed a fix as
65e9f13116edc58836cdbd1da60bfb81a3d58c82 to use it instead of the
tarballs.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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, otherwise tests fail with:
>;; Component QURI-ASD::QURI-TEST not found, required by #;; "quri">.
>'(#:asd-systems '("quri-test" "quri")))
> --8<---cut here---end--->8---
>
> Our build system should be able to do better, we should not even have to
> specify the asd-systems here.  After all, ASDF is smart enough.
>
> Note that:
>
> - If we don't specify the systems, the tests are still run and
>   succeed(!), it's only the phase that fails with the aforementioned
>   error.
>
> - If we specify the systems in the reverse order, it still fails!
>
> We've got this issue for many SBCL packages.
>
> Any clue?  Guillaume?

Currently we are using the 'asdf:load-asd' function to load system
definitions (see the 'build' function in
'guix/build/asdf-build-system.scm' and the 'compile-systems' function in
'guix/build/lisp-utils.scm').

This function can only load one '.asd' file at a time, which is the
cause of the issue. If we find how ASDF does the "lazy-load" of all the
'.asd' files in a directory tree, and if we use that instead of
'load-asd', I think it would solve the issue and we could get rid of the
'asd-files' parameter in Guix package definitions.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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

[Guillaume Le Vaillant]

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:

--8<---cut here---start->8---
_ TestDateTimeParserParse.test_parse_tz_name_zzz[America/Nuuk] _

self = 
full_tz_name = 'America/Nuuk'

@pytest.mark.parametrize("full_tz_name", make_full_tz_list())
def test_parse_tz_name_zzz(self, full_tz_name):

self.expected = datetime(2013, 1, 1, tzinfo=tz.gettz(full_tz_name))
>   assert (
self.parser.parse("2013-01-01 {}".format(full_tz_name), "-MM-DD 
ZZZ")
== self.expected
)

tests/test_parser.py:347: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
arrow/parser.py:244: in parse
self._parse_token(token, value, parts)
arrow/parser.py:397: in _parse_token
parts["tzinfo"] = TzinfoParser.parse(value)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

cls = , tzinfo_string = 'America/Nuuk'

@classmethod
def parse(cls, tzinfo_string):

tzinfo = None

if tzinfo_string == "local":
tzinfo = tz.tzlocal()

elif tzinfo_string in ["utc", "UTC", "Z"]:
tzinfo = tz.tzutc()

else:

iso_match = cls._TZINFO_RE.match(tzinfo_string)

if iso_match:
sign, hours, minutes = iso_match.groups()
if minutes is None:
minutes = 0
seconds = int(hours) * 3600 + int(minutes) * 60

if sign == "-":
seconds *= -1

tzinfo = tz.tzoffset(None, seconds)

else:
tzinfo = tz.gettz(tzinfo_string)

if tzinfo is None:
>   raise ParserError(
'Could not parse timezone expression "{}"'.format(tzinfo_string)
)
E   arrow.parser.ParserError: Could not parse timezone expression 
"America/Nuuk"

arrow/parser.py:592: ParserError
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#44112: SBCL is not reproducible

[Guillaume Le Vaillant]

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 would simplify
>> things. Maybe nothing really depends on it and it would be possible...
>
> Any news from upstream?  Still unreproducible for me.
>
>
> All the best,
> simon

So far Slime still uses the function getting the source file timestamp,
so these timestamps can't be removed from SBCL.
A patch for Slime would be accepted (see [2]), but as far as I know
nobody has worked on it yet.

[2] https://github.com/slime/slime/issues/583


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 it failed with the same memory fault.
>
> Thanks! On #guix, Efraim reported that the builds were succeeding on his
> aarch64 hardware. So, I'm not sure what's going on :/

When taking a look at the logs of failing builds of sbcl-* packages on
aarch64-linux (for example at [1] for master or at [2] for staging),
I saw that the build jobs try to build sbcl (which is currently failing)
for every package.

I would have expected the builds for sbcl-* packages to be marked as
"failed because missing dependency" given that the main dependency of
the asdf-build-system/sbcl failed to build. Instead the build farm is
trying to rebuild sbcl over and over, which wastes quite some time and
resources.

It looks like the dependencies of the build system are not considered as
dependencies for the packages that use this build system.
Am I missing something?

[1] https://ci.guix.gnu.org/eval/31355?status=failed
[2] https://ci.guix.gnu.org/eval/20644?status=failed


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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
> //doing warm init - compilation phase
> This is SBCL 2.1.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at .
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> Initial page table:
> Gen  Boxed   CodeRaw  LgBox LgCode  LgRaw  Pin   Alloc Waste  
>   Trig  WP GCs Mem-age
>  6 397250  0  0  0  0042335440 66352 
> 200 647   0  0.
>Total bytes allocated=  42335440
>Dynamic-space-size bytes =3221225472
> COLD-INIT... (Length(TLFs)= 9736)
> Disassembler: 72 printers, 0 prefilters, 4 labelers
> CORRUPTION WARNING in SBCL pid 1774 tid 1774:
> Memory fault at 0xfffa (pc=0x1002199f70)
> The integrity of this image is possibly compromised.
> Exiting.
> Error opening /dev/tty: No such device or address
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> 
> real  0m6.120s
> user  0m5.958s
> sys   0m0.137s
> command "sh" "make.sh" "clisp" 
> "--prefix=/gnu/store/j1ciw4dc8iskd5fdcw0s1ba08kkg7vx6-sbcl-2.1.0" 
> "--dynamic-space-size=3072" "--with-sb-core-compression" 
> "--with-sb-xref-for-internals" failed with status 1
> --
>
> It appears that SBCL can support this platform. However, until we make
> it work, I plan to remove aarch64 from the "supported-systems" of sbcl,
> to avoid attempting these builds.

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 it failed with the same memory fault.


signature.asc
Description: PGP signature

bug#45236: Xboard doesn't work.

[Guillaume Le Vaillant]

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 -- xboard
>>
>> and it spawns what looks like a “working” XBoard to me (that’s with
>> commit 3d85c3ec652feb22824f355538b51e6955ded361 as reported by ‘guix
>> describe’).
>
> Even if the Data Service says that no substitute are available:
>
> 
>
> all these commits f4450e8c 27866b7c af1225a3 b5ed51bd 48cccf06 8ab70bae
> 9bc516ba 35c43fcd c81457a5 aebba13c 747953c4 e7ce4ef9 4730878b 6d15516d
> 0ed75a5f 33b59c1a build, i.e., all the xboard 4.9.1 are buildable.
>
> However, then trying I get:
>
> --8<---cut here---start->8---
> xboard: Erreur lors de l'écriture dans le programme d'échecs Premier: Relais 
> brisé (pipe)
> --8<---cut here---end--->8---
>
> and a crash.  I do not know if it comes from an user config of xboard (I
> never use it) or a Guix config of the package or something broken
> upstream.
>
> Pablo, could you precise what you mean by “not working for so long”?
> And what do you mean by “wait until update”?  What “update” means here?
>
>
> All the best,
> simon

On my system, starting XBoard with the "xboard" command and trying to
use the gnuchess engine fails with a "broken pipe" error. According to
the engine menu in XBoard, it uses the "-fcp gnuchess" to set gnuchess
as the engine.

What is strange is that if I start XBoard directly with "xboard -fcp gnuchess",
everything works fine.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 introduced with the build system overhaul.
>
> Thoughts?

Thanks for the review. Pushed as
031fbebafef81244a72e584a46b3fcc219256fcb and following.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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.

* gnu/packages/patches/cl-asdf-config-directories.patch: New file.
* gnu/local.mk (dist_PATCH_DATA): Add it.
* gnu/packages/lisp.scm (cl-asdf)[native-inputs]: Add it.
  [arguments]: Apply the new patch.

Co-authored-by: Pierre Neidhardt 
---
 gnu/local.mk  |  1 +
 gnu/packages/lisp.scm | 28 
 .../patches/cl-asdf-config-directories.patch  | 44 +++
 3 files changed, 53 insertions(+), 20 deletions(-)
 create mode 100644 gnu/packages/patches/cl-asdf-config-directories.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 28ad119846..f838ebe1fa 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -868,6 +868,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/cdrtools-3.01-mkisofs-isoinfo.patch 	\
   %D%/packages/patches/ceph-disable-cpu-optimizations.patch	\
   %D%/packages/patches/chmlib-inttypes.patch			\
+  %D%/packages/patches/cl-asdf-config-directories.patch		\
   %D%/packages/patches/clamav-config-llvm-libs.patch		\
   %D%/packages/patches/clamav-system-tomsfastmath.patch		\
   %D%/packages/patches/clang-3.5-libc-search-path.patch		\
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index e4c963070e..0038cb0dca 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -90,6 +90,9 @@
(sha256
 (base32 "1hpx30f6yrak15nw992k7x3pn75ahvjs04n4f134k68mhgs62km2"
 (build-system trivial-build-system)
+(native-inputs
+ `(("config-patch" ,@(search-patches "cl-asdf-config-directories.patch"))
+   ("patch" ,patch)))
 (arguments
  `(#:modules ((guix build utils)
   (guix build lisp-utils))
@@ -101,28 +104,13 @@
 (asdf-install (string-append out %source-install-prefix
  "/source/asdf/"))
 (src-asdf (string-append (assoc-ref %build-inputs "source")))
-(dst-asdf (string-append asdf-install "asdf.lisp")))
+(dst-asdf (string-append asdf-install "asdf.lisp"))
+(patch (string-append (assoc-ref %build-inputs "patch")
+  "/bin/patch"))
+(config-patch (assoc-ref %build-inputs "config-patch")))
(mkdir-p asdf-install)
(copy-file src-asdf dst-asdf)
-   ;; Patch ASDF to make it read the configuration files in all
-   ;; the direcories listed in '$XDG_CONFIG_DIRS' instead of just
-   ;; the first.
-   (substitute* dst-asdf
- (("\\(xdg-config-pathname \\*source-registry-directory\\* direction\\)")
-  "`(:source-registry
- ,@(loop
-  for dir in (xdg-config-dirs
-  \"common-lisp/source-registry.conf.d/\")
-  collect `(:include ,dir))
- :inherit-configuration)")
- (("\\(xdg-config-pathname \\*output-translations-directory\\* direction\\)")
-  "`(:output-translations
- ,@(loop
-  for dir in (xdg-config-dirs
-  \"common-lisp/asdf-output-translations.conf.d/\")
-  collect `(:include ,dir))
- :inherit-configuration)")))
- #t)))
+   (invoke patch "-p1" "-i" config-patch dst-asdf)
 (home-page "https://common-lisp.net/project/asdf/";)
 (synopsis "Another System Definition Facility")
 (description
diff --git a/gnu/packages/patches/cl-asdf-config-directories.patch b/gnu/packages/patches/cl-asdf-config-directories.patch
new file mode 100644
index 00..2b1b51932c
--- /dev/null
+++ b/gnu/packages/patches/cl-asdf-config-directories.patch
@@ -0,0 +1,44 @@
+Search for ASDF configuration files first in user directories, and then in
+Guix profiles.
+
+diff -ru a/asdf-3.3.4.lisp b/asdf-3.3.4.lisp
+--- a/asdf-3.3.4.lisp	2020-02-14 20:16:22.0 +0100
 b/asdf-3.3.4.lisp	2020-12-05 11:09:56.066229482 +0100
+@@ -12535,10 +12535,15 @@
+ (find-preferred-file (system-config-pathnames *output-translations-file*)
+  :direction direction))
+   (defun user-output-translations-directory-pathname (&key (direction :input))
+-(xdg-config-pathname *output-translations-directory* direction))
+-  (defun system-output-translations-directory-pathname (&key (direction :input))
+-(find-preferred-file (system-config-pathnames *output-tran

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

[Guillaume Le Vaillant]

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
> #P"/gnu/store/5gj1inwiqpn2fm9w384zd0grpyadx96m-sbcl-quri-0.1.0-2.b53231c/share/common-lisp/sbcl/quri/quri.asd"
> NIL
> NIL
> NIL
>
> ;; Indeed:
> * (asdf:user-source-registry-directory)
> #P"/gnu/store/75qppl3a062b138fkrn324qq8f912zqh-profile/etc/common-lisp/source-registry.conf.d/"
> --8<---cut here---end--->8---
>
> It does not work because the sbcl package definition sets the
> XDG_CONFIG_DIRS native search path which is picked by
> user-source-registry-directory, which has higher priority than
> default-user-source-registry.
>
> I think the flaw is ASDF's this time:
>
> --8<---cut here---start->8---
>   (defun user-source-registry-directory (&key (direction :input))
> (xdg-config-pathname *source-registry-directory* direction))
>
> ;...
>
>   (defun xdg-config-pathnames (&rest more)
> "Return a list of pathnames for application configuration.
> MORE may contain specifications for a subpath relative to these directories: a
> subpathname specification and keyword arguments as per RESOLVE-LOCATION \(see
> also \"Configuration DSL\"\) in the ASDF manual."
> (filter-pathname-set
>  `(,(xdg-config-home more)
>,@(xdg-config-dirs more
> --8<---cut here---end--->8---
>
> So the user registry looks into XDG_CONFIG_DIRS, while really it should
> just look at XDG_CONFIG_HOME.
>

The same test works for me. I think it's because I have
a ".config/common-lisp/source-registry.conf.d" directory (even if it's
empty), and '(user-source-registry-directory)' returns it instead of the
first directory in XDG_CONFIG_DIRS.

> So this patch should do (untested):
>
> --8<---cut here---start->8---
> - (defun user-source-registry-directory (&key (direction :input))
> -   (xdg-config-pathname *source-registry-directory* direction))
> + (defun user-source-registry-directory (&key (direction :input))
> +   (find-preferred-file (list (xdg-config-home *source-registry-directory*)) 
> :direction direction))
> --8<---cut here---end--->8---
>
> If you confirm, then we should also report upstream I think.
>
> Cheers!

I don't know if the fact that ASDF can give priority to XDG_CONFIG_DIRS
over "~/common-lisp" is a feature or a bug, so you could ask upstream.
Anyway in our case, your patch makes sense since we always want to give
priority to "~/common-lisp" and other usual user directories. I'll add
it to our patch for cl-asdf.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> A few comments:
>
>> @@ -603,7 +603,8 @@ statistical profiler, a code coverage tool, and many 
>> other extensions.")
>>  "0x4bjx6cxsjvxyagijhlvmc7jkyxifdvz5q5zvz37028va65243c")
>> (_ 
>> "15l7cfa4a7jkfwdzsfm4q3n22jnb57imxahpql3h77xin57v1gbz"
>>  (native-inputs
>> - `(("m4" ,m4)))
>> + `(("cl-asdf" ,cl-asdf)
>> +   ("m4" ,m4)))
>>  (arguments
>>   `(#:tests? #f  ;no 'check' target
>> #:modules ((ice-9 match)
>> @@ -615,6 +616,17 @@ statistical profiler, a code coverage tool, and many 
>> other extensions.")
>>   (add-after 'unpack 'unpack-image
>> (lambda* (#:key inputs #:allow-other-keys)
>>   (invoke "tar" "xzvf" (assoc-ref inputs "ccl-bootstrap"
>> + (add-after 'unpack 'replace-asdf
>> +   ;; Use system ASDF instead of bundled one.
>> +   (lambda* (#:key inputs outputs #:allow-other-keys)
>> + (let* ((cl-asdf (assoc-ref inputs "cl-asdf"))
>> +(guix-asdf (string-append
>> +cl-asdf
>> +"/share/common-lisp/source/asdf/asdf.lisp"))
>> +(out (string-append (assoc-ref outputs "out")))
>
> "out" is unused.  By the way, the same "out" is unused in SBCL.
>

Indeed, I'll fix that.

>> +(contrib-asdf "tools/asdf.lisp"))
>> +   (delete-file contrib-asdf)
>
> I think you don't need to delete the file, copy-file should overwrite.
> That's what SBCL does.
>
> Same with CLISP.

Actually, for CCL and Clisp, I get a "In procedure copy-file: Permission
denied" error if I don't delete the current file before copying the new
one.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 translations for these systems.
> When doing development, it might be more convenient to just use the
> sources or source packages of every system that has to be recompiled.

I think entering the following expressions just after starting SBCL will
allow development mixing libraries from user directories and from Guix
profiles:

--8<---cut here---start->8---
(require :asdf)
(asdf:clear-output-translations)
(asdf:initialize-output-translations
 '(:output-translations
   :enable-user-cache
   :ignore-inherited-configuration))
--8<---cut here---end--->8---

However with this configuration, the pre-compiled files in
"/gnu/store/..." will not be used at all; everything will be compiled
again if necessary and put in the user cache in ".cache/common-lisp/...".


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 use the same
>> version of ASDF, and hopefully behave in the same way when looking for
>> configuration files.
>
> Yup, that'd be neat :)

Patches for CCL and Clisp attached. ABCL fails to build with ASDF 3.3.4
and I have not seen an obvious error message in the logs, so this one
will need more investigation...


> Related to this, I've noticed another issue with SBCL packages: when an
> SBCL package has a dependency that's updated in ~/common-lisp,
> (asdf:load-system ...) tries to recompile it in its folder, which fails
> since /gnu/store is read-only.
>
> Example:
>
> - Apply the above patch or edit
>   ~/.config/common-lisp/source-registry.conf
>   to make sure ~/common-lisp is loaded before system packages.
>
> - Install sbcl-cl-cookie.
>
> - Check out https://github.com/fukamachi/quri:
>   git clone https://github.com/fukamachi/quri ~/common-lisp/quri
>
> - Now run
>
> --8<---cut here---start->8---
> $ sbcl
> * (asdf:load-system :cl-cookie)
> WARNING: System definition file 
> #P"/gnu/store/81cwmspx3366vdjs6v20rnd8a0xyr6in-sbcl-cl-fad-0.7.6/share/common-lisp/sbcl/cl-fad/cl-fad.asd"
>  contains definition for system "cl-fad-test". Please only define "cl-fad" 
> and secondary systems with a name starting with "cl-fad/" (e.g. 
> "cl-fad/test") in that file.
>
> debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread
> #:
>   Error opening 
> #P"/gnu/store/22q4ydm0pagi4irz0clssgkhkyh115j8-sbcl-cl-cookie-0.9.10-1.cea55ae/lib/common-lisp/sbcl/cl-cookie/src/cl-cookie-tmpGHU3ALSV.fasl":
>
> Read-only file system
> --8<---cut here---end--->8---
>
> Not sure what to do about this.
>
> I'm guessing that Common Lisp development is not practical with Guix'
> SBCL packages and I should just stick to the CL packages.
>
> Thoughts?

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 translations for these systems.
When doing development, it might be more convenient to just use the
sources or source packages of every system that has to be recompiled.
From 5ce14232fafef61fdd5f9412c50dbfbb90f0d03e Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant 
Date: Fri, 4 Dec 2020 10:29:34 +0100
Subject: [PATCH 2/4] gnu: ccl: Use system ASDF instead of bundled one.

* gnu/packages/lisp.scm (ccl)[native-inputs]: Add cl-asdf.
  [arguments]: Add 'replace-asdf' phase.
  [native-search-paths]: Add XDG_CONFIG_DIRS and XDG_DATA_DIRS.
---
 gnu/packages/lisp.scm | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 0038cb0dca..2a8c59546e 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -603,7 +603,8 @@ statistical profiler, a code coverage tool, and many other extensions.")
 "0x4bjx6cxsjvxyagijhlvmc7jkyxifdvz5q5zvz37028va65243c")
(_ "15l7cfa4a7jkfwdzsfm4q3n22jnb57imxahpql3h77xin57v1gbz"
 (native-inputs
- `(("m4" ,m4)))
+ `(("cl-asdf" ,cl-asdf)
+   ("m4" ,m4)))
 (arguments
  `(#:tests? #f  ;no 'check' target
#:modules ((ice-9 match)
@@ -615,6 +616,17 @@ statistical profiler, a code coverage tool, and many other extensions.")
  (add-after 'unpack 'unpack-image
(lambda* (#:key inputs #:allow-other-keys)
  (invoke "tar" "xzvf" (assoc-ref inputs "ccl-bootstrap"
+ (add-after 'unpack 'replace-asdf
+   ;; Use system ASDF instead of bundled one.
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let* ((cl-asdf (assoc-ref inputs "cl-asdf"))
+(guix-asdf (string-append
+cl-asdf
+"/share/common-lisp/source/asdf/asdf.lisp"))
+(out (string-append (assoc-ref outputs "out")))
+(contrib-asdf "tools/asdf.lisp"))
+   (delete-file contrib-asdf)
+   (copy-file guix-asdf contrib-asdf
  (delete 'configure)
  (add-before 'build 'pre-build
;;

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

[Guillaume Le Vaillant]

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 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 use the same
version of ASDF, and hopefully behave in the same way when looking for
configuration files.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> Alternately, we could simply move the patch from
> user-source-registry-directory to system-source-registry-directory; same
> for the output translation.

What do you think of the attached patch? Does it work for you?
From cb8d52ec606bb8984622f6b117346b4772bf0d16 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/packages/lisp.scm (cl-asdf)[native-inputs]: Add it.
  [arguments]: Apply the new patch.
---
 gnu/local.mk  |  1 +
 gnu/packages/lisp.scm | 28 +--
 .../patches/cl-asdf-config-directories.patch  | 36 +++
 3 files changed, 45 insertions(+), 20 deletions(-)
 create mode 100644 gnu/packages/patches/cl-asdf-config-directories.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 28ad119846..f838ebe1fa 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -868,6 +868,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/cdrtools-3.01-mkisofs-isoinfo.patch 	\
   %D%/packages/patches/ceph-disable-cpu-optimizations.patch	\
   %D%/packages/patches/chmlib-inttypes.patch			\
+  %D%/packages/patches/cl-asdf-config-directories.patch		\
   %D%/packages/patches/clamav-config-llvm-libs.patch		\
   %D%/packages/patches/clamav-system-tomsfastmath.patch		\
   %D%/packages/patches/clang-3.5-libc-search-path.patch		\
diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index e4c963070e..0038cb0dca 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -90,6 +90,9 @@
(sha256
 (base32 "1hpx30f6yrak15nw992k7x3pn75ahvjs04n4f134k68mhgs62km2"
 (build-system trivial-build-system)
+(native-inputs
+ `(("config-patch" ,@(search-patches "cl-asdf-config-directories.patch"))
+   ("patch" ,patch)))
 (arguments
  `(#:modules ((guix build utils)
   (guix build lisp-utils))
@@ -101,28 +104,13 @@
 (asdf-install (string-append out %source-install-prefix
  "/source/asdf/"))
 (src-asdf (string-append (assoc-ref %build-inputs "source")))
-(dst-asdf (string-append asdf-install "asdf.lisp")))
+(dst-asdf (string-append asdf-install "asdf.lisp"))
+(patch (string-append (assoc-ref %build-inputs "patch")
+  "/bin/patch"))
+(config-patch (assoc-ref %build-inputs "config-patch")))
(mkdir-p asdf-install)
(copy-file src-asdf dst-asdf)
-   ;; Patch ASDF to make it read the configuration files in all
-   ;; the direcories listed in '$XDG_CONFIG_DIRS' instead of just
-   ;; the first.
-   (substitute* dst-asdf
- (("\\(xdg-config-pathname \\*source-registry-directory\\* direction\\)")
-  "`(:source-registry
- ,@(loop
-  for dir in (xdg-config-dirs
-  \"common-lisp/source-registry.conf.d/\")
-  collect `(:include ,dir))
- :inherit-configuration)")
- (("\\(xdg-config-pathname \\*output-translations-directory\\* direction\\)")
-  "`(:output-translations
- ,@(loop
-  for dir in (xdg-config-dirs
-  \"common-lisp/asdf-output-translations.conf.d/\")
-  collect `(:include ,dir))
- :inherit-configuration)")))
- #t)))
+   (invoke patch "-p1" "-i" config-patch dst-asdf)
 (home-page "https://common-lisp.net/project/asdf/";)
 (synopsis "Another System Definition Facility")
 (description
diff --git a/gnu/packages/patches/cl-asdf-config-directories.patch b/gnu/packages/patches/cl-asdf-config-directories.patch
new file mode 100644
index 00..04ec67c9a0
--- /dev/null
+++ b/gnu/packages/patches/cl-asdf-config-directories.patch
@@ -0,0 +1,36 @@
+Search for ASDF configuration files first in user directories, and then in
+Guix profiles.
+
+diff -ru a/asdf-3.3.4.lisp b/asdf-3.3.4.lisp
+--- a/asdf-3.3.4.lisp	2020-02-14 20:16:22.0 +0100
 b/asdf-3.3.4.lisp	2020-12-03 13:57:54.843428936 +0100
+@@ -12537,8 +12537,12 @@
+   (defun user-output-translations-directory-pathname (&key (direction :input))
+ (xdg-config-pathname *output-translations-directory* direction))
+   (defun system-output-translations-directory-pathname (&key (direction :input))
+-(find-preferred-f

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

[Guillaume Le Vaillant]

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 here---start->8---
> (defparameter* *default-source-registries*
> '(environment-source-registry
>   user-source-registry
>   user-source-registry-directory
>   default-user-source-registry
>   system-source-registry
>   system-source-registry-directory
>   default-system-source-registry)
> "List of default source registries" "3.1.0.102")
> --8<---cut here---end--->8---
>
> `user-source-registry' points to what is read in
> ~/.config/common-lisp/source-registry.conf(.d/)?, so nothing by default.
>
> user-source-registry-directory reads what's in XDG_CONFIG_DIRS, and it
> finds the Guix packages there.
>
> The default-user-source-registry expands to
>
> --8<---cut here---start->8---
> (:SOURCE-REGISTRY (:TREE (:HOME "common-lisp/"))
> (:DIRECTORY (:HOME ".sbcl/systems/"))
> (:DIRECTORY
>  #P"/home/ambrevar/.local/share/common-lisp/systems/")
> (:TREE #P"/home/ambrevar/.local/share/common-lisp/source/")
> :INHERIT-CONFIGURATION)
> --8<---cut here---end--->8---
>
> which is where I would drop my user-local packages.
>
> Finally, default-system-source-registry reads what's in XDG_DATA_DIRS,
> and it finds the packages there again, but it does not read the
> Guix-generated conf which collects the dependencies of each package.
>
>
>
> I believe the issue is that `user-source-registry-directory' should read
> from XDG_CONFIG_HOME, and not XDG_CONFIG_DIRS (which would make it
> redundant with `user-source-registry').  This would make it an upstream
> issue, but I wanted to double-check I properly understood the problem
> with the Guix community first.
>
> Guillaume, thoughts on this?

Our cl-asdf package definition has little patches for
'user-source-registry-directory' and
'user-output-translations-directory-pathname' to make ASDF read
configuration files in all the directories listed in 'XDG_CONFIG_DIRS'
(IIRC regular ASDF was only reading from the first valid one in
'XDG_CONFIG_HOME' or 'XDG_CONFIG_DIRS'):

--8<---cut here---start->8---
(substitute* dst-asdf
  (("\\(xdg-config-pathname \\*source-registry-directory\\* direction\\)")
   "`(:source-registry
  ,@(loop
   for dir in (xdg-config-dirs
   \"common-lisp/source-registry.conf.d/\")
   collect `(:include ,dir))
  :inherit-configuration)")
  (("\\(xdg-config-pathname \\*output-translations-directory\\* direction\\)")
   "`(:output-translations
  ,@(loop
   for dir in (xdg-config-dirs
   \"common-lisp/asdf-output-translations.conf.d/\")
   collect `(:include ,dir))
  :inherit-configuration)")))
--8<---cut here---end--->8---

I guess 'XDG_CONFIG_HOME' is missing here and we could add it in the
list before the 'XDG_CONFIG_DIRS' directories. Something like:

--8<---cut here---start->8---
(substitute* dst-asdf
  (("\\(xdg-config-pathname \\*source-registry-directory\\* direction\\)")
   "`(:source-registry
  (:include (xdg-config-home \"common-lisp/source-registry.conf.d/\"))
  ,@(loop
   for dir in (xdg-config-dirs
   \"common-lisp/source-registry.conf.d/\")
   collect `(:include ,dir))
  :inherit-configuration)")
  (("\\(xdg-config-pathname \\*output-translations-directory\\* direction\\)")
   "`(:output-translations
  (:include (xdg-config-home 
\"common-lisp/asdf-output-translations.conf.d/\"))
  ,@(loop
   for dir in (xdg-config-dirs
   \"common-lisp/asdf-output-translations.conf.d/\")
   collect `(:include ,dir))
  :inherit-configuration)")))
--8<---cut here---end--->8---

Or maybe we could make a better patch not changing
'user-source-registry-directory', but adding a new
'guix-source-registry' between 'default-user-source-registry' and
'system-source-registry' in the list of registries (and likewise for
output-translations).
I think this way the systems in '$HOME/.config/...', '$HOME/.local/...'
or '$HOME/common-lisp/...' will have priority on the ones in Guix
profiles.

What do you think?


signature.asc
Description: PGP signature

bug#44925: gdm boot up failure

[Guillaume Le Vaillant]

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 next reboot, gdm didn't work anymore. I rebooted and launched the
previous system generation, but gdm still didn't work, which is strange.

After some investigation, I found that gdm was failing because the
kernel driver for the GPU was not loaded (the 'nouveau' driver in my
case). I tried to load it by hand with
'insmod /run/booted-system/kernel/lib/modules/5.9.11/.../nouveau.ko.gz',
and it failed with the error 'unknown symbol in module'.

I'm not sure what was going on here... The only way I got everything to
work again is by reconfiguring the system to compile and use the 5.9.12
kernel.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 `patch-usr-bin-file'
> phase `patch-usr-bin-file' succeeded after 0.0 seconds
> starting phase `patch-source-shebangs'
> patch-shebang: ./autogen.sh: changing `/bin/sh' to
> `/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh'
> phase `patch-source-shebangs' succeeded after 0.0 seconds
> starting phase `patch-generated-file-shebangs'
> phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
> starting phase `install'
> Backtrace:
>8 (primitive-load "/gnu/store/3yrl560yxms43sqvyhv0g5xy4ki…")
> In ice-9/eval.scm:
>191:35  7 (_ #f)
> In guix/build/gnu-build-system.scm:
> 838:2  6 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> In ice-9/boot-9.scm:
>   1736:10  5 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
>857:16  4 (every1 # …)
> In guix/build/gnu-build-system.scm:
>847:30  3 (_ _)
> In guix/build/asdf-build-system.scm:
>128:24  2 (install #:inputs _ #:outputs _)
> In unknown file:
>1 (string-take "stumpwm" #f)
> In ice-9/boot-9.scm:
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Wrong type (expecting exact integer): #f
>
> The problem seems to be caused by this commit
> https://git.savannah.gnu.org/cgit/guix.git/commit/guix/build/asdf-build-system.scm?id=c3f1f09586967c3fefbb280014a4d46b57786696
>  "
> build: asdf-build-system: Use SBCL source in CL packages.
> "
>
>
> More specifically the way the parent-source is computed does not seem
> handle packages that lack hyphen character in the name of their
> parent.
> + (define parent-source
> + (and parent
> + (string-append parent "/share/common-lisp/"
> + (string-take parent-name
> + (string-index parent-name #\-))
> + "-source")))
>
> My guix describe is:
> Generation 10May 31 2020 18:04:46(current)
>   my-personal-packages 451bc28
> repository URL: https://github.com/geostarling/guix-packages.git
> branch: master
> commit: 451bc28676242ff3ada89eae73b3a914836205e6
>   guix bf6438f
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: bf6438f46583003cfd851c9f8ff4104aa3107c4d
>
>
> Thank you for advice,
>
> Jiri

This seems to be fixed on the master branch since commit
4dadb4977908028bb0651d43ed4813cc988db92d.
Closing.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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]

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/gst-plugins-bad/-/issues/1463
>>   aarch64: 
>> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1464
>>
>> (I believe the i686 issue affects armhf too)
>>
>> This issue is currently holding up merging of 'staging' because
>> gst-plugins-bad is a dependency of 'cheese', which is a dependency of
>> 'gnome'.
>>
>> To move on with the merge, I wonder whether to:
>>
>> 1. Disable the affected tests, as upstream does not seem terribly
>>concerned.
>> 2. Drop 'cheese' from 'gnome'.
>>
>> I'm leaning towards 2, as the AArch64 failure looks kind of serious.
>> Unfortunately 'cheese' does seem to require gst-plugins-bad.
>>
>> Thoughts?
>
> Hi,
>
> I tested a few programs on 'staging' on x86-64 and I got some GStreamer
> related issues. However I don't know if there is a link with the failing
> tests on other architectures.
>
> I wasn't able to play anything with the 'gst-play-1.0' program. It
> always errors out with the message:
> "Failed to create 'playbin' element. Check your GStreamer installation."
>
> The 'clementine' program crashes because of a segmentation fault inside
> a GStreamer function when trying to play a music file.
>
> [...]
>
> Can someone reproduce these issues?

Hi,

After trying to find where the problem could come from, GStreamer
started working fine again, but I'm not sure why. I suspect there was
some bad local state in my user environment that I reset while hacking
around, or something like that...

Anyway, concerning 'cheese', I think not installing it by default with
Gnome would not be a problem. It's not an essential core component of
Gnome and users who want it will still be able to install it trivially.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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: 
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1464
>
> (I believe the i686 issue affects armhf too)
>
> This issue is currently holding up merging of 'staging' because
> gst-plugins-bad is a dependency of 'cheese', which is a dependency of
> 'gnome'.
>
> To move on with the merge, I wonder whether to:
>
> 1. Disable the affected tests, as upstream does not seem terribly
>concerned.
> 2. Drop 'cheese' from 'gnome'.
>
> I'm leaning towards 2, as the AArch64 failure looks kind of serious.
> Unfortunately 'cheese' does seem to require gst-plugins-bad.
>
> Thoughts?

Hi,

I tested a few programs on 'staging' on x86-64 and I got some GStreamer
related issues. However I don't know if there is a link with the failing
tests on other architectures.

I wasn't able to play anything with the 'gst-play-1.0' program. It
always errors out with the message:
"Failed to create 'playbin' element. Check your GStreamer installation."

The 'clementine' program crashes because of a segmentation fault inside
a GStreamer function when trying to play a music file.

--8<---cut here---start->8---
Thread 1 ".clementine-rea" received signal SIGSEGV, Segmentation fault.
0x0092aafe in CheckedGConnect(void*, char const*, void (*)(), void*, 
int) ()
(gdb) backtrace
#0  0x0092aafe in CheckedGConnect(void*, char const*, void (*)(), 
void*, int) ()
#1  0x006c73e5 in GstEnginePipeline::ReplaceDecodeBin(QUrl const&) ()
#2  0x006cb7ac in GstEnginePipeline::InitFromUrl(QUrl const&, long 
long) ()
#3  0x006c1fde in GstEngine::CreatePipeline(QUrl const&, long long) ()
#4  0x006c26d8 in GstEngine::Load(QUrl const&, 
QFlags, bool, unsigned long long, long long) ()
#5  0x006bbb08 in Engine::Base::Play(QUrl const&, 
QFlags, bool, unsigned long long, long long) ()
#6  0x0066f318 in Player::PlayAt(int, QFlags, 
bool) ()
#7  0x007ff958 in MainWindow::PlaylistDoubleClick(QModelIndex const&) ()
#8  0x008eb62a in MainWindow::qt_static_metacall(QObject*, 
QMetaObject::Call, int, void**) ()
#9  0x7742ce73 in void doActivate(QObject*, int, void**) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Core.so.5
#10 0x7615fdd5 in QAbstractItemView::doubleClicked(QModelIndex const&) 
() from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#11 0x761ce3c8 in QTreeView::mouseDoubleClickEvent(QMouseEvent*) () 
from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#12 0x75f60d69 in QWidget::event(QEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#13 0x760032de in QFrame::event(QEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#14 0x7616b18c in QAbstractItemView::viewportEvent(QEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#15 0x761cfe1c in QTreeView::viewportEvent(QEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#16 0x773f3e1d in 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () 
from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Core.so.5
#17 0x75f21bd2 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#18 0x75f293f7 in QApplication::notify(QObject*, QEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#19 0x773f4088 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Core.so.5
#20 0x75f27e9c in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool, bool) ()
   from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#21 0x75f7a1c6 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#22 0x75f7cd2e in QWidgetWindow::event(QEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#23 0x75f21bfc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#24 0x75f2892f in QApplication::notify(QObject*, QEvent*) () from 
/gnu/store/p6gcdpw824izd2x7aq55w4167j9bymjs-qtbase-5.14.2/lib/libQt5Widgets.so.5
#25 0x773f4088 in Q

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

[Guillaume Le Vaillant]

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'

[Guillaume Le Vaillant]

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, it's also works in Common Lisp:
>>(uiop:run-program '("guix" "repl") :input s :output
>> t:error-output nil))
>
> Well, I stranded trying to import (or whatever the CL term is) UIOP itself, 
> but
> my Common Lisp-fu is hella weak.
>
>> However this brings me to another issue: the program output is prefixed
>> with the REPL welcome message which is printed to stdout.
>>
>> So ideally when we read from standard input we should not include the
>> welcome message.
>
> That's a question for Guile channels, but I totally agree.  It's annoying and
> nowhere near ‘an interactive mode’ as suggested by the GPL3.
>
> This is sensible:
>
>  $ echo echo Hi. | bash
>  Hi.
>  $ 
> This is not:
>
>  $ echo '(display "Hi.\n")' | guile
>  GNU Guile 3.0.2
>  Copyright (C) 1995-2020 Free Software Foundation, Inc.
>
>  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show   w'.
>  This program is free software, and you are welcome to   redistribute it
>  under certain conditions; type `,show c' for details.
>
>  Enter `,help' for help.
>  Hi.
>  scheme@(guile-user)>   $
>
>> Any clue how to do that?
>
> The following line in my ~/.guile does just that:
>
>  (set! repl-welcome (const #t))
>
> ...unfortunately, it doesn't work late:
>
>  $ echo '(use-modules ((system repl common))) \
>(set! repl-welcome (const #t))' | guix repl
>  [shouty noises]
>  $
>
> It does not appear documented if and how you'd make Guile load a different
> (Nyxt-specific) init file name.
>
> This reminds me: do you want Nyxt to call ‘guix repl -q’ to skip loading
> ~/.guile to make your UI more predictable & debuggable? Or keep it as an 
> escape
> hatch for cool hacks?
>
> Kind regards,
>
> T G-R

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.


signature.asc
Description: PGP signature

bug#44558: Mesa isn't update to date

[Guillaume Le Vaillant]

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 know.  An otherwise working package not being at 
>>> the
>>> latest upstream version isn't a bug.
>>>
>>> romulasry via Bug reports for GNU Guix 写道：
>>>> Mesa 20.2.2 is released
>>>
>>> The core-updates branch updates Mesa to 20.1.9.  Would you like to submit
>>> a (tested) core-updates patch updating it to 20.2.2?
>>
>> Hi,
>>
>> Mesa 20.2 brings direct OpenGL rendering support for Nvidia RTX 20xx
>> graphic cards with the nouveau driver, whereas with our current version
>> these cards have to use LLVMpipe.
>> I tested the update quickly on my local staging branch using glxgears
>> and vlc, and it worked fine. When reading a video the CPU usage dropped
>> from 30% to 2%, which is nice.
>
> That is great news.
>
> The current 'staging' branch is just about ready for merge[*], so a Mesa
> update will have to wait until the next round.
>
> However, I think libGL is fairly ABI-stable, so you may be able to
> "graft" this version in the mean time, like in commit
> fdd883509301845ddb4dc90e70e58b469afb5441.
>
> [*] gst-plugins-good fails on armhf and i686, not sure what to do about
> it yet: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/803

I'll try this grafting trick, thanks for the pointer.

I saw that issue 803 of gst-plugin-good has been closed with patch
2ce5909f; are there other things blocking the merge of the 'staging'
branch into 'master'?


signature.asc
Description: PGP signature

bug#44558: Mesa isn't update to date

[Guillaume Le Vaillant]

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 Guix 写道：
>> Mesa 20.2.2 is released
>
> The core-updates branch updates Mesa to 20.1.9.  Would you like to submit
> a (tested) core-updates patch updating it to 20.2.2?

Hi,

Mesa 20.2 brings direct OpenGL rendering support for Nvidia RTX 20xx
graphic cards with the nouveau driver, whereas with our current version
these cards have to use LLVMpipe.
I tested the update quickly on my local staging branch using glxgears
and vlc, and it worked fine. When reading a video the CPU usage dropped
from 30% to 2%, which is nice.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 necessary pass on all the Guix build servers.
>
> I'm leaning towards disabling the tests for generic-cl.  What do you think?

If the tests don't run reliably, disabling them sounds like a good idea.
IIRC the tests of sbcl-numcl are disabled because of a similar problem.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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-space-size" option
>> at runtime.
>
> Fine with me, let's do it now on staging then?

Yes, go ahead.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 "--dynamic-space-size=5000" just for generic-cl.
>
> Thoughts?  Guillaume?

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-space-size" option
at runtime.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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
compiling "src/common/macro-util.lisp".
I'm not sure why it fails with asdf-build-system/sbcl but it succeeds
with Quicklisp though; different versions of ASDF maybe, or slightly
different initialization of ASDF...

By adding the missing ":serial t" I was able to build sbcl-cl-environments:

--8<---cut here---start->8---
(define-public sbcl-cl-environments
  ;; TODO: asdf-build-system/sbcl fails here, why?  See if it works with the
  ;; build system revamp once staging is merged after 2020-11-09.
  (let ((commit "bbcd958a9ff23ce3e6ea5f8ee2edad9634819a3a")) ; No version in 2 
years.
(package
  (name "sbcl-cl-environments")
  (version (git-version "0.2.3" "1" commit))
  (source
   (origin
 (method git-fetch)
 (uri (git-reference
   (url "https://github.com/alex-gutev/cl-environments";)
   (commit commit)))
 (file-name (git-file-name name version))
 (sha256
  (base32
   "1pfxl3vcdrb4mjy4q4c3c7q95kzv6rfjif3hzd5q91i9z621d64r"
  (build-system asdf-build-system/sbcl)
  (propagated-inputs
   `(("alexandria" ,sbcl-alexandria)
 ("anaphora" ,sbcl-anaphora)
 ("collectors" ,sbcl-collectors)
 ("optima" ,sbcl-optima)))
  (native-inputs
   `(("prove" ,sbcl-prove)))
  (arguments
   `(#:phases
 (modify-phases %standard-phases
   (add-after 'unpack 'fix-build
 (lambda _
   (substitute* "cl-environments.asd"
 ((":module \"common\"" all)
  (string-append all " :serial t")))
   #t)
  (home-page "https://github.com/alex-gutev/cl-environments";)
  (synopsis "Implements the Common Lisp standard environment access API")
  (description "This library provides a uniform API, as specified in Common
Lisp the Language 2, for accessing information about variable and function
bindings from implementation-defined lexical environment objects.  All major
Common Lisp implementations are supported, even those which don't support the
CLTL2 environment access API.")
  (license license:expat
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#44112: SBCL is not reproducible

[Guillaume Le Vaillant]

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 function depending on it. I asked if this could
be fixed [2]. We'll see...

[1] https://sourceforge.net/p/sbcl/mailman/message/37133640/
[2] https://github.com/slime/slime/issues/583


signature.asc
Description: PGP signature

bug#44112: SBCL is not reproducible

[Guillaume Le Vaillant]

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
> issues cuts any Diverse Double Compiling attempt.

IIRC, when compiling, SBCL puts the timestamp of the source file in the
compiled file. It's not a problem when just doing basic compilation
because the source files' timestamps have been set to "1970-01-01".

However, some packages generate some source files at build time, usually
containing things like data type sizes fetched from system header in
order to use C libraries with FFI. The timestamp of a generated file
is the current time, therefore the build is not reproducible.

IIRC, SBCL itself is built in 2 stages. First its core is compiled
using another Common Lisp implementation (currently clisp in Guix), then
the complete SBCL is compiled using the core compiled in stage 1. There
is probably also an embedded timestamp issue here (coming for clisp,
from SBCL, or both) causing the reproducibility issue.

The patches currently in the staging branch don't have any effect on
the generation of source files or on the format of the compiled files,
so they will not help with this issue.

Removing this source file timestamp from compiled files would simplify
things. Maybe nothing really depends on it and it would be possible...


signature.asc
Description: PGP signature

bug#42667: opencv fails to build

[Guillaume Le Vaillant]

This was fixed by 8bf704262d672ae0735f0685bfd1c9ddcb1d8484, closing.


signature.asc
Description: PGP signature

bug#42667: opencv fails to build

[Guillaume Le Vaillant]

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 && 
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++  -DCVAPI_EXPORTS 
-DHAVE_IMGCODEC_HDR -DHAVE_IMGCODEC_PXM -DHAVE_IMGCODEC_SUNRASTER -DHAVE_WEBP 
-D_USE_MATH_DEFINES -D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/imgcodecs/include
 -I/tmp/guix-build-opencv-3.4.3.drv-0/build/modules/imgcodecs 
-I/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/core/include 
-I/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/imgproc/include
 -isystem /tmp/guix-build-opencv-3.4.3.drv-0/build -isystem 
/gnu/store/7xqvr2nr5g1cw9kwc0rdlhg92zg5zi44-openexr-2.5.2/include/OpenEXR  
-fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor 
-Werror=address -Werror=sequence-point -Wformat -Werror=format-security 
-Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow 
-Wsign-promo -Wuninitialized -Winit-self -Wsuggest-override -Wno-narrowing 
-Wno-delete-non-virtual-dtor -Wno-comment -Wimplicit-fallthrough=3 
-fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer 
-ffunction-sections -fdata-sections  -msse -msse2 -fvisibility=hidden 
-fvisibility-inlines-hidden -Wno-deprecated-declarations -O2 -g -DNDEBUG -fPIC  
 -o CMakeFiles/opencv_imgcodecs.dir/src/grfmt_pxm.cpp.o -c 
/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/imgcodecs/src/grfmt_pxm.cpp
/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/imgcodecs/src/grfmt_jpeg2000.cpp:
 In member function ‘bool cv::Jpeg2KDecoder::readComponent8u(uchar*, void*, 
int, int, int, int, int)’:
/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/imgcodecs/src/grfmt_jpeg2000.cpp:340:71:
 error: lvalue required as unary ‘&’ operand
 jas_seqent_t* pix_row = &jas_matrix_get( buffer, y / ystep, 0 );
   ^
/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/imgcodecs/src/grfmt_jpeg2000.cpp:
 In member function ‘bool cv::Jpeg2KDecoder::readComponent16u(short unsigned 
int*, void*, int, int, int, int, int)’:
/tmp/guix-build-opencv-3.4.3.drv-0/opencv-3.4.3-checkout/modules/imgcodecs/src/grfmt_jpeg2000.cpp:404:71:
 error: lvalue required as unary ‘&’ operand
 jas_seqent_t* pix_row = &jas_matrix_get( buffer, y / ystep, 0 );
   ^
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#42321: qgis PyQgsExpressionBuilderWidget test fails

[Guillaume Le Vaillant]

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 the result is usable.

Hi, I just built QGIS on my machine and everything worked fine. Do you
get this test failure every time, or does it fail randomly?


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 path.
>
> <<< Welcome to GNU Radio Companion 3.8.0.0 >>>
>
> Block paths:
>   /home/christopher/.guix-profile/share/gnuradio/grc/blocks
>   /gnu/store/h2igg2gcbx6ds8wbvlkqz0dkplvwjxbd-gnuradio-
> 3.8.0.0/share/gnuradio/grc/blocks
>
> Generating: '/home/christopher/Scratch/test.py'
>
> Executing: /gnu/store/c0ysvb6s92kwwnmkgdhnspllxvd3f231-python-
> 3.7.4/bin/python3 -u /home/christopher/Scratch/test.py
>
> Warning: failed to XInitThreads()
> Traceback (most recent call last):
>   File "/home/christopher/Scratch/test.py", line 33, in 
> import osmosdr
> ModuleNotFoundError: No module named 'osmosdr'
>
 Done (return code 1)

I pushed a patch to set PYTHONPATH in the profile when gnuradio is
intalled (commit f03e5ca59f2f099693def2c8e6ff409e5b4ed40a). I guess
I had another installed package that had set it, because I didn't get
this error.
Could you try if it works for you?


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 believe the problem
> is that the osmosdr blocks are not in the directory where gnuradio-
> companion is looking for blocks.
>
> When starting up gnuradio-companion, stdout indicates grc is looking for 
> blocks here:
>
> /gnu/store/h2igg2gcbx6ds8wbvlkqz0dkplvwjxbd-gnuradio-3.8.0.0/share/gnuradio/grc/blocks
>
> But osmosdr blocks are in 
>
> /gnu/store/ppb504vizb32f4w2s5f0yd6i4xpy41nz-gnuradio-osmosdr-0.2.0/share/gnuradio/grc/blocks/
>
> Evidentally gnuradio package needs to be enhanced to create a per-
> profile merged directory from all gnuradio- block packages that are
> installed. Unless there is some way to extend the gnuradio search path
> through environment variables.

Hi Christopher,

I pushed a fix (commit cf480830e22e7725b8607b5b895e49f74d4e1525) that
should put the paths to installed third-party blocks in GRC_BLOCKS_PATH,
and allow gnuradio-companion to see them. Could you check if it works
for you?


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 again?

I tried again and I wasn't able to reproduce the problem.
Maybe I did something weird with my config last time, but I can't
remember what it could have been...

> Now, I think we should generalize this chown thing and apply it to all
> the user accounts.  ‘user-homes’ would chown recursively if needed or
> use the newfangled shiftfs, like systemd-homed does¹.
>
> Thoughts?
> Ludo’.
>
> ¹ https://systemd.io/HOME_DIRECTORY/

A recursive chown for system accounts (with their home directory
somewhere in '/var') sounds like a good idea.

For user accounts (in '/home'), I guess it could be slightly annoying if
a user wants to set a specific group id to some of their files and if it
gets set back to the 'users' group at each system reconfiguration.
However it's probably not a very common use case, and if we only change
the files' uid, they could end up with an invalid gid anyway.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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-type (generation n) to
>>> make it use slim-service-type instead (generation n+1), and then
>>> reconfiguring to gdm-service-type again (generation n+2).
>>>
>>> The problem was that the 'gdm' user id number (or group id number) was
>>> not the same in generations n and n+2, which prevented GDM from
>>> accessing the '/var/lib/gdm' directory.
>>
>> When did that happen?
>>
>> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
>> ensures that /var/lib/gdm has proper ownership.
>>
>> Thanks,
>> Ludo’.
>
> I think it was around 2 weeks ago.

Concerning the service extensions of gdm-service-type, is it guaranteed
that %gdm-activation will be run after %gdm-accounts and not before?
If it's not the case it could explain the problem...


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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-service-type instead (generation n+1), and then
>> reconfiguring to gdm-service-type again (generation n+2).
>>
>> The problem was that the 'gdm' user id number (or group id number) was
>> not the same in generations n and n+2, which prevented GDM from
>> accessing the '/var/lib/gdm' directory.
>
> When did that happen?
>
> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
> ensures that /var/lib/gdm has proper ownership.
>
> Thanks,
> Ludo’.

I think it was around 2 weeks ago.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 gdm-service-type (generation n) to
make it use slim-service-type instead (generation n+1), and then
reconfiguring to gdm-service-type again (generation n+2).

The problem was that the 'gdm' user id number (or group id number) was
not the same in generations n and n+2, which prevented GDM from
accessing the '/var/lib/gdm' directory.

Changing the permissions with "chown -R gdm.gdm /var/lib/gdm" or
deleting '/var/lib/gdm' to force the creation of a new one with correct
permissions allowed GDM to work correctly again.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 "fare-quasiquote-extras" not found, required by
> #.
>
> debugger invoked on a ASDF/FIND-COMPONENT:MISSING-DEPENDENCY in thread
> #:
>   Component "fare-quasiquote-extras" not found, required by
>   #
> ...
>
> The same command works with other substantial packages if you replace (both
> mentions of) serapeum with dramka or cl-async for example. Maybe there is a
> dependency issue with either serapeum or the fare utils? How might this be
> fixed?
>
> guix --version
>
> guix (GNU Guix) 9d0dfd9a9a7c43363a4e140c20d49f119fe6f2e3
>
> Thanks!

Hi,

There was indeed an issue with the fare-quasiquote-extras input of the
serapeum package. I pushed a fix as
8137983adfe3c3f61e583aae140a62046e859435.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 example the 'monero-gui'
>> package builds fine but it fails to run:
>>
>> --8<---cut here---start->8---
>> 2019-12-31 12:50:42.076  W app startd (log: 
>> /home/guillaume/.bitmonero/monero-wallet-gui.log)
>> 2019-12-31 12:50:42.077  W Qt:5.12.6 GUI:- | screen: 1920x1080 - dpi: 
>> 96.1263 - ratio:0.997092
>> 2019-12-31 12:50:42.179  W QQmlApplicationEngine failed to load component
>> 2019-12-31 12:50:42.179  W qrc:/main.qml:1693 Type WizardLang unavailable
>> 2019-12-31 12:50:42.179  W qrc:/wizard/WizardLang.qml:32 module 
>> "QtQuick.XmlListModel" is not installed
>> 2019-12-31 12:50:42.179  E Error: no root objects
>> --8<---cut here---end--->8---
>
> I was able to build the QML for 'XmlListModel' by making 'qtdeclarative'
> a dependency of 'qtxmlpatterns' instead of the opposite (and the QML is in
> the 'qtxmlpatterns' package).
>
> Rebuilding the required Qt packages and 'monero-gui' and running it
> worked fine. However I'm not too familiar with the Qt packages, so does
> someone think this approach could cause problems in some of them?
>
>
> Here's the patch I used:
>
> --8<---cut here---start->8---
> From 2f0befe2e183d65a731e616b7b55808d27d8af8e Mon Sep 17 00:00:00 2001
> From: Guillaume Le Vaillant 
> Date: Sun, 5 Jan 2020 19:27:17 +0100
> Subject: [PATCH] gnu: qtxmlpatterns: Build QML plugin for XmlListModel.
>
> * gnu/packages/qt.scm (qtdeclarative)[native-inputs]: Remove qtxmlpatterns.
>   (qtxmlpatterns)[native-inputs]: Add qtdeclarative.
> ---
>  gnu/packages/qt.scm | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
> index 795b5e9d2b..daa35c77cb 100644
> --- a/gnu/packages/qt.scm
> +++ b/gnu/packages/qt.scm
> @@ -723,6 +723,7 @@ from within Qt 5.")))
> "1l44476ibb8rv4rf80vbjdc3712lmrl1xcxswa513ip66k47p5vn"
>  (arguments
>   (substitute-keyword-arguments (package-arguments qtsvg)
> +   ((#:tests? _ #f) #f) ; TODO: Enable the tests
> ((#:phases phases)
>  `(modify-phases ,phases
> (add-after 'unpack 'disable-network-tests
> @@ -730,7 +731,8 @@ from within Qt 5.")))
>   (("qxmlquery") "# qxmlquery")
>   (("xmlpatterns ") "# xmlpatterns"))
> #t))
> -(native-inputs `(("perl" ,perl)))
> +(native-inputs `(("perl" ,perl)
> + ("qtdeclarative" ,qtdeclarative)))
>  (inputs `(("qtbase" ,qtbase)))
>  (synopsis "Qt XML patterns module")
>  (description "The QtXmlPatterns module is a XQuery and XPath engine for
> @@ -758,8 +760,7 @@ xmlpatternsvalidator.")))
> ("pkg-config" ,pkg-config)
> ("python" ,python)
> ("python-wrapper" ,python-wrapper)
> -   ("qtsvg" ,qtsvg)
> -   ("qtxmlpatterns" ,qtxmlpatterns)))
> +   ("qtsvg" ,qtsvg)))
>  (inputs
>   `(("mesa" ,mesa)
> ("qtbase" ,qtbase)))

I built some other packages depending on 'qtdeclarative' and/or
'qtxmlpatterns' and I haven't seen any failure, so I pushed the patch as
3e10b2418dc0952c16053ccced4baba405facb6b.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 fails to run:
>
> --8<---cut here---start->8---
> 2019-12-31 12:50:42.076   W app startd (log: 
> /home/guillaume/.bitmonero/monero-wallet-gui.log)
> 2019-12-31 12:50:42.077   W Qt:5.12.6 GUI:- | screen: 1920x1080 - dpi: 
> 96.1263 - ratio:0.997092
> 2019-12-31 12:50:42.179   W QQmlApplicationEngine failed to load component
> 2019-12-31 12:50:42.179   W qrc:/main.qml:1693 Type WizardLang unavailable
> 2019-12-31 12:50:42.179   W qrc:/wizard/WizardLang.qml:32 module 
> "QtQuick.XmlListModel" is not installed
> 2019-12-31 12:50:42.179   E Error: no root objects
> --8<---cut here---end--->8---

I was able to build the QML for 'XmlListModel' by making 'qtdeclarative'
a dependency of 'qtxmlpatterns' instead of the opposite (and the QML is in
the 'qtxmlpatterns' package).

Rebuilding the required Qt packages and 'monero-gui' and running it
worked fine. However I'm not too familiar with the Qt packages, so does
someone think this approach could cause problems in some of them?


Here's the patch I used:

--8<---cut here---start->8---
From 2f0befe2e183d65a731e616b7b55808d27d8af8e Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant 
Date: Sun, 5 Jan 2020 19:27:17 +0100
Subject: [PATCH] gnu: qtxmlpatterns: Build QML plugin for XmlListModel.

* gnu/packages/qt.scm (qtdeclarative)[native-inputs]: Remove qtxmlpatterns.
  (qtxmlpatterns)[native-inputs]: Add qtdeclarative.
---
 gnu/packages/qt.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 795b5e9d2b..daa35c77cb 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -723,6 +723,7 @@ from within Qt 5.")))
"1l44476ibb8rv4rf80vbjdc3712lmrl1xcxswa513ip66k47p5vn"
 (arguments
  (substitute-keyword-arguments (package-arguments qtsvg)
+   ((#:tests? _ #f) #f) ; TODO: Enable the tests
((#:phases phases)
 `(modify-phases ,phases
(add-after 'unpack 'disable-network-tests
@@ -730,7 +731,8 @@ from within Qt 5.")))
  (("qxmlquery") "# qxmlquery")
  (("xmlpatterns ") "# xmlpatterns"))
#t))
-(native-inputs `(("perl" ,perl)))
+(native-inputs `(("perl" ,perl)
+ ("qtdeclarative" ,qtdeclarative)))
 (inputs `(("qtbase" ,qtbase)))
 (synopsis "Qt XML patterns module")
 (description "The QtXmlPatterns module is a XQuery and XPath engine for
@@ -758,8 +760,7 @@ xmlpatternsvalidator.")))
("pkg-config" ,pkg-config)
("python" ,python)
("python-wrapper" ,python-wrapper)
-   ("qtsvg" ,qtsvg)
-   ("qtxmlpatterns" ,qtxmlpatterns)))
+   ("qtsvg" ,qtsvg)))
 (inputs
  `(("mesa" ,mesa)
("qtbase" ,qtbase)))
-- 
2.24.1
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 here---start->8---
2019-12-31 12:50:42.076 W app startd (log: 
/home/guillaume/.bitmonero/monero-wallet-gui.log)
2019-12-31 12:50:42.077 W Qt:5.12.6 GUI:- | screen: 1920x1080 - dpi: 96.1263 - 
ratio:0.997092
2019-12-31 12:50:42.179 W QQmlApplicationEngine failed to load component
2019-12-31 12:50:42.179 W qrc:/main.qml:1693 Type WizardLang unavailable
2019-12-31 12:50:42.179 W qrc:/wizard/WizardLang.qml:32 module 
"QtQuick.XmlListModel" is not installed
2019-12-31 12:50:42.179 E Error: no root objects
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

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 guix repository as my default channel, which
>   includes a number of slow-to-build Haskell packages. Now and
>   then, I run out of disk space. So I call `guix gc`, which invariably
>   removes the store paths involved in building my current system generation,
>   so the next call to `guix system reconfigure` takes hours.
>
> Desired situation:
>   After calling `guix gc`, the paths that were involved in my last system
>   build are still around, so reconfiguring doesn’t result in everything
>   being rebuilt.
>
> (If there’s some way I can achieve that now, perhaps by explicitly managing
> some roots, or passing specific arguments to `guix gc`, I’d be happy to
> know! I’d still argue that we should try to make this the default behaviour,
> though.)

Have you tried passing the options '--gc-keep-derivations=yes' and
'--gc-keep-outputs=yes' to guix-daemon?

In the operating-system definition, it would be something like:
--8<---cut here---start->8---
(services
   (cons* (service ...)
  [...]
  (modify-services %desktop-services
(guix-service-type config =>
  (guix-configuration
   (inherit config)
   (extra-options '("--gc-keep-derivations=yes"
"--gc-keep-outputs=yes")))
--8<---cut here---end--->8---

bug#38435: BTRFS open_ctree failed

[Guillaume Le Vaillant]

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.342790] BTRFS error (device sda1): open_ctree failed
>> >
>> > Previous profiles work, I haven't modified anything about my
>> > config.scm between them.
>> >
>> > [...]
>> >
>> >
>> > Contents of /etc/profile.scm:
>> >
>> > [...]
>> >
>> >   (file-systems (cons* (file-system
>> >  (device (file-system-label "GUIX"))
>> >  (mount-point "/")
>> > (options "lazytime,compress")
>> >  (type "btrfs"))
>> >;(file-system
>> >;  (device (uuid "1234-ABCD" 'fat))
>> >;  (mount-point "/boot/efi")
>> >;  (type "vfat"))
>> >%base-file-systems))
>> >  
>> 
>> I just tried adding the 'lazytime' option to my root file system, and
>> I got the same error as you when booting. Could you try removing it
>> and see if it works?
>> 
>> Until recently, the options declared in 'file-system' records were
>> always ignored when mounting the root file system. Now they are taken
>> into consideration, and I think it reveals a bug in the way file
>> systems are mounted. If some options like 'lazytime' or 'defaults'
>> are declared in a 'file-system' record (root file system or not),
>> mounting it fails. However some other options like 'compress' or
>> 'autodefrag' work fine.
>> 
>> I suspect Guix adds some options by default when trying to mount file
>> systems, and maybe we end up with conflicting options or doubled
>> options that cause problems.
>> 
>> 
>> 
>
> I removed it and ran reconfigure and now it works.

Applying patches #38462 and #38468 and changing the file system
definition to the following should allow you to mount the root file
system with the 'lazytime' option:

--8<---cut here---start->8---
(file-system
  (device (file-system-label "GUIX"))
  (mount-point "/")
  (flags '(lazy-time))
  (options "compress")
  (type "btrfs"))
--8<---cut here---end--->8---

bug#38435: BTRFS open_ctree failed

[Guillaume Le Vaillant]

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 modified anything about my config.scm
>> between them.
>>
>> [...]
>>
>>
>> Contents of /etc/profile.scm:
>>
>> [...]
>>
>>   (file-systems (cons* (file-system
>>  (device (file-system-label "GUIX"))
>>  (mount-point "/")
>>   (options "lazytime,compress")
>>  (type "btrfs"))
>>;(file-system
>>;  (device (uuid "1234-ABCD" 'fat))
>>;  (mount-point "/boot/efi")
>>;  (type "vfat"))
>>%base-file-systems))
>>
>
> I just tried adding the 'lazytime' option to my root file system, and
> I got the same error as you when booting. Could you try removing it and
> see if it works?
>
> Until recently, the options declared in 'file-system' records were
> always ignored when mounting the root file system. Now they are taken
> into consideration, and I think it reveals a bug in the way file systems
> are mounted. If some options like 'lazytime' or 'defaults' are declared
> in a 'file-system' record (root file system or not), mounting it fails.
> However some other options like 'compress' or 'autodefrag' work fine.
>
> I suspect Guix adds some options by default when trying to mount file
> systems, and maybe we end up with conflicting options or doubled options
> that cause problems.

Apparently, Guix uses the 'mount' system call directly to mount file
systems (c.f. 'guix/build/syscalls.scm'), and passes all the options
declared in the 'file-system' records in the 'data' argument.

However the man page for mount(2) indicates:

--8<---cut here---start->8---
int mount(const char *source, const char *target,
const char *filesystemtype, unsigned long mountflags,
const void *data);

[...]

The data argument is interpreted by the different filesystems.
Typically it is a string of comma-separated options understood by this
filesystem.  See mount(8) for details of the options available for each
filesystem type.
--8<---cut here---end--->8---

If I understand correcly, the generic options (e.g. 'lazytime') must be
passed in 'mountflags', and the options specific to the file system
(e.g. 'compress') must be passed in 'data'.

This would mean that before calling the 'mount' system call, we must
remove the generic options from the 'options' variable (which is then
passed in 'data'), and add their corresponding flags to the 'flags'
variable (which is then passed in 'mountflags').

What do you think?

bug#38435: BTRFS open_ctree failed

[Guillaume Le Vaillant]

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 of /etc/profile.scm:
>
> [...]
>
>   (file-systems (cons* (file-system
>  (device (file-system-label "GUIX"))
>  (mount-point "/")
>(options "lazytime,compress")
>  (type "btrfs"))
>;(file-system
>;  (device (uuid "1234-ABCD" 'fat))
>;  (mount-point "/boot/efi")
>;  (type "vfat"))
>%base-file-systems))
>

I just tried adding the 'lazytime' option to my root file system, and
I got the same error as you when booting. Could you try removing it and
see if it works?

Until recently, the options declared in 'file-system' records were
always ignored when mounting the root file system. Now they are taken
into consideration, and I think it reveals a bug in the way file systems
are mounted. If some options like 'lazytime' or 'defaults' are declared
in a 'file-system' record (root file system or not), mounting it fails.
However some other options like 'compress' or 'autodefrag' work fine.

I suspect Guix adds some options by default when trying to mount file
systems, and maybe we end up with conflicting options or doubled options
that cause problems.

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

[Guillaume Le Vaillant]

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 build process, like 'gzip', 'bzip2' and 'xz'?

bug#37977: Mount options ignored for root file system

[Guillaume Le Vaillant]

Ludovic Courtès skribis:

> The root file system is mounted by ‘mount-root-file-system’ in
> linux-boot.scm, and you’re right: it happily ignores any options in the
>  object for “/”.  :-)
>
> A solution would be to have ‘boot-system’ take an additional
> #:root-file-system-options parameter that it would pass down to
> ‘mount-root-file-system’, which would honor it.
>
> Would you like to give it a try?

The attached patch adds an 'options' parameter to
'mount-root-file-system' and makes 'boot-system' use it with the
content of the 'options' field of the  object for "/".

It's not exactly the solution you described (adding a keyword argument
to 'boot-system'), but I think it should work. What do you think?

I tried it with my btrfs root file system, and it is correctly mounted
with the options declared in my '/etc/config.scm' file.

>From 3597f0fda6f6a13bf1fdab0fcde4f72ece688d93 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 argument and use it when mounting the root file system.
  (boot-system): Pass the root file system options to
  'mount-root-file-system'.
---
 gnu/build/linux-boot.scm | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
index 84a5447977..a8a9c2e2c8 100644
--- a/gnu/build/linux-boot.scm
+++ b/gnu/build/linux-boot.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès 
 ;;; Copyright © 2017 Mathieu Othacehe 
+;;; Copyright © 2019 Guillaume Le Vaillant 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -357,15 +358,16 @@ the last argument of `mknod'."
   (filter-map string->number (scandir "/proc")
 
 (define* (mount-root-file-system root type
- #:key volatile-root?)
+ #:key volatile-root? options)
   "Mount the root file system of type TYPE at device ROOT.  If VOLATILE-ROOT?
 is true, mount ROOT read-only and make it an overlay with a writable tmpfs
-using the kernel built-in overlayfs."
+using the kernel built-in overlayfs.  OPTIONS indicates the options to use
+to mount ROOT."
 
   (if volatile-root?
   (begin
 (mkdir-p "/real-root")
-(mount root "/real-root" type MS_RDONLY)
+(mount root "/real-root" type MS_RDONLY options)
 (mkdir-p "/rw-root")
 (mount "none" "/rw-root" "tmpfs")
 
@@ -382,7 +384,7 @@ using the kernel built-in overlayfs."
"lowerdir=/real-root,upperdir=/rw-root/upper,workdir=/rw-root/work"))
   (begin
 (check-file-system root type)
-(mount root "/root" type)))
+(mount root "/root" type 0 options)))
 
   ;; Make sure /root/etc/mtab is a symlink to /proc/self/mounts.
   (false-if-exception
@@ -472,6 +474,12 @@ upon error."
  mounts)
 "ext4"))
 
+  (define root-fs-options
+(any (lambda (fs)
+   (and (root-mount-point? fs)
+(file-system-options fs)))
+ mounts))
+
   (display "Welcome, this is GNU's early boot Guile.\n")
   (display "Use '--repl' for an initrd REPL.\n\n")
 
@@ -524,7 +532,8 @@ upon error."
  (else (file-system-label root)
  (mount-root-file-system (canonicalize-device-spec root)
  root-fs-type
- #:volatile-root? volatile-root?))
+ #:volatile-root? volatile-root?
+ #:options root-fs-options))
(mount "none" "/root" "tmpfs"))
 
;; Mount the specified file systems.
-- 
2.24.0

bug#37977: Mount options ignored for root file system

[Guillaume Le Vaillant]

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,autodefrag,compress=lzo" in kernel
arguments, but it didn't have any effect.

I then tried adding a one-shot service that remounts the root file
system, and it works, the options declared in '/etc/fstab' are taken
into consideration. This service just does 'mount -o remount /'.

--8<---cut here---start->8---
(define remount-rootfs-service-type
  (shepherd-service-type
   'remount-rootfs
   (const
(shepherd-service
 (documentation "Remount rootfs with correct options.")
 (requirement '(udev))
 (provision '(remount-rootfs))
 (one-shot? #t)
 (start #~(lambda _
(invoke (string-append #$util-linux "/bin/mount")
"-o" "remount" "/")))

(operating-system
  ...
  (services
(cons* ...
   (service remount-rootfs-service-type #f)
   ...)))
--8<---cut here---end--->8---


I saw that the 'start' function of 'root-file-system-service-type'
doesn't do anything. Is it on purpose? Or could we make it remount the
root filesystem?

bug#37977: Mount options ignored for root file system

[Guillaume Le Vaillant]

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
(uuid "ee90b2aa-97e8-4ae5-ac72-9bf9058cc949"))
  (target "cryptroot")
  (type luks-device-mapping))
(mapped-device
  (source
(uuid "ec9cd327-0370-4e20-baa4-254d03b1901e"))
  (target "cryptguillaume")
  (type luks-device-mapping
(file-systems
  (cons* (file-system
   (mount-point "/")
   (device "/dev/mapper/cryptroot")
   (type "btrfs")
   (options "autodefrag,compress=lzo")
   (dependencies mapped-devices))
 (file-system
   (mount-point "/home/guillaume")
   (device "/dev/mapper/cryptguillaume")
   (type "btrfs")
   (options "autodefrag,compress=lzo")
   (dependencies mapped-devices))
 %base-file-systems))
--8<---cut here---end--->8---


Exerpt from '/etc/fstab':

--8<---cut here---start->8---
/dev/mapper/cryptroot / btrfs autodefrag,compress=lzo   
/dev/mapper/cryptguillaume /home/guillaume btrfs autodefrag,compress=lzo
--8<---cut here---end--->8---


Exerpt from '/etc/mtab':

--8<---cut here---start->8---
/dev/mapper/cryptroot / btrfs
  rw,relatime,ssd,space_cache,subvolid=5,subvol=/
  0 0

/dev/mapper/cryptguillaume /home/guillaume btrfs
  rw,relatime,compress=lzo,ssd,space_cache,autodefrag,subvolid=5,subvol=/
  0 0

/dev/mapper/cryptroot /gnu/store btrfs
  ro,relatime,ssd,space_cache,subvolid=5,subvol=/gnu/store
  0 0
--8<---cut here---end--->8---

Here we see that the options 'autodefrag' and 'compress=lzo' have
disappeared on the root filesystem. Maybe it has something to do with
the new '/gnu/store' subvolume that appeared?