supercollider 3.7.0 in alioth to try

[Felipe Sateler]

On 10 May 2016 at 17:05, Dan S <danstowell+debmm at gmail.com> wrote:
> 2016-05-10 18:23 GMT+01:00 Felipe Sateler <fsateler at debian.org>:
>> On 6 May 2016 at 13:32, Dan S <danstowell+debmm at gmail.com> wrote:
>>> 2016-05-04 16:09 GMT+01:00 Felipe Sateler <fsateler at debian.org>:
>>>> On 4 May 2016 at 11:57, Dan S <danstowell+debmm at gmail.com> wrote:
>>>>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler <fsateler at debian.org>:
>>>>>> On 25 April 2016 at 18:12, Felipe Sateler <fsateler at debian.org> wrote:
>>>>>>> On 20 March 2016 at 12:52, Dan S <danstowell+debmm at gmail.com> 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:
>>
>> https://buildd.debian.org/status/package.php?p=supercollider
>>
>> 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.

BTW, is it possible to use a system oscpack? It looks like the library
is barely ever updated, so maybe I could just bite the bullet and
upload it.

[1] https://anonscm.debian.org/cgit/pkg-multimedia/supercollider.git/tree/debian/rules#n25

-- 

Saludos,
Felipe Sateler