R2-D2 wrote on 2/27/22 21:39:
> Lew Pitcher wrote on 2/25/22 14:55:
>> On Thursday, 24 February 2022 at 04:02:27 UTC-5, R2-D2 wrote:
>>> 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.
>>
>>
>> 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.)"
>
> 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.

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. :-)

On 16/05/2022 15:44, R2-D2 wrote:
> R2-D2 wrote on 2/27/22 21:39:
>> Lew Pitcher wrote on 2/25/22 14:55:
>>> On Thursday, 24 February 2022 at 04:02:27 UTC-5, R2-D2 wrote:
>>>> 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.
>>>
>>>
>>> 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.)"
>>
>> 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.
>
> 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. :-)

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

--
Chris Elvidge
England

Chris Elvidge wrote on 5/16/22 18:06:
> On 16/05/2022 15:44, R2-D2 wrote:
>> R2-D2 wrote on 2/27/22 21:39:
>>> Lew Pitcher wrote on 2/25/22 14:55:
>>>> On Thursday, 24 February 2022 at 04:02:27 UTC-5, R2-D2 wrote:
>>>>> 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.
>>>>
>>>>
>>>> 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.)"
>>>
>>> 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.
>>
>> 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. :-)
>
> Have you looked in Slackware-current?
> e.g. https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/
>
>

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?

On 17/05/2022 09:21, R2-D2 wrote:
> Chris Elvidge wrote on 5/16/22 18:06:
>> On 16/05/2022 15:44, R2-D2 wrote:
>>> R2-D2 wrote on 2/27/22 21:39:
>>>> Lew Pitcher wrote on 2/25/22 14:55:
>>>>> On Thursday, 24 February 2022 at 04:02:27 UTC-5, R2-D2 wrote:
>>>>>> 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.
>>>>>
>>>>>
>>>>> 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.)"
>>>>
>>>> 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.
>>>
>>> 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. :-)
>>
>> Have you looked in Slackware-current?
>> e.g.
>> https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/
>>
>>
>>
>
> 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?

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

Chris Elvidge wrote on 5/17/22 12:26:
> On 17/05/2022 09:21, R2-D2 wrote:
>> Chris Elvidge wrote on 5/16/22 18:06:
>>> On 16/05/2022 15:44, R2-D2 wrote:
>>>> R2-D2 wrote on 2/27/22 21:39:
>>>>> Lew Pitcher wrote on 2/25/22 14:55:
>>>>>> On Thursday, 24 February 2022 at 04:02:27 UTC-5, R2-D2 wrote:
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> 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.)"
>>>>>
>>>>> 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.
>>>>
>>>> 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. :-)
>>>
>>> Have you looked in Slackware-current?
>>> e.g. https://mirror.bytemark.co.uk/slackware/slackware64-current/slackware64/n/
>>>
>>>
>>
>> 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?
>
> Why would the kernel version make a difference?
> Void (for e.g.) has rsync 3.2.4 and kernel 5.16.20

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.

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

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.

R2-D2 <r2-d2@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.

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

On 18/05/2022 11:17, R2-D2 wrote:
> 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.

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

--
Chris Elvidge
England