unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* core-updates merged!
@ 2015-02-10 16:38 Federico Beffa
  2015-02-10 17:13 ` Lack of locales in build environment Ludovic Courtès
  2015-02-10 18:46 ` core-updates merged! Andreas Enge
  0 siblings, 2 replies; 10+ messages in thread
From: Federico Beffa @ 2015-02-10 16:38 UTC (permalink / raw)
  To: ludo; +Cc: Guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Lack of locales in build environment
  2015-02-10 16:38 core-updates merged! Federico Beffa
@ 2015-02-10 17:13 ` Ludovic Courtès
  2015-02-10 17:36   ` Federico Beffa
  2015-02-10 18:46 ` core-updates merged! Andreas Enge
  1 sibling, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2015-02-10 17:13 UTC (permalink / raw)
  To: Federico Beffa; +Cc: Guix-devel

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’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Lack of locales in build environment
  2015-02-10 17:13 ` Lack of locales in build environment Ludovic Courtès
@ 2015-02-10 17:36   ` Federico Beffa
  2015-02-10 18:02     ` John Darrington
  2015-02-10 21:15     ` Ludovic Courtès
  0 siblings, 2 replies; 10+ messages in thread
From: Federico Beffa @ 2015-02-10 17:36 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Lack of locales in build environment
  2015-02-10 17:36   ` Federico Beffa
@ 2015-02-10 18:02     ` John Darrington
  2015-02-10 21:13       ` Ludovic Courtès
  2015-02-10 21:15     ` Ludovic Courtès
  1 sibling, 1 reply; 10+ messages in thread
From: John Darrington @ 2015-02-10 18:02 UTC (permalink / raw)
  To: Federico Beffa; +Cc: Guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: core-updates merged!
  2015-02-10 16:38 core-updates merged! Federico Beffa
  2015-02-10 17:13 ` Lack of locales in build environment Ludovic Courtès
@ 2015-02-10 18:46 ` Andreas Enge
  2015-02-10 18:50   ` John Darrington
  2015-02-10 19:38   ` Federico Beffa
  1 sibling, 2 replies; 10+ messages in thread
From: Andreas Enge @ 2015-02-10 18:46 UTC (permalink / raw)
  To: Federico Beffa; +Cc: Guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: core-updates merged!
  2015-02-10 18:46 ` core-updates merged! Andreas Enge
@ 2015-02-10 18:50   ` John Darrington
  2015-02-10 19:38   ` Federico Beffa
  1 sibling, 0 replies; 10+ messages in thread
From: John Darrington @ 2015-02-10 18:50 UTC (permalink / raw)
  To: Andreas Enge; +Cc: Guix-devel, Federico Beffa

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: core-updates merged!
  2015-02-10 18:46 ` core-updates merged! Andreas Enge
  2015-02-10 18:50   ` John Darrington
@ 2015-02-10 19:38   ` Federico Beffa
  1 sibling, 0 replies; 10+ messages in thread
From: Federico Beffa @ 2015-02-10 19:38 UTC (permalink / raw)
  To: Andreas Enge; +Cc: Guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Lack of locales in build environment
@ 2015-02-10 19:54 Federico Beffa
  0 siblings, 0 replies; 10+ messages in thread
From: Federico Beffa @ 2015-02-10 19:54 UTC (permalink / raw)
  To: Guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Lack of locales in build environment
  2015-02-10 18:02     ` John Darrington
@ 2015-02-10 21:13       ` Ludovic Courtès
  0 siblings, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2015-02-10 21:13 UTC (permalink / raw)
  To: John Darrington; +Cc: Guix-devel, Federico Beffa

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’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Lack of locales in build environment
  2015-02-10 17:36   ` Federico Beffa
  2015-02-10 18:02     ` John Darrington
@ 2015-02-10 21:15     ` Ludovic Courtès
  1 sibling, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2015-02-10 21:15 UTC (permalink / raw)
  To: Federico Beffa; +Cc: Guix-devel

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’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-02-10 21:15 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-10 16:38 core-updates merged! Federico Beffa
2015-02-10 17:13 ` Lack of locales in build environment Ludovic Courtès
2015-02-10 17:36   ` Federico Beffa
2015-02-10 18:02     ` John Darrington
2015-02-10 21:13       ` Ludovic Courtès
2015-02-10 21:15     ` Ludovic Courtès
2015-02-10 18:46 ` core-updates merged! Andreas Enge
2015-02-10 18:50   ` John Darrington
2015-02-10 19:38   ` Federico Beffa
  -- strict thread matches above, loose matches on Subject: below --
2015-02-10 19:54 Lack of locales in build environment Federico Beffa

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).