[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Duncan]

Daniel Campbell posted on Tue, 31 May 2016 10:31:22 -0700 as excerpted:

> I think this idea has some potential, but would there be a way for a
> user to choose L10N *or* INSTALL_MASK instead of both? If I understand
> correctly, a person who wanted all of their system to be en_US only, but
> wanted to take part in translation of some other project, would need to
> add the other locales directly to L10N, then somehow mask them out for
> other packages. Or the reverse: leave L10N="en_US" or something, and
> somehow enable other languages in that specific package.
> 
> Is there a package-level option for this? Users can set their locales in
> /etc/locale.gen, and that handles things globally, but what about the
> user that doesn't want to include that for all of their packages? This
> seems like an all-or-nothing thing, lacking in granularity. If I'm
> wrong, please clarify so I can understand better.

For portage at least, pretty much all vars, including the proposed L10N, 
can be set per-package using /etc/portage/package.env and the files it 
points to in /etc/portage/env/.  

(The package.env method works during the python phase as well, but is 
primarily for direct variable setting and isn't as flexible as the older 
/etc/portage/env/cat-egory/pkg/file method, which only works during the 
bash/ebuild phase, but exposes the full richness of bash to be used as 
it's actually bash executing it.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Duncan]

Andrew Savchenko posted on Tue, 31 May 2016 20:08:10 +0300 as excerpted:

> If we are going to do an instant move from LINGUAS to L10N (no graced
> period as discussed here on another thread), why to rename variable in
> the first place?

Because the LINGUAS var is hopelessly tangled up in various build 
systems... in different ways for different build systems so it's nigh 
impossible to automatically untangle it.

By switching to a var (L10N being the proposed name) that's not actually 
used in strange ways by the build systems, gentoo's settings won't have 
unexpected implicit results due to getting tangled up with the build 
system, only the explicit results managed by the gentoo-level code in the 
ebuilds/eclasses.

That of course being the whole problem LINGUAS turned into such a mess in 
the first place.  In hindsight the mess could have been predicted, but as 
they say, hindsight is 20/20...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Francesco Riosa]

2016-06-01 0:03 GMT+02:00 Mike Gilbert :

> On Tue, May 31, 2016 at 5:34 PM, Jörg Schaible 
> wrote:
> > How can I select different linguas for individual packages with this
> > approach?
>
> Why would you want to?
>
> In addition to  Jörg Schaible answer:
I do use my kde sessions with en_US language, my daughter prefer to use
it_IT, same PC.

[gentoo-dev] Re: Re: [RFC] Masterplan for solving LINGUAS problems

[Jörg Schaible]

Mike Gilbert wrote:

> On Tue, May 31, 2016 at 5:34 PM, Jörg Schaible 
> wrote:
>> How can I select different linguas for individual packages with this
>> approach?
> 
> Why would you want to?

As programmer I am used to read English manuals and for most command line 
tools it is the only up-to-date documentation. Development tools or system 
configuration with translated manuals is simply awful for me. Therefore I've 
set LINGUAS to "en" in make.conf and run my shells with "LANG=en_US.UTF-8".

Situation changes for GUI stuff like office applications where I feel more 
comfortable as "normal" user. KDE is configured for German language and for 
a lot of those apps I've explicitly set linguas_de in package.use. For 
libreoffice and calligra I've even added linguas_fr to get French spelling 
support.

For me it is currently very convenient to look simply at the use flags of a 
package to see which languages will be supported. Gnucash is the only 
application I had to set environment variables for (using package.env) to 
get German language support (and it took me a while to find this and get it 
right). I may have missed other packages that do not use IUSE_EXPAND, simply 
because I am not aware of the support.

Cheers,
Jörg

Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Mike Gilbert]

On Tue, May 31, 2016 at 5:34 PM, Jörg Schaible  wrote:
> How can I select different linguas for individual packages with this
> approach?

Why would you want to?

[gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Jörg Schaible]

How can I select different linguas for individual packages with this 
approach?

Michał Górny wrote:

> Hello, everyone.
> 
> Since the previous thread doesn't seem to have brought any good
> solution to the problem other than stopping to (ab)use LINGUAS
> as USE_EXPAND, I would like to start a RFC on a draft solution that
> I'd like afterwards to propose to the Council.
> 
> 
> Rationale
> -
> 
> The direct reason for this is that LINGUAS is treated as non-standard
> special variable by multiple build systems. This includes the following
> problems:
> 
> 1. no localizations are installed if it is set to an empty value (which
> happens in EAPI 5 when the ebuild does not use the flags),
> 
> 2. there were historical cases where order of LINGUAS mattered.
> 
> Those problems can't be reasonably solved within the scope of
> USE_EXPAND. Furthermore, the use of flags to control localizations is
> causing the following problems:
> 
> a. maintaining correct flag list is a serious maintenance burden,
> especially that differences in build systems make it hard to figure out
> the 'most correct' set automatically,
> 
> b. missing flags result in localizations being silently dropped, with
> no clear way (i.e. for QA check) to detect that,
> 
> c. large number of additional USE flags make it pretty much impossible
> to limit localizations this way when using binary packages.
> 
> 
> The plan
> 
> 
> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
> in Portage.
> 
> 2. Introduce a new USE_EXPAND that can be used to control localizations
> whenever this is really required (dependencies, large files, etc.).
> Let's use L10N as a draft name for it.
> 
> 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting
> to L10N or by removing the needless flags.
> 
> 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI
> rules from the variable.
> 
> 5. Release a news item explaining the users the change,
> and the necessary action. Request changing LINGUAS to L10N
> in make.conf, and make LINGUAS considered an 'advanced variable' for
> implicit localization control (i.e. passed through to build systems).
> Recommend clean INSTALL_MASK solution instead.
> 
> The example 'new' make.conf would probably look like:
> 
>   # controlling e.g. langpacks
>   L10N="en_US pl"
>   # stripping unneeded files
>   INSTALL_MASK="@linguas -@linguas_pl"
> 
> 
> Your thoughts?
> 
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
> 

Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[James Le Cuirot]

On Tue, 31 May 2016 23:34:07 +0200
Jörg Schaible  wrote:

> How can I select different linguas for individual packages with this 
> approach?

You could probably set INSTALL_MASK and L10N
via /etc/portage/package.env.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpIJXJOrenuN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Daniel Campbell]

On 05/31/2016 10:31 AM, Daniel Campbell wrote:
> On 05/31/2016 05:49 AM, Michał Górny wrote:
>> Hello, everyone.
>>
>> Since the previous thread doesn't seem to have brought any good
>> solution to the problem other than stopping to (ab)use LINGUAS
>> as USE_EXPAND, I would like to start a RFC on a draft solution that
>> I'd like afterwards to propose to the Council.
>>
>>
>> Rationale
>> -
>>
>> The direct reason for this is that LINGUAS is treated as non-standard
>> special variable by multiple build systems. This includes the following
>> problems:
>>
>> 1. no localizations are installed if it is set to an empty value (which
>> happens in EAPI 5 when the ebuild does not use the flags),
>>
>> 2. there were historical cases where order of LINGUAS mattered.
>>
>> Those problems can't be reasonably solved within the scope of
>> USE_EXPAND. Furthermore, the use of flags to control localizations is
>> causing the following problems:
>>
>> a. maintaining correct flag list is a serious maintenance burden,
>> especially that differences in build systems make it hard to figure out
>> the 'most correct' set automatically,
>>
>> b. missing flags result in localizations being silently dropped, with
>> no clear way (i.e. for QA check) to detect that,
>>
>> c. large number of additional USE flags make it pretty much impossible
>> to limit localizations this way when using binary packages.
>>
>>
>> The plan
>> 
>>
>> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
>> in Portage.
>>
>> 2. Introduce a new USE_EXPAND that can be used to control localizations
>> whenever this is really required (dependencies, large files, etc.).
>> Let's use L10N as a draft name for it.
>>
>> 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting
>> to L10N or by removing the needless flags.
>>
>> 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI
>> rules from the variable.
>>
>> 5. Release a news item explaining the users the change,
>> and the necessary action. Request changing LINGUAS to L10N
>> in make.conf, and make LINGUAS considered an 'advanced variable' for
>> implicit localization control (i.e. passed through to build systems).
>> Recommend clean INSTALL_MASK solution instead.
>>
>> The example 'new' make.conf would probably look like:
>>
>>   # controlling e.g. langpacks
>>   L10N="en_US pl"
>>   # stripping unneeded files
>>   INSTALL_MASK="@linguas -@linguas_pl"
>>
>>
>> Your thoughts?
>>
>>
>> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
>>
> 
> I think this idea has some potential, but would there be a way for a
> user to choose L10N *or* INSTALL_MASK instead of both? If I understand
> correctly, a person who wanted all of their system to be en_US only, but
> wanted to take part in translation of some other project, would need to
> add the other locales directly to L10N, then somehow mask them out for
> other packages. Or the reverse: leave L10N="en_US" or something, and
> somehow enable other languages in that specific package.
> 
> Is there a package-level option for this? Users can set their locales in
> /etc/locale.gen, and that handles things globally, but what about the
> user that doesn't want to include that for all of their packages? This
> seems like an all-or-nothing thing, lacking in granularity. If I'm
> wrong, please clarify so I can understand better.
> 

I forgot to include that I think the INSTALL_MASK groups, even if not
implemented for this issue, are a great idea. It would allow users to
target specific things like "get rid of info pages", "no systemd unit
files", etc, in a way that is controlled by the repo (or an override in
/etc/portage somewhere). It prevents more ebuild bloat, too.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Daniel Campbell]

On 05/31/2016 05:49 AM, Michał Górny wrote:
> Hello, everyone.
> 
> Since the previous thread doesn't seem to have brought any good
> solution to the problem other than stopping to (ab)use LINGUAS
> as USE_EXPAND, I would like to start a RFC on a draft solution that
> I'd like afterwards to propose to the Council.
> 
> 
> Rationale
> -
> 
> The direct reason for this is that LINGUAS is treated as non-standard
> special variable by multiple build systems. This includes the following
> problems:
> 
> 1. no localizations are installed if it is set to an empty value (which
> happens in EAPI 5 when the ebuild does not use the flags),
> 
> 2. there were historical cases where order of LINGUAS mattered.
> 
> Those problems can't be reasonably solved within the scope of
> USE_EXPAND. Furthermore, the use of flags to control localizations is
> causing the following problems:
> 
> a. maintaining correct flag list is a serious maintenance burden,
> especially that differences in build systems make it hard to figure out
> the 'most correct' set automatically,
> 
> b. missing flags result in localizations being silently dropped, with
> no clear way (i.e. for QA check) to detect that,
> 
> c. large number of additional USE flags make it pretty much impossible
> to limit localizations this way when using binary packages.
> 
> 
> The plan
> 
> 
> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
> in Portage.
> 
> 2. Introduce a new USE_EXPAND that can be used to control localizations
> whenever this is really required (dependencies, large files, etc.).
> Let's use L10N as a draft name for it.
> 
> 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting
> to L10N or by removing the needless flags.
> 
> 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI
> rules from the variable.
> 
> 5. Release a news item explaining the users the change,
> and the necessary action. Request changing LINGUAS to L10N
> in make.conf, and make LINGUAS considered an 'advanced variable' for
> implicit localization control (i.e. passed through to build systems).
> Recommend clean INSTALL_MASK solution instead.
> 
> The example 'new' make.conf would probably look like:
> 
>   # controlling e.g. langpacks
>   L10N="en_US pl"
>   # stripping unneeded files
>   INSTALL_MASK="@linguas -@linguas_pl"
> 
> 
> Your thoughts?
> 
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
> 

I think this idea has some potential, but would there be a way for a
user to choose L10N *or* INSTALL_MASK instead of both? If I understand
correctly, a person who wanted all of their system to be en_US only, but
wanted to take part in translation of some other project, would need to
add the other locales directly to L10N, then somehow mask them out for
other packages. Or the reverse: leave L10N="en_US" or something, and
somehow enable other languages in that specific package.

Is there a package-level option for this? Users can set their locales in
/etc/locale.gen, and that handles things globally, but what about the
user that doesn't want to include that for all of their packages? This
seems like an all-or-nothing thing, lacking in granularity. If I'm
wrong, please clarify so I can understand better.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Andrew Savchenko]

Hi,

On Tue, 31 May 2016 14:49:26 +0200 Michał Górny wrote:
> Hello, everyone.
> 
> Since the previous thread doesn't seem to have brought any good
> solution to the problem other than stopping to (ab)use LINGUAS
> as USE_EXPAND, I would like to start a RFC on a draft solution that
> I'd like afterwards to propose to the Council.
> 
> 
> Rationale
> -
> 
> The direct reason for this is that LINGUAS is treated as non-standard
> special variable by multiple build systems. This includes the following
> problems:
> 
> 1. no localizations are installed if it is set to an empty value (which
> happens in EAPI 5 when the ebuild does not use the flags),
> 
> 2. there were historical cases where order of LINGUAS mattered.
> 
> Those problems can't be reasonably solved within the scope of
> USE_EXPAND. Furthermore, the use of flags to control localizations is
> causing the following problems:
> 
> a. maintaining correct flag list is a serious maintenance burden,
> especially that differences in build systems make it hard to figure out
> the 'most correct' set automatically,
> 
> b. missing flags result in localizations being silently dropped, with
> no clear way (i.e. for QA check) to detect that,
> 
> c. large number of additional USE flags make it pretty much impossible
> to limit localizations this way when using binary packages.
> 
> 
> The plan
> 
> 
> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
> in Portage.
> 
> 2. Introduce a new USE_EXPAND that can be used to control localizations
> whenever this is really required (dependencies, large files, etc.).
> Let's use L10N as a draft name for it.
> 
> 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting
> to L10N or by removing the needless flags.
> 
> 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI
> rules from the variable.
> 
> 5. Release a news item explaining the users the change,
> and the necessary action. Request changing LINGUAS to L10N
> in make.conf, and make LINGUAS considered an 'advanced variable' for
> implicit localization control (i.e. passed through to build systems).
> Recommend clean INSTALL_MASK solution instead.
> 
> The example 'new' make.conf would probably look like:
> 
>   # controlling e.g. langpacks
>   L10N="en_US pl"
>   # stripping unneeded files
>   INSTALL_MASK="@linguas -@linguas_pl"

Users will have extra burden because of this change. We should make
user experience simpler, not more and more difficult. With proposed
change users will need to manage two lists for the same
functionality: L10N and INSTALL_MASK.

The latter one is being used for many purposes and people may be
confused by requirement to put @linguas-like directives there. It's
like we'll force to put all USE_EXPAND flags explicitly in the USE
variable.

What about different locales for the same language? E.g. there is
ru, ru_RU and ru_RU_0 for Russian (I have no clue what ru_RU_0 is
supposed to mean). What are planes for this varians? Will
@lingual_ru contain all of them or only some?

What about man pages? They are also controlled by LINGUAS (at
least for some packages), but will be out of control with proposed
changes.

If we are going to do an instant move from LINGUAS to L10N (no
graced period as discussed here on another thread), why to rename
variable in the first place?

It will be a nice move towards our users if INSTALL_MASK will be
automatically populated based on L10N list with ability to override
it if really needed, e.g. user needs L10N for en only (e.g. large
docs), but wants some other languages for localization files.

Best regards,
Andrew Savchenko


pgpHhtynQ4sQp.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] git-r3.eclass: Support checking out repo by date, #510704

[Michał Górny]

On Thu, 26 May 2016 14:08:26 +0200
Michał Górny  wrote:

> ---
>  eclass/git-r3.eclass | 69 
> +++-
>  1 file changed, 58 insertions(+), 11 deletions(-)

Merged.

-- 
Best regards,
Michał Górny



pgpJMZTT4Ohfo.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Michał Górny]

On Tue, 31 May 2016 14:53:36 +0200
Chí-Thanh Christopher Nguyễn  wrote:

> Michał Górny schrieb:
> > Request changing LINGUAS to L10N
> > in make.conf, and make LINGUAS considered an 'advanced variable' for
> > implicit localization control (i.e. passed through to build systems).
> > Recommend clean INSTALL_MASK solution instead.  
> 
> Can we have this change happen (semi-)automatically, via config_protect?

I don't know. We'd have to bind it to some package then.

Maybe we should bind it to sys-apps/portage, along with the USE_EXPAND
behavior fix. Then users wouldn't directly be affected by LINGUAS
removing localizations from all packages.

> Also, will there be a transition period where users need to have both 
> variables set?

I'd rather avoid that, since that prolongs the problem with LINGUAS
misbehavior.

-- 
Best regards,
Michał Górny



pgpfQOH5DW2ND.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

Request changing LINGUAS to L10N
in make.conf, and make LINGUAS considered an 'advanced variable' for
implicit localization control (i.e. passed through to build systems).
Recommend clean INSTALL_MASK solution instead.


Can we have this change happen (semi-)automatically, via config_protect?
Also, will there be a transition period where users need to have both 
variables set?



Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Michał Górny]

Hello, everyone.

Since the previous thread doesn't seem to have brought any good
solution to the problem other than stopping to (ab)use LINGUAS
as USE_EXPAND, I would like to start a RFC on a draft solution that
I'd like afterwards to propose to the Council.


Rationale
-

The direct reason for this is that LINGUAS is treated as non-standard
special variable by multiple build systems. This includes the following
problems:

1. no localizations are installed if it is set to an empty value (which
happens in EAPI 5 when the ebuild does not use the flags),

2. there were historical cases where order of LINGUAS mattered.

Those problems can't be reasonably solved within the scope of
USE_EXPAND. Furthermore, the use of flags to control localizations is
causing the following problems:

a. maintaining correct flag list is a serious maintenance burden,
especially that differences in build systems make it hard to figure out
the 'most correct' set automatically,

b. missing flags result in localizations being silently dropped, with
no clear way (i.e. for QA check) to detect that,

c. large number of additional USE flags make it pretty much impossible
to limit localizations this way when using binary packages.


The plan


1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
in Portage.

2. Introduce a new USE_EXPAND that can be used to control localizations
whenever this is really required (dependencies, large files, etc.).
Let's use L10N as a draft name for it.

3. Fix all packages using LINGUAS as USE_EXPAND, either by converting
to L10N or by removing the needless flags.

4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI
rules from the variable.

5. Release a news item explaining the users the change,
and the necessary action. Request changing LINGUAS to L10N
in make.conf, and make LINGUAS considered an 'advanced variable' for
implicit localization control (i.e. passed through to build systems).
Recommend clean INSTALL_MASK solution instead.

The example 'new' make.conf would probably look like:

  # controlling e.g. langpacks
  L10N="en_US pl"
  # stripping unneeded files
  INSTALL_MASK="@linguas -@linguas_pl"


Your thoughts?


[1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK

-- 
Best regards,
Michał Górny



pgpWccQMAZm2J.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: kde-apps/superkaramba

[Johannes Huber]

# Johannes Huber  (31 May 2016)
# Masked for removal in 30 days. Declared as dead by
# upstream in 2015. Last release with KDE Applications 15.08.3.
# Exported to user maintained overlay kde-sunset.
kde-apps/superkaramba

signature.asc
Description: This is a digitally signed message part.