Hmm, all the trouble of discussing and voting, and then nobody tallies the
ballots. :) FWIW, this was brought to my attention because I was consulted
on a similar bug report on /another/ package, so I think we ought to get
these results up on the webpage where they can be pointed at.
>From <[EMAI
Florian Weimer writes ("Re: Bug#412976 repoened - reassign tech-ctte (mixmaster
/etc/default/*)"):
> The manpage also says:
> | System administrators are not encouraged to use update-rc.d to manage
> | runlevels.
>
> My experience with update-rc.d has been mixed at best
* Kurt Roeckx:
> On Sun, Dec 02, 2007 at 10:10:38PM +, Ian Jackson wrote:
>> Florian Weimer writes ("Re: Bug#412976 repoened - reassign tech-ctte
>> (mixmaster /etc/default/*)"):
>> > Really? Won't upgrades re-enable disabled services if update-rc.d
* Ian Jackson ([EMAIL PROTECTED]) [071206 20:08]:
> For the avoidance of any doubt, I don't think that decisions of the TC
> should be interpreted as overruling the maintainer unless that is the
> only possible interpretation of the resolution's text.
>
> In the past it has always been clearly sta
Steve Langasek writes ("Re: Call for Votes (Re: mixmaster /etc/default/*)"):
> On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote:
> > [1] Choice K: Keep current behaviour and existing policy, as above.
> > [2] Choice F: Further discussion
>
> I agree
Andreas Barth writes ("Re: Call for Votes (Re: mixmaster /etc/default/*)"):
> I assume the voting means "we are not overriding the maintainer", i.e.
> this vote doesn't restrict the right of the maintainer to adjust the
> behaviour as he considers appropriate.
Anthony Towns writes ("Re: Call for Votes (Re: mixmaster /etc/default/*)"):
> This bug hasn't been reassigned to the committee so we don't have any
> business ruling on it.
?
That seems to be an oversight on the part of the petitioner.
For the record, I agree with ev
* Ian Jackson ([EMAIL PROTECTED]) [071202 23:14]:
> -8<-
>
> (1) The REMAIL option should not be supplanted or supplemented by
> anything in an /etc/default file. The current behaviour of the
> mixmaster init script, to examine /etc/mixmaster/remailer.conf's
> REMAIL option, is c
On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote:
> -8<-
> (1) The REMAIL option should not be supplanted or supplemented by
> anything in an /etc/default file. The current behaviour of the
> mixmaster init script, to examine /etc/mixmaster/remailer.conf's
> REMAIL opt
On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote:
> (1) The REMAIL option should not be supplanted or supplemented by
> anything in an /etc/default file. The current behaviour of the
> mixmaster init script, to examine /etc/mixmaster/remailer.conf's
> REMAIL option, is c
On Sun, 2 Dec 2007 22:13:38 +, Ian Jackson
<[EMAIL PROTECTED]> said:
> I hereby call for a vote on the resolution below, which I sent round a
> draft of on Friday and formally proposed yesterday:
-8> -
> (1) The REMAIL option should not be supplanted or supplemented by
> anything in
Kurt Roeckx writes ("Re: Bug#412976 repoened - reassign tech-ctte (mixmaster
/etc/default/*)"):
> It is documented in the update-rc.d manpage:
>If any files /etc/rcrunlevel.d/[SK]??name already exist then
>update- rc.d does nothing. The program was written t
On Sun, Dec 02, 2007 at 10:10:38PM +, Ian Jackson wrote:
> Florian Weimer writes ("Re: Bug#412976 repoened - reassign tech-ctte
> (mixmaster /etc/default/*)"):
> > Really? Won't upgrades re-enable disabled services if update-rc.d is
> > used?
>
> Onl
I hereby call for a vote on the resolution below, which I sent round a
draft of on Friday and formally proposed yesterday:
-8<-
(1) The REMAIL option should not be supplanted or supplemented by
anything in an /etc/default file. The current behaviour of the
mixmaster init script, to e
Florian Weimer writes ("Re: Bug#412976 repoened - reassign tech-ctte (mixmaster
/etc/default/*)"):
> Really? Won't upgrades re-enable disabled services if update-rc.d is
> used?
Only if you delete _all_ of the links. If you leave the K links in
the shutdown and reboot run
* Marc Haber:
> On Sat, Dec 01, 2007 at 07:34:58PM +0200, Jari Aalto wrote:
>> >From Admin's point of view dealing with symlinks is much more
>> uncomfortable to control the initial start/stop status.
>
> If one is not comfortable with a sysvinit scheme, one should not be
> adminning a Debian syst
Anthony Towns writes ("Re: mixmaster /etc/default/*"):
> No, I'm saying that we shouldn't be in the business of reviewing every
> disagreement in Debian. And we certainly shouldn't leave the decision
> as to whether we'll review any particular decision solel
On Sun, Dec 02, 2007 at 02:37:43AM -0800, Don Armstrong wrote:
> > No it doesn't, it just requires not noticing an issue -- eg, by it
> > not being brought to the tech ctte's attention at all (most
> > decisions in Debian), or by the tech ctte missing it when it is
> > (429761, 439006), or by the t
On Fri, Nov 30, 2007 at 07:38:00PM +, Ian Jackson wrote:
> Having read the bug report I don't think there is very much to be said
> in favour of the submitter's point of view.
> Here is a draft resolution and rationale.
> -8<-
> (1) The REMAIL option should not be supplanted or supplemente
On Sun, 02 Dec 2007, Anthony Towns wrote:
> On Fri, Nov 30, 2007 at 06:40:36PM -0800, Don Armstrong wrote:
> > Deciding that an issue isn't important enough to make a decision
> > requires making some sort of decision.
>
> No it doesn't, it just requires not noticing an issue -- eg, by it
> not b
On Fri, Nov 30, 2007 at 06:40:36PM -0800, Don Armstrong wrote:
> Deciding that an issue isn't important enough to make a decision
> requires making some sort of decision.
No it doesn't, it just requires not noticing an issue -- eg, by it not
being brought to the tech ctte's attention at all (most
On Sat, Dec 01, 2007 at 06:19:00PM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: mixmaster /etc/default/*"):
> > This is exactly the sort of thing I think we should simply ignore rather
> > than issue any sort of ruling on. It's simply not important enough
On Sat, Dec 01, 2007 at 07:34:58PM +0200, Jari Aalto wrote:
> >From Admin's point of view dealing with symlinks is much more
> uncomfortable to control the initial start/stop status.
If one is not comfortable with a sysvinit scheme, one should not be
adminning a Debian system. Alternatives (such a
Ian Jackson writes ("Re: mixmaster /etc/default/*"):
> Anthony Towns writes ("Re: mixmaster /etc/default/*"):
> > This is exactly the sort of thing I think we should simply ignore rather
> > than issue any sort of ruling on. It's simply not important enoug
Thanks to Jari for confirming agreement with Peter Palfrader's
summary, and for clarifying what is being requested. I don't think
anything more needs to be said about this.
So I hereby formally propose the draft resolution below. I'll give
other members of the TC a few days to weigh in (in parti
Anthony Towns writes ("Re: mixmaster /etc/default/*"):
> This is exactly the sort of thing I think we should simply ignore rather
> than issue any sort of ruling on. It's simply not important enough to
> be an issue. ie, unless someone on the tech ctte wants to champion th
* Fri 2007-11-30 Ian Jackson <[EMAIL PROTECTED]> INBOX
> Peter Palfrader writes ("Re: Bug#412976 repoened - reassign tech-ctte
> (mixmaster /etc/default/*)"):
>
>> Summary of current status:
>>
>> o The mixmaster package provides both the client an
On Sat, 01 Dec 2007, Anthony Towns wrote:
> On Fri, Nov 30, 2007 at 07:38:00PM +, Ian Jackson wrote:
> > Having read the bug report I don't think there is very much to be said
> > in favour of the submitter's point of view.
>
> This is exactly the sort of thing I think we should simply ignore
On Fri, Nov 30, 2007 at 07:38:00PM +, Ian Jackson wrote:
> Having read the bug report I don't think there is very much to be said
> in favour of the submitter's point of view.
This is exactly the sort of thing I think we should simply ignore rather
than issue any sort of ruling on. It's simply
Having read the bug report I don't think there is very much to be said
in favour of the submitter's point of view.
Here is a draft resolution and rationale.
Ian.
-8<-
(1) The REMAIL option should not be supplanted or supplemented by
anything in an /etc/default file. The current behaviou
Peter Palfrader writes ("Re: Bug#412976 repoened - reassign tech-ctte
(mixmaster /etc/default/*)"):
> Summary of current status:
>
> o The mixmaster package provides both the client and server functionality.
> o By default the server part (running a remailer) is not ena
On Thu, Nov 29, 2007 at 02:07:47PM +0200, Jari Aalto wrote:
> [BTS control messages were sent separately]
AFAICS that didn't actually happen...
> To ease the burden on the system administrator, such
> configurable values should not be placed directly in the script.
> !In
* Joerg Jaspert [Thu, 29 Nov 2007 13:54:35 +0100]:
> The maintainer is (IMO) right to deny your request.
Agreed.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
British policemen don't wear gu
On Thu, 29 Nov 2007, Jari Aalto wrote:
> [BTS control messages were sent separately]
[apparently not yet, but I'll provide a summary anyway.]
Summary of current status:
o The mixmaster package provides both the client and server functionality.
o By default the server part (running a remailer) is
On 11218 March 1977, Jari Aalto wrote:
> to decide if the daemon will start at boot or via "start" command.
If you do not want something to start - remove the startup links. Thats
what those links are for. Everything else is just a broken thing.
The maintainer is (IMO) right to deny your requ
[BTS control messages were sent separately]
I ask resolution for the following dispute
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412976
Please find resolution to the dispute where a bug was filed to ask
to use /etc/default/mixmaster to control the daemon start/stop
behavi
36 matches
Mail list logo
