From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SNo8m-000723-PG for garchives@archives.gentoo.org; Fri, 27 Apr 2012 16:35:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7A078E08FC; Fri, 27 Apr 2012 16:35:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 46460E08FC for ; Fri, 27 Apr 2012 16:35:25 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: djc) by smtp.gentoo.org (Postfix) with ESMTPSA id 857781B4033 for ; Fri, 27 Apr 2012 16:35:24 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so842116wgb.10 for ; Fri, 27 Apr 2012 09:35:22 -0700 (PDT) Received: by 10.180.24.66 with SMTP id s2mr7606178wif.7.1335544522050; Fri, 27 Apr 2012 09:35:22 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussions centering around the Python ecosystem in Gentoo Linux X-BeenThere: gentoo-python@gentoo.org X-BeenThere: gentoo-python@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.18.208 with HTTP; Fri, 27 Apr 2012 09:35:01 -0700 (PDT) In-Reply-To: <4F9AB7AB.3050807@gentoo.org> References: <4F935B10.1030206@gentoo.org> <4F9AB7AB.3050807@gentoo.org> From: Dirkjan Ochtman Date: Fri, 27 Apr 2012 18:35:01 +0200 Message-ID: Subject: Re: [gentoo-python] Testing dev-lang/python version bumps To: Mike Gilbert Cc: gentoo-python@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 829762da-52cd-4bc8-88ad-07cb73dc34c3 X-Archives-Hash: 1559921d440ec781355858cd89ce83ac On Fri, Apr 27, 2012 at 17:13, Mike Gilbert 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