- Apr 09, 2018
-
-
Peter Korsgaard authored
Signed-off-by:Peter Korsgaard <peter@korsgaard.com>
-
Baruch Siach authored
Fixes CVE-2018-1000156: arbitrary command execution in ed-style patches. Depend on MMU for now, because the patch adds a fork() call. Upstream later switched to gnulib provided execute(), so this dependency can be dropped on the next version bump. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com> (cherry picked from commit f4a4df20) Signed-off-by:
-
Rafal Susz authored
Custom dts files are still conditionally copied based on non existing boolean. So it is currently not possible to use custom dts file(s) at all. List of dts files is now iterated and files are copied into dedicated kernel arch dir. Signed-off-by:
Rafal Susz <rafal.susz@gmail.com> Tested-by:
Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by:
-
Yann E. MORIN authored
The host directory no longer uses /usr. This currently works because we still have the legacy /usr symlink, but for correctness it is better that we just fix it. Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
-
Thomas Petazzoni authored
zend_alloc.h defines some macros such as: Where _estrdup is the actual function implemented by the PHP core. If this header file is not included, and some code uses estrdup, one ends up with an undefined reference. This happens when libexpat support is enabled. This commit adds a PHP patch that fixes this issue. The patch has been submitted upstream through a Github pull request. Fixes: http://autobuild.buildroot.net/results/889d2c1f509c035cd506e36061939bfddc8f1500/ Signed-off-by:
-
André Hentschel authored
Security fixes since 2.2.12: - wnpa-sec-2018-15 The MP4 dissector could crash. (Bug 13777) - wnpa-sec-2018-16 The ADB dissector could crash. (Bug 14460) - wnpa-sec-2018-17 The IEEE 802.15.4 dissector could crash. (Bug 14468) - wnpa-sec-2018-18 The NBAP dissector could crash. (Bug 14471) - wnpa-sec-2018-19 The VLAN dissector could crash. (Bug 14469) - wnpa-sec-2018-20 The LWAPP dissector could crash. (Bug 14467) - wnpa-sec-2018-23 The Kerberos dissector could crash. (Bug 14576) - wnpa-sec-2018-05 The IEEE 802.11 dissector could crash. Bug 14442, CVE-2018-7335 - wnpa-sec-2018-06 Multiple dissectors could go into large infinite loops. All ASN.1 BER dissectors (Bug 14444), along with the DICOM (Bug 14411), DMP (Bug 14408), LLTD (Bug 14419), OpenFlow (Bug 14420), RELOAD (Bug 14445), RPCoRDMA (Bug 14449), RPKI-Router (Bug 14414), S7COMM (Bug 14423), SCCP (Bug 14413), Thread (Bug 14428), Thrift (Bug 14379), USB (Bug 14421), and WCCP (Bug 14412) dissectors were susceptible. - wnpa-sec-2018-07 The UMTS MAC dissector could crash. Bug 14339, CVE-2018-7334 - wnpa-sec-2018-09 The FCP dissector could crash. Bug 14374, CVE-2018-7336 - wnpa-sec-2018-10 The SIGCOMP dissector could crash. Bug 14398, CVE-2018-7320 - wnpa-sec-2018-11 The pcapng file parser could crash. Bug 14403, CVE-2018-7420 - wnpa-sec-2018-12 The IPMI dissector could crash. Bug 14409, CVE-2018-7417 - wnpa-sec-2018-13 The SIGCOMP dissector could crash. Bug 14410, CVE-2018-7418 - wnpa-sec-2018-14 The NBAP disssector could crash. Bug 14443, CVE-2018-7419 Full release notes: https://www.wireshark.org/docs/relnotes/wireshark-2.2.14.html Signed-off-by:
André Hentschel <nerv@dawncrow.de> Signed-off-by:
-
- Apr 08, 2018
-
-
Fabio Estevam authored
Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Fabio Estevam authored
Signed-off-by:
-
Joshua Henderson authored
Instead of using the install of sam-ba under host/opt directly, use the symlink created in host/bin. The side effect of doing this instead allows the correct sam-ba binary to be used based on the host arch being 32 bit or 64 bit. Signed-off-by:
Joshua Henderson <joshua.henderson@microchip.com> Signed-off-by:
-
Thomas Petazzoni authored
When the internal PCRE library of PHP is used, it tries to use a JIT engine, which is only available on some architectures. However, the mechanism used to disable JIT has changed in recent PHP versions, and it now has a proper --without-pcre-jit option. Switch over to that to properly disable JIT on unsupported platforms. It has been tested to fix the build of PHP on ARC and Microblaze. Fixes: http://autobuild.buildroot.net/results/e1359fcad7bc57e3c5a7ecc37abaa2cf6a6a9ffa/ Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by:
-
Thomas Petazzoni authored
The BR2_PACKAGE_POSTGRESQL option depends on BR2_USE_MMU, so the Config.in comment about the dynamic library dependency should only be displayed if the BR2_USE_MMU requirement is met. Signed-off-by:
-
Giulio Benetti authored
Setting EGLFS_DEVICE_INTEGRATION at the end of qmake.conf like is done by commit 0c219ddb doesn't work correctly: it has to be set before the include(../common/linux_device_post.conf) Instead of appending to the file, change it into a qmake.conf.in template file that contains a placeholder for the EGLFS_DEVICE_INTEGRATION assignment and update it with sed. Since the sed always has to be executed, this removes the need for a separate QT5BASE_CONFIGURE_QMAKE_CONFIG definition. Signed-off-by:
Giulio Benetti <giulio.benetti@micronovasrl.com> [Arnout: simplify the replacement, move sunxi-mali support to a separate patch] Signed-off-by:
Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> (cherry picked from commit 81fb33af) Signed-off-by:
-
Peter Korsgaard authored
No functional change, but upstream has now tagged the release, so use the tag instead of the sha1. https://github.com/webpy/webpy/issues/449 Signed-off-by:
-
Peter Korsgaard authored
>From the changelog: 2018-02-28 0.39 * Fixed a security issue with the form module (tx Orange Tsai) * Fixed a security issue with the db module (tx Adrián Brav and Orange Tsai) 2016-07-08 0.38 .. * Fixed a potential remote exeution risk in `reparam` (tx Adrián Brav) License files are still not included on pypi, so continue to use the git repo. Upstream has unfortunately not tagged 0.39, so use the latest commit on the 0.39 branch. A request to fix this has been submitted: https://github.com/webpy/webpy/issues/449 0.39 now uses setuptools, so change the _SETUP_TYPE. Add hashes for the license files. Signed-off-by:
-
Peter Korsgaard authored
webpy uses hashlib for session handling, so ensure it is available: web/session.py: import hashlib web/session.py: sha1 = hashlib.sha1 Signed-off-by:
-
Stefan Becker authored
Signed-off-by:
Stefan Becker <chemobejk@gmail.com> Tested-by:
Joseph Kogut <joseph.kogut@gmail.com> Signed-off-by:
-
The license information in qt5script was just copied from all the other qt5 modules, but it is different (and complicated). - libQt5Script itself contains the third-party JavaScriptCore source. JavaScriptCore has a number of licenses: BSD-2-Clause, BSD-3-Clause, LGPL-2.0+, LGPL-2.1+. Since it is all linked together, the end result will be BSD-3-Clause and LGPL-2.1+. The different BSD licenses are all slightly different (different authors, which affects the third clause in particular). Only one separate license file is provided, so let's use that one. There is an LGPL-2.0 license file, which is slightly different from the top-level LICENSE.LGPLv21, so let's add that one as well. - libQt5Script also contains Qt-specific code which is all licensed under LGPL-2.1 only. This is covered by the LICENSE.LGPLv21 file. It merges with the LGPL-2.1+ from JavaScriptCore but limits it to 2.1 only. - libQt5ScriptTools is a separate libary containing just the script debugger. It is covered by the usual Qt license: * LGPL-2.1 or LGPL-3.0 with exception for Qt 5.6; * LGPL-3.0 or GPL-2.0+ for Qt 5.9 (actually it is GPL-2.0 or GPL-3.0 or any later version approved by the KDE Qt foundation, but let's keep it simple :-). Note that there is no LICENSE.GPLv2 provided, only LICENSE.GPLv3. Also, there is an LGPL_EXCEPTION.txt file but no mention of an exception anywhere in the sources. Update the license information with all of the above. Also add hashes for the new license files from JavaScriptCore. Signed-off-by: -
Peter Korsgaard authored
Fixes: http://autobuild.buildroot.net/results/b18/b187e64a61918f17f69588e2355a03286bc5808e tar 1.27 subtly changed the tar format when a GNU long link entry is added (which is done for path elements > 100 characters). The code used to set the permission mode of the link entry to 0: header = start_private_header ("././@LongLink", size, time (NULL)); FILL (header->header.mtime, '0'); FILL (header->header.mode, '0'); FILL (header->header.uid, '0'); FILL (header->header.gid, '0'); FILL (header->header.devmajor, 0); FILL (header->header.devminor, 0); This got dropped in 1.27 by commit df7b55a8f6354e3 (Fix some problems with negative and out-of-range integers), so the settings from start_private_header() are used directly - Which are: TIME_TO_CHARS (t < 0 ? 0 : min (t, MAX_OCTAL_VAL (header->header.mtime)), header->header.mtime); MODE_TO_CHARS (S_IFREG|S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH, header->header.mode); UID_TO_CHARS (0, header->header.uid); GID_TO_CHARS (0, header->header.gid); The end result is that tar >= 1.27 sets mode to 644. The consequence of this is that we create different tar files when long path names are encountered (which often happens when a package downloads a specific sha1 from a git repo) depending on the host tar version used, causing hash mismatches. As a workaround, bump our minimum tar version to 1.27. It would be nicer to only do this if we have packages from bzr/git/hg enabled, but that is an exercise for later. Signed-off-by:
-
Christopher McCrory authored
From ReleaseNotes156: """ This is a bugfix release, but it primarily disables the UDP protocol by default. In the last few days reports of UDP amplification attacks utilizing inesure memcached instances have surfaced. Attackers are able to set large values into memcached, then send requests via spoofed UDP packets. Memcached will then send a very large number of very large UDP packets back in response. """ Signed-off-by:
Christopher McCrory <chrismcc@gmail.com> Signed-off-by:
-
Christopher McCrory authored
Install the motion.config file were the program expects it to be. From the motion source code: snprintf(filename, PATH_MAX, "%s/motion/motion.conf", sysconfdir); Signed-off-by:
-
Gaël PORTAY authored
Adds WTF platform support for the 32-bits armv8-a architectures. Fixes: In file included from ./config.h:30:0, from ... ./wtf/Platform.h:323:6: error: #error "Not supported ARM architecture" # error "Not supported ARM architecture" ^~~~~ from this defconfig: BR2_arm=y BR2_cortex_a72=y BR2_ARM_FPU_VFPV3D16=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_NONE=y BR2_PACKAGE_QT5=y BR2_PACKAGE_QT5WEBKIT=y The patch is an adaptation of an upstream fix in version 5.212 of qtwebkit[1]. Unfortunately, the commit cannot be backported and has to be fixed since the toolchain does not define __ARM_ARCH_8__ but __ARM_ARCH_8A__. $ host/bin/arm-buildroot-linux-gnueabihf-g++ -dM -E - < /dev/null | grep ARM_ARCH #define __ARM_ARCH_ISA_ARM 1 #define __ARM_ARCH_8A__ 1 #define __ARM_ARCH_PROFILE 65 #define __ARM_ARCH_ISA_THUMB 2 #define __ARM_ARCH 8 #define __ARM_ARCH_EXT_IDIV__ 1 [1]: https://github.com/qt/qtwebkit/blob/35655d5f4bad248ead1700b59c381cc568b4e98b/Source/WTF/wtf/Platform.h#L241-L242 Cc: Arnout Vandecappelle <arnout@mind.be> Reported-by:
Brock Williams <brock@cottonwoodcomputer.com> Reviewed-by:
Adrian Perez de Castro <aperez@igalia.com> Signed-off-by:
Gaël PORTAY <gael.portay@savoirfairelinux.com> Signed-off-by:
-
Waldemar Brodkorb authored
Since gcc 4.6, GCC deprecated -mfused-madd, -ffp-contract=off should be used for the Xburst workaround. Tested with the MIPS Sourcery 2011.03 toolchain (based on gcc 4.5), the toolchain wrapper uses -mno-fused-madd, as expected: $ BR2_DEBUG_WRAPPER=2 ./output/host/bin/mips-linux-gnu-gcc -o toto toto.c Toolchain wrapper executing: '/home/thomas/toolchains/mips-2011.03/bin/mips-linux-gnu-gcc' '--sysroot' '/home/thomas/projets/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot' '-mabi=32' '-msoft-float' '-mno-fused-madd' '-EL' '-march=mips32r2' '-o' 'toto' 'toto.c' And with the MIPS Sourcery 2012.09 toolchain (based on gcc 4.7), the toolchain wrapper uses -ffp-contract=off, as expected: $ BR2_DEBUG_WRAPPER=2 ./output/host/bin/mips-linux-gnu-gcc -o toto toto.c Toolchain wrapper executing: '/home/thomas/toolchains/mips-2012.09/bin/mips-linux-gnu-gcc' '--sysroot' '/home/thomas/projets/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot' '-mabi=32' '-msoft-float' '-ffp-contract=off' '-EL' '-march=mips32r2' '-o' 'toto' 'toto.c' Fixes the ci20_defconfig build: https://gitlab.com/buildroot.org/buildroot/-/jobs/60303132 Signed-off-by:Waldemar Brodkorb <wbx@openadk.org> [Thomas: rework to continue supporting pre-gcc-4.6 toolchains, extend the commit log after doing more testing.] Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Thomas De Schampheleire authored
In current Buildroot, clashes occur between the variables _NAME and _BASE_NAME for two packages called foo and foo-base, i.e. Package foo: FOO_NAME = foo FOO_BASE_NAME = foo-1.2.3 Package foo-base: FOO_BASE_NAME = foo-base FOO_BASE_BASE_NAME = foo-base-4.5.6 where variable FOO_BASE_NAME is clashing between these two packages. Specific cases where this clash is already existing are: - alljoyn-base - alljoyn-tcl-base - perl-xml-sax-base The problem is generic and can occur for a number of variables in Buildroot. A non-exhaustive list: <pkg>_BASE and <pkg>_BASE_NAME <pkg>_BASE_NAME and <pkg>_RAW_BASE_NAME <pkg>_DIR and <pkg>_DL_DIR <pkg>_VERSION and <pkg>_DL_VERSION <pkg>_SOURCE and <pkg>_TARGET_SOURCE <pkg>_INSTALL_IMAGES and <pkg>_TARGET_INSTALL_IMAGES (same for _STAGING and _TARGET) <pkg>_LICENSE_FILES and <pkg>_MANIFEST_LICENSE_FILES <pkg>_DEPENDENCIES and <pkg>_FINAL_DEPENDENCIES One solution is to use another separator than '_' to separate the package name from the rest of the variable name. For example, a double underscore: FOO__NAME FOO__BASE_NAME FOO_BASE__NAME FOO_BASE__BASE_NAME However, making that change for only this case means that the variable naming is no longer consistent. And making the change for all variables has a large impact, also on certain user scripts. For now, keep it simple, and rename FOO_BASE_NAME into FOO_BASENAME, so that the variables become: FOO_NAME FOO_BASENAME FOO_BASE_NAME FOO_BASE_BASENAME For consistency, also adapt FOO_RAW_BASE_NAME. Since FOO_RAW_BASENAME would still pose a conflict with a package called 'foo-raw', take the opportunity to rename it into FOO_BASENAME_RAW instead, which does not pose a conflict as we have no variable called FOO_RAW. Signed-off-by:Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by:
Sam Voss <sam.voss@rockwellcollins.com> Signed-off-by:
-
Thomas Petazzoni authored
It should be "host gnupg" and not "host-gnupg" to be consistent with all other Config.in.host options. Signed-off-by:
-
Peter Korsgaard authored
Fixes #10856 The SSE_GENERIC target fails to build with a "sgemm_kernel.o: No such file or directory" error. Several upstream bug reports exist for this: https://github.com/xianyi/OpenBLAS/issues/502 https://github.com/xianyi/OpenBLAS/issues/685 In both cases, upstream suggests using a different target definition instead. E.G. from issue 685: You may use NORTHWOOD on x86: make TARGET=NORTHWOOD that uses SSE2 instructions. It's very hard to find non-SSE2 x86 CPUs today. For x86-64 use the PRESCOTT target So drop the SSE_GENERIC target. The only x86_64 variant we support not covered by a more specific openblas target is the default variant, nocona and jaguar. Nocona was a Xeon variant of the P4 "Prescott" architecture, so use the PRESCOTT openblas target: https://en.wikipedia.org/wiki/Xeon#Nocona_and_Irwindale Jaguar is from the Bobcat family, so use the BOBCAT openblas target: https://en.wikipedia.org/wiki/List_of_AMD_microprocessors#Bobcat_core_architecture_(APU) [Peter: add Jaguar as pointed out by Arnout] Signed-off-by:
-
Sasha Shyrokov authored
When the OpenCV3 Python support is enabled with Python 3.x, it builds properly, and the resulting .so file is built for the target architecture, but its name is wrong: output/target/usr/lib/python3.6/site-packages/cv2.cpython-36m-x86_64-linux-gnu.so This prevents Python 3.x from importing the module: >>> import cv2 Traceback (most recent call last): File "<stdin>", line 1, in <module> ModuleNotFoundError: No module named 'cv2' In order to fix this, we simply need to pass PKG_PYTHON_DISTUTILS_ENV in the environment. The Python module then gets named: output/target/usr/lib/python3.6/site-packages/cv2.cpython-36m-arm-linux-gnueabi.so And can be imported properly: >>> import cv2 >>> This solution was suggested by Arnout Vandecappelle in https://stackoverflow.com/questions/49059035/buildroot-opencv3-python-package-builds-for-the-wrong-target . With Python 2.x, the module is named just cv2.so so this problem isn't visible. However, for consistency, we also pass PKG_PYTHON_DISTUTILS_ENV when building against Python 2.x, by putting the OPENCV3_CONF_ENV assignment inside the BR2_PACKAGE_OPENCV3_LIB_PYTHON condition, but outside the BR2_PACKAGE_PYTHON3/BR2_PACKAGE_PYTHON condition. Signed-off-by:
Sasha Shyrokov <alexander-shyrokov@idexx.com> [Thomas: extend the commit log, apply the solution to Python 2.x.] Signed-off-by:
-
Bernd Kuhls authored
https://git.buildroot.net/buildroot/commit/?id=266208972192f1e0869f89d7be941de6294a810a broke imx support in Kodi because previously the G2D libraries were part of the imx-gpu-viv package: CMake Error at /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find IMX (missing: G2D_LIBRARY) Adjusting the Kodi package to use the imx-gpu-g2d as well still does not provide a working build: /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'void CIMX::Deinitialize()': /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:79:21: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0); ^~~~~~~~~~~~~~~~~~~ /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'bool CIMX::UpdateDCIC()': /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:109:19: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0); ^~~~~~~~~~~~~~~~~~~ /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:115:21: error: 'DCIC_IOC_START_VSYNC' was not declared in this scope ioctl(m_fddcic, DCIC_IOC_START_VSYNC, 0); ^~~~~~~~~~~~~~~~~~~~ /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp: In member function 'virtual void CIMX::Process()': /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:125:19: error: 'DCIC_IOC_START_VSYNC' was not declared in this scope ioctl(m_fddcic, DCIC_IOC_START_VSYNC, 0); ^~~~~~~~~~~~~~~~~~~~ /home/buildroot/br4/output/build/kodi-17.6-Krypton/xbmc/linux/imx/IMX.cpp:131:19: error: 'DCIC_IOC_STOP_VSYNC' was not declared in this scope ioctl(m_fddcic, DCIC_IOC_STOP_VSYNC, 0); ^~~~~~~~~~~~~~~~~~~ Although it might be possible to fix these bugs with something like #define DCIC_IOC_CONFIG_DCIC _IO('D', 12) #define DCIC_IOC_START_VSYNC _IO('D', 15) #define DCIC_IOC_STOP_VSYNC _IO('D', 16) as done in https://raw.githubusercontent.com/LibreELEC/LibreELEC.tv/libreelec-7.0/projects/imx6/patches/kodi/imx6-jarvis.patch we would still try to ride a dead horse. The upcoming Kodi version 18.0-Leia will remove imx support completely, see upstream PR 12990. Signed-off-by:
Bernd Kuhls <bernd.kuhls@t-online.de> Reviewed-by:
Gary Bisson <gary.bisson@boundarydevices.com> [Thomas: keep an explicit -DENABLE_IMX=OFF in CONF_OPTS.] Signed-off-by:
-
Bernd Kuhls authored
According to imx-vpu-5.4.37/Makefile, line 6: INCLUDE_LIST:= IMX27ADS IMX51 IMX53 IMX6Q imx6s is not supported by the imx-vpu package. Its install target, guarded by ifeq ($(PLATFORM), $(findstring $(PLATFORM), $(INCLUDE_LIST))) does nothing, causing a build error later on in the imx-vpuwrap package checking for vpu_lib.h... no configure: error: lib_vpu is required, consider installing imx-lib Signed-off-by:
-
Valentin Korenblit authored
When imake is installed on the host, it tries to include freetype headers from host, so we must override ac_cv_path_IMAKE to avoid this. Extract from config.log: configure:14803: checking if we should use imake to help configure:14820: result: yes configure:14829: checking for xmkmf configure:14846: found /usr/bin/xmkmf configure:14857: result: /usr/bin/xmkmf configure:14920: testing Using /usr/bin/xmkmf ... configure:15015: testing IMAKE_CFLAGS -I. -I/usr/include/freetype2 Signed-off-by:
Valentin Korenblit <valentin.korenblit@smile.fr> [Thomas: pass ac_cv_path_IMAKE="" as suggested by Romain Naour.] Reviewed-by:
Romain Naour <romain.naour@smile.fr> Signed-off-by:
-
Peter Korsgaard authored
Fixes #10776 The upstream git repo contains a number of fixes for building against newer kernel versions, so bump the version. git shortlog eb66d40310c93dc82bc8eac889744c1ed1f01f7b.. Alain Kalker (2): uprobe: Print the symbol, not the matching pattern uprobe: Blacklist uretprobes on _start Aleksa Sarai (2): runtime: update GFP_WAIT to GFP_RECLAIM userspace: fix up argument parsing NULL dereference Alexey Makhalov (1): Fix building for v4.8 kernel Azat Khuzhin (12): Use get_unused_fd_flags(0) instead of get_unused_fd() Support trace_seq::seq Ignore separate debug files (*.dwo) Use trace_seq_has_overflowed() makefile: split vim plugins installing into separate target makefile: use DESTDIR for install (allow to change install dir) makefile: install: create dirs makefile: use ldflags for linking ktap makefile: add CPPFLAGS to KTAPC_CFLAGS, to allow change default flags ignore: exclude /debian Support compilation for 4.2 (ftrace_events cleanup) runtime: fix building on 4.3 Jovi Zhangwei (11): Merge pull request #84 from azat/linux-3.19-fixes-v3 Merge pull request #85 from azat/debian-preparations-v2 Merge pull request #88 from NanXiao/master Merge pull request #89 from NanXiao/patch-1 Merge pull request #91 from NanXiao/patch-1 Merge pull request #90 from azat/linux-4.2-compilation-fixes Merge pull request #99 from cyphar/fix-null-deref Merge pull request #98 from cyphar/fix-gfp-reclaim Merge pull request #97 from azat/fix-building-4.3-__GFP_RECLAIM Merge pull request #103 from ackalker/blacklist Merge pull request #104 from YustasSwamp/master Nan Xiao (3): Update tutorial.md Update Makefile Fix memory leak issue in main function. WEI ZHANG (1): ktap: Change the copyright to Huawei Technologies While we are at it, also add a hash for the license file. Signed-off-by:
-
- Apr 07, 2018
-
-
Fabio Estevam authored
Signed-off-by:
-
- Apr 06, 2018
-
-
Fabio Estevam authored
Signed-off-by:
-
Thomas Petazzoni authored
A number of autobuilder failures are due to the fact that autobuilder instances use old distributions, with old SSL certificates, and therefore wget aborts with an error "The certificate of `xyz.org' is not trusted.". In order to avoid such failures that are not very interesting in the context of the autobuilders, we pass --no-check-certificate to wget. The integrity of the downloaded files is anyway verified by the hashes, and this is only meant to be used in the context of testing/CI, not in production. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Peter Korsgaard authored
Fixes the following security issues: - Fix for inspector DNS rebinding vulnerability (CVE-2018-7160): A malicious website could use a DNS rebinding attack to trick a web browser to bypass same-origin-policy checks and allow HTTP connections to localhost or to hosts on the local network, potentially to an open inspector port as a debugger, therefore gaining full code execution access. The inspector now only allows connections that have a browser Host value of localhost or localhost6. - Fix for 'path' module regular expression denial of service (CVE-2018-7158): A regular expression used for parsing POSIX paths could be used to cause a denial of service if an attacker were able to have a specially crafted path string passed through one of the impacted 'path' module functions. - Reject spaces in HTTP Content-Length header values (CVE-2018-7159): The Node.js HTTP parser allowed for spaces inside Content-Length header values. Such values now lead to rejected connections in the same way as non-numeric values. While we are at it, also add a hash for the license file. Signed-off-by:
-
Yann E. MORIN authored
Currently, when a filename contains characters not representable in the user's locale, we fail hard, especially when the host python is python3. This is because python2 and python3 handle encoding/decoding strings differently, with python3 presumable doing the right thing, but it breaks on some systems, while python2 presumable does the wrong thing, but it works everywhere. (Just joking, obviously...) Part of the issue being that the csv reader in python2 is broken with UTF8. We fix the issue by ditching the csv reader, and simply read the file in binary mode, manually partitioning the lines on the first comma. Then, we use the binary-encoded (really, un-encoded) package names and filenames as values and keys, respectively. Finally, for each filename or package we need to print, we try to decode them with the defaults for the user settings, but catch any decoding exception and fall back to dumping the raw, binary values. Which codec is used by default differs between Python version, but in all cases something sane is printed at least. Thanks a lot to Arnout for the live help doing this patch. :-) Reported-by:
Jaap Crezee <jaap@jcz.nl> Signed-off-by:
-
Yann E. MORIN authored
Commit 4cd1ab15 (core: alternate solution to disable C++) made use of a non-existent 'no' binary when C++ is not available in the toolchain. However, some packages, like jimtcl as bundled in opeocd, really want to find the binary that $CXX contains. Revert openocd to use 'false' instead of 'no'. Fixes: http://autobuild.buildroot.org/results/cbd/cbd5ab97fb0659968ff628461130627cf1745955/ Signed-off-by:
-
Yann E. MORIN authored
Commit 4cd1ab15 (core: alternate solution to disable C++) made use of a non-existent 'no' binary when C++ is not available in the toolchain. However, some packages, like jimtcl, really want to find the binary that $CXX contains. Revert jimtcl to use 'false' instead of 'no'. Fixes: http://autobuild.buildroot.org/results/54f/54f3df03551fbdf293d33dc1e3f08005faa15321/ Signed-off-by:
-
Thomas Petazzoni authored
Commit c8680956 ("toolchain: fix detection of SSP support") fixed the SSP check so that it does the correct thing for nios2 toolchains. While this commit fixed the description of the Sourcery NIOSII toolchain, it didn't fix the description for the autobuilders of the br-nios2-glibc toolchain, causing some build failures. This commit adjusts br-nios2-glibc.config to indicate that the toolchain doesn't have SSP support. Fixes: http://autobuild.buildroot.net/results/6c44e328b7bffd8474d29d5bdf1ea109ec15f4ad/ Signed-off-by:
-
Rahul Bedarkar authored
zstd is dual licensed under BSD-3-Clause or GPL-2.0 as per README.md and source files license header. Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
-
