From Fedora Project Wiki

m (Remove extra line break)
(add F29FTBFS)
Line 40: Line 40:
* F27? ([[Fedora 27 Mass Rebuild]])
* F27? ([[Fedora 27 Mass Rebuild]])
* [https://bugzilla.redhat.com/show_bug.cgi?id=1555378 F28FTBFS] ([[Fedora 28 Mass Rebuild]])
* [https://bugzilla.redhat.com/show_bug.cgi?id=1555378 F28FTBFS] ([[Fedora 28 Mass Rebuild]])
* [https://bugzilla.redhat.com/show_bug.cgi?id=1602938]([[Fedora 29 Mass Rebuild]])


== What to do if you get a FTBFS bug? ==
== What to do if you get a FTBFS bug? ==

Revision as of 19:13, 29 July 2018

This page describes the policy for packages that no longer build and need developer attention.

The schedule for most releases of Fedora includes a mass rebuild (e.g. Fedora 27 Mass Rebuild, Fedora 28 Mass Rebuild) to update the packages with new features of the compiler, packaging, build flags, etc. This serves as a convenient opportunity to detect all packages which no longer build properly.

Package Removal for Long-standing FTBFS bugs

Packages which fail to build will be retired after a period of time.

  1. Releng perfoms the mass rebuild and will open bugs for any packages which fail.
  2. Maintainers should either fix and close the bug or acknowledge that they are working on a solution by setting the state to ASSIGNED.
  3. If a FTBFS bug remains in NEW state, a weekly reminder will be sent. The package will be orphaned after the FTBFS bug is in NEW state for 8 weeks.
  4. The normal Orphaned package that need new maintainers procedure will be followed for the packages orphaned in this way, leading to their retirement if nobody adopts them.
  5. A week before the mass branching any packages which still have open FTBFS bugs from the previous release will be retired.

(Effectively, packages will be retired after 14 weeks if there is no maintainer response and the package is orphaned, or after 6½ months if the maintainer responds but the bug is not fixed.)

Only one FTBFS bug should be open at any time against a given package. If the package FTBFS in more than one mass rebuild, the bug will be set as blocking for all relevant tracking bugs.

Tracking bugs

What to do if you get a FTBFS bug?

  • Read the logs. Each FTBFS bug should have the build logs attached.
  • If the build of your package fails due to a bug in your package:
  1. Fix the problems uncovered and commit the changes.
  2. Build the package. The fixed package will land in rawhide, generally the next day. If branching has already occurred, also fix the build in branched.
  3. If the build succeeds, close the bug as CLOSED: RAWHIDE, and include the package version number in the comments.
  4. If branching already occurred, but bodhi hasn't been activated yet, also build the package in branched.
  5. If bodhi has already been activated for branched, also make an update. An update should be made even if branched has already been released.
  • If the build of your package fails due to a bug in another package (such as a compiler bug or missing dependency):
  1. Find an existing bug for that package describing the problem. Set your bug to "Depends on" that other bug. Do not change the component of your bug to the other package, or you will get more FTBFS bugs created against you.
  2. When that other bug is closed, you'll get an email from bugzilla as usual. Rebuild your package using a koji scratch build, to verify it builds cleanly again. Proceed according to points 2-5 above.

In all cases, if you close an FTBFS bug as a duplicate of another bug, please make the other bug to block the right FTBFS tracking bugs. This way the bug left open will appear in the FTBFS reports properly.

See also

Retrieved from "https://fedoraproject.org/w/index.php?title=Fails_to_build_from_source&oldid=522897"