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(' > 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
so...@debian.org
signature.asc
Description: This is a digitally signed message part.
