Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(116)

Issue 122713003: Merge trunk r242964 to the 33.0.1750 branch. (Closed)

Created:
6 years, 11 months ago by Mark Mentovai
Modified:
6 years, 11 months ago
Reviewers:
Mark Mentovai
CC:
chromium-reviews, grt+watch_chromium.org
Visibility:
Public.

Description

Merge trunk r242964 and r243035 to the 33.0.1750 branch. r242964: > Expand the Keystone tag to contain the system's CPU's bitness and whether a > full installer is desired. > > Formerly, the tag identified only the channel that Chrome was on. The tag is > being enhanced to detect the CPU's bitness (adding "-32bit" for 32-bit-only, > non-64-bit-capable CPUs) and whether a full (as opposed to binary diff patch) > update is requested (adding "-full"). > > CPU bitness detection ought to be a feature of Keystone, but Keystone uses the > NXGetLocalArchInfo to determine the CPU type, and winds up always reporting > "i486". The "-32bit" tag suffix will be present whenever the > "hw.cpu64bit_capable" sysctl name is not found or has value 0. This enables > proper detection of users who are capable of running 64-bit Chrome on the > server side. > > When a binary diff patch update application fails in dirpatcher, typically the > result of modifications made to existing installations, the "-full" tag suffix > will be set. On a subsequent update attempt, the server can detect this value > and provide the client with a full updater package, which does not depend on > the existing installation. The "-full" tag suffix is cleared on successful > update installation. > > BUG=18323, 54047, 225352, 303280, 316916 > R=thakis@chromium.org > > Review URL: https://codereview.chromium.org/102963007 r243035: > Switch exit status from 77 (try again later) back to 12/13 (errors). > > When driving an update from KeystoneRegistration, Chrome sees 77 as success. > This causes the about page to say that an update was successfully installed > and offer the option to relaunch. When the user clicks Relaunch, Chrome quits > and the same old version restarts and starts trying to apply an update again. > This seems kind of glitchy. > > I'm switching back to the failure codes, because those are properly reported > in the UI. In the future, I can make keystone_glue.mm check for the > .want_full_installer file when update installation fails and silently retry > installation once, for a seamless "error 12"-free experience. > > BUG=54047, 303280 > TBR=thakis > > Review URL: https://codereview.chromium.org/121673003 Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=243102

Patch Set 1 #

Patch Set 2 : #

Unified diffs Side-by-side diffs Delta from patch set Stats (+259 lines, -7 lines) Patch
M build/mac/tweak_info_plist.py View 3 chunks +28 lines, -0 lines 0 comments Download
M chrome/browser/mac/keystone_glue.mm View 6 chunks +81 lines, -2 lines 0 comments Download
M chrome/installer/mac/keystone_install.sh View 1 11 chunks +150 lines, -5 lines 0 comments Download

Messages

Total messages: 2 (0 generated)
Mark Mentovai
6 years, 11 months ago (2014-01-06 16:52:44 UTC) #1
Mark Mentovai
6 years, 11 months ago (2014-01-06 16:59:09 UTC) #2
Message was sent while issue was closed.
Committed patchset #2 manually as r243102.

Powered by Google App Engine
This is Rietveld 408576698