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

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

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

* disable getty on tty1
* disable weston toolbar (as we are running only one app at boot)
* define the epiphany app to use (HomeAssistant)
* run the HomeAssistant epiphany app at boot

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

This image doesn't need epiphany broweser per se, it actually needs the
epiphany browser for a specific app. Include epiphany-app and let the
epiphany dependency be pulled automatically.

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>

This support is done configurable using the following variables:

EPIPHANY_APP             - Defines the app name (which needs to be the
			   directory name in FILESPATH/FILEEXTRAPATHS).
			   Currently defines it for HomeAssistant. If
			   this directory provides a
			   `service-override.conf`, the build system
			   will set it up as a systemd service
			   configuration for the main boot systemd
                           service.
EPIPHANY_URL             - The URL that the browser will load at
                           startup.
EPIPHANY_RDEPENDS        - Extra dependencies. If the specific
			   application needs extra dependencies at
                           runtime, they can be specifed here.
EPIPHANY_SERVICE_ENABLED - By default disabled (0). When enabled (1), it
			   will enable loading the epiphany app at boot.

The configuration defaults to setting up Epiphany browser in application
mode for a local instance of Home Assistant.

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>

ActsJFFS2Test it is requires mtd_block device to mount jffs2 fs image.

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

jffs2.img will be used to mount /storage directory required by ActsJFFS2Test
test suite using loopback device.

Related-To: https://git.ostc-eu.org/OSTC/OHOS/components/staging/xts_acts/-/issues/5


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

ActsJFFS2Test test suite requires /storage directory to be mounted on jffs2.
To achieve that jffs2 image is mounted on loopdevice using block2mtd module,
therefore mtd, jffs2 and block2mtd modules have to be configured.

Related-To: https://git.ostc-eu.org/OSTC/OHOS/components/staging/xts_acts/-/issues/5


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

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

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>

This is not ideal but will unblock using the browser while we
investigate the matter.

See: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14281



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

This image is part of the dashboard gateway demo and is meant to run on
the linux based target running HomeAssistant.

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

This configuration inherits the ohos distro configuration but makes
configurations specific to the dashboard demo use-cases. For now we only
handle the HomeAssistant version requirements and set a custom hostname.

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

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

Our bblayers file diverged between the different flavours and e.g. the
meta-ohos-foundation was still present for zephyr and freertos.

We enable all layers on all flavours. The only overhead should be in
parsing the recipes. If something else breaks we consider this a bug
worth fixing.

The usage of symlinks should be safe here. Yocto buildhost will almost
always be Linux based, but it this should even work on Windows by now.
If we run into trouble with this we can always got back to three files.

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

Since https://git.ostc-eu.org/OSTC/OHOS/meta-av96/-/merge_requests/4


it is no longer needed.

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@huawei.com>

Dongni He authored 4 years ago and Stefan Schmidt committed 4 years ago

Signed-off-by: Dongni He <dongni.he@huawei.com>

Zygmunt Krynicki authored 4 years ago and Andrei Gherzan committed 4 years ago

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

The BSP layer is now a subdirectory - meta-av96-core.

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

The layer was restructured and all the BSP support is now provided
through the machine configuration.

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>

Add meta-qt5, new dependency layer of meta-av96.

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@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 will include definitions and info for useful variables like DL_DIR,
SSTATE_DIR etc.

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

This fixes:

    $ test "$ACCEPT_FSL_EULA" -eq 1 && echo 'ACCEPT_FSL_EULA = "1"' >> conf/local.conf
    /usr/bin/bash: line 155: test: : integer expression expected

To avoid the problem and reduce complexity, move the Freescale-specific
logic to the only build that requires it.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>

Following documentation from
https://git.ostc-eu.org/OSTC/infrastructure/pipelines/-/blob/main/reuse.yaml
Add the reuse job which can fail, since this repository is not compliant
with REUSE yet.

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


Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@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>

Signed-off-by: Ettore Chimenti <ettore.chimenti@seco.com>

Add general description of MACHINE and add bblayers to template.

Signed-off-by: Ettore Chimenti <ettore.chimenti@seco.com>

Add mosquitto 2.0.7. This recipe is in sync with the one recently added
to upstream meta-networking and should be removed once we rebase to a
newer Yocto that has commit 9428a09002a0a1058b155ff767bd5de5c8929998.

Fixes https://git.ostc-eu.org/OSTC/planning/core-os/-/issues/30



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

Stefan observed that CI job initializes bitbake with layer configuration
from the layer as checked out by git-repo, and only then switches to the
branch being tested.

This resulted in bitbake incorrectly failing to notice a layer that was
added by the tested patch.

The solution is to move all of the bitbake initialization stage from the
.build jobs "script_before" section, to the "script" section. In effect
any derivative job can use "script_before" to freely alter the source
tree before bitbake is initialized. Due to the lucky arrangement of YAML
anchors, the .build job's "script" keeps running with bitbake
environment sourced, so it can do exactly what one would expect - build
the desired recipe.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@huawei.com>