Please stabilise python-2.5.
Anyone?
Adding arches.
What about bug 148333? There are still packages that don't work with Python 2.5, plus it's not even out of hardmask yet
(In reply to comment #0) > Please stabilise python-2.5. dev-lang/python-2.5 doesn't exist in the tree.
Removing arches until the Python team specifies a version they think is ready to go stable.
> dev-lang/python-2.5 doesn't exist in the tree. Witty. Python 2.5 does indeed exist in the tree.
> What about bug 148333? There are still packages that don't work with Python 2.5, plus it's not even out of hardmask yet If a package doesn't work, then it can DEPEND on an earlier python version. That is why we have version dependencies. It is no reason to hold up stabilisation. From python.org: "The current production version is Python 2.5.1. You should start here if you want to learn Python or if you want the most stable version." Upstream considers 2.5.1 "the most stable version". Should it not be eligible for stabilisation?
Chris, please let the python herd decide when to unmask and when to stabilize AFTER that happens. Closing...
> let the python herd decide when to unmask and when to stabilize AFTER that happens That is what I have done - the bug is assigned to the python herd, they have control. However, after 30 days there had been no response, so I CC'd the arch teams as protocol allows. This is a valid (enhancement) bug report. Resolving it as 'CANTFIX' is incorrect - the bug can (and should be) fixed at some point in the future. Feel free to resolve it 'LATER' if you wish. The proper course of action would be to make the bugs that are holding up stabilisation depend on this bug, so that it's clear to everyone why 2.5 can't be stabilised.
With respect to the guys fixing bug 148333, I wouldn't know about the packages that Python-2.5 supposedly blacks beacuse *they aren't installed on my system*. What reasoning is behind a decision to block everyone's installation of Python-2.5 over packages that are not commonly installed?? trac? numeric? yodl? genshi?? Are you joking me? Those are the reasons that Python-2.5 is hardmasked? I know someone (or some people) in the world have the executive power to do that, but it should be tempered by common sense. Is there something I'm missing here?
@KingLeonidas: Unfortunately yes. Bug #183977 is more complicated than it seems. At the moment, we 'sed' out almost all *_require from setup.py to avoid: a) That the installation of a package fails because an entry in install_require refers to a package which is being installed but doesn't have egg-info (pretty common case with py-2.4 for packages not using setuptools) and therefore being ignored by setuptools. b) That packages in *_require are being auto-fetched which would generate collisions and a larger mess The problem is that there are packages around which check during runtime for plugins/extensions/whatever in that egg-information and fail if they don't find anything (like turbogears with genshi). And at the moment we're working on a solution for this.
Good to know... and thanks for telling! I know this sounds a bit strange, but could you drop us a status-line in here from time to time, so we know what's happening (and don't feel like standing in the rain without a clue when it will stop)? I know we could instead join the Python herd, but there's only so many things you can do at the same time, and my time slots are already (over-)filled. And it would make the Python herd seem much more transparent...
ok, we will try. It seems to me that some kind of "message channels" in Gentoo would be a good thing.
Some message channels other than the GWN would definitely be good, because the GWN isn't that useful when I'm mostly interested in one aspect of the system. As a first step it might e possible to just declare a specific bug the official point of information, but on the long run a cleaner way might be much preferable. One idea I deem possible is to use Drupal for community blogs and to give each member of a herd - or at least each herd - an account, so people can just subscribe to feeds by topic/tag/keyword. http://drupal.org But at first, an official "Python-herd - what we are doing" bug might already help much. And if that bug gets referenced as information source somehwere on the outside of bugzilla, people should be able to find it more easily (and at the same time get drawn into the bug system and that way get used to it).
Come on guys, python 2.4 is broken for pygtk bindings the tree is nearly done can we unmask python 2.5 and get it going ? Need any help around here ?
Just for those who didn't notice, Python 2.5.1-r2 is ~arch for just about everything. Thanks devs!
Is this going to be done ever? Python guys: if you need help with something, please, ask for it. It seems this won't be done for 2008.0 but at least it could be done by 2008.1.
Having the numeric dependency bug (http://bugs.gentoo.org/show_bug.cgi?id=181653) in here doesn't seem appropriate anymore: ------- Comment #12 From Luis Medinas (RETIRED) 2007-07-26 23:57:36 0000 [reply] ------- the current numeric on the tree works on amd64 with py2.5 so we don't have to worry now. The python team can unmask py2.5 when they want it won't affect us Can we remove 181653 from the list of dependencies?
Just a status message: #148333 needs only three more changes: - Test why rekall 2.4.6 isn't in the tree, even though there's an ebuild and a resolved bug for it: #200151 - update the pygame ebuild to apply the patch (ebuild and patch are avaible): #194932 - Update the xapian ebuild to 1.0.5 (ebuilds for xapian and xapian-bindings is avaible, both build for me on amd64): #185837 And with these changes, all dependencies of this bug should be resolved, so I don't see any dependencies in the way of stabilizing python 2.5. If there are still blockers, please add them.
Please remove 181653 from the list of dependencies. It is solved in another bug. Besides: Can we somehow help the python herd? Do you need more people to do the work? I've been diving into python for the last 6 months, and I'd love to help out where I can.
It seems that dev-python/numeric has been patched to work with 2.5, so only dev-db/rekall and x11-misc/qterm are left, I propose we force depends <python-2.5 on both and propose python 2.5 for stabilisation. I will proceed in one week if no one objects.
Don't forget stabilizing dev-python/pygame-1.8.0 with Python 2.5.
ping? (just wondering if 2.5 will come soon or if I should cave in and merge it from ~arch)
(In reply to comment #21) > It seems that dev-python/numeric has been patched to work with 2.5, so only > dev-db/rekall and x11-misc/qterm are left, I propose we force depends > <python-2.5 on both and propose python 2.5 for stabilisation. I will proceed in > one week if no one objects. Any news on the stabilisation?
As talked over with hawking, ccing arches. Architecture teams: Please check all blockers before stabilising it. Thanks.
@Python: Should we stabilize any of the new python-updater versions?
(In reply to comment #26) > @Python: Should we stabilize any of the new python-updater versions? > bug 208902. Coldwind can you drop older soappy versions and fix bug 208902? I do not have access to my devbox right now...
(In reply to comment #27) > Coldwind can you drop older soappy versions and fix bug 208902? > I do not have access to my devbox right now... Done.
ppc64 stable. I looked carefully at the dependent bugs and decided to mark some of the packages stable, even if there hasn't been an OK from some maintainers to stabilize the necessary versions. There hasn't been an "NO", too.
(In reply to comment #29) > ppc64 stable. > > I looked carefully at the dependent bugs and decided to mark some of the > packages stable, even if there hasn't been an OK from some maintainers to > stabilize the necessary versions. There hasn't been an "NO", too. This does not mean to rush it for the others, I have to or three more candidates that need newer stable versions...but I still need to check.
I found two more packages: pyreverse and prewikka (which are linked against 148333). Both have no reverse dependencies, so I assume we can go on with stabilisation.
ppc stable
x86 stable and as a major arch, we will see 1000 of damned users now. :)
I saw that python-docs was stabilized at 2.5.1, not 2.5.2. Is there any reason why it is not kept in sync with the main package? There may not be much of a difference between .1 and .2, but even then I'd vote for consistency, especially since it is just a simple tarball.
(In reply to comment #34) > I saw that python-docs was stabilized at 2.5.1, not 2.5.2. Is there any reason > why it is not kept in sync with the main package? There may not be much of a > difference between .1 and .2, but even then I'd vote for consistency, > especially since it is just a simple tarball. If there had been a 2.5.2 ebuild for python-docs, I would have stabilised that. Python team?
ia64/sparc stable
Stabilized python-2.5.2-r5 and python-docs-2.5.1 on alpha.
Stable for HPPA.
I should become an arch tester... I have been using python 2.5 for several months on amd64 without a single problem. Should be stable.
amd64 ... done!
