summaryrefslogtreecommitdiffstats
path: root/classes
Commit message (Collapse)AuthorAgeFilesLines
* classes: add depreciated warning bbclassBruce Ashfield2024-03-151-0/+3
| | | | | | | Adding a simple bbclass that when inherited appends do_compile to emit a warning that the recipe will be removed in the future. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* classes/image-oci: Map image architecture correctlyJoshua Watt2023-11-061-1/+1
| | | | | | | | | | | OCI requires that the architecture [1] be a valid GOARCH [2]. To correctly perform this mapping, use the go library code from OE core. [1]: https://github.com/opencontainers/image-spec/blob/main/config.md#properties [2]: https://go.dev/doc/install/source#environment Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* classes/image-oci-umoci: Replace ":" in image file nameJoshua Watt2023-11-061-3/+7
| | | | | | | | | | | | | The OCI_IMAGE_TAG variable can contain a ":" if the user wants to give the image a name and a tag, as in: OCI_IMAGE_TAG = "${IMAGE_BASENAME}:latest" However, while this is valid for tag name, the ":" is illegal in OCI image file names so replace it with "_" when naming the symlinks Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* classes/image-oci-umoci: Allow labels to have spacesJoshua Watt2023-11-061-2/+2
| | | | | | | | | | | Quote the label argument passed to umoci to allow it to correctly handle spaces. Note that this requires that OCI_IMAGE_LABELS have the argument quoted with single quotes, as in: OCI_IMAGE_LABELS = "org.opencontainers.image.description='${SUMMARY}'" Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* classes/image-oci-umoci: Allow environment variables to have spacesJoshua Watt2023-11-061-2/+2
| | | | | | | | | | | Quote the environment variable argument passed to umoci to allow it to correctly handle spaces. Note that this requires that OCI_IMAGE_ENV_VARS have the argument quoted with single quotes, as in: OCI_IMAGE_ENV_VARS = "FOO='bar bat'" Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* umoci: allow encoding of multiple entrypoint or cmd argumentsBruce Ashfield2023-11-061-2/+3
| | | | | | | | | | | | umoci can encode both entrypoint and cmd lists into the oci image. This is done by using the --config.entrypoint and --config.cmd arguments multiple times. We can split our OCI_* variables on space and support multiple arguments in either command and keep compatibility with existing users. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* conf: make container recipes parseable when virtualization is not setBruce Ashfield2023-03-201-1/+5
| | | | | | | | | | | | | The container stack flexibilty features set defaults (like other parts of the layer) when 'virtualization' is in the distro features. That reqirement means that the recipes fail parsing and QA checks when the distro feature isn't enabled. The defaults are currently safe for a virtualization enabled and disabled configuration, so we include them in either case. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* conf: introduce container configuration valuesBruce Ashfield2023-03-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the configuration file itself: These variables represent groupings of functionality in the CNCF landscape. In particular, they are areas where there is a choice between more than one implementation or an area where abstraction is beneficial. The contents of the variables are are runtime components that recipes may use for RDEPENDS. Build dependencies are not typically flexible, so do not currently have DEPENDS equivalents for the components (i.e. DEPENDS on runc versus crun). Distro features such as kubernetes or other container stacks can be used to set different defaults for these variables. Note: these are "global" values, since they represent choices. If more than of a grouping is required on target, then the variable can be appended or set to multiple values. That being said, Recipes should generally agree on the values, hence the global namespace. Recipe specific choices can still be done, but they risk conflicting on target or causing runtime issues / errors. ## CNCF "components" # engines: docker-ce/docker-moby, virtual-containerd, cri-o, podman VIRTUAL-RUNTIME_container_engine ??= "podman" # runtime: runc, crun, runv, runx VIRTUAL-RUNTIME_container_runtime ??= "virtual-runc" # networking: cni, netavark VIRTUAL-RUNTIME_container_networking ??= "cni" # dns: cni, aardvark-dns VIRTUAL-RUNTIME_container_dns ??= "cni" # orchestration: k8s, k3s VIRTUAL-RUNTIME_container_orchestration ??= "k3s" ## Kubernetes terminology "components" VIRTUAL-RUNTIME_cri ??= "containerd" VIRTUAL-RUNTIME_cni ??= "cni" Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* containers: introduce container-host classBruce Ashfield2023-02-171-0/+15
| | | | | | | | | | | | | | | | Introducing a small (at the moment) class that represents configuration and processing required to prepare a target image to be a container host. A recipe that requires container configuration should inherit this class, and the container-host-config package will be added as a RDEPENDS, and install common configuration files. In the future, additional functionality or dependencies will be added here to synchronize the configuration of multiple container host packages. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* oci-image: create two different tar outputsBruce Ashfield2023-02-102-2/+28
| | | | | | | | | | | | | | | | | | | | | | | The original tar output of the oci image followed the sloci-image convention of putting the oci contents into a subdirectory in the tarball. This allows it to work directly with skopeo, etc, but it isn't the format that tools like podman expect in an oci-image tarball. We move the original format to have "-dir" in the name, and let the more simply named one be the oci-image format as expcted by various 3rd party tools 1) image_name.tar: compatible with oci tar format, blobs and rootfs are at the top level. Can load directly from something like podman 2) image_name-dir.tar: original format from meta-virt, is just a tar'd up oci image directory (compatible with skopeo :dir format) We also fix a bug in the sloci-image backend, where the sloci tar was removing the raw oci image directory leaving a dangling symlink. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* image-oci-umoci: add convenience symlink for oci image tarBruce Ashfield2022-12-071-0/+2
| | | | | | | | We have been symlinking the -oci image directory for a while, but we can also create a shorted convenience symlink for the tar'd version of that directory. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* image-oci-sloci: add convenience symlinks in deployBruce Ashfield2022-12-071-0/+7
| | | | | | | | To sync the sloci OCI image backend with the umoci variant, create shortened convenience symlinks for the image and image.tar in the deploy directory. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* image-oci-umoci: add convenience symlink to latest imageBruce Ashfield2022-09-121-0/+2
| | | | | | | | Symlink the date-time based image name, to just the imagename-oci. This makes scripting use of the deployed container much simpler. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* image-oci-umoci: add parameter for stop signalVasileios Anagnostopoulos2022-07-152-0/+5
| | | | | | | | Add an optional parameter that allows to override the stop signal that is used. Signed-off-by: Vasileios Anagnostopoulos <vasileios.anagnostopoulos@siemens.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* image-oci-umoci: properly handle tags other than latestPascal Bach2022-07-151-17/+17
| | | | | Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen: Disable highmem on qemuarmMichal Orzel2022-06-201-2/+4
| | | | | | | | | | | | | | | | | | By default, highmem option is enabled for machine types later than virt-2.12. This allows qemu to place devices and RAM in physical address space above 32-bits. This can cause issues as according to the documentation Xen supports up to 12GiB of physical address space. Recently the issue was observed using runqemu, that was causing Linux running on top of Xen to stall when trying to access ECAM space placed by qemu at 256GiB mark. Even though this issue is most probably related to QEMU and not Xen (the investigation showed that it can map ECAM space correctly), it is best to avoid such issues by disabling highmem on qemuarm. Signed-off-by: Michal Orzel <michal.orzel@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* Revert "xen: Disable PCI on qemuarm with Xen"Michal Orzel2022-06-201-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit fb0a7b97db4f419b82309f98a4944ae3330d1e2e. Justification: Commit fb0a7b97db4f removed the PCI node from the qemu device tree due to the issue when trying to access PCI configuration space that was causing Linux running on top of Xen to end up in an infinite loop. The investigation showed that the problem occurs due to qemu placing ECAM space at 256GiB mark. Even though Xen officially supports on arm32 up to 12GiB of physical address space, it is able to map it correctly for dom0. However, when Linux tries to access the ECAM space and the stage2 translation fault occurs, HPFAR register contains incorrect IPA. We can say it is incorrect because using hardware AT instruction or software lookup, we can obtain the correct IPA from the same VA. This can suggest that the problem is related to QEMU fault handling. Instead of removing the PCI node the follow-up commit will disable highmem option in qemu which will cause placing ECAM space in the 32-bit space. Signed-off-by: Michal Orzel <michal.orzel@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen: Disable PCI on qemuarm with XenBertrand Marquis2022-05-181-0/+22
| | | | | | | | | | | | | | | | | | Remove the pci node from the qemu device tree when runqemu is used with xen-qemuboot. Linux is ending up in an infinite loop when trying to access PCI configuration space when running on top of Xen on arm32. As we do not need or support any of the devices on PCI on arm32 at the moment, just remove the node from the device tree generated by qemu. The problem does not appear at the moment without Xen and it is unclear why it is with Xen. This will be investigated but in the meantime provide a working configuration for users. Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen: enable qemuboot for arm32Bertrand Marquis2022-05-181-5/+15
| | | | | | | | | | | | | | | | | | Add required variables to generate a qemuboot devicetree for qemuarm. With this change, Xen and dom0 can be started using runqemu. Xen is started using qemu kernel argument and the devicetree is modified to properly boot dom0 (which is loaded in memory). This is using the same system as qemuarm64. At this stage dom0 is hanging on PCI device scanning. This patch is also using qemuarm64 as machine for arm64 bit instead of aarch64 to allow adding support for other machine (an example a Xilinx board that can be emulated with using an other xen machine). Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* qemuboot: Fix command line and enable other machinesBertrand Marquis2022-05-181-4/+5
| | | | | | | | | | | | | | Fix qemuboot-xen-dtb to properly add dom0 bootargs by using a parameter instead of directly using the QB_XEN_DOM0_BOOTARGS inside the function. When not done, the variable is empty and dom0 bootargs are wrong in the device tree. Use QB_MACHINE to generate a device tree with qemu instead of always using the armv8 machine. This will allow this class to be used for other machines later. Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* Revert "qemuboot, xen-image-minimal: enable runqemu for qemuarm Xen images"Bruce Ashfield2022-05-092-149/+5
| | | | | | This reverts commit 1c746a976830ebaf85c7c8c25612bea349b0a7c5. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen images, qemuboot: configure xenbr0 bridge for runqemu, testimageChristopher Clark2022-05-091-1/+35
| | | | | | | | | | | | | | Networking for Xen guest virtual machines is commonly configured via bridging in the host system between a physical interface and the guest virtual interfaces. To make it easier to test networking and use testimage with Xen guest virtual machines, extend the bbclass that provides network configuration for qemu machines for the Xen images to configure a Xen bridge and put eth0 onto it when QB_XEN_HOST_BRIDGE is set. Signed-off-by: Christopher Clark <christopher.clark@starlab.io> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* qemuboot, xen-image-minimal: enable runqemu for qemuarm Xen imagesChristopher Clark2022-05-092-5/+149
| | | | | | | | | | | | | | | | | | | | | The Xen hypervisor built for Arm 32-bit targets can be launched with runqemu by providing a u-boot script and configuration for Qemu, which enables interactive testing of Xen images. Add qemuboot-xen-u-boot.bbclass to add a new bitbake task for generating the u-boot script. Since this increases the number of qemuboot-specific classes that are inherited by the xen-image-minimal recipe, change the inherit of all of these to only apply to qemu machines with the qemuall override. Update qemuboot-xen-defaults.bbclass to supply working default parameters for the qemuarm machine needed to boot successfully in testing. Also change all the arch-specific variable overrides into narrower qemu platform overrides instead to avoid unnecessary interactions with other Arm platform machines. Signed-off-by: Christopher Clark <christopher.clark@starlab.io> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* config: introduce hostname generation hooksBruce Ashfield2021-12-131-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Overriding hostname in a .conf file, via base-files: HOST_NAME="k3s-host" hostname_pn-base-files = "${HOST_NAME}" Is always a valid option, but if it is not configured, we can easily have two hosts with the same name on the network, confusing adddress assignement, etc. This commit introduces a way to generate a unique hostname based on the uuid of the build host, and the machine being built. If virt-unique-hostname is added to IMAGE_FEATURES, like the following: IMAGE_FEATURES += "virt-unique-hostname" IMAGE_FEATURES[validitems] += "virt-unique-hostname" Then a rootfs postprocessing hook will override hostnae to something unique. Note: this means your image will be reproducible on a single builder, but not between them. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen: update to setuptools based lopperBruce Ashfield2021-11-031-1/+1
| | | | Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xtf: add testimage integration to run XTF test cases in OEQAChristopher Clark2021-09-021-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new minimal OEQA test case to run the Xen Test Framework test runner in the standard testimage step. Tested with qemux86-64 and designed for compatibility with Arm when XTF supports it. To enable, append to local.conf: INHERIT += "testimage" QEMU_USE_SLIRP = "1" TEST_SERVER_IP = "127.0.0.1" To run: bitbake -c testimage xtf-image For inspection while it runs, at another shell prompt: * Observe the image booting: tail -f ${TMPDIR}/work/qemux86_64-*/xtf-image/*/testimage/qemu_boot_log.* * Observe the tests running once boot has completed: tail -f ${TMPDIR}/work/qemux86_64-*/xtf-image/*/temp/log.do_testimage The XTF test sequence by default is a single XTF test case with minimal hardware dependency to ensure that Xen is running, the Xen toolstack is functional and XTF works. Additional XTF test cases for an image can be configured via variables that are documented in the OEQA test case: * XTF_TEST_CASES_POPULATE * XTF_TEST_CASES_SKIP * XTF_TEST_CASES_REQUIRE Since testimage requires a functioning network to perform the tests on the image and the qemu MACHINES do not have networking enabled this commit provides a new qemuboot-testimage-network bbclass to add an image postprocess command to enable a functional eth0 for qemu MACHINES. Signed-off-by: Christopher Clark <christopher.clark@starlab.io> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* image-oci: use new override syntaxBruce Ashfield2021-08-061-1/+1
| | | | | | | The dependencies of the image-oci class were missed in initial conversions. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* global: overrides conversion pass 2Bruce Ashfield2021-08-021-5/+5
| | | | Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* global: overrides syntax conversionBruce Ashfield2021-08-024-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OEcore/bitbake are moving to use the clearer ":" as an overrides separator. This is pass one of updating the meta-virt recipes to use that syntax. This has only been minimally build/runtime tested, more changes will be required for missed overrides, or incorrect conversions Note: A recent bitbake is required: commit 75fad23fc06c008a03414a1fc288a8614c6af9ca Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Sun Jul 18 12:59:15 2021 +0100 bitbake: data_smart/parse: Allow ':' characters in variable/function names It is becomming increasingly clear we need to find a way to show what is/is not an override in our syntax. We need to do this in a way which is clear to users, readable and in a way we can transition to. The most effective way I've found to this is to use the ":" charater to directly replace "_" where an override is being specified. This includes "append", "prepend" and "remove" which are effectively special override directives. This patch simply adds the character to the parser so bitbake accepts the value but maps it back to "_" internally so there is no behaviour change. This change is simple enough it could potentially be backported to older version of bitbake meaning layers using the new syntax/markup could work with older releases. Even if other no other changes are accepted at this time and we don't backport, it does set us on a path where at some point in future we could require a more explict syntax. I've tested this patch by converting oe-core/meta-yocto to the new syntax for overrides (9000+ changes) and then seeing that builds continue to work with this patch. (Bitbake rev: 0dbbb4547cb2570d2ce607e9a53459df3c0ac284) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen-image-minimal: fix aarch64 build for non-qemuboot-enabled machinesChristopher Clark2021-08-021-1/+1
| | | | | | | | | | The qemuboot device tree generation task in qemuboot-xen-dtb.bbclass requires the QB_SYSTEM_NAME variable to be set to identify the Qemu binary to use. Skip the task if it is not set. Reported-and-tested-by: Jon Mason <jdmason@kudzu.us> Signed-off-by: Christopher Clark <christopher.clark@starlab.io> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* qemuboot, xen-image-minimal: enable runqemu for qemuarm64 Xen imagesChristopher Clark2021-07-292-0/+239
| | | | | | | | | | | | | | | | | | | The Xen hypervisor built for Arm 64-bit targets can be launched with runqemu by providing a Device Tree binary and configuration for Qemu, which enables interactive testing of Xen images. Add qemuboot-xen-dtb.bbclass to add a new bitbake task for generating the dtb file by using lopper on a device tree produced by Qemu. Add qemuboot-xen-defaults.bbclass to supply working default parameters for the qemuarm64 machine and general support for qemuboot for Xen, and adjust the defaults as needed to boot successfully in testing. Development aided by this script by Stewart Hildebrand of DornerWorks: https://gist.github.com/stewdk/110f43e0cc1d905fc6ed4c7e10d8d35e Signed-off-by: Christopher Clark <christopher.clark@starlab.io> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* oci-images: create backend .inc filesBruce Ashfield2021-07-193-67/+195
| | | | | | | | | | | | | | | | As part of allowing different types of oci images to be created, we split our IMG_cmd into .inc files that can then be specific to the selected type. For the umoci backend: We can take the same options as sloci expects and use umoci to create images. The resulting OCI image is similar, but by using umoci, we set the stage to do multi-tag, or multi-layer images in the future. But for now, we are functionally equivalent to the sloci backend. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* cni: introduce cni networking bbclassBruce Ashfield2021-03-151-0/+18
| | | | Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen: retire the Raspberry Pi sdcard classChristopher Clark2020-08-111-120/+0
| | | | | | | | | | | | | | | | | | The sdcard class in the meta-raspberrypi layer is now extensible with support for adding files such as hypervisor binaries to the boot partition, so this layer can switch to use that and drop the custom sdcard bbclass. Uses the new RPI_SDIMG_EXTRA_DEPENDS and DEPLOYPAYLOAD variables, and: IMAGE_CLASS: sdcard_image-rpi-xen => sdcard_image-rpi IMAGE_FSTYPE: rpi-xen-sdimg => rpi-sdimg Please note that the filename suffix of the image is changed by this. Also apply _raspberrypi4-64 scoping to the Raspberry Pi settings. Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen, raspberry pi: add Xen-specific SD card classChristopher Clark2020-07-061-0/+120
| | | | | | | | | | | | | | | At the moment the regular meta-raspberrypi SD card class does not allow for optional inclusion of extra files in the SD card boot partition without requiring those same files be present in the root filesystem. This affects hypervisor binaries, such as Xen, which do not necessarily belong within the guest filesystem. As a workaround, inherit the sdcard_image-rpi.bbclass and clone the main IMAGE_CMD function, adding the Xen-specific deploy that is needed. This can be retired when the parent class has extensibility added. Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* xen: apply layer settings when xen DISTRO_FEATURE is enabledChristopher Clark2020-07-061-0/+6
| | | | | | | | | | | | These settings are necessary for Xen and enabling them here, using the same mechanism that is used by k8s in this layer, simplifies building images for Xen. - Ensure that Xen mode is enabled in QEMU. - On ARM platforms: enable Flattened Device Tree (FDT) support. Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* conf: defer DISTRO_FEATURE check to bbclass processingBruce Ashfield2020-02-102-2/+2
| | | | | | | | | | | | | | | | | We were using USER_CLASS loading to allow conditional checking on DISTRO_FEATURES, which triggered distro feature specific version pinning. It was found that DISTRO_FEATURES set in local.conf is not consistently available at layer.conf parse time, hence our checks were not always working as expected (i.e. the version files are not included). If we move the DISTRO_FEATURE check to the bbclasses, and use it to trigger the include, we should have a consistent set of variable resolution and consistent behaviour. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* conf: add k8s distro featureBruce Ashfield2019-12-101-0/+6
| | | | | | | Add support for a new distro feature to control kubernetes versions and related configuration. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* conf: fix meta-virt version / config includeBruce Ashfield2019-12-061-0/+6
| | | | | | | | | | | | | | | As was reported: https://lists.yoctoproject.org/g/meta-virtualization/message/4173?p=,,,20,0,0,0::Created,,conf%2Flayer.conf+is+broken,20,2,0,61269733 The conditional include of the meta-virt versions and config was not working properly due to parse time constraints. This commit fixes that by following the example of the meta-cube layer and instead using a user bbclass to load the .inc file after distro/distro features have been resolved by bitbake. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* containers: introduce image-ociBruce Ashfield2019-02-271-0/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This image class creates an oci image spec directory from a generated rootfs. The contents of the rootfs do not matter (i.e. they need not be container optimized), but by using the container image type and small footprint images, we can create directly executable container images. Once the tarball (or oci image directory) has been created of the OCI image, it can be manipulated by standard tools. For example, to create a runtime bundle from the oci image, the following can be done: Assuming the image name is "container-base": If the oci image was a tarball, extract it (skip, if a directory is being directly used) % tar xvf container-base-<arch>-<stamp>.rootfs-oci-latest-x86_64-linux.oci-image.tar And then create the bundle: % oci-image-tool create --ref name=latest container-base-<arch>-<stamp>.rootfs-oci container-base-oci-bundle Or to copy (push) the oci image to a docker registry, skopeo can be used (vary the tag based on the created oci image: % skopeo copy --dest-creds <username>:<password> oci:container-base-<arch>-<stamp>:latest docker://zeddii/container-base The following image variables are available to customize the details of the constructed image (defaults as shown): OCI_IMAGE_AUTHOR ?= "${PATCH_GIT_USER_NAME}" OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}" OCI_IMAGE_TAG ?= "latest" OCI_IMAGE_RUNTIME_UID ?= "" OCI_IMAGE_ARCH ?= "${TARGET_ARCH}" OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}" OCI_IMAGE_ENTRYPOINT ?= "sh" OCI_IMAGE_ENTRYPOINT_ARGS ?= "" OCI_IMAGE_WORKINGDIR ?= "" //List of ports to expose from a container running this image: //PORT[/PROT] // format: <port>/tcp, <port>/udp, or <port> (same as <port>/tcp). OICI_IMAGE_PORTS ?= "" // key=value list of labels OCI_IMAGE_LABELS ?= "" // key=value list of environment variables OCI_IMAGE_ENV_VARS ?= "" Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* sanity-meta-virt: Watch for SanityCheck eventPaul Barker2017-10-121-1/+1
| | | | | | | | | | The ConfigParsed event is raised multiple times during a build which resulted in the sanity warning appearing up to 4 times per build. Instead we should be watching for the SanityCheck event (this is what the sanity checks in oe-core watch for). Signed-off-by: Paul Barker <pbarker@toganlabs.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* sanity-meta-virt: Make skip variable name layer specificPaul Barker2017-10-121-1/+1
| | | | | | | | | The variable used to skip the sanity check should be named in a layer specific way. This will ensure there is no confusion if other layers use a similar sanity check. Signed-off-by: Paul Barker <pbarker@toganlabs.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* sanity-meta-virt.bbclass: add class for bbappend files checkingChen Qi2017-10-021-0/+10
| | | | | | | | | | | | Add a new class, sanity-meta-virt.bbclass, to check for whether necessary settings are available for bbappend files in this layer to be effective, and warn users if not. In addition, a variable SKIP_SANITY_BBAPPEND_CHECK is added to enable users to explicitly skip the checking to avoid unwanted warnings. Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* housekeeping: swap out go-osarchmap in favor of goarchMark Asselstine2017-04-111-43/+0
| | | | | | | | | | Continue work to use go infra in oe-core instead of the support for go previously found in meta-virt. This is a 1:1 drop in replacement and removes one more go piece from meta-virt in favor of the common support found in oe-core. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* Remove True option to getVar callsPaul Barker2017-01-031-9/+9
| | | | | | | getVar() now defaults to expanding by default. Signed-off-by: Paul Barker <paul@paulbarker.me.uk> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* go-osarchmap: Skip golang recipes for unsupported architecturesPaul Barker2017-01-031-1/+6
| | | | | | | | | | Building any recipe for a mips-based machine like arduino-yun currently leads to errors in go_map_arch(). Instead, errors should only be raised if a recipe which uses golang is built. This is achieved using the same error handling seen in recipes-extended/xen. Signed-off-by: Paul Barker <paul@paulbarker.me.uk> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* go-cross: uprev to 1.5.2Zongchun Yu2016-04-191-0/+38
* Add go-native as build bootstrap for go-cross. * Upgrade go-cross to v1.5.2 Signed-off-by: Zongchun Yu <zongchun.yu@nxp.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-04-28 15:05:10 +0000