Still, breaking bind's access to root name servers is particularly
troublesome because it may tend to break all net access. It may be
worthwhile to remove db.root from the list of configuration files.
Especially, because this list isn't something anyone should need to
change.
I beg to
These packages don't conflict; they merely provide the same
service. There is no reason that these three packages cannot
coexist on the same system. Any namespace overlap can be
solved by alternatives or renaming, as such things are normally
rectified.
Debian policy should proscribe
Okay, then solve the problem of which one should actually work on the
standard port? You can't use update-alternatives if the software is
Well, I would prefer that things didn't start listening for connections
without asking first, but I can't imagine that that's a popular
suggestion.
On Fri, 29 Jan 1999, Russell Coker wrote:
What is a close(-1) supposed to do? The http program does one and I'm curious
as to why...
IIRC, close(-1) closes all open file handles. I'm not certain exactly
wher this is documented though.
On 29 Jan 1999, Stephen Zander wrote:
Scott == Scott K Ellis [EMAIL PROTECTED] writes:
Scott On Fri, 29 Jan 1999, Russell Coker wrote:
What is a close(-1) supposed to do? The http program does one
and I'm curious as to why...
Scott IIRC, close(-1) closes all open file
On Thu, 21 Jan 1999, Florian La Roche wrote:
There are reasons why all distributions stayed with /var/spool/mail.
Even Debian who also thinks a lot about making things sane/clean has
stayed with /var/spool/mail.
Note that Debian has not yet moved from FSSTND to FHS for the most part,
and
On Thu, Oct 15, 1998 at 02:39:05PM -0700, Philippe Troin wrote:
Scott K. Ellis [EMAIL PROTECTED] writes:
On Wed, Sep 30, 1998 at 07:14:20PM -0700, Ben Gertzfield wrote:
I'm a little confused. freetype2-dev conflicts with freetype1 (=
1.0.0.1998-03-22-1) yet freetype1 is nowhere
.
Now the first thing that apt wants to do when you run it is to commit
suicide by removing itself. Is there a workaround?
Yes, you encountered a bug in apt 0.0.16 (an error in the sorting code. Get
apt 0.0.17 from http://master.debian.org/~doogie/
--
Scott K. Ellis [EMAIL PROTECTED
On Sat, 10 Jan 1998, Craig Sanders wrote:
On Fri, 9 Jan 1998, Turbo Fredriksson wrote:
On Fri, 9 Jan 1998, Craig Sanders wrote:
On Fri, 9 Jan 1998, Lindsay Allen wrote:
Still one problem. /wg-15-locale/s//wg15-locale/
damn. i thought i got that one this morning.
i wont
On Sat, 3 Jan 1998, Hamish Moffatt wrote:
On Sun, Dec 28, 1997 at 03:47:22PM +0100, Richard Braakman wrote:
Philippe Troin [EMAIL PROTECTED]:
perlmagick-1.15-2
imagemagick-3.9.0-1
libhdf4g-dev-4.0.2-4 (Depends on libhdf4)
It's a strange dependency, but libhdf4 actually depends
On 30 Dec 1997, Mark W. Eichin wrote:
I was just upgrading a system from [hamm a few weeks old] to [hamm
today] using, for the first time, dftp (instead of a mirror and manual
dpkg -BORGiE runs.) I selected libnfslock, it created
/etc/ld.so.preload, and since then any attempt to run a
On Sat, 20 Dec 1997, Radu Duta wrote:
I've got a package version 1.5.0-1 that I've already packaged.
There is a new upstream release 1.5.1.
Should the new package be named 1.5.1-1 or 1.5.1-2 or is it up to
my discretion.
Since it's an entirely new source tree it would make sense
to use
On Sat, 20 Dec 1997, Tim Ferrell wrote:
I am in the process of upgrading my system to run current with hamm and
had a problem with the libmime-perl pkg relating to the libwww-perl pkg
that prevented both pkgs from configuring.
First libwww-perl requires libmime-base64-perl which does not
On Fri, 12 Dec 1997, Chris Fearnley wrote:
'Martin Mitchell wrote:'
If they want to remain with a libc5 development environment, they have two
choices, stay with bo, or use altdev from hamm. You regard utmp corruption
as a minor issue, I would not, especially if I expected that staying with
On 13 Dec 1997, Martin Mitchell wrote:
Scott Ellis [EMAIL PROTECTED] writes:
Installing libc5 from hamm forces you to abandon your old libc5
development system since it CONFLICTS (correctly) with libc5-dev. Not
everyone is going that route yet.
True, so they can stay with bo for now.
On Fri, 12 Dec 1997, Brandon Mitchell wrote:
Would it possible to make a (not altdev):
debian/dists/unstable/main/binary-i386/oldlibs/libc5-dev_5.4.33-7.deb
that conflicts with libc6-dev? And would this solve everyones problem?
I'm just wondering if the libc5 in this directory doesn't
On Fri, 12 Dec 1997, David Welton wrote:
On Sat, Dec 13, 1997 at 01:44:51PM +1100, Martin Mitchell wrote:
If they want to remain with a libc5 development environment, they have two
choices, stay with bo, or use altdev from hamm. You regard utmp corruption
as a minor issue, I would not,
On Fri, 12 Dec 1997, Joe Emenaker wrote:
On 12 Dec 1997, Rob Browning wrote:
Scott Ellis [EMAIL PROTECTED] writes:
I HAVEN'T HEARD ANY REASONS WHY UTMP CORRUPTION IS SO EVIL THAT WE
NEED TO MAKE ANYONE WHO WANTS TO RUN A FEW LIBC6 PROGRAMS ON BO GO
THROUGH HELL.
Say
On 12 Dec 1997, Rob Browning wrote:
The problem is that maybe *you* know what packages those are, but most
users expect to be able to upgrade without major system services
breaking if dpkg/dselect doesn't indicate that there's a problem.
Your approach would cause silent failures.
Imagine
On Fri, 12 Dec 1997, David Engel wrote:
On Fri, Dec 12, 1997 at 03:19:29PM -0500, Chris Fearnley wrote:
libc6: Conflicts: (libc55.4.33-6)
(Necessary due to utmp issue -- Hell, someone upgrading from a CD
with stock 1.3.1 will be able to corrupt utmp in the current scheme
anyway!)
On Sat, 13 Dec 1997, David Engel wrote:
On Sat, Dec 13, 1997 at 01:06:07AM -0500, Scott K. Ellis wrote:
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
Would it? What if they would also upgrade their libc5-dev to the same
version as the libc5 in hamm? Would that help? In the past these two
On 13 Dec 1997, Martin Mitchell wrote:
Scott K. Ellis [EMAIL PROTECTED] writes:
On Fri, 12 Dec 1997, David Engel wrote:
On Fri, Dec 12, 1997 at 03:19:29PM -0500, Chris Fearnley wrote:
libc6: Conflicts: (libc55.4.33-6)
(Necessary due to utmp issue -- Hell, someone upgrading
On Sat, 13 Dec 1997, Remco Blaakmeer wrote:
On Sat, 13 Dec 1997, Scott K. Ellis wrote:
The problem is that libc5-dev doesn't exist in hamm. Hamm has
libc5-altdev instead. This forces people who want to compile libc5 stuff
into the altgcc/lib*-altdev mode, requiring the mass removal
On 12 Dec 1997, Martin Mitchell wrote:
Chris Fearnley [EMAIL PROTECTED] writes:
debian/bo/binary-i386/base/libc5_5.4.33-6.deb conflicts with libc6
making it IMPOSSIBLE to upgrade!! I had to downgrade to
libc5_5.4.33-3.deb from a LSL CD (thank goodness this bug is not
shipped on CDs!!)
On 12 Dec 1997, Martin Mitchell wrote:
Scott K. Ellis [EMAIL PROTECTED] writes:
Huh? The upgrade path is quite clear: install a newer libc5 (5.4.33-7)
from hamm, then you may install libc6.
The solution isn't quite so simple. The libc5 from hamm DEPENDS ON libc6
On Thu, 11 Dec 1997, Chris Fearnley wrote:
The reason for my bug is to get the broken package off the ftp site.
Before anyone else breaks their system. Guy, if everyone believes that
5.4.33-7 in hamm solves the problem, could you replace
libc5_5.4.33-6.deb with libc5_5.4.33-7.deb? I won't
On Sun, 30 Nov 1997, Yann Dirson wrote:
Greg Stark writes:
We've got be be a little more careful with the Replaces header. I just
installed the libc6 version of comerr, and dpkg helpfully deinstalled
e2fsprogs.
That's perfectly normal if you previously had e2fsprogs = 1.10-6,
may not want that
arangement.
- --
Scott K. Ellis |In order to live freely and happily,
http://www.gate.net/~storm/| you must sacrifice boredom.
[EMAIL PROTECTED] | It is not always an easy sacrifice
else, such as info/texinfo, I don't want HTML
as well.
- --
|The mark of your ignorance is the depth of
Scott K. Ellis | your belief in injustice and tragedy.
http://www.gate.net/~storm/ | What the caterpillar calls the end of the world
.
++
|| Your friends will know you better in the |
| Scott K. Ellis | first minute you meet than your acquaintances |
| [EMAIL PROTECTED] | will know you in a thousand years
strong, it is annoying to beat dselect into submission
when you really don't want a package.
++
|| Your friends will know you better in the |
| Scott K. Ellis | first minute you meet than your
particular editor here. I personally use joe for
brief editing jobs and emacs for the big stuff, but I can understand the
expectations of someone familiar with unix typing vipw or such.
++
| Scott K. Ellis
?
You create fun deadlocks when one program does it lockfile/flock and the
other does it flock/lockfile.
++
| Scott K. Ellis | Argue for your limitations and |
| [EMAIL PROTECTED] | sure
are purely coincidental. Any resemblance |
| |between the above and my own views is|
| Scott K. Ellis | non-deterministic. The question of the existence |
| [EMAIL PROTECTED] | of views in the absence of anyone to hold them is |
| | left
terminal, or the view out my |
| | window are purely coincidental. Any resemblance |
| |between the above and my own views is|
| Scott K. Ellis | non-deterministic. The question of the existence |
| [EMAIL PROTECTED] | of views
the
capitilization :)
++
| Scott K. Ellis | Argue for your limitations and |
| [EMAIL PROTECTED] | sure enough, they're yours
.
++
|| Your friends will know you better in the |
| Scott K. Ellis | first minute you meet than your acquaintances |
| [EMAIL PROTECTED] | will know you in a thousand years.|
||-- Illusions
you better in the |
| Scott K. Ellis | first minute you meet than your acquaintances |
| [EMAIL PROTECTED] | will know you in a thousand years.|
||-- Illusions
. The solution is:
dpkg -i dpkg_1.4.0.8.deb
dpkg --clear-available
++
| Scott K. Ellis | Argue for your limitations and |
| [EMAIL PROTECTED] | sure enough, they're yours
is. Does perl look at the
site-perl directory before looking in its normal librarys?
++
| Scott K. Ellis | Argue for your limitations and |
| [EMAIL PROTECTED] | sure enough, they're yours
.
++
| Scott K. Ellis | Argue for your limitations and |
| [EMAIL PROTECTED] | sure enough, they're yours. |
||-- Illusions
--
Scott K. Ellis [EMAIL PROTECTED] Argue for your limitations
Systems Administrator, Anexis Inc. and sure enough,
Business Web Presence Hosting they're yours.
http://www.anexis.com/ -- Illusions
42 matches
Mail list logo