bug#40316: core-updates nss not reproducible
retitle 40316 nss not reproducible thanks Still an issue on master as of d29e5a83e887cd2f4f459a12cbbfc40c77e55ce2: guix challenge --verbose --diff=simple nss guix challenge: warning: could not determine current substitute URLs; using defaults /gnu/store/mc9gdsm0cqpyd2522f5xghdl59p1l35r-nss-3.88.1 contents differ: no local build for '/gnu/store/mc9gdsm0cqpyd2522f5xghdl59p1l35r-nss-3.88.1' https://ci.guix.gnu.org/nar/lzip/mc9gdsm0cqpyd2522f5xghdl59p1l35r-nss-3.88.1: 18xvq9cb7y2hajixnkk24bh969px0h5289hgby484iyg3x73sagp https://bordeaux.guix.gnu.org/nar/lzip/mc9gdsm0cqpyd2522f5xghdl59p1l35r-nss-3.88.1: 0pnmzsy7m34v51qxpi4lrj2a9m7l19prldabwad8gx24gih4irah differing files: /lib/nss/libfreebl3.chk /lib/nss/libfreeblpriv3.chk /lib/nss/libnssdbm3.chk /lib/nss/libsoftokn3.chk 1 store items were analyzed: - 0 (0.0%) were identical - 1 (100.0%) differed - 0 (0.0%) were inconclusive According to the notes in Debian, this is due to cryptographic signatures performed at build time: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nss.html live well, vagrant signature.asc Description: PGP signature
bug#44835: gnu/ci.go: Embeds build path, breaking reproducible builds
On 2020-12-03, Ludovic Courtès wrote: > Mathieu Othacehe skribis: > >>> … but I don’t think we can assume that the checkout is in the >>> ‘%load-path’ when this code is executed. WDYT, Mathieu? >> >> Cuirass happens to add checkouts to the %load-path just before loading >> this file. > > Is that systematic? Isn’t it only when ‘load_path_inputs’ is non-empty? > >> I tested your path, it works fine. I think it is acceptable as this (gnu >> ci) interface needs a big rework anyway. >> >> I can apply your patch if it's ok for you. > > Sure if you’re confident you can go ahead. :-) This looks to have been fixed some time ago in: 76bea3f8bcd951ded88dfb7f8cad5bc3e5a1701f ci: Remove hydra support. live well, vagrant signature.asc Description: PGP signature
bug#44097: Gnucash not reproducible
Well, with a fairly recent guix: Generation 78 Mar 07 2024 12:51:33(current) guix d29e5a8 repository URL: /home/vagrant/src/guix branch: master commit: d29e5a83e887cd2f4f459a12cbbfc40c77e55ce2 gnucash 5.5 is now still not reproducible, but apparently for a possibly different reason, the share/doc directory seems to include a versioned and/or unversioned directory: guix challenge --verbose --diff=diffoscope gnucash guix challenge: warning: could not determine current substitute URLs; using defaults /gnu/store/jbqhcipnb5fi52q10iaw387jhcq64dxs-gnucash-5.5 contents differ: no local build for '/gnu/store/jbqhcipnb5fi52q10iaw387jhcq64dxs-gnucash-5.5' https://ci.guix.gnu.org/nar/lzip/jbqhcipnb5fi52q10iaw387jhcq64dxs-gnucash-5.5: 01fx1b44nmfxn0rclxwcmz43nxz87gqn2lhk1918czr7na3hfzvg https://bordeaux.guix.gnu.org/nar/lzip/jbqhcipnb5fi52q10iaw387jhcq64dxs-gnucash-5.5: 1wxbcwqhj5fj7v38x7m6bdgays735pbghzkgsymggcqr9awvqxhx bordeaux.guix.gnu.org 10.0MiB 2.6MiB/s 00:04 ▕██▏ 100.0% --- /tmp/guix-directory.jW05dk +++ /tmp/guix-directory.vaUmoD │ --- /tmp/guix-directory.jW05dk/share ├── +++ /tmp/guix-directory.vaUmoD/share │ │ --- /tmp/guix-directory.jW05dk/share/doc │ ├── +++ /tmp/guix-directory.vaUmoD/share/doc │ │ ├── file list │ │ │ @@ -1 +1,2 @@ │ │ │ -gnucash │ │ │ +gnucash │ │ │ +gnucash-5.5 1 store items were analyzed: - 0 (0.0%) were identical - 1 (100.0%) differed - 0 (0.0%) were inconclusive signature.asc Description: PGP signature
bug#69284: guix pull is not reproducible
On 2024-03-07, 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. See also: https://tests.reproducible-builds.org/debian/issues/unstable/nondeterministic_ordering_in_guile_binaries_issue.html 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 live well, vagrant signature.asc Description: PGP signature
bug#68748: cuirass is not reproducible
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 live well, vagrant signature.asc Description: PGP signature
bug#69284: guix pull is not reproducible
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. live well, vagrant signature.asc Description: PGP signature
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 --pure. > After deleting the ~/common-lisp folder I was able to load the package > without any issue, both inside a container/shell and directly on my > system also. Ok. Closing the issue then. signature.asc Description: PGP signature
bug#67334: diffoscope: missing/undetected dependencies?
On 2023-11-21, Christopher Howard wrote: > Hi, recently I tried to use diffoscope to compare to PDFs. I got these errors: > > │┄ xxd not available in path. Falling back to Python hexlify. > │┄ 'pdftotext' not available in path. Falling back to binary comparison. > > I found that if I installed packages `xxd' and `xpdf' into my environment, > the errors go away and I can compare line-by-line as expected. It is impractical to install all of the available tools that diffoscope supports, as it supports an absurd number of file formats and thus uses a very large number of tools. You can call "diffoscope --list-missing" to give suggestions about packages you might want to add, and as you've observed, diffoscope suggests what to install to get better support for the files it is currently testing. live well, vagrant signature.asc Description: PGP signature
bug#69617: guix go import fails on some version tags
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?
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
bug#69599: peercred package crashes guix go importer
Is there a way to work around this for the recursive importer if another package uses the old domain? On Wed, Mar 6, 2024 at 11:59 PM Carlo Zancanaro wrote: > > On Wed, Mar 06 2024, Nathan Dehnel wrote: > > ice-9/boot-9.scm:1683:16: In procedure raise-exception: > > In procedure getaddrinfo: System error > > Looks like an issue with the domain. Guix tries to look up inet.af, but > the project doesn't have the domain any more[1]. > > Using "guix import go github.com/inetaf/peercred" instead should work. > > Carlo > > [1]: https://github.com/inetaf/tcpproxy/issues/39
bug#43779: tbb: test_global_control failure
On Fri, Oct 9, 2020 at 5:48 PM Ludovic Courtès wrote: > > Hi Greg, > > Greg Hogan skribis: > > > I am also successfully building tbb-2020.3 and octave-5.2.0 locally. Is it > > possible to retry the build on ci.guix.gnu.org? > > I retried and it succeeded this time: > > https://ci.guix.gnu.org/log/qc926v75q54k94mwgz6gn4s02sjgrr03-tbb-2020.3 > > Could it be non-determinism when running tests in parallel? > > Thanks, > Ludo’. Closing after 3+ years and no recent build failures: https://ci.guix.gnu.org/search?query=octave%20spec:master%20system:x86_64-linux
bug#69609: Missing Disarchive info for isl-0.19.tar.bz2
Hello, We have an empty Disarchive spec here: https://disarchive.ngyro.com/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8 https://disarchive.guix.gnu.org/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8 This is for isl-0.19.tar.bz2, a dependency of GCC in Guix v1.0.0, which can be built with /gnu/store/f0ab8n0mnr3s4zj0qxpwfyvzvlipxjdb-isl-0.19.tar.bz2. Fortunately, that tarball is still available at https://bordeaux.guix.gnu.org/nar/lzip/f0ab8n0mnr3s4zj0qxpwfyvzvlipxjdb-isl-0.19.tar.bz2 (I’ve now copied it to ci.guix.gnu.org). Thoughts? Ludo’.
