Fix CVE-2023-46852: In Memcached before 1.6.22, a buffer overflow exists
when processing multiget requests in proxy mode, if there are many
spaces after the "get" substring.
Fix CVE-2023-46853: In Memcached before 1.6.22, an off-by-one error
exists when processing proxy requests in proxy mode, if \n is used
instead of \r\n.
https://github.com/memcached/memcached/wiki/ReleaseNotes1622
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit bc96e9da0d8010482dcc50c055567d4625498088)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following uclibc-ng build failure raised since bump to version
1.6.21 in commit 6ce55ab0ed3b7125cd11ecfe8c18aaf156b5f060 and
875371a75c:
/home/buildroot/autobuild/instance-2/output-1/host/lib/gcc/arc-buildroot-linux-uclibc/10.2.0/../../../../arc-buildroot-linux-uclibc/bin/ld: memcached-thread.o: in function `thread_setname':
thread.c:(.text+0xea2): undefined reference to `pthread_setname_np'
Fixes:
- http://autobuild.buildroot.org/results/e856d381f5ec7d2727f21c8bd46dacb456984416
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit bfa3cd74d017ba47b91729f131daf5d5993c5265)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix CVE-2023-47359: Videolan VLC prior to version 3.0.20 contains an
incorrect offset read that leads to a Heap-Based Buffer Overflow in
function GetPacket() and results in a memory corruption.
Fix CVE-2023-47360: Videolan VLC prior to version 3.0.20 contains an
Integer underflow that leads to an incorrect packet length.
https://code.videolan.org/videolan/vlc/-/blob/3.0.20/NEWS
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit d675873f4fe9b601719b08cdd8a901d73ec7f731)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the favicon image was added in f26e61319f (docs/website: add
favicon.png), it was added to a different directory then where the header's
icon link points. This causes the favicon to fail to load with 404.
While we are here, remove the "shortcut" rel attribute as it is non-standard
and it's recommended not to use it[1].
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel#sect4
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8ad1a2eaa5fa6c5eaa6614b007b968223e49448e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since bump of webp to version
1.3.2 in commit c88c1d3319dd24fa833455a2e7d96bc4585bab7f:
/home/autobuild/autobuild/instance-9/output-1/host/lib/gcc/aarch64_be-buildroot-linux-uclibc/13.2.0/../../../../aarch64_be-buildroot-linux-uclibc/bin/ld: picture.o: undefined reference to symbol 'WebPMemoryWriterClear'
/home/autobuild/autobuild/instance-9/output-1/host/lib/gcc/aarch64_be-buildroot-linux-uclibc/13.2.0/../../../../aarch64_be-buildroot-linux-uclibc/bin/ld: /home/autobuild/autobuild/instance-9/output-1/host/aarch64_be-buildroot-linux-uclibc/sysroot/usr/lib64/libwebp.so.7: error adding symbols: DSO missing from command line
Fixes:
- http://autobuild.buildroot.org/results/9b859a701debeaddf1f9909e16adc6811a620576
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 1267a234fff8c5270d8ead5541167053771636b1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 13fc9dcb34926e9b6310b23662920c55c96d83a1, netsnmp was bumped
from 5.9.3 to 5.9.4 to fix two CVEs.
However, even though it's a minor version bump, there are actually 163
commits upstream between those two minor releases, and some of them
are breaking existing use-cases. In particular upstream
a2cb167514ac0c7e1b04e8f151e0b015501362e0 now requires that config_()
macros in MIB files are terminated with a semicolon, causing a build
breakage with existing MIB files that were totally valid with 5.9.3.
This commit therefore proposes to revert back to 5.9.3, by reverting
those two commits:
56caafceab3ec12669ccb7aa6fc8b653778064e1 package/netsnmp: fix musl build
13fc9dcb34926e9b6310b23662920c55c96d83a1 package/netsnmp: security bump to version 5.9.4
and instead backport the one upstream commit that fixes both CVEs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: fix typo as reported by Baruch]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 44243b4c80c3c6fd4364fa1582f6a8e8c8b928da)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Git-generated patches embed the short-hash of the objects in the
repository. The length of those short hashes are subject to change
in at least three cases:
- the number of objects in the repository increases, so git increases
the length of short hashes to get a good change there is no
collision;
- the git configuration changes, see core.abbrev in git-config;
- the heuristic to compute the length changes in a newer git version.
Since the bump to zfs 2.1.4 in commit 68dfd09708, the patch generated
by github has changed, causing download failures:
wget --passive-ftp -nd -t 3 -O '/home/ymorin/dev/buildroot/O/master/build/.bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch.uoFq9e/output' 'bc3f12bfac.patch'
--2023-11-26 16:53:25--
bc3f12bfac.patch
Resolving github.com (github.com)... 140.82.121.3
Connecting to github.com (github.com)|140.82.121.3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2976 (2.9K) [text/plain]
Saving to: ‘/home/ymorin/dev/buildroot/O/master/build/.bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch.uoFq9e/output’
/home/ymorin/dev/buildroot/O/ 100%[================================================>] 2.91K --.-KB/s in 0s
2023-11-26 16:53:25 (15.0 MB/s) - ‘/home/ymorin/dev/buildroot/O/master/build/.bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch.uoFq9e/output’ saved [2976/2976]
ERROR: while checking hashes from package/zfs//zfs.hash
ERROR: bc3f12bfac152a0c28951cec92340ba14f9ccee9.patch has wrong sha256 hash:
ERROR: expected: 96a27353fe717ff2c8b95deb8b009c4eb750303c6400e2d8a2582ab1ec12b25a
ERROR: got : 246c80f66abca5a7e0c41cc7c56eec0b4cb7f16b142262480401142bbc2f999f
ERROR: Incomplete download, or man-in-the-middle (MITM) attack
And indeed, the length of short hashes has increased by one since then.
Fix that by bundling the patch, with the short hashes that were known
then, so that it matches the sha256 we had for it.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 2c3946fcb45b07db5cc88cdc944745aa1ef8fa04)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gcc.mk attempts to disable building the documentation by setting
MAKEINFO=missing, but it is not working. If makeinfo is installed
and recent enough, gcc still uses it. This can be checked easily:
grep BUILD_INFO='info' host-gcc-initial-*/build/gcc/config.log
It happens because the root ./configure script will check
$MAKEINFO --version (aka 'missing --version') and will overwrite it with
MAKEINFO='missing makeinfo' because the version does not match.
Having MAKEINFO='missing makeinfo' is a problem because
'missing makeinfo' will actually attempt to run 'makeinfo' before
failing with an error message. If makeinfo is installed on the host,
then 'missing makeinfo' will successfully run makeinfo anyway.
Many gcc subprojects will check $MAKEINFO --version and enable building
the documentation if it is recent enough. This patch overrides these
checks by forcing gcc_cv_prog_makeinfo_modern=no.
Building the GCC documentation can fail with the wrong makeinfo version.
It happened at least when building GCC 11.3.0 with makeinfo 7.1.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit f7b9d3ad2b4acccad5252737003e8a0db4f43340)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2022-48303: GNU Tar through 1.34 has a one-byte out-of-bounds read
that results in use of uninitialized memory for a conditional jump.
Exploitation to change the flow of control has not been demonstrated. The
issue occurs in from_header in list.c via a V7 archive in which mtime has
approximately 11 whitespace characters.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: add _IGNORE_CVES entry]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit ad0bb50dc717a2d9568b73e0f4a509cf6044ffb1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit d4d483451f0a305781b94b96c15a6cf4b489cd84.
Tar 1.35 unfortunately changes the behaviour for the devmajor/devminor
fields, breaking the download hash validation. From the release notes:
* Leave the devmajor and devminor fields empty (rather than zero) for
non-special files, as this is more compatible with traditional tar.
https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00005.html
So revert the bump for now.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f2b23a63208bb026b5a5729c6a4c33e48aad934c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a script to manage the .hash files in the BR2_GLOBAL_PATCH_DIR for
packages using custom versions.
To use it, run in a configured Buildroot directory, E.G.
make foo_defconfig; ./utils/add-custom-hashes
We support multiple patch directories in BR2_GLOBAL_PATCH_DIR. If multiple
directories are specified then use the last one as that is likely to be the
most specific one.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: silence command -v invocation]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 4984d0f230d0962270beb195966603f1d5a56300)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
By default dhcpcd installed with 555 permissions as it is
configured in its Makefile.inc. Since 'w' bit is missing,
strip fails and dhcpcd binary installed non-stripped.
On ARM GCC 12 glibc configuration strip saves over 1MB of disk space.
Signed-off-by: Oleg Lyovin <ovlevin@salutedevices.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 72c3f87efacbf593abebe798321f9ecda7adc2d3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also, bump package/opencv4-contrib to in lock-step.
This addresses both CVE-2023-2617 and CVE-2023-2618, that have been
fixed in OpenCV 4.8.0.
Signed-off-by: Woodrow Douglass <wdouglass@carnegierobotics.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a01490397e4cc11155b3c396ded382eefeef4f12)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
pb-discover does not create its own pid file. Handle the creation and
removal of the pid file in the init script.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 0f04c7ae01e2bbbb88b8e39f786bc91f4a01c07c)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following (Windows only) security issues:
CVE-2023-45283: path/filepath: recognize \??\ as a Root Local Device path prefix.
CVE-2023-45284: path/filepath: recognize device names with trailing spaces and superscripts
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Node modules available on the npm registry, may contain prebuild
binaries for various targets and/or ABIs; for example., there might be
ARM. AArch64, x86_64 binaries for glibc or musl, for Linux or Darwin.
Needless to say, those binaries will most often not match the current
target architecture; as such, check-bin-arch will whine loudly as
reported in #15823:
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv6.node" is "ARM", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/android-arm/node.napi.armv7.node" is "ARM", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-arm/node.napi.armv7.node" is "ARM", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.glibc.node" is "Advanced Micro Devices X86-64", should be "AArch64"
ERROR: architecture for "/usr/lib/node_modules/node-red-node-serialport/node_modules/@serialport/bindings-cpp/prebuilds/linux-x64/node.napi.musl.node" is "Advanced Micro Devices X86-64", should be "AArch64"
The proper solution would be to remove all those prebuilt binaries, and
request npm to forcefully rebuild the proper binary for the current
architecture; alas, there is no option to tell npm to do so.
Doing it manually would not be easy either, as such modules might be
retrieved as part of the "vendoring" for another module that the user
has requested, and be pretty deep in the dependency chain; trying to fix
this properly would be a nightmare: it would require that we manually
inspect the depednency chain, and install dependent modules one by one,
recursively, re-implementing the same logic npm has when multiple
verions of the same module are installed as part of different branches
of the depenency tree, all while detecting prebuilds and removing them
before installing the mpdule (hence decorrelating download and install,
which is not trivial to do with npm alone).
We also can't simply remove all the prebuilds, because it is not known
whether the location ("<module>/prebuilds/") is standardised, or a
convention with the path noted somewhere in the package metadata, and
how deep they would be in the tree, and whether that could conflict with
arbitrary files...
Instead, we will consider that npm has a sane heuristic to detect
whether it should indeed rebuilt the modules, and that node has a sane
heuristic to know which binary to load at runtime, and we will leave the
prebuilt binaries in place and just exclude them from being checked.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=15823
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
Tested-by: Marcus Hoffmann <marcus.hoffmann@othermo.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit cbc5691ab298c89f6bd02b06a0a790ab531f2b55)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, when a package is downloaded from a custom location or
version, Buildroot excludes such a package from the mandatory integrity
check with hashes, because it was until now not possible to have such
hashes.
We now have a mechanism which users can leverage to provide additional
hashes, and so custom versions or locations can now be checked too.
Buildroot has no way to know that hashes have indeed been provided for
a custom location/version, and so will still happily ignore an
unchecked package.
However, users who do provide extra hashes most probably do expect that
no download is done without an integrity check, and thus expect that a
missing hash not be ignored.
Add an option that users can select to make Buildroot forcibly require
at least one valid hash, and no invalid hash, for all downloads.
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit e091e31831122b60b084bd755e94df4dfe7188d2)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
We leverage the existing global-patch-dir mechanism to look for extra
hash files. We use the same heuristic that is used for bundled hash
files, and for each global patch directory <dir>, we use the first file
to exist among:
1. look into <dir>/<package>/<version>/<package>.hash
2. look into <dir>/<package>/<package>.hash
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 5d36710e36fc4698c8fae71675bcff7395246006)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we expect and only use hash files that lie within the package
directory, alongside the .mk file. Those hash files are thus bundled
with Buildroot.
This implies that only what's known to Buildroot can ever get into those
hash files. For packages where the version is fixed (or a static
choice), then we can carry hashes for those known versions.
However, we do have a few packages for which the version is a free-form
entry, where the user can provide a custom location and/or version. like
a custom VCS tree and revision, or a custom tarball URL. This means that
Buildroot has no way to be able to cary hashes for such custom versions.
This means that there is no integrity check that what was downloaded is
what was expected. For a sha1 in a git tree, this is a minor issue,
because the sha1 by itself is already a hash of the expected content.
But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
integrity check.
Buildroot can't provide such hashes, but interested users may want to
provide those, and currently there is no (easy) way to do so.
So, we need our download helpers to be able to accept more than one hash
file to lookup for hashes.
Extend the dl-wrapper and the check-hash helpers thusly, and update the
legal-info accordingly.
Note that, to be able to pass more than one hash file, we also need to
re-order the arguments passed to support/download/check-hash, which also
impies some shuffling in the three places it is called:
- 2 in dl-wrapper
- 1 in the legal-info infra
That in turn also requires that the legal-license-file macro args get
re-ordered to have the hash file last; we take the opportunity to also
move the HOST/TARGET arg to be first, like in the other legal-info
macros.
Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f91e89b6e64d4ad092c359a658a8ee22e848ce66)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 27bf08e4ad (configs/avenger96_defconfig: bump ATF version to 2.9
for binutils 2.39+ support) bumped TF-A, but it unfortunately does not boot
and instead dies with a panic:
NOTICE: CPU: STM32MP157AAC Rev.B
NOTICE: Model: Arrow Electronics STM32MP157A Avenger96 board
ERROR: nvmem node board_id not found
INFO: PMIC version = 0x10
ERROR: Product_below_2v5=1:
ERROR: HSLVEN update is destructive,
ERROR: no update as VDD > 2.7V
PANIC at PC : 0x2fff086f
Exception mode=0x00000016 at: 0x2fff086f
Instead use v2.5 to match the other stm32mp1 boards and use the same E=0
-Werror workaround. The avenger95 support is unfortunately broken since
v2.3 with the introduction of authentication support, so add a patch to the
DTS to fix that.
Notice that the authentication support was reworked in v2.7 so it is skipped
for the mp157a variant used on the avenger96, so the patch is not upstreamable.
While we're at it, also drop the debug option for consistency with the other
boards.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit deb8d71c9285eb60bc3d28e8abcf7208f78980a7)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit f20589cbc7 (configs/stm32mp157c_odyssey: new defconfig) forgot to
specify a fixed TF-A version, so do that now.
When the defconfig was added, the default version was v2.5 - So use that.
Similarly to the other stm32mp1 defconfigs, this needs disabling -Werror
with E=0 to fix a build issue with GCC >= 12.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 69ac9fdbc46f28dbc6f013200e5cf13dd6f0c2aa)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With the move to default to GCC 12 in commit e0091e42ee (package/gcc:
switch to gcc 12.x as the default), TF-A now fails to build as a warning is
generated and it builds with -Werror:
CC plat/st/stm32mp1/bl2_plat_setup.c
drivers/st/io/io_stm32image.c: In function ‘stm32image_partition_read’:
drivers/st/io/io_stm32image.c:249:13: error: ‘result’ may be used uninitialized [-Werror=maybe-uninitialized]
249 | int result;
| ^~~~~~
cc1: all warnings being treated as errors
This is fixed in TF-A v2.6 with commit c1d732d0db24 (fix(io_stm32image):
uninitialized variable warning), but I do not have the board to verify if
v2.6 works, so instead disable -Werror by passsing E=0.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 1c0c67fc1ae146b34475231fb702e7f2e6bf9f8f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With the move to default to GCC 12 in commit e0091e42ee (package/gcc:
switch to gcc 12.x as the default), TF-A now fails to build as a warning is
generated and it builds with -Werror:
CC plat/st/stm32mp1/bl2_plat_setup.c
drivers/st/io/io_stm32image.c: In function ‘stm32image_partition_read’:
drivers/st/io/io_stm32image.c:249:13: error: ‘result’ may be used uninitialized [-Werror=maybe-uninitialized]
249 | int result;
| ^~~~~~
cc1: all warnings being treated as errors
This is fixed in TF-A v2.6 with commit c1d732d0db24 (fix(io_stm32image):
uninitialized variable warning), but I do not have the board to verify if
v2.6 works, so instead disable -Werror by passsing E=0.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5c40f41b2e715bb39693a188da5a540ae9fa7aef)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure raised since bump to version 3.2.3 in
commit 4155139365247ea702bb536848dd1e771f98f0d2:
In file included from /home/thomas/autobuild/instance-1/output-1/host/include/python3.11/Python.h:38,
from src/modules/rlm_python3/rlm_python3.c:37:
/home/thomas/autobuild/instance-1/output-1/host/include/python3.11/pyport.h:596:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
596 | #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
| ^~~~~
Fixes:
- http://autobuild.buildroot.org/results/36143ab06b66a047aa2247ea66b1df0d6c1cbd66
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit fdae1d231cae302bf903c128b77fd78db3dc0342)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
python handling is wrong since the addition of the package in commit
736c4c1655 so disable python(2) and enable
python3 if needed
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4513f5198a8f24af7bd24fdfc1ede143eb4e844a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
timeout = 35 * self.emulator.timeout_multiplier
[...]
self.assertRunOk(cmd, timeout=timeout)
Gets re-multiplied by self.emulator.timeout_multiplier in self.emulator.run().
Drop multiplying the timeout by self.emulator.timeout_multiplier to fix this
issue.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9a81c7a7a4629cc009b05195c9b4e37a582287ea)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
self.emulator.timeout_multiplier *= 10 is equivilent to 60 * 10 or 600.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4889ac89b8438cfaba0708338fb52d553110c1a1)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
self.emulator.timeout_multiplier *= 10 is equivilent to 60 * 10 or 600.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c9316f21c7d07bfabccb1ab297773b7b83e217a0)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
to override the current value of 60 seconds
As per a suggestion by Thomas, add a timeout argument to override the current
value of 60 seconds for the emulator.login method.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b1d554b9a769657b3a4c3263fc71c8028b33475d)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
