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=dakrev=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]
