RFS: plait - command line jukebox (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.6.2-1 of my package plait. It builds these binary packages: plait - command-line jukebox The package appears to be lintian clean. The upload would fix these bugs: 498651 as well as bringing the package up to date with upstream. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/plait - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/plait/plait_1.6.2-1.dsc I recommend plait -s goonshow as test case. :-) I would be most appreciative if someone uploaded this package for me. Kind regards, Dave. -- David Symons Armidale NSW Australia http://www.liberatedcomputing.net signature.asc Description: This is a digitally signed message part
Re: RFS: dtmfdial (updated package)
On Fri, Mar 06, 2009 at 10:31:47PM -0500, Barry deFreese wrote: Denis Briand wrote: Dear mentors, I am looking for a sponsor for the new version 0.2-5 of my package dtmfdial. It builds these binary packages: dtmfdial - DTMF Tone Dialer The package appears to be lintian clean. The upload would fix these bugs: 490041 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dtmfdial - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dtmfdial/dtmfdial_0.2-5.dsc I would be glad if someone uploaded this package for me. Kind regards Denis Briand I'm not sure this is a big deal but probably should be fixed: W: dtmfdial: copyright-refers-to-versionless-license-file usr/share/common-licenses/GPL Also, any particular reason you didn't bump the debhelper build-dep version and compat to at least 5? Thanks! Barry deFreese It was because I builded the package with lenny and lintian didn't see anything. I build it now with sid and I changed the GPL to GPL-2 (dtmfdial upstream version since 1998) to have a GPL version license in debian/copyright that's all right for lintian. But, I have one question : how can I upload that new package? -upgrade to 0.2-6 ? and $ dput mentors dtmfdial_0.2-6_i386.changes ? or -I send to you my 0.2-5 fixed package ? or -I send my 0.2-5 fixed package with dput after to removed .upload file ? Best regards Thank you Denis Briand signature.asc Description: Digital signature
Re: RFS: dtmfdial (updated package)
Denis Briand de...@narcan.fr writes: It was because I builded the package with lenny and lintian didn't see anything. You should only ever upload packages that you have used ‘sid’ to successfully build and lintian check. For one way to do that without necessarily running ‘sid’ as your operating system, investigate the ‘pbuilder’ package. But, I have one question : how can I upload that new package? -upgrade to 0.2-6 ? This is my chosen option and that of several others here; it makes a clear distinction when talking about each upload that you made. But be aware that there is disagreement on this point. and $ dput mentors dtmfdial_0.2-6_i386.changes ? You should only upload source packages for sponsorship; your sponsor needs to re-build the package from source anyway. -- \ “When cryptography is outlawed, bayl bhgynjf jvyy unir | `\ cevinpl.” —Anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: reiserfsprogs
Paul Wise wrote: On Fri, Mar 6, 2009 at 8:07 PM, Felix Zielcke fziel...@z-51.de wrote: I am looking for a sponsor for my package reiserfsprogs. I'm now a DM so only a one time upload is needed. You shouldn't add DM-Upload-Allowed to your packages, that is for sponsors to do when they are comfortable with your packaging. A one-time sponsor generally wouldn't be familiar with your work and so they shouldn't upload your package with DM-Upload-Allowed. I see Barry deFreese already uploaded it though. Well I have worked with him on reiser4progs previously but to be honest I missed the DM-Upload-Allowed Sorry, Barry -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: blueman
On Friday 06 March 2009 17:15:57 Christopher Schramm wrote: Jelle de Jong wrote: I agree this package is welcome in debian, somebody fancy to sponser? Since nobody was yet: Is there any problem with sponsoring the package? Hi, It is not necessary for the package to have any technical or legal problems in order to receive a sponsorship feedback, it generally means that it is quite likely that nobody has found the time or sufficient interest to have a look at it. As usual, a decent presentation of the package (especially its advantages over already existing packages if any) may help a lot to find a sponsor, and of course a purely deceptive or poor advertisement may even work in the opposite direction ;-) -- 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
RFS: osgppu
Dear mentors, I am looking for a sponsor for my package osgppu. * Package name: osgppu Version : 0.4.0-1 Upstream Author : Art Tevs t...@mpi-inf.mpg.de * URL : http://projects.tevs.eu/osgppu * License : LGPL Section : libs It builds these binary packages: libosgppu-dev - offscreen renderer using GLSL shaders for computations [devel] libosgppu-doc - offscreen renderer using GLSL shaders for computations [doc] libosgppu4 - offscreen renderer using GLSL shaders for computations [runtime] libosgppu4-dbg - offscreen renderer using GLSL shaders for computations [debug] The package appears to be lintian clean. The upload would fix these bugs: 518580 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/o/osgppu - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/osgppu/osgppu_0.4.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dtmfdial (updated package)
On Sat, Mar 07, 2009 at 11:38:37PM +1100, Ben Finney wrote: Denis Briand de...@narcan.fr writes: It was because I builded the package with lenny and lintian didn't see anything. You should only ever upload packages that you have used ‘sid’ to successfully build and lintian check. For one way to do that without necessarily running ‘sid’ as your operating system, investigate the ‘pbuilder’ package. But, I have one question : how can I upload that new package? -upgrade to 0.2-6 ? This is my chosen option and that of several others here; it makes a clear distinction when talking about each upload that you made. But be aware that there is disagreement on this point. and $ dput mentors dtmfdial_0.2-6_i386.changes ? You should only upload source packages for sponsorship; your sponsor needs to re-build the package from source anyway. It's ok, upgraded to 0.2-6 Thanks Denis Briand signature.asc Description: Digital signature
Re: RFS: dtmfdial (updated package)
A few additions to this. Ben Finney ben+deb...@benfinney.id.au writes: You should only ever upload packages that you have used ‘sid’ to successfully build and lintian check. For one way to do that without necessarily running ‘sid’ as your operating system, investigate the ‘pbuilder’ package. In fact, even if you run ‘sid’ as your operating system, it's recommended to build your packages in a ‘pbuilder’ environment to discover issues with build-time dependencies. [incrementing the Debian release number each time you make a new release] is my chosen option and that of several others here; it makes a clear distinction when talking about each upload that you made. But be aware that there is disagreement on this point. Neil Williams has a good explanation of why this is a good idea URL:http://people.debian.org/~codehelp/#reasons. -- \ “My interest is in the future, as I am going to spend the rest | `\ of my life there.” —Charles F. Kettering | _o__) | Ben Finney -- 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
scons /rules
Hi, I want to build my first package. I have to edit the rules file, but how? What are in general the things you have to do when building a scons package? And there is also not an makefile, but an SConstruct file, right? \r #!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make. # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 configure: configure-stamp configure-stamp: dh_testdir # Add here commands to configure the package. touch configure-stamp build: build-stamp build-stamp: configure-stampdh_testdir # Add here commands to compile the package. $(MAKE) #docbook-to-man debian/klick.sgml klick.1 touch $@ clean: dh_testdir dh_testroot rm -f build-stamp configure-stamp # Add here commands to clean up after the build process. $(MAKE) clean dh_clean install: build dh_testdir dh_testroot dh_prepdh_installdirs # Add here commands to install the package into debian/klick. $(MAKE) DESTDIR=$(CURDIR)/debian/klick install # Build architecture-independent files here. binary-indep: install # We have nothing to do by default. # Build architecture-dependent files here. binary-arch: install dh_testdir dh_testroot dh_installchangelogs dh_installdocs dh_installexamples #dh_install #dh_installmenu #dh_installdebconf #dh_installlogrotate #dh_installemacsen #dh_installpam #dh_installmime #dh_python #dh_installinit #dh_installcron #dh_installinfo dh_installman dh_link dh_strip dh_compress dh_fixperms #dh_perl #dh_makeshlibs dh_installdeb dh_shlibdeps dh_gencontrol dh_md5sums dh_builddeb binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install configure -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: scons /rules
On Sat, Mar 7, 2009 at 3:25 PM, Grammostola Rosea rosea.grammost...@gmail.com wrote: Hi, I want to build my first package. I have to edit the rules file, but how? What are in general the things you have to do when building a scons package? And there is also not an makefile, but an SConstruct file, right? In general, it's pretty similar to a normal make setup. Instead of calling $(MAKE), just define SCONS (e.g., SCONS = scons, at the top of the file) and then call $(SCONS). The upstream SConstruct file should support DESTDIR setting when you call $(SCONS) install. You may also need to remove .sconsign.dblite config.log .sconf_temp manually in debian/clean. Be aware that due to the way scons works, scons -c will not work if the SConstruct file cannot initialize itself. That is to say, if scons does not work without patching the makefile, then to allow the package to build properly, you will either have to (a) manually replicate the purpose of scons clean in the clean: target of debian/rules, or (b) force the clean target to depend on the patch target, e.g.: clean: patch clean-patched unpatch clean-patched: $(SCONS) -c etc... This only applies in a few cases though, and getting upstream to fix this is far better than implementing this kind of clean target. Just use man to discover the differences between the dh_* commands, and be sure to remove any that you don't need (don't just comment them out). Regards, Daniel -- Daniel Moerner dmoer...@gmail.com -- 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 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: scons /rules
On Sun, Mar 8, 2009 at 9:36 AM, Daniel Moerner dmoer...@gmail.com wrote: In general, it's pretty similar to a normal make setup. Instead of calling $(MAKE), just define SCONS (e.g., SCONS = scons, at the top of the file) and then call $(SCONS). The upstream SConstruct file should support DESTDIR setting when you call $(SCONS) install. Most of the time you'll have to implement DESTDIR support yourself (or convince upstream to switch to autotools or something that does DESTDIR out of the box). Check the packages in the scons reverse build-deps for examples: sudo apt-get install devscripts ; build-rdeps scons Be aware that due to the way scons works, scons -c will not work if the SConstruct file cannot initialize itself. That is to say, if scons does not work without patching the makefile, then to allow the package to build properly, you will either have to (a) manually replicate the purpose of scons clean in the clean: target of debian/rules, or (b) force the clean target to depend on the patch target, e.g.: This won't be needed when dpkg-source v3 (quilt) packages are accepted by the Debian archive (hopefully soon). -- 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 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
