On Wednesday 03 May 2006 05:34, Philippe Trottier wrote:
> We got some old school install done in a server around town, the libgpm was
> located in /usr/lib while /usr was only mounted later. This is a bug...
> Nothing should have a soft link to /usr/* from /bin or /lib*. Anyway it
> was an easy f
On Wed, May 03, 2006 at 01:51:39PM -0500, Grant Goodyear wrote:
> I just had somebody ask me about whether or not we still needed LDAP
> help. It's a good question, and I didn't know the answer, which is
> rather embarrassing since I'm the one who filed the LDAP staffing
> request. Since then I b
Grant Goodyear <[EMAIL PROTECTED]> said:
> I just had somebody ask me about whether or not we still needed LDAP
> help. It's a good question, and I didn't know the answer, which is
> rather embarrassing since I'm the one who filed the LDAP staffing
> request. Since then I believe that lcars had t
Grant Goodyear wrote:
> PS. Does anybody know if we do still need people to help w/ LDAP?
Depends if you consider "rewriting a LDAP howto" as a "help with LDAP"
[1] :). Actually as I'm doing LDAP at work ATM, I might look at it
later, but if anyone want to contribute, they're always more than wel
I just had somebody ask me about whether or not we still needed LDAP
help. It's a good question, and I didn't know the answer, which is
rather embarrassing since I'm the one who filed the LDAP staffing
request. Since then I believe that lcars had taken LDAP over, or is
otherwise assisting robbat2
Philippe Trottier wrote:
> We got some old school install done in a server around town, the libgpm
> was located in /usr/lib while /usr was only mounted later. This is a
> bug... Nothing should have a soft link to /usr/* from /bin or /lib*.
> Anyway it was an easy fix.
>
> Could people around che
On Wed, May 03, 2006 at 01:22:39PM +0100, Roy Marples wrote:
> On Wednesday 03 May 2006 12:26, Jakub Moc wrote:
> > Well, it should not be loaded first of all... Hence why I want to have
> > an ability to turn off the coldplug thing *completely* on udev level.
>
> So maybe I should be clear in con
On 4/27/06, Kevin <[EMAIL PROTECTED]> wrote:
If I explore this idea with any further discussion, I'll be sure to
follow the suggestions here about another list and reading past messages
on that list.
Feel free to look at http://dev.gentoo.org/~radek/portki/
Short feature lists:
* designed to
Hi All,
Its with great pleasure that I announce a new vict^W^W^W^Wdeveloper to
the ranks, Mike Auty. I'm sure you'll all make him feel very welcome :)
Mike's been around helping many of us for a long time now, most recently
with the excellent work he's been doing on vmware.
Mike has this to say:
On Wednesday 03 May 2006 15:03, Mike Auty wrote:
> Roy,
> I think the complaint is the automatic loading of modules by udev.
> Seemingly in the udev Changelog this is referred to as "add udevtrigger
> to request events for coldplug", whereas it seems you're using coldplug
> to refer to the au
Roy,
I think the complaint is the automatic loading of modules by udev.
Seemingly in the udev Changelog this is referred to as "add udevtrigger
to request events for coldplug", whereas it seems you're using coldplug
to refer to the automatic starting of services. Is there another name
for
On Wednesday 03 May 2006 13:35, Jakub Moc wrote:
> I do understand, however ignoring runlevels settings is in itself a
> coldplug bug. :)
So don't use coldplug then!
RC_COLDPLUG="no" unless you're on pre19-r1 where it's "!*"
--
Roy Marples <[EMAIL PROTECTED]>
Gentoo/Linux Developer (baselayout,
On Wed, 2006-05-03 at 11:43 +0200, Paul de Vrieze wrote:
> On Sunday 30 April 2006 03:55, Lance Albertson wrote:
> >
> > Here's an idea I had tonight. Since we're going to be doing the Google
> > SoC this summer, perhaps a great project would be having someone work
> > on this migration (or at leas
Roy Marples wrote:
>> iptables already has "before net", doesn't exactly help. Well, I don't
>> need net on boot level first of all and I didn't set it to be launched
>> at that runlevel. The runlevel setting gets ignored, however.
>
> Hmmm, maybe you don't understand then :)
> If coldplug adds ne
On Wednesday 03 May 2006 12:26, Jakub Moc wrote:
> Well, it should not be loaded first of all... Hence why I want to have
> an ability to turn off the coldplug thing *completely* on udev level.
So maybe I should be clear in conf.d/rc that the RC_{COLD,HOT}PLUG stuff only
affects services started
Jakub Moc schrieb:
Well, it should not be loaded first of all... Hence why I want to have
an ability to turn off the coldplug thing *completely* on udev level. I
don't have any use for such automagic stuff, it just complicates things
instead of making them easier.
Well said.
Marius
--
gentoo-d
I'd prefer,
The first option (two yes/nos and a list) since it seems cleaner and
more obvious. The only issue that I could see is where someone might
want a service started by hotplug rather than coldplug or vice-versa. I
honestly don't know anywhere near enough about the difference (up u
Roy Marples wrote:
>> Anyway, what we really need is ability to turn off that coldplug thing
>> *completely* on *udev* level and restore some sanity. I really don't
>> need to have my TV card coldplugged at the point when /dev is being
>> populated by devices (e.g., Bug 130766 or Bug 128962).
>
>
On Wednesday 03 May 2006 11:57, Roy Marples wrote:
> Attached is a patch to pre19-r1 that does this.
Of course, everyone spotted the obvious mistake where RC_HOTPLUG="no" didn't
work with that patch. This should - heh.
--
Roy Marples <[EMAIL PROTECTED]>
Gentoo/Linux Developer (baselayout, netw
Roy Marples posted <[EMAIL PROTECTED]>, excerpted
below, on Wed, 03 May 2006 10:13:58 +0100:
> baselayout lets all hotplug events through and gives no control over this,
> whereas we can limit coldplug events via the RC_COLDPLUG variable.
> RC_COLDPLUG is currently just a pattern list, but used
On Wednesday 03 May 2006 10:33, Henrik Brix Andersen wrote:
> On Wed, May 03, 2006 at 10:13:58AM +0100, Roy Marples wrote:
> > RC_HOTPLUG="yes|no"
> > RC_COLDPLUG="yes|no"
> > RC_PLUG_SERVICES="net.wlan !net.*"
>
> I like this idea much better than the current implementation in
> baselayout-1.12_pr
On Wednesday 03 May 2006 10:37, Jakub Moc wrote:
> Roy Marples wrote:
> > RC_HOTPLUG="yes|no"
> > RC_COLDPLUG="yes|no"
> > RC_PLUG_SERVICES="net.wlan !net.*"
> >
> > or
> >
> > RC_HOTPLUG="yes|no|net.wlan !net.*"
> > RC_COLDPLUG="yes|no|net.wlan !net.*"
>
> I'm afraid I don't get the exact differen
On Sunday 30 April 2006 03:55, Lance Albertson wrote:
>
> Here's an idea I had tonight. Since we're going to be doing the Google
> SoC this summer, perhaps a great project would be having someone work
> on this migration (or at least do an unbiased test implementation). I'd
> be willing to provide
Roy Marples wrote:
> RC_HOTPLUG="yes|no"
> RC_COLDPLUG="yes|no"
> RC_PLUG_SERVICES="net.wlan !net.*"
>
> or
>
> RC_HOTPLUG="yes|no|net.wlan !net.*"
> RC_COLDPLUG="yes|no|net.wlan !net.*"
I'm afraid I don't get the exact difference :P, but what about honoring
both yes|no and list of services.
An
We got some old school install done in a server around town, the libgpm was
located in /usr/lib while /usr was only mounted later. This is a bug... Nothing
should have a soft link to /usr/* from /bin or /lib*. Anyway it was an easy fix.
Could people around check, and if they find anything dist
On Wed, May 03, 2006 at 10:13:58AM +0100, Roy Marples wrote:
> RC_HOTPLUG="yes|no"
> RC_COLDPLUG="yes|no"
> RC_PLUG_SERVICES="net.wlan !net.*"
I like this idea much better than the current implementation in
baselayout-1.12_pre19-r1.
I find it unintuitive that I can currently limit coldplug events
Hi List
I'm in two minds about something so I'm asking for input :)
baselayout lets all hotplug events through and gives no control over this,
whereas we can limit coldplug events via the RC_COLDPLUG variable.
RC_COLDPLUG is currently just a pattern list, but used to be a simple yes|no
I'm wonde
Hi everybody.
I would like to announce the availability of new (split) gnat ebuilds on x86,
amd64 and soon possibly on ppc. The technical announcement (of a "new way",
eclass and virtuals) has been done earlier (for those interested, see bug
#111340), so this is really just an unmasking announc
28 matches
Mail list logo
