Hi,
On 2024-05-23 23:33, Louis-Philippe Véronneau wrote:
As far as I understand, this means the vast majority of people using
Lintian won't see it at all. I thought this also meant the check wasn't
ran at all, but it seems I'm wrong and it only means the tag is hidden.
As such, I would certain
Hi,
On 2024-05-23 20:20, Russ Allbery wrote:
This is fantastic work. Thank you!
:)
Given that the time share is still 32%, though, I'm going to make an
additional controversial suggestion: perhaps we should provide an easy
documented shorthand to tell Lintian to not run "expensive" checks,
Hi,
On 2024-05-23 19:16, Andrius Merkys wrote:
This week I gave a shot at profiling lintian. I took a large source
package at hand (~400 MB) [1], built it and ran lintian on .changes file
under NYTProf:
$ PERL5OPT=-d:NYTProf bin/lintian -EviI --pedantic ../*.changes
NYTProf highlighted that
Hi,
On 2024-05-23 23:52, Louis-Philippe Véronneau wrote:
On 2024-05-22 16:36, Nilesh Patra wrote:
Hi Julian!
On Sun, May 19, 2024 at 01:48:17PM +0100, Julian Gilbey wrote:
But here I'd suggest doing the
opposite: checking for valid build options (and note: this is a check
for DEB_BUILD_OPTION
Hello,
This week I gave a shot at profiling lintian. I took a large source
package at hand (~400 MB) [1], built it and ran lintian on .changes file
under NYTProf:
$ PERL5OPT=-d:NYTProf bin/lintian -EviI --pedantic ../*.changes
NYTProf highlighted that over 70 % of the runtime was spent in se
Control: owner -1 !
Hi,
On Thu, 25 May 2023 17:27:48 +0200 Florian Lohoff wrote:
i am in the middle of a stretch rebuild for mipsel (Upgrade path from
jessie as stretch dropped 75% of supported systems with mips32)
A big issue are certificates, mostly for build tests which have an
expire date
Hello,
On Mon, 15 May 2023 15:54:23 +0300 Andrius Merkys wrote:
On 2023-05-12 21:34, Patrice Duroux wrote:
> What is astonishing me is that the Perl code of lintian uses calls to
encode_utf8/decode_uf8 in many places of different modules instead of fixing utf8
IO once in each.
> I f
Hi Patrice,
On 2023-05-12 21:34, Patrice Duroux wrote:
I tried to figure out why lintian is not going nicely adding also a
debian/source/lintian-overrides file in my packaging.
$ cat cherrytree/debian/source/lintian-overrides
# Ignore missing sources errors for test files.
source: source-is-m
Hello,
Maintainer of cherrytree here.
On 2023-05-08 20:48, Patrice Duroux wrote:
Following #1030720, the maintainer reported #1030743 and now I am trying
to package a new upstream version (0.99.55).
This is still an issue. I attempted to override lintian error with
adding the following to de
Package: lintian
Version: 2.116.3
Hello,
One of the packages I maintain, cherrytree, has a file
'tests/data_данные/test.export.html' which invokes source-is-missing
lintian error. However, Unicode symbols in lintian output are shown broken:
$ lintian cherrytree_0.99.53+dfsg-1.dsc
E: cherrytr
Hello,
On Sun, 30 Apr 2006 09:31:51 +0200 "Piotr Engelking"
wrote:
Some man pages contain the following snippet:
This manual page was written for the Debian distribution because the
original program does not have a manual page. Instead, it has
documentation in the GNU Info format;
Package: lintian
Version: 2.114.0
Hello,
lintian reports executable-in-usr-lib for executables under
/usr/lib/cgi-bin/, which is false positive. Directory /usr/lib/cgi-bin/
is designated for CGI scripts which require execution bit in order to be
runnable on the server-side.
All packages having e
Package: lintian
Version: 2.114.0
Hello,
Recently, Python PEP-517 build plugin pybuild-plugin-pyproject has been
introduced [1]. This means that some packages will build-depend on
pybuild-plugin-pyproject instead of dh-python, as
pybuild-plugin-pyproject depends on dh-python. Thus packages depend
On 2021-11-18 18:38, Christoph Berg wrote:
> The overengineered solution would be to exploit the fact that bug
> numbers are growing mostly linearly, and base the warning on the
> current date.
Fair point!
Andrius
Package: lintian
Version: 2.112.0
Hello,
improbable-bug-number-in-closes is false-positive now since bug numbers
have just hit 100. The problem could be fixed (for example) by replacing
max-bug = 100
with
max-bug = 200
in /usr/share/lintian/data/changelog-file/bugs-number.
By the
Control: found -1 2.110.0
Bug still persists in lintian/2.110.0 when building with gem2deb/1.6.
Spotted when attempting to get rid of "X-DhRuby-Root vs X-Dhruby-Root"
hint from spglib/1.16.2-1.
Andrius
Hi Felix,
On 2021-10-17 17:18, Felix Lechner wrote:
> On Tue, Oct 12, 2021 at 11:48 PM Andrius Merkys wrote:
>> So the fix now emits lintian error for lena_std.jpg as expected.
>> However, license-problem-md5sum-non-free-file seems superfluous to me.
> The duplicate issu
Hi,
On 2021-10-13 17:11, Felix Lechner wrote:
> On Tue, Oct 12, 2021 at 11:45 PM Andrius Merkys wrote:
>> However, license-problem-md5sum-non-free-file seems superfluous to me.
>> What do you think?
> I agree. Unfortunately, the two checks are in different places. We
> hav
Hi Felix,
On 2021-10-12 19:47, Felix Lechner wrote:
> What is the package name in Debian, please?
>
> I cannot locate it, and would like to test the fix.
>
> Aside from some basic sleuthing, I searched on packages.d.o: "You have
> searched for paths that end with lena_std.jpg in suite sid, all
>
Package: lintian
Version: 2.108.0
Hello,
I have located a variant Lenna image undetected by lintian in
python-docx upstream source [1] at
features/steps/test_files/lena_std.jpg. As requested by
license-problem-non-free-img-lenna tag, I am attaching md5sum, sha1sum,
and sha256 of this file:
$ md5
Package: lintian
Version: 2.106.1
Hello,
lintian emits false positive
new-package-should-not-package-python2-module tag for Python
python-*-doc packages [1]. This could be fixed by skipping binary
packages from Section: doc.
[1]
https://lintian.debian.org/tags/new-package-should-not-package-pyth
Hi Felix,
On 2021-09-17 22:02, Felix Lechner wrote:
> Control: retitle -1 lintian: flag upstream tests missing from autopkgtest
> I agree with you, and picked yet another title. Please let me know
> what you think.
I still think the original intent was to encourage the maintainers to
run upstrea
Hi Felix,
I noticed you changed the title of the bug report from "lintian: Warn if
a test suite exists but is not run" to "lintian: Warn about unused
autopkgtests", and I doubt this reflects the original intent of this bug
report.
I read the initial Raphael's message as asking to detect test suit
Hi Felix,
On 2021-02-16 12:29, Felix Lechner wrote:
> On Mon, Feb 15, 2021 at 10:45 PM Andrius Merkys wrote:
>>
>> I filed that as a bug in lintian, #976801.
>
> Your bug was resolved for both teams in Git on the day you filed. It
> was not marked pending, however
Control: owner -1 !
Hello,
I am interested in giving this feature a shot. I have started work on my
fork [1], and will submit a MR upon completion.
[1]
https://salsa.debian.org/merkys/lintian/-/commits/978552-report-outdated-manual-pages
Andrius
Hello,
On 2021-02-15 22:12, gregor herrmann wrote:
> On Mon, 15 Feb 2021 20:29:51 +0100, Axel Beckert wrote:
>> Jelmer Vernooij wrote:
So please stop adding "Testsuite:" headers if debian/tests/control is
already present.
Luckily the testsuite declared in debian/tests/control wa
Hi Felix,
On 2021-02-06 00:13, Felix Lechner wrote:
> Hi Andrius,
>
> On Fri, Feb 5, 2021 at 1:57 AM Andrius Merkys wrote:
>> Within the man-pages project, the necessary updates to these timestamps
>> are handled automatically
> I like your idea, but how can
As explained in [1], there actually are conventions for writing man
pages given in 'man 7 man-pages'. Thus .TH line can be trusted to
contain the date of last non-trivial change:
date:
The date of the last nontrivial change that was made to the man page.
(Within the man-pages project, the necessa
Package: lintian
Version: 2.104.0
Severity: wishlist
Maintainer manual pages are already reported by lintian in pedantic mode
[1]. Such manual pages may be OK per se, but, if outdated, they may
cause confusion for downstream users. Thus I think it is important to
report outdated maintainer manual
Package: lintian
Version: 2.104.0
One of the packages I maintain, restfuldb, carries around a broken
symlink named 'jquery-3.3.1.min.js', which causes lintian to emit
source-is-missing tag, which is false-positive. I suggest either
ignoring symlinks altogether, or checking if they at least point t
Package: lintian
Version: 2.104.0
Hello,
Tag team/pkg-perl/testsuite/no-team-tests does not seem to consider
multi-valued Testsuite field. The same issue may also be in pkg-js, but
this I have not checked.
I am working on a package already having pkg-perl autopkgtest suite, and
with 'Testsuite:
Hello,
On 2020-10-28 17:57, Felix Lechner wrote:
> Lintian does not presently utilize any network resources, and while
> that may change in the future, it would be the wrong way forward. It
> makes no sense for Lintian to query the archive for valid sections for
> every invocation.
I agree.
> Id
Package: lintian
Version: 2.48.0
Severity: minor
Hello,
I have encountered a strange lintian output on built deb, using 'lintian
-EviI --pedantic':
W: node-requirejs: nodejs-module-installed-in-usr-lib
usr/lib/nodejs/requirejs/package.json
N:
N: This package installs the specified file under
Hello,
I think that generally this is a good idea. However, such general
lintian check might be difficult to implement, but at least packages
built using maven-debian-helper could be checked.
I propose the following algorithm:
1. Check that package build depends on maven-debian-helper;
2. Check
Package: lintian
Version: 2.21.0
Lintian emits the following false positive error when building
node-inflection 1.12.0 [1]:
--8<
E: node-inflection source: pkg-js-autopkgtest-test-is-empty
debian/tests/pkg-js/test
--8<
Whi
bcache-fastmmap-perl.git
cd libcache-fastmmap-perl
gbp buildpackage --git-builder=sbuild
Could it be that there is a missing dependency on libtry-tiny-perl?
Best,
Andrius
--
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania
from %.yp, but not necessarily. However,
pre-generated parsers should be regenerated during package build anyway [1] due
to possible incompatibilities with Parse::Yapp driver.
Best,
Andrius
[1] https://lists.debian.org/debian-perl/2018/07/msg00026.html
--
Andrius Merkys
Vilnius Universit
s://lists.debian.org/debian-perl/2018/07/msg00026.html
--
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania
Hi Chris,
On 2018-10-19 06:15, Chris Lamb wrote:
> Fixed in Git, pending upload:
many thanks for a prompt fix!
Best wishes,
Andrius
--
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania
warning is somewhat misleading.
Thanks,
Andrius
--
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania
40 matches
Mail list logo
