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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> - 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review