Hi. Thanks for the explanations. I guess that our beta phase is
precisely when you should be carrying out experiments like this...
Simon Josefsson writes ("Bug#1121367: tag2upload-obtain-origs: Needs to ask
git-deborig for .gz compression"):
> Please consider the following before touching code: What happened where
> was that I push the limits of tag2upload a bit, in particular:
>
> 1) I did 'git-debpush' for a NEW upload, causing something not in the
> Debian archive at all to show up on dgit, but the source-ful upload from
> tag2upload succeding on your side but failing on the upload queue side.
In the dgit data model, this is an acceptable out-of-course situation.
Unfortunately, we must work with the existing archive machinery which
is very asynchronous and hard to deal with. So skew like this cannot
be entirely prevented.
This skew *is* undesirable so we try to minimise it. Sadly I don't
think there is a reasonable way for git-debpush to detect this
particular situation, without having it query the archive API, which
we don't want it to do because it's supposed to be a pure git tool.
(I would be open to reconsidering this principle TBH. A call to the
ftpmaster API service wouldn't be a lot of code nor a lot of data
transfer, and it would jsut be part of the checks, not entangled with
the tag creation functionality.)
> I upload my amd64 build at the same time as I do the git-debpush, and
> since gbp defaults to *.gz and tag2upload defaults to *.xz there is no
> filename clash in the upload, so my amd64 upload "wins" and the
> source-only upload gets discarded eventually.
Why did you make these two uploads at the same time? You explain what
you did but not whether you did it deliberately :-).
Our recommendation for NEW is to use dgit. "dgit push-built",
specifically. This fits roughly ito the same space as git-debpush,
except that of course you have to build binaries. "dgit sbuild" and
"dgit pbuilder" will do that for you. Presumably you have a suitable
chroot setup.
(We don't like that we need wrappers for these build commands, but
they're quite shallow wrappers.)
> 2) This package was ACCEPTED by ftp-masters into the archive, and BEFORE
> the orig.tar file appeared on deb.debian.org etc I did a source-only -2
> upload of the package. That failed below, and I was somewhat ready for
> this to fail, because I wanted to see how things behaved in this
> situation.
I think if we did what Sean suggests in this bug report, this would
work (at least, almost all of the time) - because t2u would be able to
reproduce the gbp-generated .orig.tar.gz.
You make a couple of other points about handling of NEW in *.dgit.d.o:
> Re 1) I have used this a couple of times now. It leads to things not in
> the archive showing up on browse.dgit.debian.org.
Was this package wholly-NEW, or only NEW due to new binary packages?
The system is supposed to hide wholly-NEW packages from the public git
view on browse.dgit.d.o and git.dgit.d.o until they are ACCEPTed.
If that isn't working it needs fixing.
> This is open for abuse, any DD could
TBH I think this would be an attack that we expect a DD not to
conduct. So that's outside our threat model. If it were to happen,
we would manually delete the bullshit and get DAM to eject the
perpetrator.
That the -1 upload is visible to authorised users, while in NEW, via
push.dgit.d.o, is deliberate, for the reasons you gave and that I've
snipped.
HTH.
Ian.
--
Ian Jackson <[email protected]> These 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.
