I am very opposed to this renamer be cause this package doesn't provide what it name suggests. It is not a general cross-toolchain filesystem.

I'm with Ralf here, unless the whole cross-* package set will provide a general cross-tools framework, the naming of the packages is misleading. It looks to me as very mingw oriented.

Also, there is another issue with this package: 

The target name: x86_64-w64-mingw32

# rpm -qlp /var/lib/mock/fedora-rawhide-x86_64/result/mingw64-filesystem-65-1.fc15.noarch.rpm 
...
/usr/x86_64-w64-mingw32
...

I fail to understand what this target shall be. To me, this name seems unlogic.

I think Ralf has a point here.

However the problem with the proposal is simply the choice of
"cross-*" as a prefix.  I believe since this is not a truly
general cross-compiler (ie. not targetted at arm embedded etc)
that we should just come up with another prefix.

Since we aim to cross-compiler for common desktop platforms
(ie. Windows 32/64 + Mac OS X) how about calling it
crossdesktop-*?

As mentioned on the link in the initial message the plan is to rename all current mingw32-* package to cross-*. The idea behind this is that packagers can maintain packages for multiple targets using a single spec file. Initially we will support the Win32 and Win64 targets in this framework, but support for Mac OS X can be added quite easily (it has been proven to work in a testing repository, see the link in the initial message for more about that)

I'm okay with using a different prefix like the crossdesktop-* which Richard suggested if you prefer that

The target name x86_64-w64-mingw32 might look a bit odd for outsiders, but it's the default target name used by the mingw-w64 developers. I just dropped the question about the history behind that name in the #mingw-w64 IRC channel and I got multiple answers back. The main reason is compatibility. Think about the autotools where a large amount of checks look for the term 'mingw32' in the target to find out whether the target is a MS Windows one. When the 'w64' part in the target name is used certain compiler features become available like unicode startup (important for kernel-mode drivers and unicode features apps) and more. More details about this can also be found at https://sourceforge.net/apps/trac/mingw-w64/wiki/Feature%20list and http://www.ruby-forum.com/topic/217754

(In reply to comment #5)
> As mentioned on the link in the initial message the plan is to rename all
> current mingw32-* package to cross-*.
With all due respect, to me this plan is beyond reason, because mingw, rsp. their 2 sub targets mingw32 and mingw64 are only a very small subset of cross-targets.


> I'm okay with using a different prefix like the crossdesktop-* which Richard
> suggested if you prefer that

IMO, mingw-filesystem would be an appropriate name, because that's what it currently is - The rest of it is wishful thinking.
 
> The target name x86_64-w64-mingw32 might look a bit odd for outsiders, but it's
> the default target name used by the mingw-w64 developers.
Well, ... this doesn't mean their decisions are wise ;)

x86_64-w64-mingw32 (cpu=x86_64, os=mingw32) is multiply problematic:
- the "32" in mingw32 originally stood for "MinGW on 32bit Windows",
=> a 64bit MinGW for "MinGW on 64bit Windows" should be named "mingw64"
- Configure scripts currently presume "os=mingw32" to imply 32bit MinGW.
...

I.e. to me reasonable choices would be
x86_64-pc-mingw + i686-pc-mingw
or 
x86_64-pc-mingw64 + i686-pc-mingw32

> I just dropped the
> question about the history behind that name in the #mingw-w64 IRC channel and I
> got multiple answers back. The main reason is compatibility. Think about the
> autotools where a large amount of checks look for the term 'mingw32' in the
> target to find out whether the target is a MS Windows one. When the 'w64' part
> in the target name is used

The 2nd field of a target-triple is the "vendor"/"manufacturer" field, which originally was meant to be the hard-ware manufacturer of a specific board, which later became abused by Linux-vendors to put their brand into (*-redhat-*, *-suse-*).

I.e. if mingw wants to follow the "HW vendor" path, their 2nd field should be "pc" (The generic value), rsp, if they want to follow the SW vendor path, it should be "microsoft".

In any case, the vendor field is without much practical importance and unused in 99% of all configure scripts (ignored).

What matters are the "cpu"-field and the "OS" field - They need to provide sufficient information for configure scripts to destinguish architectures and OSes.

That said, I consider x86_64-w64-mingw32 to be a mistake.

(In reply to comment #6)
> > I'm okay with using a different prefix like the crossdesktop-* which Richard
> > suggested if you prefer that
> 
> IMO, mingw-filesystem would be an appropriate name, because that's what it
> currently is - The rest of it is wishful thinking.

"mingw" has always been an unfortunate choice of name.  Really
the cross-compiler has very little to do with the mingw.org project.
mingw-w64 is a completely separate fork.  And there is a separate
mingw.org-related binary project which is nothing to do with us,
but people frequently get confused over the two.

And *crucially* we are adding support for Mac OS X which doesn't
use mingw at all.

This is why I'm suggesting crossdesktop-* or some other choice
which doesn't involve the 5 letters "mingw".

> > The target name x86_64-w64-mingw32 might look a bit odd for outsiders, but it's
> > the default target name used by the mingw-w64 developers.
> Well, ... this doesn't mean their decisions are wise ;)
> 
> x86_64-w64-mingw32 (cpu=x86_64, os=mingw32) is multiply problematic:
> - the "32" in mingw32 originally stood for "MinGW on 32bit Windows",
> => a 64bit MinGW for "MinGW on 64bit Windows" should be named "mingw64"
> - Configure scripts currently presume "os=mingw32" to imply 32bit MinGW.
> ...
>
> I.e. to me reasonable choices would be
> x86_64-pc-mingw + i686-pc-mingw
> or 
> x86_64-pc-mingw64 + i686-pc-mingw32

Whatever you think doesn't really matter, since this is the
choice of the mingw-w64 upstream project.  They are in a much
better situation to judge how it should work.

(In reply to comment #7)
> (In reply to comment #6)
> > > I'm okay with using a different prefix like the crossdesktop-* which Richard
> > > suggested if you prefer that
> > 
> > IMO, mingw-filesystem would be an appropriate name, because that's what it
> > currently is - The rest of it is wishful thinking.
> 
> "mingw" has always been an unfortunate choice of name. 
I disagree - It would have been the appropriate choice.

> And *crucially* we are adding support for Mac OS X which doesn't
> use mingw at all.
Well, has the licence/copyright situation changed?
To my knowledge MacOSX requires non-free code from Apple.
  

> > > The target name x86_64-w64-mingw32 might look a bit odd for outsiders, but it's
> > > the default target name used by the mingw-w64 developers.
> > Well, ... this doesn't mean their decisions are wise ;)
> > 
> > x86_64-w64-mingw32 (cpu=x86_64, os=mingw32) is multiply problematic:
> > - the "32" in mingw32 originally stood for "MinGW on 32bit Windows",
> > => a 64bit MinGW for "MinGW on 64bit Windows" should be named "mingw64"
> > - Configure scripts currently presume "os=mingw32" to imply 32bit MinGW.
> > ...
> >
> > I.e. to me reasonable choices would be
> > x86_64-pc-mingw + i686-pc-mingw
> > or 
> > x86_64-pc-mingw64 + i686-pc-mingw32
> 
> Whatever you think doesn't really matter,
Correct.

> since this is the
> choice of the mingw-w64 upstream project.  They are in a much
> better situation to judge how it should work.
I disagree. One thing I had learnt with MinGW is them being Windows focused folks with little GNU SW experience - One of the situation this shows is situations like these.

(In reply to comment #8)
> I disagree - It would have been the appropriate choice.

Why is it if you didn't create it, Ralf, you always disagree?

cross-* is the /start/ of the cross compiler project. Eric/Richard are starting the cross compiler project with only MinGW, but with the plan to expand to OS X and whatever other cross compiling.

In your mind, Ralf, Eric/Richard need to keep the cross compiler package names split?? THAT doesn't make any sense.

(In reply to comment #9)
> (In reply to comment #8)
> > I disagree - It would have been the appropriate choice.
> 
> Why is it if you didn't create it,
... because I don't see any sense in such a package.
... and because I have a cross compiler infrastructure package of my own,

[rude as-hominem offense delete] 

> cross-* is the /start/ of the cross compiler project.
It's some people's cross-compiler project - Not mine.

> In your mind, Ralf, Eric/Richard need to keep the cross compiler package names
> split??
They can call their package by what ever name they want, but calling a package "cross-filesystem", which doesn't do what it claims, is not useful.

OK, but I don't think crossdesktop-* is going to offend anyone's
sensibilities.  It reflects what we are doing: offering a cross
compiler that targets the most popular desktop systems out there
today (where "most popular" is measured by market share, and
"desktop" doesn't include embedded/mobile systems).

And how do you want to continue with binutils, gcc etc?

Consider packaging cross compilers from Fedora to non-native Fedora targets, other Linuxes (RHEL4/5/6, openSUSE-11.2/11.3, ...), some "plain metal targets", exotic embedded target or other *nix (e.g. *BSDs).

It's simply impractiable to build all of them from one "single unified source-package" (not even MinGW32/MinGW64/MacOSX) 
=> cross-binutils/gcc packages don't even make less sense than a common base package.

> (In reply to comment #5)
> That said, I consider x86_64-w64-mingw32 to be a mistake.

I agree with you that x86_64-w64-mingw32 isn't an ideal name, but we've got to do with it for now. While it technically could be made possible to use a different target it will require patching of almost every package and the toolchain itself will divert from upstream. Is that really a direction we should be going..?

How about these names for the source rpms:

crossdesktop-filesystem - Contains the binary RPMs mingw32-filesystem, mingw64-filesytem and (later) darwinx-filesystem
mingw-binutils - Contains the binary RPMs mingw32-binutils and mingw64-binutils
mingw-gcc - Contains the binary RPMs mingw32-gcc and mingw64-gcc
mingw-headers - Contains the binary RPMs mingw32-headers and mingw64-headers
mingw-crt - Contains the binary RPMs mingw32-crt and mingw64-crt

and in the future, once legal issues get cleared :
darwinx-odcctools - Contains the binutils equivalent for Mac OS X
darwinx-gcc - Contains Apple's version of GCC(In reply to comment #6)
darwinx-sdk - Contains the various headers and libraries of a default Mac OS X environment

All mingw32-* packages could then get renamed to crossdesktop-* packages and produce binary RPMs called mingw32-*, mingw64-* (and later darwinx-*)

I am no packager (yet), but I really would like to help out. Any objections if I take this for review, or is this against the rules? For clarity: I've so far only done one Fedora package review in the past (mingw32-win-iconv, BZ #642208), so this would be my second one.

If you are not a packager, you cannot approve packages or take review tickets but of course you are welcome to make all the comments you like.

Ok. Informal review follows.


+ OK
! Needs to be looked into
/ Not applicable
* Overridden by MinGW guidelines
? Unsure


=======
Rpmlint
=======

$ rpmlint cross-filesystem.spec 
cross-filesystem.spec:75: W: unversioned-explicit-provides mingw32(kernel32.dll)
cross-filesystem.spec:76: W: unversioned-explicit-provides mingw32(msvcrt.dll)
cross-filesystem.spec:77: W: unversioned-explicit-provides mingw32(advapi32.dll)
cross-filesystem.spec:78: W: unversioned-explicit-provides mingw32(user32.dll)
cross-filesystem.spec:79: W: unversioned-explicit-provides mingw32(dnsapi.dll)
cross-filesystem.spec:80: W: unversioned-explicit-provides mingw32(ole32.dll)
cross-filesystem.spec:81: W: unversioned-explicit-provides mingw32(shell32.dll)
cross-filesystem.spec:82: W: unversioned-explicit-provides mingw32(shlwapi.dll)
cross-filesystem.spec:83: W: unversioned-explicit-provides mingw32(ws2_32.dll)
cross-filesystem.spec:84: W: unversioned-explicit-provides mingw32(gdi32.dll)
cross-filesystem.spec:85: W: unversioned-explicit-provides mingw32(msimg32.dll)
cross-filesystem.spec:86: W: unversioned-explicit-provides mingw32(comctl32.dll)
cross-filesystem.spec:87: W: unversioned-explicit-provides mingw32(comdlg32.dll)
cross-filesystem.spec:88: W: unversioned-explicit-provides mingw32(imm32.dll)
cross-filesystem.spec:89: W: unversioned-explicit-provides mingw32(crypt32.dll)
cross-filesystem.spec:90: W: unversioned-explicit-provides mingw32(oleaut32.dll)
cross-filesystem.spec:91: W: unversioned-explicit-provides mingw32(opengl32.dll)
cross-filesystem.spec:92: W: unversioned-explicit-provides mingw32(version.dll)
cross-filesystem.spec:93: W: unversioned-explicit-provides mingw32(winmm.dll)
cross-filesystem.spec:94: W: unversioned-explicit-provides mingw32(rpcrt4.dll)
cross-filesystem.spec:95: W: unversioned-explicit-provides mingw32(gdiplus.dll)
cross-filesystem.spec:96: W: unversioned-explicit-provides mingw32(usp10.dll)
cross-filesystem.spec:97: W: unversioned-explicit-provides mingw32(msdmo.dll)
cross-filesystem.spec:98: W: unversioned-explicit-provides mingw32(odbc32.dll)
cross-filesystem.spec:108: W: unversioned-explicit-provides mingw64(kernel32.dll)
cross-filesystem.spec:109: W: unversioned-explicit-provides mingw64(msvcrt.dll)
cross-filesystem.spec:110: W: unversioned-explicit-provides mingw64(advapi32.dll)
cross-filesystem.spec:111: W: unversioned-explicit-provides mingw64(user32.dll)
cross-filesystem.spec:112: W: unversioned-explicit-provides mingw64(dnsapi.dll)
cross-filesystem.spec:113: W: unversioned-explicit-provides mingw64(ole32.dll)
cross-filesystem.spec:114: W: unversioned-explicit-provides mingw64(shell32.dll)
cross-filesystem.spec:115: W: unversioned-explicit-provides mingw64(shlwapi.dll)
cross-filesystem.spec:116: W: unversioned-explicit-provides mingw64(ws2_32.dll)
cross-filesystem.spec:117: W: unversioned-explicit-provides mingw64(gdi32.dll)
cross-filesystem.spec:118: W: unversioned-explicit-provides mingw64(msimg32.dll)
cross-filesystem.spec:119: W: unversioned-explicit-provides mingw64(comctl32.dll)
cross-filesystem.spec:120: W: unversioned-explicit-provides mingw64(comdlg32.dll)
cross-filesystem.spec:121: W: unversioned-explicit-provides mingw64(imm32.dll)
cross-filesystem.spec:122: W: unversioned-explicit-provides mingw64(crypt32.dll)
cross-filesystem.spec:123: W: unversioned-explicit-provides mingw64(oleaut32.dll)
cross-filesystem.spec:124: W: unversioned-explicit-provides mingw64(opengl32.dll)
cross-filesystem.spec:125: W: unversioned-explicit-provides mingw64(version.dll)
cross-filesystem.spec:126: W: unversioned-explicit-provides mingw64(winmm.dll)
cross-filesystem.spec:127: W: unversioned-explicit-provides mingw64(rpcrt4.dll)
cross-filesystem.spec:128: W: unversioned-explicit-provides mingw64(gdiplus.dll)
cross-filesystem.spec:129: W: unversioned-explicit-provides mingw64(usp10.dll)
cross-filesystem.spec:130: W: unversioned-explicit-provides mingw64(msdmo.dll)
cross-filesystem.spec:131: W: unversioned-explicit-provides mingw64(odbc32.dll)
cross-filesystem.spec:174: W: macro-in-comment %{_prefix}
0 packages and 1 specfiles checked; 0 errors, 49 warnings.

[!] Remove lines 173-174 to get rid of the macro-in-comment
    warning. Other warnings are obviously false positives (per
    comments in spec file).

$ rpmlint cross-filesystem-65-1.fc15_cross.src.rpm 
cross-filesystem.src: W: strange-permission cross-find-provides.sh 0775L
cross-filesystem.src: W: strange-permission cross-find-debuginfo.sh 0775L
cross-filesystem.src: W: strange-permission cross-find-requires.sh 0775L
cross-filesystem.src: W: strange-permission cross-scripts.sh 0775L
cross-filesystem.src: W: strange-permission cross-find-lang.sh 0775L
cross-filesystem.src:75: W: unversioned-explicit-provides mingw32(kernel32.dll)
cross-filesystem.src:76: W: unversioned-explicit-provides mingw32(msvcrt.dll)
cross-filesystem.src:77: W: unversioned-explicit-provides mingw32(advapi32.dll)
cross-filesystem.src:78: W: unversioned-explicit-provides mingw32(user32.dll)
cross-filesystem.src:79: W: unversioned-explicit-provides mingw32(dnsapi.dll)
cross-filesystem.src:80: W: unversioned-explicit-provides mingw32(ole32.dll)
cross-filesystem.src:81: W: unversioned-explicit-provides mingw32(shell32.dll)
cross-filesystem.src:82: W: unversioned-explicit-provides mingw32(shlwapi.dll)
cross-filesystem.src:83: W: unversioned-explicit-provides mingw32(ws2_32.dll)
cross-filesystem.src:84: W: unversioned-explicit-provides mingw32(gdi32.dll)
cross-filesystem.src:85: W: unversioned-explicit-provides mingw32(msimg32.dll)
cross-filesystem.src:86: W: unversioned-explicit-provides mingw32(comctl32.dll)
cross-filesystem.src:87: W: unversioned-explicit-provides mingw32(comdlg32.dll)
cross-filesystem.src:88: W: unversioned-explicit-provides mingw32(imm32.dll)
cross-filesystem.src:89: W: unversioned-explicit-provides mingw32(crypt32.dll)
cross-filesystem.src:90: W: unversioned-explicit-provides mingw32(oleaut32.dll)
cross-filesystem.src:91: W: unversioned-explicit-provides mingw32(opengl32.dll)
cross-filesystem.src:92: W: unversioned-explicit-provides mingw32(version.dll)
cross-filesystem.src:93: W: unversioned-explicit-provides mingw32(winmm.dll)
cross-filesystem.src:94: W: unversioned-explicit-provides mingw32(rpcrt4.dll)
cross-filesystem.src:95: W: unversioned-explicit-provides mingw32(gdiplus.dll)
cross-filesystem.src:96: W: unversioned-explicit-provides mingw32(usp10.dll)
cross-filesystem.src:97: W: unversioned-explicit-provides mingw32(msdmo.dll)
cross-filesystem.src:98: W: unversioned-explicit-provides mingw32(odbc32.dll)
cross-filesystem.src:108: W: unversioned-explicit-provides mingw64(kernel32.dll)
cross-filesystem.src:109: W: unversioned-explicit-provides mingw64(msvcrt.dll)
cross-filesystem.src:110: W: unversioned-explicit-provides mingw64(advapi32.dll)
cross-filesystem.src:111: W: unversioned-explicit-provides mingw64(user32.dll)
cross-filesystem.src:112: W: unversioned-explicit-provides mingw64(dnsapi.dll)
cross-filesystem.src:113: W: unversioned-explicit-provides mingw64(ole32.dll)
cross-filesystem.src:114: W: unversioned-explicit-provides mingw64(shell32.dll)
cross-filesystem.src:115: W: unversioned-explicit-provides mingw64(shlwapi.dll)
cross-filesystem.src:116: W: unversioned-explicit-provides mingw64(ws2_32.dll)
cross-filesystem.src:117: W: unversioned-explicit-provides mingw64(gdi32.dll)
cross-filesystem.src:118: W: unversioned-explicit-provides mingw64(msimg32.dll)
cross-filesystem.src:119: W: unversioned-explicit-provides mingw64(comctl32.dll)
cross-filesystem.src:120: W: unversioned-explicit-provides mingw64(comdlg32.dll)
cross-filesystem.src:121: W: unversioned-explicit-provides mingw64(imm32.dll)
cross-filesystem.src:122: W: unversioned-explicit-provides mingw64(crypt32.dll)
cross-filesystem.src:123: W: unversioned-explicit-provides mingw64(oleaut32.dll)
cross-filesystem.src:124: W: unversioned-explicit-provides mingw64(opengl32.dll)
cross-filesystem.src:125: W: unversioned-explicit-provides mingw64(version.dll)
cross-filesystem.src:126: W: unversioned-explicit-provides mingw64(winmm.dll)
cross-filesystem.src:127: W: unversioned-explicit-provides mingw64(rpcrt4.dll)
cross-filesystem.src:128: W: unversioned-explicit-provides mingw64(gdiplus.dll)
cross-filesystem.src:129: W: unversioned-explicit-provides mingw64(usp10.dll)
cross-filesystem.src:130: W: unversioned-explicit-provides mingw64(msdmo.dll)
cross-filesystem.src:131: W: unversioned-explicit-provides mingw64(odbc32.dll)
cross-filesystem.src:174: W: macro-in-comment %{_prefix}
1 packages and 0 specfiles checked; 0 errors, 54 warnings.

[!] "chmod 755" all scripts.

$ rpm -i cross-filesystem-65-1.fc15_cross.src.rpm

Install works.

$ svn co http://svn.openftd.org/svn/fedora_cross/cross-filesystem/
$ diff cross-filesystem ~/rpmbuild/SOURCES/
Only in cross-filesystem: cross-filesystem.spec
Only in cross-filesystem: Makefile
Only in cross-filesystem: .svn

Looks fine.

$ rpmbuild -ba cross-filesystem.spec
...

Build succeeds.

$ rpmlint ~/rpmbuild/RPMS/noarch/cross-filesystem-65-1.fc14.noarch.rpm 
cross-filesystem.noarch: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

$ rpmlint ~/rpmbuild/RPMS/noarch/cross-filesystem-scripts-65-1.fc14.noarch.rpm 
cross-filesystem-scripts.noarch: W: unexpanded-macro %description -l C %{description}
cross-filesystem-scripts.noarch: W: only-non-binary-in-usr-lib
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

[!] unexpanded-macro:

    The cross-filesystem-scripts-description needs fixing (the
    packaging guidelines suggest either to avoid macros in the
    description, or to define the macro explicitly in the spec file).

[?] only-non-binary-in-usr-lib:

    This seems to suggest that everything should go into %{_datadir}
    instead (i.e. /usr/share/). Since these all concern rpm scripts,
    am I right that an exception applies (because rpm generally
    installs its scripts in /usr/lib/rpm and nowhere else)?

$ rpmlint ~/rpmbuild/RPMS/noarch/mingw32-filesystem-65-1.fc14.noarch.rpm 
mingw32-filesystem.noarch: W: unexpanded-macro %description -l C %{description}
mingw32-filesystem.noarch: W: obsolete-not-provided mingw32-dlfcn
mingw32-filesystem.noarch: W: no-documentation
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/mingw32-configure /usr/libexec/cross-scripts
mingw32-filesystem.noarch: W: no-manual-page-for-binary mingw32-configure
mingw32-filesystem.noarch: W: non-standard-dir-in-usr i686-w64-mingw32
1 packages and 0 specfiles checked; 0 errors, 6 warnings.

[!] unexpanded-macro: Fix description.
[!] obsolete-not-provided: Add "Provides: mingw32-dlfcn = 0-0.8.r11%{?dist}".
no-documentation: Bogus warning.
dangling-symlink: Bogus warning (link provided by required subpackage).
no-manual-page-for-binary: Bogus.
non-standard-dir-in-usr: Approved by Fedora MinGW guidelines.

$ rpmlint ~/rpmbuild/RPMS/noarch/mingw64-filesystem-65-1.fc14.noarch.rpm 
mingw64-filesystem.noarch: W: unexpanded-macro %description -l C %{description}
mingw64-filesystem.noarch: W: no-documentation
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/mingw64-configure /usr/libexec/cross-scripts
mingw64-filesystem.noarch: W: no-manual-page-for-binary mingw64-configure
1 packages and 0 specfiles checked; 0 errors, 4 warnings.

Dito.

============
Dependencies
============

$ su -c 'yum erase mingw*' # make sure everything is clean
$ su -c 'yum install mingw32-filesystem'
$ rpm -qa | grep mingw
mingw32-filesystem-63-1.fc14.noarch
$ su -c 'rpm -Uv /home/amorilia/rpmbuild/RPMS/noarch/cross-filesystem*.rpm /home/amorilia/rpmbuild/RPMS/noarch/mingw??-filesystem*.rpm'
Preparing packages for installation...
cross-filesystem-scripts-65-1.fc14
mingw32-filesystem-65-1.fc14
mingw64-filesystem-65-1.fc14
cross-filesystem-65-1.fc14

$ rpmquery --requires cross-filesystem
setup  
rpm  
rpmlint >= 0.85-2
mingw32-filesystem = 65-1.fc14
mingw64-filesystem = 65-1.fc14
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpmquery --requires cross-filesystem-scripts
/bin/bash  
/bin/sh  
config(cross-filesystem-scripts) = 65-1.fc14
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpmquery --requires mingw32-filesystem
config(mingw32-filesystem) = 65-1.fc14
cross-filesystem-scripts = 65-1.fc14
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpmquery --requires mingw64-filesystem
config(mingw64-filesystem) = 65-1.fc14
cross-filesystem-scripts = 65-1.fc14
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpmquery --provides cross-filesystem
cross-filesystem = 65-1.fc14

$ rpmquery --provides cross-filesystem-scripts
config(cross-filesystem-scripts) = 65-1.fc14
cross-filesystem-scripts = 65-1.fc14

$ rpmquery --provides mingw32-filesystem
config(mingw32-filesystem) = 65-1.fc14
mingw32(advapi32.dll)  
mingw32(comctl32.dll)  
mingw32(comdlg32.dll)  
mingw32(crypt32.dll)  
mingw32(dnsapi.dll)  
mingw32(gdi32.dll)  
mingw32(gdiplus.dll)  
mingw32(imm32.dll)  
mingw32(kernel32.dll)  
mingw32(msdmo.dll)  
mingw32(msimg32.dll)  
mingw32(msvcrt.dll)  
mingw32(odbc32.dll)  
mingw32(ole32.dll)  
mingw32(oleaut32.dll)  
mingw32(opengl32.dll)  
mingw32(rpcrt4.dll)  
mingw32(shell32.dll)  
mingw32(shlwapi.dll)  
mingw32(user32.dll)  
mingw32(usp10.dll)  
mingw32(version.dll)  
mingw32(winmm.dll)  
mingw32(ws2_32.dll)  
mingw32-filesystem = 65-1.fc14

$ rpmquery --provides mingw64-filesystem
config(mingw64-filesystem) = 65-1.fc14
mingw64(advapi32.dll)  
mingw64(comctl32.dll)  
mingw64(comdlg32.dll)  
mingw64(crypt32.dll)  
mingw64(dnsapi.dll)  
mingw64(gdi32.dll)  
mingw64(gdiplus.dll)  
mingw64(imm32.dll)  
mingw64(kernel32.dll)  
mingw64(msdmo.dll)  
mingw64(msimg32.dll)  
mingw64(msvcrt.dll)  
mingw64(odbc32.dll)  
mingw64(ole32.dll)  
mingw64(oleaut32.dll)  
mingw64(opengl32.dll)  
mingw64(rpcrt4.dll)  
mingw64(shell32.dll)  
mingw64(shlwapi.dll)  
mingw64(user32.dll)  
mingw64(usp10.dll)  
mingw64(version.dll)  
mingw64(winmm.dll)  
mingw64(ws2_32.dll)  
mingw64-filesystem = 65-1.fc14

=======
Testing
=======

$ su -c 'yum install mingw32-gcc'
$ mingw32-configure ...

[!] Obviously breaks stuff at the moment because the scripts refer to
    the new mingw-w64 toolchain. But this is expected behaviour. See

http://fedoraproject.org/wiki/MinGW/CrossCompilerFramework#Roadmap

=================================
Fedora MinGW Packaging Guidelines
=================================

[/] Track Fedora native package versions: stay at same version, include all the same patches as the native Fedora package, and be built with the same configuration options. 
[+] Packages named by prefixing upstream package name with mingw32-
[/] Use of standard mingw RPM macros %{_mingw32_xxx}
[+] Dll dependencies expressed as mingw32(*.dll)
[/] Dependencies: %global _use_internal_dependency_generator 0 %global __find_requires %{_mingw32_findrequires} %global __find_provides %{_mingw32_findprovides}
[/] BuildRequires: mingw32-filesystem >= xx
[+] BuildArch: noarch
[/] All files are installed in %{_mingw32_sysroot}
[/] .dll in %{_mingw32_bindir}, .dll.a (and .la and .a where applicable) in %{_mingw32_libdir}
[/] No man and info files which are already in Fedora native package
[/] Static libraries in -static subpackage
[/] Stripping: %global __strip %{_mingw32_strip} %global __objdump %{_mingw32_objdump}

Not in guidelines, but seems to be policy:

[/] Debuginfo: %define __debug_install_post %{_mingw32_debug_install_post} %{_mingw32_debug_package}  
[/] Package does not contain .exe files.

===========================
Fedora Packaging Guidelines
===========================

[+] MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.
[+] MUST: The package must be named according to the Package Naming Guidelines .
[+] MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [2] .
[+] MUST: The package must meet the Packaging Guidelines .
[+] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .
[+] MUST: The License field in the package spec file must match the actual license. 
[+] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
[+] MUST: The spec file must be written in American English. 
[+] MUST: The spec file for the package MUST be legible. 
[+] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.
[+] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. 
[/] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. 
[+] MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.
[/] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
[/] MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. 
[+] MUST: Packages must NOT bundle copies of system libraries.
[/] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. 
[+] MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. 
[+] MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)
[+] MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. 
[+] MUST: Each package must consistently use macros. 
[+] MUST: The package must contain code, or permissable content. 
[/] MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). 
[+] MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. 
[/] MUST: Header files must be in a -devel package. 
[/] MUST: Static libraries must be in a -static package. 
[/] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. 
[/] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 
[+] MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.
[/] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. 
[+] MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. 
[+] MUST: All filenames in rpm packages must be valid UTF-8. 
[/] SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. 
[/] SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. 
[+] SHOULD: The reviewer should test that the package builds in mock. 

mock -r fedora-14-x86_64 ~/rpmbuild/SRPMS/cross-filesystem-65-1.fc14.src.rpm
mock -r fedora-14-i386 ~/rpmbuild/SRPMS/cross-filesystem-65-1.fc14.src.rpm

Both work.

[+] SHOULD: The package should compile and build into binary rpms on all supported architectures. 
[/] SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
[+] SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. 
[?] SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. 

We have

cross-filesystem depends on mingw32/64-filesystem
mingw32/64-filesystem depends on cross-filesystem-scripts

This seems ok (e.g. people not wanting mingw64 do not need to install
mingw64-filesystem), so I don't think this needs fixing.

[/] SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. 
[/] SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. 
[/] SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.


=================
Summary of issues
=================

1. Remove lines 173-174 in spec to get rid of the macro-in-comment warning.

2. "chmod 755" all scripts.

3. Fix subpackage descriptions (avoid macro, or use a macro that is
   explicitly defined in the spec file).

4. Add "Provides: mingw32-dlfcn = 0-0.8.r11%{?dist}" to mingw32-filesystem.

5. Not an issue, but an important comment: the package breaks the
   current mingw32 toolchain due to the switch to mingw-w64. This is
   unavoidable. Strategy for getting this into rawhide sanely is
   described here:

   http://fedoraproject.org/wiki/MinGW/CrossCompilerFramework#Roadmap

Unsure:

6. The only-non-binary-in-usr-lib rpmlint warning seems bogus (rpm
   scripts should indeed go into /usr/lib?)

7. (Too?) strictly speaking, dependencies do not follow guidelines;
   nevertheless it looks sane to me (see details in review above).

After discussion with some members of the Fedora MinGW SIG we decided to drop the 'cross-*' prefix for now and stick with 'mingw-*' as prefix. Support for Mac OS X may take a long while to get ready (possible even never because of the legal issues), so we can use 'mingw-*' for now. We've also filed a ticket at the Fedora Packaging Committee with a request to approve the (updated) draft guidelines: https://fedorahosted.org/fpc/ticket/71

Updated package:
Spec URL:
http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/mingw-filesystem.spec
SRPM URL:
http://ftd4linux.nl/contrib/mingw-filesystem-66-1.fc15.src.rpm

* Thu Mar 17 2011 Erik van Pienbroek <epienbro> - 66-1
- Renamed the package to mingw-filesystem
- Fixed rpmlint issues
- Dropped the provides: mingw32-dlfcn for now as we still
  need to discuss whether to retire it or not
- Fixed permissions of the scripts (775 -> 755)
- Fixed description of the various subpackages

I think it's okay to ignore the other rpmlint issues. The RPM files really need to be placed in /usr/lib/rpm (even for x86_64)

(In reply to comment #17)
> After discussion with some members of the Fedora MinGW SIG we decided to drop
> the 'cross-*' prefix for now and stick with 'mingw-*' as prefix. Support for
> Mac OS X may take a long while to get ready (possible even never because of the
> legal issues), so we can use 'mingw-*' for now. We've also filed a ticket at
> the Fedora Packaging Committee with a request to approve the (updated) draft
> guidelines: https://fedorahosted.org/fpc/ticket/71
> 
> Updated package:
> Spec URL:
> http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/mingw-filesystem.spec
> SRPM URL:
> http://ftd4linux.nl/contrib/mingw-filesystem-66-1.fc15.src.rpm
> 

Hi, I've been trying out the new cross compiler framework from the repository located at: http://build1.openftd.org/fedora-cross/fedora-cross.repo on Fedora 14

I got an error when trying to install mingw32-curl saying there was a missing provides(wldap32.dll). So I added Provides: mingw32(wldap32.dll) to the mingw32-filesystem package(and similarly for the mingw64-filesystem package) and after rebuilding, curl would install fine.

Looking at the changelog:

* Thu Nov 13 2008 Richard Jones <rjones> - 35-1
- Added mingw32(wldap32.dll) pseudo-provides.

So it seems like it was there at some point but nothing in the changelog indicating why it is no longer.

Anyway, hope this is relevant and helps.

Thanks for spotting this. I've just published an updated package:

Spec URL: http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/mingw-filesystem.spec
SRPM URL: http://ftd4linux.nl/contrib/mingw-filesystem-67-1.fc15.src.rpm

* Sun Apr 10 2011 Erik van Pienbroek <epienbro> - 67-1
- Merged the provides list from the Fedora mingw32-filesystem package
  Somehow various entries got lost

Agreed Tim's analysis is correct.  It is (was) a provides that
was accidentally dropped.

The new packaging guidelines have been approved in the FPC meeting of April 13: http://meetbot.fedoraproject.org/fedora-meeting/2011-04-13/fpc.2011-04-13-15.59.html

In order to comply with these guidelines, some changes have been applied in the mingw-filesystem package, so here's a new package which implements everything mentioned in the packaging guidelines.

Spec URL:
http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/mingw-filesystem.spec
SRPM URL: http://ftd4linux.nl/contrib/mingw-filesystem-68-1.fc15.src.rpm

* Thu Apr 14 2011 Erik van Pienbroek <epienbro> - 68-1
- Make the various macros compliant with the new packaging guidelines:
  https://fedorahosted.org/fpc/ticket/71
- Dropped the macro %{_mingw_default_requires} as it isn't needed
  anymore with the new guidelines

Kalev Lember has just applied a change in the current mingw32-filesystem package. To keep everything in sync, I've also applied his change to the new mingw-filesystem package:

Spec URL:
http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/mingw-filesystem.spec
SRPM URL: http://ftd4linux.nl/contrib/mingw-filesystem-69-1.fc15.src.rpm

* Sun May 01 2011 Kalev Lember <kalev> - 69-1
- Override boost library suffix in cmake toolchain file

My first review. Go easy on me!

+ OK
! needs attention

rpmlint output:
$ rpmlint mingw-filesystem mingw-filesystem-scripts mingw32-filesystem mingw64-filesystem
mingw-filesystem.noarch: W: obsolete-not-provided cross-filesystem
mingw-filesystem.noarch: W: no-documentation
mingw-filesystem-scripts.noarch: W: obsolete-not-provided cross-filesystem-scripts
mingw-filesystem-scripts.noarch: W: only-non-binary-in-usr-lib
mingw-filesystem-scripts.noarch: E: incorrect-fsf-address /usr/libexec/mingw-scripts
mingw-filesystem-scripts.noarch: E: incorrect-fsf-address /usr/share/doc/mingw-filesystem-scripts-69/COPYING
mingw32-filesystem.noarch: W: no-documentation
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/mingw32-configure /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: no-manual-page-for-binary mingw32-configure
mingw64-filesystem.noarch: W: no-documentation
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/mingw64-configure /usr/libexec/mingw-scripts
mingw64-filesystem.noarch: W: no-manual-page-for-binary mingw64-configure
4 packages and 0 specfiles checked; 2 errors, 10 warnings.

I don't think the FSF address is an issue, but you may want to correct it. The rest of the messages look harmless.

+ rpmlint output
+ The package is named according to the latest Fedora MinGW packaging guidelines
+ The spec file name matches the package base name
+ The package meets the Packaging Guidelines
+ The package is licensed with a Fedora approved license and meets the
  Licensing Guidelines.
+ The license field in the spec file matches the actual license
+ The stated license is the same as the one for the corresponding
  native Fedora package
+ The package contains the license file (COPYING)
+ Spec file is written in American English
+ Spec file is legible
? Upstream sources match sources in the srpm.
  They are all plain-text scripts, but where is upstream?
+ The package builds in koji
  http://koji.fedoraproject.org/koji/taskinfo?taskID=3053279
n/a ExcludeArch bugs filed
+ BuildRequires look sane
n/a The spec file MUST handle locales properly
n/a ldconfig in %post and %postun
+ Package does not bundle copies of system libraries
n/a Package isn't relocatable
+ Package owns all directories it creates
+ No duplicate files in %files
+ Permissions are properly set
+ Consistent use of macros
+ The 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
    Fedora MinGW guidelines allow headers in main package
n/a Static libraries should be in -static
n/a Library files that end in .so must go in a -devel package
n/a -devel must require the fully versioned base
n/a Packages should not contain libtool .la files
    Fedora MinGW guidelines allow .la files
n/a Packages containing GUI apps must include %{name}.desktop file
+ Directory ownership sane
+ Filenames are valid UTF-8

If you want to, you can also remove the %clean section and the BuildRoot lines
which are also no longer required in current Fedora releases, before importing
the package to git.
http://fedoraproject.org/wiki/PackagingGuidelines#.25clean

I'll approve it once I know where the upstream is. I feel a comment should be put where a VC system containing the scripts is. If there is no VC system then I guess it passes. I don't see a guideline that prohibits script-only packages.

Could you please rebase the rpm changelog on top of the current mingw32-filesystem (and keep rebasing it when there are new changes to mingw32-filesystem)? It's a bit hard to see right now what changes were accidental and what was intended. When importing the rename into Fedora, I think the changes should apply cleanly on the existing package, without rewriting much of the (Fedora package's) history.

Comparing the package to the existing mingw32-filesystem, the following symlinks are no longer there. Is it intentional?
/usr/bin/mingw32-cmake
/usr/bin/mingw32-make
/usr/bin/mingw32-pkg-config
/usr/bin/mingw32-qmake-qt4


> Obsoletes:      cross-filesystem <= 67-1

<= comparision doesn't work as intended here, it's better to use 'Obsoletes:      cross-filesystem < 67-2' to take into account the .fcXX prefixes in release.


> Requires:       setup
> Requires:       rpm
> Requires:       rpmlint >= 0.85-2

These requires should surely be in the -scripts subpackage.

Thank you both for reviewing this!

Michael:
Upstream for this package is the Fedora MinGW SIG. We don't have a separate VCS as we use the Fedora VCS for this

The FSF rpmlint warnings have just been fixed

I've kept the %clean and BuildRoot lines in so this package can also be built on EL-6. Perhaps those lines can be dropped for EL-6 packages as well, but I couldn't find any documentation about that yet.

Kalev:
This diverge in changelog history was caused by the fact that a long time ago (back in May 2010) I forked the mingw32 toolchain to add mingw-w64 support. Recently I tried to merge everything back together but apparently some things got lost. I've just re-added the wrapper scripts you mentioned. Wrapper scripts for the mingw-w64 part have also just been added. 

The original changelog has also been merged now

The obsoletes and requires tags should be good now


Spec URL:
http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/mingw-filesystem.spec
SRPM URL: http://ftd4linux.nl/contrib/mingw-filesystem-70-1.fc15.src.rpm

* Fri May 06 2011 Erik van Pienbroek <epienbro> - 70-1
- Use the correct FSF-address in some scripts
- Moved some Requires tags to the mingw-filesystem-scripts subpackage
- Fixed the Obsoletes tags
- Re-added the wrapper scripts mingw32-cmake, mingw32-make,
  mingw32-pkg-config and mingw32-qmake-qt4
- Added the wrapper scripts mingw32-cmake, mingw64-make,
  mingw64-pkg-config, i686-w64-mingw32-pkg-config,
  x86_64-w64-mingw32-pkg-config and mingw64-qmake-qt4

The Provides: mingw32() and Provides: mingw64() would probably look better in alphabetical order.


Sorry for not noticing it earlier, but the Requires: setup, rpm, rpmlint and BuildRequires: rpmlint were all dropped from mingw32-filesystem a while ago:
http://pkgs.fedoraproject.org/gitweb/?p=mingw32-filesystem.git;a=commit;h=d8bcc2f5ac2ba0cde140fe0682286dfaf5c2a2fb
http://pkgs.fedoraproject.org/gitweb/?p=mingw32-filesystem.git;a=commit;h=7034ac899f074b4bed02090fb271ecb10d7266fb

I think the rationale for NOT Requiring 'setup' and 'rpm' was that these are all so low level packages that they are in all Fedora installations and therefore it's not worth requiring them, similar to not requiring the 'filesystem' package.

With rpmlint there's a different story. Rpmlint used to be required dependency because we install a file in /etc/rpmlint/. However, directory ownership guidelines were updated a while ago and now it's perfectly fine to have multiple directory ownership on /etc/rpmlint/ in order to avoid needlessly dragging in the rpmlint package.
http://fedoraproject.org/wiki/PackagingGuidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function


I'd suggest the following changes:

-BuildRequires:  rpmlint >= 0.85-2

-Requires:       setup
-Requires:       rpm
-Requires:       rpmlint >= 0.85-2

+%dir %{_sysconfdir}/rpmlint
 %config(noreplace) %{_sysconfdir}/rpmlint/mingw-rpmlint.config

(In reply to comment #26)
> +%dir %{_sysconfdir}/rpmlint
>  %config(noreplace) %{_sysconfdir}/rpmlint/mingw-rpmlint.config

Thanks for the help, Kalev.

I think for the rpmlint folder simply:
%{_sysconfdir}/rpmlint
is enough. (no %dir)

After the above fixes are applied I'll give it one more review.

For the rpmlint folder I didn't use one global %{_sysconfdir}/rpmlint entry as the file which is placed in that folder isn't a regular file, but a %config file.

Spec URL:
http://svn.openftd.org/svn/fedora_cross/mingw-filesystem/mingw-filesystem.spec
SRPM URL: http://ftd4linux.nl/contrib/mingw-filesystem-71-1.fc15.src.rpm

* Fri May 06 2011 Erik van Pienbroek <epienbro> - 71-1
- Dropped the BR and R for setup, rpm and rpmlint as they aren't needed anymore
- Own the folder %{_sysconfdir}/rpmlint (to avoid dependency on rpmlint)
- Sorted the list with mingw32(xxx) and mingw64(xxx) provides for improved readability

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3054732

Rpmlint:
$ rpmlint mingw-filesystem mingw-filesystem-scripts mingw32-filesystem mingw64-filesystem
mingw-filesystem.noarch: W: obsolete-not-provided cross-filesystem
mingw-filesystem.noarch: W: no-documentation
mingw-filesystem-scripts.noarch: W: obsolete-not-provided cross-filesystem-scripts
mingw-filesystem-scripts.noarch: W: only-non-binary-in-usr-lib
mingw-filesystem-scripts.noarch: E: incorrect-fsf-address /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: no-documentation
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/mingw32-qmake-qt4 /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/mingw32-cmake /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/mingw32-configure /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/i686-w64-mingw32-pkg-config /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/mingw32-pkg-config /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: dangling-symlink /usr/bin/mingw32-make /usr/libexec/mingw-scripts
mingw32-filesystem.noarch: W: no-manual-page-for-binary mingw32-make
mingw32-filesystem.noarch: W: no-manual-page-for-binary i686-w64-mingw32-pkg-config
mingw32-filesystem.noarch: W: no-manual-page-for-binary mingw32-qmake-qt4
mingw32-filesystem.noarch: W: no-manual-page-for-binary mingw32-cmake
mingw32-filesystem.noarch: W: no-manual-page-for-binary mingw32-configure
mingw32-filesystem.noarch: W: no-manual-page-for-binary mingw32-pkg-config
mingw64-filesystem.noarch: W: no-documentation
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/mingw64-qmake-qt4 /usr/libexec/mingw-scripts
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/mingw64-configure /usr/libexec/mingw-scripts
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/mingw64-make /usr/libexec/mingw-scripts
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/mingw64-pkg-config /usr/libexec/mingw-scripts
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/mingw64-cmake /usr/libexec/mingw-scripts
mingw64-filesystem.noarch: W: dangling-symlink /usr/bin/x86_64-w64-mingw32-pkg-config /usr/libexec/mingw-scripts
mingw64-filesystem.noarch: W: no-manual-page-for-binary mingw64-pkg-config
mingw64-filesystem.noarch: W: no-manual-page-for-binary mingw64-make
mingw64-filesystem.noarch: W: no-manual-page-for-binary x86_64-w64-mingw32-pkg-config
mingw64-filesystem.noarch: W: no-manual-page-for-binary mingw64-qmake-qt4
mingw64-filesystem.noarch: W: no-manual-page-for-binary mingw64-cmake
mingw64-filesystem.noarch: W: no-manual-page-for-binary mingw64-configure
4 packages and 0 specfiles checked; 1 errors, 30 warnings.

Looks like there's still one FSF address issue. The man pages are obvious dupes of native tools so they aren't required. It looks good to me.

APPROVED

New Package SCM Request
=======================
Package Name: mingw-filesystem
Short Description: MinGW cross compiler base filesystem and environment
Owners: epienbro rjones kalev
Branches: 
InitialCC:

Git done (by process-git-requests).

mingw-filesystem-69-15.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mingw-filesystem-69-15.fc17

mingw-filesystem-69-15.fc17 has been pushed to the Fedora 17 testing repository.

mingw-filesystem-69-15.fc17 has been pushed to the Fedora 17 stable repository.

Package Change Request
======================
Package Name: mingw-filesystem
New Branches: el6
Owners: epienbro
InitialCC:

Git done (by process-git-requests).