RFS: daemonlogger
Dear mentors, I am looking for a sponsor for my package daemonlogger. * Package name: daemonlogger Version : 0.91-1 Upstream Author : Martin Roesch [EMAIL PROTECTED] * URL : http://www.snort.org/users/roesch/Site/Daemonlogger.html * License : GPL Section : net It builds these binary packages: daemonlogger - simple network packet logger and soft tap daemon The package appears to be lintian clean. The upload would fix these bugs: 439008 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/daemonlogger - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/daemonlogger/daemonlogger_0.91-1.dsc I would be glad if someone uploaded this package for me. Kind regards Chris Taylor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: fontypython
Dear mentors, I am looking for a sponsor for my package fontypython. Package is already in Debian. * Package name: fontypython Version : 0.2.0-3 Upstream Author : Donn.C.Ingle [EMAIL PROTECTED] * URL : https://savannah.nongnu.org/projects/fontypython * License : GPL Section : utils It builds these binary packages: fontypython - A GUI tool to manage ttf fonts The package appears to be lintian/pbuilder clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fontypython - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/fontypython/fontypython_0.2.0-3.dsc I would be glad if someone uploaded this package for me. -- Cheers, --- Kartik Mistry || GPG: 0xD1028C8D || IRC: kart_ kartikmistry.org/blog || kartikm.wordpress.com -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: tagtool
Dear mentors, I am looking for a sponsor for my package tagtool. * Package name: tagtool Version : 0.12.3-3 Upstream Author : Pedro Lopes [EMAIL PROTECTED] * URL : http://pwp.netcabo.pt/paol/tagtool/ * License : GPL Section : sound It builds these binary packages: tagtool- Tool to tag and rename MP3 and Ogg Vorbis files The package appears to be lintian/pbuilder clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tagtool - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tagtool/tagtool_0.12.3-3.dsc I would be glad if someone uploaded this package for me. -- Cheers, --- Kartik Mistry || GPG: 0xD1028C8D || IRC: kart_ kartikmistry.org/blog || kartikm.wordpress.com -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: gtkdiskfree
Dear mentors, I am looking for a sponsor for the new version 1.9.3-8 of my package gtkdiskfree. It builds these binary packages: gtkdiskfree - A Gnome program to show free/used space on filesystems The package appears to be lintian/pbuilder clean. The upload would fix these bugs: #383679 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gtkdiskfree - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gtkdiskfree/gtkdiskfree_1.9.3-8.dsc I would be glad if someone uploaded this package for me. -- Cheers, --- Kartik Mistry || GPG: 0xD1028C8D || IRC: kart_ kartikmistry.org/blog || kartikm.wordpress.com -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
signing packages from a different machine
Hi I have access to two machines - say machine A, machine B. On machine A when I build a package, I can automatically sign the package as needed. However now I am sitting at a friends machine (machine B) and built a package using pdebuild. But I am not sure how to sign this package. The errors from pdebuild are pbuilder-time-stamp: 1187760442 signfile /home/raju/pbuilder/result/texmacs_1.0.6.10-2.dsc Kamaraju Kusumanchi [EMAIL PROTECTED] gpg: skipped Kamaraju Kusumanchi [EMAIL PROTECTED]: secret key not available gpg: [stdin]: clearsign failed: secret key not available debsign: gpg error occurred! Aborting What should I do? Should I copy the secret key from machine A to machine B? or should I copy the .dsc, .changes files from machine B to machine A and sign there? I looked in maint-guide, developers-reference, debian-reference but could not find any suggestions there. thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: signing packages from a different machine
Hi, On Wed Aug 22, 2007 at 10:46:38 -0400, Kamaraju S Kusumanchi wrote: Hi I have access to two machines - say machine A, machine B. On machine A when I build a package, I can automatically sign the package as needed. However now I am sitting at a friends machine (machine B) and built a package using pdebuild. But I am not sure how to sign this package. The errors from pdebuild are pbuilder-time-stamp: 1187760442 signfile /home/raju/pbuilder/result/texmacs_1.0.6.10-2.dsc Kamaraju Kusumanchi [EMAIL PROTECTED] gpg: skipped Kamaraju Kusumanchi [EMAIL PROTECTED]: secret key not available gpg: [stdin]: clearsign failed: secret key not available debsign: gpg error occurred! Aborting What should I do? Should I copy the secret key from machine A to machine B? or should I copy the .dsc, .changes files from machine B to machine A and sign there? I looked in maint-guide, developers-reference, debian-reference but could not find any suggestions there. debsign -kyourKeyId [EMAIL PROTECTED]:/path/to/changes/file.changes -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: signing packages from a different machine
2007/8/22, Kamaraju S Kusumanchi [EMAIL PROTECTED]: Hi I have access to two machines - say machine A, machine B. On machine A when I build a package, I can automatically sign the package as needed. However now I am sitting at a friends machine (machine B) and built a package using pdebuild. But I am not sure how to sign this package. The errors from pdebuild are pbuilder-time-stamp: 1187760442 signfile /home/raju/pbuilder/result/texmacs_1.0.6.10-2.dsc Kamaraju Kusumanchi [EMAIL PROTECTED] gpg: skipped Kamaraju Kusumanchi [EMAIL PROTECTED]: secret key not available gpg: [stdin]: clearsign failed: secret key not available debsign: gpg error occurred! Aborting What should I do? Should I copy the secret key from machine A to machine B? or should I copy the .dsc, .changes files from machine B to machine A and sign there? I looked in maint-guide, developers-reference, debian-reference but could not find any suggestions there. I would recommend you not to copy your secret key to your friend's machine. A secret key is something to keep safe and secret. It would be much better to move the files to your machine and sign the packages there, or to carry your secret keys in a USB device, possibly encrypted just in case you lose it, and just using it in machines you can trust. Miry
Re: signing packages from a different machine
On Wed, 22 Aug 2007 10:46:38 -0400 Kamaraju S Kusumanchi [EMAIL PROTECTED] wrote: Hi I have access to two machines - say machine A, machine B. On machine A when I build a package, I can automatically sign the package as needed. However now I am sitting at a friends machine (machine B) and built a package using pdebuild. But I am not sure how to sign this package. If you do not have sole access to root on that machine, it's best not to have your secret key on it so it's best not to sign. Use the '-uc' '-us' switches or put the data into .pbuilderrc AUTO_DEBSIGN=no You don't have to sign every build you do on every machine - you only need to sign the one build that is going to be uploaded. As none of your sponsors are even remotely interested in the architecture-dependent binaries and only really care about the .dsc, .orig.tar.gz and (if not native) the .diff.gz, there is no need to worry about signing builds on different architectures. It's good to do but it isn't relevant to sponsoring, normally. What should I do? Should I copy the secret key from machine A to machine B? Not if that machine is not secure. or should I copy the .dsc, .changes files from machine B to machine A and sign there? I looked in maint-guide, developers-reference, debian-reference but could not find any suggestions there. apt-get install devscripts man debrsign -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp7xfkGD2Nkl.pgp Description: PGP signature
dh_install and python version
Hi, I have packaged a python program. The packaging is fairly simple : 1) python setup.py build 2) python setup.py install --root $(CURDIR)/debian/tmp\ --install-lib usr/lib/python$* 3) dh_install splits the package. This works (I use python-central). Source code details may be seen online[1]. However, I'm not quite sure about this --install-lib usr/lib/python$* because : - it's nowhere to be seen in example packages - I must harcode usr/lib/python2.4/... in debian/package.install files, this means that my package will FTBS when python2.5 becomes the default. Shipping private modules clears the problem out (using --install-lib usr/share/sourcepackagename and moving the private extension using dh_install), but I see only advantages in shipping public modules for the default python version. My next idea is to preprocess new debian/package.install.in files into package.install files to match the python version. Is that not too hacky? Thanks in advance for advices, inputs or even clues, Alex [1] http://mroy31.dyndns.org/~roy/projects/deejayd/browser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: signing packages from a different machine
Neil Williams wrote: You don't have to sign every build you do on every machine - you only need to sign the one build that is going to be uploaded. As none of your sponsors are even remotely interested in the architecture-dependent binaries and only really care about the .dsc, .orig.tar.gz and (if not native) the .diff.gz, there is no need to worry about signing builds on different architectures. It's good to do but it isn't relevant to sponsoring, normally. I want to upload the packages to mentors.debian.net so that my sponsor can take a look at it. However, when I do $ dupload -t mentors texmacs_1.0.6.10-2_i386.changes dupload note: no announcement will be sent. Checking signatures before upload...GPG signature is missing dupload fatal error: Pre-upload '/usr/share/dupload/gpg-check %1' failed for texmacs_1.0.6.10-2_i386.changes at /usr/bin/dupload line 223 So mentors.debian.net requires packages to be signed. Is there any way around that? thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: signing packages from a different machine
On Wed, 22 Aug 2007 11:34:12 -0400 Kamaraju S Kusumanchi [EMAIL PROTECTED] wrote: I want to upload the packages to mentors.debian.net so that my sponsor can take a look at it. Then you really need to upload it from a secure machine that has your secret key. The reason for enforcing signatures is so that the sponsor can be sure that the package really was prepared by you. If you cannot trust the machine you are on, can you connect to a secure machine? If you cannot, you will need to delay the upload until you can. Do not compromise your secret key for the sake of this upload. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpwxtnUkRfcZ.pgp Description: PGP signature
RFS: pal (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.3.5-pre1-cvs20070815-1.0 of my package pal. It builds these binary packages: pal- Command-line calendar program that can keep track of events The package appears to be lintian clean. The upload would fix these bugs: 332642, 415457, 417854, 431352, 437732 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pal - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pal/pal_0.3.5-pre1-cvs20070815-1.0.dsc I would be glad if someone uploaded this package for me. Kind regards Martijn van Oosterhout -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ signature.asc Description: Digital signature
Re: RFS: pal (updated package)
On Wed, Aug 22, 2007 at 06:30:56PM +0200, Martijn van Oosterhout wrote.. I am looking for a sponsor for the new version 0.3.5-pre1-cvs20070815-1.0 of my package pal. It builds these binary packages: pal - Command-line calendar program that can keep track of events The package appears to be lintian clean. [EMAIL PROTECTED]:~/tmp/pal$ lintian pal_0.3.5-pre1-cvs20070815-1.0_i386.changes W: pal source: out-of-date-standards-version 3.6.1 (current is 3.7.2) W: pal: manpage-has-errors-from-man usr/share/man/man1/pal.1.gz 0: error: missing charset command -- Kevin Coyner GnuPG key: 1024D/8CE11941 signature.asc Description: Digital signature
Skipping version numbers in adopted packages
So far, all discussion I've seen about whether to collapse changes made during sponsorship review into a single debian revision for upload have focused in the case of an initial package upload. Does anyone have any special arguments for doing it one way or another in the case of an upgrade? Thanks. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: Skipping version numbers in adopted packages
On Wed, 22 Aug 2007 13:11:52 -0500 Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote: So far, all discussion I've seen about whether to collapse changes made during sponsorship review into a single debian revision for upload have focused in the case of an initial package upload. Really? My perception was that upgrades and updates are also covered in the same way as the ITP. It makes little sense to change the method after initial upload unless the maintainer is also changing sponsor. Does anyone have any special arguments for doing it one way or another in the case of an upgrade? ? My preference is mainly regarding upgrades. http://people.debian.org/~codehelp/#increment I have no problems with missing numbers when the update is 1.2.3-4 etc. Others disagree. I don't want to use ~foo (be that ~rfs or any other suffix) because I find that ugly. Others want to use tilde suffixes of various kinds. None of these preferences are invalid or necessarily better than any other, it's just preference. Unfortunately, that means that changing sponsor can mean changing the method but that is inherent in the current system. So 0.0.1-1 gets an RFS but it is 0.0.1-4 that I upload to close the ITP with appropriate -v and -sa options to debuild and pdebuild. 0.0.2 is released, 0.0.2-1 has a minor problem, so 0.0.2-2 gets uploaded. The PTS records 0.0.1-4 uploaded to unstable and the changelog lists 0.0.1-1, -2, -3 and -4. The next PTS record is 0.0.2-2 and clicking on the changelog link shows 0.0.2-1 and 0.0.2-2 (on top of the previous changelog entries). By 0.0.3 or 0.0.4, the maintainer is in a better position to prepare updated packages and -1 is likely to be good enough to upload. It is at this point that I'd be considering activating the proposals from the GR, once the infrastructure for that is in place. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgps3Vqc8kmh1.pgp Description: PGP signature
RFS: tesseract
Dear mentors, I am looking for a sponsor for the new version 2.00-1 of tesseract-ocr, plus the six language packages, tesseract-eng, tesseract-deu, tesseract-nld, tesseract-spa, tesseract-ita, tesseract-fra It builds these binary packages: tesseract - The well-known OCR engine first developed by HP and now taken over by Google The package appears to be lintian clean, apart from the fact that upstream has left a .svn directory in the tar. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tesseract - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract/tesseract_2.00-1.dsc The languages packages are: - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-deu - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-deu/tesseract-deu_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-eng - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-eng/tesseract-eng_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-fra - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-fra/tesseract-fra_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-ita - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-ita/tesseract-ita_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-nld - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-nld/tesseract-nld_2.00-1.dsc - URL: http://mentors.debian.net/debian/pool/main/t/tesseract-spa - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tesseract-spa/tesseract-spa_2.00-1.dsc I would be glad if someone uploaded this package for me. Regards Jeff Ratcliffe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
On Thu, Aug 16, 2007 at 08:03:04PM +0530, Kapil Hari Paranjape wrote: On Fri, 10 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: I am looking for a sponsor for the new version 3:4.20-3 of my package stunnel4. I have some fixes/suggestions for you. Since this would be the first package that I would sponsor, I hope we can learn from each other! :) I have uploaded a new version with the suggested fixes. Following your sugestion I used 3:4.20-4~1 as version. If you consider it worthy of upload, please change it to -4. And please build with -v3:4.20-2 Thanks http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-4~1.dsc General remark: === Please go through the package completely *as if* I were the person who had done the packaging and you were the person performing the sponsor-ship. Experience says that the time of adoption is probably the time when the maximum effort is/can be put into cleaning up packaging issues. Thanks, that's a good idea. It actually prompted two more changes: * Remove empty /usr/sbin dir. * Avoid linking to libz.so. configure checks for an specific function from it, required by openssl. But, as stunnel itself does not use the library, the generated dependency in zlib1g was bogus and marked as such by the checklib report. http://rerun.lefant.net/checklib/index.html http://rerun.lefant.net/checklib/[EMAIL PROTECTED] Must fixes: == - The author of debian/StunnelConf-0.1.pl is not mentioned in the debian/copyright file. I have *not* checked all the files in your tree. Please check each file of the unpacked source and the debian/ directory to find relevant attributions. - Please fix the debian/copyright file. See http://lists.debian.org/debian-devel-announce/2003/12/msg7.html Specifically, one thing that *is* missing is the dates of the copyright assertion by the upstream author. Done. - Avoid patching tools/script.sh in your diff. Use quilt instead. Ups. That was a mistake, I intended to do that from the start. In fact your collab-maint repository should ideally only contain the debian/ directory. I've been playing with both kinds of repositories, with and without upstream sources, in my packages, but I'm not sure yet which workflow is easier. Do you have some description on pros/cons from others, to help decide? - linda complains about the empty directory /usr/share/lintian/overrides/ I am not sure what you are using overrides here for. I just think it's easier to have debian/rules try to install the overrides file always, instead of adding/removing the snippet whenever the file gets empty. Anyways, the directory creation *is* a mistake. Fixed. - This changelog entry is not clearly written. * Use less cmd line args to debhelper commands in debian/rules. An alternative may be * Rewrite dh_* invocations in debian/rules. Or * Shorten dh_* invocations in debian/rules. Done Optional fixes: == - IMHO the README.Debian file needs better organisation. Perhaps three or four sections. One Upgrading from stunnel to stunnel4, two Sample Stunnel configurator, three Howto create Tunnels, four Howto create SSL keys for stunnel. Done - debian/StunnelConf-0.1.pl could perhaps be placed in /usr/share/doc/stunnel4/contrib/ as it is not a document but contributed code. Done - The preferred debian/changelog entry format seems to be. New maintainer. Closes: #416955. rather than Adopt package (closes: #416955). Done - I (have learnt to) prefer changelog entries that clearly indicate which files were changed rather than those that just describe the effect of the changes. Done. Kind of. I think some of the entries were explicit enough already. Not sure aspects: === - I am not sure that the warnings in the doc/ directory are enough of a warning for those who have so far been using stunnel3. Since stunnel starts network tunnels through init.d or inetd someone could suffer quite a bit in the transition. We should think about this some more ... I don't think there's much problem. Any automatic tunnel the user had will continue to work, thanks to the wrapper compatibility script. No new automatic tunnels will be created, because that requires manual enabling. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: dh_install and python version
Alexandre Rossi wrote: However, I'm not quite sure about this --install-lib usr/lib/python$* because : - it's nowhere to be seen in example packages Read the Debian Python policy[1], it may clear some things up. - I must harcode usr/lib/python2.4/... in debian/package.install files, this means that my package will FTBS when python2.5 becomes the default. Not true: you can put usr/lib/python*/... in package.install Shipping private modules clears the problem out (using --install-lib usr/share/sourcepackagename and moving the private extension using dh_install), but I see only advantages in shipping public modules for the default python version. My next idea is to preprocess new debian/package.install.in files into package.install files to match the python version. Is that not too hacky? Indeed it is hacky. Check the debian python policy for how to do this. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_install and python version
However, I'm not quite sure about this --install-lib usr/lib/python$* because : - it's nowhere to be seen in example packages Read the Debian Python policy[1], it may clear some things up. Thanks, the --debian option to setup.py was what confused me. With non --install-libs option (and no --debian option), it works well. - I must harcode usr/lib/python2.4/... in debian/package.install files, this means that my package will FTBS when python2.5 becomes the default. Not true: you can put usr/lib/python*/... in package.install Thanks, sometimes I'm so in that I can't even see the obvious. Shipping private modules clears the problem out (using --install-lib usr/share/sourcepackagename and moving the private extension using dh_install), but I see only advantages in shipping public modules for the default python version. My next idea is to preprocess new debian/package.install.in files into package.install files to match the python version. Is that not too hacky? Indeed it is hacky. Check the debian python policy for how to do this. The debian Python Policy says what to do, but not very often how. But thanks for everything, my problem is fixed. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
