Re: Broken uploads to mentors.debian.net
On Sat, Jul 14, 2007 at 10:42:52PM +0100, Neil Williams wrote:
> Just had a problem with a package for sponsoring that, AFAICT, could
> not happen with other repositories that I use, so I'm a tad concerned
> about how it happened on m.d.n.
>
> http://mentors.debian.net/debian/pool/main/x/xracer/
>
> A package has been uploaded to m.d.n several times during sponsoring
> (not uncommon) at the same version (also no uncommon) so
> the .orig.tar.gz is unchanged (which is correct):
> xracer_0.96.9.orig.tar.gz 26-Jun-2007 17:26 9.1M
>
> Other files have been updated, as expected:
> xracer_0.96.9-1.diff.gz 14-Jul-2007 17:28 28K
> xracer_0.96.9-1.dsc 14-Jul-2007 17:28 1.4K
>
> That .orig.tar.gz on m.d.n is the same as my last build:
> 41bdf64eca9960ae8932e27e7ba2bea1 9562055 xracer_0.96.9.orig.tar.gz
>
> However, the .dsc file uploaded to m.d.n references a
> different .orig.tar.gz:
> 8287bfd7e9ef9a507024bf34761791d8 9562064 xracer_0.96.9.orig.tar.gz
>
> Of course, dget -x now refuses to unpack this package - error from
> dpkg-source.
>
> I suspect an error in the .dsc but I thought that dput should have
> caught that or that the repository management tools at m.d.n should
> have complained (noisily):
>
> "Uploaded foo.dsc needs foo.orig.tar.gz with md5sum .... which differs
> from the existing foo.orig.tar.gz with md5sum ...." or similar and
> rejected the upload.
>
> I know I have had those kind of warnings from reprepro with other
> repositories - IIRC it is why we have md5sums in the .dsc in the first
> place (in addition to GnuPG signatures).
>
> Is this a result of the need to allow repeated uploads of packages at
> the same version?
Actually I don't like the idea of uploading a different file with the
same revision number. But a lot of sponsors seem to expect a ~mentors001
revision suffix or just always a "-1" revision until the package is
sponsored. When I sponsor packages I always make my sponsorees use
proper revision numbers. Who cares if it takes 10 revisions until the
package is ready for upload? Let it be revision "-10" then. At least I
don't need to know that the sponsoree meant "the version from yesterday
evening 7 p.m. CET-4" but rather use revision "-4". I found it
educationally better to handle mentors.debian.net just like the usual
ftp-master:
- once uploaded the orig tarball can't be altered any more
- new uploads are only valid with higher version/revision numbers
But since so many people insisted that the same revision should be
allowed to be overwritten I didn't enforce that.
> Can something be done with the m.d.n scripts that handle dput uploads
> to enforce a check that the existing .orig.tar.gz (which should not
> normally change during sponsorship) matches the reference in the .dsc
> and allow for the odd occasion where the .orig.tar.gz does have to be
> repackaged with an explicit mechanism?
I just checked the import script I wrote quite a while ago that handles
the uploaded files. There is but one situation that I can think of where
that clash of orig tarballs could happen:
- a sponsoree creates a package for the first time
- the orig tarball gets uploaded as it is referenced in the changes/dsc
file
- the sponsoree somehow alters the orig tarball but keeps the filename
(or rather the name and version number)
- mentors.debian.net believes it already has the orig file in the pool
directory and ignores the newly uploaded file
Instead of obeying the MD5 sum of the package at that point (I do when
the .dsc file is checked though) I'll make sure that all the uploaded
files will replace all previous existing files of a source package in
the pool directories. That should do it.
> At the very least, m.d.n should be able to prevent this situation where
> 'dget -x' fails as this is the most common method of sponsors obtaining
> sources from m.d.n.
Correct. I have to either forbid that or make it work gracefully.
I think I'll rather accept that but send the uploader a big warning.
> If it helps, I have been able to fettle the .dsc to use the correct
> values for the existing .orig.tar.gz and it has unpacked OK - it
> appears to simply be an error in the .dsc caused by some problem with
> the sponsoree. However, I am unable to upload the package in this
> condition (which is frustrating for the sponsoree because this package
> has had quite a few changes and he has put in a significant amount of
> work getting it ready for sponsoring). I was all ready to upload the
> package tonight too.
Current workaround: let the sponsoree delete the package through the web
interface and re-upload.
I'll look into this later today and probably fix it.
Christoph
--
Peer review means that you can feel better because someone else
missed the problem, too.
Reply to: