Debian Bug report logs - #456934
sbuild: Wrong handling of or'ed build-dependencies

Toggle useless messages

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

From: Jan-Marek Glogowski <glogow@fbihome.de>

To: submit@bugs.debian.org

Subject: sbuild: Wrong handling of or'ed build-dependencies

Date: Tue, 18 Dec 2007 16:59:24 +0100 (CET)

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Subject: sbuild: Wrong handling of or'ed build-dependencies
Package: sbuild
Version: 0.56
Severity: important
Tags: patch

Actually I'm using the SVN trunk r1250.

I'm trying to build bzr-svn for Debian Etch.

The package has the following build dependencies:

Build-Depends-Indep: python-subversion, bzr (>= 1.0~), python (>= 2.5) | python-pysqlite2

The following text is the relevant output from running
sbuild -A -s -D -d halut bzr-svn_0.4.5-1lhm1.dsc

==============================

...
Source dependencies of bzr-svn: python-central (>= 0.5), cdbs (>= 0.4.43),
python, debhelper (>= 5.0.37.2), python-subversion, bzr (>= 1.0~), python (>= 2.5)|python-pysqlite2
Filtering dependencies
Requesting dpkg status for packages: python-subversion python cdbs bzr
python-pysqlite2 python-central debhelper
...
python: pos dep, not installed
python: missing
/usr/bin/schroot -d '/build/buildd' -c halut --run-session -q -u root -p
- -- /bin/sh -c '/usr/bin/apt-get  --purge -o
DPkg::Options::=--force-confold -q -s install python-central cdbs python
debhelper python-subversion bzr=1.0-1lhm1 python 2>&1 </dev/null'
Default version of python not sufficient, no suitable version found.
Skipping for now, maybe there are alternatives.
python-pysqlite2: pos dep, not installed
python-pysqlite2: missing
using python for install
...
After installing, the following source dependencies are still
unsatisfied:
python(inst 2.4.4-2 ! >= wanted 2.5)|python-pysqlite2(missing)
...

==============================

The attached patch fixes this problem for me and additionally adds some
checks to to sbuild for wrong commandline args.

Jan-Marek


- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages sbuild depends on:
ii  adduser                     3.102        Add and remove users and groups
ii  apt                         0.6.46.4-0.1 Advanced front-end for dpkg
ii  dctrl-tools                 2.9.3        Command-line tools to process Debi
ii  dpkg-dev                    1.13.25      package building tools for Debian
ii  exim4                       4.63-17      metapackage to ease exim MTA (v4)
ii  exim4-daemon-light [mail-tr 4.63-17      lightweight exim MTA (v4) daemon
ii  perl                        5.8.8-7etch1 Larry Wall's Practical Extraction
ii  perl-modules                5.8.8-7etch1 Core Perl modules
ii  schroot                     1.1.6-1lhm1  Execute commands in a chroot envir

Versions of packages sbuild recommends:
ii  debootstrap                 0.3.3.2etch1 Bootstrap a basic Debian system
ii  fakeroot                    1.5.10       Gives a fake root environment

- -- no debconf information
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHZ+5gj6MK58wZA3cRAlmeAJ9C0UltlZV88OrTi3PHJwyKSNXX6gCfcLXD
H78LjnhSEAZmibADN17Ua0I=
=HiqA
-----END PGP SIGNATURE-----

[sbuild-fix-ored-build-dependencies.diff (text/plain, attachment)]

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

From: Roger Leigh <rleigh@whinlatter.ukfsn.org>

To: Jan-Marek Glogowski <glogow@fbihome.de>

Cc: 456934@bugs.debian.org

Subject: Re: [Buildd-tools-devel] Bug#456934: sbuild: Wrong handling of or'ed build-dependencies

Date: Tue, 18 Dec 2007 22:40:56 +0000

[Message part 1 (text/plain, inline)]

Jan-Marek Glogowski <glogow@fbihome.de> writes:

> Actually I'm using the SVN trunk r1250.
>
> I'm trying to build bzr-svn for Debian Etch.
>
> The package has the following build dependencies:
>
> Build-Depends-Indep: python-subversion, bzr (>= 1.0~), python (>= 2.5) | python-pysqlite2
>
> The following text is the relevant output from running
> sbuild -A -s -D -d halut bzr-svn_0.4.5-1lhm1.dsc
>
> ==============================
>
> ...
> Source dependencies of bzr-svn: python-central (>= 0.5), cdbs (>= 0.4.43),
> python, debhelper (>= 5.0.37.2), python-subversion, bzr (>= 1.0~), python (>= 2.5)|python-pysqlite2
> Filtering dependencies
> Requesting dpkg status for packages: python-subversion python cdbs bzr
> python-pysqlite2 python-central debhelper
> ...
> python: pos dep, not installed
> python: missing
> /usr/bin/schroot -d '/build/buildd' -c halut --run-session -q -u root -p
> -- /bin/sh -c '/usr/bin/apt-get  --purge -o
> DPkg::Options::=--force-confold -q -s install python-central cdbs python
> debhelper python-subversion bzr=1.0-1lhm1 python 2>&1 </dev/null'
> Default version of python not sufficient, no suitable version found.
> Skipping for now, maybe there are alternatives.
> python-pysqlite2: pos dep, not installed
> python-pysqlite2: missing
> using python for install
> ...
> After installing, the following source dependencies are still
> unsatisfied:
> python(inst 2.4.4-2 ! >= wanted 2.5)|python-pysqlite2(missing)
> ...
>
> ==============================
>
> The attached patch fixes this problem for me and additionally adds some
> checks to to sbuild for wrong commandline args.

Thanks.  I have altered the patch slightly to remove some of the
redundancy in the checks.  Is this OK?

Could you possibly explain what malformed syntax results in triggering
these checks?

Regarding the main fix, I can't replicate this with a stock etch
install.  Did you have any updated backports installed as well, such
as bzr?

BTW, the SVN is out of date.  We are now using git for all future
development:

  git clone git://git.debian.org/git/buildd-tools/sbuild.git


Thanks,
Roger


diff --git a/sbuild b/sbuild
index 9b6ca10..8cc2577 100755
--- a/sbuild
+++ b/sbuild
@@ -204,12 +204,19 @@ foreach $dscfile (@ARGV) {
 	my $pkgv = basename($dscfile);
 	$pkgv =~ s/\.dsc$//;
 	my ($pkg, $version) = split /_/, $pkgv;
+	my $invalid = 0;
 
 	# Download if package does not have a .dsc extension and no
 	# directory was specified.
 	my $download = 1;
  	if ($dscbase =~ m/\.dsc$/) {
 		$download = 0;
+		if( ! -f $dscfile ) {
+			$invalid = 1;
+		}
+	}
+	elsif( ! defined $version ) {
+		$invalid = 1;
 	}
 
 	print STDERR "D: dscfile = $dscfile\n" if $conf::debug;
@@ -220,7 +227,7 @@ foreach $dscfile (@ARGV) {
 	print STDERR "D: version = $version\n" if $conf::debug;
 	print STDERR "D: download = $download\n" if $conf::debug;
 
-	if ($download && $dscfile ne $pkgv) {
+	if ($invalid || ($download && $dscfile ne $pkgv)) {
 		print PLOG "Invalid source: $dscfile\n";
 		print PLOG "Skipping $pkg\n";
 		$main::pkg_status = "skipped";
@@ -1316,7 +1323,8 @@ sub filter_dependencies {
 							}
 						}
 						if(!$installable) {
-							print PLOG "no suitable version found. Skipping for now, maybe there are alternatives.\n" if !$installable;
+							print PLOG "no suitable version found. Skipping for now, maybe there are alternatives.\n";
+							next;
 						}
 					} else {
 						print PLOG "Using default version " . $policy{$name}->{defversion} . "\n";


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

[Message part 2 (application/pgp-signature, inline)]

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

From: Michael Banck <mbanck@debian.org>

To: 456934@bugs.debian.org

Cc: Jan-Marek Glogowski <glogow@fbihome.de>

Subject: Re: Bug#456934: [Buildd-tools-devel] Bug#456934: sbuild: Wrong handling of or'ed build-dependencies

Date: Wed, 19 Dec 2007 01:15:25 +0100

On Tue, Dec 18, 2007 at 10:40:56PM +0000, Roger Leigh wrote:
> Jan-Marek Glogowski <glogow@fbihome.de> writes:
> > I'm trying to build bzr-svn for Debian Etch.
> >
> > The package has the following build dependencies:
> >
> > Build-Depends-Indep: python-subversion, bzr (>= 1.0~), python (>= 2.5) | python-pysqlite2

> Thanks.  I have altered the patch slightly to remove some of the
> redundancy in the checks.  Is this OK?

Isn't it usual sbuild behaviour to only try the first package of a set
of alternatives?


Michael

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

From: Jan-Marek Glogowski <glogow@fbihome.de>

To: Roger Leigh <rleigh@whinlatter.ukfsn.org>

Cc: 456934@bugs.debian.org

Subject: Re: [Buildd-tools-devel] Bug#456934: sbuild: Wrong handling of or'ed build-dependencies

Date: Wed, 19 Dec 2007 07:54:53 +0100 (CET)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

> Thanks.  I have altered the patch slightly to remove some of the
> redundancy in the checks.  Is this OK?

Should be ok.

> Could you possibly explain what malformed syntax results in triggering
> these checks?

It just happend to me, that I changed the directory, and ran a sbuild
command from the history, or used just a package name instead of a
'package_version' - this resulted in undefined $version variable which
made Perl spit a lot of warnings because of undefined concated strings and
obviously made the build fail. This simply catches the wrong supplied
packages argument much earlier.

> Regarding the main fix, I can't replicate this with a stock etch
> install.  Did you have any updated backports installed as well, such
> as bzr?

I have also compiled bzr, otherwise the build fails because of the missing
bzr versioned dependency:

Build-Depends-Indep: python-subversion, bzr (>= 1.0~), python (>= 2.5) | python-pysqlite2
Build-Depends: python-central (>= 0.5), cdbs (>= 0.4.43), python, debhelper (>= 5.0.37.2)

Otherwise all dependencies are from etch.

> BTW, the SVN is out of date.  We are now using git for all future
> development:
>
>   git clone git://git.debian.org/git/buildd-tools/sbuild.git

Thanks for this info. I will update my packages from this git repo and
check, if bzr-svn still fails. This code in sbuild is still the same, as
in the SVN repo, so I guess it'll also fail. I'll report back after I have
updated my packages.

Thanks

Jan-Marek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHaMBAj6MK58wZA3cRAratAKCJ5QRHs89+CXWdZPDmm91Ug2n9NACgj5g+
PY0eiM84rW+pLab2X7ZS0fU=
=9Ri5
-----END PGP SIGNATURE-----

Message #25 received at 456934@bugs.debian.org (full text, mbox, reply):

From: Jan-Marek Glogowski <glogow@fbihome.de>

To: Michael Banck <mbanck@debian.org>

Cc: 456934@bugs.debian.org

Subject: Re: Bug#456934: [Buildd-tools-devel] Bug#456934: sbuild: Wrong handling of or'ed build-dependencies

Date: Wed, 19 Dec 2007 08:10:37 +0100 (CET)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On Tue, Dec 18, 2007 at 10:40:56PM +0000, Roger Leigh wrote:
> > Jan-Marek Glogowski <glogow@fbihome.de> writes:
> > > I'm trying to build bzr-svn for Debian Etch.
> > >
> > > The package has the following build dependencies:
> > >
> > > Build-Depends-Indep: python-subversion, bzr (>= 1.0~), python (>= 2.5) | python-pysqlite2
>
> > Thanks.  I have altered the patch slightly to remove some of the
> > redundancy in the checks.  Is this OK?
>
> Isn't it usual sbuild behaviour to only try the first package of a set
> of alternatives?

Currently yes, but I consider this a bug. The patched code already runs
in a loop to check for all alternatives, but it currently fails, if it
can't satisfy a versioned dependency.

sbuild[1301]: foreach $d ($dep, @{$dep->{'Alternatives'}}) {

Without the 'next', $installable is set, even if it's not installable.

sbuild[1325]: $installable = $name if !$installable;

Jan-Marek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHaMPwj6MK58wZA3cRArM1AJ94D8nv0eMhRY0Wbyu92aJF66Q+sgCbBFa6
UzluK40y/1HcXf/q0lZdbas=
=yzAJ
-----END PGP SIGNATURE-----

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

From: Michael Banck <mbanck@debian.org>

To: Jan-Marek Glogowski <glogow@fbihome.de>

Cc: 456934@bugs.debian.org

Subject: Re: Bug#456934: [Buildd-tools-devel] Bug#456934: sbuild: Wrong handling of or'ed build-dependencies

Date: Wed, 19 Dec 2007 14:22:26 +0100

On Wed, Dec 19, 2007 at 08:10:37AM +0100, Jan-Marek Glogowski wrote:
> > Isn't it usual sbuild behaviour to only try the first package of a set
> > of alternatives?
> 
> Currently yes, but I consider this a bug. The patched code already runs
> in a loop to check for all alternatives, but it currently fails, if it
> can't satisfy a versioned dependency.

Maybe this is a divergence of the sbuild package from upstream sbuild
then.  Fact is that the buildds will show this behaviour, so I am not
sure changing it in the sbuild package is the best solution.


Michael

Message #35 received at 456934@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@whinlatter.ukfsn.org>

To: Michael Banck <mbanck@debian.org>

Cc: 456934@bugs.debian.org, Jan-Marek Glogowski <glogow@fbihome.de>

Subject: Re: [Buildd-tools-devel] Bug#456934: Bug#456934: sbuild: Wrong handling of or'ed build-dependencies

Date: Wed, 19 Dec 2007 22:34:07 +0000

[Message part 1 (text/plain, inline)]

Michael Banck <mbanck@debian.org> writes:

> On Wed, Dec 19, 2007 at 08:10:37AM +0100, Jan-Marek Glogowski wrote:
>> > Isn't it usual sbuild behaviour to only try the first package of a set
>> > of alternatives?
>> 
>> Currently yes, but I consider this a bug. The patched code already runs
>> in a loop to check for all alternatives, but it currently fails, if it
>> can't satisfy a versioned dependency.
>
> Maybe this is a divergence of the sbuild package from upstream sbuild
> then.  Fact is that the buildds will show this behaviour, so I am not
> sure changing it in the sbuild package is the best solution.

I tend to agree here, given that one of (if not the main) primary uses
of sbuild is to check that sources will autobuild correctly on the
main buildds, using the other sbuild.  This is one place where we
definitely need to be compatible.

However, I wouldn't be opposed to adding a command-line and/or
configuration option which would allow the user to alter this, so long
as it is not the default behaviour.  Adding a variable to
Sbuild/Conf.pm is pretty easy, as is a new command-line option.  If
you would like to make a patch for that, that would be super.

I have committed all of the other changes, as the diff below.  If you
do a "git pull" or a fresh "git clone", you should get this.


diff --git a/debian/changelog b/debian/changelog
index 772d8fc..d5faed1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,10 @@ sbuild (0.57) unstable; urgency=low
 
   * Sbuild/Chroot.pm: set APT::Install-Recommends to false inside the
     chroot (Closes: #449253).
+  * sbuild:
+    - Add additional syntax checks.  Thanks to Jan-Marek Glogowski.
+    - filter_dependencies: Remove redundant conditional.  Thanks to
+      Jan-Marek Glogowski.
 
  -- Roger Leigh <rleigh@debian.org>  Sun, 02 Dec 2007 15:03:04 +0000
 
diff --git a/sbuild b/sbuild
index 9b6ca10..5464144 100755
--- a/sbuild
+++ b/sbuild
@@ -204,12 +204,19 @@ foreach $dscfile (@ARGV) {
 	my $pkgv = basename($dscfile);
 	$pkgv =~ s/\.dsc$//;
 	my ($pkg, $version) = split /_/, $pkgv;
+	my $invalid = 0;
 
 	# Download if package does not have a .dsc extension and no
 	# directory was specified.
 	my $download = 1;
  	if ($dscbase =~ m/\.dsc$/) {
 		$download = 0;
+		if( ! -f $dscfile ) {
+			$invalid = 1;
+		}
+	}
+	elsif( ! defined $version ) {
+		$invalid = 1;
 	}
 
 	print STDERR "D: dscfile = $dscfile\n" if $conf::debug;
@@ -220,7 +227,7 @@ foreach $dscfile (@ARGV) {
 	print STDERR "D: version = $version\n" if $conf::debug;
 	print STDERR "D: download = $download\n" if $conf::debug;
 
-	if ($download && $dscfile ne $pkgv) {
+	if ($invalid || ($download && $dscfile ne $pkgv)) {
 		print PLOG "Invalid source: $dscfile\n";
 		print PLOG "Skipping $pkg\n";
 		$main::pkg_status = "skipped";
@@ -1316,7 +1323,7 @@ sub filter_dependencies {
 							}
 						}
 						if(!$installable) {
-							print PLOG "no suitable version found. Skipping for now, maybe there are alternatives.\n" if !$installable;
+							print PLOG "no suitable version found. Skipping for now, maybe there are alternatives.\n";
 						}
 					} else {
 						print PLOG "Using default version " . $policy{$name}->{defversion} . "\n";



Regards,
Roger

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

[Message part 2 (application/pgp-signature, inline)]

Message #40 received at 456934@bugs.debian.org (full text, mbox, reply):

From: Jan-Marek Glogowski <glogow@fbihome.de>

To: Roger Leigh <rleigh@whinlatter.ukfsn.org>

Cc: Michael Banck <mbanck@debian.org>, 456934@bugs.debian.org

Subject: Add option to select the build dependency check algorithm

Date: Fri, 21 Dec 2007 10:31:21 +0100 (CET)

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 19 Dec 2007, Roger Leigh wrote:

> Michael Banck <mbanck@debian.org> writes:
>
> > On Wed, Dec 19, 2007 at 08:10:37AM +0100, Jan-Marek Glogowski wrote:
> >> > Isn't it usual sbuild behaviour to only try the first package of a set
> >> > of alternatives?
> >>
> >> Currently yes, but I consider this a bug. The patched code already runs
> >> in a loop to check for all alternatives, but it currently fails, if it
> >> can't satisfy a versioned dependency.
> >
> > Maybe this is a divergence of the sbuild package from upstream sbuild
> > then.  Fact is that the buildds will show this behaviour, so I am not
> > sure changing it in the sbuild package is the best solution.
>

...

> However, I wouldn't be opposed to adding a command-line and/or
> configuration option which would allow the user to alter this, so long
> as it is not the default behaviour.  Adding a variable to
> Sbuild/Conf.pm is pretty easy, as is a new command-line option.  If
> you would like to make a patch for that, that would be super.

Ok - I have attached a new patch to make the dependeny check algorith
select and configureable. Default is the old behaviour, but it can be
changed to check for alternatives via sbuild argument (-C) or by changing
check_depends_algorithm in the SBUILD BEHAVIOUR config group.

Tested with the bzr-svn package, which still fails with default, but
finishes with the alternatives algorithm.

Jan-Marek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHa4ftj6MK58wZA3cRAjI9AJ9HFuarByB6ia8+TmGtA1HORTprrwCfTJkw
zkXece2T+Thtk1QQwkO8BoU=
=aSRQ
-----END PGP SIGNATURE-----

[sbuild-check-depends-algorithm.diff (text/plain, attachment)]

Message #45 received at 456934@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@whinlatter.ukfsn.org>

To: Jan-Marek Glogowski <glogow@fbihome.de>

Cc: 456934@bugs.debian.org, Michael Banck <mbanck@debian.org>

Subject: Re: [Buildd-tools-devel] Bug#456934: Add option to select the build dependency check algorithm

Date: Sat, 22 Dec 2007 16:40:50 +0000

[Message part 1 (text/plain, inline)]

Jan-Marek Glogowski <glogow@fbihome.de> writes:

> On Wed, 19 Dec 2007, Roger Leigh wrote:
>
>> Michael Banck <mbanck@debian.org> writes:
>>
>> > On Wed, Dec 19, 2007 at 08:10:37AM +0100, Jan-Marek Glogowski wrote:
>> >> > Isn't it usual sbuild behaviour to only try the first package of a set
>> >> > of alternatives?
>> >>
>> >> Currently yes, but I consider this a bug. The patched code already runs
>> >> in a loop to check for all alternatives, but it currently fails, if it
>> >> can't satisfy a versioned dependency.
>> >
>> > Maybe this is a divergence of the sbuild package from upstream sbuild
>> > then.  Fact is that the buildds will show this behaviour, so I am not
>> > sure changing it in the sbuild package is the best solution.
>>
[>
> ...
>
>> However, I wouldn't be opposed to adding a command-line and/or
>> configuration option which would allow the user to alter this, so long
>> as it is not the default behaviour.  Adding a variable to
>> Sbuild/Conf.pm is pretty easy, as is a new command-line option.  If
>> you would like to make a patch for that, that would be super.
>
> Ok - I have attached a new patch to make the dependeny check algorith
> select and configureable. Default is the old behaviour, but it can be
> changed to check for alternatives via sbuild argument (-C) or by changing
> check_depends_algorithm in the SBUILD BEHAVIOUR config group.
>
> Tested with the bzr-svn package, which still fails with default, but
> finishes with the alternatives algorithm.

Many thanks for the patch.  I have committed this with a few minor
changes:

- I changed "first_only" to "first-only".
- Some of the missing $/@/% symbols you added to the config files were
  incorrect (type did not match the export e.g. @ instead of %).
- I removed the "-C" option to just leave
- "--check-depends-algorithm".  I don't think that an option most
  users will never use really needs a single letter abbreviation.  If
  you use it regularly, a shell alias or wrapper script can take care
  of the extra typing.

I hope this is OK.  The committed changes are now in the main repo, so
you can pull them.  If there's anything you want changing or adding,
just let me know.


Regards,
Roger

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

[Message part 2 (application/pgp-signature, inline)]

Message #50 received at 456934-done@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@whinlatter.ukfsn.org>

To: 456934-done@bugs.debian.org

Subject: Close fixed bug

Date: Mon, 21 Jan 2008 23:31:30 +0000

[Message part 1 (text/plain, inline)]

Version: 0.57.0-1

Closing this fixed bug.


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

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.