[yocto] New: "extrapatches" bbclass.

[Kaz Kylheku (poky)]

#
# extrapatches bbclass
#
# This bbclass allows for a recipe to apply additional patches.
#
# "Additional patches" refers to patches that are not individually
# fetched by the SRC_URI mechanism, but are already present
# inside the source trees that are fetched and unpacked.
# Referring directly to recipe-side patches
# without fetching them via SRC_URI is also possible.
#
# How to use this class:
#
#   1. Add   inherit extrapatches   to your recipe.
#   2. Optionally set the EXTRAPATCHES_WORKDIR,
#   3. List the patches in EXTRAPATCHES in order of application.
#  - Relative paths are interpreted relative to 
EXTRAPATCHES_WORKDIR.

#  - Absolute paths are allowed
#
# Influential variables:
#
#   Name  Default   Desc
#   
--
#   EXTRAPATCHES_WORKDIR  ${S}  extrapatches changes to this 
directory.

#
#   EXTRAPATCHES  ""list of path names of patch files
#   relative paths are resolved from
#   the EXTRAPATCHES_WORKDIR directory.
#   EXTRAPATCHES entries must not 
contain

#   spaces or shell meta-characters.
#
# The following SRC_URI style options supported in EXTRAPATCHES 
variable:

#
#   Name  Default   Desc
#   
--

#   apply 1 Boolean, apply the patch or not.
#
#   striplevel1 How many leading directory 
components

#   to remove, passed as the -p option
#   of patch.
#
# For Boolean options: yes, y, true, t, and 1 all specify "true";
# no, n, false, f and 0 specify "false".
#
# Additional usage notes:
#
# The patches you list in EXTRAPATCHES will be applied *AFTER* any
# patches that Yocto applies that are specified on the SRC_URI.
#
# If this is a problem, you can follow this method, or the alternative:
#
#   1. Add  do_patch[noexec] = "1"  to your recipe.
#   2. List your SRC_URI patches again in the EXTRAPATCHES variable,
#  keeping in mind they are fetched into ${WORKDIR}.
#  Absolute paths may be used like ${WORKDIR}/001-foo.patch
#
# Alternative:
#
#   1. Add  do_patch[noexec] = "1"  to suppress Yocto's do_patch.
#   2. Do *NOT* list any patches in SRC_URI.
#   3. Refer directly to your recipe-side patches in EXTRAPATCHES,
#  for instance EXTRAPATCHES = "${THISDIR}/files/my-patch.patch ..."
#

EXTRAPATCHES_WORKDIR = "${S}"

do_patch_extra() {
cd ${EXTRAPATCHES_WORKDIR}
mkdir -p patches

if [ "$(quilt top)" = patches/empty-last.patch ] ; then
# extra patches already applied: delete them, but
# keep the empty-first.patch
while [ "$(quilt top)" != patches/empty-first.patch ] ; do
quilt delete
done
elif quilt series | grep -q '^patches/empty-first[.]patch$' ; then
# our patches are half-applied; the markers exist, but
# the patches/empty-last.patch is not on top.
# Let's try to recover.

# blow off all unapplied patches
for patch in $(quilt unapplied) ; do
quilt delete $patch
done

if quilt applied empty-first.patch > /dev/null ; then
# if the empty-first.patch marker is applied, then
# delete everything above it
while [ "$(quilt top)" != patches/empty-first.patch ] ; do
quilt delete
done
else
# the empty-first.patch is not applied, and no
# unapplied patches exist. Let's assume that we
# have a clean slate with the only patches that exist
# being the ones from Yocto's do_patch. We begin our marker.
# quilt ref ensures that the empty patch file is actually 
created

quilt new empty-first.patch ; quilt ref
fi
else
# dummy marker patch indicating start of extra patches
quilt new empty-first.patch ; quilt ref
fi

for patch in ${EXTRAPATCHES} ; do
import_patch_with_options "$patch"
quilt push
done

# dummy marker patch indicating that all patches are applied
quilt new empty-last.patch ; quilt ref
}
addtask patch_extra after do_patch before do_configure

import_patch_with_options()
{
local patch=$1
local striplevel=1
local apply=1
local opt
local arg

while true ; do
case $patch in
*' '* )
printf "patch name %s contains spaces\n" "$patch"
exit 1
;;
*\;* )
opt=${patch##*;}
patch=${patch%;*}
case $opt in
*=* )
arg=${opt##*=}
opt=${opt%=*}
case $opt in
striplevel )
striplevel=$arg
;;

[yocto] [meta-security][PATCH] oe-scap: fix inconsistent indentation

[Yi Zhao]

Signed-off-by: Yi Zhao 
---
 .../recipes-openscap/oe-scap/oe-scap_1.0.bb   | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/meta-security-compliance/recipes-openscap/oe-scap/oe-scap_1.0.bb 
b/meta-security-compliance/recipes-openscap/oe-scap/oe-scap_1.0.bb
index 5b61375..e84ed30 100644
--- a/meta-security-compliance/recipes-openscap/oe-scap/oe-scap_1.0.bb
+++ b/meta-security-compliance/recipes-openscap/oe-scap/oe-scap_1.0.bb
@@ -8,12 +8,11 @@ LICENSE = "MIT"
 SRCREV = "7147871d7f37d408c0dd7720ef0fd3ec1b54ad98"
 SRC_URI = "git://github.com/akuster/oe-scap.git"
 SRC_URI += " \
-   file://run_cve.sh \
-   file://run_test.sh \
-   file://OpenEmbedded_nodistro_0.xml \
-file://OpenEmbedded_nodistro_0.xccdf.xml \
-"
-   
+file://run_cve.sh \
+file://run_test.sh \
+file://OpenEmbedded_nodistro_0.xml \
+file://OpenEmbedded_nodistro_0.xccdf.xml \
+   "
 
 S = "${WORKDIR}/git"
 
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] uboot-sign pyro fail

[Michael Nazzareno Trimarchi]

Hi

On Thu, Mar 7, 2019 at 6:54 PM Michael Nazzareno Trimarchi
 wrote:
>
> Hi all
>
> I'm trying to generate a sign image with pyro but problem is that when
> uboot is compiled
> the build dir depend on UBOOT_CONFIG and when the uboot-sign.class try to find
> the u-boot.dtb file this is not get because the ${B} point to the base
> but ${B}/${config}/...
> is the directory used by uboot.inc. Anyone has some suggestions?

I have improved a bit not using UBOOT_CONFIG but UBOOT_MACHINE and change
a bit uboot-sign class but still not catch who is using it and how

Michael

>
> Michael
>
>
> --
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO  -  Founder  Cruquiuskade 47 |
> | +31(0)851119172 Amsterdam 1018 AM NL |
> |  [`as] http://www.amarulasolutions.com   |



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] uboot-sign pyro fail

[Michael Nazzareno Trimarchi]

Hi all

I'm trying to generate a sign image with pyro but problem is that when
uboot is compiled
the build dir depend on UBOOT_CONFIG and when the uboot-sign.class try to find
the u-boot.dtb file this is not get because the ${B} point to the base
but ${B}/${config}/...
is the directory used by uboot.inc. Anyone has some suggestions?

Michael


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] device usb com, keyboard and composite (com and keyboard )

[A AL]

I have to develop device usb com,keyboard and composite (com and keyboard
)   , can anyone share what would be a good way to do it ?
Thank you in advance!
ALI ALERWI 
erwi...@gmail.com
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] SRC_URI when there is a local mirror but no remote repo

[Steve Scott]

SRC_URI = "file://${TOPDIR}/../local_mirror/example-1.0.0.src.tar.gz" should
work, without need for do_unpack.

What error are you getting?

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Edmund Nadolski
> Sent: Wednesday, March 06, 2019 11:52 AM
> To: Edmund Nadolski ;
> yocto@yoctoproject.org
> Subject: Re: [yocto] SRC_URI when there is a local mirror but no remote
repo
> 
> Friendly ping, any thoughts on this?
> 
> One thing I have noted - without the remote url, bitbake will not link the
file
> into DL_DIR or create a *.done file for it.
> 
> TIA,
> Ed
> 
> > -Original Message-
> > From: yocto-boun...@yoctoproject.org  boun...@yoctoproject.org>
> > On Behalf Of Edmund Nadolski
> > Sent: Wednesday, February 27, 2019 3:00 PM
> > To: yocto@yoctoproject.org
> > Subject: [yocto] SRC_URI when there is a local mirror but no remote
> > repo
> >
> > Hi,
> >
> > Does Yocto/Bitbake support a way to set SRC_URI in a recipe when there
> > is no corresponding upstream remote (git://, https://, etc.) for a
*.tar.gz
> file?
> > IOW, I've configured for own_mirrors and set BB_NO_NETWORK=1, and
> my
> > *.tar.gz file only lives in the local_mirror directory.
> >
> > It looks to me like file:// thinks that the file always lives under
${S}.
> >
> > TIA,
> > Ed
> >
> > ...
> > # functional workaround
> > SRC_URI = " http://some.example.com/example-1.0.0.src.tar.gz;
> > ...
> >
> > do_unpack () {
> > # Unpack straight from the local mirror since there is no remote
> > tar xzf ${TOPDIR}/../local_mirror/example-1.0.0.src.tar.gz -C
> > ${S}
> >
> > do_install () {
> > install -d ${D}/${MY_DIR}
> > install -m 0744 ${S}/example/example.sh ${D}/${MY_DIR}
> >
> > --
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple ubifs partition

[Ulrich Ölmann]

Hi there,

On Thu, Mar 07 2019 at 15:11 +0100, Stelling2 Carsten 
 wrote:
> Have you seen https://github.com/pengutronix/genimage?

you can find it included within https://github.com/pengutronix/meta-ptx
with an accompanying genimage.bbclass.

Best regards
Ulrich

> Regards,
>
> Carsten
>
> Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> Im Auftrag von Gabriele Zampieri
> Gesendet: Montag, 4. März 2019 12:17
> An: yocto@yoctoproject.org
> Betreff: [yocto] Multiple ubifs partition
>
> Hi all,
>
> I'm trying to build a distribution that has multiple partitions. The 
> desiderata is something like:
>
> - rootfs.ubifs mounted on /
> - data.ubifs mounted on /data
> - opt.ubifs mounted on /opt
>
> I was wondering if there is a standard way to achieve the goal. I see that 
> there is a tool called wic, but it does not seems to support ubifs. I could 
> post process the tarball image and doing stuff with my scripts, but I'd 
> prefer doing this in a single bitbake run. Can you suggest something?
>
> Thanks,
> Gabriele


--
Pengutronix e.K.   | Ulrich Ölmann   |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SRC_URI when there is a local mirror but no remote repo

[Edmund Nadolski]

Friendly ping, any thoughts on this?

One thing I have noted - without the remote url, bitbake will not link the file 
into DL_DIR or create a *.done file for it.

TIA,
Ed

> -Original Message-
> From: yocto-boun...@yoctoproject.org 
> On Behalf Of Edmund Nadolski
> Sent: Wednesday, February 27, 2019 3:00 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] SRC_URI when there is a local mirror but no remote repo
> 
> Hi,
> 
> Does Yocto/Bitbake support a way to set SRC_URI in a recipe when there is
> no corresponding upstream remote (git://, https://, etc.) for a *.tar.gz file?
> IOW, I've configured for own_mirrors and set BB_NO_NETWORK=1, and my
> *.tar.gz file only lives in the local_mirror directory.
> 
> It looks to me like file:// thinks that the file always lives under ${S}.
> 
> TIA,
> Ed
> 
> ...
> # functional workaround
> SRC_URI = " http://some.example.com/example-1.0.0.src.tar.gz;
> ...
> 
> do_unpack () {
> # Unpack straight from the local mirror since there is no remote
> tar xzf ${TOPDIR}/../local_mirror/example-1.0.0.src.tar.gz -C ${S}
> 
> do_install () {
> install -d ${D}/${MY_DIR}
> install -m 0744 ${S}/example/example.sh ${D}/${MY_DIR}
> 
> --
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple ubifs partition

[Marc Ferland]

> On Mon, Mar 4, 2019 at 6:17 AM Gabriele Zampieri
>  wrote:
> >
> > Hi all,
> >
> > I'm trying to build a distribution that has multiple partitions. The 
> > desiderata is something like:
> >
> > - rootfs.ubifs mounted on /
> > - data.ubifs mounted on /data
> > - opt.ubifs mounted on /opt
> >
> > I was wondering if there is a standard way to achieve the goal. I see that 
> > there is a tool called wic, but it does not seems to support ubifs. I could 
> > post process the tarball image and doing stuff with my scripts, but I'd 
> > prefer doing this in a single bitbake run. Can you suggest something?
> >

Hummm just reread your mail, and I think you will probably have to
roll up your own image type. The meta-raspberrypi layer contains a
custom image bbclass which you could use as an example.

Good luck!
Marc
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.29

[Bruce Ashfield]

On Mon, Mar 4, 2019 at 1:19 PM Paul Gortmaker
 wrote:
>
> Bruce, Yocto kernel folks:
>
> Here is the next 4.18.x stable update "extension" primarily created
> for the Yocto project, continuing from the previous v4.18.28 release.
>
> There are about 275 commits here, based on commits chosen from what
> was used in the existing 4.19.21 stable release that had over 300
> backports, which is one of the larger stable releases ever to ship.
>
> I've put this 4.18.x queue through the usual testing; build testing
> on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
> and finally some sanity runtime tests on x86-64.
>
> I did the signed tag just as per the previously released versions.
> Please find a signed v4.18.29 tag using this key:
>
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
>
> in the repo in the kernel.org directory here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
>git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git
>
> for merge to standard/base in linux-yocto-4.18 and then out from there
> into the other base and BSP branches.
>
> For those who are interested, the evolution of the commits is here:
>
>https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

Thanks Paul,

Both the .28 and .29 releases are now merged into linux-yocto.

Bruce

>
> This repo isn't needed for anything; it just exists for transparency and
> so people can see the evolution of the raw commits that were originally
> selected to create this 4.18.x release.
>
> Paul.



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Multiple ubifs partition

[Marc Ferland]

Look for the multiubi fstype:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass#n151


On Mon, Mar 4, 2019 at 6:17 AM Gabriele Zampieri
 wrote:
>
> Hi all,
>
> I'm trying to build a distribution that has multiple partitions. The 
> desiderata is something like:
>
> - rootfs.ubifs mounted on /
> - data.ubifs mounted on /data
> - opt.ubifs mounted on /opt
>
> I was wondering if there is a standard way to achieve the goal. I see that 
> there is a tool called wic, but it does not seems to support ubifs. I could 
> post process the tarball image and doing stuff with my scripts, but I'd 
> prefer doing this in a single bitbake run. Can you suggest something?
>
> Thanks,
> Gabriele
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple ubifs partition

[Stelling2 Carsten]

Hi Gabriele,

Have you seen https://github.com/pengutronix/genimage?

Regards,

Carsten

Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] Im 
Auftrag von Gabriele Zampieri
Gesendet: Montag, 4. März 2019 12:17
An: yocto@yoctoproject.org
Betreff: [yocto] Multiple ubifs partition

Hi all,

I'm trying to build a distribution that has multiple partitions. The desiderata 
is something like:

- rootfs.ubifs mounted on /
- data.ubifs mounted on /data
- opt.ubifs mounted on /opt

I was wondering if there is a standard way to achieve the goal. I see that 
there is a tool called wic, but it does not seems to support ubifs. I could 
post process the tarball image and doing stuff with my scripts, but I'd prefer 
doing this in a single bitbake run. Can you suggest something?

Thanks,
Gabriele
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] npm offline build for yocto

[Jan Kiszka]

On 07.03.19 11:25, Josef Holzmayr wrote:

Hi Jan,

On Thu, Mar 07, 2019 at 10:37:26AM +0100, Jan Kiszka wrote:

Hi Michael,

I found your progress report (and unanswered question) on that topic in 
http://lists.openembedded.org/pipermail/openembedded-core/2018-April/268639.html.
Did this effort go further?

I just ran into it again while updating
https://github.com/siemens/meta-iot2000 to Node.js >v6. I also played with
prefilling the cache, but likely in the wrong way.


We've had our share of fun ourselves by now, especially with the
event-stream module being hijacked and removed. To my knowledge none of


A mess...


the existing nodejs package managers (npm, yarn, ...) do support pure
fetching neither explicit caching. The only thing that seems to be
mostly working fine is using an explicit caching proxy like lazy-npm to
externally cache the remote repositories.


Fetching is already implemented by bitbake. Now the question is if we can use 
native npm to install offline.


My understanding was that "npm cache add " could be a path, though 
there were at least some issues in the past: 
https://github.com/nodejs/help/issues/944. What only I tried so far was "npm 
cache add " but that didn't work with npm 6.4.1. Maybe I should also 
check the tarball path. But that would mean unpacking the dependencies into 
${S}/node_modules becomes pointless (well, it already is).


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] npm offline build for yocto

[Josef Holzmayr]

Hi Jan,

On Thu, Mar 07, 2019 at 10:37:26AM +0100, Jan Kiszka wrote:
> Hi Michael,
> 
> I found your progress report (and unanswered question) on that topic in 
> http://lists.openembedded.org/pipermail/openembedded-core/2018-April/268639.html.
> Did this effort go further?
> 
> I just ran into it again while updating
> https://github.com/siemens/meta-iot2000 to Node.js >v6. I also played with
> prefilling the cache, but likely in the wrong way.

We've had our share of fun ourselves by now, especially with the
event-stream module being hijacked and removed. To my knowledge none of
the existing nodejs package managers (npm, yarn, ...) do support pure
fetching neither explicit caching. The only thing that seems to be
mostly working fine is using an explicit caching proxy like lazy-npm to
externally cache the remote repositories.

Greetz
-- 
———
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Recipe require kernel headers

[Gabriele Zampieri]

Hi all,

I have a custom recipe that builds and installs a C program that include:

#include 
#include 
#include 

I can compile it with TI prebuilt SDK, but when I try to build it with
yocto the compiler is unable to find those headers.

In the recipe do_compile I simply execute:
${CC} ${CFLAGS} ${S}/program.c -o program
(as I do with the prebuild SDK). But the compilation fails due to the
missing headers. I could a list of include paths to ${CC}, pointing to the
location in the kernel tree, but I don't really like it as solution. The
prebuild SDK install those file in
/sysroots//usr/include (and append that
path to CFLAGS through the env setup script). Moreover, if I build the
image without my recipe and I look for the headers I find them in rootfs,
but not in recipe-sysroot. The Yocto system I'm using is based on TI arago
customization.

How can I add the sanitized kernel heders to the recipe-sysroot or use them
to build my tool?

Thanks in advance,
Gabriele
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] openscap-daemon: backport patch to fix build error with python 3.7

[Yi Zhao]

Fixes build error:
  | Traceback (most recent call last):
  |   File "setup.py", line 25, in 
  | from openscap_daemon import version
  |   File 
"/buildarea/build/tmp/work/core2-64-poky-linux/openscap-daemon/0.1.10-r0/git/openscap_daemon/__init__.py",
 line 22, in 
  | from openscap_daemon.system import System
  |   File 
"/buildarea/build/tmp/work/core2-64-poky-linux/openscap-daemon/0.1.10-r0/git/openscap_daemon/system.py",
 line 29
  | from openscap_daemon import async
  | ^
  | SyntaxError: invalid syntax

Signed-off-by: Yi Zhao 
---
 ...-module-and-variables-to-get-rid-of-async.patch | 130 +
 .../openscap-daemon/openscap-daemon_0.1.10.bb  |   4 +-
 2 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 
meta-security-compliance/recipes-openscap/openscap-daemon/files/0001-Renamed-module-and-variables-to-get-rid-of-async.patch

diff --git 
a/meta-security-compliance/recipes-openscap/openscap-daemon/files/0001-Renamed-module-and-variables-to-get-rid-of-async.patch
 
b/meta-security-compliance/recipes-openscap/openscap-daemon/files/0001-Renamed-module-and-variables-to-get-rid-of-async.patch
new file mode 100644
index 000..2a518bf
--- /dev/null
+++ 
b/meta-security-compliance/recipes-openscap/openscap-daemon/files/0001-Renamed-module-and-variables-to-get-rid-of-async.patch
@@ -0,0 +1,130 @@
+From c34349720a57997d30946286756e2ba9dbab6ace Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Mat=C4=9Bj=20T=C3=BD=C4=8D?= 
+Date: Mon, 2 Jul 2018 11:21:19 +0200
+Subject: [PATCH] Renamed module and variables to get rid of async.
+
+async is a reserved word in Python 3.7.
+
+Upstream-Status: Backport
+[https://github.com/OpenSCAP/openscap-daemon/commit/c34349720a57997d30946286756e2ba9dbab6ace]
+
+Signed-off-by: Yi Zhao 
+---
+ openscap_daemon/{async.py => async_tools.py} |  0
+ openscap_daemon/dbus_daemon.py   |  2 +-
+ openscap_daemon/system.py| 16 
+ tests/unit/test_basic_update.py  |  3 ++-
+ 4 files changed, 11 insertions(+), 10 deletions(-)
+ rename openscap_daemon/{async.py => async_tools.py} (100%)
+
+diff --git a/openscap_daemon/async.py b/openscap_daemon/async_tools.py
+similarity index 100%
+rename from openscap_daemon/async.py
+rename to openscap_daemon/async_tools.py
+diff --git a/openscap_daemon/dbus_daemon.py b/openscap_daemon/dbus_daemon.py
+index e6eadf9..cb6a8b6 100644
+--- a/openscap_daemon/dbus_daemon.py
 b/openscap_daemon/dbus_daemon.py
+@@ -81,7 +81,7 @@ class OpenSCAPDaemonDbus(dbus.service.Object):
+ @dbus.service.method(dbus_interface=dbus_utils.DBUS_INTERFACE,
+  in_signature="", out_signature="a(xsi)")
+ def GetAsyncActionsStatus(self):
+-return self.system.async.get_status()
++return self.system.async_manager.get_status()
+ 
+ @dbus.service.method(dbus_interface=dbus_utils.DBUS_INTERFACE,
+  in_signature="s", out_signature="(sssn)")
+diff --git a/openscap_daemon/system.py b/openscap_daemon/system.py
+index 2012f6e..85c2680 100644
+--- a/openscap_daemon/system.py
 b/openscap_daemon/system.py
+@@ -26,7 +26,7 @@ import logging
+ from openscap_daemon.task import Task
+ from openscap_daemon.config import Configuration
+ from openscap_daemon import oscap_helpers
+-from openscap_daemon import async
++from openscap_daemon import async_tools
+ 
+ 
+ class ResultsNotAvailable(Exception):
+@@ -40,7 +40,7 @@ TASK_ACTION_PRIORITY = 10
+ 
+ class System(object):
+ def __init__(self, config_file):
+-self.async = async.AsyncManager()
++self.async_manager = async_tools.AsyncManager()
+ 
+ logging.info("Loading configuration from '%s'.", config_file)
+ self.config = Configuration()
+@@ -90,7 +90,7 @@ class System(object):
+ input_file, tailoring_file, None
+ )
+ 
+-class AsyncEvaluateSpecAction(async.AsyncAction):
++class AsyncEvaluateSpecAction(async_tools.AsyncAction):
+ def __init__(self, system, spec):
+ super(System.AsyncEvaluateSpecAction, self).__init__()
+ 
+@@ -113,7 +113,7 @@ class System(object):
+ return "Evaluate Spec '%s'" % (self.spec)
+ 
+ def evaluate_spec_async(self, spec):
+-return self.async.enqueue(
++return self.async_manager.enqueue(
+ System.AsyncEvaluateSpecAction(
+ self,
+ spec
+@@ -488,7 +488,7 @@ class System(object):
+ 
+ return ret
+ 
+-class AsyncUpdateTaskAction(async.AsyncAction):
++class AsyncUpdateTaskAction(async_tools.AsyncAction):
+ def __init__(self, system, task_id, reference_datetime):
+ super(System.AsyncUpdateTaskAction, self).__init__()
+ 
+@@ -536,7 +536,7 @@ class System(object):
+ 
+ if task.should_be_updated(reference_datetime):
+ self.tasks_scheduled.add(task.id_)
+-self.async.enqueue(
++