<apteryx>sadly I don't see how the .xsession content appearing there should work with SLiM
<apteryx>I've tried it on my machine and it breaks the login
<apteryx>ah, it seems I should add more to it: "Your ~/.xsession is expected to do whatever is necessary to customize and then start the specified desktop environment.". I don't use xsession normally, so SLiM start ratpoison by some other mean.
<brendyyn>you can think of guix as like a special package that's treated separately from the rest. if you have guix in your profile, when you run 'guix pull' to update guix, it will put the updated guix in .config/... but the old guix will still be in you profile, and depending on how PATH is set, this old guix may still overshadow the new one, and so you'll discover you are still on the same version even after
<adfeno>Also, #guix, does anyone know a good email filtering or splitting rule to place Debbugs replies in a general "bug guix" email directory?
<adfeno>I thought I could use List-id as a variable, but if someone replies to me directly and puts the bug's email address in Cc, then my email client doesn't know that it's related to Guix, only that it came from debbugs.gnu.org (which also happens to have other projects using that bug tracker)
<_tibbe>adfeno: I use `mu`s guile support to just filter cc, bcc and to for the debbugs mailing list address.
<adfeno>_tibbe: However I want to point out that the replies are sent via Cc to [bug number]@debbugs.gnu.org, and other projects also use debbugs.gnu.org, thus just by the email address there is no way to filter/split it correctly. Unless one goes to wild chase of all open bugs related to Guix and adds each to a regular expression match based on that domain name.
<adfeno>Hm, strange that guix build icecat fails if add --enable-debug and --enable-debug-symbols options
<adfeno>_tibbe efraim: Please forget my last question regarding filtering/splitting messages related to bug-guix. Apparently the message that came to my inbox didn't come with all the header fields *normally* set when someone puts [bug number]@debbugs.gnu.org in the To field. Instead, the person put my address there, and the Debbugs one in Cc, thus causing the issue.
<reepca>rekado: ah, turns out I didn't write my test variation of the package quite like the original. I fixed that, here are the new environment variables the flake8 build reports: https://paste.debian.net/1058919/
<reepca>(previously it contained python2-python2-configparser in PYTHONPATH, got that fixed)
<reepca>still fails just like the original, of course.
<janneke>apteryx: yeah, i figured that much .. good to know we're not alone
<apteryx>pinently.el was incorporated into Emacs 25, only to be removed from Emacs 26; it now stands alone as emacs-pinentry. Its job seems to be so that any request to gpg goes through Emacs (with a dependency on pinentry-emacs?). Meanwhile, a new configuration was added (epa-pinentry-mode) to Emacs, that should *just* work regardless of the pinentry flavour installed as it uses a loopback mode directly exposed from
<janneke>apteryx: ok, that sounds like good news...
<apteryx>*but* the epa-pinentry-mode will not redirect the requests to gpg that originated outside of the Emacs gpg library calls (epa-*), so it's useless say with Magit.
<reepca>so with the exact same sys.path the exact same python fails to import a module that it can import fine outside of the build environment, and that exists in the build environment as well. Any python experts have any insight into this witchcraft?
<apteryx>so, long story short, I think for all the cases we still need pinentry-emacs + emacs-pinentry installed, along with the allow-emacs-pinentry option in ~/.gnupg/gpg-agent.conf
<janneke>apteryx: ow, ..does not with Magit that's wicked!
<adfeno>sneek: later tell quiliro: Also, I'm trying to debug this by building IceCat with debug symbols enabled, but Mozilla Firefox's Cargo/RustC build system is giving segmentation fault due to some "invalid memory reference" when compiling a specific file (something like "encoding_c", if I recall).