bug#45574: Guile 3 fails to build non-deterministically

[Mathieu Othacehe]

Hello Chris,

> If you try to build Guile 3 without substitutes using any recent version
> of Guix, it can frequently fail.  I had to try about 12 times
> in a row before it succeeded.  The failure simply said "FAIL:
> check-guile" - I didn't save the build logs, which were lost once the
> build succeeded.  If anyone is interested in debugging, it should be
> easy to reproduce.  Just do this:

I investigated those failures yesterday. I think they are caused by:
https://lists.gnu.org/archive/html/bug-guile/2020-09/msg00012.html.

Let's see if the fix proposed by Rob can be merged in Guile.

Thanks,

Mathieu

bug#34893: Translated manuals refer to wrong substitute server

[Julien Lepiller]

Le Sun, 17 Mar 2019 14:53:56 +0100,
"pelzflorian (Florian Pelz)"  a écrit :

> Where the manual refers to the default substitute server
> https://ci.guix.info, the translated manuals wrongly use
> https://ci.guix.fr.info or similar.
> 
> This is because at the top of doc/guix.texi it says
> 
> @set SUBSTITUTE-SERVER ci.guix.info
> 
> which is wrongly replaced by something like
> 
> @set SUBSTITUTE-SERVER ci.guix.fr.info
> 
> in doc/guix.fr.texi.
> 
> 
> I believe this is because doc/local.mk has the following code:
> 
> $(srcdir)/%D%/guix.%.texi: po/doc/guix-manual.%.po
> $(srcdir)/%D%/contributing.%.texi -$(AM_V_PO4A)$(PO4A_TRANSLATE)
> $(PO4A_PARAMS) -m "%D%/guix.texi" -p "$<" -l "$@.tmp" -sed -i
> "s|guix\.info|$$(basename "$@" | sed 's|texi$$|info|')|" "$@.tmp"
> -$(AM_V_POXREF)$(xref_command) -mv "$@.tmp" "$@"
> 
> 
> Please change either the line “@set SUBSTITUTE-SERVER ci.guix.info” to
> use escape sequences so it is not affected by the local.mk code, or
> change the local.mk code somehow.
> 
> Regards,
> Florian

Since we don't use the guix.info domain anymore, this should not be an
issue anymore. I'm closing this issue, but feel free to re-open if you
think this is still an issue.

bug#45378: F1 keyboard layout switch bug in the installation process (minor)

[Mathieu Othacehe]

Hello,

> You will find the same error in the attachment. If you cant see the attachment
> i have uploaded the image here:

Thanks for the report, this is fixed with:
bb4e67415eb6d9871ee1b50b0a01e08c19f4809a.

Mathieu

bug#45174: ‘guix substitute’ doesn’t handle HTTP redirects

[Julien Lepiller]

Le Fri, 11 Dec 2020 10:50:36 +0100,
Ludovic Courtès  a écrit :

> Hi!
> 
> As reported by mange on #guix, it seems that ‘guix substitute’ does
> not follow redirects:
> 
> --8<---cut here---start->8---
> $ guix weather icecat emacs --substitute-urls=https://ci.guix.gnu.org
> computing 2 package derivations for x86_64-linux...
> looking for 2 store items on https://ci.guix.gnu.org...
> updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> https://ci.guix.gnu.org
>   100.0% substitutes available (2 out of 2)
>   at least 201.3 MiB of nars (compressed)
>   293.5 MiB on disk (uncompressed)
>   0.084 seconds per request (0.2 seconds in total)
>   11.9 requests per second
> 
>   at least 1,000 queued builds
>   x86_64-linux: 368 (36.8%)
>   i686-linux: 556 (55.6%)
>   armhf-linux: 6 (.6%)
>   aarch64-linux: 69 (6.9%)
>   i586-gnu: 1 (.1%)
>   build rate: 154.41 builds per hour
>   i686-linux: 40.77 builds per hour
>   x86_64-linux: 37.06 builds per hour
>   armhf-linux: 40.30 builds per hour
>   aarch64-linux: 35.83 builds per hour
>   i586-gnu: 0.55 builds per hour
> $ guix weather icecat emacs --substitute-urls=https://ci.guix.info
> computing 2 package derivations for x86_64-linux...
> looking for 2 store items on https://ci.guix.info...
> updating substitutes from 'https://ci.guix.info'... 100.0%
> https://ci.guix.info
>   0.0% substitutes available (0 out of 2)
>   unknown substitute sizes
>   0.0 MiB on disk (uncompressed)
>   0.069 seconds per request (0.1 seconds in total)
>   14.4 requests per second
> ni sekvas la redirektigon al 'https://ci.guix.gnu.org/api/queue'...
>   'https://ci.guix.gnu.org/api/queue' returned 500 ("Internal Server
> Error") --8<---cut
> here---end--->8---
> 
> This might explain things like .
> 
> (*.guix.info were turned into HTTP redirects a few days ago, see
> .)
> 
> Ludo’.
> 
> 
> 

Here is a patch to fix that issue. Since ci.guix.info now returns 200,
it's difficult to test the patch. I created a location block on my
website to redirect lepiller.eu/*.narinfo -> ci.guix.gnu.org/*.narinfo.
Here's the result:

$ guix weather icecat emacs --substitute-urls=https://lepiller.eu
calcul de 2 dérivations de paquets pour x86_64-linux…
recherche de 2 éléments du dépôt sur https://lepiller.eu...
mise à jour des substituts depuis « https://lepiller.eu »... 100.0 %
https://lepiller.eu
  0.0 % des substituts sont disponibles (0 sur 2)
  taille des substituts inconnue
  0,0 Mo sur le disque (décompressé)
  0,207 secondes par requête (0,4 secondes en tout)
  4,8 requêtes par seconde


$ ./pre-inst-env guix weather icecat emacs
--substitute-urls=https://lepiller.eu
computing 2 package derivations for x86_64-linux...
looking for 2 store items on https://lepiller.eu...
updating substitutes from 'https://lepiller.eu'... 100.0%
https://lepiller.eu
  100.0% substitutes available (2 out of 2)
  at least 201,3 MiB of nars (compressed)
  293,5 MiB on disk (uncompressed)
  0,525 seconds per request (1,1 seconds in total)
  1,9 requests per second


(note that I didn't redirect the ci API on my server, so the rest of the
weather command fails with a backtrace, but it's unrelated to this
patch and this issue).
>From f20e01f2a8df538519660772a7431b53d650d64f Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Tue, 12 Jan 2021 18:07:25 +0100
Subject: [PATCH] substitute: Follow narinfo redirections.

* guix/scripts/substitute.scm (fetch-narinfos): Follow redirections.
---
 guix/scripts/substitute.scm | 38 +++--
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index e53de8c304..790168091e 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -663,18 +663,36 @@ port to it, or, if connection failed, print a warning and return #f.  Pass
(len(response-content-length response))
(cache  (response-cache-control response))
(ttl(and cache (assoc-ref cache 'max-age
-  (update-progress!)
 
   ;; Make sure to read no more than LEN bytes since subsequent bytes may
   ;; belong to the next response.
-  (if (= code 200); hit
-  (let ((narinfo (read-narinfo port url #:size len)))
-(if (string=? (dirname (narinfo-path narinfo))
-  (%store-prefix))
-(begin
-  (cache-narinfo! url (narinfo-path narinfo) narinfo ttl)
-  (cons narinfo result))
-result))
+  (case code
+((200); hit
+ (update-progress!)
+ (let ((narinfo (read-narinfo port url #:size len)))
+   (if (string=? (dirname

bug#34893: Translated manuals refer to wrong substitute server

[pelzflorian (Florian Pelz)]

On Tue, Jan 12, 2021 at 03:21:14PM +0100, Julien Lepiller wrote:
> Le Sun, 17 Mar 2019 14:53:56 +0100,
> "pelzflorian (Florian Pelz)"  a écrit :
> > Where the manual refers to the default substitute server
> > https://ci.guix.info, the translated manuals wrongly use
> > https://ci.guix.fr.info or similar.
>
> Since we don't use the guix.info domain anymore, this should not be an
> issue anymore. I'm closing this issue, but feel free to re-open if you
> think this is still an issue.

Thank you for closing!  I didn’t even see the issue anymore at the one
place where ci.guix.info was still used.

 Ce que montre cet exemple est que ‘kcoreaddons’ et probablement les
 58 paquets qui en dépendent n’ont pas de substituts sur
 ‘ci.guix.info’ ; de même pour ‘qgpgme’ et les 46 paquets qui en
 dépendent.

Anyway I changed that last occurrence of guix.info as
89dbcac107d931fd33eda4a83db445e8a90cc4af.

Regards,
Florian

bug#45822: Guix cannot update again and again

[znavko--- via Bug reports for GNU Guix]

Hello! I make update under root normally.
But normal user cannot finish updates for several times during these 3 weeks.
Sometimes process stops on downloading one file,sometimes another.
I can remember when I had bad connection I restarted updates again and again 
and finally got my profile updated.
Is it a problem with my network or Guix servers, or guix code?

$ guix pull && guix package -u
...
building /gnu/store/7ingg9zn1jv0gy4lv93bj4xl1rg12s4p-gvfs-1.40.1.drv...
building /gnu/store/96wkbqpdv3b5wppma08x4xi8ps7ql82n-audacity-2.4.2.drv...
building /gnu/store/xlvl0iymrcgnl9ng8vp53ibc0rmzl4qw-pcmanfm-1.3.1.drv...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix 
substitute: error: TLS error in procedure 'read_from_session_record_port': 
Error in the pull function.
guix package: error: unexpected end-of-file

~$ guix describe
Generation 8 Jan 12 2021 20:05:21 (current)
 guix bb4e674
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: bb4e67415eb6d9871ee1b50b0a01e08c19f4809a

bug#45822: Guix cannot update again and again

[Dr. Arne Babenhauserheide]

znavko--- via Bug reports for GNU Guix  writes:

> Hello! I make update under root normally.
> But normal user cannot finish updates for several times during these 3 weeks.
> Sometimes process stops on downloading one file,sometimes another.
> I can remember when I had bad connection I restarted updates again and again 
> and finally got my profile updated.
> Is it a problem with my network or Guix servers, or guix code?
>
> $ guix pull && guix package -u
> ...
> building /gnu/store/7ingg9zn1jv0gy4lv93bj4xl1rg12s4p-gvfs-1.40.1.drv...
> building /gnu/store/96wkbqpdv3b5wppma08x4xi8ps7ql82n-audacity-2.4.2.drv...
> building /gnu/store/xlvl0iymrcgnl9ng8vp53ibc0rmzl4qw-pcmanfm-1.3.1.drv...
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix 
> substitute: error: TLS error in procedure 'read_from_session_record_port': 
> Error in the pull function.
> guix package: error: unexpected end-of-file

This example is in guix pull, it looks like either a network error or an
error in your local encryption stack.

If other examples are in guix package -u, you can add -k (--keep), then
previous good builds will be kept and won’t have to be rebuilt on the
next try.

However I have been in configurations that for some reasons did not
work. This helped me out of that:

guix pull && guix package -I | cut -f 1,3 | sed 's/\t/:/' | xargs guix install 
-k

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

bug#45826: SBCL / Common Lisp packages fail to build on aarch64

[Leo Famulari]

I noticed that many Common Lisp or SBCL-related packages are failing to
build on the aarc64 platform on our build farm, due the failure to build
SBCL:

>From the log of :

--
//entering make-target-2.sh
//doing warm init - compilation phase
This is SBCL 2.1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
Initial page table:
Gen  Boxed   CodeRaw  LgBox LgCode  LgRaw  Pin   Alloc Waste
Trig  WP GCs Mem-age
 6 397250  0  0  0  0042335440 66352 
200 647   0  0.
   Total bytes allocated=  42335440
   Dynamic-space-size bytes =3221225472
COLD-INIT... (Length(TLFs)= 9736)
Disassembler: 72 printers, 0 prefilters, 4 labelers
CORRUPTION WARNING in SBCL pid 1774 tid 1774:
Memory fault at 0xfffa (pc=0x1002199f70)
The integrity of this image is possibly compromised.
Exiting.
Error opening /dev/tty: No such device or address
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> 
real0m6.120s
user0m5.958s
sys 0m0.137s
command "sh" "make.sh" "clisp" 
"--prefix=/gnu/store/j1ciw4dc8iskd5fdcw0s1ba08kkg7vx6-sbcl-2.1.0" 
"--dynamic-space-size=3072" "--with-sb-core-compression" 
"--with-sb-xref-for-internals" failed with status 1
--

It appears that SBCL can support this platform. However, until we make
it work, I plan to remove aarch64 from the "supported-systems" of sbcl,
to avoid attempting these builds.

bug#45174: ‘guix substitute’ doesn’t handle HTTP redirects

[Mark H Weaver]

Hi Julien,

Julien Lepiller  writes:

> Here is a patch to fix that issue.  Since ci.guix.info now returns 200,
> it's difficult to test the patch.  [...]
[...]
> From f20e01f2a8df538519660772a7431b53d650d64f Mon Sep 17 00:00:00 2001
> From: Julien Lepiller 
> Date: Tue, 12 Jan 2021 18:07:25 +0100
> Subject: [PATCH] substitute: Follow narinfo redirections.
>
> * guix/scripts/substitute.scm (fetch-narinfos): Follow redirections.
> ---
>  guix/scripts/substitute.scm | 38 +++--
>  1 file changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
> index e53de8c304..790168091e 100755
> --- a/guix/scripts/substitute.scm
> +++ b/guix/scripts/substitute.scm
> @@ -663,18 +663,36 @@ port to it, or, if connection failed, print a warning 
> and return #f.  Pass
[...]
> +((301 302 303 307 308); redirect
> + (let* ((uri (response-location response))
> +(new-request (build-request
> +   uri #:headers '((User-Agent . "GNU Guile")
> +   (if len
> +   (get-bytevector-n port len)
> +   (read-to-eof port))
> +   (append
> + (http-multiple-get uri
> +handle-narinfo-response '()
> +(list new-request)
> +#:open-connection
> +open-connection-for-uri/cached
> +#:verify-certificate? #f)
> + result)))

Granted, it's been almost six years since I first implemented proper
HTTP redirects for Guix, but as I vaguely recall the URI in the response
may be a relative URI or have some missing components, so in the general
case it must be interpreted relative to the previous URI in accordance
with RFC 3986 section 5.2.

A proper implementation should use 'resolve-uri-reference' from (guix
build download).  Here's the original commit that added that function,
and used it to fix HTTP redirection support in (guix http-client):

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=04dec194d8e460831ec0695a944d9c7313affea2

Also, keep in mind that multiple redirects may occur, so a proper
implementation requires some kind of loop.  I haven't looked closely
enough at your code above to know whether that case is handled
correctly.  See the relevant code in (guix http-client) for hints.

Anyway, thanks for working on it!

 Regards,
   Mark

bug#45827: [aarch64] GCC 4.9.4 stack deallocation bug

[Leo Famulari]

There was a bug in GCC 4.9.4 that could cause miscompilation, such that
the "compiler was freeing the function's stack frame prior to the end of
the function itself." [0]

The bug was observed to cause corruption of ext4 filesystems on the
aarch64 platform.

The upstream report is here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293

Apparently this was fixed in GCC 5, but never backported to the 4.9
series.

Should we fix it? We use GCC 4.9 to bootstrap the system in (gnu
packages commencement), and a handful of packages depend on it.

[0]
https://lwn.net/SubscriberLink/842122/40442a015222c028/

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

[Leo Famulari]

Recently, many people on the #guix IRC channel reported frequent
non-deterministic failures of any operation involving substitution, like
this:

--
$ ./pre-inst-env guix build --no-grafts poezio mpdris2 sonata beets-bandcamp 
beets
substitute: 
guix build: error: got unexpected path `Backtrace:' from substituter
--

`guix describe` reports commit b4384e61165623b16b77b8cab16c81423c6853ed
for both my user's Guix and the guix-dameon.

bug#40887: No substitutes for libreoffice / vigra

[Leo Famulari]

On Sun, Jan 10, 2021 at 11:56:23PM -0500, Maxim Cournoyer wrote:
> While there are currently substitutes available for both vigra and
> libreoffice, I've raised the max-silent-time timeout value from 1 h to 2
> h in a25896bb7576c8232acc7a3fd4da0b1cba89569b.  Hopefully that'll help
> keeping the problem at bay.

Does Cuirass honor this property? In the past, the timeout and
max-silent-time properties were ignored by Cuirass:

https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00209.html

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

[Christopher Baines]

Leo Famulari  writes:

> Recently, many people on the #guix IRC channel reported frequent
> non-deterministic failures of any operation involving substitution, like
> this:
>
> --
> $ ./pre-inst-env guix build --no-grafts poezio mpdris2 sonata beets-bandcamp 
> beets
> substitute: 
> guix build: error: got unexpected path `Backtrace:' from substituter
> --
>
> `guix describe` reports commit b4384e61165623b16b77b8cab16c81423c6853ed
> for both my user's Guix and the guix-dameon.

I might have managed to reproduce the error happening on the daemon
side:

→ /gnu/store/4j8vn0gbqz5adj1y02nnwcfwmqsjgj8s-guix-1.2.0-6.799f066/bin/guix 
substitute --query
info /gnu/store/3c01q1f16kljfry70qjg6cs6k8winfzg-guix-package-cache 
/gnu/store/6lk8anal4s62gk3d30vgxppykbd5jcfj-guix-85e97c969 
/gnu/store/9zl2zbh3q2jnbfvxgnhw8j3f637ni7z4-guix-cli 
/gnu/store/ihricijvy16zwkd2n671xlyrn02sqhf9-guix-manual 
/gnu/store/m3j427qnlp81vsdj3x9ds7s4i051r1vz-guix-system-tests 
/gnu/store/mbv9j7wwqvwnr5awzbi126jdsj3h64h5-guix-packages 
/gnu/store/n2m1ay7kpa5f4fls4vvcy46ar1fdl0wk-guix-system 
/gnu/store/p4q9ajlb3l7x8xglqs6fflch2iwjqwaj-guix-module-union 
/gnu/store/snhx33fgjj2xnc5vy96sr3c8jqw9c7s0-guix-85e97c969-modules 
/gnu/store/vnrlvz9pxl5qrpy5x8y51v6awz7yzn8q-guix-packages-base 
/gnu/store/z4wj18vyzaas2yqb0577cc3japy4fi7z-guix-config 
/gnu/store/zdjfbsj1a94vdbbg9r0cx4jcqnwxazxs-guix-translated-texinfo
Backtrace:
In ice-9/boot-9.scm:
  1736:10  5 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   4 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2  3 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In guix/ui.scm:
  2127:12  1 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
   1256:4  0 (guix-substitute . _)

guix/scripts/substitute.scm:1256:4: In procedure guix-substitute:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.


It's hard to tell if that's actually consistent with the error
though. Repeating the same test after the restart of guix-publish on
ci.guix.gnu.org works without printing a backtrace.


signature.asc
Description: PGP signature

bug#45830: Assert, that user and group names are unique -> breaks guix system reconfigure

[Jonathan Brielmaier]

Hi Leo,

your commit a3002104:
system: Assert, that user and group names are unique.

breaks `guix system reconfigure` for me and other people (at least two
in IRC).

$ guix system reconfigure config.scm
guix system: error: the following groups appear more than once: lp

$ sudo grep lp /etc/group
lp:x:989:

lpadmin:x:975:

$ sudo grep lp /etc/passwd
lp:!:18467::

The same happend on my server with the `nginx` group.

I reverted it for the mean time, as I find it pretty grave...

~Jonathan

bug#45830: Assert, that user and group names are unique -> breaks guix system reconfigure

[Jonathan Brielmaier]

The original bug with the patch leading to this issue is:
https://issues.guix.gnu.org/45570

bug#45830: Assert, that user and group names are unique -> breaks guix system reconfigure

[Leo Prikler]

Hi Jonathan,

Am Mittwoch, den 13.01.2021, 00:03 +0100 schrieb Jonathan Brielmaier:
> Hi Leo,
> 
> your commit a3002104:
> system: Assert, that user and group names are unique.
> 
> breaks `guix system reconfigure` for me and other people (at least
> two
> in IRC).
> 
> $ guix system reconfigure config.scm
> guix system: error: the following groups appear more than once: lp
> 
> $ sudo grep lp /etc/group
> lp:x:989:
> 
> lpadmin:x:975:
> 
> $ sudo grep lp /etc/passwd
> lp:!:18467::
It would seem you have two or more services adding an lp group then. 
Or one service and a manually defined one.

> The same happend on my server with the `nginx` group.
Same problem here; you're probably adding an nginx group twice in some
way.  This is especially concerning, given that it's groups twice – for
some reason nothing is adding additional users or else that check would
have been triggered first.

> I reverted it for the mean time, as I find it pretty grave...
I would have preferred, if you could instead have demoted it to a
warning.  I understand, that stuff suddenly breaking can be
frustrating, but I doubt the configurations you're using are fine.

> ~Jonathan
Regards,
Leo

bug#45835: (gnu machine digital-ocean) installs old Guix

[Ricardo Wurmus]

The (oddly named) procedure “guix-infect” in (gnu machine digital-ocean)
contains a Bash script that installs Guix 1.0.1 and sets the
GUILE_LOAD_PATH to that of Guile 2.2.

Likewise, “add-static-networking” in the same module sets
GUILE_LOAD_PATH to 2.2.

It seems to me that this should be updated to install the latest version
of Guix and set the load path to that of Guile 3.0.

I also wonder if there might not be a better way to deploy Guix quickly,
for example by using a relocatable pack of Guix and using “guix copy”
instead of executing a shell script.

-- 
Ricardo

bug#45830: Assert, that user and group names are unique -> breaks guix system reconfigure

[Leo Prikler]

Hello again,
Am Mittwoch, den 13.01.2021, 00:23 +0100 schrieb Leo Prikler:
> Hi Jonathan,
> 
> Am Mittwoch, den 13.01.2021, 00:03 +0100 schrieb Jonathan Brielmaier:
> > Hi Leo,
> > 
> > your commit a3002104:
> > system: Assert, that user and group names are unique.
> > 
> > breaks `guix system reconfigure` for me and other people (at least
> > two
> > in IRC).
> > 
> > $ guix system reconfigure config.scm
> > guix system: error: the following groups appear more than once: lp
> > 
> > $ sudo grep lp /etc/group
> > lp:x:989:
> > 
> > lpadmin:x:975:
> > 
> > $ sudo grep lp /etc/passwd
> > lp:!:18467::
> It would seem you have two or more services adding an lp group then. 
> Or one service and a manually defined one.
> 
> > The same happend on my server with the `nginx` group.
> Same problem here; you're probably adding an nginx group twice in
> some
> way.  This is especially concerning, given that it's groups twice –
> for
> some reason nothing is adding additional users or else that check
> would
> have been triggered first.
> 
> > I reverted it for the mean time, as I find it pretty grave...
> I would have preferred, if you could instead have demoted it to a
> warning.  I understand, that stuff suddenly breaking can be
> frustrating, but I doubt the configurations you're using are fine.
> 
> > ~Jonathan
> Regards,
> Leo
I've re-applied the patch with errors demoted to warnings.  I hope you
and the other people, who've reported this in IRC will be able to
figure out where the duplicate groups come from.

Regards,
Leo

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

[Julien Lepiller]

Le Tue, 12 Jan 2021 22:46:34 +,
Christopher Baines  a écrit :

> Leo Famulari  writes:
> 
> > Recently, many people on the #guix IRC channel reported frequent
> > non-deterministic failures of any operation involving substitution,
> > like this:
> >
> > --
> > $ ./pre-inst-env guix build --no-grafts poezio mpdris2 sonata
> > beets-bandcamp beets substitute: 
> > guix build: error: got unexpected path `Backtrace:' from substituter
> > --
> >
> > `guix describe` reports commit
> > b4384e61165623b16b77b8cab16c81423c6853ed for both my user's Guix
> > and the guix-dameon.  
> 
> I might have managed to reproduce the error happening on the daemon
> side:
> 
> →
> /gnu/store/4j8vn0gbqz5adj1y02nnwcfwmqsjgj8s-guix-1.2.0-6.799f066/bin/guix
> substitute --query info
> /gnu/store/3c01q1f16kljfry70qjg6cs6k8winfzg-guix-package-cache
> /gnu/store/6lk8anal4s62gk3d30vgxppykbd5jcfj-guix-85e97c969
> /gnu/store/9zl2zbh3q2jnbfvxgnhw8j3f637ni7z4-guix-cli
> /gnu/store/ihricijvy16zwkd2n671xlyrn02sqhf9-guix-manual
> /gnu/store/m3j427qnlp81vsdj3x9ds7s4i051r1vz-guix-system-tests
> /gnu/store/mbv9j7wwqvwnr5awzbi126jdsj3h64h5-guix-packages
> /gnu/store/n2m1ay7kpa5f4fls4vvcy46ar1fdl0wk-guix-system
> /gnu/store/p4q9ajlb3l7x8xglqs6fflch2iwjqwaj-guix-module-union
> /gnu/store/snhx33fgjj2xnc5vy96sr3c8jqw9c7s0-guix-85e97c969-modules
> /gnu/store/vnrlvz9pxl5qrpy5x8y51v6awz7yzn8q-guix-packages-base
> /gnu/store/z4wj18vyzaas2yqb0577cc3japy4fi7z-guix-config
> /gnu/store/zdjfbsj1a94vdbbg9r0cx4jcqnwxazxs-guix-translated-texinfo
> Backtrace: In ice-9/boot-9.scm: 1736:10  5 (with-exception-handler _
> _ #:unwind? _ # _) In unknown file: 4 (apply-smob/0 # 7f23d4f2e380>) In ice-9/boot-9.scm: 718:2  3 (call-with-prompt _ _
> 7f23d4f2e380>#) In ice-9/eval.scm:
> 7f23d4f2e380>619:8  2 (_ #(#(# 7f23d4f2e380>7f23d4b70f00>))) In guix/ui.scm: 2127:12  1
> 7f23d4f2e380>7f23d4b70f00>(run-guix-command _ . _) In
> 7f23d4f2e380>7f23d4b70f00>guix/scripts/substitute.scm: 1256:4  0
> 7f23d4f2e380>7f23d4b70f00>(guix-substitute . _)
> 
> guix/scripts/substitute.scm:1256:4: In procedure guix-substitute:
> Throw to key `bad-response' with args `("Bad Response-Line: ~s"
> (""))'.
> 
> 
> It's hard to tell if that's actually consistent with the error
> though. Repeating the same test after the restart of guix-publish on
> ci.guix.gnu.org works without printing a backtrace.

During the issue, I tried to manually check what berlin had to say:

$ curl https://ci.guix.gnu.org/3c01q1f16kljfry70qjg6cs6k8winfzg.narinfo
-D-
HTTP/1.1 500 Internal Server Error Server: nginx
Date: Tue, 12 Jan 2021 22:34:01 GMT
Transfer-Encoding: chunked
Connection: keep-alive

and after the restart:

$ curl https://ci.guix.gnu.org/3c01q1f16kljfry70qjg6cs6k8winfzg.narinfo
-D-
HTTP/1.1 404 Not Found Server: nginx
Date: Tue, 12 Jan 2021 22:34:44 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 61
Connection: keep-alive

Resource not found: /3c01q1f16kljfry70qjg6cs6k8winfzg.narinfo



So I tried to learn more about what happens, so I put the first
response in a file, `response`. I used netcat to provide the file over
the network:

nc -l -p 8080 < response

then I tried the following:

$ guix build /gnu/store/3c01q1f16kljfry70qjg6cs6k8winfzg-random
--substitute-urls=http://localhost:8080
substitute: 
guix build: error: got unexpected path `Backtrace:' from substituter

Then, I restarted the daemon to pass it this substitute url:
# guix-daemon --build-users-group=guixbuild
--substitute-urls=http://localhost:8080

and from another terminal:

$ /gnu/store/wr0shvj2dy8h8w2m1pil9r9798ai6nyy-guix-command substitute
--query info
/gnu/store/3c01q1f16kljfry70qjg6cs6k8winfzg-guix-package-cache
Backtrace: 2 (primitive-load "/gnu/store/wr0shvj2dy8h8w2m1pil9r9798a…")
In guix/ui.scm:
  2127:12  1 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
   1256:4  0 (guix-substitute . _)

guix/scripts/substitute.scm:1256:4: In procedure guix-substitute:
In procedure =: Wrong type argument in position 1: #f


So my backtrace is different. For some reason, it seems that guile
cannot read anything from the body of that response, but I don't know
what's happening:

In the REPL, the following:

,m (guix scripts substitute)
(call-with-input-file "response"
  (lambda (port)
(let* ((r (read-response port))
   (body (response-body-port r)))
  (pk 'body body 'r r)
  (get-u8 body

Gives a backtrace:

;;; (body # r #< version: (1 . 1)
code: 500 reason-phrase: "Internal Server Error Server: nginx" headers:
((date . #) (transfer-encoding (chunked))
(connection keep-alive)) port: #>)

ice-9/boot-9.scm:1669:16: In procedure raise-exception: In procedure =:
Wrong type argument in position 1: #f

In ice-9/ports.scm:
   445:17  3 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In unknown file:
   2 (get-u8 #)
In web/http.scm:
  1978:17  1 (read! #vu8(115 99 104 101 109 101 64 40 103 117 105 …) …)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

HTH!

bug#45836: cups-service-type duplicates lp group

[Leo Prikler]

Hello Guix,

it has come to my attention due to the recent reporting of #45830 and
some conversation in IRC, that cups-service-type adds an lp group,
which is already defined in %base-groups.  Since both share the same
definition, this is not too big an issue, but it prohibits us from
using a hard error for #45770.

I can currently think of two solutions: Either remove the lp group from
cups-service-type or remove it from base-groups.  Neither sounds
particularly awesome.  Perhaps we could also delete identical
duplicates before asserting that there are none for #45770, but that
sounds like a little much effort.  Any ideas how else to solve this?

Regards,
Leo

bug#40887: No substitutes for libreoffice / vigra

[Maxim Cournoyer]

Hi Leo!

Leo Famulari  writes:

> On Sun, Jan 10, 2021 at 11:56:23PM -0500, Maxim Cournoyer wrote:
>> While there are currently substitutes available for both vigra and
>> libreoffice, I've raised the max-silent-time timeout value from 1 h to 2
>> h in a25896bb7576c8232acc7a3fd4da0b1cba89569b.  Hopefully that'll help
>> keeping the problem at bay.
>
> Does Cuirass honor this property? In the past, the timeout and
> max-silent-time properties were ignored by Cuirass:
>
> https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00209.html

Thanks for pointing me to that.  I wasn't aware Cuirass didn't honor it,
compared to Hydra.  I grepped the code base and found in (guix ci):

--8<---cut here---start->8---
(define* (package->alist store package system
 #:optional (package-derivation package-derivation))
  "Convert PACKAGE to an alist suitable for Hydra."
  (parameterize ((%graft? #f))
(let ((drv (package-derivation store package system
   #:graft? #f)))
  `((derivation . ,(derivation-file-name drv))
(log . ,(log-file store (derivation-file-name drv)))
(outputs . ,(filter-map (lambda (res)
  (match res
((name . path)
 `(,name . ,path
(derivation->output-paths drv)))
(nix-name . ,(derivation-name drv))
(system . ,(derivation-system drv))
(description . ,(package-synopsis package))
(long-description . ,(package-description package))

;; XXX: Hydra ignores licenses that are not a  structure or a
;; list thereof.
(license . ,(let loop ((license (package-license package)))
  (match license
((? license?)
 (license-name license))
((lst ...)
 (map loop license)

(home-page . ,(package-home-page package))
(maintainers . ("bug-guix@gnu.org"))
(max-silent-time . ,(or (assoc-ref (package-properties package)
   'max-silent-time)
3600))  ;1 hour by default
(timeout . ,(or (assoc-ref (package-properties package) 'timeout)
72000))  ;20 hours by default
--8<---cut here---end--->8---

which led me to believe it was honored.  Perhaps the question of having
Cuirass do per package session should be revisited; it seems useful to
be able to configure this setting per-package rather than globally.

Thank you!

Maxim