You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2014/02/14 00:44:44 UTC

1.8.8 up for testing/signing

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.

Thanks!

Re: 1.8.8 up for testing/signing

Posted by Branko Čibej <br...@wandisco.com>.
On 16.02.2014 14:35, Branko Čibej wrote:
>     Dependencies from homebrew:
>       SQLite 3.8.3
>       Serf 1.3.3

Actually, it was Serf 1.3.4.



-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: 1.8.8 up for testing/signing

Posted by Branko Čibej <br...@wandisco.com>.
Summary:

    +1 to release

Platform

    Mac OS X 10.9.1 Mavericks, build 13B42

    Standard dependencies:
      Apple clang(++) 5.0 (clang-500.2.79)/LLVM 3.3svn
      APR 1.4.5
      APR-Util 1.3.12
      zlib 1.2.5
      httpd 2.2.24
      OpenSSL 0.9.8y
      Python 2.7.5
      Perl 5.16.2
      Ruby 2.0.0p247
      SQLite 3.7.13

    Dependencies from homebrew:
      SQLite 3.8.3
      Serf 1.3.3
      BDB 5.3.28
      Swig 2.0.12
      libmagic 5.16

    Other dependencies:
      Java 1.7.0_51-b13
      JUnit 4.11

Verified:

  Tarball contents and signatures

  (fsfs, bdb) x (local, svnserve, dav) with SQLite 3.8.3
  (fsfs) x (local with SQLite 3.7.13
  check-all-javahl
  check-swig-py
  check-swig-rb
  check-swig-pl

New issues: None

Known issues:

  - C tests do not work with the --enable-optimize configure option.

  - Expanded URL keywords in the tarballs point to the release branch;
    they should point to the tag instead.

GPG Signatures committed to the dist/dev/subversion repository.


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

Re: 1.8.8 up for testing/signing

Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <be...@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.
>
> Thanks!

Summary
-------
+1 to release

Platform
--------
Windows XP (32 bit) SP3
Microsoft Visual Studio 2010 SP1

Verified
--------
Signature and sha1 for subversion-1.8.8.zip.

Contents of subversion-1.8.8.zip are identical to tags/1.8.8, and to
branches/1.8.x@1568071 (except for expected differences in svn_version.h,
svnpubsub and svnwcsub (symlinks vs. file contents)).

Tested
------
[ Release build ] x [ fsfs ] x [ file | svn | http ]

Results
-------
All tests pass [*].

[*] I had one spurious failure of tree_conflict_tests.py 10
(merge file: del/rpl/mv onto not-same) while testing ra_local. I could not
reproduce it despite many repeated attempts. A hypothesis is that svn failed
to flush output after 'svn commit'. This has been suggested here [1] and
further explained here [2]. I do not think this is a regression.

[1] http://svn.haxx.se/dev/archive-2014-02/0198.shtml
[2] http://svn.haxx.se/dev/archive-2014-02/0206.shtml

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)

Signature
---------

subversion-1.8.8.zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iQIcBAABCgAGBQJS/8ikAAoJELWc5tYBDIqt5tYQAJdvZqZZbvpRtYn0ZY74IL1K
mnxRUvNMAwR8hOPcSaNkRyIdq6qQ8PCrQAKVGO97natFrxgNs2P+LMbvfpPF5ST9
9guUtp/GrqcTp6ILJ5r5kOT8wSqCOOJSSYOZer3021SypZ4hnXep99iPHnyG8btC
HhkkqpPJEGDVa7ntwU97P8XrLgFXKjkqO7vYjILZDvdEkLWHS/jeLrFZxvCAZKzS
ekgdZykNcXB/VR7uLWjPhRwjTRPkAwBeH9NGDjt0BfRvzmxfFyJ7EUpumR6eKcOT
Hx0ounSs9YT44nKyEPNIK2hXlJ6HaHbIWLYGTyJNYiXAfvxh6J7uWD4ey98te4cP
IeTZCFs7GIWluGV2Z+iAZkLEKu9E78MB9ssfe7j/y5C8gQYIZKuF0lr5dwgBzEwc
EAdjY4pV1FRtT1Uo1VpKCBuN1w6nOaB5NuHzJnIO4h91oM9ouyVDqHh3DzGHW8gs
iEyQE0+ySlqjrUt42Xwzm/KsINkNnth24UVPSourx4wY3w2hXgZ2c/BEXVU0e2PL
EI18qUawSYGcR2+6mEjc10ItvlXWZ0QQCgOejbHSeRT0YVSHBKOiWfN8K4jtnYdp
2eCs0JE7mYViHcb0moM9jNktT3ceMXmqmhYK+5u3PvyrjS1Hzila5Pe2OvHj2J30
6FEjcH8J5DX2k55Nkbl/
=JsN+
-----END PGP SIGNATURE-----


-- 
Johan

Re: 1.8.8 up for testing/signing

Posted by Philip Martin <ph...@wandisco.com>.
Summary:

  +1 to release

Platform:

  Linux (Debian/wheezy) 64-bit

Tested:

  (local, svn, svn/sasl, serf, serf/v1) x (fsfs, fsfs/pack/shard, bdb)
  swig-pl, swig-py, swig-rb, ctypes-python
  javahl x (fsfs, bdb)

Results:

  All tests successful

Local dependencies:

  apache2-threaded-dev : 2.2.22-13+deb7u1
  libapr1-dev : 1.4.6-3+deb7u1
  libaprutil1-dev : 1.4.1-3
  libdb5.1-dev : 5.1.29-5
  libsasl2-dev : 2.1.25.dfsg1-6+deb7u1
  libsqlite3-dev : 3.7.17-1~bpo70+1
  perl : 5.14.2-21+deb7u1
  python2.7-dev : 2.7.3-6
  ruby1.8-dev : 1.8.7.358-7.1+deb7u1
  openjdk-7-jdk : 7u25-2.3.10-1~deb7u1
  serf : 1.3.x@2243

subversion-1.8.8.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAABCAAGBQJS/gFOAAoJEHbXiOHtGlmc02oH/RRkG310NDQsKF22BdKZeokN
KZ2zX3FbJc3v+4ExqP0kJ2YtZ03n9V09VG4ymqaEjoZzjHnkeVYRcgqd9jCldU46
C4E0iH5DZOOQ2JtGEhDHzThCnuEt/IzlC04U6ErCCAdyqemDjiSe43MPq0cKpVFJ
qczO2CPE4bPyWcNfYmfp97nNq6d9Je6cesqkWvc3oPaI1C3JgHwu4OFAy7NKYRUD
3P+SyDZMeztzyGcVAwNiWlzFxxOyE7B/cA4MCjt2cHN9Vf9L6nAmNh02EddltdeR
SBNLXnfXmNhDTT21mf4dN693dKy8oCPgBEiCN1Ehj9e4YkX58fith97pxdcxsSM=
=AvzE
-----END PGP SIGNATURE-----

subversion-1.8.8.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAABCAAGBQJS/gFOAAoJEHbXiOHtGlmc5tQH/2rlHGZetVBw/sQttktFtJP0
aM8yPWm8HcnIstIpVYt1OKggUBXJbMn4Gxcff5Z6DBY6IuEgRiotOFwOS2R6JHC2
9ByS9Z4tfX1CF/yueKAT6mtYfKov6WnTgOqZ6OKOZjIKutxQg8pLwT6y3VfHA2Yv
uIW6SyyVQ12VF5HD1sblAdxO0EsCqOCctSRX777EioRxHAGlCKHkBDmYZOgvK1zo
VCVR5B7aplpxhuwEHyvM0d+rGChgcDxjsZgn2invLOQThVFensPxrQcyDJhfQDyY
kQAjCD4VsmQCvcYuVHpmj+XYZIwRsXXKvuCvULSDg3JDJZ5KQDaRQCET0MIQwzM=
=aTFN
-----END PGP SIGNATURE-----

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: 1.8.8 up for testing/signing

Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <be...@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.
>
> Thanks!
>

Summary:

  +1 to release

Platform

  Ubuntu 13.10 x64, Linux 3.11.0-13-generic SMP

  Standard dependencies:
    APR 1.4.8
    APR-Util 1.5.2
    BDB 5.1.6
    GCC 4.8.1
    httpd 2.4.6
    JUnit 4.11
    libmagic 5.11
    OpenJDK-7 7u25
    OpenSSL 1.0.1e
    Perl 5.14.2
    Python 2.7.5+
    Ruby 1.8.7
    Swig 2.0.10
    zlib 1.2.8

  Manually installed and in-tree dependencies:
    SQLite 3.7.15.1
    Serf 1.3.2
    ctypesgen svn-r151

Verified:

  Tarball contents and signatures

  (fsfs, bdb) x (local, svnserve, neon, serf)
  check-swig-py
  check-swig-pl
  check-swig-rb
  check-javahl
  check-ctypes-python

  ./get-deps.sh

Results:

  All tests passed.

GPG Signatures committed to the dist/dev/subversion repository.

Re: 1.8.8 up for testing/signing

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 14 February 2014 03:44, Ben Reser <be...@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.
>
Summary:
--------

   +1 to release.

TESTED:
-------
[ fsfs ] x [ file | svn | http v1 | http v2] x [win32 | x64]

RESULTS:
--------
All Tests Pass

PLATFORM:
---------
MS Windows 7 Ultimate (x64)
Microsoft Visual Studio 2008 Version 9.0.30729.1 SP

DEPENDENCIES:
-------------
APR: 1.4.8
APR-Util: 1.5.2
Apache HTTPD: 2.2.25 with r1497121 and r1497441 reverted.
zlib: 1.2.8
OpenSSL: 0.9.8y
sqlite: 3.7.12.1
Python: 2.6.6
serf: 1.3.4

Signatures:
-----------

   (See the appropriate distribution files.)


-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

Re: 1.8.8 up for testing/signing

Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Feb 19, 2014 at 9:04 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Ben Reser wrote:
>
>> On 2/18/14, 12:22 PM, Johan Corveleyn wrote:
>>>  Thanks for the hint. Now, this wasn't an error path (just a commit
>>>  that should have succeeded and should've written something to stdout).
>>>  I'm not sure how I can determine that this is the likely cause ... I
>>>  can't seem to reproduce it, no matter how hard I try :-(.
>>
>> I unfortunately don't have any good suggestions.  However, I'm assuming we made
>> the change to flush stdout when there wasn't an error for some good reason.
>
> Just to be clear about the change <http://svn.apache.org/r1543868> and the reason for it, the change is to flush stdout explicitly before exit rather than implicitly at exit, and the reason is to consistently report if the flush fails. From the log message:
>
> "in order
> to report consistently if any information written to standard output is
> being lost.
>
> Standard output would be flushed on exit anyway, but this makes sure that
> output is not silently lost if it [the flush] fails. We will get both an error message
> on stderr and a non-zero exit code."
>
> Previously, in contrast to an error in any other print or flush, if an error occurred in the final flush (during the C run-time exit) then svn exited successfully.

Okay, so IIUC, the flush may fail, and before r1543868 we wouldn't
detect that (or not in all cases). So a possible hypothesis for the
failed test is that the flush somehow failed, and svn didn't notice /
report it (by erroring out). With r1543868 this would no longer be
possible, because svn would yield an error.

Thanks, I guess that makes sense now as a possible cause.

-- 
Johan

Re: 1.8.8 up for testing/signing

Posted by Julian Foad <ju...@btopenworld.com>.
Ben Reser wrote:

> On 2/18/14, 12:22 PM, Johan Corveleyn wrote:
>>  Thanks for the hint. Now, this wasn't an error path (just a commit
>>  that should have succeeded and should've written something to stdout).
>>  I'm not sure how I can determine that this is the likely cause ... I
>>  can't seem to reproduce it, no matter how hard I try :-(.
> 
> I unfortunately don't have any good suggestions.  However, I'm assuming we made
> the change to flush stdout when there wasn't an error for some good reason.

Just to be clear about the change <http://svn.apache.org/r1543868> and the reason for it, the change is to flush stdout explicitly before exit rather than implicitly at exit, and the reason is to consistently report if the flush fails. From the log message:

"in order
to report consistently if any information written to standard output is
being lost.

Standard output would be flushed on exit anyway, but this makes sure that
output is not silently lost if it [the flush] fails. We will get both an error message
on stderr and a non-zero exit code."

Previously, in contrast to an error in any other print or flush, if an error occurred in the final flush (during the C run-time exit) then svn exited successfully.

- Julian

Re: 1.8.8 up for testing/signing

Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 18, 2014 at 11:15 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Ben Reser <be...@reser.org> writes:
>
>> On 2/18/14, 12:22 PM, Johan Corveleyn wrote:
>>> Thanks for the hint. Now, this wasn't an error path (just a commit
>>> that should have succeeded and should've written something to stdout).
>>> I'm not sure how I can determine that this is the likely cause ... I
>>> can't seem to reproduce it, no matter how hard I try :-(.
>>
>> I unfortunately don't have any good suggestions.  However, I'm assuming we made
>> the change to flush stdout when there wasn't an error for some good reason.
>>
>>> Bert also suggested another possible reason: perhaps it was no
>>> flushing problem, but rather that the commit didn't do anything
>>> because the commit crawler didn't find any mods (perhaps because of
>>> timestamp granularity stuff). If my ramdisk would have been a FAT32
>>> partition, that might be a possible explanation, but "unfortunately"
>>> it's an NTFS ramdisk ... I don't see how this could have happened.
>>> Perhaps someone can hypothesize something, and talk me through a
>>> possible scenario?
>>
>> NTFS itself has 100 nanosecond resolution, but I don't believe you can actually
>> achieve that resolution with Windows XP.  See:
>> http://www.infosec.jmu.edu/documents/jmu-infosec-tr-2009-002.pdf
>>
>> That paper shows that Windows XP was only capable of providing 1600 nanosecond
>> resolution.
>>
>> I don't know if this is enough to drive the issue you're seeing.  But it's
>> useful to realize that NTFS's storage capability doesn't reflect the actual
>> accuracy of timestamps in practice.
>
> The timestamp problem can only occur if a text modification doesn't
> change the filesize and in this case the text modifications always do
> change the size.  I'm assuming XP does set NODES.translated_size, can
> you confirm that?
>
>   sqlite3 .svn/wc.db "select local_relpath, translated_size from nodes where kind='file'"

You mean in a random working copy checked out with my 1.8.8-built
client? Yes, it seems to be always set:

[[[
C:\research\svn\client_build\test\subversion>svn --version
svn, version 1.8.8 (r1568071)
   compiled Feb 15 2014, 20:57:51 on x86-microsoft-windows5.1.2600
...

C:\research\svn\client_build\test>svn co
https://svn.apache.org/repos/asf/subversion/trunk/subversion
...

C:\research\svn\client_build\test>cd subversion

C:\research\svn\client_build\test\subversion>sqlite3 .svn/wc.db
"select local_relpath, translated_size from nodes where kind='file'"
svnserve/cyrus_auth.c|12843
svnserve/server.h|9465
svnserve/svnserve.c|46457
svnserve/winservice.c|17594
svnserve/log-escape.c|5057
svnserve/logger.c|5115
svnserve/svnserve.8|5379
...

C:\research\svn\client_build\test\subversion>sqlite3 .svn/wc.db
"select local_relpath, translated_size from nodes where kind='file'
and translated_size is null"

<nothing>
]]]


> From the failure message posted we know the commit was silent but we
> don't know whether it silently created a revision or silently did
> nothing.  I expect the working copy and repository no longer exist so we
> cannot examine them.

Unfortunately not.

Okay, so far I'm assuming that the commit probably went through as it
should (since the file size should have been changed), but that
flushing of the output failed somehow (which should, on trunk, report
an error as of r1543868 -- but not on 1.8.x).

I think I can live with that hypothesis for this spurious failure :-).
I'll wrap up my stuff and sign the release.

Thanks all for your help trying to diagnose this.

-- 
Johan

Re: 1.8.8 up for testing/signing

Posted by Philip Martin <ph...@wandisco.com>.
Ben Reser <be...@reser.org> writes:

> On 2/18/14, 12:22 PM, Johan Corveleyn wrote:
>> Thanks for the hint. Now, this wasn't an error path (just a commit
>> that should have succeeded and should've written something to stdout).
>> I'm not sure how I can determine that this is the likely cause ... I
>> can't seem to reproduce it, no matter how hard I try :-(.
>
> I unfortunately don't have any good suggestions.  However, I'm assuming we made
> the change to flush stdout when there wasn't an error for some good reason.
>
>> Bert also suggested another possible reason: perhaps it was no
>> flushing problem, but rather that the commit didn't do anything
>> because the commit crawler didn't find any mods (perhaps because of
>> timestamp granularity stuff). If my ramdisk would have been a FAT32
>> partition, that might be a possible explanation, but "unfortunately"
>> it's an NTFS ramdisk ... I don't see how this could have happened.
>> Perhaps someone can hypothesize something, and talk me through a
>> possible scenario?
>
> NTFS itself has 100 nanosecond resolution, but I don't believe you can actually
> achieve that resolution with Windows XP.  See:
> http://www.infosec.jmu.edu/documents/jmu-infosec-tr-2009-002.pdf
>
> That paper shows that Windows XP was only capable of providing 1600 nanosecond
> resolution.
>
> I don't know if this is enough to drive the issue you're seeing.  But it's
> useful to realize that NTFS's storage capability doesn't reflect the actual
> accuracy of timestamps in practice.

The timestamp problem can only occur if a text modification doesn't
change the filesize and in this case the text modifications always do
change the size.  I'm assuming XP does set NODES.translated_size, can
you confirm that?

  sqlite3 .svn/wc.db "select local_relpath, translated_size from nodes where kind='file'"

>From the failure message posted we know the commit was silent but we
don't know whether it silently created a revision or silently did
nothing.  I expect the working copy and repository no longer exist so we
cannot examine them.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: 1.8.8 up for testing/signing

Posted by Ben Reser <be...@reser.org>.
On 2/18/14, 12:22 PM, Johan Corveleyn wrote:
> Thanks for the hint. Now, this wasn't an error path (just a commit
> that should have succeeded and should've written something to stdout).
> I'm not sure how I can determine that this is the likely cause ... I
> can't seem to reproduce it, no matter how hard I try :-(.

I unfortunately don't have any good suggestions.  However, I'm assuming we made
the change to flush stdout when there wasn't an error for some good reason.

> Bert also suggested another possible reason: perhaps it was no
> flushing problem, but rather that the commit didn't do anything
> because the commit crawler didn't find any mods (perhaps because of
> timestamp granularity stuff). If my ramdisk would have been a FAT32
> partition, that might be a possible explanation, but "unfortunately"
> it's an NTFS ramdisk ... I don't see how this could have happened.
> Perhaps someone can hypothesize something, and talk me through a
> possible scenario?

NTFS itself has 100 nanosecond resolution, but I don't believe you can actually
achieve that resolution with Windows XP.  See:
http://www.infosec.jmu.edu/documents/jmu-infosec-tr-2009-002.pdf

That paper shows that Windows XP was only capable of providing 1600 nanosecond
resolution.

I don't know if this is enough to drive the issue you're seeing.  But it's
useful to realize that NTFS's storage capability doesn't reflect the actual
accuracy of timestamps in practice.

Re: 1.8.8 up for testing/signing

Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 18, 2014 at 5:22 PM, Ben Reser <be...@reser.org> wrote:
> On 2/17/14, 3:27 PM, Johan Corveleyn wrote:
>> On Mon, Feb 17, 2014 at 2:47 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <be...@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
>
> Possibly related to:
> [[[
> r1544028 | svn-role | 2013-11-20 20:02:55 -0800 (Wed, 20 Nov 2013) | 11 lines
>
> Merge the r1499470 group from trunk:
>
>  * r1499470, r1543413
>    Flush stdout before exiting svn with an error.
>    Justification:
>       Without this patch merge_tests.py 135 may fail to output its required
>       output.
>    Votes:
>      +1: ivan (without r1543413)
>      +1: rhuijben, stsp, pburba
> ]]]
>
> There is a related change on trunk that has not been backported to my knowledge:
> https://svn.apache.org/r1543868
>
> The backported revisions only resolve the error cases the above revision
> resolves also the successful cases.  Maybe you're running into a random failure
> due to this?

Thanks for the hint. Now, this wasn't an error path (just a commit
that should have succeeded and should've written something to stdout).
I'm not sure how I can determine that this is the likely cause ... I
can't seem to reproduce it, no matter how hard I try :-(.

Bert also suggested another possible reason: perhaps it was no
flushing problem, but rather that the commit didn't do anything
because the commit crawler didn't find any mods (perhaps because of
timestamp granularity stuff). If my ramdisk would have been a FAT32
partition, that might be a possible explanation, but "unfortunately"
it's an NTFS ramdisk ... I don't see how this could have happened.
Perhaps someone can hypothesize something, and talk me through a
possible scenario?

-- 
Johan

Re: 1.8.8 up for testing/signing

Posted by Ben Reser <be...@reser.org>.
On 2/17/14, 3:27 PM, Johan Corveleyn wrote:
> On Mon, Feb 17, 2014 at 2:47 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <be...@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

Possibly related to:
[[[
r1544028 | svn-role | 2013-11-20 20:02:55 -0800 (Wed, 20 Nov 2013) | 11 lines

Merge the r1499470 group from trunk:

 * r1499470, r1543413
   Flush stdout before exiting svn with an error.
   Justification:
      Without this patch merge_tests.py 135 may fail to output its required
      output.
   Votes:
     +1: ivan (without r1543413)
     +1: rhuijben, stsp, pburba
]]]

There is a related change on trunk that has not been backported to my knowledge:
https://svn.apache.org/r1543868

The backported revisions only resolve the error cases the above revision
resolves also the successful cases.  Maybe you're running into a random failure
due to this?

Re: 1.8.8 up for testing/signing

Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Feb 17, 2014 at 2:47 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <be...@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

Re: 1.8.8 up for testing/signing

Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser <be...@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

-- 
Johan

RE: 1.8.8 up for testing/signing

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Ben Reser [mailto:ben@reser.org]
> Sent: vrijdag 14 februari 2014 00:45
> To: Subversion Development
> Subject: 1.8.8 up for testing/signing
> 
> 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.

+1 for release.

I ran the tests using the Visual C++ 2012 on a Windows 8.1 test environment
this time.

apr 1.5.0
apr-util 1.5.3
bdb 4.4.20
expat 2.0.1
httpd 2.4.7
java-sdk 1.7.0_45
mod_dav 2.4.7
openssl 1.0.1f
sasl 2.1.26
serf 1.3.3
sqlite 3.7.17
zlib 1.2.8

I ran [fsfs | bdb] x [local | svn | dav]

Signatures are already committed.

	Bert