Bug#801717: lintian: False positive for source-is-missing

2015-10-14 Thread Neil Williams 
On Wed, 14 Oct 2015 11:17:40 +0800
Paul Wise  wrote:

> On Tue, 13 Oct 2015 20:48:48 +0100 Neil Williams wrote:
> 
> > lava_server/htdocs/js/jquery.validate.js
> > lava_server/lava-server/js/jquery.validate.js  
> 
> Are you sure these files are source for the jQuery validation plugin?

The plugin which isn't packaged (cannot be packaged currently if it
does need grunt) and which I cannot therefore use?

These js files are effectively part of the source code of lava-server,
not the JQuery upstream - lintian should not be making any decisions
based on things which are not in the archive. 

> Looking at the upstream git repo for the jQuery validation plugin the
> source is a bunch of separate files instead of just one file.
> 
> https://github.com/jzaefferer/jquery-validation/

This isn't packaged, therefore, lintian cannot know about them.

Anything lintian has to say about things which are not packaged for
Debian can only be under the --pedantic classification.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgppROMN3mxYN.pgp
Description: OpenPGP digital signature

Bug#801717: lintian: False positive for source-is-missing

2015-10-14 Thread Paul Wise 
On Wed, 2015-10-14 at 08:52 +0100, Neil Williams wrote:

> cannot be packaged currently if it does need grunt

Sure they can, just package build-deps first, like Debian always
does.


> These js files are effectively part of the source code of lava-server,
> not the JQuery upstream

They are embedded code copies of a separate project. That separate
project has build artefacts and someone has copied them into lava-
server. Those build artefacts should be built from source and packaged
into libjs-jquery-validation instead. This is like copying an ELF
binary of a parser library into a project because bison isn't packaged.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#801760: [checks/manpages] manpage-named-after-build-path won't trigger for packages built in sbuild

2015-10-14 Thread Jakub Wilk 

* Mattia Rizzolo , 2015-10-14, 17:28:

I wonder if just using
   $file =~ m/_build_/
instaead of
   $file =~ m/_build_buildd/
is sane enough.


There are legitimate manpages that have "_build_" in their name, for 
example:

/usr/share/man/man1/slonik_build_env.1.gz (in slony1-2-bin)

This should be okay:

$file =~ m{/_build_}

--
Jakub Wilk

Bug#801760: [checks/manpages] manpage-named-after-build-path won't trigger for packages built in sbuild

2015-10-14 Thread Jakub Wilk 

Package: lintian
Version: 2.5.38

This code was meant to catch bugs like #713883:

   if ($file =~ m/_build_buildd/ or $file =~ /_tmp_buildd/) {
   tag 'manpage-named-after-build-path', $file;
   }

But sbuild builds stuff in /build/$PACKAGE-$RANDOMSTRING, so this regexp 
wouldn't match anything, unless the source package name starts with 
"buildd".


(sbuild in buildd mode used to use /build/buildd-$PACKAGE-$RANDOMSTRING, 
but AFAICS it now uses "buildd-"less paths.)


--
Jakub Wilk

Bug#801482: The name of a programme, from which an error message comes, is missing in the lintian's message

2015-10-14 Thread Jakub Wilk 

Control: severity -1 minor
Control: tags -1 + patch


Severity: important


This is definitely not "a bug which has a major effect on the usability 
of a package".


* Bjarni Ingi Gislason , 2015-10-11, 00:41:

W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian-info.1.gz  
line 5: TMPDIR: unbound variable
W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian.1.gz  line 
5: TMPDIR: unbound variable

  * What outcome did you expect instead?

 The name of the programme where the error occurred.


Well, the tag name says "errors-from-man" and the error occurred in man, 
so everything is clear.



 This is important to reduce the time figuring out from where it came.


Can you think of a more realistic scenario where the user would be 
genuinely confused about origin of the captured error?


Anyway, the attached patch seems to address you concerns. When it's 
applied, you get:


W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian-info.1.gz 
/path/to/man: line 5: TMPDIR: unbound variable
W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian.1.gz 
/path/to/man: line 5: TMPDIR: unbound variable

Hopefully the patch doesn't break anything else.

How will (the cause of) this programming error be documented, so people 
(can) learn from it and do not repeat it themselves?


As usually, in the bug log and in the changelog. (But this condescending 
tone is not helpful...)


--
Jakub Wilk
diff --git a/checks/manpages.pm b/checks/manpages.pm
--- a/checks/manpages.pm
+++ b/checks/manpages.pm
@@ -401,7 +401,7 @@
 # ignore common undefined macros from pod2man << Perl 5.10
 next if /warning: (?:macro )?\`(?:Tr|IX)\' not defined/;
 chomp;
-s/^[^:]+://o;
+s/^\Q://o;
 tag 'manpage-has-errors-from-man', $file, $_;
 last;
 }

Processed: Re: Bug#801482: The name of a programme, from which an error message comes, is missing in the lintian's message

2015-10-14 Thread Debian Bug Tracking System 
Processing control commands:

> severity -1 minor
Bug #801482 [lintian] The name of a programme, from which an error message 
comes, is missing in the lintian's message
Severity set to 'minor' from 'important'
> tags -1 + patch
Bug #801482 [lintian] The name of a programme, from which an error message 
comes, is missing in the lintian's message
Added tag(s) patch.

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

Bug#801760: [checks/manpages] manpage-named-after-build-path won't trigger for packages built in sbuild

2015-10-14 Thread Mattia Rizzolo 
On Wed, Oct 14, 2015 at 12:30:27PM +0200, Jakub Wilk wrote:
> Package: lintian
> Version: 2.5.38
> 
> This code was meant to catch bugs like #713883:
> 
>if ($file =~ m/_build_buildd/ or $file =~ /_tmp_buildd/) {
>tag 'manpage-named-after-build-path', $file;
>}
> 
> But sbuild builds stuff in /build/$PACKAGE-$RANDOMSTRING, so this regexp
> wouldn't match anything, unless the source package name starts with
> "buildd".

Also, pbuilder now easily allow changing the build path, and defaults
to /build/ (with inside the .dsc, .orig, etc and a $pkg-$ver directory,
as created by dpkg).

I wonder if just using
$file =~ m/_build_/
instaead of
$file =~ m/_build_buildd/
is sane enough.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#801483: The environmental variable 'TMPDIR' is made unset by "lintian"

2015-10-14 Thread Jakub Wilk 

* Bjarni Ingi Gislason , 2015-10-11, 01:52:

  * What outcome did you expect instead?

 That the environmental variable "TMPDIR" retains its value.


Lintian sanitizes environment when calling external programs. (See the 
clean_env function in lib/Lintian/Util.pm). It only keeps PATH and sets 
LC_ALL to C or C.UTF-8.


We could certainly add TMPDIR to the whitelist.

But why is this a problem in practice? Does man, or any other external 
command Lintian calls, create temporary files?


--
Jakub Wilk

Bug#801482: The name of a programme, from which an error message comes, is missing in the lintian's message

2015-10-14 Thread Adam D. Barratt 

On 2015-10-14 12:22, Jakub Wilk wrote:
[...]

* Bjarni Ingi Gislason , 2015-10-11, 00:41:

[...]
How will (the cause of) this programming error be documented, so 
people (can) learn from it and do not repeat it themselves?


As usually, in the bug log and in the changelog. (But this
condescending tone is not helpful...)


Very much agreed. Likewise the paragraphs of unrelated quotes following 
it.


Regards,

Adam