, and replace them with In order to become
compliant with XXX, developers will need to impliment the following
proceedures ...
Raul == Raul Miller [EMAIL PROTECTED] writes:
Raul This idea really appeals to me. We might want to excercise our advice
Raul power and make a statement to this effect
On Mon, Aug 09, 1999 at 10:27:25AM -0500, Manoj Srivastava wrote:
Since we called for votes a long time ago, can we hear from
the silent members of the ctte? Do we need new members (we are at the
low end of acceptable strngth of the ctte, I think).
I suspect that Guy and Ian have
I'm sending this email to a whole bunch of people because there's a
whole series of problems that I'd like to see resolved quickly.
Problems:
(0) the technical committee has no chairman.
(1) three of the technical committee members are not responding to
email (Klee Dienes, Guy Maor, and Ian
On Wed, Aug 18, 1999 at 02:28:36PM +0200, Santiago Vila wrote:
Hello Technical Committee.
This message from Wichert was posted nearly two weeks ago.
Yes.
Which is the current state of things?
(1) The technical committee does not have a chairman yet, so is not
able to properly vote on any
On Wed, Aug 18, 1999 at 09:31:44AM -0400, Dale Scheetz wrote:
Before we can decide on the current proposals before us, I believe we need
to settle the issue of the Chair, so we have a mechanism to call a vote.
As I understand the current situation, Raul and myself are the only two
On Wed, Aug 18, 1999 at 04:25:48PM -0700, Chris Waters wrote:
First of all, I'm still not convinced that this is a technical issue,
as I mentioned in my objection to Manoj's proposal. The information
is just as available whether it's found in one location or two, so
I don't see any technical
Raul == Raul Miller [EMAIL PROTECTED] writes:
Raul (*) debian policy 3.0.0.0 was ratified (which specifies the use of FHS
Raul in place of FSSTND) but it did not address how to manage the migration
Raul between the two standards. The implication is that all packages which
Raul have
Anthony Towns wrote:
Fourth, Raul also points out that debian-policy isn't a constitutional
body, it can only act under the auspices of the technical committee. That
is, just because we reach a consensus on -policy how to deal with an
issue, we can't suddenly declare 1000s of packages [2]
I'd like to question the current archive implementation -- where
email from non-committee member email addresses doesn't get
archived.
There's two problems with this:
(1) when we post from a non-official address, our mail doesn't
get archived.
(2) when someone proposes something to the
On Wed, 13 Jan 1999, Ian Jackson wrote:
...
On Tue, Aug 31, 1999 at 11:13:08AM -0400, Dale Scheetz wrote:
I got this message, but not the one to debian-ctte-private. I guess I'm
not subscribed?
I believe that debian-ctte-private does not yet exist.
However, please be aware that there's a lot
Raul Also, note that we need to address all the problems with our proposed
Raul strategy.
On Thu, Sep 02, 1999 at 10:49:38PM -0500, Manoj Srivastava wrote:
In which case, really, we should advice that a major upgrade
to slink be made with the updated versions of man, dwww, info,
As Ben has pointed out, we've got two empty seats on the committee, and
we might have more empty seats if some of our members are not going to
be able to actively participate.
I'd like to propose Bdale Garbee as a committee member.
In addition to his Debian background, Bdale is familiar with
On Fri, Apr 13, 2001 at 09:28:31PM -0400, Ben Collins wrote:
Thanks Raul. I'm not sure of the tech committee's process for coming to
a consensus on suggesting new members to the DPL (the constitution
doesn't seem to cover it specifically). If there's past precendence, let
me know. As for now,
On Sat, Apr 14, 2001 at 11:58:39AM -0400, Dale Scheetz wrote:
Strange, I get Ben's e-mail twice, but Raul's only once...
That's because you are both a moderator of debian-ctte and a
subscriber.
--
Raul
On Wed, Jun 13, 2001 at 04:44:22PM -0600, Bdale Garbee wrote:
Of course. I didn't mean to imply it was a slam-dunk... if it were, we would
have done it already and the set of crypto export questions we're asking would
be different.
My real point was that being too pessimistic about the
Raul Miller [EMAIL PROTECTED] writes:
I wish we could have had more discussion on this issue. I know that
some of you are very busy.
On Mon, Jun 25, 2001 at 10:14:05PM -0500, Guy Maor wrote:
I was silent because I had nothing intelligent to say. Is this really
a technical issue
On Thu, Aug 23, 2001 at 11:28:12AM -0500, Branden Robinson wrote:
I would suggest that what the katie software currently does is
the right thing in the majority of cases. But once in a while,
circumstances will arise that require replacement of an .orig.tar.gz
without a rename. I am asking for
Also: please tell me what's wrong with releasing a 4.1.0.,dfsg version.
Actually comma is an illegal character -- but the following
alternatives look valid:
4.1.0.
4.1.0+
4.1.0+dfsg
On Thu, Aug 23, 2001 at 12:52:55PM -0500, Branden Robinson wrote:
Simply put, I don't want to do it.
You do
On Thu, Aug 23, 2001 at 03:25:09PM -0400, Raul Miller wrote:
You do understand that this isn't a technical issue?
On Thu, Aug 23, 2001 at 02:58:25PM -0500, Branden Robinson wrote:
It is, however, an issue upon which the Technical Committee is empowered
to rule:
I understand that. However
On Fri, Aug 24, 2001 at 04:43:40PM -0600, Bdale Garbee wrote:
I believe that we must have the ability to remove an orig.tar.gz and all
derived objects from the archive under certain circumstances which have
already been articulated by others. If the current toolset doesn't support
that, it
On Sat, Aug 25, 2001 at 12:05:10PM +1000, Anthony Towns wrote:
It means you can find yourself downloading an .orig.tar.gz from the right
place with the right name from one non-corrupt Debian mirror, and a .dsc
from another and ending up with the md5sum of the tarball not matching
the md5sum
On Wed, Jul 31, 2002 at 04:00:05PM +0100, Ian Jackson wrote:
I disagree. I think the project is too big for us to know well all
the possible applicants, and I think collecting some information from
applicants is a very good idea to help us choose.
I think Jason's point is that we would have a
On Thu, Aug 01, 2002 at 07:47:21PM +0200, Raphael Hertzog wrote:
Your analysis is quite good.
Ok, thank you.
But, really, I don't see the technical side of this issue. All the
badness is being confined to unstable, and it looks like the handling
of the problems in unstable falls within
Ian Jackson wrote:
No-one commented on it at all. Do people think it's a good idea ?
On Sun, Aug 25, 2002 at 10:44:55PM +0200, Martin Schulze wrote:
Well, having a working and competent Tech Committee sounds useful, no?
I concur.
I don't have anything significant to contribute here, but I
On Sat, Sep 14, 2002 at 06:36:25PM +0200, Raphael Hertzog wrote:
If you ask me to go on, ignoring whatever the committe could have to
say, I'd just ask Christian to move Gnome2 into unstable and the matter
would be done.
If there's no reason not to do this, then why not do it?
This can be
On Sat, Oct 26, 2002 at 09:34:47AM +0200, Eduard Bloch wrote:
Yes, you and Xu are of the same kind. You place some ideals (code
perfectness, even with harmless code) over user's wishes.
Please, Eduard, this discussion is not about the people involved, it's
about the technical merits of vesa fb
On Sun, Oct 27, 2002 at 01:37:43PM -0600, Manoj Srivastava wrote:
What I am unsure about is whether I have the grounds to cause
my judgment to override the maintainers in this case. I don't have
the hubris to assume that I know so much better than the maintainer.
I think we can trust
On Sun, Nov 10, 2002 at 05:52:08PM +, Ian Jackson wrote:
2. We have concluded that
* md5sum is significantly more useful if there is a way to
produce the `bare' output format (ie, without trailing ` -').
Hmm.. sorry, I let this one slip by me.
What breaks? [An understanding
* Raul Miller [EMAIL PROTECTED] [2002-11-11 18:05]:
What's so hard about using apt to search for packages with the
dependency, emailing those package maintainers?
On Mon, Nov 18, 2002 at 03:28:04PM +0100, Martin Michlmayr wrote:
Both dpkg and textutils are essential, and there is no md5sum
On Fri, Oct 29, 2004 at 10:06:48AM +1000, Anibal Monsalve Salazar wrote:
This vote call is 7 weeks old. May the debian-ctte members vote Ian's
proposal, please.
I've read http://lists.debian.org/debian-ctte/2004/09/msg6.html
already. I think, we need the debian-ctte's opinion on this
I vote in favor of this resolution.
--
Raul
On Wed, Sep 15, 2004 at 11:32:01AM +0100, Ian Jackson wrote:
(I accidentally failed to send my last message to the committee list.
My apologies! Here is a slightly edited version, taking into account
a correction from Steinar.)
It looks like
On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman [EMAIL PROTECTED] said:
The proposal in bug #166718 and the bugs merged with it is for the
initial user to be added to some set of groups. Karl does not like
this proposal because it only solves the problem for the initial
user. That's
On Thu, Apr 01, 2004 at 10:19:42PM -0500, Sam Hartman wrote:
Agreed. Traditionally, however, Unix has not been in the practice of
being easy to use. We should be careful, not hidebound.
That depends.
Once upon a time, security wasn't much of an issue, and ease of use for
the casual user was
On Tue, Apr 27, 2004 at 02:15:01AM +1000, Anthony Towns wrote:
Dear technical ctte, if you are able to come to a conclusion on this
topic, please make a decision as to whether the social contract requires
non-free documentation, firmware, etc to be removed from main before
release.
So...
[Note: I've removed aj from the explicit followups to honor the
Mail-Followup-To: headers on his message.]
On Tue, Apr 27, 2004 at 02:52:27AM +1000, Anthony Towns wrote:
The key questions to my mind are:
* are there any other possible release policies on this issue
(than delay
On Tue, Apr 27, 2004 at 02:15:01AM +1000, Anthony Towns wrote:
Dear technical ctte, if you are able to come to a conclusion on this
topic, please make a decision as to whether the social contract requires
non-free documentation, firmware, etc to be removed from main before
release.
Do you
On Tue, Apr 27, 2004 at 04:53:36AM +1000, Anthony Towns wrote:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sarge-ignore
I started working through this list, but its sheer size is intimidating
-- I don't think I can come up with any point-by-point solution to all
these problems in the next
On Mon, May 03, 2004 at 04:45:57PM +0100, Ian Jackson wrote:
I'd fallen off the committee list (again).
I was off the list myself, until recently -- someone else noticed
(unfortunately, I forget who and haven't been able to find the relevant
email message) and had my subscription reinstated.
--
On Fri, May 07, 2004 at 01:56:47PM +0100, Ian Jackson wrote:
* I claim that the annotated behaviour is inferior, for two reasons:
Firstly, it is less convenient. When md5sum is used in scripts and
the like, it is significantly easier to use if a script can get it
not to annotate
On Mon, May 10, 2004 at 08:32:24AM -0700, Guy Maor wrote:
I agree that the version without the - is more useful, but I'm not
completely convinced that the coreutils maintainer should change it.
If it's already been changed several times, then I see no
reason why it should not be changed.
What
On Sat, May 22, 2004 at 12:08:01AM +0100, Ian Jackson wrote:
Raul Miller writes (Re: md5sum FILE produces spurious ` -' in output):
I do wish we has a better way of saying request (or require [if we have
sufficient supermajority]).
Perhaps we should just write `require' in draft
On Wed, May 26, 2004 at 12:53:41AM +0100, Ian Jackson wrote:
IME people nearly always put FD ahead of the options they disagree
with.
However, it's possible for people to think that two options
are acceptable, even though they have a distinct preference
for one over the other.
--
Raul
I vote yes to this resolution.
Thanks,
--
Raul
On Sat, May 29, 2004 at 06:19:10PM +0100, Ian Jackson wrote:
Ian Jackson writes (Proposed resolution Re: md5sum FILE produces spurious `
-' in output):
Well, now there are four of us who've replied so it seems we're not
going to be lacking
Manoj Srivastava writes (Re: Social Contract GR's Affect on sarge):
I think we should not interfere in whatever solution the
developers come up with, since we are not actually involved as a
group in the solution process.
Note that we as a group haven't formally agreeded to do this.
Raul Miller writes (Re: (forw) [EMAIL PROTECTED]: Re: Posting on the list
[EMAIL PROTECTED]: Re: md5sum FILE produces spurious ` -' in output]]):
I can probably live with things the way they are now, as far as spam
filtering.
On Fri, Jun 04, 2004 at 09:59:59PM +0100, Ian Jackson wrote
Here's the main issues as I see them:
[1] Existing body of work/historical precedence -- we've already got
a bunch of packages with amd64 in the name and a dpkg with x86-64
hardcoded in it (specifically, in dpkg-architecture.pl in the hash
%archtable we have the key x86-64 and the value
On Wed, Jun 16, 2004 at 08:56:31PM -0400, Stephen Frost wrote:
There are other heuristics in place to fight SPAM on the Debian lists
already. I'm on quite a few of them and I see an occational SPAM, but
not much, really. I've also got my own spam-filtering in place, of
course, which I
On Mon, Jun 21, 2004 at 03:17:45PM -0500, Manoj Srivastava wrote:
On Fri, 18 Jun 2004 01:07:54 +0100, Ian Jackson
[EMAIL PROTECTED] said:
* In our opinion the porting team are the right people to be
deciding on the architecture name, in general.
* In our opinion there is no
On Tue, Jun 22, 2004 at 03:45:56AM -0700, Blars Blarson wrote:
It would make a lot more sence to throw the hardware at spam-filtering
algorythims are already known to work and don't cause hassles to the
mail senders.
Hardware isn't application specific.
I agree that 99.99% accurate spam
On Wed, Jun 02, 2004 at 09:49:05AM +1000, Pascal Hakim wrote:
I've seen figures as high as 85% of email to Debian lists being spam
talked about. No more than 1% of that hits my inbox. That's impressive.
Spam mails fake headers anyway, a c-r system would not stop the spam,
it would just make
On Wed, Jun 30, 2004 at 08:57:59PM +0100, Ian Jackson wrote:
http://catless.ncl.ac.uk/Risks/23.18.html#subj10
I have reason to believe that Steven Bellovin's criticisms are being taken
seriously -- it's possible that future SPF drafts will have addressed
all of his concerns.
That said, I think
On Fri, Jul 02, 2004 at 12:20:44PM +0200, Wichert Akkerman wrote:
Amusingly I encountered a SPF filter for the first time this week: a
mailserver rejected an email from declaring it was spoofed. Only it
didn't see that the mailserver that contact it was only relaying the
message and was not
http://seehuhn.de/comp/GR2004-004.html
Seems to indicate that option B is likely to win.
Given that the old release policy was implicitly based
on an ambiguous interpretation of the social contract,
and given that the release manager has asked us to take
a hand in deciding about release
On Sun, Jul 04, 2004 at 09:36:20PM +0100, Ian Jackson wrote:
I'm not sure whether the transition guide document was useful, but I'm
convinced it wasn't a good thing to have as part of the social
contract, entrenched so that only a 3:1 general resolution can change
it !
How else can you have a
Raul Miller writes (releasing sarge):
We ratify the current release policy with the additional note that dfsg
issues which would have been ignored before GR 2004-003 shall be tagged
sarge-ignore.
On Sun, Jul 04, 2004 at 09:39:35PM +0100, Ian Jackson wrote:
Um, yes. (We should wait
On Tue, Jul 06, 2004 at 02:16:50AM +1000, Anthony Towns wrote:
Uh, can we have something more descriptive than just the current
release policy,
That's no problem, we could quote the specific document.
and avoid dictating mechanism (sarge-ignore) rather than just policy?
Well, it's impossible
I'm thinking we should ratify it, as is. As soon as possible.
On Sat, Jul 10, 2004 at 04:31:08PM +0100, Ian Jackson wrote:
Gads, do we really need to ratify the entire text of this document ?
We don't need to. But, why not? That's what was delegated to us.
If anything, it may be that that
Is it acceptable to everyone if the technical committee tacitly approves
the current release policy?
[Which is to say -- we've seen it, we've not raised any significant
reasons to change any of it, so we're opting for the default which is
that it's ok.]
?
Thanks,
--
Raul
[Personally, I've been pretty busy the last few weeks and expect to
remain busy for a few more (two weekends ago, it was work, but since
then it's been unexpected family obligations). However, I've a free
couple hours at the moment...]
Currently, we've been asked to makes some decisions about
On Thu, Aug 19, 2004 at 04:37:49PM -0500, Dirk Eddelbuettel wrote:
Please see #266762 for any discussion on this.
Can you explain why a Policy violation (i.e. not providing shared
libs for a -dev package) is of Severity: wishlist
Again, see #266762.
esp. in the context of repeated FTBFS
On Fri, Aug 20, 2004 at 01:22:44PM +0200, Steinar H. Gunderson wrote:
I think you've missed a point here (all times converted to UTC):
2004-08-19 11:38: #266837 gets filed as a serious bug against rpvm.
2004-08-19 21:26: Dirk reassigns #266837 to pvm.
2004-08-19 21:30: I set #266837 to
On Sat, Dec 11, 2004 at 11:04:47AM +, Martin Michlmayr wrote:
Debian buildds. So just doctoring around a failure on a buildd by
building it in a different environment is not healthy in the long run
because we need to make sure that the buildd is capable of building
every package.
On
On Tue, Aug 31, 1999 at 04:18:19PM -0700, Joseph Carter wrote:
Didn't we come up with a good and reasonable solution to that problem? =p
Well, to deal with one particular aspect of incrementel upgrading there
are some people (very competent developers, overall) who are seriously
proposing that
[Earlier today I posted saying I didn't think this was a problem.]
[I was wrong.]
On Wed, Sep 01, 1999 at 09:20:38AM -0500, Manoj Srivastava wrote:
Is this not just an issue of swetting MANPATH defaults?
I'm very glad that you brought this up.
There's still a problem here: If
I'm sending this message as a test message, because my MDA has been
changed, and I want to make sure I still get committee email.
I'd like to also take this opportunity to make a few observations about
the committee:
The committee has never been popular. People have objected to its
actions, its
On Sat, Mar 19, 2005 at 02:05:10AM -0800, Blars Blarson wrote:
The claimed basis for not wanting my uploads were technical.
If that's the case, you failed to relay this information.
You said:
. The sparc buildd maintainer insisted that I stop doing so, claiming
. that I was causing problems
On 6/12/05, Christian Perrier [EMAIL PROTECTED] wrote:
Honestly, I'm having hard times to make my own mind and I need help
and wise advice on that issue. I personnally tend to favor the
current choice of only one prompt, but this is definitely not a strong
position.
Is this true even after
On 8/14/05, Debian Bug Tracking System [EMAIL PROTECTED] wrote:
reassign -1 tech-ctte
Bug#323035: libslc violates library policies
Bug reassigned from package `libsilc' to `tech-ctte'.
It's not clear to me why this was assigned to the technical committee.
There's definitely some issues here.
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:
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
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
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
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
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)
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:
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
On 2/6/06, Anthony Towns aj@azure.humbug.org.au wrote:
On Mon, Feb 06, 2006 at 10:33:37PM -0500, Raul Miller wrote:
On 2/6/06, Anthony Towns aj@azure.humbug.org.au wrote:
I was thinking along the lines of rules of order, which isn't much
different from advertising a guideline
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
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
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
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
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
On 2/21/06, Anthony Towns aj@azure.humbug.org.au 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
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
On 2/22/06, Anthony Towns aj@azure.humbug.org.au 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
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
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
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
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
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
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
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
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
On 3/2/06, Anthony Towns aj@azure.humbug.org.au 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
On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote:
On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote:
On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote:
But it doesn't -- ndiswrapper will sit there quite beningly if the
non-free
driver isn't present. It'll do
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
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
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)
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
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
1 - 100 of 128 matches
Mail list logo
