The URL to the spec file is missing.

And intentionally so.

Dealing with lots of packages and having multiple versions of specfiles of some
floating around is a scenario I'm guaranteed to screw up every now and then. 
And because the specfile is only a part of a submission and the whole SRPM
contents need to be reviewed anyway, I prefer to not upload specfiles separately
-- doing so and uploading just the SRPM is IMO more efficient use of everyone's
time.

If this is a blocker for your review of this package, let me know and I'll
upload the spec somewhere.  Note however that the parent vdr package (bug
190343) needs to be reviewed first.

I do not know about other reviewers but I like to take a look into the spec file
before I decide whether or not to spend more time with a review request. When
the URL is provided it only takes the browser to look into it which is a lot
less work than to download the srpm, extract it and look into the spec file.
Besides I am yet very unexperienced and this way I can easily decide whether or
not the spec file is too complicated for me now.  As well the first impression
of the spec file helps me to anticipate how much work the review will be and how
long a mock test build will take. For this reasons maybe you get someone to
review your package faster if you provide a separate spec file but it won't be a
blocker for me. If I find some time I will look into your srpm and review it as
soon as I am in fedorabugs and I feel capable of it.

(In reply to comment #3)
> I do not know about other reviewers but I like to take a look into the spec file
> before I decide whether or not to spend more time with a review request.
I agree with Till.

 In addition to that, during reviews, reviewing the spec often is sufficient to
provide comments on/monitor progress of a package. In such cases, the spec file
avoids unnecessarily wasting bandwidth on d/l's of srpms.

(In this particular case, the srpm is small, so providing the spec would not
make much difference to d/l'ing the srpm. In case of XX MB packages, it does.)

I agree with the above comments that having a easy link to the .spec file 
is a good thing and helps reviewers. 

That said, here's a review of this package: 

OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
OK - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License (GPL)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
52c219e38a089504071237209ad114cd  vdr-osdteletext-0.5.1.tgz
52c219e38a089504071237209ad114cd  vdr-osdteletext-0.5.1.tgz.1
OK - BuildRequires correct
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.

OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
See below - No rpmlint output.
OK - final provides and requires are sane:

SHOULD Items:

OK - Should build in mock.
x86_64/i386 - Should build on all supported archs
OK - Should have dist tag
OK - Should package latest version

Issues:

1.  rpmlint says:

E: vdr-osdteletext non-standard-uid /var/cache/vdr/osdteletext vdr
W: vdr-osdteletext dangerous-command-in-%preun rm

Can both be ignored. Would be nice to get rid of the rm, but it
looks to be the same perl-Template issue that vdr had, so there isn't
a way around it. ;(

I don't see any blockers, so this package is APPROVED.

Don't forget to close this bug NEXTRELEASE once it's been imported
and built.

Built for devel, owners list and comps updated, FC-5 and FC-6 branches
requested.  Thanks!