Review Results

Comment

The change is limited to .SRCINFO metadata: it bumps pkgrel and adds i686/pentium4 architectures. There are no source URL changes, no new build steps, no install scripts, and no executable content introduced. This does not create an obvious supply-chain or privilege-escalation risk on its own; it only broadens the declared build targets and updates package release metadata.

@@ -1,10 +1,12 @@
 pkgbase = python2
 	pkgdesc = A high-level scripting language
 	pkgver = 2.7.18
-	pkgrel = 14
+	pkgrel = 17
 	url = https://www.python.org/
 	arch = x86_64
 	arch = aarch64
+	arch = i686
+	arch = pentium4
 	license = PSF-2.0
 	checkdepends = gdb
 	checkdepends = file

Comment

The change is low risk. It only expands the declared architectures to include 32-bit targets and skips the test suite entirely on i686/pentium4 due to reported environment-specific failures, while also adding one more excluded test on all arches. There are no new sources, downloads, privilege changes, install-script edits, or packaging actions outside the normal build/test flow. The main concern is reduced test coverage on 32-bit builds, which weakens validation but does not itself introduce a supply-chain or persistence risk.

@@ -7,10 +7,10 @@
 
 pkgname=python2
 pkgver=2.7.18
-pkgrel=14
+pkgrel=17
 _pybasever=2.7
 pkgdesc="A high-level scripting language"
-arch=('x86_64' 'aarch64')
+arch=('x86_64' 'aarch64' 'i686' 'pentium4')
 license=('PSF-2.0')
 url="https://www.python.org/"
 depends=('bzip2' 'expat' 'gdbm' 'libffi' 'libnsl' 'libxcrypt' 'openssl-1.1'  'sqlite' 'zlib')

Comment

The change does not introduce a direct supply-chain or privilege-escalation issue, but it does materially weaken package verification on 32-bit builds by skipping the entire test suite for i686/pentium4. That reduces the ability to catch regressions or malicious build-time tampering on those architectures, and the justification is based on environment-specific failures rather than a narrowly scoped test exclusion. The added test_tuple exclusion on all arches is also a packaging-quality change, but not a security issue by itself. Overall this is low risk, with the main concern being reduced assurance rather than an exploitable vulnerability.

@@ -132,11 +132,23 @@ check() {
   # test_ftplib test_imaplib test_urllib2_localnet: krb5 errors
   # test_codecmaps_jp: TODO
   # test_curses: fails
+  # 2026-08-17: skip the whole test suite on i686/pentium4. Hit two
+  # different failures back to back that only reproduce on 32-bit in
+  # this build environment -- test_bigrepeat (test_tuple) segfaulting
+  # on a deliberate huge-tuple overflow stress test, then (after
+  # excluding that) test_audioop/test_gdb failing for reasons that look
+  # like chroot/environment limitations (gdb ptrace, audio libs) rather
+  # than real packaging defects. Rather than keep excluding individual
+  # tests one at a time as more 32-bit-only quirks surface, skip check()
+  # entirely for these arches; x86_64/aarch64 still run the full suite.
+  case ${CARCH} in
+    i686|pentium4) return 0 ;;
+  esac
   export TERM=xterm
   local -x TZ=UTC
   cd Python-${pkgver}
   LD_LIBRARY_PATH="${srcdir}/Python-${pkgver}":${LD_LIBRARY_PATH} \
-    xvfb-run "${srcdir}/Python-${pkgver}/python" -m test.regrtest -v -uall -x test_idle test_tk test_ttk_guionly test_ctypes test_ssl test_ftplib test_imaplib test_urllib2_localnet test_codecmaps_jp test_ossaudiodev test_curses
+    xvfb-run "${srcdir}/Python-${pkgver}/python" -m test.regrtest -v -uall -x test_idle test_tk test_ttk_guionly test_ctypes test_ssl test_ftplib test_imaplib test_urllib2_localnet test_codecmaps_jp test_ossaudiodev test_curses test_tuple
 }
 
 package() {