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 | [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]
Rebuilding all etch packages inside etch, round 2
Lucas Nussbaum writes: > Hi, > > > I only built packages according to their Architecture: field. I didn't > consider the Packages-arch-specific list. > I see you have failed build logs for mozart, but from the control file: Package: mozart Architecture: hppa i386 m68k mipsel mips powerpc sparc s390 arm So, why was it tried? cheers k PS. Please cc me, I trimmed debian-release and I am not subscribed to debian-qa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
On Wed, 2006-10-18 at 11:16 +0200, Lucas Nussbaum wrote: > 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. No, this is definately a bug. I've indeed encountered it a couple of times already in Perl test suites. It's a problem because: - It's a privacy concern - without being asked, some information about the system is being sent to a remote host; - I should be able to build a package on e.g. my disconnected laptop or on your disconnected cluster; - The test has a high probability to fail lateron because of the referenced host disappearing. Scanning through your logs, I've "only" found 3 perl packages that fail on this, I'll make sure I'll file the appropriate bugs on them (libmath-randomorg-perl, libpoe-component-client-http-perl, libwww-myspace-perl). Thijs signature.asc Description: This is a digitally signed message part
Re: Rebuilding all etch packages inside etch, round 2
* Thijs Kinkhorst ([EMAIL PROTECTED]) [061018 11:34]: > On Wed, 2006-10-18 at 11:16 +0200, Lucas Nussbaum wrote: > > 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. > > No, this is definately a bug. I've indeed encountered it a couple of > times already in Perl test suites. It's a problem because: > - It's a privacy concern - without being asked, some information about > the system is being sent to a remote host; > - I should be able to build a package on e.g. my disconnected laptop > or on your disconnected cluster; > - The test has a high probability to fail lateron because of the > referenced host disappearing. Actually, in a test it *might* be ok. Usually, even if they're bugs, they're not RC. Access to a debian-mirror is necessary for some packages, but rather on a exception-basis - almost all packages need to build with the packages they got installed via build-dependencies. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
On Wed, 2006-10-18 at 11:41 +0200, Andreas Barth wrote: > Actually, in a test it *might* be ok. Usually, even if they're bugs, > they're not RC. > > Access to a debian-mirror is necessary for some packages, but rather > on a exception-basis - almost all packages need to build with the > packages they got installed via build-dependencies. I'm not strongly opinionated on whether or not they are RC, but given the noted concerns I think filing it as an "important" bug is justified. Thijs signature.asc Description: This is a digitally signed message part
Re: Rebuilding all etch packages inside etch, round 2
On Wed, Oct 18, 2006, Lucas Nussbaum wrote: > 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 ? I think a Wiki page would be nice. I'd like to clear my own build failures, and I suppose others as well. Now that I'm at it: - flumotion: python-central not installable, needs newer debhelper, should be ok now - gnome-python-desktop: python-central not installable, needs newer debhelper, should be ok now - rhythmbox: python-gtk2-dev not installable, needs newer python-gtk2, should be ok now -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
(Dropping d-release; please CC d-boot as I'm not subscribed to d-qa.) On Wednesday 18 October 2006 11:16, Lucas Nussbaum wrote: > 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. > 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/ Thanks for your efforts on this. I've taken a look at the failures for the debian-boot team (Debian Installer): choose-mirror localechooser Both fail with the following error: The following packages have unmet dependencies: python-xml: Depends: python-central (>= 0.4.15) but it is not going to be installed I expect this is either a transient error or a bug in the python packaging. I would probably be good if someone could check for this globally. installation-guide BR already reassigned to w3m (#393641; reduced to normal); the segfault has possibly been resolved for the installation guide by setting an alternative PATH in the build script. As this is an Arch:all package, I'm not particularly bothered by the failure anyway. linux-kernel-di-amd64-2.6 linux-modules-di-amd64-2.6 Both of these are not really meant to be built on buildds... The log of the first does not really give any indication of what goes wrong. The second is a relatively new package that currently depends on an old kernel for transition purposes. This should be fixed with the next migration of the package. Anyway, I'm inclined to ignore both of these. Cheers, FJP pgp9khj9FDhIQ.pgp Description: PGP signature
Re: Rebuilding all etch packages inside etch, round 2
On Wed, Oct 18, 2006, Frans Pop wrote: > python-xml: Depends: python-central (>= 0.4.15) but it is not going > to be installed > I expect this is either a transient error or a bug in the python > packaging. I would probably be good if someone could check for this > globally. I got python-central installation failures in my logs as well, this is because debhelper was not available in a sufficiently high version, but should be fixed now. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
On 18/10/06 at 11:52 +0200, Thijs Kinkhorst wrote: > On Wed, 2006-10-18 at 11:41 +0200, Andreas Barth wrote: > > Actually, in a test it *might* be ok. Usually, even if they're bugs, > > they're not RC. > > > > Access to a debian-mirror is necessary for some packages, but rather > > on a exception-basis - almost all packages need to build with the > > packages they got installed via build-dependencies. > > I'm not strongly opinionated on whether or not they are RC, but given > the noted concerns I think filing it as an "important" bug is justified. The main problem with my setup is that access to the outside world is firewalled to protect the outside world, but DNS do work, so tests take a very long time to fail. It would be really nice if those tests could first check if they can reach the remote site, and only run the tests if this is OK. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: Rebuilding all etch packages inside etch, round 2
On 18/10/06 at 08:49 -0500, Kevin Glynn wrote: > Lucas Nussbaum writes: > > Hi, > > > > > > > I only built packages according to their Architecture: field. I didn't > > consider the Packages-arch-specific list. > > > > I see you have failed build logs for mozart, but from the control file: > > Package: mozart > Architecture: hppa i386 m68k mipsel mips powerpc sparc s390 arm > > So, why was it tried? Because, from the Sources file: Package: mozart Binary: mozart, mozart-doc Version: 1.3.2.20060615-2 Priority: optional Section: devel Maintainer: Kevin Glynn <[EMAIL PROTECTED]> Build-Depends: debhelper (>> 4.0.0), bison (>= 1.25), flex-old (>= 2.5.3), gs, l ibgdbm-dev, libgmp3-dev, m4, netpbm, sp, tcl8.4-dev, tetex-bin, tetex-extra, tk8 .4-dev, zlib1g-dev, emacs21 | xemacs21 Architecture: any ^ Anyway, this will go away when I'll support Packages-arch-specific[0]. It says: %mozart: !alpha !ia64 !amd64# %'who would ever need > 32-bits??' [0] http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak&rev=HEAD That's great, because it means I have yet another huge list of easy-to-get-rid-of false positive :) -- | 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]
