Den mån 4 maj 2026 kl 05:50 skrev Branko Čibej <[email protected]>: > > On 3. 5. 26 15:16, Branko Čibej wrote: > > On 29. 4. 26 09:57, Branko Čibej wrote: > > On 28. 4. 26 16:57, Branko Čibej wrote: > > On 27. 4. 26 21:39, Evgeny Kotkov via dev wrote: > > The 1.15.0-rc2 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. > > Thanks! > > > +0 to release (Unix; macOS/arm64) > (+1 for release candidate but −1 for final release) > > Note: Could be a configuration problem on macOS, but not too long ago the > branch did build and test with DAV and svnserve. > > > Compiler: Apple clang version 17.0.0 (clang-1700.6.4.2) > Target: arm64-apple-darwin24.6.0 (Mac OS Sequoia 15.7.4) > Built in non-maintainer mode with default flags: -g -O2 -Wall > > > Tests: > > check × FSFS: SUCCESS: All tests successful > > svnserveautocheck × FSFS: ERROR: Tests did not run > > davautocheck × FSFS × prefork: ERROR: Python tests did not run > > > Other issues: > > Compilation warning: > > subversion/libsvn_subr/mergeinfo.c:820:1: warning: unused function > 'rangelist_to_string_debug' [-Wunused-function] > 820 | rangelist_to_string_debug(const svn_rangelist_t *rl, > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > 1 warning generated. > > > > > Building swig-rb with Ruby 4.0.3, I got this compilation error: > > subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c:1641:38: error: > use of undeclared identifier 'ruby_errinfo'; did you mean 'rb_errinfo'? > 1641 | ruby_errinfo, > | ^~~~~~~~~~~~ > | rb_errinfo > > > > Testing swig-py with Python 3.14: > > $ make -s check-swig-py > ..................svn: fs-loader: E200029: Couldn't open rep-cache database > '/var/folders/zv/qq43zzc547zcbm_h9k900hnh0000gn/T/tmpgym3eok7-mergeinfo/db/rep-cache.db' > svn: fs-loader: E200029: Couldn't perform atomic initialization > svn: E235000: In file > '/Users/brane/src/svn/dist/src/subversion-1.15.0-rc2/subversion/libsvn_fs/fs-loader.c' > line 465: internal malfunction > /bin/sh: line 1: 43093 Abort trap: 6 /opt/homebrew/bin/python3 > /Users/brane/src/svn/dist/src/subversion-1.15.0-rc2/subversion/bindings/swig/python/tests/run_all.py > make: *** [check-swig-py] Error 134 > > > With some added tracing I tracked this down to: > > .../subversion-1.15.0-rc2/subversion/libsvn_subr/sqlite.c:794: > (apr_err=SVN_ERR_SQLITE_ERROR) > init-once: E200030: SQLite compiled for 3.53.0, but running with 3.43.2 > > > So it's really a local configuration problem and I just have to see what I'm > doing differently in the dist build compared to my usual builds. It's > "interesting" that libsvn_subr appears to be linked to the correct version of > SQLite: > > $ otool -L libsvn_subr-1.dylib > libsvn_subr-1.dylib: > /opt/dist-subversion-1.15.0-rc2/lib/libsvn_subr-1.0.dylib (compatibility > version 1.0.0, current version 1.0.0) > /opt/homebrew/opt/apr-util/lib/libaprutil-1.0.dylib (compatibility version > 7.0.0, current version 7.3.0) > /opt/homebrew/opt/apr/lib/libapr-1.0.dylib (compatibility version 8.0.0, > current version 8.6.0) > /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12) > /opt/homebrew/opt/sqlite/lib/libsqlite3.dylib (compatibility version 9.0.0, > current version 9.6.0) > /opt/homebrew/opt/lz4/lib/liblz4.1.dylib (compatibility version 1.0.0, > current version 1.10.0) > /opt/homebrew/opt/utf8proc/lib/libutf8proc.3.dylib (compatibility version > 3.0.0, current version 3.2.3) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility version 150.0.0, current version 4201.0.0) > /System/Library/Frameworks/Security.framework/Versions/A/Security > (compatibility version 1.0.0, current version 61901.60.40) > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > (compatibility version 1.0.0, current version 1226.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1356.0.0) > > > > I "fixed" this by rerunning autogen.sh on the extracted tarball, but that's > not a good solution. Right now I have no idea what's different, except that > the latest libtool works differntly enough from whichever version was used to > create the release. Mine is > > $ /opt/homebrew/bin/glibtool --version > glibtool (GNU libtool) 2.5.4 > > > > -- Brane >
Do I understand it correctly that you have "resolved" the issue that was the cause of your veto against release by rerunning autogen.sh? @Nathan Hartman Does this also work for you? I'm not implying that you should remove the veto, in fact I think we need to understand the differences and fix it or document it before release. I think there are some other interesting fixes on trunk - should we backport any of these as well to improve the quality of 1.15.0? - Jun's swig-rb fixes (1933572, ..699) - Ivan's CMake fixes (1933637-638) - Brane's compilation fixes (1933795-796) - Ivan's widechar hardening (193394, ..404-405, possibly also some older) Kind regards, Daniel
