Trippy fails to use system locale

[snackiz]

Describe the bug
Trippy fails to use the system locale correctly

To Reproduce
1: Set a locale, see my locale settings below for reference:
$ env | grep 'LC_|LANG' | sort
GDM_LANG=en_US.utf8
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_ADDRESS=sv_SE.UTF-8
LC_COLLATE=sv_SE.UTF-8
LC_CTYPE=sv_SE.UTF-8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_MONETARY=sv_SE.UTF-8
LC_NAME=sv_SE.UTF-8
LC_NUMERIC=sv_SE.UTF-8
LC_PAPER=en_GB.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_TIME=en_GB.UTF-8

2 - Run trip 8.8.8.8

3 - Watch trippy displayed in swedish

Expected behavior
Trippy should start and display english language.

Screenshots

Environment Info

• OS: Debian trixie
• Trippy version: trip 0.12.2
• Installation method: apt install trippy
• Terminal / Console: terminator 2.1.4

Additional context

[fujiapple852]

@snackiz just to check, are you running trip via sudo? Perhaps the language is set differently for the root user.

[fujiapple852]

@snackiz can you confirm re: running via sudo?

[snackiz]

@fujiapple852 I was not running it via sudo, but doing so gets the same result.

[fujiapple852]

Thanks @snackiz

I am able to reproduce the same behaviour.

I ran:

docker run --rm -it debian:trixie

I then installed the required locales (code from AI as i'm not a Debian user):

export DEBIAN_FRONTEND=noninteractive

apt-get update
apt-get install -y --no-install-recommends locales libc-l10n

# enable the locales we need
sed -i -E "s/^[# ]*(en_US.UTF-8 UTF-8)/\1/" /etc/locale.gen
sed -i -E "s/^[# ]*(sv_SE.UTF-8 UTF-8)/\1/" /etc/locale.gen
sed -i -E "s/^[# ]*(en_GB.UTF-8 UTF-8)/\1/" /etc/locale.gen

locale-gen

After doing so I checked the installed languages:

root@0a41c3f936ea:/# locale -a | grep -E "^(en_US\.utf8|sv_SE\.utf8|en_GB\.utf8)$" | sort
en_GB.utf8
en_US.utf8
sv_SE.utf8

Then, after starting a new shell, I observe the following which matches your output exactly:

bash
root@0a41c3f936ea:/# env | grep 'LC_\|LANG' | sort
GDM_LANG=en_US.utf8
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_ADDRESS=sv_SE.UTF-8
LC_COLLATE=sv_SE.UTF-8
LC_CTYPE=sv_SE.UTF-8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_MONETARY=sv_SE.UTF-8
LC_NAME=sv_SE.UTF-8
LC_NUMERIC=sv_SE.UTF-8
LC_PAPER=en_GB.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_TIME=en_GB.UTF-8

I then installed trippy (0.12.2):

root@0a41c3f936ea:/# apt install trippy
root@0a41c3f936ea:/# trip -V
trip 0.12.2

Finally, I ran trip 1.1.1.1 and confirmed the language was set to sv.

[fujiapple852]

Interestingly, when I install Trippy from src and run it within the container it picks en as expected. The issue is only observed with the apt installed Trippy.

Installing Cargo/Rust and Trippy 0.12.2 from src within the container:

root@0a41c3f936ea:/# apt install cargo
root@0a41c3f936ea:/# git clone https://github.com/fujiapple852/trippy.git
root@0a41c3f936ea:/# cd trippy
root@0a41c3f936ea:/trippy# git checkout 0.12.2
root@0a41c3f936ea:/trippy# cargo build

Verify versions:

root@0a41c3f936ea:/trippy# ./target/debug/trip -V
trip 0.12.2
root@0a41c3f936ea:/trippy# trip -V
trip 0.12.2

Running ./target/debug/trip 1.1.1.1 shows en whereas running trip 1.1.1.1 shows sv.

I am aware that the debian fork of Trippy contains various patches, here, which most likely accounts for the difference. I'll dig into these to see if I can find a likely culprit. cc @nc7s.

[fujiapple852]

I see that the relax-deps.patch downgrades sys-locale from versionn 0.3.2 to version 0.3. However the committed Cargo.lock file still shows 0.3.2 was selected:

[[package]]
name = "sys-locale"
version = "0.3.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8eab9a99a024a169fe8a903cf9d4a3b3601109bcc13bd9e3c6fff259138626c4"
dependencies = [
 "libc",
]

Perhaps a different Cargo.lock file was actually used for the build?

The 0.3.1 and 0.3.2 release notes of sys-locale both contain changes which sounds highly relevant:

https://github.com/1Password/sys-locale/releases/tag/v0.3.1
https://github.com/1Password/sys-locale/releases/tag/v0.3.2

So best guess is that Trippy 0.12.2 on debian was built with sys-locale version 0.3.0 or 0.3.1 due to the relaxed dep.

[fujiapple852]

By downgrading sys-locale to version 0.3.1 I am able to reproduce the issue within a debian:trixie container.

I pinned the version in Cargo.toml:

sys-locale = "=0.3.1"

I rebuild Trippy:

root@0a41c3f936ea:/trippy# cargo build
    Updating crates.io index
     Locking 1 package to latest compatible version
 Downgrading sys-locale v0.3.2 -> v0.3.1 (available: v0.3.2)
  Downloaded sys-locale v0.3.1
  Downloaded 1 crate (15.7 KB) in 0.30s
   Compiling sys-locale v0.3.1
   Compiling trippy-tui v0.12.2 (/trippy/crates/trippy-tui)
   Compiling trippy v0.12.2 (/trippy/crates/trippy)
   Compiling hello-world v0.1.0 (/trippy/examples/hello-world)
   Compiling traceroute v0.1.0 (/trippy/examples/traceroute)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 19.49s

Then I ran ./target/debug/trip 1.1.1.1 which now shows me sv as the selected locale.

[nc7s]

Yes, the .buildinfo (a snapshot log of build environment) of my upload confirms: librust-sys-locale-dev (= 0.3.1-1+b1). It's still 0.3.1-1+b2 in unstable, so the problem should also be there.

A backport is needed to fix it in trixie, so you'd probably want a workaround before it enters the archive, e.g. a ~/.local/bin/trip which is a shell stub that launches /usr/bin/trip with a correct locale.

[fujiapple852]

Thanks @nc7s! What's the process for the backport, is there anything I need to do?

@snackiz the simplest workaround for the moment is to force the locale by passing --tui-locale en-US or adding this to your trippy config file:

[tui]
tui-locale = "en-US"

[nc7s]

Basically "releasing" the same version in unstable into an older archive; most work lies in aligning (with) dependencies there, so it (typically) does not need upstream involved.