Hi Ian, Sean,

While discussing our Release Team work with Graham, we thought it might
be a nice feature by the dgit infrastructure if it could support
lightweight (i.e. no local download of the source) no-change-source-only
uploads to the archive. Two usecases come up in my mind (but I bet there
are more):
* Fix an arch:all binary upload (I happen to do this regularly, with the
   aid of a script that powers dgit)
* Complement the binNMU facilities we have for the Release Team, but
   without some of the binNMU drawbacks:
   * Architectures in sync
   * Automatic migration checks (obviously this could be fixed on the
     Release Team side of things too)
   * Reproducibility people happier (they don't like binNMUs weird
     changelogs if I recall correctly)

Paul

Paul Gevers writes ("Bug#1085152: dgit: support lightweight no-change-source-only uploads"):

Hi.  Thanks for this suggestion.
I think this could be a function of the tag2upload service.

Do we, in this scenario, mind downloading a git clone of the package?
I think it would be best if we could avoid it.

How does the person doing this indicate their intent ?

They could make an OpenPGP signature which would say something like
"please no-source-upload package X, version A, to suite S,
as version B".

Or, in principle, there could be a web self-service system, but that
has many Implications and fits into the various data models less well.

That OpenPGP signature could be a signed git tag.  To make a tag, the
tagger does *not* need a complete copy of the code.  They need the
commitid, but that's readily available if the package is on
dgit-repos.

I think this could be a mode of git-debpush, or an allied utility.

Presumably the tag2upload service would retrieve the previous
version's archive/ tag and check that it had the same commitid.  It
should also check the ftpmaster API to get the hash of the
corresponding .dsc, and fish out the Dgit: field.

(This approach trusts that we won't find that both dgit-repos and
ftpmaster API are colmpromised.  Neither the authoriser, nor the t2u
service, can reliably verify the signature on the previous archive/
tag.  Debian has no post-hoc audit capability for upload signatures.)

Also, this only works for packages where the most recent version is on
dgit-repos.  Currently that's packages uploaded with dgit, and, soon,
t2u.  I'm hoping that t2u adoption will become widespread.  At that
point I think it would be a good idea to start importing all uploaded
packages into dgit-repos automatically.

Anyway, I think we should focus on t2u service deployment for "normal"
uploads first - but having this kind of future scenario in mind is a
good think.

After t2u is deployed I think we should probably try to widen the
t2u/dgit team.  (And we as t2u service operators should seek a DPL
delegation.)  There will be more space to explore this kind of idea.

Ian.

Hello,

Likewise.

Yeah, I think it makes sense to do those automatic imports first,
because that helps with this and several other ideas for extension we
have discussed.  It also helps us stress test the adequacy of dgit-repos
for things we might want it to do.