bug#69667: build of sway-1.9-checkout.drv failed
chris writes: > guix home reconfigure fails at sway-1.9. The bottom of the drv file shows > this, > ``` > `source is at 'sway-1.9-checkout' > [...] > ERROR: In procedure delete-file: > In procedure delete-file: No such file or directory Hello, sway build fine for me (and CI), this seems like a disk or filesystem issue on your side.
bug#69687: Error while compiling Guix: no code for module (d-bus protocol connections)
Hello, when I try to compile Guix guix shell -CWND guix -- ./bootstrap guix shell -CWND guix -- ./configure --localstatedir=/var --sysconfdir=/etc guix shell -CWND guix -- make -j16 I get the following error: [ 91%] GUILEC gnu/build/dbus-service.go ;;; Failed to autoload d-bus-session-bus-address in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-session-bus-address in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-session-bus-address in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-system-bus-address in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-system-bus-address in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-system-bus-address in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-connect in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-connect in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-connect in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-conn? in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-conn? in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-conn? in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-disconnect in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-disconnect in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-disconnect in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-write-message in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-write-message in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-write-message in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-conn-flush in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-conn-flush in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-conn-flush in (d-bus protocol connections): ;;; no code for module (d-bus protocol connections) ;;; Failed to autoload d-bus-read-message in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-read-message in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-read-message in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-message-headers in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-message-headers in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-message-headers in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-headers-ref in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-headers-ref in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-headers-ref in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-headers-ref in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-headers-ref in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-headers-ref in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-message-body in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-message-body in (d-bus protocol messages): ;;; no code for module (d-bus protocol messages) ;;; Failed to autoload d-bus-message-body in (d-bus protocol messages): ;;; no code for
bug#69686: Geiser is slow when running with geiser-guile-load-init-file set to t
Hello, I discovered that when I run Geiser with geiser-guile-load-init-file set to t, it results in horrible experience, when the REPL seems to technically work, but anything takes a long time (completion is on order of seconds). I found out that it is caused by the readline activation. I am unsure how to solve this properly. For me the workaround was to move the readline check inside the (unless (getenv "INSIDE_EMACS") ...), since I do not need it there. I was contemplating sending a patch doing just so, but I realized that also disables readline in any shell mode. I personally do not care about that (I only interact with guile from Emacs using Geiser, at least for now), but someone else might care. Ignoring the fact that disabling the colors for ansi-term (and other modes?) might not be necessary neither, I am not sure how to write more robust check. The patch I was considering is at the end of the email, feel free to use it if the trade-off would be acceptable. diff --git a/gnu/system/shadow.scm b/gnu/system/shadow.scm index d9f13271d8..fcd1d76c18 100644 --- a/gnu/system/shadow.scm +++ b/gnu/system/shadow.scm @@ -215,24 +215,26 @@ (define %default-nanorc (define %default-dotguile (plain-file "dot-guile" - "(cond ((false-if-exception (resolve-interface '(ice-9 readline))) - => - (lambda (module) - ;; Enable completion and input history at the REPL. - ((module-ref module 'activate-readline - (else - (display \"Consider installing the 'guile-readline' package for -convenient interactive line editing and input history.\\n\\n\"))) + ";;; -*- mode: scheme -*- - (unless (getenv \"INSIDE_EMACS\") -(cond ((false-if-exception (resolve-interface '(ice-9 colorized))) - => - (lambda (module) - ;; Enable completion and input history at the REPL. - ((module-ref module 'activate-colorized - (else - (display \"Consider installing the 'guile-colorized' package -for a colorful Guile experience.\\n\\n\"\n")) +(unless (getenv \"INSIDE_EMACS\") + (cond ((false-if-exception (resolve-interface '(ice-9 readline))) + => + (lambda (module) + ;; Enable completion and input history at the REPL. + ((module-ref module 'activate-readline +(else + (display \"Consider installing the 'guile-readline' package for +convenient interactive line editing and input history.\n\n\"))) + + (cond ((false-if-exception (resolve-interface '(ice-9 colorized))) + => + (lambda (module) + ;; Enable completion and input history at the REPL. + ((module-ref module 'activate-colorized +(else + (display \"Consider installing the 'guile-colorized' package +for a colorful Guile experience.\n\n\"\n")) (define %default-skeleton-home-config (plain-file "default-home-config" "\ Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
bug#60082: openblas FTBFS in KVM with default CPU
Hi, writes: > FTBFS = "Fails To Build From Source" > > guix package --no-substitutes -i openblas > > resulted in the error below on Guix System running on a KVM in Proxmox > VE using the default CPU called "kvm64". > > --- > OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat3 < ./sblat3.dat > > Program received signal SIGILL: Illegal instruction. > > Backtrace for this error: > #0 0x77d2fc1a > #1 0x77d2ee45 > #2 0x77a2209f > #3 0x186ac04 > bash: line 1: 25848 Illegal instruction OPENBLAS_NUM_THREADS=1 > OMP_NUM_THREADS=1 ./sblat3 < ./sblat3.dat > > make[1]: *** [Makefile:167: level3] Error 132 > --- > > I shutdown the VM and changed the CPU type to "host" (which provides the full > instruction set of my CPU to the VM) and was able to build successfully > using the same command. > > openblas 0.3.20 out > /gnu/store/xghpgl3fnr603z16vg7hldmpxygriqm2-openblas-0.3.20 Thanks for the report. That's probably due to some limitation in QEMU. It'd be best to report it there -- it's outside of the scope of Guix, although you could offer a Guix-based reproducer in your upstream report. Closing. -- Thanks, Maxim
bug#69682: [PATCH v2] gnu: ocaml-extlib: Convert to dune-build-system.
* gnu/packages/ocaml.scm (ocaml-extlib) [build-system]: Convert to dune-build-system. [arguments]: Remove '#:phases' and add '#:package'. Change-Id: Ia50c05423f3062200704fbcbb0680f2b326a7ca4 --- Opam still builds on gnome-team. gnu/packages/ocaml.scm | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm index 0f4c351141..b70e925d51 100644 --- a/gnu/packages/ocaml.scm +++ b/gnu/packages/ocaml.scm @@ -644,11 +644,9 @@ (define-public ocaml-extlib (sha256 (base32 "1jydzw2n84cfiz9y6lk4gih4wbr8jybanmiryfs01svd07g4vpjq" -(build-system ocaml-build-system) +(build-system dune-build-system) (arguments - `(#:phases - (modify-phases %standard-phases - (delete 'configure + (list #:package "extlib")) (native-inputs (list ocaml-cppo)) (home-page "https://github.com/ygrek/ocaml-extlib;) base-commit: 2f441fc738976175d438f7942211b1894e2eb416 -- 2.41.0
bug#69682: [PATCH 1/1] gnu: ocaml-extlib: Build with minimal=1.
Ah, you sent this while I was writing to the other bug. Would it be possible to
convert the recipe to use the dune-build-system instead? It sounds like it
would be more future-proof, and it's also prefered by opam people.
Le 9 mars 2024 22:03:15 GMT+01:00, Vivien Kraus a
écrit :
>* gnu/packages/ocaml.scm (ocaml-extlib) [arguments]: Convert to list of
>G-Expressions. Add #:make-flags.
>
>Change-Id: I42ee3c21a52788f20ddc3381927ef6ef40b2a354
>---
> gnu/packages/ocaml.scm | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
>index 0f4c351141..b911da8e5b 100644
>--- a/gnu/packages/ocaml.scm
>+++ b/gnu/packages/ocaml.scm
>@@ -646,9 +646,11 @@ (define-public ocaml-extlib
> "1jydzw2n84cfiz9y6lk4gih4wbr8jybanmiryfs01svd07g4vpjq"
> (build-system ocaml-build-system)
> (arguments
>- `(#:phases
>- (modify-phases %standard-phases
>- (delete 'configure
>+ (list
>+ #:make-flags #~'("minimal=1")
>+ #:phases
>+ #~(modify-phases %standard-phases
>+ (delete 'configure
> (native-inputs
> (list ocaml-cppo))
> (home-page "https://github.com/ygrek/ocaml-extlib;)
bug#69682: [PATCH 1/1] gnu: ocaml-extlib: Build with minimal=1.
* gnu/packages/ocaml.scm (ocaml-extlib) [arguments]: Convert to list of
G-Expressions. Add #:make-flags.
Change-Id: I42ee3c21a52788f20ddc3381927ef6ef40b2a354
---
gnu/packages/ocaml.scm | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
index 0f4c351141..b911da8e5b 100644
--- a/gnu/packages/ocaml.scm
+++ b/gnu/packages/ocaml.scm
@@ -646,9 +646,11 @@ (define-public ocaml-extlib
"1jydzw2n84cfiz9y6lk4gih4wbr8jybanmiryfs01svd07g4vpjq"
(build-system ocaml-build-system)
(arguments
- `(#:phases
- (modify-phases %standard-phases
- (delete 'configure
+ (list
+ #:make-flags #~'("minimal=1")
+ #:phases
+ #~(modify-phases %standard-phases
+ (delete 'configure
(native-inputs
(list ocaml-cppo))
(home-page "https://github.com/ygrek/ocaml-extlib;)
--
2.41.0
bug#69682: [PATCH 0/1] ocaml-extlib: Build with minimal=1.
Dear Guix, brave ocaml-team members, According to https://github.com/ocaml/opam/issues/5694 it looks like ocaml-extlib should build with minimal=1. This also fixes a build failure on gnome-team. What do you think? Best regards, Vivien Vivien Kraus (1): gnu: ocaml-extlib: Build with minimal=1. gnu/packages/ocaml.scm | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) base-commit: 2f441fc738976175d438f7942211b1894e2eb416 -- 2.41.0
bug#69682: Opam should be using a minimal version of extlib
Dear OCaml-aware Guix, opam seems to imply that we have to use a minimal variant of ocaml- extlib to build opam: https://github.com/ocaml/opam/issues/5694 This is likely related to a build failure we are experiencing on the gnome-team branch: https://issues.guix.gnu.org/69677 http://ci.guix.gnu.org/build/3415343/log/raw Best regards, Vivien
bug#63938: Inkscape 1.2.1: No module named 'lxml'
Hello,
Andreas Enge writes:
> I get a text box with a similar, but not the same error:
>
> Traceback (most recent call last):
> File
> "/gnu/store/zjc4ijkrrp1b9v1va40a3fki0gkgcp6w-inkscape-1.2.1/share/inkscape/extensions/inkex/gui/__init__.py",
> line 38, in
> import gi
> ModuleNotFoundError: No module named 'gi'
> During handling of the above exception, another exception occurred:
> Traceback (most recent call last):
> File
> "/gnu/store/zjc4ijkrrp1b9v1va40a3fki0gkgcp6w-inkscape-1.2.1/share/inkscape/extensions/inkman/inkman/manage_extensions.py",
> line 29, in
> from inkex import gui
> File
> "/gnu/store/zjc4ijkrrp1b9v1va40a3fki0gkgcp6w-inkscape-1.2.1/share/inkscape/extensions/inkex/gui/__init__.py",
> line 42, in
> raise DependencyError(
> inkex.utils.DependencyError: You are missing the required libraries for Gtk.
> Please report this problem to the Inkscape developers.
>
> Maybe we are missing propagated inputs or wrapping with some environment
> variable?
Yes, we needed GI_TYPELIB_PATH, as wrapped in commit
f4078087a69e4f57059fc6120332b47caef3aeaf ("gnu: inkscape: Fix Python
support.") on core-updates, as well as some other Python inputs.
Closing.
--
Thanks,
Maxim
bug#68748: cuirass is not reproducible
Hi Vagrant, Vagrant Cascadian writes: > On 2024-01-26, Maxim Cournoyer wrote: >> Maxim Cournoyer writes: >>> Building cuirass with 'guix build --no-grafts --check -K cuirass' shows >>> it has differences. Then running >> >> I think this is not particular to cuirass but more to any Guile package. >> I've found similar issues with guile-git and mumi. It seems Guile >> has either regressed or never supported byte compiling reproducibly? > > This looks very much like: > > > https://tests.reproducible-builds.org/debian/issues/unstable/nondeterministic_ordering_in_guile_binaries_issue.html > > Which links to several relevent issues in debian, nix, guix, and > opensuse: > > https://bugs.debian.org/995092 > https://github.com/NixOS/nixpkgs/pull/78778 > https://issues.guix.gnu.org/issue/20272 > https://build.opensuse.org/request/show/732638 Indeed, thank you. It seems the issue is a long standing one for Guile, as you linked above with #20272 (9 years old!). -- Thanks, Maxim
bug#69680: clj (clojure-tools) fails with :deps alias
I am attempting to use the :deps tools to diagnose some library issues
using "-X:deps list" and "-X:deps tree", but I keep encountering the
same error.
This example is run from an empty directory, without a project deps.edn.
$ guix shell clojure-tools openjdk -- clj -M:deps
Warning: failed to load the S3TransporterFactory class
Warning: failed to load the S3TransporterFactory class
Warning: failed to load the S3TransporterFactory class
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
further details.
Warning: failed to load the S3TransporterFactory class
Warning: failed to load the S3TransporterFactory class
Warning: failed to load the S3TransporterFactory class
Warning: failed to load the S3TransporterFactory class
Warning: failed to load the S3TransporterFactory class
Error building classpath. Could not find artifact
org.clojure:tools.deps.alpha:jar:${project.version} in central
(https://repo1.maven.org/maven2/)
bug#69617: guix go import fails on some version tags
Hi Tomas,
A little background on what I'm trying to accomplish: I have been
trying to create a package for github.com/kopia/kopia@latest. Kopia is
a multi-cloud encrypted backup thing and with that it has a sprawling
list of dependencies to handle different backends. I've been using 'go
import guix' with the -r option to attempt to recursively collect all
the dependencies. That's where I found the exception with
azure-sdk-for-go.
The approach I came up with is to retrieve the version tag from the
proxy, falling back on the prior method of generating the version tag
if it is not provided. This got me past the azure-sdk-for-go issue,
but now I'm encountering modules where the version ref is not
predictable or listed in the proxy.
I haven't encountered the problem of overlapping paths - yet!
As for my goal of building a package for kopia, I will probably hand
assemble the dependencies.
-Ryan
-Ryan
On Fri, Mar 8, 2024 at 7:25 AM Tomas Volf <~@wolfsden.cz> wrote:
>
> On 2024-03-07 10:18:52 -0800, Ryan Barber wrote:
> > In some cases the "guix import go" command fails when attempting to
> > checkout the source for a module using a tag which does not exist in
> > the repo.
> >
> > Upon further investigation, I have found guix/import/go.scm will use
> > the version string as tag. While this works most of the time, some
> > module vendors use a different tagging scheme. For example, the
> > azure-sdk-for-go repository contains many modules and the version tags
> > are namespaced by module name.
> >
> > The tag for version v1.3.0 of azure-sdk-for-go/sdk/storage/azblob is
> > storage/azblob/v1.3.0.
> >
> > $ curl -s
> > 'https://proxy.golang.org/github.com/!azure/azure-sdk-for-go/sdk/storage/azblob/@v/v1.3.0.info'
> > | jq
> > {
> > "Version": "v1.3.0",
> > "Time": "2024-02-12T16:20:44Z",
> > "Origin": {
> > "VCS": "git",
> > "URL": "https://github.com/Azure/azure-sdk-for-go;,
> > "Subdir": "sdk/storage/azblob",
> > "Ref": "refs/tags/sdk/storage/azblob/v1.3.0",
> > "Hash": "d5dfa9296a115cc5094b14198b7114a64a490994"
> > }
> > }
> >
> > I have a patch to fix this, but I would like to discuss the approach
> > before submitting it. Should I reply to this bug report with the
> > patch?
>
> I wonder, even if you manage to import it, will go-build-system be able to
> build
> it? That was what stopped me last time I looked into this, I reached the
> conclusion that current go-build-system cannot handle multiple go modules with
> overlapping paths.
>
> Out of curiosity, what was your approach to this issue?
>
> >
> > Here is the backtrace when attempting to run import on storage/azblob
> >
> > $ guix import go github.com/Azure/azure-sdk-for-go/sdk/storage/azblob
> > Backtrace:
> > 14 (primitive-load "/home/rfb/.config/guix/current/bin/guix")
> > In guix/ui.scm:
> >2324:7 13 (run-guix . _)
> > 2287:10 12 (run-guix-command _ . _)
> > In guix/scripts/import.scm:
> > 80:6 11 (guix-import . _)
> > In ice-9/boot-9.scm:
> > 1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
> > In guix/scripts/import/go.scm:
> >116:29 9 (_)
> > In ice-9/exceptions.scm:
> >406:15 8 (go-module->guix-package* . _)
> > In ice-9/boot-9.scm:
> > 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _)
> > In guix/import/go.scm:
> >532:19 6 (go-module->guix-package "github.com/Azure/azure-sdk-f…" …)
> > In guix/git.scm:
> > 295:4 5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …)
> >281:19 4 (resolve _)
> > In git/reference.scm:
> > 60:8 3 (_ _ _)
> > In git/bindings.scm:
> > 77:2 2 (raise-git-error _)
> > In ice-9/boot-9.scm:
> > 1685:16 1 (raise-exception _ #:continuable? _)
> > 1683:16 0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1683:16: In procedure raise-exception:
> > Git error: reference 'refs/tags/v1.3.1' not found
> >
>
> Have a nice day,
> Tomas Volf
>
> --
> There are only two hard things in Computer Science:
> cache invalidation, naming things and off-by-one errors.
bug#69678: Gnome fails to build
Hi Guix, As of commit 9c78902d8a9350a3277b2550c0dd87019ecc832e gnome-photos and thus gnome fails to build because pkgconfig can't find babl anymore: Run-time dependency babl found: NO (tried pkgconfig) ../gnome-photos-43.beta/meson.build:155:11: ERROR: Dependency "babl" not found, tried pkgconfig Played around with the babl package a bit and I noticed that the babl.pc file in lib/pkgconfig/ is now called babl-0.1.pc. Renaming it to babl.pc makes pkg-config find babl again. Have a nice day, Dariqq
bug#69284: guix pull is not reproducible
On 2024-03-07 12:45, Vagrant Cascadian wrote: > On 2024-02-20, Andrew Tropin wrote: >> guix pull -C channels-lock.scm produces different profiles on different >> machines. >> >> I executed the same command on a few different machines. >> channels-lock.scm contains channels list with exact commit specified. >> >> --8<---cut here---start->8--- >> curl https://paste.sr.ht/~abcdw/5f18e9e5cc6cb243c84a3975eb4e6a46ed17d996 > >> channels-lock.scm >> guix pull -C channels-lock.scm -p tmp >> readlink tmp-1-link >> --8<---cut here---end--->8--- >> >> The output log on all machines starts similiar: >> --8<---cut here---start->8--- >> Updating channel 'rde' from Git repository at >> 'https://git.sr.ht/~abcdw/rde'... >> Authenticating channel 'rde', commits 257cebd to 2a0c7e9 (2304 new >> commits)... >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> Authenticating channel 'guix', commits 9edb3f6 to d264237 (69420 new >> commits)... >> Building from these channels: >> guix https://git.savannah.gnu.org/git/guix.git d264237 >> rde https://git.sr.ht/~abcdw/rde2a0c7e9 >> --8<---cut here---end--->8--- >> >> --8<---cut here---start->8--- >> Updating channel 'rde' from Git repository at >> 'https://git.sr.ht/~abcdw/rde'... >> Authenticating channel 'rde', commits 257cebd to 2a0c7e9 (2,304 new >> commits)... >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> Authenticating channel 'guix', commits 9edb3f6 to d264237 (2,382 new >> commits)... >> Building from these channels: >> guix https://git.savannah.gnu.org/git/guix.git d264237 >> rde https://git.sr.ht/~abcdw/rde2a0c7e9 >> --8<---cut here---end--->8--- >> >> but resulting profile is different: >> /gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile (local fresh guix system) >> /gnu/store/c2i8iyqkc146ac2hqzy1v6zkqs82xypp-profile (debian 11) >> /gnu/store/svg0is4iwvlg6mgi2rvpkngcccqcvhys-profile (debian 12) >> /gnu/store/w3qq81dzdj9wckcw8fpz5lv6ylhw1m2d-profile (remote fresh guix >> system) >> >> The first guix pull takes from 25 to 50 minutes, which is really long >> time. However, due to irreproducibility, building the guix profile on >> CI doesn't help to cut that time to some manageable numbers. > > Does passing --cores=1 help? I have found building guix (and other guile > packages) on Debian had reproducibility issues frequently triggered by > parallelism. I don't think that hash of the profile depends on the building process itself. And it seems on the same system it returns the same result on consequent rebuilds. It seems something leaks from the environment. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
