Your message dated Fri, 11 Aug 2017 12:44:51 -0700
with message-id <87o9rlx51o....@iris.silentflame.com>
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 ow...@bugs.debian.org
immediately.)
--
656569: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656569
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-policy
Severity: normal
Dear Maintainer,
What led up to the situation?
What lead me here was the fact that libogre 1.7.3-3 that is basically a package
that does not work at all made it into the testing branch. This should not be
possible.
What I learnt from the policy that the demo and testsuite had been stripped due
to containing sections that were not licensed acceptable to main repo. Lack of
testing on the maintainers path. Worse lack of means for me as a end user to
simply test a library and find out if it working.
Result was a library that got threw usable as a non working library and into
testing due to being rarely used package. Excuse that is rarely used should
not cut it. This is also not the first time I have seen a rarely used package
get from unstable to testing without being caught as defective. Most have cost
me many hours trying to work out what has gone wrong with what I am working on.
*** My proposed policy change***
If upstream library source package contains a testsuite. This testsuite must
be packaged as package-testsuite unless it cannot be ship by any one of the
rules over main, contrib or non-free. This even include the case that the
library ends up in main and the testsuite ends up in non-free or contrib with
the source files split in 2.
If upstream package contains demos same rule as testsuite except its package-
demos.
If upstream library source package does not contain testsuite or demos or due
to licensing they cannot be provide by the debain system a package-testsuite-
min must be created. If testsuite or demos packages exist testsuite-min does
not have to be created.
Package-testsuite-min will contain at least little program that inits the
library and shut-down down the library done in the min amount of code. Enough
to prove the library will at east basically fire up and has some chance of
providing some functionality. Extra debian license compadible tests can be
added to this file.
Before sending a package upstream to unstable at least one of the following has
to be run testsuite, demos or testsuite-min by the package maintainer to prove
the library. What has been run with any failures. What has been run on
library to test to be record in the package description "tested by: *name*
using *testsuite/demo/testsuite-min* on *arch/archs*" with optional "failures
recorded in *file*" if there are any failures.
Recommended if possible for maintainers to integrate package-testsuite to deb8
*** End ***
This is to remove delete being used as a solution with testsuites. Reason must
provide is issues with libraries sometimes can be complier. If library
provided testsuite runs proper and testsuite built by current complier does not
you know you most likely have a complier failure on your hands.
Reason why this is a possible security flaw is there are most likely a lot of
libraries who test-suite is not being built or used by the maintainers. 10
days in unstable is not going to test the library as completely as one proper
run of the libraries test suite.
deb8 is also not going to cut it as more libraries add items like opencl
support. Reason why a library might fail test suite due to hardware
difference. Hardware difference the end user need to be able to testsuite to
know what is going on. Again dependable testsuite that is not going to give
false reading because the user damaged the complier strangely.
Also deb8 building from source is not going to help you in case of defective
complier locally.
Yes this will mean more disc space. To address some of the disc space issue I
suggest to more sub repo parts. tests and tests-nonfree. These are the repos
were all testsuites and demos go. Testsuites and demos don't need to be
replaced out to every mirror site.
This provide formal proof a test was done on a package by a maintainer that is
confirm-able in case of a failed package. This also clearly suggest to
maintainers what I was told that it would not be a problem if more programs
were using the library is not suitable ever.
A package without a tested by: *name* using *testsuite/demo/teststuite-min*
should be rejected after 12 months from this policy change. This should give
people enough time to alter system.
So yes this fault is security and stability of Debian. If my alteration to
policy is not something else mandatory about testing has to go in to make it
clear in policy sending items upstream without any form testing will not be
tolerated. Library makers should not depend on application makers to test
there libraries completely for them.
Peter Dolding
-- 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 debian-pol...@packages.debian.org
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
signature.asc
Description: PGP signature
--- End Message ---
