I used Fedora-Workstation-Live-x86_64-24_Alpha-5.iso and installed it in qemu. I selected Japanese in the language selection of the installation. I added an US English keyboard layout and made it the first priority. After the installation started, I entered a password for root but created no user. After reboot, in gnome-initial-setup, I selected German as the language. After the setup was finished and gnome started, I found that the following glib packages were installed: [mfabian@localhost ~]$ rpm -qa | grep glibc glibc-common-2.23.1-5.fc24.x86_64 glibc-langpack-en-2.23.1-5.fc24.x86_64 glibc-2.23.1-5.fc24.x86_64 glibc-headers-2.23.1-5.fc24.x86_64 glibc-devel-2.23.1-5.fc24.x86_64 glibc-2.23.1-5.fc24.i686 glibc-all-langpacks-2.23.1-5.fc24.x86_64 [mfabian@localhost ~]$ If glibc-all-langpacks is installed, then glibc-langpack-en is redundant and only wastes disk space because glibc-all-langpacks already contains all the locales, including the English locales. And why glibc-langpack-en if the installation was done in Japanese? Shouldn't it rather be glibc-langpack-ja then?
Please attach the logs from /var/log/anaconda.
Oh, hey, reading. It's a live install. So regardless of what language is selected, the installed system gets whatever is in the live image. glibc-langpacks-all should be enough to make the locale data available. I'm not sure why glib-langpack-en was also installed. My suspicion is something in the dependency logic in the glibc package, as evaluated at the time the liveimg was created, so I'll try taking a look at that. As far as installing the langpack-xx packages, that's not really possible at install time from a live source. Maybe if we go back to writing langpacks.conf then dnf can figure it out afterwards.
(In reply to David Shea from comment #2) > Oh, hey, reading. It's a live install. So regardless of what language is > selected, the installed system gets whatever is in the live image. Ah, OK, good! So I should also test what happens when I use the netinstall instead. > glibc-langpacks-all should be enough to make the locale data available. I'm > not sure why glib-langpack-en was also installed. My suspicion is something > in the dependency logic in the glibc package, as evaluated at the time the > liveimg was created, so I'll try taking a look at that. As far as installing > the langpack-xx packages, that's not really possible at install time from a > live source. Maybe if we go back to writing langpacks.conf then dnf can > figure it out afterwards. I think it was installed because langpacks-en was installed. Installing langpacks-en pulls in glibc-langpack-en. But I have no idea why langpacks-en was installed because the installation was in Japanese.
Created attachment 1137831 [details] langpack-stuff-in-live-system.png
(In reply to Mike FABIAN from comment #3) > (In reply to David Shea from comment #2) > > Oh, hey, reading. It's a live install. So regardless of what language is > > selected, the installed system gets whatever is in the live image. [...] > I think it was installed because langpacks-en was installed. > > Installing langpacks-en pulls in glibc-langpack-en. > > But I have no idea why langpacks-en was installed because the installation > was in Japanese. As David explained above, this is because langpacks-en was already there in the live image and the installed system gets everything which was in the live image. So if langpacks-en is on purpose in the live image, there is actually no bug here, in this case this bug can be closed.
I'm moving this to dnf, since currently there is not a way to add langpacks to a liveinst installed system without explicitly installing them. Even if anaconda were to go back to writing the language data to langpacks.conf, it would not have any effect, probably due to dnf's insistence that plugins not modify the package transaction. Currently liveinst users are presented with options that appear to configure language support, but there is no way for that language support to take effect.
*** Bug 1322246 has been marked as a duplicate of this bug. ***
I've talked to Vratislav Podzimek and it seems like during Anaconda installation from live image they just copy the files - no DNF installation happens. Possible solutions are: 1) have inside livewimage langpacks-<lang> metapackages + all the relevant langpacks to the packages. Install them all at first, then remove not selected. i.e. dnfbase.remove("langpacks-<lang>") for each not selected lang. 2) let the user choose langpack only when he is connected to the internet and then after the copying the rpms run: dnfbase.install("langpacks-<lang>") for each selected lang 3) set oneshot systemd task After=network-online.target on the first boot which will call "dnf reinstall langpacks-<lang>" for each lang selected. (that would pull in all langpacks for each installed package) Proper solution would be probably 1) or 2) so the user boots into his selected language. David, what do you think? Probably with yum the langpacks were added into the first transaction of yum run based on the langpack conf (not during the installation).
@Jan: I would suggest that probably option 1 is the best way to go in terms of reliability, as it doesn't require internet access to work all the time. I believe the live images are already sized up for holding all the langpacks anyway, so simply doing this would restore previous behavior and add an optimization in the form of a post-install cleanup of unnecessary language packs.
Currently we have 80 langpacks-* subpackages which comes around 644 kB of total size.
(In reply to Parag Nemade from comment #10) > Currently we have 80 langpacks-* subpackages which comes around 644 kB of > total size. It must be more than 644 kB when considering the packages supplementing the langpacks-<lang> meta packages. One single glibc-langpack-<lang> is already more than 644 kB.
Any progress here? or langpacks will not be working again in F24? We are near to F24 Beta Freeze now. I wish dnf could have implemented hooks instead long before.
(In reply to Jan Silhan from comment #8) > 1) have inside livewimage langpacks-<lang> metapackages + all the relevant > langpacks to the packages. Install them all at first, then remove not > selected. i.e. dnfbase.remove("langpacks-<lang>") for each not selected lang. > 2) let the user choose langpack only when he is connected to the internet > and then after the copying the rpms run: dnfbase.install("langpacks-<lang>") > for each selected lang We are absolutely not going to do some kind of hybrid payload type for live + langpacks. If this cannot be solved in the live payload itself, it will need to be solved post-install, somehow.
Jan, Any updates here please?
This is going to impact badly for all non-english users, specifically when our change Glibc locale sub packaging is in place now. We must fix this before final release.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 1352350 has been marked as a duplicate of this bug. ***
Reproducer: https://bugzilla.redhat.com/show_bug.cgi?id=1352350#c11
We are now pushing updates on a fedora-24 instance so they have weak deps. Bases composes always have, so I am not sure how that helps things, but there it is.
What's the status of this bug? I installed Fedora Workstation 25 Beta earlier this week with de_DE.UTF-8 and langpacks-de.noarch wasn't installed automatically. So I guess this is still valid and got forgotten?
I did a fresh install of Fedora 25 today. The result is that zh_TW (Chinese (Taiwan), which is my locale) langpack of libreoffice is still not installed along with the installation process.
Description of problem: The bug still applies as no German language localisation was installed along the installation of the system. Version-Release number of selected component (if applicable): Fedora 25 How reproducible: Very. Steps to Reproduce: 1. Install a Fedora 25 in GNOME boxes with selecting the German language and German keyboard layout. 2. Expect German localization. Actual results: No German localization is installed. rpm -qa | grep langpack gives: glibc-all-langpacks-2.24-3.fc25.x86_64 libreoffice-langpack-en-5.2.3.3-4.fc25.x86_64 langpacks-en-1.0-8.fc25.noarch glibc-langpack-en-2.24-3.fc25.x86_64 Expected results: German localization is installed.
*** Bug 1421493 has been marked as a duplicate of this bug. ***
Is there any news regarding this issue?
Please lets form some specification that will be possible to provide by DNF.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
After a fresh installation of F26 with Chinese (Traditional) language, the langpack of LibreOffice is not installed during the process.
Are there any news regarding this issue?
(In reply to Jakob Jakobson from comment #28) > Are there any news regarding this issue? This is still definitely on our TODO list, just not yet assigned to a concrete Fedora release timeframe.
*** Bug 1524773 has been marked as a duplicate of this bug. ***