[Crosswalk-dev] download.01.org is back (was Re: download.01.org is currently offline)

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> Hi, everyone,
>
> 5 GitHub issues, 2 JIRA tickets and 2 different email threads later, I
> can confirm that download.01.org looks down from our side as well.
>
> To be clear: no, this was not intentional. The entire download.01.org
> domain is offline, and this outage affects many other open-source
> projects led by Intel.
>
> We've filed an internal ticket to investigate and resolve this, but
> a fix may take longer than usual to arrive due Labor Day in the United
> States.
>
> Meanwhile, we apologize for the incident. Some people are discussing
> possible workarounds in
> https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview/issues/158,
> but none of them are officially tested or recommended by us.

Everything is up and running again (since yesterday morning PDT). We had
some internal issues with our CDN provider that have since been fixed.

Once again, we apologize for the disruption. Let us know if you still
experience any breakages.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] download.01.org is currently offline

[Raphael Kubo da Costa]

Hi, everyone,

5 GitHub issues, 2 JIRA tickets and 2 different email threads later, I
can confirm that download.01.org looks down from our side as well.

To be clear: no, this was not intentional. The entire download.01.org
domain is offline, and this outage affects many other open-source
projects led by Intel.

We've filed an internal ticket to investigate and resolve this, but
a fix may take longer than usual to arrive due Labor Day in the United
States.

Meanwhile, we apologize for the incident. Some people are discussing
possible workarounds in
https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview/issues/158,
but none of them are officially tested or recommended by us.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Could you do me a favor about xwalk-lite compilation?

[Raphael Kubo da Costa]

"KeXianbin(http://diyism.com)"  writes:

> Sorry for bothering you, I know the crosswalk project ended 2 months ago, but 
> neither electron nor
> nw.js supports the android, so i think xwalk-lite is my only choice.
> I'm customizing and compiling xwalk-lite (make dns1 and dns2 fixed to 
> 127.0.0.1:9953), but an error
> happened, could you do me a favor to help me out?

In addition to what He Ke said:
- You need to set GYP_DEFINES as described in the "Crosswalk 22 and
  earlier: gyp setup" section of
  https://crosswalk-project.org/contribute/building_crosswalk/android_build.html
- The GOMA settings are for Googlers, so you shouldn't have to touch it
  at all.
- Bear in mind that Crosswalk Lite contains a very old Chromium release
  (with plenty of security issues by now) with a similarly old Crosswalk
  release.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Some questions about xwalk

[Raphael Kubo da Costa]

Hi there,

Taekwan Lee  writes:
> Dear xwalk team
>
> Good morning! I am Taekwan Lee.
> A few days ago, I found your github site and I am really into your project
> "Crosswalk" (It is a awesome Project!)

Thanks, but you're a bit too late to the party, as it is currently
unmaintained :-)

https://crosswalk-project.org/blog/crosswalk-final-release.html

> I am working on Tizen web app project these days. So I am sure it is
> helpful when I start to test my app.
>
> Then, I have some questions.
>
> 1. Does xwalk also support Tizen TV?
> 2. Does it keep updating to support the lastest version of Tizen? (now
> version of Tizen TV is 3.0)

Unfortunately, Tizen has not been officially supported for a long time
now; for Tizen-specific questions it is better to contact the Tizen
project directly since I guess they might still maintain a Crosswalk
fork there.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [crosswalk-dev] Is there a recommanded build option ? target is x86

[Raphael Kubo da Costa]

윤영석  writes:

> Hi,
> Thank for reply.
>
> Yes, I know there is a dependency on the build environment..
> If you have a sample default setting for each environment, it might be more 
> helpful.
>
> Do you have any default configuration that you can build on ubuntu 16.04 
> x86-64?

Sorry, but this still sounds a bit vague. The default GN settings used
on a Linux build is the default configuration/sample default setting by
definition. You can see all build flags and their values (including
those we do not change in Crosswalk) if you run "gn args out/Release
--list".

You can also see the list of flags we change compared to upstream in
build/common.gni and build/linux.gni.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] build combined aar

[Raphael Kubo da Costa]

Yukio  writes:

> Hello, this is byplayer.
>
> I would like to build xwalk_core_libray(version 23.x).
> I can build x86, arm aar file, but I can't build x86 and arm combined aar
> file like as below.
> https://download.01.org/crosswalk/releases/crosswalk/android/maven2/org/xwalk/xwalk_core_library/23.53.589.4/xwalk_core_library-23.53.589.4.aar
>
> Is there any instruction to build combined aar file?

The process is (unfortunately) the same one followed by Chromium itself:
you need to have two separate, independent builds (one for each arch),
then you merge their respective AARs into one.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Planned infrastructure downtimes in the coming days

[Raphael Kubo da Costa]

Hi all,

We'll be performing maintenance in part of our infrastructure, during
which it will be unavailable.

* 4th November (today), 8:00-9:30 PDT (16:00-17:30 CET/23:00-00:30
  Shanghai and Benjing)
  Our Buildbot masters will be offline, so no new commits or pull
  requests will be processed.
  The JIRA-GitHub connector will also be down.

* 7th November, 10:30-18:00 PDT (19:30-03:00 CET/02:30-10:00 Shanghai
  and Beijing)
  Our Windows canary builder will be offline, which means no new
  canaries will be produced in this period.

* 8th November, 10:30-18:00 PDT (19:30-03:00 CET/02:30-10:00 Shanghai
  and Beijing)
  Our Windows beta builder will be offline, which means no new betas
  will be produced in this period.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Crosswalk 23 has been branched; master is now 24

[Raphael Kubo da Costa]

Hi, everyone.

The crosswalk-23 branch has just been created, and 23.53.589.1, the
first beta release, is being built as I write this message.

This means that, as usual:
* master is now Crosswalk 24, and it will use Chromium M54.
* Our beta branch is crosswalk-23, with Chromium M53.. Remember to
  cherry-pick your bug fixes!
* Our stable branch is crosswalk-22. 22.52.561.4 was promoted to the
  stable channel a few days ago, and we're in the process of updating
  the website and writing an announcement. Use extreme caution when
  backporting new patches to the crosswalk-22 branch, and remember new
  builds will only be made on demand.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Chromium M53 has landed in Crosswalk

[Raphael Kubo da Costa]

It took a lot longer than it should have, but Chromium 53.0.2785.143 has
finally hit Crosswalk master (aka Crosswalk 23).

One of the biggest changes from a developer point of view is that gyp is
now fully *UNSUPPORTED*. gyp_xwalk is no longer run by default when
calling `gclient sync', and it is not expected to work. You MUST switch
to GN if you have not already done so. Instructions here:
https://crosswalk-project.org/contribute/building_crosswalk.html
We will remove the gyp code from the tree in the near future.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: You should switch to GN

[Raphael Kubo da Costa]

Hi, everyone,

I've been sending reports on our progress porting Crosswalk's build
system from gyp to GN. We've finally reached a point where all gyp
targets have been ported to GN on Linux and Android, and our canaries
will soon start being built with GN instead of gyp. Once we move
Crosswalk 23 to Chromium 53, building with gyp will no longer be
supported.

You should considering switching your build now to avoid any nasty
surprises. I've recently updated our official build instructions on the
website and they now cover GN (in addition to having been split into
separate, less confusing pages):

  https://crosswalk-project.org/contribute/building_crosswalk.html

The only additional thing you need to do while trying out GN with
Crosswalk + M52 is setting the GYP_CHROMIUM_NO_ACTION environment
variable when running `gclient sync', otherwise gyp_xwalk will still be
run automatically. This will not be necessary with M53.

Please switch your builds to GN and report any issues you stumble upon
in JIRA.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] GN and Crosswalk: status update and plans

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> Here's what we have in mind for the next steps:
> * Before moving Crosswalk 23 (master) to M53:
>   - Finish the Linux porting work.
>   - Port Android to GN _before_ moving to M53 (otherwise we'll need to
> carry our own patches making gyp work in chromium-crosswalk).
>   - Add a few Buildbot slaves building Crosswalk with GN in parallel
> with the existing ones, so that we know building with both build
> systems is working.

We are here.

> * After moving Crosswalk 23 to M53:
>   - Stop supporting gyp on Android and Linux.
>   - Switch our Android and Linux Buildbot slaves to GN and drop gyp from
> them.
>   - Investigate whether Windows is in good shape for the migration or
> whether we will need to wait for M54 to port it.

Linux and Android support in GN are both done and (hopefully) working. I
intend to switch our Android and Linux canary builds to GN today to
catch any regressions as early as possible. I will send a separate email
recommending everyone switch to GN.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Expanding coverage in xwalk_core_library_documentation?

[Raphael Kubo da Costa]

At the moment, the xwalk_core_library_documentation target invokes
javadoc and manually lists all files it wants to document. This is bad,
as it requires keeping the list up-to-date, and it's not at all clear to
anyone that this needs to be done.

Instead, I'd like to call javadoc on all classes in
runtime/android/core/src as well as all reflection wrapper classes.

If I ran javadoc correctly, this means the following new classes would
start being part of the API documentation:

org.xwalk.core.ClientCertRequestHandler
org.xwalk.core.CustomViewCallback
org.xwalk.core.CustomViewCallbackHandler
org.xwalk.core.XWalkActivityDelegate
org.xwalk.core.XWalkApplication
org.xwalk.core.XWalkExtension
org.xwalk.core.XWalkHitTestResult
org.xwalk.core.XWalkHitTestResult
org.xwalk.core.XWalkHttpAuth
org.xwalk.core.XWalkJavascriptResultHandler
org.xwalk.core.XWalkWebResourceRequestHandler
org.xwalk.core.extension.BindingObject
org.xwalk.core.extension.BindingObjectAutoJS
org.xwalk.core.extension.BindingObjectStore
org.xwalk.core.extension.EventTarget
org.xwalk.core.extension.ExtensionInstanceHelper
org.xwalk.core.extension.JsApi
org.xwalk.core.extension.JsConstructor
org.xwalk.core.extension.JsContextInfo
org.xwalk.core.extension.JsStubGenerator
org.xwalk.core.extension.MessageHandler
org.xwalk.core.extension.MessageInfo
org.xwalk.core.extension.XWalkExternalExtensionManagerImpl

Thoughts? Objections?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] GN and Crosswalk: status update and plans

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> Here's what we have in mind for the next steps:
> * Before moving Crosswalk 23 (master) to M53:
>   - Finish the Linux porting work.
>   - Port Android to GN _before_ moving to M53 (otherwise we'll need to
> carry our own patches making gyp work in chromium-crosswalk).
>   - Add a few Buildbot slaves building Crosswalk with GN in parallel
> with the existing ones, so that we know building with both build
> systems is working.
> * After moving Crosswalk 23 to M53:
>   - Stop supporting gyp on Android and Linux.
>   - Switch our Android and Linux Buildbot slaves to GN and drop gyp from
> them.
>   - Investigate whether Windows is in good shape for the migration or
> whether we will need to wait for M54 to port it.

We landed initial support for building Crosswalk Android with GN earlier
today, and I added some Android GN bots to our waterfalls a few hours
ago.

Pretty much all targets from gyp are there, except for the ones in
xwalk_core_library_android.gypi (which is being a nightmare to port).
This means it's not possible to create apps with app-tools because we
are not creating the app template yet, but building the "xwalk_builder"
generates all the APKs we need to run our device tests.

I have also rebased our "next" branch (tracking Chromium 53) on top of
our latest master to inherit all those GN changes. This has led to a few
more pull requests being sent to master (which I've temporarily
cherry-picked into next), but it is now possible to call "gn gen" and
generate an Android build on next.

People wanting to try out Android + GN (documentation on the website is
coming soon):

cd /path/to/src
gn args out/Release

  a text editor will pop up and you should enter the following:
  import("//xwalk/build/android.gni")
  target_os = "android"
  target_cpu = "x86"  # or "x64", or "arm" etc
  is_debug = false  # unless you want a debug build

That should be enough to call gn gen automatically, after which you can
use ninja as usual.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] JIRA downtime 11:00AM-01:00PM PST (was PSA: Planned JIRA downtime (9:00AM-11:00AM Sept 8th PST))

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> Hi everyone,
>
> JIRA will be offline on Thursday next week (September 8th) for some
> planned maintenance. The maintenance should take at most 2 hours, but
> likely less.
>
> We intend to take JIRA offline from 9:00AM to 11:00AM PST, which is
> 9:00PM-11:00PM in Helsinki and 0:00AM to 2:00AM in Shanghai (Friday).
>
> A banner warning of the downtime will also be put in JIRA next week to
> remind everyone that this is going to happen.

Hi again,

The maintenance has been rescheduled: it's now happening next week on
September 13th from 11:00AM to 01:00PM PST (so 11:00PM-01:00AM in
Helsinki and 02:00AM-04:00AM in Shanghai/Beijing).
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Planned JIRA downtime (9:00AM-11:00AM Sept 8th PST)

[Raphael Kubo da Costa]

Hi everyone,

JIRA will be offline on Thursday next week (September 8th) for some
planned maintenance. The maintenance should take at most 2 hours, but
likely less.

We intend to take JIRA offline from 9:00AM to 11:00AM PST, which is
9:00PM-11:00PM in Helsinki and 0:00AM to 2:00AM in Shanghai (Friday).

A banner warning of the downtime will also be put in JIRA next week to
remind everyone that this is going to happen.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] GN and Crosswalk: status update and plans

[Raphael Kubo da Costa]

"Kapade, Mrunal"  writes:

> It's great to hear this is finally landing in the master.
> Can you also make sure the documentation on our website is updated with 
> appropriate GN config?
> Especially this page, 
> https://crosswalk-project.org/contribute/building_crosswalk.html and other 
> related pages.

I'm basically just waiting for the Android GN code to land to make sure
everything is stable before updating the build instructions.

If you are feeling adventurous, here's what you need to do:
* Set the GYP_CHROMIUM_NO_ACTION environment variable to 1.
  It makes sure gyp_xwalk does not run as part of our hooks.
* cd /path/to/src
* gn gen --args='import("//xwalk/build/linux.gni") is_debug=false' //out/Release
  OR
  gn args //out/Release
  (and type import("//xwalk/build/linux.gni") and other arguments there)
* Run ninja as usual.

GN is also run automatically when you change any BUILD.gn or *.gni file,
so you don't have to manually invoke a script to regenerate your ninja
files every time you change the build system as is the case with gyp.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] GN and Crosswalk: status update and plans

[Raphael Kubo da Costa]

Hi, everyone,

Ke He and I have been working on porting Crosswalk to GN, Chromium's
(not so) new build system. gyp has been on the deprecation path for a
few releases now, and things are getting more serious with the most
recent Chromium milestones: IIRC, Android and Linux are using GN by
default starting with M53 (Android does not even seem to build by
default with gyp in M53, and gyp_chromium.py is no longer run
automatically in those platforms), and in M54 gyp is also not officially
supported on Windows and Mac. [1][2]

[1] 
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/PaDTGJFkUnk/llV3sJnTPgAJ
[2] 
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/NZkPr-CXvQ0/dn1rb8E8CAAJ

So far, we've recently landed (as in "a few hours ago") some patches
laying the groundwork in chromium-crosswalk and crosswalk, and it is now
possible to build Crosswalk for Linux on GN (with some missing features,
such as Web Notifications and our Debian package generator).

Here's what we have in mind for the next steps:
* Before moving Crosswalk 23 (master) to M53:
  - Finish the Linux porting work.
  - Port Android to GN _before_ moving to M53 (otherwise we'll need to
carry our own patches making gyp work in chromium-crosswalk).
  - Add a few Buildbot slaves building Crosswalk with GN in parallel
with the existing ones, so that we know building with both build
systems is working.
* After moving Crosswalk 23 to M53:
  - Stop supporting gyp on Android and Linux.
  - Switch our Android and Linux Buildbot slaves to GN and drop gyp from
them.
  - Investigate whether Windows is in good shape for the migration or
whether we will need to wait for M54 to port it.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to Remove: WebUI File Picker code

[Raphael Kubo da Costa]

"Hur, Joone" <joone@intel.com> writes:

> I’m okay to remove it. The code is still alive in ozone-wayland so we
> can apply it again when it needs.

Thanks. The WebUI File Picker code was removed in
https://github.com/crosswalk-project/crosswalk/pull/3862

> Thanks,
> Joone
>
>> On Aug 25, 2016, at 7:40 AM, Alexis Menard <ale...@menard.io> wrote:
>>
>> Hi,
>>
>>> On Aug 25, 2016, at 4:08 AM, Raphael Kubo da Costa 
>>> <raphael.kubo.da.co...@intel.com> wrote:
>>>
>>> The WebUI File Picker code was only used by the Tizen port, as it is
>>> disabled by default everywhere else.
>>>
>>> This means that the code has not been compiled for almost a year and
>>> nobody is maintaining it. I've just tried building with
>>> |use_webui_file_picker| on and got several build failures that prove it.
>>>
>>> I'd like to remove the code from master (Crosswalk 23) as soon as
>>> possible since it's just dead weight at the moment.
>>
>>
>> Joone?
>>
>>> ___
>>> Crosswalk-dev mailing list
>>> Crosswalk-dev@lists.crosswalk-project.org
>>> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
>>
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Intent to Remove: WebUI File Picker code

[Raphael Kubo da Costa]

The WebUI File Picker code was only used by the Tizen port, as it is
disabled by default everywhere else.

This means that the code has not been compiled for almost a year and
nobody is maintaining it. I've just tried building with
|use_webui_file_picker| on and got several build failures that prove it.

I'd like to remove the code from master (Crosswalk 23) as soon as
possible since it's just dead weight at the moment.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Reminder: Crosswalk 22 is branching tomorrow

[Raphael Kubo da Costa]

Hi, everyone,

This is your friendly reminder that the crosswalk-22 branch is going to
be created tomorrow, most likely out of 22.52.561.0 if all goes
according to plan.

crosswalk-21 will not be promoted automatically to the stable channel,
but new builds will be made on demand only if really necessary (as is
the case for crosswalk-20 at the moment).
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] M52 has reached Crosswalk

[Raphael Kubo da Costa]

Hi, everyone,

A few days ago pull request #3835 was finally merged, which means
Crosswalk's master branch (Crosswalk 22) has moved from Chromium 51 to
Chromium 52 (upstream's current stable series).

We're still using an older M52 version (52.0.2743.82 instead of
52.0.2743.116), but that should be fixed this week.

As usual when we move to a new Chromium milestone, things might be a bit
rough in the next few days, but it shouldn't take long for us to get
back to normal.

One important thing to notice is that WebCL support is still pending;
that is also going to be fixed soon.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] ANNOUNCEMENT: Crosswalk 20 for Android and Windows is stable

[Raphael Kubo da Costa]

Hi, everyone,

Crosswalk 20.50.533.12 is the first release in 20 series to be promoted
to the stable channel. We have official releases for Android and
Windows.

The release notes can be found here:
https://github.com/crosswalk-project/crosswalk/blob/crosswalk-20/RELEASENOTES.md

It's also important to mention that, just like the last Crosswalk 19
stable release before it, this release also includes the fix for the
security vulnerability announced a while ago:
https://lists.crosswalk-project.org/pipermail/crosswalk-help/2016-July/002167.html

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Crosswalk 21 is branching this Friday

[Raphael Kubo da Costa]

Hi all,

According to our release schedule, the crosswalk-21 branch will be
created this Friday, which means Crosswalk 21 will enter the beta
channel and master will be Crosswalk 22. Crosswalk 20 will not be
immediately promoted to the stable channel, though new Crosswalk 20
builds will only be done on demand.

The crosswalk-21 branch will tentatively be created this Friday morning
(European time) out of the latest "Bump version to A.B.C.D" automatic
commit, so the window for getting things automatically into the
crosswalk-21 branch will close on Thursday.

It's also a good time for you to go through your fixed bugs and merged
pull requests and determine if something still needs to be backported to
the crosswalk-20 branch.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: gclient now defaults to unmanaged mode

[Raphael Kubo da Costa]

Hi everyone,

This is a heads-up to all developers since this caught me (and the
Crosswalk infrastructure, our Buildbot slaves in particular) by
surprise.

As of about 2 days ago with https://codereview.chromium.org/2099153003,
gclient has switched the default value of the "managed" property to
False instead of True. This property in gclient (and .gclient files)
tells gclient whether it should try updating a repository when syncing:
when it is True, "gclient sync" will fetch and update a checkout, when
it is False it never touches a repository and one is responsible for
updating a repository manually when appropriate. Upstream Chromium
checkouts have recommended and used unmanaged checkouts for src for a
long time since it gives developers more control over when to update
their checkouts and sync.

For us, this means that:
* Calls to "gclient config" (for new Crosswalk checkouts) without
  "--managed" will result in an unmanaged src/xwalk. Since this matches
  upstream Chromium, I intend to mention this fact in our website build
  instructions rather than suggesting "--managed" in the tutorial.
* The behavior of existing Crosswalk checkouts largely depends on what
  your .gclient looks like:
  - If it has '"managed": False', nothing will change.
  - If it has '"managed": True', nothing will change since you are
explicitly telling gclient to update your src/xwalk on every call to
gclient sync. I don't particularly recommend this for people
actively working on the Crosswalk code base since the branch you are
working on can change under your feet.
  - If it has no "managed" entry, calling "gclient sync" will not update
src/xwalk automatically any longer.

I have committed e9f19a9 ("DEPS.xwalk: Explicitly set `managed` to True
in .gclient-xwalk") to master and crosswalk-20: like the title says, it
adds '"managed": True' to DEPS.xwalk (which later becomes
.gclient-xwalk) to keep the old behavior we still rely upon:
.gclient-xwalk is not generally used by hand, but rather invoked by our
fetch_deps.py script. It's important to have src/ in managed mode by
default, otherwise chromium-crosswalk checkouts will lag behind despite
our DEPS rolls.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Temporary Buildbot/release bot issues

[Raphael Kubo da Costa]

Hi everyone,

It looks like we've hit some Google daily rate limit and our bots are
currently having trouble updating their git checkouts of repositories
stored in chromium.googlestorage.com.

I have tried contacting Googlers, but at the moment there isn't a lot we
can do.

In practice, this means we have not been able to create our first
Crosswalk 20 beta build yet, and our Buildbot slaves are having trouble
in the "runhooks" stage since that involves connecting to
googlestorage.com. In the worst case, I guess this should be solved
automatically in at most a day, and I am also trying to figure out a
long-term solution to the problem.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Upcoming partial Buildbot downtime: May 25th 3:30PM PST

[Raphael Kubo da Costa]

Hey all,

This Wednesday (May 25th) we'll be taking some of our Buildbot slaves
offline due to some planned maintenance. The maintenance will begin at
3:30PM PST, and will last between 30min and 1 hour.

3:30PM PST is May 26th 00:30AM CET, May 26th 01:30AM Finland and May
26th 06:30AM in Shanghai/Beijing.

Happy hacking.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] We now have V8-ARM64 Buildbot slaves

[Raphael Kubo da Costa]

Hi all,

This actually happened last Friday, but I forgot to send the
announcement email: we finally have ARM64 slaves in both
build.crosswalk-project.org and build.crosswalk-project.org/try for
v8-crosswalk. Having them is useful for us to check that our
v8-crosswalk patches (SIMD.js and XDK support) do not break anything,
and we now cover all major platforms with our bots (ARM, ARM64, x86 and
x86-64).

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [Intent to remove] Widgets and Widget Access Request Policy APIs

[Raphael Kubo da Costa]

"Pozdnyakov, Mikhail"  writes:

> Specifications:
> https://www.w3.org/TR/widgets/
> https://www.w3.org/TR/widgets-access/
>
> Rationals:
> Not used on officially supported platforms.
> Brings lots of complexity to application/ and runtime/ code.

lgtm

What Crosswalk release are you targeting for this? Which platforms are
affected?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] New squash option for merging PRs in Github

[Raphael Kubo da Costa]

Note: in my responses I'm mostly thinking of the repositories I have to
deal with the most (chromium-crosswalk, v8-crosswalk and crosswalk),
your mileage may vary for other repositories.

"Zhang, Zhiqiang"  writes:
> I just tired it at
>
> https://github.com/w3c/web-platform-tests/pull/2834
>
>> What would the commit message look like (by default, a concatenation of all
>> commit messages)? How could we determine the pull request a change
>> came from (the number is included in the commit title)?
>
> Comparing the squashed commit (automatically generated by default) to
> the commits in the pull request, yes, the pull request number is
> included in the commit title.
>
> The commit message will simply use the title of the pull request +
> (pull request number) as its title, and lists all commits' titles as
> the unordered items as its body. See
>
> https://github.com/w3c/web-platform-tests/commit/2bd72173f4580563f51eaadd6c430465be4183be

Those were rhetorical questions which I answered myself above :-)

>> And if I were to choose between squashing or merging, I would stay with
>> merging:
>> - I really like it that GitHub can use git better than Rietveld (which
>>   was conceived at a time when git was not so widespread) including
>>   allowing separate commits for things that should be committed
>>   separately (like the PR I mentioned above). Squashing inevitably
>>   creates one big patch with everything.
>
> Actually GitHub supports both the two. It is up to you, repository
> admin, to use one of squashing or merging, or both.

Yes, that's why I said we should settle on one method or another before
(per repository or once for the entire organization).

>> - This is a problem more specific to our own workflow: it puts a higher
>>   burden on the person clicking the green button on the pull request
>>   page to squash the commits because they need to choose the final
>>   commit message. By default it's going to consist of all the commit
>>   messages concatenated, meaning that we will end up with commit
>>   messages saying "fix previous mistake", "now fix it for real" etc
>>   unless the person merging the PR takes the time to either write their
>>   own commit message, or copy-paste the pull request message etc.
>
> Yes, this is a little problem. The person needs to take more time to
> make the final commit message. But it is also a good chance for the
> person to polish the commit message before confirm the squashing
> merge.

I'd be fine with that if the person who submitted the pull request was
the one merging it, but most of the times this is not the case -- in
fact, I'm the one who's been merging most pull requests in the crosswalk
repository lately, and I wouldn't like to have to write the commit
message myself in addition to spending a lot of time reviewing code.

> Actually I am only concerned that we may lose related JIRA issue
> information in the final commit message. Say, a request pull only
> added BUG=XWALK-N to the PR description, but not in any title of the
> commits. The commit message won't include that information; thus
> cannot find JIRA issue in 'git log'. Any impact on your JIRA-PR
> linking system?

It won't impact the GitHub-JIRA system we have in place since it only
looks at the pull request message, but as you've rightfully pointed out
the squashed commit message will by default get rid of any longer
explanations in the commits being squashed, including issue numbers.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Partial infrastructure downtime (18th April 15:30 PST)

[Raphael Kubo da Costa]

Hi, everyone,

We're going to have some planned downtime in part of our infrastructure
today/tomorrow (depending on where you are in the world). During this
period, the following services will be taken offline or have limited
availability:
- build.crosswalk-project.org
- build.crosswalk-project.org/try
- Our GitHub-JIRA integration

The maintenance window is planned for today, 18th April 15:30-17:30 PST.
This means:
- 19th April 06:30-08:30AM Shanghai
- 19th April 01:30-03:30AM Helsinki
- 19th April 00:30-02:30AM CET
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] New squash option for merging PRs in Github

[Raphael Kubo da Costa]

"Kapade, Mrunal"  writes:

> Hi,
>
> Recently, Github enabled much needed squash and merge functionality
> for Pull Requests[1]. This leaves the decision to squash commits or
> not upto the user. That way you can see the history of all the
> intermediate changes which led to the final commit.
> I think we should all stop squashing commits while the PR is still
> under review. This should be similar to what we are accustomed to in
> Chromium's code review tool.
>
> What do you think?
>
> Mrunal
> [1] https://github.com/blog/2141-squash-your-commits

I don't think the comparison to Chromium's code review tool is fair, as
in Rietveld one CL must correspond to exactly one commit (there is no
way for one to associate several commits to one CL at all) whereas with
GitHub that limitation does not exist. One could even say that with
Rietveld one _must_ squash all changes when sending or updating a CL.

With that said, I decided to give the squash option a try with a test
repository as I had only read about it and did not know how certain
issues would be handled: would it create a merge commit + a squashed
commit or just add a squashed patch on top of HEAD (it does the latter)?
What would the commit message look like (by default, a concatenation of
all commit messages)? How could we determine the pull request a change
came from (the number is included in the commit title)?

For a repository handling contributions from many different people such
as Crosswalk, at the very least we need to opt for one style or another
IMO. If we decide that both are valid and can be used at each
contributor's discretion, we can end up with A) merge commits with
several "fix previous commit" changes that should not have been
committed B) single squashed commits of things that should have been
committed separately (e.g. pull request #3645).

And if I were to choose between squashing or merging, I would stay with
merging:
- I really like it that GitHub can use git better than Rietveld (which
  was conceived at a time when git was not so widespread) including
  allowing separate commits for things that should be committed
  separately (like the PR I mentioned above). Squashing inevitably
  creates one big patch with everything.
- This is a problem more specific to our own workflow: it puts a higher
  burden on the person clicking the green button on the pull request
  page to squash the commits because they need to choose the final
  commit message. By default it's going to consist of all the commit
  messages concatenated, meaning that we will end up with commit
  messages saying "fix previous mistake", "now fix it for real" etc
  unless the person merging the PR takes the time to either write their
  own commit message, or copy-paste the pull request message etc.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to Implement: WebAudio API for audio clock synchronization

[Raphael Kubo da Costa]

"Pozdnyakov, Mikhail"  writes:

> Description:
> Implementation of the WebAudio API[1] extension that allows web
> developers to synchronize audio stream playing with other events in
> DOM. Pls. see [2] for the proposed API description and [3] for
> motivation and WG discussions around this topic.
>
> Platform: Windows
>
> [1] https://www.w3.org/TR/webaudio/
> [2] https://github.com/WebAudio/web-audio-api/pull/754
> [3] https://github.com/WebAudio/web-audio-api/issues/12

Hey guys,

The first big patch landed a while ago with
https://github.com/crosswalk-project/chromium-crosswalk/pull/332.

I later created XWALK-6675 to track the style issues introduced by that
change, and later we had XWALK-6703 which was a regression introduced by
pull request #332 which was fixed by #342.

Since this work is highly experimental and we are very close to
Crosswalk 19 to the beta channel, I'd like to propose moving this to
Crosswalk 20 only: the chromium-crosswalk and crosswalk git repositories
remain unchanged, but chromium-crosswalk pull requests #332 and #342 get
reverted in the crosswalk-19 branch to avoid regressions and disruptions
at this point of the branch's lifecycle.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] How can i solved this problem?

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> 윤영석 <earw...@naver.com> writes:
>
>> [586:586:0331/065405:FATAL:desktop_factory_ozone.cc(21)] Check failed:
>> impl_. DesktopFactoryOzone accessed before constructed
>> #0 0x004cc5ce 
>> #1 0x0048dbce 
>> #2 0x029b5661 
>> #3 0x02994cb9 
>> #4 0x004759ba 
>> #5 0x004709c6 
>> #6 0x00bd16d1 
>> #7 0x00d2519f 
>> #8 0x00bd7283 
>> #9 0x00bd973a 
>> #10 0x033273f3 
>> #11 0x02d0e8d4 
>> #12 0x02d0ce81 
>> #13 0x0044e1f8 
>> #14 0x7f0f09e61620 __libc_start_main
>> #15 0x0044fed9 _start
>>
>> ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf
>> failure in syscall 0063
>
> Have you tried passing `--no-sandbox' or
> `--disable-seccomp-filter-sandbox' to the xwalk binary?
>
> ozone-wayland's README recommends passing --no-sandbox so it's not clear
> if it's really expected to work if you don't pass any parameter to the
> binary.

Erm, I don't know why I thought you were using ozone-wayland. I remember
having similar errors a while ago on Fedora but they seem to have been
solved. Try passing one of the sandbox flags, or check if you need to
update your kernel or mesa.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] How can i solved this problem?

[Raphael Kubo da Costa]

윤영석  writes:

> [586:586:0331/065405:FATAL:desktop_factory_ozone.cc(21)] Check failed:
> impl_. DesktopFactoryOzone accessed before constructed
> #0 0x004cc5ce 
> #1 0x0048dbce 
> #2 0x029b5661 
> #3 0x02994cb9 
> #4 0x004759ba 
> #5 0x004709c6 
> #6 0x00bd16d1 
> #7 0x00d2519f 
> #8 0x00bd7283 
> #9 0x00bd973a 
> #10 0x033273f3 
> #11 0x02d0e8d4 
> #12 0x02d0ce81 
> #13 0x0044e1f8 
> #14 0x7f0f09e61620 __libc_start_main
> #15 0x0044fed9 _start
>
> ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf
> failure in syscall 0063

Have you tried passing `--no-sandbox' or
`--disable-seccomp-filter-sandbox' to the xwalk binary?

ozone-wayland's README recommends passing --no-sandbox so it's not clear
if it's really expected to work if you don't pass any parameter to the
binary.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: We are now using PRESUBMIT.py + call for help

[Raphael Kubo da Costa]

Hi, everyone,

So far, we had been using a homegrown script called lint.py in the
"check coding style" step of our trybots whenever a pull request was
created or updated. This script had a number of limitations and was
raising several false positives especially with chromium-crosswalk pull
requests. It has finally been dropped and replaced by a PRESUBMIT.py
script in pull request #3636 (XWALK-1853).

Presubmit scripts are used in Chromium and other upstream projects, and
are generally run when a patch is uploaded or going to be committed via
Chromium's commit queue. They are regular Python scripts, and thus can
do *a lot more* than just checking coding style. More information can be
found here:


In practice, this means that whenever a new chromium-crosswalk,
v8-crosswalk or Crosswalk pull request is created/updated, something
similar to this will be run:
  presubmit_support.py --upload --skip_canned CheckOwners \
   --upstream origin/master

v8-crosswalk and chromium-crosswalk pull requests will run the upstream
projects' respective PRESUBMIT.py scripts, meaning it will correctly
differentiate the coding style in Chromium and Blink, for example, in
addition to checking line endings, whether forbidden functions are being
used and a number of other things.

I have added a small PRESUBMIT.py to Crosswalk which runs cpplint (like
we were doing before, but better) and also performs a few other small
checks.

Here is where you can help! If you open Crosswalk's PRESUBMIT.py you
will see that several checks are disabled (including some very useful
ones that check the copyright header in all files and do code checks on
Java files). I would like to enable all of them, but we need to fix all
violations that they report first:
 * Open PRESUBMIT.py
 * Choose a commented out check you'd like to enable and uncomment it
   out.
 * Run
  presubmit_support.py --upload --skip_canned CheckOwners \
 --upstream e15c294f4be2d14590582d9f6876e2680209581e
   That is the hash of the first commit in the Crosswalk git repository,
   and the whole line makes PRESUBMIT.py check all existing files.
 * Fix the reported violations.
 * Send a pull request with everything you have done.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] how to disable optimize option during compile?

[Raphael Kubo da Costa]

윤영석  writes:

> i got a error message, that is below.
>
> may be used uninitialized in this function -wmaybe-uninitialized
>
> I saw the solution via searching goole.
> If Optimization option was disable, it will be fine. ( remove -O2
> option)
>
> But i can't found where is option of gcc.
>
> Below files may relate in this error, but i can't catch them.
> src/build/config/BUILD.gn
> src/build/config/BUILDCONFIG.gn
> src/build/config/linux/*
>
> could you please let me know hot to disable optimize option ?

Instead of changing your compiler flags, you should check what part of
the code is causing the issue and possibly fix it. The compiler version
you are using is also a variable here, so you should also make sure that
you're not using something too old that is raising false positives.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Help: a confused error for build

[Raphael Kubo da Costa]

Nick  writes:

> Hi,
>
> I am trying to build the crosswalk runtime from source code. But
> unfortunately, I got a confused error while executing "python
> xwalk/gyp_xwalk" just at the beginning...
> 
> $ python xwalk/gyp_xwalk
> Updating projects from gyp files...
> gyp:
> /home/cainick/Projs/crosswalk-src/src/third_party/android_tools/android_tools.gyp
> not found (cwd: /home/cainick/Projs/crosswalk-src/src)
> gyp: /home/cainick/Projs/crosswalk-src/src/v8/tools/gyp/v8.gyp not
> found (cwd: /home/cainick/Projs/crosswalk-src/src)
[...]
> I totally have no idea to do something to fix it now... Is there
> anyone who had met the same error? Or anyone know it's root cause? If
> so, it would be very very helpful for me.

It looks like you are missing pretty much all directories in your
checkout other than src/xwalk. Did you follow the instructions on our
website? Can you attach a log with your entire gclient sync output?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Announcement: we now have Crosswalk Windows canaries

[Raphael Kubo da Costa]

Hi, everyone,

We've finally started producing Crosswalk Windows canaries together with
our Android and Linux (Debian-based) canaries. Up to now, our Windows
canaries were produced manually, infrequently and without the goal of
reaching our end users very broadly.

This has now changed, and we hope everyone interested can start testing
our canaries and provide feedback if something suddenly breaks.

Our canaries can be downloaded from here:


At the moment, we only ship 64-bit canaries targeting Windows >= 8.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to Implement: WebAudio API for audio clock synchronization

[Raphael Kubo da Costa]

"Pozdnyakov, Mikhail"  writes:

> Description:
> Implementation of the WebAudio API[1] extension that allows web
> developers to synchronize audio stream playing with other events in
> DOM. Pls. see [2] for the proposed API description and [3] for
> motivation and WG discussions around this topic.
>
> Platform: Windows
>
> [1] https://www.w3.org/TR/webaudio/
> [2] https://github.com/WebAudio/web-audio-api/pull/754
> [3] https://github.com/WebAudio/web-audio-api/issues/12

Things which are not clear to me after reading this message:
- This looks more like something to be implemented in Chromium than in
  Crosswalk. What's the situation in Chromium regarding this feature?
- Why do we need this in Crosswalk for Windows? And why is this not
  needed for other platforms?
- Can you describe in a few lines what kind of work will be done in
  Crosswalk (e.g. what needs to be plugged into what)?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Unplanned downtime in part of our infrastructure

[Raphael Kubo da Costa]

Hi all,

We're having some issues with the machine hosting our Buildbot masters
(and the GitHub-JIRA integration); it is currently offline.

We hope to resolve the issue within the next few hours.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] XWalkAutofillClient::OnFirstUserGestureObserved() after first touch on view

[Raphael Kubo da Costa]

Petrus Repo  writes:

> Hi!
>
> I'm getting this error after first touch gesture on XWalkView:
>
> E/chromium: [ERROR:xwalk_autofill_client.cc(170)] Not implemented
> reached in virtual void
> xwalk::XWalkAutofillClient::OnFirstUserGestureObserved()
>
> this happens especially with input fields, where it sometimes blocks
> further action.
>
> I can reproduce it in my old proof-of-concept repo (just start it and
> touch around the views):
>
> https://github.com/pre/PoC-XWalkIframeConnectionRefused
>
> I get the error on Crosswalk 14.43.343.17 and 17.46.448.8.
>
> I found this similar looking issue:
> - 
> http://stackoverflow.com/questions/33827199/clicking-any-button-more-than-once-in-crosswalk-browser-does-not-work
> - https://crosswalk-project.org/jira/browse/XWALK-6067

We spoke about this briefly on XWALK-6067, but it looks like it's
unrelated to the problem you're having (the "not implemented" message is
a red herring that we should probably disable in official builds).

In that ticket, you say:

> My issues have been:
> error in Java-side of things --> "Not implemented reached in virtual void "
> error in JavaScript-side of things --> "Not implemented reached in virtual 
> void "

Given that "not implemented" messages on their own are not a problem
(they just indicate that a certain method has an empty implementation),
can you elaborate on what issues you're having?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Crosswalk 18 branched, master is now Crosswalk 19

[Raphael Kubo da Costa]

Hi, everyone,

Crosswalk 18 has just been branched off master and promoted to the beta
channel. The first beta release will be 18.48.477.1. We did experience a
delay in branching again, but it has been much shorter than what we had
for Crosswalk 17.

As usual, please keep in mind the following:
* Make sure your bug fixes go into the crosswalk-18 branch.
* Check your open pull requests and determine whether they need to be
  backported to crosswalk-18 once they land in master.
* Only P1 bug and security fixes go into the crosswalk-17 branch.
* New Crosswalk 17 beta builds will only be made on demand.

At this time, Crosswalk 16 has *NOT* been promoted to the stable channel
yet. In practice, this means Crosswalk 16 is still our stable release,
Crosswalk 17 is in beta but new builds will only be done on demand,
Crosswalk 18 is in beta and new beta builds will be done automatically
on a daily basis and Crosswalk 19 is in our canary channel.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] PSA: Planned downtime tomorrow (Feb 4th)

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> Hi everyone,
>
> We have a maintenance window planned for tomorrow in order to do some
> behind-the-scenes infrastructural work on some of our servers.
>
> During this period, the following services will be offline or with
> limited availability:
>  * build.crosswalk-project.org and build.crosswalk-project.org/try
>  * Triggering of Trybots when a pull request is sent or updated
>  * GitHub-JIRA connector
>
> The maintenance is planned for tomorrow (Feb 4th) from 8:00AM to 9:00AM
> PDT, but if all goes well it should take less than that. In other time
> zones:
>  * 5:00PM-6:00PM CET
>  * 6:00PM-7:00PM Finland
>  * 0:00AM-1:00AM next day in Beijing/Shanghai

We're back and everything should be in order. If you experience
something weird (such as a pull request not updating a related JIRA
ticket, for example), please let us know.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Welcome, Chromium M48!

[Raphael Kubo da Costa]

Hi, everyone,

As some of you might have already noticed, master (Crosswalk 18) has
moved from Chromium 46.0.2490.86 to 48.0.2564.79. That's pretty close to
48.0.2564.82, which was released yesterday and became the first M48
stable release upstream (we're already working on moving to .82).

Skipping M47 and moving directly to M48 required quite a lot of effort,
so thanks to everyone who's helped with the rebase.

https://github.com/crosswalk-project/crosswalk/pull/3498 contains a
fairly long description of what has changed, so I'll just list the most
important topics here:

 * The ozone-wayland repository is no longer being pulled in, as we have
   stopped maintaining the Linux Ozone-Wayland configuration for now.

 * Presentation API support is currently broken and the tests have been
   temporarily disabled. The existing extension will be replaced by code
   that integrates the Chromium implementation, which has started
   shipping in M48. This is being tracked in XWALK-4646.

 * When checking out Crosswalk for Android, we no longer skip
   downloading the Google Play services library pulled by the Chromium
   code. This was caused by two factors:
   1. The upstream code has become more friendly towards dowstreams like
   us and does not try to fetch files only accessible within Google's
   intranet when CHROME_HEADLESS=1 (ie. bots).
   2. Given the above, maintaining the hacks and workarounds to avoid
   fetching that library is not worth it.
   One important consequence is that users will be prompted to accept
   the Google Play services library's EULA once, and not accepting it
   will make the build fail (a directory needed by gyp will not be
   present). Anyone willing to avoid the prompt (when automating
   Crosswalk's build, for example) needs to set the CHROME_HEADLESS
   environment variable and make sure it is OK to automatically accept
   the EULA.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to deprecate: Cordova Android 3.6 support

[Raphael Kubo da Costa]

"Balestrieri, Francesco"  writes:

> The preferred way to use Crosswalk in Cordova applications is the
> Cordova Crosswalk webview plugin, which has been in use for more than
> half a year. It is therefore time to remove the Crosswalk fork of
> Cordova Android 3.6 platform.
>
> Affected components:
> https://github.com/crosswalk-project/crosswalk-cordova-android and
> related release artifacts, plus some tweaks in documentation.
>
> Related feature: https://crosswalk-project.org/jira/browse/XWALK-6137
>
> Target release: could be as early as Crosswalk 18 based on the feedback to 
> this email
>
> Implementation details: nothing special, just stop building the
> cordova zip archives in the bots and cease all QA activities.

lgtm
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Goodbye, make_apk

[Raphael Kubo da Costa]

Hi, everyone,

This is an update on the "intent to deprecate and remove make_apk" sent
a few months ago (XWALK-5629).

Yesterday I finally landed a change removing make_apk and its test suite
from the source tree, meaning it is now a thing of the past. Everyone is
encouraged to use (and contribute to) the app-tools project.

As an added bonus, not running make_apk's test suite on our Android bots
makes each run be at least 15min faster.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Crosswalk-website compile problem

[Raphael Kubo da Costa]

"Wei, Xiaosong"  writes:

> Did anybody run into “harp compile” problem with the latest
> crosswalk-website? Any help is appreciated. Thanks!
>
> [xiaosong@xiaosong-desktop crosswalk-website]$ harp compile

I'm not sure if Bob Spencer is subscribed to crosswalk-dev. If the
problem persists, you can file a bug in JIRA for the "Website"
component.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Crosswalk 17 has been branched, master is now 18

[Raphael Kubo da Costa]

Hi, everyone,

At long last, Crosswalk 17 has been branched and promoted to the beta
channel. The first beta release will be 17.46.448.1.

As usual, please keep in mind the following:
* Make sure your bug fixes go into the crosswalk-17 branch.
* Check your open pull requests and determine whether they need to be
  backported to crosswalk-17 once they land in master.
* Only P1 bug and security fixes go into the crosswalk-16 branch.
* New Crosswalk 16 beta builds will only be made on demand.

At this time, Crosswalk 16 has *NOT* been promoted to the stable channel
yet. In practice, this means Crosswalk 15 is still our stable release,
Crosswalk 16 is in beta but new builds will only be done on demand,
Crosswalk 17 is in beta and new beta builds will be done automatically
on a daily basis and Crosswalk 18 is in our canary channel.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] RFC: Rename crosswalk-cordova zip file shipped in download.01.org

[Raphael Kubo da Costa]

The crosswalk-cordova zip file we ship in download.01.org is outdated
and based on a fork of a somewhat old version of Cordova 3. Our website
already mentions that and encourages users to use the Crosswalk WebView
plugin with a more recent Cordova instead.

I woud like to:
- Rename the zip file to crosswalk-cordova3--.zip
  starting from Crosswalk 16.
- Update the README in the crosswalk-cordova-android git repository and
  mention it is outdated and people should use Cordova 4 instead,
  starting from Crosswalk 16.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: chromium-crosswalk now contains Blink

[Raphael Kubo da Costa]

Hi, fellow pedestrians,

As most of you know, about two months ago the Chromium project finally
managed to merge the Blink git repository into the main Chromium
repository, meaning src/third_party/WebKit is now part of the same
repository as src/ itself. Since then, all new releases for all Chromium
milestones were made with the same model, even for stable branches like
M45 at the time.

With the last chromium-crosswalk roll in both master and crosswalk-16,
we have finally inherited this change, and blink-crosswalk is now part
of chromium-crosswalk for crosswalk-16 (M45), master (M45) and next
(M46, to be merged into master soon).

This change should be transparent to everyone. The only difference is
that the first time you fetch the chromium-crosswalk git repository (via
gclient sync, for example), it will fetch around 1.5GB of new data
(Blink's commit history) and move your old blink-crosswalk checkout to a
new location.

In any case, please pay attention to the following points that may
affect your work flow:

- The blink-crosswalk git repository is now DEPRECATED. It is not going
  to be used by Crosswalk checkouts anymore, and no new development is
  supposed to be done there. If you send a pull request to
  blink-crosswalk, it is NOT going to be integrated into Crosswalk.

  Crosswalk Lite is a different matter though, as it is still based on
  Crosswalk 15 and has a different work flow. If you are working on
  Crosswalk Lite, this does not impact you, unless you use the same tree
  for working on both Lite and regular Crosswalk. This is probably not
  going to work anymore.

- Once you gclient sync for the first time after this update, PAY
  ATTENTION to what gclient tells you. It will move your existing
  src/third_party/WebKit checkout to a separate location, and you should
  remove it manually if you do not have any use for it.

- If you have any pending blink-crosswalk pull requests, they will need
  to be resubmitted to the chromium-crosswalk repository.

- If you have any blink-crosswalk branches with work you need to move to
  chromium-crosswalk, follow the "How to migrate local
  /src/third_party/WebKit branches" instructions from upstream:
https://www.chromium.org/blink/blink-post-merge-faq

- If you have an existing build directory and care about the contents of
  the UPSTREAM.blink file (which now contains a git hash corresponding
  to the Chromium revision we are at for the right DevTools theme to be
  fetched), make sure you run `gclient sync' *twice*, as it is possible
  that the file will be generated with the contents of the old
  third_party/WebKit checkout you have.
  You can also just run the hook that generates UPSTREAM.blink if you
  know enough about our build system.

Happy hacking.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to deprecate: make_apk packaging tool

[Raphael Kubo da Costa]

"Balestrieri, Francesco" <francesco.balestri...@intel.com> writes:

> On 03/11/15 14:56, "Crosswalk-dev on behalf of Raphael Kubo da Costa" 
> <crosswalk-dev-boun...@lists.crosswalk-project.org on behalf of 
> raphael.kubo.da.co...@intel.com> wrote:
>
>
>>"Balestrieri, Francesco" <francesco.balestri...@intel.com> writes:
>>
>>> “make_apk" is a Python script included in the crosswalk distribution
>>> that automates the creation of APKs of Crosswalk-based HTML5
>>> applications. It is replaced by crosswalk-app-tools and can therefore
>>> be removed if there are no objections.
>>>
>>> Affected component: make_apk and related tests
>>>
>>> Related feature: https://crosswalk-project.org/jira/browse/XWALK-5629
>>>
>>> Target release: Crosswalk 18
>>>
>>> Implementation details: Basically this is about removing
>>> https://github.com/crosswalk-project/crosswalk/tree/master/app/tools/android
>>> from the tree and updating all documentation to point to the new tool.
>>
>>When you say "deprecate" you mean "remove", right? How about adding a
>>big warning in Crosswalk 17's make_apk saying it will be deprecated,
>>announcing this deprecation as soon as possible and update the
>>documentation before this happens? This way we'd have everything
>>prepared before Crosswalk 18, and getting rid of it would be simpler.
>
> Agreed

lgtm+++ then :-)
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to deprecate: make_apk packaging tool

[Raphael Kubo da Costa]

"Balestrieri, Francesco"  writes:

> “make_apk" is a Python script included in the crosswalk distribution
> that automates the creation of APKs of Crosswalk-based HTML5
> applications. It is replaced by crosswalk-app-tools and can therefore
> be removed if there are no objections.
>
> Affected component: make_apk and related tests
>
> Related feature: https://crosswalk-project.org/jira/browse/XWALK-5629
>
> Target release: Crosswalk 18
>
> Implementation details: Basically this is about removing
> https://github.com/crosswalk-project/crosswalk/tree/master/app/tools/android
> from the tree and updating all documentation to point to the new tool.

When you say "deprecate" you mean "remove", right? How about adding a
big warning in Crosswalk 17's make_apk saying it will be deprecated,
announcing this deprecation as soon as possible and update the
documentation before this happens? This way we'd have everything
prepared before Crosswalk 18, and getting rid of it would be simpler.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Crosswalk 16 has been branched, master is now 17

[Raphael Kubo da Costa]

Hi, fellow pedestrians,

Crosswalk 16 has just been branched and promoted to the beta channel.
The first beta is being built right now.

As usual, this means that:
- Crosswalk's master branch is now Crosswalk 17.
- Only bug fixes go into the crosswalk-16 branch.
- New crosswalk-15 builds will only be made on demand, following fixes
  for high importance bugs.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Build error in Crosswalk for Android

[Raphael Kubo da Costa]

"Hur, Joone"  writes:

> Hi,
>
> I got the following build error:
>
> [34/12518] CXX obj.host/v8/src/base/v8_libbase.cpu.o
> FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD
> -MF obj.host/v8/src/base/v8_libbase.cpu.o.d -DV8_DEPRECATION_WARNINGS
> -D_FILE_OFFSET_BITS=64 -DNO_TCMALLOC -DDISABLE_NACL -DENABLE_WEBCL=1
> -DCHROMIUM_BUILD -DCR_CLANG_REVISION=241602-2 -DUSE_LIBJPEG_TURBO=1
> -DENABLE_WEBRTC=1 -DUSE_PROPRIETARY_CODECS -DENABLE_BROWSER_CDMS
> -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS
> -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DDONT_EMBED_BUILD_METADATA
> -DENABLE_AUTOFILL_DIALOG=1 -DCLD_VERSION=1 -DENABLE_PRINTING=1
> -DENABLE_BASIC_PRINTING=1 -DENABLE_SUPERVISED_USERS=1 -DVIDEO_HOLE=1
> -DMOBILE_SAFE_BROWSING -DSAFE_BROWSING_SERVICE -DV8_TARGET_ARCH_ARM
> -DCAN_USE_ARMV7_INSTRUCTIONS -DCAN_USE_VFP3_INSTRUCTIONS
> -DV8_I18N_SUPPORT -DUSE_LIBPCI=1 -DUSE_OPENSSL=1 -DUSE_OPENSSL_CERTS=1
> -DUSE_EABI_HARDFLOAT=0 -DNDEBUG -DNO_UNWIND_TABLES -DNVALGRIND
> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../v8 -Igen -fstack-protector
> --param=ssp-buffer-size=4 -pthread -fno-strict-aliasing
> -Wno-unused-parameter -Wno-missing-field-initializers
> -fvisibility=hidden -pipe -fPIC -Wno-format -Wheader-hygiene
> -Wno-char-subscripts -Wno-unneeded-internal-declaration
> -Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing
> -Wno-deprecated-register -Wno-inconsistent-missing-override
> -Wno-shift-negative-value -Wno-overloaded-virtual -m32 -fno-ident
> -fdata-sections -ffunction-sections -fomit-frame-pointer
> -fno-unwind-tables -fno-asynchronous-unwind-tables -fdata-sections
> -ffunction-sections -O2 -fno-exceptions -fno-rtti
> -fno-threadsafe-statics -fvisibility-inlines-hidden -Wno-deprecated
> -std=gnu++11 -c ../../v8/src/base/cpu.cc -o
> obj.host/v8/src/base/v8_libbase.cpu.o
> In file included from ../../v8/src/base/cpu.cc:5:
> In file included from ../../v8/src/base/cpu.h:16:
> In file included from ../../v8/src/base/macros.h:11:
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/cstring:41:10: 
> fatal error: 'bits/c++config.h' file not found
> #include 
>  ^
> 1 error generated.

It looks like you're missing the 32-bits development headers: you're
running a 64-bits kernel and userland, but this part of the build is
supposed to generate a 32-bits executable.

Make sure you run src/build/install-build-deps-android.sh, or just make
sure all the necessary 32-bits packages are installed.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] We have a Windows slave now

[Raphael Kubo da Costa]

Hello, fellow pedestrians,

We finally have a Windows slave in build.crosswalk-project.org. It
builds the code and runs the same tests the Linux slave does. Since it's
Windows, it is somewhat slow (a full build from scratch takes 1h30min),
but it should not impact your activities that much.

The slave is still in an experimental status; if things break, please
report a bug in JIRA.

Do note that right now there's only one slave in
build.crosswalk-project.org; there is no Trybot slave yet, but we do
intend do add one soon.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] PSA: Upcoming infrastructure downtime (21-Sept)

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:
>
>> We plan on performing some maintenance on part of our infrastructure on
>> Monday, 21st September 2015, starting at 08:00 Portland time (17:00 CET,
>> 18:00 Helsinki, 23:00 Shanghai). It should last between 30min to 1h.
>>
>> During this period, the following services will be offline or
>> intermittent:
>> - build.crosswalk-project.org and build.crosswalk-project.org/try
>> - The GitHub-JIRA integration that closes tickets and references pull
>>   requests.
>
> The services are back, but we're still performing some background
> maintenance. Please report any abnormalities you may encounter.

I think everything should be back to normal. We had issues with the pull
request/Trybot integration today, which were resolved a couple of hours
ago. All pending patches are now being processed.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] PSA: Upcoming infrastructure downtime (21-Sept)

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> writes:

> We plan on performing some maintenance on part of our infrastructure on
> Monday, 21st September 2015, starting at 08:00 Portland time (17:00 CET,
> 18:00 Helsinki, 23:00 Shanghai). It should last between 30min to 1h.
>
> During this period, the following services will be offline or
> intermittent:
> - build.crosswalk-project.org and build.crosswalk-project.org/try
> - The GitHub-JIRA integration that closes tickets and references pull
>   requests.

The services are back, but we're still performing some background
maintenance. Please report any abnormalities you may encounter.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Upcoming infrastructure downtime (21-Sept)

[Raphael Kubo da Costa]

We plan on performing some maintenance on part of our infrastructure on
Monday, 21st September 2015, starting at 08:00 Portland time (17:00 CET,
18:00 Helsinki, 23:00 Shanghai). It should last between 30min to 1h.

During this period, the following services will be offline or
intermittent:
- build.crosswalk-project.org and build.crosswalk-project.org/try
- The GitHub-JIRA integration that closes tickets and references pull
  requests.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] link error for build cross walk by integrating a library (ARM, EABI5 version 1)

[Raphael Kubo da Costa]

Gary Chine garych...@sina.com writes:

 The library libgdndk.so is referenced by obj.host/base/libbase.a ,I
 add '-m32' as ldflags.
[...]
 I wonder why I need to build on the 'host' toolset,but not only the
 'target' toolset.

From your message it is not clear how you specified this new library in
your build system. From what I could gather you should not need it in
the host part at all (and you also cannot use it since they're for
different architectures anyway). As far as I can see it should only be
used by the target targets.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to switch: using our own GitHub copy of the OpenCL headers

[Raphael Kubo da Costa]

Hu, Jiajie jiajie...@intel.com writes:

 Thanks for proposal and actually I have had the same idea for a long
 time that SVN should no longer be used for the OpenCL headers.

 However, I prefer to add these headers to third_party/khronos in
 chromium-crosswalk.git like
 https://github.com/crosswalk-project/chromium-crosswalk/pull/188, just
 as how OpenGL headers are managed in Chromium, instead of hosting them
 in a dedicated repo.

 WDYT?

Is there a reason why you think this is a better approach? I'd like to
avoid adding new commits (especially ones like this which have no chance
of being upstreamed as-is) to chromium-crosswalk if at all possible, so
putting things in a separate repository was the best I could come up
with.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to switch: using our own GitHub copy of the OpenCL headers

[Raphael Kubo da Costa]

Hu, Jiajie jiajie...@intel.com writes:

 OK.. I'm just expressing my own opinion, and I just want to keep
 things consistent with WebGL / OpenGL. It's not quite a big issue for
 me where the headers are hosted.

Alright, in this case I'll move forward with hosting them in a separate
repository.

 You mentioned that you want to avoid adding new commits (especially
 ones which have no chance of being upstreamed) to chromium-crosswalk,
 this raises another concern for me. For historical reasons, by now
 almost all WebCL code are located in src/WebKit/Source/modules/webcl,
 and this minimizes the effort required during rebase. However,
 strictly speaking this is not the right architecture because system
 hardware is accessed within Blink. We are considering moving some code
 from Blink to src/content and migrating to Chromium's multi-process
 model gradually so that WebCL can be used on platforms other than
 Android. This will apparently be a much more complex task than
 committing the OpenCL headers (see how WebGL is implemented), so I'm
 afraid that will be totally contrary to the philosophy of avoiding new
 commits.

Yeah, this is one big topic to discuss then. I don't have much to say at
the moment; basically if we decide it's the way forward and it pays off
there isn't a lot we can do other than try to minimise the changes we
make to existing files (just like we do in Blink).
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Intent to switch: using our own GitHub copy of the OpenCL headers

[Raphael Kubo da Costa]

This isn't really an intent to implement, but the idea is similar.

So far we've been fetching the OpenCL headers we use for WebCL directly
from Khronos's SVN repository. We probably rolled to a different
revision only once so far.

As people who live behind corporate proxies know, SVN is yet another
thing that needs to be configured, and access to Khronos's repository
can be flaky at times.

I would then like to make a copy of the repository and host it in the
crosswalk-project organization, with a name like khronos-cl-api-1.2
instead. This allows us to switch back to a workflow entirely based on
git, which makes things easier from a maintenance perspective.

I have made a test conversion with git-svn and hosted it here:
https://github.com/rakuco/khronos-cl-api-1.2

Does anyone have objections?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] The toolset host and target

[Raphael Kubo da Costa]

garychine garych...@sina.com writes:

 Hi All,
 When build xwalk_core_library,it default use the toolset host.If I
 just want to use the target toolset ,like arm for android.What can I
 do for that?

You're mixing things up. A small subset of the source tree needs to be
built both on the host and the target, which is why you see some
CXX.host lines in your build.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] The c++ compiler for CrossWalk

[Raphael Kubo da Costa]

Gary Chine garych...@sina.com writes:

 Hi All,

 I noticed that when I build crossWalk,the c++ compiler used is clang,

 FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD

 [...]

You did not paste the actual error that this compiler invocation threw,
so it is hard to help.

 [...]

 I find clang is too strict and don't allow convert from stat64* to
 stat*,and that's OK under g++.Can I change the compiler back to g++?

Just pass clang=0 to gyp. But doing that means you are not building with
a configuration used by upstream, which uses clang by default. And going
back to GCC because you are seeing errors with clang likely means you
will end up hiding the symptoms of an actual problem you have in your
code.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to Implement: Change Dialog of XWalkResourceClient.onReceivedLoadError to Toast

[Raphael Kubo da Costa]

Xu, Xing xing...@intel.com writes:

[...]
 So here my suggestion: Change this dialog to Android Toast
 (http://developer.android.com/guide/topics/ui/notifiers/toasts.html).

 Toast will inform users that something is wrong with network, but no
 need to click any “OK” button.

 Affected component:

 XWalkResourceClient/XWalkResourceClientInternal

 Related feature:

 Change Dialog of onReceivedLoadError to Toast

 JIRA: https://crosswalk-project.org/jira/browse/XWALK-4804

 Related Bugs:

 https://crosswalk-project.org/jira/browse/XWALK-4788,
 https://crosswalk-project.org/jira/browse/XWALK-4514

This sounds like a good idea to me.

 Target release:

 Crosswalk-15

However, I'd like to push this to Crosswalk 16: Crosswalk 15 is already
in beta and under stabilization, and in principle this does not seem to
be fixing a severe bug to the point that it would make sense to have
this in 15.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Crosswalk 15 is now beta, master is Crosswalk 16.

[Raphael Kubo da Costa]

Hi, everyone,

Due to all the summer vacations our release schedule slipped a bit, but
we are now getting back to normal.

Crosswalk 15 has finally been branched, and master has become Crosswalk
16. Consequently, this also means that we will only make new Crosswalk
14 releases on demand, and only to fix major bugs or security issues.

To people developing Crosswalk, please remember that Crosswalk 15 is now
in beta mode, so no new features are supposed to be landed there, only
bug fixes (preferably only for major bugs).

Current status:
* Canary: Crosswalk 16, master branch.
* Beta: Crosswalk 15, crosswalk-15 branch.
* Stable: Crosswalk 14, crosswalk-14 branch.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Is there any documentation on the source tree structure of crosswalk.git?

[Raphael Kubo da Costa]

Hu, Jiajie jiajie...@intel.com writes:

 The source tree of crosswalk.git seems to be a little scattered and
 confusing for new comers.

 E.g. there are several directories named tools/ or build/ in the
 source tree, what’s the difference among them? And what’s the
 difference between application/ and runtime/?

 So is there any documentation which gives an introduction on the
 source tree structure of crosswalk.git?

Unfortunately not, I'm afraid. We could make an effort to reduce the
number of directories with similar names, but other than that I don't
think there's any document describing how each part interacts with
another.

If you have specific questions though, we can try to answer them here.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Problems of build and execution Crosswalk binary on Windows

[Raphael Kubo da Costa]

홍준표 jphof...@infrawareglobal.com writes:

 Hi, I’m a new in Crosswalk framework, and I try to build and test it on 
 Windows.

 When I check build instructions on this link,
 https://crosswalk-project.org/contribute/building_crosswalk.html,
 building on Windows is enabled on Crosswalk source tree, and also
 execution it.
 Fetching source code and build is fine, but whenever trying execute
 it, it(xwalk.exe) is closed before display its main window without any
 crash.

Hi,

If you just call xwalk.exe without any parameters, you're probably
going to see some debugging messages on the console and a window quickly
opening and closing.

In this regard, the Windows version is quite similar to the desktop
Linux one, so the Running a Crosswalk application part of the Linux
documentation also works for Windows:
https://crosswalk-project.org/documentation/linux.html

Can you check if things work when you pass an argument to xwalk.exe?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Regarding Building Crosswalk for Ubuntu and Windows

[Raphael Kubo da Costa]

Nitish Sakhawalkar nits...@gmail.com writes:

 Hello,

 I tried to build crosswalk for Ubuntu and Windows. However, I am having
 multiple issues.

 On Ubuntu, I am getting the chrome-sandbox error, when I try to execute the
 built executable. On windows, when I try to execute the final xwalk.exe
 file it does not work. It also does not give any error.
 I am aware that these platforms are not directly supported. But I would be
 glad if someone can kindly provide some documentation or help as to how I
 can use use crosswalk for all the platforms.

In addition to what's been said so far: we are currently working on
improving the support for both desktop Linux and Windows. As you have
already noticed, both already work, but there are some rough edges.

Now specifically about these:

 Besides, how can I debug the javascript on this app using the chrome
 debugging tools?

For now, you can just pass --remote-debugging-port=port number to
the xwalk binary, and then you can connect to localhost:port number in
Chrome, for example.

 Once last thing, how do I issue bridge commands to this app?

What do you mean by bridging commands?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [Crosswalk-help] Missing module when running the following command: python xwalk/gyp_xwalk.py

[Raphael Kubo da Costa]

Shahar Gluzman shahar.gluz...@williamhill.com writes:

 I want to update the XWalkViewInternal which is stored in
 xwalk_core_library_java_library_part.jar and also XWalkView which is
 stored in xwalk_core_library_java_app_part.jar.
 Those jar files don't exist in the out/Release folder but same names
 with Ninja type exist (out/Release/obj/xwalk)
 How do you suggest to continue?

Which target did you build with ninja? Assuming you've properly set up
the build for Android (which seems to be the case according to your
previous messages), then the `xwalk_core_library` target should build
everything you need.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [Crosswalk-help] Missing module when running the folliwng command: python xwalk/gyp_xwalk.py

[Raphael Kubo da Costa]

Shahar Gluzman shahar.gluz...@williamhill.com writes:

 Hi,

 Thanks you again for your help before :)

 After installing Ubuntu 64 , I succeed to download , compile and build.

 The current problem , where can I find the
 xwalk_core_library_java_app_part.jar and
 xwalk_core_library_java_library_part.jar in the existing out/Release
 folder?

% cd out/Release
% find . -name xwalk_core_library_java_app_part.jar
./lib.java/xwalk_core_library_java_app_part.jar
% find . -name xwalk_core_library_java_library_part.jar
./lib.java/xwalk_core_library_java_library_part.jar

Are you sure you are really after those two files in order to achieve
whatever you intend to achieve?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [Crosswalk-help] Missing module when running the folliwng command: python xwalk/gyp_xwalk.py

[Raphael Kubo da Costa]

Shahar Gluzman shahar.gluz...@williamhill.com writes:

 The reason I downloaded to my mac is because I am using Ubuntu 14 as a
 guest machine and when I tried to fetch the code via the virtual
 machine its stops after 6 hours with an error.

What kind of error? If it's a network error, you can continue from where
it stopped; if it's a different error, then you likely need to fix
something.

 4. Install build dependencies : ~
 /crosswalk-src/src/build/install-build-deps-android.sh
 Here I got that no need to upgrade but with one error (The following
 directory is exist: java-1.7.0-openjdk-i386)
 openjdk-7-jdk is already the newest version.
 openjdk-7-jre is already the newest version.
 0 upgraded, 0 newly installed, 0 to remove and 351 not upgraded.
 ERRORS: Failed to update alternatives for java-6-sun:
 update-java-alternatives: directory does not exist:
 /usr/lib/jvm/java-1.7.0-openjdk-amd64
 crosswalk-src$

Most likely because you've installed a 32-bits version of Ubuntu and the
script is assuming you have a 64-bits installation (see how you
mentioned openjdk-i386 and the update-java-alternatives error mentions
openjdk-amd64). I suggest going for a 64-bits distro to avoid additional
headaches.

 When I wrote the following command: which java , I got /usr/bin/java

Which is a symlink to /etc/alternatives/java...
`ls -l /etc/alternatives/java` is more informative in this case.

 5. Install Google Play Services:
 src/third_party/android_tools/sdk/tools/android update sdk --no-ui -
 -filter 57
 I got the following warning:
 Warning: The package filter removed all packages. There is nothing to
 install.
 Please consider trying to update again without a package filter.

 I believe that it is OK because no error were there

Note that if you are just building Crosswalk there's no need to run
this at all. It is only necessary for Chromium itself.

 6. Prepare the environment: src$ . build/android/envsetup.sh

This shouldn't be required.

 9. Building Crosswalk for Android : sudo .
 /build/install-build-deps-android.sh
 I got the same error as Step 4.

Why do that again?

 10. Next to the .gclient file, Configure GYP : ~/crosswalk-src$ echo 
 { 'GYP_DEFINES': 'OS=android target_arch=ia32', }  chromium.gyp_env
 (This command override the previous step 2)

Then this should be step 2...

 Updating projects from gyp files...
 gyp: Error importing pymod_do_mainmodule (grit_info): No module named
 grit_info while trying to load
 /media/sf_sf_Shared/crosswalk-src/src/xwalk/xwalk.gyp
 shahar@shahar-VirtualBox:/media/sf_sf_Shared/crosswalk-src/src$

It is still hard to say. It really looks like something went wrong with
your `gclient sync' call and not everything was checked out. I don't
think it is even supposed to work on the Mac, since after checking out
all repositories it is also going to run gyp automatically on OS X and
fail because Android builds are not supposed to work there.

My suggestion is to figure out what is failing when you try to do
everything on Linux itself, or at the very least see if your gclient
sync call on OS X is really checking everything out.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Crosswalk master is now tracking Chromium 44

[Raphael Kubo da Costa]

Hi everyone,

Thanks to the efforts of several people, we have finally moved Crosswalk
15 (master) to Chromium 44.0.2403.30, the latest beta Linux release. It
will appear in our next canary.

Things to note for now:
- SIMD.js support is still not working and will be re-enabled in the
  next few days.
- Support for ICS (Android 4.0.x) devices has been temporarily removed
  because Chromium itself has done the same. We are evaluating our
  options and might reintroduce support for ICS soon (definitely before
  branching Crosswalk 15 to beta).

As usual, things get a bit rough in the first days after we move to a
new Chromium milestone. Please make sure you report any bugs you
encounter so we can get everything back on track as soon as possible.

Happy hacking.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Error building 14.43.343.10

[Raphael Kubo da Costa]

Luis Tiago Eterovick lu...@syst.com.br writes:

 I've just upgraded from 10.39.235.17 to 14.43.343.10 and I'm getting these
 errors:

 http://s12.postimg.org/o6mzd15p7/Screen_Shot_2015_06_03_at_4_18_40_PM.png

 Tried using compileSdkVersion 21 instead of 18 but it didn't solve the
 problem. What should i do?

This was fixed here:
https://github.com/crosswalk-project/crosswalk/pull/3074 (and #3078 for
crosswalk-14), so things should be back to normal in our next canaries
and betas.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Missing module when running the folliwng command: python xwalk/gyp_xwalk.py

[Raphael Kubo da Costa]

Shahar Gluzman shahar.gluz...@williamhill.com writes:
 I downloaded the code to my MAC (~21GB) and tried to build it thru
 Ubuntu 14.

 I am getting the following error when I run the following command :

 $ python xwalk/gyp_xwalk.py

 gyp: Error importing pymod_do_mainmodule (grit_info): No module named
 grit_info

 What I am doing wrong?

Can you expand on what you mean by downloaded the code to my mac and
tried to build it thru Ubuntu 14? Which steps did you follow exactly,
and why not fetch the code from Linux directly?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Planned downtime in build/trybots and JIRA integration today

[Raphael Kubo da Costa]

Hi everyone,

We are going to perform some planned maintenance on the machines hosting
the Buildbot masters for build.crosswalk-project.org and
build.crosswalk-project.org/try, the GitHub Trybot integration and the
GitHub-JIRA integration.

The maintenance is scheduled to start at 9:00 Pacific time (so 16:00
GMT) and is supposed to last around 30 minutes, during which the
services I mentioned above will not be available.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Requiring Node.js 12 for Crosswalk-app-tools

[Raphael Kubo da Costa]

Staudinger, Robert robert.staudin...@intel.com writes:

 Have to put this on hold anyway because of meeting this bug (broken debugger)
 https://github.com/node-inspector/node-inspector/issues/631

 On 20 May 2015 at 10:05, Raphael Kubo da Costa
 raphael.kubo.da.co...@intel.com wrote:

 Which version do we currently require?

 0.10

Do you know which distros ship node = 12.x?

 Haven't checked, which ones are important apart from Fedora and Ubuntu?

Fedora has a more aggressive schedule anyway. Chromium itself normally
only worries about Ubuntu, and I think if it's present in 14.04 (the
latest LTS) there's a good chance most developers are using it even in
other distros. I'm not sure about Windows and Mac though.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Requiring Node.js 12 for Crosswalk-app-tools

[Raphael Kubo da Costa]

Staudinger, Robert robert.staudin...@intel.com writes:

 Hello,

 any objections to requiring Node.js 12.x for Crosswalk-app-tools?
 There is some new API for spawning subprocesses that I would like to
 use.

 Opinions?

Which version do we currently require? Do you know which distros ship
node = 12.x?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Downtime in the canary/beta builds

[Raphael Kubo da Costa]

Raphael Kubo da Costa raphael.kubo.da.co...@intel.com writes:

 Hi everyone,

 We're experiencing some technical problems with the canary/beta builds,
 so it is very likely that there will be no new builds until Monday.

 I will send another message when things get back to normal.

Everything seems to be back, and betas/canaries should be built as
expected today.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Downtime in the canary/beta builds

[Raphael Kubo da Costa]

Hi everyone,

We're experiencing some technical problems with the canary/beta builds,
so it is very likely that there will be no new builds until Monday.

I will send another message when things get back to normal.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Please merge pull request for XWALK-3569

[Raphael Kubo da Costa]

Close, Rob rob.cl...@sap.com writes:

 Description of the feature: 
 https://crosswalk-project.org/jira/browse/XWALK-3569
 Pull request: https://github.com/crosswalk-project/crosswalk/pull/3020

 Please merge this change.  It solves a problem for us.

Apologies for the delay here. I'm still trying to get our Android folks
to look at your intent to implement.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] Crosswalk master is now 15, crosswalk-14 is the new beta channel

[Raphael Kubo da Costa]

Hi everyone,

Crosswalk 14 has just been branched off 14.43.343.0 (not .342 as
previously announced, since we wanted to include the commit moving
Crosswalk to the most recent M43 release in the beta branch).

This means that Crosswalk's master branch is now Crosswalk 15, Crosswalk
14 is the new beta branch and new Crosswalk 13 release will only be made
on demand.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: JIRA integration is now enabled for all projects

[Raphael Kubo da Costa]

Hi everyone,

Yesterday I landed some behind-the-scene changes that decouple the
Trybot integration we have for GitHub patches from the code that
comments on and closes JIRA tickets based on the pull request message.

This was asked for a long time ago, and it basically means that JIRA
integration now works and has been enabled in all projects belonging to
the crosswalk-project organisation on GitHub.

Happy hacking.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] The Tizen Common build slaves are more reliable now

[Raphael Kubo da Costa]

Those of you who have been sending pull requests lately may have noticed
how unstable the Tizen Common were: they would occasionally run out of
disk space and report a build failure to the pull requests.

We've now increased the disk space in these Tizen slaves, so they should
behave much better now.

If you still face weird build problems in them that look like
infrastructure issues, please file a bug report in JIRA and assign it to
me.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to Implement: GN Integration

[Raphael Kubo da Costa]

Dong, Jun jun.d...@intel.com writes:

 Description:

 GN Integration will replace all gyp configuration files in xwalk repo
 into gn files,

 Since chromium will completed this transition at the end of Q2.(see
 https://code.google.com/p/chromium/wiki/gn for more details)

 Besides that, gn will bring more maintainable code and more powerful
 debugging function.

 Affected component: all

 Related feature: XWALK-3674

 Target release: crosswalk-14

 Implementation details:

 Will translate all gyp files into gn files, together with some
 refactor work if needed.

It's probably too early to consider replacing our gyp files, but having
GN in place in parallel is a good idea, as we'll have to do that sooner
or later.

Does GN have a dump_dependency_json generator like gyp's? We need that
for Tizen to be able to split Crosswalk into two packages there.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Building Crosswalk Help

[Raphael Kubo da Costa]

CC'ing the list again.

Kelvin Ishigo kelvin.ish...@gmail.com writes:

 I'll check but I thought I did:
  echo { 'GYP_DEFINES': 'OS=android target_arch=arm', }  chromium.gyp_env

Right. How about the other questions I asked?

 Hmm, are you able to build any of the other *_apk targets? Does the
 `xwalk_builder' target produce a bunch of APKs?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Building Crosswalk Help

[Raphael Kubo da Costa]

Kelvin Ishigo kelvin.ish...@gmail.com writes:

 A quick google at the ubuntu uname -m seems to indicate that for a 64 bit
 12.04 precise pangolin build, i686 is expected.

 On Fri, Feb 20, 2015 at 8:29 AM, Kelvin Ishigo kelvin.ish...@gmail.com
 wrote:

 I am trying to build crosswalk for android which I am guessing is a 32 bit
 version of crosswalk.
 I am building on a 64 bit host linux PC, ubuntu 12.04.

 Should this work?

From what you say, it sounds like you have a 64-bits processor but
installed a 32-bits distro in it -- that's the only way I'd expect
`uname -m' to report i686 instead of x86_64. Is that the case?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Building Crosswalk Help

[Raphael Kubo da Costa]

Kelvin Ishigo kelvin.ish...@gmail.com writes:

 Hi,
 Yes, it is an android build.
 The XWALK_OS_ANDROID=1 was done.  I have an third_party/android_tools
 directory and the 64 bit *gcc stuff is there.  However, I do not have a
 linux-i686 tree.

I see. What value are you passing in the target_arch gyp parameter?
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Crosswalk master has been rebased to M41

[Raphael Kubo da Costa]

Fellow pedestrians,

I've finally merged pull request #2838, so Crosswalk's master branch is
now based on Chromium 41.0.2272.16, the first M41 release promoted to
the Linux beta channel (the current version in the channel is a bit more
recent, but moving to that one should be easy).

The commit message (duplicated in the pull request message) details all
the big changes that had to be done, including disabling Vibration
support on Tizen, the shipping of separate V8 snapshot files and changes
in the code to conform to the changes in the notifications API in the
content layer.

Happy hacking!
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Intent to implement: Web Notification for Crosswalk Tizen and Linux

[Raphael Kubo da Costa]

Wang, Peter H peter.h.w...@intel.com writes:

 (2) As embedder, we only need to implement some interfaces:
content::ContentBrowserClient::RequestDesktopNotificationPermission()
content::ContentBrowserClient::ShowDesktopNotification()
content::ContentBrowserClient::CancelDesktopNotification()
 (3) For Linux, we can leverage the existent code inside of ui.
 Basically, we only need to create a
 ui::message_center::NotificationView and invoke some interfaces of
 ui::message_center::DesktopPopupAlighnmentDelegate to show it on the
 corner of desktop as Chrome and Firefox do.
   All the class mentioned above, by my investigation, have taken X11
 desktop into consideration already.

By the way, I suggest moving whatever code you may already have to
Chromium M41: the notifications code underwent several changes I had to
take into account in the M41 rebase. For example, those methods in
ContentBrowserClient have all been replaced by a separate
PlatformNotificationService object.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [Intent to implement] Crosswalk uses Dual process model on Tizen

[Raphael Kubo da Costa]

Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com writes:

 Hi,

 Let me highlight that after
 https://github.com/crosswalk-project/crosswalk/pull/2717/ got landed,
 the 'xwalkctl' and 'xwalk-launcher' utils are not build anymore and
 hence are not present within the xwalk package.
 The standard platform utils should be used instead (pls. see
 https://wiki.tizen.org/wiki/Application_framework#Application_Management).

I'd like to return to this topic. How are you guys currently testing
Crosswalk? The Common image doesn't seem to come with any webapp
installed, so I had to manually look for an install a wgt (hangonman),
then it became full screen and I couldn't even close it.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [Intent to implement] Crosswalk uses Dual process model on Tizen

[Raphael Kubo da Costa]

Raphael Kubo da Costa raphael.kubo.da.co...@intel.com writes:

 Pozdnyakov, Mikhail mikhail.pozdnya...@intel.com writes:

 Hi,

 Let me highlight that after
 https://github.com/crosswalk-project/crosswalk/pull/2717/ got landed,
 the 'xwalkctl' and 'xwalk-launcher' utils are not build anymore and
 hence are not present within the xwalk package.
 The standard platform utils should be used instead (pls. see
 https://wiki.tizen.org/wiki/Application_framework#Application_Management).

 I'd like to return to this topic. How are you guys currently testing
 Crosswalk? The Common image doesn't seem to come with any webapp
 installed, so I had to manually look for an install a wgt (hangonman),
 then it became full screen and I couldn't even close it.

Hmm, apparently the different users in Common have different webapps,
and user `carol' has none. So I have to be lucky enough to drag a
launcher that is outside the screen into it that belongs to the right
user...
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] PSA: Connectivity issues with our Tizen bots

[Raphael Kubo da Costa]

Raphael Kubo da Costa raphael.kubo.da.co...@intel.com writes:

 Hi everyone,

 Some of you might have noticed that our tizen-extensions-crosswalk and
 Tizen bots (trybots, buildbots and canary builders) were not working
 since last Saturday (1st Nov).

 This was caused by a security update in the tizen.org servers that ended
 up disabling all SSL ciphers used by Ubuntu 12.04's OpenSSL package,
 hence the error we were getting:

   SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

 For now, I have switched all bots to our internal mirrors again to work
 around the problem, but this in turn brings back the risk of us using
 Tizen repositories that are outdated compared to the versions in
 download.tizen.org. In this situation, it's a lesser evil than not being
 able to build Crosswalk on Tizen at all.

 If you have access to tizendev.org, please follow INF-873 for updates on
 this.

 Last but not least: as I said, this problem started affecting us last
 Saturday. However, no canary was generated last Friday either, but this
 is due to a different problem caused by commit 4026425 ([Android] Use
 upstream blink revision for DevTools frontend URL) and how our canary
 build scripts were set up. I am currently working on fixing this, and we
 should start having canaries again by tomorrow the latest.

Things seem to have settled down, so I have switched all our Tizen bots
to download.tizen.org again.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] PSA: Changes to Crosswalk Tizen packaging

[Raphael Kubo da Costa]

Raphael Kubo da Costa raphael.kubo.da.co...@intel.com writes:

 First, the TL;DR version:
 * Optionally clean your local GBS repository and existing Crosswalk
   packages (in $GBSROOT/local/repos/$profile_name/$arch/RPMS) to free up
   some space.
 * Build the crosswalk-libs RPM package:
   cd src/xwalk
   gbs build --spec crosswalk-libs.spec
 * Build the crosswalk-bin RPM package afterwards:
   cd src/xwalk
   gbs build --spec crosswalk-bin.spec

 [...]

 To most Crosswalk developers working on Tizen, the biggest change is
 that they will need to build crosswalk-libs once (or, if they are just
 hacking src/xwalk, download a version from download.tizen.org once they
 start building those new packages) and then only build crosswalk-bin.

Actually, upon closer inspection, not passing --spec also works; in this
case, both packages will be built.

Beware if you pass --define BUILDDIR_NAME /somewhere to gbs for
incremental builds though, as in this case both packages will be built
in the same permanent directory and the second time you call `gbs build'
libxwalk_backend.so will be packaged by crosswalk-libs.

So if you are using incremental builds, you *must* use different
directories for each package.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

[Crosswalk-dev] PSA: Changes to Crosswalk Tizen packaging

[Raphael Kubo da Costa]

Fellow pedestrians,

I've just merged pull request #2791, which significantly changes the way
Crosswalk is packaged on Tizen.

First, the TL;DR version:
* Optionally clean your local GBS repository and existing Crosswalk
  packages (in $GBSROOT/local/repos/$profile_name/$arch/RPMS) to free up
  some space.
* Build the crosswalk-libs RPM package:
  cd src/xwalk
  gbs build --spec crosswalk-libs.spec
* Build the crosswalk-bin RPM package afterwards:
  cd src/xwalk
  gbs build --spec crosswalk-bin.spec

Now a more detailed explanation.

There has been a longstanding meme in the Tizen world that it takes
forever to build a Crosswalk RPM, and this was causing problems in
tizen.org, since a change to any package Crosswalk depends upon would
trigger a full Crosswalk rebuild from scratch that could potentially
take hours to complete.

To address this, the Crosswalk RPM package has been split into two
separate RPMS:
1. crosswalk-libs contains all Chromium libraries we use (libbase.so,
   libcontent.so, so on and so forth). This package has no dependency on
   any Tizen-specific library such as aul or pkgmgr. Building it
   involves building basically everything in src/ except for src/xwalk/.
   I believe there's room to remove several other dependencies from the
   package, but we can do that over time.
2. crosswalk-bin contains the actual `xwalk' binary and depends on
   crosswalk-libs. It depends on several Tizen-specific packages and
   libraries, but building it does not involve building most of the code
   in Chromium (for example, it does not require building Blink or the
   content layer, as they are both part of crosswalk-libs) and takes a
   few minutes at most.

To most Crosswalk developers working on Tizen, the biggest change is
that they will need to build crosswalk-libs once (or, if they are just
hacking src/xwalk, download a version from download.tizen.org once they
start building those new packages) and then only build crosswalk-bin.

To people more involved with Tizen than with Crosswalk: so far nothing
has changed, since the Crosswalk packages in tizen.org are several
canaries behind what we have in master. Once that changes, the crosswalk
and crosswalk-thirdparty RPM packages will disappear and crosswalk-bin
and crosswalk-libs will be produced instead.

To the people working on rebases and release engineering, there's the
problem of maintaining
packaging/crosswalk-do-not-build-several-chromium-dependencies.patch,
which is a very ugly hack necessary for skipping the build of those big
Chromium targets in crosswalk-bin. So far, porting the patch from M39 to
M40 was not very painful, but we will see what it turns out to be with
M41.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Crosswalk 11 has branched

[Raphael Kubo da Costa]

Balestrieri, Francesco francesco.balestri...@intel.com writes:

 Hello,

 Crosswalk 11 has branched, the first Beta builds will be available
 soon. Note that despite the delay in the branch creation, the next
 branch point is still January 23rd as per the original release
 schedule:
 https://github.com/crosswalk-project/crosswalk-website/wiki/Release-dates

To reiterate: this means that Crosswalk master is now 12, 11 is our beta
branch and Crosswalk 10 builds will only be created on demand now.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] [Dev] Fwd: GENIVI Browser framework: questions about xwalk suitability

[Raphael Kubo da Costa]

Patrick Ohly patrick.o...@intel.com writes:

 On Thu, 2014-11-06 at 17:21 +0100, Alejandro Piñeiro wrote:
 So, if we wanted to reimplement the current POC using the same/similar
 architecture, the options I see would be:

a) Implement a WebView on xwalk to be used on Tizen (so xwalk would
 provide a WebView on both Android and Tizen): this seems a really big
 amount of work, and mean that xwalk would somehow replicate CEF on Tizen.

 What is CEF?

CEF is Chromium Embedded Framework: https://code.google.com/p/chromiumembedded/
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] Is this error can prevent me for building a new XWALK Library?

[Raphael Kubo da Costa]

Shahar Gluzman shahar.gluz...@williamhill.com writes:

 Error: Command svn checkout
 https://cvs.khronos.org/svn/repos/registry/trunk/public/cl/api/1.2@28150
 /Users/shahar/crosswalk-src/src/third_party/khronos/CL --revision
 28150 --non-interactive --force --ignore-externals returned non-zero
 exit status 1 in /Users/shahar/crosswalk-src

You need to make SVN aware of your proxies too.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] PSA: Connectivity issues with our Tizen bots

[Raphael Kubo da Costa]

Raphael Kubo da Costa raphael.kubo.da.co...@intel.com writes:

 I am currently working on fixing this, and we should start having
 canaries again by tomorrow the latest.

If all goes according to the plan, 11.39.236.0 should be out in a couple
of hours.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Re: [Crosswalk-dev] could you help me to fix build tizen extension crosswalk error

[Raphael Kubo da Costa]

Xiangguo Qi xiangguo...@samsung.com writes:

 [ 8s] ninja: error: '../../speech/org.tizen.srs.xml', needed by '
 gen/speech/tizen_srs_gen.c', missing and no known rule to make it
 [ 8s] error: Bad exit status from /var/tmp/rpm-tmp.G3RCLM (%build)

Is your tizen-extensions-checkout OK (ie. does it contain all the files,
including speech/org.tizen.srs.xml? I've just tried building the package
with the GBS repository you used and everything worked just fine.
___
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev