Re: RFS: CLAM, C++ library for audio and music
A Dimecres 25 Març 2009 06:09:25, Paul Wise va escriure: On Wed, Mar 25, 2009 at 12:25 AM, David García Garzón dgar...@iua.upf.edu wrote: * The only lintian warning i get is: W: libclam13: package-name-doesnt-match-sonames libclam-audioio13 libclam- core13 libclam-processing13 As suggested by a debian developer and according to libpkg-guide we joined the library as the three libraries are going to change the soname at once on every release (i am also upstream release manager), but in some sponsoring guidelines i read that sponsored packages should be lintian clean including warnings. Should i ignore the warning or should i split the binary packages? It seems silly to have libclam-audioio, libclam-core and libclam-processing when you change the SONAME on all three at the same time. Why not just have libclam? That's a good point. That will silent lintian but we should change all the build system which now is splitted in three. If i can't ignore that warning i would prefer splitting the packages. Splitting the package will be a matter of reverting some changes we did. We splitted the library to provide modurarity and handling the build in three parts to speed up dependency checking and link time. Indeed libclam-processing is still too big for my taste. Another of the goals of the lib split was reducing programs third party dependencies by selecting modules, which would be ideal from a debian point of view if we separate packages, but the reorganization went half the way and current partition still doesn't make that feasible. Most applications will need an 'audioio' method (ladspa, jack, portaudio, portmidi, libsndfile, libmad...) and some 'processing' module and both depend on 'core'. We (upstream hat) plan to do a split them for a next release so that audioio factorizes out dependencies and processing gets into smaller components. Until then it is just a monolithic lib split in three parts. :-( So, by discarding joining the libs, what are remaining the options? splitting packages? ignoring warnings? Changing the SONAME at every release isn't the right thing to do either, it should only be changed when you break the ABI. CLAM has X.Y.Z version schema, and 'guarantees' no ABI change for X.Y. which is coupled to the soname. That said, i have to recognize that last releases have been X.Y.0 so ABI broke. Until now, such changes have not been a big issue since most of the users build their applications from sources and a nice porting guide and scripts were provided for each X.Y release. Your notice of warning at the IRC made me aware that as soon as we get packages depending on clam in debian we should avoid or retain ABI incompatible changes and make more X.Y.Z releases. Thanks, again, for the feedback. David. http://clam-project.org/wiki/Version_Migration_Guide -- 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
On Thu, Mar 26, 2009 at 4:41 AM, David García Garzón dgar...@iua.upf.edu wrote: So, by discarding joining the libs, what are remaining the options? splitting packages? ignoring warnings? Either, I would split them. IIRC the lintian warning may be disabled when the number in the SONAME is the same for all the libraries in the package. Changing the SONAME at every release isn't the right thing to do either, it should only be changed when you break the ABI. CLAM has X.Y.Z version schema, and 'guarantees' no ABI change for X.Y. which is coupled to the soname. Ah, that is quite a good way to do it. PS: you may be interested in joining this team: http://wiki.debian.org/DebianMultimedia -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
A new version of the following source packages is available at: http://clam-project.org/download/linux-debian-sid/svnsnapshots #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 Could someone review and eventually sponsor them? Please, ignore clam-annotator and clam-smstools source packages at that url and consider just the ones in the above list. Specially 'clam' which is the one other three packages depend on. Changes are as follows: * Updated to the latest svn version. * clam-plugins: now includes manpage for the ContinuousExcitationSynthesizer binary, * clam-plugins: the other two binaries are not compiled anymore as they were an old version of the synth (eBowSynthesizer) and a test binary (TestAudioDatabaseReader). * Added myself as Uploader and signed the package Still some issues and doubts someone in the list might help me to solve: * Should I split this RFS thread into several as i did for the ITP bugs? * The only lintian warning i get is: W: libclam13: package-name-doesnt-match-sonames libclam-audioio13 libclam- core13 libclam-processing13 As suggested by a debian developer and according to libpkg-guide we joined the library as the three libraries are going to change the soname at once on every release (i am also upstream release manager), but in some sponsoring guidelines i read that sponsored packages should be lintian clean including warnings. Should i ignore the warning or should i split the binary packages? -- 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
On Wed, Mar 25, 2009 at 12:25 AM, David García Garzón dgar...@iua.upf.edu wrote: * Should I split this RFS thread into several as i did for the ITP bugs? No need to. * The only lintian warning i get is: W: libclam13: package-name-doesnt-match-sonames libclam-audioio13 libclam- core13 libclam-processing13 As suggested by a debian developer and according to libpkg-guide we joined the library as the three libraries are going to change the soname at once on every release (i am also upstream release manager), but in some sponsoring guidelines i read that sponsored packages should be lintian clean including warnings. Should i ignore the warning or should i split the binary packages? It seems silly to have libclam-audioio, libclam-core and libclam-processing when you change the SONAME on all three at the same time. Why not just have libclam? Changing the SONAME at every release isn't the right thing to do either, it should only be changed when you break the ABI. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
On Fri, 6 Mar 2009 19:57:06 +0100 David García Garzón dgar...@iua.upf.edu wrote: David García Garzón dgar...@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 OK. Thanks for the clarification - it's annoying when maintainers try to hurry things along by sounding desperate or as if sponsors and other people on the list are just being too pedantic. A simple language difference is a much simpler explanation. 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. It does sound like more work than it should require. The main problem would appear that you are exporting and tarballing the entire export. Isn't there a way your build can generate the tarball directly? I haven't had time to look at the actual package but things like autotools have calls like 'make dist' which ignore all the generated stuff and just do the right thing. debian/ would only be added to such a tarball if mentioned explicitly in one of the Makefiles so it is trivial to remove such a section. Exporting and tarballing will avoid .svn directories, etc., but (as the debian/ directory shows) will end up including files that really don't deserve to be in the upstream tarball. Most builds generate lots of temporary and other status files which you really don't want in the tarball because they encode data that is entirely specific to the build machine. You either need to be very careful with the equivalent of 'make clean' or sort out upstream to have a way of creating the tarball that only includes the critical files that do not change between builds and are not architecture-dependent or dependent on the configuration of one particular machine. A lot of debian packages spend a lot of time cleaning up after inadequate (or stale) upstream build configurations. 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. If dropped, ensure that the reasons are described in the changelog. So, what to do now? anything else? are the packages ready be uploaded by an sponsor? Not by me. Let me just clarify that too - it's because I don't generally sponsor packages using C++ which in turn is because most of those are KDE apps and I don't use KDE (hate it with a passion). See http://people.debian.org/~codehelp/#lang 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? Right now, I don't have time to review such a large package, especially one using C++. You may or may not be doing anything particularly wrong, it is just that sponsors are volunteers with other priorities and we do what we can but there are quite a lot of packages on mentors that never get a sponsor. Patience is the key - along with a few pings to this list once in a while. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpSimiou6kan.pgp Description: PGP signature
Re: RFS: CLAM, C++ library for audio and music
A Diumenge 08 Març 2009 00:26:49, Neil Williams va escriure: On Fri, 6 Mar 2009 19:57:06 +0100 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. It does sound like more work than it should require. Its an script who does all the steps. http://clam-project.org/clam/CLAM/scripts/doDebianPackages.py Doing what i suggested would be some steps like: svn export http://clam-project.org/clam/CLAM clam-1.4.0 rm -rf clam-1.4.0/debian tar cvfz svn export http://clam-project.org/clam/CLAM/debian clam-1.4.0/debian ... and build the source package Manually could be error prone but it is a script, let it work. The main problem would appear that you are exporting and tarballing the entire export. Isn't there a way your build can generate the tarball directly? I haven't had time to look at the actual package but things like autotools have calls like 'make dist' which ignore all the generated stuff and just do the right thing. debian/ would only be added to such a tarball if mentioned explicitly in one of the Makefiles so it is trivial to remove such a section. For your information we are using scons instead of autotools and make as build system. Exporting and tarballing will avoid .svn directories, etc., but (as the debian/ directory shows) will end up including files that really don't deserve to be in the upstream tarball. Most builds generate lots of temporary and other status files which you really don't want in the tarball because they encode data that is entirely specific to the build machine. You either need to be very careful with the equivalent of 'make clean' or sort out upstream to have a way of creating the tarball that only includes the critical files that do not change between builds and are not architecture-dependent or dependent on the configuration of one particular machine. A lot of debian packages spend a lot of time cleaning up after inadequate (or stale) upstream build configurations. Such files are not included in the svn. CLAM is automatically built on commit under several flavors of debian, ubuntu, fedora, macosx and windows, so, for example, if we wrongly commit some platform dependant file we soon detect it as svn conflicts. For us is safer to do an export. 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. If dropped, ensure that the reasons are described in the changelog. Ok. I hope i can get the programs descriptions shortly anyway. So, what to do now? anything else? are the packages ready be uploaded by an sponsor? Not by me. Let me just clarify that too - it's because I don't generally sponsor packages using C++ which in turn is because most of those are KDE apps and I don't use KDE (hate it with a passion). See http://people.debian.org/~codehelp/#lang Well, in fact CLAM is just Qt not KDE but i guess the same applies. Your choice. 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? Right now, I don't have time to review such a large package, especially one using C++. You may or may not be doing anything particularly wrong, it is just that sponsors are volunteers with other priorities and we do what we can but there are quite a lot of packages on mentors that never get a sponsor. Patience is the key - along with a few pings to this list once in a while. Well, no problem. We are also volunteers so i understand. I hope we can find an sponsor soon or someone that could take it a closer look to find more issues. If we waited for five years since the first debianization, i guess we can wait for some more time... a couple of hours? ;-) Thanks a lot for your hints. They have been very helpfull. Regards. David. -- 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
On Sunday 08 March 2009 03:43:00 David García Garzón wrote: --cut-- Hi, Well, no problem. We are also volunteers so i understand. I hope we can find an sponsor soon or someone that could take it a closer look to find more issues. You may also want to check your sourses with cppcheck as found in sid. Surely there might be false positives [1], but there are also very nice catches you might want to consider. This of course doesn't mean that the package is buggy, it just helps avoiding situations like fighting bugs in the last minute before release in a relatively large and complicated package. [1] especially for the libraries providing functions which dynamically allocated memory is meant to be released in the application code, which is of course missing when you only check the library code. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
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. * 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 sponsor? 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 dgar...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
On Fri, 6 Mar 2009 14:30:11 +0100 David García Garzón dgar...@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 dgar...@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
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 dgar...@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
Re: RFS: CLAM, C++ library for audio and music
The ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493282 Packages: http://clam.iua.upf.edu/download/linux-debian-sid/svnsnapshots I did some fixes on the packages following your advices and lintian's. I will do some extra effort on christmas holidays to wrap it up so i will be glad if you can do another review on the current status of the packages so you can find more problems i could fix. My todo list looks like this (+done -todo): + Not a native package anymore (adding a diff to upstream) + examples should be packaged with dh_examples. + debian/changelog has an incorrect distribution + Not tarballing the doxygen documentation + Remove CFLAGS and INSTALL_PROGRAM from debian/rules + Remove alternative dependency on old libxerces28-dev - Fill independent RFP's for applications and plugins. - Vcs-* fields is for Debian packaging, not upstream VCS repository - Include non GPLv2-or-later licenses in debian/copyright - Add man pages to the extra binaries (needed?) - Sign DSC files. Some questions: - Should i remove the Vcs fields while there is no public svn of the diff? - Could you point me to an example of debian packaging repository? Just to know how that should be organized. - Are the man pages for the extra binaries needed at all to be in the package? Those files are not meant to be launched by user but by the core programs. David. On Divendres 05 Setembre 2008 22:22:29 Vincent Bernat wrote: OoO La nuit ayant déjà recouvert d'encre ce jour du jeudi 04 septembre 2008, vers 23:26, David García Garzón dgar...@iua.upf.edu disait : 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 OK. Moreover, the .dsc file is not signed. Must the key be validated by any debian maintainer at all? This would be better but this is not mandatory. However, this should be your key. 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. It would be better. For example, clam could be uploaded soon while clam-XXX could have a lot of problems and its upload would be delayed for several months. This would be better to have its own ITP. 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. Or you can just edit by hand. ;-) 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. Everybody is free to generate packages as they want to. However, keep in mind that you need to write sensible changelog (the script will have some difficulties). As long as the script gives good results, this is fine to use it. - 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? Both questions are related. Even if now, upstream and Debian packager are closely related, this may not be the case in the future. Debian packaging should only be targeted to go into Debian, not to be downloaded from the website, not to be included into Ubuntu (even if it will eventually migrate to Ubuntu when present in Debian). For example, in the packages that you propose to download from the website, you could widen the dependencies by depending on software not available any more or by suggesting softwares not available into Debian. Therefore, you need a dedicated branch or repository. - 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? You just have to mention the files licensed under different licenses in debian/copyright. As long as the licenses are compatible, there is no problem. - examples should be packaged with dh_examples Do you mean dh_installexamples? Yes. Well
Re: RFS: CLAM, C++ library for audio and music
On Wed, 24 Dec 2008 12:12:56 +0100 David García Garzón dgar...@iua.upf.edu wrote: - Include non GPLv2-or-later licenses in debian/copyright - Add man pages to the extra binaries (needed?) Anything in /usr/bin, /usr/sbin, /bin/, /sbin/ or /usr/games needs a man page. Anything in /usr/share/ can do without but if there is any chance of a user needing to run something from /usr/share/ then a manpage is advisable. - Could you point me to an example of debian packaging repository? Just to know how that should be organized. $ sudo apt-get install reprepro $ man reprepro $ mkdir conf/ $ vi ./conf/distributions ... $ reprepro export $ reprepro include unstable $changesfile Simple. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpMUC4j0OzD1.pgp Description: PGP signature
Re: RFS: CLAM, C++ library for audio and music
On Wed, 24 Dec 2008 15:16:15 +0100 David García Garzón dgar...@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.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpwe0jw28Q3t.pgp Description: PGP signature
Re: RFS: CLAM, C++ library for audio and music
On Wednesday 24 December 2008 14:29:47 Neil Williams wrote: On Wed, 24 Dec 2008 12:12:56 +0100 David García Garzón dgar...@iua.upf.edu wrote: - Include non GPLv2-or-later licenses in debian/copyright - Add man pages to the extra binaries (needed?) Anything in /usr/bin, /usr/sbin, /bin/, /sbin/ or /usr/games needs a man page. Anything in /usr/share/ can do without but if there is any chance of a user needing to run something from /usr/share/ then a manpage is advisable. That's my point. Most of the bins without manpage are binaries that are not intended to be run by the user but are launched by the main application. Anyway I just discovered help2man that will help me a lot to fullfil the requirement without loosing many time. - Could you point me to an example of debian packaging repository? Just to know how that should be organized. $ sudo apt-get install reprepro $ man reprepro $ mkdir conf/ $ vi ./conf/distributions ... $ reprepro export $ reprepro include unstable $changesfile Simple. 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. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
OoO La nuit ayant déjà recouvert d'encre ce jour du jeudi 04 septembre 2008, vers 23:26, David García Garzón [EMAIL PROTECTED] disait : 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 OK. Moreover, the .dsc file is not signed. Must the key be validated by any debian maintainer at all? This would be better but this is not mandatory. However, this should be your key. 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. It would be better. For example, clam could be uploaded soon while clam-XXX could have a lot of problems and its upload would be delayed for several months. This would be better to have its own ITP. 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. Or you can just edit by hand. ;-) 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. Everybody is free to generate packages as they want to. However, keep in mind that you need to write sensible changelog (the script will have some difficulties). As long as the script gives good results, this is fine to use it. - 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? Both questions are related. Even if now, upstream and Debian packager are closely related, this may not be the case in the future. Debian packaging should only be targeted to go into Debian, not to be downloaded from the website, not to be included into Ubuntu (even if it will eventually migrate to Ubuntu when present in Debian). For example, in the packages that you propose to download from the website, you could widen the dependencies by depending on software not available any more or by suggesting softwares not available into Debian. Therefore, you need a dedicated branch or repository. - 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? You just have to mention the files licensed under different licenses in debian/copyright. As long as the licenses are compatible, there is no problem. - examples should be packaged with dh_examples Do you mean dh_installexamples? Yes. 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. Dunno. I think this is a bad idea to install examples as tar.gz. The user need to unpack them somewhere while he has explicitely asked for their installation. Thanks for all the suggestions and fixes. We might need advice regarding how to adapt our current release process to something more debian friendly. Start with a fresh changelog, just for Debian. Try to apply the above suggestions and we will review the packages again. -- I NO LONGER WANT MY MTV I NO LONGER WANT MY MTV I NO LONGER WANT MY MTV -+- Bart Simpson on chalkboard in episode 3G02 pgpl5eF4WdfjP.pgp Description: PGP signature
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 PROTECTED] 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: CLAM, C++ library for audio and music
Related bug #493282. Any other information missing? On Dimarts 05 Agost 2008, David García Garzón wrote: (I am sorry, my previous mail to the list fled from my computer without my consent ;-) Here is the full one.) Package: clam Description: CLAM, C++ library for audio and music License: GPL v2 or higher CLAM, C++ library for audio and music is a development framework for audio and music applications. It provides lot of high level algorithms to analyze and manipulate audio. They can be combined in a graphical way using the NetworkEditor application or by C++ programming. It integrates backends to Ladspa, Jack, PortAudio, OSC, libsndfile, libmad, libogg... so that those libraries and technologies can be seen in a common interface. Some algorithms included in the libraries are: Tonal (chord) analysis, Sinusoidals + residual analysis and transformations, spectral analysis and transformations, realtime spatialization algorithms (ambisonics, hrtfs...), guitar effects, rhythm analysis... Web page: http://clam.iua.upf.edu/ Screenshots: http://clam.iua.upf.edu/wikis/clam/index.php/Development_screenshots A tour on the graphical tool usage: http://iua-share.upf.edu/wikis/clam/index.php/Network_Editor_tutorial Upstream team has been packaging them for a long time and we would like to get them into debian repositories, so we are requesting for an sponsor. Last versions of the debian packages can be found there: http://clam.iua.upf.edu/download/linux-debian-sid/svnsnapshots/ David Garcia Garzon -- David García Garzón (Work) dgarcia at iua dot upf anotherdot es http://www.iua.upf.edu/~dgarcia signature.asc Description: This is a digitally signed message part.
RFS: CLAM, C++ library for audio and music
CLAM, C++ library for audio and music is a development framework for audio and music applications. It provides lot of high level algorithms to analyze and manipulate audio. They can be combined -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: CLAM, C++ library for audio and music
(I am sorry, my previous mail to the list fled from my computer without my consent ;-) Here is the full one.) Package: clam Description: CLAM, C++ library for audio and music License: GPL v2 or higher CLAM, C++ library for audio and music is a development framework for audio and music applications. It provides lot of high level algorithms to analyze and manipulate audio. They can be combined in a graphical way using the NetworkEditor application or by C++ programming. It integrates backends to Ladspa, Jack, PortAudio, OSC, libsndfile, libmad, libogg... so that those libraries and technologies can be seen in a common interface. Some algorithms included in the libraries are: Tonal (chord) analysis, Sinusoidals + residual analysis and transformations, spectral analysis and transformations, realtime spatialization algorithms (ambisonics, hrtfs...), guitar effects, rhythm analysis... Web page: http://clam.iua.upf.edu/ Screenshots: http://clam.iua.upf.edu/wikis/clam/index.php/Development_screenshots A tour on the graphical tool usage: http://iua-share.upf.edu/wikis/clam/index.php/Network_Editor_tutorial Upstream team has been packaging them for a long time and we would like to get them into debian repositories, so we are requesting for an sponsor. Last versions of the debian packages can be found there: http://clam.iua.upf.edu/download/linux-debian-sid/svnsnapshots/ David Garcia Garzon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
