share all the needed linux code with OpenBSD in chrome and content

share all the needed linux code with OpenBSD in chrome and content

disabled code for OpenBSD:
  - AdjustRendererOOMScore()
  - SECCOMP_SANDBOX

BUG=
TEST=compile


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=109679

[Robert Nagy, 2011-10-26 11:15:18]

Please review the following the diff.

[Robert Nagy, 2011-10-26 19:29:24]

Adding Mark in case he wants to have a look.

[jam, 2011-10-26 21:53:52]

content lgtm

[Mark Mentovai, 2011-10-26 23:24:28]

http://codereview.chromium.org/8341052/diff/1/chrome/common/multi_process_lock.h
File chrome/common/multi_process_lock.h (right):

http://codereview.chromium.org/8341052/diff/1/chrome/common/multi_process_loc...
chrome/common/multi_process_lock.h:20: // The length of a multi-process lock
name is limited on Linux, so
This comment indicates that MULTI_PROCESS_LOCK_NAME_MAX_LEN was chosen so that a
single limit would work on all platforms. However, I don’t know if that’s
useful. Exposing this as a public part of the MultiProcessLock interface is
pointless.

I suggest removing this cross-platform limitation and instead placing
appropriate restrictions in each platform’s multi_process_lock implementation.
multi_process_lock_linux.cc would treat sizeof(sun.sun_path) - 2 as the maximum
name length, where sun is of type sockaddr_un.

Per http://msdn.microsoft.com/en-us/library/ms682396(VS.85).aspx, Windows looks
to have a MAX_PATH limitation.

http://developer.apple.com/library/mac/#documentation/CoreFoundation/Referenc...
doesn’t state what the limit is for multi_process_lock_mac, but I’m sure there
is one. It’s probably 127 or 128 (BOOTSTRAP_MAX_NAME_LEN from
<servers/bootstrap.h>) but it’s best to test this.

http://codereview.chromium.org/8341052/diff/1/chrome/test/automation/proxy_la...
File chrome/test/automation/proxy_launcher.cc (right):

http://codereview.chromium.org/8341052/diff/1/chrome/test/automation/proxy_la...
chrome/test/automation/proxy_launcher.cc:32: #if defined(OS_OPENBSD)
This file uses kill() and SIGTERM on OS_POSIX. This #if should refer to
OS_POSIX.

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
File content/browser/gpu/gpu_blacklist.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
content/browser/gpu/gpu_blacklist.cc:854: #elif defined(OS_LINUX) ||
defined(OS_OPENBSD)
I’m pretty sure the OS relevance here has to do with drivers. OpenBSD and Linux
don’t share video drivers, do they? If not, adding this “or” isn’t appropriate.

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
File content/browser/gpu/gpu_blacklist_unittest.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
content/browser/gpu/gpu_blacklist_unittest.cc:192: #if defined(OS_WIN) ||
defined(OS_LINUX) || defined(OS_MACOSX) || defined(OS_OPENBSD)
Watch the 80-character limitation. Use a \ if you need one.

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
File content/browser/zygote_host_linux.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
content/browser/zygote_host_linux.cc:309: #if defined(OS_LINUX)
It’s weird to see this in a _linux file. Can you change it to
!defined(OS_OPENBSD)? Same elsewhere in this file.

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_main_lin...
File content/browser/zygote_main_linux.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_main_lin...
content/browser/zygote_main_linux.cc:761: #if defined(OS_LINUX)
And here.

[stevenjb, 2011-10-27 16:01:54]

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
File content/browser/zygote_host_linux.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
content/browser/zygote_host_linux.cc:309: #if defined(OS_LINUX)
On 2011/10/26 23:24:28, Mark Mentovai wrote:
> It’s weird to see this in a _linux file. Can you change it to
> !defined(OS_OPENBSD)? Same elsewhere in this file.
It is even weirder to be including _linux files in openbsd builds, but not
defining OS_LINUX. I recognize this might be a significant undertaking, but
shouldn't we do it one way or the other, i.e. #define OS_LINUX for openbsd
builds and add #if !defined(OS_OPENBSD) where necessary (like we do for
chromeos), or create _openbsd versions of files where required (and don't
include _linux files)?

[Robert Nagy, 2011-10-27 16:14:37]

On 2011/10/27 16:01:54, Steven Bennetts wrote:
>
http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
> File content/browser/zygote_host_linux.cc (right):
> 
>
http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
> content/browser/zygote_host_linux.cc:309: #if defined(OS_LINUX)
> On 2011/10/26 23:24:28, Mark Mentovai wrote:
> > It’s weird to see this in a _linux file. Can you change it to
> > !defined(OS_OPENBSD)? Same elsewhere in this file.
> It is even weirder to be including _linux files in openbsd builds, but not
> defining OS_LINUX. I recognize this might be a significant undertaking, but
> shouldn't we do it one way or the other, i.e. #define OS_LINUX for openbsd
> builds and add #if !defined(OS_OPENBSD) where necessary (like we do for
> chromeos), or create _openbsd versions of files where required (and don't
> include _linux files)?

There are too many _linux files that are required so it does not really make
sense to copy all of those to _openbsd then _freebsd then _netbsd.
What I plan to do when I am finished with the openbsd parts is to introduce
OS_BSD which will shorten a lot of ifdefs.
Yes I agree that having non-linux specific ifdefs in linux files is weird and
confusing but it's all because poor naming was choosen for these files in the
first place.

The other problem is that without having all of the bsd support outside of the
official repository is a pain to maintain because we have to maintain over 150
patches and each time a new release comes, we have to redo most of them, so the
goal is to have everything in the chromium repository then slowly cleanup all
the stuff which includes moving _linux and other files to their proper names.

A good example of this was a commit 2 days ago that renamed
file_path_watcher_mac to file_path_watcher_kqueue because the file only contains
code for kqueue which is not mac specific at all.

Anyways, i think people can live with these few ifdefs until it gets cleaned up.

[Robert Nagy, 2011-10-27 16:17:41]

On 2011/10/27 16:14:37, Robert Nagy wrote:
> On 2011/10/27 16:01:54, Steven Bennetts wrote:
> >
>
http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
> > File content/browser/zygote_host_linux.cc (right):
> > 
> >
>
http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
> > content/browser/zygote_host_linux.cc:309: #if defined(OS_LINUX)
> > On 2011/10/26 23:24:28, Mark Mentovai wrote:
> > > It’s weird to see this in a _linux file. Can you change it to
> > > !defined(OS_OPENBSD)? Same elsewhere in this file.
> > It is even weirder to be including _linux files in openbsd builds, but not
> > defining OS_LINUX. I recognize this might be a significant undertaking, but
> > shouldn't we do it one way or the other, i.e. #define OS_LINUX for openbsd
> > builds and add #if !defined(OS_OPENBSD) where necessary (like we do for
> > chromeos), or create _openbsd versions of files where required (and don't
> > include _linux files)?
> 
> There are too many _linux files that are required so it does not really make
> sense to copy all of those to _openbsd then _freebsd then _netbsd.
> What I plan to do when I am finished with the openbsd parts is to introduce
> OS_BSD which will shorten a lot of ifdefs.
> Yes I agree that having non-linux specific ifdefs in linux files is weird and
> confusing but it's all because poor naming was choosen for these files in the
> first place.
> 
> The other problem is that without having all of the bsd support outside of the
> official repository is a pain to maintain because we have to maintain over 150
> patches and each time a new release comes, we have to redo most of them, so
the
> goal is to have everything in the chromium repository then slowly cleanup all
> the stuff which includes moving _linux and other files to their proper names.
> 
> A good example of this was a commit 2 days ago that renamed
> file_path_watcher_mac to file_path_watcher_kqueue because the file only
contains
> code for kqueue which is not mac specific at all.
> 
> Anyways, i think people can live with these few ifdefs until it gets cleaned
up.

For example it would be totally okay to rename zygote_{host,main}_linux.{cc,h}
to just zygote_{host,main}.{cc,h} because in the future at least 4 additional
platforms will use it.

[cpu_(ooo_6.6-7.5), 2011-10-28 03:02:47]

Robert, is there anything in particular I should be looking at? I defer any
posix changes to the people that actually know about that.

[Robert Nagy, 2011-10-31 15:38:38]

http://codereview.chromium.org/8341052/diff/1/chrome/common/multi_process_lock.h
File chrome/common/multi_process_lock.h (right):

http://codereview.chromium.org/8341052/diff/1/chrome/common/multi_process_loc...
chrome/common/multi_process_lock.h:20: // The length of a multi-process lock
name is limited on Linux, so
On 2011/10/26 23:24:28, Mark Mentovai wrote:
> This comment indicates that MULTI_PROCESS_LOCK_NAME_MAX_LEN was chosen so that
a
> single limit would work on all platforms. However, I don’t know if that’s
> useful. Exposing this as a public part of the MultiProcessLock interface is
> pointless.
> 
> I suggest removing this cross-platform limitation and instead placing
> appropriate restrictions in each platform’s multi_process_lock implementation.
> multi_process_lock_linux.cc would treat sizeof(sun.sun_path) - 2 as the
maximum
> name length, where sun is of type sockaddr_un.
> 
> Per http://msdn.microsoft.com/en-us/library/ms682396%28VS.85%29.aspx, Windows
looks
> to have a MAX_PATH limitation.
> 
>
http://developer.apple.com/library/mac/#documentation/CoreFoundation/Referenc...
> doesn’t state what the limit is for multi_process_lock_mac, but I’m sure there
> is one. It’s probably 127 or 128 (BOOTSTRAP_MAX_NAME_LEN from
> <servers/bootstrap.h>) but it’s best to test this.

I've done the modifications for the linux and the win file, and for mac I am
pretty sure we should use sizeof(sun.sun_path)

http://codereview.chromium.org/8341052/diff/1/chrome/test/automation/proxy_la...
File chrome/test/automation/proxy_launcher.cc (right):

http://codereview.chromium.org/8341052/diff/1/chrome/test/automation/proxy_la...
chrome/test/automation/proxy_launcher.cc:32: #if defined(OS_OPENBSD)
On 2011/10/26 23:24:28, Mark Mentovai wrote:
> This file uses kill() and SIGTERM on OS_POSIX. This #if should refer to
> OS_POSIX.

Done.

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
File content/browser/gpu/gpu_blacklist.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
content/browser/gpu/gpu_blacklist.cc:854: #elif defined(OS_LINUX) ||
defined(OS_OPENBSD)
On 2011/10/26 23:24:28, Mark Mentovai wrote:
> I’m pretty sure the OS relevance here has to do with drivers. OpenBSD and
Linux
> don’t share video drivers, do they? If not, adding this “or” isn’t
appropriate.

Actually they all use Mesa and DRI and the same xorg drivers, and libpci to
fetch the PCI ids of the GPU to see if it's compatible.

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
File content/browser/gpu/gpu_blacklist_unittest.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/gpu/gpu_blackli...
content/browser/gpu/gpu_blacklist_unittest.cc:192: #if defined(OS_WIN) ||
defined(OS_LINUX) || defined(OS_MACOSX) || defined(OS_OPENBSD)
On 2011/10/26 23:24:28, Mark Mentovai wrote:
> Watch the 80-character limitation. Use a \ if you need one.

Done.

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
File content/browser/zygote_host_linux.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_host_lin...
content/browser/zygote_host_linux.cc:309: #if defined(OS_LINUX)
On 2011/10/26 23:24:28, Mark Mentovai wrote:
> It’s weird to see this in a _linux file. Can you change it to
> !defined(OS_OPENBSD)? Same elsewhere in this file.

Done.

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_main_lin...
File content/browser/zygote_main_linux.cc (right):

http://codereview.chromium.org/8341052/diff/1/content/browser/zygote_main_lin...
content/browser/zygote_main_linux.cc:761: #if defined(OS_LINUX)
On 2011/10/26 23:24:28, Mark Mentovai wrote:
> And here.

Done.

[Mark Mentovai, 2011-10-31 15:47:40]

http://codereview.chromium.org/8341052/diff/1/chrome/common/multi_process_lock.h
File chrome/common/multi_process_lock.h (right):

http://codereview.chromium.org/8341052/diff/1/chrome/common/multi_process_loc...
chrome/common/multi_process_lock.h:20: // The length of a multi-process lock
name is limited on Linux, so
Robert Nagy wrote:
> I've done the modifications for the linux and the win file, and for mac I am
> pretty sure we should use sizeof(sun.sun_path)

Why? Mac’s not using the sockets interface for this at all.

http://codereview.chromium.org/8341052/diff/10002/chrome/common/multi_process...
File chrome/common/multi_process_lock_win.cc (right):

http://codereview.chromium.org/8341052/diff/10002/chrome/common/multi_process...
chrome/common/multi_process_lock_win.cc:27: if (name_.length() > MAX_PATH) {
Should this be >= to leave room for a 0-terminator?

[cpu_(ooo_6.6-7.5), 2011-10-31 19:26:08]

http://codereview.chromium.org/8341052/diff/10002/chrome/common/multi_process...
File chrome/common/multi_process_lock_win.cc (right):

http://codereview.chromium.org/8341052/diff/10002/chrome/common/multi_process...
chrome/common/multi_process_lock_win.cc:32: 
I hope this change does not mean that we are going to pass a path to this
function. See the restrictions of naming kernel objects in msdn.

[Robert Nagy, 2011-11-07 19:23:13]

http://codereview.chromium.org/8341052/diff/10002/chrome/common/multi_process...
File chrome/common/multi_process_lock_win.cc (right):

http://codereview.chromium.org/8341052/diff/10002/chrome/common/multi_process...
chrome/common/multi_process_lock_win.cc:27: if (name_.length() > MAX_PATH) {
On 2011/10/31 15:47:40, Mark Mentovai wrote:
> Should this be >= to leave room for a 0-terminator?

Done.

http://codereview.chromium.org/8341052/diff/10002/chrome/common/multi_process...
chrome/common/multi_process_lock_win.cc:32: 
On 2011/10/31 19:26:09, cpu wrote:
> I hope this change does not mean that we are going to pass a path to this
> function. See the restrictions of naming kernel objects in msdn.
> 

MAX_PATH and MULTI_PROCESS_LOCK_NAME_MAX_LEN is just a limit that we check for.

[Mark Mentovai, 2011-11-07 20:00:05]

LGTM

[cpu_(ooo_6.6-7.5), 2011-11-08 02:16:09]

lgtm

[Robert Nagy, 2011-11-09 20:03:26]

On 2011/11/08 02:16:09, cpu wrote:
> lgtm

Do we need other lgtms for this? These changes are totally safe except for the
multi process lock, but I guess the trybot will tell more about that.

[Mark Mentovai, 2011-11-09 20:32:18]

You’re probably fine on LGTMs now. I’ll feed it to the CQ.

[commit-bot: I haz the power, 2011-11-09 20:32:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/robert.nagy@gmail.com/8341052/18033

[commit-bot: I haz the power, 2011-11-09 20:32:46]

Can't apply patch for file chrome/common/multi_process_lock_linux.cc.
While running patch -p1 --forward --force;
patching file chrome/common/multi_process_lock_linux.cc
Hunk #1 FAILED at 24.
1 out of 1 hunk FAILED -- saving rejects to file
chrome/common/multi_process_lock_linux.cc.rej

[Robert Nagy, 2011-11-09 20:45:27]

On 2011/11/09 20:32:46, I haz the power (commit-bot) wrote:
> Can't apply patch for file chrome/common/multi_process_lock_linux.cc.
> While running patch -p1 --forward --force;
> patching file chrome/common/multi_process_lock_linux.cc
> Hunk #1 FAILED at 24.
> 1 out of 1 hunk FAILED -- saving rejects to file
> chrome/common/multi_process_lock_linux.cc.rej

rebased. CQ it again please.

[Mark Mentovai, 2011-11-09 20:49:14]

LGTM

[commit-bot: I haz the power, 2011-11-09 20:49:34]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/robert.nagy@gmail.com/8341052/26001

[commit-bot: I haz the power, 2011-11-09 20:49:52]

Presubmit check for 8341052-26001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit Messages **
If this change has an associated bug, add BUG=[bug number].

** Presubmit ERRORS **
Missing LGTM from an OWNER for:
chrome/browser/net/connection_tester.cc,chrome/browser/policy/browser_policy_connector.cc

Presubmit checks took 4.4s to calculate.

[Robert Nagy, 2011-11-09 20:58:19]

willchan, Mattias, please review the remaining two files.

Thank you

[willchan no longer on Chromium, 2011-11-09 21:22:09]

lgtm

[Mattias Nissler (ping if slow), 2011-11-10 00:17:53]

http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
File chrome/browser/policy/browser_policy_connector.cc (right):

http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
chrome/browser/policy/browser_policy_connector.cc:447: #elif defined(OS_POSIX)
&& !defined(OS_OPENBSD)
So no policy support for chromium on OpenBSD? The Linux implementation should
work, why disable it?

[Robert Nagy, 2011-11-10 09:35:22]

On 2011/11/10 00:17:53, Mattias Nissler wrote:
>
http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
> File chrome/browser/policy/browser_policy_connector.cc (right):
> 
>
http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
> chrome/browser/policy/browser_policy_connector.cc:447: #elif defined(OS_POSIX)
> && !defined(OS_OPENBSD)
> So no policy support for chromium on OpenBSD? The Linux implementation should
> work, why disable it?
Right. I've re-enabled it.

[Mattias Nissler (ping if slow), 2011-11-10 09:38:37]

On 2011/11/10 09:35:22, Robert Nagy wrote:
> On 2011/11/10 00:17:53, Mattias Nissler wrote:
> >
>
http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
> > File chrome/browser/policy/browser_policy_connector.cc (right):
> > 
> >
>
http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
> > chrome/browser/policy/browser_policy_connector.cc:447: #elif
defined(OS_POSIX)
> > && !defined(OS_OPENBSD)
> > So no policy support for chromium on OpenBSD? The Linux implementation
should
> > work, why disable it?
> Right. I've re-enabled it.

Cool, thanks. Now you don't need my approval any longer :)

[Robert Nagy, 2011-11-10 09:39:27]

On 2011/11/10 09:38:37, Mattias Nissler wrote:
> On 2011/11/10 09:35:22, Robert Nagy wrote:
> > On 2011/11/10 00:17:53, Mattias Nissler wrote:
> > >
> >
>
http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
> > > File chrome/browser/policy/browser_policy_connector.cc (right):
> > > 
> > >
> >
>
http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/brows...
> > > chrome/browser/policy/browser_policy_connector.cc:447: #elif
> defined(OS_POSIX)
> > > && !defined(OS_OPENBSD)
> > > So no policy support for chromium on OpenBSD? The Linux implementation
> should
> > > work, why disable it?
> > Right. I've re-enabled it.
> 
> Cool, thanks. Now you don't need my approval any longer :)

Oh i tought i need an LGTM from you :)

[Mattias Nissler (ping if slow), 2011-11-10 09:43:31]

On Thu, Nov 10, 2011 at 10:39 AM, <robert.nagy@gmail.com> wrote:

> On 2011/11/10 09:38:37, Mattias Nissler wrote:
>
>> On 2011/11/10 09:35:22, Robert Nagy wrote:
>> > On 2011/11/10 00:17:53, Mattias Nissler wrote:
>> > >
>> >
>>
>
> http://codereview.chromium.**org/8341052/diff/26001/chrome/**
>
browser/policy/browser_policy_**connector.cc<http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/browser_policy_connector.cc>
>
>> > > File chrome/browser/policy/browser_**policy_connector.cc (right):
>> > >
>> > >
>> >
>>
>
> http://codereview.chromium.**org/8341052/diff/26001/chrome/**
>
browser/policy/browser_policy_**connector.cc#newcode447<http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/browser_policy_connector.cc#newcode447>
>
>> > > chrome/browser/policy/browser_**policy_connector.cc:447: #elif
>> defined(OS_POSIX)
>> > > && !defined(OS_OPENBSD)
>> > > So no policy support for chromium on OpenBSD? The Linux implementation
>> should
>> > > work, why disable it?
>> > Right. I've re-enabled it.
>>
>
>  Cool, thanks. Now you don't need my approval any longer :)
>>
>
> Oh i tought i need an LGTM from you :)
>

Because chrome/browser/policy is no longer part of the patch, technically
you no longer need it :) But not switching off policy for OpenBSD certainly
LGTM!


>
http://codereview.chromium.**org/8341052/<http://codereview.chromium.org/8341...
>

[Robert Nagy, 2011-11-10 09:47:37]

On 2011/11/10 09:43:31, Mattias Nissler wrote:
> On Thu, Nov 10, 2011 at 10:39 AM, <mailto:robert.nagy@gmail.com> wrote:
> 
> > On 2011/11/10 09:38:37, Mattias Nissler wrote:
> >
> >> On 2011/11/10 09:35:22, Robert Nagy wrote:
> >> > On 2011/11/10 00:17:53, Mattias Nissler wrote:
> >> > >
> >> >
> >>
> >
> > http://codereview.chromium.**org/8341052/diff/26001/chrome/**
> >
>
browser/policy/browser_policy_**connector.cc<http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/browser_policy_connector.cc>
> >
> >> > > File chrome/browser/policy/browser_**policy_connector.cc (right):
> >> > >
> >> > >
> >> >
> >>
> >
> > http://codereview.chromium.**org/8341052/diff/26001/chrome/**
> >
>
browser/policy/browser_policy_**connector.cc#newcode447<http://codereview.chromium.org/8341052/diff/26001/chrome/browser/policy/browser_policy_connector.cc#newcode447>
> >
> >> > > chrome/browser/policy/browser_**policy_connector.cc:447: #elif
> >> defined(OS_POSIX)
> >> > > && !defined(OS_OPENBSD)
> >> > > So no policy support for chromium on OpenBSD? The Linux implementation
> >> should
> >> > > work, why disable it?
> >> > Right. I've re-enabled it.
> >>
> >
> >  Cool, thanks. Now you don't need my approval any longer :)
> >>
> >
> > Oh i tought i need an LGTM from you :)
> >
> 
> Because chrome/browser/policy is no longer part of the patch, technically
> you no longer need it :) But not switching off policy for OpenBSD certainly
> LGTM!
> 
> 
> >
>
http://codereview.chromium.**org/8341052/%3Chttp://codereview.chromium.org/83...>
> >

Ehhehe, right :) i guess i need another coffee.

[commit-bot: I haz the power, 2011-11-10 14:37:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/robert.nagy@gmail.com/8341052/24003

[commit-bot: I haz the power, 2011-11-10 15:36:26]

Try job failure for 8341052-24003 (retry) on mac_rel for step "compile" (clobber
build).
It's a second try, previously, step "compile" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[Robert Nagy, 2011-11-10 16:59:15]

On 2011/11/10 15:36:26, I haz the power (commit-bot) wrote:
> Try job failure for 8341052-24003 (retry) on mac_rel for step "compile"
(clobber
> build).
> It's a second try, previously, step "compile" failed.
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

patchset 7 should fix these

[commit-bot: I haz the power, 2011-11-11 17:43:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/robert.nagy@gmail.com/8341052/36001

[commit-bot: I haz the power, 2011-11-11 17:44:01]

Presubmit check for 8341052-36001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit Messages **
If this change has an associated bug, add BUG=[bug number].

** Presubmit Warnings **
Found lines longer than 80 characters (first 5 shown).
  chrome/common/multi_process_lock_unittest.cc, line 87, 85 chars \
  chrome/common/multi_process_lock_unittest.cc, line 92, 84 chars

Presubmit checks took 4.8s to calculate.

[Mark Mentovai, 2011-11-11 17:49:16]

LGTM and CQ

[commit-bot: I haz the power, 2011-11-11 17:50:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/robert.nagy@gmail.com/8341052/42003

[commit-bot: I haz the power, 2011-11-11 19:56:38]

Change committed as 109679