Re: Bug#594940: Includes binary-only and obfuscated C code
On Sun, 2010-10-03 at 13:04 +0200, Cyril Brulebois wrote:
> Ben Hutchings <firstname.lastname@example.org> (30/08/2010):
> > The following C files contain firmware images in binary-equivalent
> > form but are not obviously accompanied by the corresponding source
> > code: […]
> and thanks for your report. I'm not sure we're going to have time and
> manpower to fix this bug in time for squeeze; that's why I'm wondering
> whether it could be granted a squeeze-ignore exception. Cc-ing the
> release team.
Apologies for not getting back to you sooner regarding this.
Firstly, we'd like to thank Ben for his offer to help incorporate those
files which we are able to distribute into the existing firmware-nonfree
Sadly, the list mentioned in the bug log includes some files which we
cannot distribute for various reasons; these appear to be a couple of
sound drivers, some network card drivers, firmware for an ATM card
(which Google suggests is intended for use in Alpha machines) and some
serial multiplexers and adapters. Without the ability to distribute the
affected files, there is not a great deal we can do to resolve these
issues other than removing them.
For the remainder of the files, whilst we may consider granting a
squeeze-ignore tag, we would like to come to an agreement as to how we
can resolve these issues in the medium term. We appreciate that the BSD
kernel has not received the same level of upstream attention that the
Linux kernel has in recent years in terms of ensuring that all content
is freely distributable. We believe that working with them on these
issues can only be of benefit for free software, and would help to move
the kfreebsd-* architectures from "technology previews" towards fully
supported stable releases with everything we have to come to expect from
the Linux architectures.
Does the kfreebsd kernel include the ability to load firmware from
external files, akin to /lib/firmware on Linux? If so, this would
hopefully make the process of moving the firmware files out-of-kernel
much less painful, particularly for those cases where firmware-non-free
already includes the affected files.