Re: Bits from the Security Team (for those that care about bits)

2011-01-26 Thread Michael Gilbert
On Wed, 26 Jan 2011 14:47:52 +0100, Goswin von Brederlow wrote: > Thijs Kinkhorst 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

Re: Bits from the Security Team (for those that care about bits)

2011-01-26 Thread Goswin von Brederlow
Thijs Kinkhorst 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 up to date

Re: Bits from the Security Team (for those that care about bits)

2011-01-25 Thread Wouter Verhelst
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 standa

Re: Bits from the Security Team (for those that care about bits)

2011-01-24 Thread Stefan Fritsch
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 > en

Re: autopkgtest (was Re: Bits from the Security Team (for those that care about bits)

2011-01-24 Thread Iustin Pop
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

Re: Bits from the Security Team (for those that care about bits)

2011-01-24 Thread Philip Ashmore
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.

Re: Bits from the Security Team (for those that care about bits)

2011-01-24 Thread Michael Hanke
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? ;-)

autopkgtest (was Re: Bits from the Security Team (for those that care about bits)

2011-01-24 Thread Holger Levsen
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 tes

Re: Bits from the Security Team (for those that care about bits)

2011-01-23 Thread Iustin Pop
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)

Re: Bits from the Security Team (for those that care about bits)

2011-01-23 Thread Iustin Pop
On Mon, Jan 24, 2011 at 10:52:54AM +0800, Paul Wise wrote: > On Mon, Jan 24, 2011 at 7:19 AM, 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) providin

Re: Bits from the Security Team (for those that care about bits)

2011-01-23 Thread Paul Wise
On Mon, Jan 24, 2011 at 7:19 AM, 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 the bu

Re: Bits from the Security Team (for those that care about bits)

2011-01-23 Thread Raphael Geissert
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 >> ins

Re: Bits from the Security Team (for those that care about bits)

2011-01-23 Thread Michael Hanke
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

Re: Bits from the Security Team (for those that care about bits)

2011-01-23 Thread Iustin Pop
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