Unwedge aosp/external/libchrome repository |
||||||
Issue descriptionCurrently, the top of the aosp/external/libchrome repository includes these patches: 8263a04 libchrome: Removed Chrome OS license check 5943df7 Cherry-pick "Allow PolicyLoadStatusSample to override reporting method" c3f34a3 libchrome: Uprev the library to r456626 from Chromium 7b88bc8 Add build options to skip some libraries Patch c3f34a3 was a partial full-scale update of libchrome to latest code from Chromium [partial due to no crypto update, b/c Chromium now uses boringssl instead of openssl]. The patch was reviewed at: https://chromium-review.googlesource.com/#/c/479777/ However, libchrome is a very funny cros_workon package, that requires a manual update to "CROS_WORKON_COMMIT" for changes in the repository to take effect. Since there was never a corresponding revbump in the libchrome, the libchrome ebuild still points to 7b88bc8, and all patches beyond that are not being used. In fact, this was noticed by ljusten when landing 5943df7 (https://chromium-review.googlesource.com/#/c/497433/), so this patch is actually now being applied by the libchrome ebuild itself (see https://chromium-review.googlesource.com/#/c/497434/). It isn't clear from CL:479777 why there was no ebuild revbump, and there is no BUG=, so the trail grew cold. If it will take a while longer before we plan to update CROS_WORKON_COMMIT in the ebuild, perhaps we can just revert c3f34a3 for now, and then we can also remove the ebuild-applied patch for 5943df7.
,
Jun 29 2017
+1 to unblock libchrome changes if the uprev is going to take much more time.
,
Jun 29 2017
jcivelli@ is actively trying to update the CROS_WORKON_COMMIT in the ebuild. Unfortunately, due to the way this all is structured, he cannot proceed if we revert the change in external/libchrome :( well... there is way, by reverting the patch and immediately re-applying it so that the new trybot jobs can still pick up "ToT + his changes".
,
Jun 30 2017
Is there a bug tracking #3?
,
Jun 30 2017
Yes: crbug.com/724678
,
Jun 30 2017
,
Jul 7 2017
(I don't know why this was assigned to me.)
,
Feb 21 2018
,
Jul 5
A year later, and we still don't have a solution while the situation deteriorates by more and more patches getting piled on... Can we please figure out something to make this sane again? My vote would be to revert c3f34a3 for now and turn all the patches into proper commits, then figure out a better story for the uprev work (perform it on a branch perhaps?). I'm inclined to -2 further libchrome changes based on the the argument that the current state is horrible mess that prevents reasonable security maintenance.
,
Jul 5
,
Jan 7
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by djkurtz@chromium.org
, Jun 29 2017