bug#33968: errors in shepherd service constructors are not logged and lead to misleading status, hang boot
Hi Florian, I stumbled upon this problem with https://issues.guix.gnu.org/48521, and had a hard time to debug it (due to the completely missing information in any output or log from shepherd). Worst, this caused the system to hang early on boot! I'm raising the priority of this issue. Thanks, Maxim
bug#48521: opendht-service-type hangs Shepherd at boot
Hello, Maxim Cournoyer writes: > Hello, > > I just noticed about this problem following a reboot. I can also > reproduce it in 'guix system vm', simply adding the opendht-service-type > to my operating-system declaration. > > The boot proceeds until 'error in finalization thread: Success' then > hangs indefinitely. > > What is troubling for me is that the service is rather straightforwardly > defined. It uses the make-forkexec-constructor/container like so: > > (define (opendht-shepherd-service config) > "Return a running OpenDHT." > (shepherd-service >(documentation "Run an OpenDHT node.") >(provision '(opendht dhtnode dhtproxy)) >(requirement '(user-processes syslogd)) >(start #~(make-forkexec-constructor/container > (list #$@(opendht-configuration->command-line-arguments config)) > #:mappings (list (file-system-mapping >(source "/dev/log") ;for syslog >(target source))) > #:user "opendht")) >(stop #~(make-kill-destructor > > I'm not sure how using such basic building blocks could lead to a hang > in Shepherd ? It seems Shepherd can't cope with a failing start procedure/script when a variable was not bound. To diagnose the problem, the best way ended up being to extract the code of the constructor in a separate script to run it separately. This made the error quickly apparent: "Unbound variable: file-system-mapping". We should try to handle this class of errors in Shepherd and report a useful message and *not* crash Shepherd or otherwise hang. Pushed with commit a09cdf1f9d. Closing. Maxim
bug#46333: sbcl-common-lisp-jupyter does not install kernel.json
Hi, I've checked the r-irkernel and it's coping existing kernelspec , which is not useful in this case. As Guillaume mentioned we could tweak it before installation phase by using cl-jupyter:install, so here is my draft: --8<---cut here---start->8--- (arguments `(#:phases (modify-phases %standard-phases (add-before 'install 'generate-kernelspec (lambda* (#:key outputs #:allow-other-keys) (let* ((out (assoc-ref outputs "out")) (kernelspec (string-append out "/share/cl-jupyter/kernelspec"))) (mkdir-p kernelspec) (invoke "sbcl" "--eval" "\"(require :asdf)\"" "--eval" "\"(require :common-lisp-jupyter)\"" "--eval" (string-append "\"(cl-jupyter:install" ":bin-path" (string-append (assoc-ref %build-inputs "sbcl") "/bin/sbcl") ":prefix" out ")\"") "--eval" "\"(exit)\"")) #t)) (add-after 'install 'install-kernelspec (lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out")) (kernelspec (string-append out "/share/cl-jupyter/kernelspec"))) (invoke "jupyter" "kernelspec" "install" "--name" "cl-jupyter" "--prefix" out kernelspec) #t)) --8<---cut here---end--->8--- But there could be a potential blocking issue with :prefix key https://github.com/yitzchak/common-lisp-jupyter/issues/78 On Tue, 18 May 2021 at 16:58, Guillaume Le Vaillant wrote: > > Hi Jack, > > I guess it will be easier to just add a phase writing the "kernel.json" > file in the right place. In this build phase, to know if the package is > being built for SBCL or ECL, the '(%lisp-type)' function that will > return "sbcl" or "ecl" can be used. There's an example in the > sbcl-trivial-backtrace package. -- … наш разум - превосходная объяснительная машина которая способна найти смысл почти в чем угодно, истолковать любой феномен, но совершенно не в состоянии принять мысль о непредсказуемости.
bug#48521: opendht-service-type hangs Shepherd at boot
Maxim Cournoyer writes: > Hello, > > I just noticed about this problem following a reboot. I can also > reproduce it in 'guix system vm', simply adding the opendht-service-type > to my operating-system declaration. > > The boot proceeds until 'error in finalization thread: Success' then > hangs indefinitely. > > What is troubling for me is that the service is rather straightforwardly > defined. It uses the make-forkexec-constructor/container like so: > > (define (opendht-shepherd-service config) > "Return a running OpenDHT." > (shepherd-service >(documentation "Run an OpenDHT node.") >(provision '(opendht dhtnode dhtproxy)) >(requirement '(user-processes syslogd)) >(start #~(make-forkexec-constructor/container > (list #$@(opendht-configuration->command-line-arguments config)) > #:mappings (list (file-system-mapping >(source "/dev/log") ;for syslog >(target source))) > #:user "opendht")) >(stop #~(make-kill-destructor > > I'm not sure how using such basic building blocks could lead to a hang > in Shepherd ? After much trial and error, the service can be made to not hang Shepherd with the removal of the mappings argument: --8<---cut here---start->8--- modified gnu/services/networking.scm @@ -845,9 +845,9 @@ CONFIG, an object." (requirement '(user-processes networking syslogd)) (start #~(make-forkexec-constructor/container (list #$@(opendht-configuration->command-line-arguments config)) - #:mappings (list (file-system-mapping - (source "/dev/log") ;for syslog - (target source))) + ;; #:mappings (list (file-system-mapping + ;; (source "/dev/log") ;for syslog + ;; (target source))) #:user "opendht")) (stop #~(make-kill-destructor --8<---cut here---end--->8--- I have no idea why that is, but given that the tor-service-type does the same thing, I can only conclude that it is some strange interaction between dhtnode and syslog. The above fixes the hang, but breaks logging to syslog. Ideas? Maxim
bug#48515: ell 0.40 test failure
I was able to reproduce the test suite failure, but with a different test. I was using my 3900XT, also 24 cores PASS: unit/test-time PASS: unit/test-dir-watch PASS: unit/test-path PASS: unit/test-dbus-watch PASS: unit/test-gvariant-message PASS: unit/test-dbus ./build-aux/test-driver: line 107: 17030 Aborted "$@" > $log_file 2>&1 FAIL: unit/test-dbus-properties PASS: unit/test-dbus-message-fds PASS: unit/test-dbus-service PASS: unit/test-main PASS: unit/test-pbkdf2 Testsuite summary for ell 0.40 # TOTAL: 40 # PASS: 39 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log make[3]: *** [Makefile:2099: test-suite.log] Error 1 make[2]: *** [Makefile:2207: check-TESTS] Error 2 make[1]: *** [Makefile:2713: check-am] Error 2 make: *** [Makefile:2715: check] Error 2 Test suite failed, dumping logs. --- ./test-suite.log ell 0.40: ./test-suite.log # TOTAL: 40 # PASS: 39 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: unit/test-dbus-properties === launching dbus-daemon dbus-daemon process 17031 created ready request name result=failed TEST: Legacy properties get TEST FAILED in get_properties_callback at unit/test-dbus-properties.c:340: !l_dbus_message_get_error(message, ((void *)0), ((void *)0)) Disconnected from DBus FAIL unit/test-dbus-properties (exit status: 134) command "make" "check" "-j" "24" failed with status 2 builder for `/gnu/store/1vjr3z3mghf77wvwj0mb5f4nwzmd4c7i-ell-0.40.drv' failed with exit code 1 build of /gnu/store/1vjr3z3mghf77wvwj0mb5f4nwzmd4c7i-ell-0.40.drv failed View build log at '/var/log/guix/drvs/1v/jr3z3mghf77wvwj0mb5f4nwzmd4c7i-ell-0.40.drv.bz2'. guix build: error: build of `/gnu/store/1vjr3z3mghf77wvwj0mb5f4nwzmd4c7i-ell-0.40.drv' failed -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
That looks like it'd mess with people's installed ELPA packages. In
general, hacks based on package-directory-list don't feel very stable.
Consider writing a function similar in nature to `package-load-all-
descriptors' instead.
Also, this seems to rely on us not deleting the -pkg.el, but probably
won't work for packages, that don't ship it, e.g. emacs-howm.
[Adding Arun Isaac to CC. Their commit d8796851 is the first one to
drop -pkg.el, but without explanation.]
Am Mittwoch, den 19.05.2021, 20:58 +0300 schrieb Andrew Tropin:
> From: Andrew Tropin
> Date: Wed, 19 May 2021 20:44:22 +0300
> Subject: [PATCH] guix: build: emacs-build-system: Make package.el
> aware of
> guix packages
>
> After updating the package-directory-list variable, functions like
> list-packages,
> describe-package become aware of packages installed by guix.
>
> ---
> This code is getting work done, but I'm not a very experienced elisp
> developer, so
> please review it thoroughly.
>
> gnu/packages/aux-files/emacs/guix-emacs.el | 10 ++
> guix/build/emacs-build-system.scm | 2 +-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el
> b/gnu/packages/aux-files/emacs/guix-emacs.el
> index ca9146c535..4aa4220cda 100644
> --- a/gnu/packages/aux-files/emacs/guix-emacs.el
> +++ b/gnu/packages/aux-files/emacs/guix-emacs.el
> @@ -58,6 +58,16 @@ The files in the list do not have extensions (.el,
> .elc)."
> (load f 'noerror))
>autoloads)))
>
> +
> +(require 'package)
> +
> +;; Set `package-directory-list' to the value without elpa/ suffix
> +;; to match the structure of site-lisp directory of guix's emacs
> +;; build system.
> +;;;###autoload
> +(setq package-directory-list
> + (list (string-remove-suffix "/elpa" (car package-directory-
> list
> +
> (provide 'guix-emacs)
>
> ;;; guix-emacs.el ends here
> diff --git a/guix/build/emacs-build-system.scm
> b/guix/build/emacs-build-system.scm
> index e41e9a6595..7565b9a422 100644
> --- a/guix/build/emacs-build-system.scm
> +++ b/guix/build/emacs-build-system.scm
> @@ -53,7 +53,7 @@
>
> ;; These are the default inclusion/exclusion regexps for the install
> phase.
> (define %default-include '("^[^/]*\\.el$" "^[^/]*\\.info$"
> "^doc/.*\\.info$"))
> -(define %default-exclude '("^\\.dir-locals\\.el$" "-pkg\\.el$"
> +(define %default-exclude '("^\\.dir-locals\\.el$"
> "^[^/]*tests?\\.el$"))
>
> (define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
bug#30093: what manual workaround?
Hello,
I see people mentioning here that there doesn't seem to be a general solution
to be included in Guix for this, but I als do not understand what the
particular solution (for my machine, for example) is supposed to be.
I'm a new user to Guix and also not technically very experienced with Linux
OS's, so feel free to point me out something obvious I have missed.
I currently have Guix on top of Ubuntu 20.04, and I have this exact problem
with XDG_DATA_DIRS being exported on startup of Gnome and breaking it, and i
happend when this variable is added to ~/.guix-profile/etc/profile when
installing certain packages; the ones detected so far where python-ipython,
python-ipykernel and python-notebook.
As far as I unedrstand, when Ubuntu starts up, it runs /etc/profile, which in
turn reads through all scripts inside /etc/profile.d. In that dir, we have
guix.sh, which I will paste here:
# _GUIX_PROFILE: `guix pull` profile
_GUIX_PROFILE="$HOME/.config/guix/current"
export PATH="$_GUIX_PROFILE/bin${PATH:+:}$PATH"
# Export INFOPATH so that the updated info pages can be found
# and read by both /usr/bin/info and/or $GUIX_PROFILE/bin/info
# When INFOPATH is unset, add a trailing colon so that Emacs
# searches 'Info-default-directory-list'.
export INFOPATH="$_GUIX_PROFILE/share/info:$INFOPATH"
# GUIX_PROFILE: User's default profile
GUIX_PROFILE="$HOME/.guix-profile"
[ -L $GUIX_PROFILE ] || return
GUIX_LOCPATH="$GUIX_PROFILE/lib/locale"
export GUIX_PROFILE GUIX_LOCPATH
[ -f "$GUIX_PROFILE/etc/profile" ] && . "$GUIX_PROFILE/etc/profile"
# set XDG_DATA_DIRS to include Guix installations
export
XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
The culprit in this case seems to be [ -f "$GUIX_PROFILE/etc/profile" ] && .
"$GUIX_PROFILE/etc/profile", and this is because it is getting the following
two lines from $GUIX_PROFILE/etc/profile which are introduced by installing
python-ipython (for example):
export
GI_TYPELIB_PATH="${GUIX_PROFILE:-/gnu/store/22lc31mr4h00x5swzk73293pm2xpaahi-profile}/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"
export
XDG_DATA_DIRS="${GUIX_PROFILE:-/gnu/store/22lc31mr4h00x5swzk73293pm2xpaahi-profile}/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
In fact, when this happens, the last line in guix.sh is only duplicating what
the line inside .guix-profile/etc/profile had already exported:
export
XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
What is the workaround that can be used here?
I only see two possible solutions, which are unsatisfactory to me: * Refrain
from installing packages that alter this variable; * Comment all lines inside
guix.sh and add . "$GUIX_PROFILE/etc/profile to my .bash_rc file, focing me to
open a terminal everytime I want to launch guix installed packages.Is there
another alternative for this?
Eagerly awating for feedback on this, as it's completely destroying my
workflow; I am never sure when will install a package that wll break Ubuntu.
Thanks,
Tomás
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
From: Andrew Tropin
Date: Wed, 19 May 2021 20:44:22 +0300
Subject: [PATCH] guix: build: emacs-build-system: Make package.el aware of
guix packages
After updating the package-directory-list variable, functions like
list-packages,
describe-package become aware of packages installed by guix.
---
This code is getting work done, but I'm not a very experienced elisp
developer, so
please review it thoroughly.
gnu/packages/aux-files/emacs/guix-emacs.el | 10 ++
guix/build/emacs-build-system.scm | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el
b/gnu/packages/aux-files/emacs/guix-emacs.el
index ca9146c535..4aa4220cda 100644
--- a/gnu/packages/aux-files/emacs/guix-emacs.el
+++ b/gnu/packages/aux-files/emacs/guix-emacs.el
@@ -58,6 +58,16 @@ The files in the list do not have extensions (.el, .elc)."
(load f 'noerror))
autoloads)))
+
+(require 'package)
+
+;; Set `package-directory-list' to the value without elpa/ suffix
+;; to match the structure of site-lisp directory of guix's emacs
+;; build system.
+;;;###autoload
+(setq package-directory-list
+ (list (string-remove-suffix "/elpa" (car package-directory-list
+
(provide 'guix-emacs)
;;; guix-emacs.el ends here
diff --git a/guix/build/emacs-build-system.scm
b/guix/build/emacs-build-system.scm
index e41e9a6595..7565b9a422 100644
--- a/guix/build/emacs-build-system.scm
+++ b/guix/build/emacs-build-system.scm
@@ -53,7 +53,7 @@
;; These are the default inclusion/exclusion regexps for the install phase.
(define %default-include '("^[^/]*\\.el$" "^[^/]*\\.info$" "^doc/.*\\.info$"))
-(define %default-exclude '("^\\.dir-locals\\.el$" "-pkg\\.el$"
+(define %default-exclude '("^\\.dir-locals\\.el$"
"^[^/]*tests?\\.el$"))
(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
--
2.31.1
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > Most other package managers seem to respect "infrastructure" provided > > by package.el. > I don't think that statement is well-supported by the data we have. Agree, that was an incorrect statement. I should have said something like: there are some popular tools like use-package configuration helper, Nix package manager, Spacemacs configuration framework, some elisp archives and probably something else, which utilize and follow package.el. Not all of them use package.el itself, but they follow conventions and describe-package help command and some other work correctly. > Why should we let ELPA dictate our layout? I have not even once tried > customizing package.el for actual use since I got Guix, because the > elpa importer is trivial. We don't have to. Actually, I'm very happy with the new (current) layout we have right now. I would say I find the following use case very confusing for newcomers: - Install emacs package via Guix. - Use built-in help C-h C-h, find C-h P. - Get it to work for built-in packages, but not for packages installed by Guix. - Get frustrated. I think we could avoid this at least in two ways: 1. Use elpa/ subdirectory. 2. Keep current structure, set package-directory-list to .../site-lisp instead of .../site-lisp/elpa by default. > Thus we're not trying to keep in line with any specific package > manager, we just need to make things work "with Emacs" in the sense > that packages installed via Guix should have working autoloads and one > should be able to (require ...) them. Yes, but at the same time I don't see reasons why not to implement one of two options above. We can get both: working autoloads and working built-in help function (+newcommers won't be so frustrated). Personally, I'm quite happy that packages got their own subdirectories and I'm fully satisfied with current state of it, but it would be cool if inexperienced users will be able to use at least built-in help commands for packages out of the box without additional configuration. Hope my original point is a little better worded now. -- Best regards, Andrew Tropin
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
> > M-x list-packages ;; Doesn't list treemacs > Let me recommend Emacs-Guix (aka. 'guix.el') as a superior alternative. > :-) Sure) Aware of it, cool tool. > I think it's fine that 'package.el' is unaware of Guix-managed software > and vice-versa. Yep, perfectly fine, but why not to make it aware, if it is relatively easy to achieve?)
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Am Mittwoch, den 19.05.2021, 17:32 +0300 schrieb Andrew Tropin: > > > Most other package managers seem to respect "infrastructure" > > > provided by package.el. > > I don't think that statement is well-supported by the data we have. > > Agree, that was an incorrect statement. I should have said something > like: there are some popular tools like use-package configuration > helper, Nix package manager, Spacemacs configuration framework, some > elisp archives and probably something else, which utilize and follow > package.el. Not all of them use package.el itself, but they follow > conventions and describe-package help command and some other work > correctly. Is package.el really so well supported by all these tools? I might concede, that some of them don't throw away the package.el blurb like guix does, but other than that, I think you'd have a hard time stuffing a random git repo from use-package into package.el. Am I missing something? > > Why should we let ELPA dictate our layout? I have not even once > > tried customizing package.el for actual use since I got Guix, > > because the elpa importer is trivial. > > We don't have to. Actually, I'm very happy with the new (current) > layout we have right now. That's good :) > I would say I find the following use case very confusing for > newcomers: > - Install emacs package via Guix. > - Use built-in help C-h C-h, find C-h P. > - Get it to work for built-in packages, but not for packages > installed by Guix. > - Get frustrated. You mean Emacs newcomers? Tell me something new about the first-time Emacs experience :P > I think we could avoid this at least in two ways: > 1. Use elpa/ subdirectory. > 2. Keep current structure, set package-directory-list to .../site- > lisp instead of .../site-lisp/elpa by default. Neither sounds very pleasant, but does (2) even work? > > Thus we're not trying to keep in line with any specific package > > manager, we just need to make things work "with Emacs" in the sense > > that packages installed via Guix should have working autoloads and > > one should be able to (require ...) them. > > Yes, but at the same time I don't see reasons why not to implement > one of two options above. We can get both: working autoloads and > working built-in help function (+newcommers won't be so frustrated). Of course. The glue code for that would go into guix-emacs.el, just like our autoload glue. > Personally, I'm quite happy that packages got their own > subdirectories and I'm fully satisfied with current state of it, but > it would be cool if inexperienced users will be able to use at least > built-in help commands for packages out of the box without additional > configuration. > > Hope my original point is a little better worded now. Doing something in Emacs without configuration sounds like an oxymoron, but I get your point. At the same time, I think that this kind of change is a pretty large request (DPD has more than 100 lines not counting dependencies, it's not small and neat like guix-emacs.el). If you find a clever trick to make your troubles go away, do submit a patch, but don't let it rely on user setup (in particular, don't rely on "haha, the user always carries about the elpa subdirectory"). Regards, Leo
bug#48521: opendht-service-type hangs Shepherd at boot
Hello, I just noticed about this problem following a reboot. I can also reproduce it in 'guix system vm', simply adding the opendht-service-type to my operating-system declaration. The boot proceeds until 'error in finalization thread: Success' then hangs indefinitely. What is troubling for me is that the service is rather straightforwardly defined. It uses the make-forkexec-constructor/container like so: --8<---cut here---start->8--- (define (opendht-shepherd-service config) "Return a running OpenDHT." (shepherd-service (documentation "Run an OpenDHT node.") (provision '(opendht dhtnode dhtproxy)) (requirement '(user-processes syslogd)) (start #~(make-forkexec-constructor/container (list #$@(opendht-configuration->command-line-arguments config)) #:mappings (list (file-system-mapping (source "/dev/log") ;for syslog (target source))) #:user "opendht")) (stop #~(make-kill-destructor --8<---cut here---end--->8--- I'm not sure how using such basic building blocks could lead to a hang in Shepherd ? Thanks, Maxim
bug#48519: texlive-bin cannot be installed in a profile
raid5atemyhomework writes: In recent commits, `texlive-bin` cannot be installed in a profile. […] ***Is*** this an issue? Yes. The problem is that the texlive-configuration profile hook is hooked to texlive-bin instead of texlive-base (which includes texlive-bin). I’ve been meaning to change that but haven’t gotten around to doing this. -- Ricardo
bug#48520: rav1e 0.3.5 is not reproducible
`guix describe` outputs: ``` Generation 24 May 12 2021 18:06:24(current) guix d6aeebb repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d6aeebb23639258311fdfb9dbf5f903079fde51a ``` `guix challenge /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5` outputs: ``` /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5 contents differ: local hash: 0lr47rfaq41yn3sbf86xnwpsrgvi38ifi3hx5dz3cm5iinfwaxc0 https://ci.guix.gnu.org/nar/lzip/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5: 17g58f754k0n5hwiysb88cz9fg82di2j244zzh9mnv6a172y4xjb differing file: /share/cargo/registry/rav1e-0.3.5.crate 1 store items were analyzed: - 0 (0.0%) were identical - 1 (100.0%) differed - 0 (0.0%) were inconclusive ``` `guix challenge --diff=diffoscope /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5` outputs: ``` /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5 contents differ: local hash: 0lr47rfaq41yn3sbf86xnwpsrgvi38ifi3hx5dz3cm5iinfwaxc0 https://ci.guix.gnu.org/nar/lzip/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5: 17g58f754k0n5hwiysb88cz9fg82di2j244zzh9mnv6a172y4xjb --- /tmp/guix-directory.3zSn14 +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5 │ --- /tmp/guix-directory.3zSn14/share ├── +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share │ │ --- /tmp/guix-directory.3zSn14/share/cargo │ ├── +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share/cargo │ │ │ --- /tmp/guix-directory.3zSn14/share/cargo/registry │ │ ├── +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share/cargo/registry │ │ │ │ --- /tmp/guix-directory.3zSn14/share/cargo/registry/rav1e-0.3.5.crate │ │ │ ├── +++ /gnu/store/cdhgn2y3xzmbxfzkzzlm9fb7q70paxvz-rav1e-0.3.5/share/cargo/registry/rav1e-0.3.5.crate │ │ │ │ ├── rav1e-0.3.5.crate-content │ │ │ │ │ ├── file list │ │ │ │ │ │ @@ -1,9 +1,9 @@ │ │ │ │ │ │ --rw-r--r-- 00039196 2021-04-03 18:35:22.00 rav1e-0.3.5/Cargo.lock │ │ │ │ │ │ --rw-r--r-- 000 4228 2021-04-03 18:35:22.00 rav1e-0.3.5/Cargo.toml │ │ │ │ │ │ +-rw-r--r-- 00039196 2021-04-21 15:38:10.00 rav1e-0.3.5/Cargo.lock │ │ │ │ │ │ +-rw-r--r-- 000 4228 2021-04-21 15:38:10.00 rav1e-0.3.5/Cargo.toml │ │ │ │ │ │ -rw-r--r-- 0 9993 4228 2020-12-31 14:44:40.00 rav1e-0.3.5/Cargo.toml.orig │ │ │ │ │ │ -rw-r--r-- 0 9993 1332 2020-11-16 12:40:01.00 rav1e-0.3.5/LICENSE │ │ │ │ │ │ -rw-r--r-- 0 9993 5702 2017-09-24 10:10:31.00 rav1e-0.3.5/PATENTS │ │ │ │ │ │ -rw-r--r-- 0 9993 5820 2020-12-31 12:00:53.00 rav1e-0.3.5/README.md │ │ │ │ │ │ -rw-r--r-- 0 9993 4333 2020-12-31 12:00:53.00 rav1e-0.3.5/build.rs │ │ │ │ │ │ -rw-r--r-- 0 9993 423 2020-12-31 12:00:53.00 rav1e-0.3.5/cbindgen.toml │ │ │ │ │ │ -rw-r--r-- 0 9993 3579 2020-12-31 12:00:53.00 rav1e-0.3.5/src/activity.rs 1 store items were analyzed: - 0 (0.0%) were identical - 1 (100.0%) differed - 0 (0.0%) were inconclusive ```
bug#48519: texlive-bin cannot be installed in a profile
In recent commits, `texlive-bin` cannot be installed in a profile. This can be
replicated by doing:
guix pull
guix install texlive-bin
Or with a specific recent commit:
guix time-machine --commit=b7c7a61 -- install -p tmp texlive-bin
Note that it fails at the "building Tex Live configuration" phase; `guix build
texlive-bin` builds perfectly fine, it is the installing of the package into
*any* profile which fails.
However, in a previous commit a few weeks ago, `texlive-bin` *could* be
installed into a profile:
guix time-machine --commit=131265e -- install -p tmp texlive-bin # Succeeds
So, doing a `git bisect` between those two commits, I got to this commit:
```git
commit a6b8794c69446730b5f12eb8eefc5ef3b99c97dc
Author: Ricardo Wurmus
Date: Mon May 3 15:34:46 2021 +0200
profiles: texlive-configuration: Refresh font maps.
* guix/profiles.scm (texlive-configuration): Run updmap to generate font
maps
necessary for pdflatex and other tools.
guix/profiles.scm | 51 ---
1 file changed, 48 insertions(+), 3 deletions(-)
```
Its direct parent can install `texlive-bin` perfectly fine:
guix time-machine --commit=eb930be -- install -p tmp texlive-bin # Succeeds
The above commit fails:
guix time-machine --commit=a6b8794 -- install -p tmp texlive-bin # Fails
The specific error when constructing the profile is this:
```
updmap: open() failed: No such file or directory at
/gnu/store/jy61rq7jhiqwjcmm4agr2hpk3f7ggnks-texlive-bin-20190410/bin/updmap
line 2153.
updmap [ERROR]: The following map file(s) couldn't be found:
updmap [ERROR]: dvips35.map (in builtin)
updmap [ERROR]: pdftex35.map (in builtin)
updmap [ERROR]: ps2pk35.map (in builtin)
updmap [ERROR]: Did you run mktexlsr?
You can disable non-existent map entries using the option
--syncwithtrees.
Backtrace:
2 (primitive-load "/gnu/store/zxqc1b3asn8n7fd20815scdmp53?")
In ice-9/eval.scm:
619:8 1 (_ #f)
In guix/build/utils.scm:
654:6 0 (invoke _ . _)
guix/build/utils.scm:654:6: In procedure invoke:
ERROR:
1. :
program:
"/gnu/store/jy61rq7jhiqwjcmm4agr2hpk3f7ggnks-texlive-bin-20190410/bin/updmap-sys"
arguments:
("--cnffile=/gnu/store/5bzfkhncqa507c9zmp7sljssdxr9g08f-texlive-configuration/share/texmf-config/web2c/updmap.cfg"
"--dvipdfmxoutputdir=/gnu/store/5bzfkhncqa507c9zmp7sljssdxr9g08f-texlive-configuration/share/texmf-dist/fonts/map/updmap/dvipdfmx/"
"--dvipsoutputdir=/gnu/store/5bzfkhncqa507c9zmp7sljssdxr9g08f-texlive-configuration/share/texmf-dist/fonts/map/updmap/dvips/"
"--pdftexoutputdir=/gnu/store/5bzfkhncqa507c9zmp7sljssdxr9g08f-texlive-configuration/share/texmf-dist/fonts/map/updmap/pdftex/")
exit-status: 1
term-signal: #f
stop-signal: #f
```
I don't know how to debug this further, unfortunately.
***Is*** this an issue? It seems I can just remove `texlive-bin` and still
have `pdflatex` and co working on my profile.
Thanks
raid5atemyhomework
