bug#63972: specifying a substitute server without adding its PGP key silently ignores it
Hi, Attila Lendvai skribis: > i've installed a new guix, and at the first `guix system reconfigure` i > specified a substitute server using --substitute-urls for That Other Channel. > i had to do this, because the config.scm that contains the substitute > specification is yet to be applied. > > it didn't work. it prints everything as usual, including the 100% message for > that substitute server, but it starts to build packages locally for which > substitutes are available. i haven't noticed any indication that there's a > problem with any of the substitute servers. > > once i've downloaded the .pub and i finally did the right incantation (sudo > guix archive --authorize < signing-key.pub), then it started to download the > substitutes as i expected. > > i would much prefer a behavior where a "cryptyc" exception and backtrace is > printed by a toplevel error handler. it has cost me about an hour of my life. I agree we should print a message when stumbling upon unauthorized substitutes (it’s not OpenPGP, BTW). Note that it’s not completely trivial: you might download substitutes not signed by one of the keys in the ACL if they happen to match substitutes that *are* signed by one of the authorized keys. Also, when discovery is enabled, it’s preferable to silently ignore neighboring servers that the user did not explicitly specify via ‘--substitute-urls’. Ludo’.
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi, Maxim Cournoyer skribis: > Ludovic Courtès writes: [...] >> When a service is stopped at the time of reconfigure, it is immediately >> replaced and then started. >> >> Replacing works by unregistering the old instance from the registry and >> registering a new one. As a side effect, you end up with an instance >> that’s enabled (see ‘service-registry’ in (shepherd services)). >> >> I never thought it could be a problem. WDYT? > > I think it probably goes against users' expectation (i.e., systemd) that > a disabled service stays disabled unless manually re-enabled (I think > that's the way it is for systemd, even when the system is upgraded?). Does systemd have a notion of enabled/disabled? > If we want Guix/Shepherd to differ from this common expectation (on the > ground that declarative should prevail over state, maybe?), it'd be good > to have at least this documented/explained somewhere. > > What do you think? I’m fine either way. We can also change it such that replacing a disabled service does not re-enable it; that’s probably more logical. Thoughts? Ludo’.
bug#63368: Build coordiantor "Signals delivery fails constantly" crashes
Christopher Baines skribis: > Ludovic Courtès writes: > >> Christopher Baines skribis: [...] >>> 2023-06-02 19:01:22 Signals delivery fails constantly >>> 2023-06-02 19:01:29 locale is en_US.utf8 >>> 2023-06-02 19:01:29 (gnutls version: 3.7.7, guix version: 1.4.0-6.dc5430c) >>> >>> Which is a bit more concerning, since the build coordinator agent is >>> intentionally quite simple (no SQLite for example). >> >> The closure of (guix-build-coordinator agent) seems to be quite large >> still. >> >> Could you check what .so files are loaded by that code, perhaps via >> /proc/PID/maps? > > I think I see these (that's on milano-guix-1 currently): > > /gnu/store/0i81lpfnn05pmjc5f43q4nfvd27r08f7-guile-gnutls-3.7.12/lib/guile/3.0/extensions/guile-gnutls-v-2.so.0.0.0 > /gnu/store/0jk7sl5xqwwdkzjpp9sxgz9z0d48a3vy-libunistring-1.0/lib/libunistring.so.2.2.0 > /gnu/store/1r1azdi4hvfypnx14d01n60p4aa7g2im-libidn2-2.3.4/lib/libidn2.so.0.3.8 > /gnu/store/1w1r6r56z9lhg8ghcb7lxss6mkn7d5l1-libgc-8.2.2/lib/libgc.so.1.5.1 > /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/lib/libguile-3.0.so.1.6.0 > /gnu/store/8y0pwifz8a3d7zbdfzsawa1amf4afx1s-libgcrypt-1.10.1/lib/libgcrypt.so.20.4.1 > /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/libgcc_s.so.1 > /gnu/store/c2fx42ial6lr60s96xcbml5hd8vwaxq3-nettle-3.8.1/lib/libhogweed.so.6.6 > /gnu/store/c2fx42ial6lr60s96xcbml5hd8vwaxq3-nettle-3.8.1/lib/libnettle.so.8.6 > /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2 > /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libcrypt.so.1 > /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6 > /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so.6 > /gnu/store/ib2n2vzqpchc3bhh9i712w5sq9zapn8d-gmp-6.2.1/lib/libgmp.so.10.4.1 > /gnu/store/j5kzdjan6mnf2ngmkc50fia8vrbpqi9b-libtasn1-4.19.0/lib/libtasn1.so.6.6.3 > /gnu/store/k0p01a6b7hsxjfr65ga4f2gh6lh92aiq-lzlib-1.13/lib/liblz.so.1.13 > /gnu/store/m9wi9hcrf7f9dm4ri32vw1jrbh1csywi-libgpg-error-1.45/lib/libgpg-error.so.0.33.0 > /gnu/store/slzq3zqwj75lbrg4ly51hfhbv2vhryv5-zlib-1.2.13/lib/libz.so.1.2.13 > /gnu/store/vq7dxp5la2lnhsvniwv38j0ggvsmzim7-p11-kit-0.24.1/lib/libp11-kit.so.0.3.0 > /gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-libffi-3.4.4/lib/libffi.so.8.1.2 > /gnu/store/yr4lbvdyc4dgs76yij1dw2w2z8s84af8-gnutls-3.7.7/lib/libgnutls.so.30.34.1 Hmm no idea. I’ve never seen “Signals delivery fails” before so I really wonder what could be causing this. Would be great if you could come up with a reduced test case, but I guess that won’t be easy. Or perhaps you could run a Coordinator agent under ‘strace -f’ to see if we get hints? Ludo’.
bug#63972: specifying a substitute server without adding its PGP key silently ignores it
i've installed a new guix, and at the first `guix system reconfigure` i specified a substitute server using --substitute-urls for That Other Channel. i had to do this, because the config.scm that contains the substitute specification is yet to be applied. it didn't work. it prints everything as usual, including the 100% message for that substitute server, but it starts to build packages locally for which substitutes are available. i haven't noticed any indication that there's a problem with any of the substitute servers. once i've downloaded the .pub and i finally did the right incantation (sudo guix archive --authorize < signing-key.pub), then it started to download the substitutes as i expected. i would much prefer a behavior where a "cryptyc" exception and backtrace is printed by a toplevel error handler. it has cost me about an hour of my life. i'd suggest the following general strategy for the entire codebase in general: throw exceptions, and let them fly all the way up to the toplevel error handler that should print it with a backtrace. this should be the baseline, and only then start adding very specific exception handlers to print friendly and localizable error messages for various situations, and only ever swallow exceptions when it's really justified. e.g. a file-not-found error in an ensure-file-deleted function. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Civilization is in a race between education and catastrophe. Let us learn the truth and spread it as far and wide as our circumstances allow. For the truth is the greatest weapon we have.” — H.G. Wells (1866–1946)
bug#63526: ping on a build fix for a build failure (main branch)
Hello Andy,
Am Tue, May 30, 2023 at 10:54:20AM -0700 schrieb Andy Tai:
> Hi, following previous comments (thanks) I have submitted a patch to
> correctly fix a build failure due to compiler warnings, instead of
> avoiding not building tests, on this Guix bug issue:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
> Please review the patch (which shall be a simple and low risk fix). Thanks!
I have reworked a bit the punctuation of the commit message, shortened
the patch file name and pushed. By this I am closing the two corresponding
bug reports (it would have been enough to send a second version of the
patch to the first bug).
Did you contact upstream? Looking at the test, it looked wrong before and
after your patch...
if (len < token->data.character.len) {
hubbub_token t = { 0 };
t.type = HUBBUB_TOKEN_CHARACTER;
t.data.character.ptr += len;
t.data.character.len -= len;
...
Adding to a previously undefined, now 0 pointer .ptr raised a warning
for a reason, I think; and it looks like the t.data maybe should be
token->data. But it is quite possible that this branch is not even
reached by the test.
Andreas
bug#63975: Broken link (404) in blog post breadcrumbs
Go to: https://guix.gnu.org/en/blog/2023/parameterized-packages-for-gnu-guix/ then click on the link ‘Parameterized Packages for GNU Guix’ in the breadcrumbs ‘Home -> Blog -> Parameterized Packages for GNU Guix’. This goes to https://guix.gnu.org/blog/2023/parameterized-packages-for-gnu-guix which is a 404 Not Found. The same issue holds for non-English translations as well. Other blog posts are affected as well. Best regards Maxime Devos OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#63977: Incorrect language tags in case of incomplete translations
On the French part of the website, https://guix.gnu.org/fr/blog/2023/parameterized-packages-for-gnu-guix/, we have an lang="fr" attribute for the 'html' tag: [...] This is fine. This French web page has an English blog post. This is OK, HTML supports that. Just put a "lang="en"' attribute in the 'article' tag and the spec is happy, spell-check works, screen readers interpret things properly, ... This is, however, not done currently: Currently, blog posts are never translated at all, so fixing this should just be a matter of unconditionally adding 'lang="en"' to all . Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#63979: SHEPHERD-SERVICE-CANONICAL-NAME assumes a non-empty PROVISION, but such instantiation is allowed
it's possible to instantiate a SHEPHERD-SERVICE with an empty list as PROVISION, but then much later in time and space SHEPHERD-SERVICE-CANONICAL-NAME dies on it. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You live within a framework of perception that's determined by your values. […] We never think of the world as something that reveals itself through our values, but of course it does! Because you look at what you want. […] Whatever you're focusing on is directed by what you value.” — Jordan Peterson (1962–)
bug#63982: Shepherd can crash when a user service fails to start
Hi!
I've noticed that while all my user services (managed via GNU Stow --
not via Guix Home) were working, 'herd status' would report that
/run/user/1000/shepherd/socket was missing and bail out.
Starting from a nonexistent /run/user/1000/shepherd/socket, using old
Shepherd 0.9.1:
--8<---cut here---start->8---
$ /gnu/store/dblbnj1yra4yrrfjbnzsa0ldcl3170ap-shepherd-0.9.1/bin/shepherd
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g115}#). Add #:declarative?
#f to your define-module invocation.
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
$
Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this
problem.
Loading time (native compiled elisp)...
Loading time (native compiled elisp)...done
Loading /home/maxim/.emacs.d/recentf...
Loading /home/maxim/.emacs.d/recentf...done
Cleaning up the recentf list...
Cleaning up the recentf list...done (0 removed)
../../.emacs: Warning: Use keywords rather than deprecated positional arguments
to `define-minor-mode'
Preparing diary...
No diary entries for Friday, June 9, 2023
Preparing diary...done
Appointment reminders enabled
Loading /home/maxim/.emacs.d/emms/cache...
Loading /home/maxim/.emacs.d/emms/cache...done
[yas] Prepared just-in-time loading of snippets successfully.
[yas] Prepared just-in-time loading of snippets successfully.
Starting new Ispell process aspell with english dictionary... \
Starting new Ispell process aspell with english dictionary...done
Starting Emacs daemon.
Unable to start the daemon.
Another instance of Emacs is running the server, either as daemon or
interactively.
You can use emacsclient to connect to that Emacs process.
Saving file /home/maxim/.emacs.d/emms/history...
Wrote /home/maxim/.emacs.d/emms/history
Wrote /home/maxim/.emacs.d/recentf
Error: server did not start correctly
Service emacs could not be started.
gpg-agent: a gpg-agent is already running - not starting a new one
Service gpg-agent could not be started.
Service ibus-daemon has been started.
$ herd status
Started:
+ ibus-daemon
+ root
Stopped:
- emacs
- gpg-agent
- jackd
- workrave
--8<---cut here---end--->8---
If I then run it anew, it fails with "shepherd: while opening socket
'/run/user/1000/shepherd/socket': bind: Address already in use", because
apparently 'herd stop root' didn't remove it.
--8<---cut here---start->8---
$ herd stop root
Exiting.
[...]
$ /gnu/store/dblbnj1yra4yrrfjbnzsa0ldcl3170ap-shepherd-0.9.1/bin/shepherd
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g115}#). Add #:declarative?
#f to your define-module invocation.
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
maxim@hurd ~/src/guix [env]$
Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this
problem.
Loading time (native compiled elisp)...
Loading time (native compiled elisp)...done
Loading /home/maxim/.emacs.d/recentf...
Loading /home/maxim/.emacs.d/recentf...done
Cleaning up the recentf list...
Cleaning up the recentf list...done (0 removed)
../../.emacs: Warning: Use keywords rather than deprecated positional arguments
to `define-minor-mode'
Preparing diary...
No diary entries for Friday, June 9, 2023
Preparing diary...done
Appointment reminders enabled
Loading /home/maxim/.emacs.d/emms/cache...
Loading /home/maxim/.emacs.d/emms/cache...done
[yas] Prepared just-in-time loading of snippets successfully.
[yas] Prepared just-in-time loading of snippets successfully.
Starting new Ispell process aspell with english dictionary... \
Starting new Ispell process aspell with english dictionary...done
Starting Emacs daemon.
Unable to start the daemon.
Another instance of Emacs is running the server, either as daemon or
interactively.
You can use emacsclient to connect to that Emacs process.
Saving file /home/maxim/.emacs.d/emms/history...
Wrote /home/maxim/.emacs.d/emms/history
Wrote /home/maxim/.emacs.d/recentf
Error: server did not start correctly
Service emacs could not be started.
gpg-agent: a gpg-agent is already running - not starting a new one
Service gpg-agent could not be started.
Service ibus-daemon has been started.
shepherd: while opening socket '/run/user/1000/shepherd/socket': bind: Address
already in use
Exiting shepherd...
S
bug#63526: ping on a build fix for a build failure (main branch)
I did contact upstream, no response
On Fri, Jun 9, 2023 at 4:07 AM Andreas Enge wrote:
>
> Hello Andy,
>
> Am Tue, May 30, 2023 at 10:54:20AM -0700 schrieb Andy Tai:
> > Hi, following previous comments (thanks) I have submitted a patch to
> > correctly fix a build failure due to compiler warnings, instead of
> > avoiding not building tests, on this Guix bug issue:
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
> > Please review the patch (which shall be a simple and low risk fix). Thanks!
>
> I have reworked a bit the punctuation of the commit message, shortened
> the patch file name and pushed. By this I am closing the two corresponding
> bug reports (it would have been enough to send a second version of the
> patch to the first bug).
>
> Did you contact upstream? Looking at the test, it looked wrong before and
> after your patch...
> if (len < token->data.character.len) {
>hubbub_token t = { 0 };
>t.type = HUBBUB_TOKEN_CHARACTER;
>t.data.character.ptr += len;
>t.data.character.len -= len;
> ...
> Adding to a previously undefined, now 0 pointer .ptr raised a warning
> for a reason, I think; and it looks like the t.data maybe should be
> token->data. But it is quite possible that this branch is not even
> reached by the test.
>
> Andreas
>
--
Andy Tai, a...@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat: andytai1010
Year 2023 民國112年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi Ludovic, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >> Ludovic Courtès writes: > > [...] > >>> When a service is stopped at the time of reconfigure, it is immediately >>> replaced and then started. >>> >>> Replacing works by unregistering the old instance from the registry and >>> registering a new one. As a side effect, you end up with an instance >>> that’s enabled (see ‘service-registry’ in (shepherd services)). >>> >>> I never thought it could be a problem. WDYT? >> >> I think it probably goes against users' expectation (i.e., systemd) that >> a disabled service stays disabled unless manually re-enabled (I think >> that's the way it is for systemd, even when the system is upgraded?). > > Does systemd have a notion of enabled/disabled? Yes! 'systemctl disable ' [0]. It does stick around until the user changes it, I can confirm the behavior which I've recently seen on a Debian system upgrade (the service remained disabled and the updater warned it wouldn't be restarted because of that). [0] https://www.freedesktop.org/software/systemd/man/systemctl.html#disable%20UNIT%E2%80%A6 > I’m fine either way. We can also change it such that replacing a > disabled service does not re-enable it; that’s probably more logical. I guess sticking to the established convention set by systemd would cause the least friction down the road. If we agree on this, we should reopen this bug (and eventually fix it :-)). -- Thanks, Maxim
bug#63986: Julia is very slow
Hi guix,
I just noticed that the following line
julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N =
1000; A = rand(N, N); B = rand(N, N); @btime $A*$B'
gives around 530 ms in my laptop when using guix provided julia. Same
behavior when running within a guix container.
This very same code, using the binary one may download from the julia
site gives 15 ms.
I’m using here an up to date guix. As a reference, julia binary
provided by archlinux takes also 15 ms.
Thanks,
Cayetano Santos
