Vijay Patil ([EMAIL PROTECTED]) said:
>I was going through the PS2 detection routines
> in the kudzu code (psaux.c) and struck a problem
> there. I tried copying the psauxProbe() function and
> mouse_read(), mouse_cmd() functions to another C file
> and running it (aft
Hello,
I was going through the PS2 detection routines
in the kudzu code (psaux.c) and struck a problem
there. I tried copying the psauxProbe() function and
mouse_read(), mouse_cmd() functions to another C file
and running it (after removing the psaux_device struct
operations, replacing them
Tony Nugent ([EMAIL PROTECTED]) said:
> (Should I bugzilla this as a suggestion, or does rh8.0 already have
> this functionality?)
Nothing that we ship that touches modules.conf handles includes
or conditionals. It's in bugzilla, but I doubt it will be changed
very soon.
Bill
On Wed Jan 29 2003 at 15:10, Bill Nottingham wrote:
> 'kudzu -q' will edit the modules.conf for you, for everything that it finds
> and recognizes.
One point about using /etc/modules.conf (and perhaps drifting
slightly off-topic as per the Subject line)...
At least up to rh7.3 (
Klingaman, Aaron L ([EMAIL PROTECTED]) said:
> > Does it work outside of the chroot? Is /proc mounted inside the
> > chroot?
>
> At this point, I can't run it outside of chroot because libnewt isn't on
> this bootcd. If, in the chrooted environment, I mount /proc (
> One note is that if the kernel being run isn't the same version as
> the kernel installed in the chroot, kudzu will *not*
> configure the device,
> as it won't be able to find the module for it.
>
> Bill
>
So I tried both copying the running (boot cd) ke
Klingaman, Aaron L ([EMAIL PROTECTED]) said:
> This is interesting, because kudzu is being run from a chrooted environment
> after a system has been installed (but before its been rebooted) over that
> network device. The running kernel is a modified 2.4.19 kernel. So the
> drivers a
Klingaman, Aaron L ([EMAIL PROTECTED]) said:
> I looked through the kudzu source and saw the section isDisabled() where it
> detiremined if a device was to be disabled, but I could not understand what
> each of the tests where checking (in trying to identify which one was
> catching)
>
> If the PCI device shows no interrupt, yes, that's how it will behave.
>
> Note that with current kernels, PCI devices can have no interrupts
> assigned until the module is loaded... this has been changed in
> more recent builds of kudzu.
>
> Bill
This is intere
hwconf file docs).
>
> Attached are the output of lspci and the resultant hwconf file.
>
> Is this a known issue with this version of kudzu? I haven't tried to use the
> latest release because upgrading to glibc2.3 for this project is not really
> an option right now.
I
I'm having a problem with the following version of kudzu/hwdata (should be
stock rh7.3 rpms):
kudzu-0.99.52-1
kudzu-devel-0.99.52-1
hwdata-0.14-1
During detection of an Intel 82557/8/9 NIC, its always disabling the device
(shows up as disabled in /etc/sysconfig/hwconf). I've tri
I would like to start a project with something kudzu related. What do you
suggest?
___
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Goupil, Regis ([EMAIL PROTECTED]) said:
> Emulex SAN HBAs are noted as "Unknown" in /usr/share/Kudzu/pcitable.
> Is there a procedure to register the PCI IDs in Kudzu beside updating the
> pcitable file ?
Update the pci.ids database at pciids.sourceforge.net; these will
Hello all,
Emulex SAN HBAs are noted as "Unknown" in /usr/share/Kudzu/pcitable.
Is there a procedure to register the PCI IDs in Kudzu beside updating the
pcitable file ?
Of course, the goal is to do whatever is needed to have these IDs known.
If this is not the rigth arena to
Hi,
This is a small patch for kudzu-0.99.63 (also works on 0.99.52 from
RedHat-7.3), it works well for me under RedHat-7.3 I hope someone else
can test it.
I have rebuild RPM/SRPMS of kudzu for RedHat-7.3 with the patch included,
they can be found at:
ftp://osso.univalle.edu.co/pub
On Thu, 31 Aug 2000, Ivan Jager wrote:
>Date: Thu, 31 Aug 2000 18:04:48 -0400
>From: Ivan Jager <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: rawhide: kudzu-0.68-1 fails to compile
>
>I didn't make the .spec
I didn't make the .spec file for the package. It was one in one of the gnome
packages a long time ago. I will continue building as a normal user and report
the next problem like that as a bug.
Thanks. :)
"Mike A. Harris" wrote:
>
> On Tue, 29 Aug 2000, Ivan Jager wrote:
> >
> >When building as
On Tue, 29 Aug 2000, Stephen C. Biggs wrote:
>> Because I have done so for several years with no problems until
>> last week when I had a "rpm --rebuild" delete several
>> subdirectories on my filesystem during "%clean" stage. RPM
>> should IMHO do anything it does in a chroot()'d jail. Making
On Tue, 29 Aug 2000, Ivan Jager wrote:
>> Because I have done so for several years with no problems until
>> last week when I had a "rpm --rebuild" delete several
>> subdirectories on my filesystem during "%clean" stage. RPM
>> should IMHO do anything it does in a chroot()'d jail. Making a
>> u
t-Type: TEXT/PLAIN; charset=US-ASCII
> >Subject: Re: rawhide: kudzu-0.68-1 fails to compile
> >
> >On Sun, 27 Aug 2000, John Summerfield wrote:
> >
> >>
> >> I've chowned it to me and do not build as root (regulars will have noticed I'm
> >&g
> "Mike A. Harris" wrote:
> > Because I have done so for several years with no problems until
> > last week when I had a "rpm --rebuild" delete several
> > subdirectories on my filesystem during "%clean" stage. RPM
> > should IMHO do anything it does in a chroot()'d jail. Making a
> > user calle
"Mike A. Harris" wrote:
> Because I have done so for several years with no problems until
> last week when I had a "rpm --rebuild" delete several
> subdirectories on my filesystem during "%clean" stage. RPM
> should IMHO do anything it does in a chroot()'d jail. Making a
> user called "rpm" and
> On Mon, 28 Aug 2000, Nitebirdz wrote:
>
> >Date: Mon, 28 Aug 2000 13:51:17 -0500 (CDT)
> >From: Nitebirdz <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >Subject: Re: rawhide: kudzu-0.68-1 fails to
On Mon, 28 Aug 2000, Nitebirdz wrote:
>Date: Mon, 28 Aug 2000 13:51:17 -0500 (CDT)
>From: Nitebirdz <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Re: rawhide: kudzu-0.68-1 fails to compile
>
>On Sun, 27 Aug 2
> On Sun, 27 Aug 2000, John Summerfield wrote:
>
> >
> > I've chowned it to me and do not build as root (regulars will have noticed
> I'm
> > reluctant to build anything as root; recent news wrt pinstrip is Good).
> >
>
> Excuse me for the stupid question, but why wouldn't you build a packag
On Mon, Aug 28, 2000 at 01:51:17PM -0500, Nitebirdz wrote:
> Excuse me for the stupid question, but why wouldn't you build a package as
> root? Security reasons? Even if you trust the sources? Just trying to
> learn something from you, guys. :-)
It's good practice because, among other things
On Mon, 28 Aug 2000, Nitebirdz wrote:
> On Sun, 27 Aug 2000, John Summerfield wrote:
> > I've chowned it to me and do not build as root (regulars will
> > have noticed I'm reluctant to build anything as root; recent
> > news wrt pinstrip is Good).
>
> Excuse me for the stupid question, but why w
On Sun, 27 Aug 2000, John Summerfield wrote:
>
> I've chowned it to me and do not build as root (regulars will have noticed I'm
> reluctant to build anything as root; recent news wrt pinstrip is Good).
>
Excuse me for the stupid question, but why wouldn't you build a package as
root? Securit
> On Sat, 26 Aug 2000, John Summerfield wrote:
>
> >> 3. How do you enable multiple kernels to be installed and
> >> simultaneuosly recompile packages with different kernels booted??
> >
> >Put them in different places, play with symlinks. That's what symlinks are
> >for, Sort of;-)
>
> That is
On Sat, 26 Aug 2000, John Summerfield wrote:
>> 3. How do you enable multiple kernels to be installed and
>> simultaneuosly recompile packages with different kernels booted??
>
>Put them in different places, play with symlinks. That's what symlinks are
>for, Sort of;-)
That is correct, and like
Trond Eivind =?iso-8859-1?Q?Glomsr=F8d?= writes:
> [EMAIL PROTECTED] (Svante Signell ) writes:
>
> >
> > After installation of kernel-headers-2.4.0-0.21 kudzu compiles. The
> > .spec file should reflect this dependency, so I would consider this a
> >
>
> 3. How do you enable multiple kernels to be installed and
> simultaneuosly recompile packages with different kernels booted??
Put them in different places, play with symlinks. That's what symlinks are
for, Sort of;-)
___
Redhat-devel-list ma
[EMAIL PROTECTED] (Svante Signell ) writes:
>
> After installation of kernel-headers-2.4.0-0.21 kudzu compiles. The
> .spec file should reflect this dependency, so I would consider this a
> bug (now reported here, not in bugzilla).
Which wouldn't have helped. Anyway, A
Bill,
Thank you, problem solved.
After installation of kernel-headers-2.4.0-0.21 kudzu compiles. The
.spec file should reflect this dependency, so I would consider this a
bug (now reported here, not in bugzilla). Next time I'll try to not annoy
you with my reports, supplying patches if pos
Svante Signell ([EMAIL PROTECTED]) said:
> Compile fails for root, non-root and i386, i686:
> ...
> cc -c -O2 -march=i686 -Wall -D_GNU_SOURCE -DVERSION=\"0.68\"
>-I/usr/include/python1.5 -o ide.o ide.c
> ide.c: In function `ideProbe':
> ide.c:214: structure has no member named `command_set_1'
Compile fails for root, non-root and i386, i686:
...
cc -c -O2 -march=i686 -Wall -D_GNU_SOURCE -DVERSION=\"0.68\" -I/usr/include/python1.5
-o ide.o ide.c
ide.c: In function `ideProbe':
ide.c:214: structure has no member named `command_set_1'
make: *** [ide.o] Error 1
Bad exit status from /var/tm
First, apologies for the mangled reply previously. The Ctrl-C-Y was
typoed as Ctrl-X-Y.
What I was going to say before I changed my mind was that I agree with
John to some extent - kudzu has it's place, but it's also caused me
some problems. Specifically, it's auto-probing comple
> > I have to disagree with that statement. I have found kudzu to do a very nice
> > job of detecting hardware and also changes to my system. I have both added
> > and deleted hardware and each time kudzu detected the change and made the
> > appropriate changes.
>
>
> I have to disagree with that statement. I have found kudzu to do a very nice
> job of detecting hardware and also changes to my system. I have both added
> and deleted hardware and each time kudzu detected the change and made the
> appropriate changes.
>
> I'm su
John Summerfield wrote:
>
> > Hello,
> >
> > When I build a 2.2.12 or 2.2.14 kernel for my own, kudzu crashes with a
> > segmentation fault. I think that I forgot something to enable which is
> > needed by kudzu. I suppose it depends on the pci settings, but I d
> Hello,
>
> When I build a 2.2.12 or 2.2.14 kernel for my own, kudzu crashes with a
> segmentation fault. I think that I forgot something to enable which is
> needed by kudzu. I suppose it depends on the pci settings, but I don't
> know on which particular. I am using t
Daniel Jahre ([EMAIL PROTECTED]) said:
> When I build a 2.2.12 or 2.2.14 kernel for my own, kudzu crashes with a
> segmentation fault. I think that I forgot something to enable which is
> needed by kudzu.
IEEE1284 autoprobe.
This bug is fixed in the current kudzu in rawhide.
Bil
Hello,
When I build a 2.2.12 or 2.2.14 kernel for my own, kudzu crashes with a
segmentation fault. I think that I forgot something to enable which is
needed by kudzu. I suppose it depends on the pci settings, but I don't
know on which particular. I am using the kudzu tool which was deli
I have noticed that when I try the 2.3 kernel kudzu wrongly detects a
PS/2 mouse I don't have. This causes problems when kudzu tries to
link /dev/ps2 to /dev/mouse.
This will cause problems once 2.4 is released.
--
Jean Francois Martinez
Project Independence:
44 matches
Mail list logo
