Just took a quick look but I can't fetch the upstream source.  It looks like
they don't distribute 3.15 any longer.

Now, if I understand things, this is just building some extra files that aren't
included in the Core PyQt package.  (They couldn't be; qscintilla is in Extras.)
 So the version of PyQt used here has to be exactly the same as the version that
Core used for their packages.  If so then we'll have to make an exception for
the need for upstream sources.

Just for grins I tried to build in rawhide; the build fails in configure.py.  It
builds fine on FC5 x86_64 (in mock).

We can/will just use the same source redhat/fedora(core) does when building
PyQt-qscintilla. 

Re: rawhide breakage
That's ok, rawhide was upgraded to PyQt-3.16 recently anyway.  

Whoever wants to review this can do so against the FC-5 package here, or I can
make a rawhide one for PyQt-3.16 too.  (I'll have to do that eventually anyway).

I'l go ahead and review the FC5 version.  I can't compare against the upstream
source since it doesn't exist any longer, but I can compare against what's in
Red Hat's lookaside store from the FC5 PyQt package which seems good enough.

This package places various files in /usr/share/sip/qtext, which seems odd as
that name looks to be unrelated to the package.  Plus, nothing seems to own
/usr/share/sip.  I guess those files are the SIP-generated bindings, but the
directory ownership is still an issue.

The -debuginfo package is empty.  It looks like the makefile strips the library,
which it shouldn't be doing:

make: Entering directory `/builddir/build/BUILD/PyQt-x11-gpl-3.15/qtext'
cp -f qtext.so
/var/tmp/PyQt-qscintilla-3.15-1.fc5-root-mockbuild/usr/lib64/python2.4/site-packages/q
text.so
strip
/var/tmp/PyQt-qscintilla-3.15-1.fc5-root-mockbuild/usr/lib64/python2.4/site-packages/qtext.so

The Makefile is generated, and I don't really know enough about what's generated
to know how to convince it not to strip the library. 

Review:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text included in package.
* source files match upstream (or at least Core's cache):
   8e70fac4f403fb759b537008170ff446  PyQt-x11-gpl-3.15.tar.gz
   8e70fac4f403fb759b537008170ff446  PyQt-x11-gpl-3.15.tar.gz-srpm
O 3.15 is not the latest version, but it must match what's in each particular FC
release.
* BuildRequires are proper.
* package builds in mock (FC5, x86_64).
* rpmlint is silent.
* final provides and requires are sane:
   qtext.so()(64bit)
   PyQt-qscintilla = 3.15-1.fc5
  =
   PyQt = 3.15
   libX11.so.6()(64bit)
   libXext.so.6()(64bit)
   libqscintilla.so.6()(64bit)
   libqt-mt.so.3()(64bit)
   python(abi) = 2.4
   python-abi = 2.4
* shared libraries are present, internal to Python.
* package is not relocatable.
X owns the directories it creates (/usr/share/sip)
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is not present; no test suite upstream.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

I'll if I can convince 'make install' to not strip the library...

Re: /usr/share/sip/qtext
IMO, sip should own /usr/share/sip, but I suppose we'll mark that as owned 
here until/if that happens.

Any progress with this?  I haven't had any luck figuring out where the strip
comes from.  It might be in /usr/lib64/qt-3.3/mkspecs/linux-g++-64/qmake.conf. 
Oddly, it seems that linux-g++/qmake.conf has the strip call patched out, but
linux-g++-64/qmake.conf doesn't.  Indeed, running a build on i386 results in a
proper debuginfo package.

A bug in the core qt package, perhaps?

Certainly looks like it.

It's almost certainly a qt(qmake) bug, but I'm at a loss as to how to workaround
it here.  As Jason pointed out, it appears to be limited to 64 bit platform(s).

I'll go file a bug against qt.  There's a chance we can't do anything about it here.

At this point since it's obviously not a problem with this package and since
this really doesn't affect the operation of the package, I'm content to approve
things as is (assuming you fix the /usr/share/sip ownership issue).  Hopefully
Core will fix the qt issue in time, but until then we don't lose anything except
a meaningful debuginfo package.

You might want to add a comment about it, and if you really feel daring you can
conditionalize the building of the -debuginfo package to disable it on x86_64. 
I'll leave that up to you.

APPROVED; just own /usr/share/sip when you check in (and probably file a bug
against the sip package as well.)

FYI, Submitted bug #195410, "qt: 64bit platforms make useless -debuginfo rpms".

Thanks, I'll make sure to own /usr/share/sip.

imported, built.

%changelog
* Thu Jun 15 2006 Rex Dieter <rexdieter[AT]users.sf.net> 3.16-3
- devel/fc6 branch uses PyQt-3.16

* Thu Jun 15 2006 Rex Dieter <rexdieter[AT]users.sf.net> 3.15-2
- own %%_datadir/sip