I think it would be an interesting experiment as well.
The paper provided a lot of interesting information on DRAM failure
rates, but I don't think you can infer failure rates about the
general population solely from examining the DRAM failures in a very
isolated (though large) population such
On Sun, Oct 11, 2009 at 6:41 PM, Anthony LaForge lafo...@google.com wrote:
Hey man, this url doesn't seem to be resolving anymore:
Ooops. I have a fix and will restart the master in a few minutes. Sorry
about that.
Nicolas
On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten thoma...@chromium.orgwrote:
Looks like the failures link needs to be updated in waterfall header.
I'm pretty sure I did, can you show me which one is not updated?
TVL
On Sat, Oct 10, 2009 at 9:25 PM, Nicolas Sylvain
On Mon, Oct 12, 2009 at 10:45 AM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten
thoma...@chromium.orgwrote:
Looks like the failures link needs to be updated in waterfall header.
I'm pretty sure I did, can you show me which one is not
On Mon, Oct 12, 2009 at 7:58 AM, Thomas Van Lenten thoma...@chromium.orgwrote:
On Mon, Oct 12, 2009 at 10:45 AM, Nicolas Sylvain
nsylv...@chromium.orgwrote:
On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten thoma...@chromium.org
wrote:
Looks like the failures link needs to be
Does this relate to receiving crashbot emails adding Crash labels on
closed-out bugs where the backtrace doesn't apparently have any
relevance to the original backtraces involved with the bug? I've
gotten a couple of these in the past week.
-scott
[Unfortunately, I don't remember the earlier
I just had crashbot add a totally unrelated stack trace to a bug. I
emailed anthony about it, we'll see.
Something is clearly wrong.
On Mon, Oct 12, 2009 at 12:41 PM, Scott Hess sh...@chromium.org wrote:
Does this relate to receiving crashbot emails adding Crash labels on
closed-out bugs
On Fedora systems we'll be able to do Real Sandboxing due to SELinux.
An SELinux developer took a crack at it:
http://danwalsh.livejournal.com/32759.html
However, it looks like he's sandboxing our chroot sandbox (?). I
don't much understand this stuff, but I think on Fedora we should
probably
On Mon, Oct 12, 2009 at 10:46 AM, Evan Martin e...@chromium.org wrote:
In general, it'd be nice to reach out to Dan since he's likely to know
better than anyone here about the right way to do this. I'll link him
to this thread from his post.
I've already emailed him about this, explaining
On Mon, Oct 12, 2009 at 10:53 AM, Adam Langley a...@chromium.org wrote:
On Sun, Oct 11, 2009 at 8:39 AM, Evan Martin e...@chromium.org wrote:
I think we should to preemptively set the GDK_NATIVE_WINDOWS
environment variable mentioned there in our launcher until we've
tested it, since this
On Sun, Oct 11, 2009 at 8:39 AM, Evan Martin e...@chromium.org wrote:
I think we should to preemptively set the GDK_NATIVE_WINDOWS
environment variable mentioned there in our launcher until we've
tested it, since this change will surely break us.
We use native Xlib calls for the backing store
So, the background story here is as follows: in Windows, the typical toolbar
will have one tabstop (accessible through tab or shift-tab) on the whole
toolbar, and buttons will then be traversable using left and right arrow
keys. For instance, this behavior can be seen in the Quick Launch toolbar,
Nacl/O3d*trybots seem ok on a restart.-BradN
On Mon, Oct 12, 2009 at 8:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote:
On Mon, Oct 12, 2009 at 7:58 AM, Thomas Van Lenten
thoma...@chromium.orgwrote:
On Mon, Oct 12, 2009 at 10:45 AM, Nicolas Sylvain
nsylv...@chromium.orgwrote:
On
Please confirm the bug http://code.google.com/p/chromium/issues/detail?id=12900
It really annoys me.
I expect that someone will fix it soon. I can provide more examples if
needed.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
I think the bigger issue is how/when Area-Misc bugs get triaged. Do they
ever? If not, we should probably change that.
On Mon, Oct 12, 2009 at 11:50 AM, Guria guria...@gmail.com wrote:
Please confirm the bug
http://code.google.com/p/chromium/issues/detail?id=12900
It really annoys me.
I
On Mon, Oct 12, 2009 at 20:53, Jeremy Orlow jor...@chromium.org wrote:
I think the bigger issue is how/when Area-Misc bugs get triaged. Do they
ever? If not, we should probably change that.
I sometimes review old bugs and close those which no longer reproduce, and
ask for more details in
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov dglaz...@google.com wrote:
Today wasn't a happy day for p...@. He did a seemingly innocuous roll
that broke the world: selenium, ui tests, layout tests. I am sure it
was stressful and probably added unnecessary gray to his hair.
2) writers of
Our existing unit tests for file_util::CopyDirectory() do not test its
behavior when the destination directory already exists. The following CL:
http://codereview.chromium.org/271060/show
which adds unit tests for already-existing destination directories, shows
that Windows and POSIX behave
file_util::CopyDirectory is used by Windows installer so we really
need to make sure the change does not break installer.
Huan
On Mon, Oct 12, 2009 at 3:52 PM, Steven Knight s...@chromium.org wrote:
Our existing unit tests for file_util::CopyDirectory() do not test its
behavior when the
Yes Windows installer relies on this behavior. There are installer_unittests
which might cover this particular use case (in CopyTreeWorkItemTest) but I
am not sure.
On Mon, Oct 12, 2009 at 3:52 PM, Steven Knight s...@chromium.org wrote:
Our existing unit tests for file_util::CopyDirectory() do
On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote:
On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter
craig.schlen...@gmail.com wrote:
[big snip]
This problem only seems to happen with the scons shared build. The
make build does not have this problem so there seems to be
DBGHELP: c:\windows\symbols\chrome_dll.pdb - file not found
DBGHELP: c:\windows\symbols\dll\chrome_dll.pdb - file not found
DBGHELP: c:\windows\symbols\symbols\dll\chrome_dll.pdb - file not
found
SYMSRV: c:\downloads\symbols\chrome_dll.pdb
\B4977E8166FE42BCA9DD15A802A2E1D91\chrome_dll.pdb not
Maybe you need to clobber? The shared build bot on the FYI waterfall
is working:
http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069
On Mon, Oct 12, 2009 at 6:23 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Wed, Oct 07, 2009 at
For version 3.0.195.25, BTW.
On Oct 12, 6:25 pm, yuhong yuhongbao_...@hotmail.com wrote:
DBGHELP: c:\windows\symbols\chrome_dll.pdb - file not found
DBGHELP: c:\windows\symbols\dll\chrome_dll.pdb - file not found
DBGHELP: c:\windows\symbols\symbols\dll\chrome_dll.pdb - file not
found
On Mon, Oct 12, 2009 at 06:29:02PM -0700, Lei Zhang wrote:
Maybe you need to clobber? The shared build bot on the FYI waterfall
is working:
http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069
gclient runhooks regenerated a bunch
25 matches
Mail list logo
