Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
On Saturday, 4 February 2023 22:12:24 CEST Salvatore Bonaccorso wrote: > Hi, > > On Wed, Feb 01, 2023 at 09:20:57PM -0600, Gunnar Wolf wrote: > > Hi! > > > > Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]: > > > > Would they fit into a separate source package not associated with > > > > raspi-config? > > > > > > I do strongly think they do not belong in the raspi-firmware package for > > > the reason I retitled this bug and retitled my response Subject. > > > Another reason is that the raspi-firmware package makes (several) > > > assumptions, namely that they are only used/usable on RPi devices and > > > have a /boot/firmware directory (where a FAT partition is mounted, > > > although that part is not checked for). I have previously expressed my > > > concerns/doubts about that, but that's outside the scope of this bug. > > > It also looks 'weird' to install the raspi-firmware package while you > > > only care about the wifi firmware and not care about RPi's at all. > > > > Right, I agree this should be a package of its own. I didn't know > > raspi-nonfree came from a "coherent" set of firmware sources provided > > by a single upstream. It is a distorsion that peopleinterested in > > brcmfmac firmware have to install raspi-firmware if they have > > different hardware. > > So I guess we can close this bug here, and the files can be shipped > with a new dedicated source package containing the firmware files, > since the last option of having them merged upstream in > linux-firmware.git seems unrealistic for now? > > Regards, > Salvatore > > p.s.: sorry misstyped initially the origin source package, was obviously > not meaning raspi-config, so raspi-firmware. Just quoting this here as AFAICT Salvatore's solution (new source package) is the right one (and removed from the raspi-firmware package). I'll not remove the 'upstream' tag as it's set by the maintainer, but if you think the RPi Foundation will do the work to send it to the linux-firmware repo, then I have a bridge I'd like to sell you. signature.asc Description: This is a digitally signed message part.
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
Hi Salvatore, On Sunday, 5 February 2023 16:17:58 CET Salvatore Bonaccorso wrote: > > > So I guess we can close this bug here, and the files can be shipped > > > with a new dedicated source package containing the firmware files, > > > since the last option of having them merged upstream in > > > linux-firmware.git seems unrealistic for now? > > > > We could do that, but wouldn't it make more sense to reassign it to wnpp > > (?) and turn it into a RFP type bug? > > > > That way we would preserve the history (and thus useful info) of this > > issue. > Sure, we can do that as well. Drawback is that the initial mail does > not contain the details for the RFP, but it is a sensible idea. Please follow your initial idea. If need be, we can always reference this bug in the new RFP bug. It's not like closing this bug will make it disappear from the face of the earth ;-) You (seem to) know what can and needs to be done, while I don't. Regards, Diederik signature.asc Description: This is a digitally signed message part.
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
Hi Diederik, On Sat, Feb 04, 2023 at 10:49:29PM +0100, Diederik de Haas wrote: > On Saturday, 4 February 2023 22:12:24 CET Salvatore Bonaccorso wrote: > > > Right, I agree this should be a package of its own. I didn't know > > > raspi-nonfree came from a "coherent" set of firmware sources provided > > > by a single upstream. It is a distorsion that peopleinterested in > > > brcmfmac firmware have to install raspi-firmware if they have > > > different hardware. > > > > So I guess we can close this bug here, and the files can be shipped > > with a new dedicated source package containing the firmware files, > > since the last option of having them merged upstream in > > linux-firmware.git seems unrealistic for now? > > We could do that, but wouldn't it make more sense to reassign it to wnpp (?) > and turn it into a RFP type bug? > > That way we would preserve the history (and thus useful info) of this issue. Sure, we can do that as well. Drawback is that the initial mail does not contain the details for the RFP, but it is a sensible idea. Thank you. Regards, Salvatore
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
On Saturday, 4 February 2023 22:12:24 CET Salvatore Bonaccorso wrote: > > Right, I agree this should be a package of its own. I didn't know > > raspi-nonfree came from a "coherent" set of firmware sources provided > > by a single upstream. It is a distorsion that peopleinterested in > > brcmfmac firmware have to install raspi-firmware if they have > > different hardware. > > So I guess we can close this bug here, and the files can be shipped > with a new dedicated source package containing the firmware files, > since the last option of having them merged upstream in > linux-firmware.git seems unrealistic for now? We could do that, but wouldn't it make more sense to reassign it to wnpp (?) and turn it into a RFP type bug? That way we would preserve the history (and thus useful info) of this issue. My 0.02 signature.asc Description: This is a digitally signed message part.
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
Hi, On Wed, Feb 01, 2023 at 09:20:57PM -0600, Gunnar Wolf wrote: > Hi! > > Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]: > > > Would they fit into a separate source package not associated with > > > raspi-config? > > > > I do strongly think they do not belong in the raspi-firmware package for > > the > > reason I retitled this bug and retitled my response Subject. Another reason > > is > > that the raspi-firmware package makes (several) assumptions, namely that > > they > > are only used/usable on RPi devices and have a /boot/firmware directory > > (where > > a FAT partition is mounted, although that part is not checked for). > > I have previously expressed my concerns/doubts about that, but that's > > outside > > the scope of this bug. > > It also looks 'weird' to install the raspi-firmware package while you only > > care > > about the wifi firmware and not care about RPi's at all. > > Right, I agree this should be a package of its own. I didn't know > raspi-nonfree came from a "coherent" set of firmware sources provided > by a single upstream. It is a distorsion that peopleinterested in > brcmfmac firmware have to install raspi-firmware if they have > different hardware. So I guess we can close this bug here, and the files can be shipped with a new dedicated source package containing the firmware files, since the last option of having them merged upstream in linux-firmware.git seems unrealistic for now? Regards, Salvatore p.s.: sorry misstyped initially the origin source package, was obviously not meaning raspi-config, so raspi-firmware.
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
Hi! Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]: > > Would they fit into a separate source package not associated with > > raspi-config? > > I do strongly think they do not belong in the raspi-firmware package for the > reason I retitled this bug and retitled my response Subject. Another reason > is > that the raspi-firmware package makes (several) assumptions, namely that they > are only used/usable on RPi devices and have a /boot/firmware directory > (where > a FAT partition is mounted, although that part is not checked for). > I have previously expressed my concerns/doubts about that, but that's outside > the scope of this bug. > It also looks 'weird' to install the raspi-firmware package while you only > care > about the wifi firmware and not care about RPi's at all. Right, I agree this should be a package of its own. I didn't know raspi-nonfree came from a "coherent" set of firmware sources provided by a single upstream. It is a distorsion that peopleinterested in brcmfmac firmware have to install raspi-firmware if they have different hardware. > > The other option is that they get included upstream in > > linux-firmware.git by upstream? > > Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that > was confirmed once again by their typical reaction to this exact request. > > I'm too 'lazy' to look it up, so I'll paraphrase it: > "It works for us (so fsck off). Can't you just use our files?" I doubt we will find true RPF fans here 😉 signature.asc Description: PGP signature
Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
Hi Salvatore and Gunnar, On Tuesday, 31 January 2023 19:17:43 CET Salvatore Bonaccorso wrote: > > Gunnar indicated that he's willing to remove the files from > > raspi-firmware, > > but they still need to be added to firmware-brcm80211, so pretty please? > > So I looked at this, and don't think the firmware-nonfree packages > should take it over. Why? > The firmware files are not part of linux-firmware.git . I understand that reasoning and as said on IRC, that was the reason that I did not know how to deal with that and therefor couldn't make a MR myself. > Would they fit into a separate source package not associated with > raspi-config? I do strongly think they do not belong in the raspi-firmware package for the reason I retitled this bug and retitled my response Subject. Another reason is that the raspi-firmware package makes (several) assumptions, namely that they are only used/usable on RPi devices and have a /boot/firmware directory (where a FAT partition is mounted, although that part is not checked for). I have previously expressed my concerns/doubts about that, but that's outside the scope of this bug. It also looks 'weird' to install the raspi-firmware package while you only care about the wifi firmware and not care about RPi's at all. > The other option is that they get included upstream in > linux-firmware.git by upstream? Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that was confirmed once again by their typical reaction to this exact request. I'm too 'lazy' to look it up, so I'll paraphrase it: "It works for us (so fsck off). Can't you just use our files?" Regards, Diederik signature.asc Description: This is a digitally signed message part.
