bug#54415: backticks represented as single quotes in guix pdf manual
When working through the manual
(https://guix.gnu.org/en/manual/devel/en/guix.pdf), specifically Chapter 10,
the openssh-service-type example has a single quote (') instead of backtick
(`). It appears backticks are represented as single quotes elsewhere as well.
atka
bug#54407: Issues building grub for powerpc64le, could not force big-endian
grub can't be built for powerpc64le, I believe the same failure occurs with native builds or cross compilation from x86_64. I think this might have always been the case. This is the error from the build log: checking for options to get big-endian compilation... no configure: error: could not force big-endian Looking in the config.log file, it tries a bunch of options with different errors, but this one stands out: cc1: error: '-m32' not supported in this configuration I know very little about gcc, but I think this might relate to the multilib thing, which I'm guessing is disabled for the gcc in use here. Any ideas about this issue? Thanks, Chris signature.asc Description: PGP signature
bug#54400: Emacs error in Ubuntu
Greetings, I follow the instructions from: [ https://zimbra.inria.fr/zimbra/%20https://guix.gnu.org/manual/en/guix.html#Binary-Installation | https://guix.gnu.org/manual/en/guix.html#Binary-Installation ] Installation (Ubuntu 20.04): cd /tmp wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh chmod +x guix-install.sh ./guix-install.sh guix install glibc-utf8-locales export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" Update: guix pull Install emacs: guix install emacs Load environment: GUIX_PROFILE="$HOME/.guix-profile" . "$GUIX_PROFILE/etc/profile" Run emacs: emacs /home/vmataixf/.guix-profile/bin/emacs: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or director Best regards, Vicente Mataix Ferrándiz
bug#54397: Packages CI link
Hi, At https://guix.gnu.org/en/packages/ the "continuous integration system" link to https://ci.guix.gnu.org/jobset/guix-master looks like it should instead reference the "master" jobset. The "available as pre-built binaries" link references the same, though this could point instead to documentation (perhaps https://guix.gnu.org/manual/en/html_node/Substitutes.html). Greg
bug#54398: Adding network-manager-openvpn requires a full reboot
Maxim Cournoyer schreef op di 15-03-2022 om 11:24 [-0400]:
> 1. Add the 'network-manager-openvpn' plugin to your
> 'network-manager-configuration', like so:
>
> --8<---cut here---start->8---
> (modify-services %desktop-services
> [...]
> (network-manager-service-type config =>
> (network-manager-configuration
> (inherit config)
> (vpn-plugins (list network-manager-openvpn
> --8<---cut here---end--->8---
Looking at 'network-manager-environment'
(define network-manager-environment
(match-lambda
(($ network-manager dns vpn-
plugins)
;; Define this variable in the global environment such that
;; "nmcli connection import type openvpn file foo.ovpn" works.
`(("NM_VPN_PLUGIN_DIR"
. ,(file-append (vpn-plugin-directory vpn-plugins)
"/lib/NetworkManager/VPN")),
I expect a potential issue to be that NM_VPN_PLUGIN_DIR is a
/gnu/store/... file name and hence the plugins in there are
not adjusted by a reconfiguration. Maybe it could instead
refer to somewhere in /run/current-system/...?
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
bug#54350: Profile collisions are ignored, installing multiple versions of the same package is silently broken
Ludovic Courtès schreef op di 15-03-2022 om 14:50 [+0100]: > $ ./pre-inst-env guix shell -D guile -n > guix shell: error: profile contains conflicting entries for bash-minimal > guix shell: error: first entry: bash-minimal@5.1.8 > /gnu/store/chfwin3a4qp1znnpsjbmydr2jbzk0d6y-bash-minimal-5.1.8 > guix shell: error: second entry: bash-minimal@5.1.8 > /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8 > hint: You cannot have two different versions or variants of `bash-minimal' in > the same profile. > --8<---cut here---end--->8--- > > These collisions are harmless but frequent in package development > environments, which is why ‘guix environment’ had to turn off those > checks (commit afd06f605bf88a796acefc7ed598b43879346a6b). > > That’s a bit of a hack though. These collisions happen because the bag of a package contains of multiple variants of bash: the default canonical bash-minimal, from (gnu packages commencement), not directly visible (i.e., with "guix show" and 'specification->package'), which is overidden by the bash-minimal from native-inputs, which is visible from specification->package and as a public variable, and as I understand it, the bash-minimal supposed to end up in the references of non-bootstrap packages. For these kind of collisions, I think the non-canonical package (that's actually visible with "guix show FOO") is preferred here, so perhaps the canonical variants can be filtered out whenever that would resolve a collision? That seems also a bit of a hack though. > What we could do, as a mitigation, is to enable collision checks > unless there’s at least one ‘-D’ flag. We’d also need to introduce > ‘--allow-collisions’ for ‘guix shell’. Special-casing -D like this also seems like a hack to me. I'm not sure which hack is better, though I prefer this one and the ‘filter out canonical packages’ above the original ‘just disable collision checking’. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
bug#54398: Adding network-manager-openvpn requires a full reboot
Hello Guix, I've been bitten by this before, and again this morning, so I'm reporting this behavior as a bug. The struggle looks a bit like this: 1. Add the 'network-manager-openvpn' plugin to your 'network-manager-configuration', like so: --8<---cut here---start->8--- (modify-services %desktop-services [...] (network-manager-service-type config => (network-manager-configuration (inherit config) (vpn-plugins (list network-manager-openvpn --8<---cut here---end--->8--- 2. 'guix system reconfigure' your system with the change 3. Try configuring/importing an OpenVPN connection; it fails because the plugin hasn't yet been made available. 4. Restart the networking service and relogin. 5. Now it seems to be functional, but the connection fails to be established, with a timeout error. 6. Reboot the machine. 7. Try again: it now works. Thanks, Maxim
bug#54278: Bug report
Hi Oliver, Oliver König skribis: > curl-7.79.1 377KiB > 1.1MiB/s 00:00 [##] 100.0% > gnutls-3.7.2-debug 4.4MiB > 10.0MiB/s 00:00 [##] 100.0% > git-minimal-2.34.0 4.1MiB > 8.6MiB/s 00:00 [### ] 43.0%guix pull: error: You found a bug: > the program > '/gnu/store/b00zax7hsd0mz1088qmrz8a1dnw25pka-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "e7886fd6746267e26cf11628f96d8082680b496f"; system: "x86_64-linux"; > host version: "1.3.0"; pull-version: 1). It looks as though the download of ‘git-minimal’ was interrupted, leading to that failure. That could be a transient networking failure. Does it work if you retry? Thanks for reporting the issue, Ludo’.
bug#39542: Adding openvpn client configurations to guix system
Hi, Damien Cassou writes: > Hi David, > > david larsson writes: >> I think I have a solution for you, where you can start 3 different vpn's >> with herd start vpn1-client, herd start vpn2-client etc. > > thank you very much. I've decided I would go for NixOS though. OK, thanks for letting us know. As this was a feature request rather than a bug report, I'm closing the issue. Thank you, Maxim
bug#54234: Dropping versioned docdir for license files?
Hi, Maxim Cournoyer skribis: > Recently while packaging sysbench, I noticed that the gnu-build-system's > docdir expands to 'share/doc/name', while the 'install-license-files' > phase installs the license files to 'share/doc/name-version' instead: [...] > It seems to me it'd be nicer to have both agree on the same docdir. We > could drop the version and use gnu-build-system's docdir, or alter the > default gnu-build-system docdir to use a versioned output. The later > some more troublesome, as we'd have to do the same adjustment for each > build system, and I'm not convinced of the value added. So I'd suggest > we simply normalize to use the standard docdir. Fine with me! We can do that in ‘core-updates’. Ludo’.
bug#54234: Different license file name
Hi, Maxime Devos skribis: > Some software does not work with a COPYING or LICENSE file, or they do > but also have other relevant licenses. E.g., gnunet-scheme follows > REUSE and puts the license texts in a LICENSES directory and some extra > information in '.reuse/dep5'. It would be nice if those were copied > as well. You can use the #:license-file-regexp argument of ‘gnu-build-system’ in such a case. If the file name becomes common, we can update the default ‘%license-file-regexp’ in ‘core-updates’. HTH, Ludo’.
bug#54350: Profile collisions are ignored, installing multiple versions of the same package is silently broken
Hi, Maxime Devos skribis: > $ guix shell --pure bash pango@1.42 pango@1.48 > $ ~/.guix-profile/bin/ls -l $GUIX_ENVIRONMENT/lib/libpango*.so > > Result: > [...]/lib/libpango-1.0.so -> [...]-pango-1.42.4/lib/libpango-1.0.so > [...]/lib/libpangocairo-1.0.so -> [...]-pango-1.42.4/lib/libpangocairo-1.0.so > [...]/lib/libpangoft2-1.0.so -> [...]-1.42.4/lib/libpangoft2-1.0.so > [...]/lib/libpangoxft-1.0.so -> [...]-pango-1.42.4/lib/libpangoxft-1.0.so > > Question: how does this even work? Aren't error messages about profile > collisions a thing? Unlike ‘guix package’, ‘guix environment/shell’ explicitly disables collision checks—see #:allow-collisions? in environment.scm. The rationale back then was that if you do: guix shell -D guile then you likely end up with profile collisions, like so (I modified the code to do #:allow-collisions? #f): --8<---cut here---start->8--- $ ./pre-inst-env guix shell -D guile -n guix shell: error: profile contains conflicting entries for bash-minimal guix shell: error: first entry: bash-minimal@5.1.8 /gnu/store/chfwin3a4qp1znnpsjbmydr2jbzk0d6y-bash-minimal-5.1.8 guix shell: error: second entry: bash-minimal@5.1.8 /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8 hint: You cannot have two different versions or variants of `bash-minimal' in the same profile. --8<---cut here---end--->8--- These collisions are harmless but frequent in package development environments, which is why ‘guix environment’ had to turn off those checks (commit afd06f605bf88a796acefc7ed598b43879346a6b). That’s a bit of a hack though. What we could do, as a mitigation, is to enable collision checks unless there’s at least one ‘-D’ flag. We’d also need to introduce ‘--allow-collisions’ for ‘guix shell’. WDYT? Thanks, Ludo’.
bug#54348: Guile 3.0.7 fails to build on armhf-linux
Hi,
Ludovic Courtès skribis:
> Guile 3.0.7 appears to fail tests reproducibly on armhf-linux:
>
> Running vm.test
> Running weaks.test
> Running web-client.test
> Running web-http.test
> Running web-request.test
> Running web-response.test
> Running web-server.test
> ERROR: web-server.test: GET / - arguments: ((system-error "connect" "~A"
> ("Connection refused") (111)))
> ERROR: web-server.test: GET /latin1 - arguments: ((system-error "connect"
> "~A" ("Connection refused") (111)))
> ERROR: web-server.test: GET /user-agent - arguments: ((system-error "connect"
> "~A" ("Connection refused") (111)))
> ERROR: web-server.test: GET /does-not-exist - arguments: ((system-error
> "connect" "~A" ("Connection refused") (111)))
> ERROR: web-server.test: GET with keep-alive - arguments: ((system-error
> "connect" "~A" ("Connection refused") (111)))
> ERROR: web-server.test: POST / - arguments: ((system-error "connect" "~A"
> ("Connection refused") (111)))
Well, as it turns out it’s not 100% reproducible after all. Probably a
timing issue. I was unable to reproduce it on overdrive1.guix anyway,
so now ci.guix has substitutes for (@@ (gnu packages commencement)
guile-final) for armhf-linux.
Looking at ‘web-server.test’, there’s no synchronization between HTTP
server startup and the first test; thus, there’s a possibility that the
HTTP server is not listening yet by the time the main thread attempts to
connect to the server. Fixed upstream:
https://git.savannah.gnu.org/cgit/guile.git/commit/?id=f18f67022314eefced887df0a470a440f70f592c
Ludo’.
bug#54385: xscreensaver seems to be missing xscreensaver-demo
xscreensaver-demo makes it sound fairly unimportant, but -demo is how you launch the configuration GUI and select screensavers, turn on settings like when to lock, etc. For example, in XFCE, I went to click on the menus to select "screensaver" and it said xscreensaver-demo was missing. I imagine this could be confusing. It confused me. Looks like we're not the only ones hitting this issue: https://bugs.gentoo.org/753905 Tobias Geerinckx-Rice writes: > Hi Christine, > > Note that the name of this tool has changed upstream[0], but we're > still on an older version for now. Building it: > > Warning: GTK version 2.24.33 was found, but at least one supporting > library (gdk-pixbuf-xlib-2.0) was not, so GTK can't be > used. > Perhaps some of the development packages are not installed? > > Warning: The GTK libraries do not seem to be available; the > `xscreensaver-demo' program requires them. > > Where gdk-pixbuf-xlib is of course ‘a deprecated library’ and ‘[n]o > newly written code should ever use this library’ so that'll be fun to > maintain the coming years. > > Our gdk-pixbuf package still mentions gdk-pixbuf-xlib-2.0.pc in an > obsolete comment but doesn't actually install it. > > Oh: > > NEWS: - Split the gdk-pixbuf-xlib library to a separate repository > > The repository is archived and read-only: > > https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib > > Oh that is going to be *super* fun to maintain. > > At this point I'd usually go ahead and package the beast, but I don't > use xscreensaver. How important is this binary? (-demo sounds > unimportant, -settings very, but it's presumably the same thing.) > > In any case an update to xscreensaver would seem prudent first. > > Kind regards, > > T G-R > > Sent from a Web browser. Excuse or enjoy my brevity. > > [0]: https://www.jwz.org/xscreensaver/changelog.html
bug#54370: network problem or intentional blocking?
Hi Maxime, Maxime Devos skribis: > For the website, publishing the website not only over HTTP/S but also > over IPFS might help? The website is static and Guix has an IPFS > service, so it should be feasible I think. The browser extension > (https://docs.ipfs.io/install/ipfs-companion/) would need to be > packaged though, and a DNS link record > (https://docs.ipfs.io/concepts/dnslink/#resolve-dnslink-name) would > need to be set up. That and/or publishing as an onion service would be great. Ludo’.
