bug#65809: [mumi] [wishlist] Allow searching subject prefix
Hi Gio, Thanks for this feature request! It's always gratifying to know that someone is using mumi, especially its more advanced features! :-) > IMO is useful to be able to search for "subject:foo", it's a different > search than searching for foo in the body It looks like we implement this already. See https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/xapian.scm#n141 A search for "subject:foo" should work already. Cheers! Arun
bug#65846: Request to merge emacs-team branch
Hi Guix, what's been promised some while ago in another thread is finally close™ to becoming reality: Emacs 29 on Guix with tree-sitter and all that stuff. I expect to merge the branch onto master within next week or the week after that. In the meantime, please use this thread to mark bugs and patches that you would like to see applied before that. Cheers
bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
I experience the same thing. I hadn't updated guix since may (last generation was commit 91bfd30ee3f35dfb7048bf42aea92f939cffbf17), and since I did I'm encountering issues with shepherd. Probably unrelated, but for the record: my first issue was caused by the disappearance of the XDG_LOG_HOME environment variable. I was using it in the definition of shepherd services (as for example `#:log-file (string-append (getenv "XDG_LOG_HOME") "/emacs-daemon.log")`. Guix home reconfigure worked because the getenv wasn't evaluated immediately, but after a reboot the syntax error prevented shepherd to start the session. But once I solved that, same problems: shepherd seems to hang somewhere after starting the home services. herd status: --8<---cut here---start->8--- Started: + root Starting: ^ emacs-daemon ^ ssh-agent ^ syncthing --8<---cut here---end--->8--- ~/.local/state/log/shepherd.log: --8<---cut here---start->8--- 2023-09-09 16:12:42 Service root started. 2023-09-09 16:12:42 Service root running with value #t. 2023-09-09 16:12:42 Service root has been started. 2023-09-09 16:12:42 Daemonizing... 2023-09-09 16:12:42 Restarting signal handler. 2023-09-09 16:12:42 Now running as process 430. 2023-09-09 16:12:42 Starting services... 2023-09-09 16:12:42 Configuration successfully loaded from '/gnu/store/mq01z0gvi1zv3skk6xh1q7g4id6hsgdk-shepherd.conf'. 2023-09-09 16:12:42 Starting service ssh-agent... 2023-09-09 16:12:42 Starting service syncthing... 2023-09-09 16:12:42 Starting service emacs-daemon... 2023-09-09 16:12:42 Service ssh-agent has been started. 2023-09-09 16:12:42 Service syncthing has been started. --- guix home reconfigure happened here --- 2023-09-09 16:59:00 Service emacs-daemon has been started. 2023-09-09 16:59:00 SSSL2023-09-09 16:59:00 oading /gnu/store/mlvqhkb37zy3yycriv3lmqah7yff34af-shepherd.conf. --8<---cut here---end--->8--- My 3 services are working normally. If I try to run `herd restart emacs-daemon`, the command hangs until I press Ctrl-C and nothing happens to emacs. Same thing for the other services (and for `herd stop`). Here's how my services are defined. If I comment out all occurrences of `home-shepherd-service-type` in my home configuration (not just commenting %emacs-daemon-user-service and running it with an empty list of services), then there is no error when running `guix home reconfigure`. --8<---cut here---start->8--- (define %emacs-daemon-user-service (shepherd-service (documentation "Run emacs-daemon.") (provision '(emacs-daemon)) (start #~(make-forkexec-constructor (list #$(file-append (specification->package %emacs-package) "/bin/emacs") "--fg-daemon") #:log-file (string-append #$(getenv "HOME") "/.local/var/log/emacs-daemon.log"))) (stop #~(make-system-destructor "emacsclient --eval \"(kill-emacs)\"")) (auto-start? #t) (respawn? #t))) (define-public emacs-services (list (simple-service 'emacs-shepherd-service home-shepherd-service-type (list %emacs-daemon-user-service (home-environment (services `(,@emacs-services […]))) --8<---cut here---end--->8--- When reconfiguring with an home-shepherd-service-type service but not shepherd service in the list: --8<---cut here---start->8--- Finished updating symlinks. Loading /gnu/store/26jgrxzmabjdl3nhjx16cqa1f5h3flks-shepherd.conf. herd: error: exception caught while executing 'load' on service 'root': In procedure fport_write: Broken pipe Comparing /gnu/store/4vmxyl8fykz9wkrkicnv5azhvr1gb5i1-home/profile/share/fonts and /gnu/store/3wlqdh4i4zmwjmqa69isr62nvbgf7abh-home/profile/share/fonts... done (same) Comparing /gnu/store/4vmxyl8fykz9wkrkicnv5azhvr1gb5i1-home/files/.config/fish/fish_plugins and /gnu/store/3wlqdh4i4zmwjmqa69isr62nvbgf7abh-home/files/.config/fish/fish_plugins... done (same) Evaluating on-change gexps. On-change gexps evaluation finished. --8<---cut here---end--->8--- Only new line in ~/.local/state/log/shepherd.log: --8<---cut here---start->8--- 2023-09-09 17:45:07 Loading /gnu/store/26jgrxzmabjdl3nhjx16cqa1f5h3flks-shepherd.conf. --8<---cut here---end--->8--- /gnu/store/26jgrxzmabjdl3nhjx16cqa1f5h3flks-shepherd.conf: --8<---cut here---start->8--- (begin (use-modules (srfi srfi-34) (system repl error-handling)) (apply register-services (map (lambda (file) (load file)) (quote ( (action (quote root) (quote daemonize)) (format #t "Starting services...~%") (let ((services-to-start (quote ( (if (defined? (quote start-in-the-background)) (start-in-the-background
bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.
Hello, Liliana Marie Prikler writes: > Am Sonntag, dem 03.09.2023 um 21:59 +0200 schrieb Liliana Marie > Prikler: >> Am Sonntag, dem 03.09.2023 um 10:51 -0400 schrieb Maxim Cournoyer: >> > Hi Liliana, >> > >> > Liliana Marie Prikler writes: >> > >> > [...] >> > >> > > Queued locally for emacs-next and followed up >> s/emacs-next/emacs-team/ > s/Queued locally/Pushed/ Thank you! -- Thanks, Maxim
bug#65740: No fallback to SWH for .guix-channel dependencies
Hi, On Fri, 08 Sep 2023 at 22:40, Ludovic Courtès wrote: >> This report is about two bugs: >> >> 1. transparent fallback to SWH for .guix-channel dependencies >> >> 2. pin all channels when running “guix describe”, even the ones from >>.guix-channel dependencies. > > #1 happens, but only when channels are pinned (returned by ‘guix > #describe’). > > Re #2, I don’t think there’s such a bug, is there? In the example > below, ‘guix describe’ shows 4 channels (including dependencies), not 2: My bad! I had probably not done what I always recommend: “guix describe“. Sorry for the noise. Cheers, simon
bug#65720: Guile-Git-managed checkouts grow way too much
Hi, On Fri, 08 Sep 2023 at 19:09, Ludovic Courtès wrote: >>> It would also be pretty bad for closure size: >>> >>> --8<---cut here---start->8--- >>> $ guix size guile-git | tail -1 >>> total: 106.6 MiB >>> $ guix size guile-git git-minimal | tail -1 >>> total: 169.8 MiB >>> --8<---cut here---end--->8--- >>> >>> It’s also not clear concretely how we’d add that dependency. Try >>> invoking ‘git’ from $PATH and print a warning if it doesn’t work? >>> But then, what about applications like Cuirass and hpcguix-web? >> >> I think we can rely on something like, >> >> guix shell -C git-minimal -- git gc > > We’re talking about the implementation of a cache (meant to speed up > operations), that would actually fill said cache plus do a whole bunch > of expensive operations? Nah. :-) I do not think. If I understand correctly, we need to run “git gc” at some point, therefore git-minimal needs to me around. The question is how and when. Well, maybe I am missing what the bug is about. For me, it is about running ‘git gc’ for cleaning the Git checkout cache, no? Solution #1. Add git-minimal as inputs. It increases the closure and the extra load (on average) is about the ratio between the rate of “guix pull” and the rate of the git-minimal changes. Assuming, that people are running “guix pull” once per week and say “git gc” is run after 50 pulls. (These both number are totally arbitrary and based on my personal estimate). Data Service [1] tells: 2023-07-07 15:45:22 2023-09-08 21:22:08 2023-05-11 16:10:48 2023-07-07 14:21:45 2023-05-01 16:40:08 2023-05-11 14:36:16 2023-04-25 13:34:54 2023-05-01 15:19:55 2023-04-25 13:34:54 2023-09-08 21:22:08 2023-03-06 17:22:28 2023-04-25 12:27:33 2023-01-17 23:49:19 2023-03-06 16:48:43 2022-11-08 13:06:42 2023-01-17 15:11:47 2022-10-08 05:14:46 2022-11-08 09:56:31 2022-09-06 15:00:08 2022-10-08 04:15:43 2022-08-13 22:02:31 2022-09-06 12:58:52 … It means that an user will download ~10 times git-minimal for nothing. Solution #2. The one I am proposing. :-) Download git-minimal only when Guix needs it for running “git gc”. Yeah, there is probably a small overload with some operations. But, I bet this overload is much smaller than the one of solution #1. Well, it depends on the number of times people are updating the cache vs the rate of change of git-minimal. For sure, if one updates 100 times per week the cache, having git-minimal as inputs is far better. But I do not think that the regular usage on average. :-) That’s why I am proposing to have an option for turning off this “git gc“ operation. Well, we have lived since years without running ‘git gc’ so running it once per year on average is probably enough to keep the cache size reasonable. And git-minimal is changing every month. Maybe, there is some solution #3. ;-) Cheers, simon 1: https://data.guix.gnu.org/repository/1/branch/master/package/git-minimal/output-history
bug#65769: greetd-wlgreet-sway-session result is blinking cursor
Hi chris, chris writes: > Josselin sent this message intended for the thread and I think they are okay > with re-pasting here, > >> Usually elogind is responsible (through a PAM module) for creating this >> runtime directory. If you're not using elogind, you'll need to create this >> directory yourself somehow. I don't really think this is a bug per-se, as >> running without elogind is advanced stuff and its consequences should be >> understood by the user. oops, sorry for not replying to all (the cardinal sin of email conversation). > I support any conclusion from Josselin and unmatched-paren and want to add > these observations, > * wlgreet *does require* the greeter lock file > * wlgreet *does not require* elogind/logind > * not-advanced users like me may want to use wlgreet without elogind I'd still like feedback from actual users of wlgreet, as I have not used it myself. I do believe the only way it could work is because something takes care of creating the runtime directory. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#44053: Poor profile generation performance on spinning disks
Hi Luis, Luis Felipe skribis: >> Could you time just profile generation itself? >> > >> To do that, you need to find the profile generation and then to rebuild >> it, along these lines: >> > >> DRV=$(guix gc --derivers $(readlink -f ~/.guix-profile)) >> time guix build --check $DRV > > The above results in > > real1m28,841s > user0m2,169s > sys 0m0,450s Thanks. It means that profile generation itself (and not just hooks) is slow. The place to look at is (guix build union). Unfortunately, I suspect there’s little room for optimization at this stage (see commit 12129998689648923b58c426362a1bc875da75f9 from… 2014). Fundamentally, ‘union-build’ traverses every input directory, which is expensive with low-end hard disks. It would still be worth investigating (for example by strace’ing the ‘union-build’ process) in case we missed optimizationm opportunities, though. Thanks, Ludo’.
bug#34135: IceCat lacks WebGL support
Hi Maxim, Maxim Cournoyer skribis: > Ludovic Courtès writes: > >> If you enable WebGL support in ‘about:config’, then stop it and run: >> >> $ export LIBGL_DRIVERS_PATH=$(guix build mesa)/lib/dri >> $ icecat https://get.webgl.org [...] >>While your browser seems to support WebGL, it is disabled or >>unavailable. >> >> Weird thing is that glxgears and glxinfo (from ‘mesa-utils’) both work >> well. >> >> Thoughts? > > I don't reproduce this issue, using Guix 9f4b6bc with IceCat version > 102.14.0-guix0-preview1, although I must *not* set LIBGL_DRIVERS_PATH > the way you did otherwise it fails. > > I'm using an nvidia 8800 GTS card with the nouveau driver, and the > spinning cube displays fine at https://get.webgl.org/. > > Is it still a problem for you? Nope, closing! Ludo’.
bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.
Am Sonntag, dem 03.09.2023 um 21:59 +0200 schrieb Liliana Marie Prikler: > Am Sonntag, dem 03.09.2023 um 10:51 -0400 schrieb Maxim Cournoyer: > > Hi Liliana, > > > > Liliana Marie Prikler writes: > > > > [...] > > > > > Queued locally for emacs-next and followed up > s/emacs-next/emacs-team/ s/Queued locally/Pushed/ Cheers
