Re: [Dehs-devel] Re: watch file check in lintian

2006-02-08 Thread Julian Gilbey
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

Bug#552526: lintian: add Typesetting section for doc-base section check

2009-10-27 Thread Julian Gilbey
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

Bug#712511: lintian: should check for references to update-notifier in postinst

2013-06-16 Thread Julian Gilbey
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

Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js

2017-09-05 Thread Julian Gilbey
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

Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js

2017-09-05 Thread Julian Gilbey
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

Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js

2017-09-06 Thread Julian Gilbey
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

Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js

2017-09-06 Thread Julian Gilbey
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 >

Bug#874381: lintian: false-positive source-is-missing bug for css_browser_selector.js

2017-09-05 Thread Julian Gilbey
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": > > >

Bug#906284: CC0 is short

2018-08-25 Thread Julian Gilbey
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

Bug#906284: lintian: check for incomplete-creative-commons-license gives false positives: the "not a law firm" is a preamble, not a license

2018-08-19 Thread Julian Gilbey
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 > >

Bug#906284: CC0 is short

2018-08-27 Thread Julian Gilbey
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 !~

Bug#1001575: lintian: duplicate-globbing-patterns notice says "(lines $lines)"

2021-12-12 Thread Julian Gilbey
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

Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts

2021-12-13 Thread Julian Gilbey
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

Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts

2021-12-14 Thread Julian Gilbey
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 foll

Bug#1001677: lintian: check for: "cd ... py3versions -r" in autopkgtest scripts

2021-12-15 Thread Julian Gilbey
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

Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes

2022-01-16 Thread Julian Gilbey
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 >

Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes

2022-01-16 Thread Julian Gilbey
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 varia

Bug#1004746: lintian: provide a check for Python package version numbers validity

2022-02-01 Thread Julian Gilbey
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:

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

2022-02-06 Thread Julian Gilbey
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

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

2022-02-05 Thread Julian Gilbey
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

Bug#1005043: lintian: check that Python version numbers are not 0.0.0

2022-02-06 Thread Julian Gilbey
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

Bug#999768: lintian: false report: adopted-extended-field

2022-01-20 Thread Julian Gilbey
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

Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes

2022-01-16 Thread Julian Gilbey
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

Bug#1053855: false positive for Python top_level.txt files: package-contains-documentation-outside-usr-share-doc

2023-10-12 Thread Julian Gilbey
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)

Bug#1053855: false positive for Python top_level.txt files: package-contains-documentation-outside-usr-share-doc

2023-10-12 Thread Julian Gilbey
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: > >

Bug#1004746: lintian: provide a check for Python package version numbers validity

2022-07-14 Thread Julian Gilbey
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/

Bug#1027290: lintian: false positive missing-build-dependency-for-dh_-command dh_nodejs_autodocs when build-depends on dh-sequence-nodejs

2022-12-29 Thread Julian Gilbey
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

Bug#1004746: lintian: provide a check for Python package version numbers validity

2023-06-09 Thread Julian Gilbey
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 > &g

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

2024-05-08 Thread Julian Gilbey
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

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

2024-05-09 Thread Julian Gilbey
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

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

2024-05-19 Thread Julian Gilbey
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))) > > >