bug#56376: emacs-guix missing from package-activated-list
Am Sonntag, dem 03.07.2022 um 21:33 -0400 schrieb Philip McGrath: > Hi, > > I've been looking into managing my Emacs packages with Guix. I found > that the `emacs-guix` package doesn't seem to show up in the > `package-activated-list`, even though its dependencies do, which > seems like a bug. This might be related to the fact that Emacs doesn't see guix as a package. I think the recipe might be missing the -pkg.el autogeneration we added to emacs-build-system.
bug#54014: guix home pinentry weirdness
On 2022-02-15 13:46, Zacchaeus Scheffer wrote: > Hi Guix, > > There seems to be some problem installing password-store + pinentry > entirely via guix home. When I have both installed as such, I get the > following outputs: > > $ pinentry > OK Pleased to meet you > > $ gpg --import ... > [prompts normally with pinentry, allows me to import] > $ pass > [my password entries] > $ pass [entry name] > gpg: decryption failed: No secret key > $ guix package -i pinentry > $ pass [entry name] > [prompts with pinentry and works normally] > > So pinentry and pass seem to both be available, but don't work together > unless I install pinentry via guix package. > > My guix install is about two months behind, so sorry if this has already > been patched. > > -Zacchaeus I suspect that the problem is that someone at some moment of time doesn't have ~/.guix-home/profile/bin in its $PATH and thus it can't find a pinentry. Can you show `which gpg`, `which pass`, `which pinentry`? The gnupg home service from rde project goes a slightly other way and just sets pinentry-program to absolute path in the store. Such approach works with pass well, you can take a look at it for inspiration: https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/gnupg.scm#L127 -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#56371: Can't remove a package present in profil
It's not a bug, because you don't have icedtea in your profile, but icedtea:jdk. Guix is picky with outputs. Try "guix remove icedtea:jdk" :) On July 3, 2022 7:25:46 PM GMT+02:00, bbb ee wrote: >Hi, > >I have icedtea installed in my current profil, but `guix package remove` >doesn't find it. >``` >$ guix package -p ~/.guix-profile -I | grep icedtea >icedtea 3.19.0 jdk >/gnu/store/5k7lsz61p8fq37c9x5p9xalryjxk31bs-icedtea-3.19.0-jdk >$ guix package -p ~/.guix-profile -r icedtea >guix package: error: package 'icedtea' not found in profile >``` > >It is a bug?
bug#56376: emacs-guix missing from package-activated-list
Hi, I've been looking into managing my Emacs packages with Guix. I found that the `emacs-guix` package doesn't seem to show up in the `package-activated-list`, even though its dependencies do, which seems like a bug. Here's an illustration: ``` philip@avalon:/tmp/emacs-bug$ guix describe --format=channels (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git";) (branch "master") (commit "e069de452a2c923868f5137421b4b6349c38d754") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA") philip@avalon:/tmp/emacs-bug$ cat demo.el (require 'package) (package-initialize) (print package-activated-list) philip@avalon:/tmp/emacs-bug$ guix shell --pure --container emacs emacs-guix -- emacs --script demo.el Loading /gnu/store/7vpfhr5fzvyvnh62lj17b97q7vr0svjj-emacs-guix-0.5.2-5.c9aef52/share/emacs/site-lisp/guix-0.5.2-5.c9aef52/guix-autoloads.el (source)... Loading /gnu/store/4hnp17pjbvi3xirk9ygxzv5hb24c9ghk-emacs-bui-1.2.1/share/emacs/site-lisp/bui-1.2.1/bui-autoloads... Loading /gnu/store/gx62xcfnn7dw1ib88gzbvgbz255vrd9i-emacs-dash-2.19.1/share/emacs/site-lisp/dash-2.19.1/dash-autoloads... Loading /gnu/store/aqbcw5fjmsr4lndhpgs4bzgd58a16rkw-emacs-edit-indirect-0.1.8/share/emacs/site-lisp/edit-indirect-0.1.8/edit-indirect-autoloads... Loading /gnu/store/sic558dq3rlcx6d0f1h7pq6cq1mkliaz-emacs-geiser-0.23.2/share/emacs/site-lisp/geiser-0.23.2/geiser-autoloads... Loading /gnu/store/qc3b61ygmgpnhssy4yvk4a66xcd81kss-emacs-project-0.8.1/share/emacs/site-lisp/project-0.8.1/project-autoloads... Loading /gnu/store/6al6nhnkxkgznh7fla8rsyis8cxywz6l-emacs-xref-1.4.1/share/emacs/site-lisp/xref-1.4.1/xref-autoloads... Loading /gnu/store/g2b2bagb3p1vw57kxgry7pnh32grl4d0-emacs-transient-0.3.7/share/emacs/site-lisp/transient-0.3.7/transient-autoloads... Loading /gnu/store/dacdgzvhn1n4j8dcac6d67vnc9fnlmym-emacs-geiser-guile-0.23.2/share/emacs/site-lisp/geiser-guile-0.23.2/geiser-guile-autoloads... Loading /gnu/store/l7qm8v9pnpadllxyr6g348a4knfj4x42-emacs-magit-popup-2.13.3/share/emacs/site-lisp/magit-popup-2.13.3/magit-popup-autoloads... (bui edit-indirect xref geiser-guile geiser magit-popup dash) ``` signature.asc Description: This is a digitally signed message part.
bug#56373: Updating synapse (Matrix Homeserver) Because it is Broken
Hi Guix! I'm trying to update synapse because it seems an update somewhere has broken synapse (I'm thinking python -> 3.9.*?). Specifically, I get the following traceback: $ synctl start .config/synapse/homeserver.yaml --no-daemonize Starting ... Traceback (most recent call last): File "/gnu/store/z561ps804hs0shwicdw076wwg4mim8ml-python-3.9.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main return _run_code(code, main_globals, None, File "/gnu/store/z561ps804hs0shwicdw076wwg4mim8ml-python-3.9.9/lib/python3.9/runpy.py", line 87, in _run_code exec(code, run_globals) File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/app/homeserver.py", line 45, in from synapse.federation.transport.server import TransportLayerServer File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/federation/transport/server.py", line 46, in from synapse.server import HomeServer File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/server.py", line 55, in from synapse.events.spamcheck import SpamChecker File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/events/spamcheck.py", line 20, in from synapse.rest.media.v1._base import FileInfo File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/rest/__init__.py", line 32, in from synapse.rest.client.v2_alpha import ( File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/rest/client/v2_alpha/account.py", line 40, in from synapse.push.mailer import Mailer File "/gnu/store/sgxq33kpvbc56j1ag0rwhj3f9w16wfz0-synapse-1.29.0/lib/python3.9/site-packages/synapse/push/mailer.py", line 860, in def safe_markup(raw_html: str) -> jinja2.Markup: AttributeError: module 'jinja2' has no attribute 'Markup' error starting (exit code: 1); see above for logs No logs are saved because the code crashes before it can get to that. A quick search brought me to https://github.com/YunoHost-Apps/synapse_ynh/issues/304 which indicates that the problem is expected and fixed in later versions. It seems matrix abstracted some code to a new repository, as just increasing the synapse version number causes it to fail as it looks for a library: "matrix-common". My current working definition for matrix-common is: (define-public python-matrix-common (package (name "python-matrix-common") (version "1.2.0") ; tried 1.2.1 and 1.2.0 (source (origin (method url-fetch) (uri (pypi-uri "matrix_common" version)) (sha256 (base32 "0lrqzb6s57fxp0kwffdqnkr2pj9aia459cv1b95b55dxlq1cz7d9" ;"1bgdhzvqs51z079zjszhd5xqb100mbr5w8gpxs9z31r5xmi5nw7a" (build-system python-build-system) (arguments `(#:use-setuptools? #f ; tried with and without this #:phases (modify-phases %standard-phases (replace 'build (lambda _ (setenv "SOURCE_DATE_EPOCH" "315532800") (invoke "python" "-m" "build" "--wheel" "--no-isolation" "."))) (delete 'check) (replace 'install (lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out")) (whl (car (find-files "dist" "\\.whl$" (invoke "pip" "--no-cache-dir" "--no-input" "install" "--no-deps" "--prefix" out whl (delete 'sanity-check (propagated-inputs (list)) (native-inputs (list python-pypa-build python-attrs)) (home-page "https://github.com/matrix-org/matrix-python-common";) (synopsis "Common utilities for Synapse, Sydent and Sygnal") (description "") (license license:asl2.0))) The matrix-common library has no setup.py, hence I tried replacing the build and install phase with something similar to what was done for python-isort as suggested in the irc. I deleted check for now because it was looking for setup.py. This definition builds without printing errors. However, when I try to build synapse in v1.61.1 (adding python-matrix-common to the native-inputs), I get the following output: starting phase `check' running "python setup.py" with command "test" and parameters () running test WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox. WARNING: The wheel package is not available. WARNING: The directory '/homeless-shelter/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag. WARNING: Retrying (Retry(tota
bug#56371: Can't remove a package present in profil
Hi, I have icedtea installed in my current profil, but `guix package remove` doesn't find it. ``` $ guix package -p ~/.guix-profile -I | grep icedtea icedtea 3.19.0 jdk /gnu/store/5k7lsz61p8fq37c9x5p9xalryjxk31bs-icedtea-3.19.0-jdk $ guix package -p ~/.guix-profile -r icedtea guix package: error: package 'icedtea' not found in profile ``` It is a bug?
bug#56082: home: services: openssh: identity-file could be a list of strings.
Hi, Oleg Pykhalov skribis: > Currently ‘identity-file’ in ‘openssh-host’ record is a ‘maybe-string’, > but it could be a list, which generates a config like: > > Host example.org > … > IdentityFile ~/.ssh/id_rsa_1 > IdentityFile ~/.ssh/id_rsa_2 > IdentityFile ~/.ssh/id_rsa_3 I didn’t realize it was possible. Worth fixing! Thanks, Ludo’.
bug#56114: Guix does not have a documented general and practical procedure for lowering a single lowerable object to the /gnu/store/... string.
Hi Maxime, Maxime Devos skribis: > Seems like we are missing a general & documented & simple to use > 'lower-object-completely' (or maybe 'compile-object'?) procedure for > this ... And maybe also a ,build-object REPL command? How about the attached patch? Sample session: --8<---cut here---start->8--- scheme@(guile-user)> ,use(gnu packages base) scheme@(guile-user)> ,build coreutils $11 = "/gnu/store/y8933036ljrz4ah9zcph09nmvdmmv5sf-coreutils-8.32-debug" $12 = "/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32" scheme@(guile-user)> ,lower coreutils $13 = # /gnu/store/y8933036ljrz4ah9zcph09nmvdmmv5sf-coreutils-8.32-debug /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32 7f0ebaf821e0> scheme@(guile-user)> ,build (computed-file "foo" #~(begin (display "hi!\n")(mkdir #$output)(mkdir #$output:lib))) $14 = "/gnu/store/axij9bkg56xv3k1z0l20gd6b0swn14sy-foo-lib" $15 = "/gnu/store/h5s7k7m0fxk9n7q7729l3n4q7vyxnvpy-foo" scheme@(guile-user)> ,build (computed-file "foo" #~(begin (display "Goeden dag!\n")(mkdir #$output))) substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0% building /gnu/store/gplhka9g0bwv8b640zavw1z65y9zrvag-foo.drv... $16 = "/gnu/store/ynvga6gxwj68mmk8ddj3i9sjhavkqah1-foo" --8<---cut here---end--->8--- “lower” does what you would expect; “build” yields one value per output. If that works for you, I’ll update the manual accordingly, and we can always add more features (like build options) later on. Thoughts? Thanks, Ludo’. diff --git a/guix/monad-repl.scm b/guix/monad-repl.scm index aefabdeebb..15c10efe01 100644 --- a/guix/monad-repl.scm +++ b/guix/monad-repl.scm @@ -1,5 +1,5 @@ ;;; GNU Guix --- Functional package management for GNU -;;; Copyright © 2014, 2015, 2016 Ludovic Courtès +;;; Copyright © 2014, 2015, 2016, 2022 Ludovic Courtès ;;; ;;; This file is part of GNU Guix. ;;; @@ -21,6 +21,12 @@ (define-module (guix monad-repl) #:use-module (guix monads) #:use-module (guix utils) #:use-module (guix packages) + #:use-module (guix status) + #:autoload (guix gexp) (lower-object) + #:use-module ((guix derivations) +#:select (derivation? + derivation->output-paths built-derivations)) + #:use-module (ice-9 match) #:use-module (ice-9 pretty-print) #:use-module (system repl repl) #:use-module (system repl common) @@ -69,16 +75,56 @@ (define (store-monad-language store) #:guile-for-build guile) 'store-monad))) +(define %build-verbosity 1) + +(define* (evaluate/print-with-store mvalue #:key build?) + "Run monadic value MVALUE in the store monad and print its value." + (with-store store +(set-build-options store + #:print-build-trace #t + #:print-extended-build-trace? #t + #:multiplexed-build-output? #t) +(with-status-verbosity %build-verbosity + (let* ((guile (or (%guile-for-build) + (default-guile-derivation store))) + (values (run-with-store store + (if build? + (mlet %store-monad ((obj mvalue)) + (if (derivation? obj) + (mbegin %store-monad + (built-derivations (list obj)) + (return +(match (derivation->output-paths obj) + (((_ . files) ...) files + (return (list obj + (mlet %store-monad ((obj mvalue)) + (return (list obj + #:guile-for-build guile))) +(for-each (lambda (value) +(run-hook before-print-hook value) +(pretty-print value)) + values) + (define-meta-command ((run-in-store guix) repl (form)) "run-in-store EXP Run EXP through the store monad." - (with-store store -(let* ((guile (or (%guile-for-build) - (default-guile-derivation store))) - (value (run-with-store store (repl-eval repl form) - #:guile-for-build guile))) - (run-hook before-print-hook value) - (pretty-print value + (evaluate/print-with-store (repl-eval repl form))) + +(define-meta-command ((verbosity guix) repl (level)) + "verbosity LEVEL +Change build verbosity to LEVEL." + (set! %build-verbosity level)) + +(define-meta-command ((lower guix) repl (form)) + "lower OBJECT +Lower OBJECT into a derivation and return it." + (evaluate/print-with-store (lower-object (repl-eval repl form + +(define-meta-
bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?
Pierre Neidhardt skribis: > Robert Goldman from ASDF found out why the "COMPONENT not found" issue > happens: > > https://gitlab.common-lisp.net/asdf/asdf/-/issues/119#note_9808 > > So either we fix most of the Prove-depending libraries, or we just do > what's expected from every one, that is, add the directory to the ASDF > registries. > > The latter is much easier of course... As adding the build directory to ASDF's registry is easier and also simplifies asdf-build-system, would should do that. And we could still open issues upstream for libraries that are starting their test suites in a wrong way. signature.asc Description: PGP signature
bug#56353: sbcl-2.2.6 build fail
Guillaume Le Vaillant skribis: > b...@bokr.com skribis: > >> I wonder what running this at the time builds failed would have shown: >> >> #/usr/bin/bash >> # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes >> (no top opt for that??) >> top -n 1 | \ >> sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \ >> -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \ >> -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g' >> >> (no guarantees on my hack to get rid of the highlighting escapes >> and utf8->ascii quote subst :) >> (top seems to assume even -n 1 output is always going to interactive dest) >> >> Anyway, wondering: Could memory and CPU loading at the time >> have triggered the build failure? > > I don't think so. It looks like the SB-SIMD optional module only gets > built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and > Harbourfront machines don't, and this is why the 'build-doc' phase fails > when trying to load SB-SIMD to compile its documentation. > > I'm testing a patch disabling SB-SIMD, and I'll push it if all goes > well. Patch pushed as e0d2f8164e6a1c15fdcae6f7dadb05c0c9e25352. Closing. signature.asc Description: PGP signature
bug#56353: sbcl-2.2.6 build fail
b...@bokr.com skribis: > I wonder what running this at the time builds failed would have shown: > > #/usr/bin/bash > # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes > (no top opt for that??) > top -n 1 | \ > sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \ > -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \ > -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g' > > (no guarantees on my hack to get rid of the highlighting escapes > and utf8->ascii quote subst :) > (top seems to assume even -n 1 output is always going to interactive dest) > > Anyway, wondering: Could memory and CPU loading at the time > have triggered the build failure? I don't think so. It looks like the SB-SIMD optional module only gets built on x86_64 CPUs supporting AVX2 instructions. The Bayfront and Harbourfront machines don't, and this is why the 'build-doc' phase fails when trying to load SB-SIMD to compile its documentation. I'm testing a patch disabling SB-SIMD, and I'll push it if all goes well. signature.asc Description: PGP signature
bug#56353: sbcl-2.2.6 build fail
Hi, On +2022-07-02 20:26:40 +0100, Christopher Baines wrote: > > Guillaume Le Vaillant writes: > > > [[PGP Signed Part:Undecided]] > > Christopher Baines skribis: > > > >> Tobias Geerinckx-Rice via Bug reports for GNU Guix > >> writes: > >> > >>> On 2 July 2022 09:29:22 UTC, Wensheng Xie wrote: > Das Erstellungsprotokoll kann unter > „/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ > eingesehen werden. > >>> > >>> > >>> This log file is always a good idea to include. > >> > >> I think this is the equivalent non-grafted derivation: > >> > >> > >> https://data.guix.gnu.org/gnu/store/m7xw777v5agldb76gbqkqdvrrlj5d7zy-sbcl-2.2.6.drv > >> > >> There are plenty of failed builds on bordeaux.guix.gnu.org. I managed to > >> get it to build successfully once though on my laptop. > >> > >> Guillaume, any ideas if sbcl@2.2.6 is just really unlikely to build > >> successfully, or if there's particular conditions for it to build? > >> > >> Thanks, > >> > >> Chris > > > > According to the logs, the 'build-doc' phase fails to compile the > > documentation for SIMD related functions. There's a patch disabling this > > part of the doc unless we compile on x86_64, but maybe not all x86_64 > > CPUs have the required instructions... > > > > Would it be possible to get the result of "lscpu" on some machines where > > it fails? > > Sure, here is the lscpu output from the bayfront and harbourfront > machines. > [...] I wonder what running this at the time builds failed would have shown: --8<---cut here---start->8--- #/usr/bin/bash # ~/bin/top-1-sans-hilights -- single snap of top without highlight escapes (no top opt for that??) top -n 1 | \ sed -e 's:[\r][^\r]*[\r]\+::g' -e 's:[\x07\r]::g' -e 's:.\x08::g' \ -e 's:\x1B\[[^a-zA-Z]*[a-zA-Z]\x0f*::g' \ -e 's:\xe2\x80\x98:":g' -e 's:\xe2\x80\x99:":g' --8<---cut here---end--->8--- (no guarantees on my hack to get rid of the highlighting escapes and utf8->ascii quote subst :) (top seems to assume even -n 1 output is always going to interactive dest) Anyway, wondering: Could memory and CPU loading at the time have triggered the build failure? -- Regards, Bengt Richter
