Re: [webkit-dev] Adding JSC stress test runs with other options

[Osztrogonác Csaba]

Hi,

As far as I know there is no documentation about what can you
add after "//@". But in general you can add there whatever you
want. It is executed by run-jsc-stress-tests in an eval:
https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/run-jsc-stress-tests#L576

br,
Ossy

2019.09.20. 11:38 keltezéssel, Paulo Matos írta:

Hi,

Due to the failure reported in
https://bugs.webkit.org/show_bug.cgi?id=202041 which I am investigating,
I was attempting to add a test run of
stress/regexp-unicode-surrogate-pair-increment-should-involve-length-check.js

  with the option --useRegExpJIT=0
Unfortunately simply adding //@ requireOptions("--useRegExpJIT=0"),
makes all the tests on the file use the option instead of using the
option as an addition to what was already running.

Is there currently a way to say, in addition to the tests you're already
running, try running with this option X?

Also, is there in general any documentation on the /test language/ one
can use in test headers? i.e. after //@? See
http://llvm.org/docs/TestingGuide.html#constraining-test-execution
for an example of such documentation.

Thanks,


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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Osztrogonác Csaba]

Hi,

I expected exactly this proposal when Apple announced the 64-bit
only iOS 11 near 3 months ago. ( I should have bet. :) )

I can understand that 32-bit is only an unnecessary barrier
for you and you don't want to bear the maintenance cost of it
when there isn't a significant amount of contributors for
maintaining and active developing 32-bit backends.

Maybe it will be hard to say good bye to 32-bit architecutres
for many people, but please, it's 2017 now, the first ARMv8 SoC
is out 4 years ago, the first AMD64 CPU is out 14 years ago.

br,
Ossy

On 2017.09.05. 15:51, Filip Pizlo wrote:

I think that JIT support on platforms that don’t get regular tuning doesn’t 
make sense. I think we should:

- Remove JIT support for 32-bit platforms
- Remove JIT support for Windows
- Remove JSVALUE32_64
- Use cloop In 64-bit mode on 32-bit platforms and Windows.

I think this approach would be best for the project since it would mean less 
time spent on JIT ports that are never quite done.

-Filip

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

Re: [webkit-dev] Idiom for functions with all return values in a switch case

[Osztrogonác Csaba]

Hi,

On 2017.05.11. 0:32, Andy Estes wrote:

On May 10, 2017, at 3:17 PM, Michael Catanzaro  wrote:

On Tue, May 9, 2017 at 2:57 PM, Ryosuke Niwa  wrote:

One annoying thing is that I've seen clang complaining about that
return statement being an unreachable statement while gcc doesn't :(.
So we probably shouldn't have return statement, not to mention that 0
may not be a valid enum value.


In that case, I think I'll go with RELEASE_ASSERT_NOT_REACHED() for now... 
since otherwise GCC is going to complain in release builds if there is no 
return statement. (Won't clang complain about that too?)


Clang won’t complain if the switch is exhaustive and all cases return.

Andy


It isn't possible to check if all cases return if there is
no default label in the switch, see these comments for details:
https://bugs.webkit.org/show_bug.cgi?id=150842#c3

GCC's warning is correct and clang won't complain,
but undefined behaviour can happen in runtime.

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

[webkit-dev] What happened to WKR and webkitbot?

[Osztrogonác Csaba]

Hi,

it seems WKR and webkitbot left #webkit IRC channel
on 4th Nov and we can't see them since then.

It would be great if somebody could
find and ask them to come back.

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

Re: [webkit-dev] Bugzilla clock

[Osztrogonác Csaba]

Hi Lucas,

The clock is still or again 4 minutes fast.
Could you possibly check what happened?

Ossy

On 2016-11-08 19:10, Lucas Forschler wrote:

Thanks Michael,

I have configured the machine to sync with a local time server.
Lucas


On Nov 8, 2016, at 4:10 AM, Michael Catanzaro  wrote:

I notice that the clock on Bugzilla is about four minutes fast. I guess
it's not using NTP?

This is not anywhere near as important as not being able to commit.
It's just very slightly annoying. But I did want to report it
somewhere!

Michael

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

Re: [webkit-dev] Importing Test262 into WebKit

[Osztrogonác Csaba]

Hi,

I checked the current status on Linux (JSCOnly port), and got the following:
- 38109 tests (19758 different tests, most of them are run in
  strict and non-strict mode too, some of them only in one mode.)
- 2742 failures
- runtime: 12.5 minutes (on a Core i5 760 @ 2.80GHz CPU)
  note: test262's (deprecated!) test runner can't run tests parallel

How do you plan to include test262?
- check-in all tests (20Mb, ~20k files!) / update them periodically ?
- clone a stable revision automatically by test-harness / manually by the user ?

How do you plan to handle [onlyStrict], [noStrict] flags and
negative/includes directives in test cases?
- I would prefer offline parsing of the test cases and check-in
a generated yaml file describes how to run each tests properly.
(With a checked in script to be able to regenerate it easily after an update.)

Do you plan to run all tests with different JSC configurations?
(noJIT,noLLINT, DFG/FTLEager, noCJIT, ...)

It would be great to see preliminary results, such as runtime, conformance,
stability before making JSC tester bots run these tests by default.

I willingly help testing patches on X86_64/ARM Linux environments,
reviewing run-jsc-stress-tests improvements, please cc me to the
related bug reports and feel free to ping me on IRC.

br,
Ossy

On 2016-05-13 01:02, Keith Miller wrote:

Hi everyone,

For those of you that have not already heard of Test262, it is a continually 
updated conformance test suite for upcoming ECMAScript standards 
(https://github.com/tc39/test262). I think it’s in our best interest to include 
the test suite in our normal testing infrastructure for JavaScriptCore. The 
current plan is to only run the Test262 tests when running run-javascript-core 
tests. The test suite is fairly large (~15000 tests) and the last time I ran 
it, it took about ~15-20 minutes to run. Are there any questions or concerns 
with this proposal?

Cheers,
Keith

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

[webkit-dev] EWS: feeder and style queues are offline

[Osztrogonác Csaba]

Hi,

it seems feeder and style queues are offline
now, which means EWS and CQ bots aren't fed.

Could somebody possibly restart these bots?

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

[webkit-dev] Are there any plans to upgrade bugzilla server on bugs.webkit.org?

[Osztrogonác Csaba]

Hi,

The actual topic is upgrading, let's discuss about bugzilla too.

bugs.webkit.org still uses the ancient and unsecure 4.2.11 bugzilla.
The last release from 4.2 series is 4.2.16 (2015 Dec 22) which means
the EOL of 4.2. The latest releases are 4.4.11 and 5.0.2.

Once we could upgrade to 4.4+, a very old annoying bug would be fixed:
https://bugs.webkit.org/show_bug.cgi?id=124047 . (If you review a
patch, you aren't cc-ed to the bug to be able to follow the future
of the bug. You won't be notified if the author fixes what you asked
or if the patch breaks the build or makes tests fail.)

[1] https://www.bugzilla.org/news/
[2] https://bugs.webkit.org/show_bug.cgi?id=55882

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

Re: [webkit-dev] Are there any plans to upgrade SVN server on svn.webkit.org?

[Osztrogonác Csaba]

+1 for upgrading the SVN server.

1.6.11 is really outdated and I think it is unsecure too.
1.6.11 was released 6 years ago and the last release
from 1.6 series is 1.6.23 which was released 3 years ago.

https://subversion.apache.org/docs/release-notes/release-history.html
https://en.wikipedia.org/wiki/Apache_Subversion

br,
Ossy

Konstantin Tokarev írta:

Hello,

According to [1], currently svn.webkit.org runs severely outdated Subversion 
1.6.11. Since then, there were 3 significant releases of Subversion, which 
brought lots of performance improvements, most importantly brand new HTTP 
protocol [3] and storage format improvements [4]. Also, since 1.7 Apache 2.4 
with MPM event is supported, which may increase server throughput.


BTW, to improve performance of up to date Subversion client (>= 1.8), it is 
needed to adjust Apache configuration[5]: increase MaxKeepAliveRequests from 
default 100 to at least 1000. This needs to be done regardless of Subversion 
server upgrade.


[1] http://svn.webkit.org/repository/webkit/
[2] https://subversion.apache.org/docs/release-notes/1.7.html
https://subversion.apache.org/docs/release-notes/1.8.html
https://subversion.apache.org/docs/release-notes/1.9.html
[3] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2
[4] https://subversion.apache.org/docs/release-notes/1.8.html#fsfs-enhancements
https://subversion.apache.org/docs/release-notes/1.9.html#fsfs-improvements
[5] https://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
http://svn.haxx.se/dev/archive-2011-01/0320.shtml

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

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS [WARNING - NOT VIRUS SCANNED]

[Osztrogonác Csaba]

Hi,

now the #error macro in Compiler.h is the only one blocker to
be able to build JSCOnly port with GCC 4.8 (without FTL JIT):
http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Compiler.h#L73

The existance of a buildbot doesn't mean any obligation for anybody.
We have many bots which are allowed to break. Everybody is allowed
to break the Apple Mac cmake build, WebKit2 owners can break EFL/GTK
builds, JSC developers can break ARM Linux builds.

br,
Ossy

Filip Pizlo írta:

I don't want a buildbot for MIPS. It's not a relevant architecture anymore. I 
don't think that JSC developers should have to expend effort towards keeping 
this architecture working.

-Filip


On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  wrote:

Hello,

I'd like to run build slave for MIPS port of JSC (with JSCOnly port on Linux). 
On the first iteration it will just ensure that compilation is not broken, 
afterwards I'm planning to add running tests on target.

However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, the 
latest one supplied by Broadcom), and unmodified tree won't build because of 
GCC version check in Source/WTF/wtf/Compiler.h.

Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 (only 
for JavaScriptCore without B3)? I'm going to fix arising compilation errors 
myself.

--
Regards,
Konstantin


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

[webkit-dev] SPAM on trac.webkit.org

[Osztrogonác Csaba]

Hi,

a SPAM-mer added an attachment to wiki start page of trac.webkit.org:
https://trac.webkit.org/attachment/wiki/WikiStart/turbotax%20toll%20free%20phone%20number%20866%20769%208127%20turbotax%20help%20phone%20number.pdf

Previously I removed many SPAM from wiki pages, but I don't have rights
to remove attachments, only users with WIKI_ADMIN permission can do it.

It would be great if somebody can remove
this SPAM and ban the user who added it.

Just out of curiosity, why trac.webkit.org WIKI can be editable by
everybody? Shouldn't we restrict it for only contributors who are
present in contributors.json?

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

Re: [webkit-dev] Mac CMake

[Osztrogonác Csaba]

Hi,

despite the initial enthusiasm I haven't seen any green build at least a
month ago or any intention to add/remove files to the cmake build system.

Just out of curiosity, is there any chance that Apple Mac WebKit
will be migrated to cmake within the foreseeable future?

br,
Ossy

On 2015-10-31 18:29, Lucas Forschler wrote:

Our buildbot is up and running, and GREEN, let’s keep it that way!
https://build.webkit.org/builders/Apple%20El%20Capitan%20CMake%20Debug%20%28Build%29?numbuilds=25



On Oct 30, 2015, at 2:17 PM, Alex Christensen > wrote:

I got the Mac CMake build to the point where it can compile and link 
frameworks successfully.  We will get a buildbot up
soon, but in the meantime please try to add and remove files in the CMake 
build.Let me know if you have any questions or
concerns or want to help out.  I don’t think it can be used to run Safari 
yet, but that’s hopefully coming soon.

If you want to try it out, run this command:
Tools/Scripts/build-webkit --cmake

Alex

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

Re: [webkit-dev] CC on reviewed bugs

[Osztrogonác Csaba]

Hi,

It is a very old issue and I already proposed to fix it 2 years
before: https://bugs.webkit.org/show_bug.cgi?id=124047 and once again:
https://lists.webkit.org/pipermail/webkit-dev/2014-October/026944.html

It is a known and fixed bugzilla issue in bugzilla 4.4 (3.5 year ago!).
As far as I know we still use bugzilla 4.2(.11) which reached of its end
of life in 2015 Dec 22 - https://www.bugzilla.org/news/

One more reason to upgrade our bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=55882

br,
Ossy

Michael Catanzaro írta:

On Thu, 2016-01-07 at 13:09 -0800, Brian Burg wrote:

The only reason that normal commenting will CC you is that the [X]
Add me to CC list is checked by default.
I agree it would be reasonable to duplicate that behavior when
commenting via the review tool.

To do this, you’d have to modify “sub update()” in attachment.cgi,
and pass in some new parameter.
I recommend filing a bug so we can deliberate how to implement it.

-Brian


OK: https://bugs.webkit.org/show_bug.cgi?id=152854

Thanks,

Michael

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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Osztrogonác Csaba]

I like the idea to have a platform free, standalone JSC.
It would make easier to maintain various ARM backends.

We don't need update-webkit*-libs at all for the
standalone JSC, it really depends only on ICU and LLVM.

Ossy

Geoffrey Garen írta:

I think it would be nice to avoid tying the Nix build to update-webkitgtk-libs, 
since part of the stated goal is platform freedom.

Geoff


On Nov 11, 2015, at 2:15 AM, Sergio Villar Senin  wrote:

On 11/11/15 08:04, Yusuke SUZUKI wrote:

Hello WebKittens,

JavaScriptCore use in non-OSX environment looks emerging[1].
In addition to that, sometimes, people would like to build
JavaScriptCore to see what is happning in JavaScriptCore development[2].
However, if you don't have an OSX machine, it is a little bit difficult.
One possible solution is GTK+ port, it is nice way to build JSC in Linux.
But it involves many dependencies (Mesa, glib etc.), that are not
necessary for JavaScriptCore and this is a barrier to join JSC
development from non OSX world.

The gtk port has several external dependencies as any other port and
indeed most of them are not needed for building JSC. However I don't see
those dependencies being a barrier, mainly because we build them using a
jhbuild environment, so even if your distro don't provide the required
dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.

Do you have issues doing that?

BR


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

[webkit-dev] Proposal: Remove ENABLE(SATURATED_LAYOUT_ARITHMETIC)

[Osztrogonác Csaba]

Hi,

ENABLE(SUBPIXEL_LAYOUT) guard was removed and 
ENABLE(SATURATED_LAYOUT_ARITHMETIC)
is enabled on all ports more than a year ago. I don't know any issue related to 
it.

I'd like to propose to remove the ENABLE(SATURATED_LAYOUT_ARITHMETIC) guards 
too.
https://bugs.webkit.org/show_bug.cgi?id=150972

Any objection?

br,
Ossy

former thread - [webkit-dev] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT)
On 2014-08-18 22:30, Zalan Bujtas wrote:

Hi,

Quote for from bug #124234
"Since the SATURATED_LAYOUT_ARITHMETIC flag makes no sense without 
SUBPIXEL_LAYOUT, actually there is an assertion preventing this, it seems that the 
most sensible action is to merge the SATURATED_LAYOUT_ARITHMETIC logic into the 
SUBPIXEL_LAYOUT, and eventually removing it.”
Makes sense. I might just remove ENABLE(SATURATED_LAYOUT_ARITHMETIC) too 
(instead of just enable it by default).

Zalan.

On Aug 18, 2014, at 12:47 PM, Javier Fernandez  wrote:


Hi,

On 08/18/2014 08:14 PM, Zalan Bujtas wrote:

Hi Everyone, I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as
every port has it enabled. As part of this activity, I am planning to
enable SATURATED_LAYOUT_ARITHMETIC by default. Thanks, Zalan.


I've already opened a bug to address this issue, but unfortunately,
didn't find the time to complete the task. See
https://bugs.webkit.org/show_bug.cgi?id=124234 for details.

--
javi

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

Re: [webkit-dev] Commit queue issues

[Osztrogonác Csaba]

Hi,

now everything is broken again. :(

trac.webkit.org:
-
OperationalError: could not connect to server: Connection timed out
Is the server running on host "data.macosforge.org" and accepting
TCP/IP connections on port ?

bugs.webkit.org:
-
Internal Server Error

The server encountered an internal error or misconfiguration and was 
unable to complete your request.


Please contact the server administrator, ad...@webkit.org and inform 
them of the time the error occurred, and anything you might have done 
that may have caused the error.


More information about this error may be available in the server error log.
Apache/2.2 Server at bugs.webkit.org Port 443

perf.webkit.org:

Performance bots can't upload the results.

Uploaded JSON to https://perf.webkit.org/api/report but got an error:
{
"status": "DatabaseConnectionFailure",
"failureStored": false
}

It would be great to fix this issue as soon as possible. Thanks.

br,
Ossy


Alexey Proskuryakov írta:

2 . 2015 ?., ? 9:59, Alexey Proskuryakov  ???(?):


02 . 2015 ?., ? 5:41, Philippe Normand  ???(?):


It seems the commit queue cannot land patches?

https://bugs.webkit.org/show_bug.cgi?id=148702

This should be resolved now. I see that you already marked this patch for cq+ 
again; I'll see if any others are stuck.


The issue re-occurred later in the day, and should be really resolved now. Many 
thanks to everyone who worked on fixing it!

- Alexey

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

Re: [webkit-dev] Windows Build Now on VS2015

[Osztrogonác Csaba]

Hi,

On 2015-08-25 15:36, z...@falconsigh.net wrote:

EFL port already switched IndexedDB on by
https://trac.webkit.org/changeset/187596 ,
so we need at least GCC 4.9 since then.



But do you check for that version?


Not yet.


Anyway, there's a check for 4.7.0 in Source/WTF/wtf/Compiler.h that is
apparently redundant now.


Let's bump this check to 4.9 :
https://bugs.webkit.org/show_bug.cgi?id=148430

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

Re: [webkit-dev] Svn server is very slow to get full code.

[Osztrogonác Csaba]

Hi,

We have the same network issue in Hungary / Europe. And
it seems that some of the EFL and GTK bots are affected too.

All *.webkit.org (svn,build,trac,..) are extremely slow from
one network and everything works fine from the other network.

Maybe it is some firewall issue somewhere on Apple side.
It would be great if somebody could investigate it.

br,
Ossy


Gyuyoung Kim írta:
Some my PCs also have same problem when using svn. I don't know why it 
is too slow suddenly.


Gyuyoung. 

On Tue, Aug 25, 2015 at 12:27 PM, 조진철 jincheol...@navercorp.com 
mailto:jincheol...@navercorp.com wrote:


Hi webkit-dev.


I am getting webkit full source through svn.
But the svn server is so slow that I cannot get it.
It looks like something wrong. 


WebKit-Git works as well.

Could anybody check it?

Thanks.
___

Jincheol Jo
Naver Labs / Software Engineer.

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

Re: [webkit-dev] Windows Build Now on VS2015

[Osztrogonác Csaba]

Hi,

On 2015-08-25 14:29, z...@falconsigh.net wrote:

On Tue, Aug 25, 2015, at 12:55 PM, Carlos Garcia Campos wrote:

El mar, 25-08-2015 a las 12:47 +0200, z...@falconsigh.net escribió:

On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote:

The days of supporting VS2013 are behind us, so if it works with
VS2015, go for it.  Not all c++14 features are supported, though.
  See
https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table

I’m not sure what the oldest gcc we support is.


The oldest GCC we support is 4.7.0.


Nope, we bumped it to 4.9.0 because of the bug in 4.8 that caused
failures in the database process implementation (see bug #98932).



The EFL port didn't, to the best of my knowledge.


EFL port already switched IndexedDB on by
https://trac.webkit.org/changeset/187596 ,
so we need at least GCC 4.9 since then.

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

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

[Osztrogonác Csaba]

Something is still wrong, the commit queue, the
style queue,the GTK and EFL EWS are down again.

Commit Queue
17 hours, 46 minutes ago
Status: Starting Queue
2 pending

Style Queue
5 hours, 35 minutes ago
Status: Stopping Queue, reason: Delegate terminated queue.
6 pending

Gtk WK2 EWS
35 minutes ago
Status: Idle
0 pending

Efl WK2 EWS
16 hours, 29 minutes ago
Status: Starting Queue
17 pending


Alexey Proskuryakov írta:


I tried running the style queue from command line, and it processed some 
patches, errored out on some others, and then hit a different error. 

I restarted the queue normally then, and it has processed all patches 
except for 
https://bugs.webkit.org/attachment.cgi?id=257920action=prettypatch 
https://bugs.webkit.org/attachment.cgi?id=257920action=prettypatch. 
We probably need to find a way to enable more logging to find the 
problem(s). Looks like the bot has trouble talking to bugzilla.


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

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard [Caution: Message contains Suspicious URL content]

[Osztrogonác Csaba]

Style queue is still down, otherwise everything looks good.

br,
Ossy

Aakash Jain írta:
The upgrade was a success!  EWS and the Flakiness Dashboard are running 
smoothly. Please reply to this thread if you notice any issues.


New urls are:
https://webkit-queues.webkit.org/
https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html

Thanks
Aakash

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

[webkit-dev] EWS is down

[Osztrogonác Csaba]

Hi All,

it seems EWS server is down - http://webkit-queues.appspot.com/

Error: Not Found
The requested URL / was not found on this server.

It would be great if somebody could check and fix it. Thanks.

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

[webkit-dev] build.webkit.org issue

[Osztrogonác Csaba]

Hi,

it seems build.webkit.org is unavailabe since yesterday 23:13:00 (UTC).
It would be great if somebody can check what happened. Thanks.

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

[webkit-dev] *.webkit.org network issues

[Osztrogonác Csaba]

Hi,

*.webkit.org sites (trac,bugs,build) are extremely slow
from here (Europe/Hungary) and I didn't get any bugzilla
mail 2 days ago, but I should have got many.

Is it a known issue and/or is anybody working on the fix?

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

Re: [webkit-dev] *.webkit.org network issues

[Osztrogonác Csaba]

Hi again,

it seems the ISP of my office or somebody else on the route
is responsible for slowness, I have ~10-20% packet loss. :(
(Everything works fine from home with 0-1% packet loss.)

Unfortunately I still don't get any bugzilla e-mail, but
I got all webkit-dev mails. (However I am subscribed to
webkit-dev with this mail address, but set the webkit.org
one in bugzilla - which is forwarded to this one.) Does
everything work fine on the Apple side? If yes, I'll
ping my email service provider.

br,
Ossy

Osztrogonác Csaba írta:

*.webkit.org sites (trac,bugs,build) are extremely slow
from here (Europe/Hungary) and I didn't get any bugzilla
mail 2 days ago, but I should have got many.

Is it a known issue and/or is anybody working on the fix?

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

Re: [webkit-dev] CMake dependency bump?

[Osztrogonác Csaba]

Hi,

Why would be helpful to stuck with a very old cmake version?
CMake 2.8.8 was released on 18th Apr 2012 (3 years ago), and
2.8.12 was released on 8th Oct 2013 (1.5 years ago). What is
the blocker issue why you can't use the newer cmake? Could
you explain the details? Wouldn't be easier to try to solve
the issue you ran into with the newer cmake?

As far as I know cmake isn't shipped with OS X, but please correct me
if I'm wrong. Installing a binary cmake or building it from source isn't
a big deal at all. Additionally what builds fine with 2.8.8, it should
build fine with 2.8.12 too, including LLVM too.

Otherwise is there an expected date when will cmake officially
supported by Apple with buildbots and EWS too? This cmake on Mac
project started near a year before, but unfortunately I can't see
too big effort from Apple contributors, only your occasionally patches.

I fully support to progress toward on this way if we can see
a real intentions to switch to cmake once in the future.

br,
Ossy

Alex Christensen írta:
It would be quite helpful to my CMake on Mac effort (which isn't 
complete yet) and the long-term CMaking of WebKit, JavaScriptCore, and 
in particular JSC's FTL to keep the CMake requirements the same as LLVM, 
which are 2.8.8 right now.  I know CMake has cool new features that I 
would also like to use, but I would oppose such a change right now if 
there is another way.


http://llvm.org/docs/CMake.html

Alex Christensen

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

Re: [webkit-dev] Please be careful with webkitpy changes!

[Osztrogonác Csaba]

Hi,

There are different issues here:
- EWS bots don't run webkitpy tests, except the Mac WK1 and WK2.
(running webkitpy tests is part of run tests) Maybe we should
run webkitpy tests on the non tester EWS bots too.

- poor webkitpy test coverage: Windows buildbots should have
noticed the mentioned failure after the patch landed.
(Or is it possible that Win EWS and buildbot have different config?)

- EWS can't check properly if a patch break its own code, because
it applies the patch and then do the build, test, etc - without
restarting the process. By this time most of the code are in the
memory, changing the code of a running process won't influence
the actual run. It isn't trivial to fix this issue, and I'm not
sure if it is so important.

This kind of issues are very rare and can be catched easily if the port
maintainers / gardeners are monitoring the EWS queues and buildbots
continuously, not only once a day or more rarely. Maybe we could add
a heartbeat feature to webkitbot. It could ping maintainers on IRC
or send an email if a buildbot or EWS is offline or the queue is too 
long for a while.


br,
Ossy

Maciej Stachowiak írta:
You said it did not detect the failure until many builds later. That 
seems bad. People expect EWS validation to happen on their bug, not out 
of band 10-13 builds later. Is there any way to fix this limitation? 
That seems better than asking people to remember exceptions about 
patches that EWS can't validate the normal way.




On Apr 1, 2015, at 9:29 PM, Brent Fulgham bfulg...@apple.com 
mailto:bfulg...@apple.com wrote:


The Windows EWS bots process patches fairly quickly. Once I corrected 
the problem today, it managed to process about 97 patches in about an 
hour.


I do think one bottleneck is due to individual EWS bots locking 
patches. The first bot to reach a patch locks the patch against other 
bots handling it. If the patch happens to be 'consumed' be a bot with 
some kind of problem (e.g., bad local configuration, a full disk 
drive, etc.), that patch will not be touched again --- even if the other 
eight EWS bots are sitting dormant.


Is there some other processing metric you are concerned about?

? Brent Fulgham - Apple Inc.



On Apr 1, 2015, at 2:26 PM, Maciej Stachowiak m...@apple.com 
mailto:m...@apple.com wrote:



Is it possible to make EWS start processing changes more promptly?

On Apr 1, 2015, at 12:42 PM, Brent Fulgham bfulg...@apple.com 
mailto:bfulg...@apple.com wrote:


Hi Everyone,

We lost Windows EWS coverage for the past 36 hours due to a very 
benign-appearing change to some webkitpy code. I haven't yet figured 
out why this particular set of changes caused the Windows bots to 
start failing, but it has to do with various differences between the 
Cygwin Python 2.7.8 build and the versions used on our other EWS bots.


This does not seem like something developers SHOULD have to worry 
about, but it's an unfortunately reality that they really do need to.


To make matters worse, the patch that introduced the problem passed 
EWS. This is because the EWS bots only really begin using changes to 
webkitpy when they restart processing (about once every 10-13 build 
iterations).


To help combat this problem, I'd like to request that when making 
changes to webkitpy, please keep an eye on the various EWS bots to 
make sure they continue processing. If they do start failing, please 
roll the patch back out and we can work together to resolve the issue.


I apologize for how manual and inconvenient this needs to be (at 
least for now), but keeping the EWS up and running is critical to 
the smooth function of this project.


If you have any questions, please don't hesitate to e-mail me or 
look for me on IRC.


Thanks!

-Brent

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

Re: [webkit-dev] Running new/modified tests on EWS bots

[Osztrogonác Csaba]

Hi,

I'd like this idea basically, it would be great
if you or somebody else could work on it.

One of my former collegue started to investigate the same
thing 1.5 years before, but it was lost among many tasks
with higher priorities. Feel free to reuse these bugs and
WIP patches: (or file new ones)
- https://bugs.webkit.org/show_bug.cgi?id=117831
- and bugs in its depends on list

In my opinion red tree and flakey tets could cause many
problems, because EWS is designed primarily for green tree.
But unfortunately only Mac (and now Win release) bots are green
almost all the time. I can't remember if EFL or GTK bots were
green in the last 1-2 years ever. :-/

Now the tester EWS bots (Mac WK1 and WK2) run all tests. If all tests
pass, there is no problem. But if there is only one failure, it tries
to build and run tests without the patch. If all tests pass, the patch
caused the regression. If there are exactly the same failures on the
trunk and with the patch, the bubble becomes green.

But flakey failures on the trunk can make EWS crazy. I remember that
EWS wasn't able to process any patch for days because of 1-2 flakey
failures on the trunk. If we enabled full or partial testing on
unstable EWSs, they would become very slow, unstable and we would
lost the very quick and stable builder EWSs. Maybe we should have
separated builder and builder-and-tester EWS bots to avoid this kind
of problems, but we would need more hardware for it.

Anyway it would be great if EFL and GTK maintainers could keep the
tester bots green almost all the time. I know it isn't an easy task
and would need more resource. I remember from the QtWebKit era that
1-2 full-time gardener can be enough to keep the tree green, but
it means only minor buildfixes, expected updates, new bug reports
and skipping/marking new failures time to time. To increase the
stabilility, fix regressions, decrease the number of skipped tests
would need much more resource.

Of course, I willingly help you, but unfortunately I don't have
too much time for this topic nowadays. But feel free to cc me
to related bugs and I'll try to help if I can.

br,
Ossy

youenn fablet írta:

Hi,

Related to the webkit contributor meeting discussion related to ports,
I would find it useful if EWS bots (gtk, efl, win, ios) were running
the tests that are modified/created by a patch.

The idea would be to turn yellow the port bubble whenever one of these
tests do not pass. Results would be uploaded to bugzilla.

This would give an incentive for patch developers to try fixing the
tests on these ports.
That may reduce (slightly? noticeably?) port maintainers gardening effort.
That would also be valuable when importing test suites.

Any potential issue? objection to move that forward?
Anyone willing to help? Thoughts?

Thanks,
   Youenn

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

Re: [webkit-dev] NEON_INTRINSICS

[Osztrogonác Csaba]

Hi,

unfortunately GCC doesn't set the necessary __ARM_NEON__ define even if
the CPU supports NEON instructions, we have to pass -mfpu=neon[-*] to
make sure __ARM_NEON__ is set properly. It was explicitly set on our ARM
bots for long time, but accidentally lost after a GCC toolchain update.
I added the switch back immediately after the mentioned buildfix landed,
so the EFL ARM bots now build with enabled NEON_INTRINSICS.

I think we could add a cmake configure script to check if
NEON is available and enable it depending on the result.

Of course all of these omtimizations were validated and performance
was measured before they were landed. I collected some of these bugs
and performance progressions are pretty good:

https://bugs.webkit.org/show_bug.cgi?id=103614
https://bugs.webkit.org/show_bug.cgi?id=102060
https://bugs.webkit.org/show_bug.cgi?id=101473
https://bugs.webkit.org/show_bug.cgi?id=100737
https://bugs.webkit.org/show_bug.cgi?id=98131
https://bugs.webkit.org/show_bug.cgi?id=90949
https://bugs.webkit.org/show_bug.cgi?id=86468
https://bugs.webkit.org/show_bug.cgi?id=59447
https://bugs.webkit.org/show_bug.cgi?id=54456

https://bugs.webkit.org/show_bug.cgi?id=94886
(It isn't intrinsic, but NEON optimization.)


The idea of having an ARM performance bot is good, but I'm not sure
if it can be done easily. One test on the x86_64 performance bots
take 2.5 hours. How long would it run on an ARM device?

br,
Ossy

Maciej Stachowiak írta:

Requiring a perf bot to be set up before removing unmaintained code seems like 
a really high bar. What would it take to do a one-shot test of whether 
NEON_INTRINSICS is a perf benefit? Would it show up on PLT or on JS perf 
benchmarks if you compiled with it? If it's not a speedup in its existing form, 
then it's probably not worth keeping around. If it is, then that might be 
incentive for someone to get it production-ready and on by default for relevant 
platforms.

Regards,
Maciej


On Mar 8, 2015, at 6:56 PM, Benjamin Poulain benja...@webkit.org wrote:

That code looks straightforward, the maintenance cost is likely low. We
just really need a test bot to run that code.

I suggest we wait until we have a ARMv7 perf bot and re-evaluate
NEON_INTRINSICS.

On 05/03/2015 22:27, Carlos Garcia Campos wrote:

Yesterday a patch was submitted to fix the build with NEON_INTRINSICS,
and Ossy pointed out that the build has been broken since r170433, and
nobody has noticed it until now. So that makes me wonder if anybody is
actually using that and if it even works, because otherwise we should
probably remove the NEON_INTRINSICS code. 


So, is there anybody actually using that (I guess patched downstream)?

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

Re: [webkit-dev] Unused parameter warnings / errors / warning fixes

[Osztrogonác Csaba]

Hi again,

it seems opinions are dived about how and what should we do.

I agree that turning on errors for unused parameter for Objective-C
files is undesirable, because we can't omit the parameter name.
Additionally it isn't easy (or maybe it is impossible) to build only
Objective-C sources with -Wno-unused-parameter setting.

I tried to add -Wno-unused-parameter COMPILER_FLAGS to the pbxproj
file for an Objective-C file, but unfortunately -Wall and -Wextra
in WARNING_CFLAGS in *.xcconfig files is stronger, because it is
added later to the compiler argument list.

First and last, I suggest that cmake ports should switch on error
for unused parameters except in WebKit2, where I propose simply
suppressing the warning. This would match the actual Mac settings.

I closed the original bug as wontfixed:
https://bugs.webkit.org/show_bug.cgi?id=140764

and filed a new bug report for cmake fix:
https://bugs.webkit.org/show_bug.cgi?id=142338

br,
Ossy


Osztrogonác Csaba írta:

I noticed many patches to fix newly introduced unused
parameter warnings on GTK and EFL ports nowadays.
(ToT EFL WebKit is warning free right now.)

CMake ports now handle unused parameters as warnings, not build
errors everywhere. (-Werror and -Wno-error=unused-parameter )
Mac port handles them as build errors, except in WebKit, WebKit2
and WebInspectorUI, where it is disabled (-Wno-unused-parameter)
WebInspectorUI  is warning free now, but there are zillion warnings
in WebKit and Webkit2.

It would be great if we can handle unused parameters in the same way:
- treat them as errors
- treat them as warnings and fix sometimes
- disable them and don't try to fix again and again
  (and maybe remove zillion UNUSED_PARAM warning fixes )

I played a little bit to see if it is possible to get rid these warnings
easily on Mac too and then handle the new ones as build failres:
https://bugs.webkit.org/show_bug.cgi?id=140764

But I'm not sure if treating unused parameters as errors would be good
idea, because many of them depend on different feature ifdef guards
and it might cause more frequent build failures. Maybe disabling them
would be better.

Ideas, opinions, concerns and suggestions are welcome.

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

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

[Osztrogonác Csaba]

Hi,

Now Apple Mac, GTK and EFL ports use bmalloc without any issue.

I noticed that Apple Windows port turned off FastMalloc 1.5 years
ago (r156933) due to some issues. Is there any plan to port bmalloc
to Windows too to use the same allocator on all ports?

br,
Ossy

Geoffrey Garen írta:

To help to go ahead, I upload a patch to enable bmalloc on EFL port as well as 
to remove TCMaclloc in CMake.


Thanks!

Geoff

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

Re: [webkit-dev] WinCairo 64-bit Bot Failures

[Osztrogonác Csaba]

Hi,

thanks for fixing the build issues.

It seems the WinCairo bot still has some issues, for example
- run-javascriptcore-tests step is killed after 20 minutes
  without producing any output. JSC test doesn't take so long,
  and it should produce output during run. Maybe build-jsc stucked
  for some reason. But why do you call it, when build-webkit also
  builds jsc.exe ?
- all of the bindings tests fail. I haven't seen any problem
  from the stdout, but maybe different end on lines cause
  this problem. How come it isn't problem on the Apple Win bots?

Are you planning to port run-webkit-tests to be able run layout tests
on this bot too and maintain expected files regularly? NRWT hasn't
supported WinCairo port ever, and there is no ORWT since r171967.

Now WinCairo can't run tests, so can we remove the 
LayoutTests/platform/wincairo/TestExpectations file?

It seems it is originated from the old Skipped file and
was touched many times by many contributors for nothing.

And please add your name and mail address to the admin field of
https://build.webkit.org/buildslaves/wincairo-1
(info/admin file near the tac file on the buildslave)

br,
Ossy

Alex Christensen írta:

I have access to that bot.  I was on vacation for several weeks, but I fixed it 
this morning.  Let me know if there are any more complaints about that bot.

Alex

On Jan 29, 2015, at 4:21 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:


Hi,

the bot is persistently broken due to the SVN errors since 3 days:
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release?numbuilds=200

Is it maintained by anybody? Or it is just to increase
the network traffic with continuous svn checkouts?

Please fix the bot or stop it not to increase
the network traffic and generate useless buildlogs.

br,
Ossy

Osztrogonác Csaba írta:

Hi,
is this brand new bot really maintained? I haven't
seen any green build, but zillion flakiness on it.
It seems the WinCairo bot still has many issues, for example:
- failed svn - still suffering with different magic errors:
svn: E120106: ra_serf: The server sent a truncated HTTP response body.
svn: E155009: Failed to run the WC DB work queue associated with 
'/home/webkitbot/win-cairo-release/build/LayoutTests/fast/encoding/resources', 
work item 6962 (file-install LayoutTests/fast/encoding/resources/099.html 1 0 1 
1)
svn: E02: Can't open file 
'/home/webkitbot/win-cairo-release/build/.svn/pristine/05/052b58d5be5cf247e2642516c4e4a6bd7211cf08.svn-base':
 No such file or directory
could not find 'svn'
...
- failed jscore tets
command timed out: 1200 seconds without output
- failed webkitpy tests
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitpy-test/logs/stdio
 - failes webkitperl tests
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitperl-test/logs/stdio
 - random failed compile webkit
detail can be found here:
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release?numbuilds=200
PS: It would be great to have admin name and mail here:
https://build.webkit.org/buildslaves/wincairo-1
br,
Ossy

___
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

Re: [webkit-dev] WinCairo 64-bit Bot Failures

[Osztrogonác Csaba]

Hi,

the bot is persistently broken due to the SVN errors since 3 days:
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release?numbuilds=200

Is it maintained by anybody? Or it is just to increase
the network traffic with continuous svn checkouts?

Please fix the bot or stop it not to increase
the network traffic and generate useless buildlogs.

br,
Ossy

Osztrogonác Csaba írta:

Hi,

is this brand new bot really maintained? I haven't
seen any green build, but zillion flakiness on it.

It seems the WinCairo bot still has many issues, for example:

- failed svn - still suffering with different magic errors:

svn: E120106: ra_serf: The server sent a truncated HTTP response body.

svn: E155009: Failed to run the WC DB work queue associated with 
'/home/webkitbot/win-cairo-release/build/LayoutTests/fast/encoding/resources', 
work item 6962 (file-install 
LayoutTests/fast/encoding/resources/099.html 1 0 1 1)
svn: E02: Can't open file 
'/home/webkitbot/win-cairo-release/build/.svn/pristine/05/052b58d5be5cf247e2642516c4e4a6bd7211cf08.svn-base': 
No such file or directory


could not find 'svn'

...

- failed jscore tets
command timed out: 1200 seconds without output

- failed webkitpy tests
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitpy-test/logs/stdio 



- failes webkitperl tests
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitperl-test/logs/stdio 



- random failed compile webkit

detail can be found here:
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release?numbuilds=200

PS: It would be great to have admin name and mail here:
https://build.webkit.org/buildslaves/wincairo-1

br,
Ossy

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

Re: [webkit-dev] WinCairo 64-bit Bot Failures

[Osztrogonác Csaba]

Hi,

is this brand new bot really maintained? I haven't
seen any green build, but zillion flakiness on it.

It seems the WinCairo bot still has many issues, for example:

- failed svn - still suffering with different magic errors:

svn: E120106: ra_serf: The server sent a truncated HTTP response body.

svn: E155009: Failed to run the WC DB work queue associated with 
'/home/webkitbot/win-cairo-release/build/LayoutTests/fast/encoding/resources', 
work item 6962 (file-install 
LayoutTests/fast/encoding/resources/099.html 1 0 1 1)
svn: E02: Can't open file 
'/home/webkitbot/win-cairo-release/build/.svn/pristine/05/052b58d5be5cf247e2642516c4e4a6bd7211cf08.svn-base': 
No such file or directory


could not find 'svn'

...

- failed jscore tets
command timed out: 1200 seconds without output

- failed webkitpy tests
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitpy-test/logs/stdio

- failes webkitperl tests
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/43365/steps/webkitperl-test/logs/stdio

- random failed compile webkit

detail can be found here:
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release?numbuilds=200

PS: It would be great to have admin name and mail here:
https://build.webkit.org/buildslaves/wincairo-1

br,
Ossy

Brent Fulgham írta:

Hi Everyone,

It looks like the WinCairo 64-bit bot is having some trouble due to the 
dread Cygwin rebaseline requirement:


Could someone with bot access please take the bot down and rebaseline it?

These (annoying) failures are one of the reasons I've been trying to get 
the build to work outside of Cygwin. (Patches welcome!)


Thanks,

-Brent

3-- Build started: Project: JavaScriptCoreGenerated, Configuration: 
Release_WinCairo Win32 --
3  /usr/bin/bash
3   touch %ConfigurationBuildDir%\buildfailed
3   perl build-generated-files.pl %ConfigurationBuildDir% 
C:\cygwin\home\webkitbot\win-cairo-release\build\WebKitLibraries\win 
%PlatformArchitecture%
3  echo 
'/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/ApplicationCache.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/CSS.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Console.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOM.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMDebugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMStorage.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Database.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Debugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/GenericTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Inspector.json
 /home/webkitbot/win-

cairo-release/build/Source/JavaScriptCore/inspector/protocol/LayerTree.json 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Network.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/OverlayTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Page.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Runtime.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Timeline.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Worker.json
 ' | cmp -s - EnabledInspectorDomains || echo 
'/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/ApplicationCache.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/CSS.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Console.json
 /home/webkitbot
/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOM.json 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMDebugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMStorage.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Database.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Debugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/GenericTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Inspector.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/LayerTree.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Network.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/OverlayTypes.json
 

[webkit-dev] Unused parameter warnings / errors / warning fixes

[Osztrogonác Csaba]

Hi all,

I noticed many patches to fix newly introduced unused
parameter warnings on GTK and EFL ports nowadays.
(ToT EFL WebKit is warning free right now.)

CMake ports now handle unused parameters as warnings, not build
errors everywhere. (-Werror and -Wno-error=unused-parameter )
Mac port handles them as build errors, except in WebKit, WebKit2
and WebInspectorUI, where it is disabled (-Wno-unused-parameter)
WebInspectorUI  is warning free now, but there are zillion warnings
in WebKit and Webkit2.

It would be great if we can handle unused parameters in the same way:
- treat them as errors
- treat them as warnings and fix sometimes
- disable them and don't try to fix again and again
  (and maybe remove zillion UNUSED_PARAM warning fixes )

I played a little bit to see if it is possible to get rid these warnings
easily on Mac too and then handle the new ones as build failres:
https://bugs.webkit.org/show_bug.cgi?id=140764

But I'm not sure if treating unused parameters as errors would be good
idea, because many of them depend on different feature ifdef guards
and it might cause more frequent build failures. Maybe disabling them
would be better.

Ideas, opinions, concerns and suggestions are welcome.

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

Re: [webkit-dev] Proposal: Removing ENABLE(INSPECTOR) guards

[Osztrogonác Csaba]

Osztrogonác Csaba írta:

Inspector is enabled by default on all major WebKit port and
the build without inspector isn't really maintained by anyone.

Building without inspector can be useful on an embedded system where
you don't need it, but it only reduces the binary code size with ~3%.
It isn't so much, but the maintenance cost can be much more bigger.

I propose removing ENABLE(INSPECTOR) guards to reduce maintenance cost.


I've prepared the patch to remove the guards: 
https://bugs.webkit.org/show_bug.cgi?id=140668

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

[webkit-dev] Proposal: Removing ENABLE(INSPECTOR) guards

[Osztrogonác Csaba]

Hi All,

Inspector is enabled by default on all major WebKit port and
the build without inspector isn't really maintained by anyone.

Building without inspector can be useful on an embedded system where
you don't need it, but it only reduces the binary code size with ~3%.
It isn't so much, but the maintenance cost can be much more bigger.

I propose removing ENABLE(INSPECTOR) guards to reduce maintenance cost.

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

Re: [webkit-dev] EFL EWS bot failures [Caution: Message contains Suspicious URL content]

[Osztrogonác Csaba]

EFL EWS is down since 16.5 hours. Any news about the upgrade?

Gyuyoung Kim írta:

Now I'm trying to replace a poor performance machine with new one.
I hope EFL EWS bot will be fine soon.

Thank you for your notification.
Gyuyoung.

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

Re: [webkit-dev] EFL EWS bot failures

[Osztrogonác Csaba]

Hi Gyuyoung,

thanks for fixing the bots.

I noticed similar problem on the EFL EWS and buildbot many times.
Unfortunately it can cause not only orange bubbles, but false
positive redness too.

I saw the same error long long time ago locally, and the reason
was OOM on one of an overloaded icecc slave many times. And once
a memory module error caused the same error.

Nowadays I noticed another strange error on the EFL buildbot (2 or 3
times):  kill old processes buildstep stucked in an infinite loop
and killed after the 20 minutes timeout for several builds.

Is there any chance to check and fix/replace the hardware of
the EFL EWS and buildbot to make it as stable as previously?

br,
Ossy

Gyuyoung Kim írta:

Hello Darin,

I'm sorry for the inconvenience about that. EFL EWS seems to work again.

Gyuyoung.

On Fri, Jan 9, 2015 at 4:02 AM, Darin Adler da...@apple.com 
mailto:da...@apple.com wrote:


A lot of times recently the EFL bot has reported a failure that
shows up as an orange bubble:

c++: internal compiler error: Killed (program cc1plus)

Like in this bug https://bugs.webkit.org/show_bug.cgi?id=140166.
What's going on with that? Is there someone who can fix it?

--- Darin

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

Re: [webkit-dev] Test result updates today

[Osztrogonác Csaba]

Just a note: the Windows bot exits early long long time ago
due to too many crashes and timeouts. Additionally there
many failures too, for example almost all regions tests
fail with minor pixel differences.

Myles C. Maxfield írta:

Whoops - this time from the right email address.

Thanks,
Myles

On Dec 27, 2014, at 10:26 AM, litherum lithe...@gmail.com wrote:


Hello all! I will be rebasing results for all of our Mac + iOS + Windows tests 
today. The tree might be red for part of the day. I will post in this thread to 
keep everyone updated with this large update.

The goal of this project is to turn on kerning, ligatures, and printer fonts in 
our tests for these platforms.

Thanks,
Myles

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

[webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

[Osztrogonác Csaba]

Hi all,

it seems ENABLE(SQL_DATABASE) is enabled on all ports,
but there are still ifdef guards for it in 300+ files.

Is there anybody shipping WebKit with disabled SQL_DATABASE?
If no, I'd propopse removing these guards.

br,
Ossy

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

Re: [webkit-dev] review times

[Osztrogonác Csaba]

Hi,

30 days waiting isn't so long. :)

I think our Guinness Recorder is bug110978, the first
patch was uploaded 21 months before. And then were updated
to the top of trunk many times, because WK2 owners doesn't
have time to review the refactoring they explicitly requested.

I always wonder if a reviewer can review a 200-300K sized
patch of his/her co-worker in 5 minutes, but don't have
time for a 20-30K sized patch in a month/year/decade/century.

http://webkit.org/pending-review - 444 patches in the queue
Shouldn't we decrease this huge number?

PS: bug138971 wasn't unreviewed, check the history:
https://bugs.webkit.org/show_activity.cgi?id=138971

br,
Ossy

Daniel Lazarenko írta:
Hello,  


I've made a patch for a bug # 137299, and it's been waiting for review for more 
than 30 days now. The responsible reviewer from Apple is too busy to review. On 
the other hand there are patches sent by Apple employees and committed after 2 
hours without any review ( for example # 138971 ). This looks very unfair to 
me. I was always thinking that open source projects are open to changes and 
collaboration. There should be some rules for such cases when only one person 
can review, but he/she is so busy that practically it's not going to happen.

Whatsoever it would be nice find a new reviewer for my patch. Does anybody want 
to take it?

--
With best regards,
Daniel Lazarenko
Developer
Opera Software ASA

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

Re: [webkit-dev] Status of WinCairo buildbot?

[Osztrogonác Csaba]

I prepared the patch removes the unused bot:
https://bugs.webkit.org/show_bug.cgi?id=138805

If you would like to setup your own bot in the future,
just revert that patch. ( except the wx and qt cruft :) )

Alex Christensen írta:
I've talked to the maintainers, and they have stopped maintaining that bot. I wanted to make my own bot, but I probably won't get around to it for a few more weeks. Go ahead and remove it, but cc me so I can do the inverse once I get time to set up my bot. 


Alex


On Nov 17, 2014, at 9:16 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:

Hi,

it seems the WinCairo buildbot is offline since a months:
https://build.webkit.org/builders/WinCairo%20Release?numbuilds=200

And it had been continuosly red before it went offline,
at least since 1st October.

Is there anybody maintains / interested in maintaining this bot?
If no, I propose removing it from https://build.webkit.org/ .

br,
Ossy

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

[webkit-dev] Status of WinCairo buildbot?

[Osztrogonác Csaba]

Hi,

it seems the WinCairo buildbot is offline since a months:
https://build.webkit.org/builders/WinCairo%20Release?numbuilds=200

And it had been continuosly red before it went offline,
at least since 1st October.

Is there anybody maintains / interested in maintaining this bot?
If no, I propose removing it from https://build.webkit.org/ .

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

Re: [webkit-dev] Disk cache

[Osztrogonác Csaba]

Apple dropped Windows WebKit2 port long long time ago:
https://bugs.webkit.org/show_bug.cgi?id=105585 and as
far as I remember NetworkProcess didn't have Windows
support ever. So it isn't an easy task. Not at all.

br,
Ossy

On 2014-11-03 19:38, Brent Fulgham wrote:

I wonder if we could easily modify the Windows port to make use of a
Network process.

-Brent


On Nov 3, 2014, at 8:07 AM, Anders Carlsson ander...@apple.com
mailto:ander...@apple.com wrote:



On Nov 3, 2014, at 12:22 AM, Benjamin Poulain benja...@webkit.org
mailto:benja...@webkit.org wrote:



I believe it would be better to enable the network process for all
process models. Maintaining multiple configurations for marginal
gains is not sustainable, especially in the network stack.


I agree 100%. Not to mention that we also want to get rid of the
“single web process” code path, and just make it a special case of
having multiple web processes with a maximum process cap of 1.

- Anders

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

Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

[Osztrogonác Csaba]

Hi,

On 2014-10-17 12:42, Sergio Villar Senin wrote:

Could the format of bz emails be changed? The new one with those huge
tables on top and tiny fonts for the bug comments are pretty difficult
to process.


You can change the Preferred email format to text only here:
https://bugs.webkit.org/userprefs.cgi?tab=settings

I already did it. ;)

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

Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

[Osztrogonác Csaba]

Hi,

have you tried if the webkit-patch bugzilla tool (upload,
apply-attachment, apply-from-bug, ... ), the review tool,
the commit queue and EWS will work properly with the new
bugzilla version?

I think they are very fragile and highly rely on the generated
HTML forms. I prefer fixing these tools before updating to
breaking them and then trying to fix.

Just out of curiosity, if we do an upgrade, why do we upgrade
to the old stable release (4.2.11), why not the latest stable
relase (4.4.6)? Is there a fundamental reason for it?

There are many good fixes in 4.4 release. If we can't upgrade
to 4.4 for some reason, it would be great to cherry-pick at
least the following changes:

It is now possible to add yourself to the CC list when uploading an 
attachment and when editing an existing one. (note)

-- auto cc reviewer - https://bugs.webkit.org/show_bug.cgi?id=124047 )

Changes to the CC list no longer causes midair collisions. (note)
-- It is very annoying if you are commenting a bug, and you
have to start it again if somebody else cc-ed him/herself.
Or if you clicked force, it would remove these new cc-s.

And one more question: Are you planning to check-in
the new bugzilla to Websites/bugs.webkit.org ?

(note): http://www.bugzilla.org/releases/4.4/release-notes.html#v44_feat

br,
Ossy

David Kilzer írta:

Hi,

We’re planning on upgrading Bugzilla (bugs.webkit.org 
http://bugs.webkit.org/) from 3.2.3 to 4.2.11 on Thursday, October 16 
from 8-10 AM PDT x-apple-data-detectors://1.


Sorry for the short notice.  I sent this message from the wrong address, 
and didn't see he bounce message until now.


Please let me know if you have questions or concerns.  Thanks!

Dave

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

[webkit-dev] Apple Windows EWS bots having issues (again)

[Osztrogonác Csaba]

Hi All,

it seems the Apple Windows EWS doesn't work at all since 4 days
after http://trac.webkit.org/changeset/174315 , because it can't
find the generated JSInternals.h and cpp. Maybe they aren't
generated, but it's hard to determine without full logs.

I filed a bug report for it 2 days before, but the EWS is
still broken: https://bugs.webkit.org/show_bug.cgi?id=137450

Will the bot maintainers have a chance to look into this bug?

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

Re: [webkit-dev] error when building javascriptcore without inspector

[Osztrogonác Csaba]

There are some errors with TypeSet when building javascriptcore with 
ENABLE_INSPECTOR=0. Could anyone please fix this?

It is fixed by https://bugs.webkit.org/show_bug.cgi?id=136912,
but the patch is waiting for review now.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Subject: Windows CE port in WebKit: status, future work

[Osztrogonác Csaba]

Hi,

Patrick Gansterer írta:

On 31.01.2014, at 22:10, Anders Carlsson ander...@apple.com wrote


looks like the last legitimate commit to the Windows CE port was on November 
3rd November 2013, almost 3 months ago.


What's the minimum upstream interval for downstream fixes to show ongoing 
activity?


I also seem to remember that there's no version of MSVC for Windows CE that can 
handle the C++11 features that we now use in WebKit. (Correct me if I'm wrong 
on this!)


Windows Embedded Compact 2013 updated the compiler for CE.


With this in mind, does it make sense to keep the Windows CE port in the tree 
or should we remove it?


Does it hurt somebody in the daily workflow? If yes, where exactly?
I'm still working on getting rid of WebKit/wince by merging it into WebKit/win 
(with only a few #if WINCE) to reduce the impact of the WinCE port, but it's 
hard if there is nobody who finds time for reviewing patches. :-/ (e.g. 
webkit.org/b/119518 or webkit.org/b/123803 waiting for months - but I don't 
want to blame somebody by this!)


The last commit from WinCE maintainer was on 20th November 2013,
9 months ago - https://trac.webkit.org/changeset/159534

Since then other contributors landed 41 changes touched WinCE files:
https://trac.webkit.org/search?q=wincenoquickjump=1changeset=on

Do we have any benefit if we keep these crufts in the trunk?

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

Re: [webkit-dev] ftlopt merge - basically done

[Osztrogonác Csaba]

It works fine with EFL port on x86_64 Linux.

You only need the following things: (on Ubuntu 14.04!)
 - apply the patch from https://bugs.webkit.org/show_bug.cgi?id=133571
 - run sudo Tools/efl/install-dependencies
 - run WEBKIT_EXTRA_MODULES=llvm Tools/Scripts/update-webkitefl-libs
 - run Tools/Scripts/build-webkit --efl --ftl-jit

Yong Li írta:

Has anyone managed to make an FTL build on Linux?

Yong Li

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

[webkit-dev] Mac WK1 EWS bots having issues

[Osztrogonác Csaba]

Hi,

it seems the Apple Mac WK1 EWS bots have problems:
http://webkit-queues.appspot.com/queue-status/mac-ews

Last Pass: 11 hours, 57 minutes ago by webkit-ews-01
Unable to pass tests without patch (tree is red?)

Regressions: Unexpected text-only failures (30)
  compositing/plugins/composited-plugin.html [ Failure ]
  compositing/plugins/no-backing-store.html [ Failure ]
  compositing/plugins/small-to-large-composited-plugin.html [ Failure ]
  fast/frames/sandboxed-iframe-about-blank.html [ Failure ]
  fast/frames/sandboxed-iframe-navigation-allowed.html [ Failure ]
  fast/frames/sandboxed-iframe-plugins.html [ Failure ]
  fast/replaced/invalid-object-with-fallback.html [ Failure ]
  fullscreen/full-screen-plugin.html [ Failure ]
  http/tests/plugins/create-v8-script-objects.html [ Failure ]
  http/tests/plugins/cross-frame-object-access.html [ Failure ]
  http/tests/plugins/get-url-beforeunload-destroys-plugin.html [ Failure
  platform/mac/plugins/convert-point.html [ Failure ]
  platform/mac/plugins/supports-carbon-event-model.html [ Failure ]
  platform/mac/plugins/testplugin-onnew-onpaint.html [ Failure ]
  plugins/destroy-during-npp-new.html [ Failure ]
  plugins/destroy-plugin-from-callback.html [ Failure ]
  plugins/npruntime/browser-object-identity.html [ Failure ]
  plugins/npruntime/construct.html [ Failure ]
  plugins/npruntime/delete-plugin-within-invoke.html [ Failure ]
  plugins/npruntime/embed-property-equality.html [ Failure ]
  plugins/npruntime/embed-property-iframe-equality.html [ Failure ]
  plugins/npruntime/embed-property.html [ Failure ]
  plugins/npruntime/enumerate.html [ Failure ]
  plugins/npruntime/evaluate.html [ Failure ]
  plugins/npruntime/get-int-identifier-special-values.html [ Failure ]
  plugins/npruntime/get-property-return-value.html [ Failure ]
  plugins/npruntime/identifier-conversion.html [ Failure ]
  plugins/npruntime/invoke-browserfuncs.html [ Failure ]
  plugins/npruntime/invoke-default.html [ Failure ]
  plugins/npruntime/invoke.html [ Failure ]

It's so strange, because all (8) of the Mac WK1 EWS suffer
from this issue, but there isn't any failure on the buildbots.
How is it possible? I thought the buildbots and EWS bots
have exactly the same configuration.

Maybe https://trac.webkit.org/changeset/172608 is the culprit,
because there weren't any other relevant patch that time.

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

Re: [webkit-dev] ftlopt merge - basically done

[Osztrogonác Csaba]

Hi Filip,

the latest part of ftlopt branch merge made some performance
tests crash everywhere. I filed a bug report with the details:
https://bugs.webkit.org/show_bug.cgi?id=135750

Could you possible fix this regression?

br,
Ossy

Filip Pizlo írta:

Hi everyone,

The JSC ftlopt branch is basically merged.  I think I have one more revision 
to merge over, and it is a minor one.  Please don't land more things on the branch.  
Landing on trunk is fine; it's unlikely to get in my way as I merge the last revision 
over.

Thanks to everyone who helped with diagnostic problems and fixing things!

-Filip

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

Re: [webkit-dev] Heads up: Incremental build issue on cmake (GTK/EFL) ports

[Osztrogonác Csaba]

Of course, I used the Force Clean build checkbox on
build.webkit.org as you mentioned. ;) So the buildbots
are happy now.

I sent this mail to let the developers know what should
they do if they run into this problem on local builds.

But unfortunately we aren't able to clean the EFL EWS,
only its maintainer can do it. Gyuyoung, could you kick
this bot please? (It seems GTK guys already fixed their EWS)

br,
Ossy

Ryosuke Niwa írta:
You should be able to trgger clean builds on build.webkit.org 
http://build.webkit.org once you login.  Or are you talking about 
downstream bots GTK/EFL bots?


On Wednesday, August 6, 2014, Osztrogonác Csaba o...@inf.u-szeged.hu 
mailto:o...@inf.u-szeged.hu wrote:


Hi,

r171961 changed the path of the generated inspector files (because
of r171942) from WebKitBuild/Release/__DerivedSources/JavaScriptCore
to WebKitBuild/Release/__DerivedSources/JavaScriptCore/__inspector

But unfortunately the old generated files remained in the old
path which caused the following strange incremental build error
after r172129:

In file included from

/home/oszi/webkit/Source/__JavaScriptCore/inspector/__agents/InspectorAgent.h:35:0,
 from

/home/oszi/webkit/Source/__JavaScriptCore/inspector/__JSGlobalObjectInspectorControl__ler.cpp:35:

/home/oszi/webkit/WebKitBuild/__Release/DerivedSources/__JavaScriptCore/__InspectorJSBackendDispatchers.__h:89:18:
note:virtual void

Inspector::__InspectorRuntimeBackendDispatc__herHandler::__getRuntimeTypeForVariableInTex__tRange(Inspector::ErrorString*__,
const WTF::String, const WTF::String, int, int, int, int,
WTF::String*)

To solve this problem, you should simple remove the following files
from WebKitBuild/Release/__DerivedSources/JavaScriptCore:
InspectorJSBackendDispatchers.__cpp
InspectorJSBackendDispatchers.__h
InspectorJSFrontendDispatchers__.cpp
InspectorJSFrontendDispatchers__.h
InspectorJSTypeBuilders.cpp
InspectorJSTypeBuilders.h

I triggered clean build on the buildbots to fix this issue, but
these files should be removed on the GTK and EFL EWS bots too.

br,
Ossy
_
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/__mailman/listinfo/webkit-dev
https://lists.webkit.org/mailman/listinfo/webkit-dev



--
Ryosuke Niwa




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

[webkit-dev] Heads up: Incremental build issue on cmake (GTK/EFL) ports

[Osztrogonác Csaba]

Hi,

r171961 changed the path of the generated inspector files (because
of r171942) from WebKitBuild/Release/DerivedSources/JavaScriptCore
to WebKitBuild/Release/DerivedSources/JavaScriptCore/inspector

But unfortunately the old generated files remained in the old
path which caused the following strange incremental build error
after r172129:

In file included from 
/home/oszi/webkit/Source/JavaScriptCore/inspector/agents/InspectorAgent.h:35:0,
 from 
/home/oszi/webkit/Source/JavaScriptCore/inspector/JSGlobalObjectInspectorController.cpp:35:
/home/oszi/webkit/WebKitBuild/Release/DerivedSources/JavaScriptCore/InspectorJSBackendDispatchers.h:89:18: 
note: 	virtual void 
Inspector::InspectorRuntimeBackendDispatcherHandler::getRuntimeTypeForVariableInTextRange(Inspector::ErrorString*, 
const WTF::String, const WTF::String, int, int, int, int, WTF::String*)


To solve this problem, you should simple remove the following files
from WebKitBuild/Release/DerivedSources/JavaScriptCore:
InspectorJSBackendDispatchers.cpp
InspectorJSBackendDispatchers.h
InspectorJSFrontendDispatchers.cpp
InspectorJSFrontendDispatchers.h
InspectorJSTypeBuilders.cpp
InspectorJSTypeBuilders.h

I triggered clean build on the buildbots to fix this issue, but
these files should be removed on the GTK and EFL EWS bots too.

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

[webkit-dev] Mac WK2 EWS bots having issues

[Osztrogonác Csaba]

Hi,

It seems the Mac WK2 EWS bots are very flakey nowadays, they set cq-
and comment bugzilla due to false positive media/* test failures.

Is there any volunteer for fixing them?

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

Re: [webkit-dev] Comment on the bug email author/reviewer before reverting a patch

[Osztrogonác Csaba]

Ryosuke Niwa írta:
Well, providing details in the bug would essentially email the author  
the reviewer since they're auto cc'ed.  I agree commenting on the 
Bugzilla is better so that others could follow.


No, reviewers aren't auto cc'ed to bugs if they only used review patch
and they wasn't added to cc list explicitly due to a bugzilla bug.

I started investigating this bug more than half year before:
https://bugs.webkit.org/show_bug.cgi?id=124047

Unfortunately I don't have any chance to test my bugzilla patch without
local bugzilla setup. I willingly continue this fix if I get some help
from somebody who has the power to test any bugzilla patch.

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

[webkit-dev] commit queue stucked

[Osztrogonác Csaba]

Hi All,

it seems WebKit commit queue is stucked, because the last pass was
14 hours ago: http://webkit-queues.appspot.com/queue-status/commit-queue

All patch fails with Unable to build without patch [results] message:
/Volumes/Data/EWS/WebKit/Source/WebKit2/Shared/API/Cocoa/WKFoundation.h:58:19: 
error: typedef redefinition with different types ('NSInteger' (aka 
'long') vs 'NSURLSessionAuthChallengeDisposition')

typedef NSInteger NSURLSessionAuthChallengeDisposition;
  ^

I have no idea how is it possible, because buildbots are
green and this build failure was fixed 9 hours ago: 
http://trac.webkit.org/changeset/170166


Could you possibly check what happend with CQ bots?

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

Re: [webkit-dev] EFL bots for ARM architecture - update

[Osztrogonác Csaba]

Hi All,

WebKit hackers from University of Szeged are still on the board,
and we are committed to having better WebKit on ARM Linux.

We migrated the two builder bots to http://build.webkit.org/waterfall :
- EFL Linux ARMv7 Thumb2 Release (Build)
- EFL Linux ARMv7 Traditional Release (Build)

Additionally we managed to setup JSC tester bots for ARM and Thumb2,
temporarily on http://build.webkit.sed.hu/waterfall , because they
need some special config which doesn't work with the official master.cfg
(cross compiling on x86, wrap the jsc by a script which run tests via
ssh connection on an ARM development board, ...)

One more thing: Gábor managed to setup an ARM64 build only bot,
which can be found here: http://build.webkit.sed.hu/waterfall
We are planning to run JSC tests on this bot too, once there
is ARM64 Linux development board available.

Ossy

Gabor Rapcsanyi írta:

Hello WebKittens,

I would like to annonunce our fresh new EFL Linux bots for ARM 
architecture. If you are interested, you can find them at: 
http://build.webkit.sed.hu/waterfall


The bots:
 - EFL ARMv7 Linux Release (Build)
 - EFL ARMv7 Traditional Linux Release (Build)

These bots are just builders but we are also planning to support jscore 
and layout testing as well later.


Regards,
Gabor Rapcsanyi

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

Re: [webkit-dev] Is anyone using the LevelDB backend to IndexedDB?

[Osztrogonác Csaba]

Darin Adler írta:

On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa rak...@webkit.org wrote:


Sam Weinig wei...@apple.com writes:


Hello,

Is anyone using the LevelDB backend to IndexedDB?

The EFL and GTK+ ports are.


Are you sure?

Since the GTK+ port is now WebKit2-only, then it can't be using the LevelDB 
back end at this time, because I believe nobody has made it work in WebKit2 yet.

--- Darin


IndexedDB only works with DatabaseProcess on WebKit2 and
DatabaseProcess is Mac-only now, so neither GTK nor EFL
can use LevelDB and IndexedDB on WebKit2.

And it seems EFL is planning to disable LevelDB support
on WebKit1 too - https://bugs.webkit.org/show_bug.cgi?id=132176

If nobody uses LevelDB, shouldn't we get rid everything related
to it from the trunk? (cmake, obxproj, vcxproj project files, sources)

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

Re: [webkit-dev] DerivedSources.make: Another try?

[Osztrogonác Csaba]

Hi,

as for me, I always support changes to reduce maintenace burden. I
remember that derivedsources caused problems many times in the past.
Adding a new non trivial source generator to each build system can
be a really hard task, and keeping them in sync weren't succesful
always.

Now I don't see how can we make cmake to use DerivedSources.make
properly, but let's investigate it a little bit. I think the
easiest thing is to make cmake to call make DerivedSources.make,
but propagating the generated files back to cmake to be able
generate correct dependency for sources includes generated
headers might be not so easy.

I filed a meta bug, feel free to cc yourself if you intereseted in it:
[meta] Make cmake build system use DerivedSources.make
https://bugs.webkit.org/show_bug.cgi?id=130339

In my opinion WebKit2/DerivedSources.make is the simplest, JSC is
complex a little bit and WebCore is the biggest and most complex.

I'm going to experiment a little bit with WebKit2
and let's continue this discussion few days later.

Ossy

Darin Adler írta:

Hi folks.

Long ago I tried to make the derived sources part of building WebKit use a 
makefile, something for gnu make that we could use on multiple platforms. In WebCore, at 
least, we are using this DerivedSources.make from the Xcode project and the Windows 
project, but not for other build systems. I was hoping we could change that so that 
everyone uses DerivedSources.make. The build systems would do the main job of compiling 
code and header dependency and all that, but for the trickier, more project-specific job 
of running our scripts to make various types of derived sources we could just share one 
makefile.

With GTK moving from automake to CMake, it's possible we have the opportunity 
to achieve this just by making the CMake build system use DerivedSources.make 
instead of rules inside CMake itself.

Is there an expert on our use of CMake who is interested in trying this project?

Side question: With the recent GTK port developments, is it time to remove our 
automake files entirely?

--- Darin

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

[webkit-dev] bugzilla upgrade - previously: *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

In my opinion bugzilla upgrade is risky, because
webkit-patch extremely relies on html pages of
bugzilla. Any change might broke everything.

Additionally WebKit's bugzilla has several changes,
for example the review tool, EWS status bubbles, etc.

I'm not against upgrading, but if we do it, we have to be very careful.

Ossy

Philippe Normand írta:

BTW I've been wondering if a Bugzilla upgrade is planned?

We currently use 3.2.3 but the latest release seems to be 4.2.

If at least we could have a nice CSS like in bugzilla.mozilla.org it'd
be great :)

Philippe

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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

Hi,

There are still issues after downtime:

- Apple EWS bots are still broken (Last Pass: 1 day, 16 hours ago)
- login on build.webkit.org is broken:
The username or password you entered were not correct. Please go back 
and try again.


Ossy

Lucas Forschler írta:
FYI, I'm currently working on fixing the commit queue and the EWS bots.  
Lucas

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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

It seems the whole authentication is broken (except bugs.webkit.org),
because commit to svn.webkit.org is broken too. :-/

On 03/13/2014 11:25 AM, Sergio Villar Senin wrote:

En 13/03/14 09:56, Osztrogonác Csaba escribiu:

Hi,

There are still issues after downtime:

- Apple EWS bots are still broken (Last Pass: 1 day, 16 hours ago)
- login on build.webkit.org is broken:
The username or password you entered were not correct. Please go back
and try again.


I'd add:

- login on the Wiki is not possible either (Internal Server Error).


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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

Hi,

The Apple owned style queue and feeder queue bots are still broken.

I started a style queue and a feeder queue bot on one of our machine
until fixing the issues caused by the downtime. Now there isn't any
pending task in the style queue and patches are automatically submitted
to EWS, you don't have to push submit to EWS button manually.

Unfortunately the broken webkit-misc-style sometimes tries to pick up
a patch from the queue and holds their lock forever. :-/ In this
case I have to remove the patch from the queue, submit it to the
queue again and trust if my style bot is faster then the broken one.

Is it possible to shut down the webkit-misc-style but until proper fix?

Thanks,
Ossy

On 03/13/2014 09:56 AM, Osztrogonác Csaba wrote:

There are still issues after downtime:

- Apple EWS bots are still broken (Last Pass: 1 day, 16 hours ago)
- login on build.webkit.org is broken:
The username or password you entered were not correct. Please go back
and try again.


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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

Hi,

something is still wrong with trac.webkit.org, because it thinks
that the newest commit is http://trac.webkit.org/changeset/165452 ,
but the newest is r165460.

Could you check what happened? Thanks.

Ossy

Lucas Forschler írta:

Hello Webkit developers,

Apple will be upgrading our network infrastructure starting Tuesday morning at 
8am.
The webkit.org services will be affected for approximately 4 hours.

This includes all *.webkit.org domains.  We expect them to be back online 
before 12.

Thanks,
Lucas


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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

Additionally git.webkit.org is stucked too on r165452.

Osztrogonác Csaba írta:

Hi,

something is still wrong with trac.webkit.org, because it thinks
that the newest commit is http://trac.webkit.org/changeset/165452 ,
but the newest is r165460.

Could you check what happened? Thanks.

Ossy

Lucas Forschler írta:

Hello Webkit developers,

Apple will be upgrading our network infrastructure starting Tuesday 
morning at 8am.

The webkit.org services will be affected for approximately 4 hours.

This includes all *.webkit.org domains.  We expect them to be back 
online before 12.


Thanks,
Lucas


___
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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

Frédéric WANG írta:

git seems to work now, thanks.

However, http://trac.webkit.org/changeset is now blocked at revision 
165462.

Maybe the post commit hook is still broken.

For some reason, 165462 does not appear on 
http://build.webkit.org/console but 165463 and 165464 are visible there.


Because r165462 wasn't committed to trunk, but 
releases/WebKitGTK/webkit-2.4 branch. It isn't bug.


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

Re: [webkit-dev] Heads-up: rollout changelog format change

[Osztrogonác Csaba]

Hi Filip,

On 03/11/2014 06:43 PM, Filip Pizlo wrote:

On Mar 11, 2014, at 6:44 AM, Eva Balazsfalvi
evab.u-sze...@partner.samsung.com
mailto:evab.u-sze...@partner.samsung.com wrote:


Dear WebKit developers,

It's just a heads-up to let you know that rollout changelog format was
changed. The
previous format wasn't so informative, it wasn't obvious what was
rolled out and it
contained unnecessary informations - list of changed files and functions.

I've removed the list of changed files and functions and made the
changelog more
informative with showing the descriptions, bug urls and revision urls
of rolled out
patches in groups - http://trac.webkit.org/changeset/165447



Any particular reason for removing the list of changed files?  I find
that to be the easiest way of determining, at a glance, what kind of an
effect a change has.  If rollouts no longer include this list then I
will have to click the trac links for all of the reverted changes to
figure out that file list.  Seems painful.

-Filip


https://bugs.webkit.org/show_bug.cgi?id=122654#c0 - by AP
2. List of changed files and functions should be omitted - there are 
never per-function comments in an automatically prepared rollout, and 
searching ChangeLogs for function names doesn't need to show rollouts.


I don't understand you're problem, you still see the list of changed
files at a glance. Trac, webkit-changes mails, git log --name-status,
... still contain this list, only changelog and commit log don't.

If it is really painful for more developers, it's so easy to get
back this redundancy. You only need to revert this snippet (and
update the related webkitpy unit test results):
http://trac.webkit.org/changeset/165447/trunk/Tools/Scripts/webkitpy/common/checkout/changelog.py

Ossy

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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Osztrogonác Csaba]

Hi,

it seems there are still serious problems with *.webkit.org
infrastructure, for example the following things:
- commit queue, style queue, Apple EWS bots are still stucked
- bugzilla is very very slow, and I got this strange error right now:
--
Bugzilla has suffered an internal error. Please save this page and send 
it to ad...@webkit.org with details of what you were doing at the time 
this message appeared.


URL: https://bugs.webkit.org/post_bug.cgi


There was an error sending mail from 'bugzilla-dae...@webkit.org' to 
'webkit-unassig...@lists.webkit.org':Couldn't connect to bz.apple.com




Bugzilla has suffered an internal error. Please save this page and send 
it to ad...@webkit.org with details of what you were doing at the time 
this message appeared.


URL: https://bugs.webkit.org/post_bug.cgi
undef error - ModPerl::Util::exit: (12) exit was called at 
/var/www/html/Bugzilla/Error.pm line 118

--

Ossy

On 03/10/2014 06:35 PM, Lucas Forschler wrote:

Hello Webkit developers,

Apple will be upgrading our network infrastructure starting Tuesday morning at 
8am.
The webkit.org services will be affected for approximately 4 hours.

This includes all *.webkit.org domains.  We expect them to be back online 
before 12.

Thanks,
Lucas


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

Re: [webkit-dev] Heads-up: rollout changelog format change

[Osztrogonác Csaba]

On 03/12/2014 05:34 PM, Alexey Proskuryakov wrote:

11 марта 2014 г., в 10:43, Filip Pizlo fpi...@apple.com
mailto:fpi...@apple.com написал(а):


Any particular reason for removing the list of changed files?  I find
that to be the easiest way of determining, at a glance, what kind of
an effect a change has.  If rollouts no longer include this list then
I will have to click the trac links for all of the reverted changes to
figure out that file list.  Seems painful.


Hopefully, having a title of the rolled out bug will provide the same
information in a more concise way, without adding noise to ChangeLogs.

I'm not sure if the new behavior preserves file lists when the patch
being rolled out isn't associated with a bug.


Trac and webkit-changes mails still contain the file list, doesn't
matter if there was or wasn't bug report for the rolled out changes.

But unfortunately the description will be missing if there wasn't
bug report for the original change, because the description parser [1]
is too conservative. It recognizes the description only if the 4th line
of the changelog entry is bug url. Maybe we should make it smarter with
some heuristics or simple we should suppose that the 3rd line is the
description always. There aren't so much malformed changelog entry.

I filed a new bug report for improving description parser:
https://bugs.webkit.org/show_bug.cgi?id=130137

br,
Ossy


[1] 
https://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/checkout/changelog.py?rev=165447#L190


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

Re: [webkit-dev] Credit change set author when merging changes

[Osztrogonác Csaba]

Hi,

I checked the history of blink merges, but I haven't found too
much credit for the original author, but much more references
to the commit similar to the changeset you mentioned.

Should we mention the author _and_ the changeset too in the future?

Ossy

On 02/14/2014 09:36 AM, Ryosuke Niwa wrote:

Hi,

This is a friendly remainder that you should credit the original author
and the relevant change set in blink when you're merging patches written
by another author.

e.g. http://trac.webkit.org/changeset/163528

- R. Niwa

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

Re: [webkit-dev] EWS doesn't lie!

[Osztrogonác Csaba]

On 02/10/2014 09:51 AM, youenn fablet wrote:

Is it by design that only mac bots run regression tests? Technical
issue? Lack of resources?


Technically, it's so easy to make an EWS to run layout tests
too with adding a runTests: true to the ews.json file:
https://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/ews.json

But in my opinion it wouldn't be a good idea to enable layout tests
on Windows, GTK, EFL EWS bots, because it would make them absolutely
useless and we would lost the information if a patch builds or not.

To have a quite stable and working tester EWS, the buildbot for the
given platform must be green _almost all the time_. If there is at
least one failing test, the testing is at least twice slower, because
the EWS runs the test with the patch and then without the patch to
check if the list of the failing tests are same. Additionally the
given port must be very stable. If there are any small flakiness,
the EWS wouldn't pass ever and would stuck in an infinite loop.

The rough true is that now only the Mac platform is stable and green
enough to have tester EWS bots. (There are ~210 +/-5 failures on the
Windows bots from the cstack merge, ~205 +/-10 failures on EFL-WK1 long
time ago, ~80 +/- 2 failures on GTK-WK1 lone time ago, ~ 60 +/- 5
failures on GTK-WK2, ...)

Additionally to have tester EWS, port maintainers should have to setup
many new hardware (min. 4-8 machines with 4/8 cores per port to have
acceptable runtime) and EWS runtime would be much more slower than
the runtime of build only EWS bots, because bulding + running tests
take ~ an hour everywhere.

Ossy

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

Re: [webkit-dev] EFL EWS Bot output

[Osztrogonác Csaba]

Hi,

Fix already landed in http://trac.webkit.org/changeset/163167 ;)

Ossy

Gyuyoung Kim írta:

Hello Oliver,

I'm really sorry about the inconvenience to you. Let me try to fix it 
within a few days. 


Gyuyoung.


On Wed, Jan 29, 2014 at 8:09 AM, Alexey Proskuryakov a...@webkit.org 
mailto:a...@webkit.org wrote:



28 ???. 2014 ?., ? 14:59, Oliver Hunt oli...@apple.com
mailto:oli...@apple.com ???(?):

  Could whoever is responsible for the EFL EWS bot please make the
bot set the correct mimetype on the build output.
 
  I've requested this before, but i'm trying again.  It is really
annoying that it triggers a download rather than just opening in the
browser like the output from every other bot.

What needs to be fixed is that the output shouldn't have escape
sequences. The MIME type of text/plain is set by webkit-queues
server, but then networking code in the browser sees a resource
without an extension and that has binary data in it, so it overrides
the type.

Another solution would be for webkitpy or webkit-queues to
automagically strip escape sequences from the output.

- WBR, Alexey Proskuryakov

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

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

[Osztrogonác Csaba]

Hi,

Xabier Rodríguez Calvar írta:

O Mar, 04-02-2014 ás 13:11 +0100, Osztrogonác Csaba escribiu:
I've checked the full clean build time of GTK port on a quad core 
i5-2320 (3GHz) machine with icecc buildfarm and -j30 makeflag:

- with SVG disabled:WebKit is now built (11m:58s).
- with SVG enabled: WebKit is now built (13m:38s).


I remember the difference being bigger, in the order of several minutes.
Do you use ccache? That could explain that small difference even with
clean builds.

Br.


Of course I didn't use ccache during this measurement. :)
(I don't use it anyway.)

The majority of the community wanted to remove the guards, so
they were removed - http://trac.webkit.org/changeset/163440

I tried to do my best, but if I did some mistake,
please let me know and I will fix as soon as possible.

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

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

[Osztrogonác Csaba]

Alberto Garcia írta:

On Fri, Jan 31, 2014 at 12:43:16PM +0100, Osztrogonác Csaba wrote:


The --no-svg build is broken now, and the change broke it is 11
months old change


Not in the GTK+ port at least, I've been able to do builds without
SVG perfectly fine, so there's probably something else wrong in your
environment or the port you're using.


Good point, I haven't checked GTK port, only EFL and
Apple Mac and got the same build failure on both pof them.


Anyway, I'm also fine with removing it.

Berto

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

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

[Osztrogonác Csaba]

Xabier Rodríguez Calvar írta:

Sorry for the late answer, but I was in Brussels at FOSDEM.

O Ven, 31-01-2014 ás 14:01 +0100, Alberto Garcia escribiu:

Not in the GTK+ port at least, I've been able to do builds without
SVG perfectly fine, so there's probably something else wrong in your
environment or the port you're using.

Anyway, I'm also fine with removing it.


It saves some times in our builds and I always use it unless I have to
do something with SVG.

I would keep it unless it doesn't pay off the effort of maintaining it.

Br.


I've checked the full clean build time of GTK port on a quad core 
i5-2320 (3GHz) machine with icecc buildfarm and -j30 makeflag:

- with SVG disabled:WebKit is now built (11m:58s).
- with SVG enabled: WebKit is now built (13m:38s).

The difference isn't so big. But it was clean build, I don't think if
developers always do clean builds. If you don't touch SVG related files,
the build time shouldn't depend on enabled/disabled SVG.

In my opinion the ENABLE(SVG) flag is not to speed up clean builds, but
disable SVG if you don't want to ship it. There are so many way to speed
up builds:
 - use more cores, use icecc buildfarm, use ccache
 - get rid of include paths and use module relative includes
   (But it can be a separated thread if anybody is interested in it.)

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

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

[Osztrogonác Csaba]

Hi,

+1 for removing ENABLE(SVG) guards.

The --no-svg build is broken now, and the change broke it is
11 months old change - https://trac.webkit.org/changeset/145450, so
--no-svg build isn't maintained at all and nobody can use it on trunk.

Let's go forward and remove the guards:
https://bugs.webkit.org/show_bug.cgi?id=127991
(I started to prepare a patch, not yet finished.)

Ossy

no-svg build log:
--
In file included from 
/Users/oszi/WebKit/Source/WebCore/css/BasicShapeFunctions.cpp:35:
/Users/oszi/WebKit/Source/WebCore/css/CSSPrimitiveValueMappings.h:2670:27: 
error: use of undeclared identifier 'CSSValueAlphabetic'

m_value.valueID = CSSValueAlphabetic;
  ^
/Users/oszi/WebKit/Source/WebCore/css/CSSPrimitiveValueMappings.h:2687:10: 
error: use of undeclared identifier 'CSSValueAlphabetic'

case CSSValueAlphabetic:
 ^
/Users/oszi/WebKit/Source/WebCore/css/CSSPrimitiveValueMappings.h:4300:27: 
error: use of undeclared identifier 'CSSValueAlphabetic'

m_value.valueID = CSSValueAlphabetic;
  ^
/Users/oszi/WebKit/Source/WebCore/css/CSSPrimitiveValueMappings.h:4334:10: 
error: use of undeclared identifier 'CSSValueAlphabetic'

case CSSValueAlphabetic:
 ^
/Users/oszi/WebKit/Source/WebCore/css/CSSPrimitiveValueMappings.h:4846:27: 
error: use of undeclared identifier 'CSSValueAlphabetic'

m_value.valueID = CSSValueAlphabetic;
  ^
/Users/oszi/WebKit/Source/WebCore/css/CSSPrimitiveValueMappings.h:4872:10: 
error: use of undeclared identifier 'CSSValueAlphabetic'

case CSSValueAlphabetic:
 ^
6 errors generated.
--

On 01/29/2014 01:13 AM, Sam Weinig wrote:

Hi Everyone,

While we are discussing removing #ifdefs that everyone has enabled, I’d like to 
propose removing ENABLE(SVG), as every port has SVG enabled.  The only argument 
I have heard for keeping it around is to keep a “minimal build” working, but I 
don’t think the clutter of the #ifdefs is worth that.

-Sam

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

[webkit-dev] svn.webkit.org vs buildbots problem

[Osztrogonác Csaba]

Hi,

it seems something strange happens near svn.webkit.org server, because
the following buildbots continually fail during the svn buildstep:
- 
http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29?numbuilds=100
- 
http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29?numbuilds=100
- 
http://build.webkit.org/builders/Apple%20Mavericks%20Release%20WK1%20%28Tests%29?numbuilds=100
- 
http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2?numbuilds=100


Could you check this problem?

PS.: I haven't seen any svn problem from here, a complete checkout
took only 5 minutes ( with svn version 1.7.14 (r1542130) )

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

Re: [webkit-dev] svn.webkit.org vs buildbots problem

[Osztrogonác Csaba]

Just check the log of the Mac bots. They clobber the repository
and try a fresh checkout which fail with timeout again and again,
so it must be a real problem near the svn server or client side.

---
http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29/builds/354/steps/svn/logs/stdio

svn: E155037: Previous operation has not finished; run 'cleanup' if it 
was interrupted


After this error message buildbot triggers rm -rf:
update failed, clobbering and trying again
rm -rf /Volumes/Data/slave/mavericks-release-perf-tests/build
...

And then tries a fresh checkout which fails with timeout:
...
A 
build/PerformanceTests/Dromaeo/resources/dromaeo/web/tests/sunspider-string-unpack-code.html


command timed out: 1200 seconds without output, killing pid 2348
---

Ossy


On 01/27/2014 04:40 PM, William Siegrist wrote:

The later error messages are saying to run svn cleanup since one of the svn 
operations timed out. It could have been a spurious problem with 
svn.webkit.org, so I think the bot owner(s) should run cleanup and see if the 
timeouts keep happening.

-Bill



On Jan 27, 2014, at 6:03 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:


Hi,

it seems something strange happens near svn.webkit.org server, because
the following buildbots continually fail during the svn buildstep:
- 
http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29?numbuilds=100
- 
http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29?numbuilds=100
- 
http://build.webkit.org/builders/Apple%20Mavericks%20Release%20WK1%20%28Tests%29?numbuilds=100
- 
http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2?numbuilds=100

Could you check this problem?

PS.: I haven't seen any svn problem from here, a complete checkout
took only 5 minutes ( with svn version 1.7.14 (r1542130) )

Ossy

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

[webkit-dev] Broken Windows EWS

[Osztrogonác Csaba]

Hi,

it seems the Windows EWS bots are still broken:
http://webkit-queues.appspot.com/queue-status/win-ews


/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
12.0/Common7/IDE/WDExpress.exe WebKit.vcxproj\WebKit.sln /build 
Release|Win32
Could not open build log file at 
/home/buildbot/WebKit/WebKitBuild/Release/BuildOutput.htm at 
Tools/Scripts/build-webkit line 359.



They didn't process any patch in the last month and folks broke the
build many times because the Windows EWS is still out of order.

Is there any plan for fixing them in the near future?

br,
Ossy

Brent Fulgham írta:

Hi Ossy,

I'm not sure what's going on. Those bots do have VS2013 on them. It looks like 
a process may be locking the build log, preventing anything from happening.

I'll look into it ASAP.

Thanks,

-Brent

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

Re: [webkit-dev] Remove the WinCE bot?

[Osztrogonác Csaba]

Hi,

+1 for removing the WinCE bot, it seems it isn't maintained at all.
The latest build on it was on 8th Aug, it is offline since then:
http://build.webkit.org/builders/WinCE%20Release%20%28Build%29/builds/36154

Additionally the latest build in the build.webkit.org history
was on 6 th Jun and the build was failed since then:
http://build.webkit.org/builders/WinCE%20Release%20%28Build%29/builds/35155

I filed a bug report to remove this bot and uploaded the patch:
https://bugs.webkit.org/show_bug.cgi?id=126517

Ossy

Simon Fraser írta:

The WinCE bot has been dead for almost a month:

http://build.webkit.org/builders/WinCE%20Release%20%28Build%29

I propose we remove it from the waterfall.

WinCairo is also in a pretty bad, non-building state.

Simon

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

Re: [webkit-dev] Migration to Visual Studio 2013 Is Happening Now

[Osztrogonác Csaba]

Hi,

It seems the Windows EWS bots should be updated too:
http://webkit-queues.appspot.com/queue-status/win-ews

Ossy

Brent Fulgham írta:

I am landing changes to switch our builds over to Visual Studio 2013.  You can 
assume I know about any build failures on the Windows port. However, please let 
me know if you encounter any problems on non-Windows platforms ASAP.

Thanks,

-Brent


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

Re: [webkit-dev] WebKit, C++11, and Visual Studio 2013

[Osztrogonác Csaba]

Hi,

is there any plan to use more C++11 featurese not mentioned here?

I just ask it, because many of us still use Ubuntu 12.04 LTS with
its default compiler - GCC 4.6. (Now EFL and Nix port builds fine.)

So my question is if we will need GCC 4.7 or 4.8 in the near future
because of using C++11 featurese not supported by older compilers?

You can find here the GCC's C++11 support table:
http://gcc.gnu.org/projects/cxx0x.html

Ossy


Anders Carlsson írta:


On Dec 6, 2013, at 4:15 PM, Brent Fulgham bfulg...@apple.com 
mailto:bfulg...@apple.com wrote:



Hi Alex,

There are a few items missing from VS2012 
(see http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx) 
that we are already using in the Mac-specific source code:


1. Variadic Templates
2. Initializer Lists
3. Explicit conversion operators
4. Deleted functions


5. range-based for loops.

- Anders

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

Re: [webkit-dev] Watchlist cc rules.

[Osztrogonác Csaba]

Hi,

I don't agree with Zoltán. Adding yourself to the watchlist doesn't
need bug report and review. You are a committer, you can simple
add yourself to the watchlist directly as others did it in the past.

But you should run test-webkitpy tests before committing to make
sure you don't break webkitpy with an accidental change.

Ossy


On 10/30/2013 06:09 PM, Zoltan Horvath wrote:

Hi Sam,

You should file a bug with a patch for doing this.

Cheers,
Zoltan


On Wed, Oct 30, 2013 at 10:06 AM, Samuel White samuel_wh...@apple.com
mailto:samuel_wh...@apple.com wrote:

Hey everyone,

I’d like to add myself to the “Accessibility” cc rule in the
WebKit/Tools/Scripts/webkitpy/common/config/watchlist script. Should
I simply file a bug and attach a patch as usual, or does touching
this area involve a different procedure (since it’s not really a
bug)? Thanks for your help.

- Sam


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

Re: [webkit-dev] WTF::fastMalloc

[Osztrogonác Csaba]

Hi,

As Zoltan said this feature was introduced for Qt port. But now
EFL, GTK and Nix use fastmalloc instead of system malloc too.
It was fine and used for some use-cases in those days.

To make a decision if the fastmalloc or the system malloc is better,
we need some measurements. I made a quick test on EFL and Nix with
SunSpider and with the Methanol test suite and haven't seen any
significant performance differences between fastmalloc and system
malloc on my desktop: Ubuntu 12.04 (x86_64). I haven't checked the
memory consumption, it would need more preparation.

Keeping the old TCMalloc and the custom allocator framework isn't
blocker for us (University of Szeged), so we don't have objection
against removing it from trunk. If nodbody is interested in maintaining
the framework, it can be removed. If the final conclusion would be
dropping TCMalloc, we willingly help in this clean-up.

Ossy

Zoltan Horvath írta:
I used to work on memory related topics, while I was working on the 
University of Szeged.


Based on a 2.5-year-old measurement 
(http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast) on 
the Qt-port, the page loading on the Methanol test suite was 5% faster 
(avg) with TCmalloc than the default system allocator on Linux. The 
performance results of the SunSpider suite was similar for both 
allocators. The memory consumption was always lower with the default os 
allocator. 

I guess the new allocator only has iOS support. I'm fine with removing 
TCmalloc, although this direction might raises further questions, like 
removing the custom allocation framework also. Feel free to cc me on 
bugs, I can help by contributing some patches. 


On Mon, Sep 30, 2013 at 2:48 PM, Geoffrey Garen gga...@apple.com 
I'm planning to remove our years-out-of-date port of TCMalloc, and

replace it with something that takes maximum advantage of Mac and
iOS virtual memory, threading, and security APIs.

I've heard that TCMalloc has caused some problems for non-Mac,
non-iOS ports in the past. So, if you maintain a port, this change
might make things simpler for you.

Are there any ports whose built-in malloc implementations are slow
enough that they can't get by without TCMalloc?

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

Re: [webkit-dev] Announcing new port: Nix

[Osztrogonác Csaba]

Hi,

Geoffrey Garen írta:
   Does your code fix bugs or improve performance in WebCore or 
JavaScriptCore?

As any other WebKit port WebCore bugs are fixed when we found it and
need a fix, our current performance focus is on CoordinatedGraphics
and there are another team working on get the canvas faster.


I don't share your premise that all ports, by their nature, improve the 
correctness and performance of core code.


Can you point to some important correctness and/or performance 
improvements WebKit will see if it adopts your code into trunk?


[snip]


In that case, what is the benefit to WebKit?

Geoff


Sure. We at University of Szeged who work on WebKitNix from this year
contributed many fixes to various part of WebKit: JavaScriptCore,
WebCore, Tools, ... We landed all the fixes to WebKit trunk whenever
possible. Let me look for some fixes without striving for completeness:

Improving cURL network backend (which used by Apple's WinCairo port too)
-
- https://trac.webkit.org/changeset/150118
- https://trac.webkit.org/changeset/150221
- https://trac.webkit.org/changeset/150964
- https://trac.webkit.org/changeset/151195
- https://trac.webkit.org/changeset/151238
- https://trac.webkit.org/changeset/151254
- https://trac.webkit.org/changeset/151255
- https://trac.webkit.org/changeset/151346
- https://trac.webkit.org/changeset/151348
- https://trac.webkit.org/changeset/151441
- https://trac.webkit.org/changeset/151580
- https://trac.webkit.org/changeset/151668

JavaScriptCore fixes
-
- https://trac.webkit.org/changeset/142481
- https://trac.webkit.org/changeset/142616
- https://trac.webkit.org/changeset/143346
- https://trac.webkit.org/changeset/145047
- https://trac.webkit.org/changeset/145194
- https://trac.webkit.org/changeset/145505
- https://trac.webkit.org/changeset/145551
- https://trac.webkit.org/changeset/145689
- https://trac.webkit.org/changeset/146309
- https://trac.webkit.org/changeset/146396

WebInspector fixes
---
- https://trac.webkit.org/changeset/153471
- https://trac.webkit.org/changeset/153044
- https://trac.webkit.org/changeset/151217
- https://trac.webkit.org/changeset/150578
- https://trac.webkit.org/changeset/150959

Various assertion/missing null check fixes
---
- https://trac.webkit.org/changeset/146083
- https://trac.webkit.org/changeset/153433
- https://trac.webkit.org/changeset/153883
- https://trac.webkit.org/changeset/154439
- https://trac.webkit.org/changeset/154476
- https://trac.webkit.org/changeset/154698

I think these changes/fixes are benefit to the WebKit project. Some of
them for all ports, some of them for only Linux users, some of them for
only ARM devices, ...

Reni's Fuzzinator, a mutation based web fuzzer already revealed 75 new
bugs. (28 of them are already fixed, there are 47 opened now)
See https://bugs.webkit.org/show_bug.cgi?id=116980 for details.

Additionally we landed at least dozens, but maybe hundreds buildfixes
after accidental, forgetful (and intentional) breakages too. Not to
mention the hundreds bug reports about new regressions/failures and
how many times we helped other developers with backtraces, trying
WIP fixes on platforms they don't have.

I think the INdT guys could compose a long list of their general
fixes landed in WebKit trunk too if it is necessary.

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

[webkit-dev] Win EWS problem

[Osztrogonác Csaba]

Hi,

it seems something happened with Apple Win EWS bots. There are
9 online EWS bot, but it seems, only 2 of them work properly,
others only slow down the patch processing.

30-day Pass count: 0

http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-1
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-2
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-3
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-4
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-5
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-6
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-7

30-day Pass count: 121
-
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-8

30-day Pass count: 106
-
http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-9


I think APPLE-EWS 1-7 should be fixed or powered off to avoid waiting
hours and days to get proper build results from Apple Win EWS.

Could you check what happened with these bots? Thanks in advance.

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

Re: [webkit-dev] Does Qt ARM support NRWT?

[Osztrogonác Csaba]

Hi,

Thanks for the heads-up. I'm not working on Qt port nowadays, but
some of my colleagues (azbest_hu, kadam and abrhm). I cc-ed them to
this thread.

I can confirm that Qt ARM didn't support NRWT long long time ago,
but the Qt ARM bot on http://build.webkit.sed.hu was switched to
use NRWT directly instead of this RWT wrapper script at least half
a year before. So it's safe to remove this useNewRunWebKitTests()
function. It won't break anything.

As far as I remember that Qt ARM has only an easily fixable NRWT
issue: http://wkb.ug/6 . But it is unrelated to this bug.

I'm sure that the guys will fix these bugs quickly. ;)

Ossy

Ryosuke Niwa írta:

Hi,

It seems like the only port that uses ORWT by default is Qt ARM (and 
iOS) at this point.


Is it true that Qt ARM still doesn't support NRWT as this comment indicates?

sub useNewRunWebKitTests()
{
# NRWT does not support qt-arm: 
https://bugs.webkit.org/show_bug.cgi?id=64086

return 0 if isQt() and isARM();
# All other platforms should use NRWT by default.
return 1;
}

If so, what are remaining 
issues? https://bugs.webkit.org/show_bug.cgi?id=64086 has already been 
fixed so we need a new bug to track it if we still have some issue on Qt 
ARM.


- R. Niwa

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

Re: [webkit-dev] Ports not building as C++11?

[Osztrogonác Csaba]

Hi,

On 07/26/2013 06:04 PM, Anders Carlsson wrote:
 Hi everyone,

 when Oliver landed his “let’s break everything” patches in JSC the 
other day, I noticed that some of the follow-up build fixes by other 
ports were removing use of C++11 features (mainly nullptr).


 Are there any ports that aren’t building as C++11? If so, why not?

 - Anders

No, I don't have objections. :) I absolutely support switching to c++11,
and I'm happy to add back the removed nullptrs and scoped enum values
_after_ all ports switched to c++11.

- cmake port did the switch by http://trac.webkit.org/changeset/153315
- GTK did the switch by http://trac.webkit.org/changeset/150445
- Qt and Win confirmed that they are going to do the switch, but I'm
not sure if they already did it or not. Let the EWS bots notice us. :)

Patch is coming soon in https://bugs.webkit.org/show_bug.cgi?id=119266

But I suprised how c++11 became mandatory. If you had announced it
before pushing the FTL patches, we would have easily avoid the tons of
buildfixes removing c++11 features.

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

Re: [webkit-dev] Somewhat painful AppEngine transitions coming [Caution: Message contains Suspicious URL content]

[Osztrogonác Csaba]

Hi,

Just out of curiosity, isn't simpler deliver the ownership of
these apps from Google to Apple instead of starting new apps?

Ossy

Ryosuke Niwa írta:

Hi,

I've started moving Google owned http://test-results.appspot.com 
and http://webkit-commit-queue.appspot.com to Apple 
owned http://webkit-test-results.appspot.com 
and http://webkit-queues.appspot.com respectively.


Ojan and I have already moved the flakiness dashboard to 
http://webkit-test-results.appspot.com so builders on build.webkit.org 
http://build.webkit.org have started uploading results there. 
 Unfortunately, the historical results are still on 
http://test-results.appspot.com so we probably need to use both websites 
for the next couple of weeks.


Moving http://webkit-commit-queue.appspot.com is a little tricker 
because it involves moving off EWS bots as well.  My current plan is to 
modify Bugzilla so that it'll show two sets of bubbles for both websites 
during the transition.


I expect this transition to be somewhat painful and you may feel cause a 
great disturbance in the force.  I'll do my best to minimize the damage.


- R. Niwa

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

Re: [webkit-dev] gap in github WebKit mirror?

[Osztrogonác Csaba]

Hi Simon,

http://trac.webkit.org/changeset/147258 changed branches/chromium/1453
http://trac.webkit.org/changeset/147259 changed branches/dfgFourthTier

These commits changed different branches, not the trunk. And only
trunk is in the git mirrors. (git.webkit.org and github mirror too)

Ossy

Simon Hausmann írta:

Hi,

I'm a bit puzzled as I look at my local clone of 
https://github.com/WebKit/webkit.git to see that the commits between r147257 
and r147260 appear to be missing. The web interface appears to indicate that 
this is also the case on github itself.


Does anyone know what could cause this?


Simon

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

[webkit-dev] rolling out a buggy security patch

[Osztrogonác Csaba]

Hi All,

https://trac.webkit.org/changeset/145482 which is a security
fix, broke 33 JSC tests and made zillion layout test timeout
on all platform. (It seems the author forgot to run tests at
least on his own platform and watching the bots after landing.)

It made bots early exit and very long test runtime. Now bots can't
catch any new regression because of this patch. I tried to ping the
author and reviewer on #webkit, but they are unavailable.

Unfortunately rolling out isn't possible with sheriffbot. And I
don't think if I have authorization for rolling out a security fix
without review irrespectively of its goodness/buginess. Additionally
EWS bots can't test security patches without security group access.
And gardeners can't comment the original security bug report because
of the same reason.

So I filed a new bug report about this serious and blocker regression:
https://bugs.webkit.org/show_bug.cgi?id=112112 and I propose that we
should roll it out until the author can fix it offline. Could you
review this rollout patch, please?

Otherwise it would be great if EWS bots can test security patches
before committing to avoid similar problems. I noticed that a security
fix broke the build and/or many tests several times.

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

Re: [webkit-dev] rolling out a buggy security patch

[Osztrogonác Csaba]

Hi,

Rollout patch was already r+ -ed, thanks for the quick r+.

But my question is still open about how can we avoid similar
problems in the future. Why can't we let the EWS bots to
build and test security patches before commit.

br,
Ossy

Osztrogonác Csaba írta:

https://trac.webkit.org/changeset/145482 which is a security
fix, broke 33 JSC tests and made zillion layout test timeout
on all platform. (It seems the author forgot to run tests at
least on his own platform and watching the bots after landing.)

It made bots early exit and very long test runtime. Now bots can't
catch any new regression because of this patch. I tried to ping the
author and reviewer on #webkit, but they are unavailable.

Unfortunately rolling out isn't possible with sheriffbot. And I
don't think if I have authorization for rolling out a security fix
without review irrespectively of its goodness/buginess. Additionally
EWS bots can't test security patches without security group access.
And gardeners can't comment the original security bug report because
of the same reason.

So I filed a new bug report about this serious and blocker regression:
https://bugs.webkit.org/show_bug.cgi?id=112112 and I propose that we
should roll it out until the author can fix it offline. Could you
review this rollout patch, please?

Otherwise it would be great if EWS bots can test security patches
before committing to avoid similar problems. I noticed that a security
fix broke the build and/or many tests several times.

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

Re: [webkit-dev] Best practices for landing new/changed layout test expectations?

[Osztrogonác Csaba]

Hi,

Ryosuke Niwa írta:

(snip)

I don't like the idea that now I have to either use this tool or 
manually read through TestExpectations to find tests that need 
rebaseline. It's also annoying if we had all contributors add new lines 
to TestExpectations because those changes will almost always conflict 
when applying patches. In general, I don't like any solution that 
requires modifying TestExpectations files a lot. It's unneeded svn churn.


It should be fairly straight forward to create a tool that analyzes 
files changed in each commit and deduce which tests' expected results 
have been changed. The tool can then fetch results from each port' bot 
for those tests and automatically land them. It can then comment on the 
bug automatically about these rebaseline commits. There is no need to 
add  remove entries from TestExpectation files.


I like your idea about the new tool with some little improvement.

In my mind I see an improved EWS which analyzes the uploaded patch,
determine which expected files are touched (assuming that the author
updated the expected files at least on one platform). And then the
EWS can run only these tests on its own platform and upload the result
to bugzilla. It is much more cheaper than run all tests on all patches.
That's why only Chromium and Apple Mac EWS run test ... And to tell the
truth the waiting time is huge sometimes. This run tests on demand only
can be a good compromise for ports don't have 8x8 cores EWS machine.

I'm a little bit sceptic about automatical rebase commits. I prefer
only uploading the new results to the bugzilla. And then the author
and/or the port maintainer/gardener can review if the new results
are correct or not. And then they can integrate the new baselines
with the original patch (with a tool, of course) and land as one
commit. (Or try one more round on EWS if the results are too old.)

But unfortunately sometimes/regularly folks review and commit
faster than style checker bot run. :) In this case we might
need one more tool to check the bots automatically and help
the gardeners work to be able rebase in one patch instead
of separated patches for each port.

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

[webkit-dev] build.webkit.org problem

[Osztrogonác Csaba]

Hi,

It seems something happened with build.webkit.org.
There are pending builds on all builder, but the
master doesn't make slaves start these builds.

Could you check what happened with the buildbot master, please?

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

Re: [webkit-dev] sln files with wrong line endings

[Osztrogonác Csaba]

Hi All,

Here is an old bug report about it:
Files with CRLF lineendigs without svn:eol-style=native kills git svn 
repositories

https://bugs.webkit.org/show_bug.cgi?id=96934

The general fix would be to force all Windows project file have
svn:eol-style=native svn property. git-svn users who commit this
files can do it automatically inside: ~/.subversion/config
*.vsprops = svn:eol-style=native
*.vcproj = svn:eol-style=native

But we should force all developers to set it somehow.
There is a working solution for png files: 
https://trac.webkit.org/changeset/122311


It force commit svn:mime-type image/png svn property for SVN users
and warn GIT-SVN users if they didn't set their ~/.subversion/config
properly. I think a volunteer can do a similar thing for Windows
project files.

Ossy

Adam Roben írta:

I'm pretty sure r142864 fixed this (perhaps unintentionally) by
changing all line endings in DumpRenderTree.sln from CRLF to LF.

On Thu, Feb 14, 2013 at 11:11 AM, Darin Adler da...@apple.com wrote:

Typically in Subversion the fix for a problem like this is to set the eol-style 
explicitly; presumably to CRLF for Windows project and solution files and to LF 
or native for plain old source files. Once that property is set, people 
changing file later on can't cause problems with inconsistent line endings, 
because Subversion will check the line endings at commit time.

I have no idea how having git in the mix affects this.


WebKit's .gitattributes file contains the following:

*.vcproj eol=crlf
*.vsprops eol=crlf
*.sln eol=crlf

This tells git, When storing this file in the repository, convert all
line endings to LF. When checking out this file to disk, convert all
line endings to CRLF.

If the committed version of the file in the repository contains CRLF
line endings, git will show a diff that converts the CRLF line endings
to LF. eol=crlf means that the line endings *in the repository* should
be LF, so git is trying to fix it.

I think the thing to do is to set svn:eol-style to native for all
.vcproj, .vsprops, and .sln files. That way Subversion will commit the
files using LF line endings (like git wants), and check them out using
CRLF on Windows (like Visual Studio wants).


In fact, I don't know how to set a Subversion property using git-svn which 
means I can't easily just jump in and fix this like I would have in the past.


I don't think git-svn can set properties. When I've had to change
properties in the past I've checked out the appropriate subset of
WebKit using Subversion and made my changes there.

-Adam


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

Re: [webkit-dev] Changes to the WebKit2 development process

[Osztrogonác Csaba]

Hi,

Carlos Garcia Campos írta:

El mar, 29-01-2013 a las 09:39 +0100, Balazs Kelemen escribió:
IMHO, recently, contributors as well as WK2 owners are a bit suffering 
from it. I think we can go to a better direction: making all 
developers happy as well as resolving WK2 owners' concerns.


I think the straightforward way to achieve this is to let somebody be an 
owner from every port. He/she should could be restricted to approve only 
platform specific changes.


And why not making it even simpler an allow any reviewer to r+
port-specific patches? If the patch doesn't change any cross-platform
code at all there's no risk to break mac or any other port. 


The answer is simple: Because Apple decided and proclaimed this fiat ...

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