New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 737950 link

Starred by 6 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug

Blocked on:
issue 724678



Sign in to add a comment

Unwedge aosp/external/libchrome repository

Project Member Reported by djkurtz@chromium.org, Jun 29 2017

Issue description

Currently, 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.
 
Cc: dkrahn@chromium.org de...@chromium.org
+1 to unblock libchrome changes if the uprev is going to take much more time.
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".
Is there a bug tracking #3?

Comment 5 by lhchavez@google.com, Jun 30 2017

Yes:  crbug.com/724678 
Blockedon: 724678

Comment 7 by derat@chromium.org, Jul 7 2017

Owner: jcivelli@chromium.org
(I don't know why this was assigned to me.)
Cc: hidehiko@chromium.org
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. 
Cc: ejcaruso@chromium.org
Cc: -lhchavez@chromium.org

Sign in to add a comment