On Tue, 3 Mar 2009 16:07:38 -0500
Jarod Wilson wrote:
>
> > - Is there a long term goal to bring all the firmware from alsa-firmware
> >upstream into the kernel-firmware package?
>
> No clue... Would have to talk to some alsa folks.
>
David Woodhouse is working o
On Saturday 28 February 2009 11:47:57 Tim Jackson wrote:
> I maintain alsa-firmware and the following bug regarding file conflicts
> between recent versions of kernel-firmware and alsa-firmware got raised today:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=487873
>
> I
I maintain alsa-firmware and the following bug regarding file conflicts
between recent versions of kernel-firmware and alsa-firmware got raised today:
https://bugzilla.redhat.com/show_bug.cgi?id=487873
I'm not really familiar with the kernel package maintenance, nor who/what
governs
Steve Dickson wrote:
Chuck Ebbert wrote:
Steve Dickson wrote:
Now that devel kernels rpms require the kernel-firmware rpm, it makes
sense to me that one should be able to build both of them at the same
time. So this patch adds the "--with firmware" build option
which will al
Kyle McMartin wrote:
On Tue, Aug 05, 2008 at 04:19:07PM -0400, Chuck Ebbert wrote:
That's what it does. It includes all firmware, even for drivers that don't get
built. Look in firmware/Makefile and you'll see it builds lists
named fw-shipped-y, fw-shipped-m and fw-shipped- t
On Tue, Aug 05, 2008 at 04:19:07PM -0400, Chuck Ebbert wrote:
> That's what it does. It includes all firmware, even for drivers that don't get
> built. Look in firmware/Makefile and you'll see it builds lists
> named fw-shipped-y, fw-shipped-m and fw-shipped- then just me
Kyle McMartin wrote:
On Tue, Aug 05, 2008 at 11:01:17AM -0400, Jarod Wilson wrote:
On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote:
Chuck Ebbert wrote:
Steve Dickson wrote:
Now that devel kernels rpms require the kernel-firmware rpm, it makes
sense to me that one should be able to
On Tue, Aug 05, 2008 at 11:01:17AM -0400, Jarod Wilson wrote:
> On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote:
> > Chuck Ebbert wrote:
> > > Steve Dickson wrote:
> > >> Now that devel kernels rpms require the kernel-firmware rpm, it makes
> > >&
On Tuesday 05 August 2008 09:24:10 Steve Dickson wrote:
> Chuck Ebbert wrote:
> > Steve Dickson wrote:
> >> Now that devel kernels rpms require the kernel-firmware rpm, it makes
> >> sense to me that one should be able to build both of them at the same
> >>
Chuck Ebbert wrote:
> Steve Dickson wrote:
>> Now that devel kernels rpms require the kernel-firmware rpm, it makes
>> sense to me that one should be able to build both of them at the same
>> time. So this patch adds the "--with firmware" build option
>> whi
Steve Dickson wrote:
Now that devel kernels rpms require the kernel-firmware rpm, it makes
sense to me that one should be able to build both of them at the
same time. So this patch adds the "--with firmware" build option
which will allow kernel-firmware rpms to built with kernel r
Now that devel kernels rpms require the kernel-firmware rpm, it makes
sense to me that one should be able to build both of them at the
same time. So this patch adds the "--with firmware" build option
which will allow kernel-firmware rpms to built with kernel rpms.
This patch als
ecfile
parts too. As soon as we update to 2.6.26-git1, we'll get a separate
kernel-firmware package which is required by the main kernel binary
package.
> I suspect that (for now) we should make the kernel binary packages
> depend on kernel-firmware?
Done. There are some firmwares which ar
t for kernel-docs. No reason kernel-firmware couldn't be spit
> > out from the same build run, so far as I know.
>
> Good point; I'll do it like that. Thanks.
Actually, it already was -- it was building the kernel-firmware
subpackage for _both_ arch and noarch builds. I j
Don Zickus wrote:
On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote:
Don Zickus wrote:
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to
On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote:
> Don Zickus wrote:
>>>>> I suspect that (for now) we should make the kernel binary packages
>>>>> depend on kernel-firmware?
>>>>>
>>>>> Should the package own the
Jarod Wilson wrote:
We were trying to do this with RHEL (jcm was working on this). One
of the
issues I brought up (which no one had a solution for) was the case
for a
bad firmware for storage devices. Currently they are built into the
kernel. So if you stumble upon bad firmware, you just
Don Zickus wrote:
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get
that until we start to build it from a separat
> > to replace all the kernel firmware just to update their buggy one,
> > then they'll rush out and do this as soon as possible :)
>
> Better option might be another directory which appears first on udev's
> (and mkinitrd's) search patch. That way you can o
t; 'make firmware_install' stuff. Currently looks something like this.
> >
> > Is that something new upstream? It would be great to separate the
> > firmware from the kernel builds.
>
> http://lwn.net/Articles/284104/
> http://lwn.net/Articles/284932/
>
replace all the kernel firmware just to update their buggy one,
then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's
(and mkinitrd's) search patch. That way you can override firmware
without having to split the pa
> > to replace all the kernel firmware just to update their buggy one,
> > then they'll rush out and do this as soon as possible :)
>
> Better option might be another directory which appears first on udev's
> (and mkinitrd's) search patch. That way you can override f
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
> K. I guess I'm just raising it so we're aware of it. It's not exactly
> a loss, but my fear is that once we make it possible for someone else
> to replace all the kernel firmware just to update their buggy one,
> t
On Mon, 2008-06-09 at 15:48 +0100, David Woodhouse wrote:
> On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote:
> > Another issue that we never really solved was that we really need to
> > have one firmware package per firmware (group) so that others can
> > possibly ov
On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote:
> Another issue that we never really solved was that we really need to
> have one firmware package per firmware (group) so that others can
> possibly override their firmware without replacing the entire
> kernel-firmware package a
On Mon, 2008-06-09 at 15:15 +0100, David Woodhouse wrote:
> On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote:
> > On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
> http://lwn.net/Articles/284104/
> http://lwn.net/Articles/284932/
>
> git.infradead.org
is.
>
> Is that something new upstream? It would be great to separate the
> firmware from the kernel builds.
http://lwn.net/Articles/284104/
http://lwn.net/Articles/284932/
git.infradead.org/users/dwmw2/firmware-2.6.git
> >
> > I suspect that (for now) we should make the k
On Mon, 2008-06-09 at 10:01 -0400, Bill Nottingham wrote:
> Well, it means you may end up including various firmwares on architectures
> where they're irrelevant. But as long as you're willing to take the installed
> space hit, it's not a huge deal.
Yeah, it doesn't take much -- and it's better on
Jarod Wilson ([EMAIL PROTECTED]) said:
> > Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get
> > that until we start to build it from a separate srpm.
>
> We actually *can* make it noarch without much effort -- remember, the kernel
> is a s
On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
> Been playing with how I'd make the kernel package deal with the new
> 'make firmware_install' stuff. Currently looks something like this.
Is that something new upstream? It would be great to separate the
fir
directory owned by
filesystem, so you have singular ownership and both udev and kernel-firmware
can use it without either one explicitly requiring the other.
I'm content with requiring udev -- since it's udev which is going to
load anything that lives in /lib/firmware anyway, that actually
owned
> by
> filesystem, so you have singular ownership and both udev and kernel-firmware
> can use it without either one explicitly requiring the other.
I'm content with requiring udev -- since it's udev which is going to
load anything that lives in /lib/firmware anyway,
David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the new
'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Yeah, seems the sanest
On Mon, 2008-06-09 at 08:06 -0400, Jarod Wilson wrote:
> We actually *can* make it noarch without much effort -- remember, the
> kernel is a special beast that actually does get a noarch build pass
> done on it for kernel-docs. No reason kernel-firmware couldn't be spit
> out fr
On Monday 09 June 2008 06:04:08 am David Woodhouse wrote:
> Been playing with how I'd make the kernel package deal with the new
> 'make firmware_install' stuff. Currently looks something like this.
>
> I suspect that (for now) we should make the kernel binary packages
Been playing with how I'd make the kernel package deal with the new
'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Should the package own the /lib/firmware/ dire
Sorry for the delay in responding: I was off for the holidays.
As mentioned in bug 378651, it the new mkinitrd also solves my problem.
Thank you.
Chuck Murnane
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/m
On 12/20/2007 10:47 AM, Chuck Murnane wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=329511 and
> https://bugzilla.redhat.com/show_bug.cgi?id=240105 both appear to
> address failure of the kernel to load firmware in the initrd phase of
> system booting. I can confirm that the sec
https://bugzilla.redhat.com/show_bug.cgi?id=329511 and
https://bugzilla.redhat.com/show_bug.cgi?id=240105 both appear to
address failure of the kernel to load firmware in the initrd phase of
system booting. I can confirm that the second (aic94xx) bug, although it
results in a failure during
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, 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
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
>>> ke
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 package? Or maybe the
firmware
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 package? Or maybe the
firmware goes in the kernel package?
I personally prefer for
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 package? Or maybe the
> firmware g
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 package? Or maybe the
firmware goes in the kernel package?
Peter says the support for Anaconda / mkinit
Chuck Ebbert wrote:
> --- linux-2.6.20.noarch/drivers/base/firmware_class.c.orig2007-03-26
> 14:20:38.0 -0400
> +++ linux-2.6.20.noarch/drivers/base/firmware_class.c 2007-03-26
> 18:10:09.0 -0400
> @@ -81,8 +81,15 @@
> firmware_timeout_store(struct class *class, const char *b
Firmware default loading timeout is set to 60 seconds by a Fedora
patch (it's 10 seconds in the stock kernel.) Somehow, by the time
I've finished booting it's back to 10 seconds. Does anyone have an
idea why? I came up with this patch to make the minimum 60 seconds,
still all
48 matches
Mail list logo
