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 | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]