[Testing Update] 2022-06-07 - Kernels, Mesa 22.1.1, Haskell, Perl, Python, Pamac

Thanks for the heads up I can still tty just can’t launch terminal from the icon. Guessing the best option is just to restore my pacsave for now ?

Edit

this is the error gnome-terminal throws when trying to launch it from elimentary terminal

# Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached

MSM reads /etc/locale.conf so they will be empty if that file doesn’t exist. Choosing values there and saving will create it if the file doesn’t already exist.

@Yochanan Yeah i thought so and I wasn’t looking for a solution for myself. Instead I was thinking forward and thought that maybe MSM may need an adjustment in that regards. However, I don’t know how this will be handled in future and what’s in plan already. You know better than me. Thanks for clarification.

Everything seems to be working just fine. But during the upgrade my system began using way too much RAM while running almost nothing apart from the terminal, and my swap went over 1 GB which never happened before. This specially during depmod of linux kernel 5.18.2-1.
This time I upgraded with

sudo pamac upgrade -a

While I often just go with sudo pacman -Syu and only after that update stuff from AUR.
So I don’t know if that has anything to do with it, but that’s the only thing I can think of that was different. Also at that time no AUR packages had even been installed.

Not sure about all you guys panicking about the locale, no issue here. I noticed the .pacnew file after update, I removed the .pacnew file as nothing relevant to add to my config file. I rebooted. Nothing happened.

3 Likes

LANG=C in /etc/locale.conf breaks some apps that’s the problem. Gnome terminal is definitely broken but @Zesko posted the fix

OK. I don’t have LANG=C in /etc/locale.conf, I have a locale.conf.pacsave though. Here is the .pacsave file I have (the new locale.conf file only has the first line)

LANG=fr_FR.UTF-8
LC_ADDRESS=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8
LC_MONETARY=fr_FR.UTF-8
LC_NAME=fr_FR.UTF-8
LC_NUMERIC=fr_FR.UTF-8
LC_PAPER=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8

So the problem is not the update, but your previous configuration of locale.conf? I mean is it a user problem or is it an update problem? I don’t get it. Whatever, as said no issue here.

Its a bit above my knowledge base but so far the issue seems to be on gnome/cinnamon (gnome based) DE. Could be coincidence but i certainly don’t remember editing locale.conf anytime beforehand

After this update I had a problem with a Gnome extension which requires UTF-8 locale but the update left the locale set to β€œC”.

So, I ran localectl set-locale en_US.UTF-8, logged out of Gnome and back in and everything has been fine since.

2 Likes

Worked nicely. Thank you, sir.

It’s a problem caused by the update.
From what I gather: filesystem package no longer feels responsible for /etc/locale.conf (see [pkg-upd] 2021.12.07-5 (95553e13) Β· Commits Β· Packages / Core / filesystem Β· GitLab) and therefore that file is saved as /etc/locale.conf.pacsave - which screws up locale configuration until it’s restored (manually).

4 Likes

I have similar issue but with XFCE.
The locale is Hungarian originally,
but system is using English instead.

Neither sudo mv /etc/locale.conf.pacsave /etc/locale.conf
nor sudo locale-gen has helped.

UPDATE:
My father’s laptop has this issue as well,
but with BUDGIE instead of XFCE.

Content of /etc/locale.conf:

───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────
       β”‚ File: /etc/locale.conf
       β”‚ Size: 170 B
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   β”‚ LANG="hu_HU.UTF-8"
   2   β”‚ LC_MESSAGES="hu_HU.UTF-8"
   3   β”‚ LC_MONETARY="hu_HU.UTF-8"
   4   β”‚ LC_PAPER="hu_HU.UTF-8"
   5   β”‚ LC_MEASUREMENT="hu_HU.UTF-8"
   6   β”‚ LC_ADDRESS="hu_HU.UTF-8"
   7   β”‚ LC_TIME="hu_HU.UTF-8"
───────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────

image

image

1 Like

Corrected with filesystem 2022.06.08-1 and systemd 251.2-3. The default is now set to C.UTF-8.

3 Likes

After update I still have only LANG=β€œC” in my locale.conf file, but I don’t see any issues on Plasma. Should i manually change it to C.UTF-8?

No, that’s only the fallback default if there is no /etc/locale.conf. If one uses U.S. English for example, it would be set to to LANG=en_US.UTF-8.

The easy way is using Manjaro Settings Manager > Locale Settings and make your language changes there. After applying, it will set the LANG value in /etc/locale.conf.

4 Likes

i applied 2nd update

cat /etc/locale.conf
LANG=fr_FR.UTF-8
localectl
   System Locale: LANG=fr_FR.UTF-8
       VC Keymap: fr-latin9
      X11 Layout: fr
       X11 Model: logitech_base
     X11 Variant: oss_latin9

i have in manjaro settings

en_US.UTF-8
en_US
fr_FR.UTF-8

locale -a
C
C.UTF-8
en_US
en_US.iso88591
en_US.utf8
fr_FR.utf8
POSIX

Thanks! The corrections fixed it.

I noticed that when I upgraded filesystem to 2021.12.07-5. Veracrypt stopped working. Does anyone know how to fix this or why it is happening?

For now, my solution was to downgrade filesystem back to the previous version. But eventually, I’ll have to upgrade so I hope I find a solution by then.

@NeoTheo No issues with veracrypt for me. Current filesystem version in testing branch is 2022.06.08-2. Must be something else.
Run it in terminal and see if it brings up an error message.

That’s not the current version.

Please read the messages already posted in this thread (preferably before posting).