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
places 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 lintian-2.116.3/lib/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
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
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 =
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!
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
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
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
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"
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.
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:
>
>
>
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
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
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
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
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
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
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
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
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
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?
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
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
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
> >
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
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
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
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
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:
>
>
>
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:
>
>
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:
>
>
>
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.
/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
-04 16:05:07.0 +0100
+++ lintian-2.5.50.1+nmu1/debian/changelog 2017-03-05 21:22:21.0
+0100
@@ -1,3 +1,10 @@
+lintian (2.5.50.1+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * New tag: multiarch-foreign-shared-library
+
+ -- Helmut Grohne <hel...@subdivi.
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
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
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
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
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:
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; urgency=medium
+
+ * Non-maintainer upload.
+ * Add check for Pre-Depends: multiarch-support.
+
+ -- Helmut Grohne hel
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
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 to
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
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
On 28.03.2013, at 13:31, Helmut Grohne h.gro...@cygnusnetworks.de wrote:
$package ($origversion~$unixseconds~1.gbp$abbrevcommitid) …
** SNAPSHOT build @$longcommitid **
$origchangelog
-- $changedmaintainer
Unfortunately this does not work for all cases. When the distribution
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
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
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=revisi
N:
54 matches
Mail list logo
