On Sun, Mar 08, 21:57, Helmut Grohne wrote
> 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.
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.
> 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?
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).
> 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 couldn't agree more. Quoting Ian Jackson^[1]:
> 1. All examination and edits to the source should be performed via
> normal git operations.
> 2. Source code should be transferred and exchanged as git data, not
> tarballs. git should be the canonical form everywhere.
> 3. Upstream git histories should be re-published, traceably, as part
> of formal git releases published by Debian.
> 4. No-one should have to learn about Debian Source Packages, which
> are bizarre, and have been obsoleted by modern version control.
But we're not yet there, unfortunately. 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?
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
--
Max Planck Institute for Biology
Tel: (+49) 7071 601 829
Max-Planck-Ring 5, 72076 Tübingen, Germany
https://people.tuebingen.mpg.de/maan/
