Hi Andre,
On Sun, Mar 08, 2026 at 04:20:49PM +0100, Andre Noll wrote:
> Sorry about that. I've now added a fixup commit that adds the space. The
> tip of the updated branch is
>
> 11f06a85b699251b6ef9ecdd87c85503e007fcd4
Thank you.
> > Beyond that, this is uploading a new upstream release. I attempted
> > fetching it via uscan and uscan failed verifying the expected upstream
> > signature.
>
> Hm, works for me. Does the signature of this email verify?
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 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?
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
