bump: buildroot to 2024.11.x #169
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Drop patches which are now upstream. Drop no longer required python-six runtime dependency. Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Julien Olivain <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Julien Olivain <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Julien Olivain <[email protected]>
Signed-off-by: James Hilliard <[email protected]> [Julien: add "depends on BR2_ARCH_IS_64"] Signed-off-by: Julien Olivain <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Add new host-python-packaging build dependency. Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Due to a bug in the Config.in comment dependencies, the comment "*** picotool needs a toolchain w/ C++, threads, gcc >= 4.9 ***" is always shown even if all features are enabled. Fixes: d30c1e3 ("package/picotool: fix libusb dependencies") Signed-off-by: Cherniaev Andrei <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Bernd Kuhls <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Bernd Kuhls <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Bernd Kuhls <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
For change log, see: https://irssi.org/NEWS/#news-v1-4-5 This commit also adds the pgp key id used for the signature verification. Signed-off-by: Julien Olivain <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
For change log since v2.3.7, see: https://github.com/FluidSynth/fluidsynth/releases/tag/v2.4.0 Signed-off-by: Julien Olivain <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]>
With classic thread library, the build fails with: ../lib/igt_kmod.c:1090:21: error: implicit declaration of function 'pthread_mutexattr_setrobust'; did you mean 'pthread_mutexattr_settype'? [-Werror=implicit-function-declaration] igt-gpu-tools needs NPTL threads. Fixes: http://autobuild.buildroot.net/results/85311ce68ae1fff771ca00b434be1c4f8453d357/ Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 80e0f643e88afeccb69b679fe55677d8065445d8) Signed-off-by: Peter Korsgaard <[email protected]>
Since the bump of xxhash from 0.8.2 to 0.8.3 in Buildroot commit 4b8f2f3a5e45fe2962a9fcdb148d32198929e228, the host of host-php fails when host-xxhash has been built before. This is due to the fact that host-xxhash installs HOST_DIR/include/xxhash.h, and the PHP code has an internal xxhash.h, but due to the order of CFLAGS, the one from HOST_DIR/include/xxhash.h gets included instead of the internal xxhash.h from PHP. We initially tried to fix the order of CFLAGS, but that has proven to be challenging within the complicated PHP build system. Then, we opted for renaming the internal xxhash.h header of PHP, which we had implemented and were about to submit upstream. But while rebasing this fix on PHP's master, it turned out that PHP has an upstream commit "Sync headers installation", merged for PHP 8.4.0, which has the side effect of avoiding the issue. This commit moves xxhash.h into a subfolder, so it gets included as #include "xxhash/xxhash.h" now, which avoids the conflict with HOST_DIR/include/xxhash.h. Maybe not the best fix, but it does fix the issue and it's upstream. Since this patch is tweaking the PHP build system, we need to do the equivalent of "autoreconf" but in the PHP world. It was already done for the target package, we simply add the same logic for the host package. Fixes: http://autobuild.buildroot.net/results/583c054a564f90b8c884565070c5e17b43b89674/ Cc: James Hilliard <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 3a20dfb4267f3dc6b11a3993a6a6dcc3e5c2ed88) Signed-off-by: Peter Korsgaard <[email protected]>
The variable <pkg>_LINUX_CONFIG_FIXUPS defined in the cryptodev-linux... has no effect. Indeed, the variable is only named CRYPTODEV_LINUX_CONFIG_FIXUPS. But the variable name being <pkg>_LINUX_CONFIG_FIXUPS and the package name being CRYPTODEV_LINUX, the correct variable name is CRYPTODEV_LINUX_LINUX_CONFIG_FIXUPS. Prior to this commit, a configuration with cryptodev-linux enabled would result in: $ make VARS=PACKAGES_LINUX_CONFIG_FIXUPS printvars $ Aka, empty, while PACKAGES_LINUX_CONFIG_FIXUPS collects in package/pkg-generic.mk the value of the <pkg>_LINUX_CONFIG_FIXUPS variables from all enabled packages. With this patch applied: $ make VARS=PACKAGES_LINUX_CONFIG_FIXUPS printvars PACKAGES_LINUX_CONFIG_FIXUPS= @if ! grep -q '^CONFIG_CRYPTO=[my]' /; then /usr/bin/sed -i -e '/^\(# \)\?CONFIG_CRYPTO\>/d' / && echo 'CONFIG_CRYPTO=y' >> /; fi @if ! grep -q '^CONFIG_CRYPTO_USER_API_AEAD=[my]' /; then /usr/bin/sed -i -e '/^\(# \)\?CONFIG_CRYPTO_USER_API_AEAD\>/d' / && echo 'CONFIG_CRYPTO_USER_API_AEAD=y' >> /; fi $ As one would expect. Fixes: 4b12336 ("package/cryptodev-linux: needs CONFIG_CRYPTO_USER_API_AEAD") Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 9114d48b313744fd163e4eeea0f5b0407568e771) Signed-off-by: Peter Korsgaard <[email protected]>
The kernel option CONFIG_TRIM_UNUSED_KSYMS=y allows to trim unused kernel symbols... which basically prevents building external modules. This option has been enabled in the default MIPS architecture kernel defconfig since pretty much forever, and it causes build failures of all our external modules on MIPS in the autobuilders. To fix this in a global manner, we handle the problem in the kernel-module infrastructure, by appending to the <pkg>_LINUX_CONFIG_FIXUPS variable provided by the package. Fixes: http://autobuild.buildroot.net/results/c26abec4e24d06557079654b12825efb2211996f/ (cryptodev-linux) http://autobuild.buildroot.net/results/699c618730cb33f0ccf54f90e4b722198fd3d3bc/ (emlog) http://autobuild.buildroot.net/results/f1d5626f5698a955bf378217528fbf4f8f741435/ (rtl8812au-aircrack-ng) http://autobuild.buildroot.net/results/c9a507757ce3a01cd08d596cb519ee9f19caf77c/ (mdio-tools) Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 1d8d9e8d6cd824b2a43a0b92d71cfb25a3f9300a) Signed-off-by: Peter Korsgaard <[email protected]>
The build of GOI on Microblaze fails as qemu-user hangs forver when running the GOI programs. Considering how small Microblaze targets are, the use-case for GOI is very small if not inexistant, and it's unlikely anybody is ever going to debug this, so just disable GOI on Microblaze. This issue is causing timeouts in the autobuilders on a regular basis: http://autobuild.buildroot.net/?status=TIMEOUT&reason=gobject-introspection% Fixes: http://autobuild.buildroot.net/results/f8e5ef74478c63c89e7b99fb928b97ac4518f943/ Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 8548c7586a56938b2f52f5c41050441b53a457f0) Signed-off-by: Peter Korsgaard <[email protected]>
Offloading parser.parse_args() to a helper function does not bring much, if at all; it even is restrictive: indeed, we can't use parser.error() to report errors and thus have to resort to a canned print+return sequence... Signed-off-by: Yann E. MORIN <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit cdcb3f56e8d5b5f51cd12721feaf8679953547b1) Signed-off-by: Peter Korsgaard <[email protected]>
parser.error() reports a nice error message, that also displays a short reminder of the available options. Adapt the test-suite accordingly: previously, the error string was an exact string in the stdout list, while it now is a substring in one of the strings in stderr. The exit code changes, too. Signed-off-by: Yann E. MORIN <[email protected]> Cc: Julien Olivain <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 35f381b93e52895179569876b23a509c9a7e0225) Signed-off-by: Peter Korsgaard <[email protected]>
It is very common that get-developers be used with its stdin a pipe from
git-show:
git show |./utils-get-developers -
In this case, the '-' is superfluous: we can very easily deduce that the
user wants to read stdin as the patch.
So, if no other action was requested, and stdin is not a tty, use it as
the source of the patch, and thus '-' is then no longer required.
Signed-off-by: Yann E. MORIN <[email protected]>
Signed-off-by: Julien Olivain <[email protected]>
(cherry picked from commit d10d22221f93c2a1f5950045a4f95fbb4984d685)
Signed-off-by: Peter Korsgaard <[email protected]>
The list of reported developers is not ordered: that may leave the impression (when receiving a patch) that a Cc is more important than another, by virtue of being earlier in the list. Also, the ordering changes on every call. Report the developers in an alphabetically order, so that there is no confusion anymore, and so the ordering is reproducible across calls. Signed-off-by: Yann E. MORIN <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 3177ecd26096ab305c51620eb29b0e639f3133e9) Signed-off-by: Peter Korsgaard <[email protected]>
It is very common to use the output of get-developers to add cc: lines in the commit log. Add an option so that get-developers reports Cc: lines ready to be pasted in a commit log. That new option behaves similarly to the existing -e option: it only affects the output when parsing a patch. Signed-off-by: Yann E. MORIN <[email protected]> Cc: Julien Olivain <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 717f1fdaeb460c71f673a6ad6e82d16af878c188) Signed-off-by: Peter Korsgaard <[email protected]>
Commit ed12e2f (package/libvirt: add lxc and qemu options) introduced the definition of the 'qemu' user when the libvirt daemon is enabled, but unconditionally uses that user in its permissions table. When enabling libvirt without its qemu support, for example with the commands: cat <<EOF >.config BR2_aarch64=y BR2_PACKAGE_LIBVIRT=y BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y BR2_TARGET_ROOTFS_EXT2=y BR2_TOOLCHAIN_EXTERNAL=y EOF make olddefconfig make The build fails with output: >>> Generating filesystem image rootfs.ext2 ... makedevs: unknown user name: qemu Move the permissions needing the 'qemu' user under the same condition the 'qemu' user is defined under. It means that a few permissions needing root must also be moved, as they belong under a directory needing the 'qemu' user. It also moves a few qemu-related permissions introduced in that same commit. The list of qemu permissions is reordered alphabetically (the others are left unchanged). Of course, it also requires that the qemu-related directory and symlink be moved under the same condition as well. Reported-by: Alessandro <[email protected]> Signed-off-by: Yann E. MORIN <[email protected]> Cc: Jared Bents <[email protected]> [Julien: add the commands to reproduce the issue] Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit da9adec1491eefc618aab610615fe293899845fd) Signed-off-by: Peter Korsgaard <[email protected]>
Since commit 9c0c784 (support/dependencies: don't check for python on the host), we no longer check for a host python interpreter installed on the system. Drop the comment in support/dependencies/check-host-python3.sh, as it is now confusing. Signed-off-by: Yann E. MORIN <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 3722998a3d0b771154b5069798f55ff9ea2c81bd) Signed-off-by: Peter Korsgaard <[email protected]>
Buildroot commit
1f4b4ccde7ceb379010aeb93458792202622d64b ("package/opensc: security
bump to version 0.26.0") bumped opensc from 0.24 to 0.26, and the
build started failing with:
pkcs11-tool.c:7854:45: warning: implicit declaration of function 'EVP_bf_cbc'; did you mean 'EVP_sm4_cbc'? [-Wimplicit-function-declaration]
on configurations that have BR2_PACKAGE_LIBOPENSSL_ENABLE_BLOWFISH
disabled (it is not explicitly selected by this package).
Our initial fix was to simply select
BR2_PACKAGE_LIBOPENSSL_ENABLE_BLOWFISH, but when investigating when
EVP_bf_cbc() started being used in OpenSC, we discovered it has been
in use for a while... but in code that kept being disabled from
version to version as it was broken (upstream bug
OpenSC/OpenSC#1796), but it was apparently
forgotten to be disabled again for 0.26 (the issue is still
open). Therefore, we opted to continue disabling this known broken
part of the code, and submit an upstream PR for that
OpenSC/OpenSC#3303, which ultimately will
clarify what is the right fix.
In the mean time, this allows to fix the build issue.
Fixes:
http://autobuild.buildroot.net/results/ca51b3e8e3ac83e2a69814caa84d9862385b956f/
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Julien Olivain <[email protected]>
(cherry picked from commit 5d7ab604d24e13cfd6dd57ee95171fac0bf45b63)
Signed-off-by: Peter Korsgaard <[email protected]>
Fixes CVE-2024-53580. GHSA-2w89-5px3-fvx6 Release notes: https://github.com/esnet/iperf/releases/tag/3.18 Signed-off-by: Akhilesh Nema <[email protected]> [Julien: - fix CVE ID typo - fixed "make check-package" error in iperf3.hash ] Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit ad67ba25e229978ec06d6a836f4ad9aa89c73d25) Signed-off-by: Peter Korsgaard <[email protected]>
Release notes: https://lists.iana.org/hyperkitty/list/[email protected]/thread/IZ7AO6WRE3W3TWBL5IR6PMQUL433BQIE/ Rebased the patch and updated the hash URL. Signed-off-by: Akhilesh Nema <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit c994deab9fd357af0c1afadeba0944fe6322c073) Signed-off-by: Peter Korsgaard <[email protected]>
Release notes: https://lists.iana.org/hyperkitty/list/[email protected]/thread/IZ7AO6WRE3W3TWBL5IR6PMQUL433BQIE/ Updated the hash URL. Signed-off-by: Akhilesh Nema <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit b26bd08fc4d84c9dbbe4793422c790c9a9d136a6) Signed-off-by: Peter Korsgaard <[email protected]>
We are seeing build issues with linux-pam in the autobuilders such as:
md5_crypt.c: In function 'Goodcrypt_md5':
md5_crypt.c:145:13: error: implicit declaration of function 'asprintf'; did you mean 'vsprintf'? [-Wimplicit-function-declaration]
145 | if (asprintf(&passwd, "%s%.*s$%s", magic, sl, sp, buf) < 0)
| ^~~~~~~~
| vsprintf
This is due to the fact that <stdio.h> gets included without
_GNU_SOURCE being defined, and so the prototype of asprintf() is not
accessible, at least with uclibc-ng.
The _GNU_SOURCE definition is properly in linux-pam's config.h, but
config.h doesn't get properly included first everywhere. This issue
has been fixed upstream in the mean time, so we simply backport the
upstream patch.
Fixes:
http://autobuild.buildroot.net/results/49b190b3fbae3cdca4c7a08b3ab5100a937ede9e/
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Julien Olivain <[email protected]>
(cherry picked from commit 001e777d507b972a580d75e3ac8d892eff72fbf2)
Signed-off-by: Peter Korsgaard <[email protected]>
libxcrypt has been added as a replacement for the libcrypt implementation that was part of glibc, but dropped from glibc starting from version 2.39. However, libxcrypt was made available for all C libraries, and this is unfortunately causing some problems as it can clash with the libcrypt implementation provided by the C library. In particular, linux-pam has been consistently failing with uclibc, in BR2_PER_PACKAGE_DIRECTORIES=y builds, with the following build failure: opasswd.c: In function 'compare_password': opasswd.c:133:27: error: invalid application of 'sizeof' to incomplete type 'struct crypt_data' What happens is relatively tricky, but let's try to break it down: - uclibc-ng install a stub libcrypt.a (no shared variant, as for shared libraries, everything is in libc.so), and crypt.h - libxcrypt installs libcrypt.so.* and crypt.h So there is no "clash" on the library itself, but there is a clash on the header file. Since we're using BR2_PER_PACKAGE_DIRECTORIES=y, when building linux-pam, we are creating the per-package STAGING_DIR by copying the STAGING_DIR of linux-pam dependencies, i.e both the libxcrypt STAGING_DIR and the uclibc-ng STAGING_DIR. But the latter ends up being copied last, which means that at the end of the day, we have in the per-package STAGING_DIR of linux-pam: - The libcrypt.so from libxcrypt - The crypt.h header from uclibc-ng - The libcrypt.a from uclibc-ng When the ./configure script of linux-pam tests whether the library has crypt_r(), it concludes that yes it's available: and indeed libcrypt.so from libxcrypt has it. So it tries to use 'struct crypt_data' and 'crypt_r()', but those are not supported in uClibc-ng, and so cannot be found in the <crypt.h> header. So even if the ./configure script and the linux-pam code has some logic to fallback to crypt() if crypt_r() isn't available, this fallback doesn't trigger because the installed libcrypt.so does have crypt_r(). Basically what happens is that uclibc-ng + libxcrypt is a combo that violates a golden rule of our BR2_PER_PACKAGE_DIRECTORIES=y implementation: packages shouldn't overwrite files from each other. To avoid this situation, we make libxcrypt only installable on glibc. This isn't a problem because as of today, BR2_PACKAGE_LIBXCRYPT is always selected "if BR2_TOOLCHAIN_USES_GLIBC". It should be noted though that the case of an older glibc (which still had its own internal libcrypt) + libxcrypt continues to exist. It's less likely to cause trouble though, as the libcrypt implementations are much more similar. Fixes: http://autobuild.buildroot.net/results/560f66b0311d02dc884732221d6870ae3c38067c/ Note: we do not add a Config.in comment for this glibc dependency, because libxcrypt really is a "replacement" library to fill in the void left by libcrypt's removal from glibc. There isn't realy a point showing "libxcrypt needs a toolchain w/ glibc", because with musl or uclibc-ng, the libcrypt functionality is directly part of the C library. Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 5c0a91f7293523254e9c48667df4468370fda58d) Signed-off-by: Peter Korsgaard <[email protected]>
Signed-off-by: Peter Korsgaard <[email protected]>
Signed-off-by: Bernd Kuhls <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit cc2866ccec465623cf6deadc641b879fc61c561b) [Peter: drop 6.12.x bump] Signed-off-by: Peter Korsgaard <[email protected]>
Usually, ubxtool, a python-based tool to drive u-blox devices, connects to a gpsd instance and delegates to it the responsibility to write to and read from the actual device. This is sane, because a serial device can only be opened once, and if gpsd is running, it has that device open. However, in some cases, ubxtool can be used to directly talk to the device, to pre-configure it before gpsd runs, or even in the absence of gpsd altogether. This is not used very often, except when setting up an RTK base, where gpsd is not needed. In that case, ubxtool will directly talk to the serial device. It uses the pyserial python module. Since this is not the traditional way to talk to the device, failure to import the module is ignored, and the error reporting is deferred until it is actually needed, which is why we did not catch the issue earlier. See [1] and [2]. Fixes: f3ef072 (package/gpsd: enable python support and modules) [1] https://gitlab.com/gpsd/gpsd/-/blob/release-3.25/clients/ubxtool.py.in#L47 [2] https://gitlab.com/gpsd/gpsd/-/blob/release-3.25/gps/gps.py.in#L36 Signed-off-by: Yann E. MORIN <[email protected]> Cc: Bernd Kuhls <[email protected]> [Julien: add link to described code portion] Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit 5d2f3737a1e52d140bd412bf01241eecf5cff994) Signed-off-by: Peter Korsgaard <[email protected]>
See here for a ChangeLog: https://downloads.isc.org/isc/bind9/9.18.32/doc/arm/html/notes.html#notes-for-bind-9-18-32 Signed-off-by: Waldemar Brodkorb <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit d92b592ce145761b8b73a88c9f00fa5928b62a18) Signed-off-by: Peter Korsgaard <[email protected]>
Includes various bugfixes. For details, see NEWS: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/cc7439187f61dd73b81ca69f5dbccbb52ce970b2/NEWS Signed-off-by: Peter Korsgaard <[email protected]> Signed-off-by: Julien Olivain <[email protected]> (cherry picked from commit b94d0d354df0baec54af5ec52556d542849d6315) Signed-off-by: Peter Korsgaard <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
2024.11.1, released January 9th, 2025
2024.11, released December 8th, 2024