bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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?]]

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Leo Prikler]

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

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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>

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Leo Prikler]

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

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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.

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Leo Prikler]

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 :)

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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?]]

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

[John Hamelink]

[-- Attachment #1.1.1: Type: text/plain, Size: 3807 bytes --]

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:

xsetoot -xcf /usr/share/icons/Adwaita/cursors/left_ptr 16

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!

I'm also not entirely sure what to provide to help debug, so I thought
I'd start off by showing my channels and packages, so that my setup
can be replicated? I hope that is helpful. I've also attached a
screenshot showing the difference while using the
"leuven" theme so there is enough contrast.

Thank you for reading,
JH

---

My channels:

,----
| ;; This channel file can be passed to 'guix pull -C' or to
| ;; 'guix time-machine -C' to obtain the Guix revision that was
| ;; used to populate this profile.
| 
| (list
|      (channel
|        (name 'guix)
|        (url "https://git.savannah.gnu.org/git/guix.git")
|        (branch "master")
|        (commit
| 	 "b2f6b6f6b9df6bcc24794238e7e97357470af95d")
|        (introduction
| 	 (make-channel-introduction
| 	   "9edb3f66fd807b096b48283debdcddccfea34bad"
| 	   (openpgp-fingerprint
| 	     "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))))
`----

---

My manifest:

,----
| ;; This "manifest" file can be passed to 'guix package -m' to reproduce
| ;; the content of your profile.  This is "symbolic": it only specifies
| ;; package names.  To reproduce the exact same profile, you also need to
| ;; capture the channels being used, as returned by "guix describe".
| ;; See the "Replicating Guix" section in the manual.
| 
| (specifications->manifest
|   (list "gnome-themes-extra"
| 	"gnome-themes-standard"
| 	"adwaita-icon-theme"
| 	"guix"
| 	"guile"
| 	"font-ghostscript"
| 	"nss-certs"
| 	"fontconfig"
| 	"font-gnu-freefont"
| 	"font-dejavu"
| 	"glibc-locales"
| 	"vdirsyncer"
| 	"emacs-elfeed"
| 	"emacs-undo-tree"
| 	"emacs-dash"
| 	"emacs-treepy"
| 	"emacs-fsm"
| 	"emacs-guix"
| 	"emacs-next"
| 	"xcursor-themes"
| 	"emacs-evil"
| 	"emacs-evil-collection"
| 	"emacs-bluetooth"
| 	"emacs-mpdel"
| 	"emacs-elfeed-org"
| 	"emacs-vterm"
| 	"emacs-mu4e-alert"
| 	"mu"
| 	"emacs-writeroom"
| 	"emacs-evil-org"
| 	"emacs-org-super-agenda"
| 	"emacs-yasnippet-snippets"
| 	"emacs-yasnippet"
| 	"emacs-yaml-mode"
| 	"emacs-rustic"
| 	"emacs-php-mode"
| 	"emacs-eglot"
| 	"emacs-go-mode"
| 	"emacs-flycheck"
| 	"emacs-elixir-mode"
| 	"emacs-macrostep"
| 	"emacs-bug-hunter"
| 	"emacs-editorconfig"
| 	"emacs-dockerfile-mode"
| 	"emacs-magit"
| 	"emacs-forge"
| 	"emacs-excorporate"
| 	"emacs-corfu"
| 	"emacs-pcre2el"
| 	"emacs-embark"
| 	"emacs-orderless"
| 	"emacs-marginalia"
| 	"emacs-vertico"
| 	"emacs-consult"
| 	"emacs-doom-modeline"
| 	"emacs-all-the-icons"
| 	"emacs-solaire-mode"
| 	"emacs-helpful"
| 	"emacs-general"
| 	"emacs-which-key"
| 	"emacs-no-littering"))
`----

[-- Attachment #1.1.2: visual-examples.png --]
[-- Type: image/png, Size: 132191 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

[Liliana Marie Prikler]

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

bug#48300: Emacs cursor theme is not inherited from the OS when using foreign Guix

[John Hamelink]

[-- Attachment #1.1.1: Type: text/plain, Size: 402 bytes --]

Hi Liliana,


Liliana Marie Prikler <liliana.prikler@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

[Liliana Marie Prikler]

Am Donnerstag, dem 20.01.2022 um 09:03 +0000 schrieb John Hamelink:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@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 :)
Good to hear.  Note that you can also write to BUG-done@debbugs.gnu.org
yourself, you don't need my permission to do so ;)  Anyway, done.

In order to avoid future instances of this issue, we should probably
drop a paragraph or two about it in the manual or (more likely) the
cookbook.  I'll get to that when I do.

Cheers

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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?"

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Liliana Marie Prikler]

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

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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?"

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Liliana Marie Prikler]

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

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Jorge P. de Morais Neto via Bug reports for GNU Guix]

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.