bug#41625: Sporadic guix-offload crashes due to EOF errors

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Marius Bakke  skribis:
>
>> Marius Bakke  writes:
>>
>>> 'guix offload test' passes without problems.
>>
>> Not so fast, running it in a loop reveals the crash.
>>
>> There is a trace file in /root/offloadtest.trace on Berlin with such an
>> occurence.  It looks like a timeout is reached shortly before the EOF
>> error:
>>
>> 10139 poll([{fd=14, events=POLLIN|POLLOUT}], 1, 0) = 1 ([{fd=14, 
>> revents=POLLOUT}])
>> 10139 poll([{fd=14, events=POLLIN}], 1, 15000) = 0 (Timeout)
>> 10139 write(2, "Backtrace:\n", 11)  = 11
>>
>> This seems to be from a different node than the one reported previously,
>> as the preceding connect() was to this machine:
>>
>> 10139 connect(44, {sa_family=AF_INET, sin_port=htons(22),
>> sin_addr=inet_addr("141.80.167.186")}, 16) = -1 EINPROGRESS
>> (Operation now in progress)
>
> So it looks like ‘connect’ fails and eventually we get an EOF object.
> However, I don’t see where that EOF comes from because the return value
> of ‘connect!’ (the Guile-SSH procedure) is properly checked.
>
> Ludo’.

I got a slightly different backtrace that suggests making the connection
is not at fault, rather it occurs during the read-repl-response call:

--8<---cut here---start->8---
guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
Backtrace:
   8 (primitive-load "/home/maxim/.config/guix/current/bin/guix")
In guix/ui.scm:
  2165:12  7 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
  1747:15  5 (with-exception-handler # _ # _ # …)
In guix/scripts/offload.scm:
   704:21  4 (check-machine-availability _ _)
In srfi/srfi-1.scm:
   586:17  3 (map1 (#))
In guix/inferior.scm:
258:2  2 (port->inferior _ _)
240:2  1 (read-repl-response _ _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" #)'.
--8<---cut here---end--->8---

I seem to get this more often than not with the overdrive1 offload
machine.

Maxim

bug#48602: Grafted python2 packages gets erroneous package names

[Mark H Weaver]

Hi Marius,

Marius Bakke  writes:

> 'guix build python2-urllib3' currently gives:
>
>   /gnu/store/cx22ny550g97klf499yqgzx9mpvvkx1f-python2-python2-urllib3-1.26.4
>
> Adding '--no-grafts' gives the expected file name.
>
> Note that up until commit 2f97a666a564fea0fdcff00a0513aa8b4c2d60fe, the
> store file name was actually '...-python2-python2-python2-urllib3-...'!
>
> Not sure if this is a recent regression, or what may be causing it.
>
> Ideas?

It might be related to commit 1a265842e634656411bc7304c4648273f174f65e,
and especially the changes made to guix/build-system/python.scm.

  Mark

bug#30093: what manual workaround?

[Carlo Zancanaro]

Hi Tomás,

I'm not certain what your problem is, but I've run into problems 
with XDG_DATA_DIRS in the past, and I've added these lines in my 
profile script *before* sourcing any Guix profiles:


   # XDG_DATA_DIRS often starts off empty, but an empty value is
   # interpreted as this value. Loading a profile can set it, 
   though,

   # which effectively ignores the default value. We want it to
   # instead add to the default, so we set it here to the default
   # value.
   if [ -z "$XDG_DATA_DIRS" ]; then
   export XDG_DATA_DIRS="/usr/local/share/:/usr/share/"
   fi

I see you have this line in your profile script:

export 
XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"


but you call this *after* sourcing the Guix profiles, which means 
if Guix sets XDG_DATA_DIRS then the fallback case (i.e. including 
/usr/local/share and /usr/share) won't have any effect, and the 
default paths (which Ubuntu expects) won't end up in the path.


I'm not as familiar with GI_TYPELIB_PATH, but I think it might 
need something similar with a default value of 
/usr/lib/girepository-1.0 (that's mostly a guess, based on a quick 
search of the internet and my local Ubuntu machine).


I hope that helps!

Carlo

bug#48616: GParted root

[Emad Alblueshi]

Hi,

I have installed *GParted* 1.2.0 using (guix system GNOME) the app showed
an error message instead of asking root password to use it and even if I
run the app as a root the icons are not showing up  properly.

Thanks

bug#48604: Linux-libre 5.12.5 freezes

[Yusuf Talha via Bug reports for GNU Guix]

hello.  i am using a librebooted thinkpad x200 laptop with gnu guix.  if i use 
the latest kernel on my system, my computer suddenly freezes without a reason 
after a while of usage.  it is probably a kernel panic.  older kernels don't 
have that problem.  i'd be glad if you fix this.  thank you for your attention.

bug#48612: Expat "billion laughs attack" vulnerability (CVE-2013-0340)

[Maxime Devos]

Marius Bakke schreef op zo 23-05-2021 om 17:15 [+0200]:
> Greetings Guix,
> 
> What's old is new again!  Expat 2.4.0 was recently released with a
> fix for a denial of service issue dubbed "billion laughs attack":
> 
>   https://github.com/libexpat/libexpat/blob/R_2_4_0/expat/Changes
>   https://en.wikipedia.org/wiki/Billion_laughs_attack
> 
> Seeing as this vulnerability appears to be eight years old and is
> "merely" a DoS: is it worth fixing on the 'master' branch (and
> re-grafting pretty much everything)?

Since this is ‘merely’ a DoS that does not lead to an exploit, I
would simply upgrade the package on 'core-updates'. However, I don't
run any servers. At worst, an attacker could bring down a computer or
burn CPU cyles but nothing else. Bad, but not an exploit and not worth
a graft in my opinion. If this attack is found to cause an annoyance in
the wild, we can easily add a graft later.

> 
> In any case I've attached a patch that does just that and I'm currently
> using it on my system.  I'm hesitant to push it because of the grafting
> cost and would like others opinion.
> 

I would like others opinion as well.

Greetings,
Maxime.


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

bug#47172: Shepherd 0.8.1 tests fail on core-updates

[Marius Bakke]

Ludovic Courtès  skriver:

> Ludovic Courtès  skribis:
>
>> This turns out to be due to a… miscompilation bug.
>>
>> In (shepherd scripts herd), ‘run-command’ has this code:
>>
>>   (let ((sock(open-connection socket-file))
>> (action* (if (and (eq? action 'detailed-status)
>>   (memq service '(root shepherd)))
>>  'status
>>  action)))
>> …)
>>
>> Problem is that everything works as if (eq? action 'detailed-status)
>> was omitted, such that ‘herd stop root’ is interpreted as ‘herd status
>> root’.
>
> A workaround that works with 3.0.7 is swapping the two ‘and’
> sub-expressions:
>
> diff --git a/modules/shepherd/scripts/herd.scm 
> b/modules/shepherd/scripts/herd.scm
> index 106de1e..39d2e34 100644
> --- a/modules/shepherd/scripts/herd.scm
> +++ b/modules/shepherd/scripts/herd.scm
> @@ -126,8 +126,8 @@ of pairs."
>  the daemon via SOCKET-FILE."
>(with-system-error-handling
> (let ((sock(open-connection socket-file))
> - (action* (if (and (eq? action 'detailed-status)
> -   (memq service '(root shepherd)))
> + (action* (if (and (memq service '(root shepherd))
> +   (eq? action 'detailed-status))
>'status
>action)))
>   ;; Send the command.

Cc'ing the relevant Guile bug:

  https://bugs.gnu.org/48368

See also commit 79be6a985799adc6d663890250f4fb7c12f015b4 on
'core-updates' that builds with -O1 as a less satisfactory workaround.


signature.asc
Description: PGP signature

bug#26604: documentation: pdf generation is broken

[Marius Bakke]

zimoun  skriver:

> Hi,
>
> On Tue, 4 May 2021 at 12:04, Ricardo Wurmus  wrote:
>
>> At least the first “wizard stuff” is merely a list of packages.
>> There isn’t anything we can do to avoid the selection of packages,
>> because that stuff is modular by design.  We could have an
>> arbitrary collection of Texlive packages, but I’m sure we can’t
>> agree on any good set because what exactly is needed depends on
>> the document.
>
> [...]
>
>> If the problem is in figuring out what Texlive packages to install
>> for generating the Guix manual: we can either document that or add
>> the required packages to the inputs.
>
> I agree.  Maybe via a manifest file?
>
>> If you still get errors relating to fonts or font maps: this has
>> been fixed on the “master” branch; the texlive-configuration
>> profile hook didn’t update the font maps.
>
> Cool!  I have missed.
>
> Well, let close this old bug. \o/

Agreed, closing!


signature.asc
Description: PGP signature

bug#48612: Expat "billion laughs attack" vulnerability (CVE-2013-0340)

[Marius Bakke]

Greetings Guix,

What's old is new again!  Expat 2.4.0 was recently released with a
fix for a denial of service issue dubbed "billion laughs attack":

  https://github.com/libexpat/libexpat/blob/R_2_4_0/expat/Changes
  https://en.wikipedia.org/wiki/Billion_laughs_attack

Seeing as this vulnerability appears to be eight years old and is
"merely" a DoS: is it worth fixing on the 'master' branch (and
re-grafting pretty much everything)?

In any case I've attached a patch that does just that and I'm currently
using it on my system.  I'm hesitant to push it because of the grafting
cost and would like others opinion.

From 2589767bf405b837db06dadf1c9f990620f11a38 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 23 May 2021 14:22:16 +0200
Subject: [PATCH] gnu: expat: Replace with 2.4.0 [fixes CVE-2013-0340].

* gnu/packages/xml.scm (expat-2.4.0): New variable.
(expat)[replacement]: New field.
---
 gnu/packages/xml.scm | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm
index ad2e3ec6c9..cbd33326e8 100644
--- a/gnu/packages/xml.scm
+++ b/gnu/packages/xml.scm
@@ -13,7 +13,7 @@
 ;;; Copyright © 2016 Jan Nieuwenhuizen 
 ;;; Copyright © 2016, 2017 Nikita 
 ;;; Copyright © 2016–2021 Tobias Geerinckx-Rice 
-;;; Copyright © 2016, 2017, 2018, 2019, 2020 Marius Bakke 
+;;; Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Marius Bakke 
 ;;; Copyright © 2017 Adriano Peluso 
 ;;; Copyright © 2017 Gregor Giesen 
 ;;; Copyright © 2017 Alex Vong 
@@ -121,6 +121,7 @@ the entire document.")
   (package
 (name "expat")
 (version "2.2.9")
+(replacement expat-2.4.0)
 (source (let ((dot->underscore (lambda (c) (if (char=? #\. c) #\_ c
   (origin
 (method url-fetch)
@@ -144,6 +145,24 @@ stream-oriented parser in which an application registers handlers for
 things the parser might find in the XML document (like start tags).")
 (license license:expat)))
 
+;; Replacement package to fix CVE-2013-0340.
+(define expat-2.4.0
+  (package
+(inherit expat)
+(version "2.4.0")
+(source (let ((dot->underscore (lambda (c) (if (char=? #\. c) #\_ c
+  (origin
+(method url-fetch)
+(uri (list (string-append "mirror://sourceforge/expat/expat/"
+  version "/expat-" version ".tar.xz")
+   (string-append
+"https://github.com/libexpat/libexpat/releases/download/R_;
+(string-map dot->underscore version)
+"/expat-" version ".tar.xz")))
+(sha256
+ (base32
+  "04hyv04ygicyajb9ancv02a7sj5v97d94m2bnrjr5fx03r84iib3")))
+
 (define-public libebml
   (package
 (name "libebml")
-- 
2.31.1



signature.asc
Description: PGP signature

bug#46450: [core-updates] r-suppdists source checksum changed

[Marius Bakke]

zimoun  skriver:

> Hi,
>
> On Thu, 11 Feb 2021 at 22:54, Danny Milosavljevic  
> wrote:
>> From http://cran.r-project.org/src/contrib/SuppDists_1.1-9.5.tar.gz...
>> downloading from 
>> http://cran.r-project.org/src/contrib/SuppDists_1.1-9.5.tar.gz ...
>>  SuppDists_1.1-9.5.tar.gz  138KiB
>>   502.0MiB/s 00:00 [##] 
>> 100.0%
>> sha256 hash mismatch for 
>> /gnu/store/2rrhniq5xfab0ba80g845fbs82l66vbr-SuppDists_1.1-9.5.tar.gz:
>>   expected hash: 01j6p94m1g363nph2158fq2rmd6z3h5dvcv6aidh2d6syw131xak
>>   actual hash:   1i3iq12a5x5k49ac01mikzcrrq9gc148xq3m08h4xm07bha6f2v8
>> hash mismatch for store item 
>> '/gnu/store/2rrhniq5xfab0ba80g845fbs82l66vbr-SuppDists_1.1-9.5.tar.gz'
>> build of 
>> /gnu/store/j4kyq3knjjin3s1gn8vc4hfd61gw1c2g-SuppDists_1.1-9.5.tar.gz.drv 
>> failed
>> View build log at 
>> '/var/log/guix/drvs/j4/kyq3knjjin3s1gn8vc4hfd61gw1c2g-SuppDists_1.1-9.5.tar.gz.drv.bz2'.
>> cannot build derivation 
>> `/gnu/store/cqmqlsdw67hbhjvplh56b649c8w74lv7-r-suppdists-1.1-9.5.drv': 1 
>> dependencies couldn't be built
>
> Sadly, this often happens with R packages from CRAN.  Upstream does an
> in-place replacement.  Well, it is fixed on master (or should be soon :-))
>
> See .
>
> Closing?

Indeed, thanks for checking!


signature.asc
Description: PGP signature

bug#46478: [core-updates] runc source checksum changed

[Marius Bakke]

Danny Milosavljevic  skriver:

> downloading from 
> https://github.com/opencontainers/runc/releases/download/v1.0.0-rc6/runc.tar.xz
>  ...
>
> sha256 hash mismatch for 
> /gnu/store/i2aqpvr4ga4j6cw718jmnmrm209f37ls-runc-1.0.0-rc6.tar.xz:
>   expected hash: 1c7832dq70slkjh8qp2civ1wxhhdd2hrx84pq7db1mmqc9fdr3cc
>   actual hash:   05i1j4xqwnva30c24gcrdvdx6wcjqgpyz7cn3gi0bs6jlcfv43gs
> hash mismatch for store item 
> '/gnu/store/i2aqpvr4ga4j6cw718jmnmrm209f37ls-runc-1.0.0-rc6.tar.xz'
> build of 
> /gnu/store/ml7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv failed
> View build log at 
> '/var/log/guix/drvs/ml/7q5rz9xziqg1c85j9b9059mifqc8gs-runc-1.0.0-rc6.tar.xz.drv.bz2'.

This was fixed in 86c39376cc00ed19758a2861c11f85fa5b94cda4.


signature.asc
Description: PGP signature

bug#46479: [core-updates] scdoc source checksum changed

[Marius Bakke]

Danny Milosavljevic  skriver:

> sha256 hash mismatch for 
> /gnu/store/3kvddjq70m96y0mci365bz4z1sihyqsj-scdoc-1.10.1.tar.gz:
>   expected hash: 13x7g1r56bshvfmlvapvz35ywnbgsh337kywb5kcv8nc6b3j3q40
>   actual hash:   0cr32dgj90zzlavk83mwl6smf8wdls5yv2zq4h7idhsikhp0mdji
> hash mismatch for store item 
> '/gnu/store/3kvddjq70m96y0mci365bz4z1sihyqsj-scdoc-1.10.1.tar.gz'
> build of /gnu/store/vz804mghzh2bw7332jsm2xygrzifly6h-scdoc-1.10.1.tar.gz.drv 
> failed

This was fixed in 841e5fb4ddff7f29c06cf9faea65cfe5626fde20.


signature.asc
Description: PGP signature

bug#46474: [core-updates] libinfinity source disappeared

[Marius Bakke]

Danny Milosavljevic  skriver:

> building 
> /gnu/store/30p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv...
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From http://releases.0x539.de/libinfinity/libinfinity-0.7.2.tar.gz...
> following redirection to 
> `https://github.com/gobby/libinfinity/releases/download/v0.7.2/libinfinity-0.7.2.tar.gz'...
> download failed 
> "https://github.com/gobby/libinfinity/releases/download/v0.7.2/libinfinity-0.7.2.tar.gz;
>  404 "Not Found"
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From 
> https://ci.guix.gnu.org/file/libinfinity-0.7.2.tar.gz/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f...
> download failed 
> "https://ci.guix.gnu.org/file/libinfinity-0.7.2.tar.gz/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f;
>  404 "Not Found"
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From 
> https://tarballs.nixos.org/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f...
> download failed 
> "https://tarballs.nixos.org/sha256/17i3g61hxz9pzl3ryd1yr15142r25m06jfzjrpdy7ic1b8vjjw3f;
>  404 "Not Found"
>
> Starting download of 
> /gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz
> From 
> https://archive.softwareheritage.org/api/1/content/sha256:6e7029375a81c5e3dbcdf23b69402d220b124ac83e349f07fd37fd0e8379239e/raw/...
> download failed 
> "https://archive.softwareheritage.org/api/1/content/sha256:6e7029375a81c5e3dbcdf23b69402d220b124ac83e349f07fd37fd0e8379239e/raw/;
>  404 "Not Found"
> failed to download 
> "/gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz" from 
> "http://releases.0x539.de/libinfinity/libinfinity-0.7.2.tar.gz;
> builder for 
> `/gnu/store/30p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv' 
> failed to produce output path 
> `/gnu/store/kl8h5kar3sqp0c1ginkgijfsjva4mwpa-libinfinity-0.7.2.tar.gz'
> build of 
> /gnu/store/30p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv 
> failed
> View build log at 
> '/var/log/guix/drvs/30/p35iq59n87x1vrpf2q0ndx6xhi3h4v-libinfinity-0.7.2.tar.gz.drv.bz2'.
> cannot build derivation 
> `/gnu/store/fj7f1sydid703jlffgbmcdbas36p1fv6-libinfinity-0.7.2.drv': 1 
> dependencies couldn't be built
> guix build: error: build of 
> `/gnu/store/fj7f1sydid703jlffgbmcdbas36p1fv6-libinfinity-0.7.2.drv' failed
>
> That's because the URL should be 
> https://github.com/gobby/libinfinity/releases/download/0.7.2/libinfinity-0.7.2.tar.gz
>  , note: no "v" before "0.7.2".
>
> But that's a redirection by upstream (from 
> http://releases.0x539.de/libinfinity/libinfinity-0.7.2.tar.gz ) which is 
> wrong.
>
> Upstream bug report https://github.com/gobby/libinfinity/issues/29 .

This appears to have been fixed, closing!


signature.asc
Description: PGP signature

bug#46467: [core-updates] foo2zjs source checksum changed

[Marius Bakke]

Danny Milosavljevic  skriver:

> sha256 hash mismatch for 
> /gnu/store/5hkf0xjga0wirk1wv8fsqvyazai4zzh6-foo2zjs.tar.gz:
>   expected hash: 11ddx6wf8b5ksl4fqw6fnyz9m3y470lryyrskkya2bsch2bvj9lg
>   actual hash:   14x3wizvncdy0xgvmcx541qanwb7bg76abygqy17bxycn1zh5r1x
> hash mismatch for store item 
> '/gnu/store/5hkf0xjga0wirk1wv8fsqvyazai4zzh6-foo2zjs.tar.gz'
> build of /gnu/store/4b4fq6j1zwffz8l8c69b6y3lj2ixdl8c-foo2zjs.tar.gz.drv failed
>
> That's because http://foo2zjs.rkkda.com/foo2zjs.tar.gz is not versioned, and 
> we
> use that anyway.  WTF?

I believe this was fixed in f1442560906de4863c89a6f8c1c08169ee0738cb.


signature.asc
Description: PGP signature

bug#46330: Guile-provided GMP allocators interfere with GnuTLS

[Marius Bakke]

Ludovic Courtès  skriver:

> Ludovic Courtès  skribis:
>
>> One of the solutions is to set:
>>
>>   scm_install_gmp_memory_functions = 0;
>
> Done in a53f711422f63d7e32b8639b968cf00bcc69ffea, followed by an update
> of the ‘guix’ package in 63d4b74420563c4e2dbdfa29b3816d1dad9cd723.
>
> This mostly solves the problem on the Guix side, but the issue remains
> in GnuTLS.  I practical terms, we could experience random test failures
> in the guile-gnutls test suite, like the Debian folks did.
>
> At the very least we’ll need to work around that possibility in
> ‘core-updates’.  We could skip them, or add ‘gc-disable’ calls there.
> Or we could build GnuTLS against Nettle-with-mini-GMP when that becomes
> an option.
>
> The other option coming up is to build Guile against mini-GMP.  Mike
> Gran just started looked into it and it may be that 3.0.6 will offer it.
>
> I’m keeping the bug open until this is sorted out.

I believe this was sorted with the mini-gmp in Guile 3.0.6.  Please
reopen if I'm mistaken.  :-)


signature.asc
Description: PGP signature

bug#48602: Grafted python2 packages gets erroneous package names

[Marius Bakke]

Hello,

'guix build python2-urllib3' currently gives:

  /gnu/store/cx22ny550g97klf499yqgzx9mpvvkx1f-python2-python2-urllib3-1.26.4

Adding '--no-grafts' gives the expected file name.

Note that up until commit 2f97a666a564fea0fdcff00a0513aa8b4c2d60fe, the
store file name was actually '...-python2-python2-python2-urllib3-...'!

Not sure if this is a recent regression, or what may be causing it.

Ideas?


signature.asc
Description: PGP signature

bug#47172: Shepherd 0.8.1 tests fail on core-updates

[Ludovic Courtès]

Ludovic Courtès  skribis:

> This turns out to be due to a… miscompilation bug.
>
> In (shepherd scripts herd), ‘run-command’ has this code:
>
>   (let ((sock(open-connection socket-file))
> (action* (if (and (eq? action 'detailed-status)
>   (memq service '(root shepherd)))
>  'status
>  action)))
> …)
>
> Problem is that everything works as if (eq? action 'detailed-status)
> was omitted, such that ‘herd stop root’ is interpreted as ‘herd status
> root’.

A workaround that works with 3.0.7 is swapping the two ‘and’
sub-expressions:

diff --git a/modules/shepherd/scripts/herd.scm b/modules/shepherd/scripts/herd.scm
index 106de1e..39d2e34 100644
--- a/modules/shepherd/scripts/herd.scm
+++ b/modules/shepherd/scripts/herd.scm
@@ -126,8 +126,8 @@ of pairs."
 the daemon via SOCKET-FILE."
   (with-system-error-handling
(let ((sock(open-connection socket-file))
- (action* (if (and (eq? action 'detailed-status)
-   (memq service '(root shepherd)))
+ (action* (if (and (memq service '(root shepherd))
+   (eq? action 'detailed-status))
   'status
   action)))
  ;; Send the command.

Ludo’.

bug#47172: Shepherd 0.8.1 tests fail on core-updates

[Ludovic Courtès]

Hi there,

Léo Le Bouter  skribis:

> Some tests fail:
>
> FAIL: tests/no-home.sh
> FAIL: tests/status-sexp.sh
> PASS: tests/misbehaved-client.sh

[...]

> It seems this is due to guile 3.0.5, GNU Shepherd 0.8.1 does not work
> with it, it works with guile 3.0.2 however.

This turns out to be due to a… miscompilation bug.

In (shepherd scripts herd), ‘run-command’ has this code:

  (let ((sock(open-connection socket-file))
(action* (if (and (eq? action 'detailed-status)
  (memq service '(root shepherd)))
 'status
 action)))
…)

Problem is that everything works as if (eq? action 'detailed-status)
was omitted, such that ‘herd stop root’ is interpreted as ‘herd status
root’.

Simply wrapping the condition in (pk …) “fixes” the problem.

The peval output looks good (it contains the 'detailed-status
comparison), but the assembly seems to lack the 'detailed-status
comparison altogether:

--8<---cut here---start->8---
Disassembly of  at #x29e0:

   0(instrument-entry 15700)  at 
shepherd/scripts/herd.scm:127:2
   2(assert-nargs-ee/locals 1 11)   ;; 12 slots (0 args)
   3(static-ref 10 15369)   ;; #f at 
shepherd/scripts/herd.scm:128:19
   5(immediate-tag=? 10 7 0);; heap-object?
   7(je 9)  ;; -> L1
   8(static-ref 10 14166)   ;; #f
  10(static-ref 9 15372);; open-connection
  12(call-scm<-scm-scm 10 10 9 111) 
  14(static-set! 10 15358)  ;; #f
L1:
  16(scm-ref/immediate 7 10 1)  
  17(scm-ref/immediate 6 11 2)  
  18(handle-interrupts)   at 
shepherd/scripts/herd.scm:128:18
  19(call 4 2)  
  21(receive 1 4 12)
  23(scm-ref/immediate 9 11 3)  
  24(static-ref 8 15360);; #f at 
shepherd/scripts/herd.scm:134:6
  26(immediate-tag=? 8 7 0) ;; heap-object?
  28(je 9)  ;; -> L2
  29(static-ref 8 14145);; #f
  31(static-ref 7 15363);; write-command
  33(call-scm<-scm-scm 8 8 7 111)   
  35(static-set! 8 15349)   ;; #f
L2:
  37(scm-ref/immediate 8 8 1)   
  38(static-ref 7 15358);; #f at 
shepherd/scripts/herd.scm:134:21
  40(immediate-tag=? 7 7 0) ;; heap-object?
  42(je 9)  ;; -> L3
  43(static-ref 7 14131);; #f
  45(static-ref 6 15361);; shepherd-command
  47(call-scm<-scm-scm 7 7 6 111)   
  49(static-set! 7 15347)   ;; #f
L3:
  51(scm-ref/immediate 7 7 1)   
  52(scm-ref/immediate 6 11 4)  
  53(static-ref 5 15363);; root
  55(eq? 6 5)   
  56(je 5)  ;; -> L4
  57(static-ref 5 13655);; shepherd
  59(eq? 6 5)   
  60(jne 3) ;; -> L5
L4:
  61(static-ref 9 15365);; status at 
shepherd/scripts/herd.scm:131:22
L5:
  63(static-ref 1 15375);; #:argumentsat 
shepherd/scripts/herd.scm:134:54
  65(scm-ref/immediate 0 11 5)  
  66(mov 4 7) at 
shepherd/scripts/herd.scm:134:20
--8<---cut here---end--->8---

(This is compiled with 3.0.7 and the default optimizations, so -O2.)

To be continued…

Ludo’.

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Andrew Tropin]

> > In other words, no particular thought was given to -pkg.el. It was
> > simply dropped along with many other files. So, if consensus is
> > reachedthat keeping -pkg.el is a good idea, there is no reason to not
> > do that.
> Thanks for clearing that up.  In that case, I don't have any qualms
> about including them either.

Cool, seems we can get -pkg.el files back.

> Multi-profile Emacs should be supported, but this also breaks on
> foreign distros with foreign distro ELPA.  Again, hacking variables is
> not the solution (and even if it was, it'd be better to patch the emacs
> default value, not that this is a good idea either).

Yep, the last snippet supports multi-profile Emacs.  Installing packages
for Emacs via a few different package manager sounds like a very bad
practice) I agree that current implementation with updating variables
isn't perfect and it doesn't cover the use case, which I expect to be
rare (packages from Guix will be listed in list-packages, files from
foreign distro PM won't).  I can dive into package.el implementation and
spend some time next week providing a different workaround.

BTW, can you remind me why we do not place packages under
site-lisp/elpa/NAME-VERSION? It seems almost the same as
site-lisp/NAME-VERSION, but everything related to describe-package and
other functions will work out of the box.  This way it will work even
with a foreign distro use case.

bug#48595: `guix install mes` fails in 'check'-phase

[Gabriel Wicki]

i tried running `guix install mes` which fails on my x86_64 debian
machine. CI fails as well
(https://ci.guix.gnu.org/build/286577/details).

log output shows a couple of segmentation faults and an undefined
variable in phase 'check':

test/test10/hello.sh
+ '[' amd64 = amd64 ']'
+ ./test/results/test1-binary
+ . ./sha256.sh
++ set -ex
test/test1/hello.sh: line 37:   171 Segmentation fault  
./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1
+ '[' amd64 = x86 ']'
+ exit 0
make: *** [makefile:104: test1-binary] Error 139
[...]
test/test7/hello.sh: line 31:   175 Segmentation fault  
./test/results/test7-binary test/test7/hex1.hex1 > test/test7/proof
[...]
test/test3/hello.sh: line 23: GET_MACHINE_FLAGS: unbound variable

bug#48587: Amule 2.3.3

[Emanuele M. Monterosso]

Amule has released version 2.3.3 a few months back fixing some bugs and
preventing some of the more commonly encountered crashes. Something in
the build system has changed, I believe pkg-config and thus guix fails
to automatically build it.
--
Emanuele M. Monterosso