bug#68439: icewm do not install MO files.
Hello: At the moment: icewm do not install MO files to 'share/locale//LC_MESSAGES', gmo files in tarball are removed, but do not re-generated, I try to add gettext-minimul to inputs, but can not re-generate gmo files successfully. Any reason we should remove gmo files in tarball? ``` (add-after 'unpack 'remove-gmo-files ;; gmo files are generated from .po files ;; so remove them before build to make sure ;; they are re-generated if needed (lambda _ (for-each delete-file (find-files "po" "\\.gmo$" ``` --
bug#68359: Can't pull my channel because of getaddrinfo -8 error
Hi, Josselin. Thanks for replying! Well, actually i encountered the problem at least 20 days ago so it definitely isn't related to recent DDOS attacks. Even if there were some before, i could and can build the commit e0d813eb175adb422a6993b173c6a3767957035d as well as my shepherd channel which is hosted on codeberg too Best wishes, Paul
bug#68429: Catch2-3.5.1 tests fails on i686-linux, SSE extension
Hi, On Sat, Jan 13, 2024 at 11:43 AM, Richard Sent wrote: > Opening a ticket so discussions a bit more organized. Hope this > doesn't step on anybody's toes. > > Catch2-3.5.1 fails to build with system=i686-linux, log attached. This > is due to a test added upstream that assumes the SSE extension is > present, > SelfTest/IntrospectiveTests/RandomNumberGeneration.tests.cpp:570. > > One fix was proposed that replaces GCC with Clang, attached. This > works because Clang assumes the SSE extension by default. If we add > "-DCMAKE_CXX_FLAGS=-mno-sse", the test fails again. > > Another solution is to add "-DCMAKE_CXX_FLAGS=-msse -mfpmath=sse" to > the existing package definition. > > Of the two, the second is more explicit in how the problem is > resolved, but I don't know if we should assume SSE is present on i686. > Thanks! Looking at other packages, seems it is find to enable SSE, just for x86_64 and i686. Other times we explicitly disable SSE2 more generally, but in this case it makes sense to match upstream (unless they change this) and enable in these cases. So, I used that configure flag just for those systems in 18393fcdddf5c3d834fa89ebf5f3925fc5b166ed which I've pushed. I added you and another (Jo Gay, from the other channel) as co-authors for finding the fix(es). > An issue was opened upstream at > https://github.com/catchorg/Catch2/issues/2796 > And thanks for this too! John > Richard Sent > > diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm > index 449340f331..e09a7bd82a 100644 > --- a/gnu/packages/check.scm > +++ b/gnu/packages/check.scm > @@ -621,9 +621,14 @@ (define-public catch2-3 > (arguments > (list >#:configure-flags > - #~(list "-DCATCH_DEVELOPMENT_BUILD=ON" > + #~(list "-DCMAKE_CXX_COMPILER=clang++" ; tests fail with gcc-11 on i686 > + "-DCMAKE_CXX_STANDARD=14" > + "-DCMAKE_CXX_STANDARD_REQUIRED=ON" > + "-DCMAKE_CXX_EXTENSIONS=OFF" > + "-DCATCH_DEVELOPMENT_BUILD=ON" >"-DCATCH_ENABLE_WERROR=OFF" >"-DBUILD_SHARED_LIBS=ON"))) > +(native-inputs (list clang-10)) > (inputs (list python-wrapper)) > (synopsis "Automated test framework for C++ and Objective-C") > (description "Catch2 stands for C++ Automated Test Cases in Headers and > is
bug#68429: Catch2-3.5.1 tests fails on i686-linux, SSE extension
Hi, On Sat, Jan 13, 2024 at 11:43 AM, Richard Sent wrote: > Opening a ticket so discussions a bit more organized. Hope this > doesn't step on anybody's toes. > > Catch2-3.5.1 fails to build with system=i686-linux, log attached. This > is due to a test added upstream that assumes the SSE extension is > present, > SelfTest/IntrospectiveTests/RandomNumberGeneration.tests.cpp:570. > > One fix was proposed that replaces GCC with Clang, attached. This > works because Clang assumes the SSE extension by default. If we add > "-DCMAKE_CXX_FLAGS=-mno-sse", the test fails again. > > Another solution is to add "-DCMAKE_CXX_FLAGS=-msse -mfpmath=sse" to > the existing package definition. > > Of the two, the second is more explicit in how the problem is > resolved, but I don't know if we should assume SSE is present on i686. > Thanks! Looking at other packages, seems it is find to enable SSE, just for x86_64 and i686. Other times we explicitly disable SSE2 more generally, but in this case it makes sense to match upstream (unless they change this) and enable in these cases. So, I used that configure flag just for those systems in 18393fcdddf5c3d834fa89ebf5f3925fc5b166ed which I've pushed. I added you and another (Jo Gay, from the other channel) as co-authors for finding the fix(es). > An issue was opened upstream at > https://github.com/catchorg/Catch2/issues/2796 > And thanks for this too! John > Richard Sent > > diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm > index 449340f331..e09a7bd82a 100644 > --- a/gnu/packages/check.scm > +++ b/gnu/packages/check.scm > @@ -621,9 +621,14 @@ (define-public catch2-3 > (arguments > (list >#:configure-flags > - #~(list "-DCATCH_DEVELOPMENT_BUILD=ON" > + #~(list "-DCMAKE_CXX_COMPILER=clang++" ; tests fail with gcc-11 on i686 > + "-DCMAKE_CXX_STANDARD=14" > + "-DCMAKE_CXX_STANDARD_REQUIRED=ON" > + "-DCMAKE_CXX_EXTENSIONS=OFF" > + "-DCATCH_DEVELOPMENT_BUILD=ON" >"-DCATCH_ENABLE_WERROR=OFF" >"-DBUILD_SHARED_LIBS=ON"))) > +(native-inputs (list clang-10)) > (inputs (list python-wrapper)) > (synopsis "Automated test framework for C++ and Objective-C") > (description "Catch2 stands for C++ Automated Test Cases in Headers and > is
bug#67290: (current-profile) only works when invoked as a process named "guix"
Simon Tournier writes: Hi, On Sun, 19 Nov 2023 at 13:24, Ian Eure wrote: The issue seems to be that current-profile checks the name of the program which was invoked, and always returns #f unless the name ends with "bin/guix". Since "guile" doesn’t, they don’t work as expected. See: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/describe.scm#n64 About current-profile, maybe this patch: [2. p.patch --- text/x-diff; p.patch] diff --git a/guix/describe.scm b/guix/describe.scm index 65cd79094b..4147d5db1f 100644 --- a/guix/describe.scm +++ b/guix/describe.scm @@ -61,14 +61,18 @@ (define current-profile or #f if this is not applicable." (match initial-program-arguments ((program . _) - (and (string-suffix? "/bin/guix" program) -;; Note: We want to do _lexical dot-dot resolution_. Using ".." -;; for real would instead take us into the /gnu/store directory -;; that ~/.config/guix/current/bin points to, whereas we want to -;; obtain ~/.config/guix/current. -(let ((candidate (dirname (dirname program - (and (file-exists? (string-append candidate "/manifest")) - candidate))) + (or (and (string-suffix? "/bin/guix" program) +;; Note: We want to do _lexical dot-dot resolution_. Using ".." +;; for real would instead take us into the /gnu/store directory +;; that ~/.config/guix/current/bin points to, whereas we want to +;; obtain ~/.config/guix/current. +(let ((candidate (dirname (dirname program + (and (file-exists? (string-append candidate "/manifest")) + candidate))) + (let ((current (string-append + (config-directory #:ensure? #f) "/current/manifest"))) + (and (file-exists? current) + current))) (define (current-profile-date) "Return the creation date of the current profile (produced by 'guix pull'), ? Well, I do not know exactly if fixing your issue does not introduce regression. The patch looks good to me, but this is all stuff I’m not very familiar with. About emacs-guix, instead of launching Guile, why not start “guix repl” instead? The command “guix repl” had been improved – and maybe even introduced after the release of emacs-guix. Somehow, I am not very happy with the current integration between Geiser and Guix. :-) I’m not sure why it works the way it does, or whether it could be changed to invoke `guix repl'. I don’t think it’s expected for library code behavior to change depending on the runtime context, so I believe fixing Guix is the right solution. Perhaps the concerns around resolving relative paths belongs somewhere more proximate to where that’s an issue? I definitely don’t understand everything happening in this code, but it strikes me as a concern relevant to some operations executed from the CLI. If that’s the case, putting it in the CLI tooling where special handling is needed would make sense to me. — Ian
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
> The issue seems to be that grafting ends-up dragging the bootstrap > packages into the closure when cross-compiling which is quite scary. I could narrow it down somehow. This commands drags the bootstrap and fails: --8<---cut here---start->8--- guix build --target= alsa-lib --8<---cut here---end--->8--- while this one doesn't: --8<---cut here---start->8--- guix build --target= alsa-lib --no-grafts --8<---cut here---end--->8--- Not sure how to go further. Adding Ludo and Efraim. Thanks, Mathieu
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hey, > ./pre-inst-env guix system build --target=aarch64-linux-gnu > gnu/system/images/pine64.scm > > > which cause an issue in gawk-mesboot: > > checking host system type... Invalid configuration `aarch64-linux-gnu': > machine `aarch64' not recognized > configure: error: > /gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash > ./config.sub aarch64-linux-gnu failed > > Janneke, do you know what could have caused this regression? This probably has nothing to do with the bootstrap packages. I noticed that the CI succeeds in building the pine64 image: https://ci.guix.gnu.org/build/3265001/details. The difference is that the CI is building without grafting. Disabling grafting locally, seems to do the trick as well: --8<---cut here---start->8--- ./pre-inst-env guix system image gnu/system/images/pine64.scm --no-grafts --8<---cut here---end--->8--- The issue seems to be that grafting ends-up dragging the bootstrap packages into the closure when cross-compiling which is quite scary. Mathieu
bug#68429: Catch2-3.5.1 tests fails on i686-linux, SSE extension
Opening a ticket so discussions a bit more organized. Hope this doesn't step on anybody's toes. Catch2-3.5.1 fails to build with system=i686-linux, log attached. This is due to a test added upstream that assumes the SSE extension is present, SelfTest/IntrospectiveTests/RandomNumberGeneration.tests.cpp:570. One fix was proposed that replaces GCC with Clang, attached. This works because Clang assumes the SSE extension by default. If we add "-DCMAKE_CXX_FLAGS=-mno-sse", the test fails again. Another solution is to add "-DCMAKE_CXX_FLAGS=-msse -mfpmath=sse" to the existing package definition. Of the two, the second is more explicit in how the problem is resolved, but I don't know if we should assume SSE is present on i686. An issue was opened upstream at https://github.com/catchorg/Catch2/issues/2796 Richard Sentdiff --git a/gnu/packages/check.scm b/gnu/packages/check.scm index 449340f331..e09a7bd82a 100644 --- a/gnu/packages/check.scm +++ b/gnu/packages/check.scm @@ -621,9 +621,14 @@ (define-public catch2-3 (arguments (list #:configure-flags - #~(list "-DCATCH_DEVELOPMENT_BUILD=ON" + #~(list "-DCMAKE_CXX_COMPILER=clang++" ; tests fail with gcc-11 on i686 + "-DCMAKE_CXX_STANDARD=14" + "-DCMAKE_CXX_STANDARD_REQUIRED=ON" + "-DCMAKE_CXX_EXTENSIONS=OFF" + "-DCATCH_DEVELOPMENT_BUILD=ON" "-DCATCH_ENABLE_WERROR=OFF" "-DBUILD_SHARED_LIBS=ON"))) +(native-inputs (list clang-10)) (inputs (list python-wrapper)) (synopsis "Automated test framework for C++ and Objective-C") (description "Catch2 stands for C++ Automated Test Cases in Headers and is sll1zarpy78qi6fgrz9xrpx99hhn3b-catch2-3.5.1.drv.gz Description: application/gzip
bug#66173: Package unknown-horizons fails during build process
Liliana, 宋文武: Are you interested in reviewing these patches? Unfortunately I neglected to CC the games team when posting them. They fix the build of Unknown Horizons in master. https://issues.guix.gnu.org/66173 -- Simon South si...@simonsouth.net Start of forwarded message Subject: bug#66173: [PATCH 0/2] unknown-horizons: Fix build, runtime errors To: 66...@debbugs.gnu.org From: Simon South Date: Thu, 4 Jan 2024 15:33:54 -0500 This patch series fixes unknown-horizons, a real-time strategy game, by applying upstream commits that allow the game and its engine to build and run using recent versions of Python. This also resolves issue #54815, "Unknown Horizons 2019.1 fails to start"[0]. I've tested this on AArch64 and x86-64 and everything seems fine: The game starts as expected using ./pre-inst-env guix shell unknown-horizons -- unknown-horizons -- Simon South si...@simonsouth.net [0] https://issues.guix.gnu.org/54815 Simon South (2): gnu: fifengine: Fix runtime error when using Python 3.9 or newer. gnu: unknown-horizons: Fix build and runtime errors. gnu/local.mk | 3 + gnu/packages/games.scm| 7 +- .../patches/fifengine-python-3.9-compat.patch | 81 +++ .../unknown-horizons-python-3.10.patch| 32 .../patches/unknown-horizons-python-3.9.patch | 41 ++ 5 files changed, 162 insertions(+), 2 deletions(-) create mode 100644 gnu/packages/patches/fifengine-python-3.9-compat.patch create mode 100644 gnu/packages/patches/unknown-horizons-python-3.10.patch create mode 100644 gnu/packages/patches/unknown-horizons-python-3.9.patch base-commit: 3c1f25fc7b3cd1942c33a48e71697f94c4c86bc2 -- 2.41.0 End of forwarded message
bug#68195: [PATCH core-updates 0/1] gnu: flite: Fix build.
Here's a patch that allows flite, a lightweight speech-synthesis engine, to build in core-updates, by applying a small patch to one of its makefiles as outlined in an earlier email[0]. I've tested this on AArch64 and x86-64 and everything seems fine. Note I haven't received a response from Dr. Black in almost two weeks' time, and my email asking to join the festival-talk mailing list[1] has bounced, so it appears flite may be unmaintained at the moment. -- Simon South si...@simonsouth.net [0] https://lists.gnu.org/archive/html/bug-guix/2024-01/msg0.html [1] http://www.festvox.org/maillists.html Simon South (1): gnu: flite: Fix build. gnu/local.mk | 1 + .../patches/flite-build-with-make-4.4.patch | 24 +++ gnu/packages/speech.scm | 3 ++- 3 files changed, 27 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/flite-build-with-make-4.4.patch base-commit: a3ae833227a284fbcfbb813b1156d0e8aeeb29d1 -- 2.41.0
bug#68195: [PATCH core-updates 1/1] gnu: flite: Fix build.
* gnu/packages/patches/flite-build-with-make-4.4.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/speech.scm (flite)[source]: Apply it. Change-Id: I263696c9571e2bcf97d5a4fc619124bce90d6799 --- gnu/local.mk | 1 + .../patches/flite-build-with-make-4.4.patch | 24 +++ gnu/packages/speech.scm | 3 ++- 3 files changed, 27 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/flite-build-with-make-4.4.patch diff --git a/gnu/local.mk b/gnu/local.mk index c1833cd0dd..9b2957c9cb 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -1185,6 +1185,7 @@ dist_patch_DATA = \ %D%/packages/patches/flann-cmake-3.11.patch \ %D%/packages/patches/flatpak-fix-path.patch \ %D%/packages/patches/flatpak-unset-gdk-pixbuf-for-sandbox.patch \ + %D%/packages/patches/flite-build-with-make-4.4.patch \ %D%/packages/patches/fluxbox-1.3.7-no-dynamic-cursor.patch \ %D%/packages/patches/fluxbox-1.3.7-gcc.patch \ %D%/packages/patches/fontconfig-cache-ignore-mtime.patch \ diff --git a/gnu/packages/patches/flite-build-with-make-4.4.patch b/gnu/packages/patches/flite-build-with-make-4.4.patch new file mode 100644 index 00..d959bb73a5 --- /dev/null +++ b/gnu/packages/patches/flite-build-with-make-4.4.patch @@ -0,0 +1,24 @@ +Building flite with GNU Make 4.4 or newer fails with log messages like + + making in main ... + gcc -g -O2 -Wall -I../include -c -o flitevox_info_main.o flitevox_info_main.c + making ../build/aarch64-linux-gnu/lib/libflite.so + make[1]: *** No rule to make target 'flite_voice_list.c', needed by 'all'. Stop. + +This is due to a change in how the .NOTPARALLEL special make target is +interpreted. This patch causes the package to build as it did with earlier +versions of Make. + +diff --git a/main/Makefile b/main/Makefile +index 8166182..e5ba866 100644 +--- a/main/Makefile b/main/Makefile +@@ -104,7 +104,7 @@ else + shared_libs: nothing + endif + +-.NOTPARALLEL: $(ALL) ++.NOTPARALLEL: + + flite_lang_list: + rm -f flite_lang_list.c diff --git a/gnu/packages/speech.scm b/gnu/packages/speech.scm index 2ea8e4f64f..4009da9654 100644 --- a/gnu/packages/speech.scm +++ b/gnu/packages/speech.scm @@ -67,7 +67,8 @@ (define-public flite (commit (string-append "v" version (file-name (git-file-name name version)) (sha256 -(base32 "1n0p81jzndzc1rzgm66kw9ls189ricy5v1ps11y0p2fk1p56kbjf" +(base32 "1n0p81jzndzc1rzgm66kw9ls189ricy5v1ps11y0p2fk1p56kbjf")) + (patches (search-patches "flite-build-with-make-4.4.patch" (build-system gnu-build-system) (arguments ;; XXX: -- 2.41.0
bug#68340: coreutils-mesboot-9.1 failed
Hi Jing, Jing Luo via Bug reports for GNU Guix writes: > building > /gnu/store/9dspz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv... > | 'build' phasebuilder for > `/gnu/store/9dspz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv' > failed with exit code 1 > build of > /gnu/store/9dspz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv failed > View build log at > '/var/log/guix/drvs/9d/spz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv.gz'. Can you also include the relevant failing part of /var/log/guix/drvs/9d/spz8w4i6c9wkdskirv4rj6lmsgp54c-coreutils-mesboot-9.1.drv.gz? Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#68359: Can't pull my channel because of getaddrinfo -8 error
Hi, "ShinyZero0" writes: > Here is my channel i'm trying to pull and keep getting that "SERVICE not > supported for `ai_socktype'" error > > ``` > (channel > (name 'zero) > (url "https://codeberg.org/shinyzero0/guix-packages.git;) > (commit > "1eacb7d9e2eb96c9d45b96af006b069e443c9ebc")) > ``` > > the full log is > > ``` > (repl-version 0 1 1) > (exception getaddrinfo-error (value -8)) > ``` Isn't that rather related to Codeberg being DDoS'd yesterday? Can you retry now? Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#68413: Ungexp doesn't work on deep lists
Hi Justin, Justin Veilleux writes: >> (define packages >> (list >> (cons "coreutils" coreutils) >> (cons "make" gnu-make) >> ...)) >> >> #~(for-each >>(lambda (f) >> ... do-something) >>'#$packages) > > If I send a patch to "fix" this, will it be usefull or is there a reason > for this behavior? I think IMO that it's a bug, but it's also quite tricky to properly traverse deep structures like this. The bug comes from the fact that in gexp->sexp, we traverse lists by matching the reference with (refs ...), but that doesn't match if the reference is a pair instead. Then, it tries to match with ($ (? self-quoting? x)), which does match since self-quoting? apparently returns #t on a pair, whether or not its constituents are also self-quoting. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#68387: guix shell --container --share=/etc overrides shadow files
Hi Guix, Running the below command as root overrides the running system's shadow files (/etc/shadow, /etc/passwd, and /etc/group). WARNING: Don't run the following outside of a VM! guix shell --container --share=/etc This erases the current user from the passwd database, meaning `su` and `sudo` no longer work, and you can't log in. Discussion The context is that I was tracking down a libreoffice bug using guix time-machine and ran the very clever command trying to get the display working. sudo guix time-machine ... -- environment -C --ad-hoc coreutils sway \ --preserve='DISPLAY' --preserve='XDG' --share=/etc -- sway Now of course if you write random commands with sudo, you should expect to brick your system from time to time. And setting `--share=/etc` wasn't particularly smart idea. However, it would have been nice to not have that wipe my shadow files. For example, being warned about sharing /etc with a container. To reproduce, run the Guix command in a basic VM image, connecting to Guix daemon on the host.[1] Please let me know if you have any questions! Kind regards, - Christina O'Donnell https://mutix.org/ --- [1] See my blog for more details: https://mutix.org/pages/blog/20240109-how-to-run-guix-in-vm.html
bug#68359: Can't pull my channel because of getaddrinfo -8 error
Here is my channel i'm trying to pull and keep getting that "SERVICE not supported for `ai_socktype'" error ``` (channel (name 'zero) (url "https://codeberg.org/shinyzero0/guix-packages.git;) (commit "1eacb7d9e2eb96c9d45b96af006b069e443c9ebc")) ``` the full log is ``` (repl-version 0 1 1) (exception getaddrinfo-error (value -8)) ``` It seems to work well on just the previous commit and i also tried some rebasing/amending to change the "breaking" commit. Sometimes it worked, but when i added other ones skipping the "breaking" one it throwed the same error. Of course the channel as well as the package the commit adds work well in my GUIX_PACKAGE_PATH There is my `guix describe`: ``` (list (channel (name 'shepherd) (url "https://codeberg.org/shinyzero0/shepherd.git;) (branch "main") (commit "10d8ad5050799ee91302a5ef7c92a9ba6afd8fa7")) (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git;) (branch "master") (commit "08d94fe20eca47b69678b3eced8749dd02c700a4") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA" (channel (name 'zero) (url "https://codeberg.org/shinyzero0/guix-packages.git;) (branch "master") (commit "e0d813eb175adb422a6993b173c6a3767957035d")) (channel (name 'rde) (url "https://git.sr.ht/~abcdw/rde;) (branch "master") (commit "d0cc15bbc47b8b218e712d1b7fc92fc63527e578") (introduction (make-channel-introduction "257cebd587b66e4d865b3537a9a88cccd7107c95" (openpgp-fingerprint "2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0") ;; warning: GUIX_PACKAGE_PATH="/home/zero/dev/guix-packages" ```
bug#68397: Bub in GNU Guix
Greetings, As asked in the output below, here`s the email reporting the bug. Thank you for you time and work! Best regards, Rui Silva guix pull Updating channel 'guix' from Git repository at ' https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to 637b72e (68,882 new commits)... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git 637b72e substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% guile-gcrypt-0.3.0 143KiB 1012KiB/s 00:00 [##] 100.0% building /gnu/store/al0d6f30wj4f4w68v2gqdkb367v75f4x-config.scm.drv... building /gnu/store/60h4f5jy7x05bgwjxp41gg5wsypaixn6-git.scm.drv... building /gnu/store/n5w7gbkyyiav73f9yypafvw2n6z5jq8n-hash.scm.drv... building /gnu/store/58nrdw354vbspqbmdi61z8mb0p34j1j0-module-import.drv... building /gnu/store/bwwj8fxvi9d2n3xjbnvkanllzi3xam98-module-import.drv... building /gnu/store/c6kgyavzvjf5wdb3yyqhd6mx1v75w54r-module-import-compiled.drv... building /gnu/store/xprx1j44shbw9qs2ibws59zhpipfb0zb-module-import-compiled.drv... building /gnu/store/v53y48cvc8blrfr6n15c6ys3hq2k4hwl-compute-guix-derivation.drv... Computing Guix derivation for 'x86_64-linux'... |guix pull: error: You found a bug: the program '/gnu/store/rml7284ljsm9j5czqzf03pn64ypkqwl5-compute-guix-derivation' failed to compute the derivation for Guix (version: "637b72e2b83a6332849218ef1f193124fa8239eb"; system: "x86_64-linux"; host version: "1.4.0"; pull-version: 1). Please report the COMPLETE output above by email to .
bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur
[AMD Official Use Only - General] I have the exact same issue when setting up cuirass on a foreign distro.
bug#68340: coreutils-mesboot-9.1 failed
Hello Guix,
Guix told me to report a bug here.
I fresh installed Guix in a qemu vm using the official guix 1.4 iso
image. After booting to desktop, I ran `guix pull
--substitute-url=https://guix.jing.rocks` (guix.jing.rocks is a server
running `guix publish` in my local LAN), then ran into a loop. I'm
attaching console message, config.scm, build log here. Maybe it's
already fixed, but let me know if any other information is needed.
--
Jing Luo
About me: https://jing.rocks/about/
PGP Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC;; This is an operating system configuration generated
;; by the graphical installer.
;;
;; Once installation is complete, you can learn and modify
;; this file to tweak the system configuration, and pass it
;; to the 'guix system reconfigure' command to effect your
;; changes.
;; Indicate which modules to import to access the variables
;; used in this configuration.
(use-modules (gnu))
(use-service-modules cups desktop networking ssh xorg)
(operating-system
(locale "en_US.utf8")
(timezone "Asia/Tokyo")
(keyboard-layout (keyboard-layout "us"))
(host-name "guix1")
;; The list of user accounts ('root' is implicit).
(users (cons* (user-account
(name "jing")
(comment "Jing")
(group "users")
(home-directory "/home/jing")
(supplementary-groups '("wheel" "netdev" "audio" "video")))
%base-user-accounts))
;; Packages installed system-wide. Users can also install packages
;; under their own account: use 'guix search KEYWORD' to search
;; for packages and 'guix install PACKAGE' to install a package.
(packages (append (list (specification->package "nss-certs"))
%base-packages))
;; Below is the list of system services. To search for available
;; services, run 'guix system search KEYWORD' in a terminal.
(services
(append (list (service xfce-desktop-service-type)
(service mate-desktop-service-type)
;; To configure OpenSSH, pass an 'openssh-configuration'
;; record as a second argument to 'service' below.
(service openssh-service-type)
(set-xorg-configuration
(xorg-configuration (keyboard-layout keyboard-layout
;; This is the default list of services we
;; are appending to.
%desktop-services))
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(targets (list "/dev/sda"))
(keyboard-layout keyboard-layout)))
(initrd-modules (append '("virtio_scsi") %base-initrd-modules))
(swap-devices (list (swap-space
(target (uuid
"3a4bebe3-58ab-48a2-9258-c87cd8d0922f")
;; The list of file systems that get "mounted". The unique
;; file system identifiers there ("UUIDs") can be obtained
;; by running 'blkid' in a terminal.
(file-systems (cons* (file-system
(mount-point "/")
(device (uuid
"59038b8e-94b2-4699-8928-5f0e36284c4f"
'ext4))
(type "ext4")) %base-file-systems)))
jing@guix1 ~$ guix pull --substitute-urls=https://guix.jing.rocks
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 3eac1c8 (26 new commits)...
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git 3eac1c8
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
building
/gnu/store/s99yh40h4ablnsmp3ss3a1945qgm30b0-compute-guix-derivation.drv...
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
substitute: updating substitutes from 'https://guix.jing.rocks'... 100.0%
