Created attachment 1708807 [details]
build.log

Created attachment 1708808 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1708809 [details]
state.log

A test failed:

t/41routine.t ................ ok
Warning: unable to close filehandle $wr properly: Bad file descriptor during global destruction.
Warning: unable to close filehandle $wr properly: Bad file descriptor during global destruction.
Warning: unable to close filehandle $out properly: Bad file descriptor during global destruction.
Warning: unable to close filehandle $out properly: Bad file descriptor during global destruction.
Warning: unable to close filehandle properly: Bad file descriptor during global destruction.
Warning: unable to close filehandle properly: Bad file descriptor during global destruction.
t/42function.t ............... ok
#   Failed test '->failure [3] gives EAI_NONAME or EAI_NODATA'
#   at t/50resolver.t line 344.
# $errno is -3
# Looks like you failed 1 test of 35.
t/50resolver.t ............... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/35 subtests 

I cannot reproduce it locally.

Adding Data::Dumper to the mix, I get the following structure:
                'failure' => [
                                'Temporary failure in name resolution',
                                'resolve',
                                'getaddrinfo',
                                -3
                              ],

So the issue here is that we're getting a temporary failure (EAI_AGAIN) instead of a definite one (EAI_NONAME or EAI_NODATA)... Upstream has similar bug reports already open. RT bug #131109 seems to be the closest)

I think something must have changed in glibc in Rawhide and how it behaves when networking is disabled. I had a very similar issue with the proftpd test suite:
https://github.com/proftpd/proftpd/pull/1075

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

In mock environment there is an empty /etc/resolv.conf and thus glibc resolver sends the DNS queries using UDP to 127.0.0.1:53. The new mock isolates the network with namespaces, and because no DNS server listens on UDP/127.0.0.1:53, an ICMP error is replied:

13:21:12.632469 IP 127.0.0.1.39746 > 127.0.0.1.domain: 12204+ A? TbK4jM2M0OS.lm57DWIyu4i. (41)
E..Ei.@.@............B.5.1.D/............TbK4jM2M0OS.lm57DWIyu4i.....
13:21:12.632478 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port domain unreachable, length 77
E..aHP..@.3.................E..Ei.@.@............B.5.1.D/............TbK4jM2M0OS.lm57DWIyu4i.....

then kernel reports an error on the socket:

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])
sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\274\20\1\0\0\1\0\0\0\0\0\0\vTbK4jM2M0OS\vlm57DWI"..., iov_len=41}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=41}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\262\22\1\0\0\1\0\0\0\0\0\0\vTbK4jM2M0OS\vlm57DWI"..., iov_len=41}], msg_iovlen=1, msg_controllen=0, msg_flags=0}}], 2, MSG_NOSIGNAL) = 1
poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=3, revents=POLLOUT|POLLERR}])
sendto(3, "\262\22\1\0\0\1\0\0\0\0\0\0\vTbK4jM2M0OS\vlm57DWI"..., 41, MSG_NOSIGNAL, NULL, 0) = 41
poll([{fd=3, events=POLLIN}], 1, 4999)  = 1 ([{fd=3, revents=POLLERR}])
close(3)                                = 0

And glibc getaddrinfo() translates the socket error to EAI_AGAIN code. It cannot be EAI_NODATA, because there was no server reply that would confirm that the domain name has now network address. It cannot be EAI_NONAME, because there was no server reply to confirm that no such domain name exist. Next suitable code would be EAI_FAIL to indicate a permanent error. EAI_AGAIN indicates a temporary error.

Which one of the two is better in this case is questionable, but the t/50resolver.t does not expect none of them and that's clearly a fault of the test. Basically the test expects that a DNS server is available, but this is not the of the mock environment.

FEDORA-2020-70fc3971f6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-70fc3971f6

FEDORA-2020-70fc3971f6 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-70fc3971f6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-70fc3971f6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-70fc3971f6 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.