mkefidsk currently writes a startup.nsh with embedded control characters.
This happens because \b etc are control sequences to the shell echo
command when using dash. The resulting startup.nsh causes the bootup
to fail, and the user is dropped into the EFI shell to manually run
startup.nsh.
Patch originally provided by Troy D. Hanson <troy.hanson@jhuapl.edu>
[YOCTO #9665]
(From OE-Core rev: 359722a86580128aeccd05531eff0da4e6971721)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 008d6cb5bb4969f53a228893c502be8c9420ecb0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The secondary EFI partition is used when booting in EFI mode, and
without the configuration data we don't get any boot targets.
Partial fix to [YOCTO #11503].
(From OE-Core master rev: 84aa7a00810e135fdad3f77bdb1da7d1f5fb8627)
(From OE-Core rev: 915b01258ef426392bb9052c345f952670db4450)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* since this commit:
commit f5a1013ffa9815f22e13989e2bcb83f966e7ce2c
Author: Ross Burton <ross.burton@intel.com>
Date: Tue Apr 18 16:19:12 2017 +0100
package_manager: don't race on a file when installing complementary
packages
the file isn't closed before oe-pkgdata-util uses it and this
temporary file might look empty to oe-pkgdata-util, because it
wasn't flushed yet. Which resulted in almost empty debugfs tarballs
and no locale packages in regular rootfs.
* without this change:
124K May 30 07:41 core-image-full-cmdline-raspberrypi3-64-20170530054003-dbg.rootfs.tar.gz
* with this change:
173M May 30 07:29 core-image-full-cmdline-raspberrypi3-64-20170530052715-dbg.rootfs.tar.gz
(From OE-Core rev: 9b34200048b3d2b477a19b7ddc8d447f873adbb2)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 877d38db08aa7060d16405443cf70539c559fe82)
Signed-off-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If building for nativesdk the wrong rss sysroot is used leading the
following error message.
| ERROR: oe_runmake failed
| In file included from tools/imximage.c:13:0:
| include/image.h:1024:27: fatal error: openssl/evp.h: No such file or directory
| # include <openssl/evp.h>
Tools needed on the build host (script/basic/fixdep) and code compiled
for the SDK machine are both built with the build host's compiler,
leading to additinal errors.
Adding CROSS_COMPILE="${HOST_PREFIX}" and using the cross-compiler for
the SDK_ARCH fixes the build error.
The resulting binary in the SDK is working.
(From OE-Core rev: aab5311f3ad9fb9f9e26b18b5fe5e54d8ec14798)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This clearly wasn't tested as the correct variable is ASSUME_PROVIDED.
This reverts commit 91cee06433.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in these two functions is meant to be equivlanet in behaviour
but isn't. Add in code to ensure files that don't exist are handled
consistently by both functions. Users did report being able to generate
tracebacks otherwise.
(Bitbake rev: 1b66c57d0f8a9bd9f9feb2a85759e18d9a1d674b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure that when an item fetched from a premirror has an invalid checksum the
fetcher falls back to the usual logic of trying the upstream and any configured
mirrors.
(Bitbake rev: cc52b9b12c60810142252b9cb5d4268e42371b8e)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I discovered a mis-placed block of DocBook text that was
causing the string "bug-id" to appear in a random spot in the
"Patch Submission Details" section. Re-ording this block
fixed the problem.
(From yocto-docs rev: 92616f73ce31505e11f3193b1350acc875003649)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For development purposes, static libraries need to be
present only in the SDK. We do not need those static
libraries in the image for most scenarios. So, replace
IMAGE_INSTALL with TOOLCHAIN_TARGET_TASK in the documentation.
I updated the note to reflect this.
Suggested-by: Maxin B. John <maxin.john@intel.com>
(From yocto-docs rev: fd17ac96a44d08f7f2798e69cd923e0726a0754a)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11579]
I made some corrections by taking out the fact that BitBake
issues a warning or error if any version mismatches are found.
(From yocto-docs rev: e037858b95a97699c110be3b091db06633c9c44a)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
poky.ent - updated variables for 2.3.1
mega-manual.sed - exchanged "2.3.1" for "2.3" for links
<manual>.xml - updated manual revision tables to use
"June 2017" as the release date for 2.3.1
(From yocto-docs rev: 01d60d08a0c7371b8f7476f45fca89226caec680)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11600]
Removed the example. It was not needed.
(From yocto-docs rev: e3610147535c259c49c3dc08289c037ba49c48a1)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11411]
Added a naming convention warning to the native.bbclass description
that is similar to the existing warning used in the description for
the nativesdk.bbclass.
(From yocto-docs rev: ece69399decb54045c974e9e537286eb820fde61)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11600]
"configure" and "cmake" are not do_* tasks of BitBake. I updated
the formatting of these programs and removed links that were to
the tasks in the reference manual.
(From yocto-docs rev: a53d766976ec77a2706014d114bef698d3b6f710)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The figure that Scott Garman used for an old video cast is
much more appealing to the eye than the giant, square beast
the current manual was using. I have replaced the image.
The image is technically the same.
Because the mega-manual has to use a duplicate figure, I
put the new PNG files in the Figures directory for both the
yocto-project-qs and mega-manual books.
(From yocto-docs rev: 10985cadfecea0096412df049b3457bc0297c4bf)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The YP doc set was using a link to an out-dated video that
showed how to configure and run Eclipse. The video was very
old and Jessica suggested just removing it. So, I replaced
all occurrences of the link to the up-to-date appendix in the
SDK manual that provides information on the latest supported
version of the Eclipse IDE.
(From yocto-docs rev: a414addb427337dc76a05cf3f56bf8aeec1a7c1b)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The link to the section on how to set up Eclipse had been broken
for a while. I fixed the link so that it goes to the appropriate
section (appendix) in the SDK manual.
(From yocto-docs rev: ab2af9c0b237285c6989832db306a42957a6187d)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11579]
Added a new description for the LAYERRECOMMENDS variable.
(From yocto-docs rev: 207c69e218507b384dbd017367dfe392fd45296e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11579]
The syntax for specifying a layer version was incorrect. I
have added an explanation for the correct syntax and provided
an example.
(From yocto-docs rev: 83c97473defbbac35ebca81f4ef69289f3dd8789)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #9001]
Updated the image-live class description to specifically mention
creating *.iso and *.hddimg images as "live" images. Provided more
explanation about usage through the NOISO and NOHDD variables.
Also, provided a cross-referencing link back to the updated
image-live class from the EFI_PROVIDERS variable.
(From yocto-docs rev: 10c81adc26bd0a7a8952eb362f958f92566d42db)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #11498]
I enhanced the description of the INHERIT variable's glossary
description to provide more detail. I also included a link into the
section of the BB manual where INHERIT is described.
(From yocto-docs rev: ed44df6342ee20720aeee2dd8eae944db767023e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is the potential for sensitive information to leak through the urls
there and removing it brings this into the behavior of the other package
backends since filtering it is likely error prone.
Since ipks don't appear to be generated at all if we don't set this, set
the field to the recipe name used (basename only, no paths). This avoids
information leaking. We may want to drop the field if opkg can allow that
at a future point but the recipe name is a suitable identifier for now.
Reported-by: Andrej Valek <andrej.valek@siemens.com>
(From OE-Core rev: 0b5e0d072f93a958e4211a8aeb2fd8cc3c25cc21)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A change occured about a year ago that broke the native build, fix
that patch
[YOCTO #11590]
(From OE-Core rev: ccd8e2cf7157c941ebacc6be306c1dbe2ec31e86)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport 13f00eb4493c "automake: port to Perl 5.22 and later"
from automake upstream to fix build with perl 5.22 .
(From OE-Core rev: ab0e298ec2c155739565f1cde76639855ba7bba0)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If ASSUME_PROVIDES contains libsdl-native, we need to add sdl-config
to HOSTTOOLS to allow access to the host sdl-config.
(From OE-Core rev: ed5a602d3eb418beb2f9731fda96415ed16efff2)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Backported from master.]
Some EGL implementations do not actually ship all Khronos-
extensions. As it turns out, the Mali 450 driver does not
include any of the following symbols, used by the
egl_mesa_platform_surfaceless.c spec test:
* eglGetPlatformDisplay
* eglCreatePlatformPixmapSurface
* eglCreatePlatformWindowSurface
The Right Thing To Do was to obtain the implementation of
these functions (via eglGetProcAddress), as is provided
by their EXT counterparts. These are guaranteed to exist
since they are required by EGL_EXT_platform_base.
(From OE-Core rev: 903a051d47e550553aa9d6d9c38c43737f376cfe)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Backported from master.]
[Piglit Bug #100978] -- https://bugs.freedesktop.org/show_bug.cgi?id=100978
When linking against Mali 450 r6, errors like the following
can be seen:
../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_unmap'
../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_map'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/point-sprite] Error 1
This is due to gbm_bo_map() and gbm_bo_unmap() being recently
added but not yet implemented by all graphics drivers.
Instead of relying on GBM's version, actually try to link
against those symbols.
(From OE-Core rev: 484db109df742aafa8efc41dc3a8d31386d9b2a3)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Backported from master.]
While building for Hikey using Mali 450 driver (r6p0), an
error like the following appears while linking:
[ 1%] Linking C shared library ../../../../lib/libpiglitutil.so
[...]
[...]/aarch64-linaro-linux/gcc/aarch64-linaro-linux/6.3.1/ld: cannot find -lEGL
collect2: error: ld returned 1 exit status
make[2]: *** [lib/libpiglitutil.so.0] Error 1
Mesa generally provides virtual/egl (along with virtual/libgl,
which satisfies Piglit's current DEPENDS) but that is not the
implementation to use with Mali.
(From OE-Core rev: 5bfa4ccdba64d814cc480f22ccd8c493d87d36e7)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These commands are not whitelisted by the HOSTTOOLS variable which
silently prevents the MBR disk signature from being written to the
image.
Reported-by: Michael Davis <michael.davis@essvote.com>
(From OE-Core rev: 5527af688f6ccaacd7ec24d29425d0c007d5341c)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By exporting KBUILD_BUILD_USER with a pre-defined value we improve the
reproducibility of the kernel and remove the requirement for whoami in the
HOSTTOOLS.
KBUILD_BUILD_HOST also helps improve the reproducibility of the kernel.
For more kernel reproducibility options see:
https://lwn.net/Articles/437864/
(From OE-Core rev: 357801a491efc067c6d4bd9a2bfa6fff460357aa)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The .sethalftone5 function in psi/zht2.c in Ghostscript before 9.21 allows remote
attackers to cause a denial of service (application crash) or possibly execute
arbitrary code via a crafted Postscript document that calls .sethalftone5 with an
empty operand stack.
Artifex jbig2dec 0.13, as used in Ghostscript, allows out-of-bounds writes because
of an integer overflow in the jbig2_build_huffman_table function in jbig2_huffman.c
during operations on a crafted JBIG2 file, leading to a denial of service (application
crash) or possibly execution of arbitrary code.
References:
https://nvd.nist.gov/vuln/detail/CVE-2016-8602https://nvd.nist.gov/vuln/detail/CVE-2017-7975
Upstream patches:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=f5c7555c303http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5e57e483298
(From OE-Core rev: 8f919c2df47ca93132f21160d919b6ee2207d9a6)
(From OE-Core rev: 6040b8735b79397bf49a2154f81e9aab34c15413)
Signed-off-by: Catalin Enache <catalin.enache@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This vulnerability is also called "rpcbomb".
Backport upstream patch to fix this vulnerability.
CVE: CVE-2017-8779
(From OE-Core rev: 7936c9451eb4c376a78a0ac7461d1b2430c7f1f3)
(From OE-Core rev: bab6667d44df185b4433bcd1c283105966383844)
Signed-off-by: Fan Xin<fan.xin@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When warning users about unpatched CVE, we'd better put CVE IDs into
the warning message, so that it would be more straight forward for the
user to know which CVEs are not patched.
So instead of:
WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE, for more information check /path/to/workdir/cve/cve.log.
We should have:
WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE (CVE-2017-7869), for more information check /path/to/workdir/cve/cve.log.
(From OE-Core rev: ad46069e7b58f2fba373131716f28407816fa1a6)
(From OE-Core rev: e0e1414a4574d4165a8dc5d0d9d0d5b5a660355f)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE checking in OE didn't work as do_populate_cve_db failed with the following
error message.
[snip]/downloads/CVE_CHECK/nvdcve-2.0-2002.xml is not consistent
Backport a patch to fix this error.
(From OE-Core rev: ee55b5685aaa4be92d6d51f8641a559d4e34ce64)
(From OE-Core rev: e0f0a7283c597e783b69aac2c8e8a7663b70262d)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test_recipetool_create_github test fetches HEAD of the repository so
upstream changes can (and do) break the test. Avoid these problems by passing
the rev= argument in the URL to lock the checkout to the same version that is
fetched in the github_tarball test.
Also pass the commands to runCmd() as a list instead of a string, the semicolon
in the URL needs more quotes if the shell is involved and passing a list
bypasses the shell entirely.
(From OE-Core rev: 5f02b4300fb2ed54270aede54d30317ba757f587)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since recipe-specific sysroots were implemented, devtool add and devtool
upgrade operations that fetch from a URL that requires native sysroot
dependencies will fail to work as there is no recipe-specific sysroot
set up for them during fetching. An example was any URL pointing to a
tarball compressed with xz, e.g. devtool upgrade on gnutls.
The most expedient way to fix this is to set up a dummy recipe-specific
sysroot to use for the fetch/unpack operations. We do this in the same
manner as bitbake -b does, so we're just taking all of the sysroot
components available and creating a sysroot from those rather than
ensuring the correct dependencies are there - this means that we're
still going to have problems if e.g. xz-native hasn't been built yet,
but that issue will be trickier to solve and is tracked separately.
Fixes [YOCTO #11474].
(From OE-Core master rev: 559151e783759af78b5cdd76cdbb9ce325a391e6)
(From OE-Core rev: 9e7905c7bada1bafda661fc4a6177afeef0f5015)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Gna! project announced that the download site from gna.org HTTP server
will soon be closing down. We have verified that the site is no longer
accessible without network proxy cache. We need to update SRC_URI to
point to new alternative (nwl.cc HTTP server) in order to avoid fetcher
issues in future.
[YOCTO #11575]
(From OE-Core rev: 3195f7e68eb5cfb2af3506fe4b0dcb2f8cd9ee10)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A vulnerability was found in a way bash expands the $HOSTNAME.
Injecting the hostname with malicious code would cause it to run
each time bash expanded \h in the prompt string.
Porting patch from <https://ftp.gnu.org/gnu/bash/bash-4.3-patches/
bash43-047> to solve CVE-2016-0634
CVE: CVE-2016-0634
(From OE-Core rev: 7dd6aa1a4bf6e9fc8a1998cda6ac5397bb5cd5cb)
(From OE-Core rev: a4b37b05140b549960baef49237ce3316e84a041)
Signed-off-by: Zhixiong Chi <zhixiong.chi@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the limited dependency case we don't use any of the data from
BB_TASKDEPDATA. Restructure the code so this variable doesn't have
to be set. This allows the function to be called from other contexts
without creating artificial constructs. There should be no functional
change, behaviour remains unchanged.
(From OE-Core rev: 71e5243e3ebadb90b45fe418dac3eaa2c1b896bd)
(From OE-Core rev: e962e257f4c124869953d1fbb3da7dbf564f818a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous change to relocate HOSTTOOLS wasn't complete as some files,
particularly in gcc stashed build directories were not being correctly
relocated. This patch addresses the issue.
(From OE-Core rev: 21dd36cc12a033b012544c5d15a6f8afd84dabc9)
(From OE-Core rev: 64c2f8acd02e0e5dca234b36a2a7097c0c16f7c2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both native and target versions of this file reference mkdir and install
in hosttools paths. Use the version from PATH instead.
(From OE-Core rev: 080197bf3bdf612da8104c2ae7f0b2c8dea32a0b)
(From OE-Core rev: 8e3134953edfc88bf3d135b5dc00d361f84b5f37)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the file encodes full paths to various host tools in the
HOSTTOOLS directory which is bad in native and target cases. We can
simply use the versions from PATH quite safely in OE.
(From OE-Core rev: be901200d94beaa35e1d05eb502b117b3b523609)
(From OE-Core rev: 2a12c159aae9877a05e0ba023de278cdca59ac45)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Saul Wold
California Sullivan
Martin Jansa
Max Krummenacher
Richard Purdie
Joshua Lock
Changhyeok Bae
Scott Rifenbark
Marek Vasut
Jonathan Liu
Daniel Díaz
Yuanjie Huang
Fan Xin
Catalin Enache
Chen Qi
Ross Burton
Paul Eggleton
Chang Rebecca Swee Fun
Zhixiong Chi