Re: Bug#749152: RFS: top/2.2.3-1 [ITP]
On Sat, May 24, 2014 at 04:54:40PM +0200, Hugo Lefeuvre wrote: I am looking for a sponsor for my package top Package name: top Version : 2.2.3-1 Upstream Author : Hugo Pereira Da Costa hugo.pere...@free.fr URL : http://hugo.pereira.free.fr/software/ License : GPL2 Programming lang: C++ / Qt5 Section : admin It builds this binary package: top - windowed version of the console top command Thanks for your work on this. I am wondering whether top is the best package name, and Top the best binary name. I, for one, would be a little confused, given that the standard tool in the procps package is also named top. What is your opinion? Would a different package name be an option? Thanks. Kumar -- No, that's wrong too. Now there's a race condition between the rm and the mv. Hmm, I need more coffee. -- Guy Maor on Debian Bug#25228 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140524151720.GA3475@odessa
Re: how do I upload a package where the last changelog entry is by a co-maintainer?
On Mon, Jan 20, 2014 at 12:42:26PM +0100, Dennis van Dok wrote: Hi, my colleague has updated some of the packages for which I am the maintainer, and he is an uploader. The last changelog entry is by him. When I tried to upload to mentors, the package was refused and my colleague got e-mail from mentors stating that the (his) e-mail address was not found. Indeed he does not have a mentors account. I re-signed the changes file with my key and re-uploaded, but the result was the same. Does mentors only consider the name in the last changelog entry to see whose package it is? If he signs up for an account, will the package show up in my list of packages or his? Try using dch -r. That should update the timestamp, and put your name there. Kumar -- BREAKFAST.COM Halted... Cereal Port Not Responding. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120122021.GA24794@odessa
Re: [SOLVED] Uploading to mentors.debian.net without a signed key
On Sun, Aug 11, 2013 at 04:16:31PM +0600, Andrey Rahmatullin wrote: Thanks Kumar - the -k my-key-id did it! I saw it in --help, but I didn't think I would need it if I only had the one key. Why didn't I try it?!? You don't need to pass -k or similar options to any Debian tools if your key has the same user name as your changelog. That won't work if there two keys that share the same username and e-mail addresses. but I didn't think I would need it if I only had the one key Ah, true. I'd just be sure to check what key is used to generate the signature when -k is not specified. Kumar -- Vini, vidi, Linux! -- Unknown source -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130811133634.ga14...@bluemoon.alumni.iitm.ac.in
Re: Uploading to mentors.debian.net without a signed key
On Sat, Aug 10, 2013 at 04:38:28PM +0200, Ross Gammon wrote: I have tried signing the the changes file with debsign debsign foopackage.changes, but I assume this is just like the signing that the standard dpkg-buildpackage does? Personally, I use debsign -k my-key-id changesfile to ensure that my package is signed. Following this, you can open the changes file and the dsc file to see that they have been clearsigned. For instance, an unsigned changes file looks like this: == Format: 1.8 Date: Thu, 06 Jun 2013 08:07:48 -0400 Source: armadillo Binary: libarmadillo-dev libarmadillo3 Architecture: source amd64 Version: 1:3.900.2+dfsg-1 Distribution: unstable Urgency: low Maintainer: Debian Science Maintainers debian-science-maintain...@lists.alioth.debian.org Changed-By: Kumar Appaiah aku...@debian.org Description: libarmadillo-dev - streamlined C++ linear algebra library - Headers libarmadillo3 - streamlined C++ linear algebra library Changes: armadillo (1:3.900.2+dfsg-1) unstable; urgency=low . * New upstream release Checksums-Sha1: [snip] … == while a signed one looks like this: == -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 05 Aug 2013 07:30:51 -0400 Source: armadillo Binary: libarmadillo-dev libarmadillo3 Architecture: source amd64 Version: 1:3.900.7+dfsg-1 Distribution: unstable Urgency: low Maintainer: Debian Science Maintainers debian-science-maintain...@lists.alioth.debian.org Changed-By: Kumar Appaiah aku...@debian.org Description: libarmadillo-dev - streamlined C++ linear algebra library - Headers libarmadillo3 - streamlined C++ linear algebra library Changes: armadillo (1:3.900.7+dfsg-1) unstable; urgency=low . * New upstream release Checksums-Sha1: [snip] … -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJR/5EqAAoJEHqPSei2NIC+8IQQAJjhENzH49LzkhbRJPqWsXoS jz139BdDS86l0z9uPEbp4Y6kyXYT61FynO9Cq+PTeFFL0Im1bkJED1PlpRqqJRWw RFyDTQLEmI6alfQDX45P4A24bQr0vDsYSBR6CgA47on0IstKhUaeXgiygvGryCgA 2N2yErFwjc9rh6OsVO8rr4WeHrq3wdocSb6mCXt7e7ewlgyCXNn5yC8p9O21/mhf FS1U5VLH6yTkC/EFPrV8qGkzGBl3c3+f8mkf2H8DRiKzYcdU9THVvp4oOCtmPsdT pD3Q3HA62VIIqma533gO8h18a+2b34z5RIb4q0NFEariHztPwLzHqO/FZnoDzaZG Z8pSg6yqVDhHl/WSagWyQ9//7uWdZ1lPHtLn3qI5JEOrY2JYD6sppGgIGYsJSR4j /Zvh9e18iHFPC+HWzk/XOWlOp+iIPYDCkr1fwN1VBN8WTBEv27b76aDHgFdsXVRX HQ7eJYhOMhqEq7qu3IjJcraa4K7Y76gYdXCA3OT9Ppbw+JNzS3yIr2Ph07qtwS2m vTPNZZT2bacx1kqXUROuSWsVi6rGdIvfGDuI5mQdDmp1UnbP2u1Mvh7NdVG8x8km RNuqLXhjeTFR9TRElSDByo5sefaVYcecPYronYgt46KxLnTdio+Te+Y8EuqAXmSu DLkXuKCe/6rQEuvtNDkS =xeRH -END PGP SIGNATURE- == Not that the signature is embedded in. Is there a way to upload to mentors without needing to sign it with a key signed by a DM or DD? Or should I just wait until my local DD's get back from Debconf? Just try the above. Ensure that they key used for signing is the key known the the mentors site, and things should go well. You can verify this by doing gpg --verify changesfile yourself, after running debsign. HTH. Kumar -- Checking host system type... i586-unknown-linux configure: error: sorry, this is the gnu os, not linux -- Topic on #Linux -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130810161756.ga19...@bluemoon.alumni.iitm.ac.in
Re: [SOLVED] Uploading to mentors.debian.net without a signed key
On Sat, Aug 10, 2013 at 08:23:06PM +0200, Ross Gammon wrote: On 08/10/2013 06:17 PM, Kumar Appaiah wrote: Personally, I use debsign -k my-key-id changesfile to ensure that my package is signed. Following this, you can open the changes file and the dsc file to see that they have been clearsigned. Thanks Kumar - the -k my-key-id did it! I saw it in --help, but I didn't think I would need it if I only had the one key. Why didn't I try it?!? Ah, yes. I was intending to mention that you ought to choose the right key using the -k option. Glad that it worked for you. Kumar -- Absolutely nothing should be concluded from these figures except that no conclusion can be drawn from them. (By Joseph L. Brothers, Linux/PowerPC Project) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130810185217.ga8...@bluemoon.alumni.iitm.ac.in
Re: [SOLVED] Uploading to mentors.debian.net without a signed key
On Sun, Aug 11, 2013 at 02:41:02AM +0600, Andrey Rahmatullin wrote: Personally, I use debsign -k my-key-id changesfile to ensure that my package is signed. Following this, you can open the changes file and the dsc file to see that they have been clearsigned. Thanks Kumar - the -k my-key-id did it! I saw it in --help, but I didn't think I would need it if I only had the one key. Why didn't I try it?!? You don't need to pass -k or similar options to any Debian tools if your key has the same user name as your changelog. That won't work if there two keys that share the same username and e-mail addresses. Kumar -- Yes I have a Machintosh, please don't scream at me. -- Larry Blumette on linux-kernel -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130811021659.ga21...@bluemoon.alumni.iitm.ac.in
Re: Bug#668455: RFS: apt-build/0.12.43 QA - frontend to apt to build, optimize and install packages
Hi. On Thu, Apr 12, 2012 at 12:26:51AM +0200, D. Lasserre wrote: again I am looking for a sponsor for the orphaned package apt-build. This QA is primarily used to bring apt-build back to unstable (as there were no regression reports). I merged package codebase whith that in git repository (2 pending patches) and checked if (gfortran) wrapper is used. dget -x http://mentors.debian.net/debian/pool/main/a/apt-build/apt-build_0.12.43.dsc For changes since the last upload, see debian changelog: * QA upload. * Upload to unstable * Patch from Kumar Appaiah: Fix compiler links with host names. Closes: #502377 * Patch from Kumar Appaiah: Add gfortran support. Closes: #502379 I just wanted to point out that there is an extraneous 755 directory. Probably a remnant of you using a chmod and an mkdir together? ;-) In addition, do you intend to just do QA uploads or do you have intentions of taking up the package and becoming upstream? Thanks. Kumar -- BREAKFAST.COM Halted... Cereal Port Not Responding. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120412045332.gb16...@bluemoon.alumni.iitm.ac.in
Re: Fix FSF address in copyright notices?
On Tue, May 10, 2011 at 10:20:29PM -0700, Russ Allbery wrote: Kumar Appaiah a.ku...@alumni.iitm.ac.in writes: Pardon me if I miss something, but is it prudent to alter upstream's license without their permission in the source? Granted, it's just an address change which may not change the constraints and restriction imposed by the license itself, but I wonder if this would actually be the right thing to do, rather than have upstream fix it. [snip] The first two paragraphs establish the license, and are normative. The third paragraph isn't normative. It doesn't affect the terms and conditions of the work; it's just a pointer to where you can find the complete license. Fair. Thank you for the explanation. Kumar -- I would rather spend 10 hours reading someone else's source code than 10 minutes listening to Musak waiting for technical support which isn't. (By Dr. Greg Wettstein, Roger Maris Cancer Center) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110511055953.ga18...@bluemoon.alumni.iitm.ac.in
Re: Fix FSF address in copyright notices?
On Wed, May 11, 2011 at 02:57:18PM +1000, Ben Finney wrote: Matt Kraai kr...@ftbfs.org writes: Some of the copyright notices in a package I'm trying to create refer to the old address of the FSF and lintian warns about it. Should I fix this address? If so, should I fix it in both the copyright file and the source code? Or in only one place? Yes, fix it in both places. Send a patch to upstream fixing it in their code base; use that patch yourself in your Debian packaging while you wait for them to act on it. Pardon me if I miss something, but is it prudent to alter upstream's license without their permission in the source? Granted, it's just an address change which may not change the constraints and restriction imposed by the license itself, but I wonder if this would actually be the right thing to do, rather than have upstream fix it. Thanks. Kumar -- A Linux machine! because a 486 is a terrible thing to waste! (By j...@wintermute.ucr.edu, Joe Sloan) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110511050521.ga14...@bluemoon.alumni.iitm.ac.in
Re: On format upgrade during freeze time
On Fri, Oct 22, 2010 at 12:08:02PM +0100, Tim Retout wrote: On 22 October 2010 10:32, Mats Erik Andersson mats.anders...@gisladisker.se wrote: However, and this is my present question to you, would the release team decline the package due a decision to migrate to format 3.0 already now? Possibly, at this stage - it's not ideal to make packaging changes when fixing RC bugs; but if they did reject it, you would still be able to make an upload via testing-proposed-updates. testing-proposed-updates is often reserved as a last resort, since not much testing happens for packages uploaded via there. Many more people have unstable and testing in their sources.list, than testing-proposed-updates. If in doubt, you can ask the debian-release mailing list (preferably once you have a debdiff) before uploading the new package. This can also be done by filing a 'future unblock' bug against the release.debian.org pseudopackage: http://bugs.debian.org/release.debian.org Or, just mail them, if you don't feel like filing a bug (though the bug would make tracking easier for the release team). Kumar -- Those who don't understand Linux are doomed to reinvent it, poorly. -- unidentified source -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101022132642.ga9...@bluemoon.alumni.iitm.ac.in
Re: RFS: roxterm (updated package) [highly configurable terminal emulator]
Dear Tony, On Tue, Oct 12, 2010 at 03:34:38PM +0100, Tony Houghton wrote: On 12/10/10 00:50, Kumar Appaiah wrote: I'll take this. The change seems minimal, so I'll sponsor it. Please be sure to request the release team for a freeze exception. Thanks. I've sent a message to debian-release. I don't fully understand the freeze exception process. I see you already uploaded this to unstable, but last time George Danchev waited for a response from debian-release before uploading. Which is the more normal thing to do? It might have made more sense to ask the release team for permission, especially if you were suspicious that they might reject the change. However, since the change seemed minimal (and important), I made a guess (which I hope wasn't inaccurate) that the release team would not have too much of an issue in allowing it through. Maybe, from next time, I should first ask the release team first. But I don't think it should matter much. Also, I've now moved to 1.19.* upstream, which has new/changed features. Should I ask for this to be sponsored for experimental or just wait until the freeze is over? If you want to provide your users the package early on, experimental would be an option, though some don't like that approach (there is a discussion on this list happening now on this topic). But, in any event, under the current guidelines, I'd advise you to not get the new version into unstable during the freeze. Thanks for your contribution to Debian! Kumar -- Linux - Where do you want to fly today? -- Unknown source -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101012150952.ga27...@146653177.ece.utexas.edu
Re: RFS: roxterm (updated package) [highly configurable terminal emulator]
Hi! On Mon, Oct 11, 2010 at 06:37:49PM +0100, Tony Houghton wrote: The upload would fix these bugs: 598971 The bug can affect which environment variables roxterm decides to set or change in its child shells. The specific problem experienced in Ubuntu Maverick (not setting TERM correctly) is unlikely to affect Debian, because Debian's older vte library sets TERM whereas Maverick's doesn't. However, the bug still has potential to cause weird things to happen with environment variables and the fix is very simple, so I think it should be included in squeeze. I'll take this. The change seems minimal, so I'll sponsor it. Please be sure to request the release team for a freeze exception. Thanks for mailing the request again, and thank you for contributing to Debian! Kumar -- Who is General Failure and why is he reading my hard disk ? Microsoft spel chekar vor sail, worgs grate !! (By leit...@inf.fu-berlin.de, Felix von Leitner) signature.asc Description: Digital signature
Re: RFS: ooo-thumbnailer
On Sat, Feb 06, 2010 at 03:48:08PM -0500, Asheesh Laroia wrote: (Other Debian mentors -- is it okay to upload a package whose version is 0.2-3 or 0.2-4 as the first Debian upload? Or should we instead rewrite history and pretend this is 0.2-1 when it's ready to go?) The short answer is, yes. There is no absolute necessity to use upstream-1, unless you find appearing-to-start-from-clean-slate too important. Kumar -- /* * Please skip to the bottom of this file if you ate lunch recently * -- Alan */ -- from Linux kernel pre-2.1.91-1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
Hi! Let me address each point separately. On Fri, Jan 29, 2010 at 02:22:03PM +0100, Ersek, Laszlo wrote: Rogério Brito has submitted a wishlist bug report for lbzip2 [3]. As Rogério has accepted my proposal to use an external tool for his need, I'd like to close the bug with a wontfix tag. My question to Closing with a wontfix tag is something which people do, but I personally don't prefer. wontfix, IMHO, should be reserved for something like a potential problem or misfeature, which you acknowledge, but don't want to fix, at least for now. Usually, wontfix bugs are left open, so that 10 other people don't blindly submit the same bug report. I assume that you merely wish to close the bug in the following. the mentors list is the following: (1) what addresses should I put 1. nn-d...@bugs.debian.org in the To: field, and (2) how should I format the body of my message, so that (a) the bug gets closed, (b) the wontfix tag is saved in the appropriate place, (c) my explanation message shows up You cannot really close the bug and add the wontfix tag at the same time. You can send a separate mail to cont...@bugs.d.o with tags nn + wontfix to add the tag if you want to. both on the bug report page, and also on another bug's page [4], (d) the submitter (Rogério) gets a copy? Sending the mail to -done ensures that the mail is shown in the BTS page as well as the fact that the submitter receives it. I'm thinking of something like this: v To: 567196-d...@bugs.debian.org, Rogério Brito Cc: 563...@bugs.debian.org Subject: alternative accepted by submitter Package: lbzip2 Version: 0.20-1 Tags: wontfix thanks Won't work. :-) Check one of the several bugs which were just closed from the BTS. Randomly, I'll point you to this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547220#14 HTH. Kumar -- ...Deep Hack Mode--that mysterious and frightening state of consciousness where Mortal Users fear to tread. (By Matt Welsh) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: help with BTS mail interface
On Fri, Jan 29, 2010 at 08:34:49AM -0600, Kumar Appaiah wrote: [snipped OP's exampl Won't work. :-) Check one of the several bugs which were just closed from the BTS. Randomly, I'll point you to this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547220#14 By won't work, what I meant is that, while the bug would be closed, the tags won't be added; the pseudo-headers in your example won't be parsed by the BTS. Kumar -- World domination. Fast (By Linus Torvalds) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ripit (updated package)
On Sat, Oct 10, 2009 at 06:07:15PM +0200, Elimar Riesebieter wrote: * Elimar Riesebieter [091010 17:30 +0200] Dear mentors, I am looking for a sponsor for the new version 3.8.0-1 of my package ripit. I would be glad if someone uploaded this package for me. Done. But please mail debian-mentors again for the next sponsorship request, since I may not be a regular sponsor. Thanks a lot! Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: RFS: fftw3 3.2.1-1
Dear Paul, On Fri, Apr 03, 2009 at 07:42:59PM +0200, Paul Brossier wrote: Hi all, I would need a sponsor for fftw3. The package is available here: I am aware that you maintain fftw3. So, I built the package and checked it briefly, and it seems all right. In any case, I trust your judgement, so I have uploaded it to unstable. I hope your key is updated real soon! Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: RFS: pyrex 0.9.8.5-1 (or RFS: fftw3 3.2.1-1)
On Fri, Apr 03, 2009 at 05:58:17PM -0500, Boyd Stephen Smith Jr. wrote: I would need a sponsor for fftw3. The package is available here: dget http://goyave.piem.org/~piem/debian/fftw3_3.2.1-1.dsc Source: pyrex Binary: python-pyrex pyrex-mode How'd you get those mixed up!? Copy pasting error? In any case, I have uploaded this as well. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Building localy
2009/3/23 Jaromír Mikeš: If I will install newer perl from sid it will probably break my ubuntu here. I can't build in pbuilder coz missining dependencies. Can I somehow install manually dependencies to pbuilder chroot? The first section here might help: http://wiki.debian.org/PbuilderTricks Kumar -- Kumar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building localy
On Mon, Mar 23, 2009 at 5:32 PM, Chow Loong Jin wrote: If I will install newer perl from sid it will probably break my ubuntu here. I can't build in pbuilder coz missining dependencies. Can I somehow install manually dependencies to pbuilder chroot? The first section here might help: http://wiki.debian.org/PbuilderTricks Kumar -- Kumar I don't get it. debhelper should already pull in the appropriate perl. I cannot even begin to imagine how you borked up your perl installation to that extent. Er, I think you are right. I assumed that the OP wanted to build a package for sid on Ubuntu; and assumed that he would have a proper sid pbuilder chroot. I think I realize now that he wants to achieve something totally different. Sorry for the wrong tip. Kumar -- Kumar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building localy
On Mon, Mar 23, 2009 at 5:32 PM, Jaromír Mikeš wrote: If I will install newer perl from sid it will probably break my ubuntu here. I can't build in pbuilder coz missining dependencies. Can I somehow install manually dependencies to pbuilder chroot? The first section here might help: http://wiki.debian.org/PbuilderTricks That is absolutely what I was looking for ... Thanks o lot Oh, well, happy to help! :-) Kumar -- Kumar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building localy
On Mon, Mar 23, 2009 at 5:50 PM, Jaromír Mikeš wrote: That is absolutely what I was looking for ... http://wiki.debian.org/PbuilderTricks Sorry , but one think I don't understand: HOOKDIR=/path/to/hook/dir This has to be set in your pbuilderrc. I have a ~/.pbuilderrc in my home, which is called if I run pbuilder using sudo. If you don't have one, use /etc/pbuilderrc. My HOOKDIR is set to ~/.pbuilder/hooks/ though any other directory is also fine. # put a file like D05deps to your $HOOKDIR, make it executable and put this in there: (cd /path/to/the/dir/deps; apt-ftparchive packages . Packages) apt-get update Can you explain please? Create a file called D05deps in your HOOKDIR (for me, in ~/.pbuilder/hooks). The file should contain: #!/bin/sh (cd /path/to/the/dir/deps; apt-ftparchive packages . Packages) apt-get update Then, chmod +x ~/.pbuilder/hooks/D05deps and run pbuilder. It should now take the packages in /path/to/the/dir/deps in your build. Kumar -- Kumar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: substvar-source-version-is-deprecated
On Wed, Mar 18, 2009 at 02:15:33AM +0100, Jaromír Mikeš wrote: Hello, having this warning message from lintian. Even I was qooqling a lot I didn't found clear answer how to repair it. Two ways. First, run lintian with the -i option to display information on the errors, warnings etc. being reported. The second way is to run lintian-info --tags substvar-source-version-is-deprecated which gives the necessary information. HTH. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Using pbuilder to test packages with gcc-snapshot
On Fri, Nov 14, 2008 at 12:25:16PM +, Roger Leigh wrote: On Thu, Nov 13, 2008 at 08:19:38PM -0600, Kumar Appaiah wrote: I was wondering if you could suggest a nice way to use pbuilder to test package builds with gcc-snapshot. Just a note to point out that sbuild supports the use of gcc-snapshot without any special configuration. Just add the --use-snapshot option and it will make sure it's installed, and alter the build environment to use it in place of the default gcc. Thanks. So I guess it might be time to try out sbuild as well. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Using pbuilder to test packages with gcc-snapshot
Dear Debian Mentors, I was wondering if you could suggest a nice way to use pbuilder to test package builds with gcc-snapshot. Currently, I've got a way (albeit crude way) to get that working, and I have listed it here: Bottom part of: http://wiki.debian.org/PbuilderTricks However, one of my packages has a make check routine which runs some executables and compares the output generated for sanity checks. Unfortunately, the checks fail, as the programs fail to run because the LD_LIBRARY_PATH is not set to load the libraries for gcc-snapshot (e.g. the _new_ libstdc++ present in /usr/lib/gcc-snapshot/lib. When building outside a pbuilder, setting a nice LD_LIBRARY_PATH environment variable works. So, my questions are: 1. Is there a way to set an arbitrary environment variable while running pbuilder (in my case, LD_LIBRARY_PATH). 2. Is there a better way of doing gcc-snapshot testing with pbuilder? Either way, I promise to update the wiki page with the solution I get, and will then request the person filing the gcc-snapshot FTBFS bugs to point to that page, if possible. Thanks in advance. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Using pbuilder to test packages with gcc-snapshot
On Fri, Nov 14, 2008 at 11:34:31AM +0900, Paul Wise wrote:
1. Is there a way to set an arbitrary environment variable while
running pbuilder (in my case, LD_LIBRARY_PATH).
grep export ~/.pbuilderrc
export CCACHE_DIR=/var/cache/pbuilder/ccache
export PATH=/usr/lib/ccache:${PATH}
export DPKG_GENSYMBOLS_CHECK_LEVEL=4
export DEBUILD_DPKG_BUILDPACKAGE_OPTS=-j2
export MAKEFLAGS=-j2
Thanks. I guess I misread (or misinterpreted) the pbuilder man
page. setting LD_LIBRARY_PATH in pbuilderrc worked.
2. Is there a better way of doing gcc-snapshot testing with pbuilder?
I would add a hook to get an interactive shell before pbuilder
installs build-deps and install gcc-snapshot from that shell.
My pbuilder configuration contains the interactive shell hook(s):
http://people.debian.org/~pabs/tmp/pbuilder.tar.gz
Thanks, but I really want it to be automated for gcc-snapshot, so the
solution you suggest with the original trick on the Wiki works
perfectly for me.
Thanks for the information. I have updated the Wiki as well.
Kumar
--
Kumar Appaiah
signature.asc
Description: Digital signature
Re: Please clarify: to bugreport or not bugreport
On Tue, Nov 11, 2008 at 11:54:41AM +0100, Cyril Brulebois wrote: Kumar Appaiah [EMAIL PROTECTED] (01/11/2008): The most foolproof way of testing whether the package in question builds in pbuilder. pbuilder starts with a clean chroot, downloads the build dependencies, installs them and then copies and builds your package in that clean environment. If the package you suspect fails to build on a pbuilder environment, then that most likely points to a serious bug. Incomplete. pbuilder's (Build-)Dependency resolution differs from sbuild's, which is the tool used on buildds, so making sure the package builds in pbuilder (although usually sufficient) doesn't ensure it will do on buildds. BTW, setting sbuild chroots isn't really hard nowadays, so people may want to give it a try. :) Thanks for filling in. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Please clarify: to bugreport or not bugreport
On Sat, Nov 01, 2008 at 11:37:53PM +0200, Eric Pozharski wrote: Hence the problem; Sometimes I FTBFS some package -- because Build-Depends either misses some package or lacks explicitly set relation. FTBFS itself doesn't make problem for me (each time I'd managed to figure out a block and workaround it manually). I still can't decide -- should (would? could?) I bugreport this? Look, I admit that I build unusual way. Maybe it's not the problem? (I've solved that twice today, that's why I post.) The most foolproof way of testing whether the package in question builds in pbuilder. pbuilder starts with a clean chroot, downloads the build dependencies, installs them and then copies and builds your package in that clean environment. If the package you suspect fails to build on a pbuilder environment, then that most likely points to a serious bug. You can find the documentation of pbuilder here: http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html Hope this helps; else please tell me if I have misunderstood something. Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Query about Debian
On Tue, May 06, 2008 at 11:49:56AM +0500, Ambareen wrote: The problem i am facing is that, after this command execution, i can not work smoothly i.e. many of utilities do not work properly like web browser and in any case i shutdown debian , when i come bck to work next time , the debian no more works. It appers in light grey color as k for username password and become halted. so after that i again install debian and run the same command. I think the fetched dependencies do something wrong. Your question is far from clear, but it should be directed to [EMAIL PROTECTED], rather than here. If you get a login screen, I think you should just login. i have these lines written in sources.list : *dep http://ftp.us.debian.org/debian/sid main dep-src http://ftp.us.debian.org/debian/sid main The entries you want would be: deb http://ftp.us.debian.org/debian sid main deb-src http://ftp.us.debian.org/debian sid main HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: buildd analog for new maintainters
On Mon, May 05, 2008 at 08:04:37PM +0300, Eugene V. Lyubimkin wrote: Dear mentors, I have a question: is there a service for NMs, similar to buildd.debian.org for DMs, where NMs can build debian packages from source on different architectures and/or debian releases (etch/lenny/sid)? Or, can NMs somehow access buildd.debian.org? Uploads to Debian my DMs happen much the same way as uploads by Debian developers do, packages are built by the buildds. However, if you are referring to developer machines of various architectures to test your packages, I would guess that only Debian developers have access to such machines, and you may have to directo your architecture spcific queries and requests to debian-arch@lists.debian.org. HTH. Kumar P.S. Please don't recycle threads. -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: foo.diff.gz difficult to read
On Fri, Apr 25, 2008 at 02:59:12PM +0200, Goswin von Brederlow wrote: When I look at a diff.gz, I use zgrep '^+++ ' foo.diff.gz. If the zcat foo.diff.gz | diffstat Just for the record, diffstat foo.diff.gz would do. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: BTS Command to get messages to a BUG#
On Sat, Mar 15, 2008 at 10:40:51PM +0100, Michelle Konzack wrote: Hello Mentors, Please can you tell me the BTS/PTS command (and the E-Mail) which I must use to get all messages to a Bug#. If you need an mbox: bts --mbox show bugno HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: What is the urgency field (in debian/changelog) for?
On Thu, Feb 21, 2008 at 04:46:50PM +0100, Siegfried-Angel wrote: I'd like to ask you where I could find an explanation about what the 'urgency' field in debian/changelog is for, as it has been intriguing me for quite some time now. I've checked the Debian Policy Manual and the Debian New Maintainers' Guide but couldn't find much information about it in neither of them. urgency=low: Usual upload, and you would want Britney to try to transition the package to testing in 10 days (of no RC bugginess) urgency=medium: RC bug fix(es). You give Britney 5 days for a transition attempt. urgency=high: For fixing critical bugs (esp. security). 2 days for transition. Please see: http://www.debian.org/devel/testing HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: How uploaded zerofree?
On Thu, Feb 14, 2008 at 11:56:49AM +0100, Thibaut Paumard wrote: Hi, someone was so kind as to upload one of my packages, zerofree (now in NEW). I'd like to be sure who that was, so I can contact them later for the next upload for instance. How can I find out? It was Christoph Haas. You can find out by going to your QA page, and putting the mouse over the NEW link: http://qa.debian.org/[EMAIL PROTECTED] Once uploaded, you may wish to use the who-uploads package in devscripts. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: How uploaded zerofree?
On Thu, Feb 14, 2008 at 12:08:11PM +0100, Patrick Winnertz wrote: someone was so kind as to upload one of my packages, zerofree (now in NEW). I'd like to be sure who that was, so I can contact them later for the next upload for instance. How can I find out? It was Christoph Haas. You can find out by going to your QA page, and putting the mouse over the NEW link: Sorry.. :) No. It was me. He also asks for sponsorship on the pkg-virtualbox-devel list on alioth and I replied there that I'll sponsor it. (but as I saw now, I forgot to CC him, so he doesn't get that email, since he wasn't subscribed.). Argh! Yes, I am sorry. The first package on that list, which is yorick-spydr, was uploaded by Christoph. The second one, naturally, says winnie. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: List of out-of-date packages on a given architecture.
On Tue, Feb 05, 2008 at 10:09:21AM +0530, Kapil Hari Paranjape wrote:
On Tue, 05 Feb 2008, Charles Plessy wrote:
So in conclusion, we have nothing else to do than hoping that the
buildds will restart keeping up some day, or is it time to ask on
debian-release that packages not up to date on these arches are allowed
to migrate in testing anyway ?
Or you could look for a suitable mips machine that could be used to
help the existing buildd's!
I did ask around here but no one seemed to have one.
(Off-topic, but anyway...)
Having a mipsel machine would help with debugging many things as
well. For example, the most recent are:
lam FTBFSing on mipsel due to a gcc bug:
http://experimental.ftbfs.de/fetch.php?pkg=lamver=7.1.2-1.1arch=mipselstamp=1202167930file=logas=raw
lapack FTBFSing on mips due to a mysterious reason:
http://experimental.ftbfs.de/fetch.php?pkg=lapackver=3.1.1-0.2arch=mipsstamp=1202168381file=logas=raw
If I get enough money later in life, I'm definitely buying one of
these machines, _just_ for testing out stuff and doing a dput/dupload
of packages built on them. Would look awesome to stand apart with a
mips(el) or s390 upload, when others are doing only
source+{i386,amd64}. :-)
Kumar
--
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036
signature.asc
Description: Digital signature
Re: List of out-of-date packages on a given architecture.
(Removing CC to debian-mips, as your last mail got the point across).
On Tue, Feb 05, 2008 at 06:01:55AM +0100, Cyril Brulebois wrote:
On 05/02/2008, Kumar Appaiah wrote:
lam FTBFSing on mipsel due to a gcc bug:
http://experimental.ftbfs.de/fetch.php?pkg=lamver=7.1.2-1.1arch=mipselstamp=1202167930file=logas=raw
Enjoy 4.3 series... An IMHO interesting test would be trying to get it
built with 4.2.
While I'd love to, this is a job for Debian (mips) man!. What I mean
is, someone has to do this on a machine and tell me if this is a
regression (since doko has ruled out the possiblity of GCC 4.2 being
the preferred build toolchain component, we have confirm that it's a
regression).
lapack FTBFSing on mips due to a mysterious reason:
http://experimental.ftbfs.de/fetch.php?pkg=lapackver=3.1.1-0.2arch=mipsstamp=1202168381file=logas=raw
Maybe killed from outside, not necessarily a compiler error like the
first one.
Possible, since it doesn't look like this:
http://buildd.debian.org/fetch.cgi?pkg=lapackarch=s390ver=3.0.2531a-1.2stamp=1202005519file=logas=raw
That is outright mysterious, though the blame goes on gcc
there. Again, this (according to knowledgeable people) is a gcc
bug. doko is working on fixing it (or working around it temporarily).
If I get enough money later in life, I'm definitely buying one of
these machines, _just_ for testing out stuff and doing a
dput/dupload of packages built on them.
Porter machines could help, anyway. Depending on the architectures,
there are some of them available (at least for DDs). Some nice people
even offer access to their architectures to mere contributors (hppa,
kfreebsd-*, for example).
True. And another thing I wish to place on record is my appreciation
and gratitude to the porters who help keep a mammoth distribution sane
on so many architectures.
Would look awesome to stand apart with a mips(el) or s390 upload,
when others are doing only source+{i386,amd64}. :-)
You're forgetting powerpc uploads anyway. :p
Accepted; I've seen a few people do that. But an esoteric (from my
POV) architecture would be too cool! :-)
Kumar
--
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036
signature.asc
Description: Digital signature
Re: List of out-of-date packages on a given architecture.
On Tue, Feb 05, 2008 at 06:21:24AM +0100, Cyril Brulebois wrote: On 05/02/2008, Kumar Appaiah wrote: (Removing CC to debian-mips, as your last mail got the point across). Well, that was on purpose... I know, and that was the right thing. Enjoy 4.3 series... An IMHO interesting test would be trying to get it built with 4.2. While I'd love to, this is a job for Debian (mips) man!. What I mean is, someone has to do this on a machine and tell me if this is a regression (since doko has ruled out the possiblity of GCC 4.2 being the preferred build toolchain component, we have confirm that it's a regression). ... since I'd bet it's more likely to have a subscriber of -mips than a subscriber of -mentors be able to do so, that's why I replied with a cross-post. You might want to try [EMAIL PROTECTED], but looks to me you might have more chance by asking the -mips subscribers. I am thankful to you for doing so, which is why I said you got the point across (to the right people). :-) Just to confirm, is it considered all right to mail debian-port for help on debugging architecture specific problems? I guess people who listen wouldn't mind helping out, would they? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: localizator
On Sun, Dec 30, 2007 at 12:10:45AM -0300, Mauro wrote: Hi there, Kumar i did the changed you recomend me, and everything worked fine now. thanks :) The version is OK now. Great! If anybody could give me any other advice or comments about this package, i'll appreciate this The url is: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=localizator Please always give the dsc URL: http://mentors.debian.net/debian/pool/main/l/localizator/localizator_0.2-1.dsc Let me give you some additional remarks: 1. Successive builds fail. It doesn't seem to build if I do dpkg-buildpackage;dpkg-buildpackage. Am I doing something wrong? 2. Priority should be `optional', not extra. 3. Please don't use smileys in the description. :-) There may be a few more issues, I'll let a DD suggest these, as I also have some doubts... HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: localizator
On 28/12/2007, Mauro wrote: Hi Kumar, i followed your advices and re-uploaded the package to mentors.debian.net; but im afraid that i didn't understood what you meant by 'my package being a native package', i mean the differences between the source in the orig.tar.gz and the package are the paths (original source uses relative paths and the package uses absolute paths), and those differences are just because i didn't 'gave' a directory structure to the original source code when i made it. tell me if im wrong with this. Dear Mauro, I can't build your package at the moment (not near my sid machine), but I saw the changes you made, and they are very much in the right direction. However, you should build a non-native package. To do this, before building the package 1. Put localizator_0.2.orig.tar.gz in the directory before the source directory. Ensure that it has NO debian/ directory; that is, the tarball should be the upstream tarball, and the Debian specific things will appear in the .diff.gz. 2. Set the version in the changelog to 0.2-1 instead of 0.2. 0.2 is the upstream version, while the `1' after the hyphen refers to the Debian revision. Say, some days later, you make changes tothe Debian packaging _without_ changing anything in the .orig.tar.gz. In such a case, you would just make the Debian specific change, write a changelog entry for 0.2-2 and build it. This way, the packaging and upstream are separated. See some example packages to get this point clear. Once you get this done, build your package, and install it and run it. Once it seems OK, you have a basic package working. Then, fine tune your packaging by running lintian -i -I on the changes file, and observe the warnings and advice to correct them. If you go through these steps carefully once, it'll be very easy to do them the next time onwards. I'll check your package again tomorrow, but if someone else (preferably a DD) comes up for checking before that, it would be nice. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: localizator
Dear Mauro, On Fri, Dec 28, 2007 at 02:38:51AM -0300, Mauro wrote: I am looking for a sponsor for my package localizator. * Package name: localizator Version : 0.2 Upstream Author : Mauro Lizaur [EMAIL PROTECTED] * URL : http://mlizaur.unixpod.com/py/localizator/ * License : GPLv2 Section : misc - dget http://mentors.debian.net/debian/pool/main/l/localizator/localizator_0.2.dsc I would be glad if someone uploaded this package for me. I am not a Debian developer, but just happened to see your package. I have the following remarks/questions. * Why is your package a native package? Please see section 5.4 of the developer's reference, if you are unaware of what I mean, but in short, Debian packages are usually non-native if they are not specific to Debian (exceptions exist). If there is no compelling reason for this package to be a native one, please make it an `ordinary' one. * Please correct Standards-Version. Also, use 3.7.3, as it is the most recent one. * Your package should be `Architecture: all'. * You really shouldn't be packaging a Python application or module without using the Python tools for Debian, viz. Python Central and Python Support. Please refer to the manuals and use them. /usr/share/doc/python-support/README.gz makes a good read. See some example Python applications to get an idea; here are a few: http://qa.debian.org/[EMAIL PROTECTED] Of course, consider joining the Python Application Team as well. Hope the input is useful. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On Thu, Dec 20, 2007 at 12:23:49PM +0530, Kumar Appaiah wrote: Well, I've filed one already with a patch and severity serious! It does affect common behaviour from earlier though. Let me downgrade it if it comes to that, or the maintainer objects. OK, the verdict from #457151 is that ordering of Build-Depends must not be relied upon, and Build-Conflicts is the way to go. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Finding out why a Build-Dependency is fetched.
Dear Debian Mentors, This is with reference to a package of mine, libitpp, whose latest version I have packaged and it is available at: http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_4.0.1-2.dsc What I want to know is, earlier builds never pulled in atlas3-base-dev for the build, as you may see here: http://buildd.debian.org/fetch.cgi?pkg=libitpparch=i386ver=4.0.0-3stamp=1193598381file=logas=raw Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for the build, and my package now depends on atlas3-base. The same thing happens on amd64 (thanks to William Pitcock for testing it for me). Despite my best efforts, I am unable to spot what is causing atlas to be pulled in. I do observe that lapack3-dev has the following dependencies: Depends: lapack3 (= 3.0.2531a-6.1), libc6-dev, atlas3-base-dev | refblas3-dev | libblas-3.so, g77 However, libitpp uses the following dependencies: Build-Depends: debhelper (= 5), autotools-dev, doxygen (= 1.5.1-1), refblas3-dev, libfftw3-dev, texlive-latex-base, gs, lapack3-dev Clearly, refblas3-dev is provided, so lapack3-dev shouldn't need atlas3-base-dev, right? What am I missing? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
(Annotation at the end) On Thu, Dec 20, 2007 at 10:30:14AM +0530, Kumar Appaiah wrote: Dear Debian Mentors, This is with reference to a package of mine, libitpp, whose latest version I have packaged and it is available at: http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_4.0.1-2.dsc What I want to know is, earlier builds never pulled in atlas3-base-dev for the build, as you may see here: http://buildd.debian.org/fetch.cgi?pkg=libitpparch=i386ver=4.0.0-3stamp=1193598381file=logas=raw Also, when I try to build the package on my machine outside a pbuilder, with the B-Deps installed, it works fine without atlas, and generates packages which don't depend explicitly on libatlas. However, the moment I try to use pbuilder on it, it fetches atlas3-base-dev for the build, and my package now depends on atlas3-base. The same thing happens on amd64 (thanks to William Pitcock for testing it for me). Despite my best efforts, I am unable to spot what is causing atlas to be pulled in. I do observe that lapack3-dev has the following dependencies: Depends: lapack3 (= 3.0.2531a-6.1), libc6-dev, atlas3-base-dev | refblas3-dev | libblas-3.so, g77 However, libitpp uses the following dependencies: Build-Depends: debhelper (= 5), autotools-dev, doxygen (= 1.5.1-1), refblas3-dev, libfftw3-dev, texlive-latex-base, gs, lapack3-dev Clearly, refblas3-dev is provided, so lapack3-dev shouldn't need atlas3-base-dev, right? What am I missing? FWIW, I observe a similar happening with octave2.9. The Build-Depends haven't change significantly, but all of a sudden, atlas is coming in: Without Atlas on Sparc: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.17-1arch=sparcstamp=1195174810file=log With Atlas on Sparc: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.19-1arch=sparcstamp=1197772112file=log Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
Hi! On Thu, Dec 20, 2007 at 10:56:46AM +0530, Kapil Hari Paranjape wrote: The building of a package should not produce a different package if some additional packages not listed in Build-Conflicts are installed. In other words, if you specifically do not want atlas3-base-dev to be present during the build then you should put it in Build-Conflicts. I am aware, but want to avoid it. I know that this does not explain why pbuilder is behaving the way it is but it seems to be a solution. Well, here's a further diagnosis. For some reason, the order of installed packages in the buildds (and my pbuilder) are being reordered in alphabetical order. See this old log. The apt-get command follows the same order as specified in the package's Build-Depends: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.17-1arch=sparcstamp=1195174810file=log But here, it is in alphabetical order: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.19-1arch=sparcstamp=1197772112file=log And I saw the source package for octave2.9, here's the control: Build-Depends: g++-4.1 (= 4.1.1-4), debhelper (= 5.0.0), autoconf, texinfo, texlive-latex-base, texlive-generic-recommended, g77, libreadline5-dev, libncurses5-dev, gperf, libhdf5-serial-dev (= 1.6.5) | libhdf5-lam-dev (= 1.6.5) | libhdf5-mpich-dev (= 1.6.5), refblas3-dev | atlas3-base-dev, lapack3-dev | atlas3-base-dev, gnuplot-nox, fftw3-dev, texi2html, less, dpatch, slice, libpcre3-dev, flex, libglpk-dev (= 4.15), libsuitesparse-dev, gawk, gs-gpl, libcurl4-dev, libqhull-dev, desktop-file-utils Notice that refblas3-dev is _before_ lapack3-dev. Now, if apt-get is called faithfully in this order, atlas does not come in. But if it is reordered, the lapack3-dev dependencies are honoured first, and that pulls in atlas3-base, which is the first alternate dependency, and is satisfiable. Now, the question is, where is the reordering occurring? sbuild? Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On Thu, Dec 20, 2007 at 11:49:53AM +0530, Kumar Appaiah wrote: See this old log. The apt-get command follows the same order as specified in the package's Build-Depends: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.17-1arch=sparcstamp=1195174810file=log But here, it is in alphabetical order: http://buildd.debian.org/fetch.cgi?pkg=octave2.9ver=1%3A2.9.19-1arch=sparcstamp=1197772112file=log And I saw the source package for octave2.9, here's the control: Build-Depends: g++-4.1 (= 4.1.1-4), debhelper (= 5.0.0), autoconf, texinfo, texlive-latex-base, texlive-generic-recommended, g77, libreadline5-dev, libncurses5-dev, gperf, libhdf5-serial-dev (= 1.6.5) | libhdf5-lam-dev (= 1.6.5) | libhdf5-mpich-dev (= 1.6.5), refblas3-dev | atlas3-base-dev, lapack3-dev | atlas3-base-dev, gnuplot-nox, fftw3-dev, texi2html, less, dpatch, slice, libpcre3-dev, flex, libglpk-dev (= 4.15), libsuitesparse-dev, gawk, gs-gpl, libcurl4-dev, libqhull-dev, desktop-file-utils Notice that refblas3-dev is _before_ lapack3-dev. Now, if apt-get is called faithfully in this order, atlas does not come in. But if it is reordered, the lapack3-dev dependencies are honoured first, and that pulls in atlas3-base, which is the first alternate dependency, and is satisfiable. Now, the question is, where is the reordering occurring? sbuild? And the answer is, that the dsc file itself has it ordered! The generated dsc file has ordered B-Deps. I think this has to do with the dpkg-dev refactoring. I'll find out if a bug is warranted, though I'd appreciate more input. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Finding out why a Build-Dependency is fetched.
On Thu, Dec 20, 2007 at 12:01:24PM +0530, Y Giridhar Appaji Nag wrote: IMO, this isn't a bug. The order in which packages are listed in the build-depends shouldn't matter. Build-Depends: lapack3-dev | refblas3-dev or Build-Depends: refblas3-dev | lapack3-dev (if you please) is what you want to use really. Well, I've filed one already with a patch and severity serious! It does affect common behaviour from earlier though. Let me downgrade it if it comes to that, or the maintainer objects. And no. I want to Build-Depend on BOTH lapack3-dev and refblas3-dev, and not one of them. I don't want atlas3 coming in. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: colordiff
On Wed, Dec 12, 2007 at 10:38:27PM +, Colin Tuckley wrote: Yes, in fact so new that I don't think the lintian update has made it into testing yet (you do run lintian -i on your package don't you?). It's always best to use the lintian in sid, since all packages (most of them) enter , and are meant for, sid. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: mustang
Dear Morten, On Fri, Dec 14, 2007 at 12:29:49AM +0100, Morten Kjeldgaard wrote: - dget http://mentors.debian.net/debian/pool/main/m/mustang/mustang_3.0-1.dsc I would be glad if someone uploaded this package for me. I am not a DD, but want to just make some minor points: * A diffstat of your diff.gz reveals that some .pdb files in the tests are entering the .diff.gz. If they are generated during the build, please remove them in the clean section, though I am not sure. If you wish to include them anyway, I would suggest a patch system like dpatch or quilt, if possible. * Have you filed an ITP bug? If not, please file an ITP bug against the WNPP package, and make the upload close the package. More details are at: http://www.debian.org/devel/wnpp/ * Please use 3.7.3 as the standards version. Ensure you use lintian from the latest sid, as all packages enter sid (unstable). Otherwise, I think it's fine. A DD's eye can spot further problems. :-) All the best! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: mustang
On Fri, Dec 14, 2007 at 11:18:30AM +0530, Kumar Appaiah wrote: - dget http://mentors.debian.net/debian/pool/main/m/mustang/mustang_3.0-1.dsc I would be glad if someone uploaded this package for me. I am not a DD, but want to just make some minor points: * A diffstat of your diff.gz reveals that some .pdb files in the tests are entering the .diff.gz. If they are generated during the build, please remove them in the clean section, though I am not sure. If you wish to include them anyway, I would suggest a patch system like dpatch or quilt, if possible. * Have you filed an ITP bug? If not, please file an ITP bug against the WNPP package, and make the upload close the package. More Of course, I meant close the bug! :-) details are at: http://www.debian.org/devel/wnpp/ * Please use 3.7.3 as the standards version. Ensure you use lintian from the latest sid, as all packages enter sid (unstable). Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Packages getting created without signature
On Wed, Dec 12, 2007 at 04:44:03AM -0800, iluvlinux wrote: hi i don't have a GPG key, and i also don't know how to create one. i went through the maintainers guide at location http://www.debian.org/doc/maint-guide/index.en.html#contents http://www.debian.org/doc/maint-guide/index.en.html#contents You definitely need a GPG key, because, even to upload to Debian mentors, the processing of your upload requires your public key. So, please read a GPG howto, and get a key made! :-) Here's one: http://dewinter.com/gnupg_howto/english/GPGMiniHowto.html HTH. Look forward to your contributions to Debian! :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 09:10:11AM -0200, Tiago Saboga wrote: I am polishing the packages for omegat (#448867) and libhtmlparser-java (#448872) and I have a few questions. The background is that I already have to repackage upstream tarball, because they contain compiled jars. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? For many Java packages, I have had to do this, especially to have nice looking patches. 2) Should I convert the encoding to utf-8? I don't know about this. In libhtmlparser, there are two files without copyright notice. This is already corrected in upstream's svn, but upstream is slowly preparing a new major version and doesn't seem likely to release soon. May I introduce myself the notice, noting somewhere that it was 'backported' from svn? Again, this is also a debatable one. But since you are repackaging, you might want to merge these changes from upstream, or patch them, without hurting anyone's sentiments. But I think more knowledgeable persons should answer this. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: I don't know much about java, but if those are just compilations of things for which the source is also in the tarball, there is no need to repackage. You can remove them in the clean target in debian/rules, for example, to make sure they are regenerated. But of course I may be completely missing the point. :-) The idea is that FTP master rejects abt binary content in your orig.tar.gz for which you don't have source. So, if you package for Java, remove all the jars, package them from their source, and repackage your original program (Build-)?Depending on the others. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to beautify it. If this conversion is a good idea (and I agree that it is), then that is an upstream issue, and it should be fixed there. Asking them about it is a good idea, changing it in the package is not IMO. I had to do this, because this caused some build failed for some reason (I don't recall, but my mentor asked me to do it). Also, my patches looked too ugly. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 10:09:59AM -0500, Justin Pryzby wrote: Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged because some files had to be removed, she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. In fact devref 6.7.8.2.2 discourages doing anything except removing files when repackaging. If this is the case, I shall try to avoid it in the next revision. Thanks for pointing this out. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:59:44PM +0100, Bas Wijnen wrote: Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged because some files had to be removed, she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. That is all documented in README.Debain-source. All the repackaged packages of mine have such a file which describe, in detail, what I do. In that sense, it is not hidden. Also, my patches looked too ugly. And that's not an argument not to use it. :-) If you need to do ugly things, then it should look ugly. Putting those changes somewhere where they're hard to see may cause other problems which are hard to track down (not for you, but for other people who are expecting the have the original source). Especially if those changes are needed to make the build work, it is important that they are visible like other changes, and that's in the .diff.gz (directly or through a patch system, whatever you prefer). I agree on this, and you are very correct. But my mentor recommended the change, as we were repackaging it anyway. Besides, noting whatever I've done in README.Debian-source does alleviate suffering a little. But it's always tough when repackaging... *sigh* Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Doubt about a java version of a package
On Wed, Oct 24, 2007 at 10:48:31PM -0400, Muammar El Khatib wrote: I have a package (yacas [0]) which is providing a java-based version of itself on its latest upstream version. I have read the java-policy. I read that the file (in my case a .jar one) must be executable and installed in /usr/bin. What I am not sure it's how the application should be launched when it's installed in Debian. As far as I can tell, the JAR must be put in /usr/share/java, and the executable must be a wrapper script which calls the java interpreter with the right jar. For example, in case of JFTP: [EMAIL PROTECTED] ~] ls -l /usr/share/java/jftp* -rw-r--r-- 1 root root 466158 2007-10-12 10:57 /usr/share/java/jftp-1.51~pre3.jar lrwxrwxrwx 1 root root 18 2007-10-25 08:29 /usr/share/java/jftp.jar - jftp-1.51~pre3.jar And /usr/bin/jftp has this: #!/bin/sh /usr/lib/jvm/java-6-sun/jre/bin/java -jar /usr/share/java/jftp.jar $@ (Note that your package shouldn't explicitly use /usr/lib/jvm/etc. unless you specifically require a JVM for it. You should use /usr/bin/java, which defaults to the JVM alternative the user has set in /etc/alternnatives/java.) I'd like to know if any of you know about a package in Debian that installs a java application so I can do an apt-get source and see how to proceed. (I've tried downloading some packages making use of aptitude search but I haven't found the right one yet) Well, you could see jftp, except that it's in contrib, but you may be able to get it into main if you get it to build it with a free Java compiler like gcj. Or, see the pkg-java list for a bigger list. I hope you can help me. Come to debian-java for more. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Doubt about a java version of a package
On Wed, Oct 24, 2007 at 11:19:46PM -0400, Muammar El Khatib wrote: Well, you could see jftp, except that it's in contrib, but you may be able to get it into main if you get it to build it with a free Java compiler like gcj. Or, see the pkg-java list for a bigger list. I had to use sun-java6-jdk to compile the application, so I'll have to try to build it using a free java compiler to get the java-based version into main, right? (I'm sorry for asking that but it's my first time facing a java packaging) If you have a look at the JFTP rules file, it has this line: JAVA_HOME := /usr/lib/jvm/java-6-sun Now, instead of this, you should try to use /usr/lib/jvm/java-gcj and Build-Depend on java-gcj-compat-dev. If this helps build your package and runs it, yacas can stay in main. However, if you just can't build it using GCJ, then you may try kaffe or jikes, but I don't know too much about them. See any of the packages maintained by pkg-java-maintainers. For example, commons-io is a simple one. They all use cdbs for building, and it should be quite simple to adapt the ant based build to yacas. All the best! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New packaging advice, manpages and binary additions
On Mon, Oct 15, 2007 at 10:46:08AM +0100, Robin Cornelius wrote: The first issue i had was getting my man page to be found in the debianised source. I could not find this documentation anywhere but it seems that just having my manpage named debian/qavimator.6 was not enough i had to also have a file debian/manpages that lists the manpages to be included, eg contained debian/qavimator.6. Have i just misunderstood the documentation (new maintainers guide and policy reference), or have there been changes to dh_installman ? Put a file called manpages in the Debian directory (or package/manpages, in case you use multiple packages). The contents of this file should be: debian/qavimator.6 That's it, if you ensure that dh_installman is called. Second issue is how do I add a binary file, eg an icon (xpm), to the source tree?. The applicaiton is a X11 QT app and so it would be nice to have a menu icon but upstream does not have one. Clearly the ideal situation is to get upstream to add one but untill that happens is it possible to just add an icon to the source tree with out unrepresentable changes messages when running dpkg-buildpackage ? What is the correct policy for doing this? Do i need to split the package into 2 for arch independent and dependent, the amount of data is very small so it did not seem worth while. As you say, you can convert the image to XPM and put it in the debian/ directory. Then, you can use dh_install to put it in the right place. One final thing, upstream only has a SVN tree, it is not making tarball releases. Is this an issue? I can try to work with them to see if they will do it, but if not should i create a friendly fork? No issue. Just ensure that you version your tarballs with epoch etc. For example, foo-1.2.3+svn20071015-1 could be the version. If they don't have any version (like 1.2.3), you may artifically add 0 and make the Debian version foo-0+svn20071015-1. Ensure you name your orig.tar.gz appropriately. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New packaging advice, manpages and binary additions
On Mon, Oct 15, 2007 at 03:59:46PM +0530, Kumar Appaiah wrote: Put a file called manpages in the Debian directory (or package/manpages, in case you use multiple packages). The contents Sorry, it should be package.manpages. of this file should be: debian/qavimator.6 That's it, if you ensure that dh_installman is called. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#444514: marked as done (gpredict: FTBFS: error: 'GtkTooltips' undeclared)
On Mon, Oct 15, 2007 at 08:36:26PM +0900, Charles Plessy wrote: Since the maintainer is not a DD and is apparently inactive for one year, I would recommend Cyril to ask on -devel, and -qa if he can orphan the package, and then propose comprehensive NMU. If it is to be orphaned, there are two other ways: 1. Systematic: ITA+Upload. 2. Not recommended: Hijack+Upload. :-) 3. Plain NMU. This is just to make the point clear... Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xmms-pulse
On Fri, Sep 28, 2007 at 12:19:12AM +0800, Thomas Goirand wrote: I'm not registered to the debian-devel as it's a way too much traffic for me to read on... When I first subscribed, it was on the java license problem period, and it was too much for me. Is it always that busy? Do you think it's a mistake not to read that list? 1. It's not a mistake that you didn't read that list. But just make it a point to poll the archives for a week or so after you file an ITP. 2. If you call debian-devel busy, what about debian-user? :-) Kumar P.S. A nice comparison: http://gmane.org/plot-rate.php?group=gmane.linux.debian.user http://gmane.org/plot-rate.php?group=gmane.linux.debian.devel.general -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
On Tue, Sep 25, 2007 at 09:22:33AM +0200, liran tal wrote: I will add the webpage address to the debian/copyright. Is there a webpage tag to add in the debian/control file or should I simply add it to the description? No. I think what Christoph wants you to do is add Homepage: http://...; in the intial section of the control file as a field, below Build-Depends, Section etc. Since you are also the upstream I suggest you ask a fellow Debian developer to create the package for you. Or file a WNPP bug to find someone to create a package (`reportbug wnpp`). Uhmm, I will check the 'reportbug wnpp' indeed although I thought that this would be the place to get the package sponsored - i.e receiving help from a Debian maintainer/developer to help build this package and upload it to Debian's repositories. If you are intent on being the Debian package maintainer, thisis the right place and people will guide you here. All the best! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
On Tue, Sep 25, 2007 at 10:47:19AM +0200, liran tal wrote: I have some questions regarding the package building though which concerns the orig.tar.gz I think... The way I build the package is having in the daloradius-0.9.3/ directory the debian/ and the usr/ directories where the usr/ occupies in the full path of usr/share/daloradius my package files (the php stuff and everything). in debian/rules what I do is cp daloradius-0.9.3/usr to daloradius-0.9.3/debian/usr Is this ok? I'm asking because I think that having the orig.tar.gz makes dpkg-source think that it's suppose to copy it over to the daloradius-0.9.3/debian dir but I'm not entirely sure. Actually, the recommended way to copy files from your upstream source location to the debian/package directory would be to use dh_install. Even better than calling dh_install directly from rules would be to use an install file in the debian/ directory which has things of the form upstream file/directory destination For example, for the package foo, if I want to install foo-1.2/bar/file1 to /usr/share/foo/bar file1, my install file woul have an entry like: bar/file1 usr/share/foo Or if you want to copy the directory foo-1.2/common-files to /usr/share/foo/common-files, you can add an entry like: common-files usr/share/foo etc. Read man dh_install for details. Also dh_installdocs, dh_installexamples and dh_installwhatever for more nie stuff. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Menu transition - status of doc-base?
On Tue, Sep 25, 2007 at 04:33:28PM +0200, Daniel Leidert wrote: Some weeks ago, the menu transition was announced. The doc-base system uses the sections defined in the menu policy for their own Section: field. But may I already use the new menu sections (Applications instead of Apps, ...) in .doc-base files? I checked the Wiki and the original thread about the transition but didn't find an answer to this question. My lintian 1.23.34 already complains for Apps etc. So, I guess you should use Applications/ Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Menu transition - status of doc-base?
On Tue, Sep 25, 2007 at 06:13:37PM +0200, Daniel Leidert wrote: Does it really complain about Apps in a doc-base file? The menu transition itself is already handled in lintian, but I cannot find a check for the section in doc-base files. I also cannot find any file in /usr/share/doc-base, that uses the new sections defined in the latest menu policy. I agree with you on this one. Only meny issues are flagged by lintian, and I am not aware of doc-base files. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: debian/watch, sf.net and -dev versions
On Fri, Sep 21, 2007 at 01:37:33PM +0200, Patrick Schoenfeld wrote: version=3 http://sf.net/package/package-(.*)\.tar\.gz Then it will report every development version as a newer version, which is wrong. On the sourceforges projet site this files are divided into different packages, on called package and one package-dev. Is there any way to handle this properly? I currently think of changing the regex to contain a fixed version part (1.4.*), but that would break as soon as upstream decides to release a stable 1.5. Anny ideas? If you are sure that they use only dots and numbers, you may wish to use ([\d\.]+) instead of (.*) for versioning. Could you please tell us the package you are interested in, if this doesn't help? Thanks! Kumar P.S. [OT] For sf.net, if you want a standard directory listing instead of using the watch sf.net workaround, try http://heanet.dl.sourceforge.net/sourceforge/package, for example: http://heanet.dl.sourceforge.net/sourceforge/maxima/ -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: debian/watch, sf.net and -dev versions
On Fri, Sep 21, 2007 at 02:06:48PM +0200, Patrick Schoenfeld wrote: How would that help me? This would match digits and points as part of the version instead of everything and so it would also consider 1.5.x to be newer then 1.4.x. Which is right, if one just compares version numbers to each other. But then again I do package only stable versions of the software, so I don't mind those -dev versions. Ehm. To make it more clearer. The package name has the same scheme: Use uversionmangle to substitute (.*)-dev to some junk value, like zero. It may be inelegant, but should work. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libj2ssh-java
On Thu, Sep 06, 2007 at 09:40:25AM +0200, Michael Koch wrote: Your package is very good. Thanks for your work. Just one nit. Please put the javadocs and examples into an extra -doc package. I think the size of them warrents an extra package. And please make the normal package suggest the -doc package. We shall get down to this this evening. I have two questions: 1. Could you please consider adding kumanna-guest and varun-guest to pkg-java? I have already mailed there in this regard. 2. Could I mail you in off-list, when I upload the revised package? Thanks a lot! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Help with -dbg packages for a library
On Fri, Aug 31, 2007 at 10:57:55AM -0400, Justin Pryzby wrote: So I think there should be no performance difference between running with the libraries compiled without -g, compiled with -g, compiled with -g and stripped, and compiled with -g and debug symbols/sections moved to a separate file. Thanks for the detailed explanation. It would be neat if you could compare the ELF files using binutils tools. I didn't do that, but ran some tests myself (it's a mathematical library), and concluded that there's little to chose from between -g + stripping and no debug+no stripping. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
RFS: libj2ssh-java
(CC'ed to Debian Mentors). Dear Mentors, Myself and a friend have managed to package libj2ssh-java. http://mentors.debian.net/debian/pool/main/l/libj2ssh-java/libj2ssh-java_0.2.9-1.dsc Description: a Java library for the SSH protocol J2SSH is an object-orientated Java library implementation of the SSH version 2 protocol. It provides a rich, powerful, and extensible SSH API that enables developers to gain access to SSH servers and to develop entire SSH client/server frameworks. The API library provides a fully-featured SSH2 implementation specifically designed for cross-platform development. Higher level components, representing both the standard SSH client and SSH servers, are provided which implement the protocol specification for user sessions and port forwarding. The specification currently supports public key and password authentication and a full implementation of the SFTP protocol. . Homepage: http://sshtools.sourceforge.net The primary reason why we wish to see this package in Debian is because this is a dependency for JFTP, which has a long pending RFP. Needless to say, the packages build cleanly with pbuilder, and are Lintian clean. Please get back to us with suggestions. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Help with -dbg packages for a library
Dear Debian Mentors, I have a specific question with regard to -dbg packages for libraries. My understanding of generating -dbg libraries is like this: 1. We build the package with CFLAGS or CXXFLAGS = -g -O2 (for optimization). 2. We call dh_strip while exluding the dbg package, to ensure that debugging sumbols are present there. Now, my situation is that upstream generates special pkg_debug packages by sending ./configure --enable-debug. While I achieve the desired result with the CFLAGS mentioned above, upstream fears that generating the library with debugging symbols first and then stripping them may result in a slightly reduced performance (it's a numerical computation library). While I am going to run some tests myself to verify this, I just wanted to ask the mentors here about their knowledge of this issue. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Help with a debian/watch file (getting tarball via websvn)
On Mon, Aug 27, 2007 at 03:24:58AM +0200, Daniel Leidert wrote: Hi, I could need some help with a debian/watch file :) In this special case I would like to create a debian/watch file for molekel (http://bioinformatics.org/molekel). Unfortunately upstream doesn't provide tarballs. So I thought about the possibility to check the path via the websvn interface: http://bioinformatics.org/websvn/listing.php?repname=molekelpath=%2Ftags%2Frev=0sc=0 With this watch file: version=3 http://bioinformatics.org/websvn/listing.php?repname=molekelpath=%2Ftags%2Frev=0sc=0 listing.php\?repname=molekel\amp;path=%2Ftags%2F([\d\.]+)%2F\amp;rev=0\amp;sc=0 This command: uscan --no-conf --watchfile watch --force-download --package molekel --upstream-version 0 does this: molekel: Version (5.2.0) available on remote site: http://bioinformatics.org/websvn/listing.php?repname=molekelpath=%2Ftags%2F5.2.0%2Frev=0sc=0 (local version is 0) So, just add a debian script line to the second watchfile line to move your src.tar.gz to molekel_VER.orig.tar.gz. See the uscan man page for this. (I am having trouble with the net connection, so can't probe further). HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: logapp
Dear Mentors, I would request you to have a look at logapp. http://mentors.debian.net/debian/pool/main/l/logapp/logapp_0.7-1.dsc License: GPL Description: supervise execution of applications producing heavy output Logapp is a wrapper utility that helps supervise the execution of applications that produce heavy console output (e.g. make, CVS, and Subversion). It does this by logging, trimming, and coloring each line of the output before displaying it. It can be called instead of the executable that should be monitored; it then starts the application and logs all of its console output to a file. The output shown in the terminal is preprocessed, e.g. to limit the length of printed lines and to show the stderr output in a different color. It is also possible to automatically highlight lines that match a certain regular expression. The output is therefore reduced to the necessary amount, and all important lines are easy to identify. . Homepage: http://logapp.sourceforge.net/ Note that this package does not have anything to do with GNUstep, though it ends with app. :-) Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: logapp
On Thu, Aug 16, 2007 at 11:47:22AM +0200, Mario Iseli wrote: Good morning *wave* Hey, time zone difference! ;-) debian/changelog: * Fix man page hyphens That's quite bad. Write something like: * Added patches/0?_BlaBla.dpatch to fix hyphens in manpages Well, I think I was getting _too_ concise! Please also update the date in your changelog entry everytime you change something on it... Some emacs magic missing after an upgrade! Anyway, I have corrected this using dch -e. debian/control: (e.g. make, CVS, and Subversion) I don't know how this exactly works in english, but in German it's quite forbidden to use a colon before and. It's like this: If my understanding is correct, American English permits a comma before and, while British English doesn't. Since I prefer Indian (closer to British) English, I make this change. Someone can correct me if I am wrong. debian/copyright: - It was downloaded from http://logapp.sourceforge.net/ + It was downloaded from http://logapp.sourceforge.net/ Done. Please also remove those useless whitespaces at the and of the lines. Done. debian/examples: Quite complicated to use a whole file just for one file, you could also do that with a dh_installexamples parameter. But yes, it works also so it's okay, just as a hint... debian/manpages: Same here... ;) Well, I just thought it was a good practice. But, I have now added these things to rules and removed the separate files. debian/rules: Again two useless whitespaces behind the dh_clean lines... Done. Regards and thanks for your work, Thanks for your quick review! :-) I have uploaded an updated copy, and have addedthe package to sponsors.d.net. Thanks again! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: logapp
On Thu, Aug 16, 2007 at 01:06:48PM +0200, martin f krafft wrote: Write something like: * Added patches/0?_BlaBla.dpatch to fix hyphens in manpages It's still pretty bad. Since the changelog is for users, it should also contain what actually got changed without reference to a patch. Were the hyphens broken? What's a broken hyphen? OK, so it now reads: Added 01manpage_hyphen_fix.dpatch to ensure hyphens aren't used as minus signs. I think it can't be more clear than that! It's correct to use a comma before and even in British English. Well, I am not changing this. debian/copyright: - It was downloaded from http://logapp.sourceforge.net/ + It was downloaded from http://logapp.sourceforge.net/ Rationale? Sponsoring isn't really about making sure your preferences are honoured. Reverting to the one without , since the URL is highlighted incorrectly in Emacs if I have the trailing . :-) debian/examples: Quite complicated to use a whole file just for one file, you could also do that with a dh_installexamples parameter. But yes, it works also so it's okay, just as a hint... It's really the way debhelper was designed and is much easier and more transparent for NMUs etc. IMHO. Well, in this case, I really feel it's all right, since the package is, as such, quite small. But I also like the separate file way for the reason that if upstream adds another file later, I just append it there rather than look for it in rules... Anyway, the latest one is available at: http://mentors.debian.net/debian/pool/main/l/logapp/logapp_0.7-1.dsc Thanks for the tips, Martin! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: logapp
On Thu, Aug 16, 2007 at 02:20:09PM +0200, Mario Iseli wrote: My education was: Every difference from the dh_make templates are bad, except if you have good reasons for it. But hmm, ok... I agree, but I thought url://... was a placeholder meant to be replaced with just the URL. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
RFS: flickcurl
Dear Debian Mentors, I would request a mentor to have a look at the following package and consider sponsoring it: http://mentors.debian.net/debian/pool/main/f/flickcurl/flickcurl_0.11-1.dsc It builds the following packages: flickcurl - call Flickr API from command line flickrdf - generate RDF triples from a Flickr photo libflickcurl-dev - C library for accessing the Flickr API - development files libflickcurl0 - C library for accessing the Flickr API libflickcurl0-dbg - C library for accessing the Flickr API From my ITP (bug #436065): Package name: flickcurl Version : 0.11 Upstream Author : Dave Beckett * URL : http://librdf.org/flickcurl/ * License : LGPL 2.1 / GPL 2 /Apache 2.0 (I have chosen GPL) Programming Lang: C Description : C library for the Flickr API Flickcurl is a C library for the Flickr API, handling creating the requests, signing, token management, calling the API, marshalling request parameters and decoding responses. It uses libcurl to call the REST web service and libxml2 to manipulate the XML responses. The current version supports part of the API, primarily the functions for reading photo, people and tags description, uploading photos, changing tags and comments. Thanks in advance. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: flickcurl
Dear Mario, First of all, thanks for the quick review. On Sun, Aug 05, 2007 at 06:43:50PM +0200, Mario Iseli wrote: debian/control: Well done, really... :) Well, I must thank the last mentor who guided me through a library process (Neil codehelp Williams). So, this was pretty all right. debian/copyright: You have some useless whitespaces mostly at the end of the lines. Then ehm: License: LGPL 2.1 / GPL 2 / Apache 2.0 What should that mean? If you have several licenses in your package you have to list which files and which author did what, for example have a look at http://packages.debian.org/changelogs/pool/main/m/mcabber/mcabber_0.9.3-1/mcabber.copyright how to do that. You really have to go through all the source files and add every single copyright to this file, that's important. OK, so here's the deal. The author gives you the option of choosing from among GPL 2+, LGPL 2.1 or the Apache license. And, I *have* checked every file. For example, see this: find |egrep \.(h|c)$|xargs grep (GPL) Compare that to find|egrep \.(h|c)$. That shows that example.c (which is an example) and flickcurl_getopt.h may not be GPL'd. So, I have mentioned flickcurl_getopt.h as being public domain, and all other files as GPL. And since the COPYING file is included, I am going ahead with the assumption that it is GPL'd. Besides, it'd be a pity if a 50 line C example program is discarded! debian/flickcurl.1: Nice manpage, but please remove the comment lines at the beginning since they are from the template and not used. Done. debian/flickcurl-config.1: Well done again... Thanks. debian/flickcurl.manpages: - ./debian/flickcurl.1 + debian/flickcurl.1 OK. Done. debian/flickrdf.docs: Useless empty line at the end of the file. Removed. debian/rules: Also some useless whitespaces at the end of the line, if you use vim please add the following to your vimrc and then you will see what i mean: syntax on highlight WhitespaceEOL ctermbg=red guibg=red match WhitespaceEOL /\s\+$/ I think I've done it right now. debian/watch: Well done :) Thanks! So, hmm yes, I'm generally interested to sponsor your package, please register it on sponsors.debian.net, I use that to track my sponsoring and get in contact with me if you have fixed the things from above. Well, thanks a lot! I have registered the package on Sponsors.d.net. Please check it out, and many thanks for the review and upload offer! :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: flickcurl
On Sun, Aug 05, 2007 at 11:08:49PM +0530, Kumar Appaiah wrote: debian/copyright: You have some useless whitespaces mostly at the end of the lines. Then ehm: License: LGPL 2.1 / GPL 2 / Apache 2.0 What should that mean? If you have several licenses in your package you have to list which files and which author did what, for example have a look at http://packages.debian.org/changelogs/pool/main/m/mcabber/mcabber_0.9.3-1/mcabber.copyright how to do that. You really have to go through all the source files and add every single copyright to this file, that's important. OK, so here's the deal. The author gives you the option of choosing from among GPL 2+, LGPL 2.1 or the Apache license. And, I *have* checked every file. For example, see this: find |egrep \.(h|c)$|xargs grep (GPL) Oops! One more miss! getopt.c is also public domain! find |egrep \.(h|c)$|xargs grep -L (GPL) gives getopt.c, flickcurl_getopt.h and example.c I am reuploading with the modification in the copyright file. Sorry. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: flickcurl
On Sun, Aug 05, 2007 at 11:16:12PM +0530, Kumar Appaiah wrote: Oops! One more miss! getopt.c is also public domain! find |egrep \.(h|c)$|xargs grep -L (GPL) gives getopt.c, flickcurl_getopt.h and example.c I am reuploading with the modification in the copyright file. Sorry. Done! Copyright now reads this copyright License for flickcurl_getopt.h and getopt.c: Public domain License for all other files: gpl-stuff/ /copyright And uploaded to mentors. Hope it's OK now. http://mentors.debian.net/debian/pool/main/f/flickcurl/flickcurl_0.11-1.dsc Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Sponsor Checklist
On Tue, Jul 31, 2007 at 07:53:24AM +0100, Neil Williams wrote: Sponsors who upload packages that result in more than a fair share of RC bugs are not looked upon favourably by the release team or other parts of Debian. (This is why I do not sponsor PHP packages, despite using PHP extensively myself.) ;-) Double standards! :-) Maintaining packages in Debian *is tough* for people who have no upstream experience or knowledge simply because they are dependent on others to fix certain bugs. It is easier for Debian *and* for upstream if the Debian maintainer has detailed knowledge of the upstream code because bug reports can include working patches. One example is architecture-specific bugs - upstream have no real way of fixing bugs that only appear on some of the supported Debian architectures because they don't have access to the hardware. If the Debian maintainer has insufficient knowledge of the upstream code to fix problems specific to Debian, these kind of bugs tend to escalate in severity until either someone else has to do an NMU or the package is removed from testing. I understand. As you say, the quality of the package in Debian is also a function of the maintainer's familiarity with the package. Thanks for the clarifications! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Creating /usr/bin/ entries to scripts the right way
On Mon, Jul 30, 2007 at 11:27:35AM +0530, Kumar Appaiah wrote: echo -e #!/bin/sh\nexec /usr/bin/python2.4 \ /usr/lib/python2.4/site-packages/HarvestMan/harvestman.py \[EMAIL PROTECTED] harvestman OK, so it's actually this: echo -e #!/bin/sh\nexec /usr/bin/python2.4 \ /usr/lib/python2.4/site-packages/HarvestMan/harvestman.py \[EMAIL PROTECTED] ./debian/harvestman/usr/bin/harvestman Thanks a lot! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
RFS: harvestman (updated package)
Dear Debian Mentors, I am looking for a sponsor for harvestman. It is a Python based package already in Debian. The current package fixes a minor bug and clears up some Python packaging issues. Also, it now uses a script in /usr/bin, rather than a symbolic link, like earlier packages. Otherwise, there isn't much change. The package is at: http://mentors.debian.net/debian/pool/main/h/harvestman/harvestman_1.4.6-4.dsc I'd appreciate it if someone could sponsor the package. Please do send me your comments and queries, if you have any. Thanks. Kumar P. S.: You may be wondering what has suddenly rekindled my interest in the package. It's just that upstream is developing a new version, and I wanted to see what shape the package is in well before the next upstream release. -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: harvestman (updated package)
On Mon, Jul 30, 2007 at 01:56:09PM +0200, Piotr Ozarowski wrote: * please add python-xml to Depends (HarvestMan/xmlparser.py, line 2) Done, although it was working for me without python-xml. * XS-Vcs-* fields are for debian changes, not upstream's Removed. * debian/harvestman.1 - escape hyphen (\-) in line 116, 122, 126, 890, 921 Done. Since a version bump is not necessary, please find the updated package here: dget -x http://mentors.debian.net/debian/pool/main/h/harvestman/harvestman_1.4.6-4.dsc And thanks a lot for the quick response and suggestions. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: harvestman (updated package) - uploaded
On Mon, Jul 30, 2007 at 04:13:18PM +0200, Piotr Ozarowski wrote: thanks Thanks from me too! :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: harvestman (updated package)
On Mon, Jul 30, 2007 at 04:17:07PM +0200, Adeodato Simó wrote: On Mon, Jul 30, 2007 at 01:56:09PM +0200, Piotr Ozarowski wrote: * please add python-xml to Depends (HarvestMan/xmlparser.py, line 2) Done, although it was working for me without python-xml. Because Python itself provides a XML implementation, in this case /usr/lib/python2.4/xml/parsers/expat.py. That I realized after a relook. I guess performance is the criterion for this choice, after reading up a bit. Thanks for the suggestion! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: harvestman (updated package)
On Mon, Jul 30, 2007 at 04:29:47PM +0200, Piotr Ozarowski wrote: oh, right, python provides DOM (and SAX since python2.4, IIRC), I forgot about this - sorry, Kumar It's quite all right. But for my TODO list, should the dependency be there for the next release or should it be removed? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Sponsor Checklist
Dear Don, Though I am not a sponsor, I'm a sponsoree, and have the following questions. On Mon, Jul 30, 2007 at 11:48:16AM -0700, Don Armstrong wrote: Determine if the maintainer can actually maintain the package * What is the skill level of the maintainer? * Are they familiar with the package and its languages? * How active are they? * Do they have existing packages? * How do they interact with users? [Check out their existing bugs.] I wish to know how you can evaluate skill level. For example, if ative contribution to a FOSS project is a required skill, I really won't fit in. But if it is just knowledge of issues with the package and packaging techniques, that's all right. Of course, I realize that it's my responsibilities to get bugs fixed as well. For example, though I use python on a regular basis for small scripts for getting things done (mostly like shell script replacements, procmail mini-filters etc.), I haven't written any big application using python. However, my Python packages do build well and I am aware of the issues that concern them, such as pycentral, correcting the #!... for non-executable scripts etc. So, how do you propose to evaluate people? Though evaluation is necessary, isn't it tough for people who don't really have a FOSS contributor background? Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Sponsor Checklist
On Mon, Jul 30, 2007 at 06:59:30PM -0700, Don Armstrong wrote: The point isn't really to exclude prospective maintainers, but to make sure that the sponsor has a rough idea of how much time and effort it's going to take to help the maintainer keep the package in a state that's appropriate for Debian, and only sponsor packages where they can actually expend that time and effort. I appreciate this point. Another point I wish to make, to add to what Manoj has already said, is that sponsors _may_ wish to insist that the uploaded packages be pdebuilt, just to be sure that the packages are build on a clean, sid chroot. Thanks a lot! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
RFS: elfrc
Dear Debian Mentors, I'd appreciate it if someone could have a look at elfrc, at: dget http://mentors.debian.net/debian/pool/main/e/elfrc/elfrc_0.7-1.dsc Upstream: http://ktown.kde.org/~frerich/elfrc.html License: BSD Description: program to convert arbitrary files into elf objects elfrc is a program which can turn arbitrary files into ELF object files which can then be linked into your program directly and accessed via simple, user-defined symbol names. . For instance, it's possible to embed even huge (16MB+) files directly into the executable and then access the data in constant time without making the compiler or linker eat loads of memory. Please do send me your comments, if you find something lacking. I shall make the corrections and make a new upload later. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Sponsor Checklist
On Mon, Jul 30, 2007 at 09:40:26PM -0500, Manoj Srivastava wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. Therefore I actually am only insistent on the sources being available, since I usually discard the pre-build .debs anyway. True, but I thought that if the maintainer discovers the problems himself, it'd just save time for the sponsor. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: kplayer
On Sun, Jul 29, 2007 at 02:54:34PM -0500, Richard A. Johnson wrote: Dear mentors, I am looking for a sponsor for my package kplayer. kplayer- KDE multimedia player frontend for MPlayer What about this: shell [EMAIL PROTECTED] apt-cache show kmplayer Package: kmplayer Priority: optional Section: kde Installed-Size: 2312 Maintainer: Debian KDE Extras Team [EMAIL PROTECTED] Architecture: i386 Version: 1:0.9.4a-2 [snip] Description: media player for KDE KMPlayer is a simple frontend for MPlayer/Xine/ffmpeg/ffserver/VDR. [snip] /shell Is it different? Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Creating /usr/bin/ entries to scripts the right way
Dear Debian Mentors, While working on a Python command-line application (harvestman, which is already in Debian), I have the necessity to create a /usr/bin entry. Now, creating a symbolic link to the actual executable in /usr/lib/python2.4/... is what the provided installer does. But I want to replace it with this: #!/bin/sh exec /usr/bin/python /usr/lib/`pyversions \ -d`/site-packages/HarvestMan/harvestman.py $@ Now, this is find and great. But _how_ do I put this in my package? Do I put it as harvestman.exec in my package's ./debian/ directory and then copy it and set the permissions for it using install? Or is there a more elegant way of getting over this? Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: kplayer
On Sun, Jul 29, 2007 at 11:44:46PM -0500, Richard A. Johnson wrote: Yes it is. Granted they are similar, KPlayer is a bit more advanced with extra features. One of my favorite features is how it can either be compact or it [snip] Right! I just wanted to be sure (I am _not_ playing spoilsport), so it's great that you have packaged it. All the best in finding a sponsor! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Creating /usr/bin/ entries to scripts the right way
On Mon, Jul 30, 2007 at 07:19:20AM +0200, Bart Martens wrote: If the source package contains debian/bin/harvestman then debian/install can contain this line: debian/bin/harvestman usr/bin/ Unfortunately, the source package does not contain such a file. It merely creates a symbolic link, if I run a wrapper installer they provide, and I don't do that. Or should I just create such a file of that type using dpatch? That way, I keep the diff clean. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Creating /usr/bin/ entries to scripts the right way
On Mon, Jul 30, 2007 at 07:39:59AM +0200, Mike Hommey wrote: This is just the fine way. Or, for 2 lines, you can directly write them in debian/rules. BTW, I would recommend you to, and to hard code the python version in the script provided by the package instead of using pyversions at runtime : if your package is built for python 2.4 and 2.5, and is installed when python 2.6 becomes default, it will stop working. That's a good point. But I would like you to elaborate on this. 1. How do I put this in rules? Will this be OK: echo -e #!/bin/sh\nexec /usr/bin/python2.4 \ /usr/lib/python2.4/site-packages/HarvestMan/harvestman.py \[EMAIL PROTECTED] harvestman (It seems to dump the required thing!). 2. As you see, in the above string, I have hard coded python2.4. I guess, when Python 2.5 becomes current, I just make another upload with Python 2.5 as current. Is that correct? Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
RFS: pkpgcounter
(Cross posted to debian-mentors and debian-python) Dear Debian Mentors, I have packaged pkpgcounter, whose description reads this: Language: Python License: GPL description pkpgcounter is a generic Page Description Language parser which can either count the number of pages or compute the percent of ink coverage needed to print various types of documents. It is written in Python. . It currently recognizes the following file formats : . * PostScript (both DSC compliant and binary) * PDF * PCL3/4/5 * (And some more) . Homepage: http://www.pykota.com/software/pkpgcounter /description I was wondering if someone would be interested in packaging it. It is available at: http://mentors.debian.net/debian/pool/main/p/pkpgcounter/pkpgcounter_2.18-1.dsc It's lintian clean (I guess :-), but if you have suggestions for improving or correcting the package, please do tell me. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: pkpgcounter
On Sat, Jul 28, 2007 at 10:31:16PM +0200, Christoph Haas wrote: Sponsored. Thanks a lot, Christoph! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: List of (un)sponsored packages on Mentors (approximate)
On Thu, Jul 26, 2007 at 07:50:49PM +1000, Paul TBBle Hampson wrote: Your title= tagging has unfortunately barfed on my name, due to the TBBle in it causing the quoted string to terminate early. Well, I don't think this page is necessary anymore, since better options to check this are available (courtesy this thread). So, don't bother too much; that page is going away in a while! :-) Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: List of (un)sponsored packages on Mentors (approximate)
On Thu, Jul 26, 2007 at 03:04:31PM -0500, Raphael Geissert wrote: I've made some changes to your script in order to improve it's results. The modified script can be downloaded from here: http://files.myopera.com/atomo64/files/mentors_comp.py and the results generated by the modified script: http://files.myopera.com/atomo64/files/output.test.html Very nice! Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
