On 4. 5. 26 05:48, Branko Čibej wrote:
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
So it turns out that this is a known issue, I just didn't remember it. I
found my old release verification tools and saw that I had the same
problem. I think it may be time to upgrade the RM tool version
requirements; this can't be anything other than a libtool bug.
-- Brane
