Re: Converting to source format "3.0 (quilt)"
Raphael Hertzog <[EMAIL PROTECTED]> writes: > Yes, it means that packages not using quilt and without upstream > changes in the .diff.gz have an empty quilt series. Thanks for that clarification. Nevertheless, an obviously useful exercise, leading to some concrete guidelines. Thank you! -- \ “I have one rule to live by: Don't make it worse.” —Hazel | `\ Woodcock | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
On Thu, Jul 03, 2008 at 10:40:53PM +0200, Raphael Hertzog wrote: > > The option "--oknodo" changes the behaviour to the LSB recomendations but > > many services in Debian don't use this option and return 1 in the case > > I've quotted. This is very problematic for me when I try to use a Debian > > service init script with HeartBeat that expects to receive a 0. > 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. 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 -- 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]
Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
Right, expanding on my previous comments: On Thu, Jul 03, 2008 at 11:02:13PM +0200, Iñaki Baz Castillo wrote: > > The alternative is to change policy and/or lintian to ensure that packages > > are using --oknodo unless they have a good reason not to. > > > [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 > 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. 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. Otherwise, we end up with maintainers blindly believing that everything in the LSB init script spec is a good idea, including things like this gem from 20.8: Conforming scripts shall not specify the "exit on error" option (i.e. set -e) when sourcing this file, or calling any of the commands thus made available. Blech. -- 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]
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]
Bug#489235: ITP: libsvn-dump-perl -- A Perl interface to Subversion dumps
Package: wnpp
Severity: wishlist
Owner: Edi Stojicevic <[EMAIL PROTECTED]>
* Package name: libsvn-dump-perl
Version : 0.04
Upstream Author : Philippe Bruhat (BooK)
* URL : http://search.cpan.org/dist/SVN-Dump-0.04/lib/SVN/Dump.pm
* License : GPL
Programming Lang: Perl
Description : A Perl interface to Subversion dumps
An SVN::Dump object represents a Subversion dump.
This module follow the semantics used in the reference document (the file
notes/fs_dumprestore.txt in the Subversion source tree):
* A dump is a collection of records (SVN::Dump::Record objects).
* A record is composed of a set of headers (a SVN::Dump::Headers object), a
set of properties (a SVN::Dump::Property object) and an optional bloc of text
(a SVN::Dump::Text object).
* Some special records (delete records with a Node-kind header) recursively
contain included records.
Each class has a as_string() method that prints its content in the dump format.
The most basic thing you can do with SVN::Dump is simply copy a dump:
use SVN::Dump;
my $dump = SVN::Dump->new( 'mydump.svn' );
print $dump->as_string(); # only print the dump header
while( $rec = $dump->next_record() ) {
print $rec->as_string();
}
After the operation, the resulting dump should be identical to the original
dump.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.25-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489236: ITP: faumachine -- virtual machine running in user mode
Package: wnpp Severity: wishlist Owner: Stefan Potyra <[EMAIL PROTECTED]> * Package name: faumachine Version : 0.2008.1 Upstream Author : FAUmachine Team <[EMAIL PROTECTED]> * URL : http://www.faumachine.org/ * License : GPL Programming Lang: C Description : virtual machine running in user mode FAUmachine is a virtual machine like QEMU. However its main focus is to simulate the real hardware as close as possible. FAUmachine comes with the ability to inject faults to different hardware simulators, e.g. to inject intermittant or transient faults to the simulated disk or the simulated memory. FAUmachine also comes with an experiment controller, with which automated tests, e.g. like installing an operating system from an iso image. (Note: first a new upstream version needs to be released. Also there is one file with unclear licensing in it; I've contacted the original authors so far, but am still waiting on a response). -- 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: ITP: password -- little ruby random password generator
On Fri, Jul 04, 2008 at 01:15:19PM +0800, Paul Wise wrote: > On Fri, Jul 4, 2008 at 11:05 AM, Ryan Kavanagh <[EMAIL PROTECTED]> wrote: > > > * Package name: password > > Description : Compact ruby random password generator > > > > Little random password generator which generates a random > > password which is strong, safe and secure. > > pwgen already exists. > And gpw for pronaunceable passwords. If it did not add anything new I would avoid to add a new password generator just because it is written in Ruby instead of plain C. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
Intent to NMU tinyproxy
(please respect Mail-Followup-To:, as I'm not subscribed to this list) Hi, I've worked on some improvements to the tinyproxy package, and I'm looking for reviewers before I upload this to unstable. My main interest in NMUing this was enabling transparent proxy support to the package, but after seeing the last maintainer upload was over four years ago and there was room for several other packaging improvements, I went ahead and fixed many other things. I need advice on what to do about the version number. Debian's current version is 1.6.3-2.1, and my NMU should be -2.2. However, it seems Ubuntu uploaded -3 as a fork of Debian's -2 by mistake some time ago, so our NMU changes aren't getting synced in Ubuntu releases. Should I ignore this or should I artificially bump the version number to something greater than Ubuntu's, allowing them to sync our changes? If the latter, should I use -3.0, -3.1, -3.2? Currently I'm using -3.2. I have uploaded i386 binaries and source to http://people.debian.org/~jordi/debian, along with an (unreadable) interdiff which shows that all patches have been moved to debian/patches. List of changes is in http://people.debian.org/~jordi/debian/tinyproxy_1.6.3-3.2_i386.changes Please test and/or comment, as my usage of tinyproxy is quite simple and limited. Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ signature.asc Description: Digital signature
Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
On Thu, Jul 03, 2008 at 11:02:13PM +0200, Iñaki Baz Castillo wrote: > I think being LSB compliant is good for Debian. That may be so; but changing a long-standing interface with no migration is /not/ good for Debian. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489278: ITP: ratproxy -- passive web application security assessment tool
Package: wnpp Severity: wishlist Owner: Patrick Schoenfeld <[EMAIL PROTECTED]> * Package name: ratproxy Version : 1.51 Upstream Author : Michal Zalewski <[EMAIL PROTECTED]> (Copyright: 2007, 2008 by Google) * URL : http://code.google.com/p/ratproxy/ * License : Apache License, Version 2.0 Programming Lang: C Description : passive web application security assessment tool A semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments. Detects and prioritizes broad classes of security problems, such as dynamic cross-site trust model considerations, script inclusion issues, content serving problems, insufficient XSRF and XSS defenses, and much more. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489282: ITP: ratproxy -- web application security audit tool
Package: wnpp Severity: wishlist Owner: Iustin Pop <[EMAIL PROTECTED]> * Package name: ratproxy Version : 1.51 Upstream Author : Michal Zalewski <[EMAIL PROTECTED]> * URL : http://code.google.com/p/ratproxy/ * License : Apache-2.0 Programming Lang: C Description : web application security audit tool A semi-automated, largely passive web application security audit tool, ratproxy is optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments. It detects and prioritizes broad classes of security problems, such as dynamic cross-site trust model considerations, script inclusion issues, content serving problems, insufficient XSRF and XSS defenses, and much more. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.8-teal (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should DMs be allowed to upload to NEW
On Wed, Apr 16, 2008 at 4:53 PM, Romain Beauxis <[EMAIL PROTECTED]> wrote: > Le Wednesday 16 April 2008 15:44:56 Neil Williams, vous avez écrit : >> An upload of a new application is nowhere near as complex as the upload >> to start a library SONAME transition. Even uploading a new library never >> seen in Debian before is easier than starting a SONAME transition for a >> library that already exists. I'm sorry, merely by equating those two you >> have lost all credibility in my eyes. > > Why should he have to gain any credibility in your eyes ? Were you about to > help him dealing with this ? > >> It's not just about trust, it is about coordination, planning and >> ability. If you think that a SONAME transition is no more disruptive >> than a new application then I have cause to worry about your ability to >> maintain a library in Debian in the first place. It doesn't give me any >> confidence in you or in DMs in general. > > Well, ok SONAME is a dangerous thing, warning, warning !! > > In the mean time, it's still possible for a DM to upload a different soname in > the same binary package, which would result in an even worse mess, right ? > > I don't like your tone, it's pedantic, because somehow it's legitimate to ask > this kind of questions regarding the potential harm he already has the right > to do with the DM upload rights. And I believe you didn't even look at his > package (neither did I by the way...) In the meantime the package was fixed by a DD with enough upload rights. But let me explain the situation: Libmesh is a library whose last version in debian at the time of writing the above email was 0.6.1, and the binary packages are called libmesh0.6.1 - libMesh - A C++ Finite Element Library libmesh0.6.1-dev - libMesh - A C++ Finite Element Library libmesh0.6.1-pure - libMesh - A C++ Finite Element Library libmesh0.6.1-pure-dev - libMesh - A C++ Finite Element Library now upstream has released libmesh0.6.2, so the packages will be named libmesh0.6.2. Those were already uploaded to Debian, so all is fine. The thing is that upstream releases, e.g. 0.6.2 and 0.6.1 are not really binary compatible, so one has to bump the soname. The above scheme is the same as for the petsc packages: packages.debian.org/petsc So new upstream versions of these packages always go to NEW. Ondrej
Re: 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]
Re: 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]
Re: 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]
Re: Intent to NMU tinyproxy
Jordi Mallach dijo [Fri, Jul 04, 2008 at 06:25:58PM +0200]: > (please respect Mail-Followup-To:, as I'm not subscribed to this list) > > Hi, > > I've worked on some improvements to the tinyproxy package, and I'm > looking for reviewers before I upload this to unstable. > > My main interest in NMUing this was enabling transparent proxy support > to the package, but after seeing the last maintainer upload was over > four years ago and there was room for several other packaging > improvements, I went ahead and fixed many other things. > > I need advice on what to do about the version number. Given the above mentioned factors (mainly, you are adding functionality and not just fixing a bug, and the maintainer is not at all active), I'm sure you have tried to ping Ed Boraas on this regard. Why don't you take over the package? I think everybody will be better off that way... (of course, keeping Ed in the Cc: - Ed, are you still interested in this package? Would you oppose Jordi taking over?) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgpPdBx0ys087.pgp Description: PGP signature
Re: Intent to NMU tinyproxy
Hi, On Fri, Jul 04, 2008 at 02:08:23PM -0500, Gunnar Wolf wrote: > Given the above mentioned factors (mainly, you are adding > functionality and not just fixing a bug, and the maintainer is not at > all active), I'm sure you have tried to ping Ed Boraas on this > regard. Why don't you take over the package? I think everybody will be > better off that way... No, the first time I've contacted Ed was with my previous email, actually. I did check in the PTS and his activity in the last two or three years is quite low. I don't think I want or should take over the package. The time I can devote to Debian is really scarce these days and I should actually get rid of Debian duties, other than accepting new ones. :) > (of course, keeping Ed in the Cc: - Ed, are you still interested in > this package? Would you oppose Jordi taking over?) If Ed agrees with handing the package over, I can orphan it and do a QA upload, or post a RFA. That would fix the Ubuntu issue I mentioned, too, as they would only need to do a no-change rebuild to get it in sync. If Ed doesn't react, maybe orphaning it is best after all. Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ signature.asc Description: Digital signature
FHS location for locally-compiled bytecode (was: FHS location for Python libraries as locally-compiled bytecode)
A little while ago on debian-python, we discussed the location of system files that are executable bytecode, created by package management tools at install time, and how to comply with th FHS. Ben Finney <[EMAIL PROTECTED]> writes: > Josselin Mouette <[EMAIL PROTECTED]> writes: > > > As for the FHS argument, I don’t feel strongly for putting > > [compiled Python bytecode] files in /var/lib, it just seemed like > > the most obvious location as this is data that can be regenerated > > at any time. It can be changed very easily if there is consensus > > that another place is better. > > FHS 2.3 §4 allows for: > > /usr/lib : Alternate format libraries (optional) > > Purpose > > /usr/lib performs the same role as /usr/lib for an alternate > binary format, except that the symbolic links > /usr/lib/sendmail and /usr/lib/X11 are not required. > [26] > > "Python source code" versus "compiled Python bytecode" certainly > qualifies as "an alternative binary format", so this seems the most > applicable section of the FHS. > > Would '/usr/libcompiled/' or '/usr/libbytecode/' be an appropriate > hierarchy to place locally-compiled bytecode for package-installed > software? > > > What I do feel strongly for, is putting them in a directory that > > remains separate from /usr/lib/python2.X. > > Thanks for your convincing argument, I'm now in support of this much. This issue applies just as much to other packages with byte-compiled languages (e.g. Elisp bytecode, Java bytecode, etc.) so I'm raising it on debian-devel. I'm strongly of the position that files which should not be changing (except at package-install time) should not be anywhere under '/var', as per the FHS definition of that hierarchy. These files aren't "regenerated at any time", instead they are generated once and are then executable bytecode for the installed program that should not change until the package itself changes. Instead, program bytecode compiled on package installation should be under '/usr/lib' as per FHS 2.3 §4. I agree with Josselin that they don't belong in '/usr/lib' itself. I don't know what a good name for such a "compiled program bytecode" hierarchy would be; my reading of FHS 2.3 doesn't suggest a good name. Perhaps '/usr/libbytecode'? -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but why would anyone want to see Snow White and the | _o__) Seven Samurai?” —_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not stopping daemons, where are we?
[Marvin Renich] > If the package does need to save state, don't enable the "quick halt" > option! The maintainer definitely ought to know this. Why are all of you talking as though sending SIGTERM were not the standard way to tell a process to save its state and exit gracefully? It's certainly the method I would use if I were writing a program that needed to do things at exit time. I thought everyone did it that way. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
