bug#70258: FreeCAD dependency probably outdated

[Guillaume Le Vaillant]

Fixed by .


signature.asc
Description: PGP signature

bug#70698: python-pivy build fails (freecad dependency)

[Guillaume Le Vaillant]

Fixed by .


signature.asc
Description: PGP signature

bug#70237: Can't build python-pyside-2 5.15.10

[Guillaume Le Vaillant]

Buttons Presser via Bug reports for GNU Guix  skribis:

> Hi, I still have the same issue with python-pyside-2-5.15.10 (the build log 
> is the same) even though I pulled most fresh guix (commit: 21fad13).
>
> This package also blocks the 'freecad' installation:
>
> building /gnu/store/...-python-pyside-2-5.15.10.drv...
> - 'fix-qt-module-detection' phasebuilder for 
> `/gnu/store/...-python-pyside-2-5.15.10.drv' build of 
> /gnu/store/...-python-pyside-2-5.15.10.drv failed
> View build log at 
> '/var/log/guix/drvs/i0/...-python-pyside-2-5.15.10.drv.gz'.
> cannot build derivation `/gnu/store/...-freecad-0.21.2.drv': 1 
> dependencies couldn't be buguix home: error: build of 
> `/gnu/store/...-freecad-0.21.2.drv' failed
>
> I was wandering how long does it take for the above mentioned bug fix to be 
> available on main guix? Or the python-pyside-2 package is still broken?

Hi.
There was another fix for python-pyside-2 in commit
6d0502f9c3608ffd6b3b3c9b603cb5d4ad14d8c9.
So if you do a "guix pull" now, python-pyside-2 shoud build
successfully.


signature.asc
Description: PGP signature

bug#68764: ASDF can't load sbcl-clx-truetype installed through Guix

[Guillaume Le Vaillant]

Lars Rustand  skribis:

> I had forgot about this thread, but randomly saw it mentioned on IRC
> today. The problem in my case was that I had some packages in
> ~/common-lisp. Since I was running the container from my home folder
> this was still visible inside the container even though it was --pure.
> After deleting the ~/common-lisp folder I was able to load the package
> without any issue, both inside a container/shell and directly on my
> system also.

Ok. Closing the issue then.


signature.asc
Description: PGP signature

bug#69585: sbcl-fast-generic-functions: Failed to build

[Guillaume Le Vaillant]

Sharlatan Hellseher  skribis:

> Hi Guix,
>
> I've noticed that sbcl-fast-generic-functions is failed to build since
> <12 Sep 2023 18:35> see .
>
> Keep it tracked in issues for the future fix.
>
> --8<---cut here---start->8---
> ; caught ERROR:
> ;   READ error during COMPILE-FILE:
> ;
> ; Lock on package SB-PCL violated when interning %NO-PRIMARY-METHOD while 
> in
> ; package FAST-GENERIC-FUNCTIONS.
> ;   See also:
> ; The SBCL Manual, Node "Package Locks"
> ;
> ; (in form starting at line: 3, column: 0, position: 39)
>
> ; compilation aborted after 0:00:00.000
> Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread # tid=28 "main thread" RUNNING
>   {1001460003}>:
>   COMPILE-FILE-ERROR while compiling
>#
> --8<---cut here---end--->8---

Hi.
Reported upstream at
.


signature.asc
Description: PGP signature

bug#65441: leptonica 1.83.1 ioformats_reg test failure

[Guillaume Le Vaillant]

Fixed in df5653adcbd1f9799f810f46d514b2ca4112af97.
Closing.


signature.asc
Description: PGP signature

bug#69129: sbcl-mcclim broke on upgrade to sbcl@2.4.0

[Guillaume Le Vaillant]

Christopher Howard  skribis:

> Hi, to reproduce, run demodemo as you have done, and then click/tap the 
> Stream test button. When the new window appears, start to move your graphical 
> cursor
> over it and it will throw the error.
>
> I observed that this is now happening with at least several other of the 
> demodemo test applications, and it was happening in my private application as 
> well,
> which I have not yet released, on multiple computers. I haven't done much 
> research into the exact cause of the problem, as in my mind it was more of an 
> excuse
> to request an update to the latest release of mcclim.

Hi.
I tried updating mcclim to 0.9.8, but it didn't make any difference.
I also tried updating some dependencies, like clx or cl-freetype2, but
it still didn't make a difference.
I guess some debugging is going to be necessary...


signature.asc
Description: PGP signature

bug#69129: sbcl-mcclim broke on upgrade to sbcl@2.4.0

[Guillaume Le Vaillant]

Christopher Howard  skribis:

> Hello, sbcl-mcclim library broke on the upgrade to sbcl@2.4.0. Something 
> changed so that many applications (include :clim-examples demos) break in 
> runtime with an error like so:
>
> ```
> invalid keyword argument: :CLIPPING-REGION (valid keys are :INK,
> :TEXT-STYLE).
>[Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]
> ```
>
> The problem is not present if I time-machine back to a commit with sbcl@2.3.7.
>
> Rather than troubleshooting this problem, I would recommend upgrading 
> sbcl-mcclim to the latest official release, which is Version 0.9.8.

Hi.
I don't reproduce the issue. I tried with:

--8<---cut here---start->8---
guix shell sbcl sbcl-mcclim -- sbcl --no-userinit

(require :asdf)
(asdf:load-system "clim-examples")
(clim-demo:demodemo)
--8<---cut here---end--->8---

and it worked. What command did you use to get the error?


signature.asc
Description: PGP signature

bug#68764: ASDF can't load sbcl-clx-truetype installed through Guix

[Guillaume Le Vaillant]

rustand.l...@gmail.com skribis:

> John Kehayias  writes:
>
>> Hi Lars,
>>
>> I can't reproduce this, at least on Guix at commit
>> da3e6aea0a750246e8a9120d62441c3df65faff0
>>
>> I ran your command in one line with guix shell (and set --pure just in
>> case; I have SBCL_HOME set, not sure if anything else relevant):
>> ...
>> Perhaps try with 'guix shell --pure' as well, in case it is an
>> environment setting?
>>
>> John
>
> I ran the exact same command as you, and still get the error inside the
> pure shell. Also, I don't think this has anything to do with a specific
> Guix commit, since this has been like this for several months. In fact
> it has never worked for me at all. I did a pull again now, so should be
> on the latest commit, but the error is still present. I am currently on
> dc8aa52.
>
> I even tried running it in a container, and the error is there also, so
> this cannot be because of something else in my system, right?

Hi.
Could you check if adding the "--no-userinit" option for sbcl makes
a difference?


signature.asc
Description: PGP signature

bug#67792: txr: certain string substitution in recipe obsolete.

[Guillaume Le Vaillant]

Fixed in ac61e9705fb8c450c6cd0c1731fbb1b909c1f944.
Thanks.


signature.asc
Description: PGP signature

bug#67042: ecl-cl-pcg fails to build due to a flaky test (was: Re: bug#67042: ecl-seedable-rng recently broken)

[Guillaume Le Vaillant]

Tests for ecl-cl-pcg disabled in
9a4a480f8d51da8bf25b61a98e1092a6cd6f76ee.
Closing.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

It looks like this build failure doesn't happen anymore now.
Closing.


signature.asc
Description: PGP signature

bug#67042: ecl-seedable-rng recently broken

[Guillaume Le Vaillant]

Maxim Cournoyer  skribis:

> Hi,
>
> guix-comm...@gnu.org writes:
>
>> glv pushed a commit to branch master
>> in repository guix.
>>
>> commit 42bec70a91d2205371c96287bcf565dcc5f5dd74
>> Author: Andre A. Gomes 
>> AuthorDate: Thu Nov 2 11:19:41 2023 +0200
>>
>> gnu: cl-slynk: Update to 1.0.43-9.9c43bf6.
>> 
>> * gnu/packages/lisp-xyz.scm (sbcl-slynk): Update to 1.0.43-9.9c43bf6.
>> 
>> Signed-off-by: Guillaume Le Vaillant 
>> Change-Id: I84ff141b7eefff470f72493d02f2cc24f02db7cf
>
> This commit or some preceding cl-* ones broke ecl-seedable-rng,
> according to notifications from the CI:
>
> ecl-seedable-rng.x86_64-linux on master is broken
>
> Potentially related failures:
>
> - sbcl-cl-freetype2 (https://ci.guix.gnu.org/build/2584694/details)
> - ecl-origin (https://ci.guix.gnu.org/build/2580823/details)
>
> See: https://ci.guix.gnu.org/build/2585168/details

Hi.

Locally I can build sbcl-cl-freetype2 and ecl-origin without issue.

Concerning ecl-seedable-rng, there's something funny going on. The build
details on the CI list only 1 dependency (ecl-ironclad), but there
should be 3; ecl-cl-pcg and ecl-golden-utils are missing. And it is in
fact the ecl-cl-pcg dependency that fails to build (because of a test).
However, neither ecl-cl-pcg nor its dependencies have been updated
recently, so why did the CI need to rebuild it, and why did it start
failing?


signature.asc
Description: PGP signature

bug#66305: Error with recursive git checkout

[Guillaume Le Vaillant]

Workaround: by rebooting the machine to an older generation (and
therefore an older guix-daemon, with Guix at
4f35ff1275e05be31f5d41464ccf147e9dbfd016), the recursive git-fetch
works.


signature.asc
Description: PGP signature

bug#66305: Error with recursive git checkout

[Guillaume Le Vaillant]

Hi.

With Guix at 47d0346553fdad9795c9390a60944ccaad7e5255, I'm unable to
build a package (see attached patch) requiring a recursive git-fetch to
get the sources:

--8<---cut here---start->8---
$ ./pre-inst-env guix build bladerf
The following derivations will be built:
  /gnu/store/982zz7z94va89fxn79hpjil5wp0v49pn-bladerf-2023.02.drv
  /gnu/store/5rlqf4srlnnymsv93ydxkgxwgfszkszw-bladerf-2023.02-checkout.drv
building 
/gnu/store/5rlqf4srlnnymsv93ydxkgxwgfszkszw-bladerf-2023.02-checkout.drv...
Initialized empty Git repository in 
/gnu/store/fhlm9zxs4r4cgapbngckpzrs8rnzf1l2-bladerf-2023.02-checkout/.git/
From https://github.com/Nuand/bladeRF
 * tag   2023.02-> FETCH_HEAD
Note: switching to 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 41ef634 Revert "libbladeRF: update compatibility for FPGA 
v0.15.0 from libbladeRF 2.4.0 to 2.5.0"
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-submodule:
 line 7: basename: command not found
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-submodule:
 line 7: sed: command not found
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-sh-setup:
 line 77: basename: command not found
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-sh-setup:
 line 77: sed: command not found
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-sh-setup:
 line 292: uname: command not found
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-submodule:
 line 613: sed: command not found
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git-submodule:
 line 613: cmd_: command not found
git-fetch: 
'/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/git 
submodule update --init --recursive' failed with exit code 127
--8<---cut here---end--->8---
From ac6fc0fdf16187c4e0c61916c52ced35a031fd76 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Guillaume Le Vaillant 
Date: Sat, 30 Sep 2023 11:17:40 +0200
Subject: [PATCH 1/8] gnu: Add bladerf.

* gnu/packages/radio.scm (bladerf): New variable.
---
 gnu/packages/radio.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/radio.scm b/gnu/packages/radio.scm
index 2e4e9db4cc..aa26c04db2 100644
--- a/gnu/packages/radio.scm
+++ b/gnu/packages/radio.scm
@@ -69,10 +69,12 @@ (define-module (gnu packages radio)
   #:use-module (gnu packages image)
   #:use-module (gnu packages image-processing)
   #:use-module (gnu packages javascript)
+  #:use-module (gnu packages libedit)
   #:use-module (gnu packages libusb)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages logging)
   #:use-module (gnu packages lua)
+  #:use-module (gnu packages man)
   #:use-module (gnu packages maths)
   #:use-module (gnu packages mp3)
   #:use-module (gnu packages multiprecision)
@@ -1416,6 +1418,43 @@ (define-public hackrf
 @code{(udev-rules-service 'hackrf hackrf #:groups '(\"dialout\"))}.")
 (license license:gpl2)))
 
+(define-public bladerf
+  (package
+(name "bladerf")
+(version "2023.02")
+(source
+ (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://github.com/Nuand/bladeRF;)
+ (commit version)
+ (recursive? #t)))
+   (file-name (git-file-name name version))
+   (sha256
+(base32 "038v9qdmrwx9mxsrq4l36bap0bsypyg4i8hs7l7srv4b0c2s7ynp"
+(build-system cmake-build-system)
+(native-inputs (list doxygen help2man pkg-config))
+(inputs (list libedit libusb))
+(arguments
+ (list #:configure-flags #~(list "-DTAGGED_RELEASE=ON"
+ (string-append "-DUDEV_RULES_PATH="
+#$output
+"/lib/udev/rules.d")
+ "-DBLADERF_GROUP=dialout"
+ "-DBUILD_DOCUMENTATION=ON")
+   #:tests? #f)) ; No test suite
+(home-page "https://www.nuand.com/;)
+(synopsis "User-space library and utilities for BladeRF SDR")
+(description
+ "This package contains a li

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Guillaume Le Vaillant]

Liliana Marie Prikler  skribis:

> Am Sonntag, dem 24.09.2023 um 08:49 + schrieb Guillaume Le
> Vaillant:
>> Liliana Marie Prikler  skribis:
>> 
>> > Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
>> > > I am trying to upgrade my guix systems. I ran guix pull and now I
>> > > am
>> > > trying to run guix system reconfigure. It failed on two different
>> > > machines with the same backtrace. Please see the full backtrace
>> > > attached. The error message from it:
>> > > 
>> > > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> > > Git error: object not found - no match for id
>> > > (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
>> > > 
>> > > 
>> > > $ guix describe
>> > > Generation 28   Sep 23 2023 19:30:36(current)
>> > >   guix 4f35ff1
>> > >     repository URL: https://git.savannah.gnu.org/git/guix.git
>> > >     branch: master
>> > >     commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016
>> > > 
>> > > Considering that I experience it on two guix machines with
>> > > different
>> > > system configurations, I assume that there is some bug somewhere.
>> > Experiencing the same for commit
>> > 35fd25af9bbcce84908101a9f487ba106a8d6df7.  I would hazard a guess
>> > that it's due to them being merge commits.  Interestingly,
>> > allow-downgrades does not have an effect on this message.
>> > 
>> > Cheers
>> 
>> I reconfigured two machines using commit
>> 4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both
>> machines, I didn't get this "no match for id" issue.
>> That's strange...
> Do you have provenance tracking on your machines (the default)?

Yes. I use an additional channel, not only the "guix" default channel.
Maybe that makes a difference...


signature.asc
Description: PGP signature

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Guillaume Le Vaillant]

Liliana Marie Prikler  skribis:

> Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
>> I am trying to upgrade my guix systems. I ran guix pull and now I am
>> trying to run guix system reconfigure. It failed on two different
>> machines with the same backtrace. Please see the full backtrace
>> attached. The error message from it:
>> 
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Git error: object not found - no match for id
>> (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
>> 
>> 
>> $ guix describe
>> Generation 28   Sep 23 2023 19:30:36(current)
>>   guix 4f35ff1
>>     repository URL: https://git.savannah.gnu.org/git/guix.git
>>     branch: master
>>     commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016
>> 
>> Considering that I experience it on two guix machines with different
>> system configurations, I assume that there is some bug somewhere.
> Experiencing the same for commit
> 35fd25af9bbcce84908101a9f487ba106a8d6df7.  I would hazard a guess that
> it's due to them being merge commits.  Interestingly, allow-downgrades
> does not have an effect on this message.
>
> Cheers

I reconfigured two machines using commit
4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both
machines, I didn't get this "no match for id" issue.
That's strange...


signature.asc
Description: PGP signature

bug#66072: Duplicate/conflicting definitions for ocl-icd

[Guillaume Le Vaillant]

As the duplicate has been removed, I'm closing the issue.
If one day we find a conflict between open-icd-loader and ocl-icd, we'll
open a new bug report.


signature.asc
Description: PGP signature

bug#66072: Duplicate/conflicting definitions for ocl-icd

[Guillaume Le Vaillant]

Hi.
There are currently two conflicting definitions of ocl-icd in
"opencl.scm":

--8<---cut here---start->8---
(define-public ocl-icd
  (deprecated-package "ocl-icd" opencl-icd-loader))
--8<---cut here---end--->8---

and

--8<---cut here---start->8---
(define-public ocl-icd
  (package
(name "ocl-icd")
(version "2.3.2")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/OCL-dev/ocl-icd;)
 (commit (string-append "v" version
   (file-name (git-file-name name version))
   (sha256
(base32 "0y0lnxb6zlhfb5vxxib5n1vvxa4b23qc0j3lsih6yjz9j37mj7wz"
(build-system gnu-build-system)
(native-inputs
 (list autoconf automake libtool ruby))
(home-page "https://github.com/OCL-dev/ocl-icd;)
(synopsis "Generic OpenCL @acronym{ICD, Installable Client Driver} loader")
(description
 "This package provides an OpenCL @acronym{ICD, Installable Client Driver}
loader.  It maintains a YAML database of all known and guessed function pointers
from vendor-specific drivers.  It also delivers a skeleton of bindings to
incorporate inside an OpenCL implementation to give it ICD functionalities.")
(license license:bsd-2)))
--8<---cut here---end--->8---

Which is the good one?


signature.asc
Description: PGP signature

bug#63456: [PATCH] gnu: mesa-opencl: Remove reference to patch

[Guillaume Le Vaillant]

Patch pushed as 930e6e3e7a1c5f83aedb49f6fa0ebb0e0bdeeef3.
Thanks.


signature.asc
Description: PGP signature

bug#63430: python-pyside-2-5.15.8

[Guillaume Le Vaillant]

"bdju" via Bug reports for GNU Guix  skribis:

> guix (GNU Guix) e0c35d1578c10a8fe27c8372f3a8bb5dd88b01b8
> guix system
> python-pyside-2-5.15.8 build log attached
>
> [3. text/plain; guix-build-failure_python-pyside-2-5.15.8.txt]...

Hi,
There a fix for this in Guix at e2eb43f945fd467e9b55a4b3c91cd186cf32e268
or later.
Closing.


signature.asc
Description: PGP signature

bug#62890: StumpWM fails to start - Read only file system

[Guillaume Le Vaillant]

I think the issue comes from grafts.

Without grafts, the ASDF configuration is coherent; the path for
stumpwm's sources and libraries is the same everywhere (here in
stumpwm:lib and sbcl-stumpwm-cpu):

--8<---cut here---start->8---
$ cat $(guix build --no-grafts stumpwm | grep 
'lib$')/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 
("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree 
"/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

$ cat $(guix build --no-grafts 
sbcl-stumpwm-cpu)/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 
("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree 
"/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
--8<---cut here---end--->8---


With grafts, we get different paths, which probably explains why ASDF
fails to find the compiled Lisp files it is looking for:

--8<---cut here---start->8---
$ cat $(guix build stumpwm | grep 'lib$')/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 
("/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree 
"/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

$ cat $(guix build sbcl-stumpwm-cpu)/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 
("/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree 
"/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#62890: StumpWM fails to start - Read only file system

[Guillaume Le Vaillant]

Kjartan Óli Águstsson  skribis:

> I just started experiencing an issue with stumpwm where it fails to
> start, complaining about a read only file system.  A web search for the
> error message leads me to
> https://lists.gnu.org/archive/html/help-guix/2021-02/msg00080.html,
> which sounds exactly like the problem I'm experiencing.  I'm unsure how
> to get the backtrace shared in that thread, or in general how to proceed
> with debugging this.
>
> guix describe shows:
>   guix 9a5e1dc
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 9a5e1dc1f16f5f8c056e64f2077b035784003673
> but I tried rolling back to an earlier system generation:
>   guix:
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: d513ba83ebca347164098bb0fa1354f3657bc7e2
> to no success so I doubt it is a new change in Guix.
>
> Unless I'm missing something in the help-guix thread there is no
> solution discussed there, so any help in debugging this would be greatly
> appreciated.

Hi,

I just got the same problem after reconfiguring a machine (using
guix-home, but I'm not sure if it is relevant). It only happens when
I try to load extra modules from the ".stumpwm/init.lisp" file.

It looks like the configuration indicating where to search for the
compiled Common Lisp files (ASDF's source-registry and
output-translations) is not taken into consideration by Stumpwm
anymore... so it tries to recompile them in the wrong place.

As a workaround, replacing:
  exec stumpwm
by:
  exec sbcl --no-userinit --non-interactive --eval '(require :asdf)' --eval 
'(asdf:load-system "stumpwm")' --eval '(stumpwm:stumpwm)'
in my ".xsession" file seems to work...


signature.asc
Description: PGP signature

bug#59331: sbcl currently fails to build on aarch64

[Guillaume Le Vaillant]

I registered the new patch file in "gnu/local.mk" and pushed as
cc08d374b21f1326c2d70d5af84b56c0714a0885.
Thanks.


signature.asc
Description: PGP signature

bug#59331: sbcl currently fails to build on aarch64

[Guillaume Le Vaillant]

Andrew Patterson  skribis:

> The genesis subdirectory of src/runtime doesn't exist, so the build fails.
> Building on x86_64 successfully gets past the point where it fails on
> aarch64/arm64.

From the build log, it looks like the "make-host-1" part of SBCL's build
exits prematurely because of the following error:

--8<---cut here---start->8---
;; Compiling file 
/tmp/guix-build-sbcl-2.2.10.drv-0/sbcl-2.2.10/src/compiler/arm64/vm.lisp ...
*** - IF: variable NULL-OFFSET has no value
The following restarts are available:
USE-VALUE  :R1  Input a value to be used instead of NULL-OFFSET.
STORE-VALUE:R2  Input a new value for NULL-OFFSET.
RECOMPILE  :R3  Recompile file "src/compiler/arm64/vm.lisp"
RECOMPILE  :R4  Recompile
SKIP   :R5  skip (MAYBE-WITH-COMPILATION-UNIT # # ...)
RETRY  :R6  retry (MAYBE-WITH-COMPILATION-UNIT # # ...)
STOP   :R7  stop loading file 
/tmp/guix-build-sbcl-2.2.10.drv-0/sbcl-2.2.10/make-host-1.lisp
ABORT-BUILD:R8  Abort building SBCL.
ABORT  :R9  Abort main loop
--8<---cut here---end--->8---

Have you asked upstream if they know what could cause this error?


signature.asc
Description: PGP signature

bug#59200: reproducibility

[Guillaume Le Vaillant]

ykonai  skribis:

> Hi,
>
> It turns out this was due to the fact that I had ironclad git cloned on
> my computer, which was accidentally visible via :tree in the ASDF
> configuration. ASDF detected that a different ironclad was used and
> tried to compile-file to the gnu/store. I thought it was guix-related
> since it did occur with both --pure and --container, but I was running
> it with the default cwd share on.
>
> Using --container --no-cwd is the solution to this problem. 

Ok. Closing.


signature.asc
Description: PGP signature

bug#59200: reproducibility

[Guillaume Le Vaillant]

ykonai via Bug reports for GNU Guix  skribis:

> I can definitely consistently reproduce this issue. Maybe something in
> your filesystem could interfere with this? Try:
> guix shell sbcl sbcl-uuid --container -- sbcl --eval '(require :asdf)'
> --eval '(asdf:load-system :uuid)'
>
> This is on guix commit 8f9588185d74f1f251b041b84d43302c337588ff, which
> is from a fresh guix pull.
>
> I was wrong wrt. .fasl files missing: ls -l $(guix build
> sbcl-uuid)/lib/common-lisp/sbcl/uuid/ does show that the FASL is there,
> it is simply that SBCL arbitrarily decides it needs to be recompiled,
> which looks like the problem here. It could be some ASDF upstream bug.

I tried:

--8<---cut here---start->8---
guix time-machine --commit=8f9588185d74f1f251b041b84d43302c337588ff -- \
  shell sbcl sbcl-uuid --container -- \
  sbcl --no-userinit --eval '(require :asdf)' --eval '(asdf:load-system :uuid)'
--8<---cut here---end--->8---

and it worked without error.

Maybe there is something in your local CL configuration (.sbclrc) that
ASDF doesn't like...
Could you check if you still have an error when ignoring the local
configuration with:

--8<---cut here---start->8---
guix shell sbcl sbcl-uuid --container -- \
  sbcl --no-userinit --eval '(require :asdf)' --eval '(asdf:load-system :uuid)'
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#59200: ASDF build system/sbcl doesn't build FASLs on some packages

[Guillaume Le Vaillant]

Hi,

I can't reproduce this issue.

I tried
--8<---cut here---start->8---
guix shell sbcl sbcl-uuid --pure -- sbcl --eval '(require :asdf)' --eval 
'(asdf:load-system :uuid)'
guix shell sbcl sbcl-cl-containers --pure -- sbcl --eval '(require :asdf)' 
--eval '(asdf:load-system :cl-containers)'
--8<---cut here---end--->8---
and both commands worked without any error.

With each of the following commands, do you see the "uuid.fasl" file at
the end or not?
--8<---cut here---start->8---
ls -l $(guix build sbcl-uuid)/lib/common-lisp/sbcl/uuid/
ls -l $(guix build --check --no-grafts sbcl-uuid)/lib/common-lisp/sbcl/uuid/
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#52140: [core-updates-frozen] tcc fails to build

[Guillaume Le Vaillant]

tcc currently builds successfully.
Closing.


signature.asc
Description: PGP signature

bug#41160: sbcl-cffi-libffi: Fails to build on ARM

[Guillaume Le Vaillant]

I tested building for armhf and aarch64 with Guix at
0898fd56c910cc76d8b59bbe781f1a05ab78fad6, and it worked fine.
Closing.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

This has been fixed with commit
6b5ef03a2582ab23228478018fd356e17db1daea.
Closing.


signature.asc
Description: PGP signature

bug#55512: monero-gui@0.17.3.2 is unable to use p2pool miner due to it's binaries instalaltion to read-only filesystem

[Guillaume Le Vaillant]

Hi,

I fixed the path to the p2pool binary in commit
eecb5efad92b8f7cb5bbea0be66c4707a749512c.
I checked that p2pool starts when clicking the "Start Mining" button,
but I have not tested if all its functionalities are working correctly.
Please open a new bug report if you find issues.


signature.asc
Description: PGP signature

bug#57137: FreeCAD welcome page text rendering does not work.

[Guillaume Le Vaillant]

It's a QtWebengine/Chromium bug that affects several programs like
Calibre, FreeCAD or Qutebrowser (see issues #54033 and #54297).

A workaround is to pass the "no-sandbox" option to Chromium. It can be
done by setting the QTWEBENGINE_CHROMIUM_FLAGS environment variable.
For example:

--8<---cut here---start->8---
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" FreeCAD
--8<---cut here---end--->8---

or:

--8<---cut here---start->8---
export QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox"
FreeCAD
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> I'll be the road for a while, unable to work on this patch, so if anyone
> wants to work on it and merge, please go ahead :)
>
> Left to do:
>
> - Suggestion: add a keyword to choose between asdf:compile-system and
>   asdf:load-system (default should be asdf:load-system).
> - Make sure sbcl-stumpwm-kbd-layouts usees asdf:compile-system.
> - Rebuild the Lisp world to test.

I added a 'asd-operation' keyword parameter with a default value of
"load-system", and I used it in the package definition of
sbcl-stumpwm-kbd-layouts to use "compile-system" instead.

Patches pushed as 6b5ef03a2582ab23228478018fd356e17db1daea and
following.


signature.asc
Description: PGP signature

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> Robert Goldman from ASDF found out why the "COMPONENT not found" issue 
> happens:
>
> https://gitlab.common-lisp.net/asdf/asdf/-/issues/119#note_9808
>
> So either we fix most of the Prove-depending libraries, or we just do
> what's expected from every one, that is, add the directory to the ASDF
> registries.
>
> The latter is much easier of course...

As adding the build directory to ASDF's registry is easier and also
simplifies asdf-build-system, would should do that. And we could still
open issues upstream for libraries that are starting their test suites
in a wrong way.


signature.asc
Description: PGP signature

bug#56353: sbcl-2.2.6 build fail

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> b...@bokr.com skribis:
>
>> I wonder what running this at the time builds failed would have shown:
>>
>> #/usr/bin/bash
>> # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes 
>> (no top opt for that??)
>> top -n 1 | \
>> sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
>> -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
>> -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
>>
>> (no guarantees on my hack to get rid of the highlighting escapes
>> and utf8->ascii quote subst :)
>> (top seems to assume even -n 1 output is always going to interactive dest)
>>
>> Anyway, wondering: Could memory and CPU loading at the time
>> have triggered the build failure?
>
> I don't think so. It looks like the SB-SIMD optional module only gets
> built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and
> Harbourfront machines don't, and this is why the 'build-doc' phase fails
> when trying to load SB-SIMD to compile its documentation.
>
> I'm testing a patch disabling SB-SIMD, and I'll push it if all goes
> well.

Patch pushed as e0d2f8164e6a1c15fdcae6f7dadb05c0c9e25352.
Closing.


signature.asc
Description: PGP signature

bug#56353: sbcl-2.2.6 build fail

[Guillaume Le Vaillant]

b...@bokr.com skribis:

> I wonder what running this at the time builds failed would have shown:
>
> #/usr/bin/bash
> # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes 
> (no top opt for that??)
> top -n 1 | \
> sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \
> -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \
> -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g'
>
> (no guarantees on my hack to get rid of the highlighting escapes
> and utf8->ascii quote subst :)
> (top seems to assume even -n 1 output is always going to interactive dest)
>
> Anyway, wondering: Could memory and CPU loading at the time
> have triggered the build failure?

I don't think so. It looks like the SB-SIMD optional module only gets
built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and
Harbourfront machines don't, and this is why the 'build-doc' phase fails
when trying to load SB-SIMD to compile its documentation.

I'm testing a patch disabling SB-SIMD, and I'll push it if all goes
well.


signature.asc
Description: PGP signature

bug#56353: sbcl-2.2.6 build fail

[Guillaume Le Vaillant]

Christopher Baines  skribis:

> Tobias Geerinckx-Rice via Bug reports for GNU Guix  writes:
>
>> On 2 July 2022 09:29:22 UTC, Wensheng Xie  wrote:
>>>Das Erstellungsprotokoll kann unter 
>>>„/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ 
>>>eingesehen werden.
>>
>>
>> This log file is always a good idea to include.
>
> I think this is the equivalent non-grafted derivation:
>
>   
> https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
>
> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
> get it to build successfully once though on my laptop.
>
> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
> successfully, or if there's particular conditions for it to build?
>
> Thanks,
>
> Chris

According to the logs, the 'build-doc' phase fails to compile the
documentation for SIMD related functions. There's a patch disabling this
part of the doc unless we compile on x86_64, but maybe not all x86_64
CPUs have the required instructions...

Would it be possible to get the result of "lscpu" on some machines where
it fails?

The build always works on my machine:
--8<---cut here---start->8---
Architecture:x86_64
  CPU op-mode(s):32-bit, 64-bit
  Address sizes: 48 bits physical, 48 bits virtual
  Byte Order:Little Endian
CPU(s):  32
  On-line CPU(s) list:   0-31
Vendor ID:   AuthenticAMD
  Model name:AMD Ryzen 9 5950X 16-Core Processor
CPU family:  25
Model:   33
Thread(s) per core:  2
Core(s) per socket:  16
Socket(s):   1
Stepping:0
Frequency boost: enabled
CPU max MHz: 5083.3979
CPU min MHz: 2200.
BogoMIPS:6786.83
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_go
 od nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl 
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx 
f16c rdrand lahf_lm cmp_legacy sv
 m extapic cr8_legacy abm sse4a misalignsse 
3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext 
perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate
  ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 
smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni 
xsaveopt xsavec xgetbv1 xsaves cqm_llc c
 qm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf 
xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean 
flushbyasid decodeassists paus
 efilter pfthreshold avic v_vmsave_vmload vgif 
v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
Virtualization features: 
  Virtualization:AMD-V
Caches (sum of all): 
  L1d:   512 KiB (16 instances)
  L1i:   512 KiB (16 instances)
  L2:8 MiB (16 instances)
  L3:64 MiB (2 instances)
NUMA:
  NUMA node(s):  1
  NUMA node0 CPU(s): 0-31
Vulnerabilities: 
  Itlb multihit: Not affected
  L1tf:  Not affected
  Mds:   Not affected
  Meltdown:  Not affected
  Mmio stale data:   Not affected
  Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:Mitigation; usercopy/swapgs barriers and __user 
pointer sanitization
  Spectre v2:Mitigation; Retpolines, IBPB conditional, IBRS_FW, 
STIBP always-on, RSB filling
  Srbds: Not affected
  Tsx async abort:   Not affected
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> Hi Guillaume,
>
> I gave it a go and your suggestion indeed cuts it for cleavir and
> cl-gamepad.
>
> It did not fix it for the tests though.
>
> I did some more testing, and this is what I found out on one of the
> failing systems (cl-reexport): from a --pure sbcl repl, if I load the
> .asd files manually then run test-system, I can reproduce the issue.
>
> However, if I run
>
>  (asdf:initialize-source-registry
> `(:source-registry (:tree ,(uiop:getcwd))
>:inherit-configuration))
>   (asdf:test-system :cl-reexport)
>
> then it works!
>
> In other words, I believe that `asdf:load-asd' is yet another under-used
> ASDF function, and we should probably go with the officially recommended
> way, namely adding the source folder to the ASDF registry.
>
> Thoughts?
>
> I'll try it out then send a patch.
>
> Cheers!

I think using the 'initialize-source-registry' technique instead of
'load-asd' would also make the '#:asd-files' and '#:test-asd-file'
arguments of the build system unnecessary, so they could be removed.

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> Do you have time to try it out?

Not right now, as I'm about to take a vacation.

The main change is a one-liner in the 'compile-systems' function in
"guix/build/lisp-utils.scm"; that would be quick.
However recompiling all the Lisp packages and finding which of them
could be simplified thanks to the change would take more time...

So, if you have the time, go for it.


signature.asc
Description: PGP signature

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> While trying to package
>
> https://github.com/s-expressionists/Cleavir
>
> I hit a strange issue in which it would fail to compile, while calling
> `asdf:load-system' locally worked.
>
> Then I realized that our asdf-build-system/sbcl uses
> `asdf:compile-system' instead of `asdf:load-system'.
>
> From the ASDF doc:
>
> This will make sure all the files in the system are compiled, but not
> necessarily load any of them in the current image; on most systems, it
> will _not_ load all compiled files in the current image.  This function
> exists for symmetry with 'load-system' but is not recommended unless you
> are writing build scripts and know what you're doing.
>
>
> So should we really use it?
>
> By the way this _may_ be related to the issue we've got with loading the
> tests of some packages, like sbcl-jonathan:
>
>   ;; Tests fail with: Component JONATHAN-ASD::JONATHAN-TEST not found,
>   ;; required by #. Why?
>
> [...]

Hi,

The cl-gamepad package has a similar issue (and a custom build phase
using load-system instead of compile-system as a workaround).

If the doc of ASDF indicates that load-system is the preferred way to
compile systems, we should probably do that, and remove current
workarounds and check if everything is still working.


signature.asc
Description: PGP signature

bug#54723: [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> So in commit c1719a0adf3fa7611b56ca4d75b3ac8cf5c9c8ac I went ahead and
>> reverted it that commit.  I also added a test that reproduces the issue
>> above.
>
> Commit 9eca13094d9bdf091f9096e0f3a8b450dac0e595 updates the ‘guix’
> package, so you can now pull, reconfigure, and enjoy.  :-)
>
> Ludo’.

I just tried and everything worked without a glitch.
Thanks.


signature.asc
Description: PGP signature

bug#54837: LLVM 3.* build failure

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Guillaume Le Vaillant  skribis:
>
>> However there are other issues during the build phase:
>>
>> ../../bin/llvm-tblgen: error while loading shared libraries: 
>> libLLVMTableGen.so: cannot open shared object file: No such file or directory
>> make[2]: *** 
>> [lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/build.make:105: 
>> lib/IR/AttributesCompatFunc.inc.tmp] Error 127
>> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
>> make[1]: *** [CMakeFiles/Makefile2:5233: 
>> lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/all] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> ../../bin/llvm-tblgen: error while loading shared libraries: 
>> libLLVMTableGen.so: cannot open shared object file: No such file or directory
>> make[2]: *** 
>> [lib/LibDriver/CMakeFiles/LibOptionsTableGen.dir/build.make:105: 
>> lib/LibDriver/Options.inc.tmp] Error 127
>> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
>> make[1]: *** [CMakeFiles/Makefile2:12101: 
>> lib/LibDriver/CMakeFiles/LibOptionsTableGen.dir/all] Error 2
>> ../../../bin/llvm-tblgen: error while loading shared libraries: 
>> libLLVMTableGen.so: cannot open shared object file: No such file or directory
>> make[2]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/build.make:123: 
>> include/llvm/IR/Attributes.inc.tmp] Error 127
>> make[2]: *** Waiting for unfinished jobs
>> ../../../bin/llvm-tblgen: error while loading shared libraries: 
>> libLLVMTableGen.so: cannot open shared object file: No such file or directory
>> make[2]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/build.make:165: 
>> include/llvm/IR/Intrinsics.gen.tmp] Error 127
>> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
>> make[1]: *** [CMakeFiles/Makefile2:5153: 
>> include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all] Error 2
>> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
>
> It looks like llvm-12 has a workaround for this issue. I'll copy it to
> llvm-3.9 and test that...

Partial fix pushed in 81567f751bd31d972cf05013a177311b73425d7d; the
builds for llvm-3.7 and llvm-3.8 are still failing.


signature.asc
Description: PGP signature

bug#54837: LLVM 3.* build failure

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> However there are other issues during the build phase:
>
> ../../bin/llvm-tblgen: error while loading shared libraries: 
> libLLVMTableGen.so: cannot open shared object file: No such file or directory
> make[2]: *** 
> [lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/build.make:105: 
> lib/IR/AttributesCompatFunc.inc.tmp] Error 127
> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
> make[1]: *** [CMakeFiles/Makefile2:5233: 
> lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> ../../bin/llvm-tblgen: error while loading shared libraries: 
> libLLVMTableGen.so: cannot open shared object file: No such file or directory
> make[2]: *** [lib/LibDriver/CMakeFiles/LibOptionsTableGen.dir/build.make:105: 
> lib/LibDriver/Options.inc.tmp] Error 127
> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
> make[1]: *** [CMakeFiles/Makefile2:12101: 
> lib/LibDriver/CMakeFiles/LibOptionsTableGen.dir/all] Error 2
> ../../../bin/llvm-tblgen: error while loading shared libraries: 
> libLLVMTableGen.so: cannot open shared object file: No such file or directory
> make[2]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/build.make:123: 
> include/llvm/IR/Attributes.inc.tmp] Error 127
> make[2]: *** Waiting for unfinished jobs
> ../../../bin/llvm-tblgen: error while loading shared libraries: 
> libLLVMTableGen.so: cannot open shared object file: No such file or directory
> make[2]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/build.make:165: 
> include/llvm/IR/Intrinsics.gen.tmp] Error 127
> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
> make[1]: *** [CMakeFiles/Makefile2:5153: 
> include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all] Error 2
> make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'

It looks like llvm-12 has a workaround for this issue. I'll copy it to
llvm-3.9 and test that...


signature.asc
Description: PGP signature

bug#54837: LLVM 3.* build failure

[Guillaume Le Vaillant]

Maxime Devos  skribis:

> Guillaume Le Vaillant schreef op zo 10-04-2022 om 14:23 [+]:
>> It looks like the problem comes from a gexp in the builder. There's
>> a gexp inside another gexp, but I don't know if that's the problem:
>> 
>> --8<---cut here---start->8---
>> #:phases (modify-phases #
> Suggestion:
>
> Replace
>
>  (substitute-keyword-arguments (package-arguments llvm)
>((#:phases phases)
> `(modify-phases ,phases
>(delete 'install-opt-viewer)))
>
> by
>
>  (substitute-keyword-arguments (package-arguments llvm)
>((#:phases phases)
> #~(modify-phases #$phases
> (delete 'install-opt-viewer)))
>
> in llvm-3.9.1.

Thanks, that solves the builder issue.

However there are other issues during the build phase:

--8<---cut here---start->8---
../../bin/llvm-tblgen: error while loading shared libraries: 
libLLVMTableGen.so: cannot open shared object file: No such file or directory
make[2]: *** [lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/build.make:105: 
lib/IR/AttributesCompatFunc.inc.tmp] Error 127
make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:5233: 
lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
../../bin/llvm-tblgen: error while loading shared libraries: 
libLLVMTableGen.so: cannot open shared object file: No such file or directory
make[2]: *** [lib/LibDriver/CMakeFiles/LibOptionsTableGen.dir/build.make:105: 
lib/LibDriver/Options.inc.tmp] Error 127
make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:12101: 
lib/LibDriver/CMakeFiles/LibOptionsTableGen.dir/all] Error 2
../../../bin/llvm-tblgen: error while loading shared libraries: 
libLLVMTableGen.so: cannot open shared object file: No such file or directory
make[2]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/build.make:123: 
include/llvm/IR/Attributes.inc.tmp] Error 127
make[2]: *** Waiting for unfinished jobs
../../../bin/llvm-tblgen: error while loading shared libraries: 
libLLVMTableGen.so: cannot open shared object file: No such file or directory
make[2]: *** [include/llvm/IR/CMakeFiles/intrinsics_gen.dir/build.make:165: 
include/llvm/IR/Intrinsics.gen.tmp] Error 127
make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:5153: 
include/llvm/IR/CMakeFiles/intrinsics_gen.dir/all] Error 2
make[2]: Leaving directory '/tmp/guix-build-llvm-3.9.1.drv-0/build'
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#54837: LLVM 3.* build failure

[Guillaume Le Vaillant]

The clamav package can't be built right know because it depends on
llvm-3.6 which fails to build. In fact, all the llvm-3.* packages fail
to build with the same error:

--8<---cut here---start->8---
The following derivation will be built:
  /gnu/store/7rh78xkkglsx289s9j6fdxwfwakqdhv8-llvm-3.6.2.drv
building /gnu/store/7rh78xkkglsx289s9j6fdxwfwakqdhv8-llvm-3.6.2.drv...
ice-9/read.scm:126:4: In procedure read-expr*:
/gnu/store/kj78hgwyb11z2sxz4xfd3v9sd93xk7yc-llvm-3.6.2-builder:1:3078: Unknown 
# object: "#<"
builder for `/gnu/store/7rh78xkkglsx289s9j6fdxwfwakqdhv8-llvm-3.6.2.drv' failed 
with exit code 1
build of /gnu/store/7rh78xkkglsx289s9j6fdxwfwakqdhv8-llvm-3.6.2.drv failed
View build log at 
'/var/log/guix/drvs/7r/h78xkkglsx289s9j6fdxwfwakqdhv8-llvm-3.6.2.drv.gz'.
guix build: error: build of 
`/gnu/store/7rh78xkkglsx289s9j6fdxwfwakqdhv8-llvm-3.6.2.drv' failed
--8<---cut here---end--->8---


It looks like the problem comes from a gexp in the builder. There's
a gexp inside another gexp, but I don't know if that's the problem:

--8<---cut here---start->8---
#:phases (modify-phases #8---

The full builder file is in attachment.


kj78hgwyb11z2sxz4xfd3v9sd93xk7yc-llvm-3.6.2-builder
Description: Binary data

bug#54280: stumpwm won't load libraries

[Guillaume Le Vaillant]

Einar Largenius  skribis:

> Hello!
>
> I have an issue where I can't get slynk to load inside stumpwm with Guix
> as the package manager. I have no issue loading slynk with either nyxt
> or when running a sbcl-repl even without modifying
> asdf:*central-registry*. These are the packages I have in my profile:
>
> glibc-locales 2.33out 
> /gnu/store/nrr24nvf6548if5wdpvxhlvjif3x9jjp-glibc-locales-2.33
> nyxt  2.2.4   out 
> /gnu/store/rf5aamdsdd039mhn4c3vsx5zgzzmnzdx-nyxt-2.2.4
> sbcl  2.2.2   out 
> /gnu/store/129g8pcc2ybs1p81ak28lj44i0wkyiqj-sbcl-2.2.2
> cl-slynk  1.0.43-5.0470c02out 
> /gnu/store/zc8h7xy78k6ybfq74k4wvx0yhg4pz6ln-cl-slynk-1.0.43-5.0470c02
> stumpwm   20.11   out 
> /gnu/store/y88ghx13yv9b6a2sa7b8hnxgcnw8x3ka-stumpwm-20.11
>
> If I just try to load slynk directly asdf doesn't seem to find it at
> all. If I try to add the *.asd files that Guix provides:
>
> (push (uiop:subpathname* (user-homedir-pathname) 
> ".guix-profile/share/common-lisp/systems/") asdf:*central-registry*)
>
> And then try to load, I still get an error:
>
> Don't know how to REQUIRE SB-CLTL2
>
> stumpwm itself works without issue.

Hi,

There's a stumpwm-with-slynk package that you could use instead of the
stumpwm package. I guess it should do what you want.

If not, you could also try installing the sbcl-slynk package (which
has the compiled files for sbcl) instead of the cl-slynk one (sources
only). I think the stumpwm binary can only compile code using the
libraries that were available when it was built, and I guess sb-cltl2
isn't one of them.


signature.asc
Description: PGP signature

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Guillaume Le Vaillant]

"bdju"  skribis:

> On Fri Mar 4, 2022 at 8:07 AM CST, Guillaume Le Vaillant wrote:
>> Hi,
>>
>> FreeCAD also has some issues with the rendering of its "start page"
>> where the text is missing.
>> And as Calibre and FreeCAD are apparently both Python applications using
>> QtWebEngine, it may indicate that there is something not working
>> correctly in QtWebEngine or in the Python bindings to QtWebEngine.
>
> qutebrowser and anki are also affected. There's an issue somewhere about
> it already.

Zhu Zihao found a workaround (see issue 54297): passing "--no-sandbox"
to Chromium.

So the text is rendered correctly when using:
--8<---cut here---start->8---
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" ebook-viewer
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" calibre
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" FreeCAD
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Guillaume Le Vaillant]

Hi,

FreeCAD also has some issues with the rendering of its "start page"
where the text is missing.
And as Calibre and FreeCAD are apparently both Python applications using
QtWebEngine, it may indicate that there is something not working
correctly in QtWebEngine or in the Python bindings to QtWebEngine.

I tried printing some debug traces with:
--8<---cut here---start->8---
QTWEBENGINE_CHROMIUM_FLAGS="--enable-logging -v=1" ebook-viewer
QTWEBENGINE_CHROMIUM_FLAGS="--enable-logging -v=1" FreeCAD
--8<---cut here---end--->8---

In both cases the same error message was printed several times:
--8<---cut here---start->8---
[7052:1:0304/150130.882217:ERROR:paint_controller.cc(646)] 
PaintController::FinishCycle() completed
--8<---cut here---end--->8---

But so far I don't know what it means, or even if it's related to the
rendering issue...


signature.asc
Description: PGP signature

bug#54011: FreeCAD: Unable to import STEP files

[Guillaume Le Vaillant]

Jacob Hrbek  skribis:

> That patch seems to have broken something in FreeCAD as i have issues with 
> fonts^ and keybinds:
>
> To reproduce:
> a) Run `guix shell freecad -- FreeCAD` and notice that the texts are missing 
> on the title page
> b) Open a new project
> 1. Part Design workbench
> *
> 2. Tasks and create a new body
> *
> 3. Create a sketch
> *
> 4. In a sketch environment use `R`-key and notice that it no longer works to 
> make a rectangle

On my machine, the start page was not displayed properly even before the
patch for STEP files, so it's probably a different issue with HTML rendering.

There are indeed no keyboard shortcuts by default for creating cercles,
rectangles, etc. in part design. But you can still configure them in
"Tools -> Customize -> Keyboard -> Sketcher".
Maybe these shortcuts are missing because the version we are currently
using is not an official release (because of compatibility issues with
boost, opencascade-occt and vtk) and there's a bug in it, or maybe
upstream decided not to set them by default anymore...


signature.asc
Description: PGP signature

bug#54011: FreeCAD: Unable to import STEP files

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> When decompressing the zip file and importing the STEP file:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/gnu/store/cwfgf3xb2vfqckxqv196jz8xpbigxkqj-python-shiboken-2-5.15.2/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
>  line 142, in _import
> return original_import(name, *args, **kwargs)
> : 
> /gnu/store/pd0pxvnr3qdgcz37p80v6q8p0wk9xyfh-freecad-0.19.3-0.09a05a9/lib/Import.so:
>  undefined symbol: 
> _ZN3tbb6detail2r122cancel_group_executionERNS0_2d118task_group_contextE
>
> I guess now we have to find where
> '_ZN3tbb6detail2r122cancel_group_executionERNS0_2d118task_group_contextE'
> is coming from.

It was coming from the fact that the freecad package had the tbb package
as dependency, but it also depends on opencascade-occt which depends on
tbb-2020.
Fix pushed as 27a91b2f57bd0bf7efab77eaeb4b920f162bf8c8.


signature.asc
Description: PGP signature

bug#54011: FreeCAD: Unable to import STEP files

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Jacob Hrbek  skribis:
>
>> [[PGP Signed Part:No public key for ADD37D14AB42FCA9 created at 
>> 2022-02-15T15:56:38+0100 using EDDSA]]
>> Importing zipped STEP file: 15:50:27 Traceback (most recent call last):
>>
>> [...]
>>
>> from PySide2.QtSvg import *
>>
>> File
>> "/gnu/store/aps2s0h5l3a9w30qrsygpc0prhrmp5ap-python-shiboken-2-5.15.2/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
>> line 142, in _import
>>
>> return original_import(name, *args, **kwargs)
>>
>> : No module named 'PySide2.QtSvg'
>>
>> [...]
>
> There is an issue with the python-pyside-2 package. It fails to activate
> support for the Qt components that are not in the qtbase package (like
> qtxmlpatterns, qtmultimedia, qtsvg, etc):
>
> ...

I pushed a fix for python-pyside-2, but importing the STEP file in
freecad still fails because of other errors.

When importing the zip file:

--8<---cut here---start->8---
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/gnu/store/pd0pxvnr3qdgcz37p80v6q8p0wk9xyfh-freecad-0.19.3-0.09a05a9/Mod/Arch/importSH3D.py",
 line 47, in open
read(filename)
  File 
"/gnu/store/pd0pxvnr3qdgcz37p80v6q8p0wk9xyfh-freecad-0.19.3-0.09a05a9/Mod/Arch/importSH3D.py",
 line 79, in read
homexml = z.read("Home.xml")
  File 
"/gnu/store/mhbnni58w5hvpr304jxc5kws1vrp2l1i-python-3.9.9/lib/python3.9/zipfile.py",
 line 1463, in read
with self.open(name, "r", pwd) as fp:
  File 
"/gnu/store/mhbnni58w5hvpr304jxc5kws1vrp2l1i-python-3.9.9/lib/python3.9/zipfile.py",
 line 1502, in open
zinfo = self.getinfo(name)
  File 
"/gnu/store/mhbnni58w5hvpr304jxc5kws1vrp2l1i-python-3.9.9/lib/python3.9/zipfile.py",
 line 1429, in getinfo
raise KeyError(
: "There is no item named 'Home.xml' in the archive"
--8<---cut here---end--->8---

When decompressing the zip file and importing the STEP file:

--8<---cut here---start->8---
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/gnu/store/cwfgf3xb2vfqckxqv196jz8xpbigxkqj-python-shiboken-2-5.15.2/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
 line 142, in _import
return original_import(name, *args, **kwargs)
: 
/gnu/store/pd0pxvnr3qdgcz37p80v6q8p0wk9xyfh-freecad-0.19.3-0.09a05a9/lib/Import.so:
 undefined symbol: 
_ZN3tbb6detail2r122cancel_group_executionERNS0_2d118task_group_contextE
--8<---cut here---end--->8---

I guess now we have to find where
'_ZN3tbb6detail2r122cancel_group_executionERNS0_2d118task_group_contextE'
is coming from.


signature.asc
Description: PGP signature

bug#54011: FreeCAD: Unable to import STEP files

[Guillaume Le Vaillant]

Jacob Hrbek  skribis:

> [[PGP Signed Part:No public key for ADD37D14AB42FCA9 created at 
> 2022-02-15T15:56:38+0100 using EDDSA]]
> Importing zipped STEP file: 15:50:27 Traceback (most recent call last):
>
> [...]
>
> from PySide2.QtSvg import *
>
> File
> "/gnu/store/aps2s0h5l3a9w30qrsygpc0prhrmp5ap-python-shiboken-2-5.15.2/lib/python3.9/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
> line 142, in _import
>
> return original_import(name, *args, **kwargs)
>
> : No module named 'PySide2.QtSvg'
>
> [...]

There is an issue with the python-pyside-2 package. It fails to activate
support for the Qt components that are not in the qtbase package (like
qtxmlpatterns, qtmultimedia, qtsvg, etc):

--8<---cut here---start->8---
...
-- essential module Qt5Core found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Core
-- essential module Qt5Gui found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Gui
-- essential module Qt5Widgets found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Widgets
-- essential module Qt5PrintSupport found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5PrintSupport
-- essential module Qt5Sql found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Sql
-- essential module Qt5Network found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Network
-- essential module Qt5Test found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Test
-- essential module Qt5Concurrent found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Concurrent
-- skipped module Qt5X11Extras is essential!
   We do not guarantee that all tests are working.. Looked in: 
/gnu/store/3nr3fwrk6bpwrg3s68lrpcj024mpqjvq-qtx11extras-5.15.2/lib/cmake/Qt5X11Extras
-- optional module Qt5Xml found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Xml
-- optional module Qt5XmlPatterns skipped. Looked in: 
/gnu/store/f96i1vssl11vk483570ki90g56mhpiz1-qtxmlpatterns-5.15.2/lib/cmake/Qt5XmlPatterns
-- optional module Qt5Help skipped. Looked in: 
/gnu/store/3cpa4lv4gx2nkiyvg4xkcalvvjv6y1vq-qttools-5.15.2/lib/cmake/Qt5Help
-- optional module Qt5Multimedia skipped. Looked in: 
/gnu/store/dk284553z4sgpd0jivggham4i70z1b65-qtmultimedia-5.15.2/lib/cmake/Qt5Multimedia
-- optional module Qt5MultimediaWidgets skipped. Looked in: 
/gnu/store/dk284553z4sgpd0jivggham4i70z1b65-qtmultimedia-5.15.2/lib/cmake/Qt5MultimediaWidgets
-- optional module Qt5OpenGL found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5OpenGL
-- optional module Qt5OpenGLFunctions found (). Looked in: 
/gnu/store/v8yw01fvwdm95jvqa82sylw6qznmh2mi-qtbase-5.15.2/lib/cmake/Qt5Gui
-- optional module Qt5Positioning skipped. Looked in: 
/gnu/store/9f37skxk4yjfqfhv96a74q1yjk3mflbj-qtlocation-5.15.2/lib/cmake/Qt5Positioning
-- optional module Qt5Location skipped. Looked in: 
/gnu/store/9f37skxk4yjfqfhv96a74q1yjk3mflbj-qtlocation-5.15.2/lib/cmake/Qt5Location
-- optional module Qt5Qml skipped. Looked in: 
/gnu/store/19bs1fiffjv2p9m0l7qvf7myv5k8yi1g-qtdeclarative-5.15.2/lib/cmake/Qt5Qml
-- optional module Qt5Quick skipped. Looked in: 
/gnu/store/19bs1fiffjv2p9m0l7qvf7myv5k8yi1g-qtdeclarative-5.15.2/lib/cmake/Qt5Quick
...
--8<---cut here---end--->8---

If we can get python-pyside-2 to detect Qt modules and their headers
correctly, it should fix FreeCAD automatically.


signature.asc
Description: PGP signature

bug#53694: Librecad fails to build

[Guillaume Le Vaillant]

Ekaitz Zarraga  skribis:

> Hi,
>
> After a `guix pull` librecad fails to build. I attach the log.
> It looks related with `boost` but I have no time to research further right 
> now.
>
> Best,
> Ekaitz

Fixed in 787b13a5d9df8f0cc7170de1b80cead68b516c66.


signature.asc
Description: PGP signature

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Guillaume Le Vaillant]

Simon Streit  skribis:

> Hello,
>
> quite often, and quite randomly I run into this situation that whenever
> Guix tries to rebuild a profile, and sometimes while downloading from
> local Guix hosts sharing their store items, the process will crash with
> the following error:
>
> ~ $1 reconfigure
> substitute: updating substitutes from 'http://192.168.0.157:3000'...  
> 56.3%Backtrace:
> substitute: In ice-9/boot-9.scm:
> substitute:   1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
> substitute: In unknown file:
> substitute:   16 (apply-smob/0 #)
> substitute: In ice-9/boot-9.scm:
> substitute: 724:2 15 (call-with-prompt _ _ # default-prompt-handle…>)
> substitute: In ice-9/eval.scm:
> substitute: 619:8 14 (_ #(#(#)))
> substitute: In guix/ui.scm:
> substitute:2206:7 13 (run-guix . _)
> substitute:   2169:10 12 (run-guix-command _ . _)
> substitute: In ice-9/boot-9.scm:
> substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
> substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
> substitute: In guix/scripts/substitute.scm:
> substitute:757:18  9 (_)
> substitute:348:26  8 (process-query # _ #:cache-urls _ 
> #:acl _)
> substitute: In guix/substitutes.scm:
> substitute:365:27  7 (lookup-narinfos/diverse _ _ # 7f309690d320 …> …)
> substitute:322:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
> substitute:245:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
> substitute: In ice-9/boot-9.scm:
> substitute:   1685:16  4 (raise-exception _ #:continuable? _)
> substitute:   1685:16  3 (raise-exception _ #:continuable? _)
> substitute:   1780:13  2 (_ #< components: 
> (#<…>)
> substitute:   1685:16  1 (raise-exception _ #:continuable? _)
> substitute:   1685:16  0 (raise-exception _ #:continuable? _)
> substitute:
> substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> substitute: Wrong type (expecting exact integer): #f
> guix system: error: 
> `/gnu/store/kcc8zh1fhp05wgw2m48w3gk228j39f5q-guix-1.3.0-21.e427593/bin/guix 
> substitute' died unexpectedly
>
>
> Unfortunately this crash happens at random.  Other times it goes
> through.  Current checkout is ff14bc60e56fb0c6636da1da9a850b7b04abb367,
> which isn't the most current, I know.  I've been observing this behavior
> since some time now, and haven't figured out what the reason is behind
> it yet.  The error message looks similar to [1].
>
> The way this error appears is, that I usually have one host that I
> upgrade first, and then share the checkout and the store between hosts
> to speed up the upgrading process locally.  Unfortunately the updater
> will crash randomly whenever the host starts scanning other hosts that
> are found through mDNS.  Sometimes this happens while fetching new
> packages into a profile.
>
> I've set up publishing:
>
> (service guix-publish-service-type
>   (guix-publish-configuration (host "0.0.0.0")
>   (port 3000)
>   (ttl #f)
>   (advertise? #t)))
>
> and of course host discovery in guix-service-type too.
>
>
> Kind regards
> Simon
>
>
> [1] https://issues.guix.gnu.org/52464

Hi,

I have also seen this kind of crashes on my LAN.
I don't know what causes this issue, but I noticed that it has happened
less often since I activated the cache for the guix-publish service.


signature.asc
Description: PGP signature

bug#53658: guix shell cache not working properly

[Guillaume Le Vaillant]

Hi,

With Guix at e217174b7b9046658ac3474d522bde192e9cffb4I have an issue
with the "guix shell -p ..." command, where I end up in a environment
for a profile I used previously instead of the profile specified in the
command line.

I can reproduce the issue this way:

--8<---cut here---start->8---
# Clear the profile cache
rm ${HOME}/.cache/guix/profiles/*

# Make some profiles
mkdir a
echo "(specifications->manifest '(\"gforth\"))" > a/manifest.scm
guix package -m a/manifest.scm -p a/profile
mkdir b
echo "(specifications->manifest '(\"smalltalk\"))" > b/manifest.scm
guix package -m b/manifest.scm -p b/profile

# The first attempt at using a profile when the cache is empty fails
guix shell -q -p a/profile -- gforth
> Backtrace:
>   10 (primitive-load "/home/guillaume/.config/guix/current/b…")
> In guix/ui.scm:
>2209:7  9 (run-guix . _)
>   2172:10  8 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/status.scm:
> 802:4  6 (call-with-status-report _ _)
> In guix/scripts/environment.scm:
>951:12  5 (_)
> In guix/store.scm:
>   2123:24  4 (run-with-store #f # …)
> In guix/scripts/environment.scm:
>968:16  3 (_ _)
> In guix/store.scm:
>   1995:38  2 (_ #f)
>1473:0  1 (add-indirect-root #f "/home/guillaume/.cache/guix/prof…")
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1 (expecting 
> struct): #f

# Then using the first profile with the same command works
guix shell -q -p a/profile -- gforth
> Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
bye

# Using the second profile doesn't work
guix shell -q -p b/profile -- gst
> guix shell: erreur : gst : commande introuvable
> conseil : Vouliez-vous dire « gforth » ?

# But the second profile really has the gst program
ls b/profile/bin
> gst  gst-blox  gst-browser  gst-config  gst-convert  [...]

# In fact, using the second profile creates an environment for
# the first profile
guix shell -q -p b/profile -- gforth
> Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
bye

# And the profile cache only contains a link for the first profile instead
# of links for both profiles
ls ${HOME}/.cache/guix/profiles/
> hw7txclxu45xzbt4orha5d6zrgjej5ps4ve5n6je3cnblbg7fz2a
> last-expiry-cleanup

ls hw7txclxu45xzbt4orha5d6zrgjej5ps4ve5n6je3cnblbg7fz2a/bin
> gforth  gforth-0.7.3  gforth-fast  gforth-fast-0.7.3  [...]
--8<---cut here---end--->8---

bug#53289: [PATCH] gnu: Remove Qt WebKit.

[Guillaume Le Vaillant]

Leo Famulari  skribis:

> New failures:
> [...]
> freecad

For freecad, the qtwebkit input can be replaced by qtdeclarative,
qtwebchannel and qtwebengine.


signature.asc
Description: PGP signature

bug#53289: [PATCH] gnu: Remove Qt WebKit.

[Guillaume Le Vaillant]

Leo Famulari  skribis:

> I applied the patch and tried building all packages that are changed by
> the it.
>
> New failures:
> qgis
> [...]

For qgis, adding "-DWITH_QTWEBKIT=NO" to 'configure-flags' should work,
but I don't know what features would then be unavailable in the
application.


signature.asc
Description: PGP signature

bug#53180: eog 40.3 build error: include file not found

[Guillaume Le Vaillant]

raid5atemyhomework  skribis:

>> > > Eog and Epiphany should be fixed with Guix at
>> > > f7afefba00b65e94d073af3af2278a076c89dbc1 or later.
>> >
>> > Ha, it seems I'm late to the party. Thanks Guillaume! Will check.
>>
>> Unfortunately it seems to still be broken for me?
>
> It works with `guix build eog`, but *not* with `guix system build 
> configuration.scm` on my configuration.  Strange.
>
> I already tried a `guix gc` just in case of non-determinism but still the 
> same --- `guix build eog` works, `guix system build configuration.scm` does 
> not.
>
>
> Lemme try to trim down a small OS configuration that triggers this.
>
> Thanks
> raid5atemyhomework

Your "guix reconfigure" is failing because there are still some
dependencies of the gnome package that need to be fixed to work with the
newer libportal.
According to [1], at least gnome-todo, gnome-builder, nautilus and
gcolor3 have to be fixed.

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


signature.asc
Description: PGP signature

bug#53180: libportal missing GTK3 backend

[Guillaume Le Vaillant]

Liliana Marie Prikler  skribis:

> Hi Guix,
>
> this bug also affects Epiphany (build log attached).  The issue appears
> to be that it tries to build without the GTK3 backend, we should
> probably enable that.
>
> Cheers
>
> [2. application/x-bzip; 
> dac0xa4q6lxcp63jz3fm7phnxsn5hv-epiphany-40.3.drv.bz2]...

Eog and Epiphany should be fixed with Guix at
f7afefba00b65e94d073af3af2278a076c89dbc1 or later.

There is also gcolor3 (and maybe others) that fails in the same way
(I've not tried to fix it/them yet).


signature.asc
Description: PGP signature

bug#52913: 0ad only builds fine with a specific version of mozjs

[Guillaume Le Vaillant]

Liliana Marie Prikler  skribis:

> @Guillaume: From what I can gather from the build error, it appears as
> though the calling convention changed to require an additional
> parameter.  I've tracked down the relevant commit [1] and bug [2].
>
> Now obviously doing such a thing violates SemVer, so if rewriting 0ad
> with this and other changes in mind is not an option, I think having a
> hidden package for 0ad might be the lesser evil.
>
> Cheers
>
> [1]
> https://searchfox.org/mozilla-central/commit/a3c605929b16303e8a52ae9d99d5fe6769e8bf09
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1681268

Thanks for the pointers.
I added a phase to fix the compatibility issue with mozjs-78.15, and
pushed as fea60a2fff443b9c172ed28bd37361e34e064f13.


signature.asc
Description: PGP signature

bug#52652: FreeCAD requires write access to store for parsetab.py

[Guillaume Le Vaillant]

Jacob Hrbek  skribis:

> I started building it after the patch was merged, it finished now and
> the presented issue is no longer present.

Ok, thanks for confirming.
Closing.


signature.asc
Description: PGP signature

bug#52652: FreeCAD requires write access to store for parsetab.py

[Guillaume Le Vaillant]

Hi,

With Guix at b7078d5d49d72cb5e5356d698b99540612b4d6c4, I tried to
reproduce the issue, but I didn't get any error.

I started FreeCAD with:

--8<---cut here---start->8---
guix shell freecad openscad -- FreeCAD
--8<---cut here---end--->8---

Then I selected "OpenSCAD" in the box, then the "OpenSCAD -> Add
OpenSCAD Element" menu item, then I typed "cube();", clicked "Add", and
it created a cube without any error message (I tried with the "mesh" box
ticked and unticked).

Can you still reproduce the issue on your side?


signature.asc
Description: PGP signature

bug#52606: FreeCAD - Missing dependency python-ply

[Guillaume Le Vaillant]

Fixed in b7078d5d49d72cb5e5356d698b99540612b4d6c4.
Closing.


signature.asc
Description: PGP signature

bug#52853: Error when trying to upgrade packages

[Guillaume Le Vaillant]

Closing.
I opened bug#52913 for the failing 0ad package.


signature.asc
Description: PGP signature

bug#52913: 0ad only builds fine with a specific version of mozjs

[Guillaume Le Vaillant]

The 0ad package checks the version of mozjs and throws an error if it is
not exactly the version it expects. This check is done in
"source/scriptinterface/ScriptTypes.h" and it currently requires version
78.6 of mozjs. As Guix has mozjs 78.15 instead, 0ad fails to build.

Patching "ScriptTypes.h" to remove the check and compile with mozjs 78.15
doesn't work, the build phase fails with:

--8<---cut here---start->8---
../../../source/scriptinterface/ScriptContext.cpp: In member function ‘void 
ScriptContext::UnRegisterRealm(JS::Realm*)’:
../../../source/scriptinterface/ScriptContext.cpp:146:39: error: cannot convert 
‘JS::Zone*’ to ‘JSContext*’
  146 |  JS::PrepareZoneForGC(js::GetRealmZone(realm));
  |   ^~~
  |   |
  |   JS::Zone*
In file included from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/Value.h:25,
 from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/CallArgs.h:74,
 from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/jsapi.h:31,
 from ../../../source/scriptinterface/ScriptTypes.h:63,
 from ../../../source/scriptinterface/ScriptContext.h:21,
 from ../../../source/scriptinterface/ScriptContext.cpp:20:
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/GCAPI.h:539:55:
 note:   initializing argument 1 of ‘void JS::PrepareZoneForGC(JSContext*, 
JS::Zone*)’
  539 | extern JS_PUBLIC_API void PrepareZoneForGC(JSContext* cx, Zone* zone);
  |~~~^~
In file included from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/TraceKind.h:12,
 from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/jspubtd.h:18,
 from ../../../source/scriptinterface/ScriptTypes.h:62,
 from ../../../source/scriptinterface/ScriptContext.h:21,
 from ../../../source/scriptinterface/ScriptContext.cpp:20:
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/TypeDecls.h:55:21:
 note: class type ‘JS::Zone’ is incomplete
   55 | class JS_PUBLIC_API Zone;
  | ^~~~
../../../source/scriptinterface/ScriptContext.cpp: In member function ‘void 
ScriptContext::PrepareZonesForIncrementalGC() const’:
../../../source/scriptinterface/ScriptContext.cpp:264:40: error: cannot convert 
‘JS::Zone*’ to ‘JSContext*’
  264 |   JS::PrepareZoneForGC(js::GetRealmZone(realm));
  |^~~
  ||
  |JS::Zone*
In file included from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/Value.h:25,
 from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/CallArgs.h:74,
 from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/jsapi.h:31,
 from ../../../source/scriptinterface/ScriptTypes.h:63,
 from ../../../source/scriptinterface/ScriptContext.h:21,
 from ../../../source/scriptinterface/ScriptContext.cpp:20:
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/GCAPI.h:539:55:
 note:   initializing argument 1 of ‘void JS::PrepareZoneForGC(JSContext*, 
JS::Zone*)’
  539 | extern JS_PUBLIC_API void PrepareZoneForGC(JSContext* cx, Zone* zone);
  |~~~^~
In file included from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/TraceKind.h:12,
 from 
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/jspubtd.h:18,
 from ../../../source/scriptinterface/ScriptTypes.h:62,
 from ../../../source/scriptinterface/ScriptContext.h:21,
 from ../../../source/scriptinterface/ScriptContext.cpp:20:
/gnu/store/gzsa3jrlhgcr3mr6i170lhgfsxsmpcps-mozjs-78.15.0/include/mozjs-78/js/TypeDecls.h:55:21:
 note: class type ‘JS::Zone’ is incomplete
   55 | class JS_PUBLIC_API Zone;
  | ^~~~
make[1]: *** [scriptinterface.make:146: 
obj/scriptinterface_Release/ScriptContext.o] Error 1
--8<---cut here---end--->8---

What would be the best way to fix this?
 - keep a mozjs-78.6 package around just for 0ad
 - patch 0ad to fix the compatibility issues with mozjs 78.15
 - use the mozjs version bundled in the 0ad sources

WDYT?


signature.asc
Description: PGP signature

bug#52653: prusa-slicer fails build at configure

[Guillaume Le Vaillant]

Fixed by updating prusa-slicer to version 2.4.0 in commit
e0ef09a86c108805ae294fc0ce8d638e420f206d.


signature.asc
Description: PGP signature

bug#52076: [core-updates-frozen] eigen-for-tensorflow fails to build

[Guillaume Le Vaillant]

Fixed on master branch (after core-updates-frozen merge).
Closing.


signature.asc
Description: PGP signature

bug#52140: [core-updates-frozen] tcc fails to build

[Guillaume Le Vaillant]

The 'check' phase fails with:

--8<---cut here---start->8---
 test3 
../tcc -B.. -I../include -I.. -I.. 
-DCONFIG_TCC_SYSINCLUDEPATHS="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/include:/gnu/store/99a2njzz22dkzd8pz75fsi5nbgv9ww0x-linux-libre-headers-5.10.35/include:{B}/include\""
 
-DCONFIG_TCC_LIBPATHS="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib\""
 
-DCONFIG_TCC_CRTPREFIX="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib\""
 
-DCONFIG_TCC_ELFINTERP="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/ld-linux-x86-64.so.2\""
 -DTCC_TARGET_X86_64 -run ../tcc.c -B.. -I../include -I.. -I.. 
-DCONFIG_TCC_SYSINCLUDEPATHS="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/include:/gnu/store/99a2njzz22dkzd8pz75fsi5nbgv9ww0x-linux-libre-headers-5.10.35/include:{B}/include\""
 
-DCONFIG_TCC_LIBPATHS="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib\""
 
-DCONFIG_TCC_CRTPREFIX="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib\""
 
-DCONFIG_TCC_ELFINTERP="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/ld-linux-x86-64.so.2\""
 -DTCC_TARGET_X86_64 -run ../tcc.c -B.. -I../include -I.. -I.. 
-DCONFIG_TCC_SYSINCLUDEPATHS="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/include:/gnu/store/99a2njzz22dkzd8pz75fsi5nbgv9ww0x-linux-libre-headers-5.10.35/include:{B}/include\""
 
-DCONFIG_TCC_LIBPATHS="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib\""
 
-DCONFIG_TCC_CRTPREFIX="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib\""
 
-DCONFIG_TCC_ELFINTERP="\"/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/ld-linux-x86-64.so.2\""
 -DTCC_TARGET_X86_64 -run ../tcc.c -B.. -I../include -I.. -I.. -run tcctest.c > 
test.out3
make[1]: *** [Makefile:103: test3] Error 139
make[1]: Leaving directory '/tmp/guix-build-tcc-0.9.27.drv-0/tcc-0.9.27/tests'
make: *** [Makefile:347: test] Error 2
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#52135: surf fails to build on core-updates-frozen

[Guillaume Le Vaillant]

Fixed in 4967eb97b5f2067e8ea512ad6e87743292859c3c.


signature.asc
Description: PGP signature

bug#52076: [core-updates-frozen] eigen-for-tensorflow fails to build

[Guillaume Le Vaillant]

On the core-updates-frozen branch at d5de4e163ccef80f78bc5fe330f568d8fe3a23ab,
compilation of eigen-for-tensorflow fails with the following error:

--8<---cut here---start->8---
[ 56%] Building CXX object 
test/CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o
cd /tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/build/test 
&& /gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/bin/c++  
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/build/test 
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test 
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source 
-I/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/build 
-pedantic -Wall -Wextra -Wundef -Wcast-align -Wchar-subscripts 
-Wnon-virtual-dtor -Wunused-local-typedefs -Wpointer-arith -Wwrite-strings 
-Wformat-security -Wlogical-op -Wdouble-promotion -Wshadow -Wno-psabi 
-Wno-variadic-macros -Wno-long-long -fno-check-new -fno-common 
-fstrict-aliasing -ansi -O3 -DNDEBUG  -DEIGEN_TEST_MAX_SIZE=320 
-DEIGEN_TEST_FUNC=stddeque_overload  -DEIGEN_TEST_PART_4=1 -MD -MT 
test/CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o -MF 
CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o.d -o 
CMakeFiles/stddeque_overload_4.dir/stddeque_overload.cpp.o -c 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp
In file included from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/Eigen/StdDeque:23,
 from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:13:
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/Eigen/src/StlSupport/StdDeque.h:
 In instantiation of ‘void std::deque 
>::resize(std::deque >::size_type, const 
value_type&) [with T = Eigen::Transform; std::deque >::size_type = long unsigned int; std::deque >::value_type = Eigen::Transform]’:
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:81:11:
   required from ‘void check_stddeque_transform(const TransformType&) [with 
TransformType = Eigen::Transform]’
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:152:3:
   required from here
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/Eigen/src/StlSupport/StdDeque.h:106:41:
 error: ‘std::_Deque_base, 
Eigen::aligned_allocator_indirection > 
>::_Deque_impl std::_Deque_base, 
Eigen::aligned_allocator_indirection > 
>::_M_impl’ is protected within this context
  106 |   deque_base::_M_erase_at_end(this->_M_impl._M_start + new_size);
  |   ~~^~~
In file included from 
/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/include/c++/deque:67,
 from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/main.h:42,
 from 
/tmp/guix-build-eigen-for-tensorflow-3.3.5-1.fd6845384b86.drv-0/source/test/stddeque_overload.cpp:11:
/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/include/c++/bits/stl_deque.h:589:19:
 note: declared protected here
  589 |   _Deque_impl _M_impl;
  |   ^~~
--8<---cut here---end--->8---

bug#51900: [core-updates-frozen] xorg-server-xwayland broken

[Guillaume Le Vaillant]

Closing.


signature.asc
Description: PGP signature

bug#51900: [core-updates-frozen] xorg-server-xwayland broken

[Guillaume Le Vaillant]

Maxim Cournoyer  skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant  writes:
>
>> According to [1], since 21.1 series of Xorg, XWayland is packaged
>> separately. The attached patch replaces xorg-xserver-xwayland by the
>> xwayland package.
>>
>> However it looks like it's not working so far, the tests fail with:
>>
>> XKB: Failed to compile keymap
>> Keyboard initialization failed. This could be a missing or incorrect setup 
>> of xkeyboard-config.
>> (EE) 
>> Fatal server error:
>> (EE) Failed to activate virtual core keyboard: 2(EE)
>>
>> I tried adding the same keyboard-related parameters as the ones in
>> xorg-server (xbk_dir and xkb_bin_dir), but it doesn't seem to
>> make a difference.
>>
>> Does someone have an idea?
>>
>>
>> [1] https://lists.x.org/archives/xorg/2021-October/060799.html
>
> Perhaps it was libinput?  I'm carrying this patch set locally, I guess I
> should have shared it earlier, I was attempting to fix the Mutter test
> suite on top of it.  Could you try it?  It rebuilds lots of stuff though
> I'm afraid.
>
> Thanks,
>
> (the patch series will come shortly via git-send)

It looks like your patches are working. I was able to build
xorg-server-xwayland (maybe it could be renamed xwayland), and also
weston (which has a test using xwayland).


signature.asc
Description: PGP signature

bug#51900: [core-updates-frozen] xorg-server-xwayland broken

[Guillaume Le Vaillant]

According to [1], since 21.1 series of Xorg, XWayland is packaged
separately. The attached patch replaces xorg-xserver-xwayland by the
xwayland package.

However it looks like it's not working so far, the tests fail with:
--8<---cut here---start->8---
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of 
xkeyboard-config.
(EE) 
Fatal server error:
(EE) Failed to activate virtual core keyboard: 2(EE)
--8<---cut here---end--->8---

I tried adding the same keyboard-related parameters as the ones in
xorg-server (xbk_dir and xkb_bin_dir), but it doesn't seem to
make a difference.

Does someone have an idea?


[1] https://lists.x.org/archives/xorg/2021-October/060799.html
From 457921b36c49c68e58ac067ede50637ce71a200c Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant 
Date: Wed, 17 Nov 2021 15:20:34 +0100
Subject: [PATCH] WIP: gnu: Replace xorg-server-xwayland by xwayland.

* gnu/packages/xorg.scm (xorg-server-xwayland): Remove varable.
  (xwayland): New variable.
* gnu/packages/enlightenment.scm (enlightenment)[inputs]: Replace
  xorg-server-xwayland by xwayland.
* gnu/packages/freedesktop.scm (weston)[inputs, arguments]: Idem.
* gnu/packages/gnome.scm (mutter)[inputs, arguments]: Idem.
* gnu/packages/wm.scm (wlroots)[inputs, arguments]: Idem.
---
 gnu/packages/enlightenment.scm |  2 +-
 gnu/packages/freedesktop.scm   |  4 +--
 gnu/packages/gnome.scm |  4 +--
 gnu/packages/wm.scm|  5 ++-
 gnu/packages/xorg.scm  | 63 +++---
 5 files changed, 57 insertions(+), 21 deletions(-)

diff --git a/gnu/packages/enlightenment.scm b/gnu/packages/enlightenment.scm
index 8c7da4a5b4..9b3fcfabaa 100644
--- a/gnu/packages/enlightenment.scm
+++ b/gnu/packages/enlightenment.scm
@@ -369,7 +369,7 @@ (define-public enlightenment
("setxkbmap" ,setxkbmap)
("xcb-util-keysyms" ,xcb-util-keysyms)
("xkeyboard-config" ,xkeyboard-config)
-   ("xorg-server-xwayland" ,xorg-server-xwayland)))
+   ("xwayland" ,xwayland)))
 (propagated-inputs
  `(("efl" ,efl)
("libxkbcommon" ,libxkbcommon)
diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index 003da5c7a5..7511b2014c 100644
--- a/gnu/packages/freedesktop.scm
+++ b/gnu/packages/freedesktop.scm
@@ -1147,7 +1147,7 @@ (define-public weston
("pango" ,pango)
("pipewire" ,pipewire)
("wayland-protocols" ,wayland-protocols)
-   ("xorg-server-xwayland" ,xorg-server-xwayland)))
+   ("xwayland" ,xwayland)))
 (propagated-inputs
  `(("libxkbcommon" ,libxkbcommon)
("pixman" ,pixman)
@@ -1164,7 +1164,7 @@ (define-public weston
 "-Dbackend-default=auto"
 "-Dsystemd=false"
 (string-append "-Dxwayland-path="
-   (assoc-ref %build-inputs "xorg-server-xwayland")
+   (assoc-ref %build-inputs "xwayland")
"/bin/Xwayland"))
#:parallel-tests? #f   ; Parallel tests cause failures.
#:phases
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 39ab43c90c..73af9eddd9 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -7507,7 +7507,7 @@ (define-public mutter
 
  ;; The following flags are needed for the bundled clutter
  (string-append "-Dxwayland_path="
-(assoc-ref %build-inputs "xorg-server-xwayland")
+(assoc-ref %build-inputs "xwayland")
 "/bin/Xwayland")
 
  ;; the remaining flags are needed for the bundled cogl
@@ -7572,7 +7572,7 @@ (define-public mutter
("startup-notification" ,startup-notification)
("upower-glib" ,upower)
("xkeyboard-config" ,xkeyboard-config)
-   ("xorg-server-xwayland" ,xorg-server-xwayland)
+   ("xwayland" ,xwayland)
("zenity" ,zenity)))
 (synopsis "Window and compositing manager")
 (home-page "https://www.gnome.org;)
diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index e19a08da47..b746d68485 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -1486,8 +1486,7 @@ (define-public wlroots
  (add-before 'configure 'hardcode-paths
(lambda* (#:key inputs #:allow-other-keys)
  (substitute* "xwayland/server.c"
-   (("Xwayland") (string-append (assoc-ref inputs
-   "xorg-server-xwayland")
+   (("Xwayland") (string-

bug#51900: [core-updates-frozen] xorg-server-xwayland broken

[Guillaume Le Vaillant]

The xorg-server-xwayland-21.1.0 package is broken on the
core-updates-frozen branch. The build succeeds, but the file
"bin/Xwayland" is missing in the result. Then the mutter package
depending on xorg-server-xwayland fails to build because it can't find
the Xwayland program.

According to the configure phase, xorg-server 21.1.0 doesn't understand
the "--enable-xwayland" option:

--8<---cut here---start->8---
config.status: executing sdksyms commands
configure: WARNING: unrecognized options: --enable-xwayland, --with-os-name, 
--with-os-vendor
phase `configure' succeeded after 6.6 seconds
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#51879: [PATCH] On core-updates-frozen, deja-dup does not build

[Guillaume Le Vaillant]

Patch pushed as d05781c4bb6a1f058e7dbaaa40ebe327886bad2c.
Thanks.


signature.asc
Description: PGP signature

bug#51873: [PATCH] Fix gnome-calendar on core-updates-frozen

[Guillaume Le Vaillant]

Patch pushed as fe2575f9a96da2d81be10ac2e976b03a30e070ce.
Thanks.


signature.asc
Description: PGP signature

bug#51872: [PATCH] On core-updates-frozen, gnome-mines requires the old meson too

[Guillaume Le Vaillant]

Patch pushed as 26e894414a792fcd70039fbddfd0e4ce94501965.
Thanks.


signature.asc
Description: PGP signature

bug#51871: [PATCH] Gnome 2048 does not build on core-updates-frozen

[Guillaume Le Vaillant]

Patch pushed as 74432fb7bacc93f8cf93dee4409147d61daacd86.
Thanks.


signature.asc
Description: PGP signature

bug#51806: [PATCH] Fix dconf-editor

[Guillaume Le Vaillant]

Closing.

bug#50897: Octave package installation

[Guillaume Le Vaillant]

Zacchaeus Scheffer  skribis:

> Hi Guix!
>
> After installing octave, I tried to install the image package in octave in
> two ways.  One by running:
>> pkg install image-.tar.gz
> where image-.tar.gz is in my cwd.  I also tried installing with:
>> pkg install -forge image
> In both cases, I had the same problem.  The first error I was getting was:
>>configure: error: in `/tmp/oct-6RV451/image-2.12.0/src':
>>configure: error: C++ compiler cannot create executables
>
> This error can be fixed by installing gcc-toolchain.  After doing so,
> attempting to install image gives:
>>ld: cannot find -loctinterp
>>ld: cannot find -loctave
> repeatedly (full output below).  These libraries seem like they should be
> included in the octave installation, and also like they should be absolute
> paths.  I looked for any instance of octinterp in filenames and found these
> in the octave install:
> ./include/octave-6.2.0/octave/liboctinterp-build-info.h
> ./lib/octave/6.2.0/liboctinterp.la
> ./lib/octave/6.2.0/liboctinterp.so.8.0.1
> ./lib/octave/6.2.0/liboctinterp.so
> ./lib/octave/6.2.0/liboctinterp.so.8
> ./lib/pkgconfig/octinterp.pc
> I tried installing image with these in my cwd, but no dice.  Even if these
> are the correct library files, octave is installing this in my user
> directory so the cwd won't be the same.
>
> I need this to work for a class, so I'm willing to put in some hours (days)
> to make this work, but I'm pretty lost if anyone has ideas on where to go
> next.
>
> Thanks,
> Zacchae

Hi,

I was able to build an octave package after specifying the location of
the required libraries using the LDFLAGS environment variable:

--8<---cut here---start->8---
export LDFLAGS=-L${GUIX_PROFILE}/lib/octave/6.2.0
octave
pkg install xyz.tar.gz
pkg load xyz
--8<---cut here---end--->8---

However, it would be better to have an octave-build-system making Guix
able to build, install and setup Octave packages (e.g. Octave Forge
packages).


signature.asc
Description: PGP signature

bug#50697: [core-updates-frozen] ca-certificate-bundle generation is broken.

[Guillaume Le Vaillant]

Mathieu Othacehe  skribis:

> Hello,
>
> On core-updates-frozen, the ca-certificate-bundle derivation produces an
> empty output. That's because nss-certs only contains .crt files that are
> ignored by ca-certificate-bundle procedure.
>
> The following patches should fix the situation.
>
> Thanks,
>
> Mathieu
>
> From 18248cc817952c690694707cc965283dad1933c2 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe 
> Date: Mon, 20 Sep 2021 10:26:30 +
> Subject: [PATCH 1/2] gnu: certdata2pem: Produce pem files.
>
> Create files with pem extension instead of crt.
>
> [...]

Hi,

With this patch I think the 'install-keystore' phase of icedtea-7 will
also have to be updated to search for the ".pem" files instead of the
".crt" ones.


signature.asc
Description: PGP signature

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> On ‘core-updates-frozen’, CMake has one test failure on i686-linux when
> building on berlin (e.g., ):
>
> --8<---cut here---start->8---
> 545/558 Test #518: RunCMake.CPack_TXZ 
> ***Failed3.79 sec
> [...]
> --8<---cut here---end--->8---
>
> I cannot reproduce it on hardware with 32 cores.  I suspect it has to do
> with the number of threads used for xz compression, which defaults to
> the number of cores, and some of the build machines on berlin have way
> more cores.
>
> Ludo’.

I tried a few times on a machine with 16 cores, and I can't reproduce
either. The build succeeded every time.


signature.asc
Description: PGP signature

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

[Guillaume Le Vaillant]

Sarah Morgensen  skribis:

> arcan-sdl@0.5.5.2-1.b4dd1fb
> aris@2.2
> blastem@0.6.2
> crispy-doom@5.8.0
> geeqie@1.5
> glabels@3.4.1
> gmtp@1.3.11

These are fixed in c9f7770eeec3a7b493dcbf45c96a4528f2635604 and
following.


signature.asc
Description: PGP signature

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