This has been discussed already in the dev ml and there's bug 347639 about how to fix it. I don't want to argue about the commit, I'm just tired to have stage generation fail and want to fix this for releng. I opened this bug because I'm going to revert to the old python ebuilds, the ones before the initial commit, and will leave up to the python team and QA sort this out. The commits that broke stage generation were the following: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-2.6.5-r3.ebuild?r1=1.8&r2=1.9 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-3.1.2-r4.ebuild?r1=1.9&r2=1.10 There were more commits to other versions, but those are irrelevant for stage generation. Please note these were direct commits to stable, which is a clear violation of policy. I *kindly* request that whatever solution is agreed upon to "improve" or "fix" the python ebuilds follows procedure and RelEng is allowed to test it before it hits the stable tree. We've had enough stage breaking lately.
I think that the following commit should fix this problem: http://overlays.gentoo.org/proj/python/changeset/405 If there are no objections, then I could backport this change to gentoo-x86 ebuilds.
I just revert the commits to python-3.1.2-r4 and python-2.6.5-r3.
(In reply to comment #0) > Please note these were direct commits to stable, which is a clear violation of > policy. They breakage was unexpected and touching the ebuilds was announced two weeks in advance. You had your chance to stop it. Also, I worked on fixing the problem after that. I don't think it's fair to put that into the "policy violation" finger-pointing box. > I *kindly* request that whatever solution is agreed upon to "improve" > or "fix" the python ebuilds follows procedure and RelEng is allowed to test it > before it hits the stable tree. We've had enough stage breaking lately. Did you even test the latest patch I proposed? I never got feedback on that from you. If you and I don't agree on which patch to choose (yours or mine), what gives you the right to decide over my head? Just that I didn't test with stage creation doesn't mean I haven't put hours of testing into this. You can never test everything. Why is fixed stages more important than finally disabling autobumping? Do you decide? I am seriously disappointed how you just push me aside. (In reply to comment #2) > I just revert the commits to python-3.1.2-r4 and python-2.6.5-r3. That's very uncooperative.
(In reply to comment #3) > (In reply to comment #0) > > Please note these were direct commits to stable, which is a clear violation of > > policy. > > They breakage was unexpected and touching the ebuilds was announced two weeks > in advance. You had your chance to stop it. Also, I worked on fixing the > problem after that. I don't think it's fair to put that into the "policy > violation" finger-pointing box. As you know you broke policy and announcing it in advance doesn't allow you to commit direct to stable. This should have been committed to the testing tree so more testing could have been done. > > I *kindly* request that whatever solution is agreed upon to "improve" > > or "fix" the python ebuilds follows procedure and RelEng is allowed to test it > > before it hits the stable tree. We've had enough stage breaking lately. > > Did you even test the latest patch I proposed? I never got feedback on that > from you. If you and I don't agree on which patch to choose (yours or mine), > what gives you the right to decide over my head? Just that I didn't test with > stage creation doesn't mean I haven't put hours of testing into this. You can > never test everything. > > Why is fixed stages more important than finally disabling autobumping? Do you > decide? I am seriously disappointed how you just push me aside. I didn't push you aside nor am I against your goal. I also have no interest in pushing "my patch". It was meant as a "quick fix" so we could have stages back. I'll leave to the python team to find a proper solution to the issue. What I don't want is for us to continue to be unable to produce new stages whilst python searches "new roads". > (In reply to comment #2) > > I just revert the commits to python-3.1.2-r4 and python-2.6.5-r3. > > That's very uncooperative. In case you're not aware Arfrever also gave me a patch to test. Not being in the python team nor having any particular knowledge about it, the proposed patches seemed to me to go in complete opposite directions. I'm not trying to decide what the python team does nor do I want to get involved on it, what I want is to be able to use python in Gentoo. It seems somewhere along the road the python team forgot python is not just another "toy" in the tree, but a *vital* part of Gentoo.
> It seems > somewhere along the road the python team forgot python is not just another > "toy" in the tree, but a *vital* part of Gentoo. You cannot blame me for that: I haven't touched dev-lang/python before a few weeks ago. I wonder why I even spent time on trying to fix your Python.
(In reply to comment #5) > > It seems > > somewhere along the road the python team forgot python is not just another > > "toy" in the tree, but a *vital* part of Gentoo. > > You cannot blame me for that: I haven't touched dev-lang/python before a few > weeks ago. I'm not blaming you for what happened before. > I wonder why I even spent time on trying to fix your Python. I'm sorry if my actions have demotivated you or gave you the impression your work isn't appreciated. I do value and appreciate the goal of your work on python.
I will put my QA hat and support Jorge and his actions. Touching stable ebuilds like that is not acceptable. It is ok if you fix a typo or something but altering the behavior like that is beyond acceptable limits. Sebastian, stages are highly important to our users. The point here is NOT to do beta testing on your patches. The right thing to do was to revert changes as quick as possible, get stage generation back, then work on a feasible solution on *testing* python ebuilds. A fellow developer proposed to add python alias to autobuild email reports. Please consider following his advice so @python get early notifications about stages.
Is this considered fixed by now? In Prefix we experience what I believe is this very same bug, where our bootstraps are left without usr/bin/python. ensure_python_symlink just calls "eselect python update --python2", but this is not enough to create the usr/bin/python symlink.
Fabian, my "revert" touched only python-2.6.5-r3 and python-3.1.2-r4. I'm going to do another revert in a few minutes to python-2.6.6-r1 as it was marked stable on x86 and the stages failed to build yesterday as a consequence. Be sure to check which version you're using for prefix as you may need to "revert" another version.
(In reply to comment #9) > Fabian, > > my "revert" touched only python-2.6.5-r3 and python-3.1.2-r4. I'm going to do > another revert in a few minutes to python-2.6.6-r1 as it was marked stable on > x86 and the stages failed to build yesterday as a consequence. > Be sure to check which version you're using for prefix as you may need to > "revert" another version. > Any reason why you don't just do 2.7.1 too? That will be our (prefix) issue because we only have a ~arch concept.
(In reply to comment #10) > (In reply to comment #9) > Any reason why you don't just do 2.7.1 too? That will be our (prefix) issue > because we only have a ~arch concept. Because I tried to touch as little ebuilds as possible. @QA: What do you say? Should all ebuilds be reverted or should we only touch the required ebuilds?
As the Python lead, I would be in favor of reverting the change in all of the ebuilds for now. I can probably do it myself later today if noone else can.
Ah, thanks, that explains. We are indeed trying to skip 2.6 for new bootstraps, so we only end up with 2.7 and no garbage from previous versions left (no python-updating, etc.), which means 2.7.1 is our current first emerged python version.
I'm also in favor of reverting all of them. We could work on the patches after the crisis has been solved.
Ok, I'm reverting the following: - 2.4.6: from 1.43 to 1.41 - 2.5.4-r4: from 1.25 to 1.23 - 2.6.5-r3: from 1.10 to 1.8 (already done by Jorge) - 2.7.1: from 1.3 to 1.1 - 2.7: from 1.6 to 1.4 - 3.1.2-r4 (already done by Jorge) - 3.1.3: from 1.3 to 1.1 I have a question though, and thats why im CC'ing HPPA and x86 arches. 2.6.6-r1 is supposed to be reverted from 1.7 to 1.3 but this version was made stable in HPPA and x86 recently, so I don`t know is you guys prefer to re-stable it, or I should just stable it again in the process (STABLEREQ was bug #342927).
01 Jan 2011; Jorge Manuel B. S. Vicetto <jmbsvicetto@gentoo.org> python-2.6.6-r1.ebuild: Non-maintainer commit. Reverting commit that broke stage generation for python-2.6.6-r1 as it wasn't reverted before - bug 347867. This commit was accepted by Arfrever.
I've committed the revert for python-2.6.6-r1 (straight to stable) as there was no feedback to Jesus comment, more arches marked it stable and the stages were breaking because of it. @python: Have you been discussing / thinking about how to fix the background issue?
(In reply to comment #17) > Have you been discussing / thinking about how to fix the background issue? It will be fixed in 2.6.6-r2, 2.7.1-r1 and 3.1.3-r1.
(In reply to comment #18) > (In reply to comment #17) > > Have you been discussing / thinking about how to fix the background issue? > > It will be fixed in 2.6.6-r2, 2.7.1-r1 and 3.1.3-r1. Can you please let us know *how* you are going to "fix it"? Also, can we know if there was any discussion at all of it in the python team?
(In reply to comment #19) The code will be copied from primary ebuilds of Python 2.7/3.1/3.2: http://overlays.gentoo.org/proj/python/browser/overlays/python/dev-lang/python
I noticed that there is a certain diversity in implementation of this code between versions now. Because bootstrapping for us is still broken, I now copied the code from 2.6.6-r1 into 2.7.1 (which is what we bootstrap with), because it looks like it's more likely to be fixing things than what's in 2.7.1 right now. The code in the overlay is also different and I'm not sure if that will work, but it might.
