On Mon, 27 Apr 2026 at 21:41, Evgeny Kotkov via dev < [email protected]> 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. > > I encountered several new issues while trying to run the test suite on Windows: 1) I typically use the Python embeddable package distributed as a .zip archive [1][2]. This worked well for Subversion 1.14, but fails for 1.15, because the embeddable package does not include the venv module: [[[ File "C:\Ivan\SVN\svn-1.15.x\subversion\tests\cmdline\svntest\__init__.py", line 59, in <module> from . import main File "C:\Ivan\SVN\svn-1.15.x\subversion\tests\cmdline\svntest\main.py", line 43, in <module> import venv ModuleNotFoundError: No module named 'venv' ]]] The workaround is to perform a full installation of Python via an exe-based installer or package manager. This could be inconvenient for package maintainers and automated tools, as it requires modifying the host environment rather than simply extracting and using a portable binary. 2) Running the tests in an offline environment now introduces a 75-second delay (5 retries x 15s) before the tests start. This is caused by attempts to fetch Python packages: [[[ Testing Release configuration on local repository. WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<pip._vendor.urllib3.connection.HTTPSConnection object at 0x00000298BBEEB010>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/lxml/ ... ]]] This may reduce reproducibility and potentially cause issues for package maintainers building in offline or hardened environments. For example, here is a quote from Debian Policy [3]: [[[ Except for packages in the non-free archive with the Autobuild control field unset or set to no, required targets must not attempt network access to other hosts. Only access via the loopback interface to services on the build host that have been started by the build is allowed. ]]] 3) I haven't checked the details yet, but if we don't pin the versions/signatures of the fetched packages, this may introduce a supply chain attack threat for anyone running the Python tests. Because the test runner now includes a step that automatically downloads and executes code from a remote URL. Thoughts? [1] https://www.python.org/downloads/windows/ [2] https://www.python.org/ftp/python/3.14.5/python-3.14.5-embed-amd64.zip [3] https://www.debian.org/doc/debian-policy/ch-source.html -- Ivan Zhakov
