|
Home > Archive > Debian Developers > November 2006 > "Arch: all" package FTBFS due to test needing network access - RC?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"Arch: all" package FTBFS due to test needing network access - RC?
|
|
| Magnus Holmgren 2006-10-30, 1:19 pm |
| | |
| Lucas Nussbaum 2006-10-30, 1:19 pm |
| 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.
Hi,
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
OR
- 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
case)
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
available.
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).
Regards,
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
| |
| Peter Palfrader 2006-10-30, 7:31 pm |
| On Mon, 30 Oct 2006, Lucas Nussbaum wrote:
> 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
> available.
Actually, I think that's a very, very bad idea. It makes builds not
repeatable, so if something weird goes wrong later you might not be able
to reproduce it with a package you built for debugging purproses now.
Peter
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `- http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2006-10-30, 7:31 pm |
| On Mon, Oct 30, 2006 at 05:36:57PM +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.
> The concrete example I'm referring to is a simple PERL package
> (libmail-dkim-perl, http://bugs.debian.org/395860). It seems to be quite
> common to include test scripts with those, but some tests don't go well with
> unattended building, for example if they are interactive or require internet
> access. Is the consensus still that running as many of the tests as possible
> is desirable in this situation? 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.
Interactive tests or tests requiring network access should not have to pass
in order to build a package. Autobuilding is not the only case we want to
support, here; we have users who may want to change and rebuild packages in
their environment where they have access to source DVDs but no Internet, we
have users who may be trying to do offline test builds on their laptops,
etc. We also don't want packages to FTBFS because some network service that
Debian has no control over has been discontinued or is suffering from an
outage.
Keeping such tests in package builds is fine, but they should either be
disabled by default (enabled with an environment variable, say), or they
should be informational only.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2006-10-31, 1:31 am |
| Steve Langasek <vorlon@debian.org> writes:
> Interactive tests or tests requiring network access should not have to
> pass in order to build a package.
What about tests that only require localhost be available? I'd been
puzzling over that for a bit with some of the PERL module tests.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2006-10-31, 7:23 am |
| Russ Allbery <rra@debian.org> writes:
> Steve Langasek <vorlon@debian.org> writes:
>
>
> What about tests that only require localhost be available? I'd been
> puzzling over that for a bit with some of the PERL module tests.
Vservers have problems with localhost as you can have only one
127.0.0.1 in total. One of the amd64 is (was?) running as vserver adn
a few packages had problems with that.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2006-11-01, 1:44 am |
| On Mon, Oct 30, 2006 at 07:57:51PM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:
[vbcol=seagreen]
> What about tests that only require localhost be available? I'd been
> puzzling over that for a bit with some of the PERL module tests.
I think it's reasonable to expect both localhost and 127.0.0.1 to be
reachable during builds. I believe the vserver problems mentioned elsewhere
have been addressed on the vserver side, and I think that's the right
solution because telling the world they can no longer count on the existence
of localhost would be a very hard sell, and not something I see any reason
for Debian to be taking the lead on.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Lucas Nussbaum 2006-11-01, 1:45 am |
| (Cced the relevant bug report)
On 31/10/06 at 23:50 -0500, Anthony DeRobertis wrote:
> Lucas Nussbaum wrote:
>
>
> In general, I strongly suspect that fetching updated source during build
> is RC due to a violation of the Social Contract: the source we are
> shipping intentionally does not correspond to the binary package.
>
> I'm not sure if the above applies to choose-mirror. In particular, if
> the file shipped in the binary is its own source, then it doesn't.
> However, I'd still say it's bad idea, and a bug (maybe even RC). Some
> more general reasons (not all necessarily apply to choose-mirror)
>
> * changes to the package are not reflected in the changelog
> * random network or remote server issues can cause a broken (or
> worse) build. What happens if the file on the server is corrupted?
> * builds are no longer repeatable. Different source may even wind up
> built on different architectures.
> * the package is much harder to NMU. What should be a spelling fix
> suddenly becomes a large change (due to the automated source
> pull), unbeknown to the NMU-er. Same problem for the security team.
> * the supposedly-signed source package isn't really; it's pulling
> unsigned source for the build
>
> Also, depending on what is being downloaded from the network, there
> could be security issues. What happens if the server is compromised?
While I fully agree with you on all points, I think that this should be
discussed post-etch with the general question of "in which environment
are packages supposed to build ?". There are other similar issue, like:
- should packages allow to build as root ? (aegis, bazaar, subversion
don't)
- should packages build the same if they are built in a minimal debian
environment only satisfying their b-dep, and in a system with lots of
useless packages installed ?
There are RC bugs to fix now ;)
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2006-11-01, 1:45 am |
| On Wed, Nov 01, 2006 at 08:02:22AM +0100, Lucas Nussbaum wrote:
> While I fully agree with you on all points, I think that this should be
> discussed post-etch with the general question of "in which environment
> are packages supposed to build ?". There are other similar issue, like:
> - should packages allow to build as root ? (aegis, bazaar, subversion
> don't)
This question is misphrased; the real question is, "should we require that
all packages be buildable as root?" And I don't see any reason the answer
to this question is "yes".
> - should packages build the same if they are built in a minimal debian
> environment only satisfying their b-dep, and in a system with lots of
> useless packages installed ?
These are already RC bugs due to non-reproducibility of builds, they just
aren't practical to find systematically.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Samuelson 2006-11-02, 1:25 am |
|
> Robert Collins <robertc@robertcollins.net> writes:
[Goswin von Brederlow][vbcol=seagreen]
> That test should add a test for root and skip it. If that is the only
> reason not to build as root then that should be no excuse (post
> etch).
Your unspoken premise is that there is a _reason_ to support building
packages as root. Why? I think it is better just to tell people not
to do that.
| |
| Manoj Srivastava 2006-11-02, 1:25 am |
| On Wed, 1 Nov 2006 23:53:32 -0600, Peter Samuelson <peter@p12n.org> said:
[vbcol=seagreen]
> [Goswin von Brederlow]
[vbcol=seagreen]
> Your unspoken premise is that there is a _reason_ to support
> building packages as root. Why? I think it is better just to tell
> people not to do that.
Wring question. The right question is, why should we restrict
the choices the user has, provided we have informed him of the
potential problems it might cause?
QA number of times, in a virtual machine I am building, I
build software, but have not bothered to create non-root users.
Seems like a perfectly fine thing to do -- why should I not do that,
pray?
manoj
--
For every problem there is one solution which is simple, neat, and
wrong. Mencken
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2006-11-02, 7:21 am |
| Peter Samuelson <peter@p12n.org> writes:
>
> [Goswin von Brederlow]
>
> Your unspoken premise is that there is a _reason_ to support building
> packages as root. Why? I think it is better just to tell people not
> to do that.
My premise is that there is no reason to sabotage building as
root. Nearly all sources do build as root and many test suites skip
tests that fail as root. I see no reason to stop that now.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Samuelson 2006-11-02, 7:21 am |
|
[Goswin von Brederlow]
>
> My premise is that there is no reason to sabotage building as
> root. Nearly all sources do build as root and many test suites skip
> tests that fail as root. I see no reason to stop that now.
We're not talking about sabotage, we're talking about extra effort.
I have a reason not to support building packages as root: it is more
work for me, it takes time which I could be using to fix bugs or write
manpages. Now it is your turn to give me a reason to support building
packages as root. What is so important about building as root that I
should spend time making it work? Also keep in mind that my upstream
takes the same position that I do.
| |
| Goswin von Brederlow 2006-11-02, 1:18 pm |
| Peter Samuelson <peter@p12n.org> writes:
> [Goswin von Brederlow]
>
> We're not talking about sabotage, we're talking about extra effort.
>
> I have a reason not to support building packages as root: it is more
> work for me, it takes time which I could be using to fix bugs or write
> manpages. Now it is your turn to give me a reason to support building
> packages as root. What is so important about building as root that I
> should spend time making it work? Also keep in mind that my upstream
> takes the same position that I do.
Wait for a bug, tag the bug help and then add the patch if somone
bothers to write one.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-11-02, 1:18 pm |
| On Thu, 2 Nov 2006 03:59:17 -0600, Peter Samuelson <peter@p12n.org> said:
> [Goswin von Brederlow]
[vbcol=seagreen]
> We're not talking about sabotage, we're talking about extra effort.
Not really an answer I expected from a DD.
> I have a reason not to support building packages as root: it is more
> work for me, it takes time which I could be using to fix bugs or
> write manpages. Now it is your turn to give me a reason to support
> building packages as root. What is so important about building as
> root that I should spend time making it work? Also keep in mind
> that my upstream takes the same position that I do.
Offering options to users does add to th quality of
implementation, just as fixing bugs or writing man pages does. Your
argument seems to be that doing anything else for debian or one's
packages apart from bug fixing or writing man pages is a waste of
time -- so, to please you, should we just mass file bugs so you can
happily fix them while allowing root to build packages? 
BTW, I do practice what I preach: mailagent has a series of
tests it runs that fail when run as root, so for about a decade now
mailagent has detected that it is running as root, and then su's to a
non-root user to run the tests. This is not rocket science. It is
not a whole truckload of code either -- and you can steal what
mailagent does if you want an example
manoj
--
The only unbreakable rule: To thine own self be true, and it follows
as the night the day that you cannot be false to any man.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Samuelson 2006-11-02, 7:21 pm |
|
[Manoj Srivastava]
>
> Not really an answer I expected from a DD.
I don't mind putting in extra effort when there is some gain to be had.
I'm not so excited about putting in extra effort when there is no gain
to be had. I'm still waiting for the answer to why it is so important
that users be able to build our packages as root. So far all I'm
hearing is "what if I can't be bothered to create a non-root user"
which, to me, just doesn't sound very compelling.
> Offering options to users does add to th quality of
> implementation, just as fixing bugs or writing man pages does.
You mean offering options to users who want to rebuild packages we
already provide for them. That would be a set of users who already
went to a certain amount of trouble to set up a chroot and 'apt-get
build-dep' inside the chroot. (If they aren't building in a chroot,
the argument about 'adduser' doesn't really hold up.) I just don't see
a lot of value in saving those users from the two extra steps of
calling 'adduser foo' and 'su foo'.
> Your argument seems to be that doing anything else for debian or
> one's packages apart from bug fixing or writing man pages is a waste
> of time -- so, to please you, should we just mass file bugs so you
> can happily fix them while allowing root to build packages?
If I ever run short on real bugs to fix, I'll let you know. (:
Seriously, of course I care about quality of implementation, I just
don't see how the ability to build as root is particularly necessary to
any user under any circumstances. As such, it seems like a waste of
time to go out of one's way to support it.
> mailagent has a series of tests it runs that fail when run as root,
> so for about a decade now mailagent has detected that it is running
> as root, and then su's to a non-root user to run the tests.
So I guess that assumes there's a handy non-root user that could have
been used to build the package in the first place. So much for _that_
counter-argument, then.
|
|
|
|
|