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: Mike Gilbert <floppym@g.o>
From: Dirkjan Ochtman <djc@g.o>
Subject: Re: Testing dev-lang/python version bumps
Date: Fri, 27 Apr 2012 18:35:01 +0200
On Fri, Apr 27, 2012 at 17:13, Mike Gilbert <floppym@g.o> wrote:
> 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.

I can imagine, I just think it's probably good if we do look at
patches in detail.

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

Right. Do you know what this fixes, and how/why it will be
re-engineered? As long as we don't know these things, I'd prefer to
leave the patch out rather than include it.

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

Are you sure? The 04* patch I just unpacked from my 2.7.3 patch set
does have a bug in it (maybe it wasn't in 2.7.2, though).

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

I like the fact that it's a single patch for all the versions, and
that we don't have to manage it separately in the patch sets.

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

Yeah, I'd really prefer to have us not depend on Arfrever for our
dev-lang/python updates. IMO we should drop this from 3.3 pending
upstream movement.

> 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?

That would be perfect. I'd also still like to drop 61 unless we have a
clear picture of what/why it helps (and can document that in the
patch).

Cheers,

Dirkjan


Replies:
Re: Testing dev-lang/python version bumps
-- Mike Gilbert
Re: Testing dev-lang/python version bumps
-- Mike Gilbert
References:
Testing dev-lang/python version bumps
-- Mike Gilbert
Re: Testing dev-lang/python version bumps
-- Dirkjan Ochtman
Re: Testing dev-lang/python version bumps
-- Mike Gilbert
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.