Bug#935070: [lintian] Tags are too similar

2020-01-24 Thread Felix Lechner
Control: reopen -1

> > Did you see a d/changelog that triggered the latter but not the former?
>
> Yes:packagename (upstreamversion-1~wtf1)
> followed by packagename (upstreamversion-1)
>
> (or even ~bpo10+1, when there was not the word “backport” in the
> changelog text)

Reopening for further examination.



Bug#935070: [lintian] Tags are too similar

2020-01-24 Thread Thorsten Glaser
On Fri, 24 Jan 2020, Felix Lechner wrote:

> > - latest-debian-changelog-entry-reuses-existing-version checks that
^^^

> > - latest-debian-changelog-entry-without-new-version checks that the
^^^

> As you point out, the former strips the epoch before comparing. It
> seemed to include the latter (and both tags had the same severity).

Does it?

> > PS: Personally I’m not negatively affected by removal of the latter,
> > it was always annoying for local backports, but it might have
> >saved someone else from a brown paper bag upload…
>
> Did you see a d/changelog that triggered the latter but not the former?

Yes:packagename (upstreamversion-1~wtf1)
followed by packagename (upstreamversion-1)

(or even ~bpo10+1, when there was not the word “backport” in the
changelog text)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#935070: [lintian] Tags are too similar

2020-01-24 Thread Felix Lechner
Hi Thorsten,

On Fri, Jan 24, 2020 at 6:50 AM Thorsten Glaser  wrote:
>
> - latest-debian-changelog-entry-reuses-existing-version checks that
>   the version without the epoch is never reused, for the archive and
>   snapshots to be consistent (as the epoch is not used in filenames)
>
> - latest-debian-changelog-entry-without-new-version checks that the
>   upload does not have a smaller (or equal) version number to the
>   previous upload except in backports, to ensure that it’ll be newer
>   and nobody forgot a version increment before uploading

As you point out, the former strips the epoch before comparing. It
seemed to include the latter (and both tags had the same severity).

> PS: Personally I’m not negatively affected by removal of the latter,
> it was always annoying for local backports, but it might have
>saved someone else from a brown paper bag upload…

Did you see a d/changelog that triggered the latter but not the former?

Kind regards
Felix Lechner



Bug#935070: [lintian] Tags are too similar

2020-01-24 Thread Thorsten Glaser
On Mon, 19 Aug 2019, Chris Lamb wrote:

> > latest-debian-changelog-entry-without-new-version
> > latest-debian-changelog-entry-reuses-existing-version

> I just checked that they don't have different severities which could
> have been a justification for different tags (they don't).

Umm… as I always understood it these are completely different:

- latest-debian-changelog-entry-reuses-existing-version checks that
  the version without the epoch is never reused, for the archive and
  snapshots to be consistent (as the epoch is not used in filenames)

- latest-debian-changelog-entry-without-new-version checks that the
  upload does not have a smaller (or equal) version number to the
  previous upload except in backports, to ensure that it’ll be newer
  and nobody forgot a version increment before uploading

Just wondering,
//mirabilos

PS: Personally I’m not negatively affected by removal of the latter,
it was always annoying for local backports, but it might have
saved someone else from a brown paper bag upload…
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**



Bug#935070: [lintian] Tags are too similar

2019-08-19 Thread Chris Lamb
Hi Felix,


> During the conversion of the test suite to source format 3.0, some
> packages emitted both tags
> 
> latest-debian-changelog-entry-without-new-version
> latest-debian-changelog-entry-reuses-existing-version
> 
> According to the tag descriptions, the second tag strips the epoch, if
> present, before comparing the current version with the prior one. That
> seems to be a fine point. I propose to delete the first tag and keep
> the second.

Works for me.

I just checked that they don't have different severities which could
have been a justification for different tags (they don't).


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-



Bug#935070: [lintian] Tags are too similar

2019-08-19 Thread Chris Lamb
Hi Felix,

> During the conversion of the test suite to source format 3.0, some
> packages emitted both tags
> 
> latest-debian-changelog-entry-without-new-version
> latest-debian-changelog-entry-reuses-existing-version
> 
> According to the tag descriptions, the second tag strips the epoch, if
> present, before comparing the current version with the prior one. That
> seems to be a fine point. I propose to delete the first tag and keep
> the second.

Works for me.

I just checked that they don't have different severities which could
have been a justification for different tags (they don't).


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-



Bug#935070: [lintian] Tags are too similar

2019-08-18 Thread Felix Lechner
Package: lintian
Severity: minor

Hi,

During the conversion of the test suite to source format 3.0, some
packages emitted both tags

latest-debian-changelog-entry-without-new-version
latest-debian-changelog-entry-reuses-existing-version

According to the tag descriptions, the second tag strips the epoch, if
present, before comparing the current version with the prior one. That
seems to be a fine point. I propose to delete the first tag and keep
the second. Any thoughts?

Kind regards,
Felix Lechner