Re: RFS: CLAM, C++ library for audio and music
Hi Vincent, thanks for answering.
On Thursday 04 September 2008 18:51:54 Vincent Bernat wrote:
> OoO Lors de la soirée naissante du mardi 05 août 2008, vers 18:18, David
> García Garzón <email@example.com> disait :
> > http://clam.iua.upf.edu/download/linux-debian-sid/svnsnapshots/
> Hi David!
> Please, file an ITP for this package. This will be useful to track any
> progress, especially if someone has handled the upload or not.
I filled it before sending the RFS:
> Moreover, the .dsc file is not signed.
Must the key be validated by any debian maintainer at all?
> The directory also contains
> multiple dsc files that appear to be extracted from the same
> source. There should be one dsc file generating multiple deb files for a
> given source repository.
They are extracted from the same subversion tree but they are modules that are
intended to be released independently (though they are almost released at the
clam <- The framework itself
clam-plugins <- Contributed plugins (maybe splitted in the future)
clam-networkeditor <- The prototyping tool
clam-annotator <- An example app
clam-smstools <- Annother example app
As they are different source packages i don't know whether I should fill a
single ITP bug and RFS request or just one for each.
> I see that there debian/ directory was contributed by a Debian
> Developer. Why not ask him to upload the package?
Paul was a friend of us and former coworker but he was too busy with his
current job and the packages he already maintains, and asked us to look for
another uploader. Don't blame him about the packaging errors, he just did
some fixes to our (upstream) intents to package it ;-)
> At first glance, here are the problems with the current package:
> - debian/changelog has an incorrect distribution
I think that dhc has an --distribution option that could do the work.
We are creating the dsc files from ubuntu and then generating all the packages
for debian and ubuntu with pbuilder using that same dsc. The script we are
using, at clam/CLAM/scripts/doDebianPackages.py, is very convenient for us to
provide non-official debian and ubuntu packages. But maybe not the way to
proceed when officializing the procedure. Any suggestions are wellcome in
> - Vcs-* fields is for Debian packaging, not upstream VCS repository
Debian packaging is currently maintained at the upstream VCS. That is also
very convenient for us at the moment as we are doing fixes to the packaging
as we do changes on the install. But we really need advice as this seems also
to produce some inconveniences. Being debian maintained in the same
repository, are those fields ok? Should we keep a separate repository? Could
we just to store the diff of the debian a part and keep most of debian
folders in upstream svn?
> - some of the files are licensed under MIT/X11, some are GPLv2 only
I guess they are included 3rd party files. Any suggestion on how to deal with
> - examples should be packaged with dh_examples
Do you mean dh_installexamples?
> and should not be just a tar.gz files. If someone installs this package,
he is aware that he
> will need some disk space for it.
Well i saw that qt4 package just ships a tarball. Is it that done by
dh_installexamples? Well i'll use dh_installexamples and see what i get.
> - debian/watch is useless for a SVN snapshot
watch is pointing to the stable tarballs which are the ones intended to be
distributed. I just sent the wrong link. Stable version of the packages are
No improvements regarding the packaging though. :-(
> - CFLAGS and INSTALL_PROGRAM settings is now done automatically by
> dpkg-buildpackage. You can remove them from debian/rules
Cool. I removed them. It looks cleaner. :-)
Thanks for all the suggestions and fixes. We might need advice regarding how
to adapt our current release process to something more debian friendly.