supercollider 3.7.0 in alioth to try

Felipe Sateler fsateler at
Tue May 10 17:23:21 UTC 2016

On 6 May 2016 at 13:32, Dan S <danstowell+debmm at> wrote:
> 2016-05-04 16:09 GMT+01:00 Felipe Sateler <fsateler at>:
>> On 4 May 2016 at 11:57, Dan S <danstowell+debmm at> wrote:
>>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler <fsateler at>:
>>>> On 25 April 2016 at 18:12, Felipe Sateler <fsateler at> wrote:
>>>>> On 20 March 2016 at 12:52, Dan S <danstowell+debmm at> wrote:
>>>>>> Hi all,
>>>>>> There's a new release of SuperCollider out (3.7) and I've imported and
>>>>>> updated the packaging at pkg-multimedia/supercollider.git . It builds
>>>>>> and works for me (on x64), and I'd like to ask others to have a look
>>>>>> at it and consider testing/uploading it.
>>>>> I reproduce the same failure as Hanno, also on x64:
>>>>> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation
>>>>> R_X86_64_32S against `.rodata' can not be used when making a shared
>>>>> object; recompile with -fPIC
>>>>> ../../external_libraries/libtlsf.a: error adding symbols: Bad value
>>>>> adding said -fPIC flag to tlsf target continues until:
>>>> <snip>
>>>>> /usr/bin/ld: cannot find -lQt5::OpenGL
>>>>> Could you have a look?
>>>> This seems to be a missing build-dep on libqt5opengl5-dev. It builds
>>>> fine after that.
>>>> BTW, why do we disable the testsuite?
>>> (Sorry for the delay - didn't spot your second message)
>>> Regarding the testsuite: IIRC it doesn't succeed on all archs, and
>>> that's beyond our control. In 2013 you asked the same question, you
>>> asked "Why disable the testsuite? After all, if it is failing, its for
>>> a reason...." and my answer was the following:
>>>> That's what I thought too at first. However it's not intended to be
>>>> packaged (it doesn't build anything), and after discussion with the
>>>> developer who actually made and maintains that testsuite, he wanted it
>>>> that way... (It's not really a testsuite of supercollider, btw, I
>>>> think covers the 'supernova' component.)
>> Heh, sorry for forgetting about that. I added a comment to that effect
>> to debian/rules.
> Thanks. Also thanks for the suggested build fixes. Now I've upgraded
> my OS I can finally confirm them, so I've pushed them (and proposed
> them upstream too).

So now we have several build failures:

All of them in the embedded oscpack, but not all of them the same. I
was going to suggest using the available library, but it is orphaned.
Anyone up to take the maintainance of oscpack?


Felipe Sateler

More information about the pkg-multimedia-maintainers mailing list