On Wed, Mar 2, 2011 at 23:32, Dan S <danstowell+de...@gmail.com> wrote:
> 2011/2/25 Felipe Sateler <fsate...@debian.org>:
>> On Sun, Feb 20, 2011 at 20:59, Felipe Sateler <fsate...@debian.org> wrote:
>>> On Sat, Feb 19, 2011 at 17:46, Dan S <danstowell+de...@gmail.com> wrote:
>>>> 2010/10/31 Felipe Sateler <fsate...@debian.org>:
>>>>> Package: wnpp
>>>>> Severity: wishlist
>>>>> Owner: email@example.com
>>>>> * 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
>>>>> 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
> 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
> If anyone can offer suggestions I'd be grateful.
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.
I've pushed a commit to that branch that apparently solves the issue.
pkg-multimedia-maintainers mailing list