bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

[Leo Famulari]

For the sake of trying something, I'm going to try patching fontconfig
with this patch that other distros (Debian and Arch) are using:

https://salsa.debian.org/freedesktop-team/fontconfig/-/blob/master/debian/patches/do_not_remove_uuid.patch

I don't know how fontconfig works but that patch fixed serious problems
on those distros, yet it hasn't been released by fontconfig yet.

bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

[Leo Famulari]

On Fri, May 08, 2020 at 03:08:53AM +0200, Tobias Geerinckx-Rice wrote:
> > /var/cache/fontconfig: not cleaning unwritable cache directory
> 
> This is certainly a classic.  Have you tried deleting this stale directory?
> Guix System does so for you, I suppose Debian does not.  It doesn't jive
> with unprivileged package management.

Yes, it didn't make a difference for my fonts problem, or for fc-cache
itself:

--
$ fc-cache -rfv
/gnu/store/hbqlzgd8hcf6ndcmx7q7miqrsxb4dmkk-gs-fonts-8.11/share/fonts: caching, 
new cache contents: 0 fonts, 1 dirs
/gnu/store/hbqlzgd8hcf6ndcmx7q7miqrsxb4dmkk-gs-fonts-8.11/share/fonts/type1: 
caching, new cache contents: 0 fonts, 1 dirs
/gnu/store/hbqlzgd8hcf6ndcmx7q7miqrsxb4dmkk-gs-fonts-8.11/share/fonts/type1/ghostscript:
 caching, new cache contents: 35 fonts, 0 dirs
/home/leo/.guix-profile/share/fonts: caching, new cache contents: 0 fonts, 2 
dirs
/home/leo/.guix-profile/share/fonts/misc: caching, new cache contents: 3 fonts, 
0 dirs
/home/leo/.guix-profile/share/fonts/truetype: caching, new cache contents: 30 
fonts, 0 dirs
/run/current-system/profile/share/fonts: skipping, no such directory
/home/leo/.local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs
/home/leo/.local/share/fonts: failed to write cache
/home/leo/.fonts: caching, new cache contents: 0 fonts, 0 dirs
/home/leo/.fonts: failed to write cache
/gnu/store/hbqlzgd8hcf6ndcmx7q7miqrsxb4dmkk-gs-fonts-8.11/share/fonts/type1: 
skipping, looped directory detected
/home/leo/.guix-profile/share/fonts/misc: skipping, looped directory detected
/home/leo/.guix-profile/share/fonts/truetype: skipping, looped directory 
detected
/gnu/store/hbqlzgd8hcf6ndcmx7q7miqrsxb4dmkk-gs-fonts-8.11/share/fonts/type1/ghostscript:
 skipping, looped directory detected
/var/cache/fontconfig: not cleaning non-existent cache directory
/home/leo/.cache/fontconfig: cleaning cache directory
/home/leo/.fontconfig: not cleaning non-existent cache directory
fc-cache: failed
--

I doubt it's related to my main report, which is that things used to
"just work" to the degree that I never used fc-cache before.

bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

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

Leo,

Leo Famulari 写道：
I tried `fc-cache -rv`. Using Debian's fc-cache, it looks like 
this:

[...]

/var/cache/fontconfig: not cleaning unwritable cache directory



And with Guix's fc-cache:

[...]

/var/cache/fontconfig: not cleaning unwritable cache directory


This is certainly a classic.  Have you tried deleting this stale 
directory?  Guix System does so for you, I suppose Debian does 
not.  It doesn't jive with unprivileged package management.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

[Leo Famulari]

I'm having trouble with Guix packages using fonts from my Debian 10
system after a core-updates merge.

Using Inkscape from core-updates, the text I put in my SVG files fails
to display. When I look at the Inkscape 'Text and Font' tool, it shows
my chosen font with a red line through it, as though it can't find it.

It's similar with Hexchat; it no longer sees most of the fonts installed
by Debian.

The specific fonts in question are the URW fonts, aka the "PostScript
fonts", provided by Debian's gsfonts and gsfonts-x11 packages.

I tried `fc-cache -rv`. Using Debian's fc-cache, it looks like this:

--
$ fc-cache -rv
/usr/share/fonts: caching, new cache contents: 0 fonts, 6 dirs
/usr/share/fonts/X11: caching, new cache contents: 0 fonts, 6 dirs
/usr/share/fonts/X11/100dpi: caching, new cache contents: 358 fonts, 0 dirs
/usr/share/fonts/X11/75dpi: caching, new cache contents: 358 fonts, 0 dirs
/usr/share/fonts/X11/Type1: caching, new cache contents: 43 fonts, 0 dirs
/usr/share/fonts/X11/encodings: caching, new cache contents: 0 fonts, 1 dirs
/usr/share/fonts/X11/encodings/large: caching, new cache contents: 0 fonts, 0 
dirs
/usr/share/fonts/X11/misc: caching, new cache contents: 92 fonts, 0 dirs
/usr/share/fonts/X11/util: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/cMap: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/cmap: caching, new cache contents: 0 fonts, 5 dirs
/usr/share/fonts/cmap/adobe-cns1: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/cmap/adobe-gb1: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/cmap/adobe-japan1: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/cmap/adobe-japan2: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/cmap/adobe-korea1: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/opentype: caching, new cache contents: 0 fonts, 1 dirs
/usr/share/fonts/opentype/mathjax: caching, new cache contents: 24 fonts, 0 dirs
/usr/share/fonts/truetype: caching, new cache contents: 1 fonts, 8 dirs
/usr/share/fonts/truetype/anonymous-pro: caching, new cache contents: 4 fonts, 
0 dirs
/usr/share/fonts/truetype/dejavu: caching, new cache contents: 22 fonts, 0 dirs
/usr/share/fonts/truetype/droid: caching, new cache contents: 1 fonts, 0 dirs
/usr/share/fonts/truetype/lato: caching, new cache contents: 18 fonts, 0 dirs
/usr/share/fonts/truetype/liberation: caching, new cache contents: 16 fonts, 0 
dirs
/usr/share/fonts/truetype/noto: caching, new cache contents: 1 fonts, 0 dirs
/usr/share/fonts/truetype/unifont: caching, new cache contents: 4 fonts, 0 dirs
/usr/share/fonts/truetype/vlgothic: caching, new cache contents: 2 fonts, 0 dirs
/usr/share/fonts/type1: caching, new cache contents: 0 fonts, 1 dirs
/usr/share/fonts/type1/gsfonts: caching, new cache contents: 35 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts: skipping, no such directory
/usr/local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs
/home/leo/.local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs
/home/leo/.fonts: caching, new cache contents: 0 fonts, 0 dirs
/usr/share/fonts/X11: skipping, looped directory detected
/usr/share/fonts/cMap: skipping, looped directory detected
/usr/share/fonts/cmap: skipping, looped directory detected
/usr/share/fonts/opentype: skipping, looped directory detected
/usr/share/fonts/truetype: skipping, looped directory detected
/usr/share/fonts/type1: skipping, looped directory detected
/usr/share/fonts/X11/100dpi: skipping, looped directory detected
/usr/share/fonts/X11/75dpi: skipping, looped directory detected
/usr/share/fonts/X11/Type1: skipping, looped directory detected
/usr/share/fonts/X11/encodings: skipping, looped directory detected
/usr/share/fonts/X11/misc: skipping, looped directory detected
/usr/share/fonts/X11/util: skipping, looped directory detected
/usr/share/fonts/cmap/adobe-cns1: skipping, looped directory detected
/usr/share/fonts/cmap/adobe-gb1: skipping, looped directory detected
/usr/share/fonts/cmap/adobe-japan1: skipping, looped directory detected
/usr/share/fonts/cmap/adobe-japan2: skipping, looped directory detected
/usr/share/fonts/cmap/adobe-korea1: skipping, looped directory detected
/usr/share/fonts/opentype/mathjax: skipping, looped directory detected
/usr/share/fonts/truetype/anonymous-pro: skipping, looped directory detected
/usr/share/fonts/truetype/dejavu: skipping, looped directory detected
/usr/share/fonts/truetype/droid: skipping, looped directory detected
/usr/share/fonts/truetype/lato: skipping, looped directory detected
/usr/share/fonts/truetype/liberation: skipping, looped directory detected
/usr/share/fonts/truetype/noto: skipping, looped directory detected
/usr/share/fonts/truetype/unifont: skipping, looped directory detected
/usr/share/fonts/truetype/vlgothic: skipping, looped directory detected
/usr/share/fonts/type1/gsfonts: skipping, looped directory detected
/usr/share/fonts/X11/encodings/large: skipping, looped directory detected

bug#41115: warsow-qfusion bundles compiled software, third party sources

[Ricardo Wurmus]

Thanks.  Closing.

-- 
Ricardo

bug#39894: [Common Lisp] asdf-build-system/source should refer to dependencies in the store

[Pierre Neidhardt]

I made a mistaken in the original post:  the cl-* (source) packages do
propagate their input.  So source packages _do_ work as expected.

What we'd like to do improve here is _not_ propagate the inputs and
instead refer directly to them in the store.

I tried generating and .asd which would do the following

--8<---cut here---start->8---
(asdf:load-asd ORIGINAL-ASD)

(push INPUT-PATH-TO-SOURCE asdf:*central-registry*)
; more push of all inputs here.
--8<---cut here---end--->8---

The problem is that we can't name the .asd like the original or ASDF
will complain about circular dependencies.

The only way I can think about is to add the "push" lines to the
original .asd itself (at the end should be fine).  Not sure how I feel
about modifying the original .asd, seems brittle.

There may be a better way.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#41123: shepherd exits for no good reason

[Mathieu Othacehe]

Hey Ludo,

> May  7 09:36:52 localhost shepherd[1]: Exiting shepherd... 
> May  7 09:36:52 localhost shepherd[1]: Service xorg-server has been stopped. 
> May  7 09:36:52 localhost shepherd[1]: Service console-font-tty2 has been 
> stopped. 
> May  7 09:36:52 localhost shepherd[1]: Service term-tty2 has been stopped. 
> May  7 09:36:52 localhost shepherd[1]: Service upower-daemon has been 
> stopped. 
> May  7 09:36:52 localhost shepherd[1]: Service elogind has been stopped. 
> May  7 09:36:52 localhost ntpd[482]: ntpd exiting on signal 15 (Terminated)
> May  7 09:36:52 localhost syslogd: exiting on signal 15
>
> The end result was a kernel panic with exitcode=0x100 (meaning exited
> with 1).
>
> It looks as though one had run ‘herd stop root’.

It could be related to this bug[1]. The problem is that on 0.8.0 a
process restart can cause a root-service stop.

On your log, I can't see a process being restarted, so it might also be
unrelated.

Mathieu

[1]: https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00085.html

bug#40981: Graphical installer tests sometimes hang.

[Mathieu Othacehe]

Hello,

The previous patch was not working. The reason is that, when a process
is forked and before execv is called, it shares the parent signal
handler.

So when sending a SIGTERM to the child process, we are stopping
root-service, if the signal is received before the child has forked.

The work-around here is to save the installed SIGTERM handler and reset
it. Then, after forking, the parent can restore the SIGTERM handler. The
child will use the default SIGTERM handler that terminates the process.

WDYT?

Thanks,

Mathieu
>From aa6f67068f1fdd622673ec0223f05fd8f8a96baa Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Thu, 7 May 2020 18:39:41 +0200
Subject: [PATCH] service: Fix 'make-kill-destructor' when PGID is zero.

When a process is forked, and before its GID is changed in "exec-command",
it will share the parent GID, which is 0 for Shepherd. In that case, use
the PID instead of the PGID.

Also make sure to reset the SIGTERM handler before forking a process. Failing
to do so, will result in stopping Shepherd if a SIGTERM is received between
fork and execv calls. Restore the SIGTERM handler once the process has been
forked.

* modules/shepherd/service.scm (fork+exec-command): Save the current SIGTERM
handler and reset it before forking. Then, restore it on the parent after
forking.
(make-kill-destructor): Handle the case when PGID is zero, between the process
fork and exec.
---
 modules/shepherd/service.scm | 36 +---
 tests/forking-service.sh | 18 ++
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index 8604d2f..c68d7e0 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -5,6 +5,7 @@
 ;; Copyright (C) 2016 Alex Kost 
 ;; Copyright (C) 2018 Carlo Zancanaro 
 ;; Copyright (C) 2019 Ricardo Wurmus 
+;; Copyright (C) 2020 Mathieu Othacehe 
 ;;
 ;; This file is part of the GNU Shepherd.
 ;;
@@ -884,7 +885,18 @@ its PID."
   (unless %sigchld-handler-installed?
 (sigaction SIGCHLD handle-SIGCHLD SA_NOCLDSTOP)
 (set! %sigchld-handler-installed? #t))
-  (let ((pid (primitive-fork)))
+
+  ;; When forking a process, the signal handlers are inherited, until it
+  ;; forks. If SIGTERM is received by the forked process, before it calls
+  ;; execv, the installed SIGTERM handler, stopping Shepherd will be called.
+  ;; To avoid this, save the SIGTERM handler, disable it, and restore it once,
+  ;; the process has been forked. This way, the forked process will use the
+  ;; default SIGTERM handler stopping the process.
+  (let ((term-handler (match (sigaction SIGTERM)
+((proc . _)
+ proc)))
+(pid (and (sigaction SIGTERM SIG_DFL)
+  (primitive-fork
 (if (zero? pid)
 (exec-command command
   #:user user
@@ -893,7 +905,10 @@ its PID."
   #:directory directory
   #:file-creation-mask file-creation-mask
   #:environment-variables environment-variables)
-pid)))
+(begin
+  ;; Restore the initial SIGTERM handler.
+  (sigaction SIGTERM term-handler)
+  pid
 
 (define* (make-forkexec-constructor command
 #:key
@@ -957,11 +972,18 @@ start."
   "Return a procedure that sends SIGNAL to the process group of the PID given
 as argument, where SIGNAL defaults to `SIGTERM'."
   (lambda (pid . args)
-;; Kill the whole process group PID belongs to.  Don't assume that PID
-;; is a process group ID: that's not the case when using #:pid-file,
-;; where the process group ID is the PID of the process that
-;; "daemonized".
-(kill (- (getpgid pid)) signal)
+;; Kill the whole process group PID belongs to.  Don't assume that PID is
+;; a process group ID: that's not the case when using #:pid-file, where
+;; the process group ID is the PID of the process that "daemonized".  If
+;; this procedure is called, between the process fork and exec, the PGID
+;; will still be zero (the Shepherd PGID). In that case, use the PID.
+(let ((current-pgid (getpgid 0))
+  (pgid (getpgid pid)))
+  (if (eq? pgid current-pgid)
+  (begin
+(kill pid signal))
+  (begin
+(kill (- pgid) signal
 #f))
 
 ;; Produce a constructor that executes a command.
diff --git a/tests/forking-service.sh b/tests/forking-service.sh
index 7126c3d..47b09a2 100644
--- a/tests/forking-service.sh
+++ b/tests/forking-service.sh
@@ -71,6 +71,17 @@ cat > "$conf"<
+   ;; A service that forks into a different process.
+   #:provides '(test3)
+   #:start (make-forkexec-constructor %command3)
+   #:stop  (make-kill-destructor)
+   #:respawn? #t))
 EOF
 cat $conf
 
@@ -113,3 +124,10 @@ sleep 1;
 $herd status test2 | grep started
 test "`cat $PWD/$service2_started`" = "started
 started"

bug#41116: Guix deploy fails with new version of Herd

[Alex Sassmannshausen via Bug reports for GNU Guix]

Hi Marius,

Marius Bakke  writes:

> Hi Alex,
>
> [...]
>
> This issue has been reported by a number of users on IRC.  I think the
> problem is that the the #:file-creation-mask keyword requires support
> from the running Shepherd, which may not have it yet.  I think we should
> revert commit 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec until we find a
> smooth upgrade path.  Can you try it and push if that fixes guix deploy?

I believe Ludovic has now done this.  I will test and close this bug
if it is now working.

Cheers,

Alex

bug#41120: uvesafb service is unsupported on aarch64

[pelzflorian (Florian Pelz)]

On Thu, May 07, 2020 at 04:55:13PM +0200, pelzflorian (Florian Pelz) wrote:
> I have more success with moving the file-exists check into the
> #~(lambda …) like the attached patch.

Sorry I forgot to git add.  This is the patch.
>From f88b1b487d48c959a7ed00d6032ccfe05aa81f0e Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 7 May 2020 13:26:19 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] installer: Do not load uvesafb on non-x86 install images.

Fixes .
Suggested by Efraim Flashner .

* gnu/system/install.scm (uvesafb-shepherd-service): Do not build x86-only
v86d helper unconditionally.
---
 gnu/system/install.scm | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 6435c1bff4..952dee464f 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -299,16 +299,18 @@ the user's target storage device rather than on the RAM 
disk."
  (documentation "Load the uvesafb kernel module if needed.")
  (provision '(maybe-uvesafb))
  (requirement '(file-systems))
- (start #~(lambda ()
-;; uvesafb is only supported on x86 and x86_64.
-(or (not (and (string-suffix? "linux-gnu" %host-type)
-  (or (string-prefix? "x86_64" %host-type)
-  (string-prefix? "i686" %host-type
-(file-exists? "/dev/fb0")
-(invoke #+(file-append kmod "/bin/modprobe")
-"uvesafb"
-(string-append "v86d=" #$v86d "/sbin/v86d")
-"mode_option=1024x768"
+ (start
+   (if (and (string-suffix? "linux-gnu" %host-type)
+(or (string-prefix? "x86_64" %host-type)
+(string-prefix? "i686" %host-type)))
+   #~(lambda ()
+   ;; uvesafb is only supported on x86 and x86_64.
+   (or (file-exists? "/dev/fb0")
+   (invoke #+(file-append kmod "/bin/modprobe")
+   "uvesafb"
+   (string-append "v86d=" #$v86d "/sbin/v86d")
+   "mode_option=1024x768")))
+   #~(lambda () #t)))
  (respawn? #f)
  (one-shot? #t
 
-- 
2.26.1

bug#41120: uvesafb service is unsupported on aarch64

[pelzflorian (Florian Pelz)]

On Thu, May 07, 2020 at 11:12:34AM +0300, Efraim Flashner wrote:
> I haven't tested the produced image, but the following builds without
> trying to also build v86d
> 
>  (start
>(if (and (and (string-suffix? "linux-gnu" %host-type)
>  (or (string-prefix? "x86_64" %host-type)
>  (string-prefix? "i686" %host-type)))
> (file-exists? "/dev/fb0"))
>  #~(lambda ()
>  ;; uvesafb is only supported on x86 and x86_64.
>  (invoke #+(file-append kmod "/bin/modprobe")
>  "uvesafb"
>  (string-append "v86d=" #$v86d "/sbin/v86d")
>  "mode_option=1024x768"))
>  #~(lambda () #t)))

This way uvesafb is started unconditionally on x86_64, even when it is
not needed, leading to video corruption on some boots in QEMU.

I have more success with moving the file-exists check into the
#~(lambda …) like the attached patch.  But I’m not sure it really
fixes ARM builds.

I tested via

qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm -nic user,model=virtio-net-pci 
-boot menu=on,order=d -drive 
media=cdrom,file=/gnu/store/0cgbp4y7awk4spg49ajw077xyzk24fi0-iso9660-image

and on hardware.  With QEMU, uvesafb is needed if and only if
nomodeset is passed as a kernel parameter.

Now how to build an ARM image for QEMU?

Sorry I left such a mess with uvesafb.

Regards,
Florian
>From 13fd2b590e37095ed4213d7bb85422b48deab9c6 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 7 May 2020 13:26:19 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] installer: Do not load uvesafb on non-x86 install images.

Fixes .
Suggested by Efraim Flashner .

* gnu/system/install.scm (uvesafb-shepherd-service): Do not build x86-only
v86d helper unconditionally.
---
 gnu/system/install.scm | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index 6435c1bff4..ad8a84091c 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -299,16 +299,18 @@ the user's target storage device rather than on the RAM 
disk."
  (documentation "Load the uvesafb kernel module if needed.")
  (provision '(maybe-uvesafb))
  (requirement '(file-systems))
- (start #~(lambda ()
-;; uvesafb is only supported on x86 and x86_64.
-(or (not (and (string-suffix? "linux-gnu" %host-type)
-  (or (string-prefix? "x86_64" %host-type)
-  (string-prefix? "i686" %host-type
-(file-exists? "/dev/fb0")
-(invoke #+(file-append kmod "/bin/modprobe")
-"uvesafb"
-(string-append "v86d=" #$v86d "/sbin/v86d")
-"mode_option=1024x768"
+ (start
+   (if (and (and (string-suffix? "linux-gnu" %host-type)
+ (or (string-prefix? "x86_64" %host-type)
+ (string-prefix? "i686" %host-type)))
+(file-exists? "/dev/fb0"))
+ #~(lambda ()
+ ;; uvesafb is only supported on x86 and x86_64.
+ (invoke #+(file-append kmod "/bin/modprobe")
+ "uvesafb"
+ (string-append "v86d=" #$v86d "/sbin/v86d")
+ "mode_option=1024x768"))
+ #~(lambda () #t)))
  (respawn? #f)
  (one-shot? #t
 
-- 
2.26.1

bug#41116: Guix deploy fails with new version of Herd

[Diego Nicola Barbato]

Hey,

Ludovic Courtès  writes:

> Hello Alex & Marius,
>
> Marius Bakke  skribis:
>
>> Alex Sassmannshausen via Bug reports for GNU Guix 
>> writes:
>>
>>> Hello,
>>>
>>> I maintain a number of servers using Guix deploy.  It seems that the
>>> recent upgrade to Herd in Guix, and specifically commit
>>> 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec might have introduced a bug.
>>>
>>> From my testing, guix deploy currently consistently fails with:
>>> -8<->8---
>>> ice-9/boot-9.scm:1667:16: In procedure raise-exception:
>>> ERROR:
>>>   1. :
>>>   arguments: (srfi-34 #>>  [service: root action: eval key: 
>>> keyword-argument-error args: ("#>> shepherd/service.scm:903:4 (command #:key user group directory 
>>> environment-variables pid-file pid-file-timeout log-file) | (program . 
>>> program-args)>" "Unrecognized keyword" () (#:file-creation-mask))] 
>>> 7eff2bd7be00>>)
>>>   inferior: #f
>>>   stack: ()
>>> -8<->8---
>>>
>>> A workaround is to build the system configuration locally on the target
>>> server, then to reconfigure.  It will still error at the same place, but
>>> at this point, after restarting the server, the new version of Herd will
>>> be running and both deploy and reconfigure will work.
>>>
>>> I don't know what a good solution to this could be, but it may be
>>> something we need to consider in future development of Herd.
>>
>> This issue has been reported by a number of users on IRC.  I think the
>> problem is that the the #:file-creation-mask keyword requires support
>> from the running Shepherd, which may not have it yet.  I think we should
>> revert commit 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec until we find a
>> smooth upgrade path.  Can you try it and push if that fixes guix deploy?
>
> I’ve reverted the patch in 5aa4d2dcf2f4f8786358feb45338893ed08a4cd9.
>
> Diego: I guess we can reinstate the patch “later”, once Shepherd 0.8 can
> be considered widespread.

I'm sorry I broke reconfigure and deploy.  I didn't consider testing
upgrading from before Shepherd 0.8 to after my change and I didn't even
think of deploy.  Going forth I'll leave messing with core functionality
to the pros.

> More importantly, we should handle service reload failures more
> gracefully, as proposed in ,
> for both ‘reconfigure’ and ‘deploy’.

Regards,

Diego

bug#41116: Guix deploy fails with new version of Herd

[Ludovic Courtès]

Hello Alex & Marius,

Marius Bakke  skribis:

> Alex Sassmannshausen via Bug reports for GNU Guix 
> writes:
>
>> Hello,
>>
>> I maintain a number of servers using Guix deploy.  It seems that the
>> recent upgrade to Herd in Guix, and specifically commit
>> 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec might have introduced a bug.
>>
>> From my testing, guix deploy currently consistently fails with:
>> -8<->8---
>> ice-9/boot-9.scm:1667:16: In procedure raise-exception:
>> ERROR:
>>   1. :
>>   arguments: (srfi-34 #>  [service: root action: eval key: 
>> keyword-argument-error args: ("#> shepherd/service.scm:903:4 (command #:key user group directory 
>> environment-variables pid-file pid-file-timeout log-file) | (program . 
>> program-args)>" "Unrecognized keyword" () (#:file-creation-mask))] 
>> 7eff2bd7be00>>)
>>   inferior: #f
>>   stack: ()
>> -8<->8---
>>
>> A workaround is to build the system configuration locally on the target
>> server, then to reconfigure.  It will still error at the same place, but
>> at this point, after restarting the server, the new version of Herd will
>> be running and both deploy and reconfigure will work.
>>
>> I don't know what a good solution to this could be, but it may be
>> something we need to consider in future development of Herd.
>
> This issue has been reported by a number of users on IRC.  I think the
> problem is that the the #:file-creation-mask keyword requires support
> from the running Shepherd, which may not have it yet.  I think we should
> revert commit 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec until we find a
> smooth upgrade path.  Can you try it and push if that fixes guix deploy?

I’ve reverted the patch in 5aa4d2dcf2f4f8786358feb45338893ed08a4cd9.

Diego: I guess we can reinstate the patch “later”, once Shepherd 0.8 can
be considered widespread.

More importantly, we should handle service reload failures more
gracefully, as proposed in ,
for both ‘reconfigure’ and ‘deploy’.

Thanks,
Ludo’.

bug#41123: shepherd exits for no good reason

[Ludovic Courtès]

Hello,

I witnessed a case with Shepherd 0.8.0 on ‘core-updates’
(7b07852ddb334c92bcef69666f21c599f1f0fa79) where shepherd exited all by
itself, all of a sudden.  Here’s what /var/log/messages shows:

--8<---cut here---start->8---
May  7 09:36:23 localhost vmunix: [   20.316829] shepherd[1]: Service 
user-homes has been started.
May  7 09:36:23 localhost vmunix: [   21.319625] shepherd[1]: Service nscd has 
been started.
May  7 09:36:23 localhost vmunix: [   21.321029] shepherd[1]: Service 
guix-daemon has been started.

[…]

May  7 09:36:52 localhost shepherd[1]: Exiting shepherd... 
May  7 09:36:52 localhost shepherd[1]: Service xorg-server has been stopped. 
May  7 09:36:52 localhost shepherd[1]: Service console-font-tty2 has been 
stopped. 
May  7 09:36:52 localhost shepherd[1]: Service term-tty2 has been stopped. 
May  7 09:36:52 localhost shepherd[1]: Service upower-daemon has been stopped. 
May  7 09:36:52 localhost shepherd[1]: Service elogind has been stopped. 
May  7 09:36:52 localhost ntpd[482]: ntpd exiting on signal 15 (Terminated)
May  7 09:36:52 localhost syslogd: exiting on signal 15
--8<---cut here---end--->8---

The end result was a kernel panic with exitcode=0x100 (meaning exited
with 1).

It looks as though one had run ‘herd stop root’.

Ludo’.

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

[zimoun]

Hi Ludo,

On Thu, 7 May 2020 at 10:13, Ludovic Courtès  wrote:

> Given the enthusiasm expressed on IRC, I went ahead and pushed.  :-)
>
>   ff3ca7979e channels: Add patch for .
>   053b10c3ef channels: Add mechanism to patch checkouts of the 'guix channel.
>   4ba425060a channels: Add 'latest-channel-instance'.

Just to be sure to well-understand: the versions before 05e783 were
broken (guix build failed) and the proposed in-place mechanism is a
way to fix them, right?
If yes, that's awesome!


Cheers,
simon

bug#41120: uvesafb service is unsupported on aarch64

[Efraim Flashner]

On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote:
> 
> Hello Efraim,
> 
> > the uvesafb-service which was added to the installation image isn't
> > supported on aarch64 (or probably any non-x86 system) and causes the
> > creation of an installation image to fail.
> 
> Thanks for reporting. There's this small snippet in uvesafb-service:
> 
> --8<---cut here---start->8---
>   (or (not (and (string-suffix? "linux-gnu" %host-type)
> (or (string-prefix? "x86_64" %host-type)
> (string-prefix? "i686" %host-type
> --8<---cut here---end--->8---
> 
> which must then fail? Do you have a specific error message?
> 

I haven't tested the produced image, but the following builds without
trying to also build v86d

 (start
   (if (and (and (string-suffix? "linux-gnu" %host-type)
 (or (string-prefix? "x86_64" %host-type)
 (string-prefix? "i686" %host-type)))
(file-exists? "/dev/fb0"))
 #~(lambda ()
 ;; uvesafb is only supported on x86 and x86_64.
 (invoke #+(file-append kmod "/bin/modprobe")
 "uvesafb"
 (string-append "v86d=" #$v86d "/sbin/v86d")
 "mode_option=1024x768"))
 #~(lambda () #t)))

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Hey!

Ludovic Courtès  skribis:

> The attached patches add a mechanism to patch the Guix source tree, and
> then use that mechanism to add the missing (ice-9 threads) import.  With
> this I can do:
>
>   ./pre-inst-env guix time-machine \
>  --commit=e02c2f85b36ce1c733bd908a210ce1182bdd2560 -- build linux-libre
>
> … which is a simple way to do what the manifest above was about.

Given the enthusiasm expressed on IRC, I went ahead and pushed.  :-)

  ff3ca7979e channels: Add patch for .
  053b10c3ef channels: Add mechanism to patch checkouts of the 'guix channel.
  4ba425060a channels: Add 'latest-channel-instance'.

So… it might be that today is merge day?

Ludo’.

bug#41120: uvesafb service is unsupported on aarch64

[Efraim Flashner]

On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote:
> 
> Hello Efraim,
> 
> > the uvesafb-service which was added to the installation image isn't
> > supported on aarch64 (or probably any non-x86 system) and causes the
> > creation of an installation image to fail.
> 
> Thanks for reporting. There's this small snippet in uvesafb-service:
> 
> --8<---cut here---start->8---
>   (or (not (and (string-suffix? "linux-gnu" %host-type)
> (or (string-prefix? "x86_64" %host-type)
> (string-prefix? "i686" %host-type
> --8<---cut here---end--->8---
> 
> which must then fail? Do you have a specific error message?
> 

It fails while building v86d. Looking at the or statement, it should
probably close after (file-exists? "/dev/fb0") and then the whole thing
wrapped in a when or an if. I checked and /dev/fb0 doesn't exist on my
machine.

Actually that didn't make a difference, it still tried to build v86d.
Even changing the '(or (not' to '(if (and (and' it still tries to build
v86d. My guess is that it's not evaluating the conditionals until it's
time to run the service so it makes sure v86d is there.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#41120: uvesafb service is unsupported on aarch64

[Mathieu Othacehe]

Hello Efraim,

> the uvesafb-service which was added to the installation image isn't
> supported on aarch64 (or probably any non-x86 system) and causes the
> creation of an installation image to fail.

Thanks for reporting. There's this small snippet in uvesafb-service:

--8<---cut here---start->8---
  (or (not (and (string-suffix? "linux-gnu" %host-type)
(or (string-prefix? "x86_64" %host-type)
(string-prefix? "i686" %host-type
--8<---cut here---end--->8---

which must then fail? Do you have a specific error message?

Thanks,

Mathieu

bug#41121: (Keyboard-layout) form does not work "across the board"

[o . rojon]

Hej guys,

so I hope this actually is a bug and not something not yet implemented 
or a misunderstanding on my part.


In the process of changing my login manager to slim (over gdm), I 
noticed that the (keyboard-layout ...) form does not work the same way 
in the (bootloader)/(set-xorg-configuration) and the 
(slim-configuration) form. While in the former cases, (keyboard-layout 
keyboard-layout) uses the string I inputted in the beginning of the 
config file, an error is thrown when I try to do the same in the 
(slim-configuration) form (error 1). When I simply use (service 
slim-service-type) and try to supplement via (set-xorg-configuration), 
an error is thrown as well (error 2).


Have a good day folks, guix rules :)

### The errors (with my shabby translations)
1) user@computer ~$ sudo guix system reconfigure 
src/guix-config/os-desktop.scm

Passwort:
guix system: error: „src/guix-config/os-desktop.scm“ could not be 
loaded: /home/user/src/guix-config/os-desktop.scm:68:30: Wrong type to 
apply: #< name: "de" variant: #f model: #f options: ()>


2) user@computer ~$ sudo guix system reconfigure 
src/guix-config/os-desktop.scm

guix system: error: Der Dienst „xorg-server“ kommt mehr als einmal vor


### The config file (note that some parens might be unbalanced because I 
tried to remove the "unnecessary" stuff)

(use-modules (gnu)
 (srfi srfi-1))

(use-service-modules desktop networking ssh xorg)

(use-package-modules disk llvm linux ncdu xorg less gnome fonts 
display-managers lxqt syncthing
		 version-control emacs emacs-xyz tex cups video gstreamer gnuzilla 
web-browsers

 messaging mail rsync suckless pdf curl databases hardware 
wm)

(operating-system
  (locale "de_DE.utf8")
  (timezone "Europe/Berlin")
  (keyboard-layout (keyboard-layout "de"))
  (host-name "computer")
  (users (cons* (user-account
  (name "user")
  (comment "")
  (group "users")
  (home-directory "/home/hapster")
  (supplementary-groups
'("wheel" "netdev" "audio" "video")))
%base-user-accounts))
  (packages
(append
  (map specification->package
'(
  PACKAGES
))
  %base-packages))

   "alternative" Konfiguration
  (services (cons* (service slim-service-type)
;; (slim-configuration
;;  (xorg-configuration
;;   (keyboard-layout keyboard-layout
   ;; (set-xorg-configuration
   ;;  (xorg-configuration
   ;;   (keyboard-layout keyboard-layout)))
   (remove (lambda (service)
 (eq? (service-kind service) gdm-service-type))
   %desktop-services)))
  (bootloader
(bootloader-configuration
  (bootloader grub-bootloader)
  (target "/dev/sdX")
  (keyboard-layout keyboard-layout)))
  (file-systems
(cons*
   FILESYSTEMS
   %base-file-systems)))

bug#39527: A new information on LXQt DE not "logging in"

[o . rojon]

Hello guys,

I have come to realise something which might be of interest, but which 
might also be something which is well known to you.


When trying to launch LXQt from the GDM login/session manager, the 
screen just went blank and nothing happened. This is why I assumed "it 
simply doesnt work". Now I have switched to another login manager, and 
logging in to LXQt works - only that I am directly prompted to specify 
which WM I wanted to use. I was unable to locate one under /usr/bin 
(only /usr/bin/env seems to live there) and thus had to go to the 
/gnu/store directory.


So I assume that the problem might either be a "personal one" where I 
have forgotten to set some path (even though I have not received a 
particular warning of sorts). Or it is a problem that, either generally 
or specific to LXQt, I would call the "linking" situation -- that not 
completely supported packages just dont (yet) know about the location of 
the binaries.


That said, it is possible that to you guys, this is nothing noteworthy 
because it is clear. It's just that to me, it wasn't because I'm 
learning both guile and the linux ecosystem. Thus, if the problem at 
hand is simply a general problem, it is not a bug. Which means that the 
topic can be closed, if there is nothing to add :)


have a good day folks, guix rules