Re: [Mingw-w64-public] Mass rebuild report for March 08 2015

2015-03-08 Thread JonY
On 3/9/2015 01:14, Erik van Pienbroek wrote: > >> mingw-qt-4.8.6-6 >> Package owner: sailer >> Time to build: 26 minutes, 14 seconds >> Build logs: >> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-qt-4.8.6-6 > > Known i

Re: [Mingw-w64-public] Mass rebuild report for March 08 2015

2015-03-08 Thread Michael Cronenworth
econds >> >Build >> > logs:http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-wine-gecko-2.36-1 > /builddir/build/BUILD/mingw-wine-gecko-2.36/wine_gecko-2.36-x86/dist/lib/libdbm.a(h_bigkey.o):h_bigkey.c:(.text+0x0): > multiple definition of `_findfirst64i32'

Re: [Mingw-w64-public] Mass rebuild report for March 08 2015

2015-03-08 Thread Erik van Pienbroek
ro > Time to build: 55 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150308/mingw-angleproject-0-0.11.git.30d6c2.20141113 + gyp -D OS=win -D TARGET=win32 -D MSVS_VERSION= --depth . -I ../build/common.gypi ../src/angle.gyp Traceback (most recent c

[Mingw-w64-public] Mass rebuild report for March 08 2015

2015-03-08 Thread Erik van Pienbroek
This is a report for the 20150308 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 v4.0rc3 * binutils 2.25 * gcc 5

Re: [Mingw-w64-public] [PATCH] update ws2 defs for wack 3.4

2015-03-08 Thread Kai Tietz
Well, so it is fine for me. Thanks, Kai 2015-03-07 17:50 GMT+01:00 Martell Malone : > typo in previous email > It was meant to say > > "vlc is currently building without setting" > > On Sat, Mar 7, 2015 at 4:49 PM, Martell Malone > wrote: >> >> Hi Kai, >> >> This is for vlc, >> winsock is now av

Re: [Mingw-w64-public] [PATCH] legacythreadapi: Fixup and correct header name

2015-03-08 Thread Kai Tietz
Well, that no other project uses already this header (and we can't be sure anyway here) is no reason for renaming it AFAICS. I see the point that this header might be now present under a different name, so why not adding this new header by including the old one then? By this we don't cause any ha