App scope is blank

http://termbin.com/8t8v
http://termbin.com/6bbg

This should be fixed with next unity8 landing in silo 71 https://requests.ci-train.ubuntu.com/#/ticket/1078

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

Hmm, I'm not aware of any branch in silo 71 that was supposed to fix this problem... Are you sure it was silo 71? Do we know what was the root cause and are we sure it's fixed?

NB, I'm not able to reproduce.

After talking to Saviq on IRC we think this issue got confused with https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1545866 (which indeed had a fix in silo 71).
So, to my understanding the issue of Apps scope going blank is unfortunately not fixed, re-opening.

fwiw I also saw the store scope and app previews blank the first time I visited each

Hey Alan, do you by any chance have a whole bunch of clicks stored away somewhere that you install on your phone, say, each time you re-flash?

No. This phone doesn't get re-flashed, and I don't install lots of clicks on it. I have OTA'd and re-flashed a bit, but mostly not "--wiped" at all for many months.

I get blank apps scope basically after every rc-proposed OS upgrade (i.e. the device reboots to install the upgrade, and when unity8 starts, apps scope is empty), and sometimes after installing apps from the store.

The problem started about 2 weeks ago, iirc.

Refreshing the scope fixes the problem, in my case.

It would be helpful to run the Apps scope manually with debug enabled, reproduce the issue and grab the output, i.e.
1) Make sure the scope is not running already (ps aux|grep clickscope)
2) Log in via adb and run it as phablet user:
U1_DEBUG=1 /usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner "" /usr/lib/arm-linux-gnueabihf/unity-scopes/clickapps/clickscope.ini > output.log 2>&1
3) Reproduce the problem & stop the scope (CTRL+C), attach output.log.

Alternatively, add "env U1_DEBUG=1" below "author" line in /usr/share/upstart/sessions/scope-registry.conf to enable debug permanently, then reboot the phone - if the problem is reproduced, the debug output should be appended to /home/phablet/.cache/upstart/scope-registry.log.

scope-registry.log with U1_DEBUG=1 in /usr/share/upstart/sessions/scope-registry.conf and reproducing the issue after a reboot on arale rc-proposed 317

there you go
http://pastebin.ubuntu.com/16317195/

at 12:34 the phone had just rebooted, at 12:38 I unlocked the screen

krillin, rc-proposed, r325

unity8-dash.log from the same boot.

Does everyone who can recreate this issue have a very large number of apps installed?

@popey I know you do, could you attach a tarball of ~/.local/share/applications/ that we could dump on a phone to verify if # of installed apps is related, or if perhaps some app in particular might be causing the issue?

131 applications in the tarball attached.

245 listed in .local/share/applications.

231 according to click list | wc -l

88 listed in .local/share/applications.

Is this bug also this: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1568007 ?

@bogdanke8, hmm, that situation actually looks more sever. With this bug at least you see the scope. It's just empty: https://launchpadlibrarian.net/257870964/device-2016-05-04-165411.png

With the packages from silo 54 I cannot reproduce it on MX4

While testing I created bug #1579859 which seems unrelated

It doesn't seem that the number of apps matters: I just installed 350 click packages at once, and still can't reproduce this bug. Krillin, rc-proposed, r327.

@alecu, Yeah I am yet to reproduce the myself :/

However, the revert I did in silo 54 does seem to fix it somehow. Since applying the silo, Alan, Andrea, and Pat can no longer reproduce the issue. Just waiting for a thumbs up from Jean-Baptiste.

Alright, we have a thumbs up from Jean-Baptiste. Let's continue with reverting the sign-all-requests changes and I will continue to look into WHY this fixes it.

I still haven't been able to reproduce this bug. At least, not unless I try to load the app store while the network is down, which is probably expected behavior. Is there any reliable recipe for triggering it?

@Selene no, there isn't... Only some people were able to reproduce. It was basically a race / timing issue - Marcus and I were not hitting it after spending a day trying.

@Selene, yeah, but I was able to reproduce the issue programatically by simulating some slow startup logic with a sleep(). This allowed me to produce what I believe is now the proper fix to the bug (MP attached).

Thanks to faenil, jibel, pmcgowan, and poppy, we've confirmed that the change does in fact fix the problem.

^ poppy -> popey. Autocorrect fail :P