> On Nov 14, 2016, at 3:47 PM, Adam Mercer <[email protected]> wrote: > > Hi > > Just tried to update my ports tree, with selfupdate, and it's failing > with the following: > > Synchronizing local ports tree from > rsync://rsync.macports.org/release/tarballs/ports.tar > DEBUG: /usr/bin/rsync -rtzv --delete-after > rsync://rsync.macports.org/release/tarballs/ports.tar > /opt/local/var/macports/sources/rsync.macports.org/release/tarballs > > Willkommen auf dem RSYNC-server auf ftp.fau.de. > Nicht all unsere Mirror sind per rsync verfuegbar. > > Welcome to the RSYNC daemon on ftp.fau.de. > Not all of our mirrors are available through rsync. > > > receiving file list ... rsync: link_stat "/tarballs/ports.tar" (in > release) failed: No such file or directory (2) > done > > sent 4 bytes received 9 bytes 8.67 bytes/sec > total size is 0 speedup is 0.00 > rsync error: some files could not be transferred (code 23) at > /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-47/rsync/main.c(1400) > [receiver=2.6.9] > Command failed: /usr/bin/rsync -rtzv --delete-after > rsync://rsync.macports.org/release/tarballs/ports.tar > /opt/local/var/macports/sources/rsync.macports.org/release/tarballs > Exit code: 23 > Error: Synchronization of the local ports tree failed doing rsync > DEBUG: Synchronization of 1 source(s) failed > while executing > "mportsync [array get global_options]" > port sync failed: Synchronization of 1 source(s) failed > [ram@abhoth ~]$ > > It does seem that there is no tarball at this location: > > [ram@abhoth ~]$ rsync rsync.macports.org::release/tarballs/ > > Willkommen auf dem RSYNC-server auf ftp.fau.de. > Nicht all unsere Mirror sind per rsync verfuegbar. > > Welcome to the RSYNC daemon on ftp.fau.de. > Not all of our mirrors are available through rsync. > > > drwxr-xr-x 4,096 2016/09/11 21:46:57 . > [ram@abhoth ~]$ > > Has this location changed?
No. There is a bug in mprsyncup in which updates of our private master rsync server are not atomic. I think that occasionally the public master rsync server must be connecting to the private server at exactly the wrong moment and ends up copying a broken configuration. I'm currently rewriting mprsyncup to hopefully lessen the likelihood of this problem. Eliminating it completely is quite difficult because there isn't an easy way to atomically replace more than a single file on a server, and even if that were possible, rsync doesn't ensure that a consistent set of files is transferred.
