Package: lintian
Version: 2.1.3
Severity: wishlist
Hi
would be nice if Lintian could have an E: level for an easy to detect
FTBFS.
If there is a CMakeCache.txt file in the .diff.gz and as such in the
build tree, cmake will simply refuse to build the package and outright
fail:
CMake Error: The
Package: lintian
Version: 1.24.2.1
Severity: wishlist
/usr/bin/rep (in the librep* package) is the interpreter for the Lisp dialect
in which the window manager Sawfish is written.
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386
Hi,
Russ Allbery wrote:
* The t/tests directory is getting quite large. One easy thing we could
do that would help this, and which I think would also make sense given
the rest of the layout, is to move the *.desc file for a test from
t/tests into the test directory (calling it desc
Russ Allbery schrieb:
Matthias Klose d...@cs.tu-berlin.de writes:
gcc checks at build time all system headers (in /usr/include) and
fixes those headers which are not ANSI compliant. Because of
conflicting -dev packages, not all headers can be checked at gcc's
build time, so that could be
Ian Zimmerman i...@buug.org writes:
/usr/bin/rep (in the librep* package) is the interpreter for the Lisp
dialect in which the window manager Sawfish is written.
Hm, that looks like a bug in the librep9 package, yes? Shared library
packages may not contain unversioned files, since that
Joerg Jaspert jo...@ganneff.de writes:
would be nice if Lintian could have an E: level for an easy to detect
FTBFS. If there is a CMakeCache.txt file in the .diff.gz and as such in
the build tree, cmake will simply refuse to build the package and
outright fail:
CMake Error: The current
Raphael Geissert atomo64+deb...@gmail.com writes:
Russ Allbery wrote:
* The t/tests directory is getting quite large. One easy thing we could
do that would help this, and which I think would also make sense given
the rest of the layout, is to move the *.desc file for a test from
Matthias Klose d...@debian.org writes:
well, more headers are fixed, but I don't include these in the gcc
package. I still think to find out how many headers are affected, we
have to run the test at least once. Not sure how many many header files
will be found.
Okay, in that case I'll take a
Processing commands for cont...@bugs.debian.org:
# Automatically generated email from bts, devscripts version 2.10.35
block 510954 with 511016
Bug#511016: librep9: unversioned binaries in library package
Bug#510954: lintian: reports unusual interpreter for /usr/bin/rep
Was not blocked by any
Russ Allbery wrote:
Raphael Geissert writes:
Russ Allbery wrote:
What about grouping together tests belonging to the same check?
E.g. move all the cruft tests to t/tests/cruft/
We could do that -- it trades off directory size with more nesting. I
guess I don't have a strong opinion,
To not have a chance of too many false positives, I would suggest
looking directly into the diff, so avoid upstream source. And do not
count the error as soon as you find that filename anywhere in the rules
file (that assumes the Maintainer takes care of it somehow).
This is fairly trivial
Russ Allbery wrote:
[...]
So... we should probably figure out the best way to do this more often.
*heh*. I think triggering automatic garbage collection and repacking is
probably the easiest way. Does anyone know enough about the various Git
options in the git-gc man page or have enough
Russ Allbery wrote:
But more seriously, I think it might be more trouble than it's worth.
It's very convenient for Lintian's test suite to have a control template
that always has ${shlibs:Depends} and it's harmless in Arch: all packages.
I suppose it's one way to detect packages that were
Raphael Geissert atomo64+deb...@gmail.com writes:
Russ Allbery wrote:
But more seriously, I think it might be more trouble than it's worth.
It's very convenient for Lintian's test suite to have a control
template that always has ${shlibs:Depends} and it's harmless in Arch:
all packages. I
Russ Allbery schrieb:
Matthias Klose d...@debian.org writes:
well, more headers are fixed, but I don't include these in the gcc
package. I still think to find out how many headers are affected, we
have to run the test at least once. Not sure how many many header files
will be found.
Processing commands for cont...@bugs.debian.org:
owner 373767 !
Bug 373767 [lintian] lintian: Add support for --pedantic informational messages
Owner recorded as Raphael Geissert atom...@gmail.com.
block 497344 with 373767
Bug#373767: lintian: Add support for --pedantic informational messages
Processing commands for cont...@bugs.debian.org:
unblock 339829 with 409124
Bug#409124: [aesthetics] report trailing blank lines and whitespace
Bug#339829: [checks/fields] test for best-practice homepage fields
Was not blocked by any bugs.
Blocking bugs of 339829 removed: 409124
block 339829
Hi,
I went through the list of open bugs (including those marked as wontfix) and
marked the ones that IMO fit in the pedantic severity as being blocked by
the --pedantic feature request report.
If I missed something, or if anybody thinks that any of the checks should anyway
not be implemented
18 matches
Mail list logo