gh-122792: Changed IPv4-mapped ipaddress.IPv6Address to consistently use the
mapped IPv4 address value for deciding properties. Properties which have
their behavior fixed are is_multicast, is_reserved, is_link_local,
is_global, and is_unspecified.
https://github.com/python/cpython/issues/122792
CVE-2024-9287, gh-124651: Properly quote template strings in venv activation
scripts.
https://github.com/python/cpython/issues/124651
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
go1.22.9 (released 2024-11-06) includes fixes to the linker.
go1.22.10 (released 2024-12-03) includes fixes to the runtime and the
syscall package.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The lmbench package (largely unmaintained upstream, last release in
2006) uses a home-grown build system. The scripts/build script sets
LDLIBS to -lm and Buildroot's makefile changes that to:
LDLIBS+=-lm
Except that when Buildroot passes LDLIBS="`$(PKG_CONFIG_HOST_BINARY)
--libs libtirpc`", the LDLIBS variable ends up being equal to:
-ltirpc-lm
Yes, without any space between -ltirpc and -lm.
Due to this, the checks in scripts/build that use ${LDLIBS} all fail,
and in particular the test that checks when socklen_t is a known type
fails, causing lmbench to provide its own definition, which clashes
with the C library headers definition, and therefore causing build
failures such as:
bench.h:81:13: error: conflicting types for 'socklen_t'; have 'int'
This commit fixes that by adjusting scripts/build using a patch to
properly allow passing additional ${LDLIBS} value, with the needed
space to separate the value from -lm.
Fixes:
http://autobuild.buildroot.net/results/f1715de95b46a1d08143e529bd4574bc7dbcfb3e/
We have been unable to determine exactly when this issue was
introduced. The first build failure we could find is the one
referenced above, which dates back from Aug 19, 2024. Since this date,
lmbench has been consistently failing on a very regular
basis. However, prior to Aug 19, 2024, the previous failure was from
December 2022, and was unrelated. It is unclear what changed in Aug
2024 to cause this issue to surface. The one thing that changed right
before commit ce3dedc2 (first failing commit) are changes to
genrandconfig, which ensures all autobuilders now generated fully
random configurations instead of configurations based on a
well-defined list of arch/toolchain configurations. But even with
this, this lmbench issue should have appeared earlier, and we have
been unable to find a scientific explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 80f25d4706)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The android-tools code base uses the __b64_pton() function, which
isn't provided by all C libraries. So the Debian patch
debian/patches/add_adbd.patch adds an implementation of b64_pton(),
but doesn't actually use it, nor defines a prototype for it. Our
existing patch 0003-Fix-build-issue-with-uclibc.patch switches the
code to use the b64_pton() function... but still without providing a
prototype, causing the following build failures with GCC >= 14.x:
adb_auth_client.c:75:15: error: implicit declaration of function 'b64_pton'
To fix this, we rework 0003-Fix-build-issue-with-uclibc.patch into a
patch that:
(1) Renames b64_pton() to adb_b64_pton() to make sure it won't clash
with implementations provided by some C libraries, and adjusts
the call sites accordingly.
(2) Adds a prototype definition of adb_b64_pton() in places where
this function is used.
Fixes:
http://autobuild.buildroot.net/results/b25b25337c7ad89c33f8bd20b646850bd993ec53ae9/
Even though GCC 14.x support was merged in Buildroot in May 2024, this
particular b64_pton() only started appearing on July 15 2024, with the
first occurrence being:
http://autobuild.buildroot.net/results/1cbe87bbe3c56f28444b3aaba1ba1d05f947d36e/
Indeed, it's not before July 15 2024 that we merged commit
d201f2f5cd ("package/android-tools: add
patches to fix build with GCC 14.x"), which fixed other GCC 14.x
issues, which were hiding this b64_pton() problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 1eec67d164)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The kernel headers on mips64 and powerpc64 were historically "broken",
defining u64 as an "unsigned long" instead of "unsigned long
long". This has been fixed in the upstream Linux kernel by introducing
the __SANE_USERSPACE_TYPES__ definition.
Our commit a2e178d6b4 ("android-tools:
disable on some architecture with old kernel headers") already
disabled building fastboot on powerpc64 and mips64 systems that have
too old kernel headers. However, it turns out that even with the new
kernel headers, there are build issues because
__SANE_USERSPACE_TYPES__ isn't defined everywhere it should be in the
android-tools code base. The Debian patche
debian/patches/ppc64el-ftbfs.patch adds some definitions, but it's
missing one file, and in another the definition comes too late.
This commit adds an extra patch that fixes this up, and makes fastboot
build properly on mips64 and powerpc64.
Fixes:
http://autobuild.buildroot.net/results/8528ff876e695f79bdfe64f5330d9d51eeef66cb/ (powerpc64)
http://autobuild.buildroot.net/results/36ac6af73b618c28d1636093da333f7ebd9d6cfe/ (mips64)
This issue has been occurring as far as Feb 2021, with the first
occurence apparently being:
http://autobuild.buildroot.net/results/d9521b4bfeafb1140c21745dbfe28d476a9b71ec/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit ee65a2119a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This will make it easier to modify the patch series moving forward. No
functional changes.
On one patch, we added the SoB from Giulio, which was missing. Giulio
was the original contributor of the patch, and nobody touched it since
it was introduced.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 3ee745782a)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
losetup -f returns the next free loop device, which may not be
/dev/loop0. If you blindly follow the readmy you may end up destroying
an existing device.
Make it more robust with a variable to store the loop device.
Signed-off-by: Cherniaev Andrei <dungeonlords789@naver.com>
[Arnout: keep the actual losetup atomic]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 7dd56b6cd9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
nfs-utils configure script uses "systemd-escape" to determine the
rpc_pipefs mount point unit name in the non-default case.
If the host build system has no systemd this will silently result in an
empty name, causing rpc_pipefs.target to incorrectly depend on ".mount".
Fix that by depending on host-systemd for build.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Acked-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 4c9b13b8dd)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As it happens, I am unable to keep maintaining those entries, and it is
misleading to others about whether they should Cc me on their changes.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 773a89d414)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When halting the boot process in u-boot, the 'usb start' command does not
automatically run. Since the SD card is connected over a USB to SD card
bridge on the kd240 and kr260 boards, the readme.txt instructions should
document that the 'usb start' command needs to be manually enterred when
following the reflashing instructions. Otherwise, the command to read the
boot.bin and u-boot.itb files from the SD card will fail.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e02e59d124)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
8.5.5 fixes the following security issues:
- CVE-2024-31948: bgpd: Fix error handling when receiving BGP Prefix SID
attribute
ba6a8f1a31
- CVE-2024-31950: ospfd: Solved crash in RI parsing with OSPF TE
f69d1313b1
- CVE-2024-31951: ospfd: Correct Opaque LSA Extended parser
5557a289ac
8.5.6 fixes the following security issues:
- CVE-2024-44070: bgpd: Check the actual remaining stream length before taking TLV value
0998b38e4d
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The mosquitto runtime test can randomly fail on slow
runners, see [1].
This commit improves this test in the following ways:
- the mosquitto_sub subscriber process is now started in a subshell
to suppress the job control messages (to prevent any spurious
messages when the job stops),
- the standard error is redirected to /dev/null, to prevent the
printing of any messages,
- the mosquitto_pub publisher process is started later, by increasing
the sleep time,
- finally, a new sleep time is introduced between the mosquitto_pub
publisher process and the check of the mosquitto_sub subscriber, to
make sure it will have time to write its output and exit.
Fixes: [1]
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/8453386454
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 07a444d088)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
