Lintian/Tags/Template

Lintian tags - hints and tips

Feel free to contribute and share your hints and tips.

Include: Nothing found for "^Self:@PAGE@"!

Include: Nothing found for "^##END:@PAGE@$"!

This page contains some data that are automatically imported, and used in pages:

Lintian/Tags

To refresh this page with the latest lintian tags, simply grab the python script below. The script will generate this wiki page using your local copy of lintian. Just copy and paste the generated page into this page.

Last updated with:

```
lintian (2.4.3) unstable; urgency=low
```

conffiles

?Lintian/Tags/file-in-usr-marked-as-conffile

Lintian tag file-in-usr-marked-as-conffile:

All configuration files must reside in /etc. Files below /usr may not be marked as conffiles since /usr might be mounted read-only. The local system administrator would therefore not have a chance to modify this configuration file.

Reference(s): policy 10.7.2

?Lintian/Tags/non-etc-file-marked-as-conffile

Lintian tag non-etc-file-marked-as-conffile:

A file installed in some other directory than /etc is marked as conffile. A conffile typically implies a configuration file, and Policy mandates such files to be in /etc.

Reference(s): policy 10.7.2

?Lintian/Tags/relative-conffile

Lintian tag relative-conffile:

All entries in the debian/conffiles control file should have an absolute path specification.

Reference(s): policy E.1

?Lintian/Tags/duplicate-conffile

Lintian tag duplicate-conffile:

The file is listed more than once in your debian/conffiles file. Usually, this is because debhelper (dh_installdeb, compat level 3 or higher) will add any files in your package located in /etc automatically to the list of conffiles, so if you do that manually too, you'll get duplicates.

files

?Lintian/Tags/package-contains-ancient-file

Lintian tag package-contains-ancient-file:

Your package contains a file that claims to have been generated more than 20 years ago. This is most probably an error. Your package will be rejected by the Debian archive scripts if it contains a file with such a timestamp.

?Lintian/Tags/old-app-defaults-directory

Lintian tag old-app-defaults-directory:

The app-defaults files have moved to /etc/X11/app-defaults/. Files in the old directory, /usr/X11R6/lib/X11/app-defaults/, will no longer be used by X. The old directory should not exist in packages at all; this prevents X from replacing it with a compatibility symlink.

Reference(s): policy 11.8.6

?Lintian/Tags/package-installs-font-to-usr-x11r6

Lintian tag package-installs-font-to-usr-x11r6:

The standard location for X fonts has moved to /usr/share/fonts/X11. Packages providing X fonts must install them into the new path. Fonts installed into the old /usr/X11R6/lib/X11/fonts path may not be seen by the X server.
If the package uses imake, it must build-depend on xutils-dev (>= 1:1.0.2-2) for the correct paths. If it uses dh_installxfonts to handle X font installation, it must build-depend on debhelper (>= 5.0.31).

Reference(s): policy 11.8.5

?Lintian/Tags/package-installs-file-to-usr-x11r6-bin

Lintian tag package-installs-file-to-usr-x11r6-bin:

Debian has switched to the modular X tree which now uses the regular FHS paths, and all packages must follow. All packages installing binaries must install them into /usr/bin (or some other appropriate location) instead of /usr/X11R6/bin. The x11-common package attempts to change /usr/X11R6/bin into a symlink to /usr/bin, so if this migration has already occurred, a package installing files into /usr/X11R6/bin may appear to install successfully. However, such a package will be left in an inconsistent state and may orphan files when the compatibility link goes away.
If the package uses imake, it must build-depend on xutils-dev (>= 1:1.0.2-2) for the correct paths.

Reference(s): policy 11.8.7

?Lintian/Tags/package-installs-file-to-usr-x11r6

Lintian tag package-installs-file-to-usr-x11r6:

Packages using the X Window System should not be configured to install files under the /usr/X11R6/ directory. Debian has switched to the modular X tree which now uses regular FHS paths and all packages should follow.
Programs that use GNU autoconf and automake are usually easily configured at compile time to use /usr/ instead of /usr/X11R6/. Packages that use imake must build-depend on xutils-dev (>= 1:1.0.2-2) for the correct paths.

Reference(s): policy 11.8.7

?Lintian/Tags/config-file-reserved

Lintian tag config-file-reserved:

This file is reserved by a specific package. Please email the maintainer of the package in question if you have questions.

?Lintian/Tags/package-uses-obsolete-file

Lintian tag package-uses-obsolete-file:

the file, /etc/nntpserver, is no longer recommenced. As of policy revision 2.5.1.0, /etc/news/server is the preferred file to use to specify a news server.

Reference(s): policy 11.7

?Lintian/Tags/FSSTND-dir-in-usr

Lintian tag FSSTND-dir-in-usr:

As of policy version 3.0.0.0, Debian no longer follows the FSSTND. Instead, the Filesystem Hierarchy Standard (FHS), version 2.3, is used. You can find it in /usr/share/doc/debian-policy/fhs/ .

Reference(s): policy 9.1.1

?Lintian/Tags/FSSTND-dir-in-var

Lintian tag FSSTND-dir-in-var:

As of policy version 3.0.0.0, Debian no longer follows the FSSTND. Instead, the Filesystem Hierarchy Standard (FHS), version 2.3, is used. You can find it in /usr/share/doc/debian-policy/fhs/ .

Reference(s): policy 9.1.1

?Lintian/Tags/package-installs-into-etc-gconf-schemas

Lintian tag package-installs-into-etc-gconf-schemas:

The package installs files into the /etc/gconf/schemas directory. No package should do this; this directory is reserved for local overrides. Instead, schemas should be installed into /usr/share/gconf/schemas.

?Lintian/Tags/package-installs-into-etc-rc.d

Lintian tag package-installs-into-etc-rc.d:

The package installs files into the /etc/rc.d or /etc/rc?.d which is not allowed.

Reference(s): policy 9.3.3

?Lintian/Tags/package-installs-into-etc-rc.boot

Lintian tag package-installs-into-etc-rc.boot:

The package installs files in the /etc/rc.boot directory, which is obsolete. See rc.boot(5) for details.

Reference(s): policy 9.3.4

?Lintian/Tags/non-standard-file-permissions-for-etc-init.d-script

Lintian tag non-standard-file-permissions-for-etc-init.d-script:

Usually, scripts in the /etc/init.d directory should have mode 0755.

?Lintian/Tags/file-directly-in-usr-share

Lintian tag file-directly-in-usr-share:

Packages should not install files directly in /usr/share, i.e., without a subdirectory.
You should either create a subdirectory /usr/share/... for your package or place the file in /usr/share/misc.

?Lintian/Tags/file-in-usr-local

Lintian tag file-in-usr-local:

The package installs a file in /usr/local/... which is not allowed.

Reference(s): policy 9.1.2

?Lintian/Tags/stray-directory-in-manpage-directory

Lintian tag stray-directory-in-manpage-directory:

This package installs a directory under /usr/share/man or /usr/X11R6/man that isn't a manual section directory or locale directory.

Reference(s): fhs usrsharemanmanualpages

?Lintian/Tags/executable-manpage

Lintian tag executable-manpage:

Manual pages are not meant to be executed.

?Lintian/Tags/dir-in-usr-local

Lintian tag dir-in-usr-local:

The package installs a directory in /usr/local/... which is not allowed.
If you want to provide an empty directory in /usr/local for convenience of the local system administrator, please follow the rules in the policy manual (section 9.1.2), i.e., create the directories in the postinst script but don't fail if this isn't possible (e.g., if /usr/local is mounted read-only).

Reference(s): policy 9.1.2

?Lintian/Tags/non-standard-dir-perm

Lintian tag non-standard-dir-perm:

The directory has a mode different from 0755, and it's not one of the known exceptions.

Reference(s): policy 10.9

?Lintian/Tags/executable-is-not-world-readable

Lintian tag executable-is-not-world-readable:

All executables should be readable by any user. Since anyone can download the Debian package and obtain a copy of the executable, no security is gained by making the executable unreadable even for setuid binaries. If only members of a certain group may execute this file, remove execute permission for world, but leave read permission.

Reference(s): policy 10.9

?Lintian/Tags/non-standard-executable-perm

Lintian tag non-standard-executable-perm:

Executables that are not setuid or setgid should always have a mode of 0755. Since anyone can obtain the executable by downloading the Debian package and extracting it, restricting access serves little purpose.

Reference(s): policy 10.9

?Lintian/Tags/non-standard-game-executable-perm

Lintian tag non-standard-game-executable-perm:

The file is owned by the games group but is not mode 2755. If a game does not have to be setgid games, it should be owned by the root group like any other executable. This executable is either owned by the wrong group or is not setgid when it should be.

Reference(s): policy 11.11

?Lintian/Tags/non-standard-setuid-executable-perm

Lintian tag non-standard-setuid-executable-perm:

The file is setuid or setgid and has a mode different from any of 2755, 4755, 4754, or 6755. Any other permissions on setuid executables is probably a bug. In particular, removing root write privileges serves no purpose, group-writable setuid or setgid executables are probably bad ideas, and setgid executables that are not world-executable serve little purpose.

Reference(s): policy 10.9

?Lintian/Tags/setuid-binary

Lintian tag setuid-binary:

The file is tagged SETUID. In some cases this is intentional, but in other cases this is a bug. If this is intentional, please add a lintian override to document this fact.

?Lintian/Tags/setgid-binary

Lintian tag setgid-binary:

The file is tagged SETGID. In some cases this is intentional, but in other cases this is a bug. If this is intentional, please add a lintian override to document this fact.

?Lintian/Tags/setuid-gid-binary

Lintian tag setuid-gid-binary:

The file is tagged SETUID and SETGID. In some cases this is intentional, but in other cases this is a bug. If this is intentional, please add a lintian override to document this fact.

?Lintian/Tags/non-standard-file-perm

Lintian tag non-standard-file-perm:

The file has a mode different from 0644. In some cases this is intentional, but in other cases this is a bug.

Reference(s): policy 10.9

?Lintian/Tags/special-file

Lintian tag special-file:

The package contains a special file (e.g., a device file). This is forbidden by current policy. If your program needs this device, you should create it by calling makedev from the postinst script.

Reference(s): policy 10.6

?Lintian/Tags/old-style-example-dir

Lintian tag old-style-example-dir:

The package installs some files into the old /usr/doc/examples directory. The new location for examples is /usr/share/doc/pkg/examples.

Reference(s): policy 12.6

?Lintian/Tags/compressed-symlink-with-wrong-ext

Lintian tag compressed-symlink-with-wrong-ext:

The package installs a symbolic link pointing to a compressed file, but the symbolic link does not use the same file extension than the referenced file. In most cases, this can produce troubles when the user or a program tries to access the file through the link.

Reference(s): policy 10.5

?Lintian/Tags/symlink-has-double-slash

Lintian tag symlink-has-double-slash:

This symlink contains two successive slashes (//). This is in violation of policy, where it is stated that symlinks should be as short as possible If you use debhelper, running dh_link after creating the package structure will fix this problem for you.

Reference(s): policy 10.5

?Lintian/Tags/symlink-ends-with-slash

Lintian tag symlink-ends-with-slash:

This symlink ends with a slash (/). This is in violation of policy, where it is stated that symlinks should be as short as possible If you use debhelper, running dh_link after creating the package structure will fix this problem for you.

Reference(s): policy 10.5

?Lintian/Tags/symlink-should-be-relative

Lintian tag symlink-should-be-relative:

Symlinks to files which are in the same top-level directory should be relative according to policy. (In other words, a link in /usr to another file in /usr should be relative, while a link in /usr to a file in /etc should be absolute.) If you use debhelper, running dh_link after creating the package structure will fix this problem for you.

Reference(s): policy 10.5

?Lintian/Tags/symlink-should-be-absolute

Lintian tag symlink-should-be-absolute:

Symbolic links between different top-level directories should be absolute. If you use debhelper, running dh_link after creating the package structure will fix this problem for you.

Reference(s): policy 10.5

?Lintian/Tags/udeb-contains-documentation-file

Lintian tag udeb-contains-documentation-file:

udeb packages should not contain any documentation.

?Lintian/Tags/executable-in-usr-share-doc

Lintian tag executable-in-usr-share-doc:

Usually, documentation files in /usr/share/doc should have mode 0644. If the executable is an example, it should go in /usr/share/doc/pkg/examples.

?Lintian/Tags/script-in-usr-share-doc

Lintian tag script-in-usr-share-doc:

Scripts are usually not documentation files, unless they are examples, in which case they should be in the /usr/share/doc/pkg/examples directory.

?Lintian/Tags/symlink-has-too-many-up-segments

Lintian tag symlink-has-too-many-up-segments:

The symlink references a directory beyond the root directory "/".

Reference(s): policy 10.5

?Lintian/Tags/lengthy-symlink

Lintian tag lengthy-symlink:

This link goes up, and then back down into the same subdirectory. Making it shorter will improve its chances of finding the right file if the user's system has lots of symlinked directories. If you use debhelper, running dh_link after creating the package structure will fix this problem for you.

Reference(s): policy 10.5

?Lintian/Tags/symlink-is-self-recursive

Lintian tag symlink-is-self-recursive:

The symbolic link is recursive to a higher directory of the symlink itself. This means, that you can infinitely chdir with this symlink. This is usually not okay, but sometimes wanted behaviour.

?Lintian/Tags/symlink-contains-spurious-segments

Lintian tag symlink-contains-spurious-segments:

The symbolic link has needless segments like ".." and "." in the middle. These are unneeded and make the link longer than it could be, which is in violation of policy. They can also cause problems in the presence of symlinked directories. If you use debhelper, running dh_link after creating the package structure will fix this problem for you.

Reference(s): policy 10.5

?Lintian/Tags/run-parts-cron-filename-contains-full-stop

Lintian tag run-parts-cron-filename-contains-full-stop:

The script in /etc/cron.<time-interval> will not be executed by run-parts(8) because the filename contains a "." (full stop).

Reference(s): run-parts(8)

?Lintian/Tags/bad-permissions-for-etc-cron.d-script

Lintian tag bad-permissions-for-etc-cron.d-script:

Files in /etc/cron.d are configuration files for cron and not scripts. Thus, they should not be marked executable.

?Lintian/Tags/bad-permissions-for-etc-emacs-script

Lintian tag bad-permissions-for-etc-emacs-script:

Files in the /etc/emacs* directories should not be marked executable.

?Lintian/Tags/image-file-in-usr-lib

Lintian tag image-file-in-usr-lib:

This package installs a pixmap or a bitmap within /usr/lib. According to the Filesystem Hierarchy Standard, architecture-independent files need to be placed within /usr/share instead.

?Lintian/Tags/file-directly-in-usr-share-doc

Lintian tag file-directly-in-usr-share-doc:

Documentation files have to be installed in /usr/share/doc/pkg.

Reference(s): policy 12.3

?Lintian/Tags/bad-owner-for-doc-file

Lintian tag bad-owner-for-doc-file:

Documentation files should be owned by root/root.

?Lintian/Tags/dir-or-file-in-var-lock

Lintian tag dir-or-file-in-var-lock:

/var/lock may be a temporary filesystem, so any directories or files needed there must be created dynamically at boot time.

Reference(s): policy 9.3.2

?Lintian/Tags/dir-or-file-in-var-run

Lintian tag dir-or-file-in-var-run:

/var/run may be a temporary filesystem, so any directories or files needed there must be created dynamically at boot time.

Reference(s): policy 9.3.2

?Lintian/Tags/dir-or-file-in-var-www

Lintian tag dir-or-file-in-var-www:

Debian packages should not install files under /var/www. This is not one of the /var directories in the File Hierarchy Standard and is under the control of the local administrator. Packages should not assume that it is the document root for a web server; it is very common for users to change the default document root and packages should not assume that users will keep any particular setting. Packages that want to make files available via an installed web server should instead put instructions for the local administrator in a README.Debian file and ideally include configuration fragments for common web servers such as Apache.
As an exception, packages are permitted to create the /var/www directory due to its past history as the default document root, but should at most copy over a default file in postinst for a new install. In this case, please add a Lintian override.

Reference(s): fhs thevarhierarchy

?Lintian/Tags/dir-or-file-in-tmp

Lintian tag dir-or-file-in-tmp:

Packages must not install files into /tmp or /var/tmp. The File Hierarchy Standard specifies that such files may be removed by the administrator and that programs may not depend on any files in /tmp being preserved across invocations, which combined mean that it makes no sense to ship files in these directories.

Reference(s): fhs tmptemporaryfiles, fhs vartmptemporaryfilespreservedbetwee

?Lintian/Tags/dir-or-file-in-mnt

Lintian tag dir-or-file-in-mnt:

Packages should not install into /mnt. The FHS states that this directory is reserved for the local system administrator for temporary mounts and that it must not be used by installation programs.

Reference(s): fhs mntmountpointforatemporarilymount

?Lintian/Tags/dir-or-file-in-opt

Lintian tag dir-or-file-in-opt:

Debian packages should not install into /opt, because it is reserved for add-on software.

Reference(s): fhs optaddonapplicationsoftwarepackages

?Lintian/Tags/dir-or-file-in-srv

Lintian tag dir-or-file-in-srv:

Debian packages should not install into /srv. The specification of /srv states that its structure is at the discretion of the local administrator and no package should rely on any particular structure. Debian packages that install files directly into /srv can't adjust for local policy about its structure and in essence force a particular structure.
If a package wishes to put its data in /srv, it must do this in a way that allows the local administrator to specify and preserve their chosen directory structure (such as through post-install configuration, setup scripts, debconf prompting, etc.).

Reference(s): fhs srvdataforservicesprovidedbysystem

?Lintian/Tags/third-party-package-in-python-dir

Lintian tag third-party-package-in-python-dir:

Third-party Python packages should install their files in /usr/lib/pythonVERSION/site-packages for Python versions before 2.6 and /usr/lib/pythonVERSION/dist-packages for Python 2.6 and later. All other directories in /usr/lib/pythonVERSION are for use by the core python packages.

?Lintian/Tags/perl-module-in-core-directory

Lintian tag perl-module-in-core-directory:

Packaged modules must not be installed into the core perl directories as those directories change with each upstream perl revision. The vendor directories are provided for this purpose.

Reference(s): perl-policy 3.1

?Lintian/Tags/backup-file-in-package

Lintian tag backup-file-in-package:

There is a file in the package whose name matches the format emacs or vim uses for backup and autosave files. It may have been installed by accident.

?Lintian/Tags/nfs-temporary-file-in-package

Lintian tag nfs-temporary-file-in-package:

There is a file in the package whose name matches the format NFS uses to temporarily save files that were deleted while another process had them open. It may have been included in the package by accident while building the package in an NFS filesystem.

?Lintian/Tags/windows-thumbnail-database-in-package

Lintian tag windows-thumbnail-database-in-package:

There is a file in the package named Thumbs.db or Thumbs.db.gz, which is normally a Windows image thumbnail database. Such databases are generally useless in Debian packages and were usually accidentally included by copying complete directories from the source tarball.

?Lintian/Tags/macos-ds-store-file-in-package

Lintian tag macos-ds-store-file-in-package:

There is a file in the package named .DS_Store or .DS_Store.gz, the file name used by Mac OS X to store folder attributes. Such files are generally useless in Debian packages and were usually accidentally included by copying complete directories from the source tarball.

?Lintian/Tags/macos-resource-fork-file-in-package

Lintian tag macos-resource-fork-file-in-package:

There is a file in the package with a name starting with ._, the file name pattern used by Mac OS X to store resource forks in non-native file systems. Such files are generally useless in Debian packages and were usually accidentally included by copying complete directories from the source tarball.

?Lintian/Tags/package-installs-perllocal-pod

Lintian tag package-installs-perllocal-pod:

This package installs a file perllocal.pod. Since that file is intended for local documentation, it is not likely that it is a good place for documentation supplied by a Debian package. In fact, installing this package will wipe out whatever local documentation existed there.

?Lintian/Tags/extra-license-file

Lintian tag extra-license-file:

All license information should be collected in the debian/copyright file. This usually makes it unnecessary for the package to install this information in other places as well.

Reference(s): policy 12.5

?Lintian/Tags/non-standard-toplevel-dir

Lintian tag non-standard-toplevel-dir:

The Filesystem Hierarchy Standard forbids the installation of new files or directories in the root directory.

Reference(s): fhs therootfilesystem

?Lintian/Tags/subdir-in-bin

Lintian tag subdir-in-bin:

The Filesystem Hierarchy Standard forbids the installation of new directories in /bin.

Reference(s): fhs binessentialusercommandbinaries

?Lintian/Tags/subdir-in-usr-bin

Lintian tag subdir-in-usr-bin:

The Filesystem Hierarchy Standard forbids the installation of new directories in /usr/bin other than /usr/bin/mh.

Reference(s): fhs usrbinmostusercommands

?Lintian/Tags/non-standard-dir-in-usr

Lintian tag non-standard-dir-in-usr:

The FHS says "No large software packages should use a direct subdirectory under the /usr hierarchy". This package contains a directory in /usr that is not mentioned in the Filesystem Hierarchy Standard.

Reference(s): fhs theusrhierarchy

?Lintian/Tags/non-standard-dir-in-var

Lintian tag non-standard-dir-in-var:

The FHS says "Applications should generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list."

Reference(s): fhs thevarhierarchy

?Lintian/Tags/use-of-compat-symlink

Lintian tag use-of-compat-symlink:

This package uses a directory that, according to the Filesystem Hierarchy Standard, should exist only as a compatibility symlink. Packages should not traverse such symlinks when installing files, they should use the standard directories instead.

?Lintian/Tags/file-in-unusual-dir

Lintian tag file-in-unusual-dir:

This file or symbolic link is in a directory where files are not normally installed by Debian packages.

?Lintian/Tags/package-installs-packlist

Lintian tag package-installs-packlist:

Packages built using the perl ?MakeMaker package will have a file named .packlist in them. Those files are useless, and (in some cases) have the additional problem of creating an architecture-specific directory name in an architecture-independent package.
They can be suppressed by adding the following to debian/rules:
- find debian/pkg -type f -name .packlist | xargs rm -f
or by telling ?MakeMaker to use vendor install dirs; consult a recent version of Perl policy. Perl 5.6.0-12 or higher supports this.

Reference(s): perl-policy 4.1

?Lintian/Tags/zero-byte-file-in-doc-directory

Lintian tag zero-byte-file-in-doc-directory:

The documentation directory for this package contains an empty file. This is often due to installing an upstream NEWS or README file without realizing it's empty and hence not useful. Files in the examples subdirectory are excluded from this check, but there are some cases where empty files are legitimate parts of the documentation without being examples. In those cases, please add an override.

?Lintian/Tags/override-file-in-wrong-location

Lintian tag override-file-in-wrong-location:

Lintian overrides should be put in a regular file named /usr/share/lintian/overrides/package, not in a subdirectory named for the package or in the obsolete location under /usr/share/doc. See the Lintian documentation for more information on proper naming and format.

Reference(s): lintian 2.4

?Lintian/Tags/package-contains-upstream-install-documentation

Lintian tag package-contains-upstream-install-documentation:

Binary packages do not need to contain the instructions for building and installing the package as this info is not needed by package users. If the info contained is important for configuration perhaps it could be summarized in README.Debian, otherwise an override may be added.

Reference(s): policy 12.3

?Lintian/Tags/package-contains-hardlink

Lintian tag package-contains-hardlink:

The package contains a hardlink in /etc or across different directories. This might not work at all if directories are on different filesystems (which can happen anytime as the system administrator sees fit), certain filesystems such as AFS don't even support cross-directory hardlinks at all. For configuration files, certain editors might break hardlinks, and so does dpkg in certain cases. A better solution might be using symlinks here.

Reference(s): policy 10.7.3

?Lintian/Tags/package-contains-bts-control-dir

Lintian tag package-contains-bts-control-dir:

The package contains a control directory for a bug tracking system. It was most likely installed by accident, since bug tracking directories usually don't belong in packages.

?Lintian/Tags/package-contains-vcs-control-dir

Lintian tag package-contains-vcs-control-dir:

The package contains a control directory for a version control system. It was most likely installed by accident, since version control directories usually don't belong in packages.

?Lintian/Tags/package-contains-xvpics-dir

Lintian tag package-contains-xvpics-dir:

Package contains a .xvpics directory. It was most likely installed by accident, since thumbnails usually don't belong in packages.

?Lintian/Tags/package-contains-vcs-control-file

Lintian tag package-contains-vcs-control-file:

The package contains a VCS control file such as .(cvs|git|hg)ignore. Files such as these are used by revision control systems to, for example, specify untracked files it should ignore or inventory files. This file is generally useless in an installed package and was probably installed by accident.

?Lintian/Tags/svn-commit-file-in-package

Lintian tag svn-commit-file-in-package:

The package contains an svn-commit(.NNN).tmp file. This file is almost certainly a left-over from a failed Subversion commit, and does not belong in a Debian package.

?Lintian/Tags/svk-commit-file-in-package

Lintian tag svk-commit-file-in-package:

The package contains an svk-commitNNN.tmp file. This file is almost certainly a left-over from a failed Subversion commit, and does not belong in a Debian package.

?Lintian/Tags/nested-examples-directory

Lintian tag nested-examples-directory:

Package contains a usr/share/doc/something/examples/examples directory. It was most likely installed by accident, since one examples/ directory should be enough for everybody(tm).

?Lintian/Tags/package-installs-nonbinary-perl-in-usr-lib-perl5

Lintian tag package-installs-nonbinary-perl-in-usr-lib-perl5:

Architecture-independent Perl code should be placed in /usr/share/perl5, not /usr/lib/perl5 unless there is at least one architecture-dependent file in the module.

Reference(s): perl-policy 2.3

?Lintian/Tags/file-in-usr-lib-site-python

Lintian tag file-in-usr-lib-site-python:

The directory /usr/lib/site-python has been deprecated as a location for installing Python modules and may be dropped from Python's module search path in a future version. Most likely this module is a private module and should be packaged in a directory outside of Python's default search path.

Reference(s): python-policy 1.5

?Lintian/Tags/package-installs-python-pyc

Lintian tag package-installs-python-pyc:

Compiled python source files must not be included in the package. These files should be removed from the package and created at package installation time in the postinst.

?Lintian/Tags/bad-permissions-for-ali-file

Lintian tag bad-permissions-for-ali-file:

Ada Library Information (*.ali) files are required to be read-only (mode 0444) by GNAT. If at least one user can write the *.ali file, GNAT considers whether or not to recompile the corresponding source file. Such recompilation would fail because normal users don't have write permission on the files. Moreover, such recompilation would defeat the purpose of library packages, which provide *.a and *.so libraries to link against).

Reference(s): policy 8.4

?Lintian/Tags/package-contains-readme-for-other-platform-or-distro

Lintian tag package-contains-readme-for-other-platform-or-distro:

package contains a README.(platform) file that contains instructions specific to a platform or distribution other than Debian and thus can most likely be removed. If it contains information that pertains to Debian, please consider renaming it, or including it in an already existing README file.

?Lintian/Tags/desktop-file-in-wrong-dir

Lintian tag desktop-file-in-wrong-dir:

The package contains a .desktop file in an obsolete directory. According to the menu-spec draft on freedesktop.org, those .desktop files that are intended to create a menu should be placed in /usr/share/applications, not /usr/share/gnome/apps.

?Lintian/Tags/script-with-language-extension

Lintian tag script-with-language-extension:

When scripts are installed into a directory in the system PATH, the script name should not include an extension such as .sh or .pl that denotes the scripting language currently used to implement it. The implementation language may change; if it does, leaving the name the same would be confusing and changing it would be disruptive.

Reference(s): policy 10.4

?Lintian/Tags/file-in-usr-lib-sgml

Lintian tag file-in-usr-lib-sgml:

This package installs a file in /usr/lib/sgml. This was the old location for SGML catalogs and similar flies. All those files should now go into /usr/share/sgml.

Reference(s): fhs theusrhierarchy

?Lintian/Tags/file-name-ends-in-whitespace

Lintian tag file-name-ends-in-whitespace:

This package installs a file or directory whose name ends in whitespace. This might be intentional but it's normally a mistake. If it is intentional, add a lintian override. One possible cause is using debhelper 5.0.57 or earlier to install a doc-base file with a Document field that ends in whitespace.

?Lintian/Tags/package-contains-empty-directory

Lintian tag package-contains-empty-directory:

This package installs an empty directory. This might be intentional but it's normally a mistake. If it is intentional, add a lintian override. If a package ships with or installs empty directories, you can remove them in debian/rules by calling:
- $ find path/to/base/dir -type d -empty -delete

?Lintian/Tags/package-section-games-but-contains-no-game

Lintian tag package-section-games-but-contains-no-game:

This package is marked as part of the section games, but doesn't contain files in /usr/games. Binaries of games must be installed in /usr/games.

Reference(s): policy 11.11

?Lintian/Tags/package-section-games-but-has-usr-bin

Lintian tag package-section-games-but-has-usr-bin:

This package is marked as part of the section games, but contains executables in /bin or /usr/bin/. This can be intentional, but is usually a mistake.

Reference(s): policy 11.11

?Lintian/Tags/games-package-should-be-section-games

Lintian tag games-package-should-be-section-games:

All the executables in this package are in /usr/games, but the package is not in section games. This can be intentional but is usually a mistake.

?Lintian/Tags/package-contains-devhelp-file-without-symlink

Lintian tag package-contains-devhelp-file-without-symlink:

This package contains a *.devhelp or *.devhelp2 file which is not in the devhelp search path (/usr/share/devhelp/books and /usr/share/gtk-doc/html) and is apparently not in a directory linked into the devhelp search path. This will prevent devhelp from finding the documentation.
If the devhelp documentation is installed in a path outside the devhelp search path (such as /usr/share/doc), create a symlink in /usr/share/gtk-doc/html pointing to the documentation directory.

?Lintian/Tags/debug-package-should-be-named-dbg

Lintian tag debug-package-should-be-named-dbg:

This package provides at least one file in /usr/lib/debug, which is intended for detached debugging symbols, but the package name does not end in "-dbg". Detached debugging symbols should be put into a separate package, Priority: extra, with a package name ending in "-dbg".

Reference(s): devref 6.7.9

?Lintian/Tags/package-contains-linda-override

Lintian tag package-contains-linda-override:

This package contains a linda override file in /usr/share/linda/overrides. Linda is obsolete and has been removed from the archive as of 2008-03-04. Linda overrides should probably be dropped from packages.

?Lintian/Tags/wrong-file-owner-uid-or-gid

Lintian tag wrong-file-owner-uid-or-gid:

The user or group ID of the owner of the file is invalid. The owner user and group IDs must be in the set of globally allocated IDs, because other IDs are dynamically allocated and might be used for varying purposes on different systems, or are reserved. The set of the allowed, globally allocated IDs consists of the ranges 0-99, 64000-64999 and 65534. It's possible for a Policy-compliant package to trigger this bug if the user is created in the preinst maintainer script, but this is a very rare case and doesn't appear to be necessary. If you found yourself needing to create a package that works this way, please file a bug against Lintian to let the maintainers know.

Reference(s): policy 9.2

?Lintian/Tags/embedded-javascript-library

Lintian tag embedded-javascript-library:

This package contains an embedded copy of ?JavaScript libraries that are now available in their own packages (for example, JQuery, Prototype, Mochikit or "Cropper"). Please depend on the appropriate package and symlink the library into the appropriate location.

Reference(s): policy 4.13

?Lintian/Tags/embedded-feedparser-library

Lintian tag embedded-feedparser-library:

This package contains an embedded copy of Mark Pilgrim's Universal Feed Parser. Please depend on the "python-feedparser" package and use the normal Python import mechanism to load it.

Reference(s): policy 4.13

?Lintian/Tags/embedded-pear-module

Lintian tag embedded-pear-module:

This package appears to contain an embedded copy of a PEAR module. Please depend on the respective PEAR package providing the module and make sure the library can be found by the scripts via the include_path.

Reference(s): policy 4.13

?Lintian/Tags/embedded-php-library

Lintian tag embedded-php-library:

This package appears to contain an embedded copy of a PHP library. Please depend on the respective package providing the library and make sure it can be found by the scripts via the include_path.

Reference(s): policy 4.13

?Lintian/Tags/windows-devel-file-in-package

Lintian tag windows-devel-file-in-package:

This package appears to contain development files only meaningful to Windows environments. Such files are generally useless in Debian packages and were usually accidentally included by copying complete directories from the source tarball.

?Lintian/Tags/font-in-non-font-package

Lintian tag font-in-non-font-package:

This package contains a *.ttf, *.otf, or *.pfb file, file extensions used by TrueType, ?OpenType, or Type 1 fonts, but the package does not appear to be a dedicated font package. Dedicated font package names should begin with ttf-, otf-, or t1-, depending on the types of fonts included. (Type 1 fonts are also allowed in packages starting with xfonts-.) If the font is already packaged, you should depend on that package instead. Otherwise, normally the font should be packaged separately, since fonts are usually useful outside of the package that embeds them.

?Lintian/Tags/duplicate-font-file

Lintian tag duplicate-font-file:

This package appears to include a font file that is already provided by another package in Debian. Ideally it should instead depend on the relevant font package. If the application in this package loads the font file by name, you may need to include a symlink pointing to the file name of the font in its Debian package. Sometimes the font package containing the font is huge and you only need one font. In that case, you have a few options: modify the package (in conjunction with upstream) to use libfontconfig to find the font that you prefer but fall back on whatever installed font is available, ask that the font package be split apart into packages of a more reasonable size, or add an override and be aware of the duplication when new versions of the font are released.

?Lintian/Tags/icon-size-and-directory-name-mismatch

Lintian tag icon-size-and-directory-name-mismatch:

The icon has a size that differs from the size specified by the name of the directory under which it was installed. The icon was probably mistakenly installed into the wrong directory.

?Lintian/Tags/gz-file-not-gzip

Lintian tag gz-file-not-gzip:

The given file ends with .gz, which normally indicates it is compressed with gzip. However, it doesn't seem to be a gzip-compressed file. gzip will fail with an error on such files. Normally this indicates a mistake in the installation process of the package.

?Lintian/Tags/non-free-flash

Lintian tag non-free-flash:

The given Flash file has a filename which suggests that it may be one of a number of known Flash files with non-free content.

?Lintian/Tags/non-conf-file-in-modprobe.d

Lintian tag non-conf-file-in-modprobe.d:

Files in /etc/modprobe.d should use filenames ending in .conf. modprobe currently warns about files which do not match this convention and at some point in the future the files will no longer be processed.
If the file is an example containing only comments, consider installing it in another location as files in /etc/modprobe.d are read each time modprobe is run (which is often at boot time).

Reference(s): http://lists.debian.org/debian-devel/2009/03/msg00119.html

?Lintian/Tags/file-in-discouraged-x11-font-directory

Lintian tag file-in-discouraged-x11-font-directory:

For historical reasons, use of PEX, CID, Speedo, and cyrillic subdirectories of /usr/share/fonts/X11 are permitted, but installation of files into these directories is discouraged. Support for the first three font types is deprecated or no longer available, and Cyrillic fonts should use the normal font directories where possible.

Reference(s): policy 11.8.5

?Lintian/Tags/file-in-unknown-x11-font-directory

Lintian tag file-in-unknown-x11-font-directory:

Subdirectories of /usr/share/fonts/X11 other than 100dpi, 75dpi, misc, Type1, and some historic exceptions must be neither created nor used. (The directories encodings and util, used by some X Window System packages, are also permitted by Lintian.)

Reference(s): policy 11.8.5

?Lintian/Tags/package-contains-multiple-dpi-fonts

Lintian tag package-contains-multiple-dpi-fonts:

This package contains both 100dpi and 75dpi bitmapped fonts. Both versions should not be included in a single package. If both resolutions are available, they should be provided in separate binary packages with -75dpi or -100dpi appended to the package name for the corresponding fonts.

Reference(s): policy 11.8.5

?Lintian/Tags/package-mixes-misc-and-dpi-fonts

Lintian tag package-mixes-misc-and-dpi-fonts:

This package contains both bitmapped fonts for a specific DPI (100dpi or 75dpi) and misc bitmapped fonts. These should not be combined in the same package. Instead, the misc bitmapped fonts should be provided in a separate package with -misc appended to its name.

Reference(s): policy 11.8.5

?Lintian/Tags/package-contains-info-dir-file

Lintian tag package-contains-info-dir-file:

This package contains a file named dir or dir.old, possibly compressed, in /usr/share/info. This is the directory (or backup) of info pages and is generated automatically by install-info when a package containing info documentation is installed. Some upstream build systems create it automatically, but it must not be included in a package since it needs to be generated dynamically based on the installed info files on the system.

?Lintian/Tags/package-contains-mime-cache-file

Lintian tag package-contains-mime-cache-file:

This package contains a cache file generated automatically by update-mime-database when a package containing MIME-Info Database files is installed. Some upstream build systems create them automatically, but they must not be included in a package since they need to be generated dynamically based on the installed MIME-Info Database files on the system.

?Lintian/Tags/package-contains-mimeinfo.cache-file

Lintian tag package-contains-mimeinfo.cache-file:

This package contains a file named mimeinfo.cache, possibly compressed, in /usr/share/applications. This file is generated automatically by update-desktop-database when a package containing .desktop files associated to MIME types is installed. Some upstream build systems create it automatically, but it must not be included in a package since it needs to be generated dynamically based on the installed .desktop files on the system.

?Lintian/Tags/package-modifies-ld.so-search-path

Lintian tag package-modifies-ld.so-search-path:

This package installs a file in /etc/ld.so.conf.d, presumably to modify the search path of the run-time linker, and does not appear to be part of libc.
Packages containing shared libraries should either install them into /usr/lib or should require binaries built against them to set RPATH to find the library at run-time. Installing libraries in a different directory and modifying the run-time linker path is equivalent to installing them into /usr/lib except now conflicting library packages may cause random segfaults and difficult-to-debug problems instead of conflicts in the package manager.

Reference(s): policy 10.2

?Lintian/Tags/global-data-in-games-directory

Lintian tag global-data-in-games-directory:

This package contains files under /usr/share/games, such as desktop files, icons, pixmaps, or MIME type entries, that are global system data. The user's desktop environment will only check in the directories directly under /usr/share and this information should be put in the global directory even if it is for games.
The most common cause of this problem is using a --datadir=/usr/share/games argument to configure or an equivalent and using the upstream installation rules. These files need to be moved into the corresponding directories directly under /usr/share.

?Lintian/Tags/duplicated-compressed-file

Lintian tag duplicated-compressed-file:

The given, apparently compressed, file is shipped in the package in addition to another file with the same name without the compression-method extension. Normally this indicates a mistake in the installation process of the package.

?Lintian/Tags/udev-rule-in-etc

Lintian tag udev-rule-in-etc:

This package ships a udev rule and installs it under /etc/udev/rules.d, which is reserved for user-installed files. The correct directory for system rules is /lib/udev/rules.d.

Reference(s): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559208

?Lintian/Tags/obsolete-comments-style-in-php-ini

Lintian tag obsolete-comments-style-in-php-ini:

This package ships a .ini file used to configure php but it has comments using the old-style comment separator #. Instead, the ; separator should be used. Since version 5.3, the PHP interpreter warns about the use of the old style of comment separator.

?Lintian/Tags/triplet-dir-and-architecture-mismatch

Lintian tag triplet-dir-and-architecture-mismatch:

This package contains a directory under /lib or /usr/lib which doesn't match the proper triplet for the binary package's architecture. This is very likely to be a mistake when indicating the underlying build system where the files should be installed.

Reference(s): policy 9.1.1

?Lintian/Tags/empty-binary-package

Lintian tag empty-binary-package:

This binary package appears to be empty, and its description does not say that it's a meta-package or a transitional package. This is often due to problems with updating debhelper *.install files during package renames or similar problems where installation rules don't put files in the correct place. If the package is deliberately empty, please mention in the package long description one of the phrases "meta-package," "dummy," "dependency package," "empty package," or "virtual package."

?Lintian/Tags/star-file

Lintian tag star-file:

The given file is literally installed as * (star symbol). Normally this indicates a mistake in the installation process of the package either when creating symlinks or renaming files.

?Lintian/Tags/incorrect-locale-code

Lintian tag incorrect-locale-code:

The package appears to ship locales for a language but uses an incorrect locale code as a subdirectory of /usr/share/locale. This usually results in users of the intended target language not finding the locale. The language codes used in the locale directories are those from the ISO 639-1 and ISO 639-2 standards, not those usually used as TLDs (which are from the ISO 3166 standard). Lintian only knows about some commonly-mistaken set of incorrect locale codes.

?Lintian/Tags/unknown-locale-code

Lintian tag unknown-locale-code:

The package appears to ship locales for a language but uses an unknown locale code as a subdirectory of /usr/share/locale. This usually results in users of the intended target language not finding the locale. The language codes used in the locale directories are those from the ISO 639-1 and ISO 639-2 standards, not those usually used as TLDs (which are from the ISO 3166 standard). It is possible that the language code was mistyped or incorrectly guessed from the language's or country's name.

Reference(s): http://www.loc.gov/standards/iso639-2/php/code_list.php

etcfiles

?Lintian/Tags/file-in-etc-not-marked-as-conffile

Lintian tag file-in-etc-not-marked-as-conffile:

Files in /etc must be marked conffiles if they are included in a package. Otherwise they should be created by maintainer scripts.

Reference(s): policy 10.7

?Lintian/Tags/old-format-menu-file

Lintian tag old-format-menu-file:

The package contains a menu file that is in the old menu file format. This format is deprecated. Convert the menu file to the new menu format. Note that lintian will not test this file for any other problems.

?Lintian/Tags/whitespace-after-continuation-character

Lintian tag whitespace-after-continuation-character:

The menu item is split up over 2 or more lines using '\' at the end of the line to join them together. However, there is some whitespace after the '\' character, which is not guaranteed to be handled correctly. The '\' should be at the end of the line.

?Lintian/Tags/bad-test-in-menu-item

Lintian tag bad-test-in-menu-item:

The menu file contains an item that does not start with the text "?package(somepackage):". All menu file lines must test for the existence of a package in this way.

Reference(s): menu 3.2

?Lintian/Tags/unparsable-menu-item

Lintian tag unparsable-menu-item:

An item of the menu file cannot be parsed as a series of tag=value pairs. This could be because you didn't close a set of double quotes.

Reference(s): menu 3.2

?Lintian/Tags/pkg-not-in-package-test

Lintian tag pkg-not-in-package-test:

This menu item doesn't test to see if the package containing it is installed. The start of any menu item is a conditional testing whether the required packages are installed. Normally this conditional should always check at least the package containing it, since menu items should be included in the package that provides the application the menu refers to. This error usually indicates a misspelling of the package name in the menu entry or a copied menu entry from another package that doesn't apply to this one.

Reference(s): menu 3.2

?Lintian/Tags/duplicated-tag-in-menu-item

Lintian tag duplicated-tag-in-menu-item:

The menu item contains two instances of the same tag. This is just a waste of space, as menu will only use one of them.

Reference(s): menu 3.2

?Lintian/Tags/menu-item-missing-required-tag

Lintian tag menu-item-missing-required-tag:

The menu item has a line that is missing a required tag. It's likely that the line will have no effect without this tag. install-menu may report this as an error during package installation.

?Lintian/Tags/menu-item-contains-unknown-tag

Lintian tag menu-item-contains-unknown-tag:

The menu item has a line that has a tag in it that is not one of the standard tags (needs=, section=, title=, longtitle=, command=, etc). While other tags can be used for specialized purposes, this is rare and it's more likely the tag's name is misspelled.

?Lintian/Tags/menu-item-uses-icon-none

Lintian tag menu-item-uses-icon-none:

The menu item has a line that uses icon=none. This is redundant and deprecated -- if there is no icon, just leave off the icon tag.

?Lintian/Tags/menu-item-needs-tag-has-unknown-value

Lintian tag menu-item-needs-tag-has-unknown-value:

The menu item has a line that has a needs= field with a strange value. This may be intentional, but it's probably a typo that will make menu ignore the line.

?Lintian/Tags/menu-item-uses-apps-games-section

Lintian tag menu-item-uses-apps-games-section:

The menu item has a line that specifies a section under "Apps/Games". This section has been moved to just "Games".

Reference(s): menu-policy 2.1

?Lintian/Tags/menu-item-uses-apps-section

Lintian tag menu-item-uses-apps-section:

The menu item has a line that specifies a section under "Apps". This section has been moved to "Applications".

Reference(s): menu-policy 2.1

?Lintian/Tags/menu-item-uses-windowmanagers-section

Lintian tag menu-item-uses-windowmanagers-section:

The menu item has a line that specifies a section under "?WindowManagers". This section has been moved to "Window Managers".

Reference(s): menu-policy 2.1

?Lintian/Tags/menu-item-creates-new-section

Lintian tag menu-item-creates-new-section:

The menu item has a line that specifies an unknown section or uses a section that is intended only as a menu root, not as a section that applications should use directly. Check the spelling of the section and check the section against the list in the menu policy. (The menu sections changed as of June of 2007.)

Reference(s): menu-policy 2.1

?Lintian/Tags/menu-item-creates-new-root-section

Lintian tag menu-item-creates-new-root-section:

The menu item has a line that specifies a new section to put a menu entry in, and this section appears right in the root menu. This is almost certainly an error. No new sections should be added to the root menu without discussion with the author of menu.

?Lintian/Tags/menu-icon-not-in-xpm-format

Lintian tag menu-icon-not-in-xpm-format:

Icons in the Debian menu system should be in XPM format.

Reference(s): menu 3.7

?Lintian/Tags/menu-icon-missing

Lintian tag menu-icon-missing:

This icon file couldn't be found. If the path to the icon in the menu file is an absolute path, make sure that icon exists at that path in the package. If the path is relative or a simple filename, make sure the icon is installed in /usr/share/pixmaps, the default location. If the icon is in a package this package depends on, add a lintian override for this warning. lintian cannot check icons in other packages.

Reference(s): menu 3.7

?Lintian/Tags/menu-icon-too-big

Lintian tag menu-icon-too-big:

Icons in the Debian menu system should be at most 32x32 pixels (icon16x16 icons should of course be at most 16x16 pixels)

Reference(s): menu 3.7

?Lintian/Tags/menu-icon-cannot-be-parsed

Lintian tag menu-icon-cannot-be-parsed:

The icon file could not be parsed. Perhaps this means a bad XPM file, or perhaps it means the lintian parsing needs to be improved. If the window managers and standard tools accept the file then probably it's the latter; please file a bug on lintian then.

?Lintian/Tags/su-wrapper-without--c

Lintian tag su-wrapper-without--c:

The menu item command or desktop file uses an su wrapper such as su-to-root without the -c flag. This is a syntax error.

Reference(s): su-to-root(1)

?Lintian/Tags/su-to-root-with-usr-sbin

Lintian tag su-to-root-with-usr-sbin:

The menu item or desktop file command uses su-to-root as /usr/sbin/su-to-root. Since sarge su-to-root is located in /usr/bin and /usr/sbin/su-to-root is only a compatibility symlink that may get dropped in the future. Since su-to-root is now located in /usr/bin you can use it without absolute path now.

?Lintian/Tags/su-wrapper-not-su-to-root

Lintian tag su-wrapper-not-su-to-root:

The menu item or desktop file command uses an su wrapper other than su-to-root. On Debian systems, please use su-to-root -X, which will pick the correct wrapper based on what's installed on the system and the current desktop environment. Using su-to-root is also important for Live CD systems which need to use sudo rather than su. su-to-root permits global configuration to use sudo.

?Lintian/Tags/menu-item-needs-dwww

Lintian tag menu-item-needs-dwww:

The menu item has needs=dwww. This is deprecated. Instead, you should register your documentation with doc-base, and dwww entries will be automatically generated.

?Lintian/Tags/non-wm-in-windowmanager-menu-section

Lintian tag non-wm-in-windowmanager-menu-section:

The menu item is in the Window Manager section but does not needs=wm. Either it is a window manager and it should needs=wm, either it isn't and then it must be moved in another section.

?Lintian/Tags/non-wm-module-in-wm-modules-menu-section

Lintian tag non-wm-module-in-wm-modules-menu-section:

The menu item is in the FVWM Modules or Window Maker section but does not declare that it needs a specific window manager (using the needs key in the menu file). Modules for Fvwm should have needs="fvwmmodule". Modules for ?WindowMaker should have needs="wmmaker".

?Lintian/Tags/unquoted-string-in-menu-item

Lintian tag unquoted-string-in-menu-item:

The menu item includes a tag with an unquoted string like section=Games instead of section="Games". This is deprecated. Use a quoted string instead.

Reference(s): menu 3.2

?Lintian/Tags/menu-command-not-in-package

Lintian tag menu-command-not-in-package:

The menu item specifies a command which is not available in the package. In most cases this is a typo or after you moved a binary around, but forgot to update the menu file.

?Lintian/Tags/executable-desktop-file

Lintian tag executable-desktop-file:

The desktop entry file is marked executable. Desktop entries are regular files and should be installed mode 0644.

?Lintian/Tags/desktop-entry-file-has-crs

Lintian tag desktop-entry-file-has-crs:

The desktop entry file has lines ending in CRLF instead of just LF. The Desktop Entry Specification is explicit that lines should end with only LF. The CR may be taken by some software as part of the field.

Reference(s): http://standards.freedesktop.org/desktop-entry-spec/1.0/ar01s02.html

?Lintian/Tags/duplicated-key-in-desktop-entry

Lintian tag duplicated-key-in-desktop-entry:

The desktop entry contains two instances of the same key. The behavior of such desktop entries is not well-defined by the standard. The desktop-file-validate tool in the desktop-file-utils package is useful for checking the syntax of desktop entries.

?Lintian/Tags/desktop-entry-missing-required-key

Lintian tag desktop-entry-missing-required-key:

Desktop entries must contain, at a minimum, the keys Type and Name. The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/desktop-entry-spec/1.0/ar01s05.html

?Lintian/Tags/desktop-entry-contains-unknown-key

Lintian tag desktop-entry-contains-unknown-key:

The key on this line of the desktop entry is not one of the standard keys defined in the FreeDesktop specification, not one of the legacy KDE keywords, and one that does not begin with X-. It's most likely that the key was misspelled. The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/desktop-entry-spec/1.0/ar01s05.html

?Lintian/Tags/desktop-entry-contains-deprecated-key

Lintian tag desktop-entry-contains-deprecated-key:

The key on this line of the desktop entry has been deprecated in the FreeDesktop specification. The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/desktop-entry-spec/1.0/apc.html

?Lintian/Tags/desktop-entry-contains-encoding-key

Lintian tag desktop-entry-contains-encoding-key:

The Encoding key is now deprecated by the FreeDesktop standard and all strings are required to be encoded in UTF-8. This desktop entry explicitly specifies an Encoding of UTF-8, which is harmless but no longer necessary. The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/desktop-entry-spec/1.0/apc.html

?Lintian/Tags/desktop-entry-lacks-main-category

Lintian tag desktop-entry-lacks-main-category:

The categories for this desktop entry do not contain any Main Categories, only Additional Categories. Additional Categories should only be used on conjunction with one or more Main Categories. The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/menu-spec/1.0/apa.html

?Lintian/Tags/desktop-entry-uses-reserved-category

Lintian tag desktop-entry-uses-reserved-category:

This desktop entry includes a Reserved Category, one which has a desktop-specific meaning that has not yet been standardized, but does not include an ?OnlyShowIn key. Desktop entries using a Reserved Category must include an ?OnlyShowIn key limiting the entry to those environments that support the category. The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/menu-spec/1.0/apa.html

?Lintian/Tags/desktop-entry-invalid-category

Lintian tag desktop-entry-invalid-category:

This desktop entry lists a category that is not one of the registered Main or Additional Categories in the FreeDesktop specification. Note that case is significant and whitespace is only allowed immediately before and after the equal sign in the Category key, not elsewhere in the field. The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/menu-spec/1.0/apa.html

?Lintian/Tags/desktop-command-not-in-package

Lintian tag desktop-command-not-in-package:

The desktop entry specifies a command that is not available in the package. In most cases, this is a typo or a forgotten update of the desktop file after the install location of the binary was changed. A desktop file for a command should be included in the same package as that command.

?Lintian/Tags/desktop-contains-deprecated-header

Lintian tag desktop-contains-deprecated-header:

The header on this line of the desktop entry has been deprecated in the FreeDesktop specification. If the header is "KDE Desktop Entry", the right fix is normally changing it to "Desktop Entry". The desktop-file-validate took in the desktop-file-utils package is useful for checking the syntax of desktop entries.

Reference(s): http://standards.freedesktop.org/desktop-entry-spec/1.0/apc.html

?Lintian/Tags/deprecated-kdelnk-file

Lintian tag deprecated-kdelnk-file:

kdelnk files were used by KDE 1 and since KDE 2 desktop files are used instead. Renaming the file and removing the deprecated header and keys is often all that needs to be done.

Reference(s): http://standards.freedesktop.org/desktop-entry-spec/1.0/apc.html

?Lintian/Tags/desktop-entry-limited-to-environments

Lintian tag desktop-entry-limited-to-environments:

This desktop entry uses ?OnlyShowIn to limit the environments in which it's displayed but lists multiple environments. This is often a sign of a desktop file written assuming that only GNOME, KDE, and Xfce are in use and the desktop file intended to exclude one of them. This unintentionally hides the application from desktop environments such as LXDE where it would work fine. If this application supports any desktop environment except some specific ones, it should list the unsupported environments in the ?NotShowIn key instead.

shared-libs

?Lintian/Tags/shlib-with-executable-bit

Lintian tag shlib-with-executable-bit:

Shared libraries should be mode 0644.

Reference(s): policy 8.1

?Lintian/Tags/shlib-with-bad-permissions

Lintian tag shlib-with-bad-permissions:

Shared libraries should be mode 0644.

Reference(s): policy 8.1

?Lintian/Tags/shlib-with-non-pic-code

Lintian tag shlib-with-non-pic-code:

The listed shared libraries contain object code that was compiled without -fPIC. All object code in shared libraries should be recompiled separately from the static libraries with the -fPIC option.
Another common mistake that causes this problem is linking with gcc -Wl,-shared instead of gcc -shared. In some cases, exceptions to this rule are warranted. If this is such a case, follow the procedure outlined in Policy and then please document the exception by adding a lintian override to this package.
To check whether a shared library has this problem, run readelf -d on the shared library. If a tag of type TEXTREL is present, the shared library contains non-PIC code.

Reference(s): policy 10.2

?Lintian/Tags/shlib-without-versioned-soname

Lintian tag shlib-without-versioned-soname:

The listed shared library in a public library directory has an SONAME that does not contain any versioning information, either after the .so or before it and set off by a hyphen. It cannot therefore be represented in the shlibs system, and if linked by binaries its interface cannot safely change. There is no backward-compatible way to migrate programs linked against it to a new ABI.
Normally, this means the shared library is a private library for a particular application and is not meant for general use. Policy recommends that such libraries be installed in a subdirectory of /usr/lib rather than in a public shared library directory.
To view the SONAME of a shared library, run readelf -d on the shared library and look for the tag of type SONAME. There are some special stub libraries or special-purpose shared objects for which an ABI version is not meaningful. If this is one of those cases, please add an override.

Reference(s): policy 10.2, policy 8.6

?Lintian/Tags/ldconfig-symlink-missing-for-shlib

Lintian tag ldconfig-symlink-missing-for-shlib:

The package should not only include the shared library itself, but also the symbolic link which ldconfig would produce. (This is necessary, so that the link gets removed by dpkg automatically when the package gets removed.) If the symlink is in the package, check that the SONAME of the library matches the info in the shlibs file.

Reference(s): policy 8.1

?Lintian/Tags/ldconfig-symlink-before-shlib-in-deb

Lintian tag ldconfig-symlink-before-shlib-in-deb:

In the package contents list, the shared library has to come before any symbolic links referencing the shared library.

Reference(s): policy 8.1

?Lintian/Tags/dev-pkg-without-shlib-symlink

Lintian tag dev-pkg-without-shlib-symlink:

A "-dev" package is supposed to install a "libsomething.so" symbolic link referencing the corresponding shared library. Notice how the link name doesn't include the version number -- this is because such a link is used by the linker when other programs are built against this shared library.

Reference(s): policy 8.4

?Lintian/Tags/non-dev-pkg-with-shlib-symlink

Lintian tag non-dev-pkg-with-shlib-symlink:

Although this package is not a "-dev" package, it installs a "libsomething.so" symbolic link referencing the corresponding shared library. When the link doesn't include the version number, it is used by the linker when other programs are built against this shared library. Shared libraries are supposed to place such symbolic links in their respective "-dev" packages, so it is a bug to include it with the main library package. However, if this is a small package which includes the runtime and the development libraries, this is not a bug. In the latter case, please override this warning.

Reference(s): policy 8.4

?Lintian/Tags/preinst-calls-ldconfig

Lintian tag preinst-calls-ldconfig:

The preinst script calls ldconfig. Calls to ldconfig should only be in postinst and postrm scripts.

Reference(s): policy 8.1.1

?Lintian/Tags/prerm-calls-ldconfig

Lintian tag prerm-calls-ldconfig:

The prerm script calls ldconfig. Calls to ldconfig should only be in postinst and postrm scripts.

Reference(s): policy 8.1.1

?Lintian/Tags/postrm-unsafe-ldconfig

Lintian tag postrm-unsafe-ldconfig:

The postrm script calls ldconfig unsafely. The postrm must only call ldconfig when given the argument "remove".

Reference(s): policy 8.1.1

?Lintian/Tags/no-shlibs-control-file

Lintian tag no-shlibs-control-file:

Although the package includes a shared library, the package does not have a shlibs control file. If this is intentional, please override this error.

Reference(s): policy 8.6

?Lintian/Tags/pkg-has-shlibs-control-file-but-no-actual-shared-libs

Lintian tag pkg-has-shlibs-control-file-but-no-actual-shared-libs:

Although the package does not include any shared libraries, it does have a shlibs control file. If you did include a shared library, check that the SONAME of the library is set and that it matches the contents of the shlibs file.
SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this.

?Lintian/Tags/duplicate-entry-in-shlibs-control-file

Lintian tag duplicate-entry-in-shlibs-control-file:

The shlibs control file contains a duplicate entry.

?Lintian/Tags/shlib-missing-in-control-file

Lintian tag shlib-missing-in-control-file:

The package contains a shared library that is not listed in the shlibs control file. If this is intentional, please override this error.

Reference(s): policy 8.6

?Lintian/Tags/unused-shlib-entry-in-control-file

Lintian tag unused-shlib-entry-in-control-file:

The shlibs control file contains an entry for a shared library that is not installed by this package.

Reference(s): policy 8.6

?Lintian/Tags/shlibs-declares-dependency-on-other-package

Lintian tag shlibs-declares-dependency-on-other-package:

This package declares in its shlibs control file either a dependency on some other package not listed in the Provides of this package or on a version of this package that the package version doesn't satisfy. Packages should normally only list in their shlibs control file the shared libraries included in that package, and therefore the dependencies listed there should normally be satisfied by either the package itself or one of its Provides. In unusual circumstances where it's necessary to declare more complex dependencies in the shlibs control file, please add a lintian override for this warning.

Reference(s): policy 8.6

?Lintian/Tags/ldconfig-symlink-referencing-wrong-file

Lintian tag ldconfig-symlink-referencing-wrong-file:

The symbolic link references the wrong file. (It should reference the shared library.)

Reference(s): policy 8.1

?Lintian/Tags/ldconfig-symlink-is-not-a-symlink

Lintian tag ldconfig-symlink-is-not-a-symlink:

The package installs a file with the name, ldconfig would use for the symbolic link to reference the shared library.

Reference(s): policy 8.1

?Lintian/Tags/postinst-has-useless-call-to-ldconfig

Lintian tag postinst-has-useless-call-to-ldconfig:

The postinst script calls ldconfig even though no shared libraries are installed in a directory controlled by the dynamic library loader.

Reference(s): policy 8.1.1

?Lintian/Tags/udeb-postinst-must-not-call-ldconfig

Lintian tag udeb-postinst-must-not-call-ldconfig:

The postinst script calls ldconfig, which is an error in udebs. ldconfig is not available and not needed in debian-installer

?Lintian/Tags/postrm-has-useless-call-to-ldconfig

Lintian tag postrm-has-useless-call-to-ldconfig:

The postrm script calls ldconfig even though no shared libraries are installed in a directory controlled by the dynamic library loader.

Reference(s): policy 8.1.1

?Lintian/Tags/postinst-must-call-ldconfig

Lintian tag postinst-must-call-ldconfig:

The package installs shared libraries in a directory controlled by the dynamic library loader. Therefore, the package must call "ldconfig" in its postinst script.

Reference(s): policy 8.1.1

?Lintian/Tags/postrm-should-call-ldconfig

Lintian tag postrm-should-call-ldconfig:

The package installs shared libraries in a directory controlled by the dynamic library loader. Therefore, the package should call "ldconfig" in its postrm script.

Reference(s): policy 8.1.1

?Lintian/Tags/sharedobject-in-library-directory-missing-soname

Lintian tag sharedobject-in-library-directory-missing-soname:

A shared object was identified in a library directory (a directory in the standard linker path) which doesn't have a SONAME. This is usually an error.
SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this.
To view the SONAME of a shared library, run readelf -d on the shared library and look for the tag of type SONAME.

?Lintian/Tags/shlib-without-PT_GNU_STACK-section

Lintian tag shlib-without-PT_GNU_STACK-section:

The listed shared libraries lacks a PT_GNU_STACK section. This forces the dynamic linker to make the stack executable. The shared lib is linked either with a non-GNU linker or a linker which is very old. This problem can be fixed with a rebuild.
To see whether a shared library has this section, run readelf -l on it and look for a program header of type GNU_STACK.

?Lintian/Tags/shlib-with-executable-stack

Lintian tag shlib-with-executable-stack:

The listed shared libraries declares the stack as executable. Executable stack is usually an error as it is only needed if the code contains GCC trampolines or similar constructs which uses code on the stack. One possible source for false positives are object files built from assembler files which don't define a proper .note.GNU-stack section.
To see the permissions on the stack, run readelf -l on the shared library and look for the program header of type GNU_STACK. In the flag column, there should not be an E flag set.

?Lintian/Tags/symbols-file-contains-current-version-with-debian-revision

Lintian tag symbols-file-contains-current-version-with-debian-revision:

Debian revisions should be stripped from versions in symbols files. Not doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo << 1.0-1 while 1.0-1~bpo >= 1.0). If the debian revision can't be stripped because the symbol really appeared between two specific Debian revisions, you should postfix the version with a single "~" (example: 1.0-3~ if the symbol appeared in 1.0-3).
This problem normally means that the symbols were added automatically by dpkg-gensymbols. dpkg-gensymbols uses the full version number for the dependency associated to any new symbol that it detects. The maintainer must update the debian/<package>.symbols file by adding the new symbols with the corresponding upstream version.

?Lintian/Tags/symbols-file-contains-debian-revision

Lintian tag symbols-file-contains-debian-revision:

Debian revisions should be stripped from versions in symbols files. Not doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo << 1.0-1 while 1.0-1~bpo >= 1.0). If the debian revision can't be stripped because the symbol really appeared between two specific Debian revisions, you should postfix the version with a single "~" (example: 1.0-3~ if the symbol appeared in 1.0-3).

Reference(s): dpkg-gensymbols(1), http://wiki.debian.org/UsingSymbolsFiles

?Lintian/Tags/syntax-error-in-symbols-file

Lintian tag syntax-error-in-symbols-file:

The symbols file contains an entry that does not follow the syntax rules for symbols files. This may be due to the entry appearing out of sequence.

Reference(s): deb-symbols(5)

?Lintian/Tags/duplicate-entry-in-symbols-control-file

Lintian tag duplicate-entry-in-symbols-control-file:

The symbols control file contains a duplicate entry.

?Lintian/Tags/no-symbols-control-file

Lintian tag no-symbols-control-file:

Although the package includes a shared library, the package does not have a symbols control file. dpkg can use symbols files in order to generate more accurate library dependencies for applications, based on the symbols from the library that are actually used by the application.

Reference(s): dpkg-gensymbols(1), http://wiki.debian.org/UsingSymbolsFiles

?Lintian/Tags/pkg-has-symbols-control-file-but-no-shared-libs

Lintian tag pkg-has-symbols-control-file-but-no-shared-libs:

Although the package does not include any shared libraries, it does have a symbols control file. If you did include a shared library, check that the SONAME of the library is set and that it matches the contents of the symbols file.
SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0 is the major version of the library. If your package uses libtool, then libtool invoked with the right options should be doing this.

?Lintian/Tags/shlib-missing-in-symbols-control-file

Lintian tag shlib-missing-in-symbols-control-file:

The package contains a shared library that is not listed in the symbols control file. This may not be a problem if, for example, the library is a C++ library.

?Lintian/Tags/unused-shlib-entry-in-symbols-control-file

Lintian tag unused-shlib-entry-in-symbols-control-file:

The symbols control file contains an entry for a shared library that is not installed by this package.

?Lintian/Tags/symbols-declares-dependency-on-other-package

Lintian tag symbols-declares-dependency-on-other-package:

This package declares in its symbols control file a dependency on some other package (and not one listed in the Provides of this package). Packages should normally only list in their symbols control file the shared libraries included in that package, and therefore the dependencies listed there should normally be satisfied by either the package itself or one of its Provides. In unusual circumstances where it's necessary to declare more complex dependencies in the symbols control file, please add a lintian override for this warning.

Reference(s): policy 8.6

?Lintian/Tags/invalid-template-id-in-symbols-file

Lintian tag invalid-template-id-in-symbols-file:

The symbol definition refers to an alternative dependency template which is not defined for the library containing the symbol. The first alternative dependency template for a library the id number of 1, with the ids of subsequent alternative templates increasing in sequence.

?Lintian/Tags/unknown-meta-field-in-symbols-file

Lintian tag unknown-meta-field-in-symbols-file:

The symbols control file contains an unknown meta-information field. A list of currently supported fields may be found in deb-control(5).

Reference(s): deb-control(5)

?Lintian/Tags/symbols-declared-but-not-shlib

Lintian tag symbols-declared-but-not-shlib:

The symbols control file contains dependency and symbol information for a shared library which is not listed in the shlibs control file.

?Lintian/Tags/shlib-calls-exit

Lintian tag shlib-calls-exit:

The listed shared library calls the C library exit() or _exit() functions. In the case of an error, the library should instead return an appropriate error code to the calling program which can then determine how to handle the error, including performing any required clean-up. In most cases, removing the call should be discussed with upstream, particularly as it may produce an ABI change.

?Lintian/Tags/incorrect-libdir-in-la-file

Lintian tag incorrect-libdir-in-la-file:

The given .la file points to a libdir other than the path where it is installed. This can be caused by resetting prefix at make install time instead of using DESTDIR. The incorrect path will cause packages linking to this library using libtool to build incorrectly (adding incorrect paths to RPATH, for example).

infofiles

?Lintian/Tags/info-document-not-compressed

Lintian tag info-document-not-compressed:

Info documents should be compressed with gzip -9.

Reference(s): policy 12.2

?Lintian/Tags/info-document-not-compressed-with-gzip

Lintian tag info-document-not-compressed-with-gzip:

Info documents should be compressed with gzip -9. This file ends in .gz but doesn't appear to be a gzip-compressed file.

Reference(s): policy 12.2

?Lintian/Tags/info-document-not-compressed-with-max-compression

Lintian tag info-document-not-compressed-with-max-compression:

Info documents should be compressed with gzip -9. This file is compressed with gzip, but without using maximum compression.

Reference(s): policy 12.2

?Lintian/Tags/info-document-has-wrong-extension

Lintian tag info-document-has-wrong-extension:

The info document has an extension other than info*.gz.

?Lintian/Tags/info-document-missing-dir-section

Lintian tag info-document-missing-dir-section:

This info document has no INFO-DIR-SECTION line. install-info will be unable to determine the section into which this info page should be put. The best solution is to add a line like:
- @dircategory Development
to the texinfo source so that the generated info file will contain a section. See /usr/share/info/dir for sections to choose from. You will have to ensure that the build process builds new info files rather than using ones built by upstream.

?Lintian/Tags/info-document-missing-dir-entry

Lintian tag info-document-missing-dir-entry:

This info document has no directory entry. This is text between START-INFO-DIR-ENTRY and END-INFO-DIR-ENTRY lines which is copied into the dir file in /usr/share/info by install-info. The best solution is to add lines like:
- @direntry * foo: (foo). Foo creator and editor @end direntry
to the texinfo source so that the generated info file will contain an appropriate entry. You will have to ensure that the build process builds new info files rather than using ones built by upstream.

?Lintian/Tags/missing-dependency-on-install-info

Lintian tag missing-dependency-on-install-info:

This package appears to contain at least one info document but does not depend on dpkg (>= 1.15.4) | install-info as recommended by Policy. This dependency is needed for the transition to triggerized install-info to correctly build the info directory during partial upgrades from lenny.

Reference(s): policy 12.2

copyright-file

?Lintian/Tags/no-copyright-file

Lintian tag no-copyright-file:

Each binary package has to include a plain file /usr/share/doc/pkg/copyright

Reference(s): policy 12.5

?Lintian/Tags/copyright-refers-to-old-directory

Lintian tag copyright-refers-to-old-directory:

The common licenses (GPL, BSD, Artistic, etc) have been moved from /usr/doc/copyright to /usr/share/common-licenses. Copyright files should be updated.

Reference(s): policy 12.5

?Lintian/Tags/copyright-file-compressed

Lintian tag copyright-file-compressed:

The copyright file /usr/share/doc/pkg/copyright must not be compressed.

Reference(s): policy 12.5

?Lintian/Tags/copyright-file-is-symlink

Lintian tag copyright-file-is-symlink:

The copyright file /usr/share/doc/pkg/copyright must not be a symbolic link.

Reference(s): policy 12.5

?Lintian/Tags/copyright-file-contains-full-gpl-license

Lintian tag copyright-file-contains-full-gpl-license:

The copyright file /usr/share/doc/pkg/copyright contains the complete text of the GPL v1, v2, or v3. It should refer to the file /usr/share/common-licenses/GPL-1, GPL-2, or GPL-3 instead.

Reference(s): policy 12.5

?Lintian/Tags/copyright-file-contains-full-gfdl-license

Lintian tag copyright-file-contains-full-gfdl-license:

The copyright file /usr/share/doc/pkg/copyright contains the complete text of the GFDL v1.2. It should refer to the file /usr/share/common-licenses/GFDL-1.2 instead.

Reference(s): policy 12.5

?Lintian/Tags/copyright-file-contains-full-apache-2-license

Lintian tag copyright-file-contains-full-apache-2-license:

The copyright file /usr/share/doc/pkg/copyright contains the complete text of the Apache 2.0 license. It should refer to the file /usr/share/common-licenses/Apache-2.0 instead.

Reference(s): policy 12.5

?Lintian/Tags/usr-share-doc-symlink-without-dependency

Lintian tag usr-share-doc-symlink-without-dependency:

If the package installs a symbolic link /usr/share/doc/pkg1 -> pkg2, then pkg1 must depend on pkg2 directory, with the same version as pkg1.
Adding the dependency just to fix this bug is often not a good solution. Usually, it's better to include a real /usr/share/doc/pkg1 directory within pkg1 and copy the copyright file into that directory. Transitive dependencies are not allowed here. In other words, if the documentation directory is shipped in pkg3 and pkg1 depends on pkg2, which in turn depends on pkg3, that's still an error. Copyright file extractors are not required to go more than one level deep when resolving dependencies. Each package should have a direct dependency on the package which includes its documentation directory.

Reference(s): policy 12.5

?Lintian/Tags/usr-share-doc-symlink-to-foreign-package

Lintian tag usr-share-doc-symlink-to-foreign-package:

If the package installs a symbolic link /usr/share/doc/pkg1 -> pkg2, then pkg1 and pkg2 must both come from the same source package.
The best solution is probably to stop symlinking the /usr/share/doc directory for this package and instead include a real /usr/share/doc/pkg1 directory within pkg1 with the appropriate contents (such as the copyright and changelog.Debian.gz files).

Reference(s): policy 12.5

?Lintian/Tags/cannot-check-whether-usr-share-doc-symlink-points-to-foreign-package

Lintian tag cannot-check-whether-usr-share-doc-symlink-points-to-foreign-package:

There is a symlink /usr/share/doc/pkg1 -> pkg2 in your package. This means that pkg1 and pkg2 must both come from the same source package. I can't check this right now however since I'm only checking a binary package and I only can check this when I'm checking both the binary and the corresponding source package.

?Lintian/Tags/old-style-copyright-file

Lintian tag old-style-copyright-file:

The package installs a /usr/doc/copyright/pkg file. Instead, you should place the copyright file in /usr/share/doc/pkg/copyright.

Reference(s): policy 12.5

?Lintian/Tags/old-fsf-address-in-copyright-file

Lintian tag old-fsf-address-in-copyright-file:

The /usr/share/doc/pkg/copyright file refers to the old postal address of the Free Software Foundation (FSF). The new address is:
- Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.

?Lintian/Tags/helper-templates-in-copyright

Lintian tag helper-templates-in-copyright:

The /usr/share/doc/pkg/copyright file still contains template markers from a packaging helper. Please fill in the actual license, upstream copyright holders, and download information about the package and remove any remaining templates generated by the packaging helper.

?Lintian/Tags/copyright-refers-to-compressed-license

Lintian tag copyright-refers-to-compressed-license:

The /usr/share/doc/pkg/copyright file refers to a standard license /usr/share/common-licenses/{GPL,LGPL,Artistic,BSD}.gz as a compressed file. Please update the reference (the licenses are installed uncompressed).

?Lintian/Tags/usr-share-doc-symlink-points-outside-of-usr-share-doc

Lintian tag usr-share-doc-symlink-points-outside-of-usr-share-doc:

The /usr/share/doc/pkg symbolic link is pointing to a directory outside of /usr/share/doc.

Reference(s): policy 12.5

?Lintian/Tags/copyright-does-not-refer-to-common-license-file

Lintian tag copyright-does-not-refer-to-common-license-file:

If your package uses any one of the licenses in /usr/share/common-licenses, the copyright file should refer to files therein.

Reference(s): policy 12.5

?Lintian/Tags/copyright-refers-to-incorrect-directory

Lintian tag copyright-refers-to-incorrect-directory:

In the directory name /usr/share/common-licenses, licenses is spelled with an "s", not as licences with a "c".

Reference(s): policy 12.5

?Lintian/Tags/copyright-file-lacks-pointer-to-perl-license

Lintian tag copyright-file-lacks-pointer-to-perl-license:

If your package is released under the same terms as Perl itself, it should refer to the Artistic and GPL license files in the /usr/share/common-licenses directory.

Reference(s): policy 12.5

?Lintian/Tags/copyright-should-refer-to-common-license-file-for-gpl

Lintian tag copyright-should-refer-to-common-license-file-for-gpl:

The strings "GNU General Public License" or "GPL" appear in the copyright file for this package, but the copyright file does not reference /usr/share/common-licenses as the location of the GPL on Debian systems. If the package uses some other license that just mentions the GPL and that Lintian should detect as an exception, please file a Lintian bug. If the copyright file must mention the GPL for reasons other than stating the license of the package, please add a Lintian override.

Reference(s): policy 12.5

?Lintian/Tags/copyright-should-refer-to-common-license-file-for-gfdl

Lintian tag copyright-should-refer-to-common-license-file-for-gfdl:

The strings "GNU Free Documentation License" or "GFDL" appear in the copyright file for this package, but the copyright file does not reference /usr/share/common-licenses as the location of the GFDL on Debian systems. If the package uses some other license that just mentions the GFDL and that Lintian should detect as an exception, please file a Lintian bug. If the copyright file must mention the GFDL for reasons other than stating the license of the package, please add a Lintian override.

Reference(s): policy 12.5

?Lintian/Tags/copyright-should-refer-to-common-license-file-for-lgpl

Lintian tag copyright-should-refer-to-common-license-file-for-lgpl:

The strings "GNU Lesser General Public License", "GNU Library General Public License", or "LGPL" appear in the copyright file for this package, but the copyright file does not reference /usr/share/common-licenses as the location of the LGPL on Debian systems. If the package uses some other license that just mentions the LGPL and that Lintian should detect as an exception, please file a Lintian bug. If the copyright file must mention the LGPL for reasons other than stating the license of the package, please add a Lintian override.

Reference(s): policy 12.5

?Lintian/Tags/copyright-has-url-from-dh_make-boilerplate

Lintian tag copyright-has-url-from-dh_make-boilerplate:

There is "url://example.com" in your copyright file. This was most likely a remnant from the dh_make template. Make sure you include the real location where you obtained the upstream sources (if any).

Reference(s): policy 12.5

?Lintian/Tags/debian-copyright-file-uses-obsolete-national-encoding

Lintian tag debian-copyright-file-uses-obsolete-national-encoding:

The Debian copyright file should be valid UTF-8, an encoding of the Unicode character set. There are many ways to convert a copyright file from an obsoleted encoding like ISO-8859-1; you may for example use "iconv" like:
- $ iconv -f ISO-8859-1 -t UTF-8 copyright > copyright.new $ mv copyright.new copyright

?Lintian/Tags/copyright-contains-dh_make-todo-boilerplate

Lintian tag copyright-contains-dh_make-todo-boilerplate:

The string "Please also look if..." appears in the copyright file, which indicates that you either didn't check the whole source to find additional copyright/license, or that you didn't remove that paragraph after having done so.

Reference(s): policy 12.5

?Lintian/Tags/copyright-contains-dh-make-perl-boilerplate

Lintian tag copyright-contains-dh-make-perl-boilerplate:

The string "This copyright info was automatically extracted" appears in the copyright file, which indicates that you either didn't check the whole source to find additional copyright/license, or that you didn't remove that paragraph after having done so.

Reference(s): policy 12.5

?Lintian/Tags/copyright-with-old-dh-make-debian-copyright

Lintian tag copyright-with-old-dh-make-debian-copyright:

The copyright file contains the incomplete Debian packaging copyright boilerplate from older versions of dh_make. (C) is not considered as a valid way to express the copyright ownership. The word Copyright or the © symbol should be used instead or in addition to (C).

?Lintian/Tags/copyright-refers-to-bad-php-license

Lintian tag copyright-refers-to-bad-php-license:

This package appears to be covered by version 2.x of the PHP license, which is not appropriate for anything other than PHP itself.

Reference(s): http://ftp-master.debian.org/REJECT-FAQ.html

?Lintian/Tags/copyright-refers-to-problematic-php-license

Lintian tag copyright-refers-to-problematic-php-license:

This package appears to be covered by version 3.0 (exactly) of the PHP license. This license is not applicable to anything that is not PHP and has no contributions from the PHP Group.

Reference(s): http://ftp-master.debian.org/REJECT-FAQ.html

?Lintian/Tags/copyright-without-copyright-notice

Lintian tag copyright-without-copyright-notice:

The copyright file for this package does not appear to contain a copyright notice. You should copy the copyright notice from the upstream source (or add one of your own for a native package). A copyright notice must consist of Copyright, Copr., or the Unicode symbol of C in a circle followed by the years and the copyright holder. A copyright notice is not required for a work to be copyrighted, but Debian requires the copyright file include the authors and years of copyright, and including a valid copyright notice is the best way to do that. Examples:
- Copyright YYYY Firstname Lastname <address@example.com> Copr. YYYY-YYYY Firstname Lastname <address@example.com> © YYYY,YYYY Firstname Lastname <address@example.com>
If the package is in the public domain rather than copyrighted, be sure to mention "public domain" in the copyright file. Please be aware that this is very rare and not the same as a DFSG-free license. True public domain software is generally limited to such special cases as a work product of a United States government agency.

Reference(s): http://ftp-master.debian.org/REJECT-FAQ.html

?Lintian/Tags/spelling-error-in-copyright

Lintian tag spelling-error-in-copyright:

Lintian found a spelling error in the copyright file. Lintian has a list of common misspellings that it looks for. It does not have a dictionary like a spelling checker does. If this is a spelling error in the upstream license, in supporting email messages, or a case of Lintian being confused by non-English text, add an override.

?Lintian/Tags/possible-gpl-code-linked-with-openssl

Lintian tag possible-gpl-code-linked-with-openssl:

This package appears to be covered by the GNU GPL but depends on the OpenSSL libssl package and does not mention a license exemption or exception for OpenSSL in its copyright file. The GPL (including version 3) is incompatible with some terms of the OpenSSL license, and therefore Debian does not allow GPL-licensed code linked with OpenSSL libraries unless there is a license exception explicitly permitting this. If only the Debian packaging, or some other part of the package not linked with OpenSSL, is covered by the GNU GPL, please add a lintian override for this tag. Lintian currently has no good way of distinguishing between that case and problematic packages.

?Lintian/Tags/copyright-refers-to-symlink-license

Lintian tag copyright-refers-to-symlink-license:

The copyright file refers to the versionless symlink in /usr/share/common-licenses for the full text of the GPL, LGPL, or GFDL license. This symlink is updated to point to the latest version of the license when a new one is released. The package appears to allow relicensing under later versions of its license, so this is legally consistent, but it implies that Debian will relicense the package under later versions of those licenses as they're released. It is normally better to point to the version of the license the package references in its license statement.
For example, if the package says something like "you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version", the debian/copyright file should refer to /usr/share/common-licenses/GPL-2, not /GPL.
For packages released under the same terms as Perl, Perl references the GPL version 1, so point to /usr/share/common-licenses/GPL-1.

?Lintian/Tags/copyright-refers-to-versionless-license-file

Lintian tag copyright-refers-to-versionless-license-file:

The copyright file refers to the versionless symlink in /usr/share/common-licenses for the full text of the GPL, LGPL, or GFDL license, but the package does not appear to allow distribution under later versions of the license. This symlink will change with each release of a new version of the license and may therefore point to a different version than the package is released under. debian/copyright should instead refers to the specific version of the license that the package references.
For example, if the package says something like "you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 dated June, 1991," the debian/copyright file should refer to /usr/share/common-licenses/GPL-2, not /GPL.

?Lintian/Tags/copyright-refers-to-nonexistent-license-file

Lintian tag copyright-refers-to-nonexistent-license-file:

The copyright file refers to a license in /usr/share/common-licenses that doesn't exist. Usually this is a typo, such as accidentally omitting the - between the license name and the version number.

?Lintian/Tags/copyright-refers-to-deprecated-bsd-license-file

Lintian tag copyright-refers-to-deprecated-bsd-license-file:

The copyright file refers to /usr/share/common-licenses/BSD. Due to the brevity of this license, the specificity of this copy to code whose copyright is held by the Regents of the University of California, and the frequency of minor wording changes in the license, its text should be included in the coypright file directly rather than referencing this file. This file may be removed from a future version of base-files if references to it drop sufficiently.

Reference(s): Policy 12.5

md5sums

?Lintian/Tags/no-md5sums-control-file

Lintian tag no-md5sums-control-file:

This package does not contain an md5sums control file. This control file listing the MD5 checksums of the contents of the package is not required, but if present debsums can use it to verify that no files shipped with your package have been modified. Providing it is recommended.
If you are using debhelper to create your package, just add a call to dh_md5sums at the end of your binary-indep or binary-arch target, right before dh_builddeb.

?Lintian/Tags/malformed-md5sums-control-file

Lintian tag malformed-md5sums-control-file:

The indicated line of the md5sums control file for this package was malformed. Each line of an md5sums control file should contain an MD5 checksum, some whitespace, and then the path to the file corresponding to that checksum.

?Lintian/Tags/md5sum-mismatch

Lintian tag md5sum-mismatch:

The md5sum listed for the file does not match the actual file contents.
Usually, this error occurs during the package build process, if the debian/tmp/ directory is touched after dh_md5sums or debstd is run.

?Lintian/Tags/md5sums-lists-nonexisting-file

Lintian tag md5sums-lists-nonexisting-file:

The md5sums control file lists a file which is not included in the package.
Usually, this error occurs during the package build process, if the debian/tmp/ directory is touched after dh_md5sums or debstd is run.
If all the files in the DEBIAN/ subdirectory are listed above, the problem was probably caused by building the package using a buggy debstd/debmake. In this case, rebuilding the package with an updated debstd should fix the problem.

?Lintian/Tags/file-missing-in-md5sums

Lintian tag file-missing-in-md5sums:

The package contains a file which isn't listed in the md5sums control file.
Usually, this error occurs during the package build process, if the debian/tmp/ directory is touched after dh_md5sums or debstd is run.

description

?Lintian/Tags/package-has-no-description

Lintian tag package-has-no-description:

The binary package does not have a "Description:" control field.

?Lintian/Tags/description-synopsis-is-empty

Lintian tag description-synopsis-is-empty:

The first line in the "Description:" is empty.

?Lintian/Tags/extended-description-is-empty

Lintian tag extended-description-is-empty:

The extended description (the lines after the first line of the "Description:" field) is empty.

?Lintian/Tags/extended-description-is-probably-too-short

Lintian tag extended-description-is-probably-too-short:

The extended description (the lines after the first line of the "Description:" field) is only one or two lines long. The extended description should provide a user with enough information to decide whether they want to install this package, what it contains, and how it compares to similar packages. One or two lines is normally not enough to do this.

Reference(s): devref 6.2.1, devref 6.2.3

?Lintian/Tags/description-contains-invalid-control-statement

Lintian tag description-contains-invalid-control-statement:

The description contains a line starting with a dot (.). This is not allowed.

Reference(s): policy 5.6.13

?Lintian/Tags/description-too-long

Lintian tag description-too-long:

The first line of the "Description:" must not exceed 80 characters.

Reference(s): policy 3.4.1

?Lintian/Tags/description-starts-with-package-name

Lintian tag description-starts-with-package-name:

The first line of the "Description:" should not start with the package name. For example, the package foo should not have a description like this: "foo is a program that...".

Reference(s): policy 3.4.1

?Lintian/Tags/description-contains-tabs

Lintian tag description-contains-tabs:

The package "Description:" must not contain tab characters.

Reference(s): policy 5.6.13

?Lintian/Tags/description-starts-with-leading-spaces

Lintian tag description-starts-with-leading-spaces:

The package "Description:" starts with leading spaces. Usually, leading spaces are used to switch "verbatim display" on (i.e., lines are not wrapped) so this might be a bug in the package.

?Lintian/Tags/possible-unindented-list-in-extended-description

Lintian tag possible-unindented-list-in-extended-description:

The package "Description:" contains an unindented line which starts with a dash (-) or asterisk (*). If this was meant to be a list of items these lines need to be indented (dselect would word-wrap these lines otherwise).

Reference(s): policy 5.6.13

?Lintian/Tags/description-is-debmake-template

Lintian tag description-is-debmake-template:

The synopsis or the extended description just says "Missing", which is a template provided by debmake.

?Lintian/Tags/description-is-dh_make-template

Lintian tag description-is-dh_make-template:

The synopsis or the extended description has not been changed from the template provided by dh_make.

?Lintian/Tags/description-contains-dh-make-perl-template

Lintian tag description-contains-dh-make-perl-template:

The extended description contains the statement that it was automagically extracted by dh-make-perl. Please check the description for correctness and usefulness and remove the dh-make-perl statement to signal that you have done so.

?Lintian/Tags/description-synopsis-might-not-be-phrased-properly

Lintian tag description-synopsis-might-not-be-phrased-properly:

The synopsis (first line in the package "Description:" field, the short description) ends with a full stop "." character. This is not necessary, as the synopsis doesn't need to be a full sentence. It is recommended that a descriptive phrase is used instead. Note also that the synopsis is not part of the rest of the "Description:" field.

Reference(s): devref 6.2.2

?Lintian/Tags/description-synopsis-is-duplicated

Lintian tag description-synopsis-is-duplicated:

The first line of the extended Description: should not repeat the synopsis exactly. This indicates that either the synopsis is badly formed or that the extended description has been wrongly copied and pasted.

Reference(s): policy 3.4.2

?Lintian/Tags/extended-description-line-too-long

Lintian tag extended-description-line-too-long:

One or more lines in the extended part of the "Description:" field have been found to contain more than 80 characters. For the benefit of users of 80x25 terminals, it is recommended that the lines do not exceed 80 characters.

Reference(s): policy 3.4.1

?Lintian/Tags/description-contains-homepage

Lintian tag description-contains-homepage:

The extended description contains a "Homepage:" pseudo-header following the old Developer's Reference recommendation. As of 1.14.6, dpkg now supports Homepage: as a regular field in debian/control. This header should be moved from the extended description to the fields for the relevant source or binary packages.

?Lintian/Tags/spelling-error-in-description

Lintian tag spelling-error-in-description:

Lintian found a spelling error in the package description. Lintian has a list of common misspellings that it looks for. It does not have a dictionary like a spelling checker does. It is particularly picky about spelling and capitalization in package descriptions since they're very visible to end users.

?Lintian/Tags/capitalization-error-in-description

Lintian tag capitalization-error-in-description:

Lintian found a possible capitalization error in the package description. Lintian has a list of common capitalization errors, primarily of upstream projects, that it looks for. It does not have a dictionary like a spelling checker does. This is a particularly picky check of capitalization in package descriptions, since they're very visible to end users, but it will have false positives for project names used in a context where they should be lowercase, such as package names or executable names.

?Lintian/Tags/description-contains-duplicated-word

Lintian tag description-contains-duplicated-word:

The description contains a duplicated word. Usually this is a mistake, or at least an awkward phrasing.

?Lintian/Tags/using-first-person-in-description

Lintian tag using-first-person-in-description:

You should avoid the use of first person ("I will do this..." or "We recommend..."). The computer is not a person and the description does not speak for the maintainer or maintainers. Instead, use a more neutral construction and try to rephrase into factual statements about the package. For example, rather than saying "I don't recommend this package if you are short on memory," say something like "this package is not suitable for low-memory systems."

?Lintian/Tags/description-possibly-contains-homepage

Lintian tag description-possibly-contains-homepage:

This package has no Homepage field but has a URL in the description and wording that might indicate this is the package Homepage. If it is, add a Homepage control field containing it rather than mentioning it in the package description.

changelog-file

?Lintian/Tags/html-changelog-without-text-version

Lintian tag html-changelog-without-text-version:

If the upstream changelog file is HTML formatted, a text version should also be accessible as "changelog.gz". (This can be created by "lynx -dump -nolist")

Reference(s): policy 12.7

?Lintian/Tags/changelog-file-not-compressed

Lintian tag changelog-file-not-compressed:

Changelog files should be compressed using "gzip -9". Even if they start out small, they will become large with time.

Reference(s): policy 12.7

?Lintian/Tags/debian-news-file-not-compressed

Lintian tag debian-news-file-not-compressed:

NEWS.Debian files should be compressed using "gzip -9". The file must always have the same name.

Reference(s): devref 6.3.4

?Lintian/Tags/changelog-not-compressed-with-max-compression

Lintian tag changelog-not-compressed-with-max-compression:

Changelog files should be compressed using "gzip -9"; i.e., using the maximum compression level via the -9 option to gzip.

Reference(s): policy 12.7

?Lintian/Tags/wrong-name-for-changelog-of-native-package

Lintian tag wrong-name-for-changelog-of-native-package:

The changelog file of a native Debian package (i.e., if there is no upstream source) should usually be installed as /usr/share/doc/pkg/changelog.gz

Reference(s): policy 12.7

?Lintian/Tags/changelog-file-missing-in-native-package

Lintian tag changelog-file-missing-in-native-package:

Each Debian package (which provides a /usr/share/doc/pkg directory) has to install a changelog file. Since this package seems to be a native Debian package (i.e., there is no upstream source), the file should usually be installed as /usr/share/doc/pkg/changelog.gz

Reference(s): policy 12.7

?Lintian/Tags/wrong-name-for-upstream-changelog

Lintian tag wrong-name-for-upstream-changelog:

If there is an upstream changelog file, it should usually be installed as /usr/share/doc/pkg/changelog.gz

Reference(s): policy 12.7

?Lintian/Tags/no-upstream-changelog

Lintian tag no-upstream-changelog:

The package does not install an upstream changelog file. If upstream provides a changelog, it should be accessible as /usr/share/doc/pkg/changelog.gz. It's currently unclear how best to handle multiple binary packages from the same source. Some maintainers put a copy of the upstream changelog in each package, but it can be quite long. Some include it in one package and add symlinks to the other packages, but this requires there be dependencies between the packages. Some only include it in a "central" binary package and omit it from more ancillary packages.

Reference(s): policy 12.7

?Lintian/Tags/wrong-name-for-debian-changelog-file

Lintian tag wrong-name-for-debian-changelog-file:

The Debian changelog file should usually be installed as /usr/share/doc/pkg/changelog.Debian.gz

Reference(s): policy 12.7

?Lintian/Tags/wrong-name-for-debian-news-file

Lintian tag wrong-name-for-debian-news-file:

The Debian news file must be installed as /usr/share/doc/pkg/NEWS.Debian.gz with exactly that capitalization or automated tools may not find it correctly.

Reference(s): devref 6.3.4

?Lintian/Tags/debian-changelog-file-missing

Lintian tag debian-changelog-file-missing:

Each Debian package (which provides a /usr/share/doc/pkg directory) has to install a Debian changelog file /usr/share/doc/pkg/changelog.Debian.gz

Reference(s): policy 12.7

?Lintian/Tags/debian-changelog-file-is-a-symlink

Lintian tag debian-changelog-file-is-a-symlink:

The Debian changelog file is a symlink to a file in a different directory or not found in this package. Please don't do this. It makes package checking and manipulation unnecessarily difficult. Because it was a symlink, the Debian changelog file was not checked for other problems. (Symlinks to another file in /usr/share/doc/pkg or a subdirectory thereof are fine and should not trigger this warning.) To refer to the changelog, copyright, and other documentation files of another package that this one depends on, please symlink the entire /usr/share/doc/pkg directory rather than individual files.

?Lintian/Tags/debian-changelog-file-missing-or-wrong-name

Lintian tag debian-changelog-file-missing-or-wrong-name:

Each Debian package (which provides a /usr/share/doc/pkg directory) must install a Debian changelog file in /usr/share/doc/pkg/changelog.Debian.gz A common error is to name the Debian changelog like an upstream changelog (/usr/share/doc/pkg/changelog.gz); therefore, lintian will apply further checks to such a file if it exists even after issuing this error.

Reference(s): policy 12.7

?Lintian/Tags/debian-changelog-file-contains-obsolete-user-emacs-settings

Lintian tag debian-changelog-file-contains-obsolete-user-emacs-settings:

The add-log-mailing-address variable is no longer honored in debian-changelog-mode, and should not appear in packages' changelog files. Instead, put something like this in your ~/.emacs:
(setq debian-changelog-mailing-address "userid@debian.org")

?Lintian/Tags/debian-changelog-file-contains-debmake-default-email-address

Lintian tag debian-changelog-file-contains-debmake-default-email-address:

The changelog file contains an email address (<..@unknown>) that was not updated to the maintainer's real address.

?Lintian/Tags/debian-changelog-file-contains-invalid-email-address

Lintian tag debian-changelog-file-contains-invalid-email-address:

The changelog file contains an invalid email address: the domain needs at least one dot. This looks like a mistake.

?Lintian/Tags/debian-changelog-file-uses-obsolete-national-encoding

Lintian tag debian-changelog-file-uses-obsolete-national-encoding:

The Debian changelog file must be valid UTF-8, an encoding of the Unicode character set. There are many ways to convert a changelog from an obsoleted encoding like ISO-8859-1; you may for example use "iconv" like:
- $ iconv -f ISO-8859-1 -t UTF-8 changelog > changelog.new $ mv changelog.new changelog

Reference(s): policy 4.4

?Lintian/Tags/debian-news-file-uses-obsolete-national-encoding

Lintian tag debian-news-file-uses-obsolete-national-encoding:

The NEWS.Debian file must be valid UTF-8, an encoding of the Unicode character set. There are many ways to convert a changelog from an obsoleted encoding like ISO-8859-1; you may for example use "iconv" like:
- $ iconv -f ISO-8859-1 -t UTF-8 NEWS.Debian > NEWS.Debian.new $ mv NEWS.Debian.new NEWS.Debian

?Lintian/Tags/latest-debian-changelog-entry-without-new-date

Lintian tag latest-debian-changelog-entry-without-new-date:

The latest Debian changelog entry has either the same or even an older date as the entry before.

?Lintian/Tags/latest-debian-changelog-entry-without-new-version

Lintian tag latest-debian-changelog-entry-without-new-version:

The latest Debian changelog entry has a version number that's either the same or smaller than the version number of the entry before.

?Lintian/Tags/latest-debian-changelog-entry-changed-to-native

Lintian tag latest-debian-changelog-entry-changed-to-native:

The latest package has a Debian native version number, while the previous version number was not native. This is usually a mistake made by the maintainer by forgetting to append -1 when uploading a new upstream version.

?Lintian/Tags/possible-new-upstream-release-without-new-version

Lintian
Tags
Template

conffiles

files

etcfiles

menu-format

shared-libs

infofiles

copyright-file

md5sums

description

changelog-file

LintianTagsTemplate

conffiles

files

etcfiles

menu-format

shared-libs

infofiles

copyright-file

md5sums

description

changelog-file

Lintian
Tags
Template