The const SYS_SETNS is defined in the syscall package.  It should be referenced as syscall.SYS_SETNS, or change the way syscall is imported.  I tried both of these examples with gccgo and they compiled successfully:

Example 1:
package main

import (
        "fmt"
        . "syscall"
)

func main() {
    fmt.Printf("Hello, World: %d\n", SYS_SETNS)
}

Example 2:
package main

import (
        "fmt"
        "syscall"
)

func main() {
    fmt.Printf("Hello, World: %d\n", syscall.SYS_SETNS)
}

The problem related to mismatched data types is discussed in https://github.com/golang/go/issues/12124.  I talked to the person here who is working on submission of this fix to Docker and she said they are still waiting for it to be accepted.

She has a branch with the fix in at https://github.com/clnperez/runc/tree/power-ci-main.

If you want to open a seperate BZ for the mismatched data types issue, we can move this conversation there. 

In the meantime, here are the two patches you can cherry-pick into a runc branch to build with (and change the runc line in your hack/vendor.sh):

Merged upstream, but not in the runc version docker has in its vendor.sh
https://github.com/opencontainers/runc/commit/
9bc81d16999c324d6c04a3baa124065fc73e3133

Won't be merged upstream, b/c docker plans to move from runc's seccomp to seccomp/libseccomp:
https://github.com/clnperez/runc/commit/a12d6c602066f74723dbf29d32501b523affefad

clnperez, so what do you want us to do now?

Libseccomp support has already landed in Runc and been vendored into Docker, and should be in the upcoming 1.9 release (and rawhide docker-1.9 builds). Given this, both compile failures you note should be solved in the 1.9 release, which I believe will be hitting F22 stable once it's released in late October.

In the meantime: we already carry a patch to strip out Seccomp support from Runc to enable compilation on non-AMD64 architectures, so you shouldn't be seeing build failures from that. I'll see about getting the other patch into our existing 1.8 builds for Fedora.

> In the meantime: we already carry a patch to strip out Seccomp support from
> Runc to enable compilation on non-AMD64 architectures, so you shouldn't be
> seeing build failures from that. I'll see about getting the other patch into
> our existing 1.8 builds for Fedora.

We have seccomp in ARMv7 and aarch64 so it's likely only needed for PPC64/s390x

s390(x) and ppc64 support are already in libseccomp master branch, so should be just matter of a new libseccomp release. The missing ppc SECCOMP_FILTER kernel support is also merged since 4.2.

We also have a build flag in Docker/runc upstream (not yet in any releases) to completely remove Seccomp support as well, so systems without a compatible libseccomp can still use both.

Hi, could we get a patched package soon? Currently we are stuck on docker 1.7 for s390 and ppc :-(

Dan can we start building docker-1.9?

Patch is now in the Fedora docker-1.8 tree - sorry for the delay on this.

Next build should contain it.

(In reply to Daniel Walsh from comment #9)
> Dan can we start building docker-1.9?

If this "Dan" is me :-) then I don't see a problem with going to 1.9 in F-23 from the secondary arches point of view. I guess it might be easier to fix possible issues in docker 1.9 than in 1.8.

(In reply to Dan Horák from comment #11)
> (In reply to Daniel Walsh from comment #9)
> > Dan can we start building docker-1.9?
> 
> If this "Dan" is me :-) then I don't see a problem with going to 1.9 in F-23
> from the secondary arches point of view. I guess it might be easier to fix
> possible issues in docker 1.9 than in 1.8.

Probably a bit late in the cycle for a 1.9 rebase, either way it'll need to be filed (sooner rather than later) as either a blocker or freeze exception to get an update in. Can someone make the decision and file this bug as one or the other RSN.

https://qa.fedoraproject.org/blockerbugs/propose_bug

Fixed in docker-1.9.