Slideshow blank during live install

[Øystein Steffensen-Alværvik]

The usual slideshows during install (talking about Ubuntu features) did not show. Pressing 'next' arrow button did not help. See picture attachment.

Performed an installation from the live session, chose Norwegian language, install alongside Windows boot manager, third-party driver install with uefi safe boot password (do not know if this is related to the bug, but including it in case it is).

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: ubiquity 16.10.9
ProcVersionSignature: Ubuntu 4.4.0-9136.55-generic 4.4.16
Uname: Linux 4.4.0-9136-generic x86_64
ApportVersion: 2.20.3-0ubuntu7
Architecture: amd64
CasperVersion: 1.378
Date: Wed Aug 31 17:52:01 2016
ExecutablePath: /usr/lib/ubiquity/bin/ubiquity
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz.efi file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash ---
InterpreterPath: /usr/bin/python3.5
LiveMediaBuild: Ubuntu 16.10 "Yakkety Yak" - Alpha amd64 (20160831)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1618956

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Iain Lane (laney)]

Ya, this broke with the update to 2.12.4, and works if you downgrade to 2.12.3

You can apply this

=== modified file 'ubiquity/frontend/gtk_ui.py'
--- ubiquity/frontend/gtk_ui.py 2016-06-30 14:33:11 +0000
+++ ubiquity/frontend/gtk_ui.py 2016-09-02 08:39:34 +0000
@@ -759,6 +759,9 @@
         self.set_current_page(0)
         self.live_installer.show()

+ self.start_slideshow()
+ Gtk.main()
+
         while(self.pagesindex < len(self.pages)):
             if self.current_page is None:
                 return self.returncode
@@ -814,8 +817,6 @@

         # There's still work to do (postinstall). Let's keep the user
         # entertained.
- self.start_slideshow()
- Gtk.main()
         self.pending_quits = max(0, self.pending_quits - 1)
         # postinstall will exit here by calling Gtk.main_quit in
         # find_next_step.

to test just the slideshow step.

[Jeremy Bícha (jbicha)]

Incidentally, the slideshow works with webkit2gtk 2.13.90. While that could work for yakkety, we still need to get 2.12 working since mdeslaur was interested in uploading 2.12.4 to xenial later this month. I would say that webkit releases are more stable these days but this bug kinda argues against that, right?

I think we need to get a simpler test case to make a more effective bug report upstream.

[Michael Catanzaro (mike-catanzaro)]

I very much want to see 2.12 for Xenial. Still, I'll be honest: we still have a couple serious regressions each cycle, and any WebKit release could break anything. E.g. we had to release 2.12.5 today to fix a nasty network process hang when there is a load failure, which was introduced in 2.12.4. It's possible that could be causing the issue here (though that would probably indicate some other bug in ubiquity). Try with 2.12.5 and see if it works better. (If not, since the issue is already fixed, I would simply wait a couple weeks for 2.14.0 and skip 2.12 entirely.)

When there is a major regression like this in a stable release, Arch users and Fedora testers normally notice very soon, and we normally have a corrected release out within a week or two. If you hold WebKit updates in testing for two weeks as part of the SRU process, or, say, a month to be very conservative, then Ubuntu would have an excellent chance to avoid most such regressions while still being able to ship WebKit security updates in a timely manner. (It's very disappointing to see WebKit has not had a single update since Xenial was released.)

[Sebastien Bacher (seb128)]

@Michael, thanks for the comment, indeed it's tricky to update stable distros to newer series if those create regressions or have changes that impact applications (like needing to rebuild GNOME components is an indication that third party apps customers rely on could stop working), we usually do bugfix updates in a serie though but there is only 2.10.10 out in the 2.10 serie and it's from august so seen from this angle we didn't miss on much updates...

[Michael Catanzaro (mike-catanzaro)]

To be clear: I do not think our bugfix updates (2.10.9 -> 2.10.10) are really much safer than the bigger updates (2.10 -> 2.12) in terms of likelihood of regressions. Actually I think we've had worse luck with regressions in stable releases; we tend to backport bad patches long before they show up in the next stable release. Our stable series get six months of security support and you're expected to move onto the next stable series shortly after it's released. Support for 2.10 ended *before* you released Xenial with 2.10.9. We've announced 16 vulnerabilities affecting 2.10.9 since then <https://webkitgtk.org/security.html>. It'd be great to get those fixes out to Ubuntu users.

Regarding the need to rebuild GNOME components. Fortunately, all of our documented API is guaranteed to be API/ABI stable indefinitely, but there is an undocumented unstable API as well. I know this is a problem. For 2.12 -> 2.14, I suggested rebuilding all apps using the unstable API (Epiphany/Evolution/Yelp) just to be safe, but actually Epiphany is the only required rebuild that I'm aware of. I've had a hard time convincing the relevant developer that the unstable API is a problem for distros, but the problem is fortunately going away, because we froze the DOM API last week, and we'll be removing or stabilizing all the unstable API for 2.16. So after next cycle, you won't have to be concerned about third party apps using the unstable API anymore, as it will all be gone.

In the meantime, if you're concerned about third party apps breaking: I'm not aware of any third party app developers using WebKit2 at all, let alone any using the unstable portion of the DOM API (which is not available at all unless you define a macro to guarantee the developer knows it can break), let alone a portion of that API that has changed recently. If any such third-party developers exist, I would hope they would be smart enough to bundle WebKit, rather than rely on a system API that's clearly marked unstable, which they know can change at any time. So I think it's fairly low-risk; you just need to keep an eye on known users of the API until it goes away.

[Iain Lane (laney)]

F everyone's I: It's unrelated to the compiler - I built 2.12.3 with GCC 6 and it works still, and I built 2.12.4 with GCC 5 and it breaks still.

Here's hoping that 2.12.5 is better. I've stolen it from incoming.debian.org and tossed it at ppa:laney/ppa.

[Jeremy Bícha (jbicha)]

I tested with webkit2gtk 2.12.5-1 rebuilt in my PPA and the slideshow works so I'll be syncing webkit2gtk once LP picks it up.

[Jeremy Bícha (jbicha)]

This bug was fixed in the package webkit2gtk - 2.12.5-1

---------------
webkit2gtk (2.12.5-1) unstable; urgency=medium

  * New upstream release.
  * debian/patches/fix-ftbfs-m68k.patch:
    + Drop this patch, the m68k build has been broken for ages.
  * debian/patches/fix-ftbfs-sparc64.patch:
    + Refresh.

 -- Alberto Garcia <email address hidden> Mon, 05 Sep 2016 13:49:55 +0300