On Fri, Jul 18, 2008 at 09:47:14 -0700, Russ Allbery wrote: > > $ lintian ../xorg-server_1.4.2-2_i386.changes |wc -l > > 1438 > > A fair chunk of that with 1.4.2-1 at least is: > > E: xserver-xorg-core: unstripped-binary-or-object > ./usr/lib/xorg/modules/extensions/libGLcore.so > There are 35 of those.
> Is Lintian wrong about this? Do those files need to be left unstripped > for some reason? No. This comes from stripping rules (strip --strip-debug --remove-section=.note --remove-section=.comment) that I think come from the days of the old xfree86 custom loader, where we couldn't just strip the modules without also making them unusable. I've fixed that in the experimental branch a while ago. > > This is just not bearable. I get one warning for every Makefile.in in > > the package (see #471263), > > I believe this is a bug in the package which you should fix and Lintian is > correct. (This is particularly the case with the 3.0 format, where those > changes will end up as a monster patch combined with any other changes > made directly in the package.) > > I'll be more explicit about that now and tag 471263 as wontfix; there are > some edge cases for which we may change Lintian's behavior, but the basic > point of not having the autotools regeneration diff outside the patch > system is a place where I don't think Lintian should change. > I disagree with this, but that's not really the point. If lintian wants to complain that there are changes outside debian/, then it can do it once. Doing it once for every modified file doesn't bring anything IMO. If I want to know which files are modified I can lsdiff foo.diff.gz myself. > > and one for every line deemed too long in debian/copyright for every > > binary package. Please turn the noise down, at least by default. > > Why don't you just rewrap the license that you currently have wrapped at > 90 columns? > > I may be missing something, but it really is looking like you're > complaining that Lintian is noisy when run on a buggy package, rather than > just fixing the (minor) bugs that it's detecting. > I don't think it's reasonable to output 1000 warnings about this. I wouldn't complain if it was one per package instead of once per line per package. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
