supercollider 3.7.0 in alioth to try

[Felipe Sateler]

On 10 May 2016 at 17:43, Dan S <danstowell+debmm at gmail.com> wrote:
> 2016-05-10 21:33 GMT+01:00 Felipe Sateler <fsateler at debian.org>:
>> 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.
>
> Possible, yes, should be. However note that the pack did get a minor
> tweak in the supercollider local copy, see first commit here:
> https://github.com/supercollider/supercollider/commits/master/external_libraries/oscpack_1_1_0

Hmm. Should be possible to include in the debian version of oscpack.
I'm not sure if that breaks abi, though. Would the inlined method
still show up in the shared library?

> I guess by "upload" you mean upload the latest (1.1.0) oscpack to unstable?
> https://packages.debian.org/source/sid/oscpack
> I don't see much harm in uploading, though I've no idea of the
> present/future state of the lib - seems to be a little stale at
> present.

As long as there are users... Right now sc would be the only one.

But if the lib is dead, then probably sc (upstream) should not rely on it.

-- 

Saludos,
Felipe Sateler