On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:
Done. I will have to add your license to the copyright of some of the Debian packaging.
What I do is maintain packaging licensing in debian/rules. And I (ideally, when not too lazy) do not add licensing info of others but instead request them to add it themselves. ;-)
Actually, git-buildpackage doesn't work anymore with this. I removed it locally... I am missing some point on how to use pristine-tar. It needs the upstream tarball in the parent directory, or so... working on this.
No, the whole point of pristine-tar is that the Git is fully self-contained: You need not put a tarball anywhere, git-buildpackage regenerates it as needed.
What fails now for you is that you simply grabbed by gbp.conf file wich contained not only what you needed but also a hint to use bzip2 compressed tarballs. The tarball actually contained in the Git currently is a good old gzip-compressed one so is ignored when you tell git-buildpackage to instead use bzip2 :-P
It does seem, however, from a quick glance, that some parts of the project is not arch-limited. It might be a good idea to split packaging to provide most possible to all archs.That would be nice, but it's probably going to be difficult. The jack-info, dc-ctl and midistream utilities could be packages separately, and should be useful for the multimedia-loving masses. Since scenic relies on milhouse, they could be packaged together. Again, I am a close-to-beginner in packaging, so I am not sure where to start, especially that the current build process is unified and using a single autotools configure.ac script. It would imply splitting it upstream, no?
Packaging typically goes like this: 1. Prepare 2. configure 3. build 4. install 5. reinstall into package area 6. tune packaging Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.So splitting into multiple packages is (more or less) a simple matter of adding more binary packages in debian/control and hinting in debian/*.install which autotools-installed parts each of them should contain.
Either json or simplejson is used upstream. Are you aware that those implementations are not fully interchangeable (one of them - I forgot which - do not follow JSON specs!), and they might be slow too? The Sugar project switched to python-cjson for these reasons.
Wouldn't it be simpler to depend on python (>= 2.6) | python-simplejson ? If not, I'll try with cjson.
Sure, if it works.What I warned about is that it those JSON implementations might not behave equally. And that I do not remember the details, but know for sure that the Sugar developers ended up switching to cjson and only that.
- 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/mailman/listinfo/pkg-multimedia-maintainers
