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
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 very
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 configurations
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 another
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 various
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-devel, as
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
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
, 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 good. [Sounds like a significant bug, too.]
The non-use of pam
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
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 PROTECTED]
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-source
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.
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 what's
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]
with
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 also
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...
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 statement
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 disagree
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 binding
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 subject
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 problem
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 cost each
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 tcsh
are
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, really? I
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 the
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
Oliver Elphick olly@lfix.co.uk 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
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 the
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
connections
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,
under Section 2) in object code or executable form under
[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 to
mean dpkg_*.deb).
I was taking 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 as empty as
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. Trouble?
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 in court. [And
then usually in a limited context.]
Giving up on the GPL before it's been tested because
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 [EMAIL
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]
with a subject of unsubscribe
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
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 surely
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 (like
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? Debian can
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:
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
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
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
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 if
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.
Does
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
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,
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
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
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]
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
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
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
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
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
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]
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
[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
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
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
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
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
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
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?
--
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
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
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
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
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
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)
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
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
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
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
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
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]
Oliver Elphick olly@lfix.co.uk 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
[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
[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:
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
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
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
[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
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
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
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...
--
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
301 - 400 of 483 matches
Mail list logo
