Bug 1085832

Created attachment 764096 [details]
Error message 2

Created attachment 764099 [details]
Yast log

For YaST we have already a bug report.

Arvin, is there a reason why all tools/daemons in the snapper package ignore if setlocale fails, but only snapper fails with a hard error?

This doesn't make much sense to me, and I fail to see why snapper needs to exit instead of printing only a warning and continues?

The situation, that the locale is wrong happens quite often to me (thanks to ssh ...).

(In reply to Thorsten Kukuk from comment #3)

> Arvin, is there a reason why all tools/daemons in the snapper package ignore
> if setlocale fails, but only snapper fails with a hard error?

Yes, snapper it the only program with propoer internationalization.

This bug is still present in snapshot 0329 and blocks all SUSE CaaSP & Kubic installations with any language besides English US

Raising the Priority accordingly

What is the use case of setting up a system in a language and not installing
the locale data required for that language?

For me this issue is still not valid.

(In reply to Arvin Schnell from comment #6)
> What is the use case of setting up a system in a language and not installing
> the locale data required for that language?
> 
> For me this issue is still not valid.

It was a PM requirement for SUSE CaaSP (and as a result, Kubic also)

Because of their role as a hands-off, management free host, no Kubic host should have any locale data present. They shouldn't be needed, because no user should ever be connecting to the system.

Localisation should be present in Velum (the webui for the cluster), and YaST (during the installation)

This is the bug - snappers assumption that because they needed localisation during the installation they will have it in the resulting system means that snapper breaks on installation, as reported in comment #0

I have discussed this with Thorsten for what feels like the nth time today. There is apparently no room for maneuver here - we cannot have CaaSP and Kubic install all locale data.

Thorsten has also discussed this with Jiri

We need Snapper to be installable and working without locale data, even if the initial installation used a custom locale.

Or to put it another way
"Fix your system" is a 100% incorrect error message; "the system" is fine and working as designed.

(In reply to Richard Brown from comment #7)

> This is the bug - snappers assumption that because they needed localisation
> during the installation they will have it in the resulting system means that
> snapper breaks on installation, as reported in comment #0

The "assumption" of snapper is that 'locale::global(locale(""));' works.
Nothing else. And almost all programs make that call.

> We need Snapper to be installable and working without locale data, even if
> the initial installation used a custom locale.

The proper solution is to not set the locale in the installed system. But
proper solutions and common sense are absent quite often here.
 
> Or to put it another way
> "Fix your system" is a 100% incorrect error message; "the system" is fine
> and working as designed.

No, the system is broken!

(In reply to Arvin Schnell from comment #8)
> 
> The "assumption" of snapper is that 'locale::global(locale(""));' works.
> Nothing else. And almost all programs make that call.

> > Or to put it another way
> > "Fix your system" is a 100% incorrect error message; "the system" is fine
> > and working as designed.
> 
> No, the system is broken!

Then please explain how the following applications all install, configure, and work perfectly fine without a warning like snappers (frankly rude) "Fix your system"

zypper
yast
docker
kubectl
hyperkube

and many, many more

Your assertion that snapper's behaviour is fair and correct doesn't seem to hold water when "almost all programs" are considered.

Do those programs work as expected (e.g. showing localized messages)?

(In reply to Arvin Schnell from comment #10)
> Do those programs work as expected (e.g. showing localized messages)?

They work as expected - showing messages in a locale which is available.

Unlike snapper they do not prevent themselves from working unnecessarily nor insult the user or their system.

(In reply to Arvin Schnell from comment #10)
> Do those programs work as expected (e.g. showing localized messages)?

No, they don't show translations, since for the functionality of this applications, localisation is not required. So they still continue to work.

(In reply to Arvin Schnell from comment #8)

> No, the system is broken!

No, the system is not broken at all. If, then the system users locale is unsupported. 
As already written, use the following example to show that the current snapper behavior is wrong:

Use a system with german locale.
ssh to a system without german locale.
locale will show you de_DE.UTF-8 as language, but that is not installed.
zypper continues to work fine.
All other tools I tried continues to work fine.
Of course all above tools will use english as locale, but they still work without error message.
But snapper tells me that the system is broken and refuses to work.

(In reply to Richard Brown from comment #11)

> They work as expected - showing messages in a locale which is available.

For me that classifies as not working as expected.

And you also like a bunch of warnings during login.

Created attachment 765747 [details]
login on SLE15 with borken locale settings

(In reply to Thorsten Kukuk from comment #12)

> As already written, use the following example to show that the current
> snapper behavior is wrong:
> 
> Use a system with german locale.
> ssh to a system without german locale.
> locale will show you de_DE.UTF-8 as language, but that is not installed.
> zypper continues to work fine.
> All other tools I tried continues to work fine.
> Of course all above tools will use english as locale, but they still work
> without error message.
> But snapper tells me that the system is broken and refuses to work.

The login scripts should check the locale.

(In reply to Arvin Schnell from comment #14)
> Created attachment 765747 [details]
> login on SLE15 with borken locale settings

Lot of warnings, no error.
Can you login? YES!
Can you call snapper: NO!

Any more questions which behavior is broken?

So the system is fine if the user gets such a bunch of messages during
login. That is indeed remarkable.

And I never had question concerning what is broken.

This is an autogenerated message for OBS integration:
This bug (1085832) was mentioned in
https://build.opensuse.org/request/show/593527 Factory / patterns-caasp

We have to look at the problem pragmatically:

Should "broken" locale settings stop you from doing anything with your system?
If so, and hacker breaks locale (let's say it's the only way she can do now),
should firewall stop working? If I break my locale settings by mistake and
log out, should I be able to log in and fix it?

What if I change my locale (in a wrong way), reboot and then I want to rollback?
Should snapper crash then? Should snapper refuse to rollback?

Of course, developers often call `LANG=C do something`, e.g., https://superuser.com/questions/334800/lang-c-is-in-a-number-of-the-etc-init-d-scripts-what-does-lang-c-do-and-why

What is worse: If all is in English or if system refuses to boot and do
anything if locale "is wrong"?

My view is that we can complain, but then we need to fallback to safe default
and let the admin work with their system.

For the record there was issue with accidentally set locales - bsc#933241

(In reply to Martin Pluskal from comment #20)
> For the record there was issue with accidentally set locales - bsc#933241

That's solveable without crash or hard exit, see any other localized application we ship.

Softened error handling if setting locale failed. Have fun with distorted screens.

SR: https://build.opensuse.org/request/show/599314

*** Bug 1081372 has been marked as a duplicate of this bug. ***