Bugzilla Bug 178800

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!