weird rsync behaviour after switch to 15

[R2-D2]

Local machine just upgraded from 14.2 to 15.0. Rsync package version 3.2.3-x86_64-4.

Remote machine still on 14.2,
rsync package version 3.1.3-x86_64-1_slack14.2.

I have a directory on the remote machine that has always been backed up locally
with rsync. After switching to 15 every single file "is newer" on the local
machine, where it has always been "is uptodate".

$ rsync -arvvtu --delete user@remote:/remotedir/ /localdir

The files are identical, their timestamps are identical to the nanosecond. Any
clue? Idiosyncrasies between different rsync versions?

Thanks.

[John Forkosh]

R2-D2 <r2...@outer.space> wrote:
> The files are identical, their timestamps are identical to the nanosecond.
> Any clue?

chmod permissions?
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[R2-D2]

John Forkosh wrote on 2/24/22 11:44:

> R2-D2 <r2...@outer.space> wrote:
>> The files are identical, their timestamps are identical to the nanosecond.
>> Any clue?
>
> chmod permissions?

nope :-(

-rw-r--r-- on both sides.

username, uid, gid are also identical.

Groan...

[Lew Pitcher]

Apparently, idiosyncratic behavior that is corrected in the next upstream release of rsync.

See https://download.samba.org/pub/rsync/NEWS

"Fixed --update -vv to output "is uptodate" instead of "is newer" messages for files that are being skipped due to an identical modify time. (This was a new output quirk in 3.2.3.)"

[R2-D2]

Lew Pitcher wrote on 2/25/22 14:55:

Excellent news, thanks. I'll sit tight, looking forward to see
http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/rsync-3.2.3-i586-4.txz
replaced by 3.2.4.

[Henrik Carlqvist]

On Sun, 27 Feb 2022 21:39:43 +0100, R2-D2 wrote:
> looking forward to see
> http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/
rsync-3.2.3-i586-4.txz
> replaced by 3.2.4.

That is probably not going to happen. In the best case you will one day
find an updated rsync in http://ftp.slackware.com/pub/slackware/
slackware-15.0/slackware/patches , but that is probably only going to
happen if some kind of security hole is found in rsync.

If you want the latest greatest version of all applications with its
advantages and disadvantages you should run Slackware current instead of
the stable Slackware 15.

If you are lucky you will be able to use an updated package from
Slackware current in Slackware 15.0.

regards Henrik

[Lew Pitcher]

On Mon, 28 Feb 2022 07:07:45 +0000, Henrik Carlqvist wrote:

> On Sun, 27 Feb 2022 21:39:43 +0100, R2-D2 wrote:
>> looking forward to see
>> http://ftp.slackware.com/pub/slackware/slackware-15.0/slackware/n/
> rsync-3.2.3-i586-4.txz
>> replaced by 3.2.4.
>
> That is probably not going to happen. In the best case you will one day
> find an updated rsync in http://ftp.slackware.com/pub/slackware/
> slackware-15.0/slackware/patches , but that is probably only going to
> happen if some kind of security hole is found in rsync.

I concur. Pat V. plays a conservative game, only upgrading packages to
cover specific needs (like changing timezone info) or specific threats
(like security exposures). It seems unlikely that Slackware would issue
a new rsync package simply to address a minor reporting issue.

> If you want the latest greatest version of all applications with its
> advantages and disadvantages you should run Slackware current instead of
> the stable Slackware 15.
>
> If you are lucky you will be able to use an updated package from
> Slackware current in Slackware 15.0.

Here's where you and I differ; with Slackware 15.0 /just/ released, it
seems, to me, to be a little, shall we say, imprudent to run Slackware
unstable, /just/ on the hopes of getting an update to /one/ package.

If I were in the OP's position, I'd simply download the rsync 3.2.4 source,
when it finally gets out of beta, and compile it myself. I'd use that
locally-installed rsync until Slackware releases it's own version.

For that matter, I'd build a local Slackware package (pkgtools aren't all
that hard to use), so that I can revert the change when Slackware releases
the official package.

Just my 2 cents worth here :-)
--
Lew Pitcher
"In Skills, We Trust"

[Rich]

Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
> If I were in the OP's position, I'd simply download the rsync 3.2.4
> source, when it finally gets out of beta, and compile it myself. I'd
> use that locally-installed rsync until Slackware releases it's own
> version.

Yes, this would be the proper way to proceed.

> For that matter, I'd build a local Slackware package (pkgtools aren't
> all that hard to use), so that I can revert the change when Slackware
> releases the official package.

The OP could use the rsync slackbuild from 15.0 to build the newer
rsync and package it up as a slackware package. Then, should a
security patch be issued by Pat at some point in the future, all the OP
needs to do is download the newer release, and do 'upgradepkg'.

[R2-D2]

R2-D2 wrote on 2/27/22 21:39:

3.2.4 came out a month ago:
https://download.samba.org/pub/rsync/NEWS#3.2.4
but it hasn't made its way into the slackware-15.0 repo yet. I guess it's time
to learn to build my own packages. :-)

[Chris Elvidge]

Have you looked in Slackware-current?
e.g.
https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/


--
Chris Elvidge
England

[R2-D2]

Chris Elvidge wrote on 5/16/22 18:06:

Wow, you are right!
http://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/n/rsync-3.2.4-x86_64-1.txz
But I wonder, is it safe in general to install current packages in a stable
version? Current has a different kernel version (5.17.8) from 15.0 (5.15.38).
Could that be a problem?

[Chris Elvidge]

Why would the kernel version make a difference?
Void (for e.g.) has rsync 3.2.4 and kernel 5.16.20


--
Chris Elvidge
England

[R2-D2]

Chris Elvidge wrote on 5/17/22 12:26:

Ok, the kernel may be fine, but this is what I get when running rsync-3.2.4 from
current on a 15.0:

rsync: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by rsync)

I'd rather not mess up other things trying to install glibc from current to 15.0.

[Henrik Carlqvist]

On Tue, 17 May 2022 10:21:57 +0200, R2-D2 wrote:
> But I wonder, is it safe in general to install current packages in a
> stable version?

I would say that in general it would be a better idea to use the
Slackbuild script together with sources to try to build the package from
current on your stable installation. As you say, kernel and library
versions might differ. Those differences might cause the new version not
to build, but if it builds it is good hope that the built binary will
work. If it doesn't build, I would start by comparing the Slackbuild
scripts between stable and current, maybe some new feature has been
enabled which needs to be disabled on stable?

regards Henrik

[R2-D2]

Henrik Carlqvist wrote on 5/17/22 18:44:

> On Tue, 17 May 2022 10:21:57 +0200, R2-D2 wrote:
>> But I wonder, is it safe in general to install current packages in a
>> stable version?
>
> I would say that in general it would be a better idea to use the

> Slackbuild script together with sources...

Ok, so this is what I've done:

1) downloaded the folder
http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/;
2) made executable, and ran as root, ./rsync.SlackBuild;
3) upgradepkg /tmp/rsync-3.2.4-x86_64-1.txz;
4) happily ran rsync, the "is newer" bug is gone.

Just wondering. Why did Pat turn
https://download.samba.org/pub/rsync/src/rsync-3.2.4.tar.gz *(1.1M)* into
http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/rsync-3.2.4.tar.lz
*(728K)*?
Just to save disk space? The content is identical, I checked the hashes of every
single file.

Thanks everyone.

[Rich]

R2-D2 <r2...@outer.space> wrote:
> Just wondering. Why did Pat turn
> https://download.samba.org/pub/rsync/src/rsync-3.2.4.tar.gz *(1.1M)* into
> http://ftp.slackware.com/pub/slackware/slackware-current/source/n/rsync/rsync-3.2.4.tar.lz
> *(728K)*?
> Just to save disk space? The content is identical, I checked the hashes of every
> single file.

That looks to be the reason. Your numbers above show the .lz file as a
bit over 25% smaller than the .gz original. Multiply an approximate
25% shrink across *all* source packages and you have quite a
substantial disk space savings.

And when trying to package into DVD disk sized chunks, disk space
savings can mean the difference between fitting into X vs X+1 DVD
disks.

[Henrik Carlqvist]

On Wed, 18 May 2022 13:39:51 +0000, Rich wrote:
> And when trying to package into DVD disk sized chunks, disk space
> savings can mean the difference between fitting into X vs X+1 DVD disks.

Yes, locking at the installation isos for Slackware 14.2 you can see that
the source directory has been omitted completely. This is probably
because the source directory contains more than 6 GB of data and in
itself would not fit on a single layer DVD (4.5 GB). Together with the
rest of the installation files it would not even fit on a dual layer DVD
(8.5 GB). To have the source directory in an ISO together with the rest
of the Slackware installation files would require a bluray disc to burn.

regards Henrik

[Chris Elvidge]

Advantages of .lz
https://fileinfo.com/extension/lz


--
Chris Elvidge
England