bug#64106: `modify-services` no longer affects multiple instances of the same service
I sent a patch to this ticket yesterday, before remembering this morning that y'all probably weren't auto-Cc'd on it by debbugs. Please have a look over it, especially the tests, in case I missed some functionality or misinterpreted some requirements. This will probably be deserving of a news item, since it will cause multiple deletes on the same service type to fail, and that's what at least some people are doing due to the previous patch. One option would be to convert the ‘raise’ incantations to warnings, at least for a while to give people a chance to update without their configs breaking, but I don't know a good way to do that. -bjc
bug#64106: [PATCH] gnu: services: Revert to deleting and updating all matching services
This patch reverts the behavior introduced in
181951207339508789b28ba7cb914f983319920f which caused ‘modify-services’
clauses to only match a single instance of a service.
We will now match all service instances when doing a deletion or update, while
still raising an exception when trying to match against a service that does
not exist in the services list, or which was deleted explicitly by a ‘delete’
clause (or an update clause that returns ‘#f’ for the service).
Fixes: #64106
* gnu/services.scm (%modify-services): New procedure.
(modify-services): Use it.
(apply-clauses): Add DELETED-SERVICES argument, change to modify one service
at a time.
* tests/services.scm
("modify-services: delete then modify"),
("modify-services: modify then delete"),
("modify-services: delete multiple services of the same type"),
("modify-services: modify multiple services of the same type"): New tests.
---
gnu/services.scm | 95 +++---
tests/services.scm | 68 +
2 files changed, 124 insertions(+), 39 deletions(-)
diff --git a/gnu/services.scm b/gnu/services.scm
index 109e050a23..4c5b9b16df 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -320,45 +320,62 @@ (define-syntax clause-alist
((_)
'(
-(define (apply-clauses clauses services)
- "Apply CLAUSES, an alist as returned by 'clause-alist', to SERVICES, a list
-of services. Use each clause at most once; raise an error if a clause was not
-used."
- (let loop ((services services)
- (clauses clauses)
- (result '()))
-(match services
- (()
- (match clauses
- (() ;all clauses fired, good
- (reverse result))
- (((kind _ properties) _ ...);one or more clauses didn't match
- (raise (make-compound-condition
- (condition
- (
-(location (source-properties->location properties
- (formatted-message
- (G_ "modify-services: service '~a' not found in service
list")
- (service-type-name kind)))
- ((head . tail)
- (let ((service clauses
- (fold2 (lambda (clause service remainder)
- (if service
- (match clause
- ((kind proc properties)
- (if (eq? kind (service-kind service))
- (values (proc service) remainder)
- (values service
- (cons clause remainder)
- (values #f (cons clause remainder
- head
+(define (apply-clauses clauses service deleted-services)
+ (define (raise-if-deleted kind properties)
+(match (find (lambda (deleted)
+ (match deleted
+ ((deleted-kind _)
+ (eq? kind deleted-kind
+ deleted-services)
+ ((_ deleted-properties)
+ (raise (make-compound-condition
+ (condition
+(
+ (location (source-properties->location properties
+ (formatted-message
+(G_ "modify-services: service '~a' was deleted here: ~a")
+(service-type-name kind)
+(source-properties->location deleted-properties)
+ (_ #t)))
+
+ (match clauses
+(((kind proc properties) . rest)
+ (begin
+ (raise-if-deleted kind properties)
+ (if (eq? (and service (service-kind service))
+kind)
+ (let ((new-service (proc service)))
+ (apply-clauses rest new-service
+(if new-service
+deleted-services
+(cons (list kind properties)
+ deleted-services
+ (apply-clauses rest service deleted-services
+(()
+ service)))
+
+(define (%modify-services services clauses)
+ (define (raise-if-not-found clause)
+(match clause
+ ((kind _ properties)
+ (when (not (find (lambda (service)
+ (eq? kind (service-kind service)))
+services))
+ (raise (make-compound-condition
+ (condition
+ (
+ (location (source-properties->location properties
+ (formatted-message
+ (G_ "modify-services: service '~a' not found in service
list")
+ (service-type-name kind
+
+ (for-each raise-if-not-found clauses)
+ (reverse (filter-map identity
+ (fold (lambda (service services)
+ (cons (apply-clauses clauses service '())
+
bug#64106: `modify-services` no longer affects multiple instances of the same service
Ludovic Courtès writes: > It wasn’t really intended, more a side effect of the implementation, and > I agree it should be fixed. There have been a number of complaints about the behavior change, and I think the patch should probably be reverted. My only intention was to raise an error for the cases where a service was used in ‘modify-services’ that wasn't defined, as that's something people would probably want to know about and fix, but the sequelae to that change have changed the primary behavior of ‘modify-services’ in a disruptive way (and without a corresponding news item). I've taken a number of stabs at tweaking the current code to satisfy both my desire to raise an error for mis-configurations as well as match every instance of a service, but I can't find a way to do it that also preserves service ordering. However, if ‘modify-services’ can be changed to do two passes, the first as a sanity check which verifies service references and raises errors, and the second to do the actual modification, that should work well. I'm not concerned with efficiency particularly. Unless there are many thousands of services I sincerely doubt anyone would notice the extra pass, even on a Raspberry Pi. WDYT? -bjc
bug#63921: Activation snippets in reverse order, prevent boot
Jelle Licht writes: Thanks for the workaround! Is this "thou shall delete N times, and _exactly_ N times" effect of the recently pushed change functioning as intended? It imho seems pretty brittle and verbose compared to how things were before. We could add a ‘delete-all’ in addition to the existing ‘delete’ behavior. Alternately, we could change ‘delete’ back to deleting everything and adding ‘delete-one’. Or have both ‘delete-all’ and ‘delete-one’ where ‘delete’ is a deprecated alias for ‘delete-all’ to add a path forward for older configs. Of the three I'm most partial to the last, though I love none of them. I keep thinking the right solution is to have a delete that can match with a predicate, but then why not just use ‘filter’ or ‘remove’? -bjc
bug#53580: shepherd's architecture
Attila Lendvai writes: it doesn't seem to be an insurmontable task to make sure that guile can safely unlink a module from its heap, check if there are any references into the module to be dropped, and then reload this module from disk. the already runing fibers would keep the required code in the heap until after they are stopped/restarted. then the module would get GC'd eventually. this would help solve the problem that a reconfigured service may have a completely different start/stop code. and by taking some careful shortcuts we may be able to make reloading work without having to stop the service process in question. Erlang has had hot code reloading for decades, built around the needs of 100% uptime systems. The problem is more complex than it often appears to people who are used to how lisps traditionally do it. I strongly recommend reading up on Erlang's migration system. Briefly: you can't just swap out function definitions, because they rely on non-function state which needs to be migrated along with the function itself, and you can't do it whenever you want, because external actors may be relying on a view of the internal state. To accomplish this, Erlang has a lot of machinery, and it fits in to the core design of the language and runtime which would be extremely difficult to port over to non-Erlang languages. Doing it in Scheme is probably possible in an academic sense, but not in a practical one. OTOH, Lisp Flavoured Erlang exists if you want that syntax. There would definitely be advantages to writing an init (and, indeed, any service that needs 100% uptime) on top of the Erlang virtual machine. But going the other way, by porting Erlang's functionality into Scheme, is going to be a wash. in this setup most of the complexity and the evolution of the shepherd codebase would happen in the runner, and the other two parts could be kept minimal and would rarely need to change (and thus require a reboot). Accepting that dramatic enough changes to PID 1 are going to require a reboot seems reasonable to me. They should be even more rare than kernel updates, and we accept rebooting there already. -bjc
bug#63238: issue linking to librt
librt and libpthread were merged into libc with glibc 2.34, however, for compatibility, there exist empty .a files to satisfy the linker. But because Guix has a separate output for the static libraries, they need to be explicitly installed from ‘glibc:static’, which allows Cargo to do its thing. Cargo itself should probably be fixed so that it no longer tries to link with these libraries, but until that time, the above work-around suffices.
bug#63190: [Shepherd] Nested calls lead to a hang
Ludovic Courtès writes: (Whether that leads to a deadlock depends; at first sight, I’d say there’s no reason for this to deadlock in general, but you can of course end up with a logic bug like A starts B, which spawns a client to start A, which doesn’t start because it’s waiting for B.) It's been a while since I looked at this, but my rough recollection is the deadlock occurs because shepherd can only process one request over its socket at a time. If that request happens to *also* try to talk over the same socket, it'll hang indefinitely waiting for its turn to come off the accept queue. I'm not sure there's much to be done in the 0.9 version of shepherd about it. I'm hoping that 0.10 and up will be able to cope with situations like this without completely deadlocking the shepherd itself. It's obviously pretty bad if pid 1 hangs for any reason at all, even user error. -bjc
bug#63261: Recent changes to git config cause errors for non-committers
I've run into two issues with the recent changes to git config integration: 1) All commits must now be signed, even if you're not a committer. This breaks just tons of things, including rebasing. I'm not sure how to fix this without just disabling that configuration line altogether. 2) Some ‘make’ rules now require git to be installed so that ‘git config’ can add ‘etc/git/gitconfig’ to the local configuration. So, for instance, ‘guix shell --pure -D guix -- make’ will now fail. Calls to git should be prefixed with a test to see if there is a git executable in the path. -bjc
bug#62698: bind:utils
Maxim Cournoyer writes: Thanks for finding the problem. Should we leave this bug open until specification->package+output is properly documented in our manual, with an example? If yes, would you like to try your hand at adding it? I've looked at this briefly, and can't figure out a good place to document this (I'm also not particularly good with TexInfo). I'm okay with closing the bug. Though I will say that I think this procedure is a bit of a foot-gun. Multiple value returns are always kind of weird, and in this particular case I don't see the value at all; the only reason to use ‘specification->package+output’ would be to get both the package and the output, so the minor advantages of multi-value returns are obviated. On top of that, does this even get used outside of system/home definitions? And in those places you always want a list. I realize a lot of code uses the current semantics, so changing them would be extremely difficult at this late stage. It's worth thinking about adding another procedure that does the expected thing (returning a list of package and output), IMHO, and transitioning over to that. -bjc
bug#62936: [core-updates] pre-inst-env no longer works
Josselin Poiret writes: Ran into this problem myself, here's the reason and the fix: We build a modified `guile` executable in the source tree (for reasons), and use that to run guix. Note that it is only added to PATH by ./pre-inst-env! That guile executable is linked against glibc, and so after upgrading to a newer glibc, it isn't rebuilt (I don't know how autotools cope with external dependencies getting updated). So glibc 2.33 gets loaded, and once (gcrypt) tries to open the libgcrypt library, it fails because that newer library needs at least glibc 2.34. The solution is just to `rm guile` inside of the checkout and run `make` again. With a lot of help on IRC, the culprit was discovered: you *must* run ‘guix pull --branch=core-updates’ to update your current profile's guix. This is because guix does not update itself without the pull. Without this step, the guix in your user profile will keep around its old rules about which C compiler to use, which, in turn, pulls in the old glibc, which causes the error I initially reported. -bjc
bug#62936: [core-updates] pre-inst-env no longer works
I did a full rebuild before submitting this bug: bootstrap -> configure -> make clean -> make. FWIW, I still have the issue with ‘pre-inst-env’ when not run from within ‘guix shell -D guix’, which is a step I have never previously needed. As I just explained on IRC: --8<---cut here---start->8--- i'm confused why it's suddenly a problem, though. i've never needed to use ‘guix shell’ with pre-inst-env before [15:41] ludo says it's libgit2 linking against an old libc, but i have no idea how that's even possible for one thing: my system has been reconfigured. all my packages are now running core-updates, and that includes libgit2. for another: doesn't libgit link with a specific path in /gnu/store, so it'll use whatever glibc it needs regardless of what's in my “system” configuration? --8<---cut here---end--->8--- Even if this is some particular problem to my build environment somehow, I'd love an explanation as to what's going on because I'm extremely confused. In case it matters, I've re-run ‘system reconfigure’ and ‘home reconfigure’ since moving to core-updates, thinking maybe there's some bootstrapping issue. I'm now 2 system and home generations into core-updates, but I have the same problem. Thanks,
bug#62936: [core-updates] pre-inst-env no longer works
Ludovic Courtès writes: Make sure everything is in sync, and use ‘guix shell -D guix -C’ to avoid interference! This has made the glibc locale error and the libgit2 bindings to work. Thank you! However, I'm not sure how this happened in the first place. The system I'm running on is running core-updates, from a ‘guix system reconfigure’ and reboot. Where is the improperly linked libgit2 coming from that guix is loading it (and then, only when used with ‘pre-inst-env’). -bjc
bug#62936: [core-updates] pre-inst-env no longer works
Simon Tournier writes: ~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh Are you sure about the dash-dash (--) with ./pre-inst-env? I get this: $ ./pre-inst-env guix describe Git checkout: repository: /home/simon/src/guix/wk/core-updates/ branch: core-updates commit: 1c86be2fd69d84f536518cc5e4a32c067e851709 $ ./pre-inst-env -- guix describe ./pre-inst-env: 55: exec: --: not found Odd. I didn't think it made a difference (though I don't currently have a working ‘pre-inst-env’) to check with. Do note that the error you're seeing is different from the one I posted, and explicable. If I try without the double dash, there's no difference for me: --8<---cut here---start->8--- ~/src/guix-core-updates $ ./pre-inst-env guix build emacs-magit hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: guix install glibc-locales export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" See the "Application Setup" section in the manual, for more info. guix build: error: gcry_md_hash_buffer: Function not implemented --8<---cut here---end--->8--- As a fun aside, using ‘guix describe’ also fails, though at a different C binding point: --8<---cut here---start->8--- ~/src/guix-core-updates $ ./pre-inst-env guix describe hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: guix install glibc-locales export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" See the "Application Setup" section in the manual, for more info. Backtrace: In ice-9/threads.scm: 390:8 19 (_ _) In ice-9/boot-9.scm: 3253:13 18 (_) In ice-9/threads.scm: 390:8 17 (_ _) In ice-9/boot-9.scm: 3544:20 16 (_) 2836:4 15 (save-module-excursion _) 3564:26 14 (_) In unknown file: 13 (primitive-load-path "guix/channels" # 7f7677c326e0 at ice-9/boot-9.scm:3551?>) In ice-9/boot-9.scm: 3923:23 12 (_) 3411:4 11 (define-module* _ #:filename _ #:pure _ #:version _ #:imports _ #:exports _ # _ # _ # _ ?) 3424:24 10 (_) 222:17 9 (map1 (((git)) ((guix git)) ((guix git-authenticate)) ((guix openpgp) #:select (?)) # ?)) 3327:17 8 (resolve-interface (git) #:select _ #:hide _ #:prefix _ #:renamer _ #:version _) In ice-9/threads.scm: 390:8 7 (_ _) In ice-9/boot-9.scm: 3253:13 6 (_) In ice-9/threads.scm: 390:8 5 (_ _) In ice-9/boot-9.scm: 3544:20 4 (_) 2836:4 3 (save-module-excursion # ice-9/boot-9.scm:3545:21 ()>) 3564:26 2 (_) In unknown file: 1 (primitive-load-path "git" # at ice-9/boot-9.scm:3551:37 ()>) In git/bindings.scm: 66:8 0 (_ . _) git/bindings.scm:66:8: In procedure git_libgit2_init: Function not implemented --8<---cut here---end--->8--- -bjc
bug#62936: [core-updates] pre-inst-env no longer works
After re-configuring my system with core updates and rebooting, I'm no longer able to use Guix' ‘pre-inst-env’ command to do testing: --8<---cut here---start->8--- ~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: guix install glibc-locales export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" See the "Application Setup" section in the manual, for more info. guix build: error: gcry_md_hash_buffer: Function not implemented ~/src/guix-core-updates $ --8<---cut here---end--->8--- System guix (which is now from core-updates on my system) works fine: --8<---cut here---start->8--- ~/src/guix-core-updates $ guix build zsh /gnu/store/viwf9ar2cgly6im3yk9wf2c1dq8l1z3g-zsh-5.8.1 --8<---cut here---end--->8--- I'm not sure what's going on with the locales warning above, but I assume it's related to #62934. -bjc
bug#62933: [core-updates] emacs native-comp fails
When loading Emacs from core-updates, I get a bunch of warnings from native-comp that make me think it's not working at all: --8<---cut here---start->8--- [...] Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging Warning (comp): /net/snorlax/home/bjc/.guix-home/profile/share/emacs/site-lisp/guix-emacs.el: Error: Internal native compiler error failed to compile Disable showing Disable logging Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging Warning (comp): /gnu/store/5jyi1pa4hwndfrr288jy3z4yhga9sf6x-emacs-embark-0.21.1/share/emacs/site-lisp/embark-0.21.1/embark-autoloads.el: Error: Internal native compiler error failed to compile Disable showing Disable logging Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging Warning (comp): /gnu/store/wv29lgd8dizc73h5k2ijhq684fgl6iqi-emacs-geiser-0.28.2/share/emacs/site-lisp/geiser-0.28.2/geiser-autoloads.el: Error: Internal native compiler error failed to compile Disable showing Disable logging [...] --8<---cut here---end--->8--- -bjc
bug#62934: [core-updates] locales not installed properly
It appears as though core-updates isn't installing locales correctly, as I'm getting warnings all over the place about unsupported locales: --8<---cut here---start->8--- ~/src/guix-core-updates $ echo $LANG en_US.utf8 --8<---cut here---end--->8--- Starting Emacs: --8<---cut here---start->8--- ~/src/guix-core-updates $ emacs (process:5828): Gtk-WARNING **: 10:06:55.544: Locale not supported by C library. Using the fallback 'C' locale. --8<---cut here---end--->8--- Or herd: --8<---cut here---start->8--- ~/src/guix-core-updates $ herd status guile: warning: failed to install locale Started: + dbus + discord + emacs + gpg-agent + keepassxc + offlineimap-gmail + offlineimap-spork + pulseaudio-rtp-source + root + sway-tasks + swayidle + syncthing-gtk + waybar --8<---cut here---end--->8--- -bjc
bug#62820: [core-updates] error building xkeyboard-config
Looks like something changed between 2.34 (on master) and 2.36 (on core-updates) which caused ‘share/X11/rules/base’ to generate improperly. On core-updates: --8<---cut here---start->8--- ~/src/guix-core-updates $ ./pre-inst-env guix build xkeyboard-config /gnu/store/0yg8hlbvynr5bq8816srgcyjf50sp54h-xkeyboard-config-2.36 --8<---cut here---end--->8--- Which includes the following broken lines in ‘rules/base’: --8<---cut here---start->8--- ! $inetmediakbds = \ a4_rfkb23 a4techKB21 a4techKBS8 acer_ferrari4k acer_laptop / armada asus_laptop benqx btc5090 btc6301urf btc9019u / cherrybluea cherryblueb cherrycyboard chicony042 / compalfl90 compaqik13 compaqik18 creativedw7000 / cymotionlinux dellm65 dellusbmm dexxa diamond dtk2000 / emachines ennyah_dkb1008 fscaa1667g genius geniuscomfy / geniuscomfy2 geniuskb19e hp5xx hpdv5 hpi6 hpxe3gc hpxe3gf / hpxe4xxx hpxt1000 hpzt11xx inspiron latitude / logidinovo logidinovoedge logitech_base logitech_g15 / microsoft4000 microsoft7000 microsoftmult microsoftpro / microsoftprooem mx1998 mx2500 mx2750 pc105 precision_m / presario propeller samsung4500 samsung4510 scorpius / silvercrest sk1300 sk2500 sk7100 sp_inet targa_v811 / thinkpad thinkpad60 tm2030USB-102 tm2030USB-106 / toshiba_s3000 trust trustda trust_slimline unitekkb1925 --8<---cut here---end--->8--- Note the forward slash as a line continuation character, rather than a backslash, which is used everywhere. The same file on master: --8<---cut here---start->8--- ~/src/guix $ ./pre-inst-env guix build xkeyboard-config /gnu/store/8mszv7v6kqdyavpvf8zb7kkagaan5vri-xkeyboard-config-2.34 --8<---cut here---end--->8--- This is the equivalent block: --8<---cut here---start->8--- ! $inetmediakbds = acer_ferrari4k acer_laptop btc5090 btc9019u cherryblueb \ cherrybluea herrycyboard chicony042 compaqik13 compaqik18 \ armada presario dellm65 inspiron dellusbmm diamond \ ennyah_dkb1008 genius geniuscomfy2 hpi6 hpxe3gc hpxe3gf \ hpxt1000 hpzt11xx hpdv5 hpxe4xxx hp5xx thinkpad60 ogitech_base \ logidinovo logidinovoedge logitech_g15 mx1998 mx2500 mx2750 \ microsoft4000 microsoft7000 microsoftprooem microsoftmult \ propeller samsung4500 samsung4510 sk1300 sk2500 sk7100 \ toshiba_s3000 trust trustda cymotionlinux silvercrest \ emachines benqx unitekkb1925 creativedw7000 compalfl90 \ pc105 a4techKB21 a4techKBS8 a4_rfkb23 asus_laptop btc6301urf \ dexxa dtk2000 fscaa1667g geniuskb19e geniuscomfy latitude \ microsoftpro precision_m scorpius sp_inet targa_v811 thinkpad \ tm2030USB-102 tm2030USB-106 trust_slimline --8<---cut here---end--->8--- This is causing issues when building my system config, as ‘(keyboard-layout "us")’ with core-updates returns a syntax error due to the above. I'm not sure what's going on here, as it doesn't appear as though the package has any custom rules. It did change from ‘gnu-build-system’ to ‘meson-build-system’ with the version bump, though, so maybe there's something in there? -bjc
bug#55586: failure when linking glibc-mesboot-2.16.0
This appears to have been fixed, or at least I'm no longer getting this error.
bug#62698: bind:utils
Αντώνιος Τσώλης writes:
Well, I use this:
(packages
(append
(map specification->package+output
'("bind:utils" ... ))
%base-packages))
But I am new to scheme/guile/guix, so maybe I do something
wrong. Anyway, thanks for confirming that it works on your
side. It's probably an issue with my configuration. :)
I suspected this was the problem. You really do need to use:
(map (compose list specification->package+output)
'("bind:utils"))
Because ‘specification->package+output’ returns two values, and
you'll need to combine those into a list for the second value (the
‘utils’ output) to be seen.
-bjc
bug#62725: Undefined activation ordering between ‘setuid-program-service-type’ and ‘account-service-type’
There is currently no way to ensure that an account exists before
creating /run/setuid-programs, which means a setuid-program which
uses a custom user or group will fail to be created if setuid
activation happens before account activation.
As an example, here's a system config where I'm trying to install
‘/run/setuid-programs/dumpcap’ as setuid root with a primary group
of ‘wireshark’, also created by this config:
--8<---cut here---start->8---
(use-modules (gnu)
(gnu system setuid))
(use-package-modules networking)
(use-service-modules setuid)
;; TODO: make name configurable
(define %wireshark-groups
(list (user-group
(name "wireshark")
(system? #t
(define %wireshark-setuid-programs
(list (setuid-program
(program (file-append wireshark "/bin/dumpcap"))
(group "wireshark")
#;(mask #o550
(define wireshark-service-type
(service-type
(name 'wireshark)
(description "Allow use of wireshark by regular users in the
@code{wireshark} group.")
(extensions
(list (service-extension account-service-type
(const %wireshark-groups))
(service-extension setuid-program-service-type
(const %wireshark-setuid-programs
(default-value #f)))
(operating-system
(locale "en_US.utf8")
(timezone "America/New_York")
(keyboard-layout (keyboard-layout "us"))
(host-name "wireshark-test")
(users (cons* (user-account
(name "test")
(group "users")
(password (crypt "test" "$6$test"))
(supplementary-groups
'("wireshark")))
%base-user-accounts))
(packages
(cons*
(specification->package "wireshark")
%base-packages))
(services
(cons*
(service wireshark-service-type)
%base-services))
(bootloader
(bootloader-configuration
(bootloader grub-efi-bootloader)
(targets '("/boot/efi"))
(keyboard-layout keyboard-layout)))
(file-systems
(cons* (file-system
(mount-point "/")
(device
(uuid "14f4e958-be9e-41bb-bd25-e90a7330093c"
'btrfs))
(type "btrfs"))
(file-system
(mount-point "/boot/efi")
(device (uuid "6866-56B1" 'fat32))
(type "vfat"))
%base-file-systems)))
--8<---cut here---end--->8---
When trying to boot this system in a VM, I'm told that the dumpcap
binary couldn't be created because the file wasn't found. The
returned error is improperly attributed: the source file does
exist, and the error code is actually coming from getgrent(3)
which cannot find the ‘wireshark’ group.
Tracing through the activation scripts shows this to be because,
in this case, setuid-program activation happens before
account-activation.
Thanks to jpoiret for doing a lot of the investigative work here,
which I'm merely verifying through testing.
I believe the correct solution here is to move ‘setuid-program’
activation to a one-shot Shepherd service, because Shepherd allows
explicit ordering, as well as other advantages. To that end, I
have a patch which does precisely that, which I will send to the
patches list shorty.
-bjc
bug#62698: bind:utils
With the config below, I have ‘host’, ‘dig’, and ‘nslookup’ in my
path. Note that I'm using the ‘(compose list
specification->package+output)’ form, though. If you're not using that,
you may be accidentally loading the ‘bind’ package with the default
‘out’ output, instead of the ‘utils’ one. If that's the case, then
you're not going to have the utils in your PATH because they haven't
been installed.
--8<---cut here---start->8---
;; Testing whether ‘bind:utils’ gets installed in the path (see: #62698)
(use-modules (gnu)
(gnu system setuid))
(use-package-modules networking)
(operating-system
(locale "en_US.utf8")
(timezone "America/New_York")
(keyboard-layout (keyboard-layout "us"))
(host-name "wireshark-test")
(users (cons* (user-account
(name "test")
(group "users")
(password (crypt "test" "$6$test")))
%base-user-accounts))
(packages
(cons*
((compose list specification->package+output) "bind:utils")
%base-packages))
(bootloader
(bootloader-configuration
(bootloader grub-efi-bootloader)
(targets '("/boot/efi"))
(keyboard-layout keyboard-layout)))
(file-systems
(cons* (file-system
(mount-point "/")
(device
(uuid "14f4e958-be9e-41bb-bd25-e90a7330093c"
'btrfs))
(type "btrfs"))
(file-system
(mount-point "/boot/efi")
(device (uuid "6866-56B1" 'fat32))
(type "vfat"))
%base-file-systems)))
--8<---cut here---end--->8---
Running with ‘sh -c $(guix system vm --no-graphic
bind-utils-config.scm)’:
--8<---cut here---start->8---
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use 'gnu.repl' for an initrd REPL.
loading kernel modules...
loading '/gnu/store/z0w00ijl944lzc263gzaw17wmlg7k08f-system/boot'...
making '/gnu/store/z0w00ijl944lzc263gzaw17wmlg7k08f-system' the current
system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/rs296i8fpqx2gvy8w0za9wyd1spgmy2k-etc...
Please wait while gathering entropy to generate the key pair;
this may take time...
[2.966863] udevd[75]: no sender credentials received, message ignored
[3.306595] Error: Driver 'pcspkr' is already registered, aborting...
nscd: 99 monitoring file `/etc/hosts` (1)
nscd: 99 monitoring directory `/etc` (2)
nscd: 99 monitoring file `/etc/resolv.conf` (3)
nscd: 99 monitoring directory `/etc` (2)
nscd: 99 monitoring file `/etc/services` (4)
nscd: 99 monitoring directory `/etc` (2)
nscd: 99 monitoring file `/etc/nsswitch.conf` (5)
nscd: 99 monitoring directory `/etc` (2)
nscd: 99 monitoring file `/etc/nsswitch.conf` (5)
nscd: 99 monitoring directory `/etc` (2)
This is the GNU system. Welcome.
wireshark-test login: test
Password:
This is the GNU operating system, welcome!
test@wireshark-test ~$ which host
/run/current-system/profile/bin/host
test@wireshark-test ~$ which dig
/run/current-system/profile/bin/dig
test@wireshark-test ~$ which nslookup
/run/current-system/profile/bin/nslookup
--8<---cut here---end--->8---
bug#62698: bind:utils
They are included for me: --8<---cut here---start->8--- bjc@psyduck:~/.config/emacs% for i in dig host nslookup; do which $i; done /net/snorlax/home/bjc/.guix-home/profile/bin/dig /net/snorlax/home/bjc/.guix-home/profile/bin/host /net/snorlax/home/bjc/.guix-home/profile/bin/nslookup --8<---cut here---end--->8--- or from ‘guix shell’: --8<---cut here---start->8--- bjc@psyduck:~/.config/emacs% guix shell --pure bash bind:utils -- sh -c 'for i in dig host nslookup; do $i gnu.org; done' The following derivation will be built: /gnu/store/frdbdpa3klj5r87pm468v4qi8lfcx4y7-profile.drv building CA certificate bundle... listing Emacs sub-directories... building fonts directory... building directory of Info manuals... building profile with 2 packages... ; <<>> DiG 9.16.38 <<>> gnu.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6793 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;gnu.org. IN A ;; ANSWER SECTION: gnu.org.300 IN A 209.51.188.116 ;; Query time: 27 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Apr 06 14:26:52 EDT 2023 ;; MSG SIZE rcvd: 52 gnu.org has address 209.51.188.116 gnu.org has IPv6 address 2001:470:142:5::116 gnu.org mail is handled by 10 eggs.gnu.org. Server: 192.168.1.1 Address:192.168.1.1#53 Non-authoritative answer: Name: gnu.org Address: 209.51.188.116 Name: gnu.org Address: 2001:470:142:5::116 --8<---cut here---end--->8---
bug#55583: guix-daemon doesn't cleanly error-out on case-insensitive file systems.
Maxime Devos writes: Create a file /gnu/store/case-sensitivity-test (if it doesn't already exist). Open /gnu/store/CASE-SENSITIVITY-TEST. If it succeeds, you have a case-sensitive file system. Hah. I was so wrapped up in thinking about kernel or POSIX APIs I missed the obvious thing. ;) /If/ we go this route, though, I’d suggest a small change to handle so-called “mixed-case” file-systems, where you can have two files differentiated by case, but if there’s no ambiguity, then one may address a file using any case: - echo lower-case > case-sensitivity-test - echo UPPER-CASE > CASE-SENSITIVITY-TEST - test x$(cat CASE-SENSITIVITY-TEST) = xUPPER-CASE -bjc
bug#55583: guix-daemon doesn't cleanly error-out on case-insensitive file systems.
Maxime Devos writes: Not sure how a case-insensitivity would cause this, but I think we can keep this open -- wouldn't it be better if "guix-daemon" just says ‘nope, case-sensitivity is required (*), not continuing)? (*) For reproducible builds, and apparently for substitution. The issue is wide-spread: there are a number of packages that will install files who’s names only vary by case. It’s also per-package; most work fine, but some will just break randomly. Some don’t seem to break until you try to use them, and then they yell and complain. This is something I run into often enough that it’s familiar to me and know how to fix, but not often enough to prevent my surprise when it happens. Guix can’t fix it, unfortunately. Maybe checking case sensitivity would be a worthwhile thing to do, just to warn people, but: I don’t know of a good way to check this in a file-system independent manner, and I honestly doubt it’s something that actually happens that often. I’ve been trucking a ZFS storage pool around since I first installed it on macOS about a decade ago, and since macOS is case-insensitive, that’s how it was installed (case sensitivity causes its own issues there). Short of running Guix on Windows or macOS, I don’t see this being a problem. -bjc
bug#55583: nar-error on pull
This bug was caused by having my Guix filesystem mounted on a case-insensitive file system. Re-running pull within the Docker container mounted on a case-sensitive file system works correctly. This bug can be closed. Sorry for the noise. -bjc
bug#55583: nar-error on pull
Maxime Devos writes:
The relevant store item name has been truncated, could you run
"echo /gnu/store/8v8y8rc4rwd*" in a shell and report the output?
⇒
/gnu/store/8v8y8rc4rwdwx5kbkfr1w1rl8g3dxsa3-guile-avahi-0.4.0-1.6d43caf.drv
In case it matters, here’s its contents:
--8<---cut here---start->8---
Derive([("out","/gnu/store/8ggx0372360592j1b0q0hd722m19yrvg-guile-avahi-0.4.0-1.6d43caf","","")],[("/gnu/store/08s1nz9bpv6k6a56idv6l7r2zjqphszl-file-5.39.drv",["out"]),("/gnu/store/1d8bi67rdpjisk3qy06mzg71g0zxj7ay-libgc-8.0.4.drv",["out"]),("/gnu/store/1x2g7ysm16xqnrpbkqdc4hhni1r42dgg-patch-2.7.6.drv",["out"]),("/gnu/store/3fy0f7gy85ddy6rpa4mmhjygns8qzk03-findutils-4.8.0.drv",["out"]),("/gnu/store/3xh80313ik5h410d9qn00w84ykck0ndh-ld-wrapper-0.drv",["out"]),("/gnu/store/45wsr6x878i3fyr12lf9v496cl9x5jh6-gzip-1.10.drv",["out"]),("/gnu/store/7fm542dl9f73pvw2n8y46mns9jqb0mai-glibc-2.33.drv",["out","static"]),("/gnu/store/812jrdyy4dvhy9j52bkjhj034ryysgnz-texinfo-6.7.drv",["out"]),("/gnu/store/8xf8nnfvvy13vhkygxwg49fwf8mqbk0d-libunistring-0.9.10.drv",["out"]),("/gnu/store/9iqh8mcqcssijac0i7hkbfp83fxcaxnk-pkg-config-0.29.2.drv",["out"]),("/gnu/store/ajk17vrxljb7x6h92pd590865wa4vj9p-gawk-5.1.0.drv",["out"]),("/gnu/store/bvv5bx3pj6s5b6ih10r7l9d18w8rzmkq-guile-3.0.7.drv",["out"]),("/gnu/store/csmcig21pcykhn1yg3ga6863s6b9k38c-gcc-10.3.0.drv",["out"]),("/gnu/store/fr7c3sylihc946096irz7s70m3hwcjav-xz-5.2.5.drv",["out"]),("/gnu/store/g73za4qfn4fffdqnqmywsh2ychjb92n2-linux-libre-headers-5.10.35.drv",["out"]),("/gnu/store/gkjk02msi4nwxh384md5c0w1db3rg71m-binutils-2.37.drv",["out"]),("/gnu/store/gmvmryrkvih05790hzzb0njj9q5xq4p5-glibc-utf8-locales-2.33.drv",["out"]),("/gnu/store/hxk4ckdlacwfwmnisjiimkc1vkglka32-autoconf-2.69.drv",["out"]),("/gnu/store/k5889v7ms3f5x1rjr3php71k4743fn19-bash-minimal-5.1.8.drv",["out"]),("/gnu/store/k77fsxpnpj5y16mnsxw7719lzgp4ks58-libtool-2.4.6.drv",["out"]),("/gnu/store/ldh1m27kvrwqgx5rmrc8j9xg3xmifx5n-avahi-0.8.drv",["out"]),("/gnu/store/mqyv8wj38m51wa9g3cb0p0qqsckx836j-grep-3.6.drv",["out"]),("/gnu/store/nd9ypg18kkh6bryfz458zym8xd4gaair-diffutils-3.8.drv",["out"]),("/gnu/store/ni7fpz4paf824s2nrhfcd5iqp0kbj4h1-m4-1.4.18.drv",["out"]),("/gnu/store/prwhkd8j57v07c0qlxxi708ccsh65vxp-bzip2-1.0.8.drv",["out"]),("/gnu/store/pv30dwfrly1h54dpdpck6wizma3x739x-guile-avahi-0.4.0-1.6d43caf-checkout.drv",["out"]),("/gnu/store/qpg6frs91vaajd5yjk9m46dlgn03sfi9-tar-1.34.drv",["out"]),("/gnu/store/rn11b92k2g90dhiwzgmazb5aqd426wg3-automake-1.16.3.drv",["out"]),("/gnu/store/vvkpaxrcic1dzmgpqb861jd8nix1n78j-module-import-compiled.drv",["out"]),("/gnu/store/xfm8z55ah263g4yvygqy7iph7vv5703v-guile-3.0.7.drv",["out"]),("/gnu/store/xk22lpxqh73rjaiaibsldmbrv6pxmcqm-make-4.3.drv",["out"]),("/gnu/store/xxyl6g6qclbwkfxinibrxd9ba48hgjff-coreutils-8.32.drv",["out"]),("/gnu/store/yb9zbq7d45cdx03z8q1j2w1ah2xqzd9p-sed-4.8.drv",["out"])],["/gnu/store/71jfcpb626wb4kpj4m5lsr68xm9ih50d-guile-avahi-0.4.0-1.6d43caf-builder","/gnu/store/dwvpffvh0cvm1v7j5bgmdh7j9mld1cx9-module-import"],"x86_64-linux","/gnu/store/1kws5vkl0glvpxg7arabsv6q9vazp0hx-guile-3.0.7/bin/guile",["--no-auto-compile","-L","/gnu/store/dwvpffvh0cvm1v7j5bgmdh7j9mld1cx9-module-import","-C","/gnu/store/0q6z17h9nfybhjgwgwwj81r3q9ik554x-module-import-compiled","/gnu/store/71jfcpb626wb4kpj4m5lsr68xm9ih50d-guile-avahi-0.4.0-1.6d43caf-builder"],[("out","/gnu/store/8ggx0372360592j1b0q0hd722m19yrvg-guile-avahi-0.4.0-1.6d43caf")])
--8<---cut here---end--->8---
-bjc
bug#55586: failure when linking glibc-mesboot-2.16.0
Got here trying to compile perl with: --8<---cut here---start->8--- % guix shell -D perl --no-substitutes --pure --8<---cut here---end--->8--- and failed here: --8<---cut here---start->8--- building /gnu/store/06gk3wm09xb40n4k8whkjrgg25wzvnqy-glibc-mesboot-2.16.0.drv... / 'build' phasebuilder for `/gnu/store/06gk3wm09xb40n4k8whkjrgg25wzvnqy-glibc-mesboot-2.16.0.drv' failed with exit code 1 build of /gnu/store/06gk3wm09xb40n4k8whkjrgg25wzvnqy-glibc-mesboot-2.16.0.drv failed View build log at '/var/log/guix/drvs/06/gk3wm09xb40n4k8whkjrgg25wzvnqy-glibc-mesboot-2.16.0.drv.gz'. --8<---cut here---end--->8--- Here’s where it fails in the log: --8<---cut here---start->8--- /gnu/store/vzv582cja3qghqwbx80flvpnmvs0zvb8-gcc-mesboot1-4.6.4/bin/gcc -I /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/nptl/sysdeps/pthread/bits -D BOOTSTRAP_GLIBC=1 -L /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0 -L /gnu/store/9z1axi21hd4hwwm4zd9dy52ii6xyk2mg-glibc-mesboot0-2.2.5/lib -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/gnu/store/x7cmgrizn7qbbi95mybcjbq98bbrr1nj-glibc-mesboot-2.16.0/lib/ld-linux.so.2 -B/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/csu/ -Wl,--version-script=/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/math -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/elf -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/dlfcn -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/nss -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/nis -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/rt -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/resolv -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/crypt -L/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/nptl -Wl,-rpath-link=/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/math:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/elf:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/dlfcn:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/nss:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/nis:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/rt:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/resolv:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/crypt:/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/nptl -o /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/libc.so -T /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/shlib.lds /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/csu/abi-note.o /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/elf/soinit.os /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/libc_pic.os /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/elf/sofini.os /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/elf/interp.os /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/elf/ld.so -lgcc /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/libc_pic.os: In function `compat_call': /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/grp/compat-initgroups.c:24: undefined reference to `__GI___nss_lookup_function' /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/grp/compat-initgroups.c:28: undefined reference to `__GI___nss_lookup_function' /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/grp/compat-initgroups.c:36: undefined reference to `__GI___nss_lookup_function' /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/libc_pic.os: In function `internal_getgrouplist': /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/grp/initgroups.c:62: undefined reference to `__nss_database_custom' /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/grp/initgroups.c:100: undefined reference to `__nss_group_database' /gnu/store/a51i0sf800fgs0pfwj7jg6qqjbgsv1r4-binutils-mesboot-2.20.1a/bin/ld: /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__nss_group_database' can not be used when making a shared object /gnu/store/a51i0sf800fgs0pfwj7jg6qqjbgsv1r4-binutils-mesboot-2.20.1a/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[2]: *** [/tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/build/libc.so] Error 1
bug#55583: nar-error on pull
I’m getting an error when trying to pull inside a docker
container:
--8<---cut here---start->8---
guix# guix pull
substitute: updating substitutes from
'https://ci.guix.gnu.org'... 100.0%
0.0 MB will be downloaded
le-certs-1 5KiB
552KiB/s 00:00 [##] 100.0%Updating channel 'guix'
from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to f0e9048 (92 new
commits)...
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git f0e9048
substitute: updating substitutes from
'https://ci.guix.gnu.org'... 100.0%
[…]
lz4-1.9.3 156KiB
libxft-2.3.3 45KiB
perl-5.34.0 15.1MiB
guix substitute: error: mkdir: File exists
Backtrace:
18 (primitive-load
"/gnu/store/p411j4q9hjk639rwcy1p3s6v89c9bxhr-comput
In ice-9/eval.scm:
155:9 17 (_ _)
159:9 16 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# (guile-u?> ?) ?) ?)
In ice-9/boot-9.scm:
152:2 15 (with-fluid* _ _ _)
152:2 14 (with-fluid* _ _ _)
In ./guix/store.scm:
2155:24 13 (run-with-store # 7fe9ea44c140> #
1983:8 12 (_ #)
In ./guix/gexp.scm:
300:22 11 (_ #)
1181:2 10 (_ #)
1047:2 9 (_ #)
893:4 8 (_ #)
In ./guix/store.scm:
2040:12 7 (_ #)
1395:13 6 (map/accumulate-builds # 7fe9df0440f0> # 1391:5 5 (map/accumulate-builds # 7fe9df0440f0> # 1406:15 4 (_ #
("/gnu/store/8v8y8rc4rwd
1406:15 3 (loop #f)
711:11 2 (process-stderr # 7fe9df0440f0> _)
In ./guix/serialization.scm:
102:11 1 (read-int #)
80:6 0 (get-bytevector-n* # 8)
./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
ERROR:
1. :
file: #f
port: #
guix pull: error: You found a bug: the program
'/gnu/store/p411j4q9hjk639rwcy1p3
failed to compute the derivation for Guix (version:
"f0e9048e98f0789aa98de88984f
host version: "1.3.0-27.598f728"; pull-version: 1).
Please report the COMPLETE output above by email to
.
--8<---cut here---end--->8---
The container was made from this manifest:
--8<---cut here---start->8---
(use-modules (gnu))
(use-package-modules shells)
(operating-system
(host-name "guix")
(timezone "America/New_York")
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(targets '("/dev/vda"
(file-systems (list
(file-system
(mount-point "/")
(device "/dev/vda1")
(type "ext4"
(packages (append (map specification->package
'("zsh"))
%base-packages))
(users (cons* (user-account
(name "bjc")
(group "users")
(comment "brian")
(shell (file-append zsh "/bin/zsh"))
(home-directory "/home/bjc")
(supplementary-groups
'("wheel" "netdev" "audio" "video")))
%base-user-accounts)))
--8<---cut here---end--->8---
With this command:
--8<---cut here---start->8---
$ guix system image -t docker minimal-sysconf.scm
--8<---cut here---end--->8---
-bjc
