Debian Bug report logs - #403246
sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable

version graph

Package: sbuild; Maintainer for sbuild is Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>; Source for sbuild is src:sbuild.

Reported by: Lucas Nussbaum <lucas@lucas-nussbaum.net>

Date: Fri, 15 Dec 2006 19:03:01 UTC

Severity: important

Tags: fixed-upstream, patch

Found in version sbuild/0.52

Fixed in version sbuild/0.62.0-1

Done: Roger Leigh <rleigh@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
New Bug report received and forwarded. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: submit@bugs.debian.org
Subject: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Fri, 15 Dec 2006 19:13:06 +0100
Package: sbuild
Version: 0.52

Hi,

While rebuilding the simpledb package, I ran into a problem described in
#403059. It build-depends on libstdc++6-4.0-dev | libstdc++5-3.3-dev.
libstdc++6-4.0-dev is no longer installable, so it should have tried
libstdc++5-3.3-dev, but instead, it just failed.

** Using build dependencies supplied by package:
Build-Depends: debhelper (>= 4.0.0), unixodbc-dev, libstdc++6-4.0-dev |
libstdc++5-3.3-dev
Checking for already installed source dependencies...
debhelper: missing
unixodbc-dev: missing
libstdc++6-4.0-dev: missing
libstdc++5-3.3-dev: missing
Checking for source dependency conflicts...
Reading package lists...
Building dependency tree...
E: Couldn't find package libstdc++6-4.0-dev
apt-get failed.
Package installation failed

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



Severity set to `important' from `normal' Request was from Touko Korpela <tkorpela@phnet.fi> to control@bugs.debian.org. (Mon, 13 Aug 2007 12:21:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. Full text and rfc822 format available.

Acknowledgement sent to Piotr Ożarowski <piotr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #12 received at 403246@bugs.debian.org (full text, mbox):

From: Piotr Ożarowski <piotr@debian.org>
To: 403246@bugs.debian.org
Subject: should this bug be reassigned to the policy?
Date: Fri, 21 Mar 2008 23:06:08 +0100
Hi,

I was told to reassign this bug to policy asking to forbid alternate
build dependencies. Although I agree that alt. b. dep. are evil most of
the times, I still think they're quite useful in few cases (see #471617)
so I will not do this. Please feel free to reassign it there and I will
forget about (mentioned in #471617) Debian Python policy's spirit and
update all my packages that suffer from this bug.

If you think this bug should be fixed anyway (I don't see "wontfix" tag),
please tell me, I will learn perl and fix it for you.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. Full text and rfc822 format available.

Message #15 received at 403246@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Piotr Ożarowski <piotr@debian.org>
Cc: 403246@bugs.debian.org
Subject: Re: should this bug be reassigned to the policy?
Date: Mon, 26 May 2008 10:10:32 +0200
On Fri, Mar 21, 2008 at 11:06:08PM +0100, Piotr Ożarowski wrote:
> Hi,
> 
> I was told to reassign this bug to policy asking to forbid alternate
> build dependencies.

Who told you?  I don't see it in this bug log.

Also, please note that "forbid" them isn't really accurate.  It gives the
impression these aren't currently taken into account by policy, but in fact
policy explicitly says this can be done in section 7.1 (second paragraph).

> Although I agree that alt. b. dep. are evil most of
> the times, I still think they're quite useful in few cases (see #471617)

The problem is in fact quite common when you try to recompile a package from
testing on stable.  Our syntax is smart enough to specify different situations
in which a package is considered "buildable", and so is the parser in dpkg-dev,
so it would sound like this shouldn't be a problem when producing backports,

But, alas, not quite:

  http://lists.backports.org/lurker-bpo/message/20080421.205337.663c04a8.en.html

> so I will not do this. Please feel free to reassign it there and I will
> forget about (mentioned in #471617) Debian Python policy's spirit and
> update all my packages that suffer from this bug.

Policy makes it clear that this syntax is allowed, other utilities (e.g.
dpkg-checkbuilddeps) comply with Policy but sbuild doesn't.  It sounds
clearly like a bug in sbuild to me.

> If you think this bug should be fixed anyway (I don't see "wontfix" tag),
> please tell me, I will learn perl and fix it for you.

I'd appreciate if you did.  I've been wanting to fix this for a long time,
but never got around to it (I don't know perl either).

Thank you

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@whinlatter.ukfsn.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #20 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@whinlatter.ukfsn.org>
To: Robert Millan <rmh@aybabtu.com>
Cc: 403246@bugs.debian.org, Piotr Ożarowski <piotr@debian.org>
Subject: Re: [Buildd-tools-devel] Bug#403246: should this bug be reassigned to the policy?
Date: Mon, 26 May 2008 11:20:21 +0100
[Message part 1 (text/plain, inline)]
Robert Millan <rmh@aybabtu.com> writes:

> On Fri, Mar 21, 2008 at 11:06:08PM +0100, Piotr Ożarowski wrote:
> Policy makes it clear that this syntax is allowed, other utilities (e.g.
> dpkg-checkbuilddeps) comply with Policy but sbuild doesn't.  It sounds
> clearly like a bug in sbuild to me.
>
>> If you think this bug should be fixed anyway (I don't see "wontfix" tag),
>> please tell me, I will learn perl and fix it for you.
>
> I'd appreciate if you did.  I've been wanting to fix this for a long time,
> but never got around to it (I don't know perl either).

Patches are always welcome.  Even if you aren't familiar with Perl, I
can help review any changes you want to make.  It might be that if you
can describe what aspect of the current behaviour is wrong I can try
to implement the change for you.

In this case, however, there is a need to retain compatibility with
the version used on the autobuilders, despite it also being broken.
This would mean it won't break Lucas' autobuilder and people can still
rely on the old behaviour (needed to test if packages autobuild
correctly on the Debian autobuilders).  I would suggest simply adding
a new config option such as

  $broken_dependencies=0

to disable that, and make your changes conditional in the code:

  if ($conf::broken_dependencies) {
     [old behaviour]
  } else {
     [correct behaviour]
  }

At such time this version is used on all buildds, and it definitely
complies with Policy, we can switch it to be the default and remove
the old broken code.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Mon, 12 Jan 2009 16:51:03 GMT) Full text and rfc822 format available.

Message #23 received at 403246@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: 403246@bugs.debian.org
Cc: Lucas Nussbaum <lucas@lucas-nussbaum.net>
Subject: is this bug fixed?
Date: Mon, 12 Jan 2009 17:48:55 +0100
Hi,

I just noticed this while reading sbuild.conf:

# Algorithm for build dependency checks: possible values are
# "first_only" (used by Debian buildds) or "alternatives". Default:
# "first_only".
#$check_depends_algorithm = "first-only";

does this mean this bug is fixed now?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 14 Jan 2009 10:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 14 Jan 2009 10:42:05 GMT) Full text and rfc822 format available.

Message #28 received at 403246@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Robert Millan <rmh@aybabtu.com>
Cc: 403246@bugs.debian.org
Subject: Re: is this bug fixed?
Date: Wed, 14 Jan 2009 11:30:34 +0100
On 12/01/09 at 17:48 +0100, Robert Millan wrote:
> 
> Hi,
> 
> I just noticed this while reading sbuild.conf:
> 
> # Algorithm for build dependency checks: possible values are
> # "first_only" (used by Debian buildds) or "alternatives". Default:
> # "first_only".
> #$check_depends_algorithm = "first-only";
> 
> does this mean this bug is fixed now?

Depends on how "alternatives" is implemented. I haven't checked.

L.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Tue, 28 Apr 2009 12:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sylvestre Ledru <sylvestre.ledru@inria.fr>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Tue, 28 Apr 2009 12:06:03 GMT) Full text and rfc822 format available.

Message #33 received at 403246@bugs.debian.org (full text, mbox):

From: Sylvestre Ledru <sylvestre.ledru@inria.fr>
To: 403246@bugs.debian.org
Subject: Still occurs
Date: Tue, 28 Apr 2009 14:03:10 +0200
Hello,

Just a quick update to confirm that this bug still exists. See: #525935

Sylvestre






Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Tue, 28 Apr 2009 12:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Tue, 28 Apr 2009 12:27:06 GMT) Full text and rfc822 format available.

Message #38 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Sylvestre Ledru <sylvestre.ledru@inria.fr>, 403246@bugs.debian.org, 525935@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: Still occurs
Date: Tue, 28 Apr 2009 13:24:26 +0100
On Tue, Apr 28, 2009 at 02:03:10PM +0200, Sylvestre Ledru wrote:

> Just a quick update to confirm that this bug still exists. See: #525935

Thanks.  We still haven't yet had any proposed patches to the
dependency resolver to correctly support alternative build dependencies.
Currently support is extremely poor.  This is partly because the
whole idea of alternative build-deps would result in non-deterministic
builds.

In the case of #525935 the fact that the first build-dep is nonexistent
will cause problems, and is in itself wrong.  You should ensure that
the first build-dep is valid.

This should be fixed, but unless someone actually works on it and
submits patches, it's not a top priority to fix, partly due to the
complexity.  We are considering implementing alternative dependency
resolvers in order to fix the problem, including using a mechanism
of a "dependency package" like pbuilder uses so that we use the
apt-get or aptitude dependency resolver directly rather than
implementing our own.

The dependency package is very easy to generate; just a few lines of
code.  However, I don't yet know of an easy method of robustly
triggering package installation and removal or of reversing the
process.  One can use dpkg --(get|set)-selections to save/restore
the packages, but I'm not sure how to synch the real package status
to this state reliably (reinstalling missing packages and purging
installed build-deps).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Tue, 28 Apr 2009 14:09:08 GMT) Full text and rfc822 format available.

Message #41 received at 403246@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Roger Leigh <rleigh@codelibre.net>, 403246@bugs.debian.org
Cc: Sylvestre Ledru <sylvestre.ledru@inria.fr>, 525935@bugs.debian.org
Subject: Re: Bug#403246: [buildd-tools-devel] Bug#403246: Still occurs
Date: Tue, 28 Apr 2009 16:05:09 +0200
On Tue, Apr 28, 2009 at 01:24:26PM +0100, Roger Leigh wrote:
> On Tue, Apr 28, 2009 at 02:03:10PM +0200, Sylvestre Ledru wrote:
> 
> > Just a quick update to confirm that this bug still exists. See: #525935
> 
> Thanks.  We still haven't yet had any proposed patches to the
> dependency resolver to correctly support alternative build dependencies.
> Currently support is extremely poor.  This is partly because the
> whole idea of alternative build-deps would result in non-deterministic
> builds.

Perhaps a solution would be for packages to specify two Build-Depends fields:

 A- One that defines which dependencies are essential for build to work

 B- One that defines which dependencies are expected to be present in
    official builds

Then maintainers and buildds must satisfy B, while backporters can satisfy
A and try to satisfy as much as possible from B.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Tue, 28 Apr 2009 14:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Tue, 28 Apr 2009 14:42:02 GMT) Full text and rfc822 format available.

Message #46 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Robert Millan <rmh@aybabtu.com>
Cc: 403246@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, 525935@bugs.debian.org
Subject: Re: Bug#403246: [buildd-tools-devel] Bug#403246: Still occurs
Date: Tue, 28 Apr 2009 15:38:42 +0100
On Tue, Apr 28, 2009 at 04:05:09PM +0200, Robert Millan wrote:
> On Tue, Apr 28, 2009 at 01:24:26PM +0100, Roger Leigh wrote:
> > On Tue, Apr 28, 2009 at 02:03:10PM +0200, Sylvestre Ledru wrote:
> > 
> > > Just a quick update to confirm that this bug still exists. See: #525935
> > 
> > Thanks.  We still haven't yet had any proposed patches to the
> > dependency resolver to correctly support alternative build dependencies.
> > Currently support is extremely poor.  This is partly because the
> > whole idea of alternative build-deps would result in non-deterministic
> > builds.
> 
> Perhaps a solution would be for packages to specify two Build-Depends fields:
> 
>  A- One that defines which dependencies are essential for build to work
> 
>  B- One that defines which dependencies are expected to be present in
>     official builds
> 
> Then maintainers and buildds must satisfy B, while backporters can satisfy
> A and try to satisfy as much as possible from B.

I'm not sure that a separate type of Build-Depends field in the control
file is necessary.  Surely a build dependency is required or not required;
there isn't really a case in between where it /might/ be required, is
there?  (Excluding arch-specific, which is already catered for.)

Should backporters not simply alter the build-depends to be correct
in the backport environment, and/or backport any needed dependencies
if they can't be satisfied by older packages?

I, for example, keep separate debian and debian-backports branches
in a VCS so that such deviations can be easily tracked.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Tue, 28 Apr 2009 16:12:04 GMT) Full text and rfc822 format available.

Message #49 received at 403246@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 403246@bugs.debian.org, Sylvestre Ledru <sylvestre.ledru@inria.fr>, 525935@bugs.debian.org
Subject: Re: Bug#403246: [buildd-tools-devel] Bug#403246: Still occurs
Date: Tue, 28 Apr 2009 17:26:51 +0200
On Tue, Apr 28, 2009 at 03:38:42PM +0100, Roger Leigh wrote:
> I'm not sure that a separate type of Build-Depends field in the control
> file is necessary.  Surely a build dependency is required or not required;
> there isn't really a case in between where it /might/ be required, is
> there?  (Excluding arch-specific, which is already catered for.)

Yes.  It's very common;  imagine program "foo" whose configure script
checks for "libbar".  When "libbar" is found, it will enable features that
depend on it.  However, "libbar" is only available in sid and not in
stable.

> Should backporters not simply alter the build-depends to be correct
> in the backport environment, and/or backport any needed dependencies
> if they can't be satisfied by older packages?

Backporters can do that, but it means more work.  If this problem was
solved, most backports could be maintained automatically.

> I, for example, keep separate debian and debian-backports branches
> in a VCS so that such deviations can be easily tracked.

It's going to be a branch either way;  the difference is between branching
the whole thing or just a line in debian/control.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Sun, 20 Sep 2009 16:33:33 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Yu <jawnsy@cpan.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Sun, 20 Sep 2009 16:33:33 GMT) Full text and rfc822 format available.

Message #54 received at 403246@bugs.debian.org (full text, mbox):

From: Jonathan Yu <jawnsy@cpan.org>
To: 403246@bugs.debian.org
Subject: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Sun, 20 Sep 2009 12:28:24 -0400
Using the newest version of sbuild in sid, I'm still having this issue.

I have read the discussion from the bug report log, but would like to
add this bit of an argument as to why alternative dependencies are
useful, and why sbuild should be able to resolve them.

Consider the case of Dual-Life modules in Perl. These are modules that
are released both in the Perl core, and released separately as a
standalone package. This strategy makes it possible to use core
modules with older versions of Perl.

Recently I came across this with the Test::Simple package, which
includes Test::More. Perl version 5.10.1 has updated this
(http://search.cpan.org/~dapm/perl-5.10.1/pod/perl5101delta.pod#Updated_Modules):

Test::Simple
    Upgraded from version 0.72 to 0.92.

I was upgrading a package that requires Test::Simple >= 0.80. This
means it can be satisfied either by:
 perl-modules (>= 5.10.1)
OR
 libtest-simple-perl (>= 0.80)

Without alternative dependencies, one's only choice would be to
upgrade libtest-simple-perl, or install it despite it being made
unnecessary by its inclusion as a core module (ie, installing it even
though it is already installed as part of perl-modules).

I still haven't figured out what can be done about this. I suppose for
now the only way to make it build at all is to use:
 libtest-simple-perl (>= 0.80)
as a dependency.

Build-Depends-Indep: libperl-minimumversion-perl,
libtest-minimumversion-perl, libpod-simple-perl (>= 3.07),
libtest-pod-perl (>= 1.26), libtest-cpan-meta-perl,
libtest-script-perl (>= 1.05), perl-modules (>= 5.10.1) |
libtest-simple-perl (>= 0.80)

perl-modules: non-matching version installed (5.10.0-25 ! >= 5.10.1)
Default version of perl-modules not sufficient, no suitable
alternative found. I probably should dep-wait this one.
Package installation not possible




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Sun, 20 Sep 2009 17:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Sun, 20 Sep 2009 17:12:03 GMT) Full text and rfc822 format available.

Message #59 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Jonathan Yu <jawnsy@cpan.org>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Sun, 20 Sep 2009 18:09:56 +0100
On Sun, Sep 20, 2009 at 12:28:24PM -0400, Jonathan Yu wrote:
> Using the newest version of sbuild in sid, I'm still having this issue.
> 
> I have read the discussion from the bug report log, but would like to
> add this bit of an argument as to why alternative dependencies are
> useful, and why sbuild should be able to resolve them.

As I mentioned earlier in this bug, the main problem isn't convincing
us why they are needed, it's the lack of any patches to address this
shortcoming in sbuild.  More than anything else, we need someone to do
the work to implement resolving of alternative build deps.

If you have the time to look into it, a patch implementing alternative
build-dep installation would be very much appreciated.

The current sbuild code now has the ability to select alternative
build dependency algorithms (so as to no affect backward compatibility
and allow such experimentation), so it should be reasonably
straightfoward to add an additional algorithm.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Sun, 20 Sep 2009 18:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andres Mejia <mcitadel@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Sun, 20 Sep 2009 18:15:03 GMT) Full text and rfc822 format available.

Message #64 received at 403246@bugs.debian.org (full text, mbox):

From: Andres Mejia <mcitadel@gmail.com>
To: 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: Bug#403246: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Sun, 20 Sep 2009 13:53:06 -0400
On Sunday 20 September 2009 13:09:56 Roger Leigh wrote:
> On Sun, Sep 20, 2009 at 12:28:24PM -0400, Jonathan Yu wrote:
> > Using the newest version of sbuild in sid, I'm still having this issue.
> >
> > I have read the discussion from the bug report log, but would like to
> > add this bit of an argument as to why alternative dependencies are
> > useful, and why sbuild should be able to resolve them.
> 
> As I mentioned earlier in this bug, the main problem isn't convincing
> us why they are needed, it's the lack of any patches to address this
> shortcoming in sbuild.  More than anything else, we need someone to do
> the work to implement resolving of alternative build deps.
> 
> If you have the time to look into it, a patch implementing alternative
> build-dep installation would be very much appreciated.
> 
> The current sbuild code now has the ability to select alternative
> build dependency algorithms (so as to no affect backward compatibility
> and allow such experimentation), so it should be reasonably
> straightfoward to add an additional algorithm.
> 
> 
> Thanks,
> Roger
> 

Maybe this bug should be tagged 'help' then. I'll probably look into this as I 
have maintained packages before where I had alternative build dependencies.

-- 
Regards,
Andres




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Mon, 21 Sep 2009 21:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andres Mejia <mcitadel@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Mon, 21 Sep 2009 21:51:03 GMT) Full text and rfc822 format available.

Message #69 received at 403246@bugs.debian.org (full text, mbox):

From: Andres Mejia <mcitadel@gmail.com>
To: 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: Bug#403246: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Mon, 21 Sep 2009 17:46:25 -0400
I think I may have found the problem. Seems that
Sbuild::Build::filter_dependencies in most cases will only choose the first
package out of a list of alternatives, and ignore the rest as possible
packages that could be installed.

One thing that could be done is modify Sbuild::Build::run_apt to test if a
package is installable. Then Sbuild::Build::filter_dependencies could run the
run_apt() subroutine to check if a package is installable before declaring it
as such.

This of course has a performance penalty, since it means running apt-get
multiple times dependending on how many build dependencies a source package
may have. I think a much simpler and faster solution in the end would be to
take advantage of apt-get to resolve build dependencies.

It's been mentioned that a "dependency package" could be used to resolve build
dependencies. I have another proposal that involves using apt-get to read off
from a "Sources" file in a location that we could point to via a "deb-src"
line.

Here's what I propose. First we write our own "Sources" file somewhere, say a
temporary directory. Our "Sources" file would look something like this.

    Package: sbuild-dependencies-resolver
    Binary: sbuild-dependencies-resolver
    Version: 0.invalid.0
    Priority: extra
    Section: utils
    Maintainer: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
    Build-Depends: libgl1-mesa-dev
    Build-Depends-Indep: debhelper (>> 4.1)
    Build-Conflicts: nvidia-glx-dev
    Build-Conflicts-Indep: cdbs
    Architecture: all
    Standards-Version: 0.0.0
    Format: 1.0
    Directory: .
    Files:
     00000000000000000000000000000000 0 sbuild-dependencies-resolver_0.invalid.0.dsc
     00000000000000000000000000000000 0 sbuild-dependencies-resolver_0.invalid.0.tar.gz

The only fields that would vary here are the Build-* fields. Here we can include
any of the Build-* fields as necessary and copy them straight from the .dsc file
of a package. Some entries as you can see are bogus anyway, and the files don't
have to be in the location as mentioned in this "Sources" entry.

Next would be to add a "deb-src" line, perhaps in a new .list file in
/etc/apt/sources.list.d. It should look something like this.

    deb-src file://$temp_dir ./

Afterwards, all that would be needed to install the proper build-dependencies
is to run 'apt-get update' again and then run
'apt-get build-dep sbuild-dependencies-resolver'.

What still needs to be resolved would be how to reliably purge the newly
installed packages. Perhaps the packages that are newly installed should be
recorded out of the output from apt-get when installing the build
dependencies. This entry from the output could be used.

    The following NEW packages will be installed:
      package_1 package_2 ...
      ...

Then that list of packages could be later purged after the build is done using
'apt-get purge @list'.

One possible regression here would be support for architecture wildcards, if
we go with this proposal. See bug #547724.

-- 
Regards,
Andres




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Sun, 28 Feb 2010 07:54:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andres Mejia <mcitadel@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Sun, 28 Feb 2010 07:54:17 GMT) Full text and rfc822 format available.

Message #74 received at 403246@bugs.debian.org (full text, mbox):

From: Andres Mejia <mcitadel@gmail.com>
To: 403246@bugs.debian.org
Subject: [PATCH] sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Sun, 28 Feb 2010 02:28:59 -0500
[Message part 1 (text/plain, inline)]
Here's a patch that would partially fix this bug. I say partially because this 
only works if $apt_policy is left with it's default value of 1.

I've run into an issue in trying to work out something that could work without 
apt-get.

-- 
Regards,
Andres
[0001-Fix-internal-build-dep-satisfier-for-A-B-build-dep-a.patch (text/x-patch, attachment)]

Added tag(s) patch. Request was from Andres Mejia <mcitadel@gmail.com> to control@bugs.debian.org. (Sun, 28 Feb 2010 08:00:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 03 Mar 2010 23:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 03 Mar 2010 23:57:03 GMT) Full text and rfc822 format available.

Message #81 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Andres Mejia <mcitadel@gmail.com>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: [PATCH] sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Wed, 3 Mar 2010 23:56:14 +0000
[Message part 1 (text/plain, inline)]
On Sun, Feb 28, 2010 at 02:28:59AM -0500, Andres Mejia wrote:
> Here's a patch that would partially fix this bug. I say partially because this 
> only works if $apt_policy is left with it's default value of 1.
> 
> I've run into an issue in trying to work out something that could work without 
> apt-get.

Sorry for the delay in replying to all your recent patch mails.
Hopefully I'll get time to properly review them soon.

Regarding the debuild work, I've rebased the debuild branch
against current master, and put it at
git://git.debian.org/git/users/rleigh/sbuild
in the 'debuild-am2' branch.  There are some other patches
of mine also caught up in the rebasing which probably shouldn't
be in there.  I'll take a better look at this when I have a free
few hours.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Fri, 25 Jun 2010 20:54:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bernd Zeimetz <bernd@bzed.de>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Fri, 25 Jun 2010 20:54:07 GMT) Full text and rfc822 format available.

Message #86 received at 403246@bugs.debian.org (full text, mbox):

From: Bernd Zeimetz <bernd@bzed.de>
To: 403246@bugs.debian.org
Subject: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Fri, 25 Jun 2010 22:51:05 +0200
Hi,

are there any news on this bug? I've been hit by it today again, which is really
anoying as I have to build and use atlas now instead of the small libblas as it
is not possible for me to build-conflict on A and build-depend on B in this case.

Please fix it soon!

Thanks,

Bernd
-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Fri, 25 Jun 2010 21:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Fri, 25 Jun 2010 21:51:05 GMT) Full text and rfc822 format available.

Message #91 received at 403246@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Bernd Zeimetz <bernd@bzed.de>, 403246@bugs.debian.org
Subject: Re: Bug#403246: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Fri, 25 Jun 2010 23:49:48 +0200
On Fri, Jun 25, 2010 at 10:51:05PM +0200, Bernd Zeimetz wrote:
> Hi,
> 
> are there any news on this bug? I've been hit by it today again, which is really
> anoying as I have to build and use atlas now instead of the small libblas as it
> is not possible for me to build-conflict on A and build-depend on B in this case.

I'm not sure what you're trying to do here.  If you think it
should get build with A on the buildds, you should use A | B.
If you think B should be used, you should use B | A.

This makes sure that you actually get reproducible behaviour and
that the buildd doesn't pick A or B randomly.


Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Fri, 25 Jun 2010 22:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bernd Zeimetz <bernd@bzed.de>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Fri, 25 Jun 2010 22:18:03 GMT) Full text and rfc822 format available.

Message #96 received at 403246@bugs.debian.org (full text, mbox):

From: Bernd Zeimetz <bernd@bzed.de>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: 403246@bugs.debian.org
Subject: Re: Bug#403246: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Sat, 26 Jun 2010 00:14:31 +0200
On 06/25/2010 11:49 PM, Kurt Roeckx wrote:
> On Fri, Jun 25, 2010 at 10:51:05PM +0200, Bernd Zeimetz wrote:
>> Hi,
>>
>> are there any news on this bug? I've been hit by it today again, which is really
>> anoying as I have to build and use atlas now instead of the small libblas as it
>> is not possible for me to build-conflict on A and build-depend on B in this case.
> 
> I'm not sure what you're trying to do here.  If you think it
> should get build with A on the buildds, you should use A | B.
> If you think B should be used, you should use B | A.
> 
> This makes sure that you actually get reproducible behaviour and
> that the buildd doesn't pick A or B randomly.

No, you understood me wrong.
I build-depend on liblapack-dev, which depends on
  libatlas-base-dev | libblas-dev | libblas-3gf.so
But I want to avoid to build with libatlas-base-dev as libblas-dev is more than
enough in this case (and I need to build-depend on it anyway).
So it should be safe to build-conflict against libatlas-base-dev as all
dependencies are solved - this works well in pbuilder, but sbuild still fails to
solve that.

Hope that explains it better.

Bernd

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Fri, 25 Jun 2010 22:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Fri, 25 Jun 2010 22:33:03 GMT) Full text and rfc822 format available.

Message #101 received at 403246@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Bernd Zeimetz <bernd@bzed.de>, 403246@bugs.debian.org
Subject: Re: Bug#403246: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Sat, 26 Jun 2010 00:31:28 +0200
On Sat, Jun 26, 2010 at 12:14:31AM +0200, Bernd Zeimetz wrote:
> On 06/25/2010 11:49 PM, Kurt Roeckx wrote:
> > On Fri, Jun 25, 2010 at 10:51:05PM +0200, Bernd Zeimetz wrote:
> >> Hi,
> >>
> >> are there any news on this bug? I've been hit by it today again, which is really
> >> anoying as I have to build and use atlas now instead of the small libblas as it
> >> is not possible for me to build-conflict on A and build-depend on B in this case.
> > 
> > I'm not sure what you're trying to do here.  If you think it
> > should get build with A on the buildds, you should use A | B.
> > If you think B should be used, you should use B | A.
> > 
> > This makes sure that you actually get reproducible behaviour and
> > that the buildd doesn't pick A or B randomly.
> 
> No, you understood me wrong.
> I build-depend on liblapack-dev, which depends on
>   libatlas-base-dev | libblas-dev | libblas-3gf.so
> But I want to avoid to build with libatlas-base-dev as libblas-dev is more than
> enough in this case (and I need to build-depend on it anyway).
> So it should be safe to build-conflict against libatlas-base-dev as all
> dependencies are solved - this works well in pbuilder, but sbuild still fails to
> solve that.

build-conflict and sbuild never really work as intended, and
that's one of the more annoying things.

Did you try adding libblas-dev in the depends list before
liblapack-dev?


Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Fri, 25 Jun 2010 22:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bernd Zeimetz <bernd@bzed.de>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Fri, 25 Jun 2010 22:51:06 GMT) Full text and rfc822 format available.

Message #106 received at 403246@bugs.debian.org (full text, mbox):

From: Bernd Zeimetz <bernd@bzed.de>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: 403246@bugs.debian.org
Subject: Re: Bug#403246: sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Sat, 26 Jun 2010 00:47:13 +0200
On 06/26/2010 12:31 AM, Kurt Roeckx wrote:
> build-conflict and sbuild never really work as intended, and
> that's one of the more annoying things.
> 
> Did you try adding libblas-dev in the depends list before
> liblapack-dev?

Not yet, will give it a try.

Thanks!

Bernd

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 18 Aug 2010 13:24:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bhavani Shankar R <bhavi@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 18 Aug 2010 13:24:13 GMT) Full text and rfc822 format available.

Message #111 received at 403246@bugs.debian.org (full text, mbox):

From: Bhavani Shankar R <bhavi@ubuntu.com>
To: 403246@bugs.debian.org
Subject: Re: dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Wed, 18 Aug 2010 18:53:44 +0530
Hello all

If I have not mistaken this bug on LP has similar symptoms

https://edge.launchpad.net/bugs/619753

Please do correct me if m wrong

regards

-- 

Bhavani Shankar.R
https://launchpad.net/~bhavi, a proud ubuntu community  member.
What matters in life is application of mind!,
It makes great sense to have some common sense..!




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 03 Nov 2010 16:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 03 Nov 2010 16:39:03 GMT) Full text and rfc822 format available.

Message #116 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Bhavani Shankar R <bhavi@ubuntu.com>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: dependancy resolution fails when b-dep on A | B ; A uninstallable
Date: Wed, 3 Nov 2010 16:36:25 +0000
[Message part 1 (text/plain, inline)]
tags 403246 + fixed-upstream pending
thanks

On Wed, Aug 18, 2010 at 06:53:44PM +0530, Bhavani Shankar R wrote:
> Hello all
> 
> If I have not mistaken this bug on LP has similar symptoms
> 
> https://edge.launchpad.net/bugs/619753
> 
> Please do correct me if m wrong

This does look the same.

It's fixed by switching to the 'aptitude' dependency resolver
instead of the 'internal' resolver, since it's far more capable
and can resolve complex depdendencies, including virtual and
alternative dependencies.

If you try sbuild 0.60.2-1, it should work just fine.  0.60.3-1
should be out this weekend, and that will hopefully switch to
using the aptitude resolver by default.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending and fixed-upstream. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Wed, 03 Nov 2010 16:39:12 GMT) Full text and rfc822 format available.

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Sun, 07 Nov 2010 23:03:09 GMT) Full text and rfc822 format available.

Notification sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Bug acknowledged by developer. (Sun, 07 Nov 2010 23:03:09 GMT) Full text and rfc822 format available.

Message #123 received at 403246-close@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@debian.org>
To: 403246-close@bugs.debian.org
Subject: Bug#403246: fixed in sbuild 0.60.3-1
Date: Sun, 07 Nov 2010 23:02:22 +0000
Source: sbuild
Source-Version: 0.60.3-1

We believe that the bug you reported is fixed in the latest version of
sbuild, which is due to be installed in the Debian FTP archive:

buildd_0.60.3-1_all.deb
  to main/s/sbuild/buildd_0.60.3-1_all.deb
libsbuild-perl_0.60.3-1_all.deb
  to main/s/sbuild/libsbuild-perl_0.60.3-1_all.deb
sbuild_0.60.3-1.diff.gz
  to main/s/sbuild/sbuild_0.60.3-1.diff.gz
sbuild_0.60.3-1.dsc
  to main/s/sbuild/sbuild_0.60.3-1.dsc
sbuild_0.60.3-1_all.deb
  to main/s/sbuild/sbuild_0.60.3-1_all.deb
sbuild_0.60.3.orig.tar.gz
  to main/s/sbuild/sbuild_0.60.3.orig.tar.gz
wanna-build_0.60.3-1_all.deb
  to main/s/sbuild/wanna-build_0.60.3-1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 403246@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated sbuild package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Format: 1.8
Date: Sun, 07 Nov 2010 22:33:15 +0000
Source: sbuild
Binary: libsbuild-perl sbuild wanna-build buildd
Architecture: source all
Version: 0.60.3-1
Distribution: unstable
Urgency: low
Maintainer: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 buildd     - Daemon for automatically building Debian binary packages from Deb
 libsbuild-perl - Tool for building Debian binary packages from Debian sources
 sbuild     - Tool for building Debian binary packages from Debian sources
 wanna-build - Database to track building of Debian binary packages from Debian
Closes: 403246 464376 545215 551311 567505 602318
Changes: 
 sbuild (0.60.3-1) unstable; urgency=low
 .
   * New release.
   * sbuild-createchroot:
     - Allow direct creation of tarballs from chroots, with various
       options for compression (Closes: #545215).  Thanks to Andres
       Mejia.
   * sbuild-update:
     - sbuild-clean functionality has been merged into sbuild-update.
       Thanks to Andres Mejia.
   * sbuild:
     - Dependency resolving:
       . 'aptitude' is now the default dependency resolver.  Users
         wishing to use the old resolver should set
         $build_dep_resolver='internal' in their configuration.
       . The aptitude resolver can resolve complex dependencies.
         A | B, where A is uninstallable now correctly falls back to B
         (Closes: #403246).
       . Removal of Build-Conflicts now works, due to using apt-get
         or aptitude to perform the removal (Closes: #464376).
       . Default to not enabling virtual dependency resolving with the
         internal resolver ($resolve_virtual=0).  This is to avoid
         changing the historical behaviour by default.
     - Don't set Sbuild::debug_level to undef (Closes: #602318).
       Thanks to Andres Mejia.
     - Add debuild-like feature to run sbuild on an unpacked source
       tree (Closes: #551311).  In addition to specifying a package
       version to build, or a source package .dsc, a directory may be
       used.  This will be packaged with 'dpkg-source -b' prior to
       building.  Thanks to Andres Mejia.
     - Add support for running lintian after a build.  Thanks to Andres
       Mejia.
     - Add support for running external commands before and after a
       build, and during chroot setup and cleanup.  These may be used
       to run piuparts, for example.  Thanks to Andres Mejia.
   * Run sbuild-* chroot maintenance commands in the 'source' chroot
     namespace for chroots providing such a facility (Closes: #567505).
     This means that update/distupgrade etc. operations will occur in
     the source volume for lvm-snapshot and btrfs-snapshot chroot types.
     Note that the sbuild chroot lock (/var/lock/sbuild) may be copied
     into cloned chroots if a build is started during a maintenance
     operation and the build will block until the operation is completed.
   *
Checksums-Sha1: 
 9dfbcb2336ed41707edf690227efc9a626681813 1265 sbuild_0.60.3-1.dsc
 6c7429c90b9185f47a99c1ddf61a0c322213b28c 513163 sbuild_0.60.3.orig.tar.gz
 a0fddd5458378c1bf3c10dd2f5c060d1347741ed 20 sbuild_0.60.3-1.diff.gz
 bea75924264d393ae927fc6389178ef3bf22c5b0 230434 libsbuild-perl_0.60.3-1_all.deb
 3afcb5fe9edaa351ad758eccddd6297e8a3c2197 236854 sbuild_0.60.3-1_all.deb
 5105f35faf433811b48b787ccf631ac90c8c6412 236642 wanna-build_0.60.3-1_all.deb
 7fbcdc416075f837ee54e1af379619638ae13491 227400 buildd_0.60.3-1_all.deb
Checksums-Sha256: 
 776fe3b4a8b1da0fdd27b788fe7c5f4f81d3045df7a99f70bd531c97307fa57e 1265 sbuild_0.60.3-1.dsc
 2ad5d39ad249cbc49845c448e918831fcb6d98f0ffe503cffb3ddd0ee20bbc96 513163 sbuild_0.60.3.orig.tar.gz
 f61f27bd17de546264aa58f40f3aafaac7021e0ef69c17f6b1b4cd7664a037ec 20 sbuild_0.60.3-1.diff.gz
 6c9ef423af46fe30cc2eb20946a6ea1028f528b16bfd44e3098b27d16e8a606d 230434 libsbuild-perl_0.60.3-1_all.deb
 22faf34f1a29c0fc55fd8fedb16783185545998634063d35b46f86eb07737d71 236854 sbuild_0.60.3-1_all.deb
 f7ccc80afff9263dd46bc1b532c8d82cce36d5f34899182659980c8e0a3bd7b5 236642 wanna-build_0.60.3-1_all.deb
 ead02f9391bb2bc85bc6c1e2dd25eb038ab721fd657c5b61cf1601d24f85d95c 227400 buildd_0.60.3-1_all.deb
Files: 
 faaeab70c8298a26c8a78e9185ae4b83 1265 devel extra sbuild_0.60.3-1.dsc
 6ff10d8049a8ed32cbf5bb0e26f72e7d 513163 devel extra sbuild_0.60.3.orig.tar.gz
 4a4dd3598707603b3f76a2378a4504aa 20 devel extra sbuild_0.60.3-1.diff.gz
 149a151991f9ef75a50359a5f80fc8fd 230434 perl extra libsbuild-perl_0.60.3-1_all.deb
 d8aeefeb6930f05af9fe853b9d6b896f 236854 devel extra sbuild_0.60.3-1_all.deb
 dcba9be380029390f1abb5830a06786b 236642 devel extra wanna-build_0.60.3-1_all.deb
 9cd182acfaf0b2324c49d96199a19bf6 227400 devel extra buildd_0.60.3-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAkzXLfQACgkQVcFcaSW/uEjiMACgpqyJJKX4FyxNR0PWtmWLcjss
MnEAnRSLtXRmSP8zRYkP1jt3E7TIQnaz
=Juaw
-----END PGP SIGNATURE-----





Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Mon, 14 Feb 2011 22:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bernd Zeimetz <bernd@bzed.de>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Mon, 14 Feb 2011 22:15:03 GMT) Full text and rfc822 format available.

Message #128 received at 403246@bugs.debian.org (full text, mbox):

From: Bernd Zeimetz <bernd@bzed.de>
To: 403246@bugs.debian.org, control@bugs.debian.org
Subject: #403246 not fixed as solution not used on buildds
Date: Mon, 14 Feb 2011 23:13:03 +0100
reopen 403246
thanks

Unfortunately the solution for #403246 is not enough as the aptitude resolver is
not used on buildds. Please implement a proper dependency solution in the
traditional solver.

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F




Bug No longer marked as fixed in versions sbuild/0.60.3-1 and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 14 Feb 2011 22:15:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Mon, 14 Feb 2011 22:30:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Mon, 14 Feb 2011 22:30:07 GMT) Full text and rfc822 format available.

Message #135 received at 403246@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: Bernd Zeimetz <bernd@bzed.de>, 403246@bugs.debian.org
Subject: Re: Bug#403246: #403246 not fixed as solution not used on buildds
Date: Mon, 14 Feb 2011 23:28:24 +0100
On Mon, Feb 14, 2011 at 11:13:03PM +0100, Bernd Zeimetz wrote:
> reopen 403246
> thanks
> 
> Unfortunately the solution for #403246 is not enough as the aptitude resolver is
> not used on buildds. Please implement a proper dependency solution in the
> traditional solver.

Please atleast discuss this on debian-devel before changing this.


Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Mon, 14 Feb 2011 23:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Mon, 14 Feb 2011 23:06:03 GMT) Full text and rfc822 format available.

Message #140 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Bernd Zeimetz <bernd@bzed.de>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: #403246 not fixed as solution not used on buildds
Date: Mon, 14 Feb 2011 23:04:45 +0000
[Message part 1 (text/plain, inline)]
On Mon, Feb 14, 2011 at 11:13:03PM +0100, Bernd Zeimetz wrote:
> 
> Unfortunately the solution for #403246 is not enough as the aptitude resolver
> is not used on buildds. Please implement a proper dependency solution in the
> traditional solver.

I'm sorry, but this is not a possible solution.

The traditional "internal" resolver will never have proper dependency
resolution WRT alternative build deps.  It's unmaintainable, fragile,
non-understandable perl.  That's the reason why the bug was not fixed
for over five years, and existed since forever.  No one has the time
or skills and understanding to add the needed functionality without
breaking it in some subtle way.  Any change could result in breakage
and cripple the buildds.

What we can do is push for the internal resolver to be replaced on the
buildds with the "apt" or "aptitude" resolvers.  The "apt" resolver is
probably a more predictable and reliable solution at this point.  The
aptitude resolver was completed in a few weeks, and the following apt
resolver in a couple of days.  That's why they are the future: they
are simple and delegate all the dependency resolving to the tools that
do the job properly.  They have had months of testing (aptitude for
nearly a year, apt a few months), and are doing an excellent job so
far.

The main sticking point to making this move is concrete testing of
the resolver behaviour for a large number of packages.  Comparison
of the difference in resolver behaviour for a large number of
packages is needed in order to determine if it is safe to switch.
A whole archive rebuild of squeeze would be even better.

While I'm not unwilling to accept patches to the internal resolver,
they would require the same amount of testing as the apt or
aptitude resolvers in order to ensure their correctness.  In
consequence, there's really no reason not to switch to a better
resolver.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 16 Feb 2011 10:15:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 16 Feb 2011 10:15:09 GMT) Full text and rfc822 format available.

Message #145 received at 403246@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@debian.org>
To: 403246@bugs.debian.org
Subject: sbuild’s shortcomings
Date: Wed, 16 Feb 2011 11:03:15 +0100 (CET)
Hi,

why not “just” write something that walks like an sbuild,
quacks like an sbuild, and calls cowbuilder?

This would solve all the problems with tearing down pak-
kage installation etc.

… except #363193 (I think pbuilder too needs some love,
or team maintenance).

bye,
//mirabilos, who built “all” of m68k with cowbuilder
-- 
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 16 Feb 2011 10:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 16 Feb 2011 10:48:03 GMT) Full text and rfc822 format available.

Message #150 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Thorsten Glaser <tg@debian.org>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: sbuild’s shortcomings
Date: Wed, 16 Feb 2011 10:44:57 +0000
[Message part 1 (text/plain, inline)]
On Wed, Feb 16, 2011 at 11:03:15AM +0100, Thorsten Glaser wrote:
> why not “just” write something that walks like an sbuild,
> quacks like an sbuild, and calls cowbuilder?
> 
> This would solve all the problems with tearing down pak-
> kage installation etc.
> 
> … except #363193 (I think pbuilder too needs some love,
> or team maintenance).

cowbuilder has one major flaw: the copy-on-write is implemented by
LD_PRELOAD, as a shared library copied from the host system.  This
precludes the build environment from having a glibc incompatible with
the host, since it would break the copy-on-write functionality.
Additionally, the LD_PRELOAD symbol coverage may become outdated as
glibc adds new symbols, resulting in some actions overwriting the base
environment.  Example: the new openat/mkdirat variants of the basic
system calls.  These also need preloading.  And it will break every
time a new symbol needing preloading is added.

I did look at it in detail a year or so back, but it's really too
fragile to use long-term.  It's not that it doesn't work, it's that
continued reliability is not guaranteed.

sbuild has the ability to host alternative architectures in the
chroot; currently 32/64 bit versions of the same arch e.g.
i386/amd64.  LD_PRELOAD would break here.  Soon, we will also
gain the ability (via schroot) of using qemu-$arch-static and
binfmt-misc to run binaries from any arbitrary arch inside the
chroot to do builds for non-native architectures; here we also
can't do copy-on-write.

sbuild itself relies entirely upon schroot to do its virtualisation.
cowbuilder-like support could potentially be added to schroot to give
sbuild this functinality, but it would require some refactoring of
schroot to permit this.  I can put it on my TODO list, but I'm afraid
it won't be a priority item.

The existing lvm-snapshot support is both fast and (bar kernel bugs)
completely reliable WRT data being genuinely copy-on-write.  We now
have btrfs snapshot support when is even quicker to create snapshots,
but currently performs badly with dpkg; hopefully this will be
addressed by dpkg now squeeze is out.  While these require setup by
the sysadmin, they both have the copy-on-write guarantees we need.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 16 Feb 2011 12:24:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 16 Feb 2011 12:24:06 GMT) Full text and rfc822 format available.

Message #155 received at 403246@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
Cc: 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: sbuild’s shortcomings
Date: Wed, 16 Feb 2011 12:18:57 +0000 (UTC)
Roger Leigh dixit:

>cowbuilder has one major flaw: the copy-on-write is implemented by
>LD_PRELOAD, as a shared library copied from the host system.  This
>precludes the build environment from having a glibc incompatible with
>the host, since it would break the copy-on-write functionality.

Interestingly, I don’t think that is true: cowbuilder installs
itself into the build chroot, and LD_PRELOAD after chroot(2)
uses the library from within (as it’s pathname based).

This is the reason that, when we want to use eatmydata, we have
to install it inside the base.cow as well, and that some pak-
kages spew out warnings about “can’t preload lib*.so” under
cowbuilder (kdepim3 is my example of today).

>sbuild has the ability to host alternative architectures in the

You can do that with cowbuilder.

bye,
//mirabilos
-- 
13:47⎜<tobiasu> if i were omnipotent, i would divide by zero
                all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Wed, 16 Feb 2011 19:09:03 GMT) Full text and rfc822 format available.

Message #158 received at 403246@bugs.debian.org (full text, mbox):

From: Philipp Kern <pkern@debian.org>
To: Thorsten Glaser <tg@mirbsd.de>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: Bug#403246: sbuild’s shortcomings
Date: Wed, 16 Feb 2011 20:04:33 +0100
[Message part 1 (text/plain, inline)]
On Wed, Feb 16, 2011 at 12:18:57PM +0000, Thorsten Glaser wrote:
> Roger Leigh dixit:
> >cowbuilder has one major flaw: the copy-on-write is implemented by
> >LD_PRELOAD, as a shared library copied from the host system.  This
> >precludes the build environment from having a glibc incompatible with
> >the host, since it would break the copy-on-write functionality.
> Interestingly, I don’t think that is true: cowbuilder installs
> itself into the build chroot, and LD_PRELOAD after chroot(2)
> uses the library from within (as it’s pathname based).

Yes, this *requires* cowbuilder/dancer in the chroot.  In the past they even
had to speak the same language, which they didn't, which then broke the whole
cowbuilding.

Furthermore I don't trust the whole library preloading from the chroot thing to
provide all the native semantics some testsuites might be relying on.  I.e. I'd
like so see a pbuilder and a cowbuilder rebuild of the same set of sources and
available build-dependencies first.

Kind regards
Philipp Kern
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Thu, 24 Feb 2011 19:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Thu, 24 Feb 2011 19:54:03 GMT) Full text and rfc822 format available.

Message #163 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Bernd Zeimetz <bernd@bzed.de>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: #403246 not fixed as solution not used on buildds
Date: Thu, 24 Feb 2011 19:51:40 +0000
[Message part 1 (text/plain, inline)]
On Mon, Feb 14, 2011 at 11:13:03PM +0100, Bernd Zeimetz wrote:
> Unfortunately the solution for #403246 is not enough as the aptitude resolver
> is not used on buildds. Please implement a proper dependency solution in the
> traditional solver.

Just to update you on what's happened:

- new release 0.61.0-1 adds the ability to disable (use first alternative
  only) or enable alternative build deps for the 'apt' and 'aptitude'
  resolvers.  It defaults to disabled; setting: $resolve_alternatives
- current git (0.61.1 prerelease) makes 'apt' the default resolver, and
  deprecates the old 'internal' resolver.
- I will shortly make $resolve_alternatives default to off for 'internal'
  and 'apt', and to on for 'aptitude'.  This will still be configurable,
  but will match the historical behaviour of all three resolvers.

We will hopefully soon switch to using 'apt' as the default resolver on
the buildds, because it is now identical to the internal resolver now it
uses first-only alternatives, and behaves identically.  Once all buildds
are using it, 'internal' will be obsoleted and subsequently deleted.

Following discussion on debian-devel and #debian-devel, the consensus
was to not allow alternative build dependencies when building for
unstable, due to the inconsistencies it can introduce to builds.  Note
that this does not include alternative architecture-specific
dependencies, which are allowed.  They will be allowed for experimental
with the aptitude resolver, and possibly backports.

So, in summary, the bug will be fixed, but it will in most cases not be
the default behaviour.  I think the solution we have ended up with is
about the best we can get, and if the default behaviour is not what you
want you will have the ability to alter it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Thu, 24 Feb 2011 22:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Thu, 24 Feb 2011 22:45:03 GMT) Full text and rfc822 format available.

Message #168 received at 403246@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Bernd Zeimetz <bernd@bzed.de>, 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: Bug#403246: #403246 not fixed as solution not used on buildds
Date: Thu, 24 Feb 2011 22:41:11 +0000
[Message part 1 (text/plain, inline)]
tags 403246 + fixed-upstream pending
thanks

On Thu, Feb 24, 2011 at 07:51:40PM +0000, Roger Leigh wrote:
> On Mon, Feb 14, 2011 at 11:13:03PM +0100, Bernd Zeimetz wrote:
> > Unfortunately the solution for #403246 is not enough as the aptitude resolver
> > is not used on buildds. Please implement a proper dependency solution in the
> > traditional solver.
> 
> Just to update you on what's happened:
> 
> - new release 0.61.0-1 adds the ability to disable (use first alternative
>   only) or enable alternative build deps for the 'apt' and 'aptitude'
>   resolvers.  It defaults to disabled; setting: $resolve_alternatives
> - current git (0.61.1 prerelease) makes 'apt' the default resolver, and
>   deprecates the old 'internal' resolver.
> - I will shortly make $resolve_alternatives default to off for 'internal'
>   and 'apt', and to on for 'aptitude'.  This will still be configurable,
>   but will match the historical behaviour of all three resolvers.
> 
> We will hopefully soon switch to using 'apt' as the default resolver on
> the buildds, because it is now identical to the internal resolver now it
> uses first-only alternatives, and behaves identically.  Once all buildds
> are using it, 'internal' will be obsoleted and subsequently deleted.
> 
> Following discussion on debian-devel and #debian-devel, the consensus
> was to not allow alternative build dependencies when building for
> unstable, due to the inconsistencies it can introduce to builds.  Note
> that this does not include alternative architecture-specific
> dependencies, which are allowed.  They will be allowed for experimental
> with the aptitude resolver, and possibly backports.
> 
> So, in summary, the bug will be fixed, but it will in most cases not be
> the default behaviour.  I think the solution we have ended up with is
> about the best we can get, and if the default behaviour is not what you
> want you will have the ability to alter it.

From NEWS for the next release:

* Major changes in 0.61.1:

  1) 'apt' is now the default build dependency resolver.  Users should
     not see any significant changes compared with the old 'internal'
     resolver.  Please note that you may need to generate a GPG key
     for the local archive created for dependency package
     installation, if one does not already exist; see sbuild-update
     (--keygen) for further details.

  2) The 'internal' build dependency resolver is deprecated.  It is
     not recommended for future use, and will be removed once it is no
     longer used by the buildd infrastructure.  Please use the 'apt'
     resolver as a drop-in replacement.

  3) The 'aptitude' build dependency resolver will, unlike 'apt' and
     'internal', consider alternative dependencies by default, rather
     than only using the first alternative.  This is intended to both
     preserve backward compatibility, and make the 'aptitude' resolver
     the preferred choice for more complex situations, such as
     building for experimental.

I will be closing the bug now the resolver changes are complete unless
anyone has any objections or further comments?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Thu, 24 Feb 2011 22:45:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#403246; Package sbuild. (Sun, 27 Feb 2011 14:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bernd Zeimetz <bernd@bzed.de>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Sun, 27 Feb 2011 14:33:02 GMT) Full text and rfc822 format available.

Message #175 received at 403246@bugs.debian.org (full text, mbox):

From: Bernd Zeimetz <bernd@bzed.de>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 403246@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#403246: Bug#403246: #403246 not fixed as solution not used on buildds
Date: Sun, 27 Feb 2011 15:28:46 +0100
On 02/24/2011 11:41 PM, Roger Leigh wrote:
> I will be closing the bug now the resolver changes are complete unless
> anyone has any objections or further comments?

No objections at all - thanks for your work!

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F




Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 16 Mar 2011 19:27:05 GMT) Full text and rfc822 format available.

Notification sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Bug acknowledged by developer. (Wed, 16 Mar 2011 19:27:05 GMT) Full text and rfc822 format available.

Message #180 received at 403246-close@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@debian.org>
To: 403246-close@bugs.debian.org
Subject: Bug#403246: fixed in sbuild 0.62.0-1
Date: Wed, 16 Mar 2011 19:24:34 +0000
Source: sbuild
Source-Version: 0.62.0-1

We believe that the bug you reported is fixed in the latest version of
sbuild, which is due to be installed in the Debian FTP archive:

buildd_0.62.0-1_all.deb
  to main/s/sbuild/buildd_0.62.0-1_all.deb
libsbuild-perl_0.62.0-1_all.deb
  to main/s/sbuild/libsbuild-perl_0.62.0-1_all.deb
sbuild_0.62.0-1.debian.tar.gz
  to main/s/sbuild/sbuild_0.62.0-1.debian.tar.gz
sbuild_0.62.0-1.dsc
  to main/s/sbuild/sbuild_0.62.0-1.dsc
sbuild_0.62.0-1_powerpc.deb
  to main/s/sbuild/sbuild_0.62.0-1_powerpc.deb
sbuild_0.62.0.orig.tar.gz
  to main/s/sbuild/sbuild_0.62.0.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 403246@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated sbuild package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Format: 1.8
Date: Wed, 16 Mar 2011 16:10:31 +0000
Source: sbuild
Binary: libsbuild-perl sbuild buildd
Architecture: source all powerpc
Version: 0.62.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 buildd     - Daemon for automatically building Debian binary packages from Deb
 libsbuild-perl - Tool for building Debian binary packages from Debian sources
 sbuild     - Tool for building Debian binary packages from Debian sources
Closes: 403246 576508 605763 609658 609932 610995
Changes: 
 sbuild (0.62.0-1) unstable; urgency=low
 .
   * New release.
   * debian/control:
     - Build-Depend upon libexception-class-perl.
   * sbuild:
     - Resolvers:
       + 'apt' is now the default build dependency resolver.  Users should
         not see any significant changes compared with the old 'internal'
         resolver.  Please note that you may need to generate a GPG key
         for the local archive created for dependency package
         installation, if one does not already exist; see sbuild-update
         (--keygen) for further details.
       + The 'internal' build dependency resolver is deprecated.  It is
         not recommended for future use, and will be removed once it is no
         longer used by the buildd infrastructure.  Please use the 'apt'
         resolver as a drop-in replacement.
       + The 'aptitude' build dependency resolver will, unlike 'apt' and
         'internal', consider alternative dependencies by default, rather
         than only using the first alternative.  This is intended to both
         preserve backward compatibility, and make the 'aptitude'
         resolver the preferred choice for more complex situations, such
         as building for experimental.
       + The aptitude resolver can resolve complex dependencies, e.g.
         A | B, where A is uninstallable now correctly falls back to B.
         This is not the case for the internal or apt resolvers, which by
         intent do not make use of alternatives (they use the first
         alternative only.  sbuild now has full support for resolving
         alternatives, but this is not the default behaviour
         (Closes: #403246).  Please see #614807 for a proposed description
         of autobuilder-imposed build dependency restrictions in Policy.
       + All build dependency resolvers run dpkg with --force-confold.
         This means packages with modified conffiles in the chroot to not
         cause build failure.  This includes /etc/services and
         /etc/protocols from netbase (Closes: #576508).
     - Logging:
       + Long paths such as the chroot location and the build directory
         inside the chroot are now filtered in the build log and replaced
         with small, constant, abbreviations (Closes: #605763).  This makes
         the build logs comparable between builds with tools such as
         diff(1).
       + Logging messages have been improved, and important messages are
         now coloured when running interactively (does not affect log
         files).  Errors, warnings and informational messages are coloured
         red, yellow and green, respectively.  Build status is coloured
         green for success and red for all failure conditions.
       + Build log mails are now compressed and mailed in MIME format by
         default, together with a copy of the .changes file.  The old
         behaviour (plain mailing of uncompressed logs) may be restored by
         setting $mime_build_log_mails=0 in the configuration, and
         compression may also be disabled in the MIME mails by setting
         $compress_build_log_mails=0.  Note that it is no longer possible
         to send compressed log mails unless MIME mailing is enabled.
         Thanks to Philipp Kern for implementing this.
     - Error handling:
       + In order to handle errors more robustly, the build code now has
         initial support for exception handling.  Normal operation will
         not be affected, but fatal errors may be logged in a different
         order than seen previously.  Fatal errors will now be seen at the
         end of the build log, which should make it easier to spot
         problems.
       + sbuild now always cleans up fully when receiving a termination
         signal such as SIGINT or SIGTERM.  Note that you may need to wait
         while the cleanup actions are performed, or the current task is
         completed prior to initiating cleanup.  When running
         interactively, hitting Ctrl-C will sent SIGINT to the entire
         process group; doing this while apt-get or aptitude are running
         will potentially leave dpkg in an inconsistent state, so aborting
         at this point is not recommended.  Sending a SIGTERM to the
         sbuild process will always work cleanly.
     - General:
       + sbuild now performs an apt dist-upgrade at the start of each
         build by default, rather than an upgrade.  This is to reduce the
         amount of manual administration required to keep chroots up to
         date, and is not much more risky than upgrade in this context.
       + A new option, --keep-session, has been added (Closes: #609658).
         This prevents the automatic removal of session-managed snapshot
         chroots.  Previously, snapshots would not be deleted if purging
         of the build directory or build dependencies was disabled, but
         this was not always desirable, hence it is now configurable
         separately.
       + Internally, building and other actions in the chroot are
         performed by the 'sbuild' system user, where previously the user
         invoking sbuild would be used instead.  The aim of this change is
         to separate privileges to increase security and reduce the chance
         of accidental or deliberate tampering of the build environment.
         While the latter is not addressed by these changes, this will be
         taken care of during future architectural changes.
       + The sbuild package build directory created inside the chroot now
         has a reduced name length.  It's now /build/packagename-XXXXXX
         where XXXXXX are random characters.  This helps reduce the chance
         of hitting path length restrictions on some architectures,
         particularly when using sockets.
   * wanna-build:
     - The wanna-build database has been removed entirely.  This part of
       the sbuild package was not used, and was not maintained for some
       time.  Users wishing to use wanna-build should investigate the
       version in the wanna-build.git repository used by the Debian
       autobuilding infrastructure.  This version is actively maintained
       and in continual use.
   * sbuild.conf:
     - sbuild.conf is now automatically generated from the help text and
       defaults in the source code.  This means that the examples will
       always be syntactically correct, the help text will always be
       current, and the defaults will always match the defaults in the
       source code (Closes: #609932, #610995).
     - Non-scalar (or reference) types are deprecated in sbuild.conf.
       This is because it is not possible to tell the difference between
       an empty and an undefined value.  Values using array or hash
       types should use the equivalent array reference or hash
       reference, which have been supported for some time.  The old
       style array and hash values will remain supported for now, but
       will be removed in a future release.
   * buildd.conf:
     - Automatically generated like sbuild.conf.  As for sbuild.conf,
       non-scalar types are deprecated.
   * sbuild.conf.5:
     - All of the allowed values in sbuild.conf are now documented in a
       new sbuild.conf(5) manual page.  Like sbuild.conf, this is
       entirely generated from the source code, so will always match the
       defaults for the same sbuild version.
   * buildd.conf.5:
     - New manual page.  Like sbuild.conf(5), this documents all allowed
       values.
Checksums-Sha1: 
 549899de1ee1e7a84db1e46c9f9172091a4175be 1420 sbuild_0.62.0-1.dsc
 3a4f787d8f1a4c442ffd6adaf53151d2bb677966 540344 sbuild_0.62.0.orig.tar.gz
 19322544769c4ec334180f9cbb2f34d623c8915f 50444 sbuild_0.62.0-1.debian.tar.gz
 1ee215784648d8ef6f41be1a437a99a79f765f8e 269428 libsbuild-perl_0.62.0-1_all.deb
 a71ef52264da897cffa1cabd2413c4465314c7b6 265902 buildd_0.62.0-1_all.deb
 c5871de5c092782af1ca914c86709877655fca86 289026 sbuild_0.62.0-1_powerpc.deb
Checksums-Sha256: 
 fb07ccbd62578dce359653166dca5568aba6d1cf0928ada0e2685a0b0216d4ea 1420 sbuild_0.62.0-1.dsc
 84df7ec43e9adf3196e09f2179ccd3401fdb7f5e7eec7d5dee9fe3773229c8d8 540344 sbuild_0.62.0.orig.tar.gz
 9ae1c7ba31015df416060aa98a43e50011d134b4b79b061c33ed07d96623f812 50444 sbuild_0.62.0-1.debian.tar.gz
 209649afcb99c5375974aa6a5cff8df7a49ab25d5d54654986f4b8444c3ea7f1 269428 libsbuild-perl_0.62.0-1_all.deb
 dfc3ce0fe807741d7bc3b9d98123d72a19b3d536a091efac5986aeaed9f3acf3 265902 buildd_0.62.0-1_all.deb
 c24182872f685365326865ee5fc6a36ae57a803ee3e549b01815ec23a58b0c13 289026 sbuild_0.62.0-1_powerpc.deb
Files: 
 53ca9820be19f41ba3f525c139c42f65 1420 devel extra sbuild_0.62.0-1.dsc
 f68388257522f3228c6c4ae6f2abce2e 540344 devel extra sbuild_0.62.0.orig.tar.gz
 41e1b0f46a1fbb6280d9a0244d9862c2 50444 devel extra sbuild_0.62.0-1.debian.tar.gz
 edfd2dc158fee8bfe6b5dc691c04d957 269428 perl extra libsbuild-perl_0.62.0-1_all.deb
 98558b00c8589e8d81308d83741109b9 265902 devel extra buildd_0.62.0-1_all.deb
 681b16199bcef91b82560b7dda53f73f 289026 devel extra sbuild_0.62.0-1_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEAREDAAYFAk2BCm0ACgkQVcFcaSW/uEjHEQCfazmQDHcBUaNmrfIv/Rsr01Bp
H0oAn2w54f7olC5+OJ5Zwu1Cf9M6yCsZ
=3Y4g
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 30 Apr 2011 08:13:13 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 18:54:23 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.