Re: RFS: python-cartopy/0.14.2-2
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" <jrtc27@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
Reply to: