Release official builds (Linux)

[seandilda]

Can this project add official builds (against linux) to its release page? I was thinking something like OKD does (https://github.com/openshift/origin/releases). This would make it a lot easier to pull skopeo into a build container.

(I filed this in addition to #330 since #330 is focused on macOS binaries and I'm looking for linux builds here).

[cyphar]

I have written a release.sh that is mostly project-independent and is used for runc and umoci (as well as a handful of other projects). It gives you signed artifacts (including the source tree and binaries).

[rhatdan]

@TomSweeneyRedHat Could you look at this, at least have official containers with skopeo in them.

[TomSweeneyRedHat]

Related to #432

[TomSweeneyRedHat]

@rhatdan ack, will do

[debianmaster]

+1 for this

[gecube]

I'd like to have binary distribution too. I already faced with the problem that make binary uses ubuntu:18.10 so resulting binary can't be run on OpenSUSE.
Also skopeo depends on uidmap package from Ubuntu. And it is not obvious from documentation. If uidmap is not installed, I get the next error message:

Error: error running newgidmap: exec: "newgidmap": executable file not found in $PATH: 
ERRO[0000] error running newgidmap: : exec: "newgidmap": executable file not found in $PATH 
ERRO[0000] (unable to determine exit status)``` 

[mtrmac]

I'd like to have binary distribution too. I already faced with the problem that make binary uses ubuntu:18.10 so resulting binary can't be run on OpenSUSE.

Yes — we can’t make a single “official Linux build” because various Lines are not binary compatible! (E.g. last time this was a different SONAME of libdevmapper.so.)

We could, in principle, prepare different builds for various distributions, but at that point it seems more useful to actually provide / help maintain / link to native packages for those distributions.

[cyphar]

A simple solution is to statically compile the distributed binaries. Yes, it's not as safe (in terms of security updates) as dynamically linked binaries -- but it would solve this problem (and users who care about security should be using distribution packages anyway).

[rhatdan]

I am fine with creating a static version, and we are going to be adding container images with skopeo inside of them similar to what we have done with buildah and a PR exists for Podman now. The issue with static skopeo is I believe certain features will need to be disabled (Devmapper support?) if static c libraries do not exists.

[gecube]

Another option is to check if dynamically linked is available and then and only then - use functions from it. Unfortunately, I don't know if it is possible in Golang, but I am sure that this will work.

[cyphar]

@gecube It is possible (I wrote some patches for Docker that are now in containers/storage that do this for devicemapper) but it's very difficult and not worth the trouble. It has to be done the old-fashioned way with dlsym and cgo and can be incredibly fragile.

[sslavic]

In Pop OS I couldn't find skopeo package. I tried installing skopeo with linuxbrew, but build fails

$ brew install skopeo   
==> Downloading https://github.com/containers/skopeo/archive/v0.1.36.tar.gz
Already downloaded: /home/foo/.cache/Homebrew/downloads/fe32225729231d92149ab640ef77c7c4c98b864b53640af2fd527d532ffefbd6--skopeo-0.1.36.tar.gz
==> make binary-local
Last 15 lines from /home/foo/.cache/Homebrew/Logs/skopeo/01.make:
2019-06-10 21:06:32 +0200

make
binary-local

go build "-buildmode=pie" -ldflags "-X main.gitCommit=" -gcflags "" -tags "   containers_image_ostree_stub " -o skopeo ./cmd/skopeo
# pkg-config --cflags  -- devmapper
Package devmapper was not found in the pkg-config search path.
Perhaps you should add the directory containing `devmapper.pc'
to the PKG_CONFIG_PATH environment variable
No package 'devmapper' found
pkg-config: exit status 1
make: *** [Makefile:98: binary-local] Error 2

READ THIS: https://docs.brew.sh/Troubleshooting

It fails even with PKG_CONFIG_PATH set to /usr/lib/x86_64-linux-gnu/pkgconfig/:/home/linuxbrew/.linuxbrew/opt/isl@0.18/lib/pkgconfig, and devmapper.pc available in /usr/lib/x86_64-linux-gnu/pkgconfig

On the other hand building from latest source works:

$ make binary-local
go build "-buildmode=pie" -ldflags "-X main.gitCommit=6307635b5fc719e6e74588c7d04df449eb9557f7" -gcflags "" -tags "   ostree " -o skopeo ./cmd/skopeo

Wish installing skopeo via linuxbrew worked across distros.

[TomSweeneyRedHat]

FYI @lsm5 (in case it's not on your radar already)

[hswong3i]

Could we reference CRI-O static build which utilize nix packaging?

See https://github.com/cri-o/cri-o/blob/master/tutorials/setup.md#static-builds:

It is possible to build a statically linked binary of CRI-O by using the officially provided nix package and the derivation of it within this repository. The builds are completely reproducible and will create a x86_64/amd64 stripped ELF binary for glibc. These binaries are integration tested as well and support the following features:

• apparmor
• btrfs
• device mapper
• gpgme
• seccomp
• selinux

[mtrmac]

FWIW there are now official containers, courtesy of @TomSweeneyRedHat ; see #432 (comment) .

[seandilda]

For anyone else coming across this same issue, I have found a work around.

Crane (https://github.com/google/go-containerregistry/blob/master/cmd/crane/doc/crane.md) offers a lot of the same functionality as skopeo, but has a binary release available as part of the tarballs at https://github.com/google/go-containerregistry/releases

[cristim]

thanks @seandilda you just saved me after spending an entire day looking for such a solution! Crane is awesome and exactly what I was looking for.

[lieinsun]

@seandilda thanks a lot, crane.Save(...) save me!!