bug#68811: build hash inconsistency

[Saku Laesvuori via Bug reports for GNU Guix]

> Some more context might be useful:
> 
> Device A (which successfully built qutebrowser over a couple days)
> ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
> build qutebrowser --dry-run
> /gnu/store/i9ir7a26gv1ii98b4bzgvxp1sx0akind-qutebrowser-2.5.4
> 
> Device B (trying to avoid building qutebrowser)
> ~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
> build qutebrowser --dry-run
> The following derivations would be built:
>   /gnu/store/6n9aq7l5x26xfgrbvws7gvscbzvq5gqn-qutebrowser-2.5.4.drv
>   /gnu/store/05wj7wf7bdlkm1ar58kpakvp52drrz7p-qtwebengine-5.15.10.drv
>   /gnu/store/7nmv55qqw62jwzrd650vm434s3wpi7i3-python-pyqtwebengine-5.15.9.drv

Those hashes are not comparable: i9ir..nd (A) is the hash of the built
store item and 6n9aq..qn (B) is the hash of the derivation that builds
the store item.

> I have noticed in the past that sometimes a package gets built twice
> with two hashes, so I went back and checked if device A had built the
> 6n9..5gqn qutebrowser store item reported by B in addition to the
> i9i..ind one A was reporting.  There was no 6n9..5gqn qutebrowser build
> on device A.  I don't believe I have never run guix gc on either device.

But I do think it is weird if the derivation is not present on the
machine that build qutebrowser. Would you mind sending the output of
`guix time-machine ... -- build --derivations ...` from both machines?
If they return a different hash you could maybe also check the returned
`/gnu/store/...-qutebrowser-2.5.4.drv` files to see what is the
difference between them.

- Saku


signature.asc
Description: PGP signature

bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Montag, dem 29.01.2024 um 21:31 + schrieb Dariqq:
> * gnu/packages/gnome.scm (gdm)[propagated inputs]: Add adwaita-icon-
> theme,
> dconf, font-abattis-cantarell, gnome-control-center.
> * gnu/services/xorg.scm (gdm-shepherd-service): Set XDG_DATA_DIR to
> run/current-system/profile/share.
> (gdm-profile-service): New variable.
> (gdm-service-type): Use gdm-profile-service.
> (gdm-configuration-gnome-shell-assets): Set default to gnome-shell.
> 
> Change-Id: I870206a9ee6a7481d19e6b38b6a3ee72b5801c6a
> ---
> Hi Maxim and others,
> This is not quite the explicit wrapper we talked about on IRC but
> something similiar.
> 
> The gdm package now propagates the packages from gnome-shell-assets
> and I added dconf and gnome-control-center for basic accessibility
> settings functionality + icon. Does this introduce a problem as dconf
> is already a natice input?
> Maybe also some other packages can be added like  at-spi2-core, orca,
> ... or is this something the user should add to the system profile
> themselves?
> 
> In order for the gdm-shepherd-service to find the propagated packages
> I changed the XDG_DATA_DIR of the service to the system profile and
> added a gdm-profile-service to add gdm and gnome-shell to the system
> profile. Probably the gnome-shell-assets name should now also be
> changed as is is now only the gnome-shell package.
> 
> What do you think?
In my opinion, adding gnome-shell and gnome-control-center to gdm-
configuration-gnome-shell-assets would be preferable to propagating
inputs.

WDYT?

bug#68811: build hash inconsistency

[Zacchaeus Scheffer]

Some more context might be useful:

Device A (which successfully built qutebrowser over a couple days)
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build qutebrowser --dry-run
/gnu/store/i9ir7a26gv1ii98b4bzgvxp1sx0akind-qutebrowser-2.5.4

Device B (trying to avoid building qutebrowser)
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build qutebrowser --dry-run
The following derivations would be built:
  /gnu/store/6n9aq7l5x26xfgrbvws7gvscbzvq5gqn-qutebrowser-2.5.4.drv
  /gnu/store/05wj7wf7bdlkm1ar58kpakvp52drrz7p-qtwebengine-5.15.10.drv
  /gnu/store/7nmv55qqw62jwzrd650vm434s3wpi7i3-python-pyqtwebengine-5.15.9.drv

I have noticed in the past that sometimes a package gets built twice
with two hashes, so I went back and checked if device A had built the
6n9..5gqn qutebrowser store item reported by B in addition to the
i9i..ind one A was reporting.  There was no 6n9..5gqn qutebrowser build
on device A.  I don't believe I have never run guix gc on either device.

-Zacchae

bug#68811: build hash inconsistency

[Zacchaeus Scheffer]

Hi all,

tl;dr I run the following command on two aarch64-linux machines and get
two different hashes for the 'qutebrowser' package:

guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build 
qutebrowser --dry-run

Both machines use only the main guix repository, and guix describe gives
the same output (except generation number and date, which is fine).
Coming from aarch64, building is incredibly expensive.  If the build
hash doesn't match, then (I believe) there is no hope that my machine
will find the packages on a substitute server.  To get around this
issue, I built my guix home once, guix copy'd the store items, and
manually added a symlink in
/var/guix/profiles/per-user/USER/guix-home-N-link to point to the
foreign guix home build.  I couldn't find this issue elsewhere in the
issues, but my "hashes don't match" problem is pretty vague.

Is this an expected problem?  Is this a novel problem?  Am I
misunderstanding guix time-machine (which seems like it should produce
an identical store item)?

-Zacchae

bug#46961: Nginx and certbot cervices don't play well togther

[Clément Lassieur]

On Tue, Jan 30 2024, Carlo Zancanaro wrote:

>>> + ;; Due to the way certbot runs, we need to
>>> + ;; create the self-signed certificates in the
>>> + ;; archive folder and symlink them into the live
>>> + ;; folder. This mimics what certbot does well
>>> + ;; enough to make acquiring new certificates
>>> + ;; work.
>>
>> In another mail you say it doesn't work as well as you thought it did?
>> What doesn't work?
>
> This comment doesn't describe the code any more. In my first attempt I
> was trying to generate certificates in /etc/letsencrypt/live/ and get
> certbot to write over them when it ran. Unfortunately, it refused to do
> so. I then tried writing to /etc/letsencrypt/archive/ and symlinking
> into /etc/letsencrypt/live/ (which is what this comment describes), but
> that also failed. Certbot refuses to write over any existing files when
> fetching a certificate.

Oh I read the comment too quickly, I thought it was describing the
/etc/certs moving.  I suppose you will update it so to reflect the
actual state?

What you did (using /etc/certs, and symlinking stuff in
/etc/letsencrypt) is a good idea I think, and it's excellent that it's
backward compatible!

> It looks like other acme clients might be happier to overwrite existing
> files, but changing away from certbot seemed like more work than adding
> a deploy hook to do what we need.

Indeed!

> I'll follow up with a v2 of this patch when I get a chance.

Thanks!

> Carlo

bug#46961: Nginx and certbot cervices don't play well togther

[Carlo Zancanaro]

Hi Clément,

Thanks for taking the time to review my change. I've responded inline
below.

On Mon, Jan 29 2024, Clément Lassieur wrote:
> This is great, thank you!  I tested it, it worked.  Could you please
> just make sure lines fit within 80 columns?

Yep, no worries.

> Would it make sense now to run ‘update-certificates’ at end of the
> activation stuff?

We can't run it during activation, because nginx won't have started yet.
However, I am planning a follow-up to add a one-shot service to run
certbot after nginx starts. I'll see if I can add it to this series, but
if I run into any issues I'll leave it for later.

> And would it make sense to reload nginx after ‘update-certificates’ is
> run?

This would be a sensible default. There is an example in the manual of
configuring certbot to reload nginx, so this should be straightforward
to add.

> gnu/services/certbot.scm:203:26: warning: "subjectAltName=~{DNS:~a~^,~}": 
> unsupported format option ~{, use (ice-9 format) instead

Ha! I import (ice-9 format), but within the gexp (and then I don't use
it, whoops!). Must be a leftover from a previous iteration. I'll fix
this up.

>> + ;; Due to the way certbot runs, we need to
>> + ;; create the self-signed certificates in the
>> + ;; archive folder and symlink them into the live
>> + ;; folder. This mimics what certbot does well
>> + ;; enough to make acquiring new certificates
>> + ;; work.
>
> In another mail you say it doesn't work as well as you thought it did?
> What doesn't work?

This comment doesn't describe the code any more. In my first attempt I
was trying to generate certificates in /etc/letsencrypt/live/ and get
certbot to write over them when it ran. Unfortunately, it refused to do
so. I then tried writing to /etc/letsencrypt/archive/ and symlinking
into /etc/letsencrypt/live/ (which is what this comment describes), but
that also failed. Certbot refuses to write over any existing files when
fetching a certificate.

It looks like other acme clients might be happier to overwrite existing
files, but changing away from certbot seemed like more work than adding
a deploy hook to do what we need.

I'll follow up with a v2 of this patch when I get a chance.

Carlo

bug#68806: Dolphin looks in the wrong place for mounting programs

[Nathan Dehnel]

What happens if you try to unmount an nfs share from inside dolphin:

kf.solid.backends.fstab: "Couldn't find executable umount in
/sbin:/bin:/usr/sbin:/usr/bin"

guix version f74789c

bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Dariqq]

* gnu/packages/gnome.scm (gdm)[propagated inputs]: Add adwaita-icon-theme,
dconf, font-abattis-cantarell, gnome-control-center.
* gnu/services/xorg.scm (gdm-shepherd-service): Set XDG_DATA_DIR to
run/current-system/profile/share.
(gdm-profile-service): New variable.
(gdm-service-type): Use gdm-profile-service.
(gdm-configuration-gnome-shell-assets): Set default to gnome-shell.

Change-Id: I870206a9ee6a7481d19e6b38b6a3ee72b5801c6a
---
Hi Maxim and others,
This is not quite the explicit wrapper we talked about on IRC but something 
similiar.

The gdm package now propagates the packages from gnome-shell-assets and I added 
dconf and gnome-control-center for basic accessibility settings functionality + 
icon. Does this introduce a problem as dconf is already a natice input?
Maybe also some other packages can be added like  at-spi2-core, orca, ... or is 
this something the user should add to the system profile themselves?

In order for the gdm-shepherd-service to find the propagated packages I changed 
the XDG_DATA_DIR of the service to the system profile and added a 
gdm-profile-service to add gdm and gnome-shell to the system profile. Probably 
the gnome-shell-assets name should now also be changed as is is now only the 
gnome-shell package.

What do you think?


 gnu/packages/gnome.scm |  5 +
 gnu/services/xorg.scm  | 20 +---
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 6f22529dd7..c16079da0a 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -9020,6 +9020,11 @@ (define-public gdm
libcanberra
libgudev
linux-pam))
+(propagated-inputs
+ (list  adwaita-icon-theme
+dconf
+font-abattis-cantarell
+gnome-control-center))
 (synopsis "Display manager for GNOME")
 (home-page "https://wiki.gnome.org/Projects/GDM/;)
 (description
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 1ee15ea90c..8b360d7729 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -1039,7 +1039,9 @@ (define-record-type* 
   (debug? gdm-configuration-debug? (default #f))
   (default-user gdm-configuration-default-user (default #f))
   (gnome-shell-assets gdm-configuration-gnome-shell-assets
-  (default (list adwaita-icon-theme 
font-abattis-cantarell)))
+  ;; XXX: Remove gnome-shell below when GDM
+  ;; can depend on GNOME Shell directly.
+  (default (list gnome-shell)))
   (xorg-configuration gdm-configuration-xorg
   (default (xorg-configuration)))
   (x-session gdm-configuration-x-session
@@ -1136,6 +1138,10 @@ (define (gdm-pam-service config)
  #:allow-empty-passwords?
  (gdm-configuration-allow-empty-passwords? config
 
+(define (gdm-profile-service config)
+  (cons* (gdm-configuration-gdm config)
+ (gdm-configuration-gnome-shell-assets config)))
+
 (define (gdm-shepherd-service config)
   (define config-file
 (gdm-configuration-file config))
@@ -1164,15 +1170,7 @@ (define (gdm-shepherd-service config)
 "GDM_X_SESSION="
 #$(gdm-configuration-x-session config))
(string-append
-"XDG_DATA_DIRS="
-((lambda (ls) (string-join ls ":"))
- (map (lambda (path)
-(string-append path "/share"))
-  ;; XXX: Remove gnome-shell below when GDM
-  ;; can depend on GNOME Shell directly.
-  (cons #$gnome-shell
-
'#$(gdm-configuration-gnome-shell-assets
-config)
+"XDG_DATA_DIRS=/run/current-system/profile/share")
;; Add XCURSOR_PATH so that mutter can find its
;; cursors.  gdm doesn't login so doesn't source
;; the corresponding line in /etc/profile.
@@ -1237,7 +1235,7 @@ (define gdm-service-type
  (service-extension polkit-service-type
 gdm-polkit-rules)
  (service-extension profile-service-type
-
gdm-configuration-gnome-shell-assets)
+gdm-profile-service)
  (service-extension dbus-root-service-type
 (compose list
  gdm-configuration-gdm))

base-commit: 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8
-- 
2.41.0

bug#46961: Nginx and certbot cervices don't play well togther

[Clément Lassieur]

Also, I forgot, I think it would be great to have somewhere in the doc
an example of minimal config.scm that works.  I know we can't do proper
testing because we depend of certbot service but that would make it
easier for a lot of people to test it.  Maybe such example is already in
the docs and I haven't seen it though.

Here is the one I used:

--8<---cut here---start->8---
(use-modules (gnu) (gnu tests))
(use-package-modules web)
(use-service-modules certbot networking web)

(operating-system
  (inherit %simple-os)
  (services
   (cons*
(service dhcp-client-service-type)
(service nginx-service-type
 (nginx-configuration
  (server-blocks
   (list
(nginx-server-configuration
 (listen '("443 ssl"))
 (server-name '("test.lassieur.org"))
 (ssl-certificate
  "/etc/certs/test.lassieur.org/fullchain.pem")
 (ssl-certificate-key
  "/etc/certs/test.lassieur.org/privkey.pem"))
(service certbot-service-type
 (certbot-configuration
  (certificates
   (list
(certificate-configuration
 (domains '("test.lassieur.org")))
%base-services)))
--8<---cut here---end--->8---

bug#46961: Nginx and certbot cervices don't play well togther

[Clément Lassieur]

Hi Carlo,

On Wed, Jan 24 2024, Carlo Zancanaro wrote:

> * gnu/services/certbot.scm (): Add
> start-self-signed? field.
> (generate-certificate-gexp): New procedure.
> (certbot-activation): Generate self-signed certificates when
> start-self-signed? is #t.
> * doc/guix.texi (Certificate services): Document start-self-signed?.
> ---
>  doc/guix.texi|  6 +
>  gnu/services/certbot.scm | 56 +---
>  2 files changed, 59 insertions(+), 3 deletions(-)

This is great, thank you!  I tested it, it worked.  Could you please
just make sure lines fit within 80 columns?  And there is a warning
during compilation, pasted below.

Would it make sense now to run ‘update-certificates’ at end of the
activation stuff?

And would it make sense to reload nginx after ‘update-certificates’ is
run?

Clément

> diff --git a/doc/guix.texi b/doc/guix.texi
> index 2d43ab9a65..15b256d0a3 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -32664,6 +32664,12 @@ Certificate Services
>  contain a space-delimited list of renewed certificate domains (for
>  example, @samp{"example.com www.example.com"}.
>  
> +@item @code{start-self-signed?} (default: @code{#t})
> +Whether to generate an initial self-signed certificate during system
> +activation.  This option is particularly useful to allow @code{nginx} to
> +start before @code{certbot} has run, because @code{certbot} relies on
> +@code{nginx} running to perform HTTP challenges.
> +
>  @end table
>  @end deftp
>  
> diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
> index 58e709f8a4..bb321a1b50 100644
> --- a/gnu/services/certbot.scm
> +++ b/gnu/services/certbot.scm
> @@ -64,7 +64,9 @@ (define-record-type* 
>(cleanup-hookcertificate-cleanup-hook
> (default #f))
>(deploy-hook certificate-configuration-deploy-hook
> -   (default #f)))
> +   (default #f))
> +  (start-self-signed?  certificate-configuration-start-self-signed?
> +   (default #t)))
>  
>  (define-record-type* 
>certbot-configuration make-certbot-configuration
> @@ -91,7 +93,10 @@ (define-record-type* 
>  (define (certbot-deploy-hook name deploy-hook-script)
>"Returns a gexp which creates symlinks for privkey.pem and fullchain.pem
>  from /etc/certs/NAME to /etc/letsenctypt/live/NAME.  If DEPLOY-HOOK-SCRIPT is
> -not #f then it is run after the symlinks have been created."
> +not #f then it is run after the symlinks have been created.  This wrapping is
> +necessary for certificates with start-self-signed? set to #t, as it will
> +overwrite the initial self-signed certificates upon the first successful
> +deploy."
>(program-file
> (string-append name "-deploy-hook")
> (with-imported-modules '((guix build utils))
> @@ -108,7 +113,8 @@ (define (certbot-deploy-hook name deploy-hook-script)
>   "/etc/letsencrypt/live/" name "/fullchain.pem")
>#$(string-append "/etc/certs/" name "/fullchain.pem.new"))
>  
> - ;; Rename over the top of the old ones, if there are any.
> + ;; Rename over the top of the old ones, just in case they were the
> + ;; original self-signed certificates.
>   (rename-file #$(string-append "/etc/certs/" name "/privkey.pem.new")
>#$(string-append "/etc/certs/" name "/privkey.pem"))
>   (rename-file #$(string-append "/etc/certs/" name 
> "/fullchain.pem.new")
> @@ -182,6 +188,44 @@ (define (certbot-renewal-jobs config)
> #~(job '(next-minute-from (next-hour '(0 12)) (list (random 60)))
>#$(certbot-command config
>  
> +(define (generate-certificate-gexp certbot-cert-directory rsa-key-size)
> +  (match-lambda
> +(($  name (primary-domain other-domains ...) 
> challenge
> +csr authentication-hook
> +cleanup-hook deploy-hook)
> + (let (;; Arbitrary default subject, with just the
> +   ;; right domain filled in. These values don't
> +   ;; have any real significance.
> +   (subject (string-append "/C=US/ST=Oregon/L=Portland/O=Company 
> Name/OU=Org/CN="
> +   primary-domain))
> +   (alt-names (if (null? other-domains)
> +  #f
> +  (format #f "subjectAltName=~{DNS:~a~^,~}" 
> other-domains)))

gnu/services/certbot.scm:203:26: warning: "subjectAltName=~{DNS:~a~^,~}": 
unsupported format option ~{, use (ice-9 format) instead

> +   (directory (string-append "/etc/certs/" (or name 
> primary-domain
> +   #~(begin
> +   (use-modules (ice-9 format))
> +   (when (not (file-exists? #$directory))
> + ;; Due to the way certbot runs, we need to
> + ;; create the self-signed certificates in the
> + ;; archive folder and symlink them into the live
> +   

bug#68800: Guix waits for termination of a kernel thread

[Tomas Volf]

> Date: Mon, 29 Jan 2024 17:31:33 +0100
> From: Ludovic Courtès 
> To: guix-de...@gnu.org
> Subject: Re: GNU Shepherd 0.10.3 released
>
> Hi,
>
> Tomas Volf <~@wolfsden.cz> skribis:
>
> > Ah, that code indeed returns #f for the pid in question:
> >
> > scheme@(guix-user)> ((@@ (guix build syscalls) kernel?) 688)
> > $1 = #f
> >
> > The stat file:
> >
> > $ cat /proc/688/stat
> > 688 (mt76-tx phy0) S 2 0 0 0 -1 2129984 0 0 0 0 0 0 0 0 -2 0 1 0 964 0 
> > 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 5 1 1 0 0 0 0 0 
> > 0 0 0 0 0 0
> >
> > So the start_code is not zero (I would guess it is -1).  I have no idea what
> > that means though.
>
> What about this method (from shepherd)?
>
> --8<---cut here---start->8---
> (define (linux-process-flags pid)
>   "Return the process flags of @var{pid} (or'd @code{PF_} constants), assuming
> the Linux /proc file system is mounted; raise a @code{system-error} exception
> otherwise."
>   (call-with-input-file (string-append "/proc/" (number->string pid)
>"/stat")
> (lambda (port)
>   (define line
> (get-string-all port))
>
>   ;; Parse like systemd's 'is_kernel_thread' function.
>   (let ((offset (string-index line #\ ;offset past 'tcomm' field
> (match (and offset
> (string-tokenize (string-drop line (+ offset 1
>   ((state ppid pgrp sid tty-nr tty-pgrp flags . _)
>(or (string->number flags) 0))
>   (_
>0))
>
> ;; Per-process flag defined in .
> (define PF_KTHREAD #x0020);I am a kernel thread
>
> (define (linux-kernel-thread? pid)
>   "Return true if @var{pid} is a Linux kernel thread."
>   (= PF_KTHREAD (logand (linux-process-flags pid) PF_KTHREAD)))
> --8<---cut here---end--->8---
>
> If it works better, we can use that in syscalls.scm as well.

Yes, that does seem to work:

scheme@(guile-user)> ,use (ice-9 match)
scheme@(guile-user)> ,use (ice-9 textual-ports)
scheme@(guile-user)> (define (linux-process-flags pid)
  "Return the process flags of @var{pid} (or'd @code{PF_} constants), 
assuming
the Linux /proc file system is mounted; raise a @code{system-error} 
exception
otherwise."
  (call-with-input-file (string-append "/proc/" (number->string pid)
   "/stat")
(lambda (port)
  (define line
(get-string-all port))

  ;; Parse like systemd's 'is_kernel_thread' function.
  (let ((offset (string-index line #\ ;offset past 'tcomm' field
(match (and offset
(string-tokenize (string-drop line (+ offset 1
  ((state ppid pgrp sid tty-nr tty-pgrp flags . _)
   (or (string->number flags) 0))
  (_
   0))
scheme@(guile-user)> ;; Per-process flag defined in .
(define PF_KTHREAD #x0020);I am a kernel thread
scheme@(guile-user)> (define (linux-kernel-thread? pid)
  "Return true if @var{pid} is a Linux kernel thread."
  (= PF_KTHREAD (logand (linux-process-flags pid) PF_KTHREAD)))
scheme@(guile-user)> (linux-kernel-thread? 685)
$5 = #t

Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#68800: Guix waits for termination of a kernel thread

[Tomas Volf]

Hello,

when Guix machine is shutting down, it keeps waiting for PID associated with
[mt76-tx phy0] to terminate.  Since it is a kernel thread, it does not happen.

Previous discussion on this bug was done via email, and is copied here:



Date: Sun, 7 Jan 2024 15:59:51 +0100
From: Tomas Volf <~@wolfsden.cz>
To: guix-de...@gnu.org
Subject: Re: GNU Shepherd 0.10.3 released

On 2024-01-07 15:08:59 +0100, Ludovic Courtès wrote:
> We are pleased to announce the GNU Shepherd version 0.10.3, a bug-fix
> release of the new 0.10.x series, representing 51 commits over 6 months.

Congratulations on the release :)

>
>   ** Do not accidentally wait for Linux kernel thread completion
>  ()
>
>   In cases a PID file contained a bogus PID or one that’s only valid in a
>   separate PID namespace, shepherd could end up waiting for the termination of
>   what’s actually a Linux kernel thread, such as PID 2 (“kthreadd”).  This
>   situation is now recognized and avoided.

This is great, I will not have to remember to run `modprobe -r mt7921e' before
each shutdown anymore.  I hope.  Looking forward to getting it in the Guix :)

Have a nice 2024,
Tomas Volf



Date: Wed, 10 Jan 2024 00:34:48 +0100
From: Ludovic Courtès 
To: guix-de...@gnu.org
Subject: Re: GNU Shepherd 0.10.3 released

Tomas Volf <~@wolfsden.cz> skribis:

> On 2024-01-07 15:08:59 +0100, Ludovic Courtès wrote:

[...]

>>   ** Do not accidentally wait for Linux kernel thread completion
>>  ()
>>
>>   In cases a PID file contained a bogus PID or one that’s only valid in a
>>   separate PID namespace, shepherd could end up waiting for the termination 
>> of
>>   what’s actually a Linux kernel thread, such as PID 2 (“kthreadd”).  This
>>   situation is now recognized and avoided.
>
> This is great, I will not have to remember to run `modprobe -r mt7921e' before
> each shutdown anymore.  I hope.  Looking forward to getting it in the Guix :)

D’oh, why did you have to do that?  How did Shepherd end up with “wrong” PID?

I hope this release fixes it!

Ludo’.



Date: Wed, 10 Jan 2024 17:38:17 +0100
From: Tomas Volf <~@wolfsden.cz>
To: Ludovic Courtès 
Cc: guix-de...@gnu.org
Subject: Re: GNU Shepherd 0.10.3 released

On 2024-01-10 00:34:48 +0100, Ludovic Courtès wrote:
> Tomas Volf <~@wolfsden.cz> skribis:
>
> > On 2024-01-07 15:08:59 +0100, Ludovic Courtès wrote:
>
> [...]
>
> >>   ** Do not accidentally wait for Linux kernel thread completion
> >>  ()
> >>
> >>   In cases a PID file contained a bogus PID or one that’s only valid in a
> >>   separate PID namespace, shepherd could end up waiting for the 
> >> termination of
> >>   what’s actually a Linux kernel thread, such as PID 2 (“kthreadd”).  This
> >>   situation is now recognized and avoided.
> >
> > This is great, I will not have to remember to run `modprobe -r mt7921e' 
> > before
> > each shutdown anymore.  I hope.  Looking forward to getting it in the Guix 
> > :)
>
> D’oh, why did you have to do that?

Otherwise the shepherd would be stuck on shutdown waiting for process named

[mt76-tx phy0]

to terminate with messages along the lines of:

shepherd[1]: waiting for process termination (processes left: (1 678))

It is a kernel thread as far as I can tell (based on
https://stackoverflow.com/a/12231039):

$ cd /proc/678
$ cat cmdline
$ readlink exe; echo $?
1

Removing the module mt7921e stops the thread, so shepherd does not wait for it.

> How did Shepherd end up with “wrong” PID?

That I do not know.  It is visible in `ps' output, so I assume shepherd picked
it up on its own somehow.

>
> I hope this release fixes it!

As far as I can tell, the 0.10.3 was already added into guix:

$ ps 1 | cat
  PID TTY  STAT   TIME COMMAND
1 ?Sl 0:01 
/gnu/store/bhynhk0c6ssq3fqqc59fvhxjzwywsjbb-guile-3.0.9/bin/guile 
--no-auto-compile 
/gnu/store/06mz0yjkghi7r6d7lmhvv7gryipljhdd-shepherd-0.10.3/bin/shepherd
+--config /gnu/store/klkqq2y65k141rlipq4ls0w2rlhds12h-shepherd.conf

So I have to say it sadly did not resolve this issue.  I am unsure why though.
I am not familiar with Shepherd's code base, but quick look at the git log
suggested that procedure (@@ (shepherd service) pseudo-process?) is the relevant
one.  When I try it from a REPL, it returns #t.

$ guix shell guile shepherd guile-fibers -- guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (shepherd service)
scheme@(guile-user)> ((@@ (shepherd service) pseudo-process?) 688)
$1 = #t

So it *should* work?  However the issue is caused by non-free WiFi driver on a
corrupted kernel, so I am not 

bug#68797: Channel dependencies should be propagated

[Ludovic Courtès]

Hello!

With channels flourishing, we found a bug that’s always been there.

When channel C depends on B, which depends on A, in general you need
both A and B to be present in the build environment of C (the derivation
that compiles C when you run ‘pull’ or ‘time-machine’) because
potentially B is going to load modules from A.

However, currently only B is present in C’s environment.

To illustrate that, the script below creates three such channels.
Right now it fails like this:

--8<---cut here---start->8---
building /gnu/store/2pnfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv...
|builder for `/gnu/store/2pnfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv' 
failed to produce output path 
`/gnu/store/lix9sz9g2x2ixr3dsyrbnxhxfcqn41l7-my-channel-c'
build of /gnu/store/2pnfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv failed
View build log at 
'/var/log/guix/drvs/2p/nfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv.gz'.
cannot build derivation 
`/gnu/store/alh2yy1258206zki24z9nzi1zwrggd4d-profile.drv': 1 dependencies 
couldn't be built
guix time-machine: error: build of 
`/gnu/store/alh2yy1258206zki24z9nzi1zwrggd4d-profile.drv' failed
$ zcat /var/log/guix/drvs/2p/nfkl9l6lsndsgk4qg7rq4wjh2iisj0-my-channel-c.drv.gz
(repl-version 0 1 1)
(exception misc-error (value #f) (value "no code for module ~S") (value 
((my-channel-a))) (value #f))
--8<---cut here---end--->8---

Here’s the script:

--8<---cut here---start->8---
#!/bin/sh

set -ex

mkdir a
echo '(define-module (my-channel-a))' > a/my-channel-a.scm
(cd a; git init; git add .; git commit -m init)

mkdir b
cat > b/my-channel-b.scm < b/.guix-channel < c/my-channel-c.scm < c/.guix-channel < "channels.scm" 8---

Ludo’.

bug#39117: GNOME Files: No file thumbnails

[Jonathan Brielmaier via Bug reports for GNU Guix]

I'm running nautilus@42.2 and it shows thumbnails for at least JPEG and
PNG images.

This is on a rather recent Guix System installation:
```
$ LANG=en guix system describe
Generation 10   Jan 07 2024 16:46:14(current)
[...]
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 9816a5371663396bc092eb359222635e5675b174
```

So can we close this issue?

bug#68794: git-annex accesses /etc/protocols

[Konrad Hinsen]

As packaged in Guix, git-annex reads the file /etc/protocols,
e.g. for accessing Web remotes. This requires sharing this
file from the host when running git-annex in a container.
Other software in Guix is patched to use the protocols file
from "net-base" instead. This should be done for git-annex
as well.

A quick scan of the source code shows no obvious reference to
/etc/protocols. It is possible that the access actually
happens in some dependency.

Cheers,
  Konrad.