Bug 16211

Investigated upstream testsuite.

rsync provides both make check and make installcheck.

The tests are driven by runtests.py.

installcheck appears to be suitable for a ptest implementation because it runs against an installed rsync binary ($(bindir)/rsync).

The testsuite requires helper programs listed in CHECK_PROGS (tls, getgroups, getfsdev, testrun, trimslash, t_unsafe, wildtest, simdtest).

Initial investigation suggests ptest support is feasible.

I have been working on adding ptest support for rsync.

I have implemented ptest support for rsync and tested it on qemux86-64.

A representative successful run shows:

root@qemux86-64:~# ptest-runner rsync
START: ptest-runner
2026-05-31T14:06
BEGIN: /usr/lib/rsync/ptest
============================================================
runtests.py running in /usr/lib/rsync/ptest
    rsync_bin=/usr/bin/rsync
    srcdir=/usr/lib/rsync/ptest
    TLS_ARGS=-l -L
    testuser=root
    os=Linux qemux86-64 6.18.33-yocto-standard #1 SMP PREEMPT_DYNAMIC Wed May 27 22:05:49 UTC 2026 x86_64 GNU/Linux
    preserve_scratch=no
    scratchbase=/usr/lib/rsync/ptest/testtmp
PASS    00-hello
PASS    acls-default
PASS    acls
PASS    alt-dest
PASS    atimes
PASS    backup
PASS    batch-mode
PASS    chgrp
PASS    chmod-option
PASS    chmod-temp-dir
PASS    chmod
PASS    chown
PASS    clean-fname-underflow
SKIP    crtimes (Rsync is configured without crtimes support)
PASS    daemon-gzip-download
PASS    daemon-gzip-upload
PASS    daemon
PASS    delay-updates
PASS    delete
PASS    devices
PASS    dir-sgid
PASS    duplicates
PASS    exclude-lsh
PASS    exclude
PASS    executability
PASS    files-from
PASS    fuzzy
PASS    hands
PASS    hardlinks
PASS    itemize
PASS    longdir
PASS    merge
PASS    missing
PASS    mkpath
PASS    open-noatime
PASS    protected-regular
PASS    relative
PASS    safe-links
PASS    simd-checksum
PASS    ssh-basic
PASS    symlink-ignore
PASS    trimslash
PASS    unsafe-byname
PASS    unsafe-links
PASS    wildmatch
PASS    xattrs
------------------------------------------------------------
----- overall results:
      45 passed
      1 skipped
------------------------------------------------------------
overall result is 0
DURATION: 91
END: /usr/lib/rsync/ptest
2026-05-31T14:08
STOP: ptest-runner
TOTAL: 1 FAIL: 0


45 passed
1 skipped (crtimes)
overall result is 0

The skipped test is expected because rsync was configured without crtimes support.

To assess stability, I executed the ptest repeatedly on qemux86-64. While most runs completed successfully with the above result, I also observed intermittent failures in backup.test. Over 20 runs, backup.test failed 5 times.

The failure alternates between:

no backup message output for deep/name1

and

no backup message output for deep/name2

Example failure output:

>f.s....... deep/name2
backed up deep/name2 to deep/name2~
no backup message output for deep/name1


All other tests pass consistently.

At this point the ptest packaging appears functional and the remaining issue seems limited to the intermittent behavior of backup.test in the qemux86-64 environment.

Nikhil,

Excellent work! I particularly like that you have run the ptests
20 times to look for intermittent issues before it gets tested on
the Yocto auto-builder.

I suggest that you add a patch/filter to skip the intermittently failing
backup test and report that up upstream to get to the root cause.
Check rsync's development work at:
   https://github.com/RsyncProject/rsync.git

You can either submit that to the oe-core email list or 
wait a week to see if upstream can explain/fix the bug.

I don't think you need this link but in case other people who do
are following along:
  https://docs.yoctoproject.org/contributor-guide/index.html

Thanks.

Hi Randy,

I have reported the bug upstream 

https://github.com/RsyncProject/rsync/issues/941

Will add a patch/filter to skip the intermittently failing
backup test and send it to oe-core email list.

Will keep a track on the upstream issue as well.



Thanks

Submitted a patch in oe core

https://lists.openembedded.org/g/openembedded-core/message/237969