Re: A new paradigm for modifying operating system declarations
Hi raid5atemyhomework, On Tue, Jan 05 2021, raid5atemyhomework wrote: What `install-zfs` does is that it installs the same kernel-specific package in three different points: * `kernel-loadable-modules`, because ZFS needs to get into the kernel somehow. * `packages`, because the kernel module is useless if you don't have the userland tools to interact with the kernel module. * `services`, because ZFS is well-documented outside of Guix as automatically mounting its filesystems at bootup, but that actually requires a bit of magic in the `init` system, specifically you need to actually **load** the module, then execute `zpool import -a -l` to have it scan for all filesystems and mount those that need automounting. Thus, an `install-zfs`, that is a *single* form that inserts the correct bits in the correct ***three*** places, makes the experience of adding ZFS to your `operating-system` easier because there's less scope for error in actually adding the package. You just add a single `install-zfs`, not add three things (plus an extra `(define my-zfs (make-zfs-package linux-libre-5.4))` before your form). In principle, I think this should all be handled by a service. Services have a number of extension points where they can impact the operating system being declared, by extending other services. For example, adding a package into the global profile is done by extending profile-service-type (which you can find in gnu/services.scm). Adding a shepherd service to manage a process is done by extending shepherd-root-service-type (in gnu/services/shepherd.scm). This is how many services work. As an example, sddm-service-type extends services to: (a) start a process on the running system, (b) put files in /etc, (c) install some pam services, (d) add an account on the system, and (e) install packages in the global profile. As far as I can tell, the only thing missing for a zfs-service-type to do what you want is that services can't currently add new kernel modules (although they can load them via kernel-module-loader-service-type). I may have missed a mechanism for this, though. If we added the ability to do this, then it should be possible to add zfs support by adding a single (service zfs-service-type) to your services list. The approach of using services in this way has some advantages which are outlined in a blog post from 2015[1]. For me the most compelling advantage is that an zfs-service-type is more restricted in what it can do, and must be more explicit. An install-zfs procedure has free-reign over the entire operating-system definition that it gets passed, which makes it harder to reason about the composition of such procedures. Carlo [1]: https://guix.gnu.org/blog/2015/service-composition-in-guixsd/
Re: Mailman From header rewrite (was: [bug#45644] closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.))
Kyle Meyer writes: > As an example, the patch you feed to git-send-email would look something > like this: > > --8<---cut here---start->8--- > From ad2469ec86357b1a46dd63dcd17d5831969d5270 Mon Sep 17 00:00:00 2001 > From: Ryan Prior > Date: Mon, 4 Jan 2021 01:47:34 + > Subject: [PATCH] gnu: esbuild: Update to 0.8.29. > > From: Ryan Prior > > * gnu/packages/web.scm (esbuild): Update to 0.8.29. > > Signed-off-by: Leo Famulari Oops, sorry about the spurious Signed-off-by trailer here. I forgot to prune that after calling format-patch with ad2469ec86.
Mailman From header rewrite (was: [bug#45644] closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.))
Ryan Prior via Guix-patches via writes: >> By the way, your patches show that they are authored by "Ryan Prior >> via Guix-patches via guix-patc...@gnu.org". Is that the correct email >> address? > > No, the correct email address is rpr...@protonmail.com > > There's maybe 15 commits in Guix that have that incorrect email > address. I'm not sure where it comes from or how to get rid of it. I > send my patches by running a command like: > > git send-email --to=guix-patc...@gnu.org --suppress-cc=self > 0001-gnu-esbuild-Update-to-0.8.29.patch > > Git has my correct email address: > > $ git config user.email > rpr...@protonmail.com > > So I have to imagine that either Protonmail or your email server are > changing the email address. To add a couple of links to what Tobias mentioned downstream, I believe the From header rewrite is a DMARC-related mitigation on Mailman's part: https://wiki.list.org/DEV/DMARC https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html As far as I understand, protonmail is relevant here only in that, depending on the Mailman configuration, the originating server's DMARC policy will affect Mailman's decision to rewrite the From header. > If there's some behavior I can change to keep it from happening again > the future I will certainly be flexible. > > One thing I'm going to try (unless there's any objection) is to try > sending email [...] Here's a way that doesn't involve changing where you're sending from: add the appropriate "From:" header to the *body* of each patch. `git am` will take the in-body header over the actual header. (One use of this technique is to include a patch from someone else in a series.) As an example, the patch you feed to git-send-email would look something like this: --8<---cut here---start->8--- >From ad2469ec86357b1a46dd63dcd17d5831969d5270 Mon Sep 17 00:00:00 2001 From: Ryan Prior Date: Mon, 4 Jan 2021 01:47:34 + Subject: [PATCH] gnu: esbuild: Update to 0.8.29. From: Ryan Prior * gnu/packages/web.scm (esbuild): Update to 0.8.29. Signed-off-by: Leo Famulari --- gnu/packages/web.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm index 34998b94a5..20a40560e2 100644 --- a/gnu/packages/web.scm +++ b/gnu/packages/web.scm @@ -1487,7 +1487,7 @@ (define-public tidy (define-public esbuild (package (name "esbuild") -(version "0.8.27") +(version "0.8.29") (source (origin (method git-fetch) @@ -1496,7 +1496,7 @@ (define-public esbuild (commit (string-append "v" version (file-name (git-file-name name version)) (sha256 -(base32 "1n9h6r3q6mik7p5j0cyybh1sdcllig0awbryrx28r03cxv4ip2ij")) +(base32 "142gc21aaqmx0d01vmqsg7zi85pjgi3higr4ba0m52qf3mvxd6as")) (modules '((guix build utils))) (snippet '(begin -- 2.29.2 --8<---cut here---end--->8---
Re: guix build -d with a target causes many builds
Chris Marusich writes: > Hi, > > I've noticed that Guix builds many things when I ask it to instantiate a > derivation in the following way: > > [0] [env] marusich@garuda-lan:~/guix/repos/guix-worktrees/wip-ppc64 > $ guix build -d --target=powerpc64-linux-gnu -e '(@@ (gnu packages > make-bootstrap) %gcc-static)' > The following derivations will be built: >/gnu/store/i5wn3xl6p0zw1vglscgk0bs9dwc6hdh6-gcc-static-5.5.0.drv > > /gnu/store/3h2sk37iim53fh7g9r3sd1q0xzhqwa51-gcc-cross-powerpc64-linux-gnu-7.5.0.drv > > /gnu/store/84k0j5jm316cwf7h66vrw1vmvkd4kbck-glibc-cross-powerpc64-linux-gnu-2.31.drv > > /gnu/store/d36n7qy9xbgwpaw3nw8k9dj51hzmdnr4-gcc-cross-sans-libc-powerpc64-linux-gnu-7.5.0.drv > > /gnu/store/mqar9bnapfcfkna3rvy28awhlpd3q65q-binutils-cross-powerpc64-linux-gnu-2.34.drv > > /gnu/store/pzp93dw3rr6sp2ybi3dzs6kd7gvigfsk-ld-wrapper-powerpc64-linux-gnu-0.drv > > /gnu/store/n7dhpsq41q4kdbqgniljbwrlawvmmlp6-linux-libre-headers-cross-powerpc64-linux-gnu-5.4.20.drv > > /gnu/store/9p5anrji5wgkf66k09jhbsr3fqwwi7cn-gcc-cross-powerpc64-linux-gnu-7.5.0.drv > > /gnu/store/r4ac80znwlrnh4jmj2sbczc4mn66mqdg-glibc-cross-powerpc64-linux-gnu-2.31.drv >/gnu/store/ap8ri9ddka13vyrsl72pzqslagi4v7vj-gmp-6.2.0.drv > > /gnu/store/arxf2alzwf9rmz5hz8h11j4j12drxm3i-glibc-cross-powerpc64-linux-gnu-2.31.drv > > /gnu/store/d127w5flv12s4bfmpf4nwrvg3sibvfya-linux-libre-headers-cross-powerpc64-linux-gnu-5.4.20.drv >/gnu/store/j3d5kr7qlr6g3lq0dwc8z8jh6w814z9v-isl-0.18.drv >/gnu/store/j90wwahzd5ldw7ai11zf5lnp3kbbrmkh-mpfr-4.0.2.drv >/gnu/store/mz9fdir4avdda5cw1snyf8vhpq70c9na-libelf-0.8.13.drv >/gnu/store/q9x04y75mq2nfp2a6gwa0pvrgv60aah9-mpc-1.1.0.drv >/gnu/store/xk4yv7xj15qnl3zv2m8nnzrw0bdgjsx3-zlib-1.2.11.drv > 171.3 MB will be downloaded: >/gnu/store/ir3092v7657h6g4g2vlsw3zrli3rndb3-zlib-1.2.11.tar.gz >/gnu/store/amc0nizxsdcj212nk9a3ivr946hzhl6c-mpc-1.1.0 >/gnu/store/j4npmpn7dxmfknyfnhj4q4jmdwmk3klg-mpc-1.1.0.tar.gz >/gnu/store/0z3z3lhig0xyy817nv70p2hp1n1wqawa-libelf-0.8.13.tar.gz >/gnu/store/bkyiyc4hrjcd4ljx6jqf7z05hm4qxcwd-mpfr-4.0.2.tar.xz >/gnu/store/2jj3il6p5xrc4gkncj9303an81x2csc9-perl-5.30.2 >/gnu/store/n1yvkd7jk50qg1vv9cca6ywynkqvaqgq-ncurses-6.2 >/gnu/store/j709qpwy790bcra6w8kvyz1v5zcsw8df-texinfo-6.7 >/gnu/store/jk5k0sgqpj0sj4ymgq7m8g8617i0xji2-m4-1.4.18 >/gnu/store/57i37x74wz7ar703smykildzvhpdds1g-gmp-6.2.0 >/gnu/store/f2r1w8y7l3lpwh4i47nq2s1vqlqxq0jb-glibc-2.31 >/gnu/store/rgi1k6kx4v9m8449w00i6jfxvpgaz73g-glibc-2.31-static >/gnu/store/df1gdl0vwwbzv04snfha0g88rj02pni9-gcc-5.5.0 >/gnu/store/waz3iz17vlbpfc2fm9yiym6bgbsajghf-mpfr-4.0.2 >/gnu/store/hnsi8iaimgss3v81h7h1r8ck55c0968h-popt-1.18 >/gnu/store/vpy0bcjw0yzaj7j7qx8rfc88c7r357k3-rsync-3.1.3 >/gnu/store/0zcl1i3rbjc356138hx86b7yaz29g6fj-linux-libre-5.4.20-gnu.tar.xz >/gnu/store/l788x07ska5vffayz0gayv4hsx5flxal-module-import-compiled >/gnu/store/lqz1pygx3x5dd6ad2l3n8ixm1vh6czj4-python-minimal-3.8.2 >/gnu/store/ba6s3g925nggb57b1gpj2jkhqsq24s4q-libstdc++-7.5.0 >/gnu/store/xaclbfx6rvnbsq5qmry0251r7y82rgnv-libstdc++-headers-7.5.0 >/gnu/store/j8b9i4czpzb298zwa15wpyr42471qfbm-module-import-compiled > > The Guix documentation ((guix) Additional Build Options) says the "-d" > option should just give me the derivation paths, not the output paths: > > ‘--derivations’ > ‘-d’ > Return the derivation paths, not the output paths, of the given > packages. > > So, I'm confused about why all these builds need to happen. Didn't I > only ask Guix to instantiate the derivation - not realize it? In other > words, I expected Guix to calculate the transitive closure of the > requested derivation's inputs (mainly other derivations, I think?) and > write them to the store, without actually executing any significant > builds. > > I suppose that Guix is building these things in order to do just that, > but I don't quite understand why this happens. Can someone explain it? This can also happen even if I don't include --target: [0] marusich@garuda-lan:~/guix/repos/guix-worktrees/wip-ppc64 $ guix build -d -e '(@@ (gnu packages make-bootstrap) %gcc-static)' substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/jx7frgnihxqn75sgxwb9md420dbrh6cg-gcc-static-5.5.0.drv /gnu/store/h3y11yg8g44ss2b02rlq7is4mxqd8qfs-isl-0.18.drv /gnu/store/wx5mmblp5p5q85g55ggpcpc2kh12dsbv-zlib-1.2.11.drv /gnu/store/xk149wji2hlx0ls404agj3is77kazxx6-libelf-0.8.13.drv 10.9 MB will be downloaded: /gnu/store/f2r1w8y7l3lpwh4i47nq2s1vqlqxq0jb-glibc-2.31 /gnu/store/rgi1k6kx4v9m8449w00i6jfxvpgaz73g-glibc-2.31-static /gnu/store/b1940pfi34sxd3h3gxzx1x5mzwc55flp-linux-libre-headers-5.4.20 substituting /gnu/store/b1940pfi34sxd3h3gxzx1x5mzwc55flp-linux-libre-headers-5.4.20... downloading from
guix build -d with a target causes many builds
Hi, I've noticed that Guix builds many things when I ask it to instantiate a derivation in the following way: [0] [env] marusich@garuda-lan:~/guix/repos/guix-worktrees/wip-ppc64 $ guix build -d --target=powerpc64-linux-gnu -e '(@@ (gnu packages make-bootstrap) %gcc-static)' The following derivations will be built: /gnu/store/i5wn3xl6p0zw1vglscgk0bs9dwc6hdh6-gcc-static-5.5.0.drv /gnu/store/3h2sk37iim53fh7g9r3sd1q0xzhqwa51-gcc-cross-powerpc64-linux-gnu-7.5.0.drv /gnu/store/84k0j5jm316cwf7h66vrw1vmvkd4kbck-glibc-cross-powerpc64-linux-gnu-2.31.drv /gnu/store/d36n7qy9xbgwpaw3nw8k9dj51hzmdnr4-gcc-cross-sans-libc-powerpc64-linux-gnu-7.5.0.drv /gnu/store/mqar9bnapfcfkna3rvy28awhlpd3q65q-binutils-cross-powerpc64-linux-gnu-2.34.drv /gnu/store/pzp93dw3rr6sp2ybi3dzs6kd7gvigfsk-ld-wrapper-powerpc64-linux-gnu-0.drv /gnu/store/n7dhpsq41q4kdbqgniljbwrlawvmmlp6-linux-libre-headers-cross-powerpc64-linux-gnu-5.4.20.drv /gnu/store/9p5anrji5wgkf66k09jhbsr3fqwwi7cn-gcc-cross-powerpc64-linux-gnu-7.5.0.drv /gnu/store/r4ac80znwlrnh4jmj2sbczc4mn66mqdg-glibc-cross-powerpc64-linux-gnu-2.31.drv /gnu/store/ap8ri9ddka13vyrsl72pzqslagi4v7vj-gmp-6.2.0.drv /gnu/store/arxf2alzwf9rmz5hz8h11j4j12drxm3i-glibc-cross-powerpc64-linux-gnu-2.31.drv /gnu/store/d127w5flv12s4bfmpf4nwrvg3sibvfya-linux-libre-headers-cross-powerpc64-linux-gnu-5.4.20.drv /gnu/store/j3d5kr7qlr6g3lq0dwc8z8jh6w814z9v-isl-0.18.drv /gnu/store/j90wwahzd5ldw7ai11zf5lnp3kbbrmkh-mpfr-4.0.2.drv /gnu/store/mz9fdir4avdda5cw1snyf8vhpq70c9na-libelf-0.8.13.drv /gnu/store/q9x04y75mq2nfp2a6gwa0pvrgv60aah9-mpc-1.1.0.drv /gnu/store/xk4yv7xj15qnl3zv2m8nnzrw0bdgjsx3-zlib-1.2.11.drv 171.3 MB will be downloaded: /gnu/store/ir3092v7657h6g4g2vlsw3zrli3rndb3-zlib-1.2.11.tar.gz /gnu/store/amc0nizxsdcj212nk9a3ivr946hzhl6c-mpc-1.1.0 /gnu/store/j4npmpn7dxmfknyfnhj4q4jmdwmk3klg-mpc-1.1.0.tar.gz /gnu/store/0z3z3lhig0xyy817nv70p2hp1n1wqawa-libelf-0.8.13.tar.gz /gnu/store/bkyiyc4hrjcd4ljx6jqf7z05hm4qxcwd-mpfr-4.0.2.tar.xz /gnu/store/2jj3il6p5xrc4gkncj9303an81x2csc9-perl-5.30.2 /gnu/store/n1yvkd7jk50qg1vv9cca6ywynkqvaqgq-ncurses-6.2 /gnu/store/j709qpwy790bcra6w8kvyz1v5zcsw8df-texinfo-6.7 /gnu/store/jk5k0sgqpj0sj4ymgq7m8g8617i0xji2-m4-1.4.18 /gnu/store/57i37x74wz7ar703smykildzvhpdds1g-gmp-6.2.0 /gnu/store/f2r1w8y7l3lpwh4i47nq2s1vqlqxq0jb-glibc-2.31 /gnu/store/rgi1k6kx4v9m8449w00i6jfxvpgaz73g-glibc-2.31-static /gnu/store/df1gdl0vwwbzv04snfha0g88rj02pni9-gcc-5.5.0 /gnu/store/waz3iz17vlbpfc2fm9yiym6bgbsajghf-mpfr-4.0.2 /gnu/store/hnsi8iaimgss3v81h7h1r8ck55c0968h-popt-1.18 /gnu/store/vpy0bcjw0yzaj7j7qx8rfc88c7r357k3-rsync-3.1.3 /gnu/store/0zcl1i3rbjc356138hx86b7yaz29g6fj-linux-libre-5.4.20-gnu.tar.xz /gnu/store/l788x07ska5vffayz0gayv4hsx5flxal-module-import-compiled /gnu/store/lqz1pygx3x5dd6ad2l3n8ixm1vh6czj4-python-minimal-3.8.2 /gnu/store/ba6s3g925nggb57b1gpj2jkhqsq24s4q-libstdc++-7.5.0 /gnu/store/xaclbfx6rvnbsq5qmry0251r7y82rgnv-libstdc++-headers-7.5.0 /gnu/store/j8b9i4czpzb298zwa15wpyr42471qfbm-module-import-compiled The Guix documentation ((guix) Additional Build Options) says the "-d" option should just give me the derivation paths, not the output paths: ‘--derivations’ ‘-d’ Return the derivation paths, not the output paths, of the given packages. So, I'm confused about why all these builds need to happen. Didn't I only ask Guix to instantiate the derivation - not realize it? In other words, I expected Guix to calculate the transitive closure of the requested derivation's inputs (mainly other derivations, I think?) and write them to the store, without actually executing any significant builds. I suppose that Guix is building these things in order to do just that, but I don't quite understand why this happens. Can someone explain it? -- Chris signature.asc Description: PGP signature
Re: Staging branch [aarch64 failures]
The branch is building again! http://ci.guix.gnu.org/eval/10974 Qtbase is failing on aarch64: https://ci.guix.gnu.org/build/166439/details There errors like this: -- g++ -c -pipe -O2 -w -fPIC -I. -I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql -I/gnu/store/48i8mxxb1v4x632dff3i1dbdhsazm8bw-mariadb-10.5.8-dev/include/mysql/mysql -I/tmp/guix-build-qtbase-5.15.2.drv-0/qtbase-everywhere-src-5.15.2/mkspecs/linux-g++ -o main.o main.cpp g++ -Wl,-O1 -o mysql main.o -L/gnu/store/c9id1jf4r3cfys6289p92wpdhk1ryns0-mariadb-10.5.8-lib/lib/ ld: main.o: in function `main': main.cpp:(.text.startup+0x8): undefined reference to `mysql_get_client_version' collect2: error: ld returned 1 exit status make: *** [Makefile:69: mysql] Error 1 -- signature.asc Description: PGP signature
Re: [bootstrappable] wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Amazing work as always janneke. We will just have to do some kaem work to make it work all on POSIX systems. -Jeremiah
Re: A new paradigm for modifying operating system declarations
Hi Jan, > > Better but still don't like it. > Can't we put the os declaration into a variable and then pass it to a > procedure? > Say: > > > (define OS > > (operating-system > > (kernel linux-libre-5.4) > > ; ... other fields ... > > )) > > > > (install-zfs OS) > > (install-foo OS) > > (install-bar OS) > > (install-something OS) > > > > No, because `` objects are not mutable (or at least their formal interface doesn't expose any mutation). What we could do would be: ```scheme (define os (operating-system (kernel linux-libre-5.4) #;...)) (set! os (install-zfs os)) (set! os (install-foo os)) (set! os (install-bar os)) os ``` However, in many examples I've seen, the `configuration.scm` file looks like this: ```scheme (use-modules (gnu)) (use-package-modules #;...) (use-service-modules #;...) (operating-system (host-name "my-system") (timezone "Europe/Paris") (locale "en_US,utf-8") (kernel linux-libre-5.4) #;...) ``` What I want to avoid would be to have to nest the existing, usually screens-long, `operating-system` form. So compare: ```scheme (use-modules (gnu)) (use-package-modules #;...) (use-service-modules #;...) (decorate (install-zfs install-foo install-bar operating-system) (host-name "my-system") (timezone "Europe/Paris") (locale "en_US,utf-8") (kernel linux-libre-5.4) #;...) ``` versus: ```scheme (use-modules (gnu)) (use-package-modules #;...) (use-service-modules #;...) (define os (operating-system (host-name "my-system") (timezone "Europe/Paris") (locale "en_US,utf-8") (kernel linux-libre-5.4) #;...)) (set! os (install-zfs os)) (set! os (install-foo os)) (set! os (install-bar os)) os ``` I feel the former is better and requires less boilerplate. Now of course, I ***have*** seen examples as well where the `operating-system` is put in a `define` form as well, but those are rare and the default stuff that come with Guix tend not to use this, and we should consider that new Guix sysads might not be comfortable working with EMACS and prefer nano, so adding even just *one* additional layer of nestedness to a long `operating-system` form is not easy. Of course, such a sysad might then consider not indenting it correctly. Thanks raid5atemyhomework
Re: A new paradigm for modifying operating system declarations
Good morning Taylan,
> First, let me point out a more conventional alternative to what your
> 'decorate' macro does:
>
> (define (compose proc . rest)
> "Functional composition; e.g. ((compose x y) a) = (x (y a))."
> (if (null? rest)
> proc
> (let ((rest-proc (apply compose rest)))
> (lambda x
> (let-values ((x (apply rest-proc x)))
> (apply proc x))
>
> This allows for something like:
>
> ((compose install-foo install-bar install-zfs)
> (operating-system ...))
>
> Or perhaps cleaner:
>
> (define my-os-modifier (compose install-foo install-bar install-zfs))
>
> (my-os-modifier
> (operating-system ...))
>
> If you need custom modifications within, you can do:
>
> (define my-os-modifier
> (compose install-foo
> (lambda (os) ...)
> install-bar))
>
> It's more verbose, but doesn't "break" standard Scheme syntax as much.
> Function composition is conceptually pretty easy and probably more
> well-known than "decorators" (which I had never heard of, personally).
Yes, except function composition does not work on syntactic forms, which is
why, with `compose`, you have to separate the `operating-system` form instead
of being able to compose `operating-system` with the rest of the os
modifications.
The intent is that you have already an existing `operating-system` form with a
single layer of parenthesis. With `compose`, if you want to install ZFS and a
bunch of other complex OS modifications, you have to add a layer of
parenthesis. With `decorate`, you don't:
```scheme
((compose install-zfs install-foo)
(operating-system
(name "my-system") #;...))
;vs
(decorate (install-zfs
install-foo
operating-system)
(nmae "my-system") #;...)
```
>
> Fewer macros means the reader needs to keep fewer special rules in mind.
Fine, I'm doubling down then.
```scheme
(define-syntax compose-syntax
(syntax-rules ()
((compose-syntax (x ...))
(syntax-rules ::: ()
((form args :::)
(x ... args :::
((compose-syntax x)
(syntax-rules ::: ()
((form args :::)
(x args :::
((compose-syntax (x ...) y ...)
(syntax-rules ::: ()
((form args :::)
(let-syntax ((sub-syntax (compose-syntax y ...)))
(x ... (sub-syntax args :::))
((compose-syntax x y ...)
(syntax-rules ::: ()
((form args :::)
(let-syntax ((sub-syntax (compose-syntax y ...))
(x (sub-syntax args :::)
```
Then use it as follows:
```
(define-syntax my-operating-system
(compose-syntax
(install-zfs #:options '(("zfs_arc_max" 50)) #:os)
operating-system))
(my-operating-system
(name "my-system") #;...)
```
Again, the goal here is to keep the nestedness of your existing, very long
`operating-system` form, which your simple `compose` function fails to do,
because you can't compose syntax with `compose` and `operating-system` is a
syntax form.
>
> Secondly, I wonder if passing an OS declaration through various
> procedures that modify it is really the best approach in the first place.
>
> For build phases, we have the 'modify-phases' syntax. For services,
> there is 'modify-services'. Maybe there should be a 'modify-os' kind of
> syntax. (In other words, if we're going to invent new syntax, why not
> go all-out and create the most convenient syntax for the use-case.)
Because a *generic* form to modify the operating system is worthless --- you
can just define the operating-system directly.
What `install-zfs` does is that it installs the same kernel-specific package in
three different points:
* `kernel-loadable-modules`, because ZFS needs to get into the kernel somehow.
* `packages`, because the kernel module is useless if you don't have the
userland tools to interact with the kernel module.
* `services`, because ZFS is well-documented outside of Guix as automatically
mounting its filesystems at bootup, but that actually requires a bit of magic
in the `init` system, specifically you need to actually **load** the module,
then execute `zpool import -a -l` to have it scan for all filesystems and mount
those that need automounting.
Thus, an `install-zfs`, that is a *single* form that inserts the correct bits
in the correct ***three*** places, makes the experience of adding ZFS to your
`operating-system` easier because there's less scope for error in actually
adding the package. You just add a single `install-zfs`, not add three things
(plus an extra `(define my-zfs (make-zfs-package linux-libre-5.4))` before your
form).
Now, if this kind of simplifying form is useful for ZFS, I imagine that this
kind of simplifying form would also exist for other things you could install
into your operating system in the future. Thus, we need some way to take an
existing `` and pass it through a number of single
simplifying operating system transformations, which I don't think something
like `modify-os` would work well with.
Thanks
raid5atemyhomework
Re: A new paradigm for modifying operating system declarations
Dnia 2021-01-04, o godz. 15:38:38 raid5atemyhomework napisał(a): > Hi guix-developers, Hello. > ```scheme > (install-zfs > (operating-system > (kernel linux-libre-5.4) > ; ... other fields ... > )) > ``` I don't like this way of nesting the OS declaration inside of any other expression. > > ```scheme > (install-foo > (install-bar > (install-zfs >(operating-system > #;... This makes it even worse. > Which brings us back to the `decorate` form, which reduces nestedness: > > ```scheme > (decorate (install-foo >install-bar >install-zfs >operating-system) >#;...) Better but still don't like it. Can't we put the os declaration into a variable and then pass it to a procedure? Say: > ```scheme > (define OS > (operating-system > (kernel linux-libre-5.4) > ; ... other fields ... > )) > > (install-zfs OS) > (install-foo OS) > (install-bar OS) > (install-something OS) > > ``` > Thanks > raid5atemyhomework > Jan Wielkiewicz
The Guix Data Service can now compare system tests between two revisions
Hey, Small update on the stuff I'm doing around trying to test patches, the Guix Data Service can now compare system test derivations between two revisions [1]. I'm using this functionality to spot derivations to build to test patches, and expose the status of those through the Guix Data Service web interface. 1: https://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=6f89066355246a475897a66751afc7a75dd62aa3 There's an example of what this looks like here [2]. In the script I'm using to submit the builds to the Guix Build Coordinator instance, it has a list of the system tests that change with any change to Guix, and those will get a lower priority. Other system tests should be processed with a relatively high priority. 2: https://data.guix-patches.cbaines.net/compare/system-test-derivations?base_commit=fdfc1c81ba018dd808b0dfd9827a73262c716808_commit=6a468a0c4b92580468cefd3883ced71679e9615d=en_US.UTF-8 There's still the issues that insights from building things are currently visible in the Guix Data Service web interface, and not where they'd be more useful (Patchwork or Mumi for example), but I've got some ideas on how to start addressing that. Chris signature.asc Description: PGP signature
Re: A new paradigm for modifying operating system declarations
On 04.01.2021 16:38, raid5atemyhomework wrote: Hi guix-developers, I'd like to propose an idea for constructing `` objects. [... snip ...] What are your opinions? Blech? Yummy? Is it worth exploring this paradigm for adding particularly complex features to an operating system definition? Hi, Interesting idea. First, let me point out a more conventional alternative to what your 'decorate' macro does: (define (compose proc . rest) "Functional composition; e.g. ((compose x y) a) = (x (y a))." (if (null? rest) proc (let ((rest-proc (apply compose rest))) (lambda x (let-values ((x (apply rest-proc x))) (apply proc x)) This allows for something like: ((compose install-foo install-bar install-zfs) (operating-system ...)) Or perhaps cleaner: (define my-os-modifier (compose install-foo install-bar install-zfs)) (my-os-modifier (operating-system ...)) If you need custom modifications within, you can do: (define my-os-modifier (compose install-foo (lambda (os) ...) install-bar)) It's more verbose, but doesn't "break" standard Scheme syntax as much. Function composition is conceptually pretty easy and probably more well-known than "decorators" (which I had never heard of, personally). Fewer macros means the reader needs to keep fewer special rules in mind. --- Secondly, I wonder if passing an OS declaration through various procedures that modify it is really the best approach in the first place. For build phases, we have the 'modify-phases' syntax. For services, there is 'modify-services'. Maybe there should be a 'modify-os' kind of syntax. (In other words, if we're going to invent new syntax, why not go all-out and create the most convenient syntax for the use-case.) Just my thoughts. - Taylan
Re: Guile-zstd 0.1.1 released
On Sun, Dec 27, 2020 at 7:01 AM Ludovic Courtès wrote: > > Ludovic Courtès skribis: > > > I’m pleased to announce the first release of Guile-zstd: > > Oops, a file was missing from the repo, so here’s a brand new release! > > git clone https://notabug.org/guile-zstd/guile-zstd > cd guile-zstd > git checkout v0.1.1 # or f853c8eb81088f8fbf33d38e62cddea9a4984180 > git tag -v v0.1.1 > Great! This is now available in Guile Homebrew as well as guile-lzlib and guile-zlib. Btw, I sent a PR to guile-zstd: https://notabug.org/guile-zstd/guile-zstd/pulls/1 Aleix
Re: 02/05: gnu: libmad: Install pkg-config file.
Hi Ludovic, > It seems to me that we shouldn’t provide .pc files if upstream doesn’t > do it. The main reason is that developers who use Guix will come to > rely on it and unknowingly write code that doesn’t work on other > distros. (I remember pestering in the past as I stumbled upon packages > who depended on some library as packaged by a specific distro. :-)) > > WDYT? > > Apologies if I missed an earlier discussion! No apologies needed, the discussion was minimal at best. This patch is the result of my yielding to the forces of incompatibility you mention. Major distributions like Debian, Arch Linux [1], and Fedora [2] have all added pkg- config files for (at least) libmad. Audacity expects to find pkg-config files for the system libraries it uses, so I supplied those to follow the path of least resistance. If there's a way to supply "-I" and "-L" flags directly somewhere in the build process as was done before, I'm not opposed to reverting these changes and modifying Audacity's package definition myself during the next update. I'll investigate some of our other CMake packages for possible inspiration. Thanks, Kei [0]: https://packages.debian.org/buster/amd64/libmad0-dev/filelist [1]: https://github.com/archlinux/svntogit-packages/blob/packages/libmad/trunk/libmad.patch [2]: https://koji.fedoraproject.org/koji/rpminfo?fileOrder=-name=22388610=-id=0#filelist signature.asc Description: This is a digitally signed message part
Re: [bug#45644] closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.)
On Mon, Jan 04, 2021 at 06:02:54PM +0100, Tobias Geerinckx-Rice wrote: > Leo, does this happen to any guix-patch@ or just Ryan's? I've been noticing it with Ryan, but I don't know for sure if it happens with anyone else. Sometimes I remember to change Ryan's address, sometimes I don't. signature.asc Description: PGP signature
Re: [bug#45644] closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.)
Tobias Geerinckx-Rice 写道： I can't say what went wrong, only that I routinely apply patches from Guix MLs through mu4e and ‘git am’ without trouble. I think. The last ~dozen patches signed off by me seem fine, at least. ...no idea why I didn't actually test your actual patch that caused this actual question. commit e258898862f38aa9effa33ddae7fc517b0a403f4 (HEAD -> tmp) Author: Ryan Prior via Guix-patches via gnu: Add picoev. * gnu/packages/networking.scm (picoev): New variable. Signed-off-by: Tobias Geerinckx-Rice Eh, T G-R signature.asc Description: PGP signature
Re: [bug#45644] closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.)
via, Ryan Prior via Guix-patches via 写道： git send-email --to=guix-patc...@gnu.org --suppress-cc=self 0001-gnu-esbuild-Update-to-0.8.29.patch I (and many others) use git send-email, so it can't be directly to blame. I've never used it with an explicit patch file like that, though, only ‘-’, but that should change little. You shouldn't bother too much with Mailgun & the like, this has nothing to do with Protonmail. So I have to imagine that either Protonmail or your email server are changing the email address. Looks like us. It's by design. Mailing lists *have to* change email addresses now. If gnu.org sent out mail to mi^Whundreds of Guix users claiming to be directly from you: From: Ryan Prior it would amount to a poor forgery in this age of DMARC & DKIM. We'd be spamholed into oblivion by every recipient who doesn't go through extra (manual/heuristic) trouble to whitelist known MLs. And rightly so. So instead we munge the From header[0], with a note to make receivers aware of that fact: From: Ryan Prior via Guix-patches via Resent-From: Ryan Prior But this happens to every mail we resend, not only yours: From: Leo Famulari Resent-From: Leo Famulari I can't say what went wrong, only that I routinely apply patches from Guix MLs through mu4e and ‘git am’ without trouble. I think. The last ~dozen patches signed off by me seem fine, at least. Leo, does this happen to any guix-patch@ or just Ryan's? I don't know if it's possible with the commit-signing system you have in place to rewrite Guix repo history, or whether it would be worth it, No and no. Sorry. We also can't use .mailmap to rewrite the user-facing address. We'd be mapping all of guix-patc...@gnu.org to you. I can't think of a way to fix the past. It's unfortunate, but we'll live. Kind regards, T G-R [0]: We (Mailman?) get this part wrong, however: ‘Fu Barian via ’ looks cute, but it abuses the format & clutters address books everywhere with the bogus name ‘Fu Barian via’. signature.asc Description: PGP signature
wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Hi! I have reset Guix' wip-full-source-bootstrap branch with a first working implementation of the, well, "Full Source Bootstrap" for x86-linux (and x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from the Stage0 project (https://savannah.gnu.org/projects/stage0): --8<---cut here---start->8--- $ ./pre-inst-env guix build hello --verbosity=1 [..] /gnu/store/w61gf93yn2bxwyc6d1xp4y9lavvw1l3d-hello-2.10 17:58:54 janneke@dundal:~/src/guix/wip-fsb [env] --8<---cut here---end--->8--- (it runs too!). When you look at the bottom of the graph (see attached), you will notice "%bootstrap-guile": the driver that we use for the Guix build and also for "bootar", "gash", and "gash-utils". This "%bootstrap-guile" is not used as a seed in anything that is built, "%bootstrap-guile", "bootar", "gash", and "gash-utils" could be replaced with any other driver. Two new packages are added: "bootstrap-seeds", which contains the hex0-seed binary (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0-seed) with ASCII-equivalent (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0), and "m2-planet-boot" which, starting from hex0, via hex1, M0, hex2 and M1, bootstraps the M2-Planet transpiler. M2 is a language that closely resembles a subset of C. The breakthrough is that this M2-Planet can now compile a version of GNU Mes, as yet unreleased: the wip-m2 branch. This removes the remaining binary seeds: %bootstrap-mescc-tools and %bootstrap-mes, together with the "%bootstrap-mes-rewired" hack. Apart from a review there is still some work before it can be integrated, in short (from the top commit message): XXX TODO: * wip-full-source-bootstrap - release mes-0.24, update - possibly release m2-planet-1.8.0, update - rebase wip-full-source-bootstrap onto core-updates - integrate * wip-arm-bootstrap - finish; currently stuck on gawk-mesboot0 - release mes-0.23 - devise strategy for integrating wip-full-source-bootstrap and wip-arm-bootstrap Greetings, Janneke *) https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-full-source-bootstrap gcc-core-mesboot0-graph.dot Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: bug#45644: closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.)
‐‐‐ Original Message ‐‐‐ > By the way, your patches show that they are authored by "Ryan Prior via > Guix-patches via guix-patc...@gnu.org". Is that the correct email address? No, the correct email address is rpr...@protonmail.com There's maybe 15 commits in Guix that have that incorrect email address. I'm not sure where it comes from or how to get rid of it. I send my patches by running a command like: git send-email --to=guix-patc...@gnu.org --suppress-cc=self 0001-gnu-esbuild-Update-to-0.8.29.patch Git has my correct email address: $ git config user.email rpr...@protonmail.com So I have to imagine that either Protonmail or your email server are changing the email address. I don't know if it's possible with the commit-signing system you have in place to rewrite Guix repo history, or whether it would be worth it, but it would be nice to have my actual email on my commits instead of the weird munged one. If there's some behavior I can change to keep it from happening again the future I will certainly be flexible. One thing I'm going to try (unless there's any objection) is to try sending email through a third party like mailgun instead of using Protonmail's SMTP server. If it's confusing or triggers some kind of fraud prevention mechanism to get e-mails to the list that have my Protonmail address on them but aren't actually from Protonmail's server, then the next thing I could try is to request a gnu.org email address for the purposes of contributing to GNU software. Let me know what you think! Ryan
A new paradigm for modifying operating system declarations
Hi guix-developers,
I'd like to propose an idea for constructing `` objects.
First, let me present the `decorate` form:
```scheme
(define-syntax decorate
(syntax-rules ()
((decorate ((x ...)) a ...)
(x ... a ...))
((decorate (x) a ...)
(x a ...))
((decorate ((x ...) y ...) a ...)
(x ... (decorate (y ...) a ...)))
((decorate (x y ...) a ...)
(x (decorate (y ...) a ...)
```
Here's an example usage, instead of:
```scheme
(with-output-to-port (current-error-port)
(lambda ()
(system "echo" "an error occurred")))
```
We can use:
```scheme
(decorate ((with-output-to-port (current-error-port))
(lambda ()))
(system "echo" "an error occurred"))
```
The reason why this is relevant, is that when I was tying out
https://issues.guix.gnu.org/45643 , I ended up having several changes to the
base `operating-system` form:
```scheme
(define system-zfs (make-zfs-package linux-libre-5.4))
(operating-system
; ... other fields ...
(kernel linux-libre-5.4)
(kernel-loadable-modules (list (list system-zfs "module")))
(packages (cons* system-zfs
; ... other packages ...
%base-packages))
(services (cons* (service zfs-loader-service-type system-zfs)
; ... other services ...
%desktop-services)))
```
So, I imagined instead of exposing `make-zfs-package` and
`zfs-loader-service-type` and requiring so many modifications to various fields
of `operating-system` form, expose instead a `install-zfs` form, like so:
```scheme
(install-zfs
(operating-system
(kernel linux-libre-5.4)
; ... other fields ...
))
```
This `install-zfs` form would be defined as below:
```scheme
(define-public (install-zfs os)
(define system-zfs (make-zfs-package (operating-system-kernel os)))
(operating-system
(inherit os)
(location (operating-system-location os))
(kernel-loadable-modules (cons (list system-zfs "module")
(operating-system-kernel-loadable-modules
os)))
(packages (cons system-zfs
(operating-system-packages os)))
(services (cons (sevice zfs-loader-service-type system-zfs)
(operating-system-services os)
```
This would install ZFS "correctly", by adding the module to kernel loadable
modules, adding the package so that ZFS can be managed at runtime, and adding
the service to load ZFS module and import ZFS pools. The hope is that this
reduces the scope for errors in defining the operating system.
On the other hand, if this kind of pattern becomes common, then consider:
```scheme
(install-foo
(install-bar
(install-zfs
(operating-system
#;...
```
Which brings us back to the `decorate` form, which reduces nestedness:
```scheme
(decorate (install-foo
install-bar
install-zfs
operating-system)
#;...)
```
This seems quite elegant to me.
Now for example we can consider that the `"zfs"` module supports various
options as well, which would be put in a `/etc/modprobe.d/zfs.conf` file. We
could consider for example that `install-zfs` could support an `options` keyed
argument, which it will then add to the `modprobe` configuration file in an
`etc-service-type` in a new service that it extends to the given
``.
```scheme
(define install-zfs-full
(lambda* (#:key (options '()) os)
#;...))
(define-public install-zfs
(match-lambda
((os)
(install-zfs-full #:os os))
(rest
(apply install-zfs-full rest
```
Then in a system configuration:
```scheme
(decorate ((install-zfs #:options '(("zfs_arc_max" 50)) #:os)
operating-system)
#;...)
```
Something similar could be done for the `ddcci-driver-linux` example in the
documentation for `kernel-module-loader-service-type`:
```scheme
(define-public install-ddcci
(match-lambda
((os)
(install-ddcci-full #:os os))
(rest
(apply install-ddcci-full rest
(define install-ddcci-full
(lambda* (#:key (options '())) os)
(define config-file
(plain-file "ddcci.conf"
(if (null? options)
""
(string-join (cons "options ddcci" options)
" "
(operating-system
(inherit os)
(location (operating-system-location os))
(kernel-loadable-modules (cons ddcci-driver-linux
(operating-system-kernel-loadable-modules
os)))
(services
(cons* (service kernel-module-loader-service-type
'("ddcci" "ddcci_backlight"))
(simple-service 'ddcci-config etc-service-type
`(("modprobe.d/ddcci.conf" ,config-file)))
(operating-system-services os))
```
Then, in the system configuration file:
```scheme
(decorate (install-zfs
(install-ddcci #:options '("dyndbg" "delay=120") #:os)
operating-system)
(name "example-system")
Re: ZFS on Guix
Available here: https://issues.guix.gnu.org/45643
Please review! Hopefully it gets merged!
> Yes, I found that out after a little more digging.
>
> I have a preliminary patch here: https://issues.guix.gnu.org/45592
> However I will make a patchset based on this in order to support /home on ZFS
> and managing ZFS the "legacy" way by (file-system ...) declaration, please
> wait.
>
> > Hi,
> > the reason is that our "zfs" package uses
> > ("util-linux" ,util-linux "lib")
> > and then does
> > (substitute* "lib/libzfs/libzfs_mount.c"
> > (("/bin/mount") (string-append util-linux "/bin/mount"))
> > (("/bin/umount") (string-append util-linux "/bin/umount")))
> > .
> > That can't work.
> > zfs interna that will be patched by the Guix package are:
> > ./lib/libzfs/libzfs_mount.c
> > do_mount(const char *src, const char *mntpt, char *opts)
> > char *argv[9] = {
> > "/bin/mount",
> > "--no-canonicalize",
> > "-t", MNTTYPE_ZFS,
> > "-o", opts,
> > (char *)src,
> > (char *)mntpt,
> > (char *)NULL };
> > Easy fix would be to change our package to have both
> > ("util-linux:lib" ,util-linux "lib")
> > and
> > ("util-linux" ,util-linux)
> > .
Re: ZFS on Guix
Yes, I found that out after a little more digging.
I have a preliminary patch here: https://issues.guix.gnu.org/45592
However I will make a patchset based on this in order to support /home on ZFS
and managing ZFS the "legacy" way by (file-system ...) declaration, please wait.
> Hi,
>
> the reason is that our "zfs" package uses
>
> ("util-linux" ,util-linux "lib")
>
> and then does
>
> (substitute* "lib/libzfs/libzfs_mount.c"
> (("/bin/mount") (string-append util-linux "/bin/mount"))
> (("/bin/umount") (string-append util-linux "/bin/umount")))
>
> .
>
> That can't work.
>
> zfs interna that will be patched by the Guix package are:
>
> ./lib/libzfs/libzfs_mount.c
>
> do_mount(const char *src, const char *mntpt, char *opts)
>
> char *argv[9] = {
> "/bin/mount",
> "--no-canonicalize",
> "-t", MNTTYPE_ZFS,
> "-o", opts,
> (char *)src,
> (char *)mntpt,
> (char *)NULL };
>
> Easy fix would be to change our package to have both
>
> ("util-linux:lib" ,util-linux "lib")
>
> and
>
> ("util-linux" ,util-linux)
>
> .
Bump "Added magic-enum header-only library as a package."
Can this get reviewed? It looks like it fell between the cracks.
Re: 02/05: gnu: libmad: Install pkg-config file.
Hi Kei,
guix-comm...@gnu.org skribis:
> commit 83afa4e9a6aa4dc69f86651d795007dc96a31e64
> Author: Kei Kebreau
> AuthorDate: Sun Aug 2 16:54:03 2020 -0400
>
> gnu: libmad: Install pkg-config file.
>
> * gnu/packages/mp3.scm (libmad)[arguments]: Add 'install-pkg-config phase.
[...]
> +(add-after 'install 'install-pkg-config
> + (lambda* (#:key outputs #:allow-other-keys)
> +(let* ((out (assoc-ref outputs "out"))
> + (pkg-config-dir (string-append out "/lib/pkgconfig")))
> + (mkdir-p pkg-config-dir)
> + (with-output-to-file (string-append pkg-config-dir "/mad.pc")
> +(lambda _
> + (format #t
> + "prefix=~@*~a~@
> + libdir=${prefix}/lib~@
It seems to me that we shouldn’t provide .pc files if upstream doesn’t
do it. The main reason is that developers who use Guix will come to
rely on it and unknowingly write code that doesn’t work on other
distros. (I remember pestering in the past as I stumbled upon packages
who depended on some library as packaged by a specific distro. :-))
WDYT?
Apologies if I missed an earlier discussion!
Ludo’.
Re: bug#45069: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces
This issue seems to be gone for me with kernel 5.10.x. I guess it was a kernel bug then. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
