Update:
* Mon Jan 14 2013 Marcel Wysocki <maci> - 1.2.0-3
- use mingw header macro
- build debuginfo packages


http://koji.fedoraproject.org/koji/taskinfo?taskID=4866908

* Thu Jan 17 2013 Marcel Wysocki <maci> - 1.2.0-4
- add -static packages
- update summary and description
- update buildrequires
- follow https://fedoraproject.org/wiki/Packaging:MinGW

http://koji.fedoraproject.org/koji/taskinfo?taskID=4879446

* Thu Jan 17 2013 Marcel Wysocki <maci> - 1.2.0-5
- add autoconf to BR again, woops

http://koji.fedoraproject.org/koji/taskinfo?taskID=4879455

Taking for review

* Why are you manually moving the .def files in the %build section? If the build fails without it, then this is most likely caused by a bug in the Makefile.am file which should be patched and reported upstream
* Why is the %mingw_find_lang line commented out? If this package doesn't provide translations then please remove this line completely
* The documentation can be removed as there's already a native gtkglext package in Fedora which provides these docs as well
* The 'rm -rf $RPM_BUILD_ROOT' line isn't needed any more on modern environment and can be removed
* The file containing the license should be added to the filelist for both packages and marked as %doc
* Please update the summary for the main package so that it reflects the fact that this is a MinGW package

fixed all issues locally, except the .def file issue.

i reported it to the upstream mailing list.
https://mail.gnome.org/archives/gtkglext-list/2013-April/msg00000.html

I've created a small patch to fix the .def issue. Feel free to propose it upstream.

After applying it you need to run 'autoreconf -i --force' in the %prep section. There's already an 'autoconf -i --force' in the %build section. This one can be removed

Once you've published an updated src.rpm we can continue this review

Created attachment 741444 [details]
Fix out of source builds

thanks for the patch but autoreconf -i --force fails somewhere at the autoconf part

configure.in:190: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:360: error: possibly undefined macro: AM_PATH_GTK_2_0
autoreconf: /usr/bin/autoconf failed with exit status: 1


running libtoolize before doesnt help either.

it works fine however if i install gtk2-devel on the build machine.
but i guess thats another bug in the auto* construct

You can add an "BuildRequires: gtk2-devel" to your spec file to resolve this for now. Once the patch has been accepted upstream and upstream releases a new version you can remove this temporary BuildRequires addition and the autoreconf call.

* Tue Apr 30 2013 Marcel Wysocki <maci> - 1.2.0-8
- add gtk2-devel BR
- run autoreconf -i --force in prep

* Mon Apr 29 2013 Marcel Wysocki <maci> - 1.2.0-7
- add gtkglext-fix-out-of-source-builds.patch


Spec URL: http://maci.satgnu.net/rpmbuild/SPECS/mingw-gtkglext.spec

Please also upload the updated source rpm

SRPM URL: http://maci.satgnu.net/rpmbuild/SRPMS/mingw-gtkglext-1.2.0-8.fc18.src.rpm

* The autoconf files which are created by this package can be removed (%{mingw32_datadir}/aclocal/* and %{mingw64_datadir}/aclocal/*) as they're duplicate files which are already provided by their native counterpart
* Please replace %{mingw32_libdir}/pkgconfig/*.pc and %{mingw64_libdir}/pkgconfig/*.pc with the individual files (as general rule of thumb: try to prevent the use of wildcards in filelists)
* Please add a comment to each patch explaining what the patch does and whether is has already been proposed upstream (reference to upstream bug tracker)

(In reply to comment #13)
> * The autoconf files which are created by this package can be removed
> (%{mingw32_datadir}/aclocal/* and %{mingw64_datadir}/aclocal/*) as they're
> duplicate files which are already provided by their native counterpart

I have a nagging feeling that there must be some case where they are useful.

I would suspect the mingw aclocal files get included when the 'configure' script tries to rebuild itself after the configure.ac timestamp has changed. Not all packages do that, it depends on if/how the AM_MAINTAINER_MODE macro is used.

(This case above can be "fixed" by forcing a rebuild of 'configure' with the native aclocal files by running autoreconf before %mingw_configure.)

(In reply to comment #14)
> (In reply to comment #13)
> > * The autoconf files which are created by this package can be removed
> > (%{mingw32_datadir}/aclocal/* and %{mingw64_datadir}/aclocal/*) as they're
> > duplicate files which are already provided by their native counterpart
> 
> I have a nagging feeling that there must be some case where they are useful.
> 
> I would suspect the mingw aclocal files get included when the 'configure'
> script tries to rebuild itself after the configure.ac timestamp has changed.
> Not all packages do that, it depends on if/how the AM_MAINTAINER_MODE macro
> is used.
> 
> (This case above can be "fixed" by forcing a rebuild of 'configure' with the
> native aclocal files by running autoreconf before %mingw_configure.)

I understand the situation you're trying to explain, but afaik autoconf/automake is only aware of /usr/share/data/aclocal. There are no references to /usr/i686-w64-mingw32/sys-root/mingw/share/data/aclocal in our mingw macros so how is autofoo ever supposed to be aware of files in these folders?

Typo in paths:

/usr/share/data/aclocal --> /usr/share/aclocal
/usr/i686-w64-mingw32/sys-root/mingw/share/data/aclocal --> /usr/i686-w64-mingw32/sys-root/mingw/share/aclocal

Fair enough, sounds like they don't really get used then.

I also did a little bit digging and found the following in /usr/bin/aclocal. We don't set ACLOCAL_PATH so it will only use the hardcoded system dir.

# Include paths for searching macros.  We search macros in this order:
# user-supplied directories first, then the directory containing the
# automake macros, and finally the system-wide directories for
# third-party macros.
# @user_includes can be augmented with -I.
# @automake_includes can be reset with the '--automake-acdir' option.
# @system_includes can be augmented with the 'dirlist' file or the
# ACLOCAL_PATH environment variable, and reset with the '--system-acdir'
# option.
my @user_includes = ();
my @automake_includes = ("/usr/share/aclocal-$APIVERSION");
my @system_includes = ('/usr/share/aclocal');

I was just working on updating the MinGW packaging guidelines and this looks like a candidate which can also be added to the guidelines: autoconf files don't need to be bundled in mingw packages when their native counterparts also provide the same autoconf files

Section added to the draft MinGW packaging guidelines on what files not to package: https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler#Files_which_are_already_part_of_native_packages

* Mon May 20 2013 Marcel Wysocki <maci> - 1.2.0-9
- remove autoconf files
- spec cleanups
- added infos about patches


SPEC URL: http://maci.satgnu.net/rpmbuild/SPECS/mingw-gtkglext.spec
SRPM URL: http://maci.satgnu.net/rpmbuild/SRPMS/mingw-gtkglext-1.2.0-9.fc19.src.rpm

$ rpmlint mingw-gtkglext.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

$ rpmlint mingw-gtkglext-1.2.0-9.fc19.src.rpm 
mingw-gtkglext.src: W: spelling-error %description -l en_US ons -> nos, ins, obs
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

$ rpmlint mingw32-gtkglext-1.2.0-9.fc19.noarch.rpm mingw32-gtkglext-static-1.2.0-9.fc19.noarch.rpm mingw64-gtkglext-1.2.0-9.fc19.noarch.rpm mingw64-gtkglext-static-1.2.0-9.fc19.noarch.rpm
mingw32-gtkglext.noarch: W: spelling-error %description -l en_US ons -> nos, ins, obs
mingw32-gtkglext.noarch: E: incorrect-fsf-address /usr/share/doc/mingw32-gtkglext-1.2.0/COPYING
mingw32-gtkglext.noarch: E: incorrect-fsf-address /usr/share/doc/mingw32-gtkglext-1.2.0/COPYING.LIB
mingw32-gtkglext-static.noarch: W: spelling-error %description -l en_US ons -> nos, ins, obs
mingw32-gtkglext-static.noarch: W: no-documentation
mingw64-gtkglext.noarch: W: spelling-error %description -l en_US ons -> nos, ins, obs
mingw64-gtkglext.noarch: E: incorrect-fsf-address /usr/share/doc/mingw64-gtkglext-1.2.0/COPYING.LIB
mingw64-gtkglext.noarch: E: incorrect-fsf-address /usr/share/doc/mingw64-gtkglext-1.2.0/COPYING
mingw64-gtkglext-static.noarch: W: spelling-error %description -l en_US ons -> nos, ins, obs
mingw64-gtkglext-static.noarch: W: no-documentation
packages and 0 specfiles checked; 4 errors, 6 warnings.


$ rpm --query --requires mingw32-gtkglext
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
mingw32-crt
mingw32-filesystem >= 83
mingw32(gdi32.dll)
mingw32(glu32.dll)
mingw32(kernel32.dll)
mingw32(libgcc_s_sjlj-1.dll)
mingw32(libgdkglext-win32-1.0-0.dll)
mingw32(libgdk-win32-2.0-0.dll)
mingw32(libglib-2.0-0.dll)
mingw32(libgobject-2.0-0.dll)
mingw32(libgtk-win32-2.0-0.dll)
mingw32(libpango-1.0-0.dll)
mingw32(libpangowin32-1.0-0.dll)
mingw32(msvcrt.dll)
mingw32(opengl32.dll)
mingw32-pkg-config
mingw32(user32.dll)
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm --query --requires mingw64-gtkglext
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
mingw64-crt
mingw64-filesystem >= 83
mingw64(gdi32.dll)
mingw64(glu32.dll)
mingw64(kernel32.dll)
mingw64(libgdkglext-win32-1.0-0.dll)
mingw64(libgdk-win32-2.0-0.dll)
mingw64(libglib-2.0-0.dll)
mingw64(libgobject-2.0-0.dll)
mingw64(libgtk-win32-2.0-0.dll)
mingw64(libpango-1.0-0.dll)
mingw64(libpangowin32-1.0-0.dll)
mingw64(msvcrt.dll)
mingw64(opengl32.dll)
mingw64-pkg-config
mingw64(user32.dll)
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm --query --requires mingw32-gtkglext-static
mingw32-gtkglext = 1.2.0-9.fc19
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm --query --requires mingw64-gtkglext-static
mingw64-gtkglext = 1.2.0-9.fc19
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1


$ rpm --query --provides mingw32-gtkglext
mingw32-gtkglext = 1.2.0-9.fc19
mingw32(libgdkglext-win32-1.0-0.dll)
mingw32(libgtkglext-win32-1.0-0.dll)

$ rpm --query --provides mingw64-gtkglext
mingw64-gtkglext = 1.2.0-9.fc19
mingw64(libgdkglext-win32-1.0-0.dll)
mingw64(libgtkglext-win32-1.0-0.dll)

$ rpm --query --provides mingw32-gtkglext-static
mingw32-gtkglext-static = 1.2.0-9.fc19

$ rpm --query --provides mingw64-gtkglext-static
mingw64-gtkglext-static = 1.2.0-9.fc19


$ wget --quiet  http://downloads.sourceforge.net/sourceforge/gtkglext/gtkglext-1.2.0.tar.bz2 -O - | md5sum
ed7ba24ce06a8630c07f2d0ee5f04ab4  -
$ md5sum gtkglext-1.2.0.tar.bz2 
ed7ba24ce06a8630c07f2d0ee5f04ab4  gtkglext-1.2.0.tar.bz2


+ OK
! Needs to be looked into
/ Not applicable

[!] Compliant with generic Fedora Packaging Guidelines
[+] Source package name is prefixed with 'mingw-'
[+] Spec file starts with %{?mingw_package_header}
[+] BuildRequires: mingw32-filesystem >= 95 is in the .spec file
[+] BuildRequires: mingw64-filesystem >= 95 is in the .spec file
[+] Spec file contains %package sections for both mingw32 and mingw64 packages
[+] Binary mingw32 and mingw64 packages are noarch
[+] Spec file contains %{?mingw_debug_package} after the %description section
[+] Uses one of the macros %mingw_configure, %mingw_cmake, or %mingw_cmake_kde4
    to configure the package
[+] Uses the macro %mingw_make to build the package
[+] Uses the macro %mingw_make to install the package
[+] If package contains translations, the %mingw_find_lang macro must be used
[+] No binary package named mingw-$pkgname is generated
[+] Libtool .la files are not bundled
[+] .def files are not bundled
[+] Man pages which duplicate native package are not bundled
[+] Info files which duplicate native package are not bundled
[+] Provides of the binary mingw32 and mingw64 packages are equal
[!] Requires of the binary mingw32 and mingw64 packages are equal


The incorrect-fsf-address rpmlint warning should be reported upstream.
All other rpmlint warnings can be ignored.

The mingw32 package seems to depend on libgcc_s_sjlj-1.dll while the mingw64
package doesn't. I've also seen this on various other packages so we can
ignore this for now


====================================================
 The package mingw-gtkglext is APPROVED by epienbro
====================================================

New Package SCM Request
=======================
Package Name: mingw-gtkglext
Short Description: GtkGLExt is an OpenGL extension to GTK+. Compiled for the MinGW Platform.
Owners: maci
Branches: f17 f18 f19 el6
InitialCC:

Git done (by process-git-requests).

Note: it isn't possible to build this package on RHEL6. This is because of the fact that Red Hat is shipping the old mingw.org toolchain by default in RHEL6. All the mingw-filesystem infrastructure is also still based on the mingw.org toolchain and only supports the win32 target (win64 isn't supported).

We can't introduce the mingw-w64 toolchain in RHEL6 because according to the EPEL packaging guidelines it isn't allowed to replace packages which are already part of the official RHEL6 repositories.

mingw-gtkglext-1.2.0-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mingw-gtkglext-1.2.0-10.fc18

mingw-gtkglext-1.2.0-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mingw-gtkglext-1.2.0-10.fc19

mingw-gtkglext-1.2.0-10.fc19 has been pushed to the Fedora 19 testing repository.

mingw-gtkglext-1.2.0-10.fc18 has been pushed to the Fedora 18 stable repository.

mingw-gtkglext-1.2.0-10.fc19 has been pushed to the Fedora 19 stable repository.