Spec URL: http://www.timj.co.uk/linux/specs/alsa-firmware.spec SRPM URL: http://www.timj.co.uk/linux/srpms/alsa-firmware-1.0.12-1.src.rpm Description: This package contains the firmware binaries for a number of sound cards. Some (but not all of these) require firmware loaders which are included in the alsa-tools-firmware package alsa-firmware has not been in Fedora since Fedora.us days, even though it is absolutely vital to make some soundcards usable. There are several possible issues: 1. licensing/distribution 2. compliance with Guidelines Let's take (1) first. Thorsten did a bit of background research on this and summarised in a private mail on 2 June 2006: ====================================================================== I took a closer look at the latest upstream package at ftp://ftp.alsa-project.org/pub/firmware/alsa-firmware-1.0.11.tar.bz2 It contains a file COPYING in the root with the GPL. And a README with --- LICENSE AND COPYRIGHT ===================== The files contained in this package is regarded as the example data for each alsa-tools program. Hence, their copyright and license follow basically to the definition of alsa-tools programs. The detailed license and copyright is found in README of each subdirectory. --- alsa-tools contains a lot of license files with the GPL (and once LGPL). Most subdirs contains README files with terms like --- COPYRIGHT ========= Copyright (c) 2003 Digigram SA <alsa> Distributable under GPL. --- or --- COPYRIGHT ========= Copyright (c) RME Distributable under GPL. --- or --- COPYRIGHT ========= tascam_loader.ihx, tascam_loader.asm and an2131.asm: Available under GPL without restrictions. other firmware files: Copyright (c) 2003 Tascam / TEAC Corporation. Distributable under GPL. ====================================================================== This still stands with 1.0.12. So it appears to meet the requirements for Binary Firmware in the Guidelines. (It is also distributed with a number of other distros including Mandriva and OpenSUSE) 2. spot and Thorsten did some work with "file" to see if it met the requirement for "no executables". The most interesting one was: ./lib/firmware/mixart/miXart8.elf: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped Now this does appear to really be an ELF binary, but it is not +x and it doesn't appear to run on Linux: $ chmod +x miXart8.elf $ ./miXart8.elf bash: ./miXart8.elf: cannot execute binary file so I think we can say that is truly is firmware, and it just happens that this device uses a piece of firmware in ELF format. a "file $(find . -type f) | grep -v -e ASCII -e Bourne -e shell" also throws up some other bits that aren't "data" like: ./lib/firmware/digiface_firmware.bin: DOS executable (device driver) ./lib/firmware/digiface_firmware_rev11.bin: DOS executable (device driver) ./lib/firmware/ea/3g_asic.fw: PGP encrypted data but these appear to just be "file" noise. They appear to be genuine firmware, that's not executed on the host, so they should be fine. (and 3g_asic is not PGP data; that's just what happens when you chuck lots of random stuff at "file"). Last CVS from fedora.us days, which is largely unchanged here: http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/alsa-firmware/FC-5/alsa-firmware.spec?root=extras&rev=1.5 Package is listed on: http://www.fedoraproject.org/wiki/Extras/PackagesNoLongerInDevel?highlight=%28alsa-firmware%28 as "pending legal review" but there appears to be nothing happening and nobody tasked to do anything AFAICT. Given the above details, in the absence of a compelling reason, I don't see why this shouldn't be included in Fedora. I'm looking to spot here to make a call or, if some kind of legal review really is needed, make this block FE-LEGAL and get someone's attention about it. Note that I only have one piece of hardware that this firmware supports (Echo Audio Indigo DJ) so any feedback from anyone else welcome. I have marked the package as "noarch"; since it's containing firmware it should be. However, given that the firmware is "compiled" from big strings and there's some fiddly stuff going on, I would appreciate some md5sums of the generated firmware from someone with ppc/x86_64 architectures just to make sure that the end result is the same.
adding cc's from bug #186858 which this bug obsoletes
NB that alsa-tools-firmware (needed to push the firmware for some of the things in this package) is a subpackage of alsa-tools; see bug #217256
Incidentally, given that few people will need more than one set of firmware installed, there is a valid argument for splitting the firmware into subpackages (e.g. alsa-firmware-echoaudio). Any arguments pro- or con- are welcome.
Created attachment 142239 [details] Another spec variant The spec variant I use on my box, in case it helps
Thanks Nicolas. Your spec seems substantially the same at a glance; are there any specific bits you think need importing into mine? Also would you consider reviewing this package so we can have it in FE?
I fear I won't have this kind of free time before next year at least, that's why I dumped my spec on you
I built the alsa-tools package so it would generate the alsa-tools-firmware subpackage aswell as this package on an x86_64 FC6 system. I have a RME hammerfall DSP and with both packages installed the firmware is now loaded successfully when the udev magic happens early in the boot process. It is a little bit of a pity that at least for the RME cards that require firmware 3 separate packages are required to use the card rather than just one alsa-rme-tools package(or whatever) but I'm happy with a working solution, thank you :)
Hmm, what's the status of this review? It's been sitting for ages without any progress. If all of the legal issues are clear now, it should be easy to review because there's not much to it.
From my POV it's just waiting for a review.
OK, I know I'm really not the best person to review this because I haven't a single piece of hardware that needs this, but nobody more qualified has stepped up in over eight months and it's pointless to let this sit aroud when it would be useful to people. Perhaps you could answer one question which comes immediately to mind: Why are some of the firmware files under /lib/firmware and some under /usr/share/alsa/firmware?
Ping?
It's a good question and I was looking into it. I'm pretty sure I tried moving them all to /lib/firmware and it didn't work, so it seemed to be something that's compiled in to ALSA.
I finally have some free time now, so.... This builds fine; rpmlint says: W: alsa-firmware strange-permission alsa-firmware.spec 0660 Kind of weird and quite insecure on many systems. Should be 644. I don't know if this matters at all once things are in CVS. W: alsa-firmware mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line 1) I don't see this as a problem; fix it if you like. W: alsa-firmware incoherent-version-in-changelog 0:1.0.12-1 1.0.12-1.fc8 rpmlint doesn't like seeing the epoch there, but I think this is an rpmlint issue. E: alsa-firmware arch-independent-package-contains-binary-or-object /usr/share/alsa/firmware/mixartloader/miXart8.elf E: alsa-firmware arch-independent-package-contains-binary-or-object /lib/firmware/mixart/miXart8.elf You explained these initially. So no big rpmlint problems. This does not install, due to an unsatisfied dependency on alsa-tools-firmware >= 1.0.12. I guess this is a subpackage of alsa-tools which is currently disabled. You own alsa-tools so it should be pretty easy to get it turned on. I have no hope of testing this anyway so not being able to install it isn't much of an impediment to a review. The license does concern me (GPL but there's no real source, just C files containing data) but if spot has already acked it then I suppose it's OK. I'll ping him on it before I approve anything. The specfile does not consistently use macros. If you want to use %{__make} and %{__rm}, you need to use them everywhere and also use %{__mv} and %{__cp}. The current version seems to be 1.0.14, which came out in June. Any reason not to package it? Because of the missing dependency, I can't determine whether /usr/share/alsa is properly owned. It's provided by alsa-utils, but I can't tell if it's in the dependency chain since alsa-tools-firmware doesn't exist. * source files match upstream: 6e7d3104c4de7d031790c1e750067b13e9481bf2855b0806a300d1e697549fbd alsa-firmware-1.0.12.tar.bz2 * package meets naming and versioning guidelines. * specfile is properly named X specfile does not use macros consistently. * summary is OK. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. X latest version is not being packaged. * BuildRequires are proper. * compiler flags are appropriate (not that it matters for a noarch package). * %clean is present. * package builds in mock (development, x86_64). X package fails to install properly due to a missing dependency. * rpmlint has acceptable complaints. * final provides and requires are sane: alsa-firmware = 1.0.12-1.fc8 = alsa-tools-firmware >= 1.0.12 udev * %check is not present; no test suite upstream. I have no hope of testing this pacakge. * no shared libraries are added to the regular linker search paths. ? owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no scriptlets present. * This is acceptable content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package.
I'd pay good money if someone would figure out why on earth the component keeps changing....
(In reply to comment #13) Thanks for the review, Jason. > W: alsa-firmware strange-permission alsa-firmware.spec 0660 > Kind of weird and quite insecure on many systems. Should be 644. I don't > know if this matters at all once things are in CVS. I'm sure it doesn't. > W: alsa-firmware mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line 1) > I don't see this as a problem; fix it if you like. Sorted. (but see below) > W: alsa-firmware incoherent-version-in-changelog 0:1.0.12-1 1.0.12-1.fc8 > rpmlint doesn't like seeing the epoch there, but I think this is an rpmlint > issue. Looks like it. > This does not install, due to an unsatisfied dependency on alsa-tools-firmware > >= 1.0.12. I guess this is a subpackage of alsa-tools which is currently > disabled. You own alsa-tools so it should be pretty easy to get it turned on. Yes. It's disabled as a subpackage of alsa-tools for the exact reason that having the -firmware package without alsa-firmware makes no sense. As soon as we're reasonably happy with this package, I'll enable alsa-tools-firmware. > The specfile does not consistently use macros. If you want to use %{__make} and > %{__rm}, you need to use them everywhere and also use %{__mv} and %{__cp}. Sorted. > The current version seems to be 1.0.14, which came out in June. Any reason > not to package it? Nope, updated. Will post updated packages when I get a chance to build and test them. It seems that just dropping in 1.0.14 to the current spec leads to all kinds of craziness.
Aha. May have solved one of the mysteries raised earlier in comment #10. From README: "The recent ALSA driver supports the hotplug firmware loader. As default, the package will install firmware data to the places for both the old ALSA fw loader and the hotplug fw loader. To disable the installation of old ALSA fw loader data (if both ALSA and hotplug fw loaders are available), pass --disable-loader to configure." This disables the generation of the /usr/share/alsa/firmware/* files. Will test without these in place; I imagine it's going to work just fine.
Well, the firmware for the Echo Indigo DJ card (the only hardware I have that needs firmware) works fine with the firmware just in /lib/firmware, so great. Updated package here: Spec URL: http://www.timj.co.uk/linux/specs/alsa-firmware.spec SRPM URL: http://www.timj.co.uk/linux/srpms/alsa-firmware-1.0.14-1.src.rpm rpmlint is clean on all packages, and it builds in mock. Additionally, the alsa-tools-firmware dependency has been built in FC-6. (In the needsign queue as I write)
Actually rpmlint isn't quite completely clean: W: alsa-firmware invalid-license GPL E: alsa-firmware arch-independent-package-contains-binary-or-object /lib/firmware/mixart/miXart8.elf The latter is OK, but the former is not. I see a GPL copying file and some LGPL headers in some of the code (echoaudio/DSP/Echo3gDSP.c, for example), plus weird things like "aica/license.txt". Honestly I don't think it's the package reviewer's job to do complete license review and I'm certainly not a lawyer so I can't really do so in any case. The other issues I had are fixed now, so I'll just leave it to you to make a determination as to what the new-style License: tag should be (ping spot or block FE-Legal if you need to) and then go ahead and check in. APPROVED
Thanks very much for the review Jason. I will check out the licensing again before importing and make sure that it all ties up with the new License tag etc.
Detailed license breakdown and questions submitted to spot, awaiting response. In any case the package could do with a PACKAGE-LICENSING file adding.
Any progress over the past three months?
Unfortunately no. For the record, summarising some offline discussions with spot: a) some parts of the the package which are GPL'd (hdsploader, mixartloader, pcxhrloader, us2xyloader,vxloader) don't specify a license version for the GPL, containing only "Distributable under GPL". -> see https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3411 (no response from upstream) b) the "aica" firmware (aica/license.txt) is under a "KOS" license which spot says is the same as BSD, so that's OK. c) One of the firmwares (emi_26_62/license.txt) is clearly not OK for Fedora: "This firmware is for the Emagic EMI 2|6 Audio Interface The firmware contained herein is Copyright (c) 1999-2002 Emagic as an unpublished work. This notice does not imply unrestricted or public access to this firmware which is a trade secret of Emagic, and which may not be reproduced, used, sold or transferred to any third party without Emagic's written consent. All Rights Reserved. This firmware may not be modified and may only be used with the Emagic EMI 2|6 Audio Interface. Distribution and/or Modification of any driver which includes this firmware, in whole or in part, requires the inclusion of this statement." -> see http://mailman.alsa-project.org/pipermail/alsa-devel/2008-January/005020.html
With some clarifications made in recent releases, I think if we exclude the emi_26_62 firmware we will probably be OK. See also http://mailman.alsa-project.org/pipermail/alsa-devel/2008-January/005702.html As soon as I get a mo I will do a fresh package which should be OK.
*** Bug 186858 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > With some clarifications made in recent releases, I think if we exclude the > emi_26_62 firmware we will probably be OK. See also > http://mailman.alsa-project.org/pipermail/alsa-devel/2008-January/005702.html I think so too, but I'm waiting to see a new package to do the final sign-off.
OK, in what must rate as one of the most unrewarding bits of work on packaging ever, I have been through the package licensing in exhaustive detail at a source level (the licenses even vary between firmware from the same manufacturer for minor hardware revisions!) and offer the following rather clumsy but unambiguous revision: Spec URL: http://timj.fedorapeople.org/SPECS/alsa-firmware.spec SRPM URL: http://timj.fedorapeople.org/SRPMS/alsa-firmware-1.0.16-1.src.rpm
Well, I'm less than thrilled about the korg, asihpi, and yamaha firmwares not having explicit licensing, but I won't hold this package on them. Please file upstream bugs to get this corrected. Lifting FE-Legal. Tim, thank you for your hard work and due diligence.
I'm not sure why this ticket isn't assigned to me since I did the review. There shouldn't be any need to reassign a review ticket unless the reviewer changes for some reason.
I would like to file upstream bugs, but their bugtracker is currently broken. Bugs #3410-3413 upstream cover some of the licensing issues. I will import the package now; thanks to all for the input.
Package Change Request ====================== Package Name: alsa-firmware New Branches: F-8 Updated Fedora Owners: timj This is resurrection of a long-dead package
I see in pkgdb that this package is owned by Andreas Bierfert (awjb)... was it ever orphaned? Or did Andreas intend to?
It was dead.package'd back in the days of FC-5; I think it's pretty safe to assume that ownership should have been dropped then, but I guess if Andreas really wants back on this package then I'm sure he need only make the request.
As per comment #30, this is a resurrection of a long-dead package. As Jason rightly says, it's been dead.packaged for ages, so my request is to take ownership. Andreas would be welcome to have ownership although ISTR (perhaps incorrectly) that I tried to contact him ages ago and got no response or negative. I will forward this bug to him.
ok, makes sense. I guess if Andreas wants to maintain or co-maintain he will speak up. ;) cvs done.
Package Change Request ====================== Package Name: alsa-firmware Please remove the CVS tag alsa-firmware-1_0_16-1_fc9 which was made without the Makefile present (due to the package having previously been dead.package'd)
Built in F-8 and devel; F-9 awaiting tag removal as above
See: http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#head-6dcb75a935ccc855c229cc48746668431196f44b
# yum update alsa-firmware Loaded plugins: refresh-packagekit Excluding Packages in global exclude list Finished Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package alsa-firmware.noarch 0:1.0.16-1.fc10 set to be updated --> Processing Dependency: alsa-tools-firmware >= 1.0.16 for package: alsa-firmware --> Finished Dependency Resolution alsa-firmware-1.0.16-1.fc10.noarch from koji-f10-builds has depsolving problems --> Missing Dependency: alsa-tools-firmware >= 1.0.16 is needed by package alsa-firmware-1.0.16-1.fc10.noarch (koji-f10-builds) Error: Missing Dependency: alsa-tools-firmware >= 1.0.16 is needed by package alsa-firmware-1.0.16-1.fc10.noarch (koji-f10-builds)
Argh. I had that problem from the other end a while ago and had to take the alsa-tools-firmware subpackage out. I will rebuild alsa-tools with the -firmware subpackage for all branches now. Thanks Nicolas.
* Sun May 18 2008 Tim Jackson <rpm.uk> - 1.0.16-2 - Enable firmware subpackage - the accompanying alsa-firmware package is finally in Fedora Not really :(
(In reply to comment #40) > * Sun May 18 2008 Tim Jackson <rpm.uk> - 1.0.16-2 > - Enable firmware subpackage - the accompanying alsa-firmware package is > finally in Fedora > Not really :( I think you're pointing out the alsa-tools-firmware packages not built, still. Thank you. I don't know what has screwed up this time, but I am hoping it is the final obstacle on the road to getting this damn package in the repo. I will fix it.
Builds of alsa-tools which include the -firmware package for F-8 and F-9 are in the updates-testing queue, and it is built on devel.
Sorry to intrude - it looks like the problem has been resolved and a patch/fix will be available soon; but I'd like to check whether the problem I'm having is directly related to this defect - it seems almost certain it is. Initialization of my Echo mia midi card is failing: $ dmesg|grep -i echoaudio ALSA sound/pci/echoaudio/echoaudio.c:2001: Echoaudio driver starting... ALSA sound/pci/echoaudio/echoaudio.c:1918: chip=f7bce000 ALSA sound/pci/echoaudio/echoaudio.c:1948: pci=f78d2000 irq=17 subdev=0081 Init hardware... ALSA sound/pci/echoaudio/mia_dsp.c:44: init_hw() - Mia ALSA sound/pci/echoaudio/echoaudio.c:44: firmware requested: mia_dsp.fw ALSA sound/pci/echoaudio/echoaudio.c:47: get_firmware(): Firmware not available (-2) ALSA sound/pci/echoaudio/echoaudio.c:1964: init_hw err=-2 ALSA sound/pci/echoaudio/echoaudio.c:1854: Stop DSP... ALSA sound/pci/echoaudio/echoaudio_dsp.c:882: rest_in_peace() open=0 ALSA sound/pci/echoaudio/echoaudio_dsp.c:846: stop_transport 0 ALSA sound/pci/echoaudio/echoaudio_dsp.c:865: stop_transport: No pipes to stop! ALSA sound/pci/echoaudio/midi.c:39: enable_midi_input(0) ALSA sound/pci/echoaudio/echoaudio.c:1859: Stopped. ALSA sound/pci/echoaudio/echoaudio.c:1870: MMIO freed. ALSA sound/pci/echoaudio/echoaudio.c:1876: Chip freed. Echoaudio Mia: probe of 0000:00:0c.0 failed with error -2 This is on Fedora 9. The alsa firmware package(s) are not included in F9 at this point, right? - Thus the error. Two questions: Is the fix (such as 'yum'able alsa*firmware packages) likely to be available soon? Is there a fairly straightfoward work-around, such as installing the missing alsa-firmware packages by hand? Thanks!
(In reply to comment #43) Jim: yes, your problem should be solved by installing the firmware which, conveniently enough, is now packaged as per this bug :-) The package is built and ready for testing. The best thing for now is to install the RPM directly from https://admin.fedoraproject.org/updates/F9/pending/alsa-firmware-1.0.16-1.fc9 . You can also provide feedback via the above URL. There are a limited number of people with hardware which requires firmware, so please do - your testing is very valuable. It will also help to give us the confidence to push it into the "real" Fedora 9 repository where everyone will then be able to install it via yum. Thanks!
(In reply to comment #41) > I think you're pointing out the alsa-tools-firmware packages not built, still. > Thank you. Yes, sorry I was a bit terse, I was working on my own packaging brownpaper bag mistakes at the time Everything is ok now
(In reply to comment #44) Jim, although it's not actually technically required for your hardware, to avoid broken dependencies you will also need the alsa-tools and alsa-tools-firmware packages from: https://admin.fedoraproject.org/updates/F9/pending/alsa-tools-1.0.16-4.fc9 alsa-tools also has the "echomixer" tool which will be useful for your hardware.
Tim - Thanks for the fast response. I installed the alsa* rpms and rebooted and the card was recognized! The only problem I had was that alsa-firmware and alsa-tools-firmware depended on each other: alsa-firmware is needed by alsa-tools-firmware-1.0.16-4.fc9.i386 alsa-tools-firmware >= 1.0.16 is needed by alsa-firmware-1.0.16-1.fc9.noarch This was easily solved by picking one and installing with --nodeps options. Below is the relevant output of aplay and aplaymidi showing that the device is recognized. As a further test, I hooked a MIDI keyboard up to the sound card, started up jackd and rosegarden and succeeded in recording the MIDI keyboard output in rosegarden; and I was also able to play compositions (including what was recorded) in rosegarden with the MIDI keyboard as the output device. I've not tested the audio ports yet because I don't yet have the right connectors - for the Mia's audio ports - to hook up my speakers. $ aplaymidi -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 Mia Mia $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Mia [Mia], device 0: PCM [Mia] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 1: V8237 [VIA 8237], device 0: VIA 8237 [VIA 8237] <snip> Here's some info about my system. Let me know if you need to know anything else. $ uname -a Linux titan.milkyway.org 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13 05:38:53 EDT 2008 i686 athlon i386 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 7 model name : AMD Athlon(tm) 64 Processor 3500+ stepping : 10 cpu MHz : 1000.000 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up ts fid vid ttp bogomips : 2001.67 clflush size : 64 Thanks to you and your team for all the work you've put into this.
Addendum: I've hooked up speakers to the sound card and have verified that the audio, as well as MIDI, is working on my Echo Mia MIDI card with alsa-firmware installed. Thanks!
Is there any reason this ticket is still open? I don't see that CVS was ever done, but the package seems to be in the distro.
(In reply to comment #49) > Is there any reason this ticket is still open? I don't see that CVS was ever > done, but the package seems to be in the distro. No, closed. CVS didn't need to be done because there was already a module in CVS from legacy Fedora Extras.