Re: [OE-core] [PATCH V9] go: Add recipes for golang compilers and tools

On 2017-03-08 07:40, Khem Raj wrote: * This is converging the recipes for go from meta-virtualization and oe-meta-go * Add recipes for go 1.7 * go.bbclass is added to ease out writing recipes for go packages * go-examples: Add an example, helloworld written in go This should serve as tem

Re: [OE-core] [PATCH V7] go: Add recipes for golang compilers and tools

On Wed, Mar 8, 2017 at 11:03 PM, Kristian Amlie wrote: > On 08/03/17 23:19, Khem Raj wrote: >>> ... >>> For the following go-1.4 recipes: >>> >>> I wouldn't recommend fixing go-native at version 1.4, which is now >>> postiviely ancient. >>> Instead, add go1.4.3's SRC_URI into the go-native recipe,

[OE-core] [PATCH] wic/direct.py: Avoid exception if using multiple rawcopy/no-table entries.

If we are both having a bootloader and a U-Boot environment file, we can end up with two entries using "--source rawcopy" and "--no-table", and since they reuse the same file [1], their cleanup handlers will try to delete the same file twice. So just ignore the error if the file doesn't exist. [1]

Re: [OE-core] [PATCH V7] go: Add recipes for golang compilers and tools

On 08/03/17 23:19, Khem Raj wrote: >> ... >> For the following go-1.4 recipes: >> >> I wouldn't recommend fixing go-native at version 1.4, which is now >> postiviely ancient. >> Instead, add go1.4.3's SRC_URI into the go-native recipe, loading it >> in the right place so >> that make.bash finds it.

Re: [OE-core] [PATCH 2/7] create_npm.py: convert MIT/X11 to MIT

Hi Anders, from what I can see the problem is rooted a bit deeper, and this patch (together with 5, 6, 7 from the series) is basically symptomatic: the package.jsons license field is mostly expected to be spdx-compliant (see https://docs.npmjs.com/files/package.json#license). So I think we nee

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On Thu, 2017-03-09 at 00:18 +, Richard Purdie wrote: > How badly do people dislike the patch below? > > From: Richard Purdie > Subject: bitbake/oe-core: Filter contents of PATH > > Signed-off-by: Richard Purdie > > diff --git a/bitbake/lib/bb/utils.py b/bitbake/lib/bb/utils.py > index d6bc

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On Wed, 2017-03-08 at 19:41 +0100, Martin Jansa wrote: > On Wed, Mar 08, 2017 at 06:00:30PM +, Richard Purdie wrote: > > > > On Wed, 2017-03-08 at 17:21 +, Burton, Ross wrote: > > > > > > > > > On 8 March 2017 at 09:43, Peter Kjellerstedt > > axis > > > .com> wrote: > > > > > > > > sin

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 03/08/2017 04:02 PM, Khem Raj wrote: On 17-03-08 15:44:52, Martin Kelly wrote: On 03/08/2017 02:23 PM, Khem Raj wrote: On 17-03-08 13:56:12, Martin Kelly wrote: On 03/08/2017 01:46 PM, Khem Raj wrote: I agree we should not need them. Of course I can run a sed line to remove the rpaths from

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 03/08/2017 02:23 PM, Khem Raj wrote: On 17-03-08 13:56:12, Martin Kelly wrote: On 03/08/2017 01:46 PM, Khem Raj wrote: I agree we should not need them. Of course I can run a sed line to remove the rpaths from LLVM_LDFLAGS from tools/llvm-config/BuildVariables.inc (and this works just fine).

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 17-03-08 15:44:52, Martin Kelly wrote: > On 03/08/2017 02:23 PM, Khem Raj wrote: > > On 17-03-08 13:56:12, Martin Kelly wrote: > > > On 03/08/2017 01:46 PM, Khem Raj wrote: > > > > > > I agree we should not need them. Of course I can run a sed line to remove > > > the rpaths from LLVM_LDFLAGS f

Re: [OE-core] [PATCH] classes: add gitupstream class

On Wed, 2017-03-08 at 14:44 -0800, Andre McCurdy wrote: > On Wed, Mar 8, 2017 at 12:54 PM, Andre McCurdy > wrote: > > > > On Wed, Mar 8, 2017 at 9:25 AM, Ross Burton > > wrote: > > > > > > This class lets you use BBCLASSEXTEND to add a variant of the > > > recipe that > > > fetches from git ins

Re: [OE-core] [PATCH] Do not append to BBCLASSEXTEND

On Wed, 2017-03-08 at 16:02 -0600, Leonardo Sandoval wrote: > Hi > > you need to send a v2 revision, following the shortlog format > > * PatchDo not append to BBCLASSEXTEND >  Issue Shortlog does not follow expected format > [test_shortlog_format]  >   Suggested fixCom

Re: [OE-core] [PATCH] classes: add gitupstream class

On Wed, Mar 8, 2017 at 12:54 PM, Andre McCurdy wrote: > On Wed, Mar 8, 2017 at 9:25 AM, Ross Burton wrote: >> This class lets you use BBCLASSEXTEND to add a variant of the recipe that >> fetches from git instead of a tarball. > > Looks good. This approach could perhaps also cover git -vs- > exter

[OE-core] [PATCH] opkg: enable libsolv backend by default

The libsolv backend is vastly superior than the currently enabled internal ad-hoc solver. While the switch does have a small impact on disk and memory footprint, it make sense to change the default as for most cases the disk/memory footprint hit should be acceptable. Disk

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 17-03-08 13:56:12, Martin Kelly wrote: > On 03/08/2017 01:46 PM, Khem Raj wrote: > > On 17-03-07 16:43:47, Martin Kelly wrote: > > > Hi, > > > > > > While debugging an issue with a package that uses llvm-config to compile > > > with clang, I started hitting [rpaths] QA warnings because some out

Re: [OE-core] [PATCH V7] go: Add recipes for golang compilers and tools

Hi Matt Thanks for good feedback. I have snipped the mail and replied below On 17-03-06 12:00:44, Matt Madison wrote: > On Fri, Mar 3, 2017 at 3:18 PM, Khem Raj wrote: > > * This is converging the recipes for go from > > meta-virtualization and oe-meta-go > > > > * Add recipes for go 1.7 > > >

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 03/08/2017 01:46 PM, Khem Raj wrote: On 17-03-07 16:43:47, Martin Kelly wrote: Hi, While debugging an issue with a package that uses llvm-config to compile with clang, I started hitting [rpaths] QA warnings because some output executables contained absolute rpaths pointing into my build dire

[OE-core] [PATCH] libsolv: upgrade to 0.6.26

Drop 0001-Split-libsolvext-into-it-s-own-pkg-config-file.patch Signed-off-by: Alejandro del Castillo --- ...-libsolvext-into-it-s-own-pkg-config-file.patch | 67 -- .../{libsolv_0.6.24.bb => libsolv_0.6.26.bb} | 3 +- 2 files changed, 1 insertion(+), 69 deletions(-) d

Re: [OE-core] [PATCH] Do not append to BBCLASSEXTEND

Hi you need to send a v2 revision, following the shortlog format * PatchDo not append to BBCLASSEXTEND Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": "

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 17-03-07 16:43:47, Martin Kelly wrote: > Hi, > > While debugging an issue with a package that uses llvm-config to compile > with clang, I started hitting [rpaths] QA warnings because some output > executables contained absolute rpaths pointing into my build directory. > After tracing through th

Re: [OE-core] [PATCH] classes: add gitupstream class

On Wed, Mar 8, 2017 at 9:25 AM, Ross Burton wrote: > This class lets you use BBCLASSEXTEND to add a variant of the recipe that > fetches from git instead of a tarball. Looks good. This approach could perhaps also cover git -vs- externalsrc variants of a recipe, which seems to be a big topic for a

Re: [OE-core] [PATCH] perf.bb: Fix dependency while building kernel using externalsrc

Hi Andre, On 03/08/2017 12:23 PM, Andre McCurdy wrote: On Thu, Mar 2, 2017 at 11:59 PM, Manjukumar Matha wrote: Having dependency on do_patch will fail while building kernel using externalsrc. Depend on do_configure instead of do_patch to bypass the compilation error. I think the change to k

Re: [OE-core] [PATCH] perf.bb: Fix dependency while building kernel using externalsrc

On Thu, Mar 2, 2017 at 11:59 PM, Manjukumar Matha wrote: > Having dependency on do_patch will fail while building kernel using > externalsrc. Depend on do_configure instead of do_patch to bypass the > compilation error. I think the change to kernelsrc.bbclass is perhaps more significant than the

[OE-core] gpgme -- yet another python issue...

I don't have a fix for this, but if I enable multilib processing I see two additional issues. Maybe someone else can spot how to fix this? My config (add to local.conf) # Uncomment the following lines to enable multilib builds require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_v

Re: [OE-core] [PATCH] classes: add gitupstream class

On 3/8/17 11:45 AM, Burton, Ross wrote: > > On 8 March 2017 at 17:43, Mark Hatle > wrote: > > Devtool can do something similar, create a custom recipe... but I don't > believe > it has the ability to take an existing (patched) recipe, create a git tree >

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On Wed, Mar 08, 2017 at 06:00:30PM +, Richard Purdie wrote: > On Wed, 2017-03-08 at 17:21 +, Burton, Ross wrote: > > > > On 8 March 2017 at 09:43, Peter Kjellerstedt > .com> wrote: > > > since I see that you have integrated/staged the two patches that > > > add > > > inherits of pkgconfig

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On Wed, 2017-03-08 at 17:21 +, Burton, Ross wrote: > > On 8 March 2017 at 09:43, Peter Kjellerstedt .com> wrote: > > since I see that you have integrated/staged the two patches that > > add > > inherits of pkgconfig, but not the patches that add the dummy > > commands, > > I assume you have s

Re: [OE-core] [PATCH] classes: add gitupstream class

On 8 March 2017 at 17:43, Mark Hatle wrote: > Devtool can do something similar, create a custom recipe... but I don't > believe > it has the ability to take an existing (patched) recipe, create a git tree > somewhere [external], and then make it available for modification. > devtool modify RECIP

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On 3/8/17 11:35 AM, Richard Purdie wrote: > On Wed, 2017-03-08 at 11:28 -0600, Mark Hatle wrote: >> On 3/8/17 10:57 AM, Ross Burton wrote: >>> >>> Cryptodev is a way for userspace to access the kernel crypto >>> drivers (and so, >>> hardware crypto). >> If the BSP does not support crypto dev, what

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On 8 March 2017 at 17:35, Richard Purdie wrote: > Note that the implication here is that openssl depends on the kernel > building and many other pieces of the system depend on openssl so it > does bottleneck the build somewhat. > > It also means a kernel rebuild ends up triggering half the usersp

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On Wed, 2017-03-08 at 17:35 +, Richard Purdie wrote: > On Wed, 2017-03-08 at 11:28 -0600, Mark Hatle wrote: > > > > On 3/8/17 10:57 AM, Ross Burton wrote: > > > > > > > > > Cryptodev is a way for userspace to access the kernel crypto > > > drivers (and so, > > > hardware crypto). > > If the

Re: [OE-core] [PATCH] classes: add gitupstream class

On 3/8/17 11:36 AM, Burton, Ross wrote: > > On 8 March 2017 at 17:31, Mark Hatle > wrote: > > One of the uses I've seen people ask for is to take the (patched) > versions that > OE puts together, store these in their own git trees and manage it there >

Re: [OE-core] [PATCH] classes: add gitupstream class

On 8 March 2017 at 17:31, Mark Hatle wrote: > One of the uses I've seen people ask for is to take the (patched) versions > that > OE puts together, store these in their own git trees and manage it there > -- also > allowing them to patch them directly in their own trees. > > It appears to me this

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On Wed, 2017-03-08 at 11:28 -0600, Mark Hatle wrote: > On 3/8/17 10:57 AM, Ross Burton wrote: > > > > Cryptodev is a way for userspace to access the kernel crypto > > drivers (and so, > > hardware crypto). > If the BSP does not support crypto dev, what is the harm in this?  It > should fall back t

Re: [OE-core] [PATCH] classes: add gitupstream class

One of the uses I've seen people ask for is to take the (patched) versions that OE puts together, store these in their own git trees and manage it there -- also allowing them to patch them directly in their own trees. It appears to me this could be used to pull down that content. Have you thought

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On 3/8/17 10:57 AM, Ross Burton wrote: > Cryptodev is a way for userspace to access the kernel crypto drivers (and so, > hardware crypto). If the BSP does not support crypto dev, what is the harm in this? It should fall back to standard behaviors. > Not all hardware supports cryptodev so this is

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On 3/8/17 11:21 AM, Burton, Ross wrote: > > On 8 March 2017 at 09:43, Peter Kjellerstedt > wrote: > > since I see that you have integrated/staged the two patches that add > inherits of pkgconfig, but not the patches that add the dummy commands, > I

[OE-core] [PATCH] classes: add gitupstream class

This class lets you use BBCLASSEXTEND to add a variant of the recipe that fetches from git instead of a tarball. For example: BBCLASSEXTEND = "gitupstream:target" SRC_URI_class-gitupstream = "git://git.example.com/example" SRCREV_class-gitupstream = "abcd1234" This variant will have DEFAULT_P

[OE-core] [PATCH 3/4] lib/oeqa/selftest/oescripts: make test_cleanup_workdir use selftest-ed

Use a recipe which is bundled in the meta-selftest layer for this test, rather than relying on OE-Core remaining static (or updating the tests when OE-Core changes recipes). Tested with oe-selftest -r oescripts.TestScripts.test_cleanup_workdir Signed-off-by: Joshua Lock --- meta/lib/oeqa/selfte

[OE-core] [PATCH 1/4] chkconfig-alternatives-native: fix obey_variables

This postfunc assumes it's run from S, whereas that seems not to always be the case in practice. Explicitly define the full path of the file we wish to sed. Signed-off-by: Joshua Lock --- meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb | 2 +- 1 file changed, 1 insertion(

[OE-core] [PATCH 4/4] lib/oeqa/selftest/bbtests: update test_non_gplv3 to use selftest-ed

GPLv2 recipes have been moved to a new layer (meta-gplv2), instead of readline perform this test on the selftest-ed recipe in meta-selftest which has gplv2 and gplv3 variants. Tested with oe-selftest -r bbtests.BitbakeTests.test_non_gplv3 Signed-off-by: Joshua Lock --- meta/lib/oeqa/selftest/bb

[OE-core] [PATCH 2/4] meta-selftest: add selftest-ed recipes

The oe-selftest oescripts.TestScripts.test_cleanup_workdir was using gzip and the GPLv2 variant to test cleanup of the workdir. This broke with the removal of GPLv2 recipes from OE-Core. Instead of relying on recipes in OE-Core remaining static we should ensure that meta-selftest provides recipes

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On 8 March 2017 at 09:43, Peter Kjellerstedt wrote: > since I see that you have integrated/staged the two patches that add > inherits of pkgconfig, but not the patches that add the dummy commands, > I assume you have some reservations to these patches. What are your > take on the subject of black

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On 17-03-08 09:43:58, Peter Kjellerstedt wrote: > > -Original Message- > > From: openembedded-core-boun...@lists.openembedded.org > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > > Peter Kjellerstedt > > Sent: den 3 mars 2017 20:53 > > To: Max Krummenacher > > Cc

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On Wed, Mar 08, 2017 at 04:57:04PM +, Ross Burton wrote: > Cryptodev is a way for userspace to access the kernel crypto drivers (and so, > hardware crypto). > > Not all hardware supports cryptodev so this is something that should be > enabled > in a BSP layer instead of in oe-core. How is BS

[OE-core] [PATCH] openssl: disable cryptodev by default

Cryptodev is a way for userspace to access the kernel crypto drivers (and so, hardware crypto). Not all hardware supports cryptodev so this is something that should be enabled in a BSP layer instead of in oe-core. Signed-off-by: Ross Burton --- meta/recipes-connectivity/openssl/openssl.inc

[OE-core] [PATCH] gstreamer: remove git recipes

Yet again these were checking out 1.8.2 tags and then trying to apply 1.10.4 patches on top. Clearly nobody is actually using them, so delete them so they can't go stale again. Signed-off-by: Ross Burton --- .../gstreamer/gstreamer1.0-libav_git.bb| 38 -- .../gstream

[OE-core] [PATCH] license: don't assume source files are UTF-8

We can't assume that source files are entirely UTF-8, so when copying the license blocks open the file as binary instead of text. [ YOCTO #11135 ] Signed-off-by: Ross Burton --- meta/classes/license.bbclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/classes/l

[OE-core] [PATCH] Do not append to BBCLASSEXTEND

From: Ming Liu Replace some "+=/=+" with "=" when setting BBCLASSEXTEND, they are redundant and inconsistent with the same setting in other recipes. Signed-off-by: Ming Liu --- meta/recipes-devtools/build-compare/build-compare_git.bb | 2 +- meta/recipes-extended/libsolv/libsolv_0.6.24

Re: [OE-core] Create more than one image with WIC

On Wed, Mar 08, 2017 at 02:41:10PM +0100, Gary Thomas wrote: > On 2017-03-08 11:57, Ed Bartosh wrote: > >On Wed, Mar 08, 2017 at 10:44:21AM +0100, Daniel Schultz wrote: > >>Hi, > >> > >>I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks) > >>and added them to the local.conf. > >> >

Re: [OE-core] Create more than one image with WIC

On 2017-03-08 11:57, Ed Bartosh wrote: On Wed, Mar 08, 2017 at 10:44:21AM +0100, Daniel Schultz wrote: Hi, I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks) and added them to the local.conf. When I build the image only the first wks in WKS_FILES will be used by WIC and the se

[OE-core] [PATCH v3 5/6] vulkan: Add recipe for Vulkan common loader

Add a recipe for vulkan loader library and the vulkaninfo binary. Vulkan can be built to support X11 or wayland or both. There is currently no support for building tests, validation layers or even the demos as that would require a bunch of otherwise unnecessary dependencies. Fix the build on musl

[OE-core] [PATCH] gcc-runtime: Enable libmpx for x86-64

Intel MPX was recently enabled on x86 (_append_x86) but that didn't enable it on x86-64. Explicitly enable libmpx on x86-64 too. Signed-off-by: Mikko Ylinen --- meta/recipes-devtools/gcc/gcc-runtime.inc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/meta/recipes-devtools/gcc/gcc-runt

Re: [OE-core] [PATCH] gcc-runtime: Add libmpx supprt for x86

On Wed, 2017-03-08 at 01:00 +0100, Martin Jansa wrote: > Seems to cause following QA issue for DISTROs which don't > inherit remove-libtool.bbclass > > ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime: > Files/directories were installed but not shipped in any package: >   /usr/lib/lib

Re: [OE-core] [PATCH] recipes: Move out stale GPLv2 versions to a seperate layer

On Wed, 2017-03-08 at 11:11 +, Richard Purdie wrote: > On Wed, 2017-03-08 at 09:34 +, Peter Kjellerstedt wrote: > > > > And the layer should be added to the layer index... > > Yes, it should. I've submitted meta-gplv2 to the layer index. Joshua -- __

Re: [OE-core] [PATCH] recipes: Move out stale GPLv2 versions to a seperate layer

On Wed, 2017-03-08 at 09:34 +, Peter Kjellerstedt wrote: > > I'm proposing we mmove to this separate layer for 2.3 with its > > future > > maintinership and testing to be determined in 2.4 and beyond. > > > > Signed-off-by: Richard Purdie > Since this has now been integrated, announcing where

Re: [OE-core] Create more than one image with WIC

On Wed, Mar 08, 2017 at 10:44:21AM +0100, Daniel Schultz wrote: > Hi, > > I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks) > and added them to the local.conf. > > When I build the image only the first wks in WKS_FILES will be used > by WIC and the second will be ignored. Is it

[OE-core] [PATCH] gcc-runtime: Fix QA issue

ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package: /usr/lib/libmpxwrappers.la Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_inst

[OE-core] Create more than one image with WIC

Hi, I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks) and added them to the local.conf. When I build the image only the first wks in WKS_FILES will be used by WIC and the second will be ignored. Is it possible to build two images in one build? Includes of the wks files in

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Peter Kjellerstedt > Sent: den 3 mars 2017 20:53 > To: Max Krummenacher > Cc: OE-core > Subject: Re: [OE-core] [PATCHv3 0/5] Add dummy too

[OE-core] [PATCH] busybox: ifupdown:pass interface device name for ipv6 route command

IPv6 routes need the device argument for link-local routes, or they cannot be used at all. E.g. "gateway fe80::def" seems to be used in some places, but kernel refuses to insert the route unless device name is explicitly specified in the route addition. Signed-off-by: Haiqing Bai --- ...ss-inter

Re: [OE-core] [PATCH] recipes: Move out stale GPLv2 versions to a seperate layer

> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Richard Purdie > Sent: den 7 mars 2017 19:23 > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCH] recipes: Move out

Re: [OE-core] [PATCH v2 5/6] vulkan: Add recipe for Vulkan common loader

On Tue, 2017-02-28 at 11:26 +0200, Jussi Kukkonen wrote: > Add a recipe for vulkan loader library and the vulkaninfo binary. > > Vulkan can be built to support X11 or wayland or both. There is > currently no support for building tests, validation layers or even > the demos as that would require a

[OE-core] [PATCH v2] useradd.bbclass: drop obsolete code

Cleanup useradd class by removing the code made obsolete by the introduction of Recipe Specific Sysroot. Signed-off-by: Maxin B. John --- Changes in v2: Update PSEUDO_PASSWD as it is required by pseudo and without it ipk builds would break --- meta/classes/useradd.bbclass | 34 +

[OE-core] [PATCH] busybox: ifupdown:pass interface device name for ipv6 route command

IPv6 routes need the device argument for link-local routes, or they cannot be used at all. E.g. "gateway fe80::def" seems to be used in some places, but kernel refuses to insert the route unless device name is explicitly specified in the route addition. Signed-off-by: Haiqing Bai --- ...ss-inter