Re: RFS: CLAM, C++ library for audio and music
A Divendres 06 Març 2009 16:06:31, Neil Williams va escriure:
> On Fri, 6 Mar 2009 14:30:11 +0100
>
> David García Garzón <dgarcia@iua.upf.edu> wrote:
> > That's our last try to make those packages ready to get into Debian
> > (~svn12799):
Ups, maybe a Catalan false friend here. I just realized it could have been
understood as 'i am not trying anymore' instead of 'that's the newer one'.
It was 'the newer one' ;-) Not that desperate yet
> > http://clam-project.org/download/linux-debian-sid/svnsnapshots/
> >
> > * Separate ITP bugs have been filled for the different related source
> > packages so that they can be closed independently:
> > #493282 ITP: clam -- CLAM, C++ Library for Audio and Music
> > #517910 ITP: clam-chordata -- CLAM Chordata, chord detection tool
> > #518353 ITP: clam-plugins -- Extension plugins for the CLAM audio
> > framework #517882 ITP: clam-networkeditor -- CLAM Network Editor,
> > prototyping tool for CLAM
> > Other related source packages such as clam-voice2midi, clam-annotator and
> > clam-smstools are not as prioritary, so i will go for those 4 by now.
> > Corrections to clam-smstools and clam-annotator are also wellcome but
> > that should not stop the others.
> >
> > * Updated all the urls to point to the new domain http://clam-project.org
> >
> > * Debian packaging has been separated to a different subversion tree and
> > not included anymore in source packages so the diff now contains the full
> > debian packaging. I feel this is very inconvenient for upstream
> > maintenance but after several tries i prefer first to conform debian and
> > later to find a better method.
>
> The debian/ packaging can be in upstream RCS just not in the tarball(s)
> released by upstream. If the upstream build process cannot cope with
> ignoring certain directories, it may be a good idea to fix to solve
> the "inconvenience".
If such simple solution is allowed, i will do that in release scripts. Now we
export, tarball, export debian inside, and build source package. We should
then, export, delete debian, tarball, reexport debian and build source
package. Not that hard.
But i guess, and correct me if I am wrong, that on the debian side, the result
is the same, and it is just an inconvenience for us when wearing the upstream
developers hat. So, by keeping debian folder out of the tarball, i will focus
on any other problem that is a show-stopper.
> > * Man pages have been generated for most of the binaries. There are still
> > some missing in clam-plugins, but if this is a problem for the upload i'd
> > prefer removing them until we have some manpages from the authors as they
> > are not the central part of the package.
>
> All required manpages need to exist - I would not sponsor the package in
> this state.
> Why the rush? If the package doesn't have all manpages, wait until all
> the manpages are available. Uploading a new version with lots of new
> packages is only going to mean more time waiting for the package to
> clear the NEW queue. It's quite likely that two periods in NEW will be
> appreciably longer than the period to wait for manpages and a single
> passage through NEW.
>
> Uploading a package with certain components deliberately crippled but
> still included in the source could lead to a rejection from ftp-master
> as merely missing manpages is not a particularly good reason to drop
> entire sections of functionality. Manpages are not difficult to
> prepare, I don't see why you cannot write them yourself using the
> source code as a guide.
I understand, I will try to wait for the manpage. I would rather prefer the
original author express himself in his own words than trying to go from the
low level to the high level on source. It is not just about C++ code but about
some signal processing, musical concepts, and program conception i am not
familiar with. Meanwhile I will prepare all the infrastructure to build and
install the manpage so that when he responds all just will flow.
Anyway, as the upstream release manager I was serious when I said that this
piece of software can be dropped from this binary release. The plugin that
comes with those helper binaries was an experimental GSoC project that i just
enabled on the last package revision but it was disabled until then, just like
other experimental ones also included in source but not compiled.
Also, this concrete issue just affects to clam-plugins source package, and
should not stop clam, clam-chordata and clam-networkeditor from getting in.
That's why Vincent Bernat requested me to split them in several ITP, wasn't
it?
> > * Signed packages using a colective key for 'CLAM Team'. I think this is
> > more convenient in order to enable other CLAM developers to upload the
> > packages. If a personal key is required, warn me and i will change it.
>
> No. Multiple keys and multiple uploaders each with their own key. A
> collected secret key or shared secret key is unacceptable in Debian,
> it's only reasonable to expect the same on mentors IMHO.
>
> Take a look at any of the team-maintained packages in Debian for
> examples of how to set Maintainer: and Uploaders: as appropriate.
Ok. That seems a very reasonable policy. I thought that during the sponsoring
period the 'uploader' was the sponsor. So if now I understood that well, and
correct me again if I am wrong, i should keep 'CLAM Team' as maintainer,
declare myself as 'Uploader:' in debian/control and signing with my own key.
So I will do that. Thanks.
> > * Licenses not being GLPv2 or later acknoledged at debian/copyright
> >
> > * Several fixes (some plugins were not generated at all)
> >
> > I would prefer not to clear the changelog, but, again, if this is
> > required i would clear it giving kudos to other people involved in the
> > packaging along those years of 'unofficiality' (Miguel Ramirez, Paul
> > Brossier, Pau Arumí, Hernan Hordiales, Gunter Geiger...).
> >
> > So, what to do now? anything else? are the packages ready be uploaded by
> > an sponsor?
>
> Not by me.
Ok, but I would like to receive more feedback about any other issues in the
current revision of those packages. If those you say are the only problems i
will be pretty happy, I could build valid debian packages in short. But taking
a look back i guess there could be more issues. ;-) What else are we doing
wrong?
--
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia
Reply to: