Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Nov 26, 2007 3:36 PM, Andres Mejia [EMAIL PROTECTED] wrote: I am looking for a sponsor for my package mediatomb. A more thorough review of your package: doc/mediatomb.1 is generated from docbook xml, but that source code isn't available in the source package. This means the package cannot enter Debian because it fails DFSG 2. Please remove, rewrite or add the docbook source. Some of the .js files are not GPL licenced, please fill out the copyright file properly. Other files are copyrighted by entities not mentioned in debian/copyright: src/md5/* (different copyright holder licence), src/uuid (different copyright holder), src/inotify-nosys.h (different copyright holder, no licence, therefore we cannot distribute it - presumably there is a properly licenced copy somewhere since it looks like it came from linux), tombupnp/*** (different copyright holders licences), tombupnp/upnp/src/uuid/upnp_md5.c upnp_md5.h (looks non-free - no permission to distribute, suggest replacing with a public domain md5 implementation). src/uuid looks like a copy of libuuid, if your package gets uploaded, please notify the security team that your package contains an embedded copy of libuuid. Please also suggest to upstream that they remove it from the source and instead depend on an external libuuid from http://sourceforge.net/projects/e2fsprogs for example. Same for tombupnp, that looks like a modified copy of libupnp, try to get that merged into upstream libupnp: http://pupnp.sourceforge.net/ You also embed external JS libraries (each one js file), I'm not sure what debian policy about that is, although we now have fckeditor in the archive, so maybe package them up so other packages can depend on them? Might want to bring this up on the debian-webapps list. You may want to rewrite the copyright file to be machine parseable: http://wiki.debian.org/Proposals/CopyrightFormat open source (GPL) in the description is redundant for packages in Debian main The Vcs-* links point to a location that has only etch and sarge, where do you store packaging for sid? Do you have access to upstream SVN? If so, I suggest moving the .desktop file there so other distros may benefit from it too. Obviously you'd also need to add a ./configure flag so that distributions can choose which web browser to launch. Possibly the same for debian/config.xml.inst, but I'm not too sure about that. No need to install both the README files, I suggest just installing README. Same for the two scripting.txt files (install the ASCII one). Relevant linda warnings: W: mediatomb-common; Long descriptions contains short description. The long description of this package contains the short description. This is a bad idea, as the long description should be long, and not just reiterate the short description. W: mediatomb; Long descriptions contains short description. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITA: libdbi + libdbi-drivers (updated packages) 2nd try, please consider!
On Nov 26, 2007 4:36 PM, Thomas Goirand [EMAIL PROTECTED] wrote: What I did is this: ... Is that ok like this? Or should I just not backup the files, and delete them at the clean, as Craig Small suggested (less prone to errors)? Looks fine to me. Removing them on clean is just as good, and preferrable to some. Paul Wise wrote: You might want to support noopt too. What's that? Like nostrip, but ensures that the package is build with no optimisation (gcc -O0). Useful for people debugging crashes. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITA: libdbi + libdbi-drivers (updated packages) 2nd try, please consider!
Paul Wise wrote: On Nov 26, 2007 4:36 PM, Thomas Goirand [EMAIL PROTECTED] wrote: Paul Wise wrote: You might want to support noopt too. What's that? Like nostrip, but ensures that the package is build with no optimisation (gcc -O0). Useful for people debugging crashes. Most of the time, I see people using -O2 instead. I'd find using a poor optimization level only for some that needs debugging quite frustrating. Can't people wishing to do debugging recompile the package (and even remove the striping)? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITA: libdbi + libdbi-drivers (updated packages) 2nd try, please consider!
On Nov 26, 2007 6:20 PM, Thomas Goirand [EMAIL PROTECTED] wrote: Most of the time, I see people using -O2 instead. I'd find using a poor optimization level only for some that needs debugging quite frustrating. Can't people wishing to do debugging recompile the package (and even remove the striping)? Err, I think you misunderstand, or maybe I misunderstand you. If you encounter a crash, recompiling like so will give you a package that gives better backtraces: DEB_BUILD_OPTIONS=noopt,nostrip debuild That is, as long as the packaging supports it. Normally packages are built with -g -O2, and the debugging info is stripped by dh_strip, which checks DEB_BUILD_OPTIONS and strips only when nostrip isn't present. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scheme48 watch file
[CC'd to mentors; please also CC replies directly to me as I'm not subscribed to that list.] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411425 http://www.s48.org/1.7/scheme48-1.7.tgz http://mentors.debian.net/debian/pool/main/s/scheme48/ Regarding Please add a debian/watch file. ...I haven't been able to work out how to do this, because http://s48.org/ has a link to 1.7/download.html instead of to 1.7/ -- this means that the naïve http://s48.org/(?:[[:digit:].]+)/scheme48-([[:digit:].]+).tgz doesn't work, because it can't find any href at s48.org matching (?:[[:digit:].]+)/?$. For the same reason, this fails http://s48.org/(?:[[:digit:].]+)/download.html scheme48-([[:digit:].]+).tgz Any suggestions on this issue would be appreciated. signature.asc Description: Digital signature
Re: service helper package
On Sun, Nov 25, 2007 at 09:01:50PM -0800, C.J. Adams-Collier wrote:
is there something like a service-common package that provides a helper
script like the following for services to source?
I think the current solution is provide a template with dh_make,
which is somewhat more general since the init.sh might need to be
overhauled to be useful for some given app.
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
. /etc/default/$SERVICE_NAME
In general, you'd want to test for the existance and only source it if
it's there.
# Kill me on all errors
set -e
Put this early as possible.
# If the daemon binary does not exist, report the error and exit
if [ ! -f $SERVICE_DAEMON ]; then
fatal( Service daemon, '$SERVICE_DAEMON' does not exist. )
fi
Actually, this is usually:
[ -x $DAEMON ] || exit 0
since the conffiles (such as the initscript) are present after
removing (but not purging) the package, and this keeps them from
spewing noisy errors about the daemon not starting or such.
# Make sure the RUNDIR exists with correct permissions
if [ ! -d $RUNDIR ]; then
Any reason not to include the rundir in the pacakge? Then you don't
have to manually remove it in the initscripts.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is probably a good idea to be generally and consistently
supported. OTOH removing the execute bit or renaming the daemon file
already works most (90%) of the time.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Mon, Nov 26, 2007 at 04:49:26AM -0500, Justin Pryzby wrote:
On Sun, Nov 25, 2007 at 09:01:50PM -0800, C.J. Adams-Collier wrote:
# Make sure the RUNDIR exists with correct permissions
if [ ! -d $RUNDIR ]; then
Any reason not to include the rundir in the pacakge? Then you don't
have to manually remove it in the initscripts.
Spot the person who has never run a system with a tmpfs /var/run. grin
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is probably a good idea to be generally and consistently
supported. OTOH removing the execute bit or renaming the daemon file
already works most (90%) of the time.
No, this is a bad idea and should never be supported. If you don't want
something to start at boot, then shuffle the symlinks in /etc/rc?.d. If you
never want the possibility of the service being run, then remove the
package.
These disable-the-service-in-/etc/default hacks preclude the ability to
disable a service at boot but sometimes start it manually, and work around
the existing mechanisms for avoiding starting a daemon at boot time.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
Hallo C.J.,
C.J. Adams-Collier [EMAIL PROTECTED] wrote:
is there something like a service-common package that provides a helper
script like the following for services to source?
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
Init scripts should not use Bash, they should be Posix Shell scripts!
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
Why not use echo and cat? Calling echo this way the shell can't use the
builtin echo command and must spawn a new process.
if [ -z $SERVICE_NAME ] || \
[ -z $SERVICE_DESC ] || \
[ -z $SERVICE_DAEMON ]; then
fatal( Environment not configured correctly.\n\tService requires
definition of the following variables:\nSERVICE_NAME\nSERVICE_DESC\n
SERVICE_DAEMON )
fi
Why you want to test these values everytime? If the maintainer forgot
them one time, they are missing everytime.
# We do not want to be affected by PATH tampering. All calls to
# external programs will be fully qualified
PATH=
You know what you are doing here? PATH is necessary for the daemon to
find subcommands.
# echo an error message and quit
fatal() {
echo - failed:
You should get familiar with LSB log function. See lsb-base.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
IMO there's no need for such a script. Use /etc/init.d/skeleton as a
template and adapt it to your service.
Bye, Jörg.
--
Es liegt in der Natur des Menschen, vernünftig zu denken und
unlogisch zu handeln! Das Gesagte ist nicht das Gemeinte und das Gehörte
nicht das Verstandene!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
This one time, at band camp, Jörg Sommer said:
Init scripts should not use Bash, they should be Posix Shell scripts!
Not strictly true. A script written for use with #!/bin/sh should use
the POSIX superset allowed by policy. A script aimed at bsah should
just declare it's interpreter as #!/bin/bash. Generally, you don't need
to do that, but you are allowed to.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. just declare it's interpreter as #!/bin/bash. Generally, you don't need its to do that, but you are allowed to. Do you mean because bash is the default sh? It's still required to declare the interpretter: | If a script requires non-POSIX features from the shell interpreter, | the appropriate shell must be specified in the first line of the | script (e.g., `#!/bin/bash') Justin
Re: scheme48 watch file
Am Montag, den 26.11.2007, 20:30 +1100 schrieb Trent W. Buck: [CC'd to mentors; please also CC replies directly to me as I'm not subscribed to that list.] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411425 http://www.s48.org/1.7/scheme48-1.7.tgz http://mentors.debian.net/debian/pool/main/s/scheme48/ Regarding Please add a debian/watch file. ...I haven't been able to work out how to do this, because http://s48.org/ has a link to 1.7/download.html instead of to 1.7/ -- this means that the naïve http://s48.org/(?:[[:digit:].]+)/scheme48-([[:digit:].]+).tgz doesn't work, because it can't find any href at s48.org matching (?:[[:digit:].]+)/?$. For the same reason, this fails http://s48.org/(?:[[:digit:].]+)/download.html scheme48-([[:digit:].]+).tgz Any suggestions on this issue would be appreciated. Attached. Maybe one has a simpler file. Regards, Daniel version=3 opts=downloadurlmangle=s/([^\/]+)\/download.html$/$1\/scheme48-$1.tgz/,filenamemangle=s/([^\/]+)\/download.html/scheme48-$1.tgz/ \ http://s48.org/index.html \ ([\d\.]+)/download.html # http://s48.org/1.7/download.html/scheme48-download.html.tgz
RFS: dragbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 From: Ulrik Sverdrup [EMAIL PROTECTED] To: debian-mentors@lists.debian.org Subject: RFS: dragbox Dear mentors, I am looking for a sponsor for my package dragbox. * Package name: dragbox Version : 0.2.5-2 Upstream Author : Ulrik Sverdrup [EMAIL PROTECTED] * URL : http://www.student.lu.se/~cif04usv/wiki/dragbox.html * License : GNU GPL v2 (or any later version) Section : utils Description: A command line drag-and-drop tool for GNOME Dragbox is a tool for connecting the command line with the desktop environment. It summons a drag handle in a window when you are managing files or information in a shell, connecting the different workspaces -- desktop and command line. The inverse is also possible. It builds these binary packages: dragbox- A command line drag-and-drop tool for GNOME The package appears to be lintian clean. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/d/dragbox - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.dsc ITP: bug#452982 I would be glad if someone uploaded this package for me. Kind regards Ulrik Sverdrup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFHSt/vVHXQVLCw+tcRAtYOAJ41/F9XhPWqXNigw0KSSvZWGV9dJgCcCs41 g/JlWBGCx2D+CPZdOATsGCE= =6Cq0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
-dbg package for a suite - one libfoo-dbg package sufficient?
Hello, From a complete suite I build several packages: a library, a -dev, a plugin package for mozilla-based browsers and two packages that contain some applications. Now I got 2 crash reports during a short time. I normally rebuilt the packages with the nostrip option to get better backtraces. But now I think about adding a -dbg package. No problem so far. But: the packages for the plugin and the applications are very small, so I think creating own -dbg packages for them is not sufficient. But am I allowed to create just one -dbg package for all relevant packages? If yes, would it be ok to put all debugging symbols in the libfoo-dbg package or better in a foo-dbg package? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnome-color-chooser
Thank you very much for your useful suggestions! Paul Wise wrote: E, I guess the diff.gz is empty because you are upstream? Can I suggest that you put the debian/ directory in the diff.gz instead of your upstream tarball? Ok, done. You didn't file an ITP bug and close it in the changelog, please read http://www.debian.org/devel/wnpp/#l1 Done. The closes tag has also been taken over by *.changes correctly ;-) Please move the homepage to a proper field: http://wiki.debian.org/HomepageFieldHOWTO Done. debian/copyright points to /usr/share/common-licenses/GPL, which is a symlink to GPL-3, and your package seems to be GPL-2 or later. Done. Good eyes! ;-) Please remove cruft from debian/rules and debian/watch that isn't needed or used. Might want to install NEWS, THANKS using dh_installdocs Tried my best to clean them, but I don't want to remove all commented options as I think that I need them later probably (like debian/watch, but upstream is changing its host soon). Again, thank you very much for your help! A new version has just been uploaded to debian mentors and is waiting for reviewing. ;-) Jack P.S.: Please CC me as I'm not subscribed to the list ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scheme48 watch file
On Mon, Nov 26, 2007 at 03:08:12PM +, Daniel Leidert wrote: Please add a debian/watch file. version=3 opts=downloadurlmangle=s/([^\/]+)\/download.html$/$1\/scheme48-$1.tgz/,filenamemangle=s/([^\/]+)\/download.html/scheme48-$1.tgz/ \ http://s48.org/index.html \ ([\d\.]+)/download.html Thanks, this works. signature.asc Description: Digital signature
Re: interpretted scripts (Re: service helper package)
This one time, at band camp, Justin Pryzby said: On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. IIRC policy also allows [ $this -a $that ] and [ $this -o $that ] although I might be confused in thinking those aren't POSIX. just declare it's interpreter as #!/bin/bash. Generally, you don't need to do that, but you are allowed to. Do you mean because bash is the default sh? No, I mean that bash specific features are not generally necessary in writing something as simple as an init script. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Ubuntu-to-Debian packaging
On Fri, Nov 23, 2007 at 06:23:50PM -0400, Jose Luis Rivas Contreras wrote: You need a new changelog for Debian starting from scratch and you could adapt the copyright (if the license allow it) or just make one new. Why? Thats IMHO a very bad way to do it. 1) changelog is to track was has been done in the package since its beginning. since it is orignating from an ubuntu package, why should its history be dropped? That has several disadvantages, including that its impossible to track any change that happened before the initial Debian release. Very bad. Also its not fair to the Ubuntu maintainers that did the initial and eventually biggest part of the work. You simply ignore the fact that they did something in the history of the package. Besides from beeing unfair it might be a license violation, depending on how the ubuntu packaging has been licensed. 2) it is also not wise to start a new copyright file. Besides from the fact that the Ubuntu maintainers might already have worked alot on it and it would be a big waste of time, to just drop it and start from new, you should honour their work beeing done and their packaging license. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mcl
Dear mentors, I am looking for a sponsor for my package mcl. * Package name: mcl Version : 1:06-058-1 Upstream Author : Stijn van Dongen [EMAIL PROTECTED] * URL : http://micans.org/mcl/ * License : GPL-2 Section : math The MCL package is an implementation of the MCL algorithm, and offers utilities for manipulating sparse matrices (the essential data structure in the MCL algorithm) and conducting cluster experiments. MCL is currently being used in sciences like biology (protein family detection, genomics), computer science (node clustering in Peer-to-Peer networks), and linguistics (text analysis). It builds these binary packages: mcl- the Markov Cluster algorithm mcl-doc- documentation for mcl The package appears to be lintian clean. The upload would fix these bugs: 452405 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mcl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mcl/mcl_06-058-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Philipp Benner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scheme48 watch file
On Mon, Nov 26, 2007 at 08:30:56PM +1100, Trent W. Buck wrote:
...I haven't been able to work out how to do this, because
http://s48.org/ has a link to 1.7/download.html instead of to 1.7/
Here's a version that works, using the downloadurlmangle option:
version=3
opts=downloadurlmangle=s{s48.org/(.*)/download.html}{s48.org/$1/scheme-$1.tgz} \
http://s48.org/index.html (.*)/download.html
You could probably tighten up the (.*) regexps, but the idea is to
use one pattern to detect the version, and then munge that URL to get
to the actual tarball.
--
Eric Cooper e c c @ c m u . e d u
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dragbox
Hi Ulrik, * ulrik [EMAIL PROTECTED] [2007-11-26 17:07]: [...] I am looking for a sponsor for my package dragbox. * Package name: dragbox Version : 0.2.5-2 Upstream Author : Ulrik Sverdrup [EMAIL PROTECTED] * URL : http://www.student.lu.se/~cif04usv/wiki/dragbox.html * License : GNU GPL v2 (or any later version) Section : utils [...] - dget http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.dsc I am interested in sponsoring this package, however: [EMAIL PROTECTED]:tmp$] dget -x http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.dsc dget: retrieving http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 718 100 7180 0 5654 0 --:--:-- --:--:-- --:--:-- 0 dget: retrieving http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 87193 100 871930 0 246k 0 --:--:-- --:--:-- --:--:-- 383k dget: retrieving http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.diff.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1461 100 14610 0 11613 0 --:--:-- --:--:-- --:--:-- 258k dpkg-source: error: file dragbox_0.2.5.orig.tar.gz has size 87193 instead of expected 87189 ^^^ Please fix. I just had a quick look at the diff and saw the following in the long description: For detailed command line instructions, please read the included man page. Please remove this as every package in Debian should have a man page by policy. The menu file: ?package(dragbox):needs=X11 section=Apps/Tools\ Apps/Tools does no longer fit the menu policy, see http://lists.debian.org/debian-devel-announce/2007/07/msg0.html The changelog: * Added debian menu entry * Closes bug#452982 This is really no appropriate changelog entry, see http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-changelog-do Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpJBiMNZsuob.pgp Description: PGP signature
Re: service helper package
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 03:53:33PM +, Stephen Gran wrote: This one time, at band camp, Justin Pryzby said: On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. IIRC policy also allows [ $this -a $that ] and [ $this -o $that ] although I might be confused in thinking those aren't POSIX. -a and -o are XSI which AIUI is an (very common) extension of posix (see standards.7). dash allows them but posh does not. just declare it's interpreter as #!/bin/bash. Generally, you don't need to do that, but you are allowed to. Do you mean because bash is the default sh? No, I mean that bash specific features are not generally necessary in Ah, ok; I didn't think that could be right :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should just declare it's interpreter as #!/bin/bash. Generally, you don't need to do that, but you are allowed to. Just bear in mind that packages using such scripts will generate bug reports if/when someone needs to use the package on a low resource or embedded system where bash is not available. Yes, you are allowed to use #!/bin/bash but, IMHO, it is unwise to do so unless the package itself depends on bash (pre-depends if in preinst) or is directly related to bash in some other way. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Re: -dbg package for a suite - one libfoo-dbg package sufficient?
On Mon, Nov 26, 2007 at 03:44:14PM +, Daniel Leidert wrote: From a complete suite I build several packages: a library, a -dev, a plugin package for mozilla-based browsers and two packages that contain some applications. Now I got 2 crash reports during a short time. I normally rebuilt the packages with the nostrip option to get better backtraces. But now I think about adding a -dbg package. No problem so far. But: the packages for the plugin and the applications are very small, so I think creating own -dbg packages for them is not sufficient. But am I allowed to create just one -dbg package for all relevant packages? If yes, would it be ok to put all debugging symbols in the libfoo-dbg package or better in a foo-dbg package? I think it would be reasonable to put all of the symbols into the one dbg package. Presumably if you're intending to debug the plugin or application, the symbols for the shared library would be useful too, and if the plugin and application packages are small them their symbol tables would presumably be similarly small, so people aren't wasting massive amounts of traffic (to download) and disk space to store the unnecessary symbol tables if they just want to debug the library. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scheme48 watch file
Am Montag, den 26.11.2007, 10:31 -0500 schrieb Eric Cooper:
On Mon, Nov 26, 2007 at 08:30:56PM +1100, Trent W. Buck wrote:
...I haven't been able to work out how to do this, because
http://s48.org/ has a link to 1.7/download.html instead of to 1.7/
Here's a version that works, using the downloadurlmangle option:
version=3
opts=downloadurlmangle=s{s48.org/(.*)/download.html}{s48.org/$1/scheme-$1.tgz}
\
http://s48.org/index.html (.*)/download.html
You could probably tighten up the (.*) regexps, but the idea is to
use one pattern to detect the version, and then munge that URL to get
to the actual tarball.
This will download the tarball but name it download.html. You further
need a filenamemangle bsides the downloadurlmangle.
Regards, Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu-to-Debian packaging
El lun, 26-11-2007 a las 16:30 +0100, Patrick Schoenfeld escribió: On Fri, Nov 23, 2007 at 06:23:50PM -0400, Jose Luis Rivas Contreras wrote: You need a new changelog for Debian starting from scratch and you could adapt the copyright (if the license allow it) or just make one new. Why? Thats IMHO a very bad way to do it. 1) changelog is to track was has been done in the package since its beginning. since it is orignating from an ubuntu package, why should its history be dropped? That has several disadvantages, including that its impossible to track any change that happened before the initial Debian release. Very bad. Also its not fair to the Ubuntu maintainers that did the initial and eventually biggest part of the work. You simply ignore the fact that they did something in the history of the package. Besides from beeing unfair it might be a license violation, depending on how the ubuntu packaging has been licensed. Not too long ago, about 4 years, when Ubuntu didn't exist, I tried to upload my first package to Debian. It was a package we had been using in LinEx (our Extremadura Debian based distribution). My sponsor and some other people at Debian told me that changelog should begin when the package begins in Debian, no matter if it had been used before somewhere else. I don't know if there is a policy for this, but I would like to think there are no preferences between some derivatives and some others. I have not seen changelogs containing knoppix, progeny, mepis or linex entries... 2) it is also not wise to start a new copyright file. Besides from the fact that the Ubuntu maintainers might already have worked alot on it and it would be a big waste of time, to just drop it and start from new, you should honour their work beeing done and their packaging license. Sure, and previous work should be mentioned, no matter who did it: Ubuntu or my grand mother. Regarrds. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Ubuntu-to-Debian packaging
Hi, [no need to CC me. I never expressed the wish that I want that] On Mon, Nov 26, 2007 at 09:34:27PM +0100, José L. Redrejo Rodríguez wrote: Not too long ago, about 4 years, when Ubuntu didn't exist, I tried to upload my first package to Debian. It was a package we had been using in LinEx (our Extremadura Debian based distribution). My sponsor and some so your handling of packages derives from a time were neither Ubuntu, nor the Utnubu project existed and your only rationale for this is, that your sponsors (when you have not been a DD like now) said that? Uh. other people at Debian told me that changelog should begin when the package begins in Debian, no matter if it had been used before somewhere There is no consensous about this. See the list archive for -mentors. Their have been several discussions on this topic and there are a lot of Debian Developers that don't agree with this. Also I am quiet sure there is the talking about *your own* work. The difference is that you can do whatever you like with *your* work, while you can't just take the work from others and do like they never did it. else. I don't know if there is a policy for this, but I would like to Thats bad. You should not answer to such questions if you don't know it for your self! Thats especially true because of your DD status that causes others to give your saying more confidence. think there are no preferences between some derivatives and some others. I have not seen changelogs containing knoppix, progeny, mepis or linex entries... Giving a preference to one derivative is probably not the best idea, but if someone takes the work from others to integrate it into Debian or the otherway round then he should not just drop the packages history. And btw. Ubuntu does not do that. And: I gave you some rationales why it is bad. Whats yours? Compared to *that* case there is another case were I find it reasonable to drop changelog history. Say for example a package that evolves in your own private history. Sure, and previous work should be mentioned, no matter who did it: Ubuntu or my grand mother. Right. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnome-color-chooser
On Nov 27, 2007 1:03 AM, JackTheDipper [EMAIL PROTECTED] wrote: Again, thank you very much for your help! A new version has just been uploaded to debian mentors and is waiting for reviewing. ;-) Jack [please reply directly to the list] More review: please spell-check your package description :) You are missing copyright info from combobox.cc/h, pt.po. The other .po files need proper copyright info too. Some lintian warnings: W: gnome-color-chooser: binary-without-manpage usr/bin/gnome-color-chooser I: gnome-color-chooser: desktop-entry-contains-encoding-key /usr/share/applications/gnome-color-chooser.desktop:3 Encoding Some warnings from the new dpkg-shlibs: Some of these might bugs in some of the -dev packages you use, make sure that you aren't explicitly linking against any of these libraries. dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgnomeuimm-2.6.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgnomemm-2.6.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgnomecanvasmm-2.6.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgconfmm-2.6.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libSM.so.6 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libICE.so.6 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgnomevfsmm-2.6.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libglade-2.0.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libpangomm-1.4.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libcairomm-1.0.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libbonoboui-2.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgnomecanvas-2.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libpopt.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libbonobo-2.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libbonobo-activation.so.4 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libart_lgpl_2.so.2 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libatk-1.0.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgdk_pixbuf-2.0.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libpangocairo-1.0.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libcairo.so.2 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgnomevfs-2.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgconf-2.so.4 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgmodule-2.0.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libdl.so.2 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libORBit-2.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with libgthread-2.0.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/gnome-color-chooser/usr/bin/gnome-color-chooser shouldn't be linked with librt.so.1 (it uses none of its symbols).
Re: RFS: gnome-color-chooser
Awesome fan art btw :) -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dragbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Nico, (I would like to be CC'd any replies, if that is not totally out of form) Hi Ulrik, * ulrik [EMAIL PROTECTED] [2007-11-26 17:07]: [...] I am looking for a sponsor for my package dragbox. * Package name: dragbox Version : 0.2.5-2 Upstream Author : Ulrik Sverdrup [EMAIL PROTECTED] * URL : http://www.student.lu.se/~cif04usv/wiki/dragbox.html * License : GNU GPL v2 (or any later version) Section : utils [...] - dget http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.dsc I am interested in sponsoring this package, however: [EMAIL PROTECTED]:tmp$] dget -x http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.dsc dget: retrieving http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 718 100 7180 0 5654 0 --:--:-- --:--:-- --:--:-- 0 dget: retrieving http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 87193 100 871930 0 246k 0 --:--:-- --:--:-- --:--:-- 383k dget: retrieving http://mentors.debian.net/debian/pool/main/d/dragbox/dragbox_0.2.5-2.diff.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1461 100 14610 0 11613 0 --:--:-- --:--:-- --:--:-- 258k dpkg-source: error: file dragbox_0.2.5.orig.tar.gz has size 87193 instead of expected 87189 ^^^ Please fix. I just had a quick look at the diff and saw the following in the long description: For detailed command line instructions, please read the included man page. Please remove this as every package in Debian should have a man page by policy. The menu file: ?package(dragbox):needs=X11 section=Apps/Tools\ Apps/Tools does no longer fit the menu policy, see http://lists.debian.org/debian-devel-announce/2007/07/msg0.html The changelog: * Added debian menu entry * Closes bug#452982 This is really no appropriate changelog entry, see http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-changelog-do Kind regards Nico Thank you for your interest, and thanks for the comments on my package! I will answer with some questions before I publish a changed package. I will fix the original tarball issue. I used an equivalent but different .orig.tar.gz for -2 (compared to -1), but dput didn't upload the new .orig.tar.gz. I have fixed the menu entry, and I am now using the category Applications/Technical ; this is the best approximation I could find. I have also removed the last sentence in the long package description. Thanks for the pointers on these. For the changelog, I have no non-packaging changes to describe. I propose using just this draft (with updated timestamp later on, and for the version, see below) - --- dragbox (0.2.5-2) unstable; urgency=low * Added a debian menu entry and removed unnecessary reference to man page in package description. * Close ITP (closes: #452982) -- Ulrik Sverdrup [EMAIL PROTECTED] Mon, 26 Nov 2007 15:13:58 +0100 - --- Now, however, I wonder if I should bump the dash version further for the updated changes. Should the fixed package be version -3, or am I allowed to keep it at -2 (or even -1?). This is the main reason why I don't want to publish a changed package yet. Regards, Ulrik Sverdrup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFHSzugVHXQVLCw+tcRAnXLAKCONw/BALUJnnWUtRh48h/Lc0rprACcCbGm 33INJz1YmfNVSbGXY/32vNg= =63En -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: pykaraoke (updated package)
Dear mentors,
I am looking for a sponsor for the new version 0.5.1.ds1-1
of my package pykaraoke.
It builds these binary packages:
pykaraoke - free CDG/MIDI/MPEG karaoke player
pykaraoke-bin - free CDG/MIDI/MPEG karaoke player
python-pykaraoke - free CDG/MIDI/MPEG karaoke player
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/pykaraoke
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/p/pykaraoke/pykaraoke_0.5.1.ds1-1.dsc
Changes:
* New Upstream Release.
+ GUI: Now works with WxPython v2.8
+ GUI: Improved search results layout
+ CDG player: Improved handling of corrupt CDG files
+ CDG player: Solved minor scrolling issues
* Added DM-Upload-Allowed tag to control
* Removed Ana Guerrero from Uploaders
* Added Homepage label to control
* Updated menu: Games/Arcade - Games/Action
* Replaced deprecated ${Source-Version} by ${source:Version} in control
* Added dh_desktop to rules
I would be glad if someone uploaded this package for me.
Greetings,
Miry
PS: I've added the tag DM-Upload-Allowed: yes to debian/control to
allow future uploads of this package by Debian Maintainers (TM) - That
is, me :P
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Tue, 27 Nov 2007 01:47:31 +0800 Thomas Goirand [EMAIL PROTECTED] wrote: Stephen Gran wrote: That's not quite true - many packages in debian use an enable/disable variable in an /etc/default/package file. Not talking about any policy, but I personally hate it. Why on earth would you want to have a package NOT to work if you install it? This is insane... Disabled != not-working Haven't you had to disable a service for testing purposes or whatever? Or when comparing similar services . . . -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpyk9WI14NQ3.pgp Description: PGP signature
Re: service helper package
Hi,
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
Eric
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Tue, 2007-11-27 at 01:47 +0800, Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
Thomas
This tends to be used for packages that cannot provide a reasonable
default configuration, and would need to be hand edited before
activating the service.
--
David Watson - Debian GNU/Linux Developer
[EMAIL PROTECTED], [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]
Web: http://planetwatson.co.uk/blog
signature.asc
Description: This is a digitally signed message part
Re: service helper package
On Tue, 27 Nov 2007, Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
Because there are some times when a package works just fine without a
daemon running.
As a trivial example, see spamassassin.
That said, unless you have a really good reason the init script should
be enabled by default.
Don Armstrong
--
Clothes make the man. Naked people have little or no influence on
society.
-- Mark Twain
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pykaraoke (updated package)
Miriam, You're already in DPMT, how about joining PAPT as well and maintaining this package there? We can offer for example: * fixing lintian overrides * building python extensions for all supported Python versions in python-pykaraoke package * handling new dpkg fields fast (some freaks have whole repository on local machines, and they love to show others their sed skills) (hint: Homepage field) * fixing .desktop file (Application category issue, deprecated Encoding field) * merge README.txt and README.txt into README.txt (debian/docs) bzed: too late, Miriam is mine, you need to find another girl for the team ;-P -- http://people.debian.org/~piotr/sponsor.txt pgpKbWXQLh440.pgp Description: PGP signature
Re: -dbg package for a suite - one libfoo-dbg package sufficient?
Am Dienstag, den 27.11.2007, 06:14 +1100 schrieb Matt Palmer: On Mon, Nov 26, 2007 at 03:44:14PM +, Daniel Leidert wrote: [..] But: the packages for the plugin and the applications are very small, so I think creating own -dbg packages for them is not sufficient. But am I allowed to create just one -dbg package for all relevant packages? If yes, would it be ok to put all debugging symbols in the libfoo-dbg package or better in a foo-dbg package? I think it would be reasonable to put all of the symbols into the one dbg package. Thanks to you and Neill for your answers. I now saw, that libxml2 does the same. So I added a libfoo-dbg package and put all debugging symbols in it. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pykaraoke (updated package)
Miriam, You're already in DPMT, how about joining PAPT as well and maintaining this package there? We can offer for example: * fixing lintian overrides * building python extensions for all supported Python versions in python-pykaraoke package * handling new dpkg fields fast (some freaks have whole repository on local machines, and they love to show others their sed skills) (hint: Homepage field) * fixing .desktop file (Application category issue, deprecated Encoding field) * merge README.txt and README.txt into README.txt (debian/docs) bzed: too late, Miriam is mine, you need to find another girl for the team ;-P -- http://people.debian.org/~piotr/sponsor.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pykaraoke (updated package)
2007/11/27, Piotr Ożarowski [EMAIL PROTECTED]: Miriam, You're already in DPMT, how about joining PAPT as well and maintaining this package there? We can offer for example: * fixing lintian overrides * building python extensions for all supported Python versions in python-pykaraoke package * handling new dpkg fields fast (some freaks have whole repository on local machines, and they love to show others their sed skills) (hint: Homepage field) * fixing .desktop file (Application category issue, deprecated Encoding field) * merge README.txt and README.txt into README.txt (debian/docs) Great idea! I'll upload it to SVN tomorrow :) Thanks for the suggestion, I didn't even think about it :) I'll upload it to SVN tomorrow morning (CET here), and afterwards I'll prepare a newer package from there :) bzed: too late, Miriam is mine, you need to find another girl for the team ;-P XD Kisses, Miry
Re: service helper package
On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote:
Hallo C.J.,
C.J. Adams-Collier [EMAIL PROTECTED] wrote:
is there something like a service-common package that provides a helper
script like the following for services to source?
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
Init scripts should not use Bash, they should be Posix Shell scripts!
Sure.. by bash I mean POSIX shell
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
Why not use echo and cat? Calling echo this way the shell can't use the
builtin echo command and must spawn a new process.
Is there a test to determine whether there is a builtin for a given
command? If so, we could test for that and use it if it exists.
Otherwise, use the fully qualified version
if [ -z $SERVICE_NAME ] || \
[ -z $SERVICE_DESC ] || \
[ -z $SERVICE_DAEMON ]; then
fatal( Environment not configured correctly.\n\tService requires
definition of the following variables:\nSERVICE_NAME\nSERVICE_DESC\n
SERVICE_DAEMON )
fi
Why you want to test these values everytime? If the maintainer forgot
them one time, they are missing everytime.
Maybe they exist one time but get removed before the next run?
# We do not want to be affected by PATH tampering. All calls to
# external programs will be fully qualified
PATH=
You know what you are doing here? PATH is necessary for the daemon to
find subcommands.
Yep. I don't want to execute any but the fully qualified commands.
It's a security thing.
# echo an error message and quit
fatal() {
echo - failed:
You should get familiar with LSB log function. See lsb-base.
I will. Thanks.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
IMO there's no need for such a script. Use /etc/init.d/skeleton as a
template and adapt it to your service.
I agree... but existing scripts use such a beast, so I put it in here.
Bye, Jörg.
Cheers,
C.J.
signature.asc
Description: This is a digitally signed message part
Re: service helper package
On 25/11/2007, C.J. Adams-Collier [EMAIL PROTECTED] wrote: is there something like a service-common package that provides a helper script like the following for services to source? I'm thinking that it would belong somewhere like /usr/share/service-common/init.sh. I have not tested the following yet, and I'm a sucky bash programmer. Ever heard about lsb-base and /lib/lsb/init-functions? :) That's exactly what you are looking for. dh_make provides an example init.d script using the LSB init functions (but it isn't very compliant as it is now[1]) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450898 Regards, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Mon, Nov 26, 2007 at 11:03:57PM +0100, Eric Lavarde wrote:
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
If you *really* need to knobble an init script temporarily, an 'exit 0' at
the top works perfectly well. That's a very, very rare occurance, though.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
Eric Lavarde schrieb:
Hi,
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
Just use a tool like sysv-rc-conf which manages the symlinks for you.
sysv-rc-conf $service on|off
It can't be easier than that and it works the way it's meant to be.
I also hate the enable/disable flags in /etc/default/$service.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: service helper package
On Mon, Nov 26, 2007 at 04:51:38PM -0800, C.J. Adams-Collier wrote: On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote: C.J. Adams-Collier [EMAIL PROTECTED] wrote: # Fully qualified paths to required programs START_STOP_DAEMON=/sbin/start-stop-daemon CAT=/bin/cat ECHO=/bin/echo Why not use echo and cat? Calling echo this way the shell can't use the builtin echo command and must spawn a new process. Is there a test to determine whether there is a builtin for a given command? If so, we could test for that and use it if it exists. Otherwise, use the fully qualified version There's type and command and which and whatis (see the policy huge long bug about this things) but I don't know why you would use them at runtime (except I guess how debhelper does it with if [ `which ... 2/null` ]; ...) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
This one time, at band camp, C.J. Adams-Collier said: On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote: Why not use echo and cat? Calling echo this way the shell can't use the builtin echo command and must spawn a new process. Is there a test to determine whether there is a builtin for a given command? If so, we could test for that and use it if it exists. Otherwise, use the fully qualified version It's recommended not to use full paths in general. Sometimes it becomes necessary to move binaries from one path to another, and hard coding full paths breaks that. Resetting PATH is more useful than hard coding full paths to binaries if you're worried about security. You know what you are doing here? PATH is necessary for the daemon to find subcommands. Yep. I don't want to execute any but the fully qualified commands. It's a security thing. No, it's really not. Resetting PATH to some small subset is useful, but breaking your child processes' ability to run call popen isn't all that great. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: service helper package
Eric Lavarde wrote:
Hi,
Thomas Goirand wrote:
Stephen Gran wrote:
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is such a broken behavior. Initscripts are enabled and disabled in
the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
Not talking about any policy, but I personally hate it. Why on earth
would you want to have a package NOT to work if you install it? This is
insane...
You might want to disable _temporarily_ a certain application? It's
easier/quicker than to reconfigure the init system and you don't loose
the information about run-levels where the program is meant to start.
Eric
I'm ok with that, but not *BY DEFAULT*. IMHO, by default, a package
should just run...
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
