liblopsub1t64 is not binNMU-safe. It installs debian/changelog directly
using install. The file is architecture-specific and installed into a
shared location. The package is Multi-Arch: same. Upon coinstallation,
dpkg fails to unpack.

I suggest using dh_installchangelog as it separates the
architecture-dependent part.

Helmut

Thanks for pointing out this issue. Is the below sufficient to fix it?

Best
Andre
---
commit c0cf8e24b72effbe53c7dd840ead5130b87151d9
Author: Andre Noll <maan@tuebingen.mpg.de>
Date:   Sat Jan 31 17:10:31 2026 +0100

    debian: Use dh_installchangelogs

    liblopsub1t64 is not binNMU-safe. It installs debian/changelog directly
    using install. The file is architecture-specific and installed into a shared
    location. The package is Multi-Arch: same. Upon coinstallation, dpkg fails
    to unpack.

    Use dh_installchangelog as it separates the architecture-dependent part.

    Suggested-by: Helmut Grohne <helmut@subdivi.de>

diff --git a/debian/rules b/debian/rules
index 9801fe6..1657fa8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -54,10 +54,7 @@ binary: build
 	echo 'activate-noawait ldconfig' > $(DESTDIR)/DEBIAN/triggers
 	$(INST_FILE) debian/copyright $(DOCS_DIR)/copyright
 	$(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright
-	$(INST_FILE) debian/changelog $(DOCS_DIR)/changelog.Debian
-	$(INST_FILE) debian/changelog $(DEVDOCS_DIR)/changelog.Debian
-	gzip -fn9 $(DOCS_DIR)/changelog.Debian
-	gzip -fn9 $(DEVDOCS_DIR)/changelog.Debian
+	dh_installchangelogs
 	dh_fixperms
 	dh_makeshlibs
 	dh_shlibdeps

Thanks for pointing out this issue. Is the below sufficient to fix it?

Best
Andre
---
commit c0cf8e24b72effbe53c7dd840ead5130b87151d9
Author: Andre Noll <maan@tuebingen.mpg.de>
Date:   Sat Jan 31 17:10:31 2026 +0100

    debian: Use dh_installchangelogs

    liblopsub1t64 is not binNMU-safe. It installs debian/changelog directly
    using install. The file is architecture-specific and installed into a shared
    location. The package is Multi-Arch: same. Upon coinstallation, dpkg fails
    to unpack.

    Use dh_installchangelog as it separates the architecture-dependent part.

    Suggested-by: Helmut Grohne <helmut@subdivi.de>

diff --git a/debian/rules b/debian/rules
index 9801fe6..1657fa8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -54,10 +54,7 @@ binary: build
 	echo 'activate-noawait ldconfig' > $(DESTDIR)/DEBIAN/triggers
 	$(INST_FILE) debian/copyright $(DOCS_DIR)/copyright
 	$(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright
-	$(INST_FILE) debian/changelog $(DOCS_DIR)/changelog.Debian
-	$(INST_FILE) debian/changelog $(DEVDOCS_DIR)/changelog.Debian
-	gzip -fn9 $(DOCS_DIR)/changelog.Debian
-	gzip -fn9 $(DEVDOCS_DIR)/changelog.Debian
+	dh_installchangelogs
 	dh_fixperms
 	dh_makeshlibs
 	dh_shlibdeps

Hi Andre,

Yes, that looks good to me.

Helmut

On Sat, Jan 31, 18:02, Helmut Grohne wrote

Great. I've now applied this patch to the "debian" branch and pushed out
the result to the public repo.

Thanks
Andre

On Mon, Feb 02, 17:43, Andre Noll wrote

Looks like the package will be removed from testing anyway due to this
bug. What needs to be done to prevent that?

Thanks
Andre

Hi Andre,

You already did the right thing. The autoremover primarily handles
inactive RC bugs. In sending a mail to the bug you defer it.

Longer term, fixing the bug would be good. Do you need a one-time
sponsor? If yes, consider handing me a pgp-signed .dsc or git tag.

Helmut

On Sat, Feb 28, 11:42, Helmut Grohne wrote

Yes, please upload the version I've just tagged as v1.0.6-1. The
ID of the git commit is cd596839f6d8147ac7464fddad88d0987c728e02.

Thanks
Andre

Hi Andre,

Signing a the git commit id in the mail is fine to me.

Unfortunately, the commit does not seem very well tested. The format of
debian/changelog is rejected by dpkg-source. A space is missing.

Beyond that, this is uploading a new upstream release. I attempted
fetching it via uscan and uscan failed verifying the expected upstream
signature.

This is not in a state that I can sponsor, sorry.

How about uploading a targeted .debdiff fixing just the rc bug for now
and deferring the upstream release and its signature verification?

Helmut

On Tue, Mar 03, 08:21, Helmut Grohne wrote

Sorry about that. I've now added a fixup commit that adds the space. The
tip of the updated branch is

	11f06a85b699251b6ef9ecdd87c85503e007fcd4

Hm, works for me. Does the signature of this email verify?

I was unable to produce a .debdiff that consisted only of the change introduced
by commit c0cf8e24b72effbe53c7dd840ead5130b87151d9 that fixed the RC bug. What
would be a suitable debdiff command to achieve that?

Thanks
Andre

Hi Andre,

Thank you.

Yes and the question is pointing at the root cause. I use mutt and mutt
tends to integrate with gnupg. The signature does verify there. uscan
prefers sqop over a gnupg-based implementation. The thing that refuses
your signature is sqop. I'm not sure what exactly is being rejected
here, but one of being a DSA key 1024bits or SHA1 being used probably is
the cause.

I was able to make it use gnupg and then uscan succeeds, but then
dpkg-source fails. The upstream version discovered by uscan is 1.0.6-1.
Since the package is non-native, the corresponding Debian version should
be 1.0.6-1-1. Now building the source package attempts to locate an
orig.tar for 1.0.6, but that does not exist. I also tried

    uscan --download-version 1.0.6

but that still downloads 1.0.6-1. So this doesn't quite work out. Could
it be that @ANY_VERSION@ is not what we want here and instead skipping
versions with a dash would be better?

It is a bit sad that our tooling insists on the presence of an orig.tar
when all we need here is git. The upstream git history is part of the
Debian git history and there are no patches at all. This should have
been simple but it sadly is not. (Not you to blame.)

I'd normally say that a .debdiff is the output of the debdiff tool when
pointed at two source packages (.dsc). However, this is all git, there
is little benefit of turning two git commits into source packages just
to diff them. Diffing the commits should produce the same thing. Indeed,
the diff 52cbfcd021b7..11f06a85b699 looks very reasonable for sponsoring
to me. I note that this still goes to experimental and thus it will not
prevent your package from being autoremoved. Don't you want this
uploaded to unstable?

So the only thing that prevents me from sponsoring this is that I fail
to construct the intended source package with the present tooling. (Not
you to blame.)

Helmut

On Sun, Mar 08, 21:57, Helmut Grohne wrote

Sigh. This key is rather old, and 1024 bits was considered more than enough
back when the key was created. All signed tags of all my projects use this
key, so it's not easy to switch to a newer key. Add to this that the keyserver
situation is a bit flaky, to put it mildly.

Could be. All lopsub releases are named according to the scheme v$a.$b.$c,
so replacing @ANY_VERSION@ with

	v[[:digit:]]+\.[[:digit:]]+\.[[:digit:]]+

should work (assuming uscan uses extended regular expressions). Do you want
me to add a commit which makes this change?

Alternatively, or in addition to that, I could simply remove the two tags
which contain a dash (v1.0.5-2 and v1.0.6-1).

I couldn't agree more. Quoting Ian Jackson^[1]:

But we're not yet there, unfortunately. Not you to blame ;)

Obviously I'd prefer to not see the package being removed. So what is the
best way to accomplish this?

Thanks
Andre

[1] https://diziet.dreamwidth.org/20436.html

Hi Andre,

Either should work, but the present state doesn't produce a working
source package.

First of all, keep replying. Every reply resets the autoremoval timer.

Then an upload to unstable rather than experimental is needed. The
target suite is selected in the most recent debian/changelog entry.

Helmut

On Tue, Mar 10, 23:11, Helmut Grohne wrote

I've removed the two offending tags and applied the patch below. Hopefully,
that brings the package back to sanity.

Done :)
willing to sponsor the new version?

Thanks
Andre
---
commit f7b30dad8d74a678800fedae6f4da52a7bbcce13
Author: Andre Noll <maan@tuebingen.mpg.de>
Date:   Mon Mar 16 17:22:27 2026 +0100

    debian: Use custom regex in watch file.

    This works around the problem that there existed tags containing a dash
    character, which confused dpkg-source. These tags have been removed by now,
    but it is probably a good idea to use a regular expression which is tailored
    to the upstream naming convention of lopsub. That is, all version strings
    follow the scheme v$a.$b.$c where a, b and c are decimal numbers. There will
    be no alpha, beta, pre, rc, whatever.

    Suggested-by: Helmut Grohne <helmut@subdivi.de>

diff --git a/debian/changelog b/debian/changelog
index 7c92adb..1ed7ba2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+liblopsub (1.0.6-2) unstable; urgency=medium
+
+  * Use custom regex in watch file
+
+ -- Andre Noll <maan@tuebingen.mpg.de>  Mon, 16 Mar 2026 17:21:53 +0100
+
 liblopsub (1.0.6-1) experimental; urgency=medium

   * Use dh_installchangelogs. Closes: #1126662
diff --git a/debian/watch b/debian/watch
index 94ee548..f03e005 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,5 +1,5 @@
 version=4
 opts="mode=git, gitmode=full, pgpmode=gittag" \
https://git.tuebingen.mpg.de/lopsub/ \
-	refs/tags/v@ANY_VERSION@
+	refs/tags/v([[:digit:]]+\.[[:digit:]]+\.[[:digit:]])

[Adding some more people to CC since Helmut seems to be offline or busy]

On Mon, Mar 16, 17:59, Andre Noll wrote

Can somebody please upload this to unstable to prevent the package from
being removed?

Thanks
Andre

On Sun, Mar 22, 14:32, Andre Noll wrote

Ping?
Andre

Hi Andre,

Please excuse my delay in response.

I confirm that the tags no longer prevent me from creating an orig.tar.
sopv is still unhappy about the upstream signature. Tolerable.

I looked again and ran into three distinct problems.

1. The git server is incredibly slow. It timed out several times. This
   is annoying, but not a show stopper.

2. dh_installchangelogs does not compress changelogs. You additionally
   need to run dh_compress. Running lintian would have told you.

3. Adrian Bunk NMUed liblopsub. Your upload would revert changes from his
   upload. Please acknowledge his NMU. If you intend to revert changes,
   document it in debian/changelog.

Consider mirroring your git repository into salsa.debian.org. There you
can enable the default salsa-ci pipeline. It can help you identify a lot
of problems before it comes to sponsoring.

I consider items 2 and 3 blockers for sponsoring.

Helmut

On Fri, Apr 24, 08:09, Helmut Grohne wrote

I talked to my colleague who administers git.tuebingen.mpg.de, and he
activated some countermeasures to rule out the bots which caused this slowness.

Sorry, my bad. The one-liner patch shown below should fix this. However,
I'm not sure how to proceed from here, given that

Looks like Adrian applied a patch which I proposed already in 2024^[1] but
never ended up applying. So yes, I can ack his NMU, but I don't know what
would be the best way to get this change into the repo. Should I split the
patch into two, one for master that modifies version-gen.sh and one for the
debian branch which adjusts debian/rules accordingly, then create 1.0.6-3?

Can you please point me to instructions for what I need to do to make this
happen? I found

https://ruby-team.pages.debian.net/contributing/Starters_Guide_02.html

but I'm not sure how up-to-date this is.

Thanks
Andre

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086623
---
commit 06752e8fd1d0c0dea93e1d9675959404758b2fbe
Author: Andre Noll <maan@tuebingen.mpg.de>
Date:   Wed Apr 29 18:04:58 2026 +0200

    debian: Compress changelogs.

    Run dh_compress to do that. Fixes the following lintian errors:

            E: liblopsub-dev: changelog-file-not-compressed [usr/share/doc/liblopsub-dev/changelog.Debian]
            E: liblopsub1t64: changelog-file-not-compressed [usr/share/doc/liblopsub1t64/changelog.Debian]

    Suggested-by: Helmut Grohne <helmut@subdivi.de>

diff --git a/debian/rules b/debian/rules
index 1657fa8..7624646 100755
--- a/debian/rules
+++ b/debian/rules
@@ -55,6 +55,7 @@ binary: build
 	$(INST_FILE) debian/copyright $(DOCS_DIR)/copyright
 	$(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright
 	dh_installchangelogs
+	dh_compress
 	dh_fixperms
 	dh_makeshlibs
 	dh_shlibdeps

Hi Andre,

Thank you.

Yes, that patch looks correct.

From a Debian pov, your git tree is out-of-sync with Debian and the
version that is your head was never released. Whatever you do, ideally
your debian branch includes the NMU changes in its head commit. For
instance, you might add a branch importing the NMU and then merge that
branch manually resolving the inevitable debian/changelog conflict.

To put it another way, building a source package from your git and then
comparing (debdiff) that package to the most recent upload should not
revert the NMU changes unless you explicitly want to revert them and
state so in a changelog entry.

That feels quite unrelated. To use the pipeline, you need to create a
salsa.debian.org account, create a (e.g. personal) repository to mirror
your repository and then configure the pipeline following
https://wiki.debian.org/SalsaCI. Whenever you consider releasing a
version (or more often), also push to salsa and look at the pipeline's
results. Doing so catches a lot of things that can go wrong before a
reviewer tells you.

Hope this helps

Helmut

On Wed, Apr 29, 22:05, Helmut Grohne wrote

It's in master now.

Here's what I did to address this:

* Applied the old version-gen.sh patch to a temporary branch t/nmu.

* Merged this branch into the debian branch, amending the merge commit to
add the necessary changes to debian/rules and to resolve the debian/changelog
conflict.

Please have a look at the current pu branch (proposed updates) of the public
repo. If everything looks good to you, I'll make these changes permanent by
updating the non-rewinding master and debian branches accordingly.

Thanks for the link. I've just applied for an salsa account. According to
the FAQ, it will take a while to get it approved...

Best
Andre

Hello Adrian

On Tue, May 05, 17:30, Andre Noll wrote

Given that Helmut is unresponsive and the package is about to be removed
from testing, would you be willing to have a look at my proposed resolution?

Thanks
Andre

Hi Andre,

given that we once worked together nicely with the ball package in
Debian Med I'm guessing you are fine with a NMU of liblopsub.  I
followed the rule to upload to DELAYED/15 anyway to give you sufficient
time to insist.

I noticed that your private repository contained changelog entries
pretending releases of a new upstream version but these never have
reached the Debian mirrors.  Thus I merged these into a single entry
closing all open bugs (I opened two further ones to follow the NMU
procedure and document what issues are closed in the NMU).  You can
find all changes in

https://salsa.debian.org/debian/liblopsub

and I've granted your ID on Salsa Maintainer permissions on this
repository.  Please let me know if I should cancel the upload.

Kind regards
   Andreas.

PS: I intend to migrate tfortune in a similar manner to the Debian
    name space on Salsa.

Hi Andreas

On Mon, Aug 31, 13:57, Andreas Tille wrote

You are confusing me with someone else, as I've never worked with the ball
package in Debian Med.

Right. I proposed a way forward, but got no reply from the any of the Debian
people involved. See Bug#1086623.

Due to this bug, both tfortune and lopsub were removed from testing on July
26th. Given this and the fact that I already spent way too much time on
an issue that should take five minutes to resolve, I decided to not invest
further time on Debian integration issues. IOW, Debian just lost a contributor.

In fact, I already removed the tfortune web page and its git repo, continuing
development non-publicly. This is why the vcs tracker complains. The only
reason the lopsub repo and web page are still online is that other projects
of mine (see the link in the signature below) depend on it. I'm planning to
remove the "debian" branch of lopsub, though, because it is not needed to
build the package from source.

I might reconsider this decision if somebody volunteers to act as the
Debian maintainer for both tfortune and lopsub. This person's job would be
to maintain the debian/ directory to improve the integration with the Debian
infrastructure, to upload new versions, and to coordinate non-Debian related
changes with me. If nobody is willing to do this work, the packages should
probably get removed.

Thanks
Andre

Hi Andre

Am Wed, Sep 02, 2026 at 04:37:40PM +0200 schrieb Andre Noll:

It was removed due to bug #1126662 actually.

That's sad to hear.  Does this mean you want to orphan your packages?
If so I can do a QA upload and make the QA team maintainer.

I do not understand why the fact that you are not happy to maintain some
software in Debian (which I can understand to some extend) is a
motivation to remove a repository containing GPL-3 software (which can
be used by other distributions or users who want to compile it from
scratch) from the web.

Its actually very sensible to remove the debian/ dir from upstream source
repositories.

The fact that you are seeking for a new maintainer is not obvious at
all.  As I said I could do QA uploads and file according Orphan bugs for
both packages.  This expresses that a new maintainer is needed.

Alternatively to orphaning you can file a removal bug.  Debian has a
strict package ownership model.  So you are the person who can decide
whether orphaning or removing would be appropirate and you can ask for
removal as well (Hint: `reportbug other` and follow the menu).

I admit I'd be motivated to do a QA upload of
https://salsa.debian.org/debian/liblopsub
since I've spent some time into it and doing something similar with
tfortune would be easy as well.  Just let me know what you want to do
and how I can help you in doing so.

Kind regards
    Andreas.

Hi again,

Am Wed, Sep 02, 2026 at 09:18:23PM +0200 schrieb Andreas Tille:

Can you please clarify whether you want to orphan this (and the tfortune)
package?  I'm reading the "Debian just lost a contributor" as == "I do not
intend to maintain this package any more".

If I do not hear from you I will do a QA upload before the NMU of
  liblopsub_1.0.6-1
will hit unstable.

I admit I'm sorry that you made this bad experience with Debian and
you are kindly invited to come back again.

Kind regards
    Andreas.

On Wed, Sep 09, 16:56, Andreas Tille wrote

I'm still willing to maintain the tfortune and lopsub code, i.e. everything
except the debian/ directories, and I'm happy to work on features and bugs
that affect *users* of both packages. It's just that I won't spend time on
the Debian maintenance any more, including RFS, uploads, CI, lintian, salsa
and all that. My attempt to get familiar with these workflows was both time
consuming and fruitless, and I won't continue this frustrating experience.

No reason to be sorry, it's not your fault.

I've resurrected the tfortune web page and re-enabled the git repo, so feel
free to do whatever it takes to make the bots happy. But please keep me out
of the loop unless the code itself needs to be changed.

Thanks
Andre

Hi Andre,

thank you for the quick response.

Am Wed, Sep 09, 2026 at 07:47:32PM +0200 schrieb Andre Noll:

OK, that is upstream.

Yep, that's Debian maintenance.  So you do not want to stay the Maintainer
of the Debian packaging.  This is what I wanted to know and your statement
is the permission to officially orphan the Debian packaging.  Thank you,
this is the helpful information I was seeking for.

Yep, that's upstream work and its nice you are doing so.

Understood.  This will be taken over by Debian QA team then.

Fair enough - even if I'm a bit sorry to hear this anyway.

I did not understood it the way that it would be my fault.  I simply
like to onboard newcomers.  But well, your status update is very helpful
to let others continue.

ACK.

All the best
   Andreas.

We believe that the bug you reported is fixed in the latest version of
liblopsub, 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 1126662@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Tille <tille@debian.org> (supplier of updated liblopsub 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)
Format: 1.8
Date: Mon, 31 Aug 2026 13:38:33 +0200
Source: liblopsub
Architecture: source
Version: 1.0.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group <packages@qa.debian.org>
Changed-By: Andreas Tille <tille@debian.org>
Closes: 1115556 1126662 1146287 1146288
Changes:
 liblopsub (1.0.6-1) unstable; urgency=medium
 .
   * QA upload.
 .
   [ Andre Noll ]
   * New upstream version
     Closes: #1115556
   * Use dh_installchangelogs. Closes: #1126662
   * Use custom regex in watch file
 .
   [ Andreas Tille ]
   * Set Vcs fields to Salsa in Debian namespace
     Closes: #1146287
   * d/rules: use short dh consequently
   * d/copyright:
      - DEP5
      - more detailed
   * Add d/lrc.config
   * Bump debhelper from old 10 to 13.
     Closes: #1146288
   * Remove redundant Priority: optional from source stanza.
   * Upgrade upstream signing key to new packet format.
   * Update standards version to 4.7.4, no changes needed.
   * Set debhelper-compat version in Build-Depends.
   * d/control: Remove Rules-Requires-Root: no which is default
   * Remove unused lintian-overrides
   * d/watch: version=5
Checksums-Sha1:
 3541b650efc04da763810d3ce9573772942edcca 2032 liblopsub_1.0.6-1.dsc
 eb65953797065b3ee2419ed487f7c0ef7ca5b88c 55884 liblopsub_1.0.6.orig.tar.xz
 5dd0f9346f5eec0818fce20d6f0e7fe96948fae7 6116 liblopsub_1.0.6-1.debian.tar.xz
 2194071c8e52cea01f7dac429fd9bfb5a7b3169b 6829 liblopsub_1.0.6-1_amd64.buildinfo
Checksums-Sha256:
 5fcec579c89a31c8898513db316408358902cb8f5712e1a3d407cda166eecdd1 2032 liblopsub_1.0.6-1.dsc
 7fbd0954e7af975d118916b349855f23b5a6447221a9430f22fc84c1de18201b 55884 liblopsub_1.0.6.orig.tar.xz
 0ca6fac3689597a7e14655f383ffe7226a2f37a026e6de81ae27ebc00854af2b 6116 liblopsub_1.0.6-1.debian.tar.xz
 f44ee83dbb9ad63c063413abfc3bd068db6026751caa72de46b818e0d9dfd795 6829 liblopsub_1.0.6-1_amd64.buildinfo
Files:
 1c698fc51ac996ea7250114e14b4cf05 2032 libdevel optional liblopsub_1.0.6-1.dsc
 7de5f41e7cc8952430c452a31056a2ca 55884 libdevel optional liblopsub_1.0.6.orig.tar.xz
 9c3d4bd2c60b5f99559f76e993dcd374 6116 libdevel optional liblopsub_1.0.6-1.debian.tar.xz
 f4718f08ed4fc2118a3bf6d9263462b4 6829 libdevel optional liblopsub_1.0.6-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmqhqloRHHRpbGxlQGRl
Ymlhbi5vcmcACgkQV4oElNHGRtFZDg//aIs2SmqSd6WDaLhq8MuKodek0N3bMOOQ
nmNA6uat3TWJA5e+7KMkGXqUTiOO7gx/smiQD7eR5oZ2qwhdgdypKkt4V4MVFvEd
ewQgtp33tq2KkT+Fv0GR9hw4ZaWNHgrn9s4dwQvF3gE532pRh8ONMdfaFeTeURRt
FssQ1whybAClbVhfj8MS5GqQNLWa+aS9OmiLTX7INLQ9bPXQiVimCbmKSQ9WdaSm
cv/cfYsabPKHXa0q0cLc3el1Q7dmJJnA4u0w7ea1jgwsh/0o1sCfcT3a07zL24eu
qe/9dxGwmezo9Y2IJtiHrK2Q7ChnHOrGyfWuR4AOyJoqUfuYdMEict+3jvPyMXR8
fEBx8xEDdHS06z8xe7+X4TmcQfdZuiouXmAeAcS/Lywb6Lpzlm2DpIm4xvTPAtc9
emF9GNdeGOxIwDm0ParDs6DJMegZU5MXFbhHK71AIQhY7jy81b/QqLf4ZBu5m6mt
H/ICD9eRsNjsvuovyLAmfAI7q1rIT532gn/Zn2IEMQIfVDc2CGH35t2b/E4vouLw
mHfQNwaW94FkONH3fWspCczdhMHMqC/kTxx1IvvvvVWg3GwnjQKoGcVPxI8mN2Gx
N+3kQjN7lbjnQp3WNVAvRtyWFsaORIJT60XyGFb75xkwmOaCUsAOQA0hyJfd29Hc
QFGZYBthLPw=
=iMAh
-----END PGP SIGNATURE-----