ubuntu-phone team mailing list archive

[Didier Roche <didier.roche@xxxxxxxxxxxxx>]

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