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

2011-06-12 Thread Dan S
2011/6/11 Jonas Smedegaard d...@jones.dk:
 On 11-06-11 at 03:07pm, Dan S wrote:
 It would be great if others can comment - anyone?

 I did a quick look (don't expect much involvement - am involved in too
 much at the moment already, and have some deadlines in RL too).

Thanks very much for these comments.

 This looks bad:

 # The build system apparently can't handle this
 CXXFLAGS =

 That and the DEB_SCONS_OPTIONS above it seems to indicate that it does
 not follow Debian Policy §4.9.1. Only a recommendation apparently, but I
 am uncertain if that only is _how_ to do it (i.e. DEB_BUILD_OPTIONS
 hinting) while the underlying mechanisms (e.g. ability to build without
 optimizations or without stripping binaries) is a must.

This is reasonable -- there's about to be a minor upstream release so
I'll try and patch upstream (even though it's a debianny issue), to
parse DEB_BUILD_OPTIONS.


 The -doc package should probably suggest the main package.  Similarly
 for the editor plugin packages (suggestions are too weak to cause a
 domino effect so are in my opinion best to declare explicitly).

OK


 Oh, and why do editor plugins recommend -doc package?  Seems they are
 tools to write code, not closely related to the documentation of the
 tool, so should perhaps be lowered to a suggestion.

I see your reasoning. Well, the documentation is not completely
independent - the editor-plugins include jump to the help for this
command-type features, and if the -doc is missing we get confused
users asking why the help-feature is broken. My inclination is for
Recommends here, for that reason - sounds OK?


 And I guess main packages not suggest/recommend -doc package too.

Sorry, what do you mean? You're saying perhaps that supercollider
should Suggest supercollider-doc? That sounds sensible.


 What is the most proper build-dependency for jack these days?  Here it
 is libjack-dev (= 0.100) | libjack-jackd2-dev, which as I believe is
 not wrong but seem to recall can be satisfied by a simpler dependency.

Ah right, the version 2 package is marked as Provides: libjack-dev
so we can simplify the dependency to libjack-dev (= 0.100). I
remember there being a reason for keeping both - but it might have
been for earlier versions, before that particular Provides was in
place.


 The clean rule does not fully cleanup.  These files was left behind:

  common/.sconf_temp/
  common/.sconsign.dblite
  common/config.log

I don't see this behaviour. (The clean rule contains an explicit rm
-f common/.sconsign.dblite so I'm not sure how it would happen.)
Could you give me the full commands to reproduce please?


 I will do an analysis on copyrights/licenses now - and hope not to find
 anything controversial there

Thanks

Dan


 Regards,

  - Jonas

 --
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


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

2011-06-12 Thread Dan S
2011/6/12 Dan S danstowell+de...@gmail.com:
 2011/6/11 Jonas Smedegaard d...@jones.dk:
 On 11-06-11 at 03:07pm, Dan S wrote:
 It would be great if others can comment - anyone?

 I did a quick look (don't expect much involvement - am involved in too
 much at the moment already, and have some deadlines in RL too).

 Thanks very much for these comments.

 This looks bad:

 # The build system apparently can't handle this
 CXXFLAGS =

 That and the DEB_SCONS_OPTIONS above it seems to indicate that it does
 not follow Debian Policy §4.9.1. Only a recommendation apparently, but I
 am uncertain if that only is _how_ to do it (i.e. DEB_BUILD_OPTIONS
 hinting) while the underlying mechanisms (e.g. ability to build without
 optimizations or without stripping binaries) is a must.

 This is reasonable -- there's about to be a minor upstream release so
 I'll try and patch upstream (even though it's a debianny issue), to
 parse DEB_BUILD_OPTIONS.

My mistake, it's not upstream, it's in the rules file.

 The -doc package should probably suggest the main package.  Similarly
 for the editor plugin packages (suggestions are too weak to cause a
 domino effect so are in my opinion best to declare explicitly).

 OK


 Oh, and why do editor plugins recommend -doc package?  Seems they are
 tools to write code, not closely related to the documentation of the
 tool, so should perhaps be lowered to a suggestion.

 I see your reasoning. Well, the documentation is not completely
 independent - the editor-plugins include jump to the help for this
 command-type features, and if the -doc is missing we get confused
 users asking why the help-feature is broken. My inclination is for
 Recommends here, for that reason - sounds OK?


 And I guess main packages not suggest/recommend -doc package too.

 Sorry, what do you mean? You're saying perhaps that supercollider
 should Suggest supercollider-doc? That sounds sensible.


 What is the most proper build-dependency for jack these days?  Here it
 is libjack-dev (= 0.100) | libjack-jackd2-dev, which as I believe is
 not wrong but seem to recall can be satisfied by a simpler dependency.

 Ah right, the version 2 package is marked as Provides: libjack-dev
 so we can simplify the dependency to libjack-dev (= 0.100). I
 remember there being a reason for keeping both - but it might have
 been for earlier versions, before that particular Provides was in
 place.


 The clean rule does not fully cleanup.  These files was left behind:

  common/.sconf_temp/
  common/.sconsign.dblite
  common/config.log

 I don't see this behaviour. (The clean rule contains an explicit rm
 -f common/.sconsign.dblite so I'm not sure how it would happen.)
 Could you give me the full commands to reproduce please?


 I will do an analysis on copyrights/licenses now - and hope not to find
 anything controversial there

 Thanks

 Dan


 Regards,

  - Jonas

 --
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers





___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


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

2011-06-12 Thread Dan S
2011/6/11 Jonas Smedegaard d...@jones.dk:
 On 11-06-11 at 03:07pm, Dan S wrote:
 It would be great if others can comment - anyone?

 I've updated debian/copyright.  Please check the FIXMEs in that file!

Thanks - a couple of questions:

* The PNG images in the help system are under the same CC license as
the HTML help files. (They were not externally sourced.) They're
already covered by the common/build/Help/* entry. Why mark them as
unknown?

* Files: common/Source/plugins/FilterUGens.cpp is marked as GPL-2+
and UNKNOWN, I guess because it includes code ported from Java code
by Federico Fontana. It was me that did the porting, and Federico gave
me permission to include it in this GPL-2+ software. So there's no
unknown licensing, but are you expecting some documentation or or
something?

* Also, you've allocated copyright of some associated files to
Federico Fontana (MoogFF.sc, MoogFF.html) yet he has no copyright in
those - I wrote them, they are not ported. So I can simply delete
those fixme entries, OK?


Most of the other stuff is just sloppy notices, which I'll try to get
fixed upstream.

Dan



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


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

2011-06-11 Thread Dan S
2011/5/17 Felipe Sateler fsate...@debian.org:
 On Mon, May 16, 2011 at 09:04, Dan S danstowell+de...@gmail.com wrote:
 2011/5/15 Felipe Sateler fsate...@debian.org:
 On Thu, May 12, 2011 at 06:07, Dan S danstowell+de...@gmail.com wrote:
 2011/5/11 Felipe Sateler fsate...@debian.org:
 Hi, sorry for taking so long.

 On Fri, Apr 29, 2011 at 15:57, Dan S danstowell+de...@gmail.com wrote:
 2011/4/16 Felipe Sateler fsate...@debian.org:

 - I would really like to fold all the -dev packages into one. I don't
 see much point in splitting them.

 I've discussed it with the upstream devs and we're OK with merging
 them, so I've done that.

 Good. However, the relationship with thte old packages is wrong. It
 should Replace the older packages.

 Ah right, thanks.

 However, I'm not quite sure if we
 should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
 Replaces+Conflicts+Provides).

 What do others think?

 In lieu of any other responses (so far), the latter
 (Replaces+Conflicts+Provides) seems to me to have the better
 semantics, although we're not talking about virtual packages (which
 policy 7.5 is pretty specific about). From reading the guide I can't
 decide either; unless anyone can advise, maybe we should go for
 Replaces+Breaks.

 Upon further reading, I think we should use
 conflicts+replaces+provides, because we are replacing whole packages.

 OK, done.

 I probably won't be able to dedicate much time to this during this
 week, so if anyone else can have a look at this package and comment on
 it, I'd appreciate it. I'd like to have more eyeballs looking at it
 since it is not a trivial package and I could have missed some things.

I'm very grateful for your help in polishing up this package (indeed,
non-trivial). It would be great if others can comment - anyone?
And if not, what are the next steps?

Thanks
Dan

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


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

2011-06-11 Thread Jonas Smedegaard
On 11-06-11 at 03:07pm, Dan S wrote:
 It would be great if others can comment - anyone?

I've updated debian/copyright.  Please check the FIXMEs in that file!


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

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

2011-05-17 Thread Felipe Sateler
On Mon, May 16, 2011 at 09:04, Dan S danstowell+de...@gmail.com wrote:
 2011/5/15 Felipe Sateler fsate...@debian.org:
 On Thu, May 12, 2011 at 06:07, Dan S danstowell+de...@gmail.com wrote:
 2011/5/11 Felipe Sateler fsate...@debian.org:
 Hi, sorry for taking so long.

 On Fri, Apr 29, 2011 at 15:57, Dan S danstowell+de...@gmail.com wrote:
 2011/4/16 Felipe Sateler fsate...@debian.org:

 - I would really like to fold all the -dev packages into one. I don't
 see much point in splitting them.

 I've discussed it with the upstream devs and we're OK with merging
 them, so I've done that.

 Good. However, the relationship with thte old packages is wrong. It
 should Replace the older packages.

 Ah right, thanks.

 However, I'm not quite sure if we
 should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
 Replaces+Conflicts+Provides).

 What do others think?

 In lieu of any other responses (so far), the latter
 (Replaces+Conflicts+Provides) seems to me to have the better
 semantics, although we're not talking about virtual packages (which
 policy 7.5 is pretty specific about). From reading the guide I can't
 decide either; unless anyone can advise, maybe we should go for
 Replaces+Breaks.

 Upon further reading, I think we should use
 conflicts+replaces+provides, because we are replacing whole packages.

 OK, done.

I probably won't be able to dedicate much time to this during this
week, so if anyone else can have a look at this package and comment on
it, I'd appreciate it. I'd like to have more eyeballs looking at it
since it is not a trivial package and I could have missed some things.

-- 

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


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

2011-05-16 Thread Dan S
2011/5/15 Felipe Sateler fsate...@debian.org:
 On Thu, May 12, 2011 at 06:07, Dan S danstowell+de...@gmail.com wrote:
 2011/5/11 Felipe Sateler fsate...@debian.org:
 Hi, sorry for taking so long.

 On Fri, Apr 29, 2011 at 15:57, Dan S danstowell+de...@gmail.com wrote:
 2011/4/16 Felipe Sateler fsate...@debian.org:

 - I would really like to fold all the -dev packages into one. I don't
 see much point in splitting them.

 I've discussed it with the upstream devs and we're OK with merging
 them, so I've done that.

 Good. However, the relationship with thte old packages is wrong. It
 should Replace the older packages.

 Ah right, thanks.

 However, I'm not quite sure if we
 should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
 Replaces+Conflicts+Provides).

 What do others think?

 In lieu of any other responses (so far), the latter
 (Replaces+Conflicts+Provides) seems to me to have the better
 semantics, although we're not talking about virtual packages (which
 policy 7.5 is pretty specific about). From reading the guide I can't
 decide either; unless anyone can advise, maybe we should go for
 Replaces+Breaks.

 Upon further reading, I think we should use
 conflicts+replaces+provides, because we are replacing whole packages.

OK, done.

Best
Dan

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-05-15 Thread Felipe Sateler
On Thu, May 12, 2011 at 06:07, Dan S danstowell+de...@gmail.com wrote:
 2011/5/11 Felipe Sateler fsate...@debian.org:
 Hi, sorry for taking so long.

 On Fri, Apr 29, 2011 at 15:57, Dan S danstowell+de...@gmail.com wrote:
 2011/4/16 Felipe Sateler fsate...@debian.org:

 - I would really like to fold all the -dev packages into one. I don't
 see much point in splitting them.

 I've discussed it with the upstream devs and we're OK with merging
 them, so I've done that.

 Good. However, the relationship with thte old packages is wrong. It
 should Replace the older packages.

 Ah right, thanks.

 However, I'm not quite sure if we
 should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
 Replaces+Conflicts+Provides).

 What do others think?

 In lieu of any other responses (so far), the latter
 (Replaces+Conflicts+Provides) seems to me to have the better
 semantics, although we're not talking about virtual packages (which
 policy 7.5 is pretty specific about). From reading the guide I can't
 decide either; unless anyone can advise, maybe we should go for
 Replaces+Breaks.

Upon further reading, I think we should use
conflicts+replaces+provides, because we are replacing whole packages.

-- 

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


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

2011-05-10 Thread Felipe Sateler
Hi, sorry for taking so long.

On Fri, Apr 29, 2011 at 15:57, Dan S danstowell+de...@gmail.com wrote:
 2011/4/16 Felipe Sateler fsate...@debian.org:

 - I would really like to fold all the -dev packages into one. I don't
 see much point in splitting them.

 I've discussed it with the upstream devs and we're OK with merging
 them, so I've done that.

Good. However, the relationship with thte old packages is wrong. It
should Replace the older packages. However, I'm not quite sure if we
should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
Replaces+Conflicts+Provides).

What do others think?


-- 

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


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

2011-04-29 Thread Dan S
2011/4/16 Felipe Sateler fsate...@debian.org:
 On Fri, Apr 15, 2011 at 18:45, Dan S danstowell+de...@gmail.com wrote:
 2011/4/15 Felipe Sateler fsate...@debian.org:
 On Fri, Apr 15, 2011 at 09:40, Dan S danstowell+de...@gmail.com wrote:

 I've tried to import 3.4.3 onto a clean repository (using
 git-import-orig) and it hit a merge conflict.

 A log of my session is at http://pastie.org/1792082 - I'd be
 grateful for any advice on whatever might have gone wrong. Am I using
 git-import-orig as intended?

 Yes. But the borked import of 3.4.2  breaks it. Try first merging from
 the upstream branch and then using git-import-orig.

 Ah, now I see. OK it works now, and all is looking good. My local git
 history (on master) now looks like
 http://pastie.org/1797302

 Please let me know if it looks like the right things have happened -
 then I'll push.

 Looks good to  me.

 OK pushed, thanks.

 Some more comments:

 - Do we really want an empty Extensions dir in the supercollider
 package? What purpose does it serve?

It's the place where users will place extensions (both server plugins
and language extensions). For usability purposes I think it's better
to have this rather than to expect people to create it (they may
misspell it, etc). It's inside SuperCollider's own folder
/usr/share/SuperCollider rather than cluttering anywhere else, so I'd
argue it's not a problem.


 - I would really like to fold all the -dev packages into one. I don't
 see much point in splitting them.

I've discussed it with the upstream devs and we're OK with merging
them, so I've done that.

Best,
Dan

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-04-16 Thread Felipe Sateler
On Fri, Apr 15, 2011 at 18:45, Dan S danstowell+de...@gmail.com wrote:
 2011/4/15 Felipe Sateler fsate...@debian.org:
 On Fri, Apr 15, 2011 at 09:40, Dan S danstowell+de...@gmail.com wrote:

 I've tried to import 3.4.3 onto a clean repository (using
 git-import-orig) and it hit a merge conflict.

 A log of my session is at http://pastie.org/1792082 - I'd be
 grateful for any advice on whatever might have gone wrong. Am I using
 git-import-orig as intended?

 Yes. But the borked import of 3.4.2  breaks it. Try first merging from
 the upstream branch and then using git-import-orig.

 Ah, now I see. OK it works now, and all is looking good. My local git
 history (on master) now looks like
 http://pastie.org/1797302

 Please let me know if it looks like the right things have happened -
 then I'll push.

 Looks good to  me.

 OK pushed, thanks.

Some more comments:

- Do we really want an empty Extensions dir in the supercollider
package? What purpose does it serve?
- I would really like to fold all the -dev packages into one. I don't
see much point in splitting them.

I pushed a few fixes.

-- 

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


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

2011-04-15 Thread Felipe Sateler
On Wed, Apr 13, 2011 at 14:58, Dan S danstowell+de...@gmail.com wrote:
 2011/4/10 Dan S danstowell+de...@gmail.com:
 2011/4/10 Felipe Sateler fsate...@debian.org:
 On Sun, Apr 10, 2011 at 04:34, Dan S danstowell+de...@gmail.com wrote:
 ...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!

 I've tried to import 3.4.3 onto a clean repository (using
 git-import-orig) and it hit a merge conflict.

 A log of my session is at http://pastie.org/1792082 - I'd be
 grateful for any advice on whatever might have gone wrong. Am I using
 git-import-orig as intended?

Yes. But the borked import of 3.4.2  breaks it. Try first merging from
the upstream branch and then using git-import-orig.


-- 

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


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

2011-04-15 Thread Dan S
2011/4/15 Felipe Sateler fsate...@debian.org:
 On Wed, Apr 13, 2011 at 14:58, Dan S danstowell+de...@gmail.com wrote:
 2011/4/10 Dan S danstowell+de...@gmail.com:
 2011/4/10 Felipe Sateler fsate...@debian.org:
 On Sun, Apr 10, 2011 at 04:34, Dan S danstowell+de...@gmail.com wrote:
 ...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!

 I've tried to import 3.4.3 onto a clean repository (using
 git-import-orig) and it hit a merge conflict.

 A log of my session is at http://pastie.org/1792082 - I'd be
 grateful for any advice on whatever might have gone wrong. Am I using
 git-import-orig as intended?

 Yes. But the borked import of 3.4.2  breaks it. Try first merging from
 the upstream branch and then using git-import-orig.

Ah, now I see. OK it works now, and all is looking good. My local git
history (on master) now looks like
http://pastie.org/1797302

Please let me know if it looks like the right things have happened -
then I'll push.

Thanks
Dan

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-04-15 Thread Felipe Sateler
On Fri, Apr 15, 2011 at 09:40, Dan S danstowell+de...@gmail.com wrote:

 I've tried to import 3.4.3 onto a clean repository (using
 git-import-orig) and it hit a merge conflict.

 A log of my session is at http://pastie.org/1792082 - I'd be
 grateful for any advice on whatever might have gone wrong. Am I using
 git-import-orig as intended?

 Yes. But the borked import of 3.4.2  breaks it. Try first merging from
 the upstream branch and then using git-import-orig.

 Ah, now I see. OK it works now, and all is looking good. My local git
 history (on master) now looks like
 http://pastie.org/1797302

 Please let me know if it looks like the right things have happened -
 then I'll push.


Looks good to  me.



-- 

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


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

2011-04-10 Thread Dan S
2011/4/10 Felipe Sateler fsate...@debian.org:
 On Mon, Apr 4, 2011 at 03:06, Dan S danstowell+de...@gmail.com wrote:
 2011/4/4 Felipe Sateler fsate...@debian.org:
 On Mon, Mar 28, 2011 at 18:42, Dan S danstowell+de...@gmail.com wrote:
 2011/3/28 Dan S danstowell+de...@gmail.com:
 2011/3/28 Felipe Sateler fsate...@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.

 Also, please push the upstream tag too.

Ah, sorry, now done.

Dan

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-04-10 Thread Dan S
2011/4/10 Felipe Sateler fsate...@debian.org:
 On Sun, Apr 10, 2011 at 04:34, Dan S danstowell+de...@gmail.com wrote:
 2011/4/10 Felipe Sateler fsate...@debian.org:
 On Mon, Apr 4, 2011 at 03:06, Dan S danstowell+de...@gmail.com wrote:
 2011/4/4 Felipe Sateler fsate...@debian.org:
 On Mon, Mar 28, 2011 at 18:42, Dan S danstowell+de...@gmail.com wrote:
 2011/3/28 Dan S danstowell+de...@gmail.com:
 2011/3/28 Felipe Sateler fsate...@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

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-04-10 Thread Felipe Sateler
On Sun, Apr 10, 2011 at 14:07, Dan S danstowell+de...@gmail.com wrote:
 2011/4/10 Felipe Sateler fsate...@debian.org:
 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)?

Usually the SONAME only contains the major number. Under standard
autotools, the scheme is as follows:

libfoo.so.x.y.z - the actual shared lib
libfoo.so.x - symlink to the shared lib, for run-time linkage
libfoo.so- symlink to the shared lib, for build-time linkage

Unless you plan to use the y and z versioning, you might as well just
have the x portion and just install the lib as libfoo.so.x:

libfoo.so.x - the actual shared lib
libfoo.so - symlink for build-time linkage.


 - 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.

Both are very small and there are no (massive) extra dependencies so I
think they can be folded into one package. Can the server-dev package
be folded in too?


-- 

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


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

2011-04-04 Thread Dan S
2011/4/4 Felipe Sateler fsate...@debian.org:
 On Mon, Mar 28, 2011 at 18:42, Dan S danstowell+de...@gmail.com wrote:
 2011/3/28 Dan S danstowell+de...@gmail.com:
 2011/3/28 Felipe Sateler fsate...@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

Dan

 Any ideas on how to fix this? One could revert the commit and do a
 proper merge, I guess. Any other options?

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-04-03 Thread Felipe Sateler
On Mon, Mar 28, 2011 at 18:42, Dan S danstowell+de...@gmail.com wrote:
 2011/3/28 Dan S danstowell+de...@gmail.com:
 2011/3/28 Felipe Sateler fsate...@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.

Any ideas on how to fix this? One could revert the commit and do a
proper merge, I guess. Any other options?


-- 

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


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

2011-03-28 Thread Dan S
2011/3/28 Felipe Sateler fsate...@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

Dan



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-03-09 Thread Dan S
2011/3/8 Felipe Sateler fsate...@debian.org:
 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.

Interesting...

 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).

Thanks
Dan



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-03-09 Thread Felipe Sateler
On Wed, Mar 9, 2011 at 10:23, Dan S danstowell+de...@gmail.com wrote:
 2011/3/8 Felipe Sateler fsate...@debian.org:
 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.

 Interesting...

 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!


-- 

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


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

2011-03-07 Thread Felipe Sateler
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


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

2011-03-02 Thread Dan S
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


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

2011-02-26 Thread Dan S
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?

Pong, thanks, I will do this, busy I'm afraid - unlikely to happen
this weekend but it's on my list

Dan



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2011-02-25 Thread Felipe Sateler
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?

-- 

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


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

2011-02-20 Thread Felipe Sateler
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.

-- 

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


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

2011-02-19 Thread Dan S
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?

Dan



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


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

2010-10-31 Thread Felipe Sateler
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.
   



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers