bug: eza ignores LC_TIME and always shows dates in English (deb.gierens.de build only)

[antonsoroko]

If eza does something unexpected, or its output looks wrong, or it displays an error on the screen, or if it outright crashes, then please include the following information in your report:

• The version of eza being used (eza --version): v0.18.14 [+git]
• The command-line arguments you are using: -l
• Your operating system and hardware platform: Kubuntu 23.10 x86_64

If it’s a crash, please include the full text of the crash that gets printed to the screen. If you’re seeing unexpected behaviour, a screenshot of the issue will help a lot.

---

exa:

$ LC_TIME=fr_FR.utf8 exa -l
drwxr-xr-x - root  7 nov.   2023 cache
drwxrwxrwt - root 12 mai   14:00 crash
drwxr-xr-x - root 15 févr. 17:20 lib
drwxr-xr-x - root  1 mars  13:52 opt
drwxr-xr-x - root 15 déc.   2023 snap

$ LC_TIME=be_BY.utf8 exa -l
drwxr-xr-x - root  7 ліс  2023 cache
drwxrwxrwt - root 12 мая 14:00 crash
drwxr-xr-x - root 15 лют 17:20 lib
drwxr-xr-x - root  1 сак 13:52 opt
drwxr-xr-x - root 15 сне  2023 snap

eza:

$ LC_TIME=fr_FR.utf8 eza -l
drwxr-xr-x - root  7 Nov  2023 cache
drwxrwxrwt - root 12 May 14:00 crash
drwxr-xr-x - root 15 Feb 17:20 lib
drwxr-xr-x - root  1 Mar 13:52 opt
drwxr-xr-x - root 15 Dec  2023 snap

$ LC_TIME=be_BY.utf8 eza -l
drwxr-xr-x - root  7 Nov  2023 cache
drwxrwxrwt - root 12 May 14:00 crash
drwxr-xr-x - root 15 Feb 17:20 lib
drwxr-xr-x - root  1 Mar 13:52 opt
drwxr-xr-x - root 15 Dec  2023 snap

[antonsoroko]

looks like it is an issue of http://deb.gierens.de build. ubuntu 24.04 eza v0.18.2 works correctly.

not sure who can notify owner of that repo.

[cafkafk]

not sure who can notify owner of that repo.

You're looking for @gierens :)

[gierens]

Hm, I simply pack the musl binaries from the github release pages into the deb packages 📦 ... so when it's broken in the deb package it's broken on the release page.

I'm gonna try to confirm and look into it later 🕵‍♂️

[gierens]

Ah, this might be musl related: https://wiki.musl-libc.org/open-issues

Apparently, musl-libc simply does not support LC_TIME or locales in general. Awesome XD

[antonsoroko]

@gierens i see :-) i just have tested eza_x86_64-unknown-linux-gnu.tar.gz and it work fine. so maybe it makes sense to use version that is dynamically linked against standard libc, instead of statically linked with musl. but it is up to you to decide, of course.

[gierens]

@antonsoroko The problem with dynamically linking against glibc is that its shipped in different versions on each distro, meaning I would need to build, package and ditribute for each of them. Ubuntu at the moment has I think 6 different versions that are not EOL, there are short-lived versions popping up every now and then, and who knows what all the daughter distros of Debian and Ubuntu are doing. So this would become quite a bit of overhead quickly.

At the moment the only issues that were reported with the MUSL builds were that SSS usernames/groups are not displayed and the LC_TIME thing here now. In both cases I'd argue that the broad user base is unaffected, and cargo install is always an option for those who are.

I can imagine maybe distributing for at least the major players (Debian, Ubuntu LTS versions) but that would still incur quite a bit of overhead and require adjusting the repo structure which could be problematic for users already using it. Also I think eza should become part of the official Debian 13 Trixie repo and from there it's likely that it makes its way down to other distros quite quickly.

So overall, I'd say we are not moving away from musl-libc in the near future at least.

[antonsoroko]

for ubuntu you could use PPA - it can do auto builds for all supported ubuntu versions. but it is of course an extra burden to support another repo (PPA).

ubuntu 24.04 and debian 13 already have eza: https://packages.debian.org/search?keywords=eza&searchon=names&suite=all&section=all https://packages.ubuntu.com/search?keywords=eza&searchon=names&suite=all&section=all

and i guess for older deb based distros users can download libc version from github releases page.

i mean, it is still quite inconvenient, but it is not critical, i guess. thus - ok.