touch-packages team mailing list archive

[Timo Jyrinki <timo.jyrinki@xxxxxxxxxxxxx>]

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