Hi,

I have a package (pyraf) where I need to switch off some tests for i386
(but not for other 32-bit platforms). I do this by

import platform
is_i386 = platform.machine() in ('i386', 'i486', 'i586', 'i686')

[...]
@pytest.mark.skipif(is_i386, reason='diff is not identical on i386')
def test_gki_single_prow():

https://salsa.debian.org/debian-astro-team/pyraf/-/blob/master/debian/patches/Skip-tests-that-are-too-tight-for-i386.patch

However, on Salsa this fails; and it appears that this test is
ignored. Further investigation gave me that there -- during the regular (pybuild) test -- platform.machine() gives "x86_64", despite of the
32-bit platform.

https://salsa.debian.org/debian-astro-team/pyraf/-/jobs/2130878#L2062

How can one find out the correct machine here?

Best regards

Ole

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Oct 30, 2021 at 02:20:40PM +0200, Ole Streicher wrote:

I have a package (pyraf) where I need to switch off some tests for i386
(but not for other 32-bit platforms). I do this by

import platform
is_i386 = platform.machine() in ('i386', 'i486', 'i586', 'i686')

Yup, this is incorrect. This is the same as `uname -m` and so returns the kernel architecture.
If you want to do this purely at the upstream side without checking DEB_HOST_ARCH, AFAIK there is no 100% reliable way to do this.
Please read https://docs.python.org/3/library/platform.html#platform.architecture for further ideas and caveats.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmF9klEtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh D1EP/RaEh9RpDx00oWvNNx6YNHvrKJXl1oDZS73kZbBFWZFPSXFN5i8yMGnEEdvm ldOOgaxxSfdSCfAmvh3ptnBRyRaXHQ33IXG2MfCE46hUpyylcDhXkebUWz397f62 kTPTzDNLLpVhSTYl8uaZ1foE0IYC5nuPsuKXtsNzesgmVWsv0DdsIuhSJGCBJ6Zi YD4TUX6B7vvTmCISWEYHadJiyytizRMT0m/Cd6N2EboZfoUaicqIh4oiICJEUNwG 2GeMphgI0ngXjpHvboNucZ+oN4OeMqmN6MFhY8s4/2Ym/Gt3CehNaesGXABRcdC7 aBPi+Earq4r/+IlcbHdQBSPJRuWdtYfSfPml7YovCYmPLcVBH1Bv8WZcX1xDeSCw yuArbsZlq8Om1SglmT6dJdNOY8acCGXLU81gnhIAhbVl7J8R/136FI2Zk/84oE25 CsEvfq+vUUICF3ZApnQ4vciyJzfJfolTZnKifTw/+B3OrHXx6OBkc61wYKpSoyLY DZGb5C2ztB4e2sJXMIqOMjo5R/Jy5zieXXnvIph+xK09uSohsYp6i3gvY/9VDZaj 9qdUNdvTeAQn2MDGdDQcKI40mNBE5vyrXAUveEruDN8A2NC0PbRa0a9smnzd9I3D CkGq/N1CKH6VeaikuAmHqUEhHLGrjf+EJfAPIM2spon90OuR
=oGP0
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ole (2021.10.30_12:20:40_+0000)

How can one find out the correct machine here?

sys.implementation._multiarch will return the Debian multiarch tuple
that python was built for.

SR

--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: [email protected]

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GbETFFKkevUCp8BpsmDNRGBN5BO5pRl99
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hi Ole,

On 10/30/21 5:50 PM, Ole Streicher wrote:

Hi,
https://salsa.debian.org/debian-astro-team/pyraf/-/jobs/2130878#L2062

How can one find out the correct machine here?

I just committed something to salsa -- sort of a hack, but it works (i386 pipeline passes). I do this
for one of my other package as well. Please consider taking a look.

Nilesh





--GbETFFKkevUCp8BpsmDNRGBN5BO5pRl99--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmF9m4sFAwAAAAAACgkQALrnSzQzafGy 2RAAjHWi9VIKZfobjQibOHix4UVI//S8BeO+WQhNesiSbI473cL+BBS+Ww6HYdMv1M38EZ+8GWfi Pmd6gNSW82fW3/Kfym3E4d7w0QlDYh//A9l1QxgMFX/qvzEGGq6VU24/wswgmab9LTOZAASpVV6W OPydkSEZ3TcrLirwwShV7IepVk7Z92cYMpD1TPev6IZK23R9cziXqA2UBZihelVMEsXzj7vIj75j sMTrXsepYZTW/rzUc+LHcqo1w0ptcFO2DiK0D4Z7/mRc4wofk+hpqU+uJqo/I885AshmH5Y9XqfL dGgLk4Con9hl/EkbOcJhhCGrezT4eJqJFy/r7s/0mTA7wzQJfKyYQa+rqAEDHh3pE0gbOBLHEPgM 7U2XH66YB3l667BgpBYjmkuQFjjNmgjB3thB/m0lMng7UOuDqFhoRfLLVjGDsLaeJZDAYDja1HxM P4oOdeXAYI5sLx2uaLxI57bUYZxJVH/MBBx1FVvKaAU/w7QOkhdgkpfuwVaA0Us5zqG0La/7SQrI FOBqj56wcNqm1J8IRh97uN/yxarbtyrrEmKF8e30uKiStNqKk0mo4gkSs/gA5V8HkB4fmy47/odR 3FEBzT5rFOgvTKgXyY0gZW+J8zYn5PM9Hif8OztG5ZMS4xUNFGA/Dr/pPZSHknJBbnjFx35tFXLW NFg=
=P7uq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Nilesh, Andrey,

Nilesh Patra <[email protected]> writes:

On 10/30/21 5:50 PM, Ole Streicher wrote:

Hi,
https://salsa.debian.org/debian-astro-team/pyraf/-/jobs/2130878#L2062
How can one find out the correct machine here?

I just committed something to salsa -- sort of a hack, but it works
(i386 pipeline passes). I do this
for one of my other package as well. Please consider taking a look.

Thank you, but I think I will not use it: This requires dpkg-dev (which
is the package with dpkg-architecture) being installed, which I would
not like to depend on just to have the possibility to test.

I will rather follow Stefanos hint to use sys.implementation._multiarch,
which is however hackish as well, since variables starting with "_"
should not considered as part of the API, and this may break without
warning.

Optimal would be a way to detect whether the internal floating point
processing happens with 80 bit FPU registers (i386) or 64 bit FPU
registers (other systems), since this is the relevant difference here.

Best regards

Ole

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/30/21 8:43 PM, Andrey Rahmatullin wrote:

On Sat, Oct 30, 2021 at 02:20:40PM +0200, Ole Streicher wrote:

I have a package (pyraf) where I need to switch off some tests for i386
(but not for other 32-bit platforms). I do this by

import platform
is_i386 = platform.machine() in ('i386', 'i486', 'i586', 'i686')

Yup, this is incorrect. This is the same as `uname -m` and so returns the kernel architecture.
If you want to do this purely at the upstream side without checking DEB_HOST_ARCH, AFAIK there is no 100% reliable way to do this.

I would also advise to use DEB_HOST_ARCH... Maybe with some fallbacks if
you wish to upstream it?

Cheers,

Thomas Goirand (zigo)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)