Sorry I didn't mean to reply to Thorsten off-list.
On 5/10/06, Tim Mayberry <mojofunk(a)gmail.com> wrote:
On 5/9/06, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> Am Dienstag, den 09.05.2006, 16:31 +1000 schrieb Tim Mayberry:
> The old plan was to move alsa-firmware to livna. The current plan is to
> solve the problems with alsa-firmware and ship what can be shipped.
> Someone (Legal, FESCo) simply has to say what files from alsa-firmware
> are okay for Extras, and what not. The last I heard was this:
> > I maintained some alsa-firmware in the old fedora.us days. During the
> > transition to Fedora Extras the package got "lost" -- it was unclear
> > the files in it were okay for the official Fedora Extras. See
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143249#c3
> > We dropped it then and forwarded the issue to legal. It got lost or was
> > forgotten, I can't remember. But I'd like to get this solved now that
> > someone asked for a Extras package of alsa-firmware in bugzilla.
> > So, where were the problems? Here is the main one:
> > > $ file ./mixartloader/miXart8.elf
> > > ./mixartloader/miXart8.elf: ELF 32-bit MSB executable, PowerPC or cisco
4500, version 1 (SYSV), statically linked, not stripped
> That is a pretty big problem.
> Some of this is probably ok for FE, but only those bits which are not
> libraries or binaries.
As I remember this issue was debated a fair bit on the debian lists a
while back, I didn't follow it too closely but I think they ended up
splitting the alsa-tools source package into alsa-tools and
alsa-firmware-loaders, with alsa-tools corresponding to roughly what
is in the FE alsa-tools package currently and alsa-firmware-loaders
being what is not. You then have to download the alsa-firmware
package from the ALSA website and configure it etc, which is not at
all ideal and I'm not suggesting it but it would still be better than
it is currently.
I haven't been able to find a clear explanation of the Fedora Extras
policy on packaging firmware but I haven't looked that hard
yet(perhaps you could offer some pointers), I'd be surprised if any of
the files in alsa-firmware would be able to be ok for FE.
> We should split alsa-firmware -- the "mostly free" parts should land in
> Extras, the others in Livna. Are you interested in doing this. I simply
> have no time for it ATM, never really was interested this alsa-firmware
> stuff and I don't even have hardware to test. Are you interested in
> driving this forward? You can of course count on my help.
The problem then becomes defining what can and cannot be packaged and
where. I'm quite willing to help driving this forward but I am not
qualified to work through any legal issues. I'd rather solve this
problem more quickly on a technical level if possible, even if it is
only somewhat temporary until a better arrangement can be worked out.
It seems like you are suggesting splitting the upstream alsa-tools and
alsa-firmware into 4 or 5 packages that would then reside in 2
alsa-tools.srpm -> alsa-tools.rpm, alsa-firmware-loaders-for-free-firmware.rpm
alsa-firmware.srpm -> alsa-firmware-free.rpm (If there is such a thing)
alsa-tools.srpm -> alsa-firmware-loaders-for-non-free-firmware.rpm
alsa-firmware.srpm -> alsa-firmware-non-free.rpm
Apart from all the obvious issues with something like that there is
still then the problem that some of the tools from the alsa-tools
package are still indirectly dependent on non-free firmware unless you
further split the packages.
I think I would prefer to modify the alsa-tools package so that it
builds everything from the upstream source including firmware loaders
as there are no legal issues with that as far as I know(only with the
firmware itself). Then for an alsa-firmware rpm to reside in an
external repository and require alsa-tools from FE.
Or alternatively, do what debian has done and split alsa-tools into
alsa-tools and alsa-firmware-loaders and have an externally hosted
alsa-firmware package dependent on alsa-firmware-loaders.
I'm a bit rushed today so I hope that all came out alright. I look
forward to help resolving this issue.