tag2upload in the first month of forky
tl;dr: tag2upload (beta) is going well so far, and is already handling around one in 13 uploads to Debian.
- Introduction and some stats
- Recent UI/UX improvements
- Why we are still in beta
- Other notable ongoing work
- Common problems
- Get involved
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.
Culture of silence: Ubisoft harassment convictions, Mozilla, Sylvestre Ledru & Debian make no comment
In an earlier blog, I provided an English translation of the accusations against the Ubisoft executives. This is serious stuff.
In the summer of 2017, people discovered the head of the Albanian group, who was also a Mozilla Tech Speaker, had a 16-year-old girlfriend. He was 24 at the time.
In October 2017, I sent a protected whistleblower complaint to Mozilla.
Here is the internal complaint about the harassment. The date is 12 October 2017 so the misfits publishing alternative statements about harassment are lying. I have redacted the section that identifies underage victims.
The next internal email from Larissa Shapiro at Mozilla admits that kids are at risk.
Emma Irwin from Mozilla admits this is a serious matter and asks me to speak to Marta, Mozilla's HR investigator.
It was around this time that I confided in some of the women that I had a family connection with the choir of Cardinal George Pell and that I was watching these matters very carefully.
On 18 January 2018, at the peak of the scandals involving the Albanian female whisteblowers, Sylvestre Ledru, who is employed by Mozilla, sent a private email to Chris Lamb, Nicolas Dandrimont and I telling us that he was resigning as an administrator in Google Summer of Code.
On 27 August 2018 I sent a public message to the mailing list where I also resigned from future mentoring in the program.
People have now spent seven years complaining. They never paid us anything for the work we did recruiting and mentoring the interns for Google. They squeal like stuck pigs after we resign.
In December 2018, the late Cardinal Pell was convicted of abuse and the rogue Debianists immediately began spreading rumors about my family and I.
A few weeks later, on 12 February 2019, Sylvestre Ledru used his blog at Mozilla to announce a collaboration between Ubisoft and Mozilla using the Ubisoft Clever-Commit artificial intelligence. An excerpt:
It looks like a very close relationship between the developers at Mozilla and Ubisoft. Sylvestre is one of the Mozilla developers based in Paris, which is also the headquarters of Ubisoft.
Around the same time, Mozilla censored my blog from the Planet Mozilla blog syndication service. Is this because they don't want the Mozilla community to know what women told me in 2017 and 2018?
Look at the Mozilla Manifesto. It says that Mozilla is against censorship. Why did they censor my blog immediately before the evidence about harassment was published?
The franceinfo report about harssment describes the culture in our industry with quotes from the audit of Ubisoft culture:
The fellowship had elected me as a representative in 2017 and somebody at Mozilla didn't want me to share evidence about harassment (real harassment).
Ubisoft employees began to speak up about harassment (real harassment) in summer 2020 ( Wikipedia report). French newspaper Libération started an investigation, eventually running a series of reports.
In 2023, Mozilla created and promoted a petition against the French government's browser censorship (SREN) legislation. Five years after censoring the blog of the person elected by the Fellowship, Mozilla declared:
In the summer of 2025, three senior Ubisoft executives were convicted and punished for harassment (real harassment).
Nobody from Mozilla or Debian has ever made any public Statement on Ubisoft.
Whether we are talking about censorship or talking about harassment, the message is clear: do as we say, not as we do
Why did they attack my family when my father died but they maintain the culture of silence for the Ubisoft scandals?
Here is a photo of Sylvestre Ledru, Paul Tagliamonte and I in the offices of Google during the Google Summer of Code mentor summit 2013.
Please see the chronological history of how the Debian harassment and abuse culture evolved.
10 September, 2025 07:00PM