Bug#905881: lintian: detect packages containing X11 fonts that do not run update-fonts-* or do not dep on xfonts-utils
Package: lintian
Version: 2.5.96
Severity: wishlist
As a result of a thread[1] on debian-fonts, I found that lmodern and
tex-gyre contain X11 fonts but do not run update-fonts-* from their
postinst and do not depend on xfonts-utils via ${misc:Depends}, both
of these are automatically added by dh_installxfonts if run correctly.
I filed bugs[2] about these issues but it would be nice to have lintian
detect binary packages containing X11 fonts[3] that do not depend on
xfonts-utils or do not have the dh_installxfonts snippet[4] that
debhelper installs into the maintainer scripts.
1.
https://lists.debian.org/msgid-search/CAJqvfD-A1EPXxF_mS=_baq0ftqygvwruf+23wqsqrksmygv...@mail.gmail.com
2. https://bugs.debian.org/905879
https://bugs.debian.org/905880
3. /usr/share/fonts/X11/**/*.pcf.gz
/usr/share/fonts/X11/**/*.pcf
/usr/share/fonts/X11/**/*.pfa
/usr/share/fonts/X11/**/*.pfb
/usr/share/fonts/X11/**/*.afm
4. For example:
# Automatically added by dh_installxfonts/11.3.5
if [ -x "`which update-fonts-dir 2>/dev/null`" ]; then
update-fonts-scale Type1;update-fonts-dir --x11r7-layout Type1
fi
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU.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.31.1-2
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii dpkg 1.19.0.5+b1
ii file 1:5.33-3
ii gettext0.19.8.1-6+b1
ii intltool-debian0.35.0+20060710.4
ii libapt-pkg-perl0.1.34
ii libarchive-zip-perl1.60-1
ii libclass-accessor-perl 0.51-1
ii libclone-perl 0.39-1
ii libdpkg-perl 1.19.0.5
ii libemail-valid-perl1.202-1
ii libfile-basedir-perl 0.08-1
ii libipc-run-perl20180523.0-1
ii liblist-moreutils-perl 0.416-1+b3
ii libparse-debianchangelog-perl 1.2.0-12
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii liburi-perl1.74-1
ii libxml-simple-perl 2.25-1
ii libyaml-libyaml-perl 0.72+repack-1
ii man-db 2.8.4-2
ii patchutils 0.3.4-2
ii perl [libdigest-sha-perl] 5.26.2-6
ii t1utils1.41-2
ii xz-utils 5.2.2-1.3
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b4
Versions of packages lintian suggests:
ii binutils-multiarch 2.31.1-2
ii dpkg-dev 1.19.0.5
ii libhtml-parser-perl3.72-3+b2
ii libtext-template-perl 1.53-1
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Re: Lintian test suite proposal
Hi Niels, Thank you for your thoughtful comments. Your input weighs heavily in Debian QA. I will address your points one by one, but will mostly disregard your comments regarding style. Some of it may be my lack of experience. Perhaps it is my walk of life. I probably dislike the passive language that is so common in technical documents. Either way, I am not tied to any wording. Let's begin: > As I read it, there are two orthogonal but interesting ideas. > > 1. The tags.d layout > > 2. The Abbreviated-Tags proposal pigging backed on top of tags.d. The two ideas are not as unrelated as they seem. Both (1) and (2) dissociate the tag names from the test context. Keeping that information together as we currently do is not only redundant but also makes it hard to refactor and reorganize our tests. Given your positive reaction to 'Abbreviated-Tags' I won't dwell on its advantages, but it is the less powerful idea of the two. Sure, it's nice you don't have to mention the test name in 'tags' any more, but you still have to deal with nuisance tags from unrelated checks. Many times, they are a pointless obstacle: Who cares about a watch file, for example, when you are testing lintian's reaction to changelog entries? I think ultimately the option 'Abbreviated-Tags' only makes it easier to rename tests. It does not help with unit testing the lintian checks, which is the core proposal. The tags directory proposal suppresses tag noise from other checks. I also makes it easy to reuse tag files in various test contexts as long as you are testing the same basic features. Another great advantage, and a major motivation, is the easier reordering of git commits containing newly proposed Lintian tags. If any test validates more than one check you are working on, you can spend a lot of time with 'git rebase -i' and 'git add -i' trying to swap the commit order. With tags.d it is almost guaranteed to be conflict-free. You may want to add a third point. My proposal also abolishes the tag order. As a side note, I actually expected greater opposition to the bundling of all tags in one check as a testable entity, as opposed to viewing single tags as the proper entity under test. The idea for tags.d arose when I read the following portions of the README (emphasis marked with >>> and <<<): / Please keep each test case focused. One of the problems that / developed with the old test suite is that each test was serving many / separate purposes and testing large swaths of Lintian, which made it / difficult to know what could be changed and what would destroy some / other useful test. >>> Test cases should only test a set of closely / related tags and new tests should be added for new issues that aren't / part of that closely-related set. <<< / Test cases should be as Lintian-clean as possible except for the tags / that they're testing for. The template is intended to help with this. / It generates a Lintian-clean basic package for you to start with. You / should override only the minimal required to trigger your test, and / try to fix any unrelated problems. >>> Sometimes this won't be possible / and the only way to trigger a tag is to also trigger another tag, and / that's fine, but it shouldn't be the normal case. <<< > As I read it, these proposals should be feasible implement separately > (i.e. Abbreviated-Tags could be retrofitted into the existing framework > without adding tags.d). This is mostly relevant if one of the proposals > turn out to be controversial and the other is not - in that case, we can > move forward with the uncontroversial one. Good point. I originally implemented them separately but found the combination more powerful. Please note that either way the use of directory tags is optional. People can still use the regular 'tags' file. > Personally, I feel I understand Abbreviated-Tags good enough that I can > say I would support it and I would recommend it was made the default for > new tests (modulo a few minor remarks). > On the tags.d layout, I can mostly see where you would like to go but > it is not clear to me when the test runner will accept vs. fail a test. The test runner fails if a check being tested did not issue all tags specified, or if the check issued tags that weren't specified. That behavior is similar to what happens now, except everything happens on a per-check basis. > > New tags.d layout > > - > > General remarks about the text (assuming it is for t/tests/README): > > * I think we should avoid the "New" / "Old" in this document if it is >an addition to t/tests/README. The problem with using "new" for >everything is that in a year it will no longer be new and at some >point it could even be superseded by a different format/layout as we >improve ourselves. Let's cooperate on wording if you are available to give advice, please. > * The text sometimes stops being a README document and starts being >sales-pitch and then jumps back to bei
Processed: your mail
Processing commands for cont...@bugs.debian.org: > retitle 905843 incorrect recognizes "allow-stderr" as a non-standard > autopkgtest restriction Bug #905843 [lintian] lintian recognized "allow-stderr" as a non-standard autopkgtest restriction Changed Bug title to 'incorrect recognizes "allow-stderr" as a non-standard autopkgtest restriction' from 'lintian recognized "allow-stderr" as a non-standard autopkgtest restriction'. > thanks Stopping processing here. Please contact me if you need assistance. -- 905843: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905843 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#905843: lintian recognized "allow-stderr" as a non-standard autopkgtest restriction
tags 905843 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/91b7ec96722a3a456aa9d3a7ec6c8d23f3dd9535 data/testsuite/known-restrictions | 1 + debian/changelog | 4 2 files changed, 5 insertions(+) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Processed: Re: lintian recognized "allow-stderr" as a non-standard autopkgtest restriction
Processing commands for cont...@bugs.debian.org: > tags 905843 + pending Bug #905843 [lintian] lintian recognized "allow-stderr" as a non-standard autopkgtest restriction Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 905843: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905843 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#905843: lintian recognized "allow-stderr" as a non-standard autopkgtest restriction
Package: lintian Version: 2.5.96 Severity: normal "allow-stderr" is a standard value according to the given document. P: julia source: unknown-runtime-tests-restriction allow-stderr paragraph starting at line 2 N: N:A paragraph in debian/tests/control mentions a non-standard value for N:the Restrictions field. Though allowed, this may indicate an error, as N:the whole paragraph will be ignored. N: N:Refer to N: https://salsa.debian.org/ci-team/autopkgtest/tree/master/doc/README.package-tests.rst N:for details. N: N:Severity: pedantic, Certainty: wild-guess N: N:Check: testsuite, Type: source
Lintian test suite proposal
Hi Felix, Context for lint-maint: Felix Lechner sent me a proposed change for the test suite and asked me for write an email with the feedback. I thought it was useful to include lint-maint because it affects all contributors of lintian (if implemented). The proposal is quoted below interleaved with my comments and is to be an update/edit to t/tests/README. Thanks for working on improving Lintian. I should once again repeat that my work on lintian has dwindled and I may not be the right contributor any longer to decide which way we are going with the test suite (IOW, take my review with a grain of salt). As I read it, there are two orthogonal but interesting ideas. 1. The tags.d layout 2. The Abbreviated-Tags proposal pigging backed on top of tags.d. As I read it, these proposals should be feasible implement separately (i.e. Abbreviated-Tags could be retrofitted into the existing framework without adding tags.d). This is mostly relevant if one of the proposals turn out to be controversial and the other is not - in that case, we can move forward with the uncontroversial one. Personally, I feel I understand Abbreviated-Tags good enough that I can say I would support it and I would recommend it was made the default for new tests (modulo a few minor remarks). On the tags.d layout, I can mostly see where you would like to go but it is not clear to me when the test runner will accept vs. fail a test. > New tags.d layout > - General remarks about the text (assuming it is for t/tests/README): * I think we should avoid the "New" / "Old" in this document if it is an addition to t/tests/README. The problem with using "new" for everything is that in a year it will no longer be new and at some point it could even be superseded by a different format/layout as we improve ourselves. * The text sometimes stops being a README document and starts being sales-pitch and then jumps back to being a README a bit later only to become a TODO list in the end. I have highlighted a few of these but I stopped when I realised it was a general problem. - Note there is nothing wrong with the sales-pitch/rationale for the proposals. The "issue" is that I was told to read this as a t/tests/README change and some of the text need tweaking to fit there. > > In addition to the established format described in the remainder of > this document, our test suite now supports a new directory-based > format for expected tags. > > The new format no longer compares the entire lintian output. Instead, > it uses separate files for each lintian check. The files are located > in a directory called tags.d. >> Each file is named after a lintian check. It contains all tags issued > by a particular check. The tags can be in any order. Tags from checks > are ignored and will no longer interfere. The last sentence is a bit unclear to me. I suspect you mean that tags are ignored if they do not belong to one of the checks in tags.d? Assuming there is tags.d/X file and it contains the tag "Y". Will the test fail if the check X emits the tag "Z" in addition to "Y"? > This decoupling has several > advantages. For example, one can now enable '--pedantic' without > having to deal with any noise from other checks. Instead, one can > conveniently test just the tags expected from a particular check. > > The tags.d directory also contains a file named 'options' which gives > the user a way to restore the old behavior. How come you are going for a new "options" file for these options instead of adding them to the per-test desc file? > When set, 'Exhaustive-Set: > yes" will cause any extra tags in the output to fail the test. Since > checks generally have little correlation, this option will not be > useful in many cases. For most tests, the default setting of > 'Exhaustive-Set: no' will be a great relief. I could do with some examples of when the test succeeds and fails given a given tags.d folder/content, different Exhaustive-Set values and different lintian output. > The lintian option > '--pedantic' might even become the default setting for the test suite > going forward. > The last sentence (about making --pedantic default in tests) makes sense in the proposal as it is part of the reason why this proposal might be useful. However, I do not think it would belong in t/tests/README. > For more flexibility, there is another option 'Abbreviated-Tags: yes'. > It allows expected tags to be listed in a shorter and possibly > more convenient format. First, the letter code at the beginning of > each line is dropped and reconstructed automatically. Tags are only > ever issued with one of these letters, so the chance of an internal > error is small. Instead of worrying about a tag's severity and > certainty, you can focus on which tags are being issued and why. > Note that AFAICT, the Abbreviated-Tags could be added to the existing framework without the new layout (after resolving
