Re: lintian and Debian derivatives
On Thu, Jul 7, 2011 at 12:10 AM, Paul Wise <firstname.lastname@example.org> wrote:
> On Thu, Jul 7, 2011 at 12:49 AM, Geoffrey Thomas wrote:
>> We are the only one? I'm proud :-) We set that up about a year ago because
>> why not, but in practice, we've more been using Lintian output from the
>> package build process (debuild/sbuild) than the page, and making sure there
>> are no regressions and no unexpected warnings on new packages.
> Cool :)
>> In terms of making Lintian useful for derivatives, I think the biggest
>> feature we'd like is having a way to suppress Lintian checks during the
>> build process for an entire origin of packages (defined somehow...).
> Probably this will be useful to you:
> The work on this is in progress, so I would suggest you check it out
> as soon as possible.
> If you have any suggestions on how it works, now is the time to make them.
I realize I'm a bit late getting in on this, but I do have a small
amount of feedback on vendor profiles having just finished (finally)
setting up an Ubuntu lintian harness (http://lintian.ubuntuwire.org)
We're triggering a handful of specific tags that don't apply in an
Ubuntu context, but only with certain...arguments? (I'm a little shaky
on the terminology)
One example of this is unknown-field-in-control. Because we use a tool
on our buildds to modify all binary packages (http://bit.ly/vjllQi),
our binary packages all include both a Maintainer and
Original-Maintainer field. Lintian already handles Original-Maintainer
for packages with an Ubuntu modification, but we're currently
generating unknown-field-in-control tags on the vast majority of
packages in our archive
If I could filter "unknown-field-in-debian-control
original-maintainer", that page would be almost empty.
Similarly, we've diverged from Debian in the list of Essential
packages - python-minimal is essential for us, so we're generating
I have a couple of small other nits and patches, but most of the
modifications I had to make were around templating