bug#39711: Epiphany fails to launch Evince

[Ludovic Courtès]

Hello,

When running Epiphany on a non-GNOME system with:

  guix environment --ad-hoc epiphany -- epiphany

and opening a PDF, it fails to launch Evince (referred to as
“Dokumentmontrilo” below :-)) and crashes:

--8<---cut here---start->8---
$ guix environment --ad-hoc epiphany -- epiphany

** (epiphany:2419): WARNING **: 09:33:46.938: 
webkit_web_context_set_web_process_count_limit is deprecated and does nothing. 
Limiting the number of web processes is no longer possible for security reasons
** Message: 09:33:47.162: Remote error from secret service: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was 
not provided by any .service files

** (epiphany:2419): WARNING **: 09:33:47.162: Failed to search secrets in 
password schema: The name org.freedesktop.secrets was not provided by any 
.service files

** (epiphany:2419): WARNING **: 09:45:47.949: Failed to acquire session 
inhibitor for active download. Is gnome-session running?

** (epiphany:2419): WARNING **: 09:45:51.859: Failed to launch 
Dokumentmontrilo: No s'ha pogut executar el procés fill «gio-launch-desktop» 
(Dosiero aŭ dosierujo ne ekzistas)

(epiphany:2419): GLib-GIO-CRITICAL **: 09:45:51.860: g_app_info_launch_uris: 
assertion 'G_IS_APP_INFO (appinfo)' failed
--8<---cut here---end--->8---

The problem is that ‘gio-launch-desktop’ is not found in $PATH.

Ludo’.

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

[Mathieu Othacehe]

Hello,

On core-updates, qemu-minimal (4.2.0), fails to build. This seems to be
the same issue as this bug. The error is:

--8<---cut here---start->8---
In file included from 
/gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/features.h:489:0,
 from 
/gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/bits/libc-header-start.h:33,
 from 
/gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/stdint.h:26,
 from linuxboot_dma.c:65:
/gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/gnu/stubs.h:7:11:
 fatal error: gnu/stubs-32.h: No such file or directory
 # include 
   ^~~~

Because of this gcc command:

--8<---cut here---start->8---
/gnu/store/dcnp1h3q6qyipwkm0g7l7r1bkvlqvaqa-gcc-7.5.0/bin/gcc -iquote 
/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/. -iquote . -iquote 
/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/tcg -iquote 
/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/tcg/i386 
-I/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/linux-headers 
-I/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/linux-headers -iquote . 
-iquote /tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0 -iquote 
/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/accel/tcg -iquote 
/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/include 
-I/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0 -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fno-pie -ffreestanding   
-fno-stack-protector   -m16   -Wa,-32 -MMD -MP -MT linuxboot_dma.o -MF 
./linuxboot_dma.d -O2 -march=i486  -c -o linuxboot_dma.o linuxboot_dma.c
--8<---cut here---end--->8---

Any idea? Do we still need to add "multilib header" support to our
glibc build?

Thanks,

Mathieu

bug#39712: Partitions produced by the installer not properly unmounted?

[Ludovic Courtès]

Hi Mathieu,

I noticed that partitions created by the installer appear to not be
properly unmounted, at least when running in the context of (gnu tests
install):

--8<---cut here---start->8---
ludo@ribbon ~$ qemu-img convert -O raw 
/gnu/store/2d3s2nbb3j2c1hmkz52xds9rfbk4q3x3-installation /tmp/broken.raw
ludo@ribbon ~$ sudo losetup -P /dev/loop0 /tmp/broken.raw 
ludo@ribbon ~$ sudo dmesg |tail -3
[10703.869334] kvm [8936]: vcpu0, guest rIP: 0xac073dad disabled 
perfctr wrmsr: 0xc2 data 0x
[10742.475623] kvm [8957]: vcpu0, guest rIP: 0xaf073dad disabled 
perfctr wrmsr: 0xc2 data 0x
[11774.318468]  loop0: p1 p2 p3
ludo@ribbon ~$ sudo fdisk -l /dev/loop0
Disk /dev/loop0: 2.15 GiB, 2306867200 bytes, 4505600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 213AE251-0E91-499E-9184-0CCEC6DA64C7

DispositiuStart   Final Sectors  Size Tipus
/dev/loop0p1   2048614340962M BIOS boot
/dev/loop0p2   6144  231423  225280  110M Intercanvi Linux
/dev/loop0p3 231424 4503551 42721282G Linux filesystem
ludo@ribbon ~$ sudo mount /dev/loop0p3 /mnt/usb
ludo@ribbon ~$ sudo dmesg |tail -3
[11774.318468]  loop0: p1 p2 p3
[11803.975300] EXT4-fs (loop0p3): recovery complete
[11803.977277] EXT4-fs (loop0p3): mounted filesystem with ordered data mode. 
Opts: (null)
--8<---cut here---end--->8---

However, I’ve added logging in ‘umount-user-partitions’ in (gnu
installer parted), and the installer does seem to unmount partitions
correctly.

Could it be a side effect of the MS_MOVE dance in
1d02052067e04d7dd8fd1ec17557ca02a30b9bcf?

(I’m observing this on ‘wip-installer-tests’, roughly based on
117d8467be232bcc1b0136d04f362d95d975ca95.)

Thanks,
Ludo’.

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

On Thu, 20 Feb 2020 at 18:11, Arun Isaac  wrote:

> >  2. a regression of r-rgdal introduced by your commit
> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>
> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> regression. Can you confirm?

Maybe, but it is not what the user expects. Upstream explicitly
mentions proj.4, see [1].

[1] https://cloud.r-project.org/web/packages/rgdal/index.html

which is reflected by:

--8<---cut here---start->8---
$ guix show r-rgdal
name: r-rgdal
version: 1.4-8
outputs: out
systems: x86_64-linux i686-linux
dependencies: gdal@3.0.2 pkg-config@0.29.2 proj.4@4.9.3 r-sp@1.3-2 zlib@1.2.11
location: gnu/packages/cran.scm:15897:2
homepage: http://rgdal.r-forge.r-project.org
license: GPL 2+
synopsis: Bindings for the Geospatial Data Abstraction Library
description: This package provides bindings to the Geospatial Data
+ Abstraction Library (GDAL) and access to projection/transformation
+ operations from the PROJ.4 library.
--8<---cut here---end--->8---



The question is: why proj instead of proj.4 in libgeotiff?
The bug [1] cannot be solved using proj.4, why?


[2] https://github.com/OSGeo/libgeotiff/issues/22


All the best,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

>> >  2. a regression of r-rgdal introduced by your commit
>> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>>
>> Replacing proj.4 with proj in the r-rgdal package seems to fix this
>> regression. Can you confirm?
>
> Maybe, but it is not what the user expects. Upstream explicitly
> mentions proj.4, see [1].

> [1] https://cloud.r-project.org/web/packages/rgdal/index.html

No, upstream says that both proj (aka proj6) and proj.4 are
supported. Quoting [1],

"From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..."

> The question is: why proj instead of proj.4 in libgeotiff?
> The bug [1] cannot be solved using proj.4, why?

proj and proj.4 are different versions of the same software, with proj
being the newer version. See
https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
deprecate our proj.4 package and replace all occurrences of proj.4 with
proj.

WDYT?


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

On Fri, 21 Feb 2020 at 13:13, Arun Isaac  wrote:

> >> >  2. a regression of r-rgdal introduced by your commit
> >> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
> >>
> >> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> >> regression. Can you confirm?
> >
> > Maybe, but it is not what the user expects. Upstream explicitly
> > mentions proj.4, see [1].
>
> > [1] https://cloud.r-project.org/web/packages/rgdal/index.html
>
> No, upstream says that both proj (aka proj6) and proj.4 are
> supported. Quoting [1],
>
> "From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..."

I agree, but I was referring to "access to projection/transformation
operations from the 'PROJ.4' library." or "Windows and Mac Intel OS X
binaries (including 'GDAL', 'PROJ.4' and 'Expat') are provided on
'CRAN'."

Well, your comment below says my remark here is irrelevant. :-)


> > The question is: why proj instead of proj.4 in libgeotiff?
> > The bug [1] cannot be solved using proj.4, why?
>
> proj and proj.4 are different versions of the same software, with proj
> being the newer version. See
> https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
> deprecate our proj.4 package and replace all occurrences of proj.4 with
> proj.

Thank you for the pointer, I was not aware.
Well, I agree. Let replace all the dependencies of proj.4 by proj and
deprecate our proj.4 package.


--8<---cut here---start->8---
$ guix graph -t reverse-package proj.4 \
| grep label | cut -d'=' -f2 | cut -d',' -f1
 "proj.4@4.9.3"
 "r-sf@0.8-0"
 "r-spdep@1.1-3"
 "r-monocle3@0.1.2"
 "r-cicero-monocle3@1.3.2-1.fa2fb65"
 "r-adegenet@2.1.2"
 "r-rmetasim@3.1.7"
 "r-hierfstat@0.04-22"
 "r-pegas@0.12"
 "r-rgdal@1.4-8"
 "libosmium@2.14.2"
 "osm2pgsql@0.96.0"
 "mapnik@3.0.18"
 "python2-mapnik@3.0.16"
 "xygrib@1.2.6.1"
 "spatialite-gui@1.7.1"
 "libspatialite@4.3.0a"
 "libgaiagraphics@0.5"
--8<---cut here---end--->8---


Thanks,
simon

bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

> I can see two solutions:
>
>   1. Remove bzip2 support from bootar (it’s not actually needed, is it?).

Ugly but easiest fix for me, see attached.

>   2. Modify (compression bzip2) so that it errors out on first use
>  rather than at load time.

Or
3. Port bzip2 to to 32bit.

> Timothy, janneke, WDYT?

I would prefer 3., with the fix going upstream.  This opens the path to
really using bzip2 in the bootstrap.  2. could be a nice intermediate
step, but I would not know how to do that nicely, as we fetch
(compression bzip2) from upstream.  Timothy?

How about applying attached patch that implements 1. and revert it once
we get to 2. or 3.

janneke

>From 06bc492cdc1f476f0caa558546290ceafde357b1 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Fri, 21 Feb 2020 07:46:16 +0100
Subject: [PATCH] gnu: commencement: bootar: Build fix for i686-linux.

See #39699

* gnu/packages/commencement.scm (bootar)[i686-linux]: Stub bzip2.
---
 gnu/packages/commencement.scm | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index e3800d84a5..4901391073 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -111,6 +111,15 @@
   (guile (string-append guile-dir "/bin/guile")))
  (invoke guile "--no-auto-compile" source)
  (chdir "bootar")
+ (when ,(equal? (%current-system) "i686-linux")
+   (delete-file "scripts/bzip2.in")
+   (delete-file "compression/bzip2.scm")
+   (with-output-to-file "compression/bzip2.scm"
+ (lambda _
+   (display "(define-module (compression bzip2))
+(define-public is-bzip2-file? (const #f))
+(define-public make-bzip2-input-port (const #f))
+"
  #t)))
(replace 'configure (bootstrap-configure ,version "." "scripts"))
(replace 'build (bootstrap-build "."))
-- 
2.24.0


-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Timothy Sample]

Hi Ludo,

Ludovic Courtès  writes:

> Marius Bakke  skribis:
>
>> Bootstrap fails early on i686-linux when trying to build gash-boot0,
>> which fails thusly:
>
> [...]
>
>>?: 1 [primitive-load-path "compression/bzip2" ...]
>> In compression/bzip2.scm:
>>   45: 0 [#]
>>
>> compression/bzip2.scm:45:18: In procedure #:
>> compression/bzip2.scm:45:18: ERROR: R6RS exception:
>>   1. &error
>>   2. &who: bzip2
>>   3. &message: "This module requires at least 32-bit fixnums"
>>   4. &irritants: ()
>> command "tar" "xvf" 
>> "/gnu/store/bspn36jhcd2ky6ih7wnh9z0iz867flc2-gash-0.2.0.tar.gz" failed with 
>> status 1
>
> The error comes from the (compression bzip2) module included in
> “bootar”.
>
> I can see two solutions:
>
>   1. Remove bzip2 support from bootar (it’s not actually needed, is it?).
>
>   2. Modify (compression bzip2) so that it errors out on first use
>  rather than at load time.
>
> Timothy, janneke, WDYT?

Both of those are good options.  The 32-bit fixnum limit is a something
of a development artifact.  I think I can remove it without problems.
If not, I will just remove BZip2 support for now, since I think you’re
right that we don’t use it.

Sorry for the little hiccup!


-- Tim

bug#37939: guix-install.sh: Fails to detect signing key on Debian10.

[zimoun]

Dear

> On Sat, 16 Nov 2019 at 03:34, Kai Mertens  wrote:

> > Anyway – it is of course not a bug of the guix script. Maybe a usage
> > hint within the guix documentation in section 2.1 would be nice?

I think it is not a bug and I do not see what could be improved. I
would like to close this bug. Is it ok for you? Or do you have a
comment to add?

Thank you in advance.

All the best,
simon

bug#39607: GRUB module all_video required to get video on 4K monitor

[Maxim Cournoyer]

Maxim Cournoyer  writes:

> Hello,
>
> Maxim Cournoyer  writes:
>
>> Hello,
>>
>> I installed Guix System on a new machine, which displays on a 4K (3840 x
>> 2160 pixels) monitor.
>>
>> Unless I go to the GRUB command prompt with 'c' at boot and type 'insmod
>> all_video', the video cuts early after booting a GRUB entry with 'No
>> suitable video mode found', or similar.
>>
>> I think we should include this GRUB module in our default GRUB
>> package/configuration.
>>
>> Maxim
>
> I think the attached patches fixes this issue, and makes the
> GRUB configuration a bit simpler too!

While the patches above are an improvement over the current situation,
it still doesn't resolve my problem.  I still get the 'No suitable video
modes, booting in blind mode' message after activating a GRUB entry,
unless I manually "insmod all_video"...

Here's my grub.cfg, along with a blank one generated by 'grub-mkconfig'
for comparison.

# This file was generated from your Guix configuration.  Any changes
# will be lost upon reconfiguration.

function setup_gfxterm {
  set gfxmode=auto
  insmod all_video
  insmod gfxterm
}

# Set 'root' to the partition that contains /gnu/store.
search --label --set btrfs-pool-1

if loadfont 
/gnu/store/m1fx9h7gzw78k0n4da0khbga5i6k8ipk-grub-2.04/share/grub/unicode.pf2; 
then
  setup_gfxterm
fi

terminal_output gfxterm


insmod png
if background_image /gnu/store/xn6hf7a9f1242siybkb7cqh7v2x67qrh-grub-image.png; 
then
  set color_normal=light-gray/black
  set color_highlight=yellow/black
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
insmod keylayouts
keymap /gnu/store/ibdld2935pbkg2fkrmh2z5fjyvas0ixd-grub-keymap.dvorak

set default=0
set timeout=5
menuentry "GNU with Linux-Libre 5.4.18" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/gnu/store/ddnd4h65g3d6chknfsbkchd3xdqdhwd8-system 
--load=/gnu/store/ddnd4h65g3d6chknfsbkchd3xdqdhwd8-system/boot quiet 
modprobe.blacklist=radeon
  initrd 
/rootfs/gnu/store/s0l9md1vx0sw7rky9c9nh7xlmnczxk8g-raw-initrd/initrd.cpio.gz
}

submenu "GNU system, old configurations..." {
menuentry "GNU with Linux-Libre 5.4.18 (#12, 2020-02-20 14:25)" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/var/guix/profiles/system-12-link 
--load=/var/guix/profiles/system-12-link/boot quiet modprobe.blacklist=radeon
  initrd 
/rootfs/gnu/store/cf2qwll5nlr1i7cndxl90vlnx79bwnrq-raw-initrd/initrd.cpio.gz
}
menuentry "GNU with Linux-Libre 5.4.18 (#11, 2020-02-19 21:46)" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/var/guix/profiles/system-11-link 
--load=/var/guix/profiles/system-11-link/boot quiet modprobe.blacklist=radeon
  initrd 
/rootfs/gnu/store/cf2qwll5nlr1i7cndxl90vlnx79bwnrq-raw-initrd/initrd.cpio.gz
}
menuentry "GNU with Linux-Libre 5.4.18 (#10, 2020-02-19 21:45)" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/var/guix/profiles/system-10-link 
--load=/var/guix/profiles/system-10-link/boot quiet modprobe.blacklist=radeon
  initrd 
/rootfs/gnu/store/cf2qwll5nlr1i7cndxl90vlnx79bwnrq-raw-initrd/initrd.cpio.gz
}
menuentry "GNU with Linux-Libre 5.4.18 (#9, 2020-02-19 16:57)" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/var/guix/profiles/system-9-link 
--load=/var/guix/profiles/system-9-link/boot quiet modprobe.blacklist=radeon
  initrd 
/rootfs/gnu/store/cf2qwll5nlr1i7cndxl90vlnx79bwnrq-raw-initrd/initrd.cpio.gz
}
menuentry "GNU with Linux-Libre 5.4.18 (#8, 2020-02-19 16:54)" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/var/guix/profiles/system-8-link 
--load=/var/guix/profiles/system-8-link/boot quiet modprobe.blacklist=radeon
  initrd 
/rootfs/gnu/store/k63b8daqn4cdba3a3sxjjvpz3kil078p-raw-initrd/initrd.cpio.gz
}
menuentry "GNU with Linux-Libre 5.4.18 (#7, 2020-02-17 09:25)" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/var/guix/profiles/system-7-link 
--load=/var/guix/profiles/system-7-link/boot quiet modprobe.blacklist=radeon
  initrd 
/rootfs/gnu/store/jyak0q5b5wjxiishkv4cfgd1xplrxg9r-raw-initrd/initrd.cpio.gz
}
menuentry "GNU with Linux-Libre 5.4.18 (#6, 2020-02-17 09:23)" {
  search --label --set btrfs-pool-1
  linux 
/rootfs/gnu/store/a0499drlaqfzkyqb8fzbk0za49nzpi0k-linux-libre-5.4.18/bzImage 
--root=btrfs-pool-1 --system=/var/guix/profiles/system-6-link 
--load=/var/guix/profiles/system

bug#39712: Partitions produced by the installer not properly unmounted?

[Mathieu Othacehe]

Hey Ludo,

Nice progress on that branch :)

> Could it be a side effect of the MS_MOVE dance in
> 1d02052067e04d7dd8fd1ec17557ca02a30b9bcf?

Could be, I ran the following command on wip-installer-test branch:

--8<---cut here---start->8---
make check-system TESTS=gui-installed-os
--8<---cut here---end--->8---

But it appears to get stuck at this step:

--8<---cut here---start->8---
conversation expecting pattern ((quote pause))
--8<---cut here---end--->8---

I'll try to investigate further later on.

Thanks,

Mathieu

bug#20255: (old)bug#20255: 'search-paths' should respect both user and system profiles

[zimoun]

Dear,

What is the status of the bug#20255 [1]?
It is old; the last activity seems back on 2015, November. So let resume.

The issue is, e.g.:
 - perl installed into the system profile
 - perl-xml-parser installed into an user profile
Then "guix package --search-paths" does not set correctly XML::Parser.


Fixes had been pushed: dedb17a and b2a7223 and cc3de1d.

The final fix is still missing. Because it is a controversial patch
[2] :-) i.e., running 'guix' in '/etc/profile'; see these lines of the
patch:

--8<---cut here---start->8---
+  eval `/run/current-system/profile/bin/guix package \\
+  -p /run/current-system/profile \\
+  -p \"$HOME/.guix-profile\" --search-paths`
--8<---cut here---end--->8---


The friendly "protest" [3] is about turning these lines optional via
an environment variable. I am not sure to follow where the discussion
had been going then.



Well, is the issue still happening 4 years later?
If yes, what should be the fix? What is the status quo?
If no, let close the bug.



Note that other patches are still pending [4] and [5] -- probably
irrelevant now.



All the best,
simon


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#41
[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#44
[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#8
[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20255#26

bug#39575: guix time-machine fails when a tarball was modified in-place

[zimoun]

Hi,

Some follow ups.


For me, now, the command

> > $ guix time-machine \
> >  --commit=56e95d54d209c2428f970d65d9b27ae4168449ad -- help

does not fail anymore at the Guile step:

--8<---cut here---start->8---
  building /gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv...
  - 'check' phasebuilder for
  `/gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv' failed
--8<---cut here---end--->8---

because it was about "FAIL: test-out-of-memory".


Well, now, I am failing at the Python 3.7.3 step too:

--8<---cut here---start->8---
  /gnu/store/s0lw23myd3hvpw28sffkhz8b30x1hcz0-python-minimal-3.7.3.drv failed
--8<---cut here---end--->8---


However, the python error seems about TLS:

--8<---cut here---start->8---
test.test_asyncio.test_windows_utils (unittest.loader.ModuleSkipped)
... test test_asyncio failed
skipped 'Windows only'

==
ERROR: test_start_tls_server_1
(test.test_asyncio.test_sslproto.SelectorStartTLSTests)
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_asyncio/test_sslproto.py",
line 507, in test_start_tls_server_1
self.loop.run_until_complete(run_main())
  File 
"/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/asyncio/base_events.py",
line 584, in run_until_complete
return future.result()
  File 
"/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_asyncio/test_sslproto.py",
line 502, in run_main
loop=self.loop, timeout=self.TIMEOUT)
  File 
"/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/asyncio/tasks.py",
line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
--8<---cut here---end--->8---


> Not sure what to do here.  Could this be a (harmless) coincident?

Me neither.


Cheers,
simon

bug#39713: reply to the original report

[Akshay Khobragade via Bug reports for GNU Guix]

It seems cryptsetup is never invoked and the root partition is not decrypted 
before GRUB could load the kernel.

bug#39660: openvpn-client-service does not support auth-user-pass

[Joshua Branson via Bug reports for GNU Guix]

Julien and I discussed on irc that guix currently does not have a
method of generating my config file.  Here is just an updated list of
the options that I (and possibly others) may need or want.

#+BEGIN_SRC org
These are all the options that my config file has.  If the box does
not have an X, then we should add this in the service definition.

- [ ] "persist-key"
- [ ] "persist-tun"
- [ ] "remote-random"
- [ ] "pull"
- [X] "comp-lzo no"
- [ ] "tls-client"  does tls-auth provide this option???
- [ ] "verify-x509-name Server name-prefix"
- [ ] "ns-cert-type server"  This is possibly deprecated?
- [ ] "key-direction 1" This is another way of specifying tls-auth?
- [X] "route-method exe" This is only useful on Windows.
- [ ] "route-delay 2"
- [X] "tun-mtu 1500" The documentation says most cases...I should
  leave this to it's default parameter.  So unless needed, we probably
  shouldn't need to add it to guix.
  
- The next two options only make sense when we are using the protocol
  udp.  We should probably specify them someway that you can only use
  them if protocol is upd.  Something like:

   #+BEGIN_SRC scheme
   (proto udp
 (upd-options
   (fragment 1300)
   (mssfix 1200))
   #+END_SRC

- [X] "fragment 1300"
- [X] "mssfix 1200"


- [ ] "cipher AES-256-CBC"
- [X] keysize 256 deprecated.  Do not need. and my key size is the
  cipher size anyway.  The documentation does not reccommend manually changing 
your keysize.
- [X] auth SHA512  I have no idea where this is in the documentation
- [X] sndbuf 524288  The documentation says that the default should work.
- [X] rcvbuf 524288  as above
- [X] auth-user-pass login.conf
#+END_SRC

We should also probably allow a file option.  Some users may have a
working file.  Perhaps we should support this:

#+BEGIN_SRC scheme
(openvpn-client-service
  #:file  "/path/to/openvpn.conf")
#+END_SRC

Joshua

bug#20255: (old)bug#20255: 'search-paths' should respect both user and system profiles

[Alex Kost]

zimoun (2020-02-21 16:53 +0100) wrote:

> Dear,
>
> What is the status of the bug#20255 [1]?
> It is old; the last activity seems back on 2015, November. So let resume.
>
> The issue is, e.g.:
>  - perl installed into the system profile
>  - perl-xml-parser installed into an user profile
> Then "guix package --search-paths" does not set correctly XML::Parser.
>
>
> Fixes had been pushed: dedb17a and b2a7223 and cc3de1d.
>
> The final fix is still missing. Because it is a controversial patch
> [2] :-) i.e., running 'guix' in '/etc/profile'; see these lines of the
> patch:
>
> +  eval `/run/current-system/profile/bin/guix package \\
> +  -p /run/current-system/profile \\
> +  -p \"$HOME/.guix-profile\" --search-paths`
>
>
> The friendly "protest" [3] is about turning these lines optional via
> an environment variable. I am not sure to follow where the discussion
> had been going then.

As for me, I am OK with any default setting as long as there is a way to
change it.  I recall Ludovic proposed a patch that allowed to customize
"/etc/profile" and I was happy about it, but he changed his mind on that
patch so it was never committed.

-- 
Alex

bug#39660: openvpn-client-service does not support auth-user-pass

[Julien Lepiller]

Le 21 février 2020 12:10:44 GMT-05:00, Joshua Branson via Bug reports for GNU 
Guix  a écrit :
>
>Julien and I discussed on irc that guix currently does not have a
>method of generating my config file.  Here is just an updated list of
>the options that I (and possibly others) may need or want.
>
>#+BEGIN_SRC org
>These are all the options that my config file has.  If the box does
>not have an X, then we should add this in the service definition.
>
>- [ ] "persist-key"
>- [ ] "persist-tun"
We already have both of them. Are they not documented? They should be 
persist-key? and persist-tun? respectively.

>- [ ] "remote-random"
>- [ ] "pull"
>- [X] "comp-lzo no"
>- [ ] "tls-client"  does tls-auth provide this option???
tls-auth and tls-client are different options. tls-client replaces the client 
directive we currently generate for all openvpn-client-configuration.

>- [ ] "verify-x509-name Server name-prefix"
>- [ ] "ns-cert-type server"  This is possibly deprecated?
>- [ ] "key-direction 1" This is another way of specifying tls-auth?
>- [X] "route-method exe" This is only useful on Windows.
>- [ ] "route-delay 2"
>- [X] "tun-mtu 1500" The documentation says most cases...I should
>  leave this to it's default parameter.  So unless needed, we probably
>  shouldn't need to add it to guix.
>  
>- The next two options only make sense when we are using the protocol
>  udp.  We should probably specify them someway that you can only use
>  them if protocol is upd.  Something like:
>
>   #+BEGIN_SRC scheme
>   (proto udp
> (upd-options
>   (fragment 1300)
>   (mssfix 1200))
>   #+END_SRC
>
>- [X] "fragment 1300"
>- [X] "mssfix 1200"
>
>
>- [ ] "cipher AES-256-CBC"
>- [X] keysize 256 deprecated.  Do not need. and my key size is the
>cipher size anyway.  The documentation does not reccommend manually
>changing your keysize.
>- [X] auth SHA512  I have no idea where this is in the documentation
>- [X] sndbuf 524288  The documentation says that the default should
>work.
>- [X] rcvbuf 524288  as above
>- [X] auth-user-pass login.conf
>#+END_SRC
>
>We should also probably allow a file option.  Some users may have a
>working file.  Perhaps we should support this:
>
>#+BEGIN_SRC scheme
>(openvpn-client-service
>  #:file  "/path/to/openvpn.conf")
>#+END_SRC
>
>Joshua

bug#39713: Was told on IRC (#guix at freenode) to share the details of my problem with Guix (SD) via email

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

Akshay,

Akshay Khobragade via Bug reports for GNU Guix 写道：

This is my first ever installation of Guix where I chose:

1. Separate Boot (/boot) and EFI (/boot/efi) partitions
2. Encrypted root (having used it in Debian for the last 10 
months, I am comfortable)


This just isn't possible (yet).

There's no support in Guix System for a separate, unencrypted, 
/boot partition.  If you want a Guix System with full disk 
encryption you'll have to keep /boot as a regular subdirectory and 
enter your passphrase twice.


Both of these limitations could be removed by someone sufficiently 
motivated and/or annoyed :-)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#39713:

[Akshay Khobragade via Bug reports for GNU Guix]

Thank You for the reply, Tobias.

Will try setting up and report back in a few hours.

I figured any distro would require a separate /boot partition with an encrypted 
root since debian does. I guess not.

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

On Thu, 20 Feb 2020 at 18:11, Arun Isaac  wrote:

> >  2. a regression of r-rgdal introduced by your commit
> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>
> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> regression. Can you confirm?

You mean:

  guix build --with-input=proj.4=proj r-rgdal

then it compiles a lot... and I do not understand why gdal is
recompiled. Anyway!
So after some CPU burning, I get:

--8<---cut here---start->8---
Testing examples for package ‘rgdal’
Running specific tests for package ‘rgdal’
  Running ‘srs_rendering.R’
  comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
5c5
< [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
---
> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
7c7
< [1] "GDAL 3.0.2, released 2019/10/28"
---
> [1] "GDAL 2.4.0, released 2018/12/14"
11c11
<
   scot_BNG
---
>   
>
> trin_inca_pl03
12c12
< "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40
+y_0=-10 +ellps=airy +units=m +no_defs"
---
>   
>   
>  NA
13c13
<
 trin_inca_pl03
---
>   
>  
> kiritimati_primary_roads
14c14
<
 NA
---
>   
>   "+proj=utm +zone=4 +datum=WGS84 +units=m 
> +no_defs "
16c16
<
"+proj=longlat +datum=WGS84 +no_defs"
---
<
   kiritimati_primary_roads
---
>   
>  
> scot_BNG
18c18
<   "+proj=utm
+zone=4 +datum=WGS84 +units=m +no_defs"
---
> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40 +y_0=-10 
> +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 
> +units=m +no_defs "
22c22
< [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
+towgs84=0,0,0,0,0,0,0 +no_defs"
---
> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
24c24
< [1] "+proj=utm +zone=23 +south +ellps=aust_SA
+towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
---
> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 
> +units=m +no_defs "
26c26
< [1] "+proj=longlat +datum=WGS84 +no_defs"
---
> [1] "+proj=longlat +datum=WGS84 +no_defs "
28c28
< [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.99987742019 +x_0=60 +y_0=220.0032
+ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
+no_defs"
---
> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.999877420193 
> +x_0=60 +y_0=220.00325 +a=6378249.2 +b=6356515.00472 
> +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
40c40
< file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.7
+lon_0=-88.3 +k=0.75 +x_0=152400.30480061 +y_0=0
+ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
---
> file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.66 
> +lon_0=-88.33 +k=0.7499 +x_0=152400.3048006096 +y_0=0 
> +datum=NAD27 +units=us-ft +no_defs
41c41
< file:  cea.tif , SRS:  +proj=cea +lat_ts=33.75
+lon_0=-117. +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
---
> file:  cea.tif , SRS:  +proj=cea +lon_0=-117. +lat_ts=33.75 
> +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
42c42
< file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30
+lon_0=-82.16667 +k=0. +x_0=20 +y_0=0 +ellps=GRS80
+towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
---
> file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30 
> +lon_0=-82.17 +k=0. +x_0=20 +y_0=0 +ellps=GRS80 
> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
43c43
< file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +ellps=WGS84
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs
---
> file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +datum=WGS84 +units=m 
> +no_defs
  Running ‘test_proj.R’
  comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
   Running ‘tests.R’
  comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
  Running ‘tripup.R’
  comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
266c266
<  coords FALSE
---
>  coords TRUE
267c267
<  holes FALSE
---
>  holes TRUE
273c273
<  coords FALSE
---
>  coords TRUE
274c274
<  holes FALSE
---
>  holes TRUE
Running vignettes for package ‘rgdal’
  Running ‘OGR_shape_encoding.Rnw’
phase `check' succeeded after 18.7 seconds
--8<---cut 

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

On Fri, 21 Feb 2020 at 13:13, Arun Isaac  wrote:

> proj and proj.4 are different versions of the same software, with proj
> being the newer version. See
> https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
> deprecate our proj.4 package and replace all occurrences of proj.4 with
> proj.

For other packages than r-rgdal depending on proj.4:
 - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
 - not ok: libspatialite and libosmium

And some packages do not build at all with the default (proj.4):
mapnik and spatialite-gui. Well, it is more than on my machine. ;-)

http://data.guix.gnu.org/revision/e40d6c4c7a74fca3572991c55706a787b19d4d90/package/mapnik/3.0.18
http://data.guix.gnu.org/revision/e40d6c4c7a74fca3572991c55706a787b19d4d90/package/spatialite-gui/1.7.1


All the best,
simon

bug#36882: Qemu 4.2.0 build for x86_64-linux fails

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> On core-updates, qemu-minimal (4.2.0), fails to build. This seems to be
> the same issue as this bug. The error is:
>
> In file included from 
> /gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/features.h:489:0,
>  from 
> /gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/bits/libc-header-start.h:33,
>  from 
> /gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/stdint.h:26,
>  from linuxboot_dma.c:65:
> /gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include/gnu/stubs.h:7:11:
>  fatal error: gnu/stubs-32.h: No such file or directory
>  # include 
>^~~~
>
> Because of this gcc command:
>
> /gnu/store/dcnp1h3q6qyipwkm0g7l7r1bkvlqvaqa-gcc-7.5.0/bin/gcc -iquote 
> /tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/. -iquote . -iquote 
> /tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/tcg -iquote 
> /tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/tcg/i386 
> -I/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/linux-headers 
> -I/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/linux-headers -iquote . 
> -iquote /tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0 -iquote 
> /tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/accel/tcg -iquote 
> /tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0/include 
> -I/tmp/guix-build-qemu-minimal-4.2.0.drv-0/qemu-4.2.0 -Wstrict-prototypes 
> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
> -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value 
> -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
> -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
> -Wold-style-definition -Wtype-limits -fno-pie -ffreestanding   
> -fno-stack-protector   -m16   -Wa,-32 -MMD -MP -MT linuxboot_dma.o -MF 
> ./linuxboot_dma.d -O2 -march=i486  -c -o linuxboot_dma.o linuxboot_dma.c

How was this bug initially reported against QEMU 4.0.0 fixed?

On master there’s pretty much the same command as above, with ‘-m16’,
and “yet it works”.

  https://ci.guix.gnu.org/log/ymzp5yz2r3zfw4xczwwlykyjv2kqcqs0-qemu-4.2.0

Ludo’.

bug#39713:

[Akshay Khobragade via Bug reports for GNU Guix]

I reinstalled the system with encrypted root and without a separate /boot 
partition and it boots successfully!

Thank you Tobias.

bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> Ludovic Courtès writes:
>
> Hi!
>
>> I can see two solutions:
>>
>>   1. Remove bzip2 support from bootar (it’s not actually needed, is it?).
>
> Ugly but easiest fix for me, see attached.
>
>>   2. Modify (compression bzip2) so that it errors out on first use
>>  rather than at load time.
>
> Or
> 3. Port bzip2 to to 32bit.

Indeed!

> I would prefer 3., with the fix going upstream.  This opens the path to
> really using bzip2 in the bootstrap.  2. could be a nice intermediate
> step, but I would not know how to do that nicely, as we fetch
> (compression bzip2) from upstream.  Timothy?

I don’t think we’ll introduce new uses of bzip2 on the bootstrap path.
So if it’s unnecessary today, it may remain unnecessary in the
foreseeable future.

> From 06bc492cdc1f476f0caa558546290ceafde357b1 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen 
> Date: Fri, 21 Feb 2020 07:46:16 +0100
> Subject: [PATCH] gnu: commencement: bootar: Build fix for i686-linux.
>
> See #39699

Nitpick: “Fixes .”  :-)

> * gnu/packages/commencement.scm (bootar)[i686-linux]: Stub bzip2.

[...]

>   (chdir "bootar")
> + (when ,(equal? (%current-system) "i686-linux")
> +   (delete-file "scripts/bzip2.in")
> +   (delete-file "compression/bzip2.scm")
> +   (with-output-to-file "compression/bzip2.scm"
> + (lambda _
> +   (display "(define-module (compression bzip2))
> +(define-public is-bzip2-file? (const #f))
> +(define-public make-bzip2-input-port (const #f))
> +"

Perhaps you can write it in a way that avoids rebuilds on x86_64:

  ,@(if (equal? …)
'((…))
'())

Or actually, we can just remove the functionality unconditionally for
now since it could be error-prone to have different features depending
on the platform.

WDYT?

Timothy Sample  skribis:

> Both of those are good options.  The 32-bit fixnum limit is a something
> of a development artifact.  I think I can remove it without problems.
> If not, I will just remove BZip2 support for now, since I think you’re
> right that we don’t use it.

For now I guess we can apply something as discussed above, but in the
longer run, it’d be nice to have that 32-bit limit waived!

> Sorry for the little hiccup!

No problem, it’s really great that we got these binary seeds further
reduced!

Ludo’.

bug#39712: Partitions produced by the installer not properly unmounted?

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> Could it be a side effect of the MS_MOVE dance in
>> 1d02052067e04d7dd8fd1ec17557ca02a30b9bcf?
>
> Could be, I ran the following command on wip-installer-test branch:
>
> make check-system TESTS=gui-installed-os
>
>
> But it appears to get stuck at this step:
>
> conversation expecting pattern ((quote pause))
>
> I'll try to investigate further later on.

Don’t investigate on that branch yet though, I have quite a lot of
changes that I’ll push soon.  :-)

But I think the problem should show up even with “make check-system
TESTS=installed-os” on master.

Thanks,
Ludo’.

bug#39575: guix time-machine fails when a tarball was modified in-place

[Ludovic Courtès]

Hi,

zimoun  skribis:

> Well, now, I am failing at the Python 3.7.3 step too:
>
>   /gnu/store/s0lw23myd3hvpw28sffkhz8b30x1hcz0-python-minimal-3.7.3.drv failed
>
>
>
> However, the python error seems about TLS:
>
> test.test_asyncio.test_windows_utils (unittest.loader.ModuleSkipped)
> ... test test_asyncio failed
> skipped 'Windows only'
>
> ==
> ERROR: test_start_tls_server_1
> (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
> --
> Traceback (most recent call last):
>   File 
> "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_asyncio/test_sslproto.py",
> line 507, in test_start_tls_server_1
> self.loop.run_until_complete(run_main())
>   File 
> "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/asyncio/base_events.py",
> line 584, in run_until_complete
> return future.result()
>   File 
> "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_asyncio/test_sslproto.py",
> line 502, in run_main
> loop=self.loop, timeout=self.TIMEOUT)
>   File 
> "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/asyncio/tasks.py",
> line 423, in wait_for
> raise futures.TimeoutError()
> concurrent.futures._base.TimeoutError

It seems to be timing-sensitive, is it deterministic?

One lesson here is that we should keep substitutes for a longer amount
of time—we actually have a lot of storage space on berlin so we should
investigate what happened.  (The NixOS folks currently keep substitutes
forever but they found it’s starting to be expensive…)

Thanks,
Ludo’.

bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

>> I would prefer 3., with the fix going upstream.  This opens the path to
>> really using bzip2 in the bootstrap.  2. could be a nice intermediate
>> step, but I would not know how to do that nicely, as we fetch
>> (compression bzip2) from upstream.  Timothy?
>
> I don’t think we’ll introduce new uses of bzip2 on the bootstrap path.
> So if it’s unnecessary today, it may remain unnecessary in the
> foreseeable future.

That's a helpful perspective; Yes, I agree.

>> See #39699
>
> Nitpick: “Fixes .”  :-)

Thanks.

>>   (chdir "bootar")
>> + (when ,(equal? (%current-system) "i686-linux")
>> +   (delete-file "scripts/bzip2.in")
>> +   (delete-file "compression/bzip2.scm")
>> +   (with-output-to-file "compression/bzip2.scm"
>> + (lambda _
>> +   (display "(define-module (compression bzip2))
>> +(define-public is-bzip2-file? (const #f))
>> +(define-public make-bzip2-input-port (const #f))
>> +"
>
> Perhaps you can write it in a way that avoids rebuilds on x86_64:
>
>   ,@(if (equal? …)
> '((…))
> '())

Neat...

> Or actually, we can just remove the functionality unconditionally for
> now since it could be error-prone to have different features depending
> on the platform.
>
> WDYT?

Yes, I removed it.  Hoping that's okay.  We just decided above it's
adding an unnecessary "if".

@Timothy: if you want to change this in bootar itself and remove the
workaround from commencement, please feel free.  Pushed to core-updates
as

a82cf70e8ae4c8dcf03d2633f09dcfc8bb6d6d1e

Thanks,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

>> I would prefer 3., with the fix going upstream.  This opens the path to
>> really using bzip2 in the bootstrap.  2. could be a nice intermediate
>> step, but I would not know how to do that nicely, as we fetch
>> (compression bzip2) from upstream.  Timothy?
>
> I don’t think we’ll introduce new uses of bzip2 on the bootstrap path.
> So if it’s unnecessary today, it may remain unnecessary in the
> foreseeable future.

That's a helpful perspective; Yes, I agree.

>> See #39699
>
> Nitpick: “Fixes .”  :-)

Thanks.

>>   (chdir "bootar")
>> + (when ,(equal? (%current-system) "i686-linux")
>> +   (delete-file "scripts/bzip2.in")
>> +   (delete-file "compression/bzip2.scm")
>> +   (with-output-to-file "compression/bzip2.scm"
>> + (lambda _
>> +   (display "(define-module (compression bzip2))
>> +(define-public is-bzip2-file? (const #f))
>> +(define-public make-bzip2-input-port (const #f))
>> +"
>
> Perhaps you can write it in a way that avoids rebuilds on x86_64:
>
>   ,@(if (equal? …)
> '((…))
> '())

Neat...

> Or actually, we can just remove the functionality unconditionally for
> now since it could be error-prone to have different features depending
> on the platform.
>
> WDYT?

Yes, I removed it.  Hoping that's okay.  We just decided above it's
adding an unnecessary "if".

@Timothy: if you want to change this in bootar itself and remove the
workaround from commencement, please feel free.  Pushed to core-updates
as

a82cf70e8ae4c8dcf03d2633f09dcfc8bb6d6d1e

Thanks,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> For other packages than r-rgdal depending on proj.4:
>  - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
>  - not ok: libspatialite and libosmium

Indeed, all packages don't yet support proj. We'll have to keep proj.4
around until their upstreams adds support for proj.

> And some packages do not build at all with the default (proj.4):
> mapnik and spatialite-gui. Well, it is more than on my machine. ;-)

These will have to be fixed too. Do open separate bug reports for
those. Please provide patches if possible.

Thanks!


signature.asc
Description: PGP signature

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> You mean:
>
>   guix build --with-input=proj.4=proj r-rgdal
>
> then it compiles a lot... and I do not understand why gdal is
> recompiled. Anyway!

Your command recursively replaces proj.4 with proj. So, some dependency
of gdal might have been modified resulting in a rebuild of gdal.

> So after some CPU burning, I get:
>
> --8<---cut here---start->8---
> Testing examples for package ‘rgdal’
> Running specific tests for package ‘rgdal’
>   Running ‘srs_rendering.R’
>   comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
> 5c5
> < [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
> ---
>> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
> 7c7
> < [1] "GDAL 3.0.2, released 2019/10/28"
> ---
>> [1] "GDAL 2.4.0, released 2018/12/14"
> 11c11
> <
>scot_BNG
> ---
>>  
>> 
>> trin_inca_pl03
> 12c12
> < "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40
> +y_0=-10 +ellps=airy +units=m +no_defs"
> ---
>>  
>>  
>>NA
> 13c13
> <
>  trin_inca_pl03
> ---
>>  
>>   
>> kiritimati_primary_roads
> 14c14
> <
>  NA
> ---
>>  
>>"+proj=utm +zone=4 +datum=WGS84 +units=m 
>> +no_defs "
> 16c16
> <
> "+proj=longlat +datum=WGS84 +no_defs"
> ---
> <
>kiritimati_primary_roads
> ---
>>  
>>  
>>  scot_BNG
> 18c18
> <   "+proj=utm
> +zone=4 +datum=WGS84 +units=m +no_defs"
> ---
>> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40 +y_0=-10 
>> +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 
>> +units=m +no_defs "
> 22c22
> < [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
> +towgs84=0,0,0,0,0,0,0 +no_defs"
> ---
>> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
> 24c24
> < [1] "+proj=utm +zone=23 +south +ellps=aust_SA
> +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
> ---
>> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 
>> +units=m +no_defs "
> 26c26
> < [1] "+proj=longlat +datum=WGS84 +no_defs"
> ---
>> [1] "+proj=longlat +datum=WGS84 +no_defs "
> 28c28
> < [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
> +k_0=0.99987742019 +x_0=60 +y_0=220.0032
> +ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
> +no_defs"
> ---
>> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.999877420193 
>> +x_0=60 +y_0=220.00325 +a=6378249.2 +b=6356515.00472 
>> +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
> 40c40
> < file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.7
> +lon_0=-88.3 +k=0.75 +x_0=152400.30480061 +y_0=0
> +ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.66 
>> +lon_0=-88.33 +k=0.7499 +x_0=152400.3048006096 
>> +y_0=0 +datum=NAD27 +units=us-ft +no_defs
> 41c41
> < file:  cea.tif , SRS:  +proj=cea +lat_ts=33.75
> +lon_0=-117. +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> ---
>> file:  cea.tif , SRS:  +proj=cea +lon_0=-117. +lat_ts=33.75 
>> +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> 42c42
> < file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30
> +lon_0=-82.16667 +k=0. +x_0=20 +y_0=0 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30 
>> +lon_0=-82.17 +k=0. +x_0=20 +y_0=0 +ellps=GRS80 
>> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> 43c43
> < file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +ellps=WGS84
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
> ---
>> file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +datum=WGS84 +units=m 
>> +no_defs
>   Running ‘test_proj.R’
>   comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
>Running ‘tests.R’
>   comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
>   Running ‘tripup.R’
>   comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
> 266c266
> <  coords FALSE
> ---
>>  coords TRUE
> 267c267
> <  holes FALSE
> ---
>>  holes TRUE
> 273c273
> <  coords FALSE
> ---
>>  coords TRUE
> 274c274
> <  holes FALSE
> ---
>>  holes TRUE
> Running vignettes for packag

bug#39725: /gnu/store/.links: base16 or base32?

[Ludovic Courtès]

Seen while stracing guix-daemon during GC (the “deleting unused links”
phase):

--8<---cut here---start->8---
unlink("/gnu/store/.links/3a16c555c7c60f9c781895eec65a31a04a6cc535fff5a381499c1a4717d8f19f")
 = 0
unlink("/gnu/store/.links/1mm1n1xmjb1in2sv71kpa90n5iv30h24blzfj4z0icdssbly19kh")
 = 0
unlink("/gnu/store/.links/4213e7fe3db934f2817fbd0fb3a74e5395736fcc7633d295c557462cae88f945")
 = 0
unlink("/gnu/store/.links/1g46q6yf868x7wfqnzcy4rb8r780bqi986vjvb1n7xm4ln3jizzf")
 = 0
unlink("/gnu/store/.links/8b261f0461a89419ee4436d11ac828fc63a4d8d6473696262d020c17758964eb")
 = 0
unlink("/gnu/store/.links/0znm2gdxraz3i88r3iy838d86s1zfidx8gga4kwiqcsnmaz206d6")
 = 0
unlink("/gnu/store/.links/f3fe1645f86a6a1effd8e4f0dfcdaef8d73c8163c96d2b2cb42e0bd7c05d9b5b")
 = 0
unlink("/gnu/store/.links/69a86d84c31d5b728f6d7496413bac8a0bc06c388255f0b81868066463cff80f")
 = 0
unlink("/gnu/store/.links/0s0bb4pkm282srrdm61fd0lf9zn7r85s370llbp616pk4j2szkhs")
 = 0
unlink("/gnu/store/.links/a2b0c70e4c03f3247250155d4a2cfdf6a21e03458f892f4c2a9ba861259022f6")
 = 0
unlink("/gnu/store/.links/5faebd1dc60adbf32b430090a29248b86c56eba4805aeedc8d99c459a28b34eb")
 = 0
unlink("/gnu/store/.links/8d7d77f86a32f2a0a36b508dcbdc4a44c61dec284b9dc6299a8b7d18db9938dc")
 = 0
unlink("/gnu/store/.links/1cjlcwkyr59apcym97zaw8r2m4ahqc11zrm51aqzvwg3b0xvchhw")
 = 0
unlink("/gnu/store/.links/0z9cw4h1p4cm6jp4zap9db1lh60i0ynal0dxd2f8ilzp085wb1xj")
 = 0
unlink("/gnu/store/.links/1vzgxm1png21gf13v5ac3494h9zshy6y35cxk38pf6dd0qimcand")
 = 0
unlink("/gnu/store/.links/1r8xm4j57m9h99rvv80q2wgv29p3q42ws4s2f0c3jd9a77hl2qn8")
 = 0
--8<---cut here---end--->8---

There’s an inconsistency here!

(guix store deduplication) uses base16, but optimize-store.cc does:

/* Check if this is a known hash. */
Path linkPath = linksDir + "/" + printHash32(hash);

… where ‘printHash32’ returns a nix-base32 string.  Oops!

The effect is just that deduplication wouldn’t work as well as it could:
results from offloaded builds would be deduplicated among them but not
against other store items.

Ludo’.

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

On Fri, 21 Feb 2020 at 22:36, Arun Isaac  wrote:

> > For other packages than r-rgdal depending on proj.4:
> >  - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
> >  - not ok: libspatialite and libosmium
>
> Indeed, all packages don't yet support proj. We'll have to keep proj.4
> around until their upstreams adds support for proj.

So it is difficult to deprecate proj.4, IMHO.

> > And some packages do not build at all with the default (proj.4):
> > mapnik and spatialite-gui. Well, it is more than on my machine. ;-)
>
> These will have to be fixed too. Do open separate bug reports for
> those. Please provide patches if possible.

I will do.


Thanks,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

On Fri, 21 Feb 2020 at 22:40, Arun Isaac  wrote:

> > You mean:
> >
> >   guix build --with-input=proj.4=proj r-rgdal
> >
> > then it compiles a lot... and I do not understand why gdal is
> > recompiled. Anyway!
>
> Your command recursively replaces proj.4 with proj. So, some dependency
> of gdal might have been modified resulting in a rebuild of gdal.

Yes, but gdal already depends on proj and not proj.4.
Then I examined the graph and did not find the offending package.
That's why I do not understand why gdal is recompiled.
I mean, let find the intersection between "guix graph gdal" and "guix
graph -t reverse-package proj.4", and I do not understand because I
find it empty.


> > Therefore, I do not confirm, I guess.
>
> I don't understand. With proj instead of proj.4, it does work, doesn't
> it? There are no errors and the check phase succeeds.

I have try to replace proj.4 by proj in the inputs field and I get the
same error.
Well, it does not work for me. Maybe I am doing a mistake.


Cheers,
simon

bug#39727: statx error running 'guix gc' on CentOS 7

[Paul Garlick]

Hi Guix,

After a 'guix pull' today to commit
536cc4aae5b58b45b974530646a4916a29a8aa6c I noticed that 'guix gc' fails
with the message:

guix gc: error: statting `/gnu/store/.links/0pck...': Invalid argument

The system is running CentOS 7:

$ cat /etc/centos-release
CentOS Linux release 7.7.1908 (Core)

A temporary fix is to remove 'statx' from the list of functions checked
in 
config-daemon.ac (line 96):

-  statvfs nanosleep strsignal statx])
+ statvfs nanosleep strsignal])

This could a problem with the kernel version or coreutils [0] in CentOS
7.  

It seems that HAVE_STATX is set in the guix build process but then
runtime calls to statx generate errors.

Best regards,

Paul.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1760300

bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Ludovic Courtès]

Jan Nieuwenhuizen  skribis:

> @Timothy: if you want to change this in bootar itself and remove the
> workaround from commencement, please feel free.  Pushed to core-updates
> as
>
> a82cf70e8ae4c8dcf03d2633f09dcfc8bb6d6d1e

Thanks!

Ludo’.

bug#39727: statx error running 'guix gc' on CentOS 7

[Ludovic Courtès]

Hi,

Paul Garlick  skribis:

> After a 'guix pull' today to commit
> 536cc4aae5b58b45b974530646a4916a29a8aa6c I noticed that 'guix gc' fails
> with the message:
>
> guix gc: error: statting `/gnu/store/.links/0pck...': Invalid argument

This was during the “removing unused link” phase, right?

> The system is running CentOS 7:
>
> $ cat /etc/centos-release
> CentOS Linux release 7.7.1908 (Core)

What does “uname -r” return?

This is most likely an issue with the ancient kernel being used.

It would be nice if you could try running a C program that does
something like this:

struct statx st;
if (statx(AT_FDCWD, "/",
  AT_SYMLINK_NOFOLLOW | AT_STATX_DONT_SYNC,
  STATX_SIZE | STATX_NLINK, &st) == -1)
  printf ("failed: %m\n");

It should fail similarly.  Then you can try commenting out
AT_STATX_DONT_SYNC and see whether it fails.

Let me know how it goes!

Thanks,
Ludo’.

bug#39725: /gnu/store/.links: base16 or base32?

[Ludovic Courtès]

Ludovic Courtès  skribis:

> (guix store deduplication) uses base16, but optimize-store.cc does:
>
> /* Check if this is a known hash. */
> Path linkPath = linksDir + "/" + printHash32(hash);
>
> … where ‘printHash32’ returns a nix-base32 string.  Oops!

Fixed in 4cb63a564d413c745983a608790a943ac07f8d67.

bug#39713:

[Ludovic Courtès]

Hi,

Akshay Khobragade  skribis:

> I reinstalled the system with encrypted root and without a separate /boot 
> partition and it boots successfully!

Awesome, thanks for letting us know!

Ludo’.

bug#39584: evolution: involid page id error when composing emails

[Christopher Howard]

I'm not sure if my workaround is effective or not, at least one time I
still received the page ID error:

(evolution:20864): evolution-util-WARNING **: 15:33:29.599: Failed to
call a DBus Proxy method
org.gnome.Evolution.WebExtension::AddCSSRuleIntoStyleSheet: Invalid
page ID: 55

I'm curious as I don't recall this ever happening on my home computer,
only on my work computer.

My work computer system is

 .. `.   christopher@eowyn 
 `--..```..`   `..```..--`   - 
   .-:///-:::.   `-:::///:-. OS: Guix System
5f6ce90a90011147a555cd400d7aaec8ef532a7f x86_64 
  .:::` `:::.Host: Vostro 230 00 
   -//:`-::- Kernel: 5.4.19-gnu 
://:   -::-  Uptime: 3 days, 2 hours, 1 min 
`///- .:::`  Packages: 55 (guix-system), 81
(guix-user) 
 -+++-:::.   Shell: bash 5.0.7 
  :+/:::-DE: GNOME 3.32.2 
  `-`Theme: Adwaita [GTK2/3] 
 Icons: Adwaita [GTK2/3] 
 Terminal: .gnome-terminal 
 CPU: Intel Core 2 Duo E7500 (2) @
2.736GHz 
 GPU: Intel 4 Series Chipset 
 Memory: 3020MiB / 7929MiB 

I can send my home computer information after I get home.


-Original Message-
From: Christopher Howard 
To: Marius Bakke , 39...@debbugs.gnu.org
Subject: Re: bug#39584: evolution: involid page id error when composing
emails
Date: Tue, 18 Feb 2020 12:56:33 -0900

Looking at that patch code, I'm trying an experiment where I set the
environment variable mentioned:

christopher@eowyn ~$ WEBKIT_USE_SINGLE_WEB_PROCESS="0" evolution 

This should give the same effect as the code would, unless I'm setting
the variable the wrong way. I haven't had the problem again yet, but
I've only tried it for about 20 minutes.

I'm curious also if that code would work, since it makes the assumption
the program name is "evolution", whereas ".evolution-real" is the name
of the process in Guix as listed by "ps -e".

-- 

Christopher Howard
Enterprise Solutions Manager
Alaska Satellite Internet
PO Box 70, Ester, AK 99725
3239 La Ree Way, Fairbanks, AK 99709
907.451.0088
1.888.396.5623
www.alaskasatelliteinternet.com

-Original Message-
From: Christopher Howard 
To: Marius Bakke , 39...@debbugs.gnu.org
Subject: Re: bug#39584: evolution: involid page id error when composing
emails
Date: Fri, 14 Feb 2020 12:12:27 -0900

I'm eager to give the patch a try. I've never learned yet how to add
add a source patch to a package definition, so it might take me some
time to get to it if I had no help. Is there an ETA on Gnome 3.34?

-- 

Christopher Howard
Enterprise Solutions Manager
Alaska Satellite Internet
PO Box 70, Ester, AK 99725
3239 La Ree Way, Fairbanks, AK 99709
907.451.0088
1.888.396.5623
www.alaskasatelliteinternet.com

-Original Message-
From: Marius Bakke 
To: Christopher Howard , 
39...@debbugs.gnu.org
Subject: Re: bug#39584: evolution: involid page id error when composing
emails
Date: Fri, 14 Feb 2020 17:07:09 +0100

Christopher Howard <
christop...@alaskasi.com
> writes:

> Hi, I use evolution heavily, current 3.32.4 from Guix. I updated my
> guix user packages and guix system about a week ago. When composing
> emails, I occasionally see an error similar to this appear in a box
> above the message composition area:
> 
> gdbus.error:org.freedesktop.dbus.error.invalidargs: invalid page id:
> 165
> 
> While the error is there, I cannot save the email to drafts or send
> it.
> To resolve, I must copy the email contents to another program, then
> restart evolution to create the email again. It seems to be very
> random, but I'd guess it happens once about every five to ten emails
> I
> send.

Searching the web for the error message leads to these bug reports:

https://bugzilla.redhat.com/show_bug.cgi?id=1757243

https://gitlab.gnome.org/GNOME/evolution/issues/587


Apparently Evolution does not work properly with WebKitGTK 2.26.
Backporting all the upstream changes looks cumbersome, but I suppose we
could do something like this until we have GNOME 3.34:

https://src.fedoraproject.org/rpms/webkit2gtk3/blob/f30/f/webkit-process.patch


Thoughts?  Are you able to give it a try?

Thanks,
Marius
-- 
Christopher Howard
Enterprise Solutions Manager
Alaska Satellite Internet
PO Box 70, Ester, AK 99725
3239 La Ree Way, Fairbanks, AK 99709
907.451.0088
1.888.396.5623
www.alaskasatelliteinternet.com

bug#34033: Offloading sometimes hangs

[Maxim Cournoyer]

Hello Ludovic,

Ludovic Courtès  writes:

> Hello,
>
> Ludovic Courtès  skribis:
>
>> A simple thing would be to somehow get libssh to pass POLLIN | POLLRDHUP
>> instead of just POLLIN.
>
> Reported here:
>
>   https://www.libssh.org/archive/libssh/2019-01/000.html
>
> A fix has been proposed by upstream and should be committed shortly.
>
>> Additionally, we could change Guile-SSH so that we can specify a timeout
>> when reading from a channel.
>
> Turns out we can set a per-session timeout, which we already do (see
> #:timeout in ‘open-ssh-session’ in (guix scripts offload)) but
> ‘ssh_channel_read’ would ignore it and instead pass an infinite timeout
> to poll(2):
>
>   https://www.libssh.org/archive/libssh/2019-01/001.html
>
> This issue happens to be fixed in libssh 0.8.x, so I upgraded our libssh
> package in commit a8b0556ea1e439c89dc1ba33c8864e8b9b811f08.
>
> (That still doesn’t tell us why our ‘guix offload’ processes would
> occasionally be stuck but at least it ensures the build farm keeps
> making progress even when that happens.)
>
> Ludo’.

Seems the patch in the response at the URL you linked is awaiting some
feedback/review.  Is this the reason 'guix substitute' hangs for so long
when the substitute server is down? (like 1 minute or so).

Maxim

bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Timothy Sample]

Hi all,

Jan Nieuwenhuizen  writes:

> @Timothy: if you want to change this in bootar itself and remove the
> workaround from commencement, please feel free.

Done in 4b807ef87c4634e8bea1431d47ee3df3b519145d.


-- Tim

bug#31825: guix offload fails with guix-authenticate error

[Maxim Cournoyer]

Just as a follow-up; I've managed to fall into this trap again,
attempting to authorize the keys by adding them to the 'authorize-keys'
field of guix-configuration record.

On the local machine:

--8<---cut here---start->8---
guix offload test /etc/guix/machines.scm 127.0.0.1
guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
guix offload: Guix is usable on '127.0.0.1' (test returned 
"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: '127.0.0.1' is running GNU Guile 3.0.0
sending 1 store item (0 MiB) to '127.0.0.1'...
exporting path `/gnu/store/l9mph3k5l26nm8mb50imsklbsz0bji0b-export-test'
guix offload: error: program 
`/gnu/store/amjsgks2n05k9lkck78z64nphad1dkqr-guix-1.0.1-13.50299ad/bin/guix' 
failed with exit code 1
--8<---cut here---end--->8---

On the remote machine:

--8<---cut here---start->8---
sudo strace -p 15683 -p 15716 -f -s345 -o /tmp/log
--8<---cut here---end--->8---

And found within /tmp/log:

16120 write(2, "guix authenticate: error: error: unauthorized public key: 
(public-key \n (ecc \n  (curve Ed25519)\n  (q #MY-PUBLIC-KEY#)\n  )\n )\n", 
176) = 176

So, still actual :-)

Maxim