Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Colin Watson]

On Mon, Mar 02, 2026 at 12:20:10PM +0800, Otto Kekäläinen wrote:

Your co-author is calling this a 'fetish' so he
clearly isn't going to implement or accept any external person's
implementation,


I sat down with Ian at DebConf to talk about pristine-tar, and on the 
contrary it was quite clear to me that they would be happy to accept 
somebody else's implementation of pristine-tar in tag2upload, assuming 
the usual code review expectations.  Indeed, why else would they have 
themselves filed https://bugs.debian.org/1106071 with "wanted:" in the 
title, and "Therefore I think tag2upload *should* support pristine-tar." 
in the message?


(There were some initial misconceptions in that bug, but I believe 
they've been sorted out now.  No need to go over them again.)


--
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Otto Kekäläinen [02/Mar 12:20pm +08] wrote:
> Your own packages would be a great reference *if* they would be
> maintained more like the majority does, but it does not seem like
> that.
>
> Looking at the 11 packages you personally maintain listed at
> https://udd.debian.org/dmd/?email1=spwhitton%40spwhitton.name&nouploader1=on&nosponsor1=on&email2=&email3=&packages=&ignpackages=&format=html#todo
> I see that:
>
> - None of them are hosted on salsa.debian.org, unlike most Debian
> packages are nowadays (which brings along it several workflow aspects)
> - 10 out of 11 have a broken uscan result as reported by Debaudit,
> indicating that you maybe don't care to maintain watch files (while
> most other DDs do maintain them)

This is unfair cherry-picking.  The other 51 packages on my DDPO are
maintained on salsa in more ordinary ways.

I just do things differently when I'm also the upstream for a package.
But they are the minority.

> Respectfully, since you are not using the workflows most other people
> do, you are probably blind to the shortcomings in end-to-end workflows
> of the systems you develop. I wish you were more open to feedback to
> learn about the shortcomings and willing to address them.

I have used those workflows extensively in team maintenance situations.

I have experience maintaining packages with: gbp; git-dpm;
git-debrebase; plain git-merge; the DHG monorepo; debian/-only; I've
used pristine-tar many times too.  The only thing I think I haven't
tried is the way the Rust team do it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Otto Kekäläinen]

Hi,

On Wed, 11 Feb 2026 at 19:52, Sean Whitton  wrote:
...
> For example, I maintain or team half-maintain maybe 90 packages in
> total, and none of them use pristine-tar.  So the only case where I
> cannot use tag2upload is when I need to upload to NEW, which is not
> often.  Therefore tag2upload is my default way to upload, because why
> wouldn't it be, it's so smooth and easy.

Your own packages would be a great reference *if* they would be
maintained more like the majority does, but it does not seem like
that.

Looking at the 11 packages you personally maintain listed at
https://udd.debian.org/dmd/?email1=spwhitton%40spwhitton.name&nouploader1=on&nosponsor1=on&email2=&email3=&packages=&ignpackages=&format=html#todo
I see that:

- None of them are hosted on salsa.debian.org, unlike most Debian
packages are nowadays (which brings along it several workflow aspects)
- 10 out of 11 have a broken uscan result as reported by Debaudit,
indicating that you maybe don't care to maintain watch files (while
most other DDs do maintain them)

Respectfully, since you are not using the workflows most other people
do, you are probably blind to the shortcomings in end-to-end workflows
of the systems you develop. I wish you were more open to feedback to
learn about the shortcomings and willing to address them.

...
> I would encourage everyone reading to try 'git debpush' so we can move
> on from this situation, towards one with greater mutual understanding.

I understand you want people to try using 'git debpush' and you think
it is perfect as-is, but as many people are pointing out issues, would
it not be more productive to try to just fix them?

The biggest item being pristine-tar support as tracked in #1106071.
That would be a technical fix to get adoption to tag2upload. Other key
ones would be #1110269 to deposit upstream release tags and #331
to have git push include checking CI status and block uploads if CI is
in use, and shows a regression.

I have used tag2upload on a small scale, but I won't use it for
important packages until it supports maintaining the software
supply-chain validation mechanism that Debian has been using for
decades, and which also e.g. Fedora, SUSE, Arch and basically all
other distros use, which is to compare the checksum of the original
source tarballs. Your co-author is calling this a 'fetish' so he
clearly isn't going to implement or accept any external person's
implementation, but if you could do it we might get over this gap and
actually use tag2upload project-wide.

Thanks,

Otto

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Lucas Nussbaum]

On 13/02/26 at 10:57 +, Sean Whitton wrote:
> Lucas Nussbaum [12/Feb 10:25pm +01] wrote:
> > I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
> > https://udd.debian.org/cgi-bin/dep14stats.cgi
> >
> > 72.8% of packages with a working salsa project have a pristine-tar
> > branch.
> >
> > Among salsa groups with more than 200 packages in testing, the following
> > have more than 80% of group-maintained packages that have a pristine-tar
> > branch:
> 
> I would really appreciate knowing whether these branches are in use --
> whether they have the most recent upstream versions imported to them.
> 
> For example I often find pristine-tar branches but just ignore them,
> where team policy allows me to.  So the fact that someone used it once
> may not mean much statistically.
> 
> git-debpush has code in it to detect whether the current release in
> d/changelog is represented in the pristine-tar branch if you want to
> crib from somewhere.

Hi,

I ended up extending https://debaudit.debian.net/ with a new checker,
'git2orig', that checks whether a matching tarball can be extracted from
the Vcs-Git repository.
See https://debaudit.debian.net/git2orig/

I got the following results for the packages in sid:
 has_pristine_tar_branch | pristine_tar_worked | 
tarball_identical_using_pristine_tar | count
-+-+--+---
 true| false   | false  
  |  2077
 true| true| false  
  |   386
 true| true| true   
  | 25007

So, out of 27470 packages with a pristine-tar branch, 25007 have an
up-to-date pristine-tar branch that can generate the orig tarball in the
archive. I think that's quite good.

Lucas

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Pierre-Elliott Bécue]

Hello,

Ian Jackson  wrote on 19/02/2026 at 
11:42:13+0100:

> (droppping the bug, adjusting the CC)
>
> Pierre-Elliott Bécue writes ("Re: Bug#1127616: developers-reference: should 
> document using git-debpush to upload"):
>> I strongly suggest that you reconsider your way of interacting with
>> others in order to:
>
> I wrote to the Community Team about this.  Steve McIntyre, for the
> team, wrote me a very helpful clear and direct message which, frankly,
> basically agrees with you.
>
> So, I apologise.  I'm also sorry that I lacked awareness of the impact
> of my approach.
>
> I am going to step away from this conversation now.  In the longer
> term I need to reflect on how I can do better, before I get involved
> again in such conversations (especially here on the mailing lists).

Thanks for your message. For what it's worth, I stand with the "I want
to believe you mean well" part of my mail, and do hope you did not miss
this bit.

Bests,
-- 
PEB


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Pierre-Elliott Bécue]

"Jonathan Dowland"  wrote on 19/02/2026 at 11:35:09+0100:

> Hello Pierre-Elliott,
>
> On Tue Feb 17, 2026 at 2:08 PM GMT, Pierre-Elliott Bécue wrote:
>> Calling tarball-shipping a fetish is irrelevant, petty and insulting.
>
> With my message I REALLY don't wish to fan the flames. But I would like 
> to better understand the specifics of your objection, because it 
> surprised me.
>
> None of us are above writing bad mails, not least Ian (sorry Ian), nor 
> me. But I didn't find that particular message to be bad, and I would 
> like to understand what was wrong with it.
>
> Is it perhaps specifically the term "fetish"? If so, I think this could 
> potentially be a i18n issue. That turn of phrase is quite common in 
> en_GB, such that it has been somewhat "defanged" in common use, but I 
> could understand if it had not been defanged out of our little bubble.
>
> If Ian had written substantially the same mail, but used e.g. "tarball 
> obsession", would that have been offensive? (I'm assuming here that 
> "obsession" has been defanged more internationally. One could make a 
> reasonable argument that it shouldn't be)
>
> Or, is the problem in your eyes more fundamentally that Ian reiterates 
> his opinion that caring about tarballs is wrong?

As I mentioned, the issue is with a consistent pattern.

Apart from that, I'm not sure I agree with most of the arguments stating
that "tarball shipping is wrong", but it's offtopic.
-- 
PEB


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

(droppping the bug, adjusting the CC)

Pierre-Elliott Bécue writes ("Re: Bug#1127616: developers-reference: should 
document using git-debpush to upload"):
> I strongly suggest that you reconsider your way of interacting with
> others in order to:

I wrote to the Community Team about this.  Steve McIntyre, for the
team, wrote me a very helpful clear and direct message which, frankly,
basically agrees with you.

So, I apologise.  I'm also sorry that I lacked awareness of the impact
of my approach.

I am going to step away from this conversation now.  In the longer
term I need to reflect on how I can do better, before I get involved
again in such conversations (especially here on the mailing lists).

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Jonathan Dowland]

Hello Pierre-Elliott,

On Tue Feb 17, 2026 at 2:08 PM GMT, Pierre-Elliott Bécue wrote:

Calling tarball-shipping a fetish is irrelevant, petty and insulting.


With my message I REALLY don't wish to fan the flames. But I would like 
to better understand the specifics of your objection, because it 
surprised me.


None of us are above writing bad mails, not least Ian (sorry Ian), nor 
me. But I didn't find that particular message to be bad, and I would 
like to understand what was wrong with it.


Is it perhaps specifically the term "fetish"? If so, I think this could 
potentially be a i18n issue. That turn of phrase is quite common in 
en_GB, such that it has been somewhat "defanged" in common use, but I 
could understand if it had not been defanged out of our little bubble.


If Ian had written substantially the same mail, but used e.g. "tarball 
obsession", would that have been offensive? (I'm assuming here that 
"obsession" has been defanged more internationally. One could make a 
reasonable argument that it shouldn't be)


Or, is the problem in your eyes more fundamentally that Ian reiterates 
his opinion that caring about tarballs is wrong?



Thank you,

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ 

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Andrew McMillan]

Sounds great to me.  I created the discussion issue, as suggested:

https://salsa.debian.org/freexian-team/debusine.debian.net/support/-/issues/9

Regards,
Andrew.

On Wed, 2026-02-18 at 22:51 +, Colin Watson wrote:
> [CC: removed bug #1127616; added dfsg-team@]
> 
> On Mon, Feb 16, 2026 at 09:00:13PM +0100, Philipp Kern wrote:
> > On 2/12/26 1:11 PM, Ian Jackson wrote:
> > > Sean Whitton writes ("Bug#1127616: developers-reference: should
> > > document using git-debpush to upload"):
> > > > I think one source of opposition for autobuilding packages
> > > > before they
> > > > go into NEW is that the DFSG team won't yet has
> > > > asserted/confirmed that
> > > > the license permits autobuilding.  But, well, we already have
> > > > Salsa CI,
> > > > so I think that is not worth blocking on.
> > > 
> > > Indeed.
> > > 
> > > I don't know much about how the autobuilding system works but I
> > > would
> > > love it if someone who did understand that would figure out how
> > > to
> > > make this work.
> > 
> > I think I'd strongly prefer not to autobuild code on the existing 
> > systems that has not been vetted yet. So then we'd need a separate 
> > infrastructure for that.
> > 
> > I wouldn't mind if there is the moral equivalent of sending the
> > upload 
> > to Salsa CI and use the outputs for review. But it's not clear to
> > me 
> > if the existing autobuilding system would need to accommodate that.
> 
> We'd be open to helping to put something together so that Debusine
> could
> do this, if that's something people would be interested in.  Roughly,
> there could be a private workspace owned by the DFSG team with
> workflow templates that just run sbuild on a given source package (in
> a
> VM, since these haven't been reviewed yet); when the DFSG team's 
> machinery sees a new source upload for which it doesn't have
> binaries, 
> it would upload those artifacts to Debusine and start a workflow to 
> build them.  When the workflow finishes they could fetch the
> resulting 
> binaries and stuff them in as supplemental data for the review.  They
> could run more tests if they wanted, maybe lintian or something, but
> I'm 
> guessing they already have arrangements for that.
> 
> This would all be a bit best-effort for the time being.  We don't
> have 
> outgoing webhooks to notify other services about workflow completion 
> yet, so for now you'd have to poll for completion (I expect we'll 
> implement outgoing webhooks later this year); and it's not entirely 
> clear how to handle uploads that build-depend on other things in NEW 
> (sometimes that would be necessary, but you probably don't want to
> allow 
> it automatically).  All the same, I think this is one of the easiest 
> ways to get something like this going.
> 
> If the DFSG team is interested in this, then an issue in 
> https://salsa.debian.org/freexian-team/debusine.debian.net/support/-/issues
>  
> would be a good place to talk through the details.

-- 
--
Porirua, New Zealand +64 (27) 288 6741

   Man is the measure of all things.
-- Protagoras
--

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Philipp Kern]

On 2/18/26 11:51 PM, Colin Watson wrote:

[CC: removed bug #1127616; added dfsg-team@]

On Mon, Feb 16, 2026 at 09:00:13PM +0100, Philipp Kern wrote:

On 2/12/26 1:11 PM, Ian Jackson wrote:
Sean Whitton writes ("Bug#1127616: developers-reference: should 
document using git-debpush to upload"):

I think one source of opposition for autobuilding packages before they
go into NEW is that the DFSG team won't yet has asserted/confirmed that
the license permits autobuilding.  But, well, we already have Salsa CI,
so I think that is not worth blocking on.


Indeed.

I don't know much about how the autobuilding system works but I would
love it if someone who did understand that would figure out how to
make this work.


I think I'd strongly prefer not to autobuild code on the existing 
systems that has not been vetted yet. So then we'd need a separate 
infrastructure for that.


I wouldn't mind if there is the moral equivalent of sending the upload 
to Salsa CI and use the outputs for review. But it's not clear to me 
if the existing autobuilding system would need to accommodate that.


We'd be open to helping to put something together so that Debusine could
do this, if that's something people would be interested in.  Roughly, 
there could be a private workspace owned by the DFSG team with

workflow templates that just run sbuild on a given source package (in a
VM, since these haven't been reviewed yet); when the DFSG team's 
machinery sees a new source upload for which it doesn't have binaries, 
it would upload those artifacts to Debusine and start a workflow to 
build them.  When the workflow finishes they could fetch the resulting 
binaries and stuff them in as supplemental data for the review.  They 
could run more tests if they wanted, maybe lintian or something, but I'm 
guessing they already have arrangements for that.


This would all be a bit best-effort for the time being.  We don't have 
outgoing webhooks to notify other services about workflow completion 
yet, so for now you'd have to poll for completion (I expect we'll 
implement outgoing webhooks later this year); and it's not entirely 
clear how to handle uploads that build-depend on other things in NEW 
(sometimes that would be necessary, but you probably don't want to allow 
it automatically).  All the same, I think this is one of the easiest 
ways to get something like this going.


If the DFSG team is interested in this, then an issue in https:// 
salsa.debian.org/freexian-team/debusine.debian.net/support/-/issues 
would be a good place to talk through the details.


That sounds like an excellent use of Debusine to me.

(I held at Debconf that Debusine will likely need to show value for new 
use cases that we cannot accomodate easily with the existing 
infrastructure for now.)


Kind regards
Philipp Kern

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Colin Watson]

[CC: removed bug #1127616; added dfsg-team@]

On Mon, Feb 16, 2026 at 09:00:13PM +0100, Philipp Kern wrote:

On 2/12/26 1:11 PM, Ian Jackson wrote:

Sean Whitton writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):

I think one source of opposition for autobuilding packages before they
go into NEW is that the DFSG team won't yet has asserted/confirmed that
the license permits autobuilding.  But, well, we already have Salsa CI,
so I think that is not worth blocking on.


Indeed.

I don't know much about how the autobuilding system works but I would
love it if someone who did understand that would figure out how to
make this work.


I think I'd strongly prefer not to autobuild code on the existing 
systems that has not been vetted yet. So then we'd need a separate 
infrastructure for that.


I wouldn't mind if there is the moral equivalent of sending the upload 
to Salsa CI and use the outputs for review. But it's not clear to me 
if the existing autobuilding system would need to accommodate that.


We'd be open to helping to put something together so that Debusine could
do this, if that's something people would be interested in.  Roughly, 
there could be a private workspace owned by the DFSG team with

workflow templates that just run sbuild on a given source package (in a
VM, since these haven't been reviewed yet); when the DFSG team's 
machinery sees a new source upload for which it doesn't have binaries, 
it would upload those artifacts to Debusine and start a workflow to 
build them.  When the workflow finishes they could fetch the resulting 
binaries and stuff them in as supplemental data for the review.  They 
could run more tests if they wanted, maybe lintian or something, but I'm 
guessing they already have arrangements for that.


This would all be a bit best-effort for the time being.  We don't have 
outgoing webhooks to notify other services about workflow completion 
yet, so for now you'd have to poll for completion (I expect we'll 
implement outgoing webhooks later this year); and it's not entirely 
clear how to handle uploads that build-depend on other things in NEW 
(sometimes that would be necessary, but you probably don't want to allow 
it automatically).  All the same, I think this is one of the easiest 
ways to get something like this going.


If the DFSG team is interested in this, then an issue in 
https://salsa.debian.org/freexian-team/debusine.debian.net/support/-/issues 
would be a good place to talk through the details.


--
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Pierre-Elliott Bécue]

Ian Jackson  wrote on 11/02/2026 at 
13:56:01+0100:

> Jochen Sprickerhof writes ("Bug#1127616: developers-reference: should 
> document using git-debpush to upload"):
>> My perception is rather different here:
>> 
>> Python Team:
>> "DPT requires a pristine-tar branch"
>> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>> 
>> Science Team:
>> "It is recommended to use pristine-tar"
>> https://science-team.pages.debian.net/policy/
>> 
>> Multimedia Team:
>> "gbp clone --pristine-tar"
>> https://wiki.debian.org/DebianMultimedia/DevelopPackaging
>
> Thanks for the links.
>
> This is all very sad.
>
> I think not everyone realises that "pristine" in pristine-tar is
> sarcastic!  Joey Hess, the original author of pristine-tar (and many
> useful Debian things) has excoriated Debian's tarball fetish, writing
> of us "hoarding and rolling around in on [our] nest of gleaming
> pristine tarballs" [1].
>
> That was in 2013!  This tarball fetish has only become more obsolete
> since then, but also simultaneously more entrenched in Debian :-(.

I want very strongly to believe that you mean well, but the consistent
pattern of either aggressive or passive-aggressive behaviour you showed
in the past years, be that because of systemd, or around your other
fields of preferrence is starting to be too much.

Calling tarball-shipping a fetish is irrelevant, petty and insulting.

I strongly suggest that you reconsider your way of interacting with
others in order to:

 - avoid diminishing them or their position. The former is never
   relevant, and the latter is not the proper way to expose your
   arguments;
 - reduce friction and conflicts;
 - avoid nice and relevant people to just stop caring, contributing, or
   worse, leaving (see Antoine's mail).

It's not the first time you're being called out about the way you do
interact. We're a community of people trying to work together in spite
of our cultural differences, our different opinions and preferences.
Driving others off because they dare not thinking the same way you do is
not OK.

-- 
PEB

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Philipp Kern]

On 2/12/26 1:11 PM, Ian Jackson wrote:

Sean Whitton writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):

I think one source of opposition for autobuilding packages before they
go into NEW is that the DFSG team won't yet has asserted/confirmed that
the license permits autobuilding.  But, well, we already have Salsa CI,
so I think that is not worth blocking on.


Indeed.

I don't know much about how the autobuilding system works but I would
love it if someone who did understand that would figure out how to
make this work.


I think I'd strongly prefer not to autobuild code on the existing 
systems that has not been vetted yet. So then we'd need a separate 
infrastructure for that.


I wouldn't mind if there is the moral equivalent of sending the upload 
to Salsa CI and use the outputs for review. But it's not clear to me if 
the existing autobuilding system would need to accommodate that.


Kind regards
Philipp Kern

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[gregor herrmann]

On Wed, 11 Feb 2026 13:42:46 +0100, Jochen Sprickerhof wrote:


* Sean Whitton  [2026-02-11 11:52]:

For example, I maintain or team half-maintain maybe 90 packages in
total, and none of them use pristine-tar.  So the only case where I
cannot use tag2upload is when I need to upload to NEW, which is not
often.  Therefore tag2upload is my default way to upload, because why
wouldn't it be, it's so smooth and easy.

My perception is rather different here:


Mine as well.


Python Team:

"DPT requires a pristine-tar branch"

https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Science Team:

"It is recommended to use pristine-tar"

https://science-team.pages.debian.net/policy/

Multimedia Team:

"gbp clone --pristine-tar"

https://wiki.debian.org/DebianMultimedia/DevelopPackaging


Debian Perl Group:
https://perl-team.pages.debian.net/git.html
(gbp with pristine-tar as the default, notwithstanding some other 
approaeches in individual packages.)



Also most of my uploads are new upstream versions.


Same here.


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: security-uploads & tooling (Re: Bug#1127616: developers-reference: should document using git-debpush to upload)

[Ian Jackson]

Andreas Metzler writes ("Re: security-uploads & tooling (Re: Bug#1127616: 
developers-reference: should document using git-debpush to upload)"):
> On 2026-02-12 Holger Levsen  wrote:
> [...]
> > more seriously, the only difference between normal uploads and uploads
> > to security master is the upload host. thats really all.
> 
> No, I guess the complicated bit is [...]

No.  The difficulty is not to do with origs.[1]

But, contrary to what Marc says, it *is* significantly more
complicated to implement.

The situation is explained in
  #1050143  dgit: support uploading to security-master
which in turn is blocked by
  #862105   Please enable me to support dgit push
against security.debian.org.

The root of the difficulty is that security uploads can be embargoed.

So there needs to be machinery for keeping them secret for the right
amount of time.  That means (a) a git server with secret repos, or
secret branches, or soemthing, which is a thing we can do, but also
(b) some kind of way for that git server to find out which things it
should make public, and when.

Ian.

[1] src:dgit already has many epicycles[2] to deal with the legacy
archives' bizarre behaviours with respect to origs.  I think those
epicycles would be sufficient, but we can always add more...

[2] https://en.wikipedia.org/wiki/Deferent_and_epicycle

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Fri, Feb 13, 2026 at 08:35:51AM -0800, Russ Allbery wrote:

Marc Haber  writes:

On Fri, Feb 13, 2026 at 01:00:02AM +0100, Simon Josefsson wrote:



That would solve the problem, but it will be weaker.  Upstream tarballs
and signatures disappear or are modified over time, and more often that
we like or even want to admit.  Users won't generally be able to find
and locate those upstream signature corresponding to whatever tarball
ended up in Debian.  If we store upstream tarballs, and verify their
digital signatures, I think we should also store upstream digital
signatures.



We do, don't we?


Simon's point is that we do not store upstream signatures other than the
very specific case of PGP signatures.


Well trolled.


Previously that was about the only
case that matters, but increasingly that's not true.


And at the same time we're moving away from source tarballs. Do 
upstreams put Non-OpenPGP Signatures on their release tags?



I think this was all a bit orthogonal to the point you were trying to
make, although it does imply that we probably need a better way of
thinking about upstream signatures more generally.


Or decide tha we stopped caring.

Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: security-uploads & tooling (Re: Bug#1127616: developers-reference: should document using git-debpush to upload)

[Andreas Metzler]

On 2026-02-12 Holger Levsen  wrote:
[...]
> more seriously, the only difference between normal uploads and uploads
> to security master is the upload host. thats really all.

No, I guess the complicated bit is that the security repository does not
have the orig.tar.* unless there was a previous upload of this upstream
version to the security repository. So these uploads often (but not
always) need to built with -sa.

cu Andreas

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Otto Kekäläinen [13/Feb 10:19pm +08] wrote:
> (dropping bug report from recipients)
>
>> > I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
>> > https://udd.debian.org/cgi-bin/dep14stats.cgi
>> >
>> > 72.8% of packages with a working salsa project have a pristine-tar
>> > branch.
>> >
>> > Among salsa groups with more than 200 packages in testing, the following
>> > have more than 80% of group-maintained packages that have a pristine-tar
>> > branch:
>>
>> I would really appreciate knowing whether these branches are in use --
>> whether they have the most recent upstream versions imported to them.
>
> We could do a scan to see if gbp.conf has `pristine-tar = True`,
> assuming only packages that have that configured in the package itself
> will consistently be using it.

I think that field is often there but out-of-date.

I know I've ignored it.

> Another data point that comes to my mind is
> https://debaudit.debian.net/orig-check/statistics showing 23239
> packages (58.60%) have a orig tarball that is bit-for-bit identical
> with upstream tarball, suggesting they used pristine-tar in one way or
> another.

I don't believe that inference is valid.

Re-using bit-for-bit identical upstream tarballs, and storing those
tarballs on salsa using the pristine-tar tool, are not the same thing at
all.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Russ Allbery]

Marc Haber  writes:
> On Fri, Feb 13, 2026 at 01:00:02AM +0100, Simon Josefsson wrote:

>> That would solve the problem, but it will be weaker.  Upstream tarballs
>> and signatures disappear or are modified over time, and more often that
>> we like or even want to admit.  Users won't generally be able to find
>> and locate those upstream signature corresponding to whatever tarball
>> ended up in Debian.  If we store upstream tarballs, and verify their
>> digital signatures, I think we should also store upstream digital
>> signatures.

> We do, don't we?

Simon's point is that we do not store upstream signatures other than the
very specific case of PGP signatures. Previously that was about the only
case that matters, but increasingly that's not true.

I think this was all a bit orthogonal to the point you were trying to
make, although it does imply that we probably need a better way of
thinking about upstream signatures more generally.

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Russ Allbery]

"Theodore Tso"  writes:

> The features I use of git-buildackage is (a) making sure I'm building
> from a valid branch for building debian packages, (b) using
> pristine-tar to extract the proper tar.gz file, (c) specifying the
> correct options to sbuild for a particular debian branch --- e.g., in
> my debian/backports branch, the debian/gbp.conf file contains:

>[DEFAULT]
>pristine-tar = True
>upstream-tag='v%(version)s'
>debian-branch=debian/backports

>[buildpackage]
>builder = sbuild -A -s -v -d bookworm-backports

(b) is useful when using pristine-tar, I agree. It's a little bit annoying
to have to remember to run origtargz before building, and git-buildpackage
handles that.

(c) I think is unnecessary with the default behavior of sbuild? Maybe I'm
missing some subtlety, but I have never had to explicitly tell sbuild what
chroot to use. It picks one based on the target distribution in the latest
entry in debian/changelog (probably indirected through some other file
generated from that), so all I have to do is make sure the aliases are set
up correctly one time (and when I start building for a new release) and
then it works for all packages without any additional configuration.

> Well, I started by using "gbp buildpackage", and I have things set up
> so that all of the magic options needed by sbuild, et. al, are
> automatically specified based on what branch I have checked out what I
> am doing.  My preference is to avoid needing to type complex commands
> like:

>dgit sbuild -A -s -v -d bookworm-backports

> ... because I will invariablty forget some option, or typo the name of
> the schroot, etc.

Right, I completely agree. No one is arguing that you should have to
remember something like this, just as no one is arguing that you should
use patches-unapplied branches. :)

I also use patches-unapplied and want the correct sbuild chroot to be
autoselected, and I just run "dgit sbuild" and everything works. I'm
trying to figure out how to get you to a similar place so that you don't
have to think about any of this when you are working on your package.

One way to do that would be to stop doing the build with git-buildpackage
and just run "dgit sbuild" and let dgit talk to sbuild directly without
the git-buildpackage wrapper. I think this may require that you run
origtargz before doing a build (and therefore have a *.orig.tar.gz in the
parent directory of your current directory, in case that's not where you
currently keep them).

Another alternative would be to keep using gbp-build but configure dgit so
that it knows that you're using patches-applied, which is not the default
assumption for gbp-build. There's some, unfortunate for your use case,
mixing of defaults between using patches-unapplied and using
git-buildpackage since I'm pretty sure nearly everyone using
git-buildpackage is using patches-unapplied.

The latter option involves the least change to what you're doing now. I
think the remaining problem is that changing the *default* dgit --quilt
behavior doesn't change the behavior for gbp-build specifically, since
gbp-build assumes you're using patches-unapplied and overrides the --quilt
default accordingly (as documented in the dgit man page).

I think it makes sense for gbp-build to assume patches-unapplied since
that is by far the most common case, but maybe it would make sense to have
a dgit option that you can add to your .gitconfig or .git/config that
overrides that behavior. Maybe this already exists and I just don't know
about it?

> For me, "gbp buildpackage ; dupload" is simple, and easy.  Needing to
> type some complex command, such as

>dgit --quilt=nofix gbp-build

> means that I will forget, because I'm not typing these commands often
> enough for them to be finger macros.

Right, everyone understands. No one wants you to have to type in more
complicated commands.

> If the dgit maintainers want to make it easy so that "dgit gbp-build"
> always does the right thing --- or even "dgit sbuild" without needing
> any magic options added to the comandline, because I can specify the
> option that needed depending on whether I'm building for unstable,
> backports, or old-backports, via some per-branch config file, great.

This part already just works out of the box with sbuild so far as I can
tell. Even with git-buildpackage, I suspect specifying this explicitly may
be unnecessary (but I don't know for sure since I haven't used
git-buildpackage in some time).

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Lucas Nussbaum]

On 13/02/26 at 22:19 +0800, Otto Kekäläinen wrote:
> Another data point that comes to my mind is
> https://debaudit.debian.net/orig-check/statistics showing 23239
> packages (58.60%) have a orig tarball that is bit-for-bit identical
> with upstream tarball, suggesting they used pristine-tar in one way or
> another.

Not necessarily. As Sune pointed out, those packages could use a
debian-dir-only workflow, using origtargz to download the upstream
tarball (from the archive or using uscan).

Lucas

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Andrey Rakhmatullin]

On Fri, Feb 13, 2026 at 10:19:58PM +0800, Otto Kekäläinen wrote:

> I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
> https://udd.debian.org/cgi-bin/dep14stats.cgi
>
> 72.8% of packages with a working salsa project have a pristine-tar
> branch.
>
> Among salsa groups with more than 200 packages in testing, the following
> have more than 80% of group-maintained packages that have a pristine-tar
> branch:

I would really appreciate knowing whether these branches are in use --
whether they have the most recent upstream versions imported to them.


We could do a scan to see if gbp.conf has `pristine-tar = True`,
assuming only packages that have that configured in the package itself
will consistently be using it.


We could, but we need to consider that not everyone does this.

--
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Otto Kekäläinen]

(dropping bug report from recipients)

> > I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
> > https://udd.debian.org/cgi-bin/dep14stats.cgi
> >
> > 72.8% of packages with a working salsa project have a pristine-tar
> > branch.
> >
> > Among salsa groups with more than 200 packages in testing, the following
> > have more than 80% of group-maintained packages that have a pristine-tar
> > branch:
>
> I would really appreciate knowing whether these branches are in use --
> whether they have the most recent upstream versions imported to them.

We could do a scan to see if gbp.conf has `pristine-tar = True`,
assuming only packages that have that configured in the package itself
will consistently be using it.

Another data point that comes to my mind is
https://debaudit.debian.net/orig-check/statistics showing 23239
packages (58.60%) have a orig tarball that is bit-for-bit identical
with upstream tarball, suggesting they used pristine-tar in one way or
another.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Theodore Tso [13/Feb  8:52am -05] wrote:
> One other thought.  One of the reasons I have a *strong* opinion why
> patches-applied is the superior way is because I want to be able to
> run native build and regression tests --- e.g., "./configure ; make ;
> make check" on the git repo should run the tests on the same codebase
> as "dpkg-buildpackage -us -uc -b" --- the only difference that being
> the config options specified by debian/rules might be different.

We all (Russ, Ian, me) agree with you that patches-applied is better.

That is why we use git-debrebase, and only minimally gbp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Theodore Tso]

One other thought.  One of the reasons I have a *strong* opinion why
patches-applied is the superior way is because I want to be able to
run native build and regression tests --- e.g., "./configure ; make ;
make check" on the git repo should run the tests on the same codebase
as "dpkg-buildpackage -us -uc -b" --- the only difference that being
the config options specified by debian/rules might be different.

So my general pattern is to run a successive set of tests on the same
branch:

1)  running "make check" in my development environment
2)  running "dpkg-buildpackage" in my development environment
3)  running "schroot -c sid -- dpkg-buildpackage" to test whether
things work in a non-hermetic unstable environment
4)  running "gbp buildpackage" which runs a package build in a hermetic
environment

... and only *then* will I start the dgit workflow.

This might waste some CPU, but if there is a change in the unstable
version of pkgconfig[1], that might be a reason why (2) passes, but
(3) does not.  And CPU time is much cheaper and more abundant than my
personal time.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126636

And most *definitely* I want to be able to test and debug things
locally before I try to use tag2upload.

- Ted

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sune Vuorela]

On 2026-02-13, Sean Whitton  wrote:
>> Also note - for the tar usage the amount of repositories that are
>> debian-dir only.
>>
>> That's also workflows requiring tarballs.
>
> Not with tag2upload :)
>
> tag2upload can handle debian/-directory-only repositories where the
> upstream source is represented as a git tag, not a tarball.

While you are technically correct, for most people I think this is not a
helpful and relevant distinction.

I have at least heard the comment from some teams:
"We have enough copies of the sourcecode with full history on our disks.
we don't need more"

/Sune

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Sune Vuorela [13/Feb  9:30am GMT] wrote:
> On 2026-02-12, Lucas Nussbaum  wrote:
>> I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
>> https://udd.debian.org/cgi-bin/dep14stats.cgi
>>
>> 72.8% of packages with a working salsa project have a pristine-tar
>> branch.
>
> Also note - for the tar usage the amount of repositories that are
> debian-dir only.
>
> That's also workflows requiring tarballs.

Not with tag2upload :)

tag2upload can handle debian/-directory-only repositories where the
upstream source is represented as a git tag, not a tarball.

You would need a tarball to build locally, that's fair.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Ian Jackson [13/Feb 12:14am GMT] wrote:
> What you're doing is very much a minority thing.  I think the
> documentation is adequately clear that these options and modes are for
> use with patches-unapplied branches, unless overridden.  At this
> point, I'm inclined to think that adding more caveats about this would
> reduce clarity for the large majority of readers.
>
> But I'll CC Sean to see if he agrees.

I agree.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Lucas Nussbaum [12/Feb 10:25pm +01] wrote:
> I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
> https://udd.debian.org/cgi-bin/dep14stats.cgi
>
> 72.8% of packages with a working salsa project have a pristine-tar
> branch.
>
> Among salsa groups with more than 200 packages in testing, the following
> have more than 80% of group-maintained packages that have a pristine-tar
> branch:

I would really appreciate knowing whether these branches are in use --
whether they have the most recent upstream versions imported to them.

For example I often find pristine-tar branches but just ignore them,
where team policy allows me to.  So the fact that someone used it once
may not mean much statistically.

git-debpush has code in it to detect whether the current release in
d/changelog is represented in the pristine-tar branch if you want to
crib from somewhere.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Arto Jantunen]

Marc Haber  writes:
> There is some place where we need to stop, or should we mirror the
> original author's pgp key as well?

We most definitely should (and in many cases we already store these in
source packages)!

Considering the state of the GPG keyserver infra sometimes upstream
public keys are already surprisingly difficult to find, and this will
only get worse as time goes on.

-- 
Arto Jantunen

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Fri, Feb 13, 2026 at 01:00:02AM +0100, Simon Josefsson wrote:

Marc Haber  writes:

On Thu, Feb 12, 2026 at 06:25:07PM +0100, Simon Josefsson wrote:

Marc Haber  writes:

I THINK that we should recommend including the form that upstream
publishes with their signature.


Do you mean that generally, or more specifically 'PGP signature'?

Many upstream now sign their releases using Sigstore, Sigsum, SSH
Signatures and other non-PGP formats.  I expect non-PGP to be more
common than PGP signatures relatively soon, if this hasn't already
happened (depending on what kind of upstreams you count).

It would be nice if Debian supported more formats for verifying upstream
signatures.  Right now we just throw away many signatures.  Bonus points
for storing and publishing the non-PGP formats too.


The nice thing about having the original upstream tarballs in our
archive is that we don't have to care about that. People can verify
that our tarballs are the same than upstream's and then check whatever
signature upstream chose to apply.


Oh, then I think I misunderstood you.  Did you intend to recommend that
Debian do not store a copy of the upstream digital signature together
with the tarball at all?


Where did you read that?

There is some place where we need to stop, or should we mirror the 
original author's pgp key as well?


I just find it elegant that there is a way to go from what Debian has in 
the archive to the upstream web site and verify that both are the same. 
If not, more scrutiny is recommended.



That would solve the problem, but it will be weaker.  Upstream tarballs
and signatures disappear or are modified over time, and more often that
we like or even want to admit.  Users won't generally be able to find
and locate those upstream signature corresponding to whatever tarball
ended up in Debian.  If we store upstream tarballs, and verify their
digital signatures, I think we should also store upstream digital
signatures.


We do, don't we?


And support whatever upstream digital signature format used
(limited to widely implemented variants like PGP, SSH, Sigstore, Sigsum,
minisign, signify, ...).


as long as I dont have to work on that, okay with me.

Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Thu, Feb 12, 2026 at 11:30:35PM +0100, intrigeri wrote:

While the mere existence of a pristine-tar branch strongly suggests
the packaging has at least used pristine-tar at some point in history,
it does not necessary mean it *currently* uses pristine-tar.


I would in that case rename the pristine-tar branch to make sure that it 
doesn't accidentally get used. They will also avoid surprise when it is 
removed eventually and things break THEN.


Greetings
Marc, who is also surprised that pristine-tar didn't get DEPped into 
debian/pristine-tar


--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sune Vuorela]

On 2026-02-12, Lucas Nussbaum  wrote:
> I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
> https://udd.debian.org/cgi-bin/dep14stats.cgi
>
> 72.8% of packages with a working salsa project have a pristine-tar
> branch.

Also note - for the tar usage the amount of repositories that are
debian-dir only.

That's also workflows requiring tarballs.

/Sune

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Nicolas Schodet]

* Sean Whitton  [2026-02-12 12:11]:
> As a DM, in order to use dgit (but not tag2upload), you need your key
> adding to a certain keyring.
> Send it in a signed message to dgit-ow...@debian.org.

Thanks, I made the request.

* Ian Jackson  [2026-02-12 17:47]:
> You could email me your ssh public key, with your PGP signature on the
> email, and I'll install it.  Or get your sponsor to make an MR against
>   https://salsa.debian.org/dgit-team/extra-push-ssh-keys
> (which is a private repository because it contains personal data).

Thanks for the offer. I made the request to dgit-owner as Sean
suggested.

Nicolas.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Fabian Grünbichler]

On February 12, 2026 11:30:35 PM GMT+01:00, intrigeri  
wrote:
>Hi,
>
>Lucas Nussbaum (2026-02-12):
>> I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
>> https://udd.debian.org/cgi-bin/dep14stats.cgi
>
>Thanks!
>
>> 72.8% of packages with a working salsa project have a pristine-tar
>> branch.
>
>While the mere existence of a pristine-tar branch strongly suggests
>the packaging has at least used pristine-tar at some point in history,
>it does not necessary mean it *currently* uses pristine-tar.

The inverse might be true as well ;)

For the Rust team, only a handful of "traditionally" maintained
packages use pristine-tar. But 99% of the rest still use upstream
tarballs as their source of upstream sources, despite not
having a pristine-tar branch (they don't even track the full debian/
dir in git).

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Lucas Nussbaum]

On 12/02/26 at 23:30 +0100, intrigeri wrote:
> Hi,
> 
> Lucas Nussbaum (2026-02-12):
> > I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
> > https://udd.debian.org/cgi-bin/dep14stats.cgi
> 
> Thanks!
> 
> > 72.8% of packages with a working salsa project have a pristine-tar
> > branch.
> 
> While the mere existence of a pristine-tar branch strongly suggests
> the packaging has at least used pristine-tar at some point in history,
> it does not necessary mean it *currently* uses pristine-tar.
> 
> As a data point, this week I've converted a package to a pure-Git
> workflow, so it won't use the pristine-tar branch anymore. But I have
> no strong incentive to delete that branch on Salsa, so I plan to leave
> it alone, just in case someone may find it useful.
> 
> I doubt this makes a big difference to the results right now. But *if*
> more and more packages migrate away from pristine-tar, I understand
> these stats simply won't reflect this evolution, and the numbers
> *might* get more and more misleading to readers who interpret these
> numbers as a gauge of current popularity. Does this make sense?
> 
> If there's a good way to improve this at some point, it would be great.
> 
> In the meantime, what about making the phrasing on the webpage reflect
> this reality better than the current "N packages […] use
> pristine-tar", so future readers of dep14stats.cgi are better equipped
> to interpret the data? For example: "use pristine-tar, or have used it
> in the past".

Hi,

I improved the wording, thanks!

It would be interesting to check the tarball generated from the vcs-git
repo against the orig tarball in the archive. That would be a nice
addition to debaudit.debian.net.

Lucas

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Theodore Tso]

On Thu, Feb 12, 2026 at 06:12:59PM -0800, Russ Allbery wrote:
> 
> Have you tried just running dgit sbuild? That invokes sbuild directly
> rather than git-buildpackage, so maybe that skips something that you're
> relying on, but that worked fine for me when I started moving away from
> git-buildpackage.

The features I use of git-buildackage is (a) making sure I'm building
from a valid branch for building debian packages, (b) using
pristine-tar to extract the proper tar.gz file, (c) specifying the
correct options to sbuild for a particular debian branch --- e.g., in
my debian/backports branch, the debian/gbp.conf file contains:

   [DEFAULT]
   pristine-tar = True
   upstream-tag='v%(version)s'
   debian-branch=debian/backports

   [buildpackage]
   builder = sbuild -A -s -v -d bookworm-backports

> Anyway, I think you are running into problems because you thought you
> needed to use all the gbp options because you're using git-buildpackage,
> but all those options do complicated things to handle patches-unapplied
> trees. Since you have a patches-applied tree, I don't think you need any
> of that and adding gbp- and --gbp and whatnot may just be breaking things
> for you.

Well, I started by using "gbp buildpackage", and I have things set up
so that all of the magic options needed by sbuild, et. al, are
automatically specified based on what branch I have checked out what I
am doing.  My preference is to avoid needing to type complex commands
like:

   dgit sbuild -A -s -v -d bookworm-backports

... because I will invariablty forget some option, or typo the name of
the schroot, etc.

For me, "gbp buildpackage ; dupload" is simple, and easy.  Needing to
type some complex command, such as

   dgit --quilt=nofix gbp-build

means that I will forget, because I'm not typing these commands often
enough for them to be finger macros.  In fact, I think I had figured
out the fact that dgit gbp-build requires adding the magic
--quilt=nofix option before.  But I had forgotten it some 6-12 months
later when I needed to build e2fsprogs with a non-zero debian/patches
directory.  Needing to stare at the dgit man page to figure it out is
just annoying.

I suppose I could create my own shell script that has all of the magic
incantations required by dgit, whether it's --quilt=nofix, or
specifying all of the options which sbuild requires on the command
line.  But quite frankly, it's a lot easier to just say, screw it,
I'll just skip using dgit when it doesn't work out of the box.  It
means that dgit repo will have some fast forwards in it, but so long
as the source .dsc plus debian tarfile is authoratative, and for my
part, given that I consider the preferred form of modifiction to be
the debian/{master,backports} branch in my e2fsprogs git repo, and not
the dgit repo --- shrug.

If the dgit maintainers want to make it easy so that "dgit gbp-build"
always does the right thing --- or even "dgit sbuild" without needing
any magic options added to the comandline, because I can specify the
option that needed depending on whether I'm building for unstable,
backports, or old-backports, via some per-branch config file, great.
Otherwise, I'm not convinced it's adding any value for me.

Cheers,

- Ted

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Russ Allbery]

"Theodore Tso"  writes:

> Are you really certain everyone who uses gbp also uses "gbp pq"?
> [Citation needed.]

You are the first person I've heard of who uses git-buildpackage with
patches applied, as a data point. I'm sure you're not the only person
doing that! But I also thought the "standard" way to use it is patches
unapplied.

That doesn't necessarily mean using gbp pq. I used git-buildpackage with
quilt for years before gbp pq was written.

Everyone wants very simple Debian tools with very simple documentation (I
do too!), but the problem with simple tools and even more so with simple
documentaiton is that we have almost as many workflows as we have Debian
contributors, and every one of them thinks their workflow is just the
normal one. :)

> No, I want to make sure that I am building the package in a hermetic
> build environment.  Which is to say, I want to build using sbuild so I
> can make sure it builds correctly in the latest unstable environment
> and using the minimal set of patches so I can make sure the
> Build-Depends line in debian/control is correct, *before* I do an upload.

Have you tried just running dgit sbuild? That invokes sbuild directly
rather than git-buildpackage, so maybe that skips something that you're
relying on, but that worked fine for me when I started moving away from
git-buildpackage.

Anyway, I think you are running into problems because you thought you
needed to use all the gbp options because you're using git-buildpackage,
but all those options do complicated things to handle patches-unapplied
trees. Since you have a patches-applied tree, I don't think you need any
of that and adding gbp- and --gbp and whatnot may just be breaking things
for you.

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Theodore Tso]

On Fri, Feb 13, 2026 at 12:14:08AM +, Ian Jackson wrote:
> 
> In my experience patches-unapplied is used in majority of packaging
> repositories, and in my experience many people even regard it as
> officially blessed, or aren't aware that there are alternatives.
> I haven't done a survey but I am pretty sure that my claim that it is
> "the usual way that people use gbp" is correct.

Well, you _can_ use "gbp pq", which basicaly gives you quilt-sytle
interface.  But it only makes sense if you are working with external
patches and you aren't particularly comfortable with git.  Personally,
I think it's a terrible and not particularly useful interface,
especially if the patches that you want are already in the upstream
git repo, and all you want to do is to cherry-pick them into the
debian/master or debian/backport branch.  In any case, it is a purely
optional module in gbp, and it is mostly certainly not mandatory to
use it if you want to take advantage of the other benefits of gbp.

In other words, I didn't have to do anything special to use gbp with a
patch-applied debian/master.  It's not like I had to take advantage of
any configuration flexibility in gbp.

Are you really certain everyone who uses gbp also uses "gbp pq"?  [Citation 
needed.]

> > >dgit build-source
> > 
> > Sure, but that doesn't do a hermetic build.
> 
> I'm not sure what you mean.  Are you concerned that the .dsc is
> being built in an environment with uncontrolled other dependencies?

No, I want to make sure that I am building the package in a hermetic
build environment.  Which is to say, I want to build using sbuild so I
can make sure it builds correctly in the latest unstable environment
and using the minimal set of patches so I can make sure the
Build-Depends line in debian/control is correct, *before* I do an upload.

Put another way, my primary development environment is Debian/testing,
with a lot of convenience packages included.  (I'm not brave enough to
use Debian unstable, after too many cases where my primary environment
was broken by broken unstable upload.)  My normal development
environment is where I do my upstream Kernel and e2fsprogs
development.  So I've already run my normal set of regression testing
using a non-hermetic environment, and before I do a release, I've
already used github's CI infrastructure to make sure e2fsprogs builds
on Windows and MacOS, and I've run non-hermetic "./configure ; make ;
make check" runs on PowerPC and S390 developer machines, as well as on
a FreeBSD VM.

One of my last QA checks is to do a hermetic build using sbuild.  So I
create the upstream tarball, sign it, deposit into my git repository
using pristine-tar.  Then I run "git checkout debian/master ; git
merge master ; gbp buildpackage".  (where gbp is configured to use a
builder of "sbuild -A -s -v")

If that works, only *then* do I do a "dit gbp-build ; dgit push".

So there are an awful lot of consistency checks that I do; it's not
just about making sure .dsc == git.  In fact, I don't think that's
*ever* been the issue in terms of quality control checks where I've
caught issues before I do an upstream release or do a dupload.

> > Hmm... will something like "dgit --quilt=nofix gbp-build" do what I
> > want?  And if so, I can put something like
> 
> I should think so.
> 
> > [dgit "default"]
> > build-products-dir = /tmp/gbp
> > quilt = nofix
> 
> Yes, you can do that.

I just tried it, and it doesn't work.  Apparently that only sets
--quilt=nofix as the default for "dgit build" or "dgit sbuild".  It
does *not* override the default for "dgit gbp-build".  I can't seem to
find a way override the default --quilt setting for dgit gbp-build.
Is there a way to do that?

> You shoudln't, because the /tmp/gbp is a "use of fixed filename in
> /tmp" vulnerability!  Like most programs, dgit is not prepared to deal
> with the possibly hostile bizarrenesses that can occur in /tmp, except
> for files that it itself creates in /tmp or TMPDIR or such.
> 
> I suspect that your *fingers* have a "use of fixed filename in /tmp"
> vulnerability.  This is OK on a machine (or VM or container) on which
> all software is completely trusted, but that is rarely the situation.

This is on my (single user) development system that I use for upstream
development.  It's where I sign kernel tags before doing send git
request-pulls to Linus, and from where I upload packages to Debian.
If it is compromised, attacks involving /tmp/gbp would be the *least*
of my worries.

> So manual use of /tmp rather than (say) ~/tmp is a really bad habit.)

I use /tmp instead of ~/tmp because I'm trying to avoid SSD write
wearout.  (/tmp is a tmpfs file system)

- Ted

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

(trimming the CC somewhat)

Theodore Tso writes ("Re: Bug#1127616: developers-reference: should document 
using git-debpush to upload"):
> On Thu, Feb 12, 2026 at 05:37:26PM +, Ian Jackson wrote:
> > dgit-maint-gbp(7) is describing patches-unapplied, which is the usual
> > way that people use gbp (and gbp pq etc.)
> 
> I don't know why you say that --- "gbp buildpackage" works just *fine*
> for me and I'm using a patches applied workflow.  In fact, that's what
> I fall back to after "dgit gbp-build" fails for me.

I'm not sure which part of my statement you are questioning.

dgit-maint-gbp(7) says in terms, in paragraph 3, that it is describing
patches-unapplied.

In my experience patches-unapplied is used in majority of packaging
repositories, and in my experience many people even regard it as
officially blessed, or aren't aware that there are alternatives.
I haven't done a survey but I am pretty sure that my claim that it is
"the usual way that people use gbp" is correct.

It is true that gbp buildpackage generally does work with
patches-applied repositories, indeed.  gbp is a flexible tool and even
has certain amount of dwimmery.

In summary, I think this quote from dgit-maint-gbp(7) is accurate both
as to the scope of the guidance in that manpage, and as to the most
common way that gbp is used:

Note that we assume a patches-unapplied repository: the
upstream source committed to the git repository is unpatched.
git-buildpackage(1) can work with patched-applied repositories,
but is normally used with patches-unapplied.

> >dgit build-source
> 
> Sure, but that doesn't do a hermetic build.

I'm not sure what you mean.  Are you concerned that the .dsc is
being built in an environment with uncontrolled other dependencies?

This is not something you need to worry about, any more than you
should worry that your kernel or filesystem aren't "hermetic".  It is
quite fine to use (for example) an older version of dpkg-source to
upload.  Indeed, that is quite normal.

All of my own uploaded .dscs are constructed by dgit using the
dpkg-source in my laptop's main environment, curerntly trixie.
Of course if I upload binaries I build them with sbuild, but with
sbuild the source package is built outside the chroot because it's
how the source is conveyed into the chroot for the build!

In any case, dgit checks that the source package correctly represents
what's in (your local) git, so if you had a malfunctioning dpkg-source
it would have to round-trip not to be detected.

If you really want reliable and auditable conversion from git to dsc,
you can of course use tag2upload, which has a clear definition of what
the tag means, and hermetic conversion from git to dsc.  It's a system
with a fairly high level of assurance by Debian's usual standards.

> > I think you probably just need to stop passing it --gbp aka
> > --quilt=gbp, which is documented as follows:
> 
> I'm not passing it --quilt=gbp.  I'm just running "dgit gbp-build".

>From the documentation in dgit(1) for dgit gbp-build:

By default this uses --quilt=gbp, so HEAD should be a
git-buildpackage style branch, not a patches-applied branch.

Admittedly "git-buildpackage style branch" is rather loose phrasing
here, but "not a patches-applied branch" is quite unambiguous.

> Hmm... will something like "dgit --quilt=nofix gbp-build" do what I
> want?  And if so, I can put something like

I should think so.

> [dgit "default"]
>   build-products-dir = /tmp/gbp
>   quilt = nofix

Yes, you can do that.  You should probably put that in your
per-package git repo, rather than your global config.  Otherwise dgit
might behave weirdly for you in the future when you work on other
packages with different approaches, or try to do an NMU.

(However, and I hesitate to go into this:

You shoudln't, because the /tmp/gbp is a "use of fixed filename in
/tmp" vulnerability!  Like most programs, dgit is not prepared to deal
with the possibly hostile bizarrenesses that can occur in /tmp, except
for files that it itself creates in /tmp or TMPDIR or such.

I suspect that your *fingers* have a "use of fixed filename in /tmp"
vulnerability.  This is OK on a machine (or VM or container) on which
all software is completely trusted, but that is rarely the situation.
So manual use of /tmp rather than (say) ~/tmp is a really bad habit.)

> in my git config file?  If so, you might want to document that in
> git-maint-gbp, and not assume that everyone using gbp is using
> patch-unapplied.  I certainly don't.  (In fact, I don't even know how
> you can use gbp with a patch-unapplied orkflow; I didn't even know
> that was a possibility, in fact.)

What yo

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Simon Josefsson]

Marc Haber  writes:

> On Thu, Feb 12, 2026 at 06:25:07PM +0100, Simon Josefsson wrote:
>>Marc Haber  writes:
>>> I THINK that we should recommend including the form that upstream
>>> publishes with their signature.
>>
>>Do you mean that generally, or more specifically 'PGP signature'?
>>
>>Many upstream now sign their releases using Sigstore, Sigsum, SSH
>>Signatures and other non-PGP formats.  I expect non-PGP to be more
>>common than PGP signatures relatively soon, if this hasn't already
>>happened (depending on what kind of upstreams you count).
>>
>>It would be nice if Debian supported more formats for verifying upstream
>>signatures.  Right now we just throw away many signatures.  Bonus points
>>for storing and publishing the non-PGP formats too.
>
> The nice thing about having the original upstream tarballs in our
> archive is that we don't have to care about that. People can verify
> that our tarballs are the same than upstream's and then check whatever
> signature upstream chose to apply.

Oh, then I think I misunderstood you.  Did you intend to recommend that
Debian do not store a copy of the upstream digital signature together
with the tarball at all?

That would solve the problem, but it will be weaker.  Upstream tarballs
and signatures disappear or are modified over time, and more often that
we like or even want to admit.  Users won't generally be able to find
and locate those upstream signature corresponding to whatever tarball
ended up in Debian.  If we store upstream tarballs, and verify their
digital signatures, I think we should also store upstream digital
signatures.  And support whatever upstream digital signature format used
(limited to widely implemented variants like PGP, SSH, Sigstore, Sigsum,
minisign, signify, ...).

/Simon


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Theodore Tso]

On Thu, Feb 12, 2026 at 05:37:26PM +, Ian Jackson wrote:
> dgit-maint-gbp(7) is describing patches-unapplied, which is the usual
> way that people use gbp (and gbp pq etc.)

I don't know why you say that --- "gbp buildpackage" works just *fine*
for me and I'm using a patches applied workflow.  In fact, that's what
I fall back to after "dgit gbp-build" fails for me.

I use gbp buildpackage because I have that set up to do a hermetic
build using sbuild and schroot.  It takes care of using pristine tar
to generate the tarball, so I don't have to rely on origtargz
downloading the tarball (which is a real drag when I'm running gbp
buildpackage while on an airplane or a cruise ship).

> > I do a git cherry pick, and then manually do a "git am -o
> > debian/patches" and then edit the resulting file to meet the DEP-3
> > standards.
> 
> Gosh.  Don't you find that tiresome?

It's annoying, but most of the time I work on an upstream first model.
Which is to say, if there are sufficient bugs that I really need to do
a debian release, I'll do an upstream release so that non-Debian
distributions can also benefit, and then I'll do a debian release.
The only exception is when we're in a release lockdown.

> BTW IMO you should stop worrying so much about DEP-3 and just use
> git-format-patch.  That's what gbp pq does - and is very common
> practice in Debian.  There was some discussion somewhere recently
> about updating DEP-3 to recommend output like git-format-patch's.

Agreed, DEP-3 is pretty pointless given that all of the metadata
information is in the git repo.  But it's also not *that* hard to
start with "git format-patch -o debian/patches", and then masssage the
output slightly.  If did it more often, I'd create script that
automated it, but as I said, modulo release freezes, I generally use
the upstream first model anyway.

>dgit build-source

Sure, but that doesn't do a hermetic build.

> I think you probably just need to stop passing it --gbp aka
> --quilt=gbp, which is documented as follows:

I'm not passing it --quilt=gbp.  I'm just running "dgit gbp-build".

Hmm... will something like "dgit --quilt=nofix gbp-build" do what I
want?  And if so, I can put something like

[dgit "default"]
build-products-dir = /tmp/gbp
quilt = nofix

in my git config file?  If so, you might want to document that in
git-maint-gbp, and not assume that everyone using gbp is using
patch-unapplied.  I certainly don't.  (In fact, I don't even know how
you can use gbp with a patch-unapplied orkflow; I didn't even know
that was a possibility, in fact.)

Cheers,

- Ted

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[intrigeri]

Hi,

Lucas Nussbaum (2026-02-12):
> I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
> https://udd.debian.org/cgi-bin/dep14stats.cgi

Thanks!

> 72.8% of packages with a working salsa project have a pristine-tar
> branch.

While the mere existence of a pristine-tar branch strongly suggests
the packaging has at least used pristine-tar at some point in history,
it does not necessary mean it *currently* uses pristine-tar.

As a data point, this week I've converted a package to a pure-Git
workflow, so it won't use the pristine-tar branch anymore. But I have
no strong incentive to delete that branch on Salsa, so I plan to leave
it alone, just in case someone may find it useful.

I doubt this makes a big difference to the results right now. But *if*
more and more packages migrate away from pristine-tar, I understand
these stats simply won't reflect this evolution, and the numbers
*might* get more and more misleading to readers who interpret these
numbers as a gauge of current popularity. Does this make sense?

If there's a good way to improve this at some point, it would be great.

In the meantime, what about making the phrasing on the webpage reflect
this reality better than the current "N packages […] use
pristine-tar", so future readers of dep14stats.cgi are better equipped
to interpret the data? For example: "use pristine-tar, or have used it
in the past".

Cheers,
-- 
intrigeri

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Lucas Nussbaum]

On 11/02/26 at 13:42 +0100, Jochen Sprickerhof wrote:
> * Sean Whitton  [2026-02-11 11:52]:
> > For example, I maintain or team half-maintain maybe 90 packages in
> > total, and none of them use pristine-tar.  So the only case where I
> > cannot use tag2upload is when I need to upload to NEW, which is not
> > often.  Therefore tag2upload is my default way to upload, because why
> > wouldn't it be, it's so smooth and easy.
> 
> My perception is rather different here:
> 
> Python Team:
> 
> "DPT requires a pristine-tar branch"
> 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> 
> Science Team:
> 
> "It is recommended to use pristine-tar"
> 
> https://science-team.pages.debian.net/policy/
> 
> Multimedia Team:
> 
> "gbp clone --pristine-tar"
> 
> https://wiki.debian.org/DebianMultimedia/DevelopPackaging
> 
> Also most of my uploads are new upstream versions.

I added some statistics about fetishism^Hpristine-tar usage (SCNR) on
https://udd.debian.org/cgi-bin/dep14stats.cgi

72.8% of packages with a working salsa project have a pristine-tar
branch.

Among salsa groups with more than 200 packages in testing, the following
have more than 80% of group-maintained packages that have a pristine-tar
branch:

  debian 3501 packages using pristine-tar (80.7% of the group's packages)
with no team policy that advocates doing it AFAIK.
  perl-team 4079 (99.5%)
  python-team 2756 (97.7%)
  js-team 1674 (98.2%) 1704
  ruby-team 1174 (99.4%) 1181
  java-team 1040 (93.4%) 1113
  r-pkg-team 957 (99.9%) 958
  med-team 915 (99.8%) 917
  science-team 773 (92.6%) 835
  games-team 472 (82.2%) 574
  multimedia-team 518 (93.5%) 554
  fonts-team 345 (81.6%) 423
  ocaml-team 390 (99.0%) 394
  gnome-team 303 (98.7%) 307
  php-team 264 (96.7%) 273
  debian-astro-team 245 (95.7%) 256
  pkg-security-team 242 (96.4%) 251
  tryton-team 224 (99.6%) 225

The other groups (< 80%) are:
  homeassistant-team 368 (73.9%) 498
  emacsen-team 206 (59.4%) 347
  go-team 1467 (57.1%) 2570
  
  qt-kde-team 35 (5.4%) 654
  openstack-team 13 (2.6%) 501
  rust-team 4 (0.1%)
  haskell-team 5 (0.5%) 978

Lucas

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Lucas Nussbaum]

On 10/02/26 at 15:50 +, Ian Jackson wrote:
> [1] I don't think the current representation in UDD
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116530#41
> is particularly good - IMO the sponsor should be in "signed_by",
> and the t2u information should be relegated to a special field,
> in accordance with UDD's usual principles of providing cooked,
> directly useable data.

I did not want to change the meaning of the signed_by* fields in UDD
since third-party scripts I'm not aware of could be using it.

The cooked data is in uploaded_by*.

Lucas

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Lucas Nussbaum]

On 12/02/26 at 21:21 +0100, Marc Haber wrote:
> On Thu, Feb 12, 2026 at 05:17:32PM +0100, Jonas Smedegaard wrote:
> > It if was problematic, then I believe we have already a lot of broken
> > packages in Debian - all those with "+ds" or "+dfsg" in the name but
> > also with "orig" near the end of the name. Those are explicitly *not*
> > bit-for-bit upstream-containerized-and-compressed originals.
> 
> Yes, there are exceptions to the rule, but it is still the majorty of
> packages that have the orig.tar.gz identical to upstream's relaease tarball.

Data about that, from https://debaudit.debian.net/orig-check/statistics

uscan fails to download the current version for 22.87% of packages.
uscan downloads an upstream tarball ...
 ... that is not identical for 4.25% of packages.
 ... that is bit-by-bit identical for 58.2%
 ... that is identical after some normalizations for 12.12%
native packages: 2%

Lucas

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Thu, Feb 12, 2026 at 05:17:32PM +0100, Jonas Smedegaard wrote:

It if was problematic, then I believe we have already a lot of broken
packages in Debian - all those with "+ds" or "+dfsg" in the name but
also with "orig" near the end of the name. Those are explicitly *not*
bit-for-bit upstream-containerized-and-compressed originals.


Yes, there are exceptions to the rule, but it is still the majorty of 
packages that have the orig.tar.gz identical to upstream's relaease 
tarball. I'd like that to stay that way.


Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Thu, Feb 12, 2026 at 06:25:07PM +0100, Simon Josefsson wrote:

Marc Haber  writes:

I THINK that we should recommend including the form that upstream
publishes with their signature.


Do you mean that generally, or more specifically 'PGP signature'?

Many upstream now sign their releases using Sigstore, Sigsum, SSH
Signatures and other non-PGP formats.  I expect non-PGP to be more
common than PGP signatures relatively soon, if this hasn't already
happened (depending on what kind of upstreams you count).

It would be nice if Debian supported more formats for verifying upstream
signatures.  Right now we just throw away many signatures.  Bonus points
for storing and publishing the non-PGP formats too.


The nice thing about having the original upstream tarballs in our 
archive is that we don't have to care about that. People can verify that 
our tarballs are the same than upstream's and then check whatever 
signature upstream chose to apply.


Greetings
Marc


--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

Nicolas Schodet writes ("Re: Bug#1127616: developers-reference: should document 
using git-debpush to upload"):
> On a separate topic, now I want to try to use dgit (and git-debrebase!),
> but I did not find how pushing to the dgit repo is done (I suppose it
> needs my ssh pubkey), maybe it’s not possible for a DM, or maybe
> git-debpush renders dgit push obsolete?

Pushing to the dgit git server is principally authorised by your PGP
signature on a git tag (made for you by dgit).  It has the same access
control as the legacy ftp archive.

But there is an additional level of defence of the service - the ssh
authorisation.  Unfortunately there is an additioal step for DMs,
because we still don't have a record of all DMs' ssh keys.

This is covered near the bottom of
  https://wiki.debian.org/DgitFAQ
You could email me your ssh public key, with your PGP signature on the
email, and I'll install it.  Or get your sponsor to make an MR against
  https://salsa.debian.org/dgit-team/extra-push-ssh-keys
(which is a private repository because it contains personal data).

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

Theodore Tso writes ("Re: Bug#1127616: developers-reference: should document 
using git-debpush to upload"):
> I *think* I am using the procedures docuimented in dgit-maint-gbp.

dgit-maint-gbp(7) is describing patches-unapplied, which is the usual
way that people use gbp (and gbp pq etc.)

Perhaps the problem is that you are passing --gbp for a
patches-applied branch?

> But it appears that gbp and patches-applied has some potential
> challenges where the safety checks trying to make sure that the
> patches that were cherry picked and the patches in debian/patches are
> consistent fail.  The problem seems to be that dgit gets confused
> about what the base commit that should be used for its git diff, and
> so it refuses to do the dgit push.

The base it is using is an import of your .orig tarball.

> > How are you keeping the upstream files in the main part of your git
> > tree in sync with the debian/patches/ ?  Typically with
> > patches-applied and "3.0 (quilt)" one needs a tool to do this
> > (git-debrebase, git-dpm, git-debcherry).
> 
> I do a git cherry pick, and then manually do a "git am -o
> debian/patches" and then edit the resulting file to meet the DEP-3
> standards.

Gosh.  Don't you find that tiresome?

> See my branches at debian/backports and debian/master at the e2fsprogs
> git tree at
> 
>https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
> or
>https://github.com/tytso/e2fsprogs.git

I cloned that and WFM.  See transcript below, but basically

  git checkout debian/master
  origtargz
  dgit build-source  

Note that I didn't pass any --quilt or --gbp option, so I'm using the
default mode of --linear.  That is for patches-applied trees which may
have had additional commits to upstream files on top, and it will make
patch files in debian/patches out of commits, and commit those patch
files in turn, if necessary.

If you're sure it's correct as-is there's --quilt=nofix which will
check that you have a consistent patches-applied branch but never make
changes.

> By the way, do you have a reference to git-debcherry?  If that's
> something that automate creating a DEP-3 complaint patch file from the
> git cherry-pick that would save me a bit of time for each patch.

dgit itself, in --quilt=linear, can do this patch file generation for
you.  dgit build-source or dgit quilt-fixup will do it, and commit the
result automatically.

I tried it with your debian/master branch, manually committing a test
change to INSTALL dgit build-source worked as I expected.  See 2nd
transcript below.

I don't use git-debcherry personally but it has a manpage:
  https://manpages.debian.org/trixie/gitpkg/git-debcherry.1.en.html

My understanding of git-debcherry is that it's kind of a more relaxed
version of dgit's --quilt=linear fixup.  dgit wants the commits to
definitely be nicely linearisable into patches.  AIUI git-debcherry
*tries* to make patches that correspond to commits but falls back to
portmanteau patches automatically, or something.  Some of dgit's quilt
modes do something similar, but perhaps not as well as git-debcherry.

It would be nice if dgit supported running git-debcherry, as a quilt
fixup mode.  That's #930881.

BTW IMO you should stop worrying so much about DEP-3 and just use
git-format-patch.  That's what gbp pq does - and is very common
practice in Debian.  There was some discussion somewhere recently
about updating DEP-3 to recommend output like git-format-patch's.

> > Can you point me to an example DEP-14 tag of an upload where you fell
> > back to dput?  Examining the state in git might enlighten me.
> 
> See the debian/backports branch.  I just use "git-buildpackage"
> followed by a dupload on that branch.

I ran
   dgit build-sourceq
and even
   dgit --damp-run push-source
on that branch and its only complaint was that the version was already
in the archive.

I added a new changelog stanza and then it complained that the thing
wasn't git fast forward from the previous upload.  That's expeccted
because you didn't do the last bookworm-backports upload with dgit.
The error message suggested --trust-changelog so passed that and then
   dgit --damp-run --trust-changelog push-source
worked.

(tag2upload uses --trust-changelog by default, for Reasons.)

> > The only thing it insists on is that your git and your .dsc
> > correspond; that's the property that enables it to be a bidirectional
> > gateway.  That's also the property that means you can look only at
> > your git and then be confident that "dgit push" will DTRT without
> > needing to examine source packages, run debdiff on dscs, etc.
> 
> That's the check which it is failing.  Since *I* can recreate the
> packages using gbp, and the b

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Simon Josefsson]

Marc Haber  writes:

> I THINK that we should recommend including the form that upstream
> publishes with their signature.

Do you mean that generally, or more specifically 'PGP signature'?

Many upstream now sign their releases using Sigstore, Sigsum, SSH
Signatures and other non-PGP formats.  I expect non-PGP to be more
common than PGP signatures relatively soon, if this hasn't already
happened (depending on what kind of upstreams you count).

It would be nice if Debian supported more formats for verifying upstream
signatures.  Right now we just throw away many signatures.  Bonus points
for storing and publishing the non-PGP formats too.

/Simon



signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Theodore Tso]

On Thu, Feb 12, 2026 at 03:11:17PM +, Ian Jackson wrote:
> 
> I'm not sure I understand your git workflow.  You say you're using
> patches-applied.  I assume that means you're using "3.0 (quilt)".
> Reading between the lines, Ithink yuu probably aren't basing your
> approach on any of the workflow recommendations in dgit-maint-*(7).
> That's fine, and dgit may well be able to work with your git branch,
> but it does mean I don't know what's going on.

I *think* I am using the procedures docuimented in dgit-maint-gbp.
But it appears that gbp and patches-applied has some potential
challenges where the safety checks trying to make sure that the
patches that were cherry picked and the patches in debian/patches are
consistent fail.  The problem seems to be that dgit gets confused
about what the base commit that should be used for its git diff, and
so it refuses to do the dgit push.

But I *know* that it's consistent, and it's at that point that I say,
f*ck dgit, and just do a manual upload.

> How are you keeping the upstream files in the main part of your git
> tree in sync with the debian/patches/ ?  Typically with
> patches-applied and "3.0 (quilt)" one needs a tool to do this
> (git-debrebase, git-dpm, git-debcherry).

I do a git cherry pick, and then manually do a "git am -o
debian/patches" and then edit the resulting file to meet the DEP-3
standards.

See my branches at debian/backports and debian/master at the e2fsprogs
git tree at

   https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
or
   https://github.com/tytso/e2fsprogs.git

By the way, do you have a reference to git-debcherry?  If that's
something that automate creating a DEP-3 complaint patch file from the
git cherry-pick that would save me a bit of time for each patch.

> Certainly I think cherry-picking a patch from upstream, or writing a
> fresh patch on an interim basis, is a routine operation that ought to
> be straightforward.

Agreed.

> Can you point me to an example DEP-14 tag of an upload where you fell
> back to dput?  Examining the state in git might enlighten me.

See the debian/backports branch.  I just use "git-buildpackage"
followed by a dupload on that branch.

> The only thing it insists on is that your git and your .dsc
> correspond; that's the property that enables it to be a bidirectional
> gateway.  That's also the property that means you can look only at
> your git and then be confident that "dgit push" will DTRT without
> needing to examine source packages, run debdiff on dscs, etc.

That's the check which it is failing.  Since *I* can recreate the
packages using gbp, and the branch that I use is published on
git.kernel.org and github.com, whether or not dgit thinks it's
possible isn't worth my trying to figure out how to make dgit
happy.

- Ted

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Holger Levsen [12/Feb  3:01pm GMT] wrote:
> On Thu, Feb 12, 2026 at 02:15:39PM +, Holger Levsen wrote:
>> On Thu, Feb 12, 2026 at 12:16:54PM +, Sean Whitton wrote:
>> > How's this, then:
>> >
>> > --8<---cut here---start->8---
> [...]
>> > --8<---cut here---end--->8---
>> looks great to me, thanks! (feel free to commit this directly to the main 
>> branch,
>> obviously an MR is fine as well and I'd also be happy to massage this into 
>> git for you,
>> if you'd prefer that)
>
> I wanted to move on, so I've merged this under your name and will soon
> upload dev-ref to unstable with that change. Thanks, Sean.
>
> Happy to do another upload with more changes anytime. I have good tooling \o/

Great, thank you!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: security-uploads & tooling (Re: Bug#1127616: developers-reference: should document using git-debpush to upload)

[Jonas Smedegaard]

Quoting Holger Levsen (2026-02-12 15:35:29)
> On Wed, Feb 11, 2026 at 01:59:10PM +0100, Simon Josefsson wrote:
> > All the things on the "Not supported" ways can be considered bugs
> > elsewhere -- thus I think the title of that section could be changed to
> > "Design limitations" or similar instead.
> > 
> > Analyzing them in turn:
> 
> I disagree with too many of your conclusions to reply to most of them, so 
> I will just pick one:
>  
> > > Uploads to security-master. This is difficult: 862105.
> > TBH I have no idea about this one, but I suspect the security-master
> > upload workflow isn't particular modern.
> 
> lol. of course it must be not modern, lol, there cannot be any other 
> explaination.

Please stop mocking: You are laughing at others' expense, not with them!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Jonas Smedegaard]

Quoting Marc Haber (2026-02-12 15:32:20)
> On Thu, Feb 12, 2026 at 01:28:29PM +0100, Jonas Smedegaard wrote:
> >Quoting Marc Haber (2026-02-12 12:35:15)
> >> If using the signed git tag would result in a different orig.tar.gz in
> >> our archive then we SHOULD be sad (or improve our tools) and in the
> >> mean time use their release tarball (while optionally keeping upstream
> >> git history in our git).
> >
> >I agree with the other cases (and thanks to spelling them all out
> >explicitly!), but I don't understand the above one.
> >
> >Why SHOULD we we sad if upstream offers two formats and we pick one of
> >them without being able to recreate the other from it?
> 
> Because we would then have an orig.tar.gz in our archive that isn't 
> that original. I would be less unhappy if our archive would then use a 
> different name such as synth.tar.gz or debian-upstream.tar.gz, but I 
> think that hell would need to freeze over for that to happen.

Ah, I think I now understand what you are getting at: Debian SHOULD
only include "orig" to the naming of a compressed tarball when it
originates upstream *in that container and compression formats*.

I don't find that problematic: The "orig" naming is not (that I am
aware) documented anywhere as being a promise about bit-for-bit
accuracy after containerization and compression. As I see it, our
naming scheme is merely a convention that can reasonably be extended to
cover tree-same originating upstream - i.e. original _content_ but not
necessarily orginal containerization nor compression.

It if was problematic, then I believe we have already a lot of broken
packages in Debian - all those with "+ds" or "+dfsg" in the name but
also with "orig" near the end of the name. Those are explicitly *not*
bit-for-bit upstream-containerized-and-compressed originals.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Jeremy Stanley]

On 2026-02-12 10:40:20 +0100 (+0100), Johannes Schauer Marin Rodrigues wrote:
[...]
I am upstream of some Python modules and have a bad feeling about 
using pypi since I got this email from them in October 2023:



Subject: [PyPI] Unsupported GPG signature uploaded to PyPI

[...]
I have a bad feeling about a service which actively removed 
support for attaching a cryptographic signature to my upload. I 
have since dropped pypi as the source of my Debian Python packages 
and use my upstream git repo with signed tags instead.


Upstream in a lot of the Python-based projects I work on, when the 
writing was on the wall that PyPI (Cheeseshop and later Warehouse) 
maintainers considered artifact signatures useless and made noises 
about removing support for them in the future, we started publishing 
signatures for our sdist (source tarball) and wheel (binary) 
packages on a separate web site so that users and downstream 
distribution package maintainers could still verify the provenance 
of files retrieved from there or from PyPI. I know a lot of smaller 
projects can't afford to do that, but it served as a suitable 
compromise for us at least.

--
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

(I'm dropping the dev-ref bug because this seems like a dgit user
support subthread now.)

Theodore Tso writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):
> On Tue, Feb 10, 2026 at 09:32:29AM -0800, Russ Allbery wrote:
> > I have been using dgit with pristine-tar for years. It works fine with
> > pristine-tar. People have told you this repeatedly. Please listen to us
> > and stop repeating this blatantly misleading statement in every discussion
> > about dgit.
> 
> I use dgit with pristine-tar, but if I need to add patches in between
> formal e2fsprogs releases, dgit is *painful*.  If I need to upload to
> stable backports, dgit just did't work.  Ian, I think I e-mailed you a
> request for help a few years ago, but you were apparently to busy to
> reply, so I just gave up on it for stable backports.  And if I can't
> get maintenance releases doesn't work, I just fall back to the
> pre-dgit workflow.
> 
> Part of this is because my workflow uses dgit plus gbp plus schroots,
> with patches applied.  Which is something dgit seems to only
> incidently support, but the advantage of my setup is that if dgit does
> blow up, and I can easily fall back to a pre-dgit workflow.

I'm sorry that I apparently overlooked your earlier mail.  Anyway:

We do stable backports with dgit all the time.  This is supposed to e
fully supported.  Indeed that's how the current dgit in trixie-bpo got
there.[1] If you're having trouble with this I'd welcome a bug report
(which would be less easy to overlook).


As for adding patches between (upstream?) e2fsprogs releases,
again, this ought to be routine and supported.  But:

I'm not sure I understand your git workflow.  You say you're using
patches-applied.  I assume that means you're using "3.0 (quilt)".
Reading between the lines, Ithink yuu probably aren't basing your
approach on any of the workflow recommendations in dgit-maint-*(7).
That's fine, and dgit may well be able to work with your git branch,
but it does mean I don't know what's going on.

How are you keeping the upstream files in the main part of your git
tree in sync with the debian/patches/ ?  Typically with
patches-applied and "3.0 (quilt)" one needs a tool to do this
(git-debrebase, git-dpm, git-debcherry).

Certainly I think cherry-picking a patch from upstream, or writing a
fresh patch on an interim basis, is a routine operation that ought to
be straightforward.

Can you point me to an example DEP-14 tag of an upload where you fell
back to dput?  Examining the state in git might enlighten me.


I don't see how any of this would have anything to do with
pristine-tar.

> Maybe it's possible to make dgit work with my workflow, but I've spent
> weekends trying to make it work, and I've since timed out.  I have
> higher-value work that I can do to support Linux or Debian, and trying
> to bash my head against the dgit procrustean bed isn't one of them.

Well, obviously I'm sorry you feel that way.  dgit is supposed to be
quite flexible.

The only thing it insists on is that your git and your .dsc
correspond; that's the property that enables it to be a bidirectional
gateway.  That's also the property that means you can look only at
your git and then be confident that "dgit push" will DTRT without
needing to examine source packages, run debdiff on dscs, etc.

Regards,
Ian.

[1] Well actually Sean did it and I think he used tag2upload, but
that's dgit-as-a-service.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Holger Levsen]

On Thu, Feb 12, 2026 at 02:15:39PM +, Holger Levsen wrote:
> On Thu, Feb 12, 2026 at 12:16:54PM +, Sean Whitton wrote:
> > How's this, then:
> > 
> > --8<---cut here---start->8---
[...]
> > --8<---cut here---end--->8---
> looks great to me, thanks! (feel free to commit this directly to the main 
> branch,
> obviously an MR is fine as well and I'd also be happy to massage this into 
> git for you, 
> if you'd prefer that)

I wanted to move on, so I've merged this under your name and will soon
upload dev-ref to unstable with that change. Thanks, Sean.

Happy to do another upload with more changes anytime. I have good tooling \o/


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

How long until the collective penny drops that we sacrificed our health future
for a past that isn't coming back? May policy makers be held to account in
future. (@CdrHBiscuitIII)


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Colin Watson]

On Thu, Feb 12, 2026 at 09:40:25AM -0500, Theodore Tso wrote:

On Tue, Feb 10, 2026 at 09:32:29AM -0800, Russ Allbery wrote:

I have been using dgit with pristine-tar for years. It works fine with
pristine-tar. People have told you this repeatedly. Please listen to us
and stop repeating this blatantly misleading statement in every discussion
about dgit.


I use dgit with pristine-tar, but if I need to add patches in between
formal e2fsprogs releases, dgit is *painful*.  If I need to upload to
stable backports, dgit just did't work.


I hear you that you found it difficult to get to work, but I literally 
do these things every day that I'm working on Debian (well OK, I don't 
upload to stable backports every day, but I have done it with dgit and 
it was fine).  To me, dgit is basically orthogonal to applying patches 
in between formal upstream releases anyway; I do that sort of thing with 
other tools such as "gbp pq", and dgit is just the way that I get them 
into the archive.


If you've given up then I understand, but if you want to have another go 
then feel free to email me (off-list) for help getting it working.



Part of this is because my workflow uses dgit plus gbp plus schroots,
with patches applied.  Which is something dgit seems to only
incidently support, but the advantage of my setup is that if dgit does
blow up, and I can easily fall back to a pre-dgit workflow.


I think dgit intentionally supports all those things, not incidentally.  


--
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Theodore Tso]

On Tue, Feb 10, 2026 at 09:32:29AM -0800, Russ Allbery wrote:
> Otto Kekäläinen  writes:
> 
> > The tag2upload service is tightly coupled with dgit, and while dgit by
> > design will never support pristine-tar type of ability to reproduce
> > upstream tarballs bit-for-bit, it should at least have the actual
> > upstream signed tags instead (from upstreams that publish them).
> 
> I have been using dgit with pristine-tar for years. It works fine with
> pristine-tar. People have told you this repeatedly. Please listen to us
> and stop repeating this blatantly misleading statement in every discussion
> about dgit.

I use dgit with pristine-tar, but if I need to add patches in between
formal e2fsprogs releases, dgit is *painful*.  If I need to upload to
stable backports, dgit just did't work.  Ian, I think I e-mailed you a
request for help a few years ago, but you were apparently to busy to
reply, so I just gave up on it for stable backports.  And if I can't
get maintenance releases doesn't work, I just fall back to the
pre-dgit workflow.

Part of this is because my workflow uses dgit plus gbp plus schroots,
with patches applied.  Which is something dgit seems to only
incidently support, but the advantage of my setup is that if dgit does
blow up, and I can easily fall back to a pre-dgit workflow.

Maybe it's possible to make dgit work with my workflow, but I've spent
weekends trying to make it work, and I've since timed out.  I have
higher-value work that I can do to support Linux or Debian, and trying
to bash my head against the dgit procrustean bed isn't one of them.

Cheers,

- Ted

security-uploads & tooling (Re: Bug#1127616: developers-reference: should document using git-debpush to upload)

[Holger Levsen]

On Wed, Feb 11, 2026 at 01:59:10PM +0100, Simon Josefsson wrote:
> All the things on the "Not supported" ways can be considered bugs
> elsewhere -- thus I think the title of that section could be changed to
> "Design limitations" or similar instead.
> 
> Analyzing them in turn:

I disagree with too many of your conclusions to reply to most of them, so 
I will just pick one:
 
> > Uploads to security-master. This is difficult: 862105.
> TBH I have no idea about this one, but I suspect the security-master
> upload workflow isn't particular modern.

lol. of course it must be not modern, lol, there cannot be any other 
explaination.

more seriously, the only difference between normal uploads and uploads
to security master is the upload host. thats really all.

and the fact that some modern tools cannot deal with that. also lol.

obviously, we need to be able to do security uploads, so to me personally
tools which cannot do that, are really less interesting.


-- 
cheers,
Holger, starting to become annoyed by all the cool aid we need to drink
or get called legacy, ancient, crap.

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Cholera is over. It's safe to put sewage in our drinking water again.
(@stimmyskye)


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Thu, Feb 12, 2026 at 01:28:29PM +0100, Jonas Smedegaard wrote:

Quoting Marc Haber (2026-02-12 12:35:15)

If using the signed git tag would result in a different orig.tar.gz in
our archive then we SHOULD be sad (or improve our tools) and in the
mean time use their release tarball (while optionally keeping upstream
git history in our git).


I agree with the other cases (and thanks to spelling them all out
explicitly!), but I don't understand the above one.

Why SHOULD we we sad if upstream offers two formats and we pick one of
them without being able to recreate the other from it?


Because we would then have an orig.tar.gz in our archive that isn't 
that original. I would be less unhappy if our archive would then use a 
different name such as synth.tar.gz or debian-upstream.tar.gz, but I 
think that hell would need to freeze over for that to happen.


Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Holger Levsen]

On Thu, Feb 12, 2026 at 12:16:54PM +, Sean Whitton wrote:
> How's this, then:
> 
> --8<---cut here---start->8---
> diff --git a/source/pkgs.rst b/source/pkgs.rst
> index 41d0147..02a7696 100644
> --- a/source/pkgs.rst
> +++ b/source/pkgs.rst
> @@ -359,7 +359,13 @@ All of the corresponding architecture-dependent and 
> architecture-independent
>  binary packages, for all architectures, will be built automatically by
>  the build daemons in a controlled and predictable environment
>  (see :ref:`wanna-build` for more details).
> -However, there are several situations where this is not possible.
> +
> +For many source-only uploads you can use tag2upload instead, which means that
> +you only need to push a signed Git tag to Salsa, instead of generating and
> +signing ``.dsc`` and ``.changes`` files yourself.
> +See https://wiki.debian.org/tag2upload\ .
> +
> +There are several situations where a source-only upload is not possible.
> 
>  The first upload of a new source package (see :ref:`newpackage`)
>  must include binary packages, so that they can be reviewed by the
> --8<---cut here---end--->8---

looks great to me, thanks! (feel free to commit this directly to the main 
branch,
obviously an MR is fine as well and I'd also be happy to massage this into git 
for you, 
if you'd prefer that)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The empty vessel makes the greatest sound. (William Shakespeare)


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Timo Röhling]

* Sean Whitton  [2026-02-12 12:00]:

Back when I worked NEW: I very often wanted to see the list of files
installed by the package, and the full, expanded list of binary package
relationships.  Rarely, I would actually look inside the .deb.

These are real needs for NEW review.
From personal experience, both as sponsor and packager, I'd like to add 
that these are things that you can easily get wrong by accident, so I'm 
very much in favor of these sanity checks for NEW.



I think one source of opposition for autobuilding packages before they
go into NEW is that the DFSG team won't yet has asserted/confirmed that
the license permits autobuilding.  But, well, we already have Salsa CI,
so I think that is not worth blocking on.
I sometimes upload a new package together with one or more new 
dependencies, which means it might not be immediately autobuildable from 
the archive alone. Certainly not an unsolvable problem, but it shows 
that there are edge cases to be considered.



Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Jonas Smedegaard]

Quoting Marc Haber (2026-02-12 12:35:15)
> On Thu, Feb 12, 2026 at 10:25:17AM +, Ian Jackson wrote:
> >On the question of upstream tarballs vs upstream git, devref
> >definitely needs to mention both approaches.  I'm firmly of the
> >opinion that upstream git should be the preferred recommendation.
> 
> I THINK that we should recommend including the form that upstream 
> publishes with their signature.
[...]
> If they publish both and their contents are identical, then we SHOULD 
> use the signed git tag if this makes it possible to have the 
> .orig.tar.gz in our archive to have the same checksum than the upstream 
> tarball.
>
> If using the signed git tag would result in a different orig.tar.gz in 
> our archive then we SHOULD be sad (or improve our tools) and in the 
> mean time use their release tarball (while optionally keeping upstream 
> git history in our git).

I agree with the other cases (and thanks to spelling them all out
explicitly!), but I don't understand the above one.

Why SHOULD we we sad if upstream offers two formats and we pick one of
them without being able to recreate the other from it?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Holger Levsen [11/Feb 12:15pm GMT] wrote:
> yes, its not experimental since a week. Hardly mature enough to be recommended
> for *everyone* (as your patch did) which youself have documented on
> https://wiki.debian.org/tag2upload#Not%20supported
>
> btw, I'd expect this URL (until the hash sign probably :) to be included
> in src:devref! (this URL or another which is the canonical documentation
> for tag2upload.)

How's this, then:

--8<---cut here---start->8---
diff --git a/source/pkgs.rst b/source/pkgs.rst
index 41d0147..02a7696 100644
--- a/source/pkgs.rst
+++ b/source/pkgs.rst
@@ -359,7 +359,13 @@ All of the corresponding architecture-dependent and 
architecture-independent
 binary packages, for all architectures, will be built automatically by
 the build daemons in a controlled and predictable environment
 (see :ref:`wanna-build` for more details).
-However, there are several situations where this is not possible.
+
+For many source-only uploads you can use tag2upload instead, which means that
+you only need to push a signed Git tag to Salsa, instead of generating and
+signing ``.dsc`` and ``.changes`` files yourself.
+See https://wiki.debian.org/tag2upload\ .
+
+There are several situations where a source-only upload is not possible.

 The first upload of a new source package (see :ref:`newpackage`)
 must include binary packages, so that they can be reviewed by the
--8<---cut here---end--->8---

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

Sean Whitton writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):
> Back when I worked NEW: I very often wanted to see the list of files
> installed by the package, and the full, expanded list of binary package
> relationships.  Rarely, I would actually look inside the .deb.
> 
> These are real needs for NEW review.

Right.

> I think one source of opposition for autobuilding packages before they
> go into NEW is that the DFSG team won't yet has asserted/confirmed that
> the license permits autobuilding.  But, well, we already have Salsa CI,
> so I think that is not worth blocking on.

Indeed.

I don't know much about how the autobuilding system works but I would
love it if someone who did understand that would figure out how to
make this work.

If this is hard to organise with dak etc., one option would be a
dedicated git-based autobuilder attached to the tag2upload service.
That would somewhat be less useful to Debian as a whole, though,
because it would enable source-only NEW uploads only via tag2upload.

Having said that, it is tag2upload where the difference is *most*
stark between (a) performing a source-only operation on the uploader's
machine and (b) the uploader building binaries.  So such a
tag2upload-only solution would be worthwhile if we cann't have a
general solution.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Nicolas Schodet [11/Feb 10:24pm +01] wrote:
> I think many of us needs to understand how the system works under the
> hood to trust it.
>
> The best explanation I found was in the sevice design document[1]. I
> have the feeling that at least the overall structure and dataflow could
> be added to the manual page.
>
> Before reading this doc, I had questions about how the package was
> uploaded. Do I need ssh access somewhere? Do I need to push to a special
> repository? How is it related to dgit?
>
> As a DM, I was also wondering whether I had the right access to use it
> (it’s clear now, I only need push access to salsa).

You found the document that would satisfy what you wanted to know,
TAG2UPLOAD-DESIGN.txt.  We could consider adding a reference to that to
the bottom of the manpage.

We are keen that git-debpush(1) remains short and sweet.  Not mentioning
dgit is important because many people would find that off-putting.

> On a separate topic, now I want to try to use dgit (and git-debrebase!),
> but I did not find how pushing to the dgit repo is done (I suppose it
> needs my ssh pubkey), maybe it’s not possible for a DM, or maybe
> git-debpush renders dgit push obsolete?

dgit pushes aren't obsolete because you need them to do source+binary
uploads to NEW.

As a DM, in order to use dgit (but not tag2upload), you need your key
adding to a certain keyring.
Send it in a signed message to dgit-ow...@debian.org.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: large files in git and Debian (Re: Bug#1127616: developers-reference: should document using git-debpush to upload)

[Sean Whitton]

Holger Levsen [12/Feb 11:29am GMT] wrote:
> dropping 23 people from cc: and the devref bug too...
>
> On Thu, Feb 12, 2026 at 10:53:37AM +, Ian Jackson wrote:
>> PICCA Frederic-Emmanuel writes ("Bug#1127616: developers-reference: should
>> document using git-debpush to upload"):
>> > Do we have a solution in order to deal with big files in the git history
>> > on salsa or dgit ?
>> > I think about science data set used for unit test programmes, 3D model,
>> > games assets etc...
>> With Salsa you can use git-annex or git-lfs.  Neither of those are
>> supported by dgit or tag2upload.  So, the short answer is "not
>> really, at the moment".
>
> that's true for dgit (and tag2upload) but Fred asked "on salsa *or* dgit",
> and surely it's possible with salsa and (git-annex or git-lfs) and well
> established upload tools like (dput, dput-ng or dupload).
>
> so yes, dealing with big files in git is entirely possible with Debian's
> tools. just not with some, uhem, newer ones.

(Fred has been using dgit for everything he can for maybe ten years, so
that's probably why Ian responded with the focus he did.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Simon Josefsson [11/Feb  9:50pm +01] wrote:
>> > NEW uploads should be permitted to be source-only.
>>
>> This would be a significant improvement.  I think binaries needed for
>> review by the DFSG team should be autobuilt.
>
> DFSG Team: do you look at maintainer-uploaded binaries?  Why?
>
> They could be autobuilt, but I wonder what the real purpose of that is.
> Only to prove that the source code actually builds against build
> dependencies in Debian?  That would indeed be a good test.  But
> binaries aren't needed for that, just a build log from a trusted
> builder.

Back when I worked NEW: I very often wanted to see the list of files
installed by the package, and the full, expanded list of binary package
relationships.  Rarely, I would actually look inside the .deb.

These are real needs for NEW review.

I think one source of opposition for autobuilding packages before they
go into NEW is that the DFSG team won't yet has asserted/confirmed that
the license permits autobuilding.  But, well, we already have Salsa CI,
so I think that is not worth blocking on.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Johannes Schauer Marin Rodrigues]

Quoting Simon Josefsson (2026-02-11 21:50:42)
> > > NEW uploads should be permitted to be source-only.
> > 
> > This would be a significant improvement.  I think binaries needed for
> > review by the DFSG team should be autobuilt.
> 
> DFSG Team: do you look at maintainer-uploaded binaries?  Why?
> 
> They could be autobuilt, but I wonder what the real purpose of that is.
> Only to prove that the source code actually builds against build
> dependencies in Debian?  That would indeed be a good test.  But
> binaries aren't needed for that, just a build log from a trusted builder.

Idea: Compare the binary artifact hashes of the .buildinfo (which got uploaded
along with the source-only upload) against what got autobuilt to ensure that
what was intended to be put into the archive by the developer is indeed
bit-by-bit identical to what the autobuilders produce from the uploaded source.
:)

signature.asc
Description: signature

RE: large files in git and Debian (Re: Bug#1127616: developers-reference: should document using git-debpush to upload)

[PICCA Frederic-Emmanuel]

> that's true for dgit (and tag2upload) but Fred asked "on salsa *or* dgit",
> and surely it's possible with salsa and (git-annex or git-lfs) and well
> established upload tools like (dput, dput-ng or dupload).

My point is how do I know which file need to go  into git-annex or git-lfs when 
I just do a
Gbp import-orig --uscan or in my case

Gbp import-orig 

I do not know if this is an hypothetical case, but for now I use the 
autopkgtest and internet connection in order to download these big files during 
the tests.

I am not that happy with the fact that these test files are not  on the Debian 
infra...

> so yes, dealing with big files in git is entirely possible with Debian's
> tools. just not with some, uhem, newer ones.

What is considere a big file in the git world ?

Fred

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Sean Whitton]

Jochen Sprickerhof [11/Feb  1:42pm +01] wrote:
> * Sean Whitton  [2026-02-11 11:52]:
>>For example, I maintain or team half-maintain maybe 90 packages in
>>total, and none of them use pristine-tar.  So the only case where I
>>cannot use tag2upload is when I need to upload to NEW, which is not
>>often.  Therefore tag2upload is my default way to upload, because why
>>wouldn't it be, it's so smooth and easy.
>
> My perception is rather different here:
>
> Python Team:
>
> "DPT requires a pristine-tar branch"
>
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>
> Science Team:
>
> "It is recommended to use pristine-tar"
>
> https://science-team.pages.debian.net/policy/
>
> Multimedia Team:
>
> "gbp clone --pristine-tar"
>
> https://wiki.debian.org/DebianMultimedia/DevelopPackaging
>
> Also most of my uploads are new upstream versions.
>
> So maybe a good first step would be to reduce the pristine-tar usage in
> Debian.

Likewise thanks for the references, here.  That's more than I thought.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ansgar 🙀]

On Thu, 2026-02-12 at 10:35 +, PICCA Frederic-Emmanuel wrote:
> > But Colin's catalogue of situations where that doesn't work well is
> > not unexpected!  It shows why this must be a *recommendation* that
> > a
> > package, or a whole team, might reasonably choose to diverge from.
> 
> Do we have a solution in order to deal with big files in the git
> history on salsa or dgit ?
> 
> I think about science data set used for unit test programmes, 3D
> model, games assets etc...

Yes. Git LFS should work in
Salsa: https://docs.gitlab.com/topics/git/lfs/

Ansgar

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Thu, Feb 12, 2026 at 10:25:17AM +, Ian Jackson wrote:

Obviously, there are necessary points of standardisation, so that we
(and our computers) can all work together - and in particular so that
people can work on unfamiliar packages.  These currently include the
BTS, and the archive, and since 2013 they also include *.dgit.d.o.


Thankfully you can still be an uploding DD without having understood 
dgit. I hope this stays like this until somebody has written 
documentation that a mortal can comprehend.



On the question of upstream tarballs vs upstream git, devref
definitely needs to mention both approaches.  I'm firmly of the
opinion that upstream git should be the preferred recommendation.


I THINK that we should recommend including the form that upstream 
publishes with their signature.


If they publish only signed tarballs, then we SHOULD use these.

If they publish only signed git tags, then we SHOULD use those.

If they publish both and their contents are identical, then we SHOULD 
use the signed git tag if this makes it possible to have the 
.orig.tar.gz in our archive to have the same checksum than the upstream 
tarball.


If using the signed git tag would result in a different orig.tar.gz in 
our archive then we SHOULD be sad (or improve our tools) and in the 
mean time use their release tarball (while optionally keeping upstream 
git history in our git).


If upstream publishes both signed tarballs and a signed release tag with 
different contents, then we're stuck between a rock and a hard place. I 
THINK then we should use the tarball to have the identical tarball in 
the archive, and work on our tools to allow upstream git history in our 
git.


SHOULD in capitals is the RFC2119 SHOULD, a lower case should a language 
should.


"upstram git history in our git" means that upstream commits are visible 
in git log on debian/latest.


Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

large files in git and Debian (Re: Bug#1127616: developers-reference: should document using git-debpush to upload)

[Holger Levsen]

dropping 23 people from cc: and the devref bug too...

On Thu, Feb 12, 2026 at 10:53:37AM +, Ian Jackson wrote:
> PICCA Frederic-Emmanuel writes ("Bug#1127616: developers-reference: should 
> document using git-debpush to upload"):
> > Do we have a solution in order to deal with big files in the git history on 
> > salsa or dgit ?
> > I think about science data set used for unit test programmes, 3D model, 
> > games assets etc...
> With Salsa you can use git-annex or git-lfs.  Neither of those are
> supported by dgit or tag2upload.  So, the short answer is "not
> really, at the moment".

that's true for dgit (and tag2upload) but Fred asked "on salsa *or* dgit",
and surely it's possible with salsa and (git-annex or git-lfs) and well
established upload tools like (dput, dput-ng or dupload). 

so yes, dealing with big files in git is entirely possible with Debian's
tools. just not with some, uhem, newer ones.


-- 
cheers,
Holger, fighting for the establishment since 1995

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bin mir manchmal nicht ganz sicher, was mehr triggert, Impfen oder Gendern.
Um ganz sicher zu gehen, empfehle ich beides. (@drluebbers)


signature.asc
Description: PGP signature

RE: Bug#1127616: developers-reference: should document using git-debpush to upload

[PICCA Frederic-Emmanuel]

> But Colin's catalogue of situations where that doesn't work well is
> not unexpected!  It shows why this must be a *recommendation* that a
> package, or a whole team, might reasonably choose to diverge from.

Do we have a solution in order to deal with big files in the git history on 
salsa or dgit ?

I think about science data set used for unit test programmes, 3D model, games 
assets etc...

Fred

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

PICCA Frederic-Emmanuel writes ("Bug#1127616: developers-reference: should 
document using git-debpush to upload"):
> Do we have a solution in order to deal with big files in the git history on 
> salsa or dgit ?
> 
> I think about science data set used for unit test programmes, 3D model, games 
> assets etc...

With Salsa you can use git-annex or git-lfs.  Neither of those are
supported by dgit or tag2upload.  So, the short answer is "not
really, at the moment".

I think it would make sense for dgit/tag2upload to support git-annex
but that would obviously involve setting up a separate large blob
store.  It's not near the top of my todo list, but (as ever) if this
is in someone's way, help for improvement would be very welcome.

How big a problem the lack of this support is depends on how big the
files are, and how often they change.  (Some of your examples sound
like they might sometimes not be the preferred form for modification,
so in those cases it might be better to omit them.)

So this does mean that there are indeed probably some packages where
dgit (and tag2upload) aren't suitable.  So far I haven't had anyone
tell me about such a package, but it's quite likely that the
maintainer would simply not attempt to put it in git and we (dgit
team) wouldn't hear about it.  You might be surprised, though, at how
well git copes with medium-sized blob-like files; and very large files
can pose problems for the tarball-based legacy archive, too.

As so often, case-by-case decisions are called for.  That's our bread
and butter in Debian: making judgements on how best to match whatever
upstream does, and the shape of the specific software, to the needs of
a more-or-less integrated operating system.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

Colin Watson writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):
> So sure, the situation is not ideal.  But it might be worth walking a 
> mile in our shoes first.

In Debian we sometimes have an unfortunate habit of trying to insist
that every maintainer must do things our way.

Obviously, there are necessary points of standardisation, so that we
(and our computers) can all work together - and in particular so that
people can work on unfamiliar packages.  These currently include the
BTS, and the archive, and since 2013 they also include *.dgit.d.o.

But the tasks we have set ourselves are vast and diverse.  The people
doing those tasks often have good reasons for divergence.

For this reason I think it's quite important that:

 1. We make good recommendations that are usually applicable.
(This applies both in formal documents like devref, and in
less official contexts like this mailing list discussion.)

 2. But these must be *recommendations*, not mandates.

 3. We should be very slow to use tools like MBFs, linter warnings,
and NMUs, to try to get everyone to adopt our recommendations.

On the question of upstream tarballs vs upstream git, devref
definitely needs to mention both approaches.  I'm firmly of the
opinion that upstream git should be the preferred recommendation.

But Colin's catalogue of situations where that doesn't work well is
not unexpected!  It shows why this must be a *recommendation* that a
package, or a whole team, might reasonably choose to diverge from.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Simon Josefsson (2026-02-11 20:52:04)
> Jochen Sprickerhof  writes:
> 
> > Python Team:
> >
> > "DPT requires a pristine-tar branch"
> >
> > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> 
> The Python Team's Policy insistance on use of pristine-tar and throwing
> away upstream git history is [1]:
> 
>DPT requires a pristine-tar branch, and only upstream tarballs can be
>used to advance the upstream branch. Complete upstream Git history
>should be avoided in the upstream branch.
> 
> The pypi.debian.net man-in-the-middle upstream tarball redirector is the
> recommended (?) debian/watch URL to use for Python packages [2].
> 
> I find this combination really odd.  It is a great setup to enable
> xz-style attacks: (several) trusted indirections and lack of audit-chain
> between the source code consumed by Debian and the source code from the
> upstream maintainer git repository.
> 
> Debian is using Python sources from pypi.debian.net, which may or may
> not be the actual pypi.org tarball, which may or may not be the source code
> coming from each upstream's actual source repository.

I am upstream of some Python modules and have a bad feeling about using pypi
since I got this email from them in October 2023:

> Subject: [PyPI] Unsupported GPG signature uploaded to PyPI
> 
> # What?
> During your recent upload of img2pdf to PyPI, we noticed you uploaded a GPG 
> signature. However, support for GPG signatures has been removed from PyPI.
> # What should I do?
> While uploads will continue to work, any signatures uploaded to PyPI will be 
> discarded. It is recommended to no longer upload signatures to PyPI.
> 

I have a bad feeling about a service which actively removed support for
attaching a cryptographic signature to my upload. I have since dropped pypi as
the source of my Debian Python packages and use my upstream git repo with
signed tags instead.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Colin Watson]

On Wed, Feb 11, 2026 at 08:52:04PM +0100, Simon Josefsson wrote:

The Python Team's Policy insistance on use of pristine-tar and throwing
away upstream git history is [1]:

  DPT requires a pristine-tar branch, and only upstream tarballs can be
  used to advance the upstream branch. Complete upstream Git history
  should be avoided in the upstream branch.


Well, for my own packages I insist on including upstream git history, so 
this certainly wasn't my choice, and it was before my time on the DPT.  
However, I suspect that it was a pragmatic choice to make it even 
slightly practical to maintain several thousand source packages in a 
more or less uniform structure despite the upstreams using a pretty wide 
variety of code hosting mechanisms and practices.  IIRC there are still 
quite a few packages that use something other than git or that have no 
public git repository, and there are definitely plenty where the 
upstream maintainer seems to pay more attention to what's on PyPI than 
what they've tagged in git (e.g. they don't bother to push tags).  The 
big popular packages usually work the way you'd expect, but there is a 
significant long tail.


We already have an almost impossible amount of work to do just keeping 
up with ecosystem-wide changes (sure, there's been nothing even remotely 
on the scale of the Python 3 transition for a long time, but small 
probabilities of being affected by any given breaking change multiplied 
by thousands of packages still mount up quickly).  Despite understanding 
the downsides of the current team policy, I for one have absolutely no 
appetite or capacity for yet another thing that requires us to go around 
and reorganize everything.  dgit/tag2upload doesn't require us to do 
that; it can slot into our existing workflows, and not all team members 
even have to agree.



The pypi.debian.net man-in-the-middle upstream tarball redirector is the
recommended (?) debian/watch URL to use for Python packages [2].


We've been gradually moving away from this in some cases in favour of 
pointing to forge-generated tarballs, but it varies somewhat.  There is 
no one approach that works for all Python packages:


 * Source distributions ("sdists") pushed to PyPI are technically a 
   build product of the upstream source tree, and sometimes they don't 
   include all the files we need - for example, omitting tests is fairly 
   common, as is trying to include tests but omitting some of the data 
   files they need.  And some upstreams only publish wheels to PyPI and 
   not sdists.


 * On the other hand, it's also fairly common to run into packages where 
   upstream uses something like submodules, and so the forge-generated 
   tarballs will be incomplete and basically useless.  So will pointing 
   directly to upstream git tags unless you mess about with multiple 
   components.  In those cases the sdists on PyPI usually work fine and 
   are much less hassle.


So sure, the situation is not ideal.  But it might be worth walking a 
mile in our shoes first.


--
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Nicolas Schodet]

Hi,

* Ian Jackson  [2026-02-11 18:13]:
> > >I am especially concerned about this action flipping some switches
> > >either in my repository or in the archive that might prevent me
> > >from switching back to the classical workflow in the case I don't
> > >like the result.
> > Come on, it's just a tag: to see what happens you can run "git
> > debpush --tag-only" and then check that the repository has not been
> > maimed.
> > And if you want to rollback then you can just delete the tag.
> Well, that argument doesn't prove that the tag2upload system wouldn't
> act on that tag in a way that would "flip some switches" which would
> somehow interfere with future dput-based uploads.  After all the whole
> point is that the uploader simply signs a tag and then the tag2upload
> service does Much Complicated Stuff.

I think many of us needs to understand how the system works under the
hood to trust it.

The best explanation I found was in the sevice design document[1]. I
have the feeling that at least the overall structure and dataflow could
be added to the manual page.

Before reading this doc, I had questions about how the package was
uploaded. Do I need ssh access somewhere? Do I need to push to a special
repository? How is it related to dgit?

As a DM, I was also wondering whether I had the right access to use it
(it’s clear now, I only need push access to salsa).


On a separate topic, now I want to try to use dgit (and git-debrebase!),
but I did not find how pushing to the dgit repo is done (I suppose it
needs my ssh pubkey), maybe it’s not possible for a DM, or maybe
git-debpush renders dgit push obsolete?

Nicolas.

[1]: https://salsa.debian.org/dgit-team/dgit/-/blob/main/TAG2UPLOAD-DESIGN.txt

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Simon Josefsson]

> > NEW uploads should be permitted to be source-only.
> 
> This would be a significant improvement.  I think binaries needed for
> review by the DFSG team should be autobuilt.

DFSG Team: do you look at maintainer-uploaded binaries?  Why?

They could be autobuilt, but I wonder what the real purpose of that is.
Only to prove that the source code actually builds against build
dependencies in Debian?  That would indeed be a good test.  But
binaries aren't needed for that, just a build log from a trusted
builder.

/Simon


signature.asc
Description: This is a digitally signed message part

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Simon Josefsson]

Simon McVittie  writes:

>>> "pristine-tar: With a new upstream version, tag2upload will generate a
>>> fresh orig tarball with git archive (via git-deborig). This is OK, but
>>> it may surprise some users. 1106071."
>>
>>This is probably the toughest nut, and is mostly a matter of opinion if
>>pristine-tar is a good pattern and offers anything useful.
>
> I think pristine-tar is a bit of a red herring here, and the real
> matter of opinion is:
>
> 1. on one side, some developers/workflows/upstreams place value on having
>the orig.tar.* be the same bytes that were delivered by upstream
>(in particular so we can validate signed tarballs)
>or if that isn't possible for DFSG reasons, at least having the
>orig.tar.* contain everything that upstream delivered in their
>official source release, minus the parts that either copyright law
>or our self-imposed rules require us to remove
>
> 2. on the other side, some developers/workflows/upstreams(?) place value
>on having the upstream source code be the same filesystem tree
>("tree-same") that is in upstream's *git repository*, which might or
>might not be closely related to what they release in tarballs if
>any, minus the parts that either copyright law or our self-imposed
>rules require us to remove

That is a good summary -- and establish that both positions are actually
reasonable, or at least not unreasonable, and that they are in conflict.

I think there are a lot of arguments that try to convince people that
only one of those views are objectively right.

My suggest on how to solve this dilemma is for upstreams to publish
cryptographically signed git-archive tarballs.  With those, I believe
both camps should get all the properties they are attempting to reach.

https://blog.josefsson.org/2024/04/01/towards-reproducible-minimal-source-code-tarballs-please-welcome-src-tar-gz/
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/

Some people demand a further approach: replace signed git-archive
tarballs with signed git-bundle's to ship the entire git history.  We do
this for gnulib, but I think few projects need that.

/Simon


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Simon Josefsson]

Jochen Sprickerhof  writes:

> Python Team:
>
> "DPT requires a pristine-tar branch"
>
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

The Python Team's Policy insistance on use of pristine-tar and throwing
away upstream git history is [1]:

   DPT requires a pristine-tar branch, and only upstream tarballs can be
   used to advance the upstream branch. Complete upstream Git history
   should be avoided in the upstream branch.

The pypi.debian.net man-in-the-middle upstream tarball redirector is the
recommended (?) debian/watch URL to use for Python packages [2].

I find this combination really odd.  It is a great setup to enable
xz-style attacks: (several) trusted indirections and lack of audit-chain
between the source code consumed by Debian and the source code from the
upstream maintainer git repository.

Debian is using Python sources from pypi.debian.net, which may or may
not be the actual pypi.org tarball, which may or may not be the source
code coming from each upstream's actual source repository.

/Simon

[1] 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
[2] https://wiki.debian.org/Python/LibraryStyleGuide


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Mathias Behrle]

* Jochen Sprickerhof: " Re: Bug#1127616: developers-reference: should document
  using git-debpush to upload" (Wed, 11 Feb 2026 13:42:46 +0100):

> * Sean Whitton  [2026-02-11 11:52]:
> >For example, I maintain or team half-maintain maybe 90 packages in
> >total, and none of them use pristine-tar.  So the only case where I
> >cannot use tag2upload is when I need to upload to NEW, which is not
> >often.  Therefore tag2upload is my default way to upload, because why
> >wouldn't it be, it's so smooth and easy.  
> 
> My perception is rather different here:
> 
> Python Team:
> 
> "DPT requires a pristine-tar branch"
> 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> 
> Science Team:
> 
> "It is recommended to use pristine-tar"
> 
> https://science-team.pages.debian.net/policy/
> 
> Multimedia Team:
> 
> "gbp clone --pristine-tar"
> 
> https://wiki.debian.org/DebianMultimedia/DevelopPackaging

May be add:

Tryton Team:

pristine-tar required

Upstream uses mercurial, definitely only approved and supported release path is
via tarballs.



-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

Marco d'Itri writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):
> On Feb 11, Marc Haber  wrote:
> >I am especially concerned about this action flipping some switches 
> >either in my repository or in the archive that might prevent me from 
> >switching back to the classical workflow in the case I don't like the 
> >result.
> 
> Come on, it's just a tag: to see what happens you can run "git debpush 
> --tag-only" and then check that the repository has not been maimed.
> And if you want to rollback then you can just delete the tag.

Well, that argument doesn't prove that the tag2upload system wouldn't
act on that tag in a way that would "flip some switches" which would
somehow interfere with future dput-based uploads.  After all the whole
point is that the uploader simply signs a tag and then the tag2upload
service does Much Complicated Stuff.  The whole point is that the
(simple) signed tag causes Debian's official source code management
systems to change state (in a fairly complex way) - thereby moving
some of the complexity away from the user and helping make it more of
an implementation detail.

But knowing the system, I can reassure Marc on this point.

> (Which I still believe should have been the default, with the added 
> benefit of making git-debupush much simpler to implement.)

We chose to make the usual use case the default.  This may make the
functionality and behaviour less immediately obvious to the new
adopter, but we think it's the right tradeoff.

Most of the code in git-debpush is trying to spot user mistakes.  We
have tried quite hard to have it detect what problems we can, within
certain constraints (for example, git-debpush contacts Salsa but not
other network services).

Soemthing that would just Do Exactly What I Told you would be very
simple to write indeed.  You're welcome to write that tool - the
format is documented in tag2upload(5) :-).  Or you can even write the
tag by hand if you like that kind of thing.

We think most users will prefer software that makes uploading a 1-step
process, but which tries to spot and query about potential problems.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

(reordering slightly)

Colin Watson writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):
> On Wed, Feb 11, 2026 at 01:59:10PM +0100, Simon Josefsson wrote:
> >Why on earth are we accepting maintainer-generated binaries into the
> >archive in 2026?
> 
> Just to be clear, I think this is a misinterpretation of the current 
> state.  https://wiki.debian.org/ThrowAwayNewBinaries is implemented; we 
> still require maintainer-generated binaries in that workflow so that the 
> DFSG team can review the resulting layout, but that doesn't equate to 
> "accepting maintainer-generated binaries into the archive" as part of 
> the typical NEW workflow.
> 
> (Yes, there are other situations in which maintainer-generated binaries 
> do get into unstable, although not testing, and non-main is still an 
> issue.  But let's not conflate that with what normally happens when NEW 
> is involved.)

This all matches my understanding.  Nevertheless:

> NEW uploads should be permitted to be source-only.

This would be a significant improvement.  I think binaries needed for
review by the DFSG team should be autobuilt.

For one thing that would mean we would have additional confidence that
the binaries being reivewed match what the source code will produce in
the future, after the package is accepted.  It would also relieve the
uploader of a good deal of palaver.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Ian Jackson]

Marc Haber writes ("Bug#1127616: developers-reference: should document using 
git-debpush to upload"):
> I am especially concerned about this action flipping some switches 
> either in my repository or in the archive that might prevent me from 
> switching back to the classical workflow in the case I don't like the 
> result.

I can reassure yo on this point.  There is no such switch.

You can try tag2upload, or indeed dgit, out for one upload, and then
go back to dput.  (Indeed, different maintainers of the same package
can use different upload techniques.)

There is some additional state used by tag2upload and dgit, but it is
completely ignored by the legacy tarball- and dsc-based archive
systems so definitely won't affect dput-based uploads.

I hope this helps.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Colin Watson]

On Wed, Feb 11, 2026 at 01:59:10PM +0100, Simon Josefsson wrote:

Holger Levsen  writes:

"Uploads to NEW (even if only binary-NEW), because for those ftp.d.o
currently demands maintainer-generated binaries."


Why on earth are we accepting maintainer-generated binaries into the
archive in 2026?

Yes, I know several reasonable answers to that question, but they don't
resolve the concern with maintainer-generated binaries.

NEW uploads should be permitted to be source-only.


Just to be clear, I think this is a misinterpretation of the current 
state.  https://wiki.debian.org/ThrowAwayNewBinaries is implemented; we 
still require maintainer-generated binaries in that workflow so that the 
DFSG team can review the resulting layout, but that doesn't equate to 
"accepting maintainer-generated binaries into the archive" as part of 
the typical NEW workflow.


(Yes, there are other situations in which maintainer-generated binaries 
do get into unstable, although not testing, and non-main is still an 
issue.  But let's not conflate that with what normally happens when NEW 
is involved.)


--
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Wed, Feb 11, 2026 at 05:36:18PM +, Colin Watson wrote:

On Wed, Feb 11, 2026 at 06:08:02PM +0100, Marc Haber wrote:

On Wed, Feb 11, 2026 at 06:04:23PM +0100, Marco d'Itri wrote:

On Feb 11, Marc Haber  wrote:
I am especially concerned about this action flipping some 
switches either in my repository or in the archive that might 
prevent me from switching back to the classical workflow in the 
case I don't like the result.


I understand the caution, but as a "git debpush" user I really think 
this is very unlikely.  It doesn't even change the working tree state; 
all it does is make a specially-formatted tag and push it.  It is 
definitely not any kind of one-way switch.


Still something happens in the archive that I don't fully understand. As 
far as I understand there is a chance that it will build its own 
mypackage_version.orig.tar.gz that might be different from what upstream 
has released and signed, with myself being unable to get that file out 
of the archive forever, looking as if it was ME who messed things up.


"git debpush --tag-only" is documented in git-debpush(1) as "Just tag, 
don't push".  That means you can try it out, look at the git state, 
and roll back locally if you don't like it.


The interesting things happen after the push.

Greetings
Marc

--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Colin Watson]

On Wed, Feb 11, 2026 at 06:08:02PM +0100, Marc Haber wrote:

On Wed, Feb 11, 2026 at 06:04:23PM +0100, Marco d'Itri wrote:

On Feb 11, Marc Haber  wrote:
I am especially concerned about this action flipping some switches 
either in my repository or in the archive that might prevent me 
from switching back to the classical workflow in the case I don't 
like the result.


I understand the caution, but as a "git debpush" user I really think 
this is very unlikely.  It doesn't even change the working tree state; 
all it does is make a specially-formatted tag and push it.  It is 
definitely not any kind of one-way switch.


Come on, it's just a tag: to see what happens you can run "git 
debpush --tag-only" and then check that the repository has not been 
maimed.

And if you want to rollback then you can just delete the tag.

(Which I still believe should have been the default, with the added 
benefit of making git-debupush much simpler to implement.)


So nothing happens in the archive when I run git debpush?

Why are we doing it then?


Reading what Marco said a little more closely:

"git debpush --tag-only" is documented in git-debpush(1) as "Just tag, 
don't push".  That means you can try it out, look at the git state, and 
roll back locally if you don't like it.


Normally, though, you wouldn't use the --tag-only option and it would 
push the tag to Salsa, which will cause the tag2upload service to upload 
your changes to the archive.


--
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Gunnar Wolf]

Simon Josefsson dijo [Wed, Feb 11, 2026 at 01:59:10PM +0100]:

(...)
All the things on the "Not supported" ways can be considered bugs
elsewhere -- thus I think the title of that section could be changed to
"Design limitations" or similar instead.


I agree on this. A tool should not be promoted as the only one right and
modern way to interface with the archive as long as it does not address
some widespread and useful use cases.


(... several points I completely agree with ...)

"pristine-tar: With a new upstream version, tag2upload will generate a
fresh orig tarball with git archive (via git-deborig). This is OK, but
it may surprise some users. 1106071."


This is probably the toughest nut, and is mostly a matter of opinion if
pristine-tar is a good pattern and offers anything useful.  I used to be
a big supporter of pristine-tar, but I'm now neutral.  Pristine-tar
doesn't offer the strong security properties or features that I thought
it did, and comes with a large storage and transfer cost.


I agree, I do not _love_ pristine-tar, but I do _use_ it. And I don't want
to ditch it just to try a new tool.


Uploads to security-master. This is difficult: 862105.


TBH I have no idea about this one, but I suspect the security-master
upload workflow isn't particular modern.


Maybe it is not particularly modern, but it is _vital_. And as long as we
have to teach newcomers to use a different tool whenever they need to do a
security upload, I cannot support having The Single Sanctioned Workflow™ to
be one that cannot be used. A different set of tools have to be learned by
our developers to do security support.


Uploads to backports where your workflow involves throwing away the
changelog entries for previous backports. I.e. if you start fresh for
each version from testing you backport. If you do something like git
checkout debian/bookworm-backports && git merge debian/latest and then
resolve the debian/changelog merge conflict so as to preserve all
entries, then it works (1109584).


The special debian/changelog handling for backports has always seemed
odd to me.  I think having in-package changelog files are increasingly
becoming an obsolete pattern, for the same reasons ChangeLog files are
now less relevant.


I do believe there is important value in having a human-readable,
human-oriented debian/changelog. Not all commits are of the same
importance, and having a document written so that readers understand the
main issues in a way that does not assume familiarity with implementation
details is important IMO.

Now, I know this is not an issue WRT git-debpush, it only highlights a
–again, IMO– minor nuance where a bit of usual practice has to be changed.


NMUs that don't use the package maintainer's git repository, and git
workflow, aren't likely to work well. Instead, use dgit, which offers
a completely uniform git-based NMU workflow.


Doing NMUs without pushing to maintainer's repository leads to a mess
that is frustrating to clean up from (look at some NetKit packages), and
the only reason why anyone would ever do that is because some
maintainers protect commit access to their packaging.  Which is a real
problem.


...And that some maintainers do not keep their packaging in a VCS (and,
particularly, in Git). Yes, this is finally seen as a problem rather than
norm, but still...


DELAYED/DEFERRED uploads (1123680).


I think the concept of DELAYED/DEFERRED, like NMUs, are historic ways of
working which today have better methods: bug-reports, merge requests,
Salsa pipelines, Debusine uploads, or mailing-list discussion.


Here, I disagree. I find DELAYED/DEFERRED a good, useful practice. It is a
good way to fix a bug in an NMU if you are not sure the package maintainer
is active and you don't want to keep the pending upload in the back of your
head for X days until you get an answer — uploading something to be done a
week from now is a good way to say, “I did the following changes and it
works for me™, feel free to roll it back before it reaches the public”.

I would love it if, for several of the last points, we lowered this notion
of “package ownership”. I would love that Debian held a culture where the
Maintainer/Uploader fields stated who is most likely to respond to issues
with packaging, but where every package would be a valid upload target for
all of us. But I know many people are not willing to embrace something that
strong.


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Wed, Feb 11, 2026 at 06:04:23PM +0100, Marco d'Itri wrote:

On Feb 11, Marc Haber  wrote:
I am especially concerned about this action flipping some switches 
either in my repository or in the archive that might prevent me from 
switching back to the classical workflow in the case I don't like 
the result.
Come on, it's just a tag: to see what happens you can run "git debpush 
--tag-only" and then check that the repository has not been maimed.

And if you want to rollback then you can just delete the tag.

(Which I still believe should have been the default, with the added 
benefit of making git-debupush much simpler to implement.)


So nothing happens in the archive when I run git debpush?

Why are we doing it then?

Greetings
Marc


--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marco d'Itri]

On Feb 11, Marc Haber  wrote:

I am especially concerned about this action flipping some switches 
either in my repository or in the archive that might prevent me from 
switching back to the classical workflow in the case I don't like the 
result.
Come on, it's just a tag: to see what happens you can run "git debpush 
--tag-only" and then check that the repository has not been maimed.

And if you want to rollback then you can just delete the tag.

(Which I still believe should have been the default, with the added 
benefit of making git-debupush much simpler to implement.)


--
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Wed, Feb 11, 2026 at 12:15:40PM +, Holger Levsen wrote:

pristine-tar: With a new upstream version, tag2upload will generate a fresh 
orig tarball with git archive (via git-deborig). This is OK, but it may 
surprise some users. 1106071.


I find that a problem for upstreams that don't releasa via signing tags. 
That is the majority of my packages. I think that having an .orig.tar.gz 
that hashes the same as the tarball relesed by upstream is vital for us.


Just for the record: None of my packages require upstream repacking.


And with limitations, i'm sorry but then i'm not, I feel limited to use
different words (than the one you called accusation) for your *important*
bug request documenting and recommending tag2upload for *everyone* right
now, a week after it came out of beta.

I surely have good faith in you (and Ian!) that you mean well, and also
that tag2upload will (and for some already is!) be super useful in the future.

However, we are not there yet. So yes, I stand by what I ment. And yes, maybe
"propaganda stunt" is a bit too much, however I'm not sure you would have
liked "immature $something" much better.


I fully agree and would like to add that the perisistence that 
tag2upload gets pushed slowly begins an urge to push back in my 
consiousness. Just to say it in German: "es nervt".


Greetings
Marc


--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Marc Haber]

On Wed, Feb 11, 2026 at 11:52:14AM +, Sean Whitton wrote:

I would encourage everyone reading to try 'git debpush' so we can move
on from this situation, towards one with greater mutual understanding.


I am not going to do that with a live package into the live archive from 
a live repository without understanding what happens and without ever 
having seen a real-life workflow that isn't some 
everything-so-fine-and-new-and-shiny-that-this-never-happens-in-reality 
corner case


I am especially concerned about this action flipping some switches 
either in my repository or in the archive that might prevent me from 
switching back to the classical workflow in the case I don't like the 
result.


I might try this with an extra upload to experimental right before 
switching to a new upstream version. That sounds like a reasonably safe 
point in package life to try.


Greetings
Marc


--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Santiago Vila]

On Wed, Feb 11, 2026 at 02:48:19PM +0100, Jochen Sprickerhof wrote:
> * Santiago Vila  [2026-02-11 14:37]:
> > Sorry, I can't give examples because I did not take notes, but I
> > remember that it was not a mismatch between orig tarball and git
> > branch (I am usually quite careful about that) but rather some
> > difficulty from Salsa CI to create an orig tarball. I believe it had
> > something to do with uscan and the flaky network connectivity of
> > ftp.gnu.org some weeks/months ago.
> > 
> > I know Salsa CI uses some heuristics to create the orig.tar.gz and
> > it uses uscan and the watch file in some cases. I assume there
> > is a high overlap between Salsa CI having to do that and
> > lack of a pristine-tar branch.
> 
> salsa-ci uses gbp export-orig and falls back to origtargz in case that fail:
> 
> https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/salsa-ci.yml?ref_type=heads#L440
> 
> gbp export-orig uses only git and does not use pristine-tar by default.
> origtargz can fallback to uscan. So it would be even more interesting where
> it failed for you.

I see gbp export-orig tries to use the upstream tag when there is no
pristine-tar branch, so it's possible that I just forgot to push the
upstream branch with its tag. This might have triggered the origtargz
thing, which in turn may have failed because of poor connectivity at
ftp.gnu.org and the fact that it was a -1 version (because Salsa CI
is also able to get the tarball from the archive when it exists).

That's my best theory so far. Sorry that I can't provide more details,
this is the kind of thing that you forget about when you find a
workaround that works.

Thanks.

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Simon McVittie]

On Wed, 11 Feb 2026 at 13:59:10 +0100, Simon Josefsson wrote:

Holger Levsen  writes:

"pristine-tar: With a new upstream version, tag2upload will generate a
fresh orig tarball with git archive (via git-deborig). This is OK, but
it may surprise some users. 1106071."


This is probably the toughest nut, and is mostly a matter of opinion if
pristine-tar is a good pattern and offers anything useful.


I think pristine-tar is a bit of a red herring here, and the real matter 
of opinion is:


1. on one side, some developers/workflows/upstreams place value on having
   the orig.tar.* be the same bytes that were delivered by upstream
   (in particular so we can validate signed tarballs)
   or if that isn't possible for DFSG reasons, at least having the
   orig.tar.* contain everything that upstream delivered in their
   official source release, minus the parts that either copyright law
   or our self-imposed rules require us to remove

2. on the other side, some developers/workflows/upstreams(?) place value
   on having the upstream source code be the same filesystem tree
   ("tree-same") that is in upstream's *git repository*, which might or
   might not be closely related to what they release in tarballs if
   any, minus the parts that either copyright law or our self-imposed
   rules require us to remove

(And at the same time we have a zero-tolerance policy for 
non-DFSG-compliant files, even if not installed or used, which means 
that when the upstream release contains such files we cannot completely 
follow either (1.) *or* (2.).)


For packages where (1.) is valued higher, pristine-tar is one tool that 
can help to make it happen. It is not the only tool: it's the most 
commonly-used, but pristine-lfs is one alternative that I know about, 
and I'm sure there are others. I think we should not mistake use of the 
pristine-tar tool, specifically, for being the same thing as wanting to 
follow model (1.).


I know that the dgit/tag2upload developers are very much in favour of 
(2.), but I also think it would be a mistake to entangle "we want people 
to use dgit/tag2upload" with "we want people to stop trying to use 
something closely resembling upstream tarball releases as the 
preferred/official source code, and instead behave as though upstream 
didn't release an official source artifact" (and indeed, their design 
has been careful to accommodate arbitrary .orig tarballs, as long as 
there is a git branch that is "tree-same").


The big elephant-in-the-room reason for (1.) and (2.) to differ is 
Autotools, but there are many others, like upstream packages that 
expect/require that their package is either being built from git (with 
./.git and history available for `git describe`, which our buildds 
notably don't have) or from a tarball (with extra files like 
./.tarball-version to compensate for not having git history) but not 
some middle ground between those.


I feel like I should also point out here that devref §6.9.8 demands that 
we keep the upstream source release as pristine as possible, including 
build infrastructure for non-Debian OSs.


As I think I've said before, if some project members are going to demand 
that I follow documented best-practice by doing (1.), and other project 
members are going to demand that I follow their view of best-practice by 
doing (2.), then I'm sorry but someone is going to have to be 
disappointed, because it isn't possible to do both at the same time.



The special debian/changelog handling for backports has always seemed
odd to me.  I think having in-package changelog files are increasingly
becoming an obsolete pattern, for the same reasons ChangeLog files are
now less relevant.


Whether they're an obsolete pattern or not, our packaging system 
requires the changelog, so we can't just ignore its existence.


I believe we also use debian/changelog as a load-bearing part of our 
approach to license compliance: it's our implementation of the 
"prominent notices stating that [we] modified it" and "relevant date" 
from GPL-3 §5a, or similar concepts from other licenses.


smcv

Re: Bug#1127616: developers-reference: should document using git-debpush to upload

[Jochen Sprickerhof]

* Santiago Vila  [2026-02-11 14:37]:

Sorry, I can't give examples because I did not take notes, but I
remember that it was not a mismatch between orig tarball and git
branch (I am usually quite careful about that) but rather some
difficulty from Salsa CI to create an orig tarball. I believe it had
something to do with uscan and the flaky network connectivity of
ftp.gnu.org some weeks/months ago.

I know Salsa CI uses some heuristics to create the orig.tar.gz and
it uses uscan and the watch file in some cases. I assume there
is a high overlap between Salsa CI having to do that and
lack of a pristine-tar branch.


salsa-ci uses gbp export-orig and falls back to origtargz in case that 
fail:


https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/salsa-ci.yml?ref_type=heads#L440

gbp export-orig uses only git and does not use pristine-tar by default. 
origtargz can fallback to uscan. So it would be even more interesting 
where it failed for you.




signature.asc
Description: PGP signature