Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

[Markus Koschany]

On 20.02.2017 01:56, Steve Cotton wrote:
> On Sun, Feb 19, 2017 at 09:38:12PM +0100, Steve Cotton wrote:
>> Sorry, but it's turned out that my patch either doesn't completely
>> avoid the bug, or doesn't avoid another bug which gives the same error
>> message.  The build has failed on arm64.
> 
> I've tried to reproduce this locally (on amd64, not arm64).  With my
> patch, I can't replicate the failure. Santiago, please would you test
> how it fares on your autobuilders?
> 
> Testing by removing my patch and trying to debug the root cause, I
> haven't found the cause yet.  But I think it will need a complex patch
> to either libsdl1.2 or xvfb, and I don't think this bug justifies any
> complex patch during the freeze.
> 
> It seems that one of the XOpenDisplay calls in SDL's X11VideoInit fails.
> Having a GCC breakpoint at the start of X11VideoInit, or running MakeDat
> under strace, makes the bug unreproducible.  Adding a long sleep to the
> last point in the ri-li package's code before SDL_Init doesn't help.
> Running another SDL programe first in the same xvfb server doesn't
> change anything, so it seems that the server can't be primed in advance.
> 
> Markus, I'm really sorry that what looked like a risk-free patch has
> caused a failed rebuild.  Depending on the TC's ruling, does it sound
> sensible to say that 2.0.1+ds-4 is in Stretch, and -5 doesn't affect -4?

Hi Steve,

no worries and thanks for providing a helping hand here. I've also tried
a couple of different options in the past hours. I think your initial
patch wasn't completely wrong and the underlying issue has something to
do how SDL initializes its subsystems but I have reverted it for now.

I have read about issues when using SDL in virtual machines but I have
found only one clue namely to manually link with -lX11 to avoid this
kind of error. I have tried this solution at least 20 times on
asachi.debian.org (arm64 porterbox) and couldn't reproduce the build
failure anymore.

I have uploaded another revision a few minutes ago. -5 and -6 don't
affect Stretch. I don't know about a TC ruling but since it is obvious
that the claim of "99 %" build failures is not true I stand by my
opinion that this is not release critical.

We could also stop building the data from source but this isn't
something I would call an improvement over the current situation.

Regards,

Markus


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20170220/53b79222/attachment.sig>