Clock and Mail app only have rocket icon on homescreen, can't launch/broken



Firefox OS
4 years ago
4 years ago


(Reporter: aryx, Assigned: julienw)


Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:koi+, b2g-v1.2 fixed)


(Whiteboard: [from-geeksphone], URL)


(4 attachments)

Phone type (Keon, Peak, other): Geeksphone Keon
OS version (Settings>Device information>More information>):
Build Identifier (...>More information>): 20131026225502
Update channel (...>More information>): default

Steps to Reproduce:
1) Swipe left on the home screen to see the right home screen.

Expected Result:
Clock and Mail apps have the correct icon and can be launched.

Actual Result:
Clock and Mail apps have rocket icon and tapping them just shows a black screen, doesn't launch the apps.

Is this issue sometimes or always reproducible: 
Always (in the last week in which I flashed new versions several times).

Comment 1

4 years ago
It was ok in yesterday's build (and I believe the day before), but came back in the latest 20131031223710 OTA update… The icons are ok though, but tapping them results in a black screen.
For me, it was okay on the 28th (the first update I did using Wi-Fi) and broke again with the 30th (and is still broken with the one from the 31st). Now the icons are still shown, but the screen remains black after tapping them. I guess the icons are cached.

Comment 3

4 years ago
Exactly… Is there another bug for this, or are we the only ones suffering from it?
I have posted the issue to the Geeksphone forum:
KaiRo also sees this issue with self-compiled builds for the ZTE Open, so it's likely not device-dependent.
blocking-b2g: --- → koi?

Comment 6

4 years ago
I'm seeing this on 1.2 builds I did for the ZTE directly from fresh source, with - we really can't have that process produce broken standard apps.

I think because of that, this should block koi as the standard steps we have documented should produce images with those apps working.
The Geeksphone 1.2 builds seem to keep breaking intermittently.  The ZTE source builds having the problem too are news to me.  Does anyone have a build log of a failed build?
Flags: needinfo?(kairo)

Comment 8

4 years ago
Andrew, sorry, I do not have a log, but I should have the tree in the state after build (I think that partition has a filesystem issue which will probably require me to wipe it but I haven't done it yet).
Flags: needinfo?(kairo)

Can you please determine if the build issue is specific to a particular day or is it failing in general?

Please re-nom if its the latter case.
blocking-b2g: koi? → -
Flags: needinfo?(bugmail)
(In reply to Preeti Raghunath(:Preeti) from comment #9)
> Can you please determine if the build issue is specific to a particular day
> or is it failing in general?

I need build logs to investigate.  I did another pass at searching geeksphone's site but still had no luck.  So I emailed to ask with help finding the logs.  I'll report back if I hear anything.
Flags: needinfo?(bugmail)

Comment 11

4 years ago
We receive your mail.

I'm not sure if we can share build logs. Will ask some people and come back with an answer. By default we dont share our logs because could contain private data.

If you like you can use the manifest in to try a build. When we build a image then upload the manifest there so anyone can use this xml to have the exact same image that we release and you will get the same logs that we get.

Anyway I just taked a look to logs and there is no error in email app building.
Both webapps have an empty (22 bytes large).
It's probably worth noting that both the e-mail app and the clock app have Makefiles and use XULRUNNERSDK to run r.js to perform build optimization, etc.  In the event there is a transient network failure that causes XULRUNNERSDK to not be fully downloaded, the apps will fail to build.

In other words, this is unlikely to be a deterministic problem; more a problem with the network of the build machine or something like that.  Which is why we need logs and trying to reproduce is unlikely to be of much help.

Comment 14

4 years ago
OK, I did another build of 1.2 for my ZTE Open and now it works fine.

It always was our rule with the Mozilla build system that we would fail the build if there's something missing, why aren't we doing that with those failures? If we did that with a reasonable message on what's missing, it would be much easier to see the issue and debug it.

Comment 15

4 years ago
We are having failures too with master when xulrunner is downloading but a script that is inside xulrunner is launched, so it fails. Only happens when changing branches. Maybe a control of a correct download of xulrunner is needed.

@asuth and @kairo I cannot share here the logs (they have some internal information), but i could send them to you if you agree not to share them. I will send too the one in master branch that has the problem with xulrunner.
If you could send the logs to me at and to Julien at then that's probably the best way to get the logs to people who can try and fix the problem.  (Julien has been doing a lot of improvements to the xulrunner downloading and how it executes sub-makefiles like email and clock.  I can at least skim the logs and provide a summary of the failure to others.)

The Makefile does try and make sure it is using the right xulrunner, but it wouldn't surprise me if there are potentially complicated failure cases that are not handled.

Thanks very much for your willingness to help resolve this problem!
Er, and I agree to not to further share the logs.  I think I can speak for Julien since he is also a MoCo employee that he can likewise be enjoined to not share the logs around.

Comment 18

4 years ago
Might be useful to do a "make -C gaia really-clean" command before doing the real build in build automations.

The build system in 1.2 doesn't fail if there is a failure in one of the submakes. I fixed this in bug 906316 that I plan to uplift to 1.2 probably today, as I saw no regression on master. This will (at least) fail the build if the submake fails.

Heck, I'll do it now :)

Comment 19

4 years ago
Thanks both.

@Andrew, I send the logs to you to, I sent them before I see your reply :(. And please send them to Julien. There is not a secret conspiration in this logs, but some internal paths and some info could be there.

@Julien, thanks for the info. As you will uplift it in 1.2, I will add it right now to the scripts in master and 1.2. It's a shame that we dont get this kind of info at time, we only get them when something brokes :(. We have the same problem with locales, and now someone changed the manifest of keon without asking us :(. 

Hope this fix the email and clock problem.

Comment 20

4 years ago
Bug 906316 has been uplifted, so it might help with this.

Comment 21

4 years ago
Geeksphone> "make really-clean" exists for a long time and I think we don't use this in our own builds (but maybe we should too?). Bug 906316 added some more cleanup in it.

Comment 22

4 years ago
Julien, i tested a build with really-clean and the problem is the same. Will send the logs to you and Andrew.

Comment 23

4 years ago
Created attachment 829281 [details] [diff] [review]
patch v1

WIP patch.

This forces the dependency on xulrunner before running the submakes, because the submakes need XULRunner.

I spotted other potential dependency problems:
* webapp-manifests
* webapp-zip
* webapp-optimize
* optimize-clean

don't depend on app-makefiles (which is running the submakes). I think it's wrong (maybe only for some of them), but I'd like Andrew's advice on this.
Right now, it means that the submakes or these goals could run in any order.
Assignee: nobody → felash
Flags: needinfo?(bugmail)

Comment 24

4 years ago
I guess the race condition of still downloading while doing the stuff the download is required for was also the problem why I saw this on my first ZTE Open build.
We definitely should see to fix it on any branch we can because anyone, including partners, can run into that any time, esp. when switching channels or building in a new tree.

Thanks for putting in the work to find out and fix the issue!
Created attachment 829516 [details]
install-gaia gvmake dependency graph, current tree state (without patch!)

I ran the Makefile through gvmake (with a hacked in --trim option) and got this graph to help make it more clear what the actual dependencies of stuff are.

I believe the dashed lines have to do with what targets are virtual.  Virtual targets have no border and the arrows pointing to them are dashed.  In theory targets marked as .PHONY get marked as virtual, but there are also some rules in the code about targets that lack commands being marked virtual.  install-xulrunner-sdk is explicitly marked .PHONY so there's probably some nuance I'm missing.  I'd just treat all arrows as the same.

I think Julien is right about the app-makefiles needing to be a dep of more stuff.  I'll prepare a rev of the patch, look for other obvious glitches and then prepare an additional graph because I love graphs.
Created attachment 829665 [details] [review]
even more dependencies; pull request
Flags: needinfo?(bugmail)
Attachment #829665 - Flags: review?(felash)
Created attachment 829666 [details]
install-gaia gvmake dependency graph with asuth's patch

So this threads a more explicit sequence of events for the build stuff.  Honestly, the lack of comments in the JS build files or in the Makefile leaves me pretty confused and frustrated, but it seems like this emergent sequence is right-ish (tracing through the longest path in dependency build order)
1) install-xulrunner-sdk
2) app-makefiles
3) in parallel: webapp-manifests, webapp-optimize
4) webapp-zip
5) optimize-clean
6) offline ??
7) (profile)
8) (install-gaia)

Comment 28

4 years ago
Comment on attachment 829665 [details] [review]
even more dependencies; pull request

Yuren is probably the best to review this.

I've thrown some comments but I think this is the good way forward.
Attachment #829665 - Flags: review?(yurenju.mozilla)
Attachment #829665 - Flags: review?(felash)
Attachment #829665 - Flags: feedback+

Comment 29

4 years ago
Comment on attachment 829665 [details] [review]
even more dependencies; pull request

Maybe ask review from Yuren only once my comments are fixed.
Attachment #829665 - Flags: review?(yurenju.mozilla)
Comment on attachment 829665 [details] [review]
even more dependencies; pull request

I've updated the pull request with Julien's requested changes and hopefully improving the clarity of the comment at issue.  I haven't recomputed the dependency graph since the dependency added was already a transitive dep and so the graph remains unchanged.
Attachment #829665 - Flags: review?(yurenju.mozilla)
Comment on attachment 829665 [details] [review]
even more dependencies; pull request

looks good and thanks for the comments in Makefile!
Attachment #829665 - Flags: review?(yurenju.mozilla) → review+

Comment 32

4 years ago
Any date of when will this be uplifted? to master and 1.2?
Duplicate of this bug: 916441

Comment 34

4 years ago
Geeksphone> probably today or tomorrow.
landed on gaia/master:

Requesting koi+ to be able to uplift to v1.2.  Triagers: we need this fix on v1.2 if we want the Geeksphone Nightly builds to have working e-mail and clock builds.
blocking-b2g: - → koi?
status-b2g-v1.2: --- → affected

Comment 36

4 years ago
I'd actually say we need it on 1.2 if we want to avoid that others (both developers and partners) may be running into this any time they do a fresh build where xulrunner hasn't been downloaded yet by a previous build.
As a keon user myself, I'd like to avoid Geeksphone breakage so koi+ :)
blocking-b2g: koi? → koi+

Comment 38

4 years ago
landed on master => resolved fixed

thanks Andrew!
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 39

4 years ago
Thankyou all. Is working ok in master and i add the patch manually to 1.2 and works ok too.
Uplifted 513bafaceb391b5fb102ae3ac5a2a753f91ce164 to:
v1.2: 47f62b18b9919078e38043be680914cdae0a3727
status-b2g-v1.2: affected → fixed

Comment 41

4 years ago
The keon 1.2 build from the 12th has both the clock and email working, thanks.
You need to log in before you can comment on or make changes to this bug.