Note that the subpackage alsa-tools-firmware is disabled by default; this is
pending the alsa-firmware package which I am going to submit separately.

Firmware is over in bug #217259

I had a look at this package.
Though rpmlint is silent i found 
/usr/share/doc/alsa-tools-1.0.12
directory is orphaned

Thanks, that was subtle: I hadn't spotted that. Fixed in an updated spec file (I
haven't bothered to re-upload the whole SRPM for that one-liner).

Mock build for i386 devel failed =>

checking for ENVY24CONTROL... configure: error: Package requirements (gtk+-2.0
alsa >= 0.9.0) were not met:

No package 'gtk+-2.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables ENVY24CONTROL_CFLAGS
and ENVY24CONTROL_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

error: Bad exit status from /var/tmp/rpm-tmp.87484 (%build)


I think you should bother now to again update release and submit new download
links for this modified package.
You need to add gtk2-devel as Build Requires

Thanks, fixed, sorry, I forgot to run it through mock. Builds now fine in mock.

Spec URL: http://www.timj.co.uk/linux/specs/alsa-tools.spec
SRPM URL: http://www.timj.co.uk/linux/srpms/alsa-tools-1.0.12-3.src.rpm

I have this special thing in my /etc/rc.local that loads instruments to the 
OPL3 if one is found during startup:

#!/bin/sh
# Load MIDI instruments to the OPL3, if there is one.
# Use "aplaymidi -l", "aplaymidi -p nn:nn foo.mid" to test it.
midiport=`/usr/bin/aplaymidi -l | grep OPL3 | awk '{print $1}'`
if [ "x$midiport" != "x" ]; then
    /usr/bin/sbiload -p${midiport} --opl3 /usr/share/sounds/opl3/std.o3
/usr/share/sounds/opl3/drums.o3
    echo "Loaded OPL3 Instruments"
fi

I wonder if one should actually put something like that into init.d and
link it in from the rc.d:s. It would add a Requires:alsa-utils though.

I think alsa-tools-1.0.13 is already released. How about updating package to
that tarball?

Anyway you can also do that while importing/updating this package in CVS.
Review:
+ package builds in mock (development i386).
+ rpmlint is silent for SRPM and RPMS.
+ source file's md5sum is
7342056614623273abccb1cd38a674d8  alsa-tools-1.0.12-pruned.tar.bz2
+ package meets naming and packaging guidelines.
+ specfile is properly named, is cleanly written
+ Spec file is written in American English.
+ Spec file is legible.
+ dist tag is present.
+ build root is correct.
+ license is open source-compatible.  License text included in package.
+ %doc is small; no -doc subpackage required.
+ %doc does not affect runtime.
+ BuildRequires are proper.
+ %clean is present.
+ package installed properly.
+ Macro use appears rather consistent.
+ Package contains code, not content.
+ no headers or static libraries.
+ no .pc file present.
+ no -devel subpackage exists
+ firmware subpackage though written in spec file its disabled.
+ no .la files.
+ no translations are available
+ Does owns the directories it creates.
+ no duplicates in %files.
+ file permissions are appropriate.
+ Desktop files installed without desktop-files-install as its really not needed.
APPROVED.

Many thanks for the review Parag. I left the version at 1.0.12 to match the
version of alsa-libs currently included with FC6.

Linus, I'm not 100% sure whether including your script is appropriate or not. In
one way, I think it should be in a separate package (e.g. alsa-opl3 or
something) but that seems complete overkill for a 4 line script. On the other
hand it is kind of appropriate to put it here given that alsa-tools includes the
sbiload binary.

If we did include it I'm not sure what I would call the init script.
"alsa-tools" seems wrong. "alsa-tools-opl3" is OK, but a bit of chkconfig clutter.

Parag, do you have any comments?

Tim, don't care about that script right now. Import and build instead,
I'll make a patch in some separate bug instead if I find the time.

Good work!

Linus,
 I think its better to have another package that contains your script.  you can
start packaging that script and create alsa-tools-opl3 review request. I will be
happy to review that also :)

I imported and tried to build on devel but it failed with an odd error on ppc:

http://buildsys.fedoraproject.org/logs/fedora-development-extras/22627-alsa-tools-1.0.12-3.fc7/ppc/build.log

(for some reason it didn't appear to even try to build on other archs, which is
weird).

Will have to look at this in more detail.

Hmm, it's not building on FC6 either, on PPC. See job 22645
Anyone have a PPC machine that they can play around on?

You can ask on FE-list about your build problem.
Also you will get good information at #fedora-extras 

OK, since nobody seems interested in ppc, I've ExcludeArch'd it for now.  The
corresponding bug is over in bug #219010. alsa-tools is now built successfully
in devel for x86 and i386 (job #23253). FC-6 is running now.

Thanks for the input everyone.

Package Change Request
======================
Package Name: alsa-tools

Please remove the tag "alsa-tools-1_0_16-2_fc9" on the *devel* branch
This was a bad tag created due to the F9/F10-devel rollover (this is waaay too
easy to do)

we don't remove cvs tags... please just bump your release and retag...