Nathan Hartman wrote on Wed, Dec 25, 2019 at 12:07:35 -0500:
> On Wed, Dec 25, 2019 at 1:38 AM Yasuhito FUTATSUKI <futatuki_at_poem.co.jp> wrote:
> >
> > On 2019/12/25 6:38, Nathan Hartman wrote:
> > > When running the regression test suite via the 'svn-check' target of
> > > tools/dev/unix-build/Makefile.svn, is there a convenient way to see a
> > > "All tests successful"-type summary at the very end?
> > >
> > > That is to say, is there a better way than what I'm doing now,
> > > which is:
> > >
> > > $ cat tests.log.* | grep ^FAIL
> >
> > It isn't an answer for your question, but this can miss 'XPASS'.
>
> Thank you. Yes, you are right.
>
> I ran it again, redirecting stderr and stdout to a file, and that
> generates much less output (around 2000 lines). But if someone has a
> better way, I'd love to hear about it.
For starters, you can use the fails.log files. They're generated by
build/run_tests.py after tests.log gets fully written (not during the run), and
they aren't removed when a test run starts (so beware of them remaining around
after you've already fixed a bug), but if they exist at all, they contain only
FAILs and XPASSes. If you're just looking for a quick "Did any test fail?"
bit, you can just check whether any fails.log.* file exists.
I don't know of an easy answer to your question for bindings tests. Does the
svn-check target exit non-zero when any test has failed? If it did, that would
at least handle the common case of "All tests passed".
stsp may know more.
> Observations from running the regression tests:
>
> (1) I get one test failure in [svn x bdb]:
> FAIL: autoprop_tests.py 7: import: config=no, commandline=none
>
> This test passes for all other RA x backend combinations.
With trunk on Linux:
% make svnserveautocheck FS_TYPE=bdb CLEANUP=1 TESTS="subversion/tests/cmdline/autoprop_tests.py"
⋮
SUMMARY: All tests successful
%
What was the error (in the .log file)?
> For this test run, I ran the test on trunk_at_1871942 with Sergey's
> patch "Rework of r1866425 ('Last-Modified' header)" [1] applied. (I
> doubt that should affect the autoprop test that failed above? I'll
> have to run it again without the patch to find out.)
That patch shouldn't affect the ra_svn/bdb behaviour, unless you run
davautocheck and svnserveautocheck in parallel on the same svn-test-work
directory.
> Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_serf]
> swig bindings
>
> Platform: Linux 4.19.0-6-rt-amd64 x86_64
>
> Dependencies:
> bdb: 4.7.25
> GNU-iconv: 1.15
> apr: 1.5.2
> apr-util: 1.5.4
> httpd: 2.4.37
> serf: 1.4.x
> cyrus-sasl: 2.1.27
> sqlite: 3160200
> lz4: 1.7.5
> libssl: OpenSSL 1.1.1d 10 Sep 2019
> swig: 3.0.12
> python: 3.7.5
> perl: 5.28.1
> ruby: 2.4.4
:-)
> To make successfully on Debian Buster, because of OpenSSL 1.1.1d, I
> modified Makefile.svn to use Serf 1.4.x (from branches as there is no
> 1.4.x release yet) and Cyrus SASL 2.1.27. Also I removed all the
> serf-old targets which are applicable to svn 1.5 and were breaking the
> build for me, thanks again to OpenSSL. I didn't commit my changes
> because that will probably break the OpenBSD buildbot.
It would be nice to find a way for you to share your changes without breaking
the bot. Could you talk to stsp about this?
> Also it failed on building the perl bindings with "Only one of PREFIX
> or INSTALL_BASE can be given. Not both." I didn't really know what to
> do about that so I just 'env | grep PERL' and unset the four
> environment variables that showed up (PERL5LIB, PERL_MB_OPT,
> PERL_MM_OPT, and PERL_LOCAL_LIB_ROOT) for the session and that got rid
> of the error.
I guess MB and MM stand for Module::Build and ExtUtils::MakeMaker,
respectively. subversion/bindings/swig/perl/native/Makefile.PL.in uses the
latter. So it sounds like PERL_MM_OPT in the build environment conflicts with
how Makefile invokes subversion/bindings/swig/perl/native/Makefile.PL. I don't
know what the fix is, though.
Cheers,
Daniel
Received on 2019-12-26 03:37:18 CET