You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gavin Baumanis <ga...@thespidernet.com> on 2009/11/09 03:18:42 UTC
Subversion test results.
Hi Everyone,
I have finally managed to compile Subversion on my Mac - wahoo for me!
It took 50 minutes to compile simply using ./configure;make;make
install;
Is this "about" normal? - not ever having compiled it before I have no
point of reference for whether this is a long time or not.
Also, I ran the tests for the sake of curiosity and noticed quite a
few errors reported.
I have included the results - below and I have the following few
questions please;
The summary says that only 5 tests failed, but there are most
certainly more than 5 failures listed.
So why is there is a discrepancy, and which of these two outputs
should I believe?
And while I do recall specific "test failures" mentioned at times
within the dev mailing list;
Is there a "protocol" to follow if you notice a test failure?
I guess it is going to be an experience "thing" - but how do you know
what test failures are important and which aren't?
Or is it a case of they're all important?
Anyhoo, thanks!
Gavin.
Running all tests in auth-test [1/77]...................success
Running all tests in cache-test [2/77]..................success
Running all tests in checksum-test [3/77]...............success
Running all tests in client-test [4/77].................success
Running all tests in compat-test [5/77].................success
Running all tests in config-test [6/77].................success
Running all tests in db-test [7/77].....................success
Running all tests in diff-diff3-test [8/77].............FAILURE
Running all tests in dirent_uri-test [9/77].............success
Running all tests in eol-test [10/77]...................success
Running all tests in error-test [11/77].................success
Running all tests in fs-pack-test [12/77]...............FAILURE
Running all tests in fs-test [13/77]....................FAILURE
Running all tests in hashdump-test [14/77]..............success
Running all tests in locks-test [15/77].................FAILURE
Running all tests in mergeinfo-test [16/77].............success
Running all tests in opt-test [17/77]...................success
Running all tests in parse-diff-test [18/77]............success
Running all tests in path-test [19/77]..................success
Running all tests in ra-local-test [20/77]..............success
Running all tests in random-test [21/77]................success
Running all tests in repos-test [22/77].................FAILURE
Running all tests in revision-test [23/77]..............success
Running all tests in skel-test [24/77]..................success
Running all tests in stream-test [25/77]................success
Running all tests in string-test [26/77]................success
Running all tests in target-test [27/77]................success
Running all tests in time-test [28/77]..................success
Running all tests in translate-test [29/77].............success
Running all tests in tree-conflict-data-test [30/77]....success
Running all tests in utf-test [31/77]...................success
Running all tests in window-test [32/77]................success
Running all tests in authz_tests.py [33/77].............FAILURE
Running all tests in autoprop_tests.py [34/77]..........FAILURE
Running all tests in basic_tests.py [35/77].............FAILURE
Running all tests in blame_tests.py [36/77].............FAILURE
Running all tests in cat_tests.py [37/77]...............FAILURE
Running all tests in changelist_tests.py [38/77]........FAILURE
Running all tests in checkout_tests.py [39/77]..........FAILURE
Running all tests in commit_tests.py [40/77]............FAILURE
Running all tests in copy_tests.py [41/77]..............FAILURE
Running all tests in depth_tests.py [42/77].............FAILURE
Running all tests in diff_tests.py [43/77]..............FAILURE
Running all tests in entries_tests.py [44/77]...........FAILURE
Running all tests in export_tests.py [45/77]............FAILURE
Running all tests in externals_tests.py [46/77].........FAILURE
Running all tests in getopt_tests.py [47/77]............FAILURE
Running all tests in history_tests.py [48/77]...........FAILURE
Running all tests in import_tests.py [49/77]............FAILURE
Running all tests in info_tests.py [50/77]..............FAILURE
Running all tests in lock_tests.py [51/77]..............FAILURE
Running all tests in log_tests.py [52/77]...............FAILURE
Running all tests in merge_authz_tests.py [53/77].......FAILURE
Running all tests in merge_tests.py [54/77].............FAILURE
Running all tests in mergeinfo_tests.py [55/77].........FAILURE
Running all tests in patch_tests.py [56/77].............FAILURE
Running all tests in prop_tests.py [57/77]..............FAILURE
Running all tests in resolved_tests.py [58/77]..........FAILURE
Running all tests in revert_tests.py [59/77]............FAILURE
Running all tests in schedule_tests.py [60/77]..........FAILURE
Running all tests in special_tests.py [61/77]...........FAILURE
Running all tests in stat_tests.py [62/77]..............FAILURE
Running all tests in svnadmin_tests.py [63/77]..........FAILURE
Running all tests in svndumpfilter_tests.py [64/77].....FAILURE
Running all tests in svnlook_tests.py [65/77]...........FAILURE
Running all tests in svnsync_tests.py [66/77]...........FAILURE
Running all tests in svnversion_tests.py [67/77]........FAILURE
Running all tests in switch_tests.py [68/77]............FAILURE
Running all tests in trans_tests.py [69/77].............FAILURE
Running all tests in tree_conflict_tests.py [70/77].....FAILURE
Running all tests in update_tests.py [71/77]............FAILURE
Running all tests in upgrade_tests.py [72/77]...........FAILURE
Running all tests in utf8_tests.py [73/77]..............FAILURE
Running all tests in changes-test [74/77]...............success
Running all tests in fs-base-test [75/77]...............success
Running all tests in key-test [76/77]...................success
Running all tests in strings-reps-test [77/77]..........success
At least one test was SKIPPED, checking /Users/beau/SUBVERSION/svn-src/
tests.log
SKIP: cache-test 2: basic memcache svn_cache test
SKIP: cache-test 3: memcache svn_cache with very long keys
At least one test XFAILED, checking /Users/beau/SUBVERSION/svn-src/
tests.log
XFAIL: tree-conflict-data-test 3: detect broken tree conflict data
At least one test FAILED, checking /Users/beau/SUBVERSION/svn-src/
tests.log
FAIL: diff-diff3-test: Unknown test failure; see tests.log.
FAIL: fs-pack-test: Unknown test failure; see tests.log.
FAIL: fs-test: Unknown test failure; see tests.log.
FAIL: locks-test: Unknown test failure; see tests.log.
FAIL: repos-test: Unknown test failure; see tests.log.
Summary of test results:
233 tests PASSED
2 tests SKIPPED
1 test XFAILED
5 tests FAILED
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415659
Re: Subversion test results.
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Nov 9, 2009, at 2:51 PM, Gavin Baumanis wrote:
> There are no errors when I run /.configure and it seems to find all
> the mandatory dependancies and a few non-mandatories, too.
> There are no warnngs / errors.
>
> There are a few warning about functions being deprecated, Eg.;
> subversion/libsvn_ra/compat.c: In function ‘prev_log_path’:
> subversion/libsvn_ra/compat.c:163: warning: ‘svn_path_join’ is
> deprecated (declared at ./subversion/include/svn_path.h:108)
>
> and this block that I have no idea about;
>
> ranlib: file: .libs/libsvn_subr-1.a(config_win.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(debug.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(win32_crashrpt.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(win32_crypto.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(win32_xlate.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(config_win.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(debug.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(win32_crashrpt.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(win32_crypto.o) has no symbols
> ranlib: file: .libs/libsvn_subr-1.a(win32_xlate.o) has no symbols
You aren't building on windows, so all these files are essentially
#ifdef'd out. After the preprocessor run, they look like empty files
to the compiler. The linker complains about the fact that you're
linking files with essentially no code in them. I get the same
warnings.
-Hyrum
> Otherwise make "seems" to run fine and dandy.
> And I am not too sure why the difference... but it took only a few
> minutes this time around for make and make install to complete.
>
> I "assume" that it is because "other stuff" is now compile that
> previously wan't? But I thought that was all taken care of when they
> libraries were installed via macports...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415905
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
There are no errors when I run /.configure and it seems to find all
the mandatory dependancies and a few non-mandatories, too.
There are no warnngs / errors.
There are a few warning about functions being deprecated, Eg.;
subversion/libsvn_ra/compat.c: In function ‘prev_log_path’:
subversion/libsvn_ra/compat.c:163: warning: ‘svn_path_join’ is
deprecated (declared at ./subversion/include/svn_path.h:108)
and this block that I have no idea about;
ranlib: file: .libs/libsvn_subr-1.a(config_win.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(debug.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crashrpt.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crypto.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_xlate.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(config_win.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(debug.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crashrpt.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crypto.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_xlate.o) has no symbols
Otherwise make "seems" to run fine and dandy.
And I am not too sure why the difference... but it took only a few
minutes this time around for make and make install to complete.
I "assume" that it is because "other stuff" is now compile that
previously wan't? But I thought that was all taken care of when they
libraries were installed via macports...
Gavin.
On 09/11/2009, at 23:22 , Julian Foad wrote:
> Gavin Baumanis wrote:
>> I have finally managed to compile Subversion on my Mac - wahoo for
>> me!
>
> Great!
>
>> It took 50 minutes to compile simply using ./configure;make;make
>> install;
>> Is this "about" normal? - not ever having compiled it before I have
>> no
>> point of reference for whether this is a long time or not.
>
> I haven't tried it on a Mac but that sounds very long. It takes my
> machine less than 5 minutes.
>
>> The summary says that only 5 tests failed, but there are most
>> certainly more than 5 failures listed.
>> So why is there is a discrepancy, and which of these two outputs
>> should I believe?
>
> Ah, that's a bug in the test suite: all of your Python test files are
> completely failing to run, and for each of those the test suite prints
> "authz_tests.py [33/77].............FAILURE", but it doesn't count
> that
> failure in the summary.
>
> I'll post a patch to try to fix that.
>
>> And while I do recall specific "test failures" mentioned at times
>> within the dev mailing list;
>> Is there a "protocol" to follow if you notice a test failure?
>>
>> I guess it is going to be an experience "thing" - but how do you know
>> what test failures are important and which aren't?
>> Or is it a case of they're all important?
>
> They are all important. The project policy is for all tests to be
> passing (or marked XFAIL etc) at all times. When there is a failure,
> it
> is usually your local mods or your local set-up that are the problem.
> Sometimes there are a few failures that are hard to debug and exist
> for
> up to a few weeks, but we try hard to avoid that because it makes
> everyone's life difficult because then they don't know whether
> failures
> are their fault or not.
>
> So you need to look for the cause of your failures. Start with either
> the first C test that fails or the first Python test that fails,
> depending on which you are more comfortable with debugging. For the
> Python tests, look in "tests.log" which was created by running the
> test
> suite, or run an individual test in "verbose" mode:
>
> cd subversion/tests/cmdline
> ./authz_tests.py 1 --verbose
>
> First, you should probably look through the output of "./configure"
> and
> see if there were any failures or warnings there, because maybe part
> of
> your build failed.
>
> - Julian
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415764
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415904
Re: Subversion test results.
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Sun, 15 Nov 2009 at 17:37 +0100:
> On Sat, Nov 14, 2009 at 11:09:44AM +1100, Gavin Baumanis wrote:
> > #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
> > 2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
> > (gdb) p *rep
> > $1 = {
> > md5_checksum = 0x1008858f8,
> > sha1_checksum = 0x0,
> > revision = 0,
> > offset = 0,
> > size = 4,
> > expanded_size = 4,
> > txn_id = 0x0,
> > uniquifier = 0x0
>
> The uniquifier is allowed to be NULL, but I don't know under which
> conditions (the API docs don't say, I haven't checked the code yet).
Don't know.
> I don't know about the sha1 checksum, is this allowed to be NULL?
>
Yes, for backward compatibility. The sha1 is only present in newer
revisions.
> Stefan
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418169
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418207
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Brane,
Thanks. I never knew about the head -1. (You can ;earn something new everyday - if you try!)
It does indeed point /bin/sh
I am just making autogen and it's dependencies now.
I will report back and let you all know if it is now working or not.
Gavin.
On 16/11/2009, at 07:43 , Branko Čibej wrote:
> Gavin Baumanis wrote:
>> Hi again,
>>
>> Just to be sue I downloaded libtool 1.4.3 and installed it.
>>
>> yet when attempting to compile apr I still get
>> the following error when using make;
>> /bin/sh: LIBTOOL@: command not found
>>
>
> Did you happen do re-run autogen and configure after installing the new
> libtool? The above indicated that you have an unexpanded @LIBTOOL@
> placeholder in your makefile.
>
>> make[1]: *** [passwd/apr_getpass.lo] Error 127
>> make: *** [all-recursive] Error 1
>>
>> Am I reading that right?
>> Is it looking for libtool in /bin/sh?
>> or is that something else?
>>
>
> Try:
>
> head -1 `which libtool`
>
> It might surprise you.
>
> -- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418218
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Everyone;
I thought I would start new some threads about the few remaining questions I have about building Subversion and I thought I would clear up the original intent of this one.
Using the MacPorts install of APR and APR-UTIL causes unknown (to me ) errors within Subversion.
Subversion compiles / builds correctly without error, yet the test-suite reports many errors which have been attached to a previous message in this thread.
Despite my enthusiasm, I do not have the knowledge to evaluate or fix the MacPorts induced errors - but will happily volunteer my machine and time to assist in finding out. If someone takes on the task and needs an appropriate machine to test on.
After having built apr and apr-util manually from ASF (released) source code, I can successfully compiler / install Subversion.
The test suite reports;
Summary of test results:
1148 tests PASSED
28 tests SKIPPED
42 tests XFAILED (2 WORK-IN-PROGRESS)
Gavin.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418325
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi everyone (again),
I have moved along a little in the process of getting Subversion compiled on my mac with snow leopard. (Mac OS X 10.6.2)
I have installed all dependencies prior to apr.
I have successfully build apr
I "thought" I had successfully built apr-util with berkeley-db via the following;
./buildconf
./configure --with-apr=/path/to/apr/sourcecode/ --with-berkeley-db=/usr/local/BerkeleyDB.4.8/<br />
make
sudo make install
sudo make check of apr-util provides the following output;
Loaded odbc driver OK.
[Mon Nov 16 13:49:35 2009] [dbd_odbc] SQLConnect returned SQL_ERROR (-1) at dbd/apr_dbd_odbc.c:1076 [iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded IM002
Failed to open odbc[]
And subsequently, when I do a configure of Subversion it creates a makefile without berkeley db support.
DO I need to "something" to enable berkley-db to be built within apr-util?
I.e. Is there a daemon I need to start?
All I have done at this stage is install it.
As always - thanks again,
Gavin.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418315
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Thanks (again!) Brane,
I have compiled successfully apr and apr-util.
I am now trying to compile the other dependencies
at the moment I am trying to compile neon
I have run;
./autogen.sh
./configure
make
however make reports the following.
../libtool: line 647: : warning: cannot infer operation mode without MODE-ARGS: command not found
../libtool: line 5238: : you must specify a MODE: command not found
and eventually errors out.
Gavin.
(I do realise the issues I am having are not subversion issues - as such.... but I never thought it would have been this difficult!)
Oh and while I think of it, I will provide a patch to INSTALL once I get it all going for installing SVN on mac os x.
On 16/11/2009, at 08:42 , Branko Cibej wrote:
> Branko Čibej wrote:
>> Gavin 'Beau' Baumanis wrote:
>>
>>> You'll have to excuse my "newbie" questions...
>>>
>>> But is there anything I need to pass to autogen?
>>>
>>> Because I ran it in the root of the apr source files ~/SUBVERSION/BUILD/apr/
>>>
>>>
>>
>> You have to run Subversion's autogen, not APR's autogen.
>>
>
> Let me clarify ... APR does not have an autigen.sh; it has a buildconf.
> IIRC our autogen does not run APR's buildconf. So, if you have a
> checked-out APR, you have to run buildconf from APR's source directory.
> If you got APR from a released tarball -- a simple check is if APR's
> configure script exists -- then you don't have to run buildconf.
>
> Subversion's autogen.sh must be run from the top of the Subversion
> source tree,and does not require parameters (through it has some
> optional ones).
>
> -- Brane
>
>>
>>> And it has just been sitting there for the past four minutes, seemingly not doing a lot - and had provided no feedback at all.
>>> I don't know if this is normal or otherwise.
>>>
>>> Gavin.
>>>
>>>
>>> On 16/11/2009, at 07:43 , Branko Čibej wrote:
>>>
>>>
>>>
>>>> Gavin Baumanis wrote:
>>>>
>>>>
>>>>> Hi again,
>>>>>
>>>>> Just to be sue I downloaded libtool 1.4.3 and installed it.
>>>>>
>>>>> yet when attempting to compile apr I still get
>>>>> the following error when using make;
>>>>> /bin/sh: LIBTOOL@: command not found
>>>>>
>>>>>
>>>>>
>>>> Did you happen do re-run autogen and configure after installing the new
>>>> libtool? The above indicated that you have an unexpanded @LIBTOOL@
>>>> placeholder in your makefile.
>>>>
>>>>
>>>>
>>>>> make[1]: *** [passwd/apr_getpass.lo] Error 127
>>>>> make: *** [all-recursive] Error 1
>>>>>
>>>>> Am I reading that right?
>>>>> Is it looking for libtool in /bin/sh?
>>>>> or is that something else?
>>>>>
>>>>>
>>>>>
>>>> Try:
>>>>
>>>> head -1 `which libtool`
>>>>
>>>> It might surprise you.
>>>>
>>>> -- Brane
>>>>
>>>>
>>>
>>>
>>
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418230
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418253
Re: Subversion test results.
Posted by Branko Cibej <br...@xbc.nu>.
Branko Čibej wrote:
> Gavin 'Beau' Baumanis wrote:
>
>> You'll have to excuse my "newbie" questions...
>>
>> But is there anything I need to pass to autogen?
>>
>> Because I ran it in the root of the apr source files ~/SUBVERSION/BUILD/apr/
>>
>>
>
> You have to run Subversion's autogen, not APR's autogen.
>
Let me clarify ... APR does not have an autigen.sh; it has a buildconf.
IIRC our autogen does not run APR's buildconf. So, if you have a
checked-out APR, you have to run buildconf from APR's source directory.
If you got APR from a released tarball -- a simple check is if APR's
configure script exists -- then you don't have to run buildconf.
Subversion's autogen.sh must be run from the top of the Subversion
source tree,and does not require parameters (through it has some
optional ones).
-- Brane
>
>> And it has just been sitting there for the past four minutes, seemingly not doing a lot - and had provided no feedback at all.
>> I don't know if this is normal or otherwise.
>>
>> Gavin.
>>
>>
>> On 16/11/2009, at 07:43 , Branko Čibej wrote:
>>
>>
>>
>>> Gavin Baumanis wrote:
>>>
>>>
>>>> Hi again,
>>>>
>>>> Just to be sue I downloaded libtool 1.4.3 and installed it.
>>>>
>>>> yet when attempting to compile apr I still get
>>>> the following error when using make;
>>>> /bin/sh: LIBTOOL@: command not found
>>>>
>>>>
>>>>
>>> Did you happen do re-run autogen and configure after installing the new
>>> libtool? The above indicated that you have an unexpanded @LIBTOOL@
>>> placeholder in your makefile.
>>>
>>>
>>>
>>>> make[1]: *** [passwd/apr_getpass.lo] Error 127
>>>> make: *** [all-recursive] Error 1
>>>>
>>>> Am I reading that right?
>>>> Is it looking for libtool in /bin/sh?
>>>> or is that something else?
>>>>
>>>>
>>>>
>>> Try:
>>>
>>> head -1 `which libtool`
>>>
>>> It might surprise you.
>>>
>>> -- Brane
>>>
>>>
>>
>>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418230
Re: Subversion test results.
Posted by Branko Cibej <br...@xbc.nu>.
Gavin 'Beau' Baumanis wrote:
> You'll have to excuse my "newbie" questions...
>
> But is there anything I need to pass to autogen?
>
> Because I ran it in the root of the apr source files ~/SUBVERSION/BUILD/apr/
>
You have to run Subversion's autogen, not APR's autogen.
> And it has just been sitting there for the past four minutes, seemingly not doing a lot - and had provided no feedback at all.
> I don't know if this is normal or otherwise.
>
> Gavin.
>
>
> On 16/11/2009, at 07:43 , Branko Čibej wrote:
>
>
>> Gavin Baumanis wrote:
>>
>>> Hi again,
>>>
>>> Just to be sue I downloaded libtool 1.4.3 and installed it.
>>>
>>> yet when attempting to compile apr I still get
>>> the following error when using make;
>>> /bin/sh: LIBTOOL@: command not found
>>>
>>>
>> Did you happen do re-run autogen and configure after installing the new
>> libtool? The above indicated that you have an unexpanded @LIBTOOL@
>> placeholder in your makefile.
>>
>>
>>> make[1]: *** [passwd/apr_getpass.lo] Error 127
>>> make: *** [all-recursive] Error 1
>>>
>>> Am I reading that right?
>>> Is it looking for libtool in /bin/sh?
>>> or is that something else?
>>>
>>>
>> Try:
>>
>> head -1 `which libtool`
>>
>> It might surprise you.
>>
>> -- Brane
>>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418220
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
You'll have to excuse my "newbie" questions...
But is there anything I need to pass to autogen?
Because I ran it in the root of the apr source files ~/SUBVERSION/BUILD/apr/
And it has just been sitting there for the past four minutes, seemingly not doing a lot - and had provided no feedback at all.
I don't know if this is normal or otherwise.
Gavin.
On 16/11/2009, at 07:43 , Branko Čibej wrote:
> Gavin Baumanis wrote:
>> Hi again,
>>
>> Just to be sue I downloaded libtool 1.4.3 and installed it.
>>
>> yet when attempting to compile apr I still get
>> the following error when using make;
>> /bin/sh: LIBTOOL@: command not found
>>
>
> Did you happen do re-run autogen and configure after installing the new
> libtool? The above indicated that you have an unexpanded @LIBTOOL@
> placeholder in your makefile.
>
>> make[1]: *** [passwd/apr_getpass.lo] Error 127
>> make: *** [all-recursive] Error 1
>>
>> Am I reading that right?
>> Is it looking for libtool in /bin/sh?
>> or is that something else?
>>
>
> Try:
>
> head -1 `which libtool`
>
> It might surprise you.
>
> -- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418219
Re: Subversion test results.
Posted by Branko Cibej <br...@xbc.nu>.
Gavin Baumanis wrote:
> Hi again,
>
> Just to be sue I downloaded libtool 1.4.3 and installed it.
>
> yet when attempting to compile apr I still get
> the following error when using make;
> /bin/sh: LIBTOOL@: command not found
>
Did you happen do re-run autogen and configure after installing the new
libtool? The above indicated that you have an unexpanded @LIBTOOL@
placeholder in your makefile.
> make[1]: *** [passwd/apr_getpass.lo] Error 127
> make: *** [all-recursive] Error 1
>
> Am I reading that right?
> Is it looking for libtool in /bin/sh?
> or is that something else?
>
Try:
head -1 `which libtool`
It might surprise you.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418211
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi again,
Just to be sue I downloaded libtool 1.4.3 and installed it.
yet when attempting to compile apr I still get
the following error when using make;
/bin/sh: LIBTOOL@: command not found
make[1]: *** [passwd/apr_getpass.lo] Error 127
make: *** [all-recursive] Error 1
Am I reading that right?
Is it looking for libtool in /bin/sh?
or is that something else?
because libtool certainly doesn't live at that path.
[beau@MacBook:~/SUBVERSION/BUILD/apr] $which libtool
/usr/local/bin/libtool
(which according to libtool's INSTALL is where the default location is if I don;t specify a prefix - which I didn't.)
Gavin
On 16/11/2009, at 03:37 , Stefan Sperling wrote:
> On Sat, Nov 14, 2009 at 11:09:44AM +1100, Gavin Baumanis wrote:
>> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
>> 2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
>> (gdb) p *rep
>> $1 = {
>> md5_checksum = 0x1008858f8,
>> sha1_checksum = 0x0,
>> revision = 0,
>> offset = 0,
>> size = 4,
>> expanded_size = 4,
>> txn_id = 0x0,
>> uniquifier = 0x0
>
> The uniquifier is allowed to be NULL, but I don't know under which
> conditions (the API docs don't say, I haven't checked the code yet).
> I don't know about the sha1 checksum, is this allowed to be NULL?
>
> Stefan
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418169
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418209
Re: Subversion test results.
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Nov 14, 2009 at 11:09:44AM +1100, Gavin Baumanis wrote:
> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
> 2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
> (gdb) p *rep
> $1 = {
> md5_checksum = 0x1008858f8,
> sha1_checksum = 0x0,
> revision = 0,
> offset = 0,
> size = 4,
> expanded_size = 4,
> txn_id = 0x0,
> uniquifier = 0x0
The uniquifier is allowed to be NULL, but I don't know under which
conditions (the API docs don't say, I haven't checked the code yet).
I don't know about the sha1 checksum, is this allowed to be NULL?
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418169
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi again,
Just a quick update to this let you know that I downloaded 1.6.5 from s.t.o, just in case there was an issue with compiling trunk@head.
And I still get the same errors when I try to compile that version with the macports version of apr and apr-util.
It doesn't really prove anything much beyond, the issue seems to be compiling subversion, and not simply compiling trunk.
Re: Subversion test results.
Posted by Philip Martin <ph...@wandisco.com>.
Gavin Baumanis <ga...@thespidernet.com> writes:
> I have installed libtool
>
> And it is used during the process of compiling the other deps.
>
> That was my initial thought, but it is certainly present,
> ./buildconf finds it;
>
> [beau@MacBook:~/SUBVERSION/BUILD/apr] $./buildconf
> buildconf: checking installation...
> buildconf: python version 2.6.1 (ok)
> buildconf: autoconf version 2.64 (ok)
> buildconf: libtool version 2.2.4 (ok)
> Copying libtool helper files ...
> $_prefix/share/aclocal/libtool.m4 not found
libtool.m4 is part of libtool.
If you are building from tarballs then you don't need to run buildconf
or autgen.sh; the configure file already exists so just run that.
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418129
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Phillip,
I have installed libtool
And it is used during the process of compiling the other deps.
That was my initial thought, but it is certainly present,
./buildconf finds it;
[beau@MacBook:~/SUBVERSION/BUILD/apr] $./buildconf
buildconf: checking installation...
buildconf: python version 2.6.1 (ok)
buildconf: autoconf version 2.64 (ok)
buildconf: libtool version 2.2.4 (ok)
Copying libtool helper files ...
$_prefix/share/aclocal/libtool.m4 not found
On 15/11/2009, at 22:18 , Philip Martin wrote:
> Gavin Baumanis <ga...@thespidernet.com> writes:
>
>> for apr;
>> I get the following after ./buildconf
>> Copying libtool helper files ...
>> $_prefix/share/aclocal/libtool.m4 not found
>>
>> and during a ./configure;
>> performing libtool configuration...
>> ./configure: line 8485: AC_PROG_LIBTOOL: command not found
>>
>> and thus it refuses to make at all.
>>
>> If anyone has ideas, I'd be much appreciative.
>
> You need to install libtool.
>
> --
> Philip
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418124
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418128
Re: Subversion test results.
Posted by Philip Martin <ph...@wandisco.com>.
Gavin Baumanis <ga...@thespidernet.com> writes:
> for apr;
> I get the following after ./buildconf
> Copying libtool helper files ...
> $_prefix/share/aclocal/libtool.m4 not found
>
> and during a ./configure;
> performing libtool configuration...
> ./configure: line 8485: AC_PROG_LIBTOOL: command not found
>
> and thus it refuses to make at all.
>
> If anyone has ideas, I'd be much appreciative.
You need to install libtool.
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418124
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
OK,
I think I have a problem because of Macports.
I uninstalled all the macports, ports and redid;
./configure;make;make test
I still get a lot of failures but the diff one that was failing originally no longer does.
So I have downloaded the latest DEPS archive from s.t.o
I have successfully compiled neon / serf zlib and sqlite-amalgamation
but have an issue with apr and apr-util compiling from source.
I assume that the following errors are all linked (well am hoping they are, actually)
for apr;
I get the following after ./buildconf
Copying libtool helper files ...
$_prefix/share/aclocal/libtool.m4 not found
and during a ./configure;
performing libtool configuration...
./configure: line 8485: AC_PROG_LIBTOOL: command not found
and thus it refuses to make at all.
If anyone has ideas, I'd be much appreciative.
Gavin.
On 15/11/2009, at 10:09 , Gavin Baumanis wrote:
> Hi Philip,
> Soprry I missed that in your original mail;
>
> (gdb) up
> #1 0x0000000100519594 in apr_vformatter ()
> (gdb) up
> #2 0x000000010052343c in apr_pvsprintf ()
> (gdb) up
> #3 0x00000001005236db in apr_psprintf ()
> (gdb) up
> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
> 2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
> (gdb) p rep->md5_checksum[0]
> $1 = {
> digest = 0x100885908 "-)w??oHz?J\036 -?;N/",
> kind = svn_checksum_md5
> }
>
>
>
> On 14/11/2009, at 19:55 , Philip Martin wrote:
>
>> Gavin Baumanis <ga...@thespidernet.com> writes:
>>
>>> (gdb) up
>>> #1 0x0000000100519594 in apr_vformatter ()
>>> (gdb) up
>>> #2 0x000000010052343c in apr_pvsprintf ()
>>> (gdb) up
>>> #3 0x00000001005236db in apr_psprintf ()
>>> (gdb) up
>>> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
>>> 2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
>>> (gdb) p *rep
>>> $1 = {
>>> md5_checksum = 0x1008858f8,
>>> sha1_checksum = 0x0,
>>> revision = 0,
>>> offset = 0,
>>> size = 4,
>>> expanded_size = 4,
>>> txn_id = 0x0,
>>> uniquifier = 0x0
>>> }
>>
>> Please do:
>> (gdb) p rep->md5_checksum[0]
>>
>> --
>> Philip
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417882
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418035
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418067
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Philip,
Soprry I missed that in your original mail;
(gdb) up
#1 0x0000000100519594 in apr_vformatter ()
(gdb) up
#2 0x000000010052343c in apr_pvsprintf ()
(gdb) up
#3 0x00000001005236db in apr_psprintf ()
(gdb) up
#4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
(gdb) p rep->md5_checksum[0]
$1 = {
digest = 0x100885908 "-)w??oHz?J\036 -?;N/",
kind = svn_checksum_md5
}
On 14/11/2009, at 19:55 , Philip Martin wrote:
> Gavin Baumanis <ga...@thespidernet.com> writes:
>
>> (gdb) up
>> #1 0x0000000100519594 in apr_vformatter ()
>> (gdb) up
>> #2 0x000000010052343c in apr_pvsprintf ()
>> (gdb) up
>> #3 0x00000001005236db in apr_psprintf ()
>> (gdb) up
>> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
>> 2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
>> (gdb) p *rep
>> $1 = {
>> md5_checksum = 0x1008858f8,
>> sha1_checksum = 0x0,
>> revision = 0,
>> offset = 0,
>> size = 4,
>> expanded_size = 4,
>> txn_id = 0x0,
>> uniquifier = 0x0
>> }
>
> Please do:
> (gdb) p rep->md5_checksum[0]
>
> --
> Philip
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417882
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418035
Re: Subversion test results.
Posted by Philip Martin <ph...@wandisco.com>.
Gavin Baumanis <ga...@thespidernet.com> writes:
> (gdb) up
> #1 0x0000000100519594 in apr_vformatter ()
> (gdb) up
> #2 0x000000010052343c in apr_pvsprintf ()
> (gdb) up
> #3 0x00000001005236db in apr_psprintf ()
> (gdb) up
> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
> 2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
> (gdb) p *rep
> $1 = {
> md5_checksum = 0x1008858f8,
> sha1_checksum = 0x0,
> revision = 0,
> offset = 0,
> size = 4,
> expanded_size = 4,
> txn_id = 0x0,
> uniquifier = 0x0
> }
Please do:
(gdb) p rep->md5_checksum[0]
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417882
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Firstly - a big thanks Philip and Stefan for your help.
I can certainly run any command that you request and send you back the results - but please realise that I genuinely have no idea what you're talking about - so you might need to be a little more thorough in your explanations.
Anyway,
using (gdb) up I got to the line : #4 0x00000001001e94ae in representation_string - and ran the command you requested Stefan. The output is below;
(gdb) up
#1 0x0000000100519594 in apr_vformatter ()
(gdb) up
#2 0x000000010052343c in apr_pvsprintf ()
(gdb) up
#3 0x00000001005236db in apr_psprintf ()
(gdb) up
#4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
2163 return apr_psprintf(pool, "%ld %" APR_OFF_T_FMT " %" SVN_FILESIZE_T_FMT
(gdb) p *rep
$1 = {
md5_checksum = 0x1008858f8,
sha1_checksum = 0x0,
revision = 0,
offset = 0,
size = 4,
expanded_size = 4,
txn_id = 0x0,
uniquifier = 0x0
}
On 13/11/2009, at 22:08 , Stefan Sperling wrote:
> On Fri, Nov 13, 2009 at 09:26:43AM +0000, Philip Martin wrote:
>> Gavin Baumanis <ga...@thespidernet.com> writes:
>>
>>> #0 0x00007fff86704cc0 in strlen ()
>>> #1 0x0000000100519594 in apr_vformatter ()
>>> #2 0x000000010052343c in apr_pvsprintf ()
>>> #3 0x00000001005236db in apr_psprintf ()
>>> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
>>> #5 0x00000001001e9763 in svn_fs_fs__write_noderev (outfile=0x100888e48, noderev=0x100885800, format=4, include_mergeinfo=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2206
>>
>> In gdb you move up or down the stack using 'up' or 'down', and you
>> print variables using 'p', so
>> (gdb) up
>> (gdb) up
>> (gdb) up
>> (gdb) up
>> (gdb) p rep->md5_checksum[0]
>>
>> I'm guessing that something has gone wrong with the checksum
>> calculation and svn_checksum_to_cstring_display is returning NULL.
>
> This same segfault was recently reported in #svn, great that someone
> with debug symbols can reproduce it.
>
> I'd be interested in:
> (gdb) p *rep
> within the 'representation_string' function frame.
>
> Thanks,
> Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417802
Re: Subversion test results.
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Nov 13, 2009 at 09:26:43AM +0000, Philip Martin wrote:
> Gavin Baumanis <ga...@thespidernet.com> writes:
>
> > #0 0x00007fff86704cc0 in strlen ()
> > #1 0x0000000100519594 in apr_vformatter ()
> > #2 0x000000010052343c in apr_pvsprintf ()
> > #3 0x00000001005236db in apr_psprintf ()
> > #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
> > #5 0x00000001001e9763 in svn_fs_fs__write_noderev (outfile=0x100888e48, noderev=0x100885800, format=4, include_mergeinfo=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2206
>
> In gdb you move up or down the stack using 'up' or 'down', and you
> print variables using 'p', so
> (gdb) up
> (gdb) up
> (gdb) up
> (gdb) up
> (gdb) p rep->md5_checksum[0]
>
> I'm guessing that something has gone wrong with the checksum
> calculation and svn_checksum_to_cstring_display is returning NULL.
This same segfault was recently reported in #svn, great that someone
with debug symbols can reproduce it.
I'd be interested in:
(gdb) p *rep
within the 'representation_string' function frame.
Thanks,
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417508
Re: Subversion test results.
Posted by Philip Martin <ph...@wandisco.com>.
Gavin Baumanis <ga...@thespidernet.com> writes:
> #0 0x00007fff86704cc0 in strlen ()
> #1 0x0000000100519594 in apr_vformatter ()
> #2 0x000000010052343c in apr_pvsprintf ()
> #3 0x00000001005236db in apr_psprintf ()
> #4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
> #5 0x00000001001e9763 in svn_fs_fs__write_noderev (outfile=0x100888e48, noderev=0x100885800, format=4, include_mergeinfo=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2206
In gdb you move up or down the stack using 'up' or 'down', and you
print variables using 'p', so
(gdb) up
(gdb) up
(gdb) up
(gdb) up
(gdb) p rep->md5_checksum[0]
I'm guessing that something has gone wrong with the checksum
calculation and svn_checksum_to_cstring_display is returning NULL.
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417470
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi again Philip,
Here is the backtrace after recompiling with debug information.
#0 0x00007fff86704cc0 in strlen ()
#1 0x0000000100519594 in apr_vformatter ()
#2 0x000000010052343c in apr_pvsprintf ()
#3 0x00000001005236db in apr_psprintf ()
#4 0x00000001001e94ae in representation_string (rep=0x1008858b8, format=4, mutable_rep_truncated=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
#5 0x00000001001e9763 in svn_fs_fs__write_noderev (outfile=0x100888e48, noderev=0x100885800, format=4, include_mergeinfo=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2206
#6 0x00000001001e9c2c in svn_fs_fs__put_node_revision (fs=0x100871e30, id=0x100885928, noderev=0x100885800, fresh_txn_root=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2272
#7 0x00000001001eecf6 in create_new_txn_noderev_from_rev (fs=0x100871e30, txn_id=0x100884308 "0-1", src=0x100884358, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:4163
#8 0x00000001001ef5cb in svn_fs_fs__create_txn (txn_p=0x100883f08, fs=0x100871e30, rev=0, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:4336
#9 0x00000001001f7b0a in svn_fs_fs__begin_txn (txn_p=0x100883f08, fs=0x100871e30, rev=0, flags=2, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:7035
#10 0x00000001001d5b9a in svn_fs_begin_txn2 (txn_p=0x100883f08, fs=0x100871e30, rev=0, flags=2, pool=0x100883e28) at subversion/libsvn_fs/fs-loader.c:647
#11 0x000000010019e100 in svn_repos_fs_begin_txn_for_commit2 (txn_p=0x100883f08, repos=0x10086a498, rev=0, revprop_table=0x100883f38, pool=0x100883e28) at subversion/libsvn_repos/fs-wrap.c:90
#12 0x00000001001953d2 in open_root (edit_baton=0x100883ea8, base_revision=-1, pool=0x100869e28, root_baton=0x7fff5fbfe4d8) at subversion/libsvn_repos/commit.c:189
#13 0x00000001000498f2 in import (path=0x100862d20 "/Library/WebServer/Documents", new_entries=0x100868070, editor=0x100873968, edit_baton=0x100883ea8, depth=svn_depth_infinity, excludes=0x100867fa8, no_ignore=0, ignore_unknown_node_types=0, ctx=0x1008573f8, pool=0x100869e28) at subversion/libsvn_client/commit.c:501
#14 0x000000010004a68a in svn_client_import3 (commit_info_p=0x7fff5fbfe6c0, path=0x100862d20 "/Library/WebServer/Documents", url=0x100867e58 "file:///Users/beau/SUBVERSION/svn-src/repo", depth=svn_depth_infinity, no_ignore=0, ignore_unknown_node_types=0, revprop_table=0x0, ctx=0x1008573f8, pool=0x100856e28) at subversion/libsvn_client/commit.c:786
#15 0x0000000100007983 in svn_cl__import (os=0x100857080, baton=0x7fff5fbfe960, pool=0x100856e28) at subversion/svn/import-cmd.c:119
#16 0x000000010000ec4c in main (argc=6, argv=0x7fff5fbfeaa8) at subversion/svn/main.c:2195
Gavin
On 13/11/2009, at 08:43 , Philip Martin wrote:
> Gavin Baumanis <ga...@thespidernet.com> writes:
>
>> I'm sure on some other planet at the moment..
>> That's my excuse and I am sticking to it!
>>
>> I have followed your recipe implicitly ad now I get;
>> [beau@MacBook:~/SUBVERSION/svn-src] $ subversion/svn/svn import -mm Makefile file://`pwd`/repo
>> svn: Path 'file:///Users/beau/SUBVERSION/svn-src/repo' already exists
>
> My mistake, I thought import would append Makefile to the destination
> directory but for files it seems one needs to use:
>
> $ subversion/svn/svn import -mm Makefile file://`pwd`/repo/foo
>
>> I wasn't familiar with your usage of import so I used;
>> subversion/svn/svn import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
>> Segmentation fault
>>
>> (gdb)r import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
>> Starting program: /Users/beau/SUBVERSION/svn-src/subversion/svn/.libs/svn import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
>> Reading symbols for shared libraries .+++++++++++++++++++++++++......................... done
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
>> 0x00007fff86704cc0 in strlen ()
>>
>> (gdb)bt
>> #0 0x00007fff86704cc0 in strlen ()
>> #1 0x000000010046d594 in apr_vformatter ()
>> #2 0x000000010047743c in apr_pvsprintf ()
>> #3 0x00000001004776db in apr_psprintf ()
>> #4 0x0000000100172f01 in representation_string (rep=0x1008858b8, format=<value temporarily unavailable, due to optimizations>, mutable_rep_truncated=<value temporarily unavailable, due to optimizations>, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
>
> It will be easier to debug if you configure with --enable-debug (it
> should also build more quickly).
>
> --
> Philip
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417270
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417274
Re: Subversion test results.
Posted by Philip Martin <ph...@wandisco.com>.
Gavin Baumanis <ga...@thespidernet.com> writes:
> I'm sure on some other planet at the moment..
> That's my excuse and I am sticking to it!
>
> I have followed your recipe implicitly ad now I get;
> [beau@MacBook:~/SUBVERSION/svn-src] $ subversion/svn/svn import -mm Makefile file://`pwd`/repo
> svn: Path 'file:///Users/beau/SUBVERSION/svn-src/repo' already exists
My mistake, I thought import would append Makefile to the destination
directory but for files it seems one needs to use:
$ subversion/svn/svn import -mm Makefile file://`pwd`/repo/foo
> I wasn't familiar with your usage of import so I used;
> subversion/svn/svn import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
> Segmentation fault
>
> (gdb)r import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
> Starting program: /Users/beau/SUBVERSION/svn-src/subversion/svn/.libs/svn import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
> Reading symbols for shared libraries .+++++++++++++++++++++++++......................... done
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
> 0x00007fff86704cc0 in strlen ()
>
> (gdb)bt
> #0 0x00007fff86704cc0 in strlen ()
> #1 0x000000010046d594 in apr_vformatter ()
> #2 0x000000010047743c in apr_pvsprintf ()
> #3 0x00000001004776db in apr_psprintf ()
> #4 0x0000000100172f01 in representation_string (rep=0x1008858b8, format=<value temporarily unavailable, due to optimizations>, mutable_rep_truncated=<value temporarily unavailable, due to optimizations>, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
It will be easier to debug if you configure with --enable-debug (it
should also build more quickly).
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417270
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
I'm sure on some other planet at the moment..
That's my excuse and I am sticking to it!
I have followed your recipe implicitly ad now I get;
[beau@MacBook:~/SUBVERSION/svn-src] $ subversion/svn/svn import -mm Makefile file://`pwd`/repo
svn: Path 'file:///Users/beau/SUBVERSION/svn-src/repo' already exists
I wasn't familiar with your usage of import so I used;
subversion/svn/svn import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
Segmentation fault
(gdb)r import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
Starting program: /Users/beau/SUBVERSION/svn-src/subversion/svn/.libs/svn import -m 'initial import' /Library/WebServer/Documents/ file:///`pwd`/repo
Reading symbols for shared libraries .+++++++++++++++++++++++++......................... done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff86704cc0 in strlen ()
(gdb)bt
#0 0x00007fff86704cc0 in strlen ()
#1 0x000000010046d594 in apr_vformatter ()
#2 0x000000010047743c in apr_pvsprintf ()
#3 0x00000001004776db in apr_psprintf ()
#4 0x0000000100172f01 in representation_string (rep=0x1008858b8, format=<value temporarily unavailable, due to optimizations>, mutable_rep_truncated=<value temporarily unavailable, due to optimizations>, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2163
#5 0x000000010017301b in svn_fs_fs__write_noderev (outfile=0x100888e48, noderev=0x100885800, format=4, include_mergeinfo=1, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2206
#6 0x0000000100174e25 in svn_fs_fs__put_node_revision (fs=0x100871e30, id=<value temporarily unavailable, due to optimizations>, noderev=0x100885800, fresh_txn_root=<value temporarily unavailable, due to optimizations>, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:2272
#7 0x0000000100176b10 in create_new_txn_noderev_from_rev (fs=0x100871e30, txn_id=0x100884308 "0-1", src=<value temporarily unavailable, due to optimizations>, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:4163
#8 0x0000000100178d4e in svn_fs_fs__create_txn (txn_p=0x100883f08, fs=0x100871e30, rev=0, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:4336
#9 0x0000000100178fe2 in svn_fs_fs__begin_txn (txn_p=0x100883f08, fs=0x100871e30, rev=0, flags=2, pool=0x100883e28) at subversion/libsvn_fs_fs/fs_fs.c:7035
#10 0x00000001001363c6 in svn_repos_fs_begin_txn_for_commit2 (txn_p=0x100883f08, repos=0x10086a498, rev=0, revprop_table=0x100883f38, pool=0x100883e28) at subversion/libsvn_repos/fs-wrap.c:90
#11 0x000000010013108a in open_root (edit_baton=0x100883ea8, base_revision=-1, pool=0x100869e28, root_baton=0x7fff5fbfe618) at subversion/libsvn_repos/commit.c:189
#12 0x000000010003e9c7 in import [inlined] () at /Users/beau/SUBVERSION/svn-src/subversion/libsvn_client/commit.c:501
#13 0x000000010003e9c7 in svn_client_import3 (commit_info_p=0x7fff5fbfe6d0, path=0x100862d20 "/Library/WebServer/Documents", url=0x100867e58 "file:///Users/beau/SUBVERSION/svn-src/repo", depth=svn_depth_infinity, no_ignore=0, ignore_unknown_node_types=0, revprop_table=0x0, ctx=0x1008573f8, pool=0x100856e28) at subversion/libsvn_client/commit.c:786
#14 0x0000000100005c98 in svn_cl__import (os=<value temporarily unavailable, due to optimizations>, baton=<value temporarily unavailable, due to optimizations>, pool=0x100856e28) at subversion/svn/import-cmd.c:119
#15 0x000000010000a2e2 in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at subversion/svn/main.c:2195
Gavin.
On 13/11/2009, at 01:15 , Philip Martin wrote:
> Gavin Baumanis <ga...@thespidernet.com> writes:
>
>> CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync
>> <TIME = 0.067775>
>> CMD: svn import -m "Log message for revision 1." svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
>> CMD: /Users/beau/SUBVERSION/svn-src/subversion/svn/svn import -m Log message for revision 1. svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom terminated by signal 11
>
> Signal 11 is a SEGV. It appears that the svn command line program
> doesn't work at all, although svnadmin does. In the root directory of
> your build do:
>
> $ rm -rf repo
> $ subversion/svnadmin/svnadmin create repo
> $ subversion/svn/svn import -mm Makefile file://`pwd`/repo
>
> Does the import work or SEGV? If it SEGVs do
>
> $ libtool --mode=execute gdb subversion/svn/svn
> (gdb) r import -mm Makefile file://`pwd`/repo
> Caught SEGV
> (gdb) bt
>
> to generate a backtrace.
>
> --
> Philip
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417052
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417247
Re: Subversion test results.
Posted by Philip Martin <ph...@wandisco.com>.
Gavin Baumanis <ga...@thespidernet.com> writes:
> Hi Philip,
>
> You must have been reading my mind!
> here is the output;
>
> (gdb) r import -mm Makefile file://`pwd`/repo
> Starting program: /Users/beau/SUBVERSION/svn-src/subversion/svn/.libs/svn import -mm Makefile file://`pwd`/repo
> Reading symbols for shared libraries .+++++++++++++++++++++++++......................... done
> svn: Unable to open an ra_local session to URL
> svn: Unable to open repository 'file:///Users/beau/SUBVERSION/svn-src/repo'
>
> Program exited with code 01.
> (gdb) bt
> No stack.
That hasn't SEGVd. It looks like you didn't create the repo:
$ subversion/svnadmin/svnadmin create repo
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417083
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Philip,
You must have been reading my mind!
here is the output;
(gdb) r import -mm Makefile file://`pwd`/repo
Starting program: /Users/beau/SUBVERSION/svn-src/subversion/svn/.libs/svn import -mm Makefile file://`pwd`/repo
Reading symbols for shared libraries .+++++++++++++++++++++++++......................... done
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///Users/beau/SUBVERSION/svn-src/repo'
Program exited with code 01.
(gdb) bt
No stack.
Hope that means something useful!
Gavin.
On 13/11/2009, at 01:15 , Philip Martin wrote:
> Gavin Baumanis <ga...@thespidernet.com> writes:
>
>> CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync
>> <TIME = 0.067775>
>> CMD: svn import -m "Log message for revision 1." svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
>> CMD: /Users/beau/SUBVERSION/svn-src/subversion/svn/svn import -m Log message for revision 1. svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom terminated by signal 11
>
> Signal 11 is a SEGV. It appears that the svn command line program
> doesn't work at all, although svnadmin does. In the root directory of
> your build do:
>
> $ rm -rf repo
> $ subversion/svnadmin/svnadmin create repo
> $ subversion/svn/svn import -mm Makefile file://`pwd`/repo
>
> Does the import work or SEGV? If it SEGVs do
>
> $ libtool --mode=execute gdb subversion/svn/svn
> (gdb) r import -mm Makefile file://`pwd`/repo
> Caught SEGV
> (gdb) bt
>
> to generate a backtrace.
>
> --
> Philip
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417052
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417059
Re: Subversion test results.
Posted by Philip Martin <ph...@wandisco.com>.
Gavin Baumanis <ga...@thespidernet.com> writes:
> CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync
> <TIME = 0.067775>
> CMD: svn import -m "Log message for revision 1." svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
> CMD: /Users/beau/SUBVERSION/svn-src/subversion/svn/svn import -m Log message for revision 1. svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom terminated by signal 11
Signal 11 is a SEGV. It appears that the svn command line program
doesn't work at all, although svnadmin does. In the root directory of
your build do:
$ rm -rf repo
$ subversion/svnadmin/svnadmin create repo
$ subversion/svn/svn import -mm Makefile file://`pwd`/repo
Does the import work or SEGV? If it SEGVs do
$ libtool --mode=execute gdb subversion/svn/svn
(gdb) r import -mm Makefile file://`pwd`/repo
Caught SEGV
(gdb) bt
to generate a backtrace.
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417052
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi again,
On 09/11/2009, at 23:22 , Julian Foad wrote:
>
> So you need to look for the cause of your failures. Start with either
> the first C test that fails or the first Python test that fails,
> depending on which you are more comfortable with debugging. For the
> Python tests, look in "tests.log" which was created by running the test
> suite, or run an individual test in "verbose" mode:
>
> cd subversion/tests/cmdline
> ./authz_tests.py 1 --verbose
>
> First, you should probably look through the output of "./configure" and
> see if there were any failures or warnings there, because maybe part of
> your build failed.
>
> - Julian
Ok, here is the result of the first test that fails - using "./diff_tests.py --verbose"
CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync
<TIME = 0.067775>
CMD: svn import -m "Log message for revision 1." svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
CMD: /Users/beau/SUBVERSION/svn-src/subversion/svn/svn import -m Log message for revision 1. svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom terminated by signal 11
Traceback (most recent call last):
File "./diff_tests.py", line 3150, in <module>
svntest.main.run_tests(test_list)
File "/Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svntest/main.py", line 1566, in run_tests
svntest.actions.setup_pristine_repository()
File "/Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svntest/actions.py", line 69, in setup_pristine_repository
main.pristine_url)
File "/Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svntest/main.py", line 599, in run_svn
*(_with_auth(_with_config_dir(varargs))))
File "/Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svntest/main.py", line 367, in run_command
None, *varargs)
File "/Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svntest/main.py", line 518, in run_command_stdin
*varargs)
File "/Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svntest/main.py", line 494, in spawn_process
stdout_lines, stderr_lines, exit_code = wait_on_pipe(kid, binary_mode)
File "/Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svntest/main.py", line 470, in wait_on_pipe
raise SVNProcessTerminatedBySignal
svntest.main.SVNProcessTerminatedBySignal
I'm more than happy to go through code and try and nut it out...
But could do with a little help to start things off.
If I can find someone obliging enough - to walk me through the first error and where to look etc then I can follow "that" process for the other tests that fail.
I'm assuming my first port of call is the last line, where there error occurred and that the lines prior to it in the output are for the purposes of showing what transpired prior to the fault?
Gavin.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417034
Re: Subversion test results.
Posted by Julian Foad <ju...@btopenworld.com>.
Gavin Baumanis wrote:
> I have finally managed to compile Subversion on my Mac - wahoo for me!
Great!
> It took 50 minutes to compile simply using ./configure;make;make
> install;
> Is this "about" normal? - not ever having compiled it before I have no
> point of reference for whether this is a long time or not.
I haven't tried it on a Mac but that sounds very long. It takes my
machine less than 5 minutes.
> The summary says that only 5 tests failed, but there are most
> certainly more than 5 failures listed.
> So why is there is a discrepancy, and which of these two outputs
> should I believe?
Ah, that's a bug in the test suite: all of your Python test files are
completely failing to run, and for each of those the test suite prints
"authz_tests.py [33/77].............FAILURE", but it doesn't count that
failure in the summary.
I'll post a patch to try to fix that.
> And while I do recall specific "test failures" mentioned at times
> within the dev mailing list;
> Is there a "protocol" to follow if you notice a test failure?
>
> I guess it is going to be an experience "thing" - but how do you know
> what test failures are important and which aren't?
> Or is it a case of they're all important?
They are all important. The project policy is for all tests to be
passing (or marked XFAIL etc) at all times. When there is a failure, it
is usually your local mods or your local set-up that are the problem.
Sometimes there are a few failures that are hard to debug and exist for
up to a few weeks, but we try hard to avoid that because it makes
everyone's life difficult because then they don't know whether failures
are their fault or not.
So you need to look for the cause of your failures. Start with either
the first C test that fails or the first Python test that fails,
depending on which you are more comfortable with debugging. For the
Python tests, look in "tests.log" which was created by running the test
suite, or run an individual test in "verbose" mode:
cd subversion/tests/cmdline
./authz_tests.py 1 --verbose
First, you should probably look through the output of "./configure" and
see if there were any failures or warnings there, because maybe part of
your build failed.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415764
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi again,
I have been palying around trying to decipher what is going on with the tests and why they don't work for me.
I have followed the steps in the tests and I can successfully create the repository but the import fails with a segmentation fault.
svn import -m "Log message for revision 1." svn-test-work/local_tmp/greekfiles file:///Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /Users/beau/SUBVERSION/svn-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
returns simply;
Segmentation fault
So my question therefore is - how do I go about getting more information about the Seg fault - so as to "hopefully" work out why it is misbehaving.
As always - thanks once again.
Gavin.
On 09/11/2009, at 14:18 , Gavin Baumanis wrote:
> Hi Everyone,
>
> I have finally managed to compile Subversion on my Mac - wahoo for me!
>
> It took 50 minutes to compile simply using ./configure;make;make
> install;
> Is this "about" normal? - not ever having compiled it before I have no
> point of reference for whether this is a long time or not.
>
> Also, I ran the tests for the sake of curiosity and noticed quite a
> few errors reported.
> I have included the results - below and I have the following few
> questions please;
>
> The summary says that only 5 tests failed, but there are most
> certainly more than 5 failures listed.
> So why is there is a discrepancy, and which of these two outputs
> should I believe?
>
> And while I do recall specific "test failures" mentioned at times
> within the dev mailing list;
> Is there a "protocol" to follow if you notice a test failure?
>
> I guess it is going to be an experience "thing" - but how do you know
> what test failures are important and which aren't?
> Or is it a case of they're all important?
>
> Anyhoo, thanks!
>
> Gavin.
>
> Running all tests in auth-test [1/77]...................success
> Running all tests in cache-test [2/77]..................success
> Running all tests in checksum-test [3/77]...............success
> Running all tests in client-test [4/77].................success
> Running all tests in compat-test [5/77].................success
> Running all tests in config-test [6/77].................success
> Running all tests in db-test [7/77].....................success
> Running all tests in diff-diff3-test [8/77].............FAILURE
> Running all tests in dirent_uri-test [9/77].............success
> Running all tests in eol-test [10/77]...................success
> Running all tests in error-test [11/77].................success
> Running all tests in fs-pack-test [12/77]...............FAILURE
> Running all tests in fs-test [13/77]....................FAILURE
> Running all tests in hashdump-test [14/77]..............success
> Running all tests in locks-test [15/77].................FAILURE
> Running all tests in mergeinfo-test [16/77].............success
> Running all tests in opt-test [17/77]...................success
> Running all tests in parse-diff-test [18/77]............success
> Running all tests in path-test [19/77]..................success
> Running all tests in ra-local-test [20/77]..............success
> Running all tests in random-test [21/77]................success
> Running all tests in repos-test [22/77].................FAILURE
> Running all tests in revision-test [23/77]..............success
> Running all tests in skel-test [24/77]..................success
> Running all tests in stream-test [25/77]................success
> Running all tests in string-test [26/77]................success
> Running all tests in target-test [27/77]................success
> Running all tests in time-test [28/77]..................success
> Running all tests in translate-test [29/77].............success
> Running all tests in tree-conflict-data-test [30/77]....success
> Running all tests in utf-test [31/77]...................success
> Running all tests in window-test [32/77]................success
> Running all tests in authz_tests.py [33/77].............FAILURE
> Running all tests in autoprop_tests.py [34/77]..........FAILURE
> Running all tests in basic_tests.py [35/77].............FAILURE
> Running all tests in blame_tests.py [36/77].............FAILURE
> Running all tests in cat_tests.py [37/77]...............FAILURE
> Running all tests in changelist_tests.py [38/77]........FAILURE
> Running all tests in checkout_tests.py [39/77]..........FAILURE
> Running all tests in commit_tests.py [40/77]............FAILURE
> Running all tests in copy_tests.py [41/77]..............FAILURE
> Running all tests in depth_tests.py [42/77].............FAILURE
> Running all tests in diff_tests.py [43/77]..............FAILURE
> Running all tests in entries_tests.py [44/77]...........FAILURE
> Running all tests in export_tests.py [45/77]............FAILURE
> Running all tests in externals_tests.py [46/77].........FAILURE
> Running all tests in getopt_tests.py [47/77]............FAILURE
> Running all tests in history_tests.py [48/77]...........FAILURE
> Running all tests in import_tests.py [49/77]............FAILURE
> Running all tests in info_tests.py [50/77]..............FAILURE
> Running all tests in lock_tests.py [51/77]..............FAILURE
> Running all tests in log_tests.py [52/77]...............FAILURE
> Running all tests in merge_authz_tests.py [53/77].......FAILURE
> Running all tests in merge_tests.py [54/77].............FAILURE
> Running all tests in mergeinfo_tests.py [55/77].........FAILURE
> Running all tests in patch_tests.py [56/77].............FAILURE
> Running all tests in prop_tests.py [57/77]..............FAILURE
> Running all tests in resolved_tests.py [58/77]..........FAILURE
> Running all tests in revert_tests.py [59/77]............FAILURE
> Running all tests in schedule_tests.py [60/77]..........FAILURE
> Running all tests in special_tests.py [61/77]...........FAILURE
> Running all tests in stat_tests.py [62/77]..............FAILURE
> Running all tests in svnadmin_tests.py [63/77]..........FAILURE
> Running all tests in svndumpfilter_tests.py [64/77].....FAILURE
> Running all tests in svnlook_tests.py [65/77]...........FAILURE
> Running all tests in svnsync_tests.py [66/77]...........FAILURE
> Running all tests in svnversion_tests.py [67/77]........FAILURE
> Running all tests in switch_tests.py [68/77]............FAILURE
> Running all tests in trans_tests.py [69/77].............FAILURE
> Running all tests in tree_conflict_tests.py [70/77].....FAILURE
> Running all tests in update_tests.py [71/77]............FAILURE
> Running all tests in upgrade_tests.py [72/77]...........FAILURE
> Running all tests in utf8_tests.py [73/77]..............FAILURE
> Running all tests in changes-test [74/77]...............success
> Running all tests in fs-base-test [75/77]...............success
> Running all tests in key-test [76/77]...................success
> Running all tests in strings-reps-test [77/77]..........success
> At least one test was SKIPPED, checking /Users/beau/SUBVERSION/svn-src/
> tests.log
> SKIP: cache-test 2: basic memcache svn_cache test
> SKIP: cache-test 3: memcache svn_cache with very long keys
> At least one test XFAILED, checking /Users/beau/SUBVERSION/svn-src/
> tests.log
> XFAIL: tree-conflict-data-test 3: detect broken tree conflict data
> At least one test FAILED, checking /Users/beau/SUBVERSION/svn-src/
> tests.log
> FAIL: diff-diff3-test: Unknown test failure; see tests.log.
> FAIL: fs-pack-test: Unknown test failure; see tests.log.
> FAIL: fs-test: Unknown test failure; see tests.log.
> FAIL: locks-test: Unknown test failure; see tests.log.
> FAIL: repos-test: Unknown test failure; see tests.log.
> Summary of test results:
> 233 tests PASSED
> 2 tests SKIPPED
> 1 test XFAILED
> 5 tests FAILED
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415659
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417056
Re: Subversion test results.
Posted by Julian Foad <ju...@wandisco.com>.
Gavin Baumanis wrote:
> I have attached to this email message the output of configure / make and make install
Hi Gavin. The part where you get errors is the tests, so that's where
you need to look for clues. As I said before:
> Start with either
> the first C test that fails or the first Python test that fails,
> depending on which you are more comfortable with debugging. For the
> Python tests, look in "tests.log" which was created by running the
> test suite, or run an individual test in "verbose" mode:
>
> cd subversion/tests/cmdline
> ./authz_tests.py 1 --verbose
The file "tests.log" is created by the test suite ("make check") and has
much more detail than the output you see on the console.
"tests.log" is usually hugely long, but you can paste (or attach) a part
of it for us to see, e.g. from the line "START: info_tests.py" to the
line "END: info_tests.py" (since "info" is a good one to start with and
has only 3 sub-tests).
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417005
Re: Subversion test results.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Jolly and thanks for the reply.
I am really stumped then.
I am not a c-coder either... so I have no experience in "building" software - I am a web developer where it is all runtime code.
But I am currently trying to learn more.
All I can say is that I installed the latest x-code for snow leopard.
I used macports to install autoconf / libtool / apr and apr-util / openssl / python etc.
I use no modifiers to the configure script
I.e. there is no command line argument of --with.....
configure: finds all relevant modules and (I presume) goes through all its steps without complaint.
make: seems to work fine and dandy too - but for the deprecated function warnings and the windows specific errors that occur if not using windows.
make install: seems to be another that just does what it needs to do without telling me anything glaringly obvious is wrong.
The binaries are indeed created I can run them all - though I have not actually created a svn 1.7 repo ad used it.
But I get the normal responses when typing "just" svn / svn help etc / at the command line - So that also seems (at a rather rudimentary level) to be all ok too.
I am "guessing" it is a dependencies issue by using the macports version.... but this is quite an uneducated guess.
I have attached to this email message the output of configure / make and make install - just in case they prove insightful for those who know what they're looking at.
If anyone has any further ideas for me to try - I would be most grateful for the assistance.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2416859
RE: Subversion test results.
Posted by Jolly Chen <jo...@wandisco.com>.
Hi Gavin.
Running
./configure;make;make install
on my mac (2.33Ghz Intel Core 2 Duo, 3G RAM, OS 10.6.2, a 3-yr old MacBook Pro)
on the svn 1.6.6 src distribution took
real 3m48.593s
user 2m30.045s
sys 1m17.056s
my gcc -version is:
gcc version 4.2.1 (Apple Inc. build 5646)
my 'make check' does take a lot longer (about 15 minutes with other stuff going on my machine at the time) and my results are:
Running all tests in auth-test [1/67]...success
Running all tests in cache-test [2/67]...success
Running all tests in checksum-test [3/67]...success
Running all tests in client-test [4/67]...success
Running all tests in compat-test [5/67]...success
Running all tests in config-test [6/67]...success
Running all tests in diff-diff3-test [7/67]...success
Running all tests in dirent_uri-test [8/67]...success
Running all tests in error-test [9/67]...success
Running all tests in fs-pack-test [10/67]...success
Running all tests in fs-test [11/67]...success
Running all tests in hashdump-test [12/67]...success
Running all tests in locks-test [13/67]...success
Running all tests in mergeinfo-test [14/67]...success
Running all tests in opt-test [15/67]...success
Running all tests in path-test [16/67]...success
Running all tests in ra-local-test [17/67]...success
Running all tests in random-test [18/67]...success
Running all tests in repos-test [19/67]...success
Running all tests in revision-test [20/67]...success
Running all tests in skel-test [21/67]...success
Running all tests in stream-test [22/67]...success
Running all tests in string-test [23/67]...success
Running all tests in target-test [24/67]...success
Running all tests in time-test [25/67]...success
Running all tests in translate-test [26/67]...success
Running all tests in tree-conflict-data-test [27/67]...success
Running all tests in utf-test [28/67]...success
Running all tests in window-test [29/67]...success
Running all tests in getopt_tests.py [30/67]...success
Running all tests in basic_tests.py [31/67]...success
Running all tests in checkout_tests.py [32/67]...success
Running all tests in commit_tests.py [33/67]...success
Running all tests in update_tests.py [34/67]...success
Running all tests in switch_tests.py [35/67]...success
Running all tests in prop_tests.py [36/67]...success
Running all tests in schedule_tests.py [37/67]...success
Running all tests in log_tests.py [38/67]...success
Running all tests in copy_tests.py [39/67]...success
Running all tests in diff_tests.py [40/67]...success
Running all tests in export_tests.py [41/67]...success
Running all tests in externals_tests.py [42/67]...success
Running all tests in merge_tests.py [43/67]...success
Running all tests in merge_authz_tests.py [44/67]...success
Running all tests in revert_tests.py [45/67]...success
Running all tests in mergeinfo_tests.py [46/67]...success
Running all tests in stat_tests.py [47/67]...success
Running all tests in trans_tests.py [48/67]...success
Running all tests in autoprop_tests.py [49/67]...success
Running all tests in blame_tests.py [50/67]...success
Running all tests in special_tests.py [51/67]...success
Running all tests in svnadmin_tests.py [52/67]...success
Running all tests in svnlook_tests.py [53/67]...success
Running all tests in svnversion_tests.py [54/67]...success
Running all tests in utf8_tests.py [55/67]...success
Running all tests in history_tests.py [56/67]...success
Running all tests in lock_tests.py [57/67]...success
Running all tests in cat_tests.py [58/67]...success
Running all tests in import_tests.py [59/67]...success
Running all tests in svnsync_tests.py [60/67]...success
Running all tests in authz_tests.py [61/67]...success
Running all tests in depth_tests.py [62/67]...success
Running all tests in svndumpfilter_tests.py [63/67]...success
Running all tests in changelist_tests.py [64/67]...success
Running all tests in info_tests.py [65/67]...success
Running all tests in tree_conflict_tests.py [66/67]...success
Running all tests in resolved_tests.py [67/67]...success
At least one test was SKIPPED, checking /opt/subversion/subversion-1.6.6/tests.log
SKIP: cache-test 2: basic memcache svn_cache test
SKIP: cache-test 3: memcache svn_cache with very long keys
SKIP: update_tests.py 32: update wc on the root of a Windows (virtual) drive
SKIP: switch_tests.py 17: refresh the WC file system read-only attribute
SKIP: merge_tests.py 101: commits to subtrees added by merge wreak havoc
SKIP: merge_authz_tests.py 1: skipped paths get overriding mergeinfo
SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
SKIP: svnsync_tests.py 14: verify that unreadable content is not synced
SKIP: svnsync_tests.py 15: verify that copies from unreadable dirs work
SKIP: svnsync_tests.py 16: verify copies with mods from unreadable dirs
SKIP: svnsync_tests.py 17: verify copies with mods from unreadable dirs +copy
SKIP: authz_tests.py 1: authz issue #2486 - open root
SKIP: authz_tests.py 2: authz issue #2486 - open directory
SKIP: authz_tests.py 3: broken authz files cause errors
SKIP: authz_tests.py 4: test authz for read operations
SKIP: authz_tests.py 5: test authz for write operations
SKIP: authz_tests.py 6: test authz for checkout
SKIP: authz_tests.py 7: test authz for log and tracing path changes
SKIP: authz_tests.py 8: test authz for checkout and update
SKIP: authz_tests.py 9: test authz for export with unreadable subfolder
SKIP: authz_tests.py 10: test authz for aliases
SKIP: authz_tests.py 11: test the authz validation rules
SKIP: authz_tests.py 12: test authz for locking
SKIP: authz_tests.py 13: authz issue #2712
SKIP: authz_tests.py 14: switched to directory, no read access on parents
At least one test XFAILED, checking /opt/subversion/subversion-1.6.6/tests.log
XFAIL: fs-test 18: merging commit
XFAIL: locks-test 9: able to reserve a name (lock non-existent path)
XFAIL: locks-test 10: directory locks (kinda)
XFAIL: tree-conflict-data-test 3: detect broken tree conflict data
XFAIL: basic_tests.py 39: remotely remove directories from two repositories
XFAIL: update_tests.py 50: tree conflicts 2.3: skip on 2nd update
XFAIL: switch_tests.py 10: switch a file to a dir and back to the file
XFAIL: log_tests.py 21: test log -c on range of changes
XFAIL: diff_tests.py 28: diff a renamed directory
XFAIL: diff_tests.py 49: diff URL against working copy with local mods
XFAIL: diff_tests.py 50: diff -r1 of removed file to its local addition
XFAIL: merge_tests.py 34: replace both dir and one of its children
XFAIL: merge_tests.py 55: avoid repeated merges for cyclic merging
XFAIL: merge_tests.py 72: merge target with non inheritable mergeinfo
XFAIL: merge_tests.py 91: merge added subtree
XFAIL: merge_tests.py 115: tree conflicts 5.1: leaf edit, tree del
XFAIL: merge_tests.py 116: tree conflicts 5.2: leaf del, tree del
XFAIL: merge_tests.py 120: tree conflicts 5.1: leaf edit (no ci), tree del
XFAIL: merge_tests.py 121: tree conflicts 5.2: leaf del (no ci), tree del
XFAIL: merge_tests.py 125: merge prior to rename src existence still dels src
XFAIL: revert_tests.py 4: revert a moved file
XFAIL: mergeinfo_tests.py 4: 'mergeinfo' with uninteresting source selection
XFAIL: special_tests.py 10: diff a symlink to a directory
XFAIL: info_tests.py 2: info on added file
XFAIL: tree_conflict_tests.py 14: merge dir: del/rpl/mv onto not-same
Summary of test results:
25 tests SKIPPED
25 tests XFAILED
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2416833