[Clam-devel] Re: Fwd: Re: RFS: CLAM, C++ library for audio and music
David García Garzón
dgarcia at iua.upf.edu
Fri Mar 6 07:53:09 PST 2009
Uau, debian maintainers have complained very angrily about asking for
uploading binaries without man pages or even proposing to cut down those
binaries (i thought that being upstream authors we were in our right but :-P).
Could any one make those man pages, please, i don't even know what those
binaries do. Just make the binary respond to --help and --version and i will
do the manpages and installation.
A Divendres 06 Març 2009 14:39:21, David García Garzón va escriure:
> ---------- Missatge reenviat ----------
> Assumpte: Re: RFS: CLAM, C++ library for audio and music
> Data: Divendres 06 Març 2009
> De: David García Garzón <dgarcia at iua.upf.edu>
> A: debian-mentors at lists.debian.org, Vincent Bernat <bernat at debian.org>
> That's our last try to make those packages ready to get into Debian
> * 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.
> * 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.
> * 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.
> * 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
> David Garcia Garzon
> CLAM Team.
> A Dimecres 24 Desembre 2008 16:02:42, Neil Williams va escriure:
> > On Wed, 24 Dec 2008 15:16:15 +0100
> > David García Garzón <dgarcia at iua.upf.edu> wrote:
> > > > > - Could you point me to an example of debian packaging
> > > > > repository? Just to know how that should be organized.
> > >
> > > Ups, sorry, not that one. I guess that what you sent maintains a
> > > debian package repository, I was talking about svn-repository not
> > > package repository. We are maintaining the debian/ files within
> > > upstream svn (svn-repository), and i was suggested to maintain it in
> > > a separate svn. I was wondering on how to deal with that, whether to
> > > store the diff files or the full debian dir, how to apply and update
> > > it easily and so on.
> > >
> > > I guess that it has something to do with svn-buildpackage, but
> > > individual man pages don't give me the whole picture.
> > Take a look at the SVN layout for packages like QOF:
> > http://svn.debian.org/viewsvn/qof/trunk/
> > Unfortunately, viewsvn doesn't show the properties that allow
> > MergeWithUpstream but if you check out the SVN and look at in something
> > like svn-workbench, you can inspect the properties easily (or svn info
> > will do the same). The debian directory as mergeWithUpstream set to 1
> > in the svn properties. Then I copy the relevant tarball from qof/ to
> > debian/tarballs:
> > $ cp qof/qof-0.8.0.tar.gz ../debian/tarballs/qof_0.8.0.orig.tar.gz
> > $ svn-buildpackage
> > IIRC symlinks don't work, can't remember why.
> > (0.8.0 is the unreleased version, 0.7.5 was hosted at SF instead of
> > Alioth so 'debcheckout' doesn't get you the right version, yet.)
> David García Garzón
> (Work) dgarcia at iua dot upf anotherdot es
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
More information about the clam-devel