Hi, thanks for reporting this bug.

Thierry, any ideas ?

CC: (none) => thierry.vignaud
Summary: Locale settings problem => Locale settings problem (Hungary / English)
Source RPM: (none) => drakxtools-curses ?
Keywords: (none) => Triaged

I did not mentioned that didn't modified any locale setting. I don't know if it was obvious r not.

I got the following messages when ran dhclient:

/etc/sysconfig/i18n: line 9: warning: setlocale: LC_NUMERIC: cannot change locale (hu_HU.UTF-8): No such file or directory
/etc/sysconfig/i18n: line 9: warning: setlocale: LC_NUMERIC: cannot change locale (hu_HU.UTF-8)

Maybe help identify the problem.

Is this connected with https://bugs.mageia.org/show_bug.cgi?id=1063?

CC: (none) => filip.komar

@ Ilyés

Just to make sure: you did choose the LiveCD that contains the hungarian language, didn't you?


assigning to maintainer

Keywords: (none) => NEEDINFO
CC: (none) => marja11
Assignee: bugsquad => tmb
Summary: Locale settings problem (Hungary / English) => Mga2a1 Locale settings problem (Hungary / English) after install from LiveCD
Source RPM: drakxtools-curses ? => draklive-install

I choose the Americas+Europe1 live CD. But I did not set my locale or language to Hungarian, only the time zone.

Hmm, this seems to be a real bug as timezone should be able to be set independent of language and locale

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

Created attachment 2245 [details]
Bug Mageia 2 RC

Hi,

Still here in Mageia 2 RC Gnome 32 bits in French

thank you

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

This is still present in mga3 alpha3 LiveCD KDE, English-only.

LiveDVD KDE is OK.

See comment 7.

Keywords: NEEDINFO => (none)
Whiteboard: (none) => 3alpha3

Still exist in Mageia 3 beta 1, timezone messes the locale, this is what I got after setting the timezone to Baghdad (Using KDE LiveDVD x86_64):

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US.UTF-8:en_US:en",
        LC_ALL = (unset),
        LC_PAPER = "ar_IQ.UTF-8",
        LC_ADDRESS = "ar_IQ.UTF-8",
        LC_MONETARY = "ar_IQ.UTF-8",
        LC_SOURCED = "1",
        LC_NUMERIC = "ar_IQ.UTF-8",
        LC_TELEPHONE = "ar_IQ.UTF-8",
        LC_MESSAGES = "en_US.UTF-8",
        LC_IDENTIFICATION = "ar_IQ.UTF-8",
        LC_COLLATE = "en_US.UTF-8",
        LC_MEASUREMENT = "ar_IQ.UTF-8",
        LC_CTYPE = "en_US.UTF-8",
        LC_TIME = "en_US.UTF-8",
        LC_NAME = "ar_IQ.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

CC: (none) => mustafaa.alhamdaani
Hardware: i586 => All
Whiteboard: 3alpha3 => 3 Beta 1

I think this must be have a priority of "release_blocker" and a severity of "major", because it messes the locale of most people who change their timezone, it existed in Mageia 2 and prevented us from recommending Mageia to total noobs,it is a shame if Mageia 3 released with this bug after more than a year, should I change it?

(In reply to comment #14)
> I think this must be have a priority of "release_blocker" and a severity of
> "major", because it messes the locale of most people who change their timezone,
> it existed in Mageia 2 and prevented us from recommending Mageia to total
> noobs,it is a shame if Mageia 3 released with this bug after more than a year,
> should I change it?

There is something I don't understand, in the release notes it says the LiveDVD's are multilingual

https://wiki.mageia.org/en/Mageia_3_beta1#Live


but on the mirror I see only English is supported.

ftp://mageia.webconquest.com/iso/cauldron/Mageia-3-beta1-LiveDVD-KDE4-x86_64-DVD/Mageia-3-beta1-LiveDVD-KDE4-x86_64-DVD.langs

So I guess the other locales are indeed missing.

I'll download a LiveDVD and check.

Sorry, I'm sleeping

Arabic locales are on the Live DVD

Hi Marja,
I know the locales are on the LiveDVD, anything here:
ftp://mageia.webconquest.com/iso/cauldron/Mageia-3-beta1-LiveDVD-KDE4-x86_64-DVD/Mageia-3-beta1-LiveDVD-KDE4-x86_64-DVD.lst
with -ar- is Arabic, the problem is that the locale is being messed up by CHANGING THE TIMEZONE, I want US locale so I chose US language, but the installer is taking my timezone and ruining my locale by setting some to US an some to IQ.

Yes, I saw that just before I mentioned I had been sleeping :)

For now, if you only want US localization, you should choose a US time zone. 

The problem is, when you say you're somewhere else, settings for the currency, the default paper size etc. etc. will be adjusted to those of that country or region.

And because you didn't remove the tick before "Unused localization" in this screen
https://wiki.mageia.org/en/File:UnusedHardware.PNG
the correct settings for Iraq couldn't be found, so you got the error message. Else the settings would have been silently changed.

Btw, in some countries you may have problems using WLAN if you don't have the localization for that country.

I'll increase the priority of this bug though, because no one expects those settings to be changed along with the time zone.

Priority: Normal => High

Thank you, I think this should only relate to the language settings, or this can be fixed by adding a separate installer page for the locale.

(In reply to comment #19)
> Thank you, I think this should only relate to the language settings, or this
> can be fixed by adding a separate installer page for the locale.


The "time zones" we (and any other distro I know of) use, aren't just time zones like "UTC+8" or "UTC-5"

Having only that would make it needed for every user to change his time zone every time summer time switches to winter time or back.

Instead  (look in /usr/share/zoneinfo/) the "time zones" we have, are related to the area where you live. That makes auto-adjusting for summer/winter changes possible.

Now, towards most users, it would be unkind if the localisation settings we don't specifically ask for (so all settings apart from language and keyboard) wouldn't be set to those of the country he lives in, after he just told where he lives by setting his "time zone"

I don't see how this problem can be solved for the few people who want /all/ localization settings /except/ time zone to be those of another country.

However, I think it would be more clear what happens if, instead of asking something like

* Which is your time zone 

when starting the Live, we'd ask
 
* Choose your localization (includes time zone), other than for language and keyboard 



(Btw, Mustafa, in your case, locales-ar-2.16-3.mga3 shouldn't have been removed after you chose Iraq-Baghdad in the time zone screen, because it wasn't an unused locale. This seems a separate bug.)

Keywords: (none) => USABILITY
CC: (none) => doc-bugs, luigiwalser
Summary: Locale settings problem (Hungary / English) after install from LiveCD => unexpectedly, current way of setting time zone can also (try to) change other locale settings

> The "time zones" we (and any other distro I know of) use, aren't just time
> zones like "UTC+8" or "UTC-5"

I know it is not only UTC+3, but it is not locale, and all the major distos (I am a distro-hopper and openSUSE, Fedora, and Ubuntu are now installed on my system) doesn't set the locale according to time zone.

all distributions doesn't set the locale according to the time zone because I might be in another city (or country) for a vacation or a conference.
 
> I don't see how this problem can be solved for the few people who want /all/
> localization settings /except/ time zone to be those of another country.

When anybody travels a in a long journey the time zone will change, so I don't think they are "few"

locale must be set not according to timezone.

(In reply to comment #21)

> 
> When anybody travels a in a long journey the time zone will change, so I don't
> think they are "few"
> 
> locale must be set not according to timezone.

OK, I just checked what it is like with traditional installer, and that made me change my mind:

If I install with British English as preferred language, time zone will be set to Europe/London. Changing that to Europe/Amsterdam near the end of install doesn't affect the locale.

However, changing the Country/Region does affect it (of course)

Changing the Timezone when starting the LiveDVD seems to behave like changing Country/Region in traditional installer.

CC: luigiwalser => (none)

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

CC: (none) => tmassimi

I mention this also, which is still not fixed! :-/

The pb is in "en_BE" that does not match any dictionary. This setting was set up at installation time when you select a QUERTY keyboard + random country.

https://bugs.mageia.org/show_bug.cgi?id=5749

CC: (none) => dirteat

Still affecting me on M3 beta2

Created attachment 4175 [details]
patch to fix selection of unneeded locales in installer

ok, so after some research the cause of the bug has been found.

Mageia has he ability to choose both *language* and *country*
Language is used for choosing translations to be displayed, etc.
country for things like currency, etc.
(country may be deduced from other geographical settings rather than choosen directly, but that is not the problem).

GNU libc locales embedd both concepts (language and country) in a single locale.
Obviously those exists for only some combinations.

For cases were an existing matching locale doesn't exists, Mageia chooses two locales, one for the language oriented settings, and another four the country oriented settings.

Until ere it's all fine.

Now the problem is in in the LiveCD / LiveDVD installer.
Unlike normal installer where packages to be installed are choosen; here we have a set of "all packages", and "uneeded" ones are removed.
The problem was obviously the installer didn't see the "need" for the locales-xx package for country; only language was checked.

The attached patch fixes that
(or should do; didn't tested, but the idea is to check for *both* $locale->{lang} and $locale->{country}, which can lead two *two* neeeded locales-xx packages

That was exactly my point in
https://bugs.mageia.org/show_bug.cgi?id=5749

that not all combinations exist. Well done for the fix!

Any chance you can have a look to the above bug as well, I think the same issue propages to the dictionnaries as well?

Cheers,
Chris.

Thanks Pablo for working on this, is there anything we can test?

Adding Thomas in case this can still be included in mga4 before release.
It may be too late.

CC: (none) => eeeemail, tmb

Still present in Mageia 4 RC

(In reply to claire robinson from comment #29)
> Adding Thomas in case this can still be included in mga4 before release.
> It may be too late.

No:
The patch is buggy (several perl errors) and has not been tested.

Created attachment 4899 [details]
fix selection of unneeded locales in installer v2 (fixed

fixed but still need testing

Attachment 4175 is obsolete: 0 => 1

How can I test it?

Still valid in Mageia4 pre-final.

CC: (none) => stormi

Testing Mageia 4 about-to-be-released on real hardware.

[Do not recall ever choosing 'locale'; is it taken from language? Cymraeg is UK].

Installed 32-bit Classic with 6 desktops, language Cymraeg, [locale UK], timezone Paris, UK keyboard.
*Nowhere* in this system does the problem show. Not on any desktop including Gnome & KDE, with either a Terminal window or virtual console.

Installed 64-bit Live Gnome DVD and 64-bit Live KDE DVD on real hardware. Language Cymraeg, [locale UK], keyboard French, timezone Paris.
Gnome: did *not* show the problem from either Terminal or virtual console.
KDE: KONSOLE alone is the culprit, *not* virtual consoles.

Conclusion: now just for Konsole when Live KDE DVD installed.

CC: (none) => lewyssmith

KDE 32bits LiveCD, in live mode and after installation too, errors are seen not only in konsole but in xterm too.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_GB.UTF-8:en_GB:en",
        LC_ALL = (unset),
        LC_PAPER = "fr_FR.UTF-8",
        LC_ADDRESS = "fr_FR.UTF-8",
        LC_MONETARY = "fr_FR.UTF-8",
        LC_SOURCED = "1",
        LC_NUMERIC = "fr_FR.UTF-8",
        LC_TELEPHONE = "fr_FR.UTF-8",
        LC_MESSAGES = "en_GB.UTF-8",
        LC_IDENTIFICATION = "fr_FR.UTF-8",
        LC_COLLATE = "en_GB.UTF-8",
        LC_MEASUREMENT = "fr_FR.UTF-8",
        LC_CTYPE = "en_GB.UTF-8",
        LC_TIME = "en_GB.UTF-8",
        LC_NAME = "fr_FR.UTF-8",
        LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
[samuel@localhost ~]$ 

And in tty console after login:
-bash: warning: setlocale: LC_NUMERIC: cannot change locale (fr_FR_UTF-8): No such file or directory
-bash: warning: setlocale: LC_NUMERIC: cannot change locale (fr_FR_UTF-8)

Yes, fix in comment 32 is not merged as no-one has tested/validated it yet

Re comment 36
I do not have xterm in my installed system, but can believe this.
As for the TTY console warnings, yes. But since they only appear once, they are trivial compared to the main complaint.

The bug is still valid in Mageia 4.1, and I guess it affects Mageia 5 beta1 too. 

There is a fix in comment 32, but it's not particularly easy for end users to try it. What should be patched? draklive-install, then rebuild the RPMs and create one's own Live ISOs?

If there's a documented way to test draklive-install patches, I'd be glad to do it, if not, maybe it could be included for testing in the next set of Mageia 5 beta1 ISOs?

I'd like to increase the priority of this bug to release_blocker, not that it's _that huge_ an issue, but it would be really great to fix this once and for all. I guess lots of users selected timezones that don't fit their language choice, and it's annoying to have those perl warnings everytime you time anything in a terminal. WDYT?

CC: (none) => remi

I'll merge the fix for next beta1 build so we get it tested.

Priority: High => release_blocker
Status: NEW => ASSIGNED
Whiteboard: 3beta2 => 5beta1

Thanks Thomas!

I confirm the bug fixed on the Mageia 5 beta1 Live DVDs, at least with the following configuration:
- French language
- Danish timezone
- French keyboard

I'll try something more exotic next (different language and keyboard).

Previous comment was when installing from the Live environment. With a direct install without booting the Live environment, the issue shows up again (though with a more funky setting: German language, French keyboard, Danish timezone):

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "de_DE.UTF-8:de",
        LC_ALL = (unset),
        LC_PAPER = "da_DK.UTF-8",
        LC_ADDRESS = "da_DK.UTF-8",
        LC_MONETARY = "da_DK.UTF-8",
        LC_SOURCED = "1",
        LC_NUMERIC = "da_DK.UTF-8",
        LC_TELEPHONE = "da_DK.UTF-8",
        LC_MESSAGES = "de_DE.UTF-8",
        LC_IDENTIFICATION = "da_DK.UTF-8",
        LC_COLLATE = "de_DE.UTF-8",
        LC_MEASUREMENT = "da_DK.UTF-8",
        LC_CTYPE = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NAME = "da_DK.UTF-8",
        LANG = "de_DE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").


I will try again with my "funky" setting from the booted Live ISO to see if I can reproduce or not.

Same issue when installing from a booted Live environment with German language, French keyboard, Danish timezone. Since it worked with French language & keyboard and Danish timezone, I guess that the patch does not cover cases where all three components refer to different countries?

I also notice that the installer suggests to remove locale-da, even though it's listed in the Live environment when running "locale". But IMO we should keep to the language setting and set everything to de_DE.UTF-8, and let users further customise what they want.

Assigning back to Thierry as per comments 42, 43 and 44.

Assignee: tmb => thierry.vignaud

Reverting status to "NEW" because there is a different assignee now.

Status: ASSIGNED => NEW

Seems to also apply to traditional installs, or is there a separate bug for that?

Installed via Mageia 4.1 i586 FreeDVD in english, applied latest updates, and updated via Mageia 5 beta1 i586 FreeDVD, selecting german language and keyboard. After the upgrade, this came up, although everything is set to de_DE.UTF-8 - but it seems installer didn't install locales-de ... ?

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "de_DE.UTF-8:de",
        LC_ALL = (unset),
        LC_PAPER = "de_DE.UTF-8",
        LC_ADDRESS = "de_DE.UTF-8",
        LC_MONETARY = "de_DE.UTF-8",
        LC_SOURCED = "1",
        LC_NUMERIC = "de_DE.UTF-8",
        LC_TELEPHONE = "de_DE.UTF-8",
        LC_MESSAGES = "de_DE.UTF-8",
        LC_COLLATE = "de_DE.UTF-8",
        LC_IDENTIFICATION = "de_DE.UTF-8",
        LC_MEASUREMENT = "de_DE.UTF-8",
        LC_CTYPE = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NAME = "de_DE.UTF-8",
        LANG = "de_DE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").


$ rpm -qa | grep locales
locales-en-2.20-4.mga5
locales-2.20-4.mga5


FWIW, the frequent perl caller which causes all that output for every shell command run is /etc/bashrc which uses perl to show pwd, which is a pretty ugly fix for https://bugs.mageia.org/show_bug.cgi?id=1623 .

(In reply to Florian Hubold from comment #47)
> Seems to also apply to traditional installs, or is there a separate bug for
> that?
> 
> Installed via Mageia 4.1 i586 FreeDVD in english, applied latest updates,
> and updated via Mageia 5 beta1 i586 FreeDVD, selecting german language and
> keyboard. After the upgrade, this came up, although everything is set to
> de_DE.UTF-8 - but it seems installer didn't install locales-de ... ?
> 

> 
> $ rpm -qa | grep locales
> locales-en-2.20-4.mga5
> locales-2.20-4.mga5
> 

I've changed the language of systems by upgrade-installing while picking the new language in the first language choice screen many times, but didn't do that very recently. I don't know why that stopped working. locales-de is on the Mageia-5-beta1-i586-DVD:
ftp://mageia.webconquest.com/iso/cauldron/Mageia-5-beta1-i586-DVD/Mageia-5-beta1-i586-DVD.idx

(I assume that is the iso you used?)

If you're sure that you selected German in the *first* language choice screen, so the screen shown here http://doc.mageia.org/installer/4/en/content/selectLanguage.html or already before that - so in the bootloader screen - and if this isn't bug 14473, then please file a separate bug report (I didn't find one against installer and drakx-installer-stage2 with this problem:
https://bugs.mageia.org/buglist.cgi?f1=cf_rpmpkg&order=Importance&list_id=36955&o1=substring&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&v1=drakx-installer-stage2&component=Installer&product=Mageia )

> 
> FWIW, the frequent perl caller which causes all that output for every shell
> command run is /etc/bashrc which uses perl to show pwd, which is a pretty
> ugly fix for https://bugs.mageia.org/show_bug.cgi?id=1623 .

If you're sure it is that fix that caused it, then please say so in that report and reopen it (or file a new report and assign to Shlomi)

(In reply to Marja van Waes from comment #48)
> (In reply to Florian Hubold from comment #47)
> > FWIW, the frequent perl caller which causes all that output for every shell
> > command run is /etc/bashrc which uses perl to show pwd, which is a pretty
> > ugly fix for https://bugs.mageia.org/show_bug.cgi?id=1623 .
> 
> If you're sure it is that fix that caused it, then please say so in that
> report and reopen it (or file a new report and assign to Shlomi)

What Florian meant is that the symptom (i.e. the "perl: warning: Setting locale failed." stuff) is caused by the ugly fix for bug 1623, but it's not related to the actual cause of this bug (which is that locales are not properly installed or get mixed up on multi-cultural installs :).

(In reply to Rémi Verschelde from comment #49)
> (In reply to Marja van Waes from comment #48)
> > (In reply to Florian Hubold from comment #47)
> > > FWIW, the frequent perl caller which causes all that output for every shell
> > > command run is /etc/bashrc which uses perl to show pwd, which is a pretty
> > > ugly fix for https://bugs.mageia.org/show_bug.cgi?id=1623 .
> > 
> > If you're sure it is that fix that caused it, then please say so in that
> > report and reopen it (or file a new report and assign to Shlomi)
> 
> What Florian meant is that the symptom (i.e. the "perl: warning: Setting
> locale failed." stuff) is caused by the ugly fix for bug 1623, but it's not
> related to the actual cause of this bug (which is that locales are not
> properly installed or get mixed up on multi-cultural installs :).

That's exactly how I understood it, if I had understood it differently I would have suggested to also set this bug report to depend on that one ;-)

But please do continue commenting whenever you think I misunderstood something! I can be very good at misinterpreting things, and incidentally re-reading what I wrote in a bug report makes me wonder where my brain was at the time I wrote it.

Thierry anu input on that one ?

Decreasing priority, this one has been around for years and should not prevent us from releasing Mageia 5. I'll make sure it's part of the mga6 features though.

Priority: release_blocker => High

(In reply to Rémi Verschelde from comment #52)
> Decreasing priority, this one has been around for years and should not
> prevent us from releasing Mageia 5. I'll make sure it's part of the mga6
> features though.

Being around for years (long before Mageia 2) should be a reason to increase the priority, not decrease it, adding one page to select the locale to the installer that should be easy to implement to anybody who works on the installer, is there anybody who works on drakx-installer?

> adding one page to select the locale to the installer that should be easy to
> implement to anybody who works on the installer, is there anybody who works
> on drakx-installer?

Please check our release blockers list: https://lstu.fr/Mga5ReleaseBlockers
We have plenty to do already on the installer, so no, being around for years is no longer a compelling reason to be a release_blocker. If it hasn't been touched during the Mageia 5 release cycle, it's not right now when we're struggling with the final release that we should make sure to fix it.

(In reply to Mustafa Muhammad from comment #53)

You already have it, it's the "Mulitple languages" button

As stated in bug 15655 comment 3, this bug causes major issues with GNOME because some applications like gnome-terminal won't start if the timezone-related locale is missing.

Therefore I'm setting this one as release_blocker again, because IMO we really need to find a fix for it, the inconvenience is now more than the annoying perl warning from comment 0.


To summarize the current bug, since it has evolved since 2011:
- When installing from the Live ISOs, the language choice determines which locale(s) should be kept when installing.
- However, choosing a timezone that does not match the language-specific locale produces mixed definitions in the locale environment variable, as in this example (American English language, Europe/Berlin timezone):

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

- The logic in itself is good: if I live in Berlin, I probably want to use the German numeric, monetary, paper, etc. conventions.
- The problem is that locales-de is _not_ marked as needed, so it is uninstalled when draklive-install removes unused locales, thus leading to various locale-related issues like this very bug or bug 15655.


Thierry, do you think you could add a patch to make sure that the timezone-specific locale gets installed?

Priority: High => release_blocker

/me stealthily adds Martin in CC... :-)
(summary of the current bug status in comment 56)

CC: (none) => mageia

Ahh I see what you did there :)

Created attachment 6347 [details]
Patch to prevent country/timezone locale package being removed during live install

Sometimes sneakiness pays off :-)

Try this. The code to do the job was already there - it just needed a small modification to make it work.

commit dfa0fa4623025203d3ca1ed2a374d8e0d505a0b3
Author: Martin Whitaker <mageia@...>
Date:   Fri Apr 24 22:38:06 2015 +0100

    Ensure country/timezone locale is kept when removing unused locale packages.
    
    The country locale needs to be converted to a base locale name when
    generating the list of package names (mga#3723).
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=dfa0fa4623025203d3ca1ed2a374d8e0d505a0b3

Thanks Martin, I've added your patch in drakx 16.88.

Note that you can mention the bug report with mga#XXXX in the commit log to link it to the bug report like done in comment 60 (I edited the patch header to achieve that this time).

I've tested the patched drakx with boot.iso (thus testing the classical installer), and I can confirm that the bug is fixed (even though I had never really tried to reproduce it with the classical installer, since the timezone definition is less prominent).

I did a classical installation in French, and in the summary screen I chose Germany as my country; on the installed system, I have locales-fr and locales-de installed.

I tested it with a patched live image (distrib-lzma.sqfs), starting an install from the Live desktop, and selecting English as my language and Berlin as my location. Before the patch, locale-de was listed as one of the locales that would be removed, after the patch it wasn't (I didn't actually go on to complete the install).

btw, when testing fixes like this on live medias, you dont need to patch the live image... you can also add online medias and install the updates before starting the install :)

(In reply to Thomas Backlund from comment #64)
> btw, when testing fixes like this on live medias, you dont need to patch the
> live image... you can also add online medias and install the updates before
> starting the install :)

Even if the patch is in drakx-installer-stage2?

stage2 is only classical installer, so if something is broken there it happends during my generation of live medias, as that's the only time stage2 affects the isos.

after that its only drakxtools and draklive-install that affects installation

Ah it must be drakxtools that contain the fix then; since part of the code is shared (and the patch affects perl-install/pkgs.pm, which is in both packages), I'm always a bit unsure which package is used and when. Thanks for the clarification about stage2 being only the classical installer.

From what I could test, comment 60 fixed the bug. It can be reopened if need be if the Mageia 5 pre-final ISOs do not confirm this.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

The monster is back on Cauldron for what I can see!

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

More information would be needed to reopen a bug fixed since 1 year. Unless you 100% sure to be experimenting the exact same issue as in comment 0, please open a new bug report with detailed information (and maybe mention this bug 3723 for the reference, in case it would be a duplicate in the end).

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

This issue is also seen while upgrading from Mageia 6 to Cauldron in the terminal output. Can we reopen?

CC: (none) => hamnisdude

No, please open a new bug report (and feel free to reference this one for history). Similar symptoms do not necessarily mean that it's the same bug.