Dear Maintainer,

Pine64 RockPro64 requires firmware files that are currently packaged in
raspi-firmware, both in bookworm and sid:
$ dpkg -S brcm/brcmfmac43456
raspi-firmware: /lib/firmware/brcm/brcmfmac43456-sdio.txt
raspi-firmware: /lib/firmware/brcm/brcmfmac43456-sdio.clm_blob
raspi-firmware: /lib/firmware/brcm/brcmfmac43456-sdio.bin

A post install script fails, with the following error:
raspi-firmware: missing /boot/firmware, did you forget to mount it?
run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1

There is no /boot/firmware on RP64.
Can we move these files to a spearate firmware package?
That would solve the issue.

Best regards,
Krzysztof

[Krzysztof Aleksander Pyrkosz]
on Lenovo ThinkPad 10.  Perhaps the firmware blob should be moved to
firmware-brcm80211?

Petter Reinholdtsen <pere@hungry.com> (2025-01-07):

You followed up to #999485 a few months back. Having the blob moved
to firmware-brcm80211 was *not* the obvious plan[1], are you aware
of something that changed in that regard?

  1. https://bugs.debian.org/999485#81


Cheers,

[Cyril Brulebois]

Well, it has become more and more obvious that NEW processing is not
something to reliably wait for, as the pile of packages waiting in NEW
is slowly increasing and even fairly trivial and obviously free software
licensed packages has been waiting for a review for months.

Just for completeness sake, there seem to be a cluster of three issues
https://bugs.debian.org/999485, https://bugs.debian.org/1084224 and
https://bugs.debian.org/1064072, related to this firmware blob.  Perhaps
these should be merged and placed under one package, with affects to the
others?  Not sure where it best belong.

Petter Reinholdtsen <pere@hungry.com> (2025-01-07):

That does not match my experience, at all. And that's irrelevant to
implementing the best technical/legal solution for an issue that's not
exactly new (no pun intended).

[Cyril Brulebois]

Fortuntately we have measurements and graphs on
<URL: https://ftp-master.debian.org/stat.html > documenting the status,
so we do not need to depend on personal experience. :)

Would be great if that was the case, but alas, there are several
suboptimal solutions implemented in Debian to avoid waiting for NEW
processing.  I too wish that would not be the case, but pragmatic
solutions this month beat waiting indefinitely for the perfect one.

Petter Reinholdtsen <pere@hungry.com> (2025-01-07):

Stats are just that, stats. They don't dictate what happens to a
specific package.

Surely the pragmatic solution would start with a package reaching NEW in
the first place, instead of badmouthing, complaining, and handwaving.

YMMV.

Thanks for your feedback, Cyril!
Just reusing the very same function that was already defined by the
package maintainer in debian/kernel/postinst.d/z50-raspi-firmware and
trying to avoid that pointless (for a PINE64 device) error condition.
A cursory read of the full thread
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948712 should easily
make this clearer.

The very same issue applies for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064072, where a
Pine64 RockPro64 is affected. A closely related bug was filed via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999485 for the
firmware-brcm80211 package.

The raspi-firmware package contains the /lib/firmware/brcm/brcmfmac434*
blobs that are required to use the Wifi capabilities of some PINE64
devices, including the Pinebook Pro. These files would probably be
better positioned as part of the firmware-brcm80211 or other firmware
package, but there appear to be some reasons that impedes this so far.

Those using a Pinebook Pro are basically "condemned" to use the
raspi-firmware package for this blob component if we won't proper
network connectivity in Debian. And since the raspi-fimrware package is
designed with mostly RPI's in mind, these unfortunate postinst error
conditions arise if used outside of the intended scope.

Discerning RPI's in the postinst scripts from other ARM devices that use
the included firmware in different ways would very much help its wider
user base.

Thanks!
Paul

Paul Seelig <pseelig@rumbero.org> (2025-12-13):

Yes, I understood what was meant (reusing something), but that I'm
saying that particular function is not appropriate for the purpose
you're aiming for. (Spotting Pi family 4 versus detection a Pi,
respectively.)

Yes, having someone who steps us and tackles the split of those files
from the current raspi-firmware package (regardless of the destination
package) is the proper way to address the issue.

My mind is not made up regarding whether the mountpoint thing is
something that should remain (whether it's restricted to Pi or not), but
changing this only hides the actual problem longer, and that makes the
whole situation even worse in my book.

Again, the submitted patch does not actually do that.


Cheers,