Mailing List Archive: Perl: porters

sniffing the 5.16 smoke

Index | Next | Previous | View Threaded

perl.p5p at rjbs

May 3, 2012, 7:25 PM

Post #1 of 12 (145 views)
Permalink

sniffing the 5.16 smoke

I have smelled the smoke, and it is not good.

Let's review some platforms:

Linux - seems mostly okay, but I have a bunch of failures from Tux on
OpenSUSE, mostly failing when using ccache, failing on
../cpan/Socket/t/sockaddr.t

Tux, what's up? Anybody else having difficulties?

Solaris - builds just fine for me with suncc and gnucc; I see one failure
from TonyC related to op/sigsystem.t and Sockt/t/getnameinfo.t

TonyC, any idea what's up with that? I had no difficulty.

Darwin - Looks good. No surprise to me, I build it on Darwin all the time.
I see some red reports from TonyC, but the logs show all tests
successful, so I think it's a reporting problem..?

That concludes all the platforms where I regularly build. Here are more:

MSWin - Looks... pretty good! Well, about as good as usual. I'm not sure
what's up with the test failure for /cpan/Memoize/t/expmod_t.t

My plan is to try to get a Win32 smoke going overnight here. I have
a build box, but it's a VM and quite slow. Anyone else want to chime
in?

Reini reported a problem with Encode (#112612) not building because
it uses miniperl but should use perl. I haven't seen anyone else
reproduce that yet. I've asked for more info.

Cygwin - Looks bad. I don't know what cygwin looked like around, say,
5.14.0-RC0. Does it ever tend to smoke clean? :-/

Who are our other Cygwin experts on staff?

I don't have a Cygwin build environment at my disposal.

NetBSD - Looking pretty bad. I really have no idea what's up here, but surely
someone does, or can offer speculation. Some of these reports look
like the Darwin fail: all tests successful, report marked bad. Then
one has a pile of dbm failures. Are things really working or not?

I don't have a NetBSD machine at my disposal.

VMS - I see a failure. I don't know what's up. Craig? Anybody?

AIX - Holy cow, it's green! That's some great news!

HP-UX - Looks *terrible*. Lots of failures, and flipping through them, there
seem to be quite a few different kinds of failure. Tux, do you have
some idea what's up, here?

I don't have access to an HP-UX build environment.

Have I missed any platforms I should not have missed?

Right now, at the very least, HP-UX and NetBSD look blockingly bad. I think we
need more information on Cygwin and VMS and Win32.

Please chime in. Remember, the only platforms that I rely on seem to be
working just fine... ;)

--
rjbs

Attachments:

signature.asc (0.48 KB)

tony at develop-help

May 3, 2012, 8:10 PM

Post #2 of 12 (144 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On Thu, May 03, 2012 at 10:25:34PM -0400, Ricardo Signes wrote:
>
> I have smelled the smoke, and it is not good.
>
> Let's review some platforms:
>
> Solaris - builds just fine for me with suncc and gnucc; I see one failure
> from TonyC related to op/sigsystem.t and Sockt/t/getnameinfo.t
>
> TonyC, any idea what's up with that? I had no difficulty.

That test has failed for me since it went in.

> Darwin - Looks good. No surprise to me, I build it on Darwin all the time.
> I see some red reports from TonyC, but the logs show all tests
> successful, so I think it's a reporting problem..?

Failures: (common-args) -Dcc=g++
[stdio] -DDEBUGGING -Duseithreads -Dusedtrace
../dist/threads/t/free2.t...................................FAILED
Bad plan. You planned 78 tests but ran 13.

This is a rare random failure I get on darwin occasionally.

> Cygwin - Looks bad. I don't know what cygwin looked like around, say,
> 5.14.0-RC0. Does it ever tend to smoke clean? :-/
>
> Who are our other Cygwin experts on staff?
>
> I don't have a Cygwin build environment at my disposal.

cygwin has failed badly since I started smoking it. There are some
tickets covering some of it, but I don't remember what off the top of
my head.

> NetBSD - Looking pretty bad. I really have no idea what's up here, but surely
> someone does, or can offer speculation. Some of these reports look
> like the Darwin fail: all tests successful, report marked bad. Then
> one has a pile of dbm failures. Are things really working or not?
>
> I don't have a NetBSD machine at my disposal.

The M and dbm failures are from a parallel build issue, which I
believe has a ticket.

Tony

h.m.brand at xs4all

May 3, 2012, 11:39 PM

Post #3 of 12 (148 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On Thu, 3 May 2012 22:25:34 -0400, Ricardo Signes
<perl.p5p [at] rjbs> wrote:

> I have smelled the smoke, and it is not good.
>
> Let's review some platforms:
>
> Linux - seems mostly okay, but I have a bunch of failures from
> Tux on OpenSUSE, mostly failing when using ccache,
> failing on ../cpan/Socket/t/sockaddr.t
>
> Tux, what's up? Anybody else having difficulties?

I never noticed those, as the pattern looked like the usual timing
random failures. You'll note that there is no "predictable" socket
FAILures and the F's pop up in different locations. Seems hard to
reproduce.

http://perl5.test-smoke.org/report/350
http://perl5.test-smoke.org/logfile/350

Tests start here:
TSTENV = stdio No saved state, selection will be empty
make: *** [test_harness] Error 1

error while running harness target 'test_harness': 2 at /pro/3gl/CPAN/smoke/Test/Smoke.pm line 193.

../cpan/CGI/t/tmpdir.t......................................PASSED
3-9
../cpan/Socket/t/sockaddr.t.................................FAILED
Bad plan. You planned 31 tests but ran 27.

*ALL* my tests run under TEST_JOBS=n (where n depends on the number of
CPU's in the specific box). For the above report it was 3.

> Solaris - builds just fine for me with suncc and gnucc; I see one failure
> from TonyC related to op/sigsystem.t and Sockt/t/getnameinfo.t
>
> TonyC, any idea what's up with that? I had no difficulty.
>
> Darwin - Looks good. No surprise to me, I build it on Darwin all the
> time. I see some red reports from TonyC, but the logs show
> all tests successful, so I think it's a reporting problem..?
>
> That concludes all the platforms where I regularly build. Here are more:
>
> MSWin - Looks... pretty good! Well, about as good as usual. I'm
> not sure what's up with the test failure for
> /cpan/Memoize/t/expmod_t.t
>
> My plan is to try to get a Win32 smoke going overnight here.
> I have a build box, but it's a VM and quite slow. Anyone
> else want to chime in?
>
> Reini reported a problem with Encode (#112612) not building
> because it uses miniperl but should use perl. I haven't
> seen anyone else reproduce that yet. I've asked for more info.
>
> Cygwin - Looks bad. I don't know what cygwin looked like around, say,
> 5.14.0-RC0. Does it ever tend to smoke clean? :-/
>
> Who are our other Cygwin experts on staff?
>
> I don't have a Cygwin build environment at my disposal.
>
> NetBSD - Looking pretty bad. I really have no idea what's up here, but
> surely someone does, or can offer speculation. Some of these
> reports look like the Darwin fail: all tests successful,
> report marked bad. Then one has a pile of dbm failures. Are
> things really working or not?
>
> I don't have a NetBSD machine at my disposal.
>
> VMS - I see a failure. I don't know what's up. Craig? Anybody?
>
> AIX - Holy cow, it's green! That's some great news!
>
> HP-UX - Looks *terrible*. Lots of failures, and flipping through
> them, there seem to be quite a few different kinds of
> failure. Tux, do you have some idea what's up, here?

It is only PA-RISC that lives in a terrible state. I ignored it as
Nicholas was working on that.

The 'm' for HP-UX 10.20 can be ignored: the code has grown to complex
for the compiler to cope when -DDEBUGGING is on. The box only has 512
Mb and might need a -O0 for some files. Not worth digging into and is
not a blocker.

> I don't have access to an HP-UX build environment.

I can give you access to HP-UX 11.23/PA-RISC
Just mail me the required logname and your id_whatever.pub

> Have I missed any platforms I should not have missed?
>
> Right now, at the very least, HP-UX and NetBSD look blockingly bad.
> I think we need more information on Cygwin and VMS and Win32.
>
> Please chime in. Remember, the only platforms that I rely on seem
> to be working just fine... ;)

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

h.m.brand at xs4all

May 4, 2012, 1:12 AM

Post #4 of 12 (136 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On Thu, 3 May 2012 22:25:34 -0400, Ricardo Signes
<perl.p5p [at] rjbs> wrote:

> Linux - seems mostly okay, but I have a bunch of failures from Tux on
> OpenSUSE, mostly failing when using ccache, failing on
> ../cpan/Socket/t/sockaddr.t
>
> Tux, what's up? Anybody else having difficulties?

Johan has the same FAIL as X:

http://pasta.test-smoke.org/240

That'd mean the tests FAILed under test and then PASSed under harness

/me now builds to check if 50 runs will show a pattern ...

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

tony at develop-help

May 4, 2012, 1:49 AM

Post #5 of 12 (136 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On Fri, May 04, 2012 at 10:12:22AM +0200, H.Merijn Brand wrote:
> On Thu, 3 May 2012 22:25:34 -0400, Ricardo Signes
> <perl.p5p [at] rjbs> wrote:
>
> > Linux - seems mostly okay, but I have a bunch of failures from Tux on
> > OpenSUSE, mostly failing when using ccache, failing on
> > ../cpan/Socket/t/sockaddr.t
> >
> > Tux, what's up? Anybody else having difficulties?
>
> Johan has the same FAIL as X:
>
> http://pasta.test-smoke.org/240
>
> That'd mean the tests FAILed under test and then PASSed under harness

It can mean that they failed with different messages too - eg. if the
test exits with non-zero, harness and TEST report that differently,
producing an X.

Tony

h.m.brand at xs4all

May 4, 2012, 2:21 AM

Post #6 of 12 (138 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On Fri, 4 May 2012 18:49:38 +1000, Tony Cook <tony [at] develop-help>
wrote:

> On Fri, May 04, 2012 at 10:12:22AM +0200, H.Merijn Brand wrote:
> > On Thu, 3 May 2012 22:25:34 -0400, Ricardo Signes
> > <perl.p5p [at] rjbs> wrote:
> >
> > > Linux - seems mostly okay, but I have a bunch of failures from Tux on
> > > OpenSUSE, mostly failing when using ccache, failing on
> > > ../cpan/Socket/t/sockaddr.t
> > >
> > > Tux, what's up? Anybody else having difficulties?
> >
> > Johan has the same FAIL as X:
> >
> > http://pasta.test-smoke.org/240
> >
> > That'd mean the tests FAILed under test and then PASSed under harness
>
> It can mean that they failed with different messages too - eg. if the
> test exits with non-zero, harness and TEST report that differently,
> producing an X.

Running this:
--8<---
#!/pro/bin/perl

use strict;
use warnings;
use Data::Peek;

my %x;
$ENV{TEST_JOBS} = 14;
for (1 .. 2000) {
$x{harness}{$_}++ for grep s/Result:\s*(\w+)\s*[\r\n]*/$1/ =>
`./perl harness ../cpan/Socket/t/sockaddr.t 2>&1`;

$x{TEST} {$_}++ for (grep m/All tests successful/ =>
`./perl TEST ../cpan/Socket/t/sockaddr.t 2>&1`
) ? "PASS" : "FAIL";

(my $x = DDumper \%x) =~ s/[{}=>\s\r\n]+/ /g;
printf " $x\r";
}

DDumper { "../cpan/Socket/t/sockaddr.t" => \%x };
--->8--

returned for 64bitall debugging builds on two different boxes:

{ '../cpan/Socket/t/sockaddr.t' => {
harness => {
PASS => 2000
},
test => {
PASS => 2000
}
}
}

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

craig.a.berry at gmail

May 4, 2012, 8:40 AM

Post #7 of 12 (136 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On Thu, May 3, 2012 at 9:25 PM, Ricardo Signes
<perl.p5p [at] rjbs> wrote:

> Darwin �- Looks good. �No surprise to me, I build it on Darwin all the time.
> � � � � �I see some red reports from TonyC, but the logs show all tests
> � � � � �successful, so I think it's a reporting problem..?

In the one I'm looking at:

<http://www.nntp.perl.org/group/perl.daily-build.reports/2012/05/msg119139.html>

it seems pretty clear what failed. You can probably reproduce the
failure by building with Dcc=g++ -Dusethreads and defining PERLIO to
stdio in the environment. It may or may not matter that this is the
g++ from LLVM (via recent XCode, most likely) not the one from GCC
(not so recent XCode or built independently).

> VMS � � - I see a failure. �I don't know what's up. �Craig? �Anybody?

The main failure is that I'm the only anybody, but that wasn't the
question. Here's what I know about the failure list (which has been
pretty stable for some time):

t/porting/podcheck ............................................
FAILED at test 330

This happens sometimes but not always and looks like the following
when it does happen:

not ok 330 - POD of x2p/s2p.com
# Spurious =cut command
# near line 458

The =cut seems fine but the preceding =item doesn't have a blank line
before -- isn't it suposed to? The failure can be fixed with:

--- x2p/s2p.PL;-0 2012-05-04 09:24:19 -0500
+++ x2p/s2p.PL 2012-05-04 09:24:45 -0500
@@ -497,6 +497,7 @@ Swap the contents of the pattern space a

#--------------------------------------------------------------------------
$ComTab{'y'}=[ 2, 'tra', \&Emit, '' ]; #ok
+
=item [2addr]B<y>B</>I<string1>B</>I<string2>B</>

In the pattern space, replace all characters occurring in I<string1> by the
[end]

but if the way it is now is wrong, why doesn't it fail consistently on
all platforms?

cpan/Module-Build/t/PL_files ..................................
FAILED at test 3
cpan/Module-Build/t/properties/dist_suffix ....................
FAILED at test 2
cpan/Module-Build/t/runthrough ................................
FAILED at test 11
cpan/Module-Build/t/tilde .....................................
FAILED at test 16

Sadly, these have been around since 5.14.0 and I've just never gotten
back to them. Some of them may go away when I enable preservation of
filename case by default, which I intend to do in 5.17.

cpan/Module-Metadata/t/metadata ...............................
FAILED at test 114

This was a day one failure when the last version came into blead. I
sent a fix upstream six weeks ago but have had no response:

<https://rt.cpan.org/Public/Bug/Display.html?id=76030>

dist/Carp/t/Carp ..............................................
FAILED--expected 60 tests, saw 34

The test recently started using IPC::Open3::open3, which is not
available on VMS. It has nothing to do with Carp. I could still add
a skip if that's acceptable this late in code freeze.

lib/perl5db ...................................................
FAILED at test 18

These were day one failures when the new tests came into blead. They look like:

not ok 28 - Test for the s command.
# Failed test 28 - Test for the s command. at [-.lib]perl5db.t line 764
# got '
# Loading DB routines from perl5db.pl version 1.37
# Editor support available.
#
# Enter h or 'h h' for help, or 'perldoc perldebug' for more help.
#
# auto(-2) DB<1> s
# auto(-1) DB<1> q
# '
# expected /(?^msx:
# ^main::foo$[^$\n]*\brt-104168:9\):[\ \t]*\n
# ^9:\s*bar;
# )/

so the line counter is clobbered or not reset or something such that
we get things like "auto(-2)" indicating an impossible negative line
number. I haven't managed to figure out whether it's the test
infrastructure or the debugger itself that has the bug.

steve.m.hay at googlemail

May 5, 2012, 1:35 PM

Post #8 of 12 (137 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On 4 May 2012 03:25, Ricardo Signes <perl.p5p [at] rjbs> wrote:
>
> I have smelled the smoke, and it is not good.
>
> MSWin - Looks... pretty good! Well, about as good as usual. I'm not sure
> what's up with the test failure for /cpan/Memoize/t/expmod_t.t
>
> My plan is to try to get a Win32 smoke going overnight here. I have
> a build box, but it's a VM and quite slow. Anyone else want to chime
> in?
>

It's looking pretty good for me too except for two frustrations:

The long-running crash in fork.t (test 16 failing) was resolved a
while back, but it was noted at the time that test 24 still
occasionally fails. I've been bisecting that and have drawn an absurd
conclusion (absurd if you look at what the diffs involved are):
b43c142abd most definitely fails test 16 sometimes (I only need to see
it once to know there's a problem, of course, and I see it within half
a dozen runs of fork.t every time), but the previous revision,
aa80f64f72, stubbornly refuses to fail test 16 for me (although there
is always the possibility that it might do if I just ran it one more
time...).

A while ago I also reported that the test suite as a whole hangs on
certain tests, but seemingly only when stderr is not being redirected
(hence it doesn't affect my smokes). I've been bisecting that too and
have reached an equally frustrating conclusion (again, the diff cannot
possibly be the cause): at revision ea28d694b1 the test suites hangs
seemingly every time in the CPANPLUS tests, but is fine (seemingly
every time) at the previous revision, dbce43998f.

This is all on Win7 x64 with VC++ 2010. I hope to test some more in
the next day or two on a different machine and perhaps using a
different compiler :-/

steve.m.hay at googlemail

May 7, 2012, 10:04 AM

Post #9 of 12 (130 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On 5 May 2012 21:35, Steve Hay <steve.m.hay [at] googlemail> wrote:
> On 4 May 2012 03:25, Ricardo Signes <perl.p5p [at] rjbs> wrote:
>>
>> I have smelled the smoke, and it is not good.
>>
>> MSWin - Looks... pretty good! Well, about as good as usual. I'm not sure
>> what's up with the test failure for /cpan/Memoize/t/expmod_t.t
>>
>> My plan is to try to get a Win32 smoke going overnight here. I have
>> a build box, but it's a VM and quite slow. Anyone else want to chime
>> in?
>>
>
> It's looking pretty good for me too except for two frustrations:
>
> The long-running crash in fork.t (test 16 failing) was resolved a
> while back, but it was noted at the time that test 24 still
> occasionally fails. I've been bisecting that and have drawn an absurd
> conclusion (absurd if you look at what the diffs involved are):
> b43c142abd most definitely fails test 16 sometimes (I only need to see
> it once to know there's a problem, of course, and I see it within half
> a dozen runs of fork.t every time), but the previous revision,
> aa80f64f72, stubbornly refuses to fail test 16 for me (although there
> is always the possibility that it might do if I just ran it one more
> time...).
>
> A while ago I also reported that the test suite as a whole hangs on
> certain tests, but seemingly only when stderr is not being redirected
> (hence it doesn't affect my smokes). I've been bisecting that too and
> have reached an equally frustrating conclusion (again, the diff cannot
> possibly be the cause): at revision ea28d694b1 the test suites hangs
> seemingly every time in the CPANPLUS tests, but is fine (seemingly
> every time) at the previous revision, dbce43998f.
>
> This is all on Win7 x64 with VC++ 2010. I hope to test some more in
> the next day or two on a different machine and perhaps using a
> different compiler :-/

Well, I've now tried again on a different machine and get much the
same wacky results:

Using VC10, b43c142abd occasionally fails fork.t test 16, but
aa80f64f72 seems not to.

Using VC9 (to avoid the need to patch it to build with VC10, which I'd
done before), dbce43998f and ea28d694b1 both make the full test suite
hang in the CPANPLUS tests (unless STDERR is redirected to a log
file), but if I patch in b7fa2aca51 from the maint-5.12 branch (which
I'd done before after finding the similarly wacky result that things
hang without it but not with it) then dbce43998f is now ok, but
ea28d694b1 continues to hang in the CPANPLUS tests.

I'm at a loss how to proceed with either problem and I fear that I may
simply give up at this point :-(

perl.p5p at rjbs

May 8, 2012, 6:19 PM

Post #10 of 12 (129 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

* "Craig A. Berry" <craig.a.berry [at] gmail> [2012-05-04T11:40:31]
> On Thu, May 3, 2012 at 9:25 PM, Ricardo Signes
> > VMS - I see a failure. I don't know what's up. Craig? Anybody?
>
> [...]
> t/porting/podcheck ............................................
> [...]
>
> The =cut seems fine but the preceding =item doesn't have a blank line
> before -- isn't it suposed to? The failure can be fixed with:

I'm applying your fix. I agree: it's very strange that it isn't failing
everywhere. I don't see why. I'm curious, but not curious enough to spend
more time than I just spent, since the fix is clearly an improvement.

> [ Module-Build ]
> Sadly, these have been around since 5.14.0 and I've just never gotten
> back to them. Some of them may go away when I enable preservation of
> filename case by default, which I intend to do in 5.17.

Ok.

> cpan/Module-Metadata/t/metadata ...............................
> FAILED at test 114
>
> This was a day one failure when the last version came into blead. I
> sent a fix upstream six weeks ago but have had no response:
>
> <https://rt.cpan.org/Public/Bug/Display.html?id=76030>

I poked the maintainers and will do so again.

> dist/Carp/t/Carp ..............................................
> FAILED--expected 60 tests, saw 34
>
> The test recently started using IPC::Open3::open3, which is not
> available on VMS. It has nothing to do with Carp. I could still add
> a skip if that's acceptable this late in code freeze.

Yes, please.

> lib/perl5db ...................................................
> [...]
> so the line counter is clobbered or not reset or something such that
> we get things like "auto(-2)" indicating an impossible negative line
> number. I haven't managed to figure out whether it's the test
> infrastructure or the debugger itself that has the bug.

Odd! I can have a look, but I have no brilliant ideas.

Given the "some tests failing since 5.14," my assumption here is that we'd like
to apply the fixes for ones where we can, but having some failing tests is at
least not /worse/ than 5.14. :(

Right?

Thanks.

--
rjbs

Attachments:

signature.asc (0.48 KB)

perl.p5p at rjbs

May 8, 2012, 6:26 PM

Post #11 of 12 (128 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

* "Craig A. Berry" <craig.a.berry [at] gmail> [2012-05-04T11:40:31]
> not ok 330 - POD of x2p/s2p.com
> # Spurious =cut command
> # near line 458
>
> The =cut seems fine but the preceding =item doesn't have a blank line
> before -- isn't it suposed to? The failure can be fixed with:
>
> [ ... ]
>
> but if the way it is now is wrong, why doesn't it fail consistently on
> all platforms?

...because on non-VMS platforms it is not build as s2p.com but as psed, which
had a known problem registered. I removed it.

--
rjbs

Attachments:

signature.asc (0.48 KB)

craig.a.berry at gmail

May 9, 2012, 5:50 PM

Post #12 of 12 (122 views)
Permalink

Re: sniffing the 5.16 smoke [In reply to]

On Tue, May 8, 2012 at 8:19 PM, Ricardo Signes
<perl.p5p [at] rjbs> wrote:
> * "Craig A. Berry" <craig.a.berry [at] gmail> [2012-05-04T11:40:31]

>> � � dist/Carp/t/Carp ..............................................
>> FAILED--expected 60 tests, saw 34
>>
>> The test recently started using IPC::Open3::open3, which is not
>> available on VMS. �It has nothing to do with Carp. �I could still add
>> a skip if that's acceptable this late in code freeze.
>
> Yes, please.

I have pushed some skippage as be109f01e912.

>> � � lib/perl5db ...................................................
>> [...]
>> so the line counter is clobbered or not reset or something such that
>> we get things like "auto(-2)" indicating an impossible negative line
>> number. �I haven't managed to figure out whether it's the test
>> infrastructure or the debugger itself that has the bug.
>
> Odd! �I can have a look, but I have no brilliant ideas.

It doesn't look like I'm going to crack it for RC0. I haven't
observed the problem in real-world debugger use, so I think there
would be no real harm in aiming to sort it out for 5.16.1.

> Given the "some tests failing since 5.14," my assumption here is that we'd like
> to apply the fixes for ones where we can, but having some failing tests is at
> least not /worse/ than 5.14. �:(
>
> Right?

Makes sense to me. There was a time when I made myself and the
pumpking ill trying to get to 100% passing on the eve of a release,
but I think illness of that sort is overrated, we have a *lot* more
tests and dual-lived modules now, and 99.7% passing is pretty good for
a platform that doesn't use Configure, gcc, or have a unixy file
system or process model. Better test results than Cygwin, I'm told.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads