Good:

- rpmlint checks return:
W: obexftp-python no-documentation
W: obexftp-perl no-documentation
W: obexftp-devel no-documentation

All safe to ignore.

- package meets naming guidelines
- package meets packaging guidelines
- license (GPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file
- devel package ok
- no .la files
- post/postun ldconfig ok
- devel requires base package n-v-r 

Looks good, APPROVED.

%defattr missing in -perl package

Requires: perl(:MODULE_COMPAT_...) missing as well.

Subpackages should probably be called python-obexftp and perl-obexftp instead of
obexftp-* according to package naming guidelines.

_obexftp.so.X and _obexftp.so.X.X for a Python extension are probably just
cruft, and could be replaced with a plain _obexftp.so.

%configure --disable-dependency-tracking would result in cleaner build output
and possibly speed up the build.

The minimum openobex version this works with is 1.2, making the build dep on
openobex-devel versioned (>= 1.2) would save some trouble from people using
older distros.

Requires: openobex-devel >= 1.2 missing from -devel, see #includes in installed
header files.

(In reply to comment #3)
> Requires: perl(:MODULE_COMPAT_...) missing as well.

Any... pointers to some docs on that? I've searched through packaging guidelines
and there's nothing about that. I only found some old IRC logs mentioning this,
but nothing tangible.

> Subpackages should probably be called python-obexftp and perl-obexftp instead
> of obexftp-* according to package naming guidelines.

Perl naming guidelines say that only about CPAN-originated modules. Plus we have
lots of other packages named something-perl, for example openbabel (also mine).

> _obexftp.so.X and _obexftp.so.X.X for a Python extension are probably just
> cruft, and could be replaced with a plain _obexftp.so.

I don't know much about python. Are you sure I can do that?

> %configure --disable-dependency-tracking would result in cleaner build output
> and possibly speed up the build.

OK.

> The minimum openobex version this works with is 1.2, making the build dep on
> openobex-devel versioned (>= 1.2) would save some trouble from people using
> older distros.
> 
> Requires: openobex-devel >= 1.2 missing from -devel, see #includes in
> installed header files.

OK.

(In reply to comment #4)
> (In reply to comment #3)
> > Requires: perl(:MODULE_COMPAT_...) missing as well.
> 
> Any... pointers to some docs on that?

Not that I'm aware of.  Just copy/paste the line from
/etc/rpmdevtools/spectemplate-perl.spec

> > Subpackages should probably be called python-obexftp and perl-obexftp 
> > instead of obexftp-* according to package naming guidelines.
> 
> Perl naming guidelines say that only about CPAN-originated modules.

None of the other cases talk anything about where the software originates from,
and I don't see why it would make a difference, nor why the general rule
wouldn't apply, see Addon packages (general) in naming guidelines.

> > _obexftp.so.X and _obexftp.so.X.X for a Python extension are probably just
> > cruft, and could be replaced with a plain _obexftp.so.
> 
> I don't know much about python. Are you sure I can do that?

Pretty sure.  Will need to verify this though.

To clarify, I don't consider foo-obexftp vs obexftp-foo for foo={perl,python} a
blocker as there are some interpretation differences about the naming guidelines
and quite a few packages going either way in the repo.  This is something that
the packaging committee should work on, and can be fixed later if need be.

Regarding _obexftp.so.*.*, a simple "python -c 'import obexftp'" will work with
only the *.so present, it doesn't need the *.so.*.  And 'find /usr/lib/python2.4
-name "*.so.*"' finds nothing here.  So I *guess* it's safe to install the
extension just as *.so and drop the links.  This is neither a blocker though,
but is something upstream could perhaps clarify.

OK, included all suggestions except _obexftp.so.*.* renaming in python
subpackage. I'll import the package sometime tonight. Thanks for comments, everyone.

imported 0.20-2 with the following changelog:
- added missing defattr
- require openobex-devel > 1.2
- added missing MODULE_COMPAT Requires: to perl subpackage
- renamed subpackages to perl/python-obexftp
- fixed rpaths

Thanks to Toshio for some help with rpaths.

Built for devel, FC-6 branch requested. Thanks for the review, Tom.

Just in case it wasn't intentional: the package doesn't have a disttag so some
manual release tag adjustments will be needed so that the FC-6 and devel builds
don't end up with identical NEVR's.

I noticed that while trying to build for FC-6 and fixed it.