Closed
Bug 764684
Opened 13 years ago
Closed 12 years ago
Deal with app.update.stage.enabled
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(blocking-kilimanjaro:+, blocking-basecamp:+)
RESOLVED
FIXED
People
(Reporter: cjones, Assigned: marshall)
References
Details
(Whiteboard: [LOE:S])
Attachments
(1 file)
(deleted),
patch
|
ehsan.akhgari
:
review+
cjones
:
feedback+
|
Details | Diff | Splinter Review |
Support for a different update path landed since the b2g updater was enabled. I'm not 100% sure how this affected the updater protocol, but we need to figure out what to do with this new configuration option.
Updated•12 years ago
|
blocking-basecamp: --- → ?
Comment 1•12 years ago
|
||
Blocking for now - can you clarify what this means?
blocking-basecamp: ? → +
blocking-kilimanjaro: --- → +
Reporter | ||
Comment 2•12 years ago
|
||
No, it was rumored this was affecting b2g updates, but I haven't confirmed nor do I know what this setting does.
Comment 3•12 years ago
|
||
Who would know?
Comment 4•12 years ago
|
||
If you're still looking, Ehsan is your man. That pref came from bug 307181.
Comment 5•12 years ago
|
||
Ehsan, do you have some docs on this?
Comment 6•12 years ago
|
||
Not really. I thought that b2g doesn't use the updater, same way that Android doesn't. My patches disabled background updates for b2g IIRC. What is exactly broken here?
Reporter | ||
Comment 7•12 years ago
|
||
Define "updater"? We use nsUpdateService to download updates and then the related infrastructure to verify and apply them to the filesystem ...
It was unclear whether this bug affected that, but Marshall might know by now.
Comment 8•12 years ago
|
||
I'm talking about the updater application: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp
If that is used on b2g, then we should discuss how it needs to handle the background updates mode.
Reporter | ||
Comment 9•12 years ago
|
||
I ported that to gonk (b2g). We use it.
Comment 10•12 years ago
|
||
(In reply to comment #9)
> I ported that to gonk (b2g). We use it.
Oh, OK, I was not aware of that. It would be useful for me and someone who knows how the updater works in b2g to have a quick meeting next week so that I can figure out what the b2g story looks like.
Two more questions: what is the exact failure? And do all of the updater tests on mozilla-central pass with b2g (do we run those automatically somewhere?)?
Reporter | ||
Comment 11•12 years ago
|
||
(In reply to Ehsan Akhgari [:ehsan] from comment #10)
> (In reply to comment #9)
> > I ported that to gonk (b2g). We use it.
>
> Oh, OK, I was not aware of that. It would be useful for me and someone who
> knows how the updater works in b2g to have a quick meeting next week so that
> I can figure out what the b2g story looks like.
>
Do you mean the update checking, downloading, or applying? All the core parts are 100% the same, but the UI hookup is different obviously. http://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js fyi.
> Two more questions: what is the exact failure? And do all of the updater
> tests on mozilla-central pass with b2g (do we run those automatically
> somewhere?)?
I haven't reproduced this, we heard through the grapevine that this was a problem. No, we don't have those tests running yet.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → marshall
Assignee | ||
Comment 12•12 years ago
|
||
FYI, It does look like this is blocking the updater from working in Gonk.
(In reply to Ehsan Akhgari [:ehsan] from comment #10)
> It would be useful for me and someone who
> knows how the updater works in b2g to have a quick meeting next week
I'm available most of the week, Let's start with IRC and we can move to Skype/Vidyo if needed
> Two more questions: what is the exact failure? And do all of the updater
> tests on mozilla-central pass with b2g (do we run those automatically
> somewhere?)?
In my local testing, since gCanStageUpdates is false,
nsIUpdateProcessor::processUpdates is never being called. We aren't currently explicitly setting app.update.stage.enabled to true (is there anything else required?)
FWIW, we are not currently running Mochitest or xpcshell tests, so I doubt any of the automated updater tests are running. jgriffin and mdas are working on getting those running, though.
Comment 13•12 years ago
|
||
I talked to Marshall about this on IRC today. In short, I don't think there's any big thing to fix for b2g. We just need to make sure that /system is remounted RW before applying the update, and the stage directory lives on the same physical partition as the appdir. Other than this I think most of the Linux code path should be usable here unmodified.
Assignee | ||
Comment 14•12 years ago
|
||
It looks like the only changes required for this bug will be setting app.update.stage.enabled to true, and not writing to update.test from the gCanStageUpdates getter.
The remount changes are already being tracked in Bug 764683
Assignee | ||
Updated•12 years ago
|
Attachment #648046 -
Flags: feedback?(jones.chris.g)
Reporter | ||
Comment 16•12 years ago
|
||
Comment on attachment 648046 [details] [diff] [review]
enable update staging - v1
Sure.
Attachment #648046 -
Flags: feedback?(jones.chris.g) → feedback+
Comment 17•12 years ago
|
||
Comment on attachment 648046 [details] [diff] [review]
enable update staging - v1
Review of attachment 648046 [details] [diff] [review]:
-----------------------------------------------------------------
r=me assuming that the update process has been fully tested on b2g (with the remounting patches of course).
Attachment #648046 -
Flags: review?(ehsan) → review+
Updated•12 years ago
|
Priority: -- → P1
Assignee | ||
Updated•12 years ago
|
Whiteboard: [LOE:S]
Assignee | ||
Comment 18•12 years ago
|
||
Comment 19•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•