On Wed, Feb 02, 2011 at 08:55:07AM +0100, Stefano Zacchiroli wrote:
So, where do we start/continue sharing the thoughts on a tentative
DEP? ;)
Let's see first if we have all the arguments on the table already,
thanks to this thread. I'm willing to co-drive a DEP to finalize the
spec,
Yaroslav Halchenko writes (Re: package testing, autopkgtest, and all that):
First a brief question:
The source package provides a test metadata file
debian/tests/control. This is a file containing zero or more
RFC822-style stanzas, along these lines:
Do you still have somewhere that awk
Stefano Zacchiroli writes (Re: package testing, autopkgtest, and all that):
All that considered, I'd like to know the rationale of this initial
design choice as well. In particular, it would be nice to know if anyone
see disadvantages in having *also* (rather then instead) support for
running
On Wed, 02 Feb 2011 at 14:15:07 +, Ian Jackson wrote:
So if the tests were in binary packages, often we'd have to construct
a weird binary package which contained all or part of the built source
tree. This would be very ugly and also bulky.
FWIW, Maemo does this, and it's a pain to deal
On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote:
As for also running tests which are not part of a source package,
it is very easy to wrap up some tests in a dedicated source package if
that's desirable. The source package is then just a convenient
container format. There is no
On Wed, Feb 02, 2011 at 10:08:32AM -0500, Michael Hanke wrote:
I don't think going back the drawing board now is a very good idea.
What we are lacking is deployment (and, sorry for my part in the lack
of that).
I don't necessarily take the point of being 5 years too late. If
everything
Hi Ian,
thanks for the input! It does make motivation behind source
packages-based testing clearer. And Simon's example is a good one ;-)
As a summary: source packages-based testing often provides more
convenient and upstream-friendly approach, thus it must not be
excluded, echoing Stefano's
Michael Hanke writes (Re: package testing, autopkgtest, and all that):
On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote:
As for also running tests which are not part of a source package,
it is very easy to wrap up some tests in a dedicated source package if
that's desirable
Yaroslav Halchenko writes (Re: package testing, autopkgtest, and all that):
in the core -- users usually do not deal with source packages; many of
them do not even have deb-src lines for apt. They do not care how
things are built, but if we want them to contribute by testing their
systems
On Wed, Feb 02, 2011 at 04:13:37PM +, Ian Jackson wrote:
Yaroslav Halchenko writes (Re: package testing, autopkgtest, and all that):
in the core -- users usually do not deal with source packages; many of
them do not even have deb-src lines for apt. They do not care how
things are built
Michael Hanke writes (Re: package testing, autopkgtest, and all that):
But to get many machines, we need to make it dead-simple to participate
in this type of croud-testing. We can have GUI frontends to let people
do specific tests, or offer backfill job configurations for compute
clusters
On Wed, Feb 02, 2011 at 05:13:21PM +, Ian Jackson wrote:
Michael Hanke writes (Re: package testing, autopkgtest, and all that):
I see the point in having less by better-quality input to package
maintainers, but again, the test results do not have to go one-by-one to
a human to inspect
On ke, 2011-02-02 at 17:13 +, Ian Jackson wrote:
This is easily done with autopkgtest; the only difference from your
proposal is that the source package needs to be downloaded. Doing so
is not difficult or troublesome, and can be done automatically.
I concur.
However, looking things from
On Wed, Feb 02, 2011 at 02:28:14PM +, Ian Jackson wrote:
One point I would like to make is that people who are now raising
objections to fundamental design decisions are, I think, five and a
half years too late.
The design, both in principle and detail, was discussed in November
2005
Hi Ian,
First a brief question:
The source package provides a test metadata file
debian/tests/control. This is a file containing zero or more
RFC822-style stanzas, along these lines:
Do you still have somewhere that awk package demo package which had
debian/tests/ ? Currently our archive does
On Tue, Feb 01, 2011 at 06:17:45PM -0500, Yaroslav Halchenko wrote:
Unfortunately the core aspect of the current autopkgtest - relying on
tests in source packages -- imho to be not the ideal solution to
target both sides of the userbase (i.e. maintainers/QA vs mortals).
Thanks for this related
On Thu, Jan 27, 2011 at 02:45:57PM +, Ian Jackson wrote:
Ian: would you mind summarizing the status of that effort and
comment on whether, in your opinion, people interested on this topic
should continue from there or start over?
Sure. autopkgtest (the codebase) isn't very big but it
On Thu, Jan 27, 2011 at 02:46:40PM +, Ian Jackson wrote:
* A specification which allows a source package to declare that it
contains tests, and how those tests need to be run. This
specification was discussed extensively on debian-devel at the
time and a copy is in the
Stefano Zacchiroli writes (Re: package testing, autopkgtest, and all that):
I find INSTALLED version of the program to be ambiguous. It might
refer to installed in the sense of 'debian/rules install' (or, to be
more precise, 'debian/rules binary', given that 'install' is not
dictated by policy
Stefano Zacchiroli writes (Re: package testing, autopkgtest, and all that):
dep-rant
I confess that this seems to be exactly one of those cases where the
DEP process (should) shine. By putting the specification in a more
visible place than (only) in an archive package we can give it more
On 31/01/11 at 00:29 +0100, Stefano Zacchiroli wrote:
The best incentive for adoption in this case is having periodic runs of
package tests, with reporting. At first glance, I'm tempted to propose
to use grid archive rebuilds to run tests. Lucas: how much work would it
be to hack your rebuild
Lucas Nussbaum writes (Re: package testing, autopkgtest, and all that):
If there's a packaged tool to run the test suite on a given package,
then it's quite easy to integrate it into my infrastructure. But I
clearly do not have the time to get autopkgtest's code back in shape
first.
Yes
On Fri, Jan 28, 2011 at 03:19:32PM +, Ian Jackson wrote:
Iustin Pop writes (Re: package testing, autopkgtest, and all that):
I think even without a full archive integration, having this spec
publicised a bit among developers would be useful; I know I'm looking
forward to adapting my own
Iustin Pop writes (Re: package testing, autopkgtest, and all that):
As it seems to me, right now this is most useful for individual
maintainers to declare, and run, their own tests to ensure the built
packages are fine. A good start, I'd say.
Yes, you can certainly use it that way.
I think
Stefano Zacchiroli writes (package testing, autopkgtest, and all that):
Regarding this specific point (tests run on packages as if they were
installed), IIRC Ian Jackson worked a bit on the matter, producing some
code (autopkgtest---as mentioned elsewhere in this thread) and a
specification
I wrote:
* A specification which allows a source package to declare that it
contains tests, and how those tests need to be run. This
specification was discussed extensively on debian-devel at the
time and a copy is in the autopkgtest package, but I'll follow up
this email with a
On Thu, Jan 27, 2011 at 02:45:57PM +, Ian Jackson wrote:
Stefano Zacchiroli writes (package testing, autopkgtest, and all that):
Regarding this specific point (tests run on packages as if they were
installed), IIRC Ian Jackson worked a bit on the matter, producing some
code (autopkgtest
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
28 matches
Mail list logo
