Bug#1031679: lintian: d/rules: should suggest using `execute_before/_after_dh_command` instead of `override_dh_command`

[Christoph Berg]

Re: Gioele Barabucci
> execute_after_dh_clean:
> touch this_strange_file

The downside of this is that it makes backporting to buster-and-older
harder since it doesn't have the required debhelper version yet.

Christoph

Bug#1014162: lintian's run-time is too long on some packages

[Christoph Berg]

Re: To Debian Bug Tracking System
> Version: 2.115.2
> Severity: normal
> 
> Lintian now needs about 3 minutes to check the postgresql-15 source
> package alone.

Current timings:

$ time lintian postgresql-15_15~beta4-1.pgdg+1.dsc
2.115.2 2m29,255s
2.115.3 1m24,698s
2.115.4~git 1m23,866s

So it became a lot better, but I think 84s is still too slow for
checking a .dsc.

Christoph

Bug#1014175: warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64

[Christoph Berg]

Re: To Debian Bug Tracking System
> Warning in processable 
> /builds/postgresql/postgresql/debian/output/postgresql-15_15~beta2-2+salsaci_amd64.deb:
>  Cannot open 
> /tmp/lintian-pool-WqVHVEiN6s/postgresql-15/postgresql-15_15~beta2-2+salsaci_amd64_binary/unpacked/usr/share/doc/postgresql-15/README.Debian.gz
>  at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.

README.Debian.gz is a symlink to a package that isn't built from
postgresql-15, I guess that might be a problem:

lrwxrwxrwx 1 root root 37 10. Aug 14:33 
/usr/share/doc/postgresql-15/README.Debian.gz -> 
../postgresql-common/README.Debian.gz

Re: Lucas Nussbaum
> /usr/share/doc/exim4-daemon-heavy/README.Debian.gz is a symlink to
> ../exim4-base/README.Debian.gz.

... these are from the same source package, though.

Christoph

Bug#1014175: warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64

[Christoph Berg]

Package: lintian
Version: 2.115.2
Severity: normal

Hi,

Lintian is currently failing in salsa-ci on postgresql-15:

https://salsa.debian.org/postgresql/postgresql/-/jobs/2941498

lintian --suppress-tags "${SALSA_CI_LINTIAN_SUPPRESS_TAGS}" --display-info 
--pedantic ${SALSA_CI_LINTIAN_FAIL_ARG} --allow-root 
${SALSA_CI_LINTIAN_SHOW_OVERRIDES_ARG} ${WORKING_DIR}/*.changes | tee 
lintian.output || ECODE=$?
Warning in processable 
/builds/postgresql/postgresql/debian/output/postgresql-15_15~beta2-2+salsaci_amd64.deb:
 Cannot open 
/tmp/lintian-pool-WqVHVEiN6s/postgresql-15/postgresql-15_15~beta2-2+salsaci_amd64_binary/unpacked/usr/share/doc/postgresql-15/README.Debian.gz
 at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.
warning: cannot run debian/readme check on package 
binary:postgresql-15_15~beta2-2+salsaci_amd64
skipping check of binary:postgresql-15_15~beta2-2+salsaci_amd64
W: postgresql-15-dbgsym: unknown-field Postgresql-Catversion
[...]

Christoph

Bug#1014162: lintian's run-time is too long on some packages

[Christoph Berg]

Package: lintian
Version: 2.115.2
Severity: normal

Lintian now needs about 3 minutes to check the postgresql-15 source
package alone.

I'm not really willing to wait that long interactively, so chances are
I'll ignore Lintian in the future more than I'd actually like to :(.

Christoph

Bug#1014045: source-is-missing doesn't seem to understand docbook

[Christoph Berg]

Package: lintian
Version: 2.115.1
Severity: normal

The latest lintian versions are throwing a lot of these errors on
postgresql-15:

E: postgresql-15 source: source-is-missing [doc/src/sgml/html/acronyms.html]
N:   The source of the following file is missing. Lintian checked a few 
possible paths to find the source, and did not find it.
E: postgresql-15 source: source-is-missing [doc/src/sgml/html/admin.html]
E: postgresql-15 source: source-is-missing [doc/src/sgml/html/adminpack.html]
E: postgresql-15 source: source-is-missing [doc/src/sgml/html/amcheck.html]
E: postgresql-15 source: source-is-missing 
[doc/src/sgml/html/app-clusterdb.html]
...

But the source is right there one level up:

$ ls -l doc/src/sgml/html/acronyms.html
-rw-r--r-- 1 cbe cbe 21242 27. Jun 22:15 doc/src/sgml/html/acronyms.html
$ ls -l doc/src/sgml/acronyms.sgml
-rw-r--r-- 1 cbe cbe 19714 27. Jun 22:11 doc/src/sgml/acronyms.sgml

Am I supposed to override these?

Christoph

Bug#1000148: lintian: improbable-bug-number-in-closes needs updating

[Christoph Berg]

Re: Andrius Merkys
> improbable-bug-number-in-closes is false-positive now since bug numbers
> have just hit 100. The problem could be fixed (for example) by replacing
> 
> max-bug = 100
> 
> with
> 
> max-bug = 200
> 
> in /usr/share/lintian/data/changelog-file/bugs-number.

The overengineered solution would be to exploit the fact that bug
numbers are growing mostly linearly, and base the warning on the
current date.

https://wiki.debian.org/90thBugContest

Christoph

Bug#993613: lintian: Complex regular subexpression recursion limit exceeded in cruft check

[Christoph Berg]

I'm hitting this as well:

$ lintian ../powa-web_4.1.2-1_amd64.changes
Warning in processable ../powa-web_4.1.2-1.dsc: Complex regular subexpression 
recursion limit (65534) exceeded at 
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.
Warning in processable ../powa-web_4.1.2-1.dsc: Complex regular subexpression 
recursion limit (65534) exceeded at 
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.
Warning in processable ../powa-web_4.1.2-1.dsc: Complex regular subexpression 
recursion limit (65534) exceeded at 
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.
Warning in processable ../powa-web_4.1.2-1.dsc: Complex regular subexpression 
recursion limit (65534) exceeded at 
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.
Warning in processable ../powa-web_4.1.2-1.dsc: Complex regular subexpression 
recursion limit (65534) exceeded at 
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 773.
[...]

$ cat ../powa-web_4.1.2-1.dsc
Format: 3.0 (quilt)
Source: powa-web
Binary: powa-web
Architecture: all
Version: 4.1.2-1
Maintainer: Debian PostgreSQL Maintainers 

Uploaders:  Christoph Berg ,
Homepage: https://github.com/powa-team/powa
Standards-Version: 4.6.0
Vcs-Browser: https://github.com/powa-team/powa-web
Vcs-Git: https://github.com/powa-team/powa-web.git
Build-Depends: debhelper-compat (= 13), dh-python, python3
Package-List:
 powa-web deb database optional arch=all
Checksums-Sha1:
 101d34afeede4beb1a1fd3925eaad5cdd41194ed 8190557 powa-web_4.1.2.orig.tar.gz
 3f9bcd85a35c4ab40ae6e18654f068ea0481748b 8568 powa-web_4.1.2-1.debian.tar.xz
Checksums-Sha256:
 40d109f2360d2b2e526df94191478fc9ccc1a6a215aab5bbbd80c7510396a762 8190557 
powa-web_4.1.2.orig.tar.gz
 04422b1557b74e3120ea3765e6f16568d6003cddc0cb4064190d6cb56b41edeb 8568 
powa-web_4.1.2-1.debian.tar.xz
Files:
 764b768000e1b2c2a54475f708e30cdf 8190557 powa-web_4.1.2.orig.tar.gz
 a46dc33f41506ef0d17f7599b4a712a9 8568 powa-web_4.1.2-1.debian.tar.xz


Christoph

Bug#996102: Overzealous odd-historical-debian-changelog-version warning that is non-actionable when package changes from native to non-native

[Christoph Berg]

Package: lintian
Version: 2.107.0
Severity: normal

The bgw-replstatus package just changed from native to non-native, and
now I'm getting this, even if I put in a changelog entry about the
change:

W: bgw-replstatus source: odd-historical-debian-changelog-version 1.0.5 (for 
non-native)

What am I supposed to do with this tag? Edit all the old changelog
entries? Which non-benign case is this tag supposed to catch?

Please don't warn about things that I cannot "fix". The package is
correct now, and was correct in the past.

Christoph

Bug#994902: "missing-dep-for-interpreter make" should not trigger on "make:any"

[Christoph Berg]

Package: lintian
Version: 2.106.1
Severity: normal

Hi,

 Package: postgresql-server-dev-all
 Source: postgresql-common
 Version: 229
 Architecture: amd64
 Depends: make:any, postgresql-common (= 229), postgresql-server-dev-13

Yet lintian is complaining:

E: postgresql-server-dev-all: missing-dep-for-interpreter make => make | 
build-essential | dpkg-dev 
(usr/share/postgresql-common/dh_make_pgxs/debian/rules) /usr/bin/make

Christoph

Bug#973503: "missing-build-dependency-for-dh-addon pgxs => postgresql-server-dev-all" is missing postgresql-all

[Christoph Berg]

Package: lintian
Version: 2.100.0
Severity: normal

Hi,

The tag "missing-build-dependency-for-dh-addon pgxs => 
postgresql-server-dev-all"
needs to consider "postgresql-all" as a possible alternative build-dependency.

Christoph

Bug#972464: declares-possibly-conflicting-debhelper-compat-versions should reference "control" not "rules"

[Christoph Berg]

Package: lintian
Version: 2.97.0
Severity: normal

Hi,

on a hypopg package version that still used the 1.0 format, I got this tag:

E: hypopg source: declares-possibly-conflicting-debhelper-compat-versions 
rules=13 compat=9

The correct message would be "control=13 compat=9" I believe.

repo: https://github.com/credativ/hypopg.git
commit: a635c5469d4ed44

Christoph

Bug#967226: redundant-globbing-patterns [* *] for legitimate use of * and debian/*

[Christoph Berg]

Package: lintian
Version: 2.80.0
Severity: normal

python-skytools uses this copyright file:

Files: *
Copyright:
 Copyright (c) 2007-2017 Skytools Authors
 Copyright (c) 2007-2017 Marko Kreen
License: ISC

Files: skytools/apipkg.py
Copyright: Copyright (c) holger krekel, 2009
License: MIT

Files: debian/*
Copyright:
 Copyright (c) 2007-2017 Skytools Authors
 Copyright (c) 2007-2017 Marko Kreen
 Copyright (c) 2018 The Debian Project
License: ISC

https://salsa.debian.org/postgresql/python-skytools/-/blob/debian/debian/copyright

which yields these warnings:

E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/changelog
E: python-skytools source: redundant-globbing-patterns [* *] for debian/compat
E: python-skytools source: redundant-globbing-patterns [* *] for debian/control
E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/copyright
E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/py3dist-overrides
E: python-skytools source: redundant-globbing-patterns [* *] for debian/rules
E: python-skytools source: redundant-globbing-patterns [* *] for 
debian/source/format

I don't think that's wrong and lintian is at fault.

Christoph

Bug#966022: lintian: False positive on missing-depends-on-sensible-utils with commands like i3-sensible-pager

[Christoph Berg]

Re: Raphaël Hertzog
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3-sensible-pager

Additionally, the warnings are somewhat useless because it doesn't say
which of the utils is being nagged about.

Could the warning be rephrased to include that?

E: flrig: missing-depends-on-sensible-utils usr/bin/flrig sensible-something

Christoph

Bug#947763: "aCount" is not a spelling error of "account"

[Christoph Berg]

Re: Felix Lechner 2020-03-30 

> Hi Christoph,
> 
> On Mon, Dec 30, 2019 at 2:51 AM Christoph Berg  wrote:
> >
> > "aCount" is hardly a spelling error for "account". It's not even
> > present in the source, but only in the "strings /usr/bin/cqrlog"
> > output.
> 
> Since the string is not present in your source, your bug was probably
> filed against the wrong package.

I'm filing this against lintian because this is a false positive
reported by lintian.

If lintian is going to be annoying with these warnings, maintainers
will tend to ignore them. You should strive to keep the number of
false positives as low as possible.

> Here are a few more using non-standard spelling:
> 
> I: lazarus-ide-gtk2-2.0: spelling-error-in-binary
> usr/lib/lazarus/2.0.6/lazarus-gtk2 Exluded Excluded

Yes, and I'm not reporting these as lintian false positives.

> > I suggest excluding CamelCased words from the spelling check.
> 
> I have not seen a lot of GUI items in camel case (which would cause
> more legitimate strings like it to appear in binaries) and do not
> perceive 'aCount' as a false positive.

If camel case isn't a common spelling error, why is lintian reporting
it? It's clearly a programming artifact, and lintian would be well
advised to ignore it, instead of pestering me.

Christoph

Bug#954341: lintian: What's going on with "field-too-long Installed-Build-Depends"?

[Christoph Berg]

Control: severity -1 important

Re: Felix Lechner 2020-03-20 

> > E: pkg-perl-tools buildinfo: field-too-long Installed-Build-Depends (11190 
> > chars > 5000)
> 
> I will disable the tag for this particular buildinfo field in the near future.

This is causing lots of salsa-ci pipelines to fail (and it's not just
these "weird" nodejs packages):

https://salsa.debian.org/postgresql/pg-cron/-/jobs/622417
https://salsa.debian.org/postgresql/pldebugger/-/jobs/624068

Please make that future happen now.

Thanks,
Christoph

Bug#947763: "aCount" is not a spelling error of "account"

[Christoph Berg]

Package: lintian
Version: 2.25.0
Severity: normal

I: cqrlog: spelling-error-in-binary usr/bin/cqrlog aCount account

"aCount" is hardly a spelling error for "account". It's not even
present in the source, but only in the "strings /usr/bin/cqrlog"
output.

I suggest excluding CamelCased words from the spelling check.

Thanks,
Christoph

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Christoph Berg]

Re: Chris Lamb 2019-11-14 
<36f7dff0-df0b-479b-aa5e-9018ce438...@www.fastmail.com>
> 2.35.0~bpo9+1 and 2.35.0~bpo10+1 uploaded to {stretch,buster}-backports
> respectfully.

Thanks!

Christoph

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Christoph Berg]

Am 7. November 2019 23:19:51 MEZ schrieb Felix Lechner 
:
>Hi Chris,
>
>On Thu, Nov 7, 2019 at 2:07 PM Chris Lamb  wrote:
>>
>> I do not understand the frequency that Christoph's checks
>> his email has any bearing here. Can you elaborate?
>
>Unfortunately, I can only speculate that he meant to present a sense
>of urgency. If a new release is needed, Christoph should speak up.
>From my perspective no action is required.
>
>Kind regards,
>Felix Lechner

The package is not installable at the moment. That fact alone should warrant an 
upload.

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Christoph Berg]

Re: Felix Lechner 2019-11-07 

> Also, as a side note, would someone please explain why someone still
> on stretch would need lintian? I am personally on stable, but most
> package maintainers out there seem to track testing or the bleeding
> edge, unstable.

sbuild recently started running lintian by default. Since the
apt.postgresql.org build host was upgraded from stretch to buster,
lintian is now running in every chroot. I forgot why I upgraded the
lintian version in the stretch chroot to the one from
stretch-backports, but that's we are now, and at the moment I get
reminded every 6 hours via failing jenkins jobs that this package
can't upgrade.

Christoph

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Christoph Berg]

Re: Felix Lechner 2019-11-06 

> According to Andreas Beckmann, coreutils 8.30 is in the process of
> being ported to stretch.

Thanks for the feedback.

> For details, please have a look at the PS here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943910#25

I'm not sure if that means that backport is really going to appear in
stretch-backports.

My build chroots for stretch are broken at the moment, it would really
be nice if this could either be carried forward rsn, or the lintian
backport upgrade be reverted.

Christoph

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Christoph Berg]

Package: lintian
Version: 2.32.0~bpo9+1
Severity: grave

Package: lintian
Version: 2.32.0~bpo9+1
Installed-Size: 5665
Maintainer: Debian Lintian Maintainers 
Architecture: all
Replaces: funny-manpages (<< 1.3-5.1)
Depends: binutils, bzip2, coreutils (>= 8.30), ...

coreutils:
  Installiert:   8.26-3
  Installationskandidat: 8.26-3
  Versionstabelle:
 *** 8.26-3 500
500 http://debian-approx:/debian stretch/main ppc64el Packages
100 /var/lib/dpkg/status

Christoph

Bug#943711: Don't warn about missing ${sphinxdoc:Depends} when dh_sphinxdoc is *not* used

[Christoph Berg]

Package: lintian
Version: 2.29.0
Severity: normal

In postgresql-common, which is not using sphinx at all, I'm getting a
lintian warning, both with 2.29.0 and 2.30.0:

W: postgresql-common source: sphinxdoc-but-no-sphinxdoc-depends

DEB_CHECK_COMMAND=lintian dpkg-buildpackage -rfakeroot -us -uc -i -I
dpkg-buildpackage: Information: Quellpaket postgresql-common
dpkg-buildpackage: Information: Quellversion 208
dpkg-buildpackage: Information: Quelldistribution unstable
dpkg-buildpackage: Information: Quelle geändert durch Christoph Berg 

dpkg-buildpackage: Information: Host-Architektur amd64
 dpkg-source -i -I --before-build .
 fakeroot debian/rules clean
dh clean --with systemd
   dh_auto_clean
make -j1 clean
make[1]: Verzeichnis „/home/cbe/projects/postgresql/common/postgresql-common“ 
wird betreten
rm -f *.1 *.8 dh_make_pgxs/*.1
make[1]: Verzeichnis „/home/cbe/projects/postgresql/common/postgresql-common“ 
wird verlassen
   dh_clean
 dpkg-source -i -I -b .
dpkg-source: Information: Quellformat »3.0 (native)« wird verwendet
dpkg-source: Information: postgresql-common wird in 
postgresql-common_208.tar.xz gebaut
dpkg-source: Information: postgresql-common wird in postgresql-common_208.dsc 
gebaut
 debian/rules build
dh build --with systemd
   dh_update_autotools_config
   debian/rules override_dh_auto_configure
make[1]: Verzeichnis „/home/cbe/projects/postgresql/common/postgresql-common“ 
wird betreten
### Building postgresql-common flavor default
### Supported PostgreSQL versions: 12 (default version: 12)
make[1]: Verzeichnis „/home/cbe/projects/postgresql/common/postgresql-common“ 
wird verlassen
   dh_auto_build
make -j1
make[1]: Verzeichnis „/home/cbe/projects/postgresql/common/postgresql-common“ 
wird betreten
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_conftool pg_conftool.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_createcluster pg_createcluster.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_ctlcluster pg_ctlcluster.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_dropcluster pg_dropcluster.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_lsclusters pg_lsclusters.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_renamecluster pg_renamecluster.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_upgradecluster pg_upgradecluster.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_wrapper pg_wrapper.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_buildext.pod pg_buildext.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 pg_virtualenv.pod pg_virtualenv.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 1 dh_make_pgxs/dh_make_pgxs.pod dh_make_pgxs/dh_make_pgxs.1
pod2man --center "Debian PostgreSQL infrastructure" -r "Debian" --quotes=none 
--section 8 pg_updatedicts pg_updatedicts.8
make[1]: Verzeichnis „/home/cbe/projects/postgresql/common/postgresql-common“ 
wird verlassen
   dh_auto_test
 fakeroot debian/rules binary
dh binary --with systemd
   dh_testroot
   dh_prep
   dh_installdirs
   dh_auto_install
   debian/rules override_dh_install
make[1]: Verzeichnis „/home/cbe/projects/postgresql/common/postgresql-common“ 
wird betreten
dh_install
/usr/bin/make -C systemd install 
DESTDIR=/home/cbe/projects/postgresql/common/postgresql-common/debian/postgresql-common
make[2]: Verzeichnis 
„/home/cbe/projects/postgresql/common/postgresql-common/systemd“ wird betreten
install -d 
/home/cbe/projects/postgresql/common/postgresql-common/debian/postgresql-common/lib/systemd/system-generators/
 
/home/cbe/projects/postgresql/common/postgresql-common/debian/postgresql-common/lib/systemd/system/
install postgresql-generator 
/home/cbe/projects/postgresql/common/postgresql-common/debian/postgresql-common/lib/systemd/system-generators/
install -m644 postgresql*.service 
/home/cbe/projects/postgresql/common/postgresql-common/debian/postgresql-common/lib/systemd/system/
make[2]: Verzeichnis 
„/home/cbe/projects/postgresql/common/postgresql-common/systemd“ wird verlassen
install -m 644 -D debian/postgresql-common.sysctl 
debian/postgresql-common/etc/sysctl.d/30-postgresql-shm.conf
/bin/echo -e "# See /usr/share/postgresql-common/supported-versions for 
documentation of this file\ndefault" > 
debian/postgresql-client-common/etc/postgresql-common/support

Bug#928283: lintian: false positive pkg-js-tools-test-is-missing for openjk: assumes variables contain --with=nodejs

[Christoph Berg]

Re: Chris Lamb 2019-05-02 
<30f34bfa-050d-4966-856d-2cce9da3b...@www.fastmail.com>
> Indeed, how common even is this false-positive? It might be even more
> sensible to add a Lintian override until upstream accepts the package;
> it's meant to be temporary until upstream reviews/accepts some change,
> after all.

Same problem in postgresql-common:

W: postgresql-common source: pkg-js-tools-test-is-missing

WITH_SYSTEMD=--with systemd

%:
dh $@ $(WITH_SYSTEMD)

(It's written that way to make disabling it on older distributions using `sed` 
easier.)

Christoph

Bug#930677: unused-debconf-template triggers when template is used in postrm only

[Christoph Berg]

Package: lintian
Version: 2.15.0
Severity: normal

postgresql-12 is using debconf in the purge phase only:

purge_package () {
# ask the user if they want to remove clusters. If debconf is not
# available, just remove everything
if [ -e /usr/share/debconf/confmodule ]; then
db_set $DPKG_MAINTSCRIPT_PACKAGE/postrm_purge_data true
db_input high $DPKG_MAINTSCRIPT_PACKAGE/postrm_purge_data || :
db_go || :
db_get $DPKG_MAINTSCRIPT_PACKAGE/postrm_purge_data || :
[ "$RET" = "false" ] && return 0
fi

This triggers unused-debconf-template:

I: postgresql-12: unused-debconf-template postgresql-12/postrm_purge_data
N:
N:Templates which are not used by the package should be removed from the
N:templates file.
N:
N:This will reduce the size of the templates database and prevent
N:translators from unnecessarily translating the template's text.
N:
N:In some cases, the template is used but Lintian is unable to determine
N:this. Common causes are:
N:
N:- the maintainer scripts embed a variable in the template name in order
N:to allow a template to be selected from a range of similar templates
N:(e.g. db_input low start_$service_at_boot)
N:
N:- the template is not used by the maintainer scripts but is used by a
N:program in the package
N:
N:- the maintainer scripts are written in perl. Lintian currently only
N:understands the shell script debconf functions.
N:
N:If any of the above apply, please install an override.
N:
N:Severity: minor, Certainty: possible
N:
N:Check: debconf, Type: binary, udeb, source

I'm filing this bug because "postrm" isn't listed among the common
causes. Please either check postrm as well, or mention it there.

If the problem is rather $DPKG_MAINTSCRIPT_PACKAGE, please support
that use.

Thanks,
Christoph

Re: "don't bug people uploading from @work" etc.

[Christoph Berg]

Re: Chris Lamb 2018-10-12 
<1539363568.280182.1540045272.7bb76...@webmail.messagingengine.com>
> Hi Christoph,
> 
> A lot of the PostgreSQL packages have:
> 
>   1 # don't bug people uploading from @work
>   2 source: changelog-should-mention-nmu
>   3 source: source-nmu-has-incorrect-version-number
> 
> .. in their Lintian overrides. I understand the motivation and don't
> wish to open the debate yet again (!), but have you considered just
> ignoring these locally in your lintianrc?

That would still make them appear on lintian.debian.org and hence on
DDPO.

> That would mean that nobody else would accidentally not see these tags
> and, of course, would reduce the number of overrides.

The number of wrongly labeled NMUs should be next to zero anyway, so
the usefulness of these tags is limited, I'd think.

Christoph

Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

[Christoph Berg]

Re: Thijs Kinkhorst 2016-11-13 

> Yes. Some of my packages have been triggering this Lintian error for a
> long long time now, while all they do is depend on dh-apache2 and let that
> sort out the correct misc:depends.

dacs 1.4.40-1 has this problem as well.

Christoph

Bug#884870: lintian: vcs-field-has-unexpected-spaces and vcswatch don't agree

[Christoph Berg]

Re: Jeremy Bicha 2017-12-20 

> to
> Vcs-Git: https://anonscm.debian.org/git/pkg-webkit/webkit.git -b wk2/unstable

> I think the " -b BRANCHNAME" suffix should be considered valid syntax
> for Vcs-Git.

Fwiw, the -b syntax was not invented by vcswatch, it was in use in the
archive before I wrote the service. I can't find a place where it is
documented (I thought it was debcheckout(1), but it's not in there),
but the idea behind it is that you can you paste the Vcs-Git header
content to "git clone" and it will do the right thing.

(I'm still pondering how a syntax for "package is located in this
subdirectory" should look like, but as that's not supported by "git
clone", I couldn't think of anything yet that would at least look like
the -b syntax. There's a need for it, though.)

Christoph

Bug#505857: lintian: false positive debian-watch-file-should-mangle-version

[Christoph Berg]

Version: 2.5.65

Re: Roger Shimizu 2017-10-16 

Bug#882600: Allow maintainers to use different email addresses without raising NMU warnings

[Christoph Berg]

Re: Chris Lamb 2017-11-24 
<1511563146.347437.1183475376.74ebb...@webmail.messagingengine.com>
> However I wonder if there is a case for debian/source/lintian-options
> that would enable name-matching per-package.. *g*

I guess that would be debian/source/lintian-overrides with
pg-cron source: changelog-should-mention-nmu
pg-cron source: source-nmu-has-incorrect-version-number

That's the solution I'm favoring now.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

Bug#882600: Allow maintainers to use different email addresses without raising NMU warnings

[Christoph Berg]

Package: lintian
Version: 2.5.59
Severity: wishlist

Hi,

I'm using "Christoph Berg <m...@debian.org>" as Maintainer/Uploaders
address in my packages, but when I'm doing uploads from work, I'm
using "Christoph Berg <christoph.b...@credativ.de>" in
debian/changelog to attribute my employer.

The downside of this is that lintian will raise the "NMU detected"
flag. My usual workaround is to put "Team upload" into the changelog,
which is true in most cases, but shouldn't really be necessary. Another
workaround would be to simply lintian-override the warnings, or add
the other address to the Uploaders list (which seems gross to me).

I would suggest to do the NMU detection simply based on matching real
names, but this would not detect accidentally mistyped addresses in
debian/changelog or debian/control. (See also #820523 for the reverse
problem where the real name differs.)

What would the lintian maintainers suggest?

Christoph


signature.asc
Description: PGP signature

Bug#876360: copyright-year-in-future false positive: "252.227-7013 (c) (1) of DFARs"

[Christoph Berg]

Package: lintian
Version: 2.5.52
Severity: normal

Hi,

postgresql-10's debian/copyright is triggering a false positive
copyright-year-in-future warning:

W: postgresql-10: copyright-year-in-future 7013 > 2017 (line 311, column 10)

The line in question has this context:

 Government shall have only "Restricted Rights" as defined in Clause
 252.227-7013 (c) (1) of DFARs.  Notwithstanding the foregoing, the

Christoph

Bug#812248: lintian: don't check Homepage field (and similar) against dbgsym packages

[Christoph Berg]

Re: Niels Thykier 2016-01-22 <56a1d3ac.5050...@thykier.net>
> Sadly, not really.  I will try to convince DSA to make the debug mirror
> available to lintian.d.o, so we can see what tags the dbgsym packages
> trigger.

That would be awesome.

I just discovered that postgresql-common's pg_buildext script has a
bug that triggers "debug-file-with-no-debug-symbols" on a lot of
extension packages. Having lintian.d.o spot these would allow me to
reupload the broken packages.

That said, I think debug-file-with-no-debug-symbols should be E, not
W. I did see these warnings in my local build logs, but given -dbgsym
packages were still new, I pushed them off as spurious and likely
bogus (the debug files do have content (but apparently only comments
or whatever)). 'E' would likely have made me check for the problem
earlier.

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#814326: Warn if filenames contain wildcard characters (*?)

[Christoph Berg]

Package: lintian
Version: 2.5.40.2
Severity: wishlist

Hi,

I think lintian should complain if files in .deb files contain * or ?
characters. These are most likely unexpanded wildcard characters from
debian/*.install files or the like. There might legitimate uses for
these filenames, but these will probably warrant an explicit override.

A current apt-file search yields these (most duplicates removed):

$ apt-file search '*'
chise-db: /usr/lib/xemacs-21.4.15/etc/chise-db/feature/->ancient*sources
chise-db: /usr/lib/xemacs-21.4.15/etc/chise-db/feature/=>ucs*
chise-db: /usr/lib/xemacs-21.4.15/etc/chise-db/feature/name*
clanlib-doc: 
/usr/share/doc/clanlib-doc/Reference/html/CL_FunctionSlot_v0__(*Callback)().html
clanlib-doc: /usr/share/doc/clanlib-doc/Reference/html/CL_GLFunctions__*).html
clanlib-doc: 
/usr/share/doc/clanlib-doc/Reference/html/CL_GLFunctions__**params).html
clanlib-doc: 
/usr/share/doc/clanlib-doc/Reference/html/CL_GLFunctions__**pointer).html
coq-theories: /usr/share/doc/coq-theories/html/index_abbreviation_*.html
cppreference-doc-en-html: 
/usr/share/cppreference/doc/html/en/cpp/experimental/fs/directory_iterator/operator*.html
hol88-help: /usr/share/hol88-2.02.19940316/help/ENTRIES/*.doc
postgresql-contrib-9.5: /usr/share/doc/postgresql-contrib-*/autoinc.example

$ apt-file search '?'
chise-db: /usr/lib/xemacs-21.4.15/etc/chise-db/feature/cns-radical?
ucblogo: /usr/share/ucblogo/logolib/?rest
ucblogo: /usr/share/ucblogo/logolib/file?
w3-recs: 
/usr/share/doc/w3-recs/html/www.w3.org/TR/2008/REC-SVGTiny12-20081222/relaxng/index.html?C=D;O=A.html

I haven't checked the contents, but if I had to guess, only cpp's
"operator*" looks like a valid file name, but even in that case that's
unclear.

(I'm submitting this because postgresql-contrib-9.5's example
directory completely escaped my testing, and a lintian warning (or
error) would have catched it.)

Thanks,
Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#807695: lintian: false positive for command-with-path-in-maintainer-script

[Christoph Berg]

Re: Thorsten Glaser 2015-12-11 
<144985238932.307.13054893134096729173.report...@tglase.lan.tarent.de>
> I got a false positive for FusionForge in sid:
> 
> W: gforge-db-postgresql: command-with-path-in-maintainer-script postinst:8 
> /usr/bin/pg_lsclusters
> […]
> N:See particularly the function pathfind() in devref.
> 
> The line in question:
> 
> if [ -x /usr/bin/pg_lsclusters ]; then

Hi,

postgresql-9.5.postrm has exactly the same problem:

# if we still have the postgresql-common package, use it to also shutdown
# server, etc.; otherwise just remove the directories
if [ -x /usr/bin/pg_dropcluster ]; then
pg_dropcluster --stop-server $VERSION "$1"
else
# remove data directory

I think test -x is a legitimate use case here, and using "which"
instead would just mean using a Debian-specific tool, making the code
less readable for sh programmers (... not to mention the extra fork()).

Can we have that whitelisted in lintian please?

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#692282: [new check] debian/tests/control but not (XS-)Testsuite: autopkgtest header in debian/control

[Christoph Berg]

Re: Stefano Zacchiroli 2012-11-04 
20121104170013.30086.35818.reportbug@usha.takhisis.invalid
 Can you please add a lintian test that will warn if a debian/tests/control 
 file
 exists, but no XS-Testsuite: autopkgtest header is present in the source
 stanza of debian/control ?

And of course, the generic warning about unknown fields should be
dropped:

W: pgbouncer source: unknown-field-in-dsc testsuite

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107155757.ga28...@msgid.df7cb.de

Bug#692282: [new check] debian/tests/control but not (XS-)Testsuite: autopkgtest header in debian/control

[Christoph Berg]

Re: To Stefano Zacchiroli 2013-01-07 20130107155757.ga28...@msgid.df7cb.de
 Re: Stefano Zacchiroli 2012-11-04 
 20121104170013.30086.35818.reportbug@usha.takhisis.invalid
  Can you please add a lintian test that will warn if a debian/tests/control 
  file
  exists, but no XS-Testsuite: autopkgtest header is present in the source
  stanza of debian/control ?
 
 And of course, the generic warning about unknown fields should be
 dropped:
 
 W: pgbouncer source: unknown-field-in-dsc testsuite

Another thought: There should still be a warning if the value of the
field isn't autopkgtest.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107160510.ga29...@msgid.df7cb.de

Bug#550594: warn about invalid versions in debian/NEWS.Debian

[Christoph Berg]

Package: lintian
Version: 2.2.17
Severity: wishlist

While sponsoring, I stumbled over a package with this
debian/NEWS.Debian header

dphys-config (20090529~curr-1) UNRELEASED; urgency=low

while debian/changelog only contained

dphys-config (20090926-1) unstable; urgency=low
[...]
dphys-config (20061020-2.1) unstable; urgency=medium

I think lintian should enforce that NEWS versions also appear in the
changelog. (And maybe that it doesn't say UNRELEASED there when it
doesn't in the changelog.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Lintian warnings/errors

[Christoph Berg]

Re: Michael Stilkerich in [EMAIL PROTECTED]
 The error is an
 E: fvwm-crystal: shell-script-fails-syntax-check 
 ./usr/share/fvwm-crystal/fvwm/Applications/20~Games/Arcade/~jumpnbump-menu~Jump'N'Bump

 #!/bin/sh
 
 exec jumpnbump-menu $@

The general rule for sh scripts is always quote stuff, so the above
line should read

exec jumpnbump-menu $@

This makes a difference when one of the arguments contains a space,
the special $@ magic (as opposed to $*) expands these arguments
correctly.

I don't know though if that's the error that lintian complains about.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature