Thomas Hood 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:
resolvconf). At
Salvo Tomaselli 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 restarting kdm wi
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 no
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 K
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 happe
Simon McVittie 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
To recover a d
Goswin von Brederlow 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 non-event-based startup as we
Thomas Goirand wrote:
> Mario 'BitKoenig' Holbe wrote:
>> Thomas Goirand wrote:
>>> Mario 'BitKoenig' Holbe wrote:
>>>> So far this is independent of third packages which is IMHO fine and
>>>> desirable. So far, this could be s
Thomas Goirand 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
Thomas Goirand 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 co
Thomas Goirand 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 everything by hand. I
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 don
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 dire
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 l
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
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
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 :)).
> Y
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.
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 pro
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 /var
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 savin
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 your
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 unst
23 matches
Mail list logo
