bug#21843: Generated grub.cfg does not support encrypted roots

[Christopher Baines]

On 01/05/16 23:07, Ludovic Courtès wrote:

l...@gnu.org (Ludovic Courtès) skribis:


Now, I haven’t tested this in reality and would appreciate help here.


I’m in the process of implementing automated tests for the installation
process.


I've been looking at this bug, as I've got a new laptop which I would 
like to install GuixSD on, and I would like to use an encrypted root 
partition.


Regarding the system tests, it looks to me like they do exist now, but 
so far I've been unable to run them (I get an error related to hash 
mismatch of module-import-compiled, I want to try getting it to 
fallback, but first I need to work out where Guix is being invoked...).

bug#25118: All ruby packages replaced by version 2.3.3

[Christopher Baines]

On master (8f35c0306192c4b62646f2aa02879c2a8c4f4a07), as ruby 2.3.1 is
replaced by 2.3.3, and all ruby packages inherit from ruby 2.3.1, all
versions of ruby end up being 2.3.3.

For example:
→ guix environment --container --ad-hoc --pure -e "(begin (use-modules
(gnu packages ruby)) ruby-2.1)" -- ruby --version

ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux]

Removing the replacement line, or adding (replacement #f) to the other
packages fixes this.



signature.asc
Description: OpenPGP digital signature

bug#25213: Character encoding issue causing broken symlinks for profile generation

[Christopher Baines]

The profile generation/union code generates broken symlinks. I've 
reproduced this on 2 different machines (both Debian running Guix).


To reproduce, run:

  guix environment --pure --container --ad-hoc nss-certs findutils 
coreutils


[env]# find $GUIX_ENVIRONMENT/etc/ssl/certs -xtype l -exec head {} \;

head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/Certinomis_-_Autorit??_Racine:2.1.1.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??RKTRUST_Elektronik_Sertifika_Hizmet_Sa??lay??c??s??_H6:2.6.125.161.242.101.236.138.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??B??TAK_UEKAE_K??k_Sertifika_Hizmet_Sa??lay??c??s??_-_S??r??m_3:2.1.17.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??RKTRUST_Elektronik_Sertifika_Hizmet_Sa??lay??c??s??_H5:2.7.0.142.23.254.36.32.129.pem' 
for reading: No such file or directory


Note the ?? in the names, which are the points where the names are 
incorrect.


This will cause errors like Throw to key `gnutls-error' with args 
`(# when using Guix.

bug#25200: guix lint throws gnutls error

[Christopher Baines]

On 15/12/16 16:15, Ludovic Courtès wrote:
> Hi Maxim!
> 
> Maxim Cournoyer  skribis:
> 
>> I'm using an up-to-date Guix (running directly from the Git tree) and
>> recently started getting the following gnutls errors when attempting to
>> run "guix lint some-package". This happens for any package.
>>
>> The complete error traceback returned on the console looks like:
>>
>>  guix lint icecat
>> gnu/packages/gnuzilla.scm:304:2: icecat-45.5.1-gnu1: file names of patches 
>> should start with the package name
> 
> [...]
> 
>> In guix/scripts/lint.scm:
>>  786: 4 [check-vulnerabilities #]
>>  781: 3 [# #]
>> In unknown file:
>>?: 2 [force #> ()>>]
>> In guix/scripts/lint.scm:
>>  770: 1 [#]
>> In ice-9/boot-9.scm:
>>  160: 0 [catch srfi-34 #> ()> ...]
>>
>> ice-9/boot-9.scm:160:17: In procedure catch:
>> ice-9/boot-9.scm:160:17: Throw to key `gnutls-error' with args 
>> `(# 
>> set-certificate-credentials-x509-trust-file!)'.

I hit this on Wednesday, I think its a problem in the profile generation
code, related to character encoding, and possibly to do with locales.

It was triggered by the recent nss-certs update, but I don't think that
has anything to do with it, apart from introducing some files with names
including non-ascii characters.

I've filed bug#25213 about this which includes instructions to reproduce it.



signature.asc
Description: OpenPGP digital signature

bug#25453: Inconsistent keyboard layout affecting encrypted root

[Christopher Baines]

I'm using a UK keyboard layout with a computer that I recently installed
GuixSD on with a encrypted root parition. Immediately after installation
when I attempted to boot in to the new system for the first time I had
to enter the passphrase twice, and in doing this, first I had to use the
keyboard layout under which I carried out the installation (the layout
which I had intended to use), and then during the early boot stage of
the system I had to enter the passphrase using a different keyboard
layout.

The ideal behaviour here is that the way in which the passphrase is set
in the installer is the way in which it has to be entered into Grub and
during the early boot of the system. 


signature.asc
Description: PGP signature

bug#27990: Offloading repeatedly prints a message of the form "process ... acquired build slot '/var/guix/offload/.../0"

[Christopher Baines]

Hey,

I gave setting up offloading another go, I'm testing with 3 machines,
two running GuixSD, and one Debian. I've tried setting up offloading
from both GuixSD machines to the Debian machine, and from one GuixSD
machine to the other.

Running `guix offload test` works, and reports success. However, when
it actually comes to building something, guix repeatedly prints a
message like:

  "process ... acquired build slot '/var/guix/offload/.../0"

I've left it for a while, and nothing happened.

My usual approach at sticking more logging in to the code doesn't
really work, as it appears that it's not the offload script from the
Guix git repository that I have locally that is being used.

I'm happy to do some more investigation, but I haven't worked out how
to yet.


pgpCuDEeSW_Ie.pgp
Description: OpenPGP digital signature

bug#28144: info-dir ERROR: no code for module (guix build utils)

[Christopher Baines]

I've had the following issue a few times now, it seems that somehow,
the info-dir builder can be incorrectly generated, without the usual
module import stuff.

The most recent time this occurred, I worked around this by finding the
guix package in the store which I thought was being used at the time,
and explicitly garbage collected it (guix gc -d ...). I then rebuilt
it, and this seemed to work around the problem. I was using the same
guix package, pinned to an revision in a git repository.


The builder starts with:

  (begin (use-modules (guix build utils)


This is the error which you get:

The following derivations will be built:
   /gnu/store/8qi10kwz4ghabdj5p7s252z11snvhhgf-profile.drv
   /gnu/store/0jxiph2hvmvakcj6gkz9d00a8ncma903-info-dir.drv
Backtrace:
In ice-9/boot-9.scm:
 160: 18 [catch #t # ...]
In unknown file:
   ?: 17 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 16 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 15 [eval # #]
In ice-9/boot-9.scm:
2412: 14 [save-module-excursion #]
4089: 13 [#]
1734: 12 [%start-stack load-stack #]
1739: 11 [#]
In unknown file:
   ?: 10 [primitive-load 
"/gnu/store/9ywpf5jc12svv04gvbx96j5z1kpllwn4-info-dir-builder"]
In ice-9/eval.scm:
 505: 9 [# (begin # # # ...)]
In ice-9/psyntax.scm:
1107: 8 [expand-top-sequence ((begin # # # ...)) () ((top)) ...]
 990: 7 [scan ((begin (use-modules # # ...) (define # #) ...)) () ...]
 990: 6 [scan ((use-modules # # ...) (define # #) (define # #) ...) () ...]
 279: 5 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
In ice-9/boot-9.scm:
3622: 4 [process-use-modules ((#) (#) (#) (#))]
 712: 3 [map # (# # # 
#)]
3623: 2 [# (#)]
2903: 1 [resolve-interface (guix build utils) #:select ...]
In unknown file:
   ?: 0 [scm-error misc-error #f ...]

ERROR: In procedure scm-error:
ERROR: no code for module (guix build utils)
builder for `/gnu/store/0jxiph2hvmvakcj6gkz9d00a8ncma903-info-dir.drv' failed 
with exit code 1


pgpC7ucMQ7CxX.pgp
Description: OpenPGP digital signature

bug#28144: info-dir ERROR: no code for module (guix build utils)

[Christopher Baines]

On Tue, 22 Aug 2017 10:41:55 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Heya,
> 
> Christopher Baines  skribis:
> 
> > I've had the following issue a few times now, it seems that somehow,
> > the info-dir builder can be incorrectly generated, without the usual
> > module import stuff.
> >
> > The most recent time this occurred, I worked around this by finding
> > the guix package in the store which I thought was being used at the
> > time, and explicitly garbage collected it (guix gc -d ...). I then
> > rebuilt it, and this seemed to work around the problem. I was using
> > the same guix package, pinned to an revision in a git repository.
> >
> >
> > The builder starts with:
> >
> >   (begin (use-modules (guix build utils)
> >
> >
> > This is the error which you get:
> >
> > The following derivations will be built:
> >/gnu/store/8qi10kwz4ghabdj5p7s252z11snvhhgf-profile.drv
> >/gnu/store/0jxiph2hvmvakcj6gkz9d00a8ncma903-info-dir.drv  
> 
> Could you check if the .drv has the right -L and -C flags for guile?
> 
> What commit was this on?
> 
> Looking at (guix profiles), what you describe Cannot Happen™ because
> there’s a correct ‘with-imported-modules’ form there.

I've included the derivation contents below, I can't see the -L and -C
flags, so I'm guessing that they are missing.

As for what commit this is on, this particular occurance took place
when I was using my odd guix-pre-inst-env [1] script that
attempts to create an environment containing a particular version of
Guix, without letting anything from the surrounding environment creep
in, so I'm not really sure what code was in use at the time.

1: https://github.com/alphagov/govuk-guix/blob/master/guix-pre-inst-env

Derive([("out","/gnu/store/fnfm2vv9khyxpsnr7ybn8h7ir2l3685y-info-dir","","")],[("/gnu/store/0l3zxcx0n31xal7jf1d981j377wh3nir-zlib-1.2.11.drv",["out"]),("/gnu/store/0ppzqkwl7ma4s3bz1wvc0s9crd0wbir7-guile-2.2.2.drv",["out"]),("/gnu/store/1wq563kgbhv26f99hq1d2ay7gw8qy3cq-libgc-7.6.0.drv",["out"]),("/gnu/store/2ryhk3mp55dshlgyj53a16x08ifqqlvw-bash-4.4.12.drv",["out"]),("/gnu/store/4rjl58s30zwiahl6ji7bbjxq30yyl9vl-texinfo-6.3.drv",["out"]),("/gnu/store/69b611ifkq1942zvf79d5sszpp8n9w38-libunistring-0.9.7.drv",["out"]),("/gnu/store/94hkgqjvsk689zzhdv9382kh2pkn7mrz-libltdl-2.4.6.drv",["out"]),("/gnu/store/c8zl2wq0jmahcjb2zdf5w5z1i2iangma-guix-gds-release_8.drv",["out"]),("/gnu/store/g2a46givk3s9jlchmq4m1fmnc25qh1c0-git-2.13.1.drv",["out"]),("/gnu/store/hdd0rz201djb0wis4jwrlnjp3kq1f9xq-nss-certs-3.31.drv",["out"]),("/gnu/store/lvkjr70rf8j355igip04z8iglxnl3mkk-guile-ssh-0.11.0.drv",["out"]),("/gnu/store/lw5qrzgh2yxpd58b722ph6f466sn51xm-gmp-6.1.2.drv",["out"]),("/gnu/store/m71zs1cgl0qiyrl5mzrjh60dsg757nvx-guile-2.0.14.drv",["out"]),("/gnu/store/rwgybvpsmrkh6rbz502ac6p6vkfr1jgm-gzip-1.8.drv",["out"]),("/gnu/store/vd7py9zp3s81mg3h0ppm5bkbdcgpn17w-libidn2-0.16.drv",["out"]),("/gnu/store/vk8fhc7x7kc4y6h6gy42idnawxabj8dv-guile2.2-gnutls-3.5.9.drv",["out"]),("/gnu/store/vl1vcbzgplncw4i3sfiglyy1n2ycnwwn-guile-json-0.6.0.drv",["out"]),("/gnu/store/whz1jbvs9ipgkslim63lqw7wdljxlmzg-nettle-3.3.drv",["out"]),("/gnu/store/xdbnmw3kizlx157l76cdb1w6y2kz7yhi-coreutils-8.27.drv",["out"]),("/gnu/store/xs8z1ycvdpmip7rx4xqs8qj56fdblgbk-less-487.drv",["out"]),("/gnu/store/xz2zfvzy2g55wgna0vpwd6zjwfmxn1ms-libtasn1-4.10.drv",["out"])],["/gnu/store/9ywpf5jc12svv04gvbx96j5z1kpllwn4-info-dir-builder"],"x86_64-linux","/gnu/store/3lsfrwlp1qa345x71yw5w49i2mpp0vxm-guile-2.0.14/bin/guile",["--no-auto-compile","/gnu/store/9ywpf5jc12svv04gvbx96j5z1kpllwn4-info-dir-builder"],[("allowSubstitutes","0"),("out","/gnu/store/fnfm2vv9khyxpsnr7ybn8h7ir2l3685y-info-dir"),("preferLocalBuild","1")])


pgpA5clgXvciu.pgp
Description: OpenPGP digital signature

bug#28144: info-dir ERROR: no code for module (guix build utils)

[Christopher Baines]

On Tue, 22 Aug 2017 12:41:26 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Christopher Baines  skribis:
> 
> > bin/guile",["--no-auto-compile","/gnu/store/9ywpf5jc12svv04gvbx96j5z1kpllwn4-info-dir-builder"]
> >   
> 
> Something is indeed wrong here.  I have:
> 
> --8<---cut here---start->8---
> $ cat/gnu/store/0gn0dxgg68w3yc4ywxp586z98h9l00j3-info-dir.drv
> [...]
> bin/guile",["--no-auto-compile","-L","/gnu/store/l4jxniixlkqpy5aaxhgfp4xywsimd6p2-module-import","-C","/gnu/store/gj3ks9vi1ys3hgr1jzywjx2rq3dsmsbd-module-import-compiled","/gnu/store/m4kyr2isfskss2vkc7hvnbw786kd52v9-info-dir-builder"]
> [...] --8<---cut
> here---end--->8---
> 
> Is it reproducible?  Does “make clean-go && make” help?  Is it Guile
> 2.2 or 2.0?

Unfortunately, I've only run in to this when trying to get other stuff
done, and my approach for working around the problem has been to delete
the guix packages from the store to force them to be rebuilt.

I'd previously guessed that the ...-info-dir-builder was wrong, but
knowing that the command in the derivation is wrong is useful. If I
come across this again, I'll try to investigate further, but I don't
have a way of reproducing this at the moment.


pgpk62l2ObPGH.pgp
Description: OpenPGP digital signature

bug#28265: guix system build fails

[Christopher Baines]

On Mon, 28 Aug 2017 21:52:32 +0300
Efraim Flashner  wrote:

> efraim@macbook42:~/workspace/guix$ time nice ./pre-inst-env guix
> system build ~/lightweight-desktop.scm Backtrace:
>   11 (primitive-load
> "/home/efraim/workspace/guix/scripts/gu…") In guix/ui.scm:
>   1331:12 10 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
> 837:9  9 (catch _ _ #
> …) 837:9  8 (catch _ _ #
> …) In guix/scripts/system.scm:
>1022:8  7 (_)
> 905:6  6 (process-action _ _ _)
> In guix/store.scm:
>   1441:24  5 (run-with-store _ _ #:guile-for-build _ #:system _)
> In guix/scripts/system.scm:
> 637:2  4 (_ _)
> In gnu/system.scm:
> 884:4  3 (_ _)
> In gnu/bootloader/grub.scm:
>343:29  2 (grub-configuration-file #< …>
> …) 207:30  1 (eye-candy #< bootloader: #<…>
> …) 149:22  0 (grub-background-image #< bo…>
> …)
> 
> gnu/bootloader/grub.scm:149:22: In procedure grub-background-image:
> gnu/bootloader/grub.scm:149:22: In procedure struct_vtable: Wrong
> type argument in position 1 (expecting struct): 5
> 

I tried this, and got the same error, but then I deleted all the .go
files, re-ran make, and then tried again, and then it worked.

→ ./pre-inst-env guix system build gnu/system/examples/lightweight-desktop.tmpl 
/gnu/store/hqjri2wz5sz32fabv7cr85zirnbsmvjs-system

I'm not quite sure what this means my understanding of Guile is a
bit vague.


pgp2HUVpek322.pgp
Description: OpenPGP digital signature

bug#27990: Offloading is now working!

[Christopher Baines]

I tried again, and after one small change, things are now working!

Firstly, I was getting messages like:

process 1011 acquired build slot '/var/guix/offload/capella.local/0'
;;; [2017/08/31 18:16:40.455763, 0] private-key-from-file: [GSSH ERROR]
The file does not exist or permission denied: "/root/.ssh/id_rsa"


This was coming up over and over again, maybe I was hitting the same
problem, but this GSSH ERROR is something that I haven't seen before.

I had a look at the Guix source, and noticed that the private key to
use is a function of the current user. But as this is the offloader
script, I'm pretty sure that relates to the user of the guix-daemon,
which in my case is root. In my case, I want to offload as my user, so
I set private-key explicitly in /etc/guix/machines.scm, and now it just
works!


pgppa7GzYmIpc.pgp
Description: OpenPGP digital signature

bug#28470: caff in the signing-party package can't find sendmail on GuixSD

[Christopher Baines]

When using caff from the signing-tools pacakge, it looks for sendmail
in the wrong places [1]. It would be useful to find a way to make it
work when installed.

I have found a workaround, which is to specify PERL_MAILERS as
sendmail:$(type -p sendmail), e.g.:

PERL_MAILERS=sendmail:$(type -p sendmail) caff ...

1: /usr/lib/sendmail;/usr/sbin/sendmail;/usr/ucblib/sendmail



pgpA4zqL4xChH.pgp
Description: OpenPGP digital signature

bug#28470: caff in the signing-party package can't find sendmail on GuixSD

[Christopher Baines]

On Mon, 09 Oct 2017 23:37:49 +0200
Ricardo Wurmus  wrote:

> Hi Christopher,
> 
> > When using caff from the signing-tools pacakge, it looks for
> > sendmail in the wrong places [1]. It would be useful to find a way
> > to make it work when installed.
> >
> > I have found a workaround, which is to specify PERL_MAILERS as
> > sendmail:$(type -p sendmail), e.g.:
> >
> > PERL_MAILERS=sendmail:$(type -p sendmail) caff ...
> >
> > 1: /usr/lib/sendmail;/usr/sbin/sendmail;/usr/ucblib/sendmail  
> 
> What is the expected behaviour here?  Does it *only* work with
> sendmail? Or would any mailer (like msmtp) work?  Should the user’s
> default mailer be used or should we embed a reference to a specific
> mailer?

I don't have any expectations, but ideally, it would work without
specifying this environment variable.

I think approaches other than sendmail are supported [1], but I'm
unsure if that includes msmtp.

1: https://metacpan.org/pod/Mail::Mailer#DESCRIPTION

This is probably more about the Mail::Mailer perl package in the
perl-mailtools package, than caff, that just uses Mail::Mailer.

I spent a bit of time looking at the Mail::Mailer source code when
trying to get caff working, but unfortunately, bits of it are still a
bit cryptic to me.


pgpvkk_lUtMpJ.pgp
Description: OpenPGP digital signature

bug#28709: [PATCH 0/4] Content-addressed mirrors for VCS checkouts

[Christopher Baines]

On Tue, 17 Oct 2017 10:48:03 +0200
Ludovic Courtès  wrote:

> Hello,
> 
> Here’s a ready-to-merge patch series.  Once applied, nars
> (aka. “substitutes”) are downloaded and extracted when a VCS checkout
> fails.  This will address cases such as the recent Guile-Git repository
> renaming for people who have disabled substitutes.
> 
> I’m Cc’ing 宋文武 because this also moves the progress-report code to
> a new (guix progress) module.
> 
> Feedback welcome!
> 
> Ludo’.
> 
> Ludovic Courtès (4):
>   download: Remove old-Guile leftovers.
>   download: Make 'http-fetch' public.
>   Add (guix progress).
>   download: Download a nar when a VCS checkout fails.
> 
>  Makefile.am |   2 +
>  guix/build/download-nar.scm | 125 
>  guix/build/download.scm | 216 +
>  guix/cvs-download.scm   |  38 ++--
>  guix/git-download.scm   |  37 +--
>  guix/hg-download.scm|  36 +--
>  guix/progress.scm   | 228 
> 
>  guix/scripts/download.scm   |   4 +-
>  guix/scripts/substitute.scm |   5 +-
>  guix/utils.scm  |  28 +-
>  10 files changed, 470 insertions(+), 249 deletions(-)
>  create mode 100644 guix/build/download-nar.scm
>  create mode 100644 guix/progress.scm
> 

This all sounds good to me Ludo, and I didn't spot anything of note
when looking through the patches.


pgpXvysp674oi.pgp
Description: OpenPGP digital signature

bug#25073: Status: We have no build system for Go

[Christopher Baines]

I'm glad to say that there is now a build system for Go, guix-patches
bug #28586 contains the details.


signature.asc
Description: PGP signature

bug#19144: Please provide a bootable ISO image

[Christopher Baines]

There is now support for generating an ISO image of the installer
system, and I've successfully managed to use it to install GuixSD.

I've marked this as pending, and it can probably be closed once there is
a release of Guix/GuixSD which includes an ISO image installer.


signature.asc
Description: PGP signature

bug#23201: GNOME lock screen hotkey doesn't work

[Christopher Baines]

Chris Marusich  writes:

> I'm using GuixSD v0.10.0 with GNOME.  I'd like to be able to lock my
> screen, but I can't seem to do so.
>
> My settings under GNOME settings > Keyboard > Shortcuts > System lists
> the following hotkey:
>
>  * Lock screen: Super+L
>
> However, when I press Super+L, nothing happens.  Even when I change the
> key binding to something else, it still doesn't work.  I can't find any
> logs in /var/log which shed any light on why this doesn't work.
>
> How can I lock my screen or investigate further why it's not working?

Just to keep this bug up to date, there is a Gnome Display Manager (GDM)
service available, and if you use this, then Super+L does work.

However, the GDM service in GuixSD doesn't currently do any
authentication for some reason, so the "lock" part of locking the screen
is still missing.

Anyway, I think this is the path to solve this, get the GDM working
including authentication, and then make the GDM the default login
manager when using Gnome.


signature.asc
Description: PGP signature

bug#30184: guix publish issue: guix substitute: error: corrupt input while restoring

[Christopher Baines]

Hey,

I think something may have broken recently with the guix publish
service. I run this on a server with very basic configuration, just
setting the host, but I noticed recently that there were problems using
the service. The following example is guix failing to download something
from that server.

Downloading 
http://beid.cbaines.net/nar/gzip/pwg84wqsniamc4vx9c7p06284i5rxiay-wxwidgets-3.0.3...
 wxwidgets-3.0.3   256KiB/s 
00:00 | 16KiB transferred
gzip: stdin: not in gzip format
guix substitute: error: corrupt input while restoring 
'/gnu/store/pwg84wqsniamc4vx9c7p06284i5rxiay-wxwidgets-3.0.3' from #{read pipe}#
 wxwidgets-3.0.3   316KiB/s 
00:00 | 48KiB transferredguix package: error: build failed: some substitutes 
for the outputs of derivation 
`/gnu/store/7f0zr1zgp6q1nyrsxf88qn003gr1w53b-wxwidgets-3.0.3.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source

I reverted the 4 recent changes [1], changed the service configuration
to use (guix (current-guix)) and now it seems to be working again.

I've had a look through the changes, I couldn't spot anything, but I
think there could be a regression in these changes [1].

Thanks,

Chris


1: f396611776e7ed6f1a070569a338ad56461b099e
   152b7beeacb72fe96fd5d3c0fd8b321e247c2c6c
   c04ffadbed741254b8be6b78f23eed150d26
   297e04d66010ada31a40f40143d81bf6b62affcc


signature.asc
Description: PGP signature

bug#30184: guix publish issue: guix substitute: error: corrupt input while restoring

[Christopher Baines]

Ludovic Courtès  writes:

>> I think something may have broken recently with the guix publish
>> service. I run this on a server with very basic configuration, just
>> setting the host, but I noticed recently that there were problems using
>> the service. The following example is guix failing to download something
>> from that server.
>>
>> Downloading 
>> http://beid.cbaines.net/nar/gzip/pwg84wqsniamc4vx9c7p06284i5rxiay-wxwidgets-3.0.3...
>>  wxwidgets-3.0.3   
>> 256KiB/s 00:00 | 16KiB transferred
>> gzip: stdin: not in gzip format
>
> This is fixed in 33988f9b5876e4b44cabe1997a91eb604931c1ca.
>
> I’ll update the ‘guix’ snapshot for those who use the ‘guix-publish’
> service on GuixSD.

Awesome, thanks Ludo :)


signature.asc
Description: PGP signature

bug#41708: "guix weather" : 504 error

[Christopher Baines]

zimoun  writes:

> Dear Chris,
>
> On Mon, 15 Jun 2020 at 21:23, Christopher Baines  wrote:
>> zimoun  writes:
>>> On Mon, 15 Jun 2020 at 19:43, Christopher Baines  wrote:
>
>>>> I believe it's been deployed now. It was working earlier today at least,
>>>> however all of Cuirass seems to be stuck now.
>>>
>>> Well, it seems working.  Feel free to close the bug.
>>
>> Great, closing :)
>
> I do not know if it is only this evening, but something appears wrong:
>
> --8<---cut here---start->8---
> $ guix weather
> computing 13,814 package derivations for x86_64-linux...
> looking for 14,354 store items on https://ci.guix.gnu.org...
> updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> https://ci.guix.gnu.org
>   88.3% substitutes available (12,672 out of 14,354)
>   at least 72,508.1 MiB of nars (compressed)
>   118,880.3 MiB on disk (uncompressed)
>   0.001 seconds per request (12.8 seconds in total)
>   1,123.2 requests per second
>   'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway 
> Time-out")
> --8<---cut here---end--->8---

Did you check if any pages loaded for Cuirass, or was it just this API
endpoint that was timing out?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#39637: Policy to remove broken packages

[Christopher Baines]

Jack Hill  writes:

> On Sat, 20 Jun 2020, Christopher Baines wrote:
>
>> Do you have any examples of packages that are currently broken, and
>> which you'd like to remove?
>
> Perhaps mongo-tools: https://issues.guix.gnu.org/39637
>
> It broke when Go was upgraded to 1.13, and changed the test library. I
> fixed some other Go packages that ran into this issue, but it wasn't
> as easy for mongo-tools. Our version is old, so it should be
> updated. For various reasons, I don't see this package being fixed in
> the short term.

mongo-tools is definitely failing to build, and it has been since the
11th of Feb (2020) I think.

It seems like you got further in understanding this than I did. Given
that this seems like a test failure, and I don't think there's anything
to suggest that the actual functionality doesn't work, the course of
action I see here is to disable either the failing tests, or running the
test suite entirely.

I originally packaged MongoDB and mongo-tools for Guix, but that was
before the licence of MongoDB changed, so I'm not sure about the long
term future of the packages. Keeping the packages we have actually
building though is still useful.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#26302: Deploying the i18n’d web site

[Christopher Baines]

pelzflorian (Florian Pelz)  writes:

> On Thu, Apr 09, 2020 at 08:58:14PM +0200, Bengt Richter wrote:
>> Wondering, could dnsmasq help?
>
> I am already using dnsmasq to access a virtual machine of the machine
> hosting the Guix website so  can replace the
> Guix website while old URLs keep working.

...

> I am confused by all the ways to rewrite, redirect and try_files in
> nginx.  I would be happy if others with more knowledge could help.

Hey Florian,

I'm wondering what the current state of the Guix website translation
work is?

I can see the translated website is available at [1], but maybe not with
the full NGinx configuration needed. I also managed to use haunt
locally, but I noticed there were some merge conflicts between the
wip-i18n and master branch.

1: http://guix.gnu.org/.i18n/en/

I can try and help with the NGinx stuff, I've muddled through
configuring NGinx in the past. I think it might be useful to test
without the /.i18n prefix, maybe berlin can be changed to serve the site
at wip-i18n.guix.gnu.org. I also have a server where I might try
deploying the translated website for testing.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#26302: Deploying the i18n’d web site

[Christopher Baines]

pelzflorian (Florian Pelz)  writes:

> Sorry, I forgot to address the patch tracker.  I wrote some hours ago:
>
> On Thu, Apr 09, 2020 at 07:31:04PM +0200, pelzflorian (Florian Pelz) wrote:
>> On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote:
>> > Hi Florian,
>> >
>> > "pelzflorian (Florian Pelz)"  skribis:
>> >
>> > > +   (redirect "/news/porting-guix-and-guixsd.html" 
>> > > "/$lang/blog/2015/porting-guix-and-guixsd")
>> >
>> > Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG)
>> > will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd?
>> >
>> > It’s important that all the current URL, without /LANG, remain valid.
>>
>> With the new test VM, not all is working.
>>
>> /news/porting-guix-and-guixsd.html fails (code 404).
>>
>> /blog/2015/porting-guix-and-guixsd fails (code 404).
>>
>> /blog/2015/porting-guix-and-guixsd fails (404).
>>
>> But /blog/2015/porting-guix-and-guixsd/ works fine.
>>
>> Well this is difficult to figure out.
>>
>> Regards,
>> Florian
>
> An update:
>
> The attached patch for berlin serves more but not all URLs
> properly when testing on a VM.
>
> I found one problem; the nginx locations for redirecting old URLs can
> be given a higher priority via specifying = before the location path.
>
> I am sorry for neglecting this for so long until Christopher Baines
> offered to help a few days ago.  Now I too started investigating
> myself again.

Thanks for your continued time working on this Florian. I've made a
little bit of progress now, I've taken the wip-i18n branch, applied the
patch attached to this email and deployed that at [1].

1: http://guix-website-test.cbaines.net/

This isn't a close test of the configuration for berlin, but might come
in useful when testing the NGinx configuration.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#42162: Recovering source tarballs

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> There’s this other discussion you mentioned, which I hope will have a
>> positive outcome:
>>
>>   https://forge.softwareheritage.org/T2430
>
> This discussion as well as discussions on #swh-devel have made it clear
> that SWH will not archive raw tarballs, at least not in the foreseeable
> future.  Instead, it will keep archiving the contents of tarballs, as it
> has always done—that’s already a huge service.
>
> Not storing raw tarballs makes sense from an engineering perspective,
> but it does mean that we cannot rely on SWH as a content-addressed
> mirror for tarballs.  (In fact, some raw tarballs are available on SWH,
> but that’s mostly “by chance”, for instance because they appear as-is in
> a Git repo that was ingested.)  In fact this is one of the challenges
> mentioned in
> .
>
> So we need a solution for now (and quite urgently), and a solution for
> the future.
>
> For the now, since 70% of our packages use ‘url-fetch’, we need to be
> able to fetch or to reconstruct tarballs.  There’s no way around it.
>
> In the short term, we should arrange so that the build farm keeps GC
> roots on source tarballs for an indefinite amount of time.  Cuirass
> jobset?  Mcron job to preserve GC roots?  Ideas?

Going forward, being methodical as a project about storing the tarballs
and source material for the packages is probalby the way to ensure it's
available for the future. I'm not sure the data storage cost is
significant, the cost of doing this is probably in working out what to
store, doing so in a redundant manor, and making the data available.

The Guix Data Service knows about fixed output derivations, so it might
be possible to backfill such a store by just attempting to build those
derivations. It might also be possible to use the Guix Data Service to
work out what's available, and what tarballs are missing.

Chris


signature.asc
Description: PGP signature

bug#42291: data service: Show list of files and allow qeuerying

[Christopher Baines]

Hartmut Goebel  writes:

> Serverity: wishlist
> I often find myself checking the content of a package. For this I
> would like to be able to inspect the list of files in a package, or
> even query for a specific file.
>
> This is much like Debian does in "list of files" for each package
> (e.g. 
> )
> and with "Search the contents of packages"
> 
>
> Many thanks :-)

Hi Hartmut,

So, I'm in total agreement that this data would be great to have, but so
far I've not been imagining meeting the need to search the files or
contents of store items through the Guix Data Service.

The contents of a package can also be viewed as the contents of a
directory in the store. The Guix Data Service does know about nars, but
just the information in the narinfo file.

What I've had in mind for a while is a service that listens to the Guix
Data Service for new nars, downloads them, indexes them (either just the
files, or file contents too), and then provides a search interface over
this data. It's a little tricky, as you have to decide what to do about
the build reproducibility problem, if a package doesn't build
reproducibly, it's possible to get multiple different lists of files for
the same package.

At the moment, I'm looking at the "building things" area, but I'm still
interested in this.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#43062: --expose in vm does not reflect file modifications in guest

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> elaexuotee--- via Bug reports for GNU Guix  skribis:
>
>> When using --expose to mirror a path between host and guest, the guest mirror
>> fails to reflect file modifications from the host. However, file creation and
>> deletion are correctly propogated.
>>
>> To pick up file modifications in the guest, it is sufficient to remount
>> mirroring 9p filesystem.
>>
>> Is this behaviour expected?
>
> I believe this comes from the “cache=loose” 9p mount option added in
> commit e0d96774dd48c29ccc4c90fea1f8f71850ab0879.
>
> Does the patch below help?
>
> Chris, what do you think?  How would this affect the performance issues
> that led to e0d96774dd48c29ccc4c90fea1f8f71850ab0879?

Caching only for readonly filesystems sounds fine, I think I was only
thinking about the store for e0d96774dd48c29ccc4c90fea1f8f71850ab0879.


signature.asc
Description: PGP signature

bug#32548: Cuirass: Performance monitoring

[Christopher Baines]

Mathieu Othacehe  writes:

> Hello,
>
>> As discussed earlier today on IRC with Clément, we could add performance
>> monitoring capabilities to Cuirass.  Interesting metrics would be:
>>
>>   • time of push to time of evaluation completion;
>>
>>   • time of evaluation completion to time of build completion.
>
> Small update on that one. With Cuirass commit
> 154232bc767d002f69aa6bb1cdddfd108b98584b, we now have the following
> timestamps:
>
> * Checkout commit time.
> * Evaluation creation.
> * Evaluation checkouts completion.
> * Evaluation completion.
>
> For the first timestamp, I'm using Guile-Git to extract the commit time,
> which is not the commit push time. In fact, I think there is no such
> thing as "commit push time" in git.

I had this issue with the Guix Data Service as well, it uses the
timestamp in the email sent by the Savannah git hook, which is the
closest I've got to "commit push time".

> We can still compute the metric 'time of commit to time of evaluation
> completion', but it's less relevant than the proposed 'time of push to
> time of evaluation completion'.

As someone can commit, then potentially push those commits hours later,
assuming no one else has pushed, this data might be a bit noisy. Time
between Curiass noticing the new commit to the evaluation completion
might be cleaner.


signature.asc
Description: PGP signature

bug#43334: Cuirass crashes

[Christopher Baines]

Mathieu Othacehe  writes:

> Hello,
>
> I've observed a few Cuirass crashes the past days. The log looks like:
>
> --8<---cut here---start->8---
> 2020-09-11T12:55:35 next evaluation in 300 seconds
> GC Warning: Repeated allocation of very large block (appr. size 28766208):
> May lead to memory leak and poor performance
> 2020-09-11T12:58:52 heap: 942.38 MiB; threads: 110; file descriptors: 257
> 2020-09-11T13:00:35 fetching input 'core-updates' of spec 
> 'core-updates-core-updates'
> 2020-09-11T13:00:54 fetched input 'core-updates' of spec 
> 'core-updates-core-updates' (commit 
> "1bec03df9b60f156c657a64a323ef27f4ed14b44")
> 2020-09-11T13:00:54 fetching input 'guix' of spec 'guix-master'
> 2020-09-11T13:01:13 fetched input 'guix' of spec 'guix-master' (commit 
> "7daa99e52d94e409f05a874813bdf739709807a2")
> 2020-09-11T13:01:13 evaluating spec 'guix-master'
> 2020-09-11T13:01:13 fetching input 'guix-modular' of spec 
> 'guix-modular-master'
> 2020-09-11T13:01:17 fetched input 'guix-modular' of spec 
> 'guix-modular-master' (commit "7daa99e52d94e409f05a874813bdf739709807a2")
> 2020-09-11T13:01:17 evaluating spec 'guix-modular-master'
> 2020-09-11T13:01:17 fetching input 'kernel-updates' of spec 'kernel-updates'
> 2020-09-11T13:01:21 fetched input 'kernel-updates' of spec 'kernel-updates' 
> (commit "1de80be489e443e7c0d8c79ea84762e1706e81ff")
> 2020-09-11T13:01:21 fetching input 'staging' of spec 'staging-staging'
> 2020-09-11T13:01:24 fetched input 'staging' of spec 'staging-staging' (commit 
> "de3c03a47160dec355d9b19ad5ca210d90c15fd7")
> 2020-09-11T13:01:24 fetching input 'version-1.0.1' of spec 'version-1.0.1'
> 2020-09-11T13:01:27 fetched input 'version-1.0.1' of spec 'version-1.0.1' 
> (commit "58d7909c97c1ab2457faee1d7af925ee32ad15c2")
> 2020-09-11T13:01:27 fetching input 'version-1.1.0' of spec 'version-1.1.0'
> mmap(PROT_NONE) failed
> WARNING: (guile-user): imported module (fibers) overrides core binding `sleep'
> 2020-09-11T13:01:30 performing database optimizations
> --8<---cut here---end--->8---
>
> It looks like a memory allocation failed causing a Cuirass/Guile crash.

So, I've seen this before but in a slightly different context, [1]. To
summarise, with Guile built with libgc@8 the Guix Data Service couldn't
processes Guix revisions, because the code it had Guile built with
libgc@8 run caused it to consistently crash with this error. The
workaround was to add a Guile variant built with libgc@7 and use this
for the guix package [2].

1: http://issues.guix.info/40525
2: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684

I'm not quite sure what Guile process is crashing here, but switching to
use Guile built with libgc@7 might help.


signature.asc
Description: PGP signature

bug#43850: cuirass: inconsistent SQL queries execution time.

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Mathieu Othacehe  skribis:
>
>>> I have now copied the database to a tmpfs mounted directory to make sure
>>> that those inconsistent duration are only caused by the I/O pressure on
>>> berlin.
>>
>> This helps a lot. The Cuirass web service has been running smooth since
>> two days, without any inconsistent query times.
>
> Interesting.
>
>> I'm considering using a tmpfs backed database for good. The problem is
>> that we would need a save/restore mechanism in case Berlin
>> reboots.
>
> Hmm sounds risky, no?
>
> I wonder if we could instead ensure no I/O-intensive workload runs that
> machine.  I’m thinking in particular of the derivations that produce
> ISO/qcow images that are not offloaded but maybe should.
>
> WDYT?  Do you think that’d be enough?  Or is tmpfs our only hope?

I think Ricardo mentioned that the machine running Cuirass uses an SSD
for the root filesystem, so moving the database there may help?


signature.asc
Description: PGP signature

bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked

[Christopher Baines]

I found this when trying to build guile3.0-gnutls:

  guix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b -- build 
--no-grafts --check guile3.0-gnutls
  

FAIL: status-request-revoked


trying NORMAL:-VERS-ALL:+VERS-TLS1.2
received status request
received status request
cert_verify_callback:263: certificate verify status doesn't match: 100402 != 
22FAIL status-request-revoked (exit status: 1)


signature.asc
Description: PGP signature

bug#44612: Read standard input in `guix repl'

[Christopher Baines]

Pierre Neidhardt  writes:

> Hey Tobias,
>
> Always good to have someone actually test the stuff :)
>
> Tobias Geerinckx-Rice  writes:
>
>> So far this looks like an (SB)CL(-specific) bug, right?  Does it 
>> happen anywhere else?  I tried Guile[0].
>
> Maybe there was a misunderstanding, it's not about Common Lisp.
> We can do easier than from Guile, i.e. from a shell:
>
> --8<---cut here---start->8---
> echo '(display "hello")' | guix repl
> --8<---cut here---end--->8---
>
> and... it works! O.o
>
> OK, my bad then, I mistested somehow.
>
> For future reference, it's also works in Common Lisp:
>
> --8<---cut here---start->8---
>> (with-input-from-string (s "(display \"foo\\n\")")
>(uiop:run-program '("guix" "repl") :input s :output t 
> :error-output nil))
> GNU Guile 3.0.4
> Copyright (C) 1995-2020 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.
> foo
>
> --8<---cut here---end--->8---
>
> However this brings me to another issue: the program output is prefixed
> with the REPL welcome message which is printed to stdout.
>
> So ideally when we read from standard input we should not include the
> welcome message.
>
> Any clue how to do that?

I haven't been following along too closely, but I'm surprised guix repl
--type=machine hasn't been mentioned, is that relevant?


signature.asc
Description: PGP signature

bug#45621: guix refresh -l and deprecated-package issue

[Christopher Baines]

There seems to be some issues with guix refresh -l and/or deprecating
packages.

Take the following example, guile3.0-squee is used by the
guix-data-service. guix refresh -l claims it's not though.

→ ./pre-inst-env guix refresh -l guile-squee
No dependents other than itself: guile-squee@0-2.c1497a2

→ ./pre-inst-env guix refresh -l guile3.0-squee
guix refresh: package 'guile3.0-squee' has been superseded by 'guile-squee'
No dependents other than itself: guile-squee@0-2.c1497a2


signature.asc
Description: PGP signature

bug#45663: Problem installing pidgin because it propagates gtk+@2

[Christopher Baines]

As reported by sss2 on IRC [1]. I can see this has changed recently, I
don't know why [2].

  guix package -i pidgin spice-gtk --no-substitutes
  The following package will be upgraded:
 spice-gtk (dependencies or package changed)
  
  The following package will be installed:
 pidgin 2.14.1
  
  The following derivations will be built:
 /gnu/store/a4n2ankaiqv857dbaqj82bmmk6bmd6ha-spice-gtk-0.37.drv
 /gnu/store/jh9z9mn9jz6744fyb3g3q5cn2nhhi65z-spice-gtk-0.37.tar.bz2.drv
  
  building 
/gnu/store/jh9z9mn9jz6744fyb3g3q5cn2nhhi65z-spice-gtk-0.37.tar.bz2.drv...
  downloading from https://spice-space.org/download/gtk/spice-gtk-0.37.tar.bz2 
...
  building /gnu/store/a4n2ankaiqv857dbaqj82bmmk6bmd6ha-spice-gtk-0.37.drv...
  guix package: error: profile contains conflicting entries for gtk+
  guix package: error:   first entry: gtk+@3.24.23 
/gnu/store/1biqkwwsx20rbg8xm1y66qdj41h2jp4h-gtk+-3.24.23
  guix package: error:... propagated from spice-gtk@0.37
  guix package: error:   second entry: gtk+@2.24.32 
/gnu/store/19av64kqzb9y9d9lfhqfy6bb4xl8z0zh-gtk+-2.24.32
  guix package: error:... propagated from pidgin@2.14.1
  hint: Try upgrading both `spice-gtk' and `pidgin', or remove one of them from 
the profile.


1: http://logs.guix.gnu.org/guix/2021-01-04.log#212727
2: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3fd4477809caaeb668141f21baac14d87e84


signature.asc
Description: PGP signature

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#45909: rust@1.47.0, rust-1.48.0 and rust-1.49.0 broken

[Christopher Baines]

The recent llvm 11.0.0 -> 11.0.1 change seems to have broken rust on the
master branch.

bug#45901: GNOME Fonts takes about 20 seconds to display fonts

[Christopher Baines]

Luis Felipe via Bug reports for GNU Guix  writes:

> ## Steps to reproduce
>
> The following steps assume you are using Guix System with GNOME desktop.
>
> 1. Open the command prompt (ALT+F2)
> 2. Run gnome-font-viewer
>
>
> ## Expected result
>
> GNOME Fonts starts and displays the fonts available (system and user fonts?) 
> with their corresponding names and thumbnails.
>
>
> ## Unexpected result
>
> + GNOME Fonts starts, but the font view is empty and there is no visual sign 
> of content being loaded.
> + The fonts are listed after waiting for about 20 seconds.
> + The fonts have no preview thumbnails (I heard Christopher Baines was 
> looking into this particular issue)

Hey,

I've just pushed the fix I worked on for thumbnails [1].

1: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=540893a8ccef41436a1c00ae268f74219f9ab220

Could you guix pull, guix upgrade gnome-font-viewer, remove
~/.cache/thumbnails/fail/ and then re-test?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#45901: GNOME Fonts takes about 20 seconds to display fonts

[Christopher Baines]

Luis Felipe  writes:

> On Saturday, January 16, 2021 11:18 AM, Christopher Baines  
> wrote:
>
>> Hey,
>>
>> I've just pushed the fix I worked on for thumbnails [1].
>>
>> 1: 
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=540893a8ccef41436a1c00ae268f74219f9ab220
>>
>> Could you guix pull, guix upgrade gnome-font-viewer, remove
>> ~/.cache/thumbnails/fail/ and then re-test?
>
> I just upgraded and thumbnails seem to be mostly fixed. That is, most
> of the thumbnails are displayed correctly. Some fonts have no
> thumbnail at all (Noto fonts like Noto Sans Armenian, Noto Sans Batak,
> Noto Sans Bengali, ...). And Source Han fonts have a placeholder icon
> (a blue, lowercase "a" in a white sheet).

That's good, I wonder if there are corner cases with the thumbnail
generation that still need addressing.

> The slowness issue seems to be a bug in GNOME Fonts
> (https://gitlab.gnome.org/GNOME/gnome-font-viewer/-/issues/30).
>
> What should we do with this bug report? Close it or leave it open
> until it is fixed upstream (I'd prefer the latter)?

Sure, it's up to you.


signature.asc
Description: PGP signature

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

[Christopher Baines]

Mathieu Othacehe  writes:

> Hello Leo & Guillaume,
>
>> That's a good observation. I hadn't thought of it.
>>
>> I'm CC-ing Mathieu Othacehe and guix-sysadmin so that we can disable
>> these builds until we can fix the bug for real. Mathieu: this might
>> explain why the build farm is spending all its effort on aarch64.
>
> If we want to disable SBCL builds temporarily we can do something
> similar to what I did to disable Rust builds on non-x86_64 architectures
> here: 0ed631866cc0b7cece2b0a0b50e39b37ae91bb67.
>
> Regarding the rebuilding that is a limitation of the new Cuirass remote
> building mechanism I am aware of and I need to solve. As build failures
> are only cached of the machine performing the build and the builds are
> now distributed to all the machines across the build farm, we need to
> find a way to centralize the builds failure cache.
>
> It would also be nice to optionally publish the build failures cache so
> that the user doesn't try to build a package that is known to be failing
> on the build farm. Chris, have you encountered this issue with the Build
> Coordinator?

Not really. The first thing to note is that I'm running the Guix Build
Coordinator currently without the guix-daemon --cache-failures option,
in fact it's probably unwise to do so, as it would mean that rather than
some builds taking place, the guix-daemon could just return a cached
failure. I should probably mention this in the README.

The way this situation is dealt with in the Guix Build Coordinator is
simplified by the agents not attempting builds where the derivation
inputs aren't present. If an agent is unable to ensure all the inputs
are present, it just reports this to the coordinator.

The behaviour is configurable, but the default missing inputs hook will
submit a new build for a missing input, but only if one doesn't already
exist. Because of this, you don't get the behaviour where some missing
prerequisite that fails to built is built over and over again, every
time you try and build a derivation that uses it.


signature.asc
Description: PGP signature

bug#46188: openimageio (and blender) fail to build since b965b2f004d522acea17f85780e1e44c882e24b3

[Christopher Baines]

Reported on IRC, it looks like the up date of pybind11 from 2.4.3 to
2.6.1 causes openimageio to fail to build, which also prevents users
from installing/upgrading blender.

1: 
https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=51418c32d95d8188d8877616829f26479f1135c6&target_commit=b965b2f004d522acea17f85780e1e44c882e24b3&build_change=broken&after_name=&limit_results=40

Cc'ing Nicolas Goaziou as they might be able to provide more information
about the pybind11 update.


signature.asc
Description: PGP signature

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Christopher Baines]

I noticed through the Guix Data Service that some narinfo files from
ci.guix.gnu.org have an excessive NarSize.

These are the three that I've found, but there could be more.


/gnu/store/qln574djfgl8h9glij9id8jips7nnrlw-flightgear-2018.3.5
NarSize: 18446744072099351584

/gnu/store/qhix6afvy2a6n7hlx4qgdns461p8kdnv-repeat-masker-4.1.1
NarSize: 18446744071612438544

/gnu/store/wd9z64xpck56xzf52jwlpg8vb610b0ym-repeat-masker-4.1.1
NarSize: 18446744071612438544


There's additional information on IRC: 
http://logs.guix.gnu.org/guix/2021-01-31.log#152751

Cc'ing Mathieu in case this is related to the new offloading mechanism.


signature.asc
Description: PGP signature

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Christopher Baines]

Christopher Baines  writes:

> I noticed through the Guix Data Service that some narinfo files from
> ci.guix.gnu.org have an excessive NarSize.
>
> These are the three that I've found, but there could be more.
>
>
> /gnu/store/qln574djfgl8h9glij9id8jips7nnrlw-flightgear-2018.3.5
> NarSize: 18446744072099351584
>
> /gnu/store/qhix6afvy2a6n7hlx4qgdns461p8kdnv-repeat-masker-4.1.1
> NarSize: 18446744071612438544
>
> /gnu/store/wd9z64xpck56xzf52jwlpg8vb610b0ym-repeat-masker-4.1.1
> NarSize: 18446744071612438544

Guix gives the following error when it encounters one of these bad
narinfos:

  error: integer expected from stream


signature.asc
Description: PGP signature

bug#44559:

[Christopher Baines]

Ludovic Courtès  writes:

> Perhaps we could start by testing this hypothesis on a separate build
> farm.  Chris, Mathieu, WDYT?

I'm currently thinking about attempting these kind of things (testing
building derivations under different conditions) through the agent tags
in the Guix Build Coordinator.

I haven't used this functionality yet, but it's mostly implemented. The
idea is that agents have tags, that describe various attributes that are
important (time=normal, time=future, maybe for example), and builds can
also be targeted at specific agents by tagging the builds with those
same tags.

Where I'm going with this is that I'm not sure a separate build farm is
needed, it would be good to just incorperate this in to the build farm
used for testing patches and non-master branches.


signature.asc
Description: PGP signature

bug#44559:

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Perhaps we could start by testing this hypothesis on a separate build
>>> farm.  Chris, Mathieu, WDYT?
>>
>> I'm currently thinking about attempting these kind of things (testing
>> building derivations under different conditions) through the agent tags
>> in the Guix Build Coordinator.
>>
>> I haven't used this functionality yet, but it's mostly implemented. The
>> idea is that agents have tags, that describe various attributes that are
>> important (time=normal, time=future, maybe for example), and builds can
>> also be targeted at specific agents by tagging the builds with those
>> same tags.
>
> Sounds nice!  Also varying kernels I guess.

Yeah, there's a whole range of variations it would be nice to
methodically test against (filesystems, Linux versions, system time, one
vs many cores, ...).

>> Where I'm going with this is that I'm not sure a separate build farm is
>> needed, it would be good to just incorperate this in to the build farm
>> used for testing patches and non-master branches.
>
> Sure.  For the build-in-the-future thing, I think we could just do that
> by default; what I meant is that we just need to double-check beforehand
> that nothing breaks badly.

Ah, I guess that might work, if I have some time, I'll have a look in to
making the necessary machine changes.


signature.asc
Description: PGP signature

bug#46737: Services breakage from the PostgreSQL socket-directory configuration change

[Christopher Baines]

Hey,

When reconfiguring recently, I ran in to issues with the Guix Data
Service and probably the Patchwork service too.

Looking at the change, I think it's clear there's a problem, because
some system tests were changed, and I'm guessing they were changed so
that they passed [1].

1: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=6c0679215f4ffa534c1eb2e8c8a6e043a0c993fe

Passing tests are good, but working around real issues in tests is not,
because that means that the situation outside of the tests can break and
if it does, the test result is misleading.

Patchwork, the Guix Data Service and maybe other things currently depend
on the default behaviour of PostgreSQL to find the socket. Given that
the service now uses a different (non-default) value, they don't
work.

One workaround, the one employed in the tests is to revert to the old
behaviour for the PostgreSQL service by setting socket-directory to #f.


signature.asc
Description: PGP signature

bug#46737: Services breakage from the PostgreSQL socket-directory configuration change

[Christopher Baines]

Mathieu Othacehe  writes:

>> One workaround, the one employed in the tests is to revert to the old
>> behaviour for the PostgreSQL service by setting socket-directory to #f.
>
> You're right, sorry about the breakage. As you noticed we are in an
> in-between situation where the patch updating Postgresql package to use
> "/var/run/postgresql" by default is only on core-updates, but the
> service is already using it as a default on master.
>
> This means that "createdb", "dropdb" and other Postgresql user tools
> need to have an explicit "-h /var/run/postgresql" argument for now.
>
> Until the package patch gets merged in the master branch, we could set
> the "socket-directory" field of  record to #f to
> restore an acceptable default behaviour.
>
> WDYT?

I think that would be good. It's unfortunate that the package change is
stuck on core-updates for now, but configuring the service on master to
keep the old behaviour until core-updates is merged sounds sensible.

Thanks,

Chris


signature.asc
Description: PGP signature

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

[Christopher Baines]

I believe there's TLS issues with pulling for the current 1.2.0 release.

root@horna ~# guix pull
substitute: updating substitutes from 'https://guix.cbaines.net'... 100.0%
0.0 MB will be downloaded
downloading from 
https://guix.cbaines.net/nar/lzip/zg72c146skpca45ijvjigqhqgx0mwiny-le-certs-0 
...
 le-certs-0  4KiB   

1.8MiB/s 00:00 [##] 100.0%

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: Git error: the SSL certificate is invalid

root@horna ~# wget https://git.savannah.gnu.org/git/guix.git
--2021-02-28 11:22:49--  https://git.savannah.gnu.org/git/guix.git
Resolving git.savannah.gnu.org (git.savannah.gnu.org)... 209.51.188.201, 
2001:470:142:5::201
Connecting to git.savannah.gnu.org 
(git.savannah.gnu.org)|209.51.188.201|:443... connected.
ERROR: The certificate of ‘git.savannah.gnu.org’ is not trusted.
ERROR: The certificate of ‘git.savannah.gnu.org’ doesn't have a known issuer.


This is probably possible to work around by doing:

  guix pull --url=http://git.savannah.gnu.org/git/guix.git

As the commit signatures are checked, the risk of not using HTTPS should
be reduced.


signature.asc
Description: PGP signature

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 <http://issues.guix.gnu.org/issue/44559#8>?
>
> And fixes are also discussed here:
> <http://issues.guix.gnu.org/issue/46650>.

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

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#46981: Severe Emacs shell mode performance regression in recent Linux-libre

[Christopher Baines]

Mark H Weaver  writes:

> Mark H Weaver  writes:
>
>> FYI, for those who use Emacs shell mode (M-x shell), I wanted to give a
>> heads-up about a severe performance regression in Linux-libre 5.10.20,
>> and I suspect the same regression exists in 5.11.3.
>>
>> For details, see the bug report I submitted to the Emacs developers,
>> here: .
>
> I've since confirmed that reverting the two upstream commits mentioned
> in  fixes the performance regression.  I've
> attached a preliminary patch for Guix that reverts those upstream
> commits for linux-libre@5.10, and which I've tested on my system.
>
> I guess that the same fix is also needed for linux-libre@5.11, but I've
> not checked.  I'll leave it to others to try applying the same reverts
> to 5.11.3 if they wish, and to decide what (if anything) should be done
> in Guix about this issue.

Ah, thanks so much for investigating this Mark! I only got as far as
asking around on #emacs.

I can confirm that 5.11.3 is affected, and that reverting to 5.10.19
avoids the issue. I haven't tried your patch yet.


signature.asc
Description: PGP signature

bug#47019: Rust 1.26.2 from the master branch fails to build on aarch64-linux

[Christopher Baines]

The failure seems to occur in the check phase, see the build logs
referenced from:

https://data.guix-patches.cbaines.net/gnu/store/c3f7d3ziwjfkwg3j7xz47dj44sb2l5av-rust-1.26.2.drv

This looks like a relevant error:

 [compile-fail] compile-fail/issue-15919.rs stdout 


executing 
"/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/stage2/bin/rustc"
 
"/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/src/test/compile-fail/issue-15919.rs"
 "-L" 
"/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/test/compile-fail"
 "--target=aarch64-unknown-linux-gnu" "-Zui-testing" "-C" "prefer-dynamic" "-o" 
"/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/test/compile-fail/issue-15919.stage2-aarch64-unknown-linux-gnu"
 "-Crpath" "-O" "-Zmiri" "-Zunstable-options" 
"-Lnative=/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/native/rust-test-helpers"
 "-L" 
"/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/test/compile-fail/issue-15919.stage2-aarch64-unknown-linux-gnu.aux"
 "-A" "unused"
--stdout--

--stderr--
error: the type `[usize; 18446744073709551615]` is too big for the current 
architecture


signature.asc
Description: PGP signature

bug#47019: Rust 1.26.2 from the master branch fails to build on aarch64-linux

[Christopher Baines]

Efraim Flashner  writes:

> On Tue, Mar 09, 2021 at 08:56:54AM +0000, Christopher Baines wrote:
>> The failure seems to occur in the check phase, see the build logs
>> referenced from:
>> 
>> https://data.guix-patches.cbaines.net/gnu/store/c3f7d3ziwjfkwg3j7xz47dj44sb2l5av-rust-1.26.2.drv
>> 
>> This looks like a relevant error:
>> 
>>  [compile-fail] compile-fail/issue-15919.rs stdout 
>>  
>> 
>> executing 
>> "/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/stage2/bin/rustc"
>>  
>> "/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/src/test/compile-fail/issue-15919.rs"
>>  "-L" 
>> "/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/test/compile-fail"
>>  "--target=aarch64-unknown-linux-gnu" "-Zui-testing" "-C" "prefer-dynamic" 
>> "-o" 
>> "/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/test/compile-fail/issue-15919.stage2-aarch64-unknown-linux-gnu"
>>  "-Crpath" "-O" "-Zmiri" "-Zunstable-options" 
>> "-Lnative=/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/native/rust-test-helpers"
>>  "-L" 
>> "/tmp/guix-build-rust-1.26.2.drv-0/rustc-1.26.2-src/build/aarch64-unknown-linux-gnu/test/compile-fail/issue-15919.stage2-aarch64-unknown-linux-gnu.aux"
>>  "-A" "unused"
>> --stdout--
>> 
>> --stderr--
>> error: the type `[usize; 18446744073709551615]` is too big for the current 
>> architecture
>
> Is that native or emulated?

I'm almost certain they were native builds. I've recently started trying
to mix QEMU binfmt assisted builds in with native builds on
guix.cbaines.net, but these three builds happened before that:

https://data.guix-patches.cbaines.net/build-server/3/build?build_server_build_id=dcab4175-2f20-4284-9db5-c78aa4ebe560
https://data.guix-patches.cbaines.net/build-server/3/build?build_server_build_id=3cf027c0-d1c3-443b-8909-84d3c6911cfa
https://data.guix-patches.cbaines.net/build-server/3/build?build_server_build_id=21e54b9f-5c0f-4565-bde4-b4fde6f741d7

Eventually, there will be metadata for the builds which will say
something about the setup used.


signature.asc
Description: PGP signature

bug#47157: “Bad Read-Header-Line header: #” while substituting

[Christopher Baines]

Ludovic Courtès  writes:

> As reported by a few people on IRC, ‘guix substitute’ sometimes fails in
> a way that I just experienced (from
> 8154beffd8c121e953a7c4cd75c3eebfcc073a9a):
>
> --8<---cut here---start->8---
> downloading from 
> https://ci.guix.gnu.org/nar/gzip/0bji0q5n59595xaqkqrp2gv52lbz55xz-libpng-1.6.37
>  .
>  libpng-1.6.37  275KiB 11.0MiB/s 00:00 
> [##] 100.0%
>
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/h3a5ygxxh4gakhnl53mq7z9b43l8z05g-python-minimal.
>  python-minimal-wrapper-3.8.2  351B 293KiB/s 00:00 
> [##] 100.0%
>
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/h8j09yb5d8dh3jffvpzawxslig9bwhdr-freetype-2.10..
>  freetype-2.10.4  600KiB3.0MiB/s 00:00 
> [##] 100.0%
>
> building /gnu/store/2wfzazqz9g5xizi4vq4pv75nkh1m24bp-perl-5.30.2.drv...
> Backtrace:
> In guix/ui.scm:
>   2164:12 19 (run-guix-command _ . _)
> In guix/scripts/substitute.scm:
> 691:2 18 (guix-substitute . _)
> In unknown file:
>   17 (with-continuation-barrier #)
> In ice-9/boot-9.scm:
>   1736:10 16 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
> In unknown file:
>   15 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>   1736:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>   1736:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>   1731:15 12 (with-exception-handler # ice-9/boot-9.scm:1815:7 (exn)> _)
> In guix/scripts/substitute.scm:
>740:17 11 (_)
> 434:7 10 (process-substitution _ 
> "/gnu/store/ns00dyapjbq9037dwrxa7hc31dvir00n-grub-minimal-2.)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
> In guix/scripts/substitute.scm:
> 443:9  8 (_)
> In ice-9/boot-9.scm:
>   1731:15  7 (with-exception-handler # ice-9/boot-9.scm:1815:7 (exn)> _)
>   1669:16  6 (raise-exception _ #:continuable? _)
>   1667:16  5 (raise-exception _ #:continuable? _)
>   1669:16  4 (raise-exception _ #:continuable? _)
>   1764:13  3 (_ #<&compound-exception components: (#<&error> #<&irritants 
> irritants: (read-header)
>   1669:16  2 (raise-exception _ #:continuable? _)
>   1667:16  1 (raise-exception _ #:continuable? _)
>   1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Bad Read-Header-Line header: #
> --8<---cut here---end--->8---
>
> This is the kind of issue that ‘with-cached-connection’ as it can be
> seen in 9158020d7853b6e7925802e0d0a082801c680e8f avoided:
>
> --8<---cut here---start->8---
> (define* (call-with-cached-connection uri proc
>   #:optional
>   (open-connection
>open-connection-for-uri/cached))
>   (let ((port (open-connection uri)))
> (catch #t
>   (lambda ()
> (proc port))
>   (lambda (key . args)
> ;; If PORT was cached and the server closed the connection in the
> ;; meantime, we get EPIPE.  In that case, open a fresh connection and
> ;; retry.  We might also get 'bad-response or a similar exception from
> ;; (web response) later on, once we've sent the request, or a
> ;; ERROR/INVALID-SESSION from GnuTLS.
> (if (or (and (eq? key 'system-error)
>  (= EPIPE (system-error-errno `(,key ,@args
> (and (eq? key 'gnutls-error)
>  (eq? (first args) error/invalid-session))
> (memq key '(bad-response bad-header bad-header-component)))
> (proc (open-connection uri #:fresh? #t))
> (apply throw key args))
> --8<---cut here---end--->8---
>
> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits
> may have caused this regression.  In particular, in
> 20c08a8a45d0f137ead7c05e720456b2aea44402,
> ‘call-with-connection-error-handling’ is now used, but that one doesn’t
> catch the exceptions mentioned above, in this case ‘bad-header’.

I think the behaviour changed unintentionally with [1], however,
thinking about the connection reuse in process-substitution compared
with http-multiple-get, there's no attempt here to look at if the server
has specified whether the connection should be closed.

1: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f50f5751fff4cfc6d5abba9681054569694b7a5c

Just like http-multiple-get, it's probably worth trying to check the
headers of the response, look at whether the server has indicated that
the connection should be closed, and if so, close the connection,
forcing a new one to be established for future requests.

I haven't tested this theory, but maybe if that happened, then some
occurrences of trying to read a response, and 

bug#47157: “Bad Read-Header-Line header: #” while substituting

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> As reported by a few people on IRC, ‘guix substitute’ sometimes fails in
>> a way that I just experienced (from
>> 8154beffd8c121e953a7c4cd75c3eebfcc073a9a):
>>
>> --8<---cut here---start->8---
>> downloading from 
>> https://ci.guix.gnu.org/nar/gzip/0bji0q5n59595xaqkqrp2gv52lbz55xz-libpng-1.6.37
>>  .
>>  libpng-1.6.37  275KiB 11.0MiB/s 00:00 
>> [##] 100.0%
>>
>> downloading from 
>> https://ci.guix.gnu.org/nar/lzip/h3a5ygxxh4gakhnl53mq7z9b43l8z05g-python-minimal.
>>  python-minimal-wrapper-3.8.2  351B 293KiB/s 00:00 
>> [##] 100.0%
>>
>> downloading from 
>> https://ci.guix.gnu.org/nar/lzip/h8j09yb5d8dh3jffvpzawxslig9bwhdr-freetype-2.10..
>>  freetype-2.10.4  600KiB3.0MiB/s 00:00 
>> [##] 100.0%
>>
>> building /gnu/store/2wfzazqz9g5xizi4vq4pv75nkh1m24bp-perl-5.30.2.drv...
>> Backtrace:
>> In guix/ui.scm:
>>   2164:12 19 (run-guix-command _ . _)
>> In guix/scripts/substitute.scm:
>> 691:2 18 (guix-substitute . _)
>> In unknown file:
>>   17 (with-continuation-barrier #)
>> In ice-9/boot-9.scm:
>>   1736:10 16 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>> In unknown file:
>>   15 (apply-smob/0 #)
>> In ice-9/boot-9.scm:
>>   1736:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>>   1736:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>>   1731:15 12 (with-exception-handler #> ice-9/boot-9.scm:1815:7 (exn)> _)
>> In guix/scripts/substitute.scm:
>>740:17 11 (_)
>> 434:7 10 (process-substitution _ 
>> "/gnu/store/ns00dyapjbq9037dwrxa7hc31dvir00n-grub-minimal-2.)
>> In ice-9/boot-9.scm:
>>   1736:10  9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>> In guix/scripts/substitute.scm:
>> 443:9  8 (_)
>> In ice-9/boot-9.scm:
>>   1731:15  7 (with-exception-handler #> ice-9/boot-9.scm:1815:7 (exn)> _)
>>   1669:16  6 (raise-exception _ #:continuable? _)
>>   1667:16  5 (raise-exception _ #:continuable? _)
>>   1669:16  4 (raise-exception _ #:continuable? _)
>>   1764:13  3 (_ #<&compound-exception components: (#<&error> #<&irritants 
>> irritants: (read-header)
>>   1669:16  2 (raise-exception _ #:continuable? _)
>>   1667:16  1 (raise-exception _ #:continuable? _)
>>   1669:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>> Bad Read-Header-Line header: #
>> --8<---cut here---end--->8---
>>
>> This is the kind of issue that ‘with-cached-connection’ as it can be
>> seen in 9158020d7853b6e7925802e0d0a082801c680e8f avoided:
>>
>> --8<---cut here---start->8---
>> (define* (call-with-cached-connection uri proc
>>   #:optional
>>   (open-connection
>>open-connection-for-uri/cached))
>>   (let ((port (open-connection uri)))
>> (catch #t
>>   (lambda ()
>> (proc port))
>>   (lambda (key . args)
>> ;; If PORT was cached and the server closed the connection in the
>> ;; meantime, we get EPIPE.  In that case, open a fresh connection and
>> ;; retry.  We might also get 'bad-response or a similar exception 
>> from
>> ;; (web response) later on, once we've sent the request, or a
>> ;; ERROR/INVALID-SESSION from GnuTLS.
>> (if (or (and (eq? key 'system-error)
>>  (= EPIPE (system-error-errno `(,key ,@args
>> (and (eq? key 'gnutls-error)
>>  (eq? (first args) error/invalid-session))
>> (memq key '(bad-response bad-header bad-header-component)))
>> (proc (open-connection uri #:fresh? #t))
>> (apply throw key args))
>> --8<---cut here---end--->8---
>>
>> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits
>> may have caused this regression.  In particular, in
>> 20c08a8a45d0f137ead7c05e720456b2aea44402,
>> ‘call-with-connection-error-handling’ is now used, but that one doesn’t
>> catch the exceptions 

bug#47157: “Bad Read-Header-Line header: #” while substituting

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>>> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits
>>> may have caused this regression.  In particular, in
>>> 20c08a8a45d0f137ead7c05e720456b2aea44402,
>>> ‘call-with-connection-error-handling’ is now used, but that one doesn’t
>>> catch the exceptions mentioned above, in this case ‘bad-header’.
>>
>> I think the behaviour changed unintentionally with [1], however,
>> thinking about the connection reuse in process-substitution compared
>> with http-multiple-get, there's no attempt here to look at if the server
>> has specified whether the connection should be closed.
>>
>> 1: 
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f50f5751fff4cfc6d5abba9681054569694b7a5c
>>
>> Just like http-multiple-get, it's probably worth trying to check the
>> headers of the response, look at whether the server has indicated that
>> the connection should be closed, and if so, close the connection,
>> forcing a new one to be established for future requests.
>
> I think that’s not enough because we can’t rely on the server’s state
> intent here.
>
> For example, you have a keep-alive connection that you keep in cache.
> Minutes later, you come back and send a request over that port.  If the
> server dropped the connection in the meantime, that can manifest in any
> of the ways we’ve seen: 'bad-response when attempting to read the
> response, some 'gnutls-error, 'system-error and EPIPE, etc.  There’s no
> way to determine in advance whether the socket is fine.
>
> That’s why the initial approach was to wrap all the call sites were the
> socket was known to be possibly “tainted” in ‘with-cached-connection’.
>
>> I've now actually got around to testing this, I'm no expert at running
>> the substitute script manually without the guix-daemon, but I gave it a
>> go, using a local NGinx instance which just allowed two requests per
>> connection.
>
> I believe in this case ‘port-closed?’ returns true because the
> socket/TLS record port got closed right at the end of the response, so
> it’s the “easy” case; I don’t think it captures the situation I
> described above where an error comes up later while trying to write
> to/read from the port.

Yeah, of course, I think error handling is needed as well, it just
occurred to me when looking at this issue and the relevant code.


signature.asc
Description: PGP signature

bug#47283: Performance regression in narinfo fetching

[Christopher Baines]

Ludovic Courtès  writes:

> As reported on guix-devel, ‘guix weather’ has become extremely slow.
> Specifically, in the narinfo-fetching phase, it runs at 100% CPU, even
> though that part should be network-bound (pipelined HTTP GETs).
>
> A profile of the ‘report-server-coverage’ call would show this:
>
> --8<---cut here---start->8---
> % cumulative   self 
> time   seconds seconds  procedure
>  62.50  1.06  1.06  fluid-ref*
>   6.25  0.11  0.11  regexp-exec
>   3.13  0.05  0.05  ice-9/boot-9.scm:1738:4:throw
>   2.08  0.04  0.04  string-index
>   2.08  0.04  0.04  write
>   1.04568.08  0.02  ice-9/boot-9.scm:1673:4:with-exception-handler
>   1.04  0.02  0.02  %read-line
>   1.04  0.02  0.02  guix/ci.scm:78:0:json->build
>   1.04  0.02  0.02  string-append
> --8<---cut here---end--->8---
>
> More than half of the time spent in ‘fluid-ref*’—sounds fishy.
>
> Where does that that call come from?  There seems to be a single caller,
> in boot-9.scm:
>
> (define* (raise-exception exn #:key (continuable? #f))
>   (define (capture-current-exception-handlers)
> ;; FIXME: This is quadratic.
> (let lp ((depth 0))
>   (let ((h (fluid-ref* %exception-handler depth)))
> (if h
> (cons h (lp (1+ depth)))
> (list fallback-exception-handler)
>   ;; …
>   )
>
> We must be abusing exceptions somewhere…
>
> Indeed, there’s one place on the hot path where we install exception
> handlers: in ‘http-multiple-get’ (from commit
> 205833b72c5517915a47a50dbe28e7024dc74e57).  I don’t think it’s needed,
> is it?  (But if it is, let’s find another approach, this one is
> prohibitively expensive.)

I think the exception handling has moved around, but I guess the
exceptions that could be caught in http-multiple-get could happen,
right? I am really just guessing here, as Guile doesn't help tell you
about possible exceptions, and I haven't spent enough time to read all
the possible code involved to find out if these are definitely possible.

> A simple performance test is:
>
>   rm -rf ~/.cache/guix/substitute/
>   time ./pre-inst-env guix weather $(guix package -A|head -500| cut -f1)
>
> After removing this ‘catch’ in ‘http-multiple-get’, the profile is
> flatter:
>
> --8<---cut here---start->8---
> % cumulative   self
> time   seconds seconds  procedure
>   8.33  0.07  0.07  string-index
>   8.33  0.07  0.07  regexp-exec
>   5.56  0.05  0.05  anon #x154af88
>   5.56  0.05  0.05  write
>   5.56  0.05  0.05  string-tokenize
>   5.56  0.05  0.05  read-char
>   5.56  0.05  0.05  set-certificate-credentials-x509-trust-data!
>   5.56  0.05  0.05  %read-line
> --8<---cut here---end--->8---
>
> There’s also this ‘call-with-connection-error-handling’ call in (guix
> substitute), around an ‘http-multiple-get’ call, that may not be
> justified.
>
> Attached is a diff of the tweaks I made to test this.
>
> WDYT, Chris?

I haven't looked in to this yet, but maybe it would be possible to
adjust the code so that it doesn't perform so badly, but still tries to
handle possible exceptions.

The two ideas I have is to rewrite the (let ...) bit in terms of a fold,
maybe that would perform better, or stop using let for iteration and
setup the exception handling, then process each request, using set! to
update the state. I haven't tested either of these.

It's good to know that Guile exception handling can be excessively
expensive though, I wouldn't have expected it to beat out anything over
the network in terms of the performance penalty.


signature.asc
Description: PGP signature

bug#47283: Performance regression in narinfo fetching

[Christopher Baines]

Christopher Baines  writes:

> I haven't looked in to this yet, but maybe it would be possible to
> adjust the code so that it doesn't perform so badly, but still tries to
> handle possible exceptions.
>
> The two ideas I have is to rewrite the (let ...) bit in terms of a fold,
> maybe that would perform better, or stop using let for iteration and
> setup the exception handling, then process each request, using set! to
> update the state. I haven't tested either of these.

I tried something, neither of these things, but just not calling (loop
...) within the catch block. I don't know why this might work, but it
seems to make guix weather much faster.

Here's the patch [1], I've just realised it's broken, as it'll loose the
result value (and use an old one) when the connection is closed. I'll
send a updated patch without this issue in a moment.

1: https://issues.guix.gnu.org/47288


signature.asc
Description: PGP signature

bug#47283: Performance regression in narinfo fetching

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Indeed, there’s one place on the hot path where we install exception
>>> handlers: in ‘http-multiple-get’ (from commit
>>> 205833b72c5517915a47a50dbe28e7024dc74e57).  I don’t think it’s needed,
>>> is it?  (But if it is, let’s find another approach, this one is
>>> prohibitively expensive.)
>>
>> I think the exception handling has moved around, but I guess the
>> exceptions that could be caught in http-multiple-get could happen,
>> right? I am really just guessing here, as Guile doesn't help tell you
>> about possible exceptions, and I haven't spent enough time to read all
>> the possible code involved to find out if these are definitely possible.
>
> Yeah.
>
> Commit 205833b72c5517915a47a50dbe28e7024dc74e57 added a ‘catch’ block
> that catches the same things as ‘with-cached-connection’ did (it would
> be better to not duplicate it IMO).  That includes EPIPE, gnutls-error,
> bad-response & co.

So, my intention here was to move the error handling, to allow
separating out the connection caching code from the code I wanted to
move out to the (guix substitutes) module. I don't think there's
currently duplication in the error handling for the code path involving
http-multiple-get currently, at least for the exceptions in question
here.

> Earlier, commit be5a75ebb5988b87b2392e2113f6590f353dd6cd (“substitute:
> Reuse connections for '--query'.”) did not add such a ‘catch’ block in
> ‘http-multiple-get’.  Instead, it wrapped its call in ‘do-fetch’ in
> ‘fetch-narinfos’:
>
>(define (do-fetch uri)
>  (case (and=> uri uri-scheme)
>((http https)
> -   (let ((requests (map (cut narinfo-request url <>) paths)))
> - (match (open-connection-for-uri/maybe uri)
> -   (#f
> -'())
> -   (port
> -(update-progress!)
> ;; Note: Do not check HTTPS server certificates to avoid depending
> ;; on the X.509 PKI.  We can do it because we authenticate
> ;; narinfos, which provides a much stronger guarantee.
> -(let ((result (http-multiple-get uri
> +   (let* ((requests (map (cut narinfo-request url <>) paths))
> +  (result   (call-with-cached-connection uri
> +  (lambda (port)
> +(if port
> +(begin
> +  (update-progress!)
> +  (http-multiple-get uri
>   handle-narinfo-response 
> '()
>   requests
> + #:open-connection
> + 
> open-connection-for-uri/cached
>   #:verify-certificate? #f
> - #:port port)))
>
> This bit is still there in current ‘master’, so I think it’s not
> necessary to catch these exceptions in ‘http-multiple-get’ itself, and I
> would just remove the ‘catch’ wrap altogether.
>
> WDYT?

I'm not sure what you're referring to as still being there on the master
branch?

Looking at the changes to this particular code path resulting from the
changes I've made recently, starting at lookup-narinfos, before:

 - lookup-narinfos calls fetch-narinfos, which calls do-fetch

 - call-with-cached-connection is used, which catches a number of
   exceptions relating to requests, and will retry PROC once upon a
   matching exception

 - open-connection-for-uri/maybe is also used, which is like
   open-connection-for-uri/cached, except it includes error handling for
   establishing connections to substitute servers

 - http-multiple-get doesn't include error handling

After:

 - lookup-narinfos calls fetch-narinfos, which calls do-fetch

 - call-with-connection-error-handling is used, which performs the same
   role as the error handling previously within
   open-connection-for-uri/maybe, catching exceptions relating to
   establishing connections to substitute servers

 - http-multiple-get now includes error handling similar to what was
   previously done by call-with-cached-connection, although it's more
   complicated since it's done with knowledge of what http-multiple-get
   is doing

I think that the error handling now in http-multiple-get isn't covered
elsewhere. Moving this error handling back in to fetch-narinfos is
possible, but then we'd be back to handling connection caching in that
code, and avoiding that led to this refactoring in the

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

[Christopher Baines]

Leo Famulari  writes:

> On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote:
>> I believe there's TLS issues with pulling for the current 1.2.0 release.
>
> On a fresh Debian ISO image, I installed Guix 1.2.0 based on the
> instructions in the manual section Binary Installation.
>
> Then, `guix pull` succeeded for me, no problem.
>
> Can anyone reproduce still reproduce this bug?

I'm pretty sure I experienced this with a fresh install of Guix System,
I should have given more information in the initial report.


signature.asc
Description: PGP signature

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

[Christopher Baines]

Leo Famulari  writes:

> On Sat, Apr 10, 2021 at 04:30:42PM -0400, Leo Famulari wrote:
>> Okay, I'm testing this now, in a VM.
>> 
>> I wonder if it's the same thing as
>> ?
>
> I followed the instructions in the manual section Installing Guix in a
> VM.
>
> Then, I booted the new system, opened a terminal emulator in the XFCE
> desktop environment, and ran `guix pull`. It succeeded.

Maybe it just doesn't work for the root user... I encountered this when
running guix pull as the root user on a headless machine.


signature.asc
Description: PGP signature

bug#46737: Services breakage from the PostgreSQL socket-directory configuration change

[Christopher Baines]

Christopher Baines  writes:

> Mathieu Othacehe  writes:
>
>>> One workaround, the one employed in the tests is to revert to the old
>>> behaviour for the PostgreSQL service by setting socket-directory to #f.
>>
>> You're right, sorry about the breakage. As you noticed we are in an
>> in-between situation where the patch updating Postgresql package to use
>> "/var/run/postgresql" by default is only on core-updates, but the
>> service is already using it as a default on master.
>>
>> This means that "createdb", "dropdb" and other Postgresql user tools
>> need to have an explicit "-h /var/run/postgresql" argument for now.
>>
>> Until the package patch gets merged in the master branch, we could set
>> the "socket-directory" field of  record to #f to
>> restore an acceptable default behaviour.
>>
>> WDYT?
>
> I think that would be good. It's unfortunate that the package change is
> stuck on core-updates for now, but configuring the service on master to
> keep the old behaviour until core-updates is merged sounds sensible.

I don't know if the expectation was that I was going to fix this, but
since it seems there's a release coming up, I went ahead and prepared a
patch [1].

1: https://issues.guix.gnu.org/47736


signature.asc
Description: PGP signature

bug#47971: Improve Guix commands for update/upgrade

[Christopher Baines]

bo0od  writes:

> Hi There,
>
> The current commands used to make sure everything updated are not
> friendly to type nor to memorize, Current commands:(i dunno if i
> missed more)
>
> guix pull
> guix upgrade
> sudo guix reconfigure /etc/config.scm
>
>
> There is no relation can be drawn from using these commands:
>
> - pull: Is actually the opposite of push which is a git command and it
>   make sense in git atmosphere/usage.

guix pull usually does a git pull under the hood and then builds guix
from that updated repository.

I don't get what you mean when you say pull is actually the opposite of
push? That's true in the sense of the words, but how does that relate to
Guix?

> - upgrade: This is the only good one as this is very common term used
>   within distros or actually most of the operating systems generally.
>
> - reconfigure /etc/config.scm: hmm...
>
> There are many ways we can improve this by using different better
> terms which can be easily memorized and even linked e.g: (These are
> just examples, If there are any better terms you can come with sure
> why not)
>
> - pull -> update or refresh

I think update is OK, although I think pull is OK too. refresh is
already taken.

> - upgrade -> can be kept or package-upgrade
> - reconfigure /etc/config.scm -> dist-upgrade or distro-upgrade or
>   system-upgrade

You can "downgrade" (switch to using an older Guix/software) by
reconfiguring, so I wouldn't like to see that operation referred to as
an upgrade (as it's not always).


signature.asc
Description: PGP signature

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

[Christopher Baines]

This is on commit 1b792e8b5275dc010c53d91062082340431204f2.

→ make check-system TESTS=basic
Compiling Scheme modules...
Selected 1 system tests...
The following derivation will be built:
   /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv
building /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv...
/gnu/store/13v06bndh09k1db50yndqi7610a9170k-qemu-5.2.0/bin/qemu-system-x86_64: 
error while loading shared libraries: libXcursor.so.1: cannot open shared 
object file: No such file or directory
Backtrace:
   4 (primitive-load "/gnu/store/kxwahrlahs75yr5j190n7f5sah9?")
In ice-9/eval.scm:
619:8  3 (_ #f)
   626:19  2 (_ #)
In gnu/build/marionette.scm:
141:7  1 (make-marionette ("/gnu/store/s8cndczb6zz9al8l7nqk9hm?") ?)
114:7  0 (accept* #)

gnu/build/marionette.scm:114:7: In procedure accept*:
timeout in 'accept' #
QEMU runs as PID 14
note: keeping build directory `/tmp/guix-build-basic.drv-3'
builder for `/gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv' failed with 
exit code 1
build of /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv failed
View build log at 
'/var/log/guix/drvs/7d/yw16iakczr7qg89rb3rgbh443cvwpc-basic.drv.bz2'.
guix build: error: build of 
`/gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv' failed
make: *** [Makefile:6923: check-system] Error 1


signature.asc
Description: PGP signature

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> This is on commit 1b792e8b5275dc010c53d91062082340431204f2.
>>
>> → make check-system TESTS=basic
>> Compiling Scheme modules...
>> Selected 1 system tests...
>> The following derivation will be built:
>>/gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv
>> building /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv...
>> /gnu/store/13v06bndh09k1db50yndqi7610a9170k-qemu-5.2.0/bin/qemu-system-x86_64:
>>  error while loading shared libraries: libXcursor.so.1: cannot open shared 
>> object file: No such file or directory
>
> That looks fishy.  I cannot reproduce it like this:
>
> --8<---cut here---start->8---
> $ TESTS=basic guix time-machine 
> --commit=1b792e8b5275dc010c53d91062082340431204f2 -- build -m 
> etc/system-tests.scm
>
> [...]
>
> ;;; (services (file-system-/dev/shm file-system-/sys/firmware/efi/efivars 
> urandom-seed term-tty3 term-tty2 virtual-terminal mcron term-tty4 
> console-font-tty5 console-font-tty1 user-file-systems user-processes 
> root-file-system console-font-tty2 marionette loopback syslogd nscd term-tty5 
> root file-system-/dev/pts term-tty6 file-system-/sys/kernel/debug 
> console-font-tty3 guix-daemon term-tty1 user-homes console-font-tty6 sysctl 
> console-font-tty4 term-auto host-name file-systems udev))
> # of expected passes  27
> # of skipped tests1
> successfully built /gnu/store/q1p7gbpxv37ycisdpl11vi4x86l73lmg-basic.drv
> /gnu/store/2v80zymwawb9cvf9bhdfj87f60nrcpn3-basic
> --8<---cut here---end--->8---
>
> It’s not the same derivation though.
>
> I can’t seem to find
> /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv nor
> /gnu/store/13v06bndh09k1db50yndqi7610a9170k-qemu-5.2.0.  Where do they
> come from?

I've done a bit more digging, the qemu output is grafted, and I'm
probably getting a different grafted result since the libxcursor output
I have in my store is broken:

/gnu/store/mwcfhmiivhp4q7wax3ja8s17pk20i6w9-libxcursor-1.2.0/
└── share
└── doc
└── libxcursor-1.2.0
└── COPYING

This comes from guix.cbaines.net, so it's probably not affecting anyone
else. I checked where the build happened, and it took place on a machine
which I was playing around with overclocking, and wasn't running in a
stable way.

I'm sort of impressed things managed to break in such a specific way
though. Because of how the Guix Build Coordinator works, this build must
have taken place, something went wrong in the middle, and then the
outputs got uploaded and the build result reported all without
issue. The build log has some interesting "succeeded after 0.0 seconds"
bits at the end:

  https://guix.cbaines.net/build/d4850c59-a007-4754-b16d-d867d63bc95e/log

I'll close the bug since this seems to be a "me" problem.


signature.asc
Description: PGP signature

bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> Christopher Baines  skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc@7
>>> rather than libgc@8 (which is what's used above), and I can't reproduce
>>> the issue. So, I'm getting more certain that this is a regression which
>>> the libgc upgrade has led to.
>>
>> Bah.  :-/
>>
>> We noticed similar issues with libgc@8 earlier but it seemed to be
>> fixed:
>>
>>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>>
>>> Would it be feasible to keep guile, or at least the guile Guix uses with
>>> libgc@7 for now?
>>
>> Yes, we can define a Guile variant in (gnu packages guile) and have
>> (guix self) refer to it.
>
> FWIW flatwhatson reported the dreaded libgc “mmap(PROT_NONE)” crash
> upstream and gathered more info:
>
>   https://github.com/ivmai/bdwgc/issues/353
>
> On #guile they also mentioned that libgc 8 defaults to
> ‘--enable-munmap=6’ whereas libgc 7 would default to ‘--disable-munmap’.
>
> Thus, in ‘core-updates’ commit a605ef3ce9dbd6b79dd9322f89d9facaf875b487,
> I changed libgc 8 so it’s built with ‘--disable-munmap’.  This relieves
> the need for ‘guile-3.0/libgc-7’.  (I checked with “make as-derivation”
> on x86_64-linux that those derivations that would previously fail with
> libgc 8 no longer do.)

Great, that sounds good :)


signature.asc
Description: PGP signature

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

[Christopher Baines]

Tobias Geerinckx-Rice  writes:

> Chris,
>
> Christopher Baines 写道：
>> This comes from guix.cbaines.net, so it's probably not affecting
>> anyone
>> else.
>
> The spooky happenings below reminded of this thread.  Perhaps they're
> useful somehow.  Probably not.
>
> --8<---cut here---start->8---
> λ guix environment guix -- ./pre-inst-env guix build \
>   --no-grafts mergerfs --target=aarch64-linux-gnu
> [...]
> downloading from
> https://guix.cbaines.net/nar/lzip/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4
> ...
> [...]
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4
> --8<---cut here---end--->8---
>
> --8<---cut here---start->8---
> λ tree /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4/
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4/
> └── share
>└── doc
>└── mergerfs-2.32.4
>└── LICENSE
>
> 3 directories, 1 file
> --8<---cut here---end--->8---
>
> --8<---cut here---start->8---
> λ guix environment guix -- ./pre-inst-env guix build \
>   --no-grafts mergerfs --target=aarch64-linux-gnu \
>--check --keep-failed
> [...]
> guix build: error: derivation
> `/gnu/store/xkbxh0bwqppf6ga8fxx38hz3f1kq0av8-mergerfs-2.32.4.drv'
> may not be deterministic: output
> `/gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4'
> differs from
> ‘/gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4-check’
> --8<---cut here---end--->8---
>
> --8<---cut here---start->8---
> λ tree
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4-check
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4-check
> ├── bin
> │   ├── mergerfs
> │   └── mergerfs-fusermount
> ├── sbin
> │   └── mount.mergerfs
> └── share
>├── doc
>│   └── mergerfs-2.32.4
>│   └── LICENSE
>└── man
>└── man1
>└── mergerfs.1.gz
>
> 7 directories, 5 files
> --8<---cut here---end--->8---

Hmm, I checked the build for this output as well, same machine, which is
good I guess. I've submitted another build to replace it.

Where did this come up? I wasn't aware anyone else was using
guix.cbaines.net for substitutes, especially for cross-build things.


signature.asc
Description: PGP signature

bug#31773: Duplicit fails to build: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

[Christopher Baines]

Duplicity fails to build, this might be because of the GPG version used,
as it looks to me that GPG complains that the message is quite old. I'll
ask on the Duplicity talk mailing list.


test_remove_all_inc_of_but_n (testing.functional.test_cleanup.CleanupTest) ... 
ok

==
ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)
Test getting signature chain fileobjs from archive_dir
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 188, in test_sigchain_fileobj
self.sigchain_fileobj_check_list(self.sigchain_fileobj_get(None))
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 180, in sigchain_fileobj_check_list
test_fileobj(0, "Hello, world!")
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 177, in test_fileobj
fileobjlist[i].close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/dup_temp.py",
 line 227, in close
assert not self.fileobj.close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 304, in close
self.gpg_failed()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 271, in gpg_failed
raise GPGError(msg)
GPGError: GPG Failed, see log below:
= Begin GnuPG log =
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
likely that this message is legitimate.  This is because back
then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!
gpg: WARNING: unsafe permissions on homedir 
'/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/gnupg'
= End GnuPG log =


--
Ran 418 tests in 548.274s

FAILED (errors=1, skipped=3)
Backtrace:
   5 (primitive-load "/gnu/store/h8y2ahqbx83ih4kcf9x5x11wg4q…")
In ice-9/eval.scm:
   191:35  4 (_ _)
In srfi/srfi-1.scm:
640:9  3 (for-each # …)
In 
/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/gnu-build-system.scm:
   799:31  2 (_ _)
In 
/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/python-build-system.scm:
142:8  1 (check #:tests? _ #:test-target _ #:use-setuptools? _)
In 
/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/5sy3815dpjcvxhssaba6g2ilxm29va9n-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
builder for `/gnu/store/ghxnpxvxvgpgcrf0b7a5ia4s7lm5aha6-duplicity-0.7.17.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/1439zhmkrg58n15mj5m9nmx6sxd01km5-deja-dup-34.3.drv': 1 dependencies 
couldn't be built
guix package: error: build failed: build of 
`/gnu/store/1439zhmkrg58n15mj5m9nmx6sxd01km5-deja-dup-34.3.drv' failed


signature.asc
Description: PGP signature

bug#31773: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

[Christopher Baines]

Hey,

The Guix package for duplicity is failing to build, and I was wondering
if there is a fix already? I've had a look on Launchpad, but didn't spot
anything.

Here is the error:

==
ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)
Test getting signature chain fileobjs from archive_dir
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 188, in test_sigchain_fileobj
self.sigchain_fileobj_check_list(self.sigchain_fileobj_get(None))
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 180, in sigchain_fileobj_check_list
test_fileobj(0, "Hello, world!")
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/unit/test_collections.py",
 line 177, in test_fileobj
fileobjlist[i].close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/dup_temp.py",
 line 227, in close
assert not self.fileobj.close()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 304, in close
self.gpg_failed()
  File 
"/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/duplicity/gpg.py", 
line 271, in gpg_failed
raise GPGError(msg)
GPGError: GPG Failed, see log below:
= Begin GnuPG log =
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
likely that this message is legitimate.  This is because back
then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!
gpg: WARNING: unsafe permissions on homedir 
'/tmp/guix-build-duplicity-0.7.17.drv-0/duplicity-0.7.17/testing/gnupg'
= End GnuPG log =


--
Ran 418 tests in 548.274s

FAILED (errors=1, skipped=3)


Thanks,

Chris


signature.asc
Description: PGP signature

bug#31791: bootstrap phase attempts to run a directory

[Christopher Baines]

I've just noticed that the erlang package has started failing to
build. It looks like the bootstrap phase is over eager, and attempts to
run the bootstrap directory.

I think I'll fix this by deleting the phase, when I get around to
merging the changes in #31678, but this might be affecting other
packages, or possible to sure up so it doesn't break under this
circumstance.


starting phase `bootstrap'
running './bootstrap'
Backtrace:
   8 (primitive-load "/gnu/store/g1n7gbvcqcaj9s41gk62x7crc34?")
In ice-9/eval.scm:
   191:35  7 (_ _)
In srfi/srfi-1.scm:
640:9  6 (for-each # ?)
In 
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:
   799:31  5 (_ _)
   196:20  4 (bootstrap #:bootstrap-scripts _)
In 
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/utils.scm:
178:8  3 (call-with-ascii-input-file _ _)
   831:24  2 (_ #)
792:2  1 (get-char* _)
In unknown file:
   0 (get-u8 #)

ERROR: In procedure get-u8:
In procedure fport_read: Is a directory
builder for `/gnu/store/v5dshhj3bka541h12fk2xskmfj38y8qs-erlang-20.2.3.drv' 
failed with exit code 1
@ build-failed /gnu/store/v5dshhj3bka541h12fk2xskmfj38y8qs-erlang-20.2.3.drv - 
1 builder for `/gnu/store/v5dshhj3bka541h12fk2xskmfj38y8qs-erlang-20.2.3.drv' 
failed with exit code 1
guix build: error: build failed: build of 
`/gnu/store/v5dshhj3bka541h12fk2xskmfj38y8qs-erlang-20.2.3.drv' failed


signature.asc
Description: PGP signature

bug#33248: python-minimal compilation is breaking

[Christopher Baines]

Gábor Boskovits  writes:

>  ezt írta (időpont: 2018. nov. 3., Szo 7:13):
>
>> I am watching this bug on Lenovo G50-30 (CPU 2.1 GHz, 2Gb Ram):
>>
>> # guix pull  --substitute-urls=https://berlin.guixsd.org
>> Updating channel 'guix' from Git repository at '
>> https://git.savannah.gnu.org/git/guix.git'...
>> Building from this channel:
>>   guix  https://git.savannah.gnu.org/git/guix.git3995e85
>> Computing Guix derivation for 'x86_64-linux'... \
>> nothing to be done
>>
>> # guix package  --substitute-urls=https://berlin.guixsd.org -u
>> substitute: updating substitutes from 'https://berlin.guixsd.org'...
>> 100.0%
>> substitute: updating substitutes from 'https://berlin.guixsd.org'...
>> 100.0%
>> building
>> /gnu/store/6c4g38n9fhvnlk2vasn34mdd6nvpgx8m-python-minimal-3.6.5.drv...
>> /Killed
>> #
>>
>> Python-minimal cannot compile.
>>
>
> Most probably you are hitting a resource limit, I guess ram. Do you have
> any swap?

I think I've hit the same problem, I tried with 32GB of RAM, along with
60GB of swap, and it still didn't work.

There is a bug here describing it as a memory link [1], which is a
better theory I think.

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33213


signature.asc
Description: PGP signature

bug#33517: Problem booting when using btrfs subvolume for /gnu/store

[Christopher Baines]

I'm loosing track of this issue a bit, as I've been dealing with it for
a while. I have a machine that I've setup where /gnu/store is a btrfs
subvolume. I do this so that I can make flexible use of the space on
that btrfs filesystem.

Unfortunately, the grub configuration generated for this doesn't seem to
account for this, and so it requires some tweaking to get it to boot.

A long while back, I discovered I could make the following change, then
the generated grub configuration would be fine.


---
 gnu/bootloader/grub.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 06856dd58c..c3ddc3e128 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -320,8 +320,8 @@ entries corresponding to old generations of the system."
   ;; Use the right file names for KERNEL and INITRD in case
   ;; DEVICE-MOUNT-POINT is not "/", meaning that the store is on a
   ;; separate partition.
-  (let ((kernel  (strip-mount-point device-mount-point kernel))
-(initrd  (strip-mount-point device-mount-point initrd)))
+  (let ((kernel kernel)
+(initrd initrd))
 #~(format port "menuentry ~s {
   ~a
   linux ~a ~a
--
2.19.2


Unfortunately, it's not a proper solution, as it obviously breaks when
you actually want to strip the mount point off so that grub can find the
right files.

I'm creating a bug for this, as I think it would be good to track the
issue. I've also written a system test that I believe reproduced the
issue.

From 7eee5685f95d0b6baeb97f5fdd947fe5223a61c9 Mon Sep 17 00:00:00 2001
From: Christopher Baines 
Date: Fri, 26 Oct 2018 18:48:32 +0100
Subject: [PATCH] WIP Btrfs store subvolume test

---
 gnu/tests/install.scm | 91 ++-
 1 file changed, 90 insertions(+), 1 deletion(-)

diff --git a/gnu/tests/install.scm b/gnu/tests/install.scm
index 4764de..cfa071187c 100644
--- a/gnu/tests/install.scm
+++ b/gnu/tests/install.scm
@@ -43,7 +43,8 @@
 %test-separate-home-os
 %test-raid-root-os
 %test-encrypted-os
-%test-btrfs-root-os))
+%test-btrfs-root-os
+%test-btrfs-root-with-store-subvolume-os))
 
 ;;; Commentary:
 ;;;
@@ -826,4 +827,92 @@ build (current-guix) and then store a couple of full system images.")
  (command (qemu-command/writable-image image)))
   (run-basic-test %btrfs-root-os command "btrfs-root-os")
 
+
+;;;
+;;; Btrfs root file system with store subvolume.
+;;;
+
+(define-os-with-source (%btrfs-root-with-store-subvolume-os
+%btrfs-root-with-store-subvolume-os-source)
+  ;; The OS we want to install.
+  (use-modules (gnu) (gnu tests) (srfi srfi-1))
+
+  (operating-system
+(host-name "liberigilo")
+(timezone "Europe/Paris")
+(locale "en_US.UTF-8")
+
+(bootloader (bootloader-configuration
+ (bootloader grub-bootloader)
+ (target "/dev/vdb")))
+(kernel-arguments '("console=ttyS0"))
+(file-systems (cons* (file-system
+   (device (file-system-label "my-root"))
+   (mount-point "/")
+   (type "btrfs"))
+ (file-system
+   (device (file-system-label "my-root"))
+   (mount-point "/gnu/store")
+   (type "btrfs")
+   (options "subvol=/gnu/store"))
+ %base-file-systems))
+(users (cons (user-account
+  (name "charlie")
+  (group "users")
+  (home-directory "/home/charlie")
+  (supplementary-groups '("wheel" "audio" "video")))
+ %base-user-accounts))
+(services (cons (service marionette-service-type
+ (marionette-configuration
+  (imported-modules '((gnu services herd)
+  (guix combinators)
+%base-services
+
+(define %btrfs-root-with-store-subvolume-installation-script
+  ;; Shell script of a simple installation.
+  "\
+. /etc/profile
+set -e -x
+guix --version
+
+export GUIX_BUILD_OPTIONS=--no-grafts
+ls -l /run/current-system/gc-roots
+parted --script /dev/vdb mklabel gpt \\
+  mkpart primary ext2 1M 3M \\
+  mkpart primary ext2 3M 2G \\
+  set 1 boot on \\
+  set 1 bios_grub on
+mkfs.btrfs -L my-root /dev/vdb2
+mount /dev/vdb2 /mnt
+btrfs subvolume create /mnt/home
+mkdir /mnt/gnu
+btrfs subvolume create /mnt/gnu/store
+herd start cow-store /mnt
+mkdir /mn

bug#33517: Problem booting when using btrfs subvolume for /gnu/store

[Christopher Baines]

Ludovic Courtès  writes:

> Hello,
>
> Christopher Baines  skribis:
>
>> Unfortunately, it's not a proper solution, as it obviously breaks when
>> you actually want to strip the mount point off so that grub can find the
>> right files.
>
> Is there a way ‘strip-mount-point’ or some higher-level code could
> determine whether we actually need to strip the mount point?

So, this is the file-system value that I'm using currently for the
store. The information about subvolume is in the options value.

(file-system
  (device (uuid "84fc6b78-d7ff-45df-8659-bef44b5bf0ea"))
  (type "btrfs")
  (title 'uuid)
  (mount-point "/gnu/store")
  (needed-for-boot? #t)
  (options "subvol=/gnu/store"))

I guess one approach for dealing with this would be to allow directly
configuring the stripping of the mount point somehow. Or maybe having
some btrfs-file-system record, which could store the subvol option in a
more machine readable way.

One thing that still makes me uncertian, is how grub actually is trying
to find files on the btrfs filesystem. I tried changing the default
subvolume to the one containing the store, but that didn't seem to
help. Looks like it might not be aware of subvolumes.


signature.asc
Description: PGP signature

bug#33638: ruby-sass-spec substitute hash mismatch (mirror.hydra.gnu.org)

[Christopher Baines]

substituting /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
downloading from 
https://mirror.hydra.gnu.org/guix/nar/gzip/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
 ruby-sass-spec-3.5.4  1.3MiB   
1.2MiB/s 
00:01 [##] 100.0%

sha256 hash mismatch for 
/gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4:
  expected hash: 1kq3ndiv72krwb5h8bissdarm9lbbl7zbfbnzyfwnncsjh6p5xcr
  actual hash:   0x0rzrvjm7q6x20bk5k2hc13zhp12njfga3b3azky4p2yxv60hcy
substitution of 
/gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4 failed
guix build: error: build failed: some substitutes for the outputs of derivation 
`/gnu/store/xizmf292d80dxgv35z2ik4zimrcfzrx5-ruby-sass-spec-3.5.4.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source 


signature.asc
Description: PGP signature

bug#33638: ruby-sass-spec substitute hash mismatch (mirror.hydra.gnu.org)

[Christopher Baines]

Leo Famulari  writes:

> On Wed, Dec 05, 2018 at 10:05:57PM +0000, Christopher Baines wrote:
>> 
>> substituting 
>> /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
>> downloading from 
>> https://mirror.hydra.gnu.org/guix/nar/gzip/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
>>  ruby-sass-spec-3.5.4  1.3MiB
>>
>> 1.2MiB/s 00:01 [##] 100.0%
>> 
>> sha256 hash mismatch for 
>> /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4:
>>   expected hash: 1kq3ndiv72krwb5h8bissdarm9lbbl7zbfbnzyfwnncsjh6p5xcr
>>   actual hash:   0x0rzrvjm7q6x20bk5k2hc13zhp12njfga3b3azky4p2yxv60hcy
>> substitution of 
>> /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4 failed
>> guix build: error: build failed: some substitutes for the outputs of 
>> derivation 
>> `/gnu/store/xizmf292d80dxgv35z2ik4zimrcfzrx5-ruby-sass-spec-3.5.4.drv' 
>> failed (usually happens due to networking issues); try `--fallback' to build 
>> derivation from source 
>
> Are you still having this issue? It seems to work for me now.

I can't quite remember what computer I was using at the time, but yes,
it does seem to work now for me.


substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
1.4 MB will be downloaded:
   /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4
substituting /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
downloading from 
https://mirror.hydra.gnu.org/guix/nar/gzip/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4...
 ruby-sass-spec-3.5.4  1.3MiB   
1.4MiB/s 
00:01 [##] 100.0%

/gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4


signature.asc
Description: PGP signature

bug#33932: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1. (was: Re: bug#33932: Artanis fails to build - 0.3.1 is out)

[Christopher Baines]

swedebugia  writes:

> On 2019-01-02 22:50, swedebugia wrote:
>> On 2018-12-31 13:33, Ricardo Wurmus wrote:
>>>
>>> Hi swedebugia,
>>>
 We should upgrade.
>>>
>>> Could you please send a patch?
>>>
>>
>> Here it is :)

I haven't looked too closely at the patch, but I think the newer version
of Artanis have bundled guile-redis (or something like that), so it
would be good to look at unbundling it, similar to how guile-json is
handled.


signature.asc
Description: PGP signature

bug#34124: gnome-shell crash when opening the activities overview

[Christopher Baines]

On one system running GuixSD, Gnome Shell crashes when opening the
activities overview (super key, or clicking on the activities button in
the top left).


(.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639: 
g_file_new_for_path: assertion 'path != NULL' failed

(.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639: 
g_loadable_icon_load: assertion 'G_IS_LOADABLE_ICON (icon)' failed

(.gnome-shell-real:2471): Gtk-WARNING **: 10:36:30.639: Could not load a pixbuf 
from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkicontheme.c:4261:gtk_icon_info_load_icon_finish: assertion failed: 
(icon_info_get_pixbuf_ready (icon_info))


signature.asc
Description: PGP signature

bug#31773: Duplicit fails to build: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

[Christopher Baines]

I ended up pushing a patch [1] for this as part of [2]. This has now
been released by upstream, so the change doesn't exist in the Guix
codebase any longer (the package was updated in [3]).

1: e61f092c877da5a9dc5dcdd82690bd3c191769e1
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e61f092c877da5a9dc5dcdd82690bd3c191769e1

2: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32303

3: 7bb7920f64a871eadd8e76687f72673ef2298746
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7bb7920f64a871eadd8e76687f72673ef2298746


signature.asc
Description: PGP signature

bug#33470: [bug#34249] [PATCH] guix package: Avoid spinner at end of output.

[Christopher Baines]

Ludovic Courtès  writes:

> Danny Milosavljevic  skribis:
>
>> Hi Christopher,
>>> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
>>> index a633d2ee6d..4db0e72e9b 100644
>>> --- a/guix/scripts/package.scm
>>> +++ b/guix/scripts/package.scm
>>> @@ -159,6 +159,7 @@ hooks\" run when building the profile."
>>> (switch-symlinks profile (basename name))
>>> (unless (string=? profile %current-profile)
>>>   (register-gc-root store name))
>>> +   (display "\r") ; erase the spinner
>>
>> In order to actually erase it, might want to do (display "\r\x1b[K") instead.
>
> And to do that, you can use (erase-current-line port).
>
> Though actually I think this should be done in ‘print-build-event’ in
> (guix status).  Probably something like the patch below, but I haven’t
> been able to quickly reproduce the initial problem.
>
> Could you give it a spin (ah ha!) and report back?
>
> If it doesn’t solve the issue, we should strace the thing to see why it
> keeps spinning after everything is “done” basically.
>
> Thanks,
> Ludo’.
>
> diff --git a/guix/status.scm b/guix/status.scm
> index e3375816c5..7a330525b0 100644
> --- a/guix/status.scm
> +++ b/guix/status.scm
> @@ -465,8 +465,14 @@ addition to build events."
>  (_
>   (spin! port))
>
> -  (unless print-log?
> -(display "\r" port))  ;erase the spinner
> +  (define erase-current-line*
> +(if (isatty?* port)
> +(lambda (port)
> +  (erase-current-line port)
> +  (force-output port))
> +(const #t)))
> +
> +  (erase-current-line* port)  ;clear the spinner
>(match event
>  (('build-started drv . _)
>   (let ((properties (derivation-properties

I've tried out the change you pushed here [1], and it looks good to me
:) I can't see anything odd in the output now.

1: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7473bce207af846312d5167a398f5f20bbf3e896


signature.asc
Description: PGP signature

bug#34567: Bogus 'upower-service' deprecation message

[Christopher Baines]

Mark H Weaver  writes:

> My OS config includes a reference to 'upower-service', which is now
> deprecated, but the deprecation message is bogus:
>
>   mhw@jojen ~$ guix system build /etc/config.scm --verbosity=1
>   /etc/config.scm:149:19: warning: 'slim-service' is deprecated, use 
> 'slim-service-type' instead
>   /etc/config.scm:156:19: warning: 'upower-service' is deprecated, use 
> 'Return a service that runs @uref{http://upower.freedesktop.org/,
>   @command{upowerd}}, a system-wide monitor for power consumption and battery
>   levels, with the given configuration settings.  It implements the
>   @code{org.freedesktop.UPower} D-Bus interface, and is notably used by 
> GNOME.' instead
>   building 
> /gnu/store/nwdjz1mkvcc4ic65mgw5i94ig3qzp8kf-libjpeg-turbo-2.0.2.tar.gz.drv...
>   [...]

Haha, that is quite bogus. I didn't realise define-deprecated took two
arguments. I've sent a patch to fix this here [1].

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34579


signature.asc
Description: PGP signature

bug#25453: Inconsistent keyboard layout affecting encrypted root

[Christopher Baines]

Ludovic Courtès  writes:

> Hi Chris!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> Christopher Baines  skribis:
>>
>>> I'm using a UK keyboard layout with a computer that I recently installed
>>> GuixSD on with a encrypted root parition. Immediately after installation
>>> when I attempted to boot in to the new system for the first time I had
>>> to enter the passphrase twice, and in doing this, first I had to use the
>>> keyboard layout under which I carried out the installation (the layout
>>> which I had intended to use), and then during the early boot stage of
>>> the system I had to enter the passphrase using a different keyboard
>>> layout.
>>
>> Currently installing a keymap is something done by the ‘console-keymap’
>> Shepherd service, which invokes ‘loadkeys’.  That happens after
>> “cryptsetup --open” has opened your encrypted root device, hence the
>> problem.
>
> This is finally fixed by commit
> ae7a316b9da0d1a50c5abdc531c68c8e98e561c9, which initializes the console
> keyboard layout straight from the initrd.

Exciting, thanks Ludo :)


signature.asc
Description: PGP signature

bug#35243: ungoogled-chromium build stops and freezes the system

[Christopher Baines]

zna...@disroot.org writes:

> My bug report is this https://github.com/Eloston/ungoogled-chromium/issues/730
>
> During update with `guix pull && guix package -u` ungoogled-chromium build 
> process stops on build derivation on 84% three times in a row.

What does your system memory and swap look like at that point,
ungoogled-chromium requires quite a lot of memory to build.

If this is indeed an issue, you might be able to reduce the peak memory
requirement by reducing the number of cores used through --cores.


signature.asc
Description: PGP signature

bug#35387: unpack phase in the gnu-build-system is sometimes non-deterministic

[Christopher Baines]

I believe that the direnv package has encountered an issue with the
gnu-build-system [1].

1: https://issues.guix.info/issue/35386

Due to the combination of the 'setup-go-environment phase from the
go-build-system, and the 'unpack phase of the gnu-build-system, there
are two directories to be considered by first-subdirectory when called
from the unpack phase.

It seems from direnv that this either consistently, with the package
working on one machine, or failing consistently on another.

To avoid issues like this in the future, I think it would be good to
have first-subdirectory raise an error if it's behaviour could be
non-deterministic.


signature.asc
Description: PGP signature

bug#34124: gnome-shell crash when opening the activities overview

[Christopher Baines]

Ricardo Wurmus  writes:

> Christopher Baines  writes:
>
>> On one system running GuixSD, Gnome Shell crashes when opening the
>> activities overview (super key, or clicking on the activities button in
>> the top left).
>>
>>
>> (.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639: 
>> g_file_new_for_path: assertion 'path != NULL' failed
>>
>> (.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639: 
>> g_loadable_icon_load: assertion 'G_IS_LOADABLE_ICON (icon)' failed
>>
>> (.gnome-shell-real:2471): Gtk-WARNING **: 10:36:30.639: Could not load a 
>> pixbuf from icon theme.
>> This may indicate that pixbuf loaders or the mime database could not be 
>> found.
>> **
>> Gtk:ERROR:gtkicontheme.c:4261:gtk_icon_info_load_icon_finish: assertion 
>> failed: (icon_info_get_pixbuf_ready (icon_info))
>
> Could you try to see if setting LD_LIBRARY_PATH in the environment where
> GNOME Shell is launched to the lib directory of the “gdk-pixbuf+svg” (or
> “gdk-pixbuf”) package makes any difference?
>
> You may need to do this in ~/.xsession and launch the gnome-session
> manually.

It's been a while since I've experienced this issue, and I don't think I
have the generation that was affected around anymore.

If I remember, I think I may have worked around this by removing a
package, although I'm not sure which.


signature.asc
Description: PGP signature

bug#34124: gnome-shell crash when opening the activities overview

[Christopher Baines]

Ben Sturmfels  writes:

> On Tue, 2019-04-23 at 21:33 +0100, Christopher Baines wrote:
>> Ricardo Wurmus  writes:
>>
>> > Christopher Baines  writes:
>> >
>> > > On one system running GuixSD, Gnome Shell crashes when opening
>> > > the
>> > > activities overview (super key, or clicking on the activities
>> > > button in
>> > > the top left).
>> > >
>> > >
>> > > (.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639:
>> > > g_file_new_for_path: assertion 'path != NULL' failed
>> > >
>> > > (.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639:
>> > > g_loadable_icon_load: assertion 'G_IS_LOADABLE_ICON (icon)'
>> > > failed
>> > >
>> > > (.gnome-shell-real:2471): Gtk-WARNING **: 10:36:30.639: Could not
>> > > load a pixbuf from icon theme.
>> > > This may indicate that pixbuf loaders or the mime database could
>> > > not be found.
>> > > **
>> > > Gtk:ERROR:gtkicontheme.c:4261:gtk_icon_info_load_icon_finish:
>> > > assertion failed: (icon_info_get_pixbuf_ready (icon_info))
>> >
>> > Could you try to see if setting LD_LIBRARY_PATH in the environment
>> > where
>> > GNOME Shell is launched to the lib directory of the “gdk-
>> > pixbuf+svg” (or
>> > “gdk-pixbuf”) package makes any difference?
>> >
>> > You may need to do this in ~/.xsession and launch the gnome-session
>> > manually.
>>
>> It's been a while since I've experienced this issue, and I don't
>> think I
>> have the generation that was affected around anymore.
>>
>> If I remember, I think I may have worked around this by removing a
>> package, although I'm not sure which.
>
> Christopher, can you tell me how you found these error messages? I'm
> interested in troubleshooting to see if I'm having the same issue.
>
> All I can find is the following in /var/log/messages after I click
> "Activities", "Show Applications":
>
> Apr 24 13:56:34 localhost gnome-session-binary[857]: WARNING:
> Application 'org.gnome.Shell.desktop' killed by signal 6

I think I ran `gnome-shell --replace` from a terminal, and watched the
output. You might also have some success writing to a log file,
e.g. `gnome-shell --replace 1>&2 | tee gnome-shell.log`.


signature.asc
Description: PGP signature

bug#35387: unpack phase in the gnu-build-system is sometimes non-deterministic

[Christopher Baines]

Ludovic Courtès  writes:

> Hi Chris,
>
> Christopher Baines  skribis:
>
>> I believe that the direnv package has encountered an issue with the
>> gnu-build-system [1].
>>
>> 1: https://issues.guix.info/issue/35386
>>
>> Due to the combination of the 'setup-go-environment phase from the
>> go-build-system, and the 'unpack phase of the gnu-build-system, there
>> are two directories to be considered by first-subdirectory when called
>> from the unpack phase.
>>
>> It seems from direnv that this either consistently, with the package
>> working on one machine, or failing consistently on another.
>>
>> To avoid issues like this in the future, I think it would be good to
>> have first-subdirectory raise an error if it's behaviour could be
>> non-deterministic.
>
> ‘file-system-fold’ is just a wrapper around ‘readdir’ so the order in
> which it sees directory entries is non-deterministic.
>
> What about writing it like this:
>
>   (define (first-subdirectory directory)
> "Return the file name of the first sub-directory of DIRECTORY."
> (match (scandir directory
> (lambda (file)
>   (and (not (member file '("." "..")))
>(file-is-directory? (string-append directory "/"
>   file)
>   ((first . _) first)))
>
> The result will be deterministic since ‘scandir’ sorts entries.

That sounds great :)


signature.asc
Description: PGP signature

bug#36634: Virtual Machine Manager (virt-manager)

[Christopher Baines]

Raghav Gururajan  writes:

> libvirt.libvirtError: Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory

So, I've experienced this too. Even though this is a cgroup thing, I'm
pretty sure this isn't an issue with Linux.

I've tried reverting the changes in [1], and that seems to solve the
issue. Unfortunately, I don't have any insight in to what's different
between the problematic 5.5.0 release, and the working 5.4.0 release.

1: 458fe419232844d2021608d20dcd8f6e095eb2b4
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=458fe419232844d2021608d20dcd8f6e095eb2b4


signature.asc
Description: PGP signature

bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

[Christopher Baines]

Ludovic Courtès  writes:

> For now, I’m going to go with the solution below, which is to use an
> older revision of Guix (one where ‘open-inferior’ was using
> ‘open-pipe*’) as the dependency of the ‘cuirass’ package.
>
> I’m running “cuirass evaluate” manually on berlin to make sure it
> actually works.  If everything goes well, I’ll push it and reconfigure
> berlin later today or tomorrow.

To put in an email something I put on IRC earlier.

Maybe the store connection caching could be optional when calling
inferior-eval-with-store, and that could also switch between using
open-pipe* and primitive-fork for starting the inferior process.

I'm guessing the use of primitive-fork for starting the inferior process
is causing problems with Cuirass in some cases, and it's possible that
it'll affect the data service in a similar way as well.

I don't think the connection caching actually benefits Cuirass though,
since it only calls inferior-eval-with-store once per inferior.

Additionally, on the data service side, the caching functionality is
actually undesirable as it leads to the inferior process running out of
memory, so currently the cache is manually cleared in various places
[1].

1: 
http://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=ff116d5e6437ffb916aa4bc5d1458a142297a900


signature.asc
Description: PGP signature

bug#56353: sbcl-2.2.6 build fail

[Christopher Baines]

Tobias Geerinckx-Rice via Bug reports for GNU Guix  writes:

> On 2 July 2022 09:29:22 UTC, Wensheng Xie  wrote:
>>Das Erstellungsprotokoll kann unter 
>>„/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ 
>>eingesehen werden.
>
>
> This log file is always a good idea to include.

I think this is the equivalent non-grafted derivation:

  
https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv

There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
get it to build successfully once though on my laptop.

Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
successfully, or if there's particular conditions for it to build?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#56353: sbcl-2.2.6 build fail

[Christopher Baines]

Guillaume Le Vaillant  writes:

> [[PGP Signed Part:Undecided]]
> Christopher Baines  skribis:
>
>> Tobias Geerinckx-Rice via Bug reports for GNU Guix  writes:
>>
>>> On 2 July 2022 09:29:22 UTC, Wensheng Xie  wrote:
>>>>Das Erstellungsprotokoll kann unter 
>>>>„/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ 
>>>>eingesehen werden.
>>>
>>>
>>> This log file is always a good idea to include.
>>
>> I think this is the equivalent non-grafted derivation:
>>
>>   
>> https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv
>>
>> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to
>> get it to build successfully once though on my laptop.
>>
>> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build
>> successfully, or if there's particular conditions for it to build?
>>
>> Thanks,
>>
>> Chris
>
> According to the logs, the 'build-doc' phase fails to compile the
> documentation for SIMD related functions. There's a patch disabling this
> part of the doc unless we compile on x86_64, but maybe not all x86_64
> CPUs have the required instructions...
>
> Would it be possible to get the result of "lscpu" on some machines where
> it fails?

Sure, here is the lscpu output from the bayfront and harbourfront
machines.

Architecture:x86_64
  CPU op-mode(s):32-bit, 64-bit
  Address sizes: 48 bits physical, 48 bits virtual
  Byte Order:Little Endian
CPU(s):  32
  On-line CPU(s) list:   0-31
Vendor ID:   AuthenticAMD
  Model name:AMD Opteron(tm) Processor 6278
CPU family:  21
Model:   1
Thread(s) per core:  2
Core(s) per socket:  8
Socket(s):   2
Stepping:2
Frequency boost: enabled
CPU max MHz: 2400.
CPU min MHz: 1400.
BogoMIPS:4799.96
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_go
 od nopl nonstop_tsc cpuid extd_apicid amd_dcm 
aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx 
lahf_lm cmp_legacy svm extapic cr8_legac
 y abm sse4a misalignsse 3dnowprefetch osvw ibs xop 
skinit wdt lwp fma4 topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall 
arat npt lbrv svm_lock nrip_save ts
 c_scale vmcb_clean flushbyasid decodeassists 
pausefilter pfthreshold
Virtualization features: 
  Virtualization:AMD-V
Caches (sum of all): 
  L1d:   512 KiB (32 instances)
  L1i:   1 MiB (16 instances)
  L2:32 MiB (16 instances)
  L3:24 MiB (4 instances)
NUMA:
  NUMA node(s):  4
  NUMA node0 CPU(s): 0-7
  NUMA node1 CPU(s): 8-15
  NUMA node2 CPU(s): 16-23
  NUMA node3 CPU(s): 24-31
Vulnerabilities: 
  Itlb multihit: Not affected
  L1tf:  Not affected
  Mds:   Not affected
  Meltdown:  Not affected
  Spec store bypass: Mitigation; Speculative Store Bypass disabled via 
prctl and seccomp
  Spectre v1:Mitigation; usercopy/swapgs barriers and __user 
pointer sanitization
  Spectre v2:Mitigation; Full AMD retpoline, STIBP disabled, RSB 
filling
  Srbds: Not affected
  Tsx async abort:   Not affected
Architecture:   x86_64
  CPU op-mode(s):   32-bit, 64-bit
  Address sizes:38 bits physical, 48 bits virtual
  Byte Order:   Little Endian
CPU(s): 8
  On-line CPU(s) list:  0-7
Vendor ID:  GenuineIntel
  Model name:   Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz
CPU family: 6
Model:  23
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s):  2
Stepping:   10
BogoMIPS:   4987.55
Flags:  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts 
rep_good nopl cpuid aperfmperf pni dtes64 monitor 
ds_cpl est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm pti dtherm
Caches (sum of all):
  L1d:  256 KiB (8 instances)
  L1i:  256 KiB (8 instances)
  L2:   24 MiB (4 instances)
NUMA:   
  NUMA node(s): 1
  NUMA node0 CPU(s):0-7
Vulnerabilities:
  Itlb multihit:KVM: Mitigation: VMX unsup

bug#57215: ci: Fail to evaluate Guix specification

[Christopher Baines]

Mathieu Othacehe  writes:

> Now there are multiple unclear points to me:
>
> 1. Why do we need an available machine with the foreign architecture to
> compute the corresponding "guix" derivation? Note that the evaluation of
> package derivations for foreign systems works even though a
> corresponding machine is not available:
>
> mathieu@berlin ~$ guix build -s powerpc64le-linux -d hello
> /gnu/store/spzmh79qi21k26p15w27r3jjg95szg17-hello-2.12.1.drv

This has been something I've been interested in as well, since the Guix
Data Service has the same problem when computing these derivations.

I think the latest information I have is set out here:

  https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00196.html

So, I think there's some involvement of grafts that mean you end up
building things when just trying to compute the derivation. But that's
as far as I got, I don't really understand why this is the case, or what
can be done about it.

Chris


signature.asc
Description: PGP signature

bug#57215: ci: Fail to evaluate Guix specification

[Christopher Baines]

Mathieu Othacehe  writes:

> Hey,
>
>> So, I think there's some involvement of grafts that mean you end up
>> building things when just trying to compute the derivation. But that's
>> as far as I got, I don't really understand why this is the case, or what
>> can be done about it.
>
> Thanks for sharing Chris, I tried to disable grafts, but I was not able
> to go any further:
>
> mathieu@berlin ~$ guix pull -s powerpc64le-linux -v3  --no-grafts
...

> guix pull: error: build of 
> `/gnu/store/z7jij9k33bl8dm50zrhy97jxqwylx1s8-compute-guix-derivation.drv' 
> failed
>
> Maybe we should open a specific bug-report for that particular issue?

I think the grafting comes in here [1], within the build-self.scm
script, and I think that the --no-grafts argument to guix pull doesn't
currently affect the behaviour at that point.

1: https://git.savannah.gnu.org/cgit/guix.git/tree/build-aux/build-self.scm#n350

That's where the patch here [2] comes in, as it makes it possible to
control the grafting behaviour at that point, at least enough to
demonstrate that there's some change in behaviour.

2: https://lists.gnu.org/archive/html/guix-devel/2022-02/txtgzexu0El5b.txt


signature.asc
Description: PGP signature

bug#57596: guix lint --checkers=derivation doesn't complete, Too many heap sections

[Christopher Baines]

When running the derivation checker on all packages for recent guix
revisions, it dones't seem to complete. Instead, you get an error which
I think comes from the garbage collection implementation that Guile
uses:

  → guix lint --checkers=derivation
  Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
  Aborted

I noticed this on data.guix.gnu.org, as it effectively does something
similar when trying to record the lint warnings for a revision.

Maybe there's enough derivations now that the process of computing them
all is too much for Guile? Or maybe it's something in the graph that's
forming a loop?

Chris


signature.asc
Description: PGP signature

bug#57596: guix lint --checkers=derivation doesn't complete, Too many heap sections

[Christopher Baines]

Christopher Baines  writes:

> When running the derivation checker on all packages for recent guix
> revisions, it dones't seem to complete. Instead, you get an error which
> I think comes from the garbage collection implementation that Guile
> uses:
>
>   → guix lint --checkers=derivation
>   Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
>   Aborted
>
> I noticed this on data.guix.gnu.org, as it effectively does something
> similar when trying to record the lint warnings for a revision.
>
> Maybe there's enough derivations now that the process of computing them
> all is too much for Guile? Or maybe it's something in the graph that's
> forming a loop?

I've got a bit more information now, I'm guessing the changes in [1]
just tipped the balance as that's when the data service instances
started not being able to process revisions.

1: 
https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range&q=aae98c297214f87eb45302863adb021078c41a6f...d22a5c18517d662516fc93889534367fd3a448f2

I think I've managed to work around this now in the data service [2],
but the problem still remains when running the linter through the
script.

2: 
http://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=b3d59c650a45429f90953e8fd865a3ba76a891cf


signature.asc
Description: PGP signature

bug#57827: Shepherd 0.9.2 possible regressions

[Christopher Baines]

Mathieu Othacehe  writes:

> Since Shepherd 0.9.2 the following tests are failing:
>
> * cgit: https://ci.guix.gnu.org/build/1427375/details
> * gitile https://ci.guix.gnu.org/build/1427377/details
>
> It seems that an unexpected # object is received on the marionette
> socket.

I had a look at the cgit system test, and it seems like this # is
coming from the NGinx pid file being empty.

Since empty files is a possibility with wait-for-file, I've sent a patch
to [1] which prevents the eof issue, plus another change to make it
easier to debug.

1: https://issues.guix.gnu.org/57850

With that change, both of the above tests seem to pass for me.

This could be related to the Shepherd upgrade, but only indirectly, as I
think the failure at least for cgit was also timing dependent.

Chris


signature.asc
Description: PGP signature

bug#57965: Problem with freecad substitute

[Christopher Baines]

Aleksandr Vityazev  writes:

> I want to install freecad, substitute available but the package starts
> building locally.

This is probably due to you ACL, see
https://guix.gnu.org/en/manual/devel/en/html_node/Substitute-Server-Authorization.html#Substitute-Server-Authorization


signature.asc
Description: PGP signature

bug#57965: Problem with freecad substitute

[Christopher Baines]

Aleksandr Vityazev  writes:

> Hi,
>
> On 2022-09-21, 08:25 +0100, Christopher Baines  wrote:
>
>> Aleksandr Vityazev  writes:
>>
>>> I want to install freecad, substitute available but the package starts
>>> building locally.
>>
>> This is probably due to you ACL, see
>> https://guix.gnu.org/en/manual/devel/en/html_node/Substitute-Server-Authorization.html#Substitute-Server-Authorization
>>
>
> It says at the beginning of the section:
>
> Note: If you are using Guix System, you can skip this section: Guix
>  System authorizes substitutes from ‘ci.guix.gnu.org’ and
>  ‘bordeaux.guix.gnu.org’ by default.
>
>
> all packages except the ones marked are installed normally.

Ok, if you are using guix system, you need to check the configuration
for the guix-daemon, in particular the substitute URLs and ACL
(authorized-keys).

Assuming you're using a recent revision of Guix, boreaux.guix.gnu.org
should be in the default substitute URLs and default authorized-keys.

If you're still having problems, sharing the contents of /etc/guix/acl
as well as the arguments the guix-daemon is running with will help.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#57965: Problem with freecad substitute

[Christopher Baines]

Aleksandr Vityazev  writes:

> On 2022-09-21, 09:26 +0100, Christopher Baines  wrote:
>
>> Assuming you're using a recent revision of Guix, boreaux.guix.gnu.org
>> should be in the default substitute URLs and default authorized-keys.
>>
>> If you're still having problems, sharing the contents of /etc/guix/acl
>> as well as the arguments the guix-daemon is running with will help.
>>
>
> ...
>
> As I said, installing with substitutes of all but two packages,
> telegram-desktop and freecad, works fine.

Your ACL and guix-daemon arguments look fine.

Caching is one possibility, /var/guix/substitute/cache/ is usually where
substitute information gathered up by the guix-daemon is stored. It
could be that the absence of this output has been stored. You could try
deleting the contents of /var/guix/substitute/cache/.

Otherwise, dealing with the outputs directly does make debugging this
easier. If you compute the derivation, that contains the output near the
top. You can then ask guix build to substitute it.

→ guix build --no-grafts -d freecad
/gnu/store/q3pka0ql599z85zdy507fh8vrabaz5lp-freecad-0.20.1.drv

→ cat /gnu/store/q3pka0ql599z85zdy507fh8vrabaz5lp-freecad-0.20.1.drv
Derive([("out","/gnu/store/yxys4jxxgyllblm31244r2l23wvkjpv2-freecad-0.20.1","","")]...

→ guix build --substitute-urls=https://bordeaux.guix.gnu.org 
/gnu/store/yxys4jxxgyllblm31244r2l23wvkjpv2-freecad-0.20.1


signature.asc
Description: PGP signature

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

[Christopher Baines]

Leo Famulari  writes:

> On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote:
>> I tried building a newer version, but there were new test suite failures
>> on both aarch64 and x86_64 :/
>
> Since the 'guix' package still does not build on aarch64, I'm reopening
> this bug.

It looks to me that there were problems with the guix package on
aarch64-linux, but it's working currently.

1: 
https://data.guix.gnu.org/repository/1/branch/master/package/guix/output-history?output=out&system=aarch64-linux&target=none

Also, substitute availability for aarch64-linux and armhf-linux is
OK. Does that mean this issue can be closed?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#58508: gtg package (Getting Things GNOME) doesn't run

[Christopher Baines]

Pkill9  writes:

> This is the error I get when running:
>
> guix environment --ad-hoc gtg -- gtg
>
> ```
> Traceback (most recent call last):
>   File "/gnu/store/0x46vnn6nk10dmkjvg9jmzqx65pmjs4r-gtg-0.6/bin/.gtg-real", 
> line 76, in 
> gi.require_version('GtkSource', '4') 
>   File 
> "/gnu/store/vbms7iz53dpdz5iz8ik2blr77w17imva-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/__init__.py",
>  line 126, in require_version
> raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace GtkSource not available
>
> ```

If you're up for tweaking the package definition, try adding
gtksourceview-4 as an input and see if you get the same error.

Chris


signature.asc
Description: PGP signature

bug#58770: guix pull: error: You found a bug: the program '/gnu/store/9kyha1l1a1ynh9nni8428bqdanajck1b-compute-guix-derivation'

[Christopher Baines]

Mark Felt  writes:

> building /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv...
> | 'build' phasebuilder for 
> `/gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv' failed with 
> exit code 1
> build of /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv failed
> Backtrace:
> View build log at 
> '/var/log/guix/drvs/5s/1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv.bz2'.

Hi Mark,

It's not obvious to me why the build of gnutls failed from the log.

It has been built by a substitute server, so providing you're fetching
substitutes from bordeaux.guix.gnu.org, you shouldn't have to build this
locally.

Chris


signature.asc
Description: PGP signature

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Christopher Baines]

Tobias Kortkamp  writes:

> I updated from c8112f3bd95269ce4aca12dedbfe61bb6b37acae to
> 0dec41f329c37a4293a2a8326f1fe7d9318ec455 and now Nautilus crashes
> with:
>
> (org.gnome.Nautilus:3664): GLib-GObject-WARNING **: 13:25:09.877: Two 
> different plugins tried to register 'KgxNautilus'.
>
> (org.gnome.Nautilus:3664): GLib-GObject-CRITICAL **: 13:25:09.877: 
> g_type_add_interface_dynamic: assertion 'G_TYPE_IS_INSTANTIATABLE 
> (instance_type)' failed
>
> (org.gnome.Nautilus:3664): GLib-GObject-WARNING **: 13:25:09.877: Two 
> different plugins tried to register 'KgxNautilusMenuItem'.
>
> ** (org.gnome.Nautilus:3664): WARNING **: 13:25:09.882: Tracker 2 migration: 
> Couldn't run `tracker3`: Failed to execute child process “tracker3” (No such 
> file or directory)
>
> (org.gnome.Nautilus:3664): GLib-GObject-WARNING **: 13:25:10.222: invalid 
> cast from 'KgxNautilus' to ''
>
> (org.gnome.Nautilus:3664): GLib-GObject-CRITICAL **: 13:25:10.222: 
> g_object_new_valist: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
>
> (org.gnome.Nautilus:3664): GLib-GObject-CRITICAL **: 13:25:10.222: 
> g_object_get: assertion 'G_IS_OBJECT (object)' failed
>
> The problem seems to be that NAUTILUS_EXTENSION_PATH contains the same
> path twice and that it tries to load KgxNautilus from each of the paths:
>
> $ echo $NAUTILUS_EXTENSION_PATH
> /run/current-system/profile/lib/nautilus/site-extensions:/run/current-system/profile/lib/nautilus/site-extensions
>
> Running Nautilus like this works fine:
>
> $ 
> NAUTILUS_EXTENSION_PATH=/run/current-system/profile/lib/nautilus/site-extensions
>  nautilus

Thanks for investigating Tobi, I've been experiencing this too, but
didn't get anywhere trying to use GDB, so thanks for tracking it down!

This NAUTILUS_EXTENSION_PATH is a Guix specific modification made to
nautilus at build time, so yeah, something is up here and it's down to
us to fix it.

Maybe the duplication of the directory in the search path is something
to fix, but I guess the code in nautilus using the search path probalbly
needs to be smarter to avoid loading plugins twice.

Chris


signature.asc
Description: PGP signature