Control: forwarded -1
https://salsa.debian.org/lintian/lintian/-/merge_requests/524
Hi Louis-Philippe,
On Wed, Sep 11, 2024 at 04:20:47PM -0400, Louis-Philippe Véronneau wrote:
> Thanks for your contribution.
Are you aware that your reply is not automatically sent to the bug
submitter? You may
-1)
+ * Delete tag subdir-in-bin: Installing anything in bin/ causes the
+emission of aliased-location now and subdirectories in usr/bin/ are
+actually allowed.
+
+ -- Helmut Grohne Wed, 14 Aug 2024 12:45:47 +0200
+
lintian (2.118.0) unstable; urgency=medium
* Retroactively add m
Source: lintian
Version: 2.118.0
Severity: serious
Tags: ftbfs
I attempted building lintian in unstable and this is what I got.
|
debian/test-out/eval/checks/debian/lintian-overrides/malformed/missing-colon/generic.t
ok
| # Hints do not match
| #
Hi Thorsten,
On Thu, Jul 06, 2023 at 05:26:43PM +, Thorsten Glaser wrote:
> Helmut Grohne dixit:
>
> > openjdk-8 (U)
>
> Should be convered by the Depends lines in the respective
> binary packages, e.g:
>
> Depends: openjdk-8-jre (>= ${sourc
t unversiond Replaces that
+are matched with neither Breaks nor Conflicts. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 24 May 2023 08:21:25 +0200
+
lintian (2.116.3) unstable; urgency=medium
The "FFP3 (Fixing False Positives, Three Small Changes)" Release.
diff -Nru lint
Package: lintian
Version: 2.115.3
Severity: wishlist
X-Debbugs-Cc: Joe Nahmias , Jelmer Vernooij
Hi,
Joe noticed a repetitive cross build failure. Can we turn that into a
lintian check?
Preconditions
* A source package builds an architecture-dependent binary package.
* The package Build-Depend
Package: lintian
Version: 2.114.0
Hi,
lintian emits the tag package-contains-hardlink in a lot of situations
where that tag is not reasonable. The referenced policy entry only
quires that conffiles are not hard linked. Beyond that, the tag
description reasons that hard links could cross mount poi
Hi,
On Sat, Oct 02, 2021 at 01:44:34AM +0100, Simon McVittie wrote:
> In the code changes in
> https://salsa.debian.org/lintian/lintian/-/commit/9bc560a6 I'm particularly
> suspicious about these two test-cases:
>
> my $orig = 'pkgA:any, pkgB, pkgC:i386';
> my $relation = Lintian::Relatio
Hi Felix,
On Sat, Mar 20, 2021 at 10:50:01PM -0700, Felix Lechner wrote:
> > Having lintian complain here definitely is a bug.
>
> Does the use of a three-part architecture restriction [1] in package
> relationships [2] really fit into a framework limited to two
> components? [3] Thank you!
Debi
Package: lintian
Version: 2.104.0
Severity: wishlist
Nilesh Patra discovered a recurring error pattern affecting cross builds
of Debian packages. People tend to confuse DEB_BUILD_* variables with
DEB_HOST_* variables. In debian/rules, this is difficult to detect
reliably as there are legitimate us
Control: tags -1 + moreinfo
Hi Guillem,
We concurrently wrote our replies, so this may duplicate your mail a
little.
On Wed, Feb 10, 2021 at 01:42:59PM +0100, Guillem Jover wrote:
> The systemd unit file directive SystemCallArchitectures is
> incompatible with Multi-Arch:foreign markings in a pa
Package: lintian
Version: 2.104.0
lintian emits
debian-rules-uses-supported-python-versions-without-python-all-build-depends
for cracklib2. The tag description says that one should depend on
python3-all for using py3versions. cracklib2 build depends on
python3-all-dev, which depends on python3-all
Hi Andreas,
On Fri, Nov 01, 2019 at 01:42:24PM +0100, Andreas Metzler wrote:
> This was not the fine point I had been was trying to ask about, though. ;-)
> - I was wondering why you suggested using a gnutls specific
> profile ("pkg.gnutls28.noguile") while the BuildProfileSpec lists
> "noguile" a
Hi Graham,
On Sat, May 25, 2019 at 06:06:08PM +0200, Graham Inggs wrote:
> But if a maintainer were about to upload a new package, or introduced
> changes to an existing package, that used DEB_BUILD* or DEB_TARGET* instead
> of DEB_HOST_MULTIARCH, I suspect the usage is most likely incorrect.
You
Hi Chris and Graham,
On Thu, May 23, 2019 at 03:01:01PM +0100, Chris Lamb wrote:
> tags 929433 + moreinfo
I concur that this bug report is not actionable.
> So, DEB_HOST_GNU_TYPE is used quite a bit already:
>
>
> https://codesearch.debian.net/search?q=DEB_BUILD_GNU_TYPE+path%3Adebian%2Frule
Package: lintian
Version: 2.6.0
Severity: important
User: helm...@debian.org
Usertags: rebootstrap
I use lintian to detect wrongly cross built packages. In this setup,
lintian is run by sbuild inside the (unstable) schroot after the build.
I pass "-T
binary-from-other-architecture,triplet-dir-and-
Hi Chris,
On Mon, Feb 18, 2019 at 02:11:59PM +0100, Chris Lamb wrote:
> Indeed. My now-obvious mistake was that I was following:
>
> https://wiki.debian.org/CrossCompiling#Building_your_own_cross-toolchain
I've updated that section to say that you don't need that. Thank you.
> .. instead of s
Hi Matthia and Chris,
On Sun, Feb 17, 2019 at 11:18:00PM +0100, Chris Lamb wrote:
> > For the advantage of everybody, here are links to the cross-builds from
> > amd64 to mips64el and arm64 of procmail.
Thank you.
> Wow, thanks for this! I had spent an hour trying to follow the
> instructions on
Control: retitle -1 provide a package name for lrelease-pro
Control: reassign -1 qttools5-dev-tools
Control: tags -1 =
On Thu, Feb 07, 2019 at 12:54:08PM +0300, Dmitry Shachnev wrote:
> Maybe when we package Qt 5.13, I can split lrelease-pro into a separate
> package that will depend on qt5-qmake.
Control: tags -1 - moreinfo
Hi Chris,
On Thu, Feb 07, 2019 at 09:04:39AM +0100, Chris Lamb wrote:
> (Not really. I do not have/use an sbuild or a crossbuild setup...)
If you use neither pbuilder nor sbuild, how do you build packages? Is
there another significant build environment that does not s
Hi Dmitry,
On Thu, Jan 31, 2019 at 10:56:37PM +0300, Dmitry Shachnev wrote:
> One thing bothers me: it is perfectly possible to use lrelease without qmake
> at all. All you need is have qttools5-dev-tools:native installed and call
> /usr/lib/qt5/bin/lrelease during build. You can do it from any no
Hi Chris,
On Wed, Feb 06, 2019 at 10:01:44PM +0100, Chris Lamb wrote:
> Replying quickly; do you happen to have the .deb still handy? If
> so, would be great to attach to this bug report as it will save
> folks the cross-build step. :)
I actaully don't. Recording such artifacts is beyond the capa
Package: lintian
Version: 2.5.124
Please cross build the procmail package for arm64 and for mips64el on an
amd64 build machine. In both cases, you'll get a successful build, but
the binaries inside the package are amd64 binaries despite the
arm64/mips64el architecture tag. As such, lintian should
Package: lintian
Version: 2.5.124
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap
A number of qt-related projects manage their translations using
lrelease. The current packaging of qmake implies that lrelease only
works when you have a native qmake installed. When you only have a
Package: arch-test
Version: 0.12-2
Severity: wishlist
Hi Adam,
The question "Does executable / shared libary / object file X plausibly
match Debian architecture Y?" needs to be answered in a number of
places. Most of them relate to QA in some way or another.
I am aware of the following implement
On Fri, May 04, 2018 at 07:54:46PM +0100, Chris Lamb wrote:
> How did you get on with this? :)
No. I was pondering it on irc and it didn't seem immediately actionable
to me. You wanted a bug report anyway and you got one.
Is there really much point in discussing whether tool diversity is good?
Th
Package: lintian
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap
Chris asked me to file this vague idea as a bug to keep track of the
discussion. If the discussion winds down, please don't hesitate to close
this as wontfix.
While making packages cross buildable, I noticed anothe
On Thu, Feb 01, 2018 at 06:21:00PM +, Niels Thykier wrote:
> >> Please switch the dot to a suitable character, such as slash, in
> >> pkg.$sourcepackage.$anything build profile names, since dot is a valid
> >> character in package names.
I acknowledge that this is a weakness of the namespacing
On Sun, Jan 28, 2018 at 11:45:37PM +0100, Mattia Rizzolo wrote:
> On Mon, Jun 01, 2015 at 10:40:12PM +0200, Sebastian Ramacher wrote:
> > #787406 was reported against libav today. It was caused by
> > debian/libavcodec-extra-56.lintian-overrides and
> > debian/libavcodec-extra-56.lintian-overrides.
On Fri, Dec 29, 2017 at 06:02:07PM -0500, James McCoy wrote:
> http://tirania.org/blog/archive/2012/Oct-20.html had some strong words
> to say about using pkg.m4. Are those concerns still valid? Should
> pkg.m4's macros be recommended or simply AC_PATH_TOOL?
That blog post looks like a misinform
Package: lintian
Version: 2.5.65
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap
Hi lintian maintainers and in particular Chris,
I have another wish for a lintian check and maybe Santa is gracious to
me this year. I've been filing ~1000 patches for cross build bugs and
that expe
Hi Chris,
On Fri, Dec 22, 2017 at 08:09:20PM +, Chris Lamb wrote:
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=70c81c7f1c9e96c8109988efe8aeca7ed17f122a
>
> Let me know if you have any suggestions :)
Yes, I do.
The tag description suggests that pkg-config could have b
Hi Chris,
On Wed, Dec 20, 2017 at 10:45:04PM +, Chris Lamb wrote:
> > If yes, what would be a good check? Should it just check the toplevel
> > configure.ac and configure.in or any file found on any directory level?
>
> This is my primary concern ??? warning about broken configure.{am,in} in
Package: lintian
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap
Hi lintian developers,
I would like to discuss a potentially new tag. If this makes sense, I'd
hope that someone can turn it into code. If not, please close as
wontfix.
After sending like 1000 cross build patches,
On Sun, Dec 10, 2017 at 03:54:41PM +, Chris Lamb wrote:
> > The tag I am requesting here mostly targets packages that lack any
> > Multi-Arch header (i.e. not covered by the above tag).
>
> Thank you for the clarification. :) I have just pushed the following:
>
>
> https://anonscm.debian.
On Sun, Dec 10, 2017 at 09:52:41AM +, Chris Lamb wrote:
> Hi Helmut,
>
> > TL;DR: I suggest ignoring Multi-Arch: foreign packages for the purpose of
> > this tag to remove false positives.
>
> Won't these binaries in /usr/bin (etc.) be picked up by:
>
> arch-dependent-file-not-in-arch-spec
Hi Chris,
TL;DR: I suggest ignoring Multi-Arch: foreign packages for the purpose of
this tag to remove false positives.
Explanation:
On Sat, Dec 09, 2017 at 10:44:26PM +, Chris Lamb wrote:
> I've implemented this in Git:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id
Package: lintian
Version: 2.5.59
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
I observe that multiarch adoption generally improves. Unfortunately,
maintainers tend to apply it in cases where it actually is wrong. So we
need to make lintian tell them that they shouldn't do that.
Usin
/changelog 2017-10-12 17:50:41.0 +0200
+++ lintian-2.5.55+nmu1/debian/changelog2017-10-14 12:49:16.0
+0200
@@ -1,3 +1,10 @@
+lintian (2.5.55+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Allow dependencies on e2fsprogs. (Closes: #-1)
+
+ -- Helmut
and $has_public_shared_library
+ and !$has_public_executable;
+
return;
}
diff --minimal -Nru lintian-2.5.50.1/debian/changelog
lintian-2.5.50.1+nmu1/debian/changelog
--- lintian-2.5.50.1/debian/changelog 2017-02-04 16:05:07.0 +0100
+++ lintian-2.5.50.1+nmu1/debia
Package: lintian
Version: 2.5.50.1
Severity: wishlist
Hi Niels et al,
while working on multiarchy stuff again, I needed to figure out which
packages are "empty". Lintian's notion of empty-binary-package was
helpful here, but I figured that it was missing a fair number of
packages that I would cha
Hi Pierre,
On Sun, Jul 17, 2016 at 09:42:51AM +0200, Pierre Chifflier wrote:
> I have applied your patch and build the package successfully. However, I
> got a lot of lintian errors related to the profile:
Oh, that's a step I didn't do indeed, though many of these are at least
partially false pos
Control: tags -1 - moreinfo
On Sat, Apr 23, 2016 at 02:38:54PM +, Niels Thykier wrote:
> The issue then being that Lintian can say very little about the
> dependencies of a given packages (except if it has none).
I agree. For this reason I implemented the check outside lintian on top
of dedup
Control: reassign -1 libsane-bin
Control: retitle -1 libsane-bin is wrongly marked Multi-Arch: foreign
On Sat, Apr 16, 2016 at 11:37:54AM +0200, Jakub Wilk wrote:
> $ dpkg-query -Wf '${Package}\t${Architecture}\n' libsane-{dev,bin}
> libsane-bin i386
> libsane-dev amd64
This is precisely the
Package: lintian
Severity: wishlist
Dear lintian maintainers,
I would like to propose a new check for lintian. It should trigger
whenever the following conditions are met simultaneously.
* The binary package being processed is a development package. The
easiest way probably is to look for se
Package: lintian
Version: 2.5.30+deb8u3
The usr-share-doc-symlink-without-dependency currently misses many
instaces of this problem that are occuring for real in Debian in a
reproducible way causing /usr/share/doc/$pkg/copyright to be out of
sync.
Relevant policy item:
https://www.debian.org/doc/
ru lintian-2.5.22.1/debian/changelog
lintian-2.5.22.1+nmu1/debian/changelog
--- lintian-2.5.22.1/debian/changelog 2014-03-30 21:11:37.0 +0200
+++ lintian-2.5.22.1+nmu1/debian/changelog 2014-05-08 18:48:01.0
+0200
@@ -1,3 +1,10 @@
+lintian (2.5.22.1+nmu1) UNRELEASED; urgen
Package: lintian
Version: 2.5.21
Severity: wishlist
Dear lintian Maintainers,
Please raise the file-name-is-not-valid-UTF-8 tag to error level,
because the aspect it enforces has reached the Debian policy in section
10.10 in version 3.9.5 with a MUST clause.
I suggest the following info text (ba
On Sat, Feb 08, 2014 at 11:03:13PM +0100, Jakub Wilk wrote:
> >Do you happen to have an alternative proposal in mind?
>
> Well, the simpler alternative is to make doxygen use unminified JS.
I am not yet entirely convinced about the "simpler" yet. Thanks for the
suggestion anyway.
Upstream goes t
On Mon, Feb 03, 2014 at 12:39:10PM +0100, Jakub Wilk wrote:
> Security is not the only issue here. jquery.js created by Doxygen is
> minified, so there's a risk that we ship it without source.
Thanks for highlighting the issue. Fortunately we already have a tool to
work around this issue. It is ca
Package: lintian
Version: 2.5.2
Severity: normal
Dear Maintainers,
Please stop warning about jquery.js as embedded by Doxygen. I evaluated
all options at fixing this issue in Doxygen and conclude that a fix is
infeasible and its usefulness is limited. The issue and the problems
about fixing it ar
On Sun, Jun 02, 2013 at 06:49:09PM +0200, Niels Thykier wrote:
> During the current full run, lintian.d.o ran out of inodes (1.9M). At
> the moment, I have disabled experimental which I hope will work around
> the problem for now.
I was working on something entirely different which happened to re
On 28.03.2013, at 13:31, Helmut Grohne wrote:
> $package ($origversion~$unixseconds~1.gbp$abbrevcommitid) …
>
> ** SNAPSHOT build @$longcommitid **
>
> $origchangelog
>
> -- $changedmaintainer
Unfortunately this does not work for all cases. When the distribution is
UN
Package: lintian
Version: 2.5.10.4
Severity: wishlist
It would be nice if lintian could warn about the use of non-UTF-8
sequences in filenames contained in binary packages. There currently is
a policy bug #701081 with the likely outcome of making this mandatory.
Even if the policy bug report does
Package: lintian
Version: 2.5.10.4
Severity: wishlist
The jenkins-debian-glue uses git-dch --snapshot to increase the version number
before building. Unfortunately it also changes the email address in the topmost
changelog entry, so lintian believes such a package to be a NMU. Now lintian
already
Package: lintian
Version: 2.5.10.4
Severity: wishlist
It would be nice if lintian could report about broken gzip files. The
following command can be used to achieve this (on an unpacked binary
package):
find -type f -iname \*.gz -print0 | xargs --no-run-if-empty --null gzip --test
As of this rep
Package: lintian
Version: 2.5.10.3
Severity: wishlist
The current extra-license-file check only looks for files named like
m/(?:copying|licen[cs]e)(?:\.[^/]+)?/. Unfortunately this pattern misses
a number of copies. I investigated the situation for sid and came up
with the following list of embedd
Package: lintian
Version: 2.5.4
Severity: minor
This is the current message for unversioned-copyright-format-uri:
N:
N:Format URI of the machine-readable copyright file is not versioned.
N:
N:Please use
N:http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision= as the fo
58 matches
Mail list logo
