Hello Eugene, > > 1) Do you know how is it possible that you were running Debian testing > > with libc6 2.30-4? Even Debian stable has a newer version, I believe > > you could have missed running apt full-upgrade at some point. > > I have several hosts with old kernels (like 4.17) and their headers, > and gcc-7, which are tied to libc6-2.30 by their dependences. > On "aptitude install libc6" first resolver's proposal was to remove > these packages. I agreed with this choice to install libc6-2.32.
Interesting, so I will assume the system is in a consistent state. > I have a copy of one such system on backup, it may be studied for > more details if need... However, it looks pointless, because support > for lchown() is definitely a new feature, so the right way, IMHO, > is to correct dependences for rsync package: "libc6 (>= 2.31)". I don't think it's as simple as that, I understand your issue now, but I wouldn't just bump the dependency requirement without understanding it better. As it stands now, the version requirement is automatically set by debhelper, based on the symbols rsync uses. The bug we are facing comes from libc6, as we can see in the upstream bug report, and rsync is trying to workaround that issue (the patch I introduced on 3.2.3-7). > > 2) Is your system under a chroot and/or without /proc mounted? > > No, fault happens with physical hosts (not VMs or containers), > where /proc is mounted. However, they are all running SysV init. Cool, I think SysV init won't take a role in this, but good to know the details. > > > Upgrade libc6 to 2.32-4 solves the problem. > > That's the current version available in testing and unstable, so > > anybody running those will be fine. > > Right. I also have some similar hosts with libc-2.32, probably they were > upgraded to last version due to absence of old kernels, old gcc, etc. > Rsync runs fine on them. Good to know. > > If anything, 3.2.3-7 is fixing the very same issue you reported, which > > should have been happening in rsync 3.2.3 + libc6 2.32 (but you > > mention you had an older libc6). > > > > Overall I believe there might be something wrong in your system, > > related to libc6. > > Every system with periodic updates might have outdated packages, > generally it's not a problem (and should not be a problem) if binary API > is compatible and all package dependences are correct. Having outdated packages is not a problem, but having only a subset of them is an indicator of something wrong. Rsync 3.2.3-7 migrated to testing after libc6 2.32, so this issue will not happen unless the person purposely holds libc back. I thought your system was running like that by accident. I'm not judging here, I just meant to explain that the trigger to the issue will not affect every Debian user. My current guess is that rsync's workaround accidentally moved the regression from libc 2.32 to libc < 2.32. I've added a comment to rsync's issue, you can follow the discussion there as well: https://github.com/WayneD/rsync/issues/109 To be clear, I agree that as it stands right now, rsync should depend on libc >= 2.32, but I don't wanna make this change before confirming with upstream that this is not being caused by a regression from the workaround. Being able to keep the current version requirement will be important in the long term as I want to be able to upload new releases to backports. I also think that there's a chance rsync's upstream solves the new regression soon (if confirmed), which would deem the version bump unneeded. What do you think? Thank you, -- Samuel Henrique <samueloph>
