2010/11/3 Felipe Sateler <[email protected]>: > On Wed, Nov 3, 2010 at 06:32, Dan S <[email protected]> wrote: >> 2010/11/3 Felipe Sateler <[email protected]>: >>> 2010/11/2 Dan S <[email protected]>: >>>> 2010/10/31 Felipe Sateler <[email protected]>: >>>>> Артём, you are CCed because I don't know if you are subscribed to the >>>>> list. >>>>> >>>>> On Sat, Oct 16, 2010 at 11:09, Dan S <[email protected]> wrote: >>>>>> >>>>>> 2010/10/6 Felipe Sateler <[email protected]>: >>>>>> > Hi all, (Dan CCed because I'm not sure if you are subscribed to the >>>>>> > list) >>>>>> > >>>>>> > I managed to take a few minutes to take a look at the package and it is >>>>>> > not in a very good shape (it was still using simple-patchsys!). I have >>>>>> > worked a bit on it, but it still has a long way to go. I will try to >>>>>> > work on it during this week, I think I can find one hour or two. >>>>>> > >>>>>> > Dan, as you are part of upstream, could you comment on the patches >>>>>> > included in the packaging? I can see they are in upstream svn ubuntu >>>>>> > packaging module, with yourself as last commiter on most of them. They >>>>>> > are older than the latest sc release, though. >>>>>> >>>>>> Hi - sorry for slow reply, I missed this thread. Most of the patches >>>>>> are by other people but I will try to comment: >>>>>> >>>>>> 02_disable_elisp_compilation.diff >>>>>> - not sure I'm afraid, it's connected with the emacs sc3 mode, which >>>>>> I don't use. Looks like it might disable something from running simply >>>>>> because the build machine isn't the target machine. >>>>>> >>>>>> 03_fix_elisp_install_path.diff >>>>>> - another emacs mode thing, not sure. >>>>> >>>>> Does anyone use emacs and can comment on wether this should be applied >>>>> upstream? The patch changes the elisp install path from >>>>> /usr/share/emacs/site-lisp to /usr/share/emacs/site-lisp/supercollider >>>>> >>>>>> >>>>>> 06_deb_scvim.diff >>>>>> - build machine != target machine so don't error out if no ruby >>>>>> executable >>>>>> >>>>>> 07_deb_sced.diff >>>>>> - build machine != target machine so don't modify machine's mime >>>>>> database >>>>> >>>>> Dan, can you comment on whether these can be upstreamed? I don't see >>>>> why they should be debian-specific. >>>> >>>> Right, that makes sense. I've had a look at the scons scripts and not >>>> been able to integrate them in neatly (was hoping to add a nice option >>>> for not-installing-here - if anyone has the scons chops to suggest >>>> something then please do, I'd be grateful.) >>> >>> Can't do it, at least for the time being. >> >> np. In the medium-term, upstream is moving from scons to cmake; the >> build scripts will hopefully be less quirky! > > cmake does this automatically: rpath is used when building, but it is > stripped at install time. > >> >> >>>> FYI, supercollider 3.4.1 (bugfix release) has just been agreed, so is >>>> likely to come out very very soon without any further upstreaming. I >>>> hope that doesn't get in the way of debianising... would these patches >>>> be considered blocking issues, do you think? >>> >>> I'm not quite sure what you mean. If you mean that the patches are not >>> likely to be upstreamed before that, then it is no problem, we can >>> continue with the patches. >> >> Yes, that's what I meant, thanks. Just making sure I get the flow >> right, don't miss out anything I should be doing. > > Don't worry. > > By the way, the package needs to get the SONAME issue right, does > upstream have a stance on this?
We have had a long-term stable ABI and that's generally the philosophy, but we agreed that we should version the lib names anyway. One of the other devs has a patch for it that they're digging out... Dan _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
