Bug#594940: Includes binary-only and obfuscated C code
On Sat, Nov 13, 2010 at 08:13:36PM +0100, Petr Salinger wrote:
>> what would the effect on the
>> kfreebsd-* kernel be of removing all of the files which were originally
>> mentioned in Ben's mails in this bug report, and is that an option which
>> has been considered by the porters?
>> From my (non-DD) POV, the most problematic are network drivers
> - binary is packaged in firmware-linux-nonfree as /lib/firmware/3com/typhoon.bin
> - binaries are packaged in firmware-linux-nonfree as /lib/firmware/e100/*
> For our port is very important to release. It would be better to release
> even without any of these drivers compared to not release at all ...
>> fwiw, if the current firmware-loading mechanism could be extended to
>> support using the firmware-* packages, the SRMs would be prepared to
>> look at introducing the updated mechanism - and any necessary new
>> firmware packages - as part of a Squeeze point release, if desired /
> Could be the plan:
> 1) drop all files from Ben's mail, repackage .orig.tgz, disable drivers
> 2) upload into sid and ask for propagation into squeeze
> 3) start extending firmware-loading mechanism
> 4a) upload into sid and ask for propagation into squeeze
> 4b) upload into stable-proposed-updates
> Whether 4a or 4b depends on our timing.
> I have to note, that this is my personal planing,
> not planing of whole porter group, but I expect they would agree.
This looks like the way to go. I am sorry I don't have a lot of time to
spend on that, but I can do the upload once everything is ready.
About the firmware loader mechanism, another alternative is to package
all removed (but distributable) firmwares that are currently already
built as .ko in a separate source package, and build
firmware-kfreebsd-nonfree from it. But I agree it would be even better
to be able to load firmware in the same format as the linux kernel.
Aurelien Jarno GPG: 1024D/F1BCDB73