Re: GNU Shepherd 0.9.0 released

[Liliana Marie Prikler]

Am Mittwoch, dem 06.04.2022 um 23:25 +0200 schrieb Ludovic Courtès:
>   ** Log file of unprivileged ‘shepherd’ is now under $XDG_DATA_DIR
Should that not be $XDG_STATE_DIR?


Cheers

Re: GNU Shepherd 0.9.0 released

[Zhu Zihao]

Ludovic Courtès  writes:

> [[PGP Signed Part:Undecided]]
> We are pleased to announce the GNU Shepherd version 0.8.1.  This release
> represents 49 commits by 3 people, bringing a new concurrent,
> event-driven core, improved logging, and on-demand service startup.

"version 0.8.1"

A bug here? :)

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

GNU Shepherd 0.9.0 released

[Ludovic Courtès]

We are pleased to announce the GNU Shepherd version 0.8.1.  This release
represents 49 commits by 3 people, bringing a new concurrent,
event-driven core, improved logging, and on-demand service startup.


• About

  The GNU Daemon Shepherd or GNU Shepherd is a service manager written
  in Guile that looks after the herd of system services.  It provides a
  replacement for the service-managing capabilities of SysV-init (or any
  other init) with a dependency-based system with a convenient
  interface.  The GNU Shepherd may also be used by unprivileged users to
  manage per-user daemons (e.g., tor, privoxy, mcron, etc.)  It is
  written in Guile Scheme, and is configured and extended using Guile.

  The GNU Shepherd is developed jointly with the GNU Guix project; it is
  used as the init system of Guix, GNU’s advanced GNU/Linux distribution.

  https://www.gnu.org/software/shepherd/


• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/shepherd/shepherd-0.9.0.tar.gz
https://ftp.gnu.org/gnu/shepherd/shepherd-0.9.0.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://ftpmirror.gnu.org/shepherd/shepherd-0.9.0.tar.gz
https://ftpmirror.gnu.org/shepherd/shepherd-0.9.0.tar.gz.sig

  Here are the SHA1 and SHA256 checksums:

  df84c15e21b00e6237af1c243ff77dfee2373626  shepherd-0.9.0.tar.gz
  c180778397694fccc051606d97ab646c8cb07e9d65712e21f154e8155986bce5  
shepherd-0.9.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 shepherd-0.9.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.openpgp.org \
--recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
Autoconf 2.71
Automake 1.16.5
Makeinfo 6.7
Help2man 1.48.5


• Changes since version 0.8.1 (excerpt from the NEWS file)

  ** The Shepherd now depends on Fibers 1.1.0 or later
  ** ‘shepherd’ no longer blocks when waiting for PID files, etc.
  ** Services without #:log-file have their output written to syslog
  ** Services with #:log-file have their output timestamped
  ** New ‘make-inetd-constructor’ procedure for inetd-style services
  ** New ‘make-systemd-constructor’ for systemd-style “socket activation”
  ** New ‘start-in-the-background’ procedure
  ** Services can now be “transient” (see the manual for details)
  ** New #:supplementary-groups parameter for ‘make-forkexec-constructor’
  ** New #:create-session? parameter for ‘make-forkexec-constructor’
  ** New #:resource-limits parameter for ‘make-forkexec-constructor’
  ** Log file of unprivileged ‘shepherd’ is now under $XDG_DATA_DIR
  ** Do not reboot upon ‘quit’ when running as root but not PID 1
  ** Improved documentation and examples
  ** The Shepherd can no longer be built with Guile 2.0
  ** Work around Guile 3.0.[5-7] compiler bug
 ()
  ** Updated translations: da, de, sv, uk

Please report bugs to bug-g...@gnu.org.
Join guix-devel@gnu.org for discussions.

Ludovic, on behalf of the Shepherd herd.


signature.asc
Description: PGP signature

Designing importers (was: (Re-) Designing extracting-downloader)

[Hartmut Goebel]

Am 26.03.22 um 01:56 schrieb Maxim Cournoyer:

[Answering on the question how to design the extracting download I 
originally thought of using got hex.pm packages:]



Is there a strong reason to want to use the archive instead of the
sources from the project repository?


For the same reason you prefer to import from a PyPI package instead of 
the project git-repo: The metadata is easily available.


Anyhow, using the git-repo could be a pro, since the hex.pm package 
might miss tests or test-data. OTOH I discovered that some Erlang 
projects have the build-tool binary („rebar3“)  committed in the 
git-repo, So when using the git-repo, this needs to be removed by a 
snippet (which would not be required when using the hex.pm archive).


So this is a more general discussion: Would it be better — also in 
regard to detecting new versions — to use the projects source-repo or 
the package manager's repo.


Given the recent discussion about how to make packaging easier, maybe 
the hex.pm importer (and others) should become much more capable: E.g. 
the importer could fetch the meta-data from hex.pm and then create a 
package definition pointing to github (falling back to hex.pm). And then 
- to make life easy for packagers, check the repo for „rebar3“ and in 
case create a snippet for removing it.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi!
>
> Maxime Devos  skribis:
>
>> Ludovic Courtès schreef op vr 01-04-2022 om 10:58 [+0200]:
>>> As a first milestone, maybe we could start running ‘autoreconf’ more
>>> often, for packages higher in the graph.  We could change the
>>> ‘bootstrap’ build phase to do that unless it’s explicitly turned off.
>>> It may turn out to be a Sisyphean task though…
>>>
>>> Thoughts?
>>
>> Changing all pre-existing packages, maybe.  But doing this for new
>> packages (reducing review effort) and perhaps when a package is updated
>> (for purity) should be feasible I think?  Then gradually things would
>> improve and eventually(TM) doing the switch in the bootstrap phase may
>> become feasible ...
>
> Yes, we could do that as a first step (in fact it’s already happening as
> some projects no longer distribute tarballs).
>
> What do maintainers think of that policy?

No strong opinion, but I agree that having a complete development
environment capable of building from the bare sources (e.g. a git tree)
is useful in general.  On the other hand, using tarballs is often more
efficient and practical (it's made to be built by downstream users,
rather than by developers, so it includes everything needed).  Release
tarballs are also often signed by the projects, which is neat.  So
perhaps we can leave some flexibility there and not make it a hard rule,
but a case of best judgment?

Thanks,

Maxim

Re: The GNU Shepherd 0.9.0rc1 available for testing!

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> Just to let you know, I've been running on this for a couple days
>> without any noticing any issue yet.  My boot time has been reduced from
>> 5 to 3 minutes, yay!
>
> Yay, thanks for testing!
>
> I too have been running it for several days, stress-testing it a bit,
> and everything’s fine.  :-)
>
> Unless a fly falls in the ointment, I’ll go ahead and release 0.9.0
> tomorrow, followed by a merge of the ‘wip-shepherd-upgrade’ branch in
> Guix ‘master’.

Sounds like a fine plan!  Thank you for improving Shepherd!

Maxim

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[Maxime Devos]

Hartmut Goebel schreef op wo 06-04-2022 om 17:49 [+0200]:

> [...]
> >     * Package definitions can request non-default features to be built
> >   anyway.
> > 
> >   A difference from cargo-build-system: features are set in the
> >   package of the rust crate, not the package using the rust crate.
> 
> How is this intended to work?
> 
> Package 1 has features AAA (= default) and BBB. So a .rlib is build for 
> each feature (package1-AAA.rlib, package1-BBB.rlib) Or will one need to 
> define two guix packages (package1+aaa and package1+bbb) and make the 
> build-system build the respective feature?
> 
> I personally would prefer the former. Thus package2 would pick up the 
> pre-compiled rlib for the respective feature.
> 
> Rational: If there are more features to be combined, the number of 
> packages to be build can a order of square. So defining all these 
> packages becomes a burden quickly. This is a computer's job :-) The 
> build-system could easily build all combinations. suffixing each rlib 
> with a short hash over the feature names,

My third solution: no package variants, no multiple .rlib variants.
Instead, by default enable the ‘default features’ mentioned in the
Cargo.toml, and (manually) add the extra features to the package
definition of the Rust dependency if they turn out to be needed by the
dependent.

This is like adding --enable-this --enable-that, ... to ffmpeg's
#:configure-flags instead of building a variant of ffmpeg for each
dependent of ffmpeg that needs a different feature set.

So far, I have not encountered incompatible features ... Let's see if
it will become a problem.

Greetings,
Maxime.


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

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[Hartmut Goebel]

Am 05.04.22 um 18:10 schrieb Maxime Devos:
Some other improvements that weren't announced previously: 


Wow! Impressive!

I'd be eager to tr it with sequoia-openpgp. Please drop me a note when 
you think your work might be able to build that beast.




   * Package definitions can request non-default features to be built
 anyway.

 A difference from cargo-build-system: features are set in the
 package of the rust crate, not the package using the rust crate.


How is this intended to work?

Package 1 has features AAA (= default) and BBB. So a .rlib is build for 
each feature (package1-AAA.rlib, package1-BBB.rlib) Or will one need to 
define two guix packages (package1+aaa and package1+bbb) and make the 
build-system build the respective feature?


I personally would prefer the former. Thus package2 would pick up the 
pre-compiled rlib for the respective feature.


Rational: If there are more features to be combined, the number of 
packages to be build can a order of square. So defining all these 
packages becomes a burden quickly. This is a computer's job :-) The 
build-system could easily build all combinations. suffixing each rlib 
with a short hash over the feature names,



--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[Maxime Devos]

raingloom schreef op wo 06-04-2022 om 00:28 [+0200]:
> I'm also a bit worried with the trend of Guix trying to duplicate
> functionality already present in language package managers and config
> file formats. It creates a two-sources-of-truth situation.

For service configurations, there is only one source of truth: the
configuration record.  It just happens to be converted to another
format.  The underlying file format, TOML is not Cargo-specific
(https://toml.io/en/) and parsed with python-toml, presumably python-
toml parses it correctly.  (Whether antioxidant-build-system interprets
it correctly, is of course a different matter.)

Also, Cargo is both a package manager and a build system.  The package
manager part is useless to Guix, we even have to work-around it (see
e.g. patch-cargo-checksums, crate-closure).  Unfortunately, there does
not seem to be a way to only use the build system part of Cargo and
ignore the package manager part, so the build system part has to be
reimplemented ...

> Trying to keep one up to date with the other can be an issue, this is why I
> didn't create a custom record type for Yggdrasil config files and just
> used a generic JSON converter. Which paid off, since there were in fact
> changes in the config fields between versions.

The configuration record fields does not have to support every new
thing, it just haves to be _sufficiently_ up to date for users.  And if
a configuration field that's needed is missing, then it's almost
trivial to add it.

Additionally, some services have an 'extra-content' escape hatch. 
yggrasil-configuration could have one too, then the user could have
both write most things as Scheme (benefit: largely unified interface,
more automation possible) _and_ be able to use the latest features not
yet directly supported by the configuraiton fields, via the escape
hatch.

> Will this build system avoid that issue as well?

antioxidant-build-system is a build system, not a configuration format.

I've found that most Cargo.toml are rather tame.  They often just set:

  * name
  * Some metadata like version, authors, home-page, include, exclude
... that antioxidant-build-system doesn't need.
  * sometimes 'build' or 'path'
  * dependencies  / dev-dependencies / build-dependencies, also
unneeded by antioxidant-build-system (the importer might need them,
but that's a separate component)

Looking at ,
there are some more things are things that antioxidant-build-system
doesn't need:

  * resolver
  * badges, [[bench]]
  * the [patch] and [replace]  --- just use a variant package in the
package inputs

Now, there are some things that aren't yet supported by antioxidant-
build-system but probably need to be:

  * autobins / autoexamples / autotests / [lib] / [bin] / [example]
/ [links]
  * setting various environment variables before build.rs
(there's probably some list somewhere ...)

But aside from that, it seems that the essential parts of Cargo.toml
are rather tame and unlikely to be added to.  And if something
essential is added anyway and needs to be supported, then it should be
easy to modify antioxidant-build-system appropriately (long-term)
and/or work-around it by setting some environment variables locally or
maybe some substitute* (short-term).

> I guess if the data it operates on has truly stable semantics, then
> writing an independent implementation is not as big a problem, since
> once written and debugged, it won't need to change.
> (And getting rid of cargo would be nice for Rust dev on Guix.)

AFAICT, the parts important to Guix are sufficiently stable -- not
immutable (sometimes changes do happen).  And even if it was unstable,
it still seems much better than just using Cargo (due to much shorter
build times, less strict about versions, not having to add winapi
crates when compiling for Linux, no copying tarballs around, no
#:cargo-inputs instead of [propagated-]inputs ...).

Greetings,
Maxime.


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

Re: Support for glibc 2.35

[Ludovic Courtès]

Hi,

Zhu Zihao  skribis:

> Olivier Dion via "Development of GNU Guix and the GNU System distribution." 
>  writes:
>
>> Hello,
>>
>> I would like to know if there's plan to add glibc@2.35 soon to the guix
>> channel?
>
> I'm afraid not. Bumping the version of glibc is not a trivial package
> update in Guix, it means almost all packages need to rebuild (rebuild
> the world).

Right, so we update it in a separate branch, ‘core-updates’, together
with other “core” packages.  The branch gets merged roughly once every 6
months, so one needs to be patient (such updates take a non-negligible
amount of QA work!).

> If you really need it, you may inherit from a existing glibc package,
> update to 2.35 and use it. But you may need extra patches to make it
> work well.

Yes, you can do that, use ‘make-gcc-toolchain’ (say) to build a custom
toolchain, and use ‘--with-c-toolchain’ to use that.

HTH!

Ludo’.