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.
Cheers,
Javi
Attachment:
signature.asc
Description: Digital signature