I should drop out

[Raul Miller]

I believe I should be dropped from the committee.

I have not been able to schedule adequate time to research issues,
and this is not likely to change in the near future.

I am willing to stay on, but would very much like to see that
we find someone with more available energy for committee
issues than I (and an eye towards pushing stability into the
interfaces and complexity into the data).

Comments?

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#413926: Results of technical committee vote

[Raul Miller]

I apologize for not voting, but while I generally concur with
the voted decision, I have not had time to study any of
our issues in any depth these last couple weeks.

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#413926: wordpress: Should not ship with Etch

[Raul Miller]

On 3/12/07, Steve Langasek <[EMAIL PROTECTED]> wrote:

Hmm -- if it's the RMs' call, I guess that means Andi and I both are
required to abstain from any vote on this (Constitution 6.3.2).  Is it still
ok for me to call for a vote? :)  (FWIW, as RM the decision I consider to
have made is "defer to the judgement of the security team", so I guess the
TC does have a choice on who to overrule...)


I can think of no reason [constitutional or otherwise] why you should not be
allowed to call for a vote for the rest of the committee to
[potentially] override
you.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Pending tech-ctte items

[Raul Miller]

It seems to me that four votes in favor and two against is
sufficient for a resolution to pass.

That I personally didn't like that resolution doesn't seem
to me to be sufficient grounds to say it failed.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#402772: marked as done (downgrade mplayer bug 395252 (for including mplayer in etch))

[Raul Miller]

On 12/16/06, Debian Bug Tracking System <[EMAIL PROTECTED]> wrote:

Andi and I are agreed that this is a suitable solution given the evident
approval of the security team.  I'm tagging bug #395252 etch-ignore with
this mail (which means solving this *is* regarded as release critical for
lenny), which means that, AFAICS, there is no longer a matter for the TC to
rule on so I'm also closing that bug.


After reading over the discussion on this issue, I think that this should
not be a release critical bug for lenny.

In essence, what we're dealing with here is an artifact of naming.  There's
ffmpeg the binary, ffmpeg the shared library, and ffmpeg the internal
module of mplayer.  With the current development efforts, each of those
three has valid reasons to exist, but in terms of packaging I think the shared
library should be thought of as a fork of the internal module.

I can see changing this point of view, should the development scene
change.  But I do not see that this is worth release critical status
if we don't have any decent development effort track record to fall
back on.

Techically speaking: the optimization underlying this policy is premature,
in this context.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Renewed appeal to the technical committee about the FransAndCo.Vs.Sven dispute

[Raul Miller]

On 11/24/06, Sven Luther <[EMAIL PROTECTED]> wrote:

First, what is the issue exactly. I am totally at a loss to understand what it
is exactly what is reproached me, and feel that i am unfairly handled.


I'm going to try to tackle this:

In simplest form, [and limiting the context to Debian] the issue is "listening".

Of course, that's somewhat inaccurate.  First off, we don't listen to email,
we read it.  And, it's very apparent that Sven does spend considerable
time reading emails.

However there is reading and catching points here and there, and there
is reading and understanding the viewpoints and concerns of the person
who wrote them.

And, to some degree, no one really understands ALL that's being written in
the debian forums.  No one has that kind of time.  So we necessarily live
with some failures to comprehend.

But that doesn't mean that such failures are a good thing, it's just being
realistic that they exist.  We just try and avoid those failures boiling
into a significant issue in areas that are important to us.

Anyways, back to Sven... Sven: as a prolific writer in these forums, you
have exposed yourself to far greater levels of misunderstanding than just
about anyone else.  In part, no one has the time to even digest the
volumes you've written and understand why you wrote them.  In part, you do
not allow yourself the time to digest what other people are saying.  In part,
your interjections detract from the time people have available to study what
other people have to say.

And I think that, in a nutshell, is the issue.  It's really only a serious issue
because it's not a temporary state of affairs, but something that continues
for years.

And... repetition can be a fine technique to get a point across, but getting
points doesn't happen if you're not understanding other people.  You
won't know when they understand you just fine, you won't recognize
when they have a pertinent point to contribute, and you certainly won't
recognize when they don't understand you.

Anyways, if you're looking for someone to point at one specific thing
you've said, one specific issue, you're not going to get that.  There's
plenty of problems which have been raised, and not resolved, but taking
any of those in isolation is an excellent way of missing the fundamental
issue.  Taken in isolation, pretty much everything you've said is at least
tolerable and at times helpful.  That said, you do not allow people to take
your statements in isolation.

And I think all people are asking from you is...  more time (by a couple
orders, maybe, over what you currently grant) and a willingness to back off
when needed.  Time on your part to digest what they are saying, and for you
to grant them the time and respect to understand the good points in what you
have to say.  And if you can't grant that, what's the point?

That said, by this point many people seem to be rather unhappy (Sven
included), and that winds up being another issue in and of itself.

Finally, this is my point of view as a relatively disinterested observer.  I've
probably overlooked a number of pointed comments which would incline
a person to disagree with my assessment.  That kind of conflict is almost
inevitable with this kind of problem.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#385665: Fwd: Re: Bug#385665: fluidsynth needs non-free midi sound bank to function (Sat, Sep 23, 2006 at 10:45 -0700)

[Raul Miller]

On 9/26/06, Steve Langasek <[EMAIL PROTECTED]> wrote:

Do any of the other TC members disagree?


You seem to be doing a great job on this issue.

I have no current disagreement with you, and see no
reason to expect to have any disagreements with you
as further information is obtained.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/23/06, Bdale Garbee <[EMAIL PROTECTED]> wrote:

All of the arguments I've read and/or can come up with for pushing ndiswrapper
into contrib seem to me to relate to whether ndiswrapper is "useful" without
some other, probably non-free, software installed on the system.  That seems
like a slippery slope... lots of software in main isn't particularly "useful"
to me.  Does it make more sense to stay away from such arguments entirely?


It seems to me that this is the issue on which all decisions
about contrib hinge.

Software winds up in Contrib when substantially all use
of the software requires some non-free component.

As I see it, the problem with ndiswrapper -- and with the
linux kernel -- is that it's useful at install time, but current
practice with contrib and non-free means that anything in
contrib or non-free is unavailable at install time for most
users.

Perhaps the thing to do here is wait for the firmware GR
to settle out and make our choice based on that decision?

After all, whatever principles let us deal with our non
dfsg-free software issues should also apply in the
context of contrib issues.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/21/06, Steve Langasek <[EMAIL PROTECTED]> wrote:

In order to claim this as a reason for not excluding the package from main,
yes, absolutely.  That doesn't mean the converse is true, though, so we
still need to refine further to decide which side of the line ndiswrapper
belongs on -- so far we only have two tests which don't apply to
ndiswrapper. :)


I understand that some people don't want ndiswrapper in Contrib,
because it is free software and it might be used to develop other
free software.  However, every piece of software in Contrib is free
software, and can be used to develop other free software.

Put differently, a way of looking at the problem is: "Are there any
good abstract rules which describe what should be in Contrib that
(a) exclude ndiswrapper from Contrib, and (b) do not exclude all
software from Contrib?"

By "good rule", I mean at least as good as "Free software belongs
in Contrib when all users of the software require other, non-free
software to make non-trivial use of it."  [The biggest flaw, for this
rule, is that "use" means something different for different kinds
of software.  A hardware emulator, for example, sees different kinds
of uses than a software api emulator.]

On the other hand, we also have debian's policy for Contrib,
which ndiswrapper does fit.  Maybe "policy indicates it should
be in Contrib, and we do not have a compelling reason for it
to be in Main" is sufficient basis for deciding?

["It's in Main right now" might be compelling for the case of
Etch -- depending on how frozen Etch is -- but I don't think that's
a compelling reason outside the context of a release freeze.]

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/21/06, Steve Langasek <[EMAIL PROTECTED]> wrote:

I thought it was established up-thread that UAE isn't useful (in the
maintainer's opinion) without a specific non-free ROM?


By "that" do you mean "(in the maintainer's opinion)" or do you mean
"isn't useful"?

It seems to me that ndiswrapper is just as useful without a non-free
binary image as uae is without a non-free binary image.

Both are theoretically useful without such images.  However, if we
exclude hypothetical cases and focus on what people do for real,
neither are actually used without such images.

If anything since there's kickstart emulation for uae that partially
works and which is apparently in further development, if the
criteria is "useful for free software development", it seems to me
that there is more evidence that uae is suitable for main than
evidence that ndiswrapper is suitable for main.  [To be fair,
this point of view is contradicted, in some contexts, by the fact that
uae needs to emulate a 68k family cpu with a clock speed of
7.14MHz.]


So AFAICS, this term ("UAE requires a specific non-free ROM to
be useful") dominates, making contrib clearly the correct place for
UAE and also rendering UAE useless as a precedent for software
that doesn't have the same constraint of needing a specific piece
of non-free software to be useful.


Nit: there are several different kickstart rom images which can
be used with uae.  [But I don't think that's the issue.]

On the other hand, ndiswrapper requires at least one of several
specific pieces of non-free software to be useful.

You can run free software with ndiswrapper.  You can run free
software with uae.  As you've indicated above, the issue seems
to be usefulness.


I can find many counterexamples in unstable of libraries that don't have
significant communities of free software available written for them, but are
still in main.  Where they are excluded, they are excluded based on the
principle that it's not worth supporting an unused library in a stable
release, not on the principle that they don't belong in main because they
"depend" on software we don't include in main.


Maybe we don't need some of those?  On the other hand, while we
have contrib for cases such as emulation of non-free system, I
don't think contrib would be a suitable location for all of those libraries.


This last doesn't surprise me in the least; I don't believe that ndiswrapper
even provides an SDK for developers to use in building new NDIS drivers
directly against ndiswrapper.  (oh hmm, lightbulb, maybe *this* is the real
difference?)


Eh?   I thought it did?

That said, I haven't tried to develop such a driver so I don't know how
suitable the "SDK" is (I think it's mostly some headers and the ability
to inspect ndiswrapper source).


> But on the other hand "free software C depends on free software A"
> does not seem to be sufficient reason to put A in main (there seem
> to be a number of examples involving UAE that illustrate this case).

Written as "free software A does not depend on any non-free software
and free software C depends on A", I'm inclined to believe that this *is*
sufficient reason to not exclude A from main.


Then the mere existence of the free (albeit, limited functionality)
kickstart emulator is sufficient reason to include uae in main?

Or does the software have to be "useful", as we've hinted at, above?

Put differently, if free software "C" does not have to be useful, it would
seem that creating some trivial (but free) stub that depends on some
piece of software in contrib would be sufficient cause to move anything
from contrib to main.  I guess, if we got widespread agreement, I could
see going that route.  But I'm somewhat dubious of my ability to
convince people that this makes sense.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/20/06, Steve Langasek <[EMAIL PROTECTED]> wrote:

The wine-utils package contains free versions of several common Windows
utilities, built for use with wine.

The nsis package ships a Win32 binary which is a stub used for putting
together self-contained installers for Windows, which can subsequently be
tested under wine (the package even Suggests: wine for this).

One or both of these may be relevant if we're looking to the wine package in
main as precedent.


Hmm...

I don't think that's quite the issue.

Contrasting UAE with WINE, the distinction I see is that WINE has
a more significant set of free software uses.

Both are free software.

Both can be used as emulators to run other free software.

I am under the impression that UAE is in contrib because the free
software case is "vestigial", while WINE is in main because the
free software case is substantial.

There seems to be a significant community of audio software
developers who use systems based on WINE, and some of that
software gets released under free licenses (such as LGPL).

I don't see anything comparable for UAE.  Serious development
on the part of people from the Amiga community seems to be
focussed on coding directly to Linux APIs (for example, the
enlightenment window manager).

That said, at the moment, this is just my impressions.  If I'm going
to have anything significant to say about this, I need to walk through
each of the cases Anthony brought up and find the associated
free software community.  I expect that I can, for each of those
packages, but I have not yet done so.  [And, as a further aside,
I've spent quite a bit of time trying to find software development
based on ndiswrapper, but near as I can tell that's a dead
community.]

Anyways, for now... "non free software B depends on free software A"
does not seem to be sufficient reason to put A in contrib (the WINE
case, above, is a good example of that).  But on the other hand
"free software C depends on free software A" does not seem to be
sufficient reason to put A in main (there seem to be a number of
examples involving UAE that illustrate this case).

The distinction between main and contrib does not seem to depend
on existence tests.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/19/06, Ian Jackson <[EMAIL PROTECTED]> wrote:

I don't know about all of those but there is plenty of Free software
for dosbox and wine.  It's not generally in Debian for obvious reasons
but plenty of reasonable uses for those programs involve the user
running only Free software.


Yeah, that's what I (and, I wish, more people) need to think about.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/15/06, Anthony Towns  wrote:

On Fri, Sep 15, 2006 at 01:17:07PM -0400, Raul Miller wrote:
> I don't see why ndiswrapper should be different, in this regard,
> than uae.

UAE requires a Kickstart ROM to be an Amiga emulator; apparently there's a
"minimal free build-in [sic] Kickstart replacement", but presumably the
maintainer doesn't think that's sufficient for real use.


This seems similar to the situation with ndiswrapper, but:


Other similar things that are in main include coldfire, dosbox, fceu,
gngb, pcsx, wine -- the difference there is also that they don't require
a non-free ROM to actually provide their emulation.


It sounds like the policy I was referring to is not actually policy.

I'm going to think about this a few more days, but I find your
argument here to be awfully tempting.

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/15/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:

On Thu, 14 Sep 2006, Raul Miller wrote:
> Put differently, I do not understand the distinction between
>
>   "The purpose of the ndiswrapper package is to provide an ABI layer
>on top of the Linux kernel that is compatible with the interface for
>Windows NDIS drivers"
>
> and
>
>   "wrapper packages or other sorts of free accessories for non-free
>programs."
>
> (That said, I do understand that ndiswrapper is free software.
> Everything in contrib is free software.)

The different is that in one case, the package ndiswrapper doesn't
need to change to work with a free NDIS wrapper.


I don't see why ndiswrapper should be different, in this regard,
than uae.  As far as I can tell, there's far more free software
that works specifically with uae than works specifically with
ndiswrapper.

For that matter, I can think of cases where the package
ndiswrapper would have to change to work with some
free software that depends on it, even as it is currently
packaged.  [If the hypothetical free package which depends
on it is a higher priority, ndiswrapper would need to be
changed to reflect the increased priority.]

That said, there is little value in packaging software
around hypothetical packages which do not exist.  And,
for some odd reason, policy does not ask that we
package software based on hypothetical packages
which do not exist.

Put differently, I still do not see any practical distinction
between the two cases I originally quoted above.

And, personally, I am not prepared to vote for or against
a proposal I do not understand.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/14/06, Anthony Towns  wrote:

On Mon, Sep 11, 2006 at 11:58:57AM -0400, Raul Miller wrote:
> "Every package in contrib must comply with the DFSG ... Examples of
> packages which would be included in contrib are: ... wrapper packages
> or other sorts of free accessories for non-free programs."
> It seems clear to me that ndiswrapper fits this policy rather exactly.

I disagree with you on that -- I still think "providing a compatable interface"
is the best way to look at this, as per:

   http://lists.debian.org/debian-ctte/2006/03/msg00037.html


Er... what is your disagreement?

While that proposal mentions policy section 2.2.2, it does not
indicate why section 2.2.2 is not considered relevant here.  It
simply quotes part of section 2.2.2 without specifically
commenting on it.


> So, I'd like to propose that we issue an opinion that ndiswrapper
> needs to be in contrib, to comply with debian policy.

As per http://lists.debian.org/debian-ctte/2006/03/msg00130.html I think
you should draft up your proposal and we should just have a vote already.


Personally, I am not prepared to vote on an issue where I do not
understand all the proposals.

Put differently, I do not understand the distinction between

  "The purpose of the ndiswrapper package is to provide an ABI layer
   on top of the Linux kernel that is compatible with the interface for
   Windows NDIS drivers"

and

  "wrapper packages or other sorts of free accessories for non-free
   programs."

(That said, I do understand that ndiswrapper is free software.
Everything in contrib is free software.)

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ndiswrapper

[Raul Miller]

On 9/12/06, Andreas Barth <[EMAIL PROTECTED]> wrote:

* Raul Miller ([EMAIL PROTECTED]) [060911 18:30]:
> We have a release critical bug filed against ndiswrapper.
>
> More specifically, bug 353277 is severity critical, stipulating that
> ndiswrapper be in contrib, not in main.
>
> Here's the definition of "Severity: Serious" from bugs.debian.org: "is
> a severe violation of Debian policy (roughly, it violates a "must" or
> "required" directive), ..."
>
> So, an obvious question is: what does Debian policy say about contrib?
>
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

Actually, the definition refers to
http://release.debian.org/etch_rc_policy.txt as what serious is


I was going by the definition at
http://www.debian.org/Bugs/Developer#severities

The release manager document you referred to says:

  Further to this, certain issues may be exempted from being
  considered release critical for etch by the release manager.
  This is expressed by tagging the report "etch-ignore"; this
  should not be done without explicit authorisation from the
  release manager.

And gives a list of such issues where the first item on
the list is "DFSG-freeness".


Given these statements, I fail in seeing this bug as serious on the
package. (Of course, the situation might change after TC ruling.)


Well, of course, it might very well be that the release manager
will grant an "etch-ignore" exception for this bug.  However,
the package maintainer has not yet gotten such an
exception.

(On the other hand, note that this exception, if granted, would not
make the bug go away -- it would mean that the bug is no longer
release critical for etch, but would not take it off the plate of the
technical committee.)


> So, I'd like to propose that we issue an opinion that ndiswrapper
> needs to be in contrib, to comply with debian policy.

What do you want? Issue an opinion or overrule the maintainer? My
understanding is that the first doesn't change anything.


It's my understanding that the maintainer has agreed that if
the TC decides that it belongs in contrib that the package will
go in contrib.

Of course, the TC has not yet agreed that this is the case.
(I'm hoping that, by discussing this, the TC can come to
some sort of agreement that allows us to resolve this
bug.)

It's also possible that this no longer reflects the maintainer's
point of view.

On the flip side, this issue has been hanging around for
many, many months.

Anyways, the way I see it, the package currently violates policy,
and packaging it in contrib instead of main would make it
comply with policy.  None of what you have presented here
really deals with this issue.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: ndiswrapper

[Raul Miller]

On 9/12/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:

On Mon, 11 Sep 2006, Ian Jackson wrote:
> Raul Miller writes ("ndiswrapper"):
> > We have a release critical bug filed against ndiswrapper.
> ...
> > So, I'd like to propose that we issue an opinion that ndiswrapper
> > needs to be in contrib, to comply with debian policy.
> >
> > Comments?
>
> I agree.

I disagree. You already had that discussion and the discussion went
nowhere because the situation is not as clear cut as those 2 mails
seem to indicate.


Huh?

We have had earlier discussions, but they centered around the
social contract, not the policy I quoted above.


You don't have a consensus within the TC.


I am asking for comments, at the moment, not making a formal
proposal.  That said, I hope to make a formal proposal after
discussing any technical issues that come up.

At the moment, ndiswrapper has a release critical bug filed
against it.  Going forward, we need to either (a) have a
sufficiently good reason to downgrade the bug, or (b) decide
once and for all how to resolve the bug.

Leaving the situation as it currently is -- with an outstanding
release critical bug -- is not a good idea.


I believe the only viable way to go forward is to redefine contrib in
clearer terms and as it seems to be quite a political issue, I suggest
to go for a GR to settle the issue once for all.


Feel free to go ahead with that.  If it looks like you are likely to
change policy, we will certainly take that into account.  That
said, this is not a course of action I am going to put much
energy into.


(And no I don't want to reopen the discussion to know if we need a free
NDIS driver or not to make ndiswrapper a *DFSG free software*
acceptable for main)


And, note that there is significant software already in contrib
which has free software that works with it.  I think UAE is
a canonical example of this.

In other words, I agree with you here: re-opening that discussion
would be pointless.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ndiswrapper

[Raul Miller]

We have a release critical bug filed against ndiswrapper.

More specifically, bug 353277 is severity critical, stipulating that
ndiswrapper be in contrib, not in main.

Here's the definition of "Severity: Serious" from bugs.debian.org: "is
a severe violation of Debian policy (roughly, it violates a "must" or
"required" directive), ..."

So, an obvious question is: what does Debian policy say about contrib?

http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

"Every package in contrib must comply with the DFSG ... Examples of
packages which would be included in contrib are: ... wrapper packages
or other sorts of free accessories for non-free programs."

It seems clear to me that ndiswrapper fits this policy rather exactly.

So, I'd like to propose that we issue an opinion that ndiswrapper
needs to be in contrib, to comply with debian policy.

Comments?

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "technical issues" and d-i access

[Raul Miller]

On 8/14/06, Bdale Garbee <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] (Andreas Barth) writes:
> So, my question is: How can we streamline this?

I've had one possibly useful thought about this, that I'd love to have some
feedback on from other committee members.

What if we chose to divide along the boundary of whether a question directly
affects the content that ends up in a Debian package, or on a user's system
through other processes?  Anything can have an indirect impact, and this may
not always be a clearly black and white boundary, but it seems to me that it
might be a good guideline?


I think a better approach would be to come up with a list of things
we consider technical issues.

Software not functioning the way it is supposed to would seem to
be a technical issue.  Likewise, changing the way something
operates which causes other software to break is a technical
issue.  And so on...

The package scope thing seems more aimed at other aspects
of our mandate than at the "is this really a technical issue" question.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: assignments

[Raul Miller]

On 8/2/06, Steve Langasek <[EMAIL PROTECTED]> wrote:

I'm not aware that this was ever the claim.  CIPE was cited as an example of
a free NDIS driver that *could* be used with ndiswrapper; but the cipe
packages in Debian are certainly not built for NDIS, they're built for
Linux's native driver interface.


So why is ndiswrapper in main when something like uae, which has tons
of public domain software available for it (much of the stuff on the
fred fish disks) is in contrib?

I don't understand this.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: assignments

[Raul Miller]

On 7/24/06, Bdale Garbee <[EMAIL PROTECTED]> wrote:

owner 353277 [EMAIL PROTECTED]
owner 353278 [EMAIL PROTECTED]


These two bugs are about moving ndiswrapper and
ndiswrapper-modules to contrib.

At one point, I thought that we had been discussing that the
technical reason that ndiswrapper could not be moved to
contrib was that cipe depends on it.

However, looking at the cipe packages, I don't see any dependency
on ndiswrapper.
http://packages.debian.org/unstable/source/cipe
http://packages.debian.org/unstable/net/cipe-common
http://packages.debian.org/unstable/net/pkcipe

Also, these packages haven't changed since
2004.
http://packages.debian.org/changelogs/pool/main/c/cipe/cipe_1.5.4free-9/changelog

So... those people who were arguing that cipe requires ndiswrapper
be in main, could you give me some hint as to what you were
talking about?

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Chair rotation

[Raul Miller]

On 7/11/06, Bdale Garbee <[EMAIL PROTECTED]> wrote:

If the rest of the committee agrees, then I propose we try this.  I'm willing
to retain the position of chair and wrangle the assignments for a while if
that suits everyone?


Fine by me.


There are 6 open bugs against pseudo-package tech-ctte in the BTS right now.

Is anyone partial to taking responsibility for any of these, or should I
semi-randomly assign one of us to each open bug to review the current situation
and proposal suitable action for us to take?


Eh... if someone gets something they don't want, I think I'll be willing
to trade with them.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Chair rotation

[Raul Miller]

On 7/7/06, Bdale Garbee <[EMAIL PROTECTED]> wrote:

So, regardless of what we decide, I'd appreciate someone iterating the list
open issues before the ctte to either take action on or hand over to the
next chairman.  Anyone have that already in hand?


I'm having problems parsing this.

What are you asking?

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Chair rotation

[Raul Miller]

Conceptually, I should have taken up the chair in June, and should be
stepping down soon.

Obviously, I did not do that.

I see several options on how to proceed:

[1] Skip on to the next candidate.
[2] I pick up rotation starting [soon]
[3] Stick with Bdale
[4] Pick someone else (Ian?  Steve?  ...)

Comments?

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#366938: svn commit access to the d-i repo ...

[Raul Miller]

With paragraph 3 removed or reversed, I would also vote no.

(More specifically: I've not seen any good technical reasons,
yet, to override this commit access decision.)

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#366938: svn commit access to the d-i repo ...

[Raul Miller]

On 6/6/06, Steve Langasek <[EMAIL PROTECTED]> wrote:

Given that we have a very straightforward method of determining what AJ's
intent was (i.e., asking him), I would rather we did that than pass a
resolution that preserves this needless doubt.


This seems like a good idea.

Has AJ been asked, or do I need to do so?

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#367709: requesting libstdc++ .udeb in order to produce c++ based images based on d-i technology (but not d-i).

[Raul Miller]

I'm not sure what you're asking.

Ideally, I'd like to see three things:

(1) A concise description of the technical conflict that needs to be resolved.

(2) Good background material for understanding any subtle issues
underlying the conflict.

(3) A concise, specific and unambiguous proposal for dealing with the conflict.

It looks to me as if you've put quite a lot of effort into (2).
However, I'm not at all certain I know what obstacle you are running
into, and I've some uncertainties about what you are proposing.

Have you talked to the di people about this issue?  Have they raised
any objections?  If so, what are they?  (We should get involved if you
feel that they are making a choice which is technically incorrect and
which you can't resolve directly.)

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

Here's my current feelings on the ndiswrapper issue:

(1) ndiswrapper should be made available by us.

(2) the question is: should it be in main or config?

(3) ndiswrapper sometimes needs to be recompiled to be useful
http://lists.debian.org/debian-amd64/2006/04/msg00278.html

(4) the primary reason for the package to be in main is cipe.

(5) cipe has had no development attention for several years.

(6) software being stable is not sufficient reason for it to be
removed from the archive.

(7) ndiswrapper's primary use is  with non-free software (which
suggests it should be available in Contrib)

(8) there are practical problems with Contrib and some people
would be unhappy with ndiswrapper being in Contrib because
of those practical problems.

Since the primary question (should ndiswrapper be in Main or
Contrib) is a social contract issue, the determining factors in
any proposal for resolving this issue should be based on social
contract issues.

Probably the most important such issue is: what is best for
the free software community?

This is a value judgement, so I think that we can only issue
advice.  I think we should avoid making a ruling that is any
stronger than "advice" on this issue.

However, there are other problems here (for example, the
practical problems with Contrib) which perhaps should also
get some attention from us.

* * * * *

That, I think, characterizes the problem, what about solutions?

One crucial issue is cipe.  CIPE is not getting any development
attention and if it were engaging developer interest this issue might
be simpler to resolve.

Possible development efforts:

[a] Port CIPE to a native linux interface.  This eliminates the
conflict and would allow ndiswrapper to go into Contrib.

[b] Upgrade the protocol, providing options which could provide
better security.

Of course non-CIPE development efforts could also occur, for
example

[c] Other free software could be written which uses the ndiswrapper
interface.

I think we should suggest that such development efforts would be
a good thing for the free software community and that the question
of where ndiswrapper goes be tied to such development efforts.

I think that if none of the above occur, if the current state of affairs
continues to persist, that CIPE be orphaned.  If CIPE remains the
only reason for ndiswrapper to be in main, and no one cares to
address any CIPE issues (either maintaining the current interface
or using a different interface) then eventually it will vanish and
eventually ndiswrapper will need to be moved.

If ndiswrapper becomes a hotbed of cross-platform portable free
software, then it should remain in Main.

If the only software development for CIPE winds up removing the
dependence on ndiswrapper (or if it turns out that CIPE has a
hostile author who forbids that kind of porting) then ndiswrapper
does not belong in Main and should be moved to Contrib.

I think this characterizes the range of potential solutions.  Basically, I
think we could just lay out these alternatives and recommend a wait
and see approach.  (Wait and see whether CIPE represents a
real free software effort or whether it is really just a red herring.)

But maybe there's a better approach that takes into account
these possibilities?

Comments?

Thanks,

--
Raul

Re: vote time again: stepping down as chair

[Raul Miller]

On 4/11/06, I wrote:
> But I will agree that you did good getting the ndiswrapper
> issue wrapped up.

Argh.

I meant to say the "devmapper issue wrapped up".

The ndiswrapper issue is still open.

I'm writing a longer message on the status of the ndiswrapper
as I currently understand it.

My apologies,

--
Raul

BDale?

[Raul Miller]

I think Bdale is now our chairman?

Steve stepped down, we've had several votes in favor of BDale.  Quorum
is 2.  BDale has not stepped down.

--
Raul

Re: vote time again: stepping down as chair

[Raul Miller]

On 4/11/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> According to the agreed-upon schedule, I'm now overdue to step down as chair
> and it's time for us to vote Bdale in.

The agreed-upon schedule needs to be changed, because
Anthony Towns is not project leader, and general rule 2.1.2
says he can't be both leader and committee chairman.

> I don't think it helps anything to have the seat vacant for that week, in
> spite of my tardiness.  So I'm announcing with this mail that I will vacate
> the position of committee chair on April 18, i.e., 1 week from today.

Ok, my vote, based on the original schedule, with the idea that
fall backs should be the next available person from that schedule
is:

2  Bdale Garbee
4  Raul Miller
5 Andreas Barth
6  Ian Jackson
7  Steve Langasek

I'll also say that I do not think you are being negligent for
serving too long.

> For
> my part, I definitely think that a 1-month rotation would be too short,
> regardless of whether any voting was required, just because anything that
> happens in the TC takes long enough that we would be doing a whole lot of
> shuffling of current business between chairs.

I very much agree.  And, as Anthony's extra duties have also
had their impact on the schedule, I think we should informally
agree that these short terms will be two months long.

If you and Bdale can agree that you should serve another month,
I'll be happy to change my vote, above, changing my preference
for you from 7 to 1.

> Then again, I failed to step down on time because I was focusing on
> resolving the devmapper question first; so maybe asking each chair to
> conclude one item of business per month would actually improve the
> committee's efficacy? :)

I appreciate your humble approach on this issue, but I do not
want to agree with you that you failed to step down properly.

But I will agree that you did good getting the ndiswrapper
issue wrapped up.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 4/5/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On 5 Apr 2006, Raul Miller stated:
> > Has someone suggested that we should not build or distribute
> > ndiswrapper?
>
> In Debian? Yes, I think that is exactly what we are talking
>  about.

With qualifications, I guess I can agree that that's what
we're talking about.

Here's the qualifications I currently think are appropriate:

(1) That cipe is recognized as orphaned.  This would be accompanied
with a detailed set of reasons for this decision, and would not be
instantaneous.  The reasons include longstanding issues with
the package, and the lack of attention that they have received.

Orphaning the package would involve several steps.  First, we
should file bug reports detailing these issues.  Second, we
would wait for some period of time to see if the bug reports
are enough to bring development on the package active.  If not,
then the cipe package would be removed from main.

(2) Assuming that we establish that there's no free software
development activities keeping ndiswrapper in main, we move
it to contrib.  It would be distributed from there, and thus not
distributed "in Debian Main".

> I hink that the Quality of implementation would suffer if we
>  disallow this DFSG-compliant software from being a part of Debian.

I'm dubious of that assertion.  I feel that, as stated, it's too
vague to mean anything.

--
Raul

Re: devmapper: call for votes

[Raul Miller]

I vote in favor of this resolution on bug #329409.

Thanks,

--
Raul

On 4/6/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> I'm calling for a vote on the following resolution regarding bug #329409.
...
> WHEREAS
>
>  1. It is a limitation of the current device-mapper implementation in Debian
> that all device nodes managed by libdevmapper are created with the same
> hard-coded ownership and permissions; and
>
>  2. The standard owning group for disk device nodes is group "disk"; and
>
>  3. The sole reason for the existence of this group on Debian systems is
> to control access to disk devices; and
>
>  4. The majority of device-mapper nodes expose data that is already
> available to members of the disk group via the component disks; and
>
>  5. The use of a different owning group in these cases therefore makes
> accessing the data more inconvenient but not more secure; and
>
>  6. The exception to the above is dm-crypt, whereby device-mapper nodes
> expose data that is not available in unencrypted form from the
> component disks; and
>
>  7. No single owning group satisfies all possible use cases for
> device-mapper; but
>
>  8. Users of dm-crypt have the option of not adding users to the disk
> group that they do not wish to have access to their unencrypted
> dm-crypt volumes;
>
> THE TECHNICAL COMMITTEE:
>
>  9. THANKS Bastian Blank for his continued maintenance of the devmapper
> package in Debian; and
>
> 10. ALSO THANKS Roger Leigh for bringing this issue before the
> committee; and
>
> 11. ENCOURAGES the devmapper maintainer to work towards support for
> configurable device-mapper device permissions in Debian; and
>
> 12. DETERMINES that the correct default permissions for all device-mapper
> nodes is root:disk 0660, with or without support for configurable device
> permissions; and
>
> 13. ASKS (with a 3:1 majority: REQUIRES) the devmapper maintainer to
> implement these permissions in unstable by applying Roger Leigh's
> patch from
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329409;msg=87;att=0;
> and
>
> 14. RECOMMENDS policy be updated to reflect this determination on
> default block device permissions; and
>
> 15. AUTHORIZES Roger to implement these same permissions in stable via a
> non-maintainer upload.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFENNiIKN6ufymYLloRAs3kAKCGhP1weIjzn+hWZxEtDAnkK7r/iwCfdZtN
> VPGy1yLpvWx9TFK44xWjbIg=
> =Z3ZQ
> -END PGP SIGNATURE-
>
>
>

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 4/5/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> And for what benefit? Just like the FSF started by
>  distributing and build software on non-free systems, putting out
>  software that may initially be more heavily used with non-free
>  input/output is still desirable, since it is a beachhead that can
>  then be exploited for free purposes by someone out there, who may
>  never be exposed to the software in question was its distribution to
>  be severely limited.

Has someone suggested that we should not build or distribute
ndiswrapper?

We've suggested that we not consider it an integral part of our
free operating system, but that doesn't seem to be what you're
talking about.

[P.S. despite the fact that my vote on the GFDL issue put
me in an extreme minority, I do not have a problem with the
outcome of that vote.  But that's better discussed on other
lists.]

--
Raul

Re: Processed: Forwarding to the technical committee

[Raul Miller]

On 4/4/06, Joerg Jaspert <[EMAIL PROTECTED]> wrote:
> Yes, unfortunately I trust judges to be uninformed enough to have true
> randomness in decisions. I personally would think you can't revoke GPL
> for a old version, only if you release a new one use a different license
> for that, but well...

I don't think the license is the issue here.

If the code has been released under the GPL (with proper
copyright notices and everything), then we have every
right to modify it, and to distribute the modifications.

The issue, here, is the potential for spurious legal harassment.

On the plus side, harassing legal activities cost money, and
create legal risks for the person engaging in them.  This tends
to limit their use.

On the down side, the energies spent defending against
such activities could be more fruitful if spent in other
areas.

Do we have a test suite of software, to check that these
cdrtools are working properly?  Because, if we had a
good test suite, it wouldn't be hard to re-implement from
scratch.  (The hard part of re-implementing from scratch
is finding and tracking down all the little bits and pieces
that don't work quite right for somebody's special case.)

--
Raul

Re: Draft resolution on devmapper question

[Raul Miller]

On 4/3/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Raul suggested in
>  that policy
> should also be amended to spell out the permissions for disk devices -- do
> we need to include text here which addresses that directly?

Perhaps the following item could be added to your draft (renumbering the
current item 14 as 15)

14. RECOMMENDS policy be updated to reflect this determination
on default block device permissions.

In general, your proposal looks good.

> (BTW, have people read Bastian's patches in
> ?  While
> they are a very encouraging development, if you look them over you'll see
> that Bastian has still implemented root:root 0600 as the default permissions
> for lvm2 -- so there is still an unresolved technical dispute here, not just
> an issue of time management...)

Yes.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/29/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Does the fact we are boith ignorant mean that the authors and
>  users of ndiswrapper be penalized?

Yes!

...ok, I don't mean exactly that, but I don't reject it either.

Fundamentally, the only thing that keeps me from releasing a GPLed
work-alike for ANY piece of non free-software (let's say Windows
Vesta, if you want a concrete example) is my ignorance of how it works
and what it does.

This issue also holds for supplying the dependencies of software in
Contrib.

> I don't know how to use a large number of interpreters and
> compilers in Debian (scheme, python,  ...). Presumably,
> you, too, are not omniscient (If you are, I do apologize, god).
> If there is an intersection of these sets, should it have a
> bearing on the freeness of the packages that live in that
> intersection?

I'm not asking for omniscience, nor any other signs of god-ness.

The technical issue, I think, is: is the package complete in and of
itself?  If not, does Main contain what the package needs to make it
complete.

If we have libpureschemeeval.0.1.so which implements a complete scheme
interpreter, which only supports the dotted pair data-structure and
requires everything else to be implemented in the calling environment
(parsing, garbage collection, result formatting, ...), that's fine.

If, however, after some number of years, no one is using it (perhaps,
among other reasons, because it doesn't exactly implement the right
semantics), I'd be rather dubious about why we have the package at
all.

If, in addition, there are a number of users of the package, and all
of them use it to wire gcc up to Microsoft's SQL Server, so it runs
under linux, I'd be very very uncomfortable about this package.

I'd feel much better about it if either (a) it was used actively for
some obvious free software purpose, or (b) it was pulled from the
distribution.

Then again, I don't think we (the technical committee) would have the
authority to pull the package.  But I also don't think we should give
this kind of situation unqualified approval.

> > I don't understand why that means it's not in your universe.
>
> Cause I am all fere and pure, dude. Do try to keep up :)

Hmm... let me try again:  I don't think your keyboard and display are
in your universe.  So what I want to know is: who do you get to do
your typing for you?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/29/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > But what what distinguishes ndiswrapper from anything else in
> > contrib?
>
> Like gcc, it is ready for tyhe user to provide input for it to
>  process. Like gcc, it needs input to produce output (wrapped loadable
>  kernel module), but does not _depend_ on the input, any more than gcc
>  does.

Here's an example of the user providing input for gcc:

$ cat >example.c <
main() {
printf("%g\n", 3.14159*7*7);
}
END
$ gcc example.c -o example; ./example
153.938

I don't know how to do something like this with ndiswrapper.

Since I'm ignorant, could you provide an example?

> >> If ndiswrapper is not in my universe, I may never get around
> >> to writing fee windows drivers that could also be used on Linux :)
> >
> > I don't understand this one.
> >
> > Why wouldn't "Contrib" be in your universe?
>
> It is not in Debian.

I don't understand why that means it's not in your universe.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/28/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On 28 Mar 2006, Raul Miller spake thusly:
> > I think the difference has to do with intent, and expected use
> > patterns
> > -- not just at the command line, but in overall terms.
> >
> > And a related question is: what free software effort would be
> >  harmed by putting ndiswrapper in config?

> Err, wrong question. End users benefit from having this
>  interface to networking drivers around; it gives them more freedom in
>  dealing with hardware they might not have a choice about.

How was that the wrong question?

Shouldn't we make a distinction between short term benefits and
long term benefits?

Shouldn't we be focusing on development issues here?

If the only issue was short-term end-user benefits, everything in non-free
could go in main.

> Helping users make use of hardware they are saddled with adds
>  to the quality of implementation; and since users come high on our
>  list of things to care about, we should not be looking at "is some
>  free software effort damaged if we move things out of debian, even if
>  users selecting just debian (like, CD based users in areas with poor
>  network connectivity) have to jump through hoops"

But what what distinguishes ndiswrapper from anything else in contrib?

> Also, you need to look at how many future efforts you are
>  encouraging -- or discouraging -- by your treetment of this  freely
>  licensed module wrapping tool chain.

I agree on this point.

> If ndiswrapper is not in my universe, I may never get around
>  to writing fee windows drivers that could also be used on Linux :)

I don't understand this one.

Why wouldn't "Contrib" be in your universe?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/27/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On 26 Mar 2006, Raul Miller told this:
> > The ambiguity is in the resolution's interpretation of the quoted
> > policy:
> >
> > ...  must not require a package outside of _main_ for
> > compilation or  execution ...
> >
> > Does no-operation or substandard operation satisfy requirements for
> > execution?
>
> Well, yes. Consider the case that I write up a compiler for a
>  new language in C++ or ruby.  Can I put this compiler in main? Even
>  if there is no public repository of code in this new language?

That seems to me to be different.  The compiler does not require anything
special to be installed to use its full capacity.  It needs content, but the
content would typically be supplied by the person using the computer.

If the primary purpose of the "compiler" were to "compile" some pre-packaged
content from commercial vendors, then that would be a good analogy.  But
I doubt that that's what you meant.

> What if it was not a compiler, but an emulator of a virtual
>  machine?  Until there is code that can run on the virtual machine,
>  there is nothing for the emulator to show.

This is getting closer to the circumstance I think we're dealing
with here.

Note also that we have put a number of virtual machine emulators
in Config for this very reason (game console emulators).

> The only argument I have seen so far seems to imply that I
>  can't package up new emulators  or compilers unless I also provide
>  free source code for these to process, I am not sure I think that
>  expands freedom in any tangible manner.

I think the difference has to do with intent, and expected use patterns
-- not just at the command line, but in overall terms.

And a related question is: what free software effort would be harmed
by putting ndiswrapper in config?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/25/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On 22 Mar 2006, Anthony Towns stated:
> > On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
> >> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> >>> Why does contrib exist ?
> >> [essay elided.]
> >
> > So is there an alternate proposal to
> >
> > http://lists.debian.org/debian-ctte/2006/03/msg00037.html
> >
> > so we can have a vote and make a decision? AFAICS we've discussed
> > this pretty thoroughly.
>
> I am going to be out of town for the latter half of next week,
>  so if a vote comes up when I am gone,  I support the resolution in
>  the mail:
> http://lists.debian.org/debian-ctte/2006/03/msg00037.html
>
> I am not sure I see that it is at variance with published
>  policy, nor do I see why it makes contrib ambiguous, really.

The ambiguity is in the resolution's interpretation of the quoted policy:

  ...  must not require a package outside of _main_ for
  compilation or  execution ...

Does no-operation or substandard operation satisfy requirements for
execution?

One argument in favor of the above resolution is that if no operation
is documented as a part of the ABI, that is sufficient for these
requirements.

But this concept is not expressed in policy, and it's just as reasonable
to require normal operation be possible to satisfy requirements for
execution.

Another argument put forward in favor of the above resolution is that
if no software has been packaged, this policy is irrelevant as the
requirements are for non-packaged software.

But this argument seems more dubious than the "no operation is sufficient
for the typical case" concept.

The final, and perhaps most convincing argument in favor of ndiswrapper
is that it allows the use of CIPE.  But CIPE seems flawed, and oddly
enough the most recent in-depth coverage of these issues seems old:
http://lists.grok.org.uk/pipermail/full-disclosure/2003-September/010864.html

The last release of cipe (1.6.0) was in 2004.  The last debian update
to the cipe package (1.5.4) was in 2004.  There's not even an option
to use anything better than a 32 bit checksum for integrity purposes
(which is one of the more egregious security flaws in cipe).

Poking around a bit more, it looks like people have mostly abandoned
cipe for stuff like openvpn (which we also distribute).

I see no evidence that anyone cares enough about the cipe package to
justify it being in main.  If CIPE is the reason we have ndiswrapper in
main, I think we're doing our users a disfavor.

I'm not aware of any other arguments in favor of that resolution which
satisfy this policy.

Is "we should be distributing CIPE in main" really the reason for keeping
ndiswrapper in main?  or is there some better argument?

If there is such an argument, I'd like to understand it before I make a
proposal based on the idea that there are no better arguments in favor
of this resolution.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/23/06, Anthony Towns  wrote:
> On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
> > On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > > Why does contrib exist ?
> > [essay elided.]
>
> So is there an alternate proposal to
>
> http://lists.debian.org/debian-ctte/2006/03/msg00037.html
>
> so we can have a vote and make a decision? AFAICS we've discussed this
> pretty thoroughly.

I'm not sure what you mean by "pretty thoroughly":

The proposal you cited does not address any of the issues raised in
the essay I elided.

I think your proposal conflicts with published policy, and with the obvious
purpose of "Config". I don't feel so strongly about that that I don't see
your point of view, but I do think that your proposal should be amended
so that it addresses this issue (conflict, ambiguity, whatever) in some
way.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Why does contrib exist ?

[essay elided.]

I've been trying to think about this from other points of view, with
the idea of suggesting policy changes that would allow ndiswrapper
to remain in main.

I haven't found any such reasoning which I'm happy with.

Put differently:

(1) I agree with the reasoning you expressed last week.

(2) I think that any dissenting opinion should include
a policy change recommendation (with associated
reasoning).

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/9/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Technical arguments why ndiswrapper should be in main:
>
> - availability to users with the default sources.list
> - availability from within the installer
> - availability from the unmodified Debian CD images
>
> Technical arguments why ndiswrapper should be in contrib: ?

"unmoified Debian CD images"?

It seems to me that everything in contrib should be distributed
on CD.  This doesn't match existing practice -- perhaps because
we've kept useful stuff out of contrib?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/8/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> > On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > > In our opinion the relevant principle is that:
> > >
> > >  (i) If the user or administrator who is in charge of the Debian
> > >installation would have to adopt non-free software X to make
> > >sensible use of free software Y, then Y goes in contrib.
> >
> > Existing policy says something similar for free software X which
> > has not been packaged in main, for whatever reason.
>
> Are you saying wine should be in contrib ?  No-one seemed to be
> arguing that it should be until we had this conversation ...

I'm not sure whether it should be there or not.

It seems to me that reasonable readings of section 2.2.1 of
current policy would suggest that WINE belongs in Contrib, and
that reasonable readings of this same policy would suggest that
WINE belongs in Main.

Personally, I'm ambivalent about the subject.  I believe that the
typical user of WINE will already have contrib in /etc/apt/sources.list,
and I see no problems with putting WINE in contrib beyond the
usual "it's a change" issues.

For that matter, last time I looked at WINE, you had to edit
/etc/wine.conf (or .winerc) before it could be used.  This
suggests to me that the wine development folks would look
poorly on the idea that we might want to have debian
packages which provide tools for use inside the wine
environment.  Of course, that could change in the future, but
I'm not sure it's a good idea to make packaging decisions on
what could happen in the future while ignoring the present
state of affairs.

But just as I see no problem with moving WINE to config, and
I see advantages to that, I also see no immediate problems
with leaving WINE in main.

> > For example, some people might think that early versions of
> > PINE are free, but Debian has declined to package them.
> > Despite the text of the license, there is a threat of harassment
> > by the University of Washington, and I think we have a fairly
> > strong consensus that supporting PINE just isn't worth the
> > bother.
>
> Err, probably this just means that no-one can be bothered to be the
> maintainer ?

That, too.

> > We can have other reasons for not including free software in
> > Main.  I believe packages belong in Contrib if they rely on the
> > installation of software we're not likely to package.
>
> You have to say something more subtle if you want to leave wine in
> main.  It seems that our current policy depends on whether the
> non-packaged software is not packaged because of its legal or
> political status, or for some technical reason (eg, consider the free
> Windows accounting suite someone mentioned).

That may indeed be our actual policy.

However, these issues don't seem to be spelled out very clearly
in the policy manual.  And if there's a significant gray area where
it's package maintainer's discretion, then that should be spelled
out as well.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I have overhauled and extended my old draft.  See below, and please
> comment.

I think you've presented the the issues clearly.  However there is
one point that I think warrants more attention:

> In our opinion the relevant principle is that:
>
>  (i) If the user or administrator who is in charge of the Debian
>installation would have to adopt non-free software X to make
>sensible use of free software Y, then Y goes in contrib.

Existing policy says something similar for free software X which
has not been packaged in main, for whatever reason.

For example, some people might think that early versions of
PINE are free, but Debian has declined to package them.
Despite the text of the license, there is a threat of harassment
by the University of Washington, and I think we have a fairly
strong consensus that supporting PINE just isn't worth the
bother.

We can have other reasons for not including free software in
Main.  I believe packages belong in Contrib if they rely on the
installation of software we're not likely to package.

Other than this one issue, I agree with the points you've
expressed in your draft.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Here is a version of Anthony's `put it in main' resolution made into a
> suggestion rather than an instruction.  Below you'll find a diff for
> your comfort and convenience.

I vote against this proposal for the same reasons I voted against
the original.

Alternatively, if we're going to have a proper ballot listing several
different options, I'll be voting further discussion ahead of both
this proposal and Aj's original.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/6/06, Anthony Towns  wrote:
> 3.  The purpose of the ndiswrapper package is to provide an ABI layer
> on top of the Linux kernel that is compatible with the interface for
> Windows NDIS drivers, and that in order to provide this compatability
> layer, no non-free software is required; and

This is a purpose, but not the sole purpose.

This seems clearly established in the proposal:

> 4.  The primary use for this compatability layer is to run non-free
> Windows drivers for hardware not directly supported by Linux, though
> a very limited number of free drivers using the NDIS format also
> exist; and
>
> 5.  The technical policy in this matter states that: (debian-policy
> 3.6.2.2, section 2.2.1)
>
>[...] packages in _main_
>   * must not require a package outside of _main_ for compilation or
> execution

If "execution" means typical execution (as opposed to some kind of
failure condition or something else which would not be acceptable for
a normal user of the package), then I think it's clear that in the
minds of almost everyone who installs ndiswrapper, non-free Windows
drivers are required for execution of ndiswrapper.

> and: (debian-policy 3.6.2.2, section 2.2.2)
>
>Examples of packages which would be included in _contrib_ are:
> * free packages which require _contrib_, _non-free_ packages or
>   packages which are not in our archive at all for compilation or
>   execution, and
> * wrapper packages or other sorts of free accessories for non-free
>   programs.

As the normal use of ndiswrapper requires software which has not been
packaged for main, and as ndiswrapper is primarily to make these non
free drivers useful, I think it's sufficiently close to the above
examples.

> THE COMMITTEE CONCLUDES THAT
>
> 6.  It is appropriate for the committee to consider this request; and
>
> 7.  The current ndiswrapper package does not require any non-free
> software at either compilation time or installation time to fulfill
> its designated purpose; and

Point 7 seems to require we ignore points 4 and 5, and accept point
3 as describing the normal use of ndiswrapper.

> 8.  As such the ndiswrapper package complies with current technical
> policy as regards to its suitability for main; and
>
> 9.  If the ndiswrapper package come to depend on non-free software at
> compilation time or installation time, such as by prompting the user
> for a Windows driver CD, at that time the ndiswrapper package would
> be required to be moved to contrib.

If this a salient point, then 2.2.1 should be changed to read
"must not require a package outside of _main_ for compilation or installation"
instead of the current
"must not require a package outside of _main_ for compilation or execution"

> IN ADDITION
>
> 10. The committee endorses the decisions of the maintainer of ndiswrapper
> and the ftpmaster team in including the package in the main component
> as being in compliance with Debian technical policy; and
>
> 11. The committee endorses the existing policy on the suitability of packages
> for the main and contrib components; and

It seems to me that either

[1] we should be recommending policy be changed (so that it's clear that
execution requirements of nearly all users is not relevant  when
determining whether a package belongs in contrib, and perhaps removing
the reference to "wrapper packages" or perhaps providing a definition
which clearly excludes ndiswrapper), or

[2] we should be recommending a different course of action with
ndiswrapper.

I vote against this proposal.

Thanks,

--
Raul

Bug#345067: [Yaird-devel] Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this.

[Raul Miller]

On 3/7/06, Sven Luther <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 07, 2006 at 07:20:31PM +0100, Jonas Smedegaard wrote:
> > Please see http://wiki.debian.org/LinuxKernelIdeProblem that I created
> > today and have invited the kernel team and udev developers to improve
> > on.
>
> An assembly of patent ...

It looks to me like that's a wiki page.

In other words, you can fix problems on it directly without needing to ask
for help or permission.  Though, obviously, including references to
supporting information will probably be a good thing in the context of
future changes.

I think posting corrections there might be a useful approach.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Given that there's been no formal call for votes on either Raul's proposal
> or on this one, then, I think we should take another day for any further
> input (additional resolutions, editorial corrections, etc), then put these
> on a ballot and call for votes.

Given that I left out paragraph 10 of Ian's proposal, I was
under the impression that it would be withdrawn and reissued.

I had thought Ian was going to do this, but perhaps I should
have done so.

On the other hand, if opinion is strongly in favor of Aj's
proposal, perhaps I should instead try to express why I
feel points 3 and 4 of Aj's proposal are at odds and/or
what I feel should be done to change policy to be consistent
with this proposal.  (I'll try to get to that later today).

Thanks,

--
Raul

Re: Bug#307833: Processed: Re: apt-file: broken. curl is needed

[Raul Miller]

On 3/3/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> I understand that this bug has been (silently) fixed in the latest version
> of apt-file.  Any objections to reassigning the bug back to apt-file and
> closing this issue out?

I agree with you that this appears to be the right action.

If it turns out that we're wrong, the bug can always be re-opened and
maybe reassigned back to us.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Anthony Towns  wrote:
> We're getting into "if a tree fell in a forest..." territory here though.

In that context the question we're trying to resolve is analogous to:
is this a forest, or a parking lot?

Getting back to my own views on this:

I don't think a decision to put ndiswrapper in main or contrib
is going to violate the social contract.  The way I read the social
contract, both can be a valid decision.  I'm more interested in
making the best decision (and the social contract is one of the
things I'm using to judge what "best" means).

And I can be convinced that we should temporarily leave ndiswrapper
in main for hypothetical uses.

I think that the long-term decision about where ndiswrapper
belongs should be consistent with what people do with it.

Contrib is for free software, I don't think moving any free software
to contrib is "bad".  It's just a signal to our users that they are
expected to install non-free software if they want to make good use
of the package. I think it's perfectly reasonable to put dosemu and
wine in contrib for that reason.

I also think it's perfectly reasonable to leave dosemu and wine
in main if many people find them useful without having to install
non-free software.

I do NOT think that this is any sort of alarming issue requiring
immediate action -- I'm far, far more concerned about the long-term
value of these decisions than I am about what things look like next
month.

Does this make sense?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/3/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > For example, if there's free software being developed against
> > WINE (as a UI, or whatever) then that's sufficient reason right
> > there, to leave it in main.
>
> Counting the toy utilities that are bundled with wine, or only other free
> software?  I don't know of anyone developing free software against wine.
> I've used it to develop *non-*free software; I could *imagine* someone
> developing free software against wine, but I can also *imagine* someone
> developing free software against ndiswrapper.

I think using WINE to develop non-free software could count as
a use for wine sufficient to keep it in main.  We don't require that
our users use packages for free software development, just that
package use doesn't require non-free softwaer.

> > I'm willing to hear reasons why this reasoning is wrong, but if we're
> > going to go that route I think we to think those reasons through and
> > come up with some suggested policy that distinguishes between the WINE
> > case and the cases that belong in Contrib.
>
> Well, I would note that at this point, we seem to no longer be talking about
> confirming existing policy; if we were, I would expect that more weight
> would be given to AJ's proposed criteria, since as an ftpmaster he's pretty
> much the resident authority on what this de facto policy is.

That's fine -- but if we're going to go that route I think we should propose
that the text of existing policy be updated to accurately reflect
these criteria.

> But there's plenty of documentation for writing NDIS drivers, just as there
> is for writing Windows applications.  AFAIK, you can develop NDIS drivers on
> Debian using mingw just as you can develop Windows applications this way.
> Doesn't that leave as the only distinction between wine and ndiswrapper the
> theory that one is interesting to free software developers and the other
> isn't?  Does this mean wine and ndiswrapper belong in the same section, or
> do we then shuffle packages back and forth between contrib and main
> depending on the results of surveys of some kind?

If ndiswrapper is of significant use for people developing windows
applications, I think that's sufficient justification for it to be in main.

But I don't think it belongs in main if the only uses that put it in main
are hypothetical.

If we want to be fully abstract, a piece of software is just a (huge)
integer.  The integer itself is not what matters.  What matters
is what it represents to people.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Anthony Towns  wrote:
> On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote:
> > On 3/2/06, Anthony Towns  wrote:
> > > But it doesn't -- ndiswrapper will sit there quite beningly if the 
> > > non-free
> > > driver isn't present. It'll do everything it's supposed to -- link with 
> > > the
> > > kernel and provide an ABI for other software -- without any errors.
> > Ok, but that's not everything it's supposed to do.
> > If that's all it needed to do then the code implementing the ABI
> > could do (*0)= "dump core" and that would be fine.
>
> Eh? If I found something that claimed to implement the C string library
> (strcpy, strcmp, strstr, etc) but just dumped core everytime it was
> invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave
> some behaviour undefined (such as free(x); free(x);), but none leave
> all of it undefined.

For the case you described, it would not dump core.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 28, 2006 at 01:35:11PM -0500, Raul Miller wrote:
> > But I think this case -- < > install non-free software, in order to make the package work the way that
> > people typically think of as using it>>... I think this case is on the wrong
> > side of that line.
>
> But by its nature ndiswrapper requires root privs, and this would be true
> even if we were bundling a free driver with it.  So I don't think that's the
> right line here, either...

I said A, B, C

You said A (without B and C).

I don't think these are comparable, even though they use some of
the same words

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Anthony Towns  wrote:
> On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote:
> > Ok, we should probably find a different word to describe this
> > relationship.
> >
> > Perhaps it could be phrased that ndiswrapper has a need for the presence
> > of some software which is not available in debian main.
>
> But it doesn't -- ndiswrapper will sit there quite beningly if the non-free
> driver isn't present. It'll do everything it's supposed to -- link with the
> kernel and provide an ABI for other software -- without any errors.

Ok, but that's not everything it's supposed to do.

If that's all it needed to do then the code implementing the ABI
could do (*0)= "dump core" and that would be fine.

You're right, of course, that it's more precise to say that the user
has this need.

Then again, there have been packages where there were two groups of users,
one who would be better served by a dependency and another who would be
better served without.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > With that in mind, policy on contrib says that contrib is for
> > "wrapper packages or other sorts of free accessories for non-free programs."
> > http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib
>
> > And I think ndiswrapper is "a sort of free accessory for non-free programs."
>
> Ok.  Would you say the same thing about a free library that implements an
> API/ABI which is primarily of interest to users of pre-existing non-free
> software?  If not, why is one an "accessory" and the other not?

That's a good question.

The way I'm currently thinking: If there are debian packages that you
can use in WINE, or if it has some functionality that makes it useful
in and of itself, then it belongs in main.  Otherwise it belongs in
contrib.

For example, if there's free software being developed against
WINE (as a UI, or whatever) then that's sufficient reason right
there, to leave it in main.

I'm willing to hear reasons why this reasoning is wrong, but if we're
going to go that route I think we to think those reasons through and
come up with some suggested policy that distinguishes between the WINE
case and the cases that belong in Contrib.

> > Perhaps it could be phrased that ndiswrapper has a need for the presence
> > of some software which is not available in debian main.
>
> If we didn't ship any free software built around the Motif API, would this
> mean lesstif had a "need for the presence of some software which is not
> available in Debian main"?

I've been suggesting that the answers to these questions depend on
our best understanding of how our users use the software.

If it's built and deployed for people to develop against, that's one
thing.

If it's not documented and supported for development work, and no
one is developing against it, and it's only being used by people
who want to install something that's not free, then that's an
entirely different situation.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> The lack of declared dependencies in ndiswrapper isn't a result of trying
> to do an end-run around policy, it's a result of the fact that ndiswrapper
> does not *have* a dependency on windows drivers in the sense that can
> reasonably be represented in the Depends: field -- just as any given library
> is of limited use on its own, yet it doesn't have an ORed dependency list on
> all the packages (+ unpackaged software) that can use it.

Correct.

I was not disputing the headers of the ndiswrapper package.  I was
disputing the assertion that we can't assume anything about how
the software is used.  My assertion was that we must assume things
about how the software is used in order to populate the Depends:
header.

With that in mind, policy on contrib says that contrib is for
"wrapper packages or other sorts of free accessories for non-free programs."
http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

And I think ndiswrapper is "a sort of free accessory for non-free programs."

To avoid another tangent: I'll grant that drivers are system programs,
and are not application programs, and that in the typical case they're
not associated with a specific process id.  For more detail on what programs
are, see http://en.wikipedia.org/wiki/Program_(computing)

> Given that this is how we understand "dependency" every other time we use it
> in the project, I think it would be inconsistent to say that ndiswrapper has
> a "dependency" on an indeterminate but large number of distinct Windows
> drivers.

Ok, we should probably find a different word to describe this
relationship.

Perhaps it could be phrased that ndiswrapper has a need for the presence
of some software which is not available in debian main.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Wed, 01 Mar 2006, Raul Miller wrote:
> > Let's grant that any "moving to contrib" will only happing in 
> > unstable/testing
> > (and future stable) releases of debian.
> >
> > Do you see a problem with moving these to contrib?  After all, everything
>
> Honestly I don't care enough about either those libs or ndiswrapper to
> oppose to the move to contrib. But I've given my interpretation of the
> policy and my rationale why they can/should be kept in main.
>
> Now, you use that input how you want and you make up your own opinion.

Ok, correct me if I'm wrong, here's how I'm understanding what you
wrote: You feel that the contents of the "contrib" section mentioned in the
social contract should be mechanically determined by debian package
headers, and not by a more general concept of dependency?

If that's not your point, I don't understand your input.

> > in conjunction with non-free software.  Why do you think these other 
> > packages
> > should not go in contrib?
>
> Because they are DFSG-free, they have no explicit dependencies on a non-free
> package and because they're not (installation) wrapper.

It sounds to me like you're saying that all packages in contrib could
be moved to main simply by removing the explicit dependencies in
their package headers?

> > We have to make assumptions about how software is normally
> > used to define reasonable values for dpkg headers like Depends:
>
> We're speaking of software of the user that is not packaged by us. I don't
> see how a dpkg Depends field is relevant here.

I don't see why you think the Depends field is the entire issue when
we're talking about "contrib".

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Wed, 01 Mar 2006, Raul Miller wrote:
> > > The real question was "What is the difference for a package if it enables
> > > the user to make use of his own software or his own hardware (whether free
> > > or non-fee) ?"
> >
> > I don't think that's the real question in the context of ndiswrapper:
>
> But we do have old libraries whose sole purpose is to support old
> proprietary applications linked against them. Those libs are DFSG-free,
> and we distribute them in main so that our users can make use of their
> apps without too much troubles.
>
> In a way, those libs are like ndiswrapper: they are useful only in
> conjunction with some non-free stuff. But IMO it's not a reason to move
> them in contrib ...

Ok, so you disagree with the idea that these should go in contrib.

Let's grant that any "moving to contrib" will only happing in unstable/testing
(and future stable) releases of debian.

Do you see a problem with moving these to contrib?  After all, everything
in contrib is free software.  Contrib is for free software that's only useful
in conjunction with non-free software.  Why do you think these other packages
should not go in contrib?

> > We've made promises in the social contract about what we will do
> > in the context of making free software depend on other software.
> > We haven't made any promises about making free software
> > depend on hardware.
>
> True. But we're diverging here, the placement of ndiswrapper is more an
> issue of policy than an issue of the social contract.

Except, that policy is based on the social contract.

> > > I think both packages enable the user to use "something he has" (whether
> > > software or hardware) and that it doesn't make much sense to treat them
> > > differently when both are DFSG free.
> >
> > What you said here does not make sense to me.  I have never encountered
> > a piece of hardware which satisfies the Debian Free Software Guidelines.
>
> "Both" refers to "both packages" (library and ndiswrapper). (and not
> software and hardware)
>
> Here's the full parallel :
>
> The library is free, has no reverse depends in main, is thus only provided
> for the user to compile and use software coming outside of Debian. We
> can't assume anything about the software that the user will use.

I disagree.  We have to make assumptions about how software is normally
used to define reasonable values for dpkg headers like Depends:

I don't think it's at all reasonable to claim we can't make assumptions that
we have to make.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> So you responded to my question out of its context... which was trimmed
> down due to the 2 subsequent answers. :-/

Ok.  And I think a part of the problem has been inexact expression,
where assumptions are important in understanding what a
person meant.

> The real question was "What is the difference for a package if it enables
> the user to make use of his own software or his own hardware (whether free
> or non-fee) ?"

I don't think that's the real question in the context of ndiswrapper:

To my knowledge, no one is writing their own software to use with
ndiswrapper.

Then again, maybe there's some ambiguity about what you mean
by "his own software"?  If a person does not own copyright on a
piece of software, I think that that software is not "his own", though
the instance -- the copy -- might be.

This might seem like an overly narrow distinction, but it's exactly
the sort of distinction that copyright law is based on.  And, since
we're engaged in making copies of software, and distributing
those copies, this is a critically important question for us.

Hardware, on the other hand, is out of scope for us.

We've made promises in the social contract about what we will do
in the context of making free software depend on other software.
We haven't made any promises about making free software
depend on hardware.

Does this make sense to you?

> I think both packages enable the user to use "something he has" (whether
> software or hardware) and that it doesn't make much sense to treat them
> differently when both are DFSG free.

What you said here does not make sense to me.  I have never encountered
a piece of hardware which satisfies the Debian Free Software Guidelines.

So I can't think of any reasonable way to construct a specific example of
the case you're talking about that you say doesn't make much sense.

So I can easily agree that "it doesn't make much sense", but I think you're
trying to suggest something else would make sense, that doesn't make
sense to me either.

> I hope the confusion is solved now. :-)

I'm still not sure if the problem is that I don't understand some relevant
point of yours or if the problem is that you don't understand some
relevant point of mine.

Maybe I should have instead said "We can't distribute any hardware:
in main, contrib, or non-free"?

--
Raul

Re: voting for the chair

[Raul Miller]

On 2/28/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Thanks, that seems to settle the issue and confirms me as the chair.

Excellent.

And, hopefully, we can have any ambiguity about the next
chair rotation(s) resolved relatively soon.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Tue, 28 Feb 2006, Raul Miller wrote:
> > On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > > What's so different between my own non-free program and my own non-free
> > > card which requires a non-free driver to work with ?
> >
> > We can't distribute any hardware in main.
>
> We are speaking of something that the user has (and that is not in main
> obviously)... please think in the context of the replies.

Huh?

I'll try again:

When you ask about the difference between non-free
programs and non-free hardware the difference is:

hardware is not software.

Hardware can not be free in the DFSG sense any more than
Debian Developers can be free in the DFSG sense.  Hardware
is not software any more than developers are software.

Both, obviously, are closely related to software, but
closely related is not "the same as".

We can have hardware that runs free software, and we
can have hardware that runs non-free software, but in
the context of Debian, it's meaningless to talk about
hardware being "free" or "non-free".

I reserve the right to distinguish between hardware
and software contained within that hardware, and
I'll be happy to discuss this issue with you in more
detail, and talk about how I see this relating to
the DFSG and Social Contract, but that is not the
question you posed.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> What's so different between my own non-free program and my own non-free
> card which requires a non-free driver to work with ?

We can't distribute any hardware in main.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/28/06, Anthony Towns  wrote:
> Okay, so I'll vote against both these.

Understood.

But I'd appreciate it if you could refine your arguments some more:

> After the discussions so far, I'm inclined towards the following two views
> of our policy on this:
>
> * first, that dependencies are one way -- programs depend on
>   libraries, but libraries don't depend on the programs that use
>   them;

I don't think that can really be true in the general case.  For example,
we have the "base system" where pretty much everything in base has
a mutual dependency on pretty much everything else in base.

> * and second, that programs that only operate when interacting with
>   non-free programs, whether over the net or via data files, aren't
>   considered to depend on those non-free programs.

The issue I thought was important in the context of ndiswrapper was: what
software has to be installed on the debian system for people to use
ndiswrapper?

I'm not sure that this general statement really refutes that position.

> That means that:
>
> (a) libraries that aren't used by any DFSG-free programs are okay
> for main, so packages like libamstd-ruby1.8 that provide a library
> that no package happens to use are still fine

If the issue is "what needs to be installed for people to use libamstd-ruby1.8
the way it's typically used" would there be any missing packages?

> (b) ndiswrapper is okay for main (non-free drivers depend on it, and
> there are no free packages that depend on it, but it does not depend
> on anything non-free)

I'm not saying you're wrong here, but I think we should find better examples
where the "what needs to be installed" logic falls down, if we're going to
go this route.

> (c) free viewers/players for proprietary formats (Word documents,
> mp3 players, etc) are okay for main

While this is true, I you're talking about content which can be
fetched by any user on a typical system.  There's no need for
the system administrator to install anything here.

> (d) free clients for proprietary protocols (for which there is no
> free server) are okay for main

Again, in the typical case there's no need for the administrator
to install anything.

> All of which are (ttbomk) existing practice.

I agree, and I think you're drawing the line in an appropriate place,
for the most part.

But I think this case -- <>... I think this case is on the wrong
side of that line.

> It would be consistent to invert either principle; but I don't think it
> would be practical to remove packages that would be classified under
> either (a) or (c) from main, and I think the relationship between (a)
> and (b) and (c) and (d) are pretty strong, to the point I can't really
> see why it would be fair to drop one without also dropping the other.

Could you comment directly on the issue I've <> above?

Thanks,

--
Raul

Re: Status of resolutions about TC tweaks

[Raul Miller]

On 2/27/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> You, me, and Anthony voted yes on Anthony's proposed rotation; Raul voted
> for the committee chair, did not vote on the proposed rotation;

For this vote, I'm casting my vote as a proxy vote under
Ian's control.

More specifically, I'm voting the same on the proposed rotation as
Ian has voted.

I'm voting this way because of the time pressure imposed by the
proposed schedule.

FYI,

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/27/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> On 2/21/06, Raul Miller <[EMAIL PROTECTED]> wrote:
> > 1 "open source" windows driver available (can be used with ndiswrapper)

> Well, I couldn't find any trace of "1" ever happening.  If it ever
> happened, then it's ok.  But as far as I know, the Ralink company went
> directly to 2 (porting there non-free windows driver to linux, and
> then making it free).  Can you provide any evidence that 1 ever
> happened?

You could be right.  I was going on second-hand evidence, and it
may very well be that the open source drivers that were being ported
were really linux drivers for other ralink hardware.

Note that we have a more general problem here -- we should not
have to find the answer to an open-ended question to determine
the suitability of a package for main.

If a package requires something else to be installed before it can be
used, we shouldn't have to figure out whether or not there exists a
suitable free version of that other software -- if it's not in main, we know
that this other software hasn't been packaged, and that should be
sufficient to push package which requires it be installed into contrib.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/27/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I like your improvement to the first paragraph, so if I may I would
> like to accept that as a change to my original proposal (which has
> been voted down anyway).

No problem -- that fits with my intention.

> I would be happy to place your version over Further Discussion, but I
> still prefer mine (with the modification to para 1.)
>
> JOOI, why did you delete:
>
>  AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
>  ...
>
>  10. The Policy Manual maintainers should take steps to adjust the
> language regarding main and contrib to clarify and improve it.  The
> Maintainers should take our opinion in paragraphs 7 and 8 as
> advisory; they should also have regard to opinions from the Leader
> about the correct effect.
>
> ?

Oops.

That was an artifact of the quoting you used and the
mail client I used.  I had not intended to remove that
paragraph.  if I had been more careful, I would have
noticed its absence and would have included it.

I withdraw my proposal as originally stated, since it was
incomplete.  Please feel free to incorporate its text
in another proposal.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

Ok... silence.

This might mean:

(1) everyone is busy
(2) people feel they need to think about this further
(3) the modified version of Ian's proposal that I posted doesn't
properly address some ndiswrapper issue
(4) that proposal might cause some problem for other packages
(5) something else

If it's (2) or (4) perhaps someone could hint at things that might be
problem indicators?

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

This is my rephrasing of Ian's proposal.  Changes:

(*) Emphasize the debian dependency issue.
(*) Emphasize that this is a recommendation, not a command.

Basically, I'm repeating what Ian has already said.

I'm proposing this as a votable option.

Thanks,

--
Raul




WHEREAS

1. ndiswrapper's purpose is to allow non-debian (and typically non-free)
drivers to be used.

2. While there may be cases where ndiswrapper can be used
  with a DFSG-free driver, these are exceptional, and
  none of these drivers are available in Debian main.

3. The Committee is by and large satisfied with the intent behind the
  language in the Policy Manual regarding the distinction between
  non-free and contrib.

4. The Committee does not wish to overturn or change established
  political policy about the distinction between main and contrib,
  and does not wish to usurp the political authority of the Project
  Leader.

5. The Committee's reading of the current Policy Manual wording is
  that ndiswrapper falls fairly clearly into the area currently
  defined for `contrib'.

6. However, the language in the Policy Manual is somewhat unclear and
  ambiguous, and by some readings inconsistent.

THE COMMITTEE RECOMMENDS THAT

6. ndiswrapper belongs in contrib.

7. References to `package outside of main', `packages which are not in
  our archive at all', etc., in the relevant part of the Policy
  Manual, should be changed to refer to `programs' or `software'.

8. The policy manual should be clarified to make it clear that free
  software to talk to non-free software over a network can remain in
  main.  In our opinion the relevant principle is that:

 (i) If the user or administrator who is in charge of the Debian
  installation would have to adopt non-free software X to make
  sensible use free software Y, then Y goes in contrib.

 (ii) However, if free software Y is used by the user or administrator
  of the Debian system to cope to with someone else's use of non-free
  software X on another system not under their control, then Y goes
  in main.

AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS

9. ftpmasters and the ndiswrapper maintainers should cooperate to move
  nsidwrapper to contrib.

-30-

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/23/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Up until this evening I was of the opinion that this was the case; then
> Anthony presented an analogous scenario on IRC that I found persuasive.
> Supposing that lesstif had not been written yet today, and there were no
> free packages in Debian that used this API, would lesstif have to be put in
> contrib?  And I think the answer is no; I think writing a new free software
> application to use the motif API would be lame and not worthwhile, but
> that's indeed not a reason to put lesstif in contrib instead of main because
> lesstif doesn't depend on those applications, it merely extends the
> capabilities of the free operating system to include running motif apps.

This has been bothering me, too.  But there's several intertwined
issues here.

One issue is the time-sensitive nature of some of the relationships
between packages.

Another issue is the role of the package in the context of the user
community.

Debian dependencies are designed around "the typical user".  A package
would go into contrib if the typical user would have to install something
which isn't a part of Debian's "main" to use the package in the sense
which most people would mean if they were to talk about using it.

There are undoubtably border cases, and problem cases, but
I don't think the lesstif example is a problem here.

--
Raul

Re: Technical committee chair rotation, draft resolution

[Raul Miller]

On 2/22/06, Anthony Towns  wrote:
> On Wed, Feb 22, 2006 at 03:07:22PM +, Ian Jackson wrote:
> > If you believe that, then the whole thing is going to be far too much
> > hassle.  We can't be having a faffy voting election thing every month
> > or two just to routinely elect the chairman.
>
> We can't manage one mail each every two months?

A voting election is "one mail"?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> If we think they're not technical issues then we should issue an
> opinion anyway, IMO.  In practice in past when we've punted things
> away saying `this is not a technical issue' no-one else has stepped up
> to provide an opinion.  So we could say something like:
>
>   X.  We believe this is not a technical issue, so does not fall into
>   our explicit remit.  This decision is therefore advisory.
>   However, we recommend that all parties concerned follow our
>   advice unless and until a contrary statement is issued by the
>   Project Leader or an appropriate Delegate.

I think this would be a good idea.

> > This language suggests that we're not dealing with technical
> > issues.
>
> My aim here is to restrict ourselves to the narrow technicalities[1]
> and to try to interpret and clarify rather than change or make policy.
> The policy is by and large reasonable from a technical point of view.
>
> [1] Of course `technicalities' != `technical issues'.

Ok.

> > > THE COMMITTEE CONCLUDES THAT
> >
> > If this is outside our jurisdiction (and I suspect that's the case), I
> > think this should be "RECOMMENDS THAT" not "CONCLUDES THAT".
>
> We can `conclude' whatever we like.  To conclude is to complete a
> chain or argument or reasoning, and thus form a conclusion (ie, a
> grounded opinion).

Unfortunately, those are not the primary meanings of the word at
http://answers.com/conclude

> > >  (i) If the user or administrator who is in charge of the Debian
> > >installation would have to adopt non-free software X to make
> > >sensible use free software Y, then Y goes in contrib.
> >
> > Note that in the case of ndiswrapper this issue is a time-sensitive
> > issue.  There appear to have been times when the user could have
> > made sensible use of ndiswrapper installing only free software.
>
> But then the software wasn't available in Debian at all.  contrib
> seems clearly indicated for that.

This reasoning suggests that 8.(i) should read

  (i) If the user or administrator who is in charge of the Debian
  installation would have to adopt software X which is not available
  in main to make sensible use free software Y, then Y goes in contrib.

> > You've put some very good suggestions into your proposal, but I'm
> > not going to vote for it as it stands.
>
> OK.  Well, I'm happy to accept refinements.

I think I've expressed all my ideas.  I'll write up a modified proposal
tomorrow if you've not already done so.

Thanks,

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul Miller writes ("Bug#353277: ndiswrapper in main"):
> > It looks to me as if the sequence of events was:
> >
> > 1 "open source" windows driver available (can be used with ndiswrapper)
> > 2 someone ports windows driver to linux
> > 3 linux driver available
> >
> > These events are sequential, and event 3 does not erase event 1.
>
> Was the open source windows driver ever available as a Debian
> package ?  It seems clear to me that anything which requires you to
> install non-Debian stuff on your machine belongs in contrib, even if
> the reason for the dependency being non-Debian is not non-freeness.

I don't believe it was ever available as a Debian package.

I'll also note that the "require" concept here gets interesting,
in this context,  as it's different from the concepts expressed in
our packaging system.

--
Raul

Re: Technical committee chair rotation, draft resolution

[Raul Miller]

On 2/21/06, Anthony Towns  wrote:
> Augh, we just agreed on a rotation, why a new one now? Downside to the
> above: it schedules newbies and oldbies together rather than interspersing
> them (Me then Andy; Bdale then Ian).

Because the dates on the original proposal were already invalidated
by our procedures, before the proposal was accepted?

Personally, I'm happy with either proposal, but because of this date
sensitivity I'm standing by my earlier position on this issue: I'm willing
to go along with whatever Ian thinks is best.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I miswrote `achieved' as `required'.  So I withdraw my previous motion
> and propose the following instead, and call for a vote.
>
> WHEREAS
>
> 1. ndiswrapper's purpose is to allow non-free drivers to be used.
>
> 2. While there may be cases where ndiswrapper can be used
>with a DFSG-free driver, these are exceptional.

Are these technical issues?  I'm on the fence about whether these
are or are not technical issues,.  If they're not then they're outside
our jurisdiction.

> 3. The Committee is by and large satisfied with the intent behind the
>language in the Policy Manual regarding the distinction between
>non-free and contrib.
>
> 4. The Committee does not wish to overturn or change established
>political policy about the distinction between main and contrib,
>and does not wish to usurp the political authority of the Project
>Leader.

This language suggests that we're not dealing with technical
issues.

> 5. The Committee's reading of the current Policy Manual wording is
>that ndiswrapper falls fairly clearly into the area currently
>defined for `contrib'.
>
> 6. However, the language in the Policy Manual is somewhat unclear and
>ambiguous, and by some readings inconsistent.

This point also makes me dubious about our jurisdiction on this issue.

> THE COMMITTEE CONCLUDES THAT

If this is outside our jurisdiction (and I suspect that's the case), I
think this should be "RECOMMENDS THAT" not "CONCLUDES THAT".

Also note that this issue (what is the software used with) covers
a lot of ground, and that the general question of interoperability
is something that I think is of fairly broad importance to the free
software communitees.

>  (i) If the user or administrator who is in charge of the Debian
>installation would have to adopt non-free software X to make
>sensible use free software Y, then Y goes in contrib.

Note that in the case of ndiswrapper this issue is a time-sensitive
issue.  There appear to have been times when the user could have
made sensible use of ndiswrapper installing only free software.

Since then, the free software in question has been ported to
linux.  But this concept of "sensible use" seems... flighty.  I think
we need to allow that someone might have made reasonable
decisions in the past.

You've put some very good suggestions into your proposal, but I'm
not going to vote for it as it stands.

Thanks,

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> On 2/20/06, Raul Miller <[EMAIL PROTECTED]> wrote:
> > As a specific counter example, consider
> > http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
> > which is a project porting a windows driver to linux.  This port
> > appears to be possible because the windows driver was made
> > available under a free license.
>
> With this particular driver, I think you are making a mistake.  rt2x00
> is available as an independent driver (i.e. without ndiswrapper).

What is my mistake?

It looks to me as if the sequence of events was:

1 "open source" windows driver available (can be used with ndiswrapper)
2 someone ports windows driver to linux
3 linux driver available

These events are sequential, and event 3 does not erase event 1.

> As can be read in the project's history [1], the open-source project
> started because Ralink decided to release the Linux drivers under a
> free license.  There's no mention on the page of a Windows driver.

So the mention is not on that particular page, and is on a different
page.  Why is this a problem?

Note: I'm not saying there is no problem.

But if we're going to change our rules for "acceptable in main" from
"FOO is allowed in main if FOO is free and everything FOO requires
for installation is free" to "FOO is allowed in main if the typical use of
FOO can does not involve any non-free software" then we have a
much bigger issue than ndiswrapper.

And if we're going to tackle this issue properly, we need to define
the problems clearly before we can even begin to come up with a
decent solution.

For example, while we might want to define a "six degrees of separation
free" debian subset, but before we could do that we'd need to have
a good idea of what goes in that subset, how people that use it can be
sure that that's what they're getting, what we're going to do about
people who have come to rely on other software, etc. etc.

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/20/06, Anthony Towns  wrote:
> AFAICS, this would come under the "overrule a developer (3:1 majority)"
> power.

That's a good point.

While there are technical issues here (such as: "what software does ndiswrapper
depend on?"), they are not the deciding issues.   The core issues are more like
"how will most people use ndiswrapper"?

Focusing on the technical aspects is probably the wrong thing to do in
this case.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/20/06, Robert Millan <[EMAIL PROTECTED]> wrote:
> I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib.

This proposal is clear enough.

> My reasons are:
>
>   - The sole purpose of these packages is allowing the use of non-free Windows
>   drivers.
>
>   - There are no free Windows drivers for this interface, except a port of a
>   Linux driver to Windows (cipe), which is only used on native Windows
>   platform (since it is pointless to emulate it from Linux, where the original
>   cipe is already available).

I'm not sure I agree with this.

When I look at the list of drivers that ndiswrapper supports
http://ndiswrapper.sourceforge.net/mediawiki/index.php/List
I see several that seem to be open source.

You've asserted that none of these drivers satisfy the DFSG,
but I think we would need more than an assertion on this issue.

As a specific counter example, consider
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
which is a project porting a windows driver to linux.  This port
appears to be possible because the windows driver was made
available under a free license.

--
Raul

Re: Tech ctte tweaks

[Raul Miller]

On 2/17/06, Anthony Towns  wrote:
> Otherwise, Raul's vote has to be excluded so we're still waiting on an
> outcome; and it's not entirely clear that any of the votes are binding
> in any way :(

Eh... basically my vote on this issue is to go along with whatever
Ian thinks we should do on this issue.

I mean, he is the chairman, and we're talking about what the chairman
should be doing.

If you'd left more time for discussing this matter, I'd be inclined to
go into this in more depth.  But you didn't, so I'm not.

I don't really care if we go about this formally or informally.  I don't
care if it involves a "stepping down" step or not.  But I do think that
Ian's opinion -- as the current chairman -- carries a lot of weight on
this issue.

--
Raul

Re: Tech ctte tweaks

[Raul Miller]

On 2/14/06, Anthony Towns  wrote:
> Mine's: 1. Steve, 2. Bdale, 3. Andy, 4. Raul, 5. Me, 6. Ian, 7. Further 
> discussion

I believe I've already submitted my vote:

[1] Steve, contingent on Ian stepping down
[2] Further discussion

--
Raul

Re: #342455

[Raul Miller]

On 2/10/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> ... follow-up to self: given that crypt-dm sits on top of devmapper, it is
> indeed plausible that one would want to prevent members of group disk from
> reading the decrypted volume.

So don't use group disk in that context.

Just because a feature is available doesn't mean it has to be used.  Otherwise,
`chmod -R 777 /` would be a huge security hole.

--
Raul

Re: #342455

[Raul Miller]

On 2/10/06, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 10, 2006 at 04:40:22PM -0800, Steve Langasek wrote:
> > Otherwise, having access to the underlying block devices means having access
> > to meddle with anything on the LVM devices as well.
>
> And who says that anyone have access to the underlying device?

The same person who says who has access to group disk.

--
Raul

Re: #342455

[Raul Miller]

On 2/10/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul Miller writes ("Re: #342455"):
> > On 2/10/06, Ian Jackson <[EMAIL PROTECTED]> channelled:
> > > The proposed change to devmapper changes the permissions for all block
> > > devices, doesn't it ?  Whereas the other debian defaults vary from one
> > > kind of device to another.  For example, floppies are g+w floppy.
> >
> > The change to devmapper is inconsistent in the context of many groups
> > of machines.
>
> Um, are we talking about the same change here ?  I'm criticising the
> proposed change to the configure script which makes all the block
> devices start out g+w disk.

Yes, we're talking about the same change here.

If I have a cluster of debian machines (predating devmapper), by
default they'll all have block devices with g+w disk.

If I introduce devmapper systems into this cluster that will
not be true.

> > It's also inconsistent over time on many single machines.
>
> I agree that the current situation is unsatisfactory.  But I think (at
> the moment, at least) that it should be fixed by adopting Bastian's
> code fragments with an appropriate configuration.

I don't know what this means.

> > > For changing the `default' by changing the permissions at device
> > > creation time at the very least introduces a race, where the device
> > > briefly has the default permissions; if the defaults are maximally
> > > restrictive then this is OK.
> >
> > The debian defaults grant permission to an empty group -- one
> > which by default has no users -- this is maximally restrictive.
>
> This is rather disingenuous.  No-one would be complaining if the disk
> group remained empty.

That's demonstrably false: the disk group does remain empty on any
number of machines and people are complaining.  Even if the group is
not empty, access to the accounts which are members of that group
is under the control of the same person who gives access to root.

Last time I looked, when I created a new user account, I got a new
group with the same name which that user was a member of.  The
new accounts are not members of group disk.

Put differently: security is not about technology so much as it's
about the person who is responsible for the system understanding
what it's doing.  The details follow from the goals of the person
responsible for the system.

--
Raul

Re: #342455

[Raul Miller]

On 2/10/06, Ian Jackson <[EMAIL PROTECTED]> channelled:
> The proposed change to devmapper changes the permissions for all block
> devices, doesn't it ?  Whereas the other debian defaults vary from one
> kind of device to another.  For example, floppies are g+w floppy.

The change to devmapper is inconsistent in the context of many groups
of machines.

It's also inconsistent over time on many single machines.

> For changing the `default' by changing the permissions at device
> creation time at the very least introduces a race, where the device
> briefly has the default permissions; if the defaults are maximally
> restrictive then this is OK.

The debian defaults grant permission to an empty group -- one
which by default has no users -- this is maximally restrictive.

--
Raul

Re: #342455

[Raul Miller]

On 2/10/06, Roger Leigh <[EMAIL PROTECTED]> wrote:
> I did read this, and I'm happy progress is being made.  However, the
> default is still currently wrong in unstable, and the fix is a simple
> change to configure in debian/rules.

I agree that the devmapper default should match other
debian defaults, and vice-versa.

And since I don't see any credible reasoning for changing
the defaults on other packages (especially for stable), I
think you're right that devmapper's default needs to be
changed.

If need be, we can issue this as a formal opinion.  (If I
don't hear any reasons why this would be a mistake, in
the next few days, I'll make this a formal proposal.)

Thanks,

--
Raul

Re: Tech ctte tweaks

[Raul Miller]

On 2/7/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> It seems to contradict 6.1.7 of the constitution as written to have an
> automatically rotating chair, however.  Are we amending the constitution (no
> way to get that done by the 15th), or is this just an informal agreement for
> each chair to vacate after a term of two months?

I don't think we need to amend the constitution for that.

I mean, the constitution says that the vote for the committee chair
begins a week before the chair would be vacated, and that all
members are nominated.

For Anthony's proposal, (which I think Ian tentatively agreed to) the chair
would (assuming I'm right about Ian's agreement) be vacated on 15 Feb,
which means that voting opens on 8 Feb.  [That's today.]

We are approaching this from a different angle than the constitution
implies -- we not only have everyone on the ballot, we have
everyone on the ballot in a scheduled fashion.  But unless someone
in the committee raises a serious objection to this approach, I
don't see that it should be a problem.

I'll vote in favor of this proposal -- contingent on Ian's continued
agreement.

Thanks,

--
Raul

Re: Tech ctte tweaks

[Raul Miller]

On 2/6/06, Anthony Towns  wrote:
> On Mon, Feb 06, 2006 at 10:33:37PM -0500, Raul Miller wrote:
> > On 2/6/06, Anthony Towns  wrote:
> > > I was thinking along the lines of "rules of order", which isn't much
> > > different from "advertising a guideline". The difference is if we set it
> > > up as a rule, people can be confident we'll adhere to it, whereas if we
> > > call it a guideline we might end up spending time wondering if we should
> > > adhere to it on each issue.
> > Eh... of course we already have something like this written into the
> > constitution.  But, sure, a little crisping up would probably be a good
> > thing.
>
> I don't see anything like that in the constitution?

I see this as a variation on a point made in 6.3.5 (No Detailed Design Work):

   The Technical Committee restricts itself to choosing from or
   adopting compromises between solutions and decisions which have
   been proposed and reasonably thoroughly discussed elsewhere.

It seems to me that you're making a suggestion about which proposals
are detailed enough

--
Raul

Re: Tech ctte tweaks

[Raul Miller]

On 2/6/06, Anthony Towns  wrote:
> On Mon, Feb 06, 2006 at 04:30:46PM -0500, Raul Miller wrote:
> > That could work, though it's odd that Steve gets a shorter time
> > in the chair than others.
>
> Two month terms offset by a month give 7 people a go at being chair
> at some point each year. It also lets us start sooner rather than later.

Huh?

I was thinking either (a) start the whole thing at the end of the month
rather than the middle of the month, or (b) start each term on the
15th of a month.

I guess you could argue that (a) is starting later rather than sooner,
but beyond that I don't get it.

> > Also, the handoffs are going to be interesting -- then again, the
> > whole "rotating chair" thing is going to be interesting.
>
> I don't see how they should be much of a big deal; the chair's mostly
> just first among equals.

Oh, it's certainly doable.  There'll just be a fair amount of gear
shifting (which is basically the point).

> > > (2) Requiring an implementation of proposals
> > > The md5sum "decision" is still languishing after a year and a half, and
> > ...
> > > So I propose we establish a rule that we won't make decisions on issues
> > > that aren't ready for an immediate NMU when we make that decision.
> > I don't know that we need to make a rule about this so much as
> > advertise a guideline.
>
> I was thinking along the lines of "rules of order", which isn't much
> different from "advertising a guideline". The difference is if we set it
> up as a rule, people can be confident we'll adhere to it, whereas if we
> call it a guideline we might end up spending time wondering if we should
> adhere to it on each issue.

Eh... of course we already have something like this written into the
constitution.  But, sure, a little crisping up would probably be a good
thing.

> mail. But as it stands, two months after referring the topic to the ctte,
> rleigh still couldn't tell if there was any resolution. So I think by mid
> to late December he should've been able to cite a first pass statement
> by Ian to the effect of "devmapper should setup inodes with permissions
> 0600, and ownership as root.disk", possibly with a rider that that's
> the chair's opinion not a final decision or whatever, but without any
> devil's advocacy or further questions having already been dealt with.

Ok.  That was already my impression of how things are going, and
I guess you're saying we should be more emphatic earlier in the
process.

> Second change is that I don't think the tech ctte should consider
> unimplemented proposals; so while Bastian's ideas might be great,
> our choice of resolution is "leave it as it is" or "implement rleigh's
> patches"; obviously once Bastian's idea is implemented, it could replace
> either outcome, but until then we have to make a choice between things
> we can do now. That's from issue (2).

Hmm... I don't think we can consider anything but unimplemented proposals.

As a general rule, we're supposed to help solve unsolved problems.

Maybe you meant that we should not consider ambiguous proposals?
I can see that as a weakness of our approach on this issue.

Thanks,

--
Raul

Re: Tech ctte tweaks

[Raul Miller]

On 2/4/06, Anthony Towns  wrote:
> (1) Rotating the tech ctte chair
>
> Changing chairs every two months would mean everyone would be chair over
> the course of the year; helping ensure that we notice people who aren't
> active in a timely manner, and distributing the load a bit more fairly.
>
> I propose we do this, and for concreteness propose the following rotation:
>
> - Feb 14th  Ian Jackson
>Feb 15th - Mar 31st  Steve Langasek
>Apr  1st - May 31st  Bdale Garbee
>Jun  1st - Jul 31st  Anthony Towns
>Aug  1st - Sep 30th  Raul Miller
>Oct  1st - Nov 30th  Andreas Barth
>Dec  1st - Jan 31st  Ian Jackson

That could work, though it's odd that Steve gets a shorter time
in the chair than others.

Also, the handoffs are going to be interesting -- then again, the
whole "rotating chair" thing is going to be interesting.

> (2) Requiring an implementation of proposals
>
> The md5sum "decision" is still languishing after a year and a half, and
...
> So I propose we establish a rule that we won't make decisions on issues
> that aren't ready for an immediate NMU when we make that decision.

I don't know that we need to make a rule about this so much as
advertise a guideline.

> (3) Advisory opinions from the chair
...
> So I propose we establish that our procedure in addressing issues is
> for the chair to quickly issue an initial opinion; and to only vote on
> issues when an official ruling is needed (eg, to overrule a maintainer)
> or when members of the tech ctte disagree.

I'm not sure about this.

If we need someone to shoot from the hip, the package maintainer
seems just as good as anyone.  The point of the Technical Committee
is to provide a bailout when people disagree with that kind of thing.

Usually, that means that there's something seriously wrong -- some
critical piece of information isn't known, or some compatibility
issue means that more than one answer is a good answer and that
all of the good answers are bad answers...

I think I understand where you're coming from on this, but I'm
still uncomfortable with this solution.

But let's say we implemented this: what would do you think would
be different as a result?

If your primary concern is inactivity, how about something more
aimed at inactivity:  Allow the chairman to propose a solution
in some clear and formal manner, and if no one comments on
it for a week then it becomes the defacto solution for that issue
(this might require a GR to become valid for the project as
a whole).

Thanks,

--
Raul

Re: #342455

[Raul Miller]

On 2/2/06, Roger Leigh <[EMAIL PROTECTED]> wrote:
> It's nearly a month since the last mail to this bug.  Is this getting
> close to being resolved?

Did you notice the content of the message before yours in this bug's
history?  It's from Bastian Blank, and includes among other things the
statement:

  I developed the idea for this fix some months ago, but never found the
  time to implement it. So I should have refrained from tagging the bugs
  wontfix.

It seems like there's no longer any technical dispute here, but perhaps
some time management issues to solve.

(If there's some technical dispute, we should be doing something about
that dispute, but if the dispute is resolved, we should be getting out
of the way so that you can get on with supporting your packages.)

Anyways, if Bastian doesn't have time, I think an NMU would
be appropriate.  Of course, if you can work with him so that
your potential NMU meshes with his intended fix that would be
even better.

Put differently: if things stand where I think they stand, we should
re-assign this bug to to package maintainer.  [But let us know if
you think we're overlooking something important.]

Thanks,

--
Raul

Re: my thoughts on the devmapper question

[Raul Miller]

On 1/3/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> (AFAICT, for example, if the permissions have been configured locally
> somehow to be something like 0600 the configure option would result in
> a brief moment of 0660, which might be a security problem.)

Wouldn't that only be the case if

(a) devmapper is invoked with the default options?
(b) some untrusted account has permission to use the disk group?

Of course, I guess a part of the issue here is that devmapper is
invoked automatically with the default options.  But nothing requires
that any user have access to the disk group.

I'm not sure what happens if the "disk" group doesn't exist.  Perhaps
for that case, devmapper should fall back to 600 permissions and group
0?

--
Raul

Re: [Fwd: Re: Induction of new members to the technical committee]

[Raul Miller]

On 12/27/05, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> With bdale voting yes, along with me, and there being no
>  responses for a week, the quorumn of two was met, and the motion
>  passes.

My apologies, I should have realized this was a new issue that
needed to be voted on.

Belatedly: I would have voted yes if I'd been thinking things through.

Thanks,

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

On 12/23/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> Anyway, what are the problems with a default of 666? It fixes any
> of the problems.

Is this a serious question?

Access to group disk can be easily controlled by the
system administrator.  On some systems, only root
has this access, on other systems other ids also have
this access.  It's possible that all accounts will have
this access, but that's extremely rare.

That's not true for "other" -- everyone has access read
and write access to things with 666 permissions.

Do you need this explained further?

--
Raul

Bug#342455: Does anyone have anything more to say on the devmapper group/permissions issues?

[Raul Miller]

Is there anything more to be said about the devmapper group/permissions issues?

I've gone into this assuming that I've overlooked something important,
but so far I've not seen anything that makes me think that there's any
good reason for this conflict.

Does anyone have any credible reason why devmapper shouldn't use the
same defaults when creating a device as are used with other hard disk
devices?

Thanks,

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

On 12/17/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote:
> > On 12/16/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> > > On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
> > > > Are you saying that the current default permissions on (eg) /dev/hda*
> > > > are insecure and therefore wrong ?
> > >
> > > Yes, I overwrite them on my machines.
> >
> > And what is your reason for being unwilling to use the same procedure
> > on devmapper disks?
>
> Which procedure? You seem to know something I don't know. ("Overwrite"
> means in my context: chmod of static devices or a MODE setting in the
> udev config)

I'm trying to ask why you are unwilling to have devmapper disks provide
a default of root.disk 660?  Why can't you allow that to be the default?

Is there some reason you can't have implement your personally preferred
policy of root.root 600 on just your own system?  Is there some reason
for projecting your personal policies incompletely onto an arbitrary
subset of debian's users?

Is there something about this question I'm asking which doesn't make
sense to you?

> > Personally, I'm using a system where the only way to obtain root access
> > is to log in as root -- there's no privileges gained through suid binaries.
>
> Err? Write access to the device of a mounted filesystem is a way to gain
> root if you don't disable several options.

Quite a bit of stuff doesn't work the way you might normally expect, on that
particular system.

Anyways, good security means that the system works the way the person
responsible for the system think it's supposed to be working.

What you've done here introduces surprises and thus would tend to
degrade the security of debian users's systems (not directly but by
requiring that some people introduce ad-hoc and perhaps ill-considered
workarounds).

You seem to be asserting: "a malicious person who handles backups could
use the disk group to obtain root access, so you should force backup programs
to run as root."  But that does not seem to be a reasonable position:

(1) There are risks other than a malicious people -- by ensuring backup programs
don't have to run as root, we minimize the risks that such programs will do
something they weren't designed to do.

(2) A malicious person with physical access to the system can compromise
it in a variety of ways (boot with init=/bin/sh, replace the OS, add monitoring
hardware to the keyboard or the display, put a logic sniffer on the bus, etc.
etc.)

As things currently stand:

(A) The risk you're protecting against is not defeated by the measures
you propose.

(B) The measures you propose have not been accepted (or even discussed)
in the debian community at large.

(C) You've defeated some measures which make debian systems more
robust.

(D) You've clearly stated that you do not require that devmapper use these
defaults to implement your security policy.

I don't have any right to object to how you maintain your own personal systems,
but what you're inflicting on debian as a whole does not seem to make much
sense.

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

On 12/16/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
> > Are you saying that the current default permissions on (eg) /dev/hda*
> > are insecure and therefore wrong ?
>
> Yes, I overwrite them on my machines.

And what is your reason for being unwilling to use the same procedure
on devmapper disks?

Do you believe that debian should deliver a patchwork collection of
administrative decisions, such that every time a new package is
installed a new set of administrative policies must be learned and
new procedures must be adopted by the users?

Personally, I'm using a system where the only way to obtain root access
is to log in as root -- there's no privileges gained through suid binaries.
Perhaps you'd like to use some significant packages configured this way
since it fixes something I consider to be a security problem?

Note also that your inconsistency is an inconsistency.  You've not
fixed the "problem" in all packages, only one package.  You've not
proposed anything to the community in general which addresses this
issue.  Instead, you've created problems for people without really
improving the security of debian systems in general.

This is a good idea?

Why?

What good thing have you accomplished?

Thanks,

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

I've been looking at these bugs, and I can see no good reason for the 600
permissions, nor the reason to avoid using the disk group.

There also seems to be some huge confusion about where responsibility for
setting permissions and group should be handled.

Here's what I currently see suggested:

1) change devmapper defaults -- patch rejected, no reason given
2) explicitly use udev -- problem, this doesn't work for 2.4 kernels
(2.4 used devfs)
3) avoid using devmapper (but this is not a solution)

I've also seen the suggestion that we should have a explicit technical policy
that block devices should default to having 660 permissions with owner root
and group disk.  I don't have any objections to such a policy, but I don't
see that solving this problem should wait on the adoption of this policy.

Finally, I don't see any reasoning given for things being the way they are
currently.  There might be some such reason, but I'm a bit dubious --
if there was a good reason, why wasn't it spelled out months ago?

Based on what I've seen so far, I'd recommend that the defaults for
devmapper be changed using Roger Leigh's 7 Dec patch from the
329409 bug report be adopted, that Bdale Garbee's 19 Nov patch
from the same bug report be adopted, and that policy be changed
to specify the default group and permissions for disk devices.

And, yes, that's overkill and in that sense inelegant.  But system stability
and predictability is a higher priority than "do it once and only once".
With differing kernel and package versions, we have to allow at least
for transition times when the same issues are dealt with in different
packages.  (And, yes, all of this should be spelled out in detail in
some package -- preferably the package where the final responsibility
resides).

I'm hoping someone can tell me what I've overlooked -- what is so
important here that's prevented this issue from being resolved?

Thanks,

--
Raul

Re: Removing long inactive members from the technical committee

[Raul Miller]

On 12/3/05, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> I am formally proposing a resolution to remove the following
>  members from the technical committee:
>   o) Wichert Akkerman, since he has indicated that he is no longer
>  actively involved with the project, and asked to be let go,
>   o) Guy Maor , since it has been literally years since there has been
>  any communications from Guy on the tech ctte,
>   o) Jason Gunthorpe, for the same reason.

I'm in favor of this proposal.

Though I'll probably change my mind if any of the members we're considering
replacing object.

Thanks,

--
Raul

Bug#323035: Processed: referring issue to technical committee

[Raul Miller]

On 8/30/05, Robert McQueen <[EMAIL PROTECTED]> wrote:
> Raul Miller wrote:
> > It's not clear to me why this was assigned to the technical committee.

> The problem is that the maintainer refuses to concede that his packages
> are in violation of Debian's shared library packaging policy, or
> believes that this policy is incorrect or somehow irrelevant to his package.

That's definitely a problem, but it's not a technical problem.

> I was hoping that the technical committee might be able to discern which
> of these is the case, and then decide which elements need to be fixed
> and by whom, in order that the adoption of SILC-based software may
> continue in Debian.

If you had posed this as a technical question, we might have been able to
do something, but:

> However, it now seems that he's willing for someone else to maintain the
> package (see his mail on #273871), so it might be in order to orphan the
> package and close this technical committee bug.

You're probably right that it's best to simply close this bug.

Would you like to do the honors?

Thanks,

-- 
Raul