vim: do not report upstream version check as broken
As upstream tags point releases with every commit and
the version check still reports 8.2, it should not be considered
broken (e.g. current version newer than latest version)
until 8.3 is released.
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Konrad Weihmann [Tue, 14 Dec 2021 16:39:20 +0000 (17:39 +0100)]
insane: move src-uri-bad checks to unpack stage
previously used package_qa_check_src_uri was triggered during
package_qa stage, which implies having packages.
This isn't the case for native-only recipes or recipe that inherit
nopackages.
Still the checks performed (src-uri-bad) apply to those as well.
Therefore move the check from package_qa stage to unpack stage.
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Tue, 14 Dec 2021 12:34:04 +0000 (12:34 +0000)]
lttng-tools: Disable problem tests
There is a pattern of the notification tests hanging. Whilst we need to get to the
bottom of that, disable them for now as it is causing high load for triage/SWAT
and masking other failures.
[YOCTO #14263]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Quentin Schulz [Mon, 13 Dec 2021 09:16:28 +0000 (10:16 +0100)]
mesa: make ligles3-dev RDEPENDS on libgles2-dev
Khronos documentation[1] says that include/GLES2/gl2ext.h can be used
for OpenGL ES 3 specification as well as for OpenGL ES 2.
There can be applications including GLES2/gl2ext.h instead of
GLES3/gl3ext.h meaning we should probably bring in GLES2/gl2ext.h if
someone asks for development package of libgles3.
Quentin Schulz [Mon, 13 Dec 2021 09:16:27 +0000 (10:16 +0100)]
kmscube: add build dependency on virtual/libgles3
texturator requires GLES 3 headers and libs so let's explicit this
dependency. This was not detected until now because mesa, the default
provider, actually provides both Open GLES 2 and 3 compliant
implementations.
Quentin Schulz [Mon, 13 Dec 2021 09:16:26 +0000 (10:16 +0100)]
mesa: PROVIDES virtual/libgles3
It's assumed that not all OpenGL ES implementation are compliant with
the 3.x specification. Therefore an additional virtual providers is
created to explicit compatibility with OpenGL ES 3 specification.
Quentin Schulz [Mon, 13 Dec 2021 09:16:25 +0000 (10:16 +0100)]
kmscube: fix build on OpenGL ES 3 dependencies not providing GLES3/gl3ext.h
According to Khronos documentation[1], gl2ext.h can be used for OpenGL
ES 3. Some vendor implementation of OpenGL ES 3, such as
Rockchip's libmali[2], do not have a gl3ext.h but only a gl2ext.h while
being OpenGL ES 3 compliant.
This fixes the header files to be included from gl3ext.h to gl2ext.h to
be compatible with (hopefully) all OpenGL ES 3 implementations.
# /sbin/bootchartd stop
[bootchart] bootchart-collector started as pid 596 with 2 args:
[bootchart] '--dump'
[bootchart] '/tmp/bootchart.3lXpVDAq3v'
[bootchart] Extracting profile data from pid 204
[bootchart] map 0xbed9a000 -> 0xbedbb000 size: 132k from 'bed9a000' 'bedbb000'
[bootchart] read 135168 bytes of 135168
[bootchart] reading 150 chunks (of 150) ...
[bootchart] wrote 18760 kbB
[bootchart] bootchart-collector pid: 596 unmounted proc / clean exit
But there still one process exist after the above stop command finish.
# ps -ef | grep bootchartd
root 202 1 0 09:09 ? 00:00:00 /bin/sh /sbin/bootchartd
root 629 516 0 09:10 ? 00:00:00 grep bootchartd
Remove the wait_boot which used to wait the boot process to finish to
make sure only one bootchartd process and meanwhile we don't need the
wait_boot logic because we either use "/sbin/bootchartd stop" to stop
the bootchartd manually or install package bootchartd-stop-initscript
altogether with bootchart2 to stop bootchartd automatically after boot.
wangmy [Mon, 13 Dec 2021 13:16:11 +0000 (21:16 +0800)]
python3-cython: upgrade 0.29.24 -> 0.29.25
Changelog:
================
Bugs fixed
----------
* Several incompatibilities with CPython 3.11 were resolved.
(Github issues #4411, #4414, #4415, #4416, #4420, #4428, #4473, #4479, #4480)
* Some C compiler warnings were resolved.
(Github issue #4439)
* C++ "std::move()" should only be used automatically in MSVC versions that support it.
(Github issue #4191)
* The "Py_hash_t" type failed to accept arbitrary "index" values.
(Github issue #2752)
* Avoid copying unaligned 16-bit values since some platforms require them to be aligned.
Use memcpy() instead to let the C compiler decide how to do it.
(Github issue #4343)
* Cython crashed on invalid truthiness tests on C++ types without "operator bool".
(Github issue #4348)
* The declaration of "PyUnicode_CompareWithASCIIString()" in "cpython.unicode" was incorrect.
(Github issue #4344)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wangmy [Mon, 13 Dec 2021 13:19:38 +0000 (21:19 +0800)]
mpg123: upgrade 1.29.2 -> 1.29.3
Changelog:
====================
libmpg123: Catch more NULL pointer arguments in LFS wrappers
(most prominently: mpg123_feedseek(), bug 328).
mpg123:
-Fix regression that did _not_ enable --remote-err on -s anymore.
-Fix typos in man page.
-Drop mixed-up value limits on remote control SEQ command.
It is up to you if you want to distort your sound.
-Add note about equalizer frequency bands to man page.
-build: add BUILD_PROGRAMS option to ports/cmake
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton [Fri, 10 Dec 2021 14:22:39 +0000 (14:22 +0000)]
apr: remove obsolete support for renamed libtool
libtool is now longer renamed to ${host}-libtool, so remove the changes
to support this.
This means that apr now installs libtool into the build-1 folder, but
as this has never been needed before (as we use the system libtool) we
can remove it (it contains build paths so is unreproducible). Also add
a RDEPENDS on libtool for the target -dev package.
Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton [Fri, 10 Dec 2021 14:22:33 +0000 (14:22 +0000)]
libtool: don't prefix the installed binary
Typically libtool installs the binary to 'libtool' in the source tree,
but we've got patches to rename this to ${host_sys}-libtool. As this
isn't standard any upstream that don't respect the LIBTOOL variable need
to be told explicitly where libtool is, which is a long-term maintenance
burden for us on top of the initial libtool patches.
The reasoning for this renaming appears to stem from the design to be
sure that we're using our new/patched libtool and not the host's binary.
However, now that we have HOSTTOOLS, there's no way to run the host
libtool so this argument is moot.
This patch removes the libtool renaming, follow-up patches remove the
required modifications from the rest of the recipes.
[RP: Remove commented patch lines] Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Valerii Chernous [Fri, 10 Dec 2021 17:53:37 +0000 (19:53 +0200)]
elf: Discard input .note.gnu.build-id sections
Originally issue:
building of glibc 2.32 or 2.34 with option "-Wl,--build-id"
produce libc.so.6 with section ".note.gnu.build-id" that have
invalid(double, 0x48) section size. It happens because glibc
use sublibraries for linking libc.so.6
ld produce this sublibraries with build-id section and on last
linking stage loads this sections as input for linking.
ld should create new(valid) ".note.gnu.build-id" into function
ldelf_setup_build_id on last linking stage but it skip creating because
build-id section already exists.
As result libc.so.6 contain ".note.gnu.build-id" with build-ids from
sublibraries and without valid build-id
Howto solved:
1. Discard input .note.gnu.build-id sections.
2. Clear the build ID field before writing.
3. Use bfd_make_section_anyway_with_flags to create the output
.note.gnu.build-id section.
This class provides an image feature that mounts /etc as an overlayfs
file system. This is an extension for existing overlayfs class, which
doesn't support /etc
Signed-off-by: Alfred Schapansky <alfred.schapansky@avantys.de> Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Joshua Watt [Fri, 10 Dec 2021 15:38:34 +0000 (09:38 -0600)]
epiphany: Add packageconfig for libsoup2
Adds a PACKAGECONFIG option to use libsoup2 instead of libsoup3.
Including libsoup2 and libsoup3 in the same process can cause strange
runtime failures, and the latest release of each major version will
cause the process to exit if both are detected on startup.
The default is changed from libsoup3 back to libsoup2 to follow
webkitgtk.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Joshua Watt [Fri, 10 Dec 2021 15:37:41 +0000 (09:37 -0600)]
webkitgtk: Add packageconfig for libsoup2
Adds a PACKAGECONFIG option to use libsoup2 instead of libsoup3.
Including libsoup2 and libsoup3 in the same process can cause strange
runtime failures, and the latest release of each major version will
cause the process to exit if both are detected on startup.
The default is changed from libsoup3 back to libsoup2. Most GNOME
packages are still using libsoup2, and a large number of these pull in
webkitgtk either directly or indirectly. If webkitgtk uses libsoup3,
this causes all of these packages to fail at startup. It appears that
most GNOME packages will have to switch to libsoup3 when they transition
to GTK4.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mike Crowe [Tue, 7 Dec 2021 15:27:36 +0000 (15:27 +0000)]
documentation: Document PACKAGE_SNAP_LIB_SYMLINKS
PACKAGE_SNAP_LIB_SYMLINKS was added[1] originally to OpenEmbedded in
2008 and then to oe-core in 2011[2] but appears to have evaded
documentation throughout that time. Let's add something that at least
gives some clue as to what it does.
Mike Crowe [Tue, 7 Dec 2021 15:27:35 +0000 (15:27 +0000)]
package: Only snap libraries if they would be processed by ldconfig OS-12840
PACKAGE_SNAP_LIB_SYMLINKS renames libraries based on their SONAME so
that they can be found directly rather than going via symlinks that
would be created by ldconfig. For example, without
PACKAGE_SNAP_LIB_SYMLINKS in ${libdir} we have:
but with PACKAGE_SNAP_LIB_SYMLINKS="1" we have just:
libharfbuzz.so.0
Unfortunately, this renaming is done based on the SONAME which breaks
packages like mesa which install a single library with multiple hard
links:
-rwxr-xr-x root/root 13593488 2021-12-07 12:26 ./usr/lib/dri/i915_dri.so
-rwxr-xr-x root/root 13137328 2021-12-07 12:26 ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/iris_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/kms_swrast_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/nouveau_vieux_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/r200_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/radeon_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/i915_dri.so
The SONAME for i915_dri.so (and therefore all the other names that link
to the same file) is libgallium_dri.so. This means that
PACKAGE_SNAP_LIB_SYMLINKS causes do_package to successfully rename the
first name found to libgallium_dri.so. A similar thing happens to
i965_dri.so with its SONAME of libmesa_dri_drivers.so. The order is not
deterministic, so this means that although every build will be missing
one name, it's not always the same one.
-rwxr-xr-x root/root 13593488 2021-11-30 15:17 ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/kms_swrast_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/libgallium_dri.so link to ./usr/lib/dri/i915_dri.so
-rwxr-xr-x root/root 13137328 2021-11-30 15:17 ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/nouveau_vieux_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/r200_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/radeon_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/i915_dri.so
This renaming means that the library cannot be found at runtime.
The simplest way to avoid this renaming is to only snap libraries that
would be processed by ldconfig.
Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Phil Blundell <pb@pbcl.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changqing Li [Wed, 8 Dec 2021 02:33:27 +0000 (10:33 +0800)]
cmake: upgrade 3.22.0 -> 3.22.1
This upgrade include a bug fix:
Refer:
https://gitlab.kitware.com/cmake/cmake/-/issues/22963
https://gitlab.kitware.com/cmake/cmake/-/commit/643fc46bdc13dd57584d5d77eee30a99308ba896
Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mingli Yu [Wed, 8 Dec 2021 08:13:21 +0000 (16:13 +0800)]
libhandy: Backport a makefile header race
After the commit(8157ecc Separate public and private enums) introduced,
there comes a race as below:
| In file included from ../git/src/hdy-settings.c:11:
| ../git/src/hdy-settings-private.h:16:10: fatal error: hdy-enums-private.h: No such file or directory
| 16 | #include "hdy-enums-private.h"
So also add private headers like private sources did now to libhandy_sources
to fix the issue.
Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before the patch:
# ./run-xtests.sh . tst-pam_access1
mv: cannot stat '/etc/security/opasswd': No such file or directory
PASS: tst-pam_access1
mv: cannot stat '/etc/security/opasswd-pam-xtests': No such file or directory
==================
1 tests passed
0 tests not run
==================
After the patch:
# ./run-xtests.sh . tst-pam_access1
PASS: tst-pam_access1
==================
1 tests passed
0 tests not run
==================
Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Thu, 9 Dec 2021 17:22:55 +0000 (17:22 +0000)]
binutils: Drop mips XLP support patch
The kernel has dropped this as of 5.16 and we don't want to carry such patches
without active maintainers for such targets.
It isn't clear who would even have such hardware and it isn't something we can
support. It would be best maintained as a separate layer by those who can test
it if needed.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Markus Volk [Sat, 11 Dec 2021 16:35:21 +0000 (17:35 +0100)]
libva: move PACKAGECONFIG options to libva.inc
This fixes an error in libva-initial build if 'systemd' is in DISTRO_FEATURES
and libdrm is set to be built with udev support.
| Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
| Run-time dependency wayland-client found: YES 1.19.0
| Program wayland-scanner /usr/bin/wayland-scanner found: NO
|
| ../libva-2.13.0/meson.build:107:4: ERROR: Program 'wayland-scanner /usr/bin/wayland-scanner' not found
|
| A full log can be found at /home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
| ERROR: meson failed
| WARNING: exit code 1 from a shell command.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Thomas Perrot [Wed, 27 Oct 2021 14:04:12 +0000 (16:04 +0200)]
uboot-sign: fix the concatenation when multiple U-BOOT configurations are specified
Some BSPs, especially those of meta-freescale and meta-ti allow to build U-Boot
binaries using different configuration for a given target, for example:
- UBOOT_CONFIG ??= "tfa-secure-boot tfa"
- UBOOT_CONFIG ??= "nand sdcard spi nor"
When this is the case the public key wasn't concatenated to all U-Boot binaries
built.
Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Mike Crowe [Thu, 7 Oct 2021 13:17:57 +0000 (14:17 +0100)]
kernel: improve transformation from KERNEL_IMAGETYPE_FOR_MAKE
In 526bdd88ccd758204452579333ba188e29270bde the imageType loop in
kernel_do_deploy was changed to use KERNEL_IMAGETYPE_FOR_MAKE rather
than KERNEL_IMAGETYPES. This broke the special handling for fitImage
immediately below because KERNEL_IMAGETYPE_FOR_MAKE never contains
fitImage.
It has always been my understanding that KERNEL_IMAGETYPE_FOR_MAKE
controlled what was passed to make, but KERNEL_IMAGETYPE controlled what
was installed/deployed. When the two are different then it's the
responsibility of whoever set KERNEL_IMAGETYPE_FOR_MAKE to ensure that
whatever comes out of the kernel build system has been transformed in to
the requested form by the time of installation. This is what happens for
kernel.bbclass's own support for vmlinux.gz.
I think this means that for KERNEL_IMAGETYPE vmlinux.gz, kernel.bbclass
is responsible for generating vmlinux.gz.initramfs[1] so that
kernel_do_deploy can deploy it. This means that the change in 526bdd88ccd758204452579333ba188e29270bde can be reverted, fixing
KERNEL_IMAGETYPE = "fitImage".
In addition, it ought to be possible for recipes and other classes that
use kernel.bbclass to hook into this mechanism by setting
KERNEL_IMAGETYPE_FOR_MAKE and performing their own transformations.
do_bundle_initramfs calls kernel_do_compile and we don't want it to
transform vmlinux to vmlinux.gz at that point, since it will fight
against the careful renaming and preserving that do_bundle_initramfs
does. Let's separate the transformation out of kernel_do_compile to a
new do_transform_kernel task that can be run at the right time. This
means that it's also logical to perform the equivalent translation for
the kernel with the initramfs in a separate
do_transform_bundled_initramfs task too.
This leaves two clear customisation points for recipes and other classes
to hook into the process and perform their transformations:
do_transform_kernel and do_transform_bundled_initramfs.
(I care about this because our recipes that use kernel.bbclass also set
KERNEL_IMAGETYPE_FOR_MAKE and transform vmlinux into a form suitable for
our bootloader after do_compile and do_bundle_initramfs into the format
matching KERNEL_IMAGETYPE. I'm unable to successfully bundle an
initramfs after 526bdd88ccd758204452579333ba188e29270bde, but I didn't
want to just revert that change to reintroduce the bug that it was
fixing.)
I can't say that I'm entirely happy with this change, but I'm unsure
what to do to improve it. I find the way that both the bare kernel and
the one with the initramfs both get deployed to be confusing, and a
waste of build time. I would like to not actually generate a publishable
kernel image at all during do_compile when an initramfs is in use, but I
suspect that this would affect valid use cases that I'm not aware of.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
[1] It could be argued that this should be vmlinux.initramfs.gz, but
that would require another special case in kernel_do_deploy and the
filename is only visible within this class and the recipes that use it
anyway.
License-Update: GPL2 license for cli tool moved to a separate file Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Wed, 8 Dec 2021 23:51:32 +0000 (23:51 +0000)]
puzzles: Refresh patches based upon upstream discussion
I mentioned these patches to upstream and this cleans them up based upon
our discussion with better fixes, fixed comments and tracking down the correct
issue in the malloc case.
If we can test and confirm them in this form, we should be in a good position
to resovle the issues with upstream and be able to drop the patches ultimately.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bruce Ashfield [Tue, 7 Dec 2021 16:52:07 +0000 (11:52 -0500)]
linux-yocto-rt/5.10: update to -rt56
Integrating the following commit(s) to linux-yocto-rt/5.10:
23f3ad608bc7 rcutorture: fixup merge from standard/base -stable 8612be3f3e2b Revert "rcutorture: Avoid problematic critical section nesting on RT" 9a6fb5667ac8 Linux 5.10.78-rt56 78c80dca8b1f irq_work: Also rcuwait for !IRQ_WORK_HARD_IRQ on PREEMPT_RT e91d3b98e3b3 irq_work: Handle some irq_work in a per-CPU thread on PREEMPT_RT bded6a156d4e irq_work: Allow irq_work_sync() to sleep if irq_work() no IRQ support. 747c881d3348 drm/i915/gt: Queue and wait for the irq_work item. fa4ef0011e58 locking: Drop might_resched() from might_sleep_no_state_check() f44d86bc5923 fscache: Use only one fscache_object_cong_wait. 2da5bc42a911 fscache: Use only one fscache_object_cong_wait. 53ecacfc9c68 mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT 03bdef3c5563 preempt: Move preempt_enable_no_resched() to the RT block 0def39751031 sched: Switch wait_task_inactive to HRTIMER_MODE_REL_HARD 60df07c6bd86 sched: Fix get_push_task() vs migrate_disable() 27f8594efeac mm, zsmalloc: Convert zsmalloc_handle.lock to spinlock_t 3fcbcd86a8eb Linux 5.10.78-rt55
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bruce Ashfield [Tue, 7 Dec 2021 16:52:06 +0000 (11:52 -0500)]
linux-yocto-dev: use versioned branch as default
The -dev kernel used to only have standard/* branches, which were
managed similarly to linux-next. Which means, they are for testing
integration of patches, and are rebased as needed (typically on
version changes).
We now do some leading edge BSP development on the -dev kernel,
so the standard/* branches are not deleted, but are instead
archived with a version prefix v<kernel version>/standard/*
The branch renaming causes problems for maintained releases
(they'll jump forward to newer kernels), and for anything that
wants to specify a particular commit (-dev is AUTOREV by
design).
There's no reason why the branches can't start versioned at
this point, and that solves both problems. So we switch our
default branch to v5.16/standard/base now, and it will be
updated with each new version (we bump the version anyway).
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
