Guix Emacs does not get "America/Sao_Paulo" timezone by name

  • Done
  • quality assurance status badge
Details
5 participants
  • Thiago Jung Bauermann
  • Jorge P. de Morais Neto
  • Leo Prikler
  • Liliana Marie Prikler
  • John Hamelink
Owner
unassigned
Submitted by
Jorge P. de Morais Neto
Severity
normal
J
J
Jorge P. de Morais Neto wrote on 8 May 2021 23:19
(address . bug-guix@gnu.org)
87bl9k2aav.fsf@disroot.org
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
L
L
Leo Prikler wrote on 9 May 2021 01:56
e2025a27d313cda09d1bc2cef0cf735bb5130926.camel@student.tugraz.at
Am Samstag, den 08.05.2021, 18:19 -0300 schrieb Jorge P. de Morais
Neto:
Toggle quote (16 lines)
> 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
J
J
Jorge P. de Morais Neto wrote on 9 May 2021 17:38
8735uvgbnz.fsf@disroot.org
Hi Leo.

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

Toggle quote (4 lines)
> 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

Toggle quote (2 lines)
> 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.
L
L
Leo Prikler wrote on 9 May 2021 17:57
692e6fb89cce2543f831261f6da7313209e1ec4c.camel@student.tugraz.at
Am Sonntag, den 09.05.2021, 12:38 -0300 schrieb Jorge P.de Morais Neto:
Toggle quote (12 lines)
> 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.
Toggle quote (12 lines)
> > 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
J
J
Jorge P. de Morais Neto wrote on 9 May 2021 21:41
87k0o7eluo.fsf@disroot.org
Hi Leo.

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

Toggle quote (10 lines)
> 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:

Toggle snippet (5 lines)
#!/usr/bin/env bash

TZDIR="${GUIX_PROFILE}/share/zoneinfo" emacs "${@}"

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?

Toggle quote (2 lines)
> 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.
- If an email of mine arrives at your spam box, please notify me.
L
L
Leo Prikler wrote on 9 May 2021 22:08
9e44a76e7faf78407e8bf3298aee42d3f1af955f.camel@student.tugraz.at
Am Sonntag, den 09.05.2021, 16:41 -0300 schrieb Jorge P.de Morais Neto:
Toggle quote (33 lines)
> 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.

Toggle quote (3 lines)
> > Note: the above assumes, that `guix build tzdir` produces $TZDIR
>
> Don’t you mean ‘guix build tzdata’?
Yes, please pardon my typos :)
J
J
Jorge P. de Morais Neto wrote on 10 May 2021 00:23
87h7jbeecs.fsf@disroot.org
Em [2021-05-09 dom 22:08:17+0200], Leo Prikler escreveu:

Toggle quote (6 lines)
>> 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.

Toggle quote (3 lines)
>> 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
L
L
Liliana Marie Prikler wrote on 20 Jan 2022 09:18
Re: Emacs cursor theme is not inherited from the OS when using foreign Guix
(address . 48300-done@debbugs.gnu.org)
36cc0373db290039046a8235f68e7b62f487489b.camel@ist.tugraz.at
Hi

Am Donnerstag, dem 20.01.2022 um 00:03 +0000 schrieb John Hamelink:
Toggle quote (13 lines)
> 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

Toggle quote (11 lines)
> 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

Toggle snippet (6 lines)
# ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf
[Service]
Environment=TZDIR='/usr/share/zoneinfo'
Environment=XCURSOR_PATH='/usr/share/icons'

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


Closed
J
J
John Hamelink wrote on 20 Jan 2022 10:03
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)
87pmom7p6g.fsf@johnhame.link
Hi Liliana,


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

Toggle quote (5 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCgAvFiEE+Yt/N+nvP8wO2AcVFT3f6aVKmkwFAmHpJccRHG1lQGpvaG5o
YW1lLmxpbmsACgkQFT3f6aVKmkwVYhAAuHB5PpUzAi+Z/wpkDDTKlftdIRFH11Qg
FuXlVlPOulOsAzKnd7vwjg6s2/lXf5hWrzemaVhvt0wbwEMVV842mgYTCDIVAhxl
MuOYEeWiOmBZRaBRqHWHDb/7I303uqR1Emj3HegCYvlpYS1WTtJcU9nDrLqivMr4
rmkhdgHMewPrV7ekdmQqcAjL82+0C80Iqh8cMOPNHBtlpZV84usUR+cMsr9AGrIV
TE+PG2L3MqtmgQTbEwG4yLq5l8AuEniQ0poF2xsVyaC+HIJgBJ8cEmlXMztk/e+P
0djOqsFKh7at8ojlBsGCnN1zyH/dSDCRP69A2nAnwkxfOgoSTmFTjCHw1M8j7QEt
zci6qc1yE+0HGkuGgcUvzosanrVvSDxyjRRcaaw5R53RvYGoymG9h3+qwEl15F2R
+FXCU51A7fGQpKYSkm2wU76uQmihghStbftqNjlSP90pnskidKcLhFjhgg4bsQF+
7X8yubpcf51/P/k51yJp1J3hxmf1uy5YnlaCM8kc/mNMLXjSp/7r7gYGW47AJrgN
LQi/WmhZ/4RolXSO4dmCkN2SMkq4xqjrIXju07MItvk/FibPpMLCp3+Ns2zHTmTT
CdnwiTiHRc0ZbykKWxMyl1HOzE7/xNEZru9K1BUWCL01+b731HfxVSBmnc77B8st
uastSuZwX30=
=H8Tf
-----END PGP SIGNATURE-----

Closed
J
J
Jorge P. de Morais Neto wrote on 20 Jan 2022 12:27
Re: bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)
8735li7il1.fsf@disroot.org
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
L
L
Liliana Marie Prikler wrote on 20 Jan 2022 12:45
bf019799c136b53f3aa6673a226ec6d5c448dcb3.camel@ist.tugraz.at
Am Donnerstag, dem 20.01.2022 um 08:27 -0300 schrieb Jorge P.de Morais
Neto:
Toggle quote (10 lines)
> 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
J
J
Jorge P. de Morais Neto wrote on 20 Jan 2022 13:29
87v8ye4mla.fsf@disroot.org
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
L
L
Liliana Marie Prikler wrote on 20 Jan 2022 13:59
fd0f15d61544bdb01646394b520a070eaba233b2.camel@ist.tugraz.at
Am Donnerstag, dem 20.01.2022 um 09:29 -0300 schrieb Jorge P.de Morais
Neto:
Toggle quote (6 lines)
> 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
J
J
Jorge P. de Morais Neto wrote on 20 Jan 2022 15:12
87sftimr6r.fsf@disroot.org
Hi.
Em [2022-01-20 qui 13:59:55+0100], Liliana Marie Prikler escreveu:

Toggle quote (4 lines)
> 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.
T
T
Thiago Jung Bauermann wrote on 20 Jan 2022 21:26
(name . Jorge P. de Morais Neto)(address . jorge+list@disroot.org)
3832313.HcVt6924BT@popigai
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:
Toggle quote (6 lines)
> 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
J
J
Jorge P. de Morais Neto wrote on 21 Jan 2022 14:11
(name . Thiago Jung Bauermann)(address . bauermann@kolabnow.com)
87k0etmdy0.fsf@disroot.org
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.
- If an email of mine arrives at your spam box, please notify me.
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 48300
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