[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <dgarcia@iua.upf.edu> 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:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493282

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

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

>  - 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 
that?

>  - 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 
at:
http://clam.iua.upf.edu/download/linux-debian-sid/

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.

David.



Reply to: