Release an official OS X binary of the client

[cap10morgan]

For getting Docker into Homebrew, it would be great to have an official OS X binary release.

[shykes]

+1. Docker already builds on OSX, the main blocker is setting cross-compilation in our build environment. I heard it's not hard but never actually tried.

—

@solomonstre
@getdocker

On Wed, Aug 21, 2013 at 9:17 AM, Wes Morgan notifications@github.com
wrote:

For getting Docker into Homebrew, it would be great to have an official OS X binary release.

Reply to this email directly or view it on GitHub:
#1616

[crosbymichael]

https://github.com/davecheney/golang-crosscompile

[jpetazzo]

There is also some interest for ARM binary. If we do cross-compilation (and I think it's a great idea!) maybe we should also output ARM binaries. No objection?

[kencochrane]

@jpetazzo +1

[bortels]

Confusion - without AUFS support, would this have any use? (I would very much like native OS X docker, obviously)

Broadening the question a bit - is there any utility to docker with, say, a read-only filesytem, or where the filesystem is "real" but just a subdirectory? I think maybe yes?

[cap10morgan]

@bortels The client is useful for talking to a remote (or VM-based) daemon running on Linux, but you're right, the daemon doesn't run on OS X.

[bortels]

Ah, ok - makes sense. Not a use-case I think I was even aware of. :-)

[shykes]

I am scheduling this tentatively for 0.7

[cap10morgan]

Any progress on this? It seems that 0.7.1 is out, is there an OS X binary to go with it?

[creack]

Tentatively scheduling for 0.7.3.
@cap10morgan Be aware that even when we do that, You will be able to use it only as a client.

[cap10morgan]

@creack Thanks for the update. I'm aware that it's client-only. I'm trying to get the client into Homebrew so it can be easily installed in OS X and used to talk to a Docker daemon running inside a Linux VM (or other remote Linux hosts).

[creack]

@kencochrane @jpetazzo Everything for OSX is in place so it should come pretty soon. For ARM however, much more refactoring is necessary. We will get there, but a bit later.
@cap10morgan I'll try to get to it this week.

[solomonstre]

/cc @steeve

On Mon, Dec 16, 2013 at 11:28 AM, Guillaume J. Charmes
notifications@github.com wrote:

@kencochrane @jpetazzo Everything for OSX is in place so it should come pretty soon. For ARM however, much more refactoring is necessary. We will get there, but a bit later.

@cap10morgan I'll try to get to it this week.

Reply to this email directly or view it on GitHub:
#1616 (comment)

[steeve]

@creack I have a fair bit of knowledge regarding cross-compiling Go programs to pretty much everything with https://github.com/steeve/xbmctorrent let me know if I can help you guys

[creack]

@steeve If you want to take over this, be my guest :). It is fairly trivial to do it for OSX. ARM is as trivial but requires to add couple of buildtags and/or files

[solomonstre]

@steeve I copied you because of your interest in a homebrew recipe and generally providing a more polished install of docker on the Mac.

On Mon, Dec 16, 2013 at 2:44 PM, Guillaume J. Charmes
notifications@github.com wrote:

@steeve If you want to take over this, be my guest :). It is fairly trivial to do it for OSX. ARM is as trivial but requires to add couple of buildtags and/or files

Reply to this email directly or view it on GitHub:
#1616 (comment)

[steeve]

@solomonstre yeah i figure, @creack, can you assign this to me? as it's on a collision course with one of the next feature for https://github.com/steeve/boot2docker

[mboersma]

Docker v0.7.1 will build for Mac (with some shenanigans), but v0.7.2 craters:

$ CC=clang go install -a
# github.com/dotcloud/docker/graphdriver/aufs
graphdriver/aufs/aufs.go:330: undefined: syscall.MS_REMOUNT

I would really like to see Mac OS X docker client supported. Please let me know if there are related issues I could help with.

Here are my notes on building Docker v0.7.1 for Mac OS X 10.9, FYI:
https://gist.github.com/mboersma/7954708

[shykes]

Hey @tianon, are you asking at what URL we should host official builds for other archs and platforms than Linux/x86_64? If so, the answer is simple: start from the current "binary" bundle and replace "Linux" and "x86_64" with the arch and platform in question.

For example, according to the current URL structure, an official build of Darwin/x86_64 would be at:

$BUCKET/builds/Darwin/x86_64/docker-$VERSION

Ok with you?

[tianon]

That's exactly what I was thinking, @shykes, and hoping you'd say. I'll plan on making some time tonight to stub in that uploading in release.sh so we can finally close this.