Rawhide (dist-f14) now has python 2.7
Many thanks to everyone who helped get us this far!
Jesse and I moved 931 builds [1] from dist-f14-py27-rebuild to dist-f14 about 45 minutes ago. If I'm reading the Koji logs correct [2] [3], these packages are now available in the buildroot for F14, so further builds for "devel" will be against python 2.7
A further 26 builds in dist-f14-py27-rebuild had newer builds in rawhide, so we'll need to rebuild these; some are important e.g. yum and anaconda (see [1] again).
Packages should now be built into rawhide, rather than to the dist-f14-py27-rebuild target.
AdamW did some testing earlier using the py27 tag: "quick summary, preliminary findings: we can update a bare f13 live install pretty much okay, we can compose an f14 live pretty much okay (but can't test if it boots due to unrelated issues)" ; I've also been testing in runlevel3 on a rawhide box upgraded to the tag, and using it successfully as a development host for fixing other builds. However, this may be impacted by the newer builds mentioned above.
We briefly got down to 99 failing rebuilds, but there was a flaw in my original mass-rebuild method: I had only rebuilt packages with a requirement on: python(abi) = 2.6 which didn't catch packages with a requirement on: libpython2.6.so.1.0
I ran a script to rebuild anything with the second criterion that I'd missed; these mostly succeeded, but there were some new failures.
This brings the total number of failing rebuilds to 108: http://dmalcolm.fedorapeople.org/python-packaging/failures-2010-07-27-04.htm... with some new people listed there.
...plus the re-rebuilds mentioned above. I need food and sleep, so I plan to look at these rebuilds tomorrow.
Common rebuild issues (in no particular order): - gcc44 -> 45 changes - gtk issues (being discussed on desktop@lists.fedoraproject.org, though I believe most of the gtk folks are at GUADEC) - swig 1 -> swig 2 changes - configure.ac files that list python 2.2 2.3 2.4 2.5 2.6 but not 2.7 - any actual python 2.6 -> 2.7 issues (seemingly few of these so far) - boost, perhaps? (looks like we need to rebuild again for the SONAME bump)
See also: https://fedoraproject.org/wiki/Features/Python_2.7
Hope this all makes sense Dave
[1] http://dmalcolm.fedorapeople.org/python-packaging/mass-tag-from-dist-f14-py2...
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=2355260 [3] http://koji.fedoraproject.org/koji/getfile?taskID=2355261&name=createrep...
David Malcolm (dmalcolm@redhat.com) said:
A further 26 builds in dist-f14-py27-rebuild had newer builds in rawhide, so we'll need to rebuild these; some are important e.g. yum and anaconda (see [1] again).
Oof. In the future, can we make sure we just don't move these builds that override newer builds?
I was doing rebuilds against the new boost, and the fact that the older one was tagged over means that 5-10 of them now need rebuilt again, as the buildroot went backwards.
Bill
On Wed, 2010-07-28 at 11:55 -0400, Bill Nottingham wrote:
David Malcolm (dmalcolm@redhat.com) said:
A further 26 builds in dist-f14-py27-rebuild had newer builds in rawhide, so we'll need to rebuild these; some are important e.g. yum and anaconda (see [1] again).
Oof. In the future, can we make sure we just don't move these builds that override newer builds?
Looks like a bug in the script that I used; it was meant to not move them, but in fact it did.
I was doing rebuilds against the new boost, and the fact that the older one was tagged over means that 5-10 of them now need rebuilt again, as the buildroot went backwards.
Looking at boost, the log [1] contains: "Newer build found for boost." so it wasn't meant to have been moved.
However, looking at boost builds [2], I see: boost-1.41.0-13.fc14 built into dist-f14-py27-rebuild _did_ get moved into dist-f14.
Sorry about this.
It looks like oget has since built boost-1.44.0-0.3.fc14 into dist-f14 against python2.7, so presumably further builds in dist-f14 will pick up the correct version of boost.
Looking at the script [3], it looks like the indentation of the call to kojisession.tagBuildBypass(target, build) is wrong; it should be guarded by the "if not newer" conditional. Patch attached.
Grepping the log indicates that the list of 26 packages for which a newer build was replaced with an older build is: Django-south PyXML akonadi anaconda boost fonttools gdb gwibber hplip kdepimlibs libgsf libselinux livecd-tools mapserver pacemaker policycoreutils python-pyblock python-toscawidgets setroubleshoot source-highlight tryton vips virtaal xapian-bindings yum zinnia
All of these would have needed a rebuild anyway, and some already have been rebuilt.
Dave
[1] http://dmalcolm.fedorapeople.org/python-packaging/mass-tag-from-dist-f14-py2...
[2] http://koji.fedoraproject.org/koji/packageinfo?packageID=1074 [3] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/mass-tag.py;h=c62...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/28/2010 09:25 AM, David Malcolm wrote:
Looks like a bug in the script that I used; it was meant to not move them, but in fact it did.
D'oh. Due to an earlier bug in this script (which David successfully fixed) I didn't notice this later bug, which David is also fixing. My fault.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
David Malcolm wrote:
Looking at the script [3], it looks like the indentation of the call to kojisession.tagBuildBypass(target, build) is wrong; it should be guarded by the "if not newer" conditional. Patch attached.
Yuck! The joys of an indentation-sensitive language… :-(
Kevin Kofler
On Fri, 2010-07-30 at 21:18 +0200, Kevin Kofler wrote:
David Malcolm wrote:
Looking at the script [3], it looks like the indentation of the call to kojisession.tagBuildBypass(target, build) is wrong; it should be guarded by the "if not newer" conditional. Patch attached.
Yuck! The joys of an indentation-sensitive language… :-(
As opposed to leaving off a ; which NEVER happens.
-sv
Here are the latest results of our python-2.7-rebuilds. http://oget.fedorapeople.org/python27/python-27-rebuild-errors-20100731-1.ht...
Build failed in root.log: 25 packages Build failed in build.log: 38 packages Build succeeded, but may depend on old python (please check): 45 packages --- Total : 108 packages
Help from provenpackagers is appreciated. Thanks, Orcan
On Fri, Jul 30, 2010 at 11:21 AM, seth vidal skvidal@fedoraproject.org wrote:
As opposed to leaving off a ; which NEVER happens.
I never happens.. if you always use left handed emoticons <-;
-jef
On Wed, 2010-07-28 at 11:55 -0400, Bill Nottingham wrote:
David Malcolm (dmalcolm@redhat.com) said:
A further 26 builds in dist-f14-py27-rebuild had newer builds in rawhide, so we'll need to rebuild these; some are important e.g. yum and anaconda (see [1] again).
Oof. In the future, can we make sure we just don't move these builds that override newer builds?
I was doing rebuilds against the new boost, and the fact that the older one was tagged over means that 5-10 of them now need rebuilt again, as the buildroot went backwards.
Still, if they were in the py27 tag they *must* need to be rebuilt again anyway, because the later builds in Rawhide would have been against Python 2.6 and hence would be broken anyway. So in practice it doesn't make a huge different, AFAICT.
Adam Williamson (awilliam@redhat.com) said:
Still, if they were in the py27 tag they *must* need to be rebuilt again anyway, because the later builds in Rawhide would have been against Python 2.6 and hence would be broken anyway. So in practice it doesn't make a huge different, AFAICT.
Boost had python bindings. Most things that use boost don't use that, so it's more of a net win to do the boost rebuilds against the right major version of boost in conjunction with rebuilding boost for its python bindings, rather than building against the old version of boost with working python bindings.
Bill
David Malcolm wrote:
- configure.ac files that list python 2.2 2.3 2.4 2.5 2.6 but not 2.7
By the way, CMake also had this bug. I fixed cmake (in dist-f14) a while ago, so stuff using CMake should now work, unless they use their own .cmake files with the same bug to locate Python (in which case they need fixing just like the offending configure.ac files).
Kevin Kofler
On Tue, Jul 27, 2010 at 08:32:07PM -0400, David Malcolm wrote:
Rawhide (dist-f14) now has python 2.7
I have a machine which run rawhide since F11 times. Recently upgrade to python2.7 failed because of "rhpl" package. rhpl was removed from Fedora some time ago, so it wasn't rebuild lately. Now the question: what package should cause rhpl to be removed during update? Is there any obsoletes or conflicts that should cause rhpl to be removed during upgrades (F11→F15 time frame)?
On Wed, Aug 4, 2010 at 9:55 AM, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Tue, Jul 27, 2010 at 08:32:07PM -0400, David Malcolm wrote:
Rawhide (dist-f14) now has python 2.7
I have a machine which run rawhide since F11 times. Recently upgrade to python2.7 failed because of "rhpl" package. rhpl was removed from Fedora some time ago, so it wasn't rebuild lately. Now the question: what package should cause rhpl to be removed during update? Is there any obsoletes or conflicts that should cause rhpl to be removed during upgrades (F11→F15 time frame)?
I noticed this the other day as well. It should have been obsoleted by something so that it was removed on upgrade.
Peter
On Wed, Aug 04, 2010 at 10:17:27AM +0100, pbrobinson@gmail.com wrote:
On Wed, Aug 4, 2010 at 9:55 AM, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Tue, Jul 27, 2010 at 08:32:07PM -0400, David Malcolm wrote:
Rawhide (dist-f14) now has python 2.7
I have a machine which run rawhide since F11 times. Recently upgrade to python2.7 failed because of "rhpl" package. rhpl was removed from Fedora some time ago, so it wasn't rebuild lately. Now the question: what package should cause rhpl to be removed during update? Is there any obsoletes or conflicts that should cause rhpl to be removed during upgrades (F11→F15 time frame)?
I noticed this the other day as well. It should have been obsoleted by something so that it was removed on upgrade.
We've talked about adding Obsoletes for packages that are no longer in the repository with no replacement (as is the case for rhpl) to something like fedora-release before but AFAIK we've never pulled the trigger on actually doing it.
-Toshio
On Wed, 2010-08-04 at 11:46 -0400, Toshio Kuratomi wrote:
On Wed, Aug 04, 2010 at 10:17:27AM +0100, pbrobinson@gmail.com wrote:
On Wed, Aug 4, 2010 at 9:55 AM, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Tue, Jul 27, 2010 at 08:32:07PM -0400, David Malcolm wrote:
Rawhide (dist-f14) now has python 2.7
I have a machine which run rawhide since F11 times. Recently upgrade to python2.7 failed because of "rhpl" package. rhpl was removed from Fedora some time ago, so it wasn't rebuild lately. Now the question: what package should cause rhpl to be removed during update? Is there any obsoletes or conflicts that should cause rhpl to be removed during upgrades (F11→F15 time frame)?
I noticed this the other day as well. It should have been obsoleted by something so that it was removed on upgrade.
We've talked about adding Obsoletes for packages that are no longer in the repository with no replacement (as is the case for rhpl) to something like fedora-release before but AFAIK we've never pulled the trigger on actually doing it.
I think I had suggested it, multiple times, and each time fesco had a problem with it.
maybe even the package was named package-swift
http://skvidal.fedorapeople.org/misc/package-swift.spec
-sv
seth vidal skvidal@fedoraproject.org writes:
I think I had suggested it, multiple times, and each time fesco had a problem with it.
maybe even the package was named package-swift
You can also use package-cleanup --orphans.
Andreas.
On Wed, Aug 04, 2010 at 11:53:55AM -0400, seth vidal wrote:
I think I had suggested it, multiple times, and each time fesco had a problem with it. maybe even the package was named package-swift http://skvidal.fedorapeople.org/misc/package-swift.spec
Would it make sense for the obsolete list to be specified with versions?
On Wed, 2010-08-04 at 12:40 -0400, Matthew Miller wrote:
On Wed, Aug 04, 2010 at 11:53:55AM -0400, seth vidal wrote:
I think I had suggested it, multiple times, and each time fesco had a problem with it. maybe even the package was named package-swift http://skvidal.fedorapeople.org/misc/package-swift.spec
Would it make sense for the obsolete list to be specified with versions?
yes, of course - it was just a sample.
google for package-swift and/or look at the fesco discussions from dec or january and you'll see that discussed, ad nauseum.
-sv
On Wed, Aug 04, 2010 at 12:44:23PM -0400, seth vidal wrote:
Would it make sense for the obsolete list to be specified with versions?
yes, of course - it was just a sample. google for package-swift and/or look at the fesco discussions from dec or january and you'll see that discussed, ad nauseum.
Ok, cool. I'll stay out of it then. :)
On Wed, 2010-08-04 at 13:01 -0400, Matthew Miller wrote:
On Wed, Aug 04, 2010 at 12:44:23PM -0400, seth vidal wrote:
Would it make sense for the obsolete list to be specified with versions?
yes, of course - it was just a sample. google for package-swift and/or look at the fesco discussions from dec or january and you'll see that discussed, ad nauseum.
Ok, cool. I'll stay out of it then. :)
you're welcome to pick up the torch. I'm more than happy for that to happen. I just didn't have the bandwidth to keep it going.
-sv (sorry for the mixed metaphor)
-
Adam Williamson -
Andreas Schwab -
Bill Nottingham -
David Malcolm -
Jef Spaleta -
Jesse Keating -
José Abílio Matos -
Kevin Kofler -
Matthew Miller -
Orcan Ogetbil -
Peter Robinson -
Seth Vidal -
Tomasz Torcz -
Toshio Kuratomi