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...@hyrumwright.org> on 2011/07/13 22:29:15 UTC
1.7.0-beta1 up for testing / signing
All,
Our first prerelease from the 1.7.x branch is now up for testing and
signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
in the release scripts doesn't include that rev in the header file).
You can find the tarballs here:
http://people.apache.org/~hwright/svn/1.7.0-beta1/
There aren't any known release-blocking issues, but this is still a
beta release. As you may expect, these prereleases are intended for
intrepid users and testers only. Aside from the aforementioned
revision number issue, the new release scripts appear to be behaving
themselves, though any reports to the contrary would be of great
interest.
I'd like to get a complete set of 3 *nix and 3 Windows signatures for
this release. Barring any catastrophes, this will be the only beta,
and we'll start the RC train in a week or two.
Please send sigs here:
http://work.hyrumwright.org/pub/svn/collect_sigs.py
Thanks,
-Hyrum
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 8:04 pm, "rupert.thurner" <ru...@gmail.com> wrote:
> On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
>
> > "rupert.thurner" <ru...@gmail.com> writes:
> > > it seems that the python bindings leak memory, and there seems no test
> > > covering this?
>
> > It's possible. Please provide more details.
>
> the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
> tried to do is:
> python svnmem.py
> valgrind python svnmem.py
i am not really sure how to debug this correctly. using valgrind for
mercurials hgsubversion, also using log and replay, it ends up with
500 MB of allocated memory after retrieving 5000 revisions:
$ valgrind --track-origins=yes hg clone svn://gcc.gnu.org/svn/gcc
....
[r5381] rms: [CROSS_COMPILE]: Include mips/a.out.h.
[r5382] rms: (ENQUIRE, CROSS_TEST): New variables.
[r5383] rms: (L_bb): Test inhibit_libc.
[r5384] rms: Comment change.
[r5385] rms: (INIT_CUMULATIVE_ARGS): Pass just the return value type
to aggregate_value_p.
[r5386] bson: Initial revision
[r5387] bson: added declaration for `trampoline' bytecode segment.
^Cpulled 5385 revisions
updating to branch default
557 files updated, 0 files merged, 0 files removed, 0 files
unresolved
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x80CEF97: ??? (in /usr/bin/python2.7)
==15203== by 0x80BE3C5: PyDict_Clear (in /usr/bin/python2.7)
==15203== by 0x80BE3E0: ??? (in /usr/bin/python2.7)
==15203== by 0x80F2833: ??? (in /usr/bin/python2.7)
==15203== by 0x8074B53: PyGC_Collect (in /usr/bin/python2.7)
==15203== by 0x8070F49: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Address 0x51f7010 is 1,392 bytes inside a block of size
1,536 free'd
==15203== at 0x4025BF0: free (vg_replace_malloc.c:366)
==15203== by 0x80BE3E0: ??? (in /usr/bin/python2.7)
==15203== by 0x80F2833: ??? (in /usr/bin/python2.7)
==15203== by 0x8074B53: PyGC_Collect (in /usr/bin/python2.7)
==15203== by 0x8070F49: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== by 0x805B25A: main (in /usr/bin/python2.7)
==15203==
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8105E2D: ??? (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81395BA: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Address 0x44ce010 is not stack'd, malloc'd or (recently)
free'd
==15203==
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81396A8: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== Address 0x51f9010 is 320 bytes inside a block of size 352
free'd
==15203== at 0x4025BF0: free (vg_replace_malloc.c:366)
==15203== by 0x42919C9: fclose@@GLIBC_2.1 (iofclose.c:88)
==15203== by 0x80A7544: ??? (in /usr/bin/python2.7)
==15203== by 0x810D8CA: ??? (in /usr/bin/python2.7)
==15203== by 0x81048B0: ??? (in /usr/bin/python2.7)
==15203== by 0x80E1207: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==15203== by 0x8105A60: ??? (in /usr/bin/python2.7)
==15203== by 0x80A4649: PyObject_Call (in /usr/bin/python2.7)
==15203== by 0x80A603E: ??? (in /usr/bin/python2.7)
==15203== by 0x80A4649: PyObject_Call (in /usr/bin/python2.7)
==15203== by 0x80DAD42: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==15203== by 0x80E11E6: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==15203==
==15203== Conditional jump or move depends on uninitialised value(s)
==15203== at 0x80C131F: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8105E2D: ??? (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81396A8: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Uninitialised value was created by a heap allocation
==15203== at 0x4026864: malloc (vg_replace_malloc.c:236)
==15203== by 0x80C11C8: PyObject_Malloc (in /usr/bin/python2.7)
==15203== by 0x80C5817: PyString_FromStringAndSize (in /usr/bin/
python2.7)
==15203== by 0x80E7C00: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D93: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x813ADB7: PyMarshal_ReadObjectFromString (in /usr/
bin/
python2.7)
==15203== by 0x813AE84: PyMarshal_ReadLastObjectFromFile (in /usr/
bin/python2.7)
==15203== by 0x8138C14: ??? (in /usr/bin/python2.7)
==15203==
==15203== Use of uninitialised value of size 4
==15203== at 0x80C132C: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8105E2D: ??? (in /usr/bin/python2.7)
==15203== by 0x80BD444: ??? (in /usr/bin/python2.7)
==15203== by 0x80BDCAC: PyDict_SetItem (in /usr/bin/python2.7)
==15203== by 0x80BEB36: _PyModule_Clear (in /usr/bin/python2.7)
==15203== by 0x81396A8: PyImport_Cleanup (in /usr/bin/python2.7)
==15203== by 0x8070F4E: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== Uninitialised value was created by a heap allocation
==15203== at 0x4026864: malloc (vg_replace_malloc.c:236)
==15203== by 0x80C11C8: PyObject_Malloc (in /usr/bin/python2.7)
==15203== by 0x80C5817: PyString_FromStringAndSize (in /usr/bin/
python2.7)
==15203== by 0x80E7C00: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D93: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7D01: ??? (in /usr/bin/python2.7)
==15203== by 0x80E7DA8: ??? (in /usr/bin/python2.7)
==15203== by 0x813ADB7: PyMarshal_ReadObjectFromString (in /usr/
bin/
python2.7)
==15203== by 0x813AE84: PyMarshal_ReadLastObjectFromFile (in /usr/
bin/python2.7)
==15203== by 0x8138C14: ??? (in /usr/bin/python2.7)
==15203==
==15203== Invalid read of size 4
==15203== at 0x80C1316: PyObject_Free (in /usr/bin/python2.7)
==15203== by 0x8160CA6: PyGrammar_RemoveAccelerators (in /usr/bin/
python2.7)
==15203== by 0x8070FC1: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== by 0x805B25A: main (in /usr/bin/python2.7)
==15203== Address 0x4929010 is 32 bytes inside a block of size 668
free'd
==15203== at 0x4025BF0: free (vg_replace_malloc.c:366)
==15203== by 0x8160CA6: PyGrammar_RemoveAccelerators (in /usr/bin/
python2.7)
==15203== by 0x8070FC1: Py_Finalize (in /usr/bin/python2.7)
==15203== by 0x8070368: Py_Exit (in /usr/bin/python2.7)
==15203== by 0x80704CB: ??? (in /usr/bin/python2.7)
==15203== by 0x80704F1: PyErr_PrintEx (in /usr/bin/python2.7)
==15203== by 0x80707B2: PyErr_Print (in /usr/bin/python2.7)
==15203== by 0x8070B01: PyRun_SimpleFileExFlags (in /usr/bin/
python2.7)
==15203== by 0x805C068: Py_Main (in /usr/bin/python2.7)
==15203== by 0x805B25A: main (in /usr/bin/python2.7)
==15203==
==15203==
==15203== HEAP SUMMARY:
==15203== in use at exit: 522,966,454 bytes in 10,803 blocks
==15203== total heap usage: 14,067,230 allocs, 14,056,427 frees,
59,559,225,904 bytes allocated
==15203==
==15203== LEAK SUMMARY:
==15203== definitely lost: 168 bytes in 7 blocks
==15203== indirectly lost: 0 bytes in 0 blocks
==15203== possibly lost: 158,392 bytes in 435 blocks
==15203== still reachable: 522,807,894 bytes in 10,361 blocks
==15203== suppressed: 0 bytes in 0 blocks
==15203== Rerun with --leak-check=full to see details of leaked
memory
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Philip Martin <ph...@wandisco.com>.
"rupert.thurner" <ru...@gmail.com> writes:
> On Jul 17, 10:16 pm, Philip Martin <ph...@wandisco.com> wrote:
>> "rupert.thurner" <ru...@gmail.com> writes:
>> > now it works ... and running it for 100'000 revisions slowly increases
>> > #!/usr/bin/python
>>
>> > import svn.client
>> > import svn.core
>> > import svn.ra
>>
>> > pool = svn.core.Pool()
>> > client = svn.client.create_context(pool)
>> > client.config = svn.core.svn_config_get_config(None)
>> > client.auth_baton =
>> > svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>>
>> > ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
>> > pool)
>> > def rcvr(orig_paths, rev, author, date, message, pool):
>> > if orig_paths is not None:
>> > for x in orig_paths:
>> > orig_paths[x]._parent_pool.destroy()
>>
>> Destroying pools like that was a workaround for a bug that has been
>> fixed. It's only safe if nothing uses, or explictily destroys, the
>> pool.
>
> how are the pools correctly destroyed?
According to the issue 3052 it was fixed by r868618:
r868618 | djames | 2007-12-19 01:10:36 +0000 (Wed, 19 Dec 2007) | 11 lines
Fix a major memory leak in the Python object duplication code.
> i tried to use the subversion
> test cases to find a small example for replay, but it seems to be not
> tested at all? is there some documentation you could point to which
> shows how to use replay correctly?
The bindings test coverage is limited, it would help if more tests were
written. The best I can suggest is the C API and the svnsync usage:
http://subversion.apache.org/docs/api/latest/svn__ra_8h.html
http://svn.apache.org/repos/asf/subversion/trunk/subversion/svnsync/main.c
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 10:16 pm, Philip Martin <ph...@wandisco.com> wrote:
> "rupert.thurner" <ru...@gmail.com> writes:
> > now it works ... and running it for 100'000 revisions slowly increases
> > #!/usr/bin/python
>
> > import svn.client
> > import svn.core
> > import svn.ra
>
> > pool = svn.core.Pool()
> > client = svn.client.create_context(pool)
> > client.config = svn.core.svn_config_get_config(None)
> > client.auth_baton =
> > svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>
> > ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
> > pool)
> > def rcvr(orig_paths, rev, author, date, message, pool):
> > if orig_paths is not None:
> > for x in orig_paths:
> > orig_paths[x]._parent_pool.destroy()
>
> Destroying pools like that was a workaround for a bug that has been
> fixed. It's only safe if nothing uses, or explictily destroys, the
> pool.
how are the pools correctly destroyed? i tried to use the subversion
test cases to find a small example for replay, but it seems to be not
tested at all? is there some documentation you could point to which
shows how to use replay correctly?
rupert
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Philip Martin <ph...@wandisco.com>.
"rupert.thurner" <ru...@gmail.com> writes:
> now it works ... and running it for 100'000 revisions slowly increases
> the memory. but the main problem seems to be replay. you have an
> example? i did not find anything in the test subversion testcases.
I don't understand: are you saying there is a problem in replay? How do
you know if you don't have an example? Are you using some other program?
> #!/usr/bin/python
>
> import svn.client
> import svn.core
> import svn.ra
>
> pool = svn.core.Pool()
> client = svn.client.create_context(pool)
> client.config = svn.core.svn_config_get_config(None)
> client.auth_baton =
> svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>
> ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
> pool)
> def rcvr(orig_paths, rev, author, date, message, pool):
> if orig_paths is not None:
> for x in orig_paths:
> orig_paths[x]._parent_pool.destroy()
Destroying pools like that was a workaround for a bug that has been
fixed. It's only safe if nothing uses, or explictily destroys, the
pool.
> print rev
> svn.ra.get_log(ra, [""], 0, 100000, 0, True, False, rcvr)
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Does it occur over neon, serf, or both?
rupert.thurner wrote on Sun, Jul 17, 2011 at 12:55:53 -0700:
> On Jul 17, 8:04 pm, "rupert.thurner" <ru...@gmail.com> wrote:
> > On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
> >
> > > "rupert.thurner" <ru...@gmail.com> writes:
> > > > it seems that the python bindings leak memory, and there seems no test
> > > > covering this?
> >
> > > It's possible. Please provide more details.
> >
> > the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
> > tried to do is:
> > python svnmem.py
> > valgrind python svnmem.py
> >
> > for a start, i tried to run the test case fromhttp://subversion.tigris.org/issues/show_bug.cgi?id=3052with
> > svn-1.6.12, but it produces a segmentation fault here. see below for
> > the script.
> now it works ... and running it for 100'000 revisions slowly increases
> the memory. but the main problem seems to be replay. you have an
> example? i did not find anything in the test subversion testcases.
>
>
> #!/usr/bin/python
>
> import svn.client
> import svn.core
> import svn.ra
>
> pool = svn.core.Pool()
> client = svn.client.create_context(pool)
> client.config = svn.core.svn_config_get_config(None)
> client.auth_baton =
> svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
>
> ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
> pool)
> def rcvr(orig_paths, rev, author, date, message, pool):
> if orig_paths is not None:
> for x in orig_paths:
> orig_paths[x]._parent_pool.destroy()
> print rev
> svn.ra.get_log(ra, [""], 0, 100000, 0, True, False, rcvr)
>
> client = svn.client.create_context(pool)
>
>
>
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 8:04 pm, "rupert.thurner" <ru...@gmail.com> wrote:
> On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
>
> > "rupert.thurner" <ru...@gmail.com> writes:
> > > it seems that the python bindings leak memory, and there seems no test
> > > covering this?
>
> > It's possible. Please provide more details.
>
> the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
> tried to do is:
> python svnmem.py
> valgrind python svnmem.py
>
> for a start, i tried to run the test case fromhttp://subversion.tigris.org/issues/show_bug.cgi?id=3052with
> svn-1.6.12, but it produces a segmentation fault here. see below for
> the script.
now it works ... and running it for 100'000 revisions slowly increases
the memory. but the main problem seems to be replay. you have an
example? i did not find anything in the test subversion testcases.
#!/usr/bin/python
import svn.client
import svn.core
import svn.ra
pool = svn.core.Pool()
client = svn.client.create_context(pool)
client.config = svn.core.svn_config_get_config(None)
client.auth_baton =
svn.core.svn_auth_open([svn.client.get_simple_provider(pool)], pool)
ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client,
pool)
def rcvr(orig_paths, rev, author, date, message, pool):
if orig_paths is not None:
for x in orig_paths:
orig_paths[x]._parent_pool.destroy()
print rev
svn.ra.get_log(ra, [""], 0, 100000, 0, True, False, rcvr)
client = svn.client.create_context(pool)
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 17, 9:54 am, Philip Martin <ph...@wandisco.com> wrote:
> "rupert.thurner" <ru...@gmail.com> writes:
> > it seems that the python bindings leak memory, and there seems no test
> > covering this?
>
> It's possible. Please provide more details.
the problem seems to be in svn_ra_replay and/or svn_ra_get_log. what i
tried to do is:
python svnmem.py
valgrind python svnmem.py
for a start, i tried to run the test case from
http://subversion.tigris.org/issues/show_bug.cgi?id=3052 with
svn-1.6.12, but it produces a segmentation fault here. see below for
the script.
#!/usr/bin/python
import svn.client
import svn.core
import svn.ra
pool = svn.core.Pool()
client = svn.client.create_context()
ra = svn.client.open_ra_session("http://gcc.gnu.org/svn/gcc", client)
def rcvr(orig_paths, rev, author, date, message, pool):
if orig_paths is not None:
for x in orig_paths:
orig_paths[x]._parent_pool.destroy()
print rev
svn.ra.get_log(ra, [""], 0, 700000, 0, True, False, rcvr)
Re: python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by Philip Martin <ph...@wandisco.com>.
"rupert.thurner" <ru...@gmail.com> writes:
> it seems that the python bindings leak memory, and there seems no test
> covering this?
It's possible. Please provide more details.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
python bindings leak memory (Re: 1.7.0-beta1 up for testing)
Posted by "rupert.thurner" <ru...@gmail.com>.
On Jul 13, 10:29 pm, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> All,
>
> Our first prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can find the tarballs here:http://people.apache.org/~hwright/svn/1.7.0-beta1/
>
> There aren't any known release-blocking issues, but this is still a
> beta release. As you may expect, these prereleases are intended for
> intrepid users and testers only. Aside from the aforementioned
> revision number issue, the new release scripts appear to be behaving
> themselves, though any reports to the contrary would be of great
> interest.
>
> I'd like to get a complete set of 3 *nix and 3 Windows signatures for
> this release. Barring any catastrophes, this will be the only beta,
> and we'll start the RC train in a week or two.
>
> Please send sigs here:http://work.hyrumwright.org/pub/svn/collect_sigs.py
it seems that the python bindings leak memory, and there seems no test
covering this?
rupert.
Re: 1.7.0-beta1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
Summary:
+1 to release
Platform:
Linux (Debian/squeeze)
Tested:
tarball + local dependencies
(local, svn, svn+sasl, serf, neon) x (fsfs, fsfs/pack/shard, bdb)
(serf/v1, neon/v1) x (fsfs, bdb)
swig-pl, swig-py, swig-rb
javahl x (fsfs, bdb)
Results:
All tests PASS
Local dependencies:
apache2-threaded-dev : 2.2.16-6+squeeze1
libapr1-dev : 1.4.2-6+squeeze3
libaprutil1-dev : 1.3.9+dfsg-5
libdb4.8-dev : 4.8.30-2
libneon27-dev : 0.29.3-3
libsasl2-dev : 2.1.23.dfsg1-7
libsqlite3-dev : 3.7.3-1
perl : 5.10.1-17squeeze2
python2.6-dev : 2.6.6-8+b1
ruby1.8-dev : 1.8.7.302-2squeeze1
openjdk-6-jdk : 6b18-1.8.7-2~squeeze1
serf : trunk@1536
subversion-1.7.0-beta1.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABCAAGBQJOHvR5AAoJEHbXiOHtGlmcjzgH/jv51MRUEq/Cao5pln6EB8dn
fNYQwENrIuGRgIxAeTqBa63jGMmT/qcLR2SVBcCUM3kQTq8G/OcJhfP/PRYjrSW1
R0VU/DQ2KbgQaA3C8+wi7hhfrND64KHwVxgaM8vuW65qqvkDN9fFn0e1QRSD4uw4
rxzUh02Yq5YNE6aDzMAmauOkw/O5whmGvmQU9FSHjBfBGgp9fOBO3lYXulKKobxh
oMBfaMejQFMvzUeId6/E7EzA46RhMy1U71jPyiQPhJF7soH69+Q/UcvCw/emZE2D
U9Z6/hHkJKdpDKpmsRIo96BLQGb4C5qS4aw4yB3YeJE6qI08ZAuRPkRn+NdtwVI=
=mWPa
-----END PGP SIGNATURE-----
subversion-1.7.0-beta1.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABCAAGBQJOHvSmAAoJEHbXiOHtGlmcKKsH/3RAhlhUzxa9mZhcCC5tCJ5s
fOr3rePWsZsR/NKLPBOMK2ghp2a9WoCGjn3Jq1yoGMINY5uHPrbyi77U/m5qsZz+
yw9G5pygtV8zqc3p4aTWaf4NiTL9lFSqnwRReE9TR5JR1I1EqV1YKmcWTgK7dUDR
L2SAtspID11168IpoNjOiEB2L4wXSkNBbNi69IzNNzuEesmzR6Y+bCFhUoyoCMGD
p8nl9TsFmc+QXrKVc9qHe25FlKXLkjui4gXEOnsCROJKnXUlZdl8JcOLKYIKWplg
X1wVVVI0oHcPV3Ev9ObZNf+YailHJzDJ5bcWmppUVl4FeeavDK5QfTmhH0THT+M=
=O3+2
-----END PGP SIGNATURE-----
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-beta1 up for testing / signing
Posted by Mark Phippard <ma...@gmail.com>.
SUMMARY:
+1 to release
PLATFORM:
Windows 7
VS 2008 SP1
Java 1.6
COMPONENTS:
Apache 2.2.19
APR 1.4.5
APR-UTIL 1.3.12
OpenSSL 1.0.0a
Neon 0.29.6
Serf trunk
ZLib 1.2.4
SQLite 3.7.7.1
VERIFIED:
sha1 sums
TESTED:
JavaHL
ra_local | ra_svn | ra_neon | ra_serf X fsfs
RESULTS:
All passed
SIGNATURES:
subversion-1.7.0-beta1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iEYEABECAAYFAk4e8fQACgkQJl34oANalqkn9wCgj2LGNCCen4eKvm2ZLW3iSGn5
9OUAnRXMINNSf/aSYAqKf3JexLalb+8L
=+0U4
-----END PGP SIGNATURE-----
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: 1.7.0-beta1 up for testing / signing
Posted by Roderich Schupp <ro...@googlemail.com>.
On Thu, Jul 21, 2011 at 5:37 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Thanks! Could you verify the following patch:
Great, works for me with Apache 2.0.64 and APR 0.9.19.
Cheers, Roderich
Re: 1.7.0-beta1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
"roderich.schupp@googlemail.com" <ro...@googlemail.com>
writes:
> sorry for the late posting. Here are some minor build nits for people
> stuck
> with old versions of APR and Apache.
>
> - subversion/include/private/svn_dep_compat.h, line 72-73:
> APR_UINT64_C and APR_INT64_C don't exist in APR 0.9.x
I see APR_INT64_C, only APR_UINT64_C is missing.
> possible fix (at least for people with a moderately recent C
> compiler):
>
> #define APR_UINT64_MAX UINT64_MAX
> #define APR_INT64_MAX INT64_MAX
>
> - subversion/tests/libsvn_wc/op-depth-test.c, line 121:
> APR_FPROT_OS_DEFAULT doesn't exist in APR 0.9.x
> It was called APR_OS_DEFAULT then (which is still recognized in APR
> 1.4.x).
>
> - subversion/mod_dav_svn/util.c, line 681:
> apr_strtoff doesn't exist in APR 0.9.x
>
> possible fix: use strtol instead
Thanks! Could you verify the following patch:
Index: subversion/mod_dav_svn/util.c
===================================================================
--- subversion/mod_dav_svn/util.c (revision 1149187)
+++ subversion/mod_dav_svn/util.c (working copy)
@@ -37,6 +37,7 @@
#include "dav_svn.h"
#include "private/svn_fspath.h"
+#include "private/svn_string_private.h"
dav_error *
dav_svn__new_error(apr_pool_t *pool,
@@ -678,7 +679,7 @@
content_length_str = apr_table_get(r->headers_in, "Content-Length");
if (content_length_str)
{
- if (apr_strtoff(&content_length, content_length_str, &endp, 10)
+ if (svn__strtoff(&content_length, content_length_str, &endp, 10)
|| endp == content_length_str || *endp || content_length < 0)
{
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, "Invalid Content-Length");
Index: subversion/include/private/svn_string_private.h
===================================================================
--- subversion/include/private/svn_string_private.h (revision 1149187)
+++ subversion/include/private/svn_string_private.h (working copy)
@@ -53,6 +53,11 @@
*/
svn_string_t *
svn_stringbuf__morph_into_string(svn_stringbuf_t *strbuf);
+
+/** Like apr_strtoff but provided here for backward compatibility
+ * with APR 0.9 */
+apr_status_t
+svn__strtoff(apr_off_t *offset, const char *buf, char **end, int base);
/** @} */
/** @} */
Index: subversion/include/private/svn_dep_compat.h
===================================================================
--- subversion/include/private/svn_dep_compat.h (revision 1149187)
+++ subversion/include/private/svn_dep_compat.h (working copy)
@@ -62,6 +62,11 @@
#define apr_array_clear(arr) (arr)->nelts = 0
#endif
+#if !APR_VERSION_AT_LEAST(1,0,0)
+#define APR_UINT64_C(val) UINT64_C(val)
+#define APR_FPROT_OS_DEFAULT APR_OS_DEFAULT
+#endif
+
#if !APR_VERSION_AT_LEAST(1,3,0)
#define APR_UINT16_MAX 0xFFFFU
#define APR_INT16_MAX 0x7FFF
Index: subversion/libsvn_subr/svn_string.c
===================================================================
--- subversion/libsvn_subr/svn_string.c (revision 1149187)
+++ subversion/libsvn_subr/svn_string.c (working copy)
@@ -839,3 +839,16 @@
*n = (int)val;
return SVN_NO_ERROR;
}
+
+
+apr_status_t
+svn__strtoff(apr_off_t *offset, const char *buf, char **end, int base)
+{
+#if !APR_VERSION_AT_LEAST(1,0,0)
+ errno = 0;
+ *offset = strtol(buf, end, base);
+ return APR_FROM_OS_ERROR(errno);
+#else
+ return apr_strtoff(offset, buf, end, base);
+#endif
+}
Index: subversion/tests/libsvn_wc/op-depth-test.c
===================================================================
--- subversion/tests/libsvn_wc/op-depth-test.c (revision 1149187)
+++ subversion/tests/libsvn_wc/op-depth-test.c (working copy)
@@ -40,6 +40,7 @@
#include "private/svn_wc_private.h"
#include "private/svn_sqlite.h"
+#include "private/svn_dep_compat.h"
#include "../../libsvn_wc/wc.h"
#include "../../libsvn_wc/wc_db.h"
#define SVN_WC__I_AM_WC_DB
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-beta1 up for testing / signing
Posted by "roderich.schupp@googlemail.com" <ro...@googlemail.com>.
Hi,
sorry for the late posting. Here are some minor build nits for people
stuck
with old versions of APR and Apache.
- subversion/include/private/svn_dep_compat.h, line 72-73:
APR_UINT64_C and APR_INT64_C don't exist in APR 0.9.x
possible fix (at least for people with a moderately recent C
compiler):
#define APR_UINT64_MAX UINT64_MAX
#define APR_INT64_MAX INT64_MAX
- subversion/tests/libsvn_wc/op-depth-test.c, line 121:
APR_FPROT_OS_DEFAULT doesn't exist in APR 0.9.x
It was called APR_OS_DEFAULT then (which is still recognized in APR
1.4.x).
- subversion/mod_dav_svn/util.c, line 681:
apr_strtoff doesn't exist in APR 0.9.x
possible fix: use strtol instead
Cheers, Roderich
Re: 1.7.0-beta1 up for testing / signing
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jul 13, 2011 at 03:29:15PM -0500, Hyrum K Wright wrote:
> All,
>
> Our first prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can find the tarballs here:
> http://people.apache.org/~hwright/svn/1.7.0-beta1/
>
> There aren't any known release-blocking issues, but this is still a
> beta release. As you may expect, these prereleases are intended for
> intrepid users and testers only. Aside from the aforementioned
> revision number issue, the new release scripts appear to be behaving
> themselves, though any reports to the contrary would be of great
> interest.
>
> I'd like to get a complete set of 3 *nix and 3 Windows signatures for
> this release. Barring any catastrophes, this will be the only beta,
> and we'll start the RC train in a week or two.
>
> Please send sigs here:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
Summary: +1 to release
Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_neon | ra_serf]
swig bindings
Test results: All passed (except for local swig-py problems as mentioned
for alpha3 at http://svn.haxx.se/dev/archive-2011-07/0155.shtml,
still need to get around to fixing them)
Platform: OpenBSD 4.9 amd64
Dependencies:
bdb: 4.7.25
GNU-iconv: 1.13.1
apr: 1.4.5
apr-util: 1.3.12
httpd: 2.2.19
neon: 0.29.6
serf: 0.7.x
cyrus-sasl: 2.1.23
sqlite: 3070603
openssl: 1.0.0a
swig: 1.3.36
python: 2.6.6
perl: 5.12.2
ruby: 1.8.7-p334
Signatures:
subversion-1.7.0-beta1.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (OpenBSD)
iEYEABECAAYFAk4ekooACgkQ5dMCc/WdJfDv4ACgqjc+mROeNqfKj6DxdzpJhSA5
kmwAoNEDUCBX5JkHvDmyqzw4uWRmkjBO
=0B3X
-----END PGP SIGNATURE-----
subversion-1.7.0-beta1.tar.bz2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (OpenBSD)
iEYEABECAAYFAk4ekrYACgkQ5dMCc/WdJfB4vACg9cZX0UJXoI04qRM/ilsf6fBO
1YoAnAvpaoBYNjCLwP/Lzrmk+IpxW6Fq
=3mIT
-----END PGP SIGNATURE-----
Re: 1.7.0-beta1 up for testing / signing
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Mon, Jul 18, 2011 at 4:57 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: zondag 17 juli 2011 12:14
>> To: Hyrum K Wright; dev@subversion.apache.org
>> Subject: Re: 1.7.0-beta1 up for testing / signing
>>
>> On Sun, Jul 17, 2011 at 06:04, Stefan Sperling <st...@elego.de> wrote:
>> > On Sun, Jul 17, 2011 at 05:20:25AM -0400, Greg Stein wrote:
>> >> There have been quite a few changes merged into the 1.7.x branch. How
>> >> about nuking this tarball, and rolling a new one? We *know* this
>> >> tarball isn't what we'd like to deliver to users, so why should we
>> >> bother posting it?
>> >
>> > The point of pre-releases is to find regressions we don't know about.
>> > These could lurk in beta1 just as well as current 1.7.x.
>> >
>> > Stuff we have merged into 1.7.x can be listed as known problems
>> > for beta1 which will be fixed in beta2.
>>
>> Sure, but we haven't even released beta1 yet. I'm saying that we nuke
>> it as "already not what we want to deliver".
>>
>> At the "beta" point, it seems that we'd really like to be much closer
>> to reality. Alphas are pretty throw-away, but betas... we want to be
>> close. And we already know that this unreleased beta1 doesn't match
>> what we want to release.
The "long" delay between rolling the tarballs and releasing is
compounded by a couple of factors, the primary of which is waiting for
the mirror network to sync the tarballs. For instance, when I woke up
last Saturday, I noticed Mike and Philip had +1'd the beta release, so
I updated the signatures and pushed the beta to w.a.o/dist/subversion.
With tigris, I'd have updated the webpages and sent out the release
announcement right then, but using ASF infra to mirror the release, we
need to wait an extra day[1], putting the "earliest release moment" at
sometime Sunday morning. I don't do Subversion-stuffs on Sundays,
which means the release was going to be announced this morning. I've
noticed this pattern for the alphas as well.
All told, that means a series of delays from patch nomination to asf
mirror, means that a fix that goes in on a Tuesday waits until the
following Monday morning to be released (and that's *if* we get quick
sigs and the tarballs don't have any problems). Putting it in that
perspective, I think it's probably suboptimal, particularly if we're
interested in a rapid-fire series of releases (like betas or RCs).
For patch releases, I'm not so concerned (unless it's a critical fix,
in which case the 24-hour mirror window can be shorted[2]).
Now, some of the delay may be my own slothfulness, and posting
tarballs earlier in the week helps with the weekend-induced delays,
but there is some minimal amount of time for release creation. During
this time, we will probably find and fix bugs, but I don't think it
makes sense to scrap an existing pending release and restart the train
unless there is something critically wrong with the former.
Anyway, as for 1.7.0-beta1, everything is ready to go, but it feels
like the sentiment is toward not releasing it, so I won't unless
pressed.
[1] Yes, I know that per http://www.apache.org/dev/mirrors.html we can
give the mirror script a timestamp to shorten the 24-hour window, but
in attempting to be a good citizen, I've not done so.
[2] But in the case of a critical bugfix, I feel perfectly comfortable
using the above technique.
>
> +1
>
> And while we are at it, maybe we shouldn't use the 24 hour delay merging
> things back to 1.7 in this phase.
> Merging approved patches back directly improves the test coverage. Even if
> it is only because the buildbots will directly start building 1.7.x.
>
> In that case I would suggest that we DO keep the approved+already merged
> patches in STATUS for some time for better reviews.
>
> We can always roll back vetoed patches before the next tag.
If folks what to merge immediately, that's fine.
In spite of the "we can always revert it" mentality, I've observed a
significant status quo bias when it comes to reverting changes. It's
not technically hard, we just don't really do it that often, and when
a proposal does get going, we instead end up bikeshedding about
whether to fix it or revert it, which turns into a major time sink.
The idea behind the 24-hour merge window was to avoid that problem,
giving people the chance to register their concerns before we do the
merge, rather than after.
-Hyrum
RE: 1.7.0-beta1 up for testing / signing
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: zondag 17 juli 2011 12:14
> To: Hyrum K Wright; dev@subversion.apache.org
> Subject: Re: 1.7.0-beta1 up for testing / signing
>
> On Sun, Jul 17, 2011 at 06:04, Stefan Sperling <st...@elego.de> wrote:
> > On Sun, Jul 17, 2011 at 05:20:25AM -0400, Greg Stein wrote:
> >> There have been quite a few changes merged into the 1.7.x branch. How
> >> about nuking this tarball, and rolling a new one? We *know* this
> >> tarball isn't what we'd like to deliver to users, so why should we
> >> bother posting it?
> >
> > The point of pre-releases is to find regressions we don't know about.
> > These could lurk in beta1 just as well as current 1.7.x.
> >
> > Stuff we have merged into 1.7.x can be listed as known problems
> > for beta1 which will be fixed in beta2.
>
> Sure, but we haven't even released beta1 yet. I'm saying that we nuke
> it as "already not what we want to deliver".
>
> At the "beta" point, it seems that we'd really like to be much closer
> to reality. Alphas are pretty throw-away, but betas... we want to be
> close. And we already know that this unreleased beta1 doesn't match
> what we want to release.
+1
And while we are at it, maybe we shouldn't use the 24 hour delay merging
things back to 1.7 in this phase.
Merging approved patches back directly improves the test coverage. Even if
it is only because the buildbots will directly start building 1.7.x.
In that case I would suggest that we DO keep the approved+already merged
patches in STATUS for some time for better reviews.
We can always roll back vetoed patches before the next tag.
Bert
Re: 1.7.0-beta1 up for testing / signing
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Jul 17, 2011 at 7:36 PM, Stefan Sperling <st...@elego.de> wrote:
> We've already put time into beta1 for testing and signing.
> I'd say just post it and then start the beta2 (or RC1) train right away.
> The tarballs are always going to lag behind repository history.
>
> People who run these betas are voluntary testers who can cope with
> known problems.
FWIW: I agree with Greg. For betas, we should be more respectful of
their time rather than giving them something we know has a lot of
issues that have been fixed. -- justin
Re: 1.7.0-beta1 up for testing / signing
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Jul 17, 2011 at 06:14:27AM -0400, Greg Stein wrote:
> Sure, but we haven't even released beta1 yet. I'm saying that we nuke
> it as "already not what we want to deliver".
>
> At the "beta" point, it seems that we'd really like to be much closer
> to reality. Alphas are pretty throw-away, but betas... we want to be
> close. And we already know that this unreleased beta1 doesn't match
> what we want to release.
We've already put time into beta1 for testing and signing.
I'd say just post it and then start the beta2 (or RC1) train right away.
The tarballs are always going to lag behind repository history.
People who run these betas are voluntary testers who can cope with
known problems.
Re: 1.7.0-beta1 up for testing / signing
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Jul 17, 2011 at 06:04, Stefan Sperling <st...@elego.de> wrote:
> On Sun, Jul 17, 2011 at 05:20:25AM -0400, Greg Stein wrote:
>> There have been quite a few changes merged into the 1.7.x branch. How
>> about nuking this tarball, and rolling a new one? We *know* this
>> tarball isn't what we'd like to deliver to users, so why should we
>> bother posting it?
>
> The point of pre-releases is to find regressions we don't know about.
> These could lurk in beta1 just as well as current 1.7.x.
>
> Stuff we have merged into 1.7.x can be listed as known problems
> for beta1 which will be fixed in beta2.
Sure, but we haven't even released beta1 yet. I'm saying that we nuke
it as "already not what we want to deliver".
At the "beta" point, it seems that we'd really like to be much closer
to reality. Alphas are pretty throw-away, but betas... we want to be
close. And we already know that this unreleased beta1 doesn't match
what we want to release.
Cheers,
-g
Re: 1.7.0-beta1 up for testing / signing
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Jul 17, 2011 at 05:20:25AM -0400, Greg Stein wrote:
> There have been quite a few changes merged into the 1.7.x branch. How
> about nuking this tarball, and rolling a new one? We *know* this
> tarball isn't what we'd like to deliver to users, so why should we
> bother posting it?
The point of pre-releases is to find regressions we don't know about.
These could lurk in beta1 just as well as current 1.7.x.
Stuff we have merged into 1.7.x can be listed as known problems
for beta1 which will be fixed in beta2.
Re: 1.7.0-beta1 up for testing / signing
Posted by Greg Stein <gs...@gmail.com>.
There have been quite a few changes merged into the 1.7.x branch. How
about nuking this tarball, and rolling a new one? We *know* this
tarball isn't what we'd like to deliver to users, so why should we
bother posting it?
Cheers,
-g
On Wed, Jul 13, 2011 at 16:29, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> All,
>
> Our first prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can find the tarballs here:
> http://people.apache.org/~hwright/svn/1.7.0-beta1/
>
> There aren't any known release-blocking issues, but this is still a
> beta release. As you may expect, these prereleases are intended for
> intrepid users and testers only. Aside from the aforementioned
> revision number issue, the new release scripts appear to be behaving
> themselves, though any reports to the contrary would be of great
> interest.
>
> I'd like to get a complete set of 3 *nix and 3 Windows signatures for
> this release. Barring any catastrophes, this will be the only beta,
> and we'll start the RC train in a week or two.
>
> Please send sigs here:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>
> Thanks,
> -Hyrum
>
Re: 1.7.0-beta1 up for testing / signing
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Jul 13, 2011 at 4:29 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> All,
>
> Our first prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can find the tarballs here:
> http://people.apache.org/~hwright/svn/1.7.0-beta1/
>
> There aren't any known release-blocking issues, but this is still a
> beta release. As you may expect, these prereleases are intended for
> intrepid users and testers only. Aside from the aforementioned
> revision number issue, the new release scripts appear to be behaving
> themselves, though any reports to the contrary would be of great
> interest.
>
> I'd like to get a complete set of 3 *nix and 3 Windows signatures for
> this release. Barring any catastrophes, this will be the only beta,
> and we'll start the RC train in a week or two.
>
> Please send sigs here:
> http://work.hyrumwright.org/pub/svn/collect_sigs.py
>
> Thanks,
> -Hyrum
SUMMARY:
---------
+1 to release
VERIFIED:
---------
Hyrum's sig for
http://people.apache.org/~hwright/svn/1.7.0-beta1/deploy/subversion-1.7.0-beta1.zip
Other than the expected differences in
subversion/include/svn_version.h,
http://people.apache.org/~hwright/svn/1.7.0-beta1/deploy/subversion-1.7.0-beta1.zip
is identical to
https://svn.apache.org/repos/asf/subversion/branches/1.7.x@1146221.
TESTED:
-------
[Release-Build] x[ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ]
Ruby bindings (locally patched as described here:
http://svn.haxx.se/dev/archive-2011-06/0682.shtml)
JavaHL Bindings
RESULTS:
--------
All Pass[1]
PLATFORM:
---------
MS Windows 7 Home Premium 6.1.7600 Build 7600
Intel Core i7 M 620 2.67GHz 4 GB RAM
Microsoft Visual Studio 2008 Version 9.0.30729.1 SP
DEPENDENCIES:
-------------
APR: 1.4.5
APR-UTIL: 1.3.12
Neon: 0.29.5
zlib: 1.2.4
OpenSSL: 0.9.8q
Apache: 2.2.19
BDB: 4.8.30
sqlite: 3.7.7.1
Python: 2.6.6 (ActivePython 2.6.6.17)
Perl: 5.10.1
Ruby: ruby 1.8.7
java: 1.6.0_21
junit: 4.8.2
swig: 1.3.40
serf: trunk@1530
SIGNATURE:
----------
http://people.apache.org/~hwright/svn/1.7.0-alpha3/deploy/subversion-1.7.0-alpha3.zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
iD4DBQBOHiy/2RaJMFP83FURAuAjAJjNhkftMn+JI28vFgBVxaiPBHB7AJ0Ur4MW
xSBw29dtA+iuwRAxRV16YA==
=br9I
-----END PGP SIGNATURE-----
Paul
Re: 1.7.0-beta1 up for testing / signing
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/15/2011 10:53 PM, C. Michael Pilato wrote:
> Sorry, guys -- I've been watching the messages flying back and forth, but
> haven't been able to discern a key piece of information from them:
>
> Is this a regression?
>
> I ask because I test all our releases the same way, and 1.7.0-alpha3 did
> *not* exhibit this problem I reported where 1.7.0-beta1 does. Now, it's
> possible that there was a small difference in my testing approach this time,
> namely that I might have actually installed the compiled product on my
> system instead of merely running the tests having *not* done 'make install
> install-pl ...'.
>
> I'll start over from scratch to see if skipping the install step (which,
> again, I typically do) makes the difference.
Yep, it matters. That one difference in my test routine caused the problem.
So, Hyrum, you have my +1 for this release:
Summary:
+1 to release.
Platform:
Ubuntu 10.04 (lucid) Linux.
Tested:
(local, svn, neon, serf) x (bdb, fsfs) + py + py + pl + rb + javahl
Results:
All tests pass.
MD5 Checksums:
34686ebaba49bcf98206acb4e020ae6a subversion-1.7.0-beta1.tar.gz
8b184d9484f10edb6d5921e050d9d69b subversion-1.7.0-beta1.tar.bz2
GPG Signatures (left-aligned because Hyrum likes it that way):
::: subversion-1.7.0-beta1.tar.gz :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk4fFt0ACgkQokEGqRcG/W4D1QCbBJI+R8A/3UKZXgzrgbXGLTYC
L90An0iS1ebHvf5RMGmHprphgmuieaTD
=Q3l6
-----END PGP SIGNATURE-----
::: subversion-1.7.0-beta1.tar.bz2 :::
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk4fFuAACgkQokEGqRcG/W7/FwCfR9YzGu/aEzV4+8PIZRpp5rXj
maAAn06ZNy/Z9PKDHdaPLTnQTv3kh/8U
=dZch
-----END PGP SIGNATURE-----
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7.0-beta1 up for testing / signing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Sorry, guys -- I've been watching the messages flying back and forth, but
haven't been able to discern a key piece of information from them:
Is this a regression?
I ask because I test all our releases the same way, and 1.7.0-alpha3 did
*not* exhibit this problem I reported where 1.7.0-beta1 does. Now, it's
possible that there was a small difference in my testing approach this time,
namely that I might have actually installed the compiled product on my
system instead of merely running the tests having *not* done 'make install
install-pl ...'.
I'll start over from scratch to see if skipping the install step (which,
again, I typically do) makes the difference.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7.0-beta1 up for testing / signing
Posted by Peter Samuelson <pe...@p12n.org>.
> Peter Samuelson <pe...@p12n.org> writes:
> > My patch is pretty crude, to Makefile.in:
> >
> > $(SWIG_PL_DIR)/native/Makefile: $(SWIG_PL_DIR)/native/Makefile.PL
> > - cd $(SWIG_PL_DIR)/native; $(PERL) Makefile.PL
> > + cd $(SWIG_PL_DIR)/native; \
> > + $(PERL) Makefile.PL INSTALLDIRS=vendor; \
> > + sed -i -e '/^LD_RUN_PATH/s/^/#/' Makefile Makefile.[a-z]*
> >
> > Basically it comments out the LD_RUN_PATH = ... line from the family of
> > Makefiles. (Adding 'INSTALLDIRS=vendor' is also needed here, but is
> > not part of the RPATH fix.) One would think a cleaner solution could
> > be found, working _with_ ExtUtils::MakeMaker instead of against it.
[Philip Martin]
> So that removes RPATH from the shared objects in the build dir as
> well as the install dir? Do the tests still work?
Yes and yes, I think. The tests still work because the generated
Makefile sets LD_LIBRARY_PATH to that same long string.
> > Besides being crude, it uses sed -i, which works on my platform but
> > is not portable. (Portable is to redirect sed to a temp file and
> > then rename it to the original, which here would involve a shell
> > loop.)
>
> Since we must have perl
> $(PERL) -pi -e 's/..../'
> should be portable.
Heh, true enough. Anyway, editing a generated Makefile after the fact
seems pretty crude compared to just figuring out why ExtUtil::MakeMaker
puts that line in in the first place, and getting it to not do that.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: 1.7.0-beta1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
Peter Samuelson <pe...@p12n.org> writes:
> My patch is pretty crude, to Makefile.in:
>
> $(SWIG_PL_DIR)/native/Makefile: $(SWIG_PL_DIR)/native/Makefile.PL
> - cd $(SWIG_PL_DIR)/native; $(PERL) Makefile.PL
> + cd $(SWIG_PL_DIR)/native; \
> + $(PERL) Makefile.PL INSTALLDIRS=vendor; \
> + sed -i -e '/^LD_RUN_PATH/s/^/#/' Makefile Makefile.[a-z]*
>
> Basically it comments out the LD_RUN_PATH = ... line from the family of
> Makefiles. (Adding 'INSTALLDIRS=vendor' is also needed here, but is
> not part of the RPATH fix.) One would think a cleaner solution could
> be found, working _with_ ExtUtils::MakeMaker instead of against it.
So that removes RPATH from the shared objects in the build dir as well
as the install dir? Do the tests still work?
> Besides being crude, it uses sed -i, which works on my platform but is
> not portable. (Portable is to redirect sed to a temp file and then
> rename it to the original, which here would involve a shell loop.)
Since we must have perl
$(PERL) -pi -e 's/..../'
should be portable.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-beta1 up for testing / signing
Posted by Peter Samuelson <pe...@p12n.org>.
[Philip Martin]
> The perl bindings are really confusing. Start from scratch:
>
> configure
> make
> make swig-pl
> make check-swig-pl # PASS
> make clean-swig-pl
> make swig-pl
> make check-swig-pl # FAIL
>
> It was that FAIL after the rebuild that was confusing me. I get the
> same thing in 1.6 so this is not a regression.
>
> So r1037358 is not a problem, it's simply that when I reverted it I also
> manually removed enough of the perl build that my environment got back
> to the state in which the tests would PASS the first time.
Good to hear! I was very very puzzled at what r1037358 had done wrong,
there - I felt some responsibility since it was my patch.
Don't know what to make of 'clean-swig-pl' breaking things. I might
try to reproduce that some time and see if I can figure it out.
> >> $ objdump -x /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so | grep RPATH
> > I think that's been the case for a long time. I actually have a
> > patch in the Debian build specifically to work around this, dating
> > from ages and ages ago.
>
> Should we put this patch into Subversion?
My patch is pretty crude, to Makefile.in:
$(SWIG_PL_DIR)/native/Makefile: $(SWIG_PL_DIR)/native/Makefile.PL
- cd $(SWIG_PL_DIR)/native; $(PERL) Makefile.PL
+ cd $(SWIG_PL_DIR)/native; \
+ $(PERL) Makefile.PL INSTALLDIRS=vendor; \
+ sed -i -e '/^LD_RUN_PATH/s/^/#/' Makefile Makefile.[a-z]*
Basically it comments out the LD_RUN_PATH = ... line from the family of
Makefiles. (Adding 'INSTALLDIRS=vendor' is also needed here, but is
not part of the RPATH fix.) One would think a cleaner solution could
be found, working _with_ ExtUtils::MakeMaker instead of against it.
Besides being crude, it uses sed -i, which works on my platform but is
not portable. (Portable is to redirect sed to a temp file and then
rename it to the original, which here would involve a shell loop.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: 1.7.0-beta1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
Peter Samuelson <pe...@p12n.org> writes:
> [Philip Martin]
>> I'm seeing the same thing, reverting r1037358 appears to be enough to
>> make the tests run.
>
> Did you run 'perl Makefile.PL' in subversion/bindings/swig/perl/native
> _before_, or _after_, the main build? It matters.
>
> If you run it _before_ the main build, the pre-r1037358 will produce a
> bunch of empty -L flags. I fixed that in r1037358, so they get the
> directories they apparently were supposed to have attached.
>
> If you run it _after_ the main build, r1037358 makes almost no
> difference. The only difference I see is a ${LD_LIBRARY_PATH} has been
> changed to $(LD_LIBRARY_PATH). Should be equivalent.
>
>
> Thus I conclude that you probably ran it _before_ the main build, and
> that somehow all those -L flags that the previous code did not pick up
> but the current code does, are breaking your testsuite run. Could you
> post the generated 'obj-1.7/subversion/bindings/perl/native/Makefile'
> with and without r1037358 in the source? (You can regenerate the
> Makefile.PL by running ./config.status in obj-1.7/.)
The perl bindings are really confusing. Start from scratch:
configure
make
make swig-pl
make check-swig-pl # PASS
make clean-swig-pl
make swig-pl
make check-swig-pl # FAIL
It was that FAIL after the rebuild that was confusing me. I get the
same thing in 1.6 so this is not a regression.
So r1037358 is not a problem, it's simply that when I reverted it I also
manually removed enough of the perl build that my environment got back
to the state in which the tests would PASS the first time.
>> It's not clear that that is enough, the installed
>> shared objects still refer to the build directory:
>>
>> $ objdump -x /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so | grep RPATH
>> RPATH /home/pm/sw/subversion/obj-1.7/subversion/libsvn_client/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_ra/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_wc/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_diff/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_subr/.libs:/home/pm/sw/subversion/obj-1.7/subversion/bindings/swig/perl/libsvn_swig_perl/.libs
>
> I think that's been the case for a long time. I actually have a patch
> in the Debian build specifically to work around this, dating from ages
> and ages ago.
Should we put this patch into Subversion?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-beta1 up for testing / signing
Posted by Peter Samuelson <pe...@p12n.org>.
[Philip Martin]
> I'm seeing the same thing, reverting r1037358 appears to be enough to
> make the tests run.
Did you run 'perl Makefile.PL' in subversion/bindings/swig/perl/native
_before_, or _after_, the main build? It matters.
If you run it _before_ the main build, the pre-r1037358 will produce a
bunch of empty -L flags. I fixed that in r1037358, so they get the
directories they apparently were supposed to have attached.
If you run it _after_ the main build, r1037358 makes almost no
difference. The only difference I see is a ${LD_LIBRARY_PATH} has been
changed to $(LD_LIBRARY_PATH). Should be equivalent.
Thus I conclude that you probably ran it _before_ the main build, and
that somehow all those -L flags that the previous code did not pick up
but the current code does, are breaking your testsuite run. Could you
post the generated 'obj-1.7/subversion/bindings/perl/native/Makefile'
with and without r1037358 in the source? (You can regenerate the
Makefile.PL by running ./config.status in obj-1.7/.)
> It's not clear that that is enough, the installed
> shared objects still refer to the build directory:
>
> $ objdump -x /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so | grep RPATH
> RPATH /home/pm/sw/subversion/obj-1.7/subversion/libsvn_client/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_ra/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_wc/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_diff/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_subr/.libs:/home/pm/sw/subversion/obj-1.7/subversion/bindings/swig/perl/libsvn_swig_perl/.libs
I think that's been the case for a long time. I actually have a patch
in the Debian build specifically to work around this, dating from ages
and ages ago.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: 1.7.0-beta1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> I've wrapped up testing of the beta1 tarball. All the tests pass for me
> except the Perl bindings tests. They seem to build fine (albeit with the
> typical slew of warnings). They seem to install fine. But the tests fail
> immediately:
>
> [...]
> # Error: Can't load
> '/home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/arch/auto/SVN/_Repos/_Repos.so'
> for module SVN::_Repos:
> /home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/arch/auto/SVN/_Repos/_Repos.so:
> undefined symbol: svn_swig_pl_thunk_history_func at
> /usr/lib/perl/5.10/DynaLoader.pm line 193.
> # at
> /home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/lib/SVN/Base.pm
> line 59
> [...]
Gah! I ran the tests but forgot to check whether or not they passed!
I'm seeing the same thing, reverting r1037358 appears to be enough to
make the tests run. It's not clear that that is enough, the installed
shared objects still refer to the build directory:
$ objdump -x /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so | grep RPATH
RPATH /home/pm/sw/subversion/obj-1.7/subversion/libsvn_client/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_delta/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_fs/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_ra/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_repos/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_wc/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_diff/.libs:/home/pm/sw/subversion/obj-1.7/subversion/libsvn_subr/.libs:/home/pm/sw/subversion/obj-1.7/subversion/bindings/swig/perl/libsvn_swig_perl/.libs
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-beta1 up for testing / signing
Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> (You might want to get affirmation from Philip that his +1 to release stands.)
Yes, +1 to release.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: 1.7.0-beta1 up for testing / signing
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/15/2011 02:36 PM, Hyrum K Wright wrote:
> Is this relatived to the problem that Philip and Peter have discussed
> elsewhere in this thread? If so, it's sounds like a longstanding one
> that isn't a regression from 1.6 or prior 1.7.0 prereleases. We're
> only 1 *nix sig short of a bushel. :)
Yes, I believe it is related.
(You might want to get affirmation from Philip that his +1 to release stands.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.7.0-beta1 up for testing / signing
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Thu, Jul 14, 2011 at 5:09 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 07/13/2011 04:29 PM, Hyrum K Wright wrote:
>> All,
>>
>> Our first prerelease from the 1.7.x branch is now up for testing and
>> signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
>> in the release scripts doesn't include that rev in the header file).
>> You can find the tarballs here:
>> http://people.apache.org/~hwright/svn/1.7.0-beta1/
>
> I've wrapped up testing of the beta1 tarball. All the tests pass for me
> except the Perl bindings tests. They seem to build fine (albeit with the
> typical slew of warnings). They seem to install fine. But the tests fail
> immediately:
>
> [...]
> # Error: Can't load
> '/home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/arch/auto/SVN/_Repos/_Repos.so'
> for module SVN::_Repos:
> /home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/arch/auto/SVN/_Repos/_Repos.so:
> undefined symbol: svn_swig_pl_thunk_history_func at
> /usr/lib/perl/5.10/DynaLoader.pm line 193.
> # at
> /home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/lib/SVN/Base.pm
> line 59
> [...]
>
> I can see this at the shell myself, too:
>
> $ perl
> use SVN::Repos;
> Can't load '/usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so' for module
> SVN::_Repos: /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so: undefined
> symbol: svn_swig_pl_thunk_history_func at /usr/lib/perl/5.10/DynaLoader.pm
> line 193.
> at /usr/local/lib/perl/5.10.1/SVN/Base.pm line 59
> BEGIN failed--compilation aborted at /usr/local/lib/perl/5.10.1/SVN/Repos.pm
> line 5.
> Compilation failed in require at - line 1.
> BEGIN failed--compilation aborted at - line 1.
> $
>
> I notice that when I run 'ldd' on the bits installed into
> /usr/local/lib/perl, they seem to be linking against the libraries in my
> build directory, not the install locations.
Mike,
Is this relatived to the problem that Philip and Peter have discussed
elsewhere in this thread? If so, it's sounds like a longstanding one
that isn't a regression from 1.6 or prior 1.7.0 prereleases. We're
only 1 *nix sig short of a bushel. :)
-Hyrum
Re: 1.7.0-beta1 up for testing / signing
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/13/2011 04:29 PM, Hyrum K Wright wrote:
> All,
>
> Our first prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta1. The magic revision is r1146221 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can find the tarballs here:
> http://people.apache.org/~hwright/svn/1.7.0-beta1/
I've wrapped up testing of the beta1 tarball. All the tests pass for me
except the Perl bindings tests. They seem to build fine (albeit with the
typical slew of warnings). They seem to install fine. But the tests fail
immediately:
[...]
# Error: Can't load
'/home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/arch/auto/SVN/_Repos/_Repos.so'
for module SVN::_Repos:
/home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/arch/auto/SVN/_Repos/_Repos.so:
undefined symbol: svn_swig_pl_thunk_history_func at
/usr/lib/perl/5.10/DynaLoader.pm line 193.
# at
/home/cmpilato/tmp/subversion-1.7.0-beta1/subversion/bindings/swig/perl/native/blib/lib/SVN/Base.pm
line 59
[...]
I can see this at the shell myself, too:
$ perl
use SVN::Repos;
Can't load '/usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so' for module
SVN::_Repos: /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so: undefined
symbol: svn_swig_pl_thunk_history_func at /usr/lib/perl/5.10/DynaLoader.pm
line 193.
at /usr/local/lib/perl/5.10.1/SVN/Base.pm line 59
BEGIN failed--compilation aborted at /usr/local/lib/perl/5.10.1/SVN/Repos.pm
line 5.
Compilation failed in require at - line 1.
BEGIN failed--compilation aborted at - line 1.
$
I notice that when I run 'ldd' on the bits installed into
/usr/local/lib/perl, they seem to be linking against the libraries in my
build directory, not the install locations.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand