I have SYNC="rsync://[2001:48a8:0:8:0:3:0:232]/gentoo-portage" in my make.conf, and every time I run emerge --sync, it works but it complains: emerge --sync !!! getaddrinfo failed for '[2001': [Errno -2] Name or service not known >>> Starting rsync with rsync://[2001:48a8:0:8:0:3:0:232]/gentoo-portage... >>> Checking server timestamp ... Welcome to lug.mtu.edu, the rsync server for Reproducible: Always Steps to Reproduce: 1. Set a specific IPv6 address for the SYNC line 2. emerge --sync 3. getaddrinfo will fail Actual Results: It reports a failure, but then continues. It is as if it doesn't understand the bracket form for IPv6 Expected Results: It should understand that it has been given a direct IPv6 address. The reason I hardcoded [2001:48a8:0:8:0:3:0:232] instead of using lug.mtu.edu is that it has both IPv4 and IPv6 and it was preferring IPv4 and I want it to use IPv6: host lug.mtu.edu lug.mtu.edu has address 141.219.155.230 lug.mtu.edu has IPv6 address 2001:48a8:0:8:0:3:0:232
The problem is this code: proto, user_name, hostname, port = re.split( "(rsync|ssh)://([^:/]+@)?([^:/]*)(:[0-9]+)?", syncuri, maxsplit=4)[1:5] Given your SYNC setting, this code incorrectly get hostname="[2001" from the ([^:/]*) group.
Created attachment 263753 [details, diff] handle IPv6 [ip] in SYNC This should fix it: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0f065ee055741fe219187df3ad5fb58055a53902
That gives me: emerge --sync !!! getaddrinfo failed for '[2001:48a8:0:8:0:3:0:232]': [Errno -2] Name or service not known >>> Starting rsync with rsync://[2001:48a8:0:8:0:3:0:232]/gentoo-portage... >>> Checking server timestamp ... Welcome to lug.mtu.edu, the rsync server for which is closer, but shouldn't getaddrinfo succeed when given an IP address? It works when I give it an IPv4 address.
Created attachment 263755 [details, diff] handle IPv6 [ip] in SYNC Now it's fixed to strip the brackets for getaddrinfo: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4609f5da90f3d925255d68c2cacc1bda6814dfcf
Seems to work for me!
Great, thanks for testing.
This is fixed in 2.1.9.42 and 2.2.0_alpha26.