Best of Armani, Bikkembergs, UGG
The biggest and largest luxury store for shoes and bags is just one click away. Recommended by thousands of satisfied customers worldwide, we carry dozens of famous brands including: Hermes Adidas Chanel Shoes Paul Smith Prada Shoes Here you willc find hundred thousands of best designs for shoes, and leather products, at at temp't1ng priceE. Sale ends this week, so visit web site today and start pampering yourself and your loved ones! - Visit our site: www.shoesideal[DOT]com (copy this link and replace "[DOT]" to ".") -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed (with 1 errors): developers-reference: uses debian-policy style wording
Processing commands for [EMAIL PROTECTED]: > reassign 489135 developers-reference Bug#489135: debian-policy: how to document a repackaged .orig.tar.gz Bug reassigned from package `debian-policy' to `developers-reference'. > severity 489135 normal Unknown command or malformed arguments to command. > retitle 489135 developers-reference: uses debian-policy style wording Bug#489135: debian-policy: how to document a repackaged .orig.tar.gz Changed Bug title to `developers-reference: uses debian-policy style wording' from `debian-policy: how to document a repackaged .orig.tar.gz'. > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489135: developers-reference: uses debian-policy style wording
reassign 489135 developers-reference severity 489135 normal retitle 489135 developers-reference: uses debian-policy style wording stop In my opinion developers-reference should not use must/should/may wording, because this makes readers confuse developers-reference with debian-policy. For example, in developers-reference 3.4.0 : file:///usr/share/doc/developers-reference/best-pkging-practices.html#bpp-origtargz "must contain detailed information how the repackaged source was obtained, and how this can be reproduced in the debian/copyright." The word "must" gives the impression that it's a standard to which Debian software must comply. Please consider rephrasing the must/should/may parts in developers-reference to convert these parts to just best-practice recommendations. Or, please consider moving those parts to debian-policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Clarify what "sensible behaviour" is for init scripts
Reply-To: In-Reply-To: <[EMAIL PROTECTED]> reassign 426877 debian-policy 3.8.0.1 retitle 426877 Clarify what "sensible behaviour" is for init scripts thanks Ok, this confirms my initial feeling. Changing this in dpkg would require a wide-scale testing and much effort for little gains since the policy already require packages to behave sensibly. Iñaki, if you ever encounter bad init scripts, please report bugs against the offending packages. On Fri, 04 Jul 2008, Steve Langasek wrote: > Feel free to propose an amendment to policy that clarifies that "sensible" > behavior is equivalent to --oknodo (without implying that init scripts are > required to use s-s-d!), and I will happily second it; as I already > commented in that thread, I think this is a mere clarification of what the > policy has always been, not a change to policy at all. Here's a try (against current master branch): diff --git a/policy.sgml b/policy.sgml index c9bd84f..772afce 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5946,9 +5946,11 @@ rmdir /usr/local/share/emacs 2>/dev/null || true The init.d scripts must ensure that they will behave sensibly if invoked with start when the service is already running, or with stop when it - isn't, and that they don't kill unfortunately-named user + isn't (in particular, they should not exit with a non-zero +error code), and that they don't kill unfortunately-named user processes. The best way to achieve this is usually to use - start-stop-daemon. + start-stop-daemon and its --oknodo +option. Russ, feel free to clone against lintian if you think that it makes sense that it warns usage of start-stop-daemon without this option. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed (with 2 errors): Clarify what "sensible behaviour" is for init scripts
Processing commands for [EMAIL PROTECTED]: > Reply-To: Unknown command or malformed arguments to command. > In-Reply-To: <[EMAIL PROTECTED]> Unknown command or malformed arguments to command. > reassign 426877 debian-policy 3.8.0.1 Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs) Bug reassigned from package `dpkg' to `debian-policy'. > retitle 426877 Clarify what "sensible behaviour" is for init scripts Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs) Changed Bug title to `Clarify what "sensible behaviour" is for init scripts' from `dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Celebrating the Glory of our Nation
Proud to be an American http://68.58.112.130/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarify what "sensible behaviour" is for init scripts
On Fri, 04 Jul 2008, Raphael Hertzog wrote: > Here's a try (against current master branch): > diff --git a/policy.sgml b/policy.sgml > index c9bd84f..772afce 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -5946,9 +5946,11 @@ rmdir /usr/local/share/emacs 2>/dev/null || true > The init.d scripts must ensure that they will > behave sensibly if invoked with start when the > service is already running, or with stop when it > - isn't, and that they don't kill unfortunately-named user > + isn't (in particular, they should not exit with a non-zero > +error code), and that they don't kill unfortunately-named user > processes. The best way to achieve this is usually to use > - start-stop-daemon. > + start-stop-daemon and its --oknodo > +option. > > > Seconded. It is unfortunate that we need such explanations for the obvious, but we certainly *do* need them. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh signature.asc Description: Digital signature
Re: Clarify what "sensible behaviour" is for init scripts
Raphael Hertzog <[EMAIL PROTECTED]> writes: > diff --git a/policy.sgml b/policy.sgml > index c9bd84f..772afce 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -5946,9 +5946,11 @@ rmdir /usr/local/share/emacs 2>/dev/null || true > The init.d scripts must ensure that they will > behave sensibly if invoked with start when the > service is already running, or with stop when it > - isn't, and that they don't kill unfortunately-named user > + isn't (in particular, they should not exit with a non-zero > +error code), and that they don't kill unfortunately-named user > processes. The best way to achieve this is usually to use > - start-stop-daemon. > + start-stop-daemon and its --oknodo > +option. > > > Looks good to me, modulo the mixed-tabs-and-spaces indentation problems. Pick one or the other and stick to it. -- \ “When I turned two I was really anxious, because I'd doubled my | `\ age in a year. I thought, if this keeps up, by the time I'm six | _o__) I'll be ninety.” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarify what "sensible behaviour" is for init scripts
El Viernes, 4 de Julio de 2008, Raphael Hertzog escribió: > Ok, this confirms my initial feeling. Changing this in dpkg would require > a wide-scale testing and much effort for little gains since the policy > already require packages to behave sensibly. It seems that some services return 0 and others 1 in the same case: # lighttpd running: ~# /etc/init.d/lighttpd start ; echo $? * Starting web server lighttpd [fail] 1 # apache2 running: ~# /etc/init.d/apache2 start ; echo $? * Starting web server apache2 httpd (pid 8877) already running [ OK ] 0 > Iñaki, if you ever encounter > bad init scripts, please report bugs against the offending packages. In the above case which is the "bad" init script?: - lighttpd uses LSB specs. - apache2 uses Debian specs. Regards. -- Iñaki Baz Castillo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426877: Clarify what "sensible behaviour" is for init scripts
On Fri, 04 Jul 2008, Iñaki Baz Castillo wrote: > # lighttpd running: > ~# /etc/init.d/lighttpd start ; echo $? > * Starting web server lighttpd > [fail] > 1 [...] > > Iñaki, if you ever encounter > > bad init scripts, please report bugs against the offending packages. > > In the above case which is the "bad" init script?: lighttpd obviously. It's not a sensible behaviour to fail when asked to start a service that is already running. > - lighttpd uses LSB specs. This seems to contradict what you told us before about what LSB compliant means for you. :) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
Hi, On Fri, 2008-07-04 at 01:47:39 -0700, Steve Langasek wrote: > > I think being LSB compliant is good for Debian. > > The LSB init script specification *is a specification for the init scripts > of LSB packages*. It has NOTHING to do with LSB compliance of LSB > implementations. Debian is an LSB *implementation*, NOT a collection of LSB > applications. Conforming with the LSB init script specification would NOT > make Debian packages conformant LSB applications! > > The LSB init script spec is a reasonable and internally consistent set of > guidelines for init scripts. It's not a bad policy; in fact, 90% of it is > word-for-word identical with the Debian init script policy. But the LSB > init script spec is *not* the Debian init script policy, and we should not > blindly seek conformance to an LSB *application* spec for its own sake. Agreed. > I happen to be in favor of seeing Debian adopt at least one feature of the > LSB init script spec that we miss, which is the mandatory 'status' argument. > But this needs to be adopted as part of Debian policy itself, through our > normal procedures for such changes. Yeah, this is something I've on my TODO list, most of the needed code is already on s-s-d. Will try to get something working this weekend. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
Steve Langasek wrote: >> I'm reluctant to change the default behaviour of start-stop-daemon at this >> point. What do other people think of making --oknodo the default behaviour >> and adding a new option to force the current default behaviour (exit with >> failure if nothing had to be done)? > > I think this sounds like there's no real transition plan between the two > states; anything that actually relies on the current behavior of s-s-d > without --oknodo will suddenly be broken. Changing the semantics of core > tools in this way is a bad idea. Here a proposal for a transition plan: Before lenny, start-stop-daemon can gain a new option that: - conflict with --oknodo (the new option can be called --no-oknodo for example) - enforce the current behavior with start-stop-daemon In sid, after lenny, start-stop-daemon can be changed to emit a warning if invoked without --oknodo or --no-oknodo. Maintainers must update their scripts. In lenny+1, (ie just before the release of lenny+1) start-stop-daemon revert the previous patch (ie does not show warnings) so that upgrade from lenny (maintainer script without --no-oknodo) to lenny+1 (maintainer scripts with --no-oknodo or --oknodo) does not trigger lots of warnings. In sid, after lenny+1, start-stop-daemon can fail if no option are given (or change its behavior). Another one is: Before lenny, start-stop-daemon can gain a new option that: - conflict with --oknodo (the new option can be called --no-oknodo for example) - enforce the current behavior with start-stop-daemon In sid, after lenny, lintian checks and warns if none of the two options is given. In both case, the goal is to ensure that the maintainer really choose the behavior he wants for start-stop-daemon > The right answer is that we should be fixing the wrong init scripts, not > trying to coerce all the init scripts with a change in s-s-d semantics. An > init script may have a legitimate reason to want to check for the > difference between exit statuses 0 and 1, without necessarily using this > information a way that breaks the init script's own exit status, and > changing s-s-d behavior will break these legitimate use cases. > >> The alternative is to change policy and/or lintian to ensure that packages >> are using --oknodo unless they have a good reason not to. > > This was already discussed on debian-devel in March of this year. > > http://lists.debian.org/debian-devel/2008/03/msg00772.html > > Feel free to propose an amendment to policy that clarifies that "sensible" > behavior is equivalent to --oknodo (without implying that init scripts are > required to use s-s-d!), and I will happily second it; as I already > commented in that thread, I think this is a mere clarification of what the > policy has always been, not a change to policy at all. > >>> [1] LSB specifications about init script actions: >>> http://www.linux-foundation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html > > That one's starting to get up there right next to "our priorities are our > users and free software" on my list of Facile Arguments That Demonstrate The > Poster Has No Clue. :P > -- Vincent Danjean GPG key ID 0x9D025E87 [EMAIL PROTECTED] GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426877: Clarify what "sensible behaviour" is for init scripts
On Fri, Jul 04, 2008 at 11:59:31AM +0200, Raphael Hertzog wrote: > reassign 426877 debian-policy 3.8.0.1 > retitle 426877 Clarify what "sensible behaviour" is for init scripts > thanks > Ok, this confirms my initial feeling. Changing this in dpkg would require > a wide-scale testing and much effort for little gains since the policy > already require packages to behave sensibly. Iñaki, if you ever encounter > bad init scripts, please report bugs against the offending packages. > On Fri, 04 Jul 2008, Steve Langasek wrote: > > Feel free to propose an amendment to policy that clarifies that "sensible" > > behavior is equivalent to --oknodo (without implying that init scripts are > > required to use s-s-d!), and I will happily second it; as I already > > commented in that thread, I think this is a mere clarification of what the > > policy has always been, not a change to policy at all. > Here's a try (against current master branch): Here's a tweak that I think flows a little better: >From 9b94d8928d7e1faff49bfb0280851751792cd403 Mon Sep 17 00:00:00 2001 From: Steve Langasek <[EMAIL PROTECTED]> Date: Fri, 4 Jul 2008 13:28:38 -0700 Subject: [PATCH] better define sensible behavior for init scripts --- policy.sgml | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/policy.sgml b/policy.sgml index c9bd84f..24c9072 100644 --- a/policy.sgml +++ b/policy.sgml @@ -5944,11 +5944,13 @@ rmdir /usr/local/share/emacs 2>/dev/null || true The init.d scripts must ensure that they will - behave sensibly if invoked with start when the - service is already running, or with stop when it - isn't, and that they don't kill unfortunately-named user - processes. The best way to achieve this is usually to use - start-stop-daemon. + behave sensibly (i.e., returning success and not starting + multiple copies of a service) if invoked with start + when the service is already running, or with stop + when it isn't, and that they don't kill unfortunately-named + user processes. The best way to achieve this is usually to + use start-stop-daemon with the --oknodo + option. -- 1.5.6 Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
