bug#40316: [PATCH 3/6] gnu: nss: Make reproducible.
On 2024-04-26, Christina O'Donnell wrote: > gnu/packages/patches/nss-Disable-library-signing.patch: Disable library > signing to make the build reproducible. > gnu/packages/nss.scm (nss): Apply this new patch. Nice! > diff --git a/gnu/packages/patches/nss-Disable-library-signing.patch > b/gnu/packages/patches/nss-Disable-library-signing.patch > new file mode 100644 > index 000..b488d29dcad > --- /dev/null > +++ b/gnu/packages/patches/nss-Disable-library-signing.patch > @@ -0,0 +1,67 @@ > +From 4734b834755822f962af29e9395daa7338084e21 Mon Sep 17 00:00:00 2001 > +Message-ID: > <4734b834755822f962af29e9395daa7338084e21.1714059680.git@mutix.org> > +From: Christina O'Donnell > +Date: Thu, 25 Apr 2024 16:35:50 +0100 > +Subject: [PATCH] nss: Disable library signing. > + > +--- > + nss/cmd/shlibsign/Makefile | 32 +--- > + 1 file changed, 1 insertion(+), 31 deletions(-) I think it would be good to explain why this patch is included, not just in the git commit message, but in the patch comments itself. I realize the patch actually includes a comment about non-determinism, but it is a bit lost in the diff. Also, might be worth briefly explaining why disabling this feature is unlikely to break anything, etc. Curious if there might be some way to leave most of the code in place, disable it... otherwise on version updates it is more likely to result in conflicts with even minor changes... live well, vagrant signature.asc Description: PGP signature
bug#69777: Please add a test for CVE-2024-27297
On 2024-03-13, Vagrant Cascadian wrote: > It would be really nice, especially for downstream distributors, if > there was a test for CVE-2024-27297. > > There is working code to test this in the excellent blog post on the > subject, which is a likely good starting point! > > > https://guix.gnu.org/en/blog/2024/fixed-output-derivation-sandbox-bypass-cve-2024-27297/ > > Super extra bonus points if the test is backwards compatible with guix > 1.4 and 1.2 :) FWIW, the reproducer from the blog is not working for me with guix 1.2: guix build -f guix-cve-2024-27297 -M4 /home/vagrant/guix-cve-2024-27297:20:7: warning: importing module (guix config) from the host /home/vagrant/guix-cve-2024-27297:20:7: warning: importing module (guix config) from the host substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/dirlf6m5kb6by220qivwj10r677ylb39-checking-for-vulnerability.drv /gnu/store/90ysjngcdr0z5mcxprryxpp2413mly8z-derivation-that-exfiltrates-fd-65f22e2a-11731.drv /gnu/store/ndny5r3l0s2vq1nal4raskl9pb0badc3-sender.drv /gnu/store/m1ln7m49qrd5jbg0rhjwgb3p5v4iqv1p-derivation-that-grabs-fd-65f22e2a-11731.drv /gnu/store/n7zss6k3999bm566n6xwqgc5672mw5yr-receiver.drv building /gnu/store/n7zss6k3999bm566n6xwqgc5672mw5yr-receiver.drv... building /gnu/store/ndny5r3l0s2vq1nal4raskl9pb0badc3-sender.drv... Backtrace: 4 (primitive-load "/gnu/store/2vg1l5pb6jgbrg3iivzj01gl0n8?") In ice-9/eval.scm: 619:8 3 (_ #f) 191:27 2 (_ #f) 223:20 1 (proc #) In unknown file: 0 (%resolve-variable (7 . load-profile) #) ERROR: In procedure %resolve-variable: Unbound variable: load-profile Backtrace: 4 (primitive-load "/gnu/store/c4a9kl1p4xs8fmw2w5smaim04cy?") In ice-9/eval.scm: 619:8 3 (_ #f) 191:27 2 (_ #f) 223:20 1 (proc #) In unknown file: 0 (%resolve-variable (7 . load-profile) #) ERROR: In procedure %resolve-variable: Unbound variable: load-profile builder for `/gnu/store/ndny5r3l0s2vq1nal4raskl9pb0badc3-sender.drv' failed with exit code 1 build of /gnu/store/ndny5r3l0s2vq1nal4raskl9pb0badc3-sender.drv failed View build log at '/var/log/guix/drvs/nd/ny5r3l0s2vq1nal4raskl9pb0badc3-sender.drv.bz2'. cannot build derivation `/gnu/store/90ysjngcdr0z5mcxprryxpp2413mly8z-derivation-that-exfiltrates-fd-65f22e2a-11731.drv': 1 dependenc ies couldn't be built cannot build derivation `/gnu/store/dirlf6m5kb6by220qivwj10r677ylb39-checking-for-vulnerability.drv': 1 dependencies couldn't be bui lt guix build: error: build of `/gnu/store/dirlf6m5kb6by220qivwj10r677ylb39-checking-for-vulnerability.drv' failed I guess I can try "guix pull" to something current to run it... live well, vagrant signature.asc Description: PGP signature
bug#69777: Please add a test for CVE-2024-27297
It would be really nice, especially for downstream distributors, if there was a test for CVE-2024-27297. There is working code to test this in the excellent blog post on the subject, which is a likely good starting point! https://guix.gnu.org/en/blog/2024/fixed-output-derivation-sandbox-bypass-cve-2024-27297/ Super extra bonus points if the test is backwards compatible with guix 1.4 and 1.2 :) live well, vagrant signature.asc Description: PGP signature
bug#48323: guix-daemon.service and guix-publish.service use deprecated StandardError/StandardOutput features
On 2023-07-20, Vagrant Cascadian wrote: > On 2022-04-29, Ludovic Courtès wrote: >> Vagrant Cascadian skribis: >> >>> Both guix-daemon.service and guix-publish.service make use of >>> StandardError=syslog and StandardOutput=syslog. >> >> [...] >> >>> So apparently need to switch the .service files to use "journal". I am >>> not sure what implications that would have for installing guix on a >>> foreign distro, such as minimum systemd version, or if anything needs >>> significant changes. >> >> Could you confirm that setting those to “journal” works on Debian? >> >> If it does, it’s probably safe now to make this change, so feel free to >> commit it in Guix. > > So, I finally got around to testing this... > > Feels a little odd just pushing after testing over a year later, > although the patch is fairly trivial... And finally pushed the patch, as 5f100c68a4a8ef9ed5599bb99c910018869bc6f3! live well, vagrant signature.asc Description: PGP signature
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#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#69518: test suite failures building Debian 1.4.0 packages
Several tests have started failing with builds of Guix in Debian:
https://bugs.debian.org/1064748
My suspicion is I need to rebuild one of guix's build dependencies, but
I am not sure which one. Maybe all of them... Debian doesn't quite have
the same nice feature of always rebuilding everything that needs
rebuilding. :/
Digging through the referenced build log and also on a local build, the
following test failures seem to all fail in a similar way, with a
bytevecotr procedure(???):
test-name: fold-available-packages with/without cache
location: /<>/tests/packages.scm:1708
source:
+ (test-assert
+ "fold-available-packages with/without cache"
+ (let ()
+ (define no-cache
+ (fold-available-packages
+ (lambda* (name version result #:rest rest)
+ (cons (cons* name version rest) result))
+ '()))
+ (define from-cache
+ (call-with-temporary-directory
+ (lambda (cache)
+ (generate-package-cache cache)
+ (mock ((guix describe) current-profile (const cache))
+ (mock ((gnu packages)
+cache-is-authoritative?
+(const #t))
+ (fold-available-packages
+ (lambda* (name version result #:rest rest)
+ (cons (cons* name version rest) result))
+ '()))
+ (define (list->set* lst)
+ (let loop ((lst lst) (duplicates '()) (seen (set)))
+ (match lst
+(() (values seen duplicates))
+((head . tail)
+ (if (set-contains? seen head)
+ (loop tail (cons head duplicates) seen)
+ (loop tail duplicates (set-insert head seen)))
+ (let ((set1 duplicates1 (list->set* from-cache))
+ (set2 duplicates2 (list->set* no-cache)))
+ (and (null? duplicates1)
+(null? duplicates2)
+(every (cut set-contains? set1 <>) no-cache)
+(every (cut set-contains? set2 <>) from-cache)
actual-value: #f
actual-error:
+ (wrong-type-arg
+ "put-bytevector"
+ "Wrong type argument in position ~A (expecting ~A): ~S"
+ (2
+"bytevector"
+#)
+ (#))
result: FAIL
test-name: find-packages-by-name with cache
location: /<>/tests/packages.scm:1760
source:
+ (test-equal
+ "find-packages-by-name with cache"
+ (find-packages-by-name "guile")
+ (call-with-temporary-directory
+ (lambda (cache)
+ (generate-package-cache cache)
+ (mock ((guix describe) current-profile (const cache))
+ (mock ((gnu packages)
+cache-is-authoritative?
+(const #t))
+ (find-packages-by-name "guile"))
expected-value: (#
# # # # #)
actual-value: #f
actual-error:
+ (wrong-type-arg
+ "put-bytevector"
+ "Wrong type argument in position ~A (expecting ~A): ~S"
+ (2
+"bytevector"
+#)
+ (#))
result: FAIL
test-name: find-packages-by-name + version, with cache
location: /<>/tests/packages.scm:1769
source:
+ (test-equal
+ "find-packages-by-name + version, with cache"
+ (find-packages-by-name "guile" "2")
+ (call-with-temporary-directory
+ (lambda (cache)
+ (generate-package-cache cache)
+ (mock ((guix describe) current-profile (const cache))
+ (mock ((gnu packages)
+cache-is-authoritative?
+(const #t))
+ (find-packages-by-name "guile" "2"))
expected-value: (#
# #)
actual-value: #f
actual-error:
+ (wrong-type-arg
+ "put-bytevector"
+ "Wrong type argument in position ~A (expecting ~A): ~S"
+ (2
+"bytevector"
+#)
+ (#))
result: FAIL
test-name: find-package-locations with cache
location: /<>/tests/packages.scm:1927
source:
+ (test-equal
+ "find-package-locations with cache"
+ (map (lambda (package)
+ (cons (package-version package)
+(package-location package)))
+(find-packages-by-name "guile"))
+ (call-with-temporary-directory
+ (lambda (cache)
+ (generate-package-cache cache)
+ (mock ((guix describe) current-profile (const cache))
+ (mock ((gnu packages)
+cache-is-authoritative?
+(const #t))
+ (find-package-locations "guile"))
expected-value: (("3.0.8" . #< file: "gnu/packages/guile.scm" line:
392 column: 2>) ("3.0.7" . #< file: "gnu/packages/guile.scm" line:
310 column: 2>) ("2.2.7" . #< file: "gnu/packages/guile.scm" line:
250 column: 2>) ("2.2.4" . #< file: "gnu/packages/guile.scm" line:
297 column: 2>) ("2.0.14" . #< file: "gnu/packages/guile.scm" line:
147 column: 2>) ("1.8.8" . #< file: "gnu/packages/guile.scm" line: 76
column: 2>))
actual-value: #f
actual-error:
+ (wrong-type-arg
+ "put-bytevector"
+ "Wrong type argument in position ~A (expecting ~A): ~S"
+ (2
+"bytevector"
+#)
+ (#))
result: FAIL
signature.asc
Description: PGP
bug#68988: All arm64/aarch64 platforms disabled in linux-libre 6.7.x!
On 2024-02-08, Leo Famulari wrote: > On Thu, Feb 08, 2024 at 07:57:38AM +0100, Wilko Meyer wrote: >> Vagrant Cascadian writes: >> > The linux-libre 6.7.x package contains ... as far as I can tell, no >> > supported arm64/aarch64 platforms! This is a pretty significant >> > regression from the linux-libre 6.6.x packaging! > > Huh! > > When I was generating configs, I never did anything very special to > ensure continued aarch64 support in new kernel series except for `make > ARCH=arm64 oldconfig`. Maybe a stray typo, e.g. ARCH=amd64 vs. ARCH=arm64 ? Only one-letter difference and a slight position shift ... easy to think one thing and type another! > It would be useful if others would help by testing the patches adding > new kernel series on aarch64 or other non-x86_64 platforms. In my > observation that rarely happens. And then bugs like this can slip in. At any rate, I can confirm that it now works again on a virtualized arm64 system! I can probably test this when introducing a new series if given a heads-up. I haven't yet tested other physical systems, but glancing over the diff looks promising... Thanks for the fix! live well, vagrant signature.asc Description: PGP signature
bug#53423: [fix] nncp: Fails to build (renamed file not found)
On 2024-02-07, Vagrant Cascadian wrote: > On 2023-06-24, Alan & Kim Zimmerman wrote: >> I took a look at this, and the problem seems to be that the cwd ends up >> different from before, so all the file operations fail. >> >> It needs (chdir "../nncp-7.5.0") in the 'go-unpack section. >> >> Attached is a patch that does this, if it works via gmail. FWIW, nncp appears to be quite out of date in guix; might be good to explore getting current upstream working... live well, vagrant signature.asc Description: PGP signature
bug#53423: [fix] nncp: Fails to build (renamed file not found)
On 2023-06-24, Alan & Kim Zimmerman wrote:
> I took a look at this, and the problem seems to be that the cwd ends up
> different from before, so all the file operations fail.
>
> It needs (chdir "../nncp-7.5.0") in the 'go-unpack section.
>
> Attached is a patch that does this, if it works via gmail.
Thanks for the patch! Miraculously, it still applies after all this
time, and it does allow the build to proceed further, but still fails in
tests:
starting phase `check'
do test
# _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-cfgdir
cmd/nncp-cfgdir/main.go:91:4: unknown field 'AllowMinusZero' in struct
literal of type hjson.EncoderOptions
ok _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src37.407s
?
_/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-bundle[no
test files]
? _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-call [no
test files]
? _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-caller
[no test files]
do: test: got exit code 2
error: in phase 'check': uncaught exception:
%exception #< program: "contrib/do" arguments: ("-c" "test")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `check' failed after 44.5 seconds
command "contrib/do" "-c" "test" failed with status 1
CCed the members of the go team who may have a better idea of, well,
packaging go programs. :)
live well,
vagrant
> From f2cc08e9cd657717049936938077a210773ab193 Mon Sep 17 00:00:00 2001
> Message-Id:
>
> From: Alan Zimmerman
> Date: Fri, 23 Jun 2023 23:57:48 +0100
> Subject: [PATCH] nncp: set directory so build succeeds
>
> ---
> gnu/packages/uucp.scm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gnu/packages/uucp.scm b/gnu/packages/uucp.scm
> index e10de59aa2..65e71c1b1a 100644
> --- a/gnu/packages/uucp.scm
> +++ b/gnu/packages/uucp.scm
> @@ -98,6 +98,7 @@ (define-public nncp
> (assoc-ref go:%standard-phases 'setup-go-environment))
> (add-after 'unpack 'go-unpack
> (lambda* (#:key source #:allow-other-keys)
> + (chdir "../nncp-7.5.0")
> ;; Copy source to GOPATH.
> (copy-recursively "src" "../src/go.cypherpunks.ru/nncp/v7")
> ;; Move bundled dependencies to GOPATH.
>
> base-commit: f25529b08e356f89ca7cecc44295085531a8faba
> --
> 2.40.1
signature.asc
Description: PGP signature
bug#68988: All arm64/aarch64 platforms disabled in linux-libre 6.7.x!
The linux-libre 6.7.x package contains ... as far as I can tell, no supported arm64/aarch64 platforms! This is a pretty significant regression from the linux-libre 6.6.x packaging! This appears to have been introduced in 95a3aaf7ad37bb0717f2c9e3faf6f636b586d133 Unfortunately it is all too easy to drop features with non-x86 platforms... especially if you run make *config from an x86 machine. For example: diff -u /gnu/store/dnism9x21x0x15k91ngis54w6pcf7gmi-linux-libre-6.6.12/.config /gnu/store/a6xc9aad9kv8xpy7i94ga74h6hs7gdvk-linux-libre-6.7.3/.config | grep -A20 '# Platform selection' # Platform selection # # CONFIG_ARCH_ACTIONS is not set -CONFIG_ARCH_SUNXI=y +# CONFIG_ARCH_SUNXI is not set # CONFIG_ARCH_ALPINE is not set -CONFIG_ARCH_APPLE=y -CONFIG_ARCH_BCM=y -CONFIG_ARCH_BCM2835=y -# CONFIG_ARCH_BCM_IPROC is not set -CONFIG_ARCH_BCMBCA=y -# CONFIG_ARCH_BRCMSTB is not set +# CONFIG_ARCH_APPLE is not set +# CONFIG_ARCH_BCM is not set # CONFIG_ARCH_BERLIN is not set -CONFIG_ARCH_BITMAIN=y +# CONFIG_ARCH_BITMAIN is not set # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_SPARX5 is not set # CONFIG_ARCH_K3 is not set # CONFIG_ARCH_LG1K is not set There are basically no CONFIG_ARCH platforms enabled! I am not sure that all the previous platforms were intentionally added, but at the very least SUNXI, ROCKCHIP, BCM2835 and probably quite a few others should be added back. I am currently running Guix System in a virtualized environment, but in the past I've run it on a sunxi systems such as pinebook and pine64+... and rockchip systems such as pinebook-pro, rock64-rk3328 and rockpro64-rk3399. This also makes me wonder what other more subtle features got dropped along the way, as well as platform support for other architectures... :/ I don't have the time at the moment to come up with a patch, but 6.7.x should probably not become the default linux-libre until this is at least partly fixed... live well, vagrant signature.asc Description: PGP signature
bug#67572: tests fail for python-sphinx-prompt
On 2023-12-01, Vagrant Cascadian wrote: > All 12 of the tests for python-sphinx-prompt fail: > > https://ci.guix.gnu.org/build/2678884/log/raw > > I tried updating python-sphinx-prompt to the newer 1.8.x version, which > switched to pyproject and poetry, but may require a newer version of > poetry. Someone else with more experience packaging python might want to > give it a try... I also tried updating to the 1.7.0 version, and that managed to get *some* of the tests to pass. I could not get 1.8.0 to build at all; maybe needs new python-poetry-core version? diff --git a/gnu/packages/sphinx.scm b/gnu/packages/sphinx.scm index eee1f1c4a8..2a8f35d387 100644 --- a/gnu/packages/sphinx.scm +++ b/gnu/packages/sphinx.scm @@ -625,7 +625,7 @@ (define-public python-sphinx-repoze-autointerface (define-public python-sphinx-prompt (package (name "python-sphinx-prompt") -(version "1.5.0") +(version "1.7.0") (source (origin (method git-fetch) ; no source release in PyPI @@ -634,8 +634,8 @@ (define-public python-sphinx-prompt (commit version))) (file-name (git-file-name name version)) (sha256 -(base32 "0x9wmgf04rzivbzp7jv1b7fkhkpi02lpk5w1qf4i7bcgih00ym8a" -(build-system python-build-system) +(base32 "0hq2apa5dgznbqnnlvykhwq74jcnjfl7gzmkncj8q1mwqm558z7x" +(build-system pyproject-build-system) (arguments `(#:phases (modify-phases %standard-phases @@ -645,7 +645,7 @@ (define-public python-sphinx-prompt (add-installed-pythonpath inputs outputs) (invoke "python" "-m" "pytest"))) (native-inputs - (list python-pytest python-sphinx)) + (list python-pytest python-sphinx python-poetry-core)) (home-page "https://github.com/sbrunner/sphinx-prompt;) (synopsis "Sphinx directive to add unselectable prompt") (description live well, vagrant signature.asc Description: PGP signature
bug#67572: tests fail for python-sphinx-prompt
X-Debbugs-Cc: Lars-Dominik Braun , jg...@dismail.de, Marius Bakke , Munyoki Kilyungi All 12 of the tests for python-sphinx-prompt fail: https://ci.guix.gnu.org/build/2678884/log/raw I tried updating python-sphinx-prompt to the newer 1.8.x version, which switched to pyproject and poetry, but may require a newer version of poetry. Someone else with more experience packaging python might want to give it a try... live well, vagrant signature.asc Description: PGP signature
bug#64775: /run should be cleaned on boot
On 2023-08-08, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> Oh, I noticed on reconfiguring back to a system without the patches to >> support /run/privileged configurations ... the /run/privileged directory >> is still present, with all those files sitting there in their previous >> state. >> >> This is why I think at least by default, many other distros implement >> /run as a tmpfs or similar, so that it at least gets thrown out at >> reboot. Though this is obviously a deeper problem than just this patch >> series... I will file a separate bug about that. > > We could try to make that change: /run as tmpfs, or wiped by > ‘cleanup-service-type’. Or both, really! Filed: https://issues.guix.gnu.org/64775 live well, vagrant signature.asc Description: PGP signature
bug#64775: /run should be cleaned on boot
On 2023-08-06, Hilton Chain wrote: > On Sat, 22 Jul 2023 04:24:17 +0800, > Saku Laesvuori via Bug reports for GNU Guix wrote: >> >> [1 ] >> > > I vote for TMPFS, since that would also reduce flash wear. >> > > Honestly I don't get why it's not already using TMPFS. >> > >> > One argument could be how much ram it takes: >> > >> > $ du -sc /run/* >> > 12 /run/blkid >> > 0 /run/booted-system >> > 0 /run/current-system >> > 1312/run/setuid-programs >> > 524 /run/udev >> > 1848total >> > >> > That is with no explicit setuid programs configured, on a machine with a >> > fairly minimal configuration. >> > >> > Not a *huge* amount of ram, but not nothing, either... >> >> I'd say it's effectively nothing for almost all devices capable of >> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick >> test one terminal window with only zsh running in it took almost 10 >> times as much ram. >> [2 signature.asc ] >> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using >> RSA > > I'm currently using tmpfs for /tmp, /run and /var/run on my Guix > Systems. > > If you are interested, this is my base file systems: > --8<---cut here---start->8--- > (cons* (file-system > (device "none") > (mount-point "/tmp") > (type "tmpfs") > (check? #f)) > >(file-system > (device "none") > (mount-point "/run") > (type "tmpfs") > (needed-for-boot? #t) > (check? #f)) > >(file-system > (device "none") > (mount-point "/var/run") > (type "tmpfs") > (needed-for-boot? #t) > (check? #f)) You probably want to restrict permissions on /run and /var/run, as the defaults for tmpfs are world-writeable, allowing any user or process to create files or directories in potentially harmful ways... For /tmp, these defaults are appropriate, however tricky a world-writeable directory is... Although I rarely have enough spare ram on a system to have /tmp be tmpfs for Guix System because builds happen there by default, and occasionally I need a lot more space than available ram in some cases. live well, vagrant signature.asc Description: PGP signature
bug#64775: /run should be cleaned on boot
On 2023-07-21, Csepp wrote: > Vagrant Cascadian writes: >> While I know that Guix does not really follow the FHS in most respects, >> maybe the intention of /run defined there should still be respected? >> >> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html >> >> 3.15. /run : Run-time variable data >> 3.15.1. Purpose >> >> This directory contains system information data describing the system >> since it was booted. Files under this directory must be cleared >> (removed or truncated as appropriate) at the beginning of the boot >> process. >> ... >> >> Many distros implement this by having /run on a tmpfs, but making sure >> to clean up /run at boot seems like a reasonable thing to do at the very >> least. >> >> I am not sure if it makes sense to do housecleaning of /run from guix >> system reconfigure ... as there may be legitimate uses for other >> processes to write there. ... > I vote for TMPFS, since that would also reduce flash wear. > Honestly I don't get why it's not already using TMPFS. One argument could be how much ram it takes: $ du -sc /run/* 12 /run/blkid 0 /run/booted-system 0 /run/current-system 1312/run/setuid-programs 524 /run/udev 1848total That is with no explicit setuid programs configured, on a machine with a fairly minimal configuration. Not a *huge* amount of ram, but not nothing, either... live well, vagrant signature.asc Description: PGP signature
bug#64775: /run should be cleaned on boot
So, if there are files sitting around in /run, they do not get cleaned up unless it is something guix is already aware of (e.g. /run/setuid-programs). I noticed this when experimenting with: https://issues.guix.gnu.org/61462 Add support for file capabilities(7) Even after a reboot, the leftovers from that experimental patchset were still present in /run... While I know that Guix does not really follow the FHS in most respects, maybe the intention of /run defined there should still be respected? https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html 3.15. /run : Run-time variable data 3.15.1. Purpose This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. ... Many distros implement this by having /run on a tmpfs, but making sure to clean up /run at boot seems like a reasonable thing to do at the very least. I am not sure if it makes sense to do housecleaning of /run from guix system reconfigure ... as there may be legitimate uses for other processes to write there. live well, vagrant signature.asc Description: PGP signature
bug#64745: [guix-past] channel derivation broken after recent u-boot update
On 2023-07-21, Ludovic Courtès wrote:
> Maxim Cournoyer skribis:
>
>> It appears that the Guix-Past channel now fails to build like so:
>>
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from
>> 'https://ci.guix.gnu.org'... 0.0%^Msubstitute: ESC[Kupdating substitutes
>> from 'https://ci.guix.gnu.org'... 100.0%
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from
>> 'https://bordeaux.guix.gnu.org'... 0.0%^Msubstitute: ESC[Kupdating
>> substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>> @ build-started /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv -
>> x86_64-linux
>> /var/log/guix/drvs/5g//xx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv 4536
>> (repl-version 0 1 1)
>> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value
>> (crust-pine64-plus)) (value #f))
>> builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv'
>> failed to produce output path
>> `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>> @ build-failed /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - 1
>> builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv'
>> failed to produce output path
>> `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>>
>> I suspect it's caused by the commit
>> ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
>> firmware to pinebook, pine64_plus and pine64-lts."), although I don't
>> understand why.
>
> This can be reproduced like so:
>
> --8<---cut here---start->8---
> $ guix time-machine --commit=a4038c4f783b05040cfdb262d9f4c0119b612371 -- repl
> <(echo '(use-modules (gnu packages firmware))')
> Backtrace:
> In ice-9/boot-9.scm:
>222:29 19 (map1 (((gnu packages acl)) ((gnu packages admin)) ((gnu
> packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu
> packages backup)) ((gnu # #)) # …))
...
> In unknown file:
>2 (primitive-load-path "gnu/packages/bootloaders" # 7f15e68a0c00 at ice-9/boot-9.scm:3551:37 ()>)
> In gnu/packages/bootloaders.scm:
> 1061:31 1 (_)
> In ice-9/boot-9.scm:
> 1685:16 0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> error: crust-pine64-plus: unbound variable
> --8<---cut here---end--->8---
>
> This is the dreaded “circular top-level references” case: to load
> firmware.scm, you need to (indirectly) load bootloaders.scm; but to load
> bootloader.scm, you need to be able to look up ‘crust-pine64-plus’,
> which is then unbound.
>
> Fixed in 0ab46ef3f9719f03d9b191a16e5aa91619e95451 by introducing
> promises.
Thanks!
> BTW, we should probably keep ‘make-u-boot-sunxi64-package’ private, no?
What is different about crust-firmware vs. the various
arm-trusted-firmware packages, which have a similar relationship to
u-boot?
How... can I avoid this sort of issue in the future? It is at the very
least non-obvious to humble little me...
live well,
vagrant
signature.asc
Description: PGP signature
bug#45943: php 7.4.14 fails tests on aarch64
On 2021-01-22, Vagrant Cascadian wrote: > On 2021-01-18, Vagrant Cascadian wrote: >> I don't have the system handy at the moment, but there is a recent build >> log failure from staging: >> >> https://ci.guix.gnu.org/build/187255/log/raw >> >> It appears to have logged 6 failures, though I haven't managed to find >> which tests failed in the build output at a cursory glance... >> >> Will try to get a failed build log locally when I get a chance to more >> easily debug and review... > > = > FAILED TEST SUMMARY > - > Bug #76705: unusable ssl => peer_fingerprint in stream_context_create() > [ext/openssl/tests/bug76705.phpt] > int openssl_x509_checkpurpose ( mixed $x509cert , int $purpose [, array > $cainfo = array() [, string $untrustedfile ]] \ > ) function [ext/openssl/tests/openssl_x509_checkpurpose_basic.phpt] > sni_server [ext/openssl/tests/sni_server.phpt] > sni_server with separate pk and cert > [ext/openssl/tests/sni_server_key_cert.phpt] > Bug #72071 setcookie allows max-age to be negative > [ext/standard/tests/network/bug72071.phpt] > opendir() with 'ftps://' > stream. [ext/standard/tests/streams/opendir-003.phpt] > opendir() with 'ftps://' > stream. [ext/standard/tests/streams/opendir-004.phpt] > = > > > Full log attached. Seems to be working now with php 8.2.2 (and 7.x is no longer packaged): $ guix weather --system=aarch64-linux php computing 1 package derivations for aarch64-linux... looking for 1 store items on https://ci.guix.gnu.org... https://ci.guix.gnu.org ☀ 100.0% substitutes available (1 out of 1) at least 17.0 MiB of nars (compressed) 66.1 MiB on disk (uncompressed) 0.740 seconds per request (0.7 seconds in total) 1.4 requests per second at least 1,000 queued builds aarch64-linux: 636 (63.6%) x86_64-linux: 363 (36.3%) i686-linux: 1 (.1%) build rate: 31.92 builds per hour powerpc64le-linux: 12.35 builds per hour i686-linux: 3.77 builds per hour x86_64-linux: 12.34 builds per hour aarch64-linux: 3.87 builds per hour armhf-linux: 0.04 builds per hour looking for 1 store items on https://bordeaux.guix.gnu.org... https://bordeaux.guix.gnu.org ☀ 100.0% substitutes available (1 out of 1) 4.7 MiB of nars (compressed) 66.1 MiB on disk (uncompressed) 0.759 seconds per request (0.8 seconds in total) 1.3 requests per second (continuous integration information unavailable) Marking as done. live well, vagrant signature.asc Description: PGP signature
bug#46334: mbedtls-apache fails to build on aarch64
On 2021-02-05, Leo Famulari wrote: > On Fri, Feb 05, 2021 at 01:19:39PM -0800, Vagrant Cascadian wrote: >> I get the following error when building mbedtls-apache on aarch64: >> >> /tmp/guix-build-mbedtls-apache-2.23.0.drv-0/source/programs/ssl/ssl_context_info.c: >> In function ‘read_next_b64_code’: >> /tmp/guix-build-mbedtls-apache-2.23.0.drv-0/source/programs/ssl/ssl_context_info.c:384:16: >> error: comparison is always\ >> true due to limited range of data type [-Werror=type-limits] >> while( EOF != c ) >> ^~ > > Hm, we should report this upstream. Maybe it already has been? Seems it has been fixed: $ guix weather --system=aarch64-linux mbedtls-apache computing 1 package derivations for aarch64-linux... looking for 1 store items on https://ci.guix.gnu.org... https://ci.guix.gnu.org ☀ 100.0% substitutes available (1 out of 1) at least 1.4 MiB of nars (compressed) 5.1 MiB on disk (uncompressed) 1.354 seconds per request (1.4 seconds in total) 0.7 requests per second at least 1,000 queued builds aarch64-linux: 636 (63.6%) x86_64-linux: 363 (36.3%) i686-linux: 1 (.1%) build rate: 32.03 builds per hour powerpc64le-linux: 12.39 builds per hour i686-linux: 3.78 builds per hour x86_64-linux: 12.39 builds per hour aarch64-linux: 3.89 builds per hour armhf-linux: 0.04 builds per hour looking for 1 store items on https://bordeaux.guix.gnu.org... https://bordeaux.guix.gnu.org ☀ 100.0% substitutes available (1 out of 1) at least 1.4 MiB of nars (compressed) 5.1 MiB on disk (uncompressed) 1.284 seconds per request (1.3 seconds in total) 0.8 requests per second (continuous integration information unavailable) When it was fixed, who knows... but marking as done. live well, vagrant signature.asc Description: PGP signature
bug#48323: guix-daemon.service and guix-publish.service use deprecated StandardError/StandardOutput features
On 2022-04-29, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Both guix-daemon.service and guix-publish.service make use of >> StandardError=syslog and StandardOutput=syslog. > > [...] > >> So apparently need to switch the .service files to use "journal". I am >> not sure what implications that would have for installing guix on a >> foreign distro, such as minimum systemd version, or if anything needs >> significant changes. > > Could you confirm that setting those to “journal” works on Debian? > > If it does, it’s probably safe now to make this change, so feel free to > commit it in Guix. So, I finally got around to testing this... Feels a little odd just pushing after testing over a year later, although the patch is fairly trivial... Patch attached! live well, vagrant From 2c3a09314b0223531ab41407d619bcf300b4f422 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Thu, 20 Jul 2023 12:13:55 -0700 Subject: [PATCH] etc: systemd services: switch to "journal" for output and error logging. The "syslog" method has been deprecated for years, and issues a warning: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. Fixes: #48323 * etc/guix-daemon.service.in (StandardOutput): Use "journal" (StandardError): Likewise. * etc/guix-publish.service.in (StandardOutput): Likewise. (StandardError): Likewise. --- etc/guix-daemon.service.in | 4 ++-- etc/guix-publish.service.in | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/etc/guix-daemon.service.in b/etc/guix-daemon.service.in index 9dbc3b5678..5e75379b5e 100644 --- a/etc/guix-daemon.service.in +++ b/etc/guix-daemon.service.in @@ -9,8 +9,8 @@ Description=Build daemon for GNU Guix ExecStart=@localstatedir@/guix/profiles/per-user/root/current-guix/bin/guix-daemon \ --build-users-group=guixbuild --discover=no Environment='GUIX_LOCPATH=@localstatedir@/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 -StandardOutput=syslog -StandardError=syslog +StandardOutput=journal +StandardError=journal # Work around a nasty systemd ‘feature’ that kills the entire process tree # (including the daemon!) if any child, such as cc1plus, runs out of memory. diff --git a/etc/guix-publish.service.in b/etc/guix-publish.service.in index b8fd3b4c03..0d82e73d94 100644 --- a/etc/guix-publish.service.in +++ b/etc/guix-publish.service.in @@ -11,8 +11,8 @@ After=guix-daemon.service [Service] ExecStart=@localstatedir@/guix/profiles/per-user/root/current-guix/bin/guix publish --user=nobody --port=8181 Environment='GUIX_LOCPATH=@localstatedir@/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 -StandardOutput=syslog -StandardError=syslog +StandardOutput=journal +StandardError=journal # Despite the name, this is rate-limited: a broken daemon will eventually fail. Restart=always base-commit: 21b718f4d6c3ded8ef50d12f6e9ae6474f74620f -- 2.39.2 signature.asc Description: PGP signature
bug#61881: Failed install with 1.4.0 installer-dump-2464c83a
On 2023-03-06, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> On 2023-03-01, Josselin Poiret wrote: >>> Vagrant Cascadian writes: > > [...] > >>> I can't find the installer dump on dump.guix.gnu.org unfortunately >>> :(. >> >> It is possible I typoed it somehow, as I filed the report on another >> machine and eyeballed the name... > > I used my superpowers and found the typo: > > https://dump.guix.gnu.org/download/installer-dump-2464c83a Thanks for tracking that down! At any rate, I successfully managed to install on both on physical and virtual hardware... My guess with what caused the original failure was an unstable wireless connection on the host system. My latter installs on the hardware itself, and a virtual machine as well. live well, vagrant signature.asc Description: PGP signature
bug#61881: Failed install with 1.4.0 installer-dump-2464c73a
On 2023-03-01, Josselin Poiret wrote: > Vagrant Cascadian writes: >> Tried the guix installer 1.4.0, and it seemed to be going smoothly, >> downloading substitutes... but eventually timed out waiting for >> substitutes... >> >> The "Resume" option for the install dropped me back to selecting locale, >> keyboard, substitutes, root password, user, etc. without actually >> seeming to resume anything, and even re-downloaded all the same >> substitutes, apparently. >> >> When it failed, it obscured the error messages, although apparently they >> are also logged on tty12 (is there a log file somewhere?) ... > I can't find the installer dump on dump.guix.gnu.org unfortunately > :(. It is possible I typoed it somehow, as I filed the report on another machine and eyeballed the name... > Can you look into directories like /tmp/dump.X? There should be > a .tar.gz somewhere of the dump. No, that was probably lost when I powered it down. If the dump was stored on the to-be-installed-filesystem somewhere, there might be a chance to recover it? I had assumed when it said it uploaded the installer dump that it had done so successfully... (maybe a way to more easily confirm success or failure of the dump upload might be worth implementing?) > Things that drop you back to selecting locale seem like the whole > installer crashing rather than just the resume option working. In > general, we have some issues with handling `guix system init` problems > in the installer. Ah well, I will try again with that installer and/or the "latest" installer ... and if I still have similar issues will report back ... and will be more determined to capture any relevent dump files! If I feel adventurous, I might even try on the new laptop itself. :) Thanks for the quick response! live well, vagrant signature.asc Description: PGP signature
bug#61881: Failed install with 1.4.0 installer-dump-2464c73a
Tried the guix installer 1.4.0, and it seemed to be going smoothly, downloading substitutes... but eventually timed out waiting for substitutes... The "Resume" option for the install dropped me back to selecting locale, keyboard, substitutes, root password, user, etc. without actually seeming to resume anything, and even re-downloaded all the same substitutes, apparently. When it failed, it obscured the error messages, although apparently they are also logged on tty12 (is there a log file somewhere?) This was on a virtual machine running virt-manager with qemu (hosted on a Debian machine, fwiw), with virtio network and virtio disk. Will try again sometime soon... live well, vagrant signature.asc Description: PGP signature
bug#55683: Support binaries that need "setcap" similar to "setuid-programs"
On 2022-05-27, Vagrant Cascadian wrote: > On 2022-05-27, Vagrant Cascadian wrote: >> I've been working on a package called lcsync: >> >> https://issues.guix.gnu.org/55682 >> >> But lcsync needs CAP_NET_RAW... Normally, this is accomplished by >> running: >> >> setcap cap_net_raw=eip /path/to/bin/lcsync > > Similar issues seem to have come up for other packages: > > https://issues.guix.gnu.org/27415 > https://issues.guix.gnu.org/39136 > https://issues.guix.gnu.org/39136 > > And possibly: > > https://issues.guix.gnu.org/search?query=setcap Patches working towards implementing the required functionality at: https://issues.guix.gnu.org/61462 live well, vagrant signature.asc Description: PGP signature
bug#47949: Failed to produce output path for guix-package-cache
On 2022-11-03, zimoun wrote: > On Wed, 02 Nov 2022 at 11:40, Vagrant Cascadian wrote: >>> I do not know if “git clean -dfx” would help because here the error is >>> probably between the repositories src/guix and src/guix-master and Guix >>> manages them under 2 unrelated directory checkouts. >> >> I had the impression that it uses git to copy the branches (rather than >> cp -r or something), otherwise the --branch=master argument would be >> meaningless (e.g. --branch=master does not mean whatever happens to be >> in the working directory), so I would assume the state of the local >> working directory wouldn't matter, only what's in the specified branch >> as git sees it. > > From my understanding, this > > guix pull --url=/home/vagrant/src/guix --branch=master > > creates one directory under ~/.cache/guix/checkouts/ and then this, > > guix pull --url=/home/vagrant/src/guix-master --branch=master > > creates another directory under ~/.cache/guix/checkouts/ and these both > directory does not have the same name because their url is different. Yes, this seems consistent with my understanding too. I should also add that src/guix and src/guix-master are using the same git repository, src/guix-master is just another worktree. > IIUC, you were at generation 139 (using a clone of > /home/vagrant/src/guix living under say > ~/.cache/guix/checkouts/maboosgggz6g6va54rikfxrsdsxhe363jri7g5dhcqb57odwklaa) > > --8<---cut here---start->8--- > # First version where I noticed failures: > Generation 139 Oct 22 2022 13:07:08 > guix bb2701b > repository URL: /home/vagrant/src/guix > branch: master > commit: bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f > > # Failed to pull from 139, successfully pulled from 138: > Generation 140 Oct 24 2022 13:19:21 > guix 8663be6 > repository URL: /home/vagrant/src/guix-master > branch: master > commit: 8663be6da7f13a8eeea71dc1f493f7adc5b7672a > --8<---cut here---end--->8--- > > and then you had difficulties, but note that “guix pull” generating 140 > created another clone from /home/vagrant/src/guix-master living under > ~/.cache/guix/checkouts/ie7tn3i564wpt5i2dqqm7ixzqfxwpp2ns6rqkyqn4z55d4kqujuq. > > Generation 140 did not updated the checkout used by generation 139. > > Somehow, the state of > ~/.cache/guix/checkouts/maboosgggz6g6va54rikfxrsdsxhe363jri7g5dhcqb57odwklaa > and the state of > ~/.cache/guix/checkouts/ie7tn3i564wpt5i2dqqm7ixzqfxwpp2ns6rqkyqn4z55d4kqujuq > require some compatibility, no? Well, with the same inputs, they ought to produce the same outputs... :) > Well, I have lost the topic of the initial bug report. :-) While I think somewhat of a digression, it explained the confusing situation where "guix pull" appeared to behave differently (as I was calling it with diffrent --url), as one of the ~/.cache/guix/checkouts/ was dirty and that mattered (as there were old removed files present in the tree) ... which I suspect is the crux of the bug report, though I don't know with absolutely certainty. I'm guessing one could dirty the tree I'm guessing reverting: edac21bfc78ffea85f4dac7206e5e7cd621bba19 gnu: Remove wicd. Something like this, maybe? cd ~/.cache/guix/checkouts/SOMECHECKOUT git revert edac21bfc78ffea85f4dac7206e5e7cd621bba19 git reset origin/master cd ~ guix pull ... live well, vagrant signature.asc Description: PGP signature
bug#47949: Failed to produce output path for guix-package-cache
On 2022-11-02, zimoun wrote: > On ven., 28 oct. 2022 at 13:23, Vagrant Cascadian wrote: > >>> Oh yeah, that reminds me to add to the confusion, "guix time-machine >>> --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't >>> successfully work with guix pull. >>> >>> Maybe that's a clue pointing to the crufty .cache directories? >> >> Well, after removing ~/.cache/guix/checkouts/ I haven't had the problem >> again, with several successful pulls. > > Well, “guix time-machine --commit=” uses, > > --8<---cut here---start->8--- > (define %default-channel-url > ;; URL of the default 'guix' channel. > "https://git.savannah.gnu.org/git/guix.git;) > > (define %default-guix-channel > (channel >(name 'guix) >(branch "master") >(url %default-channel-url) >(introduction %guix-channel-introduction))) > > (define %default-channels > ;; Default list of channels. > (list %default-guix-channel)) > --8<---cut here---end--->8--- > > which is another directory checkout under ~/.cache/guix/checkouts. :-) Ok, that's promising. :) >> This suggests to me that guix should make sure to not use a dirty >> checkout to prevent this in the future ... either exporting the guix >> tree it's working with to a temporary location, or something like >> running "git clean -dfx" before using the checkout... > > From my understanding, you have 3 similar checkouts of Guix; the default one: > > --8<---cut here---start->8--- > $ cat > ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/config > [core] > bare = false > repositoryformatversion = 0 > filemode = true > logallrefupdates = true > [remote "origin"] > url = https://git.savannah.gnu.org/git/guix.git > fetch = +refs/heads/*:refs/remotes/origin/* > [branch "master"] > remote = origin > merge = refs/heads/master > --8<---cut here---end--->8--- > > and then 2 others, probably located at these hash names: > > --8<---cut here---start->8--- > $ guix repl > GNU Guile 3.0.8 > Copyright (C) 1995-2021 Free Software Foundation, Inc. > > Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. > This program is free software, and you are welcome to redistribute it > under certain conditions; type `,show c' for details. > > Enter `,help' for help. > scheme@(guix-user)> ,use(guix git) > scheme@(guix-user)> ,pp (map url-cache-directory (list > "https://git.savannah.gnu.org/git/guix.git; > "file:///home/vagrant/src/guix" > "file:///home/vagrant/src/guix-master")) > $1 = ( > > "/home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq" > > "/home/simon/.cache/guix/checkouts/cbek2jy4zeoea2wj4xppwabceeayfzzuap6iw6uk7kylh4hdolfa" > > "/home/simon/.cache/guix/checkouts/duxgcjge5pc2tzexf4qwjra3uzu3t4htsxojtxralegek3bqkisa" > ) > --8<---cut here---end--->8--- Hashes are coming out different, maybe without the file:// prefix? > then you pulled, > > guix pull --url=/home/vagrant/src/guix --branch=master > > and sometimes: > > guix pull --url=/home/vagrant/src/guix-master --branch=master > > How clean are these 2 local repositories? src/guix tends to have cruft laying around, but src/guix-master I tend to keep clean, barring accidents. I *usually* just pull from src/guix-master, which is essentially a local mirror of upstream guix.git. Though I suspect the state of the local branch does not or at least should not matter, since it's pulling from --branch=master. > I do not know if “git clean -dfx” would help because here the error is > probably between the repositories src/guix and src/guix-master and Guix > manages them under 2 unrelated directory checkouts. I had the impression that it uses git to copy the branches (rather than cp -r or something), otherwise the --branch=master argument would be meaningless (e.g. --branch=master does not mean whatever happens to be in the working directory), so I would assume the state of the local working directory wouldn't matter, only what's in the specified branch as git sees it. So My suspicion here is somehow guix is working off of dirty checkouts in ~/.cache/guix/checkouts ... which, maybe would not be so hard to reproduce ... just drop some files from an ancient checkout or something. Not sure wha
bug#47949: Failed to produce output path for guix-package-cache
On 2022-10-26, Vagrant Cascadian wrote: > On 2022-10-26, zimoun wrote: >> On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian wrote: >> >>> It is consistently the same errors in the log, though on further looking >>> i discovered a branch in ~/.cache/guix/checkouts/ that had old removed >>> files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow >>> related. I did remove all the evidence, so so if stale checkouts is >>> somehow the issue, it will be hard to reproduce again... oops. ... >>> I did manage again to use an old commit to pull up to a more recent >>> master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new >>> commits now so will try again. Will see. >> >> What is your hackish workflow? You do, >> >> guix pull --commit= && guix pull > > To use the older generations I used: > > /var/guix/profiles/per-user/vagrant/current-guix-138-link/bin/guix pull ... > > >> right? From your recent pull, does this >> >> guix time-machine --commit= -- help >> >> work? where is newer than your current revision. > > Oh yeah, that reminds me to add to the confusion, "guix time-machine > --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't > successfully work with guix pull. > > Maybe that's a clue pointing to the crufty .cache directories? Well, after removing ~/.cache/guix/checkouts/ I haven't had the problem again, with several successful pulls. This suggests to me that guix should make sure to not use a dirty checkout to prevent this in the future ... either exporting the guix tree it's working with to a temporary location, or something like running "git clean -dfx" before using the checkout... live well, vagrant signature.asc Description: PGP signature
bug#47949: Failed to produce output path for guix-package-cache
On 2022-10-26, zimoun wrote: > On Wed, 26 Oct 2022 at 09:57, Vagrant Cascadian wrote: > >> It is consistently the same errors in the log, though on further looking >> i discovered a branch in ~/.cache/guix/checkouts/ that had old removed >> files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow >> related. I did remove all the evidence, so so if stale checkouts is >> somehow the issue, it will be hard to reproduce again... oops. > > Hum, what does “guix describe” say? I'll try this instead, with some annotation: $ guix pull -l 1w # Version used when 139 failed: Generation 138 Oct 19 2022 19:04:26 guix e61660c repository URL: /home/vagrant/src/guix branch: master commit: e61660c78f1190c578dd6f202bc5529cbdcff84e # First version where I noticed failures: Generation 139 Oct 22 2022 13:07:08 guix bb2701b repository URL: /home/vagrant/src/guix branch: master commit: bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f # Failed to pull from 139, successfully pulled from 138: Generation 140 Oct 24 2022 13:19:21 guix 8663be6 repository URL: /home/vagrant/src/guix-master branch: master commit: 8663be6da7f13a8eeea71dc1f493f7adc5b7672a # failed to pull from 139, successfully pulled from 138: Generation 141 Oct 25 2022 13:08:12 guix a0751e3 repository URL: /home/vagrant/src/guix-master branch: master commit: a0751e3250dfea7e52468c8090e18c3118d93a60 # Finally noticed the ~/.cache/guix/... leftover cruft and removed # cached checkouts, successfully pulled from 141: Generation 142 Oct 26 2022 10:03:18 (current) guix c07b55e repository URL: /home/vagrant/src/guix-master branch: master commit: c07b55eb94f8cfa9d0f56cfd97a16f2f7d842652 Apparently I sometimes used: guix pull --url=/home/vagrant/src/guix --branch=master and sometimes: guix pull --url=/home/vagrant/src/guix-master --branch=master Which end up using different directories in ~/.cache/guix/checkouts/ ... and one of the directories has some cruft leftover in it. After cleaning out the cruft, so far so good... >> I did manage again to use an old commit to pull up to a more recent >> master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new >> commits now so will try again. Will see. > > What is your hackish workflow? You do, > > guix pull --commit= && guix pull To use the older generations I used: /var/guix/profiles/per-user/vagrant/current-guix-138-link/bin/guix pull ... > right? From your recent pull, does this > > guix time-machine --commit= -- help > > work? where is newer than your current revision. Oh yeah, that reminds me to add to the confusion, "guix time-machine --commit=SOMECOMMIT" worked fine, even where "SOMECOMMIT" didn't successfully work with guix pull. Maybe that's a clue pointing to the crufty .cache directories? live well, vagrant signature.asc Description: PGP signature
bug#47949: Failed to produce output path for guix-package-cache
On 2022-10-26, zimoun wrote: > On Tue, 25 Oct 2022 at 12:50, Vagrant Cascadian wrote: > >> originally stared for >> me with guix successfully pulled to >> bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f, and then trying to guix pull >> to anything newer would trigger the issue... >> >> I managed to workaround it by using an older guix pull at commit >> e61660c78f1190c578dd6f202bc5529cbdcff84e, and then guix pull to >> 8663be6da7f13a8eeea71dc1f493f7adc5b7672a was successful ... but now with >> 8663be6da7f13a8eeea71dc1f493f7adc5b7672a it appears to be happening >> again. Wow, that's confusing... > > These commits are from: > > bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f Sat Oct 22 18:37:02 2022 +0200 > e61660c78f1190c578dd6f202bc5529cbdcff84e Sun Oct 16 02:00:43 2022 +0200 > 8663be6da7f13a8eeea71dc1f493f7adc5b7672a Mon Oct 24 20:31:34 2022 +0200 > > when Guix complains about > >> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value >> (python2-pygtk)) (value #f)) > > removed by > > 1c09ed37211d983d04e626d736df8f69f504630d Tue May 31 14:53:45 2022 -0400 > > > Is the ’guix pull’ failure consistent? Is it always because this or > does it vary? It is consistently the same errors in the log, though on further looking i discovered a branch in ~/.cache/guix/checkouts/ that had old removed files in it (including wicd.scm/wicd.go) ... *maybe* that was somehow related. I did remove all the evidence, so so if stale checkouts is somehow the issue, it will be hard to reproduce again... oops. I did manage again to use an old commit to pull up to a more recent master (a0751e3250dfea7e52468c8090e18c3118d93a60), and see there are new commits now so will try again. Will see. live well, vagrant signature.asc Description: PGP signature
bug#47949: Failed to produce output path for guix-package-cache
On 2021-04-29, Ludovic Courtès wrote:
> Roel Janssen skribis:
>> On Wed, 2021-04-28 at 23:38 +0200, Ludovic Courtès wrote:
>>> Roel Janssen skribis:
>>>
>>> > /builder for
>>> > `/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
>>> > cache.drv'
>>> > failed to produce output path
>>> > `/gnu/store/xgjiqmh9qlvnq1701zb5dsbbwnjx76qq-guix-package-cache'
>>> > build of
>>> > /gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-cache.drv
>>> > failed
>>> > Could not find build log for
>>> > '/gnu/store/4q9aprxi2rr1i6yjk1y7d76nbavwp4fy-guix-package-
>>> > cache.drv'.
>>>
>>> Could you find the log of this derivation? :-)
>>>
>>> It’ll tell us what’s wrong.
>>>
>>
>> I'm confused.. The message says "Could not find build log for ...". Is
>> there any other place I can look?
>
> “Could not find build log” typically happens if you’re talking to a
> remote daemon, via GUIX_DAEMON_SOCKET. In that case, the build log is
> in /var/log/guix/drvs (or similar) on the machine where the daemon is
> running.
I just started getting hit by what appears to be the same issue on a
Debian system running guix whenever i guix pull...
originally stared for
me with guix successfully pulled to
bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f, and then trying to guix pull
to anything newer would trigger the issue...
I managed to workaround it by using an older guix pull at commit
e61660c78f1190c578dd6f202bc5529cbdcff84e, and then guix pull to
8663be6da7f13a8eeea71dc1f493f7adc5b7672a was successful ... but now with
8663be6da7f13a8eeea71dc1f493f7adc5b7672a it appears to be happening
again. Wow, that's confusing...
builder for
`/gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv' failed to
produce output path
`/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache'
build of /gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv
failed
View build log at
'/var/log/guix/drvs/r3/y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv.bz2'.
cannot build derivation
`/gnu/store/z2859cbabpsdz7wcy7iq5fmgkwjphhqk-profile.drv': 1 dependencies
couldn't be built
guix pull: error: build of
`/gnu/store/z2859cbabpsdz7wcy7iq5fmgkwjphhqk-profile.drv' failed
/var/log/guix/drvs/r3/y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv.bz2
says:
(repl-version 0 1 1)
Generating package cache for
'/gnu/store/fwjz2hfj9kizx1xpimq1a13p2rinfzvh-profile'...
Backtrace:
In guix/repl.scm:
141:4 19 (machine-repl _ _)
126:7 18 (_)
In ice-9/boot-9.scm:
1747:15 17 (with-exception-handler # ?)
1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/repl.scm:
99:21 15 (_)
In unknown file:
14 (_ # ?)
13 (primitive-load "/gnu/store/ia3qygs61fk0zg18x4il6lb28vx?")
In ice-9/boot-9.scm:
1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In gnu/packages.scm:
438:11 11 (generate-package-cache _)
In srfi/srfi-1.scm:
460:18 10 (fold # _ _)
In guix/packages.scm:
570:21 9 (expand-cache . _)
1317:17 8 (supported-package? # ?)
In guix/memoization.scm:
101:0 7 (_ # # ?)
In guix/packages.scm:
1295:37 6 (_)
1555:16 5 (package->bag _ _ _ #:graft? _)
1656:48 4 (thunk)
In gnu/packages/wicd.scm:
59:32 3 (inputs #)
In ice-9/boot-9.scm:
1685:16 2 (raise-exception _ #:continuable? _)
1780:13 1 (_ #< components: (#)
In unknown file:
0 (backtrace #)
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value
(python2-pygtk)) (value #f))
If it helps,
/gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv
contains:
Derive([("out","/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache","","")],[("/gnu/store/1s1izmdn2xnznrj5mrfil6ibmcb7ishh-guile-3.0.7.drv",["out"]),("/gnu/store/nc5yrjbj78f490mjc8s622g2v0v516gb-inferior-script.scm.drv",["out"]),("/gnu/store/zjnd5hvfr2b4q299if7g508r1ilnwyp5-profile.drv",["out"])],["/gnu/store/ck9dnn4n5ljhbswydf23aaymanm8xsa2-guix-package-cache-builder"],"x86_64-linux","/gnu/store/1kws5vkl0glvpxg7arabsv6q9vazp0hx-guile-3.0.7/bin/guile",["--no-auto-compile","/gnu/store/ck9dnn4n5ljhbswydf23aaymanm8xsa2-guix-package-cache-builder"],[("guix
properties","((type . profile-hook) (hook .
package-cache))"),("out","/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache"),("preferLocalBuild","1")])
live well,
vagrant
signature.asc
Description: PGP signature
bug#55822: option to run diffoscope with guix build --rounds=N and --check
When I do: guix build --rounds=2 PACKAGE And the results differ, the process of actually running diffoscope on the results is very manual and a bit hard to automate. I might get output like: guix build: error: derivation `/gnu/store/dn50zya4d1zh21q6s3nh7f394s7ksknv-autogen-5.18.16.drv' may not be deterministic: output `/gnu/store/04byv4py1firka28h3nl70bj1g0a3n6k-autogen-5.18.16' differs from ?/gnu/store/04byv4py1firka28h3nl70bj1g0a3n6k-autogen-5.18.16-check? First of all, I have to actually remember to run: guix build --rounds=2 --keep-failed PACKAGE Would it be crazy for --rounds=N resonably assume --keep-failed ? Then it'll actually keep the produced /gnu/store/*-check ... then I have to screen-scrape the right files, sometimes accidentally grabbing the .drv instead of the right directory, and pass both the regular store item and the /gnu/store/*-check item ... if i get everything right I end up with: diffoscope /gnu/store/HASH-PACKAGE-VERSION /gnu/store/HASH-PACKAGE-VERSION-check And that basically works... but it is a very manual process... guix already has a similar tool to handle this sort of thing: guix challenge --diff=diffoscope PACKAGE But that assumes you are comparing things from your local build and the substitute server or servers, not two locally built things. How plausible would it be to implement something simile to "guix challenge --diff=diffoscope" like: guix build --rounds=2 --keep-failed --diff=diffoscope (or could --diff=diffoscope *assume* --keep-failed ?) Oh, and... basically all of the above applies for: guix build --check PACKAGE e.g. --keep-failed by default, option to support --diff=diffoscope, etc. Thanks for considering! live well, vagrant signature.asc Description: PGP signature
bug#55809: guix challenge with diffoscope fails to clean up temporary directory
When I run a command such as: guix challenge --verbose --diff=diffoscope gavl 2>&1 | tee gavl It works for the most part, producing the diffoscope output, but ends with a bunch of warnings regarding removing the temporary directory it created to compare the files: warning: failed to delete /tmp/guix-directory.5TokII/share/doc: Permission denied warning: failed to delete /tmp/guix-directory.5TokII/share: Permission denied warning: failed to delete /tmp/guix-directory.5TokII: Directory not empty The permissions on the directory are read-only, which is presumably why it cannot remove them: $ ls -latr /tmp/guix-directory.5TokII/ total 28 dr-xr-xr-x 3 vagrant vagrant 4096 Dec 31 1969 share dr-xr-xr-x 3 vagrant vagrant 4096 Dec 31 1969 lib dr-xr-xr-x 3 vagrant vagrant 4096 Dec 31 1969 include dr-xr-xr-x 5 vagrant vagrant 4096 Dec 31 1969 . drwxrwxrwt 168 rootroot12288 Jun 5 09:28 .. The warnings are at best distracting, and at worst end up effectively making it impossible to see the diffoscope output without redirecting to a file, as the source files can take up many many lines in the scroll buffer. live well, vagrant signature.asc Description: PGP signature
bug#55683: Support binaries that need "setcap" similar to "setuid-programs"
On 2022-05-27, Vagrant Cascadian wrote: > I've been working on a package called lcsync: > > https://issues.guix.gnu.org/55682 > > But lcsync needs CAP_NET_RAW... Normally, this is accomplished by > running: > > setcap cap_net_raw=eip /path/to/bin/lcsync Similar issues seem to have come up for other packages: https://issues.guix.gnu.org/27415 https://issues.guix.gnu.org/39136 https://issues.guix.gnu.org/39136 And possibly: https://issues.guix.gnu.org/search?query=setcap Some programs *might* be able to handle this sort of thing in a service definition, but lcsync at least should be callable by the user from the commandline (sort of like rsync); it doesn't normally have a daemon component that would make sense to run as a service. live well, vagrant signature.asc Description: PGP signature
bug#55683: Support binaries that need "setcap" similar to "setuid-programs"
I've been working on a package called lcsync: https://issues.guix.gnu.org/55682 But lcsync needs CAP_NET_RAW... Normally, this is accomplished by running: setcap cap_net_raw=eip /path/to/bin/lcsync You could add lcsync to setuid-programs, but this would be a terrible idea, as it's a file syncing tool and you would have root access to writing any file in the filesystem... Upstream lcsync is considering how to rewrite it to drop privledges so that it would not be *terrible* to run setuid root, but ... ideally it could just use setcap to provide the very limited root privledges that it needs. It seems like something very similar to setuid-programs could work for programs that need particular capabilities... e.g. copy a binary from the store, set the appropriate capabilities with "setcap", add this special directory to PATH. But maybe there's a better way to do this already? :) live well, vagrant signature.asc Description: PGP signature
bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux
On 2022-05-06, Vagrant Cascadian wrote: > On 2022-05-06, Vagrant Cascadian wrote: >> On 2022-05-06, Maxime Devos wrote: >>> raingloom schreef op vr 06-05-2022 om 02:28 [+0200]: >>>> > …)) In guix/cpu.scm: >>>> > 94:2 0 (cpu->gcc-architecture #f) >>>> >>>> This indicates the same to me. >>>> But I don't know the internals of --tune well enough, so it's just a >>>> hunch. >>> >>> Could anyone who encounters the issue on aarch64-linux send their >>> /proc/cpuinfo, such that other people can test the body of 'current- >>> cpu' on that copy? > > What is reading from /proc/cpuinfo? I've heard it suggested that > /proc/cpuinfo was more informational and not something to be relied on > for anything that actually matters... ? > > Well, I guess I answered my initial question by reading the error > message... guix/cpu.scm ... how did that work before for things like > cross-building, where /proc/cpuinfo is *definitely* wrong to get > information about the architecture you're building for? So, the simplest reproducer is just to call what was in the test, essentially: $ guix shell --export-manifest gsl openblas gcc-toolchain --tune Backtrace: 10 (primitive-load "/home/vagrant/.config/guix/current/bin…") In guix/ui.scm: 2230:7 9 (run-guix . _) 2193:10 8 (run-guix-command _ . _) In guix/scripts/shell.scm: 160:17 7 (guix-shell . _) In ice-9/boot-9.scm: 1747:15 6 (with-exception-handler # …) In srfi/srfi-37.scm: 201:16 5 (next-arg) 113:18 4 (invoke-option-processor _ _ _ _ _) In unknown file: 3 (_ # # …) 2 (_ # # …) In guix/transformations.scm: 864:25 1 (_ _ _ _ ((package ad-hoc-package "gcc-toolchain") (…) …)) In guix/cpu.scm: 94:2 0 (cpu->gcc-architecture #f) guix/cpu.scm:94:2: In procedure cpu->gcc-architecture: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f Calling "guix shell --export-manifest gsl openblas gcc-toolchain" without the "--tune" argument works fine. So whatever codepath is not handling cpu->gcc-architecture being #f should somehow... handle that reasonably. Not sure what that is, as calling --tune you asked for somet tuning and failing makes sense... So apparently --tune is broken on aarch64 (and presumably any other architecture that doesn't return anything). Seems cpu->gcc-architecture should always at least return a safe baseline for all supported architectures, maybe? live well, vagrant signature.asc Description: PGP signature
bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux
On 2022-05-06, Vagrant Cascadian wrote: > On 2022-05-06, Maxime Devos wrote: >> raingloom schreef op vr 06-05-2022 om 02:28 [+0200]: >>> > …)) In guix/cpu.scm: >>> > 94:2 0 (cpu->gcc-architecture #f) >>> >>> This indicates the same to me. >>> But I don't know the internals of --tune well enough, so it's just a >>> hunch. >> >> Could anyone who encounters the issue on aarch64-linux send their >> /proc/cpuinfo, such that other people can test the body of 'current- >> cpu' on that copy? What is reading from /proc/cpuinfo? I've heard it suggested that /proc/cpuinfo was more informational and not something to be relied on for anything that actually matters... ? Well, I guess I answered my initial question by reading the error message... guix/cpu.scm ... how did that work before for things like cross-building, where /proc/cpuinfo is *definitely* wrong to get information about the architecture you're building for? > On a rockpro64: > > $ cat /proc/cpuinfo > processor : 0 > BogoMIPS: 48.00 > Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid > CPU implementer : 0x41 > CPU architecture: 8 > CPU variant : 0x0 > CPU part: 0xd03 > CPU revision: 4 ... > I'll test on some other hardware with a very different cpu and see if it > has the same problem too. And on an APM mustang: $ cat /proc/cpuinfo processor : 0 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 processor : 1 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 processor : 2 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 processor : 3 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 processor : 4 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 processor : 5 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 processor : 6 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 processor : 7 BogoMIPS: 100.00 Features: fp asimd evtstrm cpuid CPU implementer : 0x50 CPU architecture: 8 CPU variant : 0x0 CPU part: 0x000 CPU revision: 0 Both exhibit the same error when building guix, just like the original report, basically: guix/cpu.scm:94:2: In procedure cpu->gcc-architecture: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f + rm -r t-guix-manifest-18135 FAIL tests/guix-shell-export-manifest.sh (exit status: 1) live well, vagrant signature.asc Description: PGP signature
bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux
On 2022-05-06, Maxime Devos wrote: > raingloom schreef op vr 06-05-2022 om 02:28 [+0200]: >> > …)) In guix/cpu.scm: >> > 94:2 0 (cpu->gcc-architecture #f) >> >> This indicates the same to me. >> But I don't know the internals of --tune well enough, so it's just a >> hunch. > > Could anyone who encounters the issue on aarch64-linux send their > /proc/cpuinfo, such that other people can test the body of 'current- > cpu' on that copy? On a rockpro64: $ cat /proc/cpuinfo processor : 0 BogoMIPS: 48.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 processor : 1 BogoMIPS: 48.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 processor : 2 BogoMIPS: 48.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 processor : 3 BogoMIPS: 48.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd03 CPU revision: 4 processor : 4 BogoMIPS: 48.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd08 CPU revision: 2 processor : 5 BogoMIPS: 48.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part: 0xd08 CPU revision: 2 I'll test on some other hardware with a very different cpu and see if it has the same problem too. live well, vagrant signature.asc Description: PGP signature
bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux
On 2022-05-06, raingl...@riseup.net wrote: > On Fri, 06 May 2022 00:50:21 +0200 > Ludovic Courtès wrote: > >> The log goes like this: >> ... >> + guix shell --export-manifest gsl openblas gcc-toolchain --tune > > This seems to be the important part, it looks like the CPU arch isn't > being detected. > >> Backtrace: >> In ice-9/boot-9.scm: >> 1752:10 13 (with-exception-handler _ _ #:unwind? _ # _) >> In unknown file: >> 12 (apply-smob/0 #) >> In ice-9/boot-9.scm: >> 724:2 11 (call-with-prompt _ _ #> default-prompt-handle…>) In ice-9/eval.scm: >> 619:8 10 (_ #(#(#))) >> In guix/ui.scm: >>2230:7 9 (run-guix . _) >> 2193:10 8 (run-guix-command _ . _) >> In guix/scripts/shell.scm: >>160:17 7 (guix-shell . _) >> In ice-9/boot-9.scm: >> 1747:15 6 (with-exception-handler # >> …) In srfi/srfi-37.scm: >>201:16 5 (next-arg) >>113:18 4 (invoke-option-processor _ _ _ _ _) >> In unknown file: >>3 (_ # # #) >>2 (_ # # #) >> In guix/transformations.scm: >>864:25 1 (_ _ _ _ ((package ad-hoc-package "gcc-toolchain") (…) >> …)) In guix/cpu.scm: >> 94:2 0 (cpu->gcc-architecture #f) > > This indicates the same to me. > But I don't know the internals of --tune well enough, so it's just a > hunch. > >> guix/cpu.scm:94:2: In procedure cpu->gcc-architecture: >> In procedure struct-vtable: Wrong type argument in position 1 >> (expecting struct): #f >> + rm -r t-guix-manifest-12319 >> FAIL tests/guix-shell-export-manifest.sh (exit status: 1) >> --8<---cut here---end--->8--- I'm getting this same error too; happy to test any proposed patches. live well, vagrant signature.asc Description: PGP signature
bug#54828: ssh disconnects when reconfiguring system
On 2022-04-09, Vagrant Cascadian wrote: > Ever since switching to a system generation using the new shepherd > 0.9.0, whenever I'm reconfiguring my system over an ssh connection, the > ssh connection drops out during the switch... > > I hadn't noticed this happening before using the new shepherd. > > Thankfully I always use tmux or screen and can just reconnect and resume > where I left off... but it is still a bit disconcerting! This was a duplicate of https://issues.guix.gnu.org/54812 ... which is in theory fixed... though other outstanding issues prevent the fix from being verified: https://issues.guix.gnu.org/54833 https://issues.guix.gnu.org/54840 live well, vagrant signature.asc Description: PGP signature
bug#54840: guix system reconfigure results in 'error: live-service-transient: unbound variable'
The fix for https://issues.guix.gnu.org/54812 seems to have caused some fallout: eeb8ac43c8c0b0cc69422766070dbefc55f5c5c1 services: shepherd: Do not unload transient services. a2c759c8304c461d096ab763568e7f71546ff4e8 services: herd: Report whether a service is transient. These allow guix pull to work: ec6a585ee2fd91c857276479411eedd0756e0093 services: Test 'shepherd-service-upgrade' with transient services. e25eca35ff04e4234d0376fbb9a8e146869772c8 services: herd: Adjust to changes. But it appears guix system reconfigure still needs more work: $ sudo -E guix system reconfigure ~/config.scm Password: /home/vagrant/config.scm:68:23: warning: the 'target' field is deprecated, please use 'targets' instead /gnu/store/j4bs8x0gzwd7hz93iam8fl5ywavcwf9m-system /gnu/store/8vjf01yga20b6yr9wnvv5q02qnxzpa84-extlinux.conf activating system... making '/gnu/store/j4bs8x0gzwd7hz93iam8fl5ywavcwf9m-system' the current system... setting up setuid programs in '/run/setuid-programs'... populating /etc from /gnu/store/zn84y6d96r2x7zgz919pq69xa0s5bi6i-etc... The following derivation will be built: /gnu/store/xph757n54bk7v8bxccbdpkrvhc3z9npn-install-bootloader.scm.drv building /gnu/store/xph757n54bk7v8bxccbdpkrvhc3z9npn-install-bootloader.scm.drv... guix system: bootloader successfully installed on '(/dev/disk/by-id/mmc-SC16G_0xd0f41047)' shepherd: Evaluating user expression (and (defined? (quote transient?)) (map (# ?) ?)). Backtrace: In guix/store.scm: 1320:8 19 (call-with-build-handler _ _) 1320:8 18 (call-with-build-handler _ _) In ice-9/boot-9.scm: 1747:15 15 (with-exception-handler # …) In ice-9/exceptions.scm: 406:15 14 (_) In ice-9/boot-9.scm: 1752:10 13 (with-exception-handler _ _ #:unwind? _ # _) In guix/scripts/system.scm: 870:15 12 (_) In guix/store.scm: 2129:25 11 (run-with-store # #<…> …) In guix/scripts/system.scm: 870:15 10 (_ _) In guix/scripts/system/reconfigure.scm: 145:2 9 (_ _) In guix/scripts/system.scm: 768:14 8 (_ _) In ice-9/boot-9.scm: 222:17 7 (map1 (#< provision: (file-system-/gnu…> …)) In ice-9/eval.scm: 173:55 6 (_ #(#(#) #<)) 182:19 5 (proc #(#(#) #<)) 142:16 4 (compile-top-call # # #) In unknown file: 3 (%resolve-variable (7 . live-service-transient) #) In ice-9/boot-9.scm: 1685:16 2 (raise-exception _ #:continuable? _) 1683:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: live-service-transient: unbound variable live well, vagrant signature.asc Description: PGP signature
bug#54828: ssh disconnects when reconfiguring system
Ever since switching to a system generation using the new shepherd 0.9.0, whenever I'm reconfiguring my system over an ssh connection, the ssh connection drops out during the switch... I hadn't noticed this happening before using the new shepherd. Thankfully I always use tmux or screen and can just reconnect and resume where I left off... but it is still a bit disconcerting! live well, vagrant signature.asc Description: PGP signature
bug#48131: build failure: 1.3.0rc1 on Debian i386 with guile-2.2
On 2022-03-17, Maxim Cournoyer wrote: > Ludovic Courtès writes: >> Vagrant Cascadian skribis: >>> On 2021-05-02, Vagrant Cascadian wrote: >>>> On 2021-05-02, Ludovic Courtès wrote: >>>>> Guile 3.0’s compiler with ‘-O1’ (which is what we use for package files) >>>>> uses much less memory than 2.2¹. The amount of memory may also be a >>>>> function of the number of threads used (‘-j’). So it could be that the >>>>> build failed on a machine with less memory or more cores. >>>> >>>> The machine it failed on had 32 cores and 140GB of ram... but will >>>> experiment with reducing parallelism on that machine and see if that >>>> helps. >>> >>> I just realized that the Debian guix packages are built with parallelism >>> disabled for reproducible builds, so that seems unlikely to be the >>> issue... it might just be an issue with guile-2.2 on Debian... >> >> D’oh. Could you try reducing the number of libgc marker thread, in case >> that is what’s causing troubles? You can do that by setting the >> GC_MARKERS environment variables, as in GC_MARKERS=2. > > Is this issue still actual? > > If so, could you try what Ludovic suggested? Otherwise, let's close it. The Debian packages have since switched to use guile 3.0... I'll close it for now. Can always reopen if it starts happening again. live well, vagrant signature.asc Description: PGP signature
bug#54077: What does "sequel" mean in the CODE-OF-CONDUCT
In the CODE-OF-CONDUCT, I see the phrase: Note: In the sequel, "project" refers to GNU Guix, and "project maintainer(s)" refers to maintainer(s) of GNU Guix. What does "the sequel" refer to? Maybe something more like "Note: In this document, ..." ? Maybe the intended meaning is lost in translation, or it is some turn of phrase I am unfamiliar with? It is confusing to me as a native en_US speaker, at least. live well, vagrant signature.asc Description: PGP signature
bug#53214: Release 1.4.0 progress
On 2022-01-29, Leo Famulari wrote: > The build farm is having trouble building Guix for i686-linux. In fact, > it hasn't successfully completed the 'guix' job in weeks: > > https://issues.guix.gnu.org/53463 > > And building the guix package does not work on aarch64, also for weeks: > > https://issues.guix.gnu.org/52943 It does work on my aarch64 machine as of 1ef7a03a148cf5f83ab1820444f6bd50d8e732d1 and more recently f8bfb2d85682dcabe56a4b1b0f25d566a0abbd2b, but not sure why it's not building on the build farm... > Finally, should we consider retiring the armhf port in 1.4.0? It seems > that we have stopped trying to build for it: > > https://ci.guix.gnu.org/search?query=guix+spec%3Amaster+system%3Aarmhf-linux In a similar vein, aarch64 substitutes are in pretty bad shape... and the architecture as a whole is a bit hard to keep up with; there are some pretty obscure and difficult to triage bugs here and there. I'm not sure what the qualities of a release-worthy architecture are, but aarch64 is definitely suffering badly ever since the core-updates merge and the merge of the 1.4 branch into master, which required a lot of rebuilds... live well, vagrant signature.asc Description: PGP signature
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
On 2022-01-17, Vagrant Cascadian wrote: > On 2022-01-17, Pierre Langlois wrote: >> Chris Marusich writes: >>> Chris Marusich writes: > >>>> If nobody has further comments, I will commit the attached version to >>>> master in about 24 hours. >>> >>> I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We >>> still need to update the "guix" package, so even if you run "guix pull" >>> right now, you won't be able to successfully build "guix" after pulling >>> on aarch64-linux yet. >>> >>> I will coordinate with the other people who are helping to make the >>> 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. >>> See this guix-devel email thread for details: >>> >>> https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html >> >> That's awesome, thank you! > > FWIW, I can also confirm that updating the "guix" package to a version > that contains 24c3485bb3ffc05e687ef6513ac287b8d3048bab allows the "guix" > package (which contains the fairly important "guix-daemon"), to build > again. Thanks for getting it that far! > > Haven't been able to upgrade my aarch64 systems without local patches > for over a month now... glad to see a fix is *almost* ready! > > Is there anything in particular holding back upating the guix package > (other than the huge amount of big merges in progress, release > preparation, etc. and etc.)? I went ahead and pushed to master: f758ede583ef9662963873750206540f58ff3c45 gnu: guix: update to 1.3.0-22.24c3485. I tried building a newer version, but there were new test suite failures on both aarch64 and x86_64 :/ Happy aarch64ing! live well, vagrant signature.asc Description: PGP signature
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
On 2022-01-17, Pierre Langlois wrote: > Chris Marusich writes: >> Chris Marusich writes: >>> If nobody has further comments, I will commit the attached version to >>> master in about 24 hours. >> >> I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We >> still need to update the "guix" package, so even if you run "guix pull" >> right now, you won't be able to successfully build "guix" after pulling >> on aarch64-linux yet. >> >> I will coordinate with the other people who are helping to make the >> 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. >> See this guix-devel email thread for details: >> >> https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html > > That's awesome, thank you! FWIW, I can also confirm that updating the "guix" package to a version that contains 24c3485bb3ffc05e687ef6513ac287b8d3048bab allows the "guix" package (which contains the fairly important "guix-daemon"), to build again. Thanks for getting it that far! Haven't been able to upgrade my aarch64 systems without local patches for over a month now... glad to see a fix is *almost* ready! Is there anything in particular holding back upating the guix package (other than the huge amount of big merges in progress, release preparation, etc. and etc.)? Thanks everyone! live well, vagrant signature.asc Description: PGP signature
bug#51466: guix shell --check reports missing PKG_CONFIG_PATH on Debian bookworm
On 2021-10-29, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Most things seem to work fine, but noticed an oddity with guix shell: >> >> vagrant@vagranttdgxbookworm:~$ guix shell --pure --check --development guix >> guix git less >> >> guix shell: checking the environment variables visible from shell >> '/bin/bash'... >> guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell > > [...] > >> vagrant@vagranttdgxbookworm:~$ guix shell --pure --development guix guix git >> less >> >> vagrant@vagranttdgxbookworm:~$ echo $PKG_CONFIG_PATH >> /gnu/store/9vk59alg27y0cp1za91nfdjiy718cn1f-profile/lib/pkgconfig > > Notice that it doesn’t complain about any of the other environment > variables (there are 10 of them according to ‘guix shell -D guix > --search-paths|wc -l’). > > If you look at ‘child-shell-environment’ in (guix scripts environment), > it runs this in the child shell: > > env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit > > If the shell prints non-newline-terminated stuff before the output of > ‘env’, the first line of ‘env’ would be swallowed by the parser below. > > Could you run: > > strace -o log -s 500 guix shell --check -D guix > > to see exactly what ‘guix shell’ reads? That showed nothing obvious to me; the log it spits out is about 3MB (~320k compressed with zstd) I could attach if it is useful... I did notice SHELL=/bin/bash, and tried an experiment: $ SHELL=/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash guix shell --check -D guix guix shell: checking the environment variables visible from shell '/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash'... guix shell: All is good! The shell gets correct environment variables. So, somehow the value of SHELL and/or the user's default shell is triggering the issue? live well, vagrant signature.asc Description: PGP signature
bug#51466: guix shell --check reports missing PKG_CONFIG_PATH on Debian bookworm
This is a recently installed Debian bookworm system, initially using the package from debian experimental (guix 1.3.0-3, built with guile 3.0), and "guix pull" up to a recent guix master: vagrant@vagranttdgxbookworm:~$ guix describe Generation 7Oct 28 2021 11:04:25(current) guix 0e6470b repository URL: /home/vagrant/src/guix branch: master commit: 0e6470b47f00470c213fbf20bddc5bcf1e2f8e2a Most things seem to work fine, but noticed an oddity with guix shell: vagrant@vagranttdgxbookworm:~$ guix shell --pure --check --development guix guix git less guix shell: checking the environment variables visible from shell '/bin/bash'... guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment hint: One or more environment variables have a different value in the shell than the one we set. This means that you may find yourself running code in an environment different from the one you asked Guix to prepare. This usually indicates that your shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in `~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash startup files, run: info "(bash) Bash Startup Files" Alternatively, you can avoid the problem by passing the `--container' or `-C' option. That will give you a fully isolated environment running in a "container", immune to the issue described above. vagrant@vagranttdgxbookworm:~$ guix shell --pure --development guix guix git less vagrant@vagranttdgxbookworm:~$ echo $PKG_CONFIG_PATH /gnu/store/9vk59alg27y0cp1za91nfdjiy718cn1f-profile/lib/pkgconfig So, --check seems to think the environment variable is missing but running without --check the variable is defined... I don't see anything obviously relevent in /etc/profile/ or /etc/profile.d/guix.sh or /etc/profile.d/bash-completions.sh or ~/.profile or ~/.bashrc ... just used the defaults that shipped in Debian. live well, vagrant signature.asc Description: PGP signature
bug#44675: guix lint: support for spellchecker or basic grammar
On 2021-10-24, Vagrant Cascadian wrote: > On 2021-10-24, zimoun wrote: >> On Sun, 24 Oct 2021 at 04:22, Vagrant Cascadian wrote: >>> "This packages", "This modules", "allows to" and "permits to" in package >>> descriptions. >>> * tests/lint.scm: Add tests for "This packages" and "allows to". >>> --- >>> guix/lint.scm | 19 +++ >>> tests/lint.scm | 14 ++ >>> 2 files changed, 33 insertions(+) >> >> Otherwise, LGTM. > > Shall I fix the above typo (the irony!) and push before we get any more > of these typos in the repository? :) Pushed to master as b5f45a21c27b80210753e184e52708bb75a347bb. Thanks for all your help! live well, vagrant signature.asc Description: PGP signature
bug#44675: guix lint: support for spellchecker or basic grammar
On 2021-10-24, zimoun wrote: > On Sun, 24 Oct 2021 at 04:22, Vagrant Cascadian wrote: >> From a171769da0f737468e06866164eadf1e720764ba Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Sun, 24 Oct 2021 04:00:15 -0700 >> Subject: [PATCH] lint: Add description check for common typos. >> >> Fixes: https://issues.guix.gnu.org/44675 >> >> * guix/lint.scm (check-description-typo): Add check for occurances of > ^^ > > Occurrence, no? Well, maybe a US vs UK vs French-glish. :-) You are correct! French-glish FTW! :) >> "This packages", "This modules", "allows to" and "permits to" in package >> descriptions. >> * tests/lint.scm: Add tests for "This packages" and "allows to". >> --- >> guix/lint.scm | 19 +++ >> tests/lint.scm | 14 ++ >> 2 files changed, 33 insertions(+) > > Otherwise, LGTM. Shall I fix the above typo (the irony!) and push before we get any more of these typos in the repository? :) live well, vagrant signature.asc Description: PGP signature
bug#44675: guix lint: support for spellchecker or basic grammar
On 2021-10-22, zimoun wrote:
> On Thu, 21 Oct 2021 at 16:18, Vagrant Cascadian wrote:
>
>> It has been rewritten to easily add new typo checks, but this one so far
>> only addresses pluralized "This packages". Would be easy enough to add
>> "allows to" but hard to add a suggested fix...
>
> If I remember correctly the previous discussion, Debian uses an external
> tool for spellchecking. Here, the patch uses a list of “common”
> mistakes. It is seems an easy good start. :-)
Yes, I definitely went for "catch some useful things" rather than trying
to be comprehensive... these checks should catch the majority of
historical ones I've noticed, but I didn't bother adding one-off typos.
> Instead, I would use a list of alist ’typo-corrections’ as argument.
> For instance,
>
> --8<---cut here---start->8---
> (define (check-description-typo description typo-corrections)
> (for-each
>(match-lambda
> ((typo . correction)
> (if (string-contains description typo)
> (list
>(make-warning ...))
> '(
>typo-corrections))
> --8<---cut here---end--->8---
So close! Ludo spotted that the for-each needed to be replaced with
append-map, and that basically did it!
> (check-description-typo description '(("This packages" . "This
> package")))
>
> which allows easily to add new pattern; such as,
>
> '(("This packages" . "This package")
> ("this packages" . "this package")
> ("This modules" . "This module"))
>
> Then, as a second step, depending on the patterns listed, let see if
> there is a pattern inside these patterns. ;-) (Check both capitalize and
> lower-case, etc.)
I haven't seen case issues in practice for these.
I've added "This packages", "This modules", "allows to" and "permits to"
to the list while I was at it. I only added tests for "This packages"
and "allows to" as the others are so similar I'm not sure it's worth
testing...
Here's to hoping for a guix with fewer glaring typos with which to craft
guix poetry. :)
New patch attached!
live well,
vagrant
From a171769da0f737468e06866164eadf1e720764ba Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Sun, 24 Oct 2021 04:00:15 -0700
Subject: [PATCH] lint: Add description check for common typos.
Fixes: https://issues.guix.gnu.org/44675
* guix/lint.scm (check-description-typo): Add check for occurances of
"This packages", "This modules", "allows to" and "permits to" in package
descriptions.
* tests/lint.scm: Add tests for "This packages" and "allows to".
---
guix/lint.scm | 19 +++
tests/lint.scm | 14 ++
2 files changed, 33 insertions(+)
diff --git a/guix/lint.scm b/guix/lint.scm
index 7b02b9cec0..ac2e7b3841 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -321,6 +321,21 @@ markup is valid return a plain-text version of DESCRIPTION, otherwise #f."
(G_ "Texinfo markup in description is invalid")
#:field 'description
+ (define (check-description-typo description typo-corrections)
+"Check that DESCRIPTION does not contain typo, with optional correction"
+(append-map
+ (match-lambda
+ ((typo . correction)
+ (if (string-contains description typo)
+ (list
+(make-warning package
+ (G_
+ (format #false
+ "description contains typo '~a'~@[, should be '~a'~]"
+ typo correction
+ '(
+ typo-corrections))
+
(define (check-trademarks description)
"Check that DESCRIPTION does not contain '™' or '®' characters. See
http://www.gnu.org/prep/standards/html_node/Trademarks.html.;
@@ -401,6 +416,10 @@ by two spaces; possible infraction~p at ~{~a~^, ~}")
(check-not-empty description)
(check-quotes description)
(check-trademarks description)
+ (check-description-typo description '(("This packages" . "This package")
+ ("This modules" . "This module")
+ ("allows to" . #f)
+ ("permits to" . #f)))
;; Use raw description for this because Texinfo rendering
;; automatically fixes end of sentence space.
(check-end-of-sentence-space description)
diff --git a/tests/lin
bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On 2021-10-21, Vagrant Cascadian wrote: > For the last couple years guix has been applying simple workarounds in > u-boot packages to disable the features that required openssl due to > GPL/openssl license incompatibilities. > > I made an attempt at updating guix to u-boot 2021.10, which seems to > have made openssl harder to workaround... many of the u-boot-BOARD > packages now require it, and the previous workarounds to disable openssl > in u-boot-tools seem ineffective. > > I see a few ways forward: > > * Dig deeper into figuring out how to disable the workarounds... > > * Refactor the code that uses openssl to use an alternate > implementation. Upstream would welcome the fixes, at least in > theory. Most promising candidate might be wolfssl, last I looked, but > it may miss some features. > > * Convince upstream u-boot to relicense relevent GPLed portions of code > with an openssl exception. Upstream is dubious about this being > practical, largely due to the sheer number of potential contributors > who would have to agree to it. * Disable substitutes for relevent packages. Technically correct as license incompatibility is only triggered on transmission of binary, though maybe missing something about the spirit of the GPL. live well, vagrant signature.asc Description: PGP signature
bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On 2021-10-22, Leo Famulari wrote: > On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote: >> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions >> which are GPLv2-only, so that's not as attractive of a way forward as >> one might hope for... > > What are other distros doing? Surely we can't be the only group > distributing u-boot? Both fedora and (recently) debian have openssl declared as a system library, invoking the GPL's system library exception... which I personally find at best to be a grey area workaround. I wouldn't be surprised if most distros simply ignore the issue entirely. Interestingly, today I was called in on a relevent discussion on the u-boot mailing list: https://lists.denx.de/pipermail/u-boot/2021-October/464529.html Though, it is *possible* that various u-boot-BOARD in some cases doesn't include any openssl code at all in the resulting binaries, but builds some tools used during the build process, that are then used to produce various cryptographic signatures in the build: https://lists.denx.de/pipermail/u-boot/2021-October/464533.html If that's true, it should be ok for various boards (though the possibility of openssl code getting linked in would be hard to catch). u-boot-tools would still need a viable workaround, though. live well, vagrant signature.asc Description: PGP signature
bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On 2019-03-08, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> I'm not sure where it would be appropriate to add more comments >> regarding the GPL/Openssl incompatibilities; e.g. if someone were to >> propose adding one of the u-boot targets that requires it, they might >> just go ahead and re-add the openssl input... > > There’s always a risk. I guess we’ll have to be careful when doing > reviews. > > In addition, we can add a ‘lint’ checker for this case, WDYT? > >> From ee613387c49ca60905e0a40af8af017828c8aec8 Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Thu, 7 Mar 2019 21:50:58 + >> Subject: [PATCH] gnu: u-boot: Remove openssl input. >> >> Fixes: https://bugs.gnu.org/34717 >> >> * gnu/packages/bootloaders (u-boot): Remove openssl from native-inputs. >> (u-boot-tools): Disable FIT_SIGNATURES in tests. > > Applied, thanks! For the last couple years guix has been applying simple workarounds in u-boot packages to disable the features that required openssl due to GPL/openssl license incompatibilities. I made an attempt at updating guix to u-boot 2021.10, which seems to have made openssl harder to workaround... many of the u-boot-BOARD packages now require it, and the previous workarounds to disable openssl in u-boot-tools seem ineffective. I see a few ways forward: * Dig deeper into figuring out how to disable the workarounds... * Refactor the code that uses openssl to use an alternate implementation. Upstream would welcome the fixes, at least in theory. Most promising candidate might be wolfssl, last I looked, but it may miss some features. * Convince upstream u-boot to relicense relevent GPLed portions of code with an openssl exception. Upstream is dubious about this being practical, largely due to the sheer number of potential contributors who would have to agree to it. * ??? While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions which are GPLv2-only, so that's not as attractive of a way forward as one might hope for... live well, vagrant signature.asc Description: PGP signature
bug#44675: guix lint: support for spellchecker or basic grammar
On 2021-06-09, Vagrant Cascadian wrote:
> There have been at least three newly added "This packages" since I
> submitted this patch, so wondering if we can at least get the simple
> case merged before getting too caught up in all the potential
> improvements?
And up until today, that list grew to 7! (fixed by
Long delayed updated patch ... I think it addresses almost all of the
issues brought up, and maybe introduces a few new ones!
It has been rewritten to easily add new typo checks, but this one so far
only addresses pluralized "This packages". Would be easy enough to add
"allows to" but hard to add a suggested fix...
Big thanks to rekado, vivien and nckx who helped via #guix IRC!
live well,
vagrant
From 3ab46ca7932614ab4c699512c2fbfa8207ffa964 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Thu, 21 Oct 2021 15:51:11 -0700
Subject: [PATCH] lint: Add description check for pluralized "This package"
Partial fix for: https://issues.guix.gnu.org/44675
* guix/lint.scm (check-description-typo): Add check for
occurances of "This packages" in package descriptions.
* tests/lint.scm: Add test.
---
guix/lint.scm | 12
tests/lint.scm | 7 +++
2 files changed, 19 insertions(+)
diff --git a/guix/lint.scm b/guix/lint.scm
index 7b02b9cec0..b22454fd31 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -321,6 +321,17 @@ markup is valid return a plain-text version of DESCRIPTION, otherwise #f."
(G_ "Texinfo markup in description is invalid")
#:field 'description
+ (define (check-description-typo description typo correction)
+"Check that DESCRIPTION does not contain typo, with optional correction"
+(if (string-contains description typo)
+(list
+ (make-warning package
+ (G_
+(format #false
+"description contains typo '~a'~@[, should be '~a'~]"
+ typo correction
+'()))
+
(define (check-trademarks description)
"Check that DESCRIPTION does not contain '™' or '®' characters. See
http://www.gnu.org/prep/standards/html_node/Trademarks.html.;
@@ -401,6 +412,7 @@ by two spaces; possible infraction~p at ~{~a~^, ~}")
(check-not-empty description)
(check-quotes description)
(check-trademarks description)
+ (check-description-typo description "This packages" "This package")
;; Use raw description for this because Texinfo rendering
;; automatically fixes end of sentence space.
(check-end-of-sentence-space description)
diff --git a/tests/lint.scm b/tests/lint.scm
index 699a750eb9..1902a87354 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -177,6 +177,13 @@
(description "Whitespace. "
(check-description-style pkg
+(test-equal "description: pluralized 'This package'"
+ "description contains typo 'This packages', should be 'This package'"
+ (single-lint-warning-message
+ (let ((pkg (dummy-package "x"
+ (description "This packages is a typo."
+ (check-description-style pkg
+
(test-equal "synopsis: not a string"
"invalid synopsis: #f"
(single-lint-warning-message
--
2.30.2
signature.asc
Description: PGP signature
bug#49810: source tarballs potentially built for each derivation
On 2021-08-01, Vagrant Cascadian wrote: > Turning this conversation into a bug, original thread around here: > > https://lists.gnu.org/archive/html/guix-devel/2021-05/threads.html#00427 For reference: bug#49810: source tarballs potentially built for each derivation live well, vagrant signature.asc Description: PGP signature
bug#49810: source tarballs potentially built for each derivation
Turning this conversation into a bug, original thread around here:
https://lists.gnu.org/archive/html/guix-devel/2021-05/threads.html#00427
On 2021-05-29, Vagrant Cascadian wrote:
> On 2021-05-01, Leo Famulari wrote:
>> On Sat, May 01, 2021 at 06:45:32PM -0700, Vagrant Cascadian wrote:
>>> Pragmatically speaking, on slower platforms this is a huge resource
>>> overhead. So much so that ci.guix.gnu.org *usually* times out when
>>> generating the linux-libre aarch64 tarballs:
>>>
>>>
>>> https://ci.guix.gnu.org/search?query=system%3Aaarch64-linux+linux-libre-arm64-generic
>>
>> Thanks for letting me know. I didn't know this was happening.
>>
>> The immediate solution is for me to make sure the tarballs have built
>> before committing the updates. I already do this for x86_64 and I can
>> start doing it for aarch64 too.
>
> This has definitely helped sometimes, thanks! I even saw a substitute of
> linux-libre for aarch64 earlier today! :)
>
> Still, I'm noticing another problem with the way way the tarballs are
> generated on ci.guix.gnu.org ...
>
> When it generates a tarball, all the various packages independently try
> to recreate the source tarball; so you have at least fours jobs
> ("linux-libre", "linux-libre-arm64-generic", "linux-libre-headers",
> "linux-libre-bpf") all concurrently trying to build the very same
> very-slow-to-build tarball on ci.guix.gnu.org. Sometimes one of them
> might succeed, but the others may not, and even though one of them
> succeeded, none of the failing ones retry...
>
> Not knowing exactly how ci.guix.gnu.org works, would it make sense to
> create a tarball package instead of the ... computed origin(?) tarball,
> so it could be better represented in the package dependency graph, and
> the various linux-libre-* packages can wait till it is available rather
> than all trying to recreate the same thing?
>
> That still requires the tarball generation to not time out in the first
> place, but maybe it would help with the resource limitations a bit to
> only build the source tarball once per architecture?
This seems to still be an issue for ci.guix.gnu.org, but the
linux-libre* substitutes for aarch64 seem to be available on
https://bordeaux.guix.gnu.org ...
$ guix weather linux-libre linux-libre-arm64-generic
computing 2 package derivations for aarch64-linux...
looking for 2 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
0.0% substitutes available (0 out of 2)
unknown substitute sizes
0.0 MiB on disk (uncompressed)
0.740 seconds per request (0.7 seconds in total)
1.4 requests per second
0.0% (0 out of 2) of the missing items are queued
1 queued builds
aarch64-linux: 1 (100.0%)
build rate: .00 builds per hour
x86_64-linux: 0.00 builds per hour
aarch64-linux: 0.00 builds per hour
i686-linux: 0.00 builds per hour
looking for 2 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org
100.0% substitutes available (2 out of 2)
83.9 MiB of nars (compressed)
202.2 MiB on disk (uncompressed)
(continuous integration information unavailable)
live well,
vagrant
signature.asc
Description: PGP signature
bug#49550: Enable to boot from emmc on rockpro64
On 2021-07-13, Pierre Langlois wrote:
> I'm afraid since commit 3a851d45576e046d696fcf35b34d57b2cd28ea49 [0]
> I've not been able to boot from eMMC on the rockpro64 board, it freezes
> before loading the kernel. Re-introducing the work-around fixed the
> issue for me (see patch attached).
>
> Did we mean to remove the work-around? I'm wondering if there's
> something I'm missing, or if I should instead boot from a USB device.
I definitely tested this on pinebook-pro and probably just assumed it
would also fix the issue on rockpro64...
> I've also updated u-boot to 2021.07 but I'm seeing the same boot issue
> so it doesn't appear to be fixed upstream :-/
>
> Anybody know of any other work around? If not, are you happy with the
> patch attached?
I'll try to test on rockpro64 and see if I can confirm the issue and
your fix...
live well,
vagrant
> From f3c647bb447706f465a3fb4b8d6e09cd089dbed9 Mon Sep 17 00:00:00 2001
> From: Pierre Langlois
> Date: Sat, 8 May 2021 16:19:23 +0100
> Subject: [PATCH 1/3] gnu: u-boot-rockpro64-rk3399: Disable USB boot.
>
> * gnu/packages/bootloaders.scm (u-boot-rockpro64-rk3399)[arguments]: Add
> 'patch-rockpro64-config phase.
> ---
> gnu/packages/bootloaders.scm | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
> index 742992a119..75705a27c1 100644
> --- a/gnu/packages/bootloaders.scm
> +++ b/gnu/packages/bootloaders.scm
> @@ -12,7 +12,7 @@
> ;;; Copyright © 2019 Mathieu Othacehe
> ;;; Copyright © 2020 Björn Höfling
> ;;; Copyright © 2018, 2019, 2020 Vagrant Cascadian
> -;;; Copyright © 2020 Pierre Langlois
> +;;; Copyright © 2020, 2021 Pierre Langlois
> ;;; Copyright © 2021 Vincent Legoll
> ;;; Copyright © 2021 Brice Waegeneire
> ;;;
> @@ -931,11 +931,16 @@ to Novena upstream, does not load u-boot.img from the
> first partition.")
> (substitute-keyword-arguments (package-arguments base)
>((#:phases phases)
> `(modify-phases ,phases
> + (add-after 'unpack 'patch-rockpro64-config
> +;; Fix regression in 2020.10 causing freezes on boot with
> USB boot enabled.
> +;; See
> https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-rockpro64/-/issues/4
> +(lambda _
> + (substitute* "configs/rockpro64-rk3399_defconfig"
> +(("CONFIG_USE_PREBOOT=y") "CONFIG_USE_PREBOOT=n"
>(add-after 'patch-rockpro64-config 'set-environment
> (lambda* (#:key inputs #:allow-other-keys)
>(setenv "BL31" (string-append (assoc-ref inputs "firmware")
> -"/bl31.elf"))
> - #t))
> +"/bl31.elf"
>;; Phases do not succeed on the bl31 ELF.
>(delete 'strip)
>(delete 'validate-runpath)
> --
> 2.32.0
>
>
>
> [0]: https://lists.gnu.org/archive/html/guix-commits/2021-05/msg00085.html
signature.asc
Description: PGP signature
bug#44675: guix lint: support for spellchecker or basic grammar
On 2021-05-04, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> From 4e724fbe9815e1c27967b835f08d2259164538ba Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Wed, 21 Apr 2021 09:26:45 -0700 >> Subject: [PATCH] lint: Add description check for pluralized "This package" >> >> Partial fix for: https://issues.guix.gnu.org/44675 >> >> * guix/lint.scm (check-pluralized-this-package): Add check for >> occurances of "This packages" in package descriptions. >> * tests/lint.scm: Add test. > > I had missed this patch, nice! > >> + (define (check-pluralized-this-package description) >> +"Check that DESCRIPTION does not contain 'This packages'" >> +(if (string-match "This packages" description) >> +(list >> + (make-warning package >> + (G_ "description contains 'This packages' but should >> just be 'This package'"))) >> +'())) > > How about making this ‘check-spelling’ and generalizing a bit so that it > iterates over a bunch of regexps or strings? > > Like: > > (if (any (cut string-contains description <>) patterns) > …) > > where ‘patterns’ is a list of strings. Love the idea, but would need some help in implementing! There have been at least three newly added "This packages" since I submitted this patch, so wondering if we can at least get the simple case merged before getting too caught up in all the potential improvements? > (Note that ‘string-match’ invokes libc’s regcomp + regexec, so it’s more > heavyweight than needed here.) I can probably manage that! (I'll dig up where the simpler suggestion was) live well, vagrant signature.asc Description: PGP signature
bug#48172: support split /boot partition
On 2021-05-02, Vagrant Cascadian wrote: > Unfortunately, guix doesn't currently support booting off of a separate > /boot partition, since the kernel and initrd are in /gnu/store; your > bootloader needs to be able to mount the partition that /gnu/store is > located on. > > The workaround would be to manually copy all files mentioned in grub.cfg > (kernel, initrd, possibly others) into a partition somewhere on boot > media, and tweak the grub.cfg appropriately... > > > There are several cases where this sort of thing would be desireable: > > * The above scenario; the system does not expose an NVMe drive from EFI > or BIOS. > > * Using u-boot and you want root on lvm, raid, encryption, etc. which > u-boot does not support * Using luks1 format for /boot and luks2 format for / (unless grub2 learns how to read luks2 already/soon) live well, vagrant signature.asc Description: PGP signature
bug#48405: Test suite failures on IPv6 only machines
When building guix on Debian's buildd infrastructure, some of the test suites fail when building on machines that only have IPv6: https://buildd.debian.org/status/logs.php?pkg=guix=amd64 In this case, the machine "x86-conova-01" is the only one that fails to build, and one of the main differences from other machines may be that it is IPv6 only. The specific build logs for the failures appear here: https://buildd.debian.org/status/fetch.php?pkg=guix=amd64=1.3.0-1=1620886911=0 https://buildd.debian.org/status/fetch.php?pkg=guix=amd64=1.2.0-1=1606172126=0 https://buildd.debian.org/status/fetch.php?pkg=guix=amd64=1.2.0%7Erc2-1=1605882853=0 This may be related to use of AI_ADDRCONFIG with getaddrinfo: https://lists.debian.org/debian-devel/2020/07/msg00070.html I haven't yet figured out how to reproduce an environment in which this fails consistently; maybe reproducing it in a guix container would be possible? live well, vagrant signature.asc Description: PGP signature
bug#48266: support dynamic loading of modules from initrd
On 2021-05-11, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Initially, I tried adding just the obviously mmc related modules, but >> this gave me guile prompt from the initramfs as it failed to find the >> rootfs. Notably, even with the above list, I still need to explore >> additional modules to load in order to get the display and keyboard to >> work from the initramfs, in case I wanted to use this with encrypted >> rootfs... >> >> The above list of modules could almost certainly be trimmed, but even >> getting a bootable system for pinebook pro took about 20 tries, and the >> process of defining the modules is further complicated by several >> factors... >> >> * The filesystem names of the modules (e.g. dw_mmc-pltfm) do not >> necessarily match the runtime name from lsmod (e.g. dw_mmc_pltfm). >> This becomes a good deal of trial and error to figure out which >> modules to add. >> >> * One needs to manually resolve the soft and hard dependencies of the >> modules, and ensure they are loaded, and include them in the list. >> >> * If upstream changes the module name (which does happen from time to >> time), you have to update the system config.scm to the new module >> names. >> >> * If some functionality changes from a module to a built-in, or >> vice-versa, the system config.scm needs manual updating. >> >> * Switching system between two different arm boards potentially requires >> entirely different lists of modules. > > Note that ‘guix system init’, ‘reconfigure’, and ‘deploy’ error out if > drivers for a storage device are missing (see > ‘check-device-initrd-modules’). Yes, I often have to tell it to skip those checks when using 'guix system init', as I'm installing to a microSD card by way of a usb-to-microSD adapter, and it guesses all the wrong modules. > Now, that doesn’t help if you’re using ‘guix system image’, which > perhaps is what you were doing? I wonder how we could take advantage of > that code in such a scenario. I sometimes do 'guix system image' for the initial pass, and then follow-up with init or reconfigure... >> Rather than handling modules one at a time, I would propose to at least >> add an option that can add whole directory trees of modules to the >> initrd (e.g. kernel/drivers/usb/)... and then use modprobe (or udev?) >> to handle the dependencies. Maybe opt-in at first, but longer-term, >> explore making it default? > > I remember Danny and I worked on something along these lines in the past > but it didn’t completely materialize (some of the machinery is already > here, though). That said, we still wouldn’t want to include too much in > the initrd, would we? Notably, at the moment it loads various virtio modules on all my baremetal systems, which is a bit uneccesary. :) Honestly, when debugging support for a new arm system, I'm of the opinion that more is better than less, as it takes way too many iterations to get to a working modular configuration. So at least an option to include even the kitchen sink drivers would be nice. :) live well, vagrant signature.asc Description: PGP signature
bug#48327: guix system image uses cross-compiler even on native system
I tried building a pinebook-pro image on an aarch64-linux Guix System... $ uname -a Linux myhostname 5.12.2-gnu #1 SMP 1 aarch64 GNU/Linux $ guix system image ./gnu/system/images/pinebook-pro.scm substitute: updating substitutes from 'http://mycachingproxy/ci'... 100.0% The following derivations will be built: /gnu/store/n2mmyxi710aqbicq6p4nilma56nbpp3b-net-tools-1.60-0.479bb4a.drv /gnu/store/5f7hz1bbz3m7cxiv529qyw5arqp687j5-gcc-cross-aarch64-linux-gnu-7.5.0.drv /gnu/store/ca3ki1nw3abmx4phg5aqbyvk9pw9v8j4-linux-libre-headers-cross-aarch64-linux-gnu-5.4.20.drv /gnu/store/vdl9l45257m1glbmmqcrwdy2brb96kg4-gcc-cross-sans-libc-aarch64-linux-gnu-7.5.0.drv /gnu/store/jik876a99dvxdky5jv8ghj316knfjfyj-glibc-cross-aarch64-linux-gnu-2.31.drv ... But I'm building this on an aarch64 system; it shouldn't need to use an aarch64-linux-gnu cross-compiler on an aarch64-linux system! It would be nice if it could build images natively, too. :) live well, vagrant signature.asc Description: PGP signature
bug#48323: guix-daemon.service and guix-publish.service use deprecated StandardError/StandardOutput features
Both guix-daemon.service and guix-publish.service make use of StandardError=syslog and StandardOutput=syslog. When building a guix 1.2.0 or 1.3.0rc* on Debian, I get the following warnings when checking with lintian: W: guix: systemd-service-file-uses-deprecated-syslog-facility lib/systemd/system/guix-daemon.service StandardError=syslog N: W: systemd-service-file-uses-deprecated-syslog-facility N: N: The specified systemd service file specifies StandardOutput= or N: StandardError= that references syslog or syslog-console. N: N: This is discouraged, and systemd versions 246 and above will log a N: warning about this. N: N: Refer to N: https://github.com/systemd/systemd/blob/6706384a89ae0c462e7172588c80667190c4d9e2/NEWS#L724 N: for details. N: N: Severity: warning N: N: Check: systemd Following the above link has this to say: * StandardError= and StandardOutput= in unit files no longer support the "syslog" and "syslog-console" switches. They were long removed from the documentation, but will now result in warnings when used, and be converted to "journal" and "journal+console" automatically. So apparently need to switch the .service files to use "journal". I am not sure what implications that would have for installing guix on a foreign distro, such as minimum systemd version, or if anything needs significant changes. Presumably at some point support for this Standard*=syslog will be dropped entirely from systemd... live well, vagrant signature.asc Description: PGP signature
bug#48266: support dynamic loading of modules from initrd
There should be an option to support dynamic loading of modules from the initrd. I recently pushed some changes to use the "linux-libre" kernel with pinebook pro: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d330d63a29f35ebcbebce19b13d49c69d38a5815 But in order to even boot, I need to add a lot of modules to initrd-modules: (initrd-modules (append (list "rtc-rk808" "dw_mmc" "dw_mmc-pltfm" "dw_mmc-rockchip" "joydev" "bluetooth" "jitterentropy_rng" "hid_generic" "videodev" "ghash_ce" "gf128mul" "ansi_cprng" "mc" "sha2_ce" "usbhid" "panfrost" "ecdh_generic" ;; "fusb302" "ofpart" ;; "tcpm" "hid" "ecc" "evdev" "leds_gpio" "io_domain" "dw_wdt" ;; "rockchip-thermal" "cw2015_battery" "pwm-rockchip" ;; "gpio_charger" "cpufreq_dt" "configfs" "xhci-plat-hcd" "xhci-hcd" "rk808-regulator" "clk-rk808" "udc-core" "ulpi" "fan53555" "rk808" "pwm-regulator" "fixed" "gpio_keys" "cec" ;; "phy-rockchip-typec" "phy-rockchip-emmc" "phy-rockchip-inno-usb2" ;; "analogix-dp" "sdhci-of-arasan" "sdhci-pltfm" "cqhci" "drm_kms_helper" "ohci-platform" "ohci-hcd" "ehci-platform" "panel-simple" "ehci-hcd" "sdhci" "drm" "i2c-rk3x" "usbcore" "pl330" "pwm_bl" "dwc3" ) %base-initrd-modules)) Initially, I tried adding just the obviously mmc related modules, but this gave me guile prompt from the initramfs as it failed to find the rootfs. Notably, even with the above list, I still need to explore additional modules to load in order to get the display and keyboard to work from the initramfs, in case I wanted to use this with encrypted rootfs... The above list of modules could almost certainly be trimmed, but even getting a bootable system for pinebook pro took about 20 tries, and the process of defining the modules is further complicated by several factors... * The filesystem names of the modules (e.g. dw_mmc-pltfm) do not necessarily match the runtime name from lsmod (e.g. dw_mmc_pltfm). This becomes a good deal of trial and error to figure out which modules to add. * One needs to manually resolve the soft and hard dependencies of the modules, and ensure they are loaded, and include them in the list. * If upstream changes the module name (which does happen from time to time), you have to update the system config.scm to the new module names. * If some functionality changes from a module to a built-in, or vice-versa, the system config.scm needs manual updating. * Switching system between two different arm boards potentially requires entirely different lists of modules. Rather than handling modules one at a time, I would propose to at least add an option that can add whole directory trees of modules to the initrd (e.g. kernel/drivers/usb/)... and then use modprobe (or udev?) to handle the dependencies. Maybe opt-in at first, but longer-term, explore making it default? In Debian, adding modules to the intird is done in initramfs-tools: https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/f350f122a244c60f91a3e3e5f8b58f9cb75308b6/hook-functions#L599 As for which modules to load at runtime, initramfs-tools uses udev; maybe that could be integrated into the guix initramfs as an option? Obviously, adding more modules than a strict bare minimum to the initrd will increase boot times a bit, and adding further dependencies (modprobe, udev) to the initrd will add to that even more, but the current hard-coded list of modules to load, that you can extend with another hard-coded list, is a bit painful when trying to get a new system working... Maybe the Guix way to do this is to write some guile code that can generate the list of modules to include in the initrd at build time? But that still doesn't resolve the dynamic loading of modules at runtime, and it would be impractical to load *all* the modules at runtime... and maybe impractical to re-implement modprobe and/or udev in guile? Well, thanks for considering! live well, vagrant signature.asc Description: PGP signature
bug#46038: guix 1.3.0rc1 test failure: channels-news, one entry
On 2021-05-04, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> On 2021-01-22, Vagrant Cascadian wrote:
>>> I've uploaded guix 1.2.0 built against guile-2.2 to Debian, and while it
>>> builds fine on the official buildd.debian.org infrastructure, on amd64
>>> and arm64 the "channel-news, one entry" test from tests/channels.scm
>>> fails on tests.reproducible-builds.org.
>>>
>>> There are likely a few differences in the two build environments,
>>> possibly including network access.
>>>
>>> Does the "channel-news, one entry" test indirectly depend on network or
>>> bootstrap binaries?
>>>
>>> Could a difference in locale related variables affect the result of the
>>> test (e.g. LANGUAGE=en:en_US vs. LANGUAGE unset, LC_ALL unset
>>> vs. LC_ALL=C or LC_ALL=C.UTF-8)?
>>>
>>>
>>> https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/guix.html
>>
>> Still basically the same story with 1.3.0rc1, in some cases this test
>> fails, but I haven't consistently figured out what triggers it.
>>
>>
>>> test-name: channel-news, one entry
>>> location: /build/1st/guix-1.2.0/tests/channels.scm:324
>>> source:
>
> [...]
>
>>> + (lset= equal?
>>> + (map channel-news-entry-title
>>> + (channel-news-for-commit channel commit5))
>>> + '((("en" . "Another file!"))
>>> + (("en" . "Old news.") ("eo" . "Malnova?oj."
>
> The culprit is right here: it should read “Malnovaĵoj”, but there’s a
> question mark instead of ‘ĵ’.
>
> Could it be that you’re not running tests in a UTF-8 locale?
Thanks for taking a deeper look!
Yes, on tests.reproducible-builds.org, one build is run in the C locale,
the other in various UTF-8 locales (somewhat arbitrarily tied to
architecture exactly which UTF-8 locale is used). I'm guessing
buildd.debian.org use C.UTF-8, since it builds fine there.
So now the question is what to do; should tests be able to assume a
UTF-8 locale?
Should I try to adapt the test to work in C?
Should I workaround it in the Debian packaging by forcing to use a UTF-8
locale (on Debian, the only one definitely available is C.UTF-8, which
isn't in upstream glibc, and thus not in guix itself).
live well,
vagrant
signature.asc
Description: PGP signature
bug#48131: build failure: 1.3.0rc1 on Debian i386 with guile-2.2
On 2021-05-02, Vagrant Cascadian wrote: > On 2021-05-02, Ludovic Courtès wrote: >> Vagrant Cascadian skribis: >>> On 2021-04-30, Vagrant Cascadian wrote: >>>> I've been unable to build version 1.3.0rc1 for i386 on Debian: >>>> >>>> [ 70%] GUILEC gnu/packages/direct-connect.go >>>> [ 70%] GUILEC gnu/packages/disk.go >>>> GC Warning: Failed to expand heap by 8388608 bytes >>>> GC Warning: Failed to expand heap by 8388608 bytes >>>> ... >>>> GC Warning: Failed to expand heap by 8388608 bytes >>>> GC Warning: Failed to expand heap by 8388608 bytes >>>> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS >>>> make[3]: *** [Makefile:6871: make-go] Aborted >>>> >>>> >>>> Debian is still using guile-2.2, so I'm guessing this is not a >>>> particularly well tested codepath anymore... >>> >>> But strangely enough, it built fine on debian's build machines on all >>> supported architectures: >>> >>> https://buildd.debian.org/status/package.php?p=guix=experimental >> >> Guile 3.0’s compiler with ‘-O1’ (which is what we use for package files) >> uses much less memory than 2.2¹. The amount of memory may also be a >> function of the number of threads used (‘-j’). So it could be that the >> build failed on a machine with less memory or more cores. > > The machine it failed on had 32 cores and 140GB of ram... but will > experiment with reducing parallelism on that machine and see if that > helps. I just realized that the Debian guix packages are built with parallelism disabled for reproducible builds, so that seems unlikely to be the issue... it might just be an issue with guile-2.2 on Debian... live well, vagrant signature.asc Description: PGP signature
bug#48131: build failure: 1.3.0rc1 on Debian i386 with guile-2.2
On 2021-05-02, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> On 2021-04-30, Vagrant Cascadian wrote: >>> I've been unable to build version 1.3.0rc1 for i386 on Debian: >>> >>> [ 70%] GUILEC gnu/packages/direct-connect.go >>> [ 70%] GUILEC gnu/packages/disk.go >>> GC Warning: Failed to expand heap by 8388608 bytes >>> GC Warning: Failed to expand heap by 8388608 bytes >>> ... >>> GC Warning: Failed to expand heap by 8388608 bytes >>> GC Warning: Failed to expand heap by 8388608 bytes >>> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS >>> make[3]: *** [Makefile:6871: make-go] Aborted >>> >>> >>> Debian is still using guile-2.2, so I'm guessing this is not a >>> particularly well tested codepath anymore... >> >> But strangely enough, it built fine on debian's build machines on all >> supported architectures: >> >> https://buildd.debian.org/status/package.php?p=guix=experimental > > Guile 3.0’s compiler with ‘-O1’ (which is what we use for package files) > uses much less memory than 2.2¹. The amount of memory may also be a > function of the number of threads used (‘-j’). So it could be that the > build failed on a machine with less memory or more cores. The machine it failed on had 32 cores and 140GB of ram... but will experiment with reducing parallelism on that machine and see if that helps. The buildd.debian.org machine used only four cores, not sure how much ram it had. live well, vagrant signature.asc Description: PGP signature
bug#46038: guix 1.3.0rc1 test failure: channels-news, one entry
On 2021-01-22, Vagrant Cascadian wrote: > I've uploaded guix 1.2.0 built against guile-2.2 to Debian, and while it > builds fine on the official buildd.debian.org infrastructure, on amd64 > and arm64 the "channel-news, one entry" test from tests/channels.scm > fails on tests.reproducible-builds.org. > > There are likely a few differences in the two build environments, > possibly including network access. > > Does the "channel-news, one entry" test indirectly depend on network or > bootstrap binaries? > > Could a difference in locale related variables affect the result of the > test (e.g. LANGUAGE=en:en_US vs. LANGUAGE unset, LC_ALL unset > vs. LC_ALL=C or LC_ALL=C.UTF-8)? > > > https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/guix.html Still basically the same story with 1.3.0rc1, in some cases this test fails, but I haven't consistently figured out what triggers it. > test-name: channel-news, one entry > location: /build/1st/guix-1.2.0/tests/channels.scm:324 > source: > + (test-assert > + "channel-news, one entry" > + (with-temporary-git-repository > + directory > + `((add ".guix-channel" > +,(object->string > + '(channel (version 0) (news-file "news.scm" > + (commit "first commit") > + (add "src/a.txt" "A") > + (commit "second commit") > + (tag "tag-for-first-news-entry") > + (add "news.scm" > +,(lambda (repository) > + (let ((previous > + (reference-name->oid repository "HEAD"))) > + (object->string > + `(channel-news > + (version 0) > + (entry (commit ,(oid->string previous)) > + (title (en "New file!") (eo "Nova dosiero!")) > + (body (en "Yeah, a.txt." > + (commit "third commit") > + (add "src/b.txt" "B") > + (commit "fourth commit") > + (add hint: Using 'master' as the name for the initial branch. This > default branch name > hint: is subject to change. To configure the initial branch name to use in all > hint: of your new repositories, which will suppress this warning, call: > hint: > hint: git config --global init.defaultBranch > hint: > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and > hint: 'development'. The just-created branch can be renamed via this command: > hint: > hint: git branch -m > Initialized empty Git repository in /tmp/guix-directory.6SfxEu/.git/ > [master (root-commit) 8b5d0e8] first commit > 1 file changed, 1 insertion(+) > create mode 100644 .guix-channel > [master b8dd467] second commit > 1 file changed, 1 insertion(+) > create mode 100644 src/a.txt > [master 324d7bc] third commit > 1 file changed, 1 insertion(+) > create mode 100644 news.scm > [master 2cd62e1] fourth commit > 1 file changed, 1 insertion(+) > create mode 100644 src/b.txt > [master d0e63c3] fifth commit > 1 file changed, 1 insertion(+), 1 deletion(-) > hint: Using 'master' as the name for the initial branch. This default branch > name > hint: is subject to change. To configure the initial branch name to use in all > hint: of your new repositories, which will suppress this warning, call: > hint: > hint: git config --global init.defaultBranch > hint: > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and > hint: 'development'. The just-created branch can be renamed via this command: > hint: > hint: git branch -m > Initialized empty Git repository in /tmp/guix-directory.M2UpCv/.git/ > [master (root-commit) f84a5c3] first commit > 1 file changed, 1 insertion(+) > create mode 100644 a.txt > [master b1e63da] second commit > 1 file changed, 1 insertion(+) > create mode 100644 b.scm > "news.scm" > +,(lambda (repository) > + (let ((second > + (commit-id > + (find-commit repository "second commit"))) > + (previous > + (reference-name->oid repository "HEAD"))) > + (object->string > + `(channel-news > + (version 0) > + (entry (commit ,(oid->string previous)) > + (title (en "Another file!")) > + (body (en "
bug#48131: build failure: 1.3.0rc1 on Debian i386 with guile-2.2
On 2021-04-30, Vagrant Cascadian wrote: > I've been unable to build version 1.3.0rc1 for i386 on Debian: > > [ 70%] GUILEC gnu/packages/direct-connect.go > [ 70%] GUILEC gnu/packages/disk.go > GC Warning: Failed to expand heap by 8388608 bytes > GC Warning: Failed to expand heap by 8388608 bytes > ... > GC Warning: Failed to expand heap by 8388608 bytes > GC Warning: Failed to expand heap by 8388608 bytes > Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS > make[3]: *** [Makefile:6871: make-go] Aborted > > > Debian is still using guile-2.2, so I'm guessing this is not a > particularly well tested codepath anymore... But strangely enough, it built fine on debian's build machines on all supported architectures: https://buildd.debian.org/status/package.php?p=guix=experimental *shrug* live well, vagrant signature.asc Description: PGP signature
bug#48131: build failure: 1.3.0rc1 on Debian i386 with guile-2.2
I've been unable to build version 1.3.0rc1 for i386 on Debian: [ 70%] GUILEC gnu/packages/direct-connect.go [ 70%] GUILEC gnu/packages/disk.go GC Warning: Failed to expand heap by 8388608 bytes GC Warning: Failed to expand heap by 8388608 bytes ... GC Warning: Failed to expand heap by 8388608 bytes GC Warning: Failed to expand heap by 8388608 bytes Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS make[3]: *** [Makefile:6871: make-go] Aborted Debian is still using guile-2.2, so I'm guessing this is not a particularly well tested codepath anymore... live well, vagrant signature.asc Description: PGP signature
bug#48050: Pinebook Pro LCD and Audio support
On 2021-04-26, Vagrant Cascadian wrote: > On 2021-04-26, Vagrant Cascadian wrote: >> The attached patch enables support for LCD display and limited audio >> support for pinebook-pro-rk3399. > > Updated patch which adds battery support too. Fixed in linux-libre@5.11 and linux-libre@5.10, pushed to master. d018a11ee065e0f6bafb33fcc1a130aa7900b5a3 gnu: linux-libre-arm64-generic@5.10: Add eDP panel, audio and battery support for Pinebook Pro. e7fbf10066e3634ec2d284c07afb4fa625d18574 gnu: linux-libre-arm64-generic: Add eDP panel, battery and audio support for Pinebook Pro. live well, vagrant signature.asc Description: PGP signature
bug#47978: guix/import/go.scm: Dependency on guile-lib >= 0.2.7
On 2021-04-28, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> When building guix (with commit cb3f9696f6251ad382febad33290fed929c176b4 >> from branch version-1.3.0) on Debian, it fails with the following error >> with guile-library (a.k.a. guile-lib) version 0.2.6.1-2: >> >> ice-9/eval.scm:293:34: error: %strict-tokenizer?: unbound variable >> hint: Did you forget a `use-modules' form? >> >> [ 10%] LOAD guix/import/go.scm >> ;;; Failed to autoload semver-range-contains? in (semver ranges): >> ;;; missing interface for module (semver ranges) >> ... >> ;;; Failed to autoload semver> ;;; missing interface for module (semver) >> ice-9/eval.scm:293:34: error: %strict-tokenizer?: unbound variable >> hint: Did you forget a `use-modules' form? >> >> >> Installing guile-library version 0.2.7 works fine. > > 34db952a4b655cca9d5dc7158e9a8552d389cbcf fixes it by making Guile-Lib a > “soft” dependency as was intended. But yes, 0.2.7 is required if you > want to use ‘guix import go’. Makes sense. Some (e.g. guile-ssh) of the "optional" dependencies are or were similarly required to build guix in the past ... I should probably file bugs when I encounter them, sounds like. :) live well, vagrant signature.asc Description: PGP signature
bug#48050: Pinebook Pro LCD and Audio support
On 2021-04-26, Vagrant Cascadian wrote:
> The attached patch enables support for LCD display and limited audio
> support for pinebook-pro-rk3399.
Updated patch which adds battery support too.
live well,
vagrant
From 4c2a728e1186367a4bdc5c4416d6d58eee13b0e7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Mon, 26 Apr 2021 09:27:50 -0700
Subject: [PATCH] gnu: linux-libre: Add LCD, battery and sound support for
Pinebook Pro.
* gnu/packages/linux.scm (linux-libre-5.11-source): Add Pinebook Pro
lcd patch.
(linux-libre-arm64-generic): Enable audio and battery modules for
Pinebook Pro.
* gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add patch.
---
gnu/local.mk | 1 +
gnu/packages/linux.scm| 11 -
...nux-libre-arm64-generic-pinebook-lcd.patch | 40 +++
3 files changed, 50 insertions(+), 2 deletions(-)
create mode 100644 gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index e8b6effb36..5a2ae6ef48 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1369,6 +1369,7 @@ dist_patch_DATA = \
%D%/packages/patches/linkchecker-tests-require-network.patch \
%D%/packages/patches/linphone-desktop-without-sdk.patch \
%D%/packages/patches/linux-libre-support-for-Pinebook-Pro.patch \
+ %D%/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch \
%D%/packages/patches/linux-pam-no-setfsuid.patch \
%D%/packages/patches/lirc-localstatedir.patch \
%D%/packages/patches/lirc-reproducible-build.patch \
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 080ffab527..bd79b40ca6 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -481,7 +481,10 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(define-public linux-libre-5.11-source
(source-with-patches linux-libre-5.11-pristine-source
(list %boot-logo-patch
- %linux-libre-arm-export-__sync_icache_dcache-patch)))
+ %linux-libre-arm-export-__sync_icache_dcache-patch
+ ;; Pinebook Pro patch to fix LCD display
+ (search-patch
+ "linux-libre-arm64-generic-pinebook-lcd.patch"
(define-public linux-libre-5.10-source
(source-with-patches linux-libre-5.10-pristine-source
@@ -1044,7 +1047,11 @@ It has been modified to remove all non-free binary blobs.")
("CONFIG_BATTERY_AXP20X" . m)
("CONFIG_PINCTRL_AXP209" . m)
("CONFIG_AXP20X_POWER" . m)
-("CONFIG_AXP20X_ADC" . m))
+("CONFIG_AXP20X_ADC" . m)
+;; Pinebook PRO battery and sound support
+("CONFIG_BATTERY_CW2015" . m)
+("CONFIG_CHARGER_GPIO" . m)
+("CONFIG_SND_SOC_ES8316" . m))
%default-extra-linux-options)))
(define-public linux-libre-arm64-generic-5.10
diff --git a/gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch b/gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch
new file mode 100644
index 00..51ab544d5e
--- /dev/null
+++ b/gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch
@@ -0,0 +1,40 @@
+From 3a75704e99a118f2d8a4d70f07781558bde85770 Mon Sep 17 00:00:00 2001
+From: Jian-Hong Pan
+Date: Thu, 24 Sep 2020 14:30:43 +0800
+Subject: [PATCH] arm64: dts: rockchip: disable USB type-c DisplayPort
+
+The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
+
+kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing extcon or phy
+kernel: cdn-dp: probe of fec0.dp failed with error -22
+
+Then, the device halts all of the DRM related device jobs. For example,
+the operations: vop_component_ops, vop_component_ops and
+rockchip_dp_component_ops cannot be bound to corresponding devices. So,
+Xorg cannot find the correct DRM device.
+
+The USB type-C DisplayPort does not work for now. So, disable the
+DisplayPort node until the type-C phy work has been done.
+
+Link: https://patchwork.kernel.org/patch/11794141/#23639877
+Signed-off-by: Jian-Hong Pan
+---
+ arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+index 219b7507a10f..45769764425d 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+@@ -380,7 +380,7 @@
+ };
+
+ _dp {
+- status = "okay";
++ status = "disabled";
+ };
+
+ _b0 {
+--
+2.30.2
+
--
2.30.2
signature.asc
Description: PGP signature
bug#48050: Pinebook Pro LCD and Audio support
Control: reassign 48050 guix-patches Reassigning to guix-patches. Unless this debbugs is all old-school and I have to send to instead cont...@debbugs.gnu.org ... will know shortly! live well, vagrant signature.asc Description: PGP signature
bug#48050: Pinebook Pro LCD and Audio support
The attached patch enables support for LCD display and limited audio
support for pinebook-pro-rk3399.
With this, the Pinebook Pro gets display output on the built-in LCD.
Console works, wayland works (tested with sway), presumably X.org would
work as well (untested).
Audio output on headphones kind of works.
Trackpad is still a little sketchy; might require enabling some more
modules.
This should basically obsolete the need for the wip-pinebook-pro branch;
I haven't noticed any significant functionality difference.
I believe the same patches and changes apply and work more-or-less
unchanged for linux-libre 5.10 lts series (I tested against Debian's
5.10.x kernel), and it might be worth having an LTS kernel with this
enabled. If that's considered desireable, I can update the patch to add
that too.
Since this will require rebuilding the linux-libre tarball, it is
probably best to wait to merge this until the next batch of linux-libre
updates (e.g. linux-libre 5.11.x and 5.10.x, no need to wait till 5.12).
If USB-C DisplayPort ever becomes supported and working on pinebook-pro,
this patch will need to be removed.
live well,
vagrant
From 478b620eb4f52e76bde691262ebc793e4e3fd384 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Mon, 26 Apr 2021 09:27:50 -0700
Subject: [PATCH] gnu: linux-libre: Add LCD and sound support for Pinebook Pro.
* gnu/packages/linux.scm (linux-libre-5.11-source): Add Pinebook Pro
lcd patch.
(linux-libre-arm64-generic): Enable audio module for Pinebook Pro.
* gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add patch.
---
gnu/local.mk | 1 +
gnu/packages/linux.scm| 9 -
...nux-libre-arm64-generic-pinebook-lcd.patch | 40 +++
3 files changed, 48 insertions(+), 2 deletions(-)
create mode 100644 gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index e8b6effb36..5a2ae6ef48 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1369,6 +1369,7 @@ dist_patch_DATA = \
%D%/packages/patches/linkchecker-tests-require-network.patch \
%D%/packages/patches/linphone-desktop-without-sdk.patch \
%D%/packages/patches/linux-libre-support-for-Pinebook-Pro.patch \
+ %D%/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch \
%D%/packages/patches/linux-pam-no-setfsuid.patch \
%D%/packages/patches/lirc-localstatedir.patch \
%D%/packages/patches/lirc-reproducible-build.patch \
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 080ffab527..1c6e1502b2 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -481,7 +481,10 @@ corresponding UPSTREAM-SOURCE (an origin), using the given DEBLOB-SCRIPTS."
(define-public linux-libre-5.11-source
(source-with-patches linux-libre-5.11-pristine-source
(list %boot-logo-patch
- %linux-libre-arm-export-__sync_icache_dcache-patch)))
+ %linux-libre-arm-export-__sync_icache_dcache-patch
+ ;; Pinebook Pro patch to fix LCD display
+ (search-patch
+ "linux-libre-arm64-generic-pinebook-lcd.patch"
(define-public linux-libre-5.10-source
(source-with-patches linux-libre-5.10-pristine-source
@@ -1044,7 +1047,9 @@ It has been modified to remove all non-free binary blobs.")
("CONFIG_BATTERY_AXP20X" . m)
("CONFIG_PINCTRL_AXP209" . m)
("CONFIG_AXP20X_POWER" . m)
-("CONFIG_AXP20X_ADC" . m))
+("CONFIG_AXP20X_ADC" . m)
+;; Pinebook PRO sound support
+("CONFIG_SND_SOC_ES8316" . m))
%default-extra-linux-options)))
(define-public linux-libre-arm64-generic-5.10
diff --git a/gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch b/gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch
new file mode 100644
index 00..51ab544d5e
--- /dev/null
+++ b/gnu/packages/patches/linux-libre-arm64-generic-pinebook-lcd.patch
@@ -0,0 +1,40 @@
+From 3a75704e99a118f2d8a4d70f07781558bde85770 Mon Sep 17 00:00:00 2001
+From: Jian-Hong Pan
+Date: Thu, 24 Sep 2020 14:30:43 +0800
+Subject: [PATCH] arm64: dts: rockchip: disable USB type-c DisplayPort
+
+The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
+
+kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing extcon or phy
+kernel: cdn-dp: probe of fec0.dp failed with error -22
+
+Then, the device halts all of the DRM related device jobs. For example,
+the operations: vop_component_ops, vop_component_ops and
+rockchip_dp_component_ops cannot be bound to corres
bug#44675: guix lint: support for spellchecker or basic grammar
On 2021-04-25, Efraim Flashner wrote: > On Wed, Apr 21, 2021 at 04:10:40PM -0700, Vagrant Cascadian wrote: >> Control: tags 44675 +patch >> >> On 2020-11-15, Vagrant Cascadian wrote: >> > Please consider a guix lint description/synopsis check for basic >> > spelling, typo and rudimentary grammar issues. >> ... >> > Many of these are likely to be caught by most spell checking routines; >> > I'm not sure if there is anything that would be implementable in pure >> > guile, or it if would make sense to call out to an external >> > spellchecker. >> > >> > Some of them might be harder, and obviously we do not want too many >> > false positives, but no need to get perfectionist on solving this; even >> > just checking for "This packages" would haved detected many of these >> > issues! >> >> In the attached patch, I've implemented a simple lint check for "This >> packages", which has been fixed in ... 42 packages so far in the git >> repository, so maybe this could help catch future ones! >> >> I haven't implemented a more complicated spellchecker or grammar checker >> or anything, but at least this is a start. >> >> I think it is also within my skills to address "allows to" and "permits >> to", if I'm not heading down the wrong path here... >> >> >> live well, >> vagrant > > It might make more sense to name it something more like > 'catch-common-typos' and to search for 'This packages', 'allows to', > 'permits to', 'file-name' and then print out the different mistakes in > the description. Then we can add more as we find them, rather than one > check per mistake. That makes sense, though 'This packages' is very straightforward and has a simple recommendation to fix it, whereas 'allows to' requires more complicated english skills to come up with the correct solution... it could just simply flag those cases as "wrong" without a solution. Basically, I already stretched my cargo-culting, er, guile skills just to get something obvious fixed that I keep seeing over and over again. It would be a good excercise for me to better learn guile to extend to further typos, though ... limited time. Playing whack-a-mole with typos does get tiring :) live well, vagrant signature.asc Description: PGP signature
bug#47978: guix/import/go.scm: Dependency on guile-lib >= 0.2.7
When building guix (with commit cb3f9696f6251ad382febad33290fed929c176b4 from branch version-1.3.0) on Debian, it fails with the following error with guile-library (a.k.a. guile-lib) version 0.2.6.1-2: ice-9/eval.scm:293:34: error: %strict-tokenizer?: unbound variable hint: Did you forget a `use-modules' form? [ 10%] LOAD guix/import/go.scm ;;; Failed to autoload semver-range-contains? in (semver ranges): ;;; missing interface for module (semver ranges) ... ;;; Failed to autoload semverhttps://ftp-master.debian.org/new/guile-semver_0.1.1-1.html Maybe doc/guix.texi should be updated to specify the minimum version? live well, vagrant signature.asc Description: PGP signature
bug#44675: guix lint: support for spellchecker or basic grammar
On 2021-04-22, Maxime Devos wrote:
> + (define (check-pluralized-this-package description)
> +"Check that DESCRIPTION does not contain This packages"
>
> The sentence structure would be clearer if you used quotes here,
> something like "Check that DESCRIPTION does not contain ‘This packages’".
Any compelling reason to use ‘This packages’ vs. 'This packages' ? It
seems other quotes in guix/lint.scm use '' also, and I'm not apparently
skilled enough with a keyboard to generate ‘’-style quotes... :)
> +(if (string-match "This packages" description)
> + (list
> + (make-warning package
> +(G_ "description contains This Packages but should just
> be This package")))
>
> There are no package descriptions containing "This Packages".
> Did you mean "This packages"?
Nice catch, thanks!
>> +(test-equal "description: pluralized this package"
> Quotes: "description: pluralized ‘this package’".
Noted.
>> + "description contains This Packages but should just be This package"
> Capitalisation error: This Packages --> This packages
> Also, quotes: "description contains ‘This packages’ but should just be ‘This
> package’".
Again, nice catch!
Updated the commit message and incorporated the above suggestions into
the updated attached patch.
live well,
vagrant
From 4e724fbe9815e1c27967b835f08d2259164538ba Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Wed, 21 Apr 2021 09:26:45 -0700
Subject: [PATCH] lint: Add description check for pluralized "This package"
Partial fix for: https://issues.guix.gnu.org/44675
* guix/lint.scm (check-pluralized-this-package): Add check for
occurances of "This packages" in package descriptions.
* tests/lint.scm: Add test.
---
guix/lint.scm | 9 +
tests/lint.scm | 7 +++
2 files changed, 16 insertions(+)
diff --git a/guix/lint.scm b/guix/lint.scm
index 1bebfe03d3..e00048349b 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -221,6 +221,14 @@ markup is valid return a plain-text version of DESCRIPTION, otherwise #f."
(G_ "Texinfo markup in description is invalid")
#:field 'description
+ (define (check-pluralized-this-package description)
+"Check that DESCRIPTION does not contain 'This packages'"
+(if (string-match "This packages" description)
+ (list
+ (make-warning package
+ (G_ "description contains 'This packages' but should just be 'This package'")))
+ '()))
+
(define (check-trademarks description)
"Check that DESCRIPTION does not contain '™' or '®' characters. See
http://www.gnu.org/prep/standards/html_node/Trademarks.html.;
@@ -283,6 +291,7 @@ by two spaces; possible infraction~p at ~{~a~^, ~}")
(check-not-empty description)
(check-quotes description)
(check-trademarks description)
+ (check-pluralized-this-package description)
;; Use raw description for this because Texinfo rendering
;; automatically fixes end of sentence space.
(check-end-of-sentence-space description)
diff --git a/tests/lint.scm b/tests/lint.scm
index a2c8665142..3e1b95680a 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -160,6 +160,13 @@
(description "This is a 'quoted' thing."
(check-description-style pkg
+(test-equal "description: pluralized 'This package'"
+ "description contains 'This packages' but should just be 'This package'"
+ (single-lint-warning-message
+ (let ((pkg (dummy-package "x"
+ (description "This packages is a typo."
+ (check-description-style pkg
+
(test-equal "synopsis: not a string"
"invalid synopsis: #f"
(single-lint-warning-message
--
2.30.2
signature.asc
Description: PGP signature
bug#44675: guix lint: support for spellchecker or basic grammar
Control: tags 44675 +patch
On 2020-11-15, Vagrant Cascadian wrote:
> Please consider a guix lint description/synopsis check for basic
> spelling, typo and rudimentary grammar issues.
...
> Many of these are likely to be caught by most spell checking routines;
> I'm not sure if there is anything that would be implementable in pure
> guile, or it if would make sense to call out to an external
> spellchecker.
>
> Some of them might be harder, and obviously we do not want too many
> false positives, but no need to get perfectionist on solving this; even
> just checking for "This packages" would haved detected many of these
> issues!
In the attached patch, I've implemented a simple lint check for "This
packages", which has been fixed in ... 42 packages so far in the git
repository, so maybe this could help catch future ones!
I haven't implemented a more complicated spellchecker or grammar checker
or anything, but at least this is a start.
I think it is also within my skills to address "allows to" and "permits
to", if I'm not heading down the wrong path here...
live well,
vagrant
From d4b851f5722cd6f8d514a4254884d1f7a016b74f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Wed, 21 Apr 2021 09:26:45 -0700
Subject: [PATCH] lint: Add description check for check-pluralized-package
Fixes: https://issues.guix.gnu.org/44675
* guix/lint.scm: Check for occurances of "This packages" in package
descriptions.
* tests/lint.scm: Add test.
---
guix/lint.scm | 9 +
tests/lint.scm | 7 +++
2 files changed, 16 insertions(+)
diff --git a/guix/lint.scm b/guix/lint.scm
index 1bebfe03d3..ffeac18077 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -221,6 +221,14 @@ markup is valid return a plain-text version of DESCRIPTION, otherwise #f."
(G_ "Texinfo markup in description is invalid")
#:field 'description
+ (define (check-pluralized-this-package description)
+"Check that DESCRIPTION does not contain This packages"
+(if (string-match "This packages" description)
+ (list
+ (make-warning package
+ (G_ "description contains This Packages but should just be This package")))
+ '()))
+
(define (check-trademarks description)
"Check that DESCRIPTION does not contain '™' or '®' characters. See
http://www.gnu.org/prep/standards/html_node/Trademarks.html.;
@@ -283,6 +291,7 @@ by two spaces; possible infraction~p at ~{~a~^, ~}")
(check-not-empty description)
(check-quotes description)
(check-trademarks description)
+ (check-pluralized-this-package description)
;; Use raw description for this because Texinfo rendering
;; automatically fixes end of sentence space.
(check-end-of-sentence-space description)
diff --git a/tests/lint.scm b/tests/lint.scm
index a2c8665142..6cb7a98686 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -160,6 +160,13 @@
(description "This is a 'quoted' thing."
(check-description-style pkg
+(test-equal "description: pluralized this package"
+ "description contains This Packages but should just be This package"
+ (single-lint-warning-message
+ (let ((pkg (dummy-package "x"
+ (description "This packages is a typo."
+ (check-description-style pkg
+
(test-equal "synopsis: not a string"
"invalid synopsis: #f"
(single-lint-warning-message
--
2.30.2
signature.asc
Description: PGP signature
bug#46334: mbedtls-apache fails to build on aarch64
I get the following error when building mbedtls-apache on aarch64: /tmp/guix-build-mbedtls-apache-2.23.0.drv-0/source/programs/ssl/ssl_context_info.c: In function ‘read_next_b64_code’: /tmp/guix-build-mbedtls-apache-2.23.0.drv-0/source/programs/ssl/ssl_context_info.c:384:16: error: comparison is always\ true due to limited range of data type [-Werror=type-limits] while( EOF != c ) ^~ cc1: all warnings being treated as errors make[2]: *** [programs/ssl/CMakeFiles/ssl_context_info.dir/build.make:66: programs/ssl/CMakeFiles/ssl_context_info.dir\ /ssl_context_info.c.o] Error 1 make[2]: Leaving directory '/tmp/guix-build-mbedtls-apache-2.23.0.drv-0/build' make[1]: *** [CMakeFiles/Makefile2:2252: programs/ssl/CMakeFiles/ssl_context_info.dir/all] Error 2 make[1]: Leaving directory '/tmp/guix-build-mbedtls-apache-2.23.0.drv-0/build' make: *** [Makefile:144: all] Error 2 command "make" "-j" "1" failed with status 2 The version which produced this particular error was guix commit 7382b1027a319e505be6cfcadf1f5bd761dadccc, though the issue has been present for quite some time. Full build log attached. live well, vagrant 5mdydmqz9c88gihgzm7m5f906w0fk6-mbedtls-apache-2.23.0.drv.bz2 Description: Binary data signature.asc Description: PGP signature
bug#45943: php 7.4.14 fails tests on aarch64
On 2021-01-18, Julien Lepiller wrote: > What does the log say? It should list test failures at the end. I don't have the system handy at the moment, but there is a recent build log failure from staging: https://ci.guix.gnu.org/build/187255/log/raw It appears to have logged 6 failures, though I haven't managed to find which tests failed in the build output at a cursory glance... Will try to get a failed build log locally when I get a chance to more easily debug and review... live well, vagrant > Le 17 janvier 2021 15:56:34 GMT-05:00, Vagrant Cascadian > a écrit : >>php 7.4.14 fails to build on aarch64 due to test suite failures. >> >>Reverting back to php 7.4.13 by reverting commit >>d033540e6c113323089403a26e39f9a288c9c857 works fine for me, though >>obviously it would be better to track down the exact test suite failure >>and figure out a proper fix. >> >>This blocks numerous other packages from building, such as libsoup, >>which blocks building of network-manager. >> >> >>live well, >> vagrant signature.asc Description: PGP signature
bug#45943: php 7.4.14 fails tests on aarch64
php 7.4.14 fails to build on aarch64 due to test suite failures. Reverting back to php 7.4.13 by reverting commit d033540e6c113323089403a26e39f9a288c9c857 works fine for me, though obviously it would be better to track down the exact test suite failure and figure out a proper fix. This blocks numerous other packages from building, such as libsoup, which blocks building of network-manager. live well, vagrant signature.asc Description: PGP signature
bug#45069: Guix System: unprivileged user cannot create user namespaces?
On 2020-12-07, zimoun wrote: > On Mon, 07 Dec 2020 at 18:13, Pierre Neidhardt wrote: > >>> Can you try, as root on Guix System: >>> >>> $ echo 1 > /proc/sys/kernel/unprivileged_userns_clone >> >> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone >> -bash: /proc/sys/kernel/unprivileged_userns_clone: No such file or directory > > In gnu/build/linux-container.scm, it reads: > > --8<---cut here---start->8--- > (define (unprivileged-user-namespace-supported?) > "Return #t if user namespaces can be created by unprivileged users." > (let ((userns-file "/proc/sys/kernel/unprivileged_userns_clone")) > (if (file-exists? userns-file) > (eqv? #\1 (call-with-input-file userns-file read-char)) > #t))) > --8<---cut here---end--->8--- > > Does it mean that the Linux kernel on Guix System does not support > namespaces by unprivileged users? > Turning #t to #f should work on Guix System and it appears to me a > severe bug if not. What do I miss? Please could someone fill my gap? :-) The /proc/sys/kernel_unprivileged_userns_clone file is specific to Debian and Ubuntu packaged linux kernel; it is a patchset not applied upstream, as far as I am aware. I'm not sure if other distros support disabling and enabling this feature using this mechanism. https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/debian/add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch live well, vagrant signature.asc Description: PGP signature
bug#44491: Support GUIX_DISABLE_NETWORK_TESTS environment variable
On 2020-12-03, Ludovic Courtès wrote: > Should we close this issue now that you found the RES_OPTIONS=attempts:0 > trick, or do you think we should still keep the refactoring bits? Well, it's three cases of copy-paste code, and one nearly identical but inverted. Someone once suggested to me to refactor on the third instance of copy-pasted code... Having common tests makes it a little easier to add to new tests in the future with the same code, and if there's ever a change in the underlying code, you fix it in once place. It also opens the door to adding other common functions, if it comes up. So I'd say it's worth applying, though also would be ok with leaving as is and just taking advantage of the RES_OPTIONS=attempts:0 workaround. live well, vagrant signature.asc Description: PGP signature
bug#44827: tests/channels.scm: Test failures building on Debian i386 or armhf with libgit2-dev 1.0.1
On 2020-11-27, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> On 2020-11-26, Ludovic Courtès wrote: >>> In particular, Guile-Git 0.4.0 has this thing compile-time check to make >>> sure it matches the ABI of the underlying libgit2 version (0.28 or 1.0): >>> >>> >>> https://gitlab.com/guile-git/guile-git/-/commit/2b4d077c6f55648f42af31ae783ca4d8c1c5f1de >>> >>> So if you change libgit2 versions, you need to rebuild Guile-Git. >> >> Oh, this will be fun to keep track of in debian... :/ :) > > Note that the problem is the same for packages written in C since it’s > an ABI change in libgit2. (Except that in C perhaps you get a SONAME > mismatch at load time rather than an error at run time…) > >> Yeah, the guile-git was built with the older 0.28 version of libgit2-dev >> (although also with all the architectures). >> >> Interestingly enough, guix pull completely fails with the older >> libgit2-dev version installed, but installing the new version it works >> fine. >> >> I'll build a newer guile-git version and force it to use the newer >> libgit2-dev package, and see if that fixes the issues. >> >> Then I'll have to come up with complicated versioned dependencies to >> ensure it keeps working in Debian and it becomes detectable when it >> needs to be rebuilt... > > Heheh. Let me know how it goes! Rebuilding guile-git against the newer libgit2 seems to resolve the issues; the test suites passed on amd64, armhf, i386 (the only platforms currently buildable on Debian). live well, vagrant signature.asc Description: PGP signature
bug#44827: tests/channels.scm: Test failures building on Debian i386 or armhf with libgit2-dev 1.0.1
On 2020-11-26, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Updating the build dependency to libgit2-dev >= 1.0.1 (which pulls in a >> similar version to what guix is using) fixes test suite failures ... but >> only on the amd64 architecture. The same tests pass Using an older >> version of libgit2-dev (0.28). FWIW, this is building with guile-3.0. > > [...] > >> actual-error: >> + (git-error >> + #< code: -1 message: "invalid version 0 on git_proxy_options" >> class: 3>) > > This error is the sign of an ABI mismatch issue between Guile-Git and > libgit2 (like Guile-Git assuming a wrong layout for one of the C structs > exposed by libgit2). > > Which version of Guile-Git are you using? Do its tests pass? 0.4.0, tests passed when built against libgit2 0.28... > In particular, Guile-Git 0.4.0 has this thing compile-time check to make > sure it matches the ABI of the underlying libgit2 version (0.28 or 1.0): > > > https://gitlab.com/guile-git/guile-git/-/commit/2b4d077c6f55648f42af31ae783ca4d8c1c5f1de > > So if you change libgit2 versions, you need to rebuild Guile-Git. Oh, this will be fun to keep track of in debian... :/ :) Yeah, the guile-git was built with the older 0.28 version of libgit2-dev (although also with all the architectures). Interestingly enough, guix pull completely fails with the older libgit2-dev version installed, but installing the new version it works fine. I'll build a newer guile-git version and force it to use the newer libgit2-dev package, and see if that fixes the issues. Then I'll have to come up with complicated versioned dependencies to ensure it keeps working in Debian and it becomes detectable when it needs to be rebuilt... live well, vagrant signature.asc Description: PGP signature
bug#44827: tests/channels.scm: Test failures building on Debian i386 or armhf with libgit2-dev 1.0.1
Fun With More Debian packaging test suite failures... Updating the build dependency to libgit2-dev >= 1.0.1 (which pulls in a similar version to what guix is using) fixes test suite failures ... but only on the amd64 architecture. The same tests pass Using an older version of libgit2-dev (0.28). FWIW, this is building with guile-3.0. The newer version of libgit2-dev introduces several test suite failures on i386 (and armhf) architectures, but the tests work fine on amd64. from tests/channels.log on i386: test-name: latest-channel-instances #:validate-pull location: /build/guix-M9TbTs/guix-1.2.0/tests/channels.scm:202 source: + (test-equal + "latest-channel-instances #:validate-pull" + 'descendant + (let/ec + return + (with-temporary-git-repository + directory + '((add "a.txt" "A") + (commit "first commit") + (add "b.scm" "#t") + (commit "second commit")) + (with-repository + directory + repository + (let* ((commit1 (find-commit repository "first")) +(commit2 (find-commit repository "second")) +(spec (channel +(url (string-append "file://" directory)) +(name 'foo))) +(new (channel + (inherit spec) + (commit (oid->string (commit-id commit2) +(old (channel + (inherit spec) + (commit (oid->string (commit-id commit1)) + (define (validate-pull channel current commit relation) + (return + (and (eq? channel old) +(string=? + (oid->string (commit-id commit2)) + current) +(string=? + (oid->string (commit-id commit1)) + commit) +relation))) + (with-store + store + (latest-channel-instances + store + (list old) + #:current-channels + (list new) + #:validate-pull + validate-pull))) expected-value: descendant actual-value: #f actual-error: + (git-error + #< code: -1 message: "invalid version 0 on git_proxy_options" class: 3>) result: FAIL test-name: channel-news, no news location: /build/guix-M9TbTs/guix-1.2.0/tests/channels.scm:312 source: + (test-equal + "channel-news, no news" + '() + (with-temporary-git-repository + directory + '((add "a.txt" "A") (commit "the commit")) + (with-repository + directory + repository + (let ((channel + (channel + (url (string-append "file://" directory)) + (name 'foo))) + (latest (reference-name->oid repository "HEAD"))) + (channel-news-for-commit + channel + (oid->string latest)) expected-value: () actual-value: #f actual-error: + (git-error + #< code: -1 message: "invalid version 0 on git_proxy_options" class: 3>) result: FAIL test-name: latest-channel-instances, missing introduction for 'guix' location: /build/guix-M9TbTs/guix-1.2.0/tests/channels.scm:413 source: + (test-assert + "latest-channel-instances, missing introduction for 'guix'" + (with-temporary-git-repository + directory + '((add "a.txt" "A") + (commit "first commit") + (add "b.scm" "#t") + (commit "second commit")) + (with-repository + directory + repository + (let* ((commit1 (find-commit repository "first")) + (commit2 (find-commit repository "second")) + (channel +(channel + (url (string-append "file://" directory)) + (name 'guix + (guard (c ((formatted-message? c) +(->bool + Initialized empty Git repository in /tmp/guix-directory.82hhlD/.git/ [master (root-commit) 936aa16] first commit 1 file changed, 1 insertion(+) create mode 100644 a.txt [master 6c20741] second commit 1 file changed, 1 insertion(+) create mode 100644 b.scm gpg: keybox '/tmp/guix-directory.RpLKeD/pubring.kbx' created gpg: /tmp/guix-directory.RpLKeD/trustdb.gpg: trustdb created gpg: key 771F49CBFAAE072D: public key "Ed Two-Fifty " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: key 771F49CBFAAE072D: "Ed Two-Fifty " not changed gpg: key 771F49CBFAAE072D: secret key imported gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 gpg: key 82240EDCAB80DA83: public key "Charlie Guix " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: key 82240EDCAB80DA83: "Charlie Guix " not changed gpg: key 82240EDCAB80DA83: secret key imported gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1
bug#44751: tests/swh.scm hangs building guix with guile-2.2
I'm exploring building with guile 2.2 because guile-gnutls built with guile 3.0 is only available in experimental, and even there, missing for arm64. FAIL: tests/swh.scm - lookup-origin And then hangs indefinitely. I've seen it run for hours at a time. Works fine with guile 3.0. In tests/swh.log, there is not much there, though obviously seems problematic: warning: cannot run Web server for tests: Address already in use In thread: In procedure listen: Wrong type argument in position 1 (expecting open file port): #f I don't have any debian patches applied to tests/swh.scm and do not think any other patches are likely to affect this here, but you never know. :) live well, vagrant signature.asc Description: PGP signature
bug#44745: tests/lint.scm fails building guix with guile-2.2
I'm exploring building with guile 2.2 because guile-gnutls built with guile 3.0 is only available in experimental, and even there, missing for arm64. From tests/lint.log: test-name: archival: missing content location: /build/guix-EdK9LP/guix-1.2.0~rc2/tests/lint.scm:921 source: + (test-assert + "archival: missing content" + (let* ((origin +(origin + (method url-fetch) + (uri "http://example.org/foo.tgz;) + (sha256 (make-bytevector 32 + (warnings +(with-http-server + '((404 "Not archived.")) + (parameterize +((%swh-base-url (%local-url))) +(check-archival + (dummy-package "x" (source origin))) + (warning-contains? "not archived" warnings))) actual-value: #f actual-error: + (keyword-argument-error + # + "Unrecognized keyword" + () + (#:verify-certificate?)) result: FAIL I haven't tried reproducing this without the Debian patches applied which liberally sprinkle the test suites with: (unless (network-reachable? (test-skip 1)) ... but if you can spot a likely issue, I'd be happy to test it. :) live well, vagrant signature.asc Description: PGP signature
bug#44626: tests/build-utils, tests/guix-system: fail when build path contains "~"
On 2020-11-16, Ludovic Courtès wrote:
> Vagrant Cascadian skribis:
>
>> When building from a build path containing a "~", such as:
>>
>> /build/guix-1WL3Dl/guix-1.2.0~rc1/
>>
>> tests/build-utils.scm and tests/guix-system.sh both fail.
>
> [...]
>
>> FAIL: tests/build-utils
>> ===
>> ...
>> test-name: wrap-script, simple case
>> location: /<>/tests/build-utils.scm:152
>> source:
>> + (test-equal
>> + "wrap-script, simple case"
>
> […]
>
>> + make_user_config users wheel
>> + cat
>> + guix system build t-guix-system-6249 -n
>> accepted connection from pid 6454, user vagrant
>> guix system: error: invalid character `~' in name
>> `shepherd-file-system--build-guix-1WL3Dl-guix-1.2.0~rc1-test-tmp-store.scm-builder'
>
> I believe both are fixed by 977eb5d023cfdf8e336f1896480eea9cef5c04e9.
Thanks for the quick fix! That seems to fix tests/guix-system.sh...
Though may introduce a different issue in tests/build-utils.log:
...
test-name: wrap-script, simple case
location: /build/guix-41NMGX/guix-1.2.0~rc1/tests/build-utils.scm:152
source:
+ (test-equal
+ "wrap-script, simple case"
+ (string-append
+ (format
+ #f
+ "#!~a --no-auto-compile\n#!#; Guix wrapper\n#\\-~s\n#\\-~s\n"
+ (which "guile")
+ '(begin
+ (let ((current (getenv "GUIX_FOO")))
+(setenv
+ "GUIX_FOO"
+ (if current
+(string-append
+ "/some/path:/some/other/path"
+ ":"
+ current)
+"/some/path:/some/other/path"
+ '(let ((cl (command-line)))
+ (apply execl
+ "/anything/cabbage-bash-1.2.3/bin/sh"
+ (car cl)
+ (cons (car cl) (append '("") cl)
+ script-contents)
+ (call-with-temporary-directory
+ (lambda (directory)
+ (let ((script-file-name
+ (string-append directory "/foo")))
+ (call-with-output-file
+ script-file-name
+ (lambda (port) (display script-contents port)))
+ (chmod script-file-name 511)
+ (wrap-script
+ script-file-name
+ `("GUIX_FOO"
+ prefix
+ ("/some/path" "/some/other/path")))
+ (let ((str (call-with-input-file
+ script-file-name
+ get-string-all)))
+ (with-directory-excursion
+ directory
+ (delete-file "foo"))
+ str)
FORMAT: INTERNAL ERROR IN FORMAT-ERROR!
destination: #
format string: "#!/build/guix-41NMGX/guix-1.2.0~rc1/guile
--no-auto-compile\n#!#; Guix wrapper\n#\\-(begin (let ((current
(getenv \"GUIX_FOO\"))) (setenv \"GUIX_FOO\" (if current
(string-append \"/some/path:/some/other/path\" \":\" current)
\"/some/path:/some/other/path\"\n#\\-(let ((cl
(command-line))) (apply execl
\"/anything/cabbage-bash-1.2.3/bin/sh\" (car cl) (cons (car cl)
(append (quote (\"\")) cl\n"
format args: ()
error args: (#f "error in format" () #f)
FORMAT: INTERNAL ERROR IN FORMAT-ERROR!
destination: #
format string: "#!/build/guix-41NMGX/guix-1.2.0~rc1/guile
--no-auto-compile\n#!#; Guix wrapper\n#\\-(begin (let ((current
(getenv \"GUIX_FOO\"))) (setenv \"GUIX_FOO\" (if current
(string-append \"/some/path:/some/other/path\" \":\" current)
\"/some/path:/some/other/path\"\n#\\-(let ((cl
(command-line))) (apply execl
\"/anything/cabbage-bash-1.2.3/bin/sh\" (car cl) (cons (car cl)
(append (quote (\"\")) cl\n"
format args: ()
error args: (#< program:
"/tmp/guix-directory.YrSRbV/foo" type: misc-error>)
expected-value: "#!/build/guix-41NMGX/guix-1.2.0~rc1/guile
--no-auto-compile\n#!#; Guix wrapper\n#\\-(begin (let ((current (getenv
\"GUIX_FOO\"))) (setenv \"GUIX_FOO\" (if current (string-append
\"/some/path:/some/other/path\" \":\" current)
\"/some/path:/some/other/path\"\n#\\-(let ((cl (command-line)))
(apply execl \"/anything/cabbage-bash-1.2.3/bin/sh\" (car cl) (cons (car
cl) (append (quote (\"\"))
cl\n#!/anything/cabbage-bash-1.2.3/bin/sh\n\necho hello world"
actual-value: #f
actual-error:
+ (%exception
+ #< program: "/tmp/guix-directory.YrSRbV/foo" type:
misc-error>)
result: FAIL
test-
bug#44675: guix lint: support for spellchecker or basic grammar
Please consider a guix lint description/synopsis check for basic spelling, typo and rudimentary grammar issues. Most of the ones I've found were caught by debian's "lintian" tool: https://tracker.debian.org/lintian Common issues appear to be: "This packages" -> "This package" "allows to X" -> "Xs" or "Xing" I've fixed many of these in the past: git log --author=vagrant --extended-regexp --grep='spelling|typo|grammar' --patch But some of the very same patterns keep reappearing! Many of these are likely to be caught by most spell checking routines; I'm not sure if there is anything that would be implementable in pure guile, or it if would make sense to call out to an external spellchecker. Some of them might be harder, and obviously we do not want too many false positives, but no need to get perfectionist on solving this; even just checking for "This packages" would haved detected many of these issues! That is, of course, if "guix lint" is being used consistently... :) live well, vagrant signature.asc Description: PGP signature
bug#44626: tests/build-utils, tests/guix-system: fail when build path contains "~"
When building from a build path containing a "~", such as:
/build/guix-1WL3Dl/guix-1.2.0~rc1/
tests/build-utils.scm and tests/guix-system.sh both fail.
I've observed this with v1.2.0rc1, as well as
c6e8f40f2ce6082171c18b4aad9877b0ad022563.
Building in such a directory revealed two failing tests, which I could
reproduce attempting to run the tests directly from a directory that
such as /home/vagrant/src/guix~tilde/ using "guix environment --pure
guix":
make -j2 check RES_OPTIONS=attempts:0 AM_SCM_LOG_DRIVER_FLAGS="--brief=no"
TESTS="tests/build-utils.scm tests/guix-system.sh"
Running the same tests in /home/vagrant/src/guix-tilde PASSed.
(FWIW, The version is renamed in Debian so that release candidates such
are treated as older versions than the eventual released version
(e.g. 1.2.0rc1 > 1.2.0 > 1.2.0~rc1 for Debian package versions) and it
would be best for Debian to be able to use the ~ in the Debian package
version)
FAIL: tests/build-utils
===
...
test-name: wrap-script, simple case
location: /<>/tests/build-utils.scm:152
source:
+ (test-equal
+ "wrap-script, simple case"
+ (string-append
+ (format
+ #f
+ "#!~a --no-auto-compile\n#!#; Guix wrapper\n#\\-~s\n#\\-~s\n"
+ (which "guile")
+ '(begin
+ (let ((current (getenv "GUIX_FOO")))
+(setenv
+ "GUIX_FOO"
+ (if current
+(string-append
+ "/some/path:/some/other/path"
+ ":"
+ current)
+"/some/path:/some/other/path"
+ '(let ((cl (command-line)))
+ (apply execl
+ "/anything/cabbage-bash-1.2.3/bin/sh"
+ (car cl)
+ (cons (car cl) (append '("") cl)
+ script-contents)
+ (call-with-temporary-directory
+ (lambda (directory)
+ (let ((script-file-name
+ (string-append directory "/foo")))
+ (call-with-output-file
+ script-file-name
+ (lambda (port) (format port script-contents)))
+ (chmod script-file-name 511)
+ (wrap-script
+ script-file-name
+ `("GUIX_FOO"
+ prefix
+ ("/some/path" "/some/other/path")))
+ (let ((str (call-with-input-file
+ script-file-name
+ get-string-all)))
+ (with-directory-excursion
+ directory
+ (delete-file "foo"))
+ str)
FORMAT: INTERNAL ERROR IN FORMAT-ERROR!
destination: #
format string: "#!/<>/guile --no-auto-compile\n#!#; Guix
wrapper\n#\\-(begin (let ((current (getenv \"GUIX_FOO\"))) (setenv \"GUIX_FOO\"
(if current (string-append \"/some/path:/some/other/path\" \":\" current)
\"/some/path:/some/other/path\"\n#\\-(let ((cl (command-line))) (apply
execl \"/anything/cabbage-bash-1.2.3/bin/sh\" (car cl) (cons (car cl) (append
(quote (\"\")) cl\n"
format args: ()
error args: (#f "error in format" () #f)
FORMAT: INTERNAL ERROR IN FORMAT-ERROR!
destination: #
format string: "#!/<>/guile --no-auto-compile\n#!#; Guix
wrapper\n#\\-(begin (let ((current (getenv \"GUIX_FOO\"))) (setenv \"GUIX_FOO\"
(if current (string-append \"/some/path:/some/other/path\" \":\" current)
\"/some/path:/some/other/path\"\n#\\-(let ((cl (command-line))) (apply
execl \"/anything/cabbage-bash-1.2.3/bin/sh\" (car cl) (cons (car cl) (append
(quote (\"\")) cl\n"
format args: ()
error args: (#< program: "/tmp/guix-directory.s4eviV/foo"
type: misc-error>)
expected-value: "#!/<>/guile --no-auto-compile\n#!#; Guix
wrapper\n#\\-(begin (let ((current (getenv \"GUIX_FOO\"))) (setenv \"GUIX_FOO\"
(if current (string-append \"/some/path:/some/other/path\" \":\" current)
\"/some/path:/some/other/path\"\n#\\-(let ((cl (command-line))) (apply
execl \"/anything/cabbage-bash-1.2.3/bin/sh\" (car cl) (cons (car cl) (append
(quote (\"\")) cl\n#!/anything/cabbage-bash-1.2.3/bin/sh\n\necho hello
world"
actual-value: #f
actual-error:
+ (%exception
+ #< program: "/tmp/guix-directory.s4eviV/foo" type: misc-error>)
result: FAIL
FAIL: tests/guix-system
===
+ set -e
+ guix system --version
guix system (GNU Guix) 1.2.0rc1
Copyright (C) 2020 the Guix authors
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ tmpfile=t-guix-system-6249
+ errorfile=t-guix-system-error-6249
+ tmpdir=/tmp/t-guix-system-6249
+ mkdir /tmp/t-guix-system-6249
+ trap 'rm -f "$tmpfile" "$errorfile" "$tmpdir"/*; rmdir "$tmpdir"' EXIT
+ cat
+ guix system vm t-guix-system-6249
+ grep 't-guix-system-6249:2:3:.*missing.* initializers'
t-guix-system-error-6249
t-guix-system-6249:2:3: error: (operating-system): missing field initializers
(bootloader host-name file-systems
bug#44491: Support GUIX_DISABLE_NETWORK_TESTS environment variable
On 2020-11-10, Vagrant Cascadian wrote:
> On 2020-11-10, Ludovic Courtès wrote:
>> Vagrant Cascadian skribis:
>>> On 2020-11-08, Ludovic Courtès wrote:
>>>> Vagrant Cascadian skribis:
>>>>
>>>>> If this could be considered for the upcoming 1.2 release, that would be
>>>>> appreciated, though I can also carry the patches in Debian...
>>>>
>>>> Yay! It should be doable, let’s see.
>>>
>>> It seems like a simpler workaround is to pass RES_OPTIONS=attempts:0,
>>> which should disable name resolution, and thus the network checks will
>>> fail.
>>>
>>> With the RES_OPTIONS workaround, the changes to guix/tests.scm
>>> network-reachable are no longer needed ... i think. :)
>>
>> Oooh nice, the wonders of glibc!
>>
>>> Might still be worth refactoring some of *.sh tests to use common
>>> functions, since the code is basically copied and pasted in several
>>> different places.
>>
>> Yes, that’s still a good idea. Would you like to adjust your patch
>> accordingly?
>
> Thanks for the review!
>
> Updated patch attached, with changes:
>
> * Copyright header added to common.sh.
> * New function skip_if_network_unreachable in common.sh
> * Dropped GUIX_DISABLE_NETWORK_TESTS in favor of using
> RES_OPTIONS=attempts:0.
> * Updated tests to use skip_if_network_unreachable or network_reachable.
...
> diff --git a/tests/common.sh b/tests/common.sh
> new file mode 100644
> index 00..f9dd3c2c59
> --- /dev/null
> +++ b/tests/common.sh
...
> +network_reachable() {
> +if ! guile -c '(getaddrinfo "www.gnu.org" "80" AI_NUMERICSERV)' 2>
> /dev/null; then
> +return 0
> +fi
> +}
Ooops. I inverted that check... probably "if guile -c ..." and probably
should return 1 or something if it isn't... or maybe 77?
anyways... testing again.
live well,
vagrant
signature.asc
Description: PGP signature
