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