Re: [webkit-dev] Generating compile_commands.json when building WebKit on MacOS

2020-07-27 Thread Carlos Alberto Lopez Perez
On 25/07/2020 20:16, shriva...@firemail.cc wrote:
>> Perhaps you can try to use the WebKitGTK port for Linux ?
> You mean that I should try to build WebKitGTK port for Linux on macOS or
> simply move to Linux?

In theory it is possible to build the WebKitGTK port on MacOS, but in
practice i don't think it will work out the box since its a build
configuration that is not tested at build.webkit.org

So, my suggestion is to build the WebKitGTK port on Linux.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Generating compile_commands.json when building WebKit on MacOS

2020-07-22 Thread Carlos Alberto Lopez Perez
On 22/07/2020 10:15, shriva...@firemail.cc wrote:
> 
> Your assistance would be much appreciated.

Perhaps you can try to use the WebKitGTK port for Linux ?
CMake support for it is actively maintained and should work without any
issue. Check: https://trac.webkit.org/wiki/BuildingGtk



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Proposal to start automating the process of updating imported WPT tests inside WebKit.

2020-03-02 Thread Carlos Alberto Lopez Perez
Hello webkit-dev,

I would like to start a discussion about our current process for updating
WPT tests, and to see if we can agree on some process to semi-automate it.

Currently the process of updating WPT tests its a very manual task which 
involves:
1. Raise the WPT commit in LayoutTests/imported/w3c/resources/TestRepositories
2. Run the importer script: Tools/Scripts/import-w3c-tests
3. Check that what the script did makes sense (usually those changes
   are so big that's impossible to check manually)
4. Run layout tests to generate new expectations for new tests.
5. Upload the patch to bugzilla, wait for the EWS.
6. Check what failed in each platform.
7. Open new bugs for the new failures in reftests.
8. Add the new failures to the TestExpectations.
9. Repeat from 5. until everything is green in the EWS.
10. Ask for review: the reviewer is usually also unable to review the changes in
   details because the patch is so big that its impossible to review in detail.
11. Land it

This is so tedious task, that the last time we updated this globally was
on 2018-September (that its the date of WPT commit 0313d9f which is what
its pointed on the file LayoutTests/imported/w3c/resources/TestRepositories)

Engineers interested only in a subset of WPT tests (ex: domparsing/)
what they do, its to update individual folders from WPT ToT (instead of
updating all the imported WPT checkout). But this has its own problems:
sometimes the updated folder depends on file from other folder that its
not updated and unexpected problems happpen (example: 
)

I think that having the whole imported WPT checkout inside WebKit updated
often would be a benefit for everybody.

So, we have the idea of trying to semi-automate this. On the steps above
it would mean automating everything except the step of reviewing (10.)

Our proposal would be that a bot runs weekly and generates a patch
with the update, then uploads it to Bugzilla, waits for the EWS, opens
bugs for new failures and updates expectations accordingly; and repeats
until everything is green in the EWS. Then the bot would CC the reviewers
and ask for r? and cq?.

Note that this bot would *not* try to import new folders from WPT (folders
for new specs) into WebKit. It would only update the ones already imported.

The bigger benefit would be having our set of imported WPT tests updated
often, allowing WebKit engineers to run the regression tests with the last
version of WPT tests and to get noticed early if some update on a WPT test
breaks.

Also, engineers interested in WPT tests would not need anymore to manually
update the tests since that its done now for them. Only they would need
to import the new tests if those tests belong to a WPT folder (spec)
still not imported inside WebKit.

Other side benefit of this is that reviewing the patch with the WPT checkout
update that the bot generates would be something humanly possible to review.
Since we would do that each few days, the changes hopefully would be in the 
dozens
of files instead of the thousands of files.

The are also disadvantages to this, like the extra gardening work that will
be generated due to this constant update of tests. Specially regarding flakies
or failures not catched by the EWS (this may be a big problem for platforms
that don't have an EWS running layout tests. [1])

So there its a trade-off to be made regarding the frequency of updates
(daily, weekly, etc). Maybe we can start with weekly and see how it goes.

Just out of curiosity, I have checked how often Chromium updates their WPT
imported tests, and they do that several times per day and fully automated
[2].

We previously outlined this proposed process in this document:
https://hackmd.io/b4ViVtDsSk6Qg8fAycexVA#3-Import-w3c-tests-running-in-a-bot

Thanks for reading so far.

Please let me know your thoughts.

Best regards!
-


[1]
For GTK and WPE this should not be a problem as we are already
looking forward to make our EWS bots run layout tests.
[2]
See:
http://sprunge.us/a56RIo and
https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md#Automatic-import-process



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Enabling debugging for libwebkit on Linux

2020-02-04 Thread Carlos Alberto Lopez Perez
On 03/02/2020 21:11, Ben Greear wrote:
> Hello,
> 
> Is there an easy way to add a 'show source' button to the right-click
> menu, or enable some
> other feature that would help determine what content libwebkit is trying
> to render (printing
> to stdout is good enough for me).
> 
> Thanks,
> Ben
> 

A quick way may be to enable the web inspector and use the sources tab
to inspect the sources.

You can enable the web inspector by enabling the
"enable-developer-extras" setting.


[1]
https://webkitgtk.org/reference/webkit2gtk/stable/WebKitSettings.html#WebKitSettings--enable-developer-extras



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

2019-10-17 Thread Carlos Alberto Lopez Perez
On 10/10/2019 22:08, Ryosuke Niwa wrote:
> People often associate the term "WebKit" with Apple's WebKit port in
> practice. The risk here is really about people not understanding the nuance
> of port specific bugs & set of features. WebKit's ports are unlike Gecko's
> & Blink's because while they may have platform specific bugs, each engine
> is supposed to fully support more or less the same set of features on all
> platforms equally well, and there is a clear entity which maintains either
> engine (Mozilla & Google). With WebKit, that's not the case.
> 
> If I were you, I'd do something like putting WebKit logo on a side of GTK+
> logo's box.

Thanks everybody for the feedback.

So I will try to see if we can create a new logo for WebKitGTK.

I understand this new logo can have some elements from the original
WebKit logo, but it has to be clearly visually different.
(for example, it would be OK to put the WebKit logo on a side of the GTK
logo cube/box, but it will not be OK to just change the colors of the
original logo)


Best regards.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Adrian Perez de Castro is now a WebKit reviewer

2019-10-14 Thread Carlos Alberto Lopez Perez
Hi everyone,

I would like to announce that Adrian Perez de Castro (aperezdc on #webkit)
is now a WebKit reviewer. 

Adrian has several years of experience working with the WebKitGTK and WPE
WebKit ports. He is the release manager of the WPE port and the main developer
behind the Cog WPE browser.


Please join me in congratulating Adrian, and send him some patches to review.


Adrian, congratulations.


Cheers!



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Issues running remote debug inspector for WPE instance with Epiphany dev preview

2019-10-11 Thread Carlos Alberto Lopez Perez
On 11/10/2019 18:07, Ryan Walklin wrote:
> Thanks for letting me know. Is there any workaround not requiring the edits 
> to the Web Inspector UI mentioned in 
> https://bugs.webkit.org/show_bug.cgi?id=202321#c4 (which I assume would 
> necessitate a custom Epiphany build) on Fedora currently?

Can you try this?

1. Download the source package of shared-mime-info (the SRPM and install it)
2. Patch it with this patch (by adding the patch to the RPM SPEC file):
https://people.igalia.com/clopez/wkbug/202321/0001-Revert-Assign-.html-to-XHTML-pages.patch
3. Rebuild the package and install the new version.
4. Check if it works and please report that on the bug above.

Thanks



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Implementing OffscreenCanvas

2019-10-11 Thread Carlos Alberto Lopez Perez
On 11/10/2019 11:09, Chris Lord wrote:
> This sounds good to me, I'll file a bug and write a patch for this. I
> assume there are ways of enabling features when tests are run? While a
> user (or a developer) using WebKit wouldn't want this feature to be
> enabled, I think it should be enabled for (some) test runs as soon as
> possible to give us an indication of any issues that exist at the
> moment.

This can be achieved with a run-time flag that is off by default but enabled 
for the layout tests.
See TestController::resetPreferencesToConsistentValues() in 
Tools/WebKitTestRunner/TestController.cpp



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

2019-10-10 Thread Carlos Alberto Lopez Perez
On 09/10/2019 21:53, Maciej Stachowiak wrote:
> In terms of legalities:
> 
> The WebKit logo (as well as the term WebKit) is trademarked by Apple, but 
> there are acceptable use guidelines in the Terms of Use: 
> https://webkit.org/terms-of-use/ . I am not a lawyer and cannot give legal 
> advice, but my interpretation is that it’s OK to use the WebKit logo in 
> association with WebKitGTK. As far as alterations, I think a WebKit logo with 
> a GTK+ logo next to it (or Linux logo, whatever), or badging it in the 
> corner, would be more in line with the guidelines than a recolor. i.e. 
> putting another logo/mark next to the WebKit logo seems more appropriate than 
> directly altering the logo.


So, if I understand right... something like this would be more
acceptable? https://people.igalia.com/clopez/webkit_gtk_corner_logo.png

Personally, i think that is more likely to cause confusion than using a
logo with different colors, check:

https://people.igalia.com/clopez/wpt_fyi_logo_test.png
vs
https://people.igalia.com/clopez/wpt_fyi_logo_test2.png


But if that is ok for you, then for my part is also fine... in the end
webkitgtk is webkit, right?


And if someone doesn't like this, please let me know, we may try to come
with a new logo for webkitgtk (that is not simply changing the colors).
I just want to know how to best proceed in this regard.


Regards.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

2019-10-09 Thread Carlos Alberto Lopez Perez
On 03/10/2019 00:43, Ryosuke Niwa wrote:
> I don't know the rules regarding the logo use but it might be a bit
> misleading to use WebKit logo without any qualification for GTK+ port on
> wpt.fyi.
> 
> I'd imagine people who visiting wpt.fyi may not realize how different GTK+
> and Apple's WebKit ports are in terms of set of features being enabled, and
> which sets of tests pass in each port.
> 
> So at minimum, we may want to add some kind of indication that it's GTK+
> port; or that it's distinct from Apple's WebKit ports if you were to use
> WebKit's logo somehow.

I agree that its important to not confuse users and make clearer that
the results are for the WebKitGTK port.

On one hand the name would be WebKitGTK and the platform Linux, and on
the other hand it would have on the smaller icon at the left a Tux (the
classic Linux penguin).

See this example of how it would look (without logo still):

https://wpt.fyi/results/?run_id=334360001_id=336100010_id=322590004_id=332480002_id=332480003


However, I agree that still can be confusing if we use the WebKit logo
as is. So, let's discard doing that.

But, I wonder if it would be OK to use a variation of the WebKit logo
with some clearly visible modifications like different colors.

For example: https://cloud.igalia.com/index.php/s/y4xrKBYBY8t643D
(Its the WebKit logo but with the GTK colors)


Would be using this variation of the logo OK?


Thanks



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Can the WebKit logo be used for WebKit ports? (like WebKitGTK)

2019-10-02 Thread Carlos Alberto Lopez Perez
Hi,

I'm working on having daily runs of WebKitGTK (with minibrowser) at 
https://wpt.fyi
but then I noticed that the WebKitGTK project doesn't have a logo as such.

So, I wonder...

Would it be OK to use the WebKit logo for the WebKitGTK port?
(to show on wpt.fyi at the top of the column for the WebKitGTK test results)

Thanks for the comments

Best regards.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

2017-12-13 Thread Carlos Alberto Lopez Perez
On 12/12/17 21:18, Mathias Bynens wrote:
>> We do not have any Linux binaries blessed, approved or endorsed by Apple,
>> and we never will, regardless of what domain it's hosted on. However, you
>> can get official Linux binaries from parties that own Linux ports.
> 
> If the hosting domain doesn’t matter, would you object to it being
> webkit.org? All I meant to say is that this would be my preference.
> 
> Just to clarify, I’d be excited to get the downloads at all! I understand
> who maintains the Linux port, and I appreciate everyone’s hard work on
> this.
> 

We (Igalia) as WebKitGTK+ maintainers have control over the domain
webkitgtk.org, so we have currently the capacity to host there the
requested files. But we don't have any control over the webkit.org domain.

Also note that we only distribute WebKitGTK+ as source tarballs.
We don't ship binaries.

This binaries from the buildbot bots are not intended for third-parties
uses. We just happen to generate them as part of a CI infrastructure.
In any case, we are happy to make easier for you to fetch them if you want.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

2017-12-12 Thread Carlos Alberto Lopez Perez
On 12/12/17 19:58, Mathias Bynens wrote:
> Yes, there is such an expectation. jsvu has a policy of only using URLs
> “that are controlled by the creators of the JavaScript engine”:
> https://github.com/GoogleChromeLabs/jsvu#security-considerations
> 
> Anything not on *.webkit.org or similar, or anything not on on S2 buckets
> that are owned by Apple directly, does not fit that policy.

Will an URL on the domain webkitgtk.org work for you?



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

2017-12-11 Thread Carlos Alberto Lopez Perez
On 08/12/17 18:07, Lucas Forschler wrote:
> If the GTK team wanted to support making these accessible,
> they have everything they need. They could either choose to open up
> their firewall so external folks could access them. Or, they could put
> full archives on build.webkit.org  (which would
> be transferred to s3/webkit build archives).
> 
> Maybe someone over there would be willing to take on this work if it is
> in their budget. (Both time and bandwidth)
>


Hi Lucas, Mathias, et all.

This is bit more complex that it seems. I will try to explain.

The built products the WebKitGTK+ bots currently generate are being
uploaded to a local server that was only reachable from the Igalia
intranet [1]. I have just changed that, and the build products should
be now accesible for everybody at:

http://webkitgtk-release.igalia.com/built-products/
(also available via https if you prefer)

Keep in mind that currently we delete the built products after 10 hours,
so don't expect to find there more than the very last few builds.
That is just enough time for the test bots to download and test them.

We are happy on configuring a less aggressive purging of this files to
keep them available for much longer. We can as well make this resource
available from a more official domain (like webkit.org or webkitgtk.org)
 
But before doing that I will like to know if this files will be useful
for you in the end (or not). See below.

If you download one of those build products and try to run it on your dev
machine you are likely to have some problems with the shared libraries.

The main issue is that this binaries are linked against a bunch of libraries
that we build in a internal JHBuild, and will likely differ from the ones
shipped by your distro.

To test it, you can download one of this zip files and try running:

for JSC:
LD_LIBRARY_PATH=$(pwd)/lib bin/jsc

for WebKit:
LD_LIBRARY_PATH=$(pwd)/lib WEBKIT_EXEC_PATH=$(pwd)/bin 
WEBKIT_INJECTED_BUNDLE_PATH=$(pwd)/lib bin/MiniBrowser


Perhaps the JSC binary works because it has few dependencies (libicu and
glib mainly), but I doubt the WebKit one will do. Your mileage may vary.


And this will be only for the 64-bit builds. Our current 32-bit buildbots
are test ones, which means they don't currently generate and upload
a built-product. They just test it after building it and then discard it.
There maybe the possibility of adding an extra step to add the upload in
case you find this built products useful.

Trying to look forward for a more elegant solution I tried to generate a
static build of JSC with the JSCOnly port, but I failed when trying to
link statically with libicu. I have reported that on the bug below:
https://bugs.webkit.org/show_bug.cgi?id=180678


Let me know your thoughts.

Regards
---

[1]
We do that because the server that generates the built product as well as the
others that donwload it for testing are on the same LAN. So it makes little
sense for us to daily upload and download gigabytes worth of data to Internet, 
when we can just serve the resources locally.

Doing that will make every build slower because then the build-only bot
will have to wait for an upload to Internet rather than to a local server,
as well the test-only bot will have to wait for a download from Internet. 
Our bandwith to Internet is much less than a gigabit LAN.




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Buildbot upgrade on build.webkit.org

2017-12-10 Thread Carlos Alberto Lopez Perez
On 07/12/17 21:47, Aakash Jain wrote:
> For people using build.webkit.org , I would
> like to know what pages you use most of the time (e.g.: builder page,
> console view etc.) and what are your primary use-cases (purpose to
> visit build.webkit.org ). Also if you have
> any feedback/concern about new Buildbot please let me know.
I use 99% of the time the waterfall view, and I think the new waterfall
view of buildbot 9 is a step back in terms of usefulness.

More details on about why I think this here:
https://bugs.webkit.org/show_bug.cgi?id=175056#c1




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN server broken?

2017-09-08 Thread Carlos Alberto Lopez Perez
On 08/09/17 11:56, Carlos Alberto Lopez Perez wrote:
> On 08/09/17 04:07, Ling Ho wrote:
>> We have completed server maintenance works. Please email
>> ad...@webkit.org if you encounter any problem.
> 
> It seems there is an issue with the SVN server?
> Is rejecting both commits from commit-queue or manually landed.
> 
> $ git svn dcommit
> Committing to http://svn.webkit.org/repository/webkit/trunk ...
>   D   
> Tools/wpe/patches/freetype6-2.4.11-truetype-font-height-fix.patch
>   M   Source/WebCore/ChangeLog
> 
> ERROR from SVN:
> Item is out of date: File '/trunk/Source/WebCore/ChangeLog' is out of date
> W: 7e9ab8012eb85cca13a55ea65bc0f194c37a11b7 and refs/remotes/origin/master 
> differ, using rebase:
> :04 04 a0c128f45219a4f568ffb7b27336ca501b1fc64f 
> 5f584218e40d75a9c39c52b76fd648459857f264 MSource
> :04 04 42e7bcb4148039d4fcc172c267b7db51f0ee98f8 
> 7faa3cb8917a0bdbd9d0d34942b8d5422ee72eb9 MTools
> Current branch master is up to date.
> ERROR: Not all changes have been committed into SVN, however the committed
> ones (if any) seem to be successfully integrated into the working tree.
> Please see the above messages for details.
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

Also SVN trunk is still at r221777, but on the IRC channel #webkit WKR
has claimed to have landed r221778 and r221779 (and closed bugs 176252
and 176303), and I can't see this commits anywhere on the SVN.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] SVN server broken? (was: Re: Webkit.org server maintenance - 5-7pm PDT, Thu Sep 7, 2017)

2017-09-08 Thread Carlos Alberto Lopez Perez
On 08/09/17 04:07, Ling Ho wrote:
> We have completed server maintenance works. Please email
> ad...@webkit.org if you encounter any problem.

It seems there is an issue with the SVN server?
Is rejecting both commits from commit-queue or manually landed.

$ git svn dcommit
Committing to http://svn.webkit.org/repository/webkit/trunk ...
D   
Tools/wpe/patches/freetype6-2.4.11-truetype-font-height-fix.patch
M   Source/WebCore/ChangeLog

ERROR from SVN:
Item is out of date: File '/trunk/Source/WebCore/ChangeLog' is out of date
W: 7e9ab8012eb85cca13a55ea65bc0f194c37a11b7 and refs/remotes/origin/master 
differ, using rebase:
:04 04 a0c128f45219a4f568ffb7b27336ca501b1fc64f 
5f584218e40d75a9c39c52b76fd648459857f264 M  Source
:04 04 42e7bcb4148039d4fcc172c267b7db51f0ee98f8 
7faa3cb8917a0bdbd9d0d34942b8d5422ee72eb9 M  Tools
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-29 Thread Carlos Alberto Lopez Perez
On 29/08/17 02:37, Keith Miller wrote:
> Bundling happens as part of the CMake configuration process, in the
> CMake build. In the Xcode build it’s more complicated since we cannot
> dynamically choose the files we are going to compile. The onlysolution
> I know of is to pre-list a bunch of files for the build to dump files
> into. Occasionally, we’ll need to add more files to the build list.

If I understood the proposal right, to benefit from this unified source
feature the developers have to use CMake.

Does this means that Apple ports are going to switch to CMake?

If this switch to CMake is going to be optional, then I only foresee
constant breakage and headaches for those that choose to use the
non-default option (the one not tested by the EWS and release bots).



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Python

2017-08-07 Thread Carlos Alberto Lopez Perez
On 07/08/17 17:44, Andy Estes wrote:
>>> last I checked, macOS did not provide a python2 binary either. I am hoping 
>>> that has changed in the past few years. Has it?
>> Nope.
> macOS does have /usr/bin/python2.7, though.
> 

That's a good thing.

I believe all Linux distros we support have this, right?
And all the scripts actually assume python2.7 (AFAIK).

Would it work for everyone having as shebang :

#!/usr/bin/env python2.7

?



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] What's the rationale for not including config.h in any header files?

2017-08-04 Thread Carlos Alberto Lopez Perez
On 02/08/17 12:14, Konstantin Tokarev wrote:
> FWIW, I use ENABLE_ALLINONE_BUILD=ON as a default build option in Qt
> port and don't have any "terrible" development experience. Even when I
> need to make a change in file that is not port-specific, usually just
> one of AllInOne files needs to be recompiled

Do you happen to have some numbers of how much less time it takes to
build with this?



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] update GCC version?

2017-07-17 Thread Carlos Alberto Lopez Perez
On 05/07/17 17:10, Michael Catanzaro wrote:
> On Wed, Jul 5, 2017 at 6:32 AM, Carlos Alberto Lopez Perez
> <clo...@igalia.com> wrote:
>> I think the default build toolchain should be supported also,
>> at least without the requirement of "one year after the release".
>>
>> I propose this change to the policy over yours:
>>
>> - This policy applies to runtime dependencies to ensure smooth updates
>> for users.
>> - It does not apply to the build toolchain.
>> - A compiler other than the default compiler in an otherwise-supported
>> distribution may be required to build.
>>
>> + This policy applies to the runtime dependencies to ensure smooth
>> updates for users.
>> + The requirement of "one year after the release" does not apply to
>> the default toolchain.
>> + On that extra year of support a compiler other than the default one
>> in an otherwise-supported distribution may be required to build.
>>
>>
>> I think is important to not require a too much new version of the
>> default toolchain (GCC).
> 
> Fine by me.
> 
> Michael
> 
> 

Ok. For the record: I just updated policy with this changes (plus a
minor clarification regarding that for the last version of a supported
distro both runtime and default toolchain dependencies are supported)




signature.asc
Description: OpenPGP digital signature
___
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

2017-07-05 Thread Carlos Alberto Lopez Perez
On 05/07/17 23:24, Saam barati wrote:
> What’s the testing plan here? Do y'all plan to add a bot that ensures ARMv6 
> stays working?
> 
> - Saam

We do.

I will deploy one at https://build-webkit.igalia.com/waterfall?category=misc
ASAP (hopefully this week), and then propose a patch to move it to the official
QA infrastructure at https://build.webkit.org/waterfall?category=misc




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] update GCC version?

2017-07-05 Thread Carlos Alberto Lopez Perez
On 23/06/17 19:55, Michael Catanzaro wrote:
> On Fri, Jun 23, 2017 at 12:36 PM, Yusuke SUZUKI 
> wrote:
>> It's middle of 2017! And Debian stable is released.
>>
>> We discussed a bit about updating GCC and MSVC in [1].
>> Based on the comment from JF[1], I think start of July would be very
>> nice timing to update our GCC version.
>>
>> If we can update our compiler baselines including MSVC, it would be
>> very nice to us because it means full C++14 support at least.
>>
>> [1]: https://bugs.webkit.org/show_bug.cgi?id=173582
>> [2]: https://bugs.webkit.org/show_bug.cgi?id=173582#c10
>>
>> Regards,
>> Yusuke Suzuki
> 
> I believe this is now fine for both WebKitGTK+ and WPE. We might need to
> upgrade a bot or something, but we can surely figure that out. My
> understanding is that Carlos Lopez has already upgraded most of the bots.
> 
> Since I've heard no objections since proposing this months ago, I have
> just now updated the WebKitGTK+ dependency policy [1] to change it to
> apply only to runtime dependencies and not to the build toolchain.
> 
> Michael
> 
> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy

I think the default build toolchain should be supported also,
at least without the requirement of "one year after the release".

I propose this change to the policy over yours:

- This policy applies to runtime dependencies to ensure smooth updates for 
users.
- It does not apply to the build toolchain.
- A compiler other than the default compiler in an otherwise-supported 
distribution may be required to build. 

+ This policy applies to the runtime dependencies to ensure smooth updates for 
users.
+ The requirement of "one year after the release" does not apply to the default 
toolchain.
+ On that extra year of support a compiler other than the default one in an 
otherwise-supported distribution may be required to build. 


I think is important to not require a too much new version of the default 
toolchain (GCC).





signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WebKit project in Coverity

2017-06-02 Thread Carlos Alberto Lopez Perez
Hi,

Coverity is an static analysis tool that allows to find bugs and
vulnerabilities on the source code via static analysis.

For open source projects, they offer free usage of their platform.

The WebKit project is already registered there since a while. [1]
To read the reports in detail or run new scans you have to be
member of the WebKit project in Coverity.


I happen to be one of the admins there, and I will happily grant you
access to this platform if you are a WebKit committer (listed in
contributors.json).

So if you are interested in this, just send me an email requesting
access.

Regards
---

[1] https://scan.coverity.com/projects/webkit



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Commits in branches triggering build in the bots now

2017-05-04 Thread Carlos Alberto Lopez Perez
On 05/05/17 00:55, Carlos Alberto Lopez Perez wrote:
> But the buildbot config should only trigger branches for changes on
> trunk due to the change_filter": "trunk_filter" below:

I mean: "But the buildbot config should only trigger _builds_ for 



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Commits in branches triggering build in the bots now

2017-05-04 Thread Carlos Alberto Lopez Perez
On 05/05/17 00:24, Lucas Forschler wrote:
> Hi Carlos!
> 
> I recently updated the svn post commit hook to use the newest version of 
> svn_buildbot.py from 
> https://github.com/buildbot/buildbot-contrib/blob/master/master/contrib/svn_buildbot.py
>  
> 
> 
> I am going to look through the diff now to see if there are any obvious 
> changes which would cause this.
> Thanks for bringing it to our attention!
> 
> Lucas

Its ok that the svn_buildbot script sends changes about any branches.

But the buildbot config should only trigger branches for changes on
trunk due to the change_filter": "trunk_filter" below:

https://trac.webkit.org/browser/webkit/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/master.cfg?rev=216213#L954

https://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/config.json?rev=216213#L353

Maybe the issue is that the new svn_buildbot scripts fails to identify the 
branch name
(for WebKitGTK+ we use a non-standard branch name: "releases") and sends the 
changes with
branch "None"?

Maybe the patch below fixes the issue?

--- a/Tools/BuildSlaveSupport/build.webkit.org-config/master.cfg
+++ b/Tools/BuildSlaveSupport/build.webkit.org-config/master.cfg
@@ -951,7 +951,7 @@ class PlatformSpecificScheduler(AnyBranchScheduler):
 def filter(self, change):
 return wkbuild.should_build(self.platform, change.files)
 
-trunk_filter = ChangeFilter(branch=["trunk", None])
+trunk_filter = ChangeFilter(branch="trunk")
 
 def loadBuilderConfig(c):
 # FIXME: These file handles are leaked.




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Compile time increase over time

2017-04-24 Thread Carlos Alberto Lopez Perez
On 24/04/17 21:02, Konstantin Tokarev wrote:
> 
> 24.04.2017, 21:10, "Alex Christensen" :
>> Thanks for the data, Carlos! This is a growing problem that is hurting 
>> productivity. We’ve discussed it a bit and haven’t done enough about it. 
>> Here are some of the ideas I’ve heard:
>>
>> 1) Reduce #includes by doing more forward declaring and less inlining. We 
>> would probably need link time optimization to not lose performance benefits 
>> of inlining functions in headers.
>> 2) Use distributed build tools and caches to cover up the problem. WebKit 
>> would still be prohibitively hard to compile for people without lots of 
>> expensive computers, but we could greatly improve the productivity of large 
>> teams.
>> 3) Use C++ modules
>> 4) Put more commonly included headers into precompiled headers
> Note that CMake-based ports don't use PCH on non-Windows platforms currently.
> 

Right.

I tried to enable that some years ago using the Cotire CMake module, but
I didn't managed to get it working.

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

If someone wants to take over it, please feel free.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Compile time increase over time

2017-04-24 Thread Carlos Alberto Lopez Perez
Hi,

Inspired by a similar thread on the Chromium mailing lists [1], I have
measured the build times of WebKitGTK+ over the past 2.5 years.

I benchmarked two different compilers (GCC and Clang).

The summary is: since September 2014 the time for building WebKitGTK+
has increased in a 62% for GCC 4.9 and a 51% for Clang 3.8.

However, the number of ninja targets has only increased a 19%.

On the Chromium thread [1] it is suggested that one possible explanation
for the increase in compile times is that C++11 features are slower to
compile.

Since most of the code is cross-platform, I expect other ports (like
Mac) to have a very similar percentage increases.

I'm attaching an image with the plot, as also linking below to the
interactive plot below where you can also see the raw numbers:

   https://plot.ly/~clopezdb67/3/


Hope you find this data interesting.


Regards!


[1]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZW0jcU_Y_uQ


signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Carlos Alberto Lopez Perez is now a WebKit Reviewer

2017-03-30 Thread Carlos Alberto Lopez Perez
On 30/03/17 19:10, Mark Lam wrote:
> Hi folks,
> 
> I just want to announce that Carlos Alberto Lopez Perez (clopez on
> #webkit) is now a WebKit Reviewer. Carlos has been contributing on the
> WebKitGTK+ port and has expertise on tools and build/test
> infrastructure. Please join me in congratulating Carlos, and send him
> some patches to review.
> 
> Carlos, congratulations.

Thanks a lot :)

Cheers!



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-22 Thread Carlos Alberto Lopez Perez
On 17/03/17 17:30, Lucas Forschler wrote:
> Hi Carlos,
> 
> The results folder is being copied over, it’s just taking a long time since 
> it’s many TB of data.
> 
> Interesting on the build counter being reset to zero… that is unexpected. I 
> will investigate. Thanks for pointing it out!
> 
> Lucas

It seems the index for results for the GTK Release test bot in this
directory [1] is not longer updating.

The last available results seem to be from r211747 (6 Feb -- more than a
month ago)

The bot is running fine, and its uploading the results, as this example
log from today shows:

https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Tests%29/builds/104/steps/MasterShellCommand/logs/stdio

Guessing the path from the above log, I can manually check that the
files are there:

https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r214279%20%28104%29/

https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r214279%20%28104%29.zip

But I can't see that listed on the index of [1]

Do you have any idea about what is wrong?


It seems this is also happening to more bots, like (at least):

https://build.webkit.org/results/Apple%20El%20Capitan%20Release%20WK2%20%28Tests%29/
https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK1%20%28Tests%29/
https://build.webkit.org/results/Apple%20Sierra%20Release%20WK2%20%28Tests%29/


Thanks


[1]
https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-17 Thread Carlos Alberto Lopez Perez
On 16/03/17 22:40, Ling Ho wrote:
> Hello WebKit developers:
> 
> We are continuing our transitioning of webkit.org servers today and
> tomorrow. Between 3pm and 4pm Pacific, we will be moving
> build.webkit.org. Please email us at ad...@webkit.org if you encounter
> any issue with your build bots after the transition.
> 
> Thanks,
> ...
> ling
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

It looks the buildbot database was wiped during the migration? :(

The counter number for the builds has been reset to 0 and all previous
information about layout test results at
https://build.webkit.org/results/ has been lost.


This information was used by several tools like the flakiness dashboard
the TestFailures tool, wktesthunter [1], and maybe other tools.


I wonder if the files from the results/ directory of the old server can
be recovered and copied to the results/ directory of this new one?.
Or at least make that available for download as a tarball ?



[1] https://github.com/clopez/webkit-testhunter



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] MiniBrowser

2017-03-15 Thread Carlos Alberto Lopez Perez
On 15/03/17 13:46, Jerry Geis wrote:
> I am running CentOS 7 and MiniBrowser...
> I am running XMLhttprequest() with a URL like
> http://localhost:6500/FrameCheck
> To see if the there is a new URL to load into a frame.
> 
> I run the inspect Element and view the console and I see
> 
> Failed to load resource: Message Corrupt
> 
> The response to http://localhost:6500/FrameCheck is
> 
> HTTP/1.0
> Access-Control-Allow-Origin: *
> Content-type: text/html
> 
> 402 no file
> 
> 
> I am expecting the "402 no file" or "200 URL" so that is fine.
> 
> Why am I getting message corrupt and as a consequense my callback function
> does not run.
> 
> Thanks,
> 
> jerry
> 

Please, report bugs in bugzilla: https://bugs.webkit.org/

If the bug is about WebKitGTK+ (I guess it is, because you are using
Linux), then either select component WebKit Gtk or include in the CC
list the address bugs-nore...@webkitgtk.org



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 20:16, Alexey Proskuryakov wrote:
> 
> How does one create a local git-svn checkout to try this out? Given that
> the offending file has been effectively deleted from svn, I think that
> git-svn should work too.

You have the script:
Tools/Scripts/webkit-patch setup-git-clone

And there is more doc here:
https://trac.webkit.org/wiki/UsingGitWithWebKit

I can confirm that now it seems to work :) Thanks.

Also the git mirror is now updated beyond r212951.

How do you fixed this?

I see now that the files on r212951 have different sha1 hashes:

$ svn co 
https://svn.webkit.org/repository/webkit/trunk/LayoutTests/http/tests/cache/@r212951

$ find cache/|grep pdf|xargs sha1sum
1880d3e60a5f888c5eb077dd6c52a9a80423d971  
cache/disk-cache/resources/shattered-1-nocollision.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  
cache/disk-cache/resources/shattered-1.pdf
682ca0c01721fe5e49a91da2253b4aa2fe2cde1c  
cache/disk-cache/resources/shattered-2-nocollision.pdf




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 18:46, Carlos Alberto Lopez Perez wrote:
> On 24/02/17 18:08, Alexey Proskuryakov wrote:
>>
>>> 24 февр. 2017 г., в 7:48, Antti Koivisto <koivi...@iki.fi
>>> <mailto:koivi...@iki.fi>> написал(а):
>>>
>>> Hi,
>>>
>>> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some
>>> sort of SVN problem. Please hold commits until this is resolved.
>>
>> I deleted the remaining PDF file from resources, so svn checkout now
>> works. There is almost certainly more cleanup that needs to be done - I
>> can see that trac.webkit.org <http://trac.webkit.org> is broken. Please
>> reply to the thread about what else you see not working.
>>
>> - Alexey
>>
>>
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
> 
> Any svn mirror will be unable to sync beyond r212950 [1].
> 
> And I think we can seize that to fix this as follows:
> 
>  * Create a svn mirror of the webkit repository up to r212950
>  * Replace the current repository with that mirror.
> 
> That would effectively reset the WebKit repository to r212950,
> like if r212951/r212952 never happened.
> 
> Something like this would do the trick:
> 
> $ svnadmin create webkit-svn-clone
> $ cd webkit-svn-clone/
> $ echo '#!/bin/true' > hooks/pre-revprop-change
> $ chmod +x hooks/pre-revprop-change
> $ svnsync init file://$(pwd) https://svn.webkit.org/repository/webkit/

^ The command below was missing after the svnsync init:

$ svnsync --non-interactive sync file://$(pwd)




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 18:08, Alexey Proskuryakov wrote:
> 
>> 24 февр. 2017 г., в 7:48, Antti Koivisto > > написал(а):
>>
>> Hi,
>>
>> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some
>> sort of SVN problem. Please hold commits until this is resolved.
> 
> I deleted the remaining PDF file from resources, so svn checkout now
> works. There is almost certainly more cleanup that needs to be done - I
> can see that trac.webkit.org  is broken. Please
> reply to the thread about what else you see not working.
> 
> - Alexey
> 
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

Any svn mirror will be unable to sync beyond r212950 [1].

And I think we can seize that to fix this as follows:

 * Create a svn mirror of the webkit repository up to r212950
 * Replace the current repository with that mirror.

That would effectively reset the WebKit repository to r212950,
like if r212951/r212952 never happened.

Something like this would do the trick:

$ svnadmin create webkit-svn-clone
$ cd webkit-svn-clone/
$ echo '#!/bin/true' > hooks/pre-revprop-change
$ chmod +x hooks/pre-revprop-change
$ svnsync init file://$(pwd) https://svn.webkit.org/repository/webkit/
# [...]
# This will sync up to r212950 that is precisely what we want (r212951 is the 
bad commit).
# [...]
# Copied properties for revision 212950.
# Transmitting file data ..svnsync: E200014: Checksum mismatch for resulting 
fulltext
# (/trunk/LayoutTests/http/tests/cache/disk-cache/resources/shattered-2.pdf):
#   expected:  5bd9d8cabc46041579a311230539b8d1
# actual:  ee4aa52b139d925f8d8884402b0a750c

# Now remove the hook for pre-revpro-change
$ rm -f hooks/pre-revprop-change

And rename the old svn repository directory (to keep a copy of it just in case 
we
need to recover something that was overlooked here)

And put this new mirror as the official one.

Check if there is any hook on the old one that should be moved also to the new


Note: It will take a lot to sync, so to speed up it an idea is to sync the 
mirror on
the server where the repo is located, by using a file://var/svn/webkit uri or 
similar.


Regards
---
[1] https://bugs.webkit.org/show_bug.cgi?id=168774#c32



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 18:08, Alexey Proskuryakov wrote:
> 
>> 24 февр. 2017 г., в 7:48, Antti Koivisto > > написал(а):
>>
>> Hi,
>>
>> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some
>> sort of SVN problem. Please hold commits until this is resolved.
> 
> I deleted the remaining PDF file from resources, so svn checkout now
> works. There is almost certainly more cleanup that needs to be done - I
> can see that trac.webkit.org  is broken. Please
> reply to the thread about what else you see not working.
> 
> - Alexey
> 
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

git-svn is broken

$ git log -1 --oneline HEAD
0d9a180f8c9 [Mac][cmake] Unreviewed buildfix after r212736.

$ git svn fetch
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1-nocollision.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-2-nocollision.pdf
APR does not understand this error code: ra_serf: The server sent a truncated 
HTTP response body. at /usr/share/perl5/Git/SVN/Ra.pm line 312.

$ git svn rebase
Index mismatch: 8f07398718ee1335bdf913347d759fb5d0a8535f != 
4f1b8dd4ff430af3ecac101de0063cbb9d8177bf
rereading 0d9a180f8c9d608a310c79a9a7a879d2f631d8a3
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1-nocollision.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-2-nocollision.pdf
APR does not understand this error code: ra_serf: The server sent a truncated 
HTTP response body. at /usr/share/perl5/Git/SVN/Ra.pm line 312.

$ git pull
Already up-to-date.

$ git log -1 --oneline HEAD
0d9a180f8c9 [Mac][cmake] Unreviewed buildfix after r212736.





signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] update GCC version?

2017-01-09 Thread Carlos Alberto Lopez Perez
On 09/01/17 16:47, Michael Catanzaro wrote:
> On Mon, 2017-01-09 at 16:39 +0100, Carlos Alberto Lopez Perez wrote:
>> I strongly oppose to do (a). Also, it is false that Debian doesn't
>> take
>> our updates. They take our updates in the backports repository for
>> stable.
> 
> Nobody uses that. Users expect to receive security updates in the
> security repository.
> 

Can you please explain how you reach that conclusion?
Do you have any data to back up such claim?


I'm a Debian user and I use the backports repository extensively.
And I have the feeling that most desktop users of Debian stable also use it.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] update GCC version?

2017-01-09 Thread Carlos Alberto Lopez Perez
On 09/01/17 01:09, Michael Catanzaro wrote:
> On Sun, 2017-01-08 at 18:59 +0100, z...@falconsigh.net wrote:
>> For the record, GCC 5 has complete C++14 support. The current
>> requirement is 4.9, so the bump would be minimal.
>> https://gcc.gnu.org/projects/cxx-status.html#cxx14
> We would need to redefine our dependencies policy:
> 
> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
> 
> We just recently crafted that policy. I kinda like it because it
> provides a clear formula for deciding whether a compiler is too new to
> be required or not. It means we would support GCC 4.9 until roughly
> next spring/summer, one year from the next Debian release. We could
> either (a) drop Debian from the policy, which I support doing anyway
> because it does not take our security updates, or we could (b) define
> the policy in terms of runtime dependencies, rather than build
> dependencies (which I think Carlos Garcia wanted to do anyway). Either
> way makes it more likely that distributions will get cut off and choose
> to not provide WebKit security updates. I would prefer not to do (b),
> because in practice distributions will just not take our updates if
> they can't use their default compiler.
> 

I strongly oppose to do (a). Also, it is false that Debian doesn't take
our updates. They take our updates in the backports repository for stable.

I also don't like (b).

Another idea is: (c) Drop the "one year after the release" requirement.
Which means that we could update to minimum GCC version to 5.3 (the one
in last Ubuntu LTS) when Debian 9 is released (which hopefully is
expected to happen around the middle of 2017).

A date that I guess will be near enough to when VS2017 is released.

This will mean that instead of supporting up to 3-year old dependencies
we will only support up to 2-year old ones.
I'm not particular enthusiast about this, but I'm ready to understand
that supporting 3-year old dependencies is not realistic on a project
like WebKit.

> Keep in mind that for a distro to upgrade from GCC 4.9 -> 5.0 is weeks
> of effort unless you build GCC with the flag that turns on the old C++
> ABI, but you have to switch to the new ABI eventually, so might as well
> do it at the same time. I have to support WebKit for a distribution
> that has been delaying the upgrade for this reason. GCC upgrades are
> expensive and not fun. Even turning off the ABI switch, upgrading GCC
> means lots of obscure C++ build failures in packages you're not
> familiar with.
> 
> Michael

Another (maybe easier) way forward for building it on distros that have
libstdc++ < 5.0 is to use clang.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2016-04-29 Thread Carlos Alberto Lopez Perez
On 29/04/16 19:58, Lucas Forschler wrote:
>> I wonder if it would be possible to also allow contributors (as listed
>> in the "Contributors" field of contributors.json) to edit the wiki?
>>
>> We have a need to allow WebKitGTK+ gardeners (some of them still not
>> committers) to edit the WiKi.
> 
> This should be possible. Please file a bugzilla and I’ll investigate what 
> it’s going to take to get this working.
> 

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

Thanks!



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2016-04-29 Thread Carlos Alberto Lopez Perez
On 21/04/16 19:30, Lucas Forschler wrote:
> Hello everyone,
> 
> I’d like to follow up on the current wiki situation.
> 
> In the past, any authenticated trac.webkit.org user was allowed to
> modify or create wiki entries. However, with the recent spam
> infiltration, this is no longer viable. To solve this, I’ve removed
> WIKI_MODIFY and WIKI_CREATE permissions from the authenticated users
> group. This seems to have eliminated spam from making it to the wiki
> pages.
> 
> We currently have a ‘developer' group on trac, which contains all
> members with svn committer privileges.  This group has WIKI_MODIFY
> and WIKI_CREATE permissions. Using this mechanism means only users
> with svn committer privileges are now allowed to create or modify
> wiki entries. I am hoping this will be sufficient moving forward. I
> do understand that there may be folks who contribute to WebKit, but
> are not svn committers. If there is sufficient desire, I can
> investigate another level of access.
> 
> Please let me know if you have any concerns.
> 
> thanks, Lucas

I wonder if it would be possible to also allow contributors (as listed
in the "Contributors" field of contributors.json) to edit the wiki?

We have a need to allow WebKitGTK+ gardeners (some of them still not
committers) to edit the WiKi.

Thanks



signature.asc
Description: OpenPGP digital signature
___
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

2016-04-19 Thread Carlos Alberto Lopez Perez
On 18/04/16 21:50, Filip Pizlo wrote:
> 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.
> 

MIPS is still relevant on embedded devices (mainly set-top boxes).
It is also a popular platform for IoT projects.

I understand that you don't want to spend time supporting this
architecture, and that is ok. Nobody is proposing here that JSC
developers should spend time maintaining JSC on MIPS.

However, if someone is willing to do the work, I think we should let
them do it and don't actively block it.

Having a buildbot testing JSC on MIPS certainly helps anyone interested
in maintaining this architecture.

And anybody not interested in MIPS, can just ignore this bot.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Some text about the B3 compiler

2016-02-03 Thread Carlos Alberto Lopez Perez
On 02/02/16 00:27, Ryosuke Niwa wrote:
> 
> We've been running those benchmarks with
> http://trac.webkit.org/browser/trunk/Tools/Scripts/run-benchmark
> 
> It might be useful for Mac and other ports to have bots available on
> build.webkit.org as well.
> 

After discussing this with Carlos Garcia. We think we will do the following:

1. Implement support on this run-benchmark script to execute the tests also on 
the WebKitGTK+ MiniBrowser.
2. Create a new step 'benchmark-test' for the bots to execute this script.
3. Make the current WebKitGTK+ performance test bot [1] run this step after the 
current 'perf-tests' step.
4. Hope that Apple makes public their private performance dashboard so we can 
tell the bot to upload the results there.

That way we will be running this JSC tests automatically on a browser helping 
to catch failures.

Any comment/suggestion regarding the plan is welcome.

Regards.


[1] 
https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Perf%29



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Some text about the B3 compiler

2016-02-02 Thread Carlos Alberto Lopez Perez
On 02/02/16 00:27, Ryosuke Niwa wrote:
> On Mon, Feb 1, 2016 at 7:32 AM, Carlos Alberto Lopez Perez
> <clo...@igalia.com> wrote:
>> On 31/01/16 05:16, Filip Pizlo wrote:
>>> As my original message said, I was wondering if there was any support
>>> for running some JavaScript tests *in browser*.  run-jsc-stress-tests
>>> doesn’t support that because it doesn’t know what a browser is.
>>>
>>> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
>>> require a browser to run (like JetStream and Speedometer) or have
>>> significantly different behavior in the browser than in their
>>> command-line harnesses (like Kraken and Octane).  If you did have a
>>> bot that ran these tests in some GTK+ or EFL browser, you’d probably
>>> catch bugs that testing the JSC shell cannot catch.
>>>
>>> -Filip
>>
>> Some questions regarding this JSC in-browser benchmarks:
>>
>> How does the Apple port runs this? Do you use some script that is
>> currently available on the WebKit source tree? Are the buildbots running
>> this tests public?
> 
> We've been running those benchmarks with
> http://trac.webkit.org/browser/trunk/Tools/Scripts/run-benchmark
> 

I see.

But this script seems focused on comparing the performance between
different browsers (safari vs chrome vs firefox) rather than in testing
and comparing the performance between different revisions of WebKit.

Do you think it makes any difference (from the point of view of
detecting failures, not from the performance PoV) to run this tests in a
full-fledged browser like Safari rather than in WebKitTestRunner ?

We already have a performance test bot running tests inside WTR.
And I see that the current set of tests executed on this bot already
includes Speedometer, and that JetStream and Sunspider are skipped on
PerformanceTests/Skipped.

So I see some options going forward:

 - Fix the JetStream and Sunspider tests so they can be run as part of
the current run-perf-tests script that the performance bots execute.

 - Implement support on the script run-benchmark to run the tests inside
WTR, and create a new step running this script that will be executed on
the test bots.

 - Deploy a new bot that runs run-perf-tests on a full-fledged browser
like Safari or Epiphany.

I wonder what you think is the best option or if there is some option
not viable.

From my PoV, the option #1 has the advantage of reusing the current
infrastructure that collects and draws performance data at
https://perf.webkit.org

> It might be useful for Mac and other ports to have bots available on
> build.webkit.org as well.
> 

Indeed.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Some text about the B3 compiler

2016-02-02 Thread Carlos Alberto Lopez Perez
On 02/02/16 19:58, Ryosuke Niwa wrote:
> On Tue, Feb 2, 2016 at 10:42 AM, Carlos Alberto Lopez Perez
>> But this script seems focused on comparing the performance between
>> different browsers (safari vs chrome vs firefox) rather than in testing
>> and comparing the performance between different revisions of WebKit.
> 
> Not at all.  It simply supports running benchmark in other browsers.
> 
>> Do you think it makes any difference (from the point of view of
>> detecting failures, not from the performance PoV) to run this tests in a
>> full-fledged browser like Safari rather than in WebKitTestRunner ?
> 
> Yes. There are many browser features that can significantly impact the
> real world performance.
> 

I'm specifically not asking about performance, but about correctness.

This discussion was started because Filip said that running JS tests on
a browser catches many failures that are not cached when running the
tests from the terminal.

So, I'm wondering if running the JS tests on WTR or Safari makes any
difference when catching failures.

>> We already have a performance test bot running tests inside WTR.
>> And I see that the current set of tests executed on this bot already
>> includes Speedometer, and that JetStream and Sunspider are skipped on
>> PerformanceTests/Skipped.
>>
>> So I see some options going forward:
>>
>>  - Fix the JetStream and Sunspider tests so they can be run as part of
>> the current run-perf-tests script that the performance bots execute.
> 
> We should use run-benchmark instead since run-benchmark spits out the
> JSON file that's compatible with run-pref-tests.
> 

I'm a bit lost here. Are you planning to deprecate run-perf-tests with
run-benchmark? What is wrong with run-perf-tests?

>>  - Implement support on the script run-benchmark to run the tests inside
>> WTR, and create a new step running this script that will be executed on
>> the test bots.
> 
> I don't see a point in doing this.   Why is it desirable to run these
> benchmarks inside WebKitTestRunner?
> 

Less dependencies: WTR (or the MiniBrowser) is something that is
currently built by the bots on each build.
If we want to use Epiphany (for example) for the performance tests, is
another thing we have to take care of building before each run. Not a
big deal, but I wonder if is really worth.

>>  - Deploy a new bot that runs run-perf-tests on a full-fledged browser
>> like Safari or Epiphany.
> 
> We should just do this.
> 
>> I wonder what you think is the best option or if there is some option
>> not viable.
>>
>> From my PoV, the option #1 has the advantage of reusing the current
>> infrastructure that collects and draws performance data at
>> https://perf.webkit.org
> 
> We have an internal instance of the same dashboard to which we're
> reporting results of run-benchmark script.
> 

What about making this public? We will happily contribute with a
GTK+/Linux buildbot for it.


Regards.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Some text about the B3 compiler

2016-02-01 Thread Carlos Alberto Lopez Perez
On 31/01/16 05:16, Filip Pizlo wrote:
> As my original message said, I was wondering if there was any support
> for running some JavaScript tests *in browser*.  run-jsc-stress-tests
> doesn’t support that because it doesn’t know what a browser is.
> 
> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
> require a browser to run (like JetStream and Speedometer) or have
> significantly different behavior in the browser than in their
> command-line harnesses (like Kraken and Octane).  If you did have a
> bot that ran these tests in some GTK+ or EFL browser, you’d probably
> catch bugs that testing the JSC shell cannot catch.
> 
> -Filip

Some questions regarding this JSC in-browser benchmarks:

How does the Apple port runs this? Do you use some script that is
currently available on the WebKit source tree? Are the buildbots running
this tests public?

Regards
___
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

2016-02-01 Thread Carlos Alberto Lopez Perez
On 01/02/16 00:22, Eric Wing wrote:
>> Updated version of patch is here:
>> >
>> > https://github.com/annulen/webkit/commit/80e914373fc0702708e9fda0cee36ae5ccc22339
>> >
> 
> This is very cool. Thank you for doing this. I did something very
> similar in order to build JavaScriptCore for Android. Your changes
> look very similar (but much cleaner). I was hoping those Android
> changes would have been mainlined by now because that was always the
> intent, but the branch got intertwined with a WinRT branch which had
> pretty deep changes and I guess it never got cleaned up.
> https://github.com/appcelerator/hyperloop/wiki/Building-JavaScriptCore-for-Android


Due to bug 153638, today I learned that Facebook has also some scripts
for building JSC on Android. I guess you will find it interesting:

https://github.com/facebook/android-jsc
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] How to deal with 1-pixel differences in reftests ?

2015-11-18 Thread Carlos Alberto Lopez Perez
Hi,

Some reference tests give a 1-pixel or very few pixel differences [1].

I'm not sure if this really indicates a problem in the WebKit code, or
it indicates that we are just too strict not allowing even a very small
percentage in pixel differences for this kind of tests.

Should we tolerate a few pixel differences for reftests ?

I have done some tests, and the test in [1] passes for any value of
tolerance >= 0.1% (with the GTK port).

I'm inclined to allow a very small value, for example a 0.001% (that
would be 100 times stricter than the tolerance value we use for the
other tests)


Regards
---

[1]

For example, this is happening in the GTK port:
https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r192415%20%2812243%29/imported/blink/fast/canvas/canvas-clip-stack-persistence-diffs.html
The diff image normalized (so you can see where is the diff):
http://people.igalia.com/clopez/wkbug/151261/canvas-clip-stack-persistence-diff_normalized.png


___
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

2015-07-31 Thread Carlos Alberto Lopez Perez
On 30/07/15 17:30, Alexey Proskuryakov wrote:
 Hi,
 
 Which are the bots that you found missing?
 
 I don't expect any changes to how frequently the dashboard code is updated 
 just because of the switch. However, the code is in svn 
 (Tools/TestResultServer), so you are encouraged to update the list a 
 appropriate.
 
 - Alexey
 

When we deployed the last GTK test bots a year ago [1], the flakiness
dashboard was not showing this new bots.

This new site is showing it correctly.


Regards.

[1] http://article.gmane.org/gmane.os.opendarwin.webkit.gtk/1919



signature.asc
Description: OpenPGP digital signature
___
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

2015-03-19 Thread Carlos Alberto Lopez Perez
On 19/03/15 16:46, youenn fablet wrote:
 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?
 

I think that having an EWS running only the tests that the patch touches
is of limited value because a patch can break unrelated tests.

However running all the tests requires to have the tree green and this
is not possible for GTK or EFL because it will require more manpower
than the currently available.

An idea that comes to mind for running all the tests without requiring
to have the tree green is the following:

1) EWS either run all the tests without the patch or download from
https://build.webkit.org/results the results from the bot for the
revision if they are available.
2) EWS run all the tests with the patch.
3) EWS gets the diff from 1. and 2.
4) EWS runs only the tests that broke from 1 to 2 several times, in
order to discard the ones that are flaky and only report the ones that
on every run fail now.

If I'm not overlooking something, I think that this would allow to
identify what tests a given patch breaks and it won't require to have
the tree green, neither it will be affected by flaky tests.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev