Rebuilding all etch packages inside etch, round 2
Hi,
I built packages from main which where supposed to build on AMD64
according to their Architecture: field in a etch AMD64 chroot. Using
sbuild improved the situation a lot compared to my first attempt[1].
However, 548 packages still fail to build.
[1] http://lists.debian.org/debian-qa/2006/10/msg00034.html
The list of packages which failed to build is available at:
http://ox.blop.info/bazaar/buildlogs/20061017/000FailedBuilds-list.txt
Sorted using dd-list:
http://ox.blop.info/bazaar/buildlogs/20061017/000FailedBuilds-ddlist.txt
All build logs from failed builds:
http://ox.blop.info/bazaar/buildlogs/20061017/
There's a problem on AMD64 with the kernel version I was using (2.6.12),
causing messages like "Inconsistency detected by ld.so: rtld.c: 1075:
dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!"
(Packages affected: aegis gcc-3.4 geant321 installation-guide lapack3
mclibs newlib-m68hc1x paw pocketpc-gcc scalapack urlgrabber vtk). Ignore
the build failure if your package is affected. I'll try to fix that
soon.
I built the versions of the packages in testing. Newer versions in
unstable might fix the failure, I haven't tried to determine that
automatically.
I only built packages according to their Architecture: field. I didn't
consider the Packages-arch-specific list.
Internet access was not available from the nodes. Are build scripts
allowed to download files from the Internet during build ? Some perl
modules do this in their tests.
I started filing bugs, and after interactions with the release team :)
(thanks Steve & Andreas for providing comments), here are some notes
about how I determined they should be filed after several
severity-downgrades ;) :
* A arch:all package doesn't need to be buildable on all archs (not RC,
can be filed as important I think?)
* A package which has never been built on $arch (due to
Packages-arch-specific restrictions for example) doesn't build on
$arch => not RC, can be filed as important
* Transient problems don't need to be filed of course, except if the
transientness has high changes of becoming permanent (e.g build-dep on
a package not in testing because it has non-trivial RC bugs)
I'm not going to process all the logs, so feel free to pick up some of
them and work on them. Maybe we should find a way to work together on
this ? (like a list of packages on wiki.d.o or in a svn repos ?)
Are there some wiki-like table edition tool ?
Do you have ideas/suggestions to improve the whole process ?
If you file bugs, please credit the Grid'5000 project as I did in
#392117 for example: it's important if I want to be able to continue to
use the resources.
The rebuilt was done on about 40 AMD64 nodes of the Grid'5000 platform.
The Grid'5000 project aims at building a highly reconfigurable
experimental Grid platform gathering 9 sites and featuring a total of
5000 CPUs. Its main purpose is to serve as an experimental testbed for
research in Grid Computing. To learn more about Grid'5000, read
https://www.grid5000.fr/
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: