From Fedora Project Wiki
m (1 revision(s))
mNo edit summary
 
Line 1: Line 1:
= GCC 4.3 Rebuild Failures =
= GCC 4.3 Rebuild Failures =


== Why is this happening? ==
== Why is this happening? ==
Line 7: Line 5:
GCC 4.3 is an [[Features/GCC4.3|  accepted feature]]  of F9.  As part of this effort, a [[JesseKeating/gcc43MassRebuildProposal|  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).
GCC 4.3 is an [[Features/GCC4.3|  accepted feature]]  of F9.  As part of this effort, a [[JesseKeating/gcc43MassRebuildProposal|  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).


{{ Template:message/note | It is important to note that '''NO PROGRAMMING KNOWLEDGE''' is needed to assist in this effort
{{Admon/note | It is important to note that ''NO PROGRAMMING KNOWLEDGE'' is needed to assist in this effort}}
}}


== Sounds great! How do I do it? ==
== Sounds great! How do I do it? ==
Line 19: Line 16:
=== Getting down to business ===
=== Getting down to business ===


{{ Template:message/notice | All the bugs needing to be triaged are blocking the [https://bugzilla.redhat.com/showdependencytree.cgi?id=432425&hide_resolved=1 tracker bug here] and in NEW status
{{Admon/tip | All the bugs needing to be triaged are blocking the [https://bugzilla.redhat.com/showdependencytree.cgi?id=432425&hide_resolved=1 tracker bug here] and in NEW status}}
}}


Using [https://bugzilla.redhat.com/show_bug.cgi?id=433046 one bug]  as an example:
Using [https://bugzilla.redhat.com/show_bug.cgi?id=433046 one bug]  as an example:
Line 38: Line 34:


* If you have a ''compiler error'' (illustrated above):
* If you have a ''compiler error'' (illustrated above):
1. ''Remove'' the bug from the '''gcc43rebuildfail''' tracker
# ''Remove'' the bug from the '''gcc43rebuildfail''' tracker
1. ''Add'' the bug to the '''gcc43errors''' tracker
# ''Add'' the bug to the '''gcc43errors''' tracker
1. ''Change'' the status of the bug to ''ASSIGNED''.
# ''Change'' the status of the bug to ''ASSIGNED''.


== What other instances can there be? ==
== What other instances can there be? ==
Line 57: Line 53:


* If you have a ''dependency'' problem (illustrated above):
* If you have a ''dependency'' problem (illustrated above):
1. ''Copy'' the errors to the bugzilla
# ''Copy'' the errors to the bugzilla
1. ''Change'' the status to ''ASSIGNED'',
# ''Change'' the status to ''ASSIGNED'',
1. Keep the bug blocking the'''gcc43massrebuild''' tracker
# Keep the bug blocking the'''gcc43massrebuild''' tracker


=== Configure error ===
=== Configure error ===
Line 88: Line 84:


* If you have a ''configure error'' (illustrated above):
* If you have a ''configure error'' (illustrated above):
1. ''Copy'' the error message to the bugzilla
# ''Copy'' the error message to the bugzilla
1. ''Change'' the bug status to ''ASSIGNED''
# ''Change'' the bug status to ''ASSIGNED''
1. Keep it blocking the '''gcc43rebuildfail''' tracker
# Keep it blocking the '''gcc43rebuildfail''' tracker

Latest revision as of 13:07, 5 June 2008

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