Re: packages with really old standards version
On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: snip when I rewrite lintian (started yesterday) the lintian messages will match policy: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed Advisory (A:)? not sure what I am naming the MAY message. Messages that are not due to policy violations will have their level set on the importance of the problem. With this restructuring, a Developer who gets a third level may ignore the message, ignore a Warning for a short time and know that E: means 'I should read policy'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- I can be immature if I want to, because I'm mature enough to make my own decisions. Who is John Galt? [EMAIL PROTECTED]
Re: packages with really old standards version
On Tue, Feb 20, 2001 at 07:16:14PM -0800, Sean 'Shaleh' Perry wrote: On Wed, Feb 21, 2001 at 12:39:08PM +1000, Anthony Towns wrote: Currently, aiui, lintian uses E: for problems that it's sure are mistakes, and W: for problems that it's only guessing are mistakes. I think that division is still useful. no, it tries to do this based on 2.x level MUST/SHOULD and the authors beliefs of severity. Has nothing to do with the sureness of the test. When did this change, then? Christian and I designed it the way Anthony described it. Richard Braakman
Re: packages with really old standards version
Adrian Bunk wrote: And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. I would be happy to do that to tell the truth, if it meant we got half of them updated to current standards before the freeze. (I had pretty good luck with a recent filing of 80-some rc bug reports on app-defaults files) -- see shy jo
Re: packages with really old standards version
Joey Hess wrote: Adrian Bunk wrote: And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. I would be happy to do that to tell the truth, if it meant we got half of them updated to current standards before the freeze. (I had pretty good luck with a recent filing of 80-some rc bug reports on app-defaults files) Reading the rest of the thread, I sense there's a consnsensus that it'd be ok to file such bugs if they weren't rc, at least. So 578 priority normal bugs coming right up unless someone tells me otherwise. (Bet, apt 0.5 has Standards-Version: 3.1.1 :-) -- see shy jo, whose package release scripts cheat by updating the standards-version the the currently-installed version of policy
Re: packages with really old standards version
On Wed, 21 Feb 2001, Anthony Towns wrote: On Tue, Feb 20, 2001 at 06:27:40PM -0800, Sean 'Shaleh' Perry wrote: I file any bugs I detect, once I get lintian running on the archive, old packages beware (-: A package of 2.x policy behaves in a way different than current packages. They lack a /usr/share/doc, their manpages are not in share either. They may violate other things. Point is, these packages will be a source of bugs. Sure, but lacking /usr/share/doc is, aiui, a non-RC issue as it stands (since there seems to be some sort of deadlock in working out what to do about it)... ... In a message sent in this thread only a good hour before this mail you said you want that RC are filed for packages lacking /usr/share/doc (and all the /usr/doc problems and symlinks can go away as soon as all packages have moved their documentation to /usr/share/doc): -- snip -- ... severity); and I'd definitely encourage the lintian maintainer to file serious bugs about automatically detect-able violations of any MUST directives in current policy (no matter what standards-version the packages claims to comply with). ... -- snip -- A package that puts it's documentation in /usr/doc violates a must in section 10.1.1. of the policy: -- snip -- 10.1.1. Linux File system Structure --- The location of all installed files and directories must comply with the Linux File system Hierarchy Standard (FHS). The latest version of this document can be found alongside this manual or on http://www.pathname.com/fhs/. Specific questions about following the standard may be asked on `debian-devel', or referred to Daniel Quinlan, the FHS coordinator, at [EMAIL PROTECTED]. -- snip -- Cheers, aj cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: packages with really old standards version
On Wed, Feb 21, 2001 at 01:31:30AM -0800, Joey Hess wrote: Reading the rest of the thread, I sense there's a consnsensus that it'd be ok to file such bugs if they weren't rc, at least. So 578 priority normal bugs coming right up unless someone tells me otherwise. I'm sure you've got a better idea than I do where lintian's up to at the moment, but, if it's possible, it'd probably be helpful to also include all the lintian errors in a package (or at least an interesting subset thereof), and making it `serious' iff some of those errors are against MUST clauses... Or not. Whatever. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpShj30Ht9bc.pgp Description: PGP signature
Re: packages with really old standards version
On Wed, Feb 21, 2001 at 11:07:01AM +0100, Adrian Bunk wrote: On Wed, 21 Feb 2001, Anthony Towns wrote: On Tue, Feb 20, 2001 at 06:27:40PM -0800, Sean 'Shaleh' Perry wrote: Sure, but lacking /usr/share/doc is, aiui, a non-RC issue as it stands (since there seems to be some sort of deadlock in working out what to do about it)... In a message sent in this thread only a good hour before this mail you said you want that RC are filed for packages lacking /usr/share/doc [...] Obviously, I misunderstand it then. So, what, exactly are we doing about /usr/doc and /usr/share/doc for woody? I propose we make the /usr/doc/foo - /usr/share/doc/foo kludge mandatory for all packages in woody, and file RC bugs on them ASAP. It's functional, it's already in policy, we know how to do it, and we can get rid of in the future without major hassle. If someone has some specific alternative they'd rather, that's at least as effective, please explain it now (ie, within the next few days), or wait 'til after woody. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpRQcTP9hkHK.pgp Description: PGP signature
Re: packages with really old standards version
On 21-Feb-2001 Bob Hilliard wrote: Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed There should be no Lintian messages regarding MAY items. If any such thing is considered to warrant a Lintian Warning or Error message, Policy should be changed to make it a SHOULD or MUST item. it is all ideas right now. likely if I do implement it, the messages will be controlled via command line / conf file options. It is ridiculous to have Policy say something is permissible or acceptable, and then have Lintian pop up with a Warning.
packages with really old standards version
So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held.
Re: packages with really old standards version
* Sean 'Shaleh' Perry [EMAIL PROTECTED] [20010220 12:49]: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I second this. -- Martin Michlmayr [EMAIL PROTECTED]
Re: packages with really old standards version
Hi Sean! On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. picardmake it so/picard yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' :By professionals, | `. `' for professionals http://www.palfrader.org/ | `-http://www.debian.org/
Re: packages with really old standards version
On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. Just for the record: ftp.debian.org has currently 579 source packages with standards version 3.0.0 And just out of curiosity: apt has standards version 2.4.1 And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: packages with really old standards version
* Adrian Bunk [EMAIL PROTECTED] [010220 13:52]: On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. And just out of curiosity: apt has standards version 2.4.1 That is interesting. Of course, I bet apt 0.4 will be 3.x.x when it is finally released. And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. Logistics aside though, wouldn't it be kind of neat to have all the packages shipped with woody be standards version 3.0 or higher? (Although, maybe sarge is a better idea for this one; sarge ought to have kernel 2.4.x, and between that and having all packages be standards version 3.x, numbering sarge to 3.0 would make a certain amount of cool sense. shrug) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: packages with really old standards version
And more serious: If you want to force the upgrade of the standards version you must file 579 RC bugs on these packages. sounds like a plan to me. Many of these are either: a) horribly out of date b) simply forgot to change the number
Re: packages with really old standards version
On Tue, 20 Feb 2001, Martin Michlmayr wrote: * Sean 'Shaleh' Perry [EMAIL PROTECTED] [20010220 12:49]: So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I second this. So do I. 2.x doesn't get the GPL copyright, FHS or logrotate right, and that's a bit too much IMHO. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpViKEzrXDZ2.pgp Description: PGP signature
Re: packages with really old standards version
On Tue, Feb 20, 2001 at 12:49:34PM -0800, Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I.. (second? third? fourth?) this. -- Brian Russo [EMAIL PROTECTED] Debian/GNU Linux [EMAIL PROTECTED] http://www.debian.org LPSG member[EMAIL PROTECTED] http://www.lpsg.org -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: packages with really old standards version
On Tue, 20 Feb 2001 at 12:49:34 -0800 (PST), Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I second this proposal (assuming it is one). To avoid quite such a large number of RC bugs being filed, shall we try to deal with as many of these as possible during the bugsquash party this weekend? -- Colin Watson [EMAIL PROTECTED] pgp5MV6021a5W.pgp Description: PGP signature
Re: packages with really old standards version
On Tue, Feb 20, 2001 at 12:49:34PM -0800, Sean 'Shaleh' Perry wrote: So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check the changelog and this binary-any package has not been uploaded in 2 years. It is standards version 2.3.0.1, ICK! So, perhaps we should drop the bar a little. If your package is not at least 3.x.x, it gets held. I object to this. Holding packages due to actual bugs, yes certainly. Holding packages because there's a number that seems to indicate there might possibly be bugs, no way in hell. I'd encourage the lintian maintainer ( :) ) to automatically file old standards version bugs about such packages (of normal/minor/wishlist severity); and I'd definitely encourage the lintian maintainer to file serious bugs about automatically detect-able violations of any MUST directives in current policy (no matter what standards-version the packages claims to comply with). But please don't file RC bugs unless there is a *specific* problem with the package. Shaleh, I'm not sure I got around to filing a bug against lintian about this, but it'd be nice if lintian differentiated between MUST/SHOULD/MAY violations in its output. Something like: E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 or similar, perhaps? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpsG8gAoIKhf.pgp Description: PGP signature
Re: packages with really old standards version
On Wed, Feb 21, 2001 at 11:30:23AM +1000, Anthony Towns wrote: Shaleh, I'm not sure I got around to filing a bug against lintian about this, but it'd be nice if lintian differentiated between MUST/SHOULD/MAY violations in its output. Something like: E!: non-FHS-directory Yes, real bug. E-: missing-manpage Ditto. E?: standards-version-uses-4-digits-not-3 Not a bug (explicitly permitted by policy). As I work through policy, I'm going to take care over the issue of MUST/SHOULD/MAY etc. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: packages with really old standards version
On Wed, Feb 21, 2001 at 11:30:23AM +1000, Anthony Towns wrote: I'd encourage the lintian maintainer ( :) ) to automatically file old standards version bugs about such packages (of normal/minor/wishlist severity); and I'd definitely encourage the lintian maintainer to file serious bugs about automatically detect-able violations of any MUST directives in current policy (no matter what standards-version the packages claims to comply with). I file any bugs I detect, once I get lintian running on the archive, old packages beware (-: A package of 2.x policy behaves in a way different than current packages. They lack a /usr/share/doc, their manpages are not in share either. They may violate other things. Point is, these packages will be a source of bugs. All I am asking for is the package get looked at. I found one today that had not been touched in 2 years. Ther eare many others, and they hide. If nothing else a way to flag packages older than X months or Standards-Version YY would be nice. Shaleh, I'm not sure I got around to filing a bug against lintian about this, but it'd be nice if lintian differentiated between MUST/SHOULD/MAY violations in its output. Something like: E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 when I rewrite lintian (started yesterday) the lintian messages will match policy: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed not sure what I am naming the MAY message. Messages that are not due to policy violations will have their level set on the importance of the problem. With this restructuring, a Developer who gets a third level may ignore the message, ignore a Warning for a short time and know that E: means 'I should read policy'.
Re: packages with really old standards version
On Tue, Feb 20, 2001 at 06:27:40PM -0800, Sean 'Shaleh' Perry wrote: I file any bugs I detect, once I get lintian running on the archive, old packages beware (-: A package of 2.x policy behaves in a way different than current packages. They lack a /usr/share/doc, their manpages are not in share either. They may violate other things. Point is, these packages will be a source of bugs. Sure, but lacking /usr/share/doc is, aiui, a non-RC issue as it stands (since there seems to be some sort of deadlock in working out what to do about it)... All I am asking for is the package get looked at. I found one today that had not been touched in 2 years. Ther eare many others, and they hide. Sure, getting looked at is fine. That's different from filing RC bugs, though. E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 when I rewrite lintian (started yesterday) the lintian messages will match policy: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed Currently, aiui, lintian uses E: for problems that it's sure are mistakes, and W: for problems that it's only guessing are mistakes. I think that division is still useful. katie or testing could legitimately automatically reject packages with E! lintian errors, but not E- or W!, eg. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: packages with really old standards version
On Wed, Feb 21, 2001 at 12:39:08PM +1000, Anthony Towns wrote: E!: non-FHS-directory E-: missing-manpage E?: standards-version-uses-4-digits-not-3 when I rewrite lintian (started yesterday) the lintian messages will match policy: Error (E:) -- violate a MUST Warning (W:) -- violate a SHOULD XXX (?:) -- a MAY is not followed Currently, aiui, lintian uses E: for problems that it's sure are mistakes, and W: for problems that it's only guessing are mistakes. I think that division is still useful. no, it tries to do this based on 2.x level MUST/SHOULD and the authors beliefs of severity. Has nothing to do with the sureness of the test. katie or testing could legitimately automatically reject packages with E! lintian errors, but not E- or W!, eg. lintian will never be able to return a sure judgement. Manoj's packages confuse it thoroughly, but on hand inspection I am sure they follow policy. Every message lintian outputs should be checked manually and by a re-read of policy. It is trying to discern what a human meant. In the realm of coding, people do all kinds of crazy things and lintian can only cope so well. Assume every message is 'X-:'. A Package with an E: should be marked for human inspection at best. James Troup has stated that when I trust lintian he will consider hooking it into dinstall. I think this is a good thing. It is my hope to have lintian to a sane state by summer (July-ish). Wichert wants something in 3 months for the FSG. Not sure if the code base will make that, but I will try.
