Jenkins build is back to normal : lintian-tests_sid #2890

[jenkins]

See 

Build failed in Jenkins: lintian-tests_sid #2889

[jenkins]

See 


Changes:

[lamby] Emit an error when a package bumps the epoch but the upstream version

--
[...truncated 237.74 KB...]
Adding debian:Certinomis_-_Root_CA.pem
Adding debian:Certigna.pem
Adding debian:COMODO_RSA_Certification_Authority.pem
Adding debian:COMODO_ECC_Certification_Authority.pem
Adding debian:COMODO_Certification_Authority.pem
Adding debian:CFCA_EV_ROOT.pem
Adding debian:CA_Disig_Root_R2.pem
Adding debian:Buypass_Class_3_Root_CA.pem
Adding debian:Buypass_Class_2_Root_CA.pem
Adding debian:Baltimore_CyberTrust_Root.pem
Adding debian:Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem
Adding debian:Atos_TrustedRoot_2011.pem
Adding debian:Amazon_Root_CA_4.pem
Adding debian:Amazon_Root_CA_3.pem
Adding debian:Amazon_Root_CA_2.pem
Adding debian:Amazon_Root_CA_1.pem
Adding debian:AffirmTrust_Premium_ECC.pem
Adding debian:AffirmTrust_Premium.pem
Adding debian:AffirmTrust_Networking.pem
Adding debian:AffirmTrust_Commercial.pem
Adding debian:AddTrust_External_Root.pem
Adding debian:Actalis_Authentication_Root_CA.pem
Adding debian:AC_RAIZ_FNMT-RCM.pem
Adding debian:ACCVRAIZ1.pem
done.
Setting up openjdk-10-jdk-headless:amd64 (10.0.1+10-4) ...
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/idlj to 
provide /usr/bin/idlj (idlj) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jdeps to 
provide /usr/bin/jdeps (jdeps) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/wsimport to 
provide /usr/bin/wsimport (wsimport) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/rmic to 
provide /usr/bin/rmic (rmic) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jinfo to 
provide /usr/bin/jinfo (jinfo) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jstat to 
provide /usr/bin/jstat (jstat) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jlink to 
provide /usr/bin/jlink (jlink) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jhsdb to 
provide /usr/bin/jhsdb (jhsdb) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jstack to 
provide /usr/bin/jstack (jstack) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jrunscript to 
provide /usr/bin/jrunscript (jrunscript) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/javac to 
provide /usr/bin/javac (javac) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jmod to 
provide /usr/bin/jmod (jmod) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/javap to 
provide /usr/bin/javap (javap) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jar to 
provide /usr/bin/jar (jar) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jaotc to 
provide /usr/bin/jaotc (jaotc) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/javadoc to 
provide /usr/bin/javadoc (javadoc) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/schemagen to 
provide /usr/bin/schemagen (schemagen) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jshell to 
provide /usr/bin/jshell (jshell) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jps to 
provide /usr/bin/jps (jps) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/xjc to 
provide /usr/bin/xjc (xjc) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jmap to 
provide /usr/bin/jmap (jmap) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jdeprscan to 
provide /usr/bin/jdeprscan (jdeprscan) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jimage to 
provide /usr/bin/jimage (jimage) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jstatd to 
provide /usr/bin/jstatd (jstatd) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jdb to 
provide /usr/bin/jdb (jdb) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/serialver to 
provide /usr/bin/serialver (serialver) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/wsgen to 
provide /usr/bin/wsgen (wsgen) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jcmd to 
provide /usr/bin/jcmd (jcmd) in auto mode
update-alternatives: using /usr/lib/jvm/java-10-openjdk-amd64/bin/jarsigner to 
provide /usr/bin/jarsigner (jarsigner) in auto mode
Setting up default-jdk-headless (2:1.10-65) ...
Setting up lintian-build-deps (2.5.86) ...
Processing triggers for libc-bin (2.27-3) ...
Processing triggers for 

Processed: Re: Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 898136 + moreinfo
Bug #898136 [lintian] lintian: Reduce 
depends-on-mail-transport-agent-without-alternatives to pedantic
Added tag(s) moreinfo.
> thanks
Stopping processing here.

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

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Chris Lamb]

tags 898136 + moreinfo
thanks

Hi Russ,

> I just now checked, and the packages currently diagnosed with this tag [1]
> are 100% false positives, which makes me wonder if this tag should just be
> deleted.

Always possible. Let's let pabs chime in; tagging as moreinfo for now... :)


Regards,

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

Processed: Re: Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 889816 + pending
Bug #889816 [lintian] lintian: Complain when epoch has been bumped but upstream 
version did not go backwards
Added tag(s) pending.
> thanks
Stopping processing here.

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

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Chris Lamb]

tags 889816 + pending
thanks

Hi Raphael,

> >  "W: latest-debian-changelog-entry-without-new-version"
> > 
> > Do you think it's still worth adding (essentially) an "E:" version
> > of this? I would tend to be in favour, given that at least I did not
> > see this warning when uploading "that" Django version.
> 
> I think this warning was not in place yet when you made that mistake.

This warning was added in 2007 so it's likely I just missed it. Anyway,
I have implemented this in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/bb13a144e8b2b4326dc5a1d65bf7a1b8f1881247

> Still I think that [latest-debian-changelog-entry-without-new-version]
> was not correctly implemented. It should really ensure that […]

(If so, could you clone and/or re-file etc. with concrete examples?)


Best wishes,

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

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Russ Allbery]

Chris Lamb  writes:

> Just to confirm; it currently it reports for all packages that provide
> mail-transport-agent, ie:

>   citadel-server
>   courier-mta
>   dma
>   esmtp-run
>   exim4
>   exim4-daemon-heavy
>   exim4-daemon-light
>   masqmail
>   msmtp-mta
>   nullmailer
>   opensmtpd
>   postfix
>   qmail-run
>   sendmail-bin
>   ssmtp

> .. and the suggestion is that this list is (essentially) reduced to
> just exim4?

> If so, I don't believe this would warrant the change in severity.

Some more research:

I looked at the original bug report from Paul Wise (cc'd) (#892144), and
the motivation was unclear to me.  Were there packages in the archive that
depended on only one MTA and weren't MTA add-ons or otherwise
intentionally locked to just one MTA?

I just now checked, and the packages currently diagnosed with this tag [1]
are 100% false positives, which makes me wonder if this tag should just be
deleted.

At first glance, the bug this tag is trying to diagnose seems unlikely to
me.  I'm not sure how many maintainers intended to depend on a generic
mail-transport-agent and just picked one out of a hat (although I admit
the lack of documentation in Policy for how to declare this dependency
doesn't help).  In contrast, add-ons for one specific MTA, or management
interfaces that only know how to configure one specific MTA, are fairly
common.

[1] 
https://lintian.debian.org/tags/depends-on-mail-transport-agent-without-alternatives.html

-- 
Russ Allbery (r...@debian.org)   

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Chris Lamb]

Hi Scott.


> Limiting it to packages that depend on exim4 would address all the false 
> positives I saw (since I mostly know about postfix stuff).

Just to confirm; it currently it reports for all packages that
provide mail-transport-agent, ie:

  citadel-server
  courier-mta
  dma
  esmtp-run
  exim4
  exim4-daemon-heavy
  exim4-daemon-light
  masqmail
  msmtp-mta
  nullmailer
  opensmtpd
  postfix
  qmail-run
  sendmail-bin
  ssmtp

.. and the suggestion is that this list is (essentially) reduced to
just exim4?

If so, I don't believe this would warrant the change in severity.


Best wishes,

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

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Raphael Hertzog]

Hi Chris,

On Mon, 07 May 2018, Chris Lamb wrote:
> I've just implemented this, but I notice that it overlaps with
> 
>  "W: latest-debian-changelog-entry-without-new-version"
> 
> Do you think it's still worth adding (essentially) an "E:" version
> of this? I would tend to be in favour, given that at least I did not
> see this warning when uploading "that" Django version.

I think this warning was not in place yet when you made that mistake.

Still I think that this warning was not correctly implemented. It should
really ensure that the epoch-less version does not match any former
epoch-less version (of entries matching the same source package name).

Ensuring that the version is greater is not sufficient as we can have had
multiple epoch jumps in the past and we can potentially have again the
same version even though the last two changelog entries have increasing
version numbers.

So yes I think that this "error-level" tag is still deserved and that we
should better implement latest-debian-changelog-entry-without-new-version. 

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#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Scott Kitterman]

On Monday, May 07, 2018 01:35:30 PM Russ Allbery wrote:
> Scott Kitterman  writes:
> > Package: lintian
> > Version: 2.5.85
> > Severity: normal
> > 
> > Also, please reduce the certainty from certain.  It's not.
> > 
> > I'd just noticed depends-on-mail-transport-agent-without-alternatives.
> > I mainain approximately 10% of the packages affected by the check (3 of
> > 33) and in all those cases the check is wrong.  A cursory review of some
> > of the others clearly show it's incorrect for them as well (at least
> > 10).  I don't think a check with a false positive rate of a minimum of
> > nearly 50% is that useful.
> > 
> > In the case of my three, they depend on postfix without alternative
> > becuase they are only for postfix.
> 
> It sounds like there's both a bug and a certainty error here, but I don't
> think this check is a good example of something that should be pedantic.
> The dependency structure for depending on a generic MTA should be
> documented in Policy and only isn't because no one has found the time to
> write the patch.
> 
> A simple check for whether the depended-on MTA is also present in the name
> of the package would make a lot of these false positives go away.  If the
> package name contains "postfix" or "exim4" and depends on those MTAs, it's
> probably not a mistake.  :)
> 
> More generally, I suspect this tag should only affect packages that depend
> on the default (exim4).  If the package is already depending on a
> non-default MTA, I think it's highly likely that was intentional and
> Lintian is being more annoying than helpful here.
> 
> Pedantic isn't a dumping ground for buggy or uncertain checks.  If a check
> is known to be buggy or produce a lot of false positives but we don't want
> to delete it entirely because we think we can make it better in the
> future, that's what experimental is for.  Pedantic is for best-practice
> advice that's controversial, that is correct but may not be fixable (no
> upstream changelog, for instance), or that is minor
> quality-of-implementation details that a lot of maintainers aren't
> interested in messing with (upstream/metadata, for instance).

Thanks.  Experimental seems better.  Mostly I was thinking "not on the list of 
stuff most people see".  

I don't think that package name is a great trigger since, while many MTA 
specfic packages have the MTA name in the package name, not all do and there's 
no requirement for it.

Limiting it to packages that depend on exim4 would address all the false 
positives I saw (since I mostly know about postfix stuff).

Scott K

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Russ Allbery]

Scott Kitterman  writes:

> Package: lintian
> Version: 2.5.85
> Severity: normal

> Also, please reduce the certainty from certain.  It's not.

> I'd just noticed depends-on-mail-transport-agent-without-alternatives.
> I mainain approximately 10% of the packages affected by the check (3 of
> 33) and in all those cases the check is wrong.  A cursory review of some
> of the others clearly show it's incorrect for them as well (at least
> 10).  I don't think a check with a false positive rate of a minimum of
> nearly 50% is that useful.

> In the case of my three, they depend on postfix without alternative
> becuase they are only for postfix.

It sounds like there's both a bug and a certainty error here, but I don't
think this check is a good example of something that should be pedantic.
The dependency structure for depending on a generic MTA should be
documented in Policy and only isn't because no one has found the time to
write the patch.

A simple check for whether the depended-on MTA is also present in the name
of the package would make a lot of these false positives go away.  If the
package name contains "postfix" or "exim4" and depends on those MTAs, it's
probably not a mistake.  :)

More generally, I suspect this tag should only affect packages that depend
on the default (exim4).  If the package is already depending on a
non-default MTA, I think it's highly likely that was intentional and
Lintian is being more annoying than helpful here.

Pedantic isn't a dumping ground for buggy or uncertain checks.  If a check
is known to be buggy or produce a lot of false positives but we don't want
to delete it entirely because we think we can make it better in the
future, that's what experimental is for.  Pedantic is for best-practice
advice that's controversial, that is correct but may not be fixable (no
upstream changelog, for instance), or that is minor
quality-of-implementation details that a lot of maintainers aren't
interested in messing with (upstream/metadata, for instance).

-- 
Russ Allbery (r...@debian.org)   

Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic

[Scott Kitterman]

Package: lintian
Version: 2.5.85
Severity: normal

Also, please reduce the certainty from certain.  It's not.

I'd just noticed depends-on-mail-transport-agent-without-alternatives.  I
mainain approximately 10% of the packages affected by the check (3 of 33) and
in all those cases the check is wrong.  A cursory review of some of the others
clearly show it's incorrect for them as well (at least 10).  I don't think a
check with a false positive rate of a minimum of nearly 50% is that useful.

In the case of my three, they depend on postfix without alternative becuase
they are only for postfix.

Scott K

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Chris Lamb]

Hi Raphael Hertzog,

I've just implemented this, but I notice that it overlaps with

 "W: latest-debian-changelog-entry-without-new-version"

Do you think it's still worth adding (essentially) an "E:" version
of this? I would tend to be in favour, given that at least I did not
see this warning when uploading "that" Django version.


Regards,

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

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Chris Lamb]

Dear Raphael,

> Bad:
> 
> python-django (2:2.0-1) experimental; urgency=medium
> 
>   * New upstream stable release.
> https://docs.djangoproject.com/en/2.0/releases/2.0/
> 
>  -- Chris Lamb   Sat, 02 Dec 2017 18:36:33 +
> 
> python-django (1:2.0~rc1-1) experimental; urgency=medium
> 
>   * New upstream release candidate.

Well played sir, well played… :)


Best wishes,

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

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Raphael Hertzog]

On Fri, 04 May 2018, Chris Lamb wrote:
> Could you provide some concrete "good" and "bad" cases? I'm pretty
> sure I know what you're after here but want to be 100% certain,
> especially if we want this to be an "error". :)

Good (in the context of this lintian tag, though I would have used
1.10~beta1+really1.9.7 in this case):

python-django (1:1.9.7-2) unstable; urgency=medium

  * Re-upload 1.9.7 to unstable with epoch.

 -- Chris Lamb   Sun, 26 Jun 2016 09:58:19 +0200

python-django (1.10~beta1-1) unstable; urgency=medium

  * New upstream beta release.

 -- Chris Lamb   Sat, 25 Jun 2016 19:17:49 +0200



Bad:

python-django (2:2.0-1) experimental; urgency=medium

  * New upstream stable release.
https://docs.djangoproject.com/en/2.0/releases/2.0/

 -- Chris Lamb   Sat, 02 Dec 2017 18:36:33 +

python-django (1:2.0~rc1-1) experimental; urgency=medium

  * New upstream release candidate.


  * Drop trailing whitespace in debian/changelog.

 -- Chris Lamb   Thu, 16 Nov 2017 09:55:14 +0900


;-)

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/