FFE: Update webkit to 1.9.91

in fact let's keep the bug open, I updated to 1.9.2 not to the current version 1.9.5

I started looking to 1.9.5 but the update is a bit harder, random notes:
- should we enable webkit2 (it doesn't work with gtk2, only gtk3)
- the new version has new build-depends
- it seems to have some build issues

I don't think we can enable webkit2 yet unless we can still build a webkit1 library for gtk2, there are reverse dependencies that still need it. Also, while there was talk of stabilizing the API for webkit2, idk if that's happened yet, so porting might still end up being a nightmare.

This blocks the update to Epiphany 3.5.5 (bug 1033909) as epiphany-browser now requires webkit 1.9.6.

1.9.6 had abi,api incompatibles changes, I reported them upstream and they should be fixed in the new version, I need to check that

Unfortunatly 1.9.90 still have api break issues, that's known and being worked upstream...

1.9.91 has resolved the API issues, it's available in the ubuntu-desktop ppa for i386, some issues remain to resolve before upload:

- the .symbols need to be updated for some of the cpp symbols that changed

- the dh_makeshlibs level should probably be restored to -c4 for the archive upload

- the build fails on amd64 on the ppa buildds, it might be a toolchain limitation, I've opened https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1043507 about that

Upstream pointed to https://trac.webkit.org/wiki/WebKitGTK/1.10.x which includes that item
​https://bugs.webkit.org/show_bug.cgi?id=94435 "[GTK] Split WebCore/platform into a separate library"

that might workaround the amd64 issue and is planned for 1.10...

Turning the bug to a FFe as well because at this point the update doesn't only have bug fixes since previous versions failed landing. The rational to update is that we are on an early version of that unstable serie and we will probably want to update to the stable version for obvious reasons (less bugs, easier to maintain, etc)

From the security team's perspective, we'd much rather have the final webkit release in rather than an unstable snapshot to shake out any issues with the new pieces while it's still the dev release. Otherwise, we'd prefer to revert to 1.8, which would mean reverting anything that uses the new webkit version (epiphany and various other pieces of GNOME) which would be a real mess. I currently plan to update quantal with the 1.10.x stable release branch as the releases come out.

The version of epiphany currently in Quantal works with webkit 1.8. I'm not aware of anything else depending on webkit 1.9.

Based on the above discussion, it does not appear that this is essential for 12.10. Deferring this to R-Series, so more timely review can occur.

Based on discussion in #ubuntu-release, impact of reverting from 1.9.2 to 1.8 may not be as risk free as hoped.

<cjwatson> how big is the reverse dep tree anyway?
<jbicha> Mageia was also having trouble getting WebKit 1.9 to build
<infinity> 140 reverse build-deps. Not sure how far down the tree that gets one.
<cjwatson> ow
<cjwatson> and those are all on 1.9 already?
<infinity> And not sure how many things have been rebuilt against the new ABI (and thus need a rebuild) versus need the new API (thus needing a revert as well) and how many wouldn't need to be touched.
<infinity> A versioned rdep scan would be more accurate for the ABI-rebuild question, the API one's a bit tougher.
<infinity> And might just be epihany, if we're lucky.

Marking this as back to In-progress for quantal until least risk path is figured out.

no toolchain limitation, just a broken build system. The only way to build it is to build without -g to keep the size of the archive file below 4G. should be better fixed by building smaller archives/libraries.

webkit | 1.10.0-0ubuntu1 | quantal | sourc