tag 339829 + patch
usertag 339829 + sentpatch
thanks
I've attached a patch against lintian 1.23.14 that adds a check for the
correctness of the Homepage/webpage part of the package description. It
is by no means complete, but it is a reasonable check.
Basically it checks for one blank line, then
On Wed, 2006-01-04 at 09:33 -0500, Justin Pryzby wrote:
Packages for which this is a false-positive (such as slash, gnudip,
and bake)
These can be eliminated by checking for a url in the description too.
It reduces some true positives also: abcmidi, achims-guestbook,
airsnort,
On Thu, 2006-01-05 at 11:19 +0800, Paul Wise wrote:
I'll add the last-para instead of last-line change and then send an
updated patch.
Patch attached.
--
bye,
pabs
http://wiki.debian.org/PaulWise
lintian-1.23.14-check-homepage-in-description-field.patch.gz
Description: GNU Zip compressed
On Thu, 2006-01-05 at 14:59 -0500, Justin Pryzby wrote:
How about the attached combination check - does my check and also does
yours, with the changes that it checks a couple of other words, and
checks for a url in the description too.
$description =~
Package: lintian
Version: 1.23.14
Severity: normal
The description for lintian's menu-icon-not-in-xpm-format check needs to
be updated since it refers to section 3.4 of the menu policy, which does
not currently exist.
The alternative is to remove the check entirely, which seems
appropriate,
On Sat, 2006-01-21 at 15:03 -0800, Russ Allbery wrote:
Aha, so that is where it is. Well, lintian should probably make what it
is referring to more apparent, something like Debian Menu System 3.7.
It does currently say menu 3.7; does that still seem unclear to you?
To me, that suggested
Package: lintian
Version: 1.23.34
Severity: wishlist
Please add a check to search the .deb for windows thumbnail databases.
These are generally useless in Debian binary packages and just take up
space. They will be named Thumbs.db (or any variation in case) and
file reports that they are
Package: lintian
Version: 1.23.34
Severity: wishlist
Please detect .DS_Store files in binary and source packages. They are
generally not useful and just waste small amounts of space. More info:
http://en.wikipedia.org/wiki/.DS_Store
Packages containing these files:
album
On Sun, 2006-03-26 at 17:14 -0800, Russ Allbery wrote:
I really think the effort would be better spent standardizing an optional
URL field in Policy so that people can start using that, package build
tools can be updated where necessary to handle it, and package viewing and
installation tools
On Sun, 2007-10-14 at 17:36 -0700, Russ Allbery wrote:
If you do see ones with a variation in case, let me know.
The glest-data package contains the lowercased variation:
http://packages.debian.org/search?searchon=contentskeywords=Thumbs.dbmode=filenamesuite=unstablearch=any
--
bye,
pabs
Hi,
It would be nice to have some stats on lintian.d.o about how many (and
maybe which) source packages use each standards-version and how many use
a specific minor version of policy in their standards version (perhaps
that should be a lintian info/warning too).
--
bye,
pabs
Woops, wrong subject.
Initially I thought lintian.d.o wasn't checking arch all packages
because the PTS link for the chromium-data lintian report is wrong (dash
in place of underscore in the anchor). I'll following up to the
qa.debian.org bug about that.
--
bye,
pabs
Hi all,
I'm sponsoring ttf-khmeros, which produces a font udeb for d-i. The
latest ttf-khmeros update moved the homepage from the package
description to the new dpkg source package field. As a result, lintian
complains with I: ttf-khmeros-udeb udeb: unknown-field-in-control
homepage. Is this a
On Thu, 2008-01-03 at 17:59 -0800, Russ Allbery wrote:
I'd check with the d-i team and ask them their opinion. I'm happy to
modify lintian to match if needed.
Thanks for that.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
On Fri, 2008-01-04 at 10:30 +, Colin Watson wrote:
With my d-i hat on, I would certainly recommend not including the
Homepage field in udebs. It's not actually forbidden as such, but any
waste of space in udebs is frowned upon.
I thought as much.
I expect you could work around this by
Hi,
Does lintian check for and warn about versions like 1.2.3.dfsg1?
The reason it should is this:
1.2.3 1.2.3+dfsg1 1.2.3.4 1.2.3.dfsg1
My NM found that more packages use the dot variant (621) than use the +
variant (263).
I also wonder if lintian checks for dsfg (vs dfsg) in the
Package: lintian
Version: 1.23.45
Severity: normal
Currently the menu-command-not-in-package warning is output when the
menu file uses su-to-root. It should not do so, because su-to-root is
available in the menu package, so it will be available to everyone who
uses the menu item.
--
bye,
pabs
On Wed, 2008-02-20 at 10:07 -0800, Russ Allbery wrote:
There's code in lintian specifically to not do this, and running lintian
on two packages I have installed locally that use su-to-root in menus
(magicfilter and alsa-utils) doesn't produce that tag. Could you point me
at the package where
Package: lintian
Version: 1.23.45
Severity: wishlist
The password-gorilla package that I recently sponsored contains the
following files:
/usr/share/icons/hicolor/16x16/password-gorilla.png
/usr/share/icons/hicolor/32x32/password-gorilla.png
/usr/share/icons/hicolor/48x48/password-gorilla.png
On Sun, 2008-03-02 at 22:21 -0800, Russ Allbery wrote:
That only lists some of the subdirectories of your list (it's missing all
the stock/* ones) and doesn't use the same names (international instead of
intl, applications instead of apps). All of those seem like things that
could change on
Hi all,
The pkg-games-devel report seems to be broken, mancala shows warnings on
my page but not on the pkg-games-devel page:
http://lintian.debian.org/reports/full/[EMAIL PROTECTED]
http://lintian.debian.org/reports/full/[EMAIL PROTECTED]
Any thoughts?
--
bye,
pabs
Hi all,
Debian GNOME no longer shows the Debian menu by default, users have to
set the Debian item in the menu to visible to get it.
In my opinion the Debian-specific menu should be phased out in favour of
the cross-distro freedesktop menu, with a transition like what is
mentioned in #431118.
On Fri, 2008-04-25 at 19:42 -0700, Russ Allbery wrote:
I wish you the best of luck resolving this, but I'm not willing to touch
that debate with a ten-foot pole, given the flamewar that happened on
debian-devel the last time. (At least with my Lintian maintainer hat on;
it might be
On Fri, 2008-04-25 at 20:03 -0700, Russ Allbery wrote:
I think I've fixed this. There were various logic bugs in the HTML page
generation code introduced with the uploaders support. Thank you for the
report!
Hmm, seems that there is now a different bug.
This page shows mancala:
On Fri, 2008-04-25 at 20:35 -0700, Russ Allbery wrote:
I'm not sure why what I just changed fixed that, but it seems to have. I
think it's now okay.
Thanks.
One more minor issue, there is no anchor/id for packages where the
person is an Uploader rather than a Maintainer:
dtstrongmancala
On Fri, 2008-04-25 at 20:57 -0700, Russ Allbery wrote:
Right, that was intentional, since nothing linked to that for uploaders...
although I guess it wouldn't hurt to add anyway.
Thanks
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed
On Thu, 2008-05-01 at 00:43 +0200, Frank Lichtenheld wrote:
I'm still not sure that the original patch in this bug report (trying to
guess at whether a random URL found in the extended description should be
a homepage) is really a good idea.
I personally would vote for closing this bug.
Package: lintian
Version: 2.0.0
Severity: wishlist
rpmlint added checks for exit() or _exit() calls in shared libraries:
https://bugzilla.redhat.com/show_bug.cgi?id=450011
http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1448
I think this would be a useful addition to lintian.
--
bye,
pabs
Package: lintian
Version: 2.0.0
Severity: wishlist
Please warn about empty or whitespace-only files being listed in
debian/*docs when dh_installdocs is being used, or on the command-line
to the dh_installdocs command in debian/rules. Shipping useless files
in .debs should be discouraged. Please
On Sun, 2008-11-02 at 21:22 -0800, Russ Allbery wrote:
lintian already warns about empty files in the package in general, which
would seem to cover this. Do you have a specific example that we can look
at where this didn't work?
Ah. I was reviewing an RFS, but only ran lintian on the source
On Sun, 2008-11-02 at 21:21 -0800, Russ Allbery wrote:
I have some packages that would trigger this because the library uses
generic error handling routines that include functions that can call
exit() or _exit() but which are never called in practice. Ideally, that
dead code would be
Package: lintian
Version: 2.1.6
Severity: wishlist
swfobject.js is some JavaScript for using flash on the web. It is
currently duplicated in 3 packages in Debian (and one HTML version??):
http://packages.debian.org/search?suite=sidarch=anymode=filenamesearchon=contentskeywords=swfobject.js
I
Hi,
Is it possible to show comments from the override file on the web?
For example, /usr/share/lintian/overrides/apt contains this:
# apt-mark is rarely used auxiliary script, we don't want to depend on
# python-apt only for it.
apt binary: python-script-but-no-python-dep ./usr/bin/apt-mark
Package: lintian
Severity: wishlist
Is it possible to show comments from the override file on the web?
For example, /usr/share/lintian/overrides/apt contains this:
# apt-mark is rarely used auxiliary script, we don't want to depend on
# python-apt only for it.
apt binary:
On Sat, 2009-01-24 at 13:00 -0800, Russ Allbery wrote:
Paul Wise p...@debian.org writes:
Is it possible to show comments from the override file on the web?
It's possible but a bit complex to implement since it requires parsing the
comments out of the override file. Could you file a bug
Would it be possible to also detect duplicates of free fonts already in
Debian?
As you can see from here, there are a ton of Bitstream Vera duplicates
in Debian already (and these are just the ones with the same md5sum):
On Fri, 2009-01-30 at 16:57 +0900, Atomo64 wrote in IRC:
Atomo64 pabs: is it really needed to compare the md5 of the font
files as shipped by the ttf- package and the duplicates? or can it
just work like the current embedded-* checks? (i.e. by checking the
file name)
The name picks up most
Package: lintian
Severity: wishlist
Please check for *.ttf *.otf fonts in packages not named ttf-* and
otf-*. These fonts should be generally be packaged separately and
depended on because they are usually useful outside the package that
embeds them (often they are decorative fonts, which are
Package: lintian
Severity: wishlist
[I sent this to lintian-maint, filing a bug so it isn't forgotten]
I would like it if lintian warned about the following issues with
package version numbers:
1.2.3.dfsg1 (info/warning):
It should warn about this because of this:
1.2.3 1.2.3+dfsg1 1.2.3.4
On Tue, 2009-02-17 at 14:39 -0800, Russ Allbery wrote:
Could you comment on this from the Debian font team perspective? What's
the right thing to do in a case like this?
I can comment from my perspective (best suggestion at the top):
Firstly figure out what the font is doing in the package.
Package: lintian
Version: 2.2.5
Severity: wishlist
I was perusing the list of .swf (flash executables) files in the archive:
http://packages.debian.org/search?suite=sidsearchon=contentskeywords=.swf
I note the following files that should probably not be there and the
corresponding software
On Fri, 2009-02-20 at 11:51 +0900, Paul Wise wrote:
-
http://weblogs.macromedia.com/flashjavascript/readme.html
http://www.macromedia.com/go/flashjavascript
BSD-like: http://weblogs.macromedia.com/flashjavascript
On Thu, 2009-02-19 at 19:34 -0800, Russ Allbery wrote:
In this particular case, I think the best path forward would be to form a
Flash packaging group that takes as their mission packaging the common
code -- in other words, being proactive at developing the solution instead
of trying to push
Package: lintian
Version: 2.2.5
Severity: wishlist
I think *-patch-missing-description should mention more things and I
propose the following replacement text. The things I mention are very
useful for reducing divergence in cases where the Debian maintainer
hasn't done a very good job of
Hi all,
Should binary-from-other-architecture be emitted for i386 binaries in
amd64 packages where the package depends on the 32-bit versions of
libc/etc. For example, nsis isn't portable to !i386, upstream builds
with -m32 by default and I use that to give it to amd64 folks. Once
Debian has
On Mon, 2009-02-23 at 10:05 -0800, Russ Allbery wrote:
You should file a bug about this. I was expecting some problems along
those lines since it's a brand-new check. Looking for a dependency on
32-bit libc is a good way of detecting this case and avoiding it. Thanks!
Will do.
Also,
Package: lintian
Version: 2.2.6
Severity: normal
nsis on amd64 is built for i386 for portability issues. I can do this
because of libc6-i386, which is for running 32-bit apps on a 64-bit
system. Until Debian gets multi-arch support (hopefully for squeeze),
lintian should not warn about i386
Package: lintian
Version: 2.2.6
Severity: normal
NSIS contains the following architecture-specific files in /usr/share.
These are all binaries for Microsoft Windows built with the mingw32
cross-compiler we have in Debian. nsis is a tool to create installers
for Windows applications and so it
On Mon, 2009-02-23 at 18:16 -0800, Russ Allbery wrote:
It's not warning because they're not ELF, and those are the only types of
binaries that it warns about.
I figured as much.
Hm. I'm somewhat torn on this -- my guess was that whenever there are
non-ELF binaries in an
Package: lintian
Version: 2.2.6
Severity: wishlist
I recently found a package where upstream switched from tar.gz to
tar.bz2 and released a new upstream version. The debian/watch file for
that package didn't detect the new upstream version because it was
looking for tar.gz and upstream only
On Sun, 2009-03-01 at 12:23 +0900, Paul Wise wrote:
I think lintian should warn about this situation (and the
reverse) and suggest that both tar.gz and tar.bzip2 be checked for.
I forgot to mention that it should also check for tgz maybe tbz2/tbz.
The canonical watch regex for stuff
On Sun, 2009-03-01 at 12:39 +0900, Paul Wise wrote:
The canonical watch regex for stuff that currently detects only one or
two variants should probably be increased to something like this:
(tar|tar\.gz|tar\.bz2|tgz|tbz|tbz2)
Make that
(?:tar|tar\.gz|tar\.bz2|tgz|tbz|tbz2)
This ensures
On Sat, 2009-02-28 at 20:14 -0800, Russ Allbery wrote:
Hm, I've seen upstreams switch from .tar.gz to .tar.bz2, but I've not seen
one switch from .tar.gz to .tgz or vice versa. Maybe my experience is
just limited, though. I'd be very surprised to see any upstream go back
to a plain .tar
retitle 517637 [uscan] add an option to auto-generalise the search regex
reassign 517637 devscripts
thanks
On Sun, 2009-03-01 at 13:35 +0900, Paul Wise wrote:
Hmm, perhaps this should be a job for dehs or debexpo, which could run
uscan and be a bit smarter about checking the results
Hi all,
I've been thinking that it might be a good idea for lintian to not emit
the NMU warnings when the changelog has a Foo team upload message at
the beginning. I realise this would be a fairly major change for Debian.
It would make me much more comfortable doing more QA and more uploads
On Sun, 2009-04-05 at 12:54 -0700, Russ Allbery wrote:
I'm not sure what the drawback is to adding yourself to Uploaders. Could
you elaborate?
Well, it means that in various places I'll be marked as maintaining the
package rather than having done a once-off upload to bring the packaging
up to
On Sun, 2009-04-05 at 20:36 -0700, Russ Allbery wrote:
Hm. So it's sort of a team NMU -- you're not planning on taking ongoing
responsibility for the package except as just another member of the team.
Yeah, a team upload is a good way of putting it. You're uploading it as a
member of the
Package: lintian
Severity: minor
mat...@eisbox.net has no lintian complaints on his single package and
his lintian pages say that.
http://lintian.debian.org/maintainer/mat...@eisbox.net.html#libicns
http://lintian.debian.org/full/mat...@eisbox.net.html#libicns
Both pages link to the directory
I'd like to suggest that lintian should also warn about the reverse
situation (menu file but no desktop file). If the lintian maintainers
agree, please retitle this bug.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Package: lintian
Severity: wishlist
Some python-based applications use incorrect constructs in their
exception handling, which was reported in the following thread and
results in some exceptions not being handled properly.
http://lists.debian.org/debian-python/2010/08/msg1.html
In addition, I don't think the naming policy is yet ready for general
use. For example no-one commented on my question about foundries,
which I now think are a irrelevant in the package name, but might be
relevant in the package description.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
---
checks/binaries |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/checks/binaries b/checks/binaries
index 8c46be2..ebfb859 100644
--- a/checks/binaries
+++ b/checks/binaries
@@ -113,6 +113,9 @@ our %EMBEDDED_LIBRARIES = (
'openjpeg' = qr'tcd_decode:
Package: lintian
Severity: wishlist
In #628146 it was reported that desktop-base installs a 36x36
into /usr/share/icons/hicolor/48x48/emblems/ instead
of /usr/share/icons/hicolor/36x36/emblems/.
It would be good if lintian could check for these issues:
* images in the wrong
On Sun, 2011-06-05 at 13:11 +0200, Niels Thykier wrote:
I am not really sure what to say about the detection strings, except I
feel they seem very generic (but I could be wrong)[1]. With
embedded-library being an auto-reject tag now (about 45 minutes ago), I
think we have to be more careful
Hi all,
As a member of the Debian derivatives front desk (CCed) and initiator of
the derivatives census, which aims to make derivatives more visible to
Debian, I figured I should update lintian folks on the state of lintian
development and usage in Debian derivatives.
On Thu, Jul 7, 2011 at 12:49 AM, Geoffrey Thomas wrote:
We are the only one? I'm proud :-) We set that up about a year ago because
why not, but in practice, we've more been using Lintian output from the
package build process (debuild/sbuild) than the page, and making sure there
are no
On Thu, Jul 7, 2011 at 11:18 AM, Neil Williams wrote:
Lintian requires a lot of resources if it's to be run automatically
against an entire distribution.
Yeah. Also there is quite a bit of scope for expanding the range of
tests lintian performs, by running external checkers like cppcheck,
On Fri, Jul 8, 2011 at 9:25 AM, Stefano Zacchiroli wrote:
I haven't yet chosen the technology for code indexing, but if anyone has
experience with *multi-language* code indexers, I'd be happy to hear
from you. I've looked around a bit, but I've found good technologies
only for specific
On Fri, Jul 8, 2011 at 12:30 PM, Niels Thykier wrote:
We could do it like that, though the vendor profiles specification
actually deliberately did not answer the question of how to add
third-party checks. I know some people already do this, so we have made
Lintian behave sanely to it.
The
This is the new font naming policy for Debian.
---
data/files/fonts |2 +-
private/refresh-fonts-data |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/data/files/fonts b/data/files/fonts
index 69631a0..03da667 100644
--- a/data/files/fonts
+++
---
data/files/fonts | 463 ++
1 files changed, 324 insertions(+), 139 deletions(-)
diff --git a/data/files/fonts b/data/files/fonts
index 03da667..e211f7e 100644
--- a/data/files/fonts
+++ b/data/files/fonts
@@ -2,7 +2,7 @@
# package that
---
checks/cruft |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/checks/cruft b/checks/cruft
index 25ee03b..520e155 100644
--- a/checks/cruft
+++ b/checks/cruft
@@ -149,6 +149,8 @@ for my $file (keys(%$file_info)) {
tag 'source-contains-prebuilt-binary', $file;
Package: lintian
Severity: wishlist
Please detect and warn about *.chm files. The file program says these
are MS Windows HtmlHelp Data and they all begin with the 4 bytes
ITSF, which is the magic of the container format. CHM files are mainly
produced by proprietary, Windows-specific software.
Hi all,
One thing I see on debian-mentors a lot is a mismatch between the
default configuration of lintian (used by most new people) and the
configuration of people reviewing packages (much more verbose). This
comes up a lot, resulting in people needing to explain the difference a
lot and people
On Sat, 2012-01-21 at 22:02 -0800, Russ Allbery wrote:
I don't think this is a good idea. The reason why Lintian is conservative
about what it reports by default is because we know from past history that
people will not use it if they get too many tags that they think are
pointless or are
On Sat, 2012-01-21 at 23:02 -0800, Russ Allbery wrote:
Yeah, but that's in the middle of a rather long document. Given how
integral Lintian is to the mentoring process, I wonder if it would be good
to push it at people more directly on the pages they have to read to learn
how to upload. For
On Mon, 2012-01-23 at 13:04 +0100, Niels Thykier wrote:
On a related note, I plotted (part of) the data[1] we got on
debian-rules-missing-recommended-target tag[2]. The huge increase of
affected packages in the start can most likely be attributed to this
full-run[3].
The second spike
Package: lintian
Severity: wishlist
dh_make creates lines like this in debian/control by default:
#Vcs-Git: git://git.debian.org/collab-maint/pkg.git
#Vcs-Browser: http://git.debian.org/?p=collab-maint/pkg.git;a=summary
I think lintian should check for these lines and warn if they are still
Package: lintian
Severity: wishlist
It would be very nice if lintian could have detected this situation:
http://lwn.net/Articles/453970/
This would need a mechanism to check for generated files that are
missing source files. This bug isn't about any specific type of missing
source, but I have
Package: lintian
Version: 2.5.10.1
Severity: wishlist
glib from experimental removed the patch that disabled warnings about
deprecated gsettings schema paths, leading to warnings like these in
during upgrade:
Processing triggers for libglib2.0-0:amd64 ...
warning: Schema
Package: lintian
Severity: wishlist
Please add a check for duplicated translation data. By duplicated
translation data I mean the same translation data in multiple formats.
This happens when both the source and binary forms of translation data
are shipped in binary packages. The source forms of
On Sat, Sep 15, 2012 at 5:03 AM, Hideki Yamane wrote:
It has watch results and show version number with pink color if upstream
released newer version than Debian package. However, if upstream uses
github and sometimes watch file is check just its master branch in git
(without enough
Package: lintian
Version: 2.5.10.2
Severity: wishlist
User: debian-...@lists.debian.org
Usertags: arm64
X-Debbugs-CC: debian-...@lists.debian.org
Please encourage updating to config.guess and config.sub that support
arm64. The GNU name for arm64 is aarch64. aarch64 was added to
On Sun, Dec 30, 2012 at 4:09 AM, Niels Thykier wrote:
As far as I know, Lintian exports a file called qa-list.txt for
consumption by the QA infrastructure. Particularly I suspect that the
PTS and the DDPO consumes this file to display the relevant TODO
item/column. If anyone is aware of any
On Sun, Dec 30, 2012 at 5:16 PM, Stefano Zacchiroli wrote:
Looks like the two formats are easily mechanically distinguishable: the
That part is easy but I was not thinking about it, but about how the
PTS should present the lintian data.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To
Package: lintian
Version: 2.5.11
Severity: wishlist
dpkg-source on squeeze and earlier errors out when one of the
dpkg-source 3.0 (quilt) patches modifies one file twice. With
dpkg-source on wheezy and later this becomes a warning instead. I've
encountered this issue while unpacking source
Package: lintian
Version: 2.5.11
Severity: wishlist
dpkg-source is not able (#645157) to properly handle source packages
with relative/absolute symlinks that point outside of the package. It
would be good if lintian could detect this situation and give an error.
lintian should check both the
On Sun, Jan 13, 2013 at 5:14 PM, Niels Thykier wrote:
Are there any news on the PTS side? DDPO has been fixed already, so to
my knowledge we are currently just waiting for the PTS.
Still discussing how the data should be presented AFAICS. What do the
lintian maintainers think? Should the
On Sun, Jan 13, 2013 at 6:15 PM, Paul Wise wrote:
Still discussing how the data should be presented AFAICS. What do the
lintian maintainers think? Should the links remain as they are and
point at data for unstable only?
Bart suggested off-list to just keep things as-is for now and deal
In addition, the various other compression formats include test options:
find -type f -iname \*.bz2 -print0 | xargs --no-run-if-empty --null bzip2 --test
find -type f -iname \*.xz -print0 | xargs --no-run-if-empty --null xz --test
find -type f -iname \*.zip -print0 | xargs --no-run-if-empty
---
data/spelling/corrections-case | 3 +++
1 file changed, 3 insertions(+)
diff --git a/data/spelling/corrections-case b/data/spelling/corrections-case
index 20507f0..03a2700 100644
--- a/data/spelling/corrections-case
+++ b/data/spelling/corrections-case
@@ -54,6 +54,9 @@ ocaml||OCaml
Package: lintian
Severity: wishlist
Vcs-Browser URLs of this form give HTTP 400 Bad Request, due to
the ?op=log at the end. lintian should warn about them and not output
the problematic part in the output of the other vcs-* tags. This is
another unhandled part of the alioth transition a while
Package: lintian
Severity: wishlist
It would be nice to have some examples for third-party checks. As an
example, for the last few uploads I forgot to add debian/upstream files
and I would like to remind myself for future uploads that they are
missing. This is obviously not yet suitable for an
Package: lintian
Severity: wishlist
From [1]:
- Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file. You are advised to start using the
recommended name 'configure.ac' instead, ASAP.
I would suggest the following plan for Debian
Package: lintian
Severity: wishlist
We have some packages in the archive that have a Maintainer: field that
starts with 'Maintainer: '. I think it would be good if lintian could
detect this and similar situations where the field value starts with the
field name and a colon. Here are some examples
Package: lintian
Version: 2.5.19
Severity: wishlist
Please add a pedantic level warning about git related files or the
compressed versions of these that are not useful in binary packages.
This is the current list of packages containing these useless files:
pabs@chianamo ~ $ apt-file -x search
On Fri, 2013-12-27 at 23:57 +, bastien ROUCARIES wrote:
I have implemented the machinery to check non free file by md5.
Excellent.
I need md5sum, sha1, sha256, a usual filename, a reason, and a more info link.
Hopefully this is enough info:
Lets start with Microsoft's core fonts for the
Package: lintian
Severity: wishlist
There are some problematic copyright format 1.0 license statements in
the archive. The most common is UNKNOWN, sometimes with FIXME as the
full license but sometimes completely blank. In one file UNKNOWN is
defined as No information available about the license
Package: lintian
Severity: wishlist
Please add a warning for overrides where there is no comment before them
explaining the situation leading to the override. See also #512901 and
#474590 for related lintian bug reports.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description:
Package: lintian
Severity: wishlist
Please add a privacy breach check for twitter follow buttons. Here is an
example from the awstats project (see #738101 for related discussion).
!-- twitter --
a href=https://twitter.com/awstats_project; class=twitter-follow-button
data-show-count=falseFollow
1 - 100 of 796 matches
Mail list logo
