Bug#895597: lintian: Please improve advice on fixing maintainer-script-should-not-use-recursive-chown-or-chmod
On Fri, 13 Apr 2018 10:33:54 +0100 Chris Lamb <la...@debian.org> wrote: > tags 895597 + moreinfo > thanks > > Hi Neil, > > > From the tag description (extended in bug #889489), it's not clear > > to me *how* to use runuser for the requested fix and *why* using > > runuser actually fixes the problem described in the tag > > I can't comment on this directly, but the tag was also extended in > #895370 which might explain a little more. That is the same content as I've been looking at - I don't find anything useful in that bug report on how to use runuser or why using runuser helps the situation. > > If the *current* tag description is not helpful that is still a > bug in Lintian, of course. > > > For now, I will have to override this warning because I see no > > practical way to fix it. > > Surely one can hold off on that until we get resolution here. A > resigned "have to" seems somewhat of an excessive and unnecessary > level of reaction, especially given the effort that has already > gone into this already. There are a lot of people waiting on this upstream release, a lot of other tasks outside Debian. The upstream release can't wait for this Debian bug to be fixed, much more important bug fixes are contained within the upstream code. Besides, as outlined in the original bug report, the objective here is to document the reasoning so that a full replacement for the current maintainer script can be designed, from scratch. The testing stage of that development alone is expected to take several weeks. We cannot risk that level of disruption at this stage of the upstream release process. A rushed fix to the current postinst is simply unacceptable. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpfzJMk5LhhU.pgp Description: OpenPGP digital signature
Bug#895597: lintian: Please improve advice on fixing maintainer-script-should-not-use-recursive-chown-or-chmod
Package: lintian Version: 2.5.82 Severity: wishlist >From the tag description (extended in bug #889489), it's not clear to me *how* to use runuser for the requested fix and *why* using runuser actually fixes the problem described in the tag and the referenced bug reports. (The bugs referenced in the tag outline the security issue but actually give no example or advice on how to implement the advice in the tag description.) Specifically: W: lava-server: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:154 W: lava-server: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:156 W: lava-server: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:158 W: lava-server: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:159 W: lava-server: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:160 W: lava-server: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:161 The postinst at the point in git history matching the build which generated the above output was: https://github.com/Linaro/pkg-lava-server/blob/901d4d89b174544eebcf08cbc3c78fe3f9fef4f4/debian/lava-server.postinst The problem is that the directories concerned are specific to the current installation and are created based on dates (year, month day) for archival reasons. Every day that an installation is doing useful work, a directory of test logs will be created. There are other directory trees as well, so simply replacing the find with a static list of directories is completely infeasible. Also, although I've given a link to the current postinst, patches to that postinst are not a fix for this bug - the rationale, supporting documentation and reasoning is required, as well as examples. Upstream will be creating a new packaging script (see https://projects.linaro.org/browse/LAVA-973) which will almost certainly be written in Python3 to replace the majority of the current Debian packaging postinst maintainer script. So, clear reasons and advice, without getting tied up in specific languages, on how to avoid the problem which lead to this tag is really important. Testing any changes to the permission handling in this package is going to take a *lot* of effort because tests can only be done on snapshots of busy installations which have a lot of data and the data cannot be easily generated. The current code has been tried and tested over many iterations of large installations (typically with a few Gb of data in the respective directories, so the fix needs to be at least as fast as the current code). Can a wiki page be created which goes into detail on how this issue can be fixed both in a maintainer script and in other upstream scripts which maintainers may need to package? For now, I will have to override this warning because I see no practical way to fix it. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.30-15 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5 ii file 1:5.32-2 ii gettext 0.19.8.1-6 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.33 ii libarchive-zip-perl 1.60-1 ii libclass-accessor-perl0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.99-1 ii liblist-moreutils-perl0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.26 [libdigest-sha-perl] 5.26.1-5 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.73-1 ii libxml-simple-perl2.25-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db2.8.3-2 ii patchutils0.3.4-2 ii perl 5.26.1-5 ii t1utils 1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.52-1 -- no debconf information
Bug#818609: lintian: python-script-but-no-python-dep false positive
} so that lintian is happy. What we should *not* be doing is forcing this kind of workaround by maintainers: https://github.com/Linaro/pkg-lava-server/commit/ac3f2ef4e9b796f1176305f885fa815d0c756508 It all comes down to a python source package which builds more than one python binary. One or more of the binaries only installs python scripts into /usr/share/ and that will trigger the bug. Change the .install to put even one python script into /usr/bin or /usr/sbin and the bug disappears. Add the workaround above and the bug disappears. The workaround isn't needed for any package that installs precisely the same python scripts in /usr/bin or /usr/sbin - that's why this whole sorry story exists. That should be relatively easy to test. What is going wrong is that lintian and dpkg disagree on what is correct. lintian either needs to not check /usr/share or this gets reassigned to dpkg-gencontrol to make dpkg check /usr/share. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJ2ujBQiS1j.pgp Description: OpenPGP digital signature
Bug#818609: lintian: python-script-but-no-python-dep false positive
On Fri, 06 Apr 2018 19:41:08 +0100 Chris Lamb <la...@debian.org> wrote: > Hi Neil, > > > $ /usr/share/lava-server/debian-dev-build.sh -p lava-server > > I tried building as per your instructions but it starting re-cloning > a bunch of stuff within the chroot, after installing fuse, grub, node > etc. etc. … It's simply cloning the debian/ directory out of the git packaging repo. This is an upstream script for upstream developers. > > Could you simply provide this lava-dev .deb somewhere publically? :) https://staging.validation.linaro.org/static/docs/v2/installing_on_debian.html#lava-repositories http://images.validation.linaro.org/staging-repo/pool/main/l/lava-server/ > > the upstream helper script builds whatever is in the git working > > tree, without fussing about uncommitted changes like git-bp. > > As an aside: I understand that git-buildpackage is not for everyone, > but here is a great example of where common, shared tools would really > have a benefit and would save this round trip to fixing this issue. I > mean, this script seems a *lot* more fuss than just committing first > or passing --git-ignore-new … !) This isn't about git-ignore anything, this is about building upstream packages with (sometimes) untested and uncommitted upstream changes to be able to do the testing prior to and during code review. Making debian/patches for that is a complete nonsense. This script is for upstream work with static Debian packaging. Same process is then used to build the nightly builds which are used for functional testing well before any release. Debian tooling is completely useless for all of that upstream work, indeed dpkg is actively obstructive - hence the need for the lava-dev scripts. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJ_qmcBDWPe.pgp Description: OpenPGP digital signature
Bug#818609: lintian: python-script-but-no-python-dep false positive
On Fri, 06 Apr 2018 11:53:25 +0100 Chris Lamb <la...@debian.org> wrote: > tags 818609 + moreinfo > thanks > > Chris Lamb wrote: > > > > $ lintian weboob_1.3-1_all.deb > > > E: weboob: python-script-but-no-python-dep > > > usr/share/weboob/imm-o-matic > > > > I believe you are missing a dependency on Python 3 for this > > script. > […] > > https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=8385bfa725a324d8591343179e0207d72aec9511 > > > > Neil, is this the cause of your issue too? My lava-server packages > here don't seem to have render-template.py (or I'm missing something > obvious!) Upstream have since moved on to exclusive Python3 support but lintian is still getting this wrong. Before the following change, yes, lintian spots these files: neil@sylvester:lava-server (master)$ git diff diff --git a/share/download-test-suites-api.py b/share/download-test-suites-api.py index 96ffe1a8..43b319b2 100755 --- a/share/download-test-suites-api.py +++ b/share/download-test-suites-api.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/env python3 # -*- coding: utf-8 -*- # # download-test-suites-api.py diff --git a/share/render-template.py b/share/render-template.py index 011745cf..ffad2879 100755 --- a/share/render-template.py +++ b/share/render-template.py @@ -1,4 +1,4 @@ -#! /usr/bin/python +#! /usr/bin/python3 """ This script is particularly intended for those adding new devices to LAVA diff --git a/share/validate_devices.py b/share/validate_devices.py index fd53b808..b65cf25e 100755 --- a/share/validate_devices.py +++ b/share/validate_devices.py @@ -1,4 +1,4 @@ -#! /usr/bin/python +#! /usr/bin/python3 """ This script is to check the combination of the Jinja2 device-type templates After building with these changes, lintian gets it wrong: neil@sylvester:lava-server (master)$ lintian -o /tmp/tmp.WrhJ2TmpXH/lava-dev_2018.2+7171.458f470e-1_all.deb W: lava-dev: binary-package-depends-on-toolchain-package depends: debhelper (>= 9.20160709) E: lava-dev: python-script-but-no-python-dep usr/share/lava-server/download-test-suites-api.py E: lava-dev: python-script-but-no-python-dep usr/share/lava-server/render-template.py E: lava-dev: python-script-but-no-python-dep usr/share/lava-server/validate_devices.py $ dpkg -I /tmp/tmp.WrhJ2TmpXH/lava-dev_2018.2+7171.458f470e-1_all.deb|grep Depends Depends: build-essential, ca-certificates, devscripts, dpkg-dev, debootstrap (>= 1.0.86), debhelper (>= 9.20160709), fakeroot, git, libdistro-info-perl, node-uglify, libjs-excanvas, libjs-jquery-cookie, libjs-jquery, libjs-jquery-watermark, libjs-jquery-flot (>= 0.8.2), libjs-jquery-ui, python3 | python3-all | python3-dev | python3-all-dev, python3-setuptools, python3-dateutil, python3-guestfs, python3-nose, python3-netifaces, python3-pexpect (>= 4.2), pep8 | python3-pep8, python3-sphinx (>= 1.4), python3-sphinx-bootstrap-theme, python3-requests, python3-zmq, python3-yaml, python3-voluptuous (>= 0.8.8), docbook-xsl, xsltproc If you have time to reproduce, we have a build script helper. Install lava-dev (in chroot or wherever), git clone http://git.linaro.org/lava/lava-server.git , cd lava-server then: $ /usr/share/lava-server/debian-dev-build.sh -p lava-server Is it something to do with the scripts being in /usr/share ? dh_python3 doesn't notice files in /usr/share $ dpkg-query -W lintian lintian 2.5.80 I'll be putting the above git diff into review today, so the master branch will likely have this change soon. However, the upstream helper script builds whatever is in the git working tree, without fussing about uncommitted changes like git-bp. > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpDyd8KB867T.pgp Description: OpenPGP digital signature
Bug#818609: lintian: python-script-but-no-python-dep false positive
On Tue, 23 Jan 2018 11:11:30 +0530 Chris Lamb <la...@debian.org> wrote: > tags 818609 + moreinfo > thanks > > Hi, > > > The python-script-but-no-python-dep check is being triggered despite > > the dependency existing > > I can't reproduce this; as in, this package is missing the > dependencies for me! > > $ dget lava-dev > dget: retrieving > http://127.0.0.1/deb.debian.org/pool/main/l/lava-server/lava-dev_2018.1-2_all.deb > % Total% Received % Xferd Average Speed TimeTime Time > Current Dload Upload Total SpentLeft Speed 100 39832 100 > 398320 0 39832 0 0:00:01 --:--:-- 0:00:01 37.9M > > $ dpkg -I lava-dev_2018.1-2_all.deb | grep Depends > Depends: build-essential, ca-certificates, devscripts, dpkg-dev, > debootstrap (>= 1.0.86), debhelper (>= 9.20160709), fakeroot, git, > libdistro-info-perl, node-uglify, libjs-excanvas, > libjs-jquery-cookie, libjs-jquery, libjs-jquery-watermark, > libjs-jquery-flot (>= 0.8.2), libjs-jquery-ui, pep8 | python-pep8, > python-guestfs, python-nose, python-netifaces, python3-sphinx (>= > 1.4), python-setuptools, python-pexpect (>= 4.2), > python3-sphinx-bootstrap-theme, python-requests, python-zmq, > python-yaml, python-voluptuous (>= 0.8.8), docbook-xsl, xsltproc, > python-mock > There are 10 packages there which already have that strict Depends which lintian expects. The packaging already has the lintian advice for calculating dependencies with debhelper but no such dependency is calculated. So is debhelper wrong here to not add (a completely redundant) dependency or is lintian wrong to not handle dependencies already listed? There really is no point adding the spurious dependency covered by this lintian warning. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpc0tL1iXyuf.pgp Description: OpenPGP digital signature
Bug#818607: lintian: python-script-but-no-python-dep refers to removed package: dh_pysupport or dh_pycentral
Package: lintian
Version: 2.5.42.1
Severity: normal
The information for python-script-but-no-python-dep contains the section:
N:If you are using debhelper, adding ${python:Depends} to the Depends
N:field and ensuring dh_pysupport or dh_pycentral are run during the build
N:should take care of adding the correct dependency.
Neither dh_pysupport nor dh_pycentral exist in stretch or sid since the
end of December 2015.
https://tracker.debian.org/news/736769
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lintian depends on:
ii binutils 2.26-6
ii bzip2 1.0.6-8
ii diffstat 1.61-1
ii file 1:5.25-2
ii gettext 0.19.7-2
ii hardening-includes2.8+nmu2
ii intltool-debian 0.35.0+20060710.4
ii libapt-pkg-perl 0.1.29+b5
ii libarchive-zip-perl 1.56-2
ii libclass-accessor-perl0.34-1
ii libclone-perl 0.38-1+b1
ii libdata-alias-perl1.20-1+b1
ii libdpkg-perl 1.18.4
ii libemail-valid-perl 1.198-1
ii libfile-basedir-perl 0.07-1
ii libipc-run-perl 0.94-1
ii liblist-moreutils-perl0.413-1+b1
ii libparse-debianchangelog-perl 1.2.0-8
ii libperl5.22 [libdigest-sha-perl] 5.22.1-9
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii liburi-perl 1.71-1
ii libyaml-libyaml-perl 0.41-6+b1
ii man-db2.7.5-1
ii patchutils0.3.4-1
ii perl 5.22.1-9
ii t1utils 1.39-2
ii xz-utils 5.1.1alpha+20120614-2.1
Versions of packages lintian recommends:
ii dpkg 1.18.4
pn libperlio-gzip-perl
ii perl 5.22.1-9
ii perl-modules-5.22 [libautodie-perl] 5.22.1-9
Versions of packages lintian suggests:
pn binutils-multiarch
ii dpkg-dev 1.18.4
ii libhtml-parser-perl3.72-1
ii libtext-template-perl 1.46-1
-- no debconf information
Bug#818609: lintian: python-script-but-no-python-dep false positive
Package: lintian Version: 2.5.42.1 Severity: normal The python-script-but-no-python-dep check is being triggered despite the dependency existing: $ lintian ../lava-server_2016.3+5538.7f896cb-1_amd64.changes E: lava-dev: python-script-but-no-python-dep usr/share/lava-server/render-template.py E: lava-dev: python-script-but-no-python-dep usr/share/lava-server/validate_devices.py N: 7 tags overridden (4 errors, 3 warnings) $ dpkg -I ../lava-dev_2016.3+5538.7f896cb-1_all.deb|grep Depends Depends: build-essential, ca-certificates, devscripts, dpkg-dev, debhelper (>= 8.0.0), fakeroot, git, libdistro-info-perl, node-uglify, libjs-excanvas, libjs-jquery-cookie, libjs-jquery, libjs-jquery-watermark, libjs-jquery-flot (>= 0.8.2), libjs-jquery-ui, django-testscenarios, android-tools-adb, android-tools-fastboot, python | python-all | python-dev | python-all-dev, pep8 | python-pep8, python-sphinx (>= 1.0.7+dfsg) | python3-sphinx, po-debconf, python-mocker, python-setuptools, python-versiontools, python-yaml, docbook-xsl, xsltproc, python-mock python | python-all | python-dev | python-all-dev is the same as other binaries built from the same source which correctly pass lintian checks. - System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.26-6 ii bzip2 1.0.6-8 ii diffstat 1.61-1 ii file 1:5.25-2 ii gettext 0.19.7-2 ii hardening-includes2.8+nmu2 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.29+b5 ii libarchive-zip-perl 1.56-2 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-1+b1 ii libdata-alias-perl1.20-1+b1 ii libdpkg-perl 1.18.4 ii libemail-valid-perl 1.198-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.94-1 ii liblist-moreutils-perl0.413-1+b1 ii libparse-debianchangelog-perl 1.2.0-8 ii libperl5.22 [libdigest-sha-perl] 5.22.1-9 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.71-1 ii libyaml-libyaml-perl 0.41-6+b1 ii man-db2.7.5-1 ii patchutils0.3.4-1 ii perl 5.22.1-9 ii t1utils 1.39-2 ii xz-utils 5.1.1alpha+20120614-2.1 Versions of packages lintian recommends: ii dpkg 1.18.4 pn libperlio-gzip-perl ii perl 5.22.1-9 ii perl-modules-5.22 [libautodie-perl] 5.22.1-9 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.4 ii libhtml-parser-perl3.72-1 ii libtext-template-perl 1.46-1 -- no debconf information
Bug#801717: lintian: False positive for source-is-missing
On Wed, 14 Oct 2015 11:17:40 +0800 Paul Wise <p...@debian.org> wrote: > On Tue, 13 Oct 2015 20:48:48 +0100 Neil Williams wrote: > > > lava_server/htdocs/js/jquery.validate.js > > lava_server/lava-server/js/jquery.validate.js > > Are you sure these files are source for the jQuery validation plugin? The plugin which isn't packaged (cannot be packaged currently if it does need grunt) and which I cannot therefore use? These js files are effectively part of the source code of lava-server, not the JQuery upstream - lintian should not be making any decisions based on things which are not in the archive. > Looking at the upstream git repo for the jQuery validation plugin the > source is a bunch of separate files instead of just one file. > > https://github.com/jzaefferer/jquery-validation/ This isn't packaged, therefore, lintian cannot know about them. Anything lintian has to say about things which are not packaged for Debian can only be under the --pedantic classification. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgppROMN3mxYN.pgp Description: OpenPGP digital signature
Bug#801717: lintian: False positive for source-is-missing
Package: lintian Version: 2.5.38 Severity: normal lintian is complaining about source-is-missing in the lava-server binary package for these files. The files are present in the package as source: dashboard_app/static/dashboard_app/js/jquery.flot.navigate.js lava_scheduler_app/static/lava_scheduler_app/js/beautify.js lava_scheduler_app/static/lava_scheduler_app/js/shCore.js lava_server/htdocs/js/jquery.validate.js lava_server/lava-server/js/jquery.validate.js lava-server has support for using a number of javascript packages and using symlinks to the minified javascript files in those packages. I'm unclear why these files are being listed as lacking source as these are not minified javascript files. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.25.1-7 ii bzip2 1.0.6-8 ii diffstat 1.60-1 ii file 1:5.25-2 ii gettext0.19.6-1 ii hardening-includes 2.7 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.29+b3 ii libarchive-zip-perl1.53-1 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.38-1 ii libdpkg-perl 1.18.3 ii libemail-valid-perl1.196-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl0.94-1 ii liblist-moreutils-perl 0.413-1 ii libparse-debianchangelog-perl 1.2.0-8 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.69-1 ii man-db 2.7.4-1 ii patchutils 0.3.4-1 ii perl [libdigest-sha-perl] 5.20.2-6 ii t1utils1.38-4 ii xz-utils 5.1.1alpha+20120614-2.1 Versions of packages lintian recommends: ii dpkg1.18.3 pn libperlio-gzip-perl ii perl5.20.2-6 ii perl-modules [libautodie-perl] 5.20.2-6 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.3 ii libhtml-parser-perl3.71-2 ii libtext-template-perl 1.46-1 ii libyaml-perl 1.13-1 -- no debconf information
Re: lintian and Debian derivatives
On Thu, 07 Jul 2011 00:25:59 +0200 Paul Wise p...@debian.org wrote: As a member of the Debian derivatives front desk (CCed) and initiator of the derivatives census, which aims to make derivatives more visible to Debian, I figured I should update lintian folks on the state of lintian development and usage in Debian derivatives. Just a note, Emdebian is involved in lintian testing for Emdebian packages, via the new lintian profile support (based on DEB_VENDOR), but as the current Emdebian release (Grip) is binary-compatible with Debian, the emphasis is on ensuring that the processed packages comply with the Emdebian Policy changes from Debian Policy. (Specifically, allow the removal of manpages and other files which lintian would otherwise output as missing, allow compression where Debian does not, etc.) Once MultiArch is in place with cross-building support, things will change and Emdebian will again start using lintian in earnest. Quite how and where the lintian tests are run is largely a problem of resources. In addition, there is one derivative that I know of that has current and public lintian web pages, but I guess that one is well known by lintian maintainers since I guess it is run by Russ. It is a shame that lintian pages aren't more widespread within our derivatives. I guess some use it on the packages during their build process but I wonder how we could encourage them to use it more, anyone have any thoughts? Lintian requires a lot of resources if it's to be run automatically against an entire distribution. Emdebian will look at lintian reports for cross-built stuff but that's only because that is likely to be limited to less than a thousand source packages. Even then, I'm expecting the full lintian test to take almost as long as it currently takes to process the daily updates to Emdebian Grip. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp6I4ZpEPdo1.pgp Description: PGP signature
Re: Vendor-based customization of Lintian (or profiles)
On Tue, 19 Apr 2011 20:04:47 +0200 Niels Thykier ni...@thykier.net wrote: [Needed] * No code changes: - It must be possible to alter whether Lintian emits a tag without modifying code. * Re-usable: - Most profiles will likely be based on the core profile. New profiles should be able to extend existing profile. - Extended profile must be able to include tags not originally in the original profile. - Extended profile must be able to exclude tags originally in the original profile. * Add vendor/3rd party checks [Deferred]: - A profile may include new checks/collections not present in the Lintian package itself. * A tag not included in the current profile shall not be emitted. - An override for such a tag is not considered unneeded and must be ignored. Emdebian tried this and came up against a few hidden assumptions in lintian which we discussed with the lintian maintainers at the time. We experimented with an emdebian checks file and desc file: http://packages.debian.org/sid/all/emdebian-crush/filelist If this proposal completes the final stage of that process, I will be v.happy. :-) Another common requirement at work is to switch off the lintian warning about unsupported distributions as we're trying to build lintian-clean packages for our own internal repositories and it makes apt pinning a lot easier to *not* use stable, testing, unstable or any of the Debian ToyStory codenames. If that can be done with a simple file which applies across all packages, it will just be so much easier. Rationale for deferring Add checks: Fixing this is effectively to fix the third party checks problem and this adds complexity like how to handle name clashing with checks/collections. We will have that debate eventually. It is my belief that it will be easier for us to add the third party checks on top on the profile system than the other way around (infrastructure wise). That makes the third-party responsible for avoiding clashes - which is, IMHO, the way it should work. Also, as soon as we add third party checks our current collections as well as our check interface becomes part of our API. Changing any of these could possibly break other packages. Proposed solution - We add a new directory to the Lintian root called profiles with the structure: profiles/ debian/ main.profile ftp-auto-reject.profile ubuntu/ main.profile $other_vendor/ some.profile default I think there should be support for dpkg-vendor in this situation. If DEB_VENDOR is defined, lintian can look for that profile. Emdebian has been doing this for some time with emvendor but not (yet) with lintian. Profiles should be specified with a new command line argument --profile profile or the environment/lintianrc variable LINTIAN_PROFILE=profile. IMHO DEB_VENDOR is a better fit. When we agree on (the basis of) an implementation (not necessarily the one proposed here) I suggest we add it to the Debian wiki under Lintian/Spec/VendorCustomization (or similar). This way the specification does not suddenly get lost on the mailing list and we can easily update it later. Any patches? :-) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpsoi6oCLH7K.pgp Description: PGP signature
Re: Vendor-based customization of Lintian (or profiles)
On Tue, 19 Apr 2011 21:02:27 +0200 Niels Thykier ni...@thykier.net wrote: Emdebian tried this and came up against a few hidden assumptions in lintian which we discussed with the lintian maintainers at the time. We experimented with an emdebian checks file and desc file: http://packages.debian.org/sid/all/emdebian-crush/filelist If this proposal completes the final stage of that process, I will be v.happy. :-) Do you have a link to that debate; unfortunately I believe it was before my involvement with Lintian, so I do not believe I have seen it (unless it is covered in the DC10 notes from the BoF). Not really. I did describe some of the results to the Emdebian folks: http://lists.debian.org/debian-embedded/2008/04/msg3.html http://lists.debian.org/debian-embedded/2009/12/msg00032.html The other discussions with Russ were mostly direct email and/or discussions at DebConf9. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpKvBnkJLj0z.pgp Description: PGP signature
Bug#575400: lintian does not allow overriding bad-distribution-in-changes-file
Package: lintian Version: 2.3.4 Severity: wishlist When working with packages not intended for upload to Debian but used with internal repositories to create systems based on Debian, it is still useful to run lintian over the results of dpkg-buildpackage. Such configurations have non-standard suites and codenames, targeted at our own releases and schedules, and these are included in the .changes files so that reprepro and other tools can handle the .changes files correctly upon local upload. lintian does not appear to accept an override for a bad-distribution-in-changes-file where we need to use development instead of unstable. Please allow lintian to support an override in debian/source.lintian-overrides to clear this warning. Current source overrides for the package concerned: $ cat debian/source.lintian-overrides section-category-mismatch ancient-standards-version bad-distribution-in-changes-file section-area-mismatch missing-debian-source-format -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.20.1-3 The GNU assembler, linker and bina ii diffstat 1.47-1produces graph of changes introduc ii dpkg-dev 1.15.5.6 Debian package development tools ii file 5.04-1Determines file type using magic ii gettext0.17-10 GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.24Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1Perl module that automatically gen ii libipc-run-perl0.84-1Perl module for running processes ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl1.53-1module to manipulate and access UR ii locales2.10.2-6 Embedded GNU C Library: National L ii man-db 2.5.7-2 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-11 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.7-2on-line manual pager -- no debconf information -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpbxzkjA6z3m.pgp Description: PGP signature
Bug#575400: lintian does not allow overriding bad-distribution-in-changes-file
On Thu, 25 Mar 2010 11:25:51 -0700 Russ Allbery r...@debian.org wrote: There's really no way for Lintian to use information from the source package to override tags for the *.changes file. Those are two entirely separate objects to Lintian, and the *.changes file is parsed and tags emitted for it before the source package is looked at. I suspected that from a cursory glance at the source code. The supported way of handling unwanted tags from the *.changes file is to suppress them from the command line: lintian --suppress-tags bad-distribution-in-changes-file Sounds like an alias is required . . . which will accomplish functionally the same thing as an override. There's an open bug to allow one to put things like that into a configuration file, which is definitely something we want to support going forward. Does that sound like a reasonable solution to you? Yes, feel free to merge this bug report into the bug seeking a per-system configuration file. Is that the support where a package can drop in a config file into a lintian/overrrides.d/ type directory? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpOR3CJqC9xH.pgp Description: PGP signature
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
containing debconf questions should always be reviewed before upload and that review will lead to at least some translations. BTW mentors may require that repeated uploads to mentors.debian.net during the process of review and testing get full descriptive entries in the changelog for what has actually been done during the sponsoring process. So a single changelog entry is not a predicate of a NEW package. I'd like to see severity important but normal would be OK for starters. Remember, the rule of thumb here is that severity should match the severity that you'd pick for the bug that you filed about the problem, were you to file a bug. Important is a rather large leap over the current severities used for translations. Debconf is a little different. It is a peculiar problem that if a new debconf question is not translated, the user does not get the chance to reconsider their answer when the translation finally arrives. Normal severity would be fine if important is deemed a step too far. I still think it is worth enforcing no untranslated debconf questions in debian-mentors as a point of good practice - even if the lintian tag severity is not changed in order to avoid annoying existing DD's. Mentors should be about raising the quality of NEW packages and package updates (especially QA uploads etc.) and all packages coming through mentors should be up to the latest measures of Policy, Standards and general behaviour. Maybe lintian could be more aggressive for checks performed during sponsoring than when being used by more experienced DD's. ;-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpi1r7jP4xr5.pgp Description: PGP signature
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
On Mon, 19 Jan 2009 18:27:40 +0100
Christian Perrier bubu...@debian.org wrote:
Quoting Neil Williams (codeh...@debian.org):
Yes, we can change the severity, although I'd like to run that past
debian-i18n first.
Christian - this is a slightly different problem to what you first
thought. It isn't that some translators have answered and some have
not, it is that a new question has been added and nobody at all has
replied. If a sane deadline is set, isn't it unlikely that not one of
the language teams managed to get a translation to the maintainer in
time? It is far more likely that the maintainer didn't ask the
translation teams before uploading the new question.
I agree here. If you manage to get through the problem of having to
examine binary packages' templates, then I agree that having a
template that's marked translatable and *no* translation at all makes
it very likely that no call for translations was issued when the
templated was added.
Something like this should work:
# i18n -- lintian check script -*- perl -*-
package Lintian::codehelp;
use strict;
use Tags;
use Util;
sub run {
my $pkg = shift;
my $type = shift;
if (-f control/templates)
{
my $incomplete;
my $stanza;
open (I18N, '', control/templates) or
fail (cannot open lintian templates: $!);
while (I18N)
{
if (/^Description: /)
{
$stanza++;
undef $incomplete;
next;
}
undef ($stanza) if (/^Description-/);
if ((defined ($stanza) and (/^Template:/)))
{
$incomplete++;
last;
}
}
close (I18N);
tag (ch-package-contains-docs, templates) if (defined $incomplete);
}
}
1;
control/templates is safe as we're checking the binary here - we don't
want to be checking debian/foo.templates. It's not perfect, it probably
also need to check that this isn't a source package with:
return if ($type eq source);
and output the $pkg variable instead of the rather bland templates.
It simply says that once a Description has been found, there must be a
Description- (this too can be improved) before the next empty line and
following Template stanza. That might need improvement to catch the
last question in the file, especially if there is no terminal newline.
I've not used a sensible tagname either.
Under what circumstances are questions untranslated? There should
always be some help text that needs translation.
By fairly likely, I mean quite certain, indeed
The tag name might have to change:
new-question-without-translations
that would certainly help avoiding the case where maintainers entirely
drop existing translations
A properly worded long information will also help.
I'm sure we can come up with that. Something based on:
debconf only ever asks the same question once - to be effective, that
question should be translated the very first time that question is
offered to the user. Translating it after the user has answered the
question in English is pointless - at least as far as that user is
concerned.
.
This package contains a template file containing at least one question
that has not been translated at all. This means that translators
were not properly warned about new strings.
.
Translators may be notified of changes using podebconf-report-po, for
example:
.
podebconf-report-po --call --withtranslators --deadline=+10 days \
--languageteam
Ref: devref 6.5.2.2
I can spend some more time on this, if you'd like a fully tested patch Russ.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpYwNSe5z91E.pgp
Description: PGP signature
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
On Mon, 19 Jan 2009 12:20:40 -0800
Russ Allbery r...@debian.org wrote:
If I check the generated templates in the binary deb, how do I check that
the string was marked for translation? We don't want to trigger this tag
on strings that aren't intended to be translated.
TBH I was expecting that all questions would be translated - at least
the help text (Description), even if not the possible answers.
Otherwise, doesn't it tend to indicate that debconf is being used as a
registry?
The empirical answer, at the moment, would be as described earlier:
Template:
...
Description:
Template:
should fail - with the proviso that the last question in the file also
needs to be allowed to fail, so check for EOF as well.
Template:
...
Description:
Description-
...
Template:
would pass.
A quick check finds these files on my system that contain unexpected
content like:
Template: debconf-apt-progress/info
Type: text
Description: ${DESCRIPTION}
Template: debconf-apt-progress/media-change
Type: text
Description: Media change
${MESSAGE}
How are those variables utilised? Where and how could these be
translated?
debconf.templates failed
console-data.templates failed
x11-common.templates failed
gdm.templates failed
console-setup.templates failed
tasksel.templates failed
dbconfig-common.templates failed
linux-image-2.6.24-1-amd64.templates failed
linux-image-2.6.25-2-amd64.templates failed
linux-image-2.6.26-1-amd64.templates failed
That's using a script based on the perl script from the other message.
Out of 65 templates on this system, it's a start.
Choices is a little awkward but I cannot see a scenario where Choices
is *translated* but the Description *is not* so basing the check on
Description alone (to avoid a more common case where Choices is not
translatable) is appropriate, AFAICT.
x11 has:
Template: x11-common/xwrapper/actual_allowed_users
Type: string
Description: internal use only
This template is never shown to the user and does not require
translation.
Others include:
Template: console-data/bootmap-md5sum
Type: string
Default: none
Description: for internal use
Template: gdm/daemon_name
Type: string
Default: /usr/bin/gdm
Description: for internal use only
Template: console-setup/modelcode
Type: string
Description: for internal use
Template: console-setup/layoutcode
Type: string
Description: for internal use
Template: console-setup/variantcode
Type: string
Description: for internal use
Template: console-setup/optionscode
Type: string
Description: for internal use
Template: console-setup/fontsize
Type: string
Description: for internal use
Template: console-setup/codesetcode
Type: string
Description: for internal use
Those all look wrong to me - debconf for internal use only?
Template: tasksel/desktop
Type: multiselect
Choices: gnome, kde, xfce
Default: gnome
Description: The desktop environment to install when the desktop task
is selected This can be preseeded to change the default.
(That tasksel one looks like a true positive - I can't see why that is
not translated.)
Template: dbconfig-common/missing-db-package-error
Type: select
Choices: abort, retry, ignore
Default: abort
Description: Database package required.
To properly configure the database for ${pkg}, it is necessary
that you also have ${dbpackage} installed. Unfortunately, this can
not be done automatically.
.
If in doubt, you should choose abort, and install ${dbpackage} before
continuing with the configuration of this package. If you choose
retry, you will be allowed to choose different answers (in case you
chose the wrong database type by mistake). If you choose ignore,
then installation will continue as normal.
.
(Note to translators: don't bother translating this message yet, as the
text/wording is not stabilized)
Hmm. That's going to be tricky to identify but probably OK for an
override.
linux-image-2.6.24-1-amd64.templates - none of the strings appear to be
translated and to my eye, all should have been - true positive?
Ditto for linux-image-2.6.25-2-amd64.templates and
linux-image-2.6.26-1-amd64.templates
I'm attaching the script so that others can check their templates
files. (Consider it under the GPL-3+, Copyright me 2009. Note that
it does not currently check for EOF correctly.)
So, overall, only one package needs an override from this cursory
glance at one machine, two packages (four template files) look like
correct checks that should have been caught before (probably) and
another 4 that are using debconf for internal use which seems to be
against the spirit of debconf, to me anyway.
Oh and before anyone asks, I'm not saying that the true positive checks
or the internal use only templates need to be fixed for Lenny. ;-)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
#!/usr/bin/perl
opendir (LINT, /var/lib/dpkg/info/);
@files=grep(/templates$/, readdir(LINT));
closedir (LINT);
foreach $file
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
On Mon, 19 Jan 2009 14:54:26 -0800 Russ Allbery r...@debian.org wrote: Neil Williams codeh...@debian.org writes: Russ Allbery r...@debian.org wrote: If I check the generated templates in the binary deb, how do I check that the string was marked for translation? We don't want to trigger this tag on strings that aren't intended to be translated. TBH I was expecting that all questions would be translated - at least the help text (Description), even if not the possible answers. Otherwise, doesn't it tend to indicate that debconf is being used as a registry? Private templates are extremely common. We can't realistically do anything that would warn about private templates. It will just annoy a lot of people. OK, I think there is a way of identifying private templates. It could be as simple as agreeing (after Lenny) that a particular Description is uniformly used for all private templates. That would help translators too. Most already seem to use for internal use. After all, the description itself is completely arbitrary as far as internal templates are concerned. Indeed, simply adding one line to the test script could be enough: next if ($line =~ /^Description: .*[for ]?internal use/); Which gives: (excluding debconf.templates as you described) tasksel.templates failed dbconfig-common.templates failed linux-image-2.6.24-1-amd64.templates failed linux-image-2.6.25-2-amd64.templates failed linux-image-2.6.26-1-amd64.templates failed dbconfig probably needs an override and the others look like correct checks. Until there is consensus on the syntax for private templates, the lintian test could stay at lower severity. Description: For internal use only That would match too - so it would be ignored for the test. I think this sort of thing is quite common. As long as a particular identifier can be used for all (and the lintian test can provide information on that identifier in the guide text), that shouldn't be a problem. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprvn2hu4gOp.pgp Description: PGP signature
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
Package: lintian
Version: 2.1.6
Severity: wishlist
Tags: l10n
http://people.debian.org/~codehelp/#debconf
http://lists.debian.org/debian-mentors/2009/01/msg00178.html
I've been thinking about translation and debconf, partially due to my
work on TDebs etc. I think there are good reasons to consider any
untranslated debconf templates as automatically buggy.
debconf only ever asks the same question once - to be effective, that
question should be translated the very first time that question is
offered to the user. Translating it after the user has answered the
question in English is pointless - at least as far as that user is
concerned.
So, I wonder if lintian could extend checks/po-debconf to raise an error
not only if any package contains a completely untranslated set of templates
but also check if a single question is untranslated even if the rest
of the templates have one or more translations.
It is important that if a question is translated, even just once, that
the error is not issued - only questions that have no translations at
all should generate the error.
Maybe for Squeeze it could even be a release goal that no package using
debconf is uploaded without the translations being updated. A lintian
test would be a useful stage in such a process.
'msgfmt -c --statistics' will output the status of the debian/po files
or it may just be simpler to parse the templates file(s) in the binary
package(s) and check for any 'Description' that does not have a
'Description-[a-z]{2}\..*:' in the corresponding Template: stanza.
e.g.:
Template: emsource/svnusername
Type: string
Description: Subversion login to use on buildd.emdebian.org:
...
Description-cs.UTF-8: Uživatelské jméno pro subversion na
buildd.emdebian.org:
...
Description-eu.UTF-8: buildd.emdebian.org-en erabiliko den subversion
erabiltzaile izena:
...
Description-fi.UTF-8: Koneella buildd.emdebian.org käytettävä
Subversion-tunnus:
...
Template: emsetup/aptagent
...
Deliberately breaking that stanza produces:
Template: emsource/svnusername
Type: string
Description: Subversion login to use on buildd.emdebian.org:
...
.
Deliberately compromising the question to break translations
Template: emsetup/aptagent
...
No lintian warning is raised after this act of wanton vandalism. ;-)
$ lintian -Ii ../build-area/libemdebian-tools-perl_1.4.15_all.deb
$
lintian (2.1.6)
The lack of a Description-$foo at the start of a line after a
Description: but before the next empty line would indicate the error
with a high degree of certainty. (UTF-8 is by no means a reliable
token, sadly).
A lintian error would also provide a quite useful hook for various
l10n scripts that may exist or will soon be written by myself and/or
Christian Perrier, just by parsing lintian.debian.org. It would provide
very useful data on existing translation support and assist me in the
development of a range of TDeb support code.
An extension like this would complement the existing support for
newer-debconf-templates and no-complete-debconf-translation.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages lintian depends on:
ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii diffstat1.46-1 produces graph of changes introduc
ii dpkg-dev1.14.24 Debian package development tools
ii file4.26-2 Determines file type using magic
ii gettext 0.17-6 GNU Internationalization utilities
ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii libipc-run-perl 0.82-1 Perl module for running processes
ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output
ii libtimedate-perl1.1600-9 Time and date functions for Perl
ii liburi-perl 1.37+dfsg-1 Manipulates and accesses URI strin
ii man-db 2.5.2-3 on-line manual pager
ii perl [libdigest-sha 5.10.0-19Larry Wall's Practical Extraction
lintian recommends no packages.
Versions of packages lintian suggests:
ii binutils-multiarch 2.18.1~cvs20080103-7 Binary utilities that support mult
ii libtext-template-pe 1.44-1.2 Text::Template perl module
ii man-db 2.5.2-3 on-line manual pager
-- no debconf information
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
On Sun, 18 Jan 2009 10:22:09 -0800 Russ Allbery r...@debian.org wrote: Neil Williams codeh...@debian.org writes: debconf only ever asks the same question once - to be effective, that question should be translated the very first time that question is offered to the user. Translating it after the user has answered the question in English is pointless - at least as far as that user is concerned. So, I wonder if lintian could extend checks/po-debconf to raise an error not only if any package contains a completely untranslated set of templates but also check if a single question is untranslated even if the rest of the templates have one or more translations. I must be missing something -- why doesn't no-complete-debconf-translation catch that? That's its intention as I understand it; in fact, it's even stricter than what you're proposing. Is it just buggy? Well that check only works on the source package and only uses msgfmt - it could probably be improved with a check on the binaries and the actual templates file(s). In the original report, I only tested against the .deb. The no-complete-debconf-translation check is not high enough severity to show up without -I when checking the source package. If the binary check is added, the certainty can be raised and also the severity. With that change, the description could be made more strict: Info: Even though this package provides debconf translation support, there are either no translations or none of the translations are complete. This will mean that users are expected to answer the new question(s) exclusively in English. You should always call for translations for any new strings before uploading new debconf questions because debconf only asks any question once. I'd like to see severity important but normal would be OK for starters. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpVCCQa4KB97.pgp Description: PGP signature
Bug#510190: lintian: missing-dep-for-interpreter confused by unusual layout
Package: lintian Version: 2.1.3 Severity: normal I'm designing a fairly unusual package which contains the source to build another package as well as scripts and other files for the main package. Therefore, /usr/share/foo/ contains a debian/ directory with debian/rules and postinst files as well as a copyright, control etc. ;-) (The built package is entirely free software but cannot be uploaded to Debian as it does non-Policy stuff with unrelated packages.) Yes, embedded stuff can get a little weird at times. The main package (the outer package) is to be installed on a server that builds, maintains and updates a repository of packages for machines running the Grip flavour of Emdebian. In order to work around bugs as they appear (and during times when such bugs cannot be fixed, e.g. during release freezes), Grip provides for a helper package - grip-config - which only exists inside the Grip repository created by the main package. When grip-config needs to be updated, the main package containing the source is updated and the admin can build the grip-config package and update the repository. Rather than require the debian/ directory for grip-config to be checked out of Emdebian SVN, I thought I'd add the entire package build metadata into the server-side package and update the server package when the helper package needs an update. In practice, the server side package will need more frequent updates than the helper package anyway. The server-side package depends on dpkg-dev and lintian complains: E: emdebian-grip-server: missing-dep-for-interpreter make = make | build-essential (./usr/share/emdebian-tools/grip-config/debian/rules) N: N:You used an interpreter for a script that is not in an essential N:package. In most cases, you will need to add a Dependency on the package N:that contains the interpreter. If the dependency is already present, N:please file a bug against Lintian with the details of your package so N:that its database can be updated. N: N:In some cases a weaker relationship, such as Suggests or Recommends, N:will be more appropriate. N: N:Severity: important; Certainty: possible dpkg-dev depends on make and Recommends build-essential. I'm expecting to use lndir or similar to create a writeable directory containing the relevant build files for grip-config, use dpkg-buildpackage -uc- us and then include the generated .changes file directly into the repository maintained by emdebian-grip-server and remove the build directory. This could become a script within emdebian-grip-server itself in due course. I appreciate this is an unusual situation, but could dpkg-dev be accepted by lintian as providing the relevant interpreter for debian/rules when installed in /usr/share/ ? -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.46-1 produces graph of changes introduc ii dpkg-dev1.14.24 Debian package development tools ii file4.26-2 Determines file type using magic ii gettext 0.17-6 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libipc-run-perl 0.80-2 Perl module for running processes ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.37+dfsg-1 Manipulates and accesses URI strin ii man-db 2.5.2-3 on-line manual pager ii perl [libdigest-sha 5.10.0-18Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.18.1~cvs20080103-7 Binary utilities that support mult ii libtext-template-pe 1.44-1.2 Text::Template perl module ii man-db 2.5.2-3 on-line manual pager -- debconf-show failed -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507278: lintian: complains about uninitialized values for severity and certainty
clone -1 reassign -1 emdebian-tools retitle -1 emdebian.desc lintian checks should include certainty values severity 507278 wishlist retitle 507278 please check for out-of-sync check files in /usr/share/lintian/checks thanks On Sat, 29 Nov 2008 18:20:16 + Adam D. Barratt [EMAIL PROTECTED] wrote: On Sat, 2008-11-29 at 18:26 +0100, Neil Williams wrote: lintian has started outputting a lot of perl warnings: Use of uninitialized value $severity in hash element at /usr/share/lintian/lib/Tags.pm line 293. Use of uninitialized value $certainty in hash element at /usr/share/lintian/lib/Tags.pm line 293. (repeated once for each test) In this particular case, I was running lintian after a build of the current version of ipsec-tools in unstable/testing (without changes). Apologies for the amount of information requested, but the warnings suggest that something is quite broken, and I can't reproduce them locally. The above sounds like lintian's not reading the tag files from /usr/share/lintian/checks/*.desc properly. The number of occurrences of Tag:, Severity: and Certainty: in each file should match. Ah. In that case, the problem is /usr/share/lintian/checks/emdebian.desc I didn't know that the desc file had to be updated. Would it be possible to get hold of a copy of the package(s) you're checking? I've just done apt-get source ipsec-tools; pdebuild on an amd64 unstable box and lintian 2.1.0 didn't produce any perl warnings when run against the .changes, .dsc or .deb. It would be good if lintian wasn't quite so noisy about such errors, hence I've cloned this as wishlist for lintian as well as reassigning to emdebian-tools. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp0tkI5mLuPN.pgp Description: PGP signature
Bug#507278: more uninitialized values with lintian --color=auto
$ alias | grep lintian alias lintian='lintian --color=auto' $ lintian ../ipsec-tools_0.7.1-1.3_amd64.changes Use of uninitialized value $_ in split at /usr/share/perl/5.10/Term/ANSIColor.pm line 121. Use of uninitialized value in concatenation (.) or string at /usr/share/perl/5.10/Term/ANSIColor.pm line 187. W: ipsec-tools source: debhelper-but-no-misc-depends ipsec-tools Use of uninitialized value $_ in split at /usr/share/perl/5.10/Term/ANSIColor.pm line 121. Use of uninitialized value in concatenation (.) or string at /usr/share/perl/5.10/Term/ANSIColor.pm line 187. W: ipsec-tools source: debhelper-but-no-misc-depends racoon Use of uninitialized value $_ in split at /usr/share/perl/5.10/Term/ANSIColor.pm line 121. Use of uninitialized value in concatenation (.) or string at /usr/share/perl/5.10/Term/ANSIColor.pm line 187. W: ipsec-tools source: out-of-date-standards-version 3.7.3 (current is 3.8.0) Use of uninitialized value $_ in split at /usr/share/perl/5.10/Term/ANSIColor.pm line 121. Use of uninitialized value in concatenation (.) or string at /usr/share/perl/5.10/Term/ANSIColor.pm line 187. W: racoon: non-dev-pkg-with-shlib-symlink usr/lib/libracoon.so.0.0.0 usr/lib/libracoon.so Use of uninitialized value $_ in split at /usr/share/perl/5.10/Term/ANSIColor.pm line 121. Use of uninitialized value in concatenation (.) or string at /usr/share/perl/5.10/Term/ANSIColor.pm line 187. W: racoon: package-name-doesnt-match-sonames libracoon0 Use of uninitialized value $_ in split at /usr/share/perl/5.10/Term/ANSIColor.pm line 121. Use of uninitialized value in concatenation (.) or string at /usr/share/perl/5.10/Term/ANSIColor.pm line 187. W: ipsec-tools: package-name-doesnt-match-sonames libipsec0 The errors go away if I avoid the alias using /usr/bin/lintian. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpbH699ZTSI3.pgp Description: PGP signature
Bug#471263: Generated changes and patch systems
Oops, sent to the wrong bug report. On Wed, 2008-05-28 at 11:45 +0100, Neil Williams wrote: On Tue, 2008-05-27 at 18:06 -0700, Russ Allbery wrote: Neil Williams [EMAIL PROTECTED] writes: On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote: Lots of other packages do this -- one of mine off the top of my head is xml-security-c. Nope. No mention of aclocal.m4 in debian/rules for that package, just /usr/share/misc/config.guess and config.sub. Uh, it's the same problem. Surely the generalization is obvious? It's not quite the same problem because aclocal.m4 is regenerated in the clean rule itself because changing it causes ./configure --recheck to recreate the (modified) file. So instead of copying it around, it has to be deleted - merely because a patch system is in use. Seems crazy to me. I need to patch configure and configure.ac in this package, that means that aclocal.m4 is constantly being changed and reverted. It shouldn't matter - it really should not. Right, so delete it in the clean rule. OK. It's a bit like collateral damage - need a patch to configure, patching causes configure --recheck which modifies aclocal.m4 so delete aclocal.m4. Hmmm. I don't like it but I'll do it anyway. I see no purpose in lintian (or dpkg come to that) testing for changes in aclocal.m4 - IMHO it should simply be exempt from this check. Absolutely not -- you're introducing unexpected changes to the packaging diff file, Well my point is that the change is entirely expected (because the patch modifies a file that is involved in generating the changes) - the changes are merely a consequence of the patch. It feels wrong to have to add a clean rule for aclocal.m4 as a direct result of patching configure.ac when aclocal.m4 was not a problem before the patch. Anyway, the problem of the tmpl/* files is far more resistant. I really don't want to do all that for the tmpl/* files as well - I don't see the need, copying dozens of files into foo.safe or foo.upstream and then moving them back? Just delete them then. ??? That simply does not work. The problem is that running gtk-doc not only requires tmpl/*.sgml files to exist but it *then modifies them*! This is extremely unusual. Are you *sure* that it does an inplace edit of the files during the build process? $ ls libgpewidget-0.115.orig/doc/tmpl/ -1 colordialog.sgml color-slider.sgml dirbrowser.sgml errorbox.sgml gpeclockface.sgml gpehelp.sgml gpeiconlistitem.sgml gpe-iconlist.sgml gpeiconlistview.sgml gpetimesel.sgml gpewindowlist.sgml gtkdatecombo.sgml gtksimplemenu.sgml infoprint.sgml init.sgml libgpewidget-unused.sgml picturebutton.sgml pixmaps.sgml popup_menu.sgml popup.sgml question.sgml smallbox.sgml spacing.sgml stylus.sgml translabel.sgml tray.sgml windows.sgml From the build log: gtkdoc-mkdb --module=libgpewidget --source-dir=.. --output-format=xml --sgml-mode --output-format=xml --tmpl-dir=tmpl Now running lintian... W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/color-slider.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colordialog.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colorrenderer.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpeclockface.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpedialog.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpehelp.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtkdatecombo.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtksimplemenu.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/libgpewidget-unused.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/link-warning.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/pixmaps.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/smallbox.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/spacing.sgml Finished running lintian. 13 out of 27 files modified by gtk-doc. Copy those files back into doc/tmpl/ from the upstream source and they are still modified at the next build. Add a rm -f doc/tmpl/*.sgml to clean:: and the build fails: No rule to make doc/tmp/*.sgml So, yes, --enable-gtkdoc is modifying files included upstream and which are essential to the build process. If I drop --enable-gtkdoc I get different contents in the libgpewidget-doc package. This is almost never what build systems do; instead, they generate files from other files using templating systems. They may ship the results of that operation and then redo it during the build, in which case you need to delete
Generated files and patch systems
have been changed, hence no patches. This, to me, is where the all changes are patches approach falls down. A patch, IMHO, is a deliberate action - similar to a GnuPG signature on an email. It should require a conscious act to solve an identifiable problem - preferably one with a bug report. Changes that result merely from differences in build environment between upstream and Debian should not even be in the .diff.gz if at all possible - such changes are, IMHO, certainly not deliberate actions by the maintainer. Changes that themselves change independently of the actions of the maintainer cannot be implemented by the maintainer as patches, imho. The silent build is available from my repo: dget -x http://www.linux.codehelp.co.uk/packages/pool/main/libg/libgpewidget/libgpewidget_0.116-1.dsc I won't upload to ftp-master just yet - I do need to do some more tests to ensure that other GPE packages build and function correctly so that I don't inadvertently trigger a transition in over 40 packages. ;-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: lintian for Emdebian
On Thu, 2008-04-03 at 16:59 -0700, Russ Allbery wrote:
Neil Williams [EMAIL PROTECTED] writes:
We should support a global overrides file or directory. I'd be happy to
add that functionality, but it does probably require code changes now that
I think about this some more.
Yes, it would need to either be duplicated into %info under the $file
key of each package or held as a separate reference and checked in
check_overrides() of Tags.pm or simply duplicate the existing code to
read package overrides:
unless ($no_override) {
if (open(O, '', $base/override)) {
while (O)
which means reading the global override file more than once.
I've played with a global override directory and I've included some
working perl code below. However, there are problems with using this as
a global and I've also included sample code for an alternative method
that does not involve a global directory but actually retains complete
control over the overrides within the specific check script itself. (So
this email is a bit long.) :-)
However, I'm finding it impossible to override the manpage warnings
without removing all the manpages checks with -X :
I don't actually need the manpages checks but I would like to not have
to alias lintian to lintian -X manpages.
Where are you adding the overrides? Is it possible that the manpage check
script is happening before your overrides are added?
Is there a way of implementing '-X' within the check scripts? (It would
save time if I could drop entire scripts like manpages and replace with
a simple check that /usr/share/man/ is empty).
You could divert the manpages file, but there isn't any way to skip an
entire check from within another check (in part because the order in which
the checks are run is not, I think, fully deterministic, although I could
be wrong -- I think it runs them in glob order).
Not AFAICT at the readdir stage:
$ perl -le 'opendir DIR, /usr/share/lintian/checks; print join , readdir
DIR'
emdebian appears there before manpages.
. .. changelog-file.desc po-debconf.desc emdebian init.d scripts
copyright-file.desc emdebian.desc menu-format description.desc
common_data.pm shared-libs md5sums etcfiles menu-format.desc cruft.desc
debconf files standards-version menus.desc fields conffiles.desc
standards-version.desc manpages.desc conffiles control-file.desc
etcfiles.desc nmu.desc huge-usr-share.desc debconf.desc infofiles
files.desc control-files description fields.desc cruft init.d.desc nmu
debian-readme.desc copyright-file menus infofiles.desc debhelper rules
manpages
No, the problem appears to be only when running the checks due to the
arbitrary way that perl indexes hashes:
# perform checks
for my $check (keys %checks) {
my $ci = $check_info{$check};
Sorting those keys puts manpages behind emdebian but then puts copyright
ahead of emdebian which means that the copyright overrides are missed
instead. :-(
I can hack around it by then making the emdebian checks to be 00emdebian
etc. but that is ugly.
I think the right approach may be to create a directory
/usr/share/lintian/overrides/global and load all files in that directory
in addition to the regular overrides.
Even that needs some flexibility because I currently use
Tags::add_override to selectively override tags dependent on the type of
package so that I don't get too many unused overrides.
My current override set is:
binary-or-shlib-defines-rpath
binary-without-manpage
build-depends-indep-without-arch-indep
changelog-should-mention-nmu
debian-files-list-in-source
debian-rules-missing-required-target
extended-description-is-empty
native-package-with-dash-version
no-copyright-file
no-md5sums-control-file
python-script-but-no-python-dep
source-nmu-has-incorrect-version-number
Of those, some apply only to the source package, some only to binaries,
some only to the Emdebian TDebs that are a completely different issue
(eventually, those will need something like the current lintian support
for udebs).
e.g.
elsif (($info =~ /GNU message catalog/) and ($tdeb 0))
{
Tags::add_override (extended-description-is-empty);
Tags::add_override (no-md5sums-control-file);
Tags::add_override (no-copyright-file);
# need TDeb checks here.
Tags::add_override (debian-rules-missing-required-target *);
# might want to fix this one.
Tags::add_override (debian-files-list-in-source);
Tags::add_override (native-package-with-dash-version);
This code works for me (without the extra flexibility):
Adding to the existing code at:
unless ($no_override) {
if (open(O, '', $base/override)) {
while (O) {
chomp;
next if m,^\s*(\#|\z),o;
s/^\s+//o;
s/\s+$//o;
s/\s+/ /go;
my $override = $_;
$override =~ s/^\Q$pkg\E( \Q$long_type\E
Re: lintian for Emdebian
On Tue, 2008-04-01 at 14:09 -0700, Russ Allbery wrote:
Neil Williams [EMAIL PROTECTED] writes:
My recommendation is to try to tackle this on two fronts:
* For the new checks specific to emdebian, add new check files. You can
do this in a completely separate package and just depend on lintian.
OK, that's working, thanks Russ.
Current test code:
http://buildd.emdebian.org/svn/browser/current/host/trunk/emdebian-tools/trunk/checks
Lintian when run will pick up any files in /usr/share/lintian/checks, so
you can just drop more checks and *.desc files in there. You can have
those checks do nothing if they detect they're not running in the
emdebian mode somehow.
* For the Lintian checks that are wrong for emdebian, I would just add a
global override file for emdebian.
Hmmm, can't find any docs on a global lintian override file - where
would that live and how would it cope with unknown/unbuilt packages?
So far, I'm working with:
Tags::add_override (source-nmu-has-incorrect-version-number);
Tags::add_override (changelog-should-mention-nmu);
Tags::add_override (binary-or-shlib-defines-rpath);
tag binary-or-shlib-omits-rpath, $file $RPATH{$file};
and others
Those all work fine.
However, I'm finding it impossible to override the manpage warnings
without removing all the manpages checks with -X :
Tags::add_override (binary-without-manpage);
Tags::add_override (binary-without-manpage apt-cache);
Tags::add_override (apt, binary-without-manpage apt-cache);
Tags::add_override (binary-without-manpage usr/bin/apt-cache);
Tags::add_override (apt, binary-without-manpage usr/bin/apt-cache);
Tags::add_override (apt, binary-without-manpage ./usr/bin/apt-cache);
Tags::add_override (binary-without-manpage apt-cache);
Still, I get:
W: apt: binary-without-manpage usr/bin/apt-cache
W: apt: binary-without-manpage usr/bin/apt-cdrom
W: apt: binary-without-manpage usr/bin/apt-config
W: apt: binary-without-manpage usr/bin/apt-get
W: apt: binary-without-manpage usr/bin/apt-key
W: apt: binary-without-manpage usr/bin/apt-mark
I: apt: unused-override binary-without-manpage
I: apt: unused-override binary-without-manpage apt-cache
I: apt: unused-override binary-without-manpage usr/bin/apt-cache
I don't actually need the manpages checks but I would like to not have
to alias lintian to lintian -X manpages.
Is there a way of implementing '-X' within the check scripts? (It would
save time if I could drop entire scripts like manpages and replace with
a simple check that /usr/share/man/ is empty). (Have I got the overrides
wrong? I've tried various formats.)
W: apt: binary-without-manpage usr/bin/apt-cache
I: apt: unused-override binary-without-manpage
I: apt: unused-override binary-without-manpage apt-cache
I: apt: unused-override binary-without-manpage usr/bin/apt-cache
Tags::add_override (binary-without-manpage);
Tags::add_override (binary-without-manpage *);
Tags::add_override (binary-without-manpage apt-cache);
Tags::add_override (binary-without-manpage usr/bin/apt-cache);
You can get an example .deb from the Emdebian repository:
http://www.emdebian.org/packages/pool/main/a/apt/
$ lintian -q -C emdebian apt_0.7.9em2_arm.deb
E: apt: unsupported-interpreter-in-binary usr/bin/apt-mark
E: apt: unsupported-interpreter-in-binary usr/lib/dpkg/methods/apt/setup
(These are errors in the current Emdebian package which I need to fix -
a failure with 'lintian -q -C emdebian' will cause a FTBFS in Emdebian
once this support is implemented in emdebian-tools 1.0.0 - that call
could easily be 'lintian -q -X manpages -C emdebian' but I'd like to
know if I've done something wrong in my manpage overrides.)
$ lintian -I apt_0.7.9em2_arm.deb
W: apt: binary-without-manpage usr/bin/apt-cache
W: apt: binary-without-manpage usr/bin/apt-cdrom
W: apt: binary-without-manpage usr/bin/apt-config
W: apt: binary-without-manpage usr/bin/apt-get
W: apt: binary-without-manpage usr/bin/apt-key
W: apt: binary-without-manpage usr/bin/apt-mark
E: apt: unsupported-interpreter-in-binary usr/bin/apt-mark
E: apt: unsupported-interpreter-in-binary usr/lib/dpkg/methods/apt/setup
W: apt: package-name-doesnt-match-sonames libapt-pkg-libc6.6-6-4.6
I: apt: unused-override binary-or-shlib-defines-rpath
I: apt: unused-override binary-without-manpage
I: apt: unused-override build-depends-indep-without-arch-indep
N: 2 tags overridden (2 errors)
If you need additional Lintian
support for override files that are more overridey than normal
(suppressing tags even with --show-overrides, for example) or are
selectively loaded, we can try to work out generic changes to the driver
scripts for this.
Thanks, I'll work through the current package set and build up a list of
lintian messages and overrides.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
lintian for Emdebian
I've been looking over the lintian source code with a view to implementing some form of lintian support for crossbuilt packages in Emdebian. Common differences between Emdebian packages and standard Debian policy include: 1. Removal of documentation, even those files mandated by Debian policy like manpages, leading to empty virtual packages and empty (or entirely missing) -doc packages. /usr/share/doc should be almost empty. 2. Architecture-checks on all files in ./*/?bin and ./*/lib to ensure that the build has completed successfully without the native compiler being called accidentally (quite common) or due to a patch failure. 3. Removal of all /usr/share/locale/ content unless the package is an Emdebian TDeb. 4. Complete ban on the use of perl in maintainer scripts, including the use of any command that is implemented in perl like update-alternatives, until such time as Emdebian has a C replacement. 5. Complete ban on trying to process any file in a maintainer script that has been removed for Emdebian (like install-info). 6. Checks on Emdebian TDebs to ensure the presence of the POT file in the source, the presence of only .mo files in the package and a ban on empty TDeb packages. 7. No Essential tags in debian/control, ever. 8. No unsupported interpreters (python etc.) and no expectation of running /bin/bash - all /bin/sh only (actually must be able to use busybox dash but I'll deal with that on a package-specific basis via the BTS.) 9. Mandatory use of RPATH - any package that has removed RPATH for Debian will find it exists again after a cross build and this is essential. A lack of an RPATH may indicate a crossbuild failure. 10. No attempts to use network access during package configuration - this one is harder but it is important because a lot of embedded devices will have no possible network connection during installation - serial yes, network, no. (Installation media == USB keys or SD cards.) Those are just the top 10. :-) There are probably another 25 that I can think of. Now I'm quite familiar with Perl (all the emdebian build tools are in Perl), I could come up with compatible Perl modules along the lines of Lintian::binaries::Emdebian or Lintian::Cross but I want to be able to fold these checks into the standard lintian checks so that I don't just create a fork that will lag behind lintian and eventually be too incompatible to maintain. (We did that with dpkg-dev and dpkg-cross and it took nearly 10 years to get our changes back into dpkg-dev.) So I'm looking for ideas. I want to be able to selectively disable checks *within* lintian packages - e.g. the RPATH issue - whilst retaining the other checks in that package, modifying the importance of some and adding new ones. Simply disabling the entire set of checks is not worthwhile - I'd have to maintain 90% of the original check file as a fork. I want to be able to do this largely independently of lintian itself so that I don't have to bug you for changes in lintian every time Emdebian makes a new Policy decision. (Emdebian Policy is extremely fluid at this time but will be mostly compatible with Debian Policy within the constraints of an embedded device.) Within the above 10 items, some are even more subtle because if, for example, someone uses Emdebian patches and Emdebian build tools to prepare an i386 package on i386 (e.g. for Eeee PC etc.) then the RPATH issue may disappear and the check would need to revert to Debian behaviour. Necessarily, the actual code running these tests should remain in the Emdebian build tools packages (emdebian-tools) so that these can be maintained without expecting lintian maintainers to test with cross builds. A basic subset of these checks is already implemented in the emdebian-tools build script but wider and more subtle support is necessary, along with proper support for the rest of the lintian checks. It may also be a good idea if Emdebian can modify the importance of various existing lintian checks so that we can downplay errors and warnings that really only matter within the wider Debian context. I don't want to spend too much time discussing the actual checks, I described the 10 above to give some flavour of the extent of the changes and the required granularity of the changes. I'm willing to do the work, all I need from you is some direction and possible means of creating a suitable interface or wrapper. I'm quite happy writing 'emlintian' if I know how it could remain a wrapper without becoming a fork. How could this be achieved? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#452316: Packages with empty directories
Daniel Schepler wrote: On Tuesday 20 November 2007 11:20:17 pm Michael Biebl wrote: Imho adding a lintian check for empty /usr/bin, /usr/sbin, /usr/lib and /usr/include directories (as created by dh-make) would be a good start. I wrote a lintian check implementing the conservative approach, and submitted a patch as bug #452316. It lists empty directories matching directories from base-files, as well as any empty subdirectories of /usr/include, /usr/share/man, and some others where they clearly make no sense. The only problem with the patch is that /usr/lib/perl5/ is often included just by creating a perl package. I've tried to get rid of it but it *is* created during 'make install' by use ExtUtils::MakeMaker; but it is not necessarily used by package files. Another problem is that the creation of the directory often doesn't show up in the build log - I can force it by running make install without sudo or a prefix: Warning: You do not have permissions to install into /usr/local/lib/perl/5.8.8 at /usr/share/perl/5.8/ExtUtils/Install.pm line 114. mkdir /usr/local/share/perl/5.8.8/XML: Permission denied at /usr/share/perl/5.8/ExtUtils/Install.pm line 176 It seems that ExtUtils::MakeMaker insists on using both /usr/lib/perl5 and /usr/share/perl5 whether the module itself uses them or not. Maybe someone from the Debian Perl group can show me where I'm going wrong or maybe CDBS can check for empty directories but everytime I remove debian/tmp/usr/lib/perl5, it gets recreated, despite not having any mention of it in the package files. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Bug#407528: typo
Maybe this very old bug should be closed as unfeasible? s/very old// Hmm, it must be getting late - I've been browsing some old lintian bugs and thought this one was a lot older than it really is. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpxI1JGBc37K.pgp Description: PGP signature
Bug#406731: reopen: bug still exists in source: check
Package: lintian Version: 1.23.28 --- Please enter the report below this line. --- For some reason, this bug has not actually gone - the source check is still complaining: lintian -o /path/build-area/emdebian-tools_0.1.5_amd64.changes W: emdebian-tools source: uploader-not-full-name Wookey Once debian/source.lintian-overrides is removed svn-buildpackage with --svn-lintian gives: Binary package: /path/trunk/emdebian-tools/build-area/emdebian-tools_0.2.0_all.deb lintian /path/build-area/emdebian-tools_0.2.0_powerpc.changes W: emdebian-tools source: uploader-not-full-name Wookey --- System information. --- Architecture: powerpc Kernel: Linux 2.6.18-4-powerpc Debian Release: lenny/sid 500 unstablewww.linux.codehelp.co.uk 500 unstablewww.emdebian.org 500 unstablemirror.ox.ac.uk 500 unstableftp.uk.debian.org 1 experimentalftp.uk.debian.org --- Package information. --- Depends (Version) | Installed ===-+-== perl| 5.8.8-7 libdigest-md5-perl | OR perl ( 5.8) | 5.8.8-7 dpkg-dev (= 1.13.17) | 1.13.25 file| 4.20-4 binutils| 2.17-3 diffstat(= 1.27-1) | 1.43-2 man-db(= 2.3.20-1) | 2.4.4-2 gettext (= 0.16) | 0.16.1-1 intltool-debian | 0.35.0+20060710.1 libparse-debianchangelog-perl (= 0.6) | 1.0-1 -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp5WkVV5SXii.pgp Description: PGP signature
Bug#406731: lintian: please consider removing maintainer-not-full-name check
Package: lintian Version: 1.23.27 Severity: wishlist The only packages that generate this warning are packages by a DD who has changed his name by deed poll to just one word: wookey. It seems unfair to have a warning that only he has to override. :-) I came across this when checking my own package that Wookey will co-maintain: emdebian-tools, currently at ITP stage. I'd rather not have to use a lintian override in perpetuity. http://lintian.debian.org/reports/Tmaintainer-not-full-name.html http://www.chaos.org.uk/~wookey/name.html -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages lintian depends on: ii binutils 2.17-3The GNU assembler, linker and bina ii diffstat 1.43-2produces graph of changes introduc ii dpkg-dev 1.13.25 package building tools for Debian ii file 4.17-5Determines file type using magic ii gettext0.16.1-1 GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libparse-debianchangel 1.0-1 parse Debian changelogs and output ii man-db 2.4.3-5 The on-line manual pager ii perl [libdigest-md5-pe 5.8.8-7 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387166: lintian: Failed to identify Priorities error: Policy 2.5.
Package: lintian Version: 1.23.24 Severity: important A recent upload of QOF included two new packages. The main library is dependent on at least one of these new packages being installed and is Priority: optional. However, I inadvertently put the two new packages as Priority: extra and lintian did NOT complain. When the upload was made, the two new binaries raised a Debcheck error: Binary Package: libqof1 (Version: 0.7.1-1) Priority According to Policy Section 2.5: Priorities packages MUST NOT depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages must be adjusted. Package is optional and has a Depends on libqof-backend-qsf0 (within libqof-backend-qsf0 | libqof-backend-sqlite0) which is extra on mips. etc. I have since built and my sponsor has uploaded 0.7.1-2 which corrects the settings in the debian/control file for qof before the Debcheck becomes an RC bug. Despite the Debcheck page being created, the online lintian page indicates no lintian errors in 0.7.1-1. Lintian should make sure that errors like this are caught in future because 2.5 is a 'must' in Policy. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages lintian depends on: ii binutils 2.17-2 The GNU assembler, linker and bina ii diffstat 1.43-1 produces graph of changes introduc ii dpkg-dev 1.13.22 package building tools for Debian ii file 4.17-3 Determines file type using magic ii gettext 0.15-2 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710 Help i18n of RFC822 compliant conf ii libparse-debianchangelog 1.0-1 parse Debian changelogs and output ii man-db 2.4.3-3 The on-line manual pager ii perl [libdigest-md5-perl 5.8.8-6.1 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
