[Bug 673790] Rename Request: mingw32-w32api -> mingw-headers - Win32/Win64 header files and stubs

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=673790

--- Comment #13 from Erik van Pienbroek <erik-fedora at vanpienbroek.nl> 2012-02-25 15:03:41 EST ---
New Spec URL:
http://svn.openftd.org/svn/fedora_cross/mingw-headers/mingw-headers.spec
New SRPM URL:
http://build1.openftd.org/fedora-cross/src/mingw-headers-2.0.999-0.4.trunk.20120120.fc18_cross.src.rpm

* Fri Feb 24 2012 Erik van Pienbroek <epienbro at fedoraproject.org> -
2.0.999-0.4.trunk.20120224
- Update to 20120224 snapshot
- Made the win64 pieces optional for now (pending approval of the
mingw-gcc/mingw-binutils package reviews)
- Eliminated some conditionals related to snapshot builds
- Added DISCLAIMER, DISCLAIMER.PD and COPYING.LIB files
- Added ZPLv2.1 to the license tag
- Added a conditional which is needed to prevent a file conflict with
winpthreads
- Bumped BR: mingw{32,64}-filesystem to >= 70

The BR: mingw32-filesystem bump to >= 70 was done because this will be the
first version to support the new RPM macros like mingw_package_header,
mingw_configure and mingw_make.

The optional win64 conditional was introduced to make the introduction of
mingw-w64 possible (for just the win32 target) while the new mingw-gcc and
mingw-binutils packages are still pending review. Once these packages are
approved this conditional can be removed.

I've decided to use the trunk release instead of v2.0.1 as the trunk version
contains some interesting features like POSIX printf functions and LFS support.
It has also been tested already in the testing repository for some time and all
detected issues are already resolved upstream. All Fedora packages can now
build fine against mingw-w64 trunk (well, except for mingw32-qpid-cpp, but that
one FTBFS because of the new boost library). Nevertheless, the release
management of the mingw-w64 project is an area which could be improved. For
example there is no roadmap containing the list of expected features and
expected release dates and there's no clear overview of the differences between
all versions which makes it hard to make a balanced decision about which
version should be used. From what I've heard upstream is thinking about
releasing current trunk as v2.1 so I think we're good if we stay with trunk for
now until upstream branches.

Yesterday I asked upstream about the automated snapshots. I was told that the
viewvc instance at SourceForge has this nice feature which makes it possible to
generate tarballs from SVN, for example
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/?view=tar which
automatically generates a tarball from the latest trunk. However, the downside
is that the mingw-w64 SVN currently contains a link to an external SVN
repository (ReactOS) for the DDK part. The SF viewvc instance doesn't support
generating tarballs which include files from an external SVN repository. When
an attempt is done to build mingw-headers using this tarball you'd end up with
these kind of messages: configure: WARNING: svn checkout incomplete, ddk
headers missing. Upstream is working on eliminating this external SVN
repository link so this issue should be resolved soon hopefully. For the time
being I think it's okay to use the source snapshot tarballs which can be found
on the SF downloads page

Your suggestion about the improved %prep has been applied in this release

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.