Re: lintian and Debian derivatives
On Thu, Jul 7, 2011 at 12:10 AM, Paul Wise p...@debian.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: 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
On Tue, Nov 8, 2011 at 8:02 PM, Evan Broder e...@ebroder.net wrote: On Thu, Jul 7, 2011 at 12:10 AM, Paul Wise p...@debian.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: 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
-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
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
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
On Thu, 07 Jul 2011 00:25:59 +0200 Paul Wise p...@debian.org 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
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
Paul Wise p...@debian.org 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) http://www.eyrie.org/~eagle/ -- 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
Re: lintian and Debian derivatives
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
