)

(cherry picked from commit d1d8b6d)

(cherry picked from commit 802afd0)

(cherry picked from commit 5c99d67)

(cherry picked from commit 2a908a0)

On machines with many build cores, the tests either fail repeatedly or
don't even manage to start because all ports are blocked. For instance,
on a heavy machine with >350 threads, valkey was busy trying to find
ports for its tests for several hours:

    [...]
    Port 23380 was already busy, trying another port...
    Port 23381 was already busy, trying another port...
    Port 23382 was already busy, trying another port...
    Port 23383 was already busy, trying another port...
    Port 23384 was already busy, trying another port...
    Port 23385 was already busy, trying another port...
    Port 23386 was already busy, trying another port...
    Port 23387 was already busy, trying another port...
    Port 23388 was already busy, trying another port...
    Port 23389 was already busy, trying another port...
    Port 23390 was already busy, trying another port...

It should be noted that the tests seem to repeatedly use the same,
smallish range given it always tried to allocate ports in the range of
233xx.

(cherry picked from commit 8e4b0ab)

(cherry picked from commit 0a1836c)

…2025-9165 (#437401)

https://docs.djangoproject.com/en/4.2/releases/4.2.24/
https://www.djangoproject.com/weblog/2025/sep/03/security-releases/

Fixes: CVE-2025-57833
(cherry picked from commit 4523b24)

systemd/systemd@v257.8...v257.9
close #439240 and #440073

Signed-off-by: misilelab <[email protected]>
(cherry picked from commit 0e70ce7)

https://curl.se/docs/CVE-2025-9086.html
https://curl.se/docs/CVE-2025-10148.html

Not-cherry-picked-because: Possible behavior changes in 8.15.0 and 8.16.0

… (#441889)

The source hash changes because they use `$Format:%d$` in their code,
and GitHub can substitute this with different things in different times,
see #84312.

In this case, the diff looks like this:

```
diff -ur /nix/store/v2yfg05q83i154bdi2s96g21zi079rgi-source/msgspec/_version.py /nix/store/94zddrfms1ikx61i0plxnqdd3gavfdzr-source/msgspec/_version.py
--- /nix/store/v2yfg05q83i154bdi2s96g21zi079rgi-source/msgspec/_version.py      1970-01-01 00:00:01.000000000 +0000
+++ /nix/store/94zddrfms1ikx61i0plxnqdd3gavfdzr-source/msgspec/_version.py      1970-01-01 00:00:01.000000000 +0000
@@ -24,7 +24,7 @@
     # setup.py/versioneer.py will grep for the variable names, so they must
     # each be defined on a line of their own. _version.py will just call
     # get_keywords().
-    git_refnames = " (HEAD -> main, tag: 0.19.0)"
+    git_refnames = " (tag: 0.19.0)"
     git_full = "dd965dce22e5278d4935bea923441ecde31b5325"
     git_date = "2024-12-27 11:06:58 -0600"
     keywords = {"refnames": git_refnames, "full": git_full, "date": git_date}
```

Fix the hash and add a comment explaining the situation.

(cherry picked from commit e72eda8)

aarch64 FMV (Function MultiVersioning) is not available before the libc
is available. This causes issues while building with compiler-rt on
aarch64. By disabling FMV before the libc is available resolves missing
symbol errors.

(cherry picked from commit ded560c)

… on aarch64 without libc (#442664)

(cherry picked from commit 86af86b)