Re: A Critique of Shepherd Design

[Mark H Weaver]

Hi,

raid5atemyhomework  writes:

> GNU Shepherd is the `init` system used by GNU Guix.  It features:
>
> * A rich full Scheme language to describe actions.
> * A simple core that is easy to maintain.
>
> However, in this critique, I contend that these features are bugs.
>
> The Shepherd language for describing actions on Shepherd daemons is a
> Turing-complete Guile language.  Turing completeness runs afoul of the
> Principle of Least Power.  In principle, all that actions have to do
> is invoke `exec`, `fork`, `kill`, and `waitpid` syscalls.

These 4 calls are already enough to run "sleep 1000" and wait
for it to finish, or to rebuild your Guix system with an extra patch
added to glibc.

> Yet the language is a full Turing-complete language, including the
> major weakness of Turing-completeness: the inability to solve the
> halting problem.
>
> The fact that the halting problem is unsolved in the language means it
> is possible to trivially write an infinite loop in the language.  In
> the context of an `init` system, the possibility of an infinite loop
> is dangerous, as it means the system may never complete bootup.

Limiting ourselves to strictly total functions wouldn't help much here,
because for all practical purposes, computing 10^100 digits of Pi is
just as bad as an infinite loop.

That said, I certainly agree that Shepherd could use improvement, and
I'm glad that you've started this discussion.

At a glance, your idea of having Shepherd do more within subprocesses
looks promising to me, although this is not my area of expertise.

 Thanks,
   Mark

Re: A Critique of Shepherd Design

[Maxim Cournoyer]

Hi,

raid5atemyhomework  writes:

> GNU Shepherd is the `init` system used by GNU Guix.  It features:
>
> * A rich full Scheme language to describe actions.
> * A simple core that is easy to maintain.
>
> However, in this critique, I contend that these features are bugs.
>
> The Shepherd language for describing actions on Shepherd daemons is a
> Turing-complete Guile language.  Turing completeness runs afoul of the
> Principle of Least Power.  In principle, all that actions have to do
> is invoke `exec`, `fork`, `kill`, and `waitpid` syscalls.  Yet the
> language is a full Turing-complete language, including the major
> weakness of Turing-completeness: the inability to solve the halting
> problem.
>
> The fact that the halting problem is unsolved in the language means it
> is possible to trivially write an infinite loop in the language.  In
> the context of an `init` system, the possibility of an infinite loop
> is dangerous, as it means the system may never complete bootup.
>
> Now, let us combine this with the second feature (really a bug): GNU
> shepherd is a simple, single-threaded Scheme program.  That means that
> if the single thread enters an infinite loop (because of a Shepherd
> service description that entered an infinite loop), then Shepherd
> itself hangs.  This means that the system is severely broken.  You
> cannot `sudo reboot` because that communicates with the Shepherd
> daemon.  You cannot even `kill 1` because signals are handled in the
> mainloop, which never get entered if the `start` action of some
> Shepherd daemon managed to enter an infinite loop.
>
> I have experienced this firsthand since I wrote a Shepherd service to
> launch a daemon, and I needed to wait for the daemon initialization to
> complete.  My implementation of this had a bug that caused an infinite
> loop to be entered, but would only tickle this bug when a very
> particular (persistent on-disk) state existed.  I wrote this code
> about a month or so ago, and never got to test it until last week,
> when the bug was tickled.  Unfortunately, by then I had removed older
> system versions that predated the bug.  When I looked at a backup copy
> of the `configuration.scm`, I discovered the bug soon afterwards.  But
> the amount of code verbiage needed here had apparently overwhelmed me
> at the time I wrote the code to do the waiting, and the bug got into
> the code and broke my system.  I had to completely reinstall Guix
> (fortunately the backup copy of `configuration.scm` was helpful in
> recovering most of the system, also ZFS rocks).
>
> Yes, I made a mistake.  I'm only human.  It should be easy to recover
> from mistakes.  The full Turing-completeness of the language invites
> mistakes, and the single-threadedness makes the infinite-loop mistakes
> that Turing-completeness invites, into catastrophic system breakages.
>
> So what can we do?
>
> For one, a Turing-complete language is a strict *superset* of
> non-Turing-complete languages.  So one thing we can do is to define a
> more dedicated language for Shepherd actions, strongly encourage the
> use of that sub-language, and, at some point, require that truly
> Turing-complete actions need to be wrapped in a
> `(unsafe-turing-complete ...)` form.
>
> For example, in addition to the current existing
> `make-forkexec-constructor` and `make-kill-destructor`, let us also
> add these syntax forms:
>
> `(wait-for-condition  )` - Return a procedure that
> accepts a numeric `pid`, that does: Check if evaluating `` in
> the lexical context results in `#f`.  If so, wait one second and
> re-evaluate, but exit anyway and return `#f` if `` seconds
> has passed, or if the `pid` has died.  If `` evaluates to
> non-`#f` then return it immediately.
>
> `(timed-action   ...)` - Return a procedure that
> accepts a numeric `pid`, that does: Spawn a new thread (or maybe
> better a `fork`ed process group?).  The new thread evaluates `
> ...` in sequence.  If the thread completes or throws in ``
> seconds, return the result or throw the exception in the main thread.
> IF the `` is reached or the given `pid` has died, kill the
> thread and any processes it may have spawned, then return `#f`.
>
> `(wait-to-die )` - Return a procedure that accepts a `pid`
> that does: Check if the `pid` has died, if so, return #t.  Else sleep
> 1 second and try again, and if `` is reached, return `#f`.
>
> The above forms should also report as well what they are doing
> (e.g. `Have been waiting 10 of 30 seconds for `) on the console
> and/or syslog.
>
> In addition, `make-forkexec-constructor` should accept a
> `#:post-fork`, which is a procedure that accepts a `pid`, and
> `make-kill-destructor` should accept a `#:pre-kill`, which is a
> procedure that accepts a `pid`.  Possibly we need to add combinators
> for the above actions as well.  For example a `sub-actions` procedural
> form that accepts any number of functions of the above `pid -> bool`
> type and creates a single combined `pid -> bool`.
>
> So 

Re: A Critique of Shepherd Design

[raid5atemyhomework]

Hello Maxime,

> Multi-threading seems complicated (but can be worth it). What work would you 
> put
> on which thread (please give us some concrete to reason about, ‘thread X does 
> A,
> and is created on $EVENT ...’)? A complication is that "fork" is ‘unsafe’ in a
> process with multiple threads (I don't know the details). Maybe that could be
> worked around. (E.g. by using system* on a helper binary that closes unneeded
> file descriptors and sets the umask  and eventually uses exec to run the
> service binary.)

Perhaps the point is not so much to be *multi-threaded* but to be *concurrent*, 
and whether to be multi-*thread* or multi-*process* or multi-*fiber* is a 
lower-level detail.

For example, we can consider that for 99% of shepherd services, the `start` 
action returns a numeric PID, and the remaining ones return `#t`.  Rather than 
call the `start` action in the same thread/process/fiber that implements the 
Shepherd main loop:

* Create a pipe.
* `fork`.
  * On the child:
* Close the pipe output end, make the input end cloexec.
* Call the `start` action.
* If an error is thrown, print out `(error <>)` with the serialization of 
the error to the pipe.
* Otherwise, print out `(return <>)` with the return value of the `start` 
action.
  * On the parent:
* Close the pipe input end, and add the output end and the pid of the 
forked child to one of the things we will poll in the mainloop.
* Return to the mainloop.
* In the mainloop:
  * `poll` (or `select`, or whatever) the action pipes in addition to the 
`herd` command socket(s).
  * If an action pipe is ready, read it in:
* If it EOFed then the sub-process died or execed without returning 
anything, treat as an error.
* Similarly if unable to `read` from it.
* Otherwise deserialize it and react appropriately as to whether it is an 
error or a return of some value.
  * If an action pipe has been around too long, kill the pid (and all child 
pids) and close the pipe and treat as an error.

I mean --- single-threaded/process/fibered, non-concurrent `init` systems have 
fallen by the wayside because of their brittleness.  SystemD is getting wide 
support precisely because it's an excellent concurrent `init` mechanism that is 
fairly tolerant of mistakes; a problem in one service unit is generally 
isolated in that service unit and its dependents and will not cause problems 
with the other service units.

Presumably, `fork`ing within a `fork`ed process has no issues since that is 
what is normally done in Unix anyway, it's threads that are weird.


> That's a bit of an over-simplification. At least in a singly-threaded 
> Shepherd,
> waitpid could not be used by an individual service, as it
> (1) returns not often
> enough (if a process of another service exits and this action was waiting on
> a single pid) (2) too often (likewise,
> and this action was ‘just waiting’
> (3) potentially never (imagine every process has been started and an action
> was waiting for one to exit,
> and now the user tries to reboot. Then shepherd
> daemon would never accept the connection from the user!).

Yes, I agree it is an oversimplification, but in any case, there should be some 
smaller subset of things that can be (typically) done.

Then any escape hatch like `unsafe-turing-complete` or 
`without-static-analysis` can retain the full power of the language for those 
times when you *really* do need it.

>
> And in a multi-threaded Shepherd, "fork" is unsafe. (Anyway, "fork" captures
> too much state, and no action should ever call "exec" without "fork".) Also,
> "exec" replaces too little state (e.g. open file descriptors, umask, root
> directory, current working directory ...).
>
> But perhaps that's just a call for a different set of primitives (which could
> be implemented on top of these system calls by shepherd, or directly on top
> of the relevant Hurd RPCs when running on GNU/Hurd.).

Yes.

> > Yet the language is a full Turing-complete language, including the major
> > weakness of Turing-completeness: the inability to solve the halting problem.
>
> IIUC, there are plans to perform the network configuration inside shepherd
> (search for guile-netlink). So arbitrary code still needs to be allowed.
> This is the Procedural (extensible) I'll referring to later.
>
> > The fact that the halting problem is unsolved in the language means it is
> > possible to trivially write an infinite loop in the language. In the context
> > of an `init` system, the possibility of an infinite loop is dangerous, as it
> > means the system may never complete bootup.
>
> I'm assuming the hypothetical infinite loop is in, say, the code for starting
> guix-daemon which isn't very essential (try "herd stop guix-daemon"!)
> (If there's an infinite loop is in e.g. udev-service-type then there's indeed
> a problem, then that infinite loop might as well be in eudev itself, so I'm
> only speaking of non-essential services blocking the boot process.)
>

Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

[Mark H Weaver]

Leo Famulari  writes:

> On Thu, Mar 18, 2021 at 09:40:04AM -0400, Mark H Weaver wrote:
>> I knew this couldn't be right, but I thought I remembered it having
>> fewer dependencies.  Oh well.  Sorry for the noise.
>
> It's relatively new that ImageMagick is depended on by so many packages.
> I think we should look into this and see if we can significantly reduce
> the number.

The following dependency chain seems to be responsible for most of the
imagemagick-dependent packages:

gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick

  Mark

Re: Release 1.2.1: status

[Luis Felipe]

Hi zimoun :)


‐‐‐ Original Message ‐‐‐
On Thursday, March 18, 2021 2:28 PM, zimoun  wrote:

[...]

> We are still missing a good story to monitor what is archived on
> Software Heritage and what is not. Because for now there is rate limit,
> I am not able to automate… Well, it is a long WIP. :-)
>
> To help and avoid this rate limit, if all of us simply run:
>
> for pkg in $(guix package -I | cut -f1);
> do
> guix lint -c archival $pkg
> done
>
> for all our profiles, it will ensure at least a coverage for the
> packages using git-fetch that we individually care. Note the option
> --manifest for “guix lint” is missing… should happen soon if no one
> beats me. :-)

I tried this with my user profile and the script hit the Software heritage 
limit after reporting the status of 33 packages (most of which are not 
archived). So, for the rest of the packages, you are asked to try again later 
(I have 95 packages in my profile).

Is "guix lint -c archival $pkg" supposed to poke Software Heritage to archive 
the $pkg if it is not archived yet? I ask because I ran the script later and I 
got the same output from the first run, i.e., packages reported to be missing 
from Software Heritage were still reported as such, instead of being planned 
for archive.

Also, I got a backtrace when checking icecat:

★★★
gnu/packages/virtualization.scm:1070:5: libvirt@5.8.0: Software Heritage rate 
limit reached; try again later
Backtrace:cecat@78.8.0-guix0-preview1 [archival]...
  12 (primitive-load "/home/yo/.config/guix/current/bin/guix")
In guix/ui.scm:
  2164:12 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10 10 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15  9 (with-exception-handler # ?)
In srfi/srfi-1.scm:
634:9  8 (for-each # ?)
In guix/scripts/lint.scm:
 65:4  7 (run-checkers # ?)
In srfi/srfi-1.scm:
634:9  6 (for-each # ?)
In guix/scripts/lint.scm:
74:21  5 (_ _)
In guix/lint.scm:
   1225:4  4 (check-archival _)
   1092:2  3 (call-with-networking-fail-safe _ _ _)
In ice-9/boot-9.scm:
  1736:10  2 (with-exception-handler _ _ #:unwind? _ # _)
  1669:16  1 (raise-exception _ #:continuable? _)
  1667:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1667:16: In procedure raise-exception:
In procedure bv-length: Wrong type argument in position 1 (expecting 
bytevector): #f
★★★

Re: Release 1.2.1: status

[Luis Felipe]

‐‐‐ Original Message ‐‐‐
On Friday, March 19, 2021 6:31 PM, Andreas Enge  wrote:

> Hello,
>
> Am Thu, Mar 18, 2021 at 03:28:38PM +0100 schrieb zimoun:
>
> > guix weather --display-missing
>
> I am giving it a try, but after about one hour at 100% CPU on one core it
> is still only half way through. Is this normal? I think I will stop it to
> at least redirect the output into a file...


In my case, after ~20 minutes, it progressed about 20-30%, and then the 
progress bar got reset and started again. Later, an hour and ten minutes have 
passed since I ran the command, it reached around 30% again, progressing very, 
very slowly. Then, a gnu-tls error occurred:

★★★
Backtrace:
  11 (primitive-load "/home/yo/.config/guix/current/bin/guix")
In guix/ui.scm:
  2164:12 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15  8 (with-exception-handler # …)
In guix/scripts/weather.scm:
552:9  7 (_)
In guix/build/utils.scm:
   569:23  6 (every* # …)
In guix/scripts/weather.scm:
   553:19  5 (_ "https://ci.guix.gnu.org;)
   116:17  4 (report-server-coverage _ _ #:display-missing? _)
In unknown file:
   3 (_ # . #)
In guix/substitutes.scm:
   315:31  2 (lookup-narinfos _ _ #:open-connection _ # _)
   238:26  1 (fetch-narinfos _ _ #:open-connection _ # _)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `gnutls-error' with args `(# read_from_session_record_port)'.
★★★

The text in # is Spanish, 
meaning something like: Error in the push function.

This is my system information:

OS: Guix System 1ab03fb74505458e7754dce338a5da29dc754d80 x86_64
Kernel: 5.11.7-gnu
CPU: Intel i3-8100 (4) @ 3.600GHz
GPU: Intel 8th Gen Core Processor Gaussian Mixture Model
Memory: 1804MiB / 3766MiB

Re: A Critique of Shepherd Design

[Maxime Devos]

On Fri, 2021-03-19 at 17:33 +, raid5atemyhomework wrote:
> GNU Shepherd is the `init` system used by GNU Guix.  It features:
> 
> * A rich full Scheme language to describe actions.
> * A simple core that is easy to maintain.
> 
> However, in this critique, I contend that these features are bugs.

A lot of unpack here!  Some agreements, some disagreements,
some alternative proposals, maybe some misunderstandings:

* Section 1: Singly-threading (simple) or multi-threading (robust if done well)

> Now, let us combine this with the second feature (really a bug): GNU shepherd
> is a simple, single-threaded Scheme program.  That means that if the single
> thread enters an infinite loop (because of a Shepherd service description
> that entered an infinite loop), then Shepherd itself hangs.  This means that
> the system is severely broken.  You cannot `sudo reboot` because that 
> communicates
> with the Shepherd daemon.  You cannot even `kill 1` because signals are 
> handled in
> the mainloop, which never get entered if the `start` action of some Shepherd 
> daemon
> managed to enter an infinite loop.

I don't think simplicity is in the ‘design goals’ of shepherd -- it's primarily
used within Guix System (though it can be used outside Guix), which I would not
call simple (-:.

Multi-threading seems complicated (but can be worth it).  What work would you 
put
on which thread (please give us some concrete to reason about, ‘thread X does A,
and is created on $EVENT ...’)?  A complication is that "fork" is ‘unsafe’ in a
process with multiple threads (I don't know the details).  Maybe that could be
worked around.  (E.g. by using system* on a helper binary that closes unneeded
file descriptors and sets the umask  and eventually uses exec to run the
service binary.)

* Section 2: Scheme too powerful?

> The Shepherd language for describing actions on Shepherd daemons is a 
> Turing-complete Guile language.

There isn't really a ‘Shepherd language’, it's ‘just’ Scheme code and shepherd 
is ‘merely’ a library.
But I guess that's your point.

>   Turing completeness runs afoul of the Principle of Least Power.
>   In principle, all that actions have to do is invoke `exec`, `fork`, `kill`, 
> and `waitpid` syscalls.

That's a bit of an over-simplification.  At least in a singly-threaded Shepherd,
waitpid could not be used by an individual service, as it
(1) returns not often
enough (if a process of another service exits and this action was waiting on
a single pid) (2) too often (likewise,
and this action was ‘just waiting’
(3) potentially never (imagine every process has been started and an action
was waiting for one to exit,
and now the user tries to reboot.  Then shepherd
daemon would never accept the connection from the user!).

And in a multi-threaded Shepherd, "fork" is unsafe.  (Anyway, "fork" captures
too much state, and no action should ever call "exec" without "fork".)  Also,
"exec" replaces *too little* state (e.g. open file descriptors, umask, root
directory, current working directory ...).

But perhaps that's just a call for a different set of primitives (which could
be implemented on top of these system calls by shepherd, or directly on top
of the relevant Hurd RPCs when running on GNU/Hurd.).

>   Yet the language is a full Turing-complete language, including the major
>   weakness of Turing-completeness: the inability to solve the halting problem.

IIUC, there are plans to perform the network configuration inside shepherd
(search for guile-netlink).  So arbitrary code still needs to be allowed.
This is the Procedural (extensible) I'll referring to later.

>  The fact that the halting problem is unsolved in the language means it is
>  possible to trivially write an infinite loop in the language.  In the context
>  of an `init` system, the possibility of an infinite loop is dangerous, as it
>  means the system may never complete bootup.

I'm assuming the hypothetical infinite loop is in, say, the code for starting
guix-daemon which isn't very essential (try "herd stop guix-daemon"!)
(If there's an infinite loop is in e.g. udev-service-type then there's indeed
a problem, then that infinite loop might as well be in eudev itself, so I'm
only speaking of *non-essential* services blocking the boot process.)

I'm not convinced we need Turing-incompleteness here, at least if the
start / do-a-dance action / stop code of each service definition is run in
a separate thread (not currently the case).

> I have experienced this firsthand since I wrote a Shepherd service to launch
> a daemon, and I needed to wait for the daemon initialization to complete.
> My implementation of this had a bug that caused an infinite loop to be 
> entered,
> but would only tickle this bug when a very particular (persistent on-disk) 
> state
> existed.
>
> I wrote this code about a month or so ago, and never got to test it until 
> last week,
> when the bug was tickled.  Unfortunately, by then I had removed older system 
> versions
> 

Re: [SPITBALL] Jehanne as another kernel option / porting target

[Vincent Legoll]

On Fri, Mar 19, 2021 at 8:42 PM Vincent Legoll  wrote:
>
> On Fri, Mar 19, 2021 at 7:02 PM Vincent Legoll  
> wrote:
> > I have created a guix build recipe for seL4 recently, it builds, but I don't
> > know what to do with it :-)
> >
> > I'll send it as a followup to this thread, if any one is interested.
>
> Here it is, ukernel only, hardcoded arch, nothing fancy like camkes, etc.

vince@guix ~/dev/repo/guix [env]$ file
/gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf
/gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically
linked, not stripped

vince@guix ~/dev/repo/guix [env]$ l
/gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf
-r-xr-xr-x 2 root root 179K Jan  1  1970
/gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf

vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env guix build --check
--rounds=5 sel4
[...]
successfully built /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv
The following builds are still in progress:
  /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv
  /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv
  /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv
  /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv

successfully built /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv
The following builds are still in progress:
  /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv
  /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv
  /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv

Looks even reproducible...

-- 
Vincent Legoll

Re: [SPITBALL] Jehanne as another kernel option / porting target

[Vincent Legoll]

On Fri, Mar 19, 2021 at 7:02 PM Vincent Legoll  wrote:
> I have created a guix build recipe for seL4 recently, it builds, but I don't
> know what to do with it :-)
>
> I'll send it as a followup to this thread, if any one is interested.

Here it is, ukernel only, hardcoded arch, nothing fancy like camkes, etc.

-- 
Vincent Legoll
From 607cef41839131fd740fbf754d30f3a9277c5a0a Mon Sep 17 00:00:00 2001
From: Vincent Legoll 
Date: Fri, 19 Feb 2021 23:49:43 +0100
Subject: [PATCH] gnu: Add sel4.

* gnu/packages/sel4.scm: New file...
* gnu/local.mk (GNU_SYSTEM_MODULES): ...Add it here.
---
 gnu/local.mk  |  1 +
 gnu/packages/sel4.scm | 83 +++
 2 files changed, 84 insertions(+)
 create mode 100644 gnu/packages/sel4.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index 33da7b979a..6d4ddb2bdd 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -502,6 +502,7 @@ GNU_SYSTEM_MODULES =\
   %D%/packages/sdl.scm\
   %D%/packages/search.scm			\
   %D%/packages/security-token.scm		\
+  %D%/packages/sel4.scm\
   %D%/packages/selinux.scm			\
   %D%/packages/sequoia.scm			\
   %D%/packages/serialization.scm		\
diff --git a/gnu/packages/sel4.scm b/gnu/packages/sel4.scm
new file mode 100644
index 00..6fc3f88ac2
--- /dev/null
+++ b/gnu/packages/sel4.scm
@@ -0,0 +1,83 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2021 Vincent Legoll 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages sel4)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages python-xyz)
+  #:use-module (gnu packages python-web)
+  #:use-module (gnu packages ninja)
+  #:use-module (gnu packages xml)
+  #:use-module (guix build-system cmake)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix git-download))
+
+(define-public sel4
+  (package
+(name "sel4")
+(version "12.0.0")
+(source
+ (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://github.com/seL4/seL4;)
+ (commit version)))
+   (file-name (git-file-name name version))
+   (sha256
+(base32 "1zkx6x5jly8f75ph9jxd2jrp1kg5l001zkfqpmjf8ancsi1b43y7"
+(build-system cmake-build-system)
+(arguments
+ '(#:tests? #f ;; No need for tests when you have formal proof of correctness
+   #:configure-flags
+   (list
+"-G" "Ninja"
+"-DKernelArch=x86"
+"-DCROSS_COMPILER_PREFIX="
+"-DCMAKE_TOOLCHAIN_FILE=../source/gcc.cmake"
+"-C" "../source/configs/X64_verified.cmake")
+   #:phases (modify-phases %standard-phases
+  (replace 'build
+(lambda _
+  (invoke "ninja" "kernel.elf")))
+  (replace 'install
+(lambda _
+  (mkdir-p %output)
+  (copy-file "kernel.elf"
+ (string-append %output "/kernel.elf")))
+(native-inputs
+ `(("libxml2" ,libxml2)
+   ("ninja" ,ninja)
+   ("python" ,python-3)
+   ("python-future" ,python-future)
+   ("python-jinja2" ,python-jinja2)
+   ("python-paste" ,python-paste)
+   ("python-ply" ,python-ply)
+   ("python-six" ,python-six)
+   ))
+(synopsis "Operating System microkernel")
+(description "Formally verified member of the L4 microkernel family.")
+(home-page "https://sel4.systems;)
+(license (list license:asl2.0 ; And also a variant in LICENSES/SHL-0.51.txt
+   license:bsd-2
+   license:bsd-3
+   license:cc-by-sa4.0
+   license:gpl2
+   license:gpl2+
+   license:lppl1.3c
+   license:x11
-- 
2.30.0

Re: Release 1.2.1: status

[Andreas Enge]

Hello,

Am Thu, Mar 18, 2021 at 03:28:38PM +0100 schrieb zimoun:
>   guix weather --display-missing

I am giving it a try, but after about one hour at 100% CPU on one core it
is still only half way through. Is this normal? I think I will stop it to
at least redirect the output into a file...

Andreas

Re: [SPITBALL] Jehanne as another kernel option / porting target

[Vincent Legoll]

Hello,

On Fri, Mar 19, 2021 at 5:45 PM Joshua Branson  wrote:
> >> seL4 would be cool too.
> > Didn't someone do some work on making hurd run on SEL4?
> > Or am I misremembering
>
> You are correct.  :)

It was a member of the L4 family, but I think it was not seL4 (looks like seL4
started in 2006).

I have created a guix build recipe for seL4 recently, it builds, but I don't
know what to do with it :-)

I'll send it as a followup to this thread, if any one is interested.

-- 
Vincent Legoll

A Critique of Shepherd Design

[raid5atemyhomework]

GNU Shepherd is the `init` system used by GNU Guix.  It features:

* A rich full Scheme language to describe actions.
* A simple core that is easy to maintain.

However, in this critique, I contend that these features are bugs.

The Shepherd language for describing actions on Shepherd daemons is a 
Turing-complete Guile language.  Turing completeness runs afoul of the 
Principle of Least Power.  In principle, all that actions have to do is invoke 
`exec`, `fork`, `kill`, and `waitpid` syscalls.  Yet the language is a full 
Turing-complete language, including the major weakness of Turing-completeness: 
the inability to solve the halting problem.

The fact that the halting problem is unsolved in the language means it is 
possible to trivially write an infinite loop in the language.  In the context 
of an `init` system, the possibility of an infinite loop is dangerous, as it 
means the system may never complete bootup.

Now, let us combine this with the second feature (really a bug): GNU shepherd 
is a simple, single-threaded Scheme program.  That means that if the single 
thread enters an infinite loop (because of a Shepherd service description that 
entered an infinite loop), then Shepherd itself hangs.  This means that the 
system is severely broken.  You cannot `sudo reboot` because that communicates 
with the Shepherd daemon.  You cannot even `kill 1` because signals are handled 
in the mainloop, which never get entered if the `start` action of some Shepherd 
daemon managed to enter an infinite loop.

I have experienced this firsthand since I wrote a Shepherd service to launch a 
daemon, and I needed to wait for the daemon initialization to complete.  My 
implementation of this had a bug that caused an infinite loop to be entered, 
but would only tickle this bug when a very particular (persistent on-disk) 
state existed.  I wrote this code about a month or so ago, and never got to 
test it until last week, when the bug was tickled.  Unfortunately, by then I 
had removed older system versions that predated the bug.  When I looked at a 
backup copy of the `configuration.scm`, I discovered the bug soon afterwards.  
But the amount of code verbiage needed here had apparently overwhelmed me at 
the time I wrote the code to do the waiting, and the bug got into the code and 
broke my system.  I had to completely reinstall Guix (fortunately the backup 
copy of `configuration.scm` was helpful in recovering most of the system, also 
ZFS rocks).

Yes, I made a mistake.  I'm only human.  It should be easy to recover from 
mistakes.  The full Turing-completeness of the language invites mistakes, and 
the single-threadedness makes the infinite-loop mistakes that 
Turing-completeness invites, into catastrophic system breakages.

So what can we do?

For one, a Turing-complete language is a strict *superset* of 
non-Turing-complete languages.  So one thing we can do is to define a more 
dedicated language for Shepherd actions, strongly encourage the use of that 
sub-language, and, at some point, require that truly Turing-complete actions 
need to be wrapped in a `(unsafe-turing-complete ...)` form.

For example, in addition to the current existing `make-forkexec-constructor` 
and `make-kill-destructor`, let us also add these syntax forms:

`(wait-for-condition  )` - Return a procedure that accepts a 
numeric `pid`, that does: Check if evaluating `` in the lexical context 
results in `#f`.  If so, wait one second and re-evaluate, but exit anyway and 
return `#f` if `` seconds has passed, or if the `pid` has died.  If 
`` evaluates to non-`#f` then return it immediately.

`(timed-action   ...)` - Return a procedure that accepts a 
numeric `pid`, that does: Spawn a new thread (or maybe better a `fork`ed 
process group?).  The new thread evaluates ` ...` in sequence.  If the 
thread completes or throws in `` seconds, return the result or throw 
the exception in the main thread.  IF the `` is reached or the given 
`pid` has died, kill the thread and any processes it may have spawned, then 
return `#f`.

`(wait-to-die )` - Return a procedure that accepts a `pid` that does: 
Check if the `pid` has died, if so, return #t.  Else sleep 1 second and try 
again, and if `` is reached, return `#f`.

The above forms should also report as well what they are doing (e.g. `Have been 
waiting 10 of 30 seconds for `) on the console and/or syslog.

In addition, `make-forkexec-constructor` should accept a `#:post-fork`, which 
is a procedure that accepts a `pid`, and `make-kill-destructor` should accept a 
`#:pre-kill`, which is a procedure that accepts a `pid`.  Possibly we need to 
add combinators for the above actions as well.  For example a `sub-actions` 
procedural form that accepts any number of functions of the above `pid -> bool` 
type and creates a single combined `pid -> bool`.

So for example, in my case, I would have written a `make-forkexec-constructor` 
that accepted a `#:post-fork` that had a `wait-for-condition` on the code 

Re: Best practices for writing services

[Xinglu Chen]

On Fri, Mar 19 2021, Joshua Branson wrote:

>> Currently there seems to be two main ways to do this, the first one
>> is the define one or more records for the configuration field of a
>> service using `define-record-type*`, see the tor service in (gnu
>> services networking) for example.  The other method is to use
>> `define-configuration` to declare the configuration fields of a service,
>> see the transmission service in (gnu services file-sharing) for example.
>
> I believe that the first method via define-record-type* seems to be the
> recommended method to do this.  I only say that because I feel like more
> services are defined that way now.  :)

I decided to use `define-record-type*` since the service for mcron is
pretty simple because it is already configured in Guile. :)

> I've been working on a sway service and an endlessh service in my
> hacking videos
> (https://video.hardlimit.com/accounts/joshua_branson/video-channels).

Cool, great to see more videos on Guix, and it's on PeerTube.

> I was running into issues, where I could compile the service, but
> trying to reconfigure my system would result in errors.

The Guile compiler seems to miss quite a few errors in my exprience too.

> The errors messages were a little vague.  I will also say that the
> better method I have found in writing a guix service is to
>
> 1) write the service as simply as possible first.  I personally would
> copy the simplest service that you can find in gnu/services/  and modify
> that via a M-x anzu-query-replace-regexp.  If re-configuring works, make a 
> commit.
>
> 2) If possible, containerize the service.  If it works, make a commit.
>
> 3) Now start adding in all the features you left out before.

Thanks for the suggestions, I will take them into account in the future.

Re: [SPITBALL] Jehanne as another kernel option / porting target

[Joshua Branson]

pinoaffe  writes:

> raingloom writes:
>
>> seL4 would be cool too.
> Didn't someone do some work on making hurd run on SEL4?
> Or am I misremembering

You are correct.  :)

https://www.gnu.org/software/hurd/history/port_to_another_microkernel.html

By now (that is, after 2006), there were some new L4 variants available,
which added protected IPC paths and other features necessary for
object-capability systems; so it might be possible to implement the Hurd
on top of these. However, by that time the developers concluded that
microkernel design and system design are interconnected in very
intricate ways, and thus trying to use a third-party microkernel will
always result in trouble. So Neal Walfield created the experimental
Viengoos kernel instead -- based on the experience from the previous
experiments with L4 and Coyotos -- for his research on resource
management. Currently he works in another research area though, and thus
Viengoos is on hold.

So essentially most of the active hurd developers considered a port to a
different microkernel to be impractical.  :(

However, one of the main hurd developers (he has since stepped away from
active development), started a hurd clone:  x15.

https://www.sceen.net/x15/

He claimed that the original GNU Hurd has too many bad design
decisions.  So he started from scratch writing a kernel.  His kernel x15
is NOT a mach replacement.  However, some of the code he wrote for x15
has been incorporated in the GNU Hurd.  :)

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Best practices for writing services

[Joshua Branson]

Xinglu Chen  writes:

> Hi Guix,
>
> I am going to write an mcron service for `guix home`[1][2] and before
> proceding, I would like to get some suggestions on what the best
> practices are for writing services in Guix.

Please note that I am a guix documentation contributor, and I am not
quite a guix developer yet.  :)  Though I do have a patch pending on
http://issues.guix.gnu.org/39136  (not certain why the 2/2 patch does
not show, 'cause I saw that come through in my inbox).

>
> Currently there seems to be two main ways to do this, the first one
> is the define one or more records for the configuration field of a
> service using `define-record-type*`, see the tor service in (gnu
> services networking) for example.  The other method is to use
> `define-configuration` to declare the configuration fields of a service,
> see the transmission service in (gnu services file-sharing) for example.

I believe that the first method via define-record-type* seems to be the
recommended method to do this.  I only say that because I feel like more
services are defined that way now.  :)

> The second method removes quite a lot of boilerplate and the developer
> will define different serializers that convert scheme syntax like lists,
> alist, boolean... to the "real" configuration syntax of the program.  It
> also does some automatic typechecking to some degree and allows the
> developer to write docstrings for each configuration field.  There is
> then a procedure called `generate-documentation` which can automatically
> generate texinfo documenation from the docstrings.

I do like that generate-documentation procedure.  Perhaps we could add
that for the define-record-type*  somehow...

>
> I couldn't find any information in the manual regarding what conventions
> should be used when writing services for Guix and would like to hear
> from more experienced Guix hackers what the best practices are.

You might try asking in irc in #guix too!

I've been working on a sway service and an endlessh service in my
hacking videos
(https://video.hardlimit.com/accounts/joshua_branson/video-channels).  I
was running into issues, where I could compile the service, but trying
to reconfigure my system would result in errors.  The errors messages
were a little vague.  I will also say that the better method I have
found in writing a guix service is to

1) write the service as simply as possible first.  I personally would
copy the simplest service that you can find in gnu/services/  and modify
that via a M-x anzu-query-replace-regexp.  If re-configuring works, make a 
commit.

2) If possible, containerize the service.  If it works, make a commit.

3) Now start adding in all the features you left out before.

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: [SPITBALL] Jehanne as another kernel option / porting target

[pinoaffe]

raingloom writes:
> http://jehanne.io/2021/01/06/gcc_on_jehanne.html
>
> Should support more architectures than Hurd ;)
>
> Anyways, just throwing this out there, as I - and I imagine every
> other contributor - have some more pressing projects.
>
> It probably wouldn't be able to run most packages and services without
> some significant work but it could maybe still use Guix as a package
> manager.
I'm far from in the loop, but from a cursory glance I'd think that
porting to Jehanne is significantly more involved than porting to the
Hurd, considering that Hurd seems to provide more POSIX compatibility
than Jehenne.

> seL4 would be cool too.
Didn't someone do some work on making hurd run on SEL4?
Or am I misremembering

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Julien Lepiller]

I don't think I understand the problem fully, but it looks like there is 
nothing wrong with the graft now that you symlinked tge library, so it's fine 
to keep the graft. Hopefully we can ungraft shortly during the "ungraftathon" 
next week :)

Le 19 mars 2021 05:40:45 GMT-04:00, "Léo Le Bouter"  a 
écrit :
>Hello!
>
>See commit: 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef
>
>Following discussion around whether it is safe to graft and whether we
>should do so or not, first, I apologize for not doing as rigorous
>checking on this issue as I should have, and also requesting more peer-
>review, I initially believed those two ImageMagick version were ABI
>compatible with unchanged soname so it turns out it would be a rather
>uncontroversial graft to make but now it turns out we have a changed
>soname but whether it is binary (backwards) compatible or not remains a
>question.
>
>We had a user reporting that Inkscape stopped working after the graft (
>https://logs.guix.gnu.org/guix/2021-03-18.log#100200), after which we
>decided on IRC with rekado we might cheat by symlinking the shared
>libraries, which I've done in commit
>2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd, from a glance it didnt seem
>the soname change caused backwards incompatible changes but only
>forward incompatible changes.
>
>Let's see some abidiff output now:
>
>$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
>$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
>doc)/lib/libMagickCore-6.Q16.so.6 $(./pre-inst-env guix build 
>imagemagick@6.9.12-2g | grep -v doc)/lib/libMagickCore-6.Q16.so.7
>ELF SONAME changed
>Functions changes summary: 0 Removed, 0 Changed, 0 Added function
>Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
>Function symbols changes summary: 0 Removed, 0 Added function symbol
>not referenced by debug info
>Variable symbols changes summary: 0 Removed, 1 Added variable symbol
>not referenced by debug info
>
>SONAME changed from 'libMagickCore-6.Q16.so.6' to 'libMagickCore-
>6.Q16.so.7'
>
>1 Added variable symbol not referenced by debug info:
>
>  [A] .gomp_critical_user_analyzeImage
>
>
>$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
>$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
>doc)/lib/libMagick++-6.Q16.so.8 $(./pre-inst-env guix build 
>imagemagick@6.9.12-2g | grep -v doc)/lib/libMagick++-6.Q16.so.9
>ELF SONAME changed
>Functions changes summary: 0 Removed, 0 Changed, 0 Added function
>Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
>
>SONAME changed from 'libMagick++-6.Q16.so.8' to 'libMagick++-
>6.Q16.so.9'
>
>$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
>$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
>doc)/lib/libMagickWand-6.Q16.so.6 $(./pre-inst-env guix build 
>imagemagick@6.9.12-2g | grep -v doc)/lib/libMagickWand-6.Q16.so.7
>ELF SONAME changed
>Functions changes summary: 0 Removed, 0 Changed, 0 Added function
>Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
>
>SONAME changed from 'libMagickWand-6.Q16.so.6' to 'libMagickWand-
>6.Q16.so.7'
>
>Any more ABI diff-ing/testing, information, etc.. on whether this is
>safe or not is welcome, it sounds to me it could be fine but there is
>some amount of doubt still.
>
>If we can't graft ImageMagick we shall revert all commits and then it
>means we would have to apply patches for each and every CVE which can
>be tedious to create and maintain and to me leaving the package as-is
>without patching is not really OK :-/
>
>To graft or not to graft?
>
>Thank you,
>Léo

imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Léo Le Bouter]

Hello!

See commit: 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef

Following discussion around whether it is safe to graft and whether we
should do so or not, first, I apologize for not doing as rigorous
checking on this issue as I should have, and also requesting more peer-
review, I initially believed those two ImageMagick version were ABI
compatible with unchanged soname so it turns out it would be a rather
uncontroversial graft to make but now it turns out we have a changed
soname but whether it is binary (backwards) compatible or not remains a
question.

We had a user reporting that Inkscape stopped working after the graft (
https://logs.guix.gnu.org/guix/2021-03-18.log#100200), after which we
decided on IRC with rekado we might cheat by symlinking the shared
libraries, which I've done in commit
2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd, from a glance it didnt seem
the soname change caused backwards incompatible changes but only
forward incompatible changes.

Let's see some abidiff output now:

$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
doc)/lib/libMagickCore-6.Q16.so.6 $(./pre-inst-env guix build 
imagemagick@6.9.12-2g | grep -v doc)/lib/libMagickCore-6.Q16.so.7
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 0 Added function symbol
not referenced by debug info
Variable symbols changes summary: 0 Removed, 1 Added variable symbol
not referenced by debug info

SONAME changed from 'libMagickCore-6.Q16.so.6' to 'libMagickCore-
6.Q16.so.7'

1 Added variable symbol not referenced by debug info:

  [A] .gomp_critical_user_analyzeImage


$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
doc)/lib/libMagick++-6.Q16.so.8 $(./pre-inst-env guix build 
imagemagick@6.9.12-2g | grep -v doc)/lib/libMagick++-6.Q16.so.9
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

SONAME changed from 'libMagick++-6.Q16.so.8' to 'libMagick++-
6.Q16.so.9'

$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
doc)/lib/libMagickWand-6.Q16.so.6 $(./pre-inst-env guix build 
imagemagick@6.9.12-2g | grep -v doc)/lib/libMagickWand-6.Q16.so.7
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

SONAME changed from 'libMagickWand-6.Q16.so.6' to 'libMagickWand-
6.Q16.so.7'

Any more ABI diff-ing/testing, information, etc.. on whether this is
safe or not is welcome, it sounds to me it could be fine but there is
some amount of doubt still.

If we can't graft ImageMagick we shall revert all commits and then it
means we would have to apply patches for each and every CVE which can
be tedious to create and maintain and to me leaving the package as-is
without patching is not really OK :-/

To graft or not to graft?

Thank you,
Léo


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

Re: GNOME 3.34 in GNU Guix and security

[Guillaume Le Vaillant]

Danny Milosavljevic  skribis:

> Hello,
>
> core-updates is still in a pretty bad state.
>
> [...]
>
> A short summary of what is at least broken:
>
> [...]
> (2) Source files have been in-place replaced upstream with a lot of packages 
> (see my bug report about the topic).  fldigi has such a problem but can just 
> be updated.  This is easy to see by just building without substitutes--and it 
> doesn't do anyone any good for me to file individual bug reports for each and 
> every one of those
> [...]

Concerning the disappearing source tarballs of older fldigi versions on
the official website, it has been fixed on master
(65e9f13116edc58836cdbd1da60bfb81a3d58c82), but core-updates hasn't
merged that in yet.


signature.asc
Description: PGP signature

Re: Release 1.2.1: status

[zimoun]

Hi Chris,

On Thu, 18 Mar 2021 at 23:37, Chris Marusich  wrote:

> More review is welcome, but unless some unforeseen issues are
> discovered, I agree that we can go ahead with adding support for
> powerpc64le-linux.

Great!  

> Where is the release work happening?  Where can I merge or apply these
> changes to ensure they get included in the next release?

The release work happens on master.  The branch wip-next-release
contains fixes, but AFAIK, it is not built by the CI, and these fixes
are ’core-updates’-like changes; I do not know if it is doable to merge
on time.

Well, maybe the patches could be directly applied to master, IMHO.

Quote the proposed Release timeline [1]:

A draft of the timeline is:

 - until April 1rst: fixes, check substitute availability, etc.
 - as soon as possible: start to build wip-next-release
 - merge branch wip-next-release when ready
 - on Monday 12th April, string freeze
 - couple of days after, branch the release and write the materials
   (ChangeLog and posts)
 - release

Cheers,
simon



PS: Sorry if the release process appears unclear.  Based on the
experiences of 1.2.0 and now this one, the idea is to propose then a
clear documented timeline for the next releases.  Basically, some
technical items are described in maintenance/doc/release.org [2] and
from my point of view, some items describing the (timeline) process
should be added.  Maybe in the manual so that we all know what we can
«expect».


1: 
2: 

Re: Release 1.2.1: status

[Christopher Baines]

Chris Marusich  writes:

> Hi simon,
>
> zimoun  writes:
>
>> First, thanks to Chris and folks, powerpc64le-linux will be [1] in the
>> next release, great! Isn’t it? :-)
>
> I'm very excited about this!  Efraim was able to rework our patches so
> they could be applied to master without rebuilding the entire world.
> The patches are currently under review here:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47182
>
> More review is welcome, but unless some unforeseen issues are
> discovered, I agree that we can go ahead with adding support for
> powerpc64le-linux.
>
> Where is the release work happening?  Where can I merge or apply these
> changes to ensure they get included in the next release?

In the past, a branch might appear for the release, but that hasn't
happened yet. Merging to master is the next step I believe, and as you
say, I think the patches are ready.


signature.asc
Description: PGP signature

Re: guix home

[Andrew Tropin]

Hi Julien, very glad to see you here!)

> Obviously I'm not a big fan of having configuration that can be modified
> after I ran guix home, but I understand this approach sounds less crazy
> :). I think both approaches have a lot more in common than they diverge,
> so merging one in guix is just one step away of merging the other :)
>
> Having a read-only home is a fun experiment (that have been going since
> I started guix-home-manager, so it's definitely possible), but a bit
> broken, and I keep poking holes for software I can't manage properly.

I really like the idea of strict separation of configuration and state,
and read-only home sounds like a rational solution to me, however it's
not a step in the right direction, but a leap, which not possible for
many even advanced users right now.

I considered many options like read-only home, read-only ~/.config and
few others, but decided that the transition to a new tool for most people
should be iterative and as smooth as possible. It will help to grow and
educate the community before exposing them to smart and great, but very
unusual approaches.

Thus, targeted symlinking is more a social decision rather than
technical. Configs itself remain immutable, but can be mixed with files
managed by user or other software.

> Also, I had this grand vision of using "extension points" in services,
> which might be useful to have in Guix. Though I never ended up using
> them in any meaningful way ^^'.

I have a small write-up on the topic [fn:1]. From time to time I feel
restricted by service extension mechanism, I know use cases where some
improvements to the mechanism will be beneficial, but for now I would
say they are statistically insignificant and can be workarounded with
other tools.

`guix home` propose the evolutionary approach here too, we stick with
what we have in guix system service extension mechanism, make a tool to
be a part of the guix, grow user base, collect use cases hard to solve
with current capabilities, make a decision based on collected data to
improve/modify extension mechanism, which affects both `guix system` and
`guix home`.

Otherwise, we can face a problem of integration gap, which won't be
solved in years.

> Merging either of our work will make it more visible and attract more
> users/contributors, that would be great! If we settle with Andrew's
> approach, I'd be glad to provide my own services, but I will also
> probably add something to get back my dear read-only home, because
> that's the intellectually superior approach, albeit broken ;)

As I said earlier I endorse and support all the good ideas and would like
to see them in `guix home`, keeping a space for users to allow them
making one small step at a time towards wonderful world of declarative
configurations, not giant leap)

Appreciate all your ideas and the work you did on the project, I learned
quite a lot from it!

* Footnotes

[fn:1] https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

Re: Release 1.2.1: status

[Chris Marusich]

Hi simon,

zimoun  writes:

> First, thanks to Chris and folks, powerpc64le-linux will be [1] in the
> next release, great! Isn’t it? :-)

I'm very excited about this!  Efraim was able to rework our patches so
they could be applied to master without rebuilding the entire world.
The patches are currently under review here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47182

More review is welcome, but unless some unforeseen issues are
discovered, I agree that we can go ahead with adding support for
powerpc64le-linux.

Where is the release work happening?  Where can I merge or apply these
changes to ensure they get included in the next release?

-- 
Chris


signature.asc
Description: PGP signature