← Back to team overview

ubuntu-phone team mailing list archive

Re: Landing team 16.01.14

 

Le 20/01/2014 06:02, Steve Langasek a écrit :
This is the result of the split of the qtubuntu-android package into
qtubuntu-android and qtubuntu-desktop packages.  Apparently libqubuntu.so is
now only distributed in the latter.

If libqubuntu.so is still needed for SF, even on Mir-based devices, perhaps
qtubuntu-desktop should be added to the seed.  Or perhaps now's the right
moment to get rid of SF once and for all?

Simultaneously, a regression was introduced by a change to
/etc/profile.d/qpa_plugin.sh in ubuntu-touch-session 0.88.  The changed code
used the presence of a $MIR_SOCKET variable to determine which qpa plugin to
use, but nothing sets this variable in an adb session.

ubuntu-touch-session 0.89 reverts to the previous behavior, which should fix
things for adb on Mir-based systems (such as maguro).


Even with Steve's fix and another from Ogra (it seems there is a race to setup an environment variables and so some AP tests are failing as the components are crashing under the wrong environment), we had to revert ubuntu-touch-session for nested Mir. We noticed on latest images multiples issues:
- stacking issues:
* start on a vanilla configuration, try to setup a wiki -> the WPA dialog is never shown (probably displayed under the shell) * no u1 account, click on "install" in the click scope, then, depending on config/boot: - either Unity8 is toping at 80% CPU and no refresh/phone locked (had to reboot) - either the u1 account dialog is showing up, but the keyboard is showing under the shell or under the app and the whole system is stuck - the env variable isn't set properly reliably, as told previously, this occurs: * (probably due to that): no way to install click apps if you already have an u1 account associated on your phone * some random crashes happening in multiple pieces (Unity8, HUD, mediascanner, unity-system-compositor…)

We decided to revert the nested Mir mode for now. Investigation and a lot of manual testing in addition to the automatic one will be needed, as we are clearly lacking of safe bet here.

I *strongly* suggests that we use that opportunity to create at least 2 AP tests for basic vanilla setup (and we accept the nested Mir only when at least those 2 are here):
* connect to a wifi network and type a WPA (or WEP) key
* try to install a click app with no u1 account associated, and then, associating one. Finally ensuring the selected click app is installed and launch it.

Can anyone step up and help creating those AP test cases? ^
Thanks,
Didier


Follow ups

References