Re: RFS: whohas (bug fixes)
On Wed, Dec 31, 2008 at 11:38 AM, Jonathan Wiltshire wrote: > Ok, sorry for the noise. I wasn't sure how closely you were watching > -mentors. NP. I watch it quite closely, reading all the mails at least daily. > I've uploaded 0.21-4 to m.d.n which closes bugs 510189, 510231, 510259, > 510152 and 510203. If you've time to take a look and upload that would > be great, I've also sent all the bugs and patches upstream. > > I wondered, with this many bugs opened so soon, if whohas wouldn't be > better suited in experimental, but then again most of them have been > because of incorrect urls in the various package searchers, so perhaps > not. Do you have any thoughts? Its the usual post-accept bug flood, nothing to worry about IMO. It might be a good idea to allow some kind of config file to override the URLs/regexes, this would be useful for when the external websites change and the package has not been updated yet. Could you suggest this upstream? I'd like to wait a few more days before uploading - see how many more bugs testers can shake out. If there are no more changes by Sunday, I'll upload then. -- 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: kita2
Hi, Junichi Uekawa wrote: > At Sun, 28 Dec 2008 05:34:46 +0900, > Hiroyuki Yamamoto wrote: >> I am looking for a sponsor for my package "kita2". >> >> * Package name: kita2 >> ITP: #488488 >> Version: 1.90.4-1 >> Upstream Author: Hideki Ikemoto >> * URL: http://kita.sourceforge.jp/ >> * License: The MIT License >> Section: net >> Language: Ruby >> Description: Ruby based 2ch client for KDE >> Kita2 is useful to view "2ch-style Bulletin Board System" that use >> "bbs.cgi" and "read.cgi", it is like that we use RSS reader to read >> blogs. It helps you to read/write articles in such BBS. >> . >> 2ch-style BBS include >> - 2 channel (http://www.2ch.net, largest BBS in Japan) >> - Pink channel (http://www.bbspink.com/) >> - Machi-BBS (http://www.machi.to/) >> - Shitaraba (http://rentalbbs.livedoor.com/jbbs/) and so on. >> >> >> It builds this binary package: >> kita2 - Ruby based 2ch client for KDE >> >> The package appears to be lintian clean. > > > I tested the package, and it doesn't seem to work well on my > environment GNOME with LC_ALL=ja_JP.EUC-JP. Oh, I did not test on LANG=ja_JP.EUC-JP. Well, here is the new package: http://mentors.debian.net/debian/pool/main/k/kita2/kita2_1.90.4-1.dsc Regards, -- Hiroyuki Yamamoto -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: whohas (bug fixes)
On Tue, Dec 30, 2008 at 10:59:44AM +0900, Paul Wise wrote:
>
> Next time, please depend on ${DPATCH_STAMPFN} instead of patch-stamp
> in debian/rules.
Done.
> For the manual page change, once the manual page is accepted upstream,
> I would suggest a sed command in debian/rules install or binary rather
> than a patch. The file in question will be uncompressed on most
> systems and compressed on Debian, so upstream's manual page should
> just refer to uncompressed intro.txt and Debian should modify it at
> install time. See the nsis package for an (ugly) example of how to do
> this. This way you won't have to refresh the patch every time upstream
> modifies the manual page around the change.
That makes sense; I'll set it up once the manual goes into upstream.
> In future, it is a good idea to document the status of patches
> upstream in the patch header/description.
Done for all existing and new patches.
> PS: I prefer not to be CCed on RFS mails. If have time I'll upload, if
> not someone else will.
Ok, sorry for the noise. I wasn't sure how closely you were watching
-mentors.
I've uploaded 0.21-4 to m.d.n which closes bugs 510189, 510231, 510259,
510152 and 510203. If you've time to take a look and upload that would
be great, I've also sent all the bugs and patches upstream.
I wondered, with this many bugs opened so soon, if whohas wouldn't be
better suited in experimental, but then again most of them have been
because of incorrect urls in the various package searchers, so perhaps
not. Do you have any thoughts?
TIA.
Jonathan
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
Sending of encrypted mail is encouraged
signature.asc
Description: Digital signature
Re: RFS: krypt
On Wed, Dec 31, 2008 at 10:09 AM, Stefanos Harhalakis wrote: > The upload would fix these bugs: 507655, 510275 Firstly, there was no need to file 510275, instead you should have just retitled the RFP 507655 to ITP and marked yourself as the owner. Please read these: http://www.debian.org/devel/wnpp/#l3 http://www.debian.org/Bugs/server-control#retitle http://www.debian.org/Bugs/server-control#owner Secondly, I've merged them and retitled 507655. So you only need to close one and the other will be closed too. > - dget http://mentors.debian.net/debian/pool/main/k/krypt/krypt_0.2-1.dsc Quick review of the diff.gz: debian/watch needn't have blank lines or comments. Please forward the manual page upstream if you have not already. Post-lenny, kde3/qt3 will be transitioned away from, so it might be a good idea to ask upstream to port the app to KDE 4 & Qt 4. Same for the HAL -> DeviceKit transition. debian/rules contains a lot of unnessecary comments and stuff. debian/rules doesn't handle DEB_BUILD_OPTIONS=noopt or DEB_BUILD_OPTIONS=parallel (see debian-policy for info about these). debian/rules runs dh_installexamples but there are no debian/*examples files since you are depending on debhelper 7 and using compat 7, perhaps you should be using features from it? see the dh manual page, /usr/share/doc/debhelper/examples/rules.simple and /usr/share/doc/debhelper/examples/rules.tiny. -- 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
RFS: krypt
Dear mentors, I am looking for a sponsor for the package "krypt". * Package name: krypt Version : 0.2-1 Upstream Author : Upstream Author : Jakub Schmidtke * URL : http://krypt.berlios.de/ * License : GPL Section : kde It builds these binary packages: krypt - KDE GUI for managing volumes encrypted with LUKS The package appears to be lintian clean. The upload would fix these bugs: 507655, 510275 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/krypt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/krypt/krypt_0.2-1.dsc This is a very useful program that isn't currently available as a debian package. I'm new to debian packaging (there is only one other package that I'm maintaining) but I believe that I've packaged this according to debian policy and the new maintainer's guide. I would be glad if someone checked this package for errors (it seems as lintian error/warning free) and uploaded it for me. Kind regards, Stefanos Harhalakis -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: cppcheck, new upstream version 1.27
Reijo Tomperi wrote: Dear mentors, I am looking for a sponsor for my package "cppcheck". * Package name: cppcheck Version : 1.25-1 Upstream Authors: Daniel Marjamäki Reijo Tomperi * URL : http://cppcheck.wiki.sourceforge.net/ * License : GPL 3 Section : devel It builds these binary packages: cppcheck - C/C++ code analyzer The package appears to be lintian clean. The upload would fix these bugs: 503730 Hi, New upstream version was released, so I made a new Debian package of it. (and right after that noticed that I missed the new developer from the copyright file and made new package again). I'm again looking for a sponsor for it. It is lintian clean and builds with cowbuilder. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cppcheck - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.27-2.dsc -- Reijo -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Call Me Immediately For More Information.
I have a new email address!You can now email me at: eric23zaka...@yahoo.com - Call Me Immediately For More Information.
Re: RFS: dhcp-probe, another try to request with a lot of update
Hi! [...] > > I'll grab the package from mentors.d.n later on this weekend and report back. > Sorry that it took so long, but now I got around to do another round of review. - The unpacked source contains dhcp-probe.debhelper.log - control/Description has some strange whitespace, please clean up. - You don't need a Pre-Depends on ucf, Depends should be sufficient (you use it in the postinst, there is no preinst here) - What about the upstream status of your patch? - debian/rules: * You don't use the DEST variable, please remove it. * In the clean target, run dh_clean ... after dh_auto_clean; this will resolve the above dhcp-probe.debhelper.log issue I think these issues should be easy to resolve, and other than that the package looks fine to me. Best, Michael pgp1zdkIKQrgt.pgp Description: PGP signature
Re: RFS: libpqstego
Hi Christian! > I am looking for a sponsor for my packages "libpqstego" and "pqstego". I'm not a DD so I cannot sponsor uploads, but here are some comments: Both packages are tagged as version: 0.0.0, do you really think they are ready to be included in Debian? In both packages you are shipping the debian/ stuff in the sources, so the *.diff.gz are empty :S. $ dpkg-source -x libpqstego_0.0.0-1.dsc dpkg-source: warning: diff `./libpqstego_0.0.0-1.diff.gz' doesn't contain any patch $ dpkg-source -x pqstego_0.0.0-1.dsc dpkg-source: warning: diff `./pqstego_0.0.0-1.diff.gz' doesn't contain any patch As you are upstream, you should separate the debian/ dir from the sources. If you release a *.tar.gz without debian/ dir, and then you are prepare the debian package, the changes needed are stored in the *.diff.gz file... Check your packages with lintian adding the -I option: $ lintian -I libpqstego_0.0.0-1_i386.changes I: libpqstego source: package-lacks-versioned-build-depends-on-debhelper 7 I: libpqstego0: no-symbols-control-file usr/lib/libpqstego.so.0.0.0 I: libpqstego0-dev: extended-description-is-probably-too-short I: libpqstego0-dbg: extended-description-is-probably-too-short $ lintian -IE pqstego_0.0.0-1_i386.changes I: pqstego-dbg: extended-description-is-probably-too-short I: pqstego: extended-description-is-probably-too-short you should work on this... And yes... your extended descriptions are for sure *too* short :) BTW, check your short descriptions too, after reading 6.2.1-6.2.3 on Developers Reference [1] [1] http://www.debian.org/doc/developers-reference/ libpqstego builds fine under pbuilder, but libpqstego0-dev and libpqstego0-dbg fails on piuparts... I haven't tested why, but please check this too... Uhmm... didn't tried for pqstego... Uhmm BTW, I'm not sure about versioning the package names for -dev and -dbg... check the Library Packaging Guide too [2] :) [2] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ Uhmm, finally, maybe both projects can be merged... (?) OK. That's what I can see after a fast checking... Thanks for your interest on Debian :) Ruben Molina > Ps.: Merry Chrismas, and a Happy New Year signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Re: RFS: remote-hellanzb-gui
Hello all, I'm forwarding my RFS of the Remote HellaNZB GUI python application to debian-python list as I forgot to do so initially. Would someone be kind enough to have a look at it? Original RFS: > I am looking for a sponsor for my package "remote-hellanzb-gui". > > * Package name: remote-hellanzb-gui > Version : 0.9.2-1 > Upstream Author : Clement Lorteau > * URL : http://launchpad.net/remote-hellanzb-gui > * License : GPLv3 > Section : net > > It builds these binary packages: > remote-hellanzb-gui - HellaNZB GNOME front-end > > The package appears to be lintian clean. > > The upload would fix these bugs: 509038 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/r/remote-hellanzb-gui > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/r/remote-hellanzb-gui/remote-hellanzb-gui_0.9.2-1.dsc > > I would be glad if someone uploaded this package for me. Thank you for > your reviews. > Additional details: > Hello, > > To try to draw a little attention to my request, here are some details > about this package, as I realize i didn't include more than what the > d.m.n template says. > > First, what it is this package : it's a small GNOME application i > wrote to > easily download newsgroups binary files by remotely controlling your > HellaNZB daemon. What makes it different from the other similar tools > out there (like LottaNZB, Hellafox...) is that this one is really > aimed at controlling your HellaNZB daemon remotely, by using SSH to > copy NZB files located on your computer, and optionally setting up a > SSH tunnel automatically to access your server through the Internet > securely. Add stuff to your download queue from work, university, or > anywhere ! ;) Screenshots [1] could give you an idea of what it's like. > > [1] https://sourceforge.net/project/screenshots.php?group_id=246092 > > It's written in Python. It uses python-support, so that makes the > debian packaging fairly easy. I think my packaging is pretty clean. I > don't have as much experience as you guys, but at least, "lintian -iI > *changes *deb *dsc" from unstable gives nothing, and the binary > package installs and runs well on unstable. I'd really appreciate a > review. > > Thank you for your attention ! > -- Clément Lorteau www.lorteau.net | launchpad.net/~northern-lights signature.asc Description: OpenPGP digital signature
Re: advise needed for library packaging
On Tue, 30 Dec 2008 16:30:28 +0200 George Danchev wrote: > > "some sort of API version discriminator" doesn't sound as if you've > > understood SONAME transitions. > > ... or you better understand [1] that you should avoid keeping SONAME > artifacts in the -dev package names, thus avoid changing -dev package name on > each SONAME bump, which would make release team cry upon transitions, loudly. Which is why, generally, I prefer to use libfoo-dev - it isn't an argument (to me) for using some number other than the SONAME in the -dev package name. It would be particularly confusing to use a number in the -dev package name that is just "some sort of API discriminator" but that had no relation to the actual SONAME. If a number is used, it should change in step with the transitions and be predictable from objdump -p. However, once a transition does come along, if you want to retain libfoo1.2-dev and libfoo2.0-dev, then it makes more work for some but allows libraries with hundreds and hundreds of reverse-dependencies to have a sensible migration path. Such libraries are few and far between, thankfully, but the ability to retain the SONAME in the -dev package name (and the source package name) is important for a small number of fundamental libraries. There is then the inevitable pain of deciding that libfoo1.2 simply has to go away at some point. :-) Where would we be without libc6-dev ? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHEMY117W1l.pgp Description: PGP signature
Re: advise needed for library packaging
On Tuesday 30 December 2008 00:07:34 Neil Williams wrote:
> On Mon, 29 Dec 2008 22:12:24 +0200
>
> George Danchev wrote:
> > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> > > http://bugs.debian.org/libpkg-guide
> > >
> > > Firstly, do you need that library? Nothing in sid seems to depend on
> > > it, not even sleuthkit.
> >
> > Library packages which nobody {build-}depends on yet, sits in the same
> > boat as the rest of the leaf (application) packages, so general rules
> > should apply:
>
> I think that is an error. Libraries are intrinsically harder to package
> correctly and have more implications for the archive than applications.
> e.g. applications don't change binary package name (let alone source
> package name) on a routine basis. A library package without reverse
> dependencies is less useful than a leaf application with more intrinsic
> problems and more hassle, therefore counts as less desirable than a
> leaf application.
Libraries being intrinsically harder to package correctly does not make those
of them with no reverse build dependencies being useless to the users who
would like use them and prefer them in the form of debian packages (just like
any other leaf packages). Currently Debian main contains 1489 -dev packages
with no reverse build-depends found for them. Do you really believe that
these are some sort of massive fallacy (assuming ~10% of them being false
positives and not relevant to the topic like manpages-dev) and waste of
packaging time.
> > > -dev packages should not have SONAMEs in their package names,
>
> ? -dev packages can have SONAMEs in the package name - but in most
> situations, the extra complexity isn't worth it.
>
> > > what is
> > > the reason for the libtsk-dev -> libtsk3-3-dev change? If the API has
> > > changed incompatibly, libtsk-3-dev might be more appropriate.
> >
> > Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort
> > of API version discriminator ?
>
> IMHO libtsk-dev should only change to libtsk3-dev - I don't see the
> need for libtsk-3-dev (I suspect you'll get a lintian warning).
> libtsk3-3-dev is only if the upstream API is so unstable that you will
> need a libtsk3-4-dev instead of migrating smoothly to libtsk4.
> Personally, I'd look at the glib and gtk model of libfooN.N rather than
> libfooN-N if there is a good reason to not use libfoo-dev or
> libfooN-dev.
>
> "some sort of API version discriminator" doesn't sound as if you've
> understood SONAME transitions.
... or you better understand [1] that you should avoid keeping SONAME
artifacts in the -dev package names, thus avoid changing -dev package name on
each SONAME bump, which would make release team cry upon transitions, loudly.
[1] these comments from Stephen Frost would help ;-)
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#ftn.id292176
--
pub 4096R/0E4BD0AB 2003-03-18
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: libpqstego
Dear mentors, I am looking for a sponsor for my packages "libpqstego" and "pqstego". * Package name: libpqstego Version : 0.0.0-1 Upstream Author : Christian Kuka * URL : https://sourceforge.net/projects/pqstego * License : GPL Section : libs * Package name: pqstego Version : 0.0.0-1 Upstream Author : Christian Kuka * URL : https://sourceforge.net/projects/pqstego * License : GPL Section : text It builds these binary packages: libpqstego0 - Perturbed Quantization Steganography Library libpqstego0-dbg - Perturbed Quantization Steganography Library Debug symbols libpqstego0-dev - Perturbed Quantization Steganography Library Development pqstego- A steganography console tool for JPEG images pqstego-dbg - debugging symbols for pqstego The packages can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libpqstego - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libpqstego/libpqstego_0.0.0-1.dsc - URL: http://mentors.debian.net/debian/pool/main/p/pqstego - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pqstego/pqstego_0.0.0-1.dsc I would be glad if someone uploaded this packages for me. Kind regards Christian Kuka Ps.: Merry Chrismas, and a Happy New Year -- --- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x61E7150B - 4EFC 3FA6 FB8E 2BD5 CA11 6F15 F557 6B5D 61E7 150B Christian Kuka ck...@madkooky.de signature.asc Description: Digital signature
Re: advise needed for library packaging
On Tuesday 30 December 2008 04:04:55 Paul Wise wrote: > On Tue, Dec 30, 2008 at 5:12 AM, George Danchev wrote: > > Why is libfoo-X-dev better than libfooX-dev, where 'X' is being some sort > > of API version discriminator ? > > Both of those are the same, I'm glad to read that. > my comment was about libfooABI-API-dev vs libfoo-API-dev. Yes, your wording made that clear, the latter is preferred. To summarize: * if the ABI has changed, but the API remains the same, then change the library package name, but not the -dev package one. * if the API has changed, both -dev and library package names should be changed. I wonder if such a wording would address the valid complain of #493951 ? -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
