bug#36870: was: date bug -- really locale bug or ??

[Mark H Weaver]

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

bug#36870: was: date bug -- really locale bug or ??

[Bengt Richter]

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 
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
bashpts/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-
mutttty4  6327 Smutt
bashtty4 24159 Sbash
bashtty4  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,
 "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
fstat(4,
 {st_mode=S_IFREG|0644,
 st_size=2836,
 ...}) = 0
fstat(4,
 {st_mode=S_IFREG|0644,
 st_size=2836,
 ...}) = 0
read(4,
 "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,
 -1802,
 SEEK_CUR) = 1034
read(4,
 "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) = 0
write(1,
 "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-locales2.28out 
/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