[chromium-dev] Re: Flakiness. Please help.
Maybe this is a stupid question, but where can I find test-expectations.txt? I looked in the tree and didn't see it. -Paul Wicks On Wed, Aug 5, 2009 at 11:12 PM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidel esei...@chromium.org wrote: Do we have a list of flakey tests? I feel like we used to have one... Every test in test-expectations.txt marked PASS FAIL or PASS FAIL CRASH or some similar set of multiple expectations is flaky, or at least thought to be so. 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: Flakiness. Please help.
src/webkit/tools/data/layout_tests btw, run_layout_tests.* can be used to run stuff (and lint the exceptions file) On Wed, Aug 5, 2009 at 11:26 PM, Paul Wicks pwick...@gmail.com wrote: Maybe this is a stupid question, but where can I find test-expectations.txt? I looked in the tree and didn't see it. -Paul Wicks On Wed, Aug 5, 2009 at 11:12 PM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidel esei...@chromium.org wrote: Do we have a list of flakey tests? I feel like we used to have one... Every test in test-expectations.txt marked PASS FAIL or PASS FAIL CRASH or some similar set of multiple expectations is flaky, or at least thought to be so. 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: gcl change that you should be aware of
Yay! Thanks for optimizing this. Adam On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForgelafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Flakiness. Please help.
Oops...I failedit's actually src/webkit/tools/layout_tests Also the file uses an underscore, not a dash...it's test_expectations.txt J On Wed, Aug 5, 2009 at 11:28 PM, Jeremy Orlow jor...@chromium.org wrote: src/webkit/tools/data/layout_tests btw, run_layout_tests.* can be used to run stuff (and lint the exceptions file) On Wed, Aug 5, 2009 at 11:26 PM, Paul Wicks pwick...@gmail.com wrote: Maybe this is a stupid question, but where can I find test-expectations.txt? I looked in the tree and didn't see it. -Paul Wicks On Wed, Aug 5, 2009 at 11:12 PM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidel esei...@chromium.org wrote: Do we have a list of flakey tests? I feel like we used to have one... Every test in test-expectations.txt marked PASS FAIL or PASS FAIL CRASH or some similar set of multiple expectations is flaky, or at least thought to be so. 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: Urgent, a very evil site i think which does evil things (no joke)
Jeremy, i can't see how it will make things any worse to punch these holes you still fork flash in its own process like you do now only you sandbox it how is it any worse ? this is just an observation that if i would write malware (which of course, i would never) i would just use flash plugins exploits to be cross browser compatible and this renders the sandbox nearly useless for future attacks what decent malware writer would bother with webkit explits ? none! besides, if you look at the help forum of chrome, you will see some people are starting to catch malware like this which is btw, how i got this evil site's URL i would never click on my own such a foul looking site as for the auto updating issue, i suggested a solution in one of my prev posts and i am sure you can have a word with adobe for this in a sense chrome makes it easier to infect itself(!) as you run plugins in the medium integrity level (Vista and above) and you normally install chrome in the local user account, so no UAC prompt will help the user if some delicate file or DLL is written to chrome folder, and then it will do something never intended also, one more note, flash is special enough that if you would hard code the solution to it, you would anyays solve most infections problems in the world, and maybe even cancer... who knows ? and regarding what CPU said (and ignoring the auto-update) it seems that flash does work flawlessly using your '--safe-plugins' switch, and doing this on that site does stop the attack (tbh, maybe the attack was stopped because the sun's java died in the sandbox, but Ian said it was a flash based attack) --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Wed, Aug 5, 2009 at 11:52 PM, yoav zilberberg yoav.zilberb...@gmail.comwrote: Jeremy, i can't see how it will make things any worse to punch these holes I never said it's worse...just that you couldn't make it airtight. Patches welcome. :-) you still fork flash in its own process like you do now only you sandbox it how is it any worse ? this is just an observation that if i would write malware (which of course, i would never) i would just use flash plugins exploits to be cross browser compatible and this renders the sandbox nearly useless for future attacks what decent malware writer would bother with webkit explits ? none! besides, if you look at the help forum of chrome, you will see some people are starting to catch malware like this which is btw, how i got this evil site's URL i would never click on my own such a foul looking site as for the auto updating issue, i suggested a solution in one of my prev posts and i am sure you can have a word with adobe for this in a sense chrome makes it easier to infect itself(!) as you run plugins in the medium integrity level (Vista and above) and you normally install chrome in the local user account, so no UAC prompt will help the user if some delicate file or DLL is written to chrome folder, and then it will do something never intended also, one more note, flash is special enough that if you would hard code the solution to it, you would anyays solve most infections problems in the world, and maybe even cancer... who knows ? and regarding what CPU said (and ignoring the auto-update) it seems that flash does work flawlessly using your '--safe-plugins' switch, and doing this on that site does stop the attack (tbh, maybe the attack was stopped because the sun's java died in the sandbox, but Ian said it was a flash based attack) --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Aug 5, 2009, at 11:52 PM, yoav zilberberg wrote: Jeremy, i can't see how it will make things any worse to punch these holes you still fork flash in its own process like you do now only you sandbox it how is it any worse ? Please trust authoritative folks like Carlos when they tell you that if sandboxing Flash were something that could be done reliably, even with high effort, it would have been done by the Chrome team already. Features of Flash like direct network access through their own stack, direct access to GPU resources, access to the file system, and audio/ video input are incredibly hard to sort out from regular Flash usage. At a minimum, they'll require code changes to Flash to help browsers mediate the access to those resources in a sandboxed environment. The current NPAPI interface doesn't have those contracts in place, and so the assumptions have been fixed and code written right up to the limit of those assumptions. To see how it works for yourself, try the --safe-plugins flag and then see how well the Flash- using web at large works (and if/how things break). It's all tractable in time, and you're right that it's absolutely desirable to sandbox Flash, but doing it today will undoubtedly lead to a poor user experience. If you'd like this situation to improve, might I suggest you help out by striking up a conversation with Adobe on the topic? In my personal interactions with their folks, they've been cordial and reasonable, and I'm sure they'd like to hear from a customer who's interested in seeing a safer Flash. Regards this is just an observation that if i would write malware (which of course, i would never) i would just use flash plugins exploits to be cross browser compatible and this renders the sandbox nearly useless for future attacks what decent malware writer would bother with webkit explits ? none! besides, if you look at the help forum of chrome, you will see some people are starting to catch malware like this which is btw, how i got this evil site's URL i would never click on my own such a foul looking site as for the auto updating issue, i suggested a solution in one of my prev posts and i am sure you can have a word with adobe for this in a sense chrome makes it easier to infect itself(!) as you run plugins in the medium integrity level (Vista and above) and you normally install chrome in the local user account, so no UAC prompt will help the user if some delicate file or DLL is written to chrome folder, and then it will do something never intended also, one more note, flash is special enough that if you would hard code the solution to it, you would anyays solve most infections problems in the world, and maybe even cancer... who knows ? and regarding what CPU said (and ignoring the auto-update) it seems that flash does work flawlessly using your '--safe-plugins' switch, and doing this on that site does stop the attack (tbh, maybe the attack was stopped because the sun's java died in the sandbox, but Ian said it was a flash based attack) --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
Another vote against this change for similar reasons... On Thu, Aug 6, 2009 at 12:37 AM, Dirk Pranke dpra...@google.com wrote: I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
Perhaps a better default is to use this behavior when first creating a changelist and to use the old behavior when modifying a changelist. Adam On Thu, Aug 6, 2009 at 12:37 AM, Dirk Prankedpra...@google.com wrote: I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
Alex, your reply irritates me so much that i am willing to take my chancesand if anyone (from @chromium) finds my answer insulting e-mail me and i will remove myself forever from your lists, promise! what kind of an answer is that ? do you know how this attack was carried ? did you even read this thread before suggesting your comments ? even the start of your thread trust the force is so arrogant, and while i don't know who carlos is i would think that even carlos would know that if you intercepted file access you would have easily stopped this attack. jeremy was at least constructive, in suggesting i would patch it myself, but like i said, i don't know NPAPI nor do i know flash for that matter but i do know windows, alex, and whatever flash does internally he cannot access the disk directly, right ? (of course not) so just that simple test would have been enough and again, if anyone(!) from chrome(!) finds my response offensive, reply here and i promise never to post here again with zero hard feelings nakro --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
Ian, well, i like your reply, so just tell me please for my own knowledge one thing is there ever a reason to allow flash (we are talking only flash here) to fork WinMail.exe for example ? i am a very light weight surfer, and i mostly read tech stuff, so my experience with flash is mostly youtube is this really something which any flash application does ? does flash really expect to have access to 'program files' ? if flash is expected to have access to it all, then you wouldn't have tried to sandbox it in the first place, right ? and btw, i read really a lot of the source code of chrome, and i still do, i even used your sandbox API to various tricks, and i even submitted patches and expect to do more in the future --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
No adam, i did not sumbit patches to the sandbox :) i just used its API's to forward calls from kernel32.dll to my own DLL's so i could inject code to VC.exe and force it to run in the idle priority class but i still don't get it if Flash expects to be able to SendMessage, then you cannot sandbox it anyways as there is no limit to what can be done and of course, i also look forward to HTML5 All i am saying is that one of the biggest selling points of chrome is that it is secure (no drive by malware anymore) and i was hoping from such a good produce as chrome to protect me there is simple statistics to be had here do most flash apps expect to the able to SendMessage ? if so, i admit, this is a hopeless case but if not, then you should have added an option in chrome to say 'sandbox flash by default' and then you could whitelist some sites you trust --~--~-~--~~~---~--~~ 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: Need some help with Grit
Well the grd file hasn't been changed, I'm using the 196 one (tried 197 as well). I figured that might be intended, but using reshacker I can see that IDR_FRAME is 10583 (by identifying the image I mean). This is also the case in the .rc file made manually for Chromium Theme Creator by U_I. (Which I'm trying to automate). Thanks for the info though. I'll see what I can sort out. On Aug 6, 1:42 am, Jói joi.sigurds...@gmail.com wrote: Hi Wa, GRIT generates ID numbers for all constants regardless of if elements or not, but skips output to the RC file for items that are in if elements that evaluate to false. This is done so that two different builds with different preprocessor defines (that cause different if sections to be included or not) get the same IDs for the same resources. This doesn't seem to be the same as when you guys build the .rc file though, as the correct ID for IDR_FRAME is 10583. Why do you think this is the correct ID for IDR_FRAME? GRIT generates IDs every time it is run, and they are internally consistent but may change between invocations if the .grd file has been changed. Cheers, Jói On Aug 6, 2:34 am, Wa sevencolored...@gmail.com wrote: I'm trying to use Grit to compile the theme resource headers for reference. But when I do so, it seems to be counting the includes under if expr=os == 'linux2' though it's not exporting them to the header. For example from compile app_resources.grd: #define IDR_MINIMIZE_H 10581 #define IDR_MINIMIZE_P 10582 #define IDR_FRAME 10595 #define IDR_FRAME_INACTIVE 10596 That's the output, which as you can see, the increment breaks between IDR_MINIMIZE_P and IDR_FRAME. Checking the -x verbose output, it is in fact enumerating the inputs under the linux check there, incrementing the ID value. This doesn't seem to be the same as when you guys build the .rc file though, as the correct ID for IDR_FRAME is 10583. Is there a command line argument to Grit to step over ifs that evaluate false that I'm missing here? I looked over the source for Grit and your build files as best I could without knowing Python and having never used VC++, but can't find anything related. If nothing else I guess I can just parse them out entirely in my bat..though I really would rather not. --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
On Thu, Aug 6, 2009 at 3:51 AM, Adam Barth aba...@chromium.org wrote: Perhaps a better default is to use this behavior when first creating a changelist and to use the old behavior when modifying a changelist. +1 TVL Adam On Thu, Aug 6, 2009 at 12:37 AM, Dirk Prankedpra...@google.com wrote: I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Flakiness. Please help.
On Wed, Aug 5, 2009 at 9:44 PM, Peter Kastingpkast...@google.com wrote: * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) I'm willing to be a valgrind contact. - Dan --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
whoa, please revert this change. if I have a big changelist, now every time I run gcl I have to expend effort to make sure no new files crept in. this will lead to more build failures as people check in other files accidently. On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
I've reverted the change, gcl will go back to normal in about 5-10 minutes. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Thu, Aug 6, 2009 at 8:13 AM, John Abd-El-Malek j...@chromium.org wrote: whoa, please revert this change. if I have a big changelist, now every time I run gcl I have to expend effort to make sure no new files crept in. this will lead to more build failures as people check in other files accidently. On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.comwrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
Dirk, Adium should automatically do it for your full IRC nick. You can also go into Adium -- Preferences -- Advanced -- Mention to have it watch for other things. Also, you can go into the Events preference and change the You are mentioned (Group Chat) notification options. - Robert On Aug 5, 10:25 pm, Dirk Pranke dpra...@google.com wrote: I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegel mac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegel emailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Strange periodic popup window on 3.0.196.0 on Linux?
Ever since updating to 3.0.196.0, I've seen a blank window pop up and go away periodically (once an hour or so?). Anyone else seen 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: [Chrome-team] Beware of any issues linking to trucountme.com
the new spam is by a user called lewiskevin64 http://code.google.com/u/lewiskevin64/updates spamming the url giga-tube.net which i am guessing is also devious On Aug 6, 7:40 am, Mohamed Mansour m...@chromium.org wrote: I was going to delete them when I saw them, but committers have no access to delete posts :) If only the issue tracker was open source, we could have helped them implement it ! -- Mohamed Mansour On Thu, Aug 6, 2009 at 12:19 AM, Ian Fette i...@chromium.org wrote: Sadly there's about 60 of these, still cleaning them up. AFAIK there's no way for me to ban the user :( (Also, queuing up 60 tabs reminds me that I would really love a tab overflow solution :) 2009/8/5 Anthony LaForge lafo...@google.com A friendly person appears to be spamming our issue tracker w/ a virus link. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
For Colloquy, enter your nick in Preferences Alerts Highlight words. You can also enter other things you might be interested in, such as red or sheriff or caja. - Pam On Wed, Aug 5, 2009 at 7:25 PM, Dirk Pranke dpra...@google.com wrote: I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegelmac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegelemailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
I've been using a local copy with this change (add all files to a new change, but not to an existing one) forever, but last I checked around, some people prefer the always copy-paste model. I'd be glad to check in my change if the consensus agrees. - Pam On Thu, Aug 6, 2009 at 12:51 AM, Adam Barth aba...@chromium.org wrote: Perhaps a better default is to use this behavior when first creating a changelist and to use the old behavior when modifying a changelist. Adam On Thu, Aug 6, 2009 at 12:37 AM, Dirk Prankedpra...@google.com wrote: I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Aug 6, 2009, at 1:43 AM, yoav zilberberg wrote: No adam, i did not sumbit patches to the sandbox :) i just used its API's to forward calls from kernel32.dll to my own DLL's so i could inject code to VC.exe and force it to run in the idle priority class but i still don't get it if Flash expects to be able to SendMessage, then you cannot sandbox it anyways as there is no limit to what can be done and of course, i also look forward to HTML5 All i am saying is that one of the biggest selling points of chrome is that it is secure (no drive by malware anymore) --disable-plugins or --safe-plugins will get you there. Just don't expect full web compatibility. What you're expressing is the very real tension between what users currently expect and the security implications of how those expectations are realized today. Browser vendors are caught in the middle -- this is by way of explanation, not excuse. I think everyone working on Chrome wishes Flash were sandbox- able and are frustrated with the current situation. If you've got ideas for how to make --safe-plugins work better with real-world Flash, I suspect those ideas would be well received. Accusing the team of gross negligence probably won't help you get patches landed any faster, though. and i was hoping from such a good produce as chrome to protect me there is simple statistics to be had here do most flash apps expect to the able to SendMessage ? if so, i admit, this is a hopeless case but if not, then you should have added an option in chrome to say 'sandbox flash by default' and then you could whitelist some sites you trust I think to Adam's point, we'd like a relatively complete sandbox (i.e., one that run in a pre-defined policy and in which one failure won't lead to many other kinds of breaks). Take the example of 3D hardware access: drivers run in the kernel. Any problem there will invalidate whatever work is done at, say, the filesystem level. It's likely true that most of the world's Flash doesn't need to do insecure things. Figuring out a sane way to either tell Flash no in a way that doesn't out-and-out crash movies or in some other way give users control seems an area that could use more exploration if you've got the time. Regards --~--~-~--~~~---~--~~ 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: Strange periodic popup window on 3.0.196.0 on Linux?
I haven't. What sort of window? (Does it have a title bar? Toolbar?) Can you get a screenshot? On Thu, Aug 6, 2009 at 8:37 AM, Dan Kegeld...@kegel.com wrote: Ever since updating to 3.0.196.0, I've seen a blank window pop up and go away periodically (once an hour or so?). Anyone else seen 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: Urgent, a very evil site i think which does evil things (no joke)
Alex, let me get it, are you part of the chrome team ? i don't recall accusing anyone from chromebut i do recall not liking your reply, so just let me know if you are part of the devs of chrome please i will be honest, if you are, then i think it is time for me to move to a different browser, if you are not then don't decide if i accuse the chrome team or not, let them tell me, and like i said i would remove myself in a second and with no hard feelings --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
I don't really understand why you find Alex's message so frustrating. We'd love to make --safe-plugins the default. One road to getting there is having more people use the option and find the incompatibilities. We'd certainly welcome patches that improve it's compatibility. If we can make it work well enough, then we can turn it on by default and everyone wins. Adam On Thu, Aug 6, 2009 at 9:46 AM, yoav zilberbergyoav.zilberb...@gmail.com wrote: Alex, let me get it, are you part of the chrome team ? i don't recall accusing anyone from chrome but i do recall not liking your reply, so just let me know if you are part of the devs of chrome please i will be honest, if you are, then i think it is time for me to move to a different browser, if you are not then don't decide if i accuse the chrome team or not, let them tell me, and like i said i would remove myself in a second and with no hard feelings --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Git usage in chromium
Hi, I read this about git usage in chromium: http://code.google.com/p/chromium/wiki/UsingGit It looks like it is using a combination of git and svn for version control. Can you please tell me what are using git and what are using svn? My guess is third-party/webkit will be using svn and everything else is git? Is that correct? 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-dev] Re: Git usage in chromium
On Thu, Aug 6, 2009 at 9:55 AM, n179911 n179...@gmail.com wrote: Hi, I read this about git usage in chromium: http://code.google.com/p/chromium/wiki/UsingGit It looks like it is using a combination of git and svn for version control. Can you please tell me what are using git and what are using svn? My guess is third-party/webkit will be using svn and everything else is git? Is that correct? Both Chromium and WebKit use svn, but you can wrap git on top of that if you want by following those instructions. - Pam 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-dev] Re: Git usage in chromium
On Thu, Aug 6, 2009 at 9:55 AM, n179911n179...@gmail.com wrote: I read this about git usage in chromium: http://code.google.com/p/chromium/wiki/UsingGit It looks like it is using a combination of git and svn for version control. Can you please tell me what are using git and what are using svn? My guess is third-party/webkit will be using svn and everything else is git? Is that correct? After following the instructions in that document trunk/src is git and everything else (pulled in via DEPS, including webkit and also ICU, skia, etc.) is via svn. You are of course welcome to check out yourself (via git-svn) in any combination you see fit, but it can be fiddly to get right. --~--~-~--~~~---~--~~ 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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
One caveat for Colloquy is that the default highlight for someone sent you a PM is bounce once rather than bounce lots of times, so it's really easy to miss PMs if you don't change the default. -atw On Thu, Aug 6, 2009 at 8:57 AM, Pam Greene p...@chromium.org wrote: For Colloquy, enter your nick in Preferences Alerts Highlight words. You can also enter other things you might be interested in, such as red or sheriff or caja. - Pam On Wed, Aug 5, 2009 at 7:25 PM, Dirk Pranke dpra...@google.com wrote: I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegelmac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegelemailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
Yoav everyone on this thread is a Chromium developer and almost everyone posting in this thread (not me) are some of the top developers working on Chrome and many of them have spent a good deal of time working on sandbox related issues. All of us have a healthy disrespect for the impossible and would definitely like to see plugin's sandboxed by default, but it's a very difficult problem. We're working hard on many fronts like making more stuff possible without plugins (HTML 5), new technologies (NaCl), etc to change the status quo. I know it doesn't mean much to you, but I've met and/or worked with many of the developers that reached the conclusion that sandboxing plugins isn't practical (at least by default) and I can say that they're not only some of the smartest developers I've ever met, but that the decision was also painful to them. If you wanted to help, patches would be great. But I think it'd also be helpful if you turned it on and filed bugs when you hit compat issues. I'm not sure there's much else to say on the topic... J On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth aba...@chromium.org wrote: I don't really understand why you find Alex's message so frustrating. We'd love to make --safe-plugins the default. One road to getting there is having more people use the option and find the incompatibilities. We'd certainly welcome patches that improve it's compatibility. If we can make it work well enough, then we can turn it on by default and everyone wins. Adam On Thu, Aug 6, 2009 at 9:46 AM, yoav zilberbergyoav.zilberb...@gmail.com wrote: Alex, let me get it, are you part of the chrome team ? i don't recall accusing anyone from chrome but i do recall not liking your reply, so just let me know if you are part of the devs of chrome please i will be honest, if you are, then i think it is time for me to move to a different browser, if you are not then don't decide if i accuse the chrome team or not, let them tell me, and like i said i would remove myself in a second and with no hard feelings --~--~-~--~~~---~--~~ 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: Git usage in chromium
On Thu, Aug 6, 2009 at 12:59 PM, Evan Martin e...@chromium.org wrote: On Thu, Aug 6, 2009 at 9:55 AM, n179911n179...@gmail.com wrote: I read this about git usage in chromium: http://code.google.com/p/chromium/wiki/UsingGit After following the instructions in that document trunk/src is git and everything else (pulled in via DEPS, including webkit and also ICU, skia, etc.) is via svn. I've been wondering about this. What would it take to modify our git checkout process to pull third_party/WebKit via git as well? Would it mostly work to just exclude third_party/WebKit via DEPS, create it via a git checkout and then write a script that wraps gclient sync to also git pull/rebase third_party/WebKit? Is there a better way? I'd like to have a git checkout of tip of tree trunk/src and tip of tree WebKit so I can have one tree for developing both Chrome and WebKit. Ojan --~--~-~--~~~---~--~~ 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: Flakiness. Please help.
One easy suggestion in helping catch bugs is to run Chrome with --enable-dcheck . This'll prompt if you hit a DCHECK in release builds and hopefully help isolate crashes before the fact. -Scott On Wed, Aug 5, 2009 at 9:44 PM, Peter Kastingpkast...@google.com wrote: THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these P1? Because until we prove they can't affect Chrome itself, they potentially can, and Chrome crashes are always P1. They affect stability and security both. (5) If you have commit rights, go ahead and TBR test-expectations changes you're confident of. I even suggest using --force if the tree is closed. Updating expectations is like fixing bustage, it helps the tree go green faster and thus is almost always desirable. If you don't have commit rights, send your review to the WebKit sheriff. *** Your reward for reading this far: * At the end of the quarter, I will nominate for a peer bonus every Googler who puts something meaningful about flakiness/test failures/the other stuff above on their OKRs, accomplishes it, and sends me a note pointing that out. * At the end of the quarter, I will nominate for commit access every non-Googler who sends me a pointer to ten
[chromium-dev] Re: Urgent, a very evil site i think which does evil things (no joke)
Hi, On Thu, Aug 6, 2009 at 6:08 PM, Jeremy Orlow jor...@chromium.org wrote: Yoav everyone on this thread is a Chromium developer and almost everyone posting in this thread (not me) are some of the top developers working on Chrome and many of them have spent a good deal of time working on sandbox related issues. All of us have a healthy disrespect for the impossible and would definitely like to see plugin's sandboxed by default, but it's a very difficult problem. We're working hard on many fronts like making more stuff possible without plugins (HTML 5), new technologies (NaCl), etc to change the status quo. Sorry to intrude, but can you explain what NaCl are you talking ? Is it this one: http://nacl.cr.yp.to/ And what kind of work/use is being thought for NaCl + chromium. I'm asking this because I've looked at NaCl recently and seems very interesting.. kind regards, I know it doesn't mean much to you, but I've met and/or worked with many of the developers that reached the conclusion that sandboxing plugins isn't practical (at least by default) and I can say that they're not only some of the smartest developers I've ever met, but that the decision was also painful to them. If you wanted to help, patches would be great. But I think it'd also be helpful if you turned it on and filed bugs when you hit compat issues. I'm not sure there's much else to say on the topic... J On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth aba...@chromium.org wrote: I don't really understand why you find Alex's message so frustrating. We'd love to make --safe-plugins the default. One road to getting there is having more people use the option and find the incompatibilities. We'd certainly welcome patches that improve it's compatibility. If we can make it work well enough, then we can turn it on by default and everyone wins. Adam On Thu, Aug 6, 2009 at 9:46 AM, yoav zilberbergyoav.zilberb...@gmail.com wrote: Alex, let me get it, are you part of the chrome team ? i don't recall accusing anyone from chrome but i do recall not liking your reply, so just let me know if you are part of the devs of chrome please i will be honest, if you are, then i think it is time for me to move to a different browser, if you are not then don't decide if i accuse the chrome team or not, let them tell me, and like i said i would remove myself in a second and with no hard feelings -- Miguel Sousa Filipe --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Thu, Aug 6, 2009 at 10:16 AM, Miguel F Mascarenhas Sousa Filipe miguel.fil...@gmail.com wrote: Hi, On Thu, Aug 6, 2009 at 6:08 PM, Jeremy Orlow jor...@chromium.org wrote: Yoav everyone on this thread is a Chromium developer and almost everyone posting in this thread (not me) are some of the top developers working on Chrome and many of them have spent a good deal of time working on sandbox related issues. All of us have a healthy disrespect for the impossible and would definitely like to see plugin's sandboxed by default, but it's a very difficult problem. We're working hard on many fronts like making more stuff possible without plugins (HTML 5), new technologies (NaCl), etc to change the status quo. Sorry to intrude, but can you explain what NaCl are you talking ? Is it this one: http://nacl.cr.yp.to/ I was talking about this one: http://code.google.com/p/nativeclient/ http://nacl.cr.yp.to/ And what kind of work/use is being thought for NaCl + chromium. I'm asking this because I've looked at NaCl recently and seems very interesting.. kind regards, I know it doesn't mean much to you, but I've met and/or worked with many of the developers that reached the conclusion that sandboxing plugins isn't practical (at least by default) and I can say that they're not only some of the smartest developers I've ever met, but that the decision was also painful to them. If you wanted to help, patches would be great. But I think it'd also be helpful if you turned it on and filed bugs when you hit compat issues. I'm not sure there's much else to say on the topic... J On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth aba...@chromium.org wrote: I don't really understand why you find Alex's message so frustrating. We'd love to make --safe-plugins the default. One road to getting there is having more people use the option and find the incompatibilities. We'd certainly welcome patches that improve it's compatibility. If we can make it work well enough, then we can turn it on by default and everyone wins. Adam On Thu, Aug 6, 2009 at 9:46 AM, yoav zilberbergyoav.zilberb...@gmail.com wrote: Alex, let me get it, are you part of the chrome team ? i don't recall accusing anyone from chrome but i do recall not liking your reply, so just let me know if you are part of the devs of chrome please i will be honest, if you are, then i think it is time for me to move to a different browser, if you are not then don't decide if i accuse the chrome team or not, let them tell me, and like i said i would remove myself in a second and with no hard feelings -- Miguel Sousa Filipe --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Thu, Aug 6, 2009 at 1:16 PM, Miguel F Mascarenhas Sousa Filipe miguel.fil...@gmail.com wrote: Hi, On Thu, Aug 6, 2009 at 6:08 PM, Jeremy Orlow jor...@chromium.org wrote: Yoav everyone on this thread is a Chromium developer and almost everyone posting in this thread (not me) are some of the top developers working on Chrome and many of them have spent a good deal of time working on sandbox related issues. All of us have a healthy disrespect for the impossible and would definitely like to see plugin's sandboxed by default, but it's a very difficult problem. We're working hard on many fronts like making more stuff possible without plugins (HTML 5), new technologies (NaCl), etc to change the status quo. Sorry to intrude, but can you explain what NaCl are you talking ? Is it this one: http://nacl.cr.yp.to/ And what kind of work/use is being thought for NaCl + chromium. I'm asking this because I've looked at NaCl recently and seems very interesting.. Nope, this one: http://code.google.com/p/nativeclient/ TVL kind regards, I know it doesn't mean much to you, but I've met and/or worked with many of the developers that reached the conclusion that sandboxing plugins isn't practical (at least by default) and I can say that they're not only some of the smartest developers I've ever met, but that the decision was also painful to them. If you wanted to help, patches would be great. But I think it'd also be helpful if you turned it on and filed bugs when you hit compat issues. I'm not sure there's much else to say on the topic... J On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth aba...@chromium.org wrote: I don't really understand why you find Alex's message so frustrating. We'd love to make --safe-plugins the default. One road to getting there is having more people use the option and find the incompatibilities. We'd certainly welcome patches that improve it's compatibility. If we can make it work well enough, then we can turn it on by default and everyone wins. Adam On Thu, Aug 6, 2009 at 9:46 AM, yoav zilberbergyoav.zilberb...@gmail.com wrote: Alex, let me get it, are you part of the chrome team ? i don't recall accusing anyone from chrome but i do recall not liking your reply, so just let me know if you are part of the devs of chrome please i will be honest, if you are, then i think it is time for me to move to a different browser, if you are not then don't decide if i accuse the chrome team or not, let them tell me, and like i said i would remove myself in a second and with no hard feelings -- Miguel Sousa Filipe --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] new Linux custom frame
I just saw the new Linux custom frame buttons when compiled today from trunk. With the new increased padding it looks really well. I like it! --~--~-~--~~~---~--~~ 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: Git usage in chromium
On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafaio...@chromium.org wrote: After following the instructions in that document trunk/src is git and everything else (pulled in via DEPS, including webkit and also ICU, skia, etc.) is via svn. I've been wondering about this. What would it take to modify our git checkout process to pull third_party/WebKit via git as well? Would it mostly work to just exclude third_party/WebKit via DEPS, create it via a git checkout and then write a script that wraps gclient sync to also git pull/rebase third_party/WebKit? Is there a better way? I had an old version of gclient that did this. The problem you run into is that there are more possible tree states of git than in svn so it's hard to map across. Say DEPS says web...@revision A, and you have webkit at revision A~10. gclient sync should probably fast-forward your checkout. Say DEPS says web...@revision A, and then you've checked out trunk and have local changes. gclient sync should probably... do nothing? But then how do we tell DEPS checked them out at A~10 before, so we should fast forward to A from they checked out A~10 because that was trunk at the time, so we should fast forward to trunk? Etc. It's basically some UI questions that I haven't had the time to worry about 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: new Linux custom frame
Yes, it's too bad that our dev channel release got bad padding on the buttons. I've seen a few comments online to the effect of this is so ugly how can I turn it off. I fear people will turn it off then and not discover it has improved since. I think we're gonna tweak them one more time before we stop touching them, though. On Thu, Aug 6, 2009 at 10:29 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I just saw the new Linux custom frame buttons when compiled today from trunk. With the new increased padding it looks really well. I like it! --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
On Thu, Aug 6, 2009 at 6:12 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Thu, Aug 6, 2009 at 3:51 AM, Adam Barth aba...@chromium.org wrote: Perhaps a better default is to use this behavior when first creating a changelist and to use the old behavior when modifying a changelist. +1 TVL I agree. This sounds like a nice compromise. -Darin Adam On Thu, Aug 6, 2009 at 12:37 AM, Dirk Prankedpra...@google.com wrote: I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Git usage in chromium
On Thu, Aug 6, 2009 at 10:36 AM, Evan Martin e...@chromium.org wrote: On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafaio...@chromium.org wrote: After following the instructions in that document trunk/src is git and everything else (pulled in via DEPS, including webkit and also ICU, skia, etc.) is via svn. I've been wondering about this. What would it take to modify our git checkout process to pull third_party/WebKit via git as well? Would it mostly work to just exclude third_party/WebKit via DEPS, create it via a git checkout and then write a script that wraps gclient sync to also git pull/rebase third_party/WebKit? Is there a better way? I had an old version of gclient that did this. The problem you run into is that there are more possible tree states of git than in svn so it's hard to map across. Say DEPS says web...@revision A, and you have webkit at revision A~10. gclient sync should probably fast-forward your checkout. Say DEPS says web...@revision A, and then you've checked out trunk and have local changes. gclient sync should probably... do nothing? But then how do we tell DEPS checked them out at A~10 before, so we should fast forward to A from they checked out A~10 because that was trunk at the time, so we should fast forward to trunk? Etc. It's basically some UI questions that I haven't had the time to worry about yet. Currently, I just manage the webkit changes by hand rather than letting gclient do it. I have a git checkout of webkit symlinked (mounted in XP since symlinks don't work right until vista) on top of third_party/WebKit. You'll need to add the following into the custom_deps of your .gclient: src/third_party/WebKit/JavaScriptCore: None, src/third_party/WebKit/WebCore: None, src/third_party/WebKit/WebKitLibraries: None, src/third_party/WebKit/LayoutTests: None, Then after a gclient sync, to get a branch of webkit at the right revision + all the build files regenerated, I do some variant of ajwong$ i=`head ~/src/git-chrome/src/DEPS | grep webkit_revision | cut -d '' -f4`; git checkout -b $i `git svn find-rev r$i` ajwong$ i gclient runhooks --force Any of the merges/cherry-pick of current work off the webkit tree, I do by hand. It's been working pretty well for me. -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] Re: The program 'chrome' received an X Window System error
On Wed, Aug 5, 2009 at 5:51 PM, Albert Bachandalbe...@google.com wrote: Thanks, that was useful. The IPC messages right before the crash are: ipc 1855.ba2d400.22596386 3 ViewHostMsg_PaintRect (171016409, (0, 0, 1, 1), (1, 1), , 1) ipc 1855.ba2d400.22596386 3 ViewHostMsg_RenderViewReady ipc 1855.ba2d400.22596386 3 ViewHostMsg_DidStartLoading ipc 1855.ba2d400.22596386 3 ViewHostMsg_DidStartProvisionalLoadForFrame true, chrome://about/linux-splash Digging through the code it looks like the problem has to do with drawing the TabContentsViewGtk widgets. As far as I can tell, those widgets are not children of the GtkWindow widget which I'm drawing on the remote X screen. And since TabContentsViewGtk creates a custom widget (GtkFloatingContainer) that doesn't define a set_screen() function, I can't move that widget to the remote X screen. There's a few widgets that support being moved to a remote X screen (GtkWindow, GtkMenu, GtkInvisible, etc.) maybe the solution is to make GtkFloatingContainer support that as well. I'll keep digging... Only top-level widgets should need a set_screen function, as otherwise (as I understand it) the screen is inherited from the parent widget. That's why for example GtkMenu has it (menus are top-level windows, not children of the thing that popped it up). As we discussed earlier, if I had to guess I'd say it's related to the way we handle backing stores. Generally we don't do any tricks with X so it all should Just Work but the way renderers paint is very complicated. You could try stubbing out some of the functions in backing_store_x.cc to see if you can make it neither crash nor draw anything, then go from there. I see a call to a function x11_util::GetXDisplay() that seems like a good one to set a breakpoint on so you can trace it backwards up to its caller, as that kind of call is surely the source of these sorts of errors. --~--~-~--~~~---~--~~ 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: Git usage in chromium
On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafai o...@chromium.org wrote: I've been wondering about this. What would it take to modify our git checkout process to pull third_party/WebKit via git as well? Would it mostly work to just exclude third_party/WebKit via DEPS, create it via a git checkout and then write a script that wraps gclient sync to also git pull/rebase third_party/WebKit? Is there a better way? I'd like to have a git checkout of tip of tree trunk/src and tip of tree WebKit so I can have one tree for developing both Chrome and WebKit. You can do this via svn; abarth started a thread about it several weeks ago with a link to an instructions wiki page, and I have been fixing bugs on the WebKit side to make it viable for development. Dunno how to do it with git though, sorry. 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: gcl change that you should be aware of
On Thu, Aug 6, 2009 at 8:59 AM, Pam Greene p...@chromium.org wrote: I've been using a local copy with this change (add all files to a new change, but not to an existing one) forever, but last I checked around, some people prefer the always copy-paste model. I'd be glad to check in my change if the consensus agrees. Yes, please do this. laforge's behavior is awesome as long as the bug of subsequent modifications doesn't affect it. 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] crashing on startup
A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. --~--~-~--~~~---~--~~ 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: Flakiness. Please help.
To clarify, doesn't --enable-dcheck only work on chromium release builds you built yourself and not official builds of Google Chrome? On Thu, Aug 6, 2009 at 10:15 AM, Scott Violet s...@chromium.org wrote: One easy suggestion in helping catch bugs is to run Chrome with --enable-dcheck . This'll prompt if you hit a DCHECK in release builds and hopefully help isolate crashes before the fact. -Scott On Wed, Aug 5, 2009 at 9:44 PM, Peter Kastingpkast...@google.com wrote: THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these P1? Because until we prove they can't affect Chrome itself, they potentially can, and Chrome crashes are always P1. They affect stability and security both. (5) If you have commit rights, go ahead and TBR test-expectations changes you're confident of. I even suggest using --force if the tree is closed. Updating expectations is like fixing bustage, it helps the tree go green faster and thus is almost always desirable. If you don't have commit rights, send your review to the WebKit sheriff. *** Your reward for reading this far: * At the end of the quarter, I will
[chromium-dev] Re: Flakiness. Please help.
Not sure, perhaps Huan could answer that. That said, --enable-dcheck certainly works on the Chromium release builds from the buildbot: http://build.chromium.org/buildbot/continuous/LATEST/ . -Scott On Thu, Aug 6, 2009 at 12:59 PM, Antony Sargentasarg...@google.com wrote: To clarify, doesn't --enable-dcheck only work on chromium release builds you built yourself and not official builds of Google Chrome? On Thu, Aug 6, 2009 at 10:15 AM, Scott Violet s...@chromium.org wrote: One easy suggestion in helping catch bugs is to run Chrome with --enable-dcheck . This'll prompt if you hit a DCHECK in release builds and hopefully help isolate crashes before the fact. -Scott On Wed, Aug 5, 2009 at 9:44 PM, Peter Kastingpkast...@google.com wrote: THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these P1? Because until we prove they can't affect Chrome itself, they potentially can, and Chrome crashes are always P1. They affect stability and security both. (5) If you have commit rights, go ahead and TBR test-expectations changes you're confident of. I even suggest
[chromium-dev] Re: Running UI test in parallel (experimental)
This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 32, in
module
import google.httpd_utils
ImportError: No module named google.httpd_utils
hmmm, never needed PYTHONPATH set before. Can't this script set it itself?
Setting it manually will fail when I move depot locations etc.. But
anyways, I set it and then
a:\chrome2\src\chromeset PYTHONPATH=a:\chrome\src\tools\python
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 274, in
module
result = main(options, args)
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 155, in main
sys.path.insert(0, _BuildbotScriptPath('slave'))
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 84, in
_BuildbotScriptPath
'scripts', sub_dir)
File a:\chrome\src\tools\python\google\path_utils.py, line 72, in
FindUpward
parent = FindUpwardParent(start_dir, *desired_list)
File a:\chrome\src\tools\python\google\path_utils.py, line 55, in
FindUpwardParent
(desired_path, start_dir))
google.path_utils.PathNotFound: Unable to find tools\buildbot\scripts\slave
above A:\chrome2\src\chrome\tools\test
tools\buildbot isn't in the public tree I think, since I don't find it
here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/. So
external contributors can't use this? Also, why should this script depend
on the buildbot scripts? I don't have them so I can't try this out.
Can't we just have a minimal python script that runs ui_tests in parallel?
On Wed, Jul 29, 2009 at 3:28 PM, Huan Ren hu...@google.com wrote:
I just checked in a change to run ui_tests in parallel based on
sharding mechanism provided by GTest. Each ui_tests instance has its
own user data dir, and the number of ui_tests instances is
NUMBER_OF_PROCESSORS. I have updated
src/chrome/tools/test/smoketests.py so you can run it through command
line:
python.exe smoketests.py --tests=ui [--verbose]
Running ui_tests.exe directly is still the old behavior of
sequentially running. On my 4 core machine, the running time has been
reduced by half, from 832 secs to 443 secs. But I need to make sure
all tests can run reliably in this parallel fashion. So if you try it
out, I will be interested to know how fast the performance is improved
and what additional tests are failing.
Huan
P.S. this change is for Windows platform as I think Linux/Mac is
already using GTest sharding.
--~--~-~--~~~---~--~~
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: Flakiness. Please help.
On Thu, Aug 6, 2009 at 1:05 PM, Scott Violet s...@chromium.org wrote: Not sure, perhaps Huan could answer that. That said, --enable-dcheck certainly works on the Chromium release builds from the buildbot: http://build.chromium.org/buildbot/continuous/LATEST/ . Yes, --enable-dcheck is supposed to be disabled in Google Chrome build. Nicolas -Scott On Thu, Aug 6, 2009 at 12:59 PM, Antony Sargentasarg...@google.com wrote: To clarify, doesn't --enable-dcheck only work on chromium release builds you built yourself and not official builds of Google Chrome? On Thu, Aug 6, 2009 at 10:15 AM, Scott Violet s...@chromium.org wrote: One easy suggestion in helping catch bugs is to run Chrome with --enable-dcheck . This'll prompt if you hit a DCHECK in release builds and hopefully help isolate crashes before the fact. -Scott On Wed, Aug 5, 2009 at 9:44 PM, Peter Kastingpkast...@google.com wrote: THIS MAIL APPLIES TO YOU Flakiness is growing. Smash it before it gets bigger, and keep it smashed. *** The MOST IMPORTANT section in this gigantic mail: PLEASE spend some of every workday (or each week at least, if you can't spare time each day) looking at test failures, flakiness, valgrind/purify/coverity bugs, crashes, and/or memory bugs. Make it a goal to get an average of one line in the test-expectations file removed each day. If you're a Googler, put it on your OKRs (now, not sometime tomorrow). * DON'T wait for someone to assign bugs to you or ask for your help * DON'T wait for a team fixit week (those haven't worked) * DON'T wait for someone else to solve the problems * DON'T wait until after your current project is finished * DON'T wait until you have worked on WebKit HELP, even if it's just a little, even if it's not your core competence. We currently have hundreds upon hundreds of failing or flaky tests. We can dramatically reduce this quickly but ONLY IF YOU HELP. This is an investment not only in the quality of Chrome but in the team's ability to move fast, so help here doesn't just improve the quality of Chrome, but also the derivative of the quality :) (If you do not know how to do anything above and need handholding, e-mail me and I will help you. It's OK to be ignorant.) *** Next, how you should help keep the tree green at all times: * If you ever look at the buildbot and see red, and there's no explanation in the build status, ask what's going on on #chromium. Ping the sheriffs specifically (they're listed in the upper-right corner). If you do not get an answer about ownership within a few minutes, close the tree (if you have the rights to) or ask someone to close it. THE TREE SHOULD NOT BE OPEN WITH RED THAT NO ONE OWNS. Help the sheriffs out with this -- they can't watch every second. Closed trees suck; unowned bustage sucks more. Be hard-nosed. * Yes, even purify, valgrind, and reliability bot redness. If you can't figure out what to do with these, try pinging erikkay for purify issues and huanr for reliability issues. (Not sure who a good general valgrind contact is.) * If you ever look at the buildbot and see orange (unexpected pass), especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the calendar is linked from the top of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know whether it's world-readable). If he wasn't aware of it, agree between you on who will deal with it. Orange alone is not reason to close the tree, but it should NOT be ignored. * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE. If they're really fixed by someone's commit, that should be easy to determine. Otherwise, they're flaky, and we NEED to mark them as such, not just leave them. *** Finally, how to help if the LayoutTest bots are red or orange: (1) Try and determine if the test(s) are consistently passing/failing unexpectedly, or if they're flaky. Make sure you look at all the different bots to see which OSes are affected. (2) Update src/webkit/tools/layout_tests/test-expectations.txt. Look for the test(s) in question. Often, flaky tests will already be in there as failing or flaky for one OS, and need to have more added; or they will be marked flaky (FAIL PASS) and need CRASH added. If they're not there, add a line. (3) Ensure the test(s) have a bug on file. Note the bug on the expectation. (4) If any tests are crashing (flaky or not), they're high-priority and someone needs to triage them. Today, dglazkov was WebKit sheriff and was having me mark these bugs as P1, Mstone-3, owner:dglazkov. I'm not sure whether the Right Thing is to assign them to the WebKit sheriff or still to him (feel free to comment, dglazkov!). Why are these
[chromium-dev] Re: Running UI test in parallel (experimental)
On Thu, Aug 6, 2009 at 1:06 PM, John Abd-El-Malek j...@chromium.org wrote:
This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 32, in
module
import google.httpd_utils
ImportError: No module named google.httpd_utils
You get this error when you use a python that is different from the one in
src\third_party\python_24\python.exe
hmmm, never needed PYTHONPATH set before. Can't this script set it itself?
Setting it manually will fail when I move depot locations etc.. But
anyways, I set it and then
a:\chrome2\src\chromeset PYTHONPATH=a:\chrome\src\tools\python
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 274, in
module
result = main(options, args)
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 155, in main
sys.path.insert(0, _BuildbotScriptPath('slave'))
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 84, in
_BuildbotScriptPath
'scripts', sub_dir)
File a:\chrome\src\tools\python\google\path_utils.py, line 72, in
FindUpward
parent = FindUpwardParent(start_dir, *desired_list)
File a:\chrome\src\tools\python\google\path_utils.py, line 55, in
FindUpwardParent
(desired_path, start_dir))
google.path_utils.PathNotFound: Unable to find tools\buildbot\scripts\slave
above A:\chrome2\src\chrome\tools\test
tools\buildbot isn't in the public tree I think, since I don't find it
here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/. So
external contributors can't use this? Also, why should this script depend
on the buildbot scripts? I don't have them so I can't try this out.
http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/
Not sure why it needs it though.
Can't we just have a minimal python script that runs ui_tests in parallel?
Nicolas
On Wed, Jul 29, 2009 at 3:28 PM, Huan Ren hu...@google.com wrote:
I just checked in a change to run ui_tests in parallel based on
sharding mechanism provided by GTest. Each ui_tests instance has its
own user data dir, and the number of ui_tests instances is
NUMBER_OF_PROCESSORS. I have updated
src/chrome/tools/test/smoketests.py so you can run it through command
line:
python.exe smoketests.py --tests=ui [--verbose]
Running ui_tests.exe directly is still the old behavior of
sequentially running. On my 4 core machine, the running time has been
reduced by half, from 832 secs to 443 secs. But I need to make sure
all tests can run reliably in this parallel fashion. So if you try it
out, I will be interested to know how fast the performance is improved
and what additional tests are failing.
Huan
P.S. this change is for Windows platform as I think Linux/Mac is
already using GTest sharding.
--~--~-~--~~~---~--~~
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: Git usage in chromium
On Thu, Aug 6, 2009 at 1:36 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafaio...@chromium.org wrote: After following the instructions in that document trunk/src is git and everything else (pulled in via DEPS, including webkit and also ICU, skia, etc.) is via svn. I've been wondering about this. What would it take to modify our git checkout process to pull third_party/WebKit via git as well? Would it mostly work to just exclude third_party/WebKit via DEPS, create it via a git checkout and then write a script that wraps gclient sync to also git pull/rebase third_party/WebKit? Is there a better way? I had an old version of gclient that did this. The problem you run into is that there are more possible tree states of git than in svn so it's hard to map across. Say DEPS says web...@revision A, and you have webkit at revision A~10. gclient sync should probably fast-forward your checkout. Say DEPS says web...@revision A, and then you've checked out trunk and have local changes. gclient sync should probably... do nothing? But then how do we tell DEPS checked them out at A~10 before, so we should fast forward to A from they checked out A~10 because that was trunk at the time, so we should fast forward to trunk? I assume s/trunk/HEAD/g But I still don't understand your sentence. Doesn't `git svn rebase --revision A` work for that or I misunderstood? I presume it will back merge if needed? There's also conflict management but that's another story. :) 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] Re: Dev Chrome crashes on subsequent starts after installing a theme
Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
Does http://groups.google.com/group/chromium-dev/browse_thread/thread/df20c1f0e4576131 help? If not, please go to new.crbug.com On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook aftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
Open your favorite terminal program and type rm -rf ~/.config/google-chrome/Default/Extensions/ at the prompt -- Evan Stade On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
Just read the entire thread. It looks like this thread has gotten a little more... mucky than it ever needed to be. What is going on here? On Aug 6, 11:16 am, yoav zilberberg yoav.zilberb...@gmail.com wrote: I apologize, i had no idea all of you are chrome devs, and i shall indeed happily remove myself thanx for answering, and best of luck you all. From what I've seen, the Chromium developers seem very reasonable, and quite knowledgeable. I don't see any reason for the tension we've seen here; and certainly don't see a reason why you should remove yourself from the Chromium community. It's a shame you feel that way, Yoav =\ --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
oh sorry. Not using linux. rm -rf means to delete. So go find your profile directory and delete the Extensions/ folder in there. -- Evan Stade On Thu, Aug 6, 2009 at 2:15 PM, Evan Stadeest...@chromium.org wrote: Open your favorite terminal program and type rm -rf ~/.config/google-chrome/Default/Extensions/ at the prompt -- Evan Stade On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
On Thu, Aug 6, 2009 at 5:15 PM, Evan Stade est...@chromium.org wrote: Open your favorite terminal program and type rm -rf ~/.config/google-chrome/Default/Extensions/ at the prompt Or, if you're using Windows, delete the contents of this folder: C:\Users\your username\AppData\Local\Google\Chrome\User Data\Default\Extensions -- Evan Stade On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
You can find the location of your profile directory on this page: http://dev.chromium.org/user-experience/user-data-directory - a On Thu, Aug 6, 2009 at 2:16 PM, Evan Stadeest...@chromium.org wrote: oh sorry. Not using linux. rm -rf means to delete. So go find your profile directory and delete the Extensions/ folder in there. -- Evan Stade On Thu, Aug 6, 2009 at 2:15 PM, Evan Stadeest...@chromium.org wrote: Open your favorite terminal program and type rm -rf ~/.config/google-chrome/Default/Extensions/ at the prompt -- Evan Stade On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Git usage in chromium
On Thu, Aug 6, 2009 at 2:06 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Say DEPS says web...@revision A, and you have webkit at revision A~10. gclient sync should probably fast-forward your checkout. Say DEPS says web...@revision A, and then you've checked out trunk and have local changes. gclient sync should probably... do nothing? But then how do we tell DEPS checked them out at A~10 before, so we should fast forward to A from they checked out A~10 because that was trunk at the time, so we should fast forward to trunk? I assume s/trunk/HEAD/g Yeah, the SVN HEAD, not the git one. Confusing. :( But I still don't understand your sentence. Doesn't `git svn rebase --revision A` work for that or I misunderstood? I presume it will back merge if needed? I didn't think rebase takes a --revision argument... My examples were bad. Let me try again. Suppose current DEPS says WebKit at revision A. I am tweaking WebKit stuff so I started at the newest version I can find, version B. I have made a local commit on top of that, call it C. Now I do a gclient sync, and my DEPS updates to request some other WebKit version D. In the meantime, the newest WebKit available is now version E. (Note that D can be earlier or later than B.) In this circumstance I think I should remain on commit C. But if C=B, then maybe I should end up at E? Or if you think rebasing is correct, should I rebase C onto E or C onto D? And what if I have local uncommitted changes -- then rebasing isn't possible? Finally, what if D is an *earlier* commit than A (we rolled back DEPS for some reason), do I rebase my work in C backwards? Etc. etc. And say A=B=C (that is, I'm not working on WebKit at all), I think you probably want to end up on D. But detecting that A=C means you need the DEPS file from *before* you synced (to get A). What I had done before was add a tag to each git repo called gclient that always pointed at the version requested by gclient, and then left it up to you whether you wanted to check that out or not. And then you can compare your current commit to the gclient tag and warn appropriately. But I think git is confusing enough for most people so someone (I think it was Tony?) pointed out I can keep it even simpler and say figure it out yourself. --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
haha yes. plain old windows user. i had an inkling it referred to a linum remove command but I thought it could be a shortcut overloader as well (end of target field thing). Anyway, I successfully found the folder, deleted it, installed Dev version, and now everything works! Thank you!! RESOLVED!! On Aug 6, 10:16 pm, Evan Stade est...@chromium.org wrote: oh sorry. Not using linux. rm -rf means to delete. So go find your profile directory and delete the Extensions/ folder in there. -- Evan Stade On Thu, Aug 6, 2009 at 2:15 PM, Evan Stadeest...@chromium.org wrote: Open your favorite terminal program and type rm -rf ~/.config/google-chrome/Default/Extensions/ at the prompt -- Evan Stade On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: Dev Chrome crashes on subsequent starts after installing a theme
*linux On Aug 6, 10:27 pm, Gobbledegook aftabkha...@gmail.com wrote: haha yes. plain old windows user. i had an inkling it referred to a linum remove command but I thought it could be a shortcut overloader as well (end of target field thing). Anyway, I successfully found the folder, deleted it, installed Dev version, and now everything works! Thank you!! RESOLVED!! On Aug 6, 10:16 pm, Evan Stade est...@chromium.org wrote: oh sorry. Not using linux. rm -rf means to delete. So go find your profile directory and delete the Extensions/ folder in there. -- Evan Stade On Thu, Aug 6, 2009 at 2:15 PM, Evan Stadeest...@chromium.org wrote: Open your favorite terminal program and type rm -rf ~/.config/google-chrome/Default/Extensions/ at the prompt -- Evan Stade On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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: crashing on startup
Thanks! Had the same problem and was directed to this solution. Resolved! Windows users need to delete the extensions folder located here: http://dev.chromium.org/user-experience/user-data-directory On Aug 6, 7:43 pm, Evan Martin e...@chromium.org wrote: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. --~--~-~--~~~---~--~~ 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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red
+1 to this idea. Close the tree, only fixes can get in. -- Elliot On Thu, Aug 6, 2009 at 4:09 PM, Dan Kegeld...@kegel.com wrote: Despite having had several valgrind/purify fixit weeks, our bug tracker is still full of 'em. It might be a mistake to expect people to get exicited about combing through a dusty bug database. How about we tap in to the adrenalin rush of a red tree instead? i.e. Next time we hold a valgrind fixit, how about we just delete the non-upstream-bugs suppressions files? The waterfall will turn a lovely shade of red, and people will go into action in their usual rapid way. (We'd still need to publicize it ahead of time, and make sure people were set up with valgrind properly, but that goes without saying.) - Dan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] PluginTest.Refresh is hanging purify every time
Hi Erik, PluginTest.Refresh is hanging purify every time, ever since http://build.chromium.org/buildbot/waterfall/builders/Webkit%20(purify)/builds/9777 two days ago. Want me to file a bug / disable it? --~--~-~--~~~---~--~~ 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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red
+1 Additional benefit would be the cleanup of the suppression files. I believe some of them are fixed (I was able to successfuly remove at least two of them). On Thu, Aug 6, 2009 at 16:16, Elliot Glaysher (Chromium) e...@chromium.orgwrote: +1 to this idea. Close the tree, only fixes can get in. -- Elliot On Thu, Aug 6, 2009 at 4:09 PM, Dan Kegeld...@kegel.com wrote: Despite having had several valgrind/purify fixit weeks, our bug tracker is still full of 'em. It might be a mistake to expect people to get exicited about combing through a dusty bug database. How about we tap in to the adrenalin rush of a red tree instead? i.e. Next time we hold a valgrind fixit, how about we just delete the non-upstream-bugs suppressions files? The waterfall will turn a lovely shade of red, and people will go into action in their usual rapid way. (We'd still need to publicize it ahead of time, and make sure people were set up with valgrind properly, but that goes without saying.) - Dan --~--~-~--~~~---~--~~ 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: PluginTest.Refresh is hanging purify every time
On Thu, Aug 6, 2009 at 4:23 PM, Dan Kegel d...@kegel.com wrote: Hi Erik, PluginTest.Refresh is hanging purify every time, ever since http://build.chromium.org/buildbot/waterfall/builders/Webkit%20(purify)/builds/9777 two days ago. Want me to file a bug / disable it? Per nsylvain, timsteele is disabling this for purify right now. 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: PluginTest.Refresh is hanging purify every time
I believe Erik is also out for the next week. On Thu, Aug 6, 2009 at 4:32 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 6, 2009 at 4:23 PM, Dan Kegel d...@kegel.com wrote: Hi Erik, PluginTest.Refresh is hanging purify every time, ever since http://build.chromium.org/buildbot/waterfall/builders/Webkit%20(purify)/builds/9777 two days ago. Want me to file a bug / disable it? Per nsylvain, timsteele is disabling this for purify right now. 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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red
On Thu, Aug 6, 2009 at 4:09 PM, Dan Kegel d...@kegel.com wrote: Despite having had several valgrind/purify fixit weeks, our bug tracker is still full of 'em. Hence my email last night. i.e. Next time we hold a valgrind fixit, how about we just delete the non-upstream-bugs suppressions files? I think this would be a mistake. There is a lot of accumulated knowledge in the valgrind suppresions file. Doubtless some of it is obsolete (suppressions that no longer apply). However, both erg and phajdan.jr have removed things like this (LayoutTest cruft for erg) recently, and that can be done in a change-one-variable-at-a-time controlled fashion. By contrast, dumping the whole file would have two effects: (1) If you're really serious about it, the tree will be closed for at least several days. This is an extremely high cost. (2) You will be getting intermittent red far more frequently for weeks as the rarest of the suppressions in that file occasionally rear their head. Flakiness is very bad. Compare this to today, where the valgrind bots went red, I put hclam on it, and he had a leak fix inside of an hour. Non-flaky tests mean we can fix new failures fast. For better or worse, I believe we simply have to get people to clean things up themselves. Hence my directive last night for every Googler to put something on his or her OKRs. If we start fixing flaky LayoutTests, memory bugs, etc., the hard-to-track-down valgrind suppressions will be removable too. 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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red
On Thu, Aug 6, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: i.e. Next time we hold a valgrind fixit, how about we just delete the non-upstream-bugs suppressions files? I think this would be a mistake. There is a lot of accumulated knowledge in the valgrind suppresions file. Doubtless some of it is obsolete (suppressions that no longer apply). However, both erg and phajdan.jr have removed things like this (LayoutTest cruft for erg) recently, and that can be done in a change-one-variable-at-a-time controlled fashion. By contrast, dumping the whole file would have two effects: (1) If you're really serious about it, the tree will be closed for at least several days. This is an extremely high cost. (2) You will be getting intermittent red far more frequently for weeks as the rarest of the suppressions in that file occasionally rear their head. I forgot to mention: we would put the still-needed suppressions back after the fixit. There would be no ongoing flakiness as a result of the temporary deletion of the suppressions. Closing the tree for several days would be a low price to pay for cleaning up the flaky tests and valgrind leaks... - Dan --~--~-~--~~~---~--~~ 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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red
On Thu, Aug 6, 2009 at 4:45 PM, Dan Kegel d...@kegel.com wrote: Closing the tree for several days would be a low price to pay for cleaning up the flaky tests and valgrind leaks... I disagree, and I also think that closing the tree would not net you as many people working on valgrind failures as you hope. Most people would continue working on their various different bugs, waiting for the tree to reopen. I know because we have had periods where the tree was closed for more than a full day before and people's behavior was not really affected. I told Ben this morning that I'm taking ownership of the flakiness problem, and I meant it. I will do my best to harass people. Next on my list is going to every single subteam meeting and making noise at all of them. 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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red
On Thu, Aug 6, 2009 at 4:48 PM, Peter Kastingpkast...@google.com wrote: I told Ben this morning that I'm taking ownership of the flakiness problem, and I meant it. I will do my best to harass people. Next on my list is going to every single subteam meeting and making noise at all of them. Thank you for taking this on. --~--~-~--~~~---~--~~ 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-extensions] Re: Extension API Proposal: Performance Tracing
[moving to chromium-dev, as it seems better for this discussion] Kelly, Sorry for not replying earlier. I'm a little bit underwater right now, as we're trying to get everything with extensions tied up so we can turn it on by default on dev. I'd like to take a step back and ponder why even do this as an extension. I assume your end goal must be to build this feature into Chrome's dev tools, right? If so, I think it would be better to start out building the code into Chrome, not on top of the extension system. There is a significant cost to adding APIs to the extension system. They must be general, relatively safe, and we must maintain them, forever. In this case, I don't see a huge demand for these kind of APIs. Even in Firefox, which has infinite flexibility, we only see a few of these type of extensions. In contrast, when something is part of Chrome directly, there is a lot more power and flexibility available. - a On Wed, Aug 5, 2009 at 9:28 AM, Kelly Nortonknor...@google.com wrote: If you're interested in what the mechanics of this would look like, an initial patch for this is posted here: http://codereview.chromium.org/159882 /kelly On Tue, Aug 4, 2009 at 2:39 PM, Kelly Norton knor...@google.com wrote: I've added a document to the chromium wiki that describes an extensions API to support a performance tool, which is being called APU for now. For those who haven't seen the tool, there is a very brief demo in this video: http://www.youtube.com/watch?v=S5aJAaGZIvk#t=21m15s. The API is essentially a firehose of timing data that can be enabled on a per-tab basis. We're hoping this API is a good starting point for DevTools-related APIs in that it has a narrowly focused initial use case and very little API surface area. I'm interested in getting your feedback. http://code.google.com/p/chromium/wiki/ExtensionsPerfTraceAPI Thanks, /kelly -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] gyp failing while triggering gclient sync in linux with git
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 module
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 gspen...@google.com
@0039d316-1c4b-4281-b951-d872f2087c98
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...@227170039d316-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 file... 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: 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 Mansourm0.interact...@gmail.com 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 module
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
gspen...@google.com@0039d316-1c4b-4281-b951-d872f2087c98
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 file... 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: gyp failing while triggering gclient sync in linux with git
Can you check out another client and see if that fixes it for you?
On Thu, Aug 6, 2009 at 8:58 PM, Mohamed Mansour m0.interact...@gmail.comwrote:
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 module
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 gspen...@google.com
@0039d316-1c4b-4281-b951-d872f2087c98
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...@227170039d316-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 file... 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: gyp failing while triggering gclient sync in linux with git
What version of GYP do you have in tools?
Do you have any GYP_* env var set?
Do you have anything in ~/.gyp/*
TVL
On Thu, Aug 6, 2009 at 11:58 PM, Mohamed Mansour
m0.interact...@gmail.comwrote:
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 module
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 gspen...@google.com
@0039d316-1c4b-4281-b951-d872f2087c98
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...@227170039d316-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 file... 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: gyp failing while triggering gclient sync in linux with git
Please check to make sure the python scripts have UNIX line endings, not DOS ones. --~--~-~--~~~---~--~~ 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
I don't believe I have any GYP_* env set:
m...@m0-desktop:~/chrome/src$ echo $PATH
~/chrome/depot_tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
I don't have a directory called ~/.gyp/
m...@m0-desktop:~/chrome/src$ echo $PATH
~/chrome/depot_tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
I got version 579
m...@m0-desktop:~/chrome/src/tools/gyp$ svn infoPath: .
URL: http://gyp.googlecode.com/svn/trunk
Repository Root: http://gyp.googlecode.com/svn
Repository UUID: 78cadc50-ecff-11dd-a971-7dbc132099af
Revision: 579
Node Kind: directory
Schedule: normal
Last Changed Author: gspen...@google.com
Last Changed Rev: 579
Last Changed Date: 2009-08-05 12:49:34 -0400 (Wed, 05 Aug 2009)
I really don't understand what is wrong.
-- Mohamed Mansour
On Fri, Aug 7, 2009 at 12:08 AM, Thomas Van Lenten thoma...@chromium.org
wrote:
What version of GYP do you have in tools?
Do you have any GYP_* env var set?
Do you have anything in ~/.gyp/*
TVL
On Thu, Aug 6, 2009 at 11:58 PM, Mohamed Mansour m0.interact...@gmail.com
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 module
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 gspen...@google.com
@0039d316-1c4b-4281-b951-d872f2087c98
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 file... 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: gyp failing while triggering gclient sync in linux with git
Ah thank you Dan! It worked! I guess I should commit the line ending then? -- Mohamed Mansour On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel d...@kegel.com wrote: Please check to make sure the python scripts have UNIX line endings, not DOS ones. --~--~-~--~~~---~--~~ 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
Yes Mohamed, please do. Which files had the dos line endings?We should really add a presubmit check... -BradN On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour m0.interact...@gmail.comwrote: Ah thank you Dan! It worked! I guess I should commit the line ending then? -- Mohamed Mansour On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel d...@kegel.com wrote: Please check to make sure the python scripts have UNIX line endings, not DOS ones. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] How to debug Aw, Snap! error
Hi, When I load a page on chromium that I run on debugger,I get 'Aw, Snap! Something went wrong while displaying this webpage.' error. And I see this in the console: WebCore::FrameView::paintContents(WebCore::GraphicsContext*, const WebCore::IntRect)) LEAK: 1899 RenderObject LEAK: 1 Page LEAK: 19 Frame LEAK: 1 SubresourceLoader LEAK: 141 CachedResource LEAK: 4197 WebCoreNode [1487:2067:12214450218929:ERROR:../chrome/common/temp_scaffolding_stubs.h(75)] Not implemented reached in bool printing::PrintViewManager::OnRenderViewGone(RenderViewHost*) My question is how can i debug problem like this? Is there a stack trace or core dump for situation like this? 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-dev] Re: How to debug Aw, Snap! error
On Thu, Aug 6, 2009 at 9:43 PM, n179911n179...@gmail.com wrote: When I load a page on chromium that I run on debugger,I get 'Aw, Snap! What page? My question is how can i debug problem like this? Is there a stack trace or core dump for situation like this? If you installed the dev channel version from http://dev.chromium.org/getting-involved/dev-channel and you checked the 'send feedback' button, we'll get a crash log. We look at the top N crashes every dev channel release and try to fix them. (You can even put messages in the environment, e.g. by starting chrome with FOOBAR=every time I click on the frobnicator, it crashes! my_email=n179...@gmail.com google-chrome but we won't see them unless we happen to be looking at that exact crash report, and happen to run strings on the minidump :-) - Dan --~--~-~--~~~---~--~~ 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
I am a little surprised that Python's eval isn't line-ending agnostic. This thread http://mail.python.org/pipermail/pythonmac-sig/2004-September/011638.html suggests it doesn't like \r even on Windows and offers a simple workaround when reading the file: '\n'.join(s.splitlines()) On Thu, Aug 6, 2009 at 9:28 PM, Bradley Nelsonbradnel...@google.com wrote: Yes Mohamed, please do. Which files had the dos line endings? We should really add a presubmit check... -BradN On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Ah thank you Dan! It worked! I guess I should commit the line ending then? -- Mohamed Mansour On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel d...@kegel.com wrote: Please check to make sure the python scripts have UNIX line endings, not DOS ones. --~--~-~--~~~---~--~~ 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 debug Aw, Snap! error
http://code.google.com/p/chromium/wiki/LinuxDebugging has a section on debugging renderers. I'd try the --single-process trick I just added to it. (Despite the page having Linux in the title the gdb tips mostly apply to a Mac as well.) On Thu, Aug 6, 2009 at 9:43 PM, n179911n179...@gmail.com wrote: Hi, When I load a page on chromium that I run on debugger,I get 'Aw, Snap! Something went wrong while displaying this webpage.' error. And I see this in the console: WebCore::FrameView::paintContents(WebCore::GraphicsContext*, const WebCore::IntRect)) LEAK: 1899 RenderObject LEAK: 1 Page LEAK: 19 Frame LEAK: 1 SubresourceLoader LEAK: 141 CachedResource LEAK: 4197 WebCoreNode [1487:2067:12214450218929:ERROR:../chrome/common/temp_scaffolding_stubs.h(75)] Not implemented reached in bool printing::PrintViewManager::OnRenderViewGone(RenderViewHost*) My question is how can i debug problem like this? Is there a stack trace or core dump for situation like this? 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-dev] Re: gyp failing while triggering gclient sync in linux with git
What is stopping us doing Massive line endings commit for all the files in our repository in src/chrome. +1 on the presubmit check! Is there a way to force Visual Studio Solutions or Projects to always save line endings in LF generated via gyp. -- Mohamed Mansour On Fri, Aug 7, 2009 at 1:48 AM, Bradley Nelson bradnel...@google.comwrote: Yeah we should certainly handle this better.This was a known thing, but I've called it out in this gyp issue: http://code.google.com/p/gyp/issues/detail?id=38 I do like have consistent line endings, but the error message leaves something to be desired (not to mention being different on each platform :-). Shouldn't be a big deal to fix. -BradN On Thu, Aug 6, 2009 at 10:39 PM, Evan Martin e...@chromium.org wrote: I am a little surprised that Python's eval isn't line-ending agnostic. This thread http://mail.python.org/pipermail/pythonmac-sig/2004-September/011638.html suggests it doesn't like \r even on Windows and offers a simple workaround when reading the file: '\n'.join(s.splitlines()) On Thu, Aug 6, 2009 at 9:28 PM, Bradley Nelsonbradnel...@google.com wrote: Yes Mohamed, please do. Which files had the dos line endings? We should really add a presubmit check... -BradN On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Ah thank you Dan! It worked! I guess I should commit the line ending then? -- Mohamed Mansour On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel d...@kegel.com wrote: Please check to make sure the python scripts have UNIX line endings, not DOS ones. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
