May 2013 - mingw - Fedora Mailing-Lists

[Bug 894834] Review Request: mingw-gtkglext - OpenGL Extension to GTK+

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=894834 --- Comment #19 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> --- Section added to the draft MinGW packaging guidelines on what files not to package: https://fedoraproject.org/wiki/PackagingDrafts/MinGWCrossCompiler#Files_w... -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=K3ObahePen&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

[Bug 894834] Review Request: mingw-gtkglext - OpenGL Extension to GTK+

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=894834 --- Comment #18 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> --- I was just working on updating the MinGW packaging guidelines and this looks like a candidate which can also be added to the guidelines: autoconf files don't need to be bundled in mingw packages when their native counterparts also provide the same autoconf files -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=8rrbFXHqkA&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

[Bug 894834] Review Request: mingw-gtkglext - OpenGL Extension to GTK+

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=894834 --- Comment #17 from Kalev Lember <kalevlember(a)gmail.com> --- Fair enough, sounds like they don't really get used then. I also did a little bit digging and found the following in /usr/bin/aclocal. We don't set ACLOCAL_PATH so it will only use the hardcoded system dir. # Include paths for searching macros. We search macros in this order: # user-supplied directories first, then the directory containing the # automake macros, and finally the system-wide directories for # third-party macros. # @user_includes can be augmented with -I. # @automake_includes can be reset with the '--automake-acdir' option. # @system_includes can be augmented with the 'dirlist' file or the # ACLOCAL_PATH environment variable, and reset with the '--system-acdir' # option. my @user_includes = (); my @automake_includes = ("/usr/share/aclocal-$APIVERSION"); my @system_includes = ('/usr/share/aclocal'); -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fyl0Ln6eik&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

[Bug 894834] Review Request: mingw-gtkglext - OpenGL Extension to GTK+

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=894834 --- Comment #16 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> --- Typo in paths: /usr/share/data/aclocal --> /usr/share/aclocal /usr/i686-w64-mingw32/sys-root/mingw/share/data/aclocal --> /usr/i686-w64-mingw32/sys-root/mingw/share/aclocal -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NzSMT37ihz&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

[Bug 894834] Review Request: mingw-gtkglext - OpenGL Extension to GTK+

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=894834 --- Comment #15 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> --- (In reply to comment #14) > (In reply to comment #13) > > * The autoconf files which are created by this package can be removed > > (%{mingw32_datadir}/aclocal/* and %{mingw64_datadir}/aclocal/*) as they're > > duplicate files which are already provided by their native counterpart > > I have a nagging feeling that there must be some case where they are useful. > > I would suspect the mingw aclocal files get included when the 'configure' > script tries to rebuild itself after the configure.ac timestamp has changed. > Not all packages do that, it depends on if/how the AM_MAINTAINER_MODE macro > is used. > > (This case above can be "fixed" by forcing a rebuild of 'configure' with the > native aclocal files by running autoreconf before %mingw_configure.) I understand the situation you're trying to explain, but afaik autoconf/automake is only aware of /usr/share/data/aclocal. There are no references to /usr/i686-w64-mingw32/sys-root/mingw/share/data/aclocal in our mingw macros so how is autofoo ever supposed to be aware of files in these folders? -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dSbkRs053S&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

[Bug 894834] Review Request: mingw-gtkglext - OpenGL Extension to GTK+

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=894834 Kalev Lember <kalevlember(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kalevlember(a)gmail.com --- Comment #14 from Kalev Lember <kalevlember(a)gmail.com> --- (In reply to comment #13) > * The autoconf files which are created by this package can be removed > (%{mingw32_datadir}/aclocal/* and %{mingw64_datadir}/aclocal/*) as they're > duplicate files which are already provided by their native counterpart I have a nagging feeling that there must be some case where they are useful. I would suspect the mingw aclocal files get included when the 'configure' script tries to rebuild itself after the configure.ac timestamp has changed. Not all packages do that, it depends on if/how the AM_MAINTAINER_MODE macro is used. (This case above can be "fixed" by forcing a rebuild of 'configure' with the native aclocal files by running autoreconf before %mingw_configure.) -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=uefEYIfqd9&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

[Bug 894834] Review Request: mingw-gtkglext - OpenGL Extension to GTK+

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=894834 --- Comment #13 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> --- * The autoconf files which are created by this package can be removed (%{mingw32_datadir}/aclocal/* and %{mingw64_datadir}/aclocal/*) as they're duplicate files which are already provided by their native counterpart * Please replace %{mingw32_libdir}/pkgconfig/*.pc and %{mingw64_libdir}/pkgconfig/*.pc with the individual files (as general rule of thumb: try to prevent the use of wildcards in filelists) * Please add a comment to each patch explaining what the patch does and whether is has already been proposed upstream (reference to upstream bug tracker) -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=0LxeOr0QVy&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

[Bug 957346] Review Request: mingw-physfs - MinGW compiled physfs library to provide abstract access to various archives

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=957346 --- Comment #3 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> --- It looks like physfs contains a bundled copy of lzma. According to the packaging guidelines it isn't allowed to use bundled copies of external libraries. Now there are two options on how to continue: 1. Strip the lzma pieces from physfs (thus also removing lzma support in the library itself) 2. Create a dedicated mingw-lzma package and have this package use it A choice from one of these options needs to be made before this package can be approved -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ZVafF6BScF&a=cc_unsubscribe

11 years, 1 month

1
0
0 / 0

Cross-compiling with cmake?

by Steven Boswell II

Hello all! Lately I've been hell-bent to port several packages to MinGW. So far I have flac, kde-filesystem, libid3tag, libmad, libsamplerate, libsndfile, portaudio, portmidi, protobuf, and taglib built and running. (My goal is to make all of Mixxx's dependencies -- see http://www.mixxx.org/ for more information on this open-source DJing tool.) Mixxx is up and running on MS Windows when built with these dependent packages! Now I'm trying to build phonon (so that I can enable some additional Mixxx features), and I ran into a problem -- its build is using the host's cmake configuration files! In phonon-4.6.0/phonon/CMakeLists.txt, after running "macro_optional_find_package(PulseAudio 0.9.15)", PULSEAUDIO_FOUND is TRUE, but none of the other variables are set, e.g. PULSEAUDIO_INCLUDE_DIR, PULSEAUDIO_LIBRARY, and PULSEAUDIO_MAINLOOP_LIBRARY. It shouldn't even be finding the host's cmake configuration during a cross-compile! The problem seems to be in /usr/share/mingw/Toolchain-mingw{32,64}.cmake -- it looks like it needs a "SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)" line. Also, it seems like there would have to be mingw{32,64}-cmake and mingw64-cmake packages, just to provide /usr/share/cmake/Modules -- executables wouldn't be necessary. What do you think? Steven Boswell

11 years, 1 month

2
3
0 / 0

Broken dependencies: mingw32-libpng

by Fedora Koji Build System

mingw32-libpng has broken dependencies in the epel-6 tree: On ppc64: mingw32-libpng-1.2.37-3.el6.noarch requires mingw32-runtime mingw32-libpng-1.2.37-3.el6.noarch requires mingw32-filesystem >= 0:63 mingw32-libpng-1.2.37-3.el6.noarch requires mingw32(zlib1.dll) mingw32-libpng-1.2.37-3.el6.noarch requires mingw32(msvcrt.dll) mingw32-libpng-1.2.37-3.el6.noarch requires mingw32(kernel32.dll) Please resolve this as soon as possible.

11 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw May 2013