bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Hello, Leo Prikler writes: > Am Donnerstag, den 20.05.2021, 15:24 +0300 schrieb Andrew Tropin: >> > > In other words, no particular thought was given to -pkg.el. It >> > > was >> > > simply dropped along with many other files. So, if consensus is >> > > reachedthat keeping -pkg.el is a good idea, there is no reason to >> > > not >> > > do that. >> > Thanks for clearing that up. In that case, I don't have any qualms >> > about including them either. >> >> Cool, seems we can get -pkg.el files back. > Yes, we can. I'm late, but I think it's OK to have those *-pkg.el files installed, if they are useful. [...] >> BTW, can you remind me why we do not place packages under >> site-lisp/elpa/NAME-VERSION? It seems almost the same as >> site-lisp/NAME-VERSION, but everything related to describe-package >> and other functions will work out of the box. This way it will work >> even with a foreign distro use case. > Again, Guix is not ELPA and calling it ELPA would be misleading. As > for why we don't put stuff in any other site-lisp/ directory, e.g. > site-lisp/guix.d/NAME-VERSION, doing that led to rather tricky issues, > which is why we've decided to use site-lisp "directly". The current > way of handling things is a bit of a compromise. It gives you per- > package directories like ELPA, but unlike ELPA can easily be handled at > Emacs startup. If you are interested in an alternate view of the world, with the benefits and drawbacks of integrating with package.el to provide packages autoloading in Guix, you may be interested in studying the abandoned https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45316. The packages are loaded by the package.el library via (package-initialize). The main drawback (that was deemed inconvenient enough to not go ahead with this scheme) is summarized in the introductory message: Parting with a directly usable EMACSLOADPATH means that site-start.el *must* run for packages to appear in the load-path; that means for running a test suite, the -Q or --quick Emacs options cannot be used, since it implies --no-site-file. HTH, Maxim
bug#48335: Emacs is broken
Hi,
Xinglu Chen writes:
> On Thu, May 20 2021, Maxim Cournoyer wrote:
>
>> Hi,
>>
>> Checking with a `guix build emacs` built from master:
>>
>> --8<---cut here---start->8---
>> $ ldd
>> /gnu/store/lnwgc4ww47vkq2wv2ay3rdm0ppnmgyfy-emacs-27.2/bin/.emacs-27.2-real
>> | grep libm17n
>> libm17n-core.so.0 =>
>> /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-core.so.0
>> (0x7faa39623000)
>> libm17n-flt.so.0 =>
>> /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-flt.so.0
>> (0x7faa39617000)
>> --8<---cut here---end--->8---
>>
>> So it seems at least on current master things are good?
>>
>> If you cannot reproduce this issue on current master, I suggest we close
>> it.
>
> Unfortunately the problem still exists for me (commit
> 652a03888e1609bd1a687326760436867fe2abb7)
Oh! That's strange.
> ~/src/guix $ guix environment --ad-hoc emacs -- emacs --version
> The following derivation will be built:
>/gnu/store/js53a7lydr66bk3wpwkaj1j8j43mirrm-profile.drv
>
> building CA certificate bundle...
> listing Emacs sub-directories...
> building fonts directory...
> generating GLib schema cache...
> creating GTK+ icon theme cache...
> building cache files for GTK+ input methods...
> building directory of Info manuals...
> building database for manual pages...
> building XDG desktop file cache...
> building XDG MIME database...
> building profile with 1 package...
> /gnu/store/gbzd8hc6360vaxmk2xh5bzkx7dkkwl8q-profile/bin/emacs: error while
> loading shared libraries: libm17n-core.so.0: cannot open shared object file:
> No such file or directory
>
> Since other people aren’t able to reproduce this, I am OK with closing
> this bug.
I tried that exact commit:
$ guix time-machine --commit=652a03888e1609bd1a687326760436867fe2abb7 --
environment --ad-hoc emacs -- emacs --version
GNU Emacs 27.2
Copyright (C) 2021 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
I cannot reproduce it here.
Do you use channels? If so, could you
$ mv ~/.config/guix/channels.scm{,.bak}
$ guix pull
$ guix environment --ad-hoc emacs -- emacs --version
Thank you,
Maxim
bug#48336: kicad cannot see libngspice
Thank you. I ran a simulation based on a tutorial and the results of the simulation were identical. -Original Message- From: Guillaume Le Vaillant To: Christopher Howard Cc: 48336-d...@debbugs.gnu.org Subject: Re: bug#48336: kicad cannot see libngspice Date: Thu, 20 May 2021 21:50:40 + Christopher Howard skribis: > In Kicad Eeschema, if I try to use the Tools >> Simulator menu entry, > Iget an error in a pop-up window that libngspice cannot be found, > andthen the whole Kicad application closes. I see that libngspice is > adependency of kicad so I'm not quite sure what is wrong. > I asked at #kicad at they said that Kicad does not have any gui- > adjustable path settings for ngspice or libngspice, so I don't think > Ihave the application configured wrong. Fix pushed as f7d2ae57543ae6afe14434877d7480b15dcbb5b7.I checked that the libngspice library is detected and that thesimulation window opens correctly, but I have not tried makingsimulations of electronic circuits.Please open another bug if you find a problem.
bug#48576: R: .libPaths dereferences symbolic links; requires restart after "guix install STUFF"
Today I started R (from Emacs). I needed mefa::rep.data.frame,
so I ran "guix install r-mefa -p ../prof" (actually guix package
-p ../prof -m ../manifest.scm, but that shouldn't matter for
the purposes of the bug report)
(r-mefa is not in the guix repo yet)
Now it is installed, I typed in the R prompt:
> mefa::rep.data.frame
Error in loadNamespace(name) : there is no package called ‘mefa’
The solution is to exit the R prompt and restart.
Can we do better?
It appears the search path is set with .libPaths:
> .libPaths
function (new)
{
if (!missing(new)) {
new <- Sys.glob(path.expand(new))
paths <- c(new, .Library.site, .Library)
paths <- paths[dir.exists(paths)]
.lib.loc <<- unique(normalizePath(paths, "/"))
}
else .lib.loc
}
> .libPaths()
[1] "/gnu/store/5cgx6pkhr300v706sv46gx9ypnwanngw-profile/site-library"
[2] "/gnu/store/6laxfxgjxnisi5fzhvqv82wjrgs7q0md-r-minimal-4.0.4/lib/R/library"
It seems like the symbolic link of ../prof is dereferenced to
/gnu/store/5cgx6pkhr300v706sv46gx9ypnwanngw-profile.
Promising is the documentation (? base::normalizePath) of base::normalizePath:
[...]
Where the Unix-alike platform supports it attempts to turn paths
into absolute paths in their canonical form (no ‘./’, ‘../’ nor
**symbolic links**). [...] (emphasis mine)
Maybe we make a copy of normalizePath (base:::guix_normalizeLibraryPath?) doing
the same as base::normalizePath but without dereferencing symbolic links,
and adjust .libPaths to use our variant base:::guix_normalizeLibraryPath instead
of normalizePath?
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
bug#48455: texlive-latex-graphics: non-deterministic build failure
Hi, Chris Marusich skribis: > warning (pdf backend): no pages of output. > Transcript written on graphics-drivers.log. > realloc(): invalid next size > command "luatex" "-interaction=nonstopmode" "-output-directory=build" > "" "graphics-drivers.ins" failed with signal 6 I observed similar issues on several texlive packages: https://issues.guix.gnu.org/48064 Ludo’.
bug#48571: guix pull fails with failed to compute the derivation for Guix
Hi,
"Dr. Arne Babenhauserheide" skribis:
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
As in , this is probably solved by
updating your system to run a newer guix-daemon.
What’s the version of guix-daemon currently in use? You can see that
with ‘pgrep -a guix-daemon’.
HTH,
Ludo’.
bug#48574: Derivations for active jobsets are missing
I noticed that many jobs from the 'ungrafting' jobset were failing due to errors like this: -- substitute: substitute: [Kupdating substitutes from 'http://141.80.167.131:5557'... 0.0% substitute: [Kupdating substitutes from 'http://141.80.167.131:5557'... 100.0% substitute: substitute: [Kupdating substitutes from 'https://ci.guix.gnu.org'... 0.0% substitute: [Kupdating substitutes from 'https://ci.guix.gnu.org'... 100.0% cannot build missing derivation ?/gnu/store/mfyjaw81dhizfm4zkkx75h28vfjy0qq4-python-hacking-4.1.0.drv? -- https://ci.guix.gnu.org/build/375186/details I logged in to berlin.gnu.org and confirmed that the derivation was missing. I think we need to make these "active" of registered derivations into GC roots.
bug#48571: guix pull fails with failed to compute the derivation for Guix
Hi,
I get a failure when using guix pull. Using --no-substitutes makes the
pull work, though.
Log:
$ guix pull
Kanal „flat“ wird vom Git-Repository auf
„https://github.com/flatwhatson/guix-channel.git“ aktualisiert …
Kanal „guix“ wird vom Git-Repository auf
„https://git.savannah.gnu.org/git/guix.git“ aktualisiert …
Kanal „guix“, Commits 9edb3f6 bis 1a06caf werden authentifiziert (3 neue
Commits) …
Von diesen Kanälen wird erstellt:
guix https://git.savannah.gnu.org/git/guix.git 1a06caf
flat https://github.com/flatwhatson/guix-channel.git eba45f4
libtiff-4.2.0-doc 358KiB
2.4MiB/s 00:00 [##] 100.0%
curl-7.76.0-doc 624KiB
3.5MiB/s 00:00 [##] 100.0%
curl-7.76.0 385KiB
9.4MiB/s 00:00 [##] 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird
aktualisiert … 100.0%
compute-guix-derivation 1003B
406KiB/s 00:00 [##] 100.0%
graphviz-2.42.3-doc
5.29GiB/s 00:00 | 3.9MiB transferred
Backtrace:
In guix/ui.scm:
2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
652:2 18 (guix-substitute . _)
In unknown file:
17 (with-continuation-barrier #)
In ice-9/boot-9.scm:
1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
15 (apply-smob/0 #)
In ice-9/boot-9.scm:
1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
1731:15 12 (with-exception-handler # ?)
In guix/scripts/substitute.scm:
701:17 11 (_)
410:7 10 (process-substitution _ "/gnu/store/grb6fymvw0rz75gcm9?" ?)
In ice-9/boot-9.scm:
1736:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
419:9 8 (_)
In ice-9/boot-9.scm:
1731:15 7 (with-exception-handler # ?)
1669:16 6 (raise-exception _ #:continuable? _)
1667:16 5 (raise-exception _ #:continuable? _)
1669:16 4 (raise-exception _ #:continuable? _)
1764:13 3 (_ #< components: (#<> #)
1669:16 2 (raise-exception _ #:continuable? _)
1667:16 1 (raise-exception _ #:continuable? _)
1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
Backtrace:
In ice-9/boot-9.scm:
1736:10 4 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
3 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2 2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 1 (_ #(#(#)))
In guix/ui.scm:
2164:12 0 (run-guix-command _ . _)
guix/ui.scm:2164:12: In procedure run-guix-command:
Backtrace:
15 (primitive-load
"/gnu/store/z3db00laqj4wvhk06fvn8ivgnahy1ma7-compute-guix-derivation")
In ice-9/eval.scm:
155:9 14 (_ _)
159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 12 (with-fluid* _ _ _)
152:2 11 (with-fluid* _ _ _)
In ./guix/store.scm:
2076:24 10 (run-with-store # _
#:guile-for-build _ #:system _ #:target _)
1910:8 9 (_ _)
In ./guix/gexp.scm:
256:18 8 (_ _)
1137:2 7 (_ _)
1003:2 6 (_ _)
849:4 5 (_ _)
In ./guix/store.scm:
1958:12 4 (_ #)
1372:5 3 (map/accumulate-builds # _ _)
1383:15 2 (_ # _ _)
729:11 1 (process-stderr # _)
In ./guix/serialization.scm:
80:6 0 (read-int #)
./guix/serialization.scm:80:6: In procedure read-int:
ERROR:
1. :
file: #f
port: #
guix pull: error: You found a bug: the program
'/gnu/store/z3db00laqj4wvhk06fvn8ivgnahy1ma7-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"1a06cafc07b5ab6a46ea174937694fe8df7fd24a"; system: "x86_64-linux";
host version: "a74de6c41d0af7bfc8b81aac49d8bf1ae7a49cdb"; pull-version: 1).
Please report it by email to .
$ guix --version
guix (GNU Guix) a74de6c41d0af7bfc8b81aac49d8bf1ae7a49cdb
Copyright © 2021 die Guix-Autoren
Lizenz GPLv3+: GNU GPL Version 3 oder neuer
Dies ist freie Software: Sie können sie ändern und weitergeben.
Es gibt keine Garantie, soweit gesetzlich zulässig.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
signature.asc
Description: PGP signature
bug#48561: "Daemon not running" exception when avahi-daemon is not running
Hi Mathieu, Mathieu Othacehe schreef op vr 21-05-2021 om 15:23 [+0200]: > +(catch 'avahi-error > + (lambda () > +(avahi-browse-service-thread service-proc > + #:types %services)) > + (lambda (key err function . _) > +(cond > + ((eq? err error/no-daemon) > + (warning (G_ "Avahi daemon is not running, \ > +cannot auto-discover substitutes servers.~%" > +(exit 1))) Shouldn't this code print an an error message when err is something other than error/no-daemon? You can use error->string. Two examples from (guile-avahi)Error handling: 2.4 Error Handling == Avahi errors are implemented as Scheme exceptions (*note exceptions in Guile: (guile)Exceptions.). Each time a Avahi function returns an error, an exception with key 'avahi-error' is raised. The additional arguments that are thrown include an error code and the name of the Avahi procedure that raised the exception. The error code is pretty much like an enumerate value: it is one of the 'error/' variables exported by the '(avahi)' module (*note Enumerates and Constants::). Exceptions can be turned into error messages using the 'error->string' procedure. The following examples illustrates how Avahi exceptions can be handled: (let ((poll (make-simple-poll))) ;; ;; ... ;; (catch 'avahi-error (lambda () (run-simple-poll (simple-poll poll))) (lambda (key err function . currently-unused) (format (current-error-port) "an Avahi error was raised by `~a': ~a~%" function (error->string err) Again, error values can be compared using 'eq?': ;; `avahi-error' handler. (lambda (key err function . currently-unused) (if (eq? err error/no-daemon) (format (current-error-port) "~a: the Avahi daemon is not running~%" function))) Otherwise LGTM, but I haven't tested. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
bug#48564: ‘channel-with-substitutes-available’ makes assumptions about job names
Hi, Mathieu Othacehe skribis: >> Wouldn’t it be enough to look for the latest completed evaluation (of a >> given jobset)? > > I guess it would be enough but we would need to specify the jobset that > needs to be used, this way maybe: > > (define* (channel-with-substitutes-available chan url > #:key > (specification "master")) Sure, SGTM. > this would also allow me to simplify this patchset: > https://issues.guix.gnu.org/47929. Oh nice, I had completely overlooked that one! I’ll take a look. Thank you, Ludo’.
bug#48335: Emacs is broken
On Thu, May 20 2021, Maxim Cournoyer wrote: > Hi, > > Checking with a `guix build emacs` built from master: > > --8<---cut here---start->8--- > $ ldd > /gnu/store/lnwgc4ww47vkq2wv2ay3rdm0ppnmgyfy-emacs-27.2/bin/.emacs-27.2-real | > grep libm17n > libm17n-core.so.0 => > /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-core.so.0 > (0x7faa39623000) > libm17n-flt.so.0 => > /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-flt.so.0 > (0x7faa39617000) > --8<---cut here---end--->8--- > > So it seems at least on current master things are good? > > If you cannot reproduce this issue on current master, I suggest we close > it. Unfortunately the problem still exists for me (commit 652a03888e1609bd1a687326760436867fe2abb7) --8<---cut here---start->8--- ~/src/guix $ guix environment --ad-hoc emacs -- emacs --version The following derivation will be built: /gnu/store/js53a7lydr66bk3wpwkaj1j8j43mirrm-profile.drv building CA certificate bundle... listing Emacs sub-directories... building fonts directory... generating GLib schema cache... creating GTK+ icon theme cache... building cache files for GTK+ input methods... building directory of Info manuals... building database for manual pages... building XDG desktop file cache... building XDG MIME database... building profile with 1 package... /gnu/store/gbzd8hc6360vaxmk2xh5bzkx7dkkwl8q-profile/bin/emacs: error while loading shared libraries: libm17n-core.so.0: cannot open shared object file: No such file or directory --8<---cut here---end--->8--- Since other people aren’t able to reproduce this, I am OK with closing this bug. signature.asc Description: PGP signature
bug#48468: substitute server connection timeout
Hey, I posted a patchset adding keep-alive support to guix publish earlier: https://issues.guix.gnu.org/48556. Thanks, Mathieu
bug#48564: ‘channel-with-substitutes-available’ makes assumptions about job names
Hey Ludo, > Wouldn’t it be enough to look for the latest completed evaluation (of a > given jobset)? I guess it would be enough but we would need to specify the jobset that needs to be used, this way maybe: --8<---cut here---start->8--- (define* (channel-with-substitutes-available chan url #:key (specification "master")) --8<---cut here---end--->8--- this would also allow me to simplify this patchset: https://issues.guix.gnu.org/47929. WDYT? Thanks, Mathieu
bug#48561: "Daemon not running" exception when avahi-daemon is not running
Hello Maxime, > warning: avahi daemon is not running, cannot auto-discover substitute > servers! This should be fixed with the attached patch. Thanks, Mathieu >From a50bbf99f65d26bbdb0d16112a49335bf913b822 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Fri, 21 May 2021 15:21:15 +0200 Subject: [PATCH] scripts: discover: Warn when the daemon is unreachable. * guix/scripts/discover (guix-discover): Print a warning message when the daemon is unreachable. --- guix/scripts/discover.scm | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/guix/scripts/discover.scm b/guix/scripts/discover.scm index be1eaa6e95..e42f7662d0 100644 --- a/guix/scripts/discover.scm +++ b/guix/scripts/discover.scm @@ -1,5 +1,5 @@ ;;; GNU Guix --- Functional package management for GNU -;;; Copyright © 2020 Mathieu Othacehe +;;; Copyright © 2020, 2021 Mathieu Othacehe ;;; Copyright © 2021 Simon Tournier ;;; ;;; This file is part of GNU Guix. @@ -26,6 +26,7 @@ #:use-module (guix build syscalls) #:use-module (guix build utils) #:use-module (guix scripts publish) + #:use-module (avahi) #:use-module (ice-9 rdelim) #:use-module (srfi srfi-37) #:export (read-substitute-urls @@ -138,5 +139,13 @@ to synchronize with the writer." (parameterize ((%publish-file publish-file)) (mkdir-p (dirname publish-file)) (false-if-exception (delete-file publish-file)) -(avahi-browse-service-thread service-proc - #:types %services) +(catch 'avahi-error + (lambda () +(avahi-browse-service-thread service-proc + #:types %services)) + (lambda (key err function . _) +(cond + ((eq? err error/no-daemon) + (warning (G_ "Avahi daemon is not running, \ +cannot auto-discover substitutes servers.~%" +(exit 1))) -- 2.31.1
bug#48564: ‘channel-with-substitutes-available’ makes assumptions about job names
Hello! I wanted to try something like this: --8<---cut here---start->8--- (use-modules (guix ci)) (list (channel-with-substitutes-available %default-guix-channel "https://ci.guix.gnu.org;) (channel-with-substitutes-available (channel (name 'guix-hpc) (url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;)) "https://guix.bordeaux.inria.fr;)) --8<---cut here---end--->8--- However, that doesn’t work because ‘channel-with-substitutes-available’ looks for a ‘guix.x86_64-linux’ job, which doesn’t exist on this Cuirass instance. Wouldn’t it be enough to look for the latest completed evaluation (of a given jobset)? Incidentally, it seems ‘complete?’ is always false: --8<---cut here---start->8--- scheme@(guix ci)> (latest-evaluations "https://guix.bordeaux.inria.fr; 10) $16 = (#< id: 88628 spec: "guix-past" complete?: #f checkouts: (#< commit: "065d2cd6ced96ddb38c15a46f798488f61660a33" channel: "guix">)> #< id: 88627 spec: "guix-hpc" complete?: #f checkouts: (#< commit: "065d2cd6ced96ddb38c15a46f798488f61660a33" channel: "guix">)> #< id: 88584 spec: "guix-past" complete?: #f checkouts: (#< commit: "fd5527407ff336c4af1c5511e19c0956720cd7aa" channel: "guix">)> #< id: 88583 spec: "guix-hpc" complete?: #f checkouts: (#< commit: "fd5527407ff336c4af1c5511e19c0956720cd7aa" channel: "guix">)> #< id: 88470 spec: "guix-past" complete?: #f checkouts: (#< commit: "2710df38b0c317bdc69c61c7775d8141eb214dd1" channel: "guix">)> #< id: 88469 spec: "guix-hpc" complete?: #f checkouts: (#< commit: "2710df38b0c317bdc69c61c7775d8141eb214dd1" channel: "guix">)> #< id: 88442 spec: "guix-past" complete?: #f checkouts: (#< commit: "83d21785a9fbc6a7e87435d437b2b3917f3a3b09" channel: "guix">)> #< id: 88441 spec: "guix-hpc" complete?: #f checkouts: (#< commit: "83d21785a9fbc6a7e87435d437b2b3917f3a3b09" channel: "guix">)> #< id: 88186 spec: "guix-past" complete?: #f checkouts: (#< commit: "061823da03add693df9c411fee9ccdcc7291f0ec" channel: "guix">)> #< id: 88185 spec: "guix-hpc" complete?: #f checkouts: (#< commit: "061823da03add693df9c411fee9ccdcc7291f0ec" channel: "guix">)>) --8<---cut here---end--->8--- Thoughts? Ludo’.
bug#48561: "Daemon not running" exception when avahi-daemon is not running
Severity: minor My /var/log/guix-daemon.log.* are full of backtraces like these (and boring messages like SIGPOLL, spurious SIGPOLL, accepted connections from pid [..], user [...]). Backtrace: In ice-9/boot-9.scm: 1752:10 10 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 9 (apply-smob/0 #) In ice-9/boot-9.scm: 724:2 8 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 7 (_ #(#(#))) In guix/ui.scm: 2166:12 6 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 5 (with-exception-handler _ _ #:unwind? _ # _) 1747:15 4 (with-exception-handler # …) In guix/scripts/discover.scm: 141:8 3 (_) In guix/avahi.scm: 171:17 2 (avahi-browse-service-thread _ #:types _ #:ignore-local? …) In unknown file: 1 (make-client # () #) In ice-9/boot-9.scm: 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `avahi-error' with args `(# make-client)'. Some kind of warning message when the daemon is not running makes sense, but a full backtrace seems unneeded. Maybe print a line like: warning: avahi daemon is not running, cannot auto-discover substitute servers! instead. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
