EPEL Intend to remove all mingw32 packages from 5
Hi, On behalf of the Fedora MinGW SIG I would like to announce that we intend to remove all mingw32 packages from EPEL5. These packages were added to EPEL5 back in 2008 and were never properly maintained. These packages are ancient by now and have multiple known security vulnerabilities. Therefore these packages shouldn't be used any more. More details about the situation can be found at https://lists.fedoraproject.org/pipermail/mingw/2014-August/008273.html Here is the complete list of packages which we plan to remove from EPEL5 mingw32-atk mingw32-binutils mingw32-bzip2 mingw32-cairo mingw32-cppunit mingw32-crossreport mingw32-curl mingw32-dirac mingw32-dlfcn mingw32-expat mingw32-filesystem mingw32-fontconfig mingw32-freeglut mingw32-freetype mingw32-gcc mingw32-gdbm mingw32-gettext mingw32-glib2 mingw32-gnutls mingw32-gtk2 mingw32-gtk-vnc mingw32-iconv mingw32-jasper mingw32-libffi mingw32-libgcrypt mingw32-libgpg-error mingw32-libjpeg mingw32-liboil mingw32-libpng mingw32-libxml2 mingw32-nsis mingw32-nsiswrapper mingw32-openssl mingw32-pango mingw32-pdcurses mingw32-pixman mingw32-pthreads mingw32-readline mingw32-runtime mingw32-SDL mingw32-sqlite mingw32-termcap mingw32-w32api mingw32-webkitgtk mingw32-zlib Unless somebody objects I'll ask releng to remove these packages. Regards, Erik van Pienbroek Fedora MinGW SIG ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
Christophe Fergeau schreef op do 24-01-2013 om 11:40 [+0100]: On Sat, Jan 12, 2013 at 07:59:24PM +0100, Erik van Pienbroek wrote: The mingw-w64 compiler which is currently in Fedora should be capable of building virtio as the DDK pieces are also bundled (in the folder /usr/i686-w64-mingw32/sys-root/mingw/include/ddk). I just took a quick attempt to manually compile these drivers using the mingw-w64 compiler in Fedora and I think it should be possible. Do you happen to have a log of these attempts? You just quickly passed the driver C files to mingw-gcc, or did you do something more sophisticated? I think it would be easier if we could discuss this on IRC: #fedora-mingw @ FreeNode. This subject is a bit off-topic for this list. Regards, Erik van Pienbroek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
Jaroslav Reznik schreef op wo 16-01-2013 om 12:35 [-0500]: See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details. Once gcc-4.8.0-* is built into Fedora, after a few days or weeks a mass rebuild should be performed. I see that gcc 4.8 was just imported in rawhide some hours ago. What's the plan next? Will the rebuilds happen in a side-tag or in the master branch and when is it scheduled? We on the Fedora MinGW side are ready to import mingw-gcc 4.8 in rawhide as well and we would like to know what's going to happen next so we make the necessary preparations. Introducing mingw-gcc 4.8 is a bit more painful for us at the moment as upstream has decided to use a different exception handling model for the win64 target starting with gcc 4.8 (SEH instead of SjLj). Therefore various packages need to be rebuilt soon after the introduction of mingw-gcc 4.8 to avoid broken dependencies. Regards, Erik van Pienbroek Fedora MinGW SIG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
Jaroslav Reznik schreef op wo 16-01-2013 om 12:35 [-0500]: As decided by FESCo on 2012-12-05 meeting, all proposed Features are required to pass through the community review by announcing them on devel-announce list. FESCo votes on new features no sooner than a week from the announcement. = Features/GCC48 = https://fedoraproject.org/wiki/Features/GCC48 I would also like to mention that we at the Fedora MinGW SIG are also preparing on introducing GCC 4.8 for our win32/win64 cross-compiler (mingw-gcc). A test mass rebuild of all our 135 mingw-* packages is currently being performed. I'll report the results back to the Fedora MinGW and upstream mingw-w64 mailing lists once this test mass rebuild is completed so we can investigate and resolve the remaining issues. We plan on introducing mingw-gcc 4.8 in rawhide shortly after the native gcc package gets updated to 4.8. That way we'll be ready before the mass rebuild of all Fedora packages starts. Regards, Erik van Pienbroek Fedora MinGW SIG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
Richard W.M. Jones schreef op za 12-01-2013 om 01:24 [+]: Do the virtio drivers now build using the mingw-* stack in Fedora? IIRC this should be possible now that Fedora has switched over to using mingw-w64. The git repo for the virtio drivers only contains msvc project files, so in order to get the virtio drivers built using the mingw-w64 cross-compiler would require new Makefile's to be written. The mingw-w64 compiler which is currently in Fedora should be capable of building virtio as the DDK pieces are also bundled (in the folder /usr/i686-w64-mingw32/sys-root/mingw/include/ddk). I just took a quick attempt to manually compile these drivers using the mingw-w64 compiler in Fedora and I think it should be possible. Right now I've got some errors like redefinition of 'struct foo' in some of the DDK headers, but I'm sure upstream mingw-w64 devs (and indirectly the ReactOS project) would be interested in helping out with this. Regards, Erik van Pienbroek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Greg Hellings schreef op zo 27-05-2012 om 14:23 [-0500]: As per the encouragement on the wiki, just wanted to throw out a greeting. I've been a Linux user for a bit over 10 years now, bouncing between Fedora and Ubuntu depending on the application. The recent addition of the MinGW toolkit into Fedora 17 has brought me back, as I had been trying to leverage that into Ubuntu on my own. So, here I am to hopefully join in the effort with the Fedora MinGW team. Hi Greg, Welcome aboard the Fedora train! The Fedora MinGW SIG is always looking for people to help maintaining packages in Fedora. You've already found out our IRC channel and are hanging out there often which is very good. If you've got any questions, feel free to ask them Kind regards, Erik van Pienbroek Fedora MinGW SIG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lazarus is lacking crosscompiling ability(?)
Heiko Adams schreef op vr 02-12-2011 om 01:40 [+0100]:
Hi,
I'm not very experienced in crosscompiling applications but as far as
I understand lazarus wiki page for that topic[1], lazarus is able to
compile i.e. windows binaries on linux.
I'm currently in a situation where this feature would be very helpful
because it gets boring and costs some time for me to start my windows
vm just for a new build of my applications. I've allready filed a
bug[2] for making feodra's lazarus package able to compile windows
binaries but there isn't any reaction so far.
So can anyone give me a hint how I can compile my lazarus applications
for windows on my linux box without using a windows vm and why the
lazarus package seems to miss the neccessary files for doing this out
of the box?
[1]
http://wiki.lazarus.freepascal.org/Cross_compiling_for_Win32_under_Linux
[2] https://bugzilla.redhat.com/show_bug.cgi?id=756486
Forwarding your mail to the Fedora MinGW mailing list.
The Fedora MinGW SIG currently has an infrastructure ready which allows
easy cross compilation of packages for the win32 target using the
mingw.org toolchain.
I'm not really familiar with lazarus, but I'm willing to help out
wherever I can. I just took a quick look at the wiki page you mentioned.
As I see it now there are 3 steps involved in builder a lazarus cross
compiler for the win32 target:
1. build binutils for the win32 target
2. build the lazarus fpc compiler for the win32 target
3. configure the lazarus fpc.cfg
Step 1 is already provided by the Fedora MinGW SIG. We've got the
mingw32-binutils package which contains the various binutils tools for
the win32 target. The only real differences I've found so quick are the
name of the build target and the installation location.
In the fpc buildcrossbinutils script the build target 'i686-mingw32' is
used while all Fedora MinGW packages use 'i686-pc-mingw32' (and once the
mingw-w64 toolchain is approved for inclusion in Fedora this will be
changed to 'i686-w64-mingw32' and 'x86_64-w64-mingw32', see [1] for more
details about that). The mingw32-binutils binaries are all placed in
%{_bindir}.
For step 2 I think you need to extract the interesting instructions from
the lazarus buildcrosssnaphot script and merge them in a .spec file. I
think it should be pretty straightforward to do so.
Step 3 doesn't tell me much, but I guess the current lazarus package
ships a fpc.cfg and this file needs to be changed to be aware of the
win32 fpc target.
If you need any help with the above steps you can always join our IRC
channel at #fedora-mingw on FreeNode and we'll try to help you as much
as possible.
Kind regards,
Erik van Pienbroek
Fedora MinGW SIG
[1]: https://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shrinking terminals in rawhide
Matthias Clasen schreef op ma 17-01-2011 om 10:14 [-0500]: On Fri, 2011-01-14 at 13:40 -0500, Matthew Miller wrote: On Fri, Jan 14, 2011 at 12:05:44PM -0500, Matthias Clasen wrote: for everybody who is annoyed by the recent trend of shrinking terminals in rawhide: I've just pushed a fixed for vte3 through koji. Problem better, but not gone. Now clicking on a window border (bottom or side), causes the whole thing to shrivel up. Not happening here. What wm ? I'm having this issue on KDE using KWin (yeah, I prefer gnome-terminal over Konsole because of it's copy/paste behaviour). The package vte3-0.27.4-2.fc15.x86_64 is installed (which is the latest package available in Koji) Regards, Erik van Pienbroek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
Panu Matilainen schreef op vr 26-11-2010 om 13:20 [+0200]:
In particular, I'm interested in feedback on the new, pluggable and
enhanced dependency extration system. Documentation is scarce at the
moment but some background and examples can be found here:
http://laiskiainen.org/blog/?p=35
All mingw32 packages in Fedora contain these set of instructions in
the .spec files:
%global _use_internal_dependency_generator 0
%global __find_requires %{_mingw32_findrequires}
%global __find_provides %{_mingw32_findprovides}
Does this new dependency extraction system make these kind of
instructions obsolete?
If I understand your blog entry correctly then we (the Fedora MinGW SIG)
are recommended to use something like this:
%__mingw32_provides %{_mingw32_findprovides}
%__mingw32_requires %{_mingw32_findrequires}
Is this correct or do you recommend something different?
The macros %{_mingw32_findrequires} and %{_mingw32_findprovides} are
mentioned in the file /etc/rpm/macros.mingw32 which is part of the
mingw32-filesystem package. Both refer to a small shell script which
uses the i686-pc-mingw32-objdump tool to extract dependency information.
Kind regards,
Erik van Pienbroek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
Panu Matilainen schreef op di 30-11-2010 om 22:10 [+0200]:
On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
If I understand your blog entry correctly then we (the Fedora MinGW SIG)
are recommended to use something like this:
%__mingw32_provides %{_mingw32_findprovides}
%__mingw32_requires %{_mingw32_findrequires}
Is this correct or do you recommend something different?
That alone wont do anything at all, to create a new file attribute
called mingw32 you'd add a file like this to a suitable package,
mingw32-filesystem probably:
/usr/lib/rpm/fileattrs/mingw32.attr:
%__mingw32_requires /usr/lib/rpm/mingw32-find-requires.sh
%__mingw32_provides /usr/lib/rpm/mingw32-find-provides.sh
%__mingw32_magic ^PE32 executable for MS Windows.* 80386 32-bit$
The magic rule is based on what 'file -b file' outputs for mingw32
executables and dll's - the above includes both, but you can make it
tighter to only include DLL's or have different extractors for DLL's and
EXE's by creating two rules instead of just one etc. Or if libmagic
strings aren't good (fakedll binaries from Wine would match the above
rule), path based regexes can be used too. It all depends on what makes
sense in a given scenario.
You could also easily have a mingw32-specific pkg-config dependency
extractor which uses a different namespace than the regular pkgconfig(foo)
and only activates on .pc files from the mingw32 sys-root directory.
And with necessary mingw32-specific .attr files in place through
buildrequires, there's no need for override kludges in each and every
mingw32 spec.
Ah yes, thanks for the detailed information. This sure looks interesting
for us! I'll try to play around a bit with this in a mock environment
and see if it's possible to update our packaging guidelines to make use
of it.
Regards,
Erik van Pienbroek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
