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