- Feb 26, 2020
-
-
Peter Korsgaard authored
Signed-off-by:Peter Korsgaard <peter@korsgaard.com>
-
Pascal de Bruijn authored
During _POST_PATCH_HOOKS _DEPENDANCIES aren't guaranteed to be built, however during _PRE_CONFIGURE_HOOKS they should be built. Should fix: http://autobuild.buildroot.net/results/dd8e225e2a49cfa6735bed11459007003a37c137/ http://autobuild.buildroot.net/results/e688c3652bd474ac682984e2e5947701942f0f57/ Cc: Baruch Siach <baruch@tkos.co.il> Signed-off-by:
Pascal de Bruijn <p.debruijn@unilogic.nl> Signed-off-by:
-
Adam Duskett authored
For additional post-244 fixes. Update the hash of the README after commit faba5b2b (Revert "Drop dbus activation stub service") changed a comment about dbus: - dbus >= 1.11.0 (strictly speaking optional, but recommended) + dbus >= 1.4.0 (strictly speaking optional, but recommended) + NOTE: If using dbus < 1.9.18, you should override the default + policy directory (--with-dbuspolicydir=/etc/dbus-1/system.d). Signed-off-by:
Adam Duskett <Aduskett@gmail.com> Signed-off-by:
-
Peter Korsgaard authored
As discussed during the FOSDEM2019 develop days, Qt 5.6 is very old (5.6.3 was released in September 2017, and 5.6.x became EOL in March 2019), so drop it before the new Buildroot LTS release: https://elinux.org/Buildroot:DeveloperDaysFOSDEM2019#Qt5_versions_to_support:_keep_5.6_or_a_newer_LTS.3F And add legacy handling for it. There are a number of places where code checks for BR2_PACKAGE_QT5_VERSION_LATEST, so leave that as a blind option for now to not break the build. Signed-off-by:
-
Pascal de Bruijn authored
Workaround for: ld: hv_vss_daemon.o: unable to initialize decompress status for section .debug_info ld: hv_vss_daemon.o: unable to initialize decompress status for section .debug_info hv_vss_daemon.o: file not recognized: File format not recognized Signed-off-by:
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/d3edbab1f2cd0f7b790e2559dc8d489497ae02f3 Signed-off-by:
Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by:
-
- Feb 25, 2020
-
-
Peter Korsgaard authored
Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
-
Fabrice Fontaine authored
License is Apache-2.0 since version 7.800: http://arma.sourceforge.net/license.html Signed-off-by:
-
Romain Naour authored
Fedora 30 switched to GCC 9.x. [1] [1] https://fedoraproject.org/wiki/Changes/GCC9 Signed-off-by:
Romain Naour <romain.naour@smile.fr> Signed-off-by:
-
Fabrice Fontaine authored
Add a patch to correct a typo in the Makefile, so -fno-stack-protector / -fno-stack-protector-all are really used. With this applied, kvm-unit-tests will always be built without SSP as intented by upstream. This will fix the build on ppc64 with SSP that started to fail for an unknown reason since November 27th. Moreover, the Arch Linux workaround could also be removed in a follow-up patch. Fixes: - http://autobuild.buildroot.org/results/ad689b08173548af21dd1fb0e827fd561de6dfef Signed-off-by:
-
- Feb 24, 2020
-
-
Fabrice Fontaine authored
- This will fix a static build failure with readline thanks to https://github.com/FluidSynth/fluidsynth/commit/c538c9fa7e392ce16c3354696e7dc7781a78a300 - Update indentation of hash file (two spaces) Fixes: - http://autobuild.buildroot.org/results/88609eefe55af2ca50d43e17d3424b923528b07a Signed-off-by:
-
Carlos Santos authored
The regular expressions used in the sed commands assumes that there is a space after '/dev/root' but the skeleton file contains a tab. Use a more flexible '[[:blank:]]', instead. Signed-off-by:
Carlos Santos <unixmania@gmail.com> Signed-off-by:
Yann E. MORIN <yann.morin.1998@free.fr>
-
- Feb 23, 2020
-
-
Francois Gervais authored
A project could quite possibly have a custom rcw file that does not rely on any custom rcw include files (rcwi). Allow the build to succeed if this is the case. Signed-off-by:
Francois Gervais <fgervais@distech-controls.com> [yann.morin.1998@free.fr: install includes in a separate hook] Signed-off-by:
-
Peter Seiderer authored
Through the evolution of the qt5webengine package patch ([1], [2]) until the initial commit ([3]) the translations target install path got mangled resulting in a double trailing qtwebengine_locales path: /usr/translations/qtwebengine_locales/qtwebengine_locales Instead of: /usr/translations/qtwebengine_locales Fixes the translations runtime access failure resulting in the following warning: WARNING:resource_bundle_qt.cpp(116): locale_file_path.empty() for locale [1] http://lists.busybox.net/pipermail/buildroot/2015-July/132010.html [2] https://patchwork.ozlabs.org/patch/640633 [3] https://git.buildroot.net/buildroot/commit/?id=89080bac9bc47946a09c1e74f2f872363bf6785b Signed-off-by:
Peter Seiderer <ps.report@gmx.net> Signed-off-by:
-
Peter Seiderer authored
For details see [1]. [1] https://lists.freedesktop.org/archives/wayland-devel/2020-February/041227.html Signed-off-by:
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/e0e7ed448df8bdd6cb13a0989d7a6c7dbaa5bc4e Signed-off-by:
-
Yann E. MORIN authored
This reverts commit dc171f12, which was aimed at the next branch, not master. Signed-off-by:
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/0de9f2a69fa2a39164211299f8a429d2fec6935a Signed-off-by:
-
Carlos Santos authored
Call BUSYBOX_INSTALL_INDIVIDUAL_BINARIES in BUSYBOX_INSTALL_TARGET_CMDS, not in BUSYBOX_INSTALL_INIT_SYSV. This should have been done in commit b1e07d6d but was somehow lost during the review/aply process. Signed-off-by:
-
Yegor Yefremov authored
Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
-
Yegor Yefremov authored
GCC later than 5.x produce _fdti1.so file with an undefined symbol str2charp_size due to C99 inline semantics change. So remove this keyword. Signed-off-by:
-
Giulio Benetti authored
Add a patch to finally fix parallel build failure. Patch is pending upstream: https://salsa.debian.org/debian/at/merge_requests/14 Signed-off-by:
Giulio Benetti <giulio.benetti@benettiengineering.com> Signed-off-by:
-
Peter Korsgaard authored
Bugfix release, fixing a number of issues: - Fixed mixing salted and unsalted sessions in the same ESAPI context - Removed use of VLAs from TPML marshal code - Added check for object node before calling compute_session_value function - Fixed auth calculation in Esys_StartAuthSession called with optional parameters - Fixed compute_encrypted_salt error handling in Esys_StartAuthSession - Fixed exported symbols map for libtss2-mu The 2.3.3 tarball accidently contains a Makefile-fuzz-generated.am with content from a fuzz testing run (rather than an empty file as in earlier releases), confusing autoreconf together with our 0001-configure-Only-use-CXX-when-fuzzing.patch. Work around that by adding a post-patch hook to truncate the file. The issue has been reported upstream and the release logic has been changed to ensure this does not happen again for future releases: https://github.com/tstruk/tpm2-tss/commit/d163041e3bafa23c0be89c82a99b8501634ebdb4 Signed-off-by:
-
Baruch Siach authored
Unlike <PKG>_DEPENDENCIES, <PKG>_PATCH_DEPENDENCIES only guarantees extract and patch of listed dependencies, not build. Make this subtlety more explicit in the documentation. Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by:
Baruch Siach <baruch@tkos.co.il> [yann.morin.1998@free.fr: slight fix] Signed-off-by:
-
Fabrice Fontaine authored
- Fix potential memory overread when performing an ECDSA signature operation. The overread only happens with cryptographically low probability (of the order of 2^-n where n is the bitsize of the curve) unless the RNG is broken, and could result in information disclosure or denial of service (application crash or extra resource consumption). - To avoid a side channel vulnerability when parsing an RSA private key, read all the CRT parameters from the DER structure rather than reconstructing them. - Update indentation of hash file (two spaces) Signed-off-by:
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/83b34e606b128546da8a70836d039090e334a1ec Signed-off-by:
-
Giulio Benetti authored
Fix previous commit[1] which purpose was to fix parallel build. It didn't work since it assigned $(MAKE1) to LIBSVGTINY_MAKE, but this is a generic-package and building is done using $(MAKE), then LIBSVGTINY_MAKE was ignored. Let's substitute instead $(MAKE) with $(MAKE1) in LIBSVGTINY_BUILD_CMDS. [1]: https://git.buildroot.net/buildroot/commit/?id=26d67a2599d6c88facd5178de853fa355244e7c2 Fixes: http://autobuild.buildroot.net/results/67d/67d341c0cc272323d6e231a20796a6848c21d760/ Signed-off-by:
-
- Feb 22, 2020
-
-
Yann E. MORIN authored
Commit 509db3b8 added calls to (parts of) the instrumentation steps. However, those calls are echoed, unlike the other places where we call them (in the package infra). Signed-off-by:
Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
-
Romain Naour authored
src/gbm/cd6bfad@@gbm at sha/main_backend.c.o: In function `_gbm_create_device': backend.c:(.text+0x38): undefined reference to `gbm_dri_backend' backend.c:(.text+0x40): undefined reference to `gbm_dri_backend' backend.c:(.text+0x74): undefined reference to `gbm_dri_backend' backend.c:(.text+0x78): undefined reference to `gbm_dri_backend' collect2: error: ld returned 1 exit status This issue has been trigged since [1]: "package/mesa3d: add option to configure gbm support" Before the patch, the gbm support was autodetected by meson and enabled only when at least one dri driver was enabled [2]. On the Buildroot side, the gbm support was explicitely enabled only when BR2_PACKAGE_MESA3D_OPENGL_EGL was set. We have two cases: - At least one DRI driver. - No DRI driver but one Gallium w/ EGL enable (EGL selected or not by the Gallium driver). In this case the meson build system set with_dri to true (even if no DRI driver is enabled) to use the builtin:egl_dri2 [3]. The gbm's meson build system seems to handle the case where no dri driver is enabled [4] but it still use main/backend.c source file [6] that use gbm_dri_backend [7]. So with_dri2 must always be set. Probably a missing check in meson.build: if with_gbm and not with_dri error('GBM backend needs a dri driver or a gallium driver w/ EGL support.') endif Add a dependency on GBM option: depends on BR2_PACKAGE_MESA3D_DRI_DRIVER \ || (BR2_PACKAGE_MESA3D_GALLIUM_DRIVER && BR2_PACKAGE_MESA3D_OPENGL_EGL) Fixes: http://autobuild.buildroot.net/results/b9b6281983388dc22d929887d653da3db60f1f2c [1] b6c051ac [2] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L348 [3] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L212 [4] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/src/gbm/meson.build#L37 [5] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/src/gbm/meson.build#L24 [6] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/src/gbm/main/backend.c#L38 [7] http://lists.busybox.net/pipermail/buildroot/2020-February/274425.html Signed-off-by:Bernd Kuhls <bernd.kuhls@t-online.de> [yann.morin.1998@free.fr: fix dependency of comment] Signed-off-by:
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/2ae2eca969e6d1febcacb8b0423ced3aad7505a2 Signed-off-by:
-
Fabrice Fontaine authored
Signed-off-by:
-
Romain Naour authored
This issue has been trigged since [1]: "package/mesa3d: add option to configure gbm support" Before the patch, the gbm support was autodetected by meson and enabled only when at least one dri driver was enabled [2]. On the Buildroot side, the gbm support was explicitely enabled only when BR2_PACKAGE_MESA3D_OPENGL_EGL was set. Now, the gbm support is explicitely disabled but the meson build system check if at least one option OpenGL GLX or OpenGL EGL or GBM or OSMesa (classic) library is enabled [3]. The previous behavious was to enable GBM when GLX, EGL and OSMesa are disabled. So select GBM symbol for this case. Fixes: http://autobuild.buildroot.net/results/a14f329560f8022f7ba8ec43ad8eed84e005d226 [1] b6c051ac [2] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L348 [3] https://gitlab.freedesktop.org/mesa/mesa/blob/19.3/meson.build#L449 Signed-off-by:
Romain Naour <romain.naour@gmail.com> Cc: Bernd Kuhls <bernd.kuhls@t-online.de> Tested-by:
-
Romain Naour authored
When BR2_SSP_ALL is set, there is a link issue due to missing -fPIC in CFLAGS. Set CMAKE_POSITION_INDEPENDENT_CODE=ON to add it. This is a similar fix as for gtest package [1] [1] https://git.buildroot.net/buildroot/commit/?id=2026621f3c60167aa8ba48e658be1b214d1347d7 Fixes: http://autobuild.buildroot.net/results/e1f/e1f164cee16b037c0232fdda40fc16caf8f0c0af Signed-off-by:
-
Gilles Talis authored
Signed-off-by:
Gilles Talis <gilles.talis@gmail.com> Signed-off-by:
-
Carlos Santos authored
We don't provide a configuration file, so disable radvd by default. Update the help message with instructions on how to enable radvd at build time with systemd. Signed-off-by:
-
- Feb 21, 2020
-
-
Bernd Kuhls authored
Changelog: https://www.php.net/ChangeLog-7.php#7.4.3 Fixes CVE-2020-7061, CVE-2020-7062 & CVE-2020-7063. Removed patch applied upstream: https://github.com/php/php-src/commit/f0f5c415a6e0abc40514f97113deb52a343174ee Signed-off-by:
-
- Feb 20, 2020
-
-
Yann E. MORIN authored
Signed-off-by: -
Thomas Petazzoni authored
This commit ensures that BR2_SSP_STRONG cannot be chosen if the toolchain doesn't support strong SSP. Fixes: http://autobuild.buildroot.net/results/cba93a681d10692c4e4c5584e4c962bd18a608d4/ Signed-off-by:
-
Thomas Petazzoni authored
This commit adds a user-visible option BR2_TOOLCHAIN_EXTERNAL_HAS_SSP_STRONG, which will allow the user to indicate if the custom external toolchain does or does not have SSP_STRONG support. Depending on this, the user will be able to use (or not) the BR2_SSP_STRONG option. Checking if what the user said is true or not about this is already done in toolchain/toolchain-external/pkg-toolchain-external.mk: $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION)) If the user selects BR2_SSP_STRONG, this will check if -fstack-protector-strong is really supported. Signed-off-by: -
Thomas Petazzoni authored
This will allow toolchain to indicate if they support -fstack-protector-strong or not. Whenever the gcc version is >= 4.9, we always have SSP_STRONG support if we have SSP support. However, some toolchains older than gcc 4.9 might have backported SSP_STRONG support, which is why we cannot rely just on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9. Having this "default" value allows to avoid adding a "select BR2_TOOLCHAIN_HAS_SSP_STRONG" in the internal toolchain logic plus in almost external toolchains. But it allows custom external toolchains that are pre-4.9 to potentially declare that they support strong SSP. Signed-off-by:
-
