Re: lintian and Debian derivatives
On Tue, Nov 8, 2011 at 8:02 PM, Evan Broder <firstname.lastname@example.org> wrote:
> On Thu, Jul 7, 2011 at 12:10 AM, Paul Wise <email@example.com> 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
Ah, yes. I also meant to mention that, to date, we haven't found any
overrides we want to put in that require wildcards, just constant