Closed Bug 931550 Opened 11 years ago Closed 11 years ago

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

Categories

(Firefox OS Graveyard :: Gaia, defect)

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

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

Status:
VERIFIED FIXED
Project Flags:
blocking-b2g koi+
Tracking Flags:
Tracking Status
b2g-v1.2 --- fixed

People

(Reporter: aryx, Assigned: julienw)

References

(
URL
)

Details

(Whiteboard: [from-geeksphone])

Attachments

(4 files)

patch v1
1.06 KB, patch
Details | Diff | Splinter Review
install-gaia gvmake dependency graph, current tree state (without patch!)
90.48 KB, image/png
Details
even more dependencies; pull request
46 bytes, text/x-github-pull-request
yurenju
: review+
julienw
: feedback+
Details | Review
install-gaia gvmake dependency graph with asuth's patch
103.67 KB, image/png
Details 
Phone type (Keon, Peak, other): Geeksphone Keon
OS version (Settings>Device information>More information>): 1.2.0.0-prerelease
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).
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.
Exactly… Is there another bug for this, or are we the only ones suffering from it?
KaiRo also sees this issue with self-compiled builds for the ZTE Open, so it's likely not device-dependent.
blocking-b2g: --- → koi?
I'm seeing this on 1.2 builds I did for the ZTE directly from fresh source, with config.sh+build.sh - 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)
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)
Andrew,

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 info@geeksphone.com to ask with help finding the logs.  I'll report back if I hear anything.
Flags: needinfo?(bugmail)
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 http://www.geeksphone.com/manifests/index.php 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 application.zip (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.
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.
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 asuth@mozilla.com and to Julien at jwajsberg@mozilla.com 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.
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 :)
Thanks both.

@Andrew, I send the logs to you to bugmail@asutherland.org, 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.
Bug 906316 has been uplifted, so it might help with this.
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.
Julien, i tested a build with really-clean and the problem is the same. Will send the logs to you and Andrew.
Attached patch patch v1 — — Splinter Review 
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)
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!
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.
Flags: needinfo?(bugmail)

        Attachment #829665 -
        Flags: review?(felash)

    
    

    
  


  
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 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 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+

    
    

    
  
Any date of when will this be uplifted? to master and 1.2?

    
    

    
  
Geeksphone> probably today or tomorrow.

    
    

    
  
landed on gaia/master:
https://github.com/mozilla-b2g/gaia/pull/13540
https://github.com/mozilla-b2g/gaia/commit/513bafaceb391b5fb102ae3ac5a2a753f91ce164

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

    
    

    
  
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+

    
    

    
  
landed on master => resolved fixed

thanks Andrew!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED

    
    

    
  
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

    
    

    
  
The keon 1.2 build from the 12th has both the clock and email working, thanks.
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: