Specifying a list of br2-external trees is poorly documented, and the
only example uses a colon to separate the br2-external paths.
Adding the support for colon-separated list is the biggest mistake that
was made when introducing support for multiple br2-external [0]. Indeed,
both space and colon can be used to separate entries in the list, and it
is also possible to mix the two. However, internally, the list is stored
as a space-separated list, and all the code will split on spaces.
Besides, all other lists in Buildroot are a space-separated:
BR2_ROOTFS_DEVICE_TABLE
BR2_ROOTFS_STATIC_DEVICE_TABLE
BR2_TARGET_TZ_ZONELIST
BR2_ROOTFS_USERS_TABLES
BR2_ROOTFS_OVERLAY
BR2_ROOTFS_PRE_BUILD_SCRIPT
BR2_ROOTFS_POST_BUILD_SCRIPT
BR2_ROOTFS_POST_FAKEROOT_SCRIPT
BR2_ROOTFS_POST_IMAGE_SCRIPT
...
So, using colons is odd.
The fact that BR2_EXTERNAL is passed on the command line rather than
being a Kconfig item is not a reason enough to justify that it be
colon-separated.
Change the documentation to only mention using a space-separated list.
Of course, for backward compatibility, we keep the code as-is to accept
a colon-separated list, but we just do not advertise it.
Note that keeping the split on colons means that colons are not accepted
in pathnames of br2-external trees; in practice, this is not a new
restriction, or one that could lift as usign colons in Makefiles are
problematic anyway.
[0] in 20cd497387 core: add support for multiple br2-external trees
Reported-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Reported-by: Brandon Maier <Brandon.Maier@collins.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit f9cdca48a5)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The trap was initially introduced in c5fa9308ea (core/br2-external:
properly report unexpected errors), in 2017, to catch all unexpected
errors, back when a single file was generated, and errors emitted to
stderr.
Since commit d027cd75d0 (core: generate all br2-external files in
one go), in 2019 the single output file 'ofile' is no longer created,
as multiple output files were then introduced, while messages for
*expected errors* were redirected to a Makefile variable assignment
emitted on stdout, at which point the script just exits (in error);
expected failures only occur in do_validate().
Unexpected errors can only occur on failure to create, or write to,
output files, either '.br2-external.mk' in do_validate() or do_mk(),
or any of the kconfig fragments in do_kconfig(). Cause for failure to
create those can only be a no-space-left-on-device condition, as they
are created in a directory that was just created by the script earlier
in main(), and thus has the necessary mode; failure to create that
directory is now caught explicitly.
A trap on ERR is not called when the shell exits explicitly with a call
to 'exit', thus, only failures to create or write to output file would
be caught. In that case, we are better off not trying to write to those
files anyway: failure to create the file would already be reported by
the shell on stderr, while disk-full would not allow to store the output
anyway...
In any case, the script exits in error, which is going to be caught by
the caller, which will terminate.
So, drop the trap altogether.
As a side effect, that squelches a shellcheck error.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit 244e4283a9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
https://curl.se/ch/8.19.0.htmlhttps://curl.se/docs/security.html
Fixes the following CVEs:
CVE-2026-3805: use after free in SMB connection reuse
CVE-2026-3784: wrong proxy connection reuse with credentials
CVE-2026-3783: token leak with redirect and netrc
CVE-2026-1965: bad reuse of HTTP Negotiate connection
Switch to sha256 tarball hash provided by upstream.
Updated license hash due to copyright year bump:
e83c82f05f
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Julien: add back pgp signature info in hash file]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3a5e071e4f)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Building Go 1.26 and later requires Go 1.24.6 or later for bootstrap.
To support this we use Go version 1.25.8 as the version for
go-bootstrap-stage5 and have the build for Go 1.26.1 depend on
go-bootstrap-stage5.
Go version 1.25.8 is the latest Go version we can build using
go-bootstrap-stage4.
The package build for go-bootstrap-stage5 is effectively identical to
go-bootstrap-stage4 with only the Go version and stage number changed.
Go 1.28 is expected to require a minor release of Go 1.26 for bootstrap.
Fixes the following security vulnerabilities:
- CVE-2026-25679: net/url: reject IPv6 literal not at start of host
- CVE-2026-27142: html/template: URLs in meta attribute actions not escaped
- CVE-2026-27137: crypto/x509: incorrect enforcement of email constraints
- CVE-2026-27138: crypto/x509: panic in name constraint checking: certificates
- CVE-2026-27139: os: FileInfo can escape from a Root
For full release notes, see:
https://go.dev/doc/devel/release#go1.26.0
Signed-off-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 43d1323196)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
OP-TEE generates a few binaries that can be used by u-boot on some
platforms (Rockchip, Texas Instruments K3) using TEE variable.
Add a link to the OP-TEE documentation were we can find easily the
desciption for each TEE format that can be used by u-boot.
For convenience, copy tee.elf and tee.bin description in each option
choice help text.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit a5f5c08dcd)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Remove myself from packages that I'm no longer personally interested in.
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1210e4efeb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes build error with gcc 9.x:
output/build/libheif-1.21.1/libheif/nclx.h:128:50: error:
'bool nclx_profile::operator==(const nclx_profile&)
const' cannot be defaulted
using this defconfig:
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-static-2020.11.2.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_9=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_4=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_STATIC_LIBS=y
BR2_PACKAGE_LIBHEIF=y
According to https://github.com/strukturag/libheif/issues/1615#issuecomment-3457979167
gcc >= 10 with support for C++20 is needed for the package.
The failing code was introduced upstream in version 0.21.0 with commit
a62f933e38
which was added to buildroot with commit
a8aed698c7.
Also removed -std=c++11 from CXXFLAGS.
The build error was not yet recorded by the autobuilders.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7323bcc1d4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Buildroot commit 72c7d99e22 switched the
build system to meson which causes an error during configure:
output/build/libvips-8.17.2/meson.build:108:4:
ERROR: Problem encountered: GModule is not supported on your system,
please reconfigure with -Dmodules=disabled
using this defconfig:
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-static-2020.11.2.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_9=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_4=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_STATIC_LIBS=y
BR2_PACKAGE_LIBVIPS=y
Added configure options for -Dmodules to fix the problem which was not
yet caught by the autobuilders.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 86d0fcd77b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
These modules were dropped in Python 3.13 as per PEP 594.
The current version in Buildroot is 3.14.3.
- Remove the TODO and related config overrides in python3.mk.
- Remove BR2_PACKAGE_PYTHON3_OSSAUDIODEV from Config.in.
- Add BR2_PACKAGE_PYTHON3_OSSAUDIODEV to Config.in.legacy.
See [1] [2] [3].
[1] https://peps.python.org/pep-0594/
[2] fc07fe4e37
[3] 17e1fe0f9b
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
[Julien:
- add links in commit log
- move legacy option in 2026.05 section
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit df6e7a6664)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The artifacts URL has been moved to https and domain to .org to
improve security and avoid redirection issues. This ensures that
downloads of kernels and rootfs images during runtime tests are
encrypted and verified.
The change has been tested by running a runtime test, confirming the
correct download and renaming of artifacts from the new URL:
Downloading to .../tmpyotq8uor
Renaming from .../tmpyotq8uor to .../kernel-versatile-5.10.202
Signed-off-by: Dowan Gullient <dowan.gullient@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 8313d8a2fa)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
EDK2 removed OVMF IA32 support in commit [1], which is included in
version edk2-stable202511. This commit removes the test relying on it.
[1] 1fb88ffe28
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit bd06eace37)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
EDK2 removed OVMF IA32 support in commit [1], which is included in
version edk2-stable202511. This commit removes tests relying on it.
[1] 1fb88ffe28
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit cf16e1abe0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The zjit option introduces a rust dependency and due to that not
being handled appropriately it can cause build failures if this
feature gets incorrectly autodetected as being available.
This feature was introduced when ruby was bumped to version 4.0.0
in f594f86f9d.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that custom arm-trusted-firmware versions can specify license files, add
license file hashes for the Xilinx custom arm-trusted-firmware version.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that custom Linux versions can specify license files, add license file
hashes for the Xilinx custom Linux version.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 127f36b406 ("package/ruby: bump to version 4.0.1") adjusted
RUBY_VERSION_EXT, but ruby 4.0.1 still installs its extensions into the
4.0.0 subdir:
ls target/usr/lib/ruby/
4.0.0 site_ruby vendor_ruby
So revert the RUBY_VERSION_EXT change to ensure the unneeded extensions are
correctly removed.
Signed-off-by: William Sherrer <william@sherrer.com>
[Peter: significantly extend commit message]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Patches mostly backported with the basis of the work of Ubuntu Security
team. See [1].
Fix the following vulnerabilities:
- CVE-2024-32661:
FreeRDP is a free implementation of the Remote Desktop Protocol.
FreeRDP based clients prior to version 3.5.1 are vulnerable to a
possible `NULL` access and crash. Version 3.5.1 contains a patch for
the issue. No known workarounds are available.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2024-32661
- CVE-2026-23530:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to version 3.21.0,`freerdp_bitmap_decompress_planar` does not validate
`nSrcWidth`/`nSrcHeight` against `planar->maxWidth`/`maxHeight` before
RLE decode. A malicious server can trigger a client‑side heap buffer
overflow, causing a crash (DoS) and potential heap corruption with
code‑execution risk depending on allocator behavior and surrounding
heap layout. Version 3.21.0 contains a patch for the issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23530
- CVE-2026-23531:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to version 3.21.0, in ClearCodec, when `glyphData` is present,
`clear_decompress` calls `freerdp_image_copy_no_overlap` without
validating the destination rectangle, allowing an out-of-bounds
read/write via crafted RDPGFX surface updates. A malicious server can
trigger a client‑side heap buffer overflow, causing a crash (DoS) and
potential heap corruption with code‑execution risk depending on
allocator behavior and surrounding heap layout. Version 3.21.0
contains a patch for the issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23531
- CVE-2026-23532:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to version 3.21.0, a client-side heap buffer overflow occurs in the
FreeRDP client’s `gdi_SurfaceToSurface` path due to a mismatch between
destination rectangle clamping and the actual copy size. A malicious
server can trigger a client‑side heap buffer overflow, causing a crash
(DoS) and potential heap corruption with code‑execution risk depending
on allocator behavior and surrounding heap layout. Version 3.21.0
contains a patch for the issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23532
- CVE-2026-23533:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to version 3.21.0, a client-side heap buffer overflow occurs in the
RDPGFX ClearCodec decode path when maliciously crafted residual data
causes out-of-bounds writes during color output. A malicious server
can trigger a client‑side heap buffer overflow, causing a crash (DoS)
and potential heap corruption with code‑execution risk depending on
allocator behavior and surrounding heap layout. Version 3.21.0
contains a patch for the issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23533
- CVE-2026-23534:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to version 3.21.0, a client-side heap buffer overflow occurs in the
ClearCodec bands decode path when crafted band coordinates allow
writes past the end of the destination surface buffer. A malicious
server can trigger a client‑side heap buffer overflow, causing a crash
(DoS) and potential heap corruption with code‑execution risk depending
on allocator behavior and surrounding heap layout. Version 3.21.0
contains a patch for the issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23534
- CVE-2026-23948:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to 3.22.0, a NULL pointer dereference vulnerability in
rdp_write_logon_info_v2() allows a malicious RDP server to crash
FreeRDP proxy by sending a specially crafted LogonInfoV2 PDU with
cbDomain=0 or cbUserName=0. This vulnerability is fixed in 3.22.0.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-23948
- CVE-2026-24675:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to 3.22.0, urb_select_interface can free the device's MS config on
error but later code still dereferences it, leading to a use after
free in libusb_udev_select_interface. This vulnerability is fixed in
3.22.0.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24675
- CVE-2026-24676:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to 3.22.0, AUDIN format renegotiation frees the active format list
while the capture thread continues using audin->format, leading to a
use after free in audio_format_compatible. This vulnerability is fixed
in 3.22.0.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24676
- CVE-2026-24679:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to 3.22.0, The URBDRC client uses server-supplied interface numbers as
array indices without bounds checks, causing an out-of-bounds read in
libusb_udev_select_interface. This vulnerability is fixed in 3.22.0.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24679
- CVE-2026-24681:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to 3.22.0, aAsynchronous bulk transfer completions can use a freed
channel callback after URBDRC channel close, leading to a use after
free in urb_write_completion. This vulnerability is fixed in 3.22.0.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24681
- CVE-2026-24682:
FreeRDP is a free implementation of the Remote Desktop Protocol. Prior
to 3.22.0, audin_server_recv_formats frees an incorrect number of
audio formats on parse failure (i + i), leading to out-of-bounds
access in audio_formats_free. This vulnerability is fixed in 3.22.0.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24682
- CVE-2026-24683:
FreeRDP is a free implementation of the Remote Desktop Protocol.
ainput_send_input_event caches channel_callback in a local variable
and later uses it without synchronization; a concurrent channel close
can free or reinitialize the callback, leading to a use after free.
Prior to 3.22.0, This vulnerability is fixed in 3.22.0.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-24683
[1] https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/freerdp2/2.6.1+dfsg1-3ubuntu2.10/freerdp2_2.6.1+dfsg1-3ubuntu2.10.debian.tar.xz
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes the following vulnerability:
- CVE-2025-62168:
Squid is a caching proxy for the Web. In Squid versions prior to 7.2,
a failure to redact HTTP authentication credentials in error handling
allows information disclosure. The vulnerability allows a script to
bypass browser security protections and learn the credentials a
trusted client uses to authenticate. This potentially allows a remote
client to identify security tokens or credentials used internally by a
web application using Squid for backend load balancing. These attacks
do not require Squid to be configured with HTTP authentication. The
vulnerability is fixed in version 7.2. As a workaround, disable debug
information in administrator mailto links generated by Squid by
configuring squid.conf with email_err_data off.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-62168
- 0951a06810
The backport has been compared against debian patch [1].
[1] https://sources.debian.org/src/squid/6.13-2%2Bdeb13u1/debian/patches/CVE-2025-62168.patch
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
For changes, see:
- https://github.com/vim/vim/compare/v9.1.2017...v9.1.2148
Fixes the following vulnerabilities:
- CVE-2026-25749:
Vim is an open source, command line text editor. Prior to version
9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag
file resolution logic when processing the 'helpfile' option. The
vulnerability is located in the get_tagfname() function in src/tag.c.
When processing help file tags, Vim copies the user-controlled
'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1
bytes (typically 4097 bytes) using an unsafe STRCPY() operation
without any bounds checking. This issue has been patched in version
9.1.2132.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-25749
- 0714b15940
- CVE-2026-26269:
Vim is an open source, command line text editor. Prior to 9.1.2148, a
stack buffer overflow vulnerability exists in Vim's NetBeans
integration when processing the specialKeys command, affecting Vim
builds that enable and use the NetBeans feature. The Stack buffer
overflow exists in special_keys() (in src/netbeans.c). The while
(*tok) loop writes two bytes per iteration into a 64-byte stack buffer
(keybuf) with no bounds check. A malicious NetBeans server can
overflow keybuf with a single specialKeys command. The issue has been
fixed as of Vim patch v9.1.2148.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2026-26269
- c5f312aad8
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit 3d2141bcee("support/testing/run-tests: specify multiprocessing
method") added a call to multiprocessing.set_start_method('fork') as a
workaround for python 3.14, which changed the default start method to
forkserver - Which is incompatible with the nose2 setup.
multiprocessing.set_start_method() is only supposed to be called a maximum
of 1 time per process and throws a RuntimeError if called more than that
(even with the same arguments):
>>> import multiprocessing
>>> multiprocessing.set_start_method('fork')
>>> multiprocessing.set_start_method('fork')
Traceback (most recent call last):
File "<python-input-2>", line 1, in <module>
multiprocessing.set_start_method('fork')
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
File "/usr/lib/python3.13/multiprocessing/context.py", line 247, in set_start_method
raise RuntimeError('context has already been set')
Debian included a similar patch in python3-nose2 0.51.1-2 (currently in
testing/unstable) which adds its own call to set_start_method():
https://salsa.debian.org/python-team/packages/nose2/-/blob/debian/0.15.1-2/debian/patches/0004-plugins-mp-set-context-to-fork-for-Python-3.14-mp-AP.patch?ref_type=tags
Which comes from:
https://github.com/nose-devs/nose2/pull/644
As discussed in the upstream PR, this is not a correct fix is wrong and
breaks various use cases. An issue has been opened to get this fixed in the
Debian packaging at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1129350
But until that is done, rework the patch to:
- Only override set_start_method() if needed to limit impact
- Monkey patch set_start_method() so additional calls are ignored
To unbreak run-test on affected Debian systems and add some documentation to
make it clear why this is done.
[Peter: use allow_none / force optional arguments as pointed out by Julien]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the toolchain involved in openscap build does not support C++, the
configure step fails with the following error:
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /bin/false
-- Check for working CXX compiler: /bin/false - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:73 (message):
The C++ compiler
"/bin/false"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: '/home/autobuild/autobuild/instance-6/output-1/build/openscap-1.3.12/buildroot-build/CMakeFiles/CMakeScratch/TryCompile-tUydqI'
Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_1834b/fast
make[1]: Entering directory '/home/autobuild/autobuild/instance-6/output-1/build/openscap-1.3.12/buildroot-build/CMakeFiles/CMakeScratch/TryCompile-tUydqI'
/usr/bin/make -f CMakeFiles/cmTC_1834b.dir/build.make CMakeFiles/cmTC_1834b.dir/build
make[2]: Entering directory '/home/autobuild/autobuild/instance-6/output-1/build/openscap-1.3.12/buildroot-build/CMakeFiles/CMakeScratch/TryCompile-tUydqI'
Building CXX object CMakeFiles/cmTC_1834b.dir/testCXXCompiler.cxx.o /bin/false -o CMakeFiles/cmTC_1834b.dir/testCXXCompiler.cxx.o -c /home/autobuild/autobuild/instance-6/output-1/build/openscap-1.3.12/buildroot-build/CMakeFiles/CMakeScratch/TryCompile-tUydqI/testCXXCompiler.cxx
make[2]: *** [CMakeFiles/cmTC_1834b.dir/build.make:81: CMakeFiles/cmTC_1834b.dir/testCXXCompiler.cxx.o] Error 1
make[2]: Leaving directory '/home/autobuild/autobuild/instance-6/output-1/build/openscap-1.3.12/buildroot-build/CMakeFiles/CMakeScratch/TryCompile-tUydqI'
make[1]: *** [Makefile:134: cmTC_1834b/fast] Error 2
make[1]: Leaving directory '/home/autobuild/autobuild/instance-6/output-1/build/openscap-1.3.12/buildroot-build/CMakeFiles/CMakeScratch/TryCompile-tUydqI'
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:11 (project)
-- Configuring incomplete, errors occurred!
make: *** [package/pkg-generic.mk:263: /home/autobuild/autobuild/instance-6/output-1/build/openscap-1.3.12/.stamp_configured] Error 1
make: Leaving directory '/home/autobuild/autobuild/instance-6/buildroot'
The openscap project does not contain any C++ file, and so does not need
a C++ capable compiler. Bring the to-be-integrated-upstream patch
enforcing C language in CMakeLists.txt to prevent this build failure.
Fixes: https://autobuild.buildroot.org/results/1fe550ffa79f0a083a450ae03fe067a8ab7336be
Fixes: https://autobuild.buildroot.org/results/e9d52b52658544916022050c78dcb137ca6c97e0
Fixes: https://autobuild.buildroot.org/results/4a9c21763aaddb217ee5f8bb8947faad9767baa3
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
