Re: Possibly excessive lintian warnings (was: NEW processing)
On Thu, 04 Dec 2008 01:00:17 -0800, Russ Allbery wrote: Sune Vuorela [EMAIL PROTECTED] writes: Latest, the warning about quilt patches without any description. Sure it is nice to have a description, but I don't need lintian to tell it. This is severity: minor, certainty: certain, which currently *barely* makes the W threshold. I think a very good argument could be made that this is actually severity: wishlist, which would downgrade it to an I. I'm copying debian-lint-maint to see what the other Lintian maintainers think. As I mentioned to Sune on IRC last night, the quilt tag's severity was copied from the equivalent dpatch tag (which was originally implemented as a warning and then moved to minor/certain during the transition). I've no problem with downgrading the severity, although we should make a corresponding change to the dpatch tag at the same time, unless there's some reason it's particularly worse for a dpatch to be missing a description. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
On 2008-12-04, Russ Allbery [EMAIL PROTECTED] wrote: Sune Vuorela [EMAIL PROTECTED] writes: Latest, the warning about quilt patches without any description. Sure it is nice to have a description, but I don't need lintian to tell it. I do think the warning is correct for a lint program, and it sounds like you do agree that this is something that should be improved about the package. The prioritization just may be off. Yes. downgrading to I is a good solution. And other warnings that could be changed: dbg-package-missing-depends - if there 1 dbg package and multiple arch depending packages beside that. Much of this is just more of the desktop file fiasco, since KDE doesn't follow what's supposedly a shared standard. I've complained about that at some length before and don't know what people are supposed to do with desktop files. If anyone from the KDE team is willing to propose patches or even concrete actionable changes to how Lintian checks desktop files so that KDE's desktop files don't produce tons of noise, I'd love to hear them. A good solution is to get lenny out of the door so that we can ditch kde3 and go on with kde4. KDE4 do follow the specs. Kde3 originates from before it was a shared standard (one of the few fdo standards that is actually a *shared* standard and not a rubber stamp on gnome standards, but that's a entirely different issue) You're apparently not using detached symbols for your debugging libraries, which is another small pile of warnings. we are, but apparantly dh_strip has issues under some conditions with some of the files. You have a huge and difficult-to-package piece of software and inadequate resources to do all the work on it that should ideally be done. I get This is why I need automatic tools that *helps* me and not tools that gets in the way. Not having a man page for a binary is a Policy violation. If Lintian doesn't complain about Policy violations, it's hard to understand what the point of it would be. There's a reason why that's a warning and not an error, though. :) It is also one of the reasons why we aren't overriding that. Please stop making the lives for the developers harder. Especially the idea about automatically rejecting based on lintian. The only thing that's been seriously discussed with an eye to implementation, so far as I know, is to automatically reject on the basis of a hand-selected and very limited subset of Lintian tags, which would probably not affect anything that you're doing and which would certainly not automatically block packages with proper overrides. I don't think this is going to hurt you as much as you think it would. Some people in this thread are suggesting automatic rejecting based on any E: tag. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
Sune Vuorela wrote:
[...]
And other warnings that could be changed:
dbg-package-missing-depends - if there 1 dbg package and multiple
arch depending packages beside that.
Will try to work on a dh-like command (or maybe a patch against dh_strip,
depends on what Joey prefers) that will basically scan
debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
matching the subgrouped expression, to automagically generate the Depends field
(say ${dbg:Depends}).
Once that's done it would be just a matter of adjusting a couple of lines in
debian/control and you are done with dealing with -dbg packages.
Cheers,
Raphael Geissert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
On 2008-12-04, Raphael Geissert [EMAIL PROTECTED] wrote:
Will try to work on a dh-like command (or maybe a patch against dh_strip,
depends on what Joey prefers) that will basically scan
debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
matching the subgrouped expression, to automagically generate the Depends
field
(say ${dbg:Depends}).
Once that's done it would be just a matter of adjusting a couple of lines in
debian/control and you are done with dealing with -dbg packages.
No. it actually wouldn't work.
In kde, for example kdepim, contains applications like
- korganizer
- kaddressbook
- kmail
- kpilot
With a -dbg package depending on all apps, the user will have to install
all apps just for getting a backtrace for one application.
That is not desired.
Bloating the archive with seperated -dbg packages is ttbomk not desired
as well.
The current approach is currently the least bad, and lintian should not
complain.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
Sune Vuorela wrote:
On 2008-12-04, Raphael Geissert [EMAIL PROTECTED] wrote:
Will try to work on a dh-like command (or maybe a patch against dh_strip,
depends on what Joey prefers) that will basically scan
debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
matching the subgrouped expression, to automagically generate the Depends
field (say ${dbg:Depends}).
Using ORed depends, I forgot to say.
Once that's done it would be just a matter of adjusting a couple of lines in
debian/control and you are done with dealing with -dbg packages.
No. it actually wouldn't work.
In kde, for example kdepim, contains applications like
- korganizer
- kaddressbook
- kmail
- kpilot
With a -dbg package depending on all apps, the user will have to install
all apps just for getting a backtrace for one application.
That is not desired.
Bloating the archive with seperated -dbg packages is ttbomk not desired
as well.
Of course.
The current approach is currently the least bad, and lintian should not
complain.
I don't agree, -dbg packages all by themselves are completely useless, they MUST
depend on something that will actually make them meaningful. Otherwise they
should not be built/shipped.
/Sune
Cheers,
Raphael Geissert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
On 2008-12-04, Raphael Geissert [EMAIL PROTECTED] wrote:
Using ORed depends, I forgot to say.
How would OR'ed depends work?
let us look at a example:
package: kdepim-dbg
depends: korganizer (= ${binary:Version})|kaddressbook (=${binary:version})
version: 4.1.3-1
now, I install korganizer 4.1.3-1 and kdepim-dbg.
later, 4.1.3-2 gets uploadde and I install kaddressbook.
korganizer still fulfills the kdepim-dbg version.
thus, the user is not anywhere better satisfied than before.
The only thing that would work would be if dpkg and apt supported
Conflicts: korganizer (!= $binary:Version), but that is as far as I can
read in policy not valid, so I also don't expect the tools to support
it.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
The best solution would just be to drop most -dbg packages, drop maintainer-uploaded binary packages (using the buildd built packages instead), install the dh_strip from debug.d.n on all the buildds and get people to use -dbgsym packages from debug.d.n. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly excessive lintian warnings (was: NEW processing)
Paul Wise wrote: The best solution would just be to drop most -dbg packages, drop maintainer-uploaded binary packages (using the buildd built packages instead), install the dh_strip from debug.d.n on all the buildds and get people to use -dbgsym packages from debug.d.n. a) That doesn't solve the dependencies problem. b) There are lots of packages missing at debug.d.n, and they only keep one package version. It isn't a drop-in replacement. c) What's the point on using a separate server when we have mirrors? d) We don't need debug symbols for every package out there. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
