Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file

[Stefan Monnier]

> The systemd documentation contains code to implement sd_notify without
> using libsystemd at
> https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
>
> Lennart Poettering said on Mastodon that the notify protocol is stable
> and is independent of libsystemd.
>
> https://mastodon.social/@pid_eins/112202687764571433
> https://mastodon.social/@pid_eins/112202696589971319

Looks quite promising.


Stefan

Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Hello Matt, pushed as 86fb0e039bf30cf85e2066401f9a384427c47ea8.

I was bold enough to retain the xref change in (Setting Up the Daemon)
prompted by Ludo, because starting a sentence with @xref is recommended
in the Texinfo manual and its examples, while @pxref at the start of a
phrase is not preferrable, according to the “info "(texinfo)@pxref"”.

Again, Texinfo cross-references are complicated.

(In the German translations, I always wrote only @ref, but only because
@xref is not properly translated; Emacs in particular is not
internationalized at all.)

Regards,
Florian

Re: Sustainability fund application ongoing

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> It was pointed to us that the "Free and Open Source Software
> Sustainability Fund" [0] is currently receiving applications.  The fund
> aim to sponsors free software projects for their
> maintenance/organisational activities.

Nice!  You forgot the link but I guess it’s
.
Deadline is May 17th.

> I'm tempted to apply myself, but I thought I'd share it here: the more
> submissions they get the more likely Guix is to receive support.

Agreed, it’s great to have people apply there (even better if it works,
of course).

Maybe we should provide a contact point for people who want to
coordinate when applying for Guix-related funding, to avoid overlapping
or competing applications?

Ludo’.

Re: Distributed GNU Shepherd NLNet Grant

[Ludovic Courtès]

Hey Juliana,

Juliana Sims  skribis:

> As some of you already know, in December I submitted an application
> for an NLNet grant to fund porting our beloved Shepherd to Spritely
> Goblins [1]. This work would represent a radical evolution in the
> capabilities of not just Guix's system layer, but of GNU/Linux system
> layers in general; and would also be the biggest real-world test to
> date of the Goblins library and its capabilities (pun not
> intended). Materially, it would allow Shepherd dæmons running on
> different machines to securely communicate and interact with each
> other, going so far as to control one machine's dæmons from another
> machine.
>
> I am happy to announce that this grant application was approved! [2]

Yay, congrats!! 

This is exciting; I’m glad Ricardo has already offered another nice use
case.  :-)

It’s great to have you on board, and it’s great to have you be the first
person bridging the inspiring work happening in Goblins and the cool
stuff in Shepherd and Guix.

Cheers,
Ludo’.

Re: System can no longer be reconfigured

[Ludovic Courtès]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  skribis:

> I can no longer reconfigure a system with any of these methods:
>
> 1. "guix deploy" which I use almost exclusively
> 2. "guix system reconfigure" after a recent pull
> 3. "./pre-inst-env guix system reconfigure" with a recent Git checkout.
>
> Guix hangs during the system activation step.  Any ideas?

Is it not hanging during Shepherd service upgrade?  (I think you
mentioned that elsewhere.)

If that is the case, (1) that is not preventing upgrade from happening
since that’s the very last step (it just means you’ll have to reboot),
and (2) it’s a shepherd-related bug for which perhaps there are clues in
/var/log/messages?

HTH!

Ludo’.

Re: No public interface for shepherd-package

[Ludovic Courtès]

Hi Felix,

Felix Lechner  skribis:

> Following podiki's and jab's kind advice on IRC yesterday, I recompiled
> Guix locally.  I also provided all channels locally via -L.
>
> That 'system reconfigure' failed too, however.  The error message was:
>
> Module named (shepherd-package) has no public interface.

Is ‘shepherd’ among your channels?

I do something similar to what Attila described, and I have:

--8<---cut here---start->8---
$ guix describe
Generation 299  Apr 08 2024 00:55:02(current)
  shepherd d8d96fc
repository URL: https://git.savannah.gnu.org/git/shepherd.git
branch: devel
commit: d8d96fc28c49c624323b2f9f5cb01c4fc18a4afd
  guile db7efa5
repository URL: https://git.savannah.gnu.org/git/guile.git
branch: main
commit: db7efa5d204b2e46ce9eb82f417d8c12d394858d
  guix 49f82fc
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 49f82fca4130ffcfb16aa0cf89750ab56fb99ad7
--8<---cut here---end--->8---

Ludo’.

Re: The `channels' field of `operating-system' record

[Ludovic Courtès]

Hi,

Tomas Volf <~@wolfsden.cz> skribis:

> On 2024-04-10 17:17:27 +0200, Ludovic Courtès wrote:

[...]

>> Yes, why is that?  At first sight, that’s because ‘extra-special-file’
>> does things at activation time; there’s no check happening at
>> configuration time.
>>
>> It was really meant for /bin/sh, /usr/bin/env, and similar.  The reason
>> its effect is silently dismissed in this case is, I think, because its
>> activation runs before the /etc activation.  So it’s really bad luck.
>>
>> I’m not sure what to do here, apart from maybe recommending against
>> broad use of this service.
>
> I will re-phrase the above into a documentation patch.

Great.

>> That would be: (guix-configuration … (channels (load "channels.scm"))).
>
> That does not seems to work, I am getting this error:
>
> /tmp $ guix system build os.scm
> ;;; compiling /tmp/channels.scm
> ;;; /tmp/channels.scm:1:7: warning: possibly unbound variable `channel'

[...]

> But after some experimentation (and looking into pull.scm), it seems what I 
> need
> is this:
>
> (use-modules (guix ui))
> (use-modules (guix channels))
>
> and
>
> (channels (load* "channels.scm"
>  (make-user-module '((guix channels)

Or simpler: use (guix channels) in your OS config so you can use
(load "channels.scm").

(‘load’ evaluates code in the current module.)

> Maybe it would be best to extract (load-channels) from pull.scm into
> guix/channels.scm, exporting it?  (Since for example the above is missing 
> error
> checking code from (load-channels)).

Yes, good idea, we can do that.

Thanks for your feedback!

Ludo’.

Re: Creating a documentation team?

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> Hi Florian and all,
>
> I figure you’ve been doing a lot of review and writing of the manual.
> Should we create a documentation team, of which you could be a honorary
> member?  :-)

Yes, please add this team for documentation.  I agree and would like to
be in that team.  (Although I am already not able to keep up with all
outstanding doc patches like bug#70202.)

Regards,
Florian

Re: Creating a documentation team?

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi Florian and all,
>
> I figure you’ve been doing a lot of review and writing of the manual.
> Should we create a documentation team, of which you could be a honorary
> member?  :-)
>
> I feel like ensuring doc consistency, be it regarding the content,
> terminology, typography, or use of markup, is a job in its own that
> could be best reviewed by people familiar with and interested in those
> issues.
>
> WDYT?
>
> Ludo’.
>
> diff --git a/etc/teams.scm b/etc/teams.scm
> index d537e83efc..4d65a5476e 100755
> --- a/etc/teams.scm
> +++ b/etc/teams.scm
> @@ -434,6 +434,16 @@ (define-team core
>(make-regexp* "^guix/scripts/")
>(make-regexp* "^guix/store/"
>  
> +(define-team documentation
> +  (team 'documentation
> +#:name "Documentation"
> +#:description "Documentation: the manual and cookbook."
> +#:scope (list (make-regexp* "\\.texi$")
> +  "doc/build.scm"
> +  "gnu/system/examples/bare-bones.tmpl"
> +  "gnu/system/examples/lightweight-desktop.tmpl"
> +  "gnu/system/examples/desktop.tmpl")))
> +
>  (define-team core-packages
>(team 'core-packages
>  #:name "Core packages"

I second this.  I'd be happy to be added to it.

-- 
Thanks,
Maxim

Re: Should we include nss-certs out of the box?

[Maxim Cournoyer]

Hi Fabio,

Fabio Natali  writes:

> Hi,
>
> Here's my attempt at adding 'nss-certs' to '%default-packages'.
>
> https://lists.gnu.org/archive/html/guix-patches/2024-04/msg01187.html
>
> I've removed the 'nss-certs' entry from the installer, as suggested by
> Ludo, and I've updated the docs, hopefully all the relevant parts. Can
> you think of anything else that may need to be updated?

It seems we were working on a similar thing at a similar time :-).
Could you please take a look at
'65e8472a4b6fc6f66871ba0dad518b7d4c63595e', which I hope didn't leave
no longer useful 'nss-certs' doc/examples behind ?

-- 
Thanks,
Maxim

Re: Status of ‘core-updates’

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Since branches were merged in, I believe the problem we are facing at
>> the moment is librsvg failing its test suite with a segfault (!).  Could
>> be the glibc upgrade, or rust itself, I'm not sure.  I was trying to
>> upgrade librsvg, which needs an update anyway, but it pulls many rust
>> crates updates.  I'll get there eventually, if nobody beats me to it.
>
> Ouch, OK.  I guess it doesn’t hurt if several of us take a look and we
> share our findings here.
>
>>> Josselin, Maxim: could you explain what problems there are around
>>> pkgconf and what you would recommend?
>>
>> Nothing in particular to point at the moment, but remaining problems
>> would manifest in the form of missing inputs, due to transitive libtool
>> dependencies causing overlinking and the new pkgconf being smart enough
>> to optimize away some previously captured link directives that would be
>> baked in the RUNPATH and sastify libtool overlinking needs.
>>
>> The solution is to hunt the libtool .la files from the transitive
>> dependencies causing the problem and removing them. See commit
>> b6540bd285cbe5920ad379ddfc6256359ee7204c for an example.
>
> Good.  So it seems like we can move forward after all and just do the
> “normal” job and finding and fixing build failures along these lines.
>
> Do we need ci.guix to build more packages to facilitate testing and
> debugging?  That’s something I can help with (though I’ll be away for a
> week).

If we do this, and I believe it'd be useful, I think it'd help to fork a
'core-updates-frozen' and have the CI rebuild this one fully, leaving
'core-updates' open to business as usual.

-- 
Thanks,
Maxim

Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file

[Rudolf Schlatte]

Ludovic Courtès  writes:

> Stefan Monnier  skribis:
>
>>> Would that make sense on systems where systemd is used? If libsystem is
>>> already installed it would be more convenient for the user to use the
>>> already installed and very likely loaded libsystemd instead of
>>> reimplementing the feature.
>>
>> You might be right, but it's hard to say without seeing the replacement
>> code and the actual doc of the protocol.
>
> As an example, here’s C++ code that checks the LISTEN_* environment
> variables I mentioned earlier:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/tree/nix/nix-daemon/guix-daemon.cc#n437
>
> Ludo’.

The systemd documentation contains code to implement sd_notify without
using libsystemd at
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes

Lennart Poettering said on Mastodon that the notify protocol is stable
and is independent of libsystemd.

https://mastodon.social/@pid_eins/112202687764571433
https://mastodon.social/@pid_eins/112202696589971319

Re: Shepherd timers

[Ludovic Courtès]

Hi,

Felix Lechner  skribis:

> On Wed, Apr 10 2024, Ludovic Courtès wrote:
>
>> Could you share this service or at least the (calendar-event …) bit?
>
> It was my error.  The iota in
>
> (calendar-event #:minutes '(iota 12 3 5))

Oh, great that you found out.  We should add checks to diagnose such
issues earlier.

>> Feedback & suggestions welcome!
>
> As a feature request, it would be nice to run timers as users other than
> root.

Good news: that’s already possible with the #:user argument of
‘command’.  :-)

> To encourage adoption of these timers among Guix user, I'll also share
> some of my timers:
>
> Btrbk Snapshot [2]
> Mdadm Resync service [3]
> Guix Garbage Collector service [4]
> Debbugs Config Sync service [5]
> Debbugs Bug Data Sync service [6]
> Borg Backup service [7]

Nice, thanks for sharing!

BTW, until 1.0 is released, the interface may still change.  Just so you
know!

Ludo’.

Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

[Ludovic Courtès]

Hi,

Skyler Ferris  skribis:

> In short, I'm not sure that we actually get any value from checking the 
> PGP signature for most projects. Either HTTPS is good enough or the 
> attacker won. 99% of the time HTTPS is good enough (though it is notable 
> that the remaining 1% has a disproportionate impact on the affected 
> population).

When checking PGP signatures, you end up with a trust-on-first-use
model: the first time, you download a PGP key that you know nothing
about and you authenticate code against that, which gives no
information.

On subsequent releases though, you can ensure (ideally) that releases
still originates from the same party.

HTTPS has nothing to do with that: it just proves that the web server
holds a valid certificate for its domain name.

But really, the gold standard, if I dare forego any form of modesty, is
the ‘.guix-authorizations’ model as it takes care of key distribution as
well as authorization delegation and revocation.

  https://doi.org/10.22152/programming-journal.org/2023/7/1

Ludo’.

Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file

[Ludovic Courtès]

Hi,

Nicolas Graves  skribis:

> (define (emacs-shepherd-service config name)
>   (shepherd-service
>(documentation
> (format #f "Emacs server.  Use ~a to connect to it."
> (if (eq? 'server name)
> "@code{emacsclient}"
> (format #f "@code{emacsclient -s ~a}" name
>(provision `(,(symbol-append 'emacs- name)))
>(requirement '(emacs))
>(modules '((shepherd support)))  ;for '%user-runtime-dir'
>(start #~(make-systemd-constructor
>  (list #$(file-append
>   (home-emacs-configuration-emacs config)
>   "/bin/emacs") #$(format #f "--fg-daemon=~a" name))
>  (list (endpoint
> (make-socket-address
>  AF_UNIX
>  (string-append %user-runtime-dir
> "/emacs/" #$(symbol->string name)))
> #:name '#$(format #f "emacs-~a" name)
> #:socket-directory-permissions #o700))
>  #:log-file (string-append
>  (getenv "XDG_STATE_HOME") "/log"
>  "/emacs-" #$(symbol->string name) ".log")))
>(stop #~(make-systemd-destructor

Note that in this case the server is started lazily, the first time
someone connects to the socket.

You can pass #:lazy-start? #false if you instead want to start it
upfront.

> But I'm not sure it's better regarding user experience. On RDE we
> implemented a notifier that parses the result of
> herd eval root "(and=> (lookup-service 'emacs-server) service-status)"
> thus giving a nice "Emacs is currently starting" notification.

With socket activation, the service is immediately in “running” state:
starting it requires nothing more than accepting connections on the
socket.

(Maybe that’s one of the rare situations where sd-notify would help?)

> This evaluation doesn't seem to work using make-systemd-constructor,
> although it has its advantages (indeed launches a frame when available).
> It would be nice if service-status could "sync" with
> make-systemd-constructor in this case.
>
> I would be happy to send such a patch for Guix (is there already some
> patch series on which to graft this?), WDYT @Ludo?

Sure, feel free to send a patch for this; there are unfortunately
several attempts at an Emacs service in the issue tracker, but none of
them made it to the tree so far, in part because some were very
ambitious.

Thanks,
Ludo’.

Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file

[Ludovic Courtès]

Stefan Monnier  skribis:

>> Would that make sense on systems where systemd is used? If libsystem is
>> already installed it would be more convenient for the user to use the
>> already installed and very likely loaded libsystemd instead of
>> reimplementing the feature.
>
> You might be right, but it's hard to say without seeing the replacement
> code and the actual doc of the protocol.

As an example, here’s C++ code that checks the LISTEN_* environment
variables I mentioned earlier:

  
https://git.savannah.gnu.org/cgit/guix.git/tree/nix/nix-daemon/guix-daemon.cc#n437

Ludo’.

Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file

[Ludovic Courtès]

Hi,

Björn Bidar  skribis:

> Stefan Monnier  writes:
>
>>> Maybe some feedback on the Emacs side about this? There are indeed very
>>> few places where systemd sd_* functions are called in emacs.c, should we
>>> try and re-implement them instead of using the library as is? Would that
>>> be a contribution Emacs devs would be interested in? That would
>>> definitely be beneficial for Emacs on Guix as highlighted by Ludo'.
>>
>> It's hard to tell without seeing the actual patch.
>>
>> But if the code is sufficiently simple, it implements a protocol that's
>> well documented, and it allows us to eliminate the dependency on the
>> systemd library, we might like it.
>
> Would that make sense on systems where systemd is used? If libsystem is
> already installed it would be more convenient for the user to use the
> already installed and very likely loaded libsystemd instead of
> reimplementing the feature.

As I wrote, in the wake of the xz backdoor, many came to the conclusion
that linking against libsystemd “just” to check a couple of environment
variables (for socket activation) is hard to justify (libsystemd
provides much more functionality than this bit.)

> Ideally the support for other initrd system could implement a function
> that is then called instead of the systemd codepath  be it something
> different or to reimplenent sd-notify. Maybe shepherd as something like
> sd-notify of it's own?

Shepherd does not implement the sd-notify protocol, but it implements
socket activation, which is what Emacs currently uses AFAICS.

HTH,
Ludo’.

Re: Status of ‘core-updates’

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Since branches were merged in, I believe the problem we are facing at
> the moment is librsvg failing its test suite with a segfault (!).  Could
> be the glibc upgrade, or rust itself, I'm not sure.  I was trying to
> upgrade librsvg, which needs an update anyway, but it pulls many rust
> crates updates.  I'll get there eventually, if nobody beats me to it.

Ouch, OK.  I guess it doesn’t hurt if several of us take a look and we
share our findings here.

>> Josselin, Maxim: could you explain what problems there are around
>> pkgconf and what you would recommend?
>
> Nothing in particular to point at the moment, but remaining problems
> would manifest in the form of missing inputs, due to transitive libtool
> dependencies causing overlinking and the new pkgconf being smart enough
> to optimize away some previously captured link directives that would be
> baked in the RUNPATH and sastify libtool overlinking needs.
>
> The solution is to hunt the libtool .la files from the transitive
> dependencies causing the problem and removing them. See commit
> b6540bd285cbe5920ad379ddfc6256359ee7204c for an example.

Good.  So it seems like we can move forward after all and just do the
“normal” job and finding and fixing build failures along these lines.

Do we need ci.guix to build more packages to facilitate testing and
debugging?  That’s something I can help with (though I’ll be away for a
week).

Thank you for explaining,
Ludo’.

Creating a documentation team?

[Ludovic Courtès]

Hi Florian and all,

I figure you’ve been doing a lot of review and writing of the manual.
Should we create a documentation team, of which you could be a honorary
member?  :-)

I feel like ensuring doc consistency, be it regarding the content,
terminology, typography, or use of markup, is a job in its own that
could be best reviewed by people familiar with and interested in those
issues.

WDYT?

Ludo’.

diff --git a/etc/teams.scm b/etc/teams.scm
index d537e83efc..4d65a5476e 100755
--- a/etc/teams.scm
+++ b/etc/teams.scm
@@ -434,6 +434,16 @@ (define-team core
   (make-regexp* "^guix/scripts/")
   (make-regexp* "^guix/store/"
 
+(define-team documentation
+  (team 'documentation
+#:name "Documentation"
+#:description "Documentation: the manual and cookbook."
+#:scope (list (make-regexp* "\\.texi$")
+  "doc/build.scm"
+  "gnu/system/examples/bare-bones.tmpl"
+  "gnu/system/examples/lightweight-desktop.tmpl"
+  "gnu/system/examples/desktop.tmpl")))
+
 (define-team core-packages
   (team 'core-packages
 #:name "Core packages"

Re: Adding plumbing subcommand 'derivation'?

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

> On ven., 12 avril 2024 at 20:04, Leo Famulari  wrote:
>
>>> Do you think it would be useful to package it?  Or maybe to include it
>>> as another subcommand (or part of some subcommand)?
>>
>> I'd love for this to be built in to Guix. I'm often struggling to read
>> derivations while debugging or analysing something.
>
> So I propose to add the plumbing command ’derivation’.  Any objection?

We should see how that fits into the set of tools we already have, in
particular the (guix derivations) interface and the REPL meta-commands.

My gut feeling, with a Schemer bias, is that we’d rather enrich the
Scheme API and/or REPL than add more commands (this is not Nix :-)).

But I don’t know, maybe we can have both?

Ludo’.

Re: Distributed GNU Shepherd NLNet Grant

[Development of GNU Guix and the GNU System distribution.]

Hi Juli,

On Thu, Apr 18 2024, Juliana Sims wrote:

> I submitted an application for an NLNet grant to fund porting our
> beloved Shepherd to Spritely Goblins

Wow, I'm not sure what that will do just yet, but I can't wait to hear
more!

> I am happy to announce that this grant application was approved!

Congratulations!

Kind regards
Felix

P.S. Please have a look at ZeroMQ for your sockets, if you haven't.

Sustainability fund application ongoing

[Maxim Cournoyer]

Hello Guix,

It was pointed to us that the "Free and Open Source Software
Sustainability Fund" [0] is currently receiving applications.  The fund
aim to sponsors free software projects for their
maintenance/organisational activities.

I'm tempted to apply myself, but I thought I'd share it here: the more
submissions they get the more likely Guix is to receive support.

-- 
Thanks,
Maxim

Re: Distributed GNU Shepherd NLNet Grant

[Ricardo Wurmus]

Hi Juli,

> I am happy to announce that this grant application was approved! [2]

Congratulations!

> Materially, it would allow Shepherd dæmons running on
> different machines to securely communicate and interact with each
> other, going so far as to control one machine's dæmons from another
> machine.

I'm very interested in this.  Back when I worked on the Swineherd I
wanted to eventually extend it so that it can communicate with other
Swineherd instances to migrate Guix System containers between
cooperating machines.  Having this feature at the foundation of the
implementation of the Shepherd is much preferable to implementing a pale
compromise of this in an extension.

It also reminds me of Mach's cross-node message passing that could be
used to turn the Hurd into a Single System Image cluster.

Exciting stuff!  I wish you success and lots of fun working on this
project.

-- 
Ricardo