Re: RFS: dhcp-probe, another try to request with a lot of update
[...] OK, OK, i think that is not the cleaner method to run a rm -rf on a file which doesn't exist but if you want, and if it is the usage in debian project, i will do This is definitely a minor issue, but I'm just trying to get you to follow at the very least the KISS principle (keep it simple and stupid) and some efficiency, getting rid of unnecessary bloat. [...] - Your init.d file feels fairly hacked, please take a look at, e.g., the init.d file of the arpwatch package (which also runs multiple daemons for multiple interfaces). Just looking at the code you use to kill daemons makes me shiver. start-stop-daemon will do. Really. Please don't keep all the stuff you commented out, either remove it or implement it. force-reload, however, must get implemented (see Debian Policy Sec. 9.3.2). your words fairly hacked is a joke ? No. Again, this init script does not follow the KISS principle and it does not make use of LSB helper function, which makes it just all too complex. An init script is an utterly simple thing: It should start and stop a daemon, and maybe report whether it is running. As a rule of thumb, 8% of code contains bugs. The large such a script is, the more bugs it will contain. And reviewing so much code is more work as well. The main problem i found in my init.d file was the signal used to kill the daemon (9) instead of the normal (15). For each configuration files, the script will read information about interface and its properties. Then script read daemon PID associated to configuration file and kill it and delete the PID file (added in latest update). Why can't you just use start-stop-daemon? It will handle all that stuff. The force_stop function is here to handle, with a basic system view, cases where daemons have to be stop. Moreover, arpwatch package does not provide the status option if 'running*' function are sources of the reaction... Could you explain me your comment ? My comment is mostly about the way you stop the daemons. There should not be a need to attempt to kill it in so many ways, just let start-stop-daemon do the job. If it fails -- so be it. Then something horribly bad is going on. But I need to review your updated package before further commenting on this. [...] * lines 59,61: Only depend on install, you can't do build and install in parallel and install already depends on build * lines 62,63: dh_testdir is ok, no additional files required * line 69: I think defaults should be fine, why do you add 80 15; that contradicts defaults According to tour advice i put defaults level to start daemon but i think that it is better to start the daemon before network start and stop it after. Isn't that the wrong way round? What is dhcp-probe good for, if there is no network running? But anyway, I'm fine with custom numbers, but then don't put defaults in there as well. [...] I'll grab the package from mentors.d.n later on this weekend and report back. Best, Michael pgpP8Huu06J6N.pgp Description: PGP signature
Re: RFS: remote-hellanzb-gui
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklL56oACgkQOSmNf03rmMR3CACfactqCT+8pAlmuRlxU6K7xWFg xfAAnRzKmIeUblLIDSU9xeQ0tClMa9fa =8rzF -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: ITS: xf86-input-tslib (updated package)
On Tue, 16 Dec 2008 04:18:45 +0800
Wen-Yen Chuang ca...@calno.com wrote:
Sorry it's taken so long to get back to you, I have been very
tired recently.
I am looking for a sponsor for the new version 0.0.5-2
of my package xf86-input-tslib.
It builds the binary package: xserver-xorg-input-tslib
You note in the changelog that this version build-depends on the
upload I made for tslib 1.0-5 to experimental. However, the binary
package does not depend on that version of tslib which could result in
unexpected behaviour, e.g. if a user takes the xorg driver package from
experimental without also taking the tslib package from experimental.
Outside of a release freeze, this could also be a problem during the
normal migration from unstable into testing, if for example a bug was
found in tslib that prevented the migration of 1.0-5, the xorg driver
would migrate ahead of tslib.
I'm only mentioning this as a caution - I don't consider it a practical
problem for these particular changes to these particular packages. Once
Lenny is released and we migrate both tslib and the xorg driver into
unstable and thence into testing, it would be best if either the
build-depends change was reverted or that the driver had a stricter
dependency on that version of tslib by using this change in
debian/control for the binary package:
- Depends: ${shlibs:Depends}, ${misc:Depends}, ${xserver:Depends}
+ Depends: libts-0.0-0 (= 1.0-5), ${shlibs:Depends}, ${misc:Depends},
${xserver:Depends}
In general, bumping the build-depends without changing the binary
dependency is not actually solving any particular problem, except a
FTBFS. Can you remind me why you wanted/needed to bump the
build-depends in the first place?
tslib 1.0-5 does include a tweak to the pkgconfig file in the libts-dev
package but the xorg driver configure.ac does not use pkgconfig for
libts so this change would have no effect on this package. Your 0.0.5-2
driver does build successfully against libts-dev 1.0-4 and debdiff
cannot find any unexpected differences if the build-depends is reverted.
Did you experience any problems with this version of the xorg driver
and the version of libts currently in unstable (and lenny)?
Description: tslib touchscreen driver for X.Org/XFree86 server
This X.Org/XFree86 driver provides support for touchscreens input
devices. The driver is based on tslib which supports events for moving
in absolute coordinates and relative coordinates.
On a different note, I'd like to ask a favour on behalf of users
needing busybox support for Xorg.
I noted that this version of the xorg ts driver uses a new copy of
debian/xsfbs. Lots of Xorg packages use debian/xsfbs/ and the shell
script in that directory forms the basis of a variety of maintainer
scripts in other Xorg packages. When those maintainer scripts are run
on a system that only has busybox shell, certain features of the shell
script fail because options are used for fgrep that simply do not exist
in the busybox implementation.
Can you help me identify someone in the Debian Xorg strike force or
someone responsible for the xsfbs code or some other way that these
concerns can be fixed?
The current patch for xsfbs.sh is available here:
http://buildd.emdebian.org/svn/browser/current/target/trunk/x/xorg/trunk/emdebian-xsfbs-xsfbs.sh.patch
I'd like to know if there are likely to be problems due to this patch
and whether the effect of the patch can be incorporated into all xsfbs
scripts. There are good reasons why busybox does not include support
for these particular options and I'd like to know if Xorg can do
without them before I try to persuade busybox upstream to add such
support.
I'll wait to hear from you about the build-depends issue before
uploading - I suspect it is OK to revert that change and build-depend
on libts-dev without a specific version when uploading to unstable. The
extra time should also allow me time to test both new versions more
fully. I don't need a new upload to mentors at this time.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp2roxP5OgnS.pgp
Description: PGP signature
RFS: ganttpv (was: Re: Processed: owner 509061)
Hello Brian, [CC'ing debian-mentors] 2008/12/19 Brian C. Christensen br...@pureviolet.net: Raphael, This is my first time submitting a request to get a package into Debian, so I don't know whether I'm supposed to contact you or not. If not, please ignore this email. You can contact me, just like anybody else, if you wish to; but there's no requirement ;) I'm just another folk working on Debian. I have taken my best shot at packaging GanttPV for Debian. I have posted requests for a sponsor on the sponsors web site and on the mentors web site. I have also sent the template email to the mentors mailing list and uploaded the .change file. Is there anything else that I am supposed to be doing to move this forward? First of all, have you seen the two replies sent to your email to the mentors mailing list? You can see your thread at http://comments.gmane.org/gmane.linux.debian.devel.mentors/34499 or in a different view: http://thread.gmane.org/gmane.linux.debian.devel.mentors/34499 or all alone: http://article.gmane.org/gmane.linux.debian.devel.mentors/34499 If you are not subscribed to the mailing list then say so when sending your messages, so that people can send you a copy of the message when replying. From what I can see, I've had nibbles but no bites. I am hoping that someone will be able to look it over and let know if something is wrong. One problem I know about is that I don't know how to set it up so that double clicking on a .ganttpv file would open the file with GanttPV. It appears that I need to add a new mime type and icon somewhere, but I can't find the documentation that says where and how to do that. That's done thanks to the .desktop files and to some other magic trick which I don't remember very well right now. You can start by taking a look at the .desktop files specifications at: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html In the mean time I'm trying to get people to try out my deb file. Assuming it works for them, I'll get the deb file posted on the GanttPV download site. Regards, Brian C. Christensen On Dec 18, 2008, at 8:27 PM, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: owner 509061 Brian C. Christensen br...@pureviolet.net Bug 509061 [wnpp] ITP: ganttpv -- project scheduling software Owner recorded as Brian C. Christensen br...@pureviolet.net. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net Douglas MacArthur - We are not retreating - we are advancing in another direction. signature.asc Description: This is a digitally signed message part.
Non free license?
Hello mentors, I'm interested in packaging Shapely [0], a python library, because I need it as a dependency for a program I'm working on (and I'd like to package too). Skapely was already packaged (as python-shapely) [1] and uploaded some time ago, but was rejected. Unfortunately, nobody could tell me the reason (the maintainer didn't answer to my emails, ftp masters didn't neither and other community members of the project seem to have no clue). Since I started to repackage it, I maybe found a possible solution to the dilemma: do you think that the license [2] (in particular the third condition) is not enough free? Notice that if this is the problem, I could try to contact upstream, or package an old GPLed version of the library (see [3]). (or just rewrite the _2_ function that I use from that library...) thank for you help Pietro Battiston [0]: http://trac.gispython.org/lab/wiki/Shapely [1]: http://lists.alioth.debian.org/pipermail/pkg-grass-general/2008-May/003072.html [2]: http://svn.gispython.org/svn/gispy/Shapely/trunk/LICENSE.txt [3]: http://lists.gispython.org/pipermail/community/2007-November/001271.html signature.asc Description: Questa è una parte del messaggio firmata digitalmente
RFS: gnapi
Dear mentors, I am looking for a sponsor for my package gnapi. * Package name: gnapi Version : 0.1.9-1 Upstream Author : Wieslaw Spyra * URL : http://www.gnapi.pl * License : GPL v.3 + OpenSSL Section : gnome It builds these binary packages: gnapi - Subtitles downloader from Napiprojekt.pl database The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnapi - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gnapi/gnapi_0.1.9-1.dsc I would be glad if someone uploaded this package for me. Kind regards Wieslaw Spyra -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Non free license?
hi Pietro: On Sat, 20 Dec 2008, Pietro Battiston wrote: Since I started to repackage it, I maybe found a possible solution to the dilemma: do you think that the license [2] (in particular the third condition) is not enough free? Notice that if this is the problem, I could try to contact upstream, or package an old GPLed version of the library (see [3]). It seems to me that it is very close to a BSD license, which should be OK. My suggestion is that you forward your query to the debian-legal list and get some feedback. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://www.iit.edu/~segre se...@debian.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
pam-script
Hello Mentors! I'm wondering if there is anything I can do to help get this package approved for inclusion in the main Debian repositories: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libpam-script It can be used to do some very cool things, including synchronizing non-shell email accounts when a user authenticates over POP3 or IMAP, triggering OfflineIMAP to sync with a redundant IMAP server. Thanks for any suggestions, Albert -- http://www.docunext.com/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
