On 8. 5. 26 22:17, Daniel Sahlberg wrote:
Den tors 7 maj 2026 kl 15:32 skrev Branko Čibej<[email protected]>:
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.
2.4.6, which was used to prepare the release, was released 2015. I
have not yet compared output with 2.4.7 (released 2022) or any of the
2.5 releases. However I think we should consider updating to something
released less than 10 years ago. Any thoughts?
Using a newer libtool (and autoconf) should not cause problems for users
who build on older platforms, at least most of the time. They're
supposed to be backwards We should make sure however that the release
tarballs work on the current crop: Windows 10+, the various
Linux/*BSD/macOS distros not more than a couple years old. Anyone who
builds on really niche platforms can probably regenerate the build, or
use a custom build like Tortoise does.
For macOS, I can have a go at finding the earliest autoconf and libtool
releases that still work.
We should also think about upgrading Swig, I found that the generated
Ruby bindings don't work out of the box, either.
-- Brane
