Your message dated Fri, 11 Aug 2017 12:44:51 -0700
with message-id <>
and subject line Closing inactive Policy bugs
has caused the Debian Bug report #656569,
regarding require test suite or demo for all libraries
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact

Debian Bug Tracking System
Contact with problems
--- Begin Message ---
Package: debian-policy
Severity: normal

Dear Maintainer
What has lead up to this situation was the discovery of libogre 1.7.3-3 in the
testing branch.  I will be very simple it don't work at all even with the most
basic OGRE test command line no graphical and it segfaulted out yet no simple
application existed for it that a end user could be requested to install and
run to find out if it was dud or not.  This is not a suitable location for
support end user ends up blaming the program not the library as they should.
This is not the first time I have seen 100 percent non functional parts make it
to testing.

What I am requesting that its Mandatory requirement to provide a testsuite
package or a demo package matching up with all libraries.

This way something to test the functionality of the libraries even to the most
basic level has to exist.

--The Rules I am putting Forwards START--
If library has a upstream test-suite  the test-suite be build and bundled as
If library has upstream  demos/sample applications  they will be packaged up

If those packages happen to contain parts that are license incompatible with
main repo but can be shipped in contrib or non-free without causing the
maintainer any legal trouble.  They should still be shipped.

If the upstream testsuite or demos cannot be shipped for any reason in main,
contrib or non-free repositories a package-testsuite-min must be made.

If required the  package-testsuite-min will contain the smallest functional
program for the library will be provided where possible without requiring x11
packaged basically initing the basic structs of the library and shutting
library down cleanly.

Package-testsuite-min, package-testsuite and package-demos will all be built
with the exact same complier and envorment used to make the library.

It is mandatory that the Maintainer before sending package up stream to run in
order of preference the upstream testsuite, upstream demos or the smallest
functional program.  If Maintainer will report in package description what test
was run being one of testsuite,demo or testsuite-min along with any known

Integration of upstream testsuite with deb8 is preferred if possible.
--The Rules I am putting Forwards END--

Libraries missing all 3 will be pretty simple to search for.  I would be kind
and say maintainers have 12 months to come into line with the new policy.

This should allow end users making applications to work out if it complier or
library failure.  The idea that a library will be run some time in 10 days
before it moves from unstable to testing is a flawed one.  Only way to be 100
percent sure it run its make it  mandatory for the maintainer todo so.

Issue of maintainers being able to skip out on providing test-suites means they
also get to skip out on running them.  If they have had to build them anyhow
they might as well run them.  Maintainers praying that someone tries there
library before the 10 days is up is not suitable to say the least.  Even in 10
days a all users of the unstable branch might not use all functions of a
library to the extent the libraries own testsuite will.  So detectable faults
are slipping threw that should be stopped.

Issues of testsuites not existing removes means to for users to test against
hardware particular errors.   This will become more important as more items use
opencl and other acceleration methods.   Saying users can build from source is
not going to cut it.  In case of a complier error the source code build will
not work of the test-suite but the binary build should work the same as
everyone else with the binary build.  Reverse is also true if the binary
testsuite does not work yet everyone rebuilding the testsuite with a different
complier it works you know you had a complier issue and the package need to be

Really go to repo and search testsuite and the problem is straight up in your
face.  Less than 20 items return.  End user cannot test there system unless
they know how to code even then building the testsuite from source may give a
false reading due to complier defect.  That the library is bust when the
complier is,

List of people who should be able to check.  Maintainer,  Automated system
about the maintainer reason for deb8 support recommendation and the end user.

The issue causing me to request this is a segfault all kind of errors can be
sneaking past due to testing not being done.  There can be security issues
sneaking past as well.

Will everyone like this most likely not.  I know it will mean more disk space.
Of course one option might be extra branches in the repos  test and test-non-
free for containing the test-suites so all mirror sites don't have major
storage requirement expand.

There are reasons at times test suites cannot be allowed to be modified so they
fall outside the normal permitted licenses by Debian even that they are
perfectly allowed to be shipped as long as there source code is not modified.

Solution to prevent this issue need to be design.  Needs to be mandatory that
every package maintainer has to consider when packaging.  Failure to provide in
time see package rejected until it is.

10 line program to run the library to confirm it does the basics is really not
asking much.   Proper splitting of packages so leading to requesting upstream
proper splits there licensing parts is also not asking too much.

Solution of lets just delete what does not conform is not suitable but it is
acceptable under the current policy.  Package contains a test-suite containing
license parts that cannot go into main repo deleting it out right is a suitable
solution to conflict by current policy.   Yes libogre contains quite a decent
testsuite that basically is not provided even in the source debs due to license
issue blocking it from main.   Not blocking from contrib or non-free.  Simpler
on the maintainer not to have to make those packages.

You will find many maintainers only doing what the bar min of the rules

This issue is grave because it can be a source of poor QA control leading to
every problem under the sun.  Programs crashing as demoed by libogre.  Secuirty
flaws can be missed due to testsuites not being run,   Data-loss possible with
libogre that is build inside policy rules.

Something has to be changed in the policy to prevent this.  If not my change
something else equally mandorary.

Yes its better to reject a under-tested package outright and force a maintainer
to make a package that is tested by testsuite than let a undertested package
get to testing then with a possible hope of sneaking into stable.

-- System Information:
Debian Release: wheezy/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'proposed-updates'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message ---
control: user
control: usertag -1 +obsolete
control: tag -1 +wontfix

Russ Allbery and I did a round of in-person bug triage at DebConf17 and
we are closing this bug as inactive.

The reasons for closing fall into the following categories, from most
frequent to least frequent:

- issue is appropriate for Policy, there is a consensus on how to fix
  the problem, but preparing the patch is very time-consuming and no-one
  has volunteered to do it, and we do not judge the issue to be
  important enough to keep an open bug around;

- issue is appropriate for Policy but there does not yet exist a
  consensus on what should change, and no recent discussion.  A fresh
  discussion might allow us to reach consensus, and the messages in the
  old bug are unlikely to help very much; or

- issue is not appropriate for Policy.

If you feel this bug is still relevant and want to restart the
discussion, you can re-open the bug.  However, please consider instead
opening a new bug with a message that summarises and condenses the
previous discussion, updates the report for the current state of Debian,
and makes clear exactly what you think should change.

A lot of these old bugs have long side tangents and numerous messages,
and that old discussion is not necessarily helpful for figuring out what
Debian Policy should say today.

Sean Whitton

Attachment: signature.asc
Description: PGP signature

--- End Message ---

Reply via email to