[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Arch: all" package FTBFS due to test needing network access - RC?

On 30/10/06 at 17:36 +0200, Magnus Holmgren wrote:
> If an architecture-independent binary package fails to build because the build 
> target runs a test that needs network access, should that be considered 
> release critical, if the package requires network access to function in any 
> useful manner? Since the package is Architecture: all, no autobuilding is 
> needed on Debian's part, and building from source with dpkg-buildpackage 
> works in all normal situations.


I've worked/am working on archive rebuilds of etch currently, and I'm
concerned about this issue too, since my build environment doesn't allow
me to access the Internet.

> The concrete example I'm referring to is a simple Perl package 
> (libmail-dkim-perl, http://bugs.debian.org/395860).

I'm only rebuilding etch, so I didn't try this package. However, here is
a list of packages that accessed the network in some way other than DNS
during their build.

Packages which accessed the network AND failed to build (might be
unrelated): (6 packages)
libimage-info-perl 1.22-1
libmath-randomorg-perl 0.03-2
libpoe-component-client-http-perl 0.65-1
libwww-myspace-perl 0.48-2
python-vobject 0.0.svn155-2
rhino 1.6R2-1

Packages which accessed the network but built successfully: (62 pkgs)
bcfg2 choose-mirror control-center db4.2 debian-edu debian-med exim4
fast-user-switch-applet finance-yahooquote gnome-doc-utils
gnome-power-manager gnunet-gtk gtkmm2.0 imapcopy jmock kdetv kvpnc
libcommons-codec-java libcommons-collections3-java
libcommons-collections-java libcommons-dbcp-java libdtdparser-java
libmail-cclient-perl libnet-z3950-perl libpoe-component-irc-perl
libspork-perl libweather-com-perl libxml-stream-perl lucene mailagent
omnievents passepartout perl php-benchmark php-cache php-cache-lite
php-http-request php-image-canvas php-image-graph php-log
php-net-checkip php-net-dime php-net-ftp php-net-ldap php-net-sieve
php-net-smartirc php-net-url php-pager php-services-weather
php-simpletest php-soap phpunit2 php-xml-serializer php-xml-util postgis
pugs python-markdown sensors-applet sitemap stlport4.6 urlgrabber vdk2

My point of view would be that accessing the network during the build is
RC if:
- a network failure causes the build to fail
- a network failure causes the generated package to be different from
  the one generated when the network is available (files missing, for
example). (some packages amongst the 62 pkgs above might be in this

Some packages (e.g choose-mirror) fetch a newer version of a file during
build if it's possible to fetch that file. I don't think this is RC,
since the file is not missing from the package if the network is not

That was my humble opinion, and I'm not a DD.

> Normally, Debian, as a distribution, provides 
> a coherent platform in the form of a set of packages that have been tested 
> together, so that if the build dependencies are met, then the package builds, 
> and if the normal dependencies are met, then it runs. Running tests on many 
> computers with identical environments is then a bit redundant.
Such "redundant" tests have already been proven useful numerous times.
Changes in other packages can influence the behaviour of a package, and
the fact that a package builds if its build dependencies are satisfied
can only be considered true at the time of its upload, if the maintainer
has made the proper tests (build in a clean chroot/pbuilder).

| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Attachment: signature.asc
Description: Digital signature

Reply to: