Debian Bug report logs - #229357
dpkg-buildpackage: support for Build-Options: build-arch

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Bill Allombert <ballombe@debian.org>

Date: Sat, 24 Jan 2004 14:18:06 UTC

Severity: wishlist

Tags: patch

Merged with 398625, 479556, 545081, 604919

Found in versions dpkg/1.13.24, dpkg/1.14.7, dpkg/1.15.3.1, dpkg/1.15.8.6

Fixed in versions dpkg/1.16.2~wipmultiarch, dpkg/1.16.2

Done: Guillem Jover <guillem@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, Dpkg Development <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
New Bug report received and forwarded. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <ballombe@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: dpkg-buildpackage: support for Build-Options: build-arch
Date: Wed, 7 Jan 2004 15:26:26 +0100
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.10.18
Severity: wishlist
Tags: patch

Hello dpkg developers,

As discussed in #218893,
here a patch that implement support in dpkg-buildpackage
for `Build-Options: build-arch' in debian/control as
defined in the matching patch to debian-policy.

When a package specify the Build-Options 'build-arch', dpkg-buildpackage
will assume that build-arch and build-indep are implemented in
debian/rules and act accordingly.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux seventeen 2.4.24 #1 Mon Jan 5 19:10:08 CET 2004 i686
Locale: LANG=français, LC_CTYPE=français

Versions of packages dpkg depends on:
ii  dselect                     1.10.18      a user tool to manage Debian packa
ii  libc6                       2.3.2.ds1-10 GNU C Library: Shared libraries an

-- no debconf information
[patch.3.0 (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to "Per Olofsson" <pelle@dsv.su.se>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: "Per Olofsson" <pelle@dsv.su.se>
To: 229357@bugs.debian.org
Cc: 229357-submitter@bugs.debian.org
Subject: Will this patch be applied?
Date: Sat, 20 Mar 2004 13:39:41 +0100
Hi,

Is anybody considering applying this patch? Or do you have any
objections against it? I think it would be good if buildd's didn't
have to waste time on building architecture-independent packages.

-- 
Pelle



Message sent on to Bill Allombert <ballombe@debian.org>:
Bug#229357. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Scott James Remnant <scott@netsplit.com>:
Bug#229357; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to <bill@yellowpig.yi.org>:
Extra info received and forwarded to list. Copy sent to Scott James Remnant <scott@netsplit.com>. Full text and rfc822 format available.

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

From: <bill@yellowpig.yi.org>
To: 229357@bugs.debian.org
Subject: Re: dpkg-buildpackage: support for Build-Options: build-arch
Date: Mon, 17 Oct 2005 12:16:58 +0200
On Wed, Jan 07, 2004 at 03:26:26PM +0100, Bill Allombert wrote:
> Package: dpkg
> Version: 1.10.18
> Severity: wishlist
> Tags: patch
> 
> Hello dpkg developers,
> 
> As discussed in #218893,
> here a patch that implement support in dpkg-buildpackage
> for `Build-Options: build-arch' in debian/control as
> defined in the matching patch to debian-policy.
> 
> When a package specify the Build-Options 'build-arch', dpkg-buildpackage
> will assume that build-arch and build-indep are implemented in
> debian/rules and act accordingly.

Hello dpkg developers,
Now that Sarge was released and dpkg upgraded, is it possible to get
your input on the build-arch/build-indep issue ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: 229357@bugs.debian.org
Subject: dpkg-buildpackage: support for Build-Options: build-arch
Date: Thu, 19 Jan 2006 17:18:26 +0100
Hello DPKG developers,

I am attempting to fix a long standing issue in Debian, which is fully
documented in bug #218893, namely the fact that dpkg-buildpackage will
call 'debian/rules build' even when called with -B, thus making
Build-Depends-Indep nearly useless.

For the exact issue please read #218893. The patch in the bug #229357
implement the fourth proposal.

One problem that plagued the resolution of this bug was the conflicting
opinions of the various dpkg maintainers about how to fix this issue.

So I would be very grateful f you could take a decision and implement
it.

Cheers,
Bill.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: <allomber@math.u-bordeaux.fr>
To: 229357@bugs.debian.org
Subject: Re: dpkg-buildpackage: support for Build-Options: build-arch
Date: Fri, 2 Jun 2006 22:27:38 +0200
Hello DPKG developers,

Following Christian Perrier advice, I resent a former request I posted
in January. I apologise if you actually got the earlier request:

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I am attempting to fix a long standing issue in Debian, which is fully
documented in bug #218893, namely the fact that dpkg-buildpackage will
call 'debian/rules build' even when called with -B, thus making
Build-Depends-Indep nearly useless.

For the exact issue please read #218893. The patch in the bug #229357
implement the fourth proposal.

One problem that plagued the resolution of this bug was the conflicting
opinions of the various dpkg maintainers about how to fix this issue.

So I would be very grateful f you could take a decision and implement
it.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Bug reassigned from package `dpkg' to `dpkg-dev'. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 25 Mar 2007 05:48:02 GMT) Full text and rfc822 format available.

Merged 229357 398625. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 25 Mar 2007 05:48:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Bill Allombert <ballombe@master.debian.org>
Cc: debian-devel@lists.debian.org, 229357@bugs.debian.org
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Tue, 26 Jun 2007 14:33:26 +0100
Bill Allombert writes ("Re: Can we require build-arch/indep targets for lenny?"):
> In 3 years and a half, I had the time to try all of that...
> So I will try something new: an online petition:
> 
> If you would like bug #229357 to get an answer, please
> send a signed email to the buglog.

Please, this is no way to carry on.

> At least, I would feel less alone.

FWIW, I agree with you.  I think the proposed `Build-Options' source
control field is a sensible addition and the bug should be implemented
immediately.

Obviously the dpkg developers are rather busy at the moment.  I think
that the right thing to do is to offer to NMU.

While we are at it we should write a specification for Build-Options,
something like:

  The Build-Options field appears (only) in the first stanza in
  debian/control.  It gives a whitespace-separated list of options.
  The meanings of these options is defined in policy.

  Any package processing tool may act only on options which it
  recognises.  Unknown tokens must be ignored.

  Currently only the following token is defined:

  * build-arch
    Declares that the package supports all of the following
    build targets: `build-indep', `build-arch', `binary-indep',
    `binary-arch'.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: debian-devel@lists.debian.org
Cc: 229357@bugs.debian.org, Bill Allombert <ballombe@debian.org>
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Tue, 26 Jun 2007 16:29:56 +0200
On Tue, Jun 26, 2007 at 02:33:26PM +0100, Ian Jackson wrote:
> Bill Allombert writes ("Re: Can we require build-arch/indep targets for lenny?"):
> > In 3 years and a half, I had the time to try all of that...
> > So I will try something new: an online petition:
> > 
> > If you would like bug #229357 to get an answer, please
> > send a signed email to the buglog.
> 
> Please, this is no way to carry on.

Ironically, you are the only one to do that so far, the fact that you
did not sign your post notwithstanding.

> > At least, I would feel less alone.
> 
> FWIW, I agree with you.  I think the proposed `Build-Options' source
> control field is a sensible addition and the bug should be implemented
> immediately.
> 
> Obviously the dpkg developers are rather busy at the moment.  I think
> that the right thing to do is to offer to NMU.

So I hereby offer to do a NMU by applying this patch.

> While we are at it we should write a specification for Build-Options,
> something like:
> 
>   The Build-Options field appears (only) in the first stanza in
>   debian/control.  It gives a whitespace-separated list of options.
>   The meanings of these options is defined in policy.
> 
>   Any package processing tool may act only on options which it
>   recognises.  Unknown tokens must be ignored.
> 
>   Currently only the following token is defined:
> 
>   * build-arch
>     Declares that the package supports all of the following
>     build targets: `build-indep', `build-arch', `binary-indep',
>     `binary-arch'.

Note: binary-indep and binary-arch are already mandatory according to
Debian policy 4.9. 

The specification are included in the patch to debian-policy in bug
#218893, msgid <20031112203546.GI3260@seventeen>, specifically

+        <sect1 id="f-Build-Options">
+        <heading><tt>Build-Options</tt></heading>
+        <p>
+           The syntax is a list of options separated by
+          commas that are implemented in the build process.
+           The following options are defined:
+           <list>
+             <item> <tt>build-arch</tt> The optional targets "build-arch"
+                 and "build-indep" are implemented by <tt>debian/rules</tt>
+                 as defined in <ref id="debianrules">.  </item>
+           </list>
+        </p>
+        </sect1>

Thanks for yours answer,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: debian-devel@lists.debian.org, 229357@bugs.debian.org
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Tue, 26 Jun 2007 19:19:08 -0400
[Message part 1 (text/plain, inline)]
Ian Jackson wrote:
> While we are at it we should write a specification for Build-Options,
> something like:
> 
>   The Build-Options field appears (only) in the first stanza in
>   debian/control.  It gives a whitespace-separated list of options.
>   The meanings of these options is defined in policy.
> 
>   Any package processing tool may act only on options which it
>   recognises.  Unknown tokens must be ignored.
> 
>   Currently only the following token is defined:
> 
>   * build-arch
>     Declares that the package supports all of the following
>     build targets: `build-indep', `build-arch', `binary-indep',
>     `binary-arch'.

Funny, I'd forgotten this was ever proposed before, and was planning to
propose adding a Build-Options field for entirely other, though fully
compatible reasons. Which suggests that the name and format are well
chosen.

I think it would also be useful to include 'nostrip' and 'noopt' in the
Build-Options field, as a way to indicate that the package implements
those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
that can go in Build-Options, but they're not ready yet and would be OT
in this thread.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: debian-devel@lists.debian.org, 229357@bugs.debian.org
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Tue, 26 Jun 2007 19:22:48 -0400
[Message part 1 (text/plain, inline)]
Bill Allombert wrote:
> +           The syntax is a list of options separated by
> +          commas that are implemented in the build process.
> +           The following options are defined:

If commas are used as delimiters, it should use ", " as the delimiter
for consistency with other fields using commas as delimiters. Since
debian/control has both space and comma-delimited fields, I have no real
preference which is chosen.

Also, I like Ian's language about all unknown fields being ignored.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: debian-devel@lists.debian.org
Cc: 229357@bugs.debian.org
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Tue, 26 Jun 2007 16:23:12 -0700
Joey Hess <joeyh@debian.org> writes:

> I think it would also be useful to include 'nostrip' and 'noopt' in the
> Build-Options field, as a way to indicate that the package implements
> those DEB_BUILD_OPTIONS.

parallel=n as well, while we're at it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Loïc Minier <lool@dooz.org>
To: debian-devel@lists.debian.org
Cc: 229357@bugs.debian.org
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Wed, 27 Jun 2007 11:34:15 +0200
On Tue, Jun 26, 2007, Joey Hess wrote:
> I think it would also be useful to include 'nostrip' and 'noopt' in the
> Build-Options field, as a way to indicate that the package implements
> those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
> that can go in Build-Options, but they're not ready yet and would be OT
> in this thread.

 Why not promote these to requirements in a particular policy version
 instead?  I fear we will have to list 10 Build-Options in all packages
 in a couple of years.

-- 
Loïc Minier



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: debian-devel@lists.debian.org
Cc: 229357@bugs.debian.org
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Wed, 27 Jun 2007 06:38:00 -0700
Loïc Minier <lool@dooz.org> writes:
> On Tue, Jun 26, 2007, Joey Hess wrote:

>> I think it would also be useful to include 'nostrip' and 'noopt' in the
>> Build-Options field, as a way to indicate that the package implements
>> those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
>> that can go in Build-Options, but they're not ready yet and would be OT
>> in this thread.

>  Why not promote these to requirements in a particular policy version
>  instead?  I fear we will have to list 10 Build-Options in all packages
>  in a couple of years.

Currently, policy says that it's recommended (the weakest policy
directive) to support noopt and nostrip.  My main concern with increasing
the strength of that directive is that, depending on how demented the
upstream build system is, it can be difficult to support these options,
and since neither is used for regular builds in Debian, they're not
usually tested and aren't necessary for properly functioning packages.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>, 229357@bugs.debian.org
Cc: Bill Allombert <ballombe@master.debian.org>, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Fri, 29 Jun 2007 00:41:04 +0300
Hi,

On Tue, 2007-06-26 at 14:33:26 +0100, Ian Jackson wrote:
> Bill Allombert writes ("Re: Can we require build-arch/indep targets for lenny?"):
> > At least, I would feel less alone.
> 
> FWIW, I agree with you.  I think the proposed `Build-Options' source
> control field is a sensible addition and the bug should be implemented
> immediately.
>
> Obviously the dpkg developers are rather busy at the moment.  I think
> that the right thing to do is to offer to NMU.

Errr, what's the rush now to get this fixed? It's something that has
been there like forever, the bug report proposes adding a new field
which personally I don't like taking lightly.

I've been pondering on what's the cleanest way to fix it for some time,
and I tend to agree with Steve about using the make options to test
for the existence of the targets. But as others have pointed out it's
not clear why that change was reverted at the time.

regards,
guillem



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: debian-devel@lists.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 229357@bugs.debian.org, Bill Allombert <ballombe@debian.org>
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Fri, 29 Jun 2007 23:11:04 +0200
On Fri, Jun 29, 2007 at 12:41:04AM +0300, Guillem Jover wrote:
> > Obviously the dpkg developers are rather busy at the moment.  I think
> > that the right thing to do is to offer to NMU.
> 
> Errr, what's the rush now to get this fixed? It's something that has
> been there like forever, the bug report proposes adding a new field
> which personally I don't like taking lightly.

This field does not need to be exported to the Source file, so it does
not have a large impact.

> I've been pondering on what's the cleanest way to fix it for some time,
> and I tend to agree with Steve about using the make options to test
> for the existence of the targets. But as others have pointed out it's
> not clear why that change was reverted at the time.

One of the issue is that tools like sbuild and pbuilder which want to
take advantage of the Build-Depends-Indep split needs to know whether
dpkg-buildpackage will call debian/rules build or build-arch.  So if you
go that route, the exact criterium used by dpkg-buildpackage need to be
published as an interface.

Any additional detail is available at <http://bugs.debian.org/218893>

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, debian-devel@lists.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>, 229357@bugs.debian.org,
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Sat, 30 Jun 2007 09:40:29 +0200
In article <20070629211104.GC3320@yellowpig> (gmane.linux.debian.devel.general) you wrote:
> On Fri, Jun 29, 2007 at 12:41:04AM +0300, Guillem Jover wrote:
[...]
>> I've been pondering on what's the cleanest way to fix it for some time,
>> and I tend to agree with Steve about using the make options to test
>> for the existence of the targets. But as others have pointed out it's
>> not clear why that change was reverted at the time.

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=345;att=0;bug=218893
| -q checks for "up to dateness" ... the next time you ran the test, it
| would fail because build-stamp had been touched and dpkg-buildpackage
| would incorrectly run build for you instead.

> One of the issue is that tools like sbuild and pbuilder which want to
> take advantage of the Build-Depends-Indep split needs to know whether
> dpkg-buildpackage will call debian/rules build or build-arch.  So if you
> go that route, the exact criterium used by dpkg-buildpackage need to be
> published as an interface.

I think that is just wrong. sbuild should not need to know anything
about dpkg-buildpackage's internals and there is no need for change
here. The currently used and proven interface is:

1. install Build-Depends for running dpkg-buildpackage -B

2. install Build-Depends *and* Build-Indep-Indep for running
dpkg-buildpackage differently (e.g without any modifier or with -b)

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Sun, 1 Jul 2007 17:22:31 +0200
On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
> I think that is just wrong. sbuild should not need to know anything
> about dpkg-buildpackage's internals and there is no need for change
> here. The currently used and proven interface is:
> 
> 1. install Build-Depends for running dpkg-buildpackage -B

The issue we are trying to fix is that the current combination of 
Debian policy and dpkg-buildpackage actually require
Build-Depends-Indep to be installed when running dpkg-buildpackage -B.

Indeed dpkg-buildpackage -B calls 'debian/rules build' which
requires Build-Depends-Indep to be installed. Since buildd actually
implement 1) this cause packages to FTBFS until they are 'fixed' by
having 'build' not depending on 'build-indep' (or equivalently, the
build-indep task being performed directly by binary-indep), which is
against the spirit of policy (because build-indep will then be 
executed under sudo or fakeroot).

So this interface is used and proven to be wrong.

> 2. install Build-Depends *and* Build-Indep-Indep for running
> dpkg-buildpackage differently (e.g without any modifier or with -b)

If you insist to go that road, you need to:

1) Change policy to require build-arch is implemented anytime the field
Build-Depends-Indep is provided.
and
2) Change dpkg-buildpackage -B to call build-arch if the field
Build-Depends-Indep is present.

Please submit patches if you are interested.

However this proposal will cause a number packages to FTBFS until
they are fixed (but less than always using build-arch).

See <http://bugs.debian.org/218893> for any additional details. I am
merely restating the issues.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Sun, 01 Jul 2007 18:51:12 +0200
Bill Allombert wrote:
> On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
>> I think that is just wrong. sbuild should not need to know anything
>> about dpkg-buildpackage's internals and there is no need for change
>> here. The currently used and proven interface is:

>> 1. install Build-Depends for running dpkg-buildpackage -B

> The issue we are trying to fix is that the current combination of 
> Debian policy and dpkg-buildpackage actually require
> Build-Depends-Indep to be installed when running dpkg-buildpackage -B.

Hello,
Policy does not reflect current reality in that respect. The buildds
do run dpkg-buildpackage -B and they do not install
Build-Depends-Indep. Packages requiring Build-Depends-Indep for
dpkg-buildpackage -B will FTBFS. Since that makes the package
unreleasable there are not many packages around that work like that.
(Except for source packages that do not build any arch-any packages
and therefore are not autobuilt.)

[snip]

>> 2. install Build-Depends *and* Build-Indep-Indep for running
>> dpkg-buildpackage differently (e.g without any modifier or with -b)

> If you insist to go that road, you need to:

> 1) Change policy to require build-arch is implemented anytime the field
> Build-Depends-Indep is provided.
> and
> 2) Change dpkg-buildpackage -B to call build-arch if the field
> Build-Depends-Indep is present.
[...]

No, that is not necessary. What needs to happen is just:
---------------
Somehow make dpkg-buildpackage -B make use of the build-arch target
if present. Either by detecting it automatically or by something like
#229357.
---------------

Once that happens the current wording in policy matches reality for
packages proving a build-arch target.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Simon Richter <sjr@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Simon Richter <sjr@debian.org>
To: 229357@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Mon, 02 Jul 2007 10:12:09 +0200
Hi,

Andreas Metzler wrote:

> ---------------
> Somehow make dpkg-buildpackage -B make use of the build-arch target
> if present. Either by detecting it automatically or by something like
> #229357.
> ---------------

The entire issue circles around not being able to reliably detect 
whether the target is present using a simple script. But who said it has 
to be a script?

Proposed alternative solution:

1. hack GNU make to support a "--has-target" option that returns an 
appropriate return code (hey, it's free software, after all!). Proposed 
return codes are 0 (yes), 1 (no) and 2 (error).

2. make "dpkg-buildpackage -B" use this facility to determine whether 
the target is present. If yes, use the "build-arch" target to build; if 
no, use the "build" target after printing a warning.

3. grep the build logs for warnings about missing "build-arch" target, 
add an entry to the TODO list on the package overview page on 
qa.debian.org and to DDPO.

The only remaining question is what should happen with build failures in 
packages that provide a non-functional "build-arch" target. In my 
opinion, this is a genuine bug, even if policy can be read in a way that 
makes it disagree.

   Simon



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Simon Richter <sjr@debian.org>
Cc: 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Mon, 02 Jul 2007 14:42:31 +0200
Simon Richter <sjr@debian.org> writes:

> Hi,
>
> Andreas Metzler wrote:
>
>> ---------------
>> Somehow make dpkg-buildpackage -B make use of the build-arch target
>> if present. Either by detecting it automatically or by something like
>> #229357.
>> ---------------
>
> The entire issue circles around not being able to reliably detect
> whether the target is present using a simple script. But who said it
> has to be a script?
>
> Proposed alternative solution:
>
> 1. hack GNU make to support a "--has-target" option that returns an
> appropriate return code (hey, it's free software, after
> all!). Proposed return codes are 0 (yes), 1 (no) and 2 (error).
>
> 2. make "dpkg-buildpackage -B" use this facility to determine whether
> the target is present. If yes, use the "build-arch" target to build;
> if no, use the "build" target after printing a warning.
>
> 3. grep the build logs for warnings about missing "build-arch" target,
> add an entry to the TODO list on the package overview page on
> qa.debian.org and to DDPO.
>
> The only remaining question is what should happen with build failures
> in packages that provide a non-functional "build-arch" target. In my
> opinion, this is a genuine bug, even if policy can be read in a way
> that makes it disagree.
>
>    Simon
>
>
> -- 
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

There are two points to this:

1.) don't call build so build-indep is not called

2.) have Build-Depends only contain packages needed for build-arch and
binary-arch

The seconds part requires that tools like sbuild and pbuilder know
beforehand if build or build-arch will be used. Running debian-rules
can always have side effects and can actively rely on them so a
"--has-target" can not be implemented cleanly in make.

So you missed the point.

MfG
        Goswin



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Simon Richter <sjr@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Simon Richter <sjr@debian.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Mon, 02 Jul 2007 15:28:05 +0200
Hello,

Goswin von Brederlow wrote:

> The seconds part requires that tools like sbuild and pbuilder know
> beforehand if build or build-arch will be used.

For packages that do not implement build-arch, it is acceptable to call 
the build target with only B-D installed, because that is the way the 
autobuilders handle it now. So no problem there; packages that implement 
build-arch can move the dependencies not needed for building 
arch-dependent packages from B-D to B-D-I as soon as the autobuilders 
start using build-arch.

Getting rid of unneeded build dependencies is mostly orthogonal to the 
issue at hand, though.

> Running debian-rules
> can always have side effects and can actively rely on them so a
> "--has-target" can not be implemented cleanly in make.

I am proposing hooking into the logic that ultimately decides that there 
is no such target in the Makefile and goes on to print "Don't know how 
to make 'foo'. Stop.". This means that Makefiles are rebuilt before that 
test is performed, we stop immediately before the point where we would 
go towards the first goal target.

Yes, that means running commands that possibly have side effects. But we 
are going to run these commands anyway.

   Simon



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, debian-devel@lists.debian.org, lucas@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Mon, 2 Jul 2007 21:26:23 -0700
[Message part 1 (text/plain, inline)]
On Sun, Jul 01, 2007 at 05:22:31PM +0200, Bill Allombert wrote:
> On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
> > I think that is just wrong. sbuild should not need to know anything
> > about dpkg-buildpackage's internals and there is no need for change
> > here. The currently used and proven interface is:

> > 1. install Build-Depends for running dpkg-buildpackage -B

> The issue we are trying to fix is that the current combination of 
> Debian policy and dpkg-buildpackage actually require
> Build-Depends-Indep to be installed when running dpkg-buildpackage -B.

> Indeed dpkg-buildpackage -B calls 'debian/rules build' which
> requires Build-Depends-Indep to be installed. Since buildd actually
> implement 1) this cause packages to FTBFS until they are 'fixed' by
> having 'build' not depending on 'build-indep' (or equivalently, the
> build-indep task being performed directly by binary-indep), which is
> against the spirit of policy (because build-indep will then be 
> executed under sudo or fakeroot).

> So this interface is used and proven to be wrong.

Attached is a patch to dpkg which implements a check for a 'build-arch'
target using 'make -f debian/rules -qn build-arch'.

I looked into using make -pn, but Guillem Jover pointed out that this
doesn't work if the 'build-arch' target is implemented using patterns. 
'-qn' appears the most reliable option; this is the same basic technique
that was attempted once before and reverted by Adam Heath, the dpkg
maintainer at the time, so I spoke with him about the reasons for the revert
and it appears the concerns are mostly about dpkg behavior on systems that
do not conform to Debian policy.

I don't think that's a good enough reason to stall innovation that benefits
Debian, but perhaps the current dpkg maintainers do; I'll try to lay out the
technical details impartially for their consideration so they can make an
informed decision.

I believe the attached patch has the following characteristics:

- Any packages in Debian that currently have existing but /broken/
  'build-arch' targets will fail to build because of the failure of this
  target.
- Any packages that have a debian/rules which is not a valid Makefile will
  continue to build as before (the new code will conclude that there is no
  valid 'build-arch' target).
- Packages in Debian that have a 'build-arch' target will have this target
  used instead of 'build' when 'dpkg-buildpackage -B' is called.
- Packages in Debian that do not have a 'build-arch' target will continue to
  have their 'build' target called by 'dpkg-buildpackage -B'.
- Behavior on systems where 'make' is not GNU make is undefined.
  Specifically, on such a system dpkg is likely to either conclude that
  /all/ packages support 'build-arch', or that /none/ of them support
  'build-arch', depending on whether and how 'make -qn' fails.

This has the following further implications:

- Barring any buggy 'build-arch' targets, all packages that currently build
  on Debian autobuilders should continue to build successfully and
  correctly.
- Packages that do support 'build-arch' today will also build faster,
  because the indep build will now be skipped.
- Packages that do not yet support 'build-arch' can adopt this target
  without any need for coordinated changes on the buildds.
- Packages that include in their Build-Depends field build-dependencies
  which are only needed for the architecture-independent portion of the
  'build' target can move these build-dependencies to Build-Depends-Indep as
  soon as they have a 'binary-arch' target that does not depend on the
  'build' target, and a working 'build-arch' target that does not perform
  the related architecture-independent build operations.  Packages that make
  this change to their Build-Depends field should also build-depend on the
  version of dpkg-dev introducing these semantics.

Documenting this in policy should be straightforward if these changes to
dpkg are accepted.

Lucas has agreed to doing a full archive rebuild with a modified dpkg-dev,
for comparison with the previous test.  A dpkg-dev binary including this
change can be found at
<http://people.debian.org/~vorlon/dpkg-dev_1.14.4-0.1_all.deb>.

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/
[dpkg-229357.diff (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Adam Borowski <kilobyte@angband.pl>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Adam Borowski <kilobyte@angband.pl>
To: debian-devel@lists.debian.org
Cc: 229357@bugs.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 3 Jul 2007 09:54:03 +0200
On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> I believe the attached patch has the following characteristics:
> - Behavior on systems where 'make' is not GNU make is undefined.
>   Specifically, on such a system dpkg is likely to either conclude that
>   /all/ packages support 'build-arch', or that /none/ of them support
>   'build-arch', depending on whether and how 'make -qn' fails.

Too bad, both Solaris and BSD make fail the bad way, returning 1 on a bad
target -- and neither has -v or --version.  I haven't checked the rest, but
it's likely they behave the same way.

So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
for some portability?

-- 
1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Adam Borowski <kilobyte@angband.pl>
Cc: debian-devel@lists.debian.org, 229357@bugs.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 3 Jul 2007 10:01:47 -0700
On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
> On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > I believe the attached patch has the following characteristics:
> > - Behavior on systems where 'make' is not GNU make is undefined.
> >   Specifically, on such a system dpkg is likely to either conclude that
> >   /all/ packages support 'build-arch', or that /none/ of them support
> >   'build-arch', depending on whether and how 'make -qn' fails.

> Too bad, both Solaris and BSD make fail the bad way, returning 1 on a bad
> target -- and neither has -v or --version.  I haven't checked the rest, but
> it's likely they behave the same way.

> So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
> for some portability?

What 'blah' are you planning to use that's guaranteed to not have broken
side-effects in some cases on Debian packages?

-- 
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/



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Simon Richter <sjr@debian.org>
Cc: 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 3 Jul 2007 18:05:54 +0100
Simon Richter writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
> The entire issue circles around not being able to reliably detect 
> whether the target is present using a simple script. But who said it has 
> to be a script?

We want the package to _declare_ whether it supports this new target.

The proposed -Options field will actually be very useful for any
other enhancements we make to the source package format.

> Proposed alternative solution:
> 
> 1. hack GNU make to support a "--has-target" option that returns an 
> appropriate return code (hey, it's free software, after all!). Proposed 
> return codes are 0 (yes), 1 (no) and 2 (error).

OMG WTF BBQ

(ie, this is a terrible suggestion)

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Steve Langasek <vorlon@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, debian-devel@lists.debian.org, lucas@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 3 Jul 2007 18:07:54 +0100
Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
> Attached is a patch to dpkg which implements a check for a 'build-arch'
> target using 'make -f debian/rules -qn build-arch'.

Why are we so resistant to the new debian/control field ?  That
doesn't require any of this messing about with make.

Note that the current setup does not actually require debian/rules to
be a makefile.  I don't think we should introduce software which has a
requirement if we can avoid it.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, debian-devel@lists.debian.org, lucas@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 3 Jul 2007 11:01:08 -0700
On Tue, Jul 03, 2007 at 06:07:54PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets for lenny?"):
> > Attached is a patch to dpkg which implements a check for a 'build-arch'
> > target using 'make -f debian/rules -qn build-arch'.

> Why are we so resistant to the new debian/control field ?  That
> doesn't require any of this messing about with make.

But it does require the maintainer to keep three bits of information in
sync: the new declarative Build-Options field, the build-arch target, and
the Build-Depends field.  That's added complexity which means an added
opportunity for bugs, so if the complexity can be avoided I think it's
worthwhile.

If the dpkg maintainers feel that this autodetection isn't adequate, I do
support implementing build-arch by way of Build-Options.  The benefits would
be realized more slowly, but they would be realized, and without the
insanity of making 75% of our packages FTBFS in unstable first.

> Note that the current setup does not actually require debian/rules to
> be a makefile.  I don't think we should introduce software which has a
> requirement if we can avoid it.

This doesn't require debian/rules to be a makefile either (though Policy
does), it just requires that debian/rules be a makefile *if* the package
implements build-arch and uses the corresponding semantics for
Build-Depends.

Anyway, for the perverse, the following is a valid makefile and a valid
shell script. ;)

  #!/bin/sh

  fakeout="
  build-arch: "

  	case "$1" in
  	build-arch)
  		echo whee fun.
  		;;
  	esac



-- 
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/



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Sam Hocevar <sam@zoy.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Sam Hocevar <sam@zoy.org>
To: debian-devel@lists.debian.org, 229357@bugs.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 3 Jul 2007 20:04:54 +0200
On Tue, Jul 03, 2007, Steve Langasek wrote:

> > So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
> > for some portability?
> 
> What 'blah' are you planning to use that's guaranteed to not have broken
> side-effects in some cases on Debian packages?

   How about: "blah$((uptime;ps aux) | sha1sum | cut -f1 -d-)"

Cheers,
-- 
Sam.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Adam Borowski <kilobyte@angband.pl>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Adam Borowski <kilobyte@angband.pl>
To: debian-devel@lists.debian.org
Cc: 229357@bugs.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 3 Jul 2007 22:01:44 +0200
On Tue, Jul 03, 2007 at 10:01:47AM -0700, Steve Langasek wrote:
> On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
> > So, an idea: what about checking "make -f /dev/null blah 2>/dev/null" first,
> > for some portability?
> 
> What 'blah' are you planning to use that's guaranteed to not have broken
> side-effects in some cases on Debian packages?

Any 'blah' which is not found in /dev/null, I think.
I'm not aware of any local files which can break 'make -f'.

-- 
1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Wouter Verhelst <wouter@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, debian-devel@lists.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>, 229357@bugs.debian.org, Bill Allombert <ballombe@debian.org>
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Wed, 4 Jul 2007 01:06:43 +0200
On Fri, Jun 29, 2007 at 11:11:04PM +0200, Bill Allombert wrote:
> One of the issue is that tools like sbuild and pbuilder which want to
> take advantage of the Build-Depends-Indep split needs to know whether
> dpkg-buildpackage will call debian/rules build or build-arch.

It needs to know no such thing. It just needs to know that if it runs
"dpkg-buildpackage -b", only .debs will be generated, and if it runs
"dpkg-buildpackage -B", all debs apart from the _all.debs will be
generated. How exactly this happens is of no concern to sbuild.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Wouter Verhelst <wouter@debian.org>
To: Simon Richter <sjr@debian.org>
Cc: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Wed, 4 Jul 2007 01:17:11 +0200
On Mon, Jul 02, 2007 at 03:28:05PM +0200, Simon Richter wrote:
>> Running debian-rules can always have side effects and can actively
>> rely on them so a "--has-target" can not be implemented cleanly in
>> make.
>
> I am proposing hooking into the logic that ultimately decides that
> there is no such target in the Makefile and goes on to print "Don't
> know how to make 'foo'. Stop.".

$(shell ls temp-target-* && rm temp-target-*):

Yes, that's broken, but there are your side effects, and you'll have to
run this code if you want to make your --has-target work.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Simon Richter <sjr@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Simon Richter <sjr@debian.org>
To: Wouter Verhelst <wouter@debian.org>
Cc: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Wed, 04 Jul 2007 10:19:47 +0200
Hi,

Wouter Verhelst wrote:

> $(shell ls temp-target-* && rm temp-target-*):

> Yes, that's broken, but there are your side effects, and you'll have to
> run this code if you want to make your --has-target work.

Yes, that is exactly what I'm proposing. The same thing happens for -q 
mode now.

   Simon



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Simon Richter <sjr@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Simon Richter <sjr@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Wed, 04 Jul 2007 10:35:05 +0200
Hi,

Ian Jackson wrote:

> We want the package to _declare_ whether it supports this new target.

Ideally, we'd want all packages to support the new target, and then turn 
that into policy, otherwise we'll end up supporting both for a very long 
time.

> The proposed -Options field will actually be very useful for any
> other enhancements we make to the source package format.

I'm not disputing that, but I'm not sure we really want it in this case.

   Simon



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. 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 Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Wed, 4 Jul 2007 10:38:08 +0200
On 02/07/07 at 21:26 -0700, Steve Langasek wrote:
> Lucas has agreed to doing a full archive rebuild with a modified dpkg-dev,
> for comparison with the previous test.  A dpkg-dev binary including this
> change can be found at
> <http://people.debian.org/~vorlon/dpkg-dev_1.14.4-0.1_all.deb>.

Hi,

Here are some results:
7299 packages from unstable/main were rebuilt (that's all packages
building non-arch:all packages).
1823 packages were built using 'debian/rules build-arch'.

Of those 1823 packages, 31 packages failed to build. Logs can be found
on http://people.debian.org/~lucas/logs/2007/07/04/ .

Regarding build time, it's difficult to compare, because the most recent
data I have was generated on a different set of cluster nodes, and the
nodes I used for this have a slower network connection. Also, the
mirror's disk is a bottleneck since I was using 55 nodes. But some
packages seem to benefit from using build-arch despite that. See
http://people.debian.org/~lucas/logs/2007/07/04/00impr_bt.txt . Previous
and current build times are the 8th and 9th columns.

There might be others, that /built/ faster, but that took a longer time
to fetch build-deps because of the network/mirror.

The full listing of the results is on
http://people.debian.org/~lucas/logs/2007/07/04/00summary.txt , with the
columns being:
1: package
2, 3, 4: previous, current version, and whether they differ
5, 6, 7: previous, current result, and whether they differ
8, 9, 10: previous, current result, and whether they differ (incl.
margin of error)
11, 12, 13: previous, current reason for build failure, and whether they
differ.

So, to conclude: this change seems like a good idea, with only about 30
packages to fix (but they should probably be fixed anyway). Not so many
packages benefit from it currently, but there was no reason until now for packages
to implement that.
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Wouter Verhelst <wouter@debian.org>
Cc: Simon Richter <sjr@debian.org>, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, 229357@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Thu, 05 Jul 2007 19:49:50 +0200
Wouter Verhelst <wouter@debian.org> writes:

> On Mon, Jul 02, 2007 at 03:28:05PM +0200, Simon Richter wrote:
>>> Running debian-rules can always have side effects and can actively
>>> rely on them so a "--has-target" can not be implemented cleanly in
>>> make.
>>
>> I am proposing hooking into the logic that ultimately decides that
>> there is no such target in the Makefile and goes on to print "Don't
>> know how to make 'foo'. Stop.".
>
> $(shell ls temp-target-* && rm temp-target-*):
>
> Yes, that's broken, but there are your side effects, and you'll have to
> run this code if you want to make your --has-target work.

Or just a simple

include debian/rules.gen

while that is generated as needed.

MfG
        Goswin



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: debian-devel@lists.debian.org, 229357@bugs.debian.org
Subject: Re: Can we require build-arch/indep targets for lenny?
Date: Tue, 10 Jul 2007 10:20:36 +0100
Russ Allbery writes ("Re: Can we require build-arch/indep targets for lenny?"):
> Lo?c Minier <lool@dooz.org> writes:
> >  Why not promote these to requirements in a particular policy version
> >  instead?  I fear we will have to list 10 Build-Options in all packages
> >  in a couple of years.

This is a much better idea.

> Currently, policy says that it's recommended (the weakest policy
> directive) to support noopt and nostrip.  My main concern with increasing
> the strength of that directive is that, depending on how demented the
> upstream build system is, it can be difficult to support these options,
> and since neither is used for regular builds in Debian, they're not
> usually tested and aren't necessary for properly functioning packages.

Surely we are planning to support these options in all packages
eventually ?  In a package where it is difficult to separate out the
work for binary-indep, it would be acceptable to say:
   binary-indep: binary
   binary-arch: binary
   binary: build
           some stuff
?

I'm tempted to suggest _just_ going by the package's Standards-Version.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Wouter Verhelst <wouter@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, debian-devel@lists.debian.org, Ian Jackson <ian@davenant.greenend.org.uk>, 229357@bugs.debian.org, Bill Allombert <ballombe@debian.org>
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Tue, 17 Jul 2007 11:41:59 +0200
Wouter Verhelst <wouter@debian.org> writes:

> On Fri, Jun 29, 2007 at 11:11:04PM +0200, Bill Allombert wrote:
>> One of the issue is that tools like sbuild and pbuilder which want to
>> take advantage of the Build-Depends-Indep split needs to know whether
>> dpkg-buildpackage will call debian/rules build or build-arch.
>
> It needs to know no such thing. It just needs to know that if it runs
> "dpkg-buildpackage -b", only .debs will be generated, and if it runs
> "dpkg-buildpackage -B", all debs apart from the _all.debs will be
> generated. How exactly this happens is of no concern to sbuild.

It does when "Build-Depends" is used as specified in policy and not
like it is (brokenly) used now:

Policy 7.6:

| Build-Depends, Build-Conflicts
|
|    The Build-Depends and Build-Conflicts fields must be satisfied
|    when any of the following targets is invoked: build, clean,
|    binary, binary-arch, build-arch, build-indep and binary-indep. 
|
| Build-Depends-Indep, Build-Conflicts-Indep
| 
|     The Build-Depends-Indep and Build-Conflicts-Indep fields must be
|     satisfied when any of the following targets is invoked: build,
|     build-indep, binary and binary-indep.

That means that is -b is used or if the package does NOT support
build-arch then sbuild must install Build-Depends-Indep as well.

If build-arch remains optional and policy for Build-Depends remains
unchanged then sbuild must now. Making build-arch required or changing
the meaning of Build-Depends to the broken use we have now resolves
this. I favor making build-arch required.

MfG
        Goswin



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Frank Lichtenheld <djpig@debian.org>
To: control@bugs.debian.org
Cc: 229357@bugs.debian.org
Subject: tagging 229357
Date: Sat, 29 Sep 2007 21:10:52 +0200
# Automatically generated email from bts, devscripts version 2.10.8
# wrong bugnumber
tags 229357 + patch





Tags added: patch Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. (Sat, 29 Sep 2007 19:15:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Frank Lichtenheld <djpig@debian.org>
To: control@bugs.debian.org
Cc: 229357@bugs.debian.org
Subject: tagging 229357
Date: Sat, 29 Sep 2007 21:09:38 +0200
# Automatically generated email from bts, devscripts version 2.10.8
# non-trivial patch against old shell version
tags 229357 - patch





Tags removed: patch Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. (Sat, 29 Sep 2007 19:39:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Frank Lichtenheld <djpig@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, debian-devel@lists.debian.org, lucas@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Sat, 29 Sep 2007 22:09:19 +0200
On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> Attached is a patch to dpkg which implements a check for a 'build-arch'
> target using 'make -f debian/rules -qn build-arch'.

Is there actually a defined semantic for make -qn ? The make info manual
states:

"It is an error to use more than one of these three flags [-q, -t, -n] in the same
invocation of `make'."

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/




Tags added: patch Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. (Sat, 29 Sep 2007 20:42:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Frank Lichtenheld <djpig@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, debian-devel@lists.debian.org, lucas@debian.org, vorlon@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Fri, 12 Oct 2007 22:49:13 +0200
On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote:
> On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > Attached is a patch to dpkg which implements a check for a 'build-arch'
> > target using 'make -f debian/rules -qn build-arch'.
> 
> Is there actually a defined semantic for make -qn ? The make info manual
> states:
> 
> "It is an error to use more than one of these three flags [-q, -t, -n] in the same
> invocation of `make'."

No answer? I would like to work on this, but someone would need to
answer my questions about it...

(explicetly sending to vorlon, too, ignoring the M-F-T)

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: debian-devel@lists.debian.org
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, lucas@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Fri, 12 Oct 2007 14:13:49 -0700
On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
> On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote:
> > On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
> > > Attached is a patch to dpkg which implements a check for a 'build-arch'
> > > target using 'make -f debian/rules -qn build-arch'.

> > Is there actually a defined semantic for make -qn ? The make info manual
> > states:

> > "It is an error to use more than one of these three flags [-q, -t, -n] in the same
> > invocation of `make'."
> 
> No answer? I would like to work on this, but someone would need to
> answer my questions about it...

> (explicetly sending to vorlon, too, ignoring the M-F-T)

I have no answers for you about whether there are defined semantics for this
use of make. :)

Anyway, I thought this patch was ruled out in later discussion in the
thread.

-- 
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/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Frank Lichtenheld <djpig@debian.org>
To: debian-devel@lists.debian.org, debian-dpkg@lists.debian.org, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, lucas@debian.org, vorlon@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Sat, 13 Oct 2007 01:09:57 +0200
On Fri, Oct 12, 2007 at 02:13:49PM -0700, Steve Langasek wrote:
> On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
> > No answer? I would like to work on this, but someone would need to
> > answer my questions about it...
> 
> > (explicetly sending to vorlon, too, ignoring the M-F-T)
> 
> I have no answers for you about whether there are defined semantics for this
> use of make. :)
> 
> Anyway, I thought this patch was ruled out in later discussion in the
> thread.

Hmm, it was opposed by some but I don't see a consensus reached
anywhere. Let's try to give a summary of the discussion.

So far the proposed solutions for this problem are:

1) Build-Options field

As pointed out this doesn't scale very well and there is no real way to
make it default behaviour one day. This would be the way to go though if
it only needs to be specified for few packages (either because we think
that few packages actually need build-arch support or because of the
solution I propose below, combining it with autodetection).

I'm not particulary impressed with this.

2) Standards-Version, i.e. make it 'must' in policy

This should work but it completly contradicts the past Debian standards
process (according to Lucas' numbers, the new policy would currently
only be satisfied by < 2000 packages, i.e. somewhere in the 20% region)
and would make a solution dependant on the policy team, which is currently
somewhat MIA...

It would be really nice to have a policy someday that acutally matches
reality, though.

3) Autodetection

Would be clearly the easiest solution if it works reliably.
There are some problems:
 - Works only with GNU make
 - depends on a _should_ in policy, not a _must_
   (error code)
On the other hand, according to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#172 it
mostly works, and most of the cases where it doesn't work seem
to be the packages fault (i.e. the binary-arch target seems to
depend on the build-indep target without actually declaring
that dependency).


BTW, the "correct" solution in any case would be to run checkbuilddeps
again if we don't find build-arch support, since we need b-d-i, too.
And *poof*, there go our buildds ;) which brings me to the last
solution which I think wasn't actually proposed:

4) Adapt policy to sbuilds behaviour

I.e. don't require b-d-i on build, but only on binary and binary-indep.



Conclusion:

I would be interested to gather some input from the interested persons
regarding their exact position. I think the following questions should
give us a good understanding or their position:
(want == 'I want it and I also think it would be possible to do')

 1) Do you want to change sbuild to actually respect policy?
 1a) (SKIP if 'no' to 1) Before lenny's release?
 2) (SKIP if 'yes' to 1) Do you want to change policy to declare sbuild's
    behaviour official?
 3) Do you want for all packages to support build-arch in the
    nearer future (longest lenny+1) [== policy 'must']?
 4) (SKIP if 'yes' to 3) In the farer future?
 5) Do you think autodetection can work and should be used?
 6) (SKIP if 'yes' to 5) Do you think that autodetection can
    work and should be used, if packages would have the ability
    to override it if they know they get detected wrong?

My answers are:
YN-NNNY

After considering all the arguments I believe that the best solution
would be to try to implement autodetection _and_ support Build-Options
to give maintainers the ability to override it. Build-Options is simply
the easiest and best-working possibility, but for good behaving packages
it should not be neccessary. And I strongly believe that after lenny's
release dpkg-buildpackage should start to check the 'correct'
build-dependencies according to policy (i.e. requiring b-d-i if
build-arch is not supported).

I would volunteer to implement the solution I propose (in the near
future) if there are enough supporters.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Simon Richter <sjr@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Simon Richter <sjr@debian.org>
To: debian-devel@lists.debian.org, debian-dpkg@lists.debian.org, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, lucas@debian.org, vorlon@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Wed, 17 Oct 2007 15:47:14 +0200
Hi,

Frank Lichtenheld schrieb:

> 3) Autodetection

My approach would be to have the autobuilders use "build-arch", and if 
that fails within 60 seconds, "clean" and "build".

If "build-arch" is not implemented, it fails rather quickly, so we use 
"build" and make a note in the build log. Later, one can grep for that note.

If it is implemented, but fails within 60 seconds, not much is lost.

If it takes longer to fail, then it's a normal FTBFS.

   Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: 229357@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#229357 closed by Ian Jackson <ian@davenant.greenend.org.uk> (Re: Bug#398625: adapted patch against current dpkg)
Date: Sun, 4 Nov 2007 19:20:12 +0100
reopen 229357
thanks
On Sun, Nov 04, 2007 at 03:45:14PM +0000, Debian Bug Tracking System wrote:
> Simon Richter writes ("Bug#398625: adapted patch against current dpkg"):
> > I have written a new implementation of the patch proposed earlier,
> > against the current shell script.
> 
> As discussed on debian-devel, I think this approach is fundamentally
> wrong.

This report seems to have been closed in error: 229357 is my patch, not Simon
which is 398625.

> Failure of a rules target should not be treated as an invitation to
> try a different target. 

My patch does not do that.

> The package should declare (eg with
> Build-Options) what the situation is.

My patch does that.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Bug reopened, originator not changed. Request was from Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> to control@bugs.debian.org. (Sun, 04 Nov 2007 18:24:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, 398625@bugs.debian.org
Subject: Re: Bug#229357: closed by Ian Jackson <ian@davenant.greenend.org.uk> (Re: Bug#398625: adapted patch against current dpkg)
Date: Sun, 4 Nov 2007 19:41:21 +0000
Bill Allombert writes ("Bug#229357: closed by Ian Jackson <ian@davenant.greenend.org.uk>  (Re: Bug#398625: adapted patch against current dpkg)"):
> This report seems to have been closed in error: 229357 is my patch, not Simon
> which is 398625.

The two bug reports are merged and I was responding to Simon Richter's
mail of 2007-11-04 14:44:41 +0100.  Evidently neither of us had
noticed the merger.  Thanks for being observant and reopening the bug.

> > The package should declare (eg with
> > Build-Options) what the situation is.
> 
> My patch does that.

Ah, yes.

Bill, can you give me a reference to what you consider the definitive
definition of the behaviour of your proposed patch ?  Presumably this
would be in the form of a policy amendment ?

Both #229357 and #218893 are very long and it would save some time if
you could point out what you think is the current final spec and
whether there are any outstanding issues that you would like the dpkg
developers to decide on.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Ian Jackson <ian@davenant.greenend.org.uk>
Cc: 229357@bugs.debian.org
Subject: Bug #229357: dpkg-buildpackage: support for Build-Options: build-arch
Date: Tue, 6 Nov 2007 11:40:07 +0100
On Sun, Nov 04, 2007 at 07:41:21PM +0000, Ian Jackson wrote:
> > > The package should declare (eg with
> > > Build-Options) what the situation is.
> > 
> > My patch does that.
> 
> Ah, yes.
> 
> Bill, can you give me a reference to what you consider the definitive
> definition of the behaviour of your proposed patch ?  Presumably this
> would be in the form of a policy amendment ?

After those four years, I am bit lost myself.
This is what I wrote at the time:

+       <sect1 id="f-Build-Options">
+       <heading><tt>Build-Options</tt></heading>
+       <p>
+          The syntax is a list of options separated by
+         commas that are implemented in the build process.
+          The following options are defined:
+          <list>
+            <item> <tt>build-arch</tt> The optional targets "build-arch"
+                and "build-indep" are implemented by <tt>debian/rules</tt>
+                as defined in <ref id="debianrules">.  </item>
+          </list>
+       </p>
+       </sect1>

Some comments:

1) The target binary-arch and binary-indep are already mandatory according to
debian-policy. No need to mention them.

2) Build-Options should ideally use the same separator/line breaking rule as 
Depends (packages name being replaced by options). I will let you fill
the specific. My patch only implement commas separation, but since only
build-arch is implemented, this is not a practical issue.

This option signals a property of the source package, but not the
associated behaviour of dpkg-buildpackage. Obviously a patch to
dpkg-buildpackage should document that. This is my first try:

1) Unreckognized Build-Options are ignored by dpkg.

2) The following option is reckognized:
  build-arch: If this option is set, dpkg-buildpackage, when invoked
with the -B option, will call 'debian/rules build-arch' instead of
'debian/rules build'.

Cheers,
Bill.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org, lucas@debian.org, vorlon@debian.org
Subject: Re: Bug#229357: Can we require build-arch/indep targets for lenny?
Date: Sat, 19 Jan 2008 18:38:58 +0100
On Sat, 13 Oct 2007, Frank Lichtenheld wrote:
> 1) Build-Options field
> 
> As pointed out this doesn't scale very well and there is no real way to
> make it default behaviour one day. This would be the way to go though if
> it only needs to be specified for few packages (either because we think
> that few packages actually need build-arch support or because of the
> solution I propose below, combining it with autodetection).

IMO combining Build-Options and Standards-Version could be enough to get
the best of both worlds. Use Build-Options to declare that the package
supports some "should" rules of the policy but also auto-set some flags
based on the version of the policy: if it's greater than the version which
changed a rule in a "must", then we define the corresponding flag.

That way maintainers don't have to carry dozen of options indefinitely.

> I would be interested to gather some input from the interested persons
> regarding their exact position. I think the following questions should
> give us a good understanding or their position:
> (want == 'I want it and I also think it would be possible to do')
> 
>  1) Do you want to change sbuild to actually respect policy?

Yes.

>  1a) (SKIP if 'no' to 1) Before lenny's release?

I don't mind.

>  3) Do you want for all packages to support build-arch in the
>     nearer future (longest lenny+1) [== policy 'must']?
>  4) (SKIP if 'yes' to 3) In the farer future?

I think it makes sense in the long term, yes.

>  5) Do you think autodetection can work and should be used?

I must say I'm not very convinced by the various tricks tried and
suggested. That said I wouldn't oppose all of them either.

>  6) (SKIP if 'yes' to 5) Do you think that autodetection can
>     work and should be used, if packages would have the ability
>     to override it if they know they get detected wrong?

Seems reasonable, but you still have to let them declare if they support
the target build-arch if they declare "skip-auto-detection". :-)

So basically the process would be:
- if Build-Options contains build-arch, call build-arch/indep
- unless Build-Options contains "skip-auto-detection" (or whatever name we
  come by), do an auto-detection and call build-arch/indep
- otherwise you have to call "build"

> After considering all the arguments I believe that the best solution
> would be to try to implement autodetection _and_ support Build-Options
> to give maintainers the ability to override it. Build-Options is simply
> the easiest and best-working possibility, but for good behaving packages
> it should not be neccessary. And I strongly believe that after lenny's
> release dpkg-buildpackage should start to check the 'correct'
> build-dependencies according to policy (i.e. requiring b-d-i if
> build-arch is not supported).
> 
> I would volunteer to implement the solution I propose (in the near
> future) if there are enough supporters.

Ack from me at least. It's time to take a decision here. First step is to
add the Build-Options support IMO.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Felipe Sateler <fsateler@gmail.com>
To: 229357@bugs.debian.org
Subject: Am I missing something?
Date: Thu, 14 Feb 2008 01:49:09 -0300
[Message part 1 (text/plain, inline)]
Why is it taking so long implement Build-Options? It seems to me that the 
implementation is trivial: right before actually doing something (ie: 
checking build-dependencies), check for the Build-Options (plus adding it to 
the legal fields). The attached patch does that. 
Or is there some other stuff to do?

-- 
Felipe Sateler
[0001-Add-support-for-Build-Options.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Felipe Sateler <fsateler@gmail.com>
To: 229357@bugs.debian.org
Subject: Build-Options
Date: Wed, 19 Mar 2008 22:56:26 -0300
[Message part 1 (text/plain, inline)]
Attaching a newer version of the patch that does a better search for the 
options. The search should be put probably on a subroutine, but I'm not 
really sure where, and there is only one build option for now, so it's not a 
major problem.

-- 
Felipe Sateler
[0001-Add-support-for-Build-Options.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Merged 229357 398625 479556. Request was from Roger Leigh <rleigh@whinlatter.ukfsn.org> to control@bugs.debian.org. (Mon, 05 May 2008 18:18:06 GMT) Full text and rfc822 format available.

Blocking bugs of 474413 added: 479556, 229357, and 398625 Request was from Roger Leigh <rleigh@whinlatter.ukfsn.org> to control@bugs.debian.org. (Mon, 05 May 2008 18:18:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Felipe Sateler <fsateler@gmail.com>
To: 229357@bugs.debian.org
Subject: Re: Build-Options
Date: Sat, 21 Jun 2008 16:59:02 -0400
[Message part 1 (text/plain, inline)]
Attaching a version against current master (since this can't make it to lenny 
anyway). 

PS: an (N)ACK would be nice.

Saludos,
Felipe Sateler
[0001-Add-support-for-Build-Options.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org
Cc: djpig@debian.org
Subject: Re: Bug#229357: Build-Options
Date: Sun, 22 Jun 2008 11:15:02 +0200
Hi,

On Sat, 21 Jun 2008, Felipe Sateler wrote:
> Attaching a version against current master (since this can't make it to lenny 
> anyway). 
> 
> PS: an (N)ACK would be nice.

We have received your patch. Your patch would be even better if it was
complete: please update the documentation of dpkg-buildpackage accordingly.
But I have some other remarks, see below.

Last time we discussed this idea within the team, Frank wanted to 
handle it, but it's been a long time since we had this discussion. Frank,
do you still have time/plans for this?

> +my $source = Dpkg::Control->new()->get_source();
> +if (defined($source->{"Build-Options"}) ) {
> +    # The build options are comma-separated, with optional spaces
> +    my @build_options = split( / *, */, $source->{"Build-Options"} );

Please use "\s*,\s*".

> +    if( grep(/\bbuild-arch\b/, @build_options) && $binaryonly eq "-B") {

Please match the keyword in its entirety: /^build-arch$/

> +	$buildtarget = "build-arch";
> +    }
> +}

As we will probably add more Build-Options over time, we probably want to
move this processing in a dedicated module... but we already have
Dpkg::BuildOptions which handles DEB_BUILD_OPTIONS.

I don't know if we want to put both in the same module or if we need to
come up with a different name (or a sub-module maybe).

The discussion in the bug log also suggest to use Standards-Version as a
source of implicit "build-options". If policy 4.0 mandates the build-arch
target, then the simple fact that Standards-Version >= 4.0 can be assumed
as having Build-Options: build-arch. I like this idea and would like to
see it implemented in this patch.

(Yes there are reasons why your seemingly simple patch dit not yet got
merged, and I'm sorry for my lack of explanation up to now)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Felipe Sateler <fsateler@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 229357@bugs.debian.org, djpig@debian.org
Subject: Re: Bug#229357: Build-Options
Date: Sun, 22 Jun 2008 20:14:01 -0400
[Message part 1 (text/plain, inline)]
El 22/06/08 05:15 Raphael Hertzog escribió:
> Hi,
>
> On Sat, 21 Jun 2008, Felipe Sateler wrote:
> > Attaching a version against current master (since this can't make it to
> > lenny anyway).
> >
> > PS: an (N)ACK would be nice.
>
> We have received your patch.

Thanks for the response.

> Your patch would be even better if it was 
> complete: please update the documentation of dpkg-buildpackage accordingly.

OK. This means editing man/dpkg-buildpackage.1?

> But I have some other remarks, see below.
>
> Last time we discussed this idea within the team, Frank wanted to
> handle it, but it's been a long time since we had this discussion. Frank,
> do you still have time/plans for this?
>
> > +my $source = Dpkg::Control->new()->get_source();
> > +if (defined($source->{"Build-Options"}) ) {
> > +    # The build options are comma-separated, with optional spaces
> > +    my @build_options = split( / *, */, $source->{"Build-Options"} );
>
> Please use "\s*,\s*".
>
> > +    if( grep(/\bbuild-arch\b/, @build_options) && $binaryonly eq "-B") {
>
> Please match the keyword in its entirety: /^build-arch$/

Both done (locally, I will submit again when the documentation is done).

>
> > +	$buildtarget = "build-arch";
> > +    }
> > +}
>
> As we will probably add more Build-Options over time, we probably want to
> move this processing in a dedicated module... but we already have
> Dpkg::BuildOptions which handles DEB_BUILD_OPTIONS.
>
> I don't know if we want to put both in the same module or if we need to
> come up with a different name (or a sub-module maybe).

I can try doing this, although I couldn't find an appropriate name (perhaps 
Source::BuildOptions?). The idea would be to add one function per build 
option, or one function that processes them all? I think it's best to do one 
function per build option, since an option can touch any part of the process.

>
> The discussion in the bug log also suggest to use Standards-Version as a
> source of implicit "build-options". If policy 4.0 mandates the build-arch
> target, then the simple fact that Standards-Version >= 4.0 can be assumed
> as having Build-Options: build-arch. I like this idea and would like to
> see it implemented in this patch.

This seems simple enough. I'll try doing this.


Saludos,
Felipe Sateler
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Felipe Sateler <fsateler@gmail.com>
Cc: 229357@bugs.debian.org, djpig@debian.org
Subject: Re: Bug#229357: Build-Options
Date: Mon, 23 Jun 2008 08:37:15 +0200
On Sun, 22 Jun 2008, Felipe Sateler wrote:
> > Your patch would be even better if it was 
> > complete: please update the documentation of dpkg-buildpackage accordingly.
> 
> OK. This means editing man/dpkg-buildpackage.1?

Yes.

> > I don't know if we want to put both in the same module or if we need to
> > come up with a different name (or a sub-module maybe).
> 
> I can try doing this, although I couldn't find an appropriate name (perhaps 
> Source::BuildOptions?). The idea would be to add one function per build 
> option, or one function that processes them all? I think it's best to do one 
> function per build option, since an option can touch any part of the process.

I'm not yet 100% sure what the best design is. I think both
DEB_BUILD_OPTIONS and Build-Options are going to be closely tied anyway...
Build-Options is a way to express that the package supports a set
of functionalities and often those will be enabled through a keyword
in DEB_BUILD_OPTIONS.

As such, it probably makes sense to add support for both in the same
module but with different commands to allow checking one set or the other
or both.

Ideally the module a has a list of keywords with meta-information that
says where the keyword is allowed/expected, if it accepts a value
(keyword=value, like parallel=4), if it represents a "supported feature"
(always to be found in Build-Options:) or a "request to enable" something
specific (usually in DEB_BUILD_OPTIONS, but could also be in Build-Options
maybe). Here you would also put the minimal Standards-Version where the
feature can be considered as always supported (unless there's an opposite
keyword "no-<keyword>" in the list).

This will require refactoring of the module and thus also of its
associated test suite (scripts/t/300_Dpkg_BuildOptions.t) (and of
dpkg-buildpackage that uses it already).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Felipe Sateler <fsateler@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 229357@bugs.debian.org, djpig@debian.org
Subject: Re: Bug#229357: Build-Options
Date: Mon, 23 Jun 2008 09:45:28 -0400
[Message part 1 (text/plain, inline)]
El 23/06/08 02:37 Raphael Hertzog escribió:

> > > I don't know if we want to put both in the same module or if we need to
> > > come up with a different name (or a sub-module maybe).
> >
> > I can try doing this, although I couldn't find an appropriate name
> > (perhaps Source::BuildOptions?). The idea would be to add one function
> > per build option, or one function that processes them all? I think it's
> > best to do one function per build option, since an option can touch any
> > part of the process.
>
> I'm not yet 100% sure what the best design is. I think both
> DEB_BUILD_OPTIONS and Build-Options are going to be closely tied anyway...
> Build-Options is a way to express that the package supports a set
> of functionalities and often those will be enabled through a keyword
> in DEB_BUILD_OPTIONS.
>
> As such, it probably makes sense to add support for both in the same
> module but with different commands to allow checking one set or the other
> or both.

I'm not really sure this is a good idea. The way I see it, Build-Options is 
most useful for declaring that the package handles something that would break 
a normal package (such as build-arch). Thus, I think they will be boolean (or 
should, at least: I don't see the usefulness of parallel=n in Build-Options). 
DEB_BUILD_OPTIONS doesn't have these characteristics, as a package that 
doesn't handle a given option simply ignores it, and that options can have 
any type. As such, I think it is a good idea to provide separate modules, 
since it makes the Build-Options support simpler.


Saludos,
Felipe Sateler
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Felipe Sateler <fsateler@gmail.com>
Cc: 229357@bugs.debian.org, djpig@debian.org
Subject: Re: Bug#229357: Build-Options
Date: Mon, 23 Jun 2008 16:20:50 +0200
On Mon, 23 Jun 2008, Felipe Sateler wrote:
> > As such, it probably makes sense to add support for both in the same
> > module but with different commands to allow checking one set or the other
> > or both.
> 
> I'm not really sure this is a good idea. The way I see it, Build-Options is 
> most useful for declaring that the package handles something that would break 
> a normal package (such as build-arch). Thus, I think they will be boolean (or 
> should, at least: I don't see the usefulness of parallel=n in Build-Options). 

parellel=n was not the best example, but it could have been "maxparallel=n" for
instance to indicate a limit on what it supports. Or maybe it could be
"supported_flavors=gtk,kde,both" to explain us that we can use
DEB_BUILD_OPTIONS="flavor=gtk" to build a gtk-only flavor of the package.

In any case, I don't think it's wise to arbitrarily limit the use cases
of those options and as such I'd prefer something that supports those
richer semantics.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Felipe Sateler <fsateler@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 229357@bugs.debian.org, djpig@debian.org
Subject: Re: Bug#229357: Build-Options
Date: Mon, 23 Jun 2008 11:13:21 -0400
[Message part 1 (text/plain, inline)]
El 23/06/08 09:45 Felipe Sateler escribió:
> El 23/06/08 02:37 Raphael Hertzog escribió:
> > > > I don't know if we want to put both in the same module or if we need
> > > > to come up with a different name (or a sub-module maybe).
> > >
> > > I can try doing this, although I couldn't find an appropriate name
> > > (perhaps Source::BuildOptions?). The idea would be to add one function
> > > per build option, or one function that processes them all? I think it's
> > > best to do one function per build option, since an option can touch any
> > > part of the process.
> >
> > I'm not yet 100% sure what the best design is. I think both
> > DEB_BUILD_OPTIONS and Build-Options are going to be closely tied
> > anyway... Build-Options is a way to express that the package supports a
> > set of functionalities and often those will be enabled through a keyword
> > in DEB_BUILD_OPTIONS.
> >
> > As such, it probably makes sense to add support for both in the same
> > module but with different commands to allow checking one set or the other
> > or both.
>
> I'm not really sure this is a good idea. The way I see it, Build-Options is
> most useful for declaring that the package handles something that would
> break a normal package (such as build-arch). Thus, I think they will be
> boolean (or should, at least: I don't see the usefulness of parallel=n in
> Build-Options). DEB_BUILD_OPTIONS doesn't have these characteristics, as a
> package that doesn't handle a given option simply ignores it, and that
> options can have any type. As such, I think it is a good idea to provide
> separate modules, since it makes the Build-Options support simpler.

Also, there is another important difference: Build-Options are specified by 
the package, while DEB_BUILD_OPTIONS are specified by the builder. I think it 
can be confusing if both are in the same module.


Saludos,
Felipe Sateler
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: debian-dpkg@lists.debian.org
Cc: 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Felipe Sateler <fsateler@gmail.com>, Kees Cook <kees@outflux.net>
Subject: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 00:02:33 +0200
[Message part 1 (text/plain, inline)]
Hello,

in order to fix #229357 I decided to add a new Build-Options field.
I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
And I added support for a build-arch option, that if present, will let
dpkg-buildpackage call debian/rules build-arch and build-indep.

It's not obvious that this was the right choice when you think of the
currently existing build options but once you start thinking of possible
additions (as requested in #489771), it becomes more evident that it makes
sense. Even if some build options should really only be used in
the field while others should only be used in the environment variable,
the possibility to override the former with the latter is nice.

The current patchset is available in my public repository but I'll attach
it as well so that you can easily review it. I intend to merge it this
week-end after some tests but feel free to test and comment in the mean
time.

http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug229357-build-options

The patchset only applies on top of master.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
[0001-Refactor-Dpkg-BuildOptions-to-handle-Build-Options.patch (text/x-diff, attachment)]
[0002-dpkg-buildpackage-use-build-arch-indep-target.-Clos.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Felipe Sateler <fsateler@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Felipe Sateler <fsateler@gmail.com>
To: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Thu, 10 Jul 2008 19:19:16 -0400
[Message part 1 (text/plain, inline)]
El 10/07/08 18:02 Raphael Hertzog escribió:
> Hello,
>
> in order to fix #229357 I decided to add a new Build-Options field.
> I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> And I added support for a build-arch option, that if present, will let
> dpkg-buildpackage call debian/rules build-arch and build-indep.
>
> It's not obvious that this was the right choice when you think of the
> currently existing build options but once you start thinking of possible
> additions (as requested in #489771), it becomes more evident that it makes
> sense. Even if some build options should really only be used in
> the field while others should only be used in the environment variable,
> the possibility to override the former with the latter is nice.

I'm not really sure this is right. There are two things that we want to do 
here: declare that a package supports something, and asking the package to do 
something. This difference is blurred now, and I think it is confusing.
OTOH, it gives the benefit of being able to ignore the package capabilities 
via the environment (ie, unset a given option).
I fear it will give rise to abuses such as setting parallel=n in the control 
file.


Saludos,
Felipe Sateler
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Felipe Sateler <fsateler@gmail.com>
Cc: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 09:10:41 +0200
On Thu, 10 Jul 2008, Felipe Sateler wrote:
> El 10/07/08 18:02 Raphael Hertzog escribió:
> > Hello,
> >
> > in order to fix #229357 I decided to add a new Build-Options field.
> > I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> > And I added support for a build-arch option, that if present, will let
> > dpkg-buildpackage call debian/rules build-arch and build-indep.
> >
> > It's not obvious that this was the right choice when you think of the
> > currently existing build options but once you start thinking of possible
> > additions (as requested in #489771), it becomes more evident that it makes
> > sense. Even if some build options should really only be used in
> > the field while others should only be used in the environment variable,
> > the possibility to override the former with the latter is nice.
> 
> I'm not really sure this is right. There are two things that we want to do 
> here: declare that a package supports something, and asking the package to do 
> something. This difference is blurred now, and I think it is confusing.

Even if there's only two things, the fact is that the package maintainer
wants not only to decide what is supported but he might also want to
enable some features... if you check the case that I listed above, we also
want to use Build-Options to _enable_ specific hardening measures. Because
the maintainer knows best which hardening measures should be enabled. But
we also want the builder to be able to override them for example to test
if the package now supports a previously disabled hardening measure.

The meaning of each build options is specific to each, there's no global
rule that works for all cases. That's why we have documentation of each
option in dpkg-buildpackage.

> I fear it will give rise to abuses such as setting parallel=n in the control 
> file.

There are dozens of ways to "abuse" any interface if you choose to use
it in a way that contradicts the documentation. But that's not a reason
to limit the flexibility offered by an interface.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Felipe Sateler <fsateler@gmail.com>
Cc: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 11:49:07 +0200
On Thu, Jul 10, 2008 at 07:19:16PM -0400, Felipe Sateler wrote:
> El 10/07/08 18:02 Raphael Hertzog escribió:
> > Hello,
> >
> > in order to fix #229357 I decided to add a new Build-Options field.
> > I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
> > And I added support for a build-arch option, that if present, will let
> > dpkg-buildpackage call debian/rules build-arch and build-indep.
> >
> > It's not obvious that this was the right choice when you think of the

Maybe it is not obvious, but since noone proposed another working
solution in the ten years this issue exists, there is no alternative.

> > currently existing build options but once you start thinking of possible
> > additions (as requested in #489771), it becomes more evident that it makes
> > sense. Even if some build options should really only be used in
> > the field while others should only be used in the environment variable,
> > the possibility to override the former with the latter is nice.
> 
> I'm not really sure this is right. There are two things that we want to do 
> here: declare that a package supports something, and asking the package to do 
> something. This difference is blurred now, and I think it is confusing.
> OTOH, it gives the benefit of being able to ignore the package capabilities 
> via the environment (ie, unset a given option).
> I fear it will give rise to abuses such as setting parallel=n in the control 
> file.

I concur. This also create a namespace problem by conflating the
'Build-Options' namespace with the DEB_BUILD_OPTIONS namespace.
Since a developer can put virtually anything in DEB_BUILD_OPTIONS
(and check for it in debian/rules) even if it is not mentionned 
in policy, this is a real issue.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Felipe Sateler <fsateler@gmail.com>
Cc: debian-dpkg@lists.debian.org, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Fri, 11 Jul 2008 09:47:51 -0700
Raphael Hertzog <hertzog@debian.org> writes:

> Even if there's only two things, the fact is that the package maintainer
> wants not only to decide what is supported but he might also want to
> enable some features... if you check the case that I listed above, we
> also want to use Build-Options to _enable_ specific hardening
> measures. Because the maintainer knows best which hardening measures
> should be enabled. But we also want the builder to be able to override
> them for example to test if the package now supports a previously
> disabled hardening measure.

This doesn't make sense to me.  The maintainer writes debian/rules; why
would they need to change Build-Options in debian/control to enable
anything about the build?

I'd rather see Build-Options in debian/control be clearly defined as
capabilities that the package supports and not used as a substitute for
the existing DEB_BUILD_OPTIONS method of controlling what the build does
in practice.  (And I'd prefer it to be called Build-Options-Supported or
something along those lines.)  I think this still fits for #489771; the
presence of the hardening option in Build-Options-Supported indicates that
the package can usefully be built with hardening (it doesn't cause the
package build to break or the binaries to malfunction).  If the package
maintainer wants the package to always be built with those options, they
should make that change directly in debian/rules, not via this method.
They're going to have to test each flag that goes into the hardening
options separately anyway to make sure that it works (the current proposed
hardening flags break many packages, and if you follow debian/changelog
files, you'll see that many maintainers have added them blindly and then
had to roll back when they break).

Using a debian/control field to set DEB_BUILD_OPTIONS in dpkg-buildpackage
is a solution looking for a problem, IMO, and I'd rather not see that
tangled up with the much-needed problem of specifying which options a
package supports and finally dealing with the whole build-arch/build-indep
mess.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Joey Hess <joeyh@debian.org>, Russ Allbery <rra@debian.org>
Cc: debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Sun, 13 Jul 2008 11:18:05 +0200
Hi,

thanks for your answers.

On Fri, 11 Jul 2008, Joey Hess wrote:
> Raphael Hertzog wrote:
> > Even if there's only two things, the fact is that the package maintainer
> > wants not only to decide what is supported but he might also want to
> > enable some features...
> 
> Did you think about having two fields, one to specify the set of
> supported options, and one to allow setting defaults?

This might be possible but the limit is not always very clear: in the case
of build-arch, the simple fact that it's supported means that it's enabled
by default. 

It doesn't really make sense to require the maintainer to put it in
Build-Options-Supported and also in Build-Options.

> For some types of options, it makes sense to not just declare that
> they're supported, but that some particular combinations of options is
> supported, while declaring other combinations as unsupported. This would
> be particularly useful when setting compile options (including librarary
> link combinations).

You're thinking of options in terms of configure flags, is that right?
--with-mysql might be incompatible with --with-postgresql but both might
coexist with yet another feature.

I'm not sure I want to go that far in the logic of Build-Options. I
certainly would consider nice to have a sort of "flavor" mechanism
where the maintainer can propose various combinations of options.

Build-Options-Supported: flavor=mysql,postgresql,oracle,all
Build-Options-Default: flavor=all

But we could also express this with:
Build-Options: possible-flavor=mysql,postgresql,oracle,all
 default-flavor=all

(Well the set of prefix can be discussed and set in stone, exactly like
I have used the "no-" prefix to disable an option previously set)

> Also, I think it would be a good idea to explicitly make "x-foo" be
> reserved for non-standard options.

Fine.

On Fri, 11 Jul 2008, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > Even if there's only two things, the fact is that the package maintainer
> > wants not only to decide what is supported but he might also want to
> > enable some features... if you check the case that I listed above, we
> > also want to use Build-Options to _enable_ specific hardening
> > measures. Because the maintainer knows best which hardening measures
> > should be enabled. But we also want the builder to be able to override
> > them for example to test if the package now supports a previously
> > disabled hardening measure.
> 
> This doesn't make sense to me.  The maintainer writes debian/rules; why
> would they need to change Build-Options in debian/control to enable
> anything about the build?

Because they want that anyone can easily rebuild it with that option
disabled?

> I'd rather see Build-Options in debian/control be clearly defined as
> capabilities that the package supports and not used as a substitute for
> the existing DEB_BUILD_OPTIONS method of controlling what the build does
> in practice.  (And I'd prefer it to be called Build-Options-Supported or
> something along those lines.)  I think this still fits for #489771; the
> presence of the hardening option in Build-Options-Supported indicates that
> the package can usefully be built with hardening (it doesn't cause the
> package build to break or the binaries to malfunction).  

Separating the two meanings is always possible, see above for a
discussion.

> If the package maintainer wants the package to always be built with
> those options, they should make that change directly in debian/rules,
> not via this method.

Why? (and it's not "always", it's by _default_)

I find it rather nice that we have a common way to enable this for all
packages: add a hardening-wrapper to Build-Depends, add the option
indicating which of the hardenings flags to enable, and you're done
and it works for all packages.

Of course, you can also set the right variables in debian/rules directly
but then you make it complex for anyone to disable those build options
(for example to verify if a failure can be attributed to one of these
hardening options).

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Sun, 13 Jul 2008 11:31:45 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Fri, 11 Jul 2008, Russ Allbery wrote:

>> This doesn't make sense to me.  The maintainer writes debian/rules; why
>> would they need to change Build-Options in debian/control to enable
>> anything about the build?

> Because they want that anyone can easily rebuild it with that option
> disabled?

That is already supported using the existing DEB_BUILD_OPTIONS mechanism.

I may be confused about your mental model here, but it seems like you're
moving rules about how the package is built from the package itself into
dpkg-buildpackage.  If that's really what's happening, I think that is a
truly dreadful idea and strongly object.  It should be possible to build
the package using whatever flags and options are the default by running
debian/rules build without involving dpkg-buildpackage at all, which
implies that the package should not be relying on dpkg-buildpackage to
provide compiler and linker flags.  Those defaults should be in
debian/rules, just as they always have been for Debian packages.

If some set of flags, such as hardening, should be possible to easily
disable, this is exactly the same case as we have right now with
optimization and with stripping.  The way to support that is to specify
another DEB_BUILD_OPTIONS flag which, if set, instructs the package to
modify its behavior accordingly.  Furthermore, that allows the package
maintainer to provide more useful defaults specific to that package, such
as exactly the hardening flags that *that* package supports, rather than
some default (and possibly changing) set from dpkg-buildpackage.

DEB_BUILD_OPTIONS then stays clearly semantically separate from the
Build-Options-Supported field; the latter specifies which interfaces the
package supports, and the former is the way to actually *use* those
interfaces, with some exceptions for interfaces that can be used other
ways (such as build-arch/build-indep).

>> If the package maintainer wants the package to always be built with
>> those options, they should make that change directly in debian/rules,
>> not via this method.

> Why? (and it's not "always", it's by _default_)

See above.  By moving the logic from debian/rules into dpkg-buildpackage,
we would be breaking a common workflow when working with packages.
Running debian/rules build in an unpacked source package to test would no
longer be a reasonable development step since you may get a completely
different compile than dpkg-buildpackage would give you.

I think the way that optimization and stripping are handled right now
works fairly well in practice, and I think we should be building on that
as a model, not replacing it with some entirely different method that
relies on additional external programs to wrap debian/rules.

The choice between always and by default can be handled using the existing
DEB_BUILD_OPTIONS mechanism just as optimization and stripping are now.

> I find it rather nice that we have a common way to enable this for all
> packages: add a hardening-wrapper to Build-Depends, add the option
> indicating which of the hardenings flags to enable, and you're done and
> it works for all packages.

Instead of doing that, you add hardening-wrapper to Build-Depends and
modify debian/rules to invoke it.  The process is just as simple.

> Of course, you can also set the right variables in debian/rules directly
> but then you make it complex for anyone to disable those build options
> (for example to verify if a failure can be attributed to one of these
> hardening options).

Not if you implement a DEB_BUILD_OPTIONS flag at the same time.  You can
then make hardening-wrapper trigger off of the DEB_BUILD_OPTIONS flag and
the package maintainer doesn't even have to handle it directly (very
similar to how debhelper packages let dh_strip handle DEB_BUILD_OPTIONS
for that flag).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Mon, 14 Jul 2008 21:47:02 +0200
On Sun, 13 Jul 2008, Russ Allbery wrote:
> > Because they want that anyone can easily rebuild it with that option
> > disabled?
> 
> That is already supported using the existing DEB_BUILD_OPTIONS mechanism.
> 
> I may be confused about your mental model here, but it seems like you're
> moving rules about how the package is built from the package itself into
> dpkg-buildpackage.  If that's really what's happening, I think that is a
> truly dreadful idea and strongly object.  It should be possible to build
> the package using whatever flags and options are the default by running
> debian/rules build without involving dpkg-buildpackage at all, which
> implies that the package should not be relying on dpkg-buildpackage to
> provide compiler and linker flags.  Those defaults should be in
> debian/rules, just as they always have been for Debian packages.

I think we're already on that path for quite some time. If your package
uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting
them for you (with dpkg-architecture). The same is expected with default
values of builder/linker flags now that dpkg-buildpackage provides
reasonable defaults.

So yes, I'm somehow building on this model where dpkg-buildpackage can
simplify the work of packager by providing some distribution-wide
reasonable defaults.

People have noticed that and already requested that we can call arbitrary
targets of debian/rules with all the proper initialization done precisely
for test purpose during packaging work (see #477916).

> If some set of flags, such as hardening, should be possible to easily
> disable, this is exactly the same case as we have right now with
> optimization and with stripping.  The way to support that is to specify
> another DEB_BUILD_OPTIONS flag which, if set, instructs the package to
> modify its behavior accordingly.  Furthermore, that allows the package
> maintainer to provide more useful defaults specific to that package, such
> as exactly the hardening flags that *that* package supports, rather than
> some default (and possibly changing) set from dpkg-buildpackage.

Ok makes sense. In the case of hardening, it means that we have to modify
each and every package to enable it though. I suppose that the people
pushing this proposal would like to have the option to enable it globally
and have broken packages opt out and/or disable specific hardening
options.

Without taking into account the specific risks associated to any default
activation of build hardening, I find that having a generic system where
you can start early with an opt-in policy, have the stuff matures, and
switch to an opt-out policy later can make sense (if that plan is
announced early and that people know by advance how to opt-out
explicitely).

> See above.  By moving the logic from debian/rules into dpkg-buildpackage,
> we would be breaking a common workflow when working with packages.
> Running debian/rules build in an unpacked source package to test would no
> longer be a reasonable development step since you may get a completely
> different compile than dpkg-buildpackage would give you.

That might be so, but I'm not sure why it would be a major problem. It
can take some time to change habits but unless you see real drawbacks, I'm
not convinced that there are good reasons to revert in that direction.

> I think the way that optimization and stripping are handled right now
> works fairly well in practice, and I think we should be building on that
> as a model, not replacing it with some entirely different method that
> relies on additional external programs to wrap debian/rules.
> 
> The choice between always and by default can be handled using the existing
> DEB_BUILD_OPTIONS mechanism just as optimization and stripping are now.

Well, right now buildd do not use DEB_BUILD_OPTIONS at all AFAIK. So
there's no way to enable anything globally with this method in practice.

And I certainly wouldn't want to have to manually set DEB_BUILD_OPTIONS to
get a build similar to what the buildd would do.

The current practice only has options to disable something that
is enabled by default. I'm not sure you can usefully build on that
to provide a mechanism where something is disabled by default and that
can be enabled either by the maintainer or by the builder.

But maybe such a scheme is not desirable in general, we might not want
to offer any option for the builder that has not been validated by the
maintainer. I don't know. Maybe we won't have any other situation similar
to the hardening one and it's over-kill to try to generalize it.


the

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Mon, 14 Jul 2008 13:22:58 -0700
Raphael Hertzog <hertzog@debian.org> writes:

> I think we're already on that path for quite some time. If your package
> uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting
> them for you (with dpkg-architecture).

I most certainly do not rely on dpkg-buildpackage setting anything.  I
call dpkg-architecture directly, which is also what's in our best practice
documents.

DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

I would consider packages that didn't do that and just assumed that those
variables were already set to be buggy.

> The same is expected with default values of builder/linker flags now
> that dpkg-buildpackage provides reasonable defaults.

Yeah, that bothered me too.  I made a perhaps poor tactical decision to
not fight about it since it seemed that it had a lot of momentum and I
couldn't think of specific problems other than the one that we ran into.
But this is going beyond setting some defaults that are already set in
nearly all of our packages.

> So yes, I'm somehow building on this model where dpkg-buildpackage can
> simplify the work of packager by providing some distribution-wide
> reasonable defaults.
>
> People have noticed that and already requested that we can call arbitrary
> targets of debian/rules with all the proper initialization done precisely
> for test purpose during packaging work (see #477916).

I must say, I really do not like this direction.  debhelper and cdbs and
similar sytsems are the places to provide this help where people want to
use it, in my opinion.  We have a lot of past experience with that and we
have the compatibility level to handle smoothing transitions.  (And to
provide a way for people to never transition, I admit, and I see where
that's the problem that you're solving, but I prefer that problem to the
problems introduced by the instability of having the package build
infrastructure change the input to the builds without coordination with
the package.)

Note that if you're requiring a package to participate by adding something
to Build-Options in debian/control, you have the same transition problem,
so I think that it's pretty equivalent to changing debian/rules; it's only
when you want packages to be able to change with external defaults that
you get the transition advantage.

I don't want to underestimate the transition advantage -- that is pretty
significant.  I do understand the problem that you're trying to solve, and
I understand that what I'm proposing is going to make transitions a lot
harder.

> Ok makes sense. In the case of hardening, it means that we have to
> modify each and every package to enable it though.

Well, not if you can do it via debhelper, which now with version 7 is much
more likely.  Similarly with cdbs.  But in general, yes.

For hardening, I think this is a feature; the flags aren't ones that can
just be applied to every package without breaking things.

> I suppose that the people pushing this proposal would like to have the
> option to enable it globally and have broken packages opt out and/or
> disable specific hardening options.

I think we've already found that this isn't a great approach for hardening
options in particular, since they break too many packages (and those
packages are not necessarily broken; in some cases it's the compiler
that's broken, or the assumptions behind the options).

> Without taking into account the specific risks associated to any default
> activation of build hardening, I find that having a generic system where
> you can start early with an opt-in policy, have the stuff matures, and
> switch to an opt-out policy later can make sense (if that plan is
> announced early and that people know by advance how to opt-out
> explicitely).

I agree with the benefit, but I think it's better to implement that sort
of thing in the packaging tools that already do that sort of magic and
which we already have a way of dealing with (compatibility levels in
debhelper, for example), and which continue to work with debian/rules
build.

>> See above.  By moving the logic from debian/rules into
>> dpkg-buildpackage, we would be breaking a common workflow when working
>> with packages.  Running debian/rules build in an unpacked source
>> package to test would no longer be a reasonable development step since
>> you may get a completely different compile than dpkg-buildpackage would
>> give you.

> That might be so, but I'm not sure why it would be a major problem. It
> can take some time to change habits but unless you see real drawbacks, I'm
> not convinced that there are good reasons to revert in that direction.

I'm somewhat disturbed by this.  Until this discussion, I had no idea that
you were planning on deprecating debian/rules build and expecting everyone
to use dpkg-buildpackage to get a reproducible build.  I'm not even sure
how to use dpkg-buildpackage to do the equivalent of just running
debian/rules build without the binary-* targets.

It seems like this is a significant enough change that it would warrant
Policy changes and a significant announcement in debian-devel-announce,
and I don't think we've had one about the high-level semantic change (but
maybe I missed it?).

> Well, right now buildd do not use DEB_BUILD_OPTIONS at all AFAIK.

I think the buildds should always build packages with the defaults set by
the maintainer of that package.

> The current practice only has options to disable something that
> is enabled by default.

The current practice has options that either disable something *or* enable
something; parallel=N is in the latter category.  DEB_BUILD_OPTIONS is
used to change the defaults, in whichever direction.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Russ Allbery <rra@debian.org>
Cc: Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: New Build-Options field and build-arch option, please review
Date: Wed, 10 Sep 2008 19:47:08 +0200
On Mon, Jul 14, 2008 at 01:22:58PM -0700, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> 
> > I think we're already on that path for quite some time. If your package
> > uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting
> > them for you (with dpkg-architecture).
> 
> I most certainly do not rely on dpkg-buildpackage setting anything.  I
> call dpkg-architecture directly, which is also what's in our best practice
> documents.
> 
> DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
> DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> 
> I would consider packages that didn't do that and just assumed that those
> variables were already set to be buggy.
> 
> > The same is expected with default values of builder/linker flags now
> > that dpkg-buildpackage provides reasonable defaults.
> 
> Yeah, that bothered me too.  I made a perhaps poor tactical decision to
> not fight about it since it seemed that it had a lot of momentum and I
> couldn't think of specific problems other than the one that we ran into.
> But this is going beyond setting some defaults that are already set in
> nearly all of our packages.
> 
> > So yes, I'm somehow building on this model where dpkg-buildpackage can
> > simplify the work of packager by providing some distribution-wide
> > reasonable defaults.
> >
> > People have noticed that and already requested that we can call arbitrary
> > targets of debian/rules with all the proper initialization done precisely
> > for test purpose during packaging work (see #477916).
> 
> I must say, I really do not like this direction.  debhelper and cdbs and
> similar sytsems are the places to provide this help where people want to
> use it, in my opinion.  We have a lot of past experience with that and we
> have the compatibility level to handle smoothing transitions.  (And to
> provide a way for people to never transition, I admit, and I see where
> that's the problem that you're solving, but I prefer that problem to the
> problems introduced by the instability of having the package build
> infrastructure change the input to the builds without coordination with
> the package.)

I like to say I concurr with Russ. There are some much difference
between packages that distributions wide default does not make sense.
Such change would rather lead me to hardcode values of
DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: Russ Allbery <rra@debian.org>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 08:46:05 +0200
On Wed, 10 Sep 2008, Bill Allombert wrote:
> > > People have noticed that and already requested that we can call arbitrary
> > > targets of debian/rules with all the proper initialization done precisely
> > > for test purpose during packaging work (see #477916).
> > 
> > I must say, I really do not like this direction.  debhelper and cdbs and
> > similar sytsems are the places to provide this help where people want to
> > use it, in my opinion.  We have a lot of past experience with that and we
> > have the compatibility level to handle smoothing transitions.  (And to
> > provide a way for people to never transition, I admit, and I see where
> > that's the problem that you're solving, but I prefer that problem to the
> > problems introduced by the instability of having the package build
> > infrastructure change the input to the builds without coordination with
> > the package.)
> 
> I like to say I concurr with Russ. There are some much difference
> between packages that distributions wide default does not make sense.
> Such change would rather lead me to hardcode values of
> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.

But more and more people want to be able to change distribution wide
default: Emdebian wants to enable "nodocs" and "nocheck" by default, other
want to be able to enable hardening options by default and I agree with
them that official support for such a facility is desirable.

See also #498355 and #498380 for such requests from Emdebian.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Neil Williams <codehelp@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Russ Allbery <rra@debian.org>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 10:08:58 +0100
[Message part 1 (text/plain, inline)]
On Thu, 2008-09-11 at 08:46 +0200, Raphael Hertzog wrote:
> On Wed, 10 Sep 2008, Bill Allombert wrote:
> > > > People have noticed that and already requested that we can call arbitrary
> > > > targets of debian/rules with all the proper initialization done precisely
> > > > for test purpose during packaging work (see #477916).
> > > 
> > > I must say, I really do not like this direction.  debhelper and cdbs and
> > > similar sytsems are the places to provide this help where people want to
> > > use it, in my opinion. 

The actual support will be implemented in debhelper - all that is needed
is a consistent manner to pass the same options to debhelper across a
range of packages. Packages then add extra support if necessary, e.g. if
a package installs docs manually instead of using dh_installdocs, then
those sections of debian/rules need to be either conditionally excluded:
ifeq (,$(findstring nodocs,$(DEB_BUILD_OPTIONS)))
        install foo.1 debian/foo/usr/share/man/man1/
        ...
endif

or redone for debhelper support via foo.install files, etc.

After Lenny, I will be filing bugs for this support - at least for the
packages used in Emdebian.

>  We have a lot of past experience with that and we
> > > have the compatibility level to handle smoothing transitions.  (And to
> > > provide a way for people to never transition, I admit, and I see where
> > > that's the problem that you're solving, but I prefer that problem to the
> > > problems introduced by the instability of having the package build
> > > infrastructure change the input to the builds without coordination with
> > > the package.)

There has to be coordination with the package - the package needs to
support the build option, either explicitly or via debhelper. All CDBS
or any other layer needs to do is pass down the option to make it
accessible to debhelper (usually via DEB_BUILD_OPTIONS).

> > I like to say I concurr with Russ. There are some much difference
> > between packages that distributions wide default does not make sense.

On the contrary, there are clear divisions where distribution-wide build
options do make sense. Raphael correctly identifies nodocs and nocheck
as the current Emdebian distribution-wide build options. nodocs itself
needs to be refined to allow for graded levels of documentation
exclusion and other build options may change the build process itself -
all under the control of the particular package. If the package does not
understand the option, nothing happens.

e.g. Emdebian needs nodocs (or something as broad) that drops
everything, from README and TODO to changelog.gz and manpages during the
build, rather than after downloading. Preferably, nodocs would also lead
to the mandatory compression of copyright to save more space. It is not
new for DEB_BUILD_OPTIONS to break Debian Policy - supporting a
distribution-wide superset of options allows the use of the set to
conform to Emdebian Policy etc.

Other uses of options could use graduations so that examples are dropped
but not the rest, or just manpages or just HTML docs etc. Dpkg Classes
will help with graduations, as long as the distro can afford to remove
the files *after* the package has been downloaded.

> But more and more people want to be able to change distribution wide
> default: Emdebian wants to enable "nodocs" and "nocheck" by default, other
> want to be able to enable hardening options by default and I agree with
> them that official support for such a facility is desirable.
> 
> See also #498355 and #498380 for such requests from Emdebian.

Note also that Ubuntu are interested in supporting distribution-wide
build options.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 10:53:27 -0700
Raphael Hertzog <hertzog@debian.org> writes:
> On Wed, 10 Sep 2008, Bill Allombert wrote:

>> I like to say I concurr with Russ. There are some much difference
>> between packages that distributions wide default does not make sense.
>> Such change would rather lead me to hardcode values of
>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
>
> But more and more people want to be able to change distribution wide
> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> other want to be able to enable hardening options by default and I agree
> with them that official support for such a facility is desirable.

So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
for.  I don't have any objections to that, or even to doing it via
dpkg-buildpackage.

My objection is specifically to having dpkg-buildpackage set a variety of
environment variables *by default*, and then telling package maintainers
that they should rely on those environment variables being set in the
default case.  That breaks the debian/rules interface and requires that
all package builds go through dpkg-buildpackage.  Having dpkg-buildpackage
set environment variables in the non-default case like Emdebian is not a
problem, since for Emdebian builds (for example) Emdebian can decide that
using dpkg-buildpackage or setting the environment variables manually is
required.  There is no existing precedent, and they can make that rule
from scratch.

My concern is for the default build where there *is* an existing precedent
that debian/rules build should work sanely, not for support for special
cases like that where the existing debian/rules interface already doesn't
do the right thing without additional help.

If you are going to go down this path of having dpkg-buildpackage set up
an environment that package maintainers should rely on, you or someone
else on the dpkg team needs to make a debian-devel-announce post making it
clear that debian/rules build is no longer a supported interface for
building packages and using dpkg-buildpackage is required for consistent
behavior.

Right now, I don't think most Debian Developers have any idea what the
implications of these changes are.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Neil Williams <codehelp@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 11 Sep 2008 19:02:33 +0100
[Message part 1 (text/plain, inline)]
On Thu, 2008-09-11 at 10:53 -0700, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> > On Wed, 10 Sep 2008, Bill Allombert wrote:
> 
> >> I like to say I concurr with Russ. There are some much difference
> >> between packages that distributions wide default does not make sense.
> >> Such change would rather lead me to hardcode values of
> >> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
> >
> > But more and more people want to be able to change distribution wide
> > default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> > other want to be able to enable hardening options by default and I agree
> > with them that official support for such a facility is desirable.
> 
> So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
> for.  I don't have any objections to that, or even to doing it via
> dpkg-buildpackage.

That is what DEB_VENDOR seeks to achieve - set it once and it sets the
same options across all builds, in the environment.

This is getting to be a long list of CC: - isn't it worth sending to
debian-devel instead? Goswin von Brederlow and Simon Richter did a lot
of work on this at Extremadura and they aren't on the current CC:.

I'm losing track of all the bugs in the CC: and why they are listed.

> My objection is specifically to having dpkg-buildpackage set a variety of
> environment variables *by default*, and then telling package maintainers
> that they should rely on those environment variables being set in the
> default case. 

If by default you mean Debian, then NO. DEB_BUILD_OPTIONS is empty for
Debian and will continue so.

>  That breaks the debian/rules interface and requires that
> all package builds go through dpkg-buildpackage.  Having dpkg-buildpackage
> set environment variables in the non-default case like Emdebian is not a
> problem, since for Emdebian builds (for example) Emdebian can decide that
> using dpkg-buildpackage or setting the environment variables manually is
> required.  There is no existing precedent, and they can make that rule
> from scratch.

Exactly.

> My concern is for the default build where there *is* an existing precedent
> that debian/rules build should work sanely, not for support for special
> cases like that where the existing debian/rules interface already doesn't
> do the right thing without additional help.
> 
> If you are going to go down this path of having dpkg-buildpackage set up
> an environment that package maintainers should rely on, you or someone
> else on the dpkg team needs to make a debian-devel-announce post making it
> clear that debian/rules build is no longer a supported interface for
> building packages and using dpkg-buildpackage is required for consistent
> behavior.
> 
> Right now, I don't think most Debian Developers have any idea what the
> implications of these changes are.

That's fine. DEB_BUILD_OPTIONS would be empty if DEB_VENDOR is not set
or is set to Debian.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Russ Allbery <rra@debian.org>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 15:03:20 +0200
Russ Allbery <rra@debian.org> writes:

> Raphael Hertzog <hertzog@debian.org> writes:
>> On Wed, 10 Sep 2008, Bill Allombert wrote:
>
>>> I like to say I concurr with Russ. There are some much difference
>>> between packages that distributions wide default does not make sense.
>>> Such change would rather lead me to hardcode values of
>>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
>>
>> But more and more people want to be able to change distribution wide
>> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
>> other want to be able to enable hardening options by default and I agree
>> with them that official support for such a facility is desirable.
>
> So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
> for.  I don't have any objections to that, or even to doing it via
> dpkg-buildpackage.

Setting the environment on a distribution wide level is ugly and
fragile. Too many users will reset the environment in their .bashrc.

Instead the idea was to have a vendor (set in
/etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.

The bugreports relevant for this have 2 solutions:

1) make dpkg-buildpackage use (or tool with equivalent environment
   setting up capabilities) mandatory

2) have debian/rules call something to set DEB_VENDOR and possibly
   more

   E.g. 'include /usr/share/dpkg/Makefile.dpkg'
   or   'DEB_VENDOR        ?= (shell dpkg-vendor -qDEB_VENDOR)
         DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)

The argument against 2 is that is requires every source to be modified
if they want to support vendors whereas 1 only needs some small
modification to dpkg-buildpackage to support calling arbitrary targets
in debian/rules and a change in policy making its use mandatory.

> My objection is specifically to having dpkg-buildpackage set a variety of
> environment variables *by default*, and then telling package maintainers
> that they should rely on those environment variables being set in the
> default case.  That breaks the debian/rules interface and requires that
> all package builds go through dpkg-buildpackage.  Having dpkg-buildpackage
> set environment variables in the non-default case like Emdebian is not a
> problem, since for Emdebian builds (for example) Emdebian can decide that
> using dpkg-buildpackage or setting the environment variables manually is
> required.  There is no existing precedent, and they can make that rule
> from scratch.

Then you have one interface for Debian and one interface for every
other vendor including ubuntu (or option 2 above).

> My concern is for the default build where there *is* an existing precedent
> that debian/rules build should work sanely, not for support for special
> cases like that where the existing debian/rules interface already doesn't
> do the right thing without additional help.
>
> If you are going to go down this path of having dpkg-buildpackage set up
> an environment that package maintainers should rely on, you or someone
> else on the dpkg team needs to make a debian-devel-announce post making it
> clear that debian/rules build is no longer a supported interface for
> building packages and using dpkg-buildpackage is required for consistent
> behavior.

Plus a note in policy clarifying that debian/rules is only an
interface for dpkg-buildpackage but not users.

> Right now, I don't think most Debian Developers have any idea what the
> implications of these changes are.

I have to say i verry rarely do not use debuild. And 99% of the
exceptions are calling debian/rules clean.

MfG
        Goswin

PS: with dpkg-buildpackage setting env vars like it does now you
already have a verry confusing situation.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Kees Cook <kees@outflux.net>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 15:35:26 +0200
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote:
> Russ Allbery <rra@debian.org> writes:
> 
> > Raphael Hertzog <hertzog@debian.org> writes:
> >> On Wed, 10 Sep 2008, Bill Allombert wrote:
> >
> >>> I like to say I concurr with Russ. There are some much difference
> >>> between packages that distributions wide default does not make sense.
> >>> Such change would rather lead me to hardcode values of
> >>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
> >>
> >> But more and more people want to be able to change distribution wide
> >> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> >> other want to be able to enable hardening options by default and I agree
> >> with them that official support for such a facility is desirable.
> >
> > So they should set DEB_BUILD_OPTIONS in the environment.  That's what it's
> > for.  I don't have any objections to that, or even to doing it via
> > dpkg-buildpackage.
> 
> Setting the environment on a distribution wide level is ugly and
> fragile. Too many users will reset the environment in their .bashrc.
> 
> Instead the idea was to have a vendor (set in
> /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
> unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.
> 
> The bugreports relevant for this have 2 solutions:
> 
> 1) make dpkg-buildpackage use (or tool with equivalent environment
>    setting up capabilities) mandatory
> 
> 2) have debian/rules call something to set DEB_VENDOR and possibly
>    more
> 
>    E.g. 'include /usr/share/dpkg/Makefile.dpkg'
>    or   'DEB_VENDOR        ?= (shell dpkg-vendor -qDEB_VENDOR)
>          DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)
> 
> The argument against 2 is that is requires every source to be modified
> if they want to support vendors whereas 1 only needs some small
> modification to dpkg-buildpackage to support calling arbitrary targets
> in debian/rules and a change in policy making its use mandatory.

2) is the right way to proceed for _Debian_. People in a hurry can use 1,
but not us. 

2) imply that packages will not have DEB_VENDOR support unless some
check they support it.

> > Right now, I don't think most Debian Developers have any idea what the
> > implications of these changes are.
> 
> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
directly.

Cheers,
Bill.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Kees Cook <kees@outflux.net>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 17:36:46 +0200
On Thu, 18 Sep 2008, Bill Allombert wrote:
> > I have to say i verry rarely do not use debuild. And 99% of the
> > exceptions are calling debian/rules clean.
> 
> Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
> directly.

This has been fixed already. It calls dpkg-buildpackage now (except if you use
its hook features).

(And I don't see why one way would be more Debianish than the other)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Bill Allombert <ballombe@debian.org>, Kees Cook <kees@outflux.net>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 12:08:21 -0700
Goswin von Brederlow <goswin-v-b@web.de> writes:

> Plus a note in policy clarifying that debian/rules is only an
> interface for dpkg-buildpackage but not users.

Right.  If you want to make this a rule, then we should discuss it, reach
a consensus, document and publicize the change, and so forth.

Right now, I feel like this change is being made as part of dpkg
development, without general recognition of what's happening and without
the corresponding changes to Policy so that DDs know what to expect.  (I
don't think this is *intentional* on your part, more a case of a set of
decisions that all seemed like a good idea at the time but which
cumulatively have a significant impact.)

> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

The hard part of standards isn't the common case.  Currently, debian/rules
is defined as the package build interface, and while most people don't
normally rely on that, we don't know what might break; one of the points
of a standard is to let people rely on it without having to tell you first
what they're doing.

Personally, I use debian/rules build all the time for testing, and would
never have thought to mention it to anyone.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Goswin von Brederlow <goswin-v-b@web.de>, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org, Felipe Sateler <fsateler@gmail.com>, 229357@bugs.debian.org, 489771@bugs.debian.org, Kees Cook <kees@outflux.net>, Russ Allbery <rra@debian.org>
Subject: Re: Bug#489771: New Build-Options field and build-arch option, please review
Date: Thu, 18 Sep 2008 21:23:22 +0200
On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote:
> On Thu, 18 Sep 2008, Bill Allombert wrote:
> > > I have to say i verry rarely do not use debuild. And 99% of the
> > > exceptions are calling debian/rules clean.
> > 
> > Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
> > directly.
> 
> This has been fixed already. It calls dpkg-buildpackage now (except if you use
> its hook features).

So it still call debian/rules directly in some case.

> (And I don't see why one way would be more Debianish than the other)

Neither I do, but then I do not attempt to kill one way in favour of the other.

I would object to a proposal policy making dpkg-buildpackage mandatory
to build packages.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Forcibly Merged 229357 398625 479556 545081. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Fri, 04 Sep 2009 20:39:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Sun, 06 Sep 2009 13:57:19 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 06 Sep 2009 13:57:19 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Zack Weinberg <zackw@panix.com>, 229357@bugs.debian.org
Cc: ballombe@debian.org
Subject: Re: Bug#545081: dpkg-dev: dpkg-buildpackage -B should UNCONDITIONALLY invoke debian/rules build-arch
Date: Sun, 6 Sep 2009 15:46:52 +0200
On Sun, 06 Sep 2009, Bill Allombert wrote:
> Good, good, progress at last. Please find a patch that is a port of the
> old patch.3.0 in the first post of #229357 and implement
> Build-Options: build-arch as specified therein.

First, if Build-Options is not integrated with DEB_BUILD_OPTIONS it should
not have the same name. I suggest Features:, Build-Features: or something similar.

Then, I don't want it to use commas as separator, it should use spaces as
separator like DEB_BUILD_OPTIONS and list of architectures.

To be of any use in other use cases (mainly enabling hardened build
options), it should support having values associated to each feature
(ex: build-arch hardening=a,b,c). Default values for features where one is
not given would be a bonus.

I want to be able to reuse this when I'll write dpkg-buildflags, so
the parsing should be moved outside of dpkg-builpackage, likely in its own
module (somewhat similar to Dpkg::BuildOptions).

And last point, a branch is never ready to be merged if the documentation
is not updated accordingly.

> +$buildtarget='build-arch' if ( $binarytarget == 'binary-arch' && 
> +                               defined($buildoptions{'build-arch'}));
> +

== is wrong as noted by Cyril.

And the change in dpkg-buildpackage should really be similar to what
I did in
http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;h=de4a0d2935201352f3b24382a18b8893d9ae2bdf#patch3

The rest should be outside in a module.

Cheers,
-- 
Raphaël Hertzog




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Tue, 22 Sep 2009 00:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Javier Serrano Polo <jasp00@terra.es>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 22 Sep 2009 00:45:03 GMT) Full text and rfc822 format available.

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

From: Javier Serrano Polo <jasp00@terra.es>
To: 229357@bugs.debian.org
Cc: 229357-submitter@bugs.debian.org
Subject: Re: dpkg-buildpackage: support for Build-Options: build-arch
Date: Tue, 22 Sep 2009 02:38:22 +0200
Could someone explain (again?) why "dpkg-buildpackage -B" should not add
build-arch to DEB_BUILD_OPTIONS? It doesn't require any control fields,
any make fiddling, it's compatible with old rules files... it just
works.





Message sent on to Bill Allombert <ballombe@debian.org>:
Bug#229357. (Tue, 22 Sep 2009 00:45:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Tue, 22 Sep 2009 16:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 22 Sep 2009 16:03:03 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Javier Serrano Polo <jasp00@terra.es>, 229357@bugs.debian.org
Subject: Re: Bug#229357: dpkg-buildpackage: support for Build-Options: build-arch
Date: Tue, 22 Sep 2009 17:57:51 +0200
Hi,

On Tue, 22 Sep 2009, Javier Serrano Polo wrote:
> Could someone explain (again?) why "dpkg-buildpackage -B" should not add
> build-arch to DEB_BUILD_OPTIONS? It doesn't require any control fields,
> any make fiddling, it's compatible with old rules files... it just
> works.

What are you trying to resolve? Adding a new value in an environment
variable doesn't change the behavior of any tool.

This bug is about making dpkg-buildpackage -B or -A call
respectively debian/rules build-arch or debian/rules build-indep (instead
of debian/rules build).

Are you suggesting that the “build” rules of packages should be modified
to not build stuff specific to arch: all packages if DEB_BUILD_OPTIONS
contains build-arch?

Cheers,
-- 
Raphaël Hertzog




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Tue, 22 Sep 2009 16:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Javier Serrano Polo <jasp00@terra.es>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 22 Sep 2009 16:36:03 GMT) Full text and rfc822 format available.

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

From: Javier Serrano Polo <jasp00@terra.es>
To: 229357@bugs.debian.org
Cc: 229357-submitter@bugs.debian.org
Subject: Re: dpkg-buildpackage: support for Build-Options: build-arch
Date: Tue, 22 Sep 2009 18:22:33 +0200
El dt 22 de 09 de 2009 a les 17:57 +0200, en/na Raphael Hertzog va
escriure:
> Are you suggesting that the “build” rules of packages should be modified
> to not build stuff specific to arch: all packages if DEB_BUILD_OPTIONS
> contains build-arch?

Precisely. I'm using these lines:

ifeq (,$(filter build-arch,$(DEB_BUILD_OPTIONS)))
build: build-indep build-arch
else
build: build-arch
endif





Message sent on to Bill Allombert <ballombe@debian.org>:
Bug#229357. (Tue, 22 Sep 2009 16:36:08 GMT) Full text and rfc822 format available.

Removed tag(s) patch. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Thu, 05 Nov 2009 22:42:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Tue, 25 May 2010 21:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 25 May 2010 21:03:03 GMT) Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Zack Weinberg <zackw@panix.com>, 229357@bugs.debian.org, ballombe@debian.org
Subject: Re: Bug#545081: dpkg-dev: dpkg-buildpackage -B should UNCONDITIONALLY invoke debian/rules build-arch
Date: Tue, 25 May 2010 22:59:07 +0200
[Message part 1 (text/plain, inline)]
On Sun, Sep 06, 2009 at 03:46:52PM +0200, Raphael Hertzog wrote:
> On Sun, 06 Sep 2009, Bill Allombert wrote:
> > Good, good, progress at last. Please find a patch that is a port of the
> > old patch.3.0 in the first post of #229357 and implement
> > Build-Options: build-arch as specified therein.
> 
> First, if Build-Options is not integrated with DEB_BUILD_OPTIONS it should
> not have the same name. I suggest Features:, Build-Features: or something similar.

It clearly does not have the same name. and DEB_BUILD_OPTIONS is for use
by debian/rules only, while Build-Options should be used by
dpkg-buildpackage. They live in different namespaces. Beside the name
Build-Options was decided by agreement in the relevant bug against Debian 
policy. 

The only problem come from the fact that you added a module
BuildOptions.pm to dpkg to mess with DEB_BUILD_OPTIONS, something
dpkg-buildpackage should not do.
(I am not sure I like that dpkg-buildflags does it, but dpkg-buildflags
is normally called from debian/rules which is clearly allowed to read
DEB_BUILD_OPTIONS, so maybe it is fine. Maybe dpkg-buildflags needs a
flag to ignore DEB_BUILD_OPTIONS).

It should be renamed to DEB_BUILD_OPTIONS.pm or
DebBuildOptions.pm to avoid this issue.

In the mean time I named the Build-Options module DebBuildOpts.pm. Feel
encouraged to rename both of them.  

> Then, I don't want it to use commas as separator, it should use spaces as
> separator like DEB_BUILD_OPTIONS and list of architectures.

All other control fields use commas. It would be awkward not to use
commas here.

> To be of any use in other use cases (mainly enabling hardened build
> options), it should support having values associated to each feature
> (ex: build-arch hardening=a,b,c). Default values for features where one is
> not given would be a bonus.

Such support can be added latter. This bug is very old and should have
been fixed years ago. Delaying it for features that were not even
proposed on debian-policy for agreement is not acceptable.

> And last point, a branch is never ready to be merged if the
> documentation is not updated accordingly.

A patch for the documentation for this feature is provided in the
relevant bug against debian-policy since years.

> > +$buildtarget='build-arch' if ( $binarytarget == 'binary-arch' &&
> > +                               defined($buildoptions{'build-arch'}));
> > +
> 
> == is wrong as noted by Cyril.

Ah, sorry for the typo.

The new patch should not have this issue.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 
[0001-Add-support-for-Build-Options-build-arch.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Thu, 25 Nov 2010 13:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to 229357@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 25 Nov 2010 13:21:03 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Roger Leigh <rleigh@debian.org>, 604919@bugs.debian.org
Cc: 229357@bugs.debian.org
Subject: Re: Bug#604919: dpkg: Please add support for build-arch and build-indep targets
Date: Thu, 25 Nov 2010 14:19:35 +0100
reassign 604919 dpkg-dev 1.15.8.6
forcemerge 229357 604919
thanks

(Yay for yet another duplicate on this one...)

On Thu, 25 Nov 2010, Roger Leigh wrote:
> In order to allow full use of Build-Depends-Indep, and to allow
> autobuilding of arch-indep packages on our buildds, as well as
> more efficient building of arch-any packages (since building
> arch-indep stuff can be skipped), I'd like to get full support
> for the build-arch and build-indep targets in debian/rules as
> a release goal for wheezy.

Great... but dpkg-buildpackage will not impose them. If you want
to help, please implement support of the "Build-Features: build-arch"
field that will tell dpkg-buildpackage that it can rely on
build-arch/indep.

The closest patch was the one of Bill Allombert in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#429

The only thing that changed since my last
comments in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#401
is that I will accept a comma-separated field. But I won't merge
anything without documentation and with a name that leads to confusion.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Forcibly Merged 229357 398625 479556 545081 604919. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Thu, 25 Nov 2010 13:21:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Thu, 25 Nov 2010 14:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 25 Nov 2010 14:57:03 GMT) Full text and rfc822 format available.

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

From: Roger Leigh <rleigh@debian.org>
To: 229357@bugs.debian.org
Cc: Roger Leigh <rleigh@debian.org>, 604919@bugs.debian.org
Subject: Re: Bug#604919: dpkg: Please add support for build-arch and build-indep targets
Date: Thu, 25 Nov 2010 14:52:54 +0000
[Message part 1 (text/plain, inline)]
On Thu, Nov 25, 2010 at 02:19:35PM +0100, Raphael Hertzog wrote:
> reassign 604919 dpkg-dev 1.15.8.6
> forcemerge 229357 604919
> thanks
> 
> (Yay for yet another duplicate on this one...)
> 
> On Thu, 25 Nov 2010, Roger Leigh wrote:
> > In order to allow full use of Build-Depends-Indep, and to allow
> > autobuilding of arch-indep packages on our buildds, as well as
> > more efficient building of arch-any packages (since building
> > arch-indep stuff can be skipped), I'd like to get full support
> > for the build-arch and build-indep targets in debian/rules as
> > a release goal for wheezy.
> 
> Great... but dpkg-buildpackage will not impose them. If you want
> to help, please implement support of the "Build-Features: build-arch"
> field that will tell dpkg-buildpackage that it can rely on
> build-arch/indep.

I don't see why we can't just mandate it in Policy, and then
enable it unconditionally if the Standards-Version is >= that
policy version.  The package maintainer is declaring that their
package conforms to that policy version, which requires that
those targets be present.  Easy and simple.

This would make the transition smooth; we won't break existing
packages, and developers will naturally adopt it as they update
to the latest Standards Version, so there's no reason the
transition can't also be equally rapid if we push for it.

This isn't an optional build feature like noopt, parallel etc.
It's something which we want to be the default.  We shouldn't
need to jump through extra hoops to enable default behaviour.
Why bother with new fields like Build-Features when we have an
existing simple and robust mechanism to deal with this.  This
has been an outstanding defect for over six years, and it's
incredibly frustrating that it's being held back by this
(unnecessary?) requirement.

With the cdbs and dh support, followed by the addition of
lintian checks, we'll have >50% archive coverage by the end
of the year, and we should get it mandated by Policy.  I'll
be happy to drive this forward by getting the archive
coverage and policy changes done, rather than waiting another
few years for new control fields.


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, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Thu, 25 Nov 2010 15:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 25 Nov 2010 15:39:03 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Roger Leigh <rleigh@debian.org>
Cc: 229357@bugs.debian.org
Subject: Re: dpkg: Please add support for build-arch and build-indep targets
Date: Thu, 25 Nov 2010 09:34:59 -0600
Hi Roger,

Roger Leigh wrote:

> I don't see why we can't just mandate it in Policy, and then
> enable it unconditionally if the Standards-Version is >= that
> policy version.

It seems that a summary of the previous discussion is in order.

dpkg 1.10.11~9 (In dpkg-buildpackage, call debian/rules -qn
build-arch, 2003-09-15) includes logic to check for the build-arch
target and use it if present.  Unfortunately that logic was wrong.
Adam reasonably concluded (6acb249):

	It is *not* possible *at all* to detect available targets
	in a rules file.  Period.

However, a couple of months ago, some code to do exactly that[1]
was written.  So we can have a transitionless utopia, provided
this works. :)

Meanwhile there has been a lot of discussion of workarounds.

One is to use Standards-Version to indicate use of build-arch.
This seems to me like a terrible precedent to set: once you have
two features enabled this way, the transitions to use them
become coupled.  Russ discussed[2] that in more detail recently;
many others have discussed it before[3].

Another is to introduce Build-options[3] to advertise support for
optional features like this (also DEB_BUILD_OPTIONS=parallel).  Of
course, there is some relucance to do that when it is not clear it
is necessary.

Hope that helps.
Jonathan

[1] http://bugs.debian.org/598534
[2] http://lists.debian.org/debian-devel/2010/09/msg00648.html
[3] http://bugs.debian.org/218893




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Thu, 25 Nov 2010 16:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 25 Nov 2010 16:27:03 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Roger Leigh <rleigh@debian.org>, 229357@bugs.debian.org
Subject: Re: Bug#604919: dpkg: Please add support for build-arch and build-indep targets
Date: Thu, 25 Nov 2010 17:24:46 +0100
Hi,

On Thu, 25 Nov 2010, Roger Leigh wrote:
> I don't see why we can't just mandate it in Policy, and then
> enable it unconditionally if the Standards-Version is >= that
> policy version.  The package maintainer is declaring that their
> package conforms to that policy version, which requires that
> those targets be present.  Easy and simple.

Jonathan made a nice summary and I'm following Russ's recommendation
to not use Standards-Version for this.

> This isn't an optional build feature like noopt, parallel etc.
> It's something which we want to be the default.  We shouldn't

It's not clear at all that we want this to be the default. Only a tiny
minority of packages benefit from the split build process. So it makes
sense to use a capability label to enable it conditionnaly.

> existing simple and robust mechanism to deal with this.  This
> has been an outstanding defect for over six years, and it's
> incredibly frustrating that it's being held back by this
> (unnecessary?) requirement.

It's not been held back by this requirement. It's been held back by
the lack of a nice and reliable way to auto-detect the available targets.
And the lack of consensus on the best way to get forward.

I have decided what I'm ready to accept and I will implement it at some
point. But if you want to go faster, you're welcome to provide me
a patch that I can accept...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Wed, 02 Mar 2011 03:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 02 Mar 2011 03:03:03 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Roger Leigh <rleigh@codelibre.net>
Cc: Jakub Wilk <jwilk@debian.org>, 604397@bugs.debian.org, Roger Leigh <rleigh@debian.org>, 229357@bugs.debian.org
Subject: Re: debian-policy: require build-arch and build-indep targets
Date: Tue, 1 Mar 2011 21:01:31 -0600
user debian-policy@packages.debian.org
usertags 604397 + normative discussion
quit

(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357
from replies)
Hi,

Roger Leigh wrote:
[out of order for convenience]

> Just for the record, I've implemented support in debhelper's dh
> command in #604563.  Once applied, this will automatically add support
> to the huge chunk of the archive using "tiny" rules files.  cdbs will
> be next on my list.

debhelper 8.1.0 has such support now.  Thanks!

>> * Roger Leigh <rleigh@debian.org>, 2010-11-21, 21:38:

>>> I'd like to propose that build-arch and build-indep be changed in
>>> Policy from "may be provided" to "must be provided" in preparation
>>> for enabling their use.

Personally, I'm all for it; ideally it would happen in the following
order:

 1. Providing build-arch and build-indep becomes a best practice.
    lintian gains a check.  devref encourages the practice.

 2. Becomes a policy "should".

 3. Becomes a policy "must".

That sounds slow, no?  Yes, that's the point.  I'd like to propose
that we not make most of the packages in the archive instantly RC
buggy, today.

>>> We've wanted to fix the root problem for
>>> at least half a decade, and I'd like to get it done for wheezy.

I just noticed this gem in policy §4.9:

	If one or both of the targets build-arch and build-indep are
	not provided, then invoking debian/rules with one of the
	not-provided targets as arguments should produce a exit status
	code of 2.  Usually this is provided automatically by make if
	the target is missing.

So it seems to me that "dpkg-buildpackage -B" ought to be taught to
run the equivalent of

	debian/rules build-arch
	if test "$?" = 2
	then
		debian/rules build
	fi

.  In http://bugs.debian.org/72335 the only argument against that I
see is

	(and notwithstanding that we're going to require both or neither), it
	should say that "debian/rules -q with one of the not-provided targets
	...", because the programs which will want to test this are likely to
	do something cheap like:

	debian/rules -q build-arch
	if [ $? -eq 2 ]; then
	    debian/rules build
	else
	    debian/rules build-arch
	fi

	To try a full build only to receive an exit status of 2 would not say
	whether the build failed or the target was not found.

That doesn't seem so compelling to me; in the failure case, the
autobuilder would just try to pick up where it left off and fail
again, which doesn't sound so expensive.  What am I missing?

Thanks for moving this forward.

Regards,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Wed, 02 Mar 2011 09:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jakub Wilk <jwilk@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 02 Mar 2011 09:45:03 GMT) Full text and rfc822 format available.

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

From: Jakub Wilk <jwilk@debian.org>
To: debian-policy@lists.debian.org, 604397@bugs.debian.org, 229357@bugs.debian.org
Subject: Re: Bug#604397: debian-policy: require build-arch and build-indep targets
Date: Wed, 2 Mar 2011 10:43:24 +0100
* Jonathan Nieder <jrnieder@gmail.com>, 2011-03-01, 21:01:
>So it seems to me that "dpkg-buildpackage -B" ought to be taught to
>run the equivalent of
>
>	debian/rules build-arch
>	if test "$?" = 2
>	then
>		debian/rules build
>	fi

make exits with code 2 "if any errors were encountered". So no, this 
approach cannot be used.

-- 
Jakub Wilk




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Sun, 05 Jun 2011 21:14:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 05 Jun 2011 21:16:09 GMT) Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: 229357@bugs.debian.org
Cc: Roger Leigh <rleigh@debian.org>, 604919@bugs.debian.org
Subject: Re: Bug#229357: Bug#604919: dpkg: Please add support for build-arch and build-indep targets
Date: Sun, 5 Jun 2011 23:10:08 +0200
[Message part 1 (text/plain, inline)]
On Thu, Nov 25, 2010 at 02:19:35PM +0100, Raphael Hertzog wrote:
> Great... but dpkg-buildpackage will not impose them. If you want
> to help, please implement support of the "Build-Features: build-arch"
> field that will tell dpkg-buildpackage that it can rely on
> build-arch/indep.
> 
> The closest patch was the one of Bill Allombert in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#429
> 
> The only thing that changed since my last
> comments in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#401
> is that I will accept a comma-separated field. But I won't merge
> anything without documentation and with a name that leads to confusion.

You did not put me in CC so I only find out about this now.  You should have
proposed the name Build-Features in the matching debian-policy bug report
#218893.
  
Please find a new patch that use the name Build-Features and the module name 
Dpkg::BuildFeatures.

It also adds the documentation to dpkg-buildpackage.1. The documentation for
Debian policy is in #218893 already.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 
[0001-Add-support-for-Build-Features-build-arch.patch (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Mon, 06 Jun 2011 06:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 06 Jun 2011 06:21:03 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 229357@bugs.debian.org
Cc: Roger Leigh <rleigh@debian.org>, 604919@bugs.debian.org
Subject: Re: Bug#229357: Bug#604919: dpkg: Please add support for build-arch and build-indep targets
Date: Mon, 6 Jun 2011 08:17:11 +0200
On Sun, 05 Jun 2011, Bill Allombert wrote:
> Please find a new patch that use the name Build-Features and the module name 
> Dpkg::BuildFeatures.

Thanks, here's a short review with a few details to clean.

1/ You're not consistent with the coding style (see doc/coding-style.txt).
2/ Why are you not calling "build-indep" for dpkg-buildpackage -A? AFAIU it
should be exactly like the binary target:
      With flag   | Without flag
-b => build       | build
-B => build-arch  | build
-A => build-indep | build
-F => build       | build
3/ You should document the new field in po/deb-src-control.5

> --- a/man/dpkg-buildpackage.1
> +++ b/man/dpkg-buildpackage.1

The doc needs to be updated as per 2/ above.

> --- /dev/null
> +++ b/scripts/Dpkg/BuildFeatures.pm
> +package Dpkg::BuildFeatures;
> +
> +use strict;
> +use warnings;
> +
> +our $VERSION = "1.00";

Please use version 0.01. I don't want this module to be part of the
stable API yet.

> +The Dpkg::BuildFeatures object can be used to query the options
> +stored in the Build-Features control field

Missing dot at the end.

> +=head1 FUNCTIONS
> +
> +=over 4
> +
> +=item my $bo = Dpkg::BuildFeatures->new($controlfile)

s/bo/bf/

> +    if (defined($src_fields->{'Build-Features'}))
> +    {
> +      my @buildfeats= split(/\s*,\s*/m, $src_fields->{'Build-Features'});

missing space before "="

> +      %buildfeats = map { $_ => 1 } @buildfeats;
> +    } else
> +    { 
> +      %buildfeats=();
> +    }

bad indentation and curly braces on the wrong lines

> +    my $self = { options => \%buildfeats }; 
> +    bless $self, $class;
> +    return $self;
> +}
> +=item $bo->has($option)

Missing empty line before the POD doc.

s/bo/bp/

> diff --git a/scripts/Makefile.am b/scripts/Makefile.am
> index 9b4d394..be376c9 100644
> --- a/scripts/Makefile.am
> +++ b/scripts/Makefile.am
> @@ -56,6 +56,7 @@ nobase_dist_perllib_DATA = \
>  	Dpkg/Arch.pm \
>  	Dpkg/BuildFlags.pm \
>  	Dpkg/BuildOptions.pm \
> +	Dpkg/BuildFeatures.pm \
>  	Dpkg/Changelog.pm \
>  	Dpkg/Changelog/Debian.pm \
>  	Dpkg/Changelog/Entry.pm \

You also want to add it to scripts/po/POTFILES.in in case we add
translatable strings in the future.

> diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
> index aaea544..17294cb 100755
> --- a/scripts/dpkg-buildpackage.pl
> +++ b/scripts/dpkg-buildpackage.pl
> @@ -27,6 +27,7 @@ use Dpkg::Gettext;
>  use Dpkg::ErrorHandling;
>  use Dpkg::BuildFlags;
>  use Dpkg::BuildOptions;
> +use Dpkg::BuildFeatures;
>  use Dpkg::Compression;
>  use Dpkg::Version;
>  use Dpkg::Changelog::Parse;
> @@ -100,6 +101,8 @@ Options:
>        --version  show the version.
>  "), $progname;
>  }
> +my $controlfile = "debian/control";
> +my $buildfeats   = Dpkg::BuildFeatures->new($controlfile);

Do not use a useless intermediary variable. In fact, do not give a value
at all and fix the object's new method to assume "debian/control" if no
explicit value has been given.

>  my @debian_rules = ("debian/rules");
>  my @rootcommand = ();
> @@ -119,6 +122,7 @@ my $checkbuilddep = 1;
>  my $signsource = 1;
>  my $signchanges = 1;
>  my $binarytarget = 'binary';
> +my $buildtarget  = 'build';

Don't align the value when nothing else is aligned.

>  my $targetarch = my $targetgnusystem = '';
>  my $call_target = '';
>  my $call_target_as_root = 0;
> @@ -247,6 +251,9 @@ if ($noclean) {
>      $include = BUILD_BINARY if ($include & BUILD_DEFAULT);
>  }
>  
> +$buildtarget='build-arch' if ( $binarytarget eq 'binary-arch' &&
> +                               $buildfeats->has('build-arch'));

Define buildtarget to build-indep/build-arch while parsing the options
but reset it to "build" here if the flag is missing:
$buildtarget = "build" unless $buildfeats->has('build-arch');

Thank you for your work on this patch!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Mon, 06 Jun 2011 10:45:50 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 06 Jun 2011 10:45:51 GMT) Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 229357@bugs.debian.org, Roger Leigh <rleigh@debian.org>, 604919@bugs.debian.org
Subject: Re: Bug#229357: Bug#604919: dpkg: Please add support for build-arch and build-indep targets
Date: Mon, 6 Jun 2011 12:05:19 +0200
[Message part 1 (text/plain, inline)]
On Mon, Jun 06, 2011 at 08:17:11AM +0200, Raphael Hertzog wrote:
> On Sun, 05 Jun 2011, Bill Allombert wrote:
> > Please find a new patch that use the name Build-Features and the module name 
> > Dpkg::BuildFeatures.
> 
> Thanks, here's a short review with a few details to clean.
> 
> 1/ You're not consistent with the coding style (see doc/coding-style.txt).
> 2/ Why are you not calling "build-indep" for dpkg-buildpackage -A? AFAIU it
> should be exactly like the binary target:
>       With flag   | Without flag
> -b => build       | build
> -B => build-arch  | build
> -A => build-indep | build
> -F => build       | build

When this patch was written, -A did not exist, and only -B was considered by the policy
proposal since autobuilder always use -B.

> 3/ You should document the new field in po/deb-src-control.5

I did a grep 'Build-Depends' to find the relevant files but this one
did not show up. Thanks.

Please find a new patch.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 
[0001-Add-support-for-Build-Features-build-arch.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Mon, 06 Jun 2011 13:33:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 06 Jun 2011 13:33:08 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 229357@bugs.debian.org, Roger Leigh <rleigh@debian.org>, 604919@bugs.debian.org
Subject: Re: Bug#229357: Bug#604919: dpkg: Please add support for build-arch and build-indep targets
Date: Mon, 6 Jun 2011 15:29:35 +0200
Hi,

On Mon, 06 Jun 2011, Bill Allombert wrote:
> Please find a new patch.

Did some small changes and merged it. Thanks!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Added tag(s) pending. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Mon, 06 Jun 2011 13:33:21 GMT) Full text and rfc822 format available.

Message sent on to Bill Allombert <ballombe@debian.org>:
Bug#229357. (Mon, 06 Jun 2011 13:33:25 GMT) Full text and rfc822 format available.

Message #486 received at 229357-submitter@bugs.debian.org (full text, mbox):

From: Raphaël Hertzog <hertzog@debian.org>
To: 229357-submitter@bugs.debian.org
Subject: Bug#229357 marked as pending
Date: Mon, 06 Jun 2011 13:31:41 +0000
tag 229357 pending
thanks

Hello,

Bug #229357 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=14d48ef

---
commit 14d48ef9abc2ce2d394e9ae4d69d4ba68b551620
Author: Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>
Date:   Sun Sep 6 13:18:50 2009 +0200

    dpkg-buildpackage: support for Build-Features: build-arch
    
    With this flag set in debian/control, dpkg-buildpackage will use
    "debian/rules build-arch" or "debian/rules build-indep" when
    appropriate.
    
    Improved-by: Raphaël Hertzog <hertzog@debian.org>
    Signed-off-by: Raphaël Hertzog <hertzog@debian.org>

diff --git a/debian/changelog b/debian/changelog
index afc2283..23574f5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -85,6 +85,12 @@ dpkg (1.16.1) UNRELEASED; urgency=low
   * Do not warn on missing architecture on packages in config-files state,
     but then make sure the architecture field is usable. Closes: #604241
 
+  [ Bill Allombert]
+  * Add support for Build-Features: build-arch. Closes: #229357
+    With this flag, dpkg-buildpackage will now run "debian/rules build-arch"
+    or "debian/rules build-indep" instead of "debian/rules build" when
+    appropriate.
+
   [ Updated dpkg translations ]
   * German (Sven Joachim). Closes: #620312
 




Removed tag(s) pending. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Tue, 02 Aug 2011 13:24:06 GMT) Full text and rfc822 format available.

Added tag(s) pending. Request was from Raphaël Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sat, 28 Jan 2012 07:15:02 GMT) Full text and rfc822 format available.

Message sent on to Bill Allombert <ballombe@debian.org>:
Bug#229357. (Sat, 28 Jan 2012 07:15:06 GMT) Full text and rfc822 format available.

Message #493 received at 229357-submitter@bugs.debian.org (full text, mbox):

From: Raphaël Hertzog <hertzog@debian.org>
To: 229357-submitter@bugs.debian.org
Subject: Bug#229357 marked as pending
Date: Sat, 28 Jan 2012 07:12:39 +0000
tag 229357 pending
thanks

Hello,

Bug #229357 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=2b6e4e5

---
commit 2b6e4e5f2667538d93d8a6beb92abaf2f6137191
Author: Raphaël Hertzog <hertzog@debian.org>
Date:   Tue Jan 24 11:59:44 2012 +0100

    dpkg-buildpackage: use build-arch and build-indep targets of debian/rules
    
    'build-arch' is used when building only arch-any binaries (-B)
    while 'build-indep' is used when building only arch-all binaries (-A).
    To avoid breaking too many packages, dpkg-buildpackages verifies that
    those targets are implemented by calling “make -f debian/rules -qn
    <target>” and ensuring that it doesn't fail with exit code 2. Otherwise
    it falls back to using the 'build' target.
    
    This fallback is a temporary measure until all packages have been
    converted to properly support the build-arch and build-indep targets.
    
    Acked-by: Guillem Jover <guillem@debian.org>

diff --git a/debian/changelog b/debian/changelog
index 06e0dee..9b38d6e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -89,6 +89,9 @@ dpkg (1.16.2) UNRELEASED; urgency=low
   * Drop misleading spaces in deb-symbols(5) in the format description.
   * Clean up dpkg-architecture(1) dropping useless information and
     adding a reference to /usr/share/dpkg/architecture.mk.
+  * Update dpkg-buildpackage to use the "build-arch" (for -B) and
+    "build-indep" (for -A) targets unless "make -qn" says that they do not
+    exist. Closes: #229357
 
   [ Jonathan Nieder ]
   * Bump po4a version in Build-Depends to 0.41, since earlier versions do




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Sat, 28 Jan 2012 21:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 28 Jan 2012 21:57:03 GMT) Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphaël Hertzog <hertzog@debian.org>, 229357@bugs.debian.org
Subject: Re: Bug#229357: marked as pending
Date: Sat, 28 Jan 2012 22:53:57 +0100
On Sat, Jan 28, 2012 at 07:12:39AM +0000, Raphaël Hertzog wrote:
> tag 229357 pending
> thanks
> 
> Hello,
> 
> Bug #229357 reported by you has been fixed in the Git repository. You can
> see the changelog below, and you can check the diff of the fix at:
> 
>     http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=2b6e4e5

Hello Raphaël,

You probably mistyped the bug number because bug 229357 was already tagged as pending
by you on Mon, 06 Jun 2011, and I am eagerly waiting for the patching dpkg to be
released. See

      http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=14d48ef

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Sun, 29 Jan 2012 06:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 29 Jan 2012 06:39:04 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 229357@bugs.debian.org
Subject: Re: Bug#229357: marked as pending
Date: Sun, 29 Jan 2012 07:31:01 +0100
Hi,

On Sat, 28 Jan 2012, Bill Allombert wrote:
> > Bug #229357 reported by you has been fixed in the Git repository. You can
> > see the changelog below, and you can check the diff of the fix at:
> > 
> >     http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=2b6e4e5
> 
> Hello Raphaël,
> 
> You probably mistyped the bug number because bug 229357 was already tagged as pending
> by you on Mon, 06 Jun 2011, and I am eagerly waiting for the patching dpkg to be
> released. See
> 
>       http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=14d48ef

I know but this commit got reverted since Guillem did not like this
solution, see commit 9f2c48ff8d3c113d627e799650e97b6f734e6f93.

So this is the definitive solution agreed upon by both of us.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Sun, 29 Jan 2012 13:45:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 29 Jan 2012 13:45:14 GMT) Full text and rfc822 format available.

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

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 229357@bugs.debian.org
Subject: Re: Bug#229357: marked as pending
Date: Sun, 29 Jan 2012 14:40:42 +0100
On Sun, Jan 29, 2012 at 07:31:01AM +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Sat, 28 Jan 2012, Bill Allombert wrote:
> > > Bug #229357 reported by you has been fixed in the Git repository. You can
> > > see the changelog below, and you can check the diff of the fix at:
> > > 
> > >     http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=2b6e4e5
> > 
> > Hello Raphaël,
> > 
> > You probably mistyped the bug number because bug 229357 was already tagged as pending
> > by you on Mon, 06 Jun 2011, and I am eagerly waiting for the patching dpkg to be
> > released. See
> > 
> >       http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=14d48ef
> 
> I know but this commit got reverted since Guillem did not like this
> solution, see commit 9f2c48ff8d3c113d627e799650e97b6f734e6f93.

I cannot imagine that Guillem reverted the commit without notify me. After all the
years I fought with this report, this would be incredibly rude and unusual for Guillem.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#229357; Package dpkg-dev. (Mon, 30 Jan 2012 06:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 30 Jan 2012 06:57:07 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 229357@bugs.debian.org
Subject: Re: Bug#229357: marked as pending
Date: Mon, 30 Jan 2012 07:54:22 +0100
On Sun, 29 Jan 2012, Bill Allombert wrote:
> > I know but this commit got reverted since Guillem did not like this
> > solution, see commit 9f2c48ff8d3c113d627e799650e97b6f734e6f93.
> 
> I cannot imagine that Guillem reverted the commit without notify me. After all the
> years I fought with this report, this would be incredibly rude and unusual for Guillem.

I reverted it because Guillem was not happy with it and was blocking the
release of dpkg 1.16.1.

See last para of http://lists.debian.org/debian-dpkg/2011/07/msg00023.html

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/




Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 06 Feb 2012 00:06:15 GMT) Full text and rfc822 format available.

Notification sent to Bill Allombert <ballombe@debian.org>:
Bug acknowledged by developer. (Mon, 06 Feb 2012 00:06:16 GMT) Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: 229357-close@bugs.debian.org
Subject: Bug#229357: fixed in dpkg 1.16.2~wipmultiarch
Date: Mon, 06 Feb 2012 00:02:22 +0000
Source: dpkg
Source-Version: 1.16.2~wipmultiarch

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

dpkg-dev_1.16.2~wipmultiarch_all.deb
  to main/d/dpkg/dpkg-dev_1.16.2~wipmultiarch_all.deb
dpkg_1.16.2~wipmultiarch.dsc
  to main/d/dpkg/dpkg_1.16.2~wipmultiarch.dsc
dpkg_1.16.2~wipmultiarch.tar.bz2
  to main/d/dpkg/dpkg_1.16.2~wipmultiarch.tar.bz2
dpkg_1.16.2~wipmultiarch_amd64.deb
  to main/d/dpkg/dpkg_1.16.2~wipmultiarch_amd64.deb
dselect_1.16.2~wipmultiarch_amd64.deb
  to main/d/dpkg/dselect_1.16.2~wipmultiarch_amd64.deb
libdpkg-dev_1.16.2~wipmultiarch_amd64.deb
  to main/d/dpkg/libdpkg-dev_1.16.2~wipmultiarch_amd64.deb
libdpkg-perl_1.16.2~wipmultiarch_all.deb
  to main/d/dpkg/libdpkg-perl_1.16.2~wipmultiarch_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 229357@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg 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: SHA1

Format: 1.8
Date: Sun, 05 Feb 2012 23:39:40 +0100
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source amd64 all
Version: 1.16.2~wipmultiarch
Distribution: experimental
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 192619 229357 367608 427945 595144 608884 627832 636238 642473 642608 642802 643746 643969 644370 646496 647915 648180 648217 649248 651481 651813 651993 652414 653575 654453 654626 655411 656496 657849
Changes: 
 dpkg (1.16.2~wipmultiarch) experimental; urgency=low
 .
   This is a WIP release, command line interfaces *will* change.
 .
   [ Guillem Jover ]
   * Move <config.h> and <compat.h> to the top of trigdeferred.l to properly
     use the configured features and compat code.
   * Honour --disable-nls when the system lacks obstack support, by updating
     the obstack compat module from gnulib.
   * Link the libdpkg unit tests with libcompat and libintl, so that systems
     needing them will compile correctly.
   * Check for the presence of the strnlen declaration and correctly provide
     the compat one in case the systems lacks it.
   * Do not assume existence of paths on the build system in the test suite.
   * Do not fail to link dselect on MacOS X when using --disable-nls.
   * Remove versioned coreutils Pre-Depends from dpkg due to the ancient
     md5sum transition. Reported by Bill Allombert <ballombe@debian.org>.
     Closes: #643746
   * Change dpkg-architecture to only compute the requested variables. This:
     - Fixes the bootstrapping problem, as the dpkg build system only needs
       the host architecture, for which dpkg itself is not required.
     - Reduces the amount of work performed, including loading and parsing
       unnecessary table files or calling either of gcc or dpkg programs.
   * Improve error message in dpkg-gencontrol and dpkg-gensymbols when
     debian/control does not have any package stanza. Closes: #642473
     Based on a patch by Kyle Willmon <kylewillmon@gmail.com>.
   * Add Pre-Depends on tar >= 1.23 (satisfied in stable) to dpkg due to it
     using the ‘--warning=no-timestamp’ option. Closes: #642802
   * Do not segfault on GNU/Linux when dpkg cannot retrieve the block size
     for the filesystem containing the info database. LP: #872734
   * Fix two memory leaks per tar entry in the tar extractor used on unpack.
   * Mark dpkg and dselect as Multi-Arch foreign.
     Reported by Steve Langasek <vorlon@debian.org>.
   * Mark dpkg-dev and libdpkg-perl as Multi-Arch foreign. Closes: #648217
     Thanks to Colin Watson <cjwatson@ubuntu.com>.
   * Add new deb-origin.5 man page. Closes: #608884
     Thanks to Matt Kraai <kraai@ftbfs.org>.
   * Return correct status on start-stop-daemon --status when using --pidfile.
   * Treat dpkg-deb compression level independently for each backend. This
     has the effect of changing the current behaviour for level 0 on all
     compressors except gzip.
   * Add new dpkg-deb -S option to specify the compression strategy. The only
     currently supported value is “extreme” for xz. Closes: #647915
   * Stop using brace expansion to install man pages by using dh_installman
     instead of dh_install, the former does not abort on empty glob expansion.
   * Do not use absolute paths for programs in perl and shell code.
   * Add missing ‘*’ in asprintf() and vasprintf() compat declarations.
   * Add support for virtual output binary:Summary and db:Status-Abbrev fields.
     Closes: #192619, #427945
   * Add support for virtual output source:Package and source:Version fields.
     Closes: #653575
   * Use a different temporary file per process on libcompat's vsnprintf()
     function to avoid race conditions from children after fork(3).
     Reported by Daniel Ruoso <daniel@ruoso.com>. Closes: #655411
   * Fix start-stop-daemon --exec and --name options on FreeBSD, NetBSD and
     OpenBSD by swapping the process matching implementations.
   * Fix start-stop-daemon --name option on GNU/Hurd to match the process name.
   * Document in more detail the implications of start-stop-daemon matching
     options. Closes: #367608
   * Improve and clarify dpkg-shlibdeps superfluous linking warning messages.
     Based on a patch by Peter Eisentraut <petere@debian.org>. Closes: #656496
 .
   [ Raphaël Hertzog ]
   * Update Dpkg::Shlibs to look into multiarch paths when cross-building
     too. Closes: #595144
   * Rewrite architecture.mk with explicit loops instead of duplicating many
     similar lines. Based on a patch by Thorsten Glaser <tg@mirbsd.de>.
   * Modify dpkg-gencontrol and dpkg-distaddfile to grab a write lock
     on debian/control before updating debian/files to avoid simultaneous
     updates. Closes: #642608
     Add libfile-fcntllock-perl to dpkg-dev's Depends since we use this module
     to handle the locking.
   * Update dpkg-gensymbols(1) to clarify that -e accepts shell patterns
     expansions and not regular expressions. And let dpkg-gensymbols output a
     warning when a pattern doesn't match any file. Closes: #649248
   * Add new option "-a <arch>" to dpkg-checkbuilddeps to check build
     dependencies for another architecture. This is really basic for now since
     it assumes all build dependencies must be satisfied on the listed
     architecture. Closes: #648180 Thanks to Colin Watson for the patch.
   * Error out if a dpkg database .list file is not a regular file. LP: #369898
   * Fix dpkg-mergechangelogs to not error out on invalid versions.
     Closes: #651993
   * Fix dpkg-source --commit on "3.0 (quilt)" when an explicit patch file
     is given with a relative filename. Closes: #652414
   * Further clarify in dpkg-source(1) the conditions under which it's possible
     to pass an explicit patch file to dpkg-source --commit.
   * Add new --query-features command to dpkg-buildflags. Thanks to Kees Cook
     for the patch. Closes: #651481
   * Fix description of Multi-Arch in deb-control(5). Closes: #654453
     Thanks to Jakub Wilk for spotting the mistake.
   * Drop misleading spaces in deb-symbols(5) in the format description.
   * Clean up dpkg-architecture(1) dropping useless information and
     adding a reference to /usr/share/dpkg/architecture.mk.
   * Update dpkg-buildpackage to use the "build-arch" (for -B) and
     "build-indep" (for -A) targets unless "make -qn" says that they do not
     exist. Closes: #229357
 .
   [ Jonathan Nieder ]
   * Bump po4a version in Build-Depends to 0.41, since earlier versions do
     not handle --srcdir correctly. Closes: #644370
 .
   [ Helge Kreutzmann ]
   * Fix a typo in man/dpkg-deb.1.
 .
   [ Updated dpkg translations ]
   * German (Sven Joachim).
   * Italian (Milo Casagrande). Closes: #627832, #657849
   * Swedish (Peter Krefting).
   * French (Christian Perrier)
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
   * Spanish (Omar Campagne). Closes: #636238
   * Swedish (Peter Krefting).
 .
   [ Updated man page translations ]
   * German (Helge Kreutzmann), including typo fix in dpkg-genchanges
     Closes: #646496, sub optimal translation of package states LP: #368783
     and an fix by Chris Leick
   * Japanese (TAKAHASHI Motonobu).
   * Spanish (Omar Campagne). Closes: #643969
   * Swedish (Peter Krefting).
   * Minor errors corrected in French (thanks to David Prévot)
   * Fix translation of -B and -A options of dpkg-buildpackage.
     Thanks to Vincent Danjean. Closes: #654626
 .
   [ Updated dselect translations ]
   * Dutch (Jeroen Schot). Closes: #651813
Checksums-Sha1: 
 5b350a13d4749a68f55688f53bd934ca33b7bc34 1414 dpkg_1.16.2~wipmultiarch.dsc
 e3c394da92562bc2bf9bb18a6832c575b32cc2a0 5569622 dpkg_1.16.2~wipmultiarch.tar.bz2
 7ce788ea96a3df3cda27c34e5769a48ccfd4cfe1 609206 libdpkg-dev_1.16.2~wipmultiarch_amd64.deb
 840f46fce0fcf7c1214924582a1100dd8d358bc4 2086476 dpkg_1.16.2~wipmultiarch_amd64.deb
 ee2acabe565079c9f1b559443bdc780079040aeb 1000514 dselect_1.16.2~wipmultiarch_amd64.deb
 a6d02b21cd5eac118de310187eae7a6bb63943c5 635810 dpkg-dev_1.16.2~wipmultiarch_all.deb
 728863e43f9185e3182eb78d807b670441e9dd94 851128 libdpkg-perl_1.16.2~wipmultiarch_all.deb
Checksums-Sha256: 
 ce7050ed905c72f823fdb183714f5b5c546e5015ec79dbdf759281c7c60faaae 1414 dpkg_1.16.2~wipmultiarch.dsc
 24b73f91f9e93ddd984172b35a52e6818c2195002ff4d5e72898712d802a3efa 5569622 dpkg_1.16.2~wipmultiarch.tar.bz2
 8a31ad426d8b7e363cce14516d73be1575b724a2683c80322c14f379b60e7efb 609206 libdpkg-dev_1.16.2~wipmultiarch_amd64.deb
 e3f3cef7dd88a5632b4139a042b8943397e512699504ca9abdf3ee97604a9208 2086476 dpkg_1.16.2~wipmultiarch_amd64.deb
 2addf6880dc5d2ee2a817519987fdc9a59751d511de4aa689b19095c0392c4b4 1000514 dselect_1.16.2~wipmultiarch_amd64.deb
 f4a65c7ebd66f7e5eba877d7a9af98ebb33ea9755fd72730d7f9416e6d0b8b7d 635810 dpkg-dev_1.16.2~wipmultiarch_all.deb
 d972b0812219c2afaca254306e8bf5e3feca49c4324924a5c5bb640447cca72d 851128 libdpkg-perl_1.16.2~wipmultiarch_all.deb
Files: 
 7c1aa845fad678163118b63c2053aee3 1414 admin required dpkg_1.16.2~wipmultiarch.dsc
 2c02844dc317beaf6d5f4e22e966813c 5569622 admin required dpkg_1.16.2~wipmultiarch.tar.bz2
 f49a6d3e6ea649b8bb36afd41258bd3c 609206 libdevel optional libdpkg-dev_1.16.2~wipmultiarch_amd64.deb
 6b3fba7d1254c0e0dda083c94e01a749 2086476 admin required dpkg_1.16.2~wipmultiarch_amd64.deb
 fec42261e17f7b60a8cb2339d8b4fa1a 1000514 admin optional dselect_1.16.2~wipmultiarch_amd64.deb
 64b69c596994b4716ed8a0f7ef6c2d0e 635810 utils optional dpkg-dev_1.16.2~wipmultiarch_all.deb
 c8e38c68397fda8dc171bc2a6d7e0c4f 851128 perl optional libdpkg-perl_1.16.2~wipmultiarch_all.deb

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

iEYEARECAAYFAk8vCk4ACgkQuW9ciZ2SjJuPQwCgk4tpFGkzvc7sKsBqQfzw7Dob
NDkAn3uyGGvGcL1KfN49EztspiEGaB47
=Tkrm
-----END PGP SIGNATURE-----





Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 06 Feb 2012 00:06:16 GMT) Full text and rfc822 format available.

Notification sent to Piotr Roszatycki <dexter@n1.pl>:
Bug acknowledged by developer. (Mon, 06 Feb 2012 00:06:16 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 06 Feb 2012 00:06:17 GMT) Full text and rfc822 format available.

Notification sent to Bastian Blank <waldi@debian.org>:
Bug acknowledged by developer. (Mon, 06 Feb 2012 00:06:17 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 06 Feb 2012 00:06:18 GMT) Full text and rfc822 format available.

Notification sent to Zack Weinberg <zackw@panix.com>:
Bug acknowledged by developer. (Mon, 06 Feb 2012 00:06:18 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 06 Feb 2012 00:06:20 GMT) Full text and rfc822 format available.

Notification sent to Roger Leigh <rleigh@debian.org>:
Bug acknowledged by developer. (Mon, 06 Feb 2012 00:06:20 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 19 Mar 2012 09:21:20 GMT) Full text and rfc822 format available.

Notification sent to Bill Allombert <ballombe@debian.org>:
Bug acknowledged by developer. (Mon, 19 Mar 2012 09:21:21 GMT) Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: 229357-close@bugs.debian.org
Subject: Bug#229357: fixed in dpkg 1.16.2
Date: Mon, 19 Mar 2012 09:17:32 +0000
Source: dpkg
Source-Version: 1.16.2

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

dpkg-dev_1.16.2_all.deb
  to main/d/dpkg/dpkg-dev_1.16.2_all.deb
dpkg_1.16.2.dsc
  to main/d/dpkg/dpkg_1.16.2.dsc
dpkg_1.16.2.tar.bz2
  to main/d/dpkg/dpkg_1.16.2.tar.bz2
dpkg_1.16.2_amd64.deb
  to main/d/dpkg/dpkg_1.16.2_amd64.deb
dselect_1.16.2_amd64.deb
  to main/d/dpkg/dselect_1.16.2_amd64.deb
libdpkg-dev_1.16.2_amd64.deb
  to main/d/dpkg/libdpkg-dev_1.16.2_amd64.deb
libdpkg-perl_1.16.2_all.deb
  to main/d/dpkg/libdpkg-perl_1.16.2_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 229357@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg 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: SHA1

Format: 1.8
Date: Mon, 19 Mar 2012 07:27:12 +0100
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source amd64 all
Version: 1.16.2
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 192619 229357 367608 427945 595144 608884 627832 636238 642473 642608 642802 643746 643969 644370 646496 647915 648180 648217 649248 651481 651813 651993 652414 653575 654453 654626 655411 656496 657849 658126 658696 658854 661638 663004
Changes: 
 dpkg (1.16.2) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Move <config.h> and <compat.h> to the top of trigdeferred.l to properly
     use the configured features and compat code.
   * Honour --disable-nls when the system lacks obstack support, by updating
     the obstack compat module from gnulib.
   * Link the libdpkg unit tests with libcompat and libintl, so that systems
     needing them will compile correctly.
   * Check for the presence of the strnlen declaration and correctly provide
     the compat one in case the systems lacks it.
   * Do not assume existence of paths on the build system in the test suite.
   * Do not fail to link dselect on MacOS X when using --disable-nls.
   * Remove versioned coreutils Pre-Depends from dpkg due to the ancient
     md5sum transition. Reported by Bill Allombert <ballombe@debian.org>.
     Closes: #643746
   * Change dpkg-architecture to only compute the requested variables. This:
     - Fixes the bootstrapping problem, as the dpkg build system only needs
       the host architecture, for which dpkg itself is not required.
     - Reduces the amount of work performed, including loading and parsing
       unnecessary table files or calling either of gcc or dpkg programs.
   * Improve error message in dpkg-gencontrol and dpkg-gensymbols when
     debian/control does not have any package stanza. Closes: #642473
     Based on a patch by Kyle Willmon <kylewillmon@gmail.com>.
   * Add Pre-Depends on tar >= 1.23 (satisfied in stable) to dpkg due to it
     using the ‘--warning=no-timestamp’ option. Closes: #642802
   * Do not segfault on GNU/Linux when dpkg cannot retrieve the block size
     for the filesystem containing the info database. LP: #872734
   * Fix two memory leaks per tar entry in the tar extractor used on unpack.
   * Mark dpkg and dselect as Multi-Arch foreign.
     Reported by Steve Langasek <vorlon@debian.org>.
   * Mark dpkg-dev and libdpkg-perl as Multi-Arch foreign. Closes: #648217
     Thanks to Colin Watson <cjwatson@ubuntu.com>.
   * Add new deb-origin.5 man page. Closes: #608884
     Thanks to Matt Kraai <kraai@ftbfs.org>.
   * Return correct status on start-stop-daemon --status when using --pidfile.
   * Treat dpkg-deb compression level independently for each backend. This
     has the effect of changing the current behaviour for level 0 on all
     compressors except gzip.
   * Add new dpkg-deb -S option to specify the compression strategy. The only
     currently supported value is “extreme” for xz. Closes: #647915
   * Stop using brace expansion to install man pages by using dh_installman
     instead of dh_install, the former does not abort on empty glob expansion.
   * Do not use absolute paths for programs in perl and shell code.
   * Add missing ‘*’ in asprintf() and vasprintf() compat declarations.
   * Add support for virtual output binary:Summary and db:Status-Abbrev fields.
     Closes: #192619, #427945
   * Add support for virtual output source:Package and source:Version fields.
     Closes: #653575
   * Use a different temporary file per process on libcompat's vsnprintf()
     function to avoid race conditions from children after fork(3).
     Reported by Daniel Ruoso <daniel@ruoso.com>. Closes: #655411
   * Fix start-stop-daemon --exec and --name options on FreeBSD, NetBSD and
     OpenBSD by swapping the process matching implementations.
   * Fix start-stop-daemon --name option on GNU/Hurd to match the process name.
   * Document in more detail the implications of start-stop-daemon matching
     options. Closes: #367608
   * Improve and clarify dpkg-shlibdeps superfluous linking warning messages.
     Based on a patch by Peter Eisentraut <petere@debian.org>. Closes: #656496
   * Relax --merge-avail Packages file parser, to not fail on bogus versions.
   * When building only arch-indep binaries with «dpkg-buildpackage -A», name
     the .changes file using ‘all’ as architecture. Closes: #661638
   * Handle unknown architectures gracefully in dpkg-buildflags.
     Closes: #663004
   * Add missing --status-logger to dpkg --help output.
   * Do not print bogus errno string for invalid package names in dpkg
     --ignore-depends option.
   * Change dpkg-query to not load the available file by default for --list
     and --show, add a new --load-avail option to expose the old behaviour.
   * Only allow setting selections via «dpkg --set-selections» for known
     packages (i.e. those present in either the status or available files).
   * Always ignore older versions when parsing the available file, not only
     for --update-avail and --merge-avail.
   * Mark not-installed non-arch-qualified selections for removal.
   * Add new «dpkg --assert-multi-arch» command to allow checking for
     multi-arch support availability.
   * Bump Standards-Version to 3.9.3 (no changes needed).
   * Add architecture consistency checks to «dpkg --audit».
   * Add new dpkg --add-architecture and --remove-architecture commands to
     track supported architectures.
 .
   [ Raphaël Hertzog ]
   * Update Dpkg::Shlibs to look into multiarch paths when cross-building
     too. Closes: #595144
   * Rewrite architecture.mk with explicit loops instead of duplicating many
     similar lines. Based on a patch by Thorsten Glaser <tg@mirbsd.de>.
   * Modify dpkg-gencontrol and dpkg-distaddfile to grab a write lock
     on debian/control before updating debian/files to avoid simultaneous
     updates. Closes: #642608
     Add libfile-fcntllock-perl to dpkg-dev's Depends since we use this module
     to handle the locking.
   * Update dpkg-gensymbols(1) to clarify that -e accepts shell patterns
     expansions and not regular expressions. And let dpkg-gensymbols output a
     warning when a pattern doesn't match any file. Closes: #649248
   * Add new option "-a <arch>" to dpkg-checkbuilddeps to check build
     dependencies for another architecture. This is really basic for now since
     it assumes all build dependencies must be satisfied on the listed
     architecture. Closes: #648180 Thanks to Colin Watson for the patch.
   * Error out if a dpkg database .list file is not a regular file. LP: #369898
   * Fix dpkg-mergechangelogs to not error out on invalid versions.
     Closes: #651993
   * Fix dpkg-source --commit on "3.0 (quilt)" when an explicit patch file
     is given with a relative filename. Closes: #652414
   * Further clarify in dpkg-source(1) the conditions under which it's possible
     to pass an explicit patch file to dpkg-source --commit.
   * Add new --query-features command to dpkg-buildflags. Thanks to Kees Cook
     for the patch. Closes: #651481
   * Fix description of Multi-Arch in deb-control(5). Closes: #654453
     Thanks to Jakub Wilk for spotting the mistake.
   * Drop misleading spaces in deb-symbols(5) in the format description.
   * Clean up dpkg-architecture(1) dropping useless information and
     adding a reference to /usr/share/dpkg/architecture.mk.
   * Update dpkg-buildpackage to use the "build-arch" (for -B) and
     "build-indep" (for -A) targets unless "make -qn" says that they do not
     exist. Closes: #229357
   * Improve deb-shlibs(5) to mention that the dependency field must
     use the same syntax than a Depends field. Closes: #658696
   * Update dpkg-maintscript-helper(1) to recommend usage of the version
     removing/renaming a conffile with a "~" suffix as "priorversion"
     parameter. Thanks to Sam Morris <sam@robots.org.uk> for the patch.
     Closes: #658854
   * Fix debug output of dpkg-maintscript-helper. LP: #936340
 .
   [ Jonathan Nieder ]
   * Bump po4a version in Build-Depends to 0.41, since earlier versions do
     not handle --srcdir correctly. Closes: #644370
 .
   [ Guillem Jover, Steve Langasek, Raphaël Hertzog ]
   * Add new dpkg --print-foreign-architectures command.
   * Add support for virtual output binary:Package field.
   * Implement Multi-Arch support.
 .
   [ Helge Kreutzmann ]
   * Fix a typo in man/dpkg-deb.1.
 .
   [ Updated dpkg translations ]
   * German (Sven Joachim).
   * Italian (Milo Casagrande). Closes: #627832, #657849
   * Swedish (Peter Krefting).
   * French (Christian Perrier)
   * Polish (Michał Kułach). Closes: #658126
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
   * Spanish (Omar Campagne). Closes: #636238
   * Swedish (Peter Krefting).
 .
   [ Updated man page translations ]
   * German (Helge Kreutzmann), including typo fix in dpkg-genchanges
     Closes: #646496, sub optimal translation of package states LP: #368783
     and an fix by Chris Leick
   * Japanese (TAKAHASHI Motonobu).
   * Spanish (Omar Campagne). Closes: #643969
   * Swedish (Peter Krefting).
   * Minor errors corrected in French (thanks to David Prévot)
   * Fix translation of -B and -A options of dpkg-buildpackage.
     Thanks to Vincent Danjean. Closes: #654626
 .
   [ Updated dselect translations ]
   * Dutch (Jeroen Schot). Closes: #651813
Checksums-Sha1: 
 77256a48ee15cf6c7b13fe54e005e392bf13e608 1362 dpkg_1.16.2.dsc
 43ea22771b0dd9eb5bf7ceaf672400e7196a2bea 5578978 dpkg_1.16.2.tar.bz2
 ca0ba8572881a940aad51a0d029560dacb6a2156 621048 libdpkg-dev_1.16.2_amd64.deb
 0b4298d541724b07fbf549249812971bf335fc42 2326938 dpkg_1.16.2_amd64.deb
 06164d70bb28998bde8db6790a2123048e6d62e0 1070312 dselect_1.16.2_amd64.deb
 db6b45db3dcbd7016bf43ab9ea5050844234591e 1165258 dpkg-dev_1.16.2_all.deb
 3c91d7a0f934cebeb90f6b1200785f3c142bc79c 860916 libdpkg-perl_1.16.2_all.deb
Checksums-Sha256: 
 16f885e5d1215c12c980b77e104bff41cc82f36431f91ed21990693324d87793 1362 dpkg_1.16.2.dsc
 53a77f694ce2269f17729b0e9626c59687683703e3822a2624b13da4a10fccc9 5578978 dpkg_1.16.2.tar.bz2
 37c676f894980da2a6bd074f2326722c8233e6bc4d507f0c8161d903193f6c38 621048 libdpkg-dev_1.16.2_amd64.deb
 f096294c2d0c6ea790137d3170fb692404d3f364363f56480f9688490945c508 2326938 dpkg_1.16.2_amd64.deb
 83973997ecc90a318accfc4ba45bd18c10a5d9c15a959b9403f3c890db61320d 1070312 dselect_1.16.2_amd64.deb
 541749e314b3d3228ce1b89666aefa4a26353d057b675e85da82a099a6684513 1165258 dpkg-dev_1.16.2_all.deb
 8864e6735ee12452435a859bd0444bed7364032e5118b91a0fbf1345a618bc44 860916 libdpkg-perl_1.16.2_all.deb
Files: 
 4c0e64a5775c90db51d3cb0263b81852 1362 admin required dpkg_1.16.2.dsc
 629ba7ee2024e6a5c0ff807aa2db02f8 5578978 admin required dpkg_1.16.2.tar.bz2
 4e2d60c52c2b04787dbc8bee72e6044d 621048 libdevel optional libdpkg-dev_1.16.2_amd64.deb
 6dbfc23909173f7948b6d67cd5f478eb 2326938 admin required dpkg_1.16.2_amd64.deb
 d3e07e1f216935c7db59ced3e9950909 1070312 admin optional dselect_1.16.2_amd64.deb
 e3cc2a84e29ac98690ca150d37a557af 1165258 utils optional dpkg-dev_1.16.2_all.deb
 9f4869d928df7aad7f22295d9ab28215 860916 perl optional libdpkg-perl_1.16.2_all.deb

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

iEYEARECAAYFAk9m67YACgkQuW9ciZ2SjJu4ZwCgg5g2xI9krladpIS55iZt7OrA
ETwAoOVYQ26EgFLrT9gNTAuRodMUoyi4
=v+Je
-----END PGP SIGNATURE-----





Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 19 Mar 2012 09:21:26 GMT) Full text and rfc822 format available.

Notification sent to Piotr Roszatycki <dexter@n1.pl>:
Bug acknowledged by developer. (Mon, 19 Mar 2012 09:21:32 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 19 Mar 2012 09:21:37 GMT) Full text and rfc822 format available.

Notification sent to Bastian Blank <waldi@debian.org>:
Bug acknowledged by developer. (Mon, 19 Mar 2012 09:21:38 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 19 Mar 2012 09:21:40 GMT) Full text and rfc822 format available.

Notification sent to Zack Weinberg <zackw@panix.com>:
Bug acknowledged by developer. (Mon, 19 Mar 2012 09:21:40 GMT) Full text and rfc822 format available.

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Mon, 19 Mar 2012 09:21:41 GMT) Full text and rfc822 format available.

Notification sent to Roger Leigh <rleigh@debian.org>:
Bug acknowledged by developer. (Mon, 19 Mar 2012 09:21:43 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 27 Apr 2012 07:35:53 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: Sun Apr 20 00:44:34 2014; Machine Name: beach.debian.org

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