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): > 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". > * 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. > * 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. > * 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. > > 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@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 > http://www.iua.upf.edu/~dgarcia > > > -- > To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpdUtYdmQSv4.pgp
Description: PGP signature