Re: [webkit-dev] Running the GTK port on macOS with Docker

[Philippe Normand via webkit-dev]

Hi,

I found out that disk I/O is terribly slow on Docker for macOS. I had to
give up on my build after several hours because of that. So I tried
"Mutagen", wasn't able to make it work, and kind of gave up and moved to
the next thing on the pile of things to do... 

Today I just found one possible workaround, involving docker-sync. I'll
give this a try and report back.

Philippe

On 2021-11-23 06:02, Jean-Yves Avenard wrote:
> Hi
> 
> How is that effort going ?
> 
> Having a way to build the GTK port today would have saved me a lot of
> time. Instead I had to keep uploading patches to bugzilla to find
> compilation errors.
> 
> Jean-Yves
> 
>> On 15 Oct 2021, at 10:33 pm, Philippe Normand  wrote:
>>
>> On Fri, 2021-10-15 at 10:04 +1100, Jean-Yves Avenard wrote:
>>> Hi.
>>>
>>> Personally, I would love a way to quickly build for GTK on my Mac, as
>>> for now I had to rely on pushing to the EWS, wait for compilation
>>> errors and fix them as I went.
>>>
>>> So something running in docker using my local tree would be ideal.
>>>
>>
>> Alright, thanks for answering Jean-Yves :) I'll clean-up the experiment
>> a bit, document it and ping you for testing when it's ready.
>>
>> Philippe
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] How to set up Intellisense-ish code completion/suggestions for editing WebKit sources on macOS?

[Philippe Normand via webkit-dev]

Hi Mike,

About ccls, some of us Igalians use it on Linux, I compiled a few
tips:

https://trac.webkit.org/wiki/WebKitEmacsTips

Nowadays trunk includes a .ccls file, is it not working for you?

Alicia recently blogged about setting up clangd/VSCode, that's on Linux,
but maybe some parts apply for macOS too:

https://blogs.igalia.com/aboya/2021/10/02/setting-up-visualstudio-code-to-work-with-webkitgtk-using-clangd/

Philippe

On 2021-11-11 01:48, Michael[tm] Smith via webkit-dev wrote:
> Can anyone recommend a combination of text-editor/IDE, plugins/tooling
> (e.g., language server), and settings/config that’ll enable me to have
> usable code-(auto)completion/suggestions (like Intellisense, etc.) when
> editing WebKit sources in a macOS environment?
> 
> Specifically, I mean the particular type of code completion you get when
> you type the name of some instance of an object in your editor, and then
> a dot, and the editor then shows you a popup with the names of all the
> available member functions and data members you can use with that object.
> 
> Over the last several days, I have been trying (and failing) in multiple
> text editors to get working code completion like that set up for editing
> WebKit sources.
> 
> A big reason it doesn’t work with the WebKit sources is that all the text
> editors and tooling don’t seem to be able to find the header files
> referenced in the various .cpp sources — beginning with #include "config.h",
> but others as well.
> 
> I’m a diehard vim user, so I started out trying the available vim plugins
> that integrate with clangd. And the big problem I ran into there was that
> clangd relies on having a compile_commands.json file to work from — which
> (as far as I understand) essentially can’t be generated from the WebKit
> sources when building the macOS port (I have gleaned that’s in part due
> to the fact it’s a Unified build, which confuses clangd).
> 
> So the next thing I tried was integrating with ccls. That seems to work to
> the point of ccls successfully generating an index of sources — but then
> when I open a file to edit, I immediately get an error about ccls not being
> able to resolve the #include “config.h” reference — and the multiple errors
> about macro references it can’t resolve.
> 
> ...And then, ultimately, no completion suggests when I put a dot after a
> particular object name I want to get the function and data-member
> suggestions for. (It seems to work for some objects, but not others.)
> 
> I like ccls though, and I think (hope) it may be that if I set up my .ccls
> file with the right options for helping it find the header files it needs,
> it may actually end up working. But my current .ccls isn’t doing that.
> 
> Anyway, the last thing I’ve been trying is Visual Studio Code. In that I
> tried with both the clangd extension and the ccls extension, but ended up
> having basically the same problems I have with the vim integrations.
> 
> So I switched back to trying the Microsoft-provided C/C++ Intellisense
> extension (cpptools), and found that seems to work better than the clangd
> or ccls extensions — at least so far as it seems to be able to at last
> partially resolve the header include references. But then it too seems to
> stumble on not being able to find some headers it needs.
> 
> For example, I think I’ve been able to make it figure out #include "config.h" 
> —
> but then the next problem I hit is stuff like this:
> 
>   cannot open source file "JavaScriptCore/JSExportMacros.h"
> (dependency of "config.h")
> 
> ...And then anyway, again, ultimately, no completion suggests when I put a dot
> after a particular object name I want to get the function and data-member
> suggestions for. (It seems to work for some objects, but not others.)
> 
> So I’m hoping others here might have something working successfully in
> their environments that gives them proper completion suggestions on member-
> function names and data-member names.
> 
>   –Mike
> 
> ___
> 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] Running the GTK port on macOS with Docker

[Philippe Normand via webkit-dev]

On Fri, 2021-10-15 at 10:04 +1100, Jean-Yves Avenard wrote:
> Hi.
> 
> Personally, I would love a way to quickly build for GTK on my Mac, as
> for now I had to rely on pushing to the EWS, wait for compilation
> errors and fix them as I went.
> 
> So something running in docker using my local tree would be ideal.
> 

Alright, thanks for answering Jean-Yves :) I'll clean-up the experiment
a bit, document it and ping you for testing when it's ready.

Philippe

> Jean-Yves
> 
> > On 15 Oct 2021, at 1:21 am, Philippe Normand via webkit-dev
> >  wrote:
> > 
> > Hi,
> > 
> > The WPE/GTK ports nowadays rely on a SDK that provides all the
> > tools
> > needed for development, it's used on the bots as well. Currently we
> > run
> > it with Flatpak, but technically, Docker can also be used.
> > 
> > I've actually checked that a GTK MiniBrowser build downloaded from
> > the
> > bots can run on macOS with Docker, that involves setting up
> > XQuartz,
> > it's not great, but for quick testing, I wonder if that could be
> > useful
> > for the Apple folks?
> > 
> > The GTK port could also be built on macOS using this docker setup,
> > the
> > SDK includes the GCC and clang versions used on the bots.
> > 
> > You can already do this with a VM, but then if you want to use the
> > SDK
> > it adds another lever of virtualization, which is not great. So
> > directly using the SDK through Docker seems more appealing, to me
> > at
> > least :)
> > 
> > WPE can't run, I haven't managed to start Weston with its X11
> > backend
> > in XQuartz... Ideally I'd prefer a native Wayland compositor for
> > macOS
> > but that doesn't seem to exist yet.
> > 
> > Anyway, please let me know if some folks are interested.
> > 
> > Philippe
> > ___
> > 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

[webkit-dev] Running the GTK port on macOS with Docker

[Philippe Normand via webkit-dev]

Hi,

The WPE/GTK ports nowadays rely on a SDK that provides all the tools
needed for development, it's used on the bots as well. Currently we run
it with Flatpak, but technically, Docker can also be used.

I've actually checked that a GTK MiniBrowser build downloaded from the
bots can run on macOS with Docker, that involves setting up XQuartz,
it's not great, but for quick testing, I wonder if that could be useful
for the Apple folks?

The GTK port could also be built on macOS using this docker setup, the
SDK includes the GCC and clang versions used on the bots.

You can already do this with a VM, but then if you want to use the SDK
it adds another lever of virtualization, which is not great. So
directly using the SDK through Docker seems more appealing, to me at
least :)

WPE can't run, I haven't managed to start Weston with its X11 backend
in XQuartz... Ideally I'd prefer a native Wayland compositor for macOS
but that doesn't seem to exist yet.

Anyway, please let me know if some folks are interested.

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

Re: [webkit-dev] WebKit Transition to Git

[Philippe Normand]

This is great!

On Fri, 2020-10-02 at 09:43 -0700, Jonathan Bedard wrote:
> Hello WebKit Contributors,
> 
> This year, Apple would like to push WebKit’s source code management
> off of Subversion and onto git. Our rationale for this is the rest of
> the industry has settled on git as their source code management
> solution.  We’re also interested in moving to a hosted Git solution
> (namely, GitHub) to make it easier for new contributors to interact
> with the project. I would like to outline our plan so far, and
> solicit feedback from our contributors about some of the pieces we’re
> still discussing.
> 
> Monotonic Commit Identifiers
> Of great interest to Apple’s engineers has been retaining some kind
> of ordered tag we can use to refer to commits to make defending CI
> and bisection easier. We’ve developed a scheme for this that assigns
> commits an ordered identifier per-branch, outlined in 
> https://trac.webkit.org/wiki/commit-identifiers, designed to be used
> alongside git hashes. These identifiers can be used in our current
> Subversion repository, and we would like to start using them before
> the project has transitions to git.
> 

Have you seen how this was handled in LLVM?
https://releases.llvm.org/9.0.0/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git

Would you also consider preventing merge commits in order to keep a
clean mainline branch?

Philippe

> Hosting the Repository
> We're most likely going to be hosting the repository in public
> GitHub. The rationale for choosing GitHub over alternatives (namely,
> GitLab) is that GitHub has a far more active community, and Apple
> would like WebKit to be more connected to the open source community.
> For this reason, we prefer to place the canonical WebKit repository
> on public GitHub so the project is more accessible to new
> contributors, although some concerns have been raised about GitHub’s
> terms and conditions, which contributors of WebKit would need to
> agree to in addition to the terms and conditions of the WebKit
> project. We are interested in what our current community of
> contributors thinks about this, and what preferences contributors may
> have.
> 
> Patches to Pull Requests
> In the coming months, more automation will start using the git
> version of the repository instead of the Subversion version. Even
> immediately after we switch, the patch review workflow will remain
> what it is now (EWS bots mostly already use a git clone as their
> checkout). We do, however, intend to switch from a system of patch
> review to a system of pull requests. This process will be incremental
> and the patch review system will remain alive as long as Bugzilla
> does.
> 
> GitHub Issues
> The last part of transitioning away from Subversion is to re-evaluate
> our bug tracker. Bugzilla has served us well, but seems to be an
> impediment to engaging with the open source community. We are
> interested in moving away from Bugzilla and to GitHub Issues,
> allowing new developers to work with a system they are likely already
> familiar with and to allow us closer integration with repositories
> managed by W3C. Although GitHub Issues has had performance problems
> in the past with projects that have many bugs, these performance
> problems have been resolved to the satisfaction of a few large
> projects hosted on GitHub that are of a comparable scale to WebKit.
> The biggest blocker we are aware of is managing security bugs, since
> the security advisory system used by GitHub is essentially the
> opposite of how WebKit security bugs work. Moving to GitHub Issues,
> if it happens, will be the last part of this transition, and we are
> interested in soliciting feedback from our contributors on what the
> WebKit project’s integration with GitHub Issues should look like.
> 
> Look forward to hearing from all of you,
> 
> Jonathan Bedard
> WebKit Operations
> ___
> 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

[webkit-dev] PSA: Flatpak WPE/GTK SDK upgrade to version 0.3

[Philippe Normand]

Hi,

This mail is mostly for WPE/GTK port developers. Feel free to skip if
you're not part of that group.

In r266455[0] the SDK build definitions were updated along with a major
upgrade to the FDO SDK version 20.08. Compared with 19.08, this new
version breaks ABI, that means applications built for 19.08 will not
work in 20.08 and need to be rebuilt. So if you are working with the
GTK and/or WPE ports and using the Flatpak SDK, you will need to remove
your local build directories after this patch lands:

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

Additionally, you will need to run `Tools/Scripts/update-webkitgtk-
libs` or `Tools/Scripts/update-webkitwpe-libs` so that version 0.3 is
locally installed on your workstation.

We plan to land this patch soon, during the early European morning, in
order to avoid major service disruption on the bots and EWS.

Philippe

[0] https://trac.webkit.org/r266455

___
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

[Philippe Normand]

On Wed, 2020-07-22 at 08:24 -0500, Michael Catanzaro wrote:
> On Wed, Jul 22, 2020 at 11:15 am, shriva...@firemail.cc wrote:
> > DerivedSources/ForwardingHeaders/JavaScriptCore/JSContext.h:40:1: 
> > error: duplicate interface definition for class 'JSContext'
> > @interface JSContext : NSObject
> > ^
> > ../../Source/JavaScriptCore/API/JSContext.h:40:12: note: previous 
> > definition is here
> > @interface JSContext : NSObject
> >^
> > 
> > Your assistance would be much appreciated.
> 
> It might be time to simply remove support for building WebKitGTK on 
> macOS. I imagine it's been many years since anyone has successfully 
> built it.
> 

jmercouris on IRC reported yesterday that he got it to build on macOS.
IIUC he's working on the macports project.

Philippe

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

Re: [webkit-dev] PSA: Changes in the recommended GTK/WPE developer workflow

[Philippe Normand]

Hi,

A few updates about this topic. Read below!

On Tue, 2020-03-17 at 17:31 +, Philippe Normand wrote:
> Hi,
> 
> Until now the most recommended way to work on the GTK and WPE ports
> was
> to use a custom JHBuild[0] moduleset ([1][2]) for build/runtime
> dependencies. This setup was deployed almost 10 years ago [3] and
> while
> it is an opt-in approach, it is highly recommended, especially if you
> want to run layout tests locally.
> 
> If you ever executed Tools/Scripts/update-webkitgtk-libs or
> Tools/Scripts/update-webkitwpe-libs it means you currently have a
> DependenciesGTK and/or DependenciesWPE folder in WebKitBuild/ and
> that
> your workflow is JHBuild-based.
> 
> JHBuild has various shortcomings, even though it served us well all
> these years:
> 
> - if the moduleset is modified, the bots remove the whole
> Dependencies{GTK,WPE} folders and rebuild everything from scratch
> - no cross-compilation support
> - no clear separation between the host system and the JHBuild-based
> sysroot
> - poor system requirements management (See the install-dependencies
> scripts in Tools/{wpe,gtk})
> - time lost rebuilding the dependencies (can take up to an hour on my
> build machine)
> 
> So in order to improve our lives a bit, we decided to try a new
> workflow, this time based on Flatpak[4]. Instead of having every
> developer locally build the dependencies, the built sysroot will be
> packaged in a Flatpak SDK/Runtime and downloaded to the developer
> machine. Currently the SDK is built for X86_64 but additional
> architectures can be supported (ARMv7, Aarch64 at least).
> 
> The advantages of this new approach:
> 
> - cross-compilation can easily be achieved
> - clear separation between the host system and the SDK sysroot
> - the SDK runs in a sandbox
> - unified toolchain for WebKit build (currently both GCC 9.2.0 and
> clang 8.0.1)
> - no time lost rebuilding dependencies :)
> - consistent layout tests coverage across different hosts
> - separate build directories for each port (example:
> WebKitBuild/GTK/Release
>   mounted as /app/WebKit/WebKitBuild/Release in the SDK sandbox)
> 
> As a bonus, this setup allows for:
> 
> - integration with sccache, for faster WebKit builds
> - builtin IceCC support without additional manual steps (you still
> need
> a scheduler running on the host system though)
> 
> The only disadvantage of this new approach is that hacking on
> dependencies is currently not trivial to accomplish. We plan to
> enable
> this most likely via the Flapjack[5] tool.
> 

Flapjack was discarded, for now, because Buildstream provides a good
workflow already.

> Once the patch from bug#205658 [6] lands, this workflow will be
> available. How do I use it? Easy:
> 
> 1. Make sure your flatpak version is recent enough, 1.4.4 is the
> minimum version we support. Backports for Debian stable are available
> and for Ubuntu LTS, a PPA is available. See the Flathub instructions
> (though you don't need to manually add the flathub remote) [7].
> 
> 2. Run update-webkitgtk-libs or update-webkitwpe-libs as usual. This
> will download and install the SDK in WebKitBuild/UserFlatpak/
> 
> 3. Run build-webkit as usual
> 
> The SDK will be used when running the tests (API, layout, webkitpy,
> etc) and the MiniBrowser.
> 
> For the time being we keep the JHBuild workflow in the SVN, although
> if
> everything goes well, it will be removed in the coming months. Hence
> we
> encourage all GTK/WPE developers to try this new workflow!
> 
> If you still want to keep using JHBuild, make sure to set the
> WEBKIT_JHBUILD=1 environment variable in your shell. But keep in mind
> that we intend to remove support for JHBuild if Flatpak works as
> expected (so please try to test it, and report any issue with it).
> The
> GTK/WPE buildbots and EWS are currently running with JHBuild and will
> be switched one-by-one to Flatpak soon.
> 

The bots now use the SDK, thanks to Diego Pino, Lauro Mauro and Carlos
López. Many thanks to them :)

> The SDK sources are currently hosted on Github[8], but we might move
> them to WebKit's SVN.
> 

This is done now, as of:
https://trac.webkit.org/r261274

Philippe


> Philippe
> 
> [0] https://developer.gnome.org/jhbuild/stable/
> [1] https://trac.webkit.org/browser/trunk/Tools/gtk/jhbuild.modules
> [2] https://trac.webkit.org/browser/trunk/Tools/wpe/jhbuild.modules
> [3] https://bugs.webkit.org/show_bug.cgi?id=73425
> [4] https://flatpak.org/
> [5] https://github.com/endlessm/flapjack
> [6] https://bugs.webkit.org/show_bug.cgi?id=205658
> [7] https://flatpak.org/setup/
> [8] https://github.com/igalia/webkit-flatpak-sdk
> 
> ___
> 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] PSA: Changes in the recommended GTK/WPE developer workflow

[Philippe Normand]

On Tue, 2020-03-17 at 17:31 +, Philippe Normand wrote:

> The only disadvantage of this new approach is that hacking on
> dependencies is currently not trivial to accomplish. We plan to
> enable
> this most likely via the Flapjack[5] tool.
> 

I forgot to mention (quoting the ChangeLog):

As an additional commodity, the new environment supports the
GStreamer gst-build-based workflow. Just set the GST_BUILD_PATH
environment variable to your gst-build path. This feature was
contributed by Thibault Saunier.

> Once the patch from bug#205658 [6] lands, this workflow will be
> available. 

The patch landed in r258626.

Happy hacking!
Philippe

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

[webkit-dev] PSA: Changes in the recommended GTK/WPE developer workflow

[Philippe Normand]

Hi,

Until now the most recommended way to work on the GTK and WPE ports was
to use a custom JHBuild[0] moduleset ([1][2]) for build/runtime
dependencies. This setup was deployed almost 10 years ago [3] and while
it is an opt-in approach, it is highly recommended, especially if you
want to run layout tests locally.

If you ever executed Tools/Scripts/update-webkitgtk-libs or
Tools/Scripts/update-webkitwpe-libs it means you currently have a
DependenciesGTK and/or DependenciesWPE folder in WebKitBuild/ and that
your workflow is JHBuild-based.

JHBuild has various shortcomings, even though it served us well all
these years:

- if the moduleset is modified, the bots remove the whole
Dependencies{GTK,WPE} folders and rebuild everything from scratch
- no cross-compilation support
- no clear separation between the host system and the JHBuild-based
sysroot
- poor system requirements management (See the install-dependencies
scripts in Tools/{wpe,gtk})
- time lost rebuilding the dependencies (can take up to an hour on my
build machine)

So in order to improve our lives a bit, we decided to try a new
workflow, this time based on Flatpak[4]. Instead of having every
developer locally build the dependencies, the built sysroot will be
packaged in a Flatpak SDK/Runtime and downloaded to the developer
machine. Currently the SDK is built for X86_64 but additional
architectures can be supported (ARMv7, Aarch64 at least).

The advantages of this new approach:

- cross-compilation can easily be achieved
- clear separation between the host system and the SDK sysroot
- the SDK runs in a sandbox
- unified toolchain for WebKit build (currently both GCC 9.2.0 and
clang 8.0.1)
- no time lost rebuilding dependencies :)
- consistent layout tests coverage across different hosts
- separate build directories for each port (example:
WebKitBuild/GTK/Release
  mounted as /app/WebKit/WebKitBuild/Release in the SDK sandbox)

As a bonus, this setup allows for:

- integration with sccache, for faster WebKit builds
- builtin IceCC support without additional manual steps (you still need
a scheduler running on the host system though)

The only disadvantage of this new approach is that hacking on
dependencies is currently not trivial to accomplish. We plan to enable
this most likely via the Flapjack[5] tool.

Once the patch from bug#205658 [6] lands, this workflow will be
available. How do I use it? Easy:

1. Make sure your flatpak version is recent enough, 1.4.4 is the
minimum version we support. Backports for Debian stable are available
and for Ubuntu LTS, a PPA is available. See the Flathub instructions
(though you don't need to manually add the flathub remote) [7].

2. Run update-webkitgtk-libs or update-webkitwpe-libs as usual. This
will download and install the SDK in WebKitBuild/UserFlatpak/

3. Run build-webkit as usual

The SDK will be used when running the tests (API, layout, webkitpy,
etc) and the MiniBrowser.

For the time being we keep the JHBuild workflow in the SVN, although if
everything goes well, it will be removed in the coming months. Hence we
encourage all GTK/WPE developers to try this new workflow!

If you still want to keep using JHBuild, make sure to set the
WEBKIT_JHBUILD=1 environment variable in your shell. But keep in mind
that we intend to remove support for JHBuild if Flatpak works as
expected (so please try to test it, and report any issue with it). The
GTK/WPE buildbots and EWS are currently running with JHBuild and will
be switched one-by-one to Flatpak soon.

The SDK sources are currently hosted on Github[8], but we might move
them to WebKit's SVN.

Philippe

[0] https://developer.gnome.org/jhbuild/stable/
[1] https://trac.webkit.org/browser/trunk/Tools/gtk/jhbuild.modules
[2] https://trac.webkit.org/browser/trunk/Tools/wpe/jhbuild.modules
[3] https://bugs.webkit.org/show_bug.cgi?id=73425
[4] https://flatpak.org/
[5] https://github.com/endlessm/flapjack
[6] https://bugs.webkit.org/show_bug.cgi?id=205658
[7] https://flatpak.org/setup/
[8] https://github.com/igalia/webkit-flatpak-sdk

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

Re: [webkit-dev] Moving to Python 3

[Philippe Normand]

Hi folks,

Now that Catalina is released, can we move on to some of the proposed
changes discussed in this thread?

Philippe

On Fri, 2019-07-12 at 12:18 -0700, Jonathan Bedard wrote:
> Hello WebKit developers,
> 
> Now that the Catalina developer seeds are available, it is official
> that the new Mac developer tools come with Python 3. As a result, we
> need to continue the ongoing discussion about migrating our Python
> 2.7 scripts to Python 3.
> 
> I propose that, over the next 9 months, we do the following:
> 
> 1. Make any no-cost Python 3 compatibility changes, in particular
> - print foo -> print(foo)
> - import .foo -> import webkitpy.foo
> 2. Convert any scripts not used in automation to Python 3 ASAP
> (scripts like bisect-builds, block-spammers, compare-results)
> 3. Make most Python 3 compatibility changes which sacrifice
> efficiency, subject to a case-by-case audit. These would be things
> like:
> - dict.iteritems() -> dict.items()
> - dict.items() -> list(dict.items())
> 4. Install Python 3 on macOS Sierra and Mojave bots
> 5. Convert peripheral automation scripts to Python 3 1-by-1 (scripts
> like clean-webkit, merge-results-json, webkit-patch)
> 6. Convert testing scripts and webkitpy to Python 3 in a single
> change
> 
> The trouble I foresee us encountering with any scheme which attempts
> a conversion which retains both Python 2.7 and Python 3 compatibility
> is code like this:
> 
> for expectation_string, expectation_enum in
> test_expectations.TestExpectations.EXPECTATIONS.iteritems():
> ...
> 
> In this code, the EXPECTATIONS dictionary is thousands of elements
> long. In Python 2.7, iteritems() gives us an iterator instead of
> creating a new list, like items() would. In Python 3, iteritems()
> doesn’t exist, but items() does, and now gives us an iterator instead
> of creating a new list. The trouble here is that, in this case,
> creating a new list will be very expensive, expensive enough that we
> might manage to impact the testing run. There isn’t really an elegant
> way around this problem if we want to support both Python 2.7 and
> Python 3, other than defining different code paths for each language.
> 
> There are other small gotchas as well. For example, ‘%’ is no longer
> a protected character, which can actually change the behavior of
> regexes. That’s why I think it’s better to just try and directly
> convert things instead of attempting to be compatible with both
> Python 2.7 and Python 3.
> 
> Jonathan
> ___
> 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] Moving to Git

[Philippe Normand]

On Wed, 2019-02-20 at 09:40 -0800, Ryosuke Niwa wrote:
> 
> On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker <
> bug.tracking.acco...@protonmail.com> wrote:
> > I was curious about the status of the proposal for migrating from
> > SVN to Git (https://trac.webkit.org/wiki/Moving%20to%20Git).
> > 
> > The relevant page on the Trac wiki hasn't been updated for over 5
> > years and since then Git has become much more popular (the de facto
> > standard for new projects, more or less), while:
> > SVN support is diminishing (e.g. in Xcode).
> > Git support on Windows is much better than 5 years ago.
> > It's difficult to find free robust SVN clients / UIs, unlike the
> > plethora of options available for Git.
> > Most young and relatively new developers (with less than 10 years
> > of experience, like myself) are much more comfortable with Git and
> > maybe have not even used SVN before, so moving to Git could
> > encourage more users and contributors.
> > 
> > Is there any progress in this direction?
> > 
> 
> No progress has been made as far as I can tell. Every other year or
> so, this topic comes up on webkit-dev, and the outcome is always the
> same.
> 
> We need a monotonically increasing revision number to track down perf
> regressions, etc... yet nobody has put the time & effort to create a
> solution with Git. 

Quoting the wiki page linked above:

Some previously svn projects have worked around this. For example,
Haiku uses automatic linear tags on each push. 
http://cgit.haiku-os.org/haiku/log/

Philippe

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

Re: [webkit-dev] Freenode spam counter-measure

[Philippe Normand]

Also the WKR and webkitbot bots will need to be registered with NickServ, 
otherwise their notifications in the channel won’t be delivered :)

Philippe

> On 6 Aug 2018, at 16:18, Philippe Normand  wrote:
> 
> 
> 
>> On 6 Aug 2018, at 16:12, Darin Adler  wrote:
>> 
>>> On Aug 6, 2018, at 5:22 AM, Konstantin Tokarev  wrote:
>>> 
>>>>> On Aug 5, 2018, at 2:38 AM, Philippe Normand  wrote:
>>>>> 
>>>>> Can one of the #webkit admin please set the +r mode on? This would help 
>>>>> reducing spam. Only messages from registered nicks would come through.
>>>> 
>>>> I tried this by typing this:
>>>> 
>>>>   /msg ChanServ set #webkit restricted on
>>> 
>>> This command works differently from +r: it forbids join for people who are 
>>> not in access list, instead of simply forbidding unregistered users.
>> 
>> What’s the ChanServ function for setting +r?
>> 
> 
> I think it is:
> 
> /msg chanserv set #webkit mlock +r
> 
> Philippe
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <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] Freenode spam counter-measure

[Philippe Normand]

> On 6 Aug 2018, at 16:12, Darin Adler  wrote:
> 
>> On Aug 6, 2018, at 5:22 AM, Konstantin Tokarev  wrote:
>> 
>>>> On Aug 5, 2018, at 2:38 AM, Philippe Normand  wrote:
>>>> 
>>>> Can one of the #webkit admin please set the +r mode on? This would help 
>>>> reducing spam. Only messages from registered nicks would come through.
>>> 
>>> I tried this by typing this:
>>> 
>>>/msg ChanServ set #webkit restricted on
>> 
>> This command works differently from +r: it forbids join for people who are 
>> not in access list, instead of simply forbidding unregistered users.
> 
> What’s the ChanServ function for setting +r?
> 

I think it is:

/msg chanserv set #webkit mlock +r

Philippe

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

[webkit-dev] Freenode spam counter-measure

[Philippe Normand]

Hi,

Can one of the #webkit admin please set the +r mode on? This would help 
reducing spam. Only messages from registered nicks would come through.

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

Re: [webkit-dev] how to enable waylandsink on webkit2?

[Philippe Normand]

Hi,

Please use the webkitgtk list next time, this is a topic specific to that port…

It is not advised to use a sink different to the one WebKit already uses 
internally. It should work fine without any change, the internal appsink should 
negotiate caps for GL texture-based rendering.

Please file a bug, providing GStreamer version and a log file produced with the 
following command:

$ GST_DEBUG=3,webkit*:6 GST_DEBUG_FILE=gst.log yourfancybrowser 

And try WebKitGTK 2.20.x.

Philippe

> On 17 May 2018, at 12:09, tugouxp <13824125...@163.com> wrote:
> 
> hi folks:
>i meet a problem when test the midori browser with   tag,  
> the player window was lost with nothing, 
> 
> but, from the pipeline message it seems the decoder pipeline goto the  state 
> pause, wating for the play trigger, so i guess it maybe something wrong with 
> the display part, from the log ,i know the default display sinker is 
> "webkit-gl-video-sink"
> not the waylandsink, which is our platfom supported!  
> 
> so my webkit version is 2.18.6, how can i enable the waylandsink by default 
> on it?  thanks for your kindly support.
> 
> Message tag received from element webkit-gl-video-sinkhandleMessage line 920.
> Message tag received from element webkit-gl-video-sinkhandleMessage line 920.
> Message tag received from element webkit-gl-video-sinkhandleMessage line 920.
> Message state-changed received from element webkit-gl-video-sinkhandleMessage 
> line 920.
> Message state-changed received from element bin0handleMessage line 920.
> Message state-changed received from element sinkhandleMessage line 920.
> Message state-changed received from element vbinhandleMessage line 920.
> Message state-changed received from element playsinkhandleMessage line 920.
> Message state-changed received from element playState: PAUSED, pending: 
> VOID_PENDINGNetwork State Changed from 2 to 3Ready State Changed from 0 to 
> 4Duration: 0:00:12.61200Position 0:00:00.0Position 0.
> Message async-done received from element playState: PAUSED, pending: 
> VOID_PENDINGdebug  : omx_vdec : *** call 
> SetVideoFbmBufAddress: pVideoPicture(0x2f662d8)
> 
> 
> 
> 
>  
> 
> ___
> 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] Status of GTK EWS bot?

[Philippe Normand]

Hi Darin,

The GTK EWS is back online. It wasn't properly rebooted after some
systems maintenance tasks at our office yesterday. Sorry about this :)

Philippe

On Mon, 2016-10-24 at 22:56 -0700, Darin Adler wrote:
> Hi folks.
> 
> As I am uploading patches to  =163876> for EWS processing I noticed that all the other platforms
> said “#1”, but gtk-wk2 said #85.
> 
> Is this just the bot falling a bit behind because of load, or is
> there a more serious problem? This is important to me because without
> the bot it is highly likely my patch will break the build for GTK; I
> normally update the GTK bindings code after the build failures on EWS
> expose which functions need updating.
> 
> — Darin
> ___
> 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] Are there any plans to upgrade SVN server on svn.webkit.org?

[Philippe Normand]

The commit-queue seems to be broken as well, one example:
https://bugs.webkit.org/show_bug.cgi?id=148524
:04 04 105f7e2febfadc8d1f550aa805ccd215e8f27c27
f3f1d4fa1265a983a518943e7e3a0f794477e6bd M  Source
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.Seems to be a consequence of the git 
mirror sync bug.
Philippe
On Mon, 2016-06-20 at 13:29 +0900, Yusuke SUZUKI wrote:
> Great work, thanks.
> 
> I've just noticed that the ToT git revision in
> git://git.webkit.org/WebKit.git is r202198 while ToT SVN revision is
> r202223.
> 
> On Mon, Jun 20, 2016 at 3:30 AM, Lucas Forschler 
> m> wrote:
> > svn.webkit.org is back online.
> > Please let me know if you see any problems.
> > 
> > I will be doing minor additional maintenance later this week. I do
> > not expect the downtime to be nearly as significant as this
> > upgrade. I’ll send email with advance notice of additional
> > downtime.
> > Lucas
> > 
> > 
> > > On Jun 18, 2016, at 10:51 PM, Lucas Forschler 
> > > om> wrote:
> > > 
> > > Update: The svn data migration to the new format is currently
> > > about 1/3 of the way completed. I’ll post another progress update
> > > Sunday morning (Pacific time zone).
> > > Thanks,
> > > Lucas
> > > 
> > > 
> > > > On Jun 18, 2016, at 5:14 PM, Lucas Forschler 
> > > > com> wrote:
> > > > 
> > > > I’m starting this now. svn.webkit and build.webkit will be
> > > > going down shortly.
> > > > I’ll send an all-clear email when things are back online.
> > > > 
> > > > Lucas
> > > > 
> > > > > On Jun 18, 2016, at 9:54 AM, Lucas Forschler 
> > > > > e.com> wrote:
> > > > > 
> > > > > Hello Folks,
> > > > > 
> > > > > I plan on updating the svn repository from version 1.6.11 to
> > > > > 1.9.4 tonight. I will likely start this process sometime this
> > > > > late afternoon. svn.webkit.org will be down during this time.
> > > > > I will also be taking build.webkit.org offline, so our bots
> > > > > do not fail due to a missing svn server. 
> > > > > 
> > > > > I will also be taking this time to upgrade the backend
> > > > > datastore on svn.webkit.org. This process requires a full svn
> > > > > dump/load cycle, and takes a significant amount of time. I
> > > > > expect the the server to return online Sunday by end of day.
> > > > > 
> > > > > Please let me know if you have any questions.
> > > > > I’ll send another email before I take the servers offline.
> > > > > Lucas
> > > > > 
> > > > > 
> > > > > > On Apr 27, 2016, at 5:13 AM, Konstantin Tokarev 
> > > > > > ndex.ru> wrote:
> > > > > > 
> > > > > > 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.ht
> > > > > > ml
> > > > > > https://subversion.apache.org/docs/release-notes/1.8.ht
> > > > > > ml
> > > > > > https://subversion.apache.org/docs/release-notes/1.9.ht
> > > > > > ml
> > > > > > [3] https://subversion.apache.org/docs/release-notes/1.7.ht
> > > > > > ml#httpv2
> > > > > > [4] https://subversion.apache.org/docs/release-notes/1.8.ht
> > > > > > ml#fsfs-enhancements
> > > > > >    https://subversion.apache.org/docs/release-notes/1.9.htm
> > > > > > l#fsfs-improvements
> > > > > > [5] https://subversion.apache.org/docs/release-notes/1.8.ht
> > > > > > ml#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
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Commit queue issues

[Philippe Normand]

Hi,

It seems the commit queue cannot land patches?

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

Philippe


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] what command used to install compiled webkitgtk?

[Philippe Normand]

 On 26 Aug 2015, at 19:58, Konovalov, Vadim vadim.konova...@emc.com wrote:
 
 after
 
   build-webkit --gtk --prefix=/foo/bar
 
 then I want to install so installation goes to the said prefix, how should I 
 do that?
 (I've searched but haven't found the answer)

This mailing list isn’t for WebKitGTK users help, please use the webkit-gtk 
list next time.

build-webkit installs everything to WebKitBuild/. This tool is for developers, 
not end-users. If you need to build and install WebKitGTK in a custom directory 
you should directly use CMake.

First hit on Google :)
http://www.linuxfromscratch.org/blfs/view/svn/x/webkitgtk.html 
http://www.linuxfromscratch.org/blfs/view/svn/x/webkitgtk.html

Philippe


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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.

[Philippe Normand]

Same for the git mirror. Very slow from Spain, at least.

Philippe

On Tue, 2015-08-25 at 12:33 +0900, Gyuyoung Kim wrote:
 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 
 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
  
 ___
 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] migrating from 2.4.6 to 2.8.1

[Philippe Normand]

Hi Jerry,

Please use webkit-...@lists.webkit.org for WebKitGTK topics.

On Mon, 2015-05-04 at 10:43 -0400, Jerry Geis wrote:
 I am migrating from 2.4.6 to 2.8.1...
 
 
 under 2.4.6 there was a ./configure script - that appears to be gone.
 (Not sure why, thought that was a standard thing).
 

We moved to CMake for the build.

 
 So then I searched for building webkit and I found 
 Tools/Scripts/build-webkit
 
 
 So I looked in that directory in 2.8.1 and that file is not present.
 

build-webkit should only be used when building a development version of
WebKitGTK. For releases please use CMake:

cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=Release .

Philippe

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

Re: [webkit-dev] gtk failure

[Philippe Normand]

Hi Said,

Can you please resubmit your patch? The EWS build directory was
cleaned-up.

Philippe

On Fri, 2014-10-31 at 09:55 -0700, Said Abou-Hallawa wrote:
 I submitted a patch for the bug https://bugs.webkit.org/show_bug.cgi?id=137132
 The build failed for gtk-wk2 but passed for mac and mac-wk2.  Here is the 
 failure.
 
 Last 500 characters of output:
 e/CMakeFiles/WebCore.dir/rendering/style/RenderStyle.cpp.o -c 
 ../../Source/WebCore/rendering/style/RenderStyle.cpp
 ../../Source/WebCore/rendering/style/RenderStyle.cpp: In member function 
 'WebCore::Color WebCore::RenderStyle::colorIncludingFallback(int, bool) 
 const':
 ../../Source/WebCore/rendering/style/RenderStyle.cpp:1525:10: error: 
 'CSSPropertyWebkitColumnRuleColor' was not declared in this scope
  case CSSPropertyWebkitColumnRuleColor:
 
 
 In the patch I have the following change 
 
 
 Source/WebCore/rendering/style/RenderStyle.cpp
 @@Color RenderStyle::colorIncludingFallbac
 15221522 case CSSPropertyOutlineColor:
 15231523 result = visitedLink ? visitedLinkOutlineColor() :
 outlineColor();
 15241524 break;
 
 1525  case CSSPropertyWebkitColumnRuleColor:
  1525 case CSSPropertyColumnRuleColor:
 
 15261526 result = visitedLink ? visitedLinkColumnRuleColor() :
 columnRuleColor();
 15271527 break;
 15281528 case CSSPropertyWebkitTextDecorationColor:
 
 
 
 
 I am un-prefixing the column rule color property.  So I replaced
 CSSPropertyWebkitColumnRuleColor with CSSPropertyColumnRuleColor.  But
 the failure is saying the prefixed property is not defined.  
 
 
 How can for gtk-wk2 only, the patch is not applied in RenderStyle.cpp
 but is applied with other files and is applied also for all files for
 the mac platform?
 
 
 Thanks,
 Said
 ___
 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] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

[Philippe Normand]

Hi!

I'm using the XML-RPC API (via git-bz) and when attaching a patch to a
bug I get the following error:

There was an error sending mail from 'bugzilla-daemon#64;webkit.org'
to 'zandobersek#64;gmail.com': 
Couldn't connect to bz.apple.com 

Before the Bugzilla upgrade the smtp server was mail.webkit.org. Any
chance to restore it?

I would have opened a new bug in bugzilla but this error would prevent
it :)

Philippe

On Thu, 2014-10-16 at 01:48 -0700, David Kilzer wrote:
 Hi,
 
 
 We’re planning on upgrading Bugzilla (bugs.webkit.org) from 3.2.3 to
 4.2.11 on Thursday, October 16 from 8-10 AM PDT.
 
 
 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Trying to turn WebRTC's code on - MEDIA_STREAM flags

[Philippe Normand]

On Wed, 2014-07-30 at 17:51 +0800, Jacques-Olivier wrote:
 Hi everyone, me again,
 
 
 I kept working on getting media_stream to work. I think my
 understanding of what is happening improved, but I’m still stuck at
 the same point:
 
 
 I read some more code and did some research about the Supplement and
 Supplementable classes.
 I mainly found this page which explains that Supplements are used to
 extract code from “massive” classes and make then more manageable and
 maintainable.
 Please correct me if I am wrong.
 
 
 Anyway, it doesn’t change that my program has no Supplement for the
 key “UserMediaController”.
 It looks like most of the supplements are being provided in two
 places:
   * WebKit::WebView::_commonInitializationWithFrameName
   * WebKit2::WebPage ’s constructor
 is there any other place where it should be done?
 
 
 WebView actually contains a call to WebCore::provideUserMediaTo which
 creates a supplement, but my debugging show that
 _commonInitializationWithFrameName is never called.
 WebPage’s constructor does not generate a UserMediaController
 supplement.
 
 
 My understanding of the WebView is that it is the rectangle in which
 the webpages are rendered. Is this assumption correct?
 I don’t understand why _commonInitializationWithFrameName is never
 called when browsing. From the name of the function, I would expect it
 to be called right after the memory allocation.
 
 
 This leaves me with 2 options:
 1) Find a way to trigger _commonInitializationWithFrameName.
 I have no idea of how to do that at the moment
 
 
 2) Duplicate the call to WebCore::provideUserMediaTo in
 WebKit2::WebPage.
 I understand this is what is being done for the geolocation
 supplement.
 I started to implement this solution, but it requires to translate
 Objective-C++ code into C++, and I am afraid that the file inclusion
 might never end.
 

You might be interested to check this bug:
https://bugs.webkit.org/show_bug.cgi?id=123158

Philippe


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

Re: [webkit-dev] WinCairo video

[Philippe Normand]

On Thu, 2014-04-24 at 11:21 -0600, Alex Christensen wrote:
 I know there are several companies who don't even want to mess with
 the licenses of GStreamer or FFmpeg.  GStreamer's license isn't a
 problem, but I'm not sure how legally safe the plugins are. 

That's right. If you need support for those problematic codecs there are
some companies that can provide them.
 
  They certainly don't have an indemnification clause in their
 licenses.  The dlls are still large compared to WebKit, and I've had
 trouble compiling them from source and debugging them on Windows.  The
 distributed versions from freedesktop.org also use a version of
 libsoup that is too old to use as the network backend for WebKit.  I'd
 also like to remove the requirement of installing GStreamer to build
 and run the unmodified WinCairo port to make it easier for people who
 don't know much about WebKit to build and run it.
 

Those issues can likely be fixed. A lot of effort was invested in easing
the build of GStreamer for windows and Mac OSX. There are still some
bugs to iron out though.

 I'm not saying that GStreamer is out of the question in the future,
 but I think there are more reasons to switch than to stay right now.
 

That's alright I understand your concerns.

Philippe

 
 Alex Christensen
 
 
 On Thu, Apr 24, 2014 at 12:19 AM, Philippe Normand ph...@igalia.com
 wrote:
 On Wed, 2014-04-23 at 18:29 -0600, Alex Christensen wrote:
  I'm working on a Media Foundation implementation of
 MediaPlayerPrivate
  to replace the GStreamer-based one we're currently using.
  Media
  Foundation avoids the licensing issues of GStreamer
 
 
 Which licensing issues? You'd be surprised to know the actual
 number and
 variety of products that use GStreamer nowadays.
 
   and the ~100MB of GStreamer dlls which need to be installed
 in a
  certain directory.  MediaFoundation is included since
 Windows Vista.
 
 
 
 Those dlls can certainly be reduced. I'm no Windows expert but
 there are
 ways to reduce the size of the gst shared libs in Linux
 (disabling debug
 is one).
 
 
  I'm pretty sure I'm the only one working on or using
 WinCairo video,
  but I hope to make the switch later this week unless someone
 wants to
  maintain GStreamer on Windows.
 
 
 
 Philippe
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 
 
 -- 
 
 
  
 
 Alex Christensen
 
 FlexSim Software Products, Inc.
 
 1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097
 
 Voice: 801-224-6914 | Fax: 801-224-6984
 
 Email: al...@flexsim.com
 
 URL: www.flexsim.com
 
  
 
 
  
 This message may contain confidential information, and is intended
 
 only for the use of the individual(s) to whom it is addressed. 
 
 
 


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

Re: [webkit-dev] WinCairo video

[Philippe Normand]

On Wed, 2014-04-23 at 18:29 -0600, Alex Christensen wrote:
 I'm working on a Media Foundation implementation of MediaPlayerPrivate
 to replace the GStreamer-based one we're currently using.  Media
 Foundation avoids the licensing issues of GStreamer

Which licensing issues? You'd be surprised to know the actual number and
variety of products that use GStreamer nowadays.

  and the ~100MB of GStreamer dlls which need to be installed in a
 certain directory.  MediaFoundation is included since Windows Vista.
 

Those dlls can certainly be reduced. I'm no Windows expert but there are
ways to reduce the size of the gst shared libs in Linux (disabling debug
is one).

 
 I'm pretty sure I'm the only one working on or using WinCairo video,
 but I hope to make the switch later this week unless someone wants to
 maintain GStreamer on Windows.
 

Philippe


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

[webkit-dev] Remove ENABLE_NETWORK_INFO ?

[Philippe Normand]

Hi,

I think that feature should be removed from WebKit. The spec[1] clearly
states:

Work on this document has been discontinued and it should not be
referenced or used as a basis for implementation.

Anyone against removing the networkinfo Module? It seems this feature
was initially implemented for the EFL port.

Philippe

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

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

Re: [webkit-dev] Remove ENABLE_NETWORK_INFO ?

[Philippe Normand]

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

Philippe

On Fri, 2014-04-18 at 18:43 +0900, Gyuyoung Kim wrote:
 Hi Philippe,
 
 
 Sad to remove the feature. However, Network Information API spec. has
 still many issues to support bandwidth and with providing useful
 information. So, I should agree to remove it. However, if the
 specification is resurrected in future, I would like to support it
 again.
 
 
 Gyuyoung.
 
 
 On Fri, Apr 18, 2014 at 5:43 PM, Philippe Normand ph...@igalia.com
 wrote:
 Hi,
 
 I think that feature should be removed from WebKit. The
 spec[1] clearly
 states:
 
 Work on this document has been discontinued and it should not
 be
 referenced or used as a basis for implementation.
 
 Anyone against removing the networkinfo Module? It seems this
 feature
 was initially implemented for the EFL port.
 
 Philippe
 
 [1]
 https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
 
 ___
 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] Remove ENABLE_NETWORK_INFO ?

[Philippe Normand]

I mean, https://bugs.webkit.org/show_bug.cgi?id=131841 :)

Philippe

On Fri, 2014-04-18 at 18:43 +0900, Gyuyoung Kim wrote:
 Hi Philippe,
 
 
 Sad to remove the feature. However, Network Information API spec. has
 still many issues to support bandwidth and with providing useful
 information. So, I should agree to remove it. However, if the
 specification is resurrected in future, I would like to support it
 again.
 
 
 Gyuyoung.
 
 
 On Fri, Apr 18, 2014 at 5:43 PM, Philippe Normand ph...@igalia.com
 wrote:
 Hi,
 
 I think that feature should be removed from WebKit. The
 spec[1] clearly
 states:
 
 Work on this document has been discontinued and it should not
 be
 referenced or used as a basis for implementation.
 
 Anyone against removing the networkinfo Module? It seems this
 feature
 was initially implemented for the EFL port.
 
 Philippe
 
 [1]
 https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html
 
 ___
 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

[Philippe Normand]

On Mon, 2014-03-10 at 10:35 -0700, 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.
 

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

[webkit-dev] Sergio Villar Senin is now a WebKit reviewer!

[Philippe Normand]

Hi,

I'm happy to announce that Sergio (svillar) is now a WebKit reviewer! 

Sergio's areas of expertize span from WebCore (CSS Grid Layout, Parser,
editing) to WebKit2 with a special dedication to the GTK port. Sergio
also spends a lot of efforts on the libsoup networking backend.

Thanks Sergio for all the work you have done so far and congratulations!

Philippe

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

Re: [webkit-dev] MAC :: building gstreamer by WebKit but without CAIRO

[Philippe Normand]

I think https://bugs.webkit.org/show_bug.cgi?id=124861 is about fixing
this issue.

Philippe

On Wed, 2013-11-27 at 22:47 +0100, Pascal Brianceau wrote:
 Files shared by Hugo raised the same issue on my side. Did anyone make
 a step forward ? Any tip Philippe ?
 
 
 /* Pascal */
 
 
 On Mon, Nov 25, 2013 at 9:52 AM, Hugo Machefer
 hugo.mache...@gmail.com wrote:
 Indeed: I didn't solve this yet; I can only say that the
 following line is responsible for these unresolved symbols:
 
 
 GOwnPtrGError error;
 
 
   -- hmachefe
 
 
 On Sun, Nov 24, 2013 at 10:04 PM, gstreamer MACOSX
 gstreamermac...@gmail.com wrote:
 I managed to restore  ImageGStreamerCG.cpp however
 LINK fails :
 
 
   __ZN3WTF13freeOwnedGPtrI7_GErrorEEvPT_, referenced
 from:
 
 
 __ZN7WebCore27MediaPlayerPrivateGStreamer13handleMessageEP11_GstMessage in 
 MediaPlayerPrivateGStreamer.o
   __ZN7WebCore19initializeGStreamerEv in
 GStreamerUtilities.o
 
 
   -- gstreamermacosx
 
 
 PS: special thanks to hmachefe for precious
 restoration tips and to Philippe of course
 
 
 
 On Sat, Nov 23, 2013 at 9:59 AM, Philippe Normand
 ph...@igalia.com wrote:
 The ImageGStreamerCG implementation was
 removed in
 http://trac.webkit.org/changeset/118610
 
 Philippe
 
 On Sat, 2013-11-23 at 00:44 +0100, Urbain EGIS
 wrote:
  I compiled most of
 Source/WebCore/platform/graphics/gstreamer
 apart
  from ImageGstreamerCairo.cpp which has a
 strong dependency on CAIRO.
 
 
  It seems to be overkill to build WebKit by
 enabling CAIRO... Because
  (only ;-) one file ImageGstreamerCairo
 requires a specific CAIRO
  surface.
 
 
  So What would be the best strategy in case
 of MAC ?
  1° activate CAIRO by WebKit and generate it
 again (+gstreamer) ... ?
  Really ?
  2° get rid of CAIRO and find an alternative
 by CF/CG rather in terms
  of surface
 
 
  -- Egis
 
 
 
 ___
  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
 
 
 
 ___
 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
 
 
 
 ___
 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] MAC :: building gstreamer by WebKit but without CAIRO

[Philippe Normand]

The ImageGStreamerCG implementation was removed in
http://trac.webkit.org/changeset/118610

Philippe

On Sat, 2013-11-23 at 00:44 +0100, Urbain EGIS wrote:
 I compiled most of Source/WebCore/platform/graphics/gstreamer apart
 from ImageGstreamerCairo.cpp which has a strong dependency on CAIRO.
 
 
 It seems to be overkill to build WebKit by enabling CAIRO... Because
 (only ;-) one file ImageGstreamerCairo requires a specific CAIRO
 surface.
 
 
 So What would be the best strategy in case of MAC ? 
 1° activate CAIRO by WebKit and generate it again (+gstreamer) ... ?
 Really ?
 2° get rid of CAIRO and find an alternative by CF/CG rather in terms
 of surface
 
 
 -- Egis
 
 ___
 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] : ENABLE_VIDEO = how to activate HTML5 video tag ?

[Philippe Normand]

On Mon, 2013-10-14 at 11:51 +0200, gstreamer MACOSX wrote:
 Unless we missed something, sources tied to GSTREAMER (like wtf
 \gobject\GlibUtilities.cpp) appear, sort of, unobtainable. Anyone
 under position to shed lights on these missing .CPP files required by
 Webkit  ?

Have you actually searched in source tree?
See Source/WTF/wtf/gobject/GlibUtilities.cpp ...

Philippe

 
 
 -- gstreamerForEver
 
 
  On Sun, 2013-10-13 at 14:22 +0200, Urbain EGIS wrote:
  Probably a painful and hackful job in sight, as we have been told.
 And
  as a prototype, to start with. Your forewords are appreciate of
  course.
  Would you mind providing some guidance to where/how to source files
  may be located. Example : \wtf\gobject\GlibUtilities.cpp
  Thanks in advance, Philippe.
 
  Regards,
 
 
  EGIS
 
 
  On Sat, Oct 12, 2013 at 3:59 PM, Philippe Normand ph...@igalia.com
  wrote:
  On Sat, 2013-10-12 at 14:53 +0200, Urbain EGIS wrote:
   Of course, I'm part of the challenge, Hugo. I started to
  analyse .diff
   files gently provided by Alex. Let's focus on one
 example :
  
  
   --- Source/WTF/WTF.vcxproj/WTF.vcxproj (revision
  156730)
   +++ Source/WTF/WTF.vcxproj/WTF.vcxproj (working
  copy)
   @@ -73,6 +73,9 @@
   ...
   +ClCompile Include=..\wtf\gobject
  \GlibUtilities.cpp /
   ...
  
  
   Then my question is :
   where can I find this CPP file wtf\gobject
  \GlibUtilities.cpp ?
   I have done: git clone
  http://git.igalia.com/webkit.git
   but is it the right way to get GSTREAMER-centric
  source files
   for/by WebKit ? It seems it's not enough/accurate
  
 
 
  Please don't forget that branch is more than 3 years old. A
  lot of code
  changed in WebKit since then. And most of the commits in
 that
  branch
  were not really ready to be upstreamed as it was mostly a
  proof-of-concept.
 
  Philippe
 
  
   On Fri, Oct 11, 2013 at 11:05 PM, Hugo Machefer
   hugo.mache...@gmail.com wrote:
   Utterly, I'd be glad to take a serious and deep
 step
  forwards
   into this direction. Therefore, on both Brendan 
  Alex's
   instructions I'm gona opt for GSTREAMER as a
 default
  player,
   oviously. Urbain, are you with me/us ? The more,
 the
  merrier,
   you know ;-) First, as mentionned earlier, check
   with ENABLE(VIDEO) = shall be disclosing as a
   consequence many CPP files impacted.
  
  
   On my side, I am gona set WTF_USE_GSTREAMER, and
  look closely
   at previous clues
   by
 
 http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst.
  Of course, Alex, any piece of your updated code (off of the webkit-dev list) 
 will be more than welcome.
  
  
   On Fri, Oct 11, 2013 at 10:34 PM, Alex Christensen
   alex.christen...@flexsim.com wrote:
   I would like WinCairo to have video
 enabled,
  also, but
   it would take some work.  This was done
  successfully a
   few years ago by Phillippe Normand, but
 his
  code needs
   to be updated.  I got it compiling a few
  days ago, but
   something was wrong with my GStreamer
  installation.
  
  
   Here's Phillippe's
   branch:
 
 http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst
  
  
   If anyone wants to look at my updated
 code,
  let me
   know and I'll email a diff off of the
  webkit-dev list.
  
  
   Alex Christensen
  
  
   On Fri, Oct 11, 2013 at 2:25 PM, Brendan
  Long
   s...@brendanlong.com wrote:
  
   On 10/11/2013 02:13 PM, Urbain
 EGIS
  wrote:
  
Playing a bit with WebKit
  sources for
Windows (using WinCairo port) I
  expected to
activate HTML5 video tag. I just
  simply
put : #define ENABLE_VIDEO 1 and
  rebuilt
everything. But I realized that
  only few

Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO = how to activate HTML5 video tag ?

[Philippe Normand]

On Mon, 2013-10-14 at 12:14 +0200, gstreamer MACOSX wrote:
 Exactly, Philippe: I searched everywhere by D:\Users\gstreamermacosx
 \webkit\Source but without any success. 
 I applyed this command like my counterparts ... :
  git clone http://git.igalia.com/webkit.git
 Is it correct ? In fact, there is not even any Source/WTF sub-folder.
 

Like I said earlier, that repository is 3 years old, a lot of changes
were made, including the move of wtf from JavascriptCore/ to Source/

Seriously, get in touch with Alexander. IIUC he got the patches updated
for trunk already...

Philippe

 
 -- gstreamerForEver
 
 
 On Mon, Oct 14, 2013 at 11:59 AM, Philippe Normand ph...@igalia.com
 wrote:
 On Mon, 2013-10-14 at 11:51 +0200, gstreamer MACOSX wrote:
  Unless we missed something, sources tied to GSTREAMER (like
 wtf
  \gobject\GlibUtilities.cpp) appear, sort of, unobtainable.
 Anyone
  under position to shed lights on these missing .CPP files
 required by
  Webkit  ?
 
 
 Have you actually searched in source tree?
 See Source/WTF/wtf/gobject/GlibUtilities.cpp ...
 
 Philippe
 
 
 
  -- gstreamerForEver
 
 
   On Sun, 2013-10-13 at 14:22 +0200, Urbain EGIS wrote:
   Probably a painful and hackful job in sight, as we have
 been told.
  And
   as a prototype, to start with. Your forewords are
 appreciate of
   course.
   Would you mind providing some guidance to where/how to
 source files
   may be located. Example : \wtf\gobject\GlibUtilities.cpp
   Thanks in advance, Philippe.
  
   Regards,
  
  
   EGIS
  
  
   On Sat, Oct 12, 2013 at 3:59 PM, Philippe Normand
 ph...@igalia.com
   wrote:
   On Sat, 2013-10-12 at 14:53 +0200, Urbain EGIS
 wrote:
Of course, I'm part of the challenge, Hugo. I
 started to
   analyse .diff
files gently provided by Alex. Let's focus on
 one
  example :
   
   
--- Source/WTF/WTF.vcxproj/WTF.vcxproj
 (revision
   156730)
+++ Source/WTF/WTF.vcxproj/WTF.vcxproj
 (working
   copy)
@@ -73,6 +73,9 @@
...
+ClCompile Include=..\wtf\gobject
   \GlibUtilities.cpp /
...
   
   
Then my question is :
where can I find this CPP file wtf
 \gobject
   \GlibUtilities.cpp ?
I have done: git clone
   http://git.igalia.com/webkit.git
but is it the right way to get
 GSTREAMER-centric
   source files
for/by WebKit ? It seems it's not
 enough/accurate
   
  
  
   Please don't forget that branch is more than 3
 years old. A
   lot of code
   changed in WebKit since then. And most of the
 commits in
  that
   branch
   were not really ready to be upstreamed as it was
 mostly a
   proof-of-concept.
  
   Philippe
  
   
On Fri, Oct 11, 2013 at 11:05 PM, Hugo Machefer
hugo.mache...@gmail.com wrote:
Utterly, I'd be glad to take a serious
 and deep
  step
   forwards
into this direction. Therefore, on both
 Brendan 
   Alex's
instructions I'm gona opt for GSTREAMER
 as a
  default
   player,
oviously. Urbain, are you with me/us ?
 The more,
  the
   merrier,
you know ;-) First, as mentionned
 earlier, check
with ENABLE(VIDEO) = shall be
 disclosing as a
consequence many CPP files impacted.
   
   
On my side, I am gona set
 WTF_USE_GSTREAMER, and
   look closely
at previous clues
by
  
 
 
 http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst.
  Of course, Alex, any piece of your updated code (off of the webkit-dev list) 
 will be more

Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO = how to activate HTML5 video tag ?

[Philippe Normand]

On Mon, 2013-10-14 at 22:09 +0530, Mital Vora wrote:
 Hi,
 
 
 I have few questions regarding move to Gstreamer. 
 
 
 * are we gonna replace the existing openssl and curl with libsoup ?
 

1. GStreamer doesn't depend on those libraries.
2. For HTTP(S) media access we have a dedicated source element in WebKit
that uses the WebCore ResourceLoader to fetch data.

 
 * are we considering any other possibilities besides gstreamer like
 ffmpeg (http://www.ffmpeg.org/) or any other. 
 

Feel free to provide a MediaPlayerPrivateFFMpeg if you want. But be
ready to maintain it too :)

 
 By moving to gstreamer would increase dependencies size a lot as the
 all GTK base libraries would be included by default and this would be
 concern to atleast few of us who does not want to increase the webkit
 base dependencies library by huge amount. 
 
 
 I may be missing something here..  can anybody clarify the advantages
 of moving to gtk based gstreamer over the other side like the binary
 size increase. 
 
 

 
 
 
 Regards,
 
 Mital Vora.
 
 
 On Mon, Oct 14, 2013 at 9:54 PM, Brendan Long s...@brendanlong.com
 wrote:
 On 10/14/2013 04:14 AM, gstreamer MACOSX wrote:
 
  Exactly, Philippe: I searched everywhere by D:\Users
  \gstreamermacosx\webkit\Source but without any success.  
  I applyed this command like my counterparts ... :
   git clone http://git.igalia.com/webkit.git 
  Is it correct ? In fact, there is not even any Source/WTF
  sub-folder.
 I think he meant you should use the normal repo:
 git clone git://git.webkit.org/WebKit.git
 (Or use SVN if you're into that?)
 
 Rebasing a patch from a 3-year-old checkout would be extremely
 difficult, so it's easier to figure out what the patch does,
 and re-apply it manually on a new checkout.
 
 
 ___
 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] : ENABLE_VIDEO = how to activate HTML5 video tag ?

[Philippe Normand]

On Sat, 2013-10-12 at 14:53 +0200, Urbain EGIS wrote:
 Of course, I'm part of the challenge, Hugo. I started to analyse .diff
 files gently provided by Alex. Let's focus on one example :
 
 
 --- Source/WTF/WTF.vcxproj/WTF.vcxproj (revision 156730)
 +++ Source/WTF/WTF.vcxproj/WTF.vcxproj (working copy)
 @@ -73,6 +73,9 @@
 ...
 +ClCompile Include=..\wtf\gobject\GlibUtilities.cpp /
 ...
 
 
 Then my question is :
 where can I find this CPP file wtf\gobject\GlibUtilities.cpp ?
 I have done: git clone http://git.igalia.com/webkit.git 
 but is it the right way to get GSTREAMER-centric source files
 for/by WebKit ? It seems it's not enough/accurate
 

Please don't forget that branch is more than 3 years old. A lot of code
changed in WebKit since then. And most of the commits in that branch
were not really ready to be upstreamed as it was mostly a
proof-of-concept.

Philippe

 
 On Fri, Oct 11, 2013 at 11:05 PM, Hugo Machefer
 hugo.mache...@gmail.com wrote:
 Utterly, I'd be glad to take a serious and deep step forwards
 into this direction. Therefore, on both Brendan  Alex's
 instructions I'm gona opt for GSTREAMER as a default player,
 oviously. Urbain, are you with me/us ? The more, the merrier,
 you know ;-) First, as mentionned earlier, check
 with ENABLE(VIDEO) = shall be disclosing as a
 consequence many CPP files impacted.
 
 
 On my side, I am gona set WTF_USE_GSTREAMER, and look closely
 at previous clues
 by 
 http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst.
  Of course, Alex, any piece of your updated code (off of the webkit-dev list) 
 will be more than welcome.
 
 
 On Fri, Oct 11, 2013 at 10:34 PM, Alex Christensen
 alex.christen...@flexsim.com wrote:
 I would like WinCairo to have video enabled, also, but
 it would take some work.  This was done successfully a
 few years ago by Phillippe Normand, but his code needs
 to be updated.  I got it compiling a few days ago, but
 something was wrong with my GStreamer installation.
 
 
 Here's Phillippe's
 branch: 
 http://git.igalia.com/cgi-bin/gitweb.cgi?p=webkit.git;a=shortlog;h=refs/heads/win-gst
 
 
 If anyone wants to look at my updated code, let me
 know and I'll email a diff off of the webkit-dev list.
 
 
 Alex Christensen
 
 
 On Fri, Oct 11, 2013 at 2:25 PM, Brendan Long
 s...@brendanlong.com wrote:
 
 On 10/11/2013 02:13 PM, Urbain EGIS wrote:
 
  Playing a bit with WebKit sources for
  Windows (using WinCairo port) I expected to
  activate HTML5 video tag. I just simply
  put : #define ENABLE_VIDEO 1 and rebuilt
  everything. But I realized that only few
  files are concerned by USE(ENABLE_VIDEO) and
  are not even .CPP files.
 It would be ENABLE(VIDEO), not
 USE(ENABLE_VIDEO).
 
 
  So something may have been falling through
  the net... But what ? What is missing from
  Visual Studio generation ? Which procedure
  shall be applied to get .CPP files included
  into MS projects ?
  
 Most likely you need to specifiy which media
 player to use. For example, to use GStreamer
 you would define WTF_USE_GSTREAMER. I don't
 see a DirectShow media player, so GStreamer is
 probably your best bet.
 
 You can look through the players by looking at
 file starting with MediaPlayerPrivate, for
 example:
   * AV Foundation (Mac)
   * Blackberry
   * GStreamer
   * QTKit (QuickTime?)
   * WinCE
 
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 

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

[Philippe Normand]

On Wed, 2013-09-11 at 17:43 -0300, Luciano Wolf wrote:

 The most recent effort from our side is to provide WebRTC support.
 Thiago Lacerda is talking with Eric Carlson and they are coordinating
 the merge of Blink patches as well as planning the development of
 missing features. So, I believe we are in the right path to become a
 mainstream port.
 

Where is this discussion happening? I'd be interested to follow it.

I also plan to work on WebRTC support at the platform (GStreamer) level
if no one else steps up in bug #87514 :)

Philippe

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

[Philippe Normand]

FWIW the GTK+ port also builds with C++11 support.
Philippe

On Fri, 2013-07-26 at 09:04 -0700, 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
 
 ___
 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] Media Server Development

[Philippe Normand]

You should write a new MediaPlayerPrivate backend instead of hacking the
MediaPlayerPrivateGStreamer one.

Philippe

On Thu, 2013-01-31 at 23:04 +0530, Kiran K wrote:
 HI All,
 
 I am working on QtWebKit  on Media Server development. Basic Idea is
 to run Gstreamer in seperate process which acts like a Media server.
 The calls  from WebKit in MediaPlayerPrivateGStreamer.cpp are routed
 to Media Server via DBUS. Media Server implements the methods in
 MediaPlayerPrivateGStreamer class. I am basically doing this to have
 control over the resources like maximum playback instances, hw codec
 control etc. I am able to do achieve playback to some extent. I am
 facing some problems  (race conditions) especially when deleting
 playback instance. From the logs i concluded that when duration()
 function is made  and is waiting for response from server,
 ~MediaPlayerPrivateGStreamer destructor is getting called. (some times
 vice versa too). I am suspecting that the MediaPlayer object is being
 shared between two threads (or across timers). Can anybody give me
 some pointers about HTMLMediaElement  and the timers involved? Any
 help is appreciated.
 
 Thanks,
 Arun
 
 ___
 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

[webkit-dev] PSA: Migration plan to GStreamer 1.x

[Philippe Normand]

Hi,

This mail is mainly for the GTK, Qt and EFL port maintainers, I decided
to post here instead of cross-posting to three mailing lists :)

So there's been work to port the MediaPlayer and WebAudio GStreamer
backends to the new GStreamer 1.x APIs. At the moment you can choose
(well, for the GTK port at least) at build time if you want to use the
0.10 or 1.x APIs.

The issue is that GStreamer 0.10 is no longer actively maintained and
the GStreamer developers/maintainers entirely focus on GStreamer 1.x.

Moreover we currently don't have the manpower to maintain the 2 code
paths in the WebKit/GStreamer platform layer. The GTK port buildbots
already switched to 1.0 last month and I encourage Qt and EFL to do the
same ASAP, at least for their buildbots.

I'd like to propose we drop the GStreamer 0.10 support from WebKit once
the next stable branch of GStreamer is released, it will be 1.2,
scheduled somewhere around February.

Opinions welcome :)

Philippe

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

Re: [webkit-dev] svns...@macosforge.org ?

[Philippe Normand]

On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote:
 I noticed today that some patches are authored by svns...@macosforge.org:
 
 http://trac.webkit.org/search?q=svnsync
 
 Is this behavior expected?
 

I guess this is a bug in one of the SVN commit hooks?

Philippe

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

Re: [webkit-dev] Not authorized to access Bugzillia

[Philippe Normand]

This is a security bug. Only some people can access those, typically the
security team members at least.

Philippe

On Wed, 2012-08-08 at 16:32 +0800, talking1...@gmail.com wrote:
 When I try to access https://bugs.webkit.org/show_bug.cgi?id=41482, it
 show me follow information, so if I want to check some bug, it need
 send an email for request to grant the permissions?
 
 
 You are not authorized to access bug #41482.
 
 --
 BGs/Felix Shi
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] GTK+ port's help needed to get rid of FAIL test expectation

[Philippe Normand]

On 2012-06-10 19:09, Žan Doberšek wrote:

I think it would suffice to replace all the FAIL occurrences with
TEXT, except for the failing reftests - those should have FAIL turned
into IMAGE. Gtk bots don't run pixel tests yet so any other IMAGE
failures could perhaps be addressed at later time.



I agree with that approach.

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

Re: [webkit-dev] can I replace webkitwebsrc with souphttpsrc?

[Philippe Normand]

On Sun, 2012-06-03 at 11:31 +0800, ZiQiangHuan wrote:
 Hi,
 
 For support to html5 video on my device, I am doing something with
 webkit+gstreamer recently. But I found that there are custom plugins
 webkitsrc and webkitsink in webkit's gstreamer backend source
 code.For my device I have to replace webkitsink with my videosink. I
 met some trouble with webkitsrc, and for example I cannot play mp4
 files if their size is too big.

A bug report describing the issue would be very welcome.

  Then I test it when I replace webkitsrc with gstreamer's plugins
 souphttpsrc, the trouble disappears. So my question is that if I
 replace webkitsrc with souphttpsrc, any trouble I will meet? any
 functions I will loss?
 

Yes. If you don't use the webkitwebsrc element you'll need to manually
set the user-agent, referer and HTTP cookies. I believe they can't be
set using GObject properties on the element.


 By the way, any introductions for webkit's streaming media policy I
 can learn?

I don't understand this question, please elaborate :)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How can I get some debug infomation in MediaPlayerPrivateGStreamer.cpp

[Philippe Normand]

On Fri, 2012-04-20 at 10:42 +0800, ZiQiangHuan wrote:
 hi，
 
 I build webkit with gstreamer support, but  I encountered a problem
 when I test with it. When I write a simple statement printf(*
 \n) in the function isAvailable() of
 MediaPlayerPrivateGStreamer.cpp, I got nothing output. When I do the
 same thing with the function create of
 MediaPlayerPrivateGStreamer.cpp, I got nothing output too. So I want
 to know if I want to get some debug info in these functions, what
 should I do? anyone has some experience with this? And I don't know
 why this happen.
 

That's odd, the stdout buffer should be flushed since you insert a new
line. Try to force a fflush() call maybe?

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

[Philippe Normand]

On Thu, 2012-03-08 at 14:10 -0300, Alexis Menard wrote:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and infrastructure,
  against my better judgement, I'd like to distract you from being productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.
 
 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).
 

We just need to keep the history linear. With good practices it's
possible :)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] git.webkit.org is offline

[Philippe Normand]

I still can't use the git mirror here and build.webkit.org doesn't
respond either, looks like an issue with the web server.

Philippe

On Wed, 2012-02-15 at 16:04 -0800, William Siegrist wrote:
 git.webkit.org is back up on faster/less-broken storage. 
 
 -Bill
 
 
 
 On Feb 15, 2012, at 1:29 PM, William Siegrist wsiegr...@apple.com wrote:
 
  We're still having problems. Git is currently down. I am making adjustments 
  so I can bring it up and hopefully keep it up soon. 
  
  -Bill
  
  
  On Feb 15, 2012, at 11:29 AM, William Siegrist wsiegr...@apple.com wrote:
  
  All services are back.
  
  -Bill
  
  
  On Feb 15, 2012, at 8:55 AM, William Siegrist wrote:
  
  That server (which includes git, build, nightly, and lists) is having 
  trouble keeping up with load, probably due to a disk array problem. I 
  will be rebooting it one more time in an hour or two to try to clear up 
  the problem. 
  
  -Bill
  
  
  On Feb 15, 2012, at 6:38 AM, Osztrogonac Csaba wrote:
  
  Hi,
  
  It seems git.webkit.org is offline.
  Could you check what happened?
  
  br,
  Ossy
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
  
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
  
  
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] GTK 64-bit Debug slave is offline

[Philippe Normand]

Hi!

We can't start the 64-bit GTK Debug slave anymore, the error we get is:

2012-02-10 03:27:55-0800 [Broker,client]
ReconnectingPBClientFactory.failedToGetPerspective
2012-02-10 03:27:55-0800 [Broker,client] Unhandled Error
Traceback from remote host -- Traceback unavailable

It seems that means we get an authentication error. Can the buildmaster
admin please check this on their side?

Thanks!
Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] GTK 64-bit Debug slave is offline

[Philippe Normand]

The buildslave is back and kicking.
Thanks!
Philippe

On Fri, 2012-02-10 at 07:45 -0800, William Siegrist wrote:
 The master has been restarted. 
 
 -Bill
 
 
 On Feb 10, 2012, at 3:37 AM, Philippe Normand wrote:
 
  Hi!
  
  We can't start the 64-bit GTK Debug slave anymore, the error we get is:
  
  2012-02-10 03:27:55-0800 [Broker,client]
  ReconnectingPBClientFactory.failedToGetPerspective
  2012-02-10 03:27:55-0800 [Broker,client] Unhandled Error
  Traceback from remote host -- Traceback unavailable
  
  It seems that means we get an authentication error. Can the buildmaster
  admin please check this on their side?
  
  Thanks!
  Philippe
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Gstreamer libraries not linking?

[Philippe Normand]

 
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_push_buffer'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_get_type'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_missing_element_message_new'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_video_parse_caps_pixel_aspect_ratio'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_set_stream_type'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_set_emit_signals'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_video_sink_get_type'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_video_format_parse_caps'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_end_of_stream'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_set_caps'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_set_max_bytes'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_set_callbacks'
 ./.libs/libwebkitgtk-1.0.so: undefined reference to
 `gst_app_src_set_size'
 collect2: ld returned 1 exit status
 make[1]: *** [Programs/GtkLauncher] Error 1
 make[1]: Leaving directory
 `/home/akg2136/JSH/WebKit-HashTab/WebKitBuild/Release'
 make: *** [all] Error 2
 
 

 
 Looking these libraries up, I found that they are located in
 libgstinterfaces, but I can't seem to get the -l command into the
 build. My env is: 
 
 
 GSTREAMER_LIBS=-pthread -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0
 -lgmodule-2.0 -lxml2 -lgthread-2.0 -lrt -lglib-2.0
  -lgstinterfaces-0.10

 Am I missing something?
 

Looks like something is wrong with your gstreamer installation.
You miss -lgstapp-0.10 -lgstpbutils-0.10 -lgstvideo-0.10 at least.

./configure checks for the following packages:

   PKG_CHECK_MODULES([GSTREAMER],
 [gstreamer-$GST_API_VERSION =
$GSTREAMER_REQUIRED_VERSION
 gstreamer-app-$GST_API_VERSION
 gstreamer-audio-$GST_API_VERSION
 gstreamer-base-$GST_API_VERSION
 gstreamer-interfaces-$GST_API_VERSION
 gstreamer-pbutils-$GST_API_VERSION
 gstreamer-plugins-base-$GST_API_VERSION =
$GSTREAMER_PLUGINS_BASE_REQUIRED_VERSION
 gstreamer-video-$GST_API_VERSION],
 [have_gstreamer=yes])

Philippe



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] About code reviews outside bugzilla

[Philippe Normand]

Hi,

I thought any substantial code contribution was to be reviewed in a
proper bugzilla entry?

This commit broke the WebKit2 build earlier today:

http://trac.webkit.org/changeset/104557

No mention of a bugzilla entry...

Hopefully Kenneth was quick coming up with a build fix, but please let's
use Bugzilla... In the case of this patch, the build breakage would have
been detected upfront by the EWS.

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] About code reviews outside bugzilla

[Philippe Normand]

On Tue, 2012-01-10 at 14:48 +, Peter Beverloo wrote:
 The bugzilla bug is here, it's just not referenced in the message
 (which it should be):
 https://bugs.webkit.org/show_bug.cgi?id=75956
 

Ah, thanks Peter!
Too bad the EWS wasn't not used though :(

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [GTK] Buildslave changes

[Philippe Normand]

The bot is now deployed and so far, working well :)
Thanks Adam for the help!

Philippe

On Wed, 2011-11-30 at 17:03 -0500, Adam Roben wrote:
 On Nov 30, 2011, at 4:34 PM, Philippe Normand wrote:
 
  Can we get new buildbot credentials for the new slave or can we reuse
  the 32-bits Debug ones? It'd be great if we can coordinate on this
  migration soon :)
 
 Credentials are a slave name/password pair. If you're using the old slave 
 name for the new machine then you should use the old password too.
 
 If you're adding a new slave name, you should post a patch to bugs.webkit.org 
 to do so and CC me. Once the patch lands I'll update the master and send you 
 a password.
 
 -Adam
 
 
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] [GTK] Buildslave changes

[Philippe Normand]

Hi!

Igalia recently purchased new hardware to improve the GTK Debug bots
situation. Here's the plan:

- Drop 32-bits Debug
- Keep current 64-bits Debug
- Add a 64-bits Release (which will run on the new hardware)

A full build on the new machine takes at most 7:30 minutes and tests
using NRWT run in about 3 minutes :)

Can we get new buildbot credentials for the new slave or can we reuse
the 32-bits Debug ones? It'd be great if we can coordinate on this
migration soon :)

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ping-pong with fast/files/create-blob-url-crash-expected.txt

[Philippe Normand]

Sorry for the last one.
Looks like the patch in https://bugs.webkit.org/show_bug.cgi?id=66045
is intended to fix this issue for both JSC and V8 code generators, if I
understood correctly.

Philippe

On Wed, 2011-08-31 at 13:40 +0200, Osztrogonac Csaba wrote:
 Hi,
 
 It seems you guys are playing ping-pong with this platform independent 
 expected file.
 Could you decide which one is the correct?
 
 br,
 Ossy
 
 http://trac.webkit.org/changeset/93713
 http://trac.webkit.org/changeset/93713/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt
 -PASS: Not enough arguments
 +PASS: Type error
 
 http://trac.webkit.org/changeset/94023
 http://trac.webkit.org/changeset/94023/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt
 -PASS: Type error
 +PASS: Not enough arguments
 
 http://trac.webkit.org/changeset/94168
 http://trac.webkit.org/changeset/94168/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt
 -PASS: Not enough arguments
 +PASS: Type error
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 


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

Re: [webkit-dev] ping-pong with fast/files/create-blob-url-crash-expected.txt

[Philippe Normand]

On Wed, 2011-08-31 at 07:28 -0700, David Levin wrote:
 On Wed, Aug 31, 2011 at 5:57 AM, Philippe Normand ph...@igalia.com
 wrote:
 Sorry for the last one. 
 Looks like the patch in
 https://bugs.webkit.org/show_bug.cgi?id=66045
 is intended to fix this issue for both JSC and V8 code
 generators, if I
 understood correctly.
 
 
 Short story: http://trac.webkit.org/changeset/94023 is correct and we
 should fix the result that in there now.
 
 
 More:
 In general, when JSC and V8 disagree, we've gone with JSC in the
 platform independent file.
 
 
 http://trac.webkit.org/changeset/93713
 and http://trac.webkit.org/changeset/94168 didn't do this so they
 aren't following what is standard practice.
 

I'll revert the involved part of r94168.
Philippe



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

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

[Philippe Normand]

I think this rollout highlighted the need for crash reports in the GTK
Release bot. The issue being absent from the Debug bots, we had to build
WebKitGTK with debug symbols and optimizations turned on to get useful
stack-traces.

Oliver relanded the big patch with an additional workaround for a gcc
reordering bug that he found after a gdb-over-irc session with me, once
I managed to have a local build useful enough for debugging.

Philippe

On Fri, 2011-04-15 at 10:55 -0700, Adam Barth wrote:
 As everyone knows, I'm a proponent of rolling things out more
 frequently, but that change looks huge.  I think we should have a bias
 against rolling out large changes because they're much harder and
 disruptive to roll in and out than small changes.  (Of course, we
 should also have a bias against accepting large patches, but sometimes
 they're necessary, as I assume Oliver's change was.)
 
 Adam
 
 
 On Fri, Apr 15, 2011 at 10:41 AM, Oliver Hunt oli...@apple.com wrote:
  Indeed, i missed the gtk release one, but the point stands that just 
  rolling out a patch (which should not roll out the changelogs) without 
  providing any information about the crash doesn't help anyone.
 
  --Oliver
 
  On Apr 15, 2011, at 10:30 AM, Adam Roben wrote:
 
  On Apr 15, 2011, at 1:19 PM, Oliver Hunt wrote:
 
  Don't roll out patches that don't break any core builders, without making 
  some attempt to diagnose the problem or providing information that will 
  make it possible to fix the problem.
 
  The GTK bots are core builders.
 
  -Adam
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Using Git for WebKit development

[Philippe Normand]

On Tue, 2011-01-18 at 11:26 +0300, Konstantin Tokarev wrote:
 Hi all,
 
 When I'm trying to cherry-pick or rebase something in my WebKit git clone,
 I constantly end up with conflicts in changelog files
 
 How do you fight this problem?
 

Add in your .git/config:

[merge changelog]
driver = Tools/Scripts/resolve-ChangeLogs --merge-driver %O %A %
B

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkitpy test failures on GTK bots

[Philippe Normand]

The first failing 32-bits release build is:

http://build.webkit.org/builders/GTK%20Linux%2032-bit%
20Release/builds/9010

which includes:

http://trac.webkit.org/changeset/74632

Could it be an issue with that unittest?

Philippe

On Fri, 2010-12-24 at 11:38 -0800, Darin Adler wrote:
 Hi folks.
 
 The GTK bots have been red for a while now; not sure whether it’s been days 
 or weeks. These are core builders, so should not be red for that long. 
 Apparently the issue is that some Python tests can’t be run because there’s a 
 Google python module of some sort that must be installed. Could someone fix 
 this? Here are possible ways to fix it:
 
 1) Turn off these tests for GTK.
 2) Install that module on the bots, if that’s appropriate.
 3) Take the GTK bots out of the core set.
 4) Undo whatever change made this problem start to occur recently.
 
 Anyone?
 
 -- Darin
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkitpy test failures on GTK bots

[Philippe Normand]

On Fri, 2010-12-24 at 22:27 +0100, Philippe Normand wrote:
 The first failing 32-bits release build is:
 
 http://build.webkit.org/builders/GTK%20Linux%2032-bit%
 20Release/builds/9010
 
 which includes:
 
 http://trac.webkit.org/changeset/74632
 
 Could it be an issue with that unittest?
 

I rolled out that changeset and reopened the corresponding bug.
I'm having a look at the test but I'm not familiar with that code, it
seems the message-broker loop of the added test-case doesn't stop, for
some reason.


 Philippe
 
 On Fri, 2010-12-24 at 11:38 -0800, Darin Adler wrote:
  Hi folks.
  
  The GTK bots have been red for a while now; not sure whether it’s been days 
  or weeks. These are core builders, so should not be red for that long. 
  Apparently the issue is that some Python tests can’t be run because there’s 
  a Google python module of some sort that must be installed. Could someone 
  fix this? Here are possible ways to fix it:
  
  1) Turn off these tests for GTK.
  2) Install that module on the bots, if that’s appropriate.
  3) Take the GTK bots out of the core set.
  4) Undo whatever change made this problem start to occur recently.
  
  Anyone?
  
  -- Darin
  
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
  
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Buildbots soon to require apache mod_bw

[Philippe Normand]

Hi,

The patch to be landed soon for
https://bugs.webkit.org/show_bug.cgi?id=45101

updates the apache config to require mod_bw. Can the buildbots admins
please install it? I contacted the GTK+ bots admins already.

The new test on this patch requires connection throttling but will run
only on the GTK bots and I'll give it a try on the Chromium bots too.

Philippe


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Buildbots soon to require apache mod_bw

[Philippe Normand]

 Having said that, it just struck me that we have a few php scripts that
 are used by tests to cause intentional delays[0]. Perhaps we could use a
 similar pattern for this case too, and avoid this new requirement.
 

Thanks for the hint Gustavo :)
Actually I found video-throttled-load.cgi which nearly is perfect fit
for my test. I just need to add Range requests support to it, having a
look now.

Philippe

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

Re: [webkit-dev] Nighties build scripts

[Philippe Normand]

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

Philippe

On Wed, 2010-06-09 at 15:56 +0200, Philippe Normand wrote:
 Hi,
 
 I've been trying the Nighly build scripts without much success. I run
 build-launcher-app and build-launcher-dmg.
 
 The build-launcher-app tries to copy Drosera.app, which doesn't seem to
 be supported anymore, http://trac.webkit.org/wiki/Drosera :
 
 Drosera has been replaced by an improved debugger built into the Web
 Inspector. The information this page still applies to Safari 3.1 and
 3.0. ...
 
 So I commented out the Drosera stuff and get a 9.5 Mb DMG (compared to
 40Mb on the nightlies website). Anyway, trying to use that DMG I get a
 popup saying my version of Mac OS X (10.6) is not supported yet by the
 nightlies. If I download the latest nightly build it works fine.
 
 Can someone, maybe bdash?, light my lantern? :)
 
 Philippe
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 


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

Re: [webkit-dev] Volcano

[Philippe Normand]

Hi,

I'm stuck in SF until sunday, unless I can find a flight earlier...
Hacking from a café there on some GTK fullscreen video support :)

Philippe

On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
 I should have asked sooner...
 
 Are any folks stuck here after the WebKit conference due to the volcano?
 
 If so, drop me a line.  I'd like to at least offer lunch and possibly
 some in-person hack-time.
 
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Volcano

[Philippe Normand]

Currently in 1195 Oak st but it closes at 5pm. Eric suggested Cafe Abir
on 1300 Fulton st.

I have to go tomorrow afternoon to Sunnyvale for a meeting but in the
morning I should be in the Cafe Abir :)

I'm open to any suggestion anyway! Currently staying in Haight st around
#800, I'd prefer to stay around if possible.

Philippe

On Tue, 2010-04-20 at 14:37 -0700, Evan Martin wrote:
 I am down for a post-gathering SF hackathon.  Name a cafe and time.  :)
 
 On Tue, Apr 20, 2010 at 2:00 PM, Philippe Normand pnorm...@igalia.com wrote:
  Hi,
 
  I'm stuck in SF until sunday, unless I can find a flight earlier...
  Hacking from a café there on some GTK fullscreen video support :)
 
  Philippe
 
  On Tue, 2010-04-20 at 13:19 -0700, Eric Seidel wrote:
  I should have asked sooner...
 
  Are any folks stuck here after the WebKit conference due to the volcano?
 
  If so, drop me a line.  I'd like to at least offer lunch and possibly
  some in-person hack-time.
 
  -eric
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] +R mode on #webkit IRC channel

[Philippe Normand]

Maybe it was a countermeasure for yesterday's CTCP flood attacks?

Philippe

On Tue, 2010-01-19 at 10:25 +0200, Xan Lopez wrote:
 Hi,
 
 I woke up this morning to find #webkit set up with mode +R
 (http://docs.dal.net/docs/modes.html#2.17), so basically you can't
 speak unless you have your nick registered on freenode. Is this a new
 policy or just some error or temporary measure that someone forgot to
 disable? If it's the latter it would be good to go back to normality.
 
 Cheers,
 
 Xan
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 


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

Re: [webkit-dev] Style for Gtk/Qt code

[Philippe Normand]

On Mon, 2009-12-21 at 01:25 -0600, Eric Seidel wrote:
 The style-bot warns for style errors in all code in the webkit tree,
 but I'm not sure if that's correct.
 
 Are there sections of gtk/qt/whatever code which should be in a different 
 style?
 
 Sometimes these warnings are ignored.  Sometimes they produce strange
 reactions like this one:
 https://bugs.webkit.org/show_bug.cgi?id=32661

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

I will send a patch for this bug and revert the offending parts of the
patch of Bug 32661 :)

Philippe

 Can we get consensus on if the WebKit style applies to all sections of
 code?  And if it does not, what style applies to the code it does not?
 
 
 I vote that the WebKit coding style should apply to all code in the WebKit 
 tree.
 
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev