Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #84135 > unrolled thread
| Started by | Jeremy Bicha <jbicha@debian.org> |
|---|---|
| First post | 2018-02-05 16:50 +0100 |
| Last post | 2018-04-09 15:30 +0200 |
| Articles | 20 on this page of 102 — 36 participants |
Back to article view | Back to linux.debian.devel
Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@debian.org> - 2018-02-05 16:50 +0100
Re: Debian part of a version number when epoch is bumped Matt Zagrabelny <mzagrabe@d.umn.edu> - 2018-02-05 17:00 +0100
Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-05 17:10 +0100
Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-06 09:40 +0100
Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-06 14:30 +0100
Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-06 23:30 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-07 13:20 +0100
Re: Debian part of a version number when epoch is bumped Jonathan McDowell <noodles@earth.li> - 2018-02-07 11:10 +0100
Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-07 18:00 +0100
Re: Debian part of a version number when epoch is bumped Seth Arnold <seth.arnold@canonical.com> - 2018-02-08 00:50 +0100
Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-09 13:10 +0100
Re: Debian part of a version number when epoch is bumped Philipp Kern <pkern@debian.org> - 2018-02-09 13:50 +0100
Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-09 17:10 +0100
Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-09 18:20 +0100
Re: Debian part of a version number when epoch is bumped Philipp Kern <pkern@debian.org> - 2018-02-09 18:20 +0100
Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-09 18:30 +0100
Re: Debian part of a version number when epoch is bumped Philipp Kern <pkern@debian.org> - 2018-02-09 19:00 +0100
Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-09 19:20 +0100
Re: Debian part of a version number when epoch is bumped Andrey Rahmatullin <wrar@debian.org> - 2018-02-09 20:30 +0100
Re: Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@debian.org> - 2018-02-09 20:40 +0100
Re: Debian part of a version number when epoch is bumped Guillem Jover <guillem@debian.org> - 2018-02-12 03:30 +0100
Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-14 13:00 +0100
Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 14:00 +0100
Re: Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@ubuntu.com> - 2018-02-14 14:50 +0100
Re: Debian part of a version number when epoch is bumped Michael Biebl <biebl@debian.org> - 2018-02-14 16:40 +0100
Re: Debian part of a version number when epoch is bumped Henrique de Moraes Holschuh <hmh@debian.org> - 2018-02-14 15:00 +0100
Re: Debian part of a version number when epoch is bumped Lars Wirzenius <liw@liw.fi> - 2018-02-14 15:20 +0100
Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 19:00 +0100
Re: Debian part of a version number when epoch is bumped Lars Wirzenius <liw@liw.fi> - 2018-02-14 20:30 +0100
Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 21:10 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 21:20 +0100
Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-14 21:30 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 21:40 +0100
Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-14 22:00 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 22:30 +0100
Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-14 22:40 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 23:10 +0100
Re: Debian part of a version number when epoch is bumped Russ Allbery <rra@debian.org> - 2018-02-14 23:20 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 23:40 +0100
Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-15 11:20 +0100
Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-02-15 11:50 +0100
Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-15 12:30 +0100
Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 13:30 +0100
Re: Debian part of a version number when epoch is bumped Vincent Ladeuil <v.ladeuil+debian@free.fr> - 2018-02-15 15:10 +0100
Re: Debian part of a version number when epoch is bumped Guillem Jover <guillem@debian.org> - 2018-02-16 03:10 +0100
Re: Debian part of a version number when epoch is bumped Dimitri John Ledkov <xnox@debian.org> - 2018-03-12 12:40 +0100
Re: Debian part of a version number when epoch is bumped Cédric Boutillier <boutil@debian.org> - 2018-03-12 18:50 +0100
Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-02-15 01:00 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-14 21:50 +0100
Re: Debian part of a version number when epoch is bumped Matt Zagrabelny <mzagrabe@d.umn.edu> - 2018-02-14 21:50 +0100
Re: Debian part of a version number when epoch is bumped Adam Borowski <kilobyte@angband.pl> - 2018-02-15 08:50 +0100
Re: Debian part of a version number when epoch is bumped gregor herrmann <gregoa@debian.org> - 2018-02-15 09:00 +0100
Re: Debian part of a version number when epoch is bumped Adam Borowski <kilobyte@angband.pl> - 2018-02-15 09:30 +0100
Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 11:20 +0100
Re: Debian part of a version number when epoch is bumped gregor herrmann <gregoa@debian.org> - 2018-02-15 13:10 +0100
Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 13:40 +0100
Re: Debian part of a version number when epoch is bumped Vincent Bernat <bernat@debian.org> - 2018-02-15 14:20 +0100
Re: Debian part of a version number when epoch is bumped Thibaut Paumard <thibaut@debian.org> - 2018-02-15 15:30 +0100
Re: Debian part of a version number when epoch is bumped Michael Stone <mstone@debian.org> - 2018-02-15 14:20 +0100
Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-14 15:50 +0100
Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-14 16:10 +0100
Re: Debian part of a version number when epoch is bumped Andrey Rahmatullin <wrar@debian.org> - 2018-02-14 16:10 +0100
Re: Debian part of a version number when epoch is bumped Michael Biebl <biebl@debian.org> - 2018-02-14 16:30 +0100
Re: Debian part of a version number when epoch is bumped Andrey Rahmatullin <wrar@debian.org> - 2018-02-14 17:10 +0100
Re: Debian part of a version number when epoch is bumped Marc Haber <mh+debian-devel@zugschlus.de> - 2018-02-14 18:30 +0100
Re: Debian part of a version number when epoch is bumped Wouter Verhelst <wouter@debian.org> - 2018-02-15 11:20 +0100
Re: Debian part of a version number when epoch is bumped Steve McIntyre <steve@einval.com> - 2018-02-14 15:10 +0100
Re: Debian part of a version number when epoch is bumped Ian Campbell <ijc@debian.org> - 2018-02-14 15:50 +0100
Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-09 19:40 +0100
Re: Debian part of a version number when epoch is bumped Guillem Jover <guillem@debian.org> - 2018-02-12 03:20 +0100
Re: Debian part of a version number when epoch is bumped Steve McIntyre <steve@einval.com> - 2018-02-06 14:40 +0100
Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-06 15:00 +0100
Re: Debian part of a version number when epoch is bumped Lars Wirzenius <liw@liw.fi> - 2018-02-06 14:40 +0100
Re: Debian part of a version number when epoch is bumped Holger Levsen <holger@layer-acht.org> - 2018-02-06 15:20 +0100
Re: Debian part of a version number when epoch is bumped Jonathan Dowland <jmtd@debian.org> - 2018-02-12 09:40 +0100
Re: Debian part of a version number when epoch is bumped Jonathan Dowland <jmtd@debian.org> - 2018-02-06 14:40 +0100
Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-02-06 15:00 +0100
Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-02-06 16:20 +0100
Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-02-07 14:00 +0100
Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-02-07 15:00 +0100
Re: Debian part of a version number when epoch is bumped Ian Campbell <ijc@debian.org> - 2018-02-08 11:20 +0100
Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-08 12:00 +0100
Re: Debian part of a version number when epoch is bumped Ian Campbell <ijc@debian.org> - 2018-02-09 21:00 +0100
Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-02-09 23:10 +0100
Re: Debian part of a version number when epoch is bumped Colin Watson <cjwatson@debian.org> - 2018-02-07 16:40 +0100
Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-07 11:00 +0100
Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-02-07 11:50 +0100
Re: Debian part of a version number when epoch is bumped Raphael Hertzog <hertzog@debian.org> - 2018-02-07 12:30 +0100
Re: Debian part of a version number when epoch is bumped Jeremy Bicha <jbicha@debian.org> - 2018-03-28 22:20 +0200
Re: Debian part of a version number when epoch is bumped Chris Lamb <lamby@debian.org> - 2018-03-29 00:00 +0200
Re: Debian part of a version number when epoch is bumped Adam Borowski <kilobyte@angband.pl> - 2018-03-29 00:30 +0200
Re: Debian part of a version number when epoch is bumped Mattia Rizzolo <mattia@debian.org> - 2018-03-29 01:00 +0200
Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-03-29 19:10 +0200
Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-03-29 20:00 +0200
Re: Debian part of a version number when epoch is bumped Adrian Bunk <bunk@debian.org> - 2018-03-30 13:30 +0200
Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-04-02 20:40 +0200
Re: Debian part of a version number when epoch is bumped Adrian Bunk <bunk@debian.org> - 2018-04-02 21:10 +0200
Re: Debian part of a version number when epoch is bumped Simon McVittie <smcv@debian.org> - 2018-04-02 21:50 +0200
Re: Debian part of a version number when epoch is bumped The Wanderer <wanderer@fastmail.fm> - 2018-04-03 05:10 +0200
Re: Debian part of a version number when epoch is bumped James McCoy <jamessan@debian.org> - 2018-04-03 05:20 +0200
Re: Debian part of a version number when epoch is bumped "Christian T. Steigies" <cts@debian.org> - 2018-04-07 20:10 +0200
Re: Debian part of a version number when epoch is bumped Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-04-09 15:30 +0200
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Ian Campbell <ijc@debian.org> |
|---|---|
| Date | 2018-02-08 11:20 +0100 |
| Message-ID | <vgRt7-26F-5@gated-at.bofh.it> |
| In reply to | #84164 |
On Wed, 2018-02-07 at 13:51 +0000, Ian Jackson wrote: > I suggest something like this wording to replace the following > paragraphs about the epoch: > > Epochs exist to cope with changes to the upstream version numbering > scheme, and some other difficult cases. The epoch is a powerful > tool, but increasing the epoch it has downsides and should be > avoided when possible. > > If you think you need to increase the epoch for a package, please > consult debian-devel first. Is it also the case that today we implicitly require that all versions used in a source package name's history are unique even once the epochs are stripped off (e.g. a given $upstream-$debianrev must be unique and not differ only in the epoch)? If so then should policy say that explicitly and/or should lintian check/warn if it isn't? Ian.
[toc] | [prev] | [next] | [standalone]
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Date | 2018-02-08 12:00 +0100 |
| Message-ID | <vgS5P-2mG-13@gated-at.bofh.it> |
| In reply to | #84175 |
On Thu, 08 Feb 2018, Ian Campbell wrote: > Is it also the case that today we implicitly require that all versions > used in a source package name's history are unique even once the epochs > are stripped off (e.g. a given $upstream-$debianrev must be unique and > not differ only in the epoch)? If so then should policy say that > explicitly and/or should lintian check/warn if it isn't? Yes. Please file bugs for this. :) Note however that such a lintian check should not consider changelog entries indicating another source package name. 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/
[toc] | [prev] | [next] | [standalone]
| From | Ian Campbell <ijc@debian.org> |
|---|---|
| Date | 2018-02-09 21:00 +0100 |
| Message-ID | <vhmZX-84A-1@gated-at.bofh.it> |
| In reply to | #84177 |
On Thu, 2018-02-08 at 11:50 +0100, Raphael Hertzog wrote: > On Thu, 08 Feb 2018, Ian Campbell wrote: > > Is it also the case that today we implicitly require that all > versions > > used in a source package name's history are unique even once the > epochs > > are stripped off (e.g. a given $upstream-$debianrev must be unique > and > > not differ only in the epoch)? If so then should policy say that > > explicitly and/or should lintian check/warn if it isn't? > > Yes. Please file bugs for this. :) > > Note however that such a lintian check should not consider changelog > entries indicating another source package name. Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889991 Thanks, Ian.
[toc] | [prev] | [next] | [standalone]
| From | Chris Lamb <lamby@debian.org> |
|---|---|
| Date | 2018-02-09 23:10 +0100 |
| Message-ID | <vhp1L-1zk-3@gated-at.bofh.it> |
| In reply to | #84201 |
Hi Ian,
> > Yes. Please file bugs for this. :)
> >
> > Note however that such a lintian check should not consider changelog
> > entries indicating another source package name.
>
> Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889991
Done: https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=1cadac3c48bf361c2894d56f2ef6fdf28bc32e9e
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org / chris-lamb.co.uk
`-
[toc] | [prev] | [next] | [standalone]
| From | Colin Watson <cjwatson@debian.org> |
|---|---|
| Date | 2018-02-07 16:40 +0100 |
| Message-ID | <vgzZf-703-1@gated-at.bofh.it> |
| In reply to | #84159 |
On Wed, Feb 07, 2018 at 01:57:03PM +0100, Christian T. Steigies wrote: > I did not know that I can upload an orig.tar.* with a debian-version > >1, nor did I know that I was supposed to workaround bugs in Ubuntu or > filesystems that can not handle epochs. Once again, I dispute that this is a bug in Ubuntu. We just have somewhat more stringent checks for duplicate file names, which any other derivative or indeed dak itself might easily also have (indeed, dak does check exactly this kind of thing, but has a shorter memory). > If this becomes policy, I guess I need to skip 10 debian versions (probably > purging my last upload from the archives is not possible). How should I do > that correctly, without attracting another bug report? Should I just skip > debian version -2 to -11, should they be mentioned in the changelog but > never uploaded, or what it the accepted solution? Simply jumping back to -12 seems perfectly reasonable; there's no need for fake changelog entries. There's no requirement to increment versions one by one. -- Colin Watson [cjwatson@debian.org]
[toc] | [prev] | [next] | [standalone]
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Date | 2018-02-07 11:00 +0100 |
| Message-ID | <vguGe-3ur-11@gated-at.bofh.it> |
| In reply to | #84151 |
Hi, On Tue, 06 Feb 2018, Chris Lamb wrote: > (The long description could make more scary noises about bumping, > however.) And include an explanation of when it's appropriate or not, and of ways to avoid it altogether... Please someone do it and add that to the auto-reject list. And also add a tag which complains even more loudly when you bump the epoch and when the upstream version does not go backwards. i.e. switching from 1:X to 2:Y would complain if Y > X. 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/
[toc] | [prev] | [next] | [standalone]
| From | Chris Lamb <lamby@debian.org> |
|---|---|
| Date | 2018-02-07 11:50 +0100 |
| Message-ID | <vgvsB-3ZK-5@gated-at.bofh.it> |
| In reply to | #84162 |
Hi Raphael,
> [..]
Could you please file bugs for these issues? Many thanks.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org / chris-lamb.co.uk
`-
[toc] | [prev] | [next] | [standalone]
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Date | 2018-02-07 12:30 +0100 |
| Message-ID | <vgw5j-4tr-7@gated-at.bofh.it> |
| In reply to | #84166 |
Hi, On Wed, 07 Feb 2018, Chris Lamb wrote: > Could you please file bugs for these issues? Many thanks. Done: - https://bugs.debian.org/889814 Improve long description of epoch-change-without-comment => Additional suggestions to put in the long description are welcome. - https://bugs.debian.org/889816 Complain when epoch has been bumped but upstream version did not go backwards 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/
[toc] | [prev] | [next] | [standalone]
| From | Jeremy Bicha <jbicha@debian.org> |
|---|---|
| Date | 2018-03-28 22:20 +0200 |
| Message-ID | <vypI5-7Lt-9@gated-at.bofh.it> |
| In reply to | #84137 |
On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo <mattia@debian.org> wrote: > Please don't consider the Debian Policy like a stick. Or a all-kwowing > never-wrong oracle. Well the maintainer refuses to make the minor change I requested. See the latest comments at https://bugs.debian.org/887740 I wish Debian had some form of informal conflict resolution besides the Tech Committee. Thanks, Jeremy Bicha
[toc] | [prev] | [next] | [standalone]
| From | Chris Lamb <lamby@debian.org> |
|---|---|
| Date | 2018-03-29 00:00 +0200 |
| Message-ID | <vyrgR-dV-5@gated-at.bofh.it> |
| In reply to | #85185 |
Hi Jeremy,
> I wish Debian had some form of informal conflict resolution besides
> the Tech Committee.
As DPL, I am always available to make an attempt at such resolutions.
If you wish, please contact me via leader@debian.org.
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org / chris-lamb.co.uk
`-
[toc] | [prev] | [next] | [standalone]
| From | Adam Borowski <kilobyte@angband.pl> |
|---|---|
| Date | 2018-03-29 00:30 +0200 |
| Message-ID | <vyrJT-Da-5@gated-at.bofh.it> |
| In reply to | #85185 |
On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote: > On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo <mattia@debian.org> wrote: > > Please don't consider the Debian Policy like a stick. Or a all-kwowing > > never-wrong oracle. > > Well the maintainer refuses to make the minor change I requested. See > the latest comments at > https://bugs.debian.org/887740 > > I wish Debian had some form of informal conflict resolution besides > the Tech Committee. The maintainer's request here can be acted upon. While in general I agree that a light-weight means of conflict resolution would be nice, this issue keeps returning, thus it probably is worthy of being mentioned in the Policy. This is https://bugs.debian.org/881431, to which I just proposed a wording. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ When I visited the US a couple decades ago, Hillary molested and ⣾⠁⢰⠒⠀⣿⡁ groped me. You don't believe? Well, the burden of proof is on you! ⢿⡄⠘⠷⠚⠋⠀ Flooding a douche with obviously false accusations makes your words ⠈⠳⣄⠀⠀⠀⠀ dubious even when they happen to be true.
[toc] | [prev] | [next] | [standalone]
| From | Mattia Rizzolo <mattia@debian.org> |
|---|---|
| Date | 2018-03-29 01:00 +0200 |
| Message-ID | <vyscV-Og-1@gated-at.bofh.it> |
| In reply to | #85185 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote:
> On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo <mattia@debian.org> wrote:
> > Please don't consider the Debian Policy like a stick. Or a all-kwowing
> > never-wrong oracle.
>
> Well the maintainer refuses to make the minor change I requested. See
> the latest comments at
> https://bugs.debian.org/887740
Right.
Ultimately, in Debian the maintianer of a package decides what to do to
that package. If a maintainer refuse to land a change you are asking,
and you fail to "sell" your change, that it: that change won't be
applied, period.
> I wish Debian had some form of informal conflict resolution besides
> the Tech Committee.
As Chris noted, one of the (informal?) jobs of the DPL is to facilitate
mediation.
TBH, I don't think here you need any kind of mediation, it's clear the
maintainer doesn't like your proposal.
I recommend you just find a way to live with it (and I don't think
doing no-change merges in ubuntu to workaround this issue are something
too hard to do…)
To that goeal I just uploaded src:moon-buggy 1:1.0.51-1ubuntu1 to
bionic: https://launchpad.net/ubuntu/+source/moon-buggy/1:1.0.51-1ubuntu1
it should appear in MoM just fine, and it hardly brings any relevant
extra work to the MOTUs… (if you are seeking to lower the delta between
debian and ubuntu, there are bigger fishes to fry…).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
[toc] | [prev] | [next] | [standalone]
| From | "Christian T. Steigies" <cts@debian.org> |
|---|---|
| Date | 2018-03-29 19:10 +0200 |
| Message-ID | <vyJdL-3IT-5@gated-at.bofh.it> |
| In reply to | #85185 |
On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote: > On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo <mattia@debian.org> wrote: > > Please don't consider the Debian Policy like a stick. Or a all-kwowing > > never-wrong oracle. > > Well the maintainer refuses to make the minor change I requested. See > the latest comments at > https://bugs.debian.org/887740 > > I wish Debian had some form of informal conflict resolution besides > the Tech Committee. I am really amazed that you are making such a big deal about this package. You still have not convinced me that I did anything wrong with the version number and you keep ignoring my request for propper official documentation how to use and not use an epoch. Maybe you all can read between the lines of the policy or just magically know how this was intended. But I can not read your mind and I assume the majority of regular DDs can neither. If it is incorrect to start with the debian revision from scratch after an epoch, please document it where a regular person can easily find it, especially if I am not the first person to fall into this trap. I do not consider this bug report a suitable place for that (one of my packages has been used before in an Ubuntu packaging manual to show how to report a bug and nobody told me about this nor the "bug" until after years somebody finally reported the bug, is this the plan for moon-buggy and epochs?). I think the TC has more important problems to solve. If you want to NMU the package, go ahead. I am not going to upload it with a version number which I think is wrong, but I am not stopping you if you want to do that upload. Or we just drop it from Debian, upstream development has stopped years ago. But that does not fix the problem with lacking documentation... Christian
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2018-03-29 20:00 +0200 |
| Message-ID | <vyK09-3Z3-1@gated-at.bofh.it> |
| In reply to | #85222 |
On Wed, 28 Mar 2018 at 23:39:58 +0200, Christian T. Steigies wrote:
> propper official documentation how to use and not use an epoch
This appears to be in progress. In response to previous discussion of
this same issue, a dpkg maintainer wrote about this a few weeks ago:
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F
Policy wording has also been proposed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891216
> If it
> is incorrect to start with the debian revision from scratch after an epoch,
> please document it where a regular person can easily find it
This is also in progress:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881431
> I think the TC has more important problems to solve.
Jeremy's mention of the TC was in the context of wishing there was a
dispute-resolution mechanism less "heavy" than escalating to the TC,
so it seems you and Jeremy are in agreement there.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Adrian Bunk <bunk@debian.org> |
|---|---|
| Date | 2018-03-30 13:30 +0200 |
| Message-ID | <vz0oi-6gt-9@gated-at.bofh.it> |
| In reply to | #85222 |
On Wed, Mar 28, 2018 at 11:39:58PM +0200, Christian T. Steigies wrote:
>...
> You still have not convinced me that I did anything wrong with the version
> number and you keep ignoring my request for propper official documentation
> how to use and not use an epoch. Maybe you all can read between the lines
> of the policy or just magically know how this was intended. But I can not
> read your mind and I assume the majority of regular DDs can neither. If it
> is incorrect to start with the debian revision from scratch after an epoch,
> please document it where a regular person can easily find it, especially if
> I am not the first person to fall into this trap. I do not consider this
> bug report a suitable place for that (one of my packages has been used
> before in an Ubuntu packaging manual to show how to report a bug and nobody
> told me about this nor the "bug" until after years somebody finally reported
> the bug, is this the plan for moon-buggy and epochs?).
>...
There are two problems here.
The first is the use of an epoch in a situation where it shouldn't be used.
The actual "trap" is when a maintainer used an epoch in such a situation.
Once introduced in a package an epoch cannot ever be undone, so all that
can be done on that is to make it clearer that it is wrong to use an
epoch in such cases.
The second problem is about filename overlap after incorrect epoch usage.
It is important to understand that this is only relevant for cases where
an epoch was used where it shouldn't have been:
When an epoch is used as intended for a change in the upstream version
numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in
version numbers.
Launchpad gave an error on that, and this is better than the silent
breakage in Debian of the assumption that no filename is ever used twice
in Debian. I would consider it a bug in dak that it doesn't know about
all versions and filenames that ever existed in Debian.
It would be wrong to document in Debian policy that skipping Debian
revisions is required in such cases, since the only case where this
second problem can happen is when a maintainer used an epoch in a
situation where it shouldn't be used (first problem).[1]
For the future it should be documented better that using an epoch is
wrong in such cases, but for past incorrect epoch usage all that can
be done is to limit the damage.
Things that cannot be undone for moon-buggy:
- the epoch
- two files moon-buggy_1.0.51-1.dsc exist in Debian,
with different contents [2]
What can be done for moon-buggy is to use a Debian revision that doesn't
result in filenames that are duplicates with pre-epoch packages.
> Christian
cu
Adrian
[1] in theory upstream could also create such a situation with frequent
changes in the versioning scheme, but that's not a problem in practice
[2] not in Ubuntu, where this problem was caught
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
[toc] | [prev] | [next] | [standalone]
| From | "Christian T. Steigies" <cts@debian.org> |
|---|---|
| Date | 2018-04-02 20:40 +0200 |
| Message-ID | <vAcx4-54A-3@gated-at.bofh.it> |
| In reply to | #85247 |
Moin, On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote: > > There are two problems here. > > The first is the use of an epoch in a situation where it shouldn't be used. > > The actual "trap" is when a maintainer used an epoch in such a situation. > > Once introduced in a package an epoch cannot ever be undone, so all that > can be done on that is to make it clearer that it is wrong to use an > epoch in such cases. I don't understand why everybody is so afraid of an epoch, but ok. > The second problem is about filename overlap after incorrect epoch usage. So the epoch is not really part of the version number, it is just there for "sorting"? > It is important to understand that this is only relevant for cases where > an epoch was used where it shouldn't have been: > When an epoch is used as intended for a change in the upstream version > numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in > version numbers. > > Launchpad gave an error on that, and this is better than the silent > breakage in Debian of the assumption that no filename is ever used twice > in Debian. I would consider it a bug in dak that it doesn't know about > all versions and filenames that ever existed in Debian. ok > It would be wrong to document in Debian policy that skipping Debian > revisions is required in such cases, since the only case where this > second problem can happen is when a maintainer used an epoch in a > situation where it shouldn't be used (first problem).[1] > > For the future it should be documented better that using an epoch is > wrong in such cases, but for past incorrect epoch usage all that can > be done is to limit the damage. If this can't go into policy, then I hope it will go into the wiki or a packaging best-practices or so. > Things that cannot be undone for moon-buggy: > - the epoch > - two files moon-buggy_1.0.51-1.dsc exist in Debian, > with different contents [2] > > What can be done for moon-buggy is to use a Debian revision that doesn't > result in filenames that are duplicates with pre-epoch packages. So what should I have done intially and what should I do now? I should have uploaded the package as 1.0.51-12 even though I uploaded a (new) orig.tar.gz? Now I should upload it as 1:1.0.51-12 and be done with it? No renaming of the orig.tar to 1.0.51+really1.0.51 neccessary? thanks, Christian
[toc] | [prev] | [next] | [standalone]
| From | Adrian Bunk <bunk@debian.org> |
|---|---|
| Date | 2018-04-02 21:10 +0200 |
| Message-ID | <vAd06-5v7-17@gated-at.bofh.it> |
| In reply to | #85276 |
On Mon, Apr 02, 2018 at 08:30:54PM +0200, Christian T. Steigies wrote:
> Moin,
Hi,
> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> >
> > There are two problems here.
> >
> > The first is the use of an epoch in a situation where it shouldn't be used.
> >
> > The actual "trap" is when a maintainer used an epoch in such a situation.
> >
> > Once introduced in a package an epoch cannot ever be undone, so all that
> > can be done on that is to make it clearer that it is wrong to use an
> > epoch in such cases.
>
> I don't understand why everybody is so afraid of an epoch, but ok.
not really afraid. "optically not nice", "slightly confusing" and
"irreversible" are the words I would use.
> > The second problem is about filename overlap after incorrect epoch usage.
>
> So the epoch is not really part of the version number, it is just there for
> "sorting"?
It is somehow part of the version number, but not in the filenames.
This is not a problem when an epoch is used for a change in the upstream
version numbering scheme.
> > It is important to understand that this is only relevant for cases where
> > an epoch was used where it shouldn't have been:
> > When an epoch is used as intended for a change in the upstream version
> > numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in
> > version numbers.
> >
> > Launchpad gave an error on that, and this is better than the silent
> > breakage in Debian of the assumption that no filename is ever used twice
> > in Debian. I would consider it a bug in dak that it doesn't know about
> > all versions and filenames that ever existed in Debian.
>
> ok
>
> > It would be wrong to document in Debian policy that skipping Debian
> > revisions is required in such cases, since the only case where this
> > second problem can happen is when a maintainer used an epoch in a
> > situation where it shouldn't be used (first problem).[1]
> >
> > For the future it should be documented better that using an epoch is
> > wrong in such cases, but for past incorrect epoch usage all that can
> > be done is to limit the damage.
>
> If this can't go into policy, then I hope it will go into the wiki or a
> packaging best-practices or so.
>
> > Things that cannot be undone for moon-buggy:
> > - the epoch
> > - two files moon-buggy_1.0.51-1.dsc exist in Debian,
> > with different contents [2]
> >
> > What can be done for moon-buggy is to use a Debian revision that doesn't
> > result in filenames that are duplicates with pre-epoch packages.
>
> So what should I have done intially and what should I do now?
>
> I should have uploaded the package as 1.0.51-12 even though I uploaded a
> (new) orig.tar.gz?
Yes.
As far as I understand it a mistake happened back in 2006 when a new
upstream version was uploaded as .tar.gz instead of .orig.tar.gz and
.diff.gz.
Correcting this mistake was correct, but it did not require an epoch.
> Now I should upload it as 1:1.0.51-12 and be done with it?
I don't see a reason for touching the 1:1.0.51-1 changelog entry,
files like moon-buggy_1.0.51-1.dsc or moon-buggy_1.0.51-1_amd64.deb
are no longer unique in the history of Debian and this cannot be
undone.
Uploading with a new changelog entry for 1:1.0.51-12 added on top
of the current 1:1.0.51-1 entry is the best option.
> No renaming of the orig.tar to 1.0.51+really1.0.51 neccessary?
This is not necessary, unless I miss something there was never before
a (different) moon-buggy_1.0.51.orig.tar.gz in Debian.
> thanks,
> Christian
Thanks
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2018-04-02 21:50 +0200 |
| Message-ID | <vAdCN-5KL-1@gated-at.bofh.it> |
| In reply to | #85276 |
On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
> I don't understand why everybody is so afraid of an epoch, but ok.
It's a source of confusion (and confusing side-effects) that, once added,
can never be removed, however many upstream releases might happen.
> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> > The second problem is about filename overlap after incorrect epoch usage.
>
> So the epoch is not really part of the version number, it is just there for
> "sorting"?
Sort of. It appears in the form of the version number that's in most
places, but not in canonical filenames. Conceptually, it's part of the
Debian package version but not part of the upstream version.
> > What can be done for moon-buggy is to use a Debian revision that doesn't
> > result in filenames that are duplicates with pre-epoch packages.
>
> So what should I have done intially and what should I do now?
>
> I should have uploaded the package as 1.0.51-12 even though I uploaded a
> (new) orig.tar.gz?
A recap of what happened, for those who might have lost track:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887740#10
> 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.
The newest version of the old tar-in-tar packaging can be seen here:
https://sources.debian.org/src/moon-buggy/1.0.51-11/
What I would personally have done *then*, from that starting point, would
be to bump the version to 1.0.51+repack, or maybe 1.0.51+upstream if
the new orig tarball was something that the upstream developer released,
or something similar, then package and upload revision 1 of that. That
would have been fine - no epoch needed.
However, because you previously maintained this as a native package,
there has been no collision for the filename of the orig.tar.gz, because
before the epoch was added there *was* no orig.tar.gz; and you've already
paid the maintenance cost of having an epoch, so you might as well benefit
from it. So what I'd advise *now* would be to increase the revision to 12
and carry on from there.
smcv
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2018-04-03 05:10 +0200 |
| Message-ID | <vAkuB-26M-3@gated-at.bofh.it> |
| In reply to | #85278 |
[Multipart message — attachments visible in raw view] — view raw
On 2018-04-02 at 15:41, Simon McVittie wrote: > On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote: > >> I don't understand why everybody is so afraid of an epoch, but ok. > > It's a source of confusion (and confusing side-effects) that, once > added, can never be removed, however many upstream releases might > happen. I thought that in theory, if the upstream version later increases to the point where it would sort above the with-an-epoch version (whether because it's a date-based version and new versions keep coming out all the way into the next millennium, or because the upstream version scheme changes again, or whatever else), the epoch could potentially be dropped without introducing issues. Is that wrong? If so, I'd be interested to see an example of a case where problems would result, because while I can intellectually conceive of there being such I so far haven't been able to think of any. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | James McCoy <jamessan@debian.org> |
|---|---|
| Date | 2018-04-03 05:20 +0200 |
| Message-ID | <vAkEh-2ag-1@gated-at.bofh.it> |
| In reply to | #85279 |
On Mon, Apr 02, 2018 at 11:01:30PM -0400, The Wanderer wrote: > On 2018-04-02 at 15:41, Simon McVittie wrote: > > > On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote: > > > >> I don't understand why everybody is so afraid of an epoch, but ok. > > > > It's a source of confusion (and confusing side-effects) that, once > > added, can never be removed, however many upstream releases might > > happen. > > I thought that in theory, if the upstream version later increases to the > point where it would sort above the with-an-epoch version (whether > because it's a date-based version and new versions keep coming out all > the way into the next millennium, or because the upstream version scheme > changes again, or whatever else), the epoch could potentially be dropped > without introducing issues. Is that wrong? Yes. There's an implicit 0 epoch in any version that doesn't have an explicit epoch. Therefore, it doesn't matter what contortions the upstream version does. Returning to an implicit 0 epoch would sort lower than the previous explicit epoch. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | linux.debian.devel
csiph-web