Re: [webkit-dev] Clobber builds in windows bots needed?

[Brian Weinstein]

In this case you want to touch WebKit.idl, that will force a rebuild of the 
Interfaces project, and should fix the Windows build.

Brian

On Oct 29, 2010, at 11:12 PM, Antonio Gomes wrote:

> Hi.
> 
> After http://trac.webkit.org/changeset/70975, Windows Debug bot
> started failing to build:
> http://build.webkit.org/builders/Windows%20Debug%20%28Build%29 . The
> build error shown is:
> 
> ()
> ### COMPILING 1 FILES USING AT MOST 8 PARALLEL INSTANCES OF cl.exe
> ###
> 
> LayoutTestControllerWin.cpp
> 
> .\LayoutTestControllerWin.cpp(1389) : error C2065:
> 'WebKitEditingUnixBehavior' : undeclared identifier
> ()
> 
> however this enum value is clearly declared in
> WebKit/win/Interfaces/IWebPreferences.idl as
> 
> 50 typedef enum WebKitEditingBehavior {
> 51 WebKitEditingMacBehavior = 0,
> 52 WebKitEditingWinBehavior,
> 53 WebKitEditingUnixBehavior
> 54 } WebKitEditingBehavior;
> 
> Could someone with access to this bot force a complete build? Maybe
> this is needed for this .idl to properly generate the corresponding
> header.
> 
> -- 
> --Antonio Gomes
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Clobber builds in windows bots needed?

[Brian Weinstein]

We have:

Need to touch WebKit.idl whenever Interfaces changes
https://bugs.webkit.org/show_bug.cgi?id=32127

Brian

On Oct 30, 2010, at 12:59 PM, Eric Seidel wrote:

>> From teh right address.
> 
> On Sat, Oct 30, 2010 at 12:59 PM, Eric Seidel  wrote:
>> The correct fix is to fix the dependency issue in the build system.
>> Please file a bug so we can prevent these from occurring in the
>> future.
>> 
>> -eric
>> 
>> On Fri, Oct 29, 2010 at 11:59 PM, Osztrogonac Csaba
>>  wrote:
>>> Hi,
>>> 
>>> Touching header is a general fix for problems like this.
>>> It will fix the build for all developer, but forcing a
>>> clean build solve the build break only on the bots.
>>> 
>>> br
>>> Ossy
>>> 
>>> Antonio Gomes írta:
 
 Hi.
 
 After http://trac.webkit.org/changeset/70975, Windows Debug bot
 started failing to build:
 http://build.webkit.org/builders/Windows%20Debug%20%28Build%29 . The
 build error shown is:
 
 ()
 ### COMPILING 1 FILES USING AT MOST 8 PARALLEL INSTANCES OF cl.exe
 ###
 
 LayoutTestControllerWin.cpp
 
 .\LayoutTestControllerWin.cpp(1389) : error C2065:
 'WebKitEditingUnixBehavior' : undeclared identifier
 ()
 
 however this enum value is clearly declared in
 WebKit/win/Interfaces/IWebPreferences.idl as
 
  50 typedef enum WebKitEditingBehavior {
  51 WebKitEditingMacBehavior = 0,
  52 WebKitEditingWinBehavior,
  53 WebKitEditingUnixBehavior
  54 } WebKitEditingBehavior;
 
 Could someone with access to this bot force a complete build? Maybe
 this is needed for this .idl to properly generate the corresponding
 header.
 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] When are patches added to EWS Queue?

[Brian Weinstein]

I uploaded a patch a couple of hours ago (uplodaded 
https://bugs.webkit.org/attachment.cgi?id=75850&action=edit to bug 
https://bugs.webkit.org/show_bug.cgi?id=50586). However, after those couple of 
hours, it doesn't even look like it has been queued in the EWS system (a couple 
of bots EWS bots are idle, and the bubbles don't have numbers on them to 
indicate where the patch is in the queue).

Is there something I can do to add my patch to the queue? Do I need to 
re-upload it?

Thanks,
Brian Weinstein
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [webkit-changes] [47447] trunk

[Brian Weinstein]

On Aug 18, 2009, at 3:12 PM, Adam Roben wrote:


We avoid ATL in WebKit/DRT code because ATL is not included with VC+ 
+ Express. Presumably this patch has broken the VC++ Express build.


-Adam



Should I just use standard BSTR's there? rs=you to make the change if  
that's what is needed?


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Visual Studio 2005 ATL Security Update

[Brian Weinstein]

At least a few people on IRC have noticed errors that look something  
like the following:


1) If you try to open FindSafari in Windows Explorer you will get the  
message "This application has failed to start because the application  
configuration is incorrect. Reinstalling the application may fix this  
problem."


or

2) In the Control Panel->Administrative Tools->Events Viewer under the  
System events, you will see a SideBySide error with the message  
"Dependent Assembly Microsoft.VC890.CRT could not be found and Last  
Error was The referenced assembly is not installed on your system."


You need to install the Visual Studio 2005 ATL Security update, which  
is linked to from http://webkit.org/building/tools.html.


The link to download the update is: Visual Studio 2005 Service Pack 1  
ATL Security Update. This should fix the problem.


Brian Weinstein


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] A bot-filled future?

[Brian Weinstein]

Seconded (or Thirded). I'd been working on a try-server using Chromium's 
try-change.py, but this seems like a much cleaner way to handle it, and ties 
into the Bugzilla workflow much better than my solution, and would be much 
easier to limit who can set the try bit, based on what we decide the policy to 
be.
 
On Nov 12, 2009, at 12:41 PM, Jeremy Orlow wrote:

> It's so easy to have code that builds on one platform but not another.  Even 
> if the try servers were only builders to begin with, I think they'd provide a 
> lot of value to the project.
> 
> On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen 
>  wrote:
> I think that sounds like a really good idea, and I can see my self
> using that when touching cross platform code.
> 
> Kenneth
> 
> On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth  wrote:
> > As the project grows, we need to scale our processes to match.  In
> > large part, that means automating as much work as possible.
> > Commit-queue has done a good job of solving the "land patches from
> > non-committers efficiently" problem, effectively removing that as a
> > pain point.  I'd like to ask you to open your hearts and your minds to
> > the idea of automating more of our processes.
> >
> > Currently, I see the biggest pain-point in our process as the
> > always-burgeoning pending-review list.  It's difficult to automate the
> > process of accepting good patches because that requires attention from
> > experts.  Instead, I think we should make it easier to reject bad
> > patches.  As a first step, I've started extending bugzilla-tool to be
> > a try server in .
> > Here's how this might work:
> >
> > 1) Contributor posts patch for review.
> > 2) Committer marks patch with the try? flag.
> > 3) The try-queue downloads, applies, builds, and tests the patch.
> > 4) If all systems are go, the try-queue marks the patch as try+.
> > Otherwise, it marks the patch as try- with an explanation of what went
> > wrong.
> >
> > The try-queue will be purely optional and advisory.  Hopefully a try-
> > notation will encourage the contributor to post a new version of the
> > patch that passes the try-queue.
> >
> > Further down the road, one can also imagine another bot that automates
> > step (2) by scanning the pending-review list for untried patches and
> > marking them as try? when the try-queue has unused bandwidth.
> >
> > Adam
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> 
> 
> 
> --
> Kenneth Rohde Christiansen
> Technical Lead / Software Engineer
> Qt Labs Americas, Nokia Technology Institute, INdT
> Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] A bot-filled future?

[Brian Weinstein]

What if someone changed build-webkit or the build procedure in one of the 
vcproj's?

On Nov 12, 2009, at 2:50 PM, Jeremy Orlow wrote:

> That sounds good to me.
> 
> As for the security issues: It seems like we could build code from anyone but 
> only run the tests from committers.
> 
> On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth  wrote:
> On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe  wrote:
> > 1) People are already confused about how to handle the recently-added 
> > commit-queue flag.  Adding an extra flag is going to increase the confusion.
> 
> I chatted with Eric about how to solve this problem.  One option is to
> just try every change that has review? and add a comment to the bug
> about success / failure.  That minimizes the UI surface and avoids
> adding yet-another-flag.
> 
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Windows Bots?

[Brian Weinstein]

My theory as to what is happening is that:

- The Windows Release tests take ~500 seconds to run.
- The Windows Debug tests take ~950 seconds to run.

The master is currently configured so that both Windows test bots 
(apple-windows-3 and apple-windows-4 - as seen in 
WebKitTools/BuildSlaveSupport/build.webkit.org-config/config.json) both 
currently run Debug and Release Tests. This means that they both have to keep 
two trees up to date (the debug and release trees), and that ~2/3 of the
time on both machines will be spend running the slower debug tests, causing 
them both to fall behind.

My idea for a solution to this is to reconfigure the master so that one 
computer is running one kind of test (3 runs debug, 4 runs release or vice 
versa). This would mean that the bots would only need to keep one tree up to 
date (dropping the amount of time they need to spend in the svn step (which is 
surprisingly slow on inspection)), and it would mean if the debug bot fell 
behind, the release bot would be able to stay caught up with the commits.

If there are any objections to this proposal, reply back on webkit-dev, if not, 
it would be great to get the master changed to make this happen.

I think another reason it was especially bad today was that in the past 24 
hours there have been 100+ commits, which is much higher than the average.

Thanks,
Brian Weinstein


On Mar 25, 2010, at 4:26 PM, Eric Seidel wrote:

> Does anyone know what's up with the windows bots?
> http://build.webkit.org/builders/Windows%20Release%20%28Tests%29
> http://build.webkit.org/builders/Windows%20Debug%20%28Tests%29
> 
> They seem wedged.  Or maybe they're just super slow?
> 
> -eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Windows Bot Wedged?

[Brian Weinstein]

I'll take care of it, thanks for the heads up.

Brian

On Apr 7, 2010, at 9:20 PM, Eric Seidel wrote:

> Traceback (most recent call last):
>  File "./WebKitTools/BuildSlaveSupport/built-product-archive", line
> 148, in 
>sys.exit(main())
>  File "./WebKitTools/BuildSlaveSupport/built-product-archive", line 47, in 
> main
>extractBuiltProduct(options.configuration, options.platform)
>  File "./WebKitTools/BuildSlaveSupport/built-product-archive", line
> 124, in extractBuiltProduct
>shutil.rmtree(binDirectory)
>  File "/usr/lib/python2.5/shutil.py", line 174, in rmtree
>onerror(os.remove, fullname, sys.exc_info())
>  File "/usr/lib/python2.5/shutil.py", line 172, in rmtree
>os.remove(fullname)
> OSError: [Errno 13] Permission denied:
> '/home/buildbot/slave/win-release-tests/build/WebKitBuild/bin/DumpRenderTree.exe'
> 
> If someone with access could kick it, that would be great. :)
> 
> -eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Windows Bot Wedged?

[Brian Weinstein]

Should be fixed now.

Brian

On Apr 7, 2010, at 9:22 PM, Brian Weinstein wrote:

> I'll take care of it, thanks for the heads up.
> 
> Brian
> 
> On Apr 7, 2010, at 9:20 PM, Eric Seidel wrote:
> 
>> Traceback (most recent call last):
>> File "./WebKitTools/BuildSlaveSupport/built-product-archive", line
>> 148, in 
>>   sys.exit(main())
>> File "./WebKitTools/BuildSlaveSupport/built-product-archive", line 47, in 
>> main
>>   extractBuiltProduct(options.configuration, options.platform)
>> File "./WebKitTools/BuildSlaveSupport/built-product-archive", line
>> 124, in extractBuiltProduct
>>   shutil.rmtree(binDirectory)
>> File "/usr/lib/python2.5/shutil.py", line 174, in rmtree
>>   onerror(os.remove, fullname, sys.exc_info())
>> File "/usr/lib/python2.5/shutil.py", line 172, in rmtree
>>   os.remove(fullname)
>> OSError: [Errno 13] Permission denied:
>> '/home/buildbot/slave/win-release-tests/build/WebKitBuild/bin/DumpRenderTree.exe'
>> 
>> If someone with access could kick it, that would be great. :)
>> 
>> -eric
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JSC String re-factorings are hosing the tree.

[Brian Weinstein]

I sent an email to webkit-dev a couple of weeks ago, explaining my logic behind 
why I thought the testers were slow.



My theory as to what is happening is that:

- The Windows Release tests take ~500 seconds to run.
- The Windows Debug tests take ~950 seconds to run.

The master is currently configured so that both Windows test bots 
(apple-windows-3 and apple-windows-4 - as seen in 
WebKitTools/BuildSlaveSupport/build.webkit.org-config/config.json) both 
currently run Debug and Release Tests. This means that they both have to keep 
two trees up to date (the debug and release trees), and that ~2/3 of the
time on both machines will be spend running the slower debug tests, causing 
them both to fall behind.

My idea for a solution to this is to reconfigure the master so that one 
computer is running one kind of test (3 runs debug, 4 runs release or vice 
versa). This would mean that the bots would only need to keep one tree up to 
date (dropping the amount of time they need to spend in the svn step (which is 
surprisingly slow on inspection)), and it would mean if the debug bot fell 
behind, the release bot would be able to stay caught up with the commits.

If there are any objections to this proposal, reply back on webkit-dev, if not, 
it would be great to get the master changed to make this happen.

I think another reason it was especially bad today was that in the past 24 
hours there have been 100+ commits, which is much higher than the average.

Thanks,
Brian Weinstein



I think we need to make this change on the master, and didn't hear any 
objections to it when I brought it up last time. I can upload a patch to 
bugzilla if that's the easiest way to handle it.

Thanks,
Brian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JSC String re-factorings are hosing the tree.

[Brian Weinstein]

Ojan,

What is going there is that both machines are running Windows Debug Tests (or 
Windows Release Tests).

We have two machines that run both Windows Debug Tests, and Windows Release 
Tests, so there are some times where they are both running the same kind of 
test, and it looks like the other kind of test is idle, when both machines are 
actually busy.

Brian

On Apr 22, 2010, at 11:42 AM, Ojan Vafai wrote:

> On Thu, Apr 22, 2010 at 11:32 AM, Adam Roben  wrote:
> On Apr 22, 2010, at 2:30 PM, Ojan Vafai wrote:
> Builds 11611 and 11612 took 89 and 93 seconds, respectively. Seems like 
> there's a fair amount of variance. In any case it sounds like the svn step is 
> even less of an issue than we thought.
> 
> In addition, those builds took less than 14 minutes overall, which is not so 
> far off from the Leopard Release test bots. So what's causing the slowness on 
> Windows?
> 
> Do we just have fewer machines running Windows tests? Also, there are huge 
> gaps where both the release and debug Windows Tests bots have huge idle 
> periods despite having pending builds to test.
> 
> For example: 
> http://build.webkit.org/waterfall?builder=Windows%20Debug%20(Build)&builder=Windows%20Debug%20(Tests)&builder=Windows%20Release%20(Build)&builder=Windows%20Release%20(Tests)
> 
> 11:06:15-11:31:39. The debug tests bot is just idle for 25 minutes despite 
> having 32 pending builds to test. 
> 
> With 32 pending builds, anyone checking in now will have to wait 8 hours to 
> see the results of their checkin on the Windows Tests bots.
> 
> Ojan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Disable sheriffbot bug posts?

[Brian Weinstein]

I filed  about this yesterday, 
that sherifbott should include a link to the failing bot output. I originally 
filed the bug with IRC in mind, but this is also true with the comments to bugs.

Brian

On Sep 23, 2010, at 1:43 PM, Mihai Parparita wrote:

> Perhaps if they included a link to the bot output (or at least the
> build permalink for that revision on that bot) they would be more
> useful (even if they're false positives, they could be checked and
> rejected that much faster).
> 
> Mihai
> 
> On Thu, Sep 23, 2010 at 1:36 PM, Adam Barth  wrote:
>> Hi webkit-dev,
>> 
>> Does anyone find the sheriffbot bug posts useful?  My sense is that
>> they're too noisy because of flaky tests and large blamelists.  I'm
>> inclined to turn them off unless someone else is finding them useful.
>> 
>> Thanks,
>> Adam
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Touch operation corrupts screen when specifying other than overflow:visible in css

[Brian Weinstein]

Please file a bug at https://bugs.webkit.org with the component WebKit Misc. 
and attach your test case as an HTML file. Please also CC me on it 
(bweinst...@apple.com).

Thanks!
Brian Weinstein 

On Oct 17, 2012, at 12:58 AM, HIDEKI YOSHIDA  
wrote:

> Hi,
> 
> On a windows 7 tablet, PAN operation(=scroll) causes
> corruption of screen.
> 
> Does anybody know how to resolve this or have the fix?
> 
> How to reproduce.
> 1. Prepare a HTML contents which have an element specifying
>   other than "visible" to the property overflow in css.
> 2. Load the contents with webkit
> 3. Operate the touch operaion, PAN on the element.
> 
> Problem
> The content in the element protrudes outside the placeholder 
> for it and can disappear.
> 
> The build version
> Webkit.exe on r131112 for Nightly builds
> 
> We guess Source\WebKit\win\WebView.cpp has some bugs on this 
> issue.
> 
> Here is the sample contents to reproduce problem. You will see the
> problem if you PAN on the field for "overflow:auto".
> 
> --
> 
> pan with css:overflow
> 
> 
> 
> overflow:visible
> 
> 
> 
> overflow:auto
> 
> 
> 
> 
> --
> 
>Hideki
> 
> ***
>  Hideki Yoshida
>  Embedded Software Division
>  NEC System Technologies, Ltd.
>E-MAIL:yoshida-...@necst.nec.co.jp
> ***
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] obtaining webkit.org address?

[Brian Weinstein]

What Simon said is correct.

We would prefer that contributors use their company affiliated email for 
committing. However, if there is a need for a webkit.org email (some people 
don't have access to their work email when not in the office, for example), 
please email me with your request for an @webkit.org email with the username 
you would like and where you would like it to be forwarded.

A further note is, if you are given a @webkit.org email and have a company 
affiliation, the company affiliated email should be used for committing, the 
@webkit.org email is meant for mailing lists.

Thanks!
Brian

On Apr 29, 2013, at 10:17 AM, Simon Fraser  wrote:

> I don't think WebKit has a strict policy on this.
> 
> I would actually prefer that we phase out webkit.org email addresses. I like 
> to be able to determine what someone's affiliation is.
> 
> Simon
> 
> On Apr 28, 2013, at 9:10 PM, Glenn Adams  wrote:
> 
>> 
>> On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams  wrote:
>> And if one prefers to use a webkit.org address, like you are doing?
>> 
>> A little follow-up: when I got my SVN account and credentials earlier this 
>> year as a committer, I expected to be given or at least asked if I wanted a 
>> webkit.org address, to which I would have said yes. However, I wasn't asked 
>> and the credentials went through with my company address. As my company is 
>> basically just me, I would prefer to use a webkit.org address in order to 
>> identify better with the community as such. So I'm just now following up on 
>> this inquiry about how to get a "community" address.
>>  
>> 
>> 
>> On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes  wrote:
>> Previously people used to get SVN accounts associated to a @webkit.org 
>> alias. Today it seems like it is preferable to get a company email as alias, 
>> and credential to write-access SVN.
>> 
>> 
>> On Sunday, April 28, 2013, Glenn Adams wrote:
>> How does a committer/reviewer obtain a webkit.org address? I notice that the 
>> majority of existing committers and reviewers have either a webkit.org or a 
>> chromium.org address listed in contributors.json. I think it an important 
>> part of being part of the WK community to be able to identify oneself as 
>> being in that community, and having a usable webkit.org address seems a good 
>> way to effect that.
>> 
>> G.
>> 
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev