Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
188693006:
Mojo interface libraries: set install name and search path properly on Mac. (Closed)
|
Created:
6 years, 9 months ago by yzshen1 Modified:
6 years, 9 months ago CC:
chromium-reviews Base URL:
https://chromium.googlesource.com/chromium/src.git@master Visibility:
Public. |
DescriptionMojo interface libraries: set install name and search path properly on Mac.
This fixed the Mac non-component build.
BUG=346766
TEST=Mojo tests (non-component build) work on Mac
R=thakis@chromium.org, viettrungluu@chromium.org
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255791
Patch Set 1 #
Total comments: 2
Patch Set 2 : #Patch Set 3 : make it a mojo-only change instead #Patch Set 4 : add comments #Messages
Total messages: 30 (0 generated)
Hi, Nico. Would you please take a look? It is scary to change common.gypi. Please let me know if it affects too many things. Thanks!
https://codereview.chromium.org/188693006/diff/1/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/188693006/diff/1/build/common.gypi#newcode2155 build/common.gypi:2155: '@loader_path/../../..', Huh, I'm pretty sure the vast majority of targets doesn't want this in a non-component build. With this, you could put a Chromium Framework next to Chromium.app, and Chromium would then load that framework instead of the one inside its app package I think, right? Which sounds like potentially a security thing? Why is libmojo_system a dylib in static library builds?
(And where do you adjust the rpath on linux for this?)
On 2014/03/06 19:11:09, Nico wrote: > (And where do you adjust the rpath on linux for this?) Thanks for the reply! I will need to do research before I can answer the questions. :)
> (And where do you adjust the rpath on linux for this?) I took a quick look at the code, and it seems I probably don't need to adjust rpath on Linux: We already use -rpath=$ORIGIN/lib even if it is non-component build: https://code.google.com/p/chromium/codesearch#chromium/src/tools/gyp/pylib/gy... https://code.google.com/p/chromium/codesearch#chromium/src/tools/gyp/pylib/gy... One question: On Mac we are using @loader_path while on Linux we are using $ORIGIN. According to the documents, @loader_path expands to the directory of the binary, while $ORIGIN expands to the directory of the executable. They are different, say, when the "binary" is a dynamic library itself. Is that correct? Thanks, Nico! https://codereview.chromium.org/188693006/diff/1/build/common.gypi File build/common.gypi (right): https://codereview.chromium.org/188693006/diff/1/build/common.gypi#newcode2155 build/common.gypi:2155: '@loader_path/../../..', On 2014/03/06 19:10:56, Nico wrote: > Huh, I'm pretty sure the vast majority of targets doesn't want this in a > non-component build. With this, you could put a Chromium Framework next to > Chromium.app, and Chromium would then load that framework instead of the one > inside its app package I think, right? Which sounds like potentially a security > thing? (Forgive my ignorance. First time working on mac issue.) Do you mean the other parts are okay in non-component build (line 2150-2153)? > Why is libmojo_system a dylib in static library builds? libmojo_system is provided by the mojo host and used by mojo apps. It exposes the API that the host allows the apps to use. At run time, the host injects the real implementation of the API into this dynamic library. Therefore, static-linking doesn't make sense.
Hi, Nico. Would you please take another look? Thanks!
On 2014/03/07 18:35:35, yzshen1 wrote: > Hi, Nico. > > Would you please take another look? Thanks! build/common.gypi looks like the wrong place for me if this is only for clients of mojo. I'd either make the mojo dylib push this into its direct_dependent_settings, or, probably better, have a mojo_user.gypi that adds this and include that in things depending on this mojo dylibs. For your path question, see the section "DYNAMIC LIBRARY LOADING" at the bottom of https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPag...
On 2014/03/07 18:39:41, Nico wrote: > On 2014/03/07 18:35:35, yzshen1 wrote: > > Hi, Nico. > > > > Would you please take another look? Thanks! > > build/common.gypi looks like the wrong place for me if this is only for clients > of mojo. I'd either make the mojo dylib push this into its > direct_dependent_settings, or, probably better, have a mojo_user.gypi that adds > this and include that in things depending on this mojo dylibs. (I am happy to make the change. Just want to make sure I fully understand.) One benefit of making it in build/common.gypi seems to be that the behavior will be more consistent with Linux. On Linux, we specify -rpath=$ORIGIN/lib even if it is non-component build, right? > > For your path question, see the section "DYNAMIC LIBRARY LOADING" at the bottom > of > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPag... Yeah, I read this part. My question was that $ORIGIN on Linux seems more like @executable_path on Mac, however, we are using @loader_path on Mac currently. (Just out of curiosity, not directly affect the problem I am trying to solve.)
Add viettrungluu@chromium.org as OWNER. Hi, Nico and Trung. Anyway, I reverted common.gypi and made the change only affect those mojo interface libraries. I tried to use 'target_defaults'. One issue is that 'direct_dependent_settings' is not allowed in 'target_conditions' (late phase). And I don't have a good way to control which targets actually get the definitions from 'target_defaults'. Therefore, I decided to simply duplicate the settings in the three shared libraries. An alternative is to move the three libraries into a separate .gyp file (instead of .gypi) and do unconditional 'target_defaults'. But I think that may be a little bit overkill. Please let me know if you have better ideas. Thanks!
On Fri, Mar 7, 2014 at 12:38 PM, <yzshen@chromium.org> wrote: > Add viettrungluu@chromium.org as OWNER. > > Hi, Nico and Trung. > > Anyway, I reverted common.gypi and made the change only affect those mojo > interface libraries. > > I tried to use 'target_defaults'. One issue is that > 'direct_dependent_settings' > is not allowed in 'target_conditions' (late phase). And I don't have a > good way > to control which targets actually get the definitions from > 'target_defaults'. > Therefore, I decided to simply duplicate the settings in the three shared > libraries. > > An alternative is to move the three libraries into a separate .gyp file > (instead > of .gypi) and do unconditional 'target_defaults'. But I think that may be a > little bit overkill. > > Please let me know if you have better ideas. Thanks! > Another idea would be to have a gypi (mac_rpath.gypi or similar) for the block you added in 3 places, but as long as it's only 3 places it's fine as is too. lgtm, might want to tweak the cl description slightly. > > > https://codereview.chromium.org/188693006/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
lgtm
(grrrrrr lgtm button)
On 2014/03/07 20:42:16, Nico wrote: > On Fri, Mar 7, 2014 at 12:38 PM, <mailto:yzshen@chromium.org> wrote: > > > Add mailto:viettrungluu@chromium.org as OWNER. > > > > Hi, Nico and Trung. > > > > Anyway, I reverted common.gypi and made the change only affect those mojo > > interface libraries. > > > > I tried to use 'target_defaults'. One issue is that > > 'direct_dependent_settings' > > is not allowed in 'target_conditions' (late phase). And I don't have a > > good way > > to control which targets actually get the definitions from > > 'target_defaults'. > > Therefore, I decided to simply duplicate the settings in the three shared > > libraries. > > > > An alternative is to move the three libraries into a separate .gyp file > > (instead > > of .gypi) and do unconditional 'target_defaults'. But I think that may be a > > little bit overkill. > > > > Please let me know if you have better ideas. Thanks! > > > > Another idea would be to have a gypi (mac_rpath.gypi or similar) for the > block you added in 3 places, but as long as it's only 3 places it's fine as > is too. lgtm, might want to tweak the cl description slightly. I kind of like this idea. Though it's not obvious to me why we have to do this explicitly on Mac and not on Linux and Windows. Does this not imply that there's something bad about (explicit) shared_library targets on Mac? (Bad in that some behavior is different.) Also, it'd probably be good to have some explanatory comment above the added blocks. I have no idea what "rpath" is, for example. > > > > > > > > https://codereview.chromium.org/188693006/ > > > > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org.
On Fri, Mar 7, 2014 at 12:51 PM, <viettrungluu@chromium.org> wrote: > On 2014/03/07 20:42:16, Nico wrote: > >> On Fri, Mar 7, 2014 at 12:38 PM, <mailto:yzshen@chromium.org> wrote: >> > > > Add mailto:viettrungluu@chromium.org as OWNER. >> >> > >> > Hi, Nico and Trung. >> > >> > Anyway, I reverted common.gypi and made the change only affect those >> mojo >> > interface libraries. >> > >> > I tried to use 'target_defaults'. One issue is that >> > 'direct_dependent_settings' >> > is not allowed in 'target_conditions' (late phase). And I don't have a >> > good way >> > to control which targets actually get the definitions from >> > 'target_defaults'. >> > Therefore, I decided to simply duplicate the settings in the three >> shared >> > libraries. >> > >> > An alternative is to move the three libraries into a separate .gyp file >> > (instead >> > of .gypi) and do unconditional 'target_defaults'. But I think that may >> be a >> > little bit overkill. >> > >> > Please let me know if you have better ideas. Thanks! >> > >> > > Another idea would be to have a gypi (mac_rpath.gypi or similar) for the >> block you added in 3 places, but as long as it's only 3 places it's fine >> as >> is too. lgtm, might want to tweak the cl description slightly. >> > > I kind of like this idea. > > Though it's not obvious to me why we have to do this explicitly on Mac and > not > on Linux and Windows. Does this not imply that there's something bad about > (explicit) shared_library targets on Mac? (Bad in that some behavior is > different.) > I THINK WHOA WHO KNEW FN TAB TURNS ON CAPS LOCK ON THIS KEYBOARD I think it's a bit weird that this is on by default on linux, but I don't know why it's on so maybe there's a good reason. Maybe it's needed for ffmpeg for chrome? Windows behavior is mostly considered a bad idea these days I think ( http://msdn.microsoft.com/en-us/library/windows/desktop/ff919712(v=vs.85).asp... this doesn't really apply to chrome – if an attacker can put stuff next to chrome, it's too late anyhow). > > Also, it'd probably be good to have some explanatory comment above the > added > blocks. I have no idea what "rpath" is, for example. > > > > > >> > >> > https://codereview.chromium.org/188693006/ >> > >> > > To unsubscribe from this group and stop receiving emails from it, send an >> > email > >> to mailto:chromium-reviews+unsubscribe@chromium.org. >> > > > > https://codereview.chromium.org/188693006/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/03/07 20:51:02, viettrungluu wrote: > On 2014/03/07 20:42:16, Nico wrote: > > On Fri, Mar 7, 2014 at 12:38 PM, <mailto:yzshen@chromium.org> wrote: > > > > > Add mailto:viettrungluu@chromium.org as OWNER. > > > > > > Hi, Nico and Trung. > > > > > > Anyway, I reverted common.gypi and made the change only affect those mojo > > > interface libraries. > > > > > > I tried to use 'target_defaults'. One issue is that > > > 'direct_dependent_settings' > > > is not allowed in 'target_conditions' (late phase). And I don't have a > > > good way > > > to control which targets actually get the definitions from > > > 'target_defaults'. > > > Therefore, I decided to simply duplicate the settings in the three shared > > > libraries. > > > > > > An alternative is to move the three libraries into a separate .gyp file > > > (instead > > > of .gypi) and do unconditional 'target_defaults'. But I think that may be a > > > little bit overkill. > > > > > > Please let me know if you have better ideas. Thanks! > > > > > > > Another idea would be to have a gypi (mac_rpath.gypi or similar) for the > > block you added in 3 places, but as long as it's only 3 places it's fine as > > is too. lgtm, might want to tweak the cl description slightly. > > I kind of like this idea. I personally think it is a little be overkill. Could we do that when we have >3 usage? :) > > Though it's not obvious to me why we have to do this explicitly on Mac and not > on Linux and Windows. On linux, we use -rpath=$ORIGIN/lib even if it is non-component build: https://code.google.com/p/chromium/codesearch#chromium/src/tools/gyp/pylib/gy... https://code.google.com/p/chromium/codesearch#chromium/src/tools/gyp/pylib/gy... Windows will search the same folder as the binary for DLLs by default, I think. > Does this not imply that there's something bad about > (explicit) shared_library targets on Mac? (Bad in that some behavior is > different.) I agree. That is why I tried to modify common.gypi at the beginning of the patch. > > Also, it'd probably be good to have some explanatory comment above the added > blocks. I have no idea what "rpath" is, for example. > > > > > > > > > > > > > > https://codereview.chromium.org/188693006/ > > > > > > > To unsubscribe from this group and stop receiving emails from it, send an > email > > to mailto:chromium-reviews+unsubscribe@chromium.org.
On Fri, Mar 7, 2014 at 1:05 PM, <yzshen@chromium.org> wrote: > On 2014/03/07 20:51:02, viettrungluu wrote: > >> On 2014/03/07 20:42:16, Nico wrote: >> > On Fri, Mar 7, 2014 at 12:38 PM, <mailto:yzshen@chromium.org> wrote: >> > >> > > Add mailto:viettrungluu@chromium.org as OWNER. >> > > >> > > Hi, Nico and Trung. >> > > >> > > Anyway, I reverted common.gypi and made the change only affect those >> mojo >> > > interface libraries. >> > > >> > > I tried to use 'target_defaults'. One issue is that >> > > 'direct_dependent_settings' >> > > is not allowed in 'target_conditions' (late phase). And I don't have a >> > > good way >> > > to control which targets actually get the definitions from >> > > 'target_defaults'. >> > > Therefore, I decided to simply duplicate the settings in the three >> shared >> > > libraries. >> > > >> > > An alternative is to move the three libraries into a separate .gyp >> file >> > > (instead >> > > of .gypi) and do unconditional 'target_defaults'. But I think that >> may be >> > a > >> > > little bit overkill. >> > > >> > > Please let me know if you have better ideas. Thanks! >> > > >> > >> > Another idea would be to have a gypi (mac_rpath.gypi or similar) for the >> > block you added in 3 places, but as long as it's only 3 places it's >> fine as >> > is too. lgtm, might want to tweak the cl description slightly. >> > > I kind of like this idea. >> > > I personally think it is a little be overkill. Could we do that when we > have >3 > usage? :) > > > > Though it's not obvious to me why we have to do this explicitly on Mac >> and not >> on Linux and Windows. >> > > On linux, we use -rpath=$ORIGIN/lib even if it is non-component build: > https://code.google.com/p/chromium/codesearch#chromium/ > src/tools/gyp/pylib/gy... > https://code.google.com/p/chromium/codesearch#chromium/ > src/tools/gyp/pylib/gy... > > Windows will search the same folder as the binary for DLLs by default, I > think. > > > > Does this not imply that there's something bad about >> (explicit) shared_library targets on Mac? (Bad in that some behavior is >> different.) >> > > I agree. That is why I tried to modify common.gypi at the beginning of the > patch. (We only have a limited numbers of targets that we ship to users, and those are all bundles. Until now we haven't used shared_libraries with non-bundled executables in non-component builds.) > > > > Also, it'd probably be good to have some explanatory comment above the >> added >> blocks. I have no idea what "rpath" is, for example. >> > > > >> > >> > > >> > > >> > > https://codereview.chromium.org/188693006/ >> > > >> > >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> email >> > to mailto:chromium-reviews+unsubscribe@chromium.org. >> > > > > https://codereview.chromium.org/188693006/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/03/07 18:39:41, Nico wrote: > On 2014/03/07 18:35:35, yzshen1 wrote: > > Hi, Nico. > > > > Would you please take another look? Thanks! > > build/common.gypi looks like the wrong place for me if this is only for clients > of mojo. I'd either make the mojo dylib push this into its > direct_dependent_settings, or, probably better, have a mojo_user.gypi that adds > this and include that in things depending on this mojo dylibs. > > For your path question, see the section "DYNAMIC LIBRARY LOADING" at the bottom > of > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPag... So @loader_path/ is the directory of the mach-o binary (i.e., .../MacOS/) not the directory containing the bundle, and so it should be fine security-wise, no?
On Fri, Mar 7, 2014 at 2:17 PM, <viettrungluu@chromium.org> wrote: > On 2014/03/07 18:39:41, Nico wrote: > >> On 2014/03/07 18:35:35, yzshen1 wrote: >> > Hi, Nico. >> > >> > Would you please take another look? Thanks! >> > > build/common.gypi looks like the wrong place for me if this is only for >> > clients > >> of mojo. I'd either make the mojo dylib push this into its >> direct_dependent_settings, or, probably better, have a mojo_user.gypi that >> > adds > >> this and include that in things depending on this mojo dylibs. >> > > For your path question, see the section "DYNAMIC LIBRARY LOADING" at the >> > bottom > >> of >> > > https://developer.apple.com/library/mac/documentation/ > Darwin/Reference/ManPages/man1/dyld.1.html > > So @loader_path/ is the directory of the mach-o binary (i.e., .../MacOS/) > not > the directory containing the bundle, and so it should be fine > security-wise, no? > Possibly, but adding this to all binaries is still unnecessary. > > https://codereview.chromium.org/188693006/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/03/07 22:30:07, Nico wrote: > On Fri, Mar 7, 2014 at 2:17 PM, <mailto:viettrungluu@chromium.org> wrote: > > > On 2014/03/07 18:39:41, Nico wrote: > > > >> On 2014/03/07 18:35:35, yzshen1 wrote: > >> > Hi, Nico. > >> > > >> > Would you please take another look? Thanks! > >> > > > > build/common.gypi looks like the wrong place for me if this is only for > >> > > clients > > > >> of mojo. I'd either make the mojo dylib push this into its > >> direct_dependent_settings, or, probably better, have a mojo_user.gypi that > >> > > adds > > > >> this and include that in things depending on this mojo dylibs. > >> > > > > For your path question, see the section "DYNAMIC LIBRARY LOADING" at the > >> > > bottom > > > >> of > >> > > > > https://developer.apple.com/library/mac/documentation/ > > Darwin/Reference/ManPages/man1/dyld.1.html > > > > So @loader_path/ is the directory of the mach-o binary (i.e., .../MacOS/) > > not > > the directory containing the bundle, and so it should be fine > > security-wise, no? > > > > Possibly, but adding this to all binaries is still unnecessary. What's the cost for doing so? (Vs the cost of scratching our heads over weird things in lots of .gyp files, necessary and unnecessary cargo-culting of these oddities, etc.) > > > > > > https://codereview.chromium.org/188693006/ > > > > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org.
On Fri, Mar 7, 2014 at 2:40 PM, <viettrungluu@chromium.org> wrote: > On 2014/03/07 22:30:07, Nico wrote: > > On Fri, Mar 7, 2014 at 2:17 PM, <mailto:viettrungluu@chromium.org> wrote: >> > > > On 2014/03/07 18:39:41, Nico wrote: >> > >> >> On 2014/03/07 18:35:35, yzshen1 wrote: >> >> > Hi, Nico. >> >> > >> >> > Would you please take another look? Thanks! >> >> >> > >> > build/common.gypi looks like the wrong place for me if this is only for >> >> >> > clients >> > >> >> of mojo. I'd either make the mojo dylib push this into its >> >> direct_dependent_settings, or, probably better, have a mojo_user.gypi >> that >> >> >> > adds >> > >> >> this and include that in things depending on this mojo dylibs. >> >> >> > >> > For your path question, see the section "DYNAMIC LIBRARY LOADING" at >> the >> >> >> > bottom >> > >> >> of >> >> >> > >> > https://developer.apple.com/library/mac/documentation/ >> > Darwin/Reference/ManPages/man1/dyld.1.html >> > >> > So @loader_path/ is the directory of the mach-o binary (i.e., >> .../MacOS/) >> > not >> > the directory containing the bundle, and so it should be fine >> > security-wise, no? >> > >> > > Possibly, but adding this to all binaries is still unnecessary. >> > > What's the cost for doing so? http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privil... It adds stuff that most programs won't need. > (Vs the cost of scratching our heads over weird > things in lots of .gyp files, necessary and unnecessary cargo-culting of > these > oddities, etc.) The cost of scratching our heads over weird things in lots of .gyp files has to be paid as long as we have gyp. One way to prevent unnecessary cargo-culting of gyp stuff is code review, which you see in action right here :-) > > > > > > >> > https://codereview.chromium.org/188693006/ >> > >> > > To unsubscribe from this group and stop receiving emails from it, send an >> > email > >> to mailto:chromium-reviews+unsubscribe@chromium.org. >> > > > > https://codereview.chromium.org/188693006/ > To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2014/03/07 22:45:17, Nico wrote: > On Fri, Mar 7, 2014 at 2:40 PM, <mailto:viettrungluu@chromium.org> wrote: > > > On 2014/03/07 22:30:07, Nico wrote: > > > > On Fri, Mar 7, 2014 at 2:17 PM, <mailto:viettrungluu@chromium.org> wrote: > >> > > > > > On 2014/03/07 18:39:41, Nico wrote: > >> > > >> >> On 2014/03/07 18:35:35, yzshen1 wrote: > >> >> > Hi, Nico. > >> >> > > >> >> > Would you please take another look? Thanks! > >> >> > >> > > >> > build/common.gypi looks like the wrong place for me if this is only for > >> >> > >> > clients > >> > > >> >> of mojo. I'd either make the mojo dylib push this into its > >> >> direct_dependent_settings, or, probably better, have a mojo_user.gypi > >> that > >> >> > >> > adds > >> > > >> >> this and include that in things depending on this mojo dylibs. > >> >> > >> > > >> > For your path question, see the section "DYNAMIC LIBRARY LOADING" at > >> the > >> >> > >> > bottom > >> > > >> >> of > >> >> > >> > > >> > https://developer.apple.com/library/mac/documentation/ > >> > Darwin/Reference/ManPages/man1/dyld.1.html > >> > > >> > So @loader_path/ is the directory of the mach-o binary (i.e., > >> .../MacOS/) > >> > not > >> > the directory containing the bundle, and so it should be fine > >> > security-wise, no? > >> > > >> > > > > Possibly, but adding this to all binaries is still unnecessary. > >> > > > > What's the cost for doing so? > > > http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privil... > It adds stuff that most programs won't need. To be balanced with the burden of divergent behavior on different platforms. Even if security were the only criterion (in which case we could probably do a lot more on a platform-by-platform basis), the engineering time spent dealing with such things means time spent not doing other beneficial things. > > > > (Vs the cost of scratching our heads over weird > > things in lots of .gyp files, necessary and unnecessary cargo-culting of > > these > > oddities, etc.) > > > The cost of scratching our heads over weird things in lots of .gyp files > has to be paid as long as we have gyp. That's a pretty lame excuse. This is an opportunity to make Mac consistent with other platforms at very little cost. > > One way to prevent unnecessary cargo-culting of gyp stuff is code review, > which you see in action right here :-) Seems unlikely, since most .gyp changes are just rubberstamped. > > > > > > > > > > > > > > >> > https://codereview.chromium.org/188693006/ > >> > > >> > > > > To unsubscribe from this group and stop receiving emails from it, send an > >> > > email > > > >> to mailto:chromium-reviews+unsubscribe@chromium.org. > >> > > > > > > > > https://codereview.chromium.org/188693006/ > > > > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org.
Patch set 4 lgtm. The common.gypi patch doesn't.
Fine, LGTM. I'll just have to sneak in the common.gypi change behind Nico's back some other time.
Thanks a lot, Nico and Trung! I am quite interested in GN-izing the mojo project. Maybe that will solve the problem in a nicer way. On Fri, Mar 7, 2014 at 3:09 PM, <viettrungluu@chromium.org> wrote: > Fine, LGTM. I'll just have to sneak in the common.gypi change behind > Nico's back > some other time. > > https://codereview.chromium.org/188693006/ > -- Best regards, Yuzhu Shen. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
The CQ bit was checked by yzshen@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/yzshen@chromium.org/188693006/60001
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/yzshen@chromium.org/188693006/60001
The CQ bit was unchecked by commit-bot@chromium.org
Retried try job too often on mac_rel for step(s) telemetry_perf_unittests http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...
Message was sent while issue was closed.
Committed patchset #4 manually as r255791 (presubmit successful). |
