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 Dan _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
