- Dec 05, 2021
-
-
Peter Korsgaard authored
Signed-off-by:Peter Korsgaard <peter@korsgaard.com>
-
Joachim Wiberg authored
This bump is mainly to fix the header file nameclash problem with LiTE, in package/lite. See the libite project's README for how to adapt to this change, and the ChangeLog for details. In short, libite now use the /usr/include/libite/*.h prefix. Signed-off-by:
Joachim Wiberg <troglobit@gmail.com> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by:
Yann E. MORIN <yann.morin.1998@free.fr>
-
Joachim Wiberg authored
This addresses the autobuilder failure for master as per 2021-11-27. The root cause was a name clash in a dependency, the libite library, clashing with the DirectFB LiTE library header files. Hence, this update alone does not fix [1], libite also needs to be updated. To provide a smooth transition though, watchdogd should be updated first. [1]: http://autobuild.buildroot.net/results/185c753af2aa159b494b13f78b0826dddbe4aed6 Signed-off-by:
-
Sébastien Szymanski authored
Do the same as commit "12c01079 package/stress-ng: bump to version 0.13.05" did for 2022.02 but without the version bump. The project URL returns 404 error because: Quoting Coling King: "Unfortunately when I left Canonical last week they removed my tarballs" So use github and update hash. Signed-off-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Ricardo: do not bump the version. There will be no version clash at sources.buildroot.net since the file format changed] Signed-off-by:
Ricardo Martincoski <ricardo.martincoski@datacom.com.br> Cc: Romain Naour <romain.naour@gmail.com> Signed-off-by:
Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
-
Markus Mayer authored
We define _DEFAULT_SOURCE in mkpasswd.c to suppress a compiler warning. In file included from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33, from /usr/include/stdio.h:27, from [...]/buildroot/output/arm64/build/host-mkpasswd/mkpasswd.c:24: /usr/include/features.h:187:3: 187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" | ^~~~~~~ As per GLIBC 2.20 release notes[1]: The _BSD_SOURCE and _SVID_SOURCE feature test macros are no longer supported; they now act the same as _DEFAULT_SOURCE (but generate a warning). Except for cases where _BSD_SOURCE enabled BSD interfaces that conflicted with POSIX (support for which was removed in 2.19), the interfaces those macros enabled remain available when compiling with _GNU_SOURCE defined, with _DEFAULT_SOURCE defined, or without any feature test macros defined. [1] https://lwn.net/Articles/611162/ Signed-off-by:Markus Mayer <mmayer@broadcom.com> Signed-off-by:
-
Bartosz Bilas authored
Fixes: /usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here Signed-off-by:
Bartosz Bilas <b.bilas@grinn-global.com> Reviewed-by:
Marcin Niestroj <m.niestroj@grinn-global.com> Signed-off-by:
-
Bartosz Bilas authored
Fixes: include/image.h:1178:12: fatal error: openssl/evp.h: No such file or directory 1178 | # include <openssl/evp.h> | ^~~~~~~~~~~~~~~ Signed-off-by: -
Fabrice Fontaine authored
Fixes: - https://bugs.buildroot.org/show_bug.cgi?id=14351 Signed-off-by:
Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by:
-
Yann E. MORIN authored
Commit 82d1e8c6 (boot/grub2: use none platform when building for host) changed host-grub2 to only install the tools, not the actual bootloader or its modules, as they are of no use on the host. It so happened that, when not instructed to built for a specific platform, the grub2 buildsystem would default to build the legacy bios platform (at least when the build happens on an x86 or x86_64 host). However, because the host is more often than not an x86 or x86_64, when the target was also an x68 or x86_64, the modules built for the host could be re-used for the target, and this is what was done for our pc_x86_64_bios_defconfig. But now that we explicitly tell the grub2 buildsystem to not build any platform when we build host-grub2, we no longer have access to the grub2 modules from the host directory, and the build fails when assembling the final image. We fix that in two ways: First, we ensure that individual modules from the target grub2 get installed in target/; we can only do that if the target grub2 tools are also installed, so we enable that in the configuration. Second, we fix the post-build script to look in target/ rather than in host/. All that, just for the 512-byte boot.img bootstrap, which pulls in all the other modules (4.3MiB), the tools (8.8MiB)... But we are not going to cherry-pick individual modules; this is error prone and unmaintainable... Reported-by:
Adam Duskett <aduskett@gmail.com> Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:apache:portable_runtime is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Aapache%3Aportable_runtime Signed-off-by:
-
Yann E. MORIN authored
Some last-minute changes were made when applying commits 7a68960b (boot/grub2/Config.in: add symbols to represent legacy and EFI boot) and 4d5b2093 (package/mender-grubenv: fix grub module checks), and the renaming of the BR2_TARGET_GRUB_LEGACY was not fully propagated. This caused the path to the boot files to always be interpreted as being the EFI one, and never the legacy one. In practice, that was not causing any build failure, because the path was passed at build-time to mender-grubenv, that would use it as the location where to install its files, and finally as the location where our image-isntall commands would look for them. Still this is incorrect because it would not match where grub2 would eventually end up lookig for its files at runtime... To avoid further issue, drop the conditional block dedicated to setting the path to the boot files, drop the intermediate variable, and move setting the environment variable down into the existing conditional block. We do drop the intermediate variable, because there is no longer any genericity needed: the installation commands are already duplicated for the two cases anyway. Reported-by:
-
- Dec 04, 2021
-
-
Fabrice Fontaine authored
cpe:2.3:a:exfat_project:exfat is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Aexfat_project%3Aexfat Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:hiawatha-webserver:hiawatha is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Ahiawatha-webserver%3Ahiawatha Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:hp:linux_imaging_and_printing_project is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Ahp%3Alinux_imaging_and_printing_project Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:libatomic_ops_project:libatomic_ops is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Alibatomic_ops_project%3Alibatomic_ops Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:gnome:libgee is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Agnome%3Alibgee Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:libunwind_project:libunwind is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Alibunwind_project%3Alibunwind Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:xiph:speex is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Axiph%3Aspeex Signed-off-by:
-
Joachim Wiberg authored
Upstream maintainer, now also maintainer in Buildroot. Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:unixodbc:unixodbc is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Aunixodbc%3Aunixodbc Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:rarlab:unrar is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Ararlab%3Aunrar Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:kernel:util-linux is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Akernel%3Autil-linux Inherit the values from util-linux; they really are, and have to be, the same. Signed-off-by:
-
Yann E. MORIN authored
Commit 0cfa1659 (package/pkg-utils.mk: introduce "name" field in show-info output) did what it said, but did so in the generic show-info part, thus it was also added to filesystems (rootfs), the other kind of entity that show-info reports on. Only packages have a "name"; filesystems do not. Instead, they already have an 'image_name'. Move the 'name' field to the package-related part of show-info. Signed-off-by:
-
Yann E. MORIN authored
The unmatched escaped single-quote lies in the middle of a few function calls, so they too must be fake-closed to properly fix colour highlighting in some editors. Signed-off-by: -
Yann E. MORIN authored
Some packages install nothing in target nor staging, but install images (like the kernel vmlinux, or a bootloader boot blob...) If we want to appropriately account for the files installed by each package, we also need to take images/ into account. Signed-off-by:
-
Yann E. MORIN authored
When calling 'printvars', the 'suitable-host-package' macro is printed (a macro is just a variable like the others, after all, just with some parameters). Because it is printed as a variable, it is missing its parameters, but it still tries to evaluate the $(shell) construct. This causes spurious warning: make[1]: support/dependencies/check-host-.sh: Command not found Only try and call the script if there is actually a tool to check for. Signed-off-by: -
Yann E. MORIN authored
When calling 'printvars' on a just-configured tree, the output contains many spurious warnings about pkg-config being not found: make[1]: [...]/host/bin/pkg-config: Command not found This is partly because a few packages call pkg-config at the time the Makefile is parsed (really, right when make evaluates the recipe before executing it). It is customary, instead, to defer the call to pkg-config to the actual shell running the recipe's commands, like all our other packages do. Signed-off-by: -
Yann E. MORIN authored
Currently, the build_dir field is reported relative to $(BASE_DIR), to avoid leaking local paths. However, BASE_DIR is not a directory that is very convenient: for in-tree builds, it is $(CONFIG_DIR)/output/, while for out-of-tree builds, it is $(CONFIG_DIR). This difference is purely an idiosyncracy of how out-of-tree builds have been implemented in Buildroot, and is not under the control of the user. What the user is in control of, however, is where the .config file is located. This, really, is the directory we should base relative paths on. Reported-by:
-
Adam Duskett authored
Commit b68810e7 (boot/grub2: add support to build multiple Grub2 configurations in the same build) broke mender-grubenv by splititng up BR2_TARGET_GRUB2_BUILTIN_MODULES into two separate symbols, one for legacy boot and one for EFI boot. This change causes a systematic build failure now, as the legacy variable BR2_TARGET_GRUB2_BUILTIN_MODULES is now always empty (during build). We fix that by supplicating the missing modules to check: one for EFI and one for legacy boot. The EFI check is tricky: Indeed, there can be more than one EFI platform enabled simultaneously; indeed, on x86_64, we can have both the 32-bit and 64-bit EFI platforms enabled. So the check is inverted, and we check that no platform is not enabled (yeah, double negation). For consistency, we do the same for the legacy boot, even though in that case, there can only ever be only one enabled at once at most. Furthermore, mender-grubenv does not support multiple installations of grub concurrently; it can only be installed for either legacy or EFI, not both at the same time: /etc/mender-grubenv.cfg, its configuration file, can only contain settings for one or the other, not both. So we add a new check to Config.in to support only one grub installation type at a time. Signed-off-by:
-
Yann E. MORIN authored
The help was missing the regexp module. The variable assignment was missing spaces around the equal sign. Signed-off-by:
-
Adam Duskett authored
There are cases to want a synthetic information whether the legacy BIOS or U-Boot boot scheme, or the EFI boot scheme, are enabled, without resorting to testing all and each platforms. This is already the cae in grub2 itself, for the configuration of the BIOS/U-Boot boot partition, and builtin modules and configuration on one hand, and the EFI builtin modules and configuraiton on the other hand. It is also the case for mender-grubenv, which will want to know if either or both are enabled, but without having to resort to testing all the cases. Add two new symbols, that each represent those conditions: * BR2_TARGET_GRUB2_HAS_LEGACY_BOOT * BR2_TARGET_GRUB2_HAS_EFI_BOOT Each target selects the appropriate bool, which makes it much more simple for other packages such as mender-grubenv to check if grub legacy or EFI is selected. And of course, we also make use of those symbols in grub2 itself, to simplify the conditions for showing.hiding legacy and EFI options. Additionally (but that does not merit being in its own patch), add a comment on the closing 'endif' for the EFI part. Signed-off-by:
-
Fabrice Fontaine authored
Fix the following build failure on uclibc-ng and musl raised since bump to version 6.1.0 in commit 33c69c02: ../block/export/fuse.c: In function 'fuse_fallocate': ../block/export/fuse.c:643:21: error: 'FALLOC_FL_ZERO_RANGE' undeclared (first use in this function) 643 | else if (mode & FALLOC_FL_ZERO_RANGE) { | ^~~~~~~~~~~~~~~~~~~~ Fixes: - http://autobuild.buildroot.org/results/6d102f005cfaeba582a78a11460bf38014f56bf9 - http://autobuild.buildroot.org/results/be24433a429fda681fb66698160132c1c99bc53b Signed-off-by:
-
Fabrice Fontaine authored
Fix CVE-2021-4020: janus-gateway is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Signed-off-by: -
Fabrice Fontaine authored
This reverts commit 8ae9156d as those CVEs are not tagged as affecting gnu:coreutils in NVD NIST database but opensuse:opensuse and redhat:entreprise_linux: - https://nvd.nist.gov/vuln/detail/CVE-2013-0221 - https://nvd.nist.gov/vuln/detail/CVE-2013-0222 - https://nvd.nist.gov/vuln/detail/CVE-2013-0223 Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:netdata:netdata is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Anetdata%3Anetdata Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:mini-xml_project:mini-xml is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Amini-xml_project%3Amini-xml Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:motion_project:motion is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Amotion_project%3Amotion Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:mozilla:netscape_portable_runtime is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Amozilla%3Anetscape_portable_runtime Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:oisf:libhtp is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Aoisf%3Alibhtp Signed-off-by:
-
Fabrice Fontaine authored
cpe:2.3:a:mono-project:libgdiplus is a valid CPE identifier for this package: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Amono-project%3Alibgdiplus Signed-off-by:
-
