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
