Re: [Dehs-devel] Re: watch file check in lintian
On Wed, Feb 08, 2006 at 11:16:38PM +0100, Bluefuture wrote: I'm asking to jdg and other devscript developers if is it possible to support some official excuses in the watch file (and uscan) for example: version=3 debian-native or for any other offcially precoded excuses. Ugh. You mean that for every native package I produce, I have to write a watch file to say there's no watchfile here. That sounds unpleasant. Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#552526: lintian: add Typesetting section for doc-base section check
Package: lintian Version: 2.2.17 Please see bug#486144: doc-base now has a Typesetting section; please could you add this to the lintian doc-base checks? Thanks! Julian -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712511: lintian: should check for references to update-notifier in postinst
Package: lintian Version: 2.5.13 I just noticed that packages such as dbus still have a reference to update-notifier that warn that a reboot is required. But sid no longer has that functionality - update-notifier is just a transitional package. So maintainers should be warned if their postinst is still assuming this to warn administrators that a reboot is required. I have no idea what the sid equivalent is, though. Julian -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616154003.ga30...@d-and-j.net
Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js
On Tue, Sep 05, 2017 at 02:03:31PM -0700, Russ Allbery wrote: > I can believe the same thing about this JavaScript, though. It's not > really that long, an editor is going to hard-wrap the line, and I bet most > changes are just adding an additional condition. > > I'd be inclined to just whitelist this particular file as an oddity. Though perhaps whitelist just the long line of code; the anki upstream had compressed the header lines to an intial comment at the start of the line of code, so the one-line file read: /* CSS Browser Selector v0.4.0 (Nov 02, 2010) Rafael Lima (http://rafael.adm.br) */function... I've now replaced that with the original upstream version. Best wishes, Julian
Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js
Package: lintian Version: 2.5.52 Severity: normal Hi there, lintian gives a false-positive source-is-missing for css_browser_selector.js (though in my case the file has been renamed). The upstream source is https://github.com/rafaelp/css_browser_selector/ and the original source is just one really long line (plus some informational header comments). And it's been manually written as one long line, it seems, as there are spaces after semicolons... Best wishes, Julian
Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js
On Tue, Sep 05, 2017 at 10:33:58PM +0100, Chris Lamb wrote: > tags 874381 + pending > thanks > > Fixed in Git: > > > https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=72d95b8ee796cafcdc05d4c612d1b435b9c37302 I wonder whether the patch should check for css_browser_selector (the function name) rather than 'css browser selector' (the title)? Best wishes, Julian
Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js
On Wed, Sep 06, 2017 at 10:12:05PM +0100, Chris Lamb wrote: > Hi Julian, > > > I wonder whether the patch should check for css_browser_selector (the > > function name) rather than 'css browser selector' (the title)? > > Great idea. I didn't actually spot this in the $block variable. Updated > in: > > > https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=8a3ec2888011b93e5f55c31bcf366bff5a8f Pleasure! Julian
Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js
On Tue, Sep 05, 2017 at 05:28:47PM +0100, Chris Lamb wrote: > Hey Juliam. > > > false-positive source-is-missing bug for css_browser_selector.js > > Is it? I don't want to start haggling over the interpretation of > "preferred form for modification", but surely this is the "source": > > > https://github.com/rafaelp/css_browser_selector/blob/master/css_browser_selector_dev.js No, that's a completely different piece of code. Julian
Bug#906284: CC0 is short
On Sat, Aug 25, 2018 at 10:32:55AM +0200, Julien Puydt wrote:
> Hi,
>
> the following also triggers the check, and I think it's a false positive,
> and would still be even with the proposed change:
>
> License: CC0
Indeed - good catch. We have to treat CC0 differently, as it's got
different license wording and it also appears in
/usr/share/common-licenses. How about the following then:
if ($full_license and $short_license =~ m/cc-/) {
if ($full_license !~ /definitions/i and
$full_license !~ /copyright and related rights/i and
$full_license !~ m%/usr/share/common-licenses/CC) {
tag 'incomplete-creative-commons-license';
}
}
Best wishes,
Julian
Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license
On Thu, Aug 16, 2018 at 04:32:08PM +0100, Chris Lamb wrote:
> Hi Julian,
>
> > The test for the human-readable rather than legal text of the Creative
> > Commons licenses seems to fail, because the preamble about Creative
> > Commons not being a law firm is not part of the license text, and
> > neither is the postamble about Creative Commons not being a party to
> > the license agreement; they are instead form the terms and conditions
> > between Creative Commons and the person using a CC license. So I
> > cannot see why these parts should necessarily be included in the
> > Debian copyright file. Has there been a policy decision to require
> > this, perhaps?
> >
> > Also, it seems that this check would be better in the parse_license
> > function when checking each license block rather than the run
> > function, as there might be more than one CC license in a copyright
> > file, and it is feasible that one is correct and one not.
>
> CC'ing Jonathan Dowland who filed the original request for this
> in #903470. Could you folks come to some agreement on a good/reliable
> check?
Hi Chris and Jonathan,
How about the following? In the parse_license function, where each
license paragraph is parsed, something like the following:
if ($full_license and $short_license =~ m/cc-/) {
if ($full_license !~ /definitions/i) {
tag 'incomplete-creative-commons-license';
}
}
All of the full legal texts contain "Section 1. Definitions", whereas
the human-readable summaries don't.
This also means that you are not searching the entire copyright file,
but rather just the paragraph with the full Creative Commons text.
Best wishes,
Julian
Bug#906284: CC0 is short
On Mon, Aug 27, 2018 at 02:36:34PM +0100, Chris Lamb wrote:
> Julian et al.,
>
> > if ($full_license and $short_license =~ m/cc-/) {
> > if ($full_license !~ /definitions/i and
> > $full_license !~ /copyright and related rights/i and
> > $full_license !~ m%/usr/share/common-licenses/CC) {
> > tag 'incomplete-creative-commons-license';
> > }
> > }
>
> Apply to apply this, but before I do can you supply some "known good"
> and "known bad" texts? That way I can supplement our testsuite..
I hope I have found the right place to apply it - I haven't read the
lintian code that carefully, and it may be that there's a better
approach.
Anyway, remind me next week if no-one else has done it and I'll write
some; it's a little difficult for me to do it this week.
Best wishes,
Julian
Bug#1001575: lintian: duplicate-globbing-patterns notice says "(lines $lines)"
Package: lintian Version: 2.114.0 Severity: normal I was testing a new version of spyder and received the following error message from lintian: E: spyder source: duplicate-globbing-patterns spyder/plugins/editor/utils/kill_ring.py (lines $lines) [debian/copyright] Presumably the $lines variable should have been expanded? Best wishes, Julian
Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts
Package: lintian Version: 2.114.0 Severity: wishlist I discovered that in several of my autopkgtest scripts, and in various other packages in the archive, the following pattern appears: ... cd somewhere ... for py in $(py3versions -r 2>/dev/null) ... Unfortunately, this silently fails, as no python versions are returned when py3versions -r is run from anywhere other than the top directory of an unpacked source, and only the error message: py3versions: error parsing Python3-Version attribute is given. The "2>/dev/null" is nevertheless usually required even when run from the correct directory to silence the warning: py3versions: no X-Python3-Version in control file, using supported versions which appears on most packages. The corrected script should read something like: ... for py in $(py3versions -r 2>/dev/null); do cd somewhere ... or ... python3_versions=$(py3versions -r 2>/dev/null) cd somewhere ... for py in $python3_versions; do ... A regex such as /\bcd\b.*py3versions\s+-r/s applied to the entire content of debian/tests/control and every other file in debian/tests should catch this issue. Best wishes, Julian
Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts
Hi Mattia, On Tue, Dec 14, 2021 at 03:39:54PM +0100, Mattia Rizzolo wrote: > Hi Julian, > > On Tue, Dec 14, 2021 at 06:49:12AM +0000, Julian Gilbey wrote: > > I discovered that in several of my autopkgtest scripts, and in various > > other packages in the archive, the following pattern appears: > > I think (although I'm not an authoritative voice of any kind here) that > you you are using the wrong option altogether actually. That may or may not be true. What I am observing, though, is that there are a number of packages that have this bug. Not many, but a moderate number nonetheless. > > cd somewhere > > ... > > for py in $(py3versions -r 2>/dev/null) > > ... > > > > Unfortunately, this silently fails, > > Of course it's silent. you are asking something and then ignoring the > output… Well, yes and no. In a package that doesn't have X-Python3-Version set, py3versions -r prints a warning message to stderr, and we want to suppress this so that autopkgtest doesn't fail for no reason (adding Restrictions: allow-stderr for a single expected warning is not a good thing to do). However, this doesn't separate from the case where py3versions -r prints an error message and exits with an error status. > > is given. The "2>/dev/null" is nevertheless usually required even > > when run from the correct directory to silence the warning: > > > > py3versions: no X-Python3-Version in control file, using supported versions > > that's because you are using the wrong option. You may well be correct. That doesn't change the reality that this is what is happening in a number of packages. > You should use `-s` instead of `-r` in those cases, and drop the > 2>/dev/null. I'm not convinced; if a X-Python3-Version is added later to a package using -s, then things might go wrong, whereas -r will always do the right thing as it falls back to -s. Or if copying boilerplate testing code, -r always works but -s doesn't. A better possibility might be for py3versions to introduce an additional option -q/--quiet to suppress the warning message when -r falls back to -s; this is vastly superior to 2>/dev/null as it will let the true failure remain visible (and possibly cause autopkgtest to correctly fail). > Besides, even if you keep the -r it wouldn't be much of a problem: $() > only captures stdout, stderr just gets printed and doesn't interfere > with the for loop or such, so why are you doing this? Because any output to stderr causes autopkgtest to fail unless it is specifically instructed to allow-stderr. > -r is used by dh_python and other build scripts because they have to > support all packages, but IMHO you really should be using -s if you know > you don't have X-Python3-Version in your package and you *really* want > to just suppose whatever are the current supported python3 versions. You may indeed be right. > > The corrected script should read something like: > > > > ... > > for py in $(py3versions -r 2>/dev/null); do > > cd somewhere > > ... > > > And then, `py3versions -s` will "just work" wherever you are, no need to > do this fairly complicated check. True. > > A regex such as /\bcd\b.*py3versions\s+-r/s applied to the entire > > content of debian/tests/control and every other file in debian/tests > > should catch this issue. > > Yeah sure, and then what about pushd ? Doing this kind of check in > lintian is fraught with false positives, so I recommend the lintian > maintainers don't try to do this. I don't think I've yet found a case where pushd has been incorrectly used (and I've so far checked all source packages beginning with a-f and all source packages with "python" in their name). > However, instead, I'd suggest that, after checking with the > debian-python@ lists, we could tell people to use -s if and only if > X-Python3-Version is not defined (conversely, we should warn if packages > use -s if X-Python3-Version *is* defined, probably). That sounds very sensible. If people hear the advice. And how does one check that the advice is being followed? Hence my suggestion to have a lintian check for this. But it may be a moot point: if it turns out that only a handful of packages have this issue (and I'm currently filing bug reports on them), then once they are fixed, maintainers who copy such scripts are unlikely to reintroduce the issue. Best wishes, Julian
Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts
On Tue, Dec 14, 2021 at 04:56:51PM +, Julian Gilbey wrote: > Hi Mattia, > > > that's because you are using the wrong option. > > You may well be correct. That doesn't change the reality that this is > what is happening in a number of packages. Hi Mattia, Here's an update. I've been through the archive, and the figures are approximately the following (only approximate, as some packages have multiple versions in unstable Sources, and I wasn't careful to only include one of each): 829 packages call py3versions in their debian/tests/* scripts 337 packages call py3versions -r 438 packages call py3versions -s 54 packages use other options: some use -i, some use -d, some use --supported (= -s), one uses -r So this is a *lot* of packages using -r, almost as many as the number using -s! After I fixed my broken packages, there are only a handful of packages incorrectly doing a cd before py3versions -r (3 or 4 such packages), so my suggested check is probably unwarranted. I've filed bug reports against those packages. Almost every package using py3versions -r redirects 2>/dev/null; the 5 or so which don't have "Restrictions: allow-stderr" in their tests/control file. I hope this is helpful. Best wishes, Julian
Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes
On Sat, Jan 15, 2022 at 05:15:52AM +, Scott Kitterman wrote: > This is certainly not a major issue, but your py3versions invocation in the > autopkgtest is sub-optimal. You are using -r for requested versions, but > then the package doesn't request specific versions so if falls back to all > supported versions: > > $ py3versions -r > py3versions: no X-Python3-Version in control file, using supported versions > python3.10 python3.9 > > If you just use supported versions directly it's a little better: > > $ py3versions -s > python3.10 python3.9 > > Please update this in your next upload. > > Scott K Dear Scott, Thanks for passing this through NEW! The question of py3versions -r versus py3versions -s is not so straightforward, IMHO. Using py3versions -r protects against the minor error of later introducing an X-Python3-Version field and forgetting to change -s to -r. With py3versions -r 2>/dev/null, the correct behaviour is always obtained, as -r falls back to -s when there is no X-Python3-Version field present. Perhaps better would be for py3versions to provide a -q flag to suppress the warning message in this case; this would also protect against the error of using py3versions incorrectly. Furthermore, this idiom appears throughout the archive. X-Python3-Version is quite rare: there are only about 194 occurrences of it across the current unstable main archive, of which only 6 are currently needed (those which specify X-Python3-Version: 3.9; all the rest specify >= 3.x, with x at most 9). On the other hand, there are over 800 packages that use py3versions in their debian/test/* scripts, but py3versions -r is very common among them, being used in a little under half of the cases. Only 4 packages have py3versions -r together with X-Python3-Version (namely formiko, pyferret, python-rpaths and sphinxcontrib-doxylink, though all of their X-Python3-Version fields are now unnecessary). There are also 4 packages which use py3versions -s together with X-Python3-Version, and these work only because the X-Python3-Version is now redundant (they are: mkosi, pyrlp, python-ecdsa, python-libzim). See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677 for a little more detail (copied into this reply). *If* the consensus is that py3versions -r is wrong, then we should probably have a lintian check for it: py3versions -r (and variants such as -rv and -vr) without a corresponding X-Python3-Version field should give a lintian warning, and py3versions -s with an X-Python3-Version field should do so likewise. Best wishes, Julian
Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes
On Sun, Jan 16, 2022 at 05:33:14AM -0800, Felix Lechner wrote:
> Hi,
>
> On Sun, Jan 16, 2022 at 2:27 AM Julian Gilbey wrote:
> >
> > *If* the consensus is that py3versions -r is wrong, then we should
> > probably have a lintian check for it: py3versions -r (and variants
> > such as -rv and -vr) without a corresponding X-Python3-Version field
> > should give a lintian warning, and py3versions -s with an
> > X-Python3-Version field should do so likewise.
>
> For reference, here is Lintian's current code examining the use of
> 'py3versions' in tests. [1]
>
> Kind regards
> Felix Lechner
>
> [1]
> https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Testsuite.pm#L289-309
Thanks Felix, that's really helpful!
So perhaps another clause or two, something along the lines of the
following, would be good? (This is not working code; I don't know all
the ins and outs of lintian's library to make it work. Also, these
should probably be warnings rather than hints.)
$x_python3_depend_field_present = [boolean specifying whether
X-Python3-Depend field is present in debian/control];
$self->pointed_hint(
'runtime-test-file-uses-requested-python-versions-without-x-python3-depend',
$pointer,
$command
)
if $options =~ /\s(?:-\w*r|--requested)/
&& !$x_python3_depend_field_present;
$self->pointed_hint(
'runtime-test-file-uses-supported-python-versions-with-x-python3-depend',
$pointer,
$command
)
if $options =~ /\s(?:-\w*s|--supported)/
&& $x_python3_depend_field_present;
There are obviously still a bunch of debian/test/* files which have
different options:
* some use -d (which does make sense, but may not be the best thing to
do in a debian/test/* file, as it will miss advanced warning of
breakages on newer versions of python)
* some use -i (which is picked up by the existing tests)
* lots use -r (see earlier discussion)
* lots use -s (which is generally fine), though some of these also use
2>/dev/null, which is not a good idea
And a couple don't follow the standard coding pattern:
* tap.py 3.1-1 has:
: ${PYVERSIONS:=py3versions}
for python in $($PYVERSIONS --supported); do
I'm unclear what is gained by thinking that the environment might
override PYVERSIONS.
* csound 6.16.2~dfsg-1 has:
# By default, test on all versions
versions="-r"
if [ "$2" = default ] ; then
versions="-d"
fi
for py in $(py3versions $versions 2>/dev/null) ; do
Finally, confget 4.1.0-1 tests for the presence of py3versions before
using it, which is just unnecessary (but thankfully doesn't mess up
the existing lintian test).
Best wishes,
Julian
Bug#1004746: lintian: provide a check for Python package version numbers validity
Package: lintian Version: 2.114.0 Severity: wishlist X-Debbugs-Cc: Debian Python Team I just hit two packages which gave me the following warning when pkg_resources tried to load them: /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an invalid version and will not be supported in a future release warnings.warn( (and a different version number in the other case). The upstream Python developers have a clear idea of what is accepted as a version number, and it appears in /usr/lib/python3/dist-packages/pkg_resources/_vendor/packaging/version.py (in the python3-pkg-resources package) in the definition of VERSION_PATTERN. The version number that is being examined is that stored in /usr/lib/python3/dist-packages/*.egg-info or /usr/lib/python3/dist-packages/*.egg-info/PKG-INFO on the line beginning "Version: ". This appears to be a fairly rare bug: only two packages on my system have this issue (and I've just reported bugs against them). Nonetheless, if it is easy, it would be nice to have a lintian test for it. Best wishes, Julian
Bug#1005043: lintian: check that Python version numbers are not 0.0.0
On Sat, Feb 05, 2022 at 04:42:57PM -0500, Sandro Tosi wrote: > > The test for this bug (and it should probably be recorded as an error, > > not just a warning, as no Python package should have a version number > > of 0.0.0) > > what exactly is the problem that would make it an 'error'? When a package uses pkg_resources to determine the version number of some package, it is returned the wrong information. This is certainly a packaging error: the upstream package, as installed by pip, announces "this is version 1.2.3" but the Debian package announces "this is version 0.0.0". In the couple of cases I've looked at so far, it is due to the upstream version using use_scm_version in setup.py. This works fine for a version that is in a Git repository, but it doesn't work for Debian packages, as the Git version lookup fails. So this needs to be patched. Perhaps a better way would be for dh_python3 to handle this by "teaching" use_scm_version to look at debian/changelog, as this would save 30+ packages having to continually update a setup.py patch. What do you think? Best wishes, Julian
Bug#1005043: lintian: check that Python version numbers are not 0.0.0
Package: lintian Version: 2.111.0 Severity: wishlist X-Debbugs-Cc: debian-pyt...@lists.debian.org I just ran into several Python packages that install modules with version number 0.0.0 because of some issue with their setup.py scripts. I just did the following on my testing system: lz4cat /var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_Contents-all.lz4 | grep 'usr/lib/python3/dist-packages/.*-0\.0\.0\..*-info/PKG-INFO' | wc -l 24 lz4cat /var/lib/apt/lists/deb.debian.org_debian_dists_testing_main_Contents-all.lz4 | grep 'usr/lib/python3/dist-packages/.*-0\.0\.0\..*-info ' | wc -l 6 So there are at least about 30 packages with this problem. The test for this bug (and it should probably be recorded as an error, not just a warning, as no Python package should have a version number of 0.0.0) is simple: if the binary package contains has a file or directory with the name as in the above regex, then the package has this error. Best wishes, Julian
Bug#1005043: lintian: check that Python version numbers are not 0.0.0
On Sun, Feb 06, 2022 at 04:46:53PM +, Stefano Rivera wrote: > Hi Julian (2022.02.06_12:19:54_+) > > In the couple of cases I've looked at so far, it is due to the > > upstream version using use_scm_version in setup.py. This works fine > > for a version that is in a Git repository, but it doesn't work for > > Debian packages, as the Git version lookup fails. So this needs to be > > patched. > > Or export SETUPTOOLS_SCM_PRETEND_VERSION. > https://github.com/pypa/setuptools_scm#environment-variables > > pybuild does this for you. Hi Stefano, I'm a little confused by this. Have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005039 against python3-iniconfig. It has a very straightforward debian/rules, using pybuild, and its setup.py script has "use_scm_version=True", but it still produces a python package with version number 0.0.0. I have tried this in an environment where I have python3-setuptools-scm installed, by the way (even though the package does not Build-Depends on it). I'm using dh-python version 5.20220119 Best wishes, Julian
Bug#999768: lintian: false report: adopted-extended-field
On Sun, Nov 21, 2021 at 07:23:32PM +0100, Francesco Poli wrote: > On Wed, 17 Nov 2021 00:56:11 +0100 Guillem Jover wrote: > [...] > > The same with XS-Go-Import-Path, and I guess a bunch of other fields > > that are unknown to dpkg-dev. > > Same here with my package (apt-listbugs). Ditto for (X-)Python-Version (though X-Python3-Version is correctly not included in the list of adopted fields). Julian
Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes
On Sun, Jan 16, 2022 at 08:37:33AM -0800, Felix Lechner wrote: > Hi Julian, > > On Sun, Jan 16, 2022 at 7:01 AM Julian Gilbey wrote: > > > > So perhaps another clause or two, something along the lines of the > > following, would be good? > > Your suggestion was implemented in: > > > https://salsa.debian.org/lintian/lintian/-/commit/d228765ce4db8057fd0c9780b2312c0e26914434 > > Thank you for making Lintian better for everyone! > > Kind regards > Felix Lechner Wow, fast work! Thanks Felix! I've just made one small suggestion on the commit. Best wishes, Julian
Bug#1053855: false positive for Python top_level.txt files: package-contains-documentation-outside-usr-share-doc
Package: lintian Version: 2.116.3 Severity: normal Just building a Python package with this version, and I receive the info tag: I: python3-bytecode: package-contains-documentation-outside-usr-share-doc [usr/lib/python3/dist-packages/bytecode-0.15.0.dist-info/top_level.txt] I think (almost) every Python package has a top_level.txt file that is automatically built, naming the top-level Python package, so this file should be excluded from this test. (The file always lives in a *.dist-info or *.egg-info directory.) Best wishes, Julian
Bug#1053855: false positive for Python top_level.txt files: package-contains-documentation-outside-usr-share-doc
On Fri, Oct 13, 2023 at 12:18:58AM +0530, Nilesh Patra wrote: > Control: tags -1 patch > > Hello, > > It seems that .dist-info and .egg-info are always ignored for this > warning anyway. However dist-info should contain > [...] > > On digging into dh-python changelog, I see the entry: > > * Remove RECORD files from dist-info, these are incompatible with > multi-arch. > > Then, I think it makes sense to remove this check from lintian as well. > > I've anyway opened an MR to fix this: > > https://salsa.debian.org/lintian/lintian/-/merge_requests/482 Amazingly fast deductive work there, Nilesh - thank you! Best wishes, Julian
Bug#1004746: lintian: provide a check for Python package version numbers validity
On Tue, Feb 01, 2022 at 07:57:58PM +0500, Andrey Rahmatullin wrote: > On Tue, Feb 01, 2022 at 02:45:21PM +0000, Julian Gilbey wrote: > > I just hit two packages which gave me the following warning when > > pkg_resources tried to load them: > > > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: > > PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an > > invalid version and will not be supported in a future release > > warnings.warn( > This looks strange to me. I wouldn't expect the package version > (especially with the Debian part) to be there. > I see flatbuffers runs `VERSION=$(DEB_VERSION) python$$pv setup.py build`, > I don't know why, or whether this is a good idea. Some updates on this: * The version information can also appear in /usr/lib/python3/dist-packages/*.dist-info/METADATA * The upstream standard is defined in PEP 440: https://peps.python.org/pep-0440/ I agree, flatbuffers is doing weird stuff. Best wishes, Julian
Bug#1027290: lintian: false positive missing-build-dependency-for-dh_-command dh_nodejs_autodocs when build-depends on dh-sequence-nodejs
Package: lintian Version: 2.115.3 Severity: normal My package-in-progress node-webfont declares Build-Depends: dh-sequence-nodejs, which is (only) provided by dh-nodejs. It uses dh_nodejs_autodocs, and lintian reports: E: node-webfont source: missing-build-dependency-for-dh_-command dh_nodejs_autodocs (does not satisfy dh-nodejs:any) [debian/rules] I suggest that this is a false positive. Best wishes, Julian
Bug#1004746: lintian: provide a check for Python package version numbers validity
On Thu, Jul 14, 2022 at 09:02:40AM +0100, Julian Gilbey wrote: > On Tue, Feb 01, 2022 at 07:57:58PM +0500, Andrey Rahmatullin wrote: > > On Tue, Feb 01, 2022 at 02:45:21PM +0000, Julian Gilbey wrote: > > > I just hit two packages which gave me the following warning when > > > pkg_resources tried to load them: > > > > > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: > > > PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is > > > an invalid version and will not be supported in a future release > > > warnings.warn( > > This looks strange to me. I wouldn't expect the package version > > (especially with the Debian part) to be there. > > I see flatbuffers runs `VERSION=$(DEB_VERSION) python$$pv setup.py build`, > > I don't know why, or whether this is a good idea. > > Some updates on this: > > * The version information can also appear in > /usr/lib/python3/dist-packages/*.dist-info/METADATA > * The upstream standard is defined in PEP 440: > https://peps.python.org/pep-0440/ > > I agree, flatbuffers is doing weird stuff. > > Best wishes, > >Julian A further update: a package with this type of bug recently caused an RC error, as it prevented other packages from loading: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036947 So if this check is implemented, it should probably raise an lintian Error if a package fails this check. (The related feature request #1005043 should probably only raise a warning.) Best wishes, Julian
Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
Package: lintian Version: 2.117.0 Severity: wishlist I have come across a number of packages with a line in their debian/rules like: ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS))) This should be "nodoc", according to the "nodoc" entry in https://wiki.debian.org/BuildProfileSpec#Registered_profile_names It would be good to check for this error.
Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
On Thu, May 09, 2024 at 01:13:45PM -0400, Louis-Philippe Véronneau wrote: > tags 1070770 patch > thanks > > I've created a patch on Salsa that creates a new Lintian check for this. > > https://salsa.debian.org/lintian/lintian/-/merge_requests/504 Amazing, thanks! I've added a bunch of suggestions/comments to the patch: the erroneous check in debian/rules is for the DEB_BUILD_OPTIONS setting rather than the DEB_BUILD_PROFILES setting, so it should refer to "options" rather than "profiles", even though the description for the "nodoc" option appears on the BuildProfilesSpec wiki page! I also suggest one tweak to the regex. Best wishes, Julian
Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
Hi Nilesh, On Sun, May 19, 2024 at 12:27:02PM +0530, Nilesh Patra wrote: > Julian Gilbey : > > I have come across a number of packages with a line in their > > debian/rules like: > > > > ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS))) > > > > This should be "nodoc", according to the "nodoc" entry in > > https://wiki.debian.org/BuildProfileSpec#Registered_profile_names > > > > It would be good to check for this error. > > This mostly looks like a typo and I am kinda sure that you'd find typos like > this all over many places. I am a bit unsure if checks for this is something > we > as a new lintian warning is something that we even need? Perhaps, perhaps not. It's not something that's easily spotted by eye unless you're explicitly looking for it. > Louis-Philippe Véronneau : > > ... > > I've created a patch on Salsa that creates a new Lintian check for this. > > > > https://salsa.debian.org/lintian/lintian/-/merge_requests/504 > > And if we do -- I checked the MR and it does not look extensible. If in > future there comes another class of typos, it will result in a new patch of > this > kind. Instead, is it possible to have a list of offending terms like this in a > data list and warn the user about them via a lintian warning? > > For instance, we have data/fields/obsolete-packages for listing obsolete > packages and showing the user about the obsolete packages and their > replacements. Do you think a similar implementation for this > (data/fields/bad-buildprofiles ?) makes sense? Now *that's* a really nice approach. But here I'd suggest doing the opposite: checking for valid build options (and note: this is a check for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES). There is a very short list of standard build options: those listed in dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse, hardening=..., reproducible=..., abi=..., future=..., qa=..., optimize=..., sanitize=...) and https://wiki.debian.org/BuildProfileSpec: nodoc Best wishes, Julian
