Since the bump of rpm from 4.17.0 to 4.18.0 in Buildroot commit
4b4046e919, tools/rpmuncompress.c uses
basename() without including <libgen.h> which causes a build failure
with the musl C library:
tools/rpmuncompress.c: In function ‘doUntar’:
tools/rpmuncompress.c💯30: error: implicit declaration of function ‘basename’ [-Wimplicit-function-declaration]
100 | const char *bn = basename(fn);
| ^~~~~~~~
tools/rpmuncompress.c💯30: error: initialization of ‘const char *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
make[4]: *** [Makefile:1082: tools/rpmuncompress.o] Error 1
This issue was not found by the autobuilders, but it can be reproduced
with:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_RPM=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
GCC 14.x brought some more strict checks on pointer types, causing a
build issue in the rpm package when python support is enabled. These
issues have been fixed upstream, initially because Clang >= 16 also
added similar stricter checks.
The build issue goes like this:
header-py.c:744:9: error: initialization of 'Py_hash_t (*)(PyObject *)' {aka 'int (*)(struct _object *)'} from incompatible pointer type 'long int (*)(PyObject *)' {aka 'long int (*)(struct _object *)'} [-Wincompatible-pointer-types]
744 | hdr_hash, /* tp_hash */
| ^~~~~~~~
header-py.c:744:9: note: (near initialization for 'hdr_Type.tp_hash')
make[3]: *** [Makefile:664: header-py.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
It never happened in the autobuilders, but it can be reproduced with
the following configuration:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_PYTHON3=y
BR2_PACKAGE_RPM=y
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Starting with mender 5.x, the docker, rpm and script modules provided by
the mender package now reside in the mender-update-modules repository.
Even though the mender package provided by Buildroot is not updated yet to 5.x,
it is best to enable the modules here to help facilitate the future update of
the mender package to 5.x, and to ensure that any future modifications or bug
fixes to these modules are easy to apply by simply bumping the upstream package
version.
Script is enabled by default to preserve the existing behavior of the mender
package.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Contains community supported Update Modules. An Update Module is an extension
to the Mender client for supporting a new type of software update, such as a
package manager, container, bootloader or even updates of nearby
microcontrollers. An Update Module can be tailored to a specific device or
environment (e.g. update a proprietary bootloader), or be more
general-purpose (e.g. install a set of .rpm packages.).
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
linux.conf does not change after manually checking the output of
`make savedefconfig` in the kernel source directory.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
CMake 4.0 requires to have a cmake_minimum_required() in
CMakeLists.txt, which cdrkit doesn't have, so ths commit adds a patch
adding the missing statement. We have chosen version 3.18 because that
the oldest version that we expect is 3.18. From
package/cmake/Config.in.host:
# The minimum system cmake version we expect if 3.18 as provided by
# Debian bullseye, that we use in our reference build docker image.
The patch cannot be upstreamed, as cdrkit basically no longer has any
upstream.
Fixes:
https://autobuild.buildroot.org/results/3412e47836b54928a55c12b46549d6307ab623e7/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This updates the VC4/V3D driver messages with the addition of the
current supported hardwares (VideoCore and Raspberry Pi).
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The Gallium VC4 driver does not require NEON[1]; Gallium V3D does. Also,
the Gallium VC4 driver supports the Raspberry Pi from 0 to 3[2].
Mesa’s VC4 graphics driver supports multiple implementations of
Broadcom’s VideoCore IV GPU. It is notably used in the Raspberry
Pi 0 through Raspberry Pi 3 hardware, and the driver is included
as an option as of the 2016-02-09 Raspbian release using
raspi-config. On most other distributions such as Debian or
Fedora, you need no configuration to enable the driver.
This reverts commit a5cdb54ed7.
That commit is superseded by 85c95e3614
that patches the sources to disable NEON via an option[3]; the sources
using NEON (tiling) are disabled if the CPU does not have that feature.
Thus, the VC4 driver compiles with toolchain without the NEON support
enabled as the one targetting the Raspberry Pi (ARMv6).
This removes the depends on BR2_ARM_CPU_HAS_NEON config since a meson
option disables NEON if the CPU does not support for it. It allows
building Gallium VC4 on Raspberry Pi, Raspberry Pi Zero and Compute
Module.
Note: kmscube with OpenGLES and Gallium/VC4 runs on Raspberry Pi B+ Rev
1.2.
# uname -a
Linux buildroot 6.12.20 #1 Fri Apr 25 02:54:03 CEST 2025 armv6l GNU/Linux
# cat /sys/firmware/devicetree/base/model
Raspberry Pi Model B Plus Rev 1.2#
# dmesg
(...)
[ 39.817806] rpi-gpiomem 20200000.gpiomem: window base 0x20200000 size 0x00001000
[ 39.837139] rpi-gpiomem 20200000.gpiomem: initialised 1 regions as /dev/gpiomem
[ 40.693845] Console: switching to colour dummy device 80x30
[ 40.717223] vc4-drm soc:gpu: bound 20400000.hvs (ops vc4_hvs_ops [vc4])
[ 40.793911] vc4-drm soc:gpu: bound 20400000.hvs (ops vc4_hvs_ops [vc4])
[ 40.824330] Registered IR keymap rc-cec
[ 40.828596] rc rc0: vc4-hdmi as /devices/platform/soc/20902000.hdmi/rc/rc0
[ 40.844139] input: vc4-hdmi as /devices/platform/soc/20902000.hdmi/rc/rc0/input0
[ 40.873434] input: vc4-hdmi HDMI Jack as /devices/platform/soc/20902000.hdmi/sound/card0/input1
[ 40.895848] vc4-drm soc:gpu: bound 20902000.hdmi (ops vc4_hdmi_ops [vc4])
[ 40.914034] vc4-drm soc:gpu: bound 20004000.txp (ops vc4_txp_ops [vc4])
[ 40.921843] vc4-drm soc:gpu: bound 20206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 40.943543] vc4-drm soc:gpu: bound 20207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 40.951969] vc4-drm soc:gpu: bound 20807000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 40.983322] vc4-drm soc:gpu: bound 20c00000.v3d (ops vc4_v3d_ops [vc4])
[ 41.010210] [drm] Initialized vc4 0.0.0 for soc:gpu on minor 0
[ 41.151906] Console: switching to colour frame buffer device 240x67
[ 41.223414] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
# kmscube
Using display 0x1f12530 with EGL version 1.4
===================================
EGL information:
version: "1.4"
vendor: "Mesa Project"
client extensions: "EGL_EXT_client_extensions EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_explicit_device EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless"
display extensions: "EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_gl_interop EGL_MESA_image_dma_buf_export EGL_MESA_query_driver "
===================================
OpenGL ES 2.x information:
version: "OpenGL ES 2.0 Mesa 24.0.9"
shading language version: "OpenGL ES GLSL ES 1.0.16"
vendor: "Broadcom"
renderer: "VC4 V3D 2.1"
extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_depth_texture GL_AMD_performance_monitor GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage GL_NV_texture_barrier GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_APPLE_sync GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_NV_generate_mipmap_sRGB GL_NV_pixel_buffer_object GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_debug_label GL_EXT_separate_shader_objects GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_EXT_texture_compression_s3tc_srgb GL_KHR_parallel_shader_compile GL_MESA_tile_raster_order GL_MESA_sampler_objects GL_MESA_bgra "
===================================
Rendered 120 frames in 2.000020 sec (59.999400 fps)
[1]: 932ed9c00b
[2]: https://docs.mesa3d.org/drivers/vc4.html
[3]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4114
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This dependency systematically applied with integrated GPUs but no longer
with discrete GPUs, so remove it.
Signed-off-by: Francois Dugast <francois.dugast.foss@gmail.com>
[Julien: fix conflicts after mesa3d bump in commit 317260f]
Signed-off-by: Julien Olivain <ju.o@free.fr>
If an attempt is made to create a UBI volume and it already exists, the
operation fails. Therefore, before requesting the creation of a UBI
volume, we erase the entire NAND to ensure that no errors occur.
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This target version is needed for Rusticl which is an LLVM based OpenCL
framework[1]. Rusticl allow programs to compile OpenCL C/C++ code
at runtime with Clang. Clang generates LLVM IR which is translated into
SPIR-V by spirv-llvm-translator. Finally, mesa can use its internal
tools to manage SPIR-V.
[1]: https://docs.mesa3d.org/rusticl.html
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Sebastian Weyer <sebastian.weyer@smile.fr>
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
host-libdrm is needed by host-mesa3d (introduced by this patch series),
which is needed by (target) mesa3d, when enabling the Gallium Iris
driver since version 24.1.0.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since commit [1], the host-nodejs package was turned into a virtual
package. However, the target nodejs package was intentionally not
turned into a virtual package and became an empty package.
The reason for this is:
- No alternatives providers were introduced for the target nodejs
package.
- The Config.in remained unchaged for the target package.
As a result, running `make show-info` with a config that includes the
target nodejs package, outputs an entry for the empty package:
```
"nodejs": {
"type": "target",
"name": "nodejs",
"virtual": false,
"version": "",
...
"cpe-id": "cpe:2.3🅰️nodejs:node.js::*:*:*:*:*:*:*"
},
```
This can be an issue because the CPE ID of the empty nodejs package
is the following `cpe:2.3🅰️nodejs:node.js::*:*:*:*:*:*:*`.
Reporting such a CPE ID can be an issue for certain software that consume
the SBOM and could be interpreted as CPE that matches with every versions
of the package.
This patch converts the target nodejs package into a virtual package to
prevents the empty package from being included in the SBOM.
[1] 4cbc2af604 package/nodejs: rename to nodejs-src and convert to virtual package
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Tested-by: johan.derycke@barco.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Migrate from old sourceforge download location to github.
License hash changed due to year update:
a927b489e2
Readme hash changed due to various minor tweaks:
94c64ead85
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Version 6.1.2 of ffmpeg fails to build with GCC 14.x due to the V4L2
ioctl code:
libavdevice/v4l2.c:137:17: error: assignment to ‘int (*)(int, long unsigned int, ...)’ from incompatible pointer type ‘int (*)(int, int, ...)’ [-W
incompatible-pointer-types]
137 | s->ioctl_f = prefix ## ioctl; \
| ^
libavdevice/v4l2.c:151:9: note: in expansion of macro ‘SET_WRAPPERS’
151 | SET_WRAPPERS();
| ^~~~~~~~~~~~
This has been fixed upstream in the release/6.1 branch, which has 27
fixes on top of 6.1.2. The commits necessary to fix our issue are:
f71076c009f84917e7a0f2f1ece86b718de2d8d3 configure: improve check for POSIX ioctl
60593d6c06c9b610359bd6af26a268feff1293eb configure: restore autodetection of v4l2 and fbdev
However, since all other commits are fixes, we believe bumping to the
latest commit in the release/6.1 branch is a better idea.
This allows to drop
0008-libavcodec-arm-mlpdsp_armv5te-fix-label-format-to-wo.patch, which
is upstream as of:
4c688845a50f7dce3af9afebe60f0f7a493c4f07 libavcodec/arm/mlpdsp_armv5te: fix label format to work with binutils 2.43
Note that we set FFMPEG_CPE_ID_VERSION to get proper CVE matching even
with FFMPEG_VERSION being set to n6.1.2-27-ge16ff06adb. One who have
ideally set FFMPEG_VERSION to n$(FFMPEG_CPE_ID_VERSION)-ge16ff06adb,
but that makes check-package unhappy with:
WARNING: package/ffmpeg/ffmpeg.mk:7: expecting package version to be set before CPE_ID_VERSION
Fixes:
https://autobuild.buildroot.net/results/fe1574443acd50ca7e576bb4beb24467be1713e3/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The V4L2 code in the ffmpeg plugin uses V4L2_PIX_FMT_BGRA32 which was
only introduced in kernel headers 5.2, in upstream kernel commit
e25ec9141114c7124eeba09385e272dd76fbe617.
Fixes:
/home/thomas/buildroot/buildroot/outputs/qt/build/qt6multimedia-6.8.1/src/plugins/multimedia/ffmpeg/qv4l2camera.cpp:36:43: error: ‘V4L2_PIX_FMT_BGRA
32’ was not declared in this scope; did you mean ‘V4L2_PIX_FMT_BGR32’?
36 | { QVideoFrameFormat::Format_BGRA8888, V4L2_PIX_FMT_BGRA32 },
| ^~~~~~~~~~~~~~~~~~~
| V4L2_PIX_FMT_BGR32
when building:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_XCB=y
BR2_PACKAGE_QT6MULTIMEDIA=y
BR2_PACKAGE_QT6MULTIMEDIA_FFMPEG=y
BR2_PACKAGE_XORG7=y
at a time when the Bootlin stable toolchain was using Linux 4.19
headers.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The following defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_XCB=y
BR2_PACKAGE_QT6MULTIMEDIA=y
BR2_PACKAGE_QT6MULTIMEDIA_FFMPEG=y
BR2_PACKAGE_XORG7=y
would fail to build, due to <X11/extensions/Xext.h> being not found,
and then <X11/extensions/Xrandr.h> being not found. Fix that up by
introducing the necessary dependencies.
There are no build failures reported for qt6multimedia in the
autobuilders, so there is no reference to a build failure.
Signed-off-by: Roy Kollen Svendsen <roykollensvendsen@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Fixes:
ERROR: Feature "xcb": Forcing to "ON" breaks its condition:
QT_FEATURE_thread AND TARGET XCB::XCB AND TEST_xcb_syslibs AND QT_FEATURE_xkbcommon_x11
Condition values dump:
QT_FEATURE_thread = "ON"
TARGET XCB::XCB found
TEST_xcb_syslibs = "FALSE"
QT_FEATURE_xkbcommon_x11 not evaluated
The xcb feature is defined in [2].
According to [1] XCB::CURSOR is needed for xcb support.
[1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/configure.cmake?h=6.9.0#n522
[2] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/configure.cmake?h=6.9.0#n1016
This bug was introduced in e634be8906,
and fixes the build with the following defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_MUSL_STABLE=y
BR2_PACKAGE_QT6=y
BR2_PACKAGE_QT6BASE_GUI=y
BR2_PACKAGE_QT6BASE_XCB=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Roy Kollen Svendsen <roykollensvendsen@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Buildroot packaging pretty much assumes that the sources it downloads
are publicly available. In general, however, Buildroot is also used to
download sources from private repositories. Nowadays, that mostly means
from a github or gitlab instance.
Although git-over-ssh can be used for that, this poses a problem for CI,
because the CI runners integrated with github and gitlab only have
access to the repository itself, not to other private repositories. And
creating ssh key pairs for CI runners is tricky.
Therefore, document how standard tools can be used to make private
repositories available both to developers and to CI. There are quite a
few alternative approaches possible, but they're more complicated or
less generically applicable.
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
[Peter: Fix insteadOf example, capitalize SSH/HTTPS]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is needed following the bump of libyang (3.12.2),
sysrepo (3.6.11) and libnetconf2 (3.7.1), as netopeer2 2.4.1 is the
version designed to work with those other components.
See https://github.com/CESNET/netopeer2/releases for the changes.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Changelog:
error-path data node
now using proper format so in rpc-reply uses XML XPath format instead of JSON
several bugfixes and improvements
Depends on libyang v3.12.2:
https://github.com/CESNET/libyang/releases/tag/v3.12.2
As part of this version bump, the ENABLE_SSH and ENABLE_TLS options
have been dropped by upstream in favor of a single ENABLE_SSH_TLS
option, which requires openssl or mbedtls, libcurl and libssh. Since
this is getting quite complicated to handle as an implicit optional
dependency, we make this explicit with a new sub-option
BR2_PACKAGE_LIBNETCONF2_SSH_TLS that ensures everything needed is
enabled.
In theory, libnetconf2 can use either mbedtls or openssl for crypto,
but netopeer2 will only work if OpenSSL is used, so we only allow
using OpenSSL until that gets fixed upstream.
The netopeer2 package, which needs SSH/TLS support in libnetconf2 is
updated accordingly (and actually becomes simpler).
Signed-off-by: Mattias Walström <lazzer@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Changelog:
optional xxhash faster hasing function
support for metadata in diff
lots of optimizations and fixes
License file changed due to copyright year change:
-Copyright (c) 2015-2021, CESNET
+Copyright (c) 2015-2024, CESNET
Signed-off-by: Mattias Walström <lazzer@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a patch (found in an upstream PR) to avoid the following error when
the dbus module is not enabled:
```
policy/modules/system/selinuxutil.te:102:ERROR 'attribute
dbusd_system_bus_client is not within scope' at token ';'
on line 155976:
```
Remove the patch 0001-policy-modules-services-smartmon.te-make-fstools-opt.patch
(upstream commit 65eed16b58015b08f43a096c202dae6cba2f0a37).
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[Arnout:
- Add patch to fix dbus issue.
- Remove dbus from default modules again.
- Remove the existing patch which is applied upstream.
]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
