On Sun, 27 Mar 2011, Niels Thykier wrote:
> I cannot reproduce the warnings when using debuild -S (-us -uc) on the
> version of this package in unstable with the lintian from git.
The version in unstable has been fixed already, you should try
with the version in snapshot.debian.org:
http://snapsho
Hi,
your latest lintian commit is wrong, Built-Using is a field that appears
in the binary packages, not in the source package.
commit b7d9e253521b8641922a3b08091d7990d767db3a
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
On Mon, 28 Mar 2011, Niels Thykier wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2011-03-28 08:08, Raphael Hertzog wrote:
> > Hi,
> >
> > your latest lintian commit is wrong, Built-Using is a field that appears
> > in the binary
Hi,
On Sun, 15 May 2011, Russ Allbery wrote:
> I'm probably just reading a bit too much finality into "next version of
> dpkg (1.16.1) will keep," but it can be a bit off-putting to get the
> feeling that dpkg's source code is authoritative for the meaning of
> Policy-standardized fields and the r
Hello,
you're maintaining a Debian package which provides a trigger file.
Currently a package that "activates" a trigger is put in the
"triggers-awaited" status where it doesn't fulfill dependencies.
The trigger must first be processed and only then is the package
considered as "installed".
I bel
On Sun, 03 Jul 2011, Ansgar Burchardt wrote:
> Hi,
>
> please allow data.tar.xz in addition to data.tar.(gz|bz2). Support in
> dak will be coming soon.
FWIW this bug is blocking the deployment of XZ-compressed .deb since dak
will reject those deb until a fixed lintian is uploaded to
backports.de
On Thu, 22 Jun 2017, Raphaël Hertzog wrote:
> lintian complains with testsuite-autopkgtest-missing when debian/control
> is missing the "Testsuite" field but that field is usually not present
> in the unpacked source package because it is automatically added by
> dpkg-source to the .dsc when it fin
Hi,
On Thu, 06 Jul 2017, Niels Thykier wrote:
> On Thu, 22 Jun 2017 14:45:52 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?=
> wrote:
> > Package: lintian
> > Version: 2.5.51
> > Severity: normal
> >
> > lintian complains with testsuite-autopkgtest-missing when debian/control
> > is missing the "Testsuit
Hi,
On Thu, 10 Aug 2017, Chris Lamb wrote:
> Hi Raphaël,
>
> > I believe that the check maintainer-address-causes-mail-loops-or-bounces
> > should no longer refuse "*@packages.debian.org" in the Maintainer field.
>
> The regex is currently:
>
>/\@packages\.(?:qa\.)?debian\.org/i
>
> htt
Hi,
On Thu, 01 Feb 2018, Daniel Kahn Gillmor wrote:
> "chown -R" and "chmod -R" are very hard to use safely
Why ?
> some debian maintainer scripts might be tempted to use them to adjust
> file ownership to specific users. however, those scripts are
> vulnerable to attack on kernels that do not
Hi,
On Fri, 02 Feb 2018, Chris Lamb wrote:
> > you do not suggest any alternative (how do I fix change
> > permissions/ownership securely?)
>
> Indeed, as the consensus is still not clear at this point. Do you
> have any suggestions for such a text?
Consensus? Has there been a broader discussion
Hi,
On Fri, 02 Feb 2018, Chris Lamb wrote:
> > In my case, I remember having touched many packages with dedicated
> > users created and I expect this tag to have a very high false positive
> > ratio
>
> Can you make this more concrete? (Or, perhaps, why is colord
> vulnerable but your particular
Control: tag -1 - moreinfo
On Mon, 27 Oct 2014, Bastien ROUCARIES wrote:
> Do you have some normative element about this tag?
It's not hard to find:
https://en.wikipedia.org/wiki/Canonical_link_element
https://tools.ietf.org/html/rfc6596
And I agree that this is false positive that should be fix
Hi,
On Mon, 26 Feb 2018, Thomas Goirand wrote:
> Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly everyone
> build-depends on debhelper (>= 11), making it impossible to use the backported
> debhelper without fixing the debhelper version of the software to backport.
>
> It'd be n
On Fri, 04 May 2018, Chris Lamb wrote:
> Could you provide some concrete "good" and "bad" cases? I'm pretty
> sure I know what you're after here but want to be 100% certain,
> especially if we want this to be an "error". :)
Good (in the context of this lintian tag, though I would have used
1.10~be
Hi Chris,
On Mon, 07 May 2018, Chris Lamb wrote:
> I've just implemented this, but I notice that it overlaps with
>
> "W: latest-debian-changelog-entry-without-new-version"
>
> Do you think it's still worth adding (essentially) an "E:" version
> of this? I would tend to be in favour, given that
Hi,
On Tue, 08 May 2018, Mattia Rizzolo wrote:
> > > I think this warning was not in place yet when you made that mistake.
> >
> > This warning was added in 2007 so it's likely I just missed it.
>
> I doubt you missed it.
> latest-debian-changelog-entry-without-new-version is really what it
> sa
On Fri, 09 Feb 2018 22:07:52 + Chris Lamb wrote:
> Done:
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=1cadac3c48bf361c2894d56f2ef6fdf28bc32e9e
This commit does not really implement what was requested in this bug
report.
The desired logic is this one (untested patch):
---
On Tue, 08 May 2018, Chris Lamb wrote:
> Hi Raphael,
>
> > + tag 'latest-debian-changelog-entry-reuses-a-formerly-existing-version'
>
> Can you provide a quick description for this new tag? :)
Info: All versions for a source package must be unique, even with a leading
epoch stripped off. Howeve
On Sat, 02 Feb 2019, Niko Tyni wrote:
> On Mon, Jan 28, 2019 at 07:01:52PM -0800, Felix Lechner wrote:
> > Maybe the pending Perl commit 672eb451 will help? Details in #916313.
>
> FYI I've just uploaded perl/5.28.1-4 which fixes #916313.
Thanks for the notice, I tried with that version of Perl b
Hi,
On Wed, 20 Nov 2019, Felix Lechner wrote:
> There are many motivations:
Among those motivations, which one is the one that triggered this process
and which one are there as "additional benefits" that you could identify
to justify the change?
> 1. Shortens tag names.
I don't see that as a be
Hello,
I just want to point out that the search for the "sensible-*" commands
might be a bit too broad. It also finds the strings in
/usr/share/lintian/overrides/i3-wm-gaps...
Same issue in i3-wm in Debian:
https://lintian.debian.org/sources/i3-wm/4.17.1-1.html
Cheers,
On Wed, 22 Jul 2020, Raph
Hi,
On Mon, 27 Jul 2020, Chris Lamb wrote:
> > In Kali, our build daemons run "rebuildd" with a build script that calls
> > sbuild --run-lintian. Since lintian 2.85 (I believe 2.84.0 is not affected),
> > the build process get stuck at the point when lintian is run. I see two
> > lintian
> > proc
Hi,
On Wed, 14 Apr 2021, Lucas Nussbaum wrote:
> I think that in Debian, we would aim for a better separation between:
>
> A/ QA tools development, focused on getting the good tools to analyze
> packages (output: tools, as Debian packages)
>
> B/ infrastructure that mass-process the archive usin
Hello Axel, Bastien, Lucas, and other members of the lintian and QA teams,
it's been a long time that I have been interested in building some
infrastructure to manage scheduling and distribution of Debian-related
build, QA and data collection tasks to a network of worker machines. I
called this pr
On Sun, 17 Aug 2014, Johannes Schauer wrote:
> Lintian could check if any dependency on binary packages has an outdated
> version constraint. If the outdated version constraint is attached to an
> essential package, then the dependency can be dropped completely. This
> will then avoid useless trigg
On Fri, 29 Aug 2014, Johannes Schauer wrote:
> Hi,
>
> Quoting Raphael Hertzog (2014-08-29 21:16:06)
> > If that is ever implemented, it must apply only on dependencies that can be
> > parsed on the source's debian/control because I would not be happy to have
> >
On Fri, 29 Aug 2014, Johannes Schauer wrote:
> - only check the manual dependencies from debian/control (and not those
>generated by dpkg-shlibdeps because those are legit)
Definitely.
> - restrict the set of packages for which to warn to those that have to be
>translated (compilers). T
On Tue, 10 Jul 2012, Niels Thykier wrote:
> Actually, it sounds like it is a proper warning, since Squeeze (i.e.
> stable) still has 1.15.8.12. That means it could cause issues for
> people not upgrading dpkg before everything else (or for any package
> upgraded together with dpkg).
Right. It's a
Hi,
On Thu, 29 Aug 2013, Bastien ROUCARIES wrote:
> > Is there a consolidated list of concerns about 3.0 (quilt) somewhere?
>
> Not to my best knowledge.
The only technical concern that I'm aware of is that it doesn't work for
the workflow of debia...@lists.debian.org, they like to use quilt to
Hi,
On Thu, 05 Dec 2013, Roland Stigge wrote:
> To implement a correct fix, Ben asked for a decision by dpkg
> maintainers, FTP team and policy. Basically, the question is if
I think Guillem's position is rather clear, since he filed #718330
requesting support of data.tar in APT. I also agree wit
$ cat debian/control
Source: guest-installer
Section: debian-installer
Priority: standard
Maintainer: Jeremy Bobbio <[EMAIL PROTECTED]>
Uploaders: Raphael Hertzog <[EMAIL PROTECTED]>
Build-Depends: debhelper
Standards-Version: 3.7.3
Package: guest-installer
Architecture: all
Depend
On Tue, 30 Jan 2007, Russ Allbery wrote:
> > An example:
>
> > debian/control
> > Depends: ${shlibs:Depends} ${misc:Depends}
>
> > SUGGESTION
>
> > If possible, detect the missing commas in debain/control fields
> > like Build-Depends and Depends. That is:
>
> > * After a word or ending
On Sun, 25 May 2008, Mark Brown wrote:
> On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote:
>
> > So I am running the relevant autotools at build time but I still get the
> > warning.
>
> If you run autotools at build time you should also ensure that the
> changes which autotools make
Package: lintian
Version: 1.23.49
Severity: normal
If you generate a "3.0 (quilt)" source package with
$ dpkg-source --format="3.0 (quilt)" -b mypackagedir
and you analyze with lintian the generated source package you'll end up
with something like this:
W: quilt source: native-package-with-dash-ve
Package: lintian
Version: 1.23.49
Severity: wishlist
Usertags: 3.0-quilt-by-default
During my tests on the Debian archive, I have found several cases where (quilt)
patches in debian/patches/ do modify other files within the debian
sub-directory.
This is always wrong as the files in the debian dir
Hi,
On Wed, 04 Jun 2008, Joey Hess wrote:
> Raphael Hertzog wrote:
> > This is always wrong as the files in the debian directory are provided by
> > Debian.
>
> Unless they're provided by upstream...
Even in that case, the changes should end up in the .diff.gz an
severity 486145 normal
thanks
Upgrading to normal because lintian is really wrong. It's not just a
wishlist.
On Fri, 13 Jun 2008, Kevin B. McCarty wrote:
> The Lintian build-depends-on-obsolete-package and
> depends-on-obsolete-package checks are useful. But they make it harder
> to write debian
not always checking
all *.dpatch files.
Thanks for applying!
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
>From c632887347cb0fefb73b2b0247881232c04570d7 Mon Sep 17 00:00:00 2001
From: Raphael Hertzog <[EMAIL PROTECTED]
Package: lintian
Version: 2.0.0
Severity: normal
On libc6 in experimental I see:
E: libc6: shlib-missing-in-control-file libpcprofile.so for lib/libpcprofile.so
E: libc6: symbols-declared-but-not-shlib libpcprofile.so
But since libpcprofile.so has no version in its soname it simply isn't
represen
Package: lintian
Version: 2.0.0
Severity: normal
For some strange reason, the latest version of libmodule-build-perl
doesn't work for zim and thus I added a Build-Conflict to force the usage
of version of the module that is provided by perl-modules:
Build-Depends: debhelper (>= 5.0), perl-modules
On Sat, 27 Dec 2008, Russ Allbery wrote:
> It does look like they can be represented in the symbols system because
> the symbols system doesn't have the separate version field and instead
> shows the complete SONAME. Is that correct?
Right.
> happening somewhere. I've seen several different reg
clone 525782 -1
reassign -1 dpkg-dev
retitle -1 dpkg-gensymbols should strip #MISSING lines in symbols files in .deb
thanks
On Mon, 27 Apr 2009, Paul Wise wrote:
> Please warn about symbols files containing #MISSING: ...
It's not clear to me that they have to be stripped. They represent useful
in
On Fri, 26 Jun 2009, Raphaël Hertzog wrote:
> Since the upload of install-info to sid, packages installing info
> documentation should no more call install-info in their postinst.
Lintian could check this, it's probably best to add this check only once
debhelper has been fixed (see #534639).
> Yo
On Thu, 25 Jun 2009, Russ Allbery wrote:
> It's been there for quite a while. It needs to be modified so that
> passing --section to install-info isn't enough, but is there something
> more that it needs besides that, or some other problem with the existing
> Lintian check?
No, I didn't knew abou
On Mon, 14 Sep 2009, Modestas Vainius wrote:
> Just grep possible source symbol file templates for tag specification and
> warn
> if no strict dpkg-dev build dependency exists.
I'm not convinced that the requested check is really important (after all,
it will be useless in squeeze+1 when that ve
Package: bsdmainutils
Version: 8.0.1
Severity: serious
Since today I gets lots of lintian warnings (manpage-has-errors-from-man)
on my dpkg builds because col fails with:
col: Invalid or incomplete multibyte or wide character
You can reproduce it by doing this:
LANG=C man --warnings -E UTF-8 -l /
On Wed, 06 Jan 2010, Michael Gilbert wrote:
> during the patching process, quilt creates a .pc/.version file, which
> did not exist in the original source package. when lintian checks the
> package, it asserts a patch-system-but-direct-changes-in-diff warning.
quilt creates many more files in its
On Mon, 04 Jan 2010, Jakub Wilk wrote:
> Package: lintian
> Version: 2.3.1
> Severity: wishlist
>
> Please warn if a package ships files directly under
> /usr/share/mime/. Those files are meant to be automatically
> generated by triggers of the shared-mime-info package.
Please also catch /usr/sha
On Mon, 04 Jan 2010, Jakub Wilk wrote:
> Package: lintian
> Version: 2.3.1
> Severity: wishlist
>
> Please warn if a package ships files directly under
> /usr/share/mime/. Those files are meant to be automatically
> generated by triggers of the shared-mime-info package.
+1, I got bitten by this t
On Mon, 25 Jan 2010, Goswin von Brederlow wrote:
> Raphaël Hertzog writes:
>
> > We could also add a tag "using-old-source-format" that warns of specifying
> > 1.0 in that file. Obviously this one should start among the "pedantic"
> > tags but its importance might be increased over time once we
Hi lintian maintainers,
On Mon, 25 Jan 2010, Raphaël Hertzog wrote:
> As part of the plan to have the new source formats as the default formats in
> Debian I would like lintian to give a warning when debian/source/format
> doesn't exist, it could be named "missing-debian-source-format".
Do you wa
tag 566820 + patch
thanks
Hi,
On Tue, 02 Mar 2010, Russ Allbery wrote:
> > Do you want a patch for this? If yes, should it be a new check file or
> > do you want it integrated in one of the existing check file?
>
> At first glance, asking people to declare the source format explicitly
> seems li
Hello,
have you planned another lintian release for squeeze? I would like to see my
debian/source/format related checks (#566820) merged in the lintian
version that will be in squeeze.
Cheers,
--
Raphaël Hertzog -+- http://www.ouaza.com
Freexian : des développeurs Debian au service des entrepri
On Mon, 08 Mar 2010, Frank Lin PIAT wrote:
> Please find a patch attached that allow (and recommends) to provide
> sha256sums. (During a "transition period", we encourage people to
> provide both SHA and MD5, so existing setup don't get broken).
I'm not sure we should push for this right now. On t
Package: tech-ctte
(a change in lintian is triggering my request)
On Thu, 11 Mar 2010, Cyril Brulebois wrote:
> following the instructions given by Frans in [1], I've written a tiny
> check to ensure I wasn't missing any occurrences in the bunch of udebs
> I'm currently adding. I guess it would b
Hi,
On Wed, 07 Apr 2010, Don Armstrong wrote:
> > Anyway, I'd rather just make dpkg-dev special case udebs and not
> > output the field to the binary, even if I think that will imply lose
> > of automation and better integration among others, than a possible
> > solution shoved down the d-i team t
On Fri, 11 Mar 2011, Niels Thykier wrote:
> I have added Multi-Arch to the list of known binary fields. I assumed
> it did not apply to udebs, changes and source packages, please correct
> me if I am wrong here.
That's correct.
(For dpkg, udeb are no different from deb and thus they are allowed
Package: lintian
Version: 1.23.14
Severity: normal
While working on a new version of sql-ledger we decided to use hardlinks
(and not symlinks) between several files inside /usr/lib/sql-ledger/.
The upstream author prefers hardlinks over symlinks because they are
better handled by suexec. And since
Package: debhelper
Version: 5.0.16
Followup-For: Bug #109642
I'm ccing the current maintainers of lintian so that they can give their
opinion on this bug.
Given the opinions voiced in this bug log here's what I suggest :
Overrides should only be placed with care, that's right, that doesn't mean
On Sat, 21 Jan 2006, Russ Allbery wrote:
> > But IMHO, debian/.lintian-overrides should automatically be
> > installed in /usr/share/lintian/overrides/ by one of the dh_*
> > script (maybe dh_lintian could be folded into a generic dh_ script?).
>
> Please make it just .lintian; the directory listi
On Sun, 11 Jun 2006, Thomas Viehmann wrote:
> --- lintian-1.23.21/checks/files.desc 2006-05-04 05:37:21.0 +0200
> +++ lintian-1.23.21.tv0/checks/files.desc 2006-06-11 18:36:34.0
> +0200
> @@ -360,6 +360,12 @@
> Info: Debian packages should not install into /opt, because it
>
(moving to lintian-maint)
On Fri, 23 Jun 2006, Russ Allbery wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>
> > FWIW, packages using CDBS and the python-distutils class and
> > Build-Depending on "python-dev" have a similar warning... and yet they
> &
Package: lintian
Version: 1.23.21
Severity: wishlist
With the latest changes in python-related packaging, some comme patterns
of error are starting to emerge... so let's check them with lintian.
1/ If you detect dh_pysupport or dh_pycentral, you should have a
corresponding python-support or pyth
Package: lintian
Version: 1.23.34
Severity: normal
I worked on creating a Dpkg::Deps module for dpkg and used lib/Dep.pm as
inspiration for some parts. I think I discovered some errors in that
code while writing Dpkg::Deps.
If you want to compare with my (object-oriented version of the) code,
you
Hi,
On Mon, 15 Oct 2007, Russ Allbery wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>
> > Package: lintian
> > Version: 1.23.34
> > Severity: normal
>
> > I worked on creating a Dpkg::Deps module for dpkg and used lib/Dep.pm as
> > inspirat
On Wed, 17 Oct 2007, Frank Lichtenheld wrote:
> A short review turned up no obious flaws. I have no objections against
> merging it into master for inclusion in the next release.
Cool!
> Some notes:
> - Should the parsing algorithm enforce the negated arch syntax, i.e.
>that either none or a
Package: lintian
Version: 1.23.41
Severity: wishlist
Maintainers are now starting to use symbols files, but maintaining symbols
files needs quite some work and it's easy to forget doing it. It would be
good if lintian could help remind maintainers that they have to update
their symbols files. But
On Thu, 20 Dec 2007, Russ Allbery wrote:
> lintian has migrated to testing, so I'm now ready to update lintian.d.o.
> An update will mean a full-archive run, which takes a little more than a
> day, after which the old maintainer URLs will be no more and the new
> format with the e-mail address must
On Fri, 21 Dec 2007, Russ Allbery wrote:
> Okay, lintian is finishing its daily run for today right now, and as soon
> as that finishes, I'll kick off the full archive run. It should be done
> sometime on Saturday afternoon (US Pacific time), judging from past
> experience.
Ok. I updated the link
changelog 2007-12-27 19:36:29.00000 +0100
@@ -1,3 +1,10 @@
+lintian (1.23.41-0.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add checks on symbols files. Closes: #457067
+
+ -- Raphael Hertzog <[EMAIL PROTECTED]> Mon, 24 Dec 2007 10:31:34 +0100
+
lintian (1.23.41) unstable; urgency=low
The "it would be lovely if there were an actual desktop file standard"
Package: lintian
Version: 1.23.42
Severity: normal
I always get:
I: dpkg-dev: unknown-field-in-control bugs
I: dpkg-dev: unknown-field-in-control origin
Since dpkg-gencontrol propagates Origin and Bugs fields to binary packages,
lintian should accept them in binary packages.
Thus you need to add
On Tue, 08 Jan 2008, Russ Allbery wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>
> > Package: lintian
> > Version: 1.23.42
> > Severity: normal
> >
> > I always get:
> > I: dpkg-dev: unknown-field-in-control bugs
> > I: dpkg-d
Hi,
On Sat, 12 Jan 2008, Russ Allbery wrote:
> > I should also say that those should also be fixed IMO:
> > I: dpkg source: non-standard-arch-in-source-relation kfreebsd-i386
> > [build-depends: libselinux1-dev (>= 1.28-4) [!hurd-i386 !kfreebsd-i386
> > !kfreebsd-amd64]]
> > I: dpkg source: non-
Package: lintian
Version: 1.23.42
Severity: wishlist
I'd like a check like shlibs-declares-dependency-on-other-package but for
symbols files (we just had the case for zlib where lib64z1 generated a
dependency on zlib1g instead of itself).
It's somewhat related to
http://bugs.debian.org/cgi-bin/bu
Package: lintian
Version: 1.23.45
Severity: normal
The upcoming dpkg will add new fields in the .dsc and in the .changes
files: you should accept/recognize by default the fields
Checksums-Sha1, Checksums-Sha256 and Checksums-Md5 (though the latter is
auto-removed for now as it would be a duplicate
Package: lintian
Version: 1.23.45
Severity: important
The dpkg team is heavily refactoring dpkg-source and while using the new
version on my system, I discovered that it broke lintian because the output
messages got changed (and also -q will quiet all messages, not only warnings).
The problem is
Note that /usr/share/lintian/checks/cruft relies on unpacked being
a symlink so you'll have to take care of that too...
Because I just did the suggested change and got this:
Use of uninitialized value in string at /usr/share/lintian/checks/cruft
line 131.
Can't stat : Aucun fichier ou répertoire d
I get this with python-django_1.8.5-1.dsc
P: python-django source: source-contains-prebuilt-javascript-object
django/contrib/admin/static/admin/js/SelectFilter2.js line length is 360
characters (>256)
E: python-django source: source-is-missing
django/contrib/admin/static/admin/js/SelectFilter2.
On Mon, 19 Oct 2015, Bastien Roucaries wrote:
> Next version will be a little bit more clever. False positive are low
> about 5% woth thé actual détection
What next version are you referring to?
lintian 2.5.38.1 gives me even more false positives on Django 1.8.7-1 now:
E: python-django source: so
Hi,
On Wed, 20 Apr 2016, Ondřej Surý wrote:
> I think the lintian should not allow dependency on phpX.Y-, but
> only on php- (people can still override that), because we want
> packages to transition between different PHP versions by default.
>
> I'll review Mathieu's patches tomorrow and update
81 matches
Mail list logo
