Package: lintian
Version: 1.23.22
Severity: wishlist
Hi,
while packaging something locally, I got the
'php-script-but-no-php4-cli-dep' warning from lintian although the
package depends on php5-cli. Shouldn't this package suffice to provide a
cli php interpreter?
Perhaps change this check to
Package: lintian
Version: 1.23.29
Severity: normal
Hi,
lintian triggers no-md5sums-control-file on dependency only packages.
Obviously dh_md5sums didn't create an empty md5sums file (because all
other packages containing files got one).
One example is the php5 binary package, which only
Package: lintian
Version: 2.2.5
Severity: wishlist
Hi,
transitional packages (as deborphan would report them) usually have a short
extended description and there is no need to be very descriptive in this case.
So the extended-description-is-probably-too-short report could be disabled for
Package: lintian
Version: 2.2.10
Severity: normal
Hi,
running lintian on a native package with version '0' does not display
the version at all:
N: Processing changes file foobar_0_amd64.changes ...
N: Processing 2 packages...
N:
N: Processing source package foobar (version ) ...
N:
N:
Package: lintian
Version: 2.2.12
Severity: normal
Hi,
the way affected files are reported by linitian is inconsistent, some
tags report them with a leading './', others don't. E.g.
shared-lib-without-dependency-information ./usr/lib/libfoo.so.1.2.3
shlib-with-non-pic-code
Package: lintian
Version: 2.2.12
Severity: normal
Hi,
the diversion-for-unknown-file check produces false positives if
output redirection is used in the dpkg-divert invokation:
nvidia-glx: diversion-for-unknown-file usr/lib/libGL.so.1.2/dev/null preinst:89
for the following command:
Package: lintian
Version: 2.2.12
Severity: normal
Hi,
there is inconsistent naming used for several lintian tags, e.g.
shared-lib-without-dependency-information
shlib-with-non-pic-code
Probably only one prefix (shlib or shared-lib) should be used.
Andreas
-- System Information:
reopen 534942
thanks
Hi,
the fix recently applied for this bug causes some more false positives,
probably by treating a trailing digit of the file name as a file
descriptor being redirected: now I get reports like
E: nvidia-glx-legacy-173xx: diversion-for-unknown-file usr/lib/libGL.so.
Package: lintian
Version: 2.3.0
Severity: normal
Hi,
I just experienced a spurious lintian warning (watch file missing) on a
newly created local native package with version (0.0.1).
The warning disappears if I add a second revision (0.0.2) to debian/changelog,
so native detection does not work
Package: lintian
Version: 2.3.4
Severity: normal
Hi,
lintian fails to open an .orig.tar.xz tarball, probably lack of support
for the new compression scheme:
internal error: could not find the source tarball
warning: could not unpack package to desired level
Andreas
Just playing
Package: lintian
Version: 2.4.1
Severity: normal
Hi,
lintian reports incorrectly
W: nvidia-graphics-drivers source: stronger-dependency-implies-weaker
libcuda1-ia32 recommends - suggests nvidia-kernel${nvidia:Legacy}-source (=
${nvidia:Version})
for the following contruct in
Package: lintian
Version: 2.4.1
Severity: normal
Hi,
after changing the dpkg-divert call from
dpkg-divert --add --rename --package $DPKG_MAINTSCRIPT_PACKAGE --divert \
/usr/lib/nvidia/libGL.so.xlibmesa \
/usr/lib/libGL.so /dev/null
to
dpkg-divert $DIVERT_QUIET --add
Debian Bug Tracking System wrote:
#586984: lintian: wrong diversion-for-unknown-file */usr/lib/libGL.so
preinst:34
The wrong file name is gone, but now diversion-for-unknown-file does not
trigger at all.
Andreas
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a
Debian Bug Tracking System wrote:
#580494: lintian: stronger-dependency-implies-weaker false positives on
package names containing substvars
I'm still getting the same stronger-dependency-implies-weaker as before.
Andreas
--
To UNSUBSCRIBE, email to
Russ Allbery wrote:
Is that file shipped by the package?
If it isn't, could you please point me to a binary package where the tag is
no longer emitted with lintian 2.4.2?
It's not included in the package; it's doing weird things to divert the
MESA libraries. nvidia-glx is the package in
Raphael Geissert wrote:
...
preinst diverts the following files:
/usr/lib/$file
...
Since lintian doesn't know what $file actually means, it replaces it with a
wildcard (represented by '*' in the output.)
So, when it goes and looks for a file shipped by the package matching
/usr/lib/* it
In case someone is going to implement this in the future, the missing
field test should check for a Disclaimer: field in the header of contrib
and non-free packages.
Andreas
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Package: lintian
Version: 2.4.2
Severity: normal
Hi,
the copyright file of nvclock contains:
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGE-
MENT, AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL
NVIDIA, CORPORATION BE LIABLE FOR ANY SPECIAL, INDIRECT,
Package: lintian
Version: 2.4.3
Severity: normal
lintian does not work properly when binutils from experimental is
installed, I recorded the following errors when checking a kernel module
binary package. There are no errors on lenny or sid with binutils/sid.
(pbuild19643)r...@cake:/tmp# su
Package: lintian
Version: 2.5.0~rc2
Severity: normal
Hi,
I just came across a possible problem with multi-arch support of
libraries that have arch-dependent overrides. I do not mean overrides
that simply differ in the triplet, that is covered in bug #617991:
lintian overrides should support more
Package: lintian
Version: 2.5.0
Severity: normal
Tags: patch
Hi,
thanks for implementing arch-specific overrides. Due to a small logic
error, the negated ones do not work. This patch for Tags.pm fixes that
behaviour:
# missing wildcard checks and sanity checking archs $arch
On 2011-07-25 23:20, Niels Thykier wrote:
I just committed some changes for lintian that should fix this issue.
Unfortunately it might be a while till I have time to test it on a
multi.changes.
If you have the time, it would be great if you could fetch lintian
from git and run it[1] on your
Package: lintian
Version: 2.5.3
Severity: normal
Hi,
lintian reports false positives for the experimental tag
package-contains-no-arch-dependent-files
on transitional packages. These are usually empty by intention and there
is no use to convert them to arch:all packages if they haven't been
Package: lintian
Version: 2.5.4
Severity: wishlist
Hi,
update-alternatives should only be used in pairs.
Usually postinst will register an alternative with
update-alternatives --install ...
There should be a corresponding
update-alternatives --remove ...
in prerm (postrm would be ok,
Package: lintian
Version: 2.5.8
Severity: wishlist
Hi,
lintian should check for shipping files in more FHS/policy violating
locations:
/home (maildir-bulletin ships /home/bulletins/removed/)
/etc/opt (meant for configuration files for software in /opt)
(controlaula ships
Package: lintian
Version: 2.5.18.1
Severity: wishlist
Hi,
lintian should check for ucf/ucfr operating on configuration files that
are shipped by the package, either as files or as symlinks.
See #724457 and #722548.
Andreas
--
To UNSUBSCRIBE, email to
Package: lintian
Version: 2.5.19
Severity: normal
this looks like a recent regression, iirc 2.5.17 didn't show this:
E: nvidia-graphics-drivers source: version-substvar-for-external-package
nvidia-driver - glx
E: nvidia-graphics-drivers source: version-substvar-for-external-package
Package: lintian
Version: 2.5.21
Severity: normal
Running lintian on sendmail-base_8.14.4-4.1_all.deb reports
E: sendmail-base: maintainer-script-should-not-use-adduser-system-without-home
postinst:64
E: sendmail-base: maintainer-script-should-not-use-adduser-system-without-home
postinst:74
Package: lintian
Version: 2.5.27
Severity: normal
Hi,
while preparing the recent nvidia-cuda-toolkit [non-free] upload I
noticed a spurious lintian error while checking the .multi.changes I was
going to upload:
X: nvidia-cuda-dev: package-contains-broken-symlink
Package: lintian
Version: 2.5.28
Severity: normal
Hi,
I just got some
bad-intended-distibution intended to experimental but uploaded to UNRELEASED
I'm not exactly sure what a distibution is :-) (lacking an r).
I think this tag should not be emitted if the distribution is still set
to
On Wed, 01 Oct 2014 16:37:54 +0200 Vincent Danjean vdanj...@debian.org
wrote:
That said, I'm not sure how to detect that a package has been compiled with
versionned symbols for the libOpenCL.so.1 library.
With my latest changes, packages built against the non-free loader will
have an ORed
Package: lintian
Version: 2.5.30~bpo70+1
Severity: wishlist
Please add a test for packages shipping a copy of the python test
module, which seems to be starting a new series of file overwrite
errors. See https://bugs.debian.org/767400 for more background.
Andreas
--
To UNSUBSCRIBE, email to
Package: lintian
Version: 2.5.30+deb8u3
Severity: normal
running lintian several times in sequence sometimes outputs spurious
unused-override tags:
$ Lintian nvidia-graphics-drivers_340.65-1_amd64.changes
W: nvidia-detect: binary-without-manpage usr/bin/nvidia-detect
I: nvidia-driver:
Package: lintian
Version:
Followup-For: Bug #769365
I found two more packages shipping
/usr/lib/python2.7/dist-packages/tests/__init__.py today ...
(#788838, #788840)
I'd even vote for adding this to the ftp-master autoreject list :-)
Andreas
--
To UNSUBSCRIBE, email to
Package: lintian
Version: 2.5.30+deb8u4
Severity: wishlist
After we had /usr/*python*/tests/__init__.py recently, now we have a new
generic filename overwrite problem.
README.3pm.gz is way too generic to be shipped by an arbitrary perl
module. Currently libatombus-perl=1.0405-1 and
Package: Lintian
Version: 2.5.33
Severity: normal
Hi,
I just saw this in mysql-5.6:
mysql-5.6 source: source-contains-svn-conflict-file
mysql-test/std_data/crldir/ab8a3803.r0
which is a false positive with this content:
-BEGIN X509 CRL-
Followup-For: Bug #769365
More python bits that shouldn't creep into a package:
/usr/lib/python2.7/dist-packages/site.py
#801901, #801902
Andreas
Even more python bits that shouldn't creep into a package:
/usr/lib/python2.7/dist-packages/docs/__init__.py
#804642, #804643
Andreas
Package: lintian
Version: 2.5.37
Severity: normal
lintian now triggers these warnings on nvidia-xconfig (in contrib):
W: nvidia-xconfig source: dep5-copyright-license-name-not-unique (paragraph at
line 164)
W: nvidia-xconfig source: missing-license-paragraph-in-dep5-copyright gpl-2+
(paragraph
Package: lintian
Version: 2.5.33
Severity: important
I have a local configuration package that contains
/etc/apt/sources.available/*.list - various snippets that I can link
into /etc/apt/sources.d/
This triggers package-install-apt-sources although it shouldn't:
E: anbe-config-apt:
Package: lintian
Version: 2.5.33
Severity: important
Recent versions of lintian do not report unused-override any longer,
causing cruft to accumulate in debian/*.lintian-overrides.
Andreas
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe.
On 2015-07-12 16:36, Jakub Wilk wrote:
Recent versions of lintian do not report unused-override any longer,
Do you have a concrete example when it doesn't work?
No package in the archive (except perhaps fglrx-driver in non-free,
there may be an unused spelling correction of thE or something
Package: lintian
Version: 2.5.38.1
Severity: normal
Hi,
I'd guess that lintian does not accept the '+' character in tags when
reading the overrides, resulting in this:
E: nvidia-cuda-dev: malformed-override Cannot parse line 9:
missing-dependency-on-libstdc++
X: nvidia-cuda-dev:
Package: lintian
Version: 2.5.40.2
Severity: important
Hi,
I stomped on vcs-field-uses-insecure-uri in src:papi which had
Vcs-Git: git://anonscm.debian.org/collab-maint/papi.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/papi.git;a=summary
vcs-field-not-canonical was not
Package: lintian
Version: 2.5.42
Severity: normal
Hi,
on the povray package I'm going to upload soon, I get a spurious lintian
warning:
povray: spelling-error-in-binary usr/bin/povray ressize resize
but I cannot find the misspelled 'ressize' string neither in the binary
nor in the source.
Package: lintian
Version: 2.5.44
Severity: normal
Hi,
this paragraph from debian/copyright triggers a few false positives:
==
Files: debian/source/lintian-overrides
Copyright: © 2014 Pedro Pérez Pérez
© 2015 Wang Wang and Funi
© 2016 F. Ree License
License:
Package: lintian
Version: 2.5.47
Severity: normal
Hi,
W: libpfm4 source: typo-in-debhelper-override-target override_dh_auto_test: ->
override_dh_auto_test (line 30)
WTF?
$ grep -n override_dh_auto_test debian/rules
30:#override_dh_auto_test: $(PYTHON2:%=test-python%)
Package: lintian
Version: 2.5.50
Severity: normal
Hi,
I just came across these lintian report:
I: tkrat source: vcs-field-not-canonical
git://git.debian.org/git/collab-maint/tkrat.git
https://anonscm.debian.org/git/git/collab-maint/tkrat.git
I: tkrat source: vcs-field-not-canonical
Package: lintian
Version: 2.5.50.1
Severity: normal
src:openhpi currently has its -dbgsym packages listed in debian/control,
making them show up in the main archive.
Lintian should blacklist (and reject) binary packages listed in
debian/control that end in -dbgsym.
Andreas
Followup-For: Bug #884655
Same problem with multiarch-foreign-pkgconfig:
E: libpocl-dev: multiarch-foreign-pkgconfig
usr/lib/x86_64-linux-gnu/pkgconfig/pocl.pc
nothing foreign here, too.
Andreas
Package: lintian
Version: 2.5.63
Severity: important
I just bumped my current ITP project to debhelper 11 and tried the
latest lintian on it ...
E: libcubew-dev: multiarch-foreign-static-library
usr/lib/arm-linux-gnueabihf/libcube4w.a
There is nothing foreign in debian/control ...
Andreas
Package: lintian
Version: 2.5.65
Severity: normal
Hi,
I just filed two bugs against packages not cleaning up properly during
debian/rules clean after building the binary packages because the
override_dh_clean target does not call dh_clean (and the package build
directories are left under
And now I've hit myself with a quoted version number in a .maintscript
that got ~ and + escaped by debhelper 10:
'20100216+1~' ==> '20100216\+1\~'
single quotes and backslash escaping is too much ...
after unquoting:
20100216+1~ ==> 20100216\+1\~
See #881990, nvidia-kernel-common 20151021+5.
Package: lintian
Version: 2.5.61
Severity: normal
Hi,
I thought these should be fixed since 2.5.59 which closed #822504 with
"Don't warn about duplicate words when separated by punctuation.", but I
still get
W: foo: spelling-error-in-description FOO FOO (duplicate word) FOO
on this package:
Package: lintian
Version: 2.5.62
Severity: normal
Hi,
another file that shouldn't be shipped by a package:
/usr/share/glib-2.0/schemas/gschemas.compiled
was recently seen in grisbi, #883801
There are probably more candidated for such errors.
Looking for similar generated files in /usr/share
Package: lintian
Version: 2.5.57
Severity: normal
I just came around this incorrect dpkg-maintscript-helper invocation in
libreoffice-sdbc-firebird (#880426):
# Automatically added by dh_installdeb/10.9
dpkg-maintscript-helper dir_to_symlink /usr/share/doc/libreoffice-sdbc-firebird
Package: lintian
Severity: normal
Hi,
after the overly generic python module names, I now came across util.h
in two packages: libduo-dev, quaternion.
Maybe we need to start another list of generic names in Lintian ...
Andreas
On 2018-05-11 13:49, Chris Lamb wrote:
> Hi Andreas,
>
>> after the overly generic python module names, I now came across util.h
>> in two packages: libduo-dev, quaternion.
>
> Were these found by piuparts, or..? Just out of interest...
I have some scripts based on Ralf Treinen's work to
Package: lintian
Version: 2.5.84
Severity: normal
Hi,
recently python3-cclib and python3-hbmqtt started shipping a "scripts"
python module.
Andreas
Control: reopen -1
On 2017-12-26 19:23, Chris Lamb wrote:
> tags 726589 + wontfix
> thanks
>
> Hi,
>
>> lintian: version-substvar-for-external-package false positive if
>> the package name contains substvars, too
>
> As such variables are (no longer?) valid in the Package, Source and
>
Package: lintian
Version: 2.5.68
Severity: normal
$ lintian -I -E --pedantic python3-mimeparse_0.1.4-3_all.deb
P: python3-mimeparse: no-upstream-changelog
I: python3-mimeparse: capitalization-error-in-description-synopsis python Python
but the package is missing the python3 dependency, see
Package: lintian
Version: 2.5.50.4
Severity: normal
Another candidate for the backlist of too generic filenames:
/usr/lib/python2.7/dist-packages/backports/__init__.py
Seen in python-backports-shutil-get-terminal-size 1.0.0-3 (stretch) and
python-backports.tempfile 1.0-1 (sid) (#888558)
Control: tags -1 =
On 2017-12-30 09:40, Chris Lamb wrote:
> I also noticed that the package in question no longer generates this
> tag. Therefore, do you have another example?
It's just overridden ... without overrides I get
E: nvidia-graphics-drivers source:
Package: lintian
Version: 2.5.75
Severity: normal
Hi,
recently dxf2gcode and fenrir started shipping a "core" python module.
Andreas
Package: lintian
Version: 2.5.99
Severity: normal
Hi,
source-only-upload-to-non-free-without-autobuild does not seem to work
as intended ... it flags the nvidia-graphics-drivers package which has
been autobuilt for years ...
description =~ s/whiltelist/whitelist/
For the explanation I would
On 2018-01-23 23:28, Chris Lamb wrote:
> tags 735040 + pending
> thanks
>
> Fixed in Git:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=0cbebd4ba0b2a067383616e18981eeb9de5d7df2
Changelog (and commit) message says: "Rename bar to bar".
Probably caused by a global
driver.
* Build only a single binary package, no -dev package or shared library.
-- Andreas Beckmann <a...@debian.org> Sun, 22 Apr 2018 20:34:56 +0200
nvidia-settings (390.48-2) unstable; urgency=medium
* Add Provides+Conflicts: nvidia-settings-gtk-${nvidia:Version} to prevent
Package: lintian
Version: 2.5.83
Severity: normal
Hi,
this Description triggers a false positive:
Package: mysql-common
Description: MySQL database common files, e.g. /etc/mysql/my.cnf
I: mysql-common: description-synopsis-might-not-be-phrased-properly
N:
N:The package synopsis (also
On 2018-09-26 10:20, Chris Lamb wrote:
> Thanks for the changelog entry; any update on the tag description? Thanks!
update-inetd demoted the error to a warning for now: #909758
let me try some description:
The maintainer scripts contain calls to update-inetd with invalid
parameter combinations.
Package: lintian
Version: 2.5.99
Severity: normal
Hi,
I just found a collision on python{,3}-alembic and python{,3}-jaraco.itertools
which both ship
/usr/lib/python*/dist-packages/.pytest_cache/v/cache/nodeids
>From the path I conclude that this file shouldn't be shipped in any package.
Package: lintian
Version: 2.5.50.4
Severity: normal
Hi,
update-inetd got more strict recently w.r.t. valid option combinations,
and now errors out with
update-inetd: error: --group is only relevant with --add
update-inetd: error: --pattern is not relevant with --add
Some offenders:
LP:
On 2018-09-24 20:19, Chris Lamb wrote:
>> update-inetd got more strict recently w.r.t. valid option combinations
>
> Thanks for this. Can you draft a very rough tag description for this?
>
> I think I would also love to see which version got stricter (vs
> "recently") — it is not immediately
Package: lintian
Version: 2.5.122
Severity: normal
X: mariadb-server-10.3: package-contains-real-file-outside-usr lib/systemd/
X: mariadb-server-10.3: package-contains-real-file-outside-usr
lib/systemd/system/
X: mariadb-server-10.3: package-contains-real-file-outside-usr
Package: lintian
Severity: normal
libpython3.7-dev ships /usr/include/python3.7 -> python3.7m
Packages should not install and ship headers in /usr/include/python3.7/
but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
otherwise they will trigger piuparts installs_over_symlink_error.
Control: tag -1 - moreinfo
On 2019-01-21 10:13, Chris Lamb wrote:
>> Packages should not install and ship headers in /usr/include/python3.7/
>> but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
>
> Why? I'll need such an explanation for the long description. :)
Installing files
Package: lintian
Severity: wishlist
Hi,
I just wanted to answer "Is #910434 fixed in sid?" but the changelog
entry is inconclusive ...
spamassassin (3.4.2-1~deb9u1) stretch; urgency=high
* lots of changes
spamassassin (3.4.1-8) unstable; urgency=medium
* lost of changes
...
I would
Package: lintian
Version: 2.5.117
Severity: normal
Hi,
this seems to be a recent regression:
X: libcupti-dev: package-contains-no-arch-dependent-files
package contents:
drwxr-xr-x root/root 0 2018-12-11 22:15 ./
drwxr-xr-x root/root 0 2018-12-11 22:15 ./usr/
drwxr-xr-x
Package: lintian
Version: 2.5.124
Severity: normal
Hi,
I get false positives for command-with-path-in-maintainer-script in my
glx-alternatives package:
W: glx-alternative-nvidia: command-with-path-in-maintainer-script postinst:214
/usr/sbin/update-initramfs
W: glx-alternative-nvidia:
Package: lintian
Version: 2.10.0
Severity: normal
Hi,
I'm getting
X: lam4-dev: maintainer-script-supports-ancient-package-version preinst:4
7.1.4-3 (2012-04-09 < 2015-04-26)
in a not-yet-uploaded NMU 7.1.4-3.2 for src:lam.
== 8< debian/lam4-dev.preinst =
#!/bin/sh
set -e
if
Followup-For: Bug #683940
Hi,
I think that would be very helpful if there was an easy access to all
packages emitting autoreject tags to make sure they have proper RC bugs
Such packages usually won't be found during archive wide rebuilds.
I ran today into a 'debian-rules-missing-required-target
On 2019-05-27 14:15, Chris Lamb wrote:
> [Keeping CC as this is a fairly-obscure list]
>
> Hi Andreas,
>
>> I just stomped into https://bugs.debian.org/929614
>> Are there Lintian reports available for (old-)stable and testing to
>> check whether there are more cases that need to be fixed than
Hi Chris,
On 2019-05-27 14:24, Chris Lamb wrote:
Are there Lintian reports available for (old-)stable and testing [..]
> […]
>>> Unless someone else can correct me, I don't believe so… We have
>>> enough trouble keeping up with unstable as it is sometimes.
> […]
>> Are logs from all the
Hi,
I just stomped into https://bugs.debian.org/929614
Are there Lintian reports available for (old-)stable and testing to
check whether there are more cases that need to be fixed than just sid?
https://lintian.debian.org/tags/latest-debian-changelog-entry-reuses-existing-version.html
Andreas
On 01/11/2019 06.17, Felix Lechner wrote:
> I did not intentionally use features of newer Perls, but it's possible
> that it plays a role.
Found it:
https://perldoc.perl.org/perl5260delta.html#scalar(%25hash)-return-signature-changed
stretch$ perl -e '%a = (1,2,3); print scalar %a, " -- ",
Package: lintian
Version: 2.31.0
Severity: important
Hi,
rebuilding lintian/2.31.0 for stretch-backports (without any further
changes) fails due to several tests failing with
Cannot parse line Argument "1/8" isn't numeric in numeric eq (==) at
Hi Felix,
On 31/10/2019 18.54, Felix Lechner wrote:
> Please have a look at coreutils >= 8.30:> It could also be related to
> libberkeleydb-perl and libmldbm-perl, but
Thanks for the pointers, but it's none of these.
So I've started bisecting between 2.29.0 and 2.30.0 ...
In case you have
Hi Michael,
what is your opinion on a backport of coreutils 8.30-3 to stretch?
Background: lintian recently bumped the dependency to coreutils (>=
8.30) because it uses some newer feature, breaking its backport to
stretch. (#944258)
I could build it on stretch(+stretch-backports?) without
On Tue, 05 Nov 2019 10:15:29 -0800 "Chris Lamb" wrote:
> > lintian in Stretch backports contains leftover from merge
>
> This was fixed in 2.25.0~bpo9+1 or thereabouts; I simply neglected to
> close it. Thanks for reporting…
Not really:
$ COLUMNS=70 git diff 2.33.0..2.33.0_bpo9+1 --stat
Package: lintian
Version: 2.37.0
Severity: serious
Justification: causes ftp-master autorejects
Hi,
this is a regression in 2.36 or 2.37. It worked fine up to 2.35.
In povray, I have this in debian/source/lintian-overrides:
= 8< =
# upstream did not release a source tarball,
# the
On Sat, 14 Dec 2019 22:39:34 -0800 Felix Lechner
wrote:
> Hi Sam,
>
> On Tue, Jun 18, 2019 at 4:27 AM Sam Hartman wrote:
> >
> > Based on that I think we'd like lintian to detect when dh is not used
> > and allow maintainers to override the tag if they have an adequate
> > justification for
Package: lintian
Version: 2.45.0
Severity: wishlist
Hi,
since I regularily forget to bump my copyright years for debian/*, it
would be nice if lintian could remind me ;-)
If the package has a machine readable d/copyright
AND the person who did the last upload according to d/changelog is a
Package: lintian
Version: 2.42.0
Severity: normal
Hi,
please add /usr/lib/python3/dist-packages/examples/README.txt (and
possible variants thereof, in case lintian uses some wildcards for this
check) to the list of overly generic file names.
This is currently shipped by
python3-geopandas
On 24/12/2019 00.32, Felix Lechner wrote:
> Hi Andreas,
>
> On Mon, Dec 23, 2019 at 1:00 PM Andreas Beckmann wrote:
>>
>> please add /usr/lib/python3/dist-packages/examples/README.txt (and
>> possible variants thereof
>>
>> /usr/lib/python3/dist-packa
Package: lintian
Version: 2.64.0
Severity: normal
Hi,
I just tried to get rid of primus-libs-ia32 by changing the Recommends
in primus-libs from
primus-libs-ia32 (= ${binary:Version}) [amd64],
to
primus-libs:i386 (= ${binary:Version}) [amd64],
This nowadays works fine and I couldn't find any
Control: tag -1 - moreinfo
On 09/04/2020 01.01, Chris Lamb wrote:
> Any input on whether a brute grep for "-Wl,--as-needed" in debian/
> rules would be sufficient to catch most instances of these? (Feel free
I think you can just grep for '--as-needed', that will catch
-Wl,--as-needed (2579
Package: lintian
Version: 2.63.0
Severity: wishlist
Hi,
if I understood correctly, the bullseye toolchain defaults to linking
with --as-needed. Therefore it should no longer be neccessary to inject
-Wl,--as-needed into the build process, allowing d/rules to be further
minimized.
Some common
On Wed, 25 Mar 2020 09:26:09 +0100 Robert Luberda wrote:
> So I think it will be OK to do upload for unstable, however I still need
> to first check how to store the signature in my git repository. I did
> some tests few days ago, but I haven't got time to finish it. I'll try
> to do this before
Followup-For: Bug #954415
Control: found -1 2.57.0
I also get these while testing an i386 .deb on an amd64 host.
This is a regression introduced after the 2.55.0 release.
Andreas
Package: lintian
Version: 2.71.0
Severity: normal
Hi,
I just found a file conflict between medit=1.2.0-3 (buster) and
terminator=1.92-1 (bullseye) on
/usr/share/icons/hicolor/icon-theme.cache
which obviously shoudn't be shipped by any package.
There might be a few legitimate uses of
Package: lintian
Version: 2.74.0
Severity: minor
$ lintian primus-vk_1.4-2_amd64.changes
bad package file name primus-vk_1.4-2_amd64.changes (neither .deb, .udeb,
.ddeb, .changes, .dsc or .buildinfo file)
Hmm, it's a .changes file. But it wasn't in the current directory ...
Andreas
1 - 100 of 144 matches
Mail list logo
