Nabble - debian-ctte

Re: Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-30T03:40:18Z

On Tue, Sep 29, 2009 at 04:39:43PM -0600, Bdale Garbee wrote:
> Gerrit, in reviewing the dropbear package source, I couldn't help but
> wonder why /etc/dropbear/log/run specifies ./main as the log file? That
> motivates use of a symlink to point /etc/dropbear/log/main
> to /var/log/dropbear. Wouldn't it be simpler and cleaner to just
> specify /var/log/dropbear as the last argument to svlogd in that script,
> and thus avoid another level of useless indirection?

Yes, possibly. But it's not completely useless, with the symlink in
log/, all service related data is consolidated in one directory. With
runit and daemontools managed services, you can cd into the service
directory, and have all data you need conveniently available without
looking up where which data actually is saved in the filesystem. You
have the service configuration in ./run (and possibly ./config or
similar), the log service configuration in ./log/run, the logs in
./log/main/, and optionally log specific configuration in
./log/main/config. If that's consistent throughout all supervised
services, I personally find that useful.

> Gerrit, in reviewing other instances of runit support, I do find some
> inconsistency in where things are delivered. The fact that dropbear is
> delivering these files to /etc/dropbear but git-daemon-run
> uses /etc/sv/git-daemon seems inconsistent to me, for example. While
> that's completely orthogonal to this request of the Tech Ctte, settling
> on one approach might make it easier for others like me to read and
> comprehend what's being delivered.

True, you're right. I did the dropbear package in 2004, and introduced
/etc/sv/ not before 2006. I didn't move the directory because of two
reasons. (1) moving conffiles was not trivial (in the meantime I have
code in some packages that do that), (2) the dropbear package ships
both, a sysv init script and a runit service directory. sysv users
look for the configuration in /etc/dropbear/, and runit users in
/etc/sv/dropbear/. /etc/dropbear/ holds the host keys which are used
by both service startup methods. I'm not sure whether a symlink
/etc/sv/dropbear -> /etc/dropbear would help, or rather complicate
things again.

Regards, Gerrit.

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Processed: Re: Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-29T15:54:09Z

Processing commands for control@...:

> reassign 548230 dropbear
Bug #548230 [tech-ctte] dropbear: configuration in /etc/<package> does not follow FHS
Bug #545242 [tech-ctte] dropbear: Please patch sources not to use /etc/dropbear/{log,run}
Bug reassigned from package 'tech-ctte' to 'dropbear'.
Bug reassigned from package 'tech-ctte' to 'dropbear'.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-29T15:39:43Z

On Thu, 2009-09-24 at 21:36 +0300, Jari Aalto wrote:

> CONCERNING
>
> "dropbear: Please patch sources not to use /etc/dropbear/{log,run}"
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545242

Jari, it's not a big deal, but for something like this it might be
easier in the future if you re-assigned the existing bug to the
tech-ctte pseudo-package instead of creating a new bug number.

Gerrit, in reviewing the dropbear package source, I couldn't help but
wonder why /etc/dropbear/log/run specifies ./main as the log file? That
motivates use of a symlink to point /etc/dropbear/log/main
to /var/log/dropbear. Wouldn't it be simpler and cleaner to just
specify /var/log/dropbear as the last argument to svlogd in that script,
and thus avoid another level of useless indirection?

I don't immediately see any problem with the other files that are
delivered to /etc/dropbear from an FHS / Debian policy perspective.

Gerrit, in reviewing other instances of runit support, I do find some
inconsistency in where things are delivered. The fact that dropbear is
delivering these files to /etc/dropbear but git-daemon-run
uses /etc/sv/git-daemon seems inconsistent to me, for example. While
that's completely orthogonal to this request of the Tech Ctte, settling
on one approach might make it easier for others like me to read and
comprehend what's being delivered.

Bdale

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Processed: Re: Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-29T11:45:08Z

Processing commands for control@...:

> tag 548230 moreinfo
Bug #548230 [tech-ctte] dropbear: configuration in /etc/<package> does not follow FHS
Bug #545242 [tech-ctte] dropbear: Please patch sources not to use /etc/dropbear/{log,run}
Added tag(s) moreinfo.
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-29T11:43:41Z

tag 548230 moreinfo
thanks

Have Russ's and my comments on this bug made clear the rationale
behind why it doesn't appear to be an FHS violation?

Jari: if you no longer feel that it is an FHS violation, feel free to
reassign this bug back to dropbear and close it; otherwise we'll start
the process of coming to a decision.

Don Armstrong

--
"A one-question geek test. If you get the joke, you're a geek: Seen on
a California license plate on a VW Beetle: 'FEATURE'..."
-- Joshua D. Wachs - Natural Intelligence, Inc.

http://www.donarmstrong.com http://rzlab.ucr.edu

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-24T13:12:11Z

Don Armstrong <don@...> writes:
> On Thu, 24 Sep 2009, Jari Aalto wrote:

>> The problems in the package were identified as follows:
>>
>> (1) /etc/dropbear/run is an executable

> There's nothing wrong with having executables in /etc, so long as they
> are not binaries. /etc/dropbear/run is "a local file used to control
> the operation of a program",[1] so it's perfectly reasonable to have
> it in /etc.

>> (2) /etc/dropbear/log is a symlink pointing to /var/log/dropbear

> If /etc/dropbear/log is a file controling the location of the log
> files (and thus, controling the operation of the program), I don't see
> the problem with the FHS.

I agree. This type of configuration is the best way of handling software
run by daemontools or any of its variations that I think we've come up
with, and seems like a reasonable approach to me. (Better, for instance,
than putting all of the configuration into /var.)

>> 1) Symlinks
>>
>> I: Symlinks are "not real configuration files" as per FHS.

> The FHS doesn't address this point at all; while it may be problematic
> technically for VCS systems without support for symlinks, it's not
> precluded by the FHS. [And given how many symlinks are in /etc, (on my
> laptop, I cound 1430[2]), a VCS which can't handle it isn't going to be
> particularly useful for managing /etc.]

Yup. There are *many* packages in the archive that use symlinks in /etc.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Processed: Re: Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-24T12:42:28Z

Processing commands for control@...:

> reassign 545242 tech-ctte
Bug #545242 {Done: Gerrit Pape <pape@...>} [dropbear] dropbear: Please patch sources not to use /etc/dropbear/{log,run}
Bug reassigned from package 'dropbear' to 'tech-ctte'.
Bug No longer marked as found in versions dropbear/0.52-2.
> forcemerge 548230 545242
Bug#548230: dropbear: configuration in /etc/<package> does not follow FHS
Bug#545242: dropbear: Please patch sources not to use /etc/dropbear/{log,run}
Forcibly Merged 545242 548230.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-24T12:30:11Z

reassign 545242 tech-ctte
forcemerge 548230 545242
thanks

On Thu, 24 Sep 2009, Jari Aalto wrote:
> The problems in the package were identified as follows:
>
> (1) /etc/dropbear/run is an executable

There's nothing wrong with having executables in /etc, so long as they
are not binaries. /etc/dropbear/run is "a local file used to control
the operation of a program",[1] so it's perfectly reasonable to have
it in /etc.

> (2) /etc/dropbear/log is a symlink pointing to /var/log/dropbear

If /etc/dropbear/log is a file controling the location of the log
files (and thus, controling the operation of the program), I don't see
the problem with the FHS.

> 1) Symlinks
>
> I: Symlinks are "not real configuration files" as per FHS.

The FHS doesn't address this point at all; while it may be problematic
technically for VCS systems without support for symlinks, it's not
precluded by the FHS. [And given how many symlinks are in /etc, (on my
laptop, I cound 1430[2]), a VCS which can't handle it isn't going to
be particularly useful for managing /etc.]

> 2) Executables
>
> I: Excutables should not apperar under "/etc/<package>" as per FHS.

The FHS precludes executable binaries from appearing under /etc, not
executables: "it must be static and cannot be an executable binary".[1]

Don Armstrong

1: http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION
2: $ sudo find /etc -type l|wc -l
1432
--
Physics is like sex. Sure, it may give some practical results, but
that's not why we do it.
-- Richard Feynman

http://www.donarmstrong.com http://rzlab.ucr.edu

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#548230: dropbear: configuration in /etc/ does not follow FHS

2009-09-24T11:36:20Z

Package: tech-ctte
Severity: normal

CONCERNING

"dropbear: Please patch sources not to use /etc/dropbear/{log,run}"
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545242

SUMMARY

I'm calling for a decision of reported bug in dropbear: "not to
install anything else than configuration files to /etc."

Maintainer has reject a proposal to move the scrips from
/etc/<package>/ and to remove symlink pointing to directory /var/log

A REQUEST

I'm hoping the committee to examine the FHS and it's appliance in
Debian when there are no strong technical reasons to deviate from
it. I feel that the decision is important and that it will set the
direction how the FHS is to be interpreted in Debian.

I believe, in technical wise, the issues itself are easily
correctable in the package.

DETAILS

The problems in the package were identified as follows:

(1) /etc/dropbear/run is an executable
(2) /etc/dropbear/log is a symlink pointing to /var/log/dropbear

Suggestions made in the bug report to:

(1) Move /etc/dropbear/run to /var/lib/dropbear/run and read
configuration file /etc/dropbear/run.conf. A skeleton code to do
this was provided in the bug report.

(2) Remove /etc/dropbear/log. There is a separate FHS directory
/var/log dedicated for this purpose. If a configurable location for
log files is needed, add a configuration file to control the
location.

RELATED STANDARDS

http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION

The /etc hierarchy contains configuration files. A
"configuration file" is a local file used to control the
operation of a program; it must be static and cannot be an
executable binary.

AGREEMENTS

Both I and maintainer acknowledge that /etc/init.d/ directory is
special and is used for scripts, so the FHS, due to de facto
history, does not apply there.

DISAGREEMENTS

1) Symlinks

I: Symlinks are "not real configuration files" as per FHS. They
can't be put under version control (not all VCS support symlinks).
They can't be "diffed" e.g. to compare two setups. The program can
be designed to read the log directory location from a separate file
that can cotain a line like "logdir = /var/log".

Maintainer: There is no problem. "A symlink" is a valid
configuration file:

/etc/dropbear/log -> /var/log/dropbear

2) Executables

I: Excutables should not apperar under "/etc/<package>" as per FHS.
Similar problems as above. Not all tools can preserve executable
flags: version control, use of zip for backups etc. The executables
can be placed elsewhere; like /var/lib/<package>. The program can
read /etc/<package>/run.conf.

Maintainer: There is no problem. Scripts are "configuration files"
and can be stored in /etc/<package>, They are not FHS-incompatible;
see the precedence e.g. in cases of /etc/init.d.

Jari

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Debian TC representative on the Ubuntu Technical Board

2009-09-22T02:53:09Z

On Tue, Aug 25, 2009 at 01:23:53PM -0600, Bdale Garbee wrote:
> On Tue, 2009-08-25 at 15:30 +0100, Colin Watson wrote:
> > Any word on this? I'd just like to keep the discussion alive.
>
> I was sort of waiting to see if anyone else on the committee jumped in.
> Since they haven't, sign me up, and I'll personally make time at least
> long enough to help define what the role of a Debian representative
> should be and see how this works out...

OK, thanks. I've belatedly subscribed you to the technical-board@ list
(if bdale@... is the wrong address, please shout), and we can
continue the discussion there.

Our IRC meetings are at 1400 UTC on Tuesdays (which I realise is
extremely short notice for you today, so don't worry about that too
much!) on #ubuntu-meeting on Freenode. They're public anyway of course,
but you're very welcome to attend.

Thanks,

--
Colin Watson [cjwatson@...]

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-09-17T14:24:14Z

On 11876 March 1977, Russ Allbery wrote:

> If I were you, I'd probably use a debconf question asking whether or not
> to enable /etc/aliases handling, with the default answer being yes, so
> that people who want the native qmail behavior can disable it. I'm sure
> that's not the only solution to the problem, though, and I've only thought
> about it for a couple of minutes.

Which, for the package layout I know of it, means he has to depend on
fastforward. And he has to move the conflicts/replaces/provides headers.
Or simply do not split it away.

--
bye, Joerg
<miro> Alfie: warum heist du jetzt eigentlich Rhonda?
<maxx> das ist heuer so mode...
<Rhonda> 17:07 <Rhonda> Nein, ich erklärs nicht schon wieder nicht....
<Rhonda> 17:08 <Rhonda> 10mal nicht erklären muss genÃ¼gen.
<maxx> Rhonda ist die FrÃ¼hjahrskollektion von Alfie :)

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-09-17T14:20:02Z

On 11876 March 1977, Gerrit Pape wrote:

> Hi, I'm not sure I'm reading policy correctly. Is it okay to provide
> such a newaliases program
> #!/bin/sh
> cat >&2 <<EOT
> qmail on Debian by default doesn't support the /etc/aliases database,
> but handles mail aliases differently, please see
> http://lifewithqmail.org/lwq.html#aliases
> EOT
> exit 1

> which will be diverted and replaced by a fully functional version if the
> fastforward package is installed? This way users would be able to
> choose which alias mechanism to use easily.

It is only ok if the smtpd does use the information from /etc/aliases
without newaliases doing anything. Nothing allows you to ignore this
file. So no, with the above output it is not ok.

The policy reads:
------------------------------------------------------------------------
/etc/aliases is the source file for the system mail aliases (e.g.,
postmaster, usenet, etc.), it is the one which the sysadmin and postinst
scripts may edit. After /etc/aliases is edited the program or human
editing it must call newaliases. All MTA packages must come with a
newaliases program, even if it does nothing, but older MTA packages did
not do this so programs should not fail if newaliases cannot be
found. Note that because of this, all MTA packages must have Provides,
Conflicts and Replaces: mail-transport-agent control file fields.
------------------------------------------------------------------------

So a `newaliases` doing nothing is OK, but the aliases defined in that
file have to work.

--
bye, Joerg
[Talking about Social Contract]:
We will not discriminate noone[...]
[So we discriminate anyone?]

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-09-17T11:18:58Z

Gerrit Pape <pape@...> writes:

> Hi, I'm not sure I'm reading policy correctly. Is it okay to provide
> such a newaliases program

> #!/bin/sh
> cat >&2 <<EOT
>
> qmail on Debian by default doesn't support the /etc/aliases database,
> but handles mail aliases differently, please see
> http://lifewithqmail.org/lwq.html#aliases
>
> EOT
> exit 1

> which will be diverted and replaced by a fully functional version if the
> fastforward package is installed? This way users would be able to
> choose which alias mechanism to use easily.

My reading of Policy is that an MTA should, by default, correctly handle
aliases defined in /etc/aliases. The MTA may require that newaliases be
called after changes to that file to update internal databases, or
newaliases may be a no-op if the MTA reads the file directly, but either
way modifications made to that file followed by a call to newaliases must
be honored by default.

It's certainly okay for a sysadmin to indicate that they don't want to use
that mechanism and want to use the qmail native mechanism instead.

If I were you, I'd probably use a debconf question asking whether or not
to enable /etc/aliases handling, with the default answer being yes, so
that people who want the native qmail behavior can disable it. I'm sure
that's not the only solution to the problem, though, and I've only thought
about it for a couple of minutes.

I agree that the Policy wording could be less ambiguous about the
requirements placed on the MTA. Right now, it reads mostly as
requirements placed on agents editing /etc/aliases and the statement about
what /etc/aliases is for is presented as a definition rather than as a
requirement. I think the above was the intention, though.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-09-17T02:33:16Z

On Sun, Mar 01, 2009 at 08:32:11PM +0000, Gerrit Pape wrote:

> On Tue, Feb 03, 2009 at 08:32:20AM +0000, Gerrit Pape wrote:
> > (3) I was of the opinion that a dependency chain to a packages that
> > provides the newliases program is enough to conform with the Debian
> > policy, and, since Recommends are install by default, recommending the
> > fastforward package is sufficient, while preserving flexibility. I now
> > see that on systems where exim is installed as default MTA, installing
> > the fastforward package will result in a file conflict. The packages
> > should be adapted, so that the qmail-run package provides the newaliases
> > program.
>
> Actually, with the first set of packages uploaded to ftp-master in April
> 2008, the qmail-run package included a minimal newaliases program (doing
> nothing but output a warning). The fastforward package, if installed,
> diverted and replaced the newaliases program with a full functional
> version, giving users the choice. AFAICS this was compliant with our
> policy, but rejected by ftpmasters[*]. I chose to follow ftpmasters'
> suggestion back then.
>
> Would reverting this change concerning newaliases be acceptable for you,
> and solve the newaliases-issue?
>
> [*] http://smarden.org/pape/Debian/1215531259.4854_332.werc

Hi, I'm not sure I'm reading policy correctly. Is it okay to provide
such a newaliases program

#!/bin/sh
cat >&2 <<EOT

qmail on Debian by default doesn't support the /etc/aliases database,
but handles mail aliases differently, please see
http://lifewithqmail.org/lwq.html#aliases

EOT
exit 1

which will be diverted and replaced by a fully functional version if the
fastforward package is installed? This way users would be able to
choose which alias mechanism to use easily.

Thanks, Gerrit.

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#535645: marked as done (Wrongfull removal of ia32-libs-tools)

2009-09-04T16:57:05Z

Your message dated Fri, 4 Sep 2009 16:47:14 -0700
with message-id <20090904234714.GO12831@...>
and subject line Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools
has caused the Debian Bug report #535645,
regarding Wrongfull removal of ia32-libs-tools
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@...
immediately.)

--
535645: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535645
Debian Bug Tracking System
Contact owner@... with problems

Package: ftp.debian.org
Severity: normal

Hi,

please remove the following 2 binary packages from unstable:

Package: ia32-libs
Version: 21
Filename: pool/main/i/ia32-libs-tools/ia32-libs_21_amd64.deb

Package: ia32-libs-gtk
Version: 21
Filename: pool/main/i/ia32-libs-tools/ia32-libs-gtk_21_amd64.deb

Mark Hymers might (or might not) later reupload the ia32-libs and
ia32-libs-gtk source packages again but meanwhile people shouldn't
install the above anymore.

MfG
Goswin

On Wed, 02 Sep 2009, Don Armstrong wrote:
> I vote 1 2 3.

Since 6 people have voted 1 first, the outcome is no longer in doubt,
so:

The Debian Technical Committee:

1. declines to override the ftp team decision to remove the
ia32-libs-tools package from the archive, finding insufficient technical
justification to warrant an override, and

2. reaffirms the ftp team's authority to exercise their own judgement in
deciding to remove packages from the archive, whenever this is done for
reasons consistent with the twin mandates to keep the archive operational
and to support the archive needs of the Debian Project.

The Committee further recommends:

3. that the ftp team recognize that it's important for maintainers to feel
empowered and in control of their packages, and therefore be willing to
provide, upon a request from any Debian Developer, an accounting of the
objective, measurable, technical conditions that a rejected package must
meet in order to enter the archive, and

4. that the petitioner and ia32-libs-tools package maintainer, Goswin von
Brederlow, solicit the help of an upload sponsor to approach the ftp team
in accordance with 3. above, so that any technical obstacles to this
package's reintroduction to the archive may be laid out for consideration.

is the resolution of this bug.

Don Armstrong

--
J.W. Grant: "Bastard!"
Rico: "Yes, Sir. In my case, an accident of birth. But you, Sir,
you're a self-made man."
-- Henry "Rico" Fardan in "The Professionals"

http://www.donarmstrong.com http://rzlab.ucr.edu

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-03T12:59:52Z

On Wed, Sep 02, 2009 at 09:32:20AM -0700, Don Armstrong wrote:
> On Wed, 02 Sep 2009, Kurt Roeckx wrote:
> > I haven't really been following this, but I don't think the ctte has
> > the power to override a delegate, and last I heard ftp-master was a
> > delegation.
>
> My reading that it does, but only in the case where a delegate is
> implementing a technical policy or decision.

I wasn't sure that allowing a package in the archive is a "technical
policy". But you do have technical reasons why you don't want
it. And you can argue that it doesn't meet the "must not be so
buggy that we refuse to support it" part that allows it in the
archive.

I guess my problem is that the wording seems to indicate this
is under 6.1.4, while you think this is under 6.1.1.

> 6.1.1 empowers the CTTE to make any technical decision, but 6.1.4
> modifies that to require a 3:1 majority when the decision has already
> been made. Furthermore, if 6.1.4 doesn't apply to technical decisions
> of a delegate, than only 6.1.1 applies, and only a simple majority is
> needed.
>
> For example, the policy editors are currently delegated, but 6.1.1
> speaks specifically to policy. In a case where we were going to
> override the policy editors, I think 6.1.4 and 6.1.1 should both
> apply, but I'm certain that 6.1.1 does.

As I understand it, policy is not made by the delegates, it's DDs
that make proposals and approve it, and the delegates are just
there to help the process.

But I think 6.1.1 and 6.1.4 are different things, and 6.1.4 does
not extend/modify 6.1.1. Changes to policy would fall under
6.1.1 and not 6.1.4.

But I guess this is getting a little off topic for here, and is
something we'll deal with when that happens.

Kurt

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-02T11:10:35Z

On Wed, Sep 02, 2009 at 09:32:20AM -0700, Don Armstrong wrote:
> On Wed, 02 Sep 2009, Kurt Roeckx wrote:
> > I haven't really been following this, but I don't think the ctte has
> > the power to override a delegate, and last I heard ftp-master was a
> > delegation.

> My reading that it does, but only in the case where a delegate is
> implementing a technical policy or decision.

Absolutely.

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-02T09:32:20Z

On Wed, 02 Sep 2009, Kurt Roeckx wrote:
> I haven't really been following this, but I don't think the ctte has
> the power to override a delegate, and last I heard ftp-master was a
> delegation.

My reading that it does, but only in the case where a delegate is
implementing a technical policy or decision.

6.1.1 empowers the CTTE to make any technical decision, but 6.1.4
modifies that to require a 3:1 majority when the decision has already
been made. Furthermore, if 6.1.4 doesn't apply to technical decisions
of a delegate, than only 6.1.1 applies, and only a simple majority is
needed.

For example, the policy editors are currently delegated, but 6.1.1
speaks specifically to policy. In a case where we were going to
override the policy editors, I think 6.1.4 and 6.1.1 should both
apply, but I'm certain that 6.1.1 does.

Don Armstrong

--
Let us chat together a moment, my friend. There are still several
hours until dawn, and I have the whole day to sleep.
-- Count Orlock in _Nosferatu (1922)_

http://www.donarmstrong.com http://rzlab.ucr.edu

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-02T09:24:29Z

On Tue, 01 Sep 2009, Steve Langasek wrote:

> I'm calling for votes on this issue. The ballot options are given as short
> summaries of the resolutions; please see the provided links for the full
> text of the resolutions.
>
> 1. Decline to override the ftp team decision to remove ia32-libs-tools
> Message-ID: <20090823065342.GA14135@...>
> http://lists.debian.org/debian-ctte/2009/08/msg00079.html
>
> 2. Require the ftp team to reinstate ia32-libs-tools, or provide more
> information
> Message-ID: <1251227318.5849.738.camel@rover>
> http://lists.debian.org/debian-ctte/2009/08/msg00096.html
>
> 3. Further Discussion

I vote 1 2 3.

Don Armstrong

--
"People selling drug paraphernalia ... are as much a part of drug
trafficking as silencers are a part of criminal homicide."
-- John Brown, DEA Chief

http://www.donarmstrong.com http://rzlab.ucr.edu

signature.asc (196 bytes) Download Attachment

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-02T04:27:30Z

On Tue, Sep 01, 2009 at 09:40:31PM -0700, Steve Langasek wrote:

I haven't really been following this, but I don't think
the ctte has the power to override a delegate, and last
I heard ftp-master was a delegation.

Kurt

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-02T01:39:33Z

* Steve Langasek (vorlon@...) [090902 06:40]:

123

(for those who are interessted I agree that documentation of the
decision wasn't the best, but well - this is not "how to document
decisions best", and I'm not going to vote 213 just to get more
written documentation that won't make any different on what is in the
archive in the end, we're not an bureaucracy)

Cheers,
Andi

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-02T00:27:43Z

On Tue, Sep 01 2009, Steve Langasek wrote:

I vote:
1 2 3

manoj
--
For a man to truly understand rejection, he must first be ignored by a
cat.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

attachment0 (208 bytes) Download Attachment

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-01T23:20:34Z

On Tue, 2009-09-01 at 21:40 -0700, Steve Langasek wrote:

1 2 3

Bdale

signature.asc (196 bytes) Download Attachment

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-01T22:34:45Z

Steve Langasek <vorlon@...> writes:

> I'm calling for votes on this issue. The ballot options are given as
> short summaries of the resolutions; please see the provided links for
> the full text of the resolutions.

> 1. Decline to override the ftp team decision to remove ia32-libs-tools
> Message-ID: <20090823065342.GA14135@...>
> http://lists.debian.org/debian-ctte/2009/08/msg00079.html

> 2. Require the ftp team to reinstate ia32-libs-tools, or provide more
> information
> Message-ID: <1251227318.5849.738.camel@rover>
> http://lists.debian.org/debian-ctte/2009/08/msg00096.html

> 3. Further Discussion

I vote 1 3 2.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

attachment0 (202 bytes) Download Attachment

Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-01T21:54:23Z

On Tue, Sep 01, 2009 at 09:40:31PM -0700, Steve Langasek wrote:
> I'm calling for votes on this issue. The ballot options are given as short
> summaries of the resolutions; please see the provided links for the full
> text of the resolutions.

> 1. Decline to override the ftp team decision to remove ia32-libs-tools
> Message-ID: <20090823065342.GA14135@...>
> http://lists.debian.org/debian-ctte/2009/08/msg00079.html

> 2. Require the ftp team to reinstate ia32-libs-tools, or provide more
> information
> Message-ID: <1251227318.5849.738.camel@rover>
> http://lists.debian.org/debian-ctte/2009/08/msg00096.html

> 3. Further Discussion

I vote: 1 2 3

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools

2009-09-01T21:40:31Z

I'm calling for votes on this issue. The ballot options are given as short
summaries of the resolutions; please see the provided links for the full
text of the resolutions.

1. Decline to override the ftp team decision to remove ia32-libs-tools
Message-ID: <20090823065342.GA14135@...>
http://lists.debian.org/debian-ctte/2009/08/msg00079.html

2. Require the ftp team to reinstate ia32-libs-tools, or provide more
information
Message-ID: <1251227318.5849.738.camel@rover>
http://lists.debian.org/debian-ctte/2009/08/msg00096.html

3. Further Discussion

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Re: Please review proposed resolution: Re: Bug#535645: Wrongfull removal of ia32-libs-tools

2009-09-01T21:40:01Z

On Tue, Sep 01, 2009 at 09:53:26AM +0200, Andreas Barth wrote:
> > > Bdales and mine shouldn't be both on the ballot - Bdale, which one
> > > should be on it?

> > I don't really care. I like the wording of mine better, since it
> > doesn't make stumble over the word 'final'. But I don't expect either
> > to garner many votes, so I'm not inclined to spend more time polishing
> > the text.

> I don't really care either. I too like the wording of mine better -
> but well. Steve, please just put on the ballot whatever you think, but
> not both.

Ok - Bdale's was here first, I'll go with that one. Let's get this vote
moving. :-)

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Re: Please review proposed resolution: Re: Bug#535645: Wrongfull removal of ia32-libs-tools

2009-09-01T00:53:26Z

* Bdale Garbee (bdale@...) [090830 17:52]:

> On Sun, 2009-08-30 at 10:23 +0200, Andreas Barth wrote:
> > * Steve Langasek (vorlon@...) [090830 09:09]:
> > > On Thu, Aug 27, 2009 at 11:48:14PM +0200, Andreas Barth wrote:
> > > > * Bdale Garbee (bdale@...) [090825 21:09]:
> > > > > So, let's have three choices. Steve's resolution, further discussion,
> > > > > and a re-stated version of Goswin's option along these lines:
> > >
> > > > > agrees that there was insufficient justification to remove the
> > > > > ia32-libs-tools package from the archive. The ftp team is
> > > > > therefore directed to, within one week of the conclusion of this
> > > > > vote, either reinstate the package to the archive, or petition
> > > > > the technical committee to reconsider this issue by
> > > > > communicating further justification for their original decision.
> > >
> > > > How about:
> > > > ... archive, or provide the maintainer and the technical committee
> > > > further justification for their original decision. In that case the
> > > > committee will make another final decision on this topic, considering
> > > > the justifications.
> > >
> > > Is there an agreement about which of these to put on the ballot, or should I
> > > include each of these proposals separately?
> >
> > Bdales and mine shouldn't be both on the ballot - Bdale, which one
> > should be on it?
>
> I don't really care. I like the wording of mine better, since it
> doesn't make stumble over the word 'final'. But I don't expect either
> to garner many votes, so I'm not inclined to spend more time polishing
> the text.

I don't really care either. I too like the wording of mine better -
but well. Steve, please just put on the ballot whatever you think, but
not both.

Cheers,
Andi
>

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Please review proposed resolution: Re: Bug#535645: Wrongfull removal of ia32-libs-tools

2009-08-30T08:52:10Z

On Sun, 2009-08-30 at 10:23 +0200, Andreas Barth wrote:

> * Steve Langasek (vorlon@...) [090830 09:09]:
> > On Thu, Aug 27, 2009 at 11:48:14PM +0200, Andreas Barth wrote:
> > > * Bdale Garbee (bdale@...) [090825 21:09]:
> > > > So, let's have three choices. Steve's resolution, further discussion,
> > > > and a re-stated version of Goswin's option along these lines:
> >
> > > > agrees that there was insufficient justification to remove the
> > > > ia32-libs-tools package from the archive. The ftp team is
> > > > therefore directed to, within one week of the conclusion of this
> > > > vote, either reinstate the package to the archive, or petition
> > > > the technical committee to reconsider this issue by
> > > > communicating further justification for their original decision.
> >
> > > How about:
> > > ... archive, or provide the maintainer and the technical committee
> > > further justification for their original decision. In that case the
> > > committee will make another final decision on this topic, considering
> > > the justifications.
> >
> > Is there an agreement about which of these to put on the ballot, or should I
> > include each of these proposals separately?
>
> Bdales and mine shouldn't be both on the ballot - Bdale, which one
> should be on it?

I don't really care. I like the wording of mine better, since it
doesn't make stumble over the word 'final'. But I don't expect either
to garner many votes, so I'm not inclined to spend more time polishing
the text.

Bdale

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Please review proposed resolution: Re: Bug#535645: Wrongfull removal of ia32-libs-tools

2009-08-30T01:23:10Z

* Steve Langasek (vorlon@...) [090830 09:09]:

> On Thu, Aug 27, 2009 at 11:48:14PM +0200, Andreas Barth wrote:
> > * Bdale Garbee (bdale@...) [090825 21:09]:
> > > So, let's have three choices. Steve's resolution, further discussion,
> > > and a re-stated version of Goswin's option along these lines:
>
> > > agrees that there was insufficient justification to remove the
> > > ia32-libs-tools package from the archive. The ftp team is
> > > therefore directed to, within one week of the conclusion of this
> > > vote, either reinstate the package to the archive, or petition
> > > the technical committee to reconsider this issue by
> > > communicating further justification for their original decision.
>
> > How about:
> > ... archive, or provide the maintainer and the technical committee
> > further justification for their original decision. In that case the
> > committee will make another final decision on this topic, considering
> > the justifications.
>
> Is there an agreement about which of these to put on the ballot, or should I
> include each of these proposals separately?

Bdales and mine shouldn't be both on the ballot - Bdale, which one
should be on it?

Cheers,
Andi

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Please review proposed resolution: Re: Bug#535645: Wrongfull removal of ia32-libs-tools

2009-08-30T00:08:57Z

On Thu, Aug 27, 2009 at 11:48:14PM +0200, Andreas Barth wrote:
> * Bdale Garbee (bdale@...) [090825 21:09]:
> > So, let's have three choices. Steve's resolution, further discussion,
> > and a re-stated version of Goswin's option along these lines:

> > agrees that there was insufficient justification to remove the
> > ia32-libs-tools package from the archive. The ftp team is
> > therefore directed to, within one week of the conclusion of this
> > vote, either reinstate the package to the archive, or petition
> > the technical committee to reconsider this issue by
> > communicating further justification for their original decision.

> How about:
> ... archive, or provide the maintainer and the technical committee
> further justification for their original decision. In that case the
> committee will make another final decision on this topic, considering
> the justifications.

Is there an agreement about which of these to put on the ballot, or should I
include each of these proposals separately?

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment

Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-08-29T03:49:24Z

* Aníbal Monsalve Salazar (anibal@...) [090829 12:39]:
> On Sat, Aug 29, 2009 at 11:46:05AM +0200, Kurt Roeckx wrote:
> >[...]
> >I think it's clear that option 3 wins.
>
> Your message wasn't signed.

Where does the constitution require this? It also isn't required at
all that somebody does summarize the vote.

Cheers,
Andi

--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-08-29T03:17:32Z

On Sat, Aug 29, 2009 at 11:46:05AM +0200, Kurt Roeckx wrote:
>[...]
>I think it's clear that option 3 wins.

Your message wasn't signed.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-08-29T02:46:05Z

On Thu, Aug 20, 2009 at 09:00:47PM -0700, Don Armstrong wrote:

>
> I'm calling for a vote on the following options[1]:
>
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> |
> | Qmail is subject to the normal removal process for packages.
> |
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> |
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> |
> | Qmail is subject to the normal removal process for packages.
> |
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> |
> | 4. Qmail is not to be allowed into Debian.
> |
> | 5. Further discussion.

We have 6 of the 7 votes now:
32145 rra
32145 don
31245 srivasta
53421 vorlon
34215 aba
12354 bdale

Note that the constitution has a 1 week voting period for this.
Bdale's mail is about 1 week and 1 day after don's CfV, but
couting it or not doesn't seem to make any difference.

This seems to fall under constitution 6.1.3, and so
has a normal 1:1 majority requirement.

There is a quorum of 2, all option reach quorum.

All option also reach the 1:1 majority requirement.

I think it's clear that option 3 wins.

Kurt

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

2009-08-28T14:33:20Z

On Fri, Aug 28, 2009 at 08:40:08PM +0200, Florian Weimer wrote:

> > On Tue, Feb 03, 2009 at 08:32:20AM +0000, Gerrit Pape wrote:
> >> 2.1 I'd suggest not to change that, it's a good compromise between
> >> performance and reliability.

> > 2.1. Bounce message contents are not crash-proof.

> > Qmail does not value the contents of a bounce message. Dan documents this
> > in a subordinate clause of his qmail reliability FAQ. That means: if your
> > qmail is bouncing mail and at the same time, your system crashes, the
> > bounce mail contents may be corrupt or incomplete.

> > This sounds like data loss, which is normally considered a grave bug per
> > <http://www.debian.org/Bugs/Developer>. Do people disagree that this is a
> > grave bug?

> Yes. Most of our MTAs deliberately truncate bounce messages.

"deliberately truncate" != "mangle to the point that there is insufficient
identifying information remaining". If you're assuring me that the latter
doesn't happen, then I'm satisfied; but none of the information provided so
far establishes this.

> And arguing with RFC 3461 is a bit problematic because our default MTA
> doesn't implement that RFC.

Well, I wasn't the one who introduced the reference to RFC 3461...

--
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 Developer http://www.debian.org/
slangasek@... vorlon@...

signature.asc (844 bytes) Download Attachment