headers
Jonathan Callen | 1 Aug 2010 01:30
Picon
Favicon

Re: Locale check in python_pkg_setup()


On 07/31/2010 05:39 PM, James Cloos wrote:
>>>>>> "PH" == Paweł Hajdan, <phajdan.jr <at> gentoo.org> writes:
> 
> PH> Another thing we can consider is making UTF8 the default setup in
> PH> Gentoo. I think most people (including me) don't care whether it's
> PH> C or UTF8 as long as it works.
> 
> Forcing utf-8 will only be reasonable when there is a C.UTF-8 and/or
> a POSIX.UTF-8 locale.
> 
> That should be done upstream in glibc, but were they to refuse then
> Gentoo should add it to the glibc ebuild.
> 
> The language_country locales are just wrong for root.  They are often
> broken (locales like en_US force case-insensitive colation, meaning that
> a command such as 'rm [a-z]*' will unlink(2) 'Makefile' and similar files
> which one would not expect to match) and cause bugs.
> 
> In fact, glibc's insistance that C and POSIX are ascii rather than raw
> unspecified eight bit is itself a bug.
> 
> Utf8 is nice, but forcing the lang_country locales on root is not.
> 
> -JimC

You can create a POSIX.UTF-8 locale right now, using the same
/etc/locale.gen mechanism that is used for generating other locales
(localedef will output a few warnings, but the generated locale works
just fine from what I can see).  If you want a C.UTF-8 locale, then you
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergei Trofimovich | 1 Aug 2010 22:27
Picon
Favicon
Gravatar

Lastrite: dev-lang/hugs98 (The Hugs98 Haskell interpreter)

# Sergei Trofimovich <slyfox <at> gentoo.org> (1 Aug 2010)
# Masked for removal in 30 days. Bunch of serious
# bugs (bug #303665), and minor ones (bug #240036).
# Dead upstream.
dev-lang/hugs98

Left in haskell overlay to wait for brave soul.

--

-- 

  Sergei
Permalink | Reply | 0 comments |
headers
Matti Bickel | 2 Aug 2010 11:56
Picon
Favicon

RFC: Reviving GLEP33

Hi folks,

I've been told that my use of eblits in dev-lang/php is something I
should get rid of as soon as possible. Suggested alternative by ferring:
use elibs.

So here goes: I want to see GLEP33[1] implemented in portage, so I can
shift the eblits core and currently global functions into elibs and
probably push the eblits I use for php into the same structure.

Basic question: what needs to be done to get this GLEP accepted and
implemented (it's current status is moribound)?

I extracted a list of things we (or rather the portage and all other PM
teams) need to do:

(1) create elibs() function to enable importing elibs
(2) extend repoman to handle new style elibs and eclass signing/checking
(3) profit ;)

Also, there're some question I have:
(1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of
"Cases where the constant [metadata] requirement is violated are known"
- who exactly are the current offenders?

(2) What's the dev community feeling on "The end of backwards
compatibility..." section in the GLEP? Personal opinion: when the
council reached consensus that old eclasses can be removed with due
last-rites, this section became obsolete. Just putting new-style
eclasses in their own dirs in eclass/ might again be an option. Please
(Continue reading)

Permalink | Reply | 27 comments |
headers
Brian Harring | 2 Aug 2010 13:11
Picon

Re: RFC: Reviving GLEP33

On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
> Hi folks,
> 
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by ferring:
> use elibs.
> 
> So here goes: I want to see GLEP33[1] implemented in portage, so I can
> shift the eblits core and currently global functions into elibs and
> probably push the eblits I use for php into the same structure.
> 
> Basic question: what needs to be done to get this GLEP accepted and
> implemented (it's current status is moribound)?
> 
> I extracted a list of things we (or rather the portage and all other PM
> teams) need to do:
> 
> (1) create elibs() function to enable importing elibs

There's a caveat here; imagine one of the current PM's processing an 
EAPI=4 (or whatever) ebuild that uses elib- specifically there will be 
a global scope function invocation of a function that doesn't exist.

In the past, a minority of folk have raised complaints about this- it 
was never stated as best I know, but my assumption looking back is 
that it was due primarily to paludis getting pissy about ebuilds 
outputing anything during metadata sourcing (paludis at this point 
isn't pissy about it- mainly sinc eclasses can invoke die after all).

Managers should implementat that functionality; orthogonal to it,
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Leverton | 2 Aug 2010 20:16

Re: RFC: Reviving GLEP33

On 2 August 2010 12:11, Brian Harring <ferringb <at> gmail.com> wrote:
> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>> Hi folks,
>>
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible. Suggested alternative by ferring:
>> use elibs.

There's a couple of hundred lines of repeated metadata between
php-5.3.2 and php-5.3.3 - not identical, but similar enough that there
would be gains from factoring it out, and elibs won't help with that.
Am I understanding correctly in that you didn't use an eclass to avoid
cluttering up the main eclass directory with something specific to
this one package?  If so, it sounds like what you really want is
per-package eclasses (maybe with elibs as well to hold the
non-metadata code), which aren't covered by GLEP33 but ought to be
easy enough to add.

> There's a caveat here; imagine one of the current PM's processing an
> EAPI=4 (or whatever) ebuild that uses elib- specifically there will be
> a global scope function invocation of a function that doesn't exist.
>
> In the past, a minority of folk have raised complaints about this- it
> was never stated as best I know, but my assumption looking back is
> that it was due primarily to paludis getting pissy about ebuilds
> outputing anything during metadata sourcing

I can't speak for other people who may have complained, but it seems
to me that for ebuilds to be calling non-existent commands is fairly
obviously wrong, even if the consequences happen to be benign - not
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mike Frysinger | 2 Aug 2010 21:51
Picon
Favicon
Gravatar

Re: RFC: Reviving GLEP33

On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible.

current eblits support isnt going anywhere.  so dont waste time trying to 
change code if there is no real alternative.  see Bug 327999.
-mike
Permalink | Reply | 3 comments |
headers
Ciaran McCreesh | 2 Aug 2010 22:15
Gravatar

Re: RFC: Reviving GLEP33

On Mon, 02 Aug 2010 11:56:08 +0200
Matti Bickel <mabi <at> gentoo.org> wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by
> ferring: use elibs.
> 
> So here goes: I want to see GLEP33[1] implemented in portage, so I can
> shift the eblits core and currently global functions into elibs and
> probably push the eblits I use for php into the same structure.

Aren't you really after per-package eclasses, not elibs? Now that
eclasses for installed packages are handled sanely, elibs are just a way
to reduce the metadata generation impact of changing a widely used
eclass, and processors are getting faster faster than the tree is
growing.

> Instead of all the backwards-compatibility issues the GLEP deals with,
> we could just sneak the implementation into EAPI4 and be done with it.

No, you can't make global scope changes just in an EAPI without
screwing up user systems. You have to do the whole "wait several years"
thing for them. If you don't want to screw things up for users, the
only way of avoiding a huge wait for all of this would be to adopt GLEP
55, and of course GLEP 55 won't ever be adopted without years of noise
anyway, so this whole discussion is purely academic.

--

-- 
Ciaran McCreesh
Permalink | Reply | 17 comments |
headers
Arfrever Frehtes Taifersar Arahesis | 2 Aug 2010 23:02
Picon
Favicon

Re: Locale check in python_pkg_setup()

2010-07-31 22:25:26 Petteri Räty napisał(a):
> On 07/31/2010 11:10 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> >>
> >> If the variable is set but not exported then it is local to the shell
> >> env.  When bash goes to exec() python the local shell variables are
> >> not in the env; so os.environ() will not contain them.
> >>
> >> antarus <at> kyoto ~ $ foo=BAR
> >> antarus <at> kyoto ~ $ echo $foo
> >> BAR
> >> antarus <at> kyoto ~ $ python -c 'import os; print os.environ.get("foo")'
> >> None
> >> antarus <at> kyoto ~ $ export foo
> >> antarus <at> kyoto ~ $ python -c 'import os; print os.environ.get("foo")'
> >> BAR
> > 
> > I want only variables exported to Python processes.
> > 
> 
> export -p

It would have to be parsed using e.g. grep and sed. It's easier to call Python in this case.
The call to Python is sufficiently fast:

$ time python -c 'import os; print(os.environ.get("LC_ALL", os.environ.get("LC_CTYPE",
os.environ.get("LANG", "POSIX"))))' > /dev/null

real    0m0.062s
user    0m0.051s
sys     0m0.011s
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arfrever Frehtes Taifersar Arahesis | 2 Aug 2010 23:18
Picon
Favicon

Re: Locale check in python_pkg_setup()

A milder warning will be printed.

--

-- 
Arfrever Frehtes Taifersar Arahesis
Attachment (python.eclass.patch): text/x-patch, 877 bytes
Permalink | Reply | 4 comments |
headers
Harald van Dijk | 2 Aug 2010 23:40
Picon
Favicon

Re: Locale check in python_pkg_setup()

On Mon, Aug 02, 2010 at 11:02:20PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> It would have to be parsed using e.g. grep and sed. It's easier to call Python in this case.

It's even easier not to.

> The call to Python is sufficiently fast:
> 
> $ time python -c 'import os; print(os.environ.get("LC_ALL", os.environ.get("LC_CTYPE",
os.environ.get("LANG", "POSIX"))))' > /dev/null
> 
> real    0m0.062s
> user    0m0.051s
> sys     0m0.011s

Let's compare. On my system:

time python -c 'import os; print(os.environ.get("LC_ALL", os.environ.get("LC_CTYPE",
os.environ.get("LANG", "POSIX"))))'
en_GB.UTF-8

real	0m0.020s
user	0m0.016s
sys	0m0.004s

time sh -c 'echo "${LC_ALL:-${LC_CTYPE:-${LANG:-POSIX}}}"'
en_GB.UTF-8

real	0m0.001s
user	0m0.000s
sys	0m0.000s
(Continue reading)

Permalink | Reply | 0 comments |

Gmane