Re: GPL and command-line libraries

[Raul Miller]

On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote:
> What I am concerned about is the following scenario:
> 
> Mr. John Wontshare writes a streaming multicast client.
> To deal with packet loss, he uses my error-correcting library.
> Without my library, Mr. Wontshare's client can't work at all.
> Mr. Wontshare's client represents only a small investment of effort and
> without having had access to my library, he could have never written it.
> He then distributes his client along with my library to end-users.
> 
> These users don't get Mr. Wontshare's code, even though he uses my library.
> Even worse, he refuses to port his client to MacOS X for business reasons.
> (intentionally giving an unfair competitive advantage to another platform)

Given that Mr. Wontshare's client represents only a small investment of
effort, "refuses to port" doesn't sound like much of a problem.

Regardless of whether you make your code available under a simple API,
there's other possibilities:

Mr. Wontshare (or someone else) puts your library behind a simply api
and then builds some application which uses that api, and yet refuses
to release his code.

Someone works with the ecc concepts behind your code and reimplements
them in some proprietary code base.

Unfortunately, ideas are hard to protect in the first place, and the
laws aimed at protecting ideas were originally designed based on the
assumption that "not sharing ideas" is "protecting the ideas".

-- 
Raul

Re: LCC and blobs

[Raul Miller]

[just some minor additions.]

> On Thu, Dec 16, 2004 at 09:20:14PM -0500, Brian Thomas Sniffen wrote:
> > No, I argue that because you've pried chips off the board, the
> > hardware is broken.

On Thu, Dec 16, 2004 at 09:39:59PM -0500, Glenn Maynard wrote:
> Er, no.  Flash can be overwritten with invalid data (eg. nulls or
> interrupting a flash process), rendering drivers that expect a working
> flash to not work.

And some monitors can be driven in ways that cause them to burn out.

In both cases, there's a change in the electrical characteristics of
the device which renders it non-functional.

> It's not correct in the general case to say that "no driver can
> drive that"; some hardware can still be re-flashed to correct the data,
> so a driver that does have a (usually redundant) copy of the firmware
> and code to upload it can, in fact, drive the device.

In principle (depending on the board design), the flash data can be pulled
off the device.  We don't have to distribute the data to allow users to
reflash their devices.  [And, in the general case, we probably shouldn't
-- because we're not set up to track all the potential hardware changes,
and we're not in a position to make sure we're providing the proper
version of the data for the instance of hardware that the user has.
Of course, we'd also get it right in a number of cases.]

Fundamentally, the DFSG is aimed at making sure that we can provide the
software that we can support.  Restrictions that leave us writing an
opaque blob of bits which drives an unknown API very much put us into
a context where we can't know that we're doing the right thing.

> However, unlike non-flash devices that need the firmware uploaded
> every time, the driver is still useful without it.

Yes.

> Whether or not the "misflashed hardware is a broken device" analogy is
> bought, the fact remains that many copies of the hardware still do
> function, having working firmware.  The existance of non-working
> hardware is irrelevant.

Exactly.

-- 
Raul

Re: LCC and blobs

[Raul Miller]

> Raul Miller wrote:
> > Fundamentally, the DFSG is aimed at making sure that we can provide the
> > software that we can support.  Restrictions that leave us writing an
> > opaque blob of bits which drives an unknown API very much put us into
> > a context where we can't know that we're doing the right thing.

On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote:
> The API is known, otherwise there would be no Linux driver.

The API that is programmed by the firmware -- which you shouldn't confuse
with the API used by the driver that downloads the firmware -- is not
known to us.

> The fact that we uploaded the firmware does not excuse the device from
> respecting its API.

Personally, I've never found devices to be particularly apologetic
under any circumstances.

> Nor is it our task to write the firmware, Debian is a distribution for 
> general-purpose computers, if you want to have a distribution for firmware 
> you are free to do so.

Are you thinking that these firmware devices are not used in general
purpose computers?  If not, this seems about as relevant as the other
stuff you've said (which is to say: not at all).

> Debian should consider hardware as things that you have to talk to with a 
> certain protocol.

This would make all software which uses a well defined interface into
hardware

> It is useful to re-upload the flash. Nothing else. So what is the 
> difference between this use and the driver that has to load it every time?

The "has to" bit.

-- 
Raul

Re: LCC and blobs

[Raul Miller]

> Raul Miller wrote:
> > The API that is programmed by the firmware -- which you shouldn't confuse
> > with the API used by the driver that downloads the firmware -- is not
> > known to us.

On Fri, Dec 17, 2004 at 03:51:22PM +0100, Peter Van Eynde wrote:
> I don't understand you.

Hmm...

> An API is not "programmed".

Programs are written against an API.

The API represents the aspect of the computer which is being programmed
when you write a program.

> Something can provide or support an API or use an API.

"Use an API" can correspond to an "API being programmed" for the case
that that the use of the API involves the creation of a program to do
the using.

> In this case the firmware+hardware provides and API to the linux
> driver.

Sure.  But that's not the API I was talking about.

I was talking about the API the firmware uses -- the one that the program
contained in the API was designed to work with.

> It is known, we can support it.

Which has nothing to do with the issue I was talking about, because
you've got the wrong API.

> If the device has bugs in executing the API it makes no difference if
> there is a firmware or not to the driver, nor does it to our support
> because we don't provide the firmware, we only use it.

EXACTLY!

We don't provide the firmware.

And the reason we don't provide the firmware is that we don't understand
the issues well enough to do so.

This rather concisely captures what the DFSG is about.

> The mere fact of uploading the firmware does not give us an obligation to 
> support it.

And, in fact, we shouldn't support it.

> If your printer misprints a page you don't expect debian to patch it do you?

This is another good example.  And, taking it a bit further, I think
shipping a printer to me would be a waste of Debian resources.

[That said, I don't have a printer.]

> >>It is useful to re-upload the flash. Nothing else. So what is the 
> >>difference between this use and the driver that has to load it every time?

> > The "has to" bit.
> 
> If the "has to" is to do a specific task, eg connecting to a wifi network, 
> then the "has to" is no different from grub loading the XP bootsector.

We don't distribute the XP bootsector.

> In the other case the ipw2100 driver already loads and does some (very 
> limited) work.

The issue is completeness.

A piece of software which has to have some non-free software to become
functional is useless without that non-free software.

-- 
Raul

Re: LCC and blobs

[Raul Miller]

On Fri, Dec 17, 2004 at 10:33:41AM -0500, I clumsily wrote:
> I was talking about the API the firmware uses -- the one that the program
> contained in the API was designed to work with.

That should have read:

I was talking about the API the firmware uses -- the one that the program
contained in the firmware was designed to work with.

-- 
Raul

Re: LCC and blobs

[Raul Miller]

On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote:
> The social contract says "...but we will never make the system depend on 
> an item of non-free software." not "but we will never make the system 
> depend on an item of non-free software /which we must distribute/."

We don't make the hardware.

-- 
Raul

Re: LCC and blobs

[Raul Miller]

On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote:
> Please suggest any case which you don't think this criteria adequately
> covers.

The bios.

Unless, we decide that the bios we put in non-free isn't the bios we
need to boot the machine.

-- 
Raul

Re: LCC and blobs

[Raul Miller]

On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote:
> However, if somebody writes a graphviz-client which just pushes the
> dot file over the network to graphviz.example.com on some port and
> gets a postscript file back, it can go into main.  No matter what
> software said server is running.  Correct?

In essence, yes.

Do you have a problem netcat being in main?

-- 
Raul

Re: Licenses for DebConf6

[Raul Miller]

It seems to me that we have some responsibility for the licenses used
on these presentations.

It also seems to me that we should structure our approach to these
licenses similarly to the way we approach other license issues.

That is: we should encourage people to use a DFSG license, and we
should label the presentations to let people know whether it's
main/contrib or non-free.

We don't have to exclude non-free presentations to encourage free software.

However, unlike other conference holding bodies (such as the ACM), we
aren't really in the business of collecting and selling copyrighted
material.  So rather than asking for a transfer of license to
ourselves we should be asking for a DFSG copyright on the material.

But SHOULD is not MUST any more than it is SHOULD NOT or MUST NOT.

You build a community by encouraging participation, not by mandating
it (nor by discouraging or forbidding it).  This applies to our part
in the free software community as much as it applies to anyone's part
in any other community.

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/8/06, Nick Phillips <[EMAIL PROTECTED]> wrote:
> The GR as amended might appear to contradict the Social Contract, or the
> DFSG, but it certainly *does not* modify them, and hence cannot be said to
> require a supermajority.

This comment seems insincere.

If the GR is adopted by Debian, there is no significant difference
between "contradicts the foundation documents" and "modifies
the foundation documents".

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/9/06, Anthony Towns  wrote:
> On Wed, Feb 08, 2006 at 08:58:39PM -0800, Thomas Bushnell BSG wrote:
> > It's not about honor; it's about decision-making.
>
> When you raise the implication that your fellow developers can't be
> trusted, you make it about honour; when you think it's important to
> move a decision from one set of hands to another in order to ensure the
> "right" decision is made, that's a pretty direct implication that you
> don't trust the first group.

Is this courtesy to be extended to the project secretary?

If not, why not?

> > If a majority sincerely believe that their proposal does not run afoul
> > of the 3:1 requirement, does that mean that it therefore does not?
>
> If the secretary sincerely believes the proposal has a 3:1 requirement,
> does that mean it does? I think you're better off looking at the
> constitution, personally.

This seems to be a moot distinction, given that the constitution says
that the secretary is the judge in disputes about what the constitution
means.  (section 7.1.3)

> As it happens, it says nothing about implicit changes to foundation
> documents, or even about having to act in accord with them.

Section 4.1.5.3 seems to say something about this issue.  It doesn't
use the exact words you've used, but the meaning of the words it
does use seems more than adequate.

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/8/06, Nick Phillips <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 08, 2006 at 11:50:51AM -0500, Raul Miller wrote:
> > If the GR is adopted by Debian, there is no significant difference
> > between "contradicts the foundation documents" and "modifies
> > the foundation documents".
>
> First of all, you're assuming that it does contradict the foundation
> documents. It clearly asserts otherwise, and one might assume that
> developers voting for it would agree with that. If it won a majority,
> it would therefore seem to be the case that the majority of developers
> agreed with it. In which case those asserting that it needed
> supermajority wouldn't have a leg to stand on. So we'd be in a right
> mess.

That would be a moot point, not a contradiction.

> Second, you're completely wrong. Of course there is a difference
> between modifying the foundation documents and appearing to contradict
> them. One modifies them and the other, well, doesn't.

This can only be true where appearances are deceiving.

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/9/06, Christopher Martin <[EMAIL PROTECTED]> wrote:
> Please cite the part of the constitution which grants the Secretary this
> extraordinary power. Despite what Raul Miller repeatedly asserts, a minor
> power to decide issues of constitutional interpretation in cases of
> deadlock DOES NOT mean that they have the power to interpret the DFSG,
> since the DFSG is not the constitution.

"Repeatedly asserts"?  I think, if you check my assertion, it included
a direct reference to the text of the constitution that I was referring
to.

If you think I'm wrong, perhaps you could say specifically what it
is about what I wrote which conflicts with that part of the constitution?

Note also that the 3:1 supermajority requirement is not a part
of the DFSG.  So your explicit claim about DFSG interpretation
being out of scope for the secretary doesn't seem to provide a basis
for your implicit claim that the secretary does not have the right
to impose the requirement on some of the options in this vote.

> Indeed, section 4.1 states that the developers, by way of GRs or elections,
> have the power to "issue, supersede and withdraw nontechnical policy
> documents and statements. These include documents describing the goals of
> the project, its relationship with other free software entities, and
> nontechnical policies such as the free software licence terms that Debian
> software must meet. They may also include position statements about issues
> of the day." The GFDL sounds like an "issue of the day" to me.

Sure, and the constitution goes on and lists the procedure the
developers follow when doing these things.

And we're following those procedures.

So where's the problem?

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/9/06, Christopher Martin <[EMAIL PROTECTED]> wrote:
> But why does the Secretary get to decide whether this barrier should be set
> or not?

The constitution says:

"... the final decision on the form of ballot(s) is the Secretary's -
see 7.1(1),
7.1(3) and A.3(4)."

I think that's pretty clear.

Also, you might want to read the references it lists.

I think it's pretty clear here that the Secretary is not exceeding his
powers in any way, shape or form.

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/9/06, Anthony Towns  wrote:
> On Thu, Feb 09, 2006 at 05:18:18PM -0500, Raul Miller wrote:
> > On 2/9/06, Anthony Towns  wrote:
> > > As it happens, it says nothing about implicit changes to foundation
> > > documents, or even about having to act in accord with them.
> > Section 4.1.5.3 seems to say something about this issue.  It doesn't
> > use the exact words you've used, but the meaning of the words it
> > does use seems more than adequate.
>
> It says how the documents can be superceded or withdrawn; it doesn't
> say anything about ignoring them outright, or changing the way they're
> interpreted.

That's a strawman argument.

The ballot options are not being ignored.  Manoj is not leaving
them off the ballot.  The 3:1 supermajority issue is only relevant
for options which are not being ignored.

And Manoj is not changing the option.  The option in question
is making a statement about the DFSG.  It says " GNU Free
Documentation License protects the freedom, it is compatible
 with Debian Free Software Guidelines".  But until the option has been
accepted as a successful GR, the proposal is not something we
as a project have agreed to.

If it passes, then it will be true that this issue isn't a 3:1 supermajority
issue, but if it does not pass then this will not be true.

If it was true for us, without us having to vote on it, the this wouldn't
be an issue

> I think it's a mistake for Manoj to have taken on that role in this case,
> but it's his choice.

And that seems to be the right choice.

I certainly would not want the secretary acting as if controversial
proposals were a true of the project goals before they had been
voted on.

> As far as the outcome's concerned, though, I don't
> think it matters either way -- I think Anton's amendment has received
> more than enough discussion that it ought to be voted above "Further
> Discussion", and I think it's far better for us to decide what we want
> to do based on what we want and what we think, rather than attacking
> each other.

I agree that voting on this issue is the best way to resolve it, and that
attacking each other is not a good way of resolving anything.

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/9/06, Christopher Martin <[EMAIL PROTECTED]> wrote:
> To impose the 3:1 requirement requires, beforehand, a judgment concerning
> the DFSG. Since no one has found a Secretarial basis for that power, it
> follows that to arbitrarily impose 3:1 supermajorities (when doing so on
> the basis of a personal interpretation of the DFSG) is not proper. That the
> 3:1 bit is mentioned in the constitution is quite irrelevant.

All debian developers are required to understand and apply the
DFSG -- the DFSG is critical to Debian.

You don't need special powers to understand and apply the DFSG.

Package maintainers are supposed to make judgements about the
DFSG in the context of their packages.  The same goes for the
Secretary in the context of preparing the ballot.

> You can't argue that since the constitution doesn't explicitly forbid the
> Secretary to take it upon him/herself to interpret the DFSG for everyone
> else, that therefore he/she must do so, in order to discharge the
> constitutional duty of placing 3:1 supermajorities on amendments, etc.
> That's backwards. Essentially you'd be asserting that any delegate has _any
> power_ he or she deems necessary to fulfill his or her view of their own
> constitutional duties, unless explicitly forbidden, item by item, by the
> constitution.

That's not my argument.

And, likewise, you can't argue that the secretary must treat an option
as accepted when preparing the ballot.  Treating controversial
general resolution proposals as if they'd already won the vote before
the vote begins would be the very abuse of power you're alluding to.

>  Because that's the only way I can see for getting from "the
> constitution mentions that some votes should require 3:1 supermajorities"
> to "therefore the Secretary must be the constitutionally ordained arbiter
> of DFSG correctness for all votes." And this despite other constitutional
> verbiage that suggests that developers have that power. Huh.

The Secretary is a developer.

> > > Indeed, section 4.1 states that the developers, by way of GRs or
> > > elections, have the power to "issue, supersede and withdraw
> > > nontechnical policy documents and statements. These include documents
> > > describing the goals of the project, its relationship with other free
> > > software entities, and nontechnical policies such as the free software
> > > licence terms that Debian software must meet. They may also include
> > > position statements about issues of the day." The GFDL sounds like an
> > > "issue of the day" to me.
> >
> > Sure, and the constitution goes on and lists the procedure the
> > developers follow when doing these things.
> >
> > And we're following those procedures.
> >
> > So where's the problem?
>
> The problem is that in the course of this procedure, the Secretary
> overstepped his authority, as I've explained above. You may not agree with
> that view, but I don't see why you should be so confused about my
> complaint.

I've yet to see any description of your complaint that doesn't require
me to accept that Anton's proposal is universally accepted by the
project.

But if I accept that Anton's proposal is universally accepted by
the project, then the "barrier" you're talking about does not exist.

So I'm faced with a contradiction: how can the Secretary be mis-using
his power if this "mis-use" of power can only be a mis-use if it is
not a mis-use?

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/10/06, Anthony Towns  wrote:
> I didn't say anything about the ballot options being ignored -- I said the
> constitution doesn't say anything about ignoring foundation documents --
> ie the social contract or the DFSG. We're actually doing that right now
> in a sense, by continuing to leave bugs like #199810 unfixed.

So stick it in non-free for unstable, until the issue gets resolved.

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/11/06, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 10, 2006 at 03:21:57PM +1300, Nick Phillips wrote:
> > The vote is not a means of rescinding the DFSG or SC, nor even of
> > contradicting them. It is the *only* means we have of determining
> > whether something is in compliance with them. If a majority say that
> > that is the case, then for our purposes, it is so.
>
> This is silly.  It seems like the constitution effectively says "if the
> resolution passes it required a simple majority; if it failed, it needed 3:1".

The only silliness is the verb tenses.  Once some concept passes
supermajority it doesn't need to pass again, because it has already
passed.

The real problem here is that the option in question uses poor grammar.

For that reason alone, I think this option would be bad for the project.
It's already spawning arguments because people think they agree
with the option, but it's not clear what agreement with the option means.

Fortunately, or unfortunately, our resolution mechanism for this kind of
problem involves voting.  Personally: I am reasonably confident that most
of the developers will vote against something like this: where the grammar
of the proposal is so poor that it spawns grammar based arguments about
what it would mean if it were accepted -- before it's even voted on.

--
Raul

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Raul Miller]

On 2/10/06, Anthony Towns  wrote:
> Personally, I'd rather the secretarial role be as automatic as possible,
> even to the point where votes would be run without any human intervention.
> I've thought about that before, but I don't have the inclination to
> write any code for it.

I don't know what this means.

In general, humans are capable of understanding what is meant by a
ballot option, while machines are not.

I don't think incomprehensible ballot options are very useful, and we're
already pushing that envelope.

--
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: 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

Re: new virtual package: ups-monitor

[Raul Miller]

On May 26, Joey Hess wrote
> I don't think wish is the right name. Unless you're familiar with tk (as
> opposed to just trying to get it installed), you may not know that the tk
> interperter is named wish.

But in that case, it's just infrastructure, so why should you care?

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: SIOCSIFFLAGS

[Raul Miller]

On May 24, Jean Pierre LeJacq wrote
> I just ran across this problem as well.  I have a PCI bus
> with a DPT RAID board and a 3COM ethernet board trying to
> share IRQ 11.  There were no software options or hardware
> jumpers to change the IRQ selection.
> 
> To solve the problem, I moved the ethernet board to a
> different empty slot. TA DA!  It now magically uses IRQ 5
> and the SIOCSIFFLAGS problem disappeared. 

I've only got two slots in this machine :-(

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Upgrading from 1.1 to frozen

[Raul Miller]

On May 27, Thomas Koenig wrote
> Manoj Srivastava wrote:
> 
> > People will probably have told you this, but the Packages file
> > was not corrupted, those 1:x.x.xx are critical (these are epochs),
> > and the problem actually is that the version of dpkg being used is
> > too old to understand epochs. 
> 
> OUCH.
> 
> Is there any reason why this can't be handled in a different field?
> Breaking compatibility for something like this is .

These packages should conflict with the versions of dpkg which
have the problem.  [Or maybe a predepends on a good version of
dpkg?]

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: GOAL: Consistent Keyboard Configuration

[Raul Miller]

David Frey:
> > PS: I was never able to reliably switch the Ctrl/CapsLock key a la Sun.
 
On May 28, Kai Henningsen wrote
> And don't do this as a standard feature, either - CapsLock is bad enough  
> on its own, but switching it with Ctrl would make a keyboard just about  
> unusable for me. The way I type, CapsLock is just about out of reach for  
> every finger.

On the other hand, it would be nice to have changes to the X keyboard
get propagated back to the regular keyboard (e.g. using both 
caps lock and control as control).

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Sysvinit and System.map (Was: dangling symlink System.map)

[Raul Miller]

On May 28, Yann Dirson wrote
> BTW, psupdate is the only program I can think about using
> System.map. Are there any other ?

lsof

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug#8416: lprng: should recommend removing init.d script of lpr

[Raul Miller]

On May 29, Sven Rudolph wrote
> IMHO this should be changed in such cases:
> - run `update-rc.d -f lpd remove >/dev/null' on remove and purge

Better to chmod -x the lpd file, because that looses less information.

[lpd postinst would have to chmod +x the file, so it's still not
perfect.]

--
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: packages.debian.org & qmail (was Re: Using CVS for package development)

[Raul Miller]

On May 29, Bruce Perens wrote
> I must admit to not understanding what that qmail alias file is for.
> I do _all_ of my aliases with .qmail-* files .
> 
> What I was trying to achieve was to have qmail forward a message without
> messing around with the headers any more than necessary. Thus, I wanted
> to have a .qmail-packages-default file to handle the packages.debian.org
> domain, and that would look up the package name and map it to the maintainer
> address, and remail messages to the maintainer. This is not a terribly
> complicated hack, but I got busy.

I don't understand why you need to use RFC822 style addresses here?
You've got a message in-transit, so RFC821 seems more appropriate.

Furthermore, qmail parses the destination addresses and stuffs
it into various environmental variables, so parsing the dest address
shouldn't be an issue.

And, of course, identifying the proper smtp destination address for
the package maintainer is something that should be done at the time
the database is populated, not every time a message hits the system.

Given these conditions, I can think of at least three different ways
of implementing the forwarding:

(1) user-map [if all package maintainers are local]
(2) db lookup from -default
(and of course there's lots of ways to implement db)
(3) ~aliase/.q*

[There's more ways .. you could generate an account for each
package, ferinstance.]

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: RFC: Policy for arch specs

[Raul Miller]

On May 31, Galen Hazelwood wrote
> Perhaps.  Anybody have any serious arguments?  I think the reason we
> configure gcc as i486 is so it automatically optimizes for the 486; it's
> a good middle ground.

If I remember right, configuring for pentium leaves an executable
that might not run on 386 or 486.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: FreeQt ?

[Raul Miller]

> On 1 Jun 1997, Mark Eichin wrote:
> > actually, a lot of us find the sound driver stuff objectionable too
> > (because it leaves us with practically useless sound code, almost
> > enough to drive one to NetBSD :-) I still don't have any way to use
> > *both* ESS1688's in my laptop (when docked), which should be *trivial*
> > if the module took arguments like every other module in the
...
> > laptop... and didn't realize until now just how bad it was...
 
On May 31, Jason Gunthorpe wrote
> Yeah, I found it equally objectionable when I was reading it over,
> considering a few other things I'm -VERY- surprised it is in the kernel at
> all. 

I'm puzzled.

I just looked over the sound driver source code and didn't see anything
but GPL licenses in there.

I agree that configuration is lousy -- who ever thought that hard-coding
interrupts, dma and io ports at compile time was a good idea?

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: FreeQt ?

[Raul Miller]

On Jun 1, Leland Olds wrote
> "free" means different things to different people. Personally, I like
> the Debian/Gnu definition.  But if someone else uses it in another way,
> that doesn't mean that they are scammers and are trying to mislead us.

Um... in principle.  On the other hand, that doesn't mean that all
uses are ethical.
 
> Qt is a commercial software product. There are restrictions on the use
> of their product - either buy the expensive commercial license, or
> don't sell your software - and buy the expensive commercial license if
> you want to compile for a non X-Windows platform.

Excellent point.

> But calling Qt a Scam is a bit strong.  I think they make it clear that
> they want to make money selling their product. I think it is also clear
> that they want to use their "Free-Software" License to encourage people
> to use and learn their product so they can sell more commercial licenses
> later.

Calling a commercial product with strong restrictions free software
in misleading, at best.

I think "scam" is a perfectly adequate way of labeling this kind
of misleading labelling.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: cygwin.dll license (was Re: FreeQt ?)

[Raul Miller]

On Jun 1, Jim Pick wrote
> Actually, I had a very similar polite argument with RMS via private e-mail
> (about linking Java libs with mixed GPL/LGPL/proprietary licenses).  He
> was pretty solid on the fact that run-time linking is the same as
> "compiled-in" linking.

Yep, once the run-time linking has occured you're not allowed to
redistribute the resulting image if you aren't willing to redistribute
the source under similar terms.

This isn't that big of an issue for most people.

[Note: what RMS is trying to argue against is the stunt
Steve Jobs & Co. pulled with Objective C.]

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: cygwin.dll license (was Re: FreeQt ?)

[Raul Miller]

On Jun 2, Jim Pick wrote
> The cygwin.dll case in an example where the GPL is being used to restrict the 
> rights of other people using the code so that they can't do something taboo 
> such as charge money, while at the same time, reserving the right for the
> authors to do the exact same thing.  To me, this is clearly hypocritical,
> and I don't consider that software to be as 'free' as it could otherwise
> be.

First off, this list isn't the right forum to discuss Cygnus morality
issues.  Can someone point out a better forum?

Second, I find it hard to conceive of some case wher Cygnus would
sue someone for selling commercial software which happened to use
a DLL authored by Cygnus.  It would trash their (Cygnus's) reputation,
and eat into their bottom line.

Third, I think you're (Jim, I mean) making a mountain out of a mole hill.

Can't we talk about something more interesting?  Like, a mechanism for
informing maintainers of packages what issues they need to address to
get packages out of Incoming and into the distribution?

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: FreeQt ?

[Raul Miller]

On Jun 1, Galen Hazelwood wrote
> My understanding was that if a shared library is GPL'd rather than
> LGPL'd, linking commercial programs against it is illegal unless you
> provide source.  The LGPL removes that restriction, and that's why glibc
> (as well as libg++) uses the LGPL.

Static linking (where you wind up distributing part of the GPL'd
library with your software) is much more significant, from a
copyright point of view than dynamic linking (where you don't
need to distribute a copy of the library).

Of course, distributing a copy of the library might still be
pretty desirable, in which case you you need to pay attention
various license details covering such things.  Here, it might
be good to distribute your code in a fashion where you own
the interfaces (e.g. freely distribute a wrapper for the library
and code to the wrapper, or write a library replacement and
make sure your code runs against it).

Commercial software can earn you some money, but sometimes
it involves a bit of work...

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: cygwin.dll license (was Re: FreeQt ?)

[Raul Miller]

On Jun 2, Jim Pick wrote
> Just so you understand why I'm so interested - I'm working on porting dpkg
> to cygwin32.

Porting or re-implementing?  If it's a port, dpkg is already under
gpl, so cygwin32 being under gpl shouldn't be an issue.  [Even if
it wasn't, I don't understand how a gpl'd dll could be considered
a problem.]

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Corel Wordperfect and Java Office

[Raul Miller]

On Jun 6, Colin R. Telmer wrote
> I just noticed that Corel is just in the process porting Wordperfect 7 to
> Linux and the following is on the web page
> :
> 
> Certified Operating Systems
> 
>  RedHat 2.0.18
>  Slackware 2.0.25
>  OpenLinux 1.0 
> 
> Should we try to get Debian in there? 

Seems like a good idea to me.  What's involved?

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: xterm terminfo entry

[Raul Miller]

On Jun 22, Mark Eichin wrote
> Except that the xterm-color entry isn't particularly widespread, yet;
> so if you rlogin or telnet somewhere that doesn't have it, you pretty
> much lose.

termcap supported  the TERMCAP environmental variable, which solved
problems like this (and like "linux" not being supported on Solaris).
ncurses, near as I can tell, doesn't support anything like this.

Maybe we could put together a portable (tar + sh based) solution that
supports both termcap and ncurses on arbitrary unix systems?

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: dc and bc in Important?

[Raul Miller]

On Jun 27, Erik B. Andersen wrote
> For most math, expr works just fine.  Of course, expr is limited
> to integer math, but it works and is portable.

Oops, you're right -- my biases are showing, sorry.

[I make it a practice to never use expr.]

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bad Maintainer Addresses

[Raul Miller]

Re: dc and bc in Important?

[Raul Miller]

Re: be careful with Replaces, please

[Raul Miller]

It occurs to me that one avenue for a safe upgrade to hamm might be
a jumbo-package.

This would basically be a hand crafted .deb that contained (and
provides) all the relevant sensitive packages.

The downside is that this approach is laborious to implement.  The
upside is that this approach solves all the problems introduced by
the current many-packages implementation of debian.

Thoughts?

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Future security problem (was Re: be careful with Replaces, please)

[Raul Miller]

Brandon Mitchell <[EMAIL PROTECTED]> wrote:
> I can see a security problem with this.  

Absolutely:  pre/post inst/rm scripts run as root, this is the security
problem to dwarf all other security problems.

Our defense is a wide audience.  The more people we have looking at the
system, the better our chances are of noticing something untoward.
Basicaly, it's an application of "you can't fool all the people all of
the time", and "real security is a social problem more than a technical
problem".

Also, it's a given that the closer you are to the cutting edge, the
less security you have.  We'd do better here if some security-concious
folks were auditting our packages in controlled "burn-in" environments
as well as in wide-open gauntlets.  However, this is a job for someone
with the need and the resources (e.g. governments -- the more the 
merrier).  We'd also need some way of keeping the security folks from
squelching future development...

All of this smells like phd-thesis or research material, to me.

-- 
Raul



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: linux/unix to NT

[Raul Miller]

Mariusz Pagowski <[EMAIL PROTECTED]> wrote:
> Hello,
> I learned about samba package allowing me to access disks
> on NT machine from unix/linux. But does samba allow me
> to login/telnet to NT machine from linux/unix and run remotely
> a program on it? If not is there some software which would allow 
> me to do it?

NT has a telnet daemon that will give you a command prompt.  This
isn't useful as it might be, since most of NTs apps (including
administrative apps) will not work from the command line.  However,
you can do a few basic things (manipulate files).

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: perl module packages: why do they exist?

[Raul Miller]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>  # generate the control file
>  % make-ppkg --generate --package libcgi-perl --module CGI-modules > control
>  % vi control# make sure things look ok (espescially version numbers)
>  % make-ppkg -d my-packaging-directory control 
>  % dpkg -I my-packaging-directory/libcgi-perl*.deb# check
>  % dpkg -BGiE my-packaging-directory/libcgi-perl*.deb # install
> 
>   How does this sound? Is it still worth trying to modify
>  ExtUtils (still feels presumtuous of me to have that modified for
>  Debian -- after all, even the Linux kernel is not modified for us, we
>  just roll our own make-kpkg)? 

This is excellent.

We'll need some experience with it before we want to tackle the larger
issues.

This doesn't address browsing after the fashion of either dselect,
deity, or cpan...  Integrating this aspect into debian is going to
be real fun.

Finally, I don't see any problem with having a debian-specific
patch to ExtUtils. Whether this gets integrated back into the main
distribution is another issue -- perhaps if the underlying concepts can
be generalized [perhaps in a data-driven fashion] such that they're
useful in more contexts than debian... Again, I think we'll want to have
some experience with your make-ppkg before we venture too far in this
direction.

If I may oversimplify a bit further: ExtUtil integration might be
re-write 2, while deity integration might be re-write 4.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Config file management utility

[Raul Miller]

Steve Greenland <[EMAIL PROTECTED]> wrote:
> That said, it appears that the only policy compliant way for a package
> to run a script more frequently than once a day is to register a user,
> and create a crontab for that user. This is not too onerous for
> news or sendmail, but seems like overkill for every little package.

Creating a user shouldn't be that big of a deal, as long as it's a
useful abstraction.  Having a user for a fax system seems apropriate.

Also, not solving non-problems generally makes our work easier.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

going to package e

[Raul Miller]

I intend to package the beta enlightenment window manager, imlib, and
the default themes.  If anyone wants to do it instead, I'll happily
fall back to kibitz mode -- let me know.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Config file management utility

[Raul Miller]

Joey Hess <[EMAIL PROTECTED]> wrote:
> Having a user for mrtg doesn't seem very appropriate to me, though.
> Mrtg is a simple program, that needs to run every 5 minutes. A user is
> overkill.

If a user is overkill then cron probably is too.  You'd probably do
fine with something like

(
trap "" SIGHUP
su nobody -c '
while sleep 300; do
whatever;
done /dev/null 2>&1 &
echo $!
' >/var/run/mtrg.pid
)


-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: going to package e

[Raul Miller]

Jim Pick <[EMAIL PROTECTED]> wrote:
> Lalo Martins <[EMAIL PROTECTED]> did a package of beta 12, back in
> August, but he didn't upload it since he was waiting for developer
> status. I wonder what happened? Did we lose another one?

I was going to pick it up from him, but...
 
> Anyways, his old package is at:
> ftp://ftp.mandrake.net/pub/enlightenment/debian-deb/
> For some reason, there's no source packages.

That's where I was supposed to pick up the source package from, and
I've not seen it there :(

I suppose I should ask Mandrake directly.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Intent to package: umich-ldap / WNPP: Dermot Bradley probably not maintaining packages

[Raul Miller]

Dermot John Bradley <[EMAIL PROTECTED]> wrote:
> BTW Can anyone tell me how to create a package based on pristine source
> using debmake?

>From www.debian.org, hit "developers corner". Then, start with Creating
a Package using Debmake, after that, hit New-Maintainer's Debian
Packaging Howto. Get your debian/* files to a rough approximation of
what you want, make note of areas where you need to do more. Then go
through the others (developer's reference, packaging manual, ..) and
look for stuff that seems relevant.  [hit a mirror site if www is acting
up.]

I've not successfully done a libc5/libc6 library package yet myself...

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Config file management utility

[Raul Miller]

Joe Emenaker <[EMAIL PROTECTED]> wrote:
> The only problem is that it uses Perl. I haven't read the Debian policies
> so I don't know if Perl (or a stripped down version of it) is one of the
> things I can assume is on even the most minimal system. If not, I can do
> the same thing with bash/sed, I s'pose.

You can rely on perl.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug log ordering

[Raul Miller]

Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul continues to suggest using a CGI program:

Er.. note that I'd also suggested using a proxy server.  I even
supplied code for such.

> We have more mirrors than places we can run CGI scripts.

Note that a proxy server can be run more places than a CGI script.

> The question then is whether (c) can be made to be acceptable.

I think there's an option (d), as well...

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: bashisms

[Raul Miller]

> Adrian Bridgett <[EMAIL PROTECTED]> writes:
> >   cp fred.{txt,html} dest->   cp fred.txt fred.html dest
> >   function f() {echo Hi;}->   f() {echo Hi;}

should be
f(){ echo Hi;}
you MUST have a space after the opening brace.  Of course, extra
spaces are legal:

   f  (  )  {  echo  Hi  ;  }

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: BS in rxvt+ncurses

[Raul Miller]

Mark W. Eichin <[EMAIL PROTECTED]> wrote:
> ps. Of course the behaviour in paragraph 2 has nothing to do with unix
> either; unix terminal handling is far too primitive for that.  Long
> Live Multics :-)

Of course, nowadays the "interact" command under expect can easily
handle this kind of thing...

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Moving topics from debian-private (was Re: SPI money out)

[Raul Miller]

Christian Schwarz <[EMAIL PROTECTED]> wrote:
> Please check out http://www.unicom.com/pw/reply-to-harmful.html . The page
> contains several arguments against the use of "Reply-To". I fully agree to
> what Ian said.

I personally find header-munging of any sort distasteful, however
I think a couple of points should be made clear:

(1) a good mail client (e.g. a properly configured mutt) will
give you the option of respecting reply-to, or ignoring it.

(2) changing an existing reply-to to an x-reply-to is a fairly
minor losage, given a good mail client.

(3) a good mail client can thread duplicate replies together,
making them easy to manage.

A really good email client would probably have a mechanism for
indicating that the previous message's author prefers to receive list
mail only via the list address. Admittedly, this solution hasn't been
designed, and debian-devel probably isn't the right place to design it,
but it shouldn't be too hard to hack up mutt, gnus, and whatever other
readers people like to support such a mechanism.

I prefer to use reply to all recipients rather than reply to list. This
is because I've been stung in cases where one of the recipients was not
on the list I was replying to.  Also, there are times when the list
and/or the author's personal address have problems, and sending to
both is just plain more robust.

Anyways, a solution aimed at bad mail clients cannot be a solution (in
my opinion).

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Taking over production of emacs20 package.

[Raul Miller]

Adam P. Harris <[EMAIL PROTECTED]> wrote:
> What if you have Xemacs *and* Emacs installed, and want to use auctex 
> from both?

Last time (a couple weeks ago) I tried selecting both xemacs and emacs,
I found that they conflicted.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ppp's ip-{up,down} and possible utilization of 'run-parts'

[Raul Miller]

Philip Hands <[EMAIL PROTECTED]> wrote:
> Any better suggestions ?

run-parts should pass arguments which follow the directory.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Service registration

[Raul Miller]

Guy Maor <[EMAIL PROTECTED]> wrote:
> When a provider first installed a hook, the system would immediately
> run the hookfile for all clients that already registered.  Then
> whenever a new client registered, it would run the hookfile.  The
> hookfile would be run with the same arguments that the client
> registered with.  Any arbitrary information can be stored in the
> service registry.
...
> Comments?

What about more than one hookfile event before service is available?

Say, ferinstance, that several revisions of a package are installed
and there are subtly different arguments each time.  Or, that package
installation fails, is backed out, then installed then reconfigured?

Simplest solution is to only track the last hookfile event, but
that only works if each call is complete unto itself.  On the other
hand, we want to maintain existing configuration information, 
should the system administrator have needed to reconfigure things.

I think that this means we'd need to define some sort of generic
(and repeatable) database interface.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Service registration

[Raul Miller]

Raul Miller <[EMAIL PROTECTED]> writes:
> > Say, ferinstance, that several revisions of a package are installed
> > and there are subtly different arguments each time.  Or, that package
> > installation fails, is backed out, then installed then reconfigured?

Guy Maor <[EMAIL PROTECTED]> wrote:
> Several clients or servers?  Clients would remove or install
> themselves whenever in their prerm and postinstall, respectively.

Clients.  My point has to do with configuration information where
default values are given on the command line.

Anyways, it sounds like you're on top of this aspect.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Does `dpkg' track the installation date of a package?

[Raul Miller]

Todd Graham Lewis <[EMAIL PROTECTED]> wrote:
> Count mine as one vote for a new LOG_DEBIAN facility.

Is syslogd guaranteed to not lose events under debian?

[It has no such guarantee for the general case.]

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Paranoia, "pristine sources", turnkeys, compiling, configuration

[Raul Miller]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> This suggests to me that at least part of what the Debian developers
> are doing is somehow redundant, when it comes to well written software
> that is set up to compile of a number of systems. I did not claim that
> there are not packages that I have balked at, or that didn't compile.
> In such cases I have found debian packages HIGHLY useful. In fact, I
> have not been able to set up sendmail or smail properly, even from the
> debian package, without considerable work. But most debian packages,
> happily, drop right in. And uninstall neatly.

In an ideal world, either:

(a) the debian package format would be supported by the package author, or
(b) compilation and installation for debian package building is trivial.

Note that the debian package system addresses more than compilation
and installation: it also addresses release engineering (stuff you
worry about when you have a lot of machines to administer but not
much time for any individual machine).  Debian doesn't address all
aspects of release engineering (for example, no one tests debian
for clean downgrades, to back out of a problem), but there's a lot
of ground to cover and we're just getting started.  

Anyways, I expect that a lot of software authors would prefer to leave
release engineering to someone else.

But you do have a point: where we see a way that we can help out the
author in making a package easier to compile or install, it's a
good idea to offer assistance.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ppp's ip-{up,down} and possible utilization of 'run-parts'

[Raul Miller]

Rob Browning <[EMAIL PROTECTED]> wrote:
> Note, that I'm not saying that I can come up with a good argument why
> it would be important to be able to make this distinction (or to even
> do what I'm depicting in the example), but I am saying that since I
> can't prove to myself that the exact arguement used to invoke pppd
> will *never* be crucial, you shouldn't mangle it.

Alternate devices directories might be useful in a secured network
environment (e.g. each physical set of connections gets its own
directory with its own permissions). Here, you want separate directories
because programs which manipulate ttys tend to manipulate device
permissions. You want lines going to the outside world to have different
permissions than lines going to the inside world because that's what
your security model dictates.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Re^4: intent to package: doom!

[Raul Miller]

Marco Budde <[EMAIL PROTECTED]> wrote:
> I would prefer a flag in CONTROL. We have got a lot of programs with such  
> problems. For example it's no problem to sell programs with GIF support in  
> Germany, because there's not patent on this algorithm.
> The crypt programs are another group. You're not allowed to use these  
> programs in France or Russia.

Why not just filter out games/doom*, and games/quake* in your mirror
configuration?

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: killall is removed from procps

[Raul Miller]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Two options:
>   I merge the psmic into procps
>   I create a new package called psmisc.

procps is required.  pure compatability would argue that
psmisc also be required (or something very close).

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian and the millenium bug

[Raul Miller]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Well, there is a problem with the Gregorian calendar that has to be
> dealt with in 2000 years or so (having to do with leap-millenia), but
> I figure if it's more than 100 years it's no problem.

I believe that can be handled by making the year 4000 not be a leap
year.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: port 80 connections persist after closing Netscape

[Raul Miller]

Oliver Elphick  wrote:
> Can anyone tell me what is going on and how to stop it?

Sounds like socket shutdown.  If so, the "right" way would be to tell
diald about such packets so it ignores them.

The "quick and dirty" way would be to shut down diald for a few minutes.

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: base-files 1.6 (source all) uploaded to master

[Raul Miller]

Riku Voipio <[EMAIL PROTECTED]> wrote:
> The point is new users. 

Then we should be talking about /etc/skel/, rather than /etc/profile

-- 
Raul


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

Re: BEWARE

[Raul Miller]

Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> the broken grep (I think it is filed as a Bug already) will do a lot of
> damage to your system. It will kill your Windowmanger -list if you install a
> Windowmanager, and it will make the /etc/X11/config not work
> (user-xsession).

There are a bunch of bug reports on this.

I think this is so bad that every binary copy of grep 2.1-7 should be
deleted from every archive as soon as possible.

-- 
Raul


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

Re: BEWARE

[Raul Miller]

> In article <[EMAIL PROTECTED]> Raul Miller wrote:
> > I think this is so bad that every binary copy of grep 2.1-7 should be
> > deleted from every archive as soon as possible.

Herbert Xu <[EMAIL PROTECTED]> wrote:
> You mean 2.1-6?

Oops. yes.

I'd hand-patched my system and hadn't noticed that the thing had
been upgraded.  [Also, I don't remember seeing a close notice on
my bug report, though I see at the archive that it's been closed.]

-- 
Raul


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

Re: base-files 1.6 (source all) uploaded to master

[Raul Miller]

Riku Voipio <[EMAIL PROTECTED]> wrote:
> The policy is to keep /etc/skel minimal, to avoid unecessary bloat of
> /home structure... keep in mind that many ISP's have thousands of users.

(1) If it's worth doing, it's worth doing right.

(2) /etc/skel/ already has a .bashrc and a .bash_profile.

(3) Administrators, even administrators with thousands of users, can 
administer /etc/skel/.

-- 
Raul


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

Re: base-files 1.6 (source all) uploaded to master

[Raul Miller]

Riku Voipio <[EMAIL PROTECTED]> wrote:
> Yes, but remeber that changes in /etc/skel affect only users that
> are added in the system _after_ the change. Exeisting users will
> still have old files. I still wonder, what it helps to put global
> configuration in user-specific files.

Then you're saying that the point is not so much new users but existing
users.

For what it's worth: note that the problem of training existing users in
the capabilities of the system extends far beyond getting them to change
their default prompt.

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

Brian White <[EMAIL PROTECTED]> wrote:
> I understand this and it is a good point. My concern is with people
> who are trying to install Debian and the difficulties they encounter.
> There have been several posts lately from experienced people who tried
> to install Debian and had it blow up in their faces. Such happenings
> can greatly hinder Debian's reputation and general acceptance.

How many of these people had problems from properly built packages?

> What do you figure to be the number of people who will want to use these
> utilities with a 2.1 kernel that do _not_ have any sort of internet
> access?  Also, how likely are the current versions of these programs
> to work with future versions of the unstable 2.1 kernel and the 2.2
> kernel that will eventually come from it?

What about people who need such support now (before the cd is released).

[such as myself.]

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

Brian White <[EMAIL PROTECTED]> wrote:
> > How many of these people had problems from properly built packages?
> 
> All of them.  It was that the packages didn't work in certain situations.

Were these "Extra" packages?

> > What about people who need such support now (before the cd is released).
> 
> Get it from "unstable", just as you have in the past.

Doesn't that imply that I put "unstable" in my configuration, and
that as packages appear in unstable my system will automatically
acquire them as I run dselect?

Or is apt ready to go, and able to deal with this issue?

Or, more generally, am I supposed to not use dselect to manage these
packages?

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

Brian White <[EMAIL PROTECTED]> wrote:
> The subject in question is whether to include these packages in "stable".
> "unstable" will include them for sure.

I think they are appropriate for "stable" provided they are classifed
as "Extra".  That is what the "Extra" priority is for, after all.

-- 
Raul


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

Re: base-files 1.6 (source all) uploaded to master

[Raul Miller]

Riku Voipio <[EMAIL PROTECTED]> wrote:
> > > Yes, but remeber that changes in /etc/skel affect only users that
> > > are added in the system _after_ the change. Exeisting users will
> > > still have old files. I still wonder, what it helps to put global
> > > configuration in user-specific files.

On Thu, Apr 09, 1998 at 11:42:30AM -0400, Raul Miller wrote:
> > Then you're saying that the point is not so much new users but existing
> > users.

Riku Voipio <[EMAIL PROTECTED]> wrote:
> Nooo... I mean those who new to linux in general and install it in their
> own computers. For them it doesn't matter if it is in the .bash_profile or
> in the /etc/profile. However, any large site admin will curse you to the
> lowest hell, if something is in every 20 000 users home dir what could be a
> single line in a single file. And if we ever decide to change /etc/skel
> stuff, it will only affect the users added after the change, and all
> previous users will be stuck with the old system. But if the change is
> done in /etc/profile, all users will be affected. Did I make myself
> clear?

No.  I think I understood what you said, but it doesn't make sense.

(1) The files already exist in debian. You're not saving any space by
not using them.

(2) The administrators of such a site are perfectly capable of deleting
the files and/or editting /etc/profile. Frankly, I don't see why you're
trying to tune debian for this case.

(3) I don't think it's a good idea to change the prompt on people who
have been using the system for a while.  Why make gratuitous changes?

(4) The old users will not be stuck with the old system, and are free
to specify whatever prompt they want.  Since there is no "one true
prompt", I expect that more would be gained by giving people a set
of samples to choose from.

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>   Add diald to the list of packages having a problem with 2.1.X
>  kernels. I have downloaded the patch from the diald list archives,
>  but even that failed for 2.1.94.

Diald works with 2.1.92, but it has a defect when connecting to
other machines on the same subnet as the host on the other side
of the ppp line.

Basically, there's no ppp route to these machines to superceed
the slip route, so diald queues all such packets (running route -n
for each).  If you're lucky (I've not analyzed the problem 
sufficiently to characterize the circumstances any better), the
packets will be dequeued onto the ppp line a short time later.

Thus, sometimes such connections don't work at all, other times
there's merely a performance hit (and nearly a full second
round trip time).

-- 
Raul


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

Re: intent to package Netscape Communicator

[Raul Miller]

Adam Heath <[EMAIL PROTECTED]> wrote:
> Also, another point I am worried about.  Included in the tarballs are hooks
> into an automated software update mechanism.  I have that disabled, as that
> would not fit well with the debian way of maintaining things.  Anyone else
> have ideas on this?

On a debian system, I'd think such a mechanism should be a script that
gives an option to bring up apt in an environment where the upgrade .deb
is available. Maybe this is what should be the default action
for debian packages.

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> From a logical point of view, I think project/experimental is the best
> choice. Why don't we include selected directories from there on the official
> CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)?

Project/experimental is not part of hamm.

If Extra really isn't enough of a distinction (how much more of a
distinction (I still don't see why, given the definition), maybe
there should be a hamm/experimental.

-- 
Raul


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

Re: vim, help files and vimrc

[Raul Miller]

David Welton <[EMAIL PROTECTED]> wrote:
> 2. Ask the user if it is ok to fool with vimrc ,and script the
> necessary changes.  This strikes me as being ugly and something that
> we might be stuck with for a long time, in the name of backwards
> compatibility.

Can't you put a global vmrc in /etc?

-- 
Raul


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

Re: vim, help files and vimrc

[Raul Miller]

On Sat, Apr 11, 1998 at 09:15:01PM -0400, Raul Miller wrote:
> > Can't you put a global vmrc in /etc?

David Welton <[EMAIL PROTECTED]> wrote:
> That's the one I'm talking about - it is a conf file, and may well
> have been changed by the admin.

The debian conffile system has a weakness: there's no simple way to
announce what the significance of a changed conffile at administrator
decision time.

-- 
Raul


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

Re: vim, help files and vimrc

[Raul Miller]

James R. Van Zandt <[EMAIL PROTECTED]> wrote:
>diff /etc/foo.conf /etc/foo.conf.dpkg-dist | head -18

I originally asked that there be a D option which would do

  diff -u $x $x.dpkg-dist | ${PAGER:-more}

and was told that that was what the Z option was for.

Unfortunately, I don't think human factors was much considered
in this aspect of dpkg's design...

[Personally, I think the capability to display a prepared message with
an option to display a diff with a simple keystroke is the right way to
go.]

-- 
Raul


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

Re: Is this a bug in libc6?

[Raul Miller]

Avery Pennarun <[EMAIL PROTECTED]> wrote:

> On Sun, 12 Apr 1998, Hamish Moffatt wrote:
> Personally, as a programmer myself, I much prefer to work on a system that
> gives up consistently when I do something wrong.  That's what segmentation
> faults are all about.  It would be _easy_ to tell the kernel "don't kill
> tasks if they write to random memory locations."  That's what DOS and Win16
> did -- and you end up with random memory corruption that's virtually
> impossible to debug.

It *is* easy to tell the kernel, "don't kill this task if it writes to
random memory locations".

-- 
Raul


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

Re: Anyone want to make a Debian XDM login screen?

[Raul Miller]

Steve Dunham <[EMAIL PROTECTED]> wrote:
> They both would be easy, but with the first option I would be
> concerned by the rapidly changing state of the gtk libraries.  (Red
> Hat is basing some gui apps on gtk, so users are unable to install
> newer versions of the gtk libraries without breaking these apps.)

Of course, this is a problem which could be solved first by static
linking, and later by carefully bumping the major version number
whenever needed.

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

Santiago Vila <[EMAIL PROTECTED]> wrote:
> If we start putting experimental things in CDs, then we should create
> another distribution "really-experimental", since experimental
> seems not to be "safe" enough...

Or create an "expirmental" priority.

The policy manual says:

   extra
  This contains packages that conflict with others with higher
  priorities, or are only likely to be useful if you already
  know what they are or have specialised requirements.

(I got this from
 http://www.noguska.net/linux/policy/archive/debian-policy-2.4.0.0/ch2.html
)

Presumably, we think that this is not an appropriate category for 
packages which are only useful for people with a 2.1.* or higher
kernel.  If this is true, we need to come up with a description 
which is generally adequate, and create ourselves an "experimental"
kernel.

Frankly, I'm don't understand why "extra" isn't an adequate category.

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

> [EMAIL PROTECTED] (Santiago Vila)  wrote on 13.04.98 in <[EMAIL PROTECTED]>:
> > It is in experimental because the author asked me not to distribute it
> > "widely". This means that even if it is not accesable by dselect, we
> > should not put it on CDs yet.

Kai Henningsen <[EMAIL PROTECTED]> wrote:
> I still think this is a very bad state of affairs. And I still fail to  
> understand the arguments for doing it that way.

Probably isn't ready to answer a lot of questions from lots of people yet.

Also, maybe isn't certain the interfaces are stable yet.

-- 
Raul


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

Re: Test Report (was: Re: boot-floppies_2.0.4 (source i386) uploaded)

[Raul Miller]

Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> I did hear something about /etc/envronment, but I'm not sure what purpose it
> has and if it works for all shells, etc. Well, I hope it is okay to change
> /etc/profile, as it is *very* annoying for non-english users (esp. first
> time user) to have to guess keys (and not knowing how to fix this).

Heh...

In my opinion, /etc/environment should be supported by init (with a
few sanity checks to avoid wedging the system), login, su, cron, ...
That said, the only applications I'm aware of that explicitly support
/etc/environment are sshd and xdm.

-- 
Raul


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

Re: Anyone want to make a Debian XDM login screen?

[Raul Miller]

David A. van Leeuwen <[EMAIL PROTECTED]> wrote:
> Even ctrl-alt-del doesn't work in XFree86. 

ctrl-alt-del should be made to work.

-- 
Raul


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

Re: Anyone want to make a Debian XDM login screen?

[Raul Miller]

Joey Hess <[EMAIL PROTECTED]> wrote:
> Raul Miller wrote:
> > David A. van Leeuwen <[EMAIL PROTECTED]> wrote:
> > > Even ctrl-alt-del doesn't work in XFree86. 
> > 
> > ctrl-alt-del should be made to work.
> 
> Um, please, NO!
> 
> I've several times been very glad ctrl-alt-del did not work in X. You see,
> my main server is often in X, another computer here isn't, and I typically
> get the keyboards confused and breath a huge sigh of relief when I realize X
> ignored the ctrl-alt-del.

That can be configured by people who need it.  

To turn off ctrl-alt-del for non-x you edit /etc/inittab

In principle, it would be nice if X could just relay the information
to init (that the key combo is being pressed). In practice, it might
be acceptable to just put a comment into /etc/inittab (and the
app-defaults) pointing to the other location(s).

-- 
Raul


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

Re: Debian Bug#20445 disagree

[Raul Miller]

Brian White <[EMAIL PROTECTED]> wrote:
> The choices are:  don't ship them, ship them in contrib, or ship them
> in project/experimental.

I still don't understand why they don't fit in Extra.  Packages designed
the 2.1.* frozen kernels seem to exactly fit the policy for Extra.

Did you post a message addressing this point and I just missed it?

Thanks,

-- 
Raul


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

Re: elvis package

[Raul Miller]

Martin Schulze <[EMAIL PROTECTED]> wrote:
> Elvis is non-free and the author ignores all mail coming from us,
> both copyright mails as well as bugreports and fixes.

Er... then why isn't it in non-free?  Also, why is it our highest
preference editor?

Also, what aspect of the copyright notice puts it in non-free?

[The only thing I can guess is the "500 lines for your own project"
thing, which is wierd, but clearly doesn't apply to modified copies of
elvis which have been marked as modified]

-- 
Raul

This package was debianized by Erik Andersen [EMAIL PROTECTED] on
Sat, 22 Nov 1997 03:14:13 -0700.

It was downloaded from ftp://ftp.cs.pdx.edu/pub/elvis/

Copyright:

Elvis 2.1 Copyright 1996 by Steve Kirkendall

Elvis 2.1 is copyrighted freeware.  It is provided in the hope that it will
be useful, but with no warranty.

You can distribute copies of it in either source form or binary form,
provided my copyright notice remains intact.  If you distribute *MODIFIED*
versions, please mark them as being modified.

You can use portions of elvis source code in your own projects.  If you use
fewer than 500 lines, then no special permission is required.  For 500 or 
more lines, please obtain permission from the author at [EMAIL PROTECTED];
in general, such permission will be granted without compensation.


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

Re: elvis package

[Raul Miller]

Martin Schulze <[EMAIL PROTECTED]> wrote:

> On Fri, Apr 17, 1998 at 09:11:41AM -0400, Raul Miller wrote:
> This fails #3 and #7 of the DFSG.  (Bug#14953 from 16 Nov 1997)

Ho hum.. the web server is still down.

-- 
Raul


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

Re: bzip2 for source packages?

[Raul Miller]

Michael Alan Dorman <[EMAIL PROTECTED]> wrote:
> Might I suggest that using it for source packaging would be
> appropriate, though?

Not as the only format -- even the linux kernel is available in gzipped
tar.

I'm sorry, but the source format is needed in a far wider range of 
contexts than the .deb format.  And, some of the machines where I've
pulled down sources to take a look at them were quite small.

-- 
Raul


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

/etc/group lossage

[Raul Miller]

Today, when installing some packages, I noticed some errors that
I didn't expect.  Looking closer, my /etc/group file had been
damaged.

Looking closer, I found a couple of packages (msqld and sudo)
which updated /etc/group in what I would consider an insufficiently
paranoid fashion.  While they couldn't have caused all the damage
themselves once you have an entry in /etc/group with two many ':'s
these packages will mangle it further.

I'm not sure that this is sufficient detail to warrant a bug report,
but be on your toes...

-- 
Raul


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

bzip2 X

[Raul Miller]

Branden Robinson <[EMAIL PROTECTED]> wrote:
> It would probably make a lot of people very happy (including me) to bzip2
> the Xfree86 source and/or binaries.

Hmm... it's actually probably a good idea to bzip2 the X sources.

They're monstrous.

-- 
Raul


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

Re: /etc/passwd : which software does support this ?

[Raul Miller]

Remco Blaakmeer <[EMAIL PROTECTED]> wrote:
> I am not really a programer, but I wonder how hard it would be to put
> support for these fields in all programs like login, xdm, cron, at and
> anything I am forgetting. Could this be done?

The difficulty isn't so much making the change, once (though that
can be a problem), but making the change every time something comes
from the original source, changed.

Sometimes this isn't much of a problem (maybe the source has been stable
for the last 11 years and needs a new caretaker anyways, or maybe the
original author is receptive to changes). Other times it can be a real
pain (maybe the source needs to run on 100 different operating systems
and the upstream maintainer isn't interested in code that breaks 50 of
those).

-- 
Raul


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

Re: elvis package

[Raul Miller]

Charles Briscoe-Smith <[EMAIL PROTECTED]> wrote:
> I'm pretty sure that a program must be either entirely GPLed,
> or contain no GPLed parts.  

More precisely, the non-gpled parts must not have terms which prevent
compliance with the gpled parts.

-- 
Raul


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

Re: less: extra entries for lesspipe

[Raul Miller]

Carl Mummert <[EMAIL PROTECTED]> wrote:
> But when you say, 'less binfile', what do you expect it to do?  

Pretty much the same thing view binfile does.

Note also that the real problem lesspipe was designed for would be
better addressed by a compressed file system.

-- 
Raul


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

Re: Intent to package moxa radius

[Raul Miller]

Rev. Joseph Carter <[EMAIL PROTECTED]> wrote:
> be GPL.  An example of this is ncftp which was using it--that's a nono,
> even though it is a simple shared library.  In this instance, the GPL
> actually hurt ncftp.
...
> This is a limitation on the GPL I think, ...

It's a limitation of ncftp.

There's nothing preventing:

(a) The authors of ncftp releasing it under terms compatible with
GPL.  [This course of action has been taken by authors of other
pieces of software.]

(b) The authors of ncftp writing a workalike for readline.  [This
course of action has also been taken by a few authors of other
pieces of software.]

Now, if there is something about this situation that hurts the
functionality of readline, that would be a limitation of the GPL.
Whether this would be good or bad in some larger sense would be subject
for the gnu advocacy mailing list.

[Aside: I notice that a few people tend to be a lot more upset about the
terms of the GPL -- despite it having proved its worth many times --
than about the terms of licenses which wind up being fairly useless for
our purposes. I don't really understand why this is.]

-- 
Raul


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

Re: why not mingetty??

[Raul Miller]

> On Fri, Apr 24, 1998 at 05:39:51PM -0400, Shaleh wrote:
> > Why is our default not mingetty.  Several other dists use this.  For
> > almost all Linux boxen this is the right choice.  It is easier on mem
> > and cpu than agetty.

Can this be quantified, please?

Changing the default will disrupt the integrity of everyone who is
relying on it. [Not me, personally, I'm using mgetty where it matters.]

Aside: I'm surprised that /sbin/getty isn't managed using
update-alternatives.  I presume that this means that the different
getties aren't very interoperable?

I realize that at present, just installing mingetty doesn't free up
the space taken up by agetty in the util-linux package. Perhaps agetty
should be factored out into its own package? [Of course, this is a slink
issue, rather than a hamm issue.]

-- 
Raul


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

Re: elvis package

[Raul Miller]

Charles Briscoe-Smith <[EMAIL PROTECTED]> wrote:
> >> I'm pretty sure that a program must be either entirely GPLed,
> >> or contain no GPLed parts.  

In message <[EMAIL PROTECTED]>, Raul Miller writes:
> >More precisely, the non-gpled parts must not have terms which prevent
> >compliance with the gpled parts.

Charles Briscoe-Smith <[EMAIL PROTECTED]> wrote:
> Before they are incorporated into the GPLed program, yes, but not
> afterwards. Please read the "viral clause" of the GPL, clause 2(b):
>
> You must cause any work that you distribute or publish, that in
> whole or in part contains or is derived from the Program or any
> part thereof, to be licensed as a whole at no charge to all third
> parties under the terms of this License.

This just means that if you can't distribute the program under the terms
of the GPL you can't distribute it.

Please notice the phrase "licensed as a whole".  It's not saying that
you have to change licenses on included fragments.  It's saying that
the fragments have to be compatible.

This clause makes it clear that you can't (for example) distribute
some of troll-tech stuff as a part of a gpl'd program.

-- 
Raul


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

Re: Licensing, was elvis package

[Raul Miller]

David Welton <[EMAIL PROTECTED]> wrote:
> So why haven't we seen this enforced, or has it happend but quietly?
> I do note that there is no kemacs.., but there are things like
> krpm.. hrm.. I'd have to look at the list, but... one would think that
> at least RMS would enforce things under the FSF's protection.  So are
> we missing something?

If you'd manage to read the copyright on rpm, you'd see:

(1) It's written by redhat, not fsf,
(2) It's available both under GPL and LGPL.

-- 
Raul


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