On 13076 March 1977, Niels Thykier wrote:
If we want to stick to entirely static serving, I suspect we could get
away with a Apache rewrite rule and a symlink farm. Concrete example
being something like:
RewriteRule ^/source/((lib.).*)\.html$ /by-source/$1/$2.html#$2 [NE,L,R]
On 11933 March 1977, Russ Allbery wrote:
The next upload of Lintian will remove the check for Author(s), since
it's very prone to false positives and isn't checking what it's supposed
to be checking. Thank you very much to Manoj for his work on verifying
this tag.
Is that the 2.2.18 we now
Package: lintian
Version: 2.1.3
Severity: wishlist
Hello,
would be nice if Lintian could issue a warning in case someone is listed
in Maintainer: *and* Uploaders: headers. One of them is enough. (In
fact, being listed in both generates a little warning at dinstall time).
Thanks!
--
bye, Joerg
would be nice if Lintian could issue a warning in case someone is listed
in Maintainer: *and* Uploaders: headers. One of them is enough. (In
fact, being listed in both generates a little warning at dinstall time).
Appears that a double listing in maintainer: and uploaders: *is* already
a tag
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
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
Package: lintian
Version: 2.1.1~bpo40+1
Severity: important
Hi
lintian had a nice --color html which we ftpmaster used. Now in 2.1.1
thats gone. Please put it back. Thanks.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
I'd rather we put back the original option. We shouldn't make users use a
different option, and that output format wasn't experimental. It was
intended to be a regularly supported option.
Okay, I'll go with that then.
Thanks.
I've re-added (and committed) support for the original
I'm fairly sure Joerg is looking for limiting the issued tags to only
the ones specified in the tag file, regardless of which check scripts
are run.
Thats the simplest possible way, yes.
Yeah, I was assuming the process would largely be:
if ! lintian --show-overrides --tags-from-file
On 11468 March 1977, Russ Allbery wrote:
What are your comments on this?
I think this sounds like a great idea. I'd ideally rather combine the
ftp-master tag in with the severity system that we're currently working
on, rather than have a separate thing that's in addition to severity, but
we
On 11469 March 1977, Jordà Polo wrote:
Still, it would be interesting to know what kind of tags do you plan to
autoreject on. Perhaps your set of tags can be directly mapped to a
particular group of tags using Severity/Certainty. This way we could
avoid duplication and synchronization (e.g.
Package: lintian
Version: 1.24.1
Severity: wishlist
Hi
please provide a way to limit the checks that get run by providing an
input file listing tags, one per line.
Use: ftpmaster side to limit runtime by lintian, enabling use of lintian
as an automated quality control tool run on every source
Hi
as just discussed with djpig here at DebConf, we (as in ftpmasters/team)
want to use lintian as an automated forced qa tool, no longer a
voluntary one. At least for a certain set of tags.
What we basically want is
- ftpmaster selects a set of tags on which we autoreject on, we write
On 11335 March 1977, Rafael Laboissiere wrote:
octave-pkg-dev build-depends on cdbs, which eliminates the need for the
Octave add-on package build-depending on cdbs. Howvere, when the package
needs quilt and include /usr/share/cdbs/1/rules/patchsys-quilt.mk is added
to debian/rules, Lintian
Package: lintian
Version: 1.23.46~bpo40+1
Severity: normal
Hi
please issue an E:, or at least W:, on packages having files or links in
/var/www.
Its a standard reject for me in NEW, with a reason similar to
+++---+++
rejected, please remove the var/www link to usr/share. Its a policy/fhs
I don't know if we want to allow for that or not. I find the logic
dubious, but dpatch supports that mode of operation.
I have to admit that I consider using a patch system in this way to be a
bug. I think we might want to upload with this check and see if there
are too many false
Package: lintian
Version: 1.23.43
Severity: important
Hi
Something seems to be wrong with python in Build-Dependencies.
We have the following dsc:
.dsc file for enthought-chaco2_2.0.1b1-1.dsc
Format: 1.0
Source: enthought-chaco2
Binary: python-enthought-chaco2
Architecture: any
Package: lintian
Hi
Would be nice if --color could optionally output html color codes.
Use the same color codes as for terminal, just use html like
span style=color: $COLORcolored text/span
Thx.
--
bye Joerg
Endianess is the dispute on which end to open an egg at.
--
To UNSUBSCRIBE,
Package: lintian
Severity: minor
Hi
yet another nice check, that should issue a warning:
If something has a dependency against libssl* *and* has GPL in its
copyright file, issue a warning, if you can not also find one of the two
words exception or exemption. That hits about 99% of those cases,
On 11223 March 1977, Thijs Kinkhorst wrote:
In general, symbolic links within a top-level directory should be relative,
and symbolic links pointing from one top-level directory into another
should be absolute. (A top-level directory is a sub-directory of the root
directory /.)
I read that as
Package: lintian
Version: 1.23.34
Severity: normal
Hi
a simple W: for a package ending in -dbg thats not priority extra,
please. Thanks.
Maybe another W: for packages containing /usr/lib/debug/ and do not end
in -dbg.
--
bye Joerg
Some NM:
main contains software that compiles with DFSG.
Package: lintian
Severity: minor
Hi
another check found in linda but (afaik) not in lintian:
W: fooo; Package Recommends apel, which is also listed in Depends.
Ie - warning if something has stuff in recommends/suggests if its also
in depends. And warn if its in suggest but also in recommends.
Package: lintian
Version: 1.23.34
Severity: minor
Hi
Lintian should do basic Package is in right section checks and warn if
they arent. Like
*-doc - it should be section doc
python-* - section python
lib* - section libs, libdevel
etc. pp.
A pretty simple check (see linda for a possible way of
On 11212 March 1977, Russ Allbery wrote:
I plan to backport future versions too (and are subscribed to the PTS to
see uploads), so would *love* if you can, as long as possible, keep
lintian backporting such an easy task as its now. No changes needed,
just modifying the version in my changelog
Hi
just wanted to let you know that ftp-master.d.o is using a backported
lintian (since a few days already).
I plan to backport future versions too (and are subscribed to the PTS to
see uploads), so would *love* if you can, as long as possible, keep
lintian backporting such an easy task as its
Package: lintian
Version: 1.23.34
Severity: minor
Hi
a difference between linda and lintian that i would love to have in
lintian too (no lintian or linda overrides in the package):
lintian lives*.deb
W: lives: binary-or-shlib-defines-rpath ./usr/lib/lives/lives-exe /usr/lib
W: lives:
26 matches
Mail list logo
