bug#41494: guix build error on armhf - hash-algorithm: unbound variable
Hi, Danny Milosavljevic skribis: > On Sun, 24 May 2020 23:27:24 +0200 > Ludovic Courtès wrote: > >> > $ guix environment --pure guix --ad-hoc git guile-json guile-readline >> > $ make >> > [ 11%] LOAD guix/scripts/download.scm >> > ice-9/eval.scm:293:34: error: hash-algorithm: unbound variable >> >> Which version of Guile-Gcrypt do you have in that profile? > > /gnu/store/k1jj8xpklngfshd9d9rvws9636am7lp7-guile-gcrypt-0.1.0/share/guile/site/2.2/gcrypt OK, so “not-a-bug” from my perspective. :-) >> You need 0.2.0 or later. > > Oops. > > I've installed the host guix using the armhf tarball from the website. > > $ which guix > /usr/local/bin/guix > $ ls -l /usr/local/bin/guix > lrwxrwxrwx 1 root root 54 Mar 4 15:25 /usr/local/bin/guix -> > /var/guix/profiles/per-user/root/current-guix/bin/guix > > Aha! That's different to Guix System, right? Yeah. > $ ls -l /var/guix/profiles/per-user/root/current-guix > /var/guix/profiles/per-user/root/current-guix -> current-guix-1-link > $ ls -l /var/guix/profiles/per-user/root/current-guix-1-link/ > [...] > libexec -> /gnu/store/a8041j3pg62zi62b30w91mxrmjsamp64-guix-1.0.1/libexec > > I guess I could guix pull under root user, but that would hide these kind of > usability bugs under the carpet :) ‘guix pull’ under the user you want, but you have to use a Guix that’s recent enough to provide Guile-Gcrypt 0.2.0 or later. :-) Cheers, Ludo’.
bug#41494: guix build error on armhf - hash-algorithm: unbound variable
Hi Ludo, On Mon, 25 May 2020 09:43:36 +0200 Ludovic Courtès wrote: > OK, so “not-a-bug” from my perspective. :-) Sure, buy maybe configure could check the guile-gcrypt version or something and error out? :) > > $ which guix > > /usr/local/bin/guix > > $ ls -l /usr/local/bin/guix > > lrwxrwxrwx 1 root root 54 Mar 4 15:25 /usr/local/bin/guix -> > > /var/guix/profiles/per-user/root/current-guix/bin/guix > > > > Aha! That's different to Guix System, right? > > Yeah. I mean especially that it doesn't use my regular user's guix (ever), as opposed to Guix System--where it does. > > I guess I could guix pull under root user, but that would hide these kind of > > usability bugs under the carpet :) > > ‘guix pull’ under the user you want I don't think guix pull under non-root would help. I've now added $HOME/.config/guix/current/bin to PATH in ~/.profile of the regular user manually--let's see. >, but you have to use a Guix that’s > recent enough to provide Guile-Gcrypt 0.2.0 or later. :-) Thanks for checking :) But it would be nice to have some kind of nicer error message, if that's possible. pgpClGtNH2XPh.pgp Description: OpenPGP digital signature
bug#37207: [PATCH] nginx: berlin: Work around Last-Modified issues for guix.gnu.org.
* hydra/nginx/berlin.scm (%berlin-servers): Add some config to the nginx-server-configurations for guix.gnu.org. --- hydra/nginx/berlin.scm | 14 ++ 1 file changed, 14 insertions(+) diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm index 303fd35..8c90eb1 100644 --- a/hydra/nginx/berlin.scm +++ b/hydra/nginx/berlin.scm @@ -514,6 +514,13 @@ PUBLISH-URL." (locations guix.gnu.org-locations) (raw-content (list + ;; TODO This works around NGinx using the epoch for the + ;; Last-Modified date, as well as the etag. + ;; See http://issues.guix.info/issue/37207 + "add_header Last-Modified \"\";" + "if_modified_since off;" + "etag off;" + "access_log /var/log/nginx/guix-info.access.log;"))) (nginx-server-configuration @@ -634,6 +641,13 @@ PUBLISH-URL." (append %tls-settings (list + ;; TODO This works around NGinx using the epoch for the + ;; Last-Modified date, as well as the etag. + ;; See http://issues.guix.info/issue/37207 + "add_header Last-Modified \"\";" + "if_modified_since off;" + "etag off;" + "access_log /var/log/nginx/guix-gnu-org.https.access.log;" (nginx-server-configuration -- 2.26.2
bug#37207: guix.gnu.org returns Last-Modified = Epoch
Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> So I think removing the Last-Modified header from the responses will fix >> the issue with the Repology fetcher (as it will stop thinking it's >> already fetch the file, since it was last modified in 1970), instead it >> will just always process the file. >> >> Removing the Last-Modified header, and maybe the ETag as well from >> responses should avoid the issue with web browsers using a cached >> version of the page when they probably shouldn't. > > It would prevent client-side caching altogether. So perhaps we can do > that as a stopgap (and it has the advantage of requiring only a tiny > config change). Great, I've finally got around to sending a patch for this now. signature.asc Description: PGP signature
bug#41451: Haskell packages retain references to bootstrap variants
Ricardo Wurmus writes: > Some Haskell packages have a “-bootstrap” variant to cut dependency > cycles. Unfortunately, these bootstrap variants remain in the reference > graph alongside their non-bootstrap counterparts. On a related note, Haskell packages retain needless references to *all* other Haskell packages at build time. That’s because we *copy* their .conf files at build time to create a package cache, and these .conf files thus propagate even to unrelated packages. We are effectively using propagation via the lib/ghc-8.6.5/.conf.d directory. I don’t know if all the files in there are really necessary, but it seems to me that perhaps this leads to spurious references. -- Ricardo
bug#41356: closed (Re: bug#41356: Install script fails on Ubuntu 18.04 x86_64: Workaround)
unarchive 41356 On Sun, 17 May 2020, GNU bug Tracking System wrote: >> ```bash >> cp: cannot stat '/root/.config/guix/current >> /lib/systemd/system/gnu-store.mount': No such file or directory >> chmod: cannot access '/etc/systemd/system/gnu-store.mount': No such file or >> directory >> ``` > > This happens because [0] links to guix-install.sh on (git) master, which > contains new code to install gnu-store.mount, but then downloads an older > (release) archive that doesn't contain that file yet. > > The above error is harmless, in that there's no regression from 1.1.0. New > installations just won't benefit from Guix Advanced System Protection(ZOMG™) > just yet. ebbf91542269fcb36d64928d4a4992e6afbf2acf avoids the error. The manual install has a similar issue where in 2.1 Binary Installation step 5, it asks you to run: # cp ~root/.config/guix/current/lib/systemd/system/gnu-store.mount \ ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \ /etc/systemd/system/ Which confused me during an install with the same "No such file" error as above. I see that guix-install.sh now includes a conditional around this `cp`. Perhaps it would be worth a small note in the documentation to advise that this will issue a harmless error on Guix <= 1.1.1? Regards, Ben
bug#41525: CVE-2020-12762: json-c
Hi, our package json-c is vulnerable to CVE-2020-12762[1]. Be careful when applying the “fix”, since it broke a lot of packages on Ubuntu and Gentoo[2] in the past week. Lars [1] https://nvd.nist.gov/vuln/detail/CVE-2020-12762 [2] https://bugs.gentoo.org/722150
bug#41527: ‘file-append’ expansion is incorrect when passed a store item
Since commit d03001a31a6d460b712825640dba11e3f1a53a14, an object like: (file-append (local-file …) "/foo/bar") where (local-file …) is lowered to a store item, say, /gnu/store/…-example, would wrongfully expand to: /gnu/store/…-example IOW, the second argument to ‘file-append’ is ignored. Ricardo noticed it in ‘doc/build.scm’, in ‘guix-manual-text-domain’. Ludo’.
bug#41528: failed to compute derivation
Hi— I did a 'guix pull && guix package -u' today, but something went wrong, tail follows: ... ./guix/store.scm:1363:15: Throw to key `srfi-34' with args `(#)'. guix pull: error: You found a bug: the program '/gnu/store/6naagkv776pp47zk9blnnrjwhzyq5k4b-compute-guix-derivation' failed to compute the derivation for Guix (version: "8c42a25b77e5cb8c97dacfdd552811a820d674eb"; system: "x86_64-linux"; host version: "545e12f40dcd8cfc779e8802dadead7a7cdc8364"; pull-version: 1). Please report it by email to . Longer tail: http://paste.debian.net/1148762/ —Marco
bug#25952: offloading empty machines file
Dear, This bug [1] had not been commented since the last 3 years and it has been asked more info 3 weeks ago. Therefore, I am closing. Feel free to reopen if I misunderstand something. [1] http://issues.guix.gnu.org/issue/25952 All the best, simon
bug#41458: Misleading error message when call guix command using pre-inst-env script
Hi, On Sat, 23 May 2020 at 17:47, Ludovic Courtès wrote: > Jérémy Korwin-Zmijowski skribis: > >$ git clone https://git.savannah.gnu.org/git/guix.git > > $ cd guix > > $ guix environment --pure guix > > [dev]$ ./bootstrap && ./configure --localstatedir=/var && make Hum? instead of these: > > exit > > $ ./pre-inst-env guix build artanis what you (Jérémy) would want seems: --8<---cut here---start->8--- [dev]$ ./pre-inst-env guix pull --url=$PWD -p /path/to/your/custom [dev]$ exit $ /path/to/your/custom/bin/guix build artanis --8<---cut here---end--->8--- > This is a development environment issue that cannot happen when using a > ‘guix pull’-provided ‘guix’ command. I would close it as “wontfix” > since, after all, it’s just one of the many ways one can end up with a > non-functional development environment. Even, I would close it as 'notabug'. ;-) Cheers, simon
bug#25952: offloading empty machines file
Simon, zimoun 写道： This bug [1] had not been commented since the last 3 years and it has been asked more info 3 weeks ago. The issue is that files such as /etc/guix/machines.scm (but this applies equally to /etc/guix/acl & so on) are expected to evaluate to a sexp. An empty file does not a valid sexp make, so Guix throws an prickly backtrace @ your face & dies. This is unlike most other configuration formats where an empty file or one consisting entirely of comments is a no-op. We should decide whether ‘’ is a valid sexp (oh dear, philosophy) or throw something softer at people. Therefore, I am closing. Feel free to reopen if I misunderstand something. I think this bug should remain open until it's decided. What you? Kind regards, T G-R signature.asc Description: PGP signature
bug#41451: Haskell packages retain references to bootstrap variants
Ricardo Wurmus skribis: > Ricardo Wurmus writes: > >> Some Haskell packages have a “-bootstrap” variant to cut dependency >> cycles. Unfortunately, these bootstrap variants remain in the reference >> graph alongside their non-bootstrap counterparts. > > On a related note, Haskell packages retain needless references to *all* > other Haskell packages at build time. That’s because we *copy* their > .conf files at build time to create a package cache, and these .conf > files thus propagate even to unrelated packages. Weren’t these files eventually superseded by the ‘ghc-package-cache-file’ profile hook? Or are these two different things? Ludo’.
bug#41528: failed to compute derivation
Marco van Hulten writes: > Hi— > > I did a 'guix pull && guix package -u' today, but something went wrong, > tail follows: > > ... > ./guix/store.scm:1363:15: Throw to key `srfi-34' with args `(# &store-protocol-error [message: "build of > `/gnu/store/gv21jfvr92p2rqwjp7idv7q1if44q5wl-openldap-2.4.50.drv' failed" > status: 100] 7f9b9a5b3e40>)'. > guix pull: error: You found a bug: the program > '/gnu/store/6naagkv776pp47zk9blnnrjwhzyq5k4b-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "8c42a25b77e5cb8c97dacfdd552811a820d674eb"; system: "x86_64-linux"; > host version: "545e12f40dcd8cfc779e8802dadead7a7cdc8364"; pull-version: 1). > Please report it by email to . > > > Longer tail: http://paste.debian.net/1148762/ One libpng test is failing. Full log included here for posterity: --8<---cut here---start->8--- FAIL: tests/pngtest === [46/1810] Testing libpng version 1.6.37 with zlib version 1.2.11 libpng version 1.6.37 Copyright (c) 2018-2019 Cosmin Truta Copyright (c) 1998-2002,2004,2006-2018 Glenn Randers-Pehrson Copyright (c) 1996-1997 Andreas Dilger Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc. library (10637): libpng version 1.6.37 - April 14, 2019 pngtest (10637): libpng version 1.6.37 - April 14, 2019 Testing ./pngtest.png: Text compression[0]=-1 stereo mode = 1 vpAg = 100 x 100, units = 0 Text compression[0]=0 eXIf type MM, 52 bytes Image width = 91, height = 69 Files ./pngtest.png and pngout.png are different Was ./pngtest.png written with the same maximum IDAT chunk size (8192 bytes), filtering heuristic (libpng default), compression level (zlib default), and zlib version (1.2.11)? FAIL libpng FAILS test Default limits: width_max = 100 height_max = 100 cache_max = 1000 malloc_max = 800 FAIL tests/pngtest (exit status: 1) --8<
bug#25952: offloading empty machines file
Hi Tobias, On Mon, 25 May 2020 at 22:32, Tobias Geerinckx-Rice wrote: > The issue is that files such as /etc/guix/machines.scm (but this > applies equally to /etc/guix/acl & so on) are expected to evaluate > to a sexp. > > An empty file does not a valid sexp make, so Guix throws an > prickly backtrace @ your face & dies. This is unlike most other > configuration formats where an empty file or one consisting > entirely of comments is a no-op. Hum? I am not sure to get the point. Are we talking about this kind of situations, e.g., --8<---cut here---start->8--- touch /tmp/empty.scm guix package -m /tmp/empty.scm -p /tmp/empy --8<---cut here---end--->8--- or --8<---cut here---start->8--- echo ";; hello" > /tmp/comment.scm guix package -m /tmp/comment.scm -p /tmp/comment --8<---cut here---end--->8--- or --8<---cut here---start->8--- echo "(define x 42)" > /tmp/answer.scm guix package -m /tmp/answer.scm -p /tmp/answer --8<---cut here---end--->8--- ? > We should decide whether ‘’ is a valid sexp (oh dear, philosophy) > or throw something softer at people. Throw something more "helping" than e.g., --8<---cut here---start->8--- Backtrace: 1 (primitive-load "/home/simon/.config/guix/current/bin/g…") In guix/ui.scm: 1936:12 0 (run-guix-command _ . _) guix/ui.scm:1936:12: In procedure run-guix-command: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): # --8<---cut here---end--->8--- ? > > Therefore, I am closing. Feel free to reopen if I misunderstand > > something. > > I think this bug should remain open until it's decided. What you? Well, it is a variant of Cunningham's Law, isn't it? :-) So, let reopen it and decide on the philosophical dilemma. ;-) Cheers, simon
bug#32324: Failing Tests
Thovthe via web writes: > Should this remain open? Probably not, as there has not been movement in almost two years and Fedora 28 is pretty old by now. I think newer versions should work. Thanks for the bug triage! signature.asc Description: PGP signature
bug#41451: Haskell packages retain references to bootstrap variants
Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> Ricardo Wurmus writes: >> >>> Some Haskell packages have a “-bootstrap” variant to cut dependency >>> cycles. Unfortunately, these bootstrap variants remain in the reference >>> graph alongside their non-bootstrap counterparts. >> >> On a related note, Haskell packages retain needless references to *all* >> other Haskell packages at build time. That’s because we *copy* their >> .conf files at build time to create a package cache, and these .conf >> files thus propagate even to unrelated packages. > > Weren’t these files eventually superseded by the > ‘ghc-package-cache-file’ profile hook? Or are these two different > things? That hook also operates on the .conf.d directory containing all .conf files that have been copied from Haskell inputs. -- Ricardo
