Re: lintian and Debian derivatives

2011-11-08 Thread Evan Broder 
On Tue, Nov 8, 2011 at 8:02 PM, Evan Broder  wrote:
> On Thu, Jul 7, 2011 at 12:10 AM, Paul Wise  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:
>>
>> http://wiki.debian.org/Lintian/Spec/VendorCustomization
>>
>> 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
> (http://lintian.ubuntuwire.org/tags/unknown-field-in-control.html).
>
> 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
> new-essential-package.

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
string matches.

- Evan


-- 
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/CAFvUpeJqHFYZJjVuzsPnPpCOD9J3xiVc=qegc1xj7rd4gmk...@mail.gmail.com

Re: lintian and Debian derivatives

2011-11-08 Thread Evan Broder 
On Thu, Jul 7, 2011 at 12:10 AM, Paul Wise  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:
>
> http://wiki.debian.org/Lintian/Spec/VendorCustomization
>
> 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
(http://lintian.ubuntuwire.org/tags/unknown-field-in-control.html).

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
new-essential-package.

I have a couple of small other nits and patches, but most of the
modifications I had to make were around templating

- Evan


-- 
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/CAFvUpeLnZSqBc01OCQdiQqknHGNpLvtuJ+yT=KCdCJ5WKixf=g...@mail.gmail.com

Re: lintian and Debian derivatives

2011-07-08 Thread Jeremiah Foster 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 7, 2011, at 00:25, Paul Wise wrote:

> Hi all,

Hi Paul,

> As a member of the Debian derivatives front desk (CCed) and initiator of
> the derivatives census, which aims to make derivatives more visible to
> Debian, I figured I should update lintian folks on the state of lintian
> development and usage in Debian derivatives.

Thanks for your work on this front.

> http://wiki.debian.org/DerivativesFrontDesk
> http://wiki.debian.org/Derivatives/Census
> 
> A while ago it was mentioned that Maemo had some customisations to make
> lintian more useful for derivatives. I just realised that the recent
> vendor stuff might obsolete that, but it might be useful to talk to the
> maemo/maemian folks to see if that is the case or what is the status of
> their projects and any interesting checks we could add. Maemo still
> exists, version 6 (also known as MeeGo 1.2 Harmattan) will be released
> on the Nokia N9 phone later this year and a beta has shipped on the
> Nokia N950 developer devices. 

"Maemian" was a project I started. It was designed to incorporate internal 
Nokia changes to Lintian into what are now vendor checks (I believe.) While 
work has stopped, largely due to the internal changes at Nokia; their move to 
MeeGo, lack of contact with Nokia lintian maintainers, I would like to pick it 
up again. I had promised Niels T. that I would test his vendor profiles 
(haven't done it yet) and incorporating the relevant Nokia changes seems like a 
very good idea as you suggest Paul. 

I will take up contact with those folks who I still know inside Nokia and see 
if I can't find out more information. If that doesn't work, I think I have some 
Nokia code, patches to Lintian, that I may be able to incorporate as a vendor 
check. 

Regards,

Jeremiah
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQIcBAEBAgAGBQJOFxZjAAoJEPoEpn8G2KIrVssP/3xOzCM5SBJCS0ClE8AebEyU
zvGLhr/wnZtcgk4ltroO4l9DyziwpkWfeVvl58TKcaSS2qDoaD7Od/SxC0q+hSeU
nz4X9WEn50+oohPUp9iB/AqZlTBk13dZdJlMRAH9gl6odIIxAe3VMKY8nEDNHAFc
oOxDLnHMcR5CdglqSbwz6EPuTLhcAcutSLYXZm3tQ8nPseKn+23Dzw0ZCLFouAXb
Ccp+wNhsmlE1U7of+yLB0hKgiGEyTIdkiYHR+9S+/s8UjdJH0/9U/ghx0Au1/FHG
8CgXTlTFuUWLhv/LtknrOXN5ffKmRoE6OKCHsEvdA8mBCJLht5amFZkLWJUlSdWp
zqZZ2uh3zc/8KmJe4BVxyOF5NDwYdL6z8dYLYeyZXCi5ParrYh+GteqJU4OuAdYY
vJ4w2X0+uXaW5oqhoscYkgwHSDn9pElv9nIrANQRXZH8bGGA2aD6GukJHvxitnvk
O0/209CgS+Cttz0BHk6/dxpJ/+YcRfxErPWBcFVKZeHTgX64wGOP5yUvDeXfNPsR
zERTU282vRLKscROcc1s0OIDvQSwrO8RWP7o1q1VdK3ee4wAG7Dy3GYIPuj2qPW5
CE9mEwjB7GfYn7tcFXO0Cn7gu6kqA8AJhTVdPXoze0s4sqb60RuUBpjGxjA9s/fn
cpN0T3U+TKEC2bN0qfJm
=Te1D
-END PGP SIGNATURE-


--
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/4f0bd03b-e7eb-43d2-b534-53b9a8fbc...@jeremiahfoster.com

Re: lintian and Debian derivatives

2011-07-07 Thread Paul Wise 
On Thu, Jul 7, 2011 at 11:18 AM, Neil Williams wrote:

> Lintian requires a lot of resources if it's to be run automatically
> against an entire distribution.

Yeah. Also there is quite a bit of scope for expanding the range of
tests lintian performs, by running external checkers like cppcheck,
pngcheck etc, which can only make lintian runs more time consuming.
Neils posted a thread about that just now.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6EFAQBURqdd912Jc=y5kczxv8ywa0qs0x_r_0yrw2n...@mail.gmail.com

Re: lintian and Debian derivatives

2011-07-07 Thread Neil Williams 
On Thu, 07 Jul 2011 00:25:59 +0200
Paul Wise  wrote:

> As a member of the Debian derivatives front desk (CCed) and initiator of
> the derivatives census, which aims to make derivatives more visible to
> Debian, I figured I should update lintian folks on the state of lintian
> development and usage in Debian derivatives.

Just a note, Emdebian is involved in lintian testing for Emdebian
packages, via the new lintian profile support (based on DEB_VENDOR), but
as the current Emdebian release (Grip) is binary-compatible with Debian,
the emphasis is on ensuring that the processed packages comply with the
Emdebian Policy changes from Debian Policy. (Specifically, allow the
removal of manpages and other files which lintian would otherwise
output as missing, allow compression where Debian does not, etc.)

Once MultiArch is in place with cross-building support, things will
change and Emdebian will again start using lintian in earnest. Quite
how and where the lintian tests are run is largely a problem of
resources.

> In addition, there is one derivative that I know of that has current and
> public lintian web pages, but I guess that one is well known by lintian
> maintainers since I guess it is run by Russ. It is a shame that lintian
> pages aren't more widespread within our derivatives. I guess some use it
> on the packages during their build process but I wonder how we could
> encourage them to use it more, anyone have any thoughts?

Lintian requires a lot of resources if it's to be run automatically
against an entire distribution. Emdebian will look at lintian reports
for cross-built stuff but that's only because that is likely to be
limited to less than a thousand source packages. Even then, I'm
expecting the full lintian test to take almost as long as it currently
takes to process the daily updates to Emdebian Grip.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp6I4ZpEPdo1.pgp
Description: PGP signature

Re: lintian and Debian derivatives

2011-07-07 Thread Niels Thykier 
On 2011-07-07 09:10, Paul Wise wrote:
> On Thu, Jul 7, 2011 at 12:49 AM, Geoffrey Thomas wrote:
> 
>> [...]
> 

Hi,

>> 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:
> 
> http://wiki.debian.org/Lintian/Spec/VendorCustomization
> 
> 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.
> 

The implementation has been merged into the master branch already, but
we have not released yet so we can still take suggestions without
breaking any "official stable" API. :)

Anyhow, basically Lintian will do the right thing if the debathena has /
provides two things: A dpkg origin file and a Lintian vendor profile.
  In the absence of a dpkg-origin file, you can use LINTIAN_PROFILE in
the config file (which works as long as the user does not have their own
and forget to copy that part).

The wiki page /should/ be up to date, but if there are disagreements
between the Lintian User manual (doc/lintian.xml in the source) and the
wiki page, let me know so I can fix it.

~Niels


-- 
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/4e1561af.10...@thykier.net

Re: lintian and Debian derivatives

2011-07-07 Thread Paul Wise 
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:

http://wiki.debian.org/Lintian/Spec/VendorCustomization

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.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6EC0qQ8C4eBaWzbwXVw-azg3XjDF2DK==ccxhjgeja...@mail.gmail.com

Re: lintian and Debian derivatives

2011-07-06 Thread Geoffrey Thomas 

On Thu, 7 Jul 2011, Paul Wise wrote:


In addition, there is one derivative that I know of that has current and
public lintian web pages, but I guess that one is well known by lintian
maintainers since I guess it is run by Russ. It is a shame that lintian
pages aren't more widespread within our derivatives. I guess some use it
on the packages during their build process but I wonder how we could
encourage them to use it more, anyone have any thoughts?

http://lintian.debathena.org/


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.


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...). For 
instance, all our packages have Maintainer: debath...@mit.edu, which is a 
list, and so just about everything triggers both 
source-nmu-has-incorrect-version-number and changelog-should-mention-nmu. 
We also put everything in debathena/* sections of our apt repository, 
triggering unknown-section everywhere. It feels pretty wrong to put 
override files in every single package, and even that doesn't suppress the 
warning entirely, just mention it's overridden.


The part I'm not positive about is how to identify "our" packages. It 
happens that we use a single maintainer, so that would work in our use 
case, but would that be upstreamable?


Alternatively, should certain checks like NMU cleanliness be disabled on 
non-official Debian packages? Again, I'm not sure how to identify which is 
which... it would be nicest if you could apt-get source and debuild on a 
machine that wasn't prepared in any special way, but it's not onerous for 
us to require that people hacking on our packages have something like a 
debathena-lintian-config package installed.


--
Geoffrey Thomas
SIPB Debathena team
debath...@mit.edu


--
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/alpine.deb.2.00.1107061834390.15...@tyger.mit.edu

Re: lintian and Debian derivatives

2011-07-06 Thread Russ Allbery 
Paul Wise  writes:

> In addition, there is one derivative that I know of that has current and
> public lintian web pages, but I guess that one is well known by lintian
> maintainers since I guess it is run by Russ. It is a shame that lintian
> pages aren't more widespread within our derivatives. I guess some use it
> on the packages during their build process but I wonder how we could
> encourage them to use it more, anyone have any thoughts?

> http://lintian.debathena.org/

Not run by me.  :)  I gave them some advice on how to get it set up, but
that was it.

> When Lars Wirzenius was an Ubuntu dev he also ran lintian against their
> archives but it seems that they discontinued that and if it is run, they
> only run it on dev machines. It might be interesting if automated runs
> of it were integrated into launchpad, do the lintian maintainers think
> it is flexible enough to make it easy for the launchpad devs to make
> that happen? Should we try to find the responsible folks and ask them to
> talk to the lintian maintainers about it?

Should be doable, although it's more awkward than it should be because
the web generation framework isn't really "productionalized" in terms of
being fully documented and installed on regular paths and so forth.  I've
been wanting to do that for a long time, but my day job has been keeping
me insanely busy.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87vcvf9gq2@windlord.stanford.edu

lintian and Debian derivatives

2011-07-06 Thread Paul Wise 
Hi all,

As a member of the Debian derivatives front desk (CCed) and initiator of
the derivatives census, which aims to make derivatives more visible to
Debian, I figured I should update lintian folks on the state of lintian
development and usage in Debian derivatives.

http://wiki.debian.org/DerivativesFrontDesk
http://wiki.debian.org/Derivatives/Census

A while ago it was mentioned that Maemo had some customisations to make
lintian more useful for derivatives. I just realised that the recent
vendor stuff might obsolete that, but it might be useful to talk to the
maemo/maemian folks to see if that is the case or what is the status of
their projects and any interesting checks we could add. Maemo still
exists, version 6 (also known as MeeGo 1.2 Harmattan) will be released
on the Nokia N9 phone later this year and a beta has shipped on the
Nokia N950 developer devices. 

http://lists.debian.org/debian-derivatives/2011/04/msg00024.html

In addition, there is one derivative that I know of that has current and
public lintian web pages, but I guess that one is well known by lintian
maintainers since I guess it is run by Russ. It is a shame that lintian
pages aren't more widespread within our derivatives. I guess some use it
on the packages during their build process but I wonder how we could
encourage them to use it more, anyone have any thoughts?

http://lintian.debathena.org/

When Lars Wirzenius was an Ubuntu dev he also ran lintian against their
archives but it seems that they discontinued that and if it is run, they
only run it on dev machines. It might be interesting if automated runs
of it were integrated into launchpad, do the lintian maintainers think
it is flexible enough to make it easy for the launchpad devs to make
that happen? Should we try to find the responsible folks and ask them to
talk to the lintian maintainers about it?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part