| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| tests-Only-check-whether-the-first-1024-fds-are-close-on-.patch | tests: Only check whether the first 1024 fds are close-on-exec On recent Linux systems, systemd sets the hard limit on the number of file descriptors extremely high (about 1e9, compared with about 1e6 in previous systemd versions or 4096 in the kernel's historical defaults), and dbus raises its soft limit to match the hard limit. The result of sysconf(_SC_OPEN_MAX) is based on the fd limit, and iterating linearly through that many fds takes long enough for activation to time out. This particular piece of code is just test instrumentation, which aims to log (possibly fatal) warnings if any file descriptor is not close-on-exec as it should be. In practice the test suite doesn't use anywhere near a thousand fds, so it's sufficient to run this check against a much smaller number of fds. |
Simon McVittie <smcv@collabora.com> | yes | debian upstream | 2024-10-27 | |
| debian/tests-Multiply-timeouts-by-20-on-riscv64.patch | tests: Multiply timeouts by 20 on riscv64 Real riscv64 hardware has performance comparable to Debian's slower buildds such as arm and mips, but the port is currently being bootstrapped using qemu-system-riscv64, and that's too slow to run some of our tests successfully. For each test that "should" take no more than a minute on real hardware, allow 20 minutes instead. |
Simon McVittie <smcv@debian.org> | invalid | debian | 2018-05-06 |