bug#39646: bug#39648: Reverse my commits on GNOME meta-package

[Raghav Gururajan]

Hi Ludo!

> I agree. As a stop-gap measure, I propose to commit the following
> change real soon. I’ve tested it in a VM; it addresses the points Andy
> raised by re-adding the important bits mentioned in
> .

Sure, I can do that.

> Raghav, don’t worry, we all make mistakes! We can refine this calmly
> later on.

Thank you. All good. I just thought reversing would be better for time being, 
but that's okay. :-)

Regards,
RG.

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

[Ludovic Courtès]

Hey!

Timothy Sample  skribis:

> 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.

Thanks!

In other news, I’ve mirrored bootar-1{,a}.ses on ftp.gnu.org so we have
an additional copy out there.

Ludo’.

bug#34033: Offloading sometimes hangs

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

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

The issues above are in libssh and were fixed a while ago.  ‘guix
substitute’ doesn’t use Guile-SSH/libssh, so the problem you’re seeing
must be something different.

What do you mean by “the substitute server is down”?  You mean ‘guix
publish’ is not running, or the machine is unavailable altogether?

Thanks,
Ludo’.

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

[Arun Isaac]

Let's try to debug the problem you are facing. After applying the
attached patch, please provide the complete outputs of the following
commands. If the output is too long, feel free to send it as an email
attachment.

$ ./pre-inst-env guix build r-gdal

$ ./pre-inst-env guix environment --container --ad-hoc r r-rgdal -- Rscript -e 
'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; 
ogrInfo(dsn=dsn, layer="cities")'

Thank you for your patience! Cheers! :-)

From 7b2430788c2d168bd2a8a848e488a0e03140057b Mon Sep 17 00:00:00 2001
From: Arun Isaac 
Date: Sun, 23 Feb 2020 00:46:32 +0530
Subject: [PATCH] gnu: r-rgdal: Replace proj.4 with proj.

* gnu/packages/cran.scm (r-rgdal)[inputs]: Replace proj.4 with proj.
---
 gnu/packages/cran.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
index b731ddc29e..05759459af 100644
--- a/gnu/packages/cran.scm
+++ b/gnu/packages/cran.scm
@@ -18,6 +18,7 @@
 ;;; Copyright © 2018, 2019 Brett Gilio 
 ;;; Copyright © 2019 Nicolò Balzarotti 
 ;;; Copyright © 2019 Wiktor Żelazny 
+;;; Copyright © 2020 Arun Isaac 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -15907,7 +15908,7 @@ effect size.")
 (build-system r-build-system)
 (inputs
  `(("gdal" ,gdal)
-   ("proj.4" ,proj.4)
+   ("proj" ,proj)
("zlib" ,zlib)))
 (propagated-inputs
  `(("r-sp" ,r-sp)))
-- 
2.23.0



signature.asc
Description: PGP signature

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

[Mathieu Othacehe]

Hello,

> 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

On master, when building qemu, this is the gcc include path (obtained
with "gcc -v -x c -E /dev/null"):

--8<---cut here---start->8---
 /gnu/store/adm2cx3ayabn1sp84nnjsk0672m800ip-flex-2.6.4/include
 /gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/include
 ...
 
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include
 [1]
 
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed
 /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include [2]
--8<---cut here---end--->8---

We see that glibc comes last. So when building a program with "gcc
-ffreestanding -m16", the first  header picked is the one from
gcc (marked [1] above). This header contains:

--8<---cut here---start->8---
#ifndef _GCC_WRAP_STDINT_H
  #if __STDC_HOSTED__ <-- Set to 0 because of -ffreestanding option.
# if defined __cplusplus && __cplusplus >= 201103L
  #  undef __STDC_LIMIT_MACROS
  #  define __STDC_LIMIT_MACROS
  #  undef __STDC_CONSTANT_MACROS
  #  define __STDC_CONSTANT_MACROS
# endif
# include_next 
  #else
# include "stdint-gcc.h" <-- This one gets included.
  #endif
  #define _GCC_WRAP_STDINT_H
#endif
--8<---cut here---end--->8---

So the  from glibc (marked [2] above) is neved included. And
that's good because this header would try to include 
that our glibc does not provide.

Now the question is, why glibc comes last, whereas it is a part of
CPATH? The "gcc -v -x c -E /dev/null" command says:

--8<---cut here---start->8---
ignoring duplicate directory 
"/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include"
  as it is a non-system directory that duplicates a system directory
--8<---cut here---end--->8---

So the glibc from CPATH is ignored and the last glibc, hardcoded into
gcc is kept.

Now, what's happening on core-updates? Because of CPATH ->
C_INCLUDE_PATH transition, we have a different behaviour. The same
command as above states:

--8<---cut here---start->8---
ignoring duplicate directory 
"/gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include"
...
 /gnu/store/kyypmcn2miyzllqqmcx28gvj89qnvhpi-flex-2.6.4/include
 ...
 /gnu/store/jsjsczgr8xdnbdminl7lm2v56b7dq7lq-glibc-2.31/include [1]
 ...
 
/gnu/store/wl7zanqf0s9bfppggmv8qxqan71fjfw8-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include
 [2]
 
/gnu/store/wl7zanqf0s9bfppggmv8qxqan71fjfw8-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include-fixed
--8<---cut here---end--->8---

The glibc ignored seems to be the hardcoded one. The one from the
C_INCLUDE_PATH is kept. So the  included is the one from glibc
(marked [1] above), which triggers  inclusion and makes
build fail.

So here's how it fails, but I'm not sure how to fix it. Removing glibc
from C_INCLUDE_PATH, forces gcc to use the hardcoded one that comes last
and fixes the build. However, there are maybe other implications?

Thanks,

Mathieu

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

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

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

Hmm I’m not sure this is true.

> Well this does not involve the graphical installer, so I'm not sure to
> understand.
>
> Anyway, testing the installer in Qemu, I can reproduce a failure where
> the first umount in "umount-cow-store" throws an exception (busy
> device), when umounting a crypted partition.

On current ‘wip-installer-test’
(0699b97f7df8708a000eb7bfb043c2cef6672dc3), you can run:

  make check-system TESTS=gui-installed-os

(It should succeed.)

If you take the /gnu/store/…-installation item produced and mount it as
I showed before in this thread, you should see a “recovery complete”
message from the kernel.

Note that LUKS is not involved at all in this case, and ‘umount’ doesn’t
throw.

Ludo’.

bug#39648: Reverse my commits on GNOME meta-package

[Ludovic Courtès]

Hi Tobias & all!

Tobias Geerinckx-Rice  skribis:

> Raghav Gururajan 写道：
>> Could you please reverse my following commits:
>>
>> 1) d36fa50fbf8169018193774782fd21f1b13b9c0e
>>
>> 2) 7922b6f795eb575084546ec9bfb9d40508a9378e
>>
>> 3) 8d8c6bffc528b60574f84620bd6c3ee9bfa1173f
>>
>> 4) a8cda7f57992e9ce9ae4a694eba54e3eab42c39b
>
> Copy-pasted from #guix:
>
> Whoa there, that's drastic, let's put that on hold.
>
> The first two only add packages (did they break anything? what?), the
> third has no effect on packages if your commit message is accurate.
>
> The fourth is the only one that removes packages, and even that might
> be better tweaked (this time: with comments noting what each non-core
> package brings to the GNOME table) than flat-out reverted.
>
> What do you think?

I agree.  As a stop-gap measure, I propose to commit the following
change real soon.  I’ve tested it in a VM; it addresses the points Andy
raised by re-adding the important bits mentioned in
.

Raghav, don’t worry, we all make mistakes!  We can refine this calmly
later on.

Thanks,
Ludo’.

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 3c63ab283d..c64b182869 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -7906,7 +7906,29 @@ world.")
("yelp" ,yelp)
  ;; Others
("hicolor-icon-theme" ,hicolor-icon-theme)
-   ("gnome-online-accounts" ,gnome-online-accounts)))
+   ("gnome-online-accounts" ,gnome-online-accounts)
+
+   ;; Packages not part of GNOME proper but that are needed for a good
+   ;; experience.  See .
+   ;; XXX: Find out exactly which ones are needed and why.
+   ("font-cantarell",font-cantarell)
+   ("font-dejavu"   ,font-dejavu)
+   ("at-spi2-core"  ,at-spi2-core)
+   ("dbus"  ,dbus)
+   ("dconf" ,dconf)
+   ("desktop-file-utils",desktop-file-utils)
+   ("gnome-default-applications" ,gnome-default-applications)
+   ("gnome-themes-standard" ,gnome-themes-standard)
+   ("gst-plugins-base"  ,gst-plugins-base)
+   ("gst-plugins-good"  ,gst-plugins-good)
+   ("gucharmap" ,gucharmap)
+   ("pinentry-gnome3"   ,pinentry-gnome3)
+   ("pulseaudio",pulseaudio)
+   ("shared-mime-info"  ,shared-mime-info)
+   ("system-config-printer" ,system-config-printer)
+   ("xdg-user-dirs" ,xdg-user-dirs)
+   ("yelp"  ,yelp)
+   ("zenity",zenity)))
 (synopsis "The GNU desktop environment")
 (home-page "https://www.gnome.org/;)
 (description

bug#39738: ffmpeg-4.2.2 fails to build on native i686-linux

[Jan Nieuwenhuizen]

Hi,

When building ffmpeg-4.2.2 (current master, 
8d1b22b27fba3d1e4310f02a5897d231b42ca117)
natively on 32bit hardware, the build fails because of two failing tests
(full log attached)

--8<---cut here---start->8---
--- ./tests/ref/fate/filter-pixdesc-grayf32be   2019-12-31 21:35:25.0 
+
+++ tests/data/fate/filter-pixdesc-grayf32be2020-02-22 15:15:50.209912771 
+
@@ -1 +1 @@
-pixdesc-grayf32be   9b23c74e8e8ffae5d7c7e82bbf5929da
+pixdesc-grayf32be   01816b882016239d0cf84241818926a4
--- ./tests/ref/fate/filter-pixdesc-grayf32le   2019-12-31 21:35:25.0 
+
+++ tests/data/fate/filter-pixdesc-grayf32le2020-02-22 15:15:50.253914049 
+
@@ -1 +1 @@
-pixdesc-grayf32le   291f074a24c44799a1f437d1c6f1
+pixdesc-grayf32le   1b234318d06d5a76e980c376ad8764e5
Test filter-pixdesc-grayf32be failed. Look at 
tests/data/fate/filter-pixdesc-grayf32be.err for details.
make: *** [tests/Makefile:238: fate-filter-pixdesc-grayf32be] Error 1
make: *** Waiting for unfinished jobs
Test filter-pixdesc-grayf32le failed. Look at 
tests/data/fate/filter-pixdesc-grayf32le.err for details.
make: *** [tests/Makefile:238: fate-filter-pixdesc-grayf32le] Error 1

Test suite failed, dumping logs.
command "make" "fate" "-j" "2" failed with status 2
--8<---cut here---end--->8---

How to attempt fixing this?

Building it on 64 bit hardware (much faster!) works for me, i.e. this

guix build --system=i686-linux ffmpeg

works for me and can be used as a substitute...

Together with qemu-minimal-2.10 depending on ffmpeg
(https://bugs.gnu.org/39737) and no available substitutes this made for
a pretty rough "guix system reconfigure"-experience today.

I worked around this by adding a ffmpeg package that ignored the check
phase (#:tests? #f); I am wondering if we could we enable (something
like) that from the command line?  WDYT?

Apart from this hiccup I had a smooth upgrade from guix 0.14,
impressive!

Greetings,
janneke



lbnqlz4ppj0bgckksn7r25p385qawy-ffmpeg-4.2.2.drv.bz2
Description: Binary data

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

bug#39511: github auth

[Matt Wette]

On 2/22/20 2:52 AM, Ludovic Courtès wrote:

Hi Matt,

Matt Wette  skribis:


I have not gotten into testing, but according to email and references
provided previously the patch below might work.

I’ve applied the patch on your behalf, thank you!

Ludo’.



much appreciated

Matt

bug#39536: problem in emacs-gnuplot mode

[Ludovic Courtès]

Hi Jean-Baptiste,

Jean-Baptiste Note  skribis:

>>From 5f2db54f0e0e31dfcc9e6271dceb5aa38a799746 Mon Sep 17 00:00:00 2001
> From: Jean-Baptiste Note 
> Date: Sun, 9 Feb 2020 21:02:33 +0100
> Subject: [PATCH] [emacs-gnuplot] Fix destination directory
>
> ---
>  gnu/packages/emacs-xyz.scm | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Good catch!  I added a commit log that follows our conventions and
applied the patch.

For the record, ‘guix.d’ support was removed in
65a7dd2950ca13a8b942b2836260a2192351b271.

Thanks,
Ludo’.

bug#39708: nfs-service-type broken: rpc.mountd respawns too quickly

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> The rpc.mountd service, one of the required services for
> nfs-service-type, respawns the process quickly until disabled.

Does /var/log/messages contain hints?  Is rpc.statd running?
Could it be that all these services need to depend on ‘loopback’?

No answers, but a lot of questions.  :-)

Ludo’.

bug#39511: github auth

[Ludovic Courtès]

Hi Matt,

Matt Wette  skribis:

> I have not gotten into testing, but according to email and references
> provided previously the patch below might work.

I’ve applied the patch on your behalf, thank you!

Ludo’.

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

[Mathieu Othacehe]

Hey Ludo,

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

Well this does not involve the graphical installer, so I'm not sure to
understand.

Anyway, testing the installer in Qemu, I can reproduce a failure where
the first umount in "umount-cow-store" throws an exception (busy
device), when umounting a crypted partition.

That's probably what's bitting you, so to be continued!

Thanks,

Mathieu