bug#70663: nss@3.99 is really hard to build
Maxim Cournoyer writes: Hi Mark, Mark H Weaver writes: Hi Maxim, Maxim Cournoyer writes: Christopher Baines writes: [...] At least from what I can see on the issues, the problem was introduced with the update to 3.98.0 [3] and then continued with the update to 3.99 [4]. Given the changes in 70662 were sent to guix-patches and then merged less than 24 hours later, I'd imagine that wasn't sufficient time for data.qa.guix.gnu.org to fail attempting to build nss. I think in [3] you meant https://issues.guix.gnu.org/70569, not #70662. Since this was security sensitive, I built it on x86_64, tested it there to ensure that IceCat worked as expected, had others confirmed it worked for them on #guix then pushed. [...] 3: https://issues.guix.gnu.org/70662 4: https://issues.guix.gnu.org/70618 Note that the IceCat package in Guix currently uses the copy of NSS that comes bundled with the IceCat source code, so testing IceCat probably won't tell you much about whether the standalone NSS package in Guix works properly. Thanks for the heads-up. It looks like there are now some low hanging fruits in terms of unbundling opportunities for icecat/Icedove! Definitely. The LibreWolf package is probably a good reference, as I was able to unbundle all its library dependencies and use the Guix-packaged versions instead. — Ian
bug#69680: clj (clojure-tools) fails with :deps alias
Looks like the issue is a ${project.version} sitting in a deps.edn
in the resources of the JAR.
I have a patch that seems to solve this, but it’s ludicrous due to
clojure-build-system being buggy. Also, tools.deps.alpha has been
deprecated for two years and really shouldn’t be in Guix at all.
I’ve done some work on getting Clojure stuff in Guix into better
shape, but it’s not ready yet.
Patch incoming shortly.
— Ian
bug#69182: home-xmodmap-service-type requires restart to work
I recently set up home-xmodmap-service-type so I could change the
PrtSc key on my ThinkPad into a Hyper modifier. This is my
configuration:
(service home-xmodmap-service-type
(home-xmodmap-configuration
(key-map '("clear mod3"
("remove mod4" . "Hyper_L")
("keycode 107" . "Hyper_R")
("add mod3" . "Hyper_L Hyper_R")
However, after logging into an EXWM session, the PrtSc key is a
Super modifier, not Hyper. The service appears to be starting
successfully:
l0p!ieure~$ herd status xmodmap
Status of xmodmap:
It is running since 11:20:59 AM (35 seconds ago).
Running value is #t.
It is enabled.
Provides (xmodmap).
Requires ().
Will be respawned.
The output of `xmodmap -pm' reports:
xmodmap: up to 4 keys per modifier, (keycodes in
parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock
control Control_L (0x25), Control_L (0x42), Control_R
(0x69)
mod1Alt_L (0x40), Alt_R (0x6c), Alt_L (0xcc),
Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3ISO_Level5_Shift (0xcb)
mod4Super_L (0x85), Super_R (0x86), Super_L (0xce),
Hyper_L (0xcf)
mod5ISO_Level3_Shift (0x5c)
Some of my configuration is applied, while other parts are not:
- "clear mod3" isn’t working; mod3 is ISO_Level5_Shift, which is
the default.
- "remove mod4 = Hyper_L" isn’t working. Hyper_L is still on mod4
(which is the super modifier), which is the default.
- "add mod3 = Hyper_L Hyper_R" isn’t working.
- The "keycode 107 = Hyper_R" config *is* working, which is what
makes PrtSc a super modifier.
If I restart the service, the modifiers work as expected:
l0p!ieure~$ herd restart xmodmap
Service xmodmap has been started.
l0p!ieure~$ guix shell xmodmap -- xmodmap -pm
xmodmap: up to 4 keys per modifier, (keycodes in
parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock
control Control_L (0x25), Control_L (0x42), Control_R
(0x69)
mod1Alt_L (0x40), Alt_R (0x6c), Alt_L (0xcc),
Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3Hyper_R (0x6b), Hyper_L (0xcf)
mod4Super_L (0x85), Super_R (0x86), Super_L (0xce)
mod5ISO_Level3_Shift (0x5c)
I haven’t set up anything else that manipulates keymaps, so I’m
not sure why this isn’t working after login.
I had a suspicion that another service might be running after
xmodmap and changing the keymap. The only home service that looks
like it might do that is x11-display. However, copying
`home-xmodmap-service-type' and `my-xmodmap-shepherd-service' into
my home.scm and editing it to add (requirement '(x11-display)) to
the shepherd-service doesn’t fix the issue.
This appears to be a timing problem. If I remove the service from
my home configuration, but manually run `guix shell xmodmap --
xmodmap /gnu/store/g3hgzx8za4qrrdgn5hjqd80gxkb6sifx-config' after
I log in (the file being the xmodmap configuration created by
`serialize-xmodmap-configuration'), the keymap is set up how I
declare it. So *what* home-xmodmap-service-type does is correct;
but *when* it does it is not.
bug#67290: (current-profile) only works when invoked as a process named "guix"
Simon Tournier writes: Hi, On Sun, 19 Nov 2023 at 13:24, Ian Eure wrote: The issue seems to be that current-profile checks the name of the program which was invoked, and always returns #f unless the name ends with "bin/guix". Since "guile" doesn’t, they don’t work as expected. See: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/describe.scm#n64 About current-profile, maybe this patch: [2. p.patch --- text/x-diff; p.patch] diff --git a/guix/describe.scm b/guix/describe.scm index 65cd79094b..4147d5db1f 100644 --- a/guix/describe.scm +++ b/guix/describe.scm @@ -61,14 +61,18 @@ (define current-profile or #f if this is not applicable." (match initial-program-arguments ((program . _) - (and (string-suffix? "/bin/guix" program) -;; Note: We want to do _lexical dot-dot resolution_. Using ".." -;; for real would instead take us into the /gnu/store directory -;; that ~/.config/guix/current/bin points to, whereas we want to -;; obtain ~/.config/guix/current. -(let ((candidate (dirname (dirname program - (and (file-exists? (string-append candidate "/manifest")) - candidate))) + (or (and (string-suffix? "/bin/guix" program) +;; Note: We want to do _lexical dot-dot resolution_. Using ".." +;; for real would instead take us into the /gnu/store directory +;; that ~/.config/guix/current/bin points to, whereas we want to +;; obtain ~/.config/guix/current. +(let ((candidate (dirname (dirname program + (and (file-exists? (string-append candidate "/manifest")) + candidate))) + (let ((current (string-append + (config-directory #:ensure? #f) "/current/manifest"))) + (and (file-exists? current) + current))) (define (current-profile-date) "Return the creation date of the current profile (produced by 'guix pull'), ? Well, I do not know exactly if fixing your issue does not introduce regression. The patch looks good to me, but this is all stuff I’m not very familiar with. About emacs-guix, instead of launching Guile, why not start “guix repl” instead? The command “guix repl” had been improved – and maybe even introduced after the release of emacs-guix. Somehow, I am not very happy with the current integration between Geiser and Guix. :-) I’m not sure why it works the way it does, or whether it could be changed to invoke `guix repl'. I don’t think it’s expected for library code behavior to change depending on the runtime context, so I believe fixing Guix is the right solution. Perhaps the concerns around resolving relative paths belongs somewhere more proximate to where that’s an issue? I definitely don’t understand everything happening in this code, but it strikes me as a concern relevant to some operations executed from the CLI. If that’s the case, putting it in the CLI tooling where special handling is needed would make sense to me. — Ian
bug#67314: xorg-configuration's extra-config should support file-like objects
I needed to tweak some xorg settings (set scroll direction, enable
tearfree, etc). On other distros, this is done by dropping files
of
config snippets into /etc/xorg.conf.d.
On Guix, this needs to be done through the extra-config field of
the
xorg-configuration record. That field requires a list of strings,
which
means the configurations need to be inlined into the config, which
is
verbose and unsightly.
For example:
(operating-system
(services
(append (list (service openssh-service-type)
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(extra-config
(list
"Section \"InputClass\"
Identifier \"Touchpads\"
MatchIsTouchpad \"on\"
Driver \"libinput\"
Option \"ClickMethod\" \"clickfinger\"
Option \"DisableWhileTyping\" \"on\"
Option \"NaturalScrolling\" \"on\"
Option \"Tapping\" \"off\"
EndSection"
The manual states that extra-config takes "a list of strings or
objects," but doesn’t indicate what type of object is expected.
If I
pass a file-like object, like this:
(operating-system
(services
(append (list (service openssh-service-type)
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(extra-config
(list (local-file
"xorg/touchpads.conf")
The resulting Xorg configutation has the store paths for those
files
added to it, instead of their contents. This is an invalid
configuation, rendering Xorg unable to start.
I was able to split the difference by reading the file contents
into the
config, ala:
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(extra-config
(map (lambda (file)
(call-with-port (open-file (string-append "xorg/"
file ".conf") "r") get-string-all))
'("radeon" "elecom-huge" "trackpad")
But this feels like a graceless hack to me.
The situation would be drastically simplified if extra-config
supported
file-like objects.
bug#67290: (current-profile) only works when invoked as a process named "guix"
When you invoke `guix repl', the current-profile and current-channels procedures reflect my current profile and channel configuration: l0p!ieure~$ guix repl GNU Guile 3.0.9 Copyright (C) 1995-2023 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guix-user)> ,m (guix describe) scheme@(guix describe)> (current-profile) $1 = "/home/ieure/.config/guix/current" scheme@(guix describe)> (length (current-channels)) $2 = 3 scheme@(guix describe)> If you run `guile', they do not: l0p!ieure~$ guile GNU Guile 3.0.9 Copyright (C) 1995-2023 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> ,m (guix describe) scheme@(guix describe)> (current-profile) $1 = #f scheme@(guix describe)> (length (current-channels)) $2 = 1 scheme@(guix describe)> The issue seems to be that current-profile checks the name of the program which was invoked, and always returns #f unless the name ends with "bin/guix". Since "guile" doesn’t, they don’t work as expected. See: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/describe.scm#n64 I discovered this when I was using emacs-guix to debug one of my package definitions, which inherits from a package in a non-default channel. While I can load the .scm file into Geiser no matter what channels are configured, it can’t use the module containing the package definition it inherits from. This also appears to be the root cause behind this three-year-old bug report for emacs-guix: https://gitlab.com/emacs-guix/emacs-guix/-/issues/17 I’m not sure what the rationale is for this behavior, so I don’t have a suggestion for a fix, but it’s definitely a bug. Thanks, — Ian
bug#59846: "Running Guix in a Virtual Machine" documentation unclear/incomplete/wrong
I’m trying to explore Guix System by running it in a VM on my computer which runs Debian. I’m interested in some of the Guix ideas, but not ready to do a bare-metal install. I found the download page[1] and got a copy of the QEMU image, then clicked "Installation instructions"[2]. These instructions didn’t work, because they’re incomplete and/or unclear and/or wrong and/or not really installation instructions in the way one might assume. Since I don’t really know anything about Guix (which is why I’m reading the documentation and test driving it in a VM), I’m not sure which one-or-more of these it may be. Specifically: To enable SSH inside a VM you need to add an SSH server like openssh-service-type to your VM (see openssh-service-type). The documentation doesn’t say *how* to do that. The openssh-service-type link[3] takes me to a large page of code documentation for every possible networking service, instead of the openssh-service-type one specifically. This documentation describes *what* the service type and its many configuration options is, but is silent on *how* to make use of it. It continues: In addition you need to forward the SSH port, 22 by default, to the host. You can do this with $(guix system vm config.scm) -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 I’m really not sure what this is supposed to be doing. It can’t run on my Debian host, since there’s no guix command. It errors inside the VM, since it can’t find a config.scm file; and I don’t see an obvious config.scm file anywhere inside the VM that it might be looking for. I *suspect* that this documentation is actually targeted at running a Guix System VM on an existing Guix host. Which is a chicken-and-egg problem, if I’ve already installed Guix, I don’t need to follow instructions to install it. [1]: https://guix.gnu.org/en/download/ [2]: https://guix.gnu.org/manual/en/html_node/Running-Guix-in-a-VM.html [3]: https://guix.gnu.org/manual/en/html_node/Networking-Services.html
