Whoops, that attachment was from my Rawhide mock-build. That said, it's showing the same results as on F26. So it clearly affects F26+.

OK, so this is odd. It fails consistently when I do a local mock-build (on two separate machines), but it succeeds consistently when I do a Koji scratch-build.

Something about these tests apparently likes the Koji builder environment but not the local environment.

This must be related to the latest mock which uses systemd-nspawn instead of chroot [0]

Using mock-1.3.4-1.fc25.noarch, python-requests builds fine locally, however when I update to mock-1.4.1-1.fc25.noarch from updates-testing I get these test failures.

[0] https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.1

Ahh, that would make sense. So should the bug be reassigned to mock or will the fix be in python-requests?

(In reply to Stephen Gallagher from comment #4)
> Ahh, that would make sense. So should the bug be reassigned to mock or will
> the fix be in python-requests?

Not sure of the internal mechanics of this mock change here and how that might affect test coverage in requests (or any other package). I suppose the bugzilla can re reassigned to mock for the time being as the maintainers should have more insight on this.

Ahh, I know what this is. Sorry for the slow response, I wasn't in front of my computer much this weekend.

Can you try building without being connected to the Red Hat VPN? The upstream tests use a "tar pit" IP[1] that the tests assume will always fail with a connection timeout. Red Hat has a host there that refuses the connection and that causes the tests to fail.

[1] https://github.com/kennethreitz/requests/blob/bf1a2a4e399ec5e75c5e9aadae564f77ca99afff/tests/test_requests.py#L40

Okay, I confirmed that even without the Red Hat VPN it's still a problem with the new mock.

Specifically, the issue is that previously opening a socket to 10.255.255.1 port 80 would simply hang forever, but now it's getting a "[Errno 101] Network is unreachable". 

The systemd-nspawn command is being run with --private-network[0], which is causing this problem. Running without that works fine. I guess that anything not heading for the loopback device gets reset rather than quietly dropped?

[0] https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--private-network

(In reply to Jeremy Cline from comment #7)
> Okay, I confirmed that even without the Red Hat VPN it's still a problem
> with the new mock.
> 
> Specifically, the issue is that previously opening a socket to 10.255.255.1
> port 80 would simply hang forever, but now it's getting a "[Errno 101]
> Network is unreachable". 
> 
> The systemd-nspawn command is being run with --private-network[0], which is
> causing this problem. Running without that works fine. I guess that anything
> not heading for the loopback device gets reset rather than quietly dropped?
> 
> [0]
> https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--
> private-network

I would call that a features rather than a bug. Our packaging policy has always required that packages build successfully in an environment with no network access. This is just making it fail hard if we're trying to reach out of the chroot.

Sure, I didn't mean to imply it was a bug, just that that's why it stopped working.

I suppose I'll either need to patch these tests out (which isn't very appealing) or re-work them so they only use the loopback device. Given that, I'll go ahead and re-assign this bug to requests.

it seems this bug was fixed by @jcline already.