Re: Discussion on Parameterized Packages

[david larsson]

On 2023-05-13 20:26, david larsson wrote:

[..]



If this were a thing, Guix could avoid an LTS version, and just run
GuixLTS via package-parameters - which would be, uhm fun, IMO :-)


I do not mean LTS. I only meant a "stable" version, sorry for any 
confusion caused.


Best regards,
David

Re: Discussion on Parameterized Packages

[david larsson]

On 2023-05-11 17:08, Sarthak Shah wrote:

Hello Guix!
I'll be working on bringing Parameterized Packages to Guix for GSoC
2023 under the guidance of Gábor and Pjotr. I've been a Guix user for
a few years now as it works great for Common Lisp and Scheme projects,
and I've always wanted to contribute to it as it has one of the best
codebases I've seen. Parameterized Packages will serve as an awesome
feature that leverages Guix's dedication to ensuring that all packages
can be compiled from source.
Parameterized Packages will introduce functionality similar to
Gentoo's USE flags, making it possible to change compile-time options
for packages. This will provide users with a lot more freedom over
what features they'd like to include or exclude from packages, and
also aid with reducing the size of binaries.
I have provided a detailed outline of parameterized packages and the
proposed user interface for interacting with them (for both users and
maintainers) in this post on my blog:
https://blog.lispy.tech/2023/05/parameterized-packages.html

I would really appreciate feedback on

(1) parameters you'd like to see in Guix

(2) the user interface for searching/installing/packaging with
parameters


Im not sure this belongs as a parameter per se, but I would like to see 
something like a stable "parameter", that only uses stable features and 
stable versions of packages when applied on an operating system level 
(which was suggested as being a possible level to apply at in the blog 
post), thus:


  "guix build python-SOMEPACKAGE --with-parameter=stable"

would recursively use only the stable version of the package, including 
stable version of the dependencies.


If this were a thing, Guix could avoid an LTS version, and just run 
GuixLTS via package-parameters - which would be, uhm fun, IMO :-)


Maybe something to put into package-properties 
(https://github.com/guix-mirror/guix/blob/270db2a56bc50bcab5739de2c9393644ab65ac6c/guix/packages.scm#L611)


Best regards,
David

Re: Discussion on Parameterized Packages

[Liliana Marie Prikler]

Am Donnerstag, dem 11.05.2023 um 20:38 +0530 schrieb Sarthak Shah:
> Hello Guix!
> I'll be working on bringing Parameterized Packages to Guix for GSoC
> 2023 under the guidance of Gábor and Pjotr. I've been a Guix user for
> a few years now as it works great for Common Lisp and Scheme
> projects, and I've always wanted to contribute to it as it has one of
> the best codebases I've seen. Parameterized Packages will serve as an
> awesome feature that leverages Guix's dedication to ensuring that all
> packages can be compiled from source.
> Parameterized Packages will introduce functionality similar to
> Gentoo's USE flags, making it possible to change compile-time options
> for packages. This will provide users with a lot more freedom over
> what features they'd like to include or exclude from packages, and
> also aid with reducing the size of binaries.
> I have provided a detailed outline of parameterized packages and the
> proposed user interface for interacting with them (for both users and
> maintainers) in this post on my blog:
> https://blog.lispy.tech/2023/05/parameterized-packages.html
> I would really appreciate feedback on
> (1) parameters you'd like to see in Guix
Having read your blog and skimmed ahead a little, preferably none with
the way things are currently phrased.  That doesn't mean I am against
parameters, but I think it's important to understand them as a package-
local transformations.  Failure to do so is imho one of the biggest
flaws in Gentoo's USE flags.

First of all, let's address the elephant in the room: tunable?  While
implemented as a package property, that's actually half a parameter. 
The tuned package specifies which microarchitecture to optimize the
package for.  I think long-term, tunable? should be turned into a
parameter.

Secondly, let's have a look at Emacs.
  (package
 (name "emacs")
 (parameters 
   (optional jit #t)
   (optional png #t)
   (optional alsa #t)
   (one-of window-system gtk pure-gtk motif none))
 ...)
looks much nicer than the proposed mix of meaningful names with
symbols.  Note, that (one-of ...) takes the first value as implicit
default.

Now you could argue that specifying 20 optional parameters like this
would be a pain in the butt and you prefer your own optional notation.
But have you considered the following syntax as an alternative:
  (optionals/enabled jit png alsa)
  (optional treesit (some-supported-system-check))
  (optionals/disabled xwidgets wide-int ...)

> (2) the user interface for searching/installing/packaging with
> parameters
As with outputs, available parameters ought to be shown in the output
of `guix show', preferably one parameter per line with an explanation
what that parameter does.  Note that this isn't supported by either
mockup however, as just like with outputs a place for the documentation
is missing.

For the `guix package' CLI, I'd like to have two options: 
  --with-parameter=PACKAGE=PARAMETER[=VALUE] enables a parameter 
or assigns a specific value to a one-of parameter
  --without-parameter=PACKAGE=PARAMETER disables a parameter
If you want to be fancy, you can do 
  --with-parameters=PACKAGE=PSPEC[,PSPEC...]
where PSPEC is one of
  "not PARAMETER" to disable PARAMETER,
  "PARAMETER" to enable it,
  "PARAMETER=VALUE" to set a specific one-of value
which internally gets lowered to the same specification as equivalent
--with-parameter and --without-parameter arguments. 

To support "global" parameters, you could allow PACKAGE to be a regular
expression or if that's too much work, simply allow "*" as a special
package matching all packages.  Again, note that I'm not very fond of
global parameters.

For the operating-system side of things, I'd prefer it if we didn't
gain yet another field to care about.  I think modify-services should
work well in combination with package transformations, wherein you
simply 
  (define our-package-parameters
'((with-parameter "emacs=window-system=none")
  (without-parameter "emacs=jit")
  ...))
ahead of time and then use 
  (options->transformation our-package-parameters)
in the right location.


Cheers

GNU Shepherd 0.10.0 released

[Ludovic Courtès]

We are pleased to announce the GNU Shepherd version 0.10.1.  This
release represents 132 commits by two people.  It is a major overhaul of
shepherd internals, addressing shortcomings and providing new features
that help comprehend system state.


• About

  The GNU Shepherd is a service manager written in Guile that looks
  after the herd of daemons running on the system.  It can be used as an
  “init” system (PID 1) and also by unprivileged users to manage
  per-user daemons—e.g., tor, privoxy, mcron.  It supports several
  daemon startup mechanisms, including inetd and systemd-style socket
  activation.  The GNU Shepherd is configured in Guile Scheme and can be
  extended in the same language.  It builds on a simple memory-safe and
  callback-free programming model.

  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.10.0.tar.gz
https://ftp.gnu.org/gnu/shepherd/shepherd-0.10.0.tar.gz.sig

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

  Here are the SHA1 and SHA256 checksums:

  1b0895fa5a0709ae612be50d5a486c137d862168  shepherd-0.10.0.tar.gz
  Dl7kcFFihN35TBunXnj8aPvYImPlGPZlGtthKAlm6zY  shepherd-0.10.0.tar.gz

  The SHA256 checksum is base64 encoded, instead of the
  hexadecimal encoding that most checksum tools default to.

  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.10.0.tar.gz.sig

  The signature should match the fingerprint of the following key:

pub   rsa4096 2014-08-11 [SC]
  3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
uid   [  full  ] Ludovic Courtès 
uid   [  full  ] Ludovic Courtès 
uid   [  full  ] Ludovic Courtès (Inria) 

  If that command fails because you don't have the required public key,
  or that public key has expired, try the following commands to retrieve
  or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  As a last resort to find the key, you can try the official GNU
  keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify shepherd-0.10.0.tar.gz.sig


  This release was bootstrapped with the following tools:
Autoconf 2.71
Automake 1.16.5
Makeinfo 7.0.3
Help2man 1.49.2


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

  ** 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 

my public GPG key (was Re: Welcome to Simon as a new committer)

[Simon Tournier]

Hi,

Reading the archives can be confusing [1].  Therefore, please find
attach my public GPG key…

On Fri, 12 May 2023 at 13:32, Simon (zimoun) Tournier 
 wrote:

> The fingerprint of my key is:
>
> 705A 29B7 01EE 410E B6F9 236E 92F1 D22C 608E E7E5
>
> and available on some keyservers [1].
>
> 1: 
> 

also available on keyservers.

1: https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00170.html

Cheers,
simon



zimoun-key.pub
Description: zimoun-key.pub


signature.asc
Description: PGP signature

Re: RISC-V (riscv64-linux) substitutes are coming

[宋文武]

宋文武  writes:

> I got 'guix-build-coordinator-agent-only' built now, running it (with
> --help) will segfault though..
>
>
> How to run it to connect to the coordinator?
>

Update, now it running fine with:
```
guix-build-coordinator-agent  \
  --uuid= \
  --password= \
  --coordinator=https://rack.z572.online \
  --substitute-urls='https://data.guix.gnu.org https://cache.z572.online 
https://mirrors.sjtug.sjtu.edu.cn/guix/'
```

So, Z572 (his email seems to be blocked the mailing lists..) has setup a
guix-build-coordinator with
guix-build-coordinator-queue-builds-service-type, derivations fetched
from data.guix.gnu.org.  Then next we'd like to make our riscv64
machines to join the offical build farm.  Does the agent machine have to
belong to guix committer?

Patch graphviz in emacs-guix

[jgart]

Hi should emacs-guix be patched and the graphviz program add as an input to 
emacs-guix?

https://github.com/alezost/guix.el/blob/c9aef52121b458297e70bb50f49f7276b4a8d759/elisp/guix-external.el#L51

If I try to run `guix-package-graph` I get the following error:

guix-dot-arguments: Couldn’t find ’dot’.
Set ‘guix-dot-program’ to a proper value