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

[Dan S]

2011/4/10 Felipe Sateler <fsateler at debian.org>:
> On Sun, Apr 10, 2011 at 04:34, Dan S <danstowell+debmm at gmail.com> wrote:
>> 2011/4/10 Felipe Sateler <fsateler at debian.org>:
>>> On Mon, Apr 4, 2011 at 03:06, Dan S <danstowell+debmm at gmail.com> wrote:
>>>> 2011/4/4 Felipe Sateler <fsateler at debian.org>:
>>>>> On Mon, Mar 28, 2011 at 18:42, Dan S <danstowell+debmm at gmail.com> wrote:
>>>>>> 2011/3/28 Dan S <danstowell+debmm at gmail.com>:
>>>>>>> 2011/3/28 Felipe Sateler <fsateler at debian.org>:
>>>>>>>>>>> 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?
>>>>>>>
>>>>>>> Thanks for the nudge - now committed. Any feedback welcome - this was
>>>>>>> the first time I used quilt "properly"
>>>>>>
>>>>>> ...and now SC 3.4.2 has been released on the same day. So I've
>>>>>> imported it into the git (3 patches no longer needed, hooray) - all
>>>>>> testing and feedback welcome.
>>>>>
>>>>>
>>>>> Looks like you didn't actually merge the upstream branch into master
>>>>> but instead imported the new tarball as a new commit.
>>>>
>>>> I used git-import-orig, surely that's the right thing to do?
>>>> <http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM>
>>>
>>> Hmm, it seems to have done a broken import. Did it actually succeed in
>>> the merge?
>>
>> Yes it did. If there's anything I should do that can fix this, please
>> let me know.
>>
>> There will be a version 3.4.3 out fairly soon (3.4.2 has a
>> regression!) so I'll need to know how to import it right.
>
> Hmm, I usually just call git-import-orig on the tarball and all the
> magic is done. I'm not sure what could have gone wrong.
>
> If 3.4.3 will be out soon, then maybe we can let this one go and do
> the 3.4.3 on right instead.

OK, well I'll do it the same way when 3.4.3 is out, but I'll do a test
run and try to make sure the commits are as expected before pushing!


> On to more general comments:
>
> - Shared libraries have to be on a package of their own. See policy
> section 8. For this package it means we need new binary packages
> called libsclang1 and libscsynth1 with the shared library. The .so
> symlinks should go in the dev package.

OK, done this, but lintian tells me:

W: libsclang1: package-name-doesnt-match-sonames libsclang1.0.0
W: libscsynth1: package-name-doesnt-match-sonames libscsynth1.0.0

Not sure what to do from here, whether the package name needs the
decimals (yuck) or the soname needs to lose the decimals (& do we then
need another soflink libsclang1->libsclang1.0.0)?


> - Is the sc-common-dev and sc-dev split really necessary?

It has a purpose: sc-dev is the dev files for working with the
language API, which would be irrelevant for someone doing work with
the server (e.g. a plugin). However, it might be worth thinking about
lumping them all together since after all it's just some header files
- I'll mention it to the devs and see what we think.


> - Add yourself to th Uploaders field.

OK

Thanks
Dan