In order to have wine-gecko build on F18 it needs at least the following upstream commits.
http://sourceforge.net/p/mingw-w64/code/5500/ http://sourceforge.net/p/mingw-w64/code/5505/ http://sourceforge.net/p/mingw-w64/code/5512/ http://sourceforge.net/p/mingw-w64/code/5530/ http://sourceforge.net/p/mingw-w64/code/5569/ http://sourceforge.net/p/mingw-w64/code/5589/ http://sourceforge.net/p/mingw-w64/code/5610/ http://sourceforge.net/p/mingw-w64/code/5611/
Also needs mfuuid (commit 5505) and wmcodecdspuuid (commit 5610) libraries built to link against.
Thanks, Michael
Michael Cronenworth schreef op do 11-07-2013 om 14:42 [-0500]:
In order to have wine-gecko build on F18 it needs at least the following upstream commits.
http://sourceforge.net/p/mingw-w64/code/5500/ http://sourceforge.net/p/mingw-w64/code/5505/ http://sourceforge.net/p/mingw-w64/code/5512/ http://sourceforge.net/p/mingw-w64/code/5530/ http://sourceforge.net/p/mingw-w64/code/5569/ http://sourceforge.net/p/mingw-w64/code/5589/ http://sourceforge.net/p/mingw-w64/code/5610/ http://sourceforge.net/p/mingw-w64/code/5611/
Also needs mfuuid (commit 5505) and wmcodecdspuuid (commit 5610) libraries built to link against.
Hi Michael,
Thanks for this list. I've tried to backport these commits and get wine-gecko built on F18. Unfortunately it turned out that a lot more commits are needed.
To get wine-gecko 2.21 built on F18 the following mingw-w64 commits are needed:
For mingw-headers: r5475, r5479, r5484, r5497, r5498, r5499, r5500 r5503, r5504, r5510, r5511, r5512, r5527, r5530 r5545, r5552, r5569, r5587, r5589, r5602, r5603 r5604, r5605, r5606, r5607, r5608, r5609
For mingw-crt: r5505, r5610, r5611
As this is a lot more than an average backport I'm unsure what route to take. Of course I could push updated packages to F18 with these backported commits, but as the number of patches is quite high we have the risk of unexpected regressions. Another solution would be to push the version of mingw-headers/mingw-crt which is currently in F19 to F18 (which is regression-free afaik).
For comparison, here's the difference between F18 and F19: Fedora 18: 20121110 snapshot, r5451 Fedora 19: 20130614 snapshot, r5904
What are your opinions about pushing a more modern mingw-w64 snapshot to Fedora 18?
As Fedora 17 is about to become EOL soon I don't have any plans to push updated packages there any more
Regards,
Erik
On 07/13/2013 01:06 PM, Erik van Pienbroek wrote:
For comparison, here's the difference between F18 and F19: Fedora 18: 20121110 snapshot, r5451 Fedora 19: 20130614 snapshot, r5904
What are your opinions about pushing a more modern mingw-w64 snapshot to Fedora 18?
If we don't update, F18 will not be able to have an updated wine package. I would not mind this one-time exception to update F18's snapshot. If you have packages in updates-testing I can build several applications against it and insure there are no regressions.
As Fedora 17 is about to become EOL soon I don't have any plans to push updated packages there any more
I agree.
Michael Cronenworth schreef op za 13-07-2013 om 17:51 [-0500]:
On 07/13/2013 01:06 PM, Erik van Pienbroek wrote:
For comparison, here's the difference between F18 and F19: Fedora 18: 20121110 snapshot, r5451 Fedora 19: 20130614 snapshot, r5904
What are your opinions about pushing a more modern mingw-w64 snapshot to Fedora 18?
If we don't update, F18 will not be able to have an updated wine package. I would not mind this one-time exception to update F18's snapshot. If you have packages in updates-testing I can build several applications against it and insure there are no regressions.
In the last couple of days I've been working with upstream mingw-w64 developers to resolve all known build failures (with exception of the ones which are caused by winpthreads). We're currently at a point where we feel confident with the current state. I plan on doing one more test mass rebuild (without winpthreads) to make sure all build failures are resolved now.
Here's what I would like to propose:
1. Update mingw-w64 in rawhide and f19-updates-testing to today's snapshot 2. Kick off a test mass rebuild without winpthreads to make sure there are no more build failures 3. Once we've got a confirmation that all build failures are really resolved, push these updated mingw-w64 packages to f18-updates (with buildroot overrides in place for the time the packages have to spend in updates-testing) 4. Afterwards the wine maintainer can build and push updated versions of mingw-wine-gecko and wine itself to f18
Does this sound like a good plan to you folks?
Regards,
Erik van Pienbroek
Erik van Pienbroek schreef op zo 21-07-2013 om 16:12 [+0200]:
- Update mingw-w64 in rawhide and f19-updates-testing to today's snapshot
I forgot to mention that today's mingw-w64 snapshot also resolves an issue where certain binaries (like webkitgtk3's GtkLauncher-3.exe) couldn't be executed on Windows XP because of a missing strnlen symbol in msvcrt.dll. It was resolved upstream in http://sourceforge.net/p/mingw-w64/code/5963/
Once the updated mingw-w64 snapshot is in f19 I'll rebuild mingw-fontconfig (which seems to be the only affected package) to resolve the strnlen dependency issue.
Regards,
Erik
On 07/21/2013 09:12 AM, Erik van Pienbroek wrote:
In the last couple of days I've been working with upstream mingw-w64 developers to resolve all known build failures (with exception of the ones which are caused by winpthreads). We're currently at a point where we feel confident with the current state. I plan on doing one more test mass rebuild (without winpthreads) to make sure all build failures are resolved now.
Here's what I would like to propose:
- Update mingw-w64 in rawhide and f19-updates-testing to today's snapshot
- Kick off a test mass rebuild without winpthreads to make sure there are no more build failures
- Once we've got a confirmation that all build failures are really resolved, push these updated mingw-w64 packages to f18-updates (with buildroot overrides in place for the time the packages have to spend in updates-testing)
- Afterwards the wine maintainer can build and push updated versions of mingw-wine-gecko and wine itself to f18
Does this sound like a good plan to you folks?
Sounds fine to me.
CC'ing wine/gecko maintainer.
Sounds good! Thanks for the good work.
Regards, Andreas
Am Montag, 22. Juli 2013 schrieb Michael Cronenworth :
On 07/21/2013 09:12 AM, Erik van Pienbroek wrote:
In the last couple of days I've been working with upstream mingw-w64 developers to resolve all known build failures (with exception of the ones which are caused by winpthreads). We're currently at a point where we feel confident with the current state. I plan on doing one more test mass rebuild (without winpthreads) to make sure all build failures are resolved now.
Here's what I would like to propose:
- Update mingw-w64 in rawhide and f19-updates-testing to today's snapshot
- Kick off a test mass rebuild without winpthreads to make sure there are no more build failures
- Once we've got a confirmation that all build failures are really resolved, push these updated mingw-w64 packages to f18-updates (with buildroot overrides in place for the time the packages have to spend in updates-testing)
- Afterwards the wine maintainer can build and push updated versions of mingw-wine-gecko and wine itself to f18
Does this sound like a good plan to you folks?
Sounds fine to me.
CC'ing wine/gecko maintainer.
Sounds good to me as well, at least the part about f19 and rawhide.
Not so sure about f18 -- might be best to just leave it be. Is there any pressing need to update the wine packages in f18?
I am sure we can keep all the Fedora-packaged stuff building with whatever mingw-w64 snapshot we ship, but updating it might make the life harder for users who build their own apps / libraries, and have come to expect the older toolchain version in their f18 setups.
In any case, good work guys!
On Mon, 22 Jul 2013 14:59:10 +0200 Kalev Lember kalevlember@gmail.com wrote:
Not so sure about f18 -- might be best to just leave it be. Is there any pressing need to update the wine packages in f18?
Well we are kind of in a bad situation here: If we do not update wine in f18 we will stay with a development version of wine which is getting more and more out of date and pretty useless for users. There is actually no way in backporting fixes etc. Going back to the last stable wine (1.4.x) is not a good solution as well.
If we update wine and drop support for native fedora gecko we are back at where we were before we had a proper mingw in fedora. This is something I'd like to avoid. Especially as this would force users to download gecko again from winehq.
Regards, Andreas
Erik van Pienbroek schreef op zo 21-07-2013 om 16:12 [+0200]:
Here's what I would like to propose:
- Update mingw-w64 in rawhide and f19-updates-testing to today's snapshot
- Kick off a test mass rebuild without winpthreads to make sure there are no more build failures
- Once we've got a confirmation that all build failures are really resolved, push these updated mingw-w64 packages to f18-updates (with buildroot overrides in place for the time the packages have to spend in updates-testing)
- Afterwards the wine maintainer can build and push updated versions of mingw-wine-gecko and wine itself to f18
Does this sound like a good plan to you folks?
Okay, so with the test mass rebuild completed we're about to enter step 3 of the plan. The test mass rebuild showed that all build regressions are resolved now. The only ones remaining are: - a cximage libpng 1.6 compatibility issue (which is rawhide specific), - a build issue in libvirt (for which patches are already upstreamed) - and a build issue in qt5-qtwebkit (which is f19 and rawhide specific as I don't plan om introducing qt 5.1 on f18).
So with this in mind I guess it should be safe to update the mingw-w64 toolchain in f18 to the 20130721 snapshot. I'll build updated packages and push them to f18-updates-testing and the f18 buildroot override.
Regards,
Erik
Erik van Pienbroek schreef op do 25-07-2013 om 23:31 [+0200]:
So with this in mind I guess it should be safe to update the mingw-w64 toolchain in f18 to the 20130721 snapshot. I'll build updated packages and push them to f18-updates-testing and the f18 buildroot override.
The updated packages were just successfully built for f18 and added as buildroot override. For those who wish to give karma: here's the updates link: https://admin.fedoraproject.org/updates/mingw-headers-2.0.999-0.30.trunk.r59...
@Andreas: you should now be able to build wine-gecko and wine on f18
Regards,
Erik
-
Andreas Bierfert -
Erik van Pienbroek -
Kalev Lember -
Michael Cronenworth