Before someone start reviewing here is a new version which fixes the following:
-missing Requires:  raidem >= 0.3.1
-missing Buildarch: noarch

The new specfile is available at:
Spec URL: http://home.zonnet.nl/jwrdegoede/raidem-music.spec

MUST
====

* Package named appropriately
* License (CC) ok
* Spec file legible and in Am. English
* No BR: needed
* No locales
* No shared libraries
* Not relocatable
* Owns the directory that it creates
* $RPM_BUILD_ROOT cleaned where it should be
* File permissions ok
* No duplicate %files
* Contains no code, but acceptible content (game data)
* No -devel package needed
* No .desktop file needed

SUGGEST
=======
* Slightly modified %description:
  "Music created by Eric Hamilton (dilvie) for the game Raid'em"

The files play fine with xmms.  I was unable to test them with the CVS
version of raidem due to problems with the raidem package itself:
"Error loading base datafiles."

I'll take your word that raidem will load/play these files correctly.

APPROVED

(In reply to comment #2)
> The files play fine with xmms.  I was unable to test them with the CVS
> version of raidem due to problems with the raidem package itself:
> "Error loading base datafiles."
> 

Hmm, thats strange are you sure you've the latest CVS? I did have the same
problem 2 days ago, but that should be fixed now?

Could you do  a rpm -ql raidem and a strace and attach both? It seems that the
latest raidem build for devel wasn't pushed to the mirrors yet so I can't test
that and my local build works fine.

(In reply to comment #2)
> MUST
> ====
> 
[...]
> * Contains no code, but acceptible content (game data)

I'm starting to rethink this one.  These ogg files are not required to play the
game, and aren't part of the upstream source.  The guidelines state:

# Game levels are not considered content, since games without levels would be
non functional.
# Sound or graphics included with the source tarball that the program or theme
uses (or the documentation uses) are acceptable.
and specifically says that ogg/mp3 files are not acceptable.

Let me get the opinion of f-e-l on this one.

Erm,

I think you're reading this to literal, the .ogg files in this package are
linked to from the download page of upstream:
http://home.exetel.com.au/tjaden/raidem/download.html
They are not some randomly picked ogg files, they are _the_ background music for
raidem. Don't tell me that I have to ask upstream to make a special tarball for
me with these included because the guidelines say so?

About the explicit saying that mp3 and ogg files are not acceptable, I believe
this is to discourage people from packaging stand alone collections of music and
is not a hard forbidden item, otherwise monkey-bubble and gcompris would have to
have all their ogg's removed leaving them severely crippled.

But if you're not sure feel free to post this to f-e-l. I'm just trying to
change your mind before we get a flamefest there :)

p.s.

I already started the import and that darn import script seems to have decided
to drop all the ogg's in CVS instead of in the lookaside cache, ouch!

(In reply to comment #5)

> But if you're not sure feel free to post this to f-e-l. I'm just trying to
> change your mind before we get a flamefest there :)

I agree that it should be acceptable, but I don't think the guidelines are
crystal clear in this case.  The guidelines also state "If you are unsure if
something is considered approved content, ask on fedora-extras-list."  I'd
rather get f-e-l's opinion and have this flamefest now instead of later when
someone discovers a package full of ogg files.  :)

Created attachment 128423 [details]
rpm -ivh output

Note the error during the installation.  I'm not sure why that is happening.

Created attachment 128424 [details]
rpm -ql raidem output

Note that even though it says /usr/share/raidem/... is part of the package,
this directory doesn't actually get created.  Other packages have no problem
creating things in /usr/share.

Created attachment 128425 [details]
strace output from raidem

It's clear from the strace output that it's dying due to the missing
/usr/share/raidem files.

Hmm, disk full / filesys corrupt? Did you check dmesg output? Have you tried
setenforce 0?

Found the problem:  there's a bad line in the %build section:

%define _datadir /use/share

This should be '/usr/share', not '/use/share'.  It would be better to remove
those two %define lines and just set datadir on the configure line:

%configure --datadir=%{_datadir}/%{name}

With that fix raidem installs fine and I was able to verify that the game loads
and plays the music with no problems.

You're right, thanks! And thanks for the better way todo this too, I didn't
think off passing --datadir twice (%configure already apsses it with another value).

Fixing this in Rawhide right away luckiliy it seems that 0.3.1-1 didn't get
pushed yet.

(In reply to comment #7)
> (In reply to comment #5)
> 
> > But if you're not sure feel free to post this to f-e-l. I'm just trying to
> > change your mind before we get a flamefest there :)
> 
> I agree that it should be acceptable, but I don't think the guidelines are
> crystal clear in this case.  The guidelines also state "If you are unsure if
> something is considered approved content, ask on fedora-extras-list."  I'd
> rather get f-e-l's opinion and have this flamefest now instead of later when
> someone discovers a package full of ogg files.  :)

This is going to be brought up at the next FESCO meeting and updated in the
packaging guidelines.  Based on the feedback from f-e-l so far, it shouldn't be
a problem.

FESCo approved a packaging guideline change to clarify this issue.

APPROVED (again :) )

package is in extras. Please remember to close package review once its been
imported into cvs etc etc

Oops sorry, I normally always close them I missed this one I also didn't see it
on the Need cleanup part of the weekly automatic Fedora Status thingie, I guess
I read over it.