David Welton <[EMAIL PROTECTED]> wrote:
> I was, for those of you who are not mind readers, of course referring
> to the Qt stuff. My mind was half out the door...:->
Oh.. er... I still don't understand what you were trying to say.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
David Welton <[EMAIL PROTECTED]> wrote:
> My main point was this: if the GPL has this clause about the
> components of a program being free, what with the large quantity of
> programs being Qtized, why haven't we seen any action?
I don't know. Where are these large quantity of programs?
Most li
Shaleh <[EMAIL PROTECTED]> wrote:
> The inittab setup is not different. However, the only way to switch
> gettys is to change thme by hand. This is because of agetty's priority,
> I could not remove agetty.
As I mentioned before, there is no agetty package, it's in util-linux.
[It would be good
Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 25, 1998 at 01:40:32AM -0400, Shaleh wrote:
> > The inittab setup is not different. However, the only way to switch
>
> That's not true, it is -- getty requires a speed, even for a virtual
> terminate, while mingetty doesn't support that.
D
Shaya Potter <[EMAIL PROTECTED]> wrote:
> Probably because it's allowed, doesn't the FSF distribute emacs linked or
> with the ability to link out of the box against Motif?
You're probably thinking of xemacs.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe"
Raul Miller <[EMAIL PROTECTED]> wrote:
> You're probably thinking of xemacs.
[Or, as other people have pointed out, emacs for systems where you
don't need a special license to be legally entitled to use motif.]
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Avery Pennarun <[EMAIL PROTECTED]> wrote:
> environment variables, I know. Maybe the "right thing to do" is modify bash
> itself to _default_ to the right prompt. bash$ is just useless, after all.
Excellent idea.
Just try to keep the default prompt from getting too long.
--
Raul
--
To UNSUB
Shaya Potter <[EMAIL PROTECTED]> wrote:
> What defines a standard linux installation. Each dist. in reality
> is it's own OS. Red Hat ships Motif, would it be legal for them to
> distribute a GPL'd program linked with Motif, and not for debian?
Only if the result can "be licensed as a whole at no
Enrique Zanardi <[EMAIL PROTECTED]> wrote:
> I'm not a dpkg expert, but AFAIK modifying directly the dpkg databases
> (yes, almost everything under var/lib/dpkg are dpkg databases) is a
> Wrong Thing (TM) In the current implementation those databases are
> ASCII files, but that may change (and sure
Jules Bean <[EMAIL PROTECTED]> wrote:
> It is perfectly legal, apparently, to have a GPLed program use (e.g.
> shell out to) a commercial piece of software. It has to be - to
> disallow this would be very stupid indeed. And indeed, the whole idea
> of have standard APIs for program communication (l
Alex Yukhimets <[EMAIL PROTECTED]> wrote:
> > If you think the GPL is wierd, you should take a look at the Motif
> > license for Linux.
>
> Looking...
> And so???
>
> Way less restrictive as far as linking with the library is concerned.
You're talking about dynamic linking or static linking? De
Alex Yukhimets <[EMAIL PROTECTED]> wrote:
> First of all, there is no distinction between static and dynamic
> linkage from either Motif license or GPL point of view. (Well,
> actually Motif has one restriction on distribution of statically
> linked _shared_libraries_, for quite obvious reason - to
Alex Yukhimets <[EMAIL PROTECTED]> wrote:
> Not exactly. GPL says that I can distribute a binary if it's source code
> of it and all of it parts (and libraries used) is available under GPL.
Please quote the relevant section.
Meanwhile, here's an extract from the GPL that might interest you:
Alex Yukhimets <[EMAIL PROTECTED]> wrote:
> 3. You may copy and distribute the Program (or a work based on it,
> under Section 2) in object code or executable form under the terms of
> Sections 1 and 2 above provided that you also do one of the following:
>
Oliver Elphick wrote:
> unix.hensa.ac.uksunsite.doc.ic.ac.uk
> wget http:1.97KB/s1.90KB/s
> wget ftp: 5.19KB/s5.42KB/s
wget uses HTTP/1.0, so must establish a new connection for
every file transfered via http, b
Bdale Garbee <[EMAIL PROTECTED]> wrote:
> a significant way for slink. Any work on device file consistency in
> cruft would be well-advised to wait a month or three, until this gets
> done. I'd hate to see a lot of work go into whacking around with the
> current MAKEDEV since I can't guarantee that
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> First off, I assume Oliver is testing single files. Secondly wget must
> recreate a data channel when using ftp anyhow so the fact that wget is
> only using HTTP/1.0 would not be relavent.
Oh.
How.. tacky.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL
Paul Slootman <[EMAIL PROTECTED]> wrote:
> This is of course trivial to do by putting a clear screen escape
> sequence at the top of /etc/issue. Make it 25 blank lines if you don't
> want terminal-type dependencies...
Conceptually, you probably don't want to clear the screen for new serial
connect
Kai Henningsen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Raul Miller) wrote on 26.04.98 in <[EMAIL PROTECTED]>:
>
> > Alex Yukhimets <[EMAIL PROTECTED]> wrote:
> > > 3. You may copy and distribute the Program (or a work based on it,
> > >
[EMAIL PROTECTED] (Raul Miller) wrote on 26.04.98 in <[EMAIL PROTECTED]>:
> > I don't like the idea of making dpkg itself yet more complicated.
Kai Henningsen <[EMAIL PROTECTED]> wrote:
> I think that's the only acceptable way, though (as long as we take dpkg
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Huh? If the maintainer wanted the file to be known to dpkg,
> they could have added a zero byte file to the paclkage (getting it
> listed), and then manipulated it in the post inst. *NO* need to muck
> around in /var/lib/dpkg. The cat idea is a
Kai Henningsen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Santiago Vila) wrote on 26.04.98 in <[EMAIL PROTECTED]>:
>
> > I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at
> > least) in /etc/skel/.bashrc. Would it be against policy?
>
> Policy 3.3.7 "'/etc/skel' should be a
Alex Yukhimets <[EMAIL PROTECTED]> wrote:
> Well, GPL or less restrictive as far as source code redistribution is
> concerned. Right?
Unless you want to discuss the particulars of license details, yes.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troub
t; >> would really try to challange the GPL in a court, I don't know if it
> >> would stand up.
At 04:14 PM 4/26/98 -0400, Raul Miller wrote:
> >FUD.
Shaya Potter <[EMAIL PROTECTED]> wrote:
> Why is this FUD?
Only the courts get to decide what would stand up
Shaya Potter <[EMAIL PROTECTED]> wrote:
> But you did need a special license to compile for Motif.
Good point.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Richard Braakman wrote:
> >The GPL specifically forbids the OS vendor from making use of the
> >shipped-with-the-OS clause. (This closes a large loophole).
> >So if Motif is considered a standard part of the Red Hat OS, then
> >everyone *except* Red Hat can distribute such a program.
Shaya Potter
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Hmm. I do think this leads to a dilution of technical discipline. And
> we already have way too many open bug reports; people do not seem to
> want to fix ``real'' bugs, and ``mere'' policy reports would be seen
> as fluff.
Policy is a kind of stat
Bob Hilliard <[EMAIL PROTECTED]> wrote:
> I think the problem has arisen because 1) the policy documents
> have not sufficiently delineated the difference between prescriptive
> (shall, must) provisions and (strong) recommendations (should, must),
> and 2) because some (many?) developers disag
Bob Hilliard <[EMAIL PROTECTED]> wrote:
> There are a nuamber of sub-threads in this thread using the same
> header. My posting was written before I saw the one that discussed
> open bugs. The "problem" that I was referring to was the disagreement
> between those who felt policy should be a
Jeff Sheinberg <[EMAIL PROTECTED]> wrote:
> If my idea of a useful default is different from yours, then let
> us each have her way with a configurable file.
You're right -- new behavior should be an option, not a new default.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> And now my comments:
> 1) He does not mention that selling is allowed. So you are not allowed to
> sell it.
Er, you're allowed to redistribute it freely, and there's no restriction
on selling it. What situation are you imagining where this is a proble
Shaya Potter <[EMAIL PROTECTED]> wrote:
> which is my point on, the fact that it's a little hypocritical (not very,
> but a little), for the FSF to make emacs compilable out of the box for
> Motif. They would never do that for Qt, which would be "free" to compile
> with, but Motif, which would cos
Kai Henningsen <[EMAIL PROTECTED]> wrote:
> > There's already a .bash_profile (and a .bashrc)
> > in /etc/skel/.
> And I strongly believe there shouldn't be any.
Well, frankly, nothing is "necessary" in /etc/skel/. The two bash
scripts are fairly content free, and .alias and .cshrc provided by tc
"Guy" == Guy Maor <[EMAIL PROTECTED]> writes:
> Guy> The constitution places no limitations on the developer's
> Guy> authority with regard to their own work. Your version says that
> Guy> the maintainers must follow policy.
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Is that such a bad thing,
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Why should you make your package conform?
Because it's the right thing to do.
> There is nothing that says you have to follow policy. Can the Tech
> committee make me do whatever they darned well please?
Well, they certainly can't make you read
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> You do have a tendency to jump to untenable positions. Who
> said that we shall remove all packages with bugs or all packages that
> fail to follow policy?
You made an ambiguous statement. You made a statement about how policy
should have more
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Please point the clause to me that I should use the help of a
> a dictionary to elucidate for my feeble intellect.
Policy: 1. a plan of action; way of management; "It is a poor policy to
promise more than you can do." "The tight-money policy was
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Well, policy means something which has been adopted by a body. Hace
> we actually done so? Am I saying we interpret the contents of the
> policy documents differently? no, but the significance of the policy
> documents definitely shall change.
Er..
Richard Braakman <[EMAIL PROTECTED]> wrote:
> Lintian would have to parse that in order to get a full list, and it
> doesn't do that (yet).
Another possibility would be to run a test install on some
machine, with strace examining the calls used during the
installation.
--
Raul
--
To UNSUBSCRIB
Marcelo E. Magallon <[EMAIL PROTECTED]> wrote:
> Alternatives, as I understood them, have to be command line compatible
> because a situation like the one I just described is not desirable.
Alternatives have to be command line compatible, but that means you need
a defined interface that they all s
Is there any reason we couldn't do a delayed debian-hamm-alpha release?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mark W. Eichin <[EMAIL PROTECTED]> wrote:
> The motif code in emacs is relatively new, and totally cosmetic.
Hm... in that case, I'm surprised it's there at all.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> I hope you are well aware of the fact that a lot of people will not
> understand it, and probably will ask you about it. I can tell you that most
> german readers may be confused. I don't know about other countries, but I
> assume the situation is not v
Rev. Joseph Carter <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 30, 1998 at 01:49:06AM +0200, Remco Blaakmeer wrote:
> Why is xfs in xbase at all? It's not required to use X. I would suggest
> just pulling it out to its own package.
Careful when doing this that you don't break people's configuratio
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> OK. I give. And, on the principle that if you can't beat 'em,
> join 'em, I now agree with Jame Troup and Dale Scheetz and formally
> declare that Policy does not govern may packages from this point on,
> and shall close any policy related Bugs
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Again, this happens not to be the case. I was perfectly happy
> letting policy be policy until a well respected senior Debian
> developer made statements to the effect "Go right ahead and
> violate policy. Thats what I do"
>
> And anoth
Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
> from a first look at debian 2.0 i'm disappointed. ok, everything is moved to
> glibc, and there are lots of new packages. but where is the enhancement ?
If I recall correctly, the stated goals of this release where upgrade
to glibc 2.0, and variou
Bruce Perens <[EMAIL PROTECTED]> wrote:
> I've been giving serious thought for a while to forming a new Linux
> distribution. My reason is to fulfill some goals that currently are
> not addressed by Debian or the commercial distributions.
>
> I've posted my first message on this topic to debian-dev
Ean Schuessler <[EMAIL PROTECTED]> wrote:
> My personal feeling is that every man hour that Debian loses to this
> effort is one man hour too many.
Er.. Debian is not that kind of effort.
Personally, I think every hour of flamage we lose will be paid back
in an order of magnitude of better coordi
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> 1 - They don't actually have package dependencies. They have
> dependencies on files - big difference.
Perhaps this could be synthesized from a complete list of all
files provided by rpm, and a limited scope which prohibits
presenting competing
nd "hope they work", especially not
> a month+ into freeze.
I didn't realize that pam was this unstable. [As in: it's been around
for a while, and I didn't realize the decision had been made this
recently.]
Raul Miller <[EMAIL PROTECTED]> writes:
> > Not g
James Troup <[EMAIL PROTECTED]> wrote:
> I never said it was unstable and it isn't. But we haven't used it
> before and I don't care how stable it is, we should not and will not
> start recompiling core applications with a previously unused (*in
> Debian*) library, one month into a freeze. The de
Michael Meskes <[EMAIL PROTECTED]> wrote:
> - all graphic packaages with GIF support
For what it's worth, GIF support is doable with free software, just not
compressed gifs. [gif supports a variety of compression mechanisms,
including "none".]
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> I agree with Ian. The .deb file format is expressly for the distribution
> of configured executables (binaries for short). Using this format for
> source distribution is simply asking for trouble.
Um... so does this mean we have to retract the kernel-sourc
Patrick Ouellette <[EMAIL PROTECTED]> wrote:
> No doubt every product needs a focus. The rift opened when Bruce
> attempted to get the developers to see the value of marketing TO an
> audience.
Hmm... the toughest part of a development project is analysis -- figuring
out what needs to be done. Ma
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> What we are talking about here is "repackaging" the source tree into a
> .deb file. Very undesirable as it defeats all the good points of the
> current source package system.
Yet our current source package system needs work. It doesn't give much
of a clue
On Thu, Apr 30, 1998 at 11:32:00AM -0700, Bruce Perens wrote:
> > The patent expires in August.
Rev. Joseph Carter <[EMAIL PROTECTED]> wrote:
> You think nobody is going to try and snatch it then?
Er.. how do you snatch an expired patent?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> As to source dependency problems, it is my understanding that all the
> packages in the main distribution can be built using only packages from
> main.
That's a lot of packages. I've used .deb packages which include source on
little dinky machines with on
Bear Giles <[EMAIL PROTECTED]> wrote:
> That said, I can't see anyone using a MCA card as his primary
> interface.
I can see this, or serial console, being used for a server.
Also, don't forget the sorts of interfaces blind people use...
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> Actually, you'd be insane to put a MCA card in a server (you'd have to get
> it second hand and so on). They generally slow down the machine because of
> the limits they place on the ISA bus and require special mca screens!
I've put together my share of
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> We do need a statement saying that the project has indeed adopted
> this policy document, and the ``policy'' nomenclature is not a
> ``mistake''.
We have one -- Ian made it. You've been objecting to it.
[Actually, we have many such statements, go
Ronald van Loon <[EMAIL PROTECTED]> wrote:
> I find having a constitution sprung on me out of the blue, as well as the
> forming of a technical committee whose authority is unclear rather
> unsettling and contrary to the open way things have been handled so far -
> rather un-Debian, so to speak.
Jules Bean <[EMAIL PROTECTED]> wrote:
> deb, however, is not the appropriate format for a source distribution - and
> by distributing something in source form as .deb, you are spreading a small
> amount of confusion.
So this means we should stop distributing .el sources, and compiling
them in the
Stephen Carpenter <[EMAIL PROTECTED]> wrote:
> now if we only had a featherball
This kinda defeats one of the advantages of distributing diffs... unless
we also want to distribute an exploded version of the ar (or if we
could somehow get the ftp server to let you "cd" into an ar archive).
--
Stephen Carpenter <[EMAIL PROTECTED]> wrote:
> featherball was a joke by the way...
Sure, but it would be easy enough to put all the various source pieces
into an ar archive (kind of like what we do for the binary pieces
when we create a .deb file), and the way things are heading
maybe that's som
Daniel Martin at cush <[EMAIL PROTECTED]> wrote:
> What about a pine-installer package?
>
> This would be similar to the netscape3 and netscape4 packages of old -
> the user would be asked in the preinst to put the pine .orig.tar.gz,
> the .diff.gz and the .dsc files into /tmp (or $TMPDIR); if th
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> What is your point? The .deb packaging of source doesn't deal with source
> dependencies any better than the current source package.
Sure it does. You put the dependencies on the Depends: line of the
control file.
> > > There is no current declared metho
Daniel Martin at cush <[EMAIL PROTECTED]> wrote:
> I don't quite understand what ability it is that you think would be
> discarded. The ability to distribute everything needed to compile and
> install pine all at once?
Essentially, yes.
> I don't see how this would not be accomplished by a pi
> > Sure it does. You put the dependencies on the Depends: line of the
> > control file.
James Troup <[EMAIL PROTECTED]> wrote:
> You can do that in the .dsc file too, but it suffers from the same
> problem, i.e. what to do with source dependencies like svgalibg1-dev,
> which are arch-specific wh
I <[EMAIL PROTECTED]> wrote:
> Sure: we do need to fix our source packaging system. I don't
> agree with that very strongly.
Argh.. bad editting on my part.
I *do* agree very strongly that we need to fix our source packaging
system.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> I wish you would talk to Raul directly. He points out that
> violations of policy shall be enforced thus:
> a) since policy is supposed to be authoritative for bug filers, and
> policy violation can be flagged as a bug.
> b) any disputes ab
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>Policy should be followed, except where a discussion about the clause in
>question is still ongoing, in which case the maintainer may indulge in a
>policy violation if they feel it is a technically superior
>approach.
Hmm.. this is actu
Buddha Buck <[EMAIL PROTECTED]> wrote:
> Your objection is to the use of the admittedly subjective criteria
> "if they feel it is a technically superior approach." Would the
> (slightly) more objective criteria "if they feel that strict adherence
> to the policy would jeopardize system integrity or
Robert Woodcock <[EMAIL PROTECTED]> wrote:
> Yeah, that's right, an editor that opens /dev/mem.
If you do an objdump (-Slx) on the binary, you'll see that it's trying
to treat the screen as a region of memory.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe
Rev. Joseph Carter <[EMAIL PROTECTED]> wrote:
> You need MTA. You just do. But you don't need a complex MTA. If you
> consider sendmail the standard to judge by, most everything is smaller,
> simpler, or better for personal systems. My personal choice for an MTA is
> qmail. The savings in conf
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> The reason I feel compelled to ask is that I will be creating two new
> names: xvi and xae.
xvi, intuitively, seems to refer to an x aware version of vi (elvis or
vim). How about xaevi?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> ln -s '/bin/ae -f /etc/aex.rc' xae
>
> and, while it seemed to build the link I desired (it looks good with ls
> -l) when I try to execute xae, bash tells me the file is not found.
>
> Any idea what I am doing wrong?
That's only going to work if yo
John Labovitz <[EMAIL PROTECTED]> wrote:
> have you looked at ssmtp? i just took a quick look at the source, and
> it seems that it's *extremely* simple -- sounds like a good one for a
> send-only MTA.
The problem with ssmtp is that it doesn't have a queue. That means
if it can't deliver the mes
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> This is the first I have heard of our Policy documents being
> goals, and I disagree.
Policy, by its very nature, lies somewhere between goals and procedures.
While the DFSG and Social contract are very good, they don't say a lot
about the tech
> > root: The person who gets root's mail (also daemons', etc).
> > This userid (on the mailhub) get all mail sent to
> > local adressees with userids less than 10. In other
> > words, she gets mail the system mails to root, daemon,
> > etc.
Rev
On Sat, May 02, 1998 at 06:52:47PM -0400, Raul Miller wrote:
> > mail supports procmail. ssmtp does not support mail reception, nor does
> > it support local mail delivery.
Rev. Joseph Carter <[EMAIL PROTECTED]> wrote:
> one word: fetchmail.
fetchmail doesn't do local
Rev. Joseph Carter <[EMAIL PROTECTED]> wrote:
> Test $DISPLAY, it's the Right Way to test for X.
But not the right way to test for xterm.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> What would be wrong with having the "non-x" ae tell you in the help
> screen what you need to run to get xterm support? The need for this
> xterm support comes from folks who want to administer a base system
> remotely from a system using an xterm. This is
Drake Diedrich <[EMAIL PROTECTED]> wrote:
>Yep, but it'd be nice if there were guidelines on how to keep local
> packages out of the way of upstream debian packages.
Er.. there are: put everything local in /usr/local/. (or, for that matter,
under /home/.)
If you're stuck with something elsew
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> You can configure fetchmail to run through procmail.
Er, the fetchmail FAQ implies that if you use -mda procmail you can lose
mail to resource exhaustion.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Sendmail configuration is tough but it is also the best documented MTA
> bar none!
Please don't confuse lots of documentation for well documented.
In fact, a useful documentation tactic is to alter the program to
make it easier to document.
--
Raul
Dale Scheetz <[EMAIL PROTECTED]> wrote:
> Is the info page wrong? Should I submit a bug?
Yes.
Aside: on solaris it's /var/adm/utmp, on the bsd system I have access to
it's /var/run/utmp, I don't remember what system would have it in /etc/.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> In my opinion, sendmail is well documented *and* has lots of
> documentation. I also fail to find sendmail.cf obfuscatory -- but
> then, I have been writing sendmail.cf files since 1992.
Depends what you're trying to do, I suppose.
When I wan
> > > Test $DISPLAY, it's the Right Way to test for X.
On Sat, May 02, 1998 at 08:24:50PM -0400, Raul Miller wrote:
> > But not the right way to test for xterm.
Rev. Joseph Carter <[EMAIL PROTECTED]> wrote:
> If $DISPLAY is set you're either in an xterm, rxvt,
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> >> In any case, policy is not meant to be followed anyway.
Raul Miller <[EMAIL PROTECTED]> writes:
> Raul> Cut it out, Manoj.
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Why? You should be happy I'm on yo
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> There are several problems with the packaging of enlightenment. It's
> menuing system is *not* easy to integrate with debian menu. This is simply
> because of the flexible and highly detailed syntax it uses. It is not
> modular in any way.
A prelimina
t/plain
>
>This report relates to a message you sent with the following header fields:
>
> Message-id: <[EMAIL PROTECTED]>
> Date: Sat, 02 May 1998 20:24:50 -0400
> From: Raul Miller <[EMAIL PROTECTED]>
> To: debian-devel@lists.debian.org
> Subject: Re: Co
Shaleh <[EMAIL PROTECTED]> wrote:
> I just was un-subscribed from debian-user for generating too many
> bounced mails. I have now problems with my mail. I have received some
> 400 e-mails in the last day and a half and sent around twenty. I work
> for the ISP, our mail server is stable. Otherwi
Raul Miller <[EMAIL PROTECTED]> wrote:
> I expect that everyone who has sent email to debian-devel this
> weekend will have been unsubscribed.
[Er... probably not everyone: the "too many bounces" mechanism
probably won't knock off people who posted just a few times.]
-
Martin Schulze <[EMAIL PROTECTED]> wrote:
> SmartList removes addresses after it has received 4 bounces per list
> per address. Sometimes it's confused though.
I take it, SmartList isn't using VERP but is instead trying to
decipher the bounce message?
--
Raul
--
To UNSUBSCRIBE, email to [EMA
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Raul> I've mostly agreed with (Buddha and Philip's) statement you
> Raul> quoted a few days ago which talks about what to do when policy
> Raul> doesn't apply properly. I think it has a weakness: in creating
> Raul> the rules for how "debian-policy" is
Bill Leach <[EMAIL PROTECTED]> wrote:
> I am a bit frustrated with hamm right now. As of just before hamm went from
> 'unstable' to 'frozen' almost every upgrade on my PC box 'breaks something'.
> I was literally 'spoiled' by the fact that during the last 6+ months of
> development under unstable
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Raul> You honestly think this is good enough for new developers? I
> Raul> must confess that I'm not really in touch with the sort of
> Raul> things they would think.
>
> Of course. You gotta trust people some time. I think we give
> folks the
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> You suddenly seem to be arguing that policy never be amended
> since we may just be screwing it up.
Er... no. Not even close.
Later,
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [E
Steve McIntyre <[EMAIL PROTECTED]> wrote:
> I'm happy that we can work with this license, as we distribute diffs.
> Thomas thinks otherwise. Thoughts?
This license conflicts with point 3 of DFSG. We can't distribute
modified versions under the same terms as the original.
--
Raul
--
To UNSUBSC
101 - 200 of 513 matches
Mail list logo
