Control: close -1
On Thu, Feb 15, 2018 at 05:21:17PM +0100, gregor herrmann wrote:
> On Fri, 04 Aug 2017 16:52:21 -0400, Alex Muntada wrote:
>
> > Niko Tyni:
> > > I think I'm leaving this for now. We can see if it becomes a problem
> > > later, and if not, just close this.
> > Agreed.
>
> I
On Fri, 04 Aug 2017 16:52:21 -0400, Alex Muntada wrote:
> Niko Tyni:
> > I think I'm leaving this for now. We can see if it becomes a problem
> > later, and if not, just close this.
> Agreed.
I think we can close this bug now. At least I don't remember seeing
any problems with the recursive
Niko Tyni:
> Any urgency this issue had is gone now that you did all the work of
> fixing the --recurse regressions. Many thanks for that :)
>
> I think I'm leaving this for now. We can see if it becomes a problem
> later, and if not, just close this.
Agreed.
Thanks both for your work!
Alex
On Thu, 03 Aug 2017 20:30:11 +0300, Niko Tyni wrote:
> > But yeah, if a realiable implementation of "find out build tests and
> > run them during autopkgtest" is possible then it probably makes
> > sense. And ...
>
> > > The 'make -n -p | grep TEST_FILES' thing seems most promising to me so
On Wed, Aug 02, 2017 at 03:50:39PM -0400, gregor herrmann wrote:
> On Wed, 02 Aug 2017 11:10:25 +0300, Niko Tyni wrote:
> > Sure, we should filter the more common tests of this kind out
> > of the runtime check list.
>
> Ack, and this should bring us a long way.
> (I saw quite a few t/author/
On Wed, 02 Aug 2017 11:10:25 +0300, Niko Tyni wrote:
> > - more tests in autopkgtest than during build but perfectly
> > reasonable tests where it looks more like an issue that they are
> > not run during build (and the typical easy-to-fix-failures);
> If the issue here is that they should be
On Tue, Aug 01, 2017 at 04:53:36PM -0400, gregor herrmann wrote:
> On Tue, 01 Aug 2017 19:58:55 +0300, Niko Tyni wrote:
>
> > Hm. I agree the goal is to get the same list of tests that are run at
> > build time.
>
> I don't agree 100% I think.
> From what I've seen so far when looking at a
On Tue, 01 Aug 2017 19:58:55 +0300, Niko Tyni wrote:
> Hm. I agree the goal is to get the same list of tests that are run at
> build time.
I don't agree 100% I think.
From what I've seen so far when looking at a dozen of the failures we
have:
- same tests in autopkgtest as during build, which
On Tue, Aug 01, 2017 at 11:31:05AM -0400, Alex Muntada wrote:
> My idea is that we should smoke test the same list of tests that
> are actually run by "make test" or "./Build test" without having
> to parse those *.PL files to figure out that list. Therefore,
> the list should be obtained by
gregor herrmann:
> alexm has more idea, we'll add something hopefully more
> coherent later :)
My idea is that we should smoke test the same list of tests that
are actually run by "make test" or "./Build test" without having
to parse those *.PL files to figure out that list. Therefore,
the list
On Tue, 01 Aug 2017 11:18:30 +0300, Niko Tyni wrote:
> Since 0.37, we're running 'prove --recurse' by default in the smoke
> test. This has resulted in ~50 regressions according to ci.d.n:
> there are packages ship .t files under t/ subdirectories (or starting
> with a dot) that are not run
Package: pkg-perl-autopkgtest
Version: 0.37
Since 0.37, we're running 'prove --recurse' by default in the smoke
test. This has resulted in ~50 regressions according to ci.d.n:
there are packages ship .t files under t/ subdirectories (or starting
with a dot) that are not run during builds and are
12 matches
Mail list logo
