> I kinda like it in %name whichever route we go here. Along the same
> lines as Ingo's kernel-rt packages, it makes it easier to install them
> in parallel with normal kernels for testing.
I was just remembering about Ingo's -rt builds. I hadn't looked. What he
uses is nearly identical to wh
> Ooh, I like it... Along those lines, what if we had Makefile include a
> Makefile.local if it existed, which was .cvsignore'd? Then you could
> tweak your local default build prefs to your hearts content without
> having to worry about accidentally committing them...
Actually you can write yo
David Woodhouse wrote:
On Fri, 2007-03-30 at 21:20 -0400, Jarod Wilson wrote:
Hrm, not sure why that doesn't pass the option through, but I hadn't
even thought to look at the Makefile to see how these flags would work
at that level. Out of curiosity, does the following work?:
$ make RPM_DEFIN
Roland McGrath wrote:
It is. And I was under the impression that's what Dave was thinking too,
but I'll let him speak for himself.
Well, do we want it in the package set? I figured we were talking about
"informal" builds that might be put up for ftp, but not be an integrated
part of the Fedora
On Fri, 2007-03-30 at 21:20 -0400, Jarod Wilson wrote:
> Hrm, not sure why that doesn't pass the option through, but I hadn't
> even thought to look at the Makefile to see how these flags would work
> at that level. Out of curiosity, does the following work?:
>
> $ make RPM_DEFINES="--define 'wi
David Woodhouse wrote:
On Fri, 2007-03-30 at 01:26 -0400, Jarod Wilson wrote:
Turns out the complexity of adding --with/--without support only
resulted in the on/off lines at the top of the spec being slightly
longer, so one can now additionally pass in, say, --without xen, on the
rpmbuild lin
On Fri, 2007-03-30 at 01:26 -0400, Jarod Wilson wrote:
> Turns out the complexity of adding --with/--without support only
> resulted in the on/off lines at the top of the spec being slightly
> longer, so one can now additionally pass in, say, --without xen, on the
> rpmbuild line to disable buil
> It is. And I was under the impression that's what Dave was thinking too,
> but I'll let him speak for himself.
Well, do we want it in the package set? I figured we were talking about
"informal" builds that might be put up for ftp, but not be an integrated
part of the Fedora world. If one rpmb
Roland McGrath wrote:
I already got it working and posted the spec and Makefile patch here.
Gah, sorry, I saw the patch, but missed that the spec mods were included
in it too.
(I've also got my stuff for building from git branches working now.)
Nobody answered about whether they wanted it c
I already got it working and posted the spec and Makefile patch here.
(I've also got my stuff for building from git branches working now.)
Nobody answered about whether they wanted it committed.
I didn't do it in a way intended to produce different variant rpms called
kernel-vanilla-V-R, if that's
Jon Masters wrote:
> Chuck Ebbert wrote:
>> At first glance it doesn't seem very hard to do something like this
>> on kernel install:
>>
>> ln -s raid456.ko
>> /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko
>> ln -s raid456.ko
>> /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko
Chuck Ebbert wrote:
At first glance it doesn't seem very hard to do something like this
on kernel install:
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko
ln -s raid456.ko /lib/modules/2.6.20-1.
On Fri, Mar 30, 2007 at 03:09:08PM -0400, Dave Jones wrote:
> Isn't that needed though to access higher config space on PCIE ?
> Or do we not have any drivers that use that yet, making it a nonissue?
>
Yeah, you need it to access Extended config space on PCI-Express, but the
only people who need
On Fri, Mar 30, 2007 at 03:04:39PM -0400, Kyle McMartin wrote:
> On Fri, Mar 30, 2007 at 01:15:28PM -0400, Chuck Ebbert wrote:
> > Jay Cliburn wrote:
> > > Chuck Ebbert wrote:
> > >> It seems like more and more problems with PCI MSI are turning up
> > >> in the 2.6.20 kernel. Discussion upstre
Kyle McMartin wrote:
>>
>
> Yeah, we've also turned off MMCONFIG by default. We've seen way too many
> bugs that go away when they're disabled.
>
Now that you mention it, that looks like a good idea too.
___
Fedora-kernel-list mailing list
Fedora-ker
At first glance it doesn't seem very hard to do something like this
on kernel install:
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid4.ko
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/drivers/md/raid5.ko
ln -s raid456.ko /lib/modules/2.6.20-1.2933.fc6/kernel/driver
On Fri, Mar 30, 2007 at 01:15:28PM -0400, Chuck Ebbert wrote:
> Jay Cliburn wrote:
> > Chuck Ebbert wrote:
> >> It seems like more and more problems with PCI MSI are turning up
> >> in the 2.6.20 kernel. Discussion upstream concluded that maybe
> >> it should have been off by default in 2.6.20, so
On Fri, Mar 30, 2007 at 02:47:28PM -0400, Chuck Ebbert wrote:
> Dave Jones wrote:
> >
> > Gets my vote too.
> > I've turned off CONFIG_PCI_MSI and turned it back on about 2-3 times
> > now for FC5/FC6, because each time it starts to look more promising,
> > it seems to find new ways to regre
Dave Jones wrote:
>
> Gets my vote too.
> I've turned off CONFIG_PCI_MSI and turned it back on about 2-3 times
> now for FC5/FC6, because each time it starts to look more promising,
> it seems to find new ways to regress.
>
> I might do a build next week in rawhide with it off again too,
> to see
A little follow-on to the "Longing for git-bisect" thread, in a
newly-created/subjected thread...
So, I've been poking around in the kernel spec file extensively the past
few days already... Any objections to my attempting to implement the
building of a kernel-vanilla package as well?
Roland, not
Chuck Ebbert wrote:
>
>> +printk(KERN_INFO
>> + "firmware_class: attempt to set timeout to %d\n",
>> + loading_timeout);
This message triggered during boot, so something /was/ screwing
with the timeout. Now it stays at 60 sec
On Fri, Mar 30, 2007 at 02:03:23PM -0400, Chuck Ebbert wrote:
> Pete Zaitcev wrote:
> > On Fri, 30 Mar 2007 11:00:12 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> >
> >> It seems like more and more problems with PCI MSI are turning up
> >> in the 2.6.20 kernel. Discussion upstream conclude
Pete Zaitcev wrote:
> On Fri, 30 Mar 2007 11:00:12 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
>> It seems like more and more problems with PCI MSI are turning up
>> in the 2.6.20 kernel. Discussion upstream concluded that maybe
>> it should have been off by default in 2.6.20, so maybe we sho
On Fri, 30 Mar 2007 11:00:12 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> It seems like more and more problems with PCI MSI are turning up
> in the 2.6.20 kernel. Discussion upstream concluded that maybe
> it should have been off by default in 2.6.20, so maybe we should
> just do that in Fedor
On Fri, 2007-03-30 at 13:15 -0400, Chuck Ebbert wrote:
> Jon Masters wrote:
> > Josh Boyer wrote:
> >> On Thu, 2007-03-29 at 16:16 -0400, Chuck Ebbert wrote:
> >>> Apparently the qlogic drivers don't have any firmware included in FC7,
> >>> so nobody can actually use a qlogic adapter. Should we be
Jon Masters wrote:
> Josh Boyer wrote:
>> On Thu, 2007-03-29 at 16:16 -0400, Chuck Ebbert wrote:
>>> Apparently the qlogic drivers don't have any firmware included in FC7,
>>> so nobody can actually use a qlogic adapter. Should we be patching the
>>> kernel like in FC6 or do we need a separate pack
Jay Cliburn wrote:
> Chuck Ebbert wrote:
>> It seems like more and more problems with PCI MSI are turning up
>> in the 2.6.20 kernel. Discussion upstream concluded that maybe
>> it should have been off by default in 2.6.20, so maybe we should
>> just do that in Fedora and make people who want it us
Chuck Ebbert wrote:
> Jarod Wilson wrote:
>> Chuck Ebbert wrote:
>>> Jarod Wilson wrote:
>>>
The minimalist approach that comes to mind is to make all the %define
build* bits all set to 1/enabled by default, and only flip them to
disabled where appropriate, so they'd be equivalent
Chuck Ebbert wrote:
It seems like more and more problems with PCI MSI are turning up
in the 2.6.20 kernel. Discussion upstream concluded that maybe
it should have been off by default in 2.6.20, so maybe we should
just do that in Fedora and make people who want it use "pci=msi"
to enable it? It's
Chuck Ebbert wrote:
It seems like more and more problems with PCI MSI are turning up
in the 2.6.20 kernel. Discussion upstream concluded that maybe
it should have been off by default in 2.6.20, so maybe we should
just do that in Fedora and make people who want it use "pci=msi"
to enable it? It's
It seems like more and more problems with PCI MSI are turning up
in the 2.6.20 kernel. Discussion upstream concluded that maybe
it should have been off by default in 2.6.20, so maybe we should
just do that in Fedora and make people who want it use "pci=msi"
to enable it? It's probably not going to
Jarod Wilson wrote:
> Chuck Ebbert wrote:
>> Jarod Wilson wrote:
>>
>>> The minimalist approach that comes to mind is to make all the %define
>>> build* bits all set to 1/enabled by default, and only flip them to
>>> disabled where appropriate, so they'd be equivalent to your allow* idea,
>>> in
32 matches
Mail list logo
