socket-0.5.3.0 fails test suite

[UnkindPartition]

@peti reports that socket-0.5.3.0 does not pass its own tests.

I get different results, but they also seem to indicate a failure. (Btw, I get the exact same results with 0.6.)

socket-0.6.0.0: test (suite: AddrInfo)

"t0002.0"
AddrInfo: t0003.2

socket-0.6.0.0: test (suite: EOPNOTSUPP)

socket-0.6.0.0: test (suite: EPIPE)

"E15"

socket-0.6.0.0: test (suite: IPV6_V6ONLY)

"t0001.7"

socket-0.6.0.0: test (suite: NonBlockingIO)

socket-0.6.0.0: test (suite: NonBlockingIO-threaded)

socket-0.6.0.0: test (suite: PingPong)

"99122/2s"

socket-0.6.0.0: test (suite: TCP)

Test "test0001.01": OK   
Test "test0001.02": OK   

socket-0.6.0.0: test (suite: TCP-sendAndRecvAll)

socket-0.6.0.0: test (suite: UDP)

Test suite failure for package socket-0.6.0.0
    AddrInfo:  exited with: ExitFailure 1
Logs printed to console

Two questions:

1. Do you know what's going on and how to fix it? If you like, I could look into it.
2. How would you feel if I converted your set of test suites to a single tasty-powered test suite? As it stands, the test results are rather hard to make sense of. I feel this could be greatly improved.

[lpeterse]

Hi,

I don't know exactly what's going on and why there are so many tests failing, but the one mentioned by @peti is definitely a duplicate of this one: https://github.com/lpeterse/haskell-socket/issues/11. It happened when I tried to build the library in a Docker container from an Ubuntu 15.10 image with minimal dependencies (especially netbase was missing). The OS's name resolution system needs a properly populated /etc/services to satisfy the test. This assumption is probably too strong and the test is wrong.

I greatly appreciate any help. If you feel motivated to convert the test suite I'd be more than happy to accept your pull request.

Btw: Did you actually use this library or know anyone doing so? I can only guess from the downloads on Hackage, but I'm not in touch with anyone depending on it so far.

[peti]

NixOS runs tests in a chroot() environment that has no network services, i.e. attempts to resolve host names or service names will fail. I guess that explains the error we have seen there. It would be great to distinguish that particular case as "inconclusive" rather than "failed" in the test suite. Do you think that's possible?

[UnkindPartition]

Did you actually use this library or know anyone doing so?

Yes, I used it while working for @signalvine to send metrics via UDP, and was fond of it. So, thank you for writing it!

I am no longer with @signalvine, so I don't use it myself (although I'm sure it's still used there), but I've got some time and will gladly help out with a good project like this.

I also discussed/advertised it on our Russian-speaking podcast (apologies if you don't understand Russian..)

[lpeterse]

@peti: Are there more limitations I have to expect than just the chroot()? As only the name resolution test fails I assume this is not the case, but I just want to reassure. I think it is a decent solution to just test the name resolution operations with IP addresses and not with names. The benefit is near zero as it rather tests the libc implementation than anything my library does.

@feuerbach: Cool. I regret I don't speak any Russian, but it nonetheless motivates me to proceed.

Apart from the effort of refactoring the whole test suite, do you both think I it is a viable quick fix to fix the existing test and package a 0.5.3.1 (resp. 0.6.0.1)? Is it possible at all to push minor version upgrades to Hackage for older branches?

[UnkindPartition]

Is it possible at all to push minor version upgrades to Hackage for older branches?

Sure, I am not aware of any limitations on that front.

[peti]

Are there more limitations I have to expect than just the chroot()? As only the name resolution test fails I assume this is not the case, but I just want to reassure.

At least in NixOS, build environments have no network access, i.e. you cannot resolve DNS names or TCP/UDP service names. Other resources can be made available if required, I guess.

Do you both think I it is a viable quick fix to fix the existing test and package a 0.5.3.1 (resp. 0.6.0.1)?

Yes, a quick point release that makes it into Stackage ASAP would be very welcome!

[lpeterse]

Done. New versions 0.5.3.1 and 0.6.3.1 are on Hackage and have been verified by TravisCI (I had to add a new travis file for the 0.5.3.1 version).

[peti]

Very cool, thank you.