> #BuildRequires:  qt-devel = %{version}  Stupid, can't write this ...

Use:
BuildRequires: qt4-devel = %{version}

Otherwise, you'd have to add the Epoch, i.e.:
BuildRequires: qt-devel = 1:%{version}

(In reply to comment #1)
> > #BuildRequires:  qt-devel = %{version}  Stupid, can't write this ...
> 
> Use:
> BuildRequires: qt4-devel = %{version}
> 
> Otherwise, you'd have to add the Epoch, i.e.:
> BuildRequires: qt-devel = 1:%{version}  

No the problem is we want to buildrequire the same version
of Fedora's native Qt package, but any release.  The reason
is that we want to use the natively compiled 'moc' program.
However 'moc' only works with a matching version of Qt
(eg. all Qt 4.5.0 or whatever).

Now we cannot BuildRequire a specific version-release of
qt-devel (or qt4-devel) because this comes from a different
package, so we would constantly have to chase the native
Fedora package every time they did a new release.

What we want to do is to BR "%{version}-*", but AFAIK there
is no way to do this in RPM.

$ rpm -q --provides qt-devel | grep qt4-devel
qt4-devel = 4.4.3-10.fc10

One way to solve this would be if the qt-devel package
could add an explicit provides, like:

Provides: qt(api) = 4.5.0

= %{version} does exactly that, it matches the version no matter what the %{release} is. The reason it did not work for you is because of the Epoch.

Thanks Kevin, I didn't realize that.

Taking for review.

Probably a good idea to add:

Obsoletes: mingw32-qt-win <= 4.5.0
Provides: mingw32-qt-win = %{version}

otherwise people who are upgrading from the temporary
repository will get conflicts.

Ouch this takes a long time to compile :-(

auto-buildrequires suggests that you have all the right
BuildRequires lines.

rpmlint says:

mingw32-qt.src:219: W: libdir-macro-in-noarch-package %{_libdir}/qt4/mkspecs/fedora-win32-cross

This seems OK ...

mingw32-qt.src: W: strange-permission qt-win-configure.sh 0775

Fine, rpmlint shouldn't complain about these.

mingw32-qt.noarch: E: devel-dependency qt-devel

This is OK, because mingw32-qt is really a devel package.
However, see comment 1.

mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSql4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libqtmaind.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtGuid4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQt3Support4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtXmld4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSvgd4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtXml4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSqld4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtCore4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtNetwork4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtSvg4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libqtmain.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQt3Supportd4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtNetworkd4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtCored4.a
mingw32-qt.noarch: E: arch-independent-package-contains-binary-or-object /usr/i686-pc-mingw32/sys-root/mingw/lib/libQtGui4.a

You can ignore these, see:
http://fedoraproject.org/wiki/MinGW/Rpmlint#arch-independent-package-contains-binary-or-object

mingw32-qt.noarch: E: only-non-binary-in-usr-lib

This refers to the following files:

/usr/lib64/qt4/mkspecs/fedora-win32-cross/qmake.conf
/usr/lib64/qt4/mkspecs/fedora-win32-cross/qplatformdefs.h

and that seems OK.

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1240262

+ rpmlint output
+ package name satisfies the packaging naming guidelines
+ specfile name matches the package base name
+ package should satisfy packaging guidelines
+ license meets guidelines and is acceptable to Fedora
+ license matches the actual package license
+ %doc includes license file
+ spec file written in American English
+ spec file is legible
+ upstream sources match sources in the srpm
+ package successfully builds on at least one architecture
  i586 and x86_64
n/a ExcludeArch bugs filed
+ BuildRequires list all build dependencies
n/a %find_lang instead of %{_datadir}/locale/*
n/a binary RPM with shared library files must call ldconfig in %post and %postun
+ does not use Prefix: /usr
+ package owns all directories it creates
+ no duplicate files in %files
+ %defattr line
+ %clean contains rm -rf $RPM_BUILD_ROOT
+ consistent use of macros
+ package must contain code or permissible content
n/a large documentation files should go in -doc subpackage
+ files marked %doc should not affect package
n/a header files should be in -devel
  ok for mingw packages to have headers
n/a static libraries should be in -static
n/a packages containing pkgconfig (.pc) files need 'Requires: pkgconfig'
n/a libfoo.so must go in -devel
n/a -devel must require the fully versioned base
n/a packages should not contain libtool .la files
n/a packages containing GUI apps must include %{name}.desktop file
+ packages must not own files or directories owned by other packages
+ %install must start with rm -rf %{buildroot} etc.
+ filenames must be valid UTF-8

Optional:

n/a if there is no license file, packager should query upstream
n/a translations of description and summary for non-English languages, if available
+ reviewer should build the package in mock
? the package should build into binary RPMs on all supported architectures
+ review should test the package functions as described
n/a scriptlets should be sane
n/a pkgconfig files should go in -devel
n/a shouldn't have file dependencies outside /etc /bin /sbin /usr/bin or /usr/sbin

-----------------------

This package is APPROVED by rjones

-----------------------

Please see comment 1 and comment 6 before committing.

> mingw32-qt.src:219: W: libdir-macro-in-noarch-package
> %{_libdir}/qt4/mkspecs/fedora-win32-cross
>
> This seems OK ...

No, it's not. Noarch packages MUST NOT install to %{_libdir} as that expands to something different depending on the arch it's built on. In addition, 64-bit qmake will not find the mkspecs in /usr/lib, so even hardcoding it as /usr/lib is wrong.

We used /usr/share/qt4/mkspecs in the native Qt at some point, but this was changed because it causes other problems. So unless we can get the native Qt to look there as well, this package cannot be noarch.

What was the problem that stopped Qt using /usr/share?
It sounds like a bug in the base Qt package TBH.

Actually for now I think we should split the
qmake specs into a separate package.  mingw32-qt.noarch
will have to depend on this.  This new package will be
arch-specific, but will only contain a couple of files,
so quick to build.

New Package CVS Request
=======================
Package Name: mingw32-qt
Short Description: Qt for MinGW32
Owners: sailer rjones
Branches: 
InitialCC:

Thanks for the quick review! I agree, let's split out the qmake related files into a separate package named mingw32-qt-qmake. I will do that and file a separate review for this mingw32-qt-qmake package.

as for #6 should we have to care about temp repos?

IMHO: yes, definitely, especially in a case like this where a simple Obsoletes/Provides is all it takes.

Yes, I agree with Kevin.  It costs almost nothing to add this,
and makes the experience better for quite a lot of early
adopters.  There are many hundreds of silent people using
the temporary yum repository.

cvs done.

Reviewer comments implemented, and built for rawhide.