Debian Patches

Status for rsync/3.5.0+ds1-2

Patch Description Author Forwarded Bugs Origin Last update
disable_reconfigure_req.diff Remove need to run reconfigure target

===================================================================		 Samuel Henrique <samueloph@debian.org> not-needed 2024-04-12
env_shebang.patch =?utf-8?q?Removes_usage_of_env_on_shebangs_as_per_Debian_Policy_?= =?utf-8?q?=C2=A7_10=2E4?= Samuel Henrique <samueloph@debian.org> not-needed 2024-04-12
fix_rrsync_man_generation.patch Fix manpage installation for rrsync
Otherwise we would get "ERROR: support/rrsync.1 cannot be created."
I'm not confident this is the best approach on solving this issue,
but I know this works with no regressions.
This patch needs to be reviewed before being submitted to upstream.
===================================================================		 Samuel Henrique <samueloph@debian.org> no 2024-04-12
Honor_STRIP_in_install-strip_for_cross-compilation.patch Honor $(STRIP) in install-strip for cross-compilation (#1024)
* Honor $(STRIP) in install-strip for cross-compilation

The install-strip target hard-coded `install -s`, which strips via the
install program using the build host's strip and ignores the STRIP
variable. When cross-compiling this runs the host strip against a
target binary and fails.

Pass --strip-program=$(or $(STRIP),strip) so the target strip is used
when STRIP is set (as cross toolchains and build systems provide),
falling back to plain `strip` for native builds. A plain `make install`
is unaffected.

* Make install-strip portable (address review)

- Detect the target strip via AC_CHECK_TOOL([STRIP],[strip],[strip]) in
configure.ac (picks up the cross-prefixed strip when cross-compiling,
defaults to plain strip otherwise) and substitute @STRIP@ in Makefile.in.
- Rewrite install-strip to run a normal install then $(STRIP) on the
installed rsync binary, dropping the GNU Make $(or ...) and the GNU
install --strip-program extension that broke with install-sh/BSD install.		 Alessandro Di Nepi <alessandro.dinepi@gmail.com> no 2026-08-16
rrsync_support_fd_pins_in_user_namespaces.patch rrsync: support fd pins in user namespaces (#1048)
* rrsync: support fd pins in user namespaces
* rrsync: support /dev/fd pins in user namespaces		 Zen Dodd <mail@steadytao.com> no 2026-08-16
testsuite_bound_the_unshare_probe.patch testsuite: bound the unshare probe (#1049) Zen Dodd <mail@steadytao.com> no 2026-08-16
testsuite_make_basis_xname_oracle_deterministic.patch testsuite: make basis xname oracle deterministic (#1051) Zen Dodd <mail@steadytao.com> no 2026-08-15
testsuite_interpose_lfs_open_symbols.patch testsuite: interpose the large-file spellings of open/openat/fstatat
Which symbol names this test's LD_PRELOAD hook exports is decided by the
compiler that builds it, and which names rsync imports is decided by
configure -- and the two do not have to agree.

Where off_t is not already 64 bits, configure's AC_SYS_LARGEFILE adds
-D_FILE_OFFSET_BITS=64 (i386 and alpha in Debian), so glibc redirects every
open()/openat()/fstatat() call in rsync to open64(), openat64() and
fstatat64(). The hook is compiled by a bare "cc", so on those architectures
it defines only the unsuffixed names: the receiver's opens never reach it, no
EACCES is injected, the marker the positive control looks for is never
written, and the test fails with

positive control failed: receiver did not open the existing partial file
with O_CREAT (rc=0, output='')

It happens to work on Debian's 64-bit time_t ports (armhf, hppa, powerpc,
...) only by luck: their gcc predefines -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64,
so glibc's __REDIRECT renames the hook's own DEFINITIONS as well and it ends
up exporting exactly the *64 names rsync imports.

Define both spellings explicitly so the hook interposes whichever set the
rsync under test was linked against, and #undef the two macros at the top of
the hook so that renaming cannot happen -- otherwise, on precisely those ports
where the compiler predefines them, open() would be emitted as open64() and
collide with the explicit wrapper ("symbol `open64' is already defined"),
which would leave the hook unbuildable and the test skipped.

The new pointers are resolved through hook_resolve(), so the existing
nested-dlsym recursion guard covers them as well.		 Samuel Henrique <samueloph@debian.org> yes 2026-08-17
testsuite_punch_granularity_guard.patch testsuite: probe the punch granularity each hole assertion relies on
The last section of preallocate_test.py writes 256 blocks of
[4 KiB data][24 KiB zeros][4 KiB data] and requires --inplace --sparse to
deallocate at least half of the file. A punch only frees whole allocation
units, and the 24 KiB interior run sits 4 KiB into each 32 KiB block: with a
4 KiB unit it covers six whole units (24 KiB freed per block), but with a
16 KiB unit it covers none at all, so st_blocks does not move.

That is what happens on loong64, whose kernel uses 16 KiB pages
(arch/loongarch/Kconfig defaults to 16KB_3LEVEL on 64-bit and Debian's
config does not override it), and the build fails with

--inplace --sparse left matching interior zero runs allocated: 8388608 of
8388608 bytes remain allocated after a 8388608-byte matched-block update

i.e. exactly "nothing was freed", which is the arithmetic of a punch
granularity >= 16 KiB rather than an rsync regression. fs_can_punch_holes()
does not catch it because it punches a whole 64 KiB file, which frees blocks
at any granularity.

Generalise that helper into punch_frees(offset, length, size) so each
assertion can probe the shape it actually depends on, and gate the interior
one on the exact [4 KiB data][24 KiB zeros][4 KiB data] layout. Where the
filesystem can free that run the assertion runs exactly as before; where it
cannot, the test says so rather than reporting a regression.

While here, call fallocate64() instead of fallocate(). ctypes declares the
offset and length as c_longlong, but where off_t is 32 bits glibc's
fallocate() takes 32-bit offsets -- so the callee reads the high half of
`offset` as its `length`, the probe fails with EINVAL, and can_punch comes
back False. That is why none of this file's hole-punching assertions have
ever run on a 32-bit port; on i386:

fs_can_punch_holes() as written : before=128 ret=-1 errno=22 -> False
the same probe via fallocate64 : before=128 ret=0 -> True

fallocate64() takes off64_t on every architecture and is a plain alias of
fallocate() where off_t is already 64 bits. The probe now writes urandom
rather than a repeated byte as well, so a filesystem that compresses does not
answer "nothing was freed" merely because nothing was allocated.		 Samuel Henrique <samueloph@debian.org> yes 2026-08-17

All known versions for source package 'rsync'

Links