Thomas Hood jdth...@gmail.com wrote:
I am interested in how openresolv stacks up against resolvconf.
...
What further pros and cons do people see out there?
Mh, having a quick glimpse at openresolv I doubt it is the drop-in
replacement for resolvconf that it suggests to be (Provides/Conflicts:
On Thu, Nov 18, 2010 at 11:41:37AM +1100, dave b wrote:
So what's kind of why i asked about how you were trying to find the bug.
Don't tell me to search through lots of C code point it out!
I don't have time for that and you seemed to know more!
Please calm down and don't shout at me. I'm not
Salvo Tomaselli tipos...@tiscali.it wrote:
Well, to me, it does indeed appear to be a GDM bug: I can not reproduce
this permanent VT allocation with either KDM, XDM or startx. The issue
It happens to me with kdm.
Before or after you logged in to a session?
Is it reproducible for you by just
On Wed, Nov 17, 2010 at 09:36:14AM +0100, Josselin Mouette wrote:
Le mercredi 17 novembre 2010 à 13:47 +1100, david b a écrit :
After upgrading from lenny to squeeze, gdm starts on vt8 always (even
after restarting it). It should start on vt7 as this is the expected
I noticed this happens
On Wed, Nov 17, 2010 at 06:01:53PM +0100, Josselin Mouette wrote:
Le mercredi 17 novembre 2010 à 17:15 +0100, Mario 'BitKoenig' Holbe a
écrit :
Well, to me, it does indeed appear to be a GDM bug: I can not reproduce
this permanent VT allocation with either KDM, XDM or startx. The issue
Simon McVittie s...@debian.org wrote:
The FHS says mkfs.* have to be on the root filesystem. I'm not entirely clear
why this is.
Well, I personally believe this holds for at least two of the purposes
listed in FHS Chapter 3:
* To enable recovery and/or repair of a system
* To restore a system
Goswin von Brederlow goswin-...@web.de wrote:
There is one big problem with an event based startup. Specifically for
raid1/4/5/6 devices. Those you can use just fine with missing devices
but the boot should really wait for all device to be present.
Well, this problem arises with
Thomas Goirand tho...@goirand.fr wrote:
Mario 'BitKoenig' Holbe wrote:
Thomas Goirand tho...@goirand.fr wrote:
Mario 'BitKoenig' Holbe wrote:
So far this is independent of third packages which is IMHO fine and
desirable. So far, this could be solved by a postfix-conf.d-snippet
shipped
Thomas Goirand tho...@goirand.fr wrote:
Mario 'BitKoenig' Holbe wrote:
So far this is independent of third packages which is IMHO fine and
desirable. So far, this could be solved by a postfix-conf.d-snippet
shipped with the amavis package.
Quite not. You also need to configure the incoming
Thomas Goirand tho...@goirand.fr wrote:
Mario 'BitKoenig' Holbe wrote:
Why would you like to go another way with mail servers?
Because upstream doesn't want a conf.d folder, unfortunately, and that
Well, you can have something equal without upstream support by
concatenating conf.d snippets
Thomas Goirand tho...@goirand.fr wrote:
What happens here is that, if you take a normal Debian system, then
install postfix, then let's say amavis, they don't talk to each other.
...
much spams. It is also totally unrealistic to say that it's up to the
system administrator to configure
Brian May [EMAIL PROTECTED] wrote:
If you want to replace a directory with a symlink, and the directory
still contains files, what do you do with these files?
Indeed, symlinks colliding with existing directories should give an
error while package installation. And IMHO this could even be done
Hello,
IMHO, one of the most frequently re-appearing issues in package-upgrades
is symlinks in previous package versions replaced by directories in
current versions and vice versa.
Although the Debian policy clearly states in 6.6 (4) A directory will
never be replaced by a symbolic link to a
Petter Reinholdtsen [EMAIL PROTECTED] wrote:
mount point. For the others, edit /etc/default/rcS and set RAMRUN and
RAMLOCK to 'yes'. There are still some packages unable to cope with
Hmm, is there any argument against making /etc/default/rcS a conffile or
an ucf file to make sure - or at
Hendrik Sattler [EMAIL PROTECTED] wrote:
Which OS combination does not define int to be 32bit on a 64bit architecture?
This is mainly compiler-, not primarily OS-dependent. And: all compilers
with an ILP64 data model.
However, the question should rather be: *why* compilers do not define
int to
Andreas Metzler [EMAIL PROTECTED] wrote:
It has been pointed out to me in http://bugs.debian.org/387699
that syvinit is going to move /var/run to a tmpfs to solve a long-standing
Yes, having the opportunity to mount /var/run on a tmpfs would be really
nice. Please consider the same for
Steve Langasek [EMAIL PROTECTED] wrote:
It is clear /to me/ from the juxtaposition of these two sentences that the
FHS intends for programs to be allowed to create such subdirectories without
them being removed at the beginning of the boot process. It is also clear
Well, it would then
Marco d'Itri [EMAIL PROTECTED] wrote:
The problem with supporting old kernels is not just the need to maintain
2.4 is not old, it's just stable :)
a few packages like initrd-tools or modutils, but that every important
package cannot rely on features of modern kernels: inotify, sysfs, etc.
Hendrik Sattler [EMAIL PROTECTED] wrote:
A good hint for such cases is to actually report such bugs to the driver
developers. Did you?
It's still in my reproduction and analysis-queue. However, 2.6 is not
my biggest priority atm (it will still take a while to get it stable
anyways :)).
You
Marco d'Itri [EMAIL PROTECTED] wrote:
Not all of them are buggy, e.g. ssh, inn and inn2 have the directory in
the package but also create it in the init script if needed.
I would consider this a bug, when a package ships things which it
expects to magically disappear and where it thus cares
Preben Randhol [EMAIL PROTECTED] wrote:
My point is that if I choose to install a doc packages I intend to use
it frequently and would therefore like that it is user friendly rather
than that one has squeezed some few kilobytes out by gzipping files. If
Agreed. Particularly since the saving
Joe Smith [EMAIL PROTECTED] wrote:
As I understand it, there is no good reason to have s.d.o in
my sources list, as the packages in there are for sarge, and may not be
compatible with the current sid ABI.
This is nonsense. If this should really be the way you understand it,
please ask yourself
On Tue, Jun 20, 2006 at 01:18:11PM -0300, Margarita Manterola wrote:
In cases where a security bug is being fixed, you usually try to
upload the package as soon as possible. If your sponsor is on
We did. 0.5.4-6sarge1 was on s.d.o as soon as possible. Since there were
no newer version in
23 matches
Mail list logo
