Re: [Fedora-music-list] Alsa tools and firmware

[Tim Mayberry]

Sorry I didn't mean to reply to Thorsten off-list.

On 5/10/06, Tim Mayberry <mojofunk(a)gmail.com&gt; wrote:
>  On 5/9/06, Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 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
> if
>  > > 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
>  separate repositories...
>
>  FE repo:
>
>  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)
>
>  Livna/other repo:
>
>  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.
>
>  Tim.
>

Alsa tools and firmware

[Thorsten Leemhuis]

Am Mittwoch, den 10.05.2006, 12:43 +1000 schrieb Tim Mayberry:
>  Sorry I didn't mean to reply to Thorsten off-list. 
It really gets more and more confusing -- some of the Fedora mailing
list use ugly things ling mangling Subjects (Like the
[Fedora-music-list]), others don't (which is good).

The same with reply to -- some of our lists mangle the "Reply to" so
each reply goes to the list. Others (like this list) don't do that.
That's really really confusing and annoying.

I think it's time for a general Fedora mailing list policy so all
(most?) of our lists use the same behavior. 

CU
thl

Alsa tools and firmware

[Aaron Sherman]

Thorsten Leemhuis wrote:
>  It really gets more and more confusing -- some of the Fedora mailing
>  list use ugly things ling mangling Subjects (Like the
>  [Fedora-music-list]), others don't (which is good).
>     
This is essential, and many of us would not be able to subscribe to 
low-volume lists if they didn't identify themselves in the subject of 
their mail. The other option is to post-process the subject through 
procmail in order to munge the subject myself, but then my replies look 
odd, and I have to make an extra effort for every list.

>  The same with reply to -- some of our lists mangle the "Reply
> to" so
>  each reply goes to the list. Others (like this list) don't do that.
>  That's really really confusing and annoying.
>     
Reply-to munging is a matter of the list policy. Many lists prefer that 
threads not migrate off-list by accident. By setting a reply-to, the 
risk becomes private messages going to the list. Some list admins prefer 
it that way. I'm actually on one list that combines the worst of both 
worlds: no reply-to change, and the list will bounce any mail that 
includes any other To or Cc targets :-/
>  I think it's time for a general Fedora mailing list policy so
> all
>  (most?) of our lists use the same behavior. 
>     
Hrm... The Fedora mailing lists are probably too diverse at this point 
to impose anything that sweeping to all of them.

Alsa tools and firmware

[Bill Nottingham]

Aaron Sherman (ajs(a)ajs.com) said: 
>  Thorsten Leemhuis wrote:
>  >It really gets more and more confusing -- some of the Fedora mailing
>  >list use ugly things ling mangling Subjects (Like the
>  >[Fedora-music-list]), others don't (which is good).
>  >  
>  This is essential, and many of us would not be able to subscribe to 
>  low-volume lists if they didn't identify themselves in the subject of 
>  their mail. The other option is to post-process the subject through 
>  procmail in order to munge the subject myself, but then my replies look 
>  odd, and I have to make an extra effort for every list. 
I'm confused... if you have procmail available, why do you need
subject tagging to make separate lists useful?

Bill