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

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

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

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

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

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

bug#65441: leptonica 1.83.1 ioformats_reg test failure

Fixed in df5653adcbd1f9799f810f46d514b2ca4112af97. Closing. signature.asc Description: PGP signature

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

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

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

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, >

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

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

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

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)

Tests for ecl-cl-pcg disabled in 9a4a480f8d51da8bf25b61a98e1092a6cd6f76ee. Closing. signature.asc Description: PGP signature

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

It looks like this build failure doesn't happen anymore now. Closing. signature.asc Description: PGP signature

bug#67042: ecl-seedable-rng recently broken

+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: I84ff141b7eefff470f72493d02f2cc

bug#66305: Error with recursive git checkout

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

odule 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]

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

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

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

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

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

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

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

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

Patch pushed as 930e6e3e7a1c5f83aedb49f6fa0ebb0e0bdeeef3. Thanks. signature.asc Description: PGP signature

bug#63430: python-pyside-2-5.15.8

"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

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

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

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

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

bug#59331: sbcl currently fails to build on aarch64

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

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

bug#59200: reproducibility

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

bug#59200: reproducibility

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

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

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

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

tcc currently builds successfully. Closing. signature.asc Description: PGP signature

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

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

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

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.

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

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:

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

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

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

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,

bug#56353: sbcl-2.2.6 build fail

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

bug#56353: sbcl-2.2.6 build fail

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

bug#56353: sbcl-2.2.6 build fail

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. >> >> >>

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

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

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

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

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

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'

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

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,

bug#54837: LLVM 3.* build failure

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 su

bug#54837: LLVM 3.* build failure

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]: *** >

bug#54837: LLVM 3.* build failure

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

bug#54837: LLVM 3.* build failure

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:

bug#54280: stumpwm won't load libraries

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

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

"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

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

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

bug#54011: FreeCAD: Unable to import STEP files

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 > * >

bug#54011: FreeCAD: Unable to import STEP files

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/

bug#54011: FreeCAD: Unable to import STEP files

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): >> >> [

bug#54011: FreeCAD: Unable to import STEP files

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 >

bug#53694: Librecad fails to build

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

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

bug#53658: guix shell cache not working properly

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

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

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.

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.

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

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

bug#53180: libportal missing GTK3 backend

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; >

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

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

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

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

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

bug#52606: FreeCAD - Missing dependency python-ply

Fixed in b7078d5d49d72cb5e5356d698b99540612b4d6c4. Closing. signature.asc Description: PGP signature

bug#52853: Error when trying to upgrade packages

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

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"

bug#52653: prusa-slicer fails build at configure

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

Fixed on master branch (after core-updates-frozen merge). Closing. signature.asc Description: PGP signature

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

The 'check' phase fails with: --8<---cut here---start->8--- test3 ../tcc -B.. -I../include -I.. -I..

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

Fixed in 4967eb97b5f2067e8ea512ad6e87743292859c3c. signature.asc Description: PGP signature

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

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

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

Closing. signature.asc Description: PGP signature

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

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. >> >> How

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

ayland" ,xorg-server-xwayland))) + ("xwayland" ,xwayland))) (native-inputs `(("pkg-config" ,pkg-config))) (home-page "https://github.com/swaywm/wlroots;) diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm index 574562f065..e387474990 100644 --- a

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

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

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

Patch pushed as d05781c4bb6a1f058e7dbaaa40ebe327886bad2c. Thanks. signature.asc Description: PGP signature

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

Patch pushed as fe2575f9a96da2d81be10ac2e976b03a30e070ce. Thanks. signature.asc Description: PGP signature

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

Patch pushed as 26e894414a792fcd70039fbddfd0e4ce94501965. Thanks. signature.asc Description: PGP signature

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

Patch pushed as 74432fb7bacc93f8cf93dee4409147d61daacd86. Thanks. signature.asc Description: PGP signature

bug#51806: [PATCH] Fix dconf-editor

Closing.

bug#50897: Octave package installation

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

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

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,

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

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 >

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

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.

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/49

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

ps/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,

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

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

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

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

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

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

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

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

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

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

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

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

bug#49307: clisp: build failure: failing tests

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

bug#49161: kicad-5.1.6 fails to build

Patches pushed as e22a711c97e0501b398467733164da4ee140036e and following. Thanks. signature.asc Description: PGP signature

bug#49161: kicad-5.1.6 fails to build

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

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

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

bug#48336: kicad cannot see libngspice

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

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

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

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

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

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

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

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

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

  1   2   >