bug#53381: wireguard service can fail on boot by starting before DNS is ready
As shown here on boot: [#] ip link add test type wireguard [#] wg setconf test /dev/fd/63 Name or service not known: `:51820' Configuration parsing error [#] ip link delete dev test failed to start service 'wireguard-test' This can cause remote machines to become inaccessible. Is there an equivalent of systemd-networkd-wait-online.service? Or perhaps you would accept a patch to enable the "respawn?" service method, so wireguard will eventually connect once DNS is ready?
bug#53369: guix pull command fails on a torified bash shell
When I run `guix pull` command the following error is generated: In procedure scm_lreadr: #:16:144: Unknown # object: #\< Further invocations to `guix ` produces Segmentation fault. However, the following command still works: `/run/current-system/profile/bin/guix `
bug#53250: (No Subject)
Hi Jonathan, Thanks for testing the patch. What exactly doesn't work? Is icedove still generating new profiles upon install? Even if it stops generating profiles, you still need to use `icedove -p` to select the correct default. Kind regards, Nicholas
bug#53147: Hunspell dictionaries unavailable in LibreOffice
Ludovic Courtès skribis:
> When running something like:
>
>guix shell hunspell hunspell-dict-fr libreoffice -- libreoffice
>
> Hunspell dictionaries (for French in this case) are unavailable from the
> spell-checking menu, even though DICPATH is set (this is with
> 92faad0adb93b8349bfd7c67911d3d95f0505eb2).
Another data point: Hunspell itself does find the dictionaries:
--8<---cut here---start->8---
$ guix shell -C hunspell-dict-{de,fr,pl} hunspell -- hunspell -D
SEARCH PATH:
.::/gnu/store/nkzscw3rb7ypm4a1f6ljx8lvpkssv8va-profile/share/hunspell:/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/ludo/.openoffice.org/3/user/wordbook:/home/ludo/.openoffice.org2/user/wordbook:/home/ludo/.openoffice.org2.0/user/wordbook:/home/ludo/Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
/gnu/store/nkzscw3rb7ypm4a1f6ljx8lvpkssv8va-profile/share/hunspell/pl_PL
/gnu/store/nkzscw3rb7ypm4a1f6ljx8lvpkssv8va-profile/share/hunspell/fr-classique
/gnu/store/nkzscw3rb7ypm4a1f6ljx8lvpkssv8va-profile/share/hunspell/de_DE
--8<---cut here---end--->8---
Stracing ‘soffice’ shows that it searches the ‘share/hunspell’
directories too. Now to find why it’s not doing anything with them.
Ludo’.
bug#53267: Profile changes after ‘guix upgrade --dry-run’
Hi, Tirifto skribis: > I have done another upgrade since, but I just made sure the problem > persists even there, or at least this is what happened… > > $ guix package --rollback > switched from generation 21 to 20 > > $ guix upgrade --dry-run > The following packages would be upgraded: > gimp (dependencies or package changed) > ungoogled-chromium (dependencies or package changed) > youtube-dl (dependencies or package changed) > > $ guix package --rollback > switched from generation 21 to 20 > > …so I’m attaching the diff between generations 20 and 21 instead, with > no other changes to your command. Please find it in the file > ‘guix-profile-diff.txt’, unless it got renamed along the way. That was an interesting corner case, fixed in ccda88a07039c62d5d0bfde7fccef02ef3937ccf. Thanks! Ludo’.
bug#53250: icedove clears user data on upgrade
I tested your patch, Nicholas, and the one I sent in. But sadly non of them resolved the problem for me :( Maybe we should add a service or something to start icedove always with `icedove -P YOUR-PROFILE-NAME`. As a "dirty" hack...
bug#53250: [PATCH] gnu: icedove: Stop per-install profile generation.
From: Nicholas von Klitzing
Fixes https://issues.guix.gnu.org/53250
* gnu/packages/gnuzilla.scm (icedove)[arguments]: Disable MOZ_NORMANDY.
Signed-off-by: Jonathan Brielmaier
---
gnu/packages/gnuzilla.scm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index a9b5ed9fe9..929e43d71d 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -1372,7 +1372,9 @@ (define-public icedove
(lambda _
(substitute* "comm/mail/moz.configure"
(("MOZ_DEDICATED_PROFILES, True")
-"MOZ_DEDICATED_PROFILES, False"))
+ "MOZ_DEDICATED_PROFILES, False")
+ (("MOZ_NORMANDY, True")
+"MOZ_NORMANDY, False"))
#t))
(add-after 'prepare-thunderbird-sources 'rename-to-icedove
(lambda _
--
2.34.0
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
On 2022-01-17, Vagrant Cascadian wrote: > On 2022-01-17, Pierre Langlois wrote: >> Chris Marusich writes: >>> Chris Marusich writes: > If nobody has further comments, I will commit the attached version to master in about 24 hours. >>> >>> I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We >>> still need to update the "guix" package, so even if you run "guix pull" >>> right now, you won't be able to successfully build "guix" after pulling >>> on aarch64-linux yet. >>> >>> I will coordinate with the other people who are helping to make the >>> 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. >>> See this guix-devel email thread for details: >>> >>> https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html >> >> That's awesome, thank you! > > FWIW, I can also confirm that updating the "guix" package to a version > that contains 24c3485bb3ffc05e687ef6513ac287b8d3048bab allows the "guix" > package (which contains the fairly important "guix-daemon"), to build > again. Thanks for getting it that far! > > Haven't been able to upgrade my aarch64 systems without local patches > for over a month now... glad to see a fix is *almost* ready! > > Is there anything in particular holding back upating the guix package > (other than the huge amount of big merges in progress, release > preparation, etc. and etc.)? I went ahead and pushed to master: f758ede583ef9662963873750206540f58ff3c45 gnu: guix: update to 1.3.0-22.24c3485. I tried building a newer version, but there were new test suite failures on both aarch64 and x86_64 :/ Happy aarch64ing! live well, vagrant signature.asc Description: PGP signature
bug#53289: [PATCH] gnu: Remove Qt WebKit.
Leo Famulari skribis: > New failures: > [...] > freecad For freecad, the qtwebkit input can be replaced by qtdeclarative, qtwebchannel and qtwebengine. signature.asc Description: PGP signature
bug#53368: Patch
Here's a quick patch I threw together for the documentation.
--
Christopher Rodriguez
From 632435ee888e9c5fc6b1b65811d43e7343e7e172 Mon Sep 17 00:00:00 2001
From: Christopher Rodriguez
Date: Wed, 19 Jan 2022 10:00:23 -0500
Subject: [PATCH] Modified '.guix-authorizations' section to clearly define
version field.
---
doc/guix.texi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index 28eaf8338c..a071754c54 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -5421,7 +5421,7 @@ for Computer Scientists}} for a great overview.} The
;; Example '.guix-authorizations' file.
(authorizations
- (version 0) ;current file format version
+ (version 0) ;current API version
(("AD17 A21E F8AE D8F1 CC02 DBD9 F8AE D8F1 765C 61E3"
(name "alice"))
@@ -5432,7 +5432,9 @@ for Computer Scientists}} for a great overview.} The
@end lisp
Each fingerprint is followed by optional key/value pairs, as in the
-example above. Currently these key/value pairs are ignored.
+example above. Currently these key/value pairs are ignored, but this
+may change in the future. The @code{version} field specifies the version
+of the @code{authorizations} API the file was written for.
This authentication rule creates a chicken-and-egg issue: how do we
authenticate the first commit? Related to that: how do we deal with
--
2.34.0
OpenPGP_0x1102102EBE7C3AE4.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
bug#52987: h-client: build failure: sanity check
h-client is building now without error, using `guix time-machine -- build h-client`.
bug#53368: .guix-authorizations 'version' field documentation
Hey all, I've just been able to clone my authenticated personal repository for the first time in a few weeks because I was confusing the `version` field of `(authorizations …` to be a file version field as opposed to the version of the API being used. For clarity, I'm working on a patch that will edit the section of the manual to clearly specify that this is the API version (will submit soon). It currently has a comment in the example source that reads "current file format version", which lead me to this mistake. Nowhere else in the text is the `version` field mentioned. However, as a Lisper, I feel as though the symbol itself could easily be more descriptive by using `api-version` or something similar rather than just a generic `version`. It would help prevent other newcomers from going through the confusion I've just had. What do You think? -- Christopher Rodriguez OpenPGP_0x1102102EBE7C3AE4.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#53183: python-xdo: Fails to build (failing sanity check)
Hi Ivan, > Hi! When trying to upgrade package `python-xdo 0.3` from Guix commit > `404f6953` to that of commit `4a943cfd`, the build fails with this error: I fixed this error with commit 71421529d8521eb48c707ed5cdb7ea7a75e52663. Cheers, Lars
bug#52987: h-client: build failure: sanity check
Hi Christopher, > Package h-client fails to build with an error during sanity-check phase: is this still an issue? I cannot reproduce it on commit 873b2eca94cb5da13602abe651c6707fe99ff14b with `guix build h-client`. Cheers, Lars
bug#53289: [PATCH] gnu: Remove Qt WebKit.
Leo Famulari skribis: > I applied the patch and tried building all packages that are changed by > the it. > > New failures: > qgis > [...] For qgis, adding "-DWITH_QTWEBKIT=NO" to 'configure-flags' should work, but I don't know what features would then be unavailable in the application. signature.asc Description: PGP signature
bug#53344: Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed!
Hi, "Dr. Arne Babenhauserheide" skribis: > Ludovic Courtès writes: > >> "Dr. Arne Babenhauserheide" skribis: >> >>> when I call guix, I get the error >>> >>> Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: >>> _dl_call_libc_early_init: Assertion `sym != NULL' failed! >>> >>> `which guix` gives >>> >>> /home/USER/.config/guix/current/bin/guix >> >> When did it start happening? > > It started happening a few weeks ago. > > I found the cause now, though: I had > > LD_LIBRARY_PATH=$HOME/.guix-profile/lib:$LD_LIBRARY_PATH > > in my .profile, because that was once needed to get some non-guix-builds > working. Removing that and updating the core system (guix system > reconfigure …) and rebooting resolved the issue. OK (though I wouldn’t expect it to cause an assertion failure in ld.so). > I still have some breakage left, though: On starting icecat, I see > /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version > `GLIBC_2.33' not found (required by > /gnu/store/qw4dm41ik5krj0s2af9fbcccjga2bfg8-gvfs-1.48.1/lib/gvfs/libgvfscommon.so) > Failed to load module: > /run/current-system/profile/lib/gio/modules/libgioremote-volume-monitor.so > /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version > `GLIBC_2.33' not found (required by > /run/current-system/profile/lib/gio/modules/libgvfsdbus.so) > Failed to load module: > /run/current-system/profile/lib/gio/modules/libgvfsdbus.so > /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version > `GLIBC_2.33' not found (required by > /gnu/store/lxcz3h4klzg041f6rhi9lfyfqba3zizy-libproxy-0.4.17/lib/libproxy.so.1) > Failed to load module: > /run/current-system/profile/lib/gio/modules/libgiolibproxy.so IceCat is trying to load libg*.so from /run/current-system/profile/lib, but those are linked against the old libc (2.31). The solution is to reconfigure your system to the new libc (2.33), as provided by current Guix: sudo guix system reconfigure … HTH! Ludo’.
bug#53142: cuirass: useless guile backtraces.
Hey, > Let's see if the backtraces are now more interesting to read. Found the issue and fixed it with: 07a419e34a31c017c69ec31243c12aa858e2f15f. Thanks, Mathieu
bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.
I can reproduce this with xelatex, lualatex, and pdflatex. This does
not happen with the monolithic texlive package.
Interestingly, the files that are directly involved are all the same.
All the koma-script files are identical to their counterparts in the
monolithic texlive.
The monolithic texlive prints this:
--8<---cut here---start->8---
(/gnu/store/pllzpxmvcldqq89x6w36w77xnr1p4lav-texlive-texmf-20210325/share/texmf
-dist/tex/latex/l3backend/l3backend-pdftex.def) (./komatest.aux) [1{/gnu/store/
pllzpxmvcldqq89x6w36w77xnr1p4lav-texlive-texmf-20210325/share/texmf-dist/fonts/
map/pdftex/updmap/pdftex.map}] (./komatest.aux) )
Output written on komatest.pdf (1 page, 15553 bytes).
--8<---cut here---end--->8---
My guess: the argument is the absolute file name of pdftex.map. It
doesn’t belong to any real package in the tlpdb, and I’m pretty sure we
generate it. However, in this case it must be missing, so that there is
no argument to \strip@prefix.
--
Ricardo
bug#53357: knot-resolver build error
Hi there, knot-resolver 5.4.4 does not build anymore. This can be fixed by adding 'python' to native-inputs. BR
