On 05/24/2011 04:06 PM, Farkas Levente wrote: anybody? what's the mingw- and mingw32 packages? do you plan to support rhel-6? does the current infrastructure use any special feature (like rpm-4.9) which is not available on el6? i see on http://svn.openftd.org/viewvc/Fedora%20Cross%20Compiler%20Framework/ there're both mingw and mingw32 pacakges why? do you plan to add epel-6 support for these packages? we need mingw support on rhel-6 so we'd like to create packages for all gstreamer related packages which can be used on rhel-6. thanks in advance. regards. -- Levente "Si vis pacem para bellum!"

On 05/25/2011 03:44 PM, Kalev Lember wrote: my biggest problem now that you start to rewrite all fedora packages to support only fedora. the template is ok but as you remove all 'not necessary part' from spec. it's no longer build on rhel-6. since first i've to recreate the whole mingw infrastructure for rhel-6. so i'd like to update gcc, binutils, filesystem etc. not to mention those dozens of other basic packages. and as you remove such lines: ------------------------------ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) ------------------------------ at the beginning of %install ------------------------------ rm -rf $RPM_BUILD_ROOT ------------------------------ ------------------------------ %clean rm -rf $RPM_BUILD_ROOT ------------------------------ and yes i know these are no longer required on fedora, but unfortunately thay are required on rhel. these are usually 2-3 lines of changes, but with these changes these src.rpms no longer be able to rebuild on rhel. which imho not worth. this only cause a lots of work anyone else. with these small changes all target's spec can be keep in sync and an everybody can enjoy others help. in the current case it's just cause a lots of work for others... now as rh start to support mingw: http://rhn.redhat.com/errata/RHEA-2011-0671.html wouldn't it be possible to keep these packages in sync? regards. -- Levente "Si vis pacem para bellum!"

On 05/30/2011 08:42 PM, Erik van Pienbroek wrote: but all other packages can... anyway your repo: http://svn.openftd.org seems to be down:-( -- Levente "Si vis pacem para bellum!"

On 05/24/2011 05:06 PM, Farkas Levente wrote: Hi Farkas, Glad to have you back, there have indeed been some new developments. Erik has been working on switching over from mingw.org toolchain to the mingw-w64 one. Among other things, the mingw-w64 toolchain has a much wider win32 API coverage and supports both 32 bit and 64 bit Windows targets. The Fedora Packaging Committee has already approved guidelines for the mingw-w64 toolchain, but the guidelines are currently on hold until the toolchain is actually imported in Fedora (there are some possible legal problems with the new toolchain that are being investigated). Right now the current guidelines are the ones under Packaging:MinGW [1] and the ones under Packaging:MinGW_Future [2] are on hold; not sure when that might change. One of the things that changes with the "MinGW_Future" guidelines is that the source packages are going to move into mingw- namespace and the binary packages are going to be named mingw32- and mingw64- respectively. To ease the transition and to avoid having to rename packages from mingw32- to mingw- in the future when the "MinGW_Future" guidelines are activated, the FPC recently decided to also allow new source packages (keep in mind that we are still using the "old" guidelines) to be named mingw-. The example spec file [3] covers how to do that. Another development is the mingw32-filesystem we have in rawhide now supports RPM 4.9 new "fileattr" dependency generator, which means that packages can now drop the following boilerplate macros if they want to: %global _use_internal_dependency_generator 0 %global __find_requires %{_mingw32_findrequires} %global __find_provides %{_mingw32_findprovides} Nothing changes for existing packages but it gives the option to remove these lines for the packagers that want to do so. I'm also planning to eventually backport the mingw32-filesystem changes to F15, so that people who need to keep rawhide and F15 spec files in sync, are able to do so. But F15 is already out and we should strictly limit the changes we are doing and concentrate new development in rawhide. [1] https://fedoraproject.org/wiki/Packaging:MinGW [2] https://fedoraproject.org/wiki/Packaging:MinGW_Future [3] https://fedoraproject.org/wiki/Packaging:MinGW#Example_Specfile Hope this helps, Kalev