- Jun 01, 2020
-
-
Peter Korsgaard authored
Signed-off-by:Peter Korsgaard <peter@korsgaard.com>
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/da996e189220499b85efbdb541a891ac18db38c6 Signed-off-by:
Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by:
-
Matt Weber authored
Signed-off-by:
Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by:
-
Fabrice Fontaine authored
- Fix CVE-2020-13645: In GNOME glib-networking through 2.64.2, the implementation of GTlsClientConnection skips hostname verification of the server's TLS certificate if the application fails to specify the expected server identity. This is in contrast to its intended documented behavior, to fail the certificate verification. Applications that fail to provide the server identity, including Balsa before 2.5.11 and 2.6.x before 2.6.1, accept a TLS certificate if the certificate is valid for any host. - Update indentation in hash file (two spaces) Signed-off-by:
-
Fabrice Fontaine authored
LIBUSB_1_0_SONAME is detected since version 0.1.6 and https://github.com/libusb/libusb-compat-0.1/commit/b6f5a2fe12ca19d658d7180e106254b31cf1f8f5 The detection mechanism is based on sed, here are the more relevant parts: shrext_regexp=`echo "$shrext_cmds" | sed 's/\./\\\\./'` [...] [AS_VAR_SET([ac_Lib_SONAME], [`ldd conftest$ac_exeext | grep 'lib[$2]'$shrext_regexp | sed 's/^@<:@ \t@:>@*lib[$2]'$shrext_regexp'/lib[$2]'$shrext_regexp'/;s/@<:@ \t@:>@.*$//'`])]) However, this mechanism is broken with sed 4.7 and will return the following 'silent' error: checking for SONAME of libusb-1.0... sed: -e expression #1, char 40: Invalid back reference unknown Moreover, it also raises the following build failure on one of the autobuilder because an empty line is added to LIBUSB_1_0_SONAME: checking for SONAME of libusb-1.0... checking libusb-1.0.so.0 checking for GNU extensions of errno.h... no configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating libusb.pc config.status: creating libusb-config config.status: creating Makefile config.status: creating libusb/Makefile config.status: creating examples/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing default commands configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --disable-nls configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline [7m>>> libusb-compat 0.1.7 Building[27m PATH="/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/bin:/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/sbin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1 /usr/local/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin" /usr/bin/make -j8 -C /usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7/ make[1]: Entering directory `/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7' Makefile:284: *** missing separator. Stop. We could patch patch m4/au_check_lib_soname.m4 to fix the mechanism however this is difficult without reproducing the autobuilder failure and upstream seems dead so just set LIBUSB_1_0_SONAME Fixes: - http://autobuild.buildroot.org/results/12d771d85d30594929cfe3e1c783fc70857e7f5f Signed-off-by:
Yann E. MORIN <yann.morin.1998@free.fr>
-
- May 31, 2020
-
-
Yann E. MORIN authored
When the linux-headers are configured to use the same source as the kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the kernel sources are not already downloaded: $ cat defconfig BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y $ make defconfig BR2_DEFCONFIG=$pwd)/defconfig $ make linux-headers-source >>> linux-headers 4.19.118-cip25 Downloading --2020-05-13 19:28:44-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176 Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-13 19:28:45 ERROR 404: Not Found. make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1 make: *** [Makefile:23: _all] Error 2 We fix that by adding yet another duplication of information out of the linux.mk, to use the CIP-specific git tree where to get the archives as snapshots. Signed-off-by:Thomas Petazzoni <thomas.petazzoni@bootlin.com>
-
Yann E. MORIN authored
The soon-to-be-released linux 5.7 has changed the way it detects the ability of gcc to use plugins, when it dropped support for gcc 4.7 or older [0]. To detect the ability to use gcc plugins, the kernel has to check whether the host gcc is capable enough to build them. When we call one of the configurator for the Linux kernel, we explicitly pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a discrepancy between the ncurses headers and libraries as found by the Linux kconfig build [1] [2]. But then, when we build the kernel, we pass another value to use [3] HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib This is needed so that at build time, the kernel can build host tools that link with our openssl et al. So, the two HOSTCC we pass to the kernel may have different behaviours. For example, on a machine where gmp is missing in the system, it is available in $(O)/host/ when using an internal toolchain (and under a few other conditions). In that case, when configuring the kernel, it decides that the host compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS are not met, and that option is not present in the linux' .config file (neither as "=y" nor as "is not set"). But then, when we build the kernel, the host compiler suddenly becomes capable of building the plugins, and the internal syncconfig run by the kernel will notice that the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user shall decide on its value. And this blocks a build on an interactive console (abbreviated): * Restart config... * GCC plugins GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _ But most problematic is the behaviour when run in a shell that is not interactiove (e.g. a CI job or such) (abbreviated): * Restart config... * GCC plugins GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) Error in reading or end of file. Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) Error in reading or end of file. Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW) Error in reading or end of file. * Memory initialization Initialize kernel stack variables at function entry > 1. no automatic initialization (weakest) (INIT_STACK_NONE) 2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW) 3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW) 4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW) choice[1-4?]: Error in reading or end of file. Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW) Error in reading or end of file. Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n The most obvious and simple solution would be to unconditionally disable gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work either, because after applying the fixups, we call olddefconfig (or the likes) with the incapable HOSTCC, so the disabled option would be removed anyway, and we'd be back to square one. So, in addition to the above, we also forcibly hack the same call just before actually building the kernel. Note that the two are needed: the one in the fixups is needed for those that have a system that already allows building gcc plugins, and the second is needed in the other case, where the system does not allow it but would work with our additional headers and libs in $(O)/host/. The two ensure there is a very similar experience in the two situations. Forcibly disabling the use of gcc plugins is not a regression on our side: it has never been possible to do so so far. We're now making sure that can't work by accident. Reported-by:Ganesh <ganesh45in@gmail.com>,> Reported-by:
Heiko Thiery <heiko.thiery@gmail.com> Signed-off-by:
-
Romain Naour authored
While cross-compiling, qt5webengine is building a host tool, 'gn', and by default wants to link it statically with libstdc++, when the tool is otherwise dynamically linked with other libraries: $ ldd 3rdparty/gn/out/Release/gn linux-vdso.so.1 (0x00007ffc1c999000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f48a3c06000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f48a3be4000) libc.so.6 => /lib64/libc.so.6 (0x00007f48a3a1b000) /lib64/ld-linux-x86-64.so.2 (0x00007f48a3c53000) Not all ditributions have the static libraries installed by default; for example, on Fedora, libstdc++-static is not installed on a fresh system, leading to build issues: [185/185] LINK gn FAILED: gn /usr/bin/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl /usr/bin/ld : unable to find -lstdc++ [...] Project ERROR: GN build error! The root cause is the addition in [0] of a command line option to the build of gn, that requests static linking with libstdc++ by default. Explicitly pass that option now, to avoid static linking with libstdc++ and get a fully dynamicallty linked executable: $ ldd 3rdparty/gn/out/Release/gn linux-vdso.so.1 (0x00007ffd3f160000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f68138e7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68138c5000) libc.so.6 => /lib64/libc.so.6 (0x00007f68136fc000) libm.so.6 => /lib64/libm.so.6 (0x00007f68135b6000) /lib64/ld-linux-x86-64.so.2 (0x00007f6813b13000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f681359c000) [0] https://github.com/qt/qtwebengine-chromium/commit/cfab9198a9917f42cf08b1caf84ab9b71aac1911#diff-905c8f054808213577c0a92d1b704615 Signed-off-by:Romain Naour <romain.naour@gmail.com> Cc: Gaël Portay <gael.portay@collabora.com> [yann.morin.1998@free.fr: - rewrite the commit log with extra details and explanations ] Signed-off-by:
-
Romain Naour authored
As reported by several Buildroot users [1][2][3], the gcc build may fail while running selftests makefile target. The problem only occurs when ccache is used with gcc 9 and 10, probably due to a race condition. While debuging with "make -p" we can notice that s-selftest-c target contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4]. s-selftest-c: cc1 While the build is failing, the s-selftest-c dependencies recipe is still running and reported as a bug by make. "Dependencies recipe running (THIS IS A BUG)." A change [5] in gcc 9 seems to introduce the problem since we can't reproduce this problem with gcc 8. As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before including language makefile fragments. With the fix applied, the s-seltest-c dependency contains SELFTEST_DEPS value. s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html [3] https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108 [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120 [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502 [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html Signed-off-by:
-
Heiko Thiery authored
The current script (S51sysrepo-plugind) is not able to stop the daemon. Possible options to fix the problem: A) By adding the "-m -p $PIDFILE" option to start the pid file will be created but it will not contain the correct PID used by the daemon. This is obviously because the daemon forks. B) By not starting the daemon in background (sysrepo-plugind -d) and let do it by start-stop-daemon with "-b" option. But then the log messages of the daemon will not longer ends in the syslog but to stderr. C) Start the daemon without a pidfile and stop the daemon with the "-x" option. The only valid option is C to fix that. Signed-off-by:
-
Carlos Santos authored
Goodbye! Signed-off-by:
Carlos Santos <unixmania@gmail.com> Signed-off-by:
-
Fabrice Fontaine authored
- Fix CVE-2020-11739: An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. - Fix CVE-2020-11740: An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (without active profiling) to obtain sensitive information about other guests. Unprivileged guests can request to map xenoprof buffers, even if profiling has not been enabled for those guests. These buffers were not scrubbed. - Fix CVE-2020-11741: An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (with active profiling) to obtain sensitive information about other guests, cause a denial of service, or possibly gain privileges. For guests for which "active" profiling was enabled by the administrator, the xenoprof code uses the standard Xen shared ring structure. Unfortunately, this code did not treat the guest as a potential adversary: it trusts the guest not to modify buffer size information or modify head / tail pointers in unexpected ways. This can crash the host (DoS). Privilege escalation cannot be ruled out. - Fix CVE-2020-11742: An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of bad continuation handling in GNTTABOP_copy. Grant table operations are expected to return 0 for success, and a negative number for errors. The fix for CVE-2017-12135 introduced a path through grant copy handling where success may be returned to the caller without any action taken. In particular, the status fields of individual operations are left uninitialised, and may result in errant behaviour in the caller of GNTTABOP_copy. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to copy a grant, it hits the incorrect exit path. This returns success to the caller without doing anything, which may cause crashes or other incorrect behaviour. - Fix CVE-2020-11743: An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of a bad error path in GNTTABOP_map_grant. Grant table operations are expected to return 0 for success, and a negative number for errors. Some misplaced brackets cause one error path to return 1 instead of a negative value. The grant table code in Linux treats this condition as success, and proceeds with incorrectly initialised state. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to map a grant, it hits the incorrect error path. This will crash a Linux based dom0 or backend domain. https://xenproject.org/downloads/xen-project-archives/xen-project-4-13-series/xen-project-4-13-1 Signed-off-by:
-
Fabrice Fontaine authored
Fixes: - http://autobuild.buildroot.org/results/14937c96a82fb3d10e5d83bd7b2905b846fb09f9 Signed-off-by:
-
- May 30, 2020
-
-
Romain Naour authored
The commit [1] "licensing info is only valid for v1.4" fixed the legal-info issues when a custom ATF tarball or a version from git is used. But we need to ignore licencing for a used defined official ATF version. Althougt the ATF version are licensed under BSD-3-Clause, the license file can be updated between version (for example between v1.4 and v2.0). Ignore the licencing check if the user provide a custom official version. [1] d1a61703 Signed-off-by:
-
- May 29, 2020
-
-
Yann E. MORIN authored
Now that Freescale has been wholly swallowed into NXP, the public-facing git repositories that were hosting those two packages are no longer available. Fortunately, they had been mirrored on Code Aurora forge (a Linux Foundation project, so relatively stable and trustworthy), which has the tags we need, and that generates the exact same archives. Signed-off-by:
-
Peter Korsgaard authored
Signed-off-by: -
Fabrice Fontaine authored
- Switch site to an active fork - Send patch upstream - Update indentation in hash file (two spaces) - Fix the following CVEs: - CVE-2018-14054: A double free exists in the MP4StringProperty class in mp4property.cpp in MP4v2 2.0.0. A dangling pointer is freed again in the destructor once an exception is triggered. Fixed by https://github.com/TechSmith/mp4v2/commit/f09cceeee5bd7f783fd31f10e8b3c440ccf4c743 - CVE-2018-14325: In MP4v2 2.0.0, there is an integer underflow (with resultant memory corruption) when parsing MP4Atom in mp4atom.cpp. Fixed by https://github.com/TechSmith/mp4v2/commit/e475013c6ef78093055a02b0d035eda0f9f01451 - CVE-2018-14326: In MP4v2 2.0.0, there is an integer overflow (with resultant memory corruption) when resizing MP4Array for the ftyp atom in mp4array.h. Fixed by https://github.com/TechSmith/mp4v2/commit/70d823ccd8e2d7d0ed9e62fb7e8983d21e6acbeb - CVE-2018-14379: MP4Atom::factory in mp4atom.cpp in MP4v2 2.0.0 incorrectly uses the MP4ItemAtom data type in a certain case where MP4DataAtom is required, which allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted MP4 file, because access to the data structure has different expectations about layout as a result of this type confusion. Fixed by https://github.com/TechSmith/mp4v2/commit/73f38b4296aeb38617fa3923018bb78671c3b833 - CVE-2018-14403: MP4NameFirstMatches in mp4util.cpp in MP4v2 2.0.0 mishandles substrings of atom names, leading to use of an inappropriate data type for associated atoms. The resulting type confusion can cause out-of-bounds memory access. Fixed by https://github.com/TechSmith/mp4v2/commit/51cb6b36f6c8edf9f195d5858eac9ba18b334a16 Signed-off-by: -
Fabrice Fontaine authored
Fix the following CVEs: - CVE-2019-17533: Mat_VarReadNextInfo4 in mat4.c in MATIO 1.5.17 omits a certain '\0' character, leading to a heap-based buffer over-read in strdup_vprintf when uninitialized memory is accessed. - CVE-2019-20017: A stack-based buffer over-read was discovered in Mat_VarReadNextInfo5 in mat5.c in matio 1.5.17. - CVE-2019-20018: A stack-based buffer over-read was discovered in ReadNextCell in mat5.c in matio 1.5.17. - CVE-2019-20020: A stack-based buffer over-read was discovered in ReadNextStructField in mat5.c in matio 1.5.17. - CVE-2019-20052: A memory leak was discovered in Mat_VarCalloc in mat.c in matio 1.5.17 because SafeMulDims does not consider the rank==0 case. Signed-off-by:
-
- May 28, 2020
-
-
Thomas Petazzoni authored
This commit backports an upstream patch made for gnupg2 into gnupg, in order to fix build failures with gcc 10 due to the use of -fno-common. Due to the code differences between upstream gnupg2 and the old gnupg 1.x, the backport is in fact more a rewrite than an actual backport. Fixes: http://autobuild.buildroot.net/results/496a18833505dc589f7ae58f2c7e5fe80fe9af79/ Signed-off-by:
-
Romain Naour authored
Installing qt5declarative examples on fast/fast/multicore machines sometimes failes with a variation of the following error messages: - Cannot touch [...]/chapter5-listproperties/app.qml: No such file or directory - Error copying [...]/chapter2-methods/app.qml: Destination file exists Fix it by using OTHER_FILES instead of a seperate qml files install target to fix the race between install_target, install_qml and install_sources. Fixes: - https://gitlab.com/buildroot.org/buildroot/-/jobs/565470221 Signed-off-by:
Peter Seiderer <ps.report@gmx.net> Reviewed-by:
-
- May 27, 2020
-
-
Heiko Thiery authored
Added upstream patch for fixing build failure when using GCC10 as a host compiler (-fno-common is now default). Fixes: http://autobuild.buildroot.net/results/47f/47fcf9bceba029accdcf159236addea3cb03f12f/ Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by:
-
Heiko Thiery authored
Added upstream patch for fixing build failure when using GCC10 as a host compiler (-fno-common is now default). Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by:
-
Yegor Yefremov authored
In version 5.6 a minor change was made to this file, stating tht "[a]ll contributions to the Linux Kernel are subject to this COPYING file", and hence the hash changed. We can update the hash, because the licensing information is only accounted for the "latest" version, so the hash change will not impact older kernel versions as the user would have to switch to a non-latest kernel. Signed-off-by:
Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by:
-
- May 26, 2020
-
-
Fabrice Fontaine authored
This patch was wrongly removed when bumping the version to 1.4.0 in commit 6976f312 Fixes: - http://autobuild.buildroot.org/results/7a53a59dd08c043f371bea967c3b450a7bddcde8 Signed-off-by:
-
Fabio Estevam authored
The default iamge size is 32MiB, which is quite low by today's standards. Besides, the AArch64 kernels are relatively big, which leaves not much room, if at all, for users to experiment on the default image. Increase the vfat size to a more reasonable 64MiB. Note that users who derive an in-tree defconfig for their own case will allways hit any arbitarary size we put here, so they will anyway have to also derive this template for their own use-cases. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Romain Naour authored
As reported by Nicolas Carrier on the Buildroot mailing list [1], there is a new build issue while building a program which interacts with the u-boot environment. This program uses the headers of the ubootenv library provided by uboot-tools. This is an upstream change from uboot [2] adding "#include <env.h>" to fw_env.h. Adding env.h require a board configuration to build. But only fw_env.h header is installed in the staging directory by uboot-tools package, but since it now include env.h the build is broken because env.h is missing from the staging directory. It's seems an upstream bug since env_set() is not used in fw_env tool. Nicolas removed env.h from fw_env tool and fixed it's build issue. This problem is present since uboot v2019.10, so the uboot version present in Buildroot 2020.02 is affected. It's probably not a problem for upstream uboot but it's a problem for uboot-tools package that build uboot tools without a board configuration for the target. [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html [2] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e Reported-by:
Nicolas Carrier <nicolas.carrier@orolia.com> Signed-off-by:
-
Heiko Thiery authored
Added upstream patch for fixing build failure when using GCC10 as a host compiler (-fno-common is now default). Fixes: http://autobuild.buildroot.net/results/c4b/c4bba80e9fc476247c7ba28850831c6a8edd559f/build-end.log Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by:
-
Thomas Petazzoni authored
Pull a patch pending in an upstream pull request to fix the detection of the snappy library when we are in static linking configurations. Fixes: https://bugs.busybox.net/show_bug.cgi?id=12671 Signed-off-by:
-
Thomas Petazzoni authored
snappy is not a mandatory dependency to build leveldb. Back when it was introduced in Buildroot, as of version 1.18, the build logic already made snappy an optional dependency. Signed-off-by:
-
James Hilliard authored
Libdrm freedreno depends on BR2_arm || BR2_aarch64 || BR2_aarch64_be as such we need to propagate those dependencies to mesa's gallium freedreno driver. Signed-off-by:
James Hilliard <james.hilliard1@gmail.com> Signed-off-by:
-
James Hilliard authored
According to https://prosody.im/doc/depends#bitop the correct bitop package to use with prosody for Lua 5.1 is: https://luarocks.org/modules/siffiejoe/bit32 As such replace BR2_PACKAGE_LUABITOP with BR2_PACKAGE_LUA_BIT32 Signed-off-by:
-
Thomas Petazzoni authored
So far in 2020, Logilin and Tap2Open made some financial donations to the Buildroot Association, so let's thank them on our sponsors page. Signed-off-by: -
Fabrice Fontaine authored
Hash was not updated by commit 18079e20 Fixes: - http://autobuild.buildroot.org/results/0f7179ed4706f05551af330d7f12b3efaeffd278 Signed-off-by:
-
Peter Korsgaard authored
Signed-off-by:
-
- May 25, 2020
-
-
Heiko Thiery authored
With commit 89f5e989 support for reproducible archives was added. Thus archives generated from svn do no longer needs to be added to BR_NO_CHECK_HASH_FOR. Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by:
-
Fabrice Fontaine authored
This bump contains only one commit that fix a build failure with asm: https://github.com/ckolivas/lrzip/commit/844b8c057c8c7372ca41ad2efdbf849f45c24506 Fixes: - http://autobuild.buildroot.org/results/800d8a97966ef75dbf20e85ec8a02766ba02cc76 Signed-off-by:
-
Romain Naour authored
We have a qemu fork for csky cpus [1] but since qemu version bump to 4.2.0 [2] and libssh2/libssh change the csky build is broken. The csky fork is based on Qemu 3.0.0 but unlike autotools packages any unknown option is handled as error. Since we don't want to support all options from previous qemu release and the github repository has been removed [3] and the only remaining archive is located on http://sources.buildroot.net, remove the qemu csky fork as suggested by [4]. [1] https://git.buildroot.net/buildroot/commit/?id=f816e5b276f1ef15840bec6667f1e8219717ab7d [2] https://git.buildroot.net/buildroot/commit/?id=0ea17054ce7dfc54efca5634133cef786445e7b1 [3] https://github.com/c-sky/qemu [4] http://lists.busybox.net/pipermail/buildroot/2020-May/281885.html Signed-off-by:
-
Yann E. MORIN authored
The author has completely ripped off the git tree, so the sources are no longer available, with that message: "Please look for alternatives for wiringPi" And indeed there is a better alternative, using the kernel GPIO subsystem and drivers. Note that queezelite looses that functionality now, but upstream squeezelite has done changes to do without wiringpi (hint for an upgrade?). Signed-off-by: -
Yann E. MORIN authored
The original git server on git.xiph.org died, and the Xiph project has now moved on to host their repositories on gitlab.comn instead. Signed-off-by:
-
Yann E. MORIN authored
The git repositories are not served on the kernel.org CDN: fatal: repository 'https://cdn.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/ ' not found Switch to explicitly use the git.kernel.org server. Signed-off-by:
-
