Bengt Richter wrote 6 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . bug-guix@gnu.org)
20190731062047.GA831@PhantoNv4ArchGx.localdomain
date bug
- Done
Details
- 3 participants
- Bengt Richter
- Ludovic Courtès
- Mark H Weaver
- Owner
- unassigned
- Submitted by
- Bengt Richter
- Severity
- normal
Bengt Richter wrote 6 years ago
bug#36870: was: date bug -- really locale bug or ??
(address . 36870@debbugs.gnu.org)
20190806023802.GA833@PhantoNv4ArchGx.localdomain
Hi all, following up on myself, sorry I lost my copy of
my original, so this does not contain any quoting, but
this can stand on its own as a new problem statement.
Problem should go away if I can get locales working,
but despite trying what purportedly has worked for others,
no luck. I hope it will be obvious to someone from the below ;-)
$ # first some context:
$ uname -rv
5.1.15-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 25 04:49:39 UTC 2019
$ guix -V
guile: warning: failed to install locale
guix (GNU Guix) a17fe3f01ac160a576135b03d23bc098ebf6fb31
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ### that warning -- "guile: warning: failed to install locale" might be a clue in that
$ ### it does _NOT_ happen in the direct bash console environment, but does in emacs's M-x shell ...
$ cat ~/bin/pidparents ## something to show where I am, that I find useful
#!/usr/bin/bash
# ~/bin/parentage
pid=${1:-$$} #this process if no pid specified as $1
while [ $(($pid)) -gt 0 ]; do
ps h -p $pid -o comm,tt,pid,stat,args
pid=$(ps -q $pid -o ppid=)
done
$ pidparents ## from here in emacs's shell
pidparents pts/0 9286 S+ /usr/bin/bash /home/bokr/bin/pidparents
bash pts/0 6884 Ss /bin/bash --noediting -i
.emacs-26.2-rea tty4 6393 Sl+ /gnu/store/9nrncjaxygfrr9q749pymcw3l9vywh0k-emacs-26.2/bin/emacs-26.2 /home/bokr/.mutt/temp/mutt-PhantoNv4ArchGx-1000-6327-
mutt tty4 6327 S mutt
bash tty4 24159 S bash
bash tty4 3608 Ss -bash
login ? 3601 Ss login -- bokr
systemd ? 1 Ss /sbin/init \EFI\PhantoNv4ArchGx\vmlinuz-linux
$ ### does something depend on ttyN vs pts/N ?? don't think so, but maybe some env gets lost in pts start?
$
$
$ ### here I call the guix date vs the archlinux date at /usr/bin/date -- note the difference
$ which -a date
/home/bokr/.guix-profile/bin/date
/usr/bin/date
$
$ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n :g'
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(1<pipe:[319076]>,
"Mon Aug 5 18:22:52 America 2019"...,
33Mon Aug 5 18:22:52 America 2019
$
$ strace -y /usr/bin/date|& egrep 'America|^write'|sed -e 's:,:,\n :g'
openat(AT_FDCWD,
"/usr/share/zoneinfo/America/Los_Angeles",
O_RDONLY|O_CLOEXEC) = 4</usr/share/zoneinfo/America/Los_Angeles>
fstat(4</usr/share/zoneinfo/America/Los_Angeles>,
{st_mode=S_IFREG|0644,
st_size=2836,
...}) = 0
fstat(4</usr/share/zoneinfo/America/Los_Angeles>,
{st_mode=S_IFREG|0644,
st_size=2836,
...}) = 0
read(4</usr/share/zoneinfo/America/Los_Angeles>,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
4096) = 2836
lseek(4</usr/share/zoneinfo/America/Los_Angeles>,
-1802,
SEEK_CUR) = 1034
read(4</usr/share/zoneinfo/America/Los_Angeles>,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
4096) = 1802
close(4</usr/share/zoneinfo/America/Los_Angeles>) = 0
write(1<pipe:[320852]>,
"Mon 05 Aug 2019 11:23:06 AM PDT\n",
32Mon 05 Aug 2019 11:23:06 AM PDT
$
;;;;;;;;;;;;;;;;
I put
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale/"
export LC_ALL=en_US.utf8
in both ~/.bash_profile and ~/.bashrc
and still no joy
I'm wondering whether I have to reboot, not just log out and back in,
to get locales into effect. Have been trying and searching, but something
is eluding me ;-/ [later, after rebooting -- nope, reboot didn't do it :( ]
Generation 37 Aug 02 2019 01:42:29
+ tzdata 2019b out /gnu/store/kmsqjsrwryfnz6p9pb4yysly71221blv-tzdata-2019b
Generation 38 Aug 04 2019 15:39:34
+ glibc-locales 2.28 out /gnu/store/bb9alx1ap57pz0vmx7p1r8qk0lxxfg3x-glibc-locales-2.28
Generation 39 Aug 05 2019 08:08:19
+ localed 241 out /gnu/store/98mpw3n6j34dsnq63hb14bpfv9bxq9f4-localed-241
(Hm, guess I ought to clean out some generations)
Any ideas appreciated. Am I the only one seeing this?
I first noticed because who -b gave me UTC time instead of local time.
Thanks.
Regards,
Bengt Richter
Mark H Weaver wrote 6 years ago
(name . Bengt Richter)(address . bokr@bokr.com)(address . 36870@debbugs.gnu.org)
871rxyokbd.fsf@netris.org
Hi Bengt,
I'm sorry that I didn't have time to fully read your messages, but if I
understand correctly from my quick skimming, the 'date' command from
Guix is failing to access the zoneinfo. I think I see your problem.
Bengt Richter <bokr@bokr.com> writes:
Toggle quote (5 lines)
> $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n :g'
> openat(AT_FDCWD,
> "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
The file name above suggests that your TZDIR variable is not set
correctly to allow Guix-built binaries to find the zoneinfo files.
On Guix systems, /etc/environment includes an entry that sets TZDIR to
the equivalent of "$(guix build tzdata)/share/zoneinfo".
When using Guix on top of another distro, an alternative choice might be
to set TZDIR to "/usr/share/zoneinfo". I'm not sure which setting is
preferable on non-Guix systems.
Can you try setting TZDIR and see if that solves the problem for you?
Regards,
Mark
Bengt Richter wrote 6 years ago
Re: bug#36870: was: date bug -> locale inconvenience -> suggestion :)
(name . Mark H Weaver)(address . mhw@netris.org)(address . 36870@debbugs.gnu.org)
20190806163148.GA7621@PhantoNv4ArchGx.localdomain
On +2019-08-06 02:54:03 -0400, Mark H Weaver wrote:
Toggle quote (27 lines)
> Hi Bengt,
>
> I'm sorry that I didn't have time to fully read your messages, but if I
> understand correctly from my quick skimming, the 'date' command from
> Guix is failing to access the zoneinfo. I think I see your problem.
>
> Bengt Richter <bokr@bokr.com> writes:
> > $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n :g'
> > openat(AT_FDCWD,
> > "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
> > O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>
> The file name above suggests that your TZDIR variable is not set
> correctly to allow Guix-built binaries to find the zoneinfo files.
>
> On Guix systems, /etc/environment includes an entry that sets TZDIR to
> the equivalent of "$(guix build tzdata)/share/zoneinfo".
>
> When using Guix on top of another distro, an alternative choice might be
> to set TZDIR to "/usr/share/zoneinfo". I'm not sure which setting is
> preferable on non-Guix systems.
>
> Can you try setting TZDIR and see if that solves the problem for you?
>
> Regards,
> Mark
Thanks, that works using either /usr/... or /gnu/...
but I am thinking everything guix should be accessed via
some profile if it's configurable?
There is already a suggestion to source like this:
GUIX_PROFILE="$HOME/.guix-profile"
. "$GUIX_PROFILE/etc/profile"
I think it would be nice if that were the only ~/.bash_profile
mod a foreign-system user would have to make to tie into the
guix packages such user installs with guix install.
So what about having that GUIX_PROFILE profile -- at its end --
source ~/.guixrc if it exists, and then when some installation wants
to suggest some environment settings, just automatically
append commented-out code to ~/.guixrc.
Then the friendly hints at then end of an install could suggest:
┌──────────────────────────────────────────────┐
│ "Consider uncommenting some of the new │
│ lines we just added at the end of ~/.guixrc" │
└──────────────────────────────────────────────┘
(sorry if utf8 box-drawing characters are a nono here -- are they? ;-/ )
I had noticed the TZDIR name looking with "guix edit tzdata",
and was trying to figure out why installing had not hinted
that I might need to do what you suggest above :)
Thanks again.
Regards,
Bengt Richter
Ludovic Courtès wrote 6 years ago
Re: bug#36870:
(name . Bengt Richter)(address . bokr@bokr.com)
87wof0z15f.fsf@gnu.org
Hi,
Bengt Richter <bokr@bokr.com> skribis:
Toggle quote (30 lines)
> On +2019-08-06 02:54:03 -0400, Mark H Weaver wrote:
>> Hi Bengt,
>>
>> I'm sorry that I didn't have time to fully read your messages, but if I
>> understand correctly from my quick skimming, the 'date' command from
>> Guix is failing to access the zoneinfo. I think I see your problem.
>>
>> Bengt Richter <bokr@bokr.com> writes:
>> > $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n :g'
>> > openat(AT_FDCWD,
>> > "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
>> > O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>>
>> The file name above suggests that your TZDIR variable is not set
>> correctly to allow Guix-built binaries to find the zoneinfo files.
>>
>> On Guix systems, /etc/environment includes an entry that sets TZDIR to
>> the equivalent of "$(guix build tzdata)/share/zoneinfo".
>>
>> When using Guix on top of another distro, an alternative choice might be
>> to set TZDIR to "/usr/share/zoneinfo". I'm not sure which setting is
>> preferable on non-Guix systems.
>>
>> Can you try setting TZDIR and see if that solves the problem for you?
>>
>> Regards,
>> Mark
>
> Thanks, that works using either /usr/... or /gnu/...
Good, closing!
Toggle quote (17 lines)
> but I am thinking everything guix should be accessed via
> some profile if it's configurable?
>
> There is already a suggestion to source like this:
>
> GUIX_PROFILE="$HOME/.guix-profile"
> . "$GUIX_PROFILE/etc/profile"
>
> I think it would be nice if that were the only ~/.bash_profile
> mod a foreign-system user would have to make to tie into the
> guix packages such user installs with guix install.
>
> So what about having that GUIX_PROFILE profile -- at its end --
> source ~/.guixrc if it exists, and then when some installation wants
> to suggest some environment settings, just automatically
> append commented-out code to ~/.guixrc.
I agree that it’d be nice to somehow tell users about ‘TZDIR’, but I’m
reluctant to introducing yet another profile file.
I’m not sure what would be the best approach!
Thanks,
Ludo’.
Closed
?