Review of debusine's lintian related API

[Raphael Hertzog]

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 project debusine:
https://salsa.debian.org/freexian-team/debusine/

It has been started a while ago but thanks to external funding, its
development pace is about to increase significantly. It is being developed
by Freexian with the intention of giving people access to a range of
pre-configured tools and workflows running on remote hardware.

We want to make it easy for Debian contributors to leverage all the great
QA tools that Debian provides. We want to improve and modernize Debian's
build infrastructure, while also enabling distribution-wide experiments,
custom package repositories and custom workflows with advanced package
reviews.

Analyzing lintian results is an important step in any serious package
review workflow and as such, our current milestone plans to make it
possible to run lintian on debusine workers. As lintian and QA experts, we
would love to have your feedback on our plans, in particular on the public
interface that we have designed.

To give a bit more context, as a debusine user with an API key, you can
submit "work requests". Each work request has a "task" assigned to it
(e.g. sbuild, autopkgtest, lintian) and some JSON data that gives more
details about the specific task. The structure of the JSON data varies
from task to task but it basically defines the public API that lets users
schedule work requests to debusine. The result of the work request
(including any artifact generated) will then be stored in the database and
made available for consumption by the user through the API.

As an example, here's how the data could look like for a simple lintian
work request:

{
"input": {
"source_artifact_id": 1234,  # References the source package to analyze
"binary_artifact_id": 1235,  # References the set of binary packages to 
analyze
},
"target_distribution": "debian:unstable",
"lintian_version": "2.116.3",  # Or minimal_lintian_version ?
"fail_on_severity": "error",
}

We are currently drafting the expected structure of that JSON data for
lintian (and autopkgtest) work requests in this merge request and we would
appreciate if you could review it:
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300

I have left some open questions in the document and there are some
unresolved review threads that have interesting questions too.

We are aware that this duplicates work made by Lucas in the context of
UDD, but we are trying to achieve a high level of integration and sharing
worker setups across different QA tools, and duplication seems unavoidable
in that context. We are certainly eager to cooperate and make it easy for
UDD and debusine to work hand-in-hand. A future milestone will make it
easier to export distribution-wide summary of data collected through such
work requests.

We plan to provide a debusine.debian.net/org instance accessible to all
Debian developers in the near future, so you will be able to experiment
and make use of the API that you will have helped to shape.

If you have questions about debusine, don't hesitate to ask. If you are
interested to follow along and/or help, you are more than welcome to:
https://freexian-team.pages.debian.net/debusine/devel/contributing.html

Have a nice day,
  Raphaël.

PS: You might find it useful to browse the documentation to learn more about the
goals and the high level concepts:
https://freexian-team.pages.debian.net/debusine/devel/why.html
https://freexian-team.pages.debian.net/debusine/design/index.html

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#960154: Feed UDD with just-in-time packaging hints from Lintian

[Raphael Hertzog]

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 using QA tools. (output:
> current status of each package in Debian, analyzed with the latest
> version of a given tool, as a parsable file)
> 
> C/ infrastructure that gathers the current status from all instances of
> (B) and exposes it per-package, per-maintainer, per-team, etc.
> 
> (C) could even be split into:
>   (C.1) infrastructure that gathers the status and stores it into a
>   common DB;
>   (C.2) infrastructure that uses (C.1) to provide useful
>   per-package/per-maintainer frontends (views).

Fully agreed on this. tracker.debian.org is clearly in the scope
of (C) but started to move into (B), but once I realized this I decided
that it would be better to have a separate project, that's how I ended
up designing "debusine".

See 
https://salsa.debian.org/freexian-team/debusine/-/blob/master/docs/devel/why.rst

As I announced a few days ago, I will invest Freexian's money
in this project so you're welcome to watch the project (in gitlab speak,
aka enable notifications) so that you can contribute to its design.

The first milestone will be oriented towards package building,
not lintian processing but I'm happy to include this in the roadmap
at some point.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#966368: lintian gets stuck when run by sbuild within rebuildd

[Raphael Hertzog]

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
> > processes (a parent and its child) and both are stuck in epoll_pwait()
> > according to strace.
> 
> I think this is the same as #966122 and/or #966072.

Looks like the same as #966122 since it seems to break in the same check
(deb-format which is the only place where I expect "ar t" to be called).

I didn't find this one while looking for duplicate... I saw #964770 but it
didn't seem exactly the same issue.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#966022: lintian: False positive on missing-depends-on-sensible-utils with commands like i3-sensible-pager

[Raphael Hertzog]

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, Raphaël Hertzog wrote:
> In this package https://gitlab.com/kalilinux/packages/i3-gaps we have the
> following lintian errors:
> 
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3-sensible-pager
> 
> But they are wrong:
> 
> $ grep -r sensible-pager src/
> src/bindings.c:sasprintf(, "i3-sensible-pager \"%s\"\n", 
> errorfilename);
> src/config_parser.c:sasprintf(, "i3-sensible-pager \"%s\"\n", 
> errorfilename);
> 
> The program is calling i3-sensible-pager (provided in the same package)
> and not "sensible-pager".
> 
> Cheers,
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
> 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages lintian depends on:
> ii  binutils  2.34.90.20200706-1
> ii  bzip2 1.0.8-3
> ii  diffstat  1.63-1
> ii  dpkg  1.20.5
> ii  dpkg-dev  1.20.5
> ii  file  1:5.38-5
> ii  gettext   0.19.8.1-10
> ii  gpg   2.2.20-1
> ii  intltool-debian   0.35.0+20060710.5
> ii  libapt-pkg-perl   0.1.36+b3
> ii  libarchive-zip-perl   1.68-1
> ii  libcapture-tiny-perl  0.48-1
> ii  libclass-xsaccessor-perl  1.19-3+b5
> ii  libclone-perl 0.45-1
> ii  libconfig-tiny-perl   2.24-1
> ii  libcpanel-json-xs-perl4.19-1
> ii  libdata-validate-domain-perl  0.10-1
> ii  libdevel-size-perl0.83-1+b1
> ii  libdpkg-perl  1.20.5
> ii  libemail-address-xs-perl  1.04-1+b2
> ii  libfile-basedir-perl  0.08-1
> ii  libfile-find-rule-perl0.34-1
> ii  libfont-ttf-perl  1.06-1
> ii  libhtml-parser-perl   3.72-5
> ii  libio-async-loop-epoll-perl   0.21-1
> ii  libio-async-perl  0.77-3
> ii  libjson-maybexs-perl  1.004002-1
> ii  liblist-compare-perl  0.53-1
> ii  liblist-moreutils-perl0.416-1+b5
> ii  liblist-utilsby-perl  0.11-1
> ii  libmoo-perl   2.004000-1
> ii  libmoox-aliases-perl  0.001006-1
> ii  libnamespace-clean-perl   0.27-1
> ii  libpath-tiny-perl 0.114-1
> ii  libsereal-decoder-perl4.014+ds-1
> ii  libsereal-encoder-perl4.014+ds-1
> ii  libtext-levenshteinxs-perl0.03-4+b7
> ii  libtext-xslate-perl   3.5.8-1
> ii  libtime-duration-perl 1.21-1
> ii  libtime-moment-perl   0.44-1+b2
> ii  libtimedate-perl  2.3300-1
> ii  libtry-tiny-perl  0.30-1
> ii  libtype-tiny-perl 1.010002-1
> ii  libunicode-utf8-perl  0.62-1+b1
> ii  liburi-perl   1.76-2
> ii  libxml-libxml-perl2.0134+dfsg-2
> ii  libxml-writer-perl0.625-1
> ii  libyaml-libyaml-perl  0.82+repack-1
> ii  man-db2.9.3-2
> ii  patchutils0.3.4-3
> ii  perl [libdigest-sha-perl] 5.30.3-4
> ii  t1utils   1.41-4
> ii  xz-utils  5.2.4-1+b1
> 
> Versions of packages lintian recommends:
> ii  libperlio-gzip-perl  0.19-1+b6
> 
> Versions of packages lintian suggests:
> pn  binutils-multiarch 
> ii  libtext-template-perl  1.59-1
> 
> -- no debconf information

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#943525: Namespaces for Lintian Tags

[Raphael Hertzog]

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 benefit, we copy/paste the tags into overrides
or full lines into lintian-info. We rarely need to type them.

> 2. Points to the code that issued the tag.

"grep -r" on the codebase has been working well for me. This mapping
is only really needed when you want to dig into the code anyway.

> 3. Frees up name space (good tags are rare).

Can you show examples of how this would help you concretely?

I have a hard time seeing how difficult it can be to invent
a new name for a new tag.

> 4. Multiple checks can use the same tag in different contexts (i.e. 
> 'spelling').

spelling-error-in-binary
spelling-error-in-description
spelling-error-in-changelog
etc

is perfectly fine.

> 5. Preempts name conflicts in case some check-writing is delegated to
> expert teams.

This is not a real problem, that's the kind of pseudo-benefit that you
try to imagine to justify the change that you want (I have done
that many times ;-)).

> 6. Quicker to split large checks when components reuse tag names.

I don't follow you. For me splitting checks means they get renamed and
thus your tag names are renamed too.

> 7. Brings consistency between Lintian and custom profile users, such
> pkg-perl-tools and pkg-js-tools, who already have private namespaces.

A very minor benefit IMO.


Now can you do the same analysis with the disadvantages?

Since the check is embedded in the tag name:
* It's harder to move a tag from one check to another.
* It's harder to rename a check.

What else can you come up with?

> The change is technically easy. (Lintian even has a way to track
> renamed tags for overrides.) On an optical level, however, the change

I was about to ask for overrides, but this would be a massive usage of
this rename feature and it will confuse many persons. People will start
to use the new name in overrides to avoid this confusion and it won't work
with old lintians (not a big deal but still).

> will affect a lot of people. It could even cause headaches for some
> users, for example in derivatives. We would like to solicit your
> input.

What kind of headaches are you referring to?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#920691: lintian gets stuck collecting info after failed objdump-info

[Raphael Hertzog]

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 but the problem I
reported is still present. So it seems unrelated.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889991: Debian part of a version number when epoch is bumped

[Raphael Hertzog]

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. However the version in the latest changelog entry, after
 removal of the epoch, matches a version that existed in the past and that is
 recorded in another changelog entry.
 .
 The Debian archive does not allow multiple files with the same name and
 different content, and the name of the generated files (.dsc, .deb, etc.) do 
not
 embed the epoch. That is why the files generated by the current version of this
 source package would be in conflict with some historical files.
 .
 You should thus pick another version (for example by increasing the Debian
 revision until you no longer have any conflict).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889991: Debian part of a version number when epoch is bumped

[Raphael Hertzog]

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):
--- a/checks/changelog-file.pm
+++ b/checks/changelog-file.pm
@@ -318,15 +318,19 @@ sub run {
 my $second_version = $entries[1]->Version;
 if ($first_version and $second_version) {
 tag 'latest-debian-changelog-entry-without-new-version'
-  unless versions_gt(
-$first_version =~ s/^([^:]+)://r,
-$second_version =~ s/^([^:]+)://r
-  )
+  unless versions_gt($first_version, $second_version)
   or $entries[0]->Changes =~ /backport/i
   or $entries[0]->Source ne $entries[1]->Source;
 tag 'latest-debian-changelog-entry-changed-to-native'
   if $native_pkg and $second_version =~ m/-/;
 }
+my $first_version_without_epoch = $first_version =~ s/^([^:]+)://r;
+foreach my $entry (@entries[1..$#entries]) {
+my $entry_version_without_epoch = $entry->Version =~ 
s/^([^:]+)://r;
+tag 
'latest-debian-changelog-entry-reuses-a-formerly-existing-version'
+unless $first_version_without_epoch ne 
$entry_version_without_epoch
+or $entries[0]->Source ne $entry->Source;
+}
 
 my $first_upstream = $first_version;
 $first_upstream =~ s/-[^-]+$//;

You might want to use true version comparison functions instead of "ne" in the
last version check.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Raphael Hertzog]

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
> says: the overall version decreases.  You can see it when you use a
> 'backports like' without targetting backports.
> 
> If you bump an epoch you should never see it.

That's not true, the code drops the epoch:
tag 'latest-debian-changelog-entry-without-new-version'
  unless versions_gt(
$first_version =~ s/^([^:]+)://r,
$second_version =~ s/^([^:]+)://r
  )
  or $entries[0]->Changes =~ /backport/i
  or $entries[0]->Source ne $entries[1]->Source;

This is a recent change (2.5.75):
  * checks/changelog-file.desc:
+ [CL] When checking latest-debian-changelog-entry-without-new-version
  ignore any change of epoch.  (Closes: #889991)

IMO reusing this tag to implement what was requested in #889991 was
a bad decision. The two problems are not really related. The fact that
the version (with epoch included!) is not increasing is a real problem
except when we backport.

The fact that we are reusing a version (with epoch stripped) that already
existed in the past is another problem. I'm going to reopen #889991.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Raphael Hertzog]

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 at least I did not
> see this warning when uploading "that" Django version.

I think this warning was not in place yet when you made that mistake.

Still I think that this warning was not correctly implemented. It should
really ensure that the epoch-less version does not match any former
epoch-less version (of entries matching the same source package name).

Ensuring that the version is greater is not sufficient as we can have had
multiple epoch jumps in the past and we can potentially have again the
same version even though the last two changelog entries have increasing
version numbers.

So yes I think that this "error-level" tag is still deserved and that we
should better implement latest-debian-changelog-entry-without-new-version. 

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Raphael Hertzog]

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~beta1+really1.9.7 in this case):

python-django (1:1.9.7-2) unstable; urgency=medium

  * Re-upload 1.9.7 to unstable with epoch.

 -- Chris Lamb   Sun, 26 Jun 2016 09:58:19 +0200

python-django (1.10~beta1-1) unstable; urgency=medium

  * New upstream beta release.

 -- Chris Lamb   Sat, 25 Jun 2016 19:17:49 +0200



Bad:

python-django (2:2.0-1) experimental; urgency=medium

  * New upstream stable release.
https://docs.djangoproject.com/en/2.0/releases/2.0/

 -- Chris Lamb   Sat, 02 Dec 2017 18:36:33 +

python-django (1:2.0~rc1-1) experimental; urgency=medium

  * New upstream release candidate.


  * Drop trailing whitespace in debian/changelog.

 -- Chris Lamb   Thu, 16 Nov 2017 09:55:14 +0900


;-)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Raphael Hertzog]

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 nice if Lintian was warning about this, and nicely suggesting to
> build- depend on version 11~, to allow backports.

I think it would be better to backport 11.1.4 (as 11.1.4~bpo9+1) and
forget about this. Otherwise we will be asking developers to update this
field for months if not years to come when in fact the problem will go
away in a few days/weeks.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#762753: moreinfo

[Raphael Hertzog]

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 fixed.

I use this field in debian-handbook to help search engines understand
taht the copy hosted on debian.org is the same as the one
on debian-handbook.info (the canonical location) and there's
no reason to forbid this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

[Raphael Hertzog]

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 package is not..?)

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 case.

In general, when you have a dedicated user it's because you want to run a
daemon under that user to restrict its accesses. The interfaces of most
daemons do not allow end users to create hardlinks/symlinks in the data
directories of the daemon... hence this chown -R vulnerability is only
exploitable after having found another vulnerability in the daemon to
create the hardlinks and/or symlinks.

That makes it much less important as a vulnerability.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

[Raphael Hertzog]

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 on this topic that I
missed?

In any case, maybe we could encourage the use of "-h / --no-dereference"
on such calls?

Of if there is no consensus, but multiple suggestions have been made,
then it's probably best to list all the possible solutions that have been
pointed out (maybe usage of systemd's dynamic user feature).

> > Please try to be a bit more restrictive in what new tags you are
> > accepting.
> 
> You seem to be implying this is a pattern. If so, please could you
> provide some other examples so I could understand better?

Well, it seems to me that you could put a bit more thought up-front
when a new tag is added... it seems to me that tags are added and
that sub-sequesent versions often provide a longer explanation
with more context and/or with new ways to not trigger the tag (i.e. that 
do not require adding an override).

That was the case with new-package-should-not-package-python2-module
and dependency-on-python-version-marked-for-end-of-life.

In any case, it's not a big deal, I largely prefer having lintian very
actively maintained with a few mistakes quickly fixed than having no new
checks... but you are still the gatekeeper, Debian developers have lots
of (sometimes weird) desires/wishlists for a tool like lintian and you
should help them better define their checks before merging them.

You could have a checklist:

- Does the long description tell the maintainer how to fix the problem?
  Can it include a reference te some relevant documentation?
- Does the long description gives the rationale why this is a problem
  in the first place?
- Can we have a mechanism to not trigger the tag when the maintainer
  knows that it's a false positive (without adding an explicit override
  tag)?
- Did someone do an estimation of the false positive ratio? Is it
  reasonable?

> This was a judgement call based on the severity of the problem (it,
> after all, had a CVE). Personally I'd rather have a check for such
> an issue that had an incomplete long description than not have the
> check at all. Clearly, this would not apply to a trivial or even a
> normal issue..

Sorry, what CVE are you referring to?

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. If you know this, you might want to acknowledge it in the long
description explaining that you accept the false positives because
of the security impact of any case where nobody took the time to
analyze the security implications (but then again you should help the
maintainer to do his own assessment, what is safe and what is not safe?).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

[Raphael Hertzog]

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 have
> fs.protected_hardlinks=1.

Only if someone has write access to the directories where chown/chmod
are called... which is generally not the cases for directories that
are modified by maintainer scripts (/var/log/foo, /var/lib/foo).

I'm sorry but this tag is going to generate lots of noise and
unhappiness among maintainers because:
1/ you do not suggest any alternative (how do I fix change
   permissions/ownership securely?)
2/ you do not tell them how to ensure that their case is safe or not and
   whether they should just override the tag or not.
3/ I expect the false-positive ratio to be very high

Chris, as a lintian maintainer, I would expect you to ensure that
any tag has actionable data and looking at the commit, clearly this
one doesn't have any. There's no indication on how to go forward
to fix this tag.

Please try to be a bit more restrictive in what new tags you are
accepting.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#871575: lintian: maintainer-address-causes-mail-loops-or-bounces should be fixed to allow @packages.debian.org emails

[Raphael Hertzog]

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
>
> https://anonscm.debian.org/git/lintian/lintian.git/tree/lib/Lintian/Check.pm#n196
> 
> Shall we keep the qa part or drop the whole thing?

Well, @packages.qa.debian.org just forwards to @tracker.debian.org. Having
@packages.qa.d.o or @tracker.d.o in Maintainer will not cause mail
loops or bounces. It might result in duplicate mails though for tracker
subscribers.

But honestly I would rather get rid of the check entirely. As I said in
my recent debian-devel mail, I would like one day to be able to use
team+...@tracker.debian.org as Maintainer field.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#865531: lintian: testsuite-autopkgtest-missing checks the wrong thing

[Raphael Hertzog]

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 "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 finds debian/tests/control.
> 
> Please provide a test case for this.

I did not verify this, I just assumed this based on the long description
of the tag.

> > So instead you should check that field in the .dsc or directly
> > debian/tests/control in the unpacked source package.
> 
> The code currently checks for the field in the .dsc file.

So then it's only a documentation issue and not a real problem.

> > BTW the long description must also be updated as it instructs the user
> > to add this field in debian/control when it's not needed.
> 
> That is true though.

Feel free to correct only this and close this bug. And word the long
description in a way that makes it clear that the test checks the field
in the .dsc file.

Thank you!
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#865531: lintian: testsuite-autopkgtest-missing checks the wrong thing

[Raphael Hertzog]

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 finds debian/tests/control.

BTW the long description must also be updated as it instructs the user
to add this field in debian/control when it's not needed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#818962: [lintian] Proposed patches for php checks

[Raphael Hertzog]

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 them accordingly.

I don't think this ever happened. And lintian is still emitting those
wrong errors.

Can you take some time to ensure this is fixed in lintian?

Thank you!
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#799861: false positive in "source-is-missing" when dealing with .js

[Raphael Hertzog]

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: source-is-missing 
django/contrib/admin/static/admin/js/calendar.js
E: python-django source: source-is-missing 
django/contrib/gis/templates/gis/admin/openlayers.js
E: python-django source: source-is-missing 
django/contrib/gis/templates/gis/google/google-map.js
E: python-django source: source-is-missing 
django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js
s

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#799861: One more case of source-is-missing false positive with Django 1.8.5

[Raphael Hertzog]

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.js

But the file is its own source code. It has comments, it's not minified at all.
Yes some of the lines are very long. That's all...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#758425: lintian: add a check for outdated version constraints

[Raphael Hertzog]

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 triggering of autopkgtests for those packages.
 If the dependency is not essential then the version constraint can be
 removed. The check whether a version is outdated can easily be done by
 having a data file with package name and its version in oldstable. If
 the version constraint points to a version prior to oldstable then the
 constraint can be dropped or the dependency dropped if it is essential.

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 warnings on library dependencies generated
by dpkg-shlibdeps.

Also there are quite a few maintainers that believe that correct
information don't do much harm and I have a hard time justifying this
change just for the purpose of bootstrapping a new port. The point
9.1 in
http://lists.debian.org/20140829095214.gv19...@stoneboat.aleph1.co.uk only
mentions compiler dependencies so maybe this can be restricted
to a smaller subset (or maybe be an I by default but a W on
the packages where it matters?).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140829191606.ga11...@x230-buxy.home.ouaza.com

Bug#758425: lintian: add a check for outdated version constraints

[Raphael Hertzog]

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
  warnings on library dependencies generated by dpkg-shlibdeps.
 
 How can it happen that library dependencies generated by dpkg-shlibdeps create
 a dependency on a package version older than in old stable?

When a library has a symbols file that has evolved over more than 2
releases (like libc6)... see /var/lib/dpkg/info/libc6:amd64.symbols it
references versions as old as 2.2.5 when oldstable currently has 2.11.

 You mean the sentence Versioned dependencies are problematic for 
 bootstrapping
 because versioned compiler dependencies have to be translated and the versions
 of binary packages is not known a priori during a bootstrap from zero.

Yes.

 compiling. The other is all other versions of binary packages because they
 have to be associated to source packages but it cannot be known from which
 version of a source package they build.

This is a wrong problem given that in the majority of the case a given binary
package will only be produced by a single source package. The binary
package might be referenced multiple times in some rare cases of binary packages
moving between source packages but I hardly doubt that this is a serious
problem for bootstrapping a new architecture. It doesn't happen that
often.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140829201743.gc19...@x230-buxy.home.ouaza.com

Bug#758425: lintian: add a check for outdated version constraints

[Raphael Hertzog]

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). The warning could then point out that the developer
can either drop the versioned dependency or format the build dependencies 
 so
that they get properly translated during cross compilation.

 Would this course of action be acceptible?

I'd say yes but I don't know how you define the set of packages. How can
lintian know if a package is a compiler?

 This also means that fixing this bug has to wait until cross compiler
 translation arrives in main.

Not sure I understand what this means. Perhaps it refers to some
meta-information that will help to identify the compilers?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140829214242.ge19...@x230-buxy.home.ouaza.com

Re: Correct way of providing uncompressed data.tar

[Raphael Hertzog]

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 with him,
data.tar ought to be correctly supported.

Guillem also added preliminary support to normalize the compression
method in dpkg at build time, see commit
625a24bbc8280362c2ab0e3f2f83aacbf25283e0 and the new fixup_gzip_params().

http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=625a24bbc8280362c2ab0e3f2f83aacbf25283e0

It lacks a call to compressor_fixup_params() in dpkg-deb/build.c to
make this effective but the intention is clear. -Zgzip -z0 shall
at some point result in a data.tar member.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131205132750.ga...@x230-buxy.home.ouaza.com

Bug#612610: [lintian] may be time now

[Raphael Hertzog]

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
maintain long-lived patches and use the .diff.gz to collate upstream
patches that they apply with git cherry-pick. The advantage being that
they don't have to maintain those cherry-picked patches explicitly, they
go away automatically when they package the next upstream release.

Their workflow is entirely git based, they have the upstream history
in their repository.

Apart from that the other objections are not really actionnable, they
are more in the domain of personal preference and/or dislike of quilt
in general.

You will always have people who dislike the format, and even
some in the technical committe (thinking of Ian Jackson here).

  Would it be possible to not display the tag in case the package fits in
  one of the cases where we know that 3.0 (quilt) is considered unsuitable
  by many?
 
 If the case could be computably detected yes. But we need to know the case
 where it is unsuitable.

FWIW, there's already a missing-debian-source-format info tag which plays
somewhat the role of the reminder that they need to opt-in in 3.0
(quilt).

You can get in touch with people who opted explicitly to put 1.0 in
debian/source/format to know their reasons...

http://lintian.debian.org/tags/missing-debian-source-format.html

Have a look at the long description, the message is rather explicit. :-)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130901183432.ga28...@x230-buxy.home.ouaza.com

Bug#679132: lintian: false positive on package-uses-local-diversion when --local and --package are not given

[Raphael Hertzog]

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 wheezy+1 or wheezy+2 wishlist then.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120710141849.ga28...@rivendell.home.ouaza.com

Bug#632556: checks/deb-format: allow data.tar.xz

[Raphael Hertzog]

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.debian.org.

It would be nice if you could thus prepare such a fixed lintian maybe
sooner than usual.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110704140809.ga4...@rivendell.home.ouaza.com

The trigger in your Debian packages

[Raphael Hertzog]

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 believe that the vast majority of triggers do not provide a
functionality that is so important as to require that the triggering
package be put in that status. Thus I'm considering to change this
and to introduce new trigger directives that would keep the old
behaviour.

I need your help to identify the set of package which would have to
use the new directives, if I decide to introduce this incompatible change.
My recent mail to -devel[1] only suggested ghc6 so I'm asking all the
maintainers directly this time.

[1] http://lists.debian.org/debian-devel/2011/05/msg01180.html

Please reply for the packages that you maintain to the question that
concerns you:

1/ If your package uses the interest directive in the triggers files,
is it important that the triggering packages that activate your triggers
be considered as not configured (and thus not satisfying dependencies)
until the trigger has been processed?

2/ If your package uses the activate directive, is it important that
your package be considered as not configured (and thus not satisfying
dependencies) until the trigger has been processed?


I have put no as answer for the install-info and man-db packages.
For the others, I would like you to answer explicitly yes or no with a
short rationale. If you don't know what to answer, please reply describing
what your trigger does, and we'll try to find out through discussion.

To make it easier to find the packages that concerns you, I have put a
dd-list below.

Thanks for your help!


Ying-Chun Liu (PaulLiu) paul...@debian.org
   clutter-imcontext
   libomxil-bellagio

Russ Allbery r...@debian.org
   lintian (U)
   nvidia-graphics-drivers (U)

Bill Allombert ballo...@debian.org
   gap
   menu

Henrik Andreasson deb...@han.pp.se
   pike7.8 (U)

Osamu Aoki os...@debian.org
   xpdf (U)

maximilian attems m...@debian.org
   initramfs-tools (U)

Sebastien Bacher seb...@debian.org
   gnome-menus

Adam D. Barratt a...@adam-barratt.org.uk
   lintian (U)

Mirco Bauer mee...@debian.org
   mono (U)

Daniel Baumann dan...@debian.org
   live-boot (U)
   open-vm-tools (U)
   plymouth (U)

Daniel Baumann dan...@lists.debian-maintainers.org
   plymouth

Daniel Baumann daniel.baum...@progress-technologies.net
   ntfs-3g

Andreas Beckmann deb...@abeckmann.de
   nvidia-graphics-drivers (U)

Vincent Bernat ber...@debian.org
   nevow

Michael Biebl bi...@debian.org
   hal (U)

Laurent Bigonville bi...@debian.org
   gdk-pixbuf (U)

Fathi Boudra f...@debian.org
   icecc (U)

Nicholas Breen nbr...@ofb.net
   grace

Joachim Breitner nome...@debian.org
   ghc6 (U)

Marc 'HE' Brockschmidt h...@debian.org
   gnome-menus (U)
   lintian (U)

Rob Browning r...@defaultvalue.org
   guile-1.8

Ross Burton r...@debian.org
   desktop-file-utils
   hicolor-icon-theme

Vagrant Cascadian vagr...@debian.org
   ltsp (U)

Jesus Climent jesus.clim...@hispalinux.es
   spamassassin (U)

C.M. Connelly c...@debian.org
   tex-common (U)

Debian Forensics forensics-de...@lists.alioth.debian.org
   rkhunter
   unhide
   unhide.rb

Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org
   gconf (U)
   gdk-pixbuf
   glib2.0 (U)
   gnome-icon-theme (U)
   gnome-menus (U)
   hicolor-icon-theme (U)

Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org
   icecc

Debian kernel team debian-ker...@lists.debian.org
   initramfs-tools

Debian LibreOffice Maintainers debian-openoff...@lists.debian.org
   libreoffice

Debian Live Project debian-l...@lists.debian.org
   live-boot

Debian Mono Group pkg-mono-gr...@lists.alioth.debian.org
   mono

Debian multimedia packages maintainers 
pkg-multimedia-maintain...@lists.alioth.debian.org
   vlc

Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
   nvidia-graphics-drivers

Debian Octave Group pkg-octave-de...@lists.alioth.debian.org
   octave3.2

Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org
   php5

Debian Python Modules Team python-modules-t...@lists.alioth.debian.org
   nevow (U)

Debian TeX maintainers debian-tex-ma...@lists.debian.org
   tex-common
   texinfo

Jan Dittberner ja...@debian.org
   cracklib2

Agustin Martin Domingo agmar...@debian.org
   dictionaries-common

Benjamin Drung bdr...@debian.org
   vlc (U)

Sebastian Dröge sl...@debian.org
   gconf (U)
   gdk-pixbuf (U)
   glib2.0 (U)
   gnome-icon-theme (U)
   hal (U)
   shared-mime-info

Free Ekanayaka fr...@debian.org
   twisted (U)
   twisted-conch (U)
   twisted-runner (U)

Rene Engelhard r...@debian.org
   dictionaries-common (U)
   libreoffice (U)

Sean Finney sean...@debian.org
   php5 (U)

Raphael Geissert geiss...@debian.org
   lintian (U)
   php5 (U)
   readahead-fedora

Michael Gilbert 

Bug#626775: lintian: should accept any all in Architecture in .dsc and not trigger magic-arch-in-arch-list

[Raphael Hertzog]

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 rest of the project is expected to get
 in line without any other discussion.  I think it creates some unnecessary
 tension that the above order would have defused.

Well, it was not meant to override the normal process, but I expected it
would not create problems so I did it all at once. But you're entirely
entitled to mark the lintian bug as blocked by the policy one (that's why
I mentioned that I was filing a policy one in parallel).

 (I suspect that this ordering may be due to slowness in action on Policy
 bugs, which I know has been a source of frustration for some of your
 work.  If you have a moment to come up with a list of Policy bugs that you
 find particularly vexing and would like to get resolved, particularly if
 any of them are relatively straightforward, could you send me that list?
 I have more time right now to work on Policy than I have in quite a while,
 and I promise to take a look.  dpkg-buildflags is already high on my list,
 for example.)

Oh no, I'm not frustrated at all. On the contrary, I know that a bug with
a good rationale and a good patch can be quickly seconded and merged, and
thus it was more efficient to do everything at once.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110515193648.ga32...@rivendell.home.ouaza.com

Built-Using and lintian

[Raphael Hertzog]

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)
  ▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110328060827.gd20...@rivendell.home.ouaza.com

Bug#618001: lintian: maintainer-script-lacks-debhelper-token is sometimes not reported when it should

[Raphael Hertzog]

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://snapshot.debian.org/archive/debian/20110313T151803Z/pool/main/liba/libapache2-mod-qos/libapache2-mod-qos_9.54-1.dsc

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110327183159.gb14...@rivendell.home.ouaza.com

Bug#616493: lintian: Should know about the Multi-Arch field

[Raphael Hertzog]

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 but
I don't see udeb making use of multiarch any time soon)

   I also included a sanity check of the values of the field (one of the
 four listed in your email in all lowercase).  I have not added any

Great.

 sanity (cross-)check for multi-arch vs. content/architecture, so Lintian
 will (at least for now) happily accept Architecture: all with
 Multi-Arch: foreign (or whatever).  I am keeping this bug open to track
 the status of such additional checks.

The only forbidden combination is Architecture: all / Multi-Arch: same.
The rest is allowed. But dpkg already enforces this at build time[1] so it's
ok if there's no check in lintian.

Cheers,

[1] Not yet in sid but in the multi-arch branch that we're working on.
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110311192521.ga28...@rivendell.home.ouaza.com

Package-Type not included in udebs

[Raphael Hertzog]

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 throat which they seem to consider
  completely unacceptable (even if probably that outcome is unlikely
  given the stance of some of the ctte members, but still), or my
  throat.
 
 I think if you're happy with the field not going into the udebs (for
 at least the time being), there's not much of a disagreement here.
 [FWICT, the primary concern of the d-i team was space, and your
 proposed solutions seem to be aware of them.]

dpkg-dev 1.15.7 stopped outputting the field by default. So this bug can
be closed (doing so now). Not really a decision of the committee but I
just wanted a decision taken.

The lintian tag package-type-in-debian-control can be dropped and replaced
by a xc-package-type-in-debian-control that suggests to do the opposite
and use the official name.

To the d-i team: you can start converting your packages to use the official name
now.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100514130749.ga22...@rivendell

Bug#575059: Should Package-Type be included in udebs or not?

[Raphael Hertzog]

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 be better to check what happens
 in the resulting binaries, but I wanted to be aware of such issues
 *before* even building those packages; that's why I implemented it so
 that it checks the source control file. Hopefully, you'll get the idea
 and either move it entirely, or only “duplicate” it for the binary
 packages.
 
  1. http://lists.debian.org/debian-boot/2010/02/msg00524.html
[...]
 +Tag: package-type-in-debian-control
 +Severity: important
 +Certainty: certain
 +Info: There is a Package-Type field in the ttdebian/control/tt
 + file.  This field is only relevant to the build process and should
 + not be embedded in the resulting binary package.  As a consequence,
 + XC-Package-Type should be used instead.

Hi,

I'm a bit annoyed with lintian officializing usage of the non-official
field name.

It's counterproductive IMO. The issue should be resolved at the dpkg
level. Unfortunately the underlying issue has never been resolved
between Guillem and the d-i team, you can find the discussion
here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452273

Hence I'm seeking advice from the technical committee. In the mean time, I
think this warning should not be kept in lintian.

Should dpkg continue to copy the Package-Type field in the binary (.udeb)
or not ?

I believe advantages and disadvantages have been listed in the discussion
in the bug report above. Some further changes in other tools might be
needed to accomodate the needs of the d-i team in that case.

Cheers, 
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100323080013.ga8...@rivendell

Another lintian release for squeeze?

[Raphael Hertzog]

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 entreprises
http://www.freexian.com


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100319080921.ga31...@rivendell

Bug#573088: Allow and recommend sha256sums control file

[Raphael Hertzog]

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 the dpkg Roadmap,
there's already stuff concerning all this:

http://wiki.debian.org/Teams/Dpkg/RoadMap
Merge back debsums:
* Generate checksums at build and install time. 
http://bugs.debian.org/155676
* Store metadata from .deb at install time.
* Add a new dpkg-foo to verify, restore, etc metadata. 

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100319080420.ga31...@rivendell

Bug#528001: Bug#566820: lintian: Warn about missing debian/source/format, advise switch to new 3.0 source formats

[Raphael Hertzog]

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 like a good idea.  I'm more reluctant to have Lintian recommend
 switching to 3.0.  Based on the debian-devel discussion, I'm not sure the
 idea has aged enough to make people comfortable with it.  But if they
 don't have any declared source format at present, I'm certainly fine with
 Lintian suggesting they consider it.
 
 I think having a new check script that checks files in debian/source would
 be a good idea.  I'm not sure what to call it.  source-control, maybe?
 That could be confused with something that tests VCS usage, though.

Ok, I went for debian-source-dir. In the process, I found other oddities
that I fixed so you really have 5 patches to apply.

I kept the pedantic tag using-old-source-format but you can comment it
if you prefer.

  It might also be a good idea to have unknown-source-format when
  debian/source/format contains something else than 1.0, 2.0, 3.0
  (quilt), 3.0 (native), 3.0 (git), 3.0 (bzr). This one should
  result in an error.
 
 Yes, please.

Also done.

 If you feel energetic, there's also #528001, and it would be nice to warn
 about unrecognized files in debian/source to catch people who have
 misspelled the control file name.

I added the check for unrecognized files in debian/source but the rest
I won't do (at least not now).

The list of debian/source/ files recognized is now longer... here's the
description I used:

N: 
N:The source package contains a file in debian/source/ that lintian
N:doesn't know about. Currently the following files are recognized:
N:
N: * format
N: * include-binaries
N: * lintian-overrides
N: * options
N: * patch-header
N:
N:This tag is emitted in case you mistyped the name of one of the above
N:files. If that's not the case and if the file can be legitimately be
N:expected in source packages, please file a bug against lintian asking
N:for the file to be recognized.
N:
N:Severity: important, Certainty: possible

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
From a2f4384f5d4cbcf536b6a896c9c9a6189f3eb5d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= hert...@debian.org
Date: Wed, 3 Mar 2010 20:04:34 +0100
Subject: [PATCH 1/5] Simplify collection/debfiles to copy the debian directory entirely
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Despite the comment in the source code, the collector has always collected
the full debian directory and several scripts now depend on this behaviour:
* patch-systems use files below debian/patches/
* po-debconf use files below debian/po/
* debian-source-dir will use files below debian/source/

The line “next if -d $file” should have been “next if -d
unpacked/debian/$file” for the script to have its intended behaviour.
---
 collection/debfiles |   13 ++---
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/collection/debfiles b/collection/debfiles
index a7664d9..6493741 100755
--- a/collection/debfiles
+++ b/collection/debfiles
@@ -35,14 +35,5 @@ if (-e debfiles) {
 	or fail(cannot rm old debfiles directory);
 }
 
-mkdir('debfiles', 0777) or fail(cannot mkdir debfiles: $!);
-
-# Don't copy the whole directory, just all files in it.
-opendir(DEBIAN, 'unpacked/debian')
-	or fail(cannot open unpacked/debian/ directory: $!);
-while (my $file=readdir(DEBIAN)) {
-	next if -d $file;
-	copy_dir(unpacked/debian/$file, 'debfiles/')
-		or fail(cannot copy unpacked/debian/$file: $!);
-}
-closedir(DEBIAN);
+# Copy the whole debian directory
+copy_dir(unpacked/debian, debfiles);
-- 
1.7.0

From 32662c68108c143e4c6644afb7a5dac9bfe9f147 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= hert...@debian.org
Date: Wed, 3 Mar 2010 20:26:23 +0100
Subject: [PATCH 2/5] New check script debian-source-dir

This script is meant to contain all checks made on debian/source/* files.
This initial implementation only covers debian/source/format.
---
 checks/debian-source-dir  |   61 +
 checks/debian-source-dir.desc |   43 +
 2 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 checks/debian-source-dir
 create mode 100644 checks/debian-source-dir.desc

diff --git a/checks/debian-source-dir b/checks/debian-source-dir
new file mode 100644
index 000..8c4281d
--- /dev/null
+++ b/checks/debian-source-dir
@@ -0,0 +1,61 @@
+# debian/source directory content -- lintian check script -*- perl -*-
+
+# Copyright (C) 2010 by Raphaël Hertzog
+#
+# This program is free software; you 

Bug#566820: lintian: Warn about missing debian/source/format, advise switch to new 3.0 source formats

[Raphael Hertzog]

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 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?

 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 decide to
 really deprecate the old format.
 
 It might also be a good idea to have unknown-source-format when
 debian/source/format contains something else than 1.0, 2.0, 3.0
 (quilt), 3.0 (native), 3.0 (git), 3.0 (bzr). This one should result
 in an error.

Any opinion on whether you are interested by those too?

Cheers,
-- 
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100214185043.ga4...@rivendell

Bug#566820: lintian: Warn about missing debian/source/format, advise switch to new 3.0 source formats

[Raphael Hertzog]

On Mon, 25 Jan 2010, Goswin von Brederlow wrote:
 Raphaël Hertzog hert...@debian.org 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 decide to
  really deprecate the old format.
 
 I think that if someone went through the trouble of specifically putting
 1.0 in that file then there is a reason for it.

It could be No time to investigate switching to the new source format and
want to get rid of the warning.

 Such a person will have been anoyed with the lintian warning about
 missing debian/source/format and will have considered and rejected
 changing to 3.0 (quilt). Anoying him yet again will not help.

That's why I suggested it as a pedantic tag only at this point. But it's
not a big deal if it's not implemented at all. And the at this point the
valid reason could be documented in the overrides file next to this tag.

Cheers,
-- 
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#563685: lintian: check for files directly under /usr/share/mime/

[Raphael Hertzog]

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/share/applications/mimeinfo.cache which is
generated by update-desktop-database.

Cheers,
-- 
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#563685: lintian: check for files directly under /usr/share/mime/

[Raphael Hertzog]

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 this morning and was surprised that lintian
didn't catch it (like it catches /usr/share/info/dir).

Cheers,
-- 
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#555331: [col] improperly fails with Invalid or incomplete multibyte or wide character

[Raphael Hertzog]

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 /usr/share/man/man8/update-alternatives.8.gz 
/dev/null

I don't know if it's col's fault or if it's man-db that does not use col
properly but since col changed recently (and not man-db), I filed the bug
against col. Note that dropping LANG=C makes the warning go away so it's
most certainly locale related. Using any other locale seems to work, even
one that is not UTF-8.

Severity serious to avoid propagation to testing until we know more on the
nature of the problem. 

Cheers,

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150, 
'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bsdmainutils depends on:
ii  bsdutils  1:2.16.1-4 Basic utilities from 4.4BSD-Lite
ii  debianutils   3.2.1  Miscellaneous utilities specific t
ii  libc6 2.10.1-5   GNU C Library: Shared libraries
ii  libncurses5   5.7+20090803-2 shared libraries for terminal hand

bsdmainutils recommends no packages.

Versions of packages bsdmainutils suggests:
ii  cpp   4:4.3.4-1  The GNU C preprocessor (cpp)
pn  vacation  none (no description available)
ii  wamerican [wordlist]  6-3American English dictionary words 
ii  wfrench [wordlist]1.2.3-7French dictionary words for /usr/s
ii  whois 4.7.36 an intelligent whois client

-- no debconf information

-- 
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#545078: lintian: warn if symbol file contains tag but no build-dep on dpkg-dev (= 1.15.3~)

[Raphael Hertzog]

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 version of dpkg-dev can be
assumed by default), but if it's implemented, then the suggestion of
Modestas is fine.

 Another issue is a set of 
 supported tags (those which are acted upon, not just passed by) in the 
 particular dpkg-dev version. More tags will probably supported in the future 
 so it makes sense to implement a mini tag specification parser in lintian as 
 well.

This part could wait until we have libdpkg-perl so that lintian can reuse
the same parsing code than dpkg-gensymbols. We expect to stabilize the
perl API during the squeeze timeframe.

  Yes, unless a tag contains spaces, it is considered by old dpkg-dev as
  a part of symbol name. That is, in many cases, a package would simply
  FTBFS due to missing symbols...
 
 Yeah, 99% of packages will FTBFS due to #MISSING symbols when built with old 
 dpkg-gensymbols.

Indeed.

Cheers,
-- 
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534640: lintian should check that info files contains section and directory entry

[Raphael Hertzog]

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).

 You should however explain that info-files must have the required
 entries (INFO-DIR-SECTION, START-INFO-DIR-ENTRY / END-INFO-DIR-ENTRY)
 so that they can be registered in the info directory file automatically.
 Bugs have been filed about this, example:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528864

This is the most important check to add in lintian. The long description
should give some hints on how this can be fixed (like in the bugreport).

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534640: lintian should check that info files contains section and directory entry

[Raphael Hertzog]

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 about this check.

 I assume we should drop the requirement that the maintainer scripts call
 install-info and indeed warn if they do, noting that the calls can be
 removed.

Yes.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#525782: lintian: warn about #MISSING: ... in symbols files

[Raphael Hertzog]

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
information for the maintainer about the history of the library. I tend to
agree that they are useless in the symbols files inside the .deb (and
hence in /var/lib/dpkg/info/) but I would not force them to be stripped
inside the source package.

dpkg-gensymbols should strip them by default when generating an updated
symbols file (but still show them that way in the diff). Hence the clone.
(It should still have an option to keep them at least for the mole worker
that generates initial symbols files)

See also in #521551 how the format might evolve to contain more
meta-information about symbols and how using those comments was
suggested.

Note that those lines might also come from the symbol files that they
grabbed on qa.debian.org/cgi-bin/mole.cgi and not necessarily from their
own patching.

 These lines indicate some symbols have disappeared in newer versions of
 a library. The removed symbols might have been private symbols that have
 been hidden or they were public symbols that have been removed. Private
 symbols should be removed from the symbols file. Removed symbols means
 an ABI breakage and that version should not be packaged without
 reintroducing the symbols or bumping the SONAME/etc. Another alternative
 is that the symbols were introduced in a release candidate and removed
 in the final release, I guess the symbols should be removed. Normally
 when a symbol disappears the package will FTBFS with a message like the
 below. Some people seem to just patch their symbols file with the lines
 containing #MISSING instead of dealing with the issue properly and
 hopefully a lintian warning would discourage that practice.

The problem is that you can't know automatically if you are in a case
where the symbols can safely be removed (private one, devel version with
unstable API, etc) or if you should shout at the maintainer.

I'm not sure that lintian can diagnose anything here.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#506673: lintian: shlib-missing-in-control-file and symbols-declared-but-not-shlib wrong for libraries without versions

[Raphael Hertzog]

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 regexes used to try to
 extract versions from libfoo-version.so library names and they all
 disagree subtly.

Right. You should use the one used by dpkg-shlibdeps imo:
$soname =~ /^(.*)-(\d.*)\.so$/

 glibc ones) should get an override.  I think it's reasonable to ask libc6
 to carry an override for weird special cases like libpcprofile.so and
 libSegFault.so, since in general we don't want people packaging shared
 libraries that can't be represented in shlibs.

Makes sense.

 Currently, due to how Lintian works internally, this also excludes all
 such files from symbols checks as well.  If that's not correct, please let
 me know.

What symbols checks ? If they are in a public dir, they can be used with
symbols files and as such the corresponding symbols files should be
checked IMO.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#506673: lintian: shlib-missing-in-control-file and symbols-declared-but-not-shlib wrong for libraries without versions

[Raphael Hertzog]

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
representable in the shlib system… so it shouldn't be an error.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii  diffstat1.46-1   produces graph of changes introduc
ii  dpkg-dev1.15.0   Debian package development tools
ii  file4.26-1   Determines file type using magic
ii  gettext 0.17-4   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  libtimedate-perl1.1600-9 Time and date functions for Perl
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.2-3  on-line manual pager
ii  perl [libdigest-sha 5.10.0-17Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarchnone (no description available)
ii  libtext-template-perl 1.44-1.2   Text::Template perl module
ii  man-db2.5.2-3on-line manual pager

-- no debconf information



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#506697: lintian: invalid missing-build-dependency libmodule-build-perl

[Raphael Hertzog]

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 (= 5.10.0) | 
libmodule-build-perl (= 0.2800)
Build-Conflicts: libmodule-build-perl (= 0.3000)

But this combination leads to lintian improperly complaining:
E: zim source: missing-build-dependency libmodule-build-perl

Not sure if the Build-Conflicts is at fault or if the change advised by
the lintian warning is the sole responsible:
W: zim source: versioned-dependency-satisfied-by-perl build-depends: 
libmodule-build-perl (= 0.28)

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii  diffstat1.46-1   produces graph of changes introduc
ii  dpkg-dev1.15.0   Debian package development tools
ii  file4.26-1   Determines file type using magic
ii  gettext 0.17-4   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  libtimedate-perl1.1600-9 Time and date functions for Perl
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.2-3  on-line manual pager
ii  perl [libdigest-sha 5.10.0-17Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarchnone (no description available)
ii  libtext-template-perl 1.44-1.2   Text::Template perl module
ii  man-db2.5.2-3on-line manual pager

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#484549: Patch to handle quilt series like

[Raphael Hertzog]

tag 484549 + patch
thanks

Hi,

please find attached a patch ready to merge that adds the check that I
requested in this bug report as well as a few others all related to quilt.
This will help prepare the switch to the source format 3.0 (quilt)
by warning people that use quilt in ways that are incompatible with the
new source format.

lintian now checks the quilt patches in the same way that it checks
dpatch patches. I also added some fixes to the current code, it
was forgetting a comma when concatenating build-deps and build-deps-indep
which made it miss some build-dependencies, and it was 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]
Date: Thu, 26 Jun 2008 22:03:37 +0200
Subject: [PATCH] * checks/patch-systems: add support of quilt

New tags:
- quilt-build-dep-but-no-series-file
- quilt-series-but-no-build-dep
- quilt-patch-with-non-standard-options
- quilt-series-references-non-existant-patch
- patch-modifying-debian-files
- more-than-one-patch-system
---
 checks/patch-systems  |   79 +++--
 checks/patch-systems.desc |   58 +
 2 files changed, 134 insertions(+), 3 deletions(-)

diff --git a/checks/patch-systems b/checks/patch-systems
index a5bfdbe..5ca3329 100644
--- a/checks/patch-systems
+++ b/checks/patch-systems
@@ -1,6 +1,7 @@
 # patch-systems -- lintian check script -*- perl -*-
 #
 # Copyright (C) 2007 Marc Brockschmidt
+# Copyright (C) 2008 Raphael Hertzog
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -46,10 +47,19 @@ sub run {
 }
 	if (open(IN, '', fields/build-depends-indep)) {
 		local $/ = undef;
+		$build_deps .= ,  if $build_deps;
 		chomp($build_deps .= IN);
 		close(IN);
 	}
 	$build_deps = Dep::parse($build_deps);
+	# Get source package format
+	my $format = ;
+	if (open(IN, '', fields/format)) {
+		local $/ = undef;
+		chomp($format .= IN);
+		close(IN);
+	}
+	my $quilt_format = ($format =~ /3\.\d+ \(quilt\)/) ? 1 : 0;
 
 	#- dpatch
 	if (Dep::implies($build_deps, Dep::parse(dpatch))) {
@@ -86,10 +96,13 @@ sub run {
 
 # Check each patch.
 foreach my $patch_file (@patches) {
-	if (! -r debfiles/patches/$patch_file  ! -r debfiles/patches/$patch_file.dpatch) {
+	$patch_file .= .dpatch if -e debfiles/patches/$patch_file.dpatch 
+		and not -e debfiles/patches/$patch_file;
+	if (! -r debfiles/patches/$patch_file) {
 		tag dpatch-index-references-non-existant-patch, $patch_file;
+		next;
 	}
-	if (open(PATCH_FILE, '', debfiles/patches/ . $patch_file)) {
+	if (open(PATCH_FILE, '', debfiles/patches/$patch_file)) {
 		my $has_comment = 0;
 		while (PATCH_FILE) {
 			#stop if something looking like a patch starts:
@@ -102,15 +115,61 @@ sub run {
 			tag dpatch-missing-description, $patch_file;
 		}
 	}
+	check_patch($patch_file);
+}
+			}
+		}
+	}
+
+	#- quilt
+	if (Dep::implies($build_deps, Dep::parse(quilt)) or $quilt_format) {
+		$uses_patch_system++;
+		#check for a debian/patches file:
+		if (! -r debfiles/patches/series) {
+			tag quilt-build-dep-but-no-series-file, $pkg unless $quilt_format;
+		} else {
+			if (open(IN, '', debfiles/patches/series)) {
+my @patches;
+my @badopts;
+while(IN) {
+	chomp; s/^\s+//; s/\s+$//; # Strip leading/trailing spaces
+	s/(^|\s+)#.*$//; # Strip comment
+	next unless $_;
+	if (/^(\S+)\s+(\S.*)$/) {
+		$_ = $1;
+		if ($2 ne '-p1') {
+			push @badopts, $_;
+		}
+	}
+	push @patches, $_;
+}
+close(IN);
+if (scalar(@badopts)) {
+	tag quilt-patch-with-non-standard-options, @badopts;
+}
+
+# Check each patch.
+foreach my $patch_file (@patches) {
+	if (! -r debfiles/patches/$patch_file) {
+		tag quilt-series-references-non-existant-patch, $patch_file;
+		next;
+	}
+	check_patch($patch_file);
 }
 			}
 		}
+	} else {
+		if (-r debfiles/patches/series) {
+			# 3.0 (quilt) sources don't need quilt as dpkg-source will do the work
+			tag quilt-series-but-no-build-dep unless $quilt_format;
+		}
 	}
 
+
 	#- general cruft checking:
 	if ($uses_patch_system) {
 		if ($uses_patch_system  1) {
-			#probably a bug too use more than one system, but we don't check anything but dpatch at the moment
+			tag more-than-one-patch-system;
 		}
 
 		open(STAT, '', diffstat) or fail(cannot open diffstat file: $!);
@@ -126,6 +185,20 @@ sub run {
 	}
 }
 
+# Checks on patches common to all build systems
+sub check_patch($) {
+	my $patch_file = shift;
+	open(DIFFSTAT, -|, diffstat -p0 -l debfiles/patches/$patch_file)
+	  or fail(can't fork diffstat);
+	while (DIFFSTAT

Bug#484549: lintian: Check that patches in debian/patches/ do not modify files in the debian directory

[Raphael Hertzog]

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 and not
really in a patch in debian/patches/.

  Furthermore those packages do not work with the 3.0 (quilt) source
  format as it needs to generate a diff between the current source directory
  and the upstream source + a copy of the debian directory + the patches
  from the quilt series. 
 
 So the quilt format cannot be used if upstream choses to include a
 debian directory?

Of course it can. It removes any pre-existing debian directory before
unpacking the .debian.tar.gz. Thus it avoids the need of repacking for
the upstream that provides a debian dir in their tarball.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#484549: lintian: Check that patches in debian/patches/ do not modify files in the debian directory

[Raphael Hertzog]

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 directory are provided by
Debian. 

Furthermore those packages do not work with the 3.0 (quilt) source
format as it needs to generate a diff between the current source directory
and the upstream source + a copy of the debian directory + the patches
from the quilt series. 

When we copy the debian directory, the patches are already applied (since
they are applied at extraction time) and when we try to reapply patches
it fails.

Thus it would be really nice if we could get such a check in the
not-too-distant future. I imagine that you can simply run
diffstat -p0 -l file on all debian/patches/* and analyze the
output. If it starts with m|^(\./)?debian/| or m|^(\./)?[^/]+/debian/|
then you complain. diffstat will silenty ignore files which are not
patches.

Cheers,

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-6 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.20  package building tools for Debian
ii  file4.24-2   Determines file type using magic
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.2-1  on-line manual pager
ii  perl [libdigest-sha 5.10.0-10Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#483384: lintian: False positive on native-package-with-dash-version with 3.0 (quilt) source packages

[Raphael Hertzog]

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-version

But the source package is definitely not native:
$ cat ../quilt_0.46-4.1.dsc 
Format: 3.0 (quilt)
Source: quilt
Binary: quilt
Architecture: all
Version: 0.46-4.1
Maintainer: Martin Quinson [EMAIL PROTECTED]
Uploaders: Martin Quinson [EMAIL PROTECTED], Simon Horman [EMAIL PROTECTED]
Standards-Version: 3.6.1.0
Build-Depends: cdbs (= 0.4.23-1.1), debhelper (= 4.1.0)
Build-Depends-Indep: gettext, hevea, lynx, diffstat
Checksums-Sha1: 
 9344c1289f262053beb0196645b41ea5d9cda597 403984 quilt_0.46.orig.tar.gz
 384fa4d069913b20fe50699dc77da9f8f644b741 38224 quilt_0.46-4.1.debian.tar.gz
Checksums-Sha256: 
 47bf030565bb462840db694acc183273455714028c74974c5b3a3bd4ad29ad89 403984 
quilt_0.46.orig.tar.gz
 e52b6fc53a588957e71d7245516fd591e3e5efd610f6589698546467da2d9f63 38224 
quilt_0.46-4.1.debian.tar.gz
Files: 
 4508546d1ed0257ef7c128b6121b7208 403984 quilt_0.46.orig.tar.gz
 713ef9174ad7269af4b88f143f193a9d 38224 quilt_0.46-4.1.debian.tar.gz


You probably check for the presence of a .diff.gz file. This check should be 
restricted
to the 1.0 format.

With newer source package format, you get 3.0 (native) for a native package
and 3.0 (quilt) can never be native. You can check for the presence of the
..debian.tar.* file though.

I'm not sure how you should handle 3.x (git) and 3.x (bzr). I'd tend to handle 
them
as native packages but some people are interested to use them even for 
packaging of
third-party software (which is a bad idea IMO).

Cheers,

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-6 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.20  package building tools for Debian
ii  file4.24-2   Determines file type using magic
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.2-1  on-line manual pager
ii  perl [libdigest-sha 5.10.0-10Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Generated files and patch systems

[Raphael Hertzog]

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 makes are reverted in the clean target.  This
 means that your diff doesn't get cluttered with automatically generated
 things and ensures that repeated builds of the package produce the same
 diff.gz.

Exactly, it's the reason why I filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482716 in the first
place.

Removing the files which are regenerated in the configure stage is a
simple way to make sure that that you don't end up with such clutter.

Several of the packages which contain such useless changes in the diff
end up causing problems once you try to convert them to source format 3.0
(quilt) because the changes can't be applied/unapplied at any point of
time if the files are regenerated by some intermediate step.

Some examples:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482749
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482733

So I'm in favor of keeping this lintian warning because if the maintainer
makes the effort to keep clean patches, it should also make the effort to
make sure that the package cleans up nicely and doesn't clutter the
.diff.gz.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#471853: lintian: False positive in udeb: maintainer-script-lacks-debhelper-token

[Raphael Hertzog]

Package: lintian
Version: 1.23.46
Severity: normal

I have a source package which produces a single udeb and lintian says me:
W: guest-installer source: maintainer-script-lacks-debhelper-token 
debian/postinst

However the single binary package is an udeb and thus this rule shouldn't
apply: 
$ 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
Depends: ${misc:Depends}, apt-setup-udeb, di-utils
XC-Package-Type: udeb
XB-Installer-Menu-Item: 76
Description: Install guest systems

The (X[CBS]*-)?Package-Type: udeb field indicates that we have an udeb.

Cheers,

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.17~srcv3package building tools for Debian
ii  file4.23-2   Determines file type using magic
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.1-3  on-line manual pager
ii  perl [libdigest-md5 5.8.8-12 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409099: lintian: debian/control::Depends check for missing commas

[Raphael Hertzog]

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 paren, a comma should follow
  * an exception: not enforced at the end of line.
 
 Hm, doesn't check/fields already do a syntax check here?  If not, it
 certainly should, but I thought it already did.
 
 Of course, if those substitutions expand to nothing, it will miss that
 because the syntax check is done on the binary package.

dpkg-gencontrol will also error out if the resulting field is not correct
however there are no check prior to substvars expansion.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#468927: lintian: Should not rely on dpkg-source's output ...

[Raphael Hertzog]

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 the following:
internal error: dpkg-source didn't report unpack directory
internal error: could not unpack package to desired level: No such file or 
directory

The bug is in /usr/share/lintian/unpack/unpack-srcpkg-l2:
| my $IN = FileHandle-new;
| pipeline_open($IN, sub {
| my $ret=exec 'dpkg-source', '-q', '-x', 'dsc';
| $ret;
| }) or fail(cannot run dpkg-source: $!);
| 
| while ($IN) {
| chop;
| $unpack_dir = $1
| if (/^dpkg-source: extracting [^\s]+ in (\S+)/);
| }
| close($IN) or fail(error occured during execution of dpkg-source in 
$base_dir: $!);
| $unpack_dir or fail(dpkg-source didn't report unpack directory);

I really suggest you to add a supplementary parameter to the dpkg-source
invocation to explicitely specify the directory name where you want to
unpack it.

dpkg-source -q -x dsc unpacked

Note however that dpkg-source will exit if 'unpacked' exists. Thus you should
probably remove it before calling dpkg-source (if it exists that is).

Hopefully you can fix that in the next upload so that once the new dpkg-source
hits unstable people already have a fixed lintian. :)

Cheers,
-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.17  package building tools for Debian
ii  file4.23-2   Determines file type using magic
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.1-2  on-line manual pager
ii  perl [libdigest-md5 5.8.8-12 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#468927: lintian: Should not rely on dpkg-source's output

[Raphael Hertzog]

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 de ce type
 at /usr/share/lintian/checks/cruft line 131

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#466979: lintian: Learn new fields Checksums-* in .dsc and .changes

[Raphael Hertzog]

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 of the Files: field)

On my machine I get:
I: dpkg source: unknown-field-in-dsc checksums-sha1
I: dpkg source: unknown-field-in-dsc checksums-sha256

Cheers,
-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.17  package building tools for Debian
ii  file4.23-2   Determines file type using magic
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.1-2  on-line manual pager
ii  perl [libdigest-md5 5.8.8-12 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#459787: lintian doesn't accept origin and bugs field in binary packages

[Raphael Hertzog]

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-standard-arch-in-source-relation kfreebsd-amd64 
  [build-depends: libselinux1-dev (= 1.28-4) [!hurd-i386 !kfreebsd-i386 
  !kfreebsd-amd64]]
 
  kfreebsd-i386, kfreebsd-amd64, armel are unofficial architectures which are
  mentioned in many cases.
 
 That's the definition of non-standard architecture.  Maybe the tag should
 go away completely, but assuming that one buys the reason for having the
 tag at all, it is correct in this case.

I'd expect that those kind of checks are made to catch typo in arch names
for example. But not valid arch names which have not yet been integrated.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Bug#459787: lintian doesn't accept origin and bugs field in binary packages

[Raphael Hertzog]

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 them in %known_binary_fields and %known_udeb_fields I 
think.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.16  package building tools for Debian
ii  file4.21-4   Determines file type using magic
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-1  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.0-4  on-line manual pager
ii  perl [libdigest-md5 5.8.8-12 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457067: Patch for symbols support

[Raphael Hertzog]

tags 457067 + patch
thanks

Hi,

Attached is a patch adding support for the checks that I requested. I'd
appreciate if it could be integrated quickly. Some review is welcome. It
worked quite well on the test package that I used:
http://ftp.debian.org/debian/pool/main/t/tokyocabinet/libtokyocabinet1_1.1.4-1_i386.deb

$ lintian libtokyocabinet1_1.1.4-1_i386.deb
E: libtokyocabinet1: symbols-file-contains-current-version-with-debian-revision 
on symbol [EMAIL PROTECTED] and 3 others
W: libtokyocabinet1: symbols-file-contains-debian-revision on symbol [EMAIL 
PROTECTED] and 321 others

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
diff -Nru /tmp/Yq0Lbe3ntH/lintian-1.23.41/checks/control-files /tmp/3p28KrBmDX/lintian-1.23.41/checks/control-files
--- /tmp/Yq0Lbe3ntH/lintian-1.23.41/checks/control-files	2007-11-21 00:12:21.0 +0100
+++ /tmp/3p28KrBmDX/lintian-1.23.41/checks/control-files	2007-12-27 19:21:22.0 +0100
@@ -107,8 +107,48 @@
 }
 close IN;
 
+if (-e control/symbols) {
+my $version = getfield(version);
+my $version_wo_rev = $version;
+$version_wo_rev =~ s/(.+)-(.+)/$1/;
+my ($full_version_count, $full_version_sym) = (0, undef);
+my ($debian_revision_count, $debian_revision_sym) = (0, undef);
+open(IN, , control/symbols);
+while (IN) {
+	next if not /^\s+(\S+)\s(\S+)(?:\s(\d+))?/;
+	my ($sym, $v, $dep_order) = ($1, $2, $3);
+	if (($v eq $version) and ($version =~ /-/)) {
+	$full_version_sym ||= $sym;
+	$full_version_count++;
+	}
+	if (($v =~ /-/) and (not $v =~ /~$/) and ($v ne $version_wo_rev)) {
+	$debian_revision_sym ||= $sym;
+	$debian_revision_count++;
+	}
+}
+close IN;
+if ($full_version_count) {
+	$full_version_count--;
+	tag symbols-file-contains-current-version-with-debian-revision,
+	on symbol $full_version_sym and $full_version_count others;
+}
+if ($debian_revision_count) {
+	$debian_revision_count--;
+	tag symbols-file-contains-debian-revision,
+	on symbol $debian_revision_sym and $debian_revision_count others;
+}
+}
+
 } # /run
 
+sub getfield {
+return undef if not open (FIELD, '', fields/ . shift);
+my $field = FIELD;
+close FIELD;
+$field =~ s/\n$//;
+return $field;
+}
+
 1;
 
 # vim: syntax=perl sw=4 ts=8
diff -Nru /tmp/Yq0Lbe3ntH/lintian-1.23.41/checks/control-files.desc /tmp/3p28KrBmDX/lintian-1.23.41/checks/control-files.desc
--- /tmp/Yq0Lbe3ntH/lintian-1.23.41/checks/control-files.desc	2007-12-07 05:39:02.0 +0100
+++ /tmp/3p28KrBmDX/lintian-1.23.41/checks/control-files.desc	2007-12-27 19:32:16.0 +0100
@@ -26,3 +26,28 @@
 Tag: control-file-has-bad-owner
 Type: error
 Info: All control files should be owned by root/root.
+
+Tag: symbols-file-contains-current-version-with-debian-revision
+Type: error
+Info: By default, dpkg-gensymbols uses the full version number for the
+ dependency associated to any new symbol that it detects. But this
+ shouldn't happen as the maintainer should have updated before-hand the
+ debian/lt;packagegt;.symbols file by adding the new symbols with the
+ corresponding upstream version. 
+ .
+ Debian revisions should be stripped from symbols files because not doing
+ it leads to dependencies unsatisfiable by backports (1.0-1~bpo lt;lt; 1.0-1
+ while 1.0-1~bpo gt;= 1.0). If the debian revision can't be stripped because
+ the symbol really appearead between two specific revisions, then you
+ should postfix the version with a single ~ (example: 1.0-3~ if the
+ symbol appeared in 1.0-3).
+
+Tag: symbols-file-contains-debian-revision
+Type: warning
+Info: Debian revisions should be stripped from symbols files because not doing 
+ it leads to dependencies unsatisfiable by backports (1.0-1~bpo lt;lt; 1.0-1
+ while 1.0-1~bpo gt;= 1.0). If the debian revision can't be stripped because
+ the symbol really appearead between two specific revisions, then you
+ should postfix the version with a single ~ (example: 1.0-3~ if the
+ symbol appeared in 1.0-3).
+
diff -Nru /tmp/Yq0Lbe3ntH/lintian-1.23.41/debian/changelog /tmp/3p28KrBmDX/lintian-1.23.41/debian/changelog
--- /tmp/Yq0Lbe3ntH/lintian-1.23.41/debian/changelog	2007-12-10 05:03:03.0 +0100
+++ /tmp/3p28KrBmDX/lintian-1.23.41/debian/changelog	2007-12-27 19:36:29.0 +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

Re: Coordinate time for the lintian URL updates

[Raphael Hertzog]

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 be used.
 
 I want to minimize the breakage in links from the PTS and developer pages,
 so I want to coordinate with you a good time to do this.  Could you let me
 know when would be a good time to do the switch, assuming that the archive
 run needs to start about a day and a half in advance of when the new URLs
 will be live?

For me you can go ahead right now if you want, I should be able to find
some time tomorrow (or on sunday) for the PTS if zack is not faster.

In any case, broken links are not the end of the world and it's doesn't
require an up-to-the minute synchronization ;-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457067: lintian: Check symbols files and warn about usage of Debian revisions

[Raphael Hertzog]

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 there's no generic way to detect if the
symbols files is up-to-date (the most reliable way is parsing the build
log and checking if dpkg-gensymbols generated a particular warning but I
don't think that lintian has access to the build log...).

However, I think I have some sort of work-around: the recommandation
for maintainers is to remove the Debian revision part of the versions
associated to symbols. For new symbols, dpkg-gensymbols will automatically
add the full version of the source package.

Thus if you scan the symbols files and if you find precisely a version
(with a Debian revision) that matches the current version of the binary
package, you should generate a warning and invite the maintainer to
update all the debian/*.symbols files in the source package to include the
new symbols with a version:
 * without the Debian revision when it's not needed, ie when the symbol
   has been introduced by the new upstream version and not
   by a change in the Debian packaging.
 * with a tilde after the Debian revision (-2~) when the symbol has been
   introduced by a packaging change.

This version mangling is important in the general case so that backports
satisfy the generated dependencies (X.Y-R~bpo doesn't satisfy = X.Y-R
while X.Y-R~bpo = X.Y-R~ = X.Y).

You can use the Dpkg::Shlibs::SymbolsFile module if you want but you can
also easily check the versions by taking the second column of all lines
starting by a single space. IOW, the check is not very difficult to
implement and I'd really appreciate if it could be implemented in the
not-too-distant future as it would help me monitor how maintainers are
handling symbols files. :)

Cheers,
-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.13  package building tools for Debian
ii  file4.21-3   Determines file type using magic
ii  gettext 0.17-2   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-1  parse Debian changelogs and output
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.0-4  on-line manual pager
ii  perl [libdigest-md5 5.8.8-12 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#446768: lintian: Bug in pred_implies in lib/Dep.pm

[Raphael Hertzog]

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
  inspiration for some parts. I think I discovered some errors in that
  code while writing Dpkg::Deps.
 
 Hm, ideally it would be cool if lintian could use that down the road.  I
 know I hurt my head when trying to expand that code to support OR and full
 version implication, and the fewer times that people have to write it, the
 better.

This will be possible. All Dpkg::* modules are currently installed in
/usr/share/perl5/ so they are globally available. However since we're
early in that process of modularization we don't want to make any
promise of API stability. And they sometimes lack good POD documentation.
It's up to you if you can live with a strong dpkg dependency in case of
incompatible changes.

BTW, I did my best to support all kinds of dependencies. But I'm sure a
review could be useful... :-)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#446768: lintian: Bug in pred_implies in lib/Dep.pm

[Raphael Hertzog]

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'll find it here for the moment:
http://lists.debian.org/debian-dpkg/2007/10/msg00136.html
(the relevant part is in the version_implies function)

The problem are in pred_implies(). It returns 0 in some cases where it
should return undef.

if ($$q[2] eq '=') {
if ($$p[2] eq '') {
return Dep::versions_gte($$p[3], $$q[3]) ? 0 : undef;
} elsif ($$p[2] eq '=') {
return Dep::versions_gt($$p[3], $$q[3]) ? 0 : undef;
} else {
return Dep::versions_lte($$p[3], $$q[3]);
}
}


Here in the case p=['pkg', '', '1.6'] and q=['pkg', '=','1.5'] you return 0
while you should return undef. The fix is to have this in the else clause:
return Dep::versions_lte($$p[3], $$q[3]) ? 1 : undef;

However it also means that you would return undef if in the same case 
$$p[2]='='
while you should return 0 because the implication is obviously impossible.
For this you need to add another elsif testing specifically this case. So the 
end
result is:
if ($$q[2] eq '=') {
if ($$p[2] eq '') {
return Dep::versions_gte($$p[3], $$q[3]) ? 0 : undef;
} elsif ($$p[2] eq '=') {
return Dep::versions_gt($$p[3], $$q[3]) ? 0 : undef;
} elsif ($$p[2] eq '=') {
return Dep::versions_lte($$p[3], $$q[3]) ? 1 : 0;
} else {
return Dep::versions_lte($$p[3], $$q[3]) ? 1 : undef;
}
}

You must make similar changes in the 3 other cases (all except the = one).

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils   2.18-1The GNU assembler, linker and bina
ii  diffstat   1.45-2produces graph of changes introduc
ii  dpkg-dev   1.14.8package building tools for Debian
ii  file   4.21-3Determines file type using magic
ii  gettext0.16.1-2  GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libparse-debianchangel 1.1.1-1   parse Debian changelogs and output
ii  man-db 2.5.0-3   on-line manual pager
ii  perl [libdigest-md5-pe 5.8.8-11  Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#375318: lintian: New python related checks

[Raphael Hertzog]

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 python-central build-dependency.
(CDBS use a variable DEB_PYTHON_SYSTEM=pysupport/pycentral to select
between them so check for that as well)

2/ We should encourage to switch to the new policy, so a warning if we're
not using it would be welcome. There's no single way to detect that but
the most common way is that packages are using dh_python and have thus a
debian/pycompat containing 2. If you detect dh_python and not
debian/pycompat then you should issue a warning about the need to move to
the new policy. You can refer them to this URL:
http://wiki.debian.org/DebianPython/NewPolicy

3/ If one has dh_python and debian/pycompat=2, then it needs to
build-depends on at least debhelper (= 5.0.37.2).

4/ arch: all .deb should usually no more have dependencies like python
( something) if they use the new policy. That could also be a useful
warning indicating that the packages have not been converted.

That's a good start IMO. We could add many more test for the python policy
itself (and not for its infrastructure), but it's a bit more difficult.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages lintian depends on:
ii  binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina
ii  diffstat 1.41-1  produces graph of changes introduc
ii  dpkg-dev 1.13.22 package building tools for Debian
ii  file 4.17-2  Determines file type using magic
ii  gettext  0.14.6-1GNU Internationalization utilities
ii  intltool-debian  0.34.2+20060512 Help i18n of RFC822 compliant conf
ii  libparse-debianchang 1.0-1   parse Debian changelogs and output
ii  man-db   2.4.3-3 The on-line manual pager
ii  perl [libdigest-md5- 5.8.8-6 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Uploads

[Raphael Hertzog]

(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
  need python-dev for the clean target.
 
 Yeah, fixed that already.

Good!

  I tend to think that you're doing too much checks here. Having too much
  in Build-Depends is not *that* bad. You'd better check only for the
  contrary ie missing Build-Depends because they are used in the clean
  rule... well IMO of course.
 
 This would be a good thing to send to lintian-maint rather than just to
 me.  I didn't add the check in the first place; I just tried to fix all of
 the false positives in a check that was already in lintian before I
 started working on it.  I agree with you that it's not completely clear
 it's worth it, although at this point there aren't many false positives
 left.

I have nothing to add, just wanted to share my initial comment with the
other maintainers as suggested by Russ.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#372748: Deprecating /usr/lib/site-python in python policy

[Raphael Hertzog]

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 tt/opt/tt, because it
   is reserved for add-on software.
  
 +Tag: file-in-usr-lib-site-python
 +Type: error
 +Info: The directory /usr/lib/site-python has been deprecated as a
 + location for installing Python packages. Packages should use
 + /usr/share/$package instead.

I suggest this:
Info: The directory /usr/lib/site-python has been deprecated as a
 location for installing Python modules. Please check the Python policy.
 Most likely the modules are private modules and should be
 packaged in a directory outside of Python's default search path.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Re: Bug#109642: debhelper: Simplify inclusion of lintian overrides

[Raphael Hertzog]

On Sat, 21 Jan 2006, Russ Allbery wrote:
  But IMHO, debian/package.lintian-overrides should automatically be
  installed in /usr/share/lintian/overrides/package by one of the dh_*
  script (maybe dh_lintian could be folded into a generic dh_ script?).
 
 Please make it just package.lintian; the directory listing of the debian
 directory is bad enough as is without adding more extra-wide filenames.

I was proposing this name in consistency with the filename needed by
lintian for source overrides which is source.lintian-overrides
according to the doc.

Howewer lintian could be changed to accept both the short and the long
version.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Bug#348978: Lintian shouldn't warn about hardlinks if they are all inside /usr/share/package or /usr/lib/package

[Raphael Hertzog]

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 this is a web-app, it's a legitimate
concern.

I believe that there's no risk that directories below /usr/lib/sql-ledger/
will be mounted on separate partitions, thus this can be done without
problems.

IMHO, the warning shouldn't be emitted if the hardlinked files are (both)
below /usr/lib/package or /usr/share/package.

For reference, here's the warning that I'm referring to.

W: sql-ledger: package-contains-hardlink 
usr/lib/sql-ledger/bin/mozilla/admin.pl - usr/lib/sql-ledger/bin/lynx/admin.pl
N:
N:   The package contains a hardlink in /etc or across different
N:   directories. This might not work at all if directories are on
N:   different filesystems (which can happen anytime as the system
N:   administrator sees fit), certain filesystems such as AFS don't even
N:   support cross-directory hardlinks at all.
N:
N:   For configuration files, certain editors might break hardlinks, and so
N:   does dpkg in certain cases.
N:
N:   A better solution might be using symlinks here.
N:

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-10-386
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages lintian depends on:
ii  binutils 2.16.1cvs20051214-1 The GNU assembler, linker and bina
ii  diffstat 1.41-1  produces graph of changes introduc
ii  dpkg-dev 1.13.11.1   package building tools for Debian
ii  file 4.15-2  Determines file type using magic
ii  gettext  0.14.5-2GNU Internationalization utilities
ii  intltool-debian  0.34.1+20050828 Help i18n of RFC822 compliant conf
ii  libparse-debianchang 1.0-1   parse Debian changelogs and output
ii  man-db   2.4.3-3 The on-line manual pager
ii  perl [libdigest-md5- 5.8.7-10Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]