Bug 1574222 - dnf system upgrade forgot langpacks-de
Summary: dnf system upgrade forgot langpacks-de
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 28
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1565718 1570924 1573911 1574769 1575186 1577330 1648671 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-02 20:20 UTC by Peter Bieringer
Modified: 2019-11-20 10:57 UTC (History)
36 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-12 09:54:07 UTC
Type: Bug


Attachments (Terms of Use)
dnf.log (2.79 MB, text/plain)
2018-05-08 00:03 UTC, Germano Massullo
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1313818 0 unspecified CLOSED Have setlocale fallback to C.UTF-8 before C/POSIX. 2021-02-22 00:41:40 UTC

Internal Links: 1313818 1570924

Description Peter Bieringer 2018-05-02 20:20:51 UTC
Description of problem:
After upgrading from FC27 with all updates to FC28 on a system with language DE (German) strange things happened


Version-Release number of selected component (if applicable):
FC27 -> FC28


How reproducible:
at least on 2 systems for now


Steps to Reproduce:
1. upgrade

Actual results:
- XFCE logout window talks "English"
- terminal "su -" results in 

$ su -
Password: 
-bash: Warnung: setlocale: LC_TIME: Kann die Standorteinstellungen nicht ��ndern (de_DE.UTF-8).


Expected results:
Proper working

Additional info:

looks like "langpacks-de" is not covered by automatic upgrade during migration, after installation including dependencies everything looks fine:

# yum install langpacks-de
Failed to set locale, defaulting to C
Fedora 28 - x86_64 - Updates                    4.9 MB/s | 5.0 MB     00:01    
Fedora 28 - x86_64                              5.8 MB/s |  60 MB     00:10    
RPM Fusion for Fedora 28 - Free - Updates       294 kB/s |  21 kB     00:00    
RPM Fusion for Fedora 28 - Free                 2.8 MB/s | 752 kB     00:00    
RPM Fusion for Fedora 28 - Nonfree - Updates     22 kB/s | 3.6 kB     00:00    
RPM Fusion for Fedora 28 - Nonfree              817 kB/s | 208 kB     00:00    
Failed to synchronize cache for repo 'virtualbox', disabling.
Last metadata expiration check: 0:00:00 ago on Wed May  2 20:02:51 2018.
Dependencies resolved.
================================================================================
 Package                     Arch        Version              Repository   Size
================================================================================
Installing:
 langpacks-de                noarch      1.0-12.fc28          fedora      8.5 k
Installing weak dependencies:
 glibc-langpack-de           x86_64      2.27-8.fc28          fedora      484 k
 kde-l10n-de                 noarch      17.08.3-3.fc28       fedora      983 k
 man-pages-de                noarch      1.22-2.fc27          fedora      2.0 M
 tesseract-langpack-deu      noarch      3.05.01-6.fc28       fedora      4.3 M

Transaction Summary
================================================================================
Install  5 Packages

Total download size: 7.8 M

Comment 1 Alexandre Franke 2018-05-06 21:21:57 UTC
Same issue for French with a graphical upgrade (from GNOME Software).

Comment 2 Martin Hatina 2018-05-07 11:15:32 UTC
*** Bug 1575186 has been marked as a duplicate of this bug. ***

Comment 3 Marek Blaha 2018-05-07 13:18:45 UTC
Please, can you provide us with relevant part (covering the system upgrade) of /var/log/dnf.log?

Comment 4 Bastien Nocera 2018-05-07 15:12:22 UTC
*** Bug 1574769 has been marked as a duplicate of this bug. ***

Comment 5 Bastien Nocera 2018-05-07 15:12:40 UTC
*** Bug 1573911 has been marked as a duplicate of this bug. ***

Comment 6 Germano Massullo 2018-05-08 00:03:54 UTC
Created attachment 1432847 [details]
dnf.log

dnf log of f27->f28 upgrade that triggered the problem

Comment 7 Marek Blaha 2018-05-09 07:26:19 UTC
Hm, it looks like langpacks-it and glibc-langpack-it packages were not installed even before upgrade, so it was not the "dnf system-upgrade" what caused the problem.
I can see quite a lot of occurrences of this bug, all of them solved by installing glibc-langpack-*:

https://bugzilla.redhat.com/show_bug.cgi?id=1570924
https://bugzilla.redhat.com/show_bug.cgi?id=1573712
https://bugzilla.redhat.com/show_bug.cgi?id=1572679
https://forums.fedora-fr.org/viewtopic.php?id=67631
http://www.hack23.de/blog/2018/05/fedora-28-upgrade-problem-mit-locale-settings/

There is probably something wrong with dependencies, which caused that glibc-langpack-* was not installed at all. But I'm puzzled how locales could work without this package (until upgrade to f28).

I'm moving this bug to the glibc, just to ask if they have some suggestions where this bug could come from.

Comment 8 Florian Weimer 2018-05-09 07:59:18 UTC
(In reply to Marek Blaha from comment #7)
> There is probably something wrong with dependencies, which caused that
> glibc-langpack-* was not installed at all. But I'm puzzled how locales could
> work without this package (until upgrade to f28).

The best explanation so far is that existing files were still around in the file system after a package has been deinstalled, and the RPM database did not reflect that.  This can easily happen due to a system crash or the system administrator hitting ^C during a DNF operation.  Unfortunately, this could have happened years ago because we did not change the locale format for quite some time, and only Fedora 28 stopped using the old files due to a format change.

Comment 9 Alexandre Franke 2018-05-09 09:41:28 UTC
FWIW my machine is one I installed F26 on, did regular updates as they were available, upgraded to F27 when it came out, did more regular updates on, then upgraded to F28. I haven’t installed that many apps on it and I probably never removed anything from it.

Comment 10 Marek Blaha 2018-05-09 11:06:54 UTC
On F26 workstation you should have glibc-all-langpacks installed. That's probably why you do not need specific glibc-langpack-it. But according to attached log, you do not have this package installed neither.

You can try to explore why is that. This command could be a good starting point:
# dnf history list glibc-all-langpacks

Comment 11 Carlos O'Donell 2018-05-10 14:19:54 UTC
*** Bug 1565718 has been marked as a duplicate of this bug. ***

Comment 12 Carlos O'Donell 2018-05-10 14:22:14 UTC
*** Bug 1570924 has been marked as a duplicate of this bug. ***

Comment 13 Arne Ahrend 2018-05-10 15:07:37 UTC
It does not appear that I never had glibc-all-langpacks installed, yet this issue only manifested itself after the recent upgrade to FC 28:

Is there a way to get wide output from dnf history?

LANG=C dnf history  *c-*langpack*
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
   570 | install glibc-langpack-d | 2018-05-05 03:03 | Install        |    1   
   569 | system-upgrade upgrade   | 2018-05-05 01:49 | D, E, I, O, U  | 2847 EE
   537 | upgrade --refresh        | 2018-03-14 22:26 | E, I, U        |  109 EE
   534 | upgrade                  | 2018-03-10 17:15 | I, U           |  188 EE
   502 | system-upgrade upgrade   | 2018-01-25 00:42 | D, E, I, O, U  | 2656 EE
   501 | upgrade --refresh        | 2018-01-25 00:28 | E, I, U        |   39 EE
   468 | upgrade                  | 2017-10-27 20:55 | E, I, U        |   80   
   443 | --releasever=26 system-u | 2017-09-21 23:22 | D, E, I, O, U  | 2600 **
   433 | upgrade                  | 2017-09-05 21:12 | Update         |    8 **
   416 | upgrade                  | 2017-07-13 21:23 | E, I, U        |   41   
   387 | upgrade                  | 2017-06-23 22:16 | Update         |   16   
   370 | upgrade                  | 2017-06-12 21:24 | I, U           |   17   
   262 | upgrade                  | 2016-12-28 00:09 | E, I, U        |  119   
   239 | --releasever=25 system-u | 2016-12-01 15:48 | D, E, I, O, U  | 1753 EE
   174 | upgrade                  | 2016-08-21 14:06 | E, I, U        |  240   
   163 | reinstall glib*          | 2016-07-22 00:57 | Reinstall      |   11   
   139 | --releasever=24 system-u | 2016-06-21 21:11 | D, E, I, O, U  | 2104 EE

Comment 14 Alexandre Franke 2018-05-10 15:51:41 UTC
FWIW my system is F20 that’s been upgraded to the next version whenever it was available as shown by https://pastebin.com/mBDVZaP5

Comment 15 Marek Blaha 2018-05-11 10:50:54 UTC
(In reply to Arne Ahrend from comment #13)
> Is there a way to get wide output from dnf history?

You can get details of particular history record by using the info subcommand:
# dnf history info 163

Comment 16 Torsten Casselt 2018-05-11 17:49:02 UTC
I have two systems (laptops) here, one still on F27, the other one already on F28. I upgraded the second one via graphical method and it showed the problem of missing the langpack (de). Since I have a few installations in my environment where the users upgrade by themselves when I tell them that everything should work I want to make sure that this is fixed so they can upgrade without me installing the langpack everywhere.
I can provide information both from the upgraded plus from the laptop still on F27. Since we have information of upgraded systems already in the thread, I’ll provide information about the old one. Let me know what I can provide for you to fix the problem (maybe introduce an additional dependency in a F28 package langpack to pull the corresponding glibc-langpack in?).


sudo dnf history list glibc*langpack*
ID     | Befehlszeile             | Datum und Zeit   | Aktion(en)     | Verände
-------------------------------------------------------------------------------
   156 | system-upgrade upgrade   | 2018-01-06 22:10 | E, I, O, U     | 6214 EE
    33 | --releasever=24 system-u | 2016-08-20 22:37 | D, E, I, O, U  | 5346 EE


sudo dnf history info 33 | grep langpack
    Installieren  glibc-langpack-en-2.23.1-10.fc24.x86_64                                             @@commandline/24
    Installieren  libreoffice-langpack-en-1:5.1.5.2-3.fc24.x86_64                                     @@commandline/24


sudo dnf history info 156 | grep langpack
    Installieren  evolution-data-server-langpacks-3.26.3-1.fc27.noarch                         @updates
    Installieren  evolution-ews-langpacks-3.26.3-1.fc27.noarch                                 @updates
    Installieren  evolution-langpacks-3.26.3-1.fc27.noarch                                     @updates
    Aktualisiert  glibc-langpack-en-2.25-12.fc26.x86_64                                        (unknown)
    Aktualisiert  libreoffice-langpack-de-1:5.3.7.2-6.fc26.x86_64                              (unknown)
    Aktualisiert  libreoffice-langpack-en-1:5.3.7.2-6.fc26.x86_64                              (unknown)


So, yes, the glibc-langpack-de is not installed on the system:


rpm -aq | grep glibc-langpack
glibc-langpack-en-2.26-27.fc27.x86_64


Still, the UI is German. Any package I can query that helps you understand why this works?

Comment 17 Florian Weimer 2018-05-11 17:54:46 UTC
(In reply to Torsten Casselt from comment #16)
> So, yes, the glibc-langpack-de is not installed on the system:
> 
> 
> rpm -aq | grep glibc-langpack
> glibc-langpack-en-2.26-27.fc27.x86_64
> 
> 
> Still, the UI is German. Any package I can query that helps you understand
> why this works?

The most common cause for this is that there is a file /usr/lib/locale/locale-archive, but the file is not listed in the RPM database.  This happens if dnf/rpm is interrupted before the postuninstall scriptlet from glibc-all-langpacks runs.

Fedora 28 is no longer compatible with the older file format for this file, so it is ignored, and the locale data contained in it is not used.

Comment 18 johan 2018-05-11 19:36:43 UTC
I was adviced to put my comments in this bug (responding on remarks in bug 1565718).

> Interesting, you had a combined en_US and nl_NL.
I never looked at my locale settings before this issue occurred. I do like application menu's and errors in English, but probably set numeric and other settings to follow our local habits.

> My hypothesis is, as Florian stated also in bug 1574222, is that this may be a dnf upgrade issue with langpacks, and an old locale-archive file.

> How many upgrades has this system gone through?
Short: maybe 10.
Long: The system this occurred on is old and has gone through many updates. I have been using Fedora since ~FC4, and probably started fresh when building this PC in ~2008 (don't know the actual release number). Updating works great since yum/dnf, never anything I could not work around (but I am probably not a typical user).

Comment 19 Steeve McCauley 2018-05-12 15:59:23 UTC
After upgrading from F27 to F28, I was also not able to launch gnome-terminal with LANG=en_CA.UTF-8, after installing glibc-langpack-fr.x86_64 the terminal would launch.

Comment 20 Piotr Drąg 2018-05-13 18:37:41 UTC
*** Bug 1577330 has been marked as a duplicate of this bug. ***

Comment 21 Andrea Musuruane 2018-05-26 17:20:24 UTC
I also had the same issue after upgrading with dnf from F27 to F28. I couldn't run gnome-terminal, gnome wanted to change the folder names, and part of the user interface was in English. I had to install glibc-langpack-it.

Comment 22 Torsten Casselt 2018-05-31 19:16:04 UTC
(In reply to Florian Weimer from comment #17)
> The most common cause for this is that there is a file
> /usr/lib/locale/locale-archive, but the file is not listed in the RPM
> database.  This happens if dnf/rpm is interrupted before the postuninstall
> scriptlet from glibc-all-langpacks runs.
> 
> Fedora 28 is no longer compatible with the older file format for this file,
> so it is ignored, and the locale data contained in it is not used.

Thanks for the explanation of the cause.

Lots of users reported this issue now and since this is reproducible and there are a lot of installations out there that run the desktop in a language that is not English, this should be fixed somehow. Especially for casual users who might not find bug reports like this one because they search for the wrong terms (especially in their mother tongue).
Since this bug is assigned to Carlos O'Donell and this is really a case for QA: Do you plan to fix it? If not, can I help fixing it? This kind of bug should really not happen on an upgrade. The casual user will probably reinstall if this bug occurs because to him it looks like something went wrong in the upgrade process — while it did not, it is just one package to install…

Comment 23 Carlos O'Donell 2018-06-04 16:01:18 UTC
(In reply to Torsten Casselt from comment #22)
> (In reply to Florian Weimer from comment #17)
> > The most common cause for this is that there is a file
> > /usr/lib/locale/locale-archive, but the file is not listed in the RPM
> > database.  This happens if dnf/rpm is interrupted before the postuninstall
> > scriptlet from glibc-all-langpacks runs.
> > 
> > Fedora 28 is no longer compatible with the older file format for this file,
> > so it is ignored, and the locale data contained in it is not used.
> 
> Thanks for the explanation of the cause.
> 
> Lots of users reported this issue now and since this is reproducible and
> there are a lot of installations out there that run the desktop in a
> language that is not English, this should be fixed somehow. Especially for
> casual users who might not find bug reports like this one because they
> search for the wrong terms (especially in their mother tongue).
> Since this bug is assigned to Carlos O'Donell and this is really a case for
> QA: Do you plan to fix it? If not, can I help fixing it? This kind of bug
> should really not happen on an upgrade. The casual user will probably
> reinstall if this bug occurs because to him it looks like something went
> wrong in the upgrade process — while it did not, it is just one package to
> install…

Help us reproduce the issue in-situ so we can understand what broke and why?

The glibc-all-langpacks file always owns /usr/lib/locale/locale-archive.

Why and how are things out of sync on these users systems?

We don't know what kind of robustness fix we need without understanding the failure mode. That is to say, anything we put in might not do anything useful if we don't know what's wrong.

Comment 24 Florian Weimer 2018-06-04 16:14:02 UTC
(In reply to Carlos O'Donell from comment #23)
> Help us reproduce the issue in-situ so we can understand what broke and why?
> 
> The glibc-all-langpacks file always owns /usr/lib/locale/locale-archive.
> 
> Why and how are things out of sync on these users systems?

My theory is that it was a side effect of bug 1397087, where users hat to interrupt DNF to recover, without completing the transaction.

Comment 25 Miro Hrončok 2018-06-04 23:28:09 UTC
I haven't noticed any dnf hangs during the upgrade and I was affected by this.

Comment 26 Florian Weimer 2018-06-05 03:34:42 UTC
(In reply to Miro Hrončok from comment #25)
> I haven't noticed any dnf hangs during the upgrade and I was affected by
> this.

The hang would have happened several Fedora releases ago.

Comment 27 Steeve McCauley 2018-06-05 10:46:18 UTC
Shouldn't this issue have appeared in F27 if the hang bug affected uses with other langpacks in F26?  In fact, I never even had another langpack (other than en) installed until this happened to us.  These are system backups that contains a list of installed rpms from F24-F28,

# grep glibc-lang */root/bin/rpm.last.list
Fedora_24_TwentyFour/root/bin/rpm.last.list:glibc-langpack-en-2.23.1-11.fc24.x86_64       Sun 06 Nov 2016 02:00:57 AM EST
Fedora_25_TwentyFive/root/bin/rpm.last.list:glibc-langpack-en-2.24-10.fc25.x86_64         Tue 05 Sep 2017 02:00:11 AM EDT
Fedora_26_TwentySix/root/bin/rpm.last.list:glibc-langpack-en-2.25-12.fc26.x86_64         Fri 27 Oct 2017 02:01:14 AM EDT
Fedora_27_TwentySeven/root/bin/rpm.last.list:glibc-langpack-en-2.26-27.fc27.x86_64         Thu 15 Mar 2018 02:00:41 AM EDT
Fedora_28_TwentyEight/root/bin/rpm.last.list:glibc-langpack-fr-2.27-15.fc28.x86_64         Mon 28 May 2018 02:00:16 AM EDT
Fedora_28_TwentyEight/root/bin/rpm.last.list:glibc-langpack-en-2.27-15.fc28.x86_64         Mon 28 May 2018 02:00:11 AM EDT

We were happily using gnome shell before F28 without any issue, myself using most english and my SO mostly french, but we both switched keyboard input, dictionaries, etc without issue.  The weirdness only appeared after the update.

Comment 28 Florian Weimer 2018-06-05 10:50:50 UTC
(In reply to Steeve McCauley from comment #27)
> Shouldn't this issue have appeared in F27 if the hang bug affected uses with
> other langpacks in F26?

No, in Fedora 27, glibc could still use stale locale files from much earlier glibc versions.  The locale format only changed in Fedora 28, making the issue visible.

Comment 29 Yura 2018-06-17 14:06:28 UTC
Just for info got similar problem after upgrading F26->F28.
- Mate desktop was in English.
- console shows error with question signs
- even when set English in console some of those questions still appeared
installing glibc-langpack-en and glibc-langpack-uk solved problem.

PS but now disappointed kernel-PAE discontinued :(

Comment 30 Tomas Novotny 2018-06-24 13:20:50 UTC
Some info from casual user: I also see that bug on our shared home PC. We have two logins, one with en_GB with Czech formats and the second user has full cs_CZ. After F27->F28 upgrade the gnome-terminal didn't start and the second user wasn't able to login at all (as described in bug 1573683).

This system is from 2014. Packages are regularly updated (in fact, on every shutdown of any user if requested on logout screen). I think that system was upgraded on every Fedora release (i.e. no release was skipped), but some times after a very long time after official release (i.e. even more than year).

Obviously installing glibc-langpack-cs fixed it. I didn't play with langpacks so far:
[root@fuji log]# dnf history  *c-*langpack*
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    60 | install glibc-langpack-c | 2018-06-24 14:13 | Install        |    1   
    51 | --releasever=25 system-u | 2016-12-10 22:02 | D, E, I, O, U  | 2017 EE
    19 | --releasever=24 system-u | 2016-09-07 00:16 | D, E, I, O, U  | 2644 EE
[root@fuji log]#

Comment 31 Harald 2018-11-11 16:51:30 UTC
*** Bug 1648671 has been marked as a duplicate of this bug. ***

Comment 32 Florian Weimer 2018-11-12 09:54:07 UTC
See comment 17.  In all instances where more data was available, the file system contents and the RPM database were out of sync.  This is not something we can correct in glibc.

Comment 33 Harald 2018-11-12 18:49:36 UTC
@Florian Weimer: just one last thought (and i might be completely wrong): could it be that the scope/content of the langpacks changed from F27 to F28 or F29? I am sure I had never installed langpack_de on my F27, so it didn't get updated anyway, but i still used a German keyboard layout. 

Now with F29 i had to install the langpack_de in order to get the Germany keyboard layout (as it is a specific locale setting)? Otherwise my LC_ALL wasn't set, causing gnome-terminal to fail.

If so, the issue will only happen when upgrading from F27 or below to F28 or above, and will be gone for all other scenarios. And it would be special case for having English language with a German (or maybe other localization) keyboard layout?

Comment 34 Florian Weimer 2018-11-12 19:03:07 UTC
(In reply to Harald from comment #33)
> @Florian Weimer: just one last thought (and i might be completely wrong):
> could it be that the scope/content of the langpacks changed from F27 to F28
> or F29? I am sure I had never installed langpack_de on my F27, so it didn't
> get updated anyway, but i still used a German keyboard layout.

See comment 24 and comment 28.  It's like that this was a dormant issue for quite some time.

Comment 35 Sergio Basto 2019-04-16 06:20:18 UTC
while locale [1] have all set in en_US, in my env I got LANGUAGE=en_US:pt [2] and evolution runs translated to Portuguese , where LANGUAGE is setting ? 


[1]
locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[2]
env | grep pt
LANGUAGE=en_US:pt

Comment 36 Ondřej Pohořelský 2019-11-20 08:47:01 UTC
I'm right now experiencing same bug on Fedora 31 as fedora-review perl script is giving me this warning

>perl: warning: Please check that your locale settings:
>        LANGUAGE = (unset),
>        LC_ALL = (unset),
>        LC_CTYPE = "C.UTF-8",
>        LANG = "cs_CZ.UTF-8"
>    are supported and installed on your system.


>LANG=cs_CZ.UTF-8
>LC_CTYPE="cs_CZ.UTF-8"
>LC_NUMERIC="cs_CZ.UTF-8"
>LC_TIME="cs_CZ.UTF-8"
>LC_COLLATE="cs_CZ.UTF-8"
>LC_MONETARY="cs_CZ.UTF-8"
>LC_MESSAGES="cs_CZ.UTF-8"
>LC_PAPER="cs_CZ.UTF-8"
>LC_NAME="cs_CZ.UTF-8"
>LC_ADDRESS="cs_CZ.UTF-8"
>LC_TELEPHONE="cs_CZ.UTF-8"
>LC_MEASUREMENT="cs_CZ.UTF-8"
>LC_IDENTIFICATION="cs_CZ.UTF-8"
>LC_ALL=


>rpm -qa | grep glibc
>glibc-headers-2.30-5.fc31.x86_64
>glibc-langpack-cs-2.30-5.fc31.x86_64
>glibc-2.30-5.fc31.x86_64
>glibc-langpack-en-2.30-5.fc31.x86_64
>glibc-devel-2.30-5.fc31.x86_64
>glibc-common-2.30-5.fc31.x86_64
>glibc-all-langpacks-2.30-5.fc31.x86_64


In history I have installed F30 and immediately upgraded to F31 without any visible error. My system is in Czech and I use en_US keyboard layout

Comment 37 Florian Weimer 2019-11-20 09:51:48 UTC
(In reply to Ondřej Pohořelský from comment #36)
> I'm right now experiencing same bug on Fedora 31 as fedora-review perl
> script is giving me this warning
> 
> >perl: warning: Please check that your locale settings:
> >        LANGUAGE = (unset),
> >        LC_ALL = (unset),
> >        LC_CTYPE = "C.UTF-8",
> >        LANG = "cs_CZ.UTF-8"
> >    are supported and installed on your system.
> 
> 
> >LANG=cs_CZ.UTF-8
> >LC_CTYPE="cs_CZ.UTF-8"
> >LC_NUMERIC="cs_CZ.UTF-8"
> >LC_TIME="cs_CZ.UTF-8"
> >LC_COLLATE="cs_CZ.UTF-8"
> >LC_MONETARY="cs_CZ.UTF-8"
> >LC_MESSAGES="cs_CZ.UTF-8"
> >LC_PAPER="cs_CZ.UTF-8"
> >LC_NAME="cs_CZ.UTF-8"
> >LC_ADDRESS="cs_CZ.UTF-8"
> >LC_TELEPHONE="cs_CZ.UTF-8"
> >LC_MEASUREMENT="cs_CZ.UTF-8"
> >LC_IDENTIFICATION="cs_CZ.UTF-8"
> >LC_ALL=

Is the above the output from the locale command? If it does not show any errors, this is a different issue. If the system is generally using Czech as the system language and only Perl prints an error, this looks like a bug in Perl.

Comment 38 Ondřej Pohořelský 2019-11-20 10:57:30 UTC
>Is the above the output from the locale command?
Yes

Thank you for your reply and useful information


Note You need to log in before you can comment on or make changes to this bug.