summaryrefslogtreecommitdiffstats
path: root/meta/classes
AgeCommit message (Collapse)Author
2024-05-29classes: go-mod: do not pack go mod cacheStefan Herbrechtsmeier
Clean go module cache from builddir to prevent it of beeing packed. (From OE-Core rev: c850931590ff22da4d38756f957b88e04078c76c) Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com> Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit 328bea56dec8f83b5c118f567e122510f9243087) Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-05-29go.bbclass: fix path to linker in native Go buildsDmitry Baryshkov
Building native Go tools results in the tool pointing to the wrong location of dynamic linker (see below). The linker is looked up in the temporary dir, which can be removed if rm_work is inherited. This results in being unable to execute the program with the 'No such file or directory' error. Override linker specificiation for native recipes (and let Go build environment to pick up a correct one on it's own). The error is observed in case the distro doesn't use uninative.bbclass. If uninative.bbclass is used, the binary will be patched automatically to use the uninative loader instead of the system one. Without this patch: $ ldd tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man linux-vdso.so.1 (0x00007ffe945ec000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3a7490e000) /home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/work/x86_64-linux/go-md2man-native/1.0.10+gitAUTOINC+f79a8a8ca6-r0/recipe-sysroot-native/usr/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f3a74d13000) $ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man --help -bash: tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man: No such file or directory With the patch $ ldd tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man linux-vdso.so.1 (0x00007ffd19dbf000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d44181000) /lib64/ld-linux-x86-64.so.2 (0x00007f2d44586000) $ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man --help Usage of tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man: -in string Path to file to be processed (default: stdin) -out string Path to output processed file (default: stdout) (From OE-Core rev: b611c77e4883ad81a8f40cbee3fea006500735ed) Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 44b397daa68b4d0a461225fe9ff7db8b5fcfdb7b) Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-05-29go: Always pass interpreter to linkerJoerg Vehlow
When gos internal linker is used, it uses hardcoded paths to the interpreter (dynamic linker). For x86_64 this hardcoded path is /lib64/ld-linux-x86-64.so.2, but yocto's default dynamic linker path is /lib64/ld-linux-x86-64.so.2. Most of the time, the internal linker is not used and binutils linker sets the correct path, but sometimes the internal linker is used and the resulting binary will not work on x86_64. To ensure the path is always correct, pass it to the linker. (From OE-Core rev: 69128ca66991b13358f2552fcd5a7cfa6dda4952) Signed-off-by: Joerg Vehlow <joerg.vehlow@aox.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 6b54215074d7f3dbba07f096f16b9c0acf51527c) Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-05-15kernel.bbclass: check, if directory exists before removing empty module ↵Heiko
directory If the kernel folder does not exist, find will result in an error. This can occur if the kernel has no modules but, for example, custom modules are created. Add check before deleting. (From OE-Core rev: 4e4681b26e0d88ad219d72b75e598e6b81b430fc) Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 7ef767d84d56b25498e45db83bb8f9d9caebeaf9) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-05-02rootfs-postcommands.bbclass: Only set DROPBEAR_RSAKEY_DIR onceMichael Glembotzki
If DROPBEAR_RSAKEY_DIR has already been set before, e.g. by overwriting the file dropbear.default, the line will still be appended a second time. DROPBEAR_RSAKEY_DIR="/path/to/dropbear" DROPBEAR_EXTRA_ARGS="-B" DROPBEAR_RSAKEY_DIR=/var/lib/dropbear (Backport of rev: 6045314d2968f6f5a0877a4dd45f35c766a40e40) (From OE-Core rev: 8a502301209ef144932ef5071c1a9b738db23270) Signed-off-by: Michael Glembotzki <Michael.Glembotzki@iris-sensing.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-03-12u-boot: Move UBOOT_INITIAL_ENV back to u-boot.incFabio Estevam
Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc because it encodes ${PN} in it, which should be set by the U-Boot recipe. Currently, whatever inherits uboot-config bbclass will fill-in its own PN, which would change the content of UBOOT_INITIAL_ENV per-package. Cc: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> Cc: Marek Vasut <marex@denx.de> Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations") (From OE-Core rev: 18b76259d27dc045f621cd512582c37e8bbab45c) Signed-off-by: Fabio Estevam <festevam@denx.de> Backported from master: 0b0c4b37d318b86f100512476ffd861e0ce1f47e Signed-off-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-03-07kernel.bbclass: Set pkg-config variables for building modulesMunehisa Kamata
[Backport cd2072e5d953 from the master without HOSTPKG_CONFIG setting] The pkg-config workaround has been applied for kernel image building, but not for module building. So pkg-config variables are different between do_compile and do_compile_kernelmodules tasks. It may unnecessary trigger rebuilding of a few host tools at the later task. Especially when CONFIG_DEBUG_INFO_BTF is enabled in the kernel, it may even trigger rebuilding vmlinux at do_compile_kernelmodules due to the rebuilt host tools such as certs/extract-cert or objtool (on x86). This eventually creates an inconsistent set of kernel binaries. Here is the repro steps: - Check out nanbield on x86 - The unexpected rebuild happens on kirkstone or possibly earlier - Ensure that pahole is available (e.g. via meta-oe) - Set KERNEL_DEBUG to "True" to properly set up PAHOLE e.g. $ export KERNEL_DEBUG="True" $ export BB_ENV_PASSTHROUGH_ADDITIONS="${BB_ENV_PASSTHROUGH_ADDITIONS} KERNEL_DEBUG" - Enable CONFIG_DEBUG_INFO_BTF=y e.g. $ bitbake -c menuconfig virtual/kernel -> Kernel hacking -> Compile-time checks and compiler options -> Generate BTF typeinfo - Build the kernel e.g. $ bitbake virtual/kernel The BTF information in the resulting bzImage and kernel modules are inconsistent, because the module's BTF information is generated using the "second" vmlinux that doesn't have the identical BTF to the "first" vmlinux. These modules can't be loaded at runtime due to the BTF mismatch. This also leads to a build-id mismatch between the installed bzImage and vmlinux since the bzImage is created from the first vmlinux, but the installed vmlinux is the second one. $ eu-readelf -n tmp/work/qemux86_64-poky-linux/linux-yocto/6.5.13+git/image/boot/{bzImage*,vmlinux*} | grep "Build ID" Build ID: 4a0d62ee7fef0244950f0f604253729875bea493 Build ID: fb99b3d91399dbe42bf67ddee59e0f5a0c7f74d9 To avoid the unexpected rebuilding that results in such inconsistency, set the same pkg-config variables when building kernel and modules. For kernel 5.19 and above, simply set the HOSTPKG_CONFIG in the make command line. (From OE-Core rev: d63af11e92094487d6e358f27283e5385937e7a8) Signed-off-by: Munehisa Kamata <kamatam@amazon.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-03-01kernel: make LOCALVERSION consistent between recipesBruce Ashfield
The initial fix for localversion setting in 6.3+ broke older recipes and also broke recipes setting localversion in a kernel recipe, as make-mod-scripts (and other locations) can trigger a regeneration of files and don't have access to the variable. Moving the setting of this variable to the global namespace doesn't make sense, so we follow the example of the kernel-abiversion and save a kernel-localversion to the build artifacts. Recipes that may regenerate scripts/dynamic files, must depend on the do_shared_workedir of the kernel and use the helper function to read the file storing the localversion. (From OE-Core rev: cca0971a7d92d823cc0c2b16cf14a7b2ed8ecb61) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com> Acked-by: Ryan Eatmon <reatmon@ti.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-03-01kernel: fix localversion in v6.3+Bruce Ashfield
During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: 74897e505db19a23a5b864a48a4fa97d657605c8) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-03-01kernel.bbclass: introduce KERNEL_LOCALVERSIONMing Liu
Just like UBOOT_LOCALVERSION, an end user can set KERNEL_LOCALVERSION to append a string to the name of the local version of the kernel image. (From OE-Core rev: 29a0d2a49df8e24f3948a2ddf03743f0cb5d09dd) Signed-off-by: Ming Liu <liu.ming50@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> cherry-picked from master 229435a52f36ddec5f85fb6d5ccd42044b688397 Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-03-01populate_sdk_ext: use ConfigParser instead of SafeConfigParserRoss Burton
SafeConfigParser was renamed to ConfigParser in 3.2, and the SafeConfigParser alias will be removed in 3.12. (From OE-Core rev: 50815c328e677ac079d38dc8555a909f049cf5be) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Cherry-picked from master: 71b3e7f71727137b4b996cc4160c9cc1581824b8 Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-02-15Revert "kernel: fix localversion in v6.3+"Steve Sakoman
This reverts commit d9273edae80978c34f8426f34f991b9598828aa9. This commit is causing breakage for some vendor kernel builds. (From OE-Core rev: 59cc2e75c15f8c6371a4c4a3b7bd2e6c3f145fbc) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-02-15kernel: fix localversion in v6.3+Bruce Ashfield
During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: d9273edae80978c34f8426f34f991b9598828aa9) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-02-07image-live.bbclass: LIVE_ROOTFS_TYPE support compressionLudovic Jozeau
The task for fstypes with compression is the same as the task for the uncompressed fstypes, e.g. when adding tar.xz to `IMAGE_FSTYPES`, it will be included into the do_image_tar task and not creating a separate do_image_tar.xz task. This commit fixes `LIVE_ROOTFS_TYPE` with compressed fstypes by depending on the actual task instead of the non-existent do_image_<fstype>.<compression> task. Fixes [YOCTO #15331] (From OE-Core rev: 60d88989698968c13f8e641f0ba1a82fcf700fb7) Signed-off-by: Ludovic Jozeau <ludovic.jozeau@smile.fr> Reviewed-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 67c507e3d42e52a6d452c4a453eeaf7f2e2d68d6) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-01-04testimage: drop target_dumper, host_dumper, and monitor_dumperSteve Sakoman
The target_dumper code is basically broken. It has been reading binary files over the text base serial communication and runs at every command failure which makes no sense. Each run might overwrite files from the previous run and the output appears corrupted due to confusion from the binary data. It isn't possible to cherry-pick "testimage: Drop target_dumper and most of monitor_dumper" from master, so just make target_dumper, host_dumper, and monitor_dumper empty functions. For further details see: https://lists.openembedded.org/g/openembedded-architecture/message/1888 (From OE-Core rev: 960e7e3dffa22c2142cb672c68cd9a8f0e3998a3) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-12-22testimage: Exclude wtmp from target-dumper commandsRichard Purdie
wtmp is filled with binary data which the run_serial command can't cope with. Catting this results in confusion of the serial interface and potentially large backlogs of data in the buffers which can hang qemu. Exclude the problematic files from the command. (From OE-Core rev: 2afd9a6002cba2a23dd62a1805b4be04083c041b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 599ac08a6f6fb3f6a89a897c8e06367c63c2f979) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-12-22externalsrc: Ensure SRCREV is processed before accessing SRC_URIYoann Congal
When SRCREV is used, call bb.fetch.get_srcrev() before accessing SRC_URI. Without this new bb.fetch.get_srcrev() call, SRC_URI might be accessed before SRCREV had a chance to be processed. In master, this is fixed by https://git.yoctoproject.org/poky/commit/?id=62afa02d01794376efab75623f42e7e08af08526 However, this commit is not suited for backport since it is quite invasive. The part of the commit that fix the bug is: --- a/meta/classes/externalsrc.bbclass +++ b/meta/classes/externalsrc.bbclass @@ -63,6 +63,7 @@ python () { else: d.setVar('B', '${WORKDIR}/${BPN}-${PV}') + bb.fetch.get_hashvalue(d) local_srcuri = [] fetch = bb.fetch2.Fetch((d.getVar('SRC_URI') or '').split(), d) for url in fetch.urls: NB: bb.fetch.get_hashvalue() does not exist in kirkstone but is equivalent to bb.fetch.get_srcrev(). Fixes [YOCTO #14918] (From OE-Core rev: f6563cca6c4bf627e904d81fbe5b0b0f2b16a107) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Suggested-by: Chris Wyse <chris.wyse@wysechoice.net> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-12-14Revert "kernel-fitImage: Strip path component from dtb"Steve Sakoman
This change breaks arm64 (and likely mips & riscv) This reverts commit 9a42349a176ca4d7a1bfab3425a0821dbcbd9368. (From OE-Core rev: b77cd331199fa62e3b162f37efca3b927c68d8e5) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-12-12native: Clear TUNE_FEATURES/ABIEXTENSIONRichard Purdie
Some recipes reference these. Rather than continually trying to chase down the references and taskhash issues, clear the variables for an easier life and simpler code. These wouldn't convey anything useful in a native build. (From OE-Core rev: 09ecafaf0e128c4dea062d359de37cbef461aed2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit f8edeead263708889d31a7ff578ef8274cb678b4) Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-12-02kernel-fitImage: Strip path component from dtbNinad Palsule
Machines that have added subdirectires to the KERNEL_DEVICETREE recently, such as arm32 boards that were moved under subdirectories in Linux 6.5, will have that subdirectory in the node name of the FIT. This breaks existing systems that select a configuration in u-boot by it's name. Strip off the directory component from the device tree to preserve compatibility. (From OE-Core rev: 941ba1a132bafa9c9be855fb91fec96d8b06299f) (From OE-Core rev: 9a42349a176ca4d7a1bfab3425a0821dbcbd9368) Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Ninad Palsule <ninad@linux.ibm.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> # backport to kirkstone Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-11-28goarch: Move Go architecture mapping to a libraryPeter Marko
Other spaces uses the Go architecture definitions as their own (for example, container arches are defined to be Go arches). To make it easier for other places to use this mapping, move the code that does the translation of OpenEmbedded arches to Go arches to a library. (From oe-core rev: 3e86f72fc2e1cc2e5ea4b4499722d736941167ce) This commit together with meta-virtualization commit 115f6367f37095415f289fb6981cda9608ac72ff broke meta-virtualization master used with meta-lts-mixins kirkstone/go which is our primary usecase for having kirkstone/go mixin layer Manually crafted since cherry-pick had too many conflicts: * different path to classes * additional architecture loongarch64 * different way how to import library (From OE-Core rev: 8726ae02d760270f9e7fe7ef5715d8f7553371ce) Signed-off-by: Peter Marko <peter.marko@siemens.com> Cc: Joshua Watt <JPEWhacker@gmail.com> Cc: Bruce Ashfield <bruce.ashfield@gmail.com> Cc: Jose Quaresma <jose.quaresma@foundries.io> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-11-14cve-check: sort the package list in the JSON reportRoss Burton
The JSON report generated by the cve-check class is basically a huge list of packages. This list of packages is, however, unsorted. To make things easier for people comparing the JSON, or more specifically for git when archiving the JSON over time in a git repository, we can sort the list by package name. (From OE-Core rev: 1245649fd2725915154648a98584c908da07af18) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit e9861be0e5020830c2ecc24fd091f4f5b05da036) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-11-01package_rpm: Allow compression mode overrideNiko Mauno
Commit 4a4d5f78a6962dda5f63e9891825c80a8a87bf66 ("package_rpm: use zstd instead of xz") changed the rpm package compressor from 'xz' to 'zstd' which results in decompression failure with BusyBox-provided 'rpm2cpio' applet and 'rpm' applet when given the '-i' (Install package) option: rpm2cpio: no gzip/bzip2/xz magic Introduce a variable which makes it possible to use a different compression mode, making it possible to override the default value for example like RPMBUILD_COMPMODE = "${@'w6T%d.xzdio' % int(d.getVar('XZ_THREADS'))}" to enable rpm decompression without including the full rpm package in the resulting root filesystem. (From OE-Core rev: a40d9258148e28cbee2168c93179cd4c1232fb62) (From OE-Core rev: ad4ea9f225b0dd6396088cc70b34f886c5fa62b4) Signed-off-by: Niko Mauno <niko.mauno@vaisala.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-10-21uboot-extlinux-config.bbclass: fix missed override syntax migrationQuentin Schulz
uboot-extlinux-config allows to specify multiple "labels" (entries in a menu, à-la grub) and each of them have their own values for some fields. Each "base" variable, e.g. UBOOT_EXTLINUX_FDT can be overridden for each label. This is done via the OVERRIDES mechanism based on the label name, e.g. UBOOT_EXTLINUX_FDT:linux if linux is a label. However, OVERRIDES doesn't contain the label globally because it's only necessary in one task. Therefore, the OVERRIDES itself is modified within the task. This means that the sigdata will not be told the dependency on UBOOT_EXTLINUX_FDT:linux, because it cannot know about it. For this reason, we need to explicitly specify which variables this task depends on via vardeps varflag for the task. This was done in the past, but we missed updating it during the override syntax migration so the cache wouldn't get invalidated if someone modifies UBOOT_EXTLINUX_FDT:linux from a configuration file or a bbappend for example. Let's fix this by migrating it to the new syntax. (From OE-Core rev: 5570e49791b770271f176a4deeb5f6f1a028cb4a) Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit b4dd9d873508128adbbf5ff6cf0a3df3d2ffbcf6) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-10-05fontcache.bbclass: avoid native recipes depending on target fontconfigMartin Jansa
* this caused liberation-font-native to depend on TUNE_PKGARCH target fontconfig because ${MLPREFIX}fontconfig-utils is added to RDEPENDS in anonymous python * the dependency tree for liberation-font-native got much shorter (just quilt-native and liberation-font-native itself): 2 after/pn-buildlist 78 before/pn-buildlist * fixes graphviz-native signature issue as well as detected with sstate-diff-machines.sh $ bitbake-diffsigs \ sstate-after/mako/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.184d4fd355f1e7a2d7d929ef4b5f62b94e2071df9dd674b2067ec21bfc7bcc1b \ sstate-after/qemux86-64/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.35da674d2dbc275bac02869dfce4165466315023910bdef65a6026e2cb942a46 Hash for task dependency liberation-fonts-native:do_populate_sysroot changed from 310d3da04ad9abf8ee99997e53d1ffa71c2b7d9d60fb0e8de85171a9ab6a77d3 to 048420ad1410c2b8d95498fc3c11681207335a2c722836f1f3e683cc449814da (From OE-Core rev: 098d4ca85c2bc77949843f117c6e336d5b77271d) Signed-off-by: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-09-30kernel.bbclass: Add force flag to rm callsRyan Eatmon
The latest 6.5 kernels do not appear to create the source file in ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the recipe errors out when trying to remove it. Simple fix is to add the -f (force) flag to the call. (From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc) (From OE-Core rev: 7e177848f97eb9958619c28b5e5dadee12f67507) Signed-off-by: Ryan Eatmon <reatmon@ti.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-09-30cml1: Fix KCONFIG_CONFIG_COMMAND not conveyed fully in do_menuconfigJaeyoon Jung
Variable overrides in KCONFIG_CONFIG_COMMAND do not work as expected due to double quote mismatches. The issue is reproducible in an environment where gold is the default linker. Below is an example snippet of run.do_terminal generated by do_menuconfig. do_terminal() { exec sh -c "make menuconfig CC="aarch64-webos-linux-gcc ..." LD="aarch64-webos-linux-ld.bfd ..." ... } Although LD override is set to bfd correctly, it is not passed to make and make menuconfig ends up with messages like: | gold linker is not supported as it is not capable of linking the kernel proper. | scripts/Kconfig.include:56: Sorry, this linker is not supported. (From OE-Core rev: 9c483765db762dbe8020423c8778518612b7e5f7) (From OE-Core rev: 536c477838fb1a318c5b283475de7f0eac99c872) Signed-off-by: Jaeyoon Jung <jaeyoon.jung@lge.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit d4664d2b7974354e73d891762ebb2c8a12d62438) Backported: File was renamed between kirkstone and master. Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-09-23cargo.bbclass: set up cargo environment in common do_compileAlexander Kanavin
cargo_do_compile runs only if the recipe is built using cargo as the top level tool. Some recipes hide usage of cargo inside setuptools (or autoconf) and use do_compile definitions specific to those, and so the environment isn't properly set up. This was exposed by latest versions of python3-cryptography. (From OE-Core rev: a3f566fcbfc02e0a3b3f6a676d6dde88a5b50506) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 9f4ff643a028d7f5670d80861f2ce19ca2d90faa) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-09-23externalsrc: fix dependency chain issuesPeter Suti
Instead of deleting setscene tasks, now SSTATE_SKIP_CREATION is set instead. This seems to fix the compile issues where the populate_sysroot task was not run when an externalsrc recipe was built as a dependency. [YOCTO #15164] [RP addition: The deltask was added by me in 2012 when the class was created. The trouble is bitbake assumes 'sstate' tasks have a setscene task and by deleting the setscene task, bitbake stops thinking the task can be accelerated. There is other code in the sysroot code which assumes some tasks are always sstate tasks. We cannot delete the task without changes to the way bitbake learns about 'setscene' tasks so the patch is correct, avoiding creating files is the better approach given the way the world works now. There would be concerns about exisitng sstate reuse however this shouldn't occur since SRC_URI changes and that will change the underlying hashes. Hash equivalency could potentially cause issues by joining hashes together again however if the output matches, that shouldn't in theory cause any issue.] (From OE-Core rev: f6bb8438a18dfa2a520ad6fa65662d908f4ef0ed) Signed-off-by: Peter Suti <peter.suti@streamunlimited.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit ee4667a24ccdd8c9d547e73aecf661e6a1283890) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-08-26kernel: Fix path comparison in kernel staging dir symlinkingStaffan Rydén
Due to an oversight in the do_symlink_kernsrc function, the path comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code obtains both variables, but modifies the local copy of "S" before comparing them, causing the comparison to always return false. This can cause the build to fail when the EXTERNALSRC flag is enabled, since the code will try to create a symlink even if one already exists. This patch resolves the issue by comparing the variables before they are modified. (From OE-Core rev: cf2267f80ec44b24c627347df7efbd492a07dcfa) Signed-off-by: Staffan Rydén <staffan.ryden@axis.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-08-19npm.bbclass: avoid DeprecationWarning with new pythonMartin Jansa
meta/classes-recipe/npm.bbclass:85: DeprecationWarning: invalid escape sequence '\.' '--transform', 's,^\./,package/,', (From OE-Core rev: a7078ff976ba720f25e94ddeddd3f82900b483be) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-08-02meson.bbclass: Point to llvm-config from native sysrootKhem Raj
Default search in meson would grok /usr/bin for llvm-config and if found will use it, which might add wrong paths into cflags/ldflags, since we depend on llvm-native when building gallium support ( thats when llvm-config is effective), its better to point llvm-config into native sysroot so it can add correct paths into compiler/linker cmdline (From OE-Core rev: 8e6b616066ba0f7f452f929dc7c412e620da9101) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit cc73360b9728812ed6123e30559b77d8e89cc21c) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-08-02uboot-extlinux-config.bbclass: fix old override syntax in commentQuentin Schulz
The comment specifies how to use the variables but uses the older and now unsupported override syntax. Let's update to match the newer syntax. Cc: Quentin Schulz <foss+yocto@0leil.net> (From OE-Core rev: 0a381eea4d50ff1c6e7c7d0d4df62eb581454b48) (From OE-Core rev: 0e9a70ee3c8f78db746d3cb627c6b212e1b4e4e4) Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit bb64f3fed29b9532e6ddc9a2ba0283d373622d87) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-08-02kernel: add missing path to search for debug filesAndrej Valek
Since explicit debug package creation via ${KERNEL_PACKAGE_NAME}-dbg has been added to kernel, it has to cover all PACKAGE_DEBUG_SPLIT_STYLE options. For ex. when the variable "debug-file-directory" package search path has to be set explicitly, otherwise it will not find any files. (From OE-Core rev: 9adbda8450c57f49edf85e3b3433304e8ac8267e) Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 9c39da147683dcaaa244b3ddc4531c4408ad5c9e) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-07-26package.bbclass: moving field data process before variable process in ↵Xiangyu Chen
process_pkgconfig Currently, the latest version abseil-cpp contains a new library named "absl_log_internal_format", it's basic package config(.pc file) as below: prefix=/usr exec_prefix=${prefix} ...... Requires: absl_config = 20230125, absl_core_headers = 20230125, absl_log_internal_append_truncated = 20230125, absl_log_internal_config = 20230125, absl_log_internal_globals = 20230125, absl_log_severity = 20230125, absl_strings = 20230125, absl_str_format = 20230125, absl_time = 20230125, absl_span = 20230125 ...... Normally, the process_pkgconfig() would process variable data before field data in a .pc file, but in the absl_log_internal_format, the field data in "Requires" section contains "xxxx = xxxx" format, the process_pkgconfig() treats them as normal variable and using the setVar() in bitbake's data_smart.py try to process. The absl_log_internal_format field data contains "_append_", this hit the setVar() checking and finally bitbake stop building and reporting an error as below: "Variable xxx contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake." This patch move the field data process before variable process to avoid the process_pkgconfig() treat the field data as variable. (From OE-Core rev: e7d3e02a624f7ce23d012bb11ad1df2049066b37) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> (cherry picked from commit a73e269d3e591a10bb397b94b82e3fb960112d33) Signed-off-by: Clément Péron <peron.clem@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-07-21wic: Add dependencies for erofs-utilsHeiko Thole
In order to build erofs filesystems, wic must have the erofs-utils package installed into its sysroot. (From OE-Core rev: c349c7fcb299b123824da9a13ee58222a6cbf9ec) Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-07-12useradd-staticids.bbclass: improve error messageMikko Rapeli
Current error message is difficult to read: ERROR: Nothing PROVIDES 'image' trs-image was skipped: image - image: normal username test does not have a static ID defined. Add test to one of these files It's not clear that first "image" is recipe name, second "image" is binary package name and that "test" is the user account which does not have a static ID defined. Improve the error message so that these are more explicit. Now the error message looks like: image was skipped: Recipe image, package image: normal username "test" does not have a static ID defined. (From OE-Core rev: 572c507736b2fcc31f7f13cb3da0d5be361838f5) Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit 07898218f3908a83e07178b6530dfa48d55d4ec2) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-07-12image_types: Fix reproducible builds for initramfs and UKI imgFrieder Paape
I've encountered issues reproducing initramfs and UKI image builds, which will be fixed with this patch. 1. initramfs There's a symbolic link to /sbin/init, which is appended to the cpio archive after creation. The links timestamp needs to be static and the cpio append command needs the '--reproducible' flag to produce deterministic outcomes. 2. Unified Kernel Image '--preserve-dates' is required for a static 'Time/Date' entry. I've added '--enable-deterministic-archives' although in my case this didn't change anything. (From OE-Core rev: 0d8890f7c1fbea5036acefa3031dcd442b316725) Signed-off-by: Frieder Paape <frieder@konvera.io> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit fd027729bafb4e085ba0949e38e724f3a8cad102) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-23staging.bbclass: do not add extend_recipe_sysroot to prefuncs of ↵Chen Qi
prepare_recipe_sysroot When running prepare_recipe_sysroot task, the extend_recipe_sysroot is run twice. What prepare_recipe_sysroot does is executing extend_recipe_sysroot, there's no need to add extend_recipe_sysroot to its prefuncs. (From OE-Core rev: dad053c4b99d4aefebe40459500ad53a2b458fa0) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit bf7584a2ac16ee46ff5b41536b06bb46d0cbada7) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-23kernel: don't force PAHOLE=falseBruce Ashfield
If a specific kernel provider or configuration wants to enable BTF and pahole analysis, it isn't currently possible due to the explicit definition to false in the base kernel build arguments. pahole is now detected by the kernel built itself, so unless pahole-native is enabled, the result is the same. If a kernel does require an explicit disable of pahole, it is better to carry PAHOLE=false in those specific recipes. (From OE-Core rev: 44b75c7442b05a2fedcc0d73982566c2bef84357) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit b1e4851a36ed47ce6ba880a49264b9a57c78cf4f) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-23go.bbclass: don't use test to check output from lsMartin Jansa
* avoids possibly confusing error message in log.do_install like: ls: cannot access 'etcd/3.5.7-r0/build/bin/linux_arm64/': No such file or directory (From OE-Core rev: f9b1a56c50a96ad6300a48bf74a540579b352411) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit 2f1777e6ac5269a71203b6a2c562a43503be95ae) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-21cve-update-nvd2-native: new CVE database fetcherMarta Rybczynska
Add new fetcher for the NVD database using the 2.0 API [1]. The implementation changes as little as possible, keeping the current database format (but using a different database file for the transition period), with a notable exception of not using the META table. Minor changes that could be visible: - the database starts in 1999 instead of 2002 - the complete fetch is longer (30 minutes typically) [1] https://nvd.nist.gov/developers/vulnerabilities (From OE-Core rev: b8ae26aabe825c1bc8d84fd7e0ee197695f1dee7) Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> (cherry picked from commit fb62c4c3dbca4e58f7ce6cf29d4b630a06411a97) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-01kernel-devicetree: recursively search for dtbsRandolph Sapp
Upstream's dtb directory structure has no real standard. They just tend to idle around the 2/3 directory depth. Recursively search for the dtb/dtbo files instead of assuming anything. Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb directory, 2023-05-02) (From OE-Core rev: 717b9f18a51e9c9fd5a471238aa2ea4de439ef17) Signed-off-by: Randolph Sapp <rs@ti.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-01package: enable recursion on file globsRandolph Sapp
Enable recursion of file globs. This just allows the use of '**' in file globs to match 0 or more subdirectories, it should not make all current globs recursive [1]. [1] https://docs.python.org/3.6/library/glob.html#glob.glob (From OE-Core rev: 90855ef11e3bd85eea718532f20878b72aa729b4) Signed-off-by: Randolph Sapp <rs@ti.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-01kernel-devicetree: make shell scripts posix compliantMartin Jansa
Use the notation suggested by Martin Jansa to avoid a bashism. Also switch KERNEL_DTBVENDORED to the more common 0/1 notation instead of true/false. Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb directory, 2023-05-02) (From OE-Core rev: b7d6fc07462e6fca09d0db7f43a62920250ef053) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Randolph Sapp <rs@ti.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-06-01kernel-devicetree: allow specification of dtb directoryRandolph Sapp
Fedora/Redhat and Arch are somewhat standardized on their dtb directory structure. Let's add some flags to configure yocto to mimic that behavior. Add the following variables to the kernel class: - KERNEL_DTBDEST (controls the destination directory for dtbs) - KERNEL_DTBVENDORED (controls if vendor subdirectories are to be respected) Currently KERNEL_DTBDEST is expected to be a subdir of KERNEL_IMAGEDEST and KERNEL_DTBVENDORED is expected to be "true"/"false". This only applies to the package directory structure. The deploydir structure is purposely left untouched for compatibility with existing recipes. By default this is configured to behave the same as the current recipe and produce a flat dtb directory at KERNEL_IMAGEDEST. (From OE-Core rev: 77d6118e20751f68ad7104edec8f14dbb5ba6ec1) Signed-off-by: Randolph Sapp <rs@ti.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-05-30license.bbclass: Include LICENSE in the output when it fails to parsePeter Kjellerstedt
(From OE-Core rev: 1dd008511cc62bd32f85b529f8d6031bd57e4cd2) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 1a5197760da3890cc80ac7da8d589766612d9051) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-05-12update-alternatives.bbclass: fix old override syntaxPeter Bergin
Function 'gen_updatealternativesvardeps' still used old override syntax when fetching variable flags. Update to use ':' instead to match recipe meta data. This was found by review and no real issue encountered but it is a bug that affects variable dependencies and can affect rebuilds as task hashes might not be accurate. (From OE-Core rev: d5fd577c066fa2fddbd16c286f2dde2883cc7828) Signed-off-by: Peter Bergin <peter.bergin@windriver.com> Signed-off-by: Peter Bergin <peter@berginkonsult.se> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 5691f554b2cd50f256a8cbb1d96781e9eb6b930e) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-05-12kernel: improve initramfs bundle processing timeBruce Ashfield
This is a partial fix for bugzilla 15059 [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059] It has been noted by several people that when an initramfs is bundled: - a lot of the kernel is rebuilt - it takes a really long time When looking at the logs, the second kernel compilation (that performs the bundle) is not using the parallel make settings, and builds with -j1. We are already explicitly passing PARALLEL_MAKE when building kernel modules, and by extending that explicit use to the main kernel compilation, we ensure that we always get a parallel build. Build times chnaged from more than 30 minutes for the bundle, to 3 minutes in local testing. The question of whether or not too much is rebuilding during the bundle step is still an open question, but with this tweak, at least the build time is back in the realm of acceptable. (From OE-Core rev: a2a889b760785474dbc04e3ec11521f6da90161d) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (cherry picked from commit 88fd394ecf0f2174b792075d409d87046896426b) Signed-off-by: Steve Sakoman <steve@sakoman.com>
2023-05-12populate_sdk_ext.bbclass: set METADATA_REVISION with an DISTRO overrideMartin Jansa
* otherwise it ends '<unknown>' inside esdk, because of parsing order: # $METADATA_REVISION [3 operations] # set /OE/build/test-D/conf/local.conf:43 # "f2da54ef432eac89b0f18eaad68e602b6990b5de" # immediate /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:9 # "${@oe.buildcfg.detect_revision(d)}" # set /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:10 # [vardepvalue] "${METADATA_REVISION}" # pre-expansion value: # "<unknown>" METADATA_REVISION="<unknown>" * This causes base-files.do_install and following tasks to have different signatures between esdk and the build directory where this esdk was created: bitbake-diffsigs {test-D,poky/build-uninative-disabled}/tmp/stamps/qemux86_64-poky-linux/base-files/*do_install*sigdata* NOTE: Starting bitbake server... basehash changed from 5b6981cf58bfd57d416b0e31611b73a26baae635dd1ac31c08d46f95064c3ffc to dbdce042da4d7813d632b6d1cc87a16f728ad20e55fecbc392830e6acf72babd Variable METADATA_REVISION value changed from '<unknown>' to 'f2da54ef432eac89b0f18eaad68e602b6990b5de' and an warning from "python3 /OE/build/test-D/ext-sdk-prepare.py" when eSDK is being prepared for use: WARNING: The base-files:do_install sig is computed to be 83b9c9a6ef1145baac5a1e0d08814b9156af239c58fc42df95c25a9cd8a7f201, but the sig is locked to 3dc22233059075978e5503691e98e79e7cc60db94259dfcd886bca2291c0add7 in SIGGEN_LOCKEDSIGS_t-qemux86-64 [RP: Add commit about why we need the override for future reference] (From OE-Core rev: da6f6340f97e80cb1b21f6083ef5d0a9a856eef5) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (cherry picked from commit 675ea7281c17f77bf5dea17cfd4d9da0928382a0) Signed-off-by: Steve Sakoman <steve@sakoman.com>