Hi, Simon.  We saw this failure.  tl;dr: I think it's not your fault.

Debian tag2upload service writes ("[tag2upload 2255] failed, cppi 1.18-4"):
...

Sure enough, the tag says:

  [dgit distro=debian split --quilt=baredebian+tarball]
  [dgit please-upload source=cppi version=1.18-4 upstream-tag=upstream/1.18 upstream=42505de52b878ff751f0edf54dc07314dea27ee7]

According to dgit(1), baredebian+tarball means this:

Hello,

Ian Jackson [01/Jan 12:21pm GMT] wrote:

Ooof, yes, we should not reuse a quilt mode that we wouldn't otherwise
put on a tag.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Oh!  That is not what I intended.

I expected/wanted it to fail because I wanted to use 'git-debpush
--quilt=baredebian+git' and wanted to find out how git-debpush fails
when I do not specify it.  Alas git-debpush created a tag and pushed it.
So I did a manual upload to get that version into the archive.

Tag2upload wasn't a thing then.  Since the last upload, I added a
upstream branch and the corresponding upstream tag:

https://salsa.debian.org/debian/cppi/-/commits/upstream?ref_type=heads

This is because I wanted to switch to tag2upload for this package.  That
branch didn't exist before.

I don't feel strongly about using baredebian for this package, but I
want to gain experience with difference packaging strategies to see how
they play out.

Do qit-debpush generally look at the PREVIOUS tag to make any decisions
right now?

As a user I really prefer if it didn't, but I don't know what the
concerns are.  I thought git-debpush was stateless wrt earlier upload
history of the git repository, if that isn't the case I'll have to
reclibrate my intuition.
tag2upload should not ALWAYS use the tarball from the archive, if one
exists, instead of synthesizing one?

This upload was not a new upstream version, just a incremental update.
Anything but the archive tarballs will be rejected, I suppose.

Yes, erroring out is what I expected.

I still have to test if 'git-debpush --quilt=baredebian+git' actually
works for this package.  Do you have any guess?  Hopefully I can find
some nit in the latest upload and test it.

/Simon

Hello,

Simon Josefsson [01/Jan  4:17pm +01] wrote:

Yes, this is how we support typing just 'git debpush' for most uploads.
It gets the quilt mode from the previous upload.

We think this is important because too many Debian tools require passing
options (almost) every time you invoke them, and because our experience
with dgit is that it's annoying to have to keep passing quilt options.

Based on what I've read I haven't any reason to think it won't work, but
I don't know what your workflow is for that package.

Simon Josefsson writes ("Bug#1124438: git-debpush should do something better about baredebian+tarball"):
...

See Sean's reply.  One reason for doing it this way is that passing
a wrong quilt mode can't always be detected.  With this history-based
automation, you don't normally have to pass --quilt so you don't have
the opportunity to make a slip and pass the wrong option.

It does in fact indeed do that.  If it can obtain the tarball from the
archive it will do so.  And if there is a tarball in the archive
which it can't obtain (sadly this is possible), it generally fails
rather than synthesising and uploading a differeent tarball.

The issue is that our tag format has no way to say "there should be an
orig tarball" without also providing instructions for how to make it.

If dgit build-source --quilt=baredebian+git works then tag2upload
should work too.  Obviously the point of tag2upload is to avoid doing
all that tarball and dgit stuff locally but, since you ask, that's
the way to test things :-).

Regards,
Ian.