The silo 32 (https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/landing-032/+packages) contains these fixes backported to Qt 5.4.1:
https://codereview.qt-project.org/#/c/122382/ https://codereview.qt-project.org/#/c/113478/ https://codereview.qt-project.org/#/c/121724/ https://codereview.qt-project.org/#/c/126219/ (with setting to skip generic plugin via ubuntu-touch-session package) With those this bug and accessibility property are fixed, but with the downside of NM bearer starting to somehow depend on more DBus calls that get blocked by apparmor (I meant "blocked by apparmor", not "blocking calls"), causing this same bug #1508945 as what happens with the PPA with Qt 5.5 packages (which have the one post-5.5.1 commit cherry- picked). If the apparmor rules are relaxed the same way as would be needed for fixing bug #1404188, the problems disappear, but alas we can't relax them for real. So unfortunately the fixes can't be apparently landed if not also switching to connectivity-api bearer or if there's a solution to NM bearer that fixes the bugs fixed in those first three commits without causing the new problem in our current apparmor setup. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtbase-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1470700 Title: QNetworkAccessManager hangs when in flight mode Status in qtbase-opensource-src package in Ubuntu: Confirmed Status in thumbnailer package in Ubuntu: Triaged Bug description: Testing the fix: - Update rc-proposed (vivid) to citrain device-upgrade 32 0000 - Optional: If you want to test using the 'generic' bearer plugin instead of the Network Manager bearer, either do not upgrade ubuntu-touch-session or move away the file /etc/profile.d/qt_networkmanager_bearer.sh - Reboot --- When my phone is in flight mode, HTTP requests made using QNetworkAccessManager seem to hang rather than erroring out immediately. From my tests, it looks like the HTTP request is blocked until the flight mode is disabled and a network connection is reestablished. This is contrary to the documentation, which states: """If the network is not accessible the network access manager will not process any new network requests, all such requests will fail with an error. Requests with URLs with the file:// scheme will still be processed.""" http://doc.qt.io/qt-5/qnetworkaccessmanager.html#networkAccessible- prop By running strace on my test program, it doesn't even look like it attempts to open a TCP connection when blocked in flight mode. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1470700/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
