Re: 1.8.8 up for testing/signing

On Mon, Feb 17, 2014 at 2:47 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <ben_at_reser.org> wrote:
>> The 1.8.8 release artifacts are now available for testing/signing.
>> Please get the tarballs from
>> https://dist.apache.org/repos/dist/dev/subversion
>> and add your signatures there. I plan to try and release on February
>> 19th so please try and get your votes/signatures in place by February 17th.
>>
>> Note that autoprop_tests.py is known to have spurious failures from time to
>> time when libmagic support is enabled and tests are run in parallel.
>
> I ran into a test failure again, while testing ra_local x fsfs:
>
> [[[
> W: CWD: R:\test\subversion\tests\cmdline\svn-test-work\working_copies\tree_conflict_tests-10
> W: EXCEPTION: SVNExpectedStdout
> Traceback (most recent call last):
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\main.py",
> line 1550, in run
> rc = self.pred.run(sandbox)
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\testcase.py",
> line 176, in run
> return self.func(sandbox)
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\tree_conflict_tests.py",
> line 685, in merge_file_del_onto_not_same
> commit_local_mods=True)
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\tree_conflict_tests.py",
> line 440, in ensure_tree_conflict
> '-m', 'Mods in target branch.')
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\actions.py",
> line 282, in run_and_verify_svn
> expected_exit, *varargs)
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\actions.py",
> line 321, in run_and_verify_svn2
> verify.verify_outputs(message, out, err, expected_stdout, expected_stderr)
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\verify.py",
> line 445, in verify_outputs
> compare_and_display_lines(message, label, expected, actual, raisable)
> File "C:\research\svn\client_build\subversion-1.8.8\subversion\tests\cmdline\svntest\verify.py",
> line 418, in compare_and_display_lines
> raise raisable
> SVNExpectedStdout
> FAIL: tree_conflict_tests.py 10: merge file: del/rpl/mv onto not-same
> ]]]
>
> All other ra_local tests succeeded, and all tests over http and svn
> succeeded as well. I cannot reproduce this single failure anymore.
>
> Running on Windows XP (32 bit), a (shared) release build with VS 2010
> SP1. Tests are run non-parallellized, and with cleanup, on a ramdisk
> in a subdirectory (R:\test).
>
> Looking at this test failure, I can't think of a reason why this would
> fail (IIUC, a commit succeeded but nothing was written to stdout),
> except if there is some kind of flushing issue. Anyone have any idea?
>
> Now, I have to admit I was running a game of Starcraft with my sons
> while the test suite was running on my laptop (it was a tough battle,
> the three of us against three computer players ... we won, thanks).
> But I doubt my zerg armies could have interfered with the test, or at
> least they shouldn't have ;-).
>
> Since I also had a failure previously while testing 1.8.6 [1] (a
> different failure, with externals_tests.py#8, also non reproducible),
> I'm currently not comfortable signing this release, until this failure
> can be explained. Either there is some local problem with my laptop
> (in which case it's no longer fit for testing), or there is a real
> issue that needs some more investigation.
>
> Dependencies:
> Httpd 2.4.4
> Apr 1.4.6
> Apr-Util 1.5.2
> Apr-Iconv 1.2.1
> OpenSSL 1.0.1e
> Serf 1.3.4
> SQLite 3.7.17
> ZLib 1.2.8 (without assembly optimizations)
>
> [1] http://svn.haxx.se/dev/archive-2014-02/0084.shtml
>

Tried to reproduce it while putting load on my cpu (using [1]), but no
success. While cpu was loaded (one of my two cores fully loaded --
like when I was playing starcraft) I ran tree_conflicts_tests.py 10
times. No problem.

I'm giving up, I'm not going to sign. I'm not going to veto either ...
I just don't know what happened there, and I don't like it.

[1] http://www.fossiltoys.com/cpuload.html

-- 
Johan