You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2010/01/12 22:52:33 UTC
1.6.8 up for signing / testing
After pulling 1.6.7 due to a segfault regression, we've rerolled the branch as Subversion 1.6.8. The magic revision is r898464, and you can find the tarballs here:
http://orac.ece.utexas.edu/pub/svn/1.6.8/
Please be sure to test the bindings.
You know the drill: signatures from full committers back to me, and enthusiastic tester feedback is welcome. At this point, this candidate is not yet blessed for wide release, so please don't make it available to people not interested in test-driving the new release.
Distro package maintainers, please do NOT include any pre-release builds, even blessed, into operating system distros. The reasons for not doing so were very eloquently outlined by Karl in a mail, which is summarized at the above address.
The quick version is: we don't guarantee compatibility between the pre-releases and the final release, so if people install the release candidate, all their repositories and working copies might break irreparably when they upgrade to 1.6.8 proper. We don't want that kind of bad publicity, and neither do you.
-Hyrum
Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I can reproduce as follows:
>
> $ rm -rf repo
> $ svnadmin create repo
> $ svn mkdir -mm http://localhost/repo/A
> $ svn copy -mm http://localhost/repo/A http://localhost/repo/B
> lt-svn: ../src-1.6/subversion/libsvn_subr/path.c:955: svn_path_url_add_component2: Assertion `svn_path_is_canonical(url, pool)' failed.
> Aborted
The crash occurs in code added in r889935, the 1.6.x-issue3519 merge,
although whether this revision introduced the problem or just
uncovered an existing bug I'm not sure. The following change to
svn_ra_serf__get_baseline_info fixes the crash:
Index: ../src-1.6/subversion/libsvn_ra_serf/property.c
===================================================================
--- ../src-1.6/subversion/libsvn_ra_serf/property.c (revision 898492)
+++ ../src-1.6/subversion/libsvn_ra_serf/property.c (working copy)
@@ -985,6 +985,8 @@
"requested baseline-collection value"));
}
+ basecoll_url = svn_path_canonicalize(basecoll_url, pool);
+
if (latest_revnum)
{
const char *version_name;
A similar line is already present in trunk, although there it calls
svn_uri_canonicalize which is not available in 1.6.
--
Philip
Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
Lieven Govaerts <sv...@mobsol.be> writes:
> You mean ra_serf, not serf. I've triggered a build on the Mac buildbot
> with ra_serf to see if it has the same problem, cause it's the first
> time I see these errors.
>
> On what platform are you building?
64-bit Linux (Debian/Lenny).
I can reproduce as follows:
$ rm -rf repo
$ svnadmin create repo
$ svn mkdir -mm http://localhost/repo/A
$ svn copy -mm http://localhost/repo/A http://localhost/repo/B
lt-svn: ../src-1.6/subversion/libsvn_subr/path.c:955: svn_path_url_add_component2: Assertion `svn_path_is_canonical(url, pool)' failed.
Aborted
Here's a bit of a gdb session:
Breakpoint 1, get_version_url (checked_in_url=0x1d48f80, session=0x1cd0a28,
conn=0x1cd7dc0, relpath=0x7f654a2fa8da "", base_revision=1,
parent_vsn_url=0x0, pool=0x1d48ee8)
at ../src-1.6/subversion/libsvn_ra_serf/commit.c:486
486 SVN_ERR(svn_ra_serf__get_baseline_info(&bc_url, &bc_relpath,
(gdb) s
svn_ra_serf__get_baseline_info (bc_url=0x7fffe0877b80,
bc_relative=0x7fffe0877b78, session=0x1cd0a28, conn=0x1cd7dc0,
url=0x1cd7c90 "/repo", revision=1, latest_revnum=0x0, pool=0x1d48ee8)
at ../src-1.6/subversion/libsvn_ra_serf/property.c:938
938 apr_hash_t *props = apr_hash_make(pool);
(gdb) n
941 if (! url)
(gdb)
946 if (! conn)
(gdb)
949 SVN_ERR(svn_ra_serf__discover_root(&vcc_url, &relative_url,
(gdb)
952 if (revision != SVN_INVALID_REVNUM)
(gdb) p vcc_url
$1 = 0x1cc48f0 "/repo/!svn/vcc/default"
(gdb) n
954 SVN_ERR(svn_ra_serf__retrieve_props(props, session, conn,
(gdb)
957 basecoll_url = svn_ra_serf__get_ver_prop(props, vcc_url, revision,
(gdb)
981 if (!basecoll_url)
(gdb) p basecoll_url
$2 = 0x1cd89b0 "/repo/!svn/bc/1/"
(gdb) fin
Run till exit from #0 svn_ra_serf__get_baseline_info (bc_url=0x7fff68746460,
bc_relative=0x7fff68746458, session=0x1c24a28, conn=0x1c2bdc0,
url=0x1c2bc90 "/repo", revision=1, latest_revnum=0x0, pool=0x1c9cee8)
at ../src-1.6/subversion/libsvn_ra_serf/property.c:988
0x00007fefc1379e60 in get_version_url (checked_in_url=0x1c9cf80,
session=0x1c24a28, conn=0x1c2bdc0, relpath=0x7fefc13938da "",
base_revision=1, parent_vsn_url=0x0, pool=0x1c9cee8)
at ../src-1.6/subversion/libsvn_ra_serf/commit.c:486
486 SVN_ERR(svn_ra_serf__get_baseline_info(&bc_url, &bc_relpath,
Value returned is $3 = (svn_error_t *) 0x0
(gdb) n
490 propfind_url = svn_path_url_add_component2(bc_url, bc_relpath, pool);
(gdb) p bc_url
$4 = 0x1c2c9b0 "/repo/!svn/bc/1/"
(gdb) n
lt-svn: ../src-1.6/subversion/libsvn_subr/path.c:955: svn_path_url_add_component2: Assertion `svn_path_is_canonical(url, pool)' failed.
Program received signal SIGABRT, Aborted.
0x0000003e68431ed5 in raise () from /lib/libc.so.6
Using wireshark I see that the basecoll_url value is exactly what the
server sends over the wire:
PROPFIND /repo/!svn/bln/1 HTTP/1.1
Transfer-Encoding: chunked
Depth: 0
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth,http://subversion.tigris.org/xmlns/dav/svn/mergeinfo,http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Content-Type: text/xml
User-Agent: SVN/1.6.8 (dev build) serf/0.3.0
Host: localhost:8888
94
<?xml version="1.0" encoding="utf-8"?><propfind xmlns="DAV:"><prop><baseline-collection xmlns="DAV:"/><version-name xmlns="DAV:"/></prop></propfind>
0
HTTP/1.1 207 Multi-Status
Date: Wed, 13 Jan 2010 21:05:55 GMT
Server: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g DAV/2 SVN/1.7.0-dev
Content-Length: 441
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:">
<D:response xmlns:lp1="DAV:" xmlns:lp2="http://subversion.tigris.org/xmlns/dav/">
<D:href>/repo/!svn/bln/1</D:href>
<D:propstat>
<D:prop>
<lp1:baseline-collection><D:href>/repo/!svn/bc/1/</D:href></lp1:baseline-collection>
<lp1:version-name>1</lp1:version-name>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
--
Philip
Re: 1.6.8 up for signing / testing
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Wed, Jan 13, 2010 at 8:22 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> On Jan 13, 2010, at 10:52 AM, Philip Martin wrote:
>
>> "Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
>>
>>> After pulling 1.6.7 due to a segfault regression, we've rerolled the
>>> branch as Subversion 1.6.8. The magic revision is r898464, and you
>>> can find the tarballs here:
>>
>> What's the status of serf? I'm seeing lots of failures (46 so far and
>> it is still running) due to non-canonical URLs. Here's one:
>>
You mean ra_serf, not serf. I've triggered a build on the Mac buildbot
with ra_serf to see if it has the same problem, cause it's the first
time I see these errors.
On what platform are you building?
>> FAIL: commit_tests.py 34: tabs in paths
>> CMD: svn copy -m msg http://localhost:22825/svn-test-work/repositories/commit_te
>> sts-34/source_dir "http://localhost:22825/svn-test-work/repositories/commit_test
>> s-34/tab%09dir" --config-dir /home/pm/sw/subversion/obj2/subversion/tests/cmdlin
>> e/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username
>> jrandom lt-svn: ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955: svn
>> _path_url_add_component2: Assertion `svn_path_is_canonical(url, pool)' failed.
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0x7fac6381f750 (LWP 17252)]
>> 0x0000003e68431ed5 in raise () from /lib/libc.so.6
>> (gdb) up
>> #1 0x0000003e684333f3 in abort () from /lib/libc.so.6
>> (gdb)
>> #2 0x0000003e6842adc9 in __assert_fail () from /lib/libc.so.6
>> (gdb)
>> #3 0x00007fac64ecfa92 in svn_path_url_add_component2 (
>> url=0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/",
>> component=0x704bb0 "", pool=0x754eb8)
>> at ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955
>> 955 assert(svn_path_is_canonical(url, pool));
>> (gdb)
>> #4 0x00007fac6551eb49 in get_version_url (checked_in_url=0x754f50,
>> session=0x710bd8, conn=0x717f40, relpath=0x7fac65530b80 "",
>> base_revision=2, parent_vsn_url=0x0, pool=0x754eb8)
>> at ../sign/subversion-1.6.8/subversion/libsvn_ra_serf/commit.c:490
>> 490 propfind_url = svn_path_url_add_component2(bc_url, bc_relpath, pool);
>> (gdb) do
>> #3 0x00007fac64ecfa92 in svn_path_url_add_component2 (
>> url=0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/",
>> component=0x704bb0 "", pool=0x754eb8)
>> at ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955
>> 955 assert(svn_path_is_canonical(url, pool));
>> (gdb) p url
>> $1 = 0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/"
>
> Is the version of serf in the deps tarball different than previous releases?
>
Not at first sight, the .tar.gz has serf 0.3.0 which is still the last
released version.
Lieven
Re: 1.6.8 up for signing / testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Jan 13, 2010, at 10:52 AM, Philip Martin wrote:
> "Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
>
>> After pulling 1.6.7 due to a segfault regression, we've rerolled the
>> branch as Subversion 1.6.8. The magic revision is r898464, and you
>> can find the tarballs here:
>
> What's the status of serf? I'm seeing lots of failures (46 so far and
> it is still running) due to non-canonical URLs. Here's one:
>
> FAIL: commit_tests.py 34: tabs in paths
> CMD: svn copy -m msg http://localhost:22825/svn-test-work/repositories/commit_te
> sts-34/source_dir "http://localhost:22825/svn-test-work/repositories/commit_test
> s-34/tab%09dir" --config-dir /home/pm/sw/subversion/obj2/subversion/tests/cmdlin
> e/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username
> jrandom lt-svn: ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955: svn
> _path_url_add_component2: Assertion `svn_path_is_canonical(url, pool)' failed.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fac6381f750 (LWP 17252)]
> 0x0000003e68431ed5 in raise () from /lib/libc.so.6
> (gdb) up
> #1 0x0000003e684333f3 in abort () from /lib/libc.so.6
> (gdb)
> #2 0x0000003e6842adc9 in __assert_fail () from /lib/libc.so.6
> (gdb)
> #3 0x00007fac64ecfa92 in svn_path_url_add_component2 (
> url=0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/",
> component=0x704bb0 "", pool=0x754eb8)
> at ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955
> 955 assert(svn_path_is_canonical(url, pool));
> (gdb)
> #4 0x00007fac6551eb49 in get_version_url (checked_in_url=0x754f50,
> session=0x710bd8, conn=0x717f40, relpath=0x7fac65530b80 "",
> base_revision=2, parent_vsn_url=0x0, pool=0x754eb8)
> at ../sign/subversion-1.6.8/subversion/libsvn_ra_serf/commit.c:490
> 490 propfind_url = svn_path_url_add_component2(bc_url, bc_relpath, pool);
> (gdb) do
> #3 0x00007fac64ecfa92 in svn_path_url_add_component2 (
> url=0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/",
> component=0x704bb0 "", pool=0x754eb8)
> at ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955
> 955 assert(svn_path_is_canonical(url, pool));
> (gdb) p url
> $1 = 0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/"
Is the version of serf in the deps tarball different than previous releases?
-Hyrum
Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
"Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
> After pulling 1.6.7 due to a segfault regression, we've rerolled the
> branch as Subversion 1.6.8. The magic revision is r898464, and you
> can find the tarballs here:
What's the status of serf? I'm seeing lots of failures (46 so far and
it is still running) due to non-canonical URLs. Here's one:
FAIL: commit_tests.py 34: tabs in paths
CMD: svn copy -m msg http://localhost:22825/svn-test-work/repositories/commit_te
sts-34/source_dir "http://localhost:22825/svn-test-work/repositories/commit_test
s-34/tab%09dir" --config-dir /home/pm/sw/subversion/obj2/subversion/tests/cmdlin
e/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username
jrandom lt-svn: ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955: svn
_path_url_add_component2: Assertion `svn_path_is_canonical(url, pool)' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fac6381f750 (LWP 17252)]
0x0000003e68431ed5 in raise () from /lib/libc.so.6
(gdb) up
#1 0x0000003e684333f3 in abort () from /lib/libc.so.6
(gdb)
#2 0x0000003e6842adc9 in __assert_fail () from /lib/libc.so.6
(gdb)
#3 0x00007fac64ecfa92 in svn_path_url_add_component2 (
url=0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/",
component=0x704bb0 "", pool=0x754eb8)
at ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955
955 assert(svn_path_is_canonical(url, pool));
(gdb)
#4 0x00007fac6551eb49 in get_version_url (checked_in_url=0x754f50,
session=0x710bd8, conn=0x717f40, relpath=0x7fac65530b80 "",
base_revision=2, parent_vsn_url=0x0, pool=0x754eb8)
at ../sign/subversion-1.6.8/subversion/libsvn_ra_serf/commit.c:490
490 propfind_url = svn_path_url_add_component2(bc_url, bc_relpath, pool);
(gdb) do
#3 0x00007fac64ecfa92 in svn_path_url_add_component2 (
url=0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/",
component=0x704bb0 "", pool=0x754eb8)
at ../sign/subversion-1.6.8/subversion/libsvn_subr/path.c:955
955 assert(svn_path_is_canonical(url, pool));
(gdb) p url
$1 = 0x7190a0 "/svn-test-work/repositories/commit_tests-34/!svn/bc/2/"
--
Philip
Re: 1.6.8 up for signing / testing
Posted by Mark Phippard <ma...@gmail.com>.
SUMMARY:
+1 to release
NOTE: I tested with the original 1.6.8 zip but signed and verified the
current one.
PLATFORM:
Windows Vista SP2
VS 2008 SP1
Java 1.6
COMPONENTS:
Apache 2.2.11
APR 1.3.5
APR-UTIL 1.3.7
OpenSSL 0.9.8k
Neon 0.28.3
Serf (from deps)
ZLib (from deps)
SQLite (from deps)
VERIFIED:
md5 and sha1 sums
gpg signature verified
TESTED:
JavaHL
ra_local | ra_svn | ra_neon | ra_serf X fsfs
RESULTS:
All passed
SIGNATURES:
subversion-1.6.8.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEABECAAYFAktOCYoACgkQJl34oANalqmxGgCfbMUaGUaHjtn4JFYPYb7APAqW
m2gAn3Qrm9AItKZO4D9DwPSuSVmAbI28
=cr9U
-----END PGP SIGNATURE-----
subversion-deps-1.6.8.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEABECAAYFAktOCZEACgkQJl34oANalqkaIACgysXDvra3OKHOHz52N3LGEZ6m
kyMAn10JScKV5fqOLrfjeYDx5cmjMCTo
=ISug
-----END PGP SIGNATURE-----
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Jan 15, 2010 at 5:04 AM, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Jan 15, 2010 at 09:49:44AM +0000, Philip Martin wrote:
>> So serf works "out of the box" only for a Windows release build; it
>> fails for a Windows debug build, a Linux build or an OSX build
>> (assuming OSX is like Linux). These other builds need to do something
>> like 'configure CFLAGS=-DNDEBUG' to get serf to work.
>>
>> This is a regression from 1.6.6. Can we get away with mentioning this
>> in the release notes? Do we need 1.6.9?
>
> If ra_neon was broken I'd halt the release. But ra_serf?
> Isn't ra_serf still flagged experimental?
I was about to type, "No, that was only through 1.5.x", but you are
correct. Serf is still considered "experimental" through 1.6.x.
1.6.x was branched in r875962, and serf was made the default DAV
access on trunk shortly after that in r875974.
We've already run into serious serf bugs in 1.6.x that we were willing
to roll with:
http://svn.haxx.se/dev/archive-2009-02/0450.shtml
(Though in this case the fix actually did make it into 1.6.0:
http://svn.apache.org/viewvc?view=revision&revision=876271)
So I don't see how this should be any different?
Paul
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Jan 14, 2010 at 5:15 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> Not to sound like I am testifying before Congress...but I don't recall
>> that. More importantly, as Mark mentioned, Senthil successfully ran
>> the serf tests on Debian.
>
> Could someone with 1.6.8 working on Windows try the following using
> serf:
>
> svnadmin create repo
> svn mkdir -mm http://localhost/repo/A
> svn cp -mm http://localhost/repo/A http://localhost/repo/B
> svn ls http://localhost/repo
>
> On my Linux machine the cp asserts so the ls won't show B.
>
> --
> Philip
Hi Philip,
No surprise I suppose (since the tests passed for me) but this works for me:
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>svn
--version -q
1.6.8
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>copy
C:\SVN\src-branch-1.6.x\Release\subversion\mod_dav_svn\mod_dav_svn.so
"
C:\Apache22"\modules
1 file(s) copied.
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>copy
C:\SVN\src-branch-1.6.x\Release\subversion\mod_authz_svn\mod_authz_svn.
so "C:\Apache22"\modules
1 file(s) copied.
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>echo
[global] > servers
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>echo
http-library = serf >> servers
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>svnadmin
create repo
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>svn
mkdir -mm http://localhost/svn-test-work/repositories/repo/A
--config-di
r=. --username=jrandom --password=rayjandom
Committed revision 1.
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>svn
cp -mc http://localhost/svn-test-work/repositories/repo/A
http://localho
st/svn-test-work/repositories/repo/B --config-dir=. --username=jrandom
--password=rayjandom
Committed revision 2.
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>svn
ls http://localhost/svn-test-work/repositories/repo
A/
B/
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> Not to sound like I am testifying before Congress...but I don't recall
> that. More importantly, as Mark mentioned, Senthil successfully ran
> the serf tests on Debian.
Could someone with 1.6.8 working on Windows try the following using
serf:
svnadmin create repo
svn mkdir -mm http://localhost/repo/A
svn cp -mm http://localhost/repo/A http://localhost/repo/B
svn ls http://localhost/repo
On my Linux machine the cp asserts so the ls won't show B.
--
Philip
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Jan 14, 2010 at 3:18 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Thu, Jan 14, 2010 at 8:08 PM, Mark Phippard <ma...@gmail.com> wrote:
>> On Thu, Jan 14, 2010 at 12:01 PM, Philip Martin
>> <ph...@wandisco.com> wrote:
>>> Paul Burba <pt...@gmail.com> writes:
>>>
>>>> TESTED:
>>>> -------
>>>> [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
>>>
>>> You're the second person to show the serf tests passing on Windows.
>>> Are you testing against the 1.6.8 server? On Linux the server sends a
>>> non-canonical URL that causes the client to abort. Is the server
>>> doing something different on Windows?
>>
>> Actually, all three of us that signed for Windows tested Serf with no
>> errors. I used 1.6.8 mod_dav_svn for this.
>>
> I recall some issues that Paul reported that assertions during tests
> are ignored on Windows.
Not to sound like I am testifying before Congress...but I don't recall
that. More importantly, as Mark mentioned, Senthil successfully ran
the serf tests on Debian.
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Jan 14, 2010 at 8:08 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Jan 14, 2010 at 12:01 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> TESTED:
>>> -------
>>> [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
>>
>> You're the second person to show the serf tests passing on Windows.
>> Are you testing against the 1.6.8 server? On Linux the server sends a
>> non-canonical URL that causes the client to abort. Is the server
>> doing something different on Windows?
>
> Actually, all three of us that signed for Windows tested Serf with no
> errors. I used 1.6.8 mod_dav_svn for this.
>
I recall some issues that Paul reported that assertions during tests
are ignored on Windows.
--
Ivan Zhakov
VisualSVN Team
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Senthil Kumaran S <se...@collab.net>.
Mark Phippard wrote:
> On Thu, Jan 14, 2010 at 12:01 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> TESTED:
>>> -------
>>> [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
>> You're the second person to show the serf tests passing on Windows.
>> Are you testing against the 1.6.8 server? On Linux the server sends a
>> non-canonical URL that causes the client to abort. Is the server
>> doing something different on Windows?
>
> Actually, all three of us that signed for Windows tested Serf with no
> errors. I used 1.6.8 mod_dav_svn for this.
>
> We also had at least one Unix signature for 1.6.7 which tested Serf:
>
> http://svn.haxx.se/dev/archive-2009-12/0500.shtml
This time my testing with 1.6.8 tar balls is not successful, after repeated
attempts with various combinations of dependencies. These are the failures I
see in fsfs/serf and bdb/serf,
<snip>
FAIL: checkout_tests.py 13: co handles obstructing paths scheduled for add
FAIL: commit_tests.py 34: tabs in paths
FAIL: commit_tests.py 43: set revision props during repos-to-repos copy
FAIL: commit_tests.py 45: set revision props during repos-to-repos move
FAIL: commit_tests.py 46: set revision props during remote property edit
FAIL: update_tests.py 13: bail when receive a file or dir named .svn
FAIL: update_tests.py 34: update handles obstructing paths scheduled for add
FAIL: update_tests.py 36: mergeinfo does not elide after update
FAIL: switch_tests.py 9: switch that deletes a sub-directory
FAIL: switch_tests.py 11: non-recursive switch
FAIL: switch_tests.py 14: obstructed switch
FAIL: switch_tests.py 17: refresh the WC file system read-only attribute
FAIL: switch_tests.py 19: out of date propset should fail after a relocate
FAIL: switch_tests.py 23: mergeinfo does not elide post switch
FAIL: switch_tests.py 30: tolerate deletion of a directory with local mods
FAIL: prop_tests.py 16: property operations on an URL
FAIL: log_tests.py 9: 'svn log TGT' with copyfrom history
FAIL: log_tests.py 16: test 'svn log -g' on a single revision
FAIL: log_tests.py 17: test 'svn log -g' on a branching revision
FAIL: log_tests.py 18: test 'svn log -g' on a non-branching revision
FAIL: log_tests.py 19: test 'svn log -g' a path added before merge
FAIL: log_tests.py 27: log -g and explicit mergeinfo replacing inherited
FAIL: log_tests.py 28: log -g and simple propmod to merge-inheriting path
FAIL: copy_tests.py 3: resurrect a deleted directory
FAIL: copy_tests.py 4: svn cp URL URL cannot overwrite destination
FAIL: copy_tests.py 13: copy item to root of repository
FAIL: copy_tests.py 14: copy URL URL/subdir
FAIL: copy_tests.py 22: check for double URI escaping in svn ls -R
FAIL: copy_tests.py 25: svn cp src-URL non-existent-URL-path
FAIL: copy_tests.py 26: svn cp oldrev-of-deleted-URL URL
FAIL: copy_tests.py 27: test URL to URL copying edge case
FAIL: copy_tests.py 37: copy a deleted dir to a prefix of its old path
FAIL: copy_tests.py 56: move multiple files within a repo
FAIL: copy_tests.py 57: copy multiple files within a repo
FAIL: copy_tests.py 58: copy multiple files from a repo to a wc
FAIL: copy_tests.py 62: copy urls using peg rev syntax
FAIL: copy_tests.py 67: svn cp --parents URL URL
FAIL: copy_tests.py 71: svn cp --parents FILE_URL DIR_URL
FAIL: copy_tests.py 72: svn cp --parents URL/src_dir URL/dst_dir
FAIL: copy_tests.py 76: issue #2475 - direct copy in the repository
FAIL: diff_tests.py 17: diff for branches
FAIL: diff_tests.py 18: diff between repos URLs and WC paths
FAIL: diff_tests.py 19: diff between two file URLs (issue #1311)
FAIL: diff_tests.py 21: check for omitted prefix in path component
FAIL: diff_tests.py 33: nonrecursive diff + deleted directories
FAIL: diff_tests.py 41: diff a revision of a file in a renamed folder
FAIL: merge_tests.py 4: some simple property merges
FAIL: merge_tests.py 8: merge should not die if a target file is absent
FAIL: merge_tests.py 9: merge on deleted directory in target
FAIL: merge_tests.py 13: 3-way merge of 'file add' into existing binary
FAIL: merge_tests.py 18: diff after merge that creates a new file
FAIL: merge_tests.py 26: merge a file whose name contains a space
FAIL: merge_tests.py 28: property merges don't overwrite existing prop-mods
FAIL: merge_tests.py 29: property merge conflict even without local mods
FAIL: merge_tests.py 31: cherry-pick a dependent change, get conflict
FAIL: merge_tests.py 36: merge an added dir on a deleted dir in target
FAIL: merge_tests.py 42: use inherited mergeinfo to avoid repeated merge
FAIL: merge_tests.py 43: use subtree's mergeinfo to avoid repeated merge
FAIL: merge_tests.py 45: target inherits mergeinfo from nearest ancestor
FAIL: merge_tests.py 46: mergeinfo elides to ancestor with identical info
FAIL: merge_tests.py 47: discontinuous merges produce correct mergeinfo
FAIL: merge_tests.py 48: merge works when target has copied children
FAIL: merge_tests.py 49: merge to switched path does not inherit or elide
FAIL: merge_tests.py 50: merge to path with switched children
FAIL: merge_tests.py 59: merge to ood path can lead to inaccurate mergeinfo
FAIL: merge_tests.py 60: merge test for --depth files
FAIL: merge_tests.py 61: merge fails if subtree is deleted on src
FAIL: merge_tests.py 62: subtrees can lose non-inheritable ranges
FAIL: merge_tests.py 64: merge -rold(before rename):head renamed dir
FAIL: merge_tests.py 65: child having different rev ranges to merge
FAIL: merge_tests.py 66: merge -rold(before rename):head renamed file
FAIL: merge_tests.py 67: merge with auto detection of revision ranges
FAIL: merge_tests.py 75: merge from renamed branch
FAIL: merge_tests.py 76: normalized mergeinfo is recorded on subtrees
FAIL: merge_tests.py 77: subtrees added after start of merge range are ok
FAIL: merge_tests.py 78: basic merge --reintegrate support
FAIL: merge_tests.py 79: merge --reintegrate with renamed file on branch
FAIL: merge_tests.py 80: merge --reintegrate on a never-updated branch
FAIL: merge_tests.py 86: cyclic merges don't add mergeinfo from own history
FAIL: merge_tests.py 87: merge range predates history (issue #3094)
FAIL: merge_tests.py 90: 2-url merge from a foreign repository
FAIL: merge_tests.py 93: merges that remove all mergeinfo work
FAIL: merge_tests.py 94: dont merge revs into a subtree that predate it
FAIL: merge_tests.py 95: merge fails with renamed subtrees with mergeinfo
FAIL: merge_tests.py 96: don't explicitly record implicit mergeinfo
FAIL: merge_tests.py 98: subtree ranges might not intersect with target
FAIL: merge_tests.py 99: subtree merge source might not exist
FAIL: merge_tests.py 100: mergeinfo not set on subtree with empty mergeinfo
FAIL: merge_tests.py 101: commits to subtrees added by merge wreak havoc
FAIL: merge_tests.py 105: subtree merges dont cause spurious conflicts
FAIL: merge_tests.py 106: target and subtrees need nonintersecting revs
FAIL: merge_tests.py 107: merge two successive edits to the same property
FAIL: merge_tests.py 108: merge an EOL unification and set svn:eol-style
FAIL: merge_tests.py 109: merge adds mergeinfo to subtrees correctly
FAIL: merge_tests.py 111: natural history filtering permits valid mergeinfo
FAIL: merge_tests.py 112: tree conflicts and obstructions
FAIL: merge_tests.py 113: tree conflicts 4.1: tree del, leaf edit
FAIL: merge_tests.py 114: tree conflicts 4.2: tree del, leaf del
FAIL: merge_tests.py 117: tree conflicts 6: tree del, tree del
FAIL: merge_tests.py 118: tree conflicts 4.1: tree del (no ci), leaf edit
FAIL: merge_tests.py 119: tree conflicts 4.2: tree del (no ci), leaf del
FAIL: merge_tests.py 122: tree conflicts 6: tree del (no ci), tree del
FAIL: merge_tests.py 123: subtree gets changes even if ultimately deleted
FAIL: merge_tests.py 124: no self referential filtering on added path
FAIL: merge_tests.py 126: merge --reintegrate with subtree mergeinfo
FAIL: merge_tests.py 127: mergeinfo aware merges ignore natural history gaps
FAIL: merge_tests.py 128: mergeinfo deleted by a merge should disappear
FAIL: merge_tests.py 129: tree conflicts: tree missing, leaf edit
FAIL: merge_tests.py 130: tree conflicts: tree missing, leaf del
FAIL: merge_tests.py 131: noop file merge does not segfault
FAIL: merge_tests.py 132: multiple reintegrates create self-referential
FAIL: mergeinfo_tests.py 6: non-inheritable mergeinfo shows as merged
FAIL: blame_tests.py 10: test 'svn blame -g'
FAIL: blame_tests.py 11: don't look for merged files out of range
FAIL: blame_tests.py 14: blame -g output with inserted lines
FAIL: special_tests.py 7: merge symlink into file
FAIL: special_tests.py 8: merge file into symlink
FAIL: svnlook_tests.py 7: history --limit
FAIL: lock_tests.py 27: commit file with xml-unsafe name and release lock
FAIL: svnsync_tests.py 15: verify that copies from unreadable dirs work
FAIL: authz_tests.py 4: test authz for read operations
FAIL: authz_tests.py 5: test authz for write operations
FAIL: authz_tests.py 10: test authz for aliases
FAIL: tree_conflict_tests.py 1: up/sw file: modify onto del/rpl/mv
FAIL: tree_conflict_tests.py 2: up/sw file: del/rpl/mv onto modify
FAIL: tree_conflict_tests.py 3: up/sw file: del/rpl/mv onto del/rpl/mv
FAIL: tree_conflict_tests.py 4: up/sw file: add onto add
FAIL: tree_conflict_tests.py 5: up/sw dir: modify onto del/rpl/mv
FAIL: tree_conflict_tests.py 6: up/sw dir: del/rpl/mv onto modify
FAIL: tree_conflict_tests.py 7: up/sw dir: del/rpl/mv onto del/rpl/mv
FAIL: tree_conflict_tests.py 9: merge file: modify onto not-file
FAIL: tree_conflict_tests.py 10: merge file: del/rpl/mv onto not-same
FAIL: tree_conflict_tests.py 11: merge file: del/rpl/mv onto not-file
FAIL: tree_conflict_tests.py 12: merge file: add onto not-none
FAIL: tree_conflict_tests.py 13: merge dir: modify onto not-dir
FAIL: tree_conflict_tests.py 15: merge dir: del/rpl/mv onto not-dir
FAIL: tree_conflict_tests.py 16: merge dir: add onto not-none
FAIL: resolved_tests.py 2: resolved on deleted item
</snip>
I first noticed this in Debian amd64 testing box where I started initially and
then now even in i386 box.
Thank You.
--
Senthil Kumaran S
http://www.stylesen.org/
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 15, 2010 at 09:49:44AM +0000, Philip Martin wrote:
> So serf works "out of the box" only for a Windows release build; it
> fails for a Windows debug build, a Linux build or an OSX build
> (assuming OSX is like Linux). These other builds need to do something
> like 'configure CFLAGS=-DNDEBUG' to get serf to work.
>
> This is a regression from 1.6.6. Can we get away with mentioning this
> in the release notes? Do we need 1.6.9?
If ra_neon was broken I'd halt the release. But ra_serf?
Isn't ra_serf still flagged experimental?
I guess people who are not running 1.6.x with neon do reckon
with breakage so mentioning it in the release notes should be fine.
Stefan
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Thu, Jan 14, 2010 at 8:29 PM, Philip Martin
<ph...@wandisco.com> wrote:
>
> I don't understand. it. The server generates baseline collection URLs
> with a trailing slash (a DeltaV requirement?) in dav_svn__build_uri:
>
> case DAV_SVN__BUILD_URI_BC:
> return apr_psprintf(pool, "%s%s/%s/bc/%ld/%s",
> href1, root_path, special_uri, revision, href2);
>
> and I see the trailing slashes on wire. The trunk client has a call
> to svn_uri_canonicalize that is not present on the branch, so the
> branch aborts. If I add a svn_path_canonicalize call the problem is
> fixed. How do some machines avoid the problem?
The Mac buildbot fails a whole lot of tests on the 1.6.x branch too,
so you're not the only one seeing this problem.
Lieven
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Senthil Kumaran S <se...@collab.net>.
Philip Martin wrote:
> Building -DNDEBUG makes the tests pass on Linux.
Yes I confirm this. When I configure with 'CFLAGS=-DNDEBUG' option, there is no
failures, here are the dependencies,
APR 1.3.9
APR-UTIL 1.3.9
Apache httpd 2.2.14
Neon 0.29.3
Serf 0.3.0
BDB 4.7.25
OpenSSL 0.9.8g
OpenJDK 1.6.0_0
SQLite 3.6.19
JUnit 3.8.2
--
Senthil Kumaran S
http://www.stylesen.org/
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> I just performed a
> $ svn diff -x -p ^/subversion/tags/1.6.6 ^/subversion/tags/1.6.8 > 1.6.6-1.6.8.patch
>
> And I see no changes in serf at all.
You've made a mistake somehow:
r889935 | hwright | 2009-12-12 14:38:38 +0000 (Sat, 12 Dec 2009) | 15 lines
Reintegrate the 1.6.x-issue3519 branch:
introduced the code that crashes.
> If I remember correctly NDEBUG is also the default on the posix
> targets, except when you enable maintainer mode?
I don't think there is an such rule in general but I suppose a given
package might have its own rule. For Subversion on Linux (and I think
OSX) one needs to specify it explicitly:
./configure CFLAGS=-DNDEBUG
or
make EXTRA_CFLAGS=-DNDEBUG
--
Philip
RE: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: vrijdag 15 januari 2010 10:50
> To: Paul Burba
> Cc: Bert Huijben; Mark Phippard; Hyrum K. Wright; Joe Swatosh; Subversion
> Dev
> Subject: Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
>
> Paul Burba <pt...@gmail.com> writes:
>
> >> The check is inside an assert(), so it only aborts in maintainer/DEBUG
> mode.
> >>
> >> Bert
> >
> > Doh, Thanks Bert. I wasn't paying close enough attention. Indeed it
> > does assert with a debug build:
> >
> > C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-
> work\repositories>svn
> > cp -mc http://localhost/svn-test-work/repositories/repo/A
> > http://localhost/svn-test-work/repositories/repo/A2 --config-dir=.
> > --username=jrandom --password=rayjandom
> > Assertion failed: svn_path_is_canonical(url, pool), file
> > ..\..\..\subversion\libsvn_subr\path.c, line 955
>
> Building -DNDEBUG makes the tests pass on Linux.
>
> So serf works "out of the box" only for a Windows release build; it
> fails for a Windows debug build, a Linux build or an OSX build
> (assuming OSX is like Linux). These other builds need to do something
> like 'configure CFLAGS=-DNDEBUG' to get serf to work.
>
> This is a regression from 1.6.6. Can we get away with mentioning this
> in the release notes? Do we need 1.6.9?
Are you sure there is a regression since 1.6.6 here?
I just performed a
$ svn diff -x -p ^/subversion/tags/1.6.6 ^/subversion/tags/1.6.8 > 1.6.6-1.6.8.patch
And I see no changes in serf at all.
If I remember correctly NDEBUG is also the default on the posix targets, except when you enable maintainer mode?
Bert
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
>> The check is inside an assert(), so it only aborts in maintainer/DEBUG mode.
>>
>> Bert
>
> Doh, Thanks Bert. I wasn't paying close enough attention. Indeed it
> does assert with a debug build:
>
> C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>svn
> cp -mc http://localhost/svn-test-work/repositories/repo/A
> http://localhost/svn-test-work/repositories/repo/A2 --config-dir=.
> --username=jrandom --password=rayjandom
> Assertion failed: svn_path_is_canonical(url, pool), file
> ..\..\..\subversion\libsvn_subr\path.c, line 955
Building -DNDEBUG makes the tests pass on Linux.
So serf works "out of the box" only for a Windows release build; it
fails for a Windows debug build, a Linux build or an OSX build
(assuming OSX is like Linux). These other builds need to do something
like 'configure CFLAGS=-DNDEBUG' to get serf to work.
This is a regression from 1.6.6. Can we get away with mentioning this
in the release notes? Do we need 1.6.9?
--
Philip
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Jan 14, 2010 at 7:52 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin@wandisco.com]
>> Sent: donderdag 14 januari 2010 20:29
>> To: Mark Phippard
>> Cc: Paul Burba; Hyrum K. Wright; Bert Huijben; Joe Swatosh; Subversion
>> Dev
>> Subject: Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
>>
>
>> I don't understand. it. The server generates baseline collection URLs
>> with a trailing slash (a DeltaV requirement?) in dav_svn__build_uri:
>>
>> case DAV_SVN__BUILD_URI_BC:
>> return apr_psprintf(pool, "%s%s/%s/bc/%ld/%s",
>> href1, root_path, special_uri, revision,
>> href2);
>>
>> and I see the trailing slashes on wire. The trunk client has a call
>> to svn_uri_canonicalize that is not present on the branch, so the
>> branch aborts. If I add a svn_path_canonicalize call the problem is
>> fixed. How do some machines avoid the problem?
>
> The check is inside an assert(), so it only aborts in maintainer/DEBUG mode.
>
> Bert
Doh, Thanks Bert. I wasn't paying close enough attention. Indeed it
does assert with a debug build:
C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline\svn-test-work\repositories>svn
cp -mc http://localhost/svn-test-work/repositories/repo/A
http://localhost/svn-test-work/repositories/repo/A2 --config-dir=.
--username=jrandom --password=rayjandom
Assertion failed: svn_path_is_canonical(url, pool), file
..\..\..\subversion\libsvn_subr\path.c, line 955
Paul
RE: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: donderdag 14 januari 2010 20:29
> To: Mark Phippard
> Cc: Paul Burba; Hyrum K. Wright; Bert Huijben; Joe Swatosh; Subversion
> Dev
> Subject: Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
>
> I don't understand. it. The server generates baseline collection URLs
> with a trailing slash (a DeltaV requirement?) in dav_svn__build_uri:
>
> case DAV_SVN__BUILD_URI_BC:
> return apr_psprintf(pool, "%s%s/%s/bc/%ld/%s",
> href1, root_path, special_uri, revision,
> href2);
>
> and I see the trailing slashes on wire. The trunk client has a call
> to svn_uri_canonicalize that is not present on the branch, so the
> branch aborts. If I add a svn_path_canonicalize call the problem is
> fixed. How do some machines avoid the problem?
The check is inside an assert(), so it only aborts in maintainer/DEBUG mode.
Bert
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> On Thu, Jan 14, 2010 at 12:01 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> TESTED:
>>> -------
>>> [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
>>
>> You're the second person to show the serf tests passing on Windows.
>> Are you testing against the 1.6.8 server? On Linux the server sends a
>> non-canonical URL that causes the client to abort. Is the server
>> doing something different on Windows?
>
> Actually, all three of us that signed for Windows tested Serf with no
> errors. I used 1.6.8 mod_dav_svn for this.
>
> We also had at least one Unix signature for 1.6.7 which tested Serf:
>
> http://svn.haxx.se/dev/archive-2009-12/0500.shtml
I don't understand. it. The server generates baseline collection URLs
with a trailing slash (a DeltaV requirement?) in dav_svn__build_uri:
case DAV_SVN__BUILD_URI_BC:
return apr_psprintf(pool, "%s%s/%s/bc/%ld/%s",
href1, root_path, special_uri, revision, href2);
and I see the trailing slashes on wire. The trunk client has a call
to svn_uri_canonicalize that is not present on the branch, so the
branch aborts. If I add a svn_path_canonicalize call the problem is
fixed. How do some machines avoid the problem?
--
Philip
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jan 14, 2010 at 12:01 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> TESTED:
>> -------
>> [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
>
> You're the second person to show the serf tests passing on Windows.
> Are you testing against the 1.6.8 server? On Linux the server sends a
> non-canonical URL that causes the client to abort. Is the server
> doing something different on Windows?
Actually, all three of us that signed for Windows tested Serf with no
errors. I used 1.6.8 mod_dav_svn for this.
We also had at least one Unix signature for 1.6.7 which tested Serf:
http://svn.haxx.se/dev/archive-2009-12/0500.shtml
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Jan 14, 2010 at 12:01 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> TESTED:
>> -------
>> [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
>
> You're the second person to show the serf tests passing on Windows.
> Are you testing against the 1.6.8 server? On Linux the server sends a
> non-canonical URL that causes the client to abort. Is the server
> doing something different on Windows?
Hi Philip,
Yes, I am using 1.6.8 on the server. I just double checked what's in
my Apache22/modules, and it is definitely the 1.6.8 mod_dav_svn and
mod_authz_svn.
Paul
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> TESTED:
> -------
> [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
You're the second person to show the serf tests passing on Windows.
Are you testing against the 1.6.8 server? On Linux the server sends a
non-canonical URL that causes the client to abort. Is the server
doing something different on Windows?
--
Philip
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Jan 13, 2010 at 11:19 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> Given this feedback, and the fact that it's a patch release with supposed minimal changes between releases, I agree we should step back to Neon 0.28.3. I've rerolled the tarballs and replaced them at the download site with the new deps tarballs.
>
> Note: All the tarballs have been recreated, as have the signatures. You'll need to sign the new 1.6.8 tarballs, not the old ones.
>
> This is turning into quite the star-crossed release. Thanks for the patience.
>
> -Hyrum
VERIFIED:
---------
Other than the expected differences in svn_version.h and www/HACKING,
http://orac.ece.utexas.edu/pub/svn/1.6.8/zimolijax/subversion-1.6.8.zip
is identical to
https://svn.apache.org/repos/asf/subversion/branches/1.6.x@898464.
http://orac.ece.utexas.edu/pub/svn/1.6.8/zimolijax/subversion-1.6.8.zip:
MD5: CD097A4493549D35210714B73D49E308
SHA1: 997BCE9CD6D6759CA1A90101AFDA7F80CB764A2F
C:\Downloads\1.6.8>gpg --verify subversion-1.6.8.zip.asc
gpg: Signature made 01/13/10 11:16:00 using DSA key ID 4E24517C
gpg: Good signature from "Hyrum K. Wright (Personal) <hy...@hyrumwright.org>"
gpg: aka "Hyrum K. Wright (UT) <hy...@mail.utexas.edu>"
SUCCESSFULLY BUILT BUT NOT TESTED:
----------------------------------
Python Bindings
Perl Bindings
TESTED:
-------
[ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
JavaHL Bindings
Ruby Bindings
RESULTS:
--------
All tests pass.
SUMMARY:
--------
+1 to release.
PLATFORM:
---------
Microsoft Windows XP Professional Version 2002 Service Pack 3 (Build 2600)
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ 2211.2 Mhz 3 GB RAM
Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM
DEPENDENCIES:
-------------
APR: 1.3.5
APR-UTIL: 1.3.7
Neon: 0.28.2
zlib: 1.2.3
OpenSSL: 0.9.8i
Apache: 2.2.10
BDB: 4.7.25
sqlite: 3.6.15
Python: ActivePython 2.6.2.2
Perl: 5.10.0
Ruby: ruby 1.8.7 (2009-12-24 patchlevel 248) [i386-mswin32_90]
java: 1.6.0_14
junit: 4.6
swig: 1.3.36
serf: 0.3.0
SIGNATURE:
-----------
user: "Paul T. Burba <pt...@gmail.com>"
1024-bit DSA key, ID 53FCDC55, created 2006-06-21
http://orac.ece.utexas.edu/pub/svn/1.6.8/zimolijax/subversion-1.6.8.zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
iD8DBQBLTyay2RaJMFP83FURAqrxAJ9YcbPTHJVTCwMhqCnL2dPPHayqZQCfeq6u
QoWEnCz/8kScktl0e2Cqfdk=
=AuWM
-----END PGP SIGNATURE-----
RE: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Bert Huijben <be...@qqmail.nl>.
+1 for release.
Tested [fsfs | bdb] x [ local | svn | serf | neon ]
Windows 7 X64
Visual Studio 2008 SP1
(Compiling everything as X86 application)
APR 1.3.8
APR-Util 1.3.9
BDB 4.4.20
Serf 0.3.0
Cyrus Sasl 2.1.23
SqLite 3.6.22
Neon 0.29.3
Apache httpd 2.2.9
(With IPv6 enabled in APR and Neon)
No test failures.
== subversion-1.6.8.tar.bz2.asc ==
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEABECAAYFAktPC/0ACgkQ/P1jBZgh97KnEwCgkgI44iNt11E1dHoFKr/UWTPQ
wmMAn15TUP8189YMrYMyRgKXz5TyAcMr
=Kkgn
-----END PGP SIGNATURE-----
== subversion-1.6.8.tar.gz.asc ==
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEABECAAYFAktPDAAACgkQ/P1jBZgh97ITugCeMged3NNv4C10cUMStfeYOuf4
zBcAn1PLYa+DpjjjvJJ7RcX+nbnA2NzF
=bpK/
-----END PGP SIGNATURE-----
== subversion-1.6.8.zip.asc ==
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEABECAAYFAktPDAQACgkQ/P1jBZgh97LvywCgykVWOIR5BeOOOxO7c6t7Jajy
ch4AoMe+Ruj7C83Dyf/kknOaCpk7EkjQ
=9PGy
-----END PGP SIGNATURE-----
== svn_version.h.dist.asc ==
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEABECAAYFAktPDAcACgkQ/P1jBZgh97LyIACguX6SonSfwFCVpc2HHnGYL6DT
ieMAn3TyrHVxfa/s/FFvUNvAF15IjbC+
=82wc
-----END PGP SIGNATURE-----
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Joe Swatosh <jo...@gmail.com>.
On Wed, Jan 13, 2010 at 8:19 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> On Jan 13, 2010, at 10:10 AM, Bert Huijben wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Mark Phippard [mailto:markphip@gmail.com]
>>> Sent: woensdag 13 januari 2010 15:53
>>> To: Hyrum K. Wright
>>> Cc: Joe Swatosh; Subversion Dev
>>> Subject: Re: 1.6.8 up for signing / testing
>>>
>>> I think the problem is with Neon. We get this error:
>>>
>>> Linking...
>>> Creating library
>>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.lib and object
>>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.exp
>>> libneon.lib(ne_socket.obj) : error LNK2019: unresolved external symbol
>>> _inet_aton referenced in function _ne_iaddr_parse
>>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
>>> LNK1120: 1 unresolved externals
>>>
>>> You are including 0.29.0 When I step it back to 0.28.3 it works.
>>
>> Not really about this issue as I can't reproduce that here, but:
>>
>> Neon versions 0.29.0-0.29.2 have a regression in connecting to several https
>> servers. On sites that run a proxy or a non-apache subversion host (E.g.
>> codeplex) you can see timeouts on connection close time.
>>
>> I would recommend sticking with 0.28.x or using 0.29.3 (Released last
>> Monday) for binary releases.
>
> Given this feedback, and the fact that it's a patch release with supposed minimal changes between releases, I agree we should step back to Neon 0.28.3. I've rerolled the tarballs and replaced them at the download site with the new deps tarballs.
>
> Note: All the tarballs have been recreated, as have the signatures. You'll need to sign the new 1.6.8 tarballs, not the old ones.
>
> This is turning into quite the star-crossed release. Thanks for the patience.
>
The deps .zip and .bz2 and .gz seem to still have neon 0.29.0....
--
Joe
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Branko Čibej <br...@xbc.nu>.
Hyrum K. Wright wrote:
> On Jan 14, 2010, at 6:33 AM, Mark Phippard wrote:
>
>
>> On Wed, Jan 13, 2010 at 11:19 AM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>
>>
>>> Given this feedback, and the fact that it's a patch release with supposed minimal changes between releases, I agree we should
>>> step back to Neon 0.28.3. I've rerolled the tarballs and replaced them at the download site with the new deps tarballs.
>>>
>> I just read this more closely and fear I have led you astray. I only
>> used Neon 0.28.3 because that happened to be the version I had sitting
>> in an old working copy (I had just deleted all of the old deps zip
>> files before starting the tests). However, there have been security
>> fixes in Neon since that release, so we should include the latest
>> version - 0.28.7 (or 0.29.3). I suspect that is the version we would
>> have included with 1.6.6, but maybe not.
>>
>
> Turns out I updated the script, but didn't bother to re-run it. Gah.
>
>
>> Can't we just copy/rename the 1.6.6 deps tarballs?
>>
>
> I don't see a problem with this. We can even borrow the signatures from those files, yes?
>
>
>> Are we (thankfully in my opinion) going to drop the deps tarballs when
>> we start releasing at ASF?
>>
>
> I don't know the party line on this, but I certainly hope it is the case.
>
We certainly can't release a deps tarball with Neon in it as an ASF
release. GPL misRules.
-- Brane
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Jan 14, 2010, at 6:33 AM, Mark Phippard wrote:
> On Wed, Jan 13, 2010 at 11:19 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>
>> Given this feedback, and the fact that it's a patch release with supposed minimal changes between releases, I agree we should
>> step back to Neon 0.28.3. I've rerolled the tarballs and replaced them at the download site with the new deps tarballs.
>
> I just read this more closely and fear I have led you astray. I only
> used Neon 0.28.3 because that happened to be the version I had sitting
> in an old working copy (I had just deleted all of the old deps zip
> files before starting the tests). However, there have been security
> fixes in Neon since that release, so we should include the latest
> version - 0.28.7 (or 0.29.3). I suspect that is the version we would
> have included with 1.6.6, but maybe not.
Turns out I updated the script, but didn't bother to re-run it. Gah.
> Can't we just copy/rename the 1.6.6 deps tarballs?
I don't see a problem with this. We can even borrow the signatures from those files, yes?
> Are we (thankfully in my opinion) going to drop the deps tarballs when
> we start releasing at ASF?
I don't know the party line on this, but I certainly hope it is the case.
-Hyrum
Re: [NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jan 13, 2010 at 11:19 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Given this feedback, and the fact that it's a patch release with supposed minimal changes between releases, I agree we should
> step back to Neon 0.28.3. I've rerolled the tarballs and replaced them at the download site with the new deps tarballs.
I just read this more closely and fear I have led you astray. I only
used Neon 0.28.3 because that happened to be the version I had sitting
in an old working copy (I had just deleted all of the old deps zip
files before starting the tests). However, there have been security
fixes in Neon since that release, so we should include the latest
version - 0.28.7 (or 0.29.3). I suspect that is the version we would
have included with 1.6.6, but maybe not.
Can't we just copy/rename the 1.6.6 deps tarballs?
Are we (thankfully in my opinion) going to drop the deps tarballs when
we start releasing at ASF?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
[NEW TARBALLS] Re: 1.6.8 up for signing / testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Jan 13, 2010, at 10:10 AM, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Mark Phippard [mailto:markphip@gmail.com]
>> Sent: woensdag 13 januari 2010 15:53
>> To: Hyrum K. Wright
>> Cc: Joe Swatosh; Subversion Dev
>> Subject: Re: 1.6.8 up for signing / testing
>>
>> I think the problem is with Neon. We get this error:
>>
>> Linking...
>> Creating library
>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.lib and object
>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.exp
>> libneon.lib(ne_socket.obj) : error LNK2019: unresolved external symbol
>> _inet_aton referenced in function _ne_iaddr_parse
>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
>> LNK1120: 1 unresolved externals
>>
>> You are including 0.29.0 When I step it back to 0.28.3 it works.
>
> Not really about this issue as I can't reproduce that here, but:
>
> Neon versions 0.29.0-0.29.2 have a regression in connecting to several https
> servers. On sites that run a proxy or a non-apache subversion host (E.g.
> codeplex) you can see timeouts on connection close time.
>
> I would recommend sticking with 0.28.x or using 0.29.3 (Released last
> Monday) for binary releases.
Given this feedback, and the fact that it's a patch release with supposed minimal changes between releases, I agree we should step back to Neon 0.28.3. I've rerolled the tarballs and replaced them at the download site with the new deps tarballs.
Note: All the tarballs have been recreated, as have the signatures. You'll need to sign the new 1.6.8 tarballs, not the old ones.
This is turning into quite the star-crossed release. Thanks for the patience.
-Hyrum
RE: 1.6.8 up for signing / testing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Mark Phippard [mailto:markphip@gmail.com]
> Sent: woensdag 13 januari 2010 15:53
> To: Hyrum K. Wright
> Cc: Joe Swatosh; Subversion Dev
> Subject: Re: 1.6.8 up for signing / testing
>
> I think the problem is with Neon. We get this error:
>
> Linking...
> Creating library
> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.lib and object
> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.exp
> libneon.lib(ne_socket.obj) : error LNK2019: unresolved external symbol
> _inet_aton referenced in function _ne_iaddr_parse
> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
> LNK1120: 1 unresolved externals
>
> You are including 0.29.0 When I step it back to 0.28.3 it works.
Not really about this issue as I can't reproduce that here, but:
Neon versions 0.29.0-0.29.2 have a regression in connecting to several https
servers. On sites that run a proxy or a non-apache subversion host (E.g.
codeplex) you can see timeouts on connection close time.
I would recommend sticking with 0.28.x or using 0.29.3 (Released last
Monday) for binary releases.
Bert
Re: 1.6.8 up for signing / testing
Posted by Joe Swatosh <jo...@gmail.com>.
Looks like Mark is correct.
--
Joe
On Wed, Jan 13, 2010 at 6:52 AM, Mark Phippard <ma...@gmail.com> wrote:
> I think the problem is with Neon. We get this error:
>
> Linking...
> Creating library
> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.lib and object
> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.exp
> libneon.lib(ne_socket.obj) : error LNK2019: unresolved external symbol
> _inet_aton referenced in function _ne_iaddr_parse
> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
> LNK1120: 1 unresolved externals
>
> You are including 0.29.0 When I step it back to 0.28.3 it works.
>
>
>
> On Wed, Jan 13, 2010 at 9:28 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> Joe,
>> Would it be possible for you to describe the differences between the versions in the two deps tarballs? I think part of the problem was that when I lost my box a few weeks ago, I also lost the magic combination of deps versions, so just used the most recent versions from the rolling scripts to construct the 1.6.8 deps. If you can detail the difference between the two, that'd be useful.
>>
>> -Hyrum
>>
>> On Jan 12, 2010, at 10:52 PM, Joe Swatosh wrote:
>>
>>> Hi
>>>
>>> On Tue, Jan 12, 2010 at 2:52 PM, Hyrum K. Wright
>>> <hy...@mail.utexas.edu> wrote:
>>>> After pulling 1.6.7 due to a segfault regression, we've rerolled the branch as Subversion 1.6.8. The magic revision is r898464, and you can find the tarballs here:
>>>>
>>>> http://orac.ece.utexas.edu/pub/svn/1.6.8/
>>>>
>>>> Please be sure to test the bindings.
>>>>
>>>> You know the drill: signatures from full committers back to me, and enthusiastic tester feedback is welcome. At this point, this candidate is not yet blessed for wide release, so please don't make it available to people not interested in test-driving the new release.
>>>>
>>>> Distro package maintainers, please do NOT include any pre-release builds, even blessed, into operating system distros. The reasons for not doing so were very eloquently outlined by Karl in a mail, which is summarized at the above address.
>>>>
>>>> The quick version is: we don't guarantee compatibility between the pre-releases and the final release, so if people install the release candidate, all their repositories and working copies might break irreparably when they upgrade to 1.6.8 proper. We don't want that kind of bad publicity, and neither do you.
>>>>
>>>
>>> Built and passed when I used the 1.6.1 deps file.
>>>
>>> Link failure when using the 1.6.8 deps file:
>>> --------------------Configuration: libsvn_ra_dll - Win32
>>> Release--------------------
>>> Performing Custom Build Step on ..\..\..\build\generator\extractor.py
>>> Compiling resources...
>>> Compiling...
>>> empty.c
>>> Linking...
>>> Creating library
>>> ..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.lib and object
>>> ..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.exp
>>> libneon.lib(ne_socket.obj) : error LNK2001: unresolved external symbol
>>> _inet_aton
>>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
>>> LNK1120: 1 unresolved externals
>>> Error executing link.exe.
>>>
>>> __SWIG_RUBY__ - 2 error(s), 51 warning(s)
>>> rake aborted!
>>> Command failed with status (2): [C:\Users\joe-swatosh\Documents\SVN/BuildSc...]
>>>
>>>
>>>
>>> MS windows vista
>>> MSVC6 sp6
>>> Feb 2003 SDK
>>> Ruby 1.8.6
>>>
>>> --
>>> Joe
>>
>>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Re: 1.6.8 up for signing / testing
Posted by Mark Phippard <ma...@gmail.com>.
I think the problem is with Neon. We get this error:
Linking...
Creating library
..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.lib and object
..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.exp
libneon.lib(ne_socket.obj) : error LNK2019: unresolved external symbol
_inet_aton referenced in function _ne_iaddr_parse
..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
LNK1120: 1 unresolved externals
You are including 0.29.0 When I step it back to 0.28.3 it works.
On Wed, Jan 13, 2010 at 9:28 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Joe,
> Would it be possible for you to describe the differences between the versions in the two deps tarballs? I think part of the problem was that when I lost my box a few weeks ago, I also lost the magic combination of deps versions, so just used the most recent versions from the rolling scripts to construct the 1.6.8 deps. If you can detail the difference between the two, that'd be useful.
>
> -Hyrum
>
> On Jan 12, 2010, at 10:52 PM, Joe Swatosh wrote:
>
>> Hi
>>
>> On Tue, Jan 12, 2010 at 2:52 PM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>> After pulling 1.6.7 due to a segfault regression, we've rerolled the branch as Subversion 1.6.8. The magic revision is r898464, and you can find the tarballs here:
>>>
>>> http://orac.ece.utexas.edu/pub/svn/1.6.8/
>>>
>>> Please be sure to test the bindings.
>>>
>>> You know the drill: signatures from full committers back to me, and enthusiastic tester feedback is welcome. At this point, this candidate is not yet blessed for wide release, so please don't make it available to people not interested in test-driving the new release.
>>>
>>> Distro package maintainers, please do NOT include any pre-release builds, even blessed, into operating system distros. The reasons for not doing so were very eloquently outlined by Karl in a mail, which is summarized at the above address.
>>>
>>> The quick version is: we don't guarantee compatibility between the pre-releases and the final release, so if people install the release candidate, all their repositories and working copies might break irreparably when they upgrade to 1.6.8 proper. We don't want that kind of bad publicity, and neither do you.
>>>
>>
>> Built and passed when I used the 1.6.1 deps file.
>>
>> Link failure when using the 1.6.8 deps file:
>> --------------------Configuration: libsvn_ra_dll - Win32
>> Release--------------------
>> Performing Custom Build Step on ..\..\..\build\generator\extractor.py
>> Compiling resources...
>> Compiling...
>> empty.c
>> Linking...
>> Creating library
>> ..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.lib and object
>> ..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.exp
>> libneon.lib(ne_socket.obj) : error LNK2001: unresolved external symbol
>> _inet_aton
>> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
>> LNK1120: 1 unresolved externals
>> Error executing link.exe.
>>
>> __SWIG_RUBY__ - 2 error(s), 51 warning(s)
>> rake aborted!
>> Command failed with status (2): [C:\Users\joe-swatosh\Documents\SVN/BuildSc...]
>>
>>
>>
>> MS windows vista
>> MSVC6 sp6
>> Feb 2003 SDK
>> Ruby 1.8.6
>>
>> --
>> Joe
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: 1.6.8 up for signing / testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Joe,
Would it be possible for you to describe the differences between the versions in the two deps tarballs? I think part of the problem was that when I lost my box a few weeks ago, I also lost the magic combination of deps versions, so just used the most recent versions from the rolling scripts to construct the 1.6.8 deps. If you can detail the difference between the two, that'd be useful.
-Hyrum
On Jan 12, 2010, at 10:52 PM, Joe Swatosh wrote:
> Hi
>
> On Tue, Jan 12, 2010 at 2:52 PM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> After pulling 1.6.7 due to a segfault regression, we've rerolled the branch as Subversion 1.6.8. The magic revision is r898464, and you can find the tarballs here:
>>
>> http://orac.ece.utexas.edu/pub/svn/1.6.8/
>>
>> Please be sure to test the bindings.
>>
>> You know the drill: signatures from full committers back to me, and enthusiastic tester feedback is welcome. At this point, this candidate is not yet blessed for wide release, so please don't make it available to people not interested in test-driving the new release.
>>
>> Distro package maintainers, please do NOT include any pre-release builds, even blessed, into operating system distros. The reasons for not doing so were very eloquently outlined by Karl in a mail, which is summarized at the above address.
>>
>> The quick version is: we don't guarantee compatibility between the pre-releases and the final release, so if people install the release candidate, all their repositories and working copies might break irreparably when they upgrade to 1.6.8 proper. We don't want that kind of bad publicity, and neither do you.
>>
>
> Built and passed when I used the 1.6.1 deps file.
>
> Link failure when using the 1.6.8 deps file:
> --------------------Configuration: libsvn_ra_dll - Win32
> Release--------------------
> Performing Custom Build Step on ..\..\..\build\generator\extractor.py
> Compiling resources...
> Compiling...
> empty.c
> Linking...
> Creating library
> ..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.lib and object
> ..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.exp
> libneon.lib(ne_socket.obj) : error LNK2001: unresolved external symbol
> _inet_aton
> ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
> LNK1120: 1 unresolved externals
> Error executing link.exe.
>
> __SWIG_RUBY__ - 2 error(s), 51 warning(s)
> rake aborted!
> Command failed with status (2): [C:\Users\joe-swatosh\Documents\SVN/BuildSc...]
>
>
>
> MS windows vista
> MSVC6 sp6
> Feb 2003 SDK
> Ruby 1.8.6
>
> --
> Joe
Re: 1.6.8 up for signing / testing
Posted by Joe Swatosh <jo...@gmail.com>.
Hi
On Tue, Jan 12, 2010 at 2:52 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> After pulling 1.6.7 due to a segfault regression, we've rerolled the branch as Subversion 1.6.8. The magic revision is r898464, and you can find the tarballs here:
>
> http://orac.ece.utexas.edu/pub/svn/1.6.8/
>
> Please be sure to test the bindings.
>
> You know the drill: signatures from full committers back to me, and enthusiastic tester feedback is welcome. At this point, this candidate is not yet blessed for wide release, so please don't make it available to people not interested in test-driving the new release.
>
> Distro package maintainers, please do NOT include any pre-release builds, even blessed, into operating system distros. The reasons for not doing so were very eloquently outlined by Karl in a mail, which is summarized at the above address.
>
> The quick version is: we don't guarantee compatibility between the pre-releases and the final release, so if people install the release candidate, all their repositories and working copies might break irreparably when they upgrade to 1.6.8 proper. We don't want that kind of bad publicity, and neither do you.
>
Built and passed when I used the 1.6.1 deps file.
Link failure when using the 1.6.8 deps file:
--------------------Configuration: libsvn_ra_dll - Win32
Release--------------------
Performing Custom Build Step on ..\..\..\build\generator\extractor.py
Compiling resources...
Compiling...
empty.c
Linking...
Creating library
..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.lib and object
..\..\..\Release\subversion\libsvn_ra/libsvn_ra-1.exp
libneon.lib(ne_socket.obj) : error LNK2001: unresolved external symbol
_inet_aton
..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error
LNK1120: 1 unresolved externals
Error executing link.exe.
__SWIG_RUBY__ - 2 error(s), 51 warning(s)
rake aborted!
Command failed with status (2): [C:\Users\joe-swatosh\Documents\SVN/BuildSc...]
MS windows vista
MSVC6 sp6
Feb 2003 SDK
Ruby 1.8.6
--
Joe
Re: 1.6.8 up for signing / testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Jan 19, 2010, at 9:26 AM, kmradke@rockwellcollins.com wrote:
>
> "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote on 01/12/2010 04:52:33 PM:
>
> > After pulling 1.6.7 due to a segfault regression, we've rerolled the
> > branch as Subversion 1.6.8. The magic revision is r898464, and you
> > can find the tarballs here:
> >
> > http://orac.ece.utexas.edu/pub/svn/1.6.8/
> >
> > Please be sure to test the bindings.
> >
> > You know the drill: signatures from full committers back to me, and
> > enthusiastic tester feedback is welcome. At this point, this
> > candidate is not yet blessed for wide release, so please don't make
> > it available to people not interested in test-driving the new release.
> >
> > Distro package maintainers, please do NOT include any pre-release
> > builds, even blessed, into operating system distros. The reasons
> > for not doing so were very eloquently outlined by Karl in a mail,
> > which is summarized at the above address.
> >
> > The quick version is: we don't guarantee compatibility between the
> > pre-releases and the final release, so if people install the release
> > candidate, all their repositories and working copies might break
> > irreparably when they upgrade to 1.6.8 proper. We don't want that
> > kind of bad publicity, and neither do you.
>
> Is there a consensus yet if 1.6.8 needs to be aborted for 1.6.9? If
> not, what votes are missing for the release?
>
> (Sorry to keep asking, but we are really being hurt by the svn:external
> connection problems in all the current 1.6.x releases...)
The general confusion with the bindings, the serf failures, and other topics, has lead discussion on IRC to recommend pulling 1.6.8, and rolling 1.6.9 with a fixed deps tarball, as well as fixes to the serf failures and one more fix for a common bug. That is now the plan, and I'll shortly send out another mail to that effect.
-Hyrum
Re: 1.6.8 up for signing / testing
Posted by km...@rockwellcollins.com.
"Hyrum K. Wright" <hy...@mail.utexas.edu> wrote on 01/12/2010
04:52:33 PM:
> After pulling 1.6.7 due to a segfault regression, we've rerolled the
> branch as Subversion 1.6.8. The magic revision is r898464, and you
> can find the tarballs here:
>
> http://orac.ece.utexas.edu/pub/svn/1.6.8/
>
> Please be sure to test the bindings.
>
> You know the drill: signatures from full committers back to me, and
> enthusiastic tester feedback is welcome. At this point, this
> candidate is not yet blessed for wide release, so please don't make
> it available to people not interested in test-driving the new release.
>
> Distro package maintainers, please do NOT include any pre-release
> builds, even blessed, into operating system distros. The reasons
> for not doing so were very eloquently outlined by Karl in a mail,
> which is summarized at the above address.
>
> The quick version is: we don't guarantee compatibility between the
> pre-releases and the final release, so if people install the release
> candidate, all their repositories and working copies might break
> irreparably when they upgrade to 1.6.8 proper. We don't want that
> kind of bad publicity, and neither do you.
Is there a consensus yet if 1.6.8 needs to be aborted for 1.6.9? If
not, what votes are missing for the release?
(Sorry to keep asking, but we are really being hurt by the svn:external
connection problems in all the current 1.6.x releases...)
Thanks!
Kevin R.