Package: lintian
Version: 2.116.0
Control: affects -1 + libreswan
Lintian, when reviewing libreswan 4.9-1, reports:
I: libreswan: bash-term-in-posix-shell 'function cool('
[usr/libexec/ipsec/_secretcensor:31]
But in fact the code in question is:
--
awk ' function cool(hot, q, cooled,
On Fri 2022-02-11 12:51:06 -0800, Felix Lechner wrote:
> I confirmed that Lintian's invocation produces that error for
> usr/lib/dxvk/wine64-development/d3d10.dll.a in dxvk, but how can we
> tell such archives apart from those that are legitimately broken?
This error is also mistakenly produced
[including full text here because i've added lintian-maint here]
On Mon 2022-09-05 13:30:06 -0400, Daniel Kahn Gillmor wrote:
> On Sun 2022-09-04 13:56:20 +0200, Ansgar wrote:
>> On Thu, 2022-09-01 at 20:42 -0400, Daniel Kahn Gillmor wrote:
>>> I'm a little bit confused by t
Package: lintian
Version: 2.115.2
Severity: minior
Control: affects -1 src:gnupg2
lintian 2.115.2 complains (in --pedantic) in the following way about
these non-text files in the gnupg2 sources:
P: gnupg2 source: very-long-line-length-in-source-file 1008 > 512 [po/eo.gmo:7]
P: gnupg2 source:
Control: affects 968525 + libgpg-error-dev
On Thu 2021-08-19 20:52:16 -0400, Daniel Kahn Gillmor wrote:
> Control: affects 968525 - libgpg-error-dev
> Control: retitle 968525 lintian: breakout-link reported for
> /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlink
Control: affects 968525 - libgpg-error-dev
Control: retitle 968525 lintian: breakout-link reported for
/usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks
On Thu 2021-08-19 19:20:16 -0400, Daniel Kahn Gillmor wrote:
> I see the same issue in libgpg-error-dev with l
Control: affects 968525 + libgpg-error-dev libc6-dev
Control: found 968525 2.104.0
Control: retitle 968525 lintian: breakout-link reported for
/usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks,
conflicts with lacks-unversioned-link-to-shared-library
On Mon 2020-08-17
Control: affects 970275 + libgmime-3.0-doc
On Mon 2020-09-14 09:13:02 +0100, Simon McVittie wrote:
> However, it currently causes Lintian to emit
> package-contains-documentation-outside-usr-share-doc. Perhaps there could
> be logic like this pseudocode?
>
> for each file outside
On Fri 2021-02-26 04:48:50 -0800, Felix Lechner wrote:
> That's a great idea! As a first step, I would like to show a
> classification tag with the hash algorithm. (It could be used for
> statistics.) Can 'gpgv' output such signature characteristics?
sure, we have several different tools (like
Package: lintian
Version: 2.104.0
Control: clone -1 -2
Control: reassign -2 devscripts
Control: retitle -2 [uscan] deprecate upstream signatures made using weak
hashes like MD5, SHA1, or RIPEMD160
Some upstream packages are signed with OpenPGP using old, deprecated
digest algorithms.
See for
Thanks for the rapid followup, Felix! I really appreciate your ongoing
attention to detail with lintian. It's a very useful tool.
On Fri 2021-02-12 19:21:39 +, Felix Lechner wrote:
> Based on the information we have, the unversioned /usr/bin/python is
> going away in the upcoming 'bullseye'
Package: lintian
Version: 2.104.0
Control: affects -1 python3-gpg
This is a peculiar error message: lintian seems confused about what the
interpreter is for an example python script shipped in python3-gpg:
$ lintian python3-gpg_1.14.0-1+b2_amd64.deb | head -n1
P: python3-gpg:
Package: lintian
Version: 2.104.0
Control: affects -1 src:faketime
faketime's debian/rules contains:
%:
PREFIX=/usr dh $@
this is due to an idiosyncracy of the upstream build system, which sets
PREFIX to /usr/local by default unless it is set explicitly in the
environment. I
Control: retitle 947258 lintian: spare-manual-page is too strict (false
positives for subcommand man pages)
Control: affects 947258 + sq
Just noticed that manpage-without-executable was renamed to
spare-manual-page, so i'm updating the title of this bug report to
match.
I also noticed the same
Control: affects 947258 + libreswan
On Fri 2020-05-22 10:46:29 -0700, Felix Lechner wrote:
> So far, I learned that 'man' interprets two commands by default as a
> sub-command [1]
[…]
> [1] https://stackoverflow.com/a/32750157
Thanks for this pointer, interesting!
> but I do not know how to
On Mon 2020-04-13 09:52:32 -0700, Felix Lechner wrote:
> I do not see that tag when running lintian's development version
> against balsa from unstable:
there are separate issues with the appdata files in 2.5.9 (that have
since been fixed upstream):
Package: lintian
Version: 2.65.0
in balsa 2.6.0, balsa.appdata.xml is generated during the build from
balsa.appdata.xml.in.
While d/copyright correctly indicates that balsa.appdata.xml.in is
CC0-1.0, lintian still complains with:
W: balsa source: inconsistent-appstream-metadata-license
On Thu 2020-03-05 15:57:18 -0800, Felix Lechner wrote:
> I do not have much experience with PE32+, but I believe that turning
> off structured exception handling (i.e. setting 'no-SEH') is a
> potential security issue. Please consider this from the PE Format
> guide:
[ very informative details
Package: lintian
Version: 2.55.0
Control: affects -1 src:win-iconv
It seems like the check in checks/pe.pm for what it calls "SafeSEH" is
not aligned with the "Optional Characteristics" flag provided by
"genpeimg -x" as "no-SEH". After a build of win-iconv which follows the
instructions given in
Package: lintian
Severity: wishlist
Contro: affects -1 dh-python
When trying to build gpgme1.0 version 1.13.1-2, i encountered the
following warning from dpkg-gencontrol:
dpkg-gencontrol: warning: package python3-gpg: substitution variable
${python3:Versions} unused, but is defined
Package: lintian
Version: 2.41.0
Control: affects -1 notmuch
The stated version of lintian (and later) produces a
manpage-without-executable warning that is far too strict for modern
subcommand-oriented interfaces.
For example, on the notmuch package, lintian 2.42.0 emits:
I: notmuch:
Package: lintian
Version: 2.18.0
Severity: normal
Control: affects -1 src:wireguard
While resolving #930432 in the wireguard package, I noticed that the
code for lintian tag version-substvar-for-external-package appears to
only trigger if the dependency is on source:Version or binary:Version
but
Package: lintian
Version: 2.17.0
Severity: wishlist
Over in #931954, Michael Biebl pointed out that the
move to debhelper 12 (which installs systemd user services) resulted in
a conflict with the old manual way of installing systemd user services.
It would be great if lintian could notice that
On Tue 2019-03-05 10:57:03 -0800, Felix Lechner wrote:
> With source format 3.0 (git) that logic even found a way into the packaging
> system. Let's flip it around for a moment: Why not validate upstream
> signatures when the package is built?
sorry, i think i'm still not following. I *do*
Hi Felix--
On Wed 2019-02-27 13:07:20 -0800, Felix Lechner wrote:
> I wrote a Debian tool to create a shipping manifest with file-based
> hashes. Would it help to include that at the time of packaging? If the
> manifest is signed, we could do away with tarball signatures.
I think what you're
On Tue 2019-02-26 16:36:05 -0500, Chris Lamb wrote:
> I'm afraid it would, and would not be visible on lintian.d.o, and
> would also give different results in different environments. Whilst
> there is no strict written policy about this anywhere, this just
> feels "kinda" wrong, alas.
gotcha,
On Tue 2019-02-26 14:24:11 +, Chris Lamb wrote:
> [ dkg wrote: ]
>> Ideally, lintian would verify that there exists a signed tag in the git
>> repo found at Vcs-Git: (from d/control) […]
>
> Lintian "cannot" talk to external sources, so this is out alas…
How about talking to the local git
Control: tags 920763 - moreinfo
Hi Chris--
On Tue 2019-01-29 09:29:50 +0100, Chris Lamb wrote:
> Probably a silly question for this time in the morning but what is
> stopping you extracting the associated signature and calling it
> $origname.asc?
the signature matches the git commit, but not
Package: lintian
Version: 2.5.124
Severity: normal
Control: affects -1 src:wireguard
In wireguard's debian/watch, we have:
opts=mode=git,pgpmode=gittag
So we don't use an "upstream tarball" other than the git repo, which
has a signed tag in it. But lintian complains:
W:
On Mon 2019-01-14 23:50:47 +, Chris Lamb wrote:
> Chris Lamb wrote:
>
>> > The gnupg2 source package version 2.2.9-1 has this mismatch because i
>> > was sloppy.
>>
>> So, debian/copyright contains:
>>
>>Files: debian/org.gnupg.scdaemo
Re: https://bugs.debian.org/913723:
i've always thought that sections were effectively impossible to have a
clear "correct" answer for some packages. hyphenation and spellcheck
dictionaries are quite clearly packages for localization (they are
meaningful in the context of, and necessary for,
Package: lintian
Version: 2.5.119
when checking the hyphen source package, lintian claims:
I: hyphen-en-us: wrong-section-according-to-package-name hyphen-en-us =>
localization
but all hyphen-* packages are Section: text, as hyphen-en-us is. (see
the source for libreoffice-dictionaries, which
On Fri 2018-08-24 17:48:29 +0900, NIIBE Yutaka wrote:
> Daniel Kahn Gillmor wrote:
>> Question 1 (for gniibe)
>> ---
>>
>> Can you confirm whether udev needs to search "up the devpath" to
>> identify the Yubikey devices?
This is a complicated multipart issue. sorry for the large Cc list!
udev ATTRS{} vs. ATTR{}
===
back in https://bugs.debian.org/854616, on 2017-02-09 04:33:38 +0900,
NIIBE Yutaka suggested the following udev rule for Yubikey devices:
> ATTRS{idVendor}=="1050",
Package: lintian
Version: 2.5.97
Severity: wishlist
Lintian currently has some checks about appstream-metadata (the
AppStream metainfo xml files shipped with some software). It also has
some checks about debian/copyright.
The AppStream metainfo files have a member named metadata_license, as
On Tue 2018-04-10 18:37:06 +0100, Chris Lamb wrote:
> Thanks for looking at this. Fixed in Git with a testcase, pending upload:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=52e1bfac52ddba315ba66778570eb00b10c473de
thanks for the prompt action, Lamby!
i note the first
Package: lintian
Version: 2.5.81
Severity: normal
i've seen a few places in the debian archive where maintscripts or
initscripts avoid chown -R by using something like:
find /etc/lava-server/dispatcher.d/ -maxdepth 1 -exec chown
$LAVA_SYS_USER:$LAVA_SYS_USER {}
(the above is from
On Mon 2018-02-05 17:55:27 +0100, Raphael Hertzog wrote:
> I'm not quite sure of what colord is vulnerable. #889060 assumes the
> attacker can create arbitrary hardlinks as the "colord" user in
> /var/lib/colord. I don't know colord enough to know if that's the case
> and why that would be the
On Tue 2018-02-06 23:29:57 +0530, Chris Lamb wrote:
> Okay, let's give it another go :) Here we go:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=44b7f754de9c8380c08ca7ffe9c2902ea47ad99b
thanks!
s/Disbled/Disabled/
Also, maybe mention in the description that
On Mon 2018-02-05 04:38:14 +0530, Chris Lamb wrote:
> tags 889592 + pending
> thanks
>
> "Fixed" in Git, pending upload:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=293c897ef968e0f50ac4f48986034aeda57e179d
>
> Ah well, just too many false-positive cases.. I mean, we'd
1.19.0.5
ii libhtml-parser-perl3.72-3+b2
ii libtext-template-perl 1.47-1
-- no debconf information
>From 86eed052809dac1bb66fd9511d5884b54d705948 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <d...@fifthhorseman.net>
Date: Sat, 3 Feb 2018 15:15:50 -0500
Subject: [PATCH]
Package: lintian
Version: 2.5.72
Severity: wishlist
"chown -R" and "chmod -R" are very hard to use safely, and very
tempting as a sledgehammer to "just make the permissions be what i
want them to be".
some debian maintainer scripts might be tempted to use them to adjust
file ownership to
Package: lintian
Version: 2.5.72
Severity: normal
mozilla extensions might be "bootstrappable". if they are, they need
to have a "bootstrap.js file at the top level:
https://developer.mozilla.org/en-US/docs/Extensions/bootstrap.js
the alpha version of enigmail (a plugin to thunderbird,
On Fri 2017-08-18 14:43:58 +0200, Mattia Rizzolo wrote:
> I'd love if something did this for me, pretty much like I'd love
> something like that does a pretty output to debian/upstream/signing-key
> like
> https://sources.debian.net/src/inkscape/0.92.2-1/debian/upstream/signing-key.asc/
On Fri 2017-08-18 12:08:02 +0200, Guillem Jover wrote:
> Hmmm, I've been thinking about this a bit, and perhaps it would be
> better if dpkg-source auto-converted any .sig binary signature into
> an .asc ASCII armored one when generating the source package (as long
> as there is no pre-existing
Package: lintian
Version: 2.5.52
Tags: patch
Maybe it's just the kind of software that i maintain, but i've been
seeing a lot of "spelling-error-in-binary" and
"spelling-error-in-manpage" lintiain informational statuses that
suggest "CAs" should be "Case".
This isn't the case (ha ha) for
Package: lintian
Version: 2.5.51
Severity: normal
It doesn't look like the
restriction-formula-with-debhelper-without-debhelper-version lintian
tag is relevant any longer, since oldstable contains 9.20150101:
0 dkg@alice:~/tmp$ lintian-info --tags
On Fri 2016-07-22 17:31:15 -0400, Russ Allbery wrote:
> I do think we should support reproducible builds for all packages, and
> that our default build should be reproducible. I'm just not sure that we
> should rule out allowing packages to be configured to use default upstream
> behavior for
On Sat 2016-05-21 04:57:15 -0400, Axel Beckert wrote:
> during the (ongoing) Debian Perl Team Sprint, one of the discussed
> topics was dpkg-source now issuing warnings about weak signatures when
> extracting source packages. (For some time, in versions1.18.5 and
> 1.18.6, it even bailed out,
---
checks/watch-file.desc | 4 +++-
checks/watch-file.pm | 3 ++-
t/tests/watch-file-pubkey-missing/desc | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/checks/watch-file.desc b/checks/watch-file.desc
index 668169e..86a0960 100644
---
Package: lintian
Version: 2.5.5
Followup-For: Bug #661363
Hi lintian folks -- i'm on the fonts packaging team, which is also
responsible for fontforge. fontforge-nox does indeed provide
/usr/bin/fontforge, which we expect to behave the same as X11-capable
fontforge with respect to scripts. So
On 02/10/2011 02:38 AM, Christian PERRIER wrote:
Quoting Daniel Kahn Gillmor (d...@fifthhorseman.net):
On 02/09/2011 12:40 PM, Vasudev Kamath wrote:
Hi,
I'm packaging the following font package
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571723
As per my previous mail to the list I'm
On 02/09/2011 12:40 PM, Vasudev Kamath wrote:
Hi,
I'm packaging the following font package
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571723
As per my previous mail to the list I'm using new font name convention
(fonts-foundry-name). But I'm getting lintian error on the new font
Hi good people maintaining lintian.debian.org--
I notice that the version of lintian on l.d.o is 2.2.0, even though the
version in sid (and squeeze, now) is 2.2.8. Would you mind upgrading
lintian on l.d.o to the current version?
I bring this up because i had a little scare during my NM process
Package: lintian
Version: 2.2.8
Preparing a new version of a truetype font package for a number of
packaging cleanups, i changed its Section: to the new fonts section, as
announced here:
http://lists.debian.org/debian-devel-announce/2009/03/msg00010.html
However, lintian 2.2.8 complains:
W:
Package: lintian
Version: 1.23.28
Severity: minor
/usr/share/lintian/checks/rules.desc contains the handy
debian-rules-missing-required-target, but references the wrong debian
policy section.
It refers to section 4.8, but i think the appropriate section is 4.9,
as seen here:
56 matches
Mail list logo
