New German PO file for 'shepherd' (version 0.10.0rc1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: package transformation and “guix graph”?

[Adam Faiz]

Hello,


Hi,

Investigating « bug#62645: Failing `guix install gnash` » [1], I am a
bit surprised:

The package rust-hmac needs to be rebuilt but it does not appear

connected via “guix graph”.  Note that rust-hmac has no direct
dependency and only the ones from the Rust build system.

Similarly, the node ’gcc’ appears in the DAG of gnash:

but then,

--8<---cut here---start->8---
$ guix graph --path gnash -e '(@@ (gnu packages gcc) gcc-11)' -t bag 
guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'gcc@11.3.0'

--8<---cut here---end--->8---

And note that,

--8<---cut here---start->8---
$ guix build -e '(@@ (gnu packages gcc) gcc-11)' --no-grafts -d
/gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
$ guix build -e '(@@ (gnu packages gcc) gcc-11)' -d
/gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
--8<---cut here---end--->8---

the derivation does not match with the one reported by “guix graph”.


Last, the package ’gcc’ appears in the graph of ’rust-hmac’ – which
seems weird to me but why not:

--8<---cut here---start->8---
$ guix graph rust-hmac -t bag-emerged | grep label | grep gcc
  "/gnu/store/wcx86bp6zcad2n2x5940dndhcksvfk5v-gcc-11.3.0.drv" [label = 
"gcc@11.3.0", shape = box, fontname = sans];

--8<---cut here---end--->8---

and then again no path between rust-hmac and gcc.  Note the same
derivation.


What do I miss?

There's a long standing issue of rust packages not using inputs and 
native-inputs[1] because of how cargo-build-system works.
The WIP antioxidant-build-system[2] will properly address all the shortcomings 
currently in Guix's Rust packaging.

gcc-11 is an implicit input of gnu-build-system so it's still in the build 
graph.

1: https://issues.guix.gnu.org/53127
2: https://notabug.org/maximed/cargoless-rust-experiments




Cheers,
simon

1: https://issues.guix.gnu.org/issue/62645

Re: Greater bug specifics for automatic team assignment

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

Hi Simon,

On Fri, Apr 28, 2023 at 10:02 AM Simon Tournier
 wrote:
>
> AFAIK, we are not able to change the current Debbugs tags

Alternatively, we could also change the bug "owner". Quoting from the
documentation, "The owner of a bug claims responsibility for fixing
it." [1]

In the context of Guix, teams would have to make sure they are not
offended when unrelated parties set or modify the bug owner. An
assignment to someone else can come across as patronizing—especially
in a ping-pong type situation—but I think that Guix contributors as a
whole have a collective morale that is strong enough to discount any
perceived slights.

With a monorepo, it's all kind of left-pocket/right-pocket, anyway.

Kind regards
Felix

[1] https://elpa.gnu.org/packages/doc/debbugs-ug.html#Mail-Command-Index

Re: Python feature branch

[Sharlatan Hellseher]

Hi,

I've fixed the build and updated chain of inputs for python-astropy,
posting here for wider awareness.



Thanks,
Oleg

New Ukrainian PO file for 'shepherd' (version 0.10.0rc1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the Ukrainian team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/uk.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Greater bug specifics for automatic team assignment

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

Hi Simon,

On Fri, Apr 28, 2023 at 10:02 AM Simon Tournier
 wrote:
>
> What do you have in mind?

In my recollection of using Debbugs in Debian, which uses a slightly
different version with more features (for example, a SOAP interface)
than the instance provided by GNU.org, there is a feature called "user
tags." They allow anyone to set arbitrary labels. [1]

Personally, I used regular tags frequently when co-maintaining Lintian
in Debian. They were super helpful when dealing with hundreds of bugs.
I therefore thought user tags could be helpful in Guix, especially for
teams. I may not be alone. [2]

We even have a section about them in the Guix manual, although I
haven't seen them being used much. [3]

Kind regards
Felix

[1] See "usertag", https://elpa.gnu.org/packages/doc/debbugs-ug.html
[2] https://lists.gnu.org/archive/html/help-debbugs/2020-08/msg0.html
[3] https://guix.gnu.org/manual/devel/en/html_node/Debbugs-Usertags.html

Re: Build dependency inflation (was: Re: Core-updates merge)

[Simon Tournier]

Hi,

On jeu., 27 avril 2023 at 19:56, Simon Josefsson via "Development of GNU Guix 
and the GNU System distribution."  wrote:
> Andreas Enge  writes:
>
>> - Too much in Guix depends on too much else, which makes building things
>>   needlessly entangled; in particular time zone data should not be referred
>>   to by packages, but be loaded at runtime (Leo Famulari).
>
> This is an important open problem -- is there any way to attack this
> problem in a systematic way?  I guess it is hard to understand which
> packages ends up depending on what since it is a large graph with long
> cycles, and also to understand which build depencies are essential and
> which are superficial, and thus consequently challenging to know where
> to start working to reduce build dependencies?

Hum, I am not to get the “large graph with long cycles” part.  Since the
graph for packages is a DAG.

Well, “guix graph” and “guix graph --path” help to spot the chain of
dependencies between two packages that seem unrelated.

>From my point of view, we should increase the tooling to inspect these
graphs.  Other said, add feature to “guix graph”.

At some point, it could be nice to have “guile-igraph” a Guile binding
of igraph [1].

Last, back on December [2], I started to apply some well-known network
algorithm (link analysis, centrality measure, pagerank, etc.) to the
graph of packages.  From my point of view, these kind of tools could be
very helpful to spot out the packages that need some specific care.

Maybe it would fit a project for a student. ;-)


1: https://igraph.org/
2: https://yhetil.org/guix/874ju4qyd4@gmail.com
   Some stats about the graph of dependencies
   Fri, 09 Dec 2022 18:29:43 +0100
   id:874ju4qyd4@gmail.com


Cheers,
simon

Re: Greater bug specifics for automatic team assignment

[Simon Tournier]

Hi,

On mer., 26 avril 2023 at 13:57, Felix Lechner via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> As a corollary to the upcoming teams approach, should we tag bugs in
> Debbugs so that their respective teams can find them?

AFAIK, we are not able to change the current Debbugs tags [1] because
they are administrated by GNU sysadmins.  However, indeed we could agree
on some common usertags as mentioned by the manual [2].

What do you have in mind?


1: https://debbugs.gnu.org/Developer.html#tags
2: https://guix.gnu.org/manual/en/html_node/Debbugs-Usertags.html


Cheers,
simon

package transformation and “guix graph”?

[Simon Tournier]

Hi,

Investigating « bug#62645: Failing `guix install gnash` » [1], I am a
bit surprised:

--8<---cut here---start->8---
$ guix build gnash --with-c-toolchain=gnash=gcc-toolchain@9 -n 2>&1 | grep 
tar.gz | wc -l
1008
--8<---cut here---end--->8---

and most of the packages to rebuild are Rust packages.  Basically
because the dependency ’gtk+’; surprising but why not.

Where I am really surprised is that:

--8<---cut here---start->8---
$ guix build gnash --with-c-toolchain=gnash=gcc-toolchain@9 -n 2>&1 | grep 
rust-hmac
  /gnu/store/983c5jb08bypxa9r6cmzg3znncmjhs4s-rust-hmac-0.8.1.tar.gz

$ guix graph --path gnash rust-hmac -t bag
guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'rust-hmac@0.12.0'
--8<---cut here---end--->8---

The package rust-hmac needs to be rebuilt but it does not appear
connected via “guix graph”.  Note that rust-hmac has no direct
dependency and only the ones from the Rust build system.

Similarly, the node ’gcc’ appears in the DAG of gnash:

--8<---cut here---start->8---
$ guix graph gnash -t bag-emerged | grep label | grep gcc
  "/gnu/store/wcx86bp6zcad2n2x5940dndhcksvfk5v-gcc-11.3.0.drv" [label = 
"gcc@11.3.0", shape = box, fontname = sans];
  "/gnu/store/rws8k2p28lvcims2yxr87v0yq4d793yk-gcc-mesboot-wrapper-4.9.4.drv" 
[label = "gcc-mesboot-wrapper@4.9.4", shape = box, fontname = sans];
  "/gnu/store/9nnxabq3m41pnq619gr59bjrbj054sl7-gcc-mesboot1-4.6.4.drv" [label = 
"gcc-mesboot1@4.6.4", shape = box, fontname = sans];
  "/gnu/store/ifxv0rvji2fqmj8m3yypwylc9fb3v1iq-gcc-mesboot0-2.95.3.drv" [label 
= "gcc-mesboot0@2.95.3", shape = box, fontname = sans];
  "/gnu/store/8vp8iadwjcvhaaqpa1wy60irhjdppwx7-gcc-core-mesboot0-2.95.3.drv" 
[label = "gcc-core-mesboot0@2.95.3", shape = box, fontname = sans];
  "/gnu/store/d3380kgfxv8dq9bimdqy2p0rfb30ad0q-gcc-mesboot-4.9.4.drv" [label = 
"gcc-mesboot@4.9.4", shape = box, fontname = sans];
  "/gnu/store/jgdyp8yr4j9ajk8ppfkypb1kylav7yx5-gcc-mesboot1-wrapper-4.6.4.drv" 
[label = "gcc-mesboot1-wrapper@4.6.4", shape = box, fontname = sans];
  "/gnu/store/j3idibd5016sxv4c15mx4xrpzggccjd0-python-pexpect-4.8.0.drv" [label 
= "python-pexpect@4.8.0", shape = box, fontname = sans];
--8<---cut here---end--->8---

but then,

--8<---cut here---start->8---
$ guix graph --path gnash -e '(@@ (gnu packages gcc) gcc-11)' -t bag 
guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'gcc@11.3.0'
--8<---cut here---end--->8---

And note that,

--8<---cut here---start->8---
$ guix build -e '(@@ (gnu packages gcc) gcc-11)' --no-grafts -d
/gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
$ guix build -e '(@@ (gnu packages gcc) gcc-11)' -d
/gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
--8<---cut here---end--->8---

the derivation does not match with the one reported by “guix graph”.


Last, the package ’gcc’ appears in the graph of ’rust-hmac’ – which
seems weird to me but why not:

--8<---cut here---start->8---
$ guix graph rust-hmac -t bag-emerged | grep label | grep gcc
  "/gnu/store/wcx86bp6zcad2n2x5940dndhcksvfk5v-gcc-11.3.0.drv" [label = 
"gcc@11.3.0", shape = box, fontname = sans];
--8<---cut here---end--->8---

and then again no path between rust-hmac and gcc.  Note the same
derivation.


What do I miss?


Cheers,
simon

1: https://issues.guix.gnu.org/issue/62645

Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json

[Simon Tournier]

Hi Ludo, Maxim, all,

On mar., 25 avril 2023 at 14:40, Ludovic Courtès  
wrote:

>> Somehow, it reveals 3 currently uncovered cases: computed-file appearing
>> as,
>>
>>  1. ’origin’ in source field (ruby-sorbet-runtime)
>>  2. ’inputs’ (racket-minimal)
>>  3. ’snippet’ in origin in source field (chromium)
>
> I think #1 and #2 are okay: we can use any file-like object there, not
> just origin/package.  Of course,  is meant to be the best choice
> for ‘source’, and  the best choice for ‘inputs’.  But I think
> it’s fine to occasionally resort to some other abstraction when these
> two are not adequate.

I agree that any file-like object is nice.  Somehow, the issue is to
“unpack“ the information of this object.  For instance,

--8<---cut here---start->8---
scheme@(guix-user)> (define ruby-sorbet-runtime (@@ (gnu packages ruby) 
ruby-sorbet-runtime))
scheme@(guix-user)> (package-source ruby-sorbet-runtime)
$1 = #< name: 
"ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout" gexp: # url: "https://github.com/sorbet/sorbet; 
commit: "0.5.10610.20230106174520-1fa668010" recursive?: #f> # () 
7fd7ad6b81e0>:out> "/gems/sorbet-" #) #)) gnu/packages/ruby.scm:14071:5 7fd7ae734480> guile: #f options: 
(#:local-build? #t)>
--8<---cut here---end--->8---

and as far as I understand, this case cannot be handled by some generic
code.  The extraction of the “real” origin needs manual and specific
extraction because of this ’computed-file’.

For sure, ’source’ can use any file-like object because some use-cases
require that.  However, I would be tempted to use an ’origin’ as a
preferred choice – i.e., when it’s possible and try to make it
possible. ;-) Because, somehow, it “normalizes“ the source information
and eases its extraction.


On mar., 25 avril 2023 at 09:52, Maxim Cournoyer  
wrote:

>> This pattern appears to me wrong.  It should use ’snippet’.  And if the
>> point is to have a meaningful path in /gnu/store, as it is the case with
>> icecat or linux or emacs-company-box, the current way is
>> ’computed-origin-method’ from (guix packages).
>>
>> For ’ruby-sorbet-runtime’, the fix seems ’computed-origin-method’.
>
> Per the source, IIRC, 'computed-origin-method' is also considered a hack
> or workaround around the fact that a snippet can't affect the name of a
> source.  But it's a well established one.  That was indeed the rationale
> here (to have meaningful top level directory names matching the source),
> which is worth it in my opinion.

I agree that ’computed-origin-method’ had been considered as a hack.  I
guess, mainly because at the time, the need seemed singular and that
’snippet’ were maybe less powerful.  For what my opinion is worth,
instead of,

--8<---cut here---start->8---
(define (make-sorbet-gem-source gem)
  "Return the source of GEM, a sub-directory."
  (computed-file
   (string-append "ruby-sorbet-" gem "-" sorbet-version "-checkout")
   (with-imported-modules (source-module-closure '((guix build utils)))
 #~(begin
 (use-modules (guix build utils))
 (copy-recursively (string-append #$sorbet-monorepo
  "/gems/sorbet-" #$gem)
   #$output)

(define-public ruby-sorbet-runtime
[...]
(source (make-sorbet-gem-source "runtime"))
--8<---cut here---end--->8---

I would try to “normalize” this behaviour.  Well, it’s not clear for me
if ’computed-origin-method’ is suitable as a basis for that; somehow it
would appear to me the direction for these kind of use cases.

Anyway, from my point of view, considering this very specific use-case
of ruby-sorbet-runtime, the pattern using ’computed-file’ as ’source’ –
only for having the correct store pathname – is not something that I
would introduce when it is avoidable.

And, maybe I am missing a point, but it appears to me avoidable:

--8<---cut here---start->8---
$ ./pre-inst-env guix build ruby-sorbet-runtime -S
/gnu/store/ni5mz1j7lbdrdqsvdm5dq1d2ack8c8q6-ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout

$ guix hash -r $(guix build ruby-sorbet-runtime -S) $(./pre-inst-env guix build 
ruby-sorbet-runtime -S)
0agzz44qqq5pxqzzpxwhzlbwwc7x20jrmbmaxj6q8a5bq9ydzws7
0agzz44qqq5pxqzzpxwhzlbwwc7x20jrmbmaxj6q8a5bq9ydzws7
--8<---cut here---end--->8---

using a ’snippet’ – see below.  Basically, ’file-name’ does the job for
the correct name and the other part is just moving content around.
Well, I guess this snippet could be simplified.

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 1dcd5f76a5..f61044f76b 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -14078,7 +14078,35 @@ (define-public ruby-sorbet-runtime
   (package
 (name "ruby-sorbet-runtime")
 (version sorbet-version)
-(source 

Re: Core-updates merge

[Simon Tournier]

Hi Andreas,

On mar., 25 avril 2023 at 16:09, Andreas Enge  wrote:


> I have just merged core-updates into master and deleted the branch!

Awesome!  Thank you for your patient leadership over the past months. :-)


> - R on powerpc64le needs to be built by changes to valgrind and lz4
>   (Simon Tournier, I).

Now, we are good, right?


> - There is still work to do to bootstrap GHC until the latest version on
>   i686, and to potentially shorten the bootstrap chain (Lars-Dominik Braun).

Argh, I will try to finish my patches soon.  I have:

 + turned off the test suite for ’ghc’ – it allows to not be blocked,
 + introduced ’ghc-testsuite’ to run the test suite,
 + introduced ’ghc-toolchain’ which depends on ’ghc’ and ’ghc-testsuite’
   – well, ’ghc’ being hidden.  Something similar as GCC.
 + shorten the chain as discussed elsewhere [1].

1: https://yhetil.org/guix/87r0siem5c@gmail.com


> - OCaml could be simplified by dropping version 4.07 (Julien Lepiller).

Well, 4.07 is the version that is de-bootstrapped, i.e. bootstrapped
using ’camlboot’ via Guile – for details see [2].

However, higher versions (4.09, 4.14, 5) does not use this seed and thus
they are not de-bootstrapped.  Well, I do not know the status upstream;
from my point of view, we have two options:

 a) Agree with other distros and OCaml folks to rely on a common OCaml
 4.07 bootstrapped using camlboot and then use this OCaml 4.07 as the
 seed for the subsequent versions.  Somehow having a way to verify the
 current OCaml compiler without running again and again via camlboot.

 b) Build ourselves a chain from 4.07 bootstrapped with camlboot to
 modern OCaml compilers.  However, each time we modify one dependency of
 camlboot, it means rebuild the complete chain.  Well, bootstrapping via
 camlboot can be very slow and I do not know if we have the resources
 for non-x86_64 architecture.  Here, the list of the emerged
 dependencies:

$ guix graph camlboot -t bag-emerged | grep label | cut -d'=' -f2
 "camlboot@0.0.0-1.45045d0", shape 
 "guile@3.0.9", shape 
 "pkg-config@0.29.2", shape 
 "tar@1.34", shape 
 "gzip@1.12", shape 
 "bzip2@1.0.8", shape 
 "file@5.44", shape 
 "diffutils@3.8", shape 
 "patch@2.7.6", shape 
 "findutils@4.9.0", shape 
 "gawk@5.2.1", shape 
 "sed@4.8", shape 
 "grep@3.8", shape 
 "xz@5.2.8", shape 
 "coreutils@9.1", shape 
 "make@4.3", shape 
 "bash-minimal@5.1.16", shape 
 "ld-wrapper@0", shape 
 "binutils@2.38", shape 
 "gcc@11.3.0", shape 
 "glibc@2.35", shape 
 "glibc-utf8-locales@2.35", shape 
 "libffi@3.4.4", shape 
 "bash-minimal@5.1.16", shape 
 "libunistring@1.0", shape 
 "libgc@8.2.2", shape

 c) Fix the dependencies of camlboot.


Well, it seems a separated discussion but it echoes the recent blog post [3]
about “The Full-Source Bootstrap”. :-)

2: 
https://10years.guix.gnu.org/video/camlboot-debootstrapping-the-ocaml-compiler
3: 
https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/


Cheers,
simon

New template for 'shepherd' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'shepherd' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/shepherd-0.10.0rc1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://alpha.gnu.org/gnu/shepherd/shepherd-0.10.0rc1.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [Rust Team] Status post core-updates merge

[Maxim Cournoyer]

Hi Efraim,

Efraim Flashner  writes:

[...]

>> I'm also curious, since you're "early adopters": how are you managing
>> with the team workflow?  Any tips, remarks or impressions that you could
>> share with other teams?
>
> Speak in the plural and no one will realize it's a team of one ;)
>
> I'm thinking of tagging the rust stuff with [rust team] so it stands out
> and is easily searchable. if/when I send patches for other teams I'll
> probably tag those too and hope it catches on.

Sounds like something to automate using git, the way CC'ing team members
can already be automated (see the patches in #58813).

Thanks for working on improving our (far from optimal) Rust situation.

-- 
Thanks,
Maxim

Re: `mumi send-email' means no more debbugs dance to send multiple patches

[Maxim Cournoyer]

Hello,

Arun Isaac  writes:

> Hi John,
>
>> I just tried it out and it worked smoothly for sending 2 patches to an
>> existing bug. However, it was sent only directly to the bug address,
>> not being aware I guess of anyone that had submitted or since been
>> CC'ed to the thread.
>>
>> Is there anything we can do here? I learned about the useful "wide
>> reply" when using debbugs in Emacs and presumably mumi can/does know
>> about all addresses on the bug. So hopefully this wishlist item won't
>> be too difficult.
>
> This is definitely a nice feature to have. For now, I put in the other
> addresses as Cc when creating the patch using `git format-patch'. Should
> we build this feature into `mumi send-email' or should we create a
> separate `mumi format-patch' command that will create a patch with the
> correct Cc and with other necessary options passed to `git
> format-patch'? The other necessary options (think options like `-1 -a
> --base=auto' as recommended in the Guix manual at "(guix) Sending a
> Patch Series") could be configured in .mumi/config allowing different
> projects using mumi to recommend different options.

All the above could be handled at the level of git directly with the
changes suggested in #58813, so I'd suggest we do this, which benefits
everyone/everything relying on it.

But I think something extra that mumi send-email could do, which git
can't (because it doesn't fetch the existing thread data), would be to
CC all parties that have already commented in the corresponding thread
(if the issue already exists).  I think this is what John was going at.

> Either way, patches to mumi are always welcome! ;-)

Thanks for this nice tool!

-- 
Thanks,
Maxim

GNU Shepherd 0.10.0rc1 available for testing!

[Ludovic Courtès]

Hello Guix!

I am pleased to announce that the first release candidate of version
0.10.0 of the GNU Shepherd is available for testing!

If you’re using Guix System or Guix Home, check out the instructions
below to give it a try.  Please report success or failure!  If you had
problems with previous versions, please check if they’re still there.

  code: https://alpha.gnu.org/gnu/shepherd/shepherd-0.10.0rc1.tar.gz
  signature: https://alpha.gnu.org/gnu/shepherd/shepherd-0.10.0rc1.tar.gz.sig
  sha256: 1x3lxsi6xhhds4pq30c3shydmhiidkf1wl2l7mxkpklmlycnbqgg

In your operating system configuration (and similarly for your
‘home-environment’), make the following changes:

  (use-modules (gnu packages admin))

  (define shepherd-next
(package
  (inherit shepherd)
  (version "0.10.0rc1")
  (source (origin
(method url-fetch)
(uri (string-append
  "https://alpha.gnu.org/gnu/shepherd/shepherd-;
  version ".tar.gz"))
(sha256
 (base32
  "1x3lxsi6xhhds4pq30c3shydmhiidkf1wl2l7mxkpklmlycnbqgg"))

  (operating-system
;; …
(essential-services
 (modify-services (operating-system-default-essential-services
   this-operating-system)
   (shepherd-root-service-type
config => (shepherd-configuration
   (shepherd shepherd-next))

You can then reconfigure, reboot, and enjoy!

You can also help with translation.  An updated PO template should soon
be available at the Translation Project:

  https://translationproject.org/domain/shepherd.html

My goal is for 0.10.x to be the last series before 1.0.  The list of
changes is quite long—see the ‘NEWS’ excerpt below.

Feedback more than welcome!

Ludo’.


* Changes in 0.10.0 (yet to be released)

** Distinguish ‘starting’ and ‘stopping’ intermediate service statuses

In previous version, a service would be either “running” or “stopped”.  The
intermediate states “starting” and “stopping” are now properly captured and
you can see them when running ‘herd status’.

** ‘start’ and ‘stop’ block when service is already being started/stopped
  

With previous version, a client running ‘herd start SERVICE’ while SERVICE is
already being started would cause shepherd to attempt to start a second
instance of that service, ultimately resulting in confusion, disappointment,
and frustration.

This is no longer the case: when a service is already being started/stopped,
additional invocation of ‘herd start’ or ‘herd stop’ now block until the
service is running/stopped.

** ‘shepherd’ starts services in parallel

Services started with ‘start-in-the-background’ and more generally service
dependencies get started in parallel.  This can reduce startup times in case
of a “wide” service dependency graph with some services that take a while to
start.

** ‘shepherd’ keeps track of failures and status change times

For each service, shepherd maintains an event log including the time of recent
status changes as well as the time of startup failures, if any.  The ‘herd
status SERVICE’ command now shows the time when the service entered its
current status and whether it failed to start; ‘herd status’ also prominently
lists services that failed to start.

** New ‘herd log’ command

Related to the previous item, the new ‘herd log’ command displays an aggregate
of the service event logs, showing the time at which each service changed
statuses.

** New ‘herd graph’ command

The new ‘herd graph’ command emits a Graphviz/Dot representation of the
service dependency graph, which can be viewed for example with ‘xdot’:

  herd graph | xdot -

Guix System users get similar information with ‘guix system shepherd-graph’
(and likewise for Guix Home).  The difference here is that this reflects the
current system status, showing transient services, services that failed to
start, and so on.

** ‘herd’ output is colorized

At long last!  We hope you’ll enjoy a little bit of coloring to highlight
important bits in the output of various commands.

** New services shipped: ‘monitoring’ and ‘repl’

The Shepherd now ships with optional services—see “Service Collection” in the
manual.  The ‘monitoring’ service logs resource usage of the ‘shepherd’
process itself.  The ‘repl’ service runs a read-eval-print loop (REPL) in the
‘shepherd’ so you can hack it live—enjoy it, but handle it with care!

** Socket-actived, systemd-style services can now be started eagerly

The ‘make-systemd-constructor’ procedure has a new #:lazy-start? parameter.
It defaults to #true, meaning that the process is started lazily, on the first
connection to one of its sockets, as was the case in 0.9.x.  Passing
#:lazy-start? #false instructs shepherd to instead start the process eagerly,
as soon as the listening sockets are ready.

This is useful for services that require socket activation as a startup
synchronization mechanism, yet are 

Re: Blog post on the Full-Source Bootstrap

[Janneke Nieuwenhuizen]

Simon Tournier writes:

Hi Simon,

> On mer., 26 avril 2023 at 16:12, Janneke Nieuwenhuizen  
> wrote:
>
>>   
>> https://gnu.org/software/guix/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
>
> Really cool!

Yeah, thanks!

> Maybe I misread the wording:
>
> If you run guix pull today, you get a package graph of more than
> 22,000 nodes rooted in a 357-byte program
> or
> First, while the package graph is rooted in a 357-byte program,
>
> Well, without being the accountant, considering the “more than 22,000
> nodes”, the revision fa685c8 contains ~23,000 packages and more than
> 1700 packages depends on GHC (Haskell) which is not bootstrapped from
> this 357-byte program, AFAIK.

Yeah, IWBN if someone would fix that and make the story more accurate
;-)

> $ guix refresh -l ghc@9.2 | cut -f1 -d':'

[..]

> In addition, that’s similar for ~450 packages relying on OCaml.
>
> Bah, I am nitpicking.  Am I? :-)

Yeah, but most enjoyably so :-)  Also, it's nice to know that someone
checked we're not telling too big a lie.

> What achievement this bootstrap story!  Thanks to all the people
> involved.  Back on FOSDEM 2017, I remember “Mes -- Maxwell's Equations
> of Software An attempt at dissolving bootstrap binaries” [1].  Thanks to
> this talk, I had this kind of revelation:
>
> Yes, that was the big revelation to me when I was in graduate
> school—when I finally understood that the half page of code on
> the bottom of page 13 of the Lisp 1.5 manual was Lisp in
> itself. These were “Maxwell’s Equations of Software!”
>
> – Alan Kay – 
>
> Then, I got the point with Yogurt metaphor [2] on FOSDEM 2019.  Anyway!

Lovely.  Thanks for you comments, most appreciated!

Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Python feature branch

[John Kehayias]

Hello,

Below is the cover letter I sent for a series of patches to fix 
python-yubikey-manager which along the way updates/fixes more. (Apologies for 
the double send to Python team but I wanted the bug number first for this 
message and to include them in any larger discussion.) The series is here: 


The deepest change is a package that affects pyproject-build-system. I thought 
I would send this here as well for wider visibility on this series as well as 
to garner any ready to go Python changes that can't be pushed to master 
directly.

So, please feel free to help gather any other patches that should go on a 
Python updates feature branch. I would like to keep this for changes that are 
less controversial/quicker changes in order to fix the breakages introduced 
from core-updates, namely poetry and python-yubikey-manager (an important leaf 
for some). However, since this series will rebuild all of 
pyproject-build-system using packages, there is the potential for lots of 
breakage. In that case, we can separate out the newer python-pypa-build package 
just for where it is needed an not update the build-system now.

Thanks everyone!
John

Cover for #63139:

Hi Guix and Python team,

Here is a patch series where the original goal was to fix 
python-yubikey-manager on core-updates and then ballooned to a bit more. This 
should be done in a feature branch for Python.

Mostly this was to fix/update the needed dependencies, though it may be 
possible to do this in a more minimal way just for that package fix. Anyway, I 
tried to generate this series in a way that each patch continues to fix things, 
but due to the complicated dependencies this may not be perfect.

A few notes:

1. Most of the series is pretty trivial, quick fixes/updates, some new packages.

2. What isn't is a few cases of failing tests which weren't immediately obvious 
to me and likely were some network access and/or build environment details. 
Some could be worked around maybe if someone wants to try (e.g. in 
python-virtualenv). I did enable more tests along the way though (like for 
poetry), so on the whole I think this is a step forward.

3. The dependents tend to be maybe 10s, a few in the hundreds, and then about 
3k for python-filelock. Until we get to pyproject-build-system updates:

4. I believe it was poetry that needed a newer python-pypa-build module, which 
then touches all pyproject-build-system (about 6k packages). This isn't 
strictly necessary as we could have a newer and separate package for leafs to 
use rather than in the build system as well, but I figured might as well do it 
sooner rather than later. At least the packages up to python-yubikey-manager 
built with this along with some random others.

5. On that note, I did not complete this change as I wanted some feedback on 
the bootstraping. I've added python-pyproject-hooks which should deprecate 
pep517, but currently it also needs python-pypa-build. I've made the older 
python-pypa-build a -bootstrap package to build this and the newer version of 
itself as well. So I did not deprecate pep517 yet.

   Also, python-wheel was a propagated-input in pep517 which is not needed in 
pyproject-hooks. However, I saw at least some packages will then need that as 
an input to build; so I kept it for pyproject-hooks to ease testing. It should 
be removed and added as an input as needed (no idea if that is just a few or a 
lot of the tree).

Okay, I think those are my notes. We should see what other things are ready to 
be made into this feature branch for Python. One brought to my attention 
recently is  though I have not looked at it.

Thanks!
John

John Kehayias (20):
  gnu: Add python-installer.
  gnu: Add python-pyproject-hooks.
  gnu: Add python-rapidfuzz.
  gnu: python-crashtest: Update to 0.4.1.
  gnu: python-cleo: Update to 2.0.1.
  gnu: Add python-deepdiff.
  gnu: python-platformdirs: Update to 3.2.0.
  gnu: python-filelock: Update to 3.12.0.
  gnu: python-distlib: Update to 0.3.6.
  gnu: python-virtualenv: Update to 20.22.0.
  gnu: python-pkginfo: Update to 1.9.6.
  gnu: python-jsonschema: Update to 4.17.3.
  gnu: python-dulwich: Update to 0.21.3.
  gnu: Update python-pypa-build to 1.0.0.
  gnu: poetry: Fix build.
  gnu: Add python-poetry-plugin-export.
  gnu: python-pyscard: Update to 2.0.7.
  gnu: python-fido2: Update to 1.1.1 and enable tests.
  gnu: Add python-makefun.
  gnu: python-yubikey-manager: Update to 5.1.0 and enable tests.

gnu/packages/python-build.scm   |  80 +++-
gnu/packages/python-xyz.scm | 319 +---
gnu/packages/security-token.scm |  61 +++---
3 files changed, 370 insertions(+), 90 deletions(-)


base-commit: aecc6e70587f8412cbbb9b2c13141de4f534518e