I don't know if LaunchServices maintains this information, but if it
does, you can reset the launch services database via:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
-eric
On Wed, Feb 10, 2010 at 6:35 PM, Dirk Pranke
ASSERTION FAILED: malloc_size(p)
(/Volumes/Big/WebKit-BuildSlave/leopard-intel-debug/build/WebKitBuild/Debug/JavaScriptCore.framework/PrivateHeaders/ValueCheck.h:52
static void WTF::ValueCheckP*::checkConsistency(const P*) [with P =
WebCore::AtomicStringImpl])
:16 PM, Eric Seidel e...@webkit.org wrote:
ASSERTION FAILED: malloc_size(p)
(/Volumes/Big/WebKit-BuildSlave/leopard-intel-debug/build/WebKitBuild/Debug/JavaScriptCore.framework/PrivateHeaders/ValueCheck.h:52
static void WTF::ValueCheckP*::checkConsistency(const P*) [with P =
WebCore
Chromium's faster, multi-threaded, python-based testing harness landed
in svn.webkit.org about a week ago.
On my 4 core work machine it runs all the tests in 5 minutes vs. 8
minutes with run-webkit-tests. On Dirk's 16 core machine it runs all
the tests in 2minutes.
HUGE thanks to Dirk Pranke
Welcome to WebKit!
I have a few questions (and I assume others are curious to the answers as well):
- Who maintains this port? (Samsung I assume.)
- Is this an active port? (Are there plans for the EFL contributors to
work upstream?)
- Does the EFL port have a DumpRenderTree implementation?
On Tue, Feb 23, 2010 at 2:19 PM, Darin Adler da...@apple.com wrote:
But in practice pixel results are often ignored entirely. I think that
reftest-style tests if done right could be a great addition.
Pixel tests are run for every build by chromium, and regressions
tracked there. :)
Also,
I find http://build.webkit.org/console more useful.
In this case, looks like mitz's patch changed the test:
http://trac.webkit.org/changeset/55203
I'm glad to see more folks are watching the bots!
-eric
On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote:
1. It looks like
after first access, so the order in which
they're accessed can change what code path is used to create them and
expose bugs like this where PASS messages turn into FAILs because the
binding was not created with the right global object pointer.
On Wed, Feb 24, 2010 at 3:50 PM, Eric Seidel e
On Thu, Feb 25, 2010 at 5:26 AM, Jeremy Orlow jor...@chromium.org wrote:
It also frees up the queue for those who need it.
A common misconception, but looking at the logs the commit-queue looks
to be no where near capacity. I believe it could commit every change
done to WebKit in a day and
?annotate=blamerev=54533
On Thu, Feb 25, 2010 at 2:22 PM, Eric Seidel e...@webkit.org wrote:
I agree, I think a commit-...@webkit.org user would be slightly better
than e...@webkit.org committing everyone's patches.
I disagree that committers should feel any need to land their own
patches
On Fri, Feb 26, 2010 at 4:14 AM, Kenneth Christiansen
kenneth.christian...@openbossa.org wrote:
1) Contributor uploads patch and nominates it for review.
2) Patch vetted by the EWS on numerous platforms.
When a non-committer uploads a patch, it is not being vet by EWS. I
know that is due to
On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski a...@milowski.com wrote:
The only EWS which requires committer access is Mac-EWS. All other
EWS bots will run any patch.
Why is that? That's the platform I'm most interested in see run.
Various reasons. Mostly due to our current hardware
The bots take 15 minutes to cycle. The moment the build is broken,
thats FIX_TIME + BOT_CYCLE_TIME until their green again.
I think we should cap the fix grace period at something like 15
minutes, that means no more than 30 minutes of tree redness per break.
That might be too aggressive to
I think we should ignore Tiger for the purposes of this discussion.
Back to the original question: does anyone have reasons to need 2.4?
-eric
On Thu, Mar 4, 2010 at 2:44 AM, Jeremy Orlow jor...@chromium.org wrote:
There difference between Python 2.3 and 2.5 is pretty large. What was added
On Thu, Mar 4, 2010 at 12:39 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 4, 2010, at 12:17 PM, Eric Seidel wrote:
I think we should ignore Tiger for the purposes of this discussion.
We (Apple) still need to do development on Tiger. We would strongly prefer
that WebKit's tools work
Qt and Gtk bots (As well as windows bots and tiger bot) are all red. :(
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
ERROR: WebKit.framework/Versions/A/Headers/DOMFile.h included
WebKit/DOMBlob.h which is private!
ERROR: WebKit.framework/Versions/A/Headers/DOMHTML.h included
WebKit/DOMBlob.h which is private!
Is the error that seems to be blocking the mac-ews bot from running.
I seem to remember Mark Rowe
I'm forcing a clean build on the EWS bot in case that's just a
left-over build failure from an earlier patch.
On Fri, Mar 5, 2010 at 3:24 PM, Eric Seidel e...@webkit.org wrote:
ERROR: WebKit.framework/Versions/A/Headers/DOMFile.h included
WebKit/DOMBlob.h which is private!
ERROR
Thanks. The Mac-EWS bot is back up and running.
The commit-queue seems to be blocked by
https://bugs.webkit.org/show_bug.cgi?id=35819
but I'm still investigating.
-eric
On Fri, Mar 5, 2010 at 4:36 PM, Simon Fraser simon.fra...@apple.com wrote:
On Mar 5, 2010, at 3:24 PM, Eric Seidel wrote
Is there any way to see who has registered? Or is that something
we'll need to make a wiki signup list for or similar?
Thanks!
-eric
On Tue, Mar 9, 2010 at 12:52 PM, Adam Roben aro...@apple.com wrote:
Hi all-
Apple will be hosting a WebKit Contributors Meeting at its campus in
Cupertino,
http://build.webkit.org/builders/Leopard%20Intel%20Release%20%28Tests%29/
Looks like the build slave is offline. Any Apple person able to kick the slave?
-eric
p.s. For any commit-queue users: Since the build was red when it went
offline, the commit-queue will be blocked until it's back.
http://build.webkit.org/builders/Leopard%20Intel%20Release%20%28Tests%29/
Looks like there are two unstoppable jobs on that builder. Not sure
why, or if we care. They don't seem to be blocking normal operation
of the builder.
-eric
___
webkit-dev
Correct, Adam's link is the official source. Tiger does not currently
block the commit-queue.
https://bugs.webkit.org/show_bug.cgi?id=33289 is the bug tracking
adding Tiger to that list (but seems a long way from completion).
The commit-bot has been blocked since the morning of the 8th, but I
The commit-queue is chugging away. I expect it should have emptied
itself within a few hours (assuming the builders stay green).
On Thu, Mar 11, 2010 at 10:01 PM, Eric Seidel e...@webkit.org wrote:
Correct, Adam's link is the official source. Tiger does not currently
block the commit-queue
Down to 4 patches remaining in the queue this morning (due to some
red-bot trouble late last night). Should reach empty today. Thanks
again to all for your patience.
-eric
On Thu, Mar 11, 2010 at 10:48 PM, Eric Seidel e...@webkit.org wrote:
The commit-queue is chugging away. I expect
http://home.introweb.nl/d/dodger/svnauthor.html
Could it be? Anyone know if that could actually work for changing
authorship after-the-fact?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Woh. Looks like this is the real deal:
https://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/svn-tweak-author.py
I'll work with Bill and see if we can wire up some magic. :)
-eric
On Wed, Mar 17, 2010 at 4:40 PM, Eric Seidel e...@webkit.org wrote:
http://home.introweb.nl/d
Gtk and Qt bots need love.
Looks like Gtk needs 5 new results, and Qt needs 42.
Various other tests are failing there too.
Do any Qt/Gtk folks have a minute to try and green up the bots so we
can start tracking regressions on those platforms again?
-eric
On Mon, Mar 22, 2010 at 1:39 PM, Eric Seidel esei...@google.com wrote:
The Qt bots are nice and happy. :) We'll try to keep them that way.
The Gtk bots still need another round of lovin.
-eric
On Fri, Mar 19, 2010 at 7:18 PM, Kenneth Christiansen
kenneth.christian...@openbossa.org wrote
Interesting. Looks like the WebKit icon on CIA is different from
webkit.org. I could have sworn they used to be the same:
http://cia.vc/stats/project/webkit
-eric
On Mon, Mar 22, 2010 at 11:07 AM, Kenneth Christiansen
kenneth.christian...@openbossa.org wrote:
Contest is fine :-) That is how
I would be against changing our guide to discourage spaces.
It's easy (and good practice) to code for handling paths with spaces.
Even if we discourage spaces in webkit itself, people who checkout
webkit in a path with spaces in it would still be screwed.
-eric
On Mon, Mar 22, 2010 at 10:24 PM,
, Mar 22, 2010 at 2:30 PM, Eric Seidel e...@webkit.org wrote:
Interesting. Looks like the WebKit icon on CIA is different from
webkit.org. I could have sworn they used to be the same:
http://cia.vc/stats/project/webkit
That's also the icon used for the WebKit group on LinkedIn:
http
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
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
consider adding the iPhone threading issue to the list of reasons at:
http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/StdLibExtras.h#L31
Thanks for the heads-up.
-eric
On Mon, Mar 29, 2010 at 12:07 PM, Darin Adler da...@apple.com wrote:
On Mar 29, 2010, at 11:07 AM, Eric Seidel wrote:
Can we
It seems Workers makes for a disproportionate number of crashes and
flaky tests on the bots:
https://bugs.webkit.org/show_bug.cgi?id=36646 (timeout)
https://bugs.webkit.org/show_bug.cgi?id=36633 (crash)
https://bugs.webkit.org/show_bug.cgi?id=36585 (timeout)
From my experience watching the bots, I would say the Qt build is
relatively stable, so I suspect it's just good at reproducing this
crasher.
The Qt build is nice that it produces stack traces for every crash.
Sadly their useless until
https://bugs.webkit.org/show_bug.cgi?id=33654 is fixed.
On
infrastructure is workers. If there are
any synchronization bugs on a platform (or in a specific part of WebKit)
they'll primarily show up as failures in Worker tests. I don't think that's
what is happening here, but it's something to keep in mind.
-atw
On Mon, Mar 29, 2010 at 6:10 PM, Eric Seidel e
Thanks to a certain Dr. Barth.
http://trac.webkit.org/changeset/56857
http://trac.webkit.org/changeset/56884
There is also now an Apple Windows EWS bot.
If you have any trouble with the bots, let us know.
-eric
___
webkit-dev mailing list
Parallel painting would only be useful if the graphics layer is
incredibly slow. In most WebKit ports we do not see very much time
painting, rather time is more often spent in layout, style resolution,
or javascript execution/bindings.
-eric
On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg
Traceback (most recent call last):
File ./WebKitTools/BuildSlaveSupport/built-product-archive, line
148, in module
sys.exit(main())
File ./WebKitTools/BuildSlaveSupport/built-product-archive, line 47, in main
extractBuiltProduct(options.configuration, options.platform)
File
I'm strongly in favor of more builders.
However, it would be nice if the builders on build.webkit.org's
front-page were all builders we were actually supposed to keep green.
Right now Windows, Qt and Gtk builders at build.webkit.org are red and
mostly ignored by the project. Would these new
SVN already is an archive. Were we to archive a port, we would just
remove the ifdefs and associated files. We already have scripts for
doing this (buried in bugzilla, or in WebKitTools/Scripts).
-eric
On Fri, Apr 9, 2010 at 2:26 PM, Adam Barth aba...@webkit.org wrote:
Is the Haiku port
Thanks to the tireless efforts of Dirk Pranke, Ojan Vafai, and
numerous other engineers, WebKit now has a new test harness for
running the Layout Tests.
It's FAST:
4-core Mac Pro, Debug build:
run-webkit-tests: 11m25s
new-run-webkit-tests: 3m24s
new-run-webkit-tests --experimental-fully-parallel:
tests) while run-webkit-tests none. Is this expected?
Are all of the errors what you mean by Exposes more flaky tests due to
running tests in a non-deterministic order ?
Yuzo
On Sat, Apr 10, 2010 at 7:35 AM, Eric Seidel e...@webkit.org wrote:
Thanks to the tireless efforts of Dirk Pranke
/subresource-expiration.html = TIMEOUT
tables/mozilla/other/slashlogo.html = TIMEOUT
websocket/tests/frame-lengths.html = TIMEOUT
These are all known slow tests. They just need to be marked SLOW in
LayoutTests/platform/mac/test_expectations.txt
Yuzo
On Sat, Apr 10, 2010 at 8:18 AM, Eric Seidel
:
Regressions: Unexpected tests timed out : (3)
http/tests/cache/subresource-expiration.html = TIMEOUT
tables/mozilla/other/slashlogo.html = TIMEOUT
websocket/tests/frame-lengths.html = TIMEOUT
Yuzo
On Sat, Apr 10, 2010 at 8:18 AM, Eric Seidel e...@webkit.org wrote:
Sounds like a bug
outcome philosophy enables a bunch of neat fringe benefits, including
documenting and tracking flaky tests w/o having them break your
builders or requiring skipping. :)
-eric
On Sat, Apr 10, 2010 at 7:49 PM, Alexey Proskuryakov a...@webkit.org wrote:
10.04.2010, в 17:44, Eric Seidel написал(а):
Yes
when you get an unexpected timeout. Same reason we save
backtraces from crashes. Having some expected timeouts does not remove the
need to diagnose regressions that manifest as a timeout.
On Apr 10, 2010, at 8:39 PM, Eric Seidel e...@webkit.org wrote:
new-run-webkit-tests does not sample tests
Currently the commit-queue commits all patches as e...@webkit.org.
Some contributers have raised concerns that the commit queue does not
properly credit them for their changes (i.e. in svn annotate), or
concerns that the commit-queue should not be used by committers for
risk of incorrect
COMMIT~1 or COMMIT^ both are one commit prior to COMMIT.
COMMIT~2 or COMMIT^^ are both 2 commits prior.
On Tue, Apr 13, 2010 at 8:35 AM, Geoffrey Garen gga...@apple.com wrote:
If Mark would add tags for the nightlies one could type git tag --
contains=COMMIT to figure out which tags include the
It looks completely hosed. It's failing to many tests for it to even
keep track. :(
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Slave Lost.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
http://trac.webkit.org/changeset/57532
http://trac.webkit.org/changeset/57534
My apologies. Investigating now.
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Turns out this was a regression from:
http://trac.webkit.org/changeset/57531
Will be fixed with:
https://bugs.webkit.org/show_bug.cgi?id=37528
This also breaks webkit-patch land until bug 37528 lands.
-eric
On Tue, Apr 13, 2010 at 3:06 PM, Eric Seidel e...@webkit.org wrote:
http
Fixed in http://trac.webkit.org/changeset/57550.
If your webkit-patch checkout is between r57531 and r57550
webkit-patch land will commit with an incorrect commit message.
Please update before using webkit-patch land.
-eric
On Tue, Apr 13, 2010 at 4:48 PM, Eric Seidel e...@webkit.org wrote
http://trac.webkit.org/changeset/57561
Sheriff Bot will nag you when you break Qt.
Commit Queue will block while any Qt builder is broken.
Qt was green all day. The Qt devs @ WKCon seemed very interested in
keeping their bots green.
The goal of the core builder list[1] is to be descriptive,
Dammit. I'm not smart enough to use mailing lists.
My suggestion was WTFURL. ;)
On Tue, Apr 13, 2010 at 11:51 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 13, 2010 at 11:39 PM, David Levin le...@google.com wrote:
On Tue, Apr 13, 2010 at 11:35 PM, Adam Barth aba...@webkit.org
Is it possible to make it so that folks with unregistered nicks can
talk in #webkit again?
Does anyone know how?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Linking is also timing out on the Release builders. Filed:
https://bugs.webkit.org/show_bug.cgi?id=37593
On Wed, Apr 14, 2010 at 12:19 PM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Am 14.04.2010 um 18:28 schrieb Adam Roben:
On 4/14/2010 7:48 AM, Nikolas Zimmermann wrote:
Anders brought to my attention this afternoon that webkit-patch
currently does all SVN operations from the root directory instead of
being current-directory aware. That behavior matches how Git
operates, but does not need to be how webkit-patch operates.
Question: Do SVN users wish to have
bike-shedding
I think 80 columns is a waste of time and hurts readability.
Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.
The optparse code
I don't see this as a decision needing pre-approval.
This is a decision needing code. No one has tried to make Mac, Win,
or other ports use a common system yet. Obviously converting them in
the end requires buy-in from those ports. But producing a demo
doesn't/shouldn't.
I eventually plan to
http://trac.webkit.org/changeset/57795
Sheriff Bot will nag you when you break GTK.
Commit Queue will block while any GTK builder is broken.
build.webkit.org will show GTK in the core set. [1]
The GKT bots have been green every time I've looked the last 5 days.
It would appear the WebKit
new-run-webkit-tests is getting closer for general project-wide use.
If you're on a Mac and would like to experience sub-3-minute layout
test runs and are willing to deal with a few bugs, try
new-run-webkit-tests instead of run-webkit-tests next time you run the
tests. We'd love to see
The commit-queue [1] is up to 28 patches (20 bugs) due to the tree
being red most of yesterday and all of last night. It's green now and
landing things, but it will take it most of today to catch up.
Anything time-sensitive that you need landed should be landed manually. [2]
Sorry for the
I should have asked sooner...
Are any folks stuck here after the WebKit conference due to the volcano?
If so, drop me a line. I'd like to at least offer lunch and possibly
some in-person hack-time.
-eric
___
webkit-dev mailing list
A large portion of the tree redness in the last 3 days is due to JSC
string re-factoring.
We need to build some better tools, or find some better method to land
these changes w/o hosing the tree. I'm happy to help with building of
said tools if folks have requests/suggestions.
Broken in 58001
On Wed, Apr 21, 2010 at 3:35 PM, Ojan Vafai o...@chromium.org wrote:
Also, maybe we could use one of the Windows test bots for the initial trial
of new-run-webkit-tests. Do we know how may cores are on those windows
machines? The improvement in running the tests will be roughly proportional
to
Am I correct that all text output from DumpRenderTree should be utf-8
(thus all expected.txt files as well)?
The Mac Code appears to use utf-8:
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L1091
Obviously it also will spit raw bytes (like webarchives and
://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/qt/DumpRenderTreeQt.cpp#L752
I think I've answered my own question. Thanks.
On Fri, Apr 23, 2010 at 2:39 PM, Eric Seidel e...@webkit.org wrote:
Am I correct that all text output from DumpRenderTree should be utf-8
(thus all expected.txt files
DerivedSources are generated from here:
http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make
I think what your'e thinking of as DerivedSources is actually just the
javascript bindings, which will be useless to you w/o the actual
implementations in WebCore.
If for some reason you
like to be able to
access WebKit's JS bindings from outside of the WebKit view.
It looks like bindings/scripts bit will help me get on the right track, in
any case. Thanks for the pointer.
Eric Seidel wrote:
DerivedSources are generated from here:
http://trac.webkit.org/browser/trunk
Since I'm in the bindings hall of shame, I guess I'm supposed to reply. ;)
The twice that I've used it, it was very helpful. The few reviews
I've done of Adam's it was much better than what we had before.
However, I agree something better could be built. I'm just not sure
what better looks like
WebKitTools/Scripts/webkitpy python requires 2.5+.
We'd like to be able to use python 2.5 on the Tiger build bot (for
websocket tests among other things).
Would someone be able to install a newer Tiger on that machine?
Here is python 2.6.5 for the mac:
would I discover windows test had started to fail. Clearly there is a
lesson I've learned here, but maybe we can find some more hardware to throw
at these queues, to help them avoid getting quite so far behind.
cheers,
G.
On Apr 21, 2010, at 1:39 PM, Eric Seidel wrote:
A large portion
- WBR, Alexey Proskuryakov
06.05.2010, в 21:30, Eric Seidel написал(а):
WebKitTools/Scripts/webkitpy python requires 2.5+.
We'd like to be able to use python 2.5 on the Tiger build bot (for
websocket tests among other things).
Would someone be able to install a newer Tiger
If you don't touch our python or perl scripts you can stop reading.
If you do, you should be aware that all the buildbots [1] are now [2]
running test-webkitpy and test-webkitperl after every commit. This
means python/perl changes can break the tree like any other change and
the sherriffbot
was that essential tools shouldn't add more
requirements on the installed tools. Is it not the case?
- WBR, Alexey Proskuryakov
06.05.2010, в 21:30, Eric Seidel написал(а):
WebKitTools/Scripts/webkitpy python requires 2.5+.
We'd like to be able to use python 2.5 on the Tiger build bot
On Mon, May 10, 2010 at 11:31 AM, Eric Seidel esei...@google.com wrote:
I have seen this on the win-ews ec2 instance.
On May 10, 2010 1:35 PM, John Abd-El-Malek j...@google.com wrote:
After reimaging my Windows 7 machine, prepare-Changelog always crashes for
me now. It seems to have
This is the 3rd in the last few days.
http://trac.webkit.org/changeset/59086
I thought it was generally good practice to have bug.webkit.org bugs
with changes?
webkit-patch upload certainly attempts to make that easy. If there
are other tools we can build to make it easier to always commit
this. credit to tonyg:
1) close cygwin
2) C:\cygwin\binash rebaseall
On Mon, May 10, 2010 at 12:20 PM, Eric Seidel e...@webkit.org wrote:
On Mon, May 10, 2010 at 11:31 AM, Eric Seidel esei...@google.com wrote:
I have seen this on the win-ews ec2 instance.
On May 10, 2010 1:35 PM, John Abd-El
it claims that Eric Seidel wrote every patch.
Indeed. Fortunately, we know how to solve that problem. It just
requires a post-commit hook to change the svn author to match the
ChangeLog. I think Eric already wrote the hook. We just need someone
on the server side to install it.
I don't
As part of https://bugs.webkit.org/show_bug.cgi?id=38866 I've added a
new flag to bugzilla patches called in-rietveld.
This flag may be changed or removed in the coming weeks. If you have
questions/comments/concerns please bring them up with Ojan or Julie on
the bug.
Thanks to both of them for
...@webkit.org wrote:
Can we hide this in the UI? My understanding is that it will be used
only by the tools.
Adam
On Mon, May 10, 2010 at 4:37 PM, Eric Seidel e...@webkit.org wrote:
As part of https://bugs.webkit.org/show_bug.cgi?id=38866 I've added a
new flag to bugzilla patches called
I have made the flag inactive. it was driving my poor little eyes
bonkers. I will work with Julie/Ojan on some less UI-hateful
solution.
-eric
On Mon, May 10, 2010 at 4:46 PM, Eric Seidel e...@webkit.org wrote:
There is an is Active checkbox, which I could uncheck:
https://bugs.webkit.org
, May 10, 2010 at 1:27 PM, Tony Gentilcore to...@chromium.org wrote:
On Mon, May 10, 2010 at 1:07 PM, Eric Seidel e...@webkit.org wrote:
Is this caused by the base load address of both perl and svn
conflicting/overlapping? (I don't really know how CYGWIN works.)
I'm by no means a cygwin
Those which can be found in SVN can be found here:
http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/
Last I heard, the rest are on Mark Rowe's harddrive, somewhere.
-eric
On Sat, May 8, 2010 at 5:10 PM, Trevor Downs cybersk...@mac.com wrote:
Hi. I'm trying to find the scripts
On Mon, May 10, 2010 at 6:04 PM, Brent Fulgham bfulg...@gmail.com wrote:
On Mon, May 10, 2010 at 2:44 PM, Adam Barth aba...@webkit.org wrote:
On Mon, May 10, 2010 at 2:30 PM, Geoffrey Garen gga...@apple.com wrote:
2) Your patch can be vetted by the various bots that analyze patches
posted for
Sent from the wrong email address the first time, sorry.
2) Your patch can be vetted by the various bots that analyze patches
posted for review.
True, if what you're really asking for is not just a bug report but also a
cooling off period during which you wait for a result from the EWS bot,
http://build.webkit.org/console
If someone with a Gtk build could post come baselines that would be fantastic!
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
In the last 3 days the commit-queue has not been keeping up. Due
partially to tree redness, and partially to graphics card troubles on
the machine (https://bugs.webkit.org/show_bug.cgi?id=38912) . The
tree is green now, but I do not expect the commit-queue to be able to
keep up until we solve
compositing is disabled).
One longer term solution is to fix
https://bugs.webkit.org/show_bug.cgi?id=35897.
For now the commit-queue should be rolling again and should make it
through the 30 (!!) patches waiting in its queue tonight and tomorrow.
-eric
On Wed, May 12, 2010 at 10:48 AM, Eric
/layout_tests/port/websocket_server.py,
line 241
with codecs.open(self._pidfile, w, ascii) as file:
^
SyntaxError: invalid syntax
--
ukai
On Tue, May 11, 2010 at 15:07, Maciej Stachowiak m...@apple.com wrote:
On May 10, 2010, at 11:01 PM, Eric Seidel wrote:
On Mon, May 10
Could someone with access to the Cr-Linux bot give it a kick?
http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/6703/steps/svn/logs/stdio
it's filesystem seems to have turned read-only.
-eric
___
webkit-dev mailing list
Filed https://bugs.webkit.org/show_bug.cgi?id=39285 about that last night.
On Tue, May 18, 2010 at 10:15 AM, Adam Barth aba...@webkit.org wrote:
The same test is failing on essentially all the bots:
fast/files/file-reader.html
http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Debug/builds/6146/steps/compile-webkit/logs/stdio
If someone could give it a kick, that'd be great.
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
The Gtk 32-bit Release bot has wedged itself. If someone could kick
it that would be grand:
http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r59822%20(13001)/results.html
Do we understand why this happens so we can prevent it in the future
(this is not the first time)?
-eric
, Eric Seidel wrote:
The Gtk 32-bit Release bot has wedged itself. If someone could kick
it that would be grand:
http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r59822%20(13001)/results.html
Do we understand why this happens so we can prevent it in the future
On Thu, May 20, 2010 at 12:54 PM, Eric Seidel esei...@google.com wrote:
We have various other bot support tools checked in under:
http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/
and
http://trac.webkit.org/browser/trunk/WebKitTools/EWSTools
You should feel encouraged
201 - 300 of 807 matches
Mail list logo
