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
Description: PGP signature
--- End Message ---