Bug#602050: ITP: supercollider -- A real time audio synthesis programming language
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/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/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/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
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
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/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
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
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/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
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
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/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
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/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/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
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/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
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/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/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
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
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/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/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
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
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
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
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