You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alan Fry <tt...@gmail.com> on 2020/12/01 02:15:02 UTC
Re: Source Code Build Errors?
Thanks for all who are helping.
After some digging and using the references from this group, I'm down to
just one error in the fails file (below). I'm still digging into this.
Does anyone have hints on where / what library might cause this one to
fault? Since this is clearly a low level call, I'm assuming that some
prerequisite is the issue. This is on the linux build.
I have all the helpful hints for the Windows build, once I get some time to
work on that, I'll create a seperate thread.
[[[
subversion/tests/libsvn_fs/locks-test.c:1134: (apr_err=SVN_ERR_TEST_FAILED)
svn_tests: E200006: Expected error but got SVN_NO_ERROR
FAIL: locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
]]]
On Thu, Nov 26, 2020 at 7:46 PM Alan Fry <tt...@gmail.com> wrote:
> Excellent, thank you.
>
> So the target is "all tests succeeded".
>
> And thank you, I'll dive into the tests.log file. I'm sure the errors are
> due to the build that I'm trying, not actual faults in the code.
>
> On Tue, Nov 24, 2020 at 1:45 PM Branko Čibej <br...@apache.org> wrote:
>
>> On 24.11.2020 19:05, Alan Fry wrote:
>> > Having some time finally to work on building SVN (thanks all who
>> > helped me get this far), I setup a VM with Ubuntu. (Also setup a
>> > Windows 10 machine w/ Visual studio, but have not started on that
>> > effort yet).
>> >
>> > Knowing little about linux, I managed to get this far, the results of
>> > make checks
>> >
>> > Last part of the make check:
>> >
>> > At least one test FAILED, checking
>> > /home/svn/Documents/subversion-1.14.0/tests.log
>> > FAIL: error-test 3: test svn_error_symbolic_name
>> > FAIL: locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
>> > FAIL: commit_tests.py 48: set revision props during remote property
>> edit
>> > FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe)
>> > FAIL: prop_tests.py 16: property operations on a URL
>> > FAIL: update_tests.py 38: update --accept automatic conflict resolution
>> > Summary of test results:
>> > 2508 tests PASSED
>> > 162 tests SKIPPED
>> > 81 tests XFAILED (17 WORK-IN-PROGRESS)
>> > 6 tests FAILED
>> > Python version: 3.8.5.
>> > SUMMARY: Some tests failed
>> >
>> > Are these errors something I need to dig into, indicating that my
>> > build is no good? I was reading in the "INSTALL" document, there is
>> > mention that some errors are expected. Is there a way to determine if
>> > these are expected errors?
>>
>> Expected test failures are tagged as XFAIL, not FAIL. So these are
>> "real" failures. Also the summary line would read "All tests succeeded"
>> if there were only expected failures.
>>
>> You should look at tests.log (the test driver hepfully prints the whole
>> path) to see why those tests failed, it could be something trivial. It's
>> not likely that there's a problem with the code, we'd have noticed that.
>>
>> -- Brane
>>
>
Re: Source Code Build Errors?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alan Fry wrote on Tue, Feb 16, 2021 at 19:32:24 -0500:
> On Mon, Feb 15, 2021 at 1:38 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
> > Alan Fry wrote on Mon, Feb 08, 2021 at 18:34:01 -0500:
> > > It seems that, in my case in subversion/tests/libsvn_fs/locks-test.c
> > (line
> > > 1134), the test expects an error, however it succeeds. Again, I'm not a
> > > linux person, so I spent an hour trying to figure out what executable is
> > > actually generating test.log...
> >
> > tests.log is generated by build/run_tests.py, which runs individual test
> > programs and is run by «make check». To cut a long story short, I think
> > you're looking for one of these:
> >
> > 1. make locks-test && (cd subversion/tests/libsvn_fs && ./locks-test)
> > (I could be wrong about the default cwd)
> >
> > 2. «make check TESTS=subversion/tests/libsvn_fs/locks-test.c»
> >
> > All this should be documented somewhere in the README files (in the tree
> > root
> > and in subversion/tests/ and subversion/tests/cmdline/).
> >
> > > Any suggestions on next steps? If I have not posted enough information,
> > > I'd be happy to be more concise.
> >
> > You haven't addressed my suggestions from my previous reply. To be
> > explicit,
> > what's the output of «id» when run just before «make check»?
>
>
> I do appreciate your help.
I didn't think otherwise.
> I documented the steps to setup a Linux VM (Virtualbox/Ubuntu 20.04). This
> time, however, I followed a different set of steps to build Subversion on
> linux, and I no longer get the error in locks-test.c. As I have mentioned,
> I have almost zero experience in Linux, so I'm sure the original error was
> 'environmental', something to do with APR probably.
>
> I did keep the original VM, so if you feel there is value in continuing
> down that line, I'd be happy to... my challenge was not being sure what
> "what's the output of «id» when run just before «make check»"... again
> having zero experience with linux I wasn't sure what you were asking for.
I was asking you to, just before you run the test suite, run the command
«id» (two letters, just like «ls») without arguments and report its
output. That's because that command reports the real and effective
uid/gid, and in particular indicates whether the tests are run with
superuser privileges, which the comment I referred to earlier documents
as a known failure case.
> At least one test FAILED, checking /home/svn/src/subversion-1.14.1/tests.log
> FAIL: commit_tests.py 48: set revision props during remote property edit
> FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe)
> FAIL: prop_tests.py 16: property operations on a URL
> FAIL: update_tests.py 38: update --accept automatic conflict resolution
I see downthread these pass for you now, but for future reference, to
answer any question about these, we'd need to see the full test output
from tests.log. At the end of a full test run the relevant parts of
tests.log are copied to fails.log. (Updating fails.log as the test run
progresses has never been implemented.)
Cheers,
Daniel
> Summary of test results:
> 2517 tests PASSED
> 161 tests SKIPPED
> 80 tests XFAILED (17 WORK-IN-PROGRESS)
> 4 tests FAILED
> Python version: 3.8.5.
> SUMMARY: Some tests failed
Re: Source Code Build Errors?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alan Fry wrote on Tue, Feb 16, 2021 at 20:16:34 -0500:
> On Tue, Feb 16, 2021 at 7:32 PM Alan Fry <tt...@gmail.com> wrote:
> > FAIL: commit_tests.py 48: set revision props during remote property edit
> > FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe)
> > FAIL: prop_tests.py 16: property operations on a URL
> > FAIL: update_tests.py 38: update --accept automatic conflict resolution
>
> I was missing a link that patched up 'python' to python3.
Right, I see the problem. Those four tests are exactly those that
invoke use_editor(), and that function sets $SVN_MERGE and $SVN_EDITOR
to a «#!/usr/bin/env python» script.
That's a bug, actually. The test suite shouldn't use whichever 'python'
binary happens to lie in $PATH, but the one specified by sys.executable.
> Seems I have a successful build:
Congrats ☺
Re: Source Code Build Errors?
Posted by Alan Fry <tt...@gmail.com>.
I was missing a link that patched up 'python' to python3.
Seems I have a successful build:
XFAIL: wc_tests.py 6: add file with not-parent symlink
Summary of test results:
2521 tests PASSED
161 tests SKIPPED
80 tests XFAILED (17 WORK-IN-PROGRESS)
Python version: 3.8.5.
SUMMARY: All tests successful
On Tue, Feb 16, 2021 at 7:32 PM Alan Fry <tt...@gmail.com> wrote:
> On Mon, Feb 15, 2021 at 1:38 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
>> Alan Fry wrote on Mon, Feb 08, 2021 at 18:34:01 -0500:
>> > It seems that, in my case in subversion/tests/libsvn_fs/locks-test.c
>> (line
>> > 1134), the test expects an error, however it succeeds. Again, I'm not a
>> > linux person, so I spent an hour trying to figure out what executable is
>> > actually generating test.log...
>>
>> tests.log is generated by build/run_tests.py, which runs individual test
>> programs and is run by «make check». To cut a long story short, I think
>> you're looking for one of these:
>>
>> 1. make locks-test && (cd subversion/tests/libsvn_fs && ./locks-test)
>> (I could be wrong about the default cwd)
>>
>> 2. «make check TESTS=subversion/tests/libsvn_fs/locks-test.c»
>>
>> All this should be documented somewhere in the README files (in the tree
>> root
>> and in subversion/tests/ and subversion/tests/cmdline/).
>>
>> > Any suggestions on next steps? If I have not posted enough information,
>> > I'd be happy to be more concise.
>>
>> You haven't addressed my suggestions from my previous reply. To be
>> explicit,
>> what's the output of «id» when run just before «make check»?
>
>
> I do appreciate your help. I was intent on working through your question,
> but then I decided to "start over".
>
> I documented the steps to setup a Linux VM (Virtualbox/Ubuntu 20.04).
> This time, however, I followed a different set of steps to build Subversion
> on linux, and I no longer get the error in locks-test.c. As I have
> mentioned, I have almost zero experience in Linux, so I'm sure the original
> error was 'environmental', something to do with APR probably.
>
> I did keep the original VM, so if you feel there is value in continuing
> down that line, I'd be happy to... my challenge was not being sure what
> "what's the output of «id» when run just before «make check»"... again
> having zero experience with linux I wasn't sure what you were asking for.
>
> Of course, I have a new set of errors. But these are all in the python
> tests (the final summary below). As time allows, I'm going to continue to
> work on the linux build, plus I've started on a windows build as well (I
> will ask questions in a separate email to keep from mixing). If anyone
> has any quick ideas, I'd be appreciative, otherwise I'll dig into the below
> errors.
>
> At least one test FAILED, checking
> /home/svn/src/subversion-1.14.1/tests.log
> FAIL: commit_tests.py 48: set revision props during remote property edit
> FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe)
> FAIL: prop_tests.py 16: property operations on a URL
> FAIL: update_tests.py 38: update --accept automatic conflict resolution
> Summary of test results:
> 2517 tests PASSED
> 161 tests SKIPPED
> 80 tests XFAILED (17 WORK-IN-PROGRESS)
> 4 tests FAILED
> Python version: 3.8.5.
> SUMMARY: Some tests failed
>
>
>
>
Re: Source Code Build Errors?
Posted by Alan Fry <tt...@gmail.com>.
On Mon, Feb 15, 2021 at 1:38 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> Alan Fry wrote on Mon, Feb 08, 2021 at 18:34:01 -0500:
> > It seems that, in my case in subversion/tests/libsvn_fs/locks-test.c
> (line
> > 1134), the test expects an error, however it succeeds. Again, I'm not a
> > linux person, so I spent an hour trying to figure out what executable is
> > actually generating test.log...
>
> tests.log is generated by build/run_tests.py, which runs individual test
> programs and is run by «make check». To cut a long story short, I think
> you're looking for one of these:
>
> 1. make locks-test && (cd subversion/tests/libsvn_fs && ./locks-test)
> (I could be wrong about the default cwd)
>
> 2. «make check TESTS=subversion/tests/libsvn_fs/locks-test.c»
>
> All this should be documented somewhere in the README files (in the tree
> root
> and in subversion/tests/ and subversion/tests/cmdline/).
>
> > Any suggestions on next steps? If I have not posted enough information,
> > I'd be happy to be more concise.
>
> You haven't addressed my suggestions from my previous reply. To be
> explicit,
> what's the output of «id» when run just before «make check»?
I do appreciate your help. I was intent on working through your question,
but then I decided to "start over".
I documented the steps to setup a Linux VM (Virtualbox/Ubuntu 20.04). This
time, however, I followed a different set of steps to build Subversion on
linux, and I no longer get the error in locks-test.c. As I have mentioned,
I have almost zero experience in Linux, so I'm sure the original error was
'environmental', something to do with APR probably.
I did keep the original VM, so if you feel there is value in continuing
down that line, I'd be happy to... my challenge was not being sure what
"what's the output of «id» when run just before «make check»"... again
having zero experience with linux I wasn't sure what you were asking for.
Of course, I have a new set of errors. But these are all in the python
tests (the final summary below). As time allows, I'm going to continue to
work on the linux build, plus I've started on a windows build as well (I
will ask questions in a separate email to keep from mixing). If anyone
has any quick ideas, I'd be appreciative, otherwise I'll dig into the below
errors.
At least one test FAILED, checking /home/svn/src/subversion-1.14.1/tests.log
FAIL: commit_tests.py 48: set revision props during remote property edit
FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe)
FAIL: prop_tests.py 16: property operations on a URL
FAIL: update_tests.py 38: update --accept automatic conflict resolution
Summary of test results:
2517 tests PASSED
161 tests SKIPPED
80 tests XFAILED (17 WORK-IN-PROGRESS)
4 tests FAILED
Python version: 3.8.5.
SUMMARY: Some tests failed
Re: Source Code Build Errors?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alan Fry wrote on Mon, Feb 08, 2021 at 18:34:01 -0500:
> It seems that, in my case in subversion/tests/libsvn_fs/locks-test.c (line
> 1134), the test expects an error, however it succeeds. Again, I'm not a
> linux person, so I spent an hour trying to figure out what executable is
> actually generating test.log...
tests.log is generated by build/run_tests.py, which runs individual test
programs and is run by «make check». To cut a long story short, I think
you're looking for one of these:
1. make locks-test && (cd subversion/tests/libsvn_fs && ./locks-test)
(I could be wrong about the default cwd)
2. «make check TESTS=subversion/tests/libsvn_fs/locks-test.c»
All this should be documented somewhere in the README files (in the tree root
and in subversion/tests/ and subversion/tests/cmdline/).
> Any suggestions on next steps? If I have not posted enough information,
> I'd be happy to be more concise.
You haven't addressed my suggestions from my previous reply. To be explicit,
what's the output of «id» when run just before «make check»?
Cheers,
Daniel
Re: Source Code Build Errors?
Posted by Alan Fry <tt...@gmail.com>.
Trying to start back up now that work has slowed a bit.
I rebuilt everything and (understandably) ended up with the same result.
Is there anyone that knows the tests? It seems that, in my case in
subversion/tests/libsvn_fs/locks-test.c (line 1134), the test expects an
error, however it succeeds. Again, I'm not a linux person, so I spent an
hour trying to figure out what executable is actually generating
test.log... but wasn't successful.
Any suggestions on next steps? If I have not posted enough information,
I'd be happy to be more concise.
On Tue, Dec 1, 2020 at 12:59 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> Alan Fry wrote on Tue, 01 Dec 2020 03:02 +00:00:
> > On Mon, Nov 30, 2020 at 9:15 PM Alan Fry <tt...@gmail.com> wrote:
> > > After some digging and using the references from this group, I'm down
> to just one error in the fails file (below). I'm still digging into this.
> Does anyone have hints on where / what library might cause this one to
> fault? Since this is clearly a low level call, I'm assuming that some
> prerequisite is the issue. This is on the linux build.
> > >
> > > I have all the helpful hints for the Windows build, once I get some
> time to work on that, I'll create a seperate thread.
> > >
> > > [[[
> > > subversion/tests/libsvn_fs/locks-test.c:1134:
> (apr_err=SVN_ERR_TEST_FAILED)
> > > svn_tests: E200006: Expected error but got SVN_NO_ERROR
> > > FAIL: locks-test 14: lock/unlock when 'write-lock' couldn't be
> obtained
> > > ]]]
> >
> > This is an interesting fault.
> >
> > The test is to lock paths and generate an error. In my build, it
> > fails... because the svn_fs_lock_many call returns success.
> >
> >
> > /* Trying to lock some paths. We don't really care about error; the
> test
> > shouldn't crash. */
> > target = svn_fs_lock_target_create(NULL, newrev, pool);
> > lock_paths = apr_hash_make(pool);
> > svn_hash_sets(lock_paths, "/iota", target);
> > svn_hash_sets(lock_paths, "/A/mu", target);
> >
> > apr_hash_clear(baton.results);
> > SVN_TEST_ASSERT_ANY_ERROR(svn_fs_lock_many(fs, lock_paths, "comment",
> 0, 0, 0,
> > lock_many_cb, &baton, pool,
> pool));
>
> Read the comment immediately above the function you quoted that code from.
>
> If that's not it, run «mount» without arguments (it may not be in $PATH)
> and post the lines of output that pertain to the build directory (the
> one you ran «./configure» in) and to its subdirectories.
>
> Cheers,
>
> Daniel
>
Re: Source Code Build Errors?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alan Fry wrote on Tue, 01 Dec 2020 03:02 +00:00:
> On Mon, Nov 30, 2020 at 9:15 PM Alan Fry <tt...@gmail.com> wrote:
> > After some digging and using the references from this group, I'm down to just one error in the fails file (below). I'm still digging into this. Does anyone have hints on where / what library might cause this one to fault? Since this is clearly a low level call, I'm assuming that some prerequisite is the issue. This is on the linux build.
> >
> > I have all the helpful hints for the Windows build, once I get some time to work on that, I'll create a seperate thread.
> >
> > [[[
> > subversion/tests/libsvn_fs/locks-test.c:1134: (apr_err=SVN_ERR_TEST_FAILED)
> > svn_tests: E200006: Expected error but got SVN_NO_ERROR
> > FAIL: locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
> > ]]]
>
> This is an interesting fault.
>
> The test is to lock paths and generate an error. In my build, it
> fails... because the svn_fs_lock_many call returns success.
>
>
> /* Trying to lock some paths. We don't really care about error; the test
> shouldn't crash. */
> target = svn_fs_lock_target_create(NULL, newrev, pool);
> lock_paths = apr_hash_make(pool);
> svn_hash_sets(lock_paths, "/iota", target);
> svn_hash_sets(lock_paths, "/A/mu", target);
>
> apr_hash_clear(baton.results);
> SVN_TEST_ASSERT_ANY_ERROR(svn_fs_lock_many(fs, lock_paths, "comment", 0, 0, 0,
> lock_many_cb, &baton, pool, pool));
Read the comment immediately above the function you quoted that code from.
If that's not it, run «mount» without arguments (it may not be in $PATH)
and post the lines of output that pertain to the build directory (the
one you ran «./configure» in) and to its subdirectories.
Cheers,
Daniel
Re: Source Code Build Errors?
Posted by Alan Fry <tt...@gmail.com>.
This is an interesting fault.
The test is to lock paths and generate an error. In my build, it fails...
because the svn_fs_lock_many call returns success.
/* Trying to lock some paths. We don't really care about error; the test
shouldn't crash. */
target = svn_fs_lock_target_create(NULL, newrev, pool);
lock_paths = apr_hash_make(pool);
svn_hash_sets(lock_paths, "/iota", target);
svn_hash_sets(lock_paths, "/A/mu", target);
apr_hash_clear(baton.results);
SVN_TEST_ASSERT_ANY_ERROR(svn_fs_lock_many(fs, lock_paths, "comment", 0,
0, 0,
lock_many_cb, &baton, pool,
pool));
On Mon, Nov 30, 2020 at 9:15 PM Alan Fry <tt...@gmail.com> wrote:
> Thanks for all who are helping.
>
> After some digging and using the references from this group, I'm down to
> just one error in the fails file (below). I'm still digging into this.
> Does anyone have hints on where / what library might cause this one to
> fault? Since this is clearly a low level call, I'm assuming that some
> prerequisite is the issue. This is on the linux build.
>
> I have all the helpful hints for the Windows build, once I get some time
> to work on that, I'll create a seperate thread.
>
> [[[
> subversion/tests/libsvn_fs/locks-test.c:1134: (apr_err=SVN_ERR_TEST_FAILED)
> svn_tests: E200006: Expected error but got SVN_NO_ERROR
> FAIL: locks-test 14: lock/unlock when 'write-lock' couldn't be obtained
> ]]]
>
> On Thu, Nov 26, 2020 at 7:46 PM Alan Fry <tt...@gmail.com> wrote:
>
>> Excellent, thank you.
>>
>> So the target is "all tests succeeded".
>>
>> And thank you, I'll dive into the tests.log file. I'm sure the errors
>> are due to the build that I'm trying, not actual faults in the code.
>>
>> On Tue, Nov 24, 2020 at 1:45 PM Branko Čibej <br...@apache.org> wrote:
>>
>>> On 24.11.2020 19:05, Alan Fry wrote:
>>> > Having some time finally to work on building SVN (thanks all who
>>> > helped me get this far), I setup a VM with Ubuntu. (Also setup a
>>> > Windows 10 machine w/ Visual studio, but have not started on that
>>> > effort yet).
>>> >
>>> > Knowing little about linux, I managed to get this far, the results of
>>> > make checks
>>> >
>>> > Last part of the make check:
>>> >
>>> > At least one test FAILED, checking
>>> > /home/svn/Documents/subversion-1.14.0/tests.log
>>> > FAIL: error-test 3: test svn_error_symbolic_name
>>> > FAIL: locks-test 14: lock/unlock when 'write-lock' couldn't be
>>> obtained
>>> > FAIL: commit_tests.py 48: set revision props during remote property
>>> edit
>>> > FAIL: prop_tests.py 1: write/read props in wc only (ps, pl, pdel, pe)
>>> > FAIL: prop_tests.py 16: property operations on a URL
>>> > FAIL: update_tests.py 38: update --accept automatic conflict
>>> resolution
>>> > Summary of test results:
>>> > 2508 tests PASSED
>>> > 162 tests SKIPPED
>>> > 81 tests XFAILED (17 WORK-IN-PROGRESS)
>>> > 6 tests FAILED
>>> > Python version: 3.8.5.
>>> > SUMMARY: Some tests failed
>>> >
>>> > Are these errors something I need to dig into, indicating that my
>>> > build is no good? I was reading in the "INSTALL" document, there is
>>> > mention that some errors are expected. Is there a way to determine if
>>> > these are expected errors?
>>>
>>> Expected test failures are tagged as XFAIL, not FAIL. So these are
>>> "real" failures. Also the summary line would read "All tests succeeded"
>>> if there were only expected failures.
>>>
>>> You should look at tests.log (the test driver hepfully prints the whole
>>> path) to see why those tests failed, it could be something trivial. It's
>>> not likely that there's a problem with the code, we'd have noticed that.
>>>
>>> -- Brane
>>>
>>