Recent update caused NoExtract directive to break system

sshaikh · 2021-05-24 16:05:08

After a recent update I found that a few applications ceased to work due to locale issues, in particular Alacritty. After trying to reproduce in a new build it appeared to be the following in my pacman.conf causing the issues:

NoExtract = usr/share/X11/locale/* !usr/share/X11/locale/compose.dir !usr/share/X11/locale/locale* !usr/share/X11/locale/en_GB.UTF-8/*

Removing this and reinstalling (`pacman -Qqn | pacman -S -`) repaired my system. I'm not actually sure where I got the above from, perhaps it's of my own design. However it had never been an issue until a recent update.

When I was investigating, libx11 was one of the packages that had been updated before the problems started, and indeed it is the package that owns files in X11/locale. However downgrading this package didn't seem to fix things, so I'm left wondering what exactly the nature of the change was in libx11 that caused the issue and didn't allow me to revert.

EDIT: On submitting I realised that, of course, libx11 hadn't been updated since I added/ported the NoExtract lines. I'll leave the above here just in case it's useful to anyone else.

Last edited by sshaikh (2021-05-24 16:07:27)

seth · 2021-05-24 17:13:46

Just to recap:
Something™ broke alacritty, you thought it was the NoExtract rule but figured that's not the case because the affected package wasn't actually part of the breaking update.
Also a complete re-installation of all packages fixed alacritty somehow™.

?

Unless you can re-cause the alacritty issue (eg. by removing the paths covered by the former NoExtract rule) I don't think this is useful information and misleading at worst.
I'd consider to report it for the dustbin in that case.

sshaikh · 2021-05-25 08:28:17

1. An update broke alacrity.
2. The root cause was a faulty NoExtract directive that interfered with an libx11 update.
3. The remaining question was why it happened, as the NoExtract had been there for a relatively long time, and downgrading libx11 didn't fix it.
4. The final realisation was that this must have been the first time libx11 had been updated since the NoExtract had been put in, so downgrading was not "restoring the previous state" as I naively assumed. That's the lesson I learned.

So yes, putting the NoExtract back in and reinstalling the system breaks alacrity (amongst other things).

V1del · 2021-05-25 08:37:22

If you actually have an interest in reinstating this, at the minimum you'll need to retain the C locale and you probably really also want to keep en_US which is what many, many utilities use as the standard fallback and there are going to be lots of tools that don't explicitly ship/use en_GB.

sshaikh · 2021-05-25 09:50:09

Thanks for the tip. I also had a look at some of the alias and dir files in x11/locale, which seem to indicate the relationship between en_GB and other locales including en_US and iso* ones.

I think I'll leave it alone for now, or at least till the space they take up becomes a real concern.

eschwartz · 2021-05-30 19:13:10

https://wiki.archlinux.org/title/Pacman … _languages

I spent some time at one point narrowing down a hopefully thorough set of rules for this. I can't swear that it's perfect, but it should work much more reliably than the simple one you listed.

Arch Linux

#1 2021-05-24 16:05:08

Recent update caused NoExtract directive to break system

#2 2021-05-24 17:13:46

Re: Recent update caused NoExtract directive to break system

#3 2021-05-25 08:28:17

Re: Recent update caused NoExtract directive to break system

#4 2021-05-25 08:37:22

Re: Recent update caused NoExtract directive to break system

#5 2021-05-25 09:50:09

Re: Recent update caused NoExtract directive to break system

#6 2021-05-30 19:13:10

Re: Recent update caused NoExtract directive to break system

Board footer