bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi David, Thanks for the reply. Apr 11, 2024 04:50:03 David Elsing : Can we put everything inside build-inputs? From my understanding, copy-build-system shouldn't care about cross-compilation at all. I understand it that way too. In guix/build-system.scm, it is mentioned that build/host/target are used in the sense of the GNU toolchain [1]. There, "build" is the system used for building and "host" is the target system for which the package is built. I guess this was confused when copy-build-system was added [2]. Then I think I can submit a patch to guix-patches, hoping to bring more attention to this bug.
bug#70324: After upgrade of linux-libre, linux-libre-documentation fails to build
On Wed, Apr 10, 2024 at 05:05:15PM +0200, Tomas Volf wrote: > linux-libre-documentation is broken again: > > starting phase `build' > Traceback (most recent call last): > File > "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", > line 26, in > import yaml > ModuleNotFoundError: No module named 'yaml' It looks like the package depends on pyyaml now. I wonder if that's intentional. Did you search the upstream bug tracker to look for more info? > How are these not caught in the CI? What do you mean? The CI server did register the build failure: https://ci.guix.gnu.org/build/3863875/details As well as many other build failures in the kernel packages: https://ci.guix.gnu.org/eval/1228559
bug#70215: Documentation about uninstalling
Do you mean the guix-install.sh script? If so then what about the https://guix.gnu.org/manual/devel/en/guix.html#index-uninstallation_002c-of-Guix ?
bug#70324: After upgrade of linux-libre, linux-libre-documentation fails to build
> linux-libre-documentation is broken again: Try to repeat ./bootstrap and configure See also https://issues.guix.gnu.org/issue/70140 and the commit 74517806f80dab17474a3c5f0b91d437e4d4e052 Cheers, Bost
bug#70279: emacs-vterm not working
I was unable to replicate this myself, the following commands worked: --8<---cut here---start->8--- $ guix time-machine -q --commit=bfc614397b5f146056bda4b5a8e3a67bd1ca7b23 \ -- shell --pure emacs emacs-vterm -- emacs -Q (require 'vterm) M-x vterm --8<---cut here---end--->8--- I've seen that message before when installing vterm via straight.el. vterm requires an external library (libvterm) to function. Guix usually handles compiling that library as an input of the emacs-vterm package. Perhaps it has something to do with how libvterm is a native input, not a regular input? If it's required at runtime my understanding is it should be the latter, not the former. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi dan, sorry for the late reply. I didn't yet find the reason why different bootstrap packages are built for the cross build when grafts are applied. This seems possibly like another bug to me, as the package inputs which use copy-build-system do not contain store references and it does not happen when they themselves are built with grafts. dan writes: > Can we put everything inside build-inputs? From my understanding, > copy-build-system shouldn't care about cross-compilation at all. I understand it that way too. In guix/build-system.scm, it is mentioned that build/host/target are used in the sense of the GNU toolchain [1]. There, "build" is the system used for building and "host" is the target system for which the package is built. I guess this was confused when copy-build-system was added [2]. Cheers, David [1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Specifying-Target-Triplets.html [2] https://issues.guix.gnu.org/39599
bug#70281: Incorrect python-portend output version
Hello. I've noticed that `python-portend' does not have a correct version number in the output derivation. This will create failures during the `python-build-system' `sanity-check' phase. The following command demonstrates the issue: --8<---cut here---start->8--- $ guix shell --pure grep python python-portend -- pip3 list portend | grep 'portend' portend 0.0.0 ... --8<---cut here---end--->8--- Have a great day, Sergio.
bug#65772: kmail fails to start "unable to obtain agent type"
Installing kdepim-runtime would fix this issue. -- Sughosha
bug#69828: greetd-wlgreet-sway-session unable to login (Respawning term-tty1)
Looks like the issue has been fixed as of https://git.savannah.gnu.org/cgit/guix.git/commit/?id=edfb05e16d409ab71f5cc5c91747b693f0054d59. Thank you! This can be closed now.
bug#70051: bug#70266: Failure to open LUKS devices from a Shepherd service
Hi Ludo', On 4/7/24 19:43, Ludovic Courtès wrote: Oops, sorry for not noticing it earlier! (That was a hard-to-debug one so kudos for the work you and others put in it.) I pushed these two commits to address the problem: 49f82fca41 mapped-devices: luks: Specify modules needed at the top-level. 6062339156 mapped-devices: can specify modules to import. It works well in my tests but please let me know if something’s amiss. Just pulled+reconfigured, and my machine boots just fine with the problem LUKS device being decrypted as expected again. Thanks! Cheers, aurtzy
bug#70034: Hostkey error when pulling or building from private git repository
Hi there, I have experienced the same problem, and have a little piece of the puzzle. As I looked at the server hosting my own private channel I saw the line Unable to negotiate with XXX.XXX.XXX.XXX port 45072: no matching host key type found. Their offer: ssh-rsa [preauth] which means that the guix pull command only uses a Hostkey using an algorithm that is not in the default configuration of the sshd HostKeyAlgorithms (as it is considered too weak for keys of a size <2048 bits?). The workaround I am using is a line HostKeyAlgorithms +ssh-rsa in my server's sshd_config (and using a key of a size of 4096 bits). Nevertheless, I would like to see guix pull using a host key with a different algorithm - or a larger variety of host keys. Hoping that helps, Cheers Tim
bug#70279: emacs-vterm not working
The package emacs-vterm doesn't seem to work as intended. Running > guix shell --pure emacs emacs-vterm -- emacs -Q > (require 'vterm) results in > Vterm need `vterm-module' to work. Compile it now? (y or n) This is very weird since this error message isn't even present in the package source (guix build emacs-vterm) but only in upstream source... guix describe > guix bfc6143 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: bfc614397b5f146056bda4b5a8e3a67bd1ca7b23 > rde 0c49f45 > repository URL: https://git.sr.ht/~abcdw/rde > branch: master > commit: 0c49f451cc2de56043ce95169a5406d1ac340e94 > nonguix ec1daa7 > repository URL: https://gitlab.com/nonguix/nonguix > branch: master > commit: ec1daa71c7f03e7401d05136c290630f03f9a560 Cheers, Théo
bug#69394: cross-gcc-toolchain for riscv64 doesn't search crt1.o properly
Hello Jean-Pierre, Today I ran into the issue reported in this bug with a custom toolchain package for aarch64-linux-gnu. I applied your patch from issue 68058 and that solved the problem! Thank you very much for your insights and proposed solutions. A couple of comments below: Jean-Pierre De Jesus Diaz via Bug reports for GNU Guix writes: > 2. The other solution is to use NATIVE-SEARCH-PATHS but when using > mixed toolchains > in a single environment all of the cross compilers will share this > environment variable. > > For example: > > guix shell gcc-cross-avr-toolchain gcc-cross-i686-w64-mingw32-toolchain > > Would have the same CROSS_* environment variables and could mix things up. > > Ideally one should have per target cross variables, like, CROSS_AVR_* > CROSS_I686_W64_MINGW32_*, but this is not done right now. > > Another option is to wrap every binary of the toolchain and set the > CROSS_* variables > so that they can find the C standard library includes and binaries > without adding > search paths to avoid collisions with other toolchains for the moment and > since > profiles don't support cross-packages yet I think it is a fair trade-off. > > I think I could update https://issues.guix.gnu.org/68058 to use the > latter method. That would be awesome. If I understand correctly what you wrote, as things stand today many cross toolchains are unusable because of this problem (but not all? IIUC bare-metal cross toolchains aren't affected because they don't use crt*.o files, right?) So even your patch as it is currently proposed in issue 68058 would be an improvement over the status quo. IMHO, supporting more than one cross toolchain installed in the same profile would be interesting (I for one would find it useful to have both aarch64-linux-gnu and arm-linux-gnueabihf cross toolchains installed at the same time) but even if that is not possible yet, supporting just one cross toolchain installed in a profile would be an important improvement. :-) All this to say: unless there are other downsides to the patch in 68058, I think it should be committed. -- Thiago
bug#70258: FreeCAD dependency probably outdated
I looked at the 'python-pivy' issue again today. I was able to build 'python-pivy' from git with: git clone https://github.com/coin3d/pivy cd pivy guix shell -D python-pivy -- python3 setup.py build Examining build log of the former and comparing to the build log of standard 'guix build python-pivy --load-path=/my/python-pivy.scm' I found some differences in paths passed as arguments to the 'swig' command called by 'setup.py'. Specifically the 'swig' command is different in its last '-I' argument guix shell -D python-pivy -- python3 setup.py build: -I"/gnu/store/1k54m72p12h0lkqa9iicfknydawdfrbm-profile/include" guix build python-pivy --load-path=/my/python-pivy.scm -I"/gnu/store/ivbbmgrvhdc46p2ywx1x2zsmal3x0z5n-soqt-1.6.0-1.fb8f655/include" Both paths have 'Inventor' dir in it but the former has a lot of symlinks to the Coin but the later has only one symlink to Qt dir. I think this is why there was a buildsystem patch commented as "respect Coin3D include directory". It does not work for the latest python-pivy and this is where I stuck. Do not understand why with 'guix shell -D python-pivy -- python3 setup.py build' works whereas 'guix build python-pivy --load-path=/my/python-pivy.scm' does not and how can I fix/path.
bug#70237: Can't build python-pyside-2 5.15.10
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?
bug#70320: Krita fails to build
Hello,
Trying to build the updated Krita (5.2.1). The package doesn't seem to
build in any way possible. Couldn't figure out what exactly is the
issue.
Guix version:
guix (GNU Guix) 8bfa49444d688fd39d66dfa7d8a5d8fc04b3b571
Log ending:
make[2]: Leaving directory '/tmp/guix-build-krita-5.2.1.drv-0/build'
[ 89%] Built target kritaheifimport
make[1]: Leaving directory '/tmp/guix-build-krita-5.2.1.drv-0/build'
make: *** [Makefile:149: all] Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("-j" "24") exit-status:
2 term-signal: #f stop-signal: #f>
CMakeError.log:
Determining if the function powf exists failed with the following output:
Change Dir: /tmp/guix-build-krita-wayland-5.2.1.drv-0/build/CMakeFiles/CMakeTmp
Run Build
Command(s):/gnu/store/wj7casda7rb55rvqjnpm0bm7a2zm6618-make-4.3/bin/make -f
Makefile cmTC_79c81/fast &&
/gnu/store/wj7casda7rb55rvqjnpm0bm7a2zm6618-make-4.3/bin/make -f
CMakeFiles/cmTC_79c81.dir/build.make CMakeFiles/cmTC_79c81.dir/build
make[1]: Entering directory
'/tmp/guix-build-krita-wayland-5.2.1.drv-0/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_79c81.dir/CheckFunctionExists.c.o
/gnu/store/5lqhcv91ijy82p92ac6g5xw48l0lwwz4-gcc-11.3.0/bin/gcc -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -fno-common -Wall -Wextra -Wcast-align -Wchar-subscripts
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef
-Wmissing-format-attribute -Wwrite-strings
-Werror=implicit-function-declaration -DCHECK_FUNCTION_EXISTS=powf -std=gnu90
-o CMakeFiles/cmTC_79c81.dir/CheckFunctionExists.c.o -c
/gnu/store/gl26kr5v6ch5lc3ignly61kb224drijc-cmake-minimal-3.24.2/share/cmake-3.24/Modules/CheckFunctionExists.c
: warning: conflicting types for built-in function ‘powf’;
expected ‘float(float, float)’ [-Wbuiltin-declaration-mismatch]
/gnu/store/gl26kr5v6ch5lc3ignly61kb224drijc-cmake-minimal-3.24.2/share/cmake-3.24/Modules/CheckFunctionExists.c:7:3:
note: in expansion of macro ‘CHECK_FUNCTION_EXISTS’
7 | CHECK_FUNCTION_EXISTS(void);
| ^
/gnu/store/gl26kr5v6ch5lc3ignly61kb224drijc-cmake-minimal-3.24.2/share/cmake-3.24/Modules/CheckFunctionExists.c:1:1:
note: ‘powf’ is declared in header ‘’
+++ |+#include
1 | #ifdef CHECK_FUNCTION_EXISTS
Linking C executable cmTC_79c81
/gnu/store/gl26kr5v6ch5lc3ignly61kb224drijc-cmake-minimal-3.24.2/bin/cmake -E
cmake_link_script CMakeFiles/cmTC_79c81.dir/link.txt --verbose=1
/gnu/store/5lqhcv91ijy82p92ac6g5xw48l0lwwz4-gcc-11.3.0/bin/gcc -fno-common
-Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long
-Wpointer-arith -Wundef -Wmissing-format-attribute -Wwrite-strings
-Werror=implicit-function-declaration -DCHECK_FUNCTION_EXISTS=powf
-Wl,--enable-new-dtags CMakeFiles/cmTC_79c81.dir/CheckFunctionExists.c.o -o
cmTC_79c81
/gnu/store/hfx4i5fd1b7xxvq8k21cpj45r3asys95-lcms-2.13.1/lib/liblcms2.so
ld: CMakeFiles/cmTC_79c81.dir/CheckFunctionExists.c.o: undefined reference to
symbol 'powf@@GLIBC_2.27'
ld: /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so.6: error
adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_79c81.dir/build.make:100: cmTC_79c81] Error 1
make[1]: Leaving directory
'/tmp/guix-build-krita-wayland-5.2.1.drv-0/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:127: cmTC_79c81/fast] Error 2
--
Best Regards,
Ignas Lapėnas
bug#70258: FreeCAD dependency probably outdated
Dear Guix people, I have checked FreeCAD on several machines and get the same error. To reproduce: - guix install freecad - Open FreeCAD - Create new document - Select 'Draft' workbench This produces an error: ' returned a result with an exception set' The backtrace and also as some forums suggest (e.g., https://forum.freecad.org/viewtopic.php?t=74156) that the issue is the outdated 'python-pivy'. The dependency version in python-xyz.scm is 0.6.5 released Jan 12, 2020 where latest release 0.6.8 is from Aug 25, 2022. I have tried to build newer version of 'python-pivy' but I hit some errors that I do not understand how to fix. The errors from build log among other things tell that it 'Could not find a package configuration file provided by "Qt5Core" with any of the following names: Qt5CoreConfig.cmake qt5core-config.cmake'. Could somebody with more knowledge about building freecad help or give some suggestions how can I define latest 'python-pivy' (assuming the outdated package causes the 'Draft' workbench crash). guix describe: guix 1dbe492 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 1dbe492b993a7629df3b35146ce0272b52913776
bug#70258: FreeCAD dependency probably outdated
Moreover it seems that there is another issue already. I just did guix pull
('guix describe' -> guix bfc6143) and now freecad can not even be installed.
This time 'python-pyside' dependency is not building. Bellow is
python-pyside-2-5.15.10 build log:
phase `go-to-source-dir' succeeded after 0.0 seconds
starting phase `fix-qt-module-detection'
error: in phase 'fix-qt-module-detection': uncaught exception:
wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string"
#f) (#f)
phase `fix-qt-module-detection' failed after 0.0 seconds
Backtrace:
19 (primitive-load "/gnu/store/hmja8r0wsfk8vjxkvy0fxa5sfbi…")
In guix/build/gnu-build-system.scm:
908:2 18 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 16 (for-each # …)
In ice-9/boot-9.scm:
1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
929:23 14 (_)
In ice-9/eval.scm:
293:34 13 (_ #(#(#) (# # …)))
In srfi/srfi-1.scm:
586:29 12 (map1 ("/gnu/store/rlim3xrf4v1hzjd3k6vpl2i0k53l2fsf-…" …))
586:29 11 (map1 ("/gnu/store/i5mkjrxmyybshk3ka3m47piqv77698gz-…" …))
586:29 10 (map1 ("/gnu/store/59rqjp4g9xsmcfcgss2174ak13nd1dm1-…" …))
586:29 9 (map1 ("/gnu/store/q8iwl3sdgdvwxfgxsbvga70kb88wykch-…" …))
586:29 8 (map1 ("/gnu/store/alp588qxq5hd57hxm58i7dmqxm362z77-…" …))
586:29 7 (map1 ("/gnu/store/4011bxwbpj51rxq9n739dr29iqdwrnhj-…" …))
586:29 6 (map1 ("/gnu/store/f8zsbzvyzwnlr2g26s31h5km41gh66b8-…" …))
586:29 5 (map1 ("/gnu/store/f887mmvdhg166p0pr78r02k10lrx6h1k-…" …))
586:29 4 (map1 ("/gnu/store/wgzaypbf65az91pgmmyjncv9rrjc3dh0-…" …))
586:17 3 (map1 (#f "/gnu/store/8rxh7dxsr5jagkxmzmlys242jy8l8p…" …))
In unknown file:
2 (string-append #f "/include/qt5")
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure string-append: Wrong type (expecting string): #f
Can someone, please, check if this is indeed a new issue or freecad can still
be installed?
bug#70258: FreeCAD dependency probably outdated
Bellow for the reference is the content of '/my/python-pivy.scm' that I used in
'guix build python-pivy --load-path=/my/python-pivy.scm' command:
(define-module (guixmiss packages python)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (gnu packages)
#:use-module (guix packages)
#:use-module (guix build-system cargo)
#:use-module (guix build-system cmake)
#:use-module (guix build-system gnu)
#:use-module (guix build-system pyproject)
#:use-module (guix build-system python)
#:use-module (guix download)
#:use-module (guix hg-download)
#:use-module (guix git-download)
#:use-module (guix gexp)
#:use-module (guix utils)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-26))
(define-public python-pivy
(package
(name "python-pivy")
;; (version "0.6.8")
(version "0.6.9.a0")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/coin3d/pivy;)
(commit version)))
(file-name (git-file-name name version))
(sha256
;; (base32 "00l4r06dwmgn8h29nrl3g3yv33cfyizyylk28x1j95qyj36sggfb")
;; (version "0.6.8")
(base32 "13v9bfmipfhjbwnrl96d82fgb317j2sijgpzhhk02390649qbx6c")
;; (version "0.6.9.a0")
)
))
;; (build-system cmake-build-system)
(build-system python-build-system)
;; (build-system pyproject-build-system)
(arguments
`(;; The test suite fails due to an import cycle between 'pivy' and
'_coin'
#:tests? #f
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'patch-cmake-include-dirs
(lambda _
;; Patch buildsystem to respect Coin3D include
directory
(substitute* "interfaces/CMakeLists.txt"
(("\\$\\{SoQt_INCLUDE_DIRS}")
"${Coin_INCLUDE_DIR}\" -I\"${SoQt_INCLUDE_DIRS}"))
#t)))
))
(native-inputs
(specifications->packages
(list
"cmake"
"swig@4.0")))
(inputs
(specifications->packages
(list "python-wrapper"
"qtbase@5"
"libxi"
"libice"
"soqt"
"glew"
"coin3D")))
(home-page "https://github.com/coin3d/pivy;)
(synopsis "Python bindings to Coin3D")
(description
"Pivy provides python bindings for Coin, a 3D graphics library with an
Application Programming Interface based on the Open Inventor 2.1 API.")
(license license:isc)))
bug#70324: After upgrade of linux-libre, linux-libre-documentation fails to build
Hello, linux-libre-documentation is broken again: starting phase `build' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml import yaml ModuleNotFoundError: No module named 'yaml' ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml import yaml ModuleNotFoundError: No module named 'yaml' ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' Traceback (most recent call last): File "/tmp/guix-build-linux-libre-documentation-6.8.4.drv-0/linux-6.8.4/./tools/net/ynl/ynl-gen-rst.py", line 26, in import yaml ModuleNotFoundError: No module named 'yaml' make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/dpll.rst] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/mptcp_pm.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/devlink.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/ethtool.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/handshake.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/nfsd.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/ovs_flow.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/fou.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/netdev.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/rt_addr.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/ovs_datapath.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/ovs_vport.rst] Error 1 make[2]: *** [Documentation/Makefile:111: Documentation/networking/netlink_spec/rt_route.rst]
bug#70100: [bug#70176] [PATCH] * gnu/packages/kde-frameworks.scm (kdelibs4support): [arguments]<#:phases>: In check-post-install phase, exclude kmimetypetest.
Hello, I fixed it by patch the test data in 9acc056725. Thank you!
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi all, I would really appreciate if anyone could give some feedback on my previous patch to the copy build system. -- dan
