The kde5.eclass itertates over all subfolders of "po/" in the source tree and deletes all translations not found in the variable ${LINGUAS}. According to the spec for EAPI6 ( or any other EAPI ), this variable is not provided to the ebuild or eclass. It is a USE_EXPAND variable and should be used only this way. Paludis does not set this variable and forbids to set USE_EXPAND variables as environment variable. Reproducible: Always Steps to Reproduce: 1. install any kde5.eclass based package with paludis/cave Actual Results: no translations are installed even if LINGUAS is set in the global use.conf Expected Results: the translations for the configured linguas should be installed
(In reply to Thomas Berger from comment #0) > According to the spec for EAPI6 ( or any other EAPI ), this variable is not > provided to the ebuild or eclass. It is a USE_EXPAND variable and should be > used only this way. Which section of the spec says this?
Created attachment 432284 [details, diff] example patch to use linguas I attached a hacky patch to use the USE_EXPAND useflags for LINGUAS. As not all packages have translations and the provided linguas must not match for all packages this should be handled with a seperate eclass.
(In reply to Michael Palimaka (kensington) from comment #1) > (In reply to Thomas Berger from comment #0) > > According to the spec for EAPI6 ( or any other EAPI ), this variable is not > > provided to the ebuild or eclass. It is a USE_EXPAND variable and should be > > used only this way. > > Which section of the spec says this? Chapter 11 The Ebuild Environment 11.1 Defined Variables https://projects.gentoo.org/pms/6/pms.html#x1-11800011.1
(In reply to Thomas Berger from comment #3) > (In reply to Michael Palimaka (kensington) from comment #1) > > (In reply to Thomas Berger from comment #0) > > > According to the spec for EAPI6 ( or any other EAPI ), this variable is not > > > provided to the ebuild or eclass. It is a USE_EXPAND variable and should be > > > used only this way. > > > > Which section of the spec says this? > > Chapter 11 > The Ebuild Environment > > 11.1 Defined Variables > > https://projects.gentoo.org/pms/6/pms.html#x1-11800011.1 That only lists variables that must be defined by the package manager. It doesn't say we can't operate on other environment variables, and indeed I believe many autotools packages behave in the same way that is happening here.
(In reply to Michael Palimaka (kensington) from comment #4) > That only lists variables that must be defined by the package manager. It > doesn't say we can't operate on other environment variables, and indeed I > believe many autotools packages behave in the same way that is happening > here. LINGUAS is not defined in the "make.defaults" file of the most profiles. If a package manger is written according to the specs LINGUAS must be exported in the "embedded" profile, but there is no requirement in the specs for others. Except where otherwise noted, all variables set in the active profiles’ make.defaults files must be exported to the ebuild environment." The variable MAY be there. Either the spec or the ebuilds/eclasses need to be fixed.
(In reply to Michael Palimaka (kensington) from comment #4) > I believe many autotools packages behave in the same way that is happening > here. Packages that use the gettext autotools macros (/usr/share/aclocal/po.m4) behave slightly differently than kde5.eclass: If LINGUAS is set in the environment, it acts as a filter on which translations get installed. If LINUGAS is unset, all translations are installed. I think the practical result is that paludis ends up installing all translations for autotools projects, whereas portage would export LINUGUAS and only install a subset. Anyway, it would definitely be good to clarify what the PM behavior should be here.
(In reply to Thomas Berger from comment #5) > (In reply to Michael Palimaka (kensington) from comment #4) > > That only lists variables that must be defined by the package manager. It > > doesn't say we can't operate on other environment variables, and indeed I > > believe many autotools packages behave in the same way that is happening > > here. > > LINGUAS is not defined in the "make.defaults" file of the most profiles. If > a package manger is written according to the specs LINGUAS must be exported > in the "embedded" profile, but there is no requirement in the specs for > others. > > Except where otherwise noted, all variables set in the active profiles’ > make.defaults files must be exported to the ebuild environment." > > The variable MAY be there. Either the spec or the ebuilds/eclasses need to > be fixed. As I said previously, I am not aware of any section of PMS that restricts us from performing some operation based on the contents of an arbitrary variable. 11.1 provides a list of what *must* be defined, not a restriction on what we can use.
(In reply to Mike Gilbert from comment #6) > (In reply to Michael Palimaka (kensington) from comment #4) > > I believe many autotools packages behave in the same way that is happening > > here. > > Packages that use the gettext autotools macros (/usr/share/aclocal/po.m4) > behave slightly differently than kde5.eclass: > > If LINGUAS is set in the environment, it acts as a filter on which > translations get installed. > > If LINUGAS is unset, all translations are installed. We can tweak kde5.eclass to behave this way.
Pushed a fix to the overlay to install all translations when LINGUAS is undefined. https://gitweb.gentoo.org/proj/kde.git/commit/?id=0510e917c31b3097087f08d4932c8347ee1efaf9
(In reply to Michael Palimaka (kensington) from comment #7) > As I said previously, I am not aware of any section of PMS that restricts us > from performing some operation based on the contents of an arbitrary > variable. 11.1 provides a list of what *must* be defined, not a restriction > on what we can use. You can use every variable you want. But you could not expect that every package manager provides this variable.
See also, my bugreport at the paludis project: http://paludis.exherbo.org/trac/ticket/1343#comment:1
(In reply to Thomas Berger from comment #11) > See also, my bugreport at the paludis project: > > http://paludis.exherbo.org/trac/ticket/1343#comment:1 exherbo...
(In reply to Johannes Huber from comment #12) > exherbo... As clarified in bug 582140 the behavior of the eclass is a QA violation and does only work because of a bug in portage.
Thanks. I have pushed the patch from Michael. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce
