Commit c07aafa087 (package/Makefile.in: set GIT_DIR=. in {HOST,
TARGET}_MAKE_ENV) added GIT_DIR=. to TARGET_MAKE_ENV (which is included in
TARGET_CONFIGURE_OPTS) to work around issues with packages getting confused
when building in a subdir of the Buildroot git repo.
This unfortunately also causes git commands to fail when
output/host/environment-setup is sourced:
git status
fatal: not a git repository: '.'
So strip GIT_DIR= from TARGET_CONFIGURE_OPTS when generating
environment-setup.
Reported-by: Mircea Gliga <gliga.mircea@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 48874afb9d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure without gbm raised since commit
534c22dd60:
Message: dmabuf-feedback requires gbm which was not found. If you rather not build this, drop "dmabuf-feedback" from simple-clients option.
Move the option assignment further down, below all the simple-clients
lists; in Makefile, and because we are usign simply expanded variables,
this is not necessary, but it is easier on us humans when we review the
code.
Also add a comment explaining why the initial list is incomplete.
Fixes:
- http://autobuild.buildroot.org/results/ebbba1d73ceeaacee17fde0c6c853415cd316091
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 611c0cb198)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The NuGet packaging description file is installed as:
$(DEST_DIR)/build/native/hiredis.targets
This is a sprurious file that has nothing to do on a Linux system,
whether that be in host/, staging/, or target/.
Backport an upstream patch to get rid of it.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
(cherry picked from commit 52f3793d46)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This was added upstream in commit:
22e4c03866
The 'USE_OPENGL_OR_ES' flag is default ON, which will enable 'USE_GBM',
so ensure that we unset 'USE_GBM' if we don't have libgbm.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Tested-by: Adrian Perez de Castro <aperez@igalia.com>
Acked-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit c06c0197f9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
1) CVE-2023-6816 can be triggered by passing an invalid array index to
DeviceFocusEvent or ProcXIQueryPointer.
2) CVE-2024-0229 can be triggered if a device has both a button and a
key class and zero buttons.
3) CVE-2024-21885 can be triggered if a device with a given ID was
removed and a new device with the same ID added both in the same
operation.
4) CVE-2024-21886 can be triggered by disabling a master device with
disabled slave devices.
5) CVE-2024-0409 can be triggered by enabling SELinux
xserver_object_manager and running a client.
6) CVE-2024-0408 can be triggered by enabling SELinux
xserver_object_manager and creating a GLX PBuffer.
For details, see the advisory:
https://lists.x.org/archives/xorg-announce/2024-January/003444.html
Switch to .tar.gz as the announcement mail only contained hashes for that:
https://lists.x.org/archives/xorg-announce/2024-January/003442.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 219178ef3e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
1) CVE-2023-6816 can be triggered by passing an invalid array index to
DeviceFocusEvent or ProcXIQueryPointer.
2) CVE-2024-0229 can be triggered if a device has both a button and a
key class and zero buttons.
3) CVE-2024-21885 can be triggered if a device with a given ID was
removed and a new device with the same ID added both in the same
operation.
4) CVE-2024-21886 can be triggered by disabling a master device with
disabled slave devices.
5) CVE-2024-0409 can be triggered by enabling SELinux
xserver_object_manager and running a client.
6) CVE-2024-0408 can be triggered by enabling SELinux
xserver_object_manager and creating a GLX PBuffer.
For details, see the advisory:
https://lists.x.org/archives/xorg-announce/2024-January/003444.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b8d9e75eb8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit e88823d667 (package/refpolicy: fix build with smartmontools) added
a 0001-policy-modules-services-smartmon.te-make-fstools-opt.patch patch, but
forgot to put it in the version specific sub directory - Breaking builds
using BR2_PACKAGE_REFPOLICY_CUSTOM_GIT as shown by the TestSELinuxCustomGit
test:
>>> refpolicy RELEASE_2_20200818 Extracting
gzip -d -c /builds/buildroot.org/buildroot/test-dl/refpolicy/refpolicy-RELEASE_2_20200818-br1.tar.gz | tar --strip-components=1 -C /builds/buildroot.org/buildroot/test-output/TestSELinuxCustomGit/build/refpolicy-RELEASE_2_20200818 -xf -
>>> refpolicy RELEASE_2_20200818 Patching
Applying 0001-policy-modules-services-smartmon.te-make-fstools-opt.patch using patch:
patching file policy/modules/services/smartmon.te
Hunk #1 FAILED at 143.
1 out of 1 hunk FAILED -- saving rejects to file policy/modules/services/smartmon.te.rej
make[1]: *** [package/pkg-generic.mk:241: /builds/buildroot.org/buildroot/test-output/TestSELinuxCustomGit/build/refpolicy-RELEASE_2_20200818/.stamp_patched] Error 1
https://gitlab.com/buildroot.org/buildroot/-/jobs/5929796183
Fix it by moving the patch to a versioned sub directory.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit bde468127c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
see CVE-2024-0553: Fix more timing side-channel inside RSA-PSK key exchange
see CVE-2024-0567: Fix assertion failure when verifying a certificate chain with a cycle of cross signatures
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b136bed2fd)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The help text is currently copy and pasted from the gstreamer video
player plugin help text. Change it to reflect the text from the
CMakeLists.txt file.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 7437cad018)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 99a50a8c98 (package/flutter-pi: new package) erroneously made
the gstreamer-based audio plugin depend on GLES, although there is no
such requirement defined in the CMakeLists. This error was likely due to
a copy/paste mistake.
Remove the requirement.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: reword commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 07c1329814)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since the addition of the package
in commit 6aa1bc3167:
In file included from /home/buildroot/autobuild/run/instance-3/output-1/build/vulkan-loader-1.3.262/loader/extension_manual.h:24,
from /home/buildroot/autobuild/run/instance-3/output-1/build/vulkan-loader-1.3.262/loader/extension_manual.c:23:
/home/buildroot/autobuild/run/instance-3/output-1/host/aarch64-buildroot-linux-gnu/sysroot/usr/include/vulkan/vulkan.h:71:10: fatal error: X11/extensions/Xrandr.h: No such file or directory
71 | #include <X11/extensions/Xrandr.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/55ddfd44393e3bcc2f25bad2f9ecb7e1b142a985
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Tested-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 3b8b1125ad)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The variable should be a YES/NO value, FALSE is not a valid value.
E.g. the yesno-to-bool cmd does not translate a FALSE value and therefore returns invalid JSON.
Signed-off-by: Maximilian Senftleben <maximilian.senftleben@frogblue-tec.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 9fa01e3097)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The MICROPYTHON_MAKE_ENV variable contained two things;
- the comon target environment variables CC, CFLAGS et al. defined in
TARGET_MAKE_ENV,
- the GIT_DIR workaround
Commit 9024e18665 (package/micropython: drop GIT_DIR=. workaround)
totally dropped the assignment to MICROPYTHON_MAKE_ENV, but did not
replace its expansin with TARGET_MAKE_ENV.
This yields build error like:
LINK build-standard/micropython
arm-linux-gcc: ERROR: unsafe header/library path used in cross-compilation: '-L/usr/lib64/../lib64'
Fix this by expanding TARGET_MAKE_ENV in lieu of MICROPYTHON_MAKE_ENV.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 6c9be611a8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
See release notes (https://github.com/redis/redis/blob/7.2.4/00-RELEASENOTES):
================================================================================
Redis 7.2.4 Released Tue 09 Jan 2024 10:45:52 IST
================================================================================
Upgrade urgency SECURITY: See security fixes below.
Security fixes
==============
* (CVE-2023-41056) In some cases, Redis may incorrectly handle resizing of memory
buffers which can result in incorrect accounting of buffer sizes and lead to
heap overflow and potential remote code execution.
Bug fixes
=========
* Fix crashes of cluster commands clusters with mixed versions of 7.0 and 7.2 (#12805, #12832)
* Fix slot ownership not being properly handled when deleting a slot from a node (#12564)
* Fix atomicity issues with the RedisModuleEvent_Key module API event (#12733)
Signed-off-by: Titouan Christophe <titouanchristophe@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5f59c175a4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Remove and create the kernel_blob.bin file in the flutter_assets directory:
When Flutter compiles the source code, it creates the kernel_blob.bin file,
a Dart Kernel Bytecode of the application.
If kernel_blob.bin exists inside the flutter_assets directory, then the
application source code can be extracted with nothing more than apktool.
Not only is this a security risk, it's also redundant and a waste of space.
Removing the kernel_blob.bin file generated for flutter-gallery saves 86M!
Because this package is a reference package, and some applications may check
if the kernel_blob.bin file exists, we also touch a blank kernel_blob.bin
file.
Do not use relative symlinks:
Users may install their applications in any arbitaryt location, not
necessarily in the /usr/share/flutter/${package_name} directory. Because
flutter-gallery is a reference application, using exact symlinks to
icudtl.dat and libflutter_engine.so is preferable.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 0805b8048f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As the flutter-gallery package is a reference package for users wishing to use
Flutter for their UX with Buildroot, this package must have the correct build
options. Indeed, this package currently starts and runs, but only because of
the 0001-remove-GetStorage.patch. Through testing, flutter-gallery fails to
run during the following scenario:
- The xdg-user-dirs package is ported and present.
- flutter-gallery depends on xdg-user-dirs.
- The 0001-remove-GetStorage.patch file is removed.
After extensive testing and comparing the current build arguments against what
the meta-flutter repository for Yocto passes to all of the applications that
inherit flutter-app, it is clear that handling the dart_plugin_registrant.dart
file is missing from the dart arguments in the flutter-gallery build step.
As the documentation for the dart_plugin_registrant.dart file is nonexistent
in any official documentation. However, there is a comment from an issue on
the official dart-lang/sdk page on Github that explains what this file is
(and refers to the Dark SDK source code instead of official documentation.)
From https://github.com/dart-lang/sdk/issues/52506#issuecomment-1562806787:
```
The dart_plugin_registrant.dart is a very special file. It's neither included
in the Dart app nor any dependent packages. Rather it's an artificially
created file by the flutter tools. It contains logic to run plugin
registration logic.
A flutter build will eventually compile the Dart application where it will add
<dir>/.dart_tool/flutter_build/dart_plugin_registrant.dart as an extra source
file (see here). Additionally it will also inject that uri as a constant into
Dart source code via a -Dflutter.dart_plugin_registrant=<uri>.
Once the app runs it will access the
package:flutter/src/dart_plugin_registrant.dart:dartPluginRegistrantLibrary
constant and use it to look up the library object and then invoke the plugin
registration logic.
```
Now that what the dart_plugin_registrant.dart does is understood, we need to
pass the following to the dart binary during the flutter-gallery build step:
-Dflutter.dart_plugin_registrant=file://[...]/dart_plugin_registrant.dart:
Injects a file containing the logic to run the plugin registration logic as
a constant into the flutter-application source code.
--source file://$(@D)/.dart_tool/flutter_build/dart_plugin_registrant.dart:
Adds the dart_plugin_registrant.dart file as a source file to compile.
--source package:flutter/src/dart_plugin_registrant.dart:
Binds the plugin implementation to the platform interface based on the
configuration of the app's pubpec.yaml, and the plugin's pubspec.yaml.
The native_assets.yaml file provides the native-assets mapping for
@Native external functions. The flutter-gallery package has no functions
marked as @Native; however, calling "flutter build bundle" creates a blank
template "native_assets.yaml" file, which is safe to include in the build.
This line, while not necessary for flutter-gallery, may be helpful for other
users who use @Native external functions in their applications, and this
example makes porting other applications quicker and easier.
Finally, there is a known issue when using the dart_plugin_registrant.dart
file outlined here: https://github.com/flutter/flutter/issues/137972.
To summarize: If a user fails to pass the --obfuscate flag to gen_snapshsot
when using the dart_plugin_registrant.dart file, their application may fail
to start. One such application is Gallery, which I have independently verified.
As such, pass the --obfuscate flag to gen_snapshot to ensure that
flutter-gallery properly starts when building with the additional
dart_plugin_registrant.dart arguments above.
However, I acknowledge that the obfuscate flag hides function and class names
in compiled Dart code, and there are some cases when a user should avoid using
the flag. For example, when using the runtimeType API:
https://api.flutter.dev/flutter/dart-core/Object/runtimeType.html. However,
this is not the case with flutter-gallery, and the --obfuscate flag is needed.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: restore FLUTTER_RUNTIME_MODES]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit a821aee2d2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To make the next patch easier to understand, add a configure step to the
flutter-gallery.mk file. The `$(HOST_FLUTTER_SDK_BIN_FLUTTER) build bundle`
command is placed in the configure step because it generates several files
needed for the flutter_gen_snapshot tool to generate the target .so file.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 562ed3dfd4)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The canonical name for the 'pub' action is 'pub', while 'packages' is
just an alias. Switch to using the canonical name.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: split off to its own commit]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1cc2c4bb86)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As Yann mentioned in commit 9d8497e79d, a
dependency on a glibc toolchain implies a dependency on
BR2_TOOLCHAIN_HAS_THREADS_NPTL. As such, remove the dependency from
package/flutter-engine/Config.in.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 019cfcfc4a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The current depot-tools version is from Jul 13 2023, and there is a bug
where when building with PPD enabled, building a Flutter application on
my laptop running Fedora 39 or even in the Debian 11 container fails due
to permission issues when running rsync such as:
/usr/bin/sed: couldn't open temporary file [...]/output/per-package/flutter-gallery/host/share/flutter/sdk/.vpython-root/0e1e32/lib/python3.8/sed763MrF: Permission denied
make: *** [package/pkg-generic.mk:267: [...]/output/build/flutter-gallery-2.10.2/.stamp_configured] Error 123
After several hours of attempting to find the exact cause of the issue
by parsing git logs of the depot_tools repository and cross-referencing
bugs on https://bugs.chromium.org/p/chromium/issues I am unable to
determine the exact reason why the problem occurs or the exact commit
that fixes the issue.
However, updating depot-tools does indeed fix the issue, and looking at
the source code between 4e87f5bf and 8d14454b shows improvements to
several bash scripts, such as gclient, vpython3, and spid. All of which
could be culprits of this bug. As flutter-engine is the only package
that uses host-depot-tools, it is safe to update.
This permission bug is present on PPD and normal builds, but causes a
build to crash only on PPD because of rsyncing. On non-ppd builds, the
bug only causes some minor annoyance when trying to run `make clean`
because permission denials crop up when trying to remove the
.vpython-root directory.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr:
- copy the cover-letter description as commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2b7b68cfe5)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When running the command "flutter pub get," the plugins are stored in the
pub-cache directory along with their sha256sum hashes. The default location of
the pub-cache directory is current $(HOST_DIR)/share/flutter/sdk/.pub-cache,
which is not an acceptable choice by default because every plugin is
re-downloaded during every build of a flutter application either during a new
build or when building with the per-package-directory option enabled.
Furthermore, keeping the pub-cache in its current location prevents users from
committing the pub-cache directory to git for faster rebuilds of a
Buildroot-based system, as users cannot store the pub-cache for later use.
To fix the above issue completely, the following two changes must occur:
- Change the hard-coded Flutter pub-cache location to
$(DL_DIR)/br-flutter-pub-cache.
- Remove the `rm -rf $(HOST_FLUTTER_SDK_BIN_SDK)/.pub-cache` and the
associated comment about why the build system removes the .pub-cache
directory. After further research, the help text of the precache command
reads, "Populate the Flutter tool's cache of binary artifacts."
The current reasoning listed in the comments is not accurate for a
the following reasons:
1. We do not want to remove their directory if users already have a pub
cache they have symlinked to.
2. If the flutter-sdk-bin package previously set up the pub-cache, then
the pub-cache directory is set up with the options we want, and there
is no reason to remove the pub-cache directory.
Note that upstream considers it safe to have multiple instances of
readers/writers to the pub cache concurently, which is a situation that
can happen when two flutter-based pacakges are going to be built in
parallel. There have been reports upstream [0] [1] [2] where concurrency
was an issue, and they have always been fixed [3] [4] (or considered
fixed already). So we can assune that, if the conncurrent ccess to the
shared pub-cache causes issues, that will be an upstream bug that will
get solved.
If that turns out to be an unsolvable problem, we'll still have the
option to run the pub-get commands under flock.
[0] https://github.com/dart-lang/pub/issues/1178
[1] https://github.com/dart-lang/pub/issues/3404
[2] https://github.com/dart-lang/pub/issues/3420
[3] https://github.com/dart-lang/pub/issues/1178#issuecomment-1006489414
[4] https://github.com/dart-lang/pub/issues/1178#issuecomment-1007273739
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: add blurb about concurrent access]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 37809258fc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As found out by Yann E. Morin in [1], apcupsd configure script is ugly,
and uses gcc to do the link line-wrapping which will raise the following
build failure with gcc 13:
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/bin/ld: /home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/lib/../lib64/libsupc++.a(eh_alloc.o): in function `std::basic_string_view<char, std::char_traits<char> >::compare(unsigned long, unsigned long, char const*, unsigned long) const':
eh_alloc.cc:(.text._ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm[_ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm]+0x44): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
It will also raise the following build failure on sparc/arc:
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /home/autobuild/autobuild/instance-3/output-1/host/arceb-buildroot-linux-uclibc/sysroot/lib/libsupc++.a(eh_throw.o): in function `__exchange_and_add_dispatch':
/SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
Instead of trying to patch the configure script as advocated by
Yann E. Morin, set LD to TARGET_CXX as:
- this solution is quicker
- usptream is dead (last release in 2016)
- this solution has already been used in other packages (nodejs, zmqpp)
[1]: https://patchwork.ozlabs.org/project/buildroot/patch/20200812171821.2517-1-Evgeniy.Didin@synopsys.com/
Fixes:
- http://autobuild.buildroot.org/results/6096c3ddc5edf3204635c2c90246c2e8c8e074e7
- http://autobuild.buildroot.org/results/d8a/d8a3ab31c5b86871c7e1117f4ffa7b6cedfcb7e0/build-end.log
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit cd2dcaa6c6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
