RFS: libpam-alreadyloggedin
Dear mentors, I am looking for a sponsor for my package "libpam-alreadyloggedin". * Package name: libpam-alreadyloggedin Version : 0.3-1 Upstream Author : Ilya Evseev * URL : http://ilya-evseev.narod.ru/posix/pam_alreadyloggedin/ * License : BSD Section : admin It builds these binary packages: libpam-alreadyloggedin - PAM module to skip password authentication for logged users The package appears to be lintian clean. The upload would fix these bugs: 520108 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libpam-alreadyloggedin - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libpam-alreadyloggedin/libpam-alreadyloggedin_0.3-1.dsc I would be glad if someone uploaded this package for me. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: ampache-themes (updated package)
Dear mentors, I am looking for a sponsor for the new version 3.4.3-1 of my package "ampache-themes". It builds these binary packages: ampache-themes - Themes for Ampache The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/ampache-themes - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ampache-themes/ampache-themes_3.4.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman signature.asc Description: This is a digitally signed message part
Re: RFS: libpam-alreadyloggedin
Hi Jakub (I'm not a DD) On Tue, May 12, 2009 at 09:11:15AM +0200, Jakub Wilk wrote: > Dear mentors, > > I am looking for a sponsor for my package "libpam-alreadyloggedin". > > * Package name: libpam-alreadyloggedin > Version : 0.3-1 > Upstream Author : Ilya Evseev > * URL : http://ilya-evseev.narod.ru/posix/pam_alreadyloggedin/ > * License : BSD > Section : admin > > It builds these binary packages: > libpam-alreadyloggedin - PAM module to skip password authentication for > logged users > > The package appears to be lintian clean. Only a short note on that, the source package fails to build in a clean pbuilder environment with: make[1]: Entering directory `/tmp/buildd/libpam-alreadyloggedin-0.3' gcc -c -g -O2 -Wall -fPIC -DLINUX_PAM -I. -DBUG_STAT_MISSING pam_alreadyloggedin.c pam_alreadyloggedin.c:70:31: error: security/pam_appl.h: No such file or directory pam_alreadyloggedin.c:71:34: error: security/pam_modules.h: No such file or directory pam_alreadyloggedin.c:72:31: error: security/pam_misc.h: No such file or directory pam_alreadyloggedin.c:151: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int' pam_alreadyloggedin.c:206: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int' make[1]: *** [pam_alreadyloggedin.o] Error 1 make[1]: Leaving directory `/tmp/buildd/libpam-alreadyloggedin-0.3' dh_auto_build: make returned exit code 2 make: *** [build-stamp] Error 1 There seems to be a missing Build dependency on at least libpam0g-dev. Hope that helps Bests Salvatore signature.asc Description: Digital signature
RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
Dear mentors, I am looking for a sponsor for my package "cconv". * Package name: cconv Version : 0.5.2-1 Upstream Author : 杨建禹 * URL : http://code.google.com/p/cconv/ * License : GPLv2 Section : text It builds these binary packages: cconv - iconv based simplified-traditional chinese conversion tool cconv-dev - iconv based simplified-traditional chinese conversion tool (development files) This tool is useful to convert all existing Chinese WML files for the Debian website from Big5 to UTF-8. Examples: $ echo "内存，海内存知已，後天，皇后" | cconv -f utf-8 -t utf8-tw 記憶體，海內存知已，後天，皇后 The package appears to be lintian clean. The upload would fix these bugs: 528319. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cconv - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cconv/cconv_0.5.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Vern 2009-05-12 signature.asc Description: Digital signature
Re: RFS: ninja (updated package)
Hello On Sat, May 9, 2009 at 1:44 AM, Mauro Lizaur wrote: > On Sat, 09 May 2009, William Vera wrote: > >> Dear mentors, >> >> I am looking for a sponsor for the new version 0.1.2-3 >> of my package "ninja". >> >> It builds these binary packages: >> ninja - Privilege escalation detection system for GNU/Linux >> >> The package appears to be lintian clean. >> >> The upload would fix these bugs: 515174 >> > > Hi there, > IANADD, but I'm curious about the debian/copyright file: >> This package was debianized by William Vera on >> Wed, 31 Aug 2005 20:03:34 -0500. > > while on debian/changelog: >>ninja (0.1.2-1) unstable; urgency=low >> >> * Initial release (Closes: #325824) >> >> -- William Vera Wed, 04 Jul 2007 21:41:21 -0500 > > There are leap of 2 years, i'm not saying it's wrong but it looks weird > to me. Yes, you are right, is weird, I corrected that :) thanks. > Also, seems like you're missing the copyright part of your package at the > end of the file, I mean something like: > The Debian packaging is © 1900 - 2012, John Doe and > is licensed under the GPL, see `/usr/share/common-licenses/GPL'. > What file? the copyright file has the correct structure (I think) Thanks for your comments Regards > > Regards, > Mauro > > -- > JID: lavaram...@jabber.org | http://lusers.com.ar/ > 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- William Vera PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: libpam-alreadyloggedin
* Salvatore Bonaccorso , 2009-05-12, 09:53: I am looking for a sponsor for my package "libpam-alreadyloggedin". * Package name: libpam-alreadyloggedin Version : 0.3-1 Upstream Author : Ilya Evseev * URL : http://ilya-evseev.narod.ru/posix/pam_alreadyloggedin/ * License : BSD Section : admin It builds these binary packages: libpam-alreadyloggedin - PAM module to skip password authentication for logged users The package appears to be lintian clean. Only a short note on that, the source package fails to build in a clean pbuilder Ooops, I should have checked that. I've just uploaded a new version that compiles cleanly. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: include desktop file and icon
On Mon, May 11, 2009 at 05:49:02PM +0200, Grammostola Rosea wrote: > Paul Wise wrote: > > On Mon, May 11, 2009 at 5:40 PM, Grammostola Rosea > > wrote: > > > > > >>> my install file looks like: > >>> > >>> phasex-0.11.1/phasex.desktop usr/share/applications > >>> phasex-0.11.1/pixmaps/* usr/share/pixmaps > >>> > >>> > >>> > >> Comments, suggestions to solve this? > >> > > > > phasex.desktop usr/share/applications > > pixmaps/* usr/share/pixmaps > > > > > thanks > > lintian says: > P: phasex source: direct-changes-in-diff-but-no-patch-system > misc/phasex.desktop and 1 more Sigh. And what does "lintian -i" say about that? And what does that actually *mean*? And do you want to use a patch system? And if you do, why not use one? And if there are really good reasons why you don't want to use a patch system, then you can ignore this warning - but only after you've come to understand what it means and why it is there. And understanding what it means and why it is there is usually - and in this case, too - as simple as *reading* the output of "lintian -i", thinking about it a bit, then reading what people with similar issues have said and done on the -mentors list, and sometimes examining a couple of packages that are already in Debian to see how they deal with it. In this particular case, just reading the additional information that Lintian displays ought to be enough to understand it :) Erm... I hope this doesn't seem harsh; it isn't meant to be. Just a piece of well-meant advice that has helped me deal with lintian warnings and other packaging problems in the past year or two :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn't! pgpSWcvd3PiQH.pgp Description: PGP signature
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
Hi Dne Tue, 12 May 2009 16:21:32 +0800 Vern Sun napsal(a): > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/c/cconv > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget http://mentors.debian.net/debian/pool/main/c/cconv/cconv_0.5.2-1.dsc - you might want to use debhelper 7 features (dh) to simplify debian/rules, your package seems to be good candidate to this - lintian slightly complains: P: cconv-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: cconv: copyright-refers-to-symlink-license usr/share/common-licenses/GPL I: cconv: extended-description-is-probably-too-short - any reason why library is placed in /usr/lib/cconv? - you should split the library to libcconv0 and rename devel package to libcconv-dev - please write useful description, pointing user to url is not a useful description - you need to list all copyrights and licenses in debian/copyright - Vcs-* fields are for debian packaging not for upstream - -dev package is not a metapackage - cconv man page is obviously generated, you should include it's sources and generate it during build - README.Debian is useless - why do you install empty file NEWS? -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: include desktop file and icon
Peter Pentchev wrote: On Mon, May 11, 2009 at 05:49:02PM +0200, Grammostola Rosea wrote: Paul Wise wrote: On Mon, May 11, 2009 at 5:40 PM, Grammostola Rosea wrote: my install file looks like: phasex-0.11.1/phasex.desktop usr/share/applications phasex-0.11.1/pixmaps/* usr/share/pixmaps Comments, suggestions to solve this? phasex.desktop usr/share/applications pixmaps/* usr/share/pixmaps thanks lintian says: P: phasex source: direct-changes-in-diff-but-no-patch-system misc/phasex.desktop and 1 more Sigh. And what does "lintian -i" say about that? And what does that actually *mean*? And do you want to use a patch system? And if you do, why not use one? And if there are really good reasons why you don't want to use a patch system, then you can ignore this warning - but only after you've come to understand what it means and why it is there. And understanding what it means and why it is there is usually - and in this case, too - as simple as *reading* the output of "lintian -i", thinking about it a bit, then reading what people with similar issues have said and done on the -mentors list, and sometimes examining a couple of packages that are already in Debian to see how they deal with it. In this particular case, just reading the additional information that Lintian displays ought to be enough to understand it :) Erm... I hope this doesn't seem harsh; it isn't meant to be. Just a piece of well-meant advice that has helped me deal with lintian warnings and other packaging problems in the past year or two :) Thanks, I understand your point. But I can't understand all those messages yet and I'm not gonna read hundreds of difficult to read manual pages with at least 200 pages each.. I hope this doesn't seem harsh ;) But in my experience, it works the best at start to ask experienced people and learn bit by bit how things work. At first the manpages are mostly 'acadabra' but picking up some bits from others will help you to be able to quickly understand the more sophisticated issues. In my experience, when people tell me how to do it and I succeeded once, I don't have to ask it again how it works (like the install file thing). After a while I see other people do things different and then I can ask and investigate why... If you want to read all the different things at start at once, packaging for Debian will cost you a fulltime job and that would in many cases not be good. I think the help is good on this list. thanks for that. But I don't think 'read the manpages of that, that and that package' is a very productive way to learn things. It's like reading all the manuals for the electric apparatus in your house... you wouldn't have time to work on Debian if you did that... Kind regards, \r -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: include desktop file and icon
On Tue, May 12, 2009 at 11:08:29AM +0200, Grammostola Rosea wrote: > Peter Pentchev wrote: > > On Mon, May 11, 2009 at 05:49:02PM +0200, Grammostola Rosea wrote: [snip] > >> lintian says: > >> P: phasex source: direct-changes-in-diff-but-no-patch-system > >> misc/phasex.desktop and 1 more > >> > > > > Sigh. And what does "lintian -i" say about that? And what > > does that actually *mean*? And do you want to use a patch system? > > And if you do, why not use one? And if there are really good > > reasons why you don't want to use a patch system, then you can > > ignore this warning - but only after you've come to understand > > what it means and why it is there. > > > > And understanding what it means and why it is there is usually - > > and in this case, too - as simple as *reading* the output of > > "lintian -i", thinking about it a bit, then reading what people > > with similar issues have said and done on the -mentors list, > > and sometimes examining a couple of packages that are already in > > Debian to see how they deal with it. > > > > In this particular case, just reading the additional information > > that Lintian displays ought to be enough to understand it :) > > > > Erm... I hope this doesn't seem harsh; it isn't meant to be. > > Just a piece of well-meant advice that has helped me deal with > > lintian warnings and other packaging problems in the past > > year or two :) > > > > > Thanks, I understand your point. > But I can't understand all those messages yet and I'm not gonna read > hundreds of difficult to read manual pages with at least 200 pages each.. > > I hope this doesn't seem harsh ;) But in my experience, it works the > best at start to ask experienced people and learn bit by bit how things > work. At first the manpages are mostly 'acadabra' but picking up some > bits from others will help you to be able to quickly understand the more > sophisticated issues. In my experience, when people tell me how to do it > and I succeeded once, I don't have to ask it again how it works (like > the install file thing). After a while I see other people do things > different and then I can ask and investigate why... > > If you want to read all the different things at start at once, packaging > for Debian will cost you a fulltime job and that would in many cases not > be good. > > I think the help is good on this list. thanks for that. But I don't > think 'read the manpages of that, that and that package' is a very > productive way to learn things. It's like reading all the manuals for > the electric apparatus in your house... you wouldn't have time to work > on Debian if you did that... Well... I think I should rather let others answer that - I'm not a DD, not applied even to DM yet (though I intend to do both soon), just a random volunteer who tries to help Debian every once in a while with a package or fifteen :) So maybe someone more authoritative could chime in here and give us an official opinion if needed :) Still, I'd just like to point out that none of what you describe was actually a problem for me a couple of years ago when I started. (Just for the record, it was not a full-time job back then, and it isn't now, although the truth is that part of my job *does* include making Debian packages of in-house software for Etch and Lenny). I read the Developer's Reference, I examined several packages to see how things were done, I ran "dh_make" with different options to see what it did... then I ran it once again and started working on lintian warnings (and errors, too, in my first packages). Working on them was really just "run lintian -i, read what it says, read the Policy section if one is mentioned, take a look at the manpage of the dh_* tool in question, change one line be done with it". Maybe it helped that I started using just plain debhelper from the start, and first dpatch, then quilt afterwards. IMHO, debhelper's manpages are written wonderfully - short, to the point, with plain and simple descriptions of what the tool does and what files it reads. And, of course, following the -mentors list helped a lot :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpHbJh6oMFos.pgp Description: PGP signature
RFS: scid (updated package)
Dear mentors, I am looking for a sponsor for the new version 3.7.3-1 of my package "scid". It builds these binary packages: scid - chess database with play and training functionality The package appears to be lintian clean. The upload would fix these bugs: 465788, 487771 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scid - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scid/scid_3.7.3-1.dsc I would be glad if someone uploaded this package for me. I have contacted the previous maintainer (see also #487771). He agreed that I may continue maintaining the package for Debian. Since the previous upload (aug-08) I have made massive changes in the build proces after some feedback from (Sandro Tosi). Kind regards W. van den Akker -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: scid (updated package)
Dear mentors, I am looking for a sponsor for the new version 3.7.3-1 of my package "scid". > It builds these binary packages: scid - chess database with play and training functionality The package appears to be lintian clean. The upload would fix these bugs: 465788, 487771 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scid - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scid/scid_3.7.3-1.dsc I would be glad if someone uploaded this package for me. I have contacted the previous maintainer (see also #487771). He agreed that I may continue maintaining the package for Debian. Since the previous upload (aug-08) I have made massive changes in the build proces after some feedback from (Sandro Tosi). Kind regards W. van den Akker -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
On Tue, May 12, 2009 at 4:21 PM, Vern Sun wrote: > cconv - iconv based simplified-traditional chinese conversion tool > cconv-dev - iconv based simplified-traditional chinese conversion tool > (development files) > > This tool is useful to convert all existing Chinese WML files for the Debian > website from Big5 to UTF-8. Examples: > $ echo "内存，海内存知已，後天，皇后" | cconv -f utf-8 -t utf8-tw > 記憶體，海內存知已，後天，皇后 Why isn't iconv capable of doing this? iconv --list contains Big5 here. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: include desktop file and icon
On Tue, 12 May 2009 11:08:29 +0200 Grammostola Rosea wrote: > > And understanding what it means and why it is there is usually - > > and in this case, too - as simple as *reading* the output of > > "lintian -i", thinking about it a bit, then reading what people > > with similar issues have said and done on the -mentors list, > > and sometimes examining a couple of packages that are already in > > Debian to see how they deal with it. > > > > In this particular case, just reading the additional information > > that Lintian displays ought to be enough to understand it :) Exactly. > But I can't understand all those messages yet and I'm not gonna read > hundreds of difficult to read manual pages with at least 200 pages each.. You do need to read all the existing documentation and that includes a lot more than just 200 pages. If there is a single manpage with more than 200 screens, by all means let us know but you are exaggerating the workload. Every maintainer has had to read all that documentation, every DD has to read (and update) a whole load more. It is part of the role and you do just have to read it and get to understand it. There are no shortcuts. You are going to have to read all the manpages - this list is not a substitute for reading the documentation. > I hope this doesn't seem harsh ;) But in my experience, it works the > best at start to ask experienced people and learn bit by bit how things > work. That only works when the questions are not those already answered in the manpages. The "experienced people" on this list are busy and have other tasks to do, you have to put in the effort at your end and show that you can do something to help yourself. Being a maintainer for a package means doing the work yourself and that work involves reading and understanding the documentation already provided. The list can help clarify issues or fix problems but you must understand the basic documentation and be willing to read up on the issues yourself. You have to put in the time. > At first the manpages are mostly 'acadabra' but picking up some > bits from others will help you to be able to quickly understand the more > sophisticated issues. In my experience, when people tell me how to do it > and I succeeded once, I don't have to ask it again how it works (like > the install file thing). After a while I see other people do things > different and then I can ask and investigate why... Yet with the install file, it took many answers before you understood it - how much of that was because you hadn't read the documentation or taken enough time to understand it first? Do test builds of packages, work out what works and what doesn't, download source packages, fiddle about and see what breaks then read the manpages to work out why it broke - you should be doing all of that yourself, in your own time and off your own initiative. How do you propose to fix bugs if you don't understand how to test packages, identify problems and read manpages to look up the correct solution? > If you want to read all the different things at start at once, packaging > for Debian will cost you a fulltime job and that would in many cases not > be good. You need to read and understand all the existing documentation - there is no getting away from that. It isn't a full time job, don't exaggerate it. Reading the documentation is not optional. Read the New Maintainer Guide, the Developer Reference and Policy. Read the manpages for debhelper commands. You initially had problems understanding what CDBS was doing, to solve that problem you need to fully understand the debhelper manpages - all of them. CDBS relies heavily on such understanding - if you don't use CDBS, you still have to understand all the debhelper commands that your package uses - there really is no escape from reading and understanding *all* the relevant manpages. If you genuinely have problems understanding the documentation, fine, build some test packages for that particular problem, look up packages that have probably already solved those issues and work out how they do it yourself. If you still have issues, then post to the list with information on the section at issue, what you've done to try and work out what is going on and what is going wrong. Using syntax like "debian/$package.install" is commonplace and you need to become familiar with such substitution patterns. You need to understand concepts like that to be able to debug the package as well as the packaging. > I think the help is good on this list. thanks for that. But I don't > think 'read the manpages of that, that and that package' is a very > productive way to learn things. Manpages and other documentation has to be the foundation of all things discussed on the list. Asking repeated questions that are already answered in the relevant manpage is just going to frustrate those trying to help you. After a while, people will simply stop helping you. > It's like reading all the manuals f
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
On Tue, May 12, 2009 at 18:12, Paul Wise wrote: > On Tue, May 12, 2009 at 4:21 PM, Vern Sun wrote: > >> cconv - iconv based simplified-traditional chinese conversion tool >> cconv-dev - iconv based simplified-traditional chinese conversion tool >> (development files) >> >> This tool is useful to convert all existing Chinese WML files for the Debian >> website from Big5 to UTF-8. Examples: >> $ echo "内存，海内存知已，後天，皇后" | cconv -f utf-8 -t utf8-tw >> �w，海�却嬷�已，後天，皇后 > > Why isn't iconv capable of doing this? iconv --list contains Big5 here. > iconv can't cover this. It sounds like an automatic translation instead of changing encoding. i don't know how to explain this, but if you lived in Chinese culture, you should know it's true. zh-autoconvert has a similar function like this program. wikipedia page: http://en.wikipedia.org/wiki/Traditional_Chinese_characters http://en.wikipedia.org/wiki/Simplified_Chinese_characters -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: include desktop file and icon
On Tue, May 12, 2009 at 12:43:21PM +0300, Peter Pentchev wrote: [snip] > Well... I think I should rather let others answer that - I'm not > a DD, not applied even to DM yet (though I intend to do both soon), > just a random volunteer who tries to help Debian every once in > a while with a package or fifteen :) So maybe someone more > authoritative could chime in here and give us an official opinion > if needed :) Just one final point now, and I'm shutting up, I promise :) This is something I simply forgot to write in my previous e-mail, and it was *the main reason* I started writing it! It is, by all means, my largest pet peeve for the past more than twelve years, ever since I started writing documentation for my first small programs and then I had three different coworkers come to me with "simple little questions" that were already answered in the docs. The main reason - I *almost* want to say "the only reason" - for anybody, ever, to write documentation for any project is to lighten the support burden on the project authors later on. Let's just consider a simple little question that may be answered in two sentences and may be documented in five (e.g. including a section heading). Now, which do you think is easier *for everyone*: 1. The author does not document the question, and in the next year, fifty people ask him the same question in person, via e-mail, ICQ, IRC, or bug reports. Each time he responds with the same two sentences, for a total of fifty sentences for the question, a hundred sentences for the answer, and a hundred minutes time overall. Also, the author is... let's say, somewhat irritated... for having to repeat himself fifty times. Hopefully, he gets irritated enough to document the answer :) 2. The author does document the question. Throughout the next year, fifty people read the question in the docs and do not bother the author, for a total of five sentences for the documented question, and fifty-five minutes time overall (five minutes for the author documenting the question, and fifty minutes for the people answering it). Now, in the second scenario, the author has the time to actually do something else while people find the answer for themselves :) And now, consider the case when the author *has* documented the answer and fifty people *still* come to him with the same question, over and over again, when they could have spent a minute - or, well, sometimes five minutes - to just find the answer in the docs. Shall we say, "the author is somewhat irritated"? :) As I said, I'm shutting up now :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgphVlxyjvPuo.pgp Description: PGP signature
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
2009/5/12 LI Daobing : > iconv can't cover this. It sounds like an automatic translation > instead of changing encoding. > > i don't know how to explain this, but if you lived in Chinese culture, > you should know it's true. > > zh-autoconvert has a similar function like this program. > > wikipedia page: > http://en.wikipedia.org/wiki/Traditional_Chinese_characters > http://en.wikipedia.org/wiki/Simplified_Chinese_characters Thanks for the explanation, something like this probably would have been useful in the initial RFS. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: autoconf-archive (updated package)
On Tue, May 12, 2009 at 11:37, Deng Xiyue wrote: > Dear mentors, > > I am looking for a sponsor for the new version 20090426-1 > of my package "autoconf-archive". > > It builds these binary packages: > autoconf-archive - The Autoconf Macro Archive > > The package appears to be lintian clean. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/a/autoconf-archive > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/a/autoconf-archive/autoconf-archive_20090426-1.dsc > > I tried to contact the main maintainer(CCing) for review, but his box > was unavailable, so he granted me to find others for review and sponsor. > Thanks Huo. > > Hence, I would be glad if someone uploaded this package for me. > uploaded. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libapache2-mod-authnz-external
Hello, On Tue, May 12, 2009 at 02:29, Hai Zaar wrote: > On Mon, May 11, 2009 at 9:24 PM, Hai Zaar wrote: >> All fixed. Reuploaded. How come my lintian -viI does not show this warnings? > Sorry, forgot dh_prep. Rebuilt and reuploaded. > uploaded. and you need not (or should not) repack the upstream tarball if the upstream tarball is already in .tar.gz format. rename or make a soft link is enough. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libapache2-mod-authz-unixgroup
Hello, On Tue, May 12, 2009 at 02:29, Hai Zaar wrote: > On Mon, May 11, 2009 at 5:23 PM, LI Daobing wrote: >> Hello, >> >> On Mon, May 11, 2009 at 05:31, Hai Zaar wrote: >>> Good time of a day, dear mentors! >>> This is a second call for sponsor for libapache2-mod-authz-unixgroup >>> >>> >>> -- Forwarded message -- >>> From: Hai Zaar >>> Date: Sun, May 3, 2009 at 6:57 PM >>> Subject: RFS: libapache2-mod-authz-unixgroup >>> To: debian-mentors@lists.debian.org >>> >>> >>> Dear mentors, >>> >>> I am looking for a sponsor for my package "libapache2-mod-authz-unixgroup". >>> >>> * Package name : libapache2-mod-authz-unixgroup >>> Version : 1.0.1-1 >>> Upstream Author : Jan Wolter >>> * URL : http://www.unixpapa.com/mod_authz_unixgroup/ >>> * License : Apache >>> Section : web >>> >>> It builds these binary packages: >>> libapache2-mod-authz-unixgroup - access control based on on unix group >>> membership for Apache >>> >>> The package appears to be lintian clean. >>> >>> The upload would fix these bugs: 526790 >>> >>> The package can be found on mentors.debian.net: >>> - URL: >>> http://mentors.debian.net/debian/pool/main/l/libapache2-mod-authz-unixgroup >>> - Source repository: deb-src http://mentors.debian.net/debian unstable >>> main contrib non-free >>> - dget >>> http://mentors.debian.net/debian/pool/main/l/libapache2-mod-authz-unixgroup/libapache2-mod-authz-unixgroup_1.0.1-1.dsc >>> >>> I would be glad if someone uploaded this package for me. >>> >> comments: >> 1. lintian warning: >> W: libapache2-mod-authz-unixgroup source: >> out-of-date-standards-version 3.8.0 (current is 3.8.1) >> >> 2. no debian/watch >> >> 3. no Homepage field in debian/control >> > All fixed. Reuploaded. comments: you should not repack the upstream tarball if the upstream tarball is already in .tar.gz format. rename or make a soft link is enough. please fix this and re-upload. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: macchanger-gtk (updated package) -- fixed URL in watch file
Hello, On Tue, May 12, 2009 at 11:09, Alejandro Garrido Mota wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.1-4 > of my package "macchanger-gtk". > > It builds these binary packages: > macchanger-gtk - a GTK+ interface for GNU/MACchanger > > The package appears to be lintian clean. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/m/macchanger-gtk > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/m/macchanger-gtk/macchanger-gtk_1.1-4.dsc > > I would be glad if someone uploaded this package for me. > undocumented changes in README: $ debdiff macchanger-gtk_1.1-3.dsc macchanger-gtk_1.1-4.dsc | diffstat README |2 +- macchanger-gtk-1.1/debian/changelog |6 ++ macchanger-gtk-1.1/debian/watch |2 +- 3 files changed, 8 insertions(+), 2 deletions(-) -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libapache2-mod-authz-unixgroup
On Tue, May 12, 2009 at 3:23 PM, LI Daobing wrote: > > you should not repack the upstream tarball if the upstream tarball is > already in .tar.gz format. rename or make a soft link is enough. I'll take it from now on. Thanks. > > please fix this and re-upload. All done. Re-uploaded. -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libapache2-mod-authnz-external
On Tue, May 12, 2009 at 3:12 PM, LI Daobing wrote: > Hello, > > On Tue, May 12, 2009 at 02:29, Hai Zaar wrote: >> On Mon, May 11, 2009 at 9:24 PM, Hai Zaar wrote: >>> All fixed. Reuploaded. How come my lintian -viI does not show this warnings? >> Sorry, forgot dh_prep. Rebuilt and reuploaded. >> > > uploaded. > > and you need not (or should not) repack the upstream tarball if the > upstream tarball is already in .tar.gz format. rename or make a soft > link is enough. Following your advice, I've fixed and re-uploaded this package as well. Thank you! -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: libmemcached
Hello, On Tue, May 12, 2009 at 05:58, Monty Taylor wrote: > Dear mentors, > > I am looking for a sponsor for my package "libmemcached". > > * Package name : libmemcached > Version : 0.28-1 > Upstream Author : Brian Aker > * URL : http://tangent.org/552/libmemcached.html > * License : BSD > Section : libs > > It builds these binary packages: > libmemcached-dev - a C and C++ client library to the memcached server > libmemcached-tools - A C and C++ client library to the memcached server > libmemcached2 - A C and C++ client library to the memcached server > > The package appears to be lintian clean. > > There is, however, a lintian override for a manpage issue. I could make > a dpatch for it - but I can fix it in upstream almost immediately, so it > seems more sensible to handle the bug there directly. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/l/libmemcached > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/l/libmemcached/libmemcached_0.28-1.dsc > > I would be glad if someone uploaded this package for me. > comments: 1. the debian policy version should be 3.8.1 2. /usr/bin/memstat in libmemcached-tools is conflict with the same file in memstat package[1], one solution is install it as memstat.libmemcached and document this in README.Debian http://packages.qa.debian.org/m/memstat.html 3. consider remove the .la file if you already have a .pc file. thanks. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: sphinxsearch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Finney wrote: > Jérémy Lal writes: > These command names are rather too generic. Perhaps they should be > prefixed with ‘sphinx-’? > > These all look like installing the package with the wrong options to > ‘configure’, but that's a guess. > > Either write something useful in the README.Debian, or remove it if it's > not needed for the package. > > Perhaps Lintian was never run on this package before uploading it? This has now been re-uploaded. The manpages don't exist, and as there is no ITP bug, it can't close it, so those warnings remain. Apart from that it appears to me to be clean. Thanks, Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoJdo0ACgkQcqOpPRWIadcX9QCeNrSKAB21YyRieMPYxjt1dB4R SfQAn3HDGQdGYiIF9c38BPz6IunRFqQa =i7dE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: sphinxsearch
On Tue, May 12, 2009 at 4:15 PM, Tom Simnett wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ben Finney wrote: >> Jérémy Lal writes: >> These command names are rather too generic. Perhaps they should be >> prefixed with ‘sphinx-’? >> >> These all look like installing the package with the wrong options to >> ‘configure’, but that's a guess. >> >> Either write something useful in the README.Debian, or remove it if it's >> not needed for the package. >> >> Perhaps Lintian was never run on this package before uploading it? > > This has now been re-uploaded. The manpages don't exist, and as there is > no ITP bug, it can't close it, so those warnings remain. Apart from that > it appears to me to be clean. Hi! I'm not a mentor or DD, but you can: 1. Write man pages yourself - pick template from /usr/share/debhelper/dh_make/debian/manpage.1.ex 2. Open an ITP bug for sphinxsearch yourself - just file a bug (using reportbug tool) against wnpp package. My 2 cents :) -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libapache2-mod-authz-unixgroup
Hello, On Tue, May 12, 2009 at 20:56, Hai Zaar wrote: > On Tue, May 12, 2009 at 3:23 PM, LI Daobing wrote: >> >> you should not repack the upstream tarball if the upstream tarball is >> already in .tar.gz format. rename or make a soft link is enough. > I'll take it from now on. Thanks. >> >> please fix this and re-upload. > All done. Re-uploaded. > sorry to bother again. copyright issue: 1. where is the copyright come from? i did not find it in the source or the homepage. 2. whether this copyright is free? whether it has been discussed in debian-legal? if so, paste a link here, thanks. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libapache2-mod-authz-unixgroup
On Tue, May 12, 2009 at 4:21 PM, LI Daobing wrote: > Hello, > > On Tue, May 12, 2009 at 20:56, Hai Zaar wrote: >> On Tue, May 12, 2009 at 3:23 PM, LI Daobing wrote: >>> >>> you should not repack the upstream tarball if the upstream tarball is >>> already in .tar.gz format. rename or make a soft link is enough. >> I'll take it from now on. Thanks. >>> >>> please fix this and re-upload. >> All done. Re-uploaded. >> > sorry to bother again. > > copyright issue: > > 1. where is the copyright come from? i did not find it in the source > or the homepage. You are right. I've just blindly copied copyright file from mod_authnz_external, assuming it would be the same, since both packages are alike and come from the same author. I'll write to the author and ask to put copyright notice into the package. > > 2. whether this copyright is free? whether it has been discussed in > debian-legal? if so, paste a link here, thanks. > > > -- > Best Regards > LI Daobing > -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#521918: pbuilder --build --binary-arch invokes 'build' target
On Mon, May 11, 2009 at 08:34:54PM +0200, Petr Pudlak wrote: > > On Mon, May 11, 2009 at 03:11:22PM +0200, Filippo Rusconi wrote: > > > > It is a pity to have a Debian Policy so well documented, to point > > package-making learners to that Policy and then have non-conformant > > builders. > > > > In fact, I'd ask what would be the solution to overcome the problem > > (apart from the desirable fixing the builders)? > > Hi, I'm glad I (finally) got some response to the problem! > > I've had precisely the same problem as Filippo: I prepared my first package, I > spent many hours studying the Policy to follow it precisely, and to my > disappointment, I got a FTBFS bug report immediately after uploading the > package. I suspected I was not alone in this situation :) > I don't think the problem is so much in the Policy, I think the problem is > with > the builders. The builders must provide dependencies according to > debian/control and the target(s) they're calling. Of course, improving the > Policy is OK, but once the guidelines are agreed upon and written there, the > builders must follow it. I agree with this, also because what is stated in Policy is just plain sensible. > Not the other way around. I'm quite surprised that > these problems with the builders haven't been solved already, considering the > number of packages in Debian! Well, maybe there are not so many packages that perform as a clear cut separation between build-indep and build-arch... > I suggest to create a dummy package that would be as simple as possible and > that would demonstrate the problem. Then test it with various building tools > and > fill eventual bug reports. Maybe I could prepare such dummy package in the > following days, if I have time. If this would convince the developers responsible for the builders to deal with the problem, then that would be awsome. Any such DD listening ? Best regards, Filippo -- Filippo Rusconi, PhD - CNRS - public key C78F687C Author of ``massXpert'' at http://www.massxpert.org signature.asc Description: Digital signature
RFS: twittare
Dear mentors, I am looking for a sponsor for my package "twittare". Of course, a check and constructive criticism beforehand would be great ;). * Package name: twittare Version : 0.7.42-1 Upstream Author : Tabaré Caorsi * URL : http://www.twittare.com * License : GPL-3+ Section : net It builds these binary packages: twittare - A twitter client for Linux written in Qt The package appears to be lintian clean. The upload would fix these bugs: 528273 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/twittare - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/twittare/twittare_0.7.42-1.dsc I would be glad if someone uploaded this package for me. Kind regards Dominik George signature.asc Description: OpenPGP digital signature
Re: RFS: macchanger-gtk (updated package) -- fixed URL in watch file
2009/5/13 LI Daobing : > Hello, > > On Tue, May 12, 2009 at 11:09, Alejandro Garrido Mota > wrote: >> Dear mentors, >> >> I am looking for a sponsor for the new version 1.1-4 >> of my package "macchanger-gtk". >> >> It builds these binary packages: >> macchanger-gtk - a GTK+ interface for GNU/MACchanger >> >> The package appears to be lintian clean. >> >> The package can be found on mentors.debian.net: >> - URL: http://mentors.debian.net/debian/pool/main/m/macchanger-gtk >> - Source repository: deb-src http://mentors.debian.net/debian unstable >> main contrib non-free >> - dget >> http://mentors.debian.net/debian/pool/main/m/macchanger-gtk/macchanger-gtk_1.1-4.dsc >> >> I would be glad if someone uploaded this package for me. >> > undocumented changes in README: > > $ debdiff macchanger-gtk_1.1-3.dsc macchanger-gtk_1.1-4.dsc | diffstat > README | 2 +- > macchanger-gtk-1.1/debian/changelog | 6 ++ > macchanger-gtk-1.1/debian/watch | 2 +- > 3 files changed, 8 insertions(+), 2 deletions(-) > > Please, check again. I fix the problem -- http://www.mogaal.com GNU/Linux Debian SID Usuario Linux registrado #386758 GPG Key Fingerprint = F6A7 EF7E 4688 70C6 6B37 A8EF F6B0 9645 B24B F200 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
python setuptools usage in trac package
I am currently on packaging trac package from the sid repository to the current version for debian and ubuntu. The sid package is trac-0.11.2.1. The rule's file contains this line: > python setup.py install \ > --root=$(CURDIR)/debian/trac \ > --single-version-externally-managed > When i packaged this version to ubuntu jaunty which uses python2.6 as default python version the installation prefix changed from /usr to /usr/local for unknown reason. > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/resource.py > to resource.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/pool.py > to pool.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/mysql_backend.py > to mysql_backend.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/schema.py > to schema.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/api.py > to api.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/postgres_backend.py > to postgres_backend.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/sqlite_backend.py > to sqlite_backend.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/util.py > to util.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/db/__init__.py > to __init__.pyc > byte-compiling > /root/Trac-0.11.4/debian/trac/usr/local/lib/python2.6/dist-packages/trac/loader.py > to loader.pyc For workaround I set the --prefix argument. What I am wonder about, is it good practice to statically define the prefix in the rules file like this? Are there documented changes in python's package tools pycentral, python-shared for python2.6? Are there alternative solution to this? > python setup.py install \ > --prefix=/usr > --root=$(CURDIR)/debian/trac \ > --single-version-externally-managed > Best Regards, Gunnar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python setuptools usage in trac package
On Tue, May 12, 2009 at 04:50:44PM +0200, Gunnar Thielebein wrote: > When i packaged this version to ubuntu jaunty which uses python2.6 as > default python version > the installation prefix changed from /usr to /usr/local for unknown reason. See the rules file in rednotebook/sid; I had exactly the same problem when trying to make it Ubuntu-friendly. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 signature.asc Description: Digital signature
Re: RFS: cconv -- A iconv based simplified-traditional chinese conversion tool
on 二, 2009-05-12 at 17:02 +0800, Michal Čihař wrote: > - you should split the library to libcconv0 and rename devel package to > libcconv-dev > - please write useful description, pointing user to url is not a useful > description done > - cconv man page is obviously generated, you should include it's > sources and generate it during build I use asciidoc to generate manpage, fixed. > - Vcs-* fields are for debian packaging not for upstream > - README.Debian is useless > - why do you install empty file NEWS? clear Reuploaded. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cconv - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cconv/cconv_0.5.2-1.dsc Thanks for the review. -- Vern 2009-05-12 signature.asc Description: Digital signature
Re: RFS: scmbug
> > > 1. Do not make package native. > > > > What do I need to do to change the package into being non-native ? > > How/where do I specify the non-native version number ? What do I need to do to change the packaging into being non-native ? > > > 2. Please create proper debian directory and not by symlink to some > > > directory with templates and other crap in it. > > > > Why not ? > > Because it breaks some tools which check archive and makes NMUs > needlessly complicated. It sounds like some tools need to be corrected. For example, "man dpkg-buildpackage" reports a "-c" parameter for specifying the control file from a directory OTHER than debian/. But this flag is not available for dpkg-buildpackage. One should be able to provide those files in a directory with any name they want. > > Debian is not the only distribution this system is packaged for. I don't > > like to have a top-level directory called "debian" in the source code > > repository. Instead, I have a directory called packaging/debian. > > There is no need to have debian packaging things in upstream. I disagree. > > There are no hardcoded paths in the build process. I'm not sure why this > > error occurs. > > Have you looked at Makefile in your package? It contains this path on > dozens of lines. Thanks, this was an issue with cleaning up. Corrected now. > > > 7. Source should match the one available on upstream website: > > > $ md5sum SCMBUG_RELEASE_0-26-13.tar.gz scmbug_0.26.13.tar.gz > > > a5c92c23e8c2fa5f67a389e12c04aacd SCMBUG_RELEASE_0-26-13.tar.gz > > > d5645be5bc4a620f8f9db67a11662f0b scmbug_0.26.13.tar.gz > > > > I don't understand how dpkg-buildpackage prepared this new .tar.gz file. > > You should not make native package. Then tarball would match the > original one and all packaging changes will be in separate file. signature.asc Description: This is a digitally signed message part
Re: RFS (take 2): libbash
On Tue, May 12, 2009 at 8:01 PM, Patrick Matthäi wrote: > Hmm there are some new lintian warnings in > http://mentors.debian.net/debian/pool/main/l/libbash/libbash_0.9.10c-1.dsc > > > I: libbash source: debian-watch-file-is-missing Oops... fixed > I: libbash source: build-depends-without-arch-dep doxygen Fixed - doxygen moved to Build-Depends-Indep. Uploaded. > E: libbash: dir-or-file-in-var-lock var/lock/dirlocks/ Well... does it mean I'll have to create /var/log/dirlocks during boot process? If yes, is there any service in Debian that can create requested files/dirs on boot? (Please do not tell me that I need to write init script to do it :) > -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: sphinxsearch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hai Zaar wrote: > On Tue, May 12, 2009 at 4:15 PM, Tom Simnett wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Ben Finney wrote: >>> Jérémy Lal writes: >>> These command names are rather too generic. Perhaps they should be >>> prefixed with ‘sphinx-’? >>> >>> These all look like installing the package with the wrong options to >>> ‘configure’, but that's a guess. >>> >>> Either write something useful in the README.Debian, or remove it if it's >>> not needed for the package. >>> >>> Perhaps Lintian was never run on this package before uploading it? >> This has now been re-uploaded. The manpages don't exist, and as there is >> no ITP bug, it can't close it, so those warnings remain. Apart from that >> it appears to me to be clean. > Hi! > I'm not a mentor or DD, but you can: > 1. Write man pages yourself - pick template from > /usr/share/debhelper/dh_make/debian/manpage.1.ex > 2. Open an ITP bug for sphinxsearch yourself - just file a bug (using > reportbug tool) against wnpp package. > > My 2 cents :) I now have an ITP bug resolved and manpages. This package is now lintian clean according to lintian :) - -- Tom Simnett Director initforthe Ltd W: www.initforthe.com T: 020 7183 3116 M: 07786 441 844 E: t...@initforthe.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoJuFgACgkQcqOpPRWIaddYigCbBdMtPp7UZznFoFopBDK4CcNs rucAoI7Lz8n/WSA2PVetOSDVrMn60QnA =tJsT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: libmemcached
LI Daobing wrote: > 1. the debian policy version should be 3.8.1 Oops. > 2. /usr/bin/memstat in libmemcached-tools is conflict with the same > file in memstat package[1], one solution is install it as > memstat.libmemcached and document this in README.Debian > http://packages.qa.debian.org/m/memstat.html Done. > 3. consider remove the .la file if you already have a .pc file. Is that a policy/best practice for library packages? I've uploaded a new copy to mentors with 1 and 2 fixed. I'd like to know more about 3 before making that change. Thanks! Monty -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: scmbug
In <1242149210.3959.13.ca...@localhost>, Kristis Makris wrote: >> > > 1. Do not make package native. >> > What do I need to do to change the package into being non-native ? >> > How/where do I specify the non-native version number ? >What do I need to do to change the packaging into being non-native ? Use a version number containing a dash. IIRC, the version is in your debian/Changelog. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: python setuptools usage in trac package
[Gunnar Thielebein, 2009-05-12]
> I am currently on packaging trac package from the sid repository to the
> current version for debian and ubuntu. The sid package is trac-0.11.2.1.
>
> The rule's file contains this line:
>
> > python setup.py install \
> > --root=$(CURDIR)/debian/trac \
> > --single-version-externally-managed
> >
>
> When i packaged this version to ubuntu jaunty which uses python2.6 as
> default python version
> the installation prefix changed from /usr to /usr/local for unknown reason.
http://lists.debian.org/debian-python/2009/03/msg00091.html
additional notes:
if you use private directories, instead of "--install-layout=deb", you
can use set of other options (like --install-lib) - this will ease
backporting your package to Lenny. If you don't use private directories,
just use python-support >= 1.0 which is checking for Python files in
lots of places (including /usr/{,local}/python*/{site,dist}-packages).
--
http://people.debian.org/~piotr/sponsor
signature.asc
Description: Digital signature
Re: RFS: scmbug
In <1242149210.3959.13.ca...@localhost>, Kristis Makris wrote: >> > Debian is not the only distribution this system is packaged for. I >> > don't like to have a top-level directory called "debian" in the source >> > code repository. Instead, I have a directory called packaging/debian. >> There is no need to have debian packaging things in upstream. >I disagree. Well, then you are wrong. There is certainly never a *need* to have the Debian packaging upstream. A desire, perhaps misguided, sure; but, never a *need*. If it is a native package, there is no upstream. If it is a non-native package the packaging is versioned separately from the upstream. This removes one of the concerns that might drive one to maintain them together. The Debian packaging may involves Debian-specific patches, and may need to change with the Debian policy which upstream shouldn't need to worry about. Separating the packaging commands is an advantage here. Most of the people downloading your release tarballs won't be building a Debian package. Most of those that are building a Debian package will already have access to the packaging commands, outside of your release tarball. If any changes that Debian (or Debian-derivatives) need to make any changes to your package, various tools may complain. At the very least, there will be spurious diffs. If you want to maintain a debian/ directory in your upstream VCS and provide your own .debs and/or apt repository then, by all means, do so. However, please don't include the debian/ directory in your release tarballs so they don't get in the way of the official Debian (or Ubuntu or Knoppix or whatever) packaging. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: sphinxsearch
On 12/05/2009 19:56, Tom Simnett wrote: Ben Finney wrote: Jérémy Lal writes: These command names are rather too generic. Perhaps they should be prefixed with ‘sphinx-’? These all look like installing the package with the wrong options to ‘configure’, but that's a guess. Either write something useful in the README.Debian, or remove it if it's not needed for the package. Perhaps Lintian was never run on this package before uploading it? This has now been re-uploaded. The manpages don't exist, and as there is no ITP bug, it can't close it, so those warnings remain. Apart from that it appears to me to be clean. Hi! I'm not a mentor or DD, but you can: 1. Write man pages yourself - pick template from /usr/share/debhelper/dh_make/debian/manpage.1.ex 2. Open an ITP bug for sphinxsearch yourself - just file a bug (using reportbug tool) against wnpp package. My 2 cents :) I now have an ITP bug resolved and manpages. This package is now lintian clean according to lintian :) i just had a quick look at it (as a novice), as i'm willing to use it : - usr/sbin is listed in debian/dirs but not really used ? - watch file is missing - /usr/share/doc/sphinxsearch should contain the doc provided by sphinx source tarball, such doc should be properly registered using doc-base and docs file. - provide a README in the /usr/share/doc/sphinxsearch so that once the package is installed, one knows what's left to do to get it working Regards, Jérémy Lal. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: scmbug
At Tue, 12 May 2009 10:26:50 -0700, Kristis Makris wrote: > > Because it breaks some tools which check archive and makes NMUs > > needlessly complicated. > > It sounds like some tools need to be corrected. > > For example, "man dpkg-buildpackage" reports a "-c" parameter for > specifying the control file from a directory OTHER than debian/. But > this flag is not available for dpkg-buildpackage. > > One should be able to provide those files in a directory with any name > they want. Hi Kristis; I think it is probably not too realistic to expect debian to adapt their tools to your expectations. When/if you get more familiar with the tools and the debian packaging process, feel free to file bug reports for suggested enhancements. In the meantime, please consider that despite what might come across as a bit arbitrary and rough toned from time to time, people here are trying to lead you to a state of if not "best practices", at least "good enough practices" for your package to enter the debian archive. all the best, David -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libbash
Hai Zaar schrieb: On Tue, May 12, 2009 at 8:01 PM, Patrick Matthäi wrote: Hmm there are some new lintian warnings in http://mentors.debian.net/debian/pool/main/l/libbash/libbash_0.9.10c-1.dsc I: libbash source: debian-watch-file-is-missing Oops... fixed I: libbash source: build-depends-without-arch-dep doxygen Fixed - doxygen moved to Build-Depends-Indep. Uploaded. E: libbash: dir-or-file-in-var-lock var/lock/dirlocks/ Well... does it mean I'll have to create /var/log/dirlocks during boot process? If yes, is there any service in Debian that can create requested files/dirs on boot? (Please do not tell me that I need to write init script to do it :) Wouldn't it make sense to write those lockfiles to ~/ instead of a systemwide dir? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libbash
On Tue, May 12, 2009 at 10:55 PM, Patrick Matthäi wrote: >> >> Well... does it mean I'll have to create /var/log/dirlocks during boot >> process? If yes, is there any service in Debian that can create >> requested files/dirs on boot? (Please do not tell me that I need to >> write init script to do it :) > > Wouldn't it make sense to write those lockfiles to ~/ instead of a > systemwide dir? Some tools that use libbash (my custom app for example), run scripts as system users that do not have valid ~/ -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: ninja (updated package)
On Tue, 12 May 2009, William Vera wrote: > > Also, seems like you're missing the copyright part of your package at the > > end of the file, I mean something like: > > The Debian packaging is © 1900 - 2012, John Doe and > > is licensed under the GPL, see `/usr/share/common-licenses/GPL'. > > > > What file? the copyright file has the correct structure (I think) > Thanks for your comments > I'm talking about debian/copyright itself, take a look at this one: http://packages.debian.org/changelogs/pool/main/e/emesene/emesene_1.0.1-2/emesene.copyright at the end of the file you may notice that Emilio Pozuelo Monfort licensed his work (the package), for example. Regards -- JID: lavaram...@jabber.org | http://lusers.com.ar/ 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libbash
Hai Zaar schrieb: On Tue, May 12, 2009 at 10:55 PM, Patrick Matthäi wrote: Well... does it mean I'll have to create /var/log/dirlocks during boot process? If yes, is there any service in Debian that can create requested files/dirs on boot? (Please do not tell me that I need to write init script to do it :) Wouldn't it make sense to write those lockfiles to ~/ instead of a systemwide dir? Some tools that use libbash (my custom app for example), run scripts as system users that do not have valid ~/ A valid point maybe also /tmp, your /var/lock/dirlocks has currently the same functions (meant as permissions) as /tmp. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libbash
On Tue, May 12, 2009 at 11:00 PM, Patrick Matthäi wrote: > Hai Zaar schrieb: >> >> On Tue, May 12, 2009 at 10:55 PM, Patrick Matthäi >> wrote: Well... does it mean I'll have to create /var/log/dirlocks during boot process? If yes, is there any service in Debian that can create requested files/dirs on boot? (Please do not tell me that I need to write init script to do it :) >>> >>> Wouldn't it make sense to write those lockfiles to ~/ instead of a >>> systemwide dir? >> >> Some tools that use libbash (my custom app for example), run scripts >> as system users that do not have valid ~/ >> > > A valid point maybe also /tmp, your /var/lock/dirlocks has currently the > same functions (meant as permissions) as /tmp. Sure. But still I need to create /tmp/dirlocks (or better /var/tmp/dirlocks) on boot. How do I do it? -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: ninja (updated package)
Hi On Tue, May 12, 2009 at 2:52 PM, Mauro Lizaur wrote: > On Tue, 12 May 2009, William Vera wrote: > >> > Also, seems like you're missing the copyright part of your package at the >> > end of the file, I mean something like: >> > The Debian packaging is © 1900 - 2012, John Doe and >> > is licensed under the GPL, see `/usr/share/common-licenses/GPL'. >> > >> >> What file? the copyright file has the correct structure (I think) >> Thanks for your comments >> > > I'm talking about debian/copyright itself, take a look at this > one: > http://packages.debian.org/changelogs/pool/main/e/emesene/emesene_1.0.1-2/emesene.copyright > > at the end of the file you may notice that Emilio Pozuelo Monfort > licensed his work (the package), for example. > > Regards I see, but AFAIK it's optional Regards > > -- > JID: lavaram...@jabber.org | http://lusers.com.ar/ > 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- William Vera PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: ninja (updated package)
On Tue, 12 May 2009, William Vera wrote: > Hi > On Tue, May 12, 2009 at 2:52 PM, Mauro Lizaur > wrote: > > On Tue, 12 May 2009, William Vera wrote: > > > >> > Also, seems like you're missing the copyright part of your package at the > >> > end of the file, I mean something like: > >> > The Debian packaging is © 1900 - 2012, John Doe and > >> > is licensed under the GPL, see `/usr/share/common-licenses/GPL'. > >> > > >> > >> What file? the copyright file has the correct structure (I think) > >> Thanks for your comments > >> > > > > I'm talking about debian/copyright itself, take a look at this > > one: > > http://packages.debian.org/changelogs/pool/main/e/emesene/emesene_1.0.1-2/emesene.copyright > > > > at the end of the file you may notice that Emilio Pozuelo Monfort > > licensed his work (the package), for example. > > > > Regards > > I see, but AFAIK it's optional > Regards > Alright, that was all I had to say :-) Bye -- JID: lavaram...@jabber.org | http://lusers.com.ar/ 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libbash
In , Hai Zaar wrote: >On Tue, May 12, 2009 at 11:00 PM, Patrick Matthäi wrote: >> Hai Zaar schrieb: >>> On Tue, May 12, 2009 at 10:55 PM, Patrick Matthäi >>> >>> wrote: > Well... does it mean I'll have to create /var/log/dirlocks during > boot process? If yes, is there any service in Debian that can create > requested files/dirs on boot? (Please do not tell me that I need to > write init script to do it :) Wouldn't it make sense to write those lockfiles to ~/ instead of a systemwide dir? >>> Some tools that use libbash (my custom app for example), run scripts >>> as system users that do not have valid ~/ >> A valid point maybe also /tmp, your /var/lock/dirlocks has currently the >> same functions (meant as permissions) as /tmp. >Sure. But still I need to create /tmp/dirlocks >on boot. How do I do it? I believe Patrick meant to put the files in /tmp, not in /tmp/dirlocks. If you need the locks to last across reboots, /var/tmp, not /var/tmp/dirlocks. Both /tmp and /var/tmp have the 1777 permissions you want and are present on any Debian system. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS (take 2): libbash
On Tue, May 12, 2009 at 11:15 PM, Boyd Stephen Smith Jr. wrote: > In , Hai Zaar > wrote: >>On Tue, May 12, 2009 at 11:00 PM, Patrick Matthäi > wrote: >>> Hai Zaar schrieb: On Tue, May 12, 2009 at 10:55 PM, Patrick Matthäi wrote: >> Well... does it mean I'll have to create /var/log/dirlocks during >> boot process? If yes, is there any service in Debian that can create >> requested files/dirs on boot? (Please do not tell me that I need to >> write init script to do it :) > Wouldn't it make sense to write those lockfiles to ~/ instead of a > systemwide dir? Some tools that use libbash (my custom app for example), run scripts as system users that do not have valid ~/ >>> A valid point maybe also /tmp, your /var/lock/dirlocks has currently the >>> same functions (meant as permissions) as /tmp. >>Sure. But still I need to create /tmp/dirlocks >>on boot. How do I do it? > > I believe Patrick meant to put the files in /tmp, not in /tmp/dirlocks. If > you need the locks to last across reboots, /var/tmp, not /var/tmp/dirlocks. I need separate 1777 directory for locks library of libbash, since it may create rather complex file structure there, so I do not want to put it to just /tmp or /var/tmp/, since it may lead to collisions with files created manually by users (yes, I understand that users can occasionally, or on purpose to create files in /var/tmp/dirlocks as well, but that is another story). -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libbash
In , Hai Zaar wrote: >I need separate 1777 directory for locks library of libbash, since it >may create rather complex file structure there, so I do not want to >put it to just /tmp or /var/tmp/, since it may lead to collisions with >files created manually by users That's a *desire*, not a *need*. Follow the lead set by GPG, KDE, ORBit, PulsaAudio, SCIM, and SSH.[1] Put files in /tmp and if you need a "complex directory structure", create a per- user (or "instance") directory in /tmp and place your files inside. mkdtemp is your friend here, although it is not completely portable. mktemp+mkdir are portable, but make sure your code does not have a race condition. So far you haven't provided any evidence that /tmp or /var/tmp are inappropriate for your program. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ [1] Taken together, it is a good crowd to be in. signature.asc Description: This is a digitally signed message part.
RFS: gearmand
Dear mentors, I am looking for a sponsor for my package "gearmand". * Package name: gearmand Version : 0.5-1 Upstream Author : Eric Day and Brian Aker * URL : http://launchpad.net/gearmand * License : BSD Section : web It builds these binary packages: gearman- A distributed job queue gearman-client - A distributed job queue gearman-server - A distributed job queue libgearman-dev - A distributed job queue libgearman0 - A distributed job queue The package appears to be lintian clean. There is one lintian override that I've had fixed upstream, but the new version of upstream isn't out just yet. I'll remove the override when the new version comes out. The upload would fix these bugs: 528309 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gearmand - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gearmand/gearmand_0.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards Monty Taylor -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (resent): libdumbnet
On Tue, May 12, 2009 at 1:30 PM, Jan C. Nordholz wrote: > If you're still willing to sponsor libdnet: upstream is not very active > (wrt. source changes), but responds quickly. Review below. > Upstream location has changed, too. Argh, there is no indication at the sf.net page that it moved to google code. Please ask upstream to do a proper migration (close the webpage, move the code, bugs and so on) and backup and shut down the sf.net project. At the very least the sf.net project needs to indicate that it moved elsewhere. Also, the README and probably other files need updating too. > If you rebuild before sponsoring, please don't forget to use -v1.8-2. ;) Uhhh, there should never be an instance of someone sponsoring prebuilt .deb files, if you see someone doing that, they probably shouldn't be a Debian developer. > I've updated the package to use the latest tarball (1.12 from Jan 2007) and > corrected all links.[1] > [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/libdumbnet_1.12-1.dsc Here is a review: Please ask upstream if they would be willing to rename the library. Both libdnet and libdumbnet are too generic IMO, but libdumbnet would be best for Debian to prevent the need for a transition. This would cause the need for a transition in other distros though so it may not be a good idea. You seem to have radically altered the install procedures, why not install to debian/tmp in the install target and use dh_install like the current version does instead of manually moving stuff around? When running autotools in configure, you want to run make maintainer-clean in the clean target and then clean up any parts it missed. Also send a patch upstream to fix the maintainer-clean target if it misses anything. There are several warnings when running autotools, please file a bug/patch upstream. Likewise there are a few GCC warnings, python related and otherwise. There are several lintian complaints: $ lintian --info --display-info --display-experimental --pedantic --show-overrides --checksums --color auto *.changes I: libdumbnet source: duplicate-short-description libdumbnet1 libdumbnet-dev python-dumbnet I: libdumbnet source: dpatch-missing-description 01rename_library.sh.dpatch I: libdumbnet source: dpatch-missing-description 03build_all_python_versions.dpatch I: libdumbnet1: no-symbols-control-file usr/lib/libdumbnet.so.1.0.1 P: libdumbnet1: no-upstream-changelog I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:362 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:372 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:383 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:392 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:401 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:410 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:823 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:838 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man3/dumbnet.3.gz:848 I: libdumbnet-dev: hyphen-used-as-minus-sign usr/share/man/man8/dumbnet.8.gz:247 P: python-dumbnet: no-upstream-changelog As noted above by lintian there is no symbols file for the library. You can get one for the version in the archive here, please start with it and add any symbols added by upstream: http://qa.debian.org/cgi-bin/mole/seedsymbols/?pkgname=libdumbnet1 I assume you've sent the non-renaming patches upstream? 01rename_library.sh.dpatch refers to sourceforge instead of google. Who is he...@pool.math.tu-berlin.de? libdumbnet1 will probably always be automatically installed, you probably don't need README/TODO installed in it. Use debian/.docs files to avoid this. Likewise, the package descriptions should reflect the audiences. libdumbnet-dev/python-dumbnet probably needs a fair bit of information but libdumbnet1 will probably always be automatically installed so needs vastly less information. There seems to be a test suite in the upstream source code. Please enable it and also handle DEB_BUILD_OPTIONS=nocheck. Also you don't seem to handle noopt or parallel=n in DEB_BUILD_OPTIONS. You also don't handle cross-compiling, but the version in the archive does. You should also add -g to CFLAGS so that DEB_BUILD_OPTIONS=nostrip works. You run dh_installman but don't install any manual pages using it. A single autoreconf call can replace the aclocal/autoheader/autoconf/automake calls (but not the libtoolize one IIRC). I assume you've read the libpkg-guide and noted the two bugs filed on it? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
