bug#63920: Emacs Packages should have an output built with emacs-next(-minimal)
Hello dear Guix community, if I understand correctly, all Emacs-packages that are packaged in Guix proper, are built with Emacs version 28 (or more precisely, emacs-minimal@28, emacs@28, emacs-no-x@28, emacs-no-x-toolkit@28 or emacs-wide-int@28 (except emacs-jsdoc which is and needs to be built with emacs-next@29)). (You may grep the Guix repository for ":emacs" to find out by yourself.) When using these Emacs-packages with emacs-next* (i.e. version 29 or 30), this can lead to misbehavior because Emacs will still prefer the compiled .elc or .eln files which may depend on version 28 specifics. My concrete experience is that, when using emacs-next-tree-sitter and emacs-consult packages, evaluating (require 'consult-register) fails because it has emacs-major-version-specific code: https://github.com/minad/consult/blob/3c0f87ebd20b25f03568fb9ef8fd36b5a2a6eb84/consult-register.el#L82 (A workaround is to instead evaluate (load "consult-register.el").) I propose: 1. Introduce a package emacs-next-minimal. 2. For all Emacs-packages, create one output corresponding to each Emacs major-version packaged in Guix proper. For example, the output "emacs-next" would be built with emacs-next-minimal. What do you think? I'd guess this should be hard to implement, right? Kindly Mekeor
bug#63904: Can't setuid programs to anybody but root
Dear Guix, CCing the core team,
I tried tracking down the bug.
The fatidic call to getpw was easy enough to find:
The make-setuid-program procedure is given a numeric uid argument. This
numeric uid is found from the user name string by
activate-setuid-program which calls getpwnam
(gnu/build/activation.scm:317).
Now this gave me an idea to sidestep the bug: See below the modified
part of the minimal reproductible example: I just force-assign a uid to
the user I want to setuid to, and give this uid instead of the username
to the setuid record.
This is cumbersome, but it does the job: the call to getpw is averted
and I get a system in which I can setuid to somebody other than root.
However, I'm lost as to how to solve the bug for good. I tried to
understand the call stack, but I can't figure out how in the folding
service machinery the services are ordered. My intuition is that I need
to make it so the folding of non-root setuids happen after the folding
of user and groups (I also have the intuition that root-setuids must
happen before, because folding users and group may require that root
setuid binaries are there, but I have not been able to verify that).
Here is what I was able to find.
getpw is called by activate-setuid-program
activate-setuid-program is called in setuid-program->activation-gexp
setuid-program->activation-gexp is the activation procedure for
setuid-program-service-type
setuid-program-service-type is itself an extension of activation-service-type
I'm trying to follow how the service DAG is constructed, and then
walked, from there, but I don't think I have a very clear model of how
it works in my head.
I think the devil may be in:
(define (compute-boot-script _ gexps)
;; Reverse GEXPS so that extensions appear in the boot script in the right
;; order. That is, user extensions would come first, and extensions added
;; by 'essential-services' (e.g., running shepherd) are guaranteed to come
;; last.
(gexp->file "boot"
;; Clean up and activate the system, then spawn shepherd.
#~(begin #$@(reverse gexps
Any help there would be greatly appreciated.
Thanks in advance,
Cheers,
Edouard.
(operating-system
(host-name "minimal-container")
(timezone "UTC")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader grub-bootloader)))
(file-systems %base-file-systems)
(users (cons
(user-account
(name "suc")
(group "users")
(uid 1042))
%base-user-accounts))
(setuid-programs
(cons (setuid-program (program (file-append coreutils "/bin/true"))
;; (user "suc")
(user 1042)
)
%setuid-programs))
(packages %base-packages)
(services %base-services))
e...@beaver-labs.com writes:
> Dear Guix developers,
>
> At the end of the email is the code for a minimal container, which tries
> to setuid =true=, the simplest binary of all, to user suc.
>
> When line 26 is commented, and the container is built and run with:
> sudo $(guix system container mwe.scm)
>
> One can login to the container and run:
> ls -l /run/setuid-programs/true
>
> which yields:
> -r-sr-xr-x 1 root root 39488 Jun 5 09:59 /run/setuid-programs/true
> as it should.
>
> Also, one can fire up guile and run (getpw "suc") and get in return:
> $1 = #("suc" "x" 1000 998 "" "/home/suc"
> "/gnu/store/m6c5hgqg569mbcjjbp8l8m7q82ascpdl-bash-5.1.16/bin/bash")
>
> However, when line 26 is uncommented, the container can be built, but
> when run fails with the error below.
> My hunch is that things are done out of order, with setuid binaries
> being set up before user creation, but I have no way of checking that.
>
> Please do not hesitate to ping me if I can be of help.
>
> Cheers,
>
> Edouard.
>
> The error:
> system container is running as PID 9825
> WARNING: (guile-user): imported module (guix build utils) overrides core
> binding `delete'
> Run 'sudo guix container exec 9825 /run/current-system/profile/bin/bash
> --login'
> or run 'sudo nsenter -a -t 9825' to get a shell into it.
>
> WARNING: (guile-user): imported module (guix build utils) overrides core
> binding `delete'
> making '/gnu/store/mnc9lfpn01frmffqa31jy3c381dkgrwl-system' the current
> system...
> WARNING: (guile-user): imported module (guix build utils) overrides core
> binding `delete'
> setting up setuid programs in '/run/setuid-programs'...
> Backtrace:
> 12 (primitive-load "/gnu/store/bygckv7p4091xqykjnkay4qnazn…")
> In gnu/build/linux-container.scm:
> 300:8 11 (call-with-temporary-directory #)
>397:16 10 (_ "/tmp/guix-directory.B9dmTN")
> 62:6 9 (call-with-clean-exit #)
> In unknown file:
>8 (primitive-load "/gnu/store/mnc9lfpn01frmffqa31jy3c381d…")
> In ice-9/eval.scm:
> 619:8 7 (_ #f)
> In unknown file:
>6 (primitive-load "/gnu/store/dib6wfh2r52dfaydz78n33267qx…")
> In srfi/srfi-1.scm:
>
bug#63921: Activation snippets in reverse order, prevent boot
Booting a system reconfigured from eed55a6544d5bda2245ec853e5fa4b28e1865bea fails with shepherd saying: error: while opening socket '/var/run/shepherd/socket': Address already in use The root cause appears to be that the ‘boot’ program has expressions reversed: --8<---cut here---start->8--- $ guix gc --references $(guix gc --derivers $(readlink -f /var/guix/profiles/system-236-link)) | grep boot /gnu/store/21ldhyrpji6lkkdxi4lgr5k9l5fr2b7l-boot.drv $ cat $(guix build /gnu/store/21ldhyrpji6lkkdxi4lgr5k9l5fr2b7l-boot.drv) (eval-when (expand load eval) (let ((extensions (quote ())) (prepend (lambda (items lst) (let loop ((items items) (lst lst)) (if (null? items) lst (loop (cdr items) (cons (car items) (delete (car items) lst (set! %load-path (prepend (cons "/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import" (map (lambda (extension) (string-append extension "/share/guile/site/" (effective-version))) extensions)) %load-path)) (set! %load-compiled-path (prepend (cons "/gnu/store/pql80c2hy38bb60c68sng74s4xa35vwk-module-import-compiled" (map (lambda (extension) (string-append extension "/lib/guile/" (effective-version) "/site-ccache")) extensions)) %load-compiled-path(begin (begin (false-if-exception (delete-file "/run/booted-system")) (symlink (canonicalize-path "/run/current-system") "/run/booted-system") (let loop ((fd 3)) (when (< fd 1024) (false-if-exception (let ((flags (fcntl fd F_GETFD))) (when (zero? (logand flags FD_CLOEXEC)) (fcntl fd F_SETFD (logior FD_CLOEXEC flags) (loop (+ fd 1 (execl "/gnu/store/wj5i6x3xgai7p8whwqybxwqdjdbmbzha-shepherd-0.10.99-git/bin/shepherd" "shepherd" "--config" "/gnu/store/gnjghlc3n5qbala5jfdslgfi0n3vy8v7-shepherd.conf")) (primitive-load "/gnu/store/riabgidmf6fh76klc1yam7k9j1478vvw-activate.scm") (begin (use-modules (guix build utils)) (letrec-syntax ((fail-safe (syntax-rules () ((_ exp rest ...) (begin (catch (quote system-error) (lambda () exp) (const #f)) (fail-safe rest ...))) ((_) #t (fail-safe (delete-file "/etc/group.lock") (delete-file "/etc/passwd.lock") (delete-file "/etc/.pwd.lock") (setenv "GUIX_LOCPATH" "/gnu/store/5fmqijrs5f7vx8mc2q2pmq26yvhb74sm-glibc-utf8-locales-2.35/lib/locale") (setlocale LC_CTYPE "en_US.utf8") (delete-file-recursively "/tmp") (delete-file-recursively "/var/run") (mkdir "/tmp") (chmod "/tmp" 1023) (mkdir "/var/run") (chmod "/var/run" 493) (delete-file-recursively "/run/udev/watch.old") --8<---cut here---end--->8--- Namely, (execl "…/bin/shepherd") comes before the cleanup expressions, which is why /var/run/shepherd/socket is still around when we boot. Ludo’.
bug#63921: Activation snippets in reverse order, prevent boot
Ludovic Courtès skribis: > Booting a system reconfigured from > eed55a6544d5bda2245ec853e5fa4b28e1865bea fails with shepherd saying: > > error: while opening socket '/var/run/shepherd/socket': Address already in > use > > The root cause appears to be that the ‘boot’ program has expressions > reversed: > > $ guix gc --references $(guix gc --derivers $(readlink -f > /var/guix/profiles/system-236-link)) | grep boot > /gnu/store/21ldhyrpji6lkkdxi4lgr5k9l5fr2b7l-boot.drv > $ cat $(guix build /gnu/store/21ldhyrpji6lkkdxi4lgr5k9l5fr2b7l-boot.drv) > (eval-when (expand load eval) (let ((extensions (quote ())) (prepend (lambda > (items lst) (let loop ((items items) (lst lst)) (if (null? items) lst (loop > (cdr items) (cons (car items) (delete (car items) lst (set! > %load-path (prepend (cons > "/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import" (map (lambda > (extension) (string-append extension "/share/guile/site/" > (effective-version))) extensions)) %load-path)) (set! %load-compiled-path > (prepend (cons > "/gnu/store/pql80c2hy38bb60c68sng74s4xa35vwk-module-import-compiled" (map > (lambda (extension) (string-append extension "/lib/guile/" > (effective-version) "/site-ccache")) extensions)) > %load-compiled-path(begin (begin (false-if-exception (delete-file > "/run/booted-system")) (symlink (canonicalize-path "/run/current-system") > "/run/booted-system") (let loop ((fd 3)) (when (< fd 1024) > (false-if-exception (let ((flags (fcntl fd F_GETFD))) (when (zero? (logand > flags FD_CLOEXEC)) (fcntl fd F_SETFD (logior FD_CLOEXEC flags) (loop (+ > fd 1 (execl > "/gnu/store/wj5i6x3xgai7p8whwqybxwqdjdbmbzha-shepherd-0.10.99-git/bin/shepherd" > "shepherd" "--config" > "/gnu/store/gnjghlc3n5qbala5jfdslgfi0n3vy8v7-shepherd.conf")) (primitive-load > "/gnu/store/riabgidmf6fh76klc1yam7k9j1478vvw-activate.scm") (begin > (use-modules (guix build utils)) (letrec-syntax ((fail-safe (syntax-rules () > ((_ exp rest ...) (begin (catch (quote system-error) (lambda () exp) (const > #f)) (fail-safe rest ...))) ((_) #t (fail-safe (delete-file > "/etc/group.lock") (delete-file "/etc/passwd.lock") (delete-file > "/etc/.pwd.lock") (setenv "GUIX_LOCPATH" > "/gnu/store/5fmqijrs5f7vx8mc2q2pmq26yvhb74sm-glibc-utf8-locales-2.35/lib/locale") > (setlocale LC_CTYPE "en_US.utf8") (delete-file-recursively "/tmp") > (delete-file-recursively "/var/run") (mkdir "/tmp") (chmod "/tmp" 1023) > (mkdir "/var/run") (chmod "/var/run" 493) (delete-file-recursively > "/run/udev/watch.old") > > Namely, (execl "…/bin/shepherd") comes before the cleanup expressions, > which is why /var/run/shepherd/socket is still around when we boot. Fixed in 181951207339508789b28ba7cb914f983319920f. The regression came from dbbc7e946131ba257728f1d05b96c4339b7ee88b, which led ‘modify-services’ to change the order of services (something I had completely overlooked while reviewing, apologies!). I ended up rewriting ‘modify-services’. Good news is we now have tests for this. Ludo’.
bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading
Hi, Christopher Baines skribis: > Ludovic Courtès writes: > >> Hi, >> >> Christopher Baines skribis: >> >>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and >>> (defined? (quote transient?)) (map (# ?) ?)). >>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression >>> (register-services (primitive-load "/gnu/st?") ?). >>> May 24 11:17:03 localhost shepherd[1]: Service host-name has been started. >>> May 24 11:17:03 localhost shepherd[1]: Service user-homes has been started. >>> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_hardlinks = 1 >>> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_symlinks = 1 >>> May 24 11:18:41 localhost shepherd[1]: Exiting shepherd... >>> May 24 11:18:46 localhost shepherd[1]: Grace period of 5 seconds is over; >>> sending -337 SIGKILL. >>> May 24 11:23:55 localhost shepherd[1]: Service root is not running. >> >> The grace period expiration thing is probably due to the fact that >> shepherd is no longer processing signals, as I described here: >> >> https://issues.guix.gnu.org/63736 >> >> Could you share all of /var/log/messages (possibly privately, and >> limiting to “shepherd” lines) starting from when the machine booted? >> I’d like to see if there are hints of something that went wrong. > > The machine is hamal (one of the HoneyComb's) and I've added a user for > you now and added the SSH key from maintenance.git. > > So you should be able to: ssh l...@hamal.cbaines.net Doesn’t work right now; anything in the logs? Ludo’.
bug#63368: Build coordiantor "Signals delivery fails constantly" crashes
Christopher Baines skribis: > I've seen this happen with the build coordinator agent now (on > milano-guix-1): > > 2023-06-02 18:59:55 2023-06-02 18:59:55 (DEBUG): > fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: checking the availability of build > inputs > 2023-06-02 18:59:55 2023-06-02 18:59:55 (INFO ): > fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: setup successful, building: > /gnu/store/7fbrli2a8nzn676q8gz2b0i0y0lr9nxv-r-quasr-1.40.0.drv > 2023-06-02 19:00:46 Signals delivery fails constantly at GC #55 > 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? Thanks, Ludo’.
bug#53580: shepherd's architecture
Hi Attila, Attila Lendvai skribis: > [forked from: bug#53580: /var/run/shepherd/socket is missing on an otherwise > functional system] > >> So I think we’re mostly okay now. The one thing we could do is load >> the whole config file in a separate fiber, and maybe it’s fine to keep >> going even when there’s an error during config file evaluation? >> >> WDYT? > > > i think there's a fundamental issue to be resolved here, and addressing that > would implicitly resolve the entire class of issues that this one belongs to. > > guile (shepherd) is run as the init process, and because of that it may not > exit or be respawn. but at the same time when we reconfigure a guix system, > then shepherd's config should not only be reloaded, but its internal state > merged with the new config, and potentially even with an evolved shepherd > codebase. Sorry to be direct: is there a concrete bug you’re reporting here? > i still lack a proper mental model of all this to succesfully predict what > will happen when i `guix system reconfigure` after i `guix pull`-ed my > service code, and/or changed the config of my services. What happens is that ‘guix system reconfigure’ loads new services into the running shepherd. New services simply get started; services for which a same-named service is already running instead get registered as a “replacement”, meaning that the new version of the service only gets started when the user explicitly runs ‘herd restart SERVICE’. Non-stop upgrades is ideal, but shepherd alone cannot do that. For instance, nginx supports that, and no init system could implement that on its behalf. Ludo’.
bug#63368: Build coordiantor "Signals delivery fails constantly" crashes
Ludovic Courtès writes: > Christopher Baines skribis: > >> I've seen this happen with the build coordinator agent now (on >> milano-guix-1): >> >> 2023-06-02 18:59:55 2023-06-02 18:59:55 (DEBUG): >> fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: checking the availability of >> build inputs >> 2023-06-02 18:59:55 2023-06-02 18:59:55 (INFO ): >> fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: setup successful, building: >> /gnu/store/7fbrli2a8nzn676q8gz2b0i0y0lr9nxv-r-quasr-1.40.0.drv >> 2023-06-02 19:00:46 Signals delivery fails constantly at GC #55 >> 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 signature.asc Description: PGP signature
bug#63712: Website/RefManual(Dev)/Brokenlink
Hi, Simon Tournier skribis: > On Sun, 28 May 2023 at 11:47, Ludovic Courtès wrote: >> Alexandros Prekates skribis: >> >>> 'Using the PIN-Entry' is dead link >>> https://guix.gnu.org/en/manual/devel/en/html_node/GNU-Privacy-Guard.html > > [...] > >> The link works fine in an Info browser though (provided both manuals are >> installed). > > In addition to this one, give a look at the ones in #29593 [1] > > 1: https://issues.guix.gnu.org/issue/29593 Is that an order? :-) Yeah these broken links are a problem. We can’t force others to host on-line copies of their manual, so I’m not sure what to do, apart from kindly telling them that this would be great. Thanks, Ludo’.
bug#63920: Emacs Packages should have an output built with emacs-next(-minimal)
Hi Mekeor, Am Dienstag, dem 06.06.2023 um 07:11 + schrieb Mekeor Melire: > Hello dear Guix community, > > if I understand correctly, all Emacs-packages that are packaged in > Guix proper, are built with Emacs version 28 (or more precisely, > emacs-minimal@28, emacs@28, emacs-no-x@28, emacs-no-x-toolkit@28 > or emacs-wide-int@28 (except emacs-jsdoc which is and needs to be > built with emacs-next@29)). (You may grep the Guix repository for > ":emacs" to find out by yourself.) Emacs packages other than emacs-minimal should be the exception rather than the norm. > When using these Emacs-packages with emacs-next* (i.e. version 29 > or 30), this can lead to misbehavior because Emacs will still > prefer the compiled .elc or .eln files which may depend on version > 28 specifics. It should not prefer the .eln files, which get put into a unique directory per Emacs – yes, that ought to include different versions of the emacs package itself built with inputs that had their hashes changed. In any case, the version number itself (28 vs 29) is enough to turn .eln loading away. For .elc, the behaviour is indeed as you described, but that's rather due to the fact that bytecode ought to be forward-compatible. The packages you describe below thus invoke (IIUC) undefined behaviour. > My concrete experience is that, when using emacs-next-tree-sitter > and emacs-consult packages, evaluating (require 'consult-register) > fails because it has emacs-major-version-specific code: > https://github.com/minad/consult/blob/3c0f87ebd20b25f03568fb9ef8fd36b5a2a6eb84/consult-register.el#L82 > > (A workaround is to instead evaluate (load > "consult-register.el").) > > I propose: > > 1. Introduce a package emacs-next-minimal. > > 2. For all Emacs-packages, create one output corresponding to each > Emacs major-version packaged in Guix proper. For example, the > output "emacs-next" would be built with emacs-next-minimal. > > What do you think? I'd guess this should be hard to implement, > right? This would unnecessarily complicate things over at emacs-build-system. Now, emacs-next-minimal itself might be worthwhile (I don't see a strong reason as to why, though), but since native compilation was introduced to Guix, the recommendation was to compile packages ahead of time rather than using the built-in JIT. To do so, add --with-input=emacs-minimal=emacs-next or use a semantically equivalent options->transformation. As for a long-term solution to the problem, I do think we could make the situation easier by providing dedicated alternatives (e.g. "emacs- next-consult") or using parameterized packages (which is a larger TODO than emacs-build-system, however). As a member of the emacs-team, I do have to sadly report that we have yet to start the most serious work for making emacs-next the new emacs. Cheers
bug#63546: nix-channel error: opening pseudoterminal master: No such device
You can have a look at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63893 which solves the problem. -- Retrieve my PGP public key: gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC Zihao signature.asc Description: PGP signature
bug#63869: [shepherd] `guix system reconfigure` forgets `herd disable mysrv`
Hi Ludovic, Ludovic Courtès writes: > Attila Lendvai skribis: > >> i turn off some services using `herd disable`. then i do a `guix >> system reconfigure`, and these services get enabled and started. >> >> i would expect the enabled/disabled state to be preserved across >> reconfigures. > > 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?). 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? -- Thanks, Maxim
bug#63934: sonnet uses hardcoded paths for hunspell dictionaries
In sonnet's source code, in src/plugins/hunspell/hunspellclient.cpp, we
have the following code snippet:
#ifdef Q_OS_WIN
maybeAddPath(QStringLiteral(SONNET_INSTALL_PREFIX "/bin/data/hunspell/"));
#else
maybeAddPath(QStringLiteral("/System/Library/Spelling"));
maybeAddPath(QStringLiteral("/usr/share/hunspell/"));
maybeAddPath(QStringLiteral("/usr/share/myspell/"));
#endif
This is probably why sonnet can't find any hunspell dictionaries.
--
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#63936: mumi GraphQL endpoint errors out on non-existent issues
The mumi GraphQL endpoint errors out with an "Internal Server Error" when queried for an issue that does not exist. It should error out with a meaningful error response.
bug#63937: feature request: add or document ability to write to /etc/default/grub from grub service
I want to implement grub fallback on boot failure for a remote machine
so I need to write this to /etc/default/grub
export GRUB_FALLBACK="1 2...{number of entries}"
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
Thanks
