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: pkg-multimedia-maintainers@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. I've pushed a commit to that branch that apparently solves the issue. -- Saludos, Felipe Sateler _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
