Created attachment 308667 [details, diff] python-2.7.3.diff I did the work to sync and test python-2.7.3 on amd64-linux. (see attached diff) It would be great if the following would happen: * Tested on other arches (especially aqua support and solaris) * Research if irix and interix patches are applied upstream OR * Decide to drop those two failing patches * Either case, decide to spin a new patchball or not (reduce ebuild diffs if new patchball) I did NOT look into the two failing patches because I don't care about the platforms (or python's upstream) If the patch looks good, I can commit this bump too. I just didn't want to until someone else ACK'd.
- $([[ "${PV}" =~ ^[[:digit:]]+\.[[:digit:]]+_pre ]] && echo "doc? ( dev-python/sphinx )") + doc? ( dev-python/sphinx ) !sys-devel/gcc[libffi]" - $([[ "${PV}" =~ ^[[:digit:]]+\.[[:digit:]]+_pre ]] || echo "doc? ( dev-python/python-docs:${SLOT} )")" + doc? ( dev-python/python-docs:${SLOT} )" These changes look wrong. I think the original lines wanted dev-python/sphinx for pre releases to build the docs itself, but the released versions wanted dev-python/python-docs prebuilt. Now all versions depend on both packages... Was that change really intended? As you dropped all the code wrt. _pre, should "doc? (dev-python/sphinx)" just be removed?
please check http://prefix.gentooexperimental.org:8000/python-patches-2_7/ if you are familiar with hg (it's a Mercurial patchqueue, since Python's sources are in Mercurial)
(In reply to comment #1) > <snip stuff> You are asking on the wrong bug. This bug is about matching the Gentoo Prefix version to gentoo-x86. (In reply to comment #2) > please check http://prefix.gentooexperimental.org:8000/python-patches-2_7/ > if you are familiar with hg (it's a Mercurial patchqueue, since Python's > sources are in Mercurial) Does this comment apply to ANYTHING in comment #0? I know where the patches are hosted but I can't solely decide to drop patches or spin a new tarball. (Well, I can and I will if needed but my decisions are simply to drop patches and not spin a new tarball because I'm lazy and don't care about irix or interix)
(In reply to comment #3) > Does this comment apply to ANYTHING in comment #0? I know where the patches > are hosted but I can't solely decide to drop patches or spin a new tarball. > (Well, I can and I will if needed but my decisions are simply to drop > patches and not spin a new tarball because I'm lazy and don't care about > irix or interix) IMHO it does, because hg is good at "rebasing" patches, or at least allows you to easily fix patches with minimal efforts. Bug references should be there, and new patchbals should be spun from that hg repo, or we'll lose track easily.
Well, I looked at the patchball and IMHO, you should spin a new patchball WITHOUT 14_all_irix-libpython.patch & 16_all_interix.patch because of the following reasons: IRIX: Upstream has been waiting for Stuart to sign paperwork for 2 years. Safe to assume that he doesn't care if his patch is upstreamed so we shouldn't care. We don't support IRIX in the tree anyway. INTERIX: No upstream reference. mduft doesn't care so we shouldn't care. I'm aware that the exclusion of these patches will break those arches, but..."we" shouldn't be maintaining such a nightmare in python without other devs help. Furthermore, there is CVEs in the current python. (and a simpler ebuild now due to new python maintainers in Gentoo)
(In reply to comment #5) > I'm aware that the exclusion of these patches will break those arches, > but..."we" shouldn't be maintaining such a nightmare in python without other > devs help. Furthermore, there is CVEs in the current python. (and a simpler > ebuild now due to new python maintainers in Gentoo) Had you minded checking a little bit why most patches failed to apply, you'd noticed that upstream renamed configure.in to configure.ac.
Why are you defending IRIX patches? We don't support it anywhere in the tree and closed all the bugs in bugzilla? My assessment in comment #5 stands
I'm not defending them, but they dont' fail either. Python itself does fail, and I'd have appreciated it a lot if instead you'd have invested your time in trying to understand why on earth there is a python2 that triggers collision-protect, and why some weird grep errors occur after installation.
(In reply to comment #8) > Python itself does fail, and I'd have appreciated it a lot if instead you'd > have invested your time in trying to understand why on earth there is a > python2 that triggers collision-protect, and why some weird grep errors > occur after installation. That didn't happen for me. I've been using this version since comment #0 (~2 weeks)
(In reply to comment #9) > (In reply to comment #8) > > > Python itself does fail, and I'd have appreciated it a lot if instead you'd > > have invested your time in trying to understand why on earth there is a > > python2 that triggers collision-protect, and why some weird grep errors > > occur after installation. > > That didn't happen for me. I've been using this version since comment #0 (~2 > weeks) Thanks for bumping, I can only see it as long term win...eventually. I just verified that nothing bad happened for me with the 2.7.3 ebuild in the tree. I guess your issues are on non-linux? Will you please open a (new) bug report so that we can track the issues that you reported in the package.mask message? Including steps to reproduce. More eyes = better.
Well, python is broken, and since it's not on any of my amd64 (Gentoo Linux) boxes, I guess we're not /that/ behind. Since the codebase of python 2.7 branch has considerably changed, I'd rather wait for 2.7.4.
We could move the 2.7.3 mask to Darwin/BSD. I think this upstream bug/fix is the culprit: http://bugs.python.org/issue8746
