bug#75080: guix pull fails on arm64 due to cmake DEB self-tests
Hi, Simon Josefsson skribis: > I get a build failure regarding "cmake-bootstrap" shown here: > > https://gitlab.com/debdistutils/guix/container/-/jobs/8717616613 > > I cannot reproduce this on my own arm64 machine running Trisquel. > > It seems only cmake's DEB related self-tests fail: Looks like the problem is gone with a current-ish commit since substitutes are available from both build farms: --8<---cut here---start->8--- $ guix weather cmake-minimal -s aarch64-linux computing 1 package derivations for aarch64-linux... looking for 1 store items on https://ci.guix.gnu.org... https://ci.guix.gnu.org ☀ 100.0% substitutes available (1 out of 1) at least 10.6 MiB of nars (compressed) 27.7 MiB on disk (uncompressed) 2.815 seconds per request (2.8 seconds in total) 0.4 requests per second at least 1,000 queued builds aarch64-linux: 993 (99.3%) x86_64-linux: 4 (.4%) powerpc64le-linux: 2 (.2%) i686-linux: 1 (.1%) build rate: 545.79 builds per hour x86_64-linux: 545.79 builds per hour looking for 1 store items on https://bordeaux.guix.gnu.org... https://bordeaux.guix.gnu.org ☀ 100.0% substitutes available (1 out of 1) 4.5 MiB of nars (compressed) 27.7 MiB on disk (uncompressed) 0.150 seconds per request (0.2 seconds in total) 6.7 requests per second (continuous integration information unavailable) looking for 1 store items on https://guix.bordeaux.inria.fr... https://guix.bordeaux.inria.fr ⛈ 0.0% substitutes available (0 out of 1) unknown substitute sizes 0.0 MiB on disk (uncompressed) 0.169 seconds per request (0.2 seconds in total) 5.9 requests per second 0.0% (0 out of 1) of the missing items are queued 0 queued builds build rate: 17.09 builds per hour x86_64-linux: 17.09 builds per hour $ guix describe Generation 331 Jan 05 2025 22:28:17(current) shepherd 6d52686 repository URL: https://git.savannah.gnu.org/git/shepherd.git branch: main commit: 6d526862375a426c13a52c7343c0ee9215367a00 guile f6359a4 repository URL: https://git.savannah.gnu.org/git/guile.git branch: main commit: f6359a4715d023761454f1bf945633ce4cca98fc guix 613c8b8 repository URL: https://git.savannah.gnu.org/git/guix.git commit: 613c8b81702f08ee36f20d15ee8f8c42a37acfef --8<---cut here---end--->8--- Could you confirm? Ludo’.
bug#67292: emacs / emacs-transient collisions and bundling
On 2024-12-20 20:23, Suhail Singh wrote: > V2 looks good; works as expected. Tested with emacs-org, emacs-magit, > emacs-transient. Tested with emacs-dape too, which didn't work properly too. -- Best regards, Nicolas Graves
bug#71065: Emacs packages that override built-in features ignored when compiled
Hi Jelle, I think this issue is fixed with the patches in 67292. Can you try them and merge or close this issue after that? Thanks! -- Best regards, Nicolas Graves
bug#70211: emacs-eglot fails after upgrade to emacs-29.3
Hi guys, I think this issue is fixed with the patches in 67292. Can you try them and merge or close this issue after that? Thanks! -- Best regards, Nicolas Graves
bug#75460: herd status hangs forever
Hi, Simen Endsjø skribis: > On one of my systems, `herd status` just hangs forever. > `sudo herd status` works as expected, and I'm able to start and stop > services as normal, just not list them. The former talks to your user shepherd (perhaps you’re using Guix Home?) whereas the latter talks to the system shepherd (PID 1). What you seem to be saying here is that your user shepherd is buggy. > I understand this is not much to debug based on -- any idea how I can > get more detailed information? Can you say which shepherd version you’re using, for your user shepherd? You can find out by running “cat /proc/PID/cmdline | xargs -0” for its PID, or by checking ~/.local/state/shepherd/shepherd.log (version 1.0.x prints its version string there at startup but previous versions didn’t.) Then please check precisely what hangs and what doesn’t. You say “herd status” hangs; what about “herd status X”, where X is a service defined for your user shepherd? Last, could you share the config file of your user shepherd, or maybe the Guix Home config if that’s what you’re using? Thanks in advance, Ludo’.
bug#75288: gnu: xfce4-session: xflock4 fails to run.
Ashvith Shetty writes: > Hello, > > Lock does not work anymore on XFCE 4.20, after moving from 4.18. > When I try to run the command manually via the terminal on XFCE 4.20, this is > what I get: > > ```console > $ xflock4 > /gnu/store/yz669dvm1cm9nqcxkm8hq8zzgf0cy96f-profile/bin/xflock4: line 52: > gdbus: command not found > ``` > This must be because of the introduction of commit 42db188a somewhere around > 4.19, making xflock4 dependent on D-Bus. > > Regards, > Ashvith Should be fixed in master now, thank you for the report! Need do a system reconfigure with xfce-desktop-service-type, which add '/etc/pam.d/xfce4-screensaver' for 'xfce4-screensaver'.
