Debian Bug report logs - #614731
support for env var substitutions in .install (helps multiarch)

version graph

Package: debhelper; Maintainer for debhelper is Debhelper Maintainers <debhelper-devel@lists.alioth.debian.org>; Source for debhelper is src:debhelper.

Reported by: Wookey <wookey@wookware.org>

Date: Wed, 23 Feb 2011 03:15:02 UTC

Severity: wishlist

Tags: patch, wontfix

Found in version debhelper/8.1.2

Fixed in version debhelper/8.9.12

Done: Joey Hess <joeyh@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, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Wed, 23 Feb 2011 03:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
New Bug report received and forwarded. Copy sent to Joey Hess <joeyh@debian.org>. (Wed, 23 Feb 2011 03:15:05 GMT) Full text and rfc822 format available.

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

From: Wookey <wookey@wookware.org>
To: submit@bugs.debian.org
Subject: multiarch support for debhelper
Date: Wed, 23 Feb 2011 03:10:44 +0000
Package: debhelper
Version: 8.1.2

Multiarch support is (finally!) coming along nicely in both Ubuntu and
Debian. (see https://launchpad.net/~vorlon/+archive/multiarch )

I'm not sure how closely you've been following the multiarch work, but
it provides the ability to cleanly install libraries of multiple
architectures. The multiarch-cross spec extension provides the
functionality to use this for cross-building and resolving
cross-dependencies.

https://wiki.ubuntu.com/MultiarchSpec
https://wiki.ubuntu.com/MultiarchCross

We've been testing this work for use on armhf and armel and have come
up with a nice patch for debhelper which makes the conversion of
packages to be multiarch compliant very straighforward.

We hope it meets with your approval.

All library packages (and -dev packages) will need to be
'multiarchified' over time, so making this as easy as possible for
maintainers is good.

To convert a package the following is necessary:
* all multiarch packages will need to be compat 8 and build-depend on debhelper >> 8.1.2
* debian/control gets the Multi-Arch fields added to relevant binary stanzas
* debian/*.install files get modified, individually, with a token which
    debhelper can replace with the triplet.
* export DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
    added to debian/rules (and tokens added as required) 
* The patch (from Daniel Silverstone), applied to debhelper (so that it
can expand the token ${DEB_HOST_MULTIARCH})

Here is an example package, converted using the suggested patch:
http://www.emdebian.org/trac/browser/current/multiarch/p/popt/trunk/debian

http://ftp.uk.debian.org/emdebian-multiarch/pool/main/p/popt/

This has been tested inside a chroot with modified, experimental,
versions of dpkg and lsb-base using vorlon's patches. These packages
are available in the above emdebian-multiarch repository (although
possibly only for amd64 but sources are included).

The resulting packages cross-build in a MultiArch manner easily.

Patch:
Index: Debian/Debhelper/Dh_Lib.pm
===================================================================
--- Debian/Debhelper/Dh_Lib.pm	(revision 7813)
+++ Debian/Debhelper/Dh_Lib.pm	(working copy)
@@ -617,6 +617,10 @@
 			next if /^#/ || /^$/;
 		}
 		my @line;
+		# Only expand ${...} environment vars in v8
+		if (! compat(7)) {
+				s#\$\{([^\}]+)\}#$ENV{$1}#g;
+		}
 		# Only do glob expansion in v3 mode.
 		#
 		# The tricky bit is that the glob expansion is done


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/




Severity set to 'wishlist' from 'normal' Request was from Wookey <wookey@wookware.org> to control@bugs.debian.org. (Wed, 23 Feb 2011 18:03:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#614731; Package debhelper. (Wed, 23 Feb 2011 21:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Wed, 23 Feb 2011 21:21:03 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: Wookey <wookey@wookware.org>, 614731@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Wed, 23 Feb 2011 17:16:52 -0400
[Message part 1 (text/plain, inline)]
Wookey wrote:
> --- Debian/Debhelper/Dh_Lib.pm	(revision 7813)
> +++ Debian/Debhelper/Dh_Lib.pm	(working copy)
> @@ -617,6 +617,10 @@
>  			next if /^#/ || /^$/;
>  		}
>  		my @line;
> +		# Only expand ${...} environment vars in v8
> +		if (! compat(7)) {
> +				s#\$\{([^\}]+)\}#$ENV{$1}#g;
> +		}

To enable this for any debhelper compatability level, I would need some
level of assurance that it does not break any existing packages that
use that compatability level. Otherwise, I would have to make this a 
v9 thing.

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

Information stored :
Bug#614731; Package debhelper. (Thu, 24 Feb 2011 12:45:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelpgpg@gmail.com>:
Extra info received and filed, but not forwarded. (Thu, 24 Feb 2011 12:45:07 GMT) Full text and rfc822 format available.

Message #17 received at 614731-quiet@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelpgpg@gmail.com>
To: 614731-quiet@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Thu, 24 Feb 2011 12:40:50 +0000
On 23 February 2011 23:21, Daniel Silverstone
<dsilvers@digital-scurf.org> wrote:
> On Wed, Feb 23, 2011 at 10:59:23PM +0000, Wookey wrote:
>> A response from joey. One would have to build a load of packages (or
>> at least search for the regexp to prove it didn't break anything.
>
> I find it hard to believe that ${...} appears anywhere in the filesystem of an
> unpacked debian system.  An easy way to be sure would be to search for $ in the
> Contents files, because globbing would otherwise leave them alone.

The Contents files do contain matches for $ and $.*$ but not for ${

Tested on ftp.uk.debian.org/debian for Sid, all architectures.

codehelp@free:/org/ftp/debian/dists/sid$ zgrep '${' Contents-*.gz

I haven't tested the entire set of postinst scripts - this could be
done, possibly on lintian.debian.org or similar.

> As for compat 9, I don't think that's entirely infeasible, esp. if you discover
> you need more debhelper changes in order to make multiarch nice.

I think compat 9 is probably the best solution anyway. Maintainers
will need to make deliberate changes in the package for multiarch, a
check for unexpected expansions in their maintainer scripts is just
one part of the change.


-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Mon, 28 Feb 2011 18:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 28 Feb 2011 18:42:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: 614731@bugs.debian.org, 614731-submitter@bugs.debian.org
Subject: Re: multiarch support for debhelper
Date: Mon, 28 Feb 2011 10:38:41 -0800
[Message part 1 (text/plain, inline)]
As long as you're considering adding this at a new debhelper compat level, I
think we should look at the possibility of v9 being multiarch-by-default -
i.e., passing a multiarch default --libdir (or equivalent) to the build
system with dh_auto_configure, adding "multiarch-support" to ${misc:Depends}
for any packages shipping libs under $prefix/lib/$tuple, and
$I'm_not_sure_what_else_yet.

Joey, do you have any timeline for a v9 release?  It would be great to be
able to coordinate this as closely as possible so that v9 is ready for
deployment as soon as multiarch policy is finalized.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Message sent on to Wookey <wookey@wookware.org>:
Bug#614731. (Mon, 28 Feb 2011 18:42:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#614731; Package debhelper. (Tue, 01 Mar 2011 15:51:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Tue, 01 Mar 2011 15:51:09 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: Steve Langasek <vorlon@debian.org>, 614731@bugs.debian.org
Cc: 614731-submitter@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Tue, 1 Mar 2011 11:49:10 -0400
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:
> As long as you're considering adding this at a new debhelper compat level, I
> think we should look at the possibility of v9 being multiarch-by-default -
> i.e., passing a multiarch default --libdir (or equivalent) to the build
> system with dh_auto_configure, adding "multiarch-support" to ${misc:Depends}
> for any packages shipping libs under $prefix/lib/$tuple, and
> $I'm_not_sure_what_else_yet.
> 
> Joey, do you have any timeline for a v9 release?  It would be great to be
> able to coordinate this as closely as possible so that v9 is ready for
> deployment as soon as multiarch policy is finalized.

I don't have a timeline. It's been quite a short time since 8.0.0.
The only serious thing on my v9 todo list is DEB_OPTIONS_DEBUG
and possibly something for #544844.

However, I can start a v9 at any point, the typical process is to
not close the compat level immediately, and so anything that uses
it is responsible for dealing with any breakage introduced by later
changes, until 9.0.0 is released.

It does seem to me that it would be better to get basic support into
debhelper generally w/o a v9. The kind of assurance I'm looking
for is along the lines of scanning all debhelper config files in Debian
to make sure none contain the new syntax somehow. While this seems
unlikely, debhelper has enough users that any weird thing could be done
by *someone*.

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

Message sent on to Wookey <wookey@wookware.org>:
Bug#614731. (Tue, 01 Mar 2011 15:51:20 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Tue, 01 Mar 2011 16:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 01 Mar 2011 16:03:05 GMT) Full text and rfc822 format available.

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

From: Wookey <wookey@wookware.org>
To: Joey Hess <joeyh@debian.org>, 614731-quiet@bugs.debian.org
Cc: Steve Langasek <vorlon@debian.org>, 614731@bugs.debian.org, 614731-submitter@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Tue, 1 Mar 2011 16:01:17 +0000
+++ Joey Hess [2011-03-01 11:49 -0400]:
> It does seem to me that it would be better to get basic support into
> debhelper generally w/o a v9. The kind of assurance I'm looking
> for is along the lines of scanning all debhelper config files in Debian
> to make sure none contain the new syntax somehow. While this seems
> unlikely, debhelper has enough users that any weird thing could be done
> by *someone*.

Neil had a look at possible occurences:

On 23 February 2011 23:21, Daniel Silverstone
<dsilvers@digital-scurf.org> wrote:
> On Wed, Feb 23, 2011 at 10:59:23PM +0000, Wookey wrote:
>> A response from joey. One would have to build a load of packages (or
>> at least search for the regexp to prove it didn't break anything.
>
> I find it hard to believe that ${...} appears anywhere in the filesystem of an
> unpacked debian system.  An easy way to be sure would be to search for $ in the
> Contents files, because globbing would otherwise leave them alone.

The Contents files do contain matches for $ and $.*$ but not for ${

Tested on ftp.uk.debian.org/debian for Sid, all architectures.

codehelp@free:/org/ftp/debian/dists/sid$ zgrep '${' Contents-*.gz

I haven't tested the entire set of postinst scripts - this could be
done, possibly on lintian.debian.org or similar.

> As for compat 9, I don't think that's entirely infeasible, esp. if you discover
> you need more debhelper changes in order to make multiarch nice.

I think compat 9 is probably the best solution anyway. Maintainers
will need to make deliberate changes in the package for multiarch, a
check for unexpected expansions in their maintainer scripts is just
one part of the change.


-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/



Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/




Information stored :
Bug#614731; Package debhelper. (Tue, 01 Mar 2011 16:03:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and filed, but not forwarded. (Tue, 01 Mar 2011 16:03:11 GMT) Full text and rfc822 format available.

Message sent on to Wookey <wookey@wookware.org>:
Bug#614731. (Tue, 01 Mar 2011 16:03:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#614731; Package debhelper. (Tue, 01 Mar 2011 16:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Tue, 01 Mar 2011 16:36:03 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: Wookey <wookey@wookware.org>
Cc: 614731-quiet@bugs.debian.org, Steve Langasek <vorlon@debian.org>, 614731@bugs.debian.org, 614731-submitter@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Tue, 1 Mar 2011 12:32:18 -0400
[Message part 1 (text/plain, inline)]
I don't feel that looking at the Contents file is good enough. Consider
that some package might sed the files to expand ${..} on its own, somehow.

> I haven't tested the entire set of postinst scripts - this could be
> done, possibly on lintian.debian.org or similar.

debhelper should not modify postinst scripts; this expansion should be
limited to debhelper config files.

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

Information stored :
Bug#614731; Package debhelper. (Tue, 01 Mar 2011 16:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and filed, but not forwarded. (Tue, 01 Mar 2011 16:36:05 GMT) Full text and rfc822 format available.

Message sent on to Wookey <wookey@wookware.org>:
Bug#614731. (Tue, 01 Mar 2011 16:36:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Tue, 01 Mar 2011 17:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 01 Mar 2011 17:09:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: Wookey <wookey@wookware.org>, 614731@bugs.debian.org, 614731-submitter@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Tue, 1 Mar 2011 09:05:22 -0800
[Message part 1 (text/plain, inline)]
On Tue, Mar 01, 2011 at 12:32:18PM -0400, Joey Hess wrote:
> I don't feel that looking at the Contents file is good enough. Consider
> that some package might sed the files to expand ${..} on its own, somehow.

How would such a file ever be seen as input by debhelper either?

But unless there are compelling uses for this other than multiarch right
now, I also think v9 is the way to go.  Changing the default --libdir
certainly won't be v8-safe, so I think multiarch conversion documentation
will want to recommend going for v9 all at once.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Message sent on to Wookey <wookey@wookware.org>:
Bug#614731. (Tue, 01 Mar 2011 17:09:07 GMT) Full text and rfc822 format available.

Merged 614731 617761. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. (Fri, 11 Mar 2011 19:15:04 GMT) Full text and rfc822 format available.

Added tag(s) pending. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. (Sat, 12 Mar 2011 18:36:04 GMT) Full text and rfc822 format available.

Changed Bug title to 'support for env var substitutions in .install (helps multiarch)' from 'multiarch support for debhelper' Request was from Steve Langasek <steve.langasek@linaro.org> to control@bugs.debian.org. (Sun, 13 Mar 2011 18:39:09 GMT) Full text and rfc822 format available.

Disconnected #614731 from all other report(s). Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sun, 13 Mar 2011 18:45:06 GMT) Full text and rfc822 format available.

Removed tag(s) pending. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Tue, 15 Mar 2011 03:36:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#614731; Package debhelper. (Tue, 15 Mar 2011 19:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Tue, 15 Mar 2011 19:33:03 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: 614731@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Tue, 15 Mar 2011 15:28:12 -0400
[Message part 1 (text/plain, inline)]
I've searched the lintian lab for debhelper config files 
containing ${ -- found none.

Now, when designing an interface like this, I like to try to think a
little bit ahead. Will arbitrary environment variables being expanded
in these files be abused? Will it make packages that are harder
for others to maintain, or that are less fragile, or harder to
source-introspect in useful ways? What is the escaping mechanism when
someone needs to put ${ literally in later? Perhaps only a subset of
environment variables, like DEB_* should be expanded? Are environment
variables the right thing at all -- perhaps debhelper should just look
up DEB_HOST_MULTIARCH on its own, and only fill that in? These are
some of the things I have been slowly mullting over; after developing
debhelper for 15 years, I have learned to think about this stuff first
rather than deal with getting it wrong later.


 1     Mar 15 Ubuntu Merge-o- Ubuntu debhelper 8.1.2ubuntu2


I have a new policy: Once Ubuntu applies a patch to software I wrote,
without allowing me to sign off on it[1], I will no longer apply that
patch to the upstream source of the package. By doing this, over and over
again, Ubuntu is implicitly saying that they do not value my work, my
expertese, or the time I would need to spend to deal with fallout of
their changes, and so I simply choose to ignore them in return.

So, if Debian feels it is appropriate for this bug to be fixed,
someone will need to NMU debhelper.

-- 
see shy jo

[1] security fixes and grave bugfixes excluded
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Tue, 15 Mar 2011 20:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@brainfood.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 15 Mar 2011 20:09:02 GMT) Full text and rfc822 format available.

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

From: Adam Heath <doogie@brainfood.com>
To: 614731@bugs.debian.org
Subject: support for env-var substitutions in .install (helps multiarch)
Date: Tue, 15 Mar 2011 15:04:43 -0500
Actually, that's more complex, and has the standard backwards 
compatible issues.

Better would be:

debian/%.install: debian/%.install.in
	sed 's///' < $^ > $@.tmp
	mv $@.tmp $@





Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Tue, 15 Mar 2011 21:00:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 15 Mar 2011 21:00:02 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Joey Hess <joeyh@debian.org>, 614731@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Tue, 15 Mar 2011 13:55:48 -0700
[Message part 1 (text/plain, inline)]
On Tue, Mar 15, 2011 at 03:28:12PM -0400, Joey Hess wrote:

> I have a new policy: Once Ubuntu applies a patch to software I wrote,
> without allowing me to sign off on it[1],

This appears to have been the result of a grave misunderstanding on my part.
From the bug log, I mistakenly believed that the only outstanding question
between this patch and the git repository was whether this should be turned
on in compat level 8 or 9.  As it's now clear to me that this is not the
case, I've reverted the change in question from Ubuntu.

Regardless of whether you consider this patch a non-starter now because of
my previous Ubuntu upload, this is the right thing for us to do so long as
this patch is not agreed for upstream inclusion.  It was never my intention
to introduce Ubuntu-specific debhelper behavior or preempt your authority to
decide whether this patch should be accepted, and I'm very sorry that this
is how it came across.

> By doing this, over and over again, Ubuntu is implicitly saying that they
> do not value my work, my expertese, or the time I would need to spend to
> deal with fallout of their changes, and so I simply choose to ignore them
> in return.

I can't speak for any other Ubuntu uploaders, but as the uploader of this
particular change I can assure you without hesitation that this is not how I
feel, and I wouldn't have pushed this patch had I understood there was any
risk that it might result in fallout to you.

I've learned my lesson and in the future will avoid grabbing debhelper
patches before they've been committed to git.  Apparently when I try to read
between the lines on bug reports, that doesn't work so well.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#614731; Package debhelper. (Tue, 15 Mar 2011 22:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Tue, 15 Mar 2011 22:09:03 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 614731@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Tue, 15 Mar 2011 18:06:50 -0400
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:
> This appears to have been the result of a grave misunderstanding on my part.
> From the bug log, I mistakenly believed that the only outstanding question

I apoogize for my poor communication.

(But not for being an asshole; that's really the only option Ubuntu has
left me beyond letting things rot.)

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

Added indication that bug 614731 blocks 623765 Request was from Sven Eckelmann <sven@narfation.org> to control@bugs.debian.org. (Fri, 22 Apr 2011 20:54:06 GMT) Full text and rfc822 format available.

Added indication that bug 614731 blocks 623766 Request was from Sven Eckelmann <sven@narfation.org> to control@bugs.debian.org. (Fri, 22 Apr 2011 20:54:08 GMT) Full text and rfc822 format available.

Added indication that bug 614731 blocks 623767 Request was from Sven Eckelmann <sven@narfation.org> to control@bugs.debian.org. (Fri, 22 Apr 2011 20:54:10 GMT) Full text and rfc822 format available.

Removed indication that bug 614731 blocks 623765 Request was from Sven Eckelmann <sven@narfation.org> to control@bugs.debian.org. (Tue, 07 Jun 2011 19:39:04 GMT) Full text and rfc822 format available.

Removed indication that bug 614731 blocks 623766 Request was from Sven Eckelmann <sven@narfation.org> to control@bugs.debian.org. (Tue, 07 Jun 2011 19:39:05 GMT) Full text and rfc822 format available.

Removed indication that bug 614731 blocks 623767 Request was from Sven Eckelmann <sven@narfation.org> to control@bugs.debian.org. (Tue, 07 Jun 2011 19:39:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Wed, 27 Jul 2011 21:45:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Wed, 27 Jul 2011 21:45:07 GMT) Full text and rfc822 format available.

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

From: Modestas Vainius <modax@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: Steve Langasek <vorlon@debian.org>, 614731@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Thu, 28 Jul 2011 00:42:03 +0300
[Message part 1 (text/plain, inline)]
Hello,

On trečiadienis 16 Kovas 2011 00:06:50 Joey Hess wrote:
> Steve Langasek wrote:
> > This appears to have been the result of a grave misunderstanding on my
> > part. From the bug log, I mistakenly believed that the only outstanding
> > question
> 
> I apoogize for my poor communication.
> 
> (But not for being an asshole; that's really the only option Ubuntu has
> left me beyond letting things rot.)

Any movement on this? With the number of multiarch packages growing rapidly, 
IMHO it is about time to establish some nice "best practises" before 
maintainers resort to various hacks...

-- 
Modestas Vainius <modax@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Wed, 14 Sep 2011 22:10:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yann Dirson <ydirson@free.fr>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Wed, 14 Sep 2011 22:10:17 GMT) Full text and rfc822 format available.

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

From: Yann Dirson <ydirson@free.fr>
To: Joey Hess <joeyh@debian.org>
Cc: 641051@bugs.debian.org, 614731@bugs.debian.org
Subject: Re: Bug#641051: dh_auto_configure does not pass multiarch paths to cmake
Date: Thu, 15 Sep 2011 00:09:24 +0200
On Wed, Sep 14, 2011 at 04:33:13PM -0400, Joey Hess wrote:
> Yann Dirson wrote:
> > Right, looks like the standard cmake rules install libs into
> > ${CMAKE_INSTALL_PREFIX}/lib/ without it being possible to override.
> > 
> > Looks like the shortest path to multiarch here would be to move the
> > lib/ and usr/lib/ contents to the appropriate dir.  Maybe just
> > immediate children matching '\.so\>' ?  That sounds a bit dwim and
> > fragile, though - what do you think ?  debhelper probably already has
> > a way to tell which files are shared libs, which would be a much
> > better guess ?
> > 
> > Since compat v9 "is still open for development", it would be possible
> > for such a feature to jump in the boat ?
> 
> Such a scheme would generalize from moving libs after cmake install to
> moving libs after an arbitrary build system install. It doesn't belong
> in the cmake support code then.

Right - and that should not badly interact with --libdir support.

> The full, non-DWIM generalization is to have a syntax for controlling
> what files dh_install puts where.

This may be useful, but my feeling is that some predefined settings
that Work for Most (tm) should be easily selectable, and possibly the
default as long as it's possible to tune it.  It would be awkward to
stay with the current situation of only autotools packages doing
multiarch by default (which, depending on upstream Makefile.*
correctness, is not guaranted to work for all packages either).  And
it would be awkward as well IMHO to require all lib packages to specify
the same regexps.

On the issue of specifying destinations to dh_install, I have already
noticed that the config-file version was less powerful than the
commandline.  If the package.install lines were redefined to contain a
pattern and an optional destination (here again, subject to
compat>=9), a first gap would be filled.

Then a special token could be used for multiarch, like:

| usr/lib/lib*.so usr/${LIB}/

But then, that still requires manual handling for all *binary*
packages, so some default --automultiarch flag to dh_install (one that
would move shared libes as in my previous suggestion) could be easier
on the maints, while possibly not even requiring a compat bump.




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Sat, 05 Nov 2011 06:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to YunQiang Su <wzssyqa@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sat, 05 Nov 2011 06:21:03 GMT) Full text and rfc822 format available.

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

From: YunQiang Su <wzssyqa@gmail.com>
To: 614731@bugs.debian.org
Subject: Re: Bug#614731: multiarch support for debhelper
Date: Sat, 5 Nov 2011 14:11:58 +0800
Any progress?

Don't forget dh_link

-- 
YunQiang Su




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Sun, 27 Nov 2011 15:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Zacchiroli <zack@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sun, 27 Nov 2011 15:21:03 GMT) Full text and rfc822 format available.

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

From: Stefano Zacchiroli <zack@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: Kees Cook <kees@debian.org>, 649784@bugs.debian.org, 614731@bugs.debian.org
Subject: Re: Bug#649784: add dh_apparmor for easier AppArmor profile management
Date: Sun, 27 Nov 2011 16:19:22 +0100
[Message part 1 (text/plain, inline)]
On Wed, Nov 23, 2011 at 07:08:04PM -0400, Joey Hess wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=82;bug=614731
>   I have a new policy: Once Ubuntu applies a patch to software I wrote,
>   without allowing me to sign off on it[1], I will no longer apply that
>   patch to the upstream source of the package. By doing this, over and over
>   again, Ubuntu is implicitly saying that they do not value my work, my
>   expertese, or the time I would need to spend to deal with fallout of
>   their changes, and so I simply choose to ignore them in return.

Heya Joey,
  having worked quite a bit on "mediating" the wishes of Debian (as
upstream) developers with those of downstream derivatives, I feel
confident stating that many people in Debian would now welcome being
asked (some people would even say "bothered", I suspect) to sign off
changes that derivatives intend to apply.

I understand and respect your desire here, but please understand that
it'd probably not be a reasonable default. Or at least not a flame-free
one.

The closest approximation of it I could imagine is that derivatives
developers will submit to Debian patches they have applied, as merge
requests (which, AFAICT, it's what Kees is doing here). Of course doing
so will open up to the risk of seeing their changes rejected, but that
would be already way better than being ignored all together. I also
think it'd also be better for Debian, but that's probably a subjective
matter.

So, to improve for the future:

- how would you like to be asked to sign-off changes by downstream
  developers? mail to the maintainer or wishlist bug report?

  I'll be happy to check with derivatives people how they can keep track
  of which Debian maintainer wishes this kind of interaction and who
  don't want to be bothered (honestly, I see no other sane default for
  such a dilemma)

> So, if Debian feels it is appropriate for this bug to be fixed,
> someone will need to NMU debhelper.

That helps, thanks. I've seen that on #debian-devel people where
interested in picking up your availability for this also for #614731,
maybe a single NMU could do?  I suggest that NMU-ers use a reasonably
DELAYED/XX queue, so that you get a chance to review and, if you feel
like, comment on it before it's final.

Cheers.
-- 
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#614731; Package debhelper. (Sun, 27 Nov 2011 16:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Sun, 27 Nov 2011 16:06:03 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: Stefano Zacchiroli <zack@debian.org>
Cc: Kees Cook <kees@debian.org>, 649784@bugs.debian.org, 614731@bugs.debian.org
Subject: Re: Bug#649784: add dh_apparmor for easier AppArmor profile management
Date: Sun, 27 Nov 2011 12:01:53 -0400
[Message part 1 (text/plain, inline)]
Stefano Zacchiroli wrote:
>   having worked quite a bit on "mediating" the wishes of Debian (as
> upstream) developers with those of downstream derivatives, I feel
> confident stating that many people in Debian would now welcome being
     (I assume you made a significant typo --------> not)
> asked (some people would even say "bothered", I suspect) to sign off
> changes that derivatives intend to apply.

Divergence in debhelper between debian derivatives results in packages
that will build in distro A but not in distro B, with no indication why
beyond a dh_ command being missing or not working as expected. This is
severely bad for the greater Debian ecosystem, to borrow a term.

I have pointed out this is a problem before, and have been roundly
ignored.

I have no interest in supporting distributions who introduce such
problems, and no remaining tolerance for divergent changes to debhelper.

> That helps, thanks. I've seen that on #debian-devel people where
> interested in picking up your availability for this also for #614731,
> maybe a single NMU could do?  I suggest that NMU-ers use a reasonably
> DELAYED/XX queue, so that you get a chance to review and, if you feel
> like, comment on it before it's final.

Note that if debhelper is NMUed, I will be stuck trying to maintain a
package that contains code that I have decided not to have anything to
do with. That could well end up being an impossible position for me to
continue maintaining debhelper in Debian.

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

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Sun, 27 Nov 2011 16:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Zacchiroli <zack@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sun, 27 Nov 2011 16:39:03 GMT) Full text and rfc822 format available.

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

From: Stefano Zacchiroli <zack@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: Kees Cook <kees@debian.org>, 649784@bugs.debian.org, 614731@bugs.debian.org
Subject: Re: Bug#649784: add dh_apparmor for easier AppArmor profile management
Date: Sun, 27 Nov 2011 17:36:28 +0100
[Message part 1 (text/plain, inline)]
On Sun, Nov 27, 2011 at 12:01:53PM -0400, Joey Hess wrote:
> Stefano Zacchiroli wrote:
> >   having worked quite a bit on "mediating" the wishes of Debian (as
> > upstream) developers with those of downstream derivatives, I feel
> > confident stating that many people in Debian would now welcome being
>      (I assume you made a significant typo --------> not)

I did indeed.  s/not/now/ is a recurrent typo for me, but that doesn't
make it less embarrassing (especially in this context).

> Divergence in debhelper between debian derivatives results in packages
> that will build in distro A but not in distro B, with no indication why
> beyond a dh_ command being missing or not working as expected. This is
> severely bad for the greater Debian ecosystem, to borrow a term.

I agree with this.

> I have pointed out this is a problem before, and have been roundly
> ignored.

I was not aware of this. Not that I should have been informed but, with
your permission, I'd like to help now. My motivation to do that is that
I believe having you ignore the two bugs we're discussing is bad for
Debian, and not only for the so called ecosystem. Mind sharing with whom
you pointed out the problem in the past? (even in private mail / IRC
query, if you prefer)

Still, I'd like to understand how we can avoid the problem in the
future. The two bug logs we are discussing concerns apparmor and
multi-arch. Both cases concern technologies that have been available
first in a downstream distro and only then, and recently, in Debian.
Would you have accepted to sign-off, and maybe even integrate, patches
about stuff not in Debian yet? We have examples of that happening with
Ubuntu, but the problem is more general that that; the higher the number
of derivatives we have the higher the potential occurrence of these
issues in the future.

I think it's reasonable for you to ask to sign-off on debhelper changes,
but we need: (1) your willingness to accept changes that are potentially
not useful for Debian (yet), and (2) a way to inform derivatives of
that. Recent work on the Derivatives Front Desk about a "Debian branding
how to" can help with (2), but not with (1).

> Note that if debhelper is NMUed, I will be stuck trying to maintain a
> package that contains code that I have decided not to have anything to
> do with. That could well end up being an impossible position for me to
> continue maintaining debhelper in Debian.

That would be very bad. It's a sort of catch 22. I'm sure nobody would
want to lose you as debhelper maintainer. At the same time you're
applying your right to ignore specific patches due to their *past*
history. When the *present* of those patches is that they are useful and
needed in Debian, for Debian needs, not for the need of a derivative who
happened to ship them in the past. If you welcome an NMU, we have a way
out of it. If you don't, I honestly don't see which way out Debian has,
to get features we currently lack.

Would a clean re-implementation do?  It seems silly to even think of
this as a way out when working code already exists, but it'd be better
than nothing.

Thanks for your feedback,
Cheers.
-- 
Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#614731; Package debhelper. (Sun, 27 Nov 2011 20:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Sun, 27 Nov 2011 20:36:03 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: Stefano Zacchiroli <zack@debian.org>
Cc: 649784@bugs.debian.org, 614731@bugs.debian.org
Subject: Re: Bug#649784: add dh_apparmor for easier AppArmor profile management
Date: Sun, 27 Nov 2011 16:32:56 -0400
[Message part 1 (text/plain, inline)]
Stefano Zacchiroli wrote:
> Still, I'd like to understand how we can avoid the problem in the
> future. The two bug logs we are discussing concerns apparmor and
> multi-arch. Both cases concern technologies that have been available
> first in a downstream distro and only then, and recently, in Debian.
> Would you have accepted to sign-off, and maybe even integrate, patches
> about stuff not in Debian yet? We have examples of that happening with
> Ubuntu, but the problem is more general that that; the higher the number
> of derivatives we have the higher the potential occurrence of these
> issues in the future.
> 
> I think it's reasonable for you to ask to sign-off on debhelper changes,
> but we need: (1) your willingness to accept changes that are potentially
> not useful for Debian (yet), and (2) a way to inform derivatives of
> that. Recent work on the Derivatives Front Desk about a "Debian branding
> how to" can help with (2), but not with (1).
> 
> > Note that if debhelper is NMUed, I will be stuck trying to maintain a
> > package that contains code that I have decided not to have anything to
> > do with. That could well end up being an impossible position for me to
> > continue maintaining debhelper in Debian.
> 
> That would be very bad. It's a sort of catch 22. I'm sure nobody would
> want to lose you as debhelper maintainer. At the same time you're
> applying your right to ignore specific patches due to their *past*
> history. When the *present* of those patches is that they are useful and
> needed in Debian, for Debian needs, not for the need of a derivative who
> happened to ship them in the past. If you welcome an NMU, we have a way
> out of it. If you don't, I honestly don't see which way out Debian has,
> to get features we currently lack.

I appreciate what you're trying to do, but I simply have no interest in
trying to deal with these problems further. I hope that whatever Debian
decides to do lets me continue to maintain debhelper in Debian.

> Would a clean re-implementation do?  It seems silly to even think of
> this as a way out when working code already exists, but it'd be better
> than nothing.

No, because my issue is not with the code but with Ubuntu continally
forcing Debian to accede to their changes or risk horrible divergence.
As we also saw with dpkg triggers, etc.

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

Added tag(s) wontfix. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. (Sun, 27 Nov 2011 20:36:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#614731; Package debhelper. (Wed, 07 Dec 2011 08:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Riku Voipio <riku.voipio@iki.fi>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Wed, 07 Dec 2011 08:06:03 GMT) Full text and rfc822 format available.

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

From: Riku Voipio <riku.voipio@iki.fi>
To: 614731@bugs.debian.org
Cc: zack@debian.org, wookey@wookware.org, joeyh@debian.org
Subject: Bug#614731: support for env var substitutions in .install (helps multiarch)
Date: Wed, 7 Dec 2011 10:01:57 +0200
Hi,

Just to chime in to list some real world cases where env variable
substition would have been useful, but lacking it I had to create
some workarounds:

popt[1], and ncurses, have now install.in and links.in, which are
then preprocessed to the actual files. Wireless-tools[2] avoids
template files, but gets rid of .links file and instead does the
ln -s command manually in the rules file. 

All these source packages have in common that the split libraries in
/lib/ with development stuff under /usr/lib/.. For the more usual
"/usr/lib" only libraries, env substition is not mandatory usually.
We can just replace install files "/usr/lib/*.so.*" with "/usr/lib/*/*.so.*".
But that is a potential trap, as packages could just fine install stuff
under subdirectories of /usr/lib which might not be relative to --libdir.

And still, we have cases like glib2.0, where the upstream buildsystem
forces building many copies, making it neccesary to use install.in files.

As a summary, it is possible to live without env substition built in
debhelper. But it means we need to add some common tasks to
debian/rules, exactly the things that debhelper usually lets
us avoid.

Riku


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638447
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642434





Reply sent to Joey Hess <joeyh@debian.org>:
You have taken responsibility. (Wed, 07 Dec 2011 19:34:25 GMT) Full text and rfc822 format available.

Notification sent to Wookey <wookey@wookware.org>:
Bug acknowledged by developer. (Wed, 07 Dec 2011 19:34:25 GMT) Full text and rfc822 format available.

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

From: Joey Hess <joeyh@debian.org>
To: 614731-close@bugs.debian.org
Subject: Bug#614731: fixed in debhelper 8.9.12
Date: Wed, 07 Dec 2011 19:33:03 +0000
Source: debhelper
Source-Version: 8.9.12

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

debhelper_8.9.12.dsc
  to main/d/debhelper/debhelper_8.9.12.dsc
debhelper_8.9.12.tar.gz
  to main/d/debhelper/debhelper_8.9.12.tar.gz
debhelper_8.9.12_all.deb
  to main/d/debhelper/debhelper_8.9.12_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 614731@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Joey Hess <joeyh@debian.org> (supplier of updated debhelper 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: SHA256

Format: 1.8
Date: Wed, 07 Dec 2011 15:09:50 -0400
Source: debhelper
Binary: debhelper
Architecture: source all
Version: 8.9.12
Distribution: unstable
Urgency: low
Maintainer: Joey Hess <joeyh@debian.org>
Changed-By: Joey Hess <joeyh@debian.org>
Description: 
 debhelper  - helper programs for debian/rules
Closes: 235302 372310 438601 477625 614731 632860 642129 651221 651224
Changes: 
 debhelper (8.9.12) unstable; urgency=low
 .
   * Debhelper config files may be made executable programs that output the
     desired configuration. No further changes are planned to the config file
     format; those needing powerful syntaxes may now use a programming language
     of their choice. (Be careful aiming that at your feet.)
     Closes: #235302, #372310, #235302, #614731,
     Closes: #438601, #477625, #632860, #642129
   * Added German translation of man pages, done by Chris Leick. Closes: #651221
   * Typo fixes. Closes: #651224 Thanks, Chris Leick
Checksums-Sha1: 
 9737ff50de2c404b43fa699ac9ffd3c5001b7889 1561 debhelper_8.9.12.dsc
 90c731d73c65b5690aa9634782317f5c0aaf722b 457449 debhelper_8.9.12.tar.gz
 dfd71bb77a117da7b79d67edcd83ac3b613dae0f 693304 debhelper_8.9.12_all.deb
Checksums-Sha256: 
 67ffe0e94f249a2a5a799d1ecf63618470cf1b9196a38d7d985b6a366fb45b9b 1561 debhelper_8.9.12.dsc
 ba5d19df5f1583efc8f9d433c229a652f3a83d0a9a3d553001e996b3e935980f 457449 debhelper_8.9.12.tar.gz
 08a4b3079fb9f4f52642ff10aeca8e7b5abee64915520743b9e283f7d04c3933 693304 debhelper_8.9.12_all.deb
Files: 
 003f53a81bd3d2b0033745a0c951d218 1561 devel optional debhelper_8.9.12.dsc
 4a54f779263c54a37e423b19b456e1b3 457449 devel optional debhelper_8.9.12.tar.gz
 9afbc8d939dfdefadf50103f2cbb7003 693304 devel optional debhelper_8.9.12_all.deb

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

iQIVAwUBTt+8FckQ2SIlEuPHAQiUFBAAmBqWVI3sbJIbd5PhEF2dPdo5qzLMZDIf
WMq09nVIJnw8oLQrb54vFa+JRIhrQZyzndLjJFXN2umu1ZYvITnR4FsA3f2zfJfp
sNHL1vQ8ldjAVJQeL+q9M0V92K2GACb8EBOW+XqIEJzxA74U/NQ9592zo0+myvAc
bBWiy04N3l9W7Y1ltxioLtBSJX8lLwt5fXdAG/t3dntv1fFMHdkw0LfQJgijaJMB
xyZW2xMHNdSJvKwiwUQdqepW2fKf8T+ayuJ7WYtgGne2B1hNeIZr7ZzKouccMWjY
FJVlvlRn07LkvpzFUga2KH9DjMgxlI3FP8yec2aQ+B5f/1ZQWulXKIQnF8v0imHC
rfnj3XATQ6I1SQCh74fYIVr+90jguQMKC9nZafNhq5nwssuLZ37jfk6ZcW6XB3hW
b1Jf3ogzZNez9tAuGvnZkBkKVb6frMIJgRrQxUQUh6a+g1Utpl/wXsOJrPKAgQmn
r1jzabh/Enx/6uhfDqUIHtUFz2hjAcCraWE55EXPlE/SChsGDe7qCXNcp0n+SWh3
aZpmJ/bTQNp2sOtK8IUbFSlxiSwcto9nMOzx0x2B7HqO9bO29niK+CJiWaGcPOMF
ONGqEL7Nf4MIZzNO8yJXYAIJVfE7jDzJZXB5pquaM+J3qEytKm8j5FQ5V+GEV763
SuDxx/V7N2s=
=1Cqd
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 05 Jan 2012 07:34:06 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 06:40:27 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.