- Feb 18, 2020
-
-
Peter Korsgaard authored
Signed-off-by:Peter Korsgaard <peter@korsgaard.com>
-
Fabrice Fontaine authored
Signed-off-by:
Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by:
-
Thomas Petazzoni authored
This is needed so that building the owfs Python module uses the gcc from owfs per-package directory, and not the one from the python per-package directory. Fixes: http://autobuild.buildroot.net/results/0d582dda367507991a4c38141db36b0fa8e47e67/ Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by:
-
Thomas Petazzoni authored
With per-package directory support, Python external modules are causing a problem: the _sysconfigdata.py module installed by the Python interpreter contains a number of paths that are relative to the current package per-package directory, i.e python or python3. For example: 'BLDSHARED': '/home/thomas/projets/buildroot/output/per-package/python/host/bin/arm-linux-gcc -shared', 'CC': '/home/thomas/projets/buildroot/output/per-package/python/host/bin/arm-linux-gcc', 'CXX': '/home/thomas/projets/buildroot/output/per-package/python/host/bin/arm-linux-g++', etc. These paths are problematic, because it means that the wrong compiler gets used when building external Python modules: instead of using the compiler from the external Python module per-package host directory, it uses the one from the 'python' or 'python3' per-package host directory. Due to this, any native dependency needed by the external Python module is not found, even though it is properly present in the current package per-package directory. Of course, the problem occurs with both target Python modules and host Python modules. To fix this, we simply rewrite those paths in _sysconfigdata.py before building a Python package. Interestingly, until now, the _sysconfidata.py that was used during the build was the one from $(TARGET_DIR), which is a bit unusual: it is more common to use files from $(STAGING_DIR) during the build process. So this commit changes the PYTHON_PATH and PYTHON3_PATH variables so that they point to $(STAGING_DIR), which makes the _sysconfigdata.py fixup in $(STAGING_DIR) effective. Fixes: http://autobuild.buildroot.net/results/a24b0555fd4261b50dc3986635c30717d9cbe764/ (python-psycopg2) http://autobuild.buildroot.net/results/080fa893e1b0e7a8c8a31ac1c98eb8871b97264d/ (python-alsaaudio) http://autobuild.buildroot.net/results/79bc070f98d6d9d8ef78df12b248cdc7d0e405c3/ (python-lxml) and many more Python packages that use native code with a native library Signed-off-by:
-
Thomas Petazzoni authored
When APR_INCLUDEDIR and APU_INCLUDEDIR point to the same directory, Apache builds properly. However, with per-package directory support, they point to different directories, and APU_INCLUDEDIR contains both the APR headers and the APU headers. Due to this, the Apache Makefile logic to generate its exports.c file leads to duplicate definitions, because the APR headers are considered twice: once from APR_INCLUDEDIR, once from APU_INCLUDEDIR. We fix this by introducing a patch to the Apache build system. In addition, apr provides a special libtool script that gets used by apr-util and apache. apr-util already had a fixup for this, but apache did not, which was causing the gcc from apr-util per-package directories be used during the apache build, causing build failures. To fix this, we adjust this libtool script to point to the correct tools in apache's per-package directories. There are no autobuilder failures for this, because Apache needs apr-util, and apr-util currently fails to build when BR2_PER_PACKAGE_DIRECTORIES=y. Signed-off-by:
-
Thomas Petazzoni authored
With per-package directories support enabled, the build of apr-util fails, for two reasons: - The rules.mk file is generated by the 'apr' package, and then copied into the 'apr-util' source directory. This is done by the 'apr-util' build process. Unfortunately, this rules.mk file has a number of hardcoded paths: to the compiler and to the libtool script. Due to this, the compiler from the 'apr' per-package directory gets used. But this compiler uses the 'apr' package sysroot, which does not have all the dependencies of the 'apr-util' package, causing the build to fail because <expat.h> is not found. - Similarly, the libtool script itself has some hardcoded paths, which make it use the compiler/linker from the 'apr' per-package directory, so it does not find the expat library. We fix both issues by doing the necessary replacement in both rules.mk and libtool. Fixes: http://autobuild.buildroot.net/results/2a67b5d58f79348e20a972125e4797eff5585716/ Signed-off-by:
-
James Hilliard authored
Fixes: Thread 1 "cog" received signal SIGSEGV, Segmentation fault. xkb_state_update_mask (state=0x0, base_mods=0, latched_mods=0, locked_mods=0, base_group=base_group@entry=0, latched_group=latched_group@entry=0, locked_group=0) at ../src/state.c:814 814 prev_components = state->components; Signed-off-by:
James Hilliard <james.hilliard1@gmail.com> Acked-by:
Adrian Perez de Castro <aperez@igalia.com> Signed-off-by:
-
Thomas De Schampheleire authored
Fixes CVE-2019-20388: xmlSchemaPreRun in xmlschemas.c in libxml2 2.9.10 allows an xmlSchemaValidateStream memory leak. Signed-off-by:
Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by:
-
Fabrice Fontaine authored
Commit 88bb278d forgot to propagate the new host gcc >= 4.9 dependency from BR2_PACKAGE_LIBSIGROKCXX Fixes: - http://autobuild.buildroot.org/results/5dc9dc95d0534b35e2443c120162b5176edafe0b Signed-off-by:
-
Peter Korsgaard authored
Fixes the following security issues (12.15.0): - CVE-2019-15606: HTTP header values do not have trailing OWS trimmed - CVE-2019-15605: HTTP request smuggling using malformed Transfer-Encoding header - CVE-2019-15604: Remotely trigger an assertion on a TLS server with a malformed certificate string For more details, see the advisory: https://nodejs.org/en/blog/vulnerability/february-2020-security-releases/ On top of this, 12.16.0 brings a number of changes and bugfixes. Update the license hash for an addition of the (MIT) licensing terms for the uvwsai module: + +- uvwasi, located at deps/uvwasi, is licensed as follows: + """ + MIT License + + Copyright (c) 2019 Colin Ihrig and Contributors + + Permission is hereby granted, free of charge, to any person obtaining a copy + of this software and associated documentation files (the "Software"), to deal + in the Software without restriction, including without limitation the rights + to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + copies of the Software, and to permit persons to whom the Software is + furnished to do so, subject to the following conditions: + + The above copyright notice and this permission notice shall be included in all + copies or substantial portions of the Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + SOFTWARE. + """ While we are at it, adjust the white space in the .hash function to match the new agreements. Signed-off-by:
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/ad7fb68ae87850a85509eed80fd0cae8721b10c5 Signed-off-by:
-
Fabrice Fontaine authored
Commit 64c42c5e removed the hook for creating the m4local directory with the assumption that it would be created because the first include is treated in a special way if it doesn't exists However, this assumption was wrong as m4local is the second include, the first one is m4 (which already exists in the archive). So put back the hook. The other solutions would be to patch: - Makefile.{am,in} to remove m4local - configure.ac and Makefile.{am,in} to add m4local before m4 However, both solutions don't seem to be upstreamable Fixes: - http://autobuild.buildroot.org/results/e40313c6ec193d6156e26eff62303545fba09413 Signed-off-by:
-
- Feb 17, 2020
-
-
Thomas De Schampheleire authored
The package instrumentation step 'step_pkg_size' is populating the files: output/build/packages-file-list.txt output/build/packages-file-list-staging.txt output/build/packages-file-list-host.txt by comparing the list of files before and after installation of a package, with some clever tricks to detect changes to existing files etc. As an optimization, instead of gathering this list before and after each package, where the 'after-state' of one package is the same as the 'before-state' of the next package, only the 'after-state' is used and is shared between packages. This works fine, except at the end of the build, as explained next. In the target-finalize step, many files will be touched. For example, files like /etc/hosts, /etc/os-release, but also all object files that are stripped, and all files touched by post-build scripts or created by rootfs overlays. This means that the 'after-state' of the last package does not reflect the actual situation after target-finalize is run. For a single complete build this poses no problem. But, if one incrementally rebuilds a package after the initial build, e.g. with 'make foo-rebuild', then all changes that happened in target-finalize at the end of the initial build (the 'after-state' of the last package built) will be detected as changes caused by the rebuild of package foo. As a result, all these files will incorrectly be treated as 'owned' by package foo. Correct this situation by capturing a new state at the end of target-finalize, so that the 'before-state' of an incremental build will be correct. Note: the reasoning above talks about packages-file-list.txt and target-finalize, but also applies to packages-file-list-staging.txt/staging-finalize and packages-file-list-host.txt/host-finalize. Signed-off-by: -
Yegor Yefremov authored
Reorder imports using the isort utility to fix a warning from pylint3: wrong-import-order: standard import "import multiprocessing" should be placed before "import nose2" Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
-
Yann E. MORIN authored
Commit 12c0f68c (package/nfs-utils: bump version to 2.4.3) added an extra empty line, causing check-package to whine: package/nfs-utils/nfs-utils.mk:27: consecutive empty lines Signed-off-by:
Yann E. MORIN <yann.morin.1998@free.fr>
-
- Feb 16, 2020
-
-
Romain Naour authored
The current Buildroot defconfigs for qemu_x86 and qemu_x86_64 instantiate a console on tty1, which appears on QEMU's graphical window. Add a console on the serial port (ttyS0) to be used later for gitlab testing. This change is need since the script used for gitlab testing needs to use a serial output with pexpect. This change is similar to the one made for raspberrypi [1] to handle HDMI and serial console: This requires three changes: 1. have two 'console=' entries in the kernel command line: tty1, then ttyS0; 2. change BR2_TARGET_GENERIC_GETTY_PORT to "console", so it starts a getty on the last console= passed to the kernel, ttyS0; 3. add a new getty on tty1 to the generated inittab. Step 2 is actually obtained by removing BR2_TARGET_GENERIC_GETTY_PORT entirely from the defconfigs, since "console" is the default value. Step 3 requires a post-build script since the Buildroot makefiles can configure only one console. Note: instead of simply adding a new getty on ttyS0 (which would work) this patch actually changes BR2_TARGET_GENERIC_GETTY_PORT to instantiate a console on UART, then adds back tty1 via post-build.sh. This is done only to avoid the "GENERIC_SERIAL" comment where we instantiate a console on QEMU graphical window, then instantiate a really-serial console on another line. The result is these two inittab lines: console::respawn:/sbin/getty -L console 0 vt100 # GENERIC_SERIAL tty1::respawn:/sbin/getty -L tty1 0 vt100 # QEMU graphical window [1] 20878a10 Signed-off-by:Romain Naour <romain.naour@smile.fr> Signed-off-by:
-
Romain Naour authored
The commit [1] added host-qemu package for each qemu defconfig for gitlab runtime testing. [1] 29e1cb88 Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Romain Naour authored
This defconfig was generated by savedefconfig but we usually use a manually modified defconfig to add some comments for Kconfig symbols. No content change intended. Signed-off-by:
-
Adam Duskett authored
Other changes: - Update License hash which properly adds the OpenSSL exception. Tested with Debian 8: br-arm-full [1/6]: OK br-arm-cortex-a9-glibc [2/6]: OK br-arm-cortex-m4-full [3/6]: SKIPPED br-x86-64-musl [4/6]: OK br-arm-full-static [5/6]: SKIPPED sourcery-arm [6/6]: OK Signed-off-by:Adam Duskett <aduskett@gmail.com> Signed-off-by:
-
Adam Duskett authored
Other changes: - Remove upstream patches - Update COPYING.LIB hash as upstream updated the file to match the new LGPL 2.1 license from upstream. See: https://github.com/qemu/qemu/commit/f0d44cc4462f112bce5ec556e87eff4eec682e39 Signed-off-by:Romain Naour <romain.naour@gmail.com> [Peter: change libssh2 to libssh as pointed out by Vincent Fazio] Signed-off-by:
-
Giulio Benetti authored
Bump to version 2.4.3 of nfs-utils. All patches have been upstreamed, so drop them all. It now needs rpcgen built by host-nfs-utils, to do this let's pass its path to --with-rpcgen= instead of 'internal'. Signed-off-by:
Giulio Benetti <giulio.benetti@benettiengineering.com> Reviewed-by:
Petr Vorel <petr.vorel@gmail.com> Tested-by:
-
Giulio Benetti authored
For a minor fix. Signed-off-by:
-
Fabrice Fontaine authored
Fixes version parsing for release-monitoring.org support Signed-off-by:
-
Yegor Yefremov authored
According to PEP8 empty sequences should be checked as booleans. Fixes the following PEP8 warning: Do not use `len(SEQUENCE)` to determine if a sequence is empty Signed-off-by:
-
Peter Korsgaard authored
Signed-off-by: -
Peter Korsgaard authored
Commit de591c5c (package/wireguard-linux-compat: new package) split up the wireguard package in wireguard-tools and wireguard-linux-compat, but forgot to update the conditional in linux.mk, so the kernel config fixups needed for wireguard are no longer applied. Update the conditional to use the BR2_PACKAGE_WIREGUARD_LINUX_COMPAT symbol instead. Signed-off-by:
-
Peter Korsgaard authored
Fixes a regression introduced in 0.0.20200214. For details, see the announcement: https://lists.zx2c4.com/pipermail/wireguard/2020-February/005014.html Signed-off-by:
-
Fabrice Fontaine authored
- Remove patch (already in version) - Update indentation of hash file (two spaces) Signed-off-by:
-
James Hilliard authored
Signed-off-by:
-
James Hilliard authored
Signed-off-by:
-
James Hilliard authored
Signed-off-by:
-
James Hilliard authored
Signed-off-by:
-
Fabrice Fontaine authored
- Update indentation of hash file (2 spaces) - This will fix a build failure without threads thanks to https://github.com/cminyard/gensio/commit/8918de5b30f90b826c48064e9ee92304b63ffe85 and associated upstream patch Fixes: - http://autobuild.buildroot.org/results/e94d0e0b46afc1223a74bcc471909f4adef0d6f3 Signed-off-by:
-
Fabrice Fontaine authored
Update indentation of hash file (two spaces) Signed-off-by:
-
James Hilliard authored
License hash change is due to date update. Signed-off-by:
-
James Hilliard authored
Signed-off-by:
-
Peter Korsgaard authored
Fixes the following security issues: - CVE-2020-3862: Impact: A malicious website may be able to cause a denial of service. Description: A denial of service issue was addressed with improved memory handling. - CVE-2020-3864: Impact: A DOM object context may not have had a unique security origin. Description: A logic issue was addressed with improved validation. - CVE-2020-3865: Impact: A top-level DOM object context may have incorrectly been considered secure. Description: A logic issue was addressed with improved validation. - CVE-2020-3867: Impact: Processing maliciously crafted web content may lead to universal cross site scripting. Description: A logic issue was addressed with improved state management. - CVE-2020-3868: Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling. For more details, see the advisory: https://wpewebkit.org/security/WSA-2020-0002.html While we are at it, adjust the white space in the .hash function to match the new agreements. Signed-off-by:
-
Peter Korsgaard authored
CMakeLists.txt contains a toolchain check: if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU") if (${CMAKE_CXX_COMPILER_VERSION} VERSION_LESS "7.3.0") message(FATAL_ERROR "GCC 7.3 or newer is required to build WebKit. Use a newer GCC version or Clang.") endif () endif () So bump the toolchain dependency to >= GCC 7. The check is really about >= 7.3.0, but we do not have such detailed version checks. Given that GCC 7.3.0 was released in January 2018 (and 7.1.0 in May 2017), most external GCC 7.x toolchains probably use >= 7.3.0. Signed-off-by: -
Peter Korsgaard authored
Fixes the following security issues: - CVE-2020-3862: Impact: A malicious website may be able to cause a denial of service. Description: A denial of service issue was addressed with improved memory handling. - CVE-2020-3864: Impact: A DOM object context may not have had a unique security origin. Description: A logic issue was addressed with improved validation. - CVE-2020-3865: Impact: A top-level DOM object context may have incorrectly been considered secure. Description: A logic issue was addressed with improved validation. - CVE-2020-3867: Impact: Processing maliciously crafted web content may lead to universal cross site scripting. Description: A logic issue was addressed with improved state management. - CVE-2020-3868: Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling. For more details, see the advisory: https://webkitgtk.org/security/WSA-2020-0002.html While we are at it, adjust the white space in the .hash function to match the new agreements. Signed-off-by:
-
Peter Korsgaard authored
CMakeLists.txt contains a toolchain check: if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU") if (${CMAKE_CXX_COMPILER_VERSION} VERSION_LESS "7.3.0") message(FATAL_ERROR "GCC 7.3 or newer is required to build WebKit. Use a newer GCC version or Clang.") endif () endif () So bump the toolchain dependency to >= GCC 7. The check is really about >= 7.3.0, but we do not have such detailed version checks. Given that GCC 7.3.0 was released in January 2018 (and 7.1.0 in May 2017), most external GCC 7.x toolchains probably use >= 7.3.0. Signed-off-by:
-
