On Sat, Jan 26, 2013 at 01:45:44PM +0000, Javi Merino wrote: > Hi Laszlo, > > On Fri, 21 Dec 2012 22:50:40 +0000, Laszlo Boszormenyi wrote: > > On Wed, 2012-12-19 at 19:55 +0000, Adam D. Barratt wrote: > > > On Sat, 2012-11-24 at 13:34 +0000, Adam D. Barratt wrote: > > > > On Fri, 2012-11-09 at 23:08 +0100, Jelmer Vernooij wrote: > > > > > On Fri, 2012-11-09 at 06:08 +0000, Adam D. Barratt wrote: > > > > > > It also itself FTBFS on a few architectures - see > > > > > > https://buildd.debian.org/status/package.php?p=python-greenlet&suite=wheezy > > > > > > ; armel and mips{,el} are regressions from the current testing > > > > > > package. > > > > > > > > > > > Thanks, I should've noticed that but hadn't. This is quite surprising > > > > > too, I don't see anything in the NMU that might be the cause of this. > > > > > > > > I suspect the issue was already there - see #665890, which is also fixed > > > > in sid already. > > > > > > Laszlo, any chance of a fixed version? > > The good is that upstream uses git, I could check the individual > > commits. The bad is that the places where it FTBFS are assembly codes. > > Upstream reworked that parts with the relevant C code as well. So it's > > not easy, I'd say impossible for me to backport those changes. I don't > > speak ARM nor Sparc ASM at least. > > You can find more info on how to fix the FTBFS in armel in #697406. > Peter says that building python-greenlet from TPU with the version of > platform/switch_arm32_gcc.h from 0.4.0 solves the issue in armel.
I've uploaded python-greenlet_0.3.1-2.2 to TPU which fixes the build for armel (tested in a porterbox). This won't fix the SPARC one though.
signature.asc
Description: Digital signature