==> Synchronizing chroot copy [/home/leming/armv8/root] -> [leming]...done
==> Making package: python-python-pkcs11 0.7.0-9 (Mon Dec 23 17:58:36 2024)
==> Retrieving sources...
-> Found python-pkcs11-0.7.0.tar.gz
-> Found python-pkcs11_mark-tests-as-xfail.patch
-> Found use-functools-cached-property.patch
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
python-pkcs11-0.7.0.tar.gz ... Passed
python-pkcs11_mark-tests-as-xfail.patch ... Passed
use-functools-cached-property.patch ... Passed
==> Making package: python-python-pkcs11 0.7.0-9 (Mon 23 Dec 2024 05:58:43 PM MST)
==> Checking runtime dependencies...
==> Installing missing dependencies...
[?25lresolving dependencies...
looking for conflicting packages...
Packages (1) python-asn1crypto-1.5.1-5
Total Installed Size: 1.49 MiB
:: Proceed with installation? [Y/n]
checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
:: Processing package changes...
installing python-asn1crypto...
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
[?25h==> Checking buildtime dependencies...
==> Installing missing dependencies...
[?25lresolving dependencies...
looking for conflicting packages...
Packages (15) python-autocommand-2.2.2-7 python-jaraco.collections-5.0.1-2
python-jaraco.context-5.3.0-3 python-jaraco.functools-4.1.0-1
python-jaraco.text-4.0.0-2 python-more-itertools-10.5.0-1
python-packaging-24.2-3 python-platformdirs-4.3.6-2
python-pyproject-hooks-1.2.0-3 cython-3.0.11-2
python-build-1.2.2-3 python-installer-0.7.0-10
python-setuptools-1:75.2.0-4 python-setuptools-scm-8.1.0-3
python-wheel-0.45.0-3
Total Installed Size: 29.21 MiB
:: Proceed with installation? [Y/n]
checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
:: Processing package changes...
installing cython...
installing python-packaging...
installing python-pyproject-hooks...
installing python-build...
Optional dependencies for python-build
python-pip: to use as the Python package installer (default)
python-uv: to use as the Python package installer
python-virtualenv: to use virtualenv for build isolation
installing python-installer...
installing python-more-itertools...
installing python-jaraco.functools...
installing python-jaraco.context...
installing python-autocommand...
installing python-jaraco.text...
Optional dependencies for python-jaraco.text
python-inflect: for show-newlines script
installing python-jaraco.collections...
installing python-platformdirs...
installing python-wheel...
Optional dependencies for python-wheel
python-keyring: for wheel.signatures
python-xdg: for wheel.signatures
python-setuptools: for legacy bdist_wheel subcommand [pending]
installing python-setuptools...
installing python-setuptools-scm...
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
[?25h==> Retrieving sources...
-> Found python-pkcs11-0.7.0.tar.gz
-> Found python-pkcs11_mark-tests-as-xfail.patch
-> Found use-functools-cached-property.patch
==> WARNING: Skipping all source file integrity checks.
==> Extracting sources...
-> Extracting python-pkcs11-0.7.0.tar.gz with bsdtar
==> Starting prepare()...
patching file pkcs11/types.py
patching file requirements.txt
patching file tests/test_ecc.py
patching file tests/test_x509.py
==> Starting build()...
* Getting build dependencies for wheel...
* Building wheel...
/usr/lib/python3.13/site-packages/setuptools/_distutils/dist.py:261: UserWarning: Unknown distribution option: 'test_suite'
warnings.warn(msg)
WARNING setuptools_scm.pyproject_reading toml section missing 'pyproject.toml does not contain a tool.setuptools_scm section'
Traceback (most recent call last):
File "/usr/lib/python3.13/site-packages/setuptools_scm/_integration/pyproject_reading.py", line 36, in read_pyproject
section = defn.get("tool", {})[tool_name]
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'setuptools_scm'
running bdist_wheel
running build
running build_py
creating build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/__init__.py -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/types.py -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/constants.py -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/exceptions.py -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/defaults.py -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/mechanisms.py -> build/lib.linux-aarch64-cpython-313/pkcs11
creating build/lib.linux-aarch64-cpython-313/pkcs11/util
copying pkcs11/util/__init__.py -> build/lib.linux-aarch64-cpython-313/pkcs11/util
copying pkcs11/util/x509.py -> build/lib.linux-aarch64-cpython-313/pkcs11/util
copying pkcs11/util/dsa.py -> build/lib.linux-aarch64-cpython-313/pkcs11/util
copying pkcs11/util/ec.py -> build/lib.linux-aarch64-cpython-313/pkcs11/util
copying pkcs11/util/dh.py -> build/lib.linux-aarch64-cpython-313/pkcs11/util
copying pkcs11/util/rsa.py -> build/lib.linux-aarch64-cpython-313/pkcs11/util
running egg_info
writing python_pkcs11.egg-info/PKG-INFO
writing dependency_links to python_pkcs11.egg-info/dependency_links.txt
writing requirements to python_pkcs11.egg-info/requires.txt
writing top-level names to python_pkcs11.egg-info/top_level.txt
reading manifest file 'python_pkcs11.egg-info/SOURCES.txt'
adding license file 'LICENSE'
writing manifest file 'python_pkcs11.egg-info/SOURCES.txt'
copying pkcs11/_errors.pyx -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/_mswin.pxd -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/_pkcs11.pyx -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/_pkcs11_defn.pxd -> build/lib.linux-aarch64-cpython-313/pkcs11
copying pkcs11/_utils.pyx -> build/lib.linux-aarch64-cpython-313/pkcs11
running build_ext
Compiling pkcs11/_pkcs11.pyx because it changed.
[1/1] Cythonizing pkcs11/_pkcs11.pyx
warning: pkcs11/_pkcs11.pyx:17:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: pkcs11/_errors.pyx:85:44: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
warning: pkcs11/_pkcs11.pyx:1366:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: pkcs11/_pkcs11.pyx:1390:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
warning: pkcs11/_pkcs11.pyx:1421:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
performance hint: pkcs11/_errors.pyx:85:6: Exception check on 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:196:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:211:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:219:70: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:219:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:230:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:268:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:274:28: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:282:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:303:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:316:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:336:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:363:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:366:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:380:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:427:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:488:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:566:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:582:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:590:63: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:590:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:606:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:609:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:616:51: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:615:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:633:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:640:32: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:646:32: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:651:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:656:64: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:656:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:720:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:731:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:747:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:759:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:769:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:855:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:892:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:896:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:903:56: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:902:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:935:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:947:74: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:946:28: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:957:67: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:957:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:983:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:987:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:994:55: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:993:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1026:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:1038:74: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:1037:28: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:1048:67: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:1048:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1074:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1077:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:1084:52: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:1083:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1105:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1115:28: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1120:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:1125:65: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:1125:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1150:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1152:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1172:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1182:28: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1186:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1210:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:1217:59: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:1216:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1276:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1338:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1409:38: Exception check after calling 'C_GetFunctionList' will always require the GIL to be acquired. Declare 'C_GetFunctionList' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
performance hint: pkcs11/_pkcs11.pyx:1409:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1432:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1439:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1470:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
warning: pkcs11/_pkcs11.pyx:1478:64: Use boundscheck(False) for faster access
performance hint: pkcs11/_pkcs11.pyx:1478:20: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1487:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1556:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1557:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
performance hint: pkcs11/_pkcs11.pyx:1562:24: Exception check after calling 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare 'assertRV' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. Use an 'int' return type on 'assertRV' to allow an error code to be returned.
building 'pkcs11._pkcs11' extension
creating build/temp.linux-aarch64-cpython-313/pkcs11
gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall -march=armv8-a -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -march=armv8-a -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -march=armv8-a -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -march=armv8-a -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fPIC -I/usr/include/python3.13 -c pkcs11/_pkcs11.c -o build/temp.linux-aarch64-cpython-313/pkcs11/_pkcs11.o
gcc -shared -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -march=armv8-a -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection build/temp.linux-aarch64-cpython-313/pkcs11/_pkcs11.o -L/usr/lib -o build/lib.linux-aarch64-cpython-313/pkcs11/_pkcs11.cpython-313-aarch64-linux-gnu.so
installing to build/bdist.linux-aarch64/wheel
running install
running install_lib
creating build/bdist.linux-aarch64/wheel
creating build/bdist.linux-aarch64/wheel/pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/__init__.py -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/_pkcs11.cpython-313-aarch64-linux-gnu.so -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/_errors.pyx -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/_utils.pyx -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/_pkcs11_defn.pxd -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/types.py -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/constants.py -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/_mswin.pxd -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/exceptions.py -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/_pkcs11.pyx -> build/bdist.linux-aarch64/wheel/./pkcs11
creating build/bdist.linux-aarch64/wheel/pkcs11/util
copying build/lib.linux-aarch64-cpython-313/pkcs11/util/__init__.py -> build/bdist.linux-aarch64/wheel/./pkcs11/util
copying build/lib.linux-aarch64-cpython-313/pkcs11/util/x509.py -> build/bdist.linux-aarch64/wheel/./pkcs11/util
copying build/lib.linux-aarch64-cpython-313/pkcs11/util/dsa.py -> build/bdist.linux-aarch64/wheel/./pkcs11/util
copying build/lib.linux-aarch64-cpython-313/pkcs11/util/ec.py -> build/bdist.linux-aarch64/wheel/./pkcs11/util
copying build/lib.linux-aarch64-cpython-313/pkcs11/util/dh.py -> build/bdist.linux-aarch64/wheel/./pkcs11/util
copying build/lib.linux-aarch64-cpython-313/pkcs11/util/rsa.py -> build/bdist.linux-aarch64/wheel/./pkcs11/util
copying build/lib.linux-aarch64-cpython-313/pkcs11/defaults.py -> build/bdist.linux-aarch64/wheel/./pkcs11
copying build/lib.linux-aarch64-cpython-313/pkcs11/mechanisms.py -> build/bdist.linux-aarch64/wheel/./pkcs11
running install_egg_info
Copying python_pkcs11.egg-info to build/bdist.linux-aarch64/wheel/./python_pkcs11-0.7.0-py3.13.egg-info
running install_scripts
creating build/bdist.linux-aarch64/wheel/python_pkcs11-0.7.0.dist-info/WHEEL
creating '/build/python-python-pkcs11/src/python-pkcs11-0.7.0/dist/.tmp-0uyvz9yd/python_pkcs11-0.7.0-cp313-cp313-linux_aarch64.whl' and adding 'build/bdist.linux-aarch64/wheel' to it
adding 'pkcs11/__init__.py'
adding 'pkcs11/_errors.pyx'
adding 'pkcs11/_mswin.pxd'
adding 'pkcs11/_pkcs11.cpython-313-aarch64-linux-gnu.so'
adding 'pkcs11/_pkcs11.pyx'
adding 'pkcs11/_pkcs11_defn.pxd'
adding 'pkcs11/_utils.pyx'
adding 'pkcs11/constants.py'
adding 'pkcs11/defaults.py'
adding 'pkcs11/exceptions.py'
adding 'pkcs11/mechanisms.py'
adding 'pkcs11/types.py'
adding 'pkcs11/util/__init__.py'
adding 'pkcs11/util/dh.py'
adding 'pkcs11/util/dsa.py'
adding 'pkcs11/util/ec.py'
adding 'pkcs11/util/rsa.py'
adding 'pkcs11/util/x509.py'
adding 'python_pkcs11-0.7.0.dist-info/LICENSE'
adding 'python_pkcs11-0.7.0.dist-info/METADATA'
adding 'python_pkcs11-0.7.0.dist-info/WHEEL'
adding 'python_pkcs11-0.7.0.dist-info/top_level.txt'
adding 'python_pkcs11-0.7.0.dist-info/RECORD'
removing build/bdist.linux-aarch64/wheel
Successfully built python_pkcs11-0.7.0-cp313-cp313-linux_aarch64.whl
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
-> Removing libtool files...
-> Purging unwanted files...
-> Removing static library files...
-> Stripping unneeded symbols from binaries and libraries...
-> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "python-python-pkcs11"...
-> Generating .PKGINFO file...
-> Generating .BUILDINFO file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: python-python-pkcs11 0.7.0-9 (Mon 23 Dec 2024 05:59:30 PM MST)
==> Cleaning up...