[lintian] branch master updated (9155fe7 -> 3bd54c4)

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a change to branch master
in repository lintian.

  from  9155fe7   spelling: Add another correction
   new  3bd54c4   spelling: Add another correction

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 data/spelling/corrections | 1 +
 1 file changed, 1 insertion(+)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/lintian/lintian.git

[lintian] 01/01: spelling: Add another correction

[Paul Wise]

This is an automated email from the git hooks/post-receive script.

pabs pushed a commit to branch master
in repository lintian.

commit 3bd54c46d5045be2dafe65ef4624a1da34995318
Author: Paul Wise 
Date:   Tue Feb 27 08:31:17 2018 +0800

spelling: Add another correction
---
 data/spelling/corrections | 1 +
 1 file changed, 1 insertion(+)

diff --git a/data/spelling/corrections b/data/spelling/corrections
index f20c8fe..16228bd 100644
--- a/data/spelling/corrections
+++ b/data/spelling/corrections
@@ -2691,6 +2691,7 @@ opertaion||operation
 opertaions||operations
 opion||option
 opions||options
+optet||opted
 optinally||optionally
 optinal||optional
 optionaly||optionally

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/lintian/lintian.git

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Thomas Goirand]

On 02/26/2018 10:02 PM, Niels Thykier wrote:
> Thomas Goirand:
>> [...]
>>
>> And then debhelper 12 is released, people start to use it, and guess
>> what happens... :)
>>
> 
> I am prototyping an alternative in debhelper that may make this issue
> obsolete.  At the moment (since 11.1.5) you can use:
> 
>  Build-Depends: debhelper-compat (= 11)
> 
> as a replacement for:
> 
>  Build-Depends: debhelper (>= 11~)
>  and d/compat set to 11.

Oh, great improvement. I always thought that debian/compat file was kind
of too much, just to express the debhelper version... :)

Thanks for this,

Thomas Goirand (zigo)

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Niels Thykier]

Thomas Goirand:
> [...]
> 
> And then debhelper 12 is released, people start to use it, and guess
> what happens... :)
> 

I am prototyping an alternative in debhelper that may make this issue
obsolete.  At the moment (since 11.1.5) you can use:

 Build-Depends: debhelper-compat (= 11)

as a replacement for:

 Build-Depends: debhelper (>= 11~)
 and d/compat set to 11.

Note the lack of "~" in the debhelper-compat version.


It spews out tons of warnings as it is still experimental.  Nonetheless,
feedback appreciated.

Thanks,
~Niels

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Thomas Goirand]

On 02/26/2018 06:10 PM, Raphael Hertzog wrote:
> Hi,
> 
> On Mon, 26 Feb 2018, Thomas Goirand wrote:
>> Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly everyone
>> build-depends on debhelper (>= 11), making it impossible to use the 
>> backported
>> debhelper without fixing the debhelper version of the software to backport.
>>
>> It'd be nice if Lintian was warning about this, and nicely suggesting to
>> build- depend on version 11~, to allow backports.
> 
> I think it would be better to backport 11.1.4 (as 11.1.4~bpo9+1) and
> forget about this. Otherwise we will be asking developers to update this
> field for months if not years to come when in fact the problem will go
> away in a few days/weeks.
> 
> Cheers,

And then debhelper 12 is released, people start to use it, and guess
what happens... :)

So, perhaps my description wasn't broad enough, but I thought it was
obvious that we'd need something that would work forever.

BTW, to even make the scope broader, this is a general problem with
native packages and backports. We don't have the issue with non-native,
because lintian warns about the debian release number that comes after
the upstream version, which makes the problem solved. So lintian would
need to know about all native packages and suggest the addition of a ~
after the version, always (I don't think it'd be hard to embed a list of
native packages in the archive, would it?).

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#891555: marked as done (Detect and warn about debhelper >= 11 instead of 11~ b-d)

[Debian Bug Tracking System]

Your message dated Mon, 26 Feb 2018 20:49:53 +
with message-id 
<1519678193.3561389.1284192704.66cf1...@webmail.messagingengine.com>
and subject line Re: Bug#891555: Detect and warn about debhelper >= 11 instead 
of 11~ b-d
has caused the Debian Bug report #891555,
regarding Detect and warn about debhelper >= 11 instead of 11~ b-d
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
891555: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891555
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lintian
Version: 2.5.50.4
Severity: wishlist

Hi,

Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly everyone
build-depends on debhelper (>= 11), making it impossible to use the backported
debhelper without fixing the debhelper version of the software to backport.

It'd be nice if Lintian was warning about this, and nicely suggesting to build-
depend on version 11~, to allow backports.

Cheers,

Thomas Goirand (zigo)
--- End Message ---
--- Begin Message ---
tags 891555 + wontfix
thanks

Thanks for providing the background detail re. the backport.

> Just bear with it for some weeks for few packages...

Mmm, that's the most sensible approach IMHO too. Closing the bug
to match, but thanks Zigo for raising this so we can get some
explicit explanation. :)


Best wishes,

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

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Chris Lamb]

tags 891555 + wontfix
thanks

Thanks for providing the background detail re. the backport.

> Just bear with it for some weeks for few packages...

Mmm, that's the most sensible approach IMHO too. Closing the bug
to match, but thanks Zigo for raising this so we can get some
explicit explanation. :)


Best wishes,

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

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Mattia Rizzolo]

Agreed.
Just bear with it for some weeks for few packages...

On Mon, 26 Feb 2018, 6:10 p.m. Raphael Hertzog,  wrote:

> Hi,
>
> On Mon, 26 Feb 2018, Thomas Goirand wrote:
> > Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly
> everyone
> > build-depends on debhelper (>= 11), making it impossible to use the
> backported
> > debhelper without fixing the debhelper version of the software to
> backport.
> >
> > It'd be nice if Lintian was warning about this, and nicely suggesting to
> > build- depend on version 11~, to allow backports.
>
> I think it would be better to backport 11.1.4 (as 11.1.4~bpo9+1) and
> forget about this. Otherwise we will be asking developers to update this
> field for months if not years to come when in fact the problem will go
> away in a few days/weeks.
>
> 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/
>

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Raphael Hertzog]

Hi,

On Mon, 26 Feb 2018, Thomas Goirand wrote:
> Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly everyone
> build-depends on debhelper (>= 11), making it impossible to use the backported
> debhelper without fixing the debhelper version of the software to backport.
> 
> It'd be nice if Lintian was warning about this, and nicely suggesting to
> build- depend on version 11~, to allow backports.

I think it would be better to backport 11.1.4 (as 11.1.4~bpo9+1) and
forget about this. Otherwise we will be asking developers to update this
field for months if not years to come when in fact the problem will go
away in a few days/weeks.

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/

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Thomas Goirand]

Package: lintian
Version: 2.5.50.4
Severity: wishlist

Hi,

Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly everyone
build-depends on debhelper (>= 11), making it impossible to use the backported
debhelper without fixing the debhelper version of the software to backport.

It'd be nice if Lintian was warning about this, and nicely suggesting to build-
depend on version 11~, to allow backports.

Cheers,

Thomas Goirand (zigo)

Bug#660165: Source package names for R libraries (and others)

[Dylan Aïssi]

Hi Chris,

2018-02-26 15:24 GMT+01:00 Chris Lamb :
> Again, not sure what this has to do with tests or the reference to
> "recommendation" :)  (Did you reply to the right bug here?)

Yes :-) , I tried to give an example (ok a bad one) how to have the
same source and binary names for R packages could be beneficial. Or
rather how a source name beginning by with r-* could be beneficial
today (i.e. it will activate some tests).

It should probably be better to forget my previous email :-).

Best,
Dylan

Bug#660165: Source package names for R libraries (and others)

[Chris Lamb]

Hi Dylan!

> Just my two cents, all Debian R packages without r-*** source package
> name don't profit of the R autodep8 tests.

I'm a little lost I'm afraid; isn't this bug about package names,
not tests?

> So, increase the application of this "recommendation" will also
> increase number of automatic tested R packages.

Again, not sure what this has to do with tests or the reference to
"recommendation" :)  (Did you reply to the right bug here?)


Regards,

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

Bug#660165:

[Dylan Aïssi]

Hi,

Just my two cents, all Debian R packages without r-*** source package
name don't profit of the R autodep8 tests. So, increase the
application of this "recommendation" will also increase number of
automatic tested R packages.

Best,
Dylan

Bug#891231: lintian: Improve r-data-without-readme-source by comparing r-data filenames to README.source contents

[Dylan Aïssi]

Hi Chris,

2018-02-23 17:22 GMT+01:00 Chris Lamb :
>> To improve the check r-data-without-readme-source and to avoid unmaintained
>> README.source, lintian could check if the filename of all .RData files from
>> a package are referenced into the README.source.
>
> Good idea!
>
>> A simple example where it could be useful is: a new version of a package
>> contains a new binary R data file, but if the maintainer does not update
>> the README.source, lintian will no emits any tag whereas this binary is not
>> properly described.
>
> Sounds like we want something a bit more machine-readable than README.source.
> Is it legal to add fields to a DEP-5 debian/copyright for this? If not,
> I wonder if a debian/source/rdata with some field (or similar) could work?

I'm not sure if d/copyright could be a correct place for this, but
d/source/rdata sounds nice. Anyway this should be discussed with the
team (we still don't have a place for discussion #886854 excepted to
spam Debian Med and Debian Science teams). We should also probably
have a tool to generate (at least) a skeleton of this file (#890451 in
CC) to avoid a manual editing :-).

> An example from the R maintainers (especially including a violating case)
> would be extremely useful.

Let's wait and see what the team will decide before to go further.

Best,
Dylan