I have a further question about this test. When it runs in autopkgtests, it looks for a file that exists in the larger upstream repository, but isn’t in the python module tarball.
The test fails [1] with this error:
E FileNotFoundError: [Errno 2] No such file or directory: '/tmp/ autopkgtest-lxc.8j5j6b6j/downtmp/build.nmg/core/embed/vendorheader/T2T1/ vendorheader_satoshilabs_signed_prod.bin'
The file it is looking for appears to be this one [2], locating in the main upstream project (with a slightly different path, but maybe it somehow resolves
it if present). As far as I can tell, this is a dummy binary firmware file used
to make sure trezor can read the headers correctly.
The main upstream repository is quite large. It has a subdirectory named python [3] which is packaged on PyPI [4] and which uscan pulls from pypi.debian.net.
My question is, what is the best way to handle this test? I can think of several possibilities, and there are probably others I haven’t thought of.
1. Just exclude this test from autopkgtests and go on with my life (I assume autopkgtest-pkg-pybuild has an easy way to do this). There are 111 other tests that run successfully, this is a test that upstream should run with every release, and it is testing the type of thing that is unlikely to work for upstream but end up broken in Debian.
3. Include this file in the Debian directory somewhere like missing-sources and run the test against that. Something about this just feels wrong, especially because it is a signed binary file, not really a source file.
2. Modify the test to download this file from github. Python is not my primary language, and I don’t know how difficult it would be to implement or maintain, but I assume this would be possible.
3. Replace the source package with the entire trezor-firmware repository. This seems like an overreach because it would introduce massive numbers of files into the Debian source package that have nothing to do with the python binary packages.
If nobody has any previous experience or strong opinions about situations like these, I am inclined to just go with option 1.
[1]
https://salsa.debian.org/python-team/packages/python-trezor/-/jobs/ 6345561#L248
[2]
https://github.com/trezor/trezor-firmware/blob/main/core/embed/models/ T2T1/vendorheader/vendorheader_satoshilabs_signed_prod.bin
[3]
https://github.com/trezor/trezor-firmware/tree/main/python
[4]
https://pypi.org/project/trezor/
On Thursday, September 26, 2024 1:34:34 PM MST Andrey Rakhmatullin wrote:
On Thu, Sep 26, 2024 at 01:02:14PM -0700, Soren Stoutner wrote:
I am in the process of adopting and updating python-trezor. Upstream now contains a test that involves downloading a binary firmware package from
the
internet [1].
This test causes the build to fail with the following error message, both
on
my local sbuild and on Salsa [2]:
requests.exceptions.ProxyError: HTTPSConnectionPool(host='data.trezor.io', port=443): Max retries exceeded with url: /firmware/2/trezor-2.4.2.bin (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f6d1440d040>: Failed to establish a new connection: [Errno 111] Connection
refused’)))
Loading the URL [3] in a browser allows downloading of the file. I do not know why the test fails in my local sbuild as I don’t believe it prohibits
network access. But it should fail on the buildds, so it needs to be addressed.
pybuild prohibits network access to all programs that honor http(s)_proxy envvars. That's why the error mentions a proxy.
I would appreciate some guidance from more experienced Python packagers on the best way to proceed.
1. What is the best (idomatic) way to disable this test during build?
In this case - just skip the whole file via appropriate PYBUILD_TEST_ARGS.
--
Soren Stoutner
[email protected]
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmb3RGoACgkQwufLJ66w tgNWPBAApSaj/75ZAwC4JzAYnssmQswcyW25+ZdhzaUCikFeFy3seQfjkfpaVQLI TdIHLCpw4V5DJfBxsF2h6YzWVqve6T/w6qvpo7iqWgIUUw74DBzOrcPSAbGLUhln inrgOJJeHGsmq+xcdNZkd+yTckWEY2dJ7mUvSh+91vQvyMx1ZNbVPA4ZAyMabsDn Bb2/ImOvpKwgFtLeaFjoFGS66LhW299ZQO7xG2qGuNUTqEHv5M8TDJ19k+BPMw43 Z8dRYmkm5NMzUD14XPHqLL1mAx4w5BeqrHZYuyce6tt8oJmVfBjMHAfk5ENXL1qq eikNNCCE7Wknycdcb72T0C9xpNs7mJaGzzcxu8J8IDkvQiuA4fGIZaVatc94N5O9 IcRMiab25WKnjFctnPuxY1jxHiGuYQNiryoGeYyyGzdx1PRB88N5MHwbUNsE0RvQ vNEfxQOFB6Pdimjac9SXxeVPBKy3RpU7rRtOBGuMk2xPZ+zMOrbAurM1GOXUGDfi WrPnTG5BSpAxtC+Y/vWdIw4pLIpLmJYW81Xq4UKqNfmycPZZIilPfnQfYc3MkpwS D9nczisDa7kKGKg/hdYWUyRxZm3hRbFzBIqSfiE7u8FCDnLfxLyJwo9kC8gdnsLe 9eDxBsJQaJMEK2jiOQZmVA70xXWcpxW1WFqa0wUylsBR8XqJt3A=
=2ZTx
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)