bug#46942: ci.guix.gnu.org is slow from my system

[zimoun]

Hi,

On Sat, 06 Mar 2021 at 00:23, raid5atemyhomework 
 wrote:
> Hi zimoun,
>
> Thanks, this is a definite improvement and I have set both systems to
> use it as the first item in `substitute-server`. I'll make a patch for
> the manual at least, then close this issue once that patch is
> accepted.

Ok.


> So I was thinking of modifying the installer so at least some page
> offers up options for mirrors. However, because of the way the
> installer works, it would have to be done by `(gnu installer
> services)`, which does not use `modify-services` on the base service
> list. 

[...]

> Is that something that has any chance of getting accepted into Guix?
> I'd rather not do any coding unless this has any chance at all of
> getting merged in. 

>From my point of view, I will get a better chance for an answer if you
ask on guix-devel with an appropriate subject, rather in (relatively)
long thread inside a bug report with a subject out this very
question. My 2 cent. ;-)


Cheers,
simon

bug#46580: vim-full fails to build

[zimoun]

On Fri, 05 Mar 2021 at 20:29, zimoun  wrote:
> Hi again,
>
> Fix with patch: .

Patch pushed as c8cbd369eb512b0bc5cc0d5dfc2b5d35da50aa4f.

Thanks for the report.


Cheers,
simon

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Hi zimoun,

Thanks, this is a definite improvement and I have set both systems to use it as 
the first item in `substitute-server`. I'll make a patch for the manual at 
least, then close this issue once that patch is accepted.

So I was thinking of modifying the installer so at least some page offers up 
options for mirrors. However, because of the way the installer works, it would 
have to be done by `(gnu installer services)`, which does not use 
`modify-services` on the base service list.

What the installer expects is that services will have their own `(service 
 )` entry, without modifying the base service type.

What I *want* to do would be to have an extensible 
`guix-substitute-url-service-type`.  Unfortunately the existing 
`guix-service-type` accepts a list of build directories to `chroot`.

So here's a sketch:

* Create a new `guix-daemon-service-type` and move most of the 
`guix-service-type` code into it.
  * This is extensible; extensions provide a procedure which accepts a 
`` record and outputs a `` record.
  * `(compose (cut apply compose <>))`
  * `(extend (lambda (config modifier) (modifier config)))`
* Create a new `guix-build-chroot-service-type` which just extends 
`guix-daemon-service-type`:
  * `(service-extension guix-daemon-service-type (lambda (build-chroots) 
(lambda (guix-config) (guix-configuration (inherit guix-config) 
(chroot-directories (append (guix-configuration-chroot-directories guix-config) 
build-chroots))`
* `(define-deprecated guix-service-type guix-build-chroot-service-type)`
  * I mean seriously why does Guix assume only one configuration field of a 
base system service is usefully extensible, it seems to me that the general 
pattern should be that basic system service types should be extensible by a 
procedure that accepts an existing configuration record and returns a modified 
configuration record, then just define individual service types for each 
list-of-foo field of the configuration record to make a convenient way to 
extend such lists.
* Create a new `guix-substitute-url-service-type` similar to 
`guix-build-chroot-service-type`, which prepends a list of substitute URLs to 
the one in the configuration.

Then finally in the installer side:

* in `(gnu installer services)` add something like:
  * `(system-service (name (G_ "https://mirrors.sjtug.sjtu.edu.cn/guix/ (SJTUG, 
China)")) (type 'substitute-url) (snippet '((simple-service 
guix-substitute-url-service-type (list 
"https://mirrors.sjtug.sjtu.edu.cn/guix/";)`
  * `(system-service (name (G_ "https://ci.guix.gnu.org (Guix, Germany) - no 
mirror") (type 'substitute-url) (snippet '(`
* In `(gnu installer newt services)`, add a page for substitute URL mirrors, 
probably a `run-listbox-selection-page`.
  * `(G_ "You can select a mirror that is nearer to you for faster updating of 
packages. The main Guix substitute server, https://ci.guix.gnu.org/, will 
always be set as a fallback, so even if the mirror goes down, you can still 
upgrade from the main Guix substitute server.")`

Is that something that has any chance of getting accepted into Guix? I'd rather 
not do any coding unless this has any chance at all of getting merged in.

Thanks
raid5atemyhomework

bug#46942: ci.guix.gnu.org is slow from my system

[zimoun]

Hi,

On Fri, 05 Mar 2021 at 22:57, raid5atemyhomework 
 wrote:

> Would it not be appropriate to somehow put a list of such substitute
> servers (even if it is currently only a single mirror) somewhere
> official, like the Guix manual? I suppose if Peng Mei Yu thinks this
> mirror would be maintained long term? 

It was something discussed in the mentioned thread.  But no one took the
time to send a patch for the manual or the cookbook.  Feel free to do. :-)

Nice if it improves the situation for you.

Do you consider the problem (bug report) is solved?  In order to close it.


Cheers,
simon

bug#46269: first guix-pull on foreign distro doesn't create directories

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Alexandre Rogers 写道：

On 05/03/2021 20:33, Leo Famulari wrote:
Can you clarify, what commit of did you use to create that ISO? 
You can

check with `guix describe` or `guix --version`.


I downloaded the aforementioned ISO file from guix.gnu.org.


Please, answer the question.  We can't help you if you don't.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#46269: first guix-pull on foreign distro doesn't create directories

[Alexandre Rogers]

On 05/03/2021 20:33, Leo Famulari wrote:


On Thu, Mar 04, 2021 at 11:33:41PM +0100, Edgar Vincent wrote:

Hello everyone,

I've encountered this issue with a fresh installation of Guix System, from
the following ISO: `gk3mcnyallckwvi8f33idv2klj3lj8nw-image.iso`.

I think the bug is fixed for "current" Guix, from the Git master branch.
Can you clarify, what commit of did you use to create that ISO? You can
check with `guix describe` or `guix --version`.


Hello,

I downloaded the aforementioned ISO file from guix.gnu.org.

EV

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Hi zimoun,

> Hi,
>
> On Fri, 05 Mar 2021 at 14:46, raid5atemyhomework 
> raid5atemyhomew...@protonmail.com wrote:
>
> > Are there any other mirror substitute servers aside from `ci.guix.gnu.org`?
>
> Well, only one in China I AFAIK.
>
> https://mirrors.sjtug.sjtu.edu.cn/guix
>
> Seehttps://yhetil.org/guix/87czz24ilu@riseup.net for details.


Thank you very much, an experimental `wget` shows I get much higher speeds from 
this:

```
$ wget 
https://mirror.sjtu.edu.cn/guix/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0
--2021-03-06 06:45:10--  
https://mirror.sjtu.edu.cn/guix/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0
Resolving mirror.sjtu.edu.cn (mirror.sjtu.edu.cn)... 111.186.58.212, 
2001:da8:8000:7100::322:a
Connecting to mirror.sjtu.edu.cn (mirror.sjtu.edu.cn)|111.186.58.212|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 57048561 (54M) [application/octet-stream]
Saving to: ‘1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0.3’

1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0.3   
100%[=>]
  54.41M  3.82MB/sin 17s

2021-03-06 06:45:31 (3.21 MB/s) - 
‘1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0.3’ saved [57048561/57048561]

```

I will try it out as the first server in `--substitute-urls`.

Would it not be appropriate to somehow put a list of such substitute servers 
(even if it is currently only a single mirror) somewhere official, like the 
Guix manual? I suppose if Peng Mei Yu thinks this mirror would be maintained 
long term?

Thanks
raid5atemyhomework

bug#46942: ci.guix.gnu.org is slow from my system

[Leo Famulari]

Right, I meant that the required information would likely make it
possible to determine this person's location. Or at least make a good
guess.

On Fri, Mar 05, 2021 at 04:53:33PM -0500, Julien Lepiller wrote:
> Actually, location usually has nothing to do with it (unless someone dug a 
> hole right in the middle of optic fibers, but you'd notice). The most 
> important info is AS (basically, which ISP you're using, but some have more 
> than one AS). We don't need your IP, but ISP might be already too revealing 
> for your taste.
> 
> Le 5 mars 2021 14:40:10 GMT-05:00, Leo Famulari  a écrit :
> >On Fri, Mar 05, 2021 at 11:22:17AM +, raid5atemyhomework via Bug
> >reports for GNU Guix wrote:
> >> Downloading substitutes from ci.guix.gnu.org is slow from my two
> >Guix-using computers.
> >> 
> >> One is a pure Guix System install without any channels, the other one
> >is a foreign Guix install with the-channel-that-cannot-be-named.
> >> 
> >> 
> >> ```
> >> downloading from
> >https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0
> >...
> >>  wine64-6.0  54.4MiB 
> >  10KiB/s 01:55 [  ]   2.1%
> >> ```
> >
> >Sometimes we get reports like this, of strangely slow downloads from
> >ci.guix.gnu.org. They don't seem to depend on geography. They sometimes
> >happen to people who usually download quickly from ci.guix.gnu.org. So
> >far, we don't have any idea why they happen. But, it's not just you.
> >
> >You are the first person to file a detailed bug report about it, if I
> >remember correctly (if!). If you'd like to help debug it, let us know,
> >but it would probably mean identifying your IP / location.

bug#46942: ci.guix.gnu.org is slow from my system

[Julien Lepiller]

Actually, location usually has nothing to do with it (unless someone dug a hole 
right in the middle of optic fibers, but you'd notice). The most important info 
is AS (basically, which ISP you're using, but some have more than one AS). We 
don't need your IP, but ISP might be already too revealing for your taste.

Le 5 mars 2021 14:40:10 GMT-05:00, Leo Famulari  a écrit :
>On Fri, Mar 05, 2021 at 11:22:17AM +, raid5atemyhomework via Bug
>reports for GNU Guix wrote:
>> Downloading substitutes from ci.guix.gnu.org is slow from my two
>Guix-using computers.
>> 
>> One is a pure Guix System install without any channels, the other one
>is a foreign Guix install with the-channel-that-cannot-be-named.
>> 
>> 
>> ```
>> downloading from
>https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0
>...
>>  wine64-6.0  54.4MiB 
>  10KiB/s 01:55 [  ]   2.1%
>> ```
>
>Sometimes we get reports like this, of strangely slow downloads from
>ci.guix.gnu.org. They don't seem to depend on geography. They sometimes
>happen to people who usually download quickly from ci.guix.gnu.org. So
>far, we don't have any idea why they happen. But, it's not just you.
>
>You are the first person to file a detailed bug report about it, if I
>remember correctly (if!). If you'd like to help debug it, let us know,
>but it would probably mean identifying your IP / location.

bug#46934: emacsy-minimal fails to build

[Xinglu Chen]

On Fri, Mar 05 2021, Maxime Devos wrote:

> On Thu, 2021-03-04 at 22:37 +0100, Xinglu Chen wrote:
>> Hi,
>> 
>> While trying to install Nomad, the emacsy-minimal packages fails to
>> build.
>> 
>> [...]
>>
>> Since emacsy-minimal uses the gnu-build-system, I thought that
>> `autoreconf` would already be available in the build environment, no?
>
> gnu-build-system does not imply "autoconf" as a native-input.
> gnu-build-system refers to packages that have a "./configure && make
> && make check && make install" build system, these do not necessarily
> use autoconf and automake.  And when they do, the generated
> Makefile.in and configure script are often included in the release
> tarball, in which case gnu-build-system does not try to call
> "autoreconf".

Thanks for the explanation!

> I propose the attached patch, which seems to let "emacsy-minimal" build
> (on top of commit 4bc9a1f4e3bd39302b4ceaab8589a2e6ef82c4bd in my case).
> I've also fixed a build input of nomad (wrong variant of gnutls).  I can
> now start nomad!

Great, it works for me too.  Would you mind sending the patch to the
guix-patches mailing list?

bug#46952: "guix build --keep-failed" and offloading

[Léo Le Bouter via Bug reports for GNU Guix]

Hello!

I noticed using --keep-failed implies that offloading is disabled. For
development of GNU Guix I offload all compilation from my laptop to a
powerful server, not having offload with --keep-failed makes it
troublesome to debug issues.

I don't know if it's easy to implement but would be nice to download
the temporary build directory along with all dependents at the end of
the build instead of disabling offloading.

What do you think?

Thank you


signature.asc
Description: This is a digitally signed message part

bug#46942: ci.guix.gnu.org is slow from my system

[Leo Famulari]

On Fri, Mar 05, 2021 at 11:22:17AM +, raid5atemyhomework via Bug reports 
for GNU Guix wrote:
> Downloading substitutes from ci.guix.gnu.org is slow from my two Guix-using 
> computers.
> 
> One is a pure Guix System install without any channels, the other one is a 
> foreign Guix install with the-channel-that-cannot-be-named.
> 
> 
> ```
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 
> ...
>  wine64-6.0  54.4MiB  
>
> 10KiB/s 01:55 [  ]   2.1%
> ```

Sometimes we get reports like this, of strangely slow downloads from
ci.guix.gnu.org. They don't seem to depend on geography. They sometimes
happen to people who usually download quickly from ci.guix.gnu.org. So
far, we don't have any idea why they happen. But, it's not just you.

You are the first person to file a detailed bug report about it, if I
remember correctly (if!). If you'd like to help debug it, let us know,
but it would probably mean identifying your IP / location.

bug#46580: vim-full fails to build

[zimoun]

Hi again,

Fix with patch: .


On Fri, 05 Mar 2021 at 19:30, zimoun  wrote:

> However, I am not sure to understand how all the machinery works.  For
> instance, I do not understand why:
>
>((#:make-flags flags)
> `("LDFLAGS=-lexpat"))
>
> raises the backtrace:
>
> --8<---cut here---start->8---
> Backtrace:

[...]

> ice-9/eval.scm:217:33: In procedure lp:
> Wrong type to apply: "LDFLAGS=-lexpat"
> --8<---cut here---end--->8---
>
> Explanations welcome. :-)

Well, that’s a quote/unquote dance.  The valid way is:

((#:make-flags flags)
 `(list "LDFLAGS=-lexpat"))

Cheers,
simon

bug#46269: first guix-pull on foreign distro doesn't create directories

[Leo Famulari]

On Thu, Mar 04, 2021 at 11:33:41PM +0100, Edgar Vincent wrote:
> Hello everyone,
> 
> I've encountered this issue with a fresh installation of Guix System, from
> the following ISO: `gk3mcnyallckwvi8f33idv2klj3lj8nw-image.iso`.

I think the bug is fixed for "current" Guix, from the Git master branch.
Can you clarify, what commit of did you use to create that ISO? You can
check with `guix describe` or `guix --version`.

bug#46949: bug report

[Leo Famulari]

On Fri, Mar 05, 2021 at 05:17:43PM +0100, Christoph Unger wrote:
> ./guix/store.scm:1043:9: ERROR:
>   1. &store-protocol-error:
>   message: "error parsing derivation
> `/gnu/store/0ywrcn2akd43rlqsvz3zry167zn3ws0f-guix-locale-guix-packages.drv':
> expected string `Derive(['"
>   status: 1

Can you send that file:

'/gnu/store/0ywrcn2akd43rlqsvz3zry167zn3ws0f-guix-locale-guix-packages.drv'?

bug#46934: emacsy-minimal fails to build

[Maxime Devos]

On Thu, 2021-03-04 at 22:37 +0100, Xinglu Chen wrote:
> Hi,
> 
> While trying to install Nomad, the emacsy-minimal packages fails to
> build.
> 
> [...]
>
> Since emacsy-minimal uses the gnu-build-system, I thought that
> `autoreconf` would already be available in the build environment, no?

gnu-build-system does not imply "autoconf" as a native-input.
gnu-build-system refers to packages that have a "./configure && make && make 
check
&& make install" build system, these do not necessarily use autoconf
and automake.  And when they do, the generated Makefile.in and configure
script are often included in the release tarball, in which case
gnu-build-system does not try to call "autoreconf".

(IMHO gnu-build-system should always regenerate configure and Makefile.in
except when it causes bootstrapping problems, but that's a separate matter.)

I propose the attached patch, which seems to let "emacsy-minimal" build
(on top of commit 4bc9a1f4e3bd39302b4ceaab8589a2e6ef82c4bd in my case).
I've also fixed a build input of nomad (wrong variant of gnutls).  I can
now start nomad!

> Any help would be appreciated!

It is a known issue, but it seems to have slippen through the cracks.

Greetings, Maxime.
-- 
Maxime Devos 
PGP Key: C1F3 3EE2 0C52 8FDB 7DD7  011F 49E3 EE22 1917 25EE
Freenode handle: mdevos
*Not* a guix committer
From c4057074960a525389f781cc30d8c2b82c2e48e5 Mon Sep 17 00:00:00 2001
From: Maxime Devos 
Date: Fri, 5 Mar 2021 20:03:19 +0100
Subject: [PATCH] gnu: nomad: Fix build.

Fixes: .
Fixes: .

* gnu/packages/guile-xyz.scm
  (emacsy-minimal)[native-inputs]: Add autotools inputs and
  use guile-2.2 instead of guile-3.0.
  (nomad)[inputs]: Use the guile2.2 version of gnutls.
---
 gnu/packages/guile-xyz.scm | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 45b3a82d00..9c237da8f7 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -3254,6 +3254,11 @@ in C using Gtk+-3 and WebKitGtk.")
  (sha256
   (base32 "03ym14g9qhjqmryr5z065kynqm8yhmvnbs2djl6vp3i9cmqln8cl"
   (build-system gnu-build-system)
+  (native-inputs
+   `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("guile" ,guile-2.2)
+ ,@(alist-delete "guile" (package-native-inputs emacsy
   (inputs
`(("guile" ,guile-2.2)
  ("guile-lib" ,guile2.2-lib)
@@ -,7 +3338,7 @@ perform geometrical transforms on JPEG images.")
("guile-lib" ,guile2.2-lib)
("guile-readline" ,guile2.2-readline)
("guile-gcrypt" ,guile2.2-gcrypt)
-   ("gnutls" ,gnutls)
+   ("guile-gnutls" ,guile2.2-gnutls)
("g-golf" ,g-golf)
("shroud" ,shroud)
("emacsy" ,emacsy-minimal)
-- 
2.30.1



signature.asc
Description: This is a digitally signed message part

bug#46949: bug report

[Christoph Unger]

./guix/store.scm:1043:9: ERROR:
  1. &store-protocol-error:
  message: "error parsing derivation
`/gnu/store/0ywrcn2akd43rlqsvz3zry167zn3ws0f-guix-locale-guix-packages.drv':
expected string `Derive(['"
  status: 1
guix pull: error: You found a bug: the program
'/gnu/store/s6p57kg8c8qyxkl5s15z8vi87hic1iq4-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"92894e64a00cf4b907a1045905032c53d52c8202"; system: "x86_64-linux";
host version: "1.2.0"; pull-version: 1).
Please report it by email to .

bug#46938: ruby-memory-profiler test-failure on x86

[Christopher Howard]

Hi, this transformation does build successfully when I pass it to `guix
build', so that is encouraging. However, I am still stuck with my
problem, as it seems that `guix system' does not accept `--with-input'
as an argument, so I do not know how to integrate this into my system
reconfigure.

bug#46942: ci.guix.gnu.org is slow from my system

[zimoun]

Hi,

On Fri, 05 Mar 2021 at 14:46, raid5atemyhomework 
 wrote:

> Are there any other mirror substitute servers aside from `ci.guix.gnu.org`?

Well, only one in China I AFAIK.

   

See  for details.


All the best,
simon

bug#46580: vim-full fails to build

[zimoun]

Hi,

On mar., 16 févr. 2021 at 23:49, Alex  wrote:

> I encountered issue recently with upgrading and (later) clean install of 
> vim-full.

Indeed, the package is broken.  The commit
988ac06ce8cf9b1760094e0e2ff23960355d07eb introduces the fix:

   ;; Fix test_signals.vim. https://github.com/vim/vim/issues/7402
   #:make-flags (list "CFLAGS=-D_REENTRANT")

which breaks “#:make-flags '("LDFLAGS=-lexpat")” in vim-full.  More
specifically, the package vim-full contains duplicate #:make-flags in
its argument.  For instance,

--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.5
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(gnu packages vim)
scheme@(guix-user)> ,pp (package-arguments vim-full)
$1 = (#:configure-flags
 (list (string-append
 "--with-lua-prefix="
 (assoc-ref %build-inputs "lua"))
   "--with-features=huge"
   "--enable-python3interp=yes"
   "--enable-perlinterp=yes"
   "--enable-rubyinterp=yes"
   "--enable-tclinterp=yes"
   "--enable-luainterp=yes"
   "--enable-cscope"
   "--enable-sniff"
   "--enable-multibyte"
   "--enable-xim"
   "--disable-selinux"
   "--enable-gui")
 #:make-flags
 '("LDFLAGS=-lexpat")
 #:test-target
 "test"
 #:parallel-tests?
 #f
 #:make-flags
 (list "CFLAGS=-D_REENTRANT")
 #:phases
 (modify-phases
   (modify-phases
[...]
--8<---cut here---end--->8---

Attached a fix.  Well, at least the package vim-full now builds.  Since
I am not a Vim user, could you confirm that with patch, the vim-full
package is functional?  If yes, I will submit the patch to guix-patches.

However, I am not sure to understand how all the machinery works.  For
instance, I do not understand why:

   ((#:make-flags flags)
`("LDFLAGS=-lexpat"))

raises the backtrace:

--8<---cut here---start->8---
Backtrace:
In ice-9/eval.scm:
   191:35 19 (_ #f)
   214:21 18 (_ #f)
   217:50 17 (lp (# ?))
   217:50 16 (lp (# ?))
   217:50 15 (lp (# ?))
   217:50 14 (lp (# ?))
   217:50 13 (lp (# ?))
   217:50 12 (lp (# ?))
   217:50 11 (lp (# ?))
   217:50 10 (lp (# ?))
   217:50  9 (lp (# ?))
   217:50  8 (lp (# ?))
   217:50  7 (lp (# ?))
   217:50  6 (lp (# ?))
   217:50  5 (lp (# ?))
   217:50  4 (lp (# ?))
   217:50  3 (lp (# ?))
   217:50  2 (lp (# ?))
   217:33  1 (lp (# ?))
Exception thrown while printing backtrace:
In procedure frame-local-ref: Argument 2 out of range: 1

ice-9/eval.scm:217:33: In procedure lp:
Wrong type to apply: "LDFLAGS=-lexpat"
--8<---cut here---end--->8---

Explanations welcome. :-)


Cheers,
simon

diff --git a/gnu/packages/vim.scm b/gnu/packages/vim.scm
index 372d470e09..a638f05908 100644
--- a/gnu/packages/vim.scm
+++ b/gnu/packages/vim.scm
@@ -9,6 +9,7 @@
 ;;; Copyright © 2019 Julien Lepiller 
 ;;; Copyright © 2019, 2020 Jakub Kądziołka 
 ;;; Copyright © 2020 Jack Hill 
+;;; Copyright © 2021 Simon Tournier 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -216,11 +217,14 @@ with the editor vim.")))
  "--enable-xim"
  "--disable-selinux"
  "--enable-gui")
-   ;; This flag fixes the following error:
-   ;; .../libpython3.7m.a(pyexpat.o): undefined reference to symbol 'XML_FreeContentModel'
-   ;; .../libexpat.so.1: error adding symbols: DSO missing from command line
-   #:make-flags '("LDFLAGS=-lexpat")
,@(substitute-keyword-arguments (package-arguments vim)
+   ;; This flag fixes the following error:
+   ;; .../libpython3.7m.a(pyexpat.o): undefined reference to symbol 'XML_FreeContentModel'
+   ;; .../libexpat.so.1: error adding symbols: DSO missing from command line
+   ((#:make-flags flags)
+`(append
+  '("LDFLAGS=-lexpat")
+  (delete "CFLAGS=-D_REENTRANT" ,flags))) ; Fix .
((#:phases phases)
 `(modify-phases ,phases
(add-before 'check 'start-xserver

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[YLC]

Thank you for your help! Everything goes fine now.

bug#46938: ruby-memory-profiler test-failure on x86

[Julien Lepiller]

Looks like I can reproduce the issue with -s i686-linux. I tried to build using 
Ruby 2.7 (we use 2.6 by default, and tests pass)

You can test with: --with-input=ruby@2.6=ruby@2.7

I'm not a Ruby user, so I won't risk sending a patch. Probably, since it's used 
only by rubocop as a native input, we can safely use a differert ruby package 
for this?

Le 4 mars 2021 20:46:52 GMT-05:00, Christopher Howard 
 a écrit :
>I'm trying to install mate desktop on a 32 bit x86 laptop. This
>evidently is dependent on gnome-shell building, which in turn is
>dependent on ruby-memory-profiler, which does not build due to three
>test failures.
>"""   /gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-profiler-
>1.0.0.drv
>building /gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-
>profiler-1.0.0.drv...builder for
>`/gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-profiler-
>1.0.0.drv' failed with exit code 1build of
>/gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-profiler-
>1.0.0.drv failedView build log at
>'/var/log/guix/drvs/v3/zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-
>profiler-1.0.0.drv.bz2'.cannot build derivation
>`/gnu/store/q8l4d3qxz8vghv5i526zckqa31xrx11n-ruby-rubocop-1.10.0.drv':
>1 dependencies couldn't be builtbuilding
>/gnu/store/vynlki5k7r2y3950xdihxr3cdi9rn47p-ruby-rubocop-ast-1.4.1-
>checkout.drv...cannot build derivation
>`/gnu/store/2yy6q52ximcm8zxyw9xdpiayc7b0mnlx-ruby-rdoc-6.2.0.drv': 1
>dependencies couldn't be builtcannot build derivation
>`/gnu/store/jxg83183dmms1w5id7kqbi1alvpyyf64-ruby-terminfo-0.1.1.drv':
>1 dependencies couldn't be builtcannot build derivation
>`/gnu/store/nsq3ydsz5rpqjg2qbpq2zggmxvxf3xbg-ruby-sass-3.6.0.drv': 1
>dependencies couldn't be builtcannot build derivation
>`/gnu/store/k25lm8nxsiba262y92ps802n79f8x5dz-gnome-shell-3.34.2.drv': 1
>dependencies couldn't be builtguix system: error: build of
>`/gnu/store/k25lm8nxsiba262y92ps802n79f8x5dz-gnome-shell-3.34.2.drv'
>failed"""
>My system info:"""$ neofetch --stdoutroot@mithril  OS: Guix
>System 1.2.0-8.7624ebb i686 Host: CF-30CTQAZBM 001 Kernel: 5.10.2-
>gnu Uptime: 2 hours, 43 mins Packages: 66 (guix-system) Shell: bash
>5.0.16 Resolution: 1024x768 Terminal: .emacs-27.1-rea CPU: Genuine
>Intel L2400 (2) @ 1.667GHz GPU: Intel Mobile 945GM/GMS/GME, 943/940GML
>Express Memory: 72MiB / 3013MiB
>$ guix describeGeneration 2Mar 04 2021 05:58:22(current)  guix
>bc10203repository URL: https://git.savannah.gnu.org/git/guix.git   
> branch: mastercommit: bc10203475ede3f88416a7614b7e9343fca8de75"""
>Build log attached.

bug#46844: guile2.2-bytestructures fails to compile.

[Maxime Devos]

On Wed, 2021-03-03 at 15:56 +0100, Taylan Kammer wrote:
> On 01.03.2021 15:47, Taylan Kammer wrote:
> [...]
> I haven't yet updated the Guix package for bytestructures.  I'm quite
> out of the loop and don't remember which branch that should be pushed,
> given it's a dependency of Guix and all.  Is it always safe to push to
> master?  (With regard to rebuilding the whole world.)

Let's see what would be rebuilt:

$ guix refresh --list-dependent guile-bytestructures guile2.0-bytestructures 
guile2.2-bytestructures

Building the following 15 packages would ensure 19 dependent packages are 
rebuilt: guile-wiredtiger@0.7.0 guile-libyaml@0-1.f5d33a6 
guile-parted@0.0.4 guix-data-service@0.0.1-25.b7ba8d0 
guix-minimal@1.2.0-13.a53f711 cuirass@0.0.1-72.543e26a 
emacs-guix@0.5.2-3.a694fdb 
guix-jupyter@0.2.1 guix-build-coordinator@0-20.1f79fc3 gwl@0.3.0 
hpcguix-web@0.0.1-5.9de6356 guix-daemon@1.2.0-13.a53f711 
guile2.0-git@0.4.0 guile2.2-parted@0.0.4 guile2.2-guix@1.2.0-13.a53f711

I suggest you run "./pre-inst-env guix build guix" first to make sure guix can 
still
be built, but otherwise there shouldn't be any issue with pushing to master.

Maxime.


signature.asc
Description: This is a digitally signed message part

bug#44187: whishlist: time-machine --channel falls back to SWH

[Ludovic Courtès]

Hi,

zimoun  skribis:

> Let’s describe the use case.  Consider that:
>
>   guix time-machine -C channels -- install foo
>
> is provided in some documentation, say scientific paper.  Where the
> channels.scm file is completly described:
>
> (list (channel
> (name 'kikoo)
> (url "https://example.org/that-great.git";)
> (commit
>   "353bdae32f72b720c7ddd706576ccc40e2b43f95")))
>
> In the future, if https://example.org/that-great.git disappears, then
> build/install the package ’foo’ is becoming difficult, nor impossible.
>
> However, let’s consider that the repo ’that-great’ had been saved in SWH
> (say manually); since it is a regular Git repo.  Guix should be able to
> fallback to it transparently.

I went head-down to add SWH fallback to ‘latest-repository-commit’… but
that’s of no use because (guix channels) wants a complete clone so that
it can determine commit relations (to detect downgrades).

The SWH vault gives access to checkouts primarily, but it’s also
possible to get a full repo in ‘git fast-import’ format, which is what
we need:

  https://archive.softwareheritage.org/api/1/vault/revision/gitfast/doc/

However, this API will be eventually replaced by some other solution say
SWH developers, possibly a bare Git repo export, so it may not be a good
idea to build upon it.

If we were able, using the SWH API, to map “revisions” to “origins”, we
could find potential mirrors hosting a given commit, but apparently
that’s not possible.

To be continued…

Ludo’.


diff --git a/guix/git.scm b/guix/git.scm
index a5103547d3..449011c51a 100644
--- a/guix/git.scm
+++ b/guix/git.scm
@@ -32,6 +32,7 @@
   #:use-module (guix records)
   #:use-module (guix gexp)
   #:use-module (guix sets)
+  #:autoload   (guix swh) (swh-download)
   #:use-module ((guix diagnostics) #:select (leave))
   #:use-module (guix progress)
   #:use-module (rnrs bytevectors)
@@ -459,22 +460,43 @@ Log progress and checkout info to LOG-PORT."
   (eq? 'regular (stat:type stat))
 
   (format log-port "updating checkout of '~a'...~%" url)
-  (let*-values
-  (((checkout commit _)
-(update-cached-checkout url
-#:recursive? recursive?
-#:ref ref
-#:cache-directory
-(url-cache-directory url cache-directory
- #:recursive?
- recursive?)
-#:log-port log-port))
-   ((name)
-(url+commit->name url commit)))
-(format log-port "retrieved commit ~a~%" commit)
-(values (add-to-store store name #t "sha256" checkout
-  #:select? (negate dot-git?))
-commit)))
+
+  (catch 'git-error
+(lambda ()
+  (let*-values
+  (((checkout commit _)
+(update-cached-checkout (pk 'l-r-c url)
+#:recursive? recursive?
+#:ref ref
+#:cache-directory
+(url-cache-directory url cache-directory
+ #:recursive?
+ recursive?)
+#:log-port log-port))
+   ((name)
+(url+commit->name url commit)))
+(format log-port "retrieved commit ~a~%" commit)
+(values (add-to-store store name #t "sha256" checkout
+  #:select? (negate dot-git?))
+commit)))
+(lambda (key err . rest)
+  ;; XXX: 'swh-download' currently doesn't support submodules.
+  (when recursive?
+(apply throw key err rest))
+
+  (pk 'err key err rest)
+  (match ref
+(('commit . commit)
+ ;; Attempt to fetch COMMIT from SWH.
+ (call-with-temporary-directory
+  (lambda (directory)
+(unless (swh-download url commit directory)
+  (apply throw key err rest))
+(values (add-to-store store (url+commit->name url commit)
+  #t "sha256" directory)
+commit
+(_
+ (apply throw key err rest))
 
 (define (print-git-error port key args default-printer)
   (match args

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Hi all,

In case it's useful, here's my `traceroute`, would this be helpful for Guix?

I erased some internal IP addresses and omit a few bytes off the source 
country. After hop 25 `traceroute` couldn't find anything anymore. I annotated 
the IP addresses to country map.

```
$ sudo `which traceroute` 141.80.181.40
traceroute to 141.80.181.40 (141.80.181.40), 64 hops max
  1 3.140ms  0.947ms  0.981ms
  2 2.527ms  1.571ms  1.416ms
  3 4.318ms  4.705ms  3.680ms
  4   .4.16  2.605ms  1.856ms  1.963ms
  5   .1.205  2.177ms  2.087ms  1.876ms
  6   .3.54  29.090ms  30.237ms  28.982ms
  7   203.208.168.129  29.200ms  29.497ms  30.863ms # Singapore Singapore 
Telecommunications Pte Ltd
  8   203.208.152.82  29.295ms  29.231ms  29.227ms  # Singapore SingTel 
Internet Exchange
  9   203.208.182.249  30.769ms  31.872ms  47.615ms # Singapore Singapore 
Telecommunications Pte Ltd
 10   203.208.183.133  30.271ms  30.713ms  31.635ms # Singapore Singapore 
Telecommunications Pte Ltd
 11   203.208.158.178  363.911ms  301.844ms  204.896ms  # Singapore SingTel 
Internet Exchange
 12   203.208.172.234  213.664ms  298.038ms  213.798ms  # Singapore Singapore 
Telecommunications Pte Ltd
 13   *  *  *
 14   *  *  *
 15   *  *  *
 16   *  *  *
 17   *  *  *
 18   64.125.28.36  335.579ms  499.267ms  411.078ms # Netherlands Zayo 
Bandwidth
 19   *  *  *
 20   64.125.28.36  349.449ms  347.413ms  432.726ms # Netherlands Zayo 
Bandwidth
 21   80.81.193.222  334.576ms  334.150ms  335.696ms# Germany DE-CIX 
Management GmbH
 22   64.125.26.173  343.767ms  344.376ms  344.544ms# Germany Zayo Bandwidth
 23   188.1.238.78  375.499ms  346.705ms  417.986ms # Germany Verein zur 
Foerderung eines Deutschen Forschungsnetzes e.V.
 24   141.80.238.11  339.792ms  383.421ms  406.579ms# Germany Campus 
Berlin-Buch GmbH
 25   188.1.146.210  410.225ms  334.844ms  335.196ms# Germany Verein zur 
Foerderung eines Deutschen Forschungsnetzes e.V.
```

The big increase in ping times is somewhere inside Singapore, which seems like 
a reasonable assumption that it's what is throttling bandwidth. A quick 
research shows Singapore Telecommunications Pte Ltd is the same as SingTel 
Internet Exchange.

Are there any other mirror substitute servers aside from `ci.guix.gnu.org`?

Thanks
raid5atemyhomework

bug#45599: using guix to install packages from inside a container that runs on foreign distro breaks guix and the foreign distro

[david larsson]

On 2021-03-04 10:14, Ludovic Courtès wrote:

Hi David,

Looks like this bug report fell through the cracks of the turn of year…

david larsson  skribis:


upon starting it with sudo /gnu/store/asdfasdfasdf-run-container


and connecting to it with

sudo guix container exec 8625 /run/current-system/profile/bin/bash
--login
[sudo] password for david:
root@MinimalSSH /#
root@MinimalSSH /#
root@MinimalSSH /# guix package -i hello


[...]


error: executing
`/gnu/store/qyjhy4bkz51jyspi63llfznsnz7vibzy-guix-1.1.0-30.875c01f/bin/guix
substitute': No such file or directory
guix package: error: unexpected EOF reading a line
root@MinimalSSH /#
root@MinimalSSH /# exit
logout
guix container: error: exec failed with status 1
david@l560:~/VirtualHome/src$ guix package -i hello
bash: /usr/local/bin/guix:
/gnu/store/b7rixb64yp00znz0d5rwd5zzklwzlzmv-guile-wrapper/bin/guile:
bad interpreter: No such file or directory


It looks as though the store item for Guix or Guile used on the host 
had

been suddenly wiped, even though we don’t see any GC activity or
similar.


As you can see, guix is now broken on both the host and guest system.


Were you able to better see what was broken?  Is it that store items
were removed?  Are there issues with non-Guix files?  It would be great
if you could gather more details as to what’s wrong.  I’ll also see if 
I

can try that in a VM.


No, unfortunately I couldn't find any reason. I repeated it a few times 
with the same results but I no longer have access to the VM I tested 
this on so I can't help with more details, sorry :/


If it does not happen when you try it (if you do), I would be glad to 
hear about so I can call this a fluke and attribute the bug to special 
unknown circumstances with the particular host system I used.



Best regards,
David

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Hi zimoun,

> Hi,
>
> On Fri, 05 Mar 2021 at 11:22, raid5atemyhomework via Bug reports for GNU Guix 
> bug-guix@gnu.org wrote:
>
> > This can be very slow, including as slow as 4KiB/s at times.
>
> [...]
>
> > The problem is not on my ISP, or at least not solely on my ISP. Doing a 
> > `wget` from `github.com`:
>
> [...]
>
> > As can be seen above, I get 9.34MB/s elsewhere, which is better than the 
> > >60Mbit/s promised by my ISP.
>
> Where are you located? I mean,ci.guix.gnu.org is in Berlin, so if you
> are far, say in Alaska or in Puerto Williams[*], you get a poor
> downloading rate. However, github.com probably uses CDN or something
> like that, so obviously the rate becomes much better.
>
> *Puerto Williams, the World Southest town with an Internet
> connection. :-)

I would rather not say, since I am a very private person (otherwise I wouldn't 
be using the "raid5atemyhomework" moniker).

What I **do** find strange is that ***Tor is faster***.  Surely connecting 
directly from my ISP to ci.guix.gnu.org should be, in principle, faster than 
connecting to my ISP to a random node, which connects to another random node, 
which connects to another random node, which finally connects to Berlin, should 
be ***slower***?

Here are a few `ping`s to some places:

```
$ ping gnu.org
PING gnu.org (209.51.188.148) 56(84) bytes of data.
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=1 ttl=50 time=301 ms
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=2 ttl=50 time=306 ms
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=3 ttl=50 time=335 ms
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=4 ttl=50 time=257 ms
64 bytes from wildebeest.gnu.org (209.51.188.148): icmp_seq=5 ttl=50 time=234 ms
^C
--- gnu.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4226ms
rtt min/avg/max/mdev = 233.804/286.626/335.242/36.261 ms

$ ping www.vikings.net
PING www.vikings.net (168.119.169.112) 56(84) bytes of data.
64 bytes from v0.h.vkgs.io (168.119.169.112): icmp_seq=1 ttl=48 time=190 ms
64 bytes from v0.h.vkgs.io (168.119.169.112): icmp_seq=2 ttl=48 time=190 ms
64 bytes from v0.h.vkgs.io (168.119.169.112): icmp_seq=3 ttl=48 time=220 ms
64 bytes from v0.h.vkgs.io (168.119.169.112): icmp_seq=4 ttl=48 time=241 ms
64 bytes from v0.h.vkgs.io (168.119.169.112): icmp_seq=5 ttl=48 time=264 ms
^C
--- www.vikings.net ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4413ms
rtt min/avg/max/mdev = 189.767/220.941/264.326/29.054 ms

$ ping www.raptorcs.com
PING www.raptorcs.com (23.155.224.44) 56(84) bytes of data.
64 bytes from websvc.rptsys.com (23.155.224.44): icmp_seq=1 ttl=55 time=294 ms
64 bytes from websvc.rptsys.com (23.155.224.44): icmp_seq=2 ttl=55 time=307 ms
64 bytes from websvc.rptsys.com (23.155.224.44): icmp_seq=3 ttl=55 time=227 ms
^C
--- www.raptorcs.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2627ms
rtt min/avg/max/mdev = 226.868/275.933/306.748/35.071 ms
```

And here's a few select `wget`s:

```
$ wget https://store.vikings.net/image/cache/catalog/kcmad8-1088x816.jpeg
--2021-03-05 20:50:37--  
https://store.vikings.net/image/cache/catalog/kcmad8-1088x816.jpeg
Resolving store.vikings.net (store.vikings.net)... 185.199.141.17
Connecting to store.vikings.net (store.vikings.net)|185.199.141.17|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 246991 (241K) [image/jpeg]
Saving to: ‘kcmad8-1088x816.jpeg’

kcmad8-1088x816.jpeg
100%[=>]
 241.20K  19.2KB/sin 13s

2021-03-05 20:50:51 (19.2 KB/s) - ‘kcmad8-1088x816.jpeg’ saved [246991/246991]

$ torify wget https://store.vikings.net/image/cache/catalog/kcmad8-1088x816.jpeg
--2021-03-05 20:51:22--  
https://store.vikings.net/image/cache/catalog/kcmad8-1088x816.jpeg
Resolving store.vikings.net (store.vikings.net)... 185.199.141.17
Connecting to store.vikings.net (store.vikings.net)|185.199.141.17|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 246991 (241K) [image/jpeg]
Saving to: ‘kcmad8-1088x816.jpeg.1’

kcmad8-1088x816.jpeg.1  
100%[=>]
 241.20K   293KB/sin 0.8s

2021-03-05 20:51:25 (293 KB/s) - ‘kcmad8-1088x816.jpeg.1’ saved [246991/246991]

$ wget 
https://static.fsf.org/nosvn/videos/fight-to-repair/videos/Fight-to-Repair-720p.webm
--2021-03-05 20:54:03--  
https://static.fsf.org/nosvn/videos/fight-to-repair/videos/Fight-to-Repair-720p.webm
Resolving static.fsf.org (static.fsf.org)... 209.51.188.233, 2001:470:142:5::233
Connecting to static.fsf.org (static.fsf.org)|209.51.188.233|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 40191351 (38M) [video/webm]
Saving to: ‘Fight-to-Repair-720p.webm’

Fight-to-Repair-720

bug#46942: ci.guix.gnu.org is slow from my system

[zimoun]

Hi,

On Fri, 05 Mar 2021 at 11:22, raid5atemyhomework via Bug reports for GNU Guix 
 wrote:

> This can be very slow, including as slow as 4KiB/s at times.

[...]

> The problem is not on my ISP, or at least not solely on my ISP. Doing a 
> `wget` from `github.com`:

[...]

> As can be seen above, I get 9.34MB/s elsewhere, which is better than the 
> >60Mbit/s promised by my ISP.

Where are you located?  I mean, ci.guix.gnu.org is in Berlin, so if you
are far, say in Alaska or in Puerto Williams[*], you get a poor
downloading rate.  However, github.com probably uses CDN or something
like that, so obviously the rate becomes much better.


*Puerto Williams, the World Southest town with an Internet
 connection. :-)


All the best,
simon

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Hi all,

> > -   Is there a way to make `guix-daemon` use a Tor proxy? I have two 
> > systems using Guix, one is a Guix System, the other is using a foreign 
> > distro, and I'd like to adjust both to use Tor instead since it's faster.
>
> I saw that`guix-daemon` respects `http_proxy` and `https_proxy` envvars, but 
> trying it out on my foreign-distro Guix computer, adding 
> `https_proxy=socks5h://127.0.0.1:9050 http_proxy=socks5h://127.0.0.1:9050` to 
> the `systemd` service file doesn't work.
>
> guix substitute: error: TLS error in procedure 'handshake': The TLS 
> connection was non-properly terminated.
> substitution of /gnu/store/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 
> failed
> guix package: error: some substitutes for the outputs of derivation 
> `/gnu/store/wr9kf2bgcsvwxcmhnl9lf047nr8xcklc-wine64-6.0.drv' failed (usually 
> happens due to networking issues); try `--fallback' to build derivation from 
> source
>
>
> Looking at the foreign distro's syslog:
>
> Mar  5 19:52:03 developer guix-daemon[145182]: accepted connection from 
> pid 145190, user raid5atemyhomework
> Mar  5 19:52:05 developer guix-daemon[145200]: spurious SIGPOLL
> Mar  5 19:52:07 developer Tor[1029]: Socks version 67 not recognized. 
> (This port is not an HTTP proxy; did you want to use HTTPTunnelPort?)
>
>
> So it looks to me that`guix-daemon` expects `https_proxy` to be an HTTPS 
> proxy and not a SOCKS5/SOCKS5H proxy. I'll look into Tor's HTTPTunnelPort.

On the foreign distro computer, adding an `HTTPTunnelPort 9080` to 
`/etc/tor/torrc` and then adding `http_proxy=https://127.0.0.1:9080 
https_proxy=https://127.0.0.1:9080` to `guix-daemon.service`, then restarting 
services, seems to work.

```
ownloading from 
https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 ...
 wine64-6.0  54.4MiB
579KiB/s 
01:36 [##] 100.0%

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/7mr17xka558smr0c76crf9g727ccj76g-profile.drv

3.2 MB will be downloaded
downloading from 
https://ci.guix.gnu.org/nar/lzip/gs3li4m0ydajm57r0qn1wvsdyfsa68p7-font-gnu-unifont-13.0.06
 ...
 font-gnu-unifont-13.0.06  3.0MiB   
515KiB/s 
00:06 [##] 100.0%

```

The above is significantly better than the previous runs where I get 11KiB/s, 
and matches the speeds I get from `torify wget`.

While it's a good ***workaround*** for my problem instead of me silently 
weeping at the ridiculous slowness of Guix substitutes, it doesn't solve my 
root problem:

* SOMETHING between my ISP and ci.guix.gnu.org is throttling access to the 
substitutes.
  * Given that I have been using my ISP for a year without experiencing such 
spurious slowdowns, and I have been using ci.guix.gnu.org for the past few 
months only and have been hit with this slowness in the past month or so, I am 
more inclined to blame ci.guix.gnu.org, but please tell me how I can find out 
what is throttling the bandwidth here.  The fact that Tor is ***FASTER*** is 
very suspicious.

Thanks
raid5atemyhomework

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

> * Is there a way to make `guix-daemon` use a Tor proxy?  I have two systems 
> using Guix, one is a Guix System, the other is using a foreign distro, and 
> I'd like to adjust both to use Tor instead since it's faster.

I saw that `guix-daemon` respects `http_proxy` and `https_proxy` envvars, but 
trying it out on my foreign-distro Guix computer, adding 
`https_proxy=socks5h://127.0.0.1:9050 http_proxy=socks5h://127.0.0.1:9050` to 
the `systemd` service file doesn't work.

```
guix substitute: error: TLS error in procedure 'handshake': The TLS connection 
was non-properly terminated.
substitution of /gnu/store/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 failed
guix package: error: some substitutes for the outputs of derivation 
`/gnu/store/wr9kf2bgcsvwxcmhnl9lf047nr8xcklc-wine64-6.0.drv' failed (usually 
happens due to networking issues); try `--fallback' to build derivation from 
source
```
Looking at the foreign distro's syslog:

```
Mar  5 19:52:03 developer guix-daemon[145182]: accepted connection from pid 
145190, user raid5atemyhomework
Mar  5 19:52:05 developer guix-daemon[145200]: spurious SIGPOLL
Mar  5 19:52:07 developer Tor[1029]: Socks version 67 not recognized. (This 
port is not an HTTP proxy; did you want to use HTTPTunnelPort?)
```

So it looks to me that `guix-daemon` expects `https_proxy` to be an HTTPS proxy 
and not a SOCKS5/SOCKS5H proxy. I'll look into Tor's HTTPTunnelPort.

Thanks
raid5atemyhomework

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Hello Christopher,

> raid5atemyhomework via Bug reports for GNU Guix bug-guix@gnu.org writes:
>
> > Downloading substitutes from ci.guix.gnu.org is slow from my two Guix-using 
> > computers.
> > One is a pure Guix System install without any channels, the other one is a 
> > foreign Guix install with the-channel-that-cannot-be-named.
> >
> > downloading from 
> > https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0
> >  ...
> >  wine64-6.0  54.4MiB
> > 
> >  10KiB/s 01:55 [  ]   2.1%
> >
>
> If you try this same download again, do you get the same speed?
>
> guix publish, which is used on ci.guix.gnu.org can dynamically create
> nars if they're not cached, which will probably result in slower
> download speeds.

Yes, I have been suffering slow download speeds for a few weeks now.  Even with 
repeated downloads, it is consistently slow.  I only just now tried out using 
`torify wget`, which surprised me since it was much much faster --- one lucky 
download even got up to 6MB/s over frikking TOR before I ^Ced it.  I've even 
tried doing `torify wget` and `wget` in parallel on two separate shells --- the 
`torify wget` was definitely faster, getting anywhere from 100kB/s to 700kB/s 
with a few outliers at >1MB/s, while `wget` was consistently below 40kB/s and 
eventually settling to ~11kB/s after a few seconds.

This holds even for packages I expect to be popular and thus likely to be 
in-cache with high probability, like `linux-libre`.

Thanks
raid5atemyhomework

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[pelzflorian (Florian Pelz)]

Hello all,

On Mon, Mar 01, 2021 at 11:06:59AM +0100, Ludovic Courtès wrote:
> Florian, could it be that we’re not normalizing language tags
> appropriately?  Does that ring a bell?

The attached patch to maintenance.git fixes the remaining minor issue:
Now Accept-Language language codes get normalized, zh to zh-CN, so web
browsers requesting any kind of Chinese get the website in mainland
Chinese.  (This is a minor issue.  The only valid URL is /zh-CN/ since
my last patch to guix-artwork because I don’t know how to
rewrite/redirect URLs in nginx.)

The patch was tested on a berlin VM.

There is no copyright header in maintenance.git’s
hydra/nginx/berlin.scm so I did not add a copyright.  I hereby license
the patch CC0
.

Shall I just push?  A reconfigure of berlin will be necessary but is
not urgent.

Regards,
FlorianFrom: Florian Pelz 
Date: Thu, 4 Mar 2021 20:29:27 +0100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] nginx: berlin: Normalize Accept-Language language code zh to
 zh-CN.

Now web browsers requesting any kind of Chinese get the website in
mainland Chinese.

zh, zh-Hans, zh-Hans-CN all are synonymous with zh-CN now.

* hydra/nginx/berlin.scm (accept-languages): New procedure.
(%extra-content): Normalize $lang variable with it.
---
 hydra/nginx/berlin.scm | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 85aaf38..4b9d297 100644
--- a/hydra/nginx/berlin.scm
+++ b/hydra/nginx/berlin.scm
@@ -995,12 +995,37 @@ PUBLISH-URL."
(uri "~ /(.*)")
(body (list "return 301 $scheme://guixwl.org/$1;"
 
+(define (accept-languages language-lists)
+  "Returns nginx configuration code to set up the $lang variable
+according to the Accept-Language header in the HTTP request.  The
+requesting user agent will be served the files at /$lang/some/url.
+Each list in LANGUAGE-LISTS starts with the $lang and is followed by
+synonymous IETF language tags that should be mapped to the same $lang."
+  (define (language-mappings language-list)
+(define (language-mapping language)
+  (string-join (list ""  language (car language-list) ";")))
+(string-join (map language-mapping language-list) "\n"))
+
+  (let ((directives
+ `(,(string-join
+ `("set_from_accept_language $lang_unmapped"
+   ,@(map string-join language-lists)
+   ";"))
+   "map $lang_unmapped $lang {"
+   ,@(map language-mappings language-lists)
+   "}")))
+(string-join directives "\n")))
+
 (define %extra-content
   (list
"default_type  application/octet-stream;"
"sendfileon;"
 
-   "set_from_accept_language $lang en de es fr zh-CN;"
+   (accept-languages '(("en")
+   ("de")
+   ("es")
+   ("fr")
+   ("zh-CN" "zh" "zh-Hans" "zh-Hans-CN")))
 
;; Maximum chunk size to send.  Partly this is a workaround for
;; , but also the nginx docs mention that
-- 
2.30.1

bug#46942: ci.guix.gnu.org is slow from my system

[Christopher Baines]

raid5atemyhomework via Bug reports for GNU Guix  writes:

> Downloading substitutes from ci.guix.gnu.org is slow from my two Guix-using 
> computers.
>
> One is a pure Guix System install without any channels, the other one is a 
> foreign Guix install with the-channel-that-cannot-be-named.
>
>
> ```
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 
> ...
>  wine64-6.0  54.4MiB  
>
> 10KiB/s 01:55 [  ]   2.1%
> ```

If you try this same download again, do you get the same speed?

guix publish, which is used on ci.guix.gnu.org can dynamically create
nars if they're not cached, which will probably result in slower
download speeds.


signature.asc
Description: PGP signature

bug#46942: ci.guix.gnu.org is slow from my system

[raid5atemyhomework via Bug reports for GNU Guix]

Downloading substitutes from ci.guix.gnu.org is slow from my two Guix-using 
computers.

One is a pure Guix System install without any channels, the other one is a 
foreign Guix install with the-channel-that-cannot-be-named.


```
downloading from 
https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 ...
 wine64-6.0  54.4MiB
 10KiB/s 
01:55 [  ]   2.1%
```

This can be very slow, including as slow as 4KiB/s at times. This is fairly 
awful since sometimes I get this result:

```
downloading from 
https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 ...
 wine64-6.0  54.4MiB
 49KiB/s 
06:01 [# ]  31.9%guix substitute: error: TLS error in procedure 
'read_from_session_record_port': Error decoding the received TLS packet.
substitution of /gnu/store/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0 failed
guix package: error: some substitutes for the outputs of derivation 
`/gnu/store/wr9kf2bgcsvwxcmhnl9lf047nr8xcklc-wine64-6.0.drv' failed (usually 
happens due to networking issues); try `--fallback' to build derivation from 
source
```

Because of the failed incomplete download, I have to ***restart the download 
again from 0%***, which is awful, awful UX. It would be really nice if:

1. The guix download process would make an effort to ***retry*** this a few 
times.
2. Continue the previous download instead of restarting from 0%.

The problem is not on my ISP, or at least not solely on my ISP. Doing a `wget` 
from `github.com`:

```
$ wget 
https://github.com/zfsonlinux/zfs/releases/download/zfs-2.0.3/zfs-2.0.3.tar.gz
--2021-03-05 17:39:46--  
https://github.com/zfsonlinux/zfs/releases/download/zfs-2.0.3/zfs-2.0.3.tar.gz
Resolving github.com (github.com)... 13.229.188.59
Connecting to github.com (github.com)|13.229.188.59|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: 
https://github.com/openzfs/zfs/releases/download/zfs-2.0.3/zfs-2.0.3.tar.gz 
[following]
--2021-03-05 17:39:47--  
https://github.com/openzfs/zfs/releases/download/zfs-2.0.3/zfs-2.0.3.tar.gz
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 302 Found
Location: 
https://github-releases.githubusercontent.com/437011/71526a80-6ba3-11eb-893f-4ceb55b479d6?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210305%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210305T093947Z&X-Amz-Expires=300&X-Amz-Signature=9454446348219aa0731af009a5232bf5772e3d45a3a34052fa61f64f04c3c979&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=437011&response-content-disposition=attachment%3B%20filename%3Dzfs-2.0.3.tar.gz&response-content-type=application%2Foctet-stream
 [following]
--2021-03-05 17:39:47--  
https://github-releases.githubusercontent.com/437011/71526a80-6ba3-11eb-893f-4ceb55b479d6?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210305%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210305T093947Z&X-Amz-Expires=300&X-Amz-Signature=9454446348219aa0731af009a5232bf5772e3d45a3a34052fa61f64f04c3c979&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=437011&response-content-disposition=attachment%3B%20filename%3Dzfs-2.0.3.tar.gz&response-content-type=application%2Foctet-stream
Resolving github-releases.githubusercontent.com 
(github-releases.githubusercontent.com)... 185.199.108.154, 185.199.109.154, 
185.199.110.154, ...
Connecting to github-releases.githubusercontent.com 
(github-releases.githubusercontent.com)|185.199.108.154|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13114404 (13M) [application/octet-stream]
Saving to: ‘zfs-2.0.3.tar.gz’

zfs-2.0.3.tar.gz
100%[=>]
  12.51M  9.34MB/sin 1.3s

2021-03-05 17:39:49 (9.34 MB/s) - ‘zfs-2.0.3.tar.gz’ saved [13114404/13114404]

```

As can be seen above, I get 9.34MB/s elsewhere, which is better than the 
>60Mbit/s promised by my ISP.

It's possible that the problem is between my ISP and ci.guix.gnu.org. If I 
`wget` directly:

```
$ wget 
https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0
--2021-03-05 18:56:21--  
https://ci.guix.gnu.org/nar/lzip/1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0
Resolving ci.guix.gnu.org (ci.guix.gnu.org)... 141.80.181.40
Connecting to ci.guix.gnu.org (ci.guix.gnu.org)|141.80.181.40|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 57048561 (54M) [application/octet-stream]
Saving to: ‘1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0’

1bdldr80p39g1mjnh76xw6hmwqrrb8lz-wine64-6.0   0%[   
  

bug#46829: Fresh install of 1.2.0 can't guix pull

[Christopher Baines]

zimoun  writes:

> Hi Chris,
>
> On Sun, 28 Feb 2021 at 10:27, Christopher Baines  wrote:
>> I believe there's TLS issues with pulling for the current 1.2.0
>> release.
>
> Is this bug different from ?
>
> And fixes are also discussed here:
> .

Yes, this bug is about a problem with guix pull, whereas #44559 relates
to a specific issue building the gnutls package.


signature.asc
Description: PGP signature