Comment # 15 on bug 1046197 from
After the last comments, I had hoped that this issue would be fixed with the
next update of rsync. Yet here is rsync-3.1.2-2.2.x86_64, and the problem
remains. In fact, the spec file for 2.2 is exactly the same as for 2.1, except
for the Release line, so why have a new release at all? Someone did change the
release number, or was this done by a script?

By the way, the supposed build date is exactly "Jun 14 14:00:00 2017" both for
rsync-3.1.2-2.1 and rsync-3.1.2-2.2, so it seems that information is useless.
But the Signature Date f�r 2.2 says Jul 17.

As mentioned before, having an rsync incapable of handling compression on the
server side means that there will be no transfer at all, not merely a fallback
to uncompressed.
At least is seems that "zypper up" wont replace my rsync version.

A simple solution is to just use the library that comes with rsync. That might
not be the optimal solution, but it works while searching for a better
solution.

--- a/rsync.spec
+++ b/rsync.spec
@@ -64,7 +64,7 @@

 %prep
 %setup -q -b 1
-rm -f zlib/*.h
+#rm -f zlib/*.h
 patch -p1 < patches/acls.diff
 patch -p1 < patches/xattrs.diff
 patch -p1 < patches/slp.diff
@@ -79,7 +79,7 @@
 export LDFLAGS="-Wl,-z,relro,-z,now -pie"
 %configure \
   --with-included-popt=no \
-  --with-included-zlib=no \
+  --with-included-zlib=yes \
   --disable-debug \
   --enable-slp \
   --enable-acl-support \


You are receiving this mail because: