BugZappers/GCC43RebuildFailures

GCC 4.3 Rebuild Failures

Why is this happening?

GCC 4.3 is an accepted feature of F9. As part of this effort, a mass rebuild of all GCC compiled packages in the Fedora distribution is required. Some of these builds will fail for various reasons, including but not limited to actual compiler failures. The goal of this project is to separate the compiler failures from the other reasons, so that the compiler can be fixed (or bad code fixed).

It is important to note that NO PROGRAMMING KNOWLEDGE is needed to assist in this effort

Sounds great! How do I do it?

Terminology

mock takes a srpm and builds it in a chroot. This ensures that your BuildRequires lines are correct, that there are no missing dependencies, and that it builds cleanly.

A buildroot is chroot created by mock for building a package

Getting down to business

All the bugs needing to be triaged are blocking the tracker bug here and in NEW status

Using one bug as an example:

• Click on the link to Koji that you see in the bug
• On the resulting page, there will be several buildArch tasks. One of them will be in red, indicating that it failed.
• Click on the task that failed .
• Note that the result field says BuildrootError: error building package (arch x86_64), mock exited with status 1 - this means that the buildroot successfully created, and the build step failed.
• In this case, click on build.log and look at the end for any errors, in this case, a compiler error:

contacts-utils.c:36: error: static declaration of 'e_util_unicode_get_utf8' follows non-static declaration
contacts-utils.h:25: error: previous declaration of 'e_util_unicode_get_utf8' was here
contacts-utils.c: In function 'contacts_choose_photo':
contacts-utils.c:601: warning: assignment from incompatible pointer type

• If you have a compiler error (illustrated above):

1. Remove the bug from the gcc43rebuildfail tracker
2. Add the bug to the gcc43errors tracker
3. Change the status of the bug to ASSIGNED.

What other instances can there be?

Mock will tell you why a build has failed. It tells you with the exit code, which is a hint as to what log file to look into. We've already seen exit code 1, which is a build time error. The likely exit codes you will see include:

• 1: Build problem. Look in build.log
• 10: Could not find a BuildRequire. Look in root.log
• 30: Problem installing BuildRequires, such as broken deps, or URL timeouts. Look in root.log

Below is more detailed information.

Buildroot dependency problem

In this case , you can see that mock exited with a status of 30. This indicates that the buildroot did not compose successfully, due to broken dependencies. The output from building the buildroot is in root.log instead of build.log. Looking there, we see the reason for the failure:

DEBUG util.py:261:  Error: Missing Dependency: libcap.so.1()(64bit) is needed by package dbus-libs
DEBUG util.py:261:  Error: Missing Dependency: libcap.so.1()(64bit) is needed by package dbus

• If you have a dependency problem (illustrated above):

1. Copy the errors to the bugzilla
2. Change the status to ASSIGNED,
3. Keep the bug blocking thegcc43massrebuild tracker

Configure error

Here is an example of a package that the buildroot built successfully for it, however the configure step of the package did not complete. Here are the errors:

checking for DRIVEL... configure: error: Package requirements (
glib-2.0 >= 2.4.0
gmodule-2.0 >= 2.4.0
gtk+-2.0 >= 2.4.0
gconf-2.0 >= 2.0.0
gnome-vfs-2.0 >= 2.6.0
libgnome-2.0 >= 2.0.0
libgnomeui-2.0 >= 2.0.0
libglade-2.0 >= 2.0.0
gtksourceview-1.0 >= 1.0.0
libsoup-2.2 >= 2.2.97
libxml-2.0 >= 2.4.0
libbonobo-2.0 >= 2.0.0
bonobo-activation-2.0 >= 2.0.0
gtkspell-2.0
dbus-glib-1
) were not met:

No package 'libsoup-2.2' found

• If you have a configure error (illustrated above):

1. Copy the error message to the bugzilla
2. Change the bug status to ASSIGNED
3. Keep it blocking the gcc43rebuildfail tracker