Bug#887740: moon-buggy: Please bump the Debian part of the version number

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Jeremy Bicha-5
Source: moon-buggy
Version: 1:1.0.51-1

moon-buggy can't be automatically synced to Debian because Launchpad
gives this error:

moon-buggy 1:1.0.51-1 in buster (moon-buggy_1.0.51-1.dsc already
exists in destination archive with different contents.)

I believe all you need to do to fix this is to upload a new version as
1:1.0.51-12 so that the non-epoch version has a different (and in this
case, higher) version number.

By the way, I don't see any reason why you needed to add or bump the epoch here.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Christian T. Steigies
On Fri, Jan 19, 2018 at 10:07:26AM -0500, Jeremy Bicha wrote:

> Source: moon-buggy
> Version: 1:1.0.51-1
>
> moon-buggy can't be automatically synced to Debian because Launchpad
> gives this error:
>
> moon-buggy 1:1.0.51-1 in buster (moon-buggy_1.0.51-1.dsc already
> exists in destination archive with different contents.)
>
> I believe all you need to do to fix this is to upload a new version as
> 1:1.0.51-12 so that the non-epoch version has a different (and in this
> case, higher) version number.

As far as I understand 1:1.0.15-1 is larger than 0:1.0.15-whatever.
The package has migrated to testing, what else needs to be synced in Debian?
What is Launchpad?

https://packages.qa.debian.org/m/moon-buggy.html
I do not know why the source package does not include the epoch in the dsc
filename, but thats how it came out of git buildpackage.

> By the way, I don't see any reason why you needed to add or bump the epoch here.

I was asked to remove ESD support. The old source package contained two tar
balls, the "real" tarball plus a separate one with patches (upstream wanted
things separate). The build script was, say, not optimal, and I also made
the mistake of uploading it as debian native package. By bumping the epoch
and repackaging from scratch, I tried to fix all the mistakes I had made a
long time ago. What is the purpose of an epoch if I need to increase the
Debian version nevertheless?

Christian

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Jeremy Bicha-5
On Fri, Jan 19, 2018 at 10:45 AM, Christian T. Steigies <[hidden email]> wrote:
> The package has migrated to testing, what else needs to be synced in Debian?
> What is Launchpad?

Oops, I meant to write "can't be synced to Ubuntu". Launchpad is the
service Ubuntu uses for bug tracking and many other things needed to
build Ubuntu.

> https://packages.qa.debian.org/m/moon-buggy.html
> I do not know why the source package does not include the epoch in the dsc
> filename, but thats how it came out of git buildpackage.

Epochs are not included in filenames.

>> By the way, I don't see any reason why you needed to add or bump the epoch here.
>
> I was asked to remove ESD support. The old source package contained two tar
> balls, the "real" tarball plus a separate one with patches (upstream wanted
> things separate). The build script was, say, not optimal, and I also made
> the mistake of uploading it as debian native package. By bumping the epoch
> and repackaging from scratch, I tried to fix all the mistakes I had made a
> long time ago. What is the purpose of an epoch if I need to increase the
> Debian version nevertheless?

I don't know. Why do you think you needed to use an epoch? epochs are
strongly disliked by many Debian Developers and we prefer to avoid
them unless they are necessary.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Christian T. Steigies
Moin,
On Fri, Jan 19, 2018 at 10:55:35AM -0500, Jeremy Bicha wrote:
> On Fri, Jan 19, 2018 at 10:45 AM, Christian T. Steigies <[hidden email]> wrote:
> > The package has migrated to testing, what else needs to be synced in Debian?
> > What is Launchpad?
>
> Oops, I meant to write "can't be synced to Ubuntu". Launchpad is the
> service Ubuntu uses for bug tracking and many other things needed to
> build Ubuntu.

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.

> > https://packages.qa.debian.org/m/moon-buggy.html
> > I do not know why the source package does not include the epoch in the dsc
> > filename, but thats how it came out of git buildpackage.
>
> Epochs are not included in filenames.
>
> >> By the way, I don't see any reason why you needed to add or bump the epoch here.
> >
> > I was asked to remove ESD support. The old source package contained two tar
> > balls, the "real" tarball plus a separate one with patches (upstream wanted
> > things separate). The build script was, say, not optimal, and I also made
> > the mistake of uploading it as debian native package. By bumping the epoch
> > and repackaging from scratch, I tried to fix all the mistakes I had made a
> > long time ago. What is the purpose of an epoch if I need to increase the
> > Debian version nevertheless?
>
> I don't know. Why do you think you needed to use an epoch? epochs are
> strongly disliked by many Debian Developers and we prefer to avoid
> them unless they are necessary.

I tried to explain in my answer above. When I first uploaded 1.0.51 I made
the mistake to upload it as Debian native package and I want to ship the
source without the ESD patches now.  I see no other way of fixing this than
using an epoch (there will not be another upstream release, I have waited
for more than 10 years already).  I know DDs do not like epochs, this is the
first time I used one.  As far as I understand the packaging manual, it is a
valid option if you screwed up the version numbering.  If you know of a
better solution, please let me know.  But in any case, moon-buggy now uses
an epoch.

Christian

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Jeremy Bicha-5
On Fri, Jan 19, 2018 at 11:11 AM, Christian T. Steigies <[hidden email]> 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/

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.

By the way, you don't need to use an epoch just to switch to 3.0
(quilt) from implicit 1.0 native.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Christian T. Steigies
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Jeremy Bicha-5
On Wed, Jan 24, 2018 at 3:05 PM, Christian T. Steigies <[hidden email]> wrote:
> 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.

If we were able to auto-reject every bug, then there wouldn't be any
bugs in Debian, right?

Epochs are bumped so rarely that I guess no one thought this issue
needed to be written into Debian Policy yet. Should we ask other
Debian Developers what they think about this issue?

> So you agree that this is a bug in Launchpad that it does not handle epochs
> correctly?

No, it will cause problems for any system that maintains a complete
Debian package history which absolutely should be possible.

> You did not look at the files it seems.

1.0.51-11 contains moon-buggy_1.0.51-11.tar.gz
Switching to 3.0 (quilt) gives you moon-buggy_1.0.51.orig.tar.gz

Those file names are not the same and therefore it would have been
fine. You absolutely do not need an epoch when switching from a native
package to a non-native package.

> I saw no other way to use the actual orig.tar.gz than using an epoch.

You could have used a 1.0.51+repack-1 version number, which would have
worked just fine for Ubuntu too.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Christian T. Steigies
On Wed, Jan 24, 2018 at 07:39:24PM -0500, Jeremy Bicha wrote:
> On Wed, Jan 24, 2018 at 3:05 PM, Christian T. Steigies <[hidden email]> wrote:
> > 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.
>
> If we were able to auto-reject every bug, then there wouldn't be any
> bugs in Debian, right?

Isn't that the goal? This will probably never happen, but at least wrong
version numbers should be automatically detectable, by lintian or other
tools that ftp masters use.  If I can not use an epoch to start version
numbers from scratch, then the whole implementation of epochs is broken.
I doubt that I am the first to fall into this trap.

> Epochs are bumped so rarely that I guess no one thought this issue
> needed to be written into Debian Policy yet. Should we ask other
> Debian Developers what they think about this issue?

I think we can agree that this is a bug not specific to my package. I think
it is a ubuntu bug, so you should forward it to ubuntu.  You think it is a
debian bug, in that case I think you should attach it to the bug you already
mentioned.  If you do not agree to that, maybe you have to take it up with
the TC, as I do not plan to introduce a bug in debian packaging to fix a
bug in ubuntu.  Or you take over maintenance of the package, but I doubt that
this would make the bug go away.
 
> > So you agree that this is a bug in Launchpad that it does not handle epochs
> > correctly?
>
> No, it will cause problems for any system that maintains a complete
> Debian package history which absolutely should be possible.

But you showed me that snapshot.debian.org has absolutely no problem to keep
track of every single upload by using separate directories that include the
epoch in the directory name. Or is this a bug as well?

> > You did not look at the files it seems.
>
> 1.0.51-11 contains moon-buggy_1.0.51-11.tar.gz
> Switching to 3.0 (quilt) gives you moon-buggy_1.0.51.orig.tar.gz
>
> Those file names are not the same and therefore it would have been
> fine. You absolutely do not need an epoch when switching from a native
> package to a non-native package.

But I can not upload two 1.0.51 versions with different tar files, can I?
 
> > I saw no other way to use the actual orig.tar.gz than using an epoch.
>
> You could have used a 1.0.51+repack-1 version number, which would have
> worked just fine for Ubuntu too.

But it would have been wrong because I uploaded the actual orig.tar.gz, it
was not repacked.  Maybe the earlier uploads should have used repack as I
had to merge two upstream tarballs into one, but that would not have
allowed me to go back to the actual orig.tar without an epoch either.  I
waited for a new upstream version for a long time, but with the removal of
esound support I had to do something now (and upstream indicated that there
would be no further development, especially no more sound support).

Christian

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Raphael Hertzog-3
Hello,

On Thu, 25 Jan 2018, Christian T. Steigies wrote:
> If I can not use an epoch to start version
> numbers from scratch, then the whole implementation of epochs is broken.
> I doubt that I am the first to fall into this trap.

epochs are meant to go backwards when upstream changes their versioning
scheme... upstream did not change anything here and using an epoch was
thus not the correct choice.

> > Those file names are not the same and therefore it would have been
> > fine. You absolutely do not need an epoch when switching from a native
> > package to a non-native package.
>
> But I can not upload two 1.0.51 versions with different tar files, can I?

Jérémy is correct. You definitely can because the filenames are
different. And even when you use a filename conflict you can update
the tarball just by using a different compression, i.e. using
orig.tar.xz instead of orig.tar.gz.

To me it also looks entirely wrong to go from 1.0.51-11
to 1:1.0.51-1. In particular since users interfaces are expected to
not show the epoch to end-users.

When you see an upgrade: 20121312 -> 1.0.51 you understand that
upstream changed their versioning scheme and you ask yourself no
questions.

When you see an upgrade 1.0.51-11 -> 1.0.51-1 then you ask yourself what's
going wrong here...

So I would also suggest to bump version to 1:1.0.51-12. Not for launchpad,
but for end users.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Colin Watson
In reply to this post by Christian T. Steigies
On Thu, Jan 25, 2018 at 08:07:52PM +0100, Christian T. Steigies wrote:
> If I can not use an epoch to start version numbers from scratch, then
> the whole implementation of epochs is broken.

Epochs were mainly intended for handling the case where upstream changed
their version numbering sequence in some way.  I don't think the goal of
"restart Debian revision numbering sequence" was one that was considered
in their design; after all the Debian maintainer can always just use
bigger integers, of which there's an indefinite supply.

I generally think of the Debian revision as being a sequence independent
of epochs.

> I doubt that I am the first to fall into this trap.

You are not.

> I think it is a ubuntu bug, so you should forward it to ubuntu.

Speaking as a Launchpad developer, this is highly unlikely to ever be
changed in Launchpad; it's one of our fundamental safety checks.  The
best that could be done in Ubuntu would be to use a different version
number, taking care to ensure that if there's ever a new upstream
release then we'll be able to get back in sync then.  (This is obviously
ugly.)

> But you showed me that snapshot.debian.org has absolutely no problem to keep
> track of every single upload by using separate directories that include the
> epoch in the directory name. Or is this a bug as well?

snapshot.debian.org doesn't aim to publish a single pool containing both
old and new versions.

It's essentially happenstance that this didn't break something in
Debian.

> > > You did not look at the files it seems.
> >
> > 1.0.51-11 contains moon-buggy_1.0.51-11.tar.gz
> > Switching to 3.0 (quilt) gives you moon-buggy_1.0.51.orig.tar.gz
> >
> > Those file names are not the same and therefore it would have been
> > fine. You absolutely do not need an epoch when switching from a native
> > package to a non-native package.
>
> But I can not upload two 1.0.51 versions with different tar files, can I?

Sure you can.  The constraint (applied by both the Debian and Ubuntu
archives, with the only material difference being how much history they
remember) is that you can't cause a file name in the pool to have
different contents from a previous upload of the same file name.

(moon-buggy_1.0.51-1.dsc has previously existed, but
moon-buggy_1.0.51.orig.tar.gz has not.)

--
Colin Watson                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Jeremy Bicha-5
In reply to this post by Raphael Hertzog-3
On Tue, Feb 6, 2018 at 3:50 AM, Raphael Hertzog <[hidden email]> wrote:
> So I would also suggest to bump version to 1:1.0.51-12. Not for launchpad,
> but for end users.

Christian, may I do an NMU now to bump the Debian revision number?

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Bug#887740: moon-buggy: Please bump the Debian part of the version number

Christian T. Steigies
Hi,
On Tue, Mar 27, 2018 at 09:06:56PM -0400, Jeremy Bicha wrote:
> On Tue, Feb 6, 2018 at 3:50 AM, Raphael Hertzog <[hidden email]> wrote:
> > So I would also suggest to bump version to 1:1.0.51-12. Not for launchpad,
> > but for end users.
>
> Christian, may I do an NMU now to bump the Debian revision number?

Has the debian policy been updated to document that skipping version numbers
is now required? Then I would do the upload myself.

But I can not stop you from doing a NMU for launchpad, I guess.

Christian