Bug 1170730

Created attachment 964776 [details]
2

Created attachment 964777 [details]
3

So the problem is that it's passing a list of package names and/or virtual Provides to a PackageKit interface that accepts only package names.

Hi Germano,

The system-config-language still uses yum and "yum install kde-l10n-it" works fine. Note, langpacks plugin needs translation packages real name in the format <pkgname>-<locale_code>. The kde-l10n package is not following this guideline.

The code in system-config-language to get package list is now similar to yum-langpacks code. The yum-langpacks just reads conditional from comps like in this case "kde-l10n-%s", so ideally package should have got named like kde-l10n-it. Langpacks plugin works on locale code but yes I have added many tweaks to fix such inconsistencies.

The proposal I gave to FPC is at https://fedoraproject.org/wiki/PackagingDrafts/LangPack and approved by them is at https://fedoraproject.org/wiki/PackagingDrafts/LangPack2

NOTE: This is still not added to Naming Guidelines by FPC. I will ping them later.

It took me some time to find when virtual provides were added in kde-l10n package but here is that http://pkgs.fedoraproject.org/cgit/kde-i18n.git/commit/?id=b7c5a12cc0c4eb907253bb44272089022e2f06cb commit. They are first added in kde-i18n package which then renamed to kde-l10n for KDE 4.x series.

There is one more reference bug https://bugzilla.redhat.com/show_bug.cgi?id=233223#c4

As said earlier, there are such many inconsistencies in fedora langpack packages and I have been asked again and again to add special parsing for such problems instead those package owners to rename their packages. Thankfully some added virtual provides and helped yum-langpacks to work fine.

So, the question is how selection of kde-l10n-it instead kde-l10n-Italian is affecting you?

(In reply to Parag from comment #4)
> So, the question is how selection of kde-l10n-it instead kde-l10n-Italian is
> affecting you?

As shown in 2 and 3 screenshots, s-c-l does not install kde-l10n-it nor kde-l10n-Italian, even if in screenshot 1 package kde-l10n-it has been selected.
yum/dnf instead correctly select kde-l10n-Italian if you ask for kde-l10n-it

(In reply to Parag from comment #4)
> The system-config-language still uses yum and "yum install kde-l10n-it"
> works fine. Note, langpacks plugin needs translation packages real name in
> the format <pkgname>-<locale_code>. The kde-l10n package is not following
> this guideline.
I think you should report that to the Fedora Engineering Steering Committee to finally solve this conflict.

Thanks and sorry I should have checked this in KDE before above comment. I was knowing something came up while moving system-config-language to use packagekit but forgot that. I remember now that packagekit do not resolve virtual provides.

Let me check what I can do to fix this. I will comment when I get some solution.

kde-l10n already has the virtual Provides. The problem is that system-config-language does not resolve them (but expects the PackageKit interface to resolve them, which it doesn't).

Now I have been suggesting we rename the packages to fit the standard convention, which is also how upstream names the tarballs, for a while. It might be the best solution after all.

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

Note here, if someone from KDE SIG can update that if they still have no plans to rename packages then only I will check system-config-language code and will see if I can fix it there by adding special parsing. 

But I also want to add here that we have now https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28langpacks.29 in effect.

Any updates here? We are now started with F22 development. We can rename packages now.

Let me move this to kde-l10n.

I can certainly rename the kde-l10n packages if that is needed (it's that until now, I've been consistently told that was not required, and that the virtual Provides: were enough).

Happy to read above comment :)

Let me do some analysis if there will be any inconsistency in usage of any kde-l10n-<localecodes> with langpacks plugin. I will comment here by tomorrow.

Looks like only 2 locales

1) Venda langauage, langcode should be used "ve" and not "ven"
we have /usr/share/locale/ve locale file.

2) I think its good to use the same virtual provides ca-valencian as a langcode for Catalan-Valencian langpack. 

rest all virtual provides names looks fine to become actual package names.

Created attachment 980378 [details]
This modified spec should rename package

Tested this spec with copr build https://copr.fedoraproject.org/coprs/pnemade/misc/build/67691/

seems dnf update to this copr repo worked fine.

fyi, you included some other unrelated changes as well

but I think I can work with that, rather than doing it from scratch.

Committed,
http://pkgs.fedoraproject.org/cgit/kde-l10n.git/commit/?id=2c52b7ddcfd530370faf042e5780ce01e4f1f60f

Sorry I forgot to mention I removed some old obsoletes as we added new obsoletes and Group tag from all subpackages.

Thank you for committing the required changes for this bug.

We worked around the system-config-language deficiency in kde4's kde-l10n translations, but doing the same with qt5/kf5 will be not practical.

What kde-sig would like to see from system-config-language:

* fix to recognize <pkg>-<locale> virtual Provides too and not just real package names (like yum-langpacks did)

or possible hack/workaround in the meantime:
* upon any request to install langpacks for new locale, check if qt5-qtbase is installed and if so, pull qt5-qttranslations into the transaction.

Can someone please provide more details here? Sorry I do not follow or use KDE much, only for testing some features/bug. I can tweak the langpacks code if needed.

Sure, in the kde-l10n case, you asked us to rename the packages to
kde-l10n-<locale>  (ie, kde-l10n-de)
from
kde-l10n-<fullname> (ie, kde-l10n-German)

because system-config-language wasn't able to handle that
kde-l10n-German included:
Provides: kde-l10n-de
properly

Well, making the kde-l10n change was relatively easy, but doing that for qt5-qttranslations will be *much* harder and invasive, so what I'm asking is to either

1.  fix system-config-language to work properly with packages that simply:
Provides: <foo>-locale
too, instead of insisting a real package named <foo>-locale exists

or

2.  always install qt5-qttranslations in the special case that qt5-qtbase is installed (and an additional language pack is being requested).


Does that help?

The thing is that there is one qt5-qttranslations package with all translations, and we are thinking of just adding Provides: qt5-qtbase-$lang for every language it contains.

I looked into current kde-l10n.spec and qt5-qttranslations.spec files. In current scenario, if the case is that when kde-l10n-de gets installed qt5-qttranslations should also be installed then adding "Recommends: qt5-qttranslations" to every kde-l10n-* subpackage works fine.

If there are plans to add subpackaging per locale based then can you confirm you people want to do that as like qt5-qttranslations-de?

I am still not clear what is getting changed. Please someone give more dependency details. Also, if there are new language packs then can we add langpacks comps entry for that?

Recommends won't work for yum

As far as qt5-qttranslations, yes, I was planning on adding Provides:
qt5-qttranslations-de
etc...
as appropriate (not done yet)

Re: comps
comps doesn't include langpacks anymore (not for awhile), so that's not a viable option.

Re: comps
I take it back, there are language support groups, but they're generally only for fonts and input methods these days.

qt5-qttranslations Provides committed:
http://pkgs.fedoraproject.org/cgit/qt5-qttranslations.git/commit/?id=0a49e80390b69a4403df99cffe55365a3d7feb78

qt5-qttranslations-5.4.1-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/qt5-qttranslations-5.4.1-2.fc22

(In reply to Rex Dieter from comment #24)
> Re: comps
> I take it back, there are language support groups, but they're generally
> only for fonts and input methods these days.

I meant to say if there is new base package is introduced that provides language packages then if base package is installed on the system langpacks plugin can pull its translations. After looking into your change. I see that you should add to comps file as

diff --git a/comps-f22.xml.in b/comps-f22.xml.in
index 64a253c..651a7ba 100644
--- a/comps-f22.xml.in
+++ b/comps-f22.xml.in
@@ -7567,6 +7567,7 @@
     <match install="moodle-%s" name="moodle"/>
     <match install="mythes-%s" name="mythes"/>
     <match install="nqc-doc-%s" name="nqc-doc"/>
+    <match install="qt5-qtbase-%s" name="qt5-qtbase"/>
     <match install="sagemath-doc-%s" name="sagemath-doc"/>
     <match install="stardict-dic-%s" name="stardict"/>
     <match install="tagainijisho-dic-%s" name="tagainijisho-common"/>

Above is the patch for comps-f22.xml.in file for its current checkout.

This will then ensure that if and only if qt5-qtbase is installed on the system then langpacks plugin will pull the qt5-qtbase-%s package.

At least I will need this first to work on langpacks plugin code modification.

Thanks.

I really need above to test langpacks plugin so I gone ahead and make the changes in rawhide comps only for now.

Looks like changes to F23 comps are working and my local modified copy of dnf-langpacks can now pick qt-qttranslations. Therefore, making the changes to F22 comps also.

Note, I am doing some testing with upcoming dnf-langpacks release now.

OK, so the langpack pkg doesn't *have* use the same basename?  Would adding Provides like:

qt5-qttranslations-$locale

combined with comps change:

<match install="qt5-qttranslations-%s" name="qt5-qtbase"/>

work too?

Yes that should work fine.

Also, dnf-langpacks-0.9.0-2 is submitted as an update for F21+ releases which should show corresponding qt5-qttranslations package if qt5-qtbase is installed for "dnf langinfo <locale> and dnf langinstall <locale>" commands.

About this bug, I will look into system-config-language code modification. As we know system-config-language uses yum currently and the requested fix for this bug is only available in dnf-langpacks. I am planning to drop yum support in F22+ system-config-language and have it only working with dnf but need to check if other spins still want to use yum.

Hi Parag, on F22 TC5 I have found similar problems of F20: system partially translated in Italian, the s-c-l cursor is setted on Italian language but kde-l10n-it package is not installed. To install it I must switch in s-c-l to another language and then switch again to Italian

I suppose you have installed your system in Italian language. Is it that you installed from KDE Live iso? If so then I just did its testing and found again anaconda-langpacks yum plugin not working. But this time I see that anaconda stopped using yumpayload.py and moved to dnfpayload.py where the anacoda-langpacks integration is not yet coded.

I have already that request pending to anaconda developers. I will check on this.

The fact that kde-l10n-* is not on the KDE image is expected, it has always been like that, for space reasons. What should happen is that setting the language to Italian in s-c-l drags it in. Now the problem is that if you already select Italian in liveinst, it happily sets the system language to Italian, assuming the langpacks are already there, which is not necessarily the case. Then s-c-l does not realize it needs to install anything unless you change to another language and back.

So the problem is in liveinst or s-c-l, not in the payload code.

(In reply to Parag from comment #34)
> I suppose you have installed your system in Italian language.
Yes

> I have already that request pending to anaconda developers. I will check on this.
Any news?

(In reply to Kevin Kofler from comment #35)
> The fact that kde-l10n-* is not on the KDE image is expected, it has always
> been like that, for space reasons.
The Fedora Spins ISOs are no longer able to be burned to Compact Discs (>700MB), so I think there are no more space reasons....

Space is always (and still is) an issue.

In particular, including all kde-l10n-* would probably blow even our current 1.4 GB size target.

Hi Germano,
   I am not seeing langpacks plugin working soon while doing an anaconda installation. Anaconda people are saying https://bugzilla.redhat.com/show_bug.cgi?id=1178969#c6
   So, for now one need to manually install langpacks using its command langinstall or system-config-language package.
   Btw I have enabled the "Ok" button in system-config-language UI. You should be able to install now any remaining langpack packages for your default language. This change is available in system-config-language-2.4.2 builds in F22+ releases.

qt5-qttranslations-5.4.1-2.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

I suppose this bug is fixed already in F22. Please open new bug for any other issues.