GNU bug report logs - #48300
Guix Emacs does not get "America/Sao_Paulo" timezone by name

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48300 in the body.
You can then email your comments to 48300 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Jorge P. de Morais Neto" <jorge+list <at> disroot.org>
To: bug-guix <at> gnu.org
Subject: Guix Emacs does not get "America/Sao_Paulo" timezone by name
Date: Sat, 08 May 2021 18:19:20 -0300

Hi all!  I use Guix on Debian bullseye¹.  My Emacs is a Guix-installed
emacs-next with a package transformation option to use the latest commit
from the master branch.  It works fine except that it wrongly evaluates
the following function call:
    (current-time-zone nil "America/Sao_Paulo")
It returns `(0 "America")'.  And I have verified that the same bug also
occurs on plain Emacs 27.2 (also from Guix).

Last time I tested in a manually compiled Emacs 27.1.50, I got the
correct result: `(-10800 "-03")'.  Also I have just tested on someone
else’s notebook---Emacs 26.3 from Ubuntu---and it too returned the
correct result.  I have not tested other timezones.

Thank you for your work in GNU!

¹ I intend to migrate to PureOS for better free software ethics.

Regards

-- 
- <https://stallmansupport.org> "In Support of Richard Stallman"
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

Message #8 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: "Jorge P. de Morais Neto" <jorge+list <at> disroot.org>, 48300 <at> debbugs.gnu.org
Subject: Re: Guix Emacs does not get "America/Sao_Paulo" timezone by name
Date: Sun, 09 May 2021 01:56:56 +0200

Am Samstag, den 08.05.2021, 18:19 -0300 schrieb Jorge P. de Morais
Neto:
> Hi all!  I use Guix on Debian bullseye¹.  My Emacs is a Guix-
> installed
> emacs-next with a package transformation option to use the latest
> commit
> from the master branch.  It works fine except that it wrongly
> evaluates
> the following function call:
>     (current-time-zone nil "America/Sao_Paulo")
> It returns `(0 "America")'.  And I have verified that the same bug
> also
> occurs on plain Emacs 27.2 (also from Guix).
> 
> Last time I tested in a manually compiled Emacs 27.1.50, I got the
> correct result: `(-10800 "-03")'.  Also I have just tested on someone
> else’s notebook---Emacs 26.3 from Ubuntu---and it too returned the
> correct result.  I have not tested other timezones.
I'm not quite sure how tzdata works on foreign systems, but I'll assume
Guix always takes the one itself has.  Using this, I don't find any
America/Sao_Paolo, which would be the one you're looking for, but I do
find Brazil/East, which gives the expected result.  

Btw. I ran the same command on Emacs 27.2 from Guix and 26.3 on a
machine, that regrettably still runs Mint.  Neither know of
America/Sao_Paolo, which strongly makes me believe it's tzdata's fault.

It also seems as though right/America/Sao_Paolo exists within tzdata,
but Emacs doesn't try to read it.  I have no clue why though.

Regards,
Leo

Message #11 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 48300 <at> debbugs.gnu.org
Subject: Re: Guix Emacs does not get "America/Sao_Paulo" timezone by name
Date: Sun, 09 May 2021 12:38:24 -0300

Hi Leo.

Em [2021-05-09 dom 01:56:56+0200], Leo Prikler escreveu:

> I'm not quite sure how tzdata works on foreign systems, but I'll assume
> Guix always takes the one itself has.  Using this, I don't find any
> America/Sao_Paolo, which would be the one you're looking for,

Actually the correct spelling is "America/Sao_Paulo".  On my Guix
installation it seems to be the file
    ${GUIX_PROFILE}/share/zoneinfo/America/Sao_Paulo

> but I do find Brazil/East, which gives the expected result.

Did you test in Guix System or, like me, in Guix Emacs atop a foreign
GNU distro?  In my case, "Brazil/East" also does not work.  I have tried
installing Guix package tzdata---both on my main profile which contains
emacs-next and on my ‘emacs’ profile which contains Emacs 27.2 for
testing---and rebooting my notebook, but the result is the same.

And I have just installed Emacs 27.1 on my Debian bullseye, and it
correctly gets both "Brazil/East" and "America/Sao_Paulo".

Regards

-- 
- <https://stallmansupport.org> "In Support of Richard Stallman"
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- <https://www.defectivebydesign.org>
- <https://www.gnu.org>

Message #14 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: "Jorge P.de Morais Neto" <jorge+list <at> disroot.org>, 48300 <at> debbugs.gnu.org
Subject: Re: Guix Emacs does not get "America/Sao_Paulo" timezone by name
Date: Sun, 09 May 2021 17:57:27 +0200

Am Sonntag, den 09.05.2021, 12:38 -0300 schrieb Jorge P.de Morais Neto:
> Hi Leo.
> 
> Em [2021-05-09 dom 01:56:56+0200], Leo Prikler escreveu:
> 
> > I'm not quite sure how tzdata works on foreign systems, but I'll
> > assume
> > Guix always takes the one itself has.  Using this, I don't find any
> > America/Sao_Paolo, which would be the one you're looking for,
> 
> Actually the correct spelling is "America/Sao_Paulo".  On my Guix
> installation it seems to be the file
>     ${GUIX_PROFILE}/share/zoneinfo/America/Sao_Paulo
Thanks for the hint, the correct spelling does work.
> > but I do find Brazil/East, which gives the expected result.
> 
> Did you test in Guix System or, like me, in Guix Emacs atop a foreign
> GNU distro?  In my case, "Brazil/East" also does not work.  I have
> tried
> installing Guix package tzdata---both on my main profile which
> contains
> emacs-next and on my ‘emacs’ profile which contains Emacs 27.2 for
> testing---and rebooting my notebook, but the result is the same.
> 
> And I have just installed Emacs 27.1 on my Debian bullseye, and it
> correctly gets both "Brazil/East" and "America/Sao_Paulo".
I've tested Guix System.  If you install tzdata locally, don't forget
to set TZDIR in your shell profile to make Emacs find it.  The
following command fails to resolve Brazil/East:

    guix environment -C --ad-hoc emacs tzdata -E TERM -- emacs

The following command does not fail to resolve Brazil/East

    guix environment -C --ad-hoc emacs tzdata -E TERM -E TZDIR -- emacs

Note: the above assumes, that `guix build tzdir` produces $TZDIR, which
in Guix System, it does.  In particular, my earlier comment, that Emacs
uses Guix' tzdata seems to be wrong – it should use whatever you set as
TZDIR.

Regards,
Leo

Message #17 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 48300 <at> debbugs.gnu.org
Subject: Re: Guix Emacs does not get "America/Sao_Paulo" timezone by name
Date: Sun, 09 May 2021 16:41:19 -0300

Hi Leo.

Em [2021-05-09 dom 17:57:27+0200], Leo Prikler escreveu:

> I've tested Guix System.  If you install tzdata locally, don't forget
> to set TZDIR in your shell profile to make Emacs find it.  The
> following command fails to resolve Brazil/East:
>
>     guix environment -C --ad-hoc emacs tzdata -E TERM -- emacs
>
> The following command does not fail to resolve Brazil/East
>
>     guix environment -C --ad-hoc emacs tzdata -E TERM -E TZDIR -- emacs

Debian bullseye (with Gnome) does not set TZDIR in my environment.  So
to work around this bug, I have now installed Guix package tzdata and
created the Bash script emacs-wrapper:

--8<---------------cut here---------------start------------->8---
#!/usr/bin/env bash

TZDIR="${GUIX_PROFILE}/share/zoneinfo" emacs "${@}"
--8<---------------cut here---------------end--------------->8---

Alternatively, I could simply ‘export TZDIR=/usr/share/zoneinfo’ in my
environment; then I could even uninstall tzdata from Guix.  But would
that work reliably?  That is, does Guix Emacs work reliably with tzdata
from the foreign distro?

> Note: the above assumes, that `guix build tzdir` produces $TZDIR

Don’t you mean ‘guix build tzdata’?

Regards

-- 
- <https://stallmansupport.org> "In Support of Richard Stallman"
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: <https://www.fsf.org/free-software-supporter>
- If an email of mine arrives at your spam box, please notify me.

Message #20 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: "Jorge P.de Morais Neto" <jorge+list <at> disroot.org>, 48300 <at> debbugs.gnu.org
Subject: Re: Guix Emacs does not get "America/Sao_Paulo" timezone by name
Date: Sun, 09 May 2021 22:08:17 +0200

Am Sonntag, den 09.05.2021, 16:41 -0300 schrieb Jorge P.de Morais Neto:
> Hi Leo.
> 
> Em [2021-05-09 dom 17:57:27+0200], Leo Prikler escreveu:
> 
> > I've tested Guix System.  If you install tzdata locally, don't
> > forget
> > to set TZDIR in your shell profile to make Emacs find it.  The
> > following command fails to resolve Brazil/East:
> > 
> >     guix environment -C --ad-hoc emacs tzdata -E TERM -- emacs
> > 
> > The following command does not fail to resolve Brazil/East
> > 
> >     guix environment -C --ad-hoc emacs tzdata -E TERM -E TZDIR --
> > emacs
> 
> Debian bullseye (with Gnome) does not set TZDIR in my
> environment.  So
> to work around this bug, I have now installed Guix package tzdata and
> created the Bash script emacs-wrapper:
> 
> --8<---------------cut here---------------start------------->8---
> #!/usr/bin/env bash
> 
> TZDIR="${GUIX_PROFILE}/share/zoneinfo" emacs "${@}"
> --8<---------------cut here---------------end--------------->8---
> 
> Alternatively, I could simply ‘export TZDIR=/usr/share/zoneinfo’ in
> my
> environment; then I could even uninstall tzdata from Guix.  But would
> that work reliably?  That is, does Guix Emacs work reliably with
> tzdata
> from the foreign distro?
I suppose things should just work™ as it's data and using the same
source for everything should prevent bugs in which two different
programs think the time is something else.  If you do encounter bugs
after setting TZDIR, please do report them, however.

> > Note: the above assumes, that `guix build tzdir` produces $TZDIR
> 
> Don’t you mean ‘guix build tzdata’?
Yes, please pardon my typos :)

Message #23 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 48300 <at> debbugs.gnu.org
Subject: Re: Guix Emacs does not get "America/Sao_Paulo" timezone by name
Date: Sun, 09 May 2021 19:23:15 -0300

Em [2021-05-09 dom 22:08:17+0200], Leo Prikler escreveu:

>> Alternatively, I could simply ‘export TZDIR=/usr/share/zoneinfo’ in
>> my environment; then I could even uninstall tzdata from Guix.  But
>> would that work reliably?  That is, does Guix Emacs work reliably
>> with tzdata from the foreign distro?
> I suppose things should just work™ as it's data

I looked at the Guix recipe for tzdata and it seems nontrivial.  There
is compilation with GCC.  Therefore I fear using Debian’s tzdata from
Guix’s Emacs.  I suppose I will continue using Guix’s tzdata.  Indeed, I
recall having heard that Guix packages are not supposed to access files
from the foreign distro outside of a few locations such as the user’s
home.

>> Don’t you mean ‘guix build tzdata’?
> Yes, please pardon my typos :)

Pardoned. :)

Regards!

-- 
- <https://stallmansupport.org> "In Support of Richard Stallman"
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

Message #28 received at 48300-done <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: John Hamelink <me <at> johnhame.link>, 53379 <at> debbugs.gnu.org
Cc: 48300-done <at> debbugs.gnu.org
Subject: Re: Emacs cursor theme is not inherited from the OS when using
 foreign Guix
Date: Thu, 20 Jan 2022 09:18:56 +0100

Hi

Am Donnerstag, dem 20.01.2022 um 00:03 +0000 schrieb John Hamelink:
> Hi there,
> 
> I'm experiencing an issue with the emacs-next package on my Guix
> foreign setup where the cursor (*not* Emacs point) is very dark. It's
> perfectly legible against the default Emacs theme, but nonetheless it
> is not respecting the settings of the rest of my system. To make
> things worse, I'm currently using (and enjoying!) the modus-vivendi
> theme.
> 
> My host machine is running Arch GNU/Linux with a tiling window
> manager. I set my cursor style using xsetroot like so:
> 
> xsetroot -xcf /usr/share/icons/Adwaita/cursors/left_ptr 16
Corrected your xsetroot invocation there :P

> I tried installing the adwaita-icon-theme, gnome-themes-standard, and
> gnome-themes-extra packages in an attempt at installing the correct
> theme, but that didn't help.
> 
> I'm not entirely sure what the issue is, but after speaking with some
> folks at #guix, it was suggested to me that this may in fact be a
> bug. The other option discussed is that Guix needs its own cursor
> settings, but I'm too early on in my journey with Guix (maybe 2 hours
> of experience using the Guix binary) to know how set that up - if that
> is indeed the case, some pointers on what to read would be very
> warmly received!
It turns out this issue is actually related to another issue of Guix'
Emacs on foreign distros, which is it not finding timezones.  Since
I've found a permanent solution to both, I will close that bug and pat
myself on the back for doing so.

The main issue here is that foreign distros with systemd really cut
down on their use of environment variables, whereas Guix (System) makes
prominent use of them.  In the case of the other bug, TZDIR was unset,
in the case of yours it was XCURSOR_PATH.

Writing an override configuration file with the following contents

--8<---------------cut here---------------start------------->8---
# ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf
[Service]
Environment=TZDIR='/usr/share/zoneinfo'
Environment=XCURSOR_PATH='/usr/share/icons'
--8<---------------cut here---------------end--------------->8---

fixed this for me, although I should specify that I previously only had
TZDIR set and bound XCURSOR_PATH interactively in the shell (I am
typing this just as I found the fix and haven't yet had the opportunity
to restart my X session).

Now one thing I don't quite get is the interaction with GNOME Shell. 
With my current setup as detailed above, Emacs inherits whichever
cursor was set in GNOME at the time of launch for the entire process
duration -- i.e. even if the corresponding GNOME setting changes.  
I'm pretty sure in your setup with xsetroot there's nothing else
setting the cursor, so it ought to be displayed correctly after that. 
If not, you might have to play around with cursor themes in other ways
(refer to [1]).

Cheers


[1] https://wiki.archlinux.org/title/Cursor_themes

Message #31 received at 48300-done <at> debbugs.gnu.org (full text, mbox):

From: John Hamelink <me <at> johnhame.link>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: 53379 <at> debbugs.gnu.org, 48300-done <at> debbugs.gnu.org
Subject: Re: Emacs cursor theme is not inherited from the OS when using
 foreign Guix
Date: Thu, 20 Jan 2022 09:03:28 +0000

[Message part 1 (text/plain, inline)]

Hi Liliana,


Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at> writes:

> It turns out this issue is actually related to another issue of Guix'
> Emacs on foreign distros, which is it not finding timezones.  Since
> I've found a permanent solution to both, I will close that bug and pat
> myself on the back for doing so.

Allow me to join in! That worked perfectly for me. Thank you :)

Best,
JH

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: 48300 <at> debbugs.gnu.org, Liliana Marie Prikler
 <liliana.prikler <at> ist.tugraz.at>
Subject: Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from
 the OS when using foreign Guix)
Date: Thu, 20 Jan 2022 08:27:38 -0300

Hello.  So the solution to the bug is for the user to manually write the
file ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf ?

I would like to know a little more about that.  What is the advantage of
specifying the environment variables on that file instead of ~/.profile?

Kind regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about <https://stallmansupport.org>
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Message #37 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: "Jorge P.de Morais Neto" <jorge+list <at> disroot.org>, 48300 <at> debbugs.gnu.org
Subject: Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from
 the OS when using foreign Guix)
Date: Thu, 20 Jan 2022 12:45:09 +0100

Am Donnerstag, dem 20.01.2022 um 08:27 -0300 schrieb Jorge P.de Morais
Neto:
> Hello.  So the solution to the bug is for the user to manually write
> the file ~/.config/systemd/user/gnome-shell-
> x11.service.d/override.conf ?
> 
> I would like to know a little more about that.  What is the advantage
> of specifying the environment variables on that file instead of
> ~/.profile?
> 
> Kind regards,
>   Jorge
In my personal experience, the value did not get sourced correctly when
I put it into .bash_profile.  I do not know about .profile, but I guess
you'll run into similar issues.  In either case, evaluation order is
something you might want to consider.

Now the advantage of doing this at all is that you get finer control
over which environment variables are set when.  It doesn't really make
sense to e.g. set the font path when you're in a terminal.  The
disadvantage is that it's obscure and brittle -- the value TZDIR will
only be correctly set inside GNOME in this example, for other desktop
environments you'd have to copy the definitions.  What if you're
launching just a terminal session?  Don't ask me.

I'm pretty sure there's some systemd file where you can put these
instead, but in the years of using it up to encountering Guix I've
never needed such a thing and now that I do use Guix, I'm quite content
with Shepherd as my PID 1.  I still remember some of systemd's major
features that I miss from shepherd, like socket activation or the
ability to control GNOME Shell at all, but ask me about some incredibly
mundane task like setting a timer and I'll have to consult a manual on
that.

Cheers

Message #40 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>,
 48300 <at> debbugs.gnu.org
Subject: Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from
 the OS when using foreign Guix)
Date: Thu, 20 Jan 2022 09:29:21 -0300

I have defined TZDIR on ~/.profile and so far it's working.  Let's see
if it continues to work well.

And how will other users know how to fix the problem?  Will Guix's
manual be updated?  There could also be a message in the Emacs package
description.

Regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about <https://stallmansupport.org>
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Message #43 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: "Jorge P.de Morais Neto" <jorge+list <at> disroot.org>, 48300 <at> debbugs.gnu.org
Subject: Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from
 the OS when using foreign Guix)
Date: Thu, 20 Jan 2022 13:59:55 +0100

Am Donnerstag, dem 20.01.2022 um 09:29 -0300 schrieb Jorge P.de Morais
Neto:
> I have defined TZDIR on ~/.profile and so far it's working.  Let's
> see if it continues to work well.
> 
> And how will other users know how to fix the problem?  Will Guix's
> manual be updated?  There could also be a message in the Emacs
> package description.
By reading the manual (or cookbook).  Updating package descriptions
with a list of quirky annoyances on foreign distros is surely overkill.
We don't even put CVEs in there, instead describing those to ignore in
a property.

I'll write up an appropriate entry once I've figured out how I want to
word it.  However, I'd like to also state for the record, that a lack
of such is not really a bug in Guix.  Applications packaged in Guix not
only honour the environment variables they're supposed to honour, they
sometimes even have more of them.  The trouble comes from implicit
defaults being assumed (and therefore not set) by the foreign distro.

Cheers

Message #46 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>,
 48300 <at> debbugs.gnu.org
Subject: Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from
 the OS when using foreign Guix)
Date: Thu, 20 Jan 2022 11:12:44 -0300

Hi.
Em [2022-01-20 qui 13:59:55+0100], Liliana Marie Prikler escreveu:

> Updating package descriptions with a list of quirky annoyances on
> foreign distros is surely overkill.  We don't even put CVEs in there,
> instead describing those to ignore in a property.

What "property" is that?  I am interested in knowing about CVE in Guix
packages.

Kind regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about <https://stallmansupport.org>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

Message #49 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Thiago Jung Bauermann <bauermann <at> kolabnow.com>
To: "Jorge P. de Morais Neto" <jorge+list <at> disroot.org>
Cc: 48300 <at> debbugs.gnu.org,
 Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Subject: Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from
 the OS when using foreign Guix)
Date: Thu, 20 Jan 2022 17:26:08 -0300

Hello,

Em quinta-feira, 20 de janeiro de 2022, às 08:27:38 -03, Jorge P.  de 
Morais Neto via Bug reports for GNU Guix escreveu:
> Hello.  So the solution to the bug is for the user to manually write the
> file ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf ?
> 
> I would like to know a little more about that.  What is the advantage of
> specifying the environment variables on that file instead of ~/.profile?

I don’t know if this applies to all distributions, but at least in Ubuntu, 
the GNOME on Wayland and KDE on Wayland desktop sessions are started 
without a shell being invoked at any point, so ~/.profile and related files 
don’t get evaluated.

In KDE, the way to define environment variables that will be set in the 
Wayland session is to put a shell script in ~/.config/plasma-workspace/env/.

I hadn’t figured out how to do it in GNOME when I briefly searched for it. 
This systemd override file seems to be the solution.

-- 
Thanks,
Thiago

Message #52 received at 48300 <at> debbugs.gnu.org (full text, mbox):

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: Thiago Jung Bauermann <bauermann <at> kolabnow.com>
Cc: 48300 <at> debbugs.gnu.org,
 Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Subject: Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from
 the OS when using foreign Guix)
Date: Fri, 21 Jan 2022 10:11:03 -0300

Hello.  This email is just to thank Thiago for the clarification,
Liliana for the solution, and everyone for supporting GNU!

Kind regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about <https://stallmansupport.org>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.