Use `assert_eq!` for the `unshare()` calls so that we can figure out what error code is being returned.

[pcwalton]

This should help us diagnose #44.

r? @jdm

[pcwalton]

@jdm I wonder if Travis is itself running its jobs under a namespace, so the attempt to create a new one fails. I have this suspicion because the manpage for unshare(2) reports that EPERM can be returned for the following reasons:

   EPERM  CLONE_NEWUSER was specified in flags, but either the effective
          user ID or the effective group ID of the caller does not have
          a mapping in the parent namespace (see user_namespaces(7)).

   EPERM (since Linux 3.9)
          CLONE_NEWUSER was specified in flags and the caller is in a
          chroot environment (i.e., the caller's root directory does not
          match the root directory of the mount namespace in which it
          resides).

It could be, for example, that Travis is running jobs in a chroot and therefore the call to unshare() is failing.

[Eijebong]

Travis uses docker and yeah I had the same problem yesterday when I tried to run mock in a docker container. No idea how to fix it except giving CAP_SYS_ADMIN to the container which we probably can't request to travis ?

[Eijebong]

Ping on this ?

[jdm]

The answer might be to switch to taskcluster for testing if this is fundamentally incompatible with the containers that TravisCI provides.

[Eijebong]

Fixed by #50 :tada: