Thijs Kinkhorst th...@debian.org writes:
* Issues in specific packages
We further discussed some specific problematic packages. One example is
ia32-libs, which is difficult because it includes 100+ other source
packages. This will be handled better for Squeeze: we'll have to ensure
it's as
On Wed, 26 Jan 2011 14:47:52 +0100, Goswin von Brederlow wrote:
Thijs Kinkhorst th...@debian.org writes:
* Issues in specific packages
We further discussed some specific problematic packages. One example is
ia32-libs, which is difficult because it includes 100+ other source
packages.
On Sun, Jan 23, 2011 at 11:32:07PM +0100, Thijs Kinkhorst wrote:
* README.test
Although many packages include a test suite that is run after package build,
there are packages that do not have such a suite, or not one that can be
run as part of the build process. It was proposed to
Hi,
On Montag, 24. Januar 2011, Iustin Pop wrote:
Second, README.test are designed for human consumption, whereas a
standardisation of how to invoke the tests would allow for much more
automation. E.g. piuparts would not only be able to test that the
install succeeds, but the automated tests
On Mon, Jan 24, 2011 at 07:48:18AM +0100, Iustin Pop wrote:
IMHO what would be a sufficient first step would be much simpler:
- being able to know if a package does offer build post-install tests
- how to run such tests
- for post-install tests, what are the depedencies (Test-Depends? ;-)
On 24/01/11 02:52, Paul Wise wrote:
* README.test
An alternative is to just provide *-test Debian packages.
If the package exists then building it is the same as running a test of
the packages
it requires to be installed - maybe just the * package, but it could
also be an
integration test.
On Mon, Jan 24, 2011 at 10:37:26AM +0100, Holger Levsen wrote:
Hi,
On Montag, 24. Januar 2011, Iustin Pop wrote:
Second, README.test are designed for human consumption, whereas a
standardisation of how to invoke the tests would allow for much more
automation. E.g. piuparts would not only
On Monday 24 January 2011, Iustin Pop wrote:
This is a very good idea, but I think it could be taken two steps
further. These are just some ideas I have but did not explore in
depth, so take them with a grain of salt.
First, tests run during a package build are good, but they do not
ensure,
On Sun, Jan 23, 2011 at 11:32:07PM +0100, Thijs Kinkhorst wrote:
Hi!
In the weekend 14-16 January 2011, the Debian Security Team convened in
Linux Hotel, Essen. We discussed many things, a lot of security work was done
and of course the necessary socialising wasn't forgotten. We'd like to
On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote:
First, tests run during a package build are good, but they do not
ensure, for example, that the package as installed is working OK. I've
been thinking that (also) providing tests to be run after the package is
installed (and not on
Michael Hanke wrote:
On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote:
Second, README.test are designed for human consumption, whereas a
standardisation of how to invoke the tests would allow for much more
automation. E.g. piuparts would not only be able to test that the
install
On Mon, Jan 24, 2011 at 7:19 AM, Iustin Pop ius...@debian.org wrote:
First, tests run during a package build are good, but they do not
ensure, for example, that the package as installed is working OK. I've
been thinking that (also) providing tests to be run after the package is
installed (and
On Mon, Jan 24, 2011 at 10:52:54AM +0800, Paul Wise wrote:
On Mon, Jan 24, 2011 at 7:19 AM, Iustin Pop ius...@debian.org wrote:
First, tests run during a package build are good, but they do not
ensure, for example, that the package as installed is working OK. I've
been thinking that
On Sun, Jan 23, 2011 at 06:45:56PM -0500, Michael Hanke wrote:
On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote:
First, tests run during a package build are good, but they do not
ensure, for example, that the package as installed is working OK. I've
been thinking that (also)
14 matches
Mail list logo
