Fedora 15 Mass Rebuild

Goal
The goal is to rebuild every single Fedora package, regardless of content, before the Fedora 15 Feature Freeze (February 08th).

Driving Features
this just needs gcc-4.6 in the buildroot
 * GCC-4.6

There is an incompatible xz format in Fedora 15. The XZ package was upgraded to 5.0, which brought small changes in the compression support. This primarily impacts deltarpms, and should not prevent F15 packages from being manipulated by F14 (and possibly older) RPM. E.g. Mock builds on F14 for Fedora 15 should continue to work.
 * XZ RPM payloads

To a lesser extent to take advantage of the new rpm features.
 * RPM 4.9

Schedule
Given the changes required for the above features and the given schedules, Release Engineering will be ready to start scripted rebuilds on Monday, Feb 7th. All automated rebuilds should be finished prior to the Feature Freeze, which is Feb 8th. Any clean-up manual rebuilds should be finished prior to the Alpha Freeze, which is Feb 4th. .

Opting Out
Due to the tight schedules there is no opt out this time around.

Scripts
Release Engineering has created two scripts. One is to initiate the builds, and the other is to query for items still needing to be built.

Build Initiation
The rebuild script works in the following way:

Generate a list of all packages in dist-f12 Loop through each package: Query if a build has already been attempted/completed since koji changes went live. If so, move to next package If not, check out CVS Check for a noautobuild file If so, move to next package If not, rpmdev-bumpspec cvs commit;tag make (background) build Move on to next package

Each step will have some error catching and logging so that people can clean up the various failures for whatever reasons. The builds will be background builds, which will allow other builds done to take higher priority when a builder has a free slot. However maintainers should take care when doing this so that the background build won't take 'latest' precedent when it finishes. Asking rel-eng to kill the scripted build will typically be enough.

Build Tagging
Once the rebuild script has finished, another script will run to tag the builds into dist-f15. This script will check that a newer build hasn't been done or started in dist-f12 since the scripted rebuild was submitted. This will protect against the scripted rebuild overriding an even newer build done while the scripted rebuild was waiting in the background.

Status Query
Release Engineering has developed a script to query dist-f15 and report on packages that have yet to be rebuilt. Results of these queries will be delivered to various places, yet to be determined, broken down by maintainer for easier discovery of work needed.

Maintainer Actions

 * Maintainers that wish to do their own builds should read the Opting Out section.
 * Maintainers can help this effort by ensuring rpmdev-bumpspec correctly bumps your package's spec files.
 * Maintainers should ensure that their packages currently build from source.
 * Maintainers should ensure that there are no unwanted changes committed to git but not built yet.

How do I opt out of the scripted rebuild?
See the Opting Out section.

When will my own build "count" for the rebuild?
After the updated gcc for gcc is put into place, a build done by a maintainer will "count" toward the rebuild. 2011-02-05 10:18:38 is the UTC time that builds count from

Will the rebuilds be ordered?
Currently there is no plan to logically order the rebuilds based on deps. The ordering will be alphanumerical based on package name. There are no planned ABI/soname changes that would require logical build ordering. Further, all the builds will be kept in a special tag (dist-f15-rebuild) until the whole run is done, and then they will be tagged into dist-f15 in one shot to minimize the shuffle of buildroot contents during the rebuilds.

Feedback
Questions/comments/concerns should be directed to, the discussion page, or #fedora-devel on freenode IRC.