On Fri, Jan 19, 2018 at 11:44:50AM -0500, Jeremy Bicha wrote: > On Fri, Jan 19, 2018 at 11:11 AM, Christian T. Steigies <c...@debian.org> > wrote: > > Since the package migrated to Debian/testing, I consider this to be a bug in > > Ubuntu Launchpad, not Debian. Please forward it to Ubuntu as I can not fix > > bugs in Ubuntu. > > The only thing that is needed now is to make a new upload versioned as > 1:1.0.51-12. > > Otherwise, there are 2 files named moon-buggy_1.0.51-1.dsc in Debian > with different contents. While we can't fix history, we can at least > fix now and ignore the old broken version. > > http://snapshot.debian.org/package/moon-buggy/1%3A1.0.51-1/ > http://snapshot.debian.org/package/moon-buggy/1.0.51-1/ > > This also is seen in the .deb's which don't include the epoch in their > version name either (see Debian bug #645895) > http://ftp.debian.org/debian/pool/main/m/moon-buggy/
Thanks for confirming my point. There are no conflicting files as every upload has its own directory on snapshot. And if you are not sure about the epoch (it is included in the directory name), the dsc contains a Version line that includes the epoch. The oldest version on the ftp server (9.1) is from 2012, the -1 version which has been uploaded 12 years ago is not available in the pool, so there is no conflict either. The bug report you mention has had no activity since more than a year, so I guess this is not seen as a problem. If it were a problem, the upload should have been rejected and not progressed into testing. > This is a case where Launchpad is more sensitive to brokenness than > Debian publishing is, but the filename conflict is still a bug in the > Debian moon-buggy packaging. So you agree that this is a bug in Launchpad that it does not handle epochs correctly? Please move your bug report over there or let ubuntu upload its own version if they are so interested in this package. Skipping 10 debian versions for no reason looks even more ugly than using an epoch, IMHO. > By the way, you don't need to use an epoch just to switch to 3.0 > (quilt) from implicit 1.0 native. You did not look at the files it seems. The current version contains the actual orig.tar.gz as it should have been from the beginning (if there had not been a bug report requesting sound support which required an extra tarball and a complicated build process to build two packages from one source). The original upload has a different source tarball (which included the two orig tarballs) and was unfortunately packaged as native package, my bad. I saw no other way to use the actual orig.tar.gz than using an epoch. When uploading a new orig.tar.gz you need to start with Debian version 1 as far as I know. The last upload was not related to switching to quilt, I just changed this as well to follow current packaging standards. Christian
