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#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#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#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#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#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 <m...@cbaines.net> 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#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 <m...@cbaines.net> 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#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#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#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#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#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#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#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#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#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#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 /mnt/etc
+cp /etc/target-config.scm /mnt/etc/config.s

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#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#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#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#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]

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#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#37348: Force https redirect missing from ci, workflow and workflows guix.info sub-domains

[Christopher Baines]

Collin J. Doering  writes:

> Not sure where the best place to report this, however today I noticed
> that ci.guix.info, workflow.guix.info and workflows.guix.info do not
> redirect http to https, though its also served over https.

I'm unsure if this is intentional, or something to change.

There are security advantages to forcing all users to use HTTPS, with
the disadvantage that some of those users might not want to use
HTTPS. I'm not sure whether the need for security on those domains is
high enough to justify not supporting plain HTTP...


signature.asc
Description: PGP signature

bug#37388: can lead to syntactically invalid configs

[Christopher Baines]

Ludovic Courtès  writes:

>> I wonder if some errors could be caught at build time, before attempting
>> to start the service.
>>
>> If in the derivation to build the configuration file, nginx is run
>> against the built config file with -t, that might spot errors at
>> derivation build time.
>
> Yeah, this is probably doable.
>
> I would consider it a stop-gap measure though.  Fundamentally, I think
> we should make it so that, by construction, invalid (or at least
> syntactically-invalid) config files cannot be produced.

Catching errors earlier is better, but being able to catch any syntactic
issues that have snuck through, as well as semantic ones when building
the configuration would be good I think. I haven't actually tested out
the NGinx configuration check functionality though, so I'm guessing
about what it does.


signature.asc
Description: PGP signature

bug#37388: can lead to syntactically invalid configs

[Christopher Baines]

Ludovic Courtès  writes:

> It’s nice that we have  but I noticed that, unlike
> most or all other configuration records that we have, it’s possible to
> create an  record that leads to a syntactically
> invalid nginx config file.
>
> For example, if you have a location block like this:
>
> (nginx-location-configuration
>   (uri "/manual/")
>   (body (list "alias /srv/guix-manual")))
>
> Guix will silently create an invalid nginx config file, which you’ll
> only notice once you’ve reconfigured and nginx fails to start.

I wonder if some errors could be caught at build time, before attempting
to start the service.

If in the derivation to build the configuration file, nginx is run
against the built config file with -t, that might spot errors at
derivation build time.

> See why?  That’s because we’re missing a semicolon in the “alias”
> directive, and that directive is spit out directly as is.
>
> To address it, we could have record types for , , and all
> the directives out there; it could be tedious, unless we automate it,
> effectively creating a complete EDSL.
>
> Another approach would be to have an sexp representation of the nginx
> configuration language.  That’d effectively replace semicolons with
> parentheses :-), but more importantly, that would allow us to not paste
> strings as-is in the resulting config file.  The downside is that it’s
> very much “free style” compared to records, but we could still
> pattern-match the sexp to validate certain properties.

An sexp representation sounds good, although I think records will work
out better for the common and high level parts.


signature.asc
Description: PGP signature

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

[Christopher Baines]

As version 5.7.0 has been released, I tried updating to that. There
seems to be some issue with the configuration for the socket file, but
even avoiding that, it doesn't seem to resolve the issue with the
cgroups.

For now, I've switched more permanently back to 5.4.0.


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#38167: guix pull takes over 8 GiB of memory to finish if there are no substitutes

[Christopher Baines]

Danny Milosavljevic  writes:

> Hi,
>
> guix pull takes over 8 GiB of memory to finish if there are no substitutes.
>
> My laptop only takes max 8 GiB of RAM.  I've set up swap, but that kind of
> memory usage still seems ridiculous.

Do you know if the derivations got built in parallel? So, does guix pull
--max-jobs=1 use the same amount of memory?


signature.asc
Description: PGP signature

bug#37822: guile-fibers build failure

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> I've now tried running the tests using Guix immediately prior to the
>> recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf),
>> and immediately after the merge
>> (cf3d1763ede1a329c2bc932c84591ab594bb6c96) and the tests passed before,
>> and failed afterwards.
>>
>> I've also tried running the tests manually, I did see a couple of times
>> a failure that mentioned about "Too many open files" [1].
>>
>> I then attempted to raise the limit for open files, I think using
>> prlimit like `prlimit --nofile=8096:8096 --pid GUIX_DAEMON_PID` did the
>> trick, and that meant that I built the package sucessfully.
>>
>> I'm thinking now that there's a relationship between the number of cores
>> the tests are run with, and the required file descriptors. Also, I'm
>> pretty sure this behaviour changed when core-updates was merged.
>
> Indeed, Fibers uses ‘epoll’ and for that it consumes file descriptors
> proportionally to the number of threads, IIRC.  You’d still have to have
> a large number of threads to hit the default rlimit, but that’s not
> impossible.
>
>> I'll close this bug for now, as I've found a way to build the package.
>
> To avoid “random” build failures, perhaps we should include a hack in
> the ‘check’ phase, like calling ‘setrlimit’ right from there, WDYT?

If that's possible, it sounds like a good idea.


signature.asc
Description: PGP signature

bug#37822: guile-fibers build failure

[Christopher Baines]

Christopher Baines  writes:

> The guile-fibers package seems to fail to build on some machines.
>
> starting phase `check'
> make  check-am
> make[1]: Entering directory 
> '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
> make  check-TESTS
> make[2]: Entering directory 
> '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0'
> assert #f equal to #f: ok
> assert #t terminates: ok
> assert (false-if-exception (begin (run-fibers) #t)) equal to #f: ok
> assert terminates: (run-fibers (lambda () (sleep 1)) #:drain? #t): ok 
> (1.044672258 s)
> assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda () 
> #t #:drain? #t): ok (0.034571671 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda 
> () #t #:drain? #t): ok (0.05742899 s)
> assert terminates: (run-fibers (lambda () (do-times 100 (spawn-fiber (lambda 
> () #t #:drain? #t): ok (0.022090434 s)
> assert terminates: (run-fibers (lambda () (do-times 1000 (spawn-fiber (lambda 
> () #t #:drain? #t): ok (0.110914993 s)
> assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber 
> (lambda () #t #:drain? #t): ok (0.110751905 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber 
> (lambda () #t #:drain? #t): ok (0.747805854 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber 
> (lambda () #t) #:parallel? #t))) #:drain? #t): ok (1.116078927 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber 
> loop-to-1e4))) #:drain? #t): ok (396.536024374 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber 
> loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (67.471703208 s)
> assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda () 
> (sleep 1) #:drain? #t): ok (1.027788168 s)
> assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda 
> () (sleep 1) #:drain? #t): 
> /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: line 
> 5:  2
> 445 Aborted 
> top_srcdir="/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0" ./env 
> /gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile -s 
> ${dir}$tst
> FAIL: tests/basic.scm
>
>
> This is from milano-guix-1, which has 32 cores. I'm a bit confused as to
> what is actually causing the test to fail. I'm guessing it could be
> timing out, but I can't see anything looking at the time the test takes
> to run.

I've now tried running the tests using Guix immediately prior to the
recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf),
and immediately after the merge
(cf3d1763ede1a329c2bc932c84591ab594bb6c96) and the tests passed before,
and failed afterwards.

I've also tried running the tests manually, I did see a couple of times
a failure that mentioned about "Too many open files" [1].

I then attempted to raise the limit for open files, I think using
prlimit like `prlimit --nofile=8096:8096 --pid GUIX_DAEMON_PID` did the
trick, and that meant that I built the package sucessfully.

I'm thinking now that there's a relationship between the number of cores
the tests are run with, and the required file descriptors. Also, I'm
pretty sure this behaviour changed when core-updates was merged.

I'll close this bug for now, as I've found a way to build the package.


1:
make  check-TESTS
make[2]: Entering directory '/home/cbaines/fibers-1.0.0'
assert #f equal to #f: ok
assert #t terminates: ok
assert (false-if-exception (begin (run-fibers) #t)) equal to #f: ok
assert terminates: (run-fibers (lambda () (sleep 1)) #:drain? #t): ok 
(1.065373625 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda () 
#t #:drain? #t): ok (0.099213566 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda () 
#t #:drain? #t): ok (0.25544907 s)
assert terminates: (run-fibers (lambda () (do-times 100 (spawn-fiber (lambda () 
#t #:drain? #t): ok (0.072169616 s)
assert terminates: (run-fibers (lambda () (do-times 1000 (spawn-fiber (lambda 
() #t #:drain? #t): ok (0.02872572 s)
assert terminates: (run-fibers (lambda () (do-times 1 (spawn-fiber (lambda 
() #t #:drain? #t): ok (0.099789859 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda 
() #t #:drain? #t): ok (0.560994013 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber (lambda 
() #t) #:parallel? #t))) #:drain? #t): ok (0.913570257 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber 
loop-to-1e4))) #:drain? #t): ok (7.429164661 s)
assert terminates: (run-fibers (lambda () (do-times 10 (spawn-fiber 
loop-to-1e4 #:parallel? #t))) #:drain? #t): ok (1.135422681 s)
assert terminates: (run-fibers (lambda () (do

bug#39844: guix import hackage parallel-io failure

[Christopher Baines]

→ guix import hackage parallel-io
Syntax error: unexpected token : (buildable (False)) (at line 52, column 8)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package 'parallel-io'


I had a quick look at the importer, but a solution didn't immediately
present itself, so I'm filing a bug instead. I came across this when
attempting to package sizes, also from hackage.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#39531: guix pull on aarch64-linux glibc derivation has incorrect output

[Christopher Baines]

Hey,

When attempting to guix pull using the aarch64-linux system, I'm seeing
some issues with derivation outputs. I tried with a newer and older
commit, and the result is the same.


→ guix pull --commit=27b09f3ab11a30821a5ce0b071aac1bc6156497d 
--system=aarch64-linux --profile=/tmp/testprofile2
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.git   27b09f3
Computing Guix derivation for 'aarch64-linux'... -
guix pull: error: derivation 
`/gnu/store/800ky8qa4az7yx36gsg9ak6bih3530qm-glibc-2.29.drv' has incorrect 
output `/gnu/store/8v34v81q86klja9rihaixkypcml5ad5j-glibc-2.29-debug', should 
be `/gnu/store/w3iq60ias1qlrjigbj75ssda09hwg21i-glibc-2.29-debug'


→ guix pull --commit=4cb7c3d6a0e6ee50f8f9f54243402560b8908378 
--system=aarch64-linux --no-grafts --profile=/tmp/testprofile
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.git   4cb7c3d
Computing Guix derivation for 'aarch64-linux'... /
guix pull: error: derivation 
`/gnu/store/800ky8qa4az7yx36gsg9ak6bih3530qm-glibc-2.29.drv' has incorrect 
output `/gnu/store/8v34v81q86klja9rihaixkypcml5ad5j-glibc-2.29-debug', should 
be `/gnu/store/w3iq60ias1qlrjigbj75ssda09hwg21i-glibc-2.29-debug'


Thanks,

Chris


signature.asc
Description: PGP signature

bug#39615: LetsEncrypt root certificate hash changed

[Christopher Baines]

Tobias Geerinckx-Rice  writes:

> Christopher Baines 写道：
>> However, while this change might avoid the problem with guix pull in
>> the
>> future, I still a bit stuck. I got this from a fresh install of Guix
>> on
>> the Overdrive machine I have (aarch64-linux).
>
> I guess I've found my purpose this week and it's ‘mirroring old shit’.
>
> This is not at all a solution, but you can ‘guix download’ the old
> .pem files here[0] and hopefully be on your merry way.

Awesome, I've managed to download them and guix pull no longer fails
with that error which is great :)


signature.asc
Description: PGP signature

bug#39615: LetsEncrypt root certificate hash changed

[Christopher Baines]

~$ guix pull
building /gnu/store/1r2cj292vvjvhbb92bri568p7dia7cp1-isrgrootx1.pem.drv...
building 
/gnu/store/dhlb62lpf1ggcrax62hm7l7rlcf5c4fi-letsencryptauthorityx3.pem.drv...
downloading from https://letsencrypt.org/certs/isrgrootx1.pem...
-sha256 hash mismatch for 
/gnu/store/ahiiz5x04rqr214sw840ifz0d3jzmnsb-isrgrootx1.pem:
  expected hash: 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
  actual hash:   1la36n2f31j9s03v847ig6ny9lr875q3g7smnq33dcsmf2i5gd92
hash mismatch for store item 
'/gnu/store/ahiiz5x04rqr214sw840ifz0d3jzmnsb-isrgrootx1.pem'
build of /gnu/store/1r2cj292vvjvhbb92bri568p7dia7cp1-isrgrootx1.pem.drv failed
View build log at 
'/var/log/guix/drvs/1r/2cj292vvjvhbb92bri568p7dia7cp1-isrgrootx1.pem.drv.bz2'.
cannot build derivation 
`/gnu/store/lv78345x77bv6103l9ssqkx4l3v7z0xj-le-certs-0.drv': 1 dependencies 
couldn't be built
guix pull: error: build of 
`/gnu/store/lv78345x77bv6103l9ssqkx4l3v7z0xj-le-certs-0.drv' failed


signature.asc
Description: PGP signature

bug#38715: Issue with guile-email: unbound variable

[Christopher Baines]

Jelle Licht  writes:

> Arun Isaac  writes:
>
>>> My best guess is that this has something to do with a circular
>>> reference between guile modules, but I am not certain on how to easily
>>> debug (and fix) this.
>>
>> I updated the guile-email package two days ago. I hope that is not what
>> introduced this problem, and I don't see how it could have. Even `guix
>> build guile-email` on the terminal fails with a guile-email unbound
>> variable error.
>
> I do not think it was that commit, as I found the offending commit:
> c7b2b539802eaa3f969e212c98eb671a1a75e9f3
>
> This is the commit that adds mumimu to gnu/packages/mail.scm, as well as
> to the inputs of mumi. Reverting this commit (at least) solves the issue
> I had in the first mail.
>
> Could it be that the reference to guile-email in the version field of
> mumimu created this issue?
> --8<---cut here---start->8---
> (version (git-version (package-version guile-email) revision commit))
> --8<---cut here---end--->8---

I also spotted this. It looks to me sort of like a copy/paste error, I'm
not sure why this variant of mu would take the version of the
guile-email package.

Anyway, to work around this issue I've pushed [1], which just replaces
the reference with the current value.

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


signature.asc
Description: PGP signature

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

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> At some point, usually when extracting the information about lint
>> warnings, package derivations or system tests, the inferior guix repl
>> crashes.
>
> Could you come up with a simpler reproducer?  What do we need to send to
> the inferior to reach that crash?

I've attached a script that when run should reproduce the issue. I
extracted the code relating to lint warnings from the Guix Data
Service. The script attached runs this code twice against the inferior,
once will often be enough to cause it to crash, but twice should
reproduce it more reliably.

(use-modules (ice-9 match)
 (guix inferior)
 (guix channels)
 (guix store))

(define (all-inferior-lint-warnings inf store)
  (define locales
'("cs_CZ.utf8"
  "da_DK.utf8"
  "de_DE.utf8"
  "eo_EO.utf8"
  "es_ES.utf8"
  "fr_FR.utf8"
  "hu_HU.utf8"
  "pl_PL.utf8"
  "pt_BR.utf8"
  ;;"sr_SR.utf8"
  "sv_SE.utf8"
  "vi_VN.utf8"
  "zh_CN.utf8"))

  (define (lint-warnings-for-checker checker-name)
`(lambda (store)
   (let* ((checker (find (lambda (checker)
   (eq? (lint-checker-name checker)
',checker-name))
 %local-checkers))
  (check (lint-checker-check checker)))

 (define lint-checker-requires-store?-defined?
   (defined? 'lint-checker-requires-store?
 (resolve-module '(guix lint

 (define (process-lint-warning lint-warning)
   (list
(match (lint-warning-location lint-warning)
  (($  file line column)
   (list (if (string-prefix? "/gnu/store/" file)
 ;; Convert a string like
 ;; 
/gnu/store/53xh0mpigin2rffg31s52x5dc08y0qmr-guix-module-union/share/guile/site/2.2/gnu/packages/xdisorg.scm
 ;;
 ;; This happens when the checker uses
 ;; package-field-location.
 (string-join (drop (string-split file #\/) 8) "/")
 file)
 line
 column)))
(let* ((source-locale "en_US.utf8")
   (source-message
(begin
  (setlocale LC_MESSAGES source-locale)
  (lint-warning-message lint-warning)))
   (messages-by-locale
(filter-map
 (lambda (locale)
   (catch 'system-error
 (lambda ()
   (setlocale LC_MESSAGES locale))
 (lambda (key . args)
   (error
(simple-format
 #f
 "error changing locale to ~A: ~A ~A"
 locale key args
   (let ((message
  (lint-warning-message lint-warning)))
 (setlocale LC_MESSAGES source-locale)
 (if (string=? message source-message)
 #f
 (cons locale message
 (list ,@locales
  (cons (cons source-locale source-message)
messages-by-locale

 (filter
  (match-lambda
((package-id . warnings)
 (not (null? warnings)))
(a
 (error (simple-format #f "NO MATCH FOR ~A\n" a
  (hash-map->list
   (lambda (package-id package)
 (cons
  package-id
  (catch
#t
(lambda ()
  (map process-lint-warning
   (if (and lint-checker-requires-store?-defined?
(lint-checker-requires-store? checker))

   (check package #:store store)
   (check package
(lambda (key . args)
  '()
   %package-table)

  (inferior-eval '(use-modules (srfi srfi-1)
   (guix lint)) inf)
  (inferior-packages inf)
  (let ((checkers
 (inferior-eval
  '(begin
 (map (lambda (checker)
(list (lint-checker-name checker)
  (lint-checker-description checker)
  (if (memq checker %network-dependent-checkers)
  #t
  #f)))
  %all-checkers))
  inf)))
(map
 (

bug#40528: 'guix lint' does not check whether propagated-inputs should be native

[Christopher Baines]

Efraim Flashner  writes:

> On Thu, Apr 09, 2020 at 11:42:18PM +0200, Marius Bakke wrote:
>> Efraim Flashner  writes:
>>
>> > On Thu, Apr 09, 2020 at 11:24:25PM +0200, Marius Bakke wrote:
>> >> 'guix lint -c inputs-should-be-native' only checks the 'inputs' field of
>> >> a package, not propagated-inputs.
>> >
>> > The attached patch should add the propagated inputs to the list of
>> > inputs to check. Do we want to start telling it to ignore some of them?
>>
>> Wow, that was incredibly fast!
>>
>> > gnu/packages/check.scm:2200:2: python-nose-timer@0.7.5: 'python-nose' 
>> > should probably be a native input
>>
>> I'm inclined to leave it.  I think many of these plugin packages should
>> not be propagating the package that they plug into anyway.
>>
>> LGTM!
>
> OK, patch pushed.

Looks like it's working :) [1]

1: 
http://data.guix.gnu.org/compare?base_commit=960abd585940c33744040c79e2a37e588d36e589_commit=d95252baf97adb261dd823d4e7a74a7522815c1c


signature.asc
Description: PGP signature

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

[Christopher Baines]

Ludovic Courtès  writes:

> Glad you manage to get more info.
>
> 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.

I've sent a patch which I think does this now [1]. Assuming I've done
the right thing, is this something that can be merged in to core-updates
Marius?

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

I've tested the patch by running:

  ./pre-inst-env guile build-aux/compile-as-derivation.scm "$PWD"

Then taking the Guix I get, and trying the script to reproduce the issue
through the guix repl, and it seems to work.


signature.asc
Description: PGP signature

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

[Christopher Baines]

Ludovic Courtès  writes:

> Hi Christopher,
>
> Christopher Baines  skribis:
>
>> I've attached a script that when run should reproduce the issue. I
>> extracted the code relating to lint warnings from the Guix Data
>> Service. The script attached runs this code twice against the inferior,
>> once will often be enough to cause it to crash, but twice should
>> reproduce it more reliably.
>
> Thanks a lot.
>
> Here’s a backtrace from the core dumped by the inferior:

...

> It could be an unbounded growth of libgc’s finalizer table or our weak
> tables as we experienced in <https://bugs.gnu.org/28590>.
>
> We should be able to reproduce it with something like:
>
>   guix time-machine --commit=d523eb5c9c2659cbbaf4eeef3691234ae527ee6a -- \
> lint -c 
> inputs-should-be-native,license,mirror-url,source-file-name,source-unstable-tarball,derivation,patch-file-names,formatting,synopsis
>
> In top one can see that heap usage keeps growing, which may well be a
> bug in Guix proper rather than in Guile… but it doesn’t crash.
>
> I would propose three actions here:
>
>   1. Run linters un ‘gcprof’ to see what’s eating memory and hopefully
>  find and address the leak.  As a start, maybe just start reducing
>  the list of checkers to see if there’s one of them that’s causing
>  it.
>
>  The ‘derivation’ checker is definitely responsible for a lot of the
>  heap consumption because of the various caches in (guix packages) &
>  co.  Perhaps add calls to ‘invalidate-derivation-caches!’ as in
>  (gnu ci).
>
>   2. Work around the problem in Guix Data Service by running, say, one
>  inferior per checker instead of one inferior for all checkers for
>  all packages.
>
>   3. If #1 didn’t help, let’s see if we can isolate a Guile weak-table
>  bug or something like that.
>
> Thoughts?

Thanks, that's useful to know.

I think I've now managed to find a way of reproducing this without the
inferior getting in the way. I was testing if triggering garbage
collection in Guile would help avoid the problem, but actually it seems
to cause it. I guess given the mentions of GC in the above stacktrace,
and the major version change of libgc, some GC related bug seems quite
likely here.

I've been testing with a checkout of Guix built with Guix from the
core-updates branch. I think that provides the same broken Guile that
the guix repl is using.

When trying to just use a checkout of the core-updates branch, and guile
built from that branch I get the following odd error:

→ ./pre-inst-env 
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile 
./reproduce-core-updates-mmap-PROT_NONE-failed.scm
guile: warning: failed to install locale
warning: failed to load '(gnu packages abiword)': Function not implemented
error: git-fetch: unbound variable
hint: Did you forget `(use-modules (guix git-download))'?

error: git-version: unbound variable



No idea what's happening there, but when I ./configure and make with
packages from core-updates, I seem to end up with a setup that works:

This is the guile I'm using: 
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile

If you just run the script, you should see:

→ ./pre-inst-env guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm

;;; ("%package-table-setup" #)
mmap(PROT_NONE) failed
Aborted


For more information, you can pipe the script to the REPL. What you
should see is that it's slow to compute the lint warnings the first
time, but the subsequent times are quick, and it crashes in one of the
(gc) calls.

I'm going to try and continue looking in to this, at least it'll be
easier to delve in to guile now that I can directly control what guile
is used.

Thanks,

Chris

(use-modules (srfi srfi-1)
 (ice-9 match)
 (gnu packages)
 (guix store)
 (guix grafts)
 (guix packages)
 (guix lint)
 (guix utils))

(define %package-table (make-hash-table))
(begin
  (fold-packages (lambda (package result)
   (let ((id (object-address package)))
 (hashv-set! %package-table id package)
 (cons (list (package-name package)
 (package-version package)
 id)
   result)))
 '())
  (peek "%package-table-setup" %package-table))

(define lint-warnings-for-checker
  (lambda (checker-name store)
(let* ((checker (find (lambda (checker)
(eq? (lint-checker-name checker)
 checker-name))
  %local-checkers))
   (check (lint-checker-check checker)))

  (define (process-lint-warning lint-warning)
(list
 (match (lint-warning-l

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

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Hi Christopher,
>>
>> Christopher Baines  skribis:
>>
>>> I've attached a script that when run should reproduce the issue. I
>>> extracted the code relating to lint warnings from the Guix Data
>>> Service. The script attached runs this code twice against the inferior,
>>> once will often be enough to cause it to crash, but twice should
>>> reproduce it more reliably.
>>
>> Thanks a lot.
>>
>> Here’s a backtrace from the core dumped by the inferior:
>
> ...
>
>> It could be an unbounded growth of libgc’s finalizer table or our weak
>> tables as we experienced in <https://bugs.gnu.org/28590>.
>>
>> We should be able to reproduce it with something like:
>>
>>   guix time-machine --commit=d523eb5c9c2659cbbaf4eeef3691234ae527ee6a -- \
>> lint -c 
>> inputs-should-be-native,license,mirror-url,source-file-name,source-unstable-tarball,derivation,patch-file-names,formatting,synopsis
>>
>> In top one can see that heap usage keeps growing, which may well be a
>> bug in Guix proper rather than in Guile… but it doesn’t crash.
>>
>> I would propose three actions here:
>>
>>   1. Run linters un ‘gcprof’ to see what’s eating memory and hopefully
>>  find and address the leak.  As a start, maybe just start reducing
>>  the list of checkers to see if there’s one of them that’s causing
>>  it.
>>
>>  The ‘derivation’ checker is definitely responsible for a lot of the
>>  heap consumption because of the various caches in (guix packages) &
>>  co.  Perhaps add calls to ‘invalidate-derivation-caches!’ as in
>>  (gnu ci).
>>
>>   2. Work around the problem in Guix Data Service by running, say, one
>>  inferior per checker instead of one inferior for all checkers for
>>  all packages.
>>
>>   3. If #1 didn’t help, let’s see if we can isolate a Guile weak-table
>>  bug or something like that.
>>
>> Thoughts?
>
> Thanks, that's useful to know.
>
> I think I've now managed to find a way of reproducing this without the
> inferior getting in the way. I was testing if triggering garbage
> collection in Guile would help avoid the problem, but actually it seems
> to cause it. I guess given the mentions of GC in the above stacktrace,
> and the major version change of libgc, some GC related bug seems quite
> likely here.
>
> I've been testing with a checkout of Guix built with Guix from the
> core-updates branch. I think that provides the same broken Guile that
> the guix repl is using.
>
> When trying to just use a checkout of the core-updates branch, and guile
> built from that branch I get the following odd error:
>
> → ./pre-inst-env 
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile 
> ./reproduce-core-updates-mmap-PROT_NONE-failed.scm
> guile: warning: failed to install locale
> warning: failed to load '(gnu packages abiword)': Function not implemented
> error: git-fetch: unbound variable
> hint: Did you forget `(use-modules (guix git-download))'?
>
> error: git-version: unbound variable
>
>
>
> No idea what's happening there, but when I ./configure and make with
> packages from core-updates, I seem to end up with a setup that works:
>
> This is the guile I'm using: 
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile
>
> If you just run the script, you should see:
>
> → ./pre-inst-env guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm
>
> ;;; ("%package-table-setup" #)
> mmap(PROT_NONE) failed
> Aborted
>
>
> For more information, you can pipe the script to the REPL. What you
> should see is that it's slow to compute the lint warnings the first
> time, but the subsequent times are quick, and it crashes in one of the
> (gc) calls.
>
> I'm going to try and continue looking in to this, at least it'll be
> easier to delve in to guile now that I can directly control what guile
> is used.

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.

Would it be feasible to keep guile, or at least the guile Guix uses with
libgc@7 for now?


signature.asc
Description: PGP signature

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

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Glad you manage to get more info.
>>
>> 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.
>
> I've sent a patch which I think does this now [1]. Assuming I've done
> the right thing, is this something that can be merged in to core-updates
> Marius?
>
> 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684
>
> I've tested the patch by running:
>
>   ./pre-inst-env guile build-aux/compile-as-derivation.scm "$PWD"
>
> Then taking the Guix I get, and trying the script to reproduce the issue
> through the guix repl, and it seems to work.

I've merged the fix [1] in now, and it looks to have worked [2].

1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40684
2: 
https://guix-patches-data.cbaines.net/revision/cef392f3936922b7b0b74bd59be67e660c10db67

Thanks for your help in resolving this Ludo!


signature.asc
Description: PGP signature

bug#40488: Finance packages broken in recent Guix: error: beancount: unbound variable

[Christopher Baines]

→ guix describe
Generation 181  Apr 07 2020 16:55:29(current)
  guix 1e96e6a
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1e96e6ac8bc0285cc2adfac4ac29b538b84d5dfc

→ guix build ledger
Backtrace:
   1 (primitive-load "/home/chris/.config/guix/current/bin/g…")
In guix/ui.scm:
  1936:12  0 (run-guix-command _ . _)

guix/ui.scm:1936:12: In procedure run-guix-command:
error: beancount: unbound variable


I believe this issue was probalby present since [1] and [2] were merged,
around ~5 days ago.

1: 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=f1f724841a6b610e162d36d08225094317ebaf09
2: 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=abcac7a52932bdf66c333659679b0a5e6169e34c

Similar commands seem to work in a Git checkout, so I'm not sure what's
goig wrong here.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#40488: Finance packages broken in recent Guix: error: beancount: unbound variable

[Christopher Baines]

Marius Bakke  writes:

> Christopher Baines  writes:
>
>> → guix describe
>> Generation 181   Apr 07 2020 16:55:29(current)
>>   guix 1e96e6a
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit: 1e96e6ac8bc0285cc2adfac4ac29b538b84d5dfc
>>
>> → guix build ledger
>> Backtrace:
>>1 (primitive-load "/home/chris/.config/guix/current/bin/g…")
>> In guix/ui.scm:
>>   1936:12  0 (run-guix-command _ . _)
>>
>> guix/ui.scm:1936:12: In procedure run-guix-command:
>> error: beancount: unbound variable
>
> This is because of cross-module inheritance, which is not safe because
> 'beancount' may not be evaluated by the time 'emacs-beancount' is.
>
> Fixed in 805d70214a1b22da70a7545cb1eb49bb5d7484d8, thanks!

Great, thanks Marius :)


signature.asc
Description: PGP signature

bug#40729: Two rottlog servives causes cryptic etc drv failure

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> I got this error when reconfiguring with a recent revision of Guix.
>>
>>
>> /builder for `/gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv' failed 
>> with exit code 1
>> build of /gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv failed
>> View build log at 
>> '/var/log/guix/drvs/kb/hl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv.bz2'.
>> building /gnu/store/59bd67s06inr5vzyxc70yk6garj2aciz-linux-modules.drv...
>> cannot build derivation 
>> `/gnu/store/n45vq7jbhn5qz24qlgv6a6ginarqs433-system.drv': 1 dependencies 
>> couldn't be built
>> guix system: error: build of 
>> `/gnu/store/n45vq7jbhn5qz24qlgv6a6ginarqs433-system.drv' failed
>> chris@guix-hetzner-1 ~$ bzcat 
>> /var/log/guix/drvs/kb/hl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv.bz2
>> Backtrace:
>>1 (primitive-load "/gnu/store/g4q88pmwr1vy54qpnkz878k3n7f?")
>>0 (symlink "/gnu/store/939n705vmkn8613b8gjc10llvsr5jcwc-?" ?)
>>
>> ERROR: In procedure symlink:
>> In procedure symlink: File exists
>
> Yeah that’s something I noticed here:
>
>   https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00032.html
>
> Commit a322e9d16b227484ce04721fee0f99618cb1007e does that.
>
> The result is not optimal yet because it just says “duplicate entries”.
> Ideally we’d be able to show a ‘fold-services’ trace of sorts telling
> showing where the faulty entries come from.

Awesome, that'll be useful for sure :)

Thanks,

Chris


signature.asc
Description: PGP signature

bug#40729: Two rottlog servives causes cryptic etc drv failure

[Christopher Baines]

I got this error when reconfiguring with a recent revision of Guix.


/builder for `/gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv' failed with 
exit code 1
build of /gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv failed
View build log at 
'/var/log/guix/drvs/kb/hl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv.bz2'.
building /gnu/store/59bd67s06inr5vzyxc70yk6garj2aciz-linux-modules.drv...
cannot build derivation 
`/gnu/store/n45vq7jbhn5qz24qlgv6a6ginarqs433-system.drv': 1 dependencies 
couldn't be built
guix system: error: build of 
`/gnu/store/n45vq7jbhn5qz24qlgv6a6ginarqs433-system.drv' failed
chris@guix-hetzner-1 ~$ bzcat 
/var/log/guix/drvs/kb/hl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv.bz2
Backtrace:
   1 (primitive-load "/gnu/store/g4q88pmwr1vy54qpnkz878k3n7f?")
   0 (symlink "/gnu/store/939n705vmkn8613b8gjc10llvsr5jcwc-?" ?)

ERROR: In procedure symlink:
In procedure symlink: File exists



Moving the rottlog-configuration to modify-services for %base-services
resolved this I believe, but that was a guess based on memory. Even if
the system definition is invalid, I don't think here should be where it
fails.


signature.asc
Description: PGP signature

bug#39531: guix pull on aarch64-linux glibc derivation has incorrect output

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> When attempting to guix pull using the aarch64-linux system, I'm seeing
>> some issues with derivation outputs. I tried with a newer and older
>> commit, and the result is the same.
>>
>>
>> → guix pull --commit=27b09f3ab11a30821a5ce0b071aac1bc6156497d 
>> --system=aarch64-linux --profile=/tmp/testprofile2
>> 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.git27b09f3
>> Computing Guix derivation for 'aarch64-linux'... -
>> guix pull: error: derivation 
>> `/gnu/store/800ky8qa4az7yx36gsg9ak6bih3530qm-glibc-2.29.drv' has incorrect 
>> output `/gnu/store/8v34v81q86klja9rihaixkypcml5ad5j-glibc-2.29-debug', 
>> should be `/gnu/store/w3iq60ias1qlrjigbj75ssda09hwg21i-glibc-2.29-debug'
>
> The problem here is that we’re building the trampoline,
> “compute-guix-derivation”, for AArch64.  It builds if substitutes are
> available (likely) and fails to build otherwise.  And then we try to
> execute it locally, and since your machine is not AArch64, it fails.
>
> The first patch attached does what I thought was all it would take to
> fix it.  But then I realized that the second patch is needed so that
> ‘make-config.scm’ uses a Guile for the right system, same for
> “module-import.drv” and so on.
>
> Together, these two patches solve the problem (not retroactively
> though), but we need to check the implications of changing the default
> value of #:guile-for-build.

Hey,

Thanks for investigating :) I completely forget why I encountered this,
but it was probably around getting the channel instance derivations in
to the Guix Data Service, but I think I got that working, so I guess I
somehow avoided this issue.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#40315: Graft segmentation faults

[Christopher Baines]

Hey,

With recent Guix revisions ([3] for example) I've had some apparently
random segmentation faults with grafts. I've encountered this on two
machines, both times it appears not to happen repeatably, as re-running
the graft can work. I encountered this when running guix package -u, and
running it again eventually worked.

One of the logs mentioned not being able to allocate memory. The machine
this was running on has 16GB of RAM, plus 16GB of swap, and most of the
memory was free, so I think using all of this is unlikely.



1:
/builder for `/gnu/store/0m25akb320nm8w1mwlfm4c61jqd7m3sq-java-swt-4.7.1a.drv' 
failed due to signal 11 (Segmentation fault)
build of /gnu/store/0m25akb320nm8w1mwlfm4c61jqd7m3sq-java-swt-4.7.1a.drv failed
View build log at 
'/var/log/guix/drvs/0m/25akb320nm8w1mwlfm4c61jqd7m3sq-java-swt-4.7.1a.drv.bz2'.

→ bzcat 
/var/log/guix/drvs/0m/25akb320nm8w1mwlfm4c61jqd7m3sq-java-swt-4.7.1a.drv.bz2
grafting '/gnu/store/bzqzjzgwk2vh06skh51hwfxad1g4wgzz-java-swt-4.7.1a' -> 
'/gnu/store/3ms7y6p4m67ff8i7gm5pda6zgjds4f82-java-swt-4.7.1a'...
madvise failed: Cannot allocate memory


2:
-builder for `/gnu/store/kgp8kxair912nvk500y4c9ckhw91njlg-orcus-0.15.3.drv' 
failed due to signal 11 (Segmentation fault)
build of /gnu/store/kgp8kxair912nvk500y4c9ckhw91njlg-orcus-0.15.3.drv
failed

3:
→ guix describe
Generation 102  Mar 28 2020 21:48:51(current)
  guix 735a8d9
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 735a8d997a92518d7d19926e1c8a1e385a98fdce


signature.asc
Description: PGP signature

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

[Christopher Baines]

Noticed this when testing guix system build with core-updates. Here's a
small example which reproduces the issue:


(use-modules (guix channels)
 (guix inferior))

(define channels
  (list (channel
 (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git;)
 (commit
  "e02c2f85b36ce1c733bd908a210ce1182bdd2560"

(define inferior
  (inferior-for-channels channels))

(first (lookup-inferior-packages inferior "linux-libre" "5.2.21"))


If you save that as a file then attempt to build it:


→ guix build -f test.scm 
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Backtrace:
   4 (primitive-load "/gnu/store/8mv5bpjgxg9c369xnbb5rf1kv9r?")
In ice-9/eval.scm:
619:8  3 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
   182:19  2 (proc #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
   142:16  1 (compile-top-call # ?)
In unknown file:
   0 (%resolve-variable (7 . call-with-new-thread) #)

ERROR: In procedure %resolve-variable:
Unbound variable: call-with-new-thread
guix build: error: You found a bug: the program 
'/gnu/store/8mv5bpjgxg9c369xnbb5rf1kv9r6z5hw-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"e02c2f85b36ce1c733bd908a210ce1182bdd2560"; system: "x86_64-linux";
host version: "a8cb1e72ef351330d1521833c1b270dcc0da593f"; pull-version: 1).
Please report it by email to .


signature.asc
Description: PGP signature

bug#37207: guix.gnu.org returns Last-Modified = Epoch

[Christopher Baines]

Ludovic Courtès  writes:

> Since the use of the ‘static-web-site’ service, which puts web site
> files in the store, nginx returns a ‘Last-Modified’ header that can
> trick clients into caching things forever:
>
> --8<---cut here---start->8---
> $ wget --debug -O /dev/null   https://guix.gnu.org/packages.json 2>&1 | grep 
> Last
> Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
> --8<---cut here---end--->8---
>
> We should tell nginx to do not emit ‘Last-Modified’, or to take the
> state from the /srv/guix.gnu.org symlink, if possible.

I ended up looking at this again in relation to Repology [1].

1: 
https://github.com/repology/repology-updater/issues/218#issuecomment-525905704

Going back to that comment, given that the Last-Modified header (and the
ETag) is wrong, it's probably sensible to remove them. That might even
fix the issue with Repology fetching the packages.json file.

Alternatively (or in addition), we could run a really simple Guile web
server that just serves the packages.json file with the right
Last-Modified value, and have NGinx proxy requests to that server. This
would be pretty easy to setup I believe, and would allow providing a
correct value.

Thoughts?

Chris


signature.asc
Description: PGP signature

bug#37207: guix.gnu.org returns Last-Modified = Epoch

[Christopher Baines]

Ludovic Courtès  writes:

> Howdy!
>
> Christopher Baines  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Since the use of the ‘static-web-site’ service, which puts web site
>>> files in the store, nginx returns a ‘Last-Modified’ header that can
>>> trick clients into caching things forever:
>>>
>>> --8<---cut here---start->8---
>>> $ wget --debug -O /dev/null   https://guix.gnu.org/packages.json 2>&1 | 
>>> grep Last
>>> Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
>>> --8<---cut here---end--->8---
>>>
>>> We should tell nginx to do not emit ‘Last-Modified’, or to take the
>>> state from the /srv/guix.gnu.org symlink, if possible.
>>
>> I ended up looking at this again in relation to Repology [1].
>>
>> 1: 
>> https://github.com/repology/repology-updater/issues/218#issuecomment-525905704
>>
>> Going back to that comment, given that the Last-Modified header (and the
>> ETag) is wrong, it's probably sensible to remove them. That might even
>> fix the issue with Repology fetching the packages.json file.
>>
>> Alternatively (or in addition), we could run a really simple Guile web
>> server that just serves the packages.json file with the right
>> Last-Modified value, and have NGinx proxy requests to that server. This
>> would be pretty easy to setup I believe, and would allow providing a
>> correct value.
>>
>> Thoughts?
>
> I think it wouldn’t really help because the Last-Modified issue is
> pervasive.  It shows for instance when accessing the web site: one often
> has to force the browser to reload pages to get the latest version.
>
> So I’m all for one of the solutions that were proposed earlier.
>
> WDYT?

So I think removing the Last-Modified header from the responses will fix
the issue with the Repology fetcher (as it will stop thinking it's
already fetch the file, since it was last modified in 1970), instead it
will just always process the file.

Removing the Last-Modified header, and maybe the ETag as well from
responses should avoid the issue with web browsers using a cached
version of the page when they probably shouldn't.

I realise what I described with using a Guile web server to serve the
packages.json file wouldn't help with other pages (unless they're served
as well, which is a possibility), but that was just an optimisation over
removing the header entirely, as having the Last-Modified header, with a
correct value would help the Repology fetcher cache the file.

Does that make sense? It still seems to me that a small change to the
NGinx config (I think these lines somewhere in the config would do it
[1]) would help with the Repology fetcher issue, and the issue you
describe with web browsers.

1:

add_header Last-Modified "";
if_modified_since off;
etag off;


signature.asc
Description: PGP signature

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

[Christopher Baines]

Marius Bakke  writes:

> Christopher Baines  writes:
>
>> Ludovic Courtès  writes:
>>
>>> Ludovic Courtès  skribis:
>>>
>>>> The attached patches add a mechanism to patch the Guix source tree, and
>>>> then use that mechanism to add the missing (ice-9 threads) import.  With
>>>> this I can do:
>>>>
>>>>   ./pre-inst-env guix time-machine \
>>>>  --commit=e02c2f85b36ce1c733bd908a210ce1182bdd2560 -- build linux-libre
>>>>
>>>> … which is a simple way to do what the manifest above was about.
>>>
>>> Given the enthusiasm expressed on IRC, I went ahead and pushed.  :-)
>>>
>>>   ff3ca7979e channels: Add patch for <https://bugs.gnu.org/41028>.
>>>   053b10c3ef channels: Add mechanism to patch checkouts of the 'guix 
>>> channel.
>>>   4ba425060a channels: Add 'latest-channel-instance'.
>>>
>>> So… it might be that today is merge day?
>>
>> Wonderful :) I've had a chance to try this out now, and it works. I was
>> able to reconfigure my system.
>>
>> One even more niche issue is that because I'm using this channel in my
>> system configuration, the patching happens as root, but it's the cached
>> channel in my users home directory that's patched. This means that
>> build-self.scm becomes owned by root.
>>
>> I noticed this when I went to pull:
>>
>>   → guix pull --branch=core-updates
>>   Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>>   guix pull: error: Git error: could not open 
>> '/home/chris/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/build-aux/build-self.scm'
>>  for writing: Permission denied
>>
>>
>> I'm not sure what the neat way of addressing this is, but maybe the file
>> ownership can be recorded prior to patching, and reset afterwards if
>> it's changed.
>
> I took a stab at exactly this:

Awesome, thanks. I haven't tried it, but it looks good :)


signature.asc
Description: PGP signature

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

[Christopher Baines]

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> The attached patches add a mechanism to patch the Guix source tree, and
>> then use that mechanism to add the missing (ice-9 threads) import.  With
>> this I can do:
>>
>>   ./pre-inst-env guix time-machine \
>>  --commit=e02c2f85b36ce1c733bd908a210ce1182bdd2560 -- build linux-libre
>>
>> … which is a simple way to do what the manifest above was about.
>
> Given the enthusiasm expressed on IRC, I went ahead and pushed.  :-)
>
>   ff3ca7979e channels: Add patch for .
>   053b10c3ef channels: Add mechanism to patch checkouts of the 'guix channel.
>   4ba425060a channels: Add 'latest-channel-instance'.
>
> So… it might be that today is merge day?

Wonderful :) I've had a chance to try this out now, and it works. I was
able to reconfigure my system.

One even more niche issue is that because I'm using this channel in my
system configuration, the patching happens as root, but it's the cached
channel in my users home directory that's patched. This means that
build-self.scm becomes owned by root.

I noticed this when I went to pull:

  → guix pull --branch=core-updates
  Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
  guix pull: error: Git error: could not open 
'/home/chris/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/build-aux/build-self.scm'
 for writing: Permission denied


I'm not sure what the neat way of addressing this is, but maybe the file
ownership can be recorded prior to patching, and reset afterwards if
it's changed.

Thanks again for looking at the original issue Ludo,

Chris


signature.asc
Description: PGP signature

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

[Christopher Baines]

Maxim Cournoyer  writes:

> Hello,
>
> Christopher Baines  writes:
>
>> 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.
>
> [...]
>
> This issue is now resolved as of commit
> 12df6684b983507b2a73e14f45d28a71cddfb3b1 on master.

Thanks Maxim, I'm guessing the commit that fixes this is
b460ba7992a0b4af2ddb5927dcf062784539ef7b.

Chris


signature.asc
Description: PGP signature

bug#41485: opensmtpd 6.7: sendmail: this program must be setgid smtpq

[Christopher Baines]

I noticed I could no longer send email recently. This is the behaviour
when I try to run sendmail from and older opensmtpd (this output
suggests it works):

→ /gnu/store/6843f93hfr54ds5zzl7ik3h5njgicy0w-opensmtpd-6.6.4p1/sbin/sendmail -h
sendmail: illegal option -- h
usage: sendmail [-tv] [-f from] [-F name] to ...


However with a more recent version, it doesn't work:

→ /gnu/store/j1mf5gdzf9i1r6sv4nl0yisk2nswzdfz-opensmtpd-6.7.1p1/sbin/sendmail -h
sendmail: this program must be setgid smtpq


Any ideas?


signature.asc
Description: PGP signature

bug#40966: Missing substitutes on ci.guix.gnu.org?

[Christopher Baines]

Leo Famulari  writes:

> I've noticed that certain packages never seem to have substitutes
> available from ci.guix.gnu.org.
>
> This is not about packages that consistently fail to build, like Vigra
> (LibreOffice) [0], but packages that never seem to be attempted at all,
> and are not found when searching on the CI results.
>
> For example, ncmpcpp has not been built since February 2020:
>
> https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+ncmpcpp

For getting data in to the Guix Data Service, I added a way of fetching
the Cuirass build for an ouptut, [1] for example.

1: https://ci.guix.gnu.org/output/a4dfa081zsmfkbcfphcr5glzgxh3n81l-ncmpcpp-0.8.2

The Guix Data Service gathers up the builds, and displays them. This is
a useful page when looking at if a package has been built:

https://data.guix.gnu.org/repository/1/branch/master/package/ncmpcpp/output-history

> And Borg has apparently never been built:
>
> https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+borg

Here's the similar link for borg:

http://data.guix.gnu.org/repository/1/branch/master/package/borg/output-history


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#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#37207: guix.gnu.org returns Last-Modified = Epoch

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> So I think removing the Last-Modified header from the responses will fix
>> the issue with the Repology fetcher (as it will stop thinking it's
>> already fetch the file, since it was last modified in 1970), instead it
>> will just always process the file.
>>
>> Removing the Last-Modified header, and maybe the ETag as well from
>> responses should avoid the issue with web browsers using a cached
>> version of the page when they probably shouldn't.
>
> It would prevent client-side caching altogether.  So perhaps we can do
> that as a stopgap (and it has the advantage of requiring only a tiny
> config change).

Great, I've finally got around to sending a patch for this now.


signature.asc
Description: PGP signature

bug#37207: [PATCH] nginx: berlin: Work around Last-Modified issues for guix.gnu.org.

[Christopher Baines]

* hydra/nginx/berlin.scm (%berlin-servers): Add some config to the
nginx-server-configurations for guix.gnu.org.
---
 hydra/nginx/berlin.scm | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 303fd35..8c90eb1 100644
--- a/hydra/nginx/berlin.scm
+++ b/hydra/nginx/berlin.scm
@@ -514,6 +514,13 @@ PUBLISH-URL."
 (locations guix.gnu.org-locations)
 (raw-content
  (list
+  ;; TODO This works around NGinx using the epoch for the
+  ;; Last-Modified date, as well as the etag.
+  ;; See http://issues.guix.info/issue/37207
+  "add_header Last-Modified \"\";"
+  "if_modified_since off;"
+  "etag off;"
+
   "access_log /var/log/nginx/guix-info.access.log;")))
 
(nginx-server-configuration
@@ -634,6 +641,13 @@ PUBLISH-URL."
  (append
   %tls-settings
   (list
+   ;; TODO This works around NGinx using the epoch for the
+   ;; Last-Modified date, as well as the etag.
+   ;; See http://issues.guix.info/issue/37207
+   "add_header Last-Modified \"\";"
+   "if_modified_since off;"
+   "etag off;"
+
"access_log /var/log/nginx/guix-gnu-org.https.access.log;"
 
(nginx-server-configuration
-- 
2.26.2

bug#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#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#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#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#41708: "guix weather" : 504 error

[Christopher Baines]

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 :)


signature.asc
Description: PGP signature

bug#41708: "guix weather" : 504 error

[Christopher Baines]

zimoun  writes:

> Hi Chris,
>
> On Sat, 13 Jun 2020 at 17:23, Christopher Baines  wrote:
>
>> I've now deployed the change to Bayfront, let me know if you see a
>> difference? :)
>
> Yes! :-)
>
> --8<---cut here---start->8---
> $ guix weather guix --substitute-urls='https://ci.guix.gnu.org 
> https://bayfront.guix.gnu.org'
> computing 1 package derivations for x86_64-linux...
>
> looking for 1 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org
>   100.0% substitutes available (1 out of 1)
>   at least 106.4 MiB of nars (compressed)
>   278.7 MiB on disk (uncompressed)
>   0.002 seconds per request (0.0 seconds in total)
>   543.8 requests per second
>   'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway 
> Time-out")
>
> looking for 1 store items on https://bayfront.guix.gnu.org...
> https://bayfront.guix.gnu.org
>   100.0% substitutes available (1 out of 1)
>   at least 106.3 MiB of nars (compressed)
>   278.6 MiB on disk (uncompressed)
>   0.001 seconds per request (0.0 seconds in total)
>   791.8 requests per second
>
>   at least 1,000 queued builds
>   x86_64-linux: 1000 (100.0%)
>   build rate: 9.22 builds per hour
>   x86_64-linux: 9.22 builds per hour
> --8<---cut here---end--->8---
>
> I will try a couple more of queries.  But I propose to push the patch on
> Berlin too.  WDYT?

I believe it's been deployed now. It was working earlier today at least,
however all of Cuirass seems to be stuck now.


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#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#41757: soundconverter doesn't work when grafted

[Christopher Baines]

Hey,

So I was having problems with soundconverter, and I noticed that if I
avoid grafts, it works. I'm not sure if there's an issue with the
grafting, or what's being grafted.


→ guix build soundconverter
/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2

→ 
/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2/bin/soundconverter
 
  faac gstreamer element not found
SoundConverter 3.0.2
/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2/lib/soundconverter/python/soundconverter/ui.py:1465:
 Warning: g_value_type_transformable: assertion 'src_type' failed
  builder.add_from_file(gladefile)

(SoundConverter:15974): Gtk-WARNING **: 21:23:20.952: gtkliststore.c:836: 
Unable to convert from (null) to gchararray
Traceback (most recent call last):
  File 
"/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2/bin/..soundconverter-real-real",
 line 221, in 
gui_main(NAME, VERSION, GLADEFILE, files)
  File 
"/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2/lib/soundconverter/python/soundconverter/ui.py",
 line 1468, in gui_main
win = SoundConverterWindow(builder)
  File 
"/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2/lib/soundconverter/python/soundconverter/ui.py",
 line 1082, in __init__
self.prefs = PreferencesDialog(builder, self.widget)
  File 
"/gnu/store/cyf72nqq2c0fbh145wc6jj3f2zssjx1n-soundconverter-3.0.2/lib/soundconverter/python/soundconverter/ui.py",
 line 459, in __init__
self.settings = Gio.Settings('org.soundconverter')
  File 
"/gnu/store/426zzzvb53ydf6l7rhvfwl30kmx1b0sm-python-pygobject-3.34.0/lib/python3.8/site-packages/gi/overrides/__init__.py",
 line 319, in new_init
return super_init_func(self, **new_kwargs)
TypeError: gobject `GSettings' doesn't support property `schema'



→ guix build --no-grafts soundconverter
/gnu/store/jic3i199783dk2wm58rcq53lmrpslcwd-soundconverter-3.0.2

→ 
/gnu/store/jic3i199783dk2wm58rcq53lmrpslcwd-soundconverter-3.0.2/bin/soundconverter
 
  faac gstreamer element not found
SoundConverter 3.0.2
/gnu/store/jic3i199783dk2wm58rcq53lmrpslcwd-soundconverter-3.0.2/lib/soundconverter/python/soundconverter/ui.py:1465:
 Warning: g_value_type_transformable: assertion 'src_type' failed
  builder.add_from_file(gladefile)

(SoundConverter:16020): Gtk-WARNING **: 21:23:34.167: gtkliststore.c:836: 
Unable to convert from (null) to gchararra
y

(It works at this point)


signature.asc
Description: PGP signature

bug#41708: "guix weather" : 504 error

[Christopher Baines]

zimoun  writes:

> By default, "guix weather" returns:
>
> --8<---cut here---start->8---
> 'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
> --8<---cut here---end--->8---
>
> which is not fatal but annoying.  Especially, it takes time.
>
> As discussed on IRC [1], it seems that it is a bug server side.
>
> In addition, something appears similar with Bayfront, well the 4
> substitutes servers that I know returns:
>
> --8<---cut here---start->8---
> 'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
> 'https://bayfront.guix.gnu.org/api/queue?nr=1000' returned 504
> ("Gateway Time-out")
> (continuous integration information unavailable)
> 'https://guix.tobias.gr/api/queue?nr=1000' returned 410 ("Gone")
> --8<---cut here---end--->8---

Hey,

So I think I've got a patch [1] to Cuirass to "fix" this.

1: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00117.html

I expected this was due to the complicated part of the db-get-builds
query, but I think it's actually down to the simple part that fetches
all the outputs for all the builds. Fetching the outputs for a build is
slow, because at the moment, there's no index on the Outputs field, so
looking up the outputs requires reading through the whole table, and the
Outputs table can be quite large.

The performance should improve with the additional query. To see why,
you can use EXPLAIN QUERY PLAN to see what SQLite plans to do when
processing the query:

sqlite> EXPLAIN QUERY PLAN SELECT name, path FROM Outputs WHERE derivation = 
'foo';
QUERY PLAN
`--SCAN TABLE Outputs

sqlite> CREATE INDEX Outputs_derivation_index ON Outputs (derivation);

sqlite> EXPLAIN QUERY PLAN SELECT name, path FROM Outputs WHERE derivation = 
'foo';
QUERY PLAN
`--SEARCH TABLE Outputs USING INDEX Outputs_derivation_index (derivation=?)


I believe that searching the table using an index is going to be faster
than scanning the table, and testing locally and on bayfront suggests
this will resolve the performance issue.


signature.asc
Description: PGP signature

bug#41708: "guix weather" : 504 error

[Christopher Baines]

zimoun  writes:

> On Tue, 09 Jun 2020 at 22:12, Christopher Baines  wrote:
>
>> So I think I've got a patch [1] to Cuirass to "fix" this.
>>
>> 1: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00117.html
>
> [...]
>
>> I believe that searching the table using an index is going to be faster
>> than scanning the table, and testing locally and on bayfront suggests
>> this will resolve the performance issue.
>
> Is the patch installed on Bayfront?
> If yes, I still see 'returned 504 ("Gateway Time-out")' when quering
> Bayfront as '--substitute-urls'.
> If no, is it possible to install it? for testing it in "real life".
>
>
> Cheers,
> simon
>
> ps:
> It is an old request because I complained [1] about it one year ago.
> Maybe something related to the summer coming. ;-)
>
> 1: https://lists.gnu.org/archive/html/help-guix/2019-05/msg00355.html

I've now deployed the change to Bayfront, let me know if you see a
difference? :)

Thanks,

Chris


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#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  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#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#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#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#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#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#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#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_commit=b965b2f004d522acea17f85780e1e44c882e24b3_change=broken_name=_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#49088: grub-hybrid fails to build on aarch64-linux: error: --enable-stack-protector is not supported

[Christopher Baines]

This is the relevant derivation [1], this change was probably introduced
here [2].

1: /gnu/store/vmpn3xk6mzns9zvq7dvlpj67ld3fv48p-grub-hybrid-2.06.drv
2: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=018f95094153660e3041ec160718f0bda286a3dc


checking whether `gcc' accepts `-fstack-protector'... yes
checking whether `gcc' accepts `-fstack-protector-strong'... yes
checking whether `gcc' accepts `-mstack-protector-guard=global'... no
configure: error: --enable-stack-protector is not supported (compiler doesn't 
support -mstack-protector-guard=global)
command 
"/gnu/store/7sfbiqh21h90bc6zi8br1xh60m6qgdd5-bash-minimal-5.0.16/bin/bash" 
"./configure" 
"CONFIG_SHELL=/gnu/store/7sfbiqh21h90bc6zi8br1xh60m6qgdd5-bash-minimal-5.0.16/bin/bash"
 "SHELL=/gnu/store/7sfbiqh21h9
0bc6zi8br1xh60m6qgdd5-bash-minimal-5.0.16/bin/bash" 
"--prefix=/gnu/store/f03p2i9fkngmx90npzl8igqy5h4w0z97-grub-hybrid-2.06" 
"--enable-fast-install" "--build=aarch64-unknown-linux-gnu" 
"--with-platform=efi" "--enabl
e-stack-protector" "PYTHON=true" failed with status 1


signature.asc
Description: PGP signature