I'm stumped here why this isn't working as before on milonia, to transfer a whole bunch of files at a time with wildcards. While individual transfers are fine: rsync deino.kde.org:stable/release-service/20.08.3/src/yakuake-20.08.3.tar.xz . -v yakuake-20.08.3.tar.xz (success)
Wildcards no longer work: rsync deino.kde.org:stable/release-service/20.08.3/src/*.xz . rsync: link_stat "/srv/archives/ftp/stable/release-service/20.08.3/src/*.xz" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1816) [Receiver=3.2.3] rsync: [Receiver] write error: Broken pipe (32) Any ideas? On Sat, Oct 31, 2020 at 1:01 PM Ben Cooksley <[email protected]> wrote: > On Sun, Nov 1, 2020 at 4:49 AM Christoph Feck <[email protected]> wrote: > >> On 10/31/20 03:08, Ben Cooksley wrote: >> > This transition has now been completed, and going forward all access >> should >> > now be directed to deino.kde.org. >> >> Did I understand it correctly, that "deino" is the replacement for >> "milona", but shouldn't offer ssh/scp access anymore, but need to use >> sftp? >> > > Deino is the replacement to Milonia yes. > The restriction on access only applies to packagers and those with > accounts for managing data on files.kde.org/cdn.kde.org/distribute.kde.org > and doesn't apply to ftpadmin. > > >> For what it's worth, I could successfully ssh login to >> [email protected] (using the credentials I used previously on >> milona), and could use mkdir/chmod in stable/release-service path, >> albeit response time was very laggy. >> > > I've investigated that issue with response times and found that the > network adapter was extremely unhappy and regularly resetting itself. > Following a system reboot it appears to have been corrected, however we'll > monitor the system to confirm this is the case. > > >> If that's not the correct replacement procedure, please clarify. >> >> BG, >> Christoph >> > > Many thanks, > Ben > > >> >> -- >> Christoph Feck >> KDE Release Team >> >>
