Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Due to a configuration bug in upstream, the build system outputs a
configuration warning similar to:

---------- CONFIG_SERIAL_OF_PLATFORM -----------------
Config: CONFIG_SERIAL_OF_PLATFORM
From:
[...]/tmp/work-shared/qemux86-64/kernel-source/.kernel-meta/configs/v5.10/standard/cfg/8250.cfg
Requested value:  CONFIG_SERIAL_OF_PLATFORM=y
Actual value:

Avoid this by disabling the specific config.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Due to a configuration bug in upstream, the build system outputs a
configuration warning similar to:

---------- CONFIG_SERIAL_OF_PLATFORM -----------------
Config: CONFIG_SERIAL_OF_PLATFORM
From:
[...]/tmp/work-shared/qemux86-64/kernel-source/.kernel-meta/configs/v5.10/standard/cfg/8250.cfg
Requested value:  CONFIG_SERIAL_OF_PLATFORM=y
Actual value:

Avoid this by disabling the specific config.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Due to a configuration bug in upstream, the build system outputs a
configuration warning similar to:

---------- CONFIG_SERIAL_OF_PLATFORM -----------------
Config: CONFIG_SERIAL_OF_PLATFORM
From:
[...]/tmp/work-shared/qemux86-64/kernel-source/.kernel-meta/configs/v5.10/standard/cfg/8250.cfg
Requested value:  CONFIG_SERIAL_OF_PLATFORM=y
Actual value:

Avoid this by disabling the specific config.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Imported from poky[1].

[1] 7e9ea9d807ba7682c9bd81a0a8711a5af08aec21

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Imported from poky[1].

[1] 7e9ea9d807ba7682c9bd81a0a8711a5af08aec21

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Imported from poky[1].

[1] 7e9ea9d807ba7682c9bd81a0a8711a5af08aec21

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

By just installing this into all of our images we open the door for
in-field debugging. It needs to be invoked manually and we do not drag
in any dbg packages so the image size stays sane.

Combined with a remote debugging setup and copy of the images files and
symbols this can allow full debugging capabilities with GDB or an IDE
later on.

Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

Available knobs:

WESTON_INI_BACKGROUND_IMAGE - Full runtime path of the background image.
			      The base name of this path needs to be
                              available in FILEPATH (EXTRAFILESPATH).
WESTON_INI_BACKGROUND_COLOR - Background color - default to white.
WESTON_INI_BACKGROUND_TYPE  - Background type - defaults to centered.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

In this way, multiple recipes can take advantage of various assets (eg.
images, logos).

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Using systemd notify, a service dependency would be more robust. This
allows, for example, another service to depend on weston-init without
having to hack a sleep (or similar).

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

This creates a mechanism to generate a dynamic weston.ini configuration
based on build variables.

The entire mechanism is enabled using the WESTON_DYNAMIC_INI variable
(enabled when set to 1).

The default path for the weston.ini configuration is set in
WESTON_INI_PATH as "etc/xdg/weston/weston.ini".

WESTON_INI_NO_TOOLBAR, when set to 1, disables the weston toolbar.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

This allows any image including this `.inc` file to have at its disposal
the primitives defined in that class.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

This class allows to hook a post install function that would mask getty
services enabled by systemd as part of `systemd_preset_all`.

To take advantage of it, an image would:
1. inherit this class
2. define SYSTEMD_MASK_GETTY to point to a list of tty devices that the
   hook will mask the getty service for.

Common use-case: disable running getty on tty1 at boot.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

We can reference it when pointing to license in recipes that don't have
any package license files.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

Epiphany needs gcr while gcr needs x11 backend in gtk3+. That leads us
to the need of bringing x11 DISTRO_FEATURE back.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

When we started to use the networkd unit for wired in qemu we also broke
the static IP configuration the runqemu script uses. The IP address, etc
are given as kernel commandline options for the static setup.

If we see this happening we can simply skip the networkd unit file for
DHCP setup as we know a static IP config was provided.

The key part of the imported unit file here is the KernelCommandLine=!ip
line in the match section to skip the unit if IP is present in the
commandline.

Closes: https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/29



Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

In order to control what we ship and being responsible for, as well as
reducing the image size, we start with disabling DISTRO_FEATURES we
inherited from Poky. These are simply default values Poky uses to show
what Yocto/OE can do. They have currently no use for us and we can still
bring them back when the use cases arises.

Before:
build tasks: 5795 (26m)
du -cs tmp/deploy/images/stm32mp1-av96/openharmony-image-extra-stm32mp1-av96-20210301211000.rootfs.tar.xz
46624

After:
build tasks: 5159 (24m)
du -cs tmp/deploy/images/stm32mp1-av96/openharmony-image-extra-stm32mp1-av96-20210301215709.rootfs.tar.xz
43420

Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

As part of our investigation and support, musl integration in the
project is fully supported (subject to the project's scope and QA
processes).

Upstream also carried out the relevant analysis and nothing 'known' is
broken: https://www.openwall.com/lists/musl/2019/11/08/6



That being said, we clean up the build logs of the respective warning.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

On ZFS hosts with compression on, the filesystem generation will fail.
The current default for extra image space is 1.2. Bump that to 2 to
workaround this issue and also have additional free space on the image.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

This file gets removed in the upstream poky recipe for qemuall due to
problems with it in the Yocto autobuilder QA.

On our side we need it in combination with spread so we bring it back
here. Next step would be to investigate why it fails on Yocto QA and get
it fixed upstream.

Signed-off-by: Stefan Schmidt <stefan.schmidt@huawei.com>

Bernhard Rosenkränzer authored 4 years ago and Stefan Schmidt committed 4 years ago

https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/issues/18



Signed-off-by: Bernhard Rosenkränzer <bernhard.rosenkraenzer.ext@huawei.com>

openharmony-image-<variant>-tests images are based on the
openharmony-image-<variant> with addition of the packagegroup-openharmony-tests
package group that aggregates all OpenHarmony tests.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

packagegroup-openharmony-tests is intended to aggregate OpenHarmony tests
and to be included in the OpenHarmony test images.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

Signed-off-by: Robert Drab <robert.drab@huawei.com>