Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Felipe Sateler]

On Wed, Mar 9, 2011 at 20:24, Felipe Sateler <fsateler at debian.org> wrote:
> On Wed, Mar 9, 2011 at 10:23, Dan S <danstowell+debmm at gmail.com> wrote:
>> 2011/3/8 Felipe Sateler <fsateler at debian.org>:
>>> On Wed, Mar 2, 2011 at 23:32, Dan S <danstowell+debmm at gmail.com> wrote:
>>>> 2011/2/25 Felipe Sateler <fsateler at debian.org>:
>>>>> On Sun, Feb 20, 2011 at 20:59, Felipe Sateler <fsateler at debian.org> wrote:
>>>>>> On Sat, Feb 19, 2011 at 17:46, Dan S <danstowell+debmm at gmail.com> wrote:
>>>>>>> 2010/10/31 Felipe Sateler <fsateler at debian.org>:
>>>>>>>> Package: wnpp
>>>>>>>> Severity: wishlist
>>>>>>>> Owner: pkg-multimedia-maintainers at lists.alioth.debian.org
>>>>>>>>
>>>>>>>> * Package name    : supercollider
>>>>>>>>  Version         : 3.4
>>>>>>>>  Upstream Author : Lots of people
>>>>>>>> * URL             : http://supercollider.sourceforge.net
>>>>>>>> * License         : mostly GPL, some BSD, CC-BY-SA-3.0
>>>>>>>>  Programming Lang: C++
>>>>>>>>  Description     : A real time audio synthesis programming language
>>>>>>>>
>>>>>>>> SuperCollider is an environment and programming language for real time
>>>>>>>> audio synthesis and algorithmic composition. It provides an interpreted
>>>>>>>> object-oriented language which functions as a network client
>>>>>>>> to a state of the art, realtime sound synthesis server.
>>>>>>>
>>>>>>> OK, status of the supercollider packaging. Here's what I wrote on 4th
>>>>>>> jan (re a patch to add versioning to the soname):
>>>>>>>
>>>>>>>> The patch is in, upstream. What's happening right now is we're
>>>>>>>> preparing a 3.4.2 release, which will include this patch. (release
>>>>>>>> candidate files are at
>>>>>>>> <http://sourceforge.net/projects/supercollider/files/Source/3.4.2/>)
>>>>>>>>
>>>>>>>> The neatest thing is to wait for 3.4.2 official release, then import
>>>>>>>> it to the deb-mm repo and tweak the scripts for .so.1. Should be soon!
>>>>>>>
>>>>>>> Since then, there's been some delay in supercolliderland due to
>>>>>>> debating garbage-collection issues in the development branch. We can
>>>>>>> either wait more, or apply the patch downstream, in which case it
>>>>>>> would I think be ready for others to try? What's the next step once
>>>>>>> we're OK with the packaging?
>>>>>>
>>>>>> Since the patch is already applied upstream, and we are likely to wait
>>>>>> a while before 3.4.2 is out, it should be OK to apply the patch
>>>>>> locally to 3.4.1 for now. Please do that, and update the packaging
>>>>>> accordingly.
>>>>>
>>>>> Ping?
>>>>
>>>> OK I've had a look at this tonight. There is a scons problem, which
>>>> lintian handily discovers for me. (Hooray lintian! I think.)
>>>>
>>>> The patched build script creates symlinks such as
>>>> libscsynth.so->libscsynth.so.1.0.0. However, when scons is installing,
>>>> it doesn't install a symlink but copies the file contents. Therefore
>>>> instead of one lib file and one symlink, we get two identical lib
>>>> files - and lintian correctly reports this as an error.
>>>>
>>>> I've been trying to find a way to convince scons to do the right
>>>> thing. I pushed an experimental branch to the git named
>>>> "scons_soversion" where instead of creating a symlink and asking scons
>>>> to install it, we add a symlinking command that should run during
>>>> installation. The problem is, that scons (v1.2.0) uses python chdir()
>>>> when running commands, which jumps it straight out of the DESTDIR and
>>>> tries to install in the system /usr/lib rather than the current build
>>>> tree. So I can't find a way of getting scons to create the symlink
>>>> during the install step AND inside DESTDIR. One or the other but not
>>>> both.
>>>>
>>>> If anyone can offer suggestions I'd be grateful.
>>>> http://git.debian.org/?p=pkg-multimedia/supercollider.git;a=shortlog;h=refs/heads/scons_soversion
>>>
>>> It seems to me that the problem you are having is because your
>>> debian/rules uses the --install-sandbox option instead of the
>>> handcoded (by upstream) DESTDIR variable handling in SConstruct.
>>
>> Interesting...
>>
>>> I've pushed a commit to that branch that apparently solves the issue.
>>
>> Great, works here, thanks.
>>
>> Someone else started the supercollider packaging (on ubuntu) and he
>> had reasons for going with --install-sandbox. He is bcc'ed here -
>> Artem please send me (or deb-mm) a mail if you have objections.
>>
>> I'll merge that branch into master, and send the change upstream (for
>> inclusion in 3.4.2).
>
> Remember to include the change in master as a patch instead of
> directly modifying SConstruct!

Ping?

-- 

Saludos,
Felipe Sateler