[chromium-dev] Re: Don't include render_messages.h in a header
On Thu, Feb 5, 2009 at 4:21 PM, James Vega wrote: > > On Thu, Feb 05, 2009 at 04:04:58PM -0800, Peter Kasting wrote: >> On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay wrote: >> >> > $ scons_deps -v >> > foo.c:inc.h:a.h >> > foo.c:inc.h:b.h >> > bar.c:bar.h >> > etc. >> > >> > Does such a script (or something similar) exist? From what you're >> > saying, I'm assuming it's easy to write. >> >> >> Note that you could always tell MSVC to turn on printing #include chains for >> each compiled file, then compile the various files you're interested in. >> From this you could probably create a reverse-mapping if you wanted... > > The same can be done with gcc/g++ by passing the -H argument when > compiling. I did the same with -MM and parsed the results. Assuming I did it right, the average .cc file in src/chrome/ includes about 135 header files. The files with the most number of includes: 440 about_chrome_view.o 470 options_window_view.o 481 history_ui.o 483 user_data_dir_dialog.o 544 dns_host_info_unittest.o 601 aero_glass_non_client_view.o --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Don't include render_messages.h in a header
On Thu, Feb 5, 2009 at 4:21 PM, James Vega wrote: > > On Thu, Feb 05, 2009 at 04:04:58PM -0800, Peter Kasting wrote: >> On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay wrote: >> >> > $ scons_deps -v >> > foo.c:inc.h:a.h >> > foo.c:inc.h:b.h >> > bar.c:bar.h >> > etc. >> > >> > Does such a script (or something similar) exist? From what you're >> > saying, I'm assuming it's easy to write. >> >> >> Note that you could always tell MSVC to turn on printing #include chains for >> each compiled file, then compile the various files you're interested in. >> From this you could probably create a reverse-mapping if you wanted... > > The same can be done with gcc/g++ by passing the -H argument when > compiling. I did the same with -MM and parsed the results. Assuming I did it right, the average .cc file in src/chrome/ includes about 135 header files. The files with the most number of includes: 440 about_chrome_view.o 470 options_window_view.o 481 history_ui.o 483 user_data_dir_dialog.o 544 dns_host_info_unittest.o 601 aero_glass_non_client_view.o --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Claimings
We're trying out a spreadsheet on the Linux side. http://spreadsheets.google.com/ccc?key=prV2wWigilGslQBvu76GpQQ On Mon, Feb 9, 2009 at 3:37 PM, John Grabowski wrote: > (We talked about a spreadsheet for this... anyone have a link?) > I'm following the chain from " on URL in browser" --> "tell renderer do > something". This currently ends at tabs; I'm removing stubs (TabContents, > TabContentsDelegate, ...) and bringing in the real thing. > jrg > > On Mon, Feb 9, 2009 at 1:12 PM, Thomas Van Lenten > wrote: >> >> Follow up from the other week - >> >> I'm still digging into ProcessUtil::LaunchApp and the fall out from >> there. The current code in unittests and w/in chromium depends on a few >> things that windows offers since it gets handlers for this, the Mac & Linux >> world can't really map things like this, so we're going to end up needed a >> slightly beefer process object to provide some of what is needed (hopefully >> we'll be able to leave the unittests on the current api for now, the >> problems doesn't really cause the tests issues (or we've fixed them)). >> >> TVL >> >> >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: thread_collision_warning error on build bot?
I've seen it happen a couple times on Windows with the trybots this week. (and only this week) On Thu, Feb 12, 2009 at 8:20 AM, Thomas Van Lenten wrote: > Before I start digging, anyone seen this failure before (one mac build bot > hit it today): > > [ RUN ] ConditionVariableTest.LargeFastTaskTest > [62774:267:0212/081020:1473451641256476:FATAL:/b/slave/sub-dbg-mac/build/src/base/thread_collision_warner.cc(13)] > Check failed: false. Thread Collision > > [62774:267:0212/081020:1473451641256476:FATAL:/b/slave/sub-dbg-mac/build/src/base/thread_collision_warner.cc(13)] > Check failed: false. Thread Collision > > That doesn't sound like something that should be flaky... > > TVL > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten wrote: > Sorry for arriving late w/ this question... > > I'm guessing NSS & NSPR are needed for the linux build? Should they be > pulled in via DEPS instead of being directly in src/third_party? In the > current form it causes both mac and windows to have to add ~80M to their svn > trees that really isn't needed. > > TVL > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows
#include
#include
int main()
{
HWND hwnd = GetAncestor(NULL, GA_PARENT);
printf("%p\n", hwnd);
hwnd = GetAncestor(NULL, GA_ROOT);
printf("%p\n", hwnd);
hwnd = GetAncestor(NULL, GA_ROOTOWNER);
printf("%p\n", hwnd);
hwnd = GetAncestor(NULL, 0);
printf("%p\n", hwnd);
return 0;
}
printed four 0's for me on Vista.
On Thu, Mar 19, 2009 at 11:27 AM, Craig Schlenter
wrote:
>
> Hi
>
> OK, that's interesting, thank you. Does GetAncestor return something
> valid when passed that null HWND or does it pass null through to
> GetwindowRect? It would also be interesting to know what rect it
> returns please. Maybe it doesn't matter ... I haven't looked at the
> renderer code that creates this request to see if it actually cares
> about this when the window is null.
>
> Thank you,
>
> --Craig
>
> On Thu, Mar 19, 2009 at 7:56 PM, Mohamed Mansour
> wrote:
>> Craig, it returns back a 0.
>> + window 0x {unused=??? } HWND__ *
>>
>>
>>
>>
>> On Thu, Mar 19, 2009 at 1:46 PM, Craig Schlenter
>> wrote:
>>>
>>> Hi Avi
>>>
>>> When I did the original change, that function wasn't being called with
>>> a null window.
>>> Clicking on a link in gmail opened the link in a new window as I
>>> recall. At some later
>>> point that changed possibly when some of the tab_contents stuff was hooked
>>> up. I
>>> think it's good practice to check for null since you don't want the
>>> renderer to be able
>>> to crash the browser but I do tend to think that it shouldn't be
>>> happening to begin with
>>> but I'm largely clueless about the code involved :(
>>>
>>> Perhaps someone with a windows build can put a breakpoint in
>>> OnGetRootWindowRect please and see if clicking on a link in an
>>> email in gmail passes a HWND of null at all?
>>>
>>> Thank you,
>>>
>>> --Craig
>>>
>>> On Thu, Mar 19, 2009 at 7:33 PM, Avi Drissman wrote:
We've been seeing calls to ResourceMessageFilter::OnGet(Root)WindowRect for
NULL windows. agl put in a fix for GTK with
http://codereview.chromium.org/42356 and I'm seeing the same problem on the
Mac.
1. Why isn't Windows seeing this? What happens when you pass a null HWND
into ::GetAncestor and ::GetWindowRect?
2. Is this expected, or is this indicative of a bug?
Avi
>>>
>>> >>
>>>
>>
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: hammer build error
FWIW, I was running into linking errors today. Tony fixed it in
r14051. Thanks Tony!
On Mon, Apr 20, 2009 at 1:36 PM, Evan Martin wrote:
>
> I don't know the particular problem, but I recommend:
> 1) update once: gclient sync --force (I updated those "get the code"
> instructions)
> 2) delete the temp build output: rm -rf sconsbuild
> 3) install the build deps: ./build/install-build-deps.sh
> 4) try building again
>
> On Sun, Apr 19, 2009 at 8:24 PM, nshah wrote:
>>
>> Hello,
>>
>> I have been trying to build chrome on linux. I downloaded the latest
>> tarball ( chromium.r14008.tgz ) and am following the build
>> instructions on chrome wiki for linux.
>>
>> However, I get following error while in release mode:
>>
>> chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/third_party/
>> icu38/source/i18n/usearch.o
>> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/utmscale.o
>> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/utrans.o
>> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/vtzone.o
>> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/windtfmt.o
>> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/winnmfmt.o
>> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> chromium/src/base
>> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> chromium/src/sconsbuild/Release/obj/global_intermediate/base/
>> file_version_info_linux.bogus] Error 2
>> scons: building terminated because of errors.
>>
>>
>>
>>
>> while in debug mode:
>>
>> ~/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/build$ hammer
>> app
>> scons: Reading SConscript files ...
>> Mkdir("/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Debug")
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> chromium/src/webkit
>> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> chromium/src/webkit
>> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> chromium/src/sconsbuild/Debug/obj/webkit/webcore/intermediate/
>> CSSPropertyNames.cpp] Error 2
>> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> chromium/src/webkit
>> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> chromium/src/sconsbuild/Debug/obj/webkit/webcore/intermediate/
>> CSSValueKeywords.c] Error 2
>> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> chromium/src/sconsbuild/Debug/obj/webkit/webcore/intermediate/
>> HTMLNames.cpp] Error 2
>> scons: building terminated because of errors.
>>
>>
>>
>> I have been able to build earlier with tarball release
>> ( chromium.r10880.tgz). I compared my webcore.scons and saw that not
>> only /auto/filer28.mtvvolmtvhome51/ is not replaced with corresponding
>> actual system path. When I manually fixed that, I was able to go
>> little further but started to get following errors in cairo.h:
>>
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Release/obj/third_party/WebKit/WebCore/css/
>> CSSCanvasValue.o
>> In file included from /home/nidhi/ProgramFiles/v8/home/chrome-svn/
>> tarball/chromium/src/skia/ext/platform_canvas_linux.h:12,
>> from /home/nidhi/ProgramFiles/v8/home/chrome-svn/
>> tarball/chromium/src/skia/ext/platform_canvas.h:14,
>> from /home/nidhi/ProgramFiles/v8/home/chrome-svn/
>> tarball/chromium/src/third_party/WebKit/WebCore/platform/graphics/skia/
>> PlatformContextSkia.h:40,
>> from /home/nidhi/ProgramFiles/v8/home/chrome-svn/
>> tarball/chromium/src/third_party/WebKit/WebCore/platform/graphics/
>> chromium/ImageBufferData.h:34,
>> from /home/nidhi/ProgramFiles/v8/home/chrome-svn/
>> tarball/chromium/src/third_party/WebKit/WebCore/platform/graphics/
>> ImageBuffer.h:33,
>> from /home/nidhi/ProgramFiles/v8/home/chrome-svn/
>> tarball/chromium/src/third_party/WebKit/WebCore/css/CSSCanvasValue.cpp:
>> 29:
>> /usr/include/cairo/cairo.h:41:28: error: cairo-features.h: No such
>> file or directory
>> /usr/include/cairo/cairo.h:42:30: error: cairo-deprecated.h: No such
>> file or directory
>> In file included from /home/nidhi/ProgramFiles/v8/home/chrome-svn/
>> tarball/chromium/src/skia/ext/platform_canvas.h:
[chromium-dev] Re: hammer build error
With SVN. See: http://dev.chromium.org/developers/how-tos/get-the-code
On Mon, Apr 20, 2009 at 2:04 PM, nshah wrote:
>
> Thanks Guys!
> Evan, thanks for instructions list. Seems like thats what needed to be
> done. I am able to build the webkit project now, I have not tried
> building the chrome project (hammer app) yet.
>
> Lei, how did you get the r14051, right now when I try to download the
> tarball its r14025.
>
> Thanks,
>
>
> On Apr 20, 4:50 pm, Lei Zhang wrote:
>> FWIW, I was running into linking errors today. Tony fixed it in
>> r14051. Thanks Tony!
>>
>> On Mon, Apr 20, 2009 at 1:36 PM, Evan Martin wrote:
>>
>> > I don't know the particular problem, but I recommend:
>> > 1) update once: gclient sync --force (I updated those "get the code"
>> > instructions)
>> > 2) delete the temp build output: rm -rf sconsbuild
>> > 3) install the build deps: ./build/install-build-deps.sh
>> > 4) try building again
>>
>> > On Sun, Apr 19, 2009 at 8:24 PM, nshah wrote:
>>
>> >> Hello,
>>
>> >> I have been trying to build chrome on linux. I downloaded the latest
>> >> tarball ( chromium.r14008.tgz ) and am following the build
>> >> instructions on chrome wiki for linux.
>>
>> >> However, I get following error while in release mode:
>>
>> >> chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/third_party/
>> >> icu38/source/i18n/usearch.o
>> >> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> >> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/utmscale.o
>> >> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> >> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/utrans.o
>> >> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> >> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/vtzone.o
>> >> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> >> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/windtfmt.o
>> >> Compiling /home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> >> src/sconsbuild/Release/obj/third_party/icu38/source/i18n/winnmfmt.o
>> >> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> >> chromium/src/base
>> >> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> >> chromium/src/sconsbuild/Release/obj/global_intermediate/base/
>> >> file_version_info_linux.bogus] Error 2
>> >> scons: building terminated because of errors.
>>
>> >>
>>
>> >> while in debug mode:
>>
>> >> ~/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/build$ hammer
>> >> app
>> >> scons: Reading SConscript files ...
>> >> Mkdir("/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> >> src/sconsbuild/Debug")
>> >> scons: done reading SConscript files.
>> >> scons: Building targets ...
>> >> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> >> chromium/src/webkit
>> >> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> >> chromium/src/webkit
>> >> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> >> chromium/src/sconsbuild/Debug/obj/webkit/webcore/intermediate/
>> >> CSSPropertyNames.cpp] Error 2
>> >> cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/
>> >> chromium/src/webkit
>> >> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> >> chromium/src/sconsbuild/Debug/obj/webkit/webcore/intermediate/
>> >> CSSValueKeywords.c] Error 2
>> >> scons: *** [/home/nidhi/ProgramFiles/v8/home/chrome-svn/tarball/
>> >> chromium/src/sconsbuild/Debug/obj/webkit/webcore/intermediate/
>> >> HTMLNames.cpp] Error 2
>> >> scons: building terminated because of errors.
>>
>> >>
>>
>> >> I have been able to build earlier with tarball release
>> >> ( chromium.r10880.tgz). I compared my webcore.scons and saw that not
>> >> only /auto/filer28.mtvvolmtvhome51/ is not replaced with corresponding
>> >> actual system path. When I manually fixed that, I was able to go
>
[chromium-dev] Re: gcl and git-cl brokenness
I reverted r14094. On Tue, Apr 21, 2009 at 4:39 PM, Evan Martin wrote: > > Since it's been asked about 10 times in the channel so far: > > - gcl is broken in some way where it thinks PRESUBMIT.py is a changelist. > Workaround is to remove .svn/gcl_entries/PRESUBMIT.py . Lei is > working on reverting it. > > - M-A checked git-cl/git-try into depot_tools, but it doesn't work and > if you have depot_tools in your path it shadows the working one. I > leave it to you to work around (I just don't have depot_tools in my > path). > > Both are temporary and will be fixed when M-A is off his train, surely. :) > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [BUG][PATCH] Small issue with "page_action.h"
I created http://codereview.chromium.org/99309 for you. Thanks.
On Fri, May 1, 2009 at 4:25 PM, LivioSoares wrote:
>
> Dear Chromium folks,
>
> I was building revision 15114 this afternoon and was snagged by
> this:
>
> cc1plus: warnings being treated as errors
> In file included from /home/livio/src/chrome/chromium/src/chrome/
> browser/extensions/extension.h:19,
> from /home/livio/src/chrome/chromium/src/chrome/
> common/resource_bundle.h:21,
> from /home/livio/src/chrome/chromium/src/chrome/
> common/jstemplate_builder.cc:13:
> /home/livio/src/chrome/chromium/src/chrome/common/page_action.h:22:
> error: 'typedef' was ignored in this declaration
> scons: *** [/home/livio/src/chrome/chromium/src/sconsbuild/Release/obj/
> chrome/common/jstemplate_builder.o] Error 1
>
> I'm compiling under Linux (Debian/unstable), GCC version 4.3.3.
>
> It seems that the following small changes fixes it.
>
> Cheers,
>
> Livio
>
>> svn diff src/chrome/common/page_action.h
> Index: src/chrome/common/page_action.h
> ===
> --- src/chrome/common/page_action.h (revision 15114)
> +++ src/chrome/common/page_action.h (working copy)
> @@ -16,10 +16,10 @@
> PageAction();
> virtual ~PageAction();
>
> - typedef enum PageActionType {
> + typedef enum {
> PERMANENT = 0,
> TAB = 1,
> - };
> + } PageActionType;
>
> std::string id() const { return id_; }
> void set_id(std::string id) { id_ = id; }
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Getting LOG(INFO) to print
I'm having the opposite problem. I did a release build on Linux, and I get tons of INFO spew. --log-level=N for N > 0 doesn't turn it off. On Wed, Apr 22, 2009 at 11:37 AM, Evan Martin wrote: > > Since Pinkerton just lost some hours to this and I did again: > The secret to getting LOG(INFO) to show is to pass --log-level=0 when you run. > > I added this to http://code.google.com/p/chromium/wiki/LinuxDebugging > (which, by the way, has had a lot of content added since you last > looked). > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: No more local copy of WebCore and JavaScriptCore!
On Fri, May 8, 2009 at 10:20 AM, Dan Kegel wrote: > > On Fri, May 8, 2009 at 10:16 AM, Darin Fisher wrote: >>> gclient sync now crashes for me: >> >> That's unfortunate... I wonder what is different about your setup. The >> buildbots and trybots and my personal Linux box were all happy with the >> change. >> Maybe just try deleting all of third_party/WebKit, and then re-run gclient >> sync. > > Yes, that worked. I also had to delete third_party/WebKit. Gclient sync was crashing in CaptureSVNInfo() because the svn info --xml output was a skeleton XML file. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: A UI crash bug report
This is not the right place to report bugs. Use the bug tracker -> http://crbug.com/ When you create an issue in the bug tracker, please include all the information needed to reproduce the bug, including what version of Chrome you're using. On Mon, May 11, 2009 at 8:59 PM, 张亚霏 wrote: > hi all > "Every time" I click the "back" button with Ctrl pressed, the browse will > crashed. > > > Best wishes. > Kimi Zhang > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: i would like to help code chrome.. but i have some compilation issues (and unittest)
On Tue, May 12, 2009 at 6:19 AM, nakro wrote: > the other thing, is that after i modify it the unit tests fail > [ PASSED ] 864 tests. > [ FAILED ] 1 test, listed below: > [ FAILED ] URLFetcherBadHTTPSTest.BadHTTPSTest > > 1 FAILED TEST > YOU HAVE 19 DISABLED TESTS See http://dev.chromium.org/developers/testing under SSL tests. If you look through the entire output, you'd see: TEST CONFIGURATION ERROR: you need to import the test ca certificate to your trusted roots for this test to work. For more info visit: http://dev.chromium.org/developers/testing --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tool to dump out the render tree for chromium
The test shell has a dump render tree function under the debug menu. Does that help? On Sat, May 23, 2009 at 12:36 AM, Daniel Dreiberg wrote: > Hi, > Is there any tool to dump out the render tree for chromium? I would like to > pass an url (e.g. www.google.com), it dumps out the render tree after that > page is loaded (JS is executed)? > Thank you for any pointers. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: --single-process not working with Chrome 2.0?
It's always disabled in Chrome. It's all in the source code. See [1] line ~416. You can use Google Code Search to grep the code more quickly. For instance, if you search for single_process, you'll end up on [2] and oh look at the first result! [1] http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/chrome_dll_main.cc?view=markup [2] http://www.google.com/codesearch?hl=en&q=single_process&exact_package=http%3A%2F%2Fsrc.chromium.org%2Fsvn%2Ftrunk%2Fsrc On Mon, Jun 1, 2009 at 12:20 PM, vijay wrote: > > The --single-process command-line switch does not seem to be working > with Chrome 2.0. I'm running the latest released version of 2.0.172.28 > on Windows XP and even when using the switch, Chrome still starts up > with 2 processes. Then, when I go to a page with a plugin (NPAPI), it > creates a brand new process. Am I doing something wrong or did > something change with --single-process? > > Thanks in advance, > Vijay > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] nested messageloop patch landed
Aren't the bots in virtual machines? Since we're in the middle of some hardware upgrades, perhaps the new host machine isn't as loaded. Would that affect the performance numbers? I still remember the numbers from my box from the last time I made the numbers go the other way. It was in the 300-350 ms range. I ran the test again just now and it's down to ~200 ms. On Wed, Jun 3, 2009 at 3:25 PM, Lei Zhang wrote: > Aren't the bots in virtual machines? Since we're in the middle of some > hardware upgrades, perhaps the new host machine isn't as loaded. Would > that affect the performance numbers? > > I still remember the numbers from my box from the last time I made the > numbers go the other way. It was in the 300-350 ms range. I ran the > test again just now and it's down to ~200 ms. > > On Wed, Jun 3, 2009 at 2:56 PM, Evan Martin wrote: >> >> This patch, aside from fixing Antoine's problem and those other two >> bugs, seems to have significantly improved our startup time: >> http://build.chromium.org/buildbot/perf/linux-release/startup/report.html?history=150 >> >> (The second drop is due to running on new hardware.) >> >> I kinda suspect we're measuring something wrong, because we're down to 65ms >> (!). >> >> On Mon, Jun 1, 2009 at 3:04 PM, Evan Martin wrote: >>> Antoine wrote a patch to make nested message loops work on Linux. >>> http://codereview.chromium.org/115812 >>> >>> It's always a bit scary touching the message loop code, but this will >>> fix two real issues we know about: >>> - file save dialogs crash on some subset of platforms >>> - copy and paste crashers >>> >>> My plan: I am going to land this patch, see if it does anything >>> horrible in the next few days or two. >>> So if you suddenly start getting new crashers, let me know. We can >>> always back it out. >>> >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Zygote mode on by default in Linux now. Here's how to disable it...
Does this mean the zygote manager process is the parent process for the browser process and all renderer processes? Whereas before the browser process was the parent to all renderer processes. On Mon, Jun 8, 2009 at 5:39 PM, Dan Kegel wrote: > > http://src.chromium.org/viewvc/chrome?view=rev&revision=17909 enabled > zygote mode on Linux by default. This changes how processes > work on Linux; the initial process becomes a fork server, > and holds open file descriptors for the .pak files. > This lets us continue running even if the app is > updated or uninstalled while we're running. The > next time you restart, the new files will take effect. > > If for some reason (say, you don't like the fact that the > main process is now this funky fork server) you want to > go back to how things were before temporarily, > you can disable zygote mode by doing > export DISABLE_ZYGOTE_MANAGER=x > before running. > > The valgrind ui_test bots are currently greener than they should > be, possibly because zygote mode is interfering with > how I set ui_test mode up under valgrind. I'll have a > look at that tomorrow. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Memory usage in chrome
FYI, --single-process only works in Chromium. It's disabled in Google Chrome. Search for switches::kSingleProcess in http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/chrome_dll_main.cc?revision=18801&view=markup On Sun, Jun 21, 2009 at 4:22 PM, est wrote: > > use --single-process > > On Jun 21, 3:37 pm, n179911 wrote: >> Hi, >> >> There is a test which compares memory usage among rendering >> engineshttp://dotnetperls.com/chrome-memory >> >> From the site, it shows the maximum memory usage of Chrome is more >> than Safari is > 2 times. >> Since both of them are Webkit base, does that mean the V8 engine uses >> twice as much memory as squirrel fish? >> >> --- Maximum memory used --- >> Peak memory usage measured during experiment. >> >> Chrome: 1216.16 MB [Largest] >> Firefox: 327.65 MB [Smallest] >> Opera: 554.11 MB >> Safari: 517.00 MB > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Error While compiling on ubuntu 64bit
You need to give more info. What revision of the source code are you at? Did you make any local changes? FWIW, we have a Jaunty build bot on the experimental waterfall and it built ok. http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20(Jaunty)/builds/1981 On Mon, Jun 22, 2009 at 5:00 AM, Ibrar Ahmed wrote: > Hi, > > I am getting error while compiling on ubuntu 9.04 (64bit) > > /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp: > In function 'int WebCore::cssValueKeywordID(const > WebCore::CSSParserString&)': > /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp:4947: > error: expected initializer before '*' token > /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp:4948: > error: 'hashTableEntry' was not declared in this scope > Compiling > /home/ibrar/Google/chromium/src/sconsbuild/Debug/obj/third_party/WebKit/WebCore/css/CSSPropertyLonghand.o > scons: *** > [/home/ibrar/Google/chromium/src/sconsbuild/Debug/obj/third_party/WebKit/WebCore/css/CSSParser.o] > Error 1 > scons: building terminated because of errors. > > > > > > > > On Sat, Jun 20, 2009 at 4:45 AM, Hunnter2k3 wrote: >> >> Ever since V2 has been pushed, the CPU usage for Chrome has sky- >> rocketed every time i am loading pages. >> Every time a page is loading, both cores are hitting 100%. >> Worse is when sites are lagging or slow, the CPU is still at 100% >> until it is finished, no ifs or buts. >> >> I even done a fresh install, I even installed SRWare's Iron, it still >> hits 100% when a page loads. >> >> If this is what V2 is going to be like, i am going straight back to >> V1, i don't want a browser eating 100% and interrupting other >> processes, especially if it is because of a feature i couldn't care >> less about. >> >> Is this what has happened to Full Page Zoom now, instead of generating >> it each time a person wants to zoom? >> If so, for the love of everything decent, please go back to the old >> system, i don't care for FPZ and never will, or at least start using >> that wonderful thing called Options and add it in there, please. >> >> > > > > -- > Ibrar Ahmed > > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Pixel layout tests and checksums
I noticed this too. LayoutTests/fast/transforms/matrix-02.html has been marked fail for a while on Linux because the checksum is different from Windows, even though the output pngs are identical. On Mon, Jun 22, 2009 at 10:24 AM, Evan Martin wrote: > > Since I'm waiting for a build I sat down to implement this. > > But our image checksums are not checksums of the image files :(, but > rather checksums of the pixels stored in the image. > > And Tony points out that our image checksumming is completely insane: > > = > // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want > // to keep it. On Windows, the alpha channel is wrong since text/form control > // drawing may have erased it in a few places. So on Windows we force it to > // opaque and also don't write the alpha channel for the reference. Linux > // doesn't have the wrong alpha like Windows, but we ignore it anyway. > #if defined(OS_WIN) > bool discard_transparency = true; > device->makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); > #elif defined(OS_LINUX) > bool discard_transparency = true; > #elif defined(OS_MACOSX) > bool discard_transparency = false; > #endif > > // Compute MD5 sum. We should have done this before calling > // device->makeOpaque on Windows. Because we do it after the call, there are > // some images that are the pixel identical on windows and other platforms > // but have different MD5 sums. At this point, rebaselining all the windows > // tests is too much of a pain, so we just check in different baselines. > > > To be more clear, here's a table of the platforms and their behaviors. > O=opaque, T=transparent. > (Sorry for my ghetto proportionally-spaced table here.) > > Win Mac Lin > cksum O T T > png O T O > > I conclude that on Linux, you cannot go from the PNG file back to the > checksum in the presence of alpha. > > > Just for fun I played around a bit with commands like: > convert path/to/pngfile rgba:- | md5sum > and wasn't able to repro the checksums I'm seeing. > > It looks ok from > convert path/to/pngfile rgba:- | xxd -g4 > (the RGBA<->BGRA problem doesn't apply for this black and while png file...). > > In summary: tears. > > On Mon, Jun 22, 2009 at 3:20 AM, Dean McNamee wrote: >> >> Last week I updated our DEPS to pull in a newer version of Skia. I >> was stumped at a few cases where the checked in PNG looked completely >> wrong, but yet it was passing on the buildbots. There was no way that >> image could have been the output. >> >> It just dawned on me today, but I haven't verified it. I can dig up >> my commit to verify it, but I'd say 99% sure this was the case. >> >> If the checksum is valid, we don't even go to the PNG. Therefor I >> believe we have a bunch of layout tests where the checked in PNG is >> completely wrong, but the checksum is right. >> >> I don't have the time right now, but it would be great if someone >> could write a script and clean this up. >> >> Thanks >> -- dean >> >> > >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how to judge layouttests' running result?
http://dev.chromium.org/developers/testing/webkit-layout-tests says: ./run_webkit_tests.sh LayoutTests/path/to/your/test.html --full-results-html will produce a page including links to the expected result, actual result, and diff. Does that help? 2009/6/25 David Jones : > I have ran layouttests on Windows XP, and got a result as: > Expected to fail, but passed (5): > LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html > LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html > LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html > LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html > LayoutTests/fast/encoding/invalid-UTF-8.html > Expected to timeout, but passed (1): > LayoutTests/http/tests/security/credentials-in-referer.html > Regressions: Unexpected failures (8): > LayoutTests/fast/css/css2-system-fonts.html = FAIL > LayoutTests/fast/dom/anchor-toString.html = FAIL > LayoutTests/fast/dom/java-applet-calls.html = FAIL > LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL > > LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht > ml = FAIL > LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL > LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL > LayoutTests/plugins/embed-attributes-setting.html = FAIL > Regressions: Unexpected timeouts (1): > LayoutTests/http/tests/security/originHeader/origin-header-for-https.html > = TI > MEOUT > -- > => Tests to be fixed for the current release (786): > 86 test cases (10.9%) Passed > 364 test cases (46.3%) Skipped > 289 test cases (36.8%) Text diff mismatch > 191 test cases (24.3%) Simplified text diff mismatch > 160 test cases (20.4%) Image mismatch > 11 test cases (1.4%) Test timed out > 6 test cases (0.8%) Test shell crashed > 2 test cases (0.3%) No expected image found > => Tests we want to pass for the current release (8984): > 8271 test cases (92.1%) Passed > 364 test cases (4.1%) Skipped > 301 test cases (3.4%) Text diff mismatch > 201 test cases (2.2%) Simplified text diff mismatch > 164 test cases (1.8%) Image mismatch > 12 test cases (0.1%) Test timed out > 6 test cases (0.1%) Test shell crashed > 2 test cases (0.0%) No expected image found > => Tests to be fixed for a future release (0): > => All tests (10884): > 8753 test cases (80.4%) Passed > 2130 test cases (19.6%) Skipped > 411 test cases (3.8%) Text diff mismatch > 302 test cases (2.8%) Simplified text diff mismatch > 183 test cases (1.7%) Image mismatch > 13 test cases (0.1%) Test timed out > 6 test cases (0.1%) Test shell crashed > 2 test cases (0.0%) No expected image found > I don't know what it tells, am I passed the layouttests? > > There's also a layouttests in webkit, what's the relation between chrome's > layouttest and webkit's layouttest? I think webkit's layouttest only run on > Leopard. > > > > 200万种商品,最低价格,疯狂诱惑你 > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: memory leak in the jpeg_codec.cc
It probably needs to be converted into a scoped_array like in
JPEGCodec::Decode. Can you file a bug for this on http://crbug.com/ ?
On Thu, Jul 2, 2009 at 5:59 AM, runtime wrote:
>
> Hi
> There is memory leak in the module jpeg_codec.cc, member function
>
> bool JPEGCodec::Encode(const unsigned char* input, ColorFormat format,
> int w, int h, int row_byte_width,
> int quality, std::vector*
> output);
>
> code
>
> // output row after converting
> unsigned char* row = new unsigned char[w * 3];
>
> while (cinfo.next_scanline < cinfo.image_height) {
> converter(&input[cinfo.next_scanline * row_byte_width], w, row);
> jpeg_write_scanlines(&cinfo, &row, 1);
> }
> delete[] row;
>
> The allocated in row pointer memory will not be released if error
> happens in libjpeg.
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Reviewers
You didn't give enough context. It'll be more helpful if you put links to the patches you want reviewed. On Mon, Jul 6, 2009 at 7:47 PM, Thiago Farina wrote: > > When I don't know who can review some patch for me what I have to do? > > Currently I have 3 patchs waiting for review, but I haven't received > any feedback or contact until now. > > What I have to do in this cases? > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: a new problem with the latest patch for 2008 SP1 (from today/yesterday)
I assume there's a similar patch for VS2005SP1. Does that have the same problem? On Wed, Jul 29, 2009 at 11:15 AM, nakro wrote: > > if you get the latest patch of VS2008SP1 (released yesterday) > you will not be able to compile chrome > > you will get errors relating to '_Swap_adl' > > i googled it a bit, and till MS fixes it i simply modified 2 files in > the inc dir > tuple > xutility > > and changed '_Swap_adl' to 'swap' <- note the lowercase > > also due to permissions you might not be able to modify the file, so i > did this in an elevated cmd prompt > > ok, now you know, here is where i got most of the info from > http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/4bc93a16-4ad5-496c-954c-45efbe4b180b > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp failing while triggering gclient sync in linux with git
Working ok here with svn and the make build.
On Thu, Aug 6, 2009 at 8:58 PM, Mohamed Mansour wrote:
> Tonight I was trying to sync my project so I did "git pull" and it worked
> fine, then I did "gclient sync" as well as --force. But gyp is failing:
>
> m...@m0-desktop:~/chrome/src$ gclient sync
> found .git directory; skipping src
> running '/usr/bin/python src/tools/gyp/gyp_chromium' in
> '/home/m0/chrome'
> Updating projects from gyp files...
> Traceback (most recent call last):
> File "src/tools/gyp/gyp_chromium", line 34, in
> sys.exit(gyp.main(args))
> File "src/tools/gyp/pylib/gyp/__init__.py", line 262, in main
> params)
> File "src/tools/gyp/pylib/gyp/__init__.py", line 75, in Load
> depth, generator_input_info)
> File "src/tools/gyp/pylib/gyp/input.py", line 1644, in Load
> LoadTargetBuildFile(build_file, data, aux_data, variables, includes,
> depth)
> File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
> includes, depth)
> File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
> includes, depth)
> File "src/tools/gyp/pylib/gyp/input.py", line 224, in LoadTargetBuildFile
> includes, True)
> File "src/tools/gyp/pylib/gyp/input.py", line 129, in LoadOneBuildFile
> build_file_data = eval(build_file_contents, {'__builtins__': None},
> None)
> File "/home/m0/chrome/src/chrome/third_party/hunspell/hunspell.gyp", line
> 4
>
> ^
> SyntaxError: invalid syntax
> failed to run command: /usr/bin/python src/tools/gyp/gyp_chromium
>
> I made sure I have no local changes (fresh out of git)
>
> m...@m0-desktop:~/chrome/src$ git log
> commit 0954eb9b2987d50c54cb9c62ba3dfdeec1f1b01b
> Author: gspen...@google.com
>
> Date: Fri Aug 7 03:38:01 2009 +
> This adds a stub for the mac installer so that the gyp generation won't
> fail on Macs.
> Review URL: http://codereview.chromium.org/165109
>
> git-svn-id: svn://svn.chromium.org/chrome/trunk/s...@22717
> 0039d316-1c4b-4281-b951-d872f2087c98
>
> But I still get the error. My "git status" is:
>
> m...@m0-desktop:~/chrome/src$ git status
>
> # On branch trunk
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> # chrome/test/data/layout_tests/LayoutTests/
> # valgrind-20090715/
> # valgrind.tmp/
> nothing added to commit but untracked files present (use "git add" to track)
>
> I really don't understand why it is happening, I diffed my hunspell.gyp wrt
> to the version online and they are identical.
> Any help is appreciated, I would like to work a bit this weekend but
> valgrind requires linux and I can't seem to gclient sync it :/
>
> Thanks!
> -- Mohamed Mansour
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Tree hygiene
Do we have a warning for when the difference between the ToT revision number and LKGR pass a certain threshold? On Fri, Aug 14, 2009 at 8:00 AM, Marc-Antoine Ruel wrote: > > - The reliability test has been red for so long that a bad regression > hasn't been noticed before it was way too late. > > - There was multiple webkit linux regressions that haven't been fixed. > (+ valgrind) > > - http://chromium-status.appspot.com/lkgr is so old it's totally worthless. > > I'll open the tree only when I'll feel like to. > > I know ya all missed me sheriffing, eh? > > M-A > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Linux] switching from hammer to make as the default build tool
Hi, On Linux, building with make is a lot faster than build with hammer. Ever since I switched to the make build on Linux, I've never looked back. I imagine many other Linux developers are also using make, and we have been using the make build without any major problems for a few months now. So I wonder, is it time to switch our build bots to make and update the Linux build instructions? - Lei --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Linux] switching from hammer to make as the default build tool
On Mon, Aug 17, 2009 at 3:00 PM, Antoine Labour wrote: > On Mon, Aug 17, 2009 at 2:07 PM, Lei Zhang wrote: >> >> Hi, >> >> On Linux, building with make is a lot faster than build with hammer. >> Ever since I switched to the make build on Linux, I've never looked >> back. I imagine many other Linux developers are also using make, and >> we have been using the make build without any major problems for a few >> months now. So I wonder, is it time to switch our build bots to make >> and update the Linux build instructions? >> >> - Lei > > I'm all for it since that would reduce the make build breaks, but I > think the dependency bug where you have to delete all your .a should > be fixed first if you don't want to spend time babysitting buildbot. > > Antoine > Is there a bug files for that? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: To get your work onto 3.0 stable
Question, have all the strings been translated? I tried Spanish and saw some untranslated stuff, i.e. IDS_OPEN_FILE_DIALOG_TITLE, IDS_OMNIBOX_SEARCH_HINT_INFOBAR_TEXT, and IDS_BLACKLIST_MESSAGE. I think these all made it in before the deadline. On Wed, Aug 12, 2009 at 12:52 PM, Glen Murphy wrote: > 2. String freeze was weeks ago - if you still require string > changes for your 3.0 feature, you're out of luck; you may > have to hack around it using existing strings, though this might > be worse than not shipping your feature. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: XP unit purify bot broken
+1 for splitting unit_tests. On Linux, it's possible to generate a 2.3GB unit_tests binary that won't run. X-( On Wed, Aug 19, 2009 at 4:12 PM, Erik Kay wrote: > > The XP unit Purify bot has been failing for the last week or so. > Unfortunately, this has turned out to be more than just a simple case > where we can filter out a particular broken test. To fix it, we > either need a fix from IBM/Rational (unlikely, due to the nature of > the bug - see below), or we need to do a bit of surgery on the test > itself. Huan has agreed to help with the latter, but this will likely > take some time to work out. In the meantime, we're more vulnerable to > new memory bugs. Please do your best to be extra careful until we can > get the bot enabled again. When we do enable the bot, we should > expect to have a number of new bugs that need to be looked at in short > order. > > We'll give more updates as we have them. > > Erik > > Details for those who care: > > The issue appears to be that unit_tests.exe under Purify is running > out of address space. I spent some time over the past few days > disabling tests hoping that the failure was specific to some > particular test. Unfortunately it seems that the issue is just that > unit_tests.exe has gotten too large. Purify keeps a bunch of > accounting data for warnings and errors in memory. It even keeps > records for errors that are filtered out. Microsoft's STL > implementation generates many warnings (primarily UMRs), and we use > STL heavily (from Rational's and our analysis, these warnings appear > to be benign). Each of these warnings slows down Purify execution and > consume (a fairly large amount of) memory. We now appear to have > enough tests that generate enough warnings that we're running out of > memory from them. > > So the approach Huan's looking into now is to run unit_tests.exe in > chunks similar to how we do layout and ui tests (although it would run > all chunks in one build rather than split across multiple runs). The > other approach would involve splitting unit_tests.exe into smaller > pieces (browser, renderer, common, etc.). This could have other > benefits potentially as the executable size would be smaller, which > would have faster iteration cycles (faster link times, faster > instrumentation times, etc.). Let me know if you have any interest in > doing work with this approach. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
On Fri, Aug 21, 2009 at 2:25 PM, Dean McNamee wrote: > > On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour wrote: >> - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's >> going to look at the host for them. If your target distribution >> matches your host maybe you're fine, but it may not work at all, so >> it'd would be good to extract that and get a way to specify the >> dependencies explicitly. > > I also don't think we should modify our GYP build for this. You can > set PKG_CONFIG_PATH, etc, to have pkg-config use a different set of pc > files. You can just create these files for whatever target you are > building, and point pkg-config to use them instead. I don't remember having to fight pkg-config. Maybe my host/target (Ubuntu Hardy x86/Debian Lenny ARM) matched closely enough that it didn't matter. Thanks for writing the wiki page. I should've done that a long time ago. I dumped the bits I remember on the wiki page. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chromium / Google Summer of Code
With the Google Summer of Code program winding down, I'm curious how our GSoC participants are doing. Can the students and their mentors share their experiences? (Assuming you're all done with evaluations and all that.) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
On Mon, Aug 24, 2009 at 6:22 PM, Antoine Labour wrote: > > On Mon, Aug 24, 2009 at 1:53 PM, Scott Hess wrote: >> Would it be possible/reasonable to use distcc plus a farm of >> cross-compiler machines to let you do faster self-hosted builds? It's >> not the "right" solution, but in the past I've found it to sometimes >> be an easier path to take in the short term while you're working on >> fixing all the little problems. >> >> -scott > > Interesting take, it might work. > Like Dean mentions, we're talking about 512 MB boards (or even 256 > MB), which in practice only means about 400 MB accessible to the OS. I > don't know how gold performs on ARM. Only x86 and x86_64 were supported at the time gold was originally released. Does it support ARM yet? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: buildbot bisect script
I've heard a few complains of "I cannot bisect because the archive does not go that far back." Are we tight on storage? It would be nice if we can keep more of the continuous builds around. On Thu, Sep 3, 2009 at 10:30 AM, Evan Martin wrote: > > I feel a couple of people have written scripts to bisect builds pulled > from http://build.chromium.org/buildbot/continuous/ . > > Can we check one of those in? I can review. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Linux] switching from hammer to make as the default build tool
FYI, I fixed a dependency bug in chrome.gyp earlier in the week, so there's a much greater chance of make finishing on the first try. I have several gyp fixes floating around, and I'll try to set up a make buildbot today/early next week. On Tue, Aug 18, 2009 at 5:44 AM, Evan Martin wrote: > I would like to make this switch, but it is not yet reliable. I don't > want build bots failing because of dependency bugs. (Heh, heaven > forbid we sometimes need to click a hypothetical "clobber" checkbox on > the buildbots to work around a build system issue! :P) > > I'd been using the "makebuild" label, though most bugs have just been > reported to me directly (special thanks to benl and davemoore for > tracking down some problems for me): > http://code.google.com/p/chromium/issues/list?can=1&q=makebuild > > Dean told me he has his build alias just always run make twice when he > builds, which is pretty tragic to me, but he says it's still faster > than scons. :\ > > > On Mon, Aug 17, 2009 at 2:07 PM, Lei Zhang wrote: >> >> Hi, >> >> On Linux, building with make is a lot faster than build with hammer. >> Ever since I switched to the make build on Linux, I've never looked >> back. I imagine many other Linux developers are also using make, and >> we have been using the make build without any major problems for a few >> months now. So I wonder, is it time to switch our build bots to make >> and update the Linux build instructions? >> >> - Lei >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux HTML5, List of Libraries
"Chromium is currently 32-bit x86 only" ... sounds like we need to update the build instructions for 64-bit. On Tue, Sep 8, 2009 at 11:47 AM, Evan Martin wrote: > > If http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites > doesn't answer your question, please ask it again and/or update that > page so it does. :) > > On Tue, Sep 8, 2009 at 5:29 AM, Luis Canaval wrote: >> >> Hello, I'm sorry if this is not the right place for this question bue >> here I go. >> Can any of the Linux Version's developers share a list of all the >> libraries, versions and file names needed for Chromium/Chrome, as >> dependencies, in Linux 64 bits? >> Specially those needed for Text rendering (Specially japanese, Korean, >> Chinese, etc.) and HMLT5 Video and audio tags. I have been trying for >> a few days now and can't make those characteristics work. >> >> Thank you so much in advance. >> >> I'm using Archlinux 2009.2 64 Bits edition and I'm familiar with linux >> development tools, I'm not an expert but I can also help doing >> specific test under this platform if by any chance needed :D. >> >> > >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux HTML5, List of Libraries
I guess you missed the "Chromium Linux 64-bit" thread and the "Google Chrome For Linux Goes 64-bit " slashdot article. On Tue, Sep 8, 2009 at 2:07 PM, Stefan Nuxoll wrote: > I was under the impression that going to 64-bit isn't just a simple > switch in build instructions, there were some components (V8, maybe) > that weren't x64 compatible. Anyone else want to comment on this? > > (Oops, hit Reply instead of Reply All, silly gmail) > > On Tue, Sep 8, 2009 at 12:53 PM, Lei Zhang wrote: >> >> "Chromium is currently 32-bit x86 only" ... sounds like we need to >> update the build instructions for 64-bit. >> >> On Tue, Sep 8, 2009 at 11:47 AM, Evan Martin wrote: >>> >>> If >>> http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites >>> doesn't answer your question, please ask it again and/or update that >>> page so it does. :) >>> >>> On Tue, Sep 8, 2009 at 5:29 AM, Luis Canaval >>> wrote: >>>> >>>> Hello, I'm sorry if this is not the right place for this question bue >>>> here I go. >>>> Can any of the Linux Version's developers share a list of all the >>>> libraries, versions and file names needed for Chromium/Chrome, as >>>> dependencies, in Linux 64 bits? >>>> Specially those needed for Text rendering (Specially japanese, Korean, >>>> Chinese, etc.) and HMLT5 Video and audio tags. I have been trying for >>>> a few days now and can't make those characteristics work. >>>> >>>> Thank you so much in advance. >>>> >>>> I'm using Archlinux 2009.2 64 Bits edition and I'm familiar with linux >>>> development tools, I'm not an expert but I can also help doing >>>> specific test under this platform if by any chance needed :D. >>>> >>>> > >>>> >>> >>> > >>> >> >> >> >> > > > > -- > Stefan Nuxoll > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Dashboard to show which UI/unit/etc (non-webkit) tests are slowest
How often is this updated? How many runs does it look at to calculate the test run times? On Thu, Sep 17, 2009 at 8:52 AM, Paweł Hajdan Jr. wrote: > The slowness dashboard is ready > at http://build.chromium.org/buildbot/slowness-report/ > There are some problems with it (like garbage in test names), and it could > possibly display more data (like median and stddev), but it's generally > usable. > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Handling bad permissions for browser profile data
Normally users have access to their profile data, but there are mis-configure systems where this assumption does not hold. This leads to weird behavior and bizarre bugs. I feel we need more sanity checks and warn users that their profile data is messed up. In bug 7733, a user wrote: "I found the problem in my case - the file "C:\Documents and Settings\Steve\Local Settings\Application Data\Google\Chrome\User Data\Local State" had lost *all* of its permissions. Chrome couldn't even READ it." In bug 22241, a user wrote: "Scratch that last -- I do have a ~/.config directory. It is owned by root and contains one file: Trolltech.conf. I probably ran some Qt app under sudo. So apparently if Chrome can't write to ~/.config, it puts the profile directory under ~ instead. Bug or feature?" --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Green Tree] Week 1
Of the three slowest tests as of last week, two has been fixed (thanks to evan and jcampan) and the third one has a fix being reviewed. The Linux trybots build almost as fast as the Mac trybots now, thanks to shared ccache with a ~80% cache hit rate. Windows trybots are still struggling - taking 3X as long to build vs. Linux/Mac. On Mon, Sep 21, 2009 at 8:25 AM, Nicolas Sylvain wrote: > Hi chromium-dev, > A small group of us joined forces to create a "Green Tree" task force. The > goal of this task > force is to make sure the tree stays green most of the time. The 2 main > pain points that > we are attacking at this time are "reducing the buildbot cycle time", to > catch errors earlier, and > "getting rid of the flakiness", to make sure the tree does not turn red for > no reason. > I'll be prepending "[Green Tree]" to the emails I send related to the task > force. > You can also follow the progress and our tasks > there: http://code.google.com/p/chromium/issues/list?q=label:GreenTreeTaskForce > For those interested, these are the highlights of the last week: > - Make sure all the tasks have bugs associated with them (pamg) > - Make sure VMWare Tools is installed on all the slaves (bev / nsylvain) > - Disable all services that we don't need on the slaves (bev) > - Split the windows chromium tests in 3 slaves (maruel) > - Change the gatekeeper to close the tree on more failures (maruel) > - Change LKGR to care about more tests, and make it cycle faster (maruel) > - Write a status page to see the cycle speed on the slaves (nsylvain) > - Make sure we build only what we need on Mac (thomasvl) > - Add more try bots (linux views, valgrind) (maruel) > - Refactor Linux Valgrind buildbots into builder/testers. (mmoss) > - Create a dashboard to see the slowest tests (phajdan) > - Speed up the transfer of builds between builders/testers by reducing the > compression (mmoss) > I'm sure I forgot some, feel free to append to this list. > Despite our efforts, this was one of the worse week we've seen in a long > time in term of tree closure. This > was caused by 5 main events: > - Buildbot maintenance went wrong. By changing a mounted drive on the > buildbot master, the mount table got corrupted, and we had to reboot the > main server. We started the maintenance at 7:30AM (pacific) and we got the > buildbot back online shortly after 10AM. It had to cycle a little, so it was > closed for almost 3 hours > - A webkit merge left some failures in the tree. And it looks like everyone > left without fixing it, so it was closed overnight. We fixed it in the > morning, but before reopening we let another webkit merge go by, and it also > broke the tree, requiring a change on webkit.org to fix the reliability > tests (IIRC). Total closure time: 20 hours. > - A bad gclient change got checked in. Some machines stopped running > "runhooks" and some bots got confused. The damage seems to have been > limited. > - A second bad gclient change got checked in. This time causing all the > bots to throw away their checkouts. Almost each slaves had to do a full > checkout (which takes an hour or so), and some of them ran out of disk > space, so we had to manually fix them. The tree was closed for another > couple of hours. > - A bad DEPS file got checked in. Causing again a bunch of slaves to throw > away their checkout. It was closed for another hour or two. > Nicolas > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is it possible to customize CXXFLAGS and CFLAGS when generating make file or invoking make?
Looks like both CXXFLAGS=foo make and CXXFLAGS=foo hammer ignore CXXFLAGS. Is this by design? On Tue, Sep 22, 2009 at 12:07 AM, James Su wrote: > Hi, > I'd like to compile chromium with some special CFLAGS/CXXFLAGS, how can I > do? I'm using make build on 64bit Linux. > Regards > James Su > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Without SSe2
Google Chrome builds without SSE2.
On Wed, Sep 23, 2009 at 11:16 AM, Dan Kegel wrote:
>
> Oddly, I can still install fine on my pentium III laptop, I think.
>
> On Wed, Sep 23, 2009 at 11:02 AM, Evan Martin wrote:
>> The code doesn't lie:
>>
>> 'conditions': [
>> ['branding=="Chromium"', {
>> 'cflags': [
>> '-march=pentium4',
>> '-msse2',
>> '-mfpmath=sse',
>> ],
>> }],
>> ],
>>
>>
>> http://code.google.com/p/chromium/issues/detail?id=8475
>>
>> On Wed, Sep 23, 2009 at 11:00 AM, Dan Kegel wrote:
>>>
>>> Does our default build really depend on -msse2 anymore? Doesn't
>>> seem to on linux...
>>>
>>> 2009/9/22 Ujjwol (उज्जवल लामिछाने) :
This (http://code.google.com/p/chromium/wiki/LinuxPackaging) page says
that
For silly reasons our default build depends on SSE, but we don't
actually need. Search base/common.gypi and patch out the -msse2 bits
before building your package.
But I cannot find base.common.gypi in the source tarball of the
chromium. How should I fix this solution.
I am wanting to run chromium on XO which has a Geode processor.
And I would be helpful if anybody points me to the download page where
chromium without SSe2 can be found.
Thanks in Advance
Ujjwol
>
>>>
>>> >>
>>>
>>
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Build time doubled since May - what gives?
This is very recent. The Windows try server build times have gone way up this week. I thought it was just because of Incredibuild misbehaving on the try servers, but it looks like you're experiencing similar problems without IB. I think this is only affects Windows - the Mac and Linux trybot compile times haven't increased significantly. On Thu, Sep 24, 2009 at 7:06 PM, Ben Goodger (Google) wrote: > > I just ran a build here at home on my i7 workstation. It took 14 > minutes. This is the same system that would build in 7 minutes when I > set it up in May. > > What gives? We need to figure this out ASAP. > > -Ben > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NaCl on Linux/x86-64?
Have you tried installing glibc-devel/i586? On Wed, Sep 30, 2009 at 10:06 AM, spotrh wrote: > > It doesn't look like NaCl works on x86-64. When I try to compile it, I get: > > Running ncdecode_tablegen > Compiling > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/validator_x86/ncvalidate/ncvalidate.o > Compiling > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/validator_x86/ncvalidate/nc_inst_state.o > gcc -m32 -DNACL_BLOCK_SHIFT=5 -DNACL_BLOCK_SIZE=32 -DNACL_LINUX=1 > -DNACL_OSX=0 -DNACL_WINDOWS=0 -D_BSD_SOURCE=1 -D_POSIX_C_SOURCE=199506 > -D_XOPEN_SOURCE=600 -D_GNU_SOURCE=1 -D__STDC_LIMIT_MACROS=1 > -D__STDC_FORMAT_MACROS -DNACL_STANDALONE=1 -DNACL_TARGET_SUBARCH=64 > -DNACL_BUILD_SUBARCH=64 -DNDEBUG > -I/mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src -c -o > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/service_runtime/tramp_gen/arch/x86_32/tramp.o > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/native_client/src/trusted/service_runtime/arch/x86_32/tramp.S > Compiling > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/service_runtime/tramp_gen/arch/x86_32/tramp_gen.o > gcc -m32 -DNACL_BLOCK_SHIFT=5 -DNACL_BLOCK_SIZE=32 -DNACL_LINUX=1 > -DNACL_OSX=0 -DNACL_WINDOWS=0 -D_BSD_SOURCE=1 -D_POSIX_C_SOURCE=199506 > -D_XOPEN_SOURCE=600 -D_GNU_SOURCE=1 -D__STDC_LIMIT_MACROS=1 > -D__STDC_FORMAT_MACROS -DNACL_STANDALONE=1 -DNACL_TARGET_SUBARCH=64 > -DNACL_BUILD_SUBARCH=64 -DNDEBUG > -I/mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src -c -o > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/service_runtime/springboard_gen/arch/x86_32/springboard.o > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/native_client/src/trusted/service_runtime/arch/x86_32/springboard.S > In file included from /usr/include/features.h:376, > from /usr/include/stdio.h:28, > from > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/native_client/src/trusted/service_runtime/arch/x86_32/tramp_gen.c:32: > /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or > directory > scons: *** > [/mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/service_runtime/tramp_gen/arch/x86_32/tramp_gen.o] > Error 1 > Compiling > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/service_runtime/springboard_gen/arch/x86_32/springboard_gen.o > In file included from /usr/include/features.h:376, > from /usr/include/stdio.h:28, > from > /mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/native_client/src/trusted/service_runtime/arch/x86_32/springboard_gen.c:32: > /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or > directory > scons: *** > [/mnt/chromium/rpmbuild/BUILD/chromium-20090930svn27599/src/sconsbuild/Release/obj/service_runtime/springboard_gen/arch/x86_32/springboard_gen.o] > Error 1 > scons: building terminated because of errors. > > > * > > From what I can decipher, it looks like it always tries to compile the > 32bit assemply bits, no matter what the arch target is. Is this intentional? > > Is there a way to disable NaCl for x86-64? > > ~spot > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NaCl on Linux/x86-64?
On Wed, Sep 30, 2009 at 11:23 AM, spotrh wrote: > On 09/30/2009 01:58 PM, Lei Zhang wrote: >> Have you tried installing glibc-devel/i586? > > No, because the resulting binaries wouldn't really be x86_64, would they? :) Native client is trying to build 32-bit binaries, even on x86_64. All they do is generate some header files, which shouldn't change very often. I asked the NaCl folks to just check in a pre-generated header and stop building the 32-bit binaries in question. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NaCl on Linux/x86-64?
On Wed, Sep 30, 2009 at 2:06 PM, spotrh wrote: > On 09/30/2009 04:34 PM, Lei Zhang wrote: >> On Wed, Sep 30, 2009 at 11:23 AM, spotrh wrote: >>> On 09/30/2009 01:58 PM, Lei Zhang wrote: >>>> Have you tried installing glibc-devel/i586? >>> >>> No, because the resulting binaries wouldn't really be x86_64, would they? :) >> >> Native client is trying to build 32-bit binaries, even on x86_64. All >> they do is generate some header files, which shouldn't change very >> often. I asked the NaCl folks to just check in a pre-generated header >> and stop building the 32-bit binaries in question. > > That would be perfect, thanks! > > ~spot > I filed a bug so this doesn't get dropped: http://code.google.com/p/nativeclient/issues/detail?id=104 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Unkown Error During Building Chromium for Linux
It looks as though you didn't save stderr, only stdout, so the logs do not contain any actual error messages. 2009/10/5 Ujjwol (उज्जवल लामिछाने) : > > While building chromium in Fedora 10, a strange build error has been > encountered. > > The tail of the log of build(hammer --verbose) process is: > > > [ujj...@ujjwol Desktop]$ tail VerboseChromeBuild.txt > Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-CN.pak to / > home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/ > Debug/locales/zh-CN.pak ... > Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-TW.pak to / > home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/ > Debug/locales/zh-TW.pak ... > Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/default.pak > to /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/themes/default.pak ... > g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/obj/chrome/page_cycler_tests/test/page_cycler/ > page_cycler_test.o -c -fno-rtti -fno-threadsafe-statics -Werror - > pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 -m32 -march=geode > -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/ > include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/ > include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 - > I/usr/include/freetype2 -I/usr/include/libpng12 -O0 -g - > D__STDC_FORMAT_MACROS -DCHROMIUM_BUILD -DUNIT_TEST -DGTEST_HAS_RTTI=0 - > D_DEBUG -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/obj/_global_intermediate/chrome -I/home/Ujjwol/ > chromium/home/chrome-svn/tarball/chromium/src -I/home/Ujjwol/chromium/ > home/chrome-svn/tarball/chromium/src/skia/config -I/home/Ujjwol/ > chromium/home/chrome-svn/tarball/chromium/src/third_party/skia/include/ > core -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > third_party/skia/include/effects -I/home/Ujjwol/chromium/home/chrome- > svn/tarball/chromium/src/skia/ext -I/home/Ujjwol/chromium/home/chrome- > svn/tarball/chromium/src/third_party/harfbuzz/src -I/home/Ujjwol/ > chromium/home/chrome-svn/tarball/chromium/src/third_party/harfbuzz/ > contrib -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > testing/gtest/include /home/Ujjwol/chromium/home/chrome-svn/tarball/ > chromium/src/chrome/test/page_cycler/page_cycler_test.cc > g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/obj/test_shell/npapi_layout_test_plugin/__/ > npapi_layout_test_plugin/PluginObject.os -c -fno-rtti -fno-threadsafe- > statics -Werror -pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 - > m32 -march=geode -O0 -g -fPIC -D__STDC_FORMAT_MACROS -DCHROMIUM_BUILD - > DENABLE_CHANNEL_MESSAGING=1 -DENABLE_DATABASE=1 -DENABLE_DATAGRID=0 - > DENABLE_OFFLINE_WEB_APPLICATIONS=1 -DENABLE_DASHBOARD_SUPPORT=0 - > DENABLE_DOM_STORAGE=1 -DENABLE_JAVASCRIPT_DEBUGGER=0 - > DENABLE_JSC_MULTIPLE_THREADS=0 -DENABLE_ICONDATABASE=0 - > DENABLE_NOTIFICATIONS=0 -DENABLE_XSLT=1 -DENABLE_XPATH=1 - > DENABLE_SHARED_WORKERS=0 -DENABLE_SVG=1 -DENABLE_SVG_ANIMATION=1 - > DENABLE_SVG_AS_IMAGE=1 -DENABLE_SVG_USE=1 - > DENABLE_SVG_FOREIGN_OBJECT=1 -DENABLE_SVG_FONTS=1 -DENABLE_VIDEO=1 - > DENABLE_WORKERS=1 -DBUILDING_CHROMIUM__=1 -DUSE_SYSTEM_MALLOC=1 - > DWTF_USE_PTHREADS=1 -DU_STATIC_IMPLEMENTATION -D_DEBUG -I/home/Ujjwol/ > chromium/home/chrome-svn/tarball/chromium/src/third_party/icu/public/ > common -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > third_party/icu/public/i18n -I/home/Ujjwol/chromium/home/chrome-svn/ > tarball/chromium/src -I/home/Ujjwol/chromium/home/chrome-svn/tarball/ > chromium/src/third_party/npapi -I/home/Ujjwol/chromium/home/chrome-svn/ > tarball/chromium/src/third_party/npapi/bindings -I/home/Ujjwol/ > chromium/home/chrome-svn/tarball/chromium/src/third_party/WebKit/ > JavaScriptCore -I/home/Ujjwol/chromium/home/chrome-svn/tarball/ > chromium/src/third_party/WebKit/JavaScriptCore/wtf /home/Ujjwol/ > chromium/home/chrome-svn/tarball/chromium/src/webkit/tools/ > npapi_layout_test_plugin/PluginObject.cpp > g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ > sconsbuild/Debug/obj/test_shell/npapi_layout_test_plugin/__/ > npapi_layout_test_plugin/TestObject.os -c -fno-rtti -fno-threadsafe- > statics -Werror -pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 - > m32 -march=geode -O0 -g -fPIC -D__STDC_FORMAT_MACROS -DCHROMIUM_BUILD - > DENABLE_CHANNEL_MESSAGING=1 -DENABLE_DATABASE=1 -DENABLE_DATAGRID=0 - > DENABLE_OFFLINE_WEB_APPLICATIONS=1 -DENABLE_DASHBOARD_SUPPORT=0 - > DENABLE_DOM_STORAGE=1 -DENABLE_JAVASCRIPT_DEBUGGER=0 - > DENABLE_JSC_MULTIPLE_THREADS=0 -DENABLE_ICONDATABASE=0 -
[chromium-dev] Re: Who owns crash...@chromium.org and why is there so many updates from it?
maruel, I think he's working on decreasing that number. On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek wrote: > I got 21 emails in the last day > for http://code.google.com/p/chromium/issues/detail?id=20915 > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Who owns crash...@chromium.org and why is there so many updates from it?
Oh sorry, I was thinking of buildbot@ On Tue, Oct 6, 2009 at 6:57 PM, Lei Zhang wrote: > maruel, I think he's working on decreasing that number. > > On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek wrote: >> I got 21 emails in the last day >> for http://code.google.com/p/chromium/issues/detail?id=20915 >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
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 wrote: > > On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: >> On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter >> 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 something >> > different about how the dependencies are being generated with the make >> > versus scons gyp backends. > > I'm now getting build failures for linux_page_load_uitest with the shared > object build, under both scons and make: > /mnt/sda4/chromium/src/out/Debug/obj/chrome/libbrowser.so: undefined > reference to `DevToolsManager::ActivateWindow(RenderViewHost*)' > ... and a bunch of other DevToolsManager:: undefined references. > (32-bit, Debug. Giving 32-bit Release a spin now.) > > -- Jacob > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Change to default build architecture
On Thu, Oct 15, 2009 at 5:28 PM, Michael Moss wrote: > If you want to continue building 32-bit on 64-bit hosts, you can force > it by setting GYP_DEFINES="target_arch=ia32" in the environment. FYI, I think $GYP_DEFINES overrides ~/.gyp/includes.gypi. You may get unexpected results if you are using both of these. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux/Stability - Remember to check the return value from GTK functions.
Hi Linux folks, This is a kind reminder to check the return values from GTK functions. Every time you put the unchecked result from, say, gtk_file_chooser_get_filename() into a FilePath or std::string, you risk a browser process crash if the result is NULL. I just triaged several crashes of this type. There's probably more... http://code.google.com/p/chromium/issues/detail?id=25490 http://code.google.com/p/chromium/issues/detail?id=25491 http://code.google.com/p/chromium/issues/detail?id=25493 http://code.google.com/p/chromium/issues/detail?id=25494 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How can we kill scons?
mmoss has been working on the make gyp generator, maybe he has a better feel for what's keeping us from switching. On Wed, Oct 28, 2009 at 12:35 PM, Albert J. Wong (王重傑) wrote: > On Wed, Oct 28, 2009 at 12:34 PM, Marc-Antoine Ruel > wrote: >> >> Not that it is effective :) > > Starred. :) > Now what? > >> >> On Wed, Oct 28, 2009 at 3:34 PM, Marc-Antoine Ruel >> wrote: >> > Have you tried starring http://crbug.com/22044 ? >> > >> > On Wed, Oct 28, 2009 at 3:28 PM, Albert J. Wong (王重傑) >> > wrote: >> >> If I'm not mistaken, I think like most everyone running on linux is >> >> using >> >> the make build nowadays, and the make build seems to work well enough >> >> for >> >> most people. The only time I hear someone mention the scons build, >> >> it's in >> >> reference to "you broke the scons build," or "so you developed on make. >> >> Did >> >> you check it worked on scons?" >> >> Given that, what's keeping us from killing the scons build completely? >> >> My current motivation for asking is that I've been spending the last >> >> hour >> >> trying to figure out why scons is deciding to insert an -fPIC into my >> >> build, >> >> whereas make is not. This is on top of my previous motivation (from >> >> about 3 >> >> days ago) where I spent another few hours making something that worked >> >> fine >> >> on the make build, scons compatible. I'd rather spend that time >> >> killing >> >> scons if there was a clear list of what was needed to make that happen. >> >> -Albert >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Linux] New chrome_sandbox needed at ToT if sandoxing is enabled.
Hi Folks, In r30948, I fixed several bugs related to the Linux suid sandbox. If you're running ToT with sandboxing turned on, you will need to rebuild chrome_sandbox. Without the new version of sandbox, Chromium will hang on start up. - Lei --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Large commit - update your .gclient files to avoid
And have the tarball generated from this lean configuration. On Thu, Nov 5, 2009 at 11:44 AM, Ben Goodger (Google) wrote: > > it'd be nice to have a gclient config lean or something like that. > > -Ben > > On Thu, Nov 5, 2009 at 11:42 AM, Jeremy Orlow wrote: >> In general, it might be interesting to document how to get a more lean >> checkout of Chromium. >> >> On Thu, Nov 5, 2009 at 11:34 AM, Adam Barth wrote: >>> >>> Can we note this on dev.chromium.org somewhere? >>> >>> Adam >>> >>> >>> On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart >>> wrote: >>> > This afternoon I will update DEPS to pull in 170MB of profile data for >>> > memory_test. Unless you run memory_test, you probably want to add the >>> > following line to the custom_deps section of your .gclient file. >>> > "src/data/memory_test/membuster": None, >>> > -- >>> > Steve >>> > > >>> > >>> >>> >> >> >> > >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [chromium-dev] Problem during compilation about gen_x86_insn.py
Do you have src/third_party/yasm/source/patched-yasm/modules/arch//x86/gen_x86_insn.py checked out? On Fri, Nov 13, 2009 at 1:43 AM, sahid wrote: > Hello, > > sa...@sahid-work:~/Documents/chromium/src$ cat /etc/debian_version > squeeze/sid > > sa...@sahid-work:~/Documents/chromium/src$ uname -sra > Linux sahid-work 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 > UTC 2009 i686 GNU/Linux > > sa...@sahid-work:~/Documents/chromium/src$ svn info > Path: . > URL: http://src.chromium.org/svn/trunk/src > Repository Root: http://src.chromium.org/svn > Repository UUID: 4ff67af0-8c30-449e-8e8b-ad334ec8d88c > Revision: 31896 > Node Kind: directory > Schedule: normal > Last Changed Author: phajdan...@chromium.org > Last Changed Rev: 31896 > Last Changed Date: 2009-11-13 10:17:58 +0100 (Fri, 13 Nov 2009) > > > i have this error: > > CXX(target) out/Debug/obj.target/wtf/third_party/WebKit/ > JavaScriptCore/wtf/unicode/UTF8.o > LINK(target) out/Debug/genperf > make: *** No rule to make target `third_party/yasm/source/patched-yasm/ > modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/ > third_party/yasm/x86insns.c'. Stop. > make: *** Waiting for unfinished jobs > LINK(target) out/Debug/genversion > g++: out/Debug/obj.target/genversion/third_party/yasm/source/patched- > yasm/modules/preprocs/nasm/genversion.o: No such file or directory > make: *** [out/Debug/genversion] Error 1 > > > you have an idea ?? > > thank you > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] More sheriffs?
Big +1 for at least a third sheriff. With two sheriffs, if one is not in PST, then really we only have one sheriff. If that sheriff happens to be new, then we have 0 <= num_sheriffs <= 1. On Fri, Nov 13, 2009 at 12:31 PM, Peter Kasting wrote: > At lunch today, a few of us discussed the idea of moving from two sheriffs > to four. > There are several reasons we contemplated such a change: > * The team is large enough that on the current schedule, you go months > between sheriffing, which is so long that you forget things like what tools > help you do what. > * Sheriffing is a heavy burden, and getting moreso with more team members. > * Either the two sheriffs are in different time zones, in which case you > have effectively one sheriff on duty who has to do everything (bad due to > point above), or they're not, in which case a chunk of the day is not > covered at all. > * New sheriffs could really use a "mentor sheriff" with them, which is > pretty difficult to schedule. > I think these are good reasons, so I propose we make this change. Comments? > PK > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Linux: gold linker users should upgrade to 2.20 soon.
Hi folks, We'll soon be relanding a patch that pass --gc-sections to the linker on Linux. For this to work, you need either GNU ld or a recent version of GNU gold. You can test and see if your copy of gold is new enough by running: /path/to/gold --gc-sections If you see: "fatal error: no input files", _no action_ is required. If you see: "--gc-sections: unknown option", then you _need to upgrade_. If you installed gold through [1], please run it again. I've updated the script at r32315 to install gold 2.20. I've also updated all the Linux build / try bots to gold 2.20. [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Linux: gold linker users should upgrade to 2.20 soon.
On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang wrote: > If you installed gold through [1], please run it again. I've updated > the script at r32315 to install gold 2.20. I've also updated all the > Linux build / try bots to gold 2.20. > > [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh > Rather, use the version from r32317 so you don't lose your original ld. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Linux: gold linker users should upgrade to 2.20 soon.
On Wed, Nov 18, 2009 at 3:00 AM, Lei Zhang wrote: > On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang wrote: >> If you installed gold through [1], please run it again. I've updated >> the script at r32315 to install gold 2.20. I've also updated all the >> Linux build / try bots to gold 2.20. >> >> [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh >> > > Rather, use the version from r32317 so you don't lose your original ld. > Whoops, the script outsmarted me and does not install gold if it's already installed. If you need to upgrade, you have to uninstall first. To quote the script: cd /usr/bin; sudo rm ld; sudo mv ld.orig ld -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Linux: gold linker users should upgrade to 2.20 soon.
If you are just testing the Google Chrome build and you don't need symbols, you can always comment out the -gstabs line in build/common.gypi. On Sat, Nov 21, 2009 at 9:10 PM, David Moore wrote: > Problem solved. Coincident with using the new linker I started building the > Google Chrome build. This uses breakpad, which turns on stabs, which makes > everything slower and bigger by a factor of 5. Only do the Chrome build if > you need to is the lesson. > Dave > > On Sat, Nov 21, 2009 at 8:39 PM, David Moore wrote: >> >> I checked and I compiled with -O2. I see a similar slowdown in the ar >> calls. I also notice that the size of the chrome executable is now 2GB. I >> think before the size was closer to 350MB. It was 750MB if you included >> webkit symbols. Perhaps something changed about the way we're managing >> symbols. >> Dave >> >> On Sat, Nov 21, 2009 at 6:50 PM, Antoine Labour wrote: >>> >>> >>> On Sat, Nov 21, 2009 at 6:24 PM, David Moore >>> wrote: >>>> >>>> Since I did this upgrade my builds have gotten very very slow. A single >>>> file change, recompile and relink used to be about 35 seconds. Now it's 2 >>>> and a half minutes. As far as I can tell I'm using the right gold. >>>> >>>> davemo...@dmoorel:~/chrome/src$ ld --version >>>> GNU gold (GNU Binutils 2.20) 1.9 >>>> Are other people seeing this on linux? >>>> Dave >>> >>> Make sure you compile gold with -O2. That made a huge difference for me >>> when I was playing with it, and that wasn't the default for some reason. >>> Antoine >>>> >>>> On Wed, Nov 18, 2009 at 2:47 AM, Lei Zhang wrote: >>>>> >>>>> Hi folks, >>>>> >>>>> We'll soon be relanding a patch that pass --gc-sections to the linker >>>>> on Linux. For this to work, you need either GNU ld or a recent version >>>>> of GNU gold. You can test and see if your copy of gold is new enough >>>>> by running: >>>>> >>>>> /path/to/gold --gc-sections >>>>> >>>>> If you see: "fatal error: no input files", _no action_ is required. >>>>> If you see: "--gc-sections: unknown option", then you _need to >>>>> upgrade_. >>>>> >>>>> If you installed gold through [1], please run it again. I've updated >>>>> the script at r32315 to install gold 2.20. I've also updated all the >>>>> Linux build / try bots to gold 2.20. >>>>> >>>>> [1] http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh >>>>> >>>>> -- >>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>>>> View archives, change email options, or unsubscribe: >>>>> http://groups.google.com/group/chromium-dev >>>> >>>> -- >>>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>>> View archives, change email options, or unsubscribe: >>>> http://groups.google.com/group/chromium-dev >> > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] TestShell target
(from the right address this time) make test_shell ? On Wed, Nov 25, 2009 at 5:21 PM, n179911 wrote: > Hi, > > Is there a way to build a TestShell target for chromium on linux? > On MacOS, there is a TestShell project, I wonder if there is a > TestShell target for building it on linux? > > Thank you. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] webcore_bindings target builds slowly
DerivedSourcesAllInOne.cpp is the biggest bottleneck on Linux too. Even when running make with a high -j value, one would end up in the situation where one core is pegged for more than a minutes while all the others sit idle. On Tue, Dec 1, 2009 at 10:57 AM, Lei Zhang wrote: > DerivedSourcesAllInOne.cpp is the biggest bottleneck on Linux too. > Even when running make with a high -j value, one would end up in the > situation where one core is pegged for more than a minutes while all > the others sit idle. > > On Tue, Dec 1, 2009 at 9:32 AM, Jens Alfke wrote: >> On Mac* the WebCore Xcode project has a separate build target >> "webcore_bindings" that contains DerivedSourcesAllInOne.cpp and a >> handful of other files. This setup is really slowing down the build >> process on my Mac Pro, because DerivedSourcesAllInOne takes much >> longer to compile than any of the other sources in that target (since >> it #includes about 100 .cpp files), so there's a long period where one >> of the 8 cores is compiling that one file while the others are >> twiddling their thumbs. >> >> (I notice this especially because I've been working on V8 bindings >> stuff lately, so everything I touch tends to force that target to >> rebuild.) >> >> This could be improved either by >> a- merging this target in with the main WebCore target (didn't it use >> to be that way?) >> b- adding more files to this target to give the other cores something >> to do >> c- breaking up DerivedSourcesAllInOne into several pieces to compile >> simultaneously >> >> Anyone have any thoughts about this? (Option c seems attractively easy >> to do...) >> >> —Jens >> >> *maybe this applies to other platforms too, since the basic build >> structure comes from the shared .gyp file? >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Need a linux-views build buddy.
I filed http://crbug.com/29364 On Thu, Dec 3, 2009 at 2:45 PM, Mike Pinkerton wrote: > Yes, except it's down and hasn't worked in days. > > On Thu, Dec 3, 2009 at 5:44 PM, Jeremy Orlow wrote: >> Isn't "gcl try -b linux_view" what you want? >> >> On Thu, Dec 3, 2009 at 1:46 PM, Mike Pinkerton >> wrote: >>> >>> I've got a cl that builds fine on win/mac/linux but I'm afraid I could >>> impact views_linux. And, since there's no trybot, I have no way of >>> knowing until I actually check in and break it. >>> >>> That's where you come in! Would someone mind trying >>> >>> http://codereview.chromium.org/465005/show >>> >>> for me with linux views and see if it's all ok? The only tricky part >>> is that there's an svn move on 2 files in there, but the trybots seem >>> able to figure it out. Would be much appreciated, thanks! >>> >>> -- >>> Mike Pinkerton >>> Mac Weenie >>> pinker...@google.com >>> >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >> >> > > > > -- > Mike Pinkerton > Mac Weenie > pinker...@google.com > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] "make all" doesn't work.
Works for me. Do you have an "all" target in your Makefile? Can you see what $all_targets is set to? On Thu, Dec 3, 2009 at 10:29 PM, James Su wrote: > "make chrome" works as expected, it builds out the chrome binary. But "make" > or "make all" doesn't work at all. > > - James Su > > 2009/12/4 Craig Schlenter >> >> Hi >> >> One known problem with the make build is that you sometimes have to >> run it twice to rebuild the chrome target as the strings sometimes >> don't get rebuilt properly but if make chrome does something, then in >> theory make/make all should have built that too. >> >> What does make chrome build that make all doesn't? - that might give >> us some clues as to what is wrong. >> >> --Craig >> >> On Fri, Dec 4, 2009 at 7:53 AM, James Su wrote: >> > Unfortunately, it doesn't work. Actually, "make" == "make all". >> > >> > - James Su >> > >> > 2009/12/4 Craig Schlenter >> >> >> >> I think you don't need to specify a target to build everything i.e. >> >> just type make and it should work. >> >> >> >> --Craig >> >> >> >> On Fri, Dec 4, 2009 at 7:44 AM, James Su wrote: >> >> > Hi, >> >> > I just switched to use make to build chromium linux, but I found >> >> > that >> >> > "make all" didn't work at all. It only told me: make: Nothing to be >> >> > done >> >> > for >> >> > `all'. Though it works if I specify the target name explicitly, such >> >> > as >> >> > "make chrome". Is it a known issue of gyp? Or I missed something? >> >> > >> >> > - James Su >> >> > >> >> > -- >> >> > Chromium Developers mailing list: chromium-dev@googlegroups.com >> >> > View archives, change email options, or unsubscribe: >> >> > http://groups.google.com/group/chromium-dev >> > >> > > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] I use Chrome 4 in Ubuntu 9.10, I found the Chinese font text is too vague
File a bug at http://new.crbug.com/, provide screenshots. This mailing list is not the appropriate place to report bugs. On Sat, Dec 5, 2009 at 7:57 PM, Blade wrote: > Especially the text on buttons, Chinese characters, are very vague. > How can I solve this problem? > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
On Tue, Dec 8, 2009 at 4:11 PM, Evan Stade wrote: > proposals on which of these options (again, see original attachment) to "rip > out" are welcome and within the scope of this thread. The vbox? holding the bookmark sync status boxes is too narrow. If it used all the horizontal space, it would waste a bit less vertical space. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: > Anyhow, what's our best practices for disabling tests? I think ideally we'd > always log a tracking bug and add a comment, akin to what we do in the > test_expectations file for layout tests. Another point to keep in mind - when you file a bug, do not write: "test foo.bar failed, here's the error: http://path/to/failed_test.log"; because we don't keep logs forever. Please paste the snippet of the log with the error instead. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] linux_view trybot seems unable to accept any patch
It has a custom .gclient entry for chrome-deps, should that be cros_deps? On Tue, Dec 15, 2009 at 3:24 PM, James Robinson wrote: > Every patch sent to the linux_view trybot lately dies with this error > in the 'gclient' step: > > Exception: > /b/slave/linux_view/build/src/third_party/chromeos_login_manager/chromeos_login_manager/chromeos_login_manager.gyp > not found (cwd: /b/slave/linux_view/build) while loading dependencies > of /b/slave/linux_view/build/src/chrome/chrome.gyp while loading > dependencies of /b/slave/linux_view/build/src/build/all.gyp while > trying to load src/build/all.gyp > failed to run command: /usr/bin/python src/build/gyp_chromium > > It seems like this bot is pretty much 100% useless right now. Is > someone looking into it? > > - James > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] linux_view trybot seems unable to accept any patch
The 3 linux_views bots currently have Git 1.5.
Can someone answer my question regarding chrome-deps vs cros_deps? I
don't think chrome-deps/DEPS is correct. It has:
deps = {
# Cros library that's dynamically linked to by Chrome
"src/third_party/cros" :
"/trunk/src/platform/c...@146",
# Source for the chrome os login manager to be built along with the
# chrome os build of chrome
"src/third_party/chromeos_login_manager" :
"/trunk/src/platform/login_manager/chromeos_login_mana...@48",
# dependency for login manager in chrome os
"src/third_party/chromeos_login_manager/include" :
"/trunk/src/third_party/pam-...@30",
}
but /trunk/src/platform/login_manager/chromeos_login_manager doesn't
seem to exist?
On the linux_views valgrind bot, I see it has cros_deps/DEPS instead, which has:
deps = {
"src/third_party/cros":
Var("chromium_git") + "/cros@767ada11",
"src/third_party/chromeos_login_manager":
Var("chromium_git") + "/login_manager@c51b4b0a",
}
On Tue, Dec 15, 2009 at 4:15 PM, Scott Violet wrote:
> There's been some recent Chrome OS changes that have caused a world of
> hurt on the try servers/build infrastructure. I believe we need to
> update the try bots to > git 1.6.1. Marc-Antoine has done a slew of
> changes, and I believe the last step is updating the install build
> script to take care of installing/updating git. Dave Moore, Chris
> Masone and myself spoke about this about an hour ago and I believe one
> of them is actively looking into this now.
>
> -Scott
>
> On Tue, Dec 15, 2009 at 3:37 PM, Lei Zhang wrote:
>> It has a custom .gclient entry for chrome-deps, should that be cros_deps?
>>
>> On Tue, Dec 15, 2009 at 3:24 PM, James Robinson wrote:
>>> Every patch sent to the linux_view trybot lately dies with this error
>>> in the 'gclient' step:
>>>
>>> Exception:
>>> /b/slave/linux_view/build/src/third_party/chromeos_login_manager/chromeos_login_manager/chromeos_login_manager.gyp
>>> not found (cwd: /b/slave/linux_view/build) while loading dependencies
>>> of /b/slave/linux_view/build/src/chrome/chrome.gyp while loading
>>> dependencies of /b/slave/linux_view/build/src/build/all.gyp while
>>> trying to load src/build/all.gyp
>>> failed to run command: /usr/bin/python src/build/gyp_chromium
>>>
>>> It seems like this bot is pretty much 100% useless right now. Is
>>> someone looking into it?
>>>
>>> - James
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] linux_view trybot seems unable to accept any patch
Ok, I think I fixed it. Running a test job right now. *fingers crossed*
http://build.chromium.org/buildbot/try-server/builders/linux_view/builds/1474
On Tue, Dec 15, 2009 at 4:29 PM, Scott Violet wrote:
> They need:
>
> { "name" : "cros deps",
> "url" : "svn://chrome-svn/chrome/trunk/cros_deps",
> },
>
> in .gclient, but there may be syncing problems unless you have git > 1.6.1 .
>
> "cros deps" is the new way dependency are managed between the two projects.
>
> -Scott
>
> On Tue, Dec 15, 2009 at 4:26 PM, Lei Zhang wrote:
>> The 3 linux_views bots currently have Git 1.5.
>>
>> Can someone answer my question regarding chrome-deps vs cros_deps? I
>> don't think chrome-deps/DEPS is correct. It has:
>>
>> deps = {
>> # Cros library that's dynamically linked to by Chrome
>> "src/third_party/cros" :
>> "/trunk/src/platform/c...@146",
>> # Source for the chrome os login manager to be built along with the
>> # chrome os build of chrome
>> "src/third_party/chromeos_login_manager" :
>> "/trunk/src/platform/login_manager/chromeos_login_mana...@48",
>> # dependency for login manager in chrome os
>> "src/third_party/chromeos_login_manager/include" :
>> "/trunk/src/third_party/pam-...@30",
>> }
>>
>> but /trunk/src/platform/login_manager/chromeos_login_manager doesn't
>> seem to exist?
>>
>> On the linux_views valgrind bot, I see it has cros_deps/DEPS instead, which
>> has:
>>
>> deps = {
>> "src/third_party/cros":
>> Var("chromium_git") + "/cros@767ada11",
>> "src/third_party/chromeos_login_manager":
>> Var("chromium_git") + "/login_manager@c51b4b0a",
>> }
>>
>> On Tue, Dec 15, 2009 at 4:15 PM, Scott Violet wrote:
>>> There's been some recent Chrome OS changes that have caused a world of
>>> hurt on the try servers/build infrastructure. I believe we need to
>>> update the try bots to > git 1.6.1. Marc-Antoine has done a slew of
>>> changes, and I believe the last step is updating the install build
>>> script to take care of installing/updating git. Dave Moore, Chris
>>> Masone and myself spoke about this about an hour ago and I believe one
>>> of them is actively looking into this now.
>>>
>>> -Scott
>>>
>>> On Tue, Dec 15, 2009 at 3:37 PM, Lei Zhang wrote:
>>>> It has a custom .gclient entry for chrome-deps, should that be cros_deps?
>>>>
>>>> On Tue, Dec 15, 2009 at 3:24 PM, James Robinson
>>>> wrote:
>>>>> Every patch sent to the linux_view trybot lately dies with this error
>>>>> in the 'gclient' step:
>>>>>
>>>>> Exception:
>>>>> /b/slave/linux_view/build/src/third_party/chromeos_login_manager/chromeos_login_manager/chromeos_login_manager.gyp
>>>>> not found (cwd: /b/slave/linux_view/build) while loading dependencies
>>>>> of /b/slave/linux_view/build/src/chrome/chrome.gyp while loading
>>>>> dependencies of /b/slave/linux_view/build/src/build/all.gyp while
>>>>> trying to load src/build/all.gyp
>>>>> failed to run command: /usr/bin/python src/build/gyp_chromium
>>>>>
>>>>> It seems like this bot is pretty much 100% useless right now. Is
>>>>> someone looking into it?
>>>>>
>>>>> - James
>>>>>
>>>>> --
>>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>>>> View archives, change email options, or unsubscribe:
>>>>> http://groups.google.com/group/chromium-dev
>>>>>
>>>>
>>>> --
>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>>> View archives, change email options, or unsubscribe:
>>>> http://groups.google.com/group/chromium-dev
>>>>
>>>
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] linux_view trybot seems unable to accept any patch
Hmm, is the try server master overdue for a reload/restart? The
master.cfg is right, but it's still checking out chrome-deps.
On Tue, Dec 15, 2009 at 4:40 PM, Lei Zhang wrote:
> Ok, I think I fixed it. Running a test job right now. *fingers crossed*
>
> http://build.chromium.org/buildbot/try-server/builders/linux_view/builds/1474
>
> On Tue, Dec 15, 2009 at 4:29 PM, Scott Violet wrote:
>> They need:
>>
>> { "name" : "cros deps",
>> "url" : "svn://chrome-svn/chrome/trunk/cros_deps",
>> },
>>
>> in .gclient, but there may be syncing problems unless you have git > 1.6.1 .
>>
>> "cros deps" is the new way dependency are managed between the two projects.
>>
>> -Scott
>>
>> On Tue, Dec 15, 2009 at 4:26 PM, Lei Zhang wrote:
>>> The 3 linux_views bots currently have Git 1.5.
>>>
>>> Can someone answer my question regarding chrome-deps vs cros_deps? I
>>> don't think chrome-deps/DEPS is correct. It has:
>>>
>>> deps = {
>>> # Cros library that's dynamically linked to by Chrome
>>> "src/third_party/cros" :
>>> "/trunk/src/platform/c...@146",
>>> # Source for the chrome os login manager to be built along with the
>>> # chrome os build of chrome
>>> "src/third_party/chromeos_login_manager" :
>>> "/trunk/src/platform/login_manager/chromeos_login_mana...@48",
>>> # dependency for login manager in chrome os
>>> "src/third_party/chromeos_login_manager/include" :
>>> "/trunk/src/third_party/pam-...@30",
>>> }
>>>
>>> but /trunk/src/platform/login_manager/chromeos_login_manager doesn't
>>> seem to exist?
>>>
>>> On the linux_views valgrind bot, I see it has cros_deps/DEPS instead, which
>>> has:
>>>
>>> deps = {
>>> "src/third_party/cros":
>>> Var("chromium_git") + "/cros@767ada11",
>>> "src/third_party/chromeos_login_manager":
>>> Var("chromium_git") + "/login_manager@c51b4b0a",
>>> }
>>>
>>> On Tue, Dec 15, 2009 at 4:15 PM, Scott Violet wrote:
>>>> There's been some recent Chrome OS changes that have caused a world of
>>>> hurt on the try servers/build infrastructure. I believe we need to
>>>> update the try bots to > git 1.6.1. Marc-Antoine has done a slew of
>>>> changes, and I believe the last step is updating the install build
>>>> script to take care of installing/updating git. Dave Moore, Chris
>>>> Masone and myself spoke about this about an hour ago and I believe one
>>>> of them is actively looking into this now.
>>>>
>>>> -Scott
>>>>
>>>> On Tue, Dec 15, 2009 at 3:37 PM, Lei Zhang wrote:
>>>>> It has a custom .gclient entry for chrome-deps, should that be cros_deps?
>>>>>
>>>>> On Tue, Dec 15, 2009 at 3:24 PM, James Robinson
>>>>> wrote:
>>>>>> Every patch sent to the linux_view trybot lately dies with this error
>>>>>> in the 'gclient' step:
>>>>>>
>>>>>> Exception:
>>>>>> /b/slave/linux_view/build/src/third_party/chromeos_login_manager/chromeos_login_manager/chromeos_login_manager.gyp
>>>>>> not found (cwd: /b/slave/linux_view/build) while loading dependencies
>>>>>> of /b/slave/linux_view/build/src/chrome/chrome.gyp while loading
>>>>>> dependencies of /b/slave/linux_view/build/src/build/all.gyp while
>>>>>> trying to load src/build/all.gyp
>>>>>> failed to run command: /usr/bin/python src/build/gyp_chromium
>>>>>>
>>>>>> It seems like this bot is pretty much 100% useless right now. Is
>>>>>> someone looking into it?
>>>>>>
>>>>>> - James
>>>>>>
>>>>>> --
>>>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>>>>> View archives, change email options, or unsubscribe:
>>>>>> http://groups.google.com/group/chromium-dev
>>>>>>
>>>>>
>>>>> --
>>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>>>> View archives, change email options, or unsubscribe:
>>>>> http://groups.google.com/group/chromium-dev
>>>>>
>>>>
>>>
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] linux_view trybot seems unable to accept any patch
Unless I hear otherwise, I'll restart the try server master tonight at 9 PM PST, and apologize to the people whose try jobs failed as a result. On Tue, Dec 15, 2009 at 4:48 PM, Lei Zhang wrote: > Hmm, is the try server master overdue for a reload/restart? The > master.cfg is right, but it's still checking out chrome-deps. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] linux_view trybot seems unable to accept any patch
It'll reload the try server configuration so try jobs will pull the right deps. I already installed git 1.6 on the linux_view and linux_chromeos try bots. On Tue, Dec 15, 2009 at 6:15 PM, Chris Masone wrote: > I'm not familiar with the infrastructure...what will that make it do? > Also, djmm@ is working on getting install_build_deps.sh to install an > appropriate version of git...we should still get that done, right? > > On Tue, Dec 15, 2009 at 6:13 PM, Lei Zhang wrote: >> Unless I hear otherwise, I'll restart the try server master tonight at >> 9 PM PST, and apologize to the people whose try jobs failed as a >> result. >> >> On Tue, Dec 15, 2009 at 4:48 PM, Lei Zhang wrote: >>> Hmm, is the try server master overdue for a reload/restart? The >>> master.cfg is right, but it's still checking out chrome-deps. >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] linux_view trybot seems unable to accept any patch
I also needed to install libpam0g-dev. Linux_view try bots should be happy now. On Tue, Dec 15, 2009 at 7:03 PM, Lei Zhang wrote: > It'll reload the try server configuration so try jobs will pull the > right deps. I already installed git 1.6 on the linux_view and > linux_chromeos try bots. > > On Tue, Dec 15, 2009 at 6:15 PM, Chris Masone wrote: >> I'm not familiar with the infrastructure...what will that make it do? >> Also, djmm@ is working on getting install_build_deps.sh to install an >> appropriate version of git...we should still get that done, right? >> >> On Tue, Dec 15, 2009 at 6:13 PM, Lei Zhang wrote: >>> Unless I hear otherwise, I'll restart the try server master tonight at >>> 9 PM PST, and apologize to the people whose try jobs failed as a >>> result. >>> >>> On Tue, Dec 15, 2009 at 4:48 PM, Lei Zhang wrote: >>>> Hmm, is the try server master overdue for a reload/restart? The >>>> master.cfg is right, but it's still checking out chrome-deps. >>> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] How to deal with flaky unit tests
Does FLAKY_ work on all tests? The test run [1] for my most recent check-in turned a bot red, even though the only test that failed is one marked FLAKY_. [red] browser_tests [browser_tests 896 flaky did not complete crashed or hung] [197 seconds] [/red] and in the log; [2] ... Note: Google Test filter = AutocompleteBrowserTest.YOU HAVE 8 FLAKY TESTS [==] Running 0 tests from 0 test cases. [==] 0 tests from 0 test cases ran. (0 ms total) [ PASSED ] 0 tests. YOU HAVE 8 FLAKY TESTS 113 tests run 1 test failed Failing tests: ExtensionBrowserTest.FLAKY_AutoUpdate program finished with exit code 1 elapsedTime=197.683425 [1] http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20(Views%20dbg)/builds/5784 [2] http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20(Views%20dbg)/builds/5784/steps/browser_tests/logs/stdio On Tue, Oct 6, 2009 at 4:02 PM, Nicolas Sylvain wrote: > Hello, > We currently have more than 50 unit tests that are disabled. Most of them > because they were flaky. > Disabling tests is bad because we lose complete coverage on them, so I > implemented a way to mark > tests as "flaky". > The same way you disable a test with DISABLED_ at the beginning of its name, > you can now mark > is as flaky with FLAKY_. The behavior is exactly the same as any other > running tests. You will still > be able to see when it fails (and why). The only difference is that if only > FLAKY_ tests failed, the > buildbot/trybots won't consider it as a failure. On the waterfall, it will > show the box as orange with the > list of all flaky tests that failed (pending one more buildbot restart). On > the console view it will stay > green. > But.. this is not a toy. Flaky tests are bad. We should mark tests flaky > only if we really have to, and > if you do, please make sure to file a P1 bug. Set the owner of the bug to > whoever regressed the test. > If you can't find who regressed the test, assign it to the person who > originally wrote the test. > Once we start tagging the flaky tests, we will monitor the flakiness > dashboard and make sure > that a test that is no longer flaky has its FLAKY_ tag removed. > Let me know if you have questions. > Thanks > Nicolas > > --~--~-~--~~~---~--~~ > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > > -~--~~~~--~~--~--~--- > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] about issue #31155 : style properties returning localized string ofr numeric values
The bug tracker is a bit backlogged because many people went on vacation the last few weeks. There's no need to email chromium-dev about it. If everyone did that then chromium-dev would just be chromium-bugs. On Wed, Jan 6, 2010 at 2:20 AM, kapouer wrote: > Hi, > could someone check > http://code.google.com/p/chromium/issues/detail?id=31155 > > it's easy to reproduce. > I have the feeling it's not only an ubuntu-build bug. > > Regards, > Jérémy Lal > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Build issue GL/glu.h
See the email from 3 days ago titled "PSA: new dev packages needed on linux" On Thu, Jan 7, 2010 at 8:14 AM, Aaron wrote: > Any idea what could be causing this thing? It's been going on for > some time now. All of my research turns up nothing. > > CXX(target) out/Release/obj.target/command_buffer_service/gpu/ > command_buffer/service/gles2_cmd_decoder.o > In file included from ./gpu/command_buffer/common/gles2_cmd_format.h: > 16, > from gpu/command_buffer/service/gles2_cmd_decoder.cc: > 15: > third_party/glew/include/GL/glew.h:1476:20: error: GL/glu.h: No such > file or directory > make: *** [out/Release/obj.target/command_buffer_service/gpu/ > command_buffer/service/gles2_cmd_decoder.o] Error 1 > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Linux sandbox configuration
Can you elaborate on what you mean by "configure the sandbox"? On Fri, Jan 8, 2010 at 11:36 PM, n179911 wrote: > Hi, > > Can you please tell me if/where is the file to configure chromium's > renderer sandbox? > > Thank you. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
