Bug#922544: lintian: Mass tag rename to unify naming convention

2020-05-28 Thread Felix Lechner
Hi,

On Tue, Feb 19, 2019 at 2:30 PM Chris Lamb  wrote:
>
> > As I mentioned initially, I don't think the patch is ready as is, it
> > even has syntax errors

The suggestions from this bug report will be adopted in the near future.

Kind regards
Felix Lechner



Processed: lintian: Pending rename for some shared library tags

2020-05-28 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 - wontfix
Bug #534938 [lintian] [general] tag names are inconsistent
Removed tag(s) wontfix.

-- 
534938: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534938
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#534938: lintian: Pending rename for some shared library tags

2020-05-28 Thread Felix Lechner
Control: tags -1 - wontfix

Hi,

> Probably only one prefix (shlib or shared-lib) should be used.

I agree with this sentiment. This will be implemented in the near
future. The new prefix will be shared-lib.

> I'm not sure that it's worth the disruption

The tag rename facility will make this process somewhat easier on maintainers.

Also, overrides are available in a Postgres database. Any impact can
be assessed beforehand. The number of affected overrides will be
documented.

Kind regards
Felix Lechner



Bug#924715: marked as done (lintian: Please rename the process based on what it is done (i.e. set $0))

2020-05-28 Thread Debian Bug Tracking System
Your message dated Thu, 28 May 2020 12:06:30 -0700
with message-id 

and subject line Re: Bug#924715: lintian: Please rename the process based on 
what it is done (i.e. set $0)
has caused the Debian Bug report #924715,
regarding lintian: Please rename the process based on what it is done (i.e. set 
$0)
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.)


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

Hi,

It is very useful when lintian changes its process name based on what
it is doing (in particularly when debugging things like #924714).
Though, only unpack jobs are currently the only parts that use this
feature.  Please expand it to more parts so it is easier to see what
is running amock.

Thanks,
~Niels
--- End Message ---
--- Begin Message ---
Hi,

On Sat, Mar 16, 2019 at 2:48 AM Niels Thykier  wrote:
>
> It is very useful when lintian changes its process name

Lintian only uses one process at the moment. The name currently
includes all arguments. It is set here:


https://salsa.debian.org/lintian/lintian/-/blob/master/commands/lintian.pm#L541

Parallel execution of checks does not work presently (probably due to
a limitation in IO::Async) but the branch includes statements to set
the process IDs accordingly.

Closing this bug.

Kind regards
Felix Lechner--- End Message ---


Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package

2020-05-28 Thread Dirk Eddelbuettel


On 28 May 2020 at 10:10, Dylan Aïssi wrote:
| Package: lintian
| Version: 2.77.1
| Severity: wishlist
| X-Debbugs-CC: debia...@lists.debian.org
| 
| Hi,
| 
| I just saw a R binary package (r-cran-isospec) with wrong dependencies
| (bug not yet opened). Lintian doesn't warn about a problem in its
| dependencies, so it would be cool to add a new warning (maybe
| "missing-dependency-on-r-api") to warn if any R binary packages (
| r-{cran|bioc|other}-* ) don't depend at least to a virtual r-api-*
| package.

Not a bad idea.

OTOH the way we implement the tag doesn't it get added automagically by the
r-base-core package when constructing an r-{cran,bioc,...}-* package?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package

2020-05-28 Thread Andreas Tille
Hi Dylan,

On Thu, May 28, 2020 at 10:10:54AM +0200, Dylan Aïssi wrote:
> Package: lintian
> Version: 2.77.1
> Severity: wishlist
> X-Debbugs-CC: debia...@lists.debian.org
> 
> Hi,
> 
> I just saw a R binary package (r-cran-isospec) with wrong dependencies
> (bug not yet opened). Lintian doesn't warn about a problem in its
> dependencies, so it would be cool to add a new warning (maybe
> "missing-dependency-on-r-api") to warn if any R binary packages (
> r-{cran|bioc|other}-* ) don't depend at least to a virtual r-api-*
> package.

Please go for it.

Regarding the actual package:  I'd strongly suggest to move it to
R pkg team as we did with all those packages (and when doing so also
change the source package name from isospec to r-cran-isospec).

Kind regards

Andreas. 

-- 
http://fam-tille.de



Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package

2020-05-28 Thread Dylan Aïssi
Hi,

Le jeu. 28 mai 2020 à 10:15, Dylan Aïssi  a écrit :
>
> I just saw a R binary package (r-cran-isospec) with wrong dependencies
>

Some days ago, I found another package with similar bug (r-bioc-mofa).
Already fixed in unstable but the version in testing has wrong
dependencies. This tag will help to identify these packages. With the
recent r-api-4.0 transition, it would be quite bad to leave behind
these packages.

Best,
Dylan



Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package

2020-05-28 Thread Dylan Aïssi
Package: lintian
Version: 2.77.1
Severity: wishlist
X-Debbugs-CC: debia...@lists.debian.org

Hi,

I just saw a R binary package (r-cran-isospec) with wrong dependencies
(bug not yet opened). Lintian doesn't warn about a problem in its
dependencies, so it would be cool to add a new warning (maybe
"missing-dependency-on-r-api") to warn if any R binary packages (
r-{cran|bioc|other}-* ) don't depend at least to a virtual r-api-*
package.

Thanks

Best,
Dylan