Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

2018-02-05 Thread Ron
On Tue, Feb 06, 2018 at 03:32:55AM +0530, Chris Lamb wrote:
> tags 820770 + moreinfo
> thanks
> 
> 
> Hi Ron and Felipe,
> 
> Hm, are #820770 and #889640 the same issue? If so, we should either
> close them both or reopen both of them.

Yes, that was exactly my line of thinking when I first saw this warning,
before discovering that in practice /etc/rc1.d/S01killprocs is going to
stop it anyway before switching to rcS and restarting it again.  And
that is exactly what the extended lintian warning was trying to explain
(and probably successfully would have if the system I first saw it on
had initscripts installed which provides that script).

These two should definitely be merged, but I'd welcome Felipe reviewing
the conclusions I came to here https://bugs.debian.org/889640#15 just
in case I did miss something we ought to do other than just close this
now.

  Cheers,
  Ron



Bug#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

2018-02-05 Thread Mattia Rizzolo
don't forget, the tag could also be marked as experimental, which is
thought exactly to help out developing of the tags with high chances of
fpos.

On Tue, Feb 6, 2018 at 4:48 AM Daniel Kahn Gillmor  wrote:

> On Mon 2018-02-05 04:38:14 +0530, Chris Lamb wrote:
> > tags 889592 + pending
> > thanks
> >
> > "Fixed" in Git, pending upload:
> >
> >
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=293c897ef968e0f50ac4f48986034aeda57e179d
> >
> > Ah well, just too many false-positive cases.. I mean, we'd have to start
> > ignoring ": " comments, as well as detecting the differences between,
> say:
> >
> > override_dh_auto_test:
> >   echo "input" | ./testsuite.sh
> >
> > and
> >
> > override_dh_auto_test:
> >   echo "Not running"
>
> Hm, ripping it out entirely seems suboptimal, i'd love to be able to
> find and fix a bunch of these.
>
> What if the tag didn't trigger if there was only one command in
> override_dh_auto_test, and it started with either "dh_auto_test " or
> with ": "?
>
> i think that would avoid most of the important false-positives, and the
> tag could provide guidance for folks who were doing 'echo "Not running"'
> to use ': Not running' instead.
>
> Seems a shame to lose a bunch of good catches if we can prune down the
> false-positives.  And even if this ends up missing some true positives,
> it would be a net win to catch the packages that *do* fail to check
> DEB_BUILD_PROFILES.
>
>--dkg
>


Bug#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

2018-02-05 Thread Daniel Kahn Gillmor
On Mon 2018-02-05 04:38:14 +0530, Chris Lamb wrote:
> tags 889592 + pending
> thanks
>
> "Fixed" in Git, pending upload:
>
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=293c897ef968e0f50ac4f48986034aeda57e179d
>
> Ah well, just too many false-positive cases.. I mean, we'd have to start
> ignoring ": " comments, as well as detecting the differences between, say:
>
> override_dh_auto_test:
>   echo "input" | ./testsuite.sh
>
> and
>
> override_dh_auto_test:
>   echo "Not running"

Hm, ripping it out entirely seems suboptimal, i'd love to be able to
find and fix a bunch of these.

What if the tag didn't trigger if there was only one command in
override_dh_auto_test, and it started with either "dh_auto_test " or
with ": "?

i think that would avoid most of the important false-positives, and the
tag could provide guidance for folks who were doing 'echo "Not running"'
to use ': Not running' instead.

Seems a shame to lose a bunch of good catches if we can prune down the
false-positives.  And even if this ends up missing some true positives,
it would be a net win to catch the packages that *do* fail to check
DEB_BUILD_PROFILES.

   --dkg


signature.asc
Description: PGP signature


Processed: Re: lintian: error on d/rules having dh_make templates

2018-02-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 679124 + pending
Bug #679124 [lintian] lintian: error on d/rules having dh_make templates
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
679124: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679124
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#679124: lintian: error on d/rules having dh_make templates

2018-02-05 Thread Chris Lamb
tags 679124 + pending
thanks

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d0fec9183b5977fa8f5e0a779631bb140ee3415d


Regards,

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



[lintian] 01/01: Check for debian/rules files that are dh_make templates. (Closes: #679124)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository lintian.

commit d0fec9183b5977fa8f5e0a779631bb140ee3415d
Author: Chris Lamb 
Date:   Mon Feb 5 22:41:52 2018 +

Check for debian/rules files that are dh_make templates. (Closes: #679124)
---
 checks/rules.desc |  8 
 checks/rules.pm   |  3 +++
 debian/changelog  |  2 ++
 t/tests/rules-general/debian/debian/rules |  3 +++
 t/tests/rules-general/desc|  1 +
 t/tests/rules-general/tags| 11 ++-
 6 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/checks/rules.desc b/checks/rules.desc
index 4e89148..b22aa06 100644
--- a/checks/rules.desc
+++ b/checks/rules.desc
@@ -337,3 +337,11 @@ Info: The debian/rules file for this package has 
a call to
  .
  Please remove the call and let dpkg-deb(1) select suitable defaults.
 Ref: #829100, dpkg-deb(1)
+
+Tag: debian-rules-is-dh_make-template
+Severity: important
+Certainty: certain
+Info: The debian/rules file appears to be an unmodified or insufficiently
+ modified copy of the dh_make template.
+ .
+ Please double-check the rules file.
diff --git a/checks/rules.pm b/checks/rules.pm
index 8f70f7e..559e72e 100644
--- a/checks/rules.pm
+++ b/checks/rules.pm
@@ -177,6 +177,9 @@ sub run {
 }
 my $line = $_;
 
+tag 'debian-rules-is-dh_make-template'
+  if $. == 2 and $line eq "# See debhelper(7) (uncomment to enable)\n";
+
 next if /^\s*\#/;
 if (m/^\s*[s-]?include\s+(\S++)/o){
 my $makefile = $1;
diff --git a/debian/changelog b/debian/changelog
index ffd05d2..749e90c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -29,6 +29,8 @@ lintian (2.5.74) UNRELEASED; urgency=medium
 + [CL] Remove override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES
   (for now) as there are just too many false-positive cases to check.
   (Closes: #889592)
++ [CL] Check for debian/rules files that are dh_make templates.
+  (Closes: #679124)
   * checks/scripts.desc:
 + [CL] Improve, elaborate and tidy the long description of the
   maintainer-script-should-not-use-recursive-chown-or-chmod tag.
diff --git a/t/tests/rules-general/debian/debian/rules 
b/t/tests/rules-general/debian/debian/rules
index a9623ca..0b01dc6 100755
--- a/t/tests/rules-general/debian/debian/rules
+++ b/t/tests/rules-general/debian/debian/rules
@@ -1,4 +1,7 @@
 #!/usr/bin/make -f
+# See debhelper(7) (uncomment to enable)
+# output every command that modifies files on the build system.
+#export DH_VERBOSE = 1
 
 DEB_AUTO_UPDATE_DEBIAN_CONTROL = yes
 DH_EXTRA_ADDONS = systemd
diff --git a/t/tests/rules-general/desc b/t/tests/rules-general/desc
index 357ef3d..38e6caa 100644
--- a/t/tests/rules-general/desc
+++ b/t/tests/rules-general/desc
@@ -3,6 +3,7 @@ Version: 1.0
 Description: Test various debian/rules checks
 Test-For:
  clean-should-be-satisfied-by-build-depends
+ debian-rules-is-dh_make-template
  debian-rules-should-not-automatically-update-control
  debian-rules-should-not-use-DEB_BUILD_OPTS
  debian-rules-should-not-use-DH_EXTRA_ADDONS
diff --git a/t/tests/rules-general/tags b/t/tests/rules-general/tags
index 800c2d8..906841b 100644
--- a/t/tests/rules-general/tags
+++ b/t/tests/rules-general/tags
@@ -1,6 +1,7 @@
 E: rules-general source: clean-should-be-satisfied-by-build-depends debhelper
-E: rules-general source: debian-rules-should-not-automatically-update-control 
line 3
-W: rules-general source: debian-rules-should-not-use-DEB_BUILD_OPTS line 11
-W: rules-general source: debian-rules-should-not-use-DH_EXTRA_ADDONS systemd 
(line 4)
-W: rules-general source: debian-rules-should-not-use-pwd line 11
-W: rules-general source: debian-rules-should-not-use-underscore-variable line 
12
+E: rules-general source: debian-rules-is-dh_make-template
+E: rules-general source: debian-rules-should-not-automatically-update-control 
line 6
+W: rules-general source: debian-rules-should-not-use-DEB_BUILD_OPTS line 14
+W: rules-general source: debian-rules-should-not-use-DH_EXTRA_ADDONS systemd 
(line 7)
+W: rules-general source: debian-rules-should-not-use-pwd line 14
+W: rules-general source: debian-rules-should-not-use-underscore-variable line 
15

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



[lintian] branch master updated (bc472ef -> d0fec91)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a change to branch master
in repository lintian.

  from  bc472ef   c/r-lintian-harness: Clear the error-counter on a success
   new  d0fec91   Check for debian/rules files that are dh_make templates. 
(Closes: #679124)

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:
 checks/rules.desc |  8 
 checks/rules.pm   |  3 +++
 debian/changelog  |  2 ++
 t/tests/rules-general/debian/debian/rules |  3 +++
 t/tests/rules-general/desc|  1 +
 t/tests/rules-general/tags| 11 ++-
 6 files changed, 23 insertions(+), 5 deletions(-)

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



Bug#526713: marked as done ([checks/fields] allow Vcs-* fields to be multiline)

2018-02-05 Thread Debian Bug Tracking System
Your message dated Tue, 06 Feb 2018 03:46:38 +0530
with message-id 
<1517868998.2361167.1260559664.21557...@webmail.messagingengine.com>
and subject line Re: [checks/fields] allow Vcs-* fields to be multiline
has caused the Debian Bug report #526713,
regarding [checks/fields] allow Vcs-* fields to be multiline
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.)


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

Hi,

several packages split the Vcs-* fields on two lines to avoid long
lines.  Lintian should not complain in this case.

See [1] for examples: most of the packages with "\n" in the Vcs-* fields
are false positives.

Regards,
Ansgar

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.19.1-1  The GNU assembler, linker and bina
ii  diffstat   1.46-1produces graph of changes introduc
ii  dpkg-dev   1.14.26   Debian package development tools
ii  file   5.00-1Determines file type using "magic"
ii  gettext0.17-6GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libipc-run-perl0.82-1Perl module for running processes
ii  libparse-debianchangel 1.1.1-2   parse Debian changelogs and output
ii  libtimedate-perl   1.1600-9  Time and date functions for Perl
ii  liburi-perl1.37+dfsg-1   Manipulates and accesses URI strin
ii  man-db 2.5.5-1   on-line manual pager
ii  perl [libdigest-sha-pe 5.10.0-19 Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch (no description available)
pn  libtext-template-perl  (no description available)
ii  man-db2.5.5-1on-line manual pager

-- no debconf information


--- End Message ---
--- Begin Message ---
Version: 2.5.4

> [checks/fields] allow Vcs-* fields to be multiline

This was fixed in 2.5.4 by Niels:

  https://anonscm.debian.org/git/lintian/lintian.git/commit/?
id=99434353efc5f9877079fcb70099b3159c27dc3b


Regards,

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


Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

2018-02-05 Thread Chris Lamb
tags 820770 + moreinfo
thanks


Hi Ron and Felipe,

Hm, are #820770 and #889640 the same issue? If so, we should either
close them both or reopen both of them.


Regards,

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



Processed: Re: Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

2018-02-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 820770 + moreinfo
Bug #820770 [lintian] lintian: init.d-script-possible-missing-stop should 
special-case runlevel S scripts
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
820770: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820770
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: [lintian] Please detect source missing .wasm file

2018-02-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 889102 + pending
Bug #889102 [lintian] [lintian] Please detect source missing .wasm file
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
889102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889102
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#889102: [lintian] Please detect source missing .wasm file

2018-02-05 Thread Chris Lamb
tags 889102 + pending
thanks

This was fixed by Bastien in:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=740e6738e364f18662264d5cdd14552bc869a54b


Regards,

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



Bug#889640: marked as done (lintian: init.d-script-possible-missing-stop misfire on rcS scripts)

2018-02-05 Thread Debian Bug Tracking System
Your message dated Tue, 06 Feb 2018 02:18:21 +0530
with message-id 
<1517863701.2323293.1260456416.6148f...@webmail.messagingengine.com>
and subject line Re: Bug#889640: lintian: init.d-script-possible-missing-stop 
misfire on rcS scripts
has caused the Debian Bug report #889640,
regarding lintian: init.d-script-possible-missing-stop misfire on rcS scripts
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.)


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

And one more for today's trifecta :)

A SysV init script with:

 # Default-Start: S
 # Default-Stop:  0 6

Will cause lintian to complain about it not being stopped in runlevel 1,
with a rationale that would be fine for services started in 2-5, but that
doesn't really apply for things which can be shut down in an orderly way
but shouldn't be just because you're switching to or entering runlevel 1.

  Cheers,
  Ron
--- End Message ---
--- Begin Message ---
Hey Ron!

> [..]

Well, thank you for such an informative followup! :)

>  - lintian is actually right.
[…]
>  - there was probably something else, but now I need a stiff drink and
>a lie down

*grin*

> And unless I've really missed some other detail there, we can probably
> just close this one, leave lintian as is

Sure, will do :)  And no worries about the noise - indeed, it was
probably the very act of "rubber ducking" of the issue here that solved
it for you and, as I mentioned above, I learned quite a few things :)


Best wishes,

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


Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

2018-02-05 Thread Ron
On Mon, Feb 05, 2018 at 08:48:57PM +0530, Chris Lamb wrote:
> tags 889640 + moreinfo
> thanks
> 
> Hi Ron,
> 
> >  # Default-Start: S
> >  # Default-Stop:  0 6
> > 
> > Will cause lintian to complain about it not being stopped in runlevel 1,
> > with a rationale that would be fine for services started in 2-5, but that
> > doesn't really apply for things which can be shut down in an orderly way
> > but shouldn't be just because you're switching to or entering runlevel 1.
> 
> Getcha. I'm not an runlevel expert, but do you suggest we don't emit
> this tag at all for scripts that /include/ 'S' in Default-Start or for
> ones that /only/ have 'S' (ie. "Default-Start: S")

Ok, so this one turns out to be a little more convoluted than I always
understood it to be ...

The rcS runlevel is/was used for things which need to be started early
in the boot sequence, regardless of which runlevel the system was going
to enter.  Ostensibly the 'S' stands for 'single user', but there's a
fuzzy overlap in that particular role as rc1 is also a/the single user
mode runlevel (but rc1 scripts only get invoked when explicitly entering
or leaving runlevel 1) ...

With that in mind, for something started in rcS, there's usually only
two sensible behaviours for when it should be stopped.  It may be a
one-shot task, which runs at early boot then exits, so it never needs
to be stopped, or it sets up or runs something which shouldn't be
explicitly stopped before the CPU itself is halted or rebooted - for
both those cases nothing would be specified for Default-Stop.

Alternatively, it does start some long-running early boot service, which
can and should be explicitly shut down in an orderly way when the system
is being halted (0) or rebooted (6).  But which should remain running in
single user mode (S/1).

In line with that, every rcS script I recall ever looking at (and all
the ones still on the machines I checked here), used either:

  # Default-Start: S
  # Default-Stop:  0 6
or
  # Default-Start: S
  # Default-Stop:

So to directly answer your question above, it would probably be a
(separate) bug for anything that had 'S' in Default-Start to have
any other runlevel included there too (because entering any other
runlevel will have already run the rcS start scripts anyway).


Where things start to get a bit more confusing is that the initscripts
package ships a SysV init script 'killprocs' - which is 'started' upon
entering runlevel 1, and basically brutally slaughters *every* process
except the kernel threads, init, and the shell running it, with
killall5(8) ...  after which the /etc/rc1.d/single script is run, which
then changes from runlevel 1 to runlevel S - restarting all the things
in rcS again to actually enter the real 'single user mode' ...

So ostensibly, the lintian warning is actually correct about what will
happen if 1 isn't included in Default-Stop - it will still get killed
anyway, but then immediately be (re)started again ...


But wait! There's more!!  The reason I missed that detail when I first
reported this was that on the buster system I looked at this all on,
the initscripts package isn't installed, so there is no killprocs
script on it - and even if it was installed, when systemd is installed
it masks that script so that it won't run at all.  But that in turn
makes this all a bit moot on current releases, because since Stretch,
systemd won't run rcS scripts at all - if they don't have a native unit
now, it simply ignores them completely ...  which means this all really
only matters for Hurd/kFreeBSD and people not running systemd (in which
case sysvinit-core will pull in initscripts again).


So with all that said and done, I think the somewhat dizzying conclusion
is that:

 - lintian is actually right.
 - almost everything I know of providing an rcS script gets this wrong.
 - killprocs seems a little bit batshit, but I can sort of see the
   logic of wiping out everything and starting again with a clean
   slate if you're changing to runlevel 1 from some other runlevel
   (and who ever does that anymore anyway if you weren't thrown into
   it due to a boot failure!)
 - hopefully everything in rcS is actually safely idempotent if anyone
   does try that.
 - there was probably something else, but now I need a stiff drink and
   a lie down, safe in the knowledge that every time I look at init
   stuff it's always more horribly broken in ways that I never imagined
   the last time I shook my head at how horribly broken it all was ...

And unless I've really missed some other detail there, we can probably
just close this one, leave lintian as is, and point at this bug log if
anyone scratches their head at this warning again in the future ...


Sorry for the noise on this one then.  For most things, killprocs will
probably only do the same thing that the service's own stop function
would do (send a polite, then more insistent signal to terminate it),
so it's probably not a big deal to have 

Bug#869547: lintian: udev-rule-missing-subsystem false positive

2018-02-05 Thread Ron
On Mon, Feb 05, 2018 at 09:06:35PM +0530, Chris Lamb wrote:
> forcemerge 869547 889639
> thanks
> 
> Hi Ron,
> 
> This appears to be same issue as #869547 ("udev-rule-missing-subsystem
> false-positive when rules file uses a GOTO").

Ah, indeed.  Sorry about the duplicate, this is the same and that patch
looks (conceptually at least!) right by eye to address it.

Re your question in the other bug about how common GOTO is, it's used a
lot in just about any set of non-trivial rules testing for common things,
so if there are (or will be) any other tests for things like this, the
same logic probably should apply to them too.

  Cheers,
  Ron



Bug#889639: udev-rule-missing-subsystem false-positive when rules file uses a GOTO

2018-02-05 Thread Didier 'OdyX' Raboud
Le lundi, 5 février 2018, 16.58:46 h CET Chris Lamb a écrit :
> Fixed in Git, pending upload

Yay, thanks; and sorry for my unresponsiveness.

-- 
OdyX



Bug#869547: udev-rule-missing-subsystem false-positive when rules file uses a GOTO

2018-02-05 Thread Chris Lamb
Hi Didier,

> > Fixed in Git, pending upload
> 
> Yay, thanks; and sorry for my unresponsiveness.

No problem; it was quite an "expansive" question :)


Regards,

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



[lintian] branch master updated (ba4969e -> bc472ef)

2018-02-05 Thread Niels Thykier
This is an automated email from the git hooks/post-receive script.

nthykier pushed a change to branch master
in repository lintian.

  from  ba4969e   c/r-lintian-harness: Add missing assignment
   new  bc472ef   c/r-lintian-harness: Clear the error-counter on a success

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:
 commands/reporting-lintian-harness.pm | 2 ++
 1 file changed, 2 insertions(+)

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



[lintian] branch master updated (a25f871 -> ba4969e)

2018-02-05 Thread Niels Thykier
This is an automated email from the git hooks/post-receive script.

nthykier pushed a change to branch master
in repository lintian.

  from  a25f871   checks/udev.pm: Add simple GOTO parsing to avoid false 
positives when checking for udev rules for SUBSYSTEM specifiers. (Closes: 
#869547, #889639)
   new  ba4969e   c/r-lintian-harness: Add missing assignment

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:
 commands/reporting-lintian-harness.pm | 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: c/r-lintian-harness: Clear the error-counter on a success

2018-02-05 Thread Niels Thykier
This is an automated email from the git hooks/post-receive script.

nthykier pushed a commit to branch master
in repository lintian.

commit bc472ef8b4ea4e00d3b02902a24b46a5ea102197
Author: Niels Thykier 
Date:   Mon Feb 5 17:57:38 2018 +

c/r-lintian-harness: Clear the error-counter on a success

Signed-off-by: Niels Thykier 
---
 commands/reporting-lintian-harness.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/commands/reporting-lintian-harness.pm 
b/commands/reporting-lintian-harness.pm
index 4d22492..a51e683 100644
--- a/commands/reporting-lintian-harness.pm
+++ b/commands/reporting-lintian-harness.pm
@@ -415,6 +415,8 @@ sub process_worklist {
 $group_data = $state->{'groups'}{$group_id};
 $group_data->{'last-processed-by'} = $LINTIAN_VERSION;
 delete($group_data->{'out-of-date'});
+# Always clear the error counter after a successful run.
+delete($group_data->{'processing-errors'});
 }
 for my $group_id (sort(keys(%errors))) {
 my $group_data;

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



[lintian] 01/01: c/r-lintian-harness: Add missing assignment

2018-02-05 Thread Niels Thykier
This is an automated email from the git hooks/post-receive script.

nthykier pushed a commit to branch master
in repository lintian.

commit ba4969e690ac2ad11cb2109ca9818064a6569223
Author: Niels Thykier 
Date:   Mon Feb 5 17:56:27 2018 +

c/r-lintian-harness: Add missing assignment

Signed-off-by: Niels Thykier 
---
 commands/reporting-lintian-harness.pm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/commands/reporting-lintian-harness.pm 
b/commands/reporting-lintian-harness.pm
index b7aa42a..4d22492 100644
--- a/commands/reporting-lintian-harness.pm
+++ b/commands/reporting-lintian-harness.pm
@@ -421,6 +421,7 @@ sub process_worklist {
 # In theory, they can disappear - in practise, that requires
 # an external call to (e.g.) dplint reporting-sync-state.
 next if not exists($state->{'groups'}{$group_id});
+$group_data = $state->{'groups'}{$group_id};
 if ($errors{$group_id}) {
 ++$group_data->{'processing-errors'};
 # Set the "last-processed-by" flag so we can clear the

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



Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

2018-02-05 Thread Raphael Hertzog
Hi,

On Fri, 02 Feb 2018, Chris Lamb wrote:
> > In my case, I remember having touched many packages with dedicated
> > users created and I expect this tag to have a very high false positive
> > ratio
> 
> Can you make this more concrete? (Or, perhaps, why is colord
> vulnerable but your particular package is not..?)

I'm not quite sure of what colord is vulnerable. #889060 assumes the
attacker can create arbitrary hardlinks as the "colord" user in
/var/lib/colord. I don't know colord enough to know if that's the case
and why that would be the case.

In general, when you have a dedicated user it's because you want to run a
daemon under that user to restrict its accesses. The interfaces of most
daemons do not allow end users to create hardlinks/symlinks in the data
directories of the daemon... hence this chown -R vulnerability is only
exploitable after having found another vulnerability in the daemon to
create the hardlinks and/or symlinks.

That makes it much less important as a vulnerability.

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/



Processed: Re: udev-rule-missing-subsystem false-positive when rules file uses a GOTO

2018-02-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 869547 + pending
Bug #869547 [lintian] udev-rule-missing-subsystem false-positive when rules 
file uses a GOTO
Bug #889639 [lintian] lintian: udev-rule-missing-subsystem false positive
Added tag(s) pending.
Added tag(s) pending.
> tags 889639 + pending
Bug #889639 [lintian] lintian: udev-rule-missing-subsystem false positive
Bug #869547 [lintian] udev-rule-missing-subsystem false-positive when rules 
file uses a GOTO
Ignoring request to alter tags of bug #889639 to the same tags previously set
Ignoring request to alter tags of bug #869547 to the same tags previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
869547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869547
889639: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889639
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#869547: udev-rule-missing-subsystem false-positive when rules file uses a GOTO

2018-02-05 Thread Chris Lamb
tags 869547 + pending
tags 889639 + pending
thanks

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=a25f87117ebe4deb3ec6ccee3d5d5c81e7aeba1d


Regards,

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



[lintian] 01/01: checks/udev.pm: Add simple GOTO parsing to avoid false positives when checking for udev rules for SUBSYSTEM specifiers. (Closes: #869547, #889639)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository lintian.

commit a25f87117ebe4deb3ec6ccee3d5d5c81e7aeba1d
Author: Chris Lamb 
Date:   Mon Feb 5 15:57:46 2018 +

checks/udev.pm: Add simple GOTO parsing to avoid false positives when 
checking for udev rules for SUBSYSTEM specifiers. (Closes: #869547, #889639)
---
 checks/udev.pm   | 8 ++--
 debian/changelog | 3 +++
 t/tests/udev-rules/debian/debian/udev-rules.udev | 7 +++
 t/tests/udev-rules/tags  | 1 +
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/checks/udev.pm b/checks/udev.pm
index 4e76591..07962d4 100644
--- a/checks/udev.pm
+++ b/checks/udev.pm
@@ -43,7 +43,7 @@ sub run {
 }
 
 sub check_rule {
-my ($file, $linenum, $rule) = @_;
+my ($file, $linenum, $in_goto, $rule) = @_;
 
 # for USB, if everyone or the plugdev group members are
 # allowed access, the uaccess tag should be used too.
@@ -78,6 +78,7 @@ sub check_rule {
 # subsystem, as vendor/product is subsystem specific.
 if (   $rule =~ m/ATTR\{idVendor\}=="[0-9a-fA-F]+"/
 && $rule =~ m/ATTR\{idProduct\}=="[0-9a-fA-F]*"/
+&& $in_goto !~ m/SUBSYSTEM!="[^"]+"/
 && $rule !~ m/SUBSYSTEM=="[^"]+"/) {
 tag(
 'udev-rule-missing-subsystem',
@@ -95,6 +96,7 @@ sub check_udev_rules {
 my $linenum = 0;
 my $cont;
 my $retval = 0;
+my $in_goto = '';
 while (<$fd>) {
 chomp;
 $linenum++;
@@ -107,7 +109,9 @@ sub check_udev_rules {
 next;
 }
 next if /^#.*/; # Skip comments
-$retval |= $check->($file, $linenum, $_);
+$in_goto = '' if m/LABEL="[^"]+"/;
+$in_goto = $_ if m/GOTO="[^"]+"/;
+$retval |= $check->($file, $linenum, $in_goto, $_);
 }
 close($fd);
 return $retval;
diff --git a/debian/changelog b/debian/changelog
index 452ba97..ffd05d2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -34,6 +34,9 @@ lintian (2.5.74) UNRELEASED; urgency=medium
   maintainer-script-should-not-use-recursive-chown-or-chmod tag.
   Heavily based on a patch by Daniel Kahn Gillmor - thanks!
   (Closes: #889489)
+  * checks/udev.pm:
++ [CL] Add simple GOTO parsing to avoid false positives when checking
+  for udev rules for SUBSYSTEM specifiers.  (Closes: #869547, #889639)

   * commands/reporting-{html-reports,lintian-harness}.pm:
 + [NT] Register packages that fail during archive wide processing.
diff --git a/t/tests/udev-rules/debian/debian/udev-rules.udev 
b/t/tests/udev-rules/debian/debian/udev-rules.udev
index dd3442b..538e174 100644
--- a/t/tests/udev-rules/debian/debian/udev-rules.udev
+++ b/t/tests/udev-rules/debian/debian/udev-rules.udev
@@ -15,3 +15,10 @@ ACTION=="add", ATTR{idVendor}=="", 
ATTR{idProduct}=="0005", \
 
 SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="", 
ATTR{idProduct}=="000a", \
 ID_TEST_DEVICE="1"
+
+SUBSYSTEM!="usb", GOTO="target"
+ATTR{idVendor}=="", ATTR{idProduct}=="", 
RUN+="missing-subsystem-false-positive"
+LABEL="target"
+
+# Ensure we trigger this one after a GOTO
+ATTR{idVendor}=="", ATTR{idProduct}=="", RUN+="missing-subsystem"
diff --git a/t/tests/udev-rules/tags b/t/tests/udev-rules/tags
index 5798a00..becee41 100644
--- a/t/tests/udev-rules/tags
+++ b/t/tests/udev-rules/tags
@@ -1,4 +1,5 @@
 E: udev-rules: udev-rule-unreadable lib/udev/rules.d/60-dangling-symlink.rules
 W: udev-rules: udev-rule-missing-subsystem 
lib/udev/rules.d/60-udev-rules.rules:14 vendor/product matching missing 
SUBSYSTEM specifier
+W: udev-rules: udev-rule-missing-subsystem 
lib/udev/rules.d/60-udev-rules.rules:24 vendor/product matching missing 
SUBSYSTEM specifier
 W: udev-rules: udev-rule-missing-uaccess 
lib/udev/rules.d/60-udev-rules.rules:2 user accessible device missing 
TAG+="uaccess"
 W: udev-rules: udev-rule-missing-uaccess 
lib/udev/rules.d/60-udev-rules.rules:5 user accessible device missing 
TAG+="uaccess"

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



[lintian] branch master updated (2901619 -> a25f871)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a change to branch master
in repository lintian.

  from  2901619   Only warn about bad-jar-name for "public" .jar files. 
(Closes: #889628)
   new  a25f871   checks/udev.pm: Add simple GOTO parsing to avoid false 
positives when checking for udev rules for SUBSYSTEM specifiers. (Closes: 
#869547, #889639)

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:
 checks/udev.pm   | 8 ++--
 debian/changelog | 3 +++
 t/tests/udev-rules/debian/debian/udev-rules.udev | 7 +++
 t/tests/udev-rules/tags  | 1 +
 4 files changed, 17 insertions(+), 2 deletions(-)

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



Processed: Re: lintian: udev-rule-missing-subsystem false positive

2018-02-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> forcemerge 869547 889639
Bug #869547 [lintian] udev-rule-missing-subsystem false-positive when rules 
file uses a GOTO
Bug #869547 [lintian] udev-rule-missing-subsystem false-positive when rules 
file uses a GOTO
Marked as found in versions lintian/2.5.72.
Bug #889639 [lintian] lintian: udev-rule-missing-subsystem false positive
Severity set to 'minor' from 'normal'
Marked as found in versions lintian/2.5.52.
Merged 869547 889639
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
869547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869547
889639: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889639
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#869547: lintian: udev-rule-missing-subsystem false positive

2018-02-05 Thread Chris Lamb
forcemerge 869547 889639
thanks

Hi Ron,

This appears to be same issue as #869547 ("udev-rule-missing-subsystem
false-positive when rules file uses a GOTO").


Regards,

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



Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

2018-02-05 Thread Chris Lamb
tags 889640 + moreinfo
thanks

Hi Ron,

>  # Default-Start: S
>  # Default-Stop:  0 6
> 
> Will cause lintian to complain about it not being stopped in runlevel 1,
> with a rationale that would be fine for services started in 2-5, but that
> doesn't really apply for things which can be shut down in an orderly way
> but shouldn't be just because you're switching to or entering runlevel 1.

Getcha. I'm not an runlevel expert, but do you suggest we don't emit
this tag at all for scripts that /include/ 'S' in Default-Start or for
ones that /only/ have 'S' (ie. "Default-Start: S")


Best wishes,

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



Bug#889638: lintian: please downgrade build-depends-on-obsolete-package dh-systemd to warning

2018-02-05 Thread Ron
On Mon, Feb 05, 2018 at 04:06:04PM +0530, Chris Lamb wrote:
> Hi Mattia,
> 
> > Right, but this way the whole tag has been downgraded.
> 
> Mmm, as Lintian does not support "per-warning" severity levels. Is
> it worth having a separate, tags for the E and the W cases..?

I wondered about that too when I looked at the patch, and the list of
packages this tag applies to ...  but are there really cases where it
would be an "error" which wouldn't already be caught as such by the
package FTBFS in a clean chroot?

If things are deprecated, a warning about the transition is nice,
even if it's not actually the right time to change to the replacement
yet in every case.  Which is part of why I'd rather not override this
where it could be forgotten, I do want the visible reminder to reassess
it again later.

An "error" says to me "if you ignore this, stuff will break", which
isn't really the case for B-D: dh-systemd right now.  If it is the
case for other things, a separate tag might be warranted, but at first
blush to me that case seems like it should be handled by filing RC
bugs against any remaining users, and removing the offending package
this would check for completely, rather than simply deprecating it.
Is there something in between that still which we need to cater for?

  Cheers.
  Ron



Bug#889638: lintian: please downgrade build-depends-on-obsolete-package dh-systemd to warning

2018-02-05 Thread Chris Lamb
Hi Mattia,

> Right, but this way the whole tag has been downgraded.

Mmm, as Lintian does not support "per-warning" severity levels. Is
it worth having a separate, tags for the E and the W cases..?

If this was the difference between E/W and P, I would be easily
convinced but there is not too many meaningful differences between
errors and warnings in terms of visibility.


Regards,

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



Bug#889638: lintian: please downgrade build-depends-on-obsolete-package dh-systemd to warning

2018-02-05 Thread Mattia Rizzolo
On Mon, Feb 05, 2018 at 02:29:43PM +0530, Chris Lamb wrote:
> Fixed in Git, pending upload:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=eadf7fd69fa0594407cacd34cbdfe1851bf6ec7b

Right, but this way the whole tag has been downgraded.
build-depends-on-obsolete-package also reports about packages that you
should really not build-depend on (openjdk-6, hardening-wrapper,
qt5-default, etc etc) and a Severity:important tag is more than
warrented for those.


This bug is only reporting about how impossible to do a straight
backport to wheezy, which can be considered a valid use case, but if
that's so can I instead suggest to just add a lintian override in that
package (with a comment)?.


-- 
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  `-


signature.asc
Description: PGP signature


Bug#889628: lintian: False-positive bad-jar-name

2018-02-05 Thread Chris Lamb
tags 889628 + pending
thanks

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=29016192066d756160444a78b9a441865a4d39bd


Regards,

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



Processed: Re: lintian: False-positive bad-jar-name

2018-02-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 889628 + pending
Bug #889628 [lintian] lintian: False-positive bad-jar-name
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
889628: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889628
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



[lintian] 01/01: Only warn about bad-jar-name for "public" .jar files. (Closes: #889628)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository lintian.

commit 29016192066d756160444a78b9a441865a4d39bd
Author: Chris Lamb 
Date:   Mon Feb 5 10:19:56 2018 +

Only warn about bad-jar-name for "public" .jar files. (Closes: #889628)
---
 checks/java.desc  | 6 +++---
 checks/java.pm| 4 ++--
 debian/changelog  | 3 +++
 t/tests/java-jars/debian/debian/libtesta-java.install | 1 +
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/checks/java.desc b/checks/java.desc
index 269975b..16e0e97 100644
--- a/checks/java.desc
+++ b/checks/java.desc
@@ -102,7 +102,7 @@ Info: The package contains a Jar file, but Lintian is 
unable to parse it.
 Tag: bad-jar-name
 Severity: normal
 Certainty: certain
-Info: The package contains a specified Jar file, but the name does not
- correspond to Java policy guidelines. This can cause tools in the Debian
- Java toolchain to fail.
+Info: The package ships the specified "public" Jar file under
+ /usr/share/java/, but the name does not correspond to Java policy
+ guidelines. This can cause tools in the Debian Java toolchain to fail.
 Ref: java-policy 2.4
diff --git a/checks/java.pm b/checks/java.pm
index 16b2fd6..32c4c8a 100644
--- a/checks/java.pm
+++ b/checks/java.pm
@@ -72,9 +72,9 @@ sub run {
 $has_jars = 1;
 if($jar_file =~ m#^usr/share/java/[^/]+\.jar$#o) {
 $has_public_jars = 1;
+tag 'bad-jar-name', $jar_file
+  unless basename($jar_file) =~ /^$PKGNAME_REGEX\.jar$/;
 }
-tag 'bad-jar-name', $jar_file
-  unless basename($jar_file) =~ /^$PKGNAME_REGEX\.jar$/;
 # check for common code files like .class or .clj (Clojure files)
 foreach
   my $class (grep { m/\.(?:class|cljc?)$/oi } sort keys %{$files}){
diff --git a/debian/changelog b/debian/changelog
index ae87ff1..452ba97 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,9 @@ lintian (2.5.74) UNRELEASED; urgency=medium
   * checks/fields.desc:
 + [CL] Downgrade severity of build-depends-on-obsolete-package from
   error to warning.  (Closes: #889638)
+  * checks/java.{desc,pm}:
++ [CL] Only warn about bad-jar-name for "public" .jar files.
+  (Closes: #889628)
   * checks/patch-systems.pm:
 + [CL] Avoid emitting "Can't use an undefined value as an ARRAY
   reference" warnings when debian/patches is a file, not a directory.
diff --git a/t/tests/java-jars/debian/debian/libtesta-java.install 
b/t/tests/java-jars/debian/debian/libtesta-java.install
index a6483d5..cf31c45 100644
--- a/t/tests/java-jars/debian/debian/libtesta-java.install
+++ b/t/tests/java-jars/debian/debian/libtesta-java.install
@@ -1,3 +1,4 @@
 0.jar usr/share/java/
+0.jar usr/share/private-jars/
 testb.jar usr/lib/
 testc.jar usr/bin

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



[lintian] branch master updated (eadf7fd -> 2901619)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a change to branch master
in repository lintian.

  from  eadf7fd   Downgrade severity of build-depends-on-obsolete-package 
from error to warning. (Closes: #889638)
   new  2901619   Only warn about bad-jar-name for "public" .jar files. 
(Closes: #889628)

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:
 checks/java.desc  | 6 +++---
 checks/java.pm| 4 ++--
 debian/changelog  | 3 +++
 t/tests/java-jars/debian/debian/libtesta-java.install | 1 +
 4 files changed, 9 insertions(+), 5 deletions(-)

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



Processed: Re: lintian: please downgrade build-depends-on-obsolete-package dh-systemd to warning

2018-02-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 889638 + pending
Bug #889638 [lintian] lintian: please downgrade 
build-depends-on-obsolete-package dh-systemd to warning
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
889638: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889638
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#889639: lintian: udev-rule-missing-subsystem false positive

2018-02-05 Thread Ron
Package: lintian
Version: 2.5.72
Severity: normal

Hi,

I see:
W: bit-babbler: udev-rule-missing-subsystem 
lib/udev/rules.d/60-bit-babbler.rules:16 vendor/product matching missing 
SUBSYSTEM specifier

But it's mistaken, because the entire rules file is guarded with:

 SUBSYSTEM!="usb", GOTO="bb_end"
  ...
 LABEL="bb_end"

because all the rules in it are inapplicable for non-USB devices.

  Cheers,
  Ron



Bug#889638: lintian: please downgrade build-depends-on-obsolete-package dh-systemd to warning

2018-02-05 Thread Ron
Package: lintian
Version: 2.5.72
Severity: normal

Hi,

Lintian reports the following for packages which B-D on dh-systemd
E: source: build-depends-on-obsolete-package build-depends: dh-systemd => use 
debhelper (>= 9.20160709)

However the suggested replacement is not possible to satisfy on Jessie
without a -backports version of debhelper, and not possible to satisfy
on Wheezy at all with what Debian currently distributes.

A note about there being a transition is welcome, but the severity seems
a bit inflated with my "someone who cares about backports of my packages
remaining as trivial as possible" hat on.

It is still safe to B-D on dh-systemd for now in Sid/Buster, that just
pulls in the transitional package which in turn depends on the version
of debhelper which replaces it - so it would be nice to downgrade the
urgency of this for at least one more release cycle.

Especially since all bets are off in later dh compat versions where
the systemd support has changed completely again - it would be nice to
not make it harder than needed for backports, and have an easy canary
for how many packages still need the older systemd support for that.

  Cheers,
  Ron



Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

2018-02-05 Thread Ron
Package: lintian
Version: 2.5.72
Severity: normal

And one more for today's trifecta :)

A SysV init script with:

 # Default-Start: S
 # Default-Stop:  0 6

Will cause lintian to complain about it not being stopped in runlevel 1,
with a rationale that would be fine for services started in 2-5, but that
doesn't really apply for things which can be shut down in an orderly way
but shouldn't be just because you're switching to or entering runlevel 1.

  Cheers,
  Ron



[lintian] branch master updated (51761a6 -> eadf7fd)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a change to branch master
in repository lintian.

  from  51761a6   c/reporting: Improve handling of packages with errors
   new  eadf7fd   Downgrade severity of build-depends-on-obsolete-package 
from error to warning. (Closes: #889638)

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:
 checks/fields.desc| 2 +-
 debian/changelog  | 3 +++
 t/tests/fields-build-depends-general/tags | 4 ++--
 t/tests/fields-java/desc  | 1 +
 t/tests/fields-java/tags  | 2 +-
 t/tests/legacy-debconf/tags   | 2 +-
 t/tests/legacy-scripts/tags   | 2 +-
 t/tests/patch-systems-dpatch-description/desc | 1 +
 t/tests/patch-systems-dpatch-description/tags | 2 +-
 t/tests/patch-systems-quilt-general/desc  | 1 +
 t/tests/patch-systems-quilt-general/tags  | 2 +-
 11 files changed, 14 insertions(+), 8 deletions(-)

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



[lintian] 01/01: Downgrade severity of build-depends-on-obsolete-package from error to warning. (Closes: #889638)

2018-02-05 Thread Chris Lamb
This is an automated email from the git hooks/post-receive script.

lamby pushed a commit to branch master
in repository lintian.

commit eadf7fd69fa0594407cacd34cbdfe1851bf6ec7b
Author: Chris Lamb 
Date:   Mon Feb 5 08:58:50 2018 +

Downgrade severity of build-depends-on-obsolete-package from error to 
warning. (Closes: #889638)
---
 checks/fields.desc| 2 +-
 debian/changelog  | 3 +++
 t/tests/fields-build-depends-general/tags | 4 ++--
 t/tests/fields-java/desc  | 1 +
 t/tests/fields-java/tags  | 2 +-
 t/tests/legacy-debconf/tags   | 2 +-
 t/tests/legacy-scripts/tags   | 2 +-
 t/tests/patch-systems-dpatch-description/desc | 1 +
 t/tests/patch-systems-dpatch-description/tags | 2 +-
 t/tests/patch-systems-quilt-general/desc  | 1 +
 t/tests/patch-systems-quilt-general/tags  | 2 +-
 11 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/checks/fields.desc b/checks/fields.desc
index 1197e26..65d5224 100644
--- a/checks/fields.desc
+++ b/checks/fields.desc
@@ -536,7 +536,7 @@ Info: The package depends on an ORed group of packages 
which includes
  a package that has been superseded.
 
 Tag: build-depends-on-obsolete-package
-Severity: important
+Severity: normal
 Certainty: possible
 Info: The package build-depends on a package that has been superseded.
  If the superseded package is part of an ORed group, it should not be
diff --git a/debian/changelog b/debian/changelog
index 93686e2..ae87ff1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -15,6 +15,9 @@ lintian (2.5.74) UNRELEASED; urgency=medium
   (Closes: #889486)
   * checks/files.pm:
 + [BR] Add context for privacy breach in order to improve debugging.
+  * checks/fields.desc:
++ [CL] Downgrade severity of build-depends-on-obsolete-package from
+  error to warning.  (Closes: #889638)
   * checks/patch-systems.pm:
 + [CL] Avoid emitting "Can't use an undefined value as an ARRAY
   reference" warnings when debian/patches is a file, not a directory.
diff --git a/t/tests/fields-build-depends-general/tags 
b/t/tests/fields-build-depends-general/tags
index e6d2840..1350527 100644
--- a/t/tests/fields-build-depends-general/tags
+++ b/t/tests/fields-build-depends-general/tags
@@ -3,8 +3,6 @@ E: fields-build-depends-general source: 
build-depends-on-build-essential build-d
 E: fields-build-depends-general source: 
build-depends-on-essential-package-without-using-version build-depends: bash
 E: fields-build-depends-general source: build-depends-on-metapackage 
build-depends: xorg-dev
 E: fields-build-depends-general source: build-depends-on-non-build-package 
build-depends: java-propose-classpath
-E: fields-build-depends-general source: build-depends-on-obsolete-package 
build-depends: hardening-wrapper (>= 2.2) => use dpkg-buildflags instead
-E: fields-build-depends-general source: build-depends-on-obsolete-package 
build-depends: x-dev (>= 1.0)
 E: fields-build-depends-general source: 
conflicting-negation-in-source-relation build-depends: baz [i386 !amd64]
 E: fields-build-depends-general source: 
depends-on-build-essential-package-without-using-version make [build-depends: 
make]
 E: fields-build-depends-general source: invalid-arch-string-in-source-relation 
all [build-depends: foo [all]]
@@ -13,6 +11,8 @@ E: fields-build-depends-general source: 
invalid-arch-string-in-source-relation s
 I: fields-build-depends-general source: 
build-depends-on-python-dev-with-no-arch-any
 I: fields-build-depends-general source: ored-build-depends-on-obsolete-package 
build-depends: xlibmesa-gl-dev
 W: fields-build-depends-general source: build-depends-on-1-revision 
build-depends: revision-1 (>= 1.0-1)
+W: fields-build-depends-general source: build-depends-on-obsolete-package 
build-depends: hardening-wrapper (>= 2.2) => use dpkg-buildflags instead
+W: fields-build-depends-general source: build-depends-on-obsolete-package 
build-depends: x-dev (>= 1.0)
 W: fields-build-depends-general source: build-depends-on-versioned-berkeley-db 
build-depends:libdb5.1++-dev
 W: fields-build-depends-general source: build-depends-on-versioned-berkeley-db 
build-depends:libdb5.1-java-dev
 W: fields-build-depends-general source: depends-on-packaging-dev build-depends
diff --git a/t/tests/fields-java/desc b/t/tests/fields-java/desc
index a096b39..97a623c 100644
--- a/t/tests/fields-java/desc
+++ b/t/tests/fields-java/desc
@@ -2,6 +2,7 @@ Testname: fields-java
 Version: 1.0
 Description: General tests for java package (build) dependencies
 Test-For:
+ build-depends-on-obsolete-package
  build-depends-on-specific-java-doc-package
  build-depends-on-an-obsolete-java-package
  depends-on-specific-java-doc-package
diff --git a/t/tests/fields-java/tags b/t/tests/fields-java/tags
index 1486627..8f67bcd 100644
--- a/t/tests/fields-java/tags
+++ b/t/tests/fields-java/tags
@@ -1,7 +1,7 @@
-E: