Re: [Draft] Bits from the lintian maintainers
On 2011-08-12 18:03, Russ Allbery wrote: Niels Thykier ni...@thykier.net writes: Other improvements == These days Lintian ^^^ (Fixed a typo, thanks to Jakub Wilk) * processes related packages together Since 2.5.0~rc3 Lintian has grouped related packages and processed them together. With this Lintian can now do things like check if a manpage is in a direct dependency. ...in a direct dependency built from the same source package. Unless that feature is much neater than I think it is. :) Thanks, corrected (quoted the resulting paragraph in full): * processes related packages together Since 2.5.0~rc3 Lintian has grouped related packages and processed them together. With this Lintian can now do things like check if a manpage is in a direct dependency built from the same source package. * supports architecture specific overrides architecture-specific In some cases tags may only appear on certain architectures and since files must be byte-for-byte-identical in Multi-Arch: same packages, Lintian now has architecture specific overrides. For now it only supports simple architectures in the overrides. ...in the overrides, not wildcards like linux-any. (Some people probably won't know what you mean here, since architecture wildcards are still fairly new.) Thanks, corrected (quoted the resulting paragraph in full): * supports architecture-specific overrides In some cases tags may only appear on certain architectures and since files must be byte-for-byte-identical in Multi-Arch: same packages, Lintian now has architecture specific overrides. For now it only supports simple architectures in the overrides, not wildcards like linux-any. Finally Jakub Wilk noted another typo of mine (s/derivate/derivative/) in the Help us write lintian-harness part. This otherwise looks great to me. Great, I will give it another day or two, just in case someone else wants to do a review. And on a personal note, thank you *so* much for all the work that you've been doing on Lintian. I've often had the experience with other open source projects of personally running out of time and seeing the project stagnate, which usually makes me feel even worse about not having enough time and is very depressing. It's been a delight to see things moving along with such wonderful progress! It's made it much less depressing to be temporarily trapped in a deluge of work, and is keeping me feeling enthusiastic about the chance to get back to work on Lintian again. Thanks, I hope we can soon do another The back under 100 open bugs release. . :) (Ref: version 1.23.31) (My current major work project is supposed to go into beta release on September 1st, after which I have a bunch of documentation to write and then am on vacation for chunks of September and most of October, and then I have great hopes to be back and able to do more Debian work. At: http://git.eyrie.org/?p=kerberos/webauth.git is what I've been working on, for anyone who's idly curious.) That sounds great; especially schools starts for me again soon, so my contribution-rate largely depend on just how boring my courses are. XD ~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/4e464d27@thykier.net
Re: [Draft] Bits from the lintian maintainers
Niels Thykier ni...@thykier.net writes: * processes related packages together Since 2.5.0~rc3 Lintian has grouped related packages and processed them together. With this Lintian can now do things like check if a manpage is in a direct dependency. ...in a direct dependency built from the same source package. Unless that feature is much neater than I think it is. :) * supports architecture specific overrides architecture-specific In some cases tags may only appear on certain architectures and since files must be byte-for-byte-identical in Multi-Arch: same packages, Lintian now has architecture specific overrides. For now it only supports simple architectures in the overrides. ...in the overrides, not wildcards like linux-any. (Some people probably won't know what you mean here, since architecture wildcards are still fairly new.) This otherwise looks great to me. And on a personal note, thank you *so* much for all the work that you've been doing on Lintian. I've often had the experience with other open source projects of personally running out of time and seeing the project stagnate, which usually makes me feel even worse about not having enough time and is very depressing. It's been a delight to see things moving along with such wonderful progress! It's made it much less depressing to be temporarily trapped in a deluge of work, and is keeping me feeling enthusiastic about the chance to get back to work on Lintian again. (My current major work project is supposed to go into beta release on September 1st, after which I have a bunch of documentation to write and then am on vacation for chunks of September and most of October, and then I have great hopes to be back and able to do more Debian work. At: http://git.eyrie.org/?p=kerberos/webauth.git is what I've been working on, for anyone who's idly curious.) -- 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/87vcu24nxv@windlord.stanford.edu
Re: [Draft] Bits from the lintian maintainers
On Aug 12, 2011, at 18:03, Russ Allbery wrote: Niels Thykier ni...@thykier.net writes: This otherwise looks great to me. And on a personal note, thank you *so* much for all the work that you've been doing on Lintian. I've often had the experience with other open source projects of personally running out of time and seeing the project stagnate, which usually makes me feel even worse about not having enough time and is very depressing. It's been a delight to see things moving along with such wonderful progress! It's made it much less depressing to be temporarily trapped in a deluge of work, and is keeping me feeling enthusiastic about the chance to get back to work on Lintian again. +1 (My current major work project is supposed to go into beta release on September 1st, after which I have a bunch of documentation to write and then am on vacation for chunks of September and most of October, and then I have great hopes to be back and able to do more Debian work. At: http://git.eyrie.org/?p=kerberos/webauth.git is what I've been working on, for anyone who's idly curious.) Interesting. :-) I've got a question regarding the various lintian modules. I'm a command line person and often use tools like perldoc to read the documentation that is in with code. Lintian does seem to use plain old documentation very much which I think is too bad. It is considered a perl best practice. I'm happy to add that type of pod to the modules and the scripts as I come across the need. Is that useful? I'd also like to move the README.Developer from plain text to pod while it is still early. pod can get translated into markdown and Mediawiki markup as well as html. Regards, Jeremiah -- 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/82741958-a5f5-47a9-b55d-97ea8286f...@jeremiahfoster.com
Re: [Draft] Bits from the lintian maintainers
Jeremiah Foster jerem...@jeremiahfoster.com writes: I've got a question regarding the various lintian modules. I'm a command line person and often use tools like perldoc to read the documentation that is in with code. Lintian does seem to use plain old documentation very much which I think is too bad. It is considered a perl best practice. I'm happy to add that type of pod to the modules and the scripts as I come across the need. Is that useful? The newer Lintian modules (the stuff under lib/Lintian) should all have POD documentation, hopefully -- if not, it's a bug. I never wrote documentation for the modules in lib that haven't moved under Lintian since normally the API of the older modules is dodgy and should be redone as part of the namespace move to Lintian::*, so writing POD for the previous API seemed like a waste. The checks themselves do indeed not have POD. I usually think of POD more as end-user documentation, so am not sure how helpful it would be, but if people would find it so, it may be a good way to document the internals more. (Although one should also think about what should instead be moved into a module instead of documented in-place in the check scripts.) I'd also like to move the README.Developer from plain text to pod while it is still early. pod can get translated into markdown and Mediawiki markup as well as html. That's probably a good idea, since among other things it would let us generate an HTML version to stick on lintian.debian.org. I have Perl scripts that do that for text documentation, but the results of converting POD are usually a bit better. -- 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/87zkje1khf@windlord.stanford.edu
Re: [Draft] Bits from the lintian maintainers
On Aug 12, 2011, at 21:36, Jeremiah Foster wrote: I've got a question regarding the various lintian modules. I'm a command line person and often use tools like perldoc to read the documentation that is in with code. Lintian does seem to use I meant doesn't of course. :} plain old documentation very much which I think is too bad. It is considered a perl best practice. I'm happy to add that type of pod to the modules and the scripts as I come across the need. Is that useful? I'd also like to move the README.Developer from plain text to pod while it is still early. pod can get translated into markdown and Mediawiki markup as well as html. Regards, Jeremiah -- 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/82741958-a5f5-47a9-b55d-97ea8286f...@jeremiahfoster.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/4181e7b0-52d6-44f7-90e1-7aee5aa2a...@jeremiahfoster.com
Re: DRAFT: Bits from the Lintian maintainers
Russ Allbery wrote:
debhelper and didn't have this dependency will now get a warning. We're
currently deciding whether to teach Lintian that ${misc:Depends} isn't
needed in this specific case or to just uniformly recommend the
${misc:Depends} dependency for all packages using debhelper.
The latter is correct. Any debhelper command may need to add new
misc:Depends at any time.
--
see shy jo
signature.asc
Description: Digital signature
Re: DRAFT: Bits from the Lintian maintainers
Joey Hess jo...@debian.org writes:
Russ Allbery wrote:
debhelper and didn't have this dependency will now get a warning.
We're currently deciding whether to teach Lintian that ${misc:Depends}
isn't needed in this specific case or to just uniformly recommend the
${misc:Depends} dependency for all packages using debhelper.
The latter is correct. Any debhelper command may need to add new
misc:Depends at any time.
Thanks! In that case, I vote we simplify the code and just require
${misc:Depends} if debhelper is in play.
--
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
Re: DRAFT: Bits from the Lintian maintainers
Russ Allbery wrote: [ Any mistakes, or anything else I should mention? ] What about including the usual we welcome more contributors? :) New Team Member === The best news about Lintian is that Raphael Geissert has joined the team as an additional Lintian maintainer. Heh, thanks :) [...] The next Lintian release is planned for Saturday, January 2nd. How about: The next Lintian release is going to be released next year. On Saturday, January 2nd.? :) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DRAFT: Bits from the Lintian maintainers
On Fri, 2009-02-06 at 19:04 -0800, Russ Allbery wrote: [ This is a draft of a post I'd like to send to debian-devel-announce. Take a look and let me know if anything is wrong or missing. Thanks! ] Thanks for that; I don't have think I have anything specific to add that wasn't on Raphael's rather comprehensive list. (fwiw, I've never really liked as good of a blah, but that could be an en_US vs en_GB thing). We're also looking for someone who would like to tackle converting the Lintian manual in Docbook instead of DebianDoc-SGML and working on s/in/to/. Adam -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DRAFT: Bits from the Lintian maintainers
Adam D. Barratt a...@adam-barratt.org.uk writes: (fwiw, I've never really liked as good of a blah, but that could be an en_US vs en_GB thing). No, you're right, it's a sloppy construct. I reworded it. We're also looking for someone who would like to tackle converting the Lintian manual in Docbook instead of DebianDoc-SGML and working on s/in/to/. Thanks! -- 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
Re: DRAFT: Bits from the Lintian maintainers
Russ Allbery wrote: [ This is a draft of a post I'd like to send to debian-devel-announce. Take a look and let me know if anything is wrong or missing. Thanks! ] Current Status == [...] Maybe it should be mentioned how many checks there were in etch's lintian, how many in lenny's, and how many in 2.2.x (the latest version in sid available as of the time the mail is sent). Something else that could also be mentioned is the new private/refresh-*-data momentum, in the attempt to remain as up to date as possible. Other points: * lintian and ftp-master * checking of .deb and .changes * summary of tag changes * the lack of a header/slogan in the latest releases :) * Yay! lintian goes 2.x * experimental check Pedantic Support [...] My opinion is that everyone with a package which is more or less lintian clean (say less than 10 tags) should try --pedantic at least once every now and then to see what it reports and think about those issues. You decide, but take a look anyway would be the right slogan. [...] Upcoming Work = [...] Raphael Geissert has been working on improved infrastructure for source package checks, generating more laboratory information to allow some requested checks to be implemented. The start of that work will hopefully be merged in the next release. Some optimisations and binary-related checks (including spell checking) are on their way as well. I also started to collect some missing checks from linda and rpmlint that should be included as well. Helping Out === More hands are always welcome! Lintian is a nice project to work on when one only has an hour or two, since a lot of the requested checks don't require very much code. Work on the test suite is also much appreciated and doesn't require a large time investment. If you want to help out, take a look at the wiki page at: http://wiki.debian.org/Teams/Lintian Some of the Debconf7 Discussion points are not longer valid, the page needs to be updated. We're also looking for someone who would like to tackle converting the Lintian manual in Docbook instead of DebianDoc-SGML and working on updates. There's quite a bit about Lintian that isn't currently documented. If you're in terested, let us know. As an end note it could be mentioned that any idea for a new check should be reported, discussion will later happen, but idea should be kept shout. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DRAFT: Bits from the Lintian maintainers
Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: FWIW, two years ago (?) Jeroen, djpig and I had a discussion about this. The basic idea back then was the same as you describe now: Move away from E, W and I and use two letters to indicate the two different measurements are represented: (i) How certain lintian is: Some checks are heuristics, in other cases lintian is absolutely sure. (ii) How bad a problem is. A spelling mistake (kde instead of KDE) is a bug - on the other hand, broken shlibs handling might be harder to detect, but leads to actual problems. I don't have notes from that meeting (and I think there were never any notes published), so the rest of That's pretty much the same, yup. I think we should probably provide a mapping to E/W/I for backwards compatibility but provide a way of getting more information. I think there's a third metric in addition to the two that you list, namely where does this rule come from, so that people can selectively enable or disable classes of rule origins, although that's probably less common. * Better information retrieval, and caching, of lab information during checks. Right now, all of Lintian's check scripts repeatedly open and reopen files in the laboratory and reparse data in each check script. Instead, that data could be loaded on demand and then cached in case another check script needed it. ACK. Let's get rid of the lab idea, it doesn't help to make lintian easier. While we are at it, we could also finally document what data is collected by lintian in what format. I sometimes need to create a static lab, check a package and look at the unpack results to find out what is already collected. I'm not sure about eliminating the lab entirely, since it's useful as a resource for other sorts of checks and greps, but I think the first step regardless is to provide an abstraction layer for reading data from the lab that caches. Then, if we so choose, we could replace the data source behind that abstraction with some other system without having to change any code. I should try to prototype something and implement a simple data method so that everyone has an example to look at. Another idea discussed in that meeting two years ago was to extend lintian by adding a second tool using pbuilder/piuparts for some checks that require data from other packages. This would of course require net access (or at least access to a Debian mirror), but would finally allow to fix the twenty-something wontfix bugs that require access to other packages. I'm not quite sure how that would fit into the other stuff that lintian does, but definitely something to keep in mind. Anyway, the mail looks fine, please go ahead and post it to dda. I'm just waiting for the complete archive run to finish so that the uploaders information is there, and then I'll do that. Thanks for the review! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DRAFT: Bits from the Lintian maintainers
Russ Allbery [EMAIL PROTECTED] writes: * Provide a way to more clearly indicate Lintian's certainty, the severity of the problem, and the source of the rule that Lintian is checking, rather than always collapsing that information into a simple three-level error/warning/info hierarchy. This would allow users to, for example, see only the tags where Lintian is certain there is a problem, or easily ignore tags for aesthetic issues that aren't violations of technical requirements. This sort of additional granularity is a necessary prerequisite for running Lintian on all uploaded packages and rejecting on serious Lintian errors, something that's been oft-proposed. FWIW, two years ago (?) Jeroen, djpig and I had a discussion about this. The basic idea back then was the same as you describe now: Move away from E, W and I and use two letters to indicate the two different measurements are represented: (i) How certain lintian is: Some checks are heuristics, in other cases lintian is absolutely sure. (ii) How bad a problem is. A spelling mistake (kde instead of KDE) is a bug - on the other hand, broken shlibs handling might be harder to detect, but leads to actual problems. I don't have notes from that meeting (and I think there were never any notes published), so the rest of * Better information retrieval, and caching, of lab information during checks. Right now, all of Lintian's check scripts repeatedly open and reopen files in the laboratory and reparse data in each check script. Instead, that data could be loaded on demand and then cached in case another check script needed it. ACK. Let's get rid of the lab idea, it doesn't help to make lintian easier. While we are at it, we could also finally document what data is collected by lintian in what format. I sometimes need to create a static lab, check a package and look at the unpack results to find out what is already collected. Another idea discussed in that meeting two years ago was to extend lintian by adding a second tool using pbuilder/piuparts for some checks that require data from other packages. This would of course require net access (or at least access to a Debian mirror), but would finally allow to fix the twenty-something wontfix bugs that require access to other packages. Anyway, the mail looks fine, please go ahead and post it to dda. Marc -- BOFH #71: The file system is full of it pgpeX1L22wSMi.pgp Description: PGP signature
