RFS: libexplain
Dear Mentors, Package: libexplain Version: 0.4 Upstream Author: (myself) Peter Miller URL: http://libexplain.sourceforge.net/ License: GPLv3 or later The libexplain project provides a library which may be used to explain Unix and Linux system call errors. This will make your application's error messages much more informative to your users. The library is not quite a drop-in replacement for strerror, but it comes close. Each system call has a dedicated libexplain function. Regards Peter Miller mill...@canb.auug.org.au /\/\*http://miller.emu.id.au/pmiller/ PGP public key ID: 1024D/D0EDB64D fingerprint = AD0A C5DF C426 4F03 5D53 2BDB 18D8 A4E2 D0ED B64D See http://www.keyserver.net or any PGP keyserver for public key. If you want a vision of the future, it is a wireless broadband network feeding requests for foreign money-laundering assistance into a human temporal lobe, forever. With banner ads. -- John M. Ford -- Regards Peter Miller pmil...@opensource.org.au /\/\*http://www.canb.auug.org.au/~millerp/ PGP public key ID: 1024D/D0EDB64D fingerprint = AD0A C5DF C426 4F03 5D53 2BDB 18D8 A4E2 D0ED B64D See http://www.keyserver.net or any PGP keyserver for public key. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
The ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493282 Packages: http://clam.iua.upf.edu/download/linux-debian-sid/svnsnapshots I did some fixes on the packages following your advices and lintian's. I will do some extra effort on christmas holidays to wrap it up so i will be glad if you can do another review on the current status of the packages so you can find more problems i could fix. My todo list looks like this (+done -todo): + Not a native package anymore (adding a diff to upstream) + examples should be packaged with dh_examples. + debian/changelog has an incorrect distribution + Not tarballing the doxygen documentation + Remove CFLAGS and INSTALL_PROGRAM from debian/rules + Remove alternative dependency on old libxerces28-dev - Fill independent RFP's for applications and plugins. - Vcs-* fields is for Debian packaging, not upstream VCS repository - Include non GPLv2-or-later licenses in debian/copyright - Add man pages to the extra binaries (needed?) - Sign DSC files. Some questions: - Should i remove the Vcs fields while there is no public svn of the diff? - Could you point me to an example of debian packaging repository? Just to know how that should be organized. - Are the man pages for the extra binaries needed at all to be in the package? Those files are not meant to be launched by user but by the core programs. David. On Divendres 05 Setembre 2008 22:22:29 Vincent Bernat wrote: OoO La nuit ayant déjà recouvert d'encre ce jour du jeudi 04 septembre 2008, vers 23:26, David García Garzón dgar...@iua.upf.edu disait : Please, file an ITP for this package. This will be useful to track any progress, especially if someone has handled the upload or not. I filled it before sending the RFS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493282 OK. Moreover, the .dsc file is not signed. Must the key be validated by any debian maintainer at all? This would be better but this is not mandatory. However, this should be your key. As they are different source packages i don't know whether I should fill a single ITP bug and RFS request or just one for each. It would be better. For example, clam could be uploaded soon while clam-XXX could have a lot of problems and its upload would be delayed for several months. This would be better to have its own ITP. At first glance, here are the problems with the current package: - debian/changelog has an incorrect distribution I think that dhc has an --distribution option that could do the work. Or you can just edit by hand. ;-) We are creating the dsc files from ubuntu and then generating all the packages for debian and ubuntu with pbuilder using that same dsc. The script we are using, at clam/CLAM/scripts/doDebianPackages.py, is very convenient for us to provide non-official debian and ubuntu packages. But maybe not the way to proceed when officializing the procedure. Any suggestions are wellcome in that sense. Everybody is free to generate packages as they want to. However, keep in mind that you need to write sensible changelog (the script will have some difficulties). As long as the script gives good results, this is fine to use it. - Vcs-* fields is for Debian packaging, not upstream VCS repository Debian packaging is currently maintained at the upstream VCS. That is also very convenient for us at the moment as we are doing fixes to the packaging as we do changes on the install. But we really need advice as this seems also to produce some inconveniences. Being debian maintained in the same repository, are those fields ok? Should we keep a separate repository? Could we just to store the diff of the debian a part and keep most of debian folders in upstream svn? Both questions are related. Even if now, upstream and Debian packager are closely related, this may not be the case in the future. Debian packaging should only be targeted to go into Debian, not to be downloaded from the website, not to be included into Ubuntu (even if it will eventually migrate to Ubuntu when present in Debian). For example, in the packages that you propose to download from the website, you could widen the dependencies by depending on software not available any more or by suggesting softwares not available into Debian. Therefore, you need a dedicated branch or repository. - some of the files are licensed under MIT/X11, some are GPLv2 only I guess they are included 3rd party files. Any suggestion on how to deal with that? You just have to mention the files licensed under different licenses in debian/copyright. As long as the licenses are compatible, there is no problem. - examples should be packaged with dh_examples Do you mean dh_installexamples? Yes. Well
RFS: bfilter (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.1.4-1.1 of the package bfilter. There is a bug in bfilter causes in firefox to pop up a download window. http://prxbx.com/forums/showthread.php?tid=1043 there is an upstream fix for it, that I've submitted to as a bugreport to debian a long time a go, but I've received no reply. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496526 So, I've decided to make a NMU. I've also fixed a few lintinan warnings. It builds these binary packages: bfilter- Simple web filtering proxy bfilter-common - Simple web filtering proxy (common files) bfilter-dbg - Simple web filtering proxy (common files) bfilter-gui - Simple web filtering proxy (GUI) The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bfilter - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bfilter/bfilter_1.1.4-1.1.dsc I would be glad if someone uploaded this package for me. Kind regards Hámorszky Balázs -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
On Wed, 24 Dec 2008 12:12:56 +0100 David García Garzón dgar...@iua.upf.edu wrote: - Include non GPLv2-or-later licenses in debian/copyright - Add man pages to the extra binaries (needed?) Anything in /usr/bin, /usr/sbin, /bin/, /sbin/ or /usr/games needs a man page. Anything in /usr/share/ can do without but if there is any chance of a user needing to run something from /usr/share/ then a manpage is advisable. - Could you point me to an example of debian packaging repository? Just to know how that should be organized. $ sudo apt-get install reprepro $ man reprepro $ mkdir conf/ $ vi ./conf/distributions ... $ reprepro export $ reprepro include unstable $changesfile Simple. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpMUC4j0OzD1.pgp Description: PGP signature
Re: RFS: bfilter - unwarranted NMU
On Wed, 24 Dec 2008 14:16:54 +0100 Hámorszky Balázs balihb@gmail.com wrote: Dear mentors, I am looking for a sponsor for the new version 1.1.4-1.1 of the package bfilter. There is a bug in bfilter causes in firefox to pop up a download window. http://prxbx.com/forums/showthread.php?tid=1043 there is an upstream fix for it, that I've submitted to as a bugreport to debian a long time a go, but I've received no reply. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496526 So, I've decided to make a NMU. This package is not marked as lowNMU threshold, the bug is not relevant to the Lenny release, the package is not orphaned, there is no indication in the bug report that you have prepared an NMU and you have not waited for the maintainer to respond to the NMU request (as you haven't made it) - why are you considering an NMU? You couldn't even be bothered to describe the problem within the bug report itself, merely linking to some other site that supposedly describes the 'issue'. I've also fixed a few lintinan warnings. Not a good enough reason - yes, if this was an orphaned package or you had proof that the maintainer is MIA. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bfilter - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bfilter/bfilter_1.1.4-1.1.dsc I would be glad if someone uploaded this package for me. I doubt that Vedran would be quite so pleased. This is another upload to mentors that should be summarily removed for blatant disregard for Policy. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgptC3wgDHYu3.pgp Description: PGP signature
Re: RFS: bfilter - unwarranted NMU
On Wed, 24 Dec 2008 13:39:26 + Neil Williams codeh...@debian.org wrote: So, I've decided to make a NMU. This package is not marked as lowNMU threshold, the bug is not relevant to the Lenny release, the package is not orphaned, there is no indication in the bug report that you have prepared an NMU and you have not waited for the maintainer to respond to the NMU request (as you haven't made it) - why are you considering an NMU? You couldn't even be bothered to describe the problem within the bug report itself, merely linking to some other site that supposedly describes the 'issue'. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bfilter - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bfilter/bfilter_1.1.4-1.1.dsc I would be glad if someone uploaded this package for me. I doubt that Vedran would be quite so pleased. This is another upload to mentors that should be summarily removed for blatant disregard for Policy. After looking at the referenced report about this bug, I'm not at all convinced that this 'bug' even needs a fix - there is a clear workaround documented in the thread linked from the bug report and people claiming that the workaround works. Do you have evidence that the workaround does not work? As this is the only evidence provided in the bug report that the bug even exists, I find it doubtful that the bug is worth fixing as maintainer, let alone as an NMU. If this was my package, I'd probably have replied but I wouldn't accept an NMU. I'd be tempted to implement the workaround, thoroughly test it, feed that back to the bug report and leave it at that. AFAICT the bug as described is minor severity at best (I'd describe it as 'trivial'), the appears to be a working fix that does not involve changing the package (let alone an NMU) and there is no justification for any NMU. I can't see any reason why you spent any time devising an NMU for such a bug. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpxNWtLmuEzy.pgp Description: PGP signature
Re: RFS: bfilter - unwarranted NMU
Neil Williams wrote: I doubt that Vedran would be quite so pleased. This is another upload to mentors that should be summarily removed for blatant disregard for Policy. than I misconceived the policy. i can actually make an NMU without going through mentors even if I'm not a developer? I didn't done it out of ill will. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libexplain
On Wednesday 24 December 2008 13:44:39 Peter Miller wrote: Dear Mentors, Hello Peter, Package: libexplain Version: 0.4 Upstream Author: (myself) Peter Miller URL: http://libexplain.sourceforge.net/ License: GPLv3 or later The libexplain project provides a library which may be used to explain Unix and Linux system call errors. This will make your application's error messages much more informative to your users. The library is not quite a drop-in replacement for strerror, but it comes close. Each system call has a dedicated libexplain function. Sharing code is always good idea! ;-) However, I don't quite understand why should developers prefer the functions from libexplain instead of already existing ones like perror(3), strerror(3) strerror_r(3) (which is GNU-specific, ok), and probably some more I don't quite recall right now. Note that I'm not saying that your library is useless (I really had a brief glance over it), I just can't get it what is so cool about it. If it is an alternative to above mentioned functions, then why do we need sucn an alternative? RFS: also means that you have prepared some preliminary debian packages for your piece of software, and you are requesting a review and sponsorship ;-) -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: CLAM, C++ library for audio and music
On Wed, 24 Dec 2008 15:16:15 +0100 David García Garzón dgar...@iua.upf.edu wrote: - Could you point me to an example of debian packaging repository? Just to know how that should be organized. Ups, sorry, not that one. I guess that what you sent maintains a debian package repository, I was talking about svn-repository not package repository. We are maintaining the debian/ files within upstream svn (svn-repository), and i was suggested to maintain it in a separate svn. I was wondering on how to deal with that, whether to store the diff files or the full debian dir, how to apply and update it easily and so on. I guess that it has something to do with svn-buildpackage, but individual man pages don't give me the whole picture. Take a look at the SVN layout for packages like QOF: http://svn.debian.org/viewsvn/qof/trunk/ Unfortunately, viewsvn doesn't show the properties that allow MergeWithUpstream but if you check out the SVN and look at in something like svn-workbench, you can inspect the properties easily (or svn info will do the same). The debian directory as mergeWithUpstream set to 1 in the svn properties. Then I copy the relevant tarball from qof/ to debian/tarballs: $ cp qof/qof-0.8.0.tar.gz ../debian/tarballs/qof_0.8.0.orig.tar.gz $ svn-buildpackage IIRC symlinks don't work, can't remember why. (0.8.0 is the unreleased version, 0.7.5 was hosted at SF instead of Alioth so 'debcheckout' doesn't get you the right version, yet.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpwe0jw28Q3t.pgp Description: PGP signature
Re: RFS: bfilter - unwarranted NMU
On Wed, 24 Dec 2008 15:15:36 +0100 Hámorszky Balázs balihb@gmail.com wrote: Neil Williams wrote: I doubt that Vedran would be quite so pleased. This is another upload to mentors that should be summarily removed for blatant disregard for Policy. than I misconceived the policy. i can actually make an NMU without going through mentors even if I'm not a developer? NMU's can be made through mentors - that isn't the problem. You still need to follow the guidance in the Developer Reference: http://www.uk.debian.org/doc/developers-reference/pkgs.html#nmu During a release freeze, bugs that are severity normal or less are rarely worth an NMU and you've also targetted unstable which isn't a good idea during the release freeze. I didn't done it out of ill will. Fine, but you haven't explained why you want to do it now rather than waiting for after the Lenny release (which may well be what the maintainer is doing). The imperative now is to get the full details into the bug report and wait. So far, the maintainer has had no communication from you since August, what makes you think he is willing to accept an NMU? In the meantime, the package should still be removed from mentors IMHO. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpQmtXKoMOWk.pgp Description: PGP signature
Re: RFS: CLAM, C++ library for audio and music
On Wednesday 24 December 2008 14:29:47 Neil Williams wrote: On Wed, 24 Dec 2008 12:12:56 +0100 David García Garzón dgar...@iua.upf.edu wrote: - Include non GPLv2-or-later licenses in debian/copyright - Add man pages to the extra binaries (needed?) Anything in /usr/bin, /usr/sbin, /bin/, /sbin/ or /usr/games needs a man page. Anything in /usr/share/ can do without but if there is any chance of a user needing to run something from /usr/share/ then a manpage is advisable. That's my point. Most of the bins without manpage are binaries that are not intended to be run by the user but are launched by the main application. Anyway I just discovered help2man that will help me a lot to fullfil the requirement without loosing many time. - Could you point me to an example of debian packaging repository? Just to know how that should be organized. $ sudo apt-get install reprepro $ man reprepro $ mkdir conf/ $ vi ./conf/distributions ... $ reprepro export $ reprepro include unstable $changesfile Simple. Ups, sorry, not that one. I guess that what you sent maintains a debian package repository, I was talking about svn-repository not package repository. We are maintaining the debian/ files within upstream svn (svn-repository), and i was suggested to maintain it in a separate svn. I was wondering on how to deal with that, whether to store the diff files or the full debian dir, how to apply and update it easily and so on. I guess that it has something to do with svn-buildpackage, but individual man pages don't give me the whole picture. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: bfilter - unwarranted NMU
After looking at the referenced report about this bug, I'm not at all convinced that this 'bug' even needs a fix - there is a clear workaround documented in the thread linked from the bug report and people claiming that the workaround works. Do you have evidence that the workaround does not work? The workaround is per site solution. So one must add a line in urls.local for every ad site. The fix in the official svn (the one I've attached to the bugreport) fix it completely. I can't see any reason why you spent any time devising an NMU for such a bug. This bug is very annoying. On some/most pages it pops up more than one download window. If someone planing on using bfilter on lenny, than he/she must add all ad urls to the urls.local or recompile it from source. The point of bfilter contrary to adblock is that it don't need any blacklist to work. It's a so little fix and affect the usability of bfilter so much. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: bfilter - unwarranted NMU
On Wed, 24 Dec 2008 16:08:39 +0100 Hámorszky Balázs balihb@gmail.com wrote: After looking at the referenced report about this bug, I'm not at all convinced that this 'bug' even needs a fix - there is a clear workaround documented in the thread linked from the bug report and people claiming that the workaround works. Do you have evidence that the workaround does not work? The workaround is per site solution. So one must add a line in urls.local for every ad site. The fix in the official svn (the one I've attached to the bugreport) fix it completely. I can't see any reason why you spent any time devising an NMU for such a bug. This bug is very annoying. On some/most pages it pops up more than one download window. If someone planing on using bfilter on lenny, than he/she must add all ad urls to the urls.local or recompile it from source. The point of bfilter contrary to adblock is that it don't need any blacklist to work. It's a so little fix and affect the usability of bfilter so much. All of that should have been in the original bug report. Glad we managed to get to the bottom of it eventually. OK, so maybe it isn't minor as I thought - I agree it is normal severity and the Developer Reference does not include normal severity bugs in the list for NMU's. Annoying does not qualify as important and only important or higher qualifies for an NMU - unless the package is in the lowNMU list which this one is not. There are other ad block utilities for iceweasel - I guess the maintainer is waiting for the next upstream release. Sorry, I don't see that you can do any NMU for this package without explicit permission from the maintainer. If he doesn't reply or wants to wait, there is nothing you can do to fix this bug. You certainly cannot do anything without supplying more information in the bug report itself. The current bug is singularly unhelpful and lacking in content. Whichever way it works out, uploading to mentors was entirely the wrong thing to do and that version needs to be removed IMHO. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpSPpswBSst1.pgp Description: PGP signature
Re: RFS: bfilter - unwarranted NMU
Neil Williams wrote: Whichever way it works out, uploading to mentors was entirely the wrong thing to do and that version needs to be removed IMHO. It's already done. I'll submit more info to the bug report and contact the developer of bfilter. I hope that he'll consider to release a new version. Thanks for all the help! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libexplain
On Wednesday 2008 December 24 08:19:27 George Danchev wrote: strerror_r(3) (which is GNU-specific, ok) SUSv3 introduced strerror_r as well, as part of the Thread Safe Functions option. The two definitions are incompatible, but both available in glibc! [1] I favor the SUSv3 interface/semantics, but I understand that the GNU version predates it by some time. [1] I don't completely understand the technical details, but if your code indicates _XOPEN_SOURCE = 600 and not _GNU_SOURCE you can get the SUSv3 version. Otherwise you get the GNU version. -- 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: libexplain
On Wednesday 24 December 2008 17:40:42 Boyd Stephen Smith Jr. wrote: On Wednesday 2008 December 24 08:19:27 George Danchev wrote: strerror_r(3) (which is GNU-specific, ok) SUSv3 introduced strerror_r as well, as part of the Thread Safe Functions option. The two definitions are incompatible, but both available in glibc! [1] I favor the SUSv3 interface/semantics, but I understand that the GNU version predates it by some time. [1] I don't completely understand the technical details, but if your code indicates _XOPEN_SOURCE = 600 and not _GNU_SOURCE you can get the SUSv3 version. Otherwise you get the GNU version. Sure, that is explained in string.h [1] (but not in my copy of glibc doc reference, unless I'm blind ;-), but the reentrant version of strerror (with its two flavors) is not the most interesting part here, is it ? [1] /* Reentrant version of `strerror'. There are 2 flavors of `strerror_r', GNU which returns the string and may or may not use the supplied temporary buffer and POSIX one which fills the string into the buffer. To use the POSIX version, -D_XOPEN_SOURCE=600 or -D_POSIX_C_SOURCE=200112L without -D_GNU_SOURCE is needed, otherwise the GNU version is preferred. */ -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libexplain
On Wednesday 2008 December 24 11:17:04 George Danchev wrote: the reentrant version of strerror is not the most interesting part here, is it ? No, but: http://xkcd.com/386/ :) -- 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.
RFS: libjinput-java - portable java joystick and gamepad support
debs at http://mahogny.areta.org/temp/debs/
(mathtex and pidgintex also need sponsors :)
Source: libjinput-java
Section: games
Priority: extra
Maintainer: Johan Henriksson maho...@areta.org
Build-Depends: debhelper (= 7), java2-compiler
Standards-Version: 3.8.0
Homepage: https://jinput.dev.java.net/
Package: libjinput-java
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, java2-runtime
Description: JInput is an interface to joysticks and gamepads for java
The JInput Project hosts an implementation of an API for game controller
discovery and polled input. It is part of a suite of open-source
technologies
initiated by the Game Technology Group at Sun Microsystems with
intention of
making the development of high performance games in Java a reality.
.
The API itself is pure Java and presents a platform-neutral completely
portable model of controller discovery and polling. It can handle arbitrary
controllers and returns both human and machine understandable descriptions
of the inputs available.
.
The implementation hosted here also includes plug-ins to allow the API to
adapt to various specific platforms. These plug-ins often contain a native
code portion to interface to the host system.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
