core-updates merged!

core-updates merged!

[Federico Beffa]

ludo@gnu.org (Ludovic Courtès) writes:

>   • The ‘glibc’ package no longer has a “locale” output, making it
>     faster to build, and much smaller (the “locale” output was always
>     pulled, and it took 110 MiB.)

I notice that this breaks some packages like guile-ncurses and the
(all?) packages using python-sphinx to generate documentation like
matplotlib, numpy, scipy.

Guile-ncurses was fixed by adding a new phase to generate the
"en_US.UTF-8" locale during the generation of the package, but wouldn't
it be better to keep the "en_US.UTF-8" locale? That appears to be the
default used by most packages.

Regards,
Fede

Lack of locales in build environment

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> Guile-ncurses was fixed by adding a new phase to generate the
> "en_US.UTF-8" locale during the generation of the package, but wouldn't
> it be better to keep the "en_US.UTF-8" locale? That appears to be the
> default used by most packages.

That’s an open question.  The vast majority of packages is happy with
just the C locale, and some need something more.

So far the approach has been to fix these one by one (that’s 4 packages
so far) but if it happens to be frequent enough or cumbersome, we can
change that in the next core-updates to have en_US.UTF-8 available by
default.

WDYT?

Thanks,
Ludo’.

Re: Lack of locales in build environment

[Federico Beffa]

On Tue, Feb 10, 2015 at 6:13 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> Guile-ncurses was fixed by adding a new phase to generate the
>> "en_US.UTF-8" locale during the generation of the package, but wouldn't
>> it be better to keep the "en_US.UTF-8" locale? That appears to be the
>> default used by most packages.
>
> That’s an open question.  The vast majority of packages is happy with
> just the C locale, and some need something more.
>
> So far the approach has been to fix these one by one (that’s 4 packages
> so far) but if it happens to be frequent enough or cumbersome, we can
> change that in the next core-updates to have en_US.UTF-8 available by
> default.

The "scipy ecosystem" documentation makes use of sphinx to build the
documentation and requires an UTF-8 locale. I do not know if this is
specific to scipy and friends of if it is a characteristic of sphinx
(that's why I speculated that there may be more python packages in
need for that).

From my point of view it would be good to include en_US.UTF-8 by
default for two reasons: (i) we already are at 7 (4+3) packages
requiring an UTF-8 locale and, I guess, that this number is doomed to
increase in the following years. (ii) This is another small step in
making maintenance easier by providing an environment setting that
sometimes helps.

Regards,
Fede

Re: Lack of locales in build environment

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On Tue, Feb 10, 2015 at 06:36:58PM +0100, Federico Beffa wrote:
     On Tue, Feb 10, 2015 at 6:13 PM, Ludovic Courtès <ludo@gnu.org> wrote:
     > Federico Beffa <beffa@ieee.org> skribis:
     >
     >> Guile-ncurses was fixed by adding a new phase to generate the
     >> "en_US.UTF-8" locale during the generation of the package, but wouldn't
     >> it be better to keep the "en_US.UTF-8" locale? That appears to be the
     >> default used by most packages.
     >
     > That’s an open question.  The vast majority of packages is happy with
     > just the C locale, and some need something more.
     >
     > So far the approach has been to fix these one by one (that’s 4 packages
     > so far) but if it happens to be frequent enough or cumbersome, we can
     > change that in the next core-updates to have en_US.UTF-8 available by
     > default.
     
     
	(i) we already are at 7 (4+3) packages requiring an UTF-8 locale 

Then that is a bug which should be filed against those pacakges.

     (ii) This is another small step in
     making maintenance easier by providing an environment setting that
     sometimes helps.

It sounds like a slippery slope.  If we shovel in everything into the defaults, 
that might possibly help somebody do something, someday we'll end up with a very
bloated system.

The C locale is the canonical locale. UTF-8 is not the only characater encoding in
the world.  English is not the only language in the world, and US English is not
the only dialect of English.

J'
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Lack of locales in build environment

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> The C locale is the canonical locale. UTF-8 is not the only characater encoding in
> the world.  English is not the only language in the world, and US English is not
> the only dialect of English.

You’re right, of course.  For the packages discussed, what matters above
all is to provide their build environment with a UTF-8 locale, and en_US
seems like the least disruptive one from a technical viewpoint.  But of
course, that does not have any impact on what locales people may want to
use in their own environment.

Ludo’.

Re: Lack of locales in build environment

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> From my point of view it would be good to include en_US.UTF-8 by
> default for two reasons: (i) we already are at 7 (4+3) packages
> requiring an UTF-8 locale and, I guess, that this number is doomed to
> increase in the following years. (ii) This is another small step in
> making maintenance easier by providing an environment setting that
> sometimes helps.

Right.

How about this: we make a package with a bunch of locales, and in
core-updates we add a specification for $LOCPATH to glibc.

For those packages, we would just add that locales package to their
inputs and be done with it.

WDYT?

Ludo’.

Re: core-updates merged!

[Andreas Enge]

On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote:
> Guile-ncurses was fixed by adding a new phase to generate the
> "en_US.UTF-8" locale during the generation of the package

This is interesting information! If I understand things correctly, I think
a solution would be to have tons of locale-XX packages, where XX stands for
the country code, the contents of which are created by calls to localedef.
And maybe a package locales-all for people who have space and do not wish
to choose. And a search path definition in glibc to set LOCPATH.

What do you think?

Andreas

Re: core-updates merged!

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Tue, Feb 10, 2015 at 07:46:48PM +0100, Andreas Enge wrote:
     On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote:
     > Guile-ncurses was fixed by adding a new phase to generate the
     > "en_US.UTF-8" locale during the generation of the package
     
     This is interesting information! If I understand things correctly, I think
     a solution would be to have tons of locale-XX packages, where XX stands for
     the country code, the contents of which are created by calls to localedef.
     And maybe a package locales-all for people who have space and do not wish
     to choose. And a search path definition in glibc to set LOCPATH.
     
     What do you think?
     
To me, it sounds like a good idea.    I have never liked the debian way where the
locales are compiled at install time.

J'


     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: core-updates merged!

[Federico Beffa]

On Tue, Feb 10, 2015 at 7:46 PM, Andreas Enge <andreas@enge.fr> wrote:
> On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote:
>> Guile-ncurses was fixed by adding a new phase to generate the
>> "en_US.UTF-8" locale during the generation of the package
>
> This is interesting information! If I understand things correctly, I think
> a solution would be to have tons of locale-XX packages, where XX stands for
> the country code, the contents of which are created by calls to localedef.
> And maybe a package locales-all for people who have space and do not wish
> to choose. And a search path definition in glibc to set LOCPATH.
>
> What do you think?

I like this idea as well.

Regards,
Fede

Re: Lack of locales in build environment

[Federico Beffa]

John Darrington <john@darrington.wattle.id.au> writes:
>     (i) we already are at 7 (4+3) packages requiring an UTF-8 locale
>
> Then that is a bug which should be filed against those pacakges.

I just discovered the problem with the "scipy ecosystem" packages
today and intended to fix them. But, before submitting changes, I wanted
to check with the ML.

If we decide to keep the status quo, then I will fix the
packages. Otherwise, if we introduce a default UTF-8 locale or implement
Andreas's suggestion, I will file a bug to avoid forgetting.

>
>      (ii) This is another small step in
>      making maintenance easier by providing an environment setting that
>      sometimes helps.
>
> It sounds like a slippery slope.  If we shovel in everything into the defaults,
> that might possibly help somebody do something, someday we'll end up with a very
> bloated system.

The C locale is really an ancient relict. I think adding a more
modern default locale to the build environment doesn't really bloat the
system.

>
> The C locale is the canonical locale. UTF-8 is not the only characater encoding in
> the world.  English is not the only language in the world, and US English is not
> the only dialect of English.

I'm not a native english speaker and I understand the problem very
well. In spite of this I do not know of any package providing
documentation in other languages than english. That's the reason for
suggesting a default locale of en_US.UTF-8 for the build systems.


Regards,
Fede