EXWM knows nothing about Guix profiles

  • Open
  • quality assurance status badge
Details
2 participants
  • janneke
  • Leo Prikler
Owner
unassigned
Submitted by
Leo Prikler
Severity
normal
L
L
Leo Prikler wrote on 4 May 2021 13:37
(address . bug-guix@gnu.org)
42353788fa03581cdb87da7d1fdea1c8cf0a0682.camel@student.tugraz.at
Hi Guix,

I just recently helped someone debug an issue they encountered when
using EXWM. It turned out their EMACSLOADPATH was set to
"/run/current-system/profile/share/emacs/site-
lisp:/gnu/store/1zszglsxl4zxy9alcwxjwj26d30qmyv9-emacs-
27.2/share/emacs/27.2/lisp" – quite notably, "$HOME/share/emacs/site-
lisp" was missing.

I think the launcher that we install in the install-xsession does not
do sufficient work to set up the environment variables of the session
appropriately. In particular, I think it should source /etc/profile
prior to running Emacs.

WDYT?
J
J
janneke wrote on 7 May 2021 21:15
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 48223@debbugs.gnu.org)
875yzuwe2i.fsf@gnu.org
Leo Prikler <leo.prikler@student.tugraz.at> writes:

Hello Leo,

Toggle quote (7 lines)
> I just recently helped someone debug an issue they encountered when
> using EXWM. It turned out their EMACSLOADPATH was set to
> "/run/current-system/profile/share/emacs/site-
> lisp:/gnu/store/1zszglsxl4zxy9alcwxjwj26d30qmyv9-emacs-
> 27.2/share/emacs/27.2/lisp" – quite notably, "$HOME/share/emacs/site-
> lisp" was missing.

Wow, I just hit this problem too. Your message helped me finding the
problem right away. My system which includes EXWM was still at
emacs-27.1, while I upgraded my profile to emacs-27.2.

Toggle quote (7 lines)
> I think the launcher that we install in the install-xsession does not
> do sufficient work to set up the environment variables of the session
> appropriately. In particular, I think it should source /etc/profile
> prior to running Emacs.
>
> WDYT?

I think this is a very good idea.

Greetings,
Janneke

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
J
J
Jan Nieuwenhuizen wrote on 8 May 2021 10:56
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)(address . 48223@debbugs.gnu.org)
875yzt7geo.fsf@gnu.org
Toggle quote (2 lines)
> Leo Prikler <leo.prikler@student.tugraz.at> writes:

Hello again,

Toggle quote (9 lines)
>> I think the launcher that we install in the install-xsession does not
>> do sufficient work to set up the environment variables of the session
>> appropriately. In particular, I think it should source /etc/profile
>> prior to running Emacs.
>>
>> WDYT?
>
> I think this is a very good idea.

To follow-up on this: at first glance sourcing /etc/profile seemed to
fix my problem. However, I am calling some scripts from Emacs that need
my ~/.bash_profile to be sourced too.

So this got me wondering, something has definately changed here.
Before, this used to work OOTB. Any ideas what may have changed?

BTW, I only tested with slim

Toggle snippet (13 lines)
(service slim-service-type
(slim-configuration
(auto-login? #t)
(allow-empty-passwords? #t)
(default-user "janneke")
;;(auto-login-session (file-append emacs-exwm "/bin/exwm"))
(auto-login-session "/home/janneke/bin/exwm")
(xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
(server-arguments '("-listen" "tcp"))))))))

and now use the attached exwm, which works OK for me.

Greetings,
Janneke
Attachment: exwm
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
L
L
Leo Prikler wrote on 8 May 2021 11:26
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 48223@debbugs.gnu.org)
4112dadd777b8e2eb86d7b871b35971a4666619e.camel@student.tugraz.at
Hi,

Am Samstag, den 08.05.2021, 10:56 +0200 schrieb Jan Nieuwenhuizen:
Toggle quote (20 lines)
> > Leo Prikler <leo.prikler@student.tugraz.at> writes:
>
> Hello again,
>
> > > I think the launcher that we install in the install-xsession does
> > > not
> > > do sufficient work to set up the environment variables of the
> > > session
> > > appropriately. In particular, I think it should source
> > > /etc/profile
> > > prior to running Emacs.
> > >
> > > WDYT?
> >
> > I think this is a very good idea.
>
> To follow-up on this: at first glance sourcing /etc/profile seemed to
> fix my problem. However, I am calling some scripts from Emacs that
> need
> my ~/.bash_profile to be sourced too.
I don't think sourcing ~/.bash_profile will be portable. As a zsh
user, I'm putting stuff in .zprofile instead, so all my hacks will be
obsoleted if we start mandating bash_profile. The "portable"
alternative, that is $HOME/.profile does not exist in our current
skeletons.

Putting this aside, I think it'd also be possible to duplicate whatever
settings you might have put into ~/.bash_profile in ~/.exwm.

Toggle quote (2 lines)
> So this got me wondering, something has definately changed here.
> Before, this used to work OOTB. Any ideas what may have changed?
One thing, that changed is Emacs itself. In particular, we reverted to
ELPA sub-directories for structure, but keeping a hopefully backwards-
compatible hack in subdirs.el
However, I doubt, that this is the only thing making a difference
between now and then. Since EMACSLOADPATH is wrong, it would seem,
that there is no profile evaluation whatsoever going on, and I'd argue
this has already been the case before, I just don't know when it
changed or whether things just happened to work "OOTB" despite this.

I also think, that any session should be run under the user's shell
with --login. As far as I can tell, that happens for GNOME under GDM –
executing getenv for a variable that I only set in my .zprofile I see
the correct value – why does it not happen for EXWM under slim?

Greetings,
Leo
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 48223@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 48223
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch