#docker-dev

thanks for the merge crosbymichael

[docker] vieux force-pushed enable_sigproxy_default from 02d93c5 to 4613289: http://git.io/ZRqgPg

docker/enable_sigproxy_default e0b59ab Victor Vieux: Enable sig-proxy by default in run and attach

docker/enable_sigproxy_default 4613289 Victor Vieux: stop proxy at one point

hey joffrey are you still around?

shykes: yep

what's up? :)

want to talk about roadmap to launching stackbrew?

sure!

how do you feel about flipping the switch and promoting it to library

then get a few days of testing out of that before announcing it

I'm down. Any other changes you feel we should make?

There's this one thread about the syntax

I kind of agree with the people saying it might be confusing

I wanted to discuss that with you

If we do decide we want to change it, it's better to change it early

since it affects file formats, which stick around and need to be supported for a long time

I kinda liked the idea of having the build scripts in the repositories on the "base" images (ie ubuntu/debian/...), even if they're not used by the build. /cc tianon

how do you like the unique syntax "<docker_tag>: <url>[@<version>]"

where <version> could be a git branch, tag or commit

what if a tag and a branch share the same name in one repo ?

mmm

git has the same problem

when you 'checkout <tag_or_branch>'

you may get a warning about ambiguous refname

and then it chooses one

[docker] keeb opened pull request #2448: Fix export clause (master...fix-dsfg-readme) http://git.io/Ul2Xtg

I think the tag gets precedence

might make sense to mimic that

okay

*or* we could just never use branches

since their use is discouraged anyway

and using them would probably not yield the intended result for upstream contributors

and then if a tag replicates a commit ID, the commit ID would take precedence?

yeah

which is what git does also

(just checked)

what do you think?

sounding tasty to me

sure, works for me. while we're at it, let's make the @<version> mandatory

joffrey: you're talking about keeping library/ in the docker directory? or the whole stackbrew code?

why not just make only commit IDs acceptable?

tianon: I think we already settled on having library/ in the stackbrew repository

if it's still in the docker repo it can probably be removed now

ok :)

tianon: There's pros and cons to leaving @TAG as an option. What do you think shykes ?

[docker] tianon opened pull request #2449: Remove old remnants of stackbrew now that it's a separate project (master...remove-stackbrew-remnants) http://git.io/XXxCPQ

just working on the release docs https://docs.google.com/document/d/1fxxjttDmzwM...

crosbymichael: it may be too late, but may you please consider gh#2448 in the release?

Fix export clause: https://github.com/dotcloud/docker/pull/2448

ok will do

keeb: who do i check with to make sure this is correct?

i will forward you the email

sent

cc jpetazzo can you make sure i copy/pasted correctly? :]

shykes: fyi, we're just waiting for you on gh#2433 ;)

Add SQLite dep to hack/PACKAGERS.md: https://github.com/dotcloud/docker/pull/2433

tianon: he is gone

wat!

so you may be waiting for a while

but that's important for the release D:

tianon: go merge it then

tianon: ah

stop

don't we need go 1.2rc2 ?

nope :)

go1.1 works with dynbinary

so we should clarify that

want that in that same PR, or merge that one and create a new one to update our Go dep language there?

I think that one's good as-is - gonna open a new one to clarify Go versions

ok

especially since you and michael already looked at that one and it's good :)

https://github.com/dotcloud/docker/pull/2426 yes it's normal in tty mode it's raw terminal between client and server you can't hijack your thing

[docker] tianon pushed 2 new commits to master: http://git.io/R3xNFA

docker/master b283900 Tianon Gravi: Add SQLite dep to hack/PACKAGERS.md and clean up a few other tiny inconsistencies

docker/master 05430c7 Tianon Gravi: Merge pull request #2433 from tianon/sqlite-dep...

same example without -t works

ok, thanks for clarifying :)

doesn't seem to be working for me without -t either...

I just did it

it looks like you've updated that PR since I compiled, though, so I'm rebuilding to be sure :)

press return in the shell to see the helloword

ah

thanks :)

shykes: Did you see my huge mail?

[docker] binaryphile opened pull request #2450: Allow backwards-compatible colon syntax for tags in 'commit' command (master...master) http://git.io/ESDCdQ

[docker] tianon opened pull request #2451: Clarify Go 1.2rc2 / Go 1.1.2 requirements in hack/PACKAGERS.md (master...clarify-go-requirement) http://git.io/pHBfzA

vieux, crosbymichael: ^ ^ (#2451)

hey there

hiyo

has anyone noticed the inconsitent syntax with the docker commit command?

please elaborate

if you put a colon instead of a space in front of the tag name, it creates the image, but it puts the colon inside the repo name instead of making a tag

that does not sound ideal.

every other command uses the colon syntax as far as i can tell

binaryphile: https://github.com/dotcloud/docker/issues/2294

vieux: thx

yeah, i think that issue captures it pretty well

there's definitely more to it than I thought. Was hoping it might be a simple fix. Looks like there's api-level changes involved as well

[docker] ewindisch opened pull request #2452: Support granular capabilities (master...2080-capabilities) http://git.io/b_ZrvA

tianon: why would the non-static binary use 1.1.2?

can use - the reason we had to switch to go1.2 was for static compilation of net without completely disabling CGO

so if we remove that requirement, go1.1.2 works again

me and shykes are still working on a good way to test that automatically via our make.sh stuff

(ie, to test multiple Go versions)

but wouldn't we want to be consistent?

regardless if it is required?

yes, but packagers can't be - we can't just arbitrarily package go1.2rc2 unfortunately

because it's not officially released

and for some distros, that's a deal breaker

I'm all for consistent

ok

but we're in kind of a catch-22 here :(

once Go 1.2 is officially released, I have no problem forcing it to be packaged properly - that's the proper duty of the distros :)