+ # Fails to build from source, Fails to install

+ :toc:

+ 

+ This page describes *the policy for packages that no longer build or install* and

+ need developer attention.

+ 

+ The schedule for most releases of Fedora includes a mass rebuild (e.g.

+ https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild],

+ https://fedoraproject.org/wiki/Fedora_28_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.

+ 

+ ## Glossary

+ 

+ FTBFS:: Fails To Build From Sources

+ FTI:: Fails To Install (usually due to broken dependencies)

+ 

+ 

+ ## Package Removal for Long-standing FTBFS and FTI bugs

+ 

+ Packages which fail to build or fail to install will be orphaned and/or

+ retired after a period of time.

+ 

+ 1.  If a package *fails to build from sources* or *fails to install*,

+     any concerned party can *file a bug* in Bugzilla blocking a FTBFS/FTI

+     tracker, providing information about the failure.

+     * A bug about build failure needs to block the FTBFS tracker for the

+       appropriate release, eg. F30FTBFS for Fedora 30, see list below.

+     * A bug about installation failure needs to block the FTI tracker for

+       the appropriate release, eg. F30FTI for Fedora 30, see list below.

+     * One bug can block multiple trackers if convenient. Reporters are

+       encouraged to search for duplicates first.

+ 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 an FTBFS or FTI bug remains in the NEW state for at least *1

+     week*, any concerned party can set a *NEEDINFO* for the maintainer to

+     respond and send an *e-mail reminder* with the Bugzilla link to

+     `+<component_name>-maintainers@fedoraproject.org+`, cc'ing the

+     https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/[devel

+     mailing list] (so there is a public record) and commenting on the bug

+     about doing so.

+ 4.  If the bug remains in NEW state for at least another 3 weeks after

+     the NEEDINFO and e-mail (= at least for *4 weeks* in total), any concerned party

+     can send *another comment and e-mail* (as in the previous point).

+ 5.  If the bug remains in NEW state for at least another 4 weeks after

+     the second e-mail and comment (= at least *8 weeks* in total), the package

+     will be *orphaned*. Orphaning can be requested via a releng issue.

+ 6.  The normal

+     https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers[Orphaned

+     package that needs new maintainers procedure] will be followed for the

+     packages orphaned in this way, leading to their *retirement* if nobody

+     adopts them.

+ 7.  A week before the *mass branching*, any packages which still have

+     open FTBFS bugs from the previous release will be *retired*. This can be

+     requested via a releng issue.

+ 8.  A week before the scheduled *beta freeze*, any packages which have

+     open FTI bugs in the NEW state with at least 8 weekly reminders will

+     be** retired** from the relevant release and rawhide (in addition to

+     being orphaned). (Releng ticket for this needs to be opened at least a

+     week before the freeze, but can be opened sooner.)

+ 9.  The previous point repeats for the *final freeze*.

+ 

+ (Effectively, packages will be retired after 14 weeks or sooner if there

+ is no maintainer response and the package is orphaned, or after 6½

+ months if the maintainer responds to FTBFS but the bug is not fixed.)

+ 

+ When releng performs the

+ https://docs.pagure.org/releng/sop_mass_rebuild.html[mass rebuild],

+ releng opens FTBFS bugs for any packages which fail to build. Anyone can

+ send the weekly reminders and request packages to be orphaned/retired –

+ in other words, the procedure can be applied manually.

+ At any point, releng can automate any steps mentioned above,

+ but this is not required.

+ 

+ Anytime a releng ticket is open, please cross reference it from the bug

+ report.

+ 

+ 

+ ## Tracking bugs

+ 

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=440169[generic

+ FTBFS blocker bug]

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=440169&hide_resolved=1[F9FTBFS]

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=463452&hide_resolved=1[F10FTBFS]

+ * F11 was handled by Release Engineering, no FTBFS bugs were filed.

+ http://jkeating.fedorapeople.org/needed-f11-rebuilds.html

+ (https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild[Fedora 11 Mass Rebuild])

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=511348&hide_resolved=1[F12FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild[Fedora 12 Mass Rebuild])

+ * https://bugzilla.redhat.com/showdependencytree.cgi?id=538681&hide_resolved=1[F13FTBFS]

+ ** https://bugzilla.redhat.com/showdependencytree.cgi?id=564245&hide_resolved=1[F13FTBFS

+ due to] Features/ChangeInImplicitDSOLinking

+ * https://bugzilla.redhat.com/show_bug.cgi?id=596849[F14FTBFS]

+ * https://bugzilla.redhat.com/show_bug.cgi?id=659965[F15FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild[Fedora 15 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=713919[F16FTBFS]

+ * https://bugzilla.redhat.com/show_bug.cgi?id=817273[F17FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild[Fedora 17 Mass Rebuild])

+ * There seem to be no FTBFS bugs reported for Fedora 18, list of failed

+ builds from the mass rebuild:

+ http://fedorapeople.org/~ausil/f18-failures.html

+ (https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild[Fedora 18 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=913825[F19FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild[Fedora 19 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=991858[F20FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild[Fedora 20 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1105908[F21FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild[Fedora 21 Mass Rebuild])

+ * F22?

+ * F23? (https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild[Fedora 23 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1305208[F24FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild[Fedora 24 Mass Rebuild])

+ * No mass rebuild in F25

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1423041[F26FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild[Fedora 26 Mass Rebuild])

+ * F27? (https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1555378[F28FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1602938[F29FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild[Fedora 29 Mass Rebuild])

+ * https://bugzilla.redhat.com/show_bug.cgi?id=1674516[F30FTBFS]

+ (https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild[Fedora 30 Mass Rebuild])

+ 

+ ## 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 _Fixed In Version_ field.

+     Here is a command line template for powerusers:

+     `+bugzilla modify --close RAWHIDE <bug-number> --comment

+     'Built successfully in rawhide' -F <package-nevr>+`

+ 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.

+ 

+ * If the package is no longer useful to the Fedora project, it should be

+ retired.

+ See https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life[How

+ to remove a package at end of life].

+ 

+ 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

+ 

+ * FESCo ticket updating this policy: https://pagure.io/fesco/issue/2109

+ * releng docs:

+ https://docs.pagure.org/releng/sop_deprecate_ftbfs_packages.html