[Debian-med-packaging] Bug#845753: Help: r-cran-treescape does not build on i386, armel and armhf any more

[Christian Seiler]

Hi Andreas,

On 12/14/2016 08:10 AM, Andreas Tille wrote:
> On Wed, Dec 14, 2016 at 12:32:24AM +0100, Christian Seiler wrote:
>> On 11/02/2016 05:20 PM, Andreas Tille wrote:
>>
>> Hmm, was going to take a shot at debugging your segfault, but I
>> simply can't reproduce this:
>> ...
>> architectures.
> 
> Unfortunately autobuilders keep on reproducing it. :-(

:-(

> I have uploaded a package where I fixed the xvfb issue and did a source
> only upload to make sure also amd64 will be autobuilt.  While amd64 is
> fine (also regarding the xserver issue - thanks to Gregor for the hints)
> the i386 build log[1] shows the
> 
> ** inst
> ** preparing package for lazy loading
> Creating a generic function for 'toJSON' from package 'jsonlite' in package 'googleVis'
> Error: segfault from C stack overflow
> * removing '/«PKGBUILDDIR»/debian/r-cran-treescape/usr/lib/R/site-library/treescape'
> 
> again even if the log also has gcc-6-base i386 6.2.1-6  and binutils
> i386 2.27.51.20161212-1 - so the toolchain on autobuilder is the same as
> it worked for you.

Yeah. Hmmm. :(

>  There might be a difference between a qemu emulation
> and real hardware, thought.

But emulation is only for armhf, i386 is native on my architecture
(amd64 can run i386 directly, and the autobuilders are also amd64
machines running i386 chroots, my setup should be identical).

Funnily enough mipsel now also failed at the same point, which it
previously didn't.

The only other key difference I can see is that the failed builds
all run a stable kernel - and the working builds (also the build
previously working on powerpc) run a backports kernel (and I'm
running testing here). OTOH, the amd64 and arm64 builds are also
running on the stable kernel - but those are 64bit platforms.
Then OTOH in the ports section of the buildd logs you have 32bit
powerpc - and that is also on stable, but powerpc is big endian,
in contrast to i386, armhf and mipsel.

I'm really not sure what's going on there, but maybe there's a
failure case for 32bit little endian architectures when running
a 3.16 kernel? But that may be a complete red herring and
coincidence...

I'm going to try an i386 build in a VM running a stable kernel
and see if that does indeed change things and if I can reproduce
the problem. Should that not be the issue though then I really
can't reproduce the problem - and hence won't be able to debug
it... Let's see...

Regards,
Christian