Re: [chromium-dev] Core Text
Here are some numbers: 10.5 75270ms 10.6 Core Text 77191ms 10.6 ATSUI 73293ms These were calculated by running PageCyclerTest.Intl2File 3 times on each platform, summing the times reported for the individual tests and then averaging over the 3 runs. I'm not sure these actually represent interesting numbers. The extra speediness in 10.6 ATSUI may be due to it ignoring certain parts of the font hinting data leading to the bug this is all in place to fix. Best regards, Jeremy On Mon, Dec 14, 2009 at 6:46 PM, Mark Mentovai m...@chromium.org wrote: Jeremy Moskovich wrote: Yep, Avi's right - we don't really have that option here. ATSUI is deprecated in 10.6 - we're seeing crashes and incorrect rendering. If there are perf issues we can file radars against Core Text. We should at least know what this change does to us perf-wise. If we're not happy with the outcome, there may be things we can tune on our side or things that we can press on Apple to investigate on the CoreText side. Mark -- 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: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 6:24 PM, Aaron Boodman a...@chromium.org wrote: On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay erik...@chromium.org wrote: On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman a...@chromium.org wrote: Seems like a bad idea. Extensions and DOMUI are basically two competing systems for doing the same thing, it would get confusing combining them. While I can see this in principle, I'm not sure I see what the problems are in practice. What kinds of problems do you envision? I think it would be nice for our current DOMUI pages to be built on top of the extensions APIs, but potentially have access to a few special APIs that extensions don't. It seems like it would be painful to try to cut them over to such a system all at once, so adding extensions APIs to DOMUI pages could be a nice bridge. When you say built on top of the extensions APIs do you mean have access to, eg, chrome.tabs.*? I'm more interested in this aspect in the short term, and I think this is what would most help arv in the short term as well. Regardless of how the dispatch system works, even the APIs themselves are there, we're more likely to be able to migrate the existing pages to use the same APIs. Or do you mean use our ExtensionFunctionDispatcher and json schema infrastructure, but not use any of our APIs? I think it would be cool to do this as well, but more from the standpoint that it would then be more straightforward for new APIs to be added and supported that could be used in both places. I looked at the latter once before and it was a serious project. There is a lot of knowledge about the extension system baked into ExtensionFunctionDispatcher, such as who the current extension is and knowledge of the json schema system in the renderer. I think a simpler approach to get the benefits of the extension system is to just make the bookmark manager an extension. We'd have to filter it out of the chrome://extensions/ page and change its icon in the task manager, but those are fairly trivial changes compared to tearing all the knowledge of extensions out of ExtensionFunctionDispatcher system. If we want the bookmark manager to have some special APIs that other extensions don't, that also seems fairly easy to do once the bookmark manager is indeed an extension. To be clear, I'm also open to lower-level refactorings. I'm just warning that I suspect it's a serious project. A couple weeks at least. Yeah, I can imagine that. It sounds like Erik's needs are shorter term than would warrant this kind of approach. Erik - a -- 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] Re: Exposing Chrome Extensions APIs to DOM UI.
(and again from right address) Since snej is writing a native bookmark manager on OS X that is done this week from what I understand, it seems like there is no need for a rush here. If you think the more involved solution is better, it might be worth doing. On Tue, Dec 15, 2009 at 8:01 AM, Nico Weber tha...@google.com wrote: Since snej is writing a native bookmark manager on OS X that is done this week from what I understand, it seems like there is no need for a rush here. If you think the more involved solution is better, it might be worth doing. On Tue, Dec 15, 2009 at 7:28 AM, Erik Kay erik...@chromium.org wrote: On Mon, Dec 14, 2009 at 6:24 PM, Aaron Boodman a...@chromium.org wrote: On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay erik...@chromium.org wrote: On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman a...@chromium.org wrote: Seems like a bad idea. Extensions and DOMUI are basically two competing systems for doing the same thing, it would get confusing combining them. While I can see this in principle, I'm not sure I see what the problems are in practice. What kinds of problems do you envision? I think it would be nice for our current DOMUI pages to be built on top of the extensions APIs, but potentially have access to a few special APIs that extensions don't. It seems like it would be painful to try to cut them over to such a system all at once, so adding extensions APIs to DOMUI pages could be a nice bridge. When you say built on top of the extensions APIs do you mean have access to, eg, chrome.tabs.*? I'm more interested in this aspect in the short term, and I think this is what would most help arv in the short term as well. Regardless of how the dispatch system works, even the APIs themselves are there, we're more likely to be able to migrate the existing pages to use the same APIs. Or do you mean use our ExtensionFunctionDispatcher and json schema infrastructure, but not use any of our APIs? I think it would be cool to do this as well, but more from the standpoint that it would then be more straightforward for new APIs to be added and supported that could be used in both places. I looked at the latter once before and it was a serious project. There is a lot of knowledge about the extension system baked into ExtensionFunctionDispatcher, such as who the current extension is and knowledge of the json schema system in the renderer. I think a simpler approach to get the benefits of the extension system is to just make the bookmark manager an extension. We'd have to filter it out of the chrome://extensions/ page and change its icon in the task manager, but those are fairly trivial changes compared to tearing all the knowledge of extensions out of ExtensionFunctionDispatcher system. If we want the bookmark manager to have some special APIs that other extensions don't, that also seems fairly easy to do once the bookmark manager is indeed an extension. To be clear, I'm also open to lower-level refactorings. I'm just warning that I suspect it's a serious project. A couple weeks at least. Yeah, I can imagine that. It sounds like Erik's needs are shorter term than would warrant this kind of approach. Erik - a -- 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] Re: Building chromium for arm--erroring out
Hi All, I have not touched sysroot at all. The only thing that I changed was the GYP_DEFINES and I did the gclient sync. That broke the whole thing. Does anyone know how I could get back to the old revision of source ? Thanks, Sofia On Mon, Dec 14, 2009 at 5:32 PM, Antoine Labour pi...@chromium.org wrote: On Mon, Dec 14, 2009 at 1:30 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Hi Antoine/All, This is what I did: export GYP_DEFINES=target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1 gclient runhooks --force gclient sync export CROSSTOOL=/home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/arm-none-linux-gnueabi export CXX=$CROSSTOOL-g++ export CC=$CROSSTOOL-gcc export AR=$CROSSTOOL-ar export AS=$CROSSTOOL-as export RANLIB=$CROSSTOOL-ranlib export LD=$CROSSTOOL-ld And then I run the make command make -r -j6 BUILDTYPE=Release chrome 21 |tee ./makelog.txt To my suprise, the build is erroring out... I am attaching the makelog for this. Really appreciate your help on this. Thanks, Sofia The very first target compilation steps fails with missing standard headers, which would point at a sysroot problem... Antoine On Mon, Dec 14, 2009 at 2:19 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Yes it was erroring out at the same point S32A_Opaque_BlitRow32_neon...but I had not done gclient runhooks --force...Now I am re-doing it...Lets wait and see how this works. On Mon, Dec 14, 2009 at 1:07 PM, Erik Corry erik.co...@gmail.comwrote: 2009/12/14 Sofia Tahseen sofia.tahs...@gmail.com Hi Antoine, I did exactly what you said-- not set armv7=1 in gyp_defines. export GYP_DEFINES=target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1 I rebuilt chromium. And then I reset my kernel so that it does not use NEON. This does not help and the browser keeps crashing again even though I do not set armv7=1 in gyp_defines. So is there a way to disable neon settings on chromium browser and make chromium working on a hardware that does not support NEON? Is it still crashing in S32A_Opaque_BlitRow32_neon ? Thanks, Sofia On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour pi...@chromium.orgwrote: On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen sofia.tahs...@gmail.com wrote: Hi Joel/Erik/All, I don't think armv5 is an issue. Reason being I used the jaunty armv5 libraries to build chrome. I tried to debug the issue with gdb. gdb chrome GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi... (gdb) (gdb) run Starting program: /home/adas/Release/chrome [Thread debugging using libthread_db enabled] [New Thread 0x4112ac80 (LWP 9722)] [New Thread 0x41d49440 (LWP 9727)] [New Thread 0x42549440 (LWP 9728)] [New Thread 0x42d49440 (LWP 9729)] [New Thread 0x43549440 (LWP 9730)] [New Thread 0x43d49440 (LWP 9731)] [New Thread 0x44549440 (LWP 9732)] [New Thread 0x44d49440 (LWP 9733)] [New Thread 0x44d69440 (LWP 9734)] [New Thread 0x458ff440 (LWP 9738)] [New Thread 0x460ff440 (LWP 9739)] [Thread 0x460ff440 (LWP 9739) exited] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x4112ac80 (LWP 9722)] 0x0081caec in S32A_Opaque_BlitRow32_neon () Current language: auto; currently asm The error S32A_Opaque_BlitRow32_neon () had to do something with the floating point setting of the kernel. I checked my kernel configuration and neon was not set. So I set it and it rebuild my kernel and booted my jaunty. Now it works perfectly...without any crashes. Key : In order to run chromium we need to set the neon in the kernel configuration. Note, if you don't set armv7=1 when you build chromium, it shouldn't use the NEON paths, so you shouldn't run into that problem. But it's better to enable it in the kernel if your hardware supports it. Antoine Regards, Sofia On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry erik.co...@gmail.comwrote: 2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now I could build the chrome browser ...finally!! I copied the whole /src/out/Release directory to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: ./chrome It starts up chrome, and then immediately kills chrome. I get an Illegal Instruction. I restart and I can now see chrome as shown in the attachment but I cannot browse. When I reload the page, it again kills chrome saying Illegal instruction. Has anyone seen this before? I have my proxy settings set
[chromium-dev] r34565 clobber notice: IncrediBuild + Recent WebKit Roll = :(
I just committed a WebKit roll (r34565) which requires clobbering if you're running IncrediBuild. Not sure why, but that's the outcome I've seen on on the build bots. If you compile using native VS compiler, the dependency-tracking works correctly. Mac and Linux builds are not affected. If you don't clobber, you won't get compile errors. Instead, you'll see fun layout test and test_shell tests failures, like so: http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/17668 :DG -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Webkit (dbg)(1), revision 34565
Automatically closing tree for test_shell_tests on Webkit (dbg)(1) http://build.chromium.org/buildbot/waterfall/builders/Webkit%20%28dbg%29%281%29/builds/13704 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20%28dbg%29%281%29 --= Automatically closing tree for test_shell_tests on Webkit (dbg)(1) =-- Revision: 34564, 34565 Blame list: dglaz...@chromium.org,s...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Revision 34486 makes Chromium crash with custom themes
Hi; Per $SUBJECT, if you have a custom theme Chromium crashes at startup. See http://code.google.com/p/chromium/issues/detail?id=30453 and http://code.google.com/p/chromium/issues/detail?id=30465 more duplicates are coming possibly. -- 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] Re: Building chromium for arm--erroring out
Has anyone been able to successfully build chromium for arm after doing a gclient sync(meaning on the latest source code) ???Can someone please verify this ? On Tue, Dec 15, 2009 at 11:19 AM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Hi All, I have not touched sysroot at all. The only thing that I changed was the GYP_DEFINES and I did the gclient sync. That broke the whole thing. Does anyone know how I could get back to the old revision of source ? Thanks, Sofia On Mon, Dec 14, 2009 at 5:32 PM, Antoine Labour pi...@chromium.orgwrote: On Mon, Dec 14, 2009 at 1:30 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Hi Antoine/All, This is what I did: export GYP_DEFINES=target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1 gclient runhooks --force gclient sync export CROSSTOOL=/home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/arm-none-linux-gnueabi export CXX=$CROSSTOOL-g++ export CC=$CROSSTOOL-gcc export AR=$CROSSTOOL-ar export AS=$CROSSTOOL-as export RANLIB=$CROSSTOOL-ranlib export LD=$CROSSTOOL-ld And then I run the make command make -r -j6 BUILDTYPE=Release chrome 21 |tee ./makelog.txt To my suprise, the build is erroring out... I am attaching the makelog for this. Really appreciate your help on this. Thanks, Sofia The very first target compilation steps fails with missing standard headers, which would point at a sysroot problem... Antoine On Mon, Dec 14, 2009 at 2:19 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Yes it was erroring out at the same point S32A_Opaque_BlitRow32_neon...but I had not done gclient runhooks --force...Now I am re-doing it...Lets wait and see how this works. On Mon, Dec 14, 2009 at 1:07 PM, Erik Corry erik.co...@gmail.comwrote: 2009/12/14 Sofia Tahseen sofia.tahs...@gmail.com Hi Antoine, I did exactly what you said-- not set armv7=1 in gyp_defines. export GYP_DEFINES=target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1 I rebuilt chromium. And then I reset my kernel so that it does not use NEON. This does not help and the browser keeps crashing again even though I do not set armv7=1 in gyp_defines. So is there a way to disable neon settings on chromium browser and make chromium working on a hardware that does not support NEON? Is it still crashing in S32A_Opaque_BlitRow32_neon ? Thanks, Sofia On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour pi...@chromium.orgwrote: On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen sofia.tahs...@gmail.com wrote: Hi Joel/Erik/All, I don't think armv5 is an issue. Reason being I used the jaunty armv5 libraries to build chrome. I tried to debug the issue with gdb. gdb chrome GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi... (gdb) (gdb) run Starting program: /home/adas/Release/chrome [Thread debugging using libthread_db enabled] [New Thread 0x4112ac80 (LWP 9722)] [New Thread 0x41d49440 (LWP 9727)] [New Thread 0x42549440 (LWP 9728)] [New Thread 0x42d49440 (LWP 9729)] [New Thread 0x43549440 (LWP 9730)] [New Thread 0x43d49440 (LWP 9731)] [New Thread 0x44549440 (LWP 9732)] [New Thread 0x44d49440 (LWP 9733)] [New Thread 0x44d69440 (LWP 9734)] [New Thread 0x458ff440 (LWP 9738)] [New Thread 0x460ff440 (LWP 9739)] [Thread 0x460ff440 (LWP 9739) exited] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x4112ac80 (LWP 9722)] 0x0081caec in S32A_Opaque_BlitRow32_neon () Current language: auto; currently asm The error S32A_Opaque_BlitRow32_neon () had to do something with the floating point setting of the kernel. I checked my kernel configuration and neon was not set. So I set it and it rebuild my kernel and booted my jaunty. Now it works perfectly...without any crashes. Key : In order to run chromium we need to set the neon in the kernel configuration. Note, if you don't set armv7=1 when you build chromium, it shouldn't use the NEON paths, so you shouldn't run into that problem. But it's better to enable it in the kernel if your hardware supports it. Antoine Regards, Sofia On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry erik.co...@gmail.comwrote: 2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now I could build the chrome browser ...finally!! I copied the whole /src/out/Release directory to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: ./chrome It starts up chrome, and then immediately kills chrome. I
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 34597
Automatically closing tree for compile on Linux Builder (ChromiumOS) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/1399 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29 --= Automatically closing tree for compile on Linux Builder (ChromiumOS) =-- Revision: 34597 Blame list: bre...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- 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] Re: Building chromium for arm--erroring out
On Tue, Dec 15, 2009 at 11:52 AM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Has anyone been able to successfully build chromium for arm after doing a gclient sync(meaning on the latest source code) ???Can someone please verify this ? We now have a buildbot for it (thanks bradn!), see http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Arm It is green at the moment. Antoine On Tue, Dec 15, 2009 at 11:19 AM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Hi All, I have not touched sysroot at all. The only thing that I changed was the GYP_DEFINES and I did the gclient sync. That broke the whole thing. Does anyone know how I could get back to the old revision of source ? Thanks, Sofia On Mon, Dec 14, 2009 at 5:32 PM, Antoine Labour pi...@chromium.orgwrote: On Mon, Dec 14, 2009 at 1:30 PM, Sofia Tahseen sofia.tahs...@gmail.comwrote: Hi Antoine/All, This is what I did: export GYP_DEFINES=target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1 gclient runhooks --force gclient sync export CROSSTOOL=/home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/arm-none-linux-gnueabi export CXX=$CROSSTOOL-g++ export CC=$CROSSTOOL-gcc export AR=$CROSSTOOL-ar export AS=$CROSSTOOL-as export RANLIB=$CROSSTOOL-ranlib export LD=$CROSSTOOL-ld And then I run the make command make -r -j6 BUILDTYPE=Release chrome 21 |tee ./makelog.txt To my suprise, the build is erroring out... I am attaching the makelog for this. Really appreciate your help on this. Thanks, Sofia The very first target compilation steps fails with missing standard headers, which would point at a sysroot problem... Antoine On Mon, Dec 14, 2009 at 2:19 PM, Sofia Tahseen sofia.tahs...@gmail.com wrote: Yes it was erroring out at the same point S32A_Opaque_BlitRow32_neon...but I had not done gclient runhooks --force...Now I am re-doing it...Lets wait and see how this works. On Mon, Dec 14, 2009 at 1:07 PM, Erik Corry erik.co...@gmail.comwrote: 2009/12/14 Sofia Tahseen sofia.tahs...@gmail.com Hi Antoine, I did exactly what you said-- not set armv7=1 in gyp_defines. export GYP_DEFINES=target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1 I rebuilt chromium. And then I reset my kernel so that it does not use NEON. This does not help and the browser keeps crashing again even though I do not set armv7=1 in gyp_defines. So is there a way to disable neon settings on chromium browser and make chromium working on a hardware that does not support NEON? Is it still crashing in S32A_Opaque_BlitRow32_neon ? Thanks, Sofia On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour pi...@chromium.orgwrote: On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen sofia.tahs...@gmail.com wrote: Hi Joel/Erik/All, I don't think armv5 is an issue. Reason being I used the jaunty armv5 libraries to build chrome. I tried to debug the issue with gdb. gdb chrome GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi... (gdb) (gdb) run Starting program: /home/adas/Release/chrome [Thread debugging using libthread_db enabled] [New Thread 0x4112ac80 (LWP 9722)] [New Thread 0x41d49440 (LWP 9727)] [New Thread 0x42549440 (LWP 9728)] [New Thread 0x42d49440 (LWP 9729)] [New Thread 0x43549440 (LWP 9730)] [New Thread 0x43d49440 (LWP 9731)] [New Thread 0x44549440 (LWP 9732)] [New Thread 0x44d49440 (LWP 9733)] [New Thread 0x44d69440 (LWP 9734)] [New Thread 0x458ff440 (LWP 9738)] [New Thread 0x460ff440 (LWP 9739)] [Thread 0x460ff440 (LWP 9739) exited] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x4112ac80 (LWP 9722)] 0x0081caec in S32A_Opaque_BlitRow32_neon () Current language: auto; currently asm The error S32A_Opaque_BlitRow32_neon () had to do something with the floating point setting of the kernel. I checked my kernel configuration and neon was not set. So I set it and it rebuild my kernel and booted my jaunty. Now it works perfectly...without any crashes. Key : In order to run chromium we need to set the neon in the kernel configuration. Note, if you don't set armv7=1 when you build chromium, it shouldn't use the NEON paths, so you shouldn't run into that problem. But it's better to enable it in the kernel if your hardware supports it. Antoine Regards, Sofia On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry erik.co...@gmail.comwrote: 2009/12/10 Sofia Tahseen sofia.tahs...@gmail.com: You are so right, Joel... I corrected my .so and now
[chromium-dev] Layout Tests Task Force - sign-up for future work
Hi all, As discussed yesterday, there's a number of areas where we believe future work is needed. Please use the following spreadsheet to indicate which area or areas you would be interested in working on: http://spreadsheets.google.com/ccc?key=0AsD4nenTp-atdFN1MTdNb1g1SVdvbFk1M25sQXlzZmchl=en thanks, Jeff On Mon, Dec 14, 2009 at 5:27 PM, Jeff Chang jeffr...@google.com wrote: Layout Tests Task Force meeting notes 12/14/2009 * * AI for jeffreyc/dglazkov: We will be sending out a spreadsheet tomorrow with general future areas of work that folks can sign up for. LTTF and Beyond Next steps: - Fix or triage remaining failures (short-term) - Drain the finders pool - Assign milestones/priority/owner to all fixer bugs - Migrate layout tests upstream (longer-term) - Harness - Test expectations - DumpRenderTree - V8 + JSC = 3 (somehow) - infrastructure (dashboard, rebaseline tools, bot config, etc.) - Maintain compatibility (long-term) - WebKit gardening += test gardening - Gardeners = committers - inactive committers. - Improve gardening tools: - new/regression detection, notifications, etc. - Expert list and possibly semi-automated routing of bugs - keeping accurate expectations (no orange!) -- 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_view trybot seems unable to accept any patch
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-dev] ARM Buildbot
On Wed, Dec 16, 2009 at 08:11, Antoine Labour pi...@chromium.org wrote: We now have a buildbot for it (thanks bradn!), see http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Arm And it's on the main waterfall too. Thanks! Joel -- 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 jam...@chromium.org 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
I've been offline most of the day. On Dec 15, 2009 6:46 PM, Mitsuru Oshima osh...@google.com wrote: satorux asked maruel to fix it several hours ago. maruel? - oshima On Tue, Dec 15, 2009 at 3:37 PM, Lei Zhang thes...@chromium.org wrote: It has a custom .gcli... -- 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 s...@google.com 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 thes...@chromium.org 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 jam...@chromium.org 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
This lame email was a courtesy of Nexus One. So if you have time, good ahead otherwise I'll take care. On Dec 15, 2009 6:46 PM, Mitsuru Oshima osh...@google.com wrote: satorux asked maruel t... - oshima On Tue, Dec 15, 2009 at 3:37 PM, Lei Zhang thes...@chromium.org wrote: It has a custom .gcli... -- 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
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 thes...@chromium.org 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 s...@google.com 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 thes...@chromium.org 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 jam...@chromium.org 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 s...@chromium.org 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 thes...@chromium.org 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 s...@google.com 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 thes...@chromium.org 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 jam...@chromium.org
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
[chromium-dev] Re: Cannot find -lffmpegasm
Hi Dominic, On Dec 14, 1:34 pm, Dominic Mazzoni dmazz...@google.com wrote: What do you have GYP_DEFINES set to? I got a compilation error involving ffmpeg last week, but then I tried again with an empty GYP_DEFINES and it worked fine. $ echo $GYP_DEFINES returns nothing :( -- 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] Re: [chromium-reviews] Add the cmdline -open-in-new-window switch
On Mon, Dec 14, 2009 at 4:52 PM, Peter Kasting pkast...@google.com wrote: On Mon, Dec 14, 2009 at 4:47 PM, Evan Stade est...@chromium.org wrote: we have had a lot of bug reports asking for NEW_WINDOW, but none for these two dispositions. What use cases do you envisage? Wanting to open pages in either of these ways? Firefox used to have options to control this and I was sad when they removed them. so even firefox, which has about 10^5 adjustable options, thinks it is not useful enough to support. CURRENT_TAB is useful for people who like only using one tab (there are some) and for using Chrome as an external viewer for HTML-based content. NEW_BACKGROUND_TAB is useful for shoveling stuff in without disturbing whatever the user is doing. a) We don't have good support for untabbed browsing; if we really wanted to support that we should have a --no-tabs mode which removes the tab strip and forces NEW_TAB to NEW_WINDOW, but I don't think we want to support it. b) for NEW_BACKGROUND_TAB, if a user is clicking on a desktop item, they have already disrupted their current browser workflow, so I am skeptical of this use case. To put it a different way, the cost of supporting these now is basically indistinguishable from the cost of just adding --new-window. in terms of code, I don't think that's true. The current patch is extremely light weight. We're never going to remove them, so there won't be any maintenance burden. But if we implement --new-window and decide we need to support one of these, we have to add a new option. Are you gnashing your teeth over the fact we already have --incognito? Same if we ever add any other useful disposition and want to support it. So this ensures we won't ever need to add more options. PK -- 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: Cannot find -lffmpegasm
Hi Albert, On Dec 15, 4:47 am, Albert J. Wong (王重傑) ajw...@chromium.org wrote: There have been some changes to the ffmpeg.gyp file recently. Dominic makes a good point that the GYP_DEFINES will make a large difference. Thiago, what GYP_DEFINES do you have set? The output of '$ echo $GYP_DEFINES' returned nothing here. Note that ffmpeg_asm is not a build dependency. It's a target in the ffmpeg.gyp file that must somehow be getting excluded in your build. -- 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 thes...@chromium.org 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 s...@chromium.org 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 thes...@chromium.org 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 s...@google.com 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 thes...@chromium.org 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 jam...@chromium.org
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
[chromium-dev] Re: Cannot find -lffmpegasm
I really don't know what was the problem exactly. After running build/install-build-deps.sh is that the problem started, so my guess is that some incompatible changes appeared because of that. So what I did was to download binutils-2.20.tar.gz, build and install it from sources. After doing that I was able to compile and link the dependencies again. So I'm thinking that the version of gold installed by install-build-deps would be the root of the problem. Now using this version: GNU ld (GNU Binutils) 2.20 is working fine *_again_* :) Sorry for all the noise, and thanks all for the answers :) -- 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] Re: [chromium-reviews] Add the cmdline -open-in-new-window switch
On Tue, Dec 15, 2009 at 4:45 PM, Evan Stade est...@chromium.org wrote: To put it a different way, the cost of supporting these now is basically indistinguishable from the cost of just adding --new-window. in terms of code, I don't think that's true. The current patch is extremely light weight. And the new patch would be equally light weight. We're never going to remove them, so there won't be any maintenance burden. But if we implement --new-window and decide we need to support one of these, we have to add a new option. Are you gnashing your teeth over the fact we already have --incognito? Yeah, I think it was shortsighted. Whatever. I don't care enough about this to argue any longer. Do whatever you want with the patch. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] The plan for upstreaming all of our layout tests infrastructure
Hi all, A number of us have drawn up a plan for getting the rest of our layout tests infrastructure upstreamed to webkit.org. You can read about it here: http://www.chromium.org/developers/design-documents/upstreaminglayouttests In addition to making us resemble other webkit ports by doing this (and definitely easing both webkit gardening and our ability to keep our webkit port from breaking), we also hope to bring added features to the webkit community. We're tentatively hoping to get this all done by the end of Q1 2010. Comments to me, Eric Seidel, Dimitry Glazkov, or the list :) -- Dirk -- 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] The plan for upstreaming all of our layout tests infrastructure
(3) forks run_webkit_tests.py upstream. (4) Make it possible to run the tests with TestShell while run_webkit_tests.py is upstream. (5) Change the chromium bots to use the upstream run_webkit_tests.py That all seems fine. But then we have to leave the forked copy in there until the last step (13) is done of making the other tools use the upstream copy. We should minimize as much as possible, the amount of time that we have these scripts forked. Can we move (13) to be (6)? Then we can delete the downstream run_webkit_tests.py. On Tue, Dec 15, 2009 at 5:18 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, A number of us have drawn up a plan for getting the rest of our layout tests infrastructure upstreamed to webkit.org. You can read about it here: http://www.chromium.org/developers/design-documents/upstreaminglayouttests In addition to making us resemble other webkit ports by doing this (and definitely easing both webkit gardening and our ability to keep our webkit port from breaking), we also hope to bring added features to the webkit community. We're tentatively hoping to get this all done by the end of Q1 2010. Comments to me, Eric Seidel, Dimitry Glazkov, or the list :) -- Dirk -- 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 thes...@chromium.org 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 cmas...@google.com 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 thes...@chromium.org 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 thes...@chromium.org 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] The plan for upstreaming all of our layout tests infrastructure
Right. I didn't actually mean to imply that the tasks had to run in the order specified. I've added a note to that effect, but if I find a few minutes I'll add a proper GANTT chart ;) -- Dirk On Tue, Dec 15, 2009 at 5:29 PM, Ojan Vafai o...@google.com wrote: (3) forks run_webkit_tests.py upstream. (4) Make it possible to run the tests with TestShell while run_webkit_tests.py is upstream. (5) Change the chromium bots to use the upstream run_webkit_tests.py That all seems fine. But then we have to leave the forked copy in there until the last step (13) is done of making the other tools use the upstream copy. We should minimize as much as possible, the amount of time that we have these scripts forked. Can we move (13) to be (6)? Then we can delete the downstream run_webkit_tests.py. On Tue, Dec 15, 2009 at 5:18 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, A number of us have drawn up a plan for getting the rest of our layout tests infrastructure upstreamed to webkit.org. You can read about it here: http://www.chromium.org/developers/design-documents/upstreaminglayouttests In addition to making us resemble other webkit ports by doing this (and definitely easing both webkit gardening and our ability to keep our webkit port from breaking), we also hope to bring added features to the webkit community. We're tentatively hoping to get this all done by the end of Q1 2010. Comments to me, Eric Seidel, Dimitry Glazkov, or the list :) -- Dirk -- 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
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 thes...@chromium.org 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 cmas...@google.com 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 thes...@chromium.org 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 thes...@chromium.org 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
