Jonathan Callen | 1 Aug 01:30 2010
Picon

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)

Sergei Trofimovich | 1 Aug 22:27 2010
Picon

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
Robin H. Johnson | 2 Aug 02:25 2010
Picon

Automated Package Removal and Addition Tracker, for the week ending 2010-08-01 23h59 UTC

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-08-01 23h59 UTC.

Removals:
sci-geosciences/vis5d+             	2010-07-26 07:25:15	xarthisius
x11-misc/gaia                      	2010-07-26 08:02:45	fauli
media-libs/panda3d                 	2010-07-26 08:12:12	ssuominen
app-text/fmt-ptrn                  	2010-07-26 08:13:11	ssuominen
x11-plugins/lightning              	2010-07-26 16:49:09	anarchy
x11-plugins/wmvolman               	2010-07-29 16:14:23	ssuominen
media-video/whaawmp                	2010-07-31 03:02:27	darkside
x11-misc/xvidcap                   	2010-07-31 03:03:49	darkside
app-doc/repodoc                    	2010-07-31 03:05:58	darkside

Additions:
dev-perl/Package-DeprecationManager	2010-07-26 06:01:10	tove
www-client/mozilla-launcher        	2010-07-26 19:14:55	armin76
net-wireless/libeap                	2010-07-26 22:05:18	alexxy
app-portage/tatt                   	2010-07-27 12:36:56	fauli
media-video/bangarang              	2010-07-28 00:02:43	reavertm
media-video/tsmuxer                	2010-07-28 00:54:12	sbriesen
rox-base/rox-media                 	2010-07-28 12:25:45	lack
app-admin/lib_users                	2010-07-28 13:14:59	jer
media-video/bdsup2sub              	2010-07-28 21:59:12	sbriesen
dev-ruby/hexoid                    	2010-07-28 22:55:50	flameeyes
games-puzzle/wizznic               	2010-07-29 05:00:18	mr_bones_
net-nds/gosa-core                  	2010-07-29 09:58:28	dev-zero
net-nds/gosa-plugin-samba          	2010-07-29 10:01:12	dev-zero
dev-libs/libdebian-installer       	2010-07-29 17:15:42	darkside
dev-util/cdebootstrap              	2010-07-29 17:21:35	darkside
(Continue reading)

Matti Bickel | 2 Aug 11:56 2010
Picon

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)

Brian Harring | 2 Aug 13:11 2010
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)

David Leverton | 2 Aug 20:16 2010

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)

Mike Frysinger | 2 Aug 21:51 2010
Picon

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
Ciaran McCreesh | 2 Aug 22:15 2010

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
Picon

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)

Picon

Re: Locale check in python_pkg_setup()

A milder warning will be printed.

--

-- 
Arfrever Frehtes Taifersar Arahesis
Attachment (python.eclass.patch): text/x-patch, 903 bytes

Gmane