Forwarding to d-python, who might know of a solution to this issue. The gist of it is that we are looking for a suitable solution to bypass a specific test which is failing on a subset of 32-bit architectures (i386 only).
My initial patch was quite blunt and disabled the test for any 32-bit arch, and James proposed a different solution based on a subprocess call to dpkg-architecture. Do you guys have any suggestion of a more Pythonic way to achieve this? Cheers, Ghis On Tue, 2017-01-17 at 23:36 +0000, Ghislain Vaillant wrote: > On Tue, 2017-01-17 at 20:39 +0000, James Clarke wrote: > > On Tue, Jan 17, 2017 at 07:59:25PM +0000, Ghislain Vaillant wrote: > > > Hi James, > > > > > > Le 17 janv. 2017 7:44 PM, "James Clarke" <jrt...@debian.org> a écrit : > > > > > > On Tue, Jan 17, 2017 at 07:22:32PM +0000, Ghislain Vaillant wrote: > > > > Dear all, > > > > > > > > I am looking for a sponsor for python-cartopy: > > > > > > > > https://anonscm.debian.org/cgit/debian-science/packages/ > > > > > > python-cartopy.git > > > > > > > > > > > > Changes since the last upload: > > > > > > > > [ Andreas Tille ] > > > > * Do not force the package maintainer to install build-dependencies > > > > like > > > > geos on local machine > > > > > > > > [ Ghislain Antony Vaillant ] > > > > * Fix FTBFS on 32-bit architectures (Closes: #848634) > > > > New patch 0001-Skip-tests-failing-on-32-bit-architectures.patch > > > > > > > > > > > > The test skip patch is a result of upstream being not responsive to the > > > > issue so far. Since the failing test is fairly minor, I see no reason > > > > to block the package for non 32-bit architectures. > > > > > > This doesn't look right; it only failed on i386 (and > > > hurd/kfreebsd-i386), but it built on armel, armhf, mips, mipsel, hppa, > > > m68k and powerpc. This is not a 32-bit issue, but an x86 floating-point > > > issue, most likely because the x87 FPU uses 80-bit floats internally. > > > > > > > > > Would you have a better patch to propose then? > > > > > > If you're going to disable the test, please do so *only* if the CPU is > > > i386. > > > > > > > > > I only know how to test for 32-bit, not for *i386 specifically, in Python. > > > Please advise if you do. > > > > There are platform.architecture()/machine()/processor(), but processor() > > seems to give '' on Debian, machine() will give x86_64 if using an i386 > > chroot on an amd64 host, and architecture() just gives ('32bit', ''). > > Not to mention that platform.architecture is notoriously unreliable to > detect bitness from my initial reading (Python docs and SO). > > > Then there's the additional complication that x32 is a 32-bit version of > > amd64, so it shouldn't fail the test. Therefore, I would propose > > something like the following Debian-specific hack: > > > > host_cpu = subprocess.check_output(['dpkg-architecture', > > '-qDEB_HOST_ARCH_CPU']) > > if host_cpu != 'i386': > > # Do the assert > > Is it really worth going to so much trouble for just one test, you > reckon? I understand your rationales for it and appreciate the > pointers, but my pragmatic self is wondering whether putting such hack > in place would be worth the reward from a maintenance perspective. > > > I would be interested to know if there's a way of doing this without > > having to call dpkg-architecture. > > I would prefer such a solution too, TBH. > > Ghis