[PATCH] service: systemd: use correct format for LISTEN_FDNAMES

[Bastien Rivière]

Hello,

This is a patch for shepherd's "make-systemd-constructor" which creates an 
invalid environment variable when there is more than one listen endpoint.

Best regards,
BastienFrom fdabd4ee6d43e32cbf9bd85282ff66138ce652b9 Mon Sep 17 00:00:00 2001
From: Bastien Riviere 
Date: Sat, 7 May 2022 01:08:28 +0200
Subject: [PATCH] service: systemd: use correct format for LISTEN_FDNAMES

As in the documentation, LISTEN_FDNAMES is expected to be a "colon-separated
list of names".
This patch add the missing delimiter when joining to LISTEN_FDNAMES.

This fixes issues with services, like gpg-agent, which produces this kind of
error:

> [gpg-agent] Fatal: number of items in LISTEN_FDNAMES (1) does not match LISTEN_FDS (4) in --supervised mode
---
 modules/shepherd/service.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index 81bd667..f343938 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -352,7 +352,7 @@ wire."
 (define-method (running? (obj ))
   (and (service-running-value obj) #t))
 
-;; Return a list of all actions implemented by OBJ. 
+;; Return a list of all actions implemented by OBJ.
 (define-method (action-list (obj ))
   (map action-name (slot-ref obj 'actions)))
 
@@ -1594,7 +1594,8 @@ This must be paired with @code{make-systemd-destructor}."
(number->string (length sockets)))
 (string-append "LISTEN_FDNAMES="
(string-join
-(map endpoint-name endpoints)
+(map endpoint-name endpoints)
+":"
(running   sockets))
   (spawn-fiber
(lambda ()
-- 
m...@babariviere.com

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Freitag, dem 06.05.2022 um 21:54 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op vr 06-05-2022 om 20:40 [+0200]:
> > Note that 'applications' is not really a useful category.
> 
> It is a clear thematic division to me.  Though it's a bit large,
> maybe 'applications' could be divided futher in more specific themes
> (‘office’ apps, games, terminal utilities, ...).
Yeah, that division makes more sense, but note that none of the
categories you cited call specifically for SSL_CERT_DIR/FILE.  It
really is curl, which you might categorize as "terminal utility", but
more accurately fits into "web" along with nss-certs, for example.

> > But what's more both nss-certs, glibc-locales and other packages
> > that on their own provide everything you need in a search path can
> > already be handled easily with existing mechanisms of Guix Home.
> 
> I haven't found any such mechanism -- I haven't found any hits for
> 'GUIX_LOCPATH' or SSL_CERT_DIR/FILE'.  At most I've found
> 'environment-variables->setup-environment-script', but as user I just
> want to add packages to a profile and have it work without having to
> manually fiddle with environemnt variables.
I'm pretty sure Guix Home allows you to write your bashrc with gexps,
no?  So you could put (string-append "export SSL_CERT_DIR=" #$nss-certs
"/etc/ssl/certs") in there IIRC.

> > This is not a use case that calls for multiple profiles
> 
> A separate 'data' profile looks like a use case for multiple thematic
> profiles to me.  As I understood it, being able to separate profiles
> as you like is the point of the proposed Guix Home?  Why prevent the
> user from making a ‘data’ profile?  Maybe a separate profile for time
> zones, certificates and locales doesn't seem useful to you, but it
> seems a practical subdivison to me.
Perhaps, but this requires more than simply a declarative way of
managing profiles, which is the main point here.  It would require
search-paths as first class citizens of profiles in addition to that,
which I already mentioned a few times in between.

> > and the fix to missing these single packages (assuming you want it
> > expressed solely in terms of profiles) would be to add them back to
> > the default profile 
> 
> Merging the 'data' profile (or other profiles) back into another
> profile kind of defeats the purpose of aseparate profiles.  What if I
> don't have any default profile (or if a default profile is
> technically required, keep it empty)?
Well, even if you name it "data" your data profile would then be the de
facto default profile.  For the record, I'm not saying that the default
profile in ~/.guix-profile would be a hard requirement going forward,
because to a certain extent, managing multiple profiles with Guix Home
already addresses both the choice of its name and its location.  What
it does not (yet) address is the fact that you'll probably have a
kitchen sink profile left after neatly sorting all the other packages
into themes.  For now this seems to be as much a technical limitation
as it is a condition of human nature.  I'm fairly certain that we'll
start to see such extensions once we've implemented the system and
people are dissatisfied with the fact that they can't have a meaningful
data profile – thus either extending the home-profile-service-type to
account for those or finding other solutions that compose well through
guix home or guix itself.

Cheers

Re: Multiple profiles with Guix Home

[Maxime Devos]

Liliana Marie Prikler schreef op vr 06-05-2022 om 20:40 [+0200]:
> Note that 'applications' is not really a useful category.

It is a clear thematic division to me.  Though it's a bit large, maybe
'applications' could be divided futher in more specific themes
(‘office’ apps, games, terminal utilities, ...).

>  But what's
> more both nss-certs, glibc-locales and other packages that on their own
> provide everything you need in a search path can already be handled
> easily with existing mechanisms of Guix Home.

I haven't found any such mechanism -- I haven't found any hits for
'GUIX_LOCPATH' or SSL_CERT_DIR/FILE'.  At most I've found 'environment-
variables->setup-environment-script', but as user I just want to add
packages to a profile and have it work without having to manually
fiddle with environemnt variables.

> This is not a use case that calls for multiple profiles

A separate 'data' profile looks like a use case for multiple thematic
profiles to me.  As I understood it, being able to separate profiles as
you like is the point of the proposed Guix Home?  Why prevent the user
from making a ‘data’ profile?  Maybe a separate profile for time zones,
certificates and locales doesn't seem useful to you, but it seems a
practical subdivison to me.

> and the fix to missing these single
> packages (assuming you want it expressed solely in terms of profiles)
> would be to add them back to the default profile 

Merging the 'data' profile (or other profiles) back into another
profile kind of defeats the purpose of aseparate profiles.  What if I
don't have any default profile (or if a default profile is technically
required, keep it empty)?


Greetings,
Maxime.


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

Re: Multiple profiles with Guix Home

[Liliana Marie Prikler]

Am Donnerstag, dem 05.05.2022 um 22:26 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op do 05-05-2022 om 20:24 [+0200]:
> > > This doesn't work for SSL_CERT_DIR/SSL_CERT_FILE
> > nss-certs can be installed to their own profile and referenced from
> > there
> 
> No, if it is installed in its own profile, then
> SSL_CERT_DIR/SSL_CERT_FILE won't be set:
> 
> * Put nss-certs its own 'certificates' profile.
> * Put curl in a 'applications' profile.
> 
> 'curl' has a SSL_CERT_FILE search path.  However, its profile does
> not have the etc/ssl/certs/ca-certificates.crt, so the SSL_CERT_FILE
> environment variable will not be defined for 'applications'
Note that 'applications' is not really a useful category.  But what's
more both nss-certs, glibc-locales and other packages that on their own
provide everything you need in a search path can already be handled
easily with existing mechanisms of Guix Home.  This is not a use case
that calls for multiple profiles and the fix to missing these single
packages (assuming you want it expressed solely in terms of profiles)
would be to add them back to the default profile which still has its
uses no matter how clean you want the split to be.


Cheers

[ANN] Dezyne 2.15.0 released as Free Software

[Jan Nieuwenhuizen]

We are thrilled to announce Dezyne 2.15: Dezyne is now being released as
Free Software (FLOSS).

* About

Dezyne[0] is a programming language and a set of tools to specify,
validate, verify, simulate, document, and implement concurrent control
software.

The Dezyne language has formal semantics expressed in mCRL2[1] developed at
the department of Mathematics and Computer Science of the Eindhoven
University of Technology (TUE[2]).  Dezyne requires that every model is
finite, deterministic and free of deadlocks, livelocks, and contract
violations.  This achieved by means of the language itself as well as
by builtin verification through model checking.  This allows the
construction of complex systems by assembling independently verified
components.

* Summary

This release completes full support for blocking: This finally marks
the Grand Unification into single threaded execution semantics.

The documentation has seen a major rewrite and is available here:
.

We will evaluate your reports and track them via the
Gitlab dezyne-issues project[3], see our guide to writing
helpful bug reports[4].

* What's next?

Verification with system scope and automatically exploring possible
traces in a system.  Introducing a new keyword `defer' for asynchronous
behavior and deprecation of `async'.

* Future

Looking beyond the next releases we will introduce implicit interface
constraints.  Hierarchical behaviors, module-specifications and
data-interfaces.  Support for Model Based Testing.

Please do not hesitate to forward this announcement to other fora
interested in formal methods and verification!

Enjoy!
The Dezyne developers.

* Download

  git clone git://git.savannah.nongnu.org/dezyne.git

  Here are the compressed sources and a GPG detached signature[*]:
https://dezyne.org/download/dezyne/dezyne-2.15.0.tar.gz
https://dezyne.org/download/dezyne/dezyne-2.15.0.tar.gz.sig

  Here are the SHA1 and SHA256 checksums:

395ff05e4f2c17bcee895fd9436d696fb0aab93d  dezyne-2.15.0.tar.gz
982d8f7cca9de23225e2f06b4c8524c0b57acfba81beaaff1a0c045c1e6409ea  
dezyne-2.15.0.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify dezyne-2.15.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 
1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

  and rerun the 'gpg --verify' command.

  Alternatively, Dezyne can be installed using GNU Guix[5]:
guix pull
guix install dezyne

* NEWS

* Changes in 2.15.0 since 2.14.0
** Language
  - Blocking is now fully supported, it may be used:
+ In non-toplevel components,
+ In a component with multiple provides ports, but see the
  `Blocking' section in the manual for caveats.
+ A new `blocking' qualifier for ports must be used if a port can
  block, or block collateraly.
  - Using unobservable non-determinism in interfaces is no longer
supported.
  - An action or function call can now also be used in a return
expression (#67[5]).  Note that recursive functions still cannot be
valued.
** Commands
  - The `dzn explore' command has been removed.
** Verification
  - The verifier now supports blocking for components with multiple
provides ports.
  - The verifier now detects possible deadlock errors due to a requires
action blocking collaterally, which could happen when a component
deeper in the system hierarchy uses blocking.
  - The option `--no-interface-determinism' has been removed for `dzn
verify'.
** Simulation
  - The simulator now supports collateral blocking.
  - In interactive mode:
+ The new `,state' command shows the state (#66[6]),
+ The new `,quit' command exits the session,
+ The simulator does not exit when supplying empty input.
  - The simulator now detects possible deadlock errors due to a requires
action blocking collaterally, which could happen when a component
deeper in the system hierarchy uses blocking.
  - The simulator now detects livelocks in interfaces at end of trail.
  - The simulator now detects queue-full errors caused by external at
end of trail.
  - The `dzn simulate' command now supports the `-C,--no-compliance',
`--no-interface-livelock' and `-Q,--no-queue-full' options,
** Code
  - The C++ and C# code generators and runtime now fully support
collaterally blocking components.
** Views
  - Returns are no longer removed from the state-diagram.  Using the new
`--hide=returns' (or `--hide=actions') now removes void action
returns.
** Documentation
  - Blocking has been updated and extended.
  - A new section on foreign components was added.
** Noteworthy bug fixes
  - Using the construct `provides external' (which has no semantics) no

Documentation Meetup

[Raghav Gururajan]

Hello Guix!

WhereIsEveryone community is hosting a meetup regarding documentation in 
Guix.

We'll be discussing and/or working on; adding new contents, removing 
obsolete contents and improving contents where required.
The outcome of the meetup will be recorded, organized and sent to Guix upstream.

DATE: Saturday, May 14, 2022.
TIME: 15:00 UTC
Duration: ~1.5hrs

LINK: https://meet.nixnet.services/b/rag-8bi-sdx-kdf

Regards,
Raghav "RG" Gururajan.

P.S.
The output of last meetup hasn't been sent to Guix upstream yet.

Re: Should Guix Home daemonize Shepherd?

[Andrew Tropin]

On 2022-03-12 18:49, Kevin Boulain wrote:

> So, I've done some digging and I'm coming back with two findings :)
>
> First, Guix Home correctly tells the user Shepherd to daemonize itself
> via an 'action'
> (https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm#n64)
> but, from my understanding, the daemonization process is missing at
> least a setsid call
> (https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1421),
> see the attached 'shepherd-setsid.patch'. This fixes the Shepherd
> dying when exiting the SSH session or the Shepherd catching the ^C.
> I guess it should also close std{in,out,err} like it's done for the
> regular services
> (https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n806)
> but this answers a part of my initial post.

CCed Leo, Ludovic and Carlo.

>
> Second, elogind (it's required by Guix Home to get the XDG_*
> environment variables and also part of %desktop-services) will remove
> /run/user/$uid when the session ends. 

Actually, XDG_RUNTIME_DIR can be provided not only by elogind, but also
by pam_rundir or something similar, however in general it's true,
runtime dir will be removed when session ends.

> It's standard, but the problem is that Guix Home's
> 'on-first-login-executed' is located there, alongside
> 'shepherd/socket' and probably the other user daemon's sockets. This
> easily results in duplicate services being rerun when the old ones
> haven't been killed because 'KillUserProcesses' is set to 'no' by
> default
> (https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/desktop.scm#n937).
> I don't think it's a bad idea to set KillUserProcesses=no (I remember
> that when this was first introduced a lot of users complained, see for
> example https://github.com/tmux/tmux/issues/428) but now we're in an
> awkward position unless Guix Home users move everything out of
> XDG_RUNTIME_DIR (for example, tmux's socket is in /tmp).
>
> Thoughts? I must admit, I'm not sure how to address the elogind issue,
> XDG_RUNTIME_DIR is ingrained in a lot of places (even in the Shepherd
> https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/support.scm#n284)
> and asking users to override socket flags (and others) for all the
> services they run (if at all possible) sounds a bit counterintuitive.

This is a tough question, faced it when only started to work on Guix
Home.  One idea I had back in the days is to have a possibility to get
lingering user shepherd, which starts on boot, the implementation
doesn't seem trivial so I decided to postpone experiments in this
direction for a better times.  Not sure if it's any perfect, but at
least is something to think about.

> Or am I missing something obvious?
> Detach from the controlling terminal when daemonizing
>
> https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00040.html
>
> diff --git c/modules/shepherd/service.scm w/modules/shepherd/service.scm
> index ad8608b..62f97bc 100644
> --- c/modules/shepherd/service.scm
> +++ w/modules/shepherd/service.scm
> @@ -1420,8 +1420,12 @@ we want to receive these signals."
>(else
> (if (zero? (primitive-fork))
> (begin
> - (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> - #t)
> + (setsid)
> + (if (zero? (primitive-fork))
> + (begin
> +   (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> +   #t)
> + (primitive-exit 0)))
> (primitive-exit 0))
>   (persistency
>"Save the current state of running and non-running services.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Updating mumi on berlin

[zimoun]

Hi Thiago,

On Fri, 06 May 2022 at 00:22, Thiago Jung Bauermann  
wrote:

> I didn't go that route because I don't like disabling tests without
> understanding why they fail and it took me a while to understand the
> zombie root cause. In addition to that, without the testsuite passing I
> didn't feel confident that I would be proposing a good enough package
> because virtually the only part of public-inbox that I use is lei
> itself. What if there was a regression in other parts of it and I didn't
> notice because I use so little?
>
> But I wouldn't mind disabling the part that checks that lei-daemon is
> truly gone, or even the whole testsuite if that is too complicated.
>
> On the other hand, the preferred solution would be the workaround
> pointed out by Maxim, where tini is used to run the testsuite and reap
> its sub-processes. I can probably take a stab at it over the weekend if
> no one beats me to it.

For sure.  For it is worth, I try to keep in mind, :-)

Now is better than never.
Although never is often better than *right* now.

– The Zen of Python, by Tim Peters –

and

Perfect is the enemy of good

– commonly attributed to Voltaire –


Cheers,
simon

Re: public-inbox v1.7 update (was: Updating mumi on berlin)

[zimoun]

Hi Kyle,

Thanks for the answer.


On Thu, 05 May 2022 at 22:24, Kyle Meyer  wrote:
> zimoun writes:

>> How do you query all new ones for a specific list?
>
> Rather than pass --all, you can call `lei up OUTPUT', where OUTPUT is a
> particular saved search generated by `lei q', so you could have a saved
> search that's specific for a list or set of lists:
>
>$ lei ls-external | grep guix
>/home/kyle/inboxes/guix-bugs boost=0
>/home/kyle/inboxes/guix-devel boost=0
>/home/kyle/inboxes/guix-patches boost=0
>/home/kyle/inboxes/guix-science boost=0
>/home/kyle/inboxes/guix-user boost=0
>
>$ lei q -I 'guix-*' -o /tmp/zimoun-on-guix d:20.days.ago.. f:zimoun
>$ lei up /tmp/zimoun-on-guix
>
> See https://public-inbox.org/lei-up.txt and
> https://public-inbox.org/lei-q.txt

For people considering the volume of the lists too much, the “saved
search” is a perfect mechanism.  For instance, it is a nice improvement
to follow guix-patches, IMHO.

However, considering guix-science, for example, the volume is not too
high, and the “saved search” would be: all the messages.

Using the public-inbox Git repo, I just run “guix fetch”, and somehow
the commits in the range master..origin/master are all the new ones.
I can convert them to maildir or whatever.

Well, using the plain Git repo, it is easy to:

 1. get messages from a list starting at a date;
using ’git clone --mirror --shallow-since=’

 2. get all the new messages;
(using ’git pull)

Git becoming the way to transport the information.

However, I have to choose the storage format (Git vs Maildir) to avoid
unnecessary duplication on my poor laptop.  I use Maildir because I can
easily index and search (notmuch) and read (emacs) locally; by locally,
I mean when I am offline.  Therefore, I have to run “git gc” and prune
already imported messages.

IIUC, ’lei’ avoid this manual dance with the Git repo and do it for me.

Well, what I miss is the lei “saved search” query for all messages.
Other said,

lei q d:..
lei up

fits #1.  Then, how do I achieve #2?

The workflow using “saved search” is not clear for me.  Before investing
some time, especially when ’lei’ is not packaged in Guix, I would like
to be sure about how to run «my workflow».


Cheers,
simon

Re: RFC: Configurable placing of the ~/.guix-home symlink

[Andrew Tropin]

On 2022-05-05 06:55, Attila Lendvai wrote:

>> When trying to get a clean $HOME, I see that the ~/.guix-home path is fixed 
>> in
>> the code under gnu/home/*,
>> usually via (string-append (GETENV "HOME") "/.guix-home").
>
> FWIW, i was also surprised that the default is not something under 
> ~/.config/guix/

It also can be problematic, we can't hardcode ~/.config/guix home due to
XDG spec, and at the same time XDG_CONFIG_HOME can be managed by Guix
Home, but also can be set outside, and all the points mentioned above
applicable here as well.

Back in the day, the implementation of Guix Home required a symlink in
home directory, right now due to improvements in symlink-manager and
reconfigure code it's probably not necessary and with a few patches
/var/guix/profiles/per-user/bob/guix-home/ can be used instead.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature