On Wed, Oct 20, 2010 at 09:23, Dan S <[email protected]> wrote: > 2010/10/20 Felipe Sateler <[email protected]>: >> On Tue, Oct 19, 2010 at 04:02, Dan S <[email protected]> wrote: >>> 2010/10/19 Felipe Sateler <[email protected]>: >>>> On Sat, Oct 16, 2010 at 11:15, Dan S <[email protected]> wrote: >>>>> 2010/10/9 Alexandre Quessy <[email protected]>: >>>>>> Hello Felipe and the team, >>>>>> >>>>>> 2010/10/6 Felipe Sateler <[email protected]>: >>>>>>> On 09/21/2010 01:40 PM, Alexandre Quessy wrote: >>>>>>>> There are quite a few lintian warnings, but I tried the vim plugin and >>>>>>>> it works. >>>>>>> >>>>>>> Yes, quite a bit. The package needs a lot of work. First of all, >>>>>>> debian/copyright needs some serious overhaul. Are you familiar with the >>>>>>> codebase? If so, please take a look at that. >>>>>> >>>>>> No much familiar, no. Dan would know better than me. >>>>> >>>>> What sort of overhaul is needed? There are quite a few different >>>>> copyrights asserted, making it fairly bulky, but I don't spot any >>>>> wrongness. >>>> >>>> For starters, a whole lot of paths are wrong (they are missing the >>>> common/ subdir prefix). Hmm, maybe serious overhaul is an >>>> overstatement, but getting the right paths is a must, and made me >>>> doubt the overall quality of the file, perhaps indicative of neglect. >>> >>> Ah thankyou. Yes that is neglect but fairly recent neglect, we >>> reorganised the folder structure before 3.4 but it seems we forgot the >>> paths in the copyright folder. >> >> Great. >> >>> >>> OK I've fixed it now in svn. >>> <http://supercollider.svn.sf.net/viewvc/supercollider/packages/ubuntu/copyright?r1=10329&r2=10403> >>> Feel free to pull it in. (I'd like to help with the debian packaging >>> git - could I be given access or should I start my own git and send >>> pull requests?) >> >> No, join our team and then clone the ssh address of our repository. >> >>> >>>>>>> Where did you get the packaging from? Upstream? >>>>>> >>>>>> Yes. I took it from the upstream SVN repository. Dan has done one more >>>>>> - at least - after I took it, though. He might have removed some >>>>>> files. I specifically told him about some proprietary files that he >>>>>> removed. I'll double check this and let you know. >>>>>> >>>>>> If Dan would tell us what he changed meanwhile, that would help. Dan? >>>>> >>>>> I removed common/Source/lang/LangPrimSource/HID_Utilities/* since that >>>>> had an apple copyright with a dubious gpl compatibility, and (in the >>>>> svn packaging info) removed the apple entry from debian/copyrights as >>>>> a result. >>>>> (To be more accurate: We have a script that makes a pruned >>>>> linux-source .tar.gz, so what I did was to add the folder to the list >>>>> of what gets pruned out. The folder is still there in the upstream and >>>>> used on mac.) >>>> >>>> Where is this pruned linux-source tar.gz? Our repository seems to have >>>> the SuperCollider-3.4-Source-With-Extras-linux.tar.gz file from >>>> sourceforge with md5sum 20631117a7e9fb1c862833ce424ce9f4. Should we be >>>> using the without extras variant? Or maybe even another tarball? >>> >>> With-extras should be fine, however so far I've only tweaked the >>> not-with-extras one to remove the Apple files >>> (SuperCollider-3.4-rev2-Source-linux.tar.gz at >>> http://sourceforge.net/projects/supercollider/files/Source/3.4/ ). >>> We're hoping to get 3.4.1 released very soon so I'll include these >>> tweaks in that. >> >> What are the extras? The without extras tarball seems to be much smaller. > > Actually I think we should not include the extras for now, because > that could muddy the process.
OK. So, if I understand correctly, we should use the -rev2 version without extras? > The extras are essentially third-party > addons, two types of thing: plugins for the audio server, and add-ons > for the language. They're both GPL but the copyrights and other things > would be a bit awkward, and there are additional dependencies and > other stuff. (The extras are more loosely policed than the core.) Are they also released indepently of the core? If so, we could package it separately, which may simplify things. -- Saludos, Felipe Sateler _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
