Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-python
Navigation:
Lists: gentoo-python: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: djc@g.o
From: Mike Gilbert <floppym@g.o>
Subject: Re: Testing dev-lang/python version bumps
Date: Fri, 27 Apr 2012 11:13:47 -0400
On 04/27/2012 09:03 AM, Dirkjan Ochtman wrote:
> Thanks for doing this! Sorry it took so long to review them... we
> should try to think of some easier review mechanism than putting up a
> tarball you have to unpack.
> 
> On Sun, Apr 22, 2012 at 03:12, Mike Gilbert <floppym@g.o> wrote:
>> If we can get some people testing these that would be great. I would
>> like to add them to the tree sometime in the next week.
> 
> I wonder, do you have a rationale for including each patch? IMO,
> Arfrever has a tendency to diverge a bit further from upstream than I
> like, and I note that you've taken in some patches and don't seem to
> have gone in upstream. 

To be honest, I did not look into each patch in great detail. I really
just tested the resulting builds to make sure they did not break
anything obvious.

That said, let's dive in!

> These are the  differences between my 2.7.3
> patchset and your 2.7.3-0:
> 
> 1. Added 08_all_regenerate_platform-specific_modules.patch, which
> doesn't seem to be upstream yet.

Indeed it does not. Based on the feedback in the upstream bug, let's
drop it.

> 2. Added back 22_all_turkish_locale.patch, which AFAIK isn't upstream,
> nor associated with an open upstream bug?

I can't find a bug for this either.

> 3. Added 61_all_process_data.patch, for which the goal seems somewhat unclear.
> 

This is some logic for python-wrapper that was in the 2.7.2 patchset as
well. If you want to drop it, I'm sure that will require some
re-engineering of python-wrapper.

> You also removed the mention of the upstream bug from
> 04_all_libdir.patch, probably just by mistake?
> 

I don't see any mention of a bug in the 2.7.2, 2.7.3 or 2.7.3-0 version
of the patch, so I'm not sure what you are referring to here.

> As for 3.2.3, I'm also -1 on including 23_all_h2py_encoding.patch
> after reading http://bugs.python.org/issue13032.

Agreed.

> Including
> 26_all_gdbm-1.9.patch in 3.1.5 is probably a good idea. For 3.1.5's
> 09_all_sys.platform_linux2.patch, I'd prefer if we just reuse
> ${FILESDIR}/linux2.patch, unless that doesn't apply for some reason.

I don't really see a difference either way. I guess it is more visible
in the ebuild.

> Now, we can certainly discuss adding these patches on this list, but I
> think we should try to maintain some balance on the upside of having
> extra fixes in our ebuilds and the amount of maintenance we're willing
> to do on carrying those patches forward (e.g. the distutils patch is a
> pretty big pain, and it seems like more of a feature than a bug).

Well, that does seem to be Arfrever's baby, so as long as he keeps
rebase it, we should be ok.

> I don't think we should throw everything out on revbumps or bugfix
> releases, but for new releases such as 3.3 I would personally like to
> do only the bare minimum of patching.
> 

That makes sense. I will keep it in mind.

Would you like me to cut a new set of tarballs without 08, 22, and 23?

Attachment:
signature.asc (OpenPGP digital signature)
Replies:
Re: Testing dev-lang/python version bumps
-- Dirkjan Ochtman
References:
Testing dev-lang/python version bumps
-- Mike Gilbert
Re: Testing dev-lang/python version bumps
-- Dirkjan Ochtman
Navigation:
Lists: gentoo-python: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Testing dev-lang/python version bumps
Next by thread:
Re: Testing dev-lang/python version bumps
Previous by date:
Re: Testing dev-lang/python version bumps
Next by date:
Re: Testing dev-lang/python version bumps


Updated Jun 29, 2012

Summary: Archive of the gentoo-python mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.