[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.7.0-alpha1 tarballs up for testing/signing

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 7 Jun 2011 10:48:54 -0400

On Mon, Jun 6, 2011 at 5:54 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, Jun 6, 2011 at 2:24 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Fri, Jun 3, 2011 at 3:12 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>>> All,
>>>
>>> At long request, we now have tarballs for the first 1.7.0 pre-release:
>>> 1.7.0-alpha1 ("phoenix-hatchling").  These were cut from trunk, and
>>> the magic rev is r1130808.  The buildbots were green at that rev, and
>>> all tests pass for me locally.  You can find them here:
>>> http://people.apache.org/~hwright/svn/1.7.0-alpha1/
>>>
>>> This is an alpha release, and there are obviously known issues.  The
>>> purpose is to give distributors and downstream consumers a concrete
>>> milestone against which to test, as well as vet our release processes
>>> on ASF infrastructure.  As you may expect, these prereleases are
>>> intended for intrepid users and testers only.
>>>
>>> As a reminder, there have been a few changes in the release artifacts
>>> since the 1.6.x series.  We no longer distribute a deps tarball, but
>>> instead provide a get-deps.sh script for folks who want to fetch the
>>> dependencies.  There is no longer a 'to-tigris' directory in the
>>> candidate directory.  We no longer computer md5sums of the tarballs,
>>> but continue to provide sha1sums to verify integrity.  (There's
>>> probably other stuff I've forgotten.)
>>>
>>> I hope to get signatures from folks by the end of Tuesday, June 7, and
>>> then do the public announcement.  Historically, we've not required a
>>> full set of signatures for alphas and betas, but it would be nice to
>>> get at least some coverage besides just my own.  As you send in your
>>> signature announcement, please note any issues you found with the
>>> alpha release (these will be included in the public announcement).
>>> Please send sigs here:
>>> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>>>
>>> -Hyrum
>>
>> VERIFIED:
>> ---------
>> Hyrum's sig for
>> http://people.apache.org/~hwright/svn/1.7.0-alpha1/phoenix-hatchling/subversion-1.7.0-alpha1.zip
>>
>> Other than the expected differences in
>> subversion/include/svn_version.h,
>> http://people.apache.org/~hwright/svn/1.7.0-alpha1/phoenix-hatchling/subversion-1.7.0-alpha1.zip
>> is the same as https://svn.apache.org/repos/asf/subversion/trunk@1130808.
>>
>> BUILD FAILURES:
>> --------------
>> I was able to build the __JAVAHL__ target, but the tests
>> (__JAVAHL_TESTS__) fail to build, see attached log.  I was able to
>> build the  tests with trunk_at_1132646, so whatever is causing this
>> failure has been fixed.
>>
>>
>> TESTED:
>> -------
>> [Release-Build] x[ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
>> Ruby bindings
>>
>> RESULTS:
>> --------
>> Ruby bindings: Pass
>>
>> ----------------------------------------
>>
>> All op-depth-test.exe tests fail when bdb is the backend.  All the
>> failures are similar to this:
>>
>> [[[
>> C:\SVN\src-trunk\Release\subversion\tests\libsvn_wc>op-depth-test.exe
>> --fs-type bdb
>> svn_tests: E180001: Unable to connect to a repository at URL
>> 'file:///C:/SVN/src-trunk/Release/subversion/tests/libsvn_wc/svn-test-work/repositories/wc_wc_copies'
>> svn_tests: E180001: Unable to open an ra_local session to URL
>> svn_tests: E180001: Unable to open repository
>> 'file:///C:/SVN/src-trunk/Release/subversion/tests/libsvn_wc/svn-test-work/repositories/wc_wc_copies'
>> svn_tests: E160029: Berkeley DB error for filesystem
>> 'C:/SVN/src-trunk/Release/subversion/tests/libsvn_wc/svn-test-work/repositories/wc_wc_copies/db'
>> while opening environment:
>>
>> svn_tests: E160029: Operation not permitted
>> svn_tests: E000000: bdb: DB_REGISTER limits processes to one open
>> DB_ENV handle per environment
>> FAIL:  op-depth-test.exe 1: test_wc_wc_copies
>> ]]]
>>
>> If run individually, each test passes.
>>
>> ----------------------------------------
>>
>> Two pristine-store tests fail with a segfault whenever bdb is the backend:
>>
>>  FAIL:  pristine-store-test.exe 1: pristine_write_read
>>  FAIL:  pristine-store-test.exe 2: pristine_delete_while_open
>>
>> The problem looks similar to that with op-depth-tests.exe, and again
>> the test pass if run individually:
>>
>> [[[
>> C:\SVN\src-trunk-2\Debug\subversion\tests\libsvn_wc>pristine-store-test.exe
>> --fs-type bdb
>> ..\..\..\subversion\tests\libsvn_wc\pristine-store-test.c:122: (apr_err=180001)
>> ..\..\..\subversion\tests\libsvn_wc\pristine-store-test.c:66: (apr_err=180001)
>> ..\..\..\subversion\tests\libsvn_wc\utils.c:143: (apr_err=180001)
>> ..\..\..\subversion\tests\libsvn_wc\utils.c:85: (apr_err=180001)
>> ..\..\..\subversion\libsvn_client\checkout.c:138: (apr_err=180001)
>> ..\..\..\subversion\libsvn_client\ra.c:464: (apr_err=180001)
>> ..\..\..\subversion\libsvn_client\ra.c:324: (apr_err=180001)
>> ..\..\..\subversion\libsvn_ra\ra_loader.c:496: (apr_err=180001)
>> ..\..\..\subversion\libsvn_ra\ra_loader.c:496: (apr_err=180001)
>> svn_tests: E180001: Unable to connect to a repository at URL
>> 'file:///C:/SVN/src-trunk-2/Debug/subversion/tests/libsvn_wc/svn-test-work/repositories/pristine_wr
>> ite_read'
>> ..\..\..\subversion\libsvn_ra_local\ra_plugin.c:475: (apr_err=180001)
>> ..\..\..\subversion\libsvn_ra_local\ra_plugin.c:475: (apr_err=180001)
>> svn_tests: E180001: Unable to open an ra_local session to URL
>> ..\..\..\subversion\libsvn_ra_local\split_url.c:54: (apr_err=180001)
>> svn_tests: E180001: Unable to open repository
>> 'file:///C:/SVN/src-trunk-2/Debug/subversion/tests/libsvn_wc/svn-test-work/repositories/pristine_write_read'
>> ..\..\..\subversion\libsvn_repos\repos.c:1374: (apr_err=160029)
>> ..\..\..\subversion\libsvn_fs\fs-loader.c:436: (apr_err=160029)
>> ..\..\..\subversion\libsvn_fs_base\fs.c:542: (apr_err=160029)
>> svn_tests: E160029: Berkeley DB error for filesystem
>> 'C:/SVN/src-trunk-2/Debug/subversion/tests/libsvn_wc/svn-test-work/repositories/pristine_write_read/db'
>> whi
>> le opening environment:
>>
>> ..\..\..\subversion\libsvn_fs_base\bdb\env.c:710: (apr_err=160029)
>> ..\..\..\subversion\libsvn_fs_base\bdb\env.c:588: (apr_err=160029)
>> ..\..\..\subversion\libsvn_fs_base\bdb\bdb-err.c:62: (apr_err=160029)
>> svn_tests: E160029: Operation not permitted
>> ..\..\..\subversion\libsvn_fs_base\bdb\env.c:229: (apr_err=0)
>> svn_tests: E000000: bdb: DB_REGISTER limits processes to one open
>> DB_ENV handle per environment
>> ]]]
>> ----------------------------------------
>>
>> One tree-conflict-data tests fails with a segfault whenever bdb is the backend:
>>
>>  FAIL:  tree-conflict-data-test.exe 3: read and write tree conflicts
>>
>> The problem looks similar to that with op-depth-tests.exe, and again
>> the test passes if run individually:
>
> Scratch that, the op-depth, pristine-store, and tree-conflict-data all
> fail individually too.  I hadn't realized that this:
>
>  op-depth-test.exe 1 --fs-type bdb
>
> is not equivalent to this:
>
>  op-depth-test.exe --fs-type bdb 1
>
> Fixed that in r1132796
>
> Paul

In IRC Bert mentioned he saw no failures with the op-depth,
pristine-store, and tree-conflict-data tests when using static
libraries (he hadn't tried shared). Sure enough, if I build with
static libraries these tests all pass.

Given that "This is an alpha release, and there are obviously known
issues" I'm voting +1 for release (with the understanding that the
aforementioned failures are among the "know issues").

Here's my sig for
http://people.apache.org/~hwright/svn/1.7.0-alpha1/phoenix-hatchling/subversion-1.7.0-alpha1.zip
(submitted it to collect_sigs.py too):

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQBN7jeh2RaJMFP83FURArfiAJ9ZXrfef7QTs5MZu7MLx0+QMbk/dQCfeUNM
wFi9DWwEn0r9ldfsr4HKSY4=
=YrS3
-----END PGP SIGNATURE-----

Paul
Received on 2011-06-07 16:49:29 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.