Debian Bug report logs - #570935
debhelper: possibility to enable an addon with an environment variable

Reply or subscribe to this bug.

Toggle useless messages

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

From: Raphaël Hertzog <hertzog@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: debhelper: possibility to enable an addon with an environment variable

Date: Mon, 22 Feb 2010 12:32:07 +0100

Package: debhelper
Version: 7.4.15
Severity: wishlist

Hello,

it would be nice to be able to enable a dh addon without modifying the
source package. Given this I think the best way is to have an environment
variable where you can list supplementary addons to enable.

I can think of multiple usages in various contexts (mainly in the context
of derivatives distribution / downstream users of our packaging):
- add the dh_buildinfo call because you really want the build information
  for as many packages as possible for debugging purposes
- add an addon to strip data (think documentation for an embedded
  distribution)
- add an addon to extract data from the packages during build (think
  ddebs)

Cheers,

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debhelper depends on:
ii  binutils                      2.20-6     The GNU assembler, linker and bina
ii  dpkg-dev                      1.15.6     Debian package development tools
ii  file                          5.04-1     Determines file type using "magic"
ii  html2text                     1.3.2a-14  advanced HTML to text converter
ii  man-db                        2.5.7-1    on-line manual pager
ii  perl                          5.10.1-11  Larry Wall's Practical Extraction 
ii  perl-base                     5.10.1-11  minimal Perl system
ii  po-debconf                    1.0.16     tool for managing templates file t

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make                       0.51       tool that converts source archives

-- no debconf information

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

From: Joey Hess <joeyh@debian.org>

To: Raphaël Hertzog <hertzog@debian.org>, 570935@bugs.debian.org

Subject: Re: Bug#570935: debhelper: possibility to enable an addon with an environment variable

Date: Tue, 11 May 2010 16:15:41 -0400

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

Raphaël Hertzog wrote:
> it would be nice to be able to enable a dh addon without modifying the
> source package. Given this I think the best way is to have an environment
> variable where you can list supplementary addons to enable.
> 
> I can think of multiple usages in various contexts (mainly in the context
> of derivatives distribution / downstream users of our packaging):
> - add the dh_buildinfo call because you really want the build information
>   for as many packages as possible for debugging purposes
> - add an addon to strip data (think documentation for an embedded
>   distribution)
> - add an addon to extract data from the packages during build (think
>   ddebs)

I wonder if dealing with this in dh is the best place. For each of the
above examples, it will only solve things for the 20% (or whatever it is
now) of packages that use dh.

OTOH, putting a wrapper about dpkg-deb will affect 100% of packages. And
all your examples seem amenable to being run at dpkg-deb --build time.
I'm not sure if data gathering and binary package tree tweaks are all
the use cases that make sense, or just happen to be the sort you thought
up.

Of course, dh_builddeb *is* a wrapper around dpkg-deb that 99% of
packages use. So maybe the hook would best go there. Or maybe it would
make sense to build it directly into dpkg-builddeb?

-- 
see shy jo

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

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

From: Raphael Hertzog <hertzog@debian.org>

To: Joey Hess <joeyh@debian.org>

Cc: 570935@bugs.debian.org

Subject: Re: Bug#570935: debhelper: possibility to enable an addon with an environment variable

Date: Wed, 12 May 2010 07:56:42 +0200

On Tue, 11 May 2010, Joey Hess wrote:
> OTOH, putting a wrapper about dpkg-deb will affect 100% of packages. And
> all your examples seem amenable to being run at dpkg-deb --build time.
> I'm not sure if data gathering and binary package tree tweaks are all
> the use cases that make sense, or just happen to be the sort you thought
> up.
> 
> Of course, dh_builddeb *is* a wrapper around dpkg-deb that 99% of
> packages use. So maybe the hook would best go there. Or maybe it would
> make sense to build it directly into dpkg-builddeb?

When I submitted this bug, I have recorded a similar wishlist against dpkg
itself (#570934). So I believe both to be useful. Of course, the dh
approach works only for packages using dh/debhelper 7.

The first two examples come from discussions I had with people involved in
Maemo when Meego started. In the context of Meego, the packaging could be
relatively uniform and standardized around dh 7 and that sort of freedom
would be welcome.

Note that this feature can also be useful when developing a new addon and
when you want to validate that it doesn't break packages by asking lucas
to do a mass rebuild.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/

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

From: Raphael Hertzog <hertzog@debian.org>

To: Joey Hess <joeyh@debian.org>

Cc: 570935@bugs.debian.org

Subject: Re: Bug#570935: debhelper: possibility to enable an addon with an environment variable

Date: Mon, 14 Jun 2010 14:26:07 +0200

Hi,

On Wed, 12 May 2010, Raphael Hertzog wrote:
> Note that this feature can also be useful when developing a new addon and
> when you want to validate that it doesn't break packages by asking lucas
> to do a mass rebuild.

While discussing with Sébastien Bacher today, I noticed that this feature
would also be useful to Ubuntu to be able to enable addons dedicated 
to "langpacks" (move the translations out of original packages to some
dedicated ones containing a single translation for many software) and
similar changes that are currently only partially supported through
changes to their CDBS class (gnome.mk).

This would on the long term reduce the need to fork debhelper itself
which is a good thing IMO.

This mail follows an IRC dicussion triggered by
http://lists.debian.org/1276511250.4912.18.camel@seb128-laptop

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/

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

From: Dmitrijs Ledkovs <dmitrijs.ledkovs@canonical.com>

To: 570935@bugs.debian.org

Subject: Re: possibility to enable an addon with an environment variable

Date: Wed, 17 Apr 2013 09:11:37 +0100

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

Well, it's 3 years later and dh has very good adoption. [1]

Dh addons are very nice to use, but they require ./debian/rules
modification.

My addon is "graceful", e.g. it does nothing if it cannot find its
configuration files under ./debian/. I'd very much enjoy if I can
specify "auto-enable" in my sequence.pm file. Maybe allow an option in
debhelper conffile whether "auto-enable" flags in addons should be
honoured and/or white list them?

On the system-wide level, it would be nice to have a conffile and
specify addons that get auto-enabled. In at least ubuntu for a large set
of packages we do following:
* strip language translations into language packs
* generate ddebs into dbgsym packages
* optimise png and svg files
* symlink duplicate files
* scan logs for Implicit Pointer Conversions and fail the build.

At the moment some of above is achieved by ugly diversions of e.g.
dpkg-builddeb and such like. Which are hard to maintain right, and are
sometimes slower than equivalent dh addons.

[1] http://www.lucas-nussbaum.net/blog/?p=751

-- 
Regards,
Dmitrijs.

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

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

From: Joey Hess <joeyh@debian.org>

To: Dmitrijs Ledkovs <dmitrijs.ledkovs@canonical.com>, 570935@bugs.debian.org

Subject: Re: Bug#570935: possibility to enable an addon with an environment variable

Date: Wed, 17 Apr 2013 10:54:02 -0400

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

Dmitrijs Ledkovs wrote:
> Well, it's 3 years later and dh has very good adoption. [1]
> 
> Dh addons are very nice to use, but they require ./debian/rules
> modification.
> 
> My addon is "graceful", e.g. it does nothing if it cannot find its
> configuration files under ./debian/. I'd very much enjoy if I can
> specify "auto-enable" in my sequence.pm file. Maybe allow an option in
> debhelper conffile whether "auto-enable" flags in addons should be
> honoured and/or white list them?
> 
> On the system-wide level, it would be nice to have a conffile and
> specify addons that get auto-enabled. In at least ubuntu for a large set
> of packages we do following:
> * strip language translations into language packs
> * generate ddebs into dbgsym packages
> * optimise png and svg files
> * symlink duplicate files
> * scan logs for Implicit Pointer Conversions and fail the build.
> 
> At the moment some of above is achieved by ugly diversions of e.g.
> dpkg-builddeb and such like. Which are hard to maintain right, and are
> sometimes slower than equivalent dh addons.

Do you have a patch?

Worth noting that the sister bug filed on dpkg has been wontfixed (#570934).

My main reason to consider this would be, I think, if it has the
potential to stop debhelper getting bugs like #705545 filed asking for
temporary changes that affect domains outside my expertise.

-- 
see shy jo

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

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

From: "Paul R. Tagliamonte" <paultag@gmail.com>

To: 570935@bugs.debian.org, control@bugs.debian.org

Subject: Patch

Date: Tue, 12 Dec 2017 23:39:18 -0500

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

tags 570935 + patch
thanks

Patch adding a DH_WITH environment var attached.

-- 
:wq

[0001-Add-DH_WITH-env-variable-to-specify-local-addons.patch (text/x-patch, attachment)]

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

From: "Paul R. Tagliamonte" <paultag@gmail.com>

To: 570935@bugs.debian.org, debhelper-devel@lists.alioth.debian.org

Subject: Re: Patch

Date: Wed, 27 Dec 2017 23:16:24 -0500

Hey all,

Please keep me on CC, I'm not subscribed

Just bumping this to the development list too. The patch seems to work
fine here. Can someone provide some review or consider merging it?

Thanks!
  Paul

On Tue, Dec 12, 2017 at 11:39 PM, Paul R. Tagliamonte <paultag@gmail.com> wrote:
> tags 570935 + patch
> thanks
>
> Patch adding a DH_WITH environment var attached.
>
> --
> :wq



-- 
:wq

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

From: Niels Thykier <niels@thykier.net>

To: "Paul R. Tagliamonte" <paultag@gmail.com>, 570935@bugs.debian.org, Debhelper Maintainers <debhelper-devel@lists.alioth.debian.org>

Subject: Re: [debhelper-devel] Patch

Date: Thu, 28 Dec 2017 10:11:00 +0000

Paul R. Tagliamonte:
> Hey all,
> 
> Please keep me on CC, I'm not subscribed
> 
> Just bumping this to the development list too. The patch seems to work
> fine here. Can someone provide some review or consider merging it?
> 
> Thanks!
>   Paul
> 
> On Tue, Dec 12, 2017 at 11:39 PM, Paul R. Tagliamonte <paultag@gmail.com> wrote:
>> tags 570935 + patch
>> thanks
>>
>> Patch adding a DH_WITH environment var attached.
>>
>> --
>> :wq
> 
> 
> 

Hi Paul,

Thanks for looking at improving debhelper.

I have been looking at this, and I am left with a concern and one piece
of "bike-shedding".

The situation:
==============
dh add-ons are order sensitive.  That is, there are cases where "--with
a,b" vs. "--with b,a" behaves different (the only know example was the
autotools-dev and autoreconf add-ons, where you always wanted --with
autotools-dev,autoreconf - in that order).

This is a nasty misfeature.  Unfortunately, it is a design flaw and
cannot be trivially fixed without rewriting the entire dh add-on system.

The concern:
============

A package maintainer can trivially shuffle the order of two add-ons, but
the builder does not have this option.  With the above mentioned
"misfeature", I foresee that eventually someone will need to place an
add-on in a different order than this patch allows (e.g. so they can
inject theirs in the middle of two add-ons enabled by the package
maintainer).

I think the best solution here is for someone (probably me) to sit down
and redesign the add-on system to avoid/fix the above misfeature.  I
suppose this can be done later if that ever becomes relevant (with this
mail just serving to record the issue to cluebat myself if/when that
becomes relevant).

The bike-shedding:
==================

I would prefer that the name of the variable(s) uses "add-on" / "ADDON"
(e.g. DH_EXTRA_ADDONS) instead of WITH (DH_WITH).  What it controls is
which adds you enable - "WITH" says nothing about what it does (I
appreciate it is a reference to the command line option, but I think an
"ADDONS"-based name will be less confusing to newcomers/people with
less/no debhelper experience).

Thanks,
~Niels

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

From: "Paul R. Tagliamonte" <paultag@gmail.com>

To: Niels Thykier <niels@thykier.net>

Cc: 570935@bugs.debian.org, Debhelper Maintainers <debhelper-devel@lists.alioth.debian.org>

Subject: Re: [debhelper-devel] Patch

Date: Thu, 28 Dec 2017 11:12:47 -0500

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

On Thu, Dec 28, 2017 at 5:11 AM, Niels Thykier <niels@thykier.net> wrote:
> Hi Paul,
>
> Thanks for looking at improving debhelper.

Of course!

> I have been looking at this, and I am left with a concern and one piece
> of "bike-shedding".
>
> The situation:
> ==============
> dh add-ons are order sensitive.  That is, there are cases where "--with
> a,b" vs. "--with b,a" behaves different (the only know example was the
> autotools-dev and autoreconf add-ons, where you always wanted --with
> autotools-dev,autoreconf - in that order).
>
> This is a nasty misfeature.  Unfortunately, it is a design flaw and
> cannot be trivially fixed without rewriting the entire dh add-on system.
>
> The concern:
> ============
>
> A package maintainer can trivially shuffle the order of two add-ons, but
> the builder does not have this option.  With the above mentioned
> "misfeature", I foresee that eventually someone will need to place an
> add-on in a different order than this patch allows (e.g. so they can
> inject theirs in the middle of two add-ons enabled by the package
> maintainer).
>
> I think the best solution here is for someone (probably me) to sit down
> and redesign the add-on system to avoid/fix the above misfeature.  I
> suppose this can be done later if that ever becomes relevant (with this
> mail just serving to record the issue to cluebat myself if/when that
> becomes relevant).


Yeah, that's a nasty one. I added a warning in the docs for folks to not
use this envvar if at all possible, so hopefully this prevents this
from causing that situation to become more complex.

> The bike-shedding:
> ==================
>
> I would prefer that the name of the variable(s) uses "add-on" / "ADDON"
> (e.g. DH_EXTRA_ADDONS) instead of WITH (DH_WITH).  What it controls is
> which adds you enable - "WITH" says nothing about what it does (I
> appreciate it is a reference to the command line option, but I think an
> "ADDONS"-based name will be less confusing to newcomers/people with
> less/no debhelper experience).

I hated the name DH_WITH, so great name, updated patch attached! I
built and tested the new patch, and it still appears to work!

> Thanks,
> ~Niels
>

Thanks, Niels,
  Paul



-- 
:wq

[0001-Add-DH_EXTRA_ADDONS-env-variable-to-specify-local-ad.patch (text/x-patch, attachment)]

Message #59 received at 570935-close@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 570935-close@bugs.debian.org

Subject: Bug#570935: fixed in debhelper 11.1

Date: Sat, 06 Jan 2018 21:34:07 +0000

Source: debhelper
Source-Version: 11.1

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.

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 570935@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Niels Thykier <niels@thykier.net> (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@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sat, 06 Jan 2018 21:17:47 +0000
Source: debhelper
Binary: debhelper dh-systemd
Architecture: source
Version: 11.1
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers <debhelper-devel@lists.alioth.debian.org>
Changed-By: Niels Thykier <niels@thykier.net>
Description:
 debhelper  - helper programs for debian/rules
 dh-systemd - debhelper add-on to handle systemd unit files - transitional pack
Closes: 566861 570935 593382 650129 653640 709384 761272 814285 858834 873831 880840 884556 884574 885998 886037 886038 886127 886279
Changes:
 debhelper (11.1) unstable; urgency=medium
 .
   [ Paul Tagliamonte ]
   * dh: Provide the DH_EXTRA_ADDONS environment as a method for
     e.g. derivatives to enable additional debhelper add-ons.
     It is *not* a replacement for the --with parameter (which
     package maintainers should still use).  (Closes: #570935)
 .
   [ Hideki Yamane ]
   * Fix typo of unnecessary.  (Closes: #884574)
 .
   [ Niels Thykier ]
   * dh_missing: Support wildcards in debian/not-installed.  Thanks
     to Maximiliano Curia for the suggestion.  (Closes: #884556)
   * dh_missing: Tweak handling of missing source directory and
     single binary packages.
   * dh_missing: Make --list-missing the default in compat 12.
     Thanks to Daniel Leidert and Christian Göttsche for the
     suggestions.  (Closes: #650129, #858834)
   * meson.pm: Set LC_ALL to C.UTF-8 when invoking meson and
     debcrossgen (helper tool for cross-building).  Thanks to
     Jeremy Bicha for the suggestion.  (Closes: #873831)
   * dh_makeshlibs: Avoid forking a shell per line in the
     generated shlibs file.
   * dh_makeshlibs: Find all libraries with an unversioned SONAME
     field (and not just the unversioned ones containing ".so").
   * dh_makeshlibs: In compat 12, stop passing ELF binaries without
     a SONAME to dpkg-gensymbols.  Thanks to Steve Langasek for the
     report.  (Closes: #653640)
   * dh_compress: In compat 12, stop compressing any thing in
     /usr/share/doc/$pkg/examples.  Thanks to Piotr Ożarowski for
     the suggestion.  (Closes: #593382)
   * dh_installinit: Support a new --no-enable parameter to setup the
     init script with the "defaults-disabled" and add the proper
     versioned dependency on "init-system-helpers (>= 1.51)", which is
     the first (functional) version with support for
     "defaults-disabled".  Thanks to Laurent Bigonville for the
     report and Evgeni Golov for filing #857452.  (Closes: #709384)
   * Dh_Lib.pm: Make "exit 1" the default error-handler instead of
     "exit $?" as this makes it easier to migrate from sed-based
     autoscript substitutions to the new hash-based ones.
   * autoscripts/*systemd*: Also use "|| true" in removal scripts for
     systemd related tools if we do it in other scripts for the same
     command.  Thanks to Laurent Bigonville for the report.
     (Closes: #761272)
   * dh_installinit: Perform the autoscript substitutions without
     needing a shell.
   * dh_clean: Skip cleaning in the '.pc' and '_darcs' directories.
     (Closes: #566861)
   * dh_strip: Do not strip debug symbols in ".../debug/.build-id/".
     Thanks to Mattia Rizzolo for reporting the bug.
     (Closes: #886037)
   * dh_gencontrol: Deduplicate debug-ids before inserting them into
     the control file.  Thanks to Mattia Rizzolo for reporting the
     bug.  (Closes: #886038)
   * dh: Rewrite sequence handling to ensure that dh does not "inline"
     a subtarget of a target it recurses into.  Thanks to James
     Cowgill for reporting the bug.  (Closes: #880840)
   * d/control: Add a Breaks against cmake (<< 3.8~) to ensure that
     cmake response to the /run change in compat 11.  Thanks to
     Adrian Bunk for the suggestion.  (Closes: #886127)
   * Dh_Lib.pm/dh_testroot: Support the DEB_GAIN_ROOT_CMD environment
     that replaces DPKG_GAIN_ROOT_CMD.
   * dh_installinit/dh_installsystemd: Re-order snippets so service
     handling is always the first to happen in removal scripts and last
     to happen on install scripts.  This means that configuration file
     management and systemd-tmpfiles handling will now always happen
     before the service is started on install/upgrade.  Thanks to
     Дилян Палаузов and Simon McVittie for reporting the bug.
     (Closes: #814285, #885998)
     - Note that the deprecated dh_systemd_enable and dh_systemd_start
       helpers have not been changed.  Services handled by these may
       still be started before configuration management happens.
   * debian/control: Drop some very old versioned constraints that are
     no longer important.
   * dh_installsystemd: Fix NOOP PROMISE to account for the tmpfiles.d
     files.
   * debian/control: Bump Standards-Versions to 4.1.3 - no additional
     changes required.
 .
   [ Translations ]
   * Update French translation (Baptiste Jammet)  (Closes: #886279)
Checksums-Sha1:
 dff994214896f3335e9ceac13f287204a0c83673 1773 debhelper_11.1.dsc
 35645827669046c18fdbd833a3d41fc3badc866f 448648 debhelper_11.1.tar.xz
 c89cd78ea798b26be0ae8e6e65d289457638fdc6 4500 debhelper_11.1_source.buildinfo
Checksums-Sha256:
 6b7e07a5634b74ec12d6fa0daac4bced2407feb35e0197ac7eb32acd91e9bdf8 1773 debhelper_11.1.dsc
 25f22ace3b9c053047ca374012ffa6cb3eb913eaf9b167713cd876b27dec5ddf 448648 debhelper_11.1.tar.xz
 1ebc16c4b4fe2529ad5038a0520ae01255db595cd7b442cf8c15c2dc7bf48b71 4500 debhelper_11.1_source.buildinfo
Files:
 4285bb7641ba6ab68f4df9490fb61cf3 1773 devel optional debhelper_11.1.dsc
 ebd851f94e224a3d120c2f38ec370fed 448648 devel optional debhelper_11.1.tar.xz
 3a9cee0305d831eedad2b9bb0c2127c9 4500 devel optional debhelper_11.1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEsxMaRR2/33ygW0GXBUu7n32AZEIFAlpRPSsACgkQBUu7n32A
ZEJydg/+MdmCwIrIOw4PuLZ/vAy6OEM2rnu4qiuM8Khq1dX1RJjNgv/MAVPVJLTP
R/D0mmOulIYJiobxlVbfjr7tNFFBmaf42U9kfANEkHwfJRUc4BqYwtkSRU/wv4m+
vfRDIuEj+uB8ArTgLIBxrfolI/lAJXCo7C1IB/l6GZ6276LanE6+0waVou9Pmf1L
MAgVPaQY43Rc+OYe2OyMI29/G5yhiebR1yjfVNxFuofUTIShoUDckGCensw61EvH
PwA44NsB7iO0hB7pDAluouzswS5bqa4qXg1CpxQEW+W+FQPpTjQx7Ew/VOgDT7z4
dk4dkEdyL1VjOQvgbTUVQ3L4q/a/33fHzvViuDHKiBLA5fanmh4gfVCyVYSleVW7
Su9iGBEfku68PmsEi3KAFQk4FXj40I13djlIiLzPwStxcVDhUqw99u5J+p6ixzEb
hUHG4VYIBZ4Tt1Ud+u7JoW2QCttA3l/J/sRDkyDNfLd7mOVv55liE9QGwVOfKwmd
5PnzDEEI3mWZE0dWsVZ89wyQM6AFWCJC0ZFznJ9Pa2kdnKVPakOfbaYhsdxhD5q6
GztcvxZefYqR5oWsEX9j8Cs2COmGqMmwYuqN4VFqf1pJNoJ/vVErXujh3oejP9/w
1oFEqYlxYhjQyGqPn2sRDrfq8EG0TTgBtyf4IFG1koX/gvTD9IM=
=QRfL
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.