supercollider 3.7.0 in alioth to try

Dan S danstowell+debmm at
Tue May 17 22:39:00 UTC 2016

2016-05-10 22:02 GMT+01:00 Felipe Sateler <fsateler at>:
> On 10 May 2016 at 17:43, Dan S <danstowell+debmm at> wrote:
>> 2016-05-10 21:33 GMT+01:00 Felipe Sateler <fsateler at>:
>>> On 10 May 2016 at 17:05, Dan S <danstowell+debmm at> wrote:
>>>> 2016-05-10 18:23 GMT+01:00 Felipe Sateler <fsateler at>:
>>>>> 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?
>>>> One thing to note: it's only "supernova" that makes use of oscpack,
>>>> and supernova is optional since it's a drop-in replacement for
>>>> "scsynth".
>>>> So, one cop-out alternative available to us (if oscpack isn't getting
>>>> fixed) is that on some platforms we could disable building it
>>>> (-DSUPERNOVA=0) and disable packaging it.
>>> We are already doing that[1], so that is a possible course of action.

I've just pushed some changes to restrict supernova to its target
archs. (Also finally worked out the lintian copyright-file complaint.)
I would hope that this fixes the builds on many archs, in the sense of
allowing the non-supernova builds to complete successfully. I don't
have access to those archs, however, so I haven't tested.


More information about the pkg-multimedia-maintainers mailing list