Re: Source Code Build Errors?

2021-02-08 Thread Alan Fry
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 
wrote:

> Alan Fry wrote on Tue, 01 Dec 2020 03:02 +00:00:
> > On Mon, Nov 30, 2020 at 9:15 PM Alan Fry  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: E26: 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: Subversion 1.14.1 up for testing/signing

2021-02-08 Thread Branko Čibej

On 04.02.2021 13:56, Stefan Sperling wrote:

The 1.14.1 release artifacts are now available for testing/signing.
Please get the tarballs from
   https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.



I suggest release.py should be updated to remove the __pycache__ 
directories from the release tarball. When I compare the zip and the tar 
package, e.g.:


Only in subversion-1.14.1/build: __pycache__
Only in subversion-1.14.1/build: config.guess
Only in subversion-1.14.1/build: config.sub
Only in subversion-1.14.1/build/generator: __pycache__
Only in subversion-1.14.1/build/generator/swig: __pycache__
...


Not only are those (python-3) compiled scripts unnecessary, they might 
actually be wrong for the platform where the code is built.


-- Brane