--- /dev/null
+Check-Script: fields
+Author: Marc 'HE' Brockschmidt <marc@marcbrockschmidt.de>
+Abbrev: fld
+Type: binary, udeb, source
+Unpack-Level: 1
+Needs-Info: debfiles, source-control-file
+Info: This script checks the syntax of the fields in package control files,
+ as described in the Policy Manual.
+
+Tag: unsupported-source-format
+Severity: serious
+Certainty: certain
+Info: This package uses a different source package format than 1.0. At
+ present, only <tt>Format: 1.0</tt> packages are permitted by the Debian
+ archive software. Newer package formats are supported by dpkg, but they
+ should not yet be used for upload to Debian.
+
+Tag: no-package-name
+Severity: serious
+Certainty: certain
+Info: The package does not have a "Package:" field in its control file.
+Ref: policy 5.3
+
+Tag: bad-package-name
+Severity: serious
+Certainty: certain
+Info: A package name should be at least two characters long, must consist
+ of the alphanumerics and "+" "-" and ".", and must start with an
+ alphanumeric character.
+Ref: policy 5.6.7
+
+Tag: package-not-lowercase
+Severity: serious
+Certainty: certain
+Info: New packages should not use uppercase characters in their names.
+Ref: policy 5.6.7
+
+Tag: no-version-field
+Severity: serious
+Certainty: certain
+Info: The package does not have a "Version:" field in its control file.
+Ref: policy 5.3
+
+Tag: bad-version-number
+Severity: serious
+Certainty: certain
+Info: The version number fails one of the syntactic requirements of dpkg.
+Ref: policy 5.6.12
+
+Tag: upstream-version-not-numeric
+Severity: important
+Certainty: certain
+Info: The upstream version number should start with a digit.
+Ref: policy 5.6.12
+
+Tag: debian-revision-not-well-formed
+Severity: normal
+Certainty: certain
+Info: The debian version part (the part after the -) should consist of one
+ or two dot-separated parts: one for a regular maintainer release or two
+ for a source-NMU.
+Ref: devref 5.11.2, policy 5.6.12
+
+Tag: debian-revision-should-not-be-zero
+Severity: important
+Certainty: certain
+Info: The debian version part (the part after the -) should start with one,
+ not with zero. This is to ensure that a correctly-done Maintainer Upload will
+ always have a higher version number than a Non-Maintainer upload: a NMU could
+ have been prepared which introduces this upstream version with
+ Debian-revision -0.1
+Ref: devref 5.11.2
+
+Tag: no-architecture-field
+Severity: serious
+Certainty: certain
+Info: The package does not have an "Architecture:" field in its control file.
+Ref: policy 5.3
+
+Tag: magic-arch-in-arch-list
+Severity: serious
+Certainty: certain
+Info: The special architecture value "any" only make sense if it occurs
+ alone. The value "all" may appear together with other architectures
+ in a *.dsc file but must occur alone if used in a binary package.
+Ref: policy 5.6.8
+
+Tag: unknown-architecture
+Severity: normal
+Certainty: possible
+Info: This package claims to be for an unknown architecture. The
+ architecture should be one of the values supported by dpkg or one of the
+ special values "all" or "any". The special value "source" is only used
+ in *.changes files and does not make sense in a binary package or a *.dsc
+ file.
+
+Tag: too-many-architectures
+Severity: serious
+Certainty: certain
+Info: A binary package should list exactly one architecture (the one it is
+ compiled for), or the special value "all" if it is architecture-independent.
+Ref: policy 5.6.8
+
+Tag: arch-any-in-binary-pkg
+Severity: serious
+Certainty: certain
+Info: The special architecture value "any" does not make sense in a binary
+ package.
+Ref: policy 5.6.8
+
+Tag: aspell-package-not-arch-all
+Severity: normal
+Certainty: certain
+Info: This package appears to be an aspell dictionary package, but it is
+ not Architecture: all. The binary hashes should be built at install-time
+ by calling aspell-autobuildhash, so the contents of the package should be
+ architecture-independent.
+Ref: aspell-autobuildhash(8)
+
+Tag: no-maintainer-field
+Severity: serious
+Certainty: certain
+Info: The package does not have a "Maintainer:" field in its control file.
+Ref: policy 5.3
+
+Tag: maintainer-name-missing
+Severity: serious
+Certainty: certain
+Info: The maintainer field seems to contain just an email address. It must
+ contain the package maintainer's name and email address.
+Ref: policy 5.6.2
+
+Tag: maintainer-address-missing
+Severity: serious
+Certainty: certain
+Info: The maintainer field should contain the package maintainer's name and
+ email address, with the name followed by the address inside angle
+ brackets (< and >). The address seems to be missing.
+Ref: policy 5.6.2
+
+Tag: maintainer-address-malformed
+Severity: important
+Certainty: certain
+Info: The maintainer field could not be parsed according to the rules in
+ the Policy Manual.
+Ref: policy 5.6.2
+
+Tag: maintainer-not-full-name
+Severity: normal
+Certainty: possible
+Info: The "name" part of this maintainer field is just one word, so it
+ might not be a full name.
+
+Tag: maintainer-address-looks-weird
+Severity: normal
+Certainty: possible
+Info: The maintainer address does not have whitespace between the name
+ and the email address.
+
+Tag: maintainer-address-is-on-localhost
+Severity: important
+Certainty: certain
+Info: The maintainer address includes localhost(.localdomain), which is
+ an invalid e-mail address.
+Ref: policy 5.6.2
+
+Tag: uploader-name-missing
+Severity: important
+Certainty: certain
+Info: The uploader field seems to contain just an email address. It must
+ contain the package uploader's name and email address.
+Ref: policy 5.6.2
+
+Tag: uploader-address-missing
+Severity: important
+Certainty: certain
+Info: The uploader field should contain the package uploader's name and
+ email address, with the name followed by the address inside angle
+ brackets (< and >). The address seems to be missing.
+Ref: policy 5.6.2
+
+Tag: uploader-address-malformed
+Severity: important
+Certainty: certain
+Info: The uploader field could not be parsed according to the rules in
+ the Policy Manual.
+Ref: policy 5.6.2
+
+Tag: uploader-not-full-name
+Severity: normal
+Certainty: possible
+Info: The "name" part of this uploader field is just one word, so it
+ might not be a full name.
+
+Tag: uploader-address-looks-weird
+Severity: normal
+Certainty: possible
+Info: The uploader address does not have whitespace between the name
+ and the email address.
+
+Tag: uploader-address-is-on-localhost
+Severity: important
+Certainty: certain
+Info: The uploader address includes localhost(.localdomain), which is
+ an invalid e-mail address.
+Ref: policy 5.6.2
+
+Tag: wrong-debian-qa-address-set-as-maintainer
+Severity: important
+Certainty: certain
+Info: Orphaned packages should no longer have the address
+ <debian-qa@lists.debian.org> in the Maintainer field.
+ .
+ The correct Maintainer field for orphaned packages is
+ Debian QA Group <packages@qa.debian.org>.
+Ref: devref 5.9.4
+
+Tag: wrong-debian-qa-group-name
+Severity: important
+Certainty: certain
+Info: Orphaned packages should have "Debian QA Group
+ <packages@qa.debian.org>" in the maintainer field.
+Ref: devref 5.9.4
+
+Tag: no-human-maintainers
+Severity: normal
+Certainty: possible
+Info: The Maintainer address for this package is a mailing list and there
+ are no Uploaders listed. Team-maintained packages should list the human
+ maintainers in the Uploaders field.
+Ref: devref 5.12
+
+Tag: no-source-field
+Severity: serious
+Certainty: certain
+Info: The package does not have a "Source:" field in its control file.
+Ref: policy 5.2
+
+Tag: source-field-does-not-match-pkg-name
+Severity: serious
+Certainty: certain
+Info: The source package's filename is not the same as the name given
+ in its Source field. The Source field should name the package.
+Ref: policy 5.6.1
+
+Tag: source-field-malformed
+Severity: important
+Certainty: certain
+Info: In a binary package, the Source field should identify the source
+ package from which the package was compiled. It should be the
+ source package name, optionally followed by a version number
+ between parentheses.
+Ref: policy 5.6.1
+
+Tag: essential-in-source-package
+Severity: important
+Certainty: certain
+Info: This field should only appear in binary packages.
+Ref: policy 5.6.9
+
+Tag: essential-no-not-needed
+Severity: normal
+Certainty: certain
+Info: Having "Essential: no" is the same as not having the field at all,
+ so it just makes the Packages file longer with no benefit.
+Ref: policy 5.6.9
+
+Tag: unknown-essential-value
+Severity: important
+Certainty: certain
+Info: The only valid values for the Essential field are yes and no.
+Ref: policy 5.6.9
+
+Tag: no-section-field
+Severity: normal
+Certainty: certain
+Info: The package does not have a "Section:" field in its control file.
+ .
+ The field is mandatory for source packages and optional for binary
+ packages, which use the source package's value as default is nothing
+ else is specified.
+Ref: policy 5.3
+
+Tag: unknown-section
+Severity: normal
+Certainty: certain
+Info: The "Section:" field in this package's control file is not one of
+ the sections in use on the ftp archive. Valid sections are currently
+ admin, comm, cli-mono, database, debug, devel, doc,
+ editors, electronics, embedded, fonts, games, gnome, gnu-r,
+ gnustep, graphics, hamradio, haskell, httpd, interpreters,
+ java, kde, libdevel, libs, lisp, localization, kernel, mail,
+ math, misc, net, news, ocaml, oldlibs, otherosfs, perl,
+ php, python, ruby, science, shells, sound, tex, text,
+ utils, vcs, video, web, x11, xfce, zope.
+ .
+ The section name should be preceded by "non-free/" if the package
+ is in the non-free archive area, and by "contrib/" if the package
+ is in the contrib archive area.
+Ref: policy 2.4
+
+Tag: section-is-dh_make-template
+Severity: important
+Certainty: certain
+Info: The "Section:" field in this package's control file is set to
+ unknown. This is not a valid section, and usually means a dh_make
+ template control file was used and never modified to set the correct
+ section.
+Ref: policy 2.4
+
+Tag: wrong-section-for-udeb
+Severity: normal
+Certainty: certain
+Info: udeb packages should have "Section: debian-installer".
+
+Tag: no-priority-field
+Severity: normal
+Certainty: certain
+Info: The package does not have a "Priority:" field in its control file.
+ .
+ The Priority field can be included in a binary package by passing
+ the -ip or -isp flags to dpkg-gencontrol when building the package.
+ The field is optional in binary packages.
+Ref: policy 5.3
+
+Tag: unknown-priority
+Severity: important
+Certainty: certain
+Info: The "Priority:" field in this package's control file is not one of
+ the priorities defined in the Policy Manual.
+Ref: policy 2.5
+
+Tag: superfluous-clutter-in-homepage
+Severity: normal
+Certainty: certain
+Info: The "Homepage:" field in this package's control file contains
+ superfluous markup around the URL, like enclosing < and >.
+ This is unnecessary and needlessly complicates using this information.
+Ref: policy 5.6.23
+
+Tag: bad-homepage
+Severity: normal
+Certainty: certain
+Info: The "Homepage:" field in this package's control file does not
+ contain a valid absolute URL. Most probably you forgot to specify
+ the scheme (e.g. http).
+
+Tag: no-homepage-field
+Severity: pedantic
+Certainty: possible
+Info: This non-native package lacks a <tt>Homepage</tt> field. If the
+ package has an upstream home page that contains useful information or
+ resources for the end user, consider adding a <tt>Homepage</tt> control
+ field to <tt>debian/control</tt>.
+Ref: policy 5.6.23
+
+Tag: homepage-for-cpan-package-contains-version
+Severity: minor
+Certainty: certain
+Info: The Homepage field for this package points to CPAN and the URL
+ includes the version. It's better to link to the unversioned CPAN page
+ so that the URL doesn't have to be updated for each new release. For
+ example, use:
+ .
+ http://search.cpan.org/~samtregar/HTML-Template/
+ .
+ not:
+ .
+ http://search.cpan.org/~samtregar/HTML-Template-2.9/
+
+Tag: obsolete-field
+Severity: important
+Certainty: certain
+Info: This field is listed in the Policy Manual as obsolete and
+ not-to-be-present in any package.
+Ref: policy D.2.6
+
+Tag: unknown-field-in-dsc
+Severity: minor
+Certainty: certain
+Info: See the Policy Manual for a list of the possible fields in
+ a source package control file.
+Ref: policy 5.4
+
+Tag: unknown-field-in-control
+Severity: minor
+Certainty: possible
+Info: See the Policy Manual for a list of the possible fields in
+ a binary package control file.
+ .
+ In udeb packages the fields pre-depends, conflicts, essential and
+ suggests are disallowed, but they can contain the new fields
+ subarchitecture and installer-menu-item.
+Ref: policy 5.3
+
+Tag: multiline-field
+Severity: important
+Certainty: certain
+Info: Most control fields must have only a single line of data.
+Ref: policy 5.1
+
+Tag: alternates-not-allowed
+Severity: important
+Certainty: certain
+Info: Only the "Depends", "Recommends", "Suggests" and "Pre-Depends"
+ fields may specify alternate dependencies using the "|" symbol.
+Ref: policy 7.1
+
+Tag: versioned-provides
+Severity: important
+Certainty: certain
+Ref: policy 7.1
+Info: The "Provides" field may not specify a version range.
+
+Tag: obsolete-relation-form
+Ref: policy 7.1
+Severity: normal
+Certainty: certain
+Info: The forms "<" and ">" mean "<=" and ">=", not "<<"
+ and ">>" as one might expect. For that reason these forms are
+ obsolete, and should not be used in new packages. Use the longer forms
+ instead.
+
+Tag: bad-version-in-relation
+Ref: policy 5.6.12
+Severity: important
+Certainty: certain
+Info: The version number used in this relationship does not match the
+ defined format of a version number.
+
+Tag: package-relation-with-self
+Severity: normal
+Certainty: possible
+Info: The package declares a relationship with itself. This is not very
+ useful, except in the case of a package Conflicting with itself, if its
+ package name doubles as a virtual package.
+
+Tag: bad-relation
+Severity: important
+Certainty: certain
+Info: The package declares a relationship that could not be parsed according
+ to the rules given in the Policy Manual.
+Ref: policy 7.1
+
+Tag: new-essential-package
+Severity: important
+Certainty: possible
+Info: This package has the Essential flag set. New Essential packages
+ are sufficiently rare that it seems worth warning about. They should
+ be discussed on debian-devel first.
+Ref: policy 3.8
+
+Tag: doc-package-depends-on-main-package
+Severity: normal
+Certainty: possible
+Info: The name of this package suggests that it is a documentation package.
+ It is usually not desirable for documentation packages to depend on the
+ packages they document, because users may want to install the docs before
+ they decide whether they want to install the package. Also, documentation
+ packages are often architecture-independent, so on other architectures
+ the package on which it depends may not even exist.
+
+Tag: depends-on-obsolete-package
+Severity: important
+Certainty: possible
+Info: The package depends on a package that has been superseded.
+ If the superseded package is part of an ORed group, it should not be
+ the first package in the group.
+
+Tag: ored-depends-on-obsolete-package
+Severity: minor
+Certainty: possible
+Info: The package depends on an ORed group of packages which includes
+ a package that has been superseded.
+
+Tag: build-depends-on-obsolete-package
+Severity: important
+Certainty: possible
+Info: The package build-depends on a package that has been superseded.
+ If the superseded package is part of an ORed group, it should not be
+ the first package in the group.
+
+Tag: ored-build-depends-on-obsolete-package
+Severity: minor
+Certainty: possible
+Info: The package build-depends on an ORed group of packages which includes
+ a package that has been superseded.
+
+Tag: depends-on-old-emacs
+Severity: normal
+Certainty: possible
+Info: The package lists an old version of Emacs as its first dependency.
+ It should probably be updated to support the current version of Emacs
+ in the archive and then list that version first in the list of Emacs
+ flavors it supports.
+ .
+ If the package intentionally only supports older versions of Emacs (if,
+ for example, it was included with later versions of Emacs), add a lintian
+ override.
+
+Tag: depends-on-x-metapackage
+Severity: important
+Certainty: certain
+Info: Packages that are not themselves metapackages must not depend on X
+ Window System metapackages.
+ .
+ The metapackages xorg, xorg-dev, x-window-system, x-window-system-dev, and
+ x-window-system-core exist only for the benefit of users and dependencies
+ for other metapackages and should not be used in regular package
+ dependencies.
+
+Tag: build-depends-on-x-metapackage
+Severity: important
+Certainty: certain
+Info: Packages must not build-depend on X Window System metapackages.
+ .
+ The metapackages xorg, xorg-dev, x-window-system, x-window-system-dev, and
+ x-window-system-core exist only for the benefit of users and should not
+ be used in package build dependencies.
+
+Tag: depends-on-essential-package-without-using-version
+Severity: important
+Certainty: certain
+Ref: policy 3.5
+Info: The package declares a depends on an essential package, e.g. dpkg,
+ without using a versioned depends. Packages do not need to depend on
+ essential packages; essential means that they will always be present.
+ The only reason to list an explicit dependency on an essential package
+ is if you need a particular version of that package, in which case the
+ version should be given in the dependency.
+
+Tag: build-depends-on-essential-package-without-using-version
+Severity: important
+Certainty: certain
+Ref: policy 4.2
+Info: The package declares a build-depends on an essential package, e.g. dpkg,
+ without using a versioned depends. Packages do not need to build-depend on
+ essential packages; essential means that they will always be present.
+ The only reason to list an explicit dependency on an essential package
+ is if you need a particular version of that package, in which case the
+ version should be given in the dependency.
+
+Tag: virtual-package-depends-without-real-package-depends
+Severity: normal
+Certainty: possible
+Info: The package declares a depends on a virtual package without listing a
+ real package as an alternative first.
+ .
+ If this package could ever be a build dependency, it should list a real
+ package as the first alternative to any virtual package in its Depends.
+ Otherwise, the build daemons will not be able to provide a consistent
+ build environment.
+ .
+ If it will never be a build dependency, this isn't necessary, but you may
+ want to consider doing so anyway if there is a real package providing
+ that virtual package that most users will want to use.
+
+Tag: invalid-arch-string-in-source-relation
+Severity: important
+Certainty: possible
+Ref: policy 5.6.8
+Info: The architecture string in the source relation does not follow policy.
+ A common cause of this is a comma in the arch, i.e. [i386, m68k], it should
+ be [i386 m68k].
+
+Tag: depends-on-build-essential-package-without-using-version
+Severity: important
+Certainty: certain
+Ref: policy 4.2
+Info: The package declares a depends on a build essential package without
+ using a versioned depends. Packages do not have to build-depend on any
+ package included in build-essential. It is the responsibility of anyone
+ building packages to have all build-essential packages installed. The
+ only reason for an explicit dependency on a package included in
+ build-essential is if a particular version of that package is required,
+ in which case the dependency should include the version.
+
+Tag: package-depends-on-an-x-font-package
+Severity: important
+Certainty: certain
+Info: Packages must not depend on X Window System font packages.
+ .
+ If one or more of the fonts so packaged are necessary for proper operation
+ of the package with which they are associated the font package may be
+ Recommended; if the fonts merely provide an enhancement, a Suggests
+ relationship may be used.
+Ref: policy 11.8.5
+
+Tag: build-depends-indep-without-arch-indep
+Severity: important
+Certainty: certain
+Ref: policy 7.7
+Info: The control file specifies source relations for architecture-independent
+ packages, but no architecture-independent packages are built.
+
+Tag: build-depends-without-arch-dep
+Severity: minor
+Certainty: possible
+Ref: policy 7.7
+Info: The control file lists the given package in Build-Depends, but no
+ architecture-dependent packages are built. If all the packages built are
+ architecture-independent, the only packages that should be listed in
+ Build-Depends are those required to run the clean target (such as
+ debhelper if you use dh_clean). Other build dependencies should be listed
+ in Build-Depends-Indep instead.
+
+Tag: clean-should-be-satisfied-by-build-depends
+Severity: important
+Certainty: certain
+Ref: policy 7.7
+Info: The specified package is required to run the clean target of
+ <tt>debian/rules</tt> and therefore must be listed in Build-Depends, not
+ Build-Depends-Indep, even if no architecture-dependent packages are
+ built.
+
+Tag: missing-build-dependency
+Severity: important
+Certainty: certain
+Ref: policy 4.2
+Info: The package doesn't specify a build dependency on a package that is
+ used in <tt>debian/rules</tt>.
+ .
+ lintian intentionally does not take into account transitive dependencies.
+ Even if the package build-depends on some package that in turn
+ build-depends on the needed package, an explicit build dependency should
+ be added. Otherwise, a latent bug is created that will appear without
+ warning if the other package is ever updated to change its dependencies.
+ Even if this seems unlikely, please always add explicit build
+ dependencies on every non-essential, non-build-essential package that is
+ used directly during the build.
+
+Tag: missing-python-build-dependency
+Severity: important
+Certainty: certain
+Ref: policy 4.2
+Info: The package appears to use Python as part of its build process in
+ <tt>debian/rules</tt> but doesn't depend on Python.
+ .
+ Normally, packages that use Python as part of the build process should
+ build-depend on one of python, python-all, python-dev, or python-all-dev
+ depending on whether they support multiple versions of Python and whether
+ they're building modules or only using Python as part of the package
+ build process. Packages that depend on a specific version of Python may
+ build-depend on the appropriate pythonX.Y or pythonX.Y-dev package
+ instead.
+
+Tag: missing-dh_python-build-dependency
+Severity: important
+Certainty: certain
+Ref: dh_python(1)
+Info: The package runs dh_python in <tt>debian/rules</tt> but doesn't
+ build-depend on python or python-dev. dh_python requires
+ <tt>/usr/bin/python</tt> to run, so packages using dh_python must
+ build-depend on python (or python-dev or python-all-dev, which in turn
+ depend on python), even if they don't otherwise need Python to build.
+
+Tag: build-conflicts-with-build-dependency
+Severity: important
+Certainty: certain
+Ref: policy 7.7
+Info: The package build-conflicts with a package that it also
+ build-depends on.
+
+Tag: package-has-a-duplicate-build-relation
+Severity: normal
+Certainty: possible
+Info: The package declares the given build relations on the same package
+ in either Build-Depends or Build-Depends-Indep, but the build relations
+ imply each other and are therefore redundant.
+
+Tag: build-depends-on-1-revision
+Severity: normal
+Certainty: possible
+Info: The package declares a build dependency on a version of a package
+ with a -1 Debian revision such as "libfoo (>= 1.2-1)". Such a
+ dependency will not be satisfied by a backport of libfoo 1.2-1 and
+ therefore makes backporting unnecessarily difficult. Normally, the -1
+ version is unneeded and a dependency such as "libfoo (>= 1.2)" would
+ be sufficient. If there was an earlier -0.X version of libfoo that would
+ not satisfy the dependency, use "libfoo (>= 1.2-1~)" instead.
+
+Tag: needlessly-depends-on-awk
+Severity: important
+Certainty: certain
+Info: The package seems to declare a relation on awk. awk is a virtual
+ package, but it is special since it's de facto essential. If you don't
+ need to depend on a specific version of awk (which wouldn't work anyway,
+ as dpkg doesn't support versioned provides), you should remove the
+ dependency on awk.
+
+Tag: package-depends-on-multiple-libstdc-versions
+Severity: important
+Certainty: possible
+Info: The package seems to declare several relations to a libstdc version.
+ This is not only sloppy but in the case of libraries, it may well break
+ the runtime execution of programs.
+
+Tag: package-depends-on-multiple-tcl-versions
+Severity: important
+Certainty: possible
+Info: The package seems to declare several relations to a tcl version.
+ This is not only sloppy but in the case of libraries, it may well break
+ the runtime execution of programs.
+
+Tag: package-depends-on-multiple-tclx-versions
+Severity: important
+Certainty: possible
+Info: The package seems to declare several relations to a tclx version.
+ This is not only sloppy but in the case of libraries, it may well break
+ the runtime execution of programs.
+
+Tag: package-depends-on-multiple-tk-versions
+Severity: important
+Certainty: possible
+Info: The package seems to declare several relations to a tk version.
+ This is not only sloppy but in the case of libraries, it may well break
+ the runtime execution of programs.
+
+Tag: package-depends-on-multiple-tkx-versions
+Severity: important
+Certainty: possible
+Info: The package seems to declare several relations to a tkx version.
+ This is not only sloppy but in the case of libraries, it may well break
+ the runtime execution of programs.
+
+Tag: package-depends-on-multiple-libpng-versions
+Severity: important
+Certainty: possible
+Info: The package seems to declare several relations to a libpng version.
+ This is not only sloppy but in the case of libraries, it may well break
+ the runtime execution of programs.
+
+Tag: depends-on-libdb1-compat
+Severity: important
+Certainty: certain
+Info: The package seems to declare a relation on libdb1-compat.
+ This library exists for compatibility with applications built against
+ glibc 2.0 or 2.1. There is intentionally no corresponding development
+ package. Do not link new applications against this library!
+
+Tag: depends-on-python-minimal
+Severity: important
+Certainty: certain
+Info: The python-minimal package (and versioned variants thereof) exists
+ only to possibly become an Essential package. Depending on it is always
+ an error since it should never be installed without python. If it
+ becomes Essential, there is no need to depend on it, and until then,
+ packages that require Python must depend on python.
+
+Tag: depends-exclusively-on-makedev
+Severity: normal
+Certainty: certain
+Info: This package depends on makedev without a udev alternative. This
+ probably means that it doesn't have udev rules and relies on makedev to
+ create devices, which won't work if udev is installed and running.
+ Alternatively, it may mean that there are udev rules, but udev was not
+ added as an alternative to the makedev dependency.
+
+Tag: dbg-package-missing-depends
+Severity: normal
+Certainty: certain
+Info: The given binary package has a name of the form of "X-dbg", indicating it
+ contains detached debugging symbols for the package X. If so, it should
+ depend on the corresponding package, generally with (= ${binary:Version})
+ since the debugging symbols are only useful with the binaries created by
+ the same build.
+ .
+ If this package provides debugging symbols for multiple other
+ packages, it should normally depend on all of those packages as
+ alternatives. In other words, <tt>pkga (= ${binary:Version}) | pkgb (=
+ ${binary:Version)</tt> and so forth.
+
+Tag: conflicts-with-dependency
+Severity: important
+Certainty: certain
+Ref: policy 7.4
+Info: The package seems to conflict with one of its dependencies,
+ recommendations, or suggestions by listing it in Conflicts or Breaks.
+
+Tag: breaks-without-version
+Severity: normal
+Certainty: possible
+Ref: policy 7.3
+Info: This package declares a Breaks relationship with another package
+ that has no version number. Normally, Breaks should be used to indicate
+ an incompatibility with a specific version of another package, or with
+ all versions predating a fix. If the two packages can never be installed
+ at the same time, Conflicts should normally be used instead.
+
+Tag: bad-menu-item
+Severity: important
+Certainty: certain
+Info: The field Installer-Menu-Item should only contain positive integer
+ values.
+
+Tag: redundant-origin-field
+Severity: normal
+Certainty: certain
+Info: You use the Origin field though the field value is the default (Debian).
+ In this case the field is redundant and should be removed.
+
+Tag: binary-nmu-uses-old-version-style
+Severity: normal
+Certainty: certain
+Ref: devref 5.10.2.1
+Info: The version number of a binary NMU should be formed by appending
+ <tt>+b</tt> and a digit to the source version. This version scheme is
+ special-cased by the archive software. The -x.x.x version number style
+ should no longer be used.
+
+Tag: binary-nmu-debian-revision-in-source
+Severity: normal
+Certainty: certain
+Ref: devref 5.10.2.1
+Info: The version number of your source package ends in +b and a number or
+ has a Debian revision containing three parts. These version numbers are
+ used by binary NMUs and should not be used as the source version. (The
+ +b form is the current standard; the three-part version number now
+ obsolete.)
+
+Tag: dfsg-version-in-native-package
+Severity: normal
+Certainty: certain
+Info: The version number of this package contains "dfsg", but it's a
+ native package. "dfsg" is conventionally used in the upstream version of
+ packages that are repackaged for Debian Free Software Guidelines
+ compliance reasons. The convention doesn't make sense in native
+ packages.
+
+Tag: dfsg-version-with-period
+Severity: minor
+Certainty: possible
+Info: The version number of this package contains ".dfsg", probably in a
+ form like "1.2.dfsg1". There is a suble sorting problem with this
+ version method: 1.2.dfsg1 is considered a later version than 1.2.1. If
+ upstream adds another level to its versioning, finding a good version
+ number for the next upstream release will be awkward.
+ .
+ Upstream may never do this, in which case this isn't a problem, but it's
+ normally better to use "+dfsg" instead (such as "1.2+dfsg1"). "+" sorts
+ before ".", so 1.2 < 1.2+dfsg1 < 1.2.1 as normally desired.
+
+Tag: dfsg-version-misspelled
+Severity: minor
+Certainty: certain
+Info: The version number of this package contains "dsfg". You probably
+ meant "dfsg", the conventional marker for upstream packages that are
+ repackaged for Debian Free Software Guidelines compliance reasons.
+
+Tag: redundant-bugs-field
+Severity: normal
+Certainty: certain
+Info: You use the Bugs field though the field value is the default
+ (debbugs://bugs.debian.org/). In this case the field is redundant and
+ should be removed.
+
+Tag: build-depends-on-build-essential
+Info: You depend on the build-essential package, which is only a
+Severity: important
+Certainty: certain
+Ref: policy 7.7
+ meta-package depending on build tools that have to be installed in all
+ build environments.
+
+Tag: malformed-python-version
+Severity: important
+Certainty: certain
+Ref: python-policy 2.3
+Info: The Python-Version control field is not in one of the valid
+ formats. It should be in one of the following formats:
+ .
+ all
+ current
+ current, >= X.Y
+ >= X.Y
+ >= A.B, << X.Y
+ A.B, X.Y
+ .
+ (One or more specific versions may be listed with the last form.) A.B
+ and X.Y should be Python versions.
+
+Tag: old-versioned-python-dependency
+Severity: normal
+Certainty: certain
+Info: This package appears to be an architecture-independent Python module
+ but has a dependency on a version of python less than a particular
+ version, doesn't use python-support and no Python-Version control field.
+ This normally means that the package isn't using the current Python
+ policy; most architecture-independent Python packages will work with any
+ future version of Python if they follow the new policy.
+ .
+ If this package really does require only a particular range of Python
+ versions and uses python-central, add a Python-Version control field (as
+ described in 2.3 of the Python policy) to resolve this warning.
+
+Tag: malformed-dm-upload-allowed
+Severity: important
+Certainty: certain
+Ref: http://www.debian.org/vote/2007/vote_003
+Info: The Dm-Upload-Allowed field in this package is set to something
+ other than "yes". The only standardized value for this field in the
+ Debian GR is "yes" and other values (including capitalization variants)
+ may not work as expected.
+
+Tag: wrong-section-according-to-package-name
+Severity: normal
+Certainty: certain
+Info: This package has a name suggesting that it belongs to a section
+ other than the one it is currently categorized in.
+
+Tag: debug-package-should-be-priority-extra
+Severity: normal
+Certainty: certain
+Info: This package has a name suggesting that it contains detached
+ debugging symbols. If so, it should have priority "extra" since users
+ normally do not need such packages.
+
+Tag: maintainer-also-in-uploaders
+Severity: minor
+Certainty: certain
+Info: The maintainer value also appears on the <tt>Uploaders</tt> field.
+ There were some reasons why this was useful when Uploaders support was
+ first introduced, but those have long-since been fixed and there is no
+ longer any need to list the maintainer in Uploaders. The duplicate
+ information should probably be removed.
+
+Tag: duplicate-uploader
+Severity: minor
+Certainty: certain
+Info: The uploader appears more than once in the <tt>Uploaders</tt>
+ field. The duplicate information should be removed.
+
+Tag: versioned-dependency-satisfied-by-perl
+Severity: normal
+Certainty: certain
+Info: This package declares an unnecessary versioned dependency
+ on a package that is also provided by one of the Perl core packages
+ (perl, perl-base, perl-modules) with at least the required version.
+ .
+ As versioned dependencies are not satisfied by provided packages,
+ this unnecessarily pulls in a separately packaged newer version
+ of the module.
+ .
+ The recommended way to express the dependency without needless
+ complications on backporting packages is to use alternative dependencies.
+ The Perl core package should be the preferred alternative and the
+ versioned dependency a secondary one.
+ .
+ Example: perl-modules (>= 5.10.0) | libmodule-build-perl (>= 0.26)
+Ref: policy 7.5
+
+Tag: package-superseded-by-perl
+Severity: normal
+Certainty: certain
+Info: This package is also provided by one of the Perl core packages
+ (perl, perl-base, perl-modules), and the core version is at least
+ as new as this one.
+ .
+ The package should either be upgraded to a newer upstream version
+ or removed from the archive as unnecessary. In the removal case, any
+ versioned dependencies on this package must first be changed to include
+ the Perl core package (because versioned dependencies are not satisfied
+ by provided packages).
+ .
+ The recommended way to express the dependency without needless
+ complications on backporting packages is to use alternative dependencies.
+ The Perl core package should be the preferred alternative and the
+ versioned dependency a secondary one.
+ .
+ Example: perl-modules (>= 5.10.0) | libmodule-build-perl (>= 0.26)
+Ref: policy 7.5
+
+Tag: vcs-field-uses-not-recommended-uri-format
+Severity: minor
+Certainty: possible
+Info: The VCS-* field uses an URI which doesn't match the recommended
+ format, but still looks valid. Examples for not recommended URI formats
+ are protocols that require authentication (like SSH). Instead where
+ possible you should provide an URI that is accessible for everyone
+ without authentication.
+
+Tag: vcs-field-uses-unknown-uri-format
+Severity: normal
+Certainty: possible
+Info: The VCS-* field uses an URI which doesn't match any known format.
+ You might have forgotten the protocol before the hostname.
projects / maemian / blobdiff