tl;dr:
tag2upload (beta) is going well so far, and is already handling around one in 13 uploads to Debian.
Introduction and some stats
We announced tag2upload s open beta in mid-July. That was in the middle of the the freeze for trixie, so usage was fairly light until the forky floodgates opened.
Since then the service has successfully performed 637 uploads, of which 420 were in the last 32 days. That s an average of about 13 per day. For comparison, during the first half of September up to today there have been 2475 uploads to unstable. That s about 176/day.
So, tag2upload is already handling around 7.5% of uploads. This is very gratifying for a service which is advertised as still being in beta!
Sean and I are very pleased both with the uptake, and with the way the system has been performing.
Recent UI/UX improvements
During this open beta period we have been hard at work. We have made many improvements to the user experience.
Current
git-debpush in forky, or trixie-backports, is much better at detecting various problems ahead of time.
When uploads do fail on the service the emailed error reports are now more informative. For example, anomalies involving orig tarballs, which by definition can t be detected locally (since one point of tag2upload is not to have tarballs locally) now generally result in failure reports containing a diffstat, and instructions for a local repro.
Why we are still in beta
There are a few outstanding work items that we currently want to complete before we declare the end of the beta.
Retrying on Salsa-side failures
The biggest of these is that the service should be able to retry when Salsa fails. Sadly, Salsa isn t wholly reliable, and right now if it breaks when the service is trying to handle your tag, your upload can fail.
We think most of these failures could be avoided. Implementing retries is a fairly substantial task, but doesn t pose any fundamental difficulties. We re working on this right now.
Other notable ongoing work
We want to support pristine-tar, so that pristine-tar users can do a new upstream release. Andrea Pappacoda is working on that with us. See
#1106071. (Note that we would generally recommend against use of pristine-tar within Debian. But we want to support it.)
We have been having conversations with
Debusine folks about what integration between tag2upload and Debusine would look like. We re
making some progress there, but a lot is still up in the air.
We are considering how best to provide tag2upload pre-checks as part of Salsa CI. There are several problems detected by the tag2upload service that could be detected by Salsa CI too, but which can t be detected by
git-debpush.
Common problems
We ve been monitoring the service and until very recently we have investigated every service-side failure, to understand the root causes. This has given us insight into the kinds of things our users want, and the kinds of packaging and git practices that are common. We ve been able to improve the system s handling of various anomalies and also improved the documentation.
Right now our failure rate is still rather high, at around 7%. Partly this is because people are trying out the system on packages that haven t ever seen git tooling with such a level of rigour.
There are two classes of problem that are responsible for the vast majority of the failures that we re still seeing:
Reuse of version numbers, and attempts to re-tag
tag2upload, like git (and like
dgit), hates it when you reuse a version number, or try to pretend that a (perhaps busted) release never happened.
git tags aren t namespaced, and tend to spread about promiscuously. So replacing a signed git tag, with a different tag of the same name, is a bad idea. More generally, reusing the same version number for a different (signed!) package is poor practice. Likewise, it s usually a bad idea to remove changelog entries for versions which were actually released, just because they were later deemed improper.
We understand that many Debian contributors have gotten used to this kind of thing. Indeed, tools like
dcut encourage it. It does allow you to make things neat-looking, even if you ve made mistakes - but really it does so by
covering up those mistakes!
The bottom line is that tag2upload can t support such history-rewriting. If you discover a mistake after you ve signed the tag, please just burn the version number and add a new changelog stanza.
One bonus of tag2upload s approach is that it will discover if you are accidentally overwriting an NMU, and report that as an error.
Discrepancies between git and orig tarballs
tag2upload promises that the source package that it generates corresponds precisely to the git tree you tag and sign.
Orig tarballs make this complicated. They aren t present on your laptop when you
git-debpush. When you re not uploading a new upstream version, the tag2upload service reuses existing orig tarballs from the archive. If your git and the archive s orig don t agree, the tag2upload service will report an error, rather than upload a package with contents that differ from your git tag.
With the most common Debian workflows, everything is fine:
If you base everything on upstream git, and make your orig tarballs with
git archive (or
git deborig), your orig tarballs are the same as the git, by construction. We recommend usually ignoring upstream tarballs: most upstreams work in git, and their tarballs can contain weirdness that we don t want. (At worst, the tarball can contain an attack that isn t visible in git, as with
xz!)
Alternatively, if you use
gbp import-orig, the differences (including an attack like Jia Tan s) are
imported into git for you. Then, once again, your git and the orig tarball will correspond.
But there are other workflows where this correspondence may not hold. Those workflows are hazardous, because the thing you re probably working with locally for your routine development is the git view. Then, when you upload, your work is transplanted onto the orig tarball, which might be quite different - so what you upload isn t what you ve been working on!
This situation is detected by tag2upload, precisely because tag2upload checks that it s keeping its promise: the source package is identical to the git view. (
dgit push makes the same promise.)
Get involved
Of course the easiest way to get involved is to
start using tag2upload.
We would love to have more contributors. There are some easy tasks to get started with, in
bugs we ve tagged newcomer mostly UX improvements such as detecting certain problems earlier, in
git-debpush.
More substantially, we are looking for help with
sbuild: we d like it to be able to work directly from git, rather than needing to build source packages:
#868527.
comments
In Could the XZ backdoor have been detected with better Git and Debian
packaging practices? ,
Otto contrasts git-buildpackage managed git repositories with dgit
managed repositories , saying that the dgit managed repositories cannot
incorporate the upstream git history and are thus less useful for auditing
the full software supply-chain in git .
Otto does qualify this earlier with a package that has not had the
history recorded in dgit earlier , but the last sentence of the section is a
misleading oversimplification. It s true for repositories that have been
synthesized by dgit (which indeed was the focus of that section of Otto s
article), but it s not true in general for repositories that are managed
by dgit.
I suspect this was just slightly unclear writing, so I don t want to nitpick
here, but rather to take the opportunity to try to clear up some
misconceptions around dgit
that I ve often heard at conferences and seen on mailing lists.
I m not a dgit developer, although I m a happy user of it and I ve tried to
help out in various design discussions over the years.
The discovery of a backdoor in XZ Utils in the spring of 2024 shocked the open source community, raising critical questions about software supply chain security. This post explores whether better Debian packaging practices could have detected this threat, offering a guide to auditing packages and suggesting future improvements.
The XZ backdoor in versions 5.6.0/5.6.1 made its way briefly into many major Linux distributions such as Debian and Fedora, but luckily didn t reach that many actual users, as the backdoored releases were quickly removed thanks to the heroic diligence of 
If the changes are extensive, and you want to use a LLM to help spot potential security issues, generate the report of both the upstream and Debian packaging differences in Markdown with:
To compare changes across the new and old upstream tarball, one would need to compare commits afba662b New upstream version 5.8.0 and fa1e8796 New upstream version 5.8.1 by running 
With all the above tips you can now go and try to audit your own favorite package in Debian and see if it is identical with upstream, and if not, how it differs.
There is only one tiny thing that maybe a very experienced Autotools user could potentially have noticed: the 
Dear lazyweb,
At work, we are trying to rotate the GPG signing keys for the Linux packages of
the 
We had 886 responses with status code 200 and 64 connections closed.
The backend terminated 64 connections while the load balancer still had
active requests directed to it.
Let's change the Load Balancer 
Great! Now all the requests worked.
This is a common issue, not specific to Envoy Proxy or the setup
shown earlier. Major cloud providers have all documented it.
Even thought the success rate is 100%, the status code distribution
show some responses with status code 503. This is the case where is not
that obvious that the problem is related to idle timeout.
However, it's clear when we look the Envoy access logs:
Key Takeaways:
Another short status update of what happened on my side last
month. Nothing stands out too much, I enjoyed doing the OSK changes
the most as that helped to improve the typing experience further. Also
doing a small bit of kernel work again was fun (still need to figure out
the 6mq's touch controller repsonsiveness though).
See below for details on the above and more:
If you're still using Vagrant (I am) and try to boot a box that uses UEFI (like 
