Bug#1031679: lintian: d/rules: should suggest using `execute_before/_after_dh_command` instead of `override_dh_command`
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
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
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
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
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
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
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
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
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"
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
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"
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/*
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
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"
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"?
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"
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
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
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
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
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
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
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/su
Bug#928283: lintian: false positive pkg-js-tools-test-is-missing for openjk: assumes variables contain --with=nodejs
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
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.
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
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
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
Version: 2.5.65 Re: Roger Shimizu 2017-10-16 > On Mon, May 30, 2016 at 1:41 AM, Roger Shimizu wrote: > > I met this false positive message, too. But in different case. > > I got the message when debian/watch is like: > > > > > > opts="repack,compression=xz, \ > >dversionmangle=s/\+ds\d*$//,repacksuffix=+ds, \ > > > > > > > > And lintian is happy when dversionmangle line moves to the 1st line: > > > > > > opts="repack,compression=xz,dversionmangle=s/\+ds\d*$//,repacksuffix=+ds, \ > > > > > > This issue got disappeared recently. > Maybe lintian already fixed this, after stretch released? There are still cases where it is buggy: # please also check http://pypi.debian.net/Flask-Mail/watch version=3 opts="uversionmangle=s/(rc|a|b|c)/~$1/, dversionmangle=s/\+dfsg.*//" \ http://pypi.debian.net/Flask-Mail/Flask-Mail-(.+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) W: flask-mail source: debian-watch-file-should-mangle-version line 4 The warning goes away when I remove the space after the comma. The version with the space is the syntax documented in uscan(1): Multiple options option1, option2, option3, ... can be set as opts="option1, option2, option3, ... " . Christoph
Bug#882600: Allow maintainers to use different email addresses without raising NMU warnings
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
Package: lintian Version: 2.5.59 Severity: wishlist Hi, I'm using "Christoph Berg " as Maintainer/Uploaders address in my packages, but when I'm doing uploads from work, I'm using "Christoph Berg " 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"
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
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 (*?)
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
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
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#692282: [new check] debian/tests/control but not (XS-)Testsuite: autopkgtest header in debian/control
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#550594: warn about invalid versions in debian/NEWS.Debian
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
Re: Michael Stilkerich in <[EMAIL PROTECTED]> > [EMAIL PROTECTED] cat > Applications/20~Games/Arcade/~jumpnbump-menu~Jump\'N\'Bump Oh, btw, please use less weird filenames. ~ and ' shouldn't be part of regular filenames when avoidable. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Lintian warnings/errors
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