Supercollider is FTBFS

[Felipe Sateler]

On Wed, Oct 16, 2013 at 6:51 PM, Dan S <danstowell+debmm at gmail.com> wrote:
> 2013/9/30 Felipe Sateler <fsateler at gmail.com>:
>> On Thu, Sep 12, 2013 at 5:48 AM, Dan S <danstowell+debmm at gmail.com> wrote:
>>> 2013/9/11 Felipe Sateler <fsateler at gmail.com>:
>>>> On Tue, Sep 10, 2013 at 8:12 PM, Felipe Sateler <fsateler at gmail.com> wrote:
>>>>> In all archs except i386 and amd64 :(
>>>>>
>>>>> So far I have the following that works,
>>>>
>>>> Hmm, turns out it doesn't. sclang needs atomic too.
>>>
>>> Well, FWIW the patch certainly looks tolerable to me. I understand
>>> your concern about the linking. I don't (afaik) have a way to poke
>>> around with those other archs myself.
>>
>> We could try to get you access to debian porterboxes[1].
>> [1]http://dsa.debian.org/doc/guest-account/
>
> Oops, I completely didn't answer this email. Sorry. Yes, I'd be happy
> to try some testing on porterboxes if debian people are OK to let me
> in.

I'm willing to sponsor you. Please send a mail with the details so
that I can sign it and open the request. Please use the same key you
are using for signing the upstream tarballs in git.

>
>> Can we force disabling of all these optimizations in untested archs?
>
> You mean the use of boost-lockfree and boost-atomic? I'm afraid
> they're baked in, there are no alternative un-optimised code paths. It
> could partially be done by restricting the "supercollider-supernova"
> package just to i386 and amd64 (note that supercollider-supernova is
> an alternative non-default implementation of supercollider-server, so
> not so necessary). But then, the libs are used elsewhere around the
> code, so that doesn't actually help...

Sigh... So that means either dropping non-x86 arches, or getting boost
to work everywhere...

-- 

Saludos,
Felipe Sateler