| davechen1y | poop, http://juju-ci.vapour.ws:8080/job/run-unit-tests-trusty-ppc64el/439/console | 00:17 |
|---|---|---|
| davechen1y | 504 | 00:17 |
| davechen1y | no | 00:18 |
| davechen1y | 404 | 00:18 |
| davechen1y | wtf | 00:18 |
| abentley | davechen1y: Not sure. But I think our last build for that is 458. | 00:20 |
| davechen1y | i know what the issue is anyway | 00:21 |
| davechen1y | will fix | 00:21 |
| waigani | wallyworld: so who should comment $$merge$$ ? | 00:22 |
| abentley | davechen1y: So your wtf is why don't we retain all the builds? Disk space. | 00:22 |
| wallyworld | waigani: the author of the pull request after getting a lgtm, just like in launchpas where the author of the mp sets approved | 00:22 |
| davechen1y | abentley: ok, fair enough | 00:23 |
| davechen1y | welcome to the cloud | 00:23 |
| waigani | wallyworld: thought so, just checking. I saw an LGTM and a $$merge$$ by the reviewer | 00:23 |
| wallyworld | waigani: np, sometimes the reviewer scan do that if the author had gone to bed or whatever and they want to get it landed | 00:24 |
| waigani | sure | 00:24 |
| wallyworld | i secretly wish we were stil on lp :-( | 00:24 |
| davechen1y | wallyworld: i don't think it is a secret | 00:25 |
| wallyworld | lol | 00:25 |
| waigani | hehe | 00:25 |
| wallyworld | you got me there | 00:25 |
| abentley | Certainly not now : -) | 00:25 |
| wallyworld | i just detest git so much compared to bzr | 00:26 |
| waigani | wallyworld: do we go here to see everything that needs to be reviewed: https://github.com/juju/juju/pulls | 00:26 |
| wallyworld | i think so yeah | 00:26 |
| waigani | just asking all the really obvious questions to get them out of the way :) | 00:27 |
| wallyworld | i'm still ramping up on github myself | 00:27 |
| davecheney | % echo $PWD | 00:41 |
| davecheney | /home/dfc/src/github.com/juju/juju/juju/osenv | 00:41 |
| davecheney | i'd like to present this for the justification _not_ to call the main repo 'juju' | 00:41 |
| perrito666 | wallyworld: I am surprised that you did not curse even once in the mail | 00:41 |
| davecheney | but it's too late for that now | 00:41 |
| perrito666 | davecheney: there where very good arguments agains | 00:41 |
| wallyworld | perrito666: i can curse here on irc :-) had to be polite in the email :-) | 00:42 |
| perrito666 | such as having clones like github.com/perrito666/core | 00:42 |
| davecheney | perrito666: meh, what's done is done | 00:42 |
| perrito666 | who would want to clone my core? :p | 00:42 |
| davecheney | perrito666: github.com/davecheney/testing | 00:42 |
| davecheney | not that descriptive either | 00:42 |
| wallyworld | davecheney: that issue was mentioned and people did suggest juju-core but the majority wanted juju/juju | 00:42 |
| perrito666 | davecheney: do you have a production davecheney too? :p | 00:42 |
| wallyworld | fwiw i wanted juju-core | 00:43 |
| davecheney | func (*importSuite) TestTemporaryDependencies(c *gc.C) { | 00:43 |
| davecheney | c.Assert(coretesting.FindJujuCoreImports(c, "github.com/juju/juju/juju/osenv"), | 00:43 |
| davecheney | gc.DeepEquals, []string{"utils"}) | 00:43 |
| perrito666 | we should have discussed this in person, over beer | 00:43 |
| davecheney | } | 00:43 |
| davecheney | what the shit is this supposed to be testing ?!? | 00:43 |
| wallyworld | that ony utils package is imported | 00:44 |
| davecheney | why ? | 00:44 |
| wallyworld | thumper wrote that stuff to ensure we were only importing sensible dependencies | 00:44 |
| wallyworld | to pick up layering violations | 00:44 |
| wallyworld | because we had several | 00:44 |
| waigani | why not change the team name? | 00:46 |
| davecheney | wallyworld: ok, this will need some fixing for gccgo | 00:46 |
| davecheney | you'll only hit that bug when /usr/bin/go is compiled by gccgo | 00:46 |
| wallyworld | waigani: i also asked that question | 00:46 |
| wallyworld | davecheney: why will that happen? | 00:47 |
| davecheney | wallyworld: under gccgo, the way we package it the path from the compiled depdency to it's source is not ../src | 00:48 |
| davecheney | as sinzui discovered | 00:48 |
| wallyworld | ah ok | 00:49 |
| wallyworld | thumper will have to fix it then :-) | 00:49 |
| * davecheney is having a look | 00:49 | |
| davecheney | thumper: is busy growing his flock | 00:50 |
| wallyworld | what does "growing his flock" mean? | 00:52 |
| lifeless | do you really want to know? | 00:53 |
| davecheney | crap, this test is going to be a bit tricky to fix | 01:00 |
| * davecheney goes to ponder it | 01:00 | |
| sinzui | wallyworld, I declare CI to be fit for juju testing from git. Two tests failed. voidspace thinks he has a fix for the local-deploy-precise-amd64 failure | 01:00 |
| wallyworld | great :-) | 01:00 |
| sinzui | maybe davecheney can explain the broken ppc64el unit tests | 01:00 |
| wallyworld | sinzui: do you have a pointer to failed tests saving me from looking? | 01:01 |
| sinzui | wallyworld, https://bugs.launchpad.net/juju-core/+bug/1325707 | 01:02 |
| wallyworld | oh goody, a bug | 01:02 |
| sinzui | I looked at the packages wondering if one got removed that provided src/pkg/bytes and all the other missing packages | 01:03 |
| wallyworld | looks like a relatively simple fix hopefully | 01:03 |
| sinzui | a simple fix for me is install a missing package | 01:04 |
| wallyworld | lifeless: well, i was scared about asking, for sure :-) | 01:04 |
| davecheney | sinzui: i know the problem | 01:09 |
| davecheney | it's a bug with the test helper | 01:09 |
| davecheney | the short, and not competely accurate explanation is, it's gc only | 01:09 |
| sinzui | excellent, gccgo manages its deps differently | 01:11 |
| davecheney | sinzui: no | 01:13 |
| davecheney | sinzui: in short, i'm fixing it | 01:14 |
| davecheney | i'm not going to explain it twice | 01:14 |
| davecheney | the commit message will be large enough | 01:14 |
| perrito666 | ok fine people, EOD, good night everyone | 01:15 |
| davecheney | https://github.com/juju/testing/pull/10 | 01:28 |
| davecheney | ^ part 1/2 of the testing failure | 01:28 |
| axw | wallyworld: hey. any githubby/landery things you'd like me to look at today? | 01:34 |
| wallyworld | axw: hi there, quick hangout? | 01:34 |
| axw | sure | 01:35 |
| wallyworld | i'll set one up | 01:35 |
| wallyworld | https://plus.google.com/hangouts/_/g3h6myvrnbm3pwvzj3dibguaaqa?hl=en | 01:35 |
| axw | wallyworld: "the party is over" | 01:36 |
| wallyworld | sigh | 01:36 |
| axw | :~( | 01:36 |
| wallyworld | i sent an invite also | 01:36 |
| axw | wallyworld davecheney: could you please take a look at https://codereview.appspot.com/101980044/ when you have some time | 01:55 |
| wallyworld | sure | 01:55 |
| davecheney | axw: sure | 01:58 |
| * thumper isn't growing his flock | 02:08 | |
| * thumper is getting punched in the head | 02:08 | |
| waigani | mgz: bzr diff -rancestor:co:trunk. I get bzr: ERROR: Not a branch | 02:08 |
| thumper | waigani: you arn't using co-located branches | 02:08 |
| thumper | waigani: I'll work it out and let you know if wallyworld doesn't first | 02:08 |
| waigani | thumper: sounds good to me :) | 02:08 |
| wallyworld | thumper: if you could do it that would be great | 02:09 |
| wallyworld | as i have co located branches | 02:09 |
| thumper | waigani: I need to do it for mine anyway | 02:09 |
| thumper | lifeless: o/ | 02:09 |
| waigani | cool | 02:09 |
| lifeless | thumper: o/ | 02:10 |
| thumper | wallyworld: are there instructions anywhere on how people should set up the git remotes? | 02:15 |
| thumper | wallyworld: personally I've added 'me' as a remote | 02:16 |
| thumper | and go 'git push me branch-name' | 02:16 |
| thumper | as origin is the juju team branch | 02:16 |
| thumper | wallyworld: I was talking with fwereade earlier today, and I think I have a way for us to have a test object factory like the old launchpad one... | 02:17 |
| thumper | wallyworld: at least one that works well enough | 02:17 |
| wallyworld | thumper: i did git remote add upstream https://github.com/juju/juju.git | 02:17 |
| wallyworld | for upstream | 02:18 |
| wallyworld | but i guess i should add 'me' too | 02:18 |
| thumper | wallyworld: and changed origin to be you? | 02:18 |
| wallyworld | not yet but i should | 02:18 |
| thumper | wallyworld: so what do you get if you go 'git remote -v'? | 02:18 |
| thumper | to me 'origin' is 'upstream' | 02:19 |
| thumper | but I guess each person has their mental model | 02:19 |
| wallyworld | [master]ian@wallyworld:~/juju/go/src/github.com/juju/juju$ git remote -v | 02:19 |
| wallyworld | origin https://github.com/wallyworld/juju (fetch) | 02:19 |
| wallyworld | origin https://github.com/wallyworld/juju (push) | 02:19 |
| wallyworld | upstream https://github.com/juju/juju.git (fetch) | 02:19 |
| wallyworld | upstream https://github.com/juju/juju.git (push) | 02:19 |
| wallyworld | thumper: +1 for better test infrastructure :-) | 02:20 |
| axw | wallyworld: can I get you to approve that goamz MP please? I am not a maintainer | 02:26 |
| wallyworld | sure | 02:26 |
| axw | davecheney: "git rebase -i master". I *think* that since it's been published, it becomes problematic (you'd have to force push and then lose GitHub comments) | 02:28 |
| thumper | wallyworld: here is a useful trick: git remote set-url --push origin no-pushing | 02:34 |
| thumper | wallyworld: or for you 'upstream' | 02:34 |
| wallyworld | what does that do? | 02:34 |
| thumper | wallyworld: so you don't accidentally push to the main juju repository | 02:34 |
| wallyworld | ah cool | 02:34 |
| wallyworld | we'll add these to the doc | 02:34 |
| thumper | $ git push | 02:34 |
| thumper | fatal: 'no-pushing' does not appear to be a git repository | 02:34 |
| thumper | fatal: The remote end hung up unexpectedly | 02:34 |
| axw | I think we should remove most people's commit access anyway | 02:35 |
| thumper | you can't remove the push url, but you can make it not work | 02:35 |
| wallyworld | we will lock it down also | 02:35 |
| thumper | I just don't trust myself not to make mistakes | 02:37 |
| wallyworld | yep. locking it down is next on martin's todo list | 02:38 |
| menn0 | thumper: isn't origin supposed to be your personal fork and upstream the central shared repo? | 02:40 |
| thumper | menn0: I don't know, is it? | 02:41 |
| thumper | I'm happy to move to a more accepted terminology | 02:41 |
| axw | thumper: yes it is | 02:41 |
| thumper | but in the absence of any information, I made it up :) | 02:41 |
| thumper | ok, can someone mention that too in the emails? | 02:41 |
| menn0 | if you fork on GH and clone that onto your machine, then origin will automagically be your personal repo | 02:41 |
| menn0 | here's what I've got: | 02:42 |
| menn0 | origingit@github.com:mjs/juju.git (fetch) | 02:42 |
| menn0 | origingit@github.com:mjs/juju.git (push) | 02:42 |
| menn0 | upstreamhttps://github.com/juju/juju.git (fetch) | 02:42 |
| menn0 | upstreamno-pushing (push) | 02:42 |
| axw | http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github | 02:42 |
| * thumper updates | 02:42 | |
| menn0 | and if you do this in your feature branches: git branch --set-upstream-to remotes/upstream/master | 02:43 |
| menn0 | then stuff like "git log @{u}.." and "git rebase -i @{u}" will work with your changes beyond upstream | 02:44 |
| menn0 | and this: git config branch.autosetupmerge always | 02:44 |
| menn0 | means you don't need to do it for every feature branch | 02:44 |
| menn0 | this all requires git 1.7.something | 02:44 |
| menn0 | ish | 02:44 |
| menn0 | but we're probably all running that | 02:44 |
| thumper | I don't get the @{u} thing | 02:46 |
| menn0 | it's short for @{upstream} and means "the rev that upstream is on" | 02:46 |
| thumper | what is the autosetupmerge do? | 02:46 |
| menn0 | avoids the need to do "git branch --set-upstream-to remotes/upstream/master" for each new branch you create | 02:47 |
| menn0 | in recent versions of git "upstream" means something special and there's support through various commands for it | 02:47 |
| menn0 | actually, I believe for rebase you can just do "git rebase -i" and it will use "upstream" if defined for the branch | 02:48 |
| thumper | ah... nice | 02:48 |
| thumper | hmm | 02:49 |
| thumper | I tried to do the git branch line | 02:49 |
| thumper | and it errored | 02:49 |
| thumper | error: the requested upstream branch 'remotes/upstream/master' does not exist | 02:50 |
| thumper | I started with "go get github.com/juju/juju" | 02:50 |
| thumper | then messed with the remotes | 02:50 |
| axw | wallyworld: is there a bot for goamz? | 02:50 |
| thumper | how do I recheckout my master branch as upstream/master ? | 02:50 |
| wallyworld | axw: i thought so | 02:50 |
| wallyworld | i'll check | 02:50 |
| axw | thumper: I think you want to do "git branch --set-upstream-to upstream/master master" | 02:51 |
| axw | assuming you haven't changed it | 02:52 |
| thumper | I think I need to fetch heads | 02:52 |
| axw | right, do a "git fetch upstream/master" first | 02:53 |
| thumper | got it now | 02:53 |
| thumper | axw: so if you don't specify remotes/ it assumes it? | 02:54 |
| axw | I don't know what the difference is :) | 02:54 |
| wallyworld | axw: bot doesn't do tarmac :-( if the tests pass for you, i guess we just push manually | 02:58 |
| axw | passes for me | 02:59 |
| axw | can you please submit? | 02:59 |
| wallyworld | sure | 03:00 |
| wallyworld | axw: done | 03:04 |
| axw | wallyworld: thanks :) | 03:04 |
| wallyworld | i forgot to update the commit message, oh well | 03:05 |
| thumper | heh | 03:06 |
| thumper | one of my imports has too many 'juju's | 03:06 |
| wallyworld | lol | 03:06 |
| thumper | waigani: :~/go/src/github.com/juju/juju$ (cd ~/go/src/launchpad.net/juju-core/ && bzr diff -r ancestor::parent) | patch -p0 --merge | 03:09 |
| thumper | waigani: so I did this from the juju branch | 03:10 |
| thumper | it assumes that the branc in juju-core does indeed have the parent branch set to trunk | 03:10 |
| thumper | I had three merge conflicts | 03:10 |
| thumper | all imports | 03:10 |
| thumper | hmm... | 03:13 |
| thumper | ick | 03:13 |
| thumper | minimumunits_test.go:21: | 03:13 |
| thumper | s.ConnSuite.SetUpTest(c) | 03:13 |
| thumper | export_test.go:115: | 03:13 |
| thumper | c.Assert(err, gc.IsNil) | 03:13 |
| thumper | ... value *errors.errorString = &errors.errorString{s:"cannot create log collection: local error: bad record MAC"} ("cannot create log collection: local error: bad record MAC") | 03:13 |
| thumper | intermittent failure | 03:13 |
| thumper | anyone know a way to do the equivalent of 'bzr clean-tree' ? | 04:01 |
| thumper | I have some untracked files created due to merge conflicts (I think) | 04:02 |
| waigani | thumper: sorry just saw your message | 04:02 |
| waigani | thumper: I get an error | 04:02 |
| waigani | patch unexpectedly ends in middle of line | 04:02 |
| waigani | patch: **** Only garbage was found in the patch input. | 04:02 |
| waigani | here's my diff: http://paste.ubuntu.com/7584825/ | 04:02 |
| thumper | waigani: look at the output of your diff by piping to less rather than patch | 04:02 |
| thumper | um... | 04:03 |
| thumper | yeah | 04:03 |
| thumper | you have colour there | 04:03 |
| waigani | thumper: I just piped my diff to pastebin | 04:03 |
| thumper | right | 04:03 |
| thumper | you have made diff give colour | 04:03 |
| thumper | patch can't handle that | 04:03 |
| waigani | I have? hmm don't remember doing that | 04:04 |
| jimmiebtlr__ | Believe there is a clean subcommand in git | 04:04 |
| thumper | jimmiebtlr__: ok, so I didn't need this? git status -s | grep "^??" | cut -d " " -f 2 | xargs rm | 04:08 |
| jimmiebtlr__ | no | 04:08 |
| thumper | yep, looks like git clean would do what I want :-) | 04:09 |
| thumper | waigani, menn0: https://github.com/juju/juju/pull/6 | 04:13 |
| menn0 | thumper: do you want us to redo our review comments or just LGTM it? | 04:14 |
| thumper | menn0: I addressed the review comments in the old review thingy | 04:14 |
| thumper | menn0: should be OK to lgtm it | 04:14 |
| menn0 | thumper: ok. I'll quickly check the old review and approve | 04:15 |
| thumper | sure | 04:15 |
| menn0 | thumper: done | 04:17 |
| menn0 | waigani: have you got a bzr alias for diff to cdiff ? | 04:20 |
| waigani | menn0: not that I know off | 04:20 |
| thumper | waigani: bzr alias | 04:20 |
| waigani | I just added a comment on thumper's branch. Do I want to "add a line note" or not? | 04:20 |
| thumper | waigani, wallyworld: now I have a question... | 04:21 |
| wallyworld | yes? | 04:21 |
| thumper | it seems to me that we want relatively clean commit logs | 04:21 |
| thumper | now I have one big commit | 04:21 |
| waigani | hey I do, menn0 yes you're right | 04:21 |
| thumper | and one review comment about changing one line | 04:21 |
| thumper | ideally I'd like to clean up the one line | 04:22 |
| thumper | bit it will then be in the commit history | 04:22 |
| thumper | and given how git handles logs differently | 04:22 |
| thumper | do we care? | 04:22 |
| thumper | or more importantly: | 04:22 |
| thumper | what is our process around this | 04:22 |
| thumper | because it will happen a lot | 04:22 |
| wallyworld | i think if the change you make relates to a review comment, perhaps it should stay in the logs? | 04:22 |
| menn0 | waigani: yeah, cdiff doesn't check to see if stdout is a terminal or a pipe and always emits color escapes regardless | 04:22 |
| thumper | wallyworld: more a "tidy up this line" nothing really log worthy | 04:22 |
| wallyworld | that was the original thinking anyway | 04:22 |
| wallyworld | i think perhaps it's a case of "do the right thing" | 04:23 |
| wallyworld | if just cleanup, then squash | 04:23 |
| thumper | wallyworld: how? | 04:23 |
| menn0 | even easier: amend | 04:23 |
| wallyworld | rebase -i ? | 04:23 |
| wallyworld | not sure | 04:23 |
| menn0 | fix the line | 04:23 |
| menn0 | then: git commit --amend | 04:23 |
| thumper | menn0: ta | 04:24 |
| * wallyworld makes a note to add that to doc | 04:24 | |
| menn0 | sorry, left out the "git add" | 04:24 |
| * wallyworld misses bzr already :-( | 04:24 | |
| menn0 | --amend just allows you to make changes to the last commit and/or edit the commit message | 04:24 |
| menn0 | useful when you forgot to include a file or realised you mistyped the commit message just as you hit enter | 04:25 |
| thumper | menn0: git commit -a --amend? | 04:25 |
| menn0 | that works too :) | 04:25 |
| thumper | menn0: however this branch is being reviewed... | 04:26 |
| thumper | menn0: so how does that work? | 04:26 |
| thumper | given that we are changing public history | 04:26 |
| menn0 | that branch only exists in your personal repo | 04:26 |
| menn0 | so I don't think it matters that much | 04:26 |
| menn0 | but i'm not sure what exactly will happen if you push again | 04:27 |
| * menn0 thinks thumper makes an excellent lab rat | 04:27 | |
| thumper | heh | 04:27 |
| menn0 | I think the "right thing" will probably happen but let's find out for sure | 04:27 |
| thumper | menn0: ok git master: how do I get a local diff vs upstream/master? | 04:28 |
| thumper | wallyworld: add that to the docs too | 04:28 |
| thumper | wallyworld: when he says it | 04:28 |
| * thumper waits | 04:28 | |
| * thumper waits impatiently | 04:28 | |
| menn0 | git fetch upstream | 04:28 |
| menn0 | then | 04:28 |
| * wallyworld taps fingers | 04:28 | |
| thumper | menn0: git status tells me I am up to date with upstream/master already | 04:29 |
| thumper | menn0: what is the difference between fetch and pull? | 04:29 |
| menn0 | git diff @{u}.. | 04:29 |
| menn0 | I think | 04:29 |
| thumper | and the two dots? | 04:29 |
| * menn0 is not a git master | 04:29 | |
| thumper | menn0: well that did something | 04:30 |
| menn0 | shorthand for a range | 04:30 |
| axw | thumper: "In its default mode, git pull is shorthand for git fetch followed by | 04:30 |
| axw | git merge FETCH_HEAD." | 04:30 |
| thumper | and it kinda looks like a diff | 04:30 |
| thumper | axw: ah... good to know | 04:30 |
| menn0 | <something>.. is the same as <something>..HEAD | 04:30 |
| jimmiebtlr__ | there is also git diff | 04:30 |
| axw | fetch brings down the commits, pull does that and merges into your working tree | 04:30 |
| * thumper likes having git capable folks to ask | 04:30 | |
| * menn0 thinks thumper didn't read what I wrote | 04:31 | |
| menn0 | git fetch | 04:31 |
| menn0 | then git diff | 04:31 |
| thumper | menn0: capable != master | 04:31 |
| thumper | menn0: but you are more capable than me | 04:31 |
| thumper | and master status is in the eye of the beholder :) | 04:31 |
| thumper | says the git pleb | 04:31 |
| menn0 | much of the stuff I've written about git today, I learned today! | 04:32 |
| menn0 | all the "upstream" stuff anyway | 04:32 |
| thumper | menn0: needed to --force the ammended commit | 04:37 |
| thumper | :) | 04:37 |
| menn0 | thumper: ok. I guess that's kinda expected. does the branch look right on GH? | 04:37 |
| thumper | the comments are handy too | 04:37 |
| thumper | the comments say "waigani commented on an outdated diff 12 minutes ago" with a "show outdated diff" link | 04:38 |
| * thumper nods | 04:39 | |
| thumper | looks ok | 04:39 |
| * thumper does the $$merge$$ thing | 04:39 | |
| thumper | I wonder if this'll work | 04:39 |
| waigani | man I'm so outdated ... | 04:40 |
| menn0 | thumper: the way GH handles updated diffs is nice, keeping track of previous versions and all that | 04:41 |
| thumper | yay, jujubot grabbed it | 04:41 |
| thumper | although I want a better picture than mgz | 04:41 |
| thumper | we should have a robot pic | 04:41 |
| menn0 | I was thinking the same | 04:41 |
| menn0 | although mgz is kinda robotic... | 04:41 |
| menn0 | in a coding machine kind of way | 04:42 |
| waigani | thumper: you might like: git config merge.conflictstyle diff3 | 04:48 |
| waigani | thumper: it'll give you the <<<<<<< ======= inline markers for conflicts | 04:49 |
| waigani | menn0: what is your preferred way of handling conflicts? | 04:51 |
| menn0 | I just use the default but diff3 is sometimes nice too | 04:52 |
| menn0 | some people like to get git to invoke an external merge tool like kdiff3 or meld but I usually prefer to handle it in my editor unless it's really hair | 04:53 |
| menn0 | hairy even | 04:53 |
| menn0 | the merge.tool config option lets you set one of the many supported tools to invoke in the event of merge conflicts | 04:54 |
| jcw4 | I just issued a pull request for a very small change in the README.md... | 05:20 |
| === menn0 is now known as menno0-afk | ||
| jcw4 | In it I replaced a recommendation to do bzr pull with a recommendation to do 'git pull --rebase' to pull in upstream updates | 05:20 |
| jcw4 | I haven't heard any discussion about git pull --rebase when pulling in from master but I don't think that will be controversial | 05:21 |
| jcw4 | (presumably no-one will be making commits in their local master branch, so it should be moot) | 05:22 |
| jam | sinzui: given that the conversion to git was lossy (something all non-mainline revs were stripped), we want to not just override our existing lp:juju-core branch with a git import. I suppose we could just move it off to the side? | 05:23 |
| jcw4 | fwereade: I guess you're the pool 1 reviewer :-D - https://github.com/juju/juju/pull/7 | 05:26 |
| jcw4 | axw: thanks | 05:40 |
| axw | no worries | 05:40 |
| axw | wallyworld: another one sorry, https://code.launchpad.net/~axwalk/goamz/ec2test-runinstances-availzone/+merge/221982 | 05:47 |
| wallyworld | sure | 05:48 |
| wallyworld | axw: so it's only the one file changed? no tests? | 05:52 |
| axw | wallyworld: right. there were no tests. I could add one, but it seemed a bit against the theme of the existing tests. I'm adding one in juju (that's how I found it) | 05:53 |
| wallyworld | oh ok, ta | 05:53 |
| wallyworld | axw: done | 05:57 |
| axw | wallyworld: thanks | 05:58 |
| axw | simple review anyone? https://github.com/juju/juju/pull/5 | 06:01 |
| jam | axw: do you know what the "Comment": "null-185" stuff is ? | 06:06 |
| jam | axw: also, there appears to be a bunch of stuff about Godeps/_workspace that we probably don't actually want | 06:07 |
| jam | I don't *think* we want to end up with double copies of all dependencies, do we? | 06:07 |
| jam | axw: at least it looks like godep wants to take over your GOPATH and auto-insert Godeps/_workspace as part of GOPATH, instead of working "as normal" | 06:09 |
| jam | so I *think* we actually need more discussion about how Godep is actually going to work with our system, since it isn't just a drop-in replacement | 06:09 |
| axw | jam: sorry walked away for a bit. where's the Comment? | 06:17 |
| jam | axw: https://github.com/juju/juju/pull/5/files#diff-681659ab9abb4b4883e78e8aaa980dbaR10 | 06:17 |
| axw | jam: ah, no idea. also, I misunderstood the workspace. I think you're right, let's hold off for now | 06:21 |
| jam | axw: what is the equivalent of marking an MP as WiP ? | 06:22 |
| axw | jam: there are no state for PRs. you could add a label, or just a comment | 06:23 |
| jam | axw: is there a "rejected" or "closed" so that other people don't try to review it? | 06:23 |
| axw | nope | 06:24 |
| jam | axw: yep, you can "Close" link | 06:24 |
| jam | when commenting | 06:24 |
| axw | sorry | 06:24 |
| jam | and it goes to Closed without merging. | 06:24 |
| jam | So you don't have quite the "please resubmit this" niceness, but you can put that in the comment. | 06:25 |
| axw | that seems like a reasonable equivalent | 06:25 |
| axw | it'll disappear off the active PRs until that person reopens it | 06:25 |
| jam | yeah | 06:25 |
| dimitern | morning all | 06:36 |
| jam | morning dimitern | 06:54 |
| voidspace | dammit, so my change didn't fix trunk - but it looks like that's only because it isn't waiting long enough for status to return successfully | 08:09 |
| voidspace | morning all | 08:09 |
| axw | morning | 08:14 |
| axw | sinzui: any particular reason why CI is using m1.xlarge, and not m3.xlarge? m3 is faster and cheaper. AFAICT, no downside | 08:21 |
| axw | mgz: ^^ is it worthwhile me changing in the build script, or do you think you'll have the HP instance plugged in soon? | 08:23 |
| axw | (changing in the build script for the lander, only) | 08:24 |
| === vladk|offline is now known as vladk | ||
| dimitern | jam, perrito666, others? I migrated my networks constraint branch to github, already approved on rietveld - just a final look? | 09:25 |
| dimitern | https://github.com/juju/juju/pull/9 | 09:25 |
| jam | looking | 09:25 |
| jam | dimitern: lgtm | 09:29 |
| dimitern | jam, thanks! | 09:29 |
| davecheney | https://github.com/juju/juju/pull/10 | 09:30 |
| davecheney | i dunno if we're using godeps anymore, but this fixes 1325707 | 09:30 |
| davecheney | #1325707 | 09:30 |
| davecheney | no _mup_ ? | 09:30 |
| dimitern | bug 1325707 | 09:31 |
| dimitern | yep it's gone | 09:31 |
| dimitern | davecheney, LGTM | 09:31 |
| dimitern | davecheney, yes, we're still using godeps | 09:31 |
| * dimitern really misses bzr pipelines in git | 09:32 | |
| davecheney | dimitern: ta | 09:34 |
| davecheney | so $$merge$$ will submit this | 09:35 |
| natefinch | morning all | 09:35 |
| davecheney | will it also run a jenkins build that I can see if 1325707 is fixed ? | 09:35 |
| natefinch | davecheney: you need to go to https://github.com/orgs/juju/members and set yourself public | 09:35 |
| davecheney | natefinch: ta | 09:35 |
| davecheney | done | 09:35 |
| davecheney | do I need to recomment ? | 09:36 |
| natefinch | as does dimitern and fwereade and vladk and rogpeppe and sinzui and voidspace and some people not online | 09:36 |
| dimitern | natefinch, cheers, just did | 09:36 |
| natefinch | :) | 09:37 |
| natefinch | davecheney: no idea | 09:37 |
| natefinch | davecheney: probably can't hurt | 09:37 |
| dimitern | natefinch, no need - "Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju" | 09:37 |
| dimitern | and i haven't recommented | 09:37 |
| natefinch | cool | 09:37 |
| davecheney | whee! | 09:38 |
| dimitern | it's sooo much nicer to see the progress of the merge | 09:38 |
| natefinch | yep | 09:39 |
| davecheney | poop, timed out | 09:39 |
| jam | dimitern: it is, though having it take 4x longer is a bit of a bad tradeoff | 09:39 |
| davecheney | does it really have to download every single dependency every time | 09:40 |
| davecheney | that is going to make the build super fragile | 09:40 |
| davecheney | espeically when there are redirectors involed | 09:40 |
| jam | davecheney: it bootstraps a brand new image to run the tests on everytime | 09:40 |
| jam | they could potentially seed it | 09:40 |
| dimitern | jam, yeah, I think some initial steps can be optimized | 09:41 |
| natefinch | so, why does the new CI system run on different computers than the old CI system? | 09:41 |
| natefinch | why can't we just use the same ones, if they worked better? | 09:42 |
| jam | natefinch: a different group of people set it up, and it uses different infrastructure (run by Jenkins, because Tarmac can't run against Github) | 09:42 |
| natefinch | jam: oh, right, this is the landing bot not CI per se... right | 09:42 |
| jam | natefinch: I *think* the idea was to enable us to get to a point where we could actually run several test suites in parallel against multiple new machines | 09:42 |
| jam | natefinch: well, the landing bot is now running like CI | 09:42 |
| natefinch | jam: right | 09:42 |
| jam | rather than running as a dedicated landing machine. | 09:43 |
| jam | natefinch: anyway, I think they might have been trying to make it so that gccgo and golang go would run in parallel, and maybe run multiple arch's | 09:43 |
| jam | natefinch: personally, the decrease in cycle time (how quickly can we land code) is a pretty major thing, which I've been bringing up as they wanted to increase what we do pre-commit. But others may not see the same. | 09:44 |
| jam | 15min was a bit long already | 09:44 |
| davecheney | go build github.com/juju/juju/... | 09:45 |
| davecheney | + export JUJU_NOTEST_MONGOJS=1 | 09:45 |
| davecheney | + JUJU_NOTEST_MONGOJS=1 | 09:45 |
| davecheney | + export GOMAXPROCS=1 | 09:45 |
| davecheney | + GOMAXPROCS=1 | 09:45 |
| davecheney | ^ who did this | 09:45 |
| davecheney | it's not wrong | 09:45 |
| davecheney | but not right either | 09:45 |
| jam | I *think* wallyworld et al are trying to get the test suite to be stable enough to run in parallel. While we can't run any given package test in parallel (because lots of tests mutate global state and then set it back again) | 09:45 |
| davecheney | the correct line occurs just after it | 09:45 |
| davecheney | go test -p 1 ./... | 09:45 |
| jam | I'm really surprised we're running the test suite with JUJU_NOTEST_MONGOJS=1 | 09:46 |
| jam | did we lose running on Precise, too ? | 09:46 |
| davecheney | that is needed when using juju mongodb package | 09:46 |
| jam | davecheney: yes, but we should be using mongodb-server on Precise, and we should be running the test suite on precise because if it is going to break *somewhere* it would be there. | 09:51 |
| jam | that, and it isn't actually needed anymore as if the test suite notices it is using juju-mongodb it sets it automatically | 09:52 |
| voidspace | yay, after updating filters for github I'm down to 34 emails in my inbox instead of 151 | 09:54 |
| axw | davecheney: indeed, GOMAXPROCS shouldn't be there. I'll take it out | 09:55 |
| axw | jam: I think it's trusty atm. mgz will be looking at changing us from an ephemeral to a nailed-up instance (maybe with start/stop by jenkins? not sure). should be simple to go back to precise then | 09:56 |
| axw | as for JUJU_NOTEST_MONGOJS ... not sure why that's in there | 09:57 |
| axw | possibly cargo culted | 09:57 |
| voidspace | natefinch: hello nate, you're on early today | 09:59 |
| natefinch | voidspace: I'm usually up by now, just often hiding :) | 10:00 |
| voidspace | natefinch: heh, sensible | 10:00 |
| voidspace | I've just "gone public" | 10:00 |
| voidspace | at least as far as the juju-team goes | 10:00 |
| voidspace | natefinch: soooo... the commit yesterday *didn't* fix the build | 10:00 |
| voidspace | natefinch: *but* | 10:01 |
| voidspace | natefinch: I think that's mostly because of a mistake on my part | 10:01 |
| natefinch | ok | 10:01 |
| * natefinch refrains from smashing his forehead on his keyboard for now | 10:01 | |
| voidspace | natefinch: when I switched from waiting for CurrentStatus instead of CurrentConfig I left it at only waiting 5 seconds | 10:01 |
| voidspace | but we know that status can take longer than that, I meant to increase the time | 10:01 |
| natefinch | right, which we know might not be long enough | 10:01 |
| voidspace | the *good* news is that the error changed | 10:01 |
| voidspace | instead of "Closed explicitly" it looks like the Refresh worked and we now get a sensible error message | 10:02 |
| voidspace | I'll go copy & paste in a second, but now it basically says "initiating, be ready shortly" | 10:02 |
| voidspace | so really it's good news | 10:02 |
| voidspace | wrapped up as bad news | 10:02 |
| voidspace | 2014-06-04 09:23:45 WARNING juju.replicaset replicaset.go:77 Initiate: fetching replicaset status failed: cannot get replica set status: Received replSetInitiate - should come online shortly. | 10:03 |
| natefinch | that does sound good | 10:04 |
| voidspace | natefinch: so my bad, but I'm hopeful that *one last attempt* really should solve the problem :-) | 10:04 |
| natefinch | That also sounds like an error we should handle explicitly in that code | 10:04 |
| voidspace | natefinch: instead of warning? | 10:04 |
| voidspace | we have to do a string comparison unfortunately | 10:04 |
| natefinch | I know that blows, but if there's an error that we actually understand and can handle programmatically... we should do so | 10:05 |
| voidspace | ok | 10:05 |
| voidspace | we do that for unreachable members in the same block of code, so it's straightforward enough | 10:05 |
| voidspace | new mp coming in shortly when I straighten out my git workflow | 10:05 |
| voidspace | heh, pr instead of mp I guess | 10:06 |
| voidspace | need to straighten my terminology too | 10:06 |
| voidspace | natefinch: on another topic, did you get an email from me this morning? | 10:06 |
| natefinch | voidspace: oooh, keynote, huh? awesome! :) | 10:08 |
| voidspace | natefinch: yeah, should be good | 10:08 |
| voidspace | natefinch: I'm going to work with bloodearnest on a good demo and do a practise run at PyCon UK | 10:08 |
| jam | mgz: wallyworld: another question on the bot. I believe that I see it does proper "always generate a merge even when you could Fast Forward", I just wanted to check if that was really tue. | 10:09 |
| jam | true | 10:09 |
| natefinch | voidspace: cool cool | 10:09 |
| jam | voidspace: well, CL from Reitveld, even | 10:09 |
| voidspace | jam: has lbox been updated for git? | 10:10 |
| * voidspace needs to read the updated CONTRIBUTING doc | 10:10 | |
| jam | voidspace: we don't use lbox anymore, AFAICT | 10:10 |
| voidspace | ok | 10:10 |
| jam | voidspace: you push up your branch, and do a PR against master | 10:10 |
| jam | no more reitveld | 10:10 |
| voidspace | I won't miss it terribly | 10:10 |
| voidspace | jam: right, I've already done the PR dance once | 10:11 |
| voidspace | for a one line change... | 10:11 |
| voidspace | but I think I managed to commit to the wrong branch in my github fork - so I need to delete and start again (well I probably don't *need* to, but it's the path of least resistance at the moment) | 10:11 |
| natefinch | mgz: do we have something running the go fmt precheck at least? | 10:12 |
| axw | natefinch: yes, we do | 10:12 |
| natefinch | axw: ok, good. all is right with the world. | 10:12 |
| axw | at least we did before yesterday... I should check it got put back in | 10:12 |
| axw | natefinch: yep. the pre-push script in juju/scripts gets run by the lander | 10:13 |
| * axw is sad that he can't link branches and bugs anymore | 10:15 | |
| axw | now I have to remember things | 10:15 |
| natefinch | you can post a comment with a link to the bug, right? | 10:16 |
| jam | natefinch: you can set up a pre-push hook to the check script, but it means everytime you want to push out your local changes it will block for 30s | 10:16 |
| axw | yes, I am doing that. I'll need to also link from the bug back to the PR/commit tho | 10:16 |
| axw | kind've a drag | 10:17 |
| jam | I would hope they followed tarmac bot's goal of "just run go fmt ./..., because if we can automatically fix it, no reason to block on it" | 10:17 |
| jam | propose time != push time is definitely != commit time. | 10:17 |
| natefinch | jam: that's a good point... as long as go fmt doesn't error out, just run it | 10:17 |
| jam | natefinch: yeah, and if it *does* then you have bad code that needs to abort anyway | 10:17 |
| axw | sounds like a good thing to do. I just stuck the script in there so we had *something*. | 10:18 |
| jam | axw: I like that the check script does stuff like go vet, etc. | 10:19 |
| jam | But I'd rather do the "takes a while" checks only when I actually am ready to publish | 10:19 |
| jam | because I like to commit a lot, push a couple of times a day, and propose when its ready | 10:19 |
| axw | jam: it is possible to not run the hooks | 10:19 |
| * axw rummages around for the command | 10:19 | |
| axw | --no-verify | 10:19 |
| jam | axw: well, having to type "git push --no-verify" every time is a bit wonky | 10:20 |
| jam | I could invert the default and then have to run "git push --verify" | 10:20 |
| axw | you could have an environment variable or something, and an alias that sets that to RUN_SLOW_THINGS=1 before "git push" | 10:21 |
| dimitern | you can do git config --global alias.push = push --no-verify | 10:21 |
| axw | ah | 10:21 |
| dimitern | that was one of the very first thing i did - migrating some of my bzr aliases into ~/.gitconfig | 10:22 |
| dimitern | the other thing i'm trying now is Stacked Git, to see how well it works as a bzr pipelines replacement | 10:22 |
| jam | vladk: dimitern: standup ? | 10:45 |
| dimitern | jam, brt | 10:46 |
| jam | dimitern: I think it is primarily about assembling patches, which doesn't actually assemble branches | 10:46 |
| axw | jam: just had another look at godep, and "godep restore" does update the branches in their usual $GOPATH location | 10:52 |
| axw | jam: not really sure what the workspace is for... | 10:52 |
| jam | axw: I'm pretty sure that "godep go test" sets GOPATH to Godep/_workspace | 10:53 |
| axw | yes it does | 10:53 |
| axw | so we'd probably not want to do that at all, but rather just "godep restore" && "go test" | 10:53 |
| natefinch | yeah, I think you can run it exactly like godeps | 10:53 |
| natefinch | godep restore is the same as our godeps -u depedencies.tsv | 10:54 |
| natefinch | I believe... I haven't tried it out yet | 10:54 |
| davecheney | natefinch: i believe that is true | 10:55 |
| jam | natefinch: well it fundamentally wants to copy everything into Godeps/_workspace | 10:55 |
| jam | which means while it might approximate it, it still does its own stuff in a different way | 10:55 |
| davecheney | jam: yes, however it will collaps imports when it finds one of those deps also uses godeps | 10:56 |
| davecheney | this will mean that CI will have less to do to construct an environment to test | 10:56 |
| davecheney | and will not depend on external sites | 10:56 |
| davecheney | this will also make life easier for sinzui as the current build-release-tar.bash script can be simplified/removed | 10:56 |
| jam | davecheney: except we aren't versioning those deps | 11:00 |
| jam | so all the things you're saying still aren't true | 11:00 |
| jam | anyway, maybe we do want to version them, but if that is true, then clearly we actually need to discuss how we need to change to use it. | 11:01 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| voidspace | natefinch: https://github.com/juju/juju/pull/12 | 11:12 |
| davecheney | jam: i don't know about versioning | 11:12 |
| davecheney | that sounds like releases and build numbers and stuff | 11:12 |
| davecheney | which is orthogonal to the problem I am intersted in, reliable, preproducable builds | 11:12 |
| natefinch | he means vendor | 11:12 |
| natefinch | I think | 11:13 |
| davecheney | natefinch: yes, reproducable builds via vendoring | 11:14 |
| jam | natefinch: I mean "commit it to our tree" which yeah, vendoring is sort of it, though even vendoring could be "github.com/juju/OTHERPACKAGE", which is still different from having it inside your tree committed with the other files. | 11:14 |
| jam | If we want to vendor, I'm not strictly against it, but it should be decided "we want to vendor" not wedged in because we thought we should use a different godep tool. | 11:15 |
| natefinch | absolutely | 11:15 |
| natefinch | I'm not sure I want to vendor btw | 11:15 |
| natefinch | actually pretty sure I don't | 11:16 |
| tasdomas | hi | 11:16 |
| tasdomas | when running `go test -gocheck.vv -gocheck.f=LifeSuite ./...` in /state, I see these log entries: | 11:17 |
| tasdomas | [LOG] 36.85478 DEBUG juju.testing tls.Dial(127.0.0.1:52204) failed with dial tcp 127.0.0.1:52204: connection refused | 11:17 |
| tasdomas | [LOG] 36.85478 DEBUG juju.testing tls.Dial(127.0.0.1:52204) failed with dial tcp 127.0.0.1:52204: connection refused | 11:17 |
| jam | natefinch: well we've talked about it, and we don't do it *yet*, so we've generally decided not to so far | 11:17 |
| tasdomas | the tests pass, but are these log entries safe to ignore? | 11:17 |
| davecheney | tasdomas: does the warning fire when you don't use -gocheck.f ? | 11:18 |
| tasdomas | davecheney, yes, for every test suite that's being set up | 11:19 |
| dimitern | jam, fwereade, natefinch, finalizing networks constraints - https://github.com/juju/juju/pull/13 PTAL | 11:19 |
| natefinch | there's a lot of crap in the logs even when things work correctly, unfortunately. these are debug messages, so probably safe tp ignore | 11:22 |
| natefinch | tasdomas: ^^ | 11:22 |
| natefinch | voidspace: see my comment on your PR | 11:22 |
| voidspace | natefinch: hah, you spotted my deliberate error... | 11:22 |
| voidspace | natefinch: fixing | 11:23 |
| natefinch | heh | 11:23 |
| natefinch | just making sure I'm paying attention? :) | 11:23 |
| === vladk is now known as vladk|offline | ||
| voidspace | natefinch: fixed | 11:24 |
| jam | natefinch: tasdomas: I believe it is reasonably expected that while starting up Mongo it takes a try or two to get connected. without ".vv" you shouldn't see them. And hopefully we have a "connected to" if we are giving the "connection refused" messages. | 11:25 |
| voidspace | natefinch: I'm assuming 15 seconds will be enough... (it really should be) | 11:26 |
| voidspace | we can always bump up maxInitiateStatusAttempts if we need to | 11:26 |
| natefinch | yep | 11:26 |
| voidspace | 15 seconds to fail is already a bit of a bump though | 11:26 |
| voidspace | 15 *extra* seconds to fail | 11:26 |
| TheMue | *: Have to leave home for about 1h, see you all later | 11:27 |
| natefinch | voidspace: but failure should be rare | 11:29 |
| voidspace | natefinch: yep, we didn't see this failure before - so it should be very rare | 11:30 |
| * perrito666 is informed by github that he has been subscribed to 14 repositories... let the mailing avalanche begin | 11:38 | |
| natefinch | haha | 11:38 |
| mgz | jam: er, I'm an idiot, can you add me back to the owners group on github? | 11:38 |
| natefinch | hahaha | 11:39 |
| mgz | I need to remove myself last... | 11:39 |
| mgz | perrito666: sorry, spam from me | 11:39 |
| dimitern | sorry to be a pest, but a gentle reminder ... jam, fwereade, natefinch, i'd appreciate a review on the following (finalizing networks constraints) - https://github.com/juju/juju/pull/13 | 11:39 |
| natefinch | should we turn off issues if we want bugs in launchpad? | 11:39 |
| mgz | trying to make it so we can't land without the bot actually testing the code | 11:40 |
| mgz | natefinch: probably | 11:40 |
| mgz | natefinch: can you re-owner me? | 11:40 |
| jam | mgz: no | 11:40 |
| mgz | ;_; | 11:41 |
| jam | mgz: I find it funny that your real account (bz2) doesn't have your picture, but your fake one (jujubot) does | 11:41 |
| mgz | yeah, I shall be fixing that | 11:41 |
| mgz | I confused github with an email account dance | 11:42 |
| jam | mgz: you are now an owner again | 11:42 |
| natefinch | where's the ui for that jam? | 11:42 |
| natefinch | I couldn't find it | 11:43 |
| jam | mgz: I take it the idea is to filter down the list of owners, and then just have the bot controlling the official reop ? | 11:43 |
| jam | natefinch: github.com/juju, click on Members, click on Teams, click on Owners, "add users to team" edit box | 11:43 |
| mgz | jam: yup | 11:43 |
| jam | looks like you can skip the "click on Members" and go straight to teams | 11:43 |
| mgz | I'm going to leave team leads as owners and see how that works out | 11:44 |
| natefinch | ug, ok, I was looking in the list of members not teams | 11:44 |
| jam | natefinch: so was I | 11:44 |
| mgz | it's a bit more annoying for everyone but should cut out some accidents | 11:44 |
| jam | mgz: given I set up lp:juju-core that way, I think you can feel where I fall in that :) | 11:44 |
| jam | the only question is whether it would block us commenting on PRs | 11:44 |
| natefinch | jam I mean, I didn't know owners was a team and not a role or something | 11:44 |
| jam | natefinch: sure | 11:44 |
| mgz | okay, *now* I remove myself :) | 11:45 |
| jam | natefinch: I certainly thought it was just a role that I could change | 11:45 |
| jam | given that the members list shows "members" and "owners" directly | 11:45 |
| jam | but I don't think it would show "hackers" | 11:45 |
| natefinch | exactly | 11:45 |
| jam | so it *is* just a team, but it is a github special team | 11:45 |
| natefinch | yeah | 11:45 |
| mgz | yeah, and I can't remove it's access to push a branch, so we all need de-ownering | 11:46 |
| mgz | okay, done | 11:46 |
| jam | mgz: so is there any chance to do the same "sudo" trick that we had on LP? | 11:46 |
| mgz | teamlead plz do this for me | 11:46 |
| jam | I know tim and myself would like to not fuck stuff up by accident, only when we really need to | 11:46 |
| mgz | it's not nearly as good | 11:46 |
| jam | mgz: I'm more concerned about one of the teamleads accidentally leaving github.com/juju/juju as origin and doing "git push" | 11:47 |
| mgz | well, I could leave the bot as the only owner, but actually I don't like that as much | 11:47 |
| jam | mgz: well we need owners to do membership status, right ? | 11:47 |
| mgz | jam: you'll have to be better than the rest of us and not make mistakes :) | 11:47 |
| mgz | right, you have to be owners really | 11:48 |
| jam | mgz: and you can't restrict your own rights... :( | 11:48 |
| natefinch | responsibility? I didn't sign up for this | 11:48 |
| mgz | or it's painful to add people/change settings/create repos | 11:48 |
| jam | natefinch: umm... I think you did :) | 11:48 |
| natefinch | oh, right :) | 11:48 |
| jam | natefinch: but there is a difference between helping you enforce your own responsibility by intentionally creating boundaries | 11:49 |
| mgz | hm, I still have a big buttom that says merge pull request | 11:49 |
| jam | I'm a big believer in "make it hard to do it wrong" | 11:49 |
| natefinch | jam: me too | 11:49 |
| jam | mgz: "hackers have write access" | 11:49 |
| jam | should I be removing that / | 11:49 |
| jam | ? | 11:49 |
| jam | This team will be able to read its repositories, as well as push to them. | 11:50 |
| mgz | nope | 11:50 |
| jam | vs Admin Access: This team will be able to push/pull to its repositories, as well as add other collaborators to them. | 11:50 |
| mgz | we don't make hackers a team on juju/juju | 11:50 |
| jam | vs This team will be able to view and clone its repositories. | 11:50 |
| mgz | we need it still for juju/testing say | 11:50 |
| mgz | till we move that to the bot, then we can remove the team from that branch | 11:50 |
| jam | mgz: https://github.com/orgs/juju/teams/hackers says "juju/juju" | 11:51 |
| jam | should I be removing *that* ? | 11:51 |
| mgz | can you doulbe check, but github.com/juju/juju/settings/collaboration should be owners only | 11:51 |
| mgz | I may have been a bit to automatic with the adding | 11:51 |
| jam | mgz: hackers is listed as a team | 11:51 |
| mgz | okay, revoke there | 11:52 |
| jam | mgz: and it doesn't let me set perms on team there | 11:52 |
| mgz | just revoke | 11:52 |
| jam | mgz: it seems there isn't an many-to-many relationship that we want | 11:52 |
| jam | "hackers" should have X access on Y project | 11:52 |
| mgz | I may need a bots team, which will be on those branches | 11:52 |
| jam | roveked | 11:52 |
| jam | revoked | 11:52 |
| mgz | if fact, I think I'll do that just in case | 11:52 |
| mgz | oh, poo | 11:53 |
| mgz | jam: can you reowner me for now... I'll revoke myself later | 11:53 |
| jam | mgz: I keep telling you, that's not gonna happen | 11:53 |
| mgz | otherwise I'll keep having to bug you when I screw up >_< | 11:53 |
| jam | mgz: ownered | 11:53 |
| mgz | ta | 11:53 |
| jam | mgz: did you see your "merge this" button go away, at least? | 11:54 |
| mgz | ah, let me check via another cunning method | 11:54 |
| jam | a second account? | 11:54 |
| mgz | yes, it does | 11:54 |
| mgz | the bot is not yet granted on most branches | 11:54 |
| jam | mgz: I don't actually see the "jujubot" account | 11:55 |
| jam | mgz: Is it a full fledged github account, or is it a 'something that has my credentials' account? | 11:56 |
| mgz | github.com/jujubot | 11:56 |
| jam | ah, there it showed up | 11:56 |
| voidspace | natefinch: should I add the $$merge$$ magic comment? | 11:57 |
| mgz | okay, this is looking good now | 11:57 |
| perrito666 | mm, there seems to be no doc for HA | 11:58 |
| natefinch | voidspace: yep, after the LGTM, you can do the $$merge$$ ... basically the same as before where you'd set the commit message and mark it as approved | 11:59 |
| voidspace | natefinch: yeah, done - thanks | 12:00 |
| voidspace | perrito666: I believe we have a card for that | 12:00 |
| perrito666 | voidspace: I am working on it, but as the card said "update HA docs" I assumed there was something to update :p | 12:00 |
| voidspace | hah | 12:00 |
| voidspace | why would you assume that? :-D | 12:01 |
| perrito666 | I am a hopelessly naive guy | 12:01 |
| natefinch | perrito666: I'll change it to upsert ;) | 12:02 |
| voidspace | Looks like that branch is building. Should know whether or not the build is fixed in about an hour or so. | 12:05 |
| voidspace | In the meantime | 12:06 |
| * voidspace lunches | 12:06 | |
| === vladk|offline is now known as vladk | ||
| jam | dimitern: I do have it open for review | 12:18 |
| dimitern | jam, thanks | 12:20 |
| === psivaa is now known as psivaa-lunch | ||
| jam | lifeless: so I tried just doing "dd" of the ubuntu.iso image. and it comes out with a filesystem that is: /dev/sdg1 * 64 1986559 993248 17 Hidden HPFS/NTFS | 12:22 |
| jam | which does have the "boot" flag set | 12:22 |
| jam | but my old machine doesn't recognize it as actually being bootable. | 12:22 |
| jam | which is why http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-ubuntu has you use startup disk creator | 12:22 |
| natefinch | startup disk creator used to 100% reliably fail last time I tried it (about 6 months ago) | 12:23 |
| natefinch | which is why I always used dd | 12:23 |
| natefinch | which 100% reliably worked | 12:24 |
| jam | natefinch: interesting. I think it works because of a newer Bios than my circa 2003 machine | 12:24 |
| jam | natefinch: so when I first tried, it kept failing, but that was because you have to create the partition and boot flag, etc, manually, and it just copies what you need onto the disk | 12:25 |
| jam | well, usb stick | 12:25 |
| jam | it doesn't seem capable of handling no media/bad filesystems | 12:25 |
| natefinch | startup disk creator may make a better image... but I couldn't ever get it to actually finish creating anything, so never got to try what it output | 12:25 |
| perrito666 | jam: I agree, dd should work just fine | 12:26 |
| natefinch | jam: for me, dd of the image onto the usb stick worked fine as-is | 12:26 |
| jam | perrito666: I can absolutely confirm it does not :) | 12:27 |
| jam | as in, I just tried it | 12:27 |
| jam | and USB doesn't show up as bootable | 12:27 |
| natefinch | jam: but I was putting it into a new computer, so maybe your old one needs something more specifically set up | 12:27 |
| perrito666 | jam: the machine I am chatting with now was installed by using a dd usb | 12:27 |
| perrito666 | try unetbootin | 12:28 |
| natefinch | perrito666: his machine is oooooold. So, who knows what people were doing with USB bootable disks in 2003 | 12:28 |
| jam | perrito666: sure, I bet it does work (sometimes), I can just confirm that it doesn't work here | 12:28 |
| perrito666 | try a cd :p | 12:28 |
| natefinch | I'm honestly surprised a 2003 machine even has that capability | 12:28 |
| perrito666 | natefinch: that capability is quite old, but before was not mentioned as "boot from usb" but as "hey this seems to be a drive, boot from it?" | 12:29 |
| jam | perrito666: well I could, but I disconnected all the CDs in this thing. I could get there eventually, but fdisk a fat32 partition seems to be workable | 12:29 |
| jam | note there's stuff like "what is the byte offset of the first partition" | 12:30 |
| wwitzel3 | 2003 .. probably has multiple LPT ports | 12:30 |
| jam | and what is the master partition table | 12:30 |
| perrito666 | :| | 12:30 |
| jam | (GPT doesn't work here) | 12:30 |
| jam | wwitzel3: I only have 1 LPT, but I have 2 COM ports | 12:30 |
| perrito666 | jam: unebootin wont create something bootable? | 12:30 |
| jam | I haven't tried unetbootin | 12:31 |
| jam | I'm just using upstream ISO/Startup disk creator. | 12:32 |
| perrito666 | jam: do you have network and floppy? if so you can create a debian net install disk, install, change the repos and upgrade, I think that ... lets say works | 12:32 |
| jam | perrito666: so fdisk in "dos compatible mode" | 12:32 |
| jam | creating a primary partition at byte 63 | 12:32 |
| jam | set it bootable | 12:32 |
| jam | set it as a Fat32, seems to create something that will actually boot | 12:32 |
| jam | but I get to "Operating System Not Found" which doesn't seem helpful :) | 12:33 |
| jam | it worked two days ago | 12:33 |
| jam | I tried "dd" to see if I was just going the long way round | 12:33 |
| jam | weird, QEMU was happy ,but now my system is not | 12:34 |
| perrito666 | jam: maybe this is a stupid question | 12:34 |
| perrito666 | what size is your pendrive? | 12:34 |
| jam | perrito666: 16GB | 12:34 |
| perrito666 | jam: do you have something smaller to try? | 12:35 |
| jam | not on hand, and it did work a couple days ago | 12:35 |
| perrito666 | meh | 12:36 |
| jam | perrito666: note, dd did seem to work on the 64 bit ISO, but it booted and said "this is not a 64-bit system, download the 32bit instead" :) | 12:36 |
| perrito666 | well, is it? | 12:36 |
| perrito666 | btw, is a machine that old usable with a newer ubuntu¿? | 12:38 |
| jam | perrito666: again, I was using it for a while, I just wiped it to see if I could dd it | 12:38 |
| jam | so yeah, it is a 32 bit machine | 12:42 |
| jam | interesting, byte 63 really did matter | 12:43 |
| jam | I tried again with the default offset (byte 32) and it failed to detect it as bootable | 12:43 |
| perrito666 | jam: that is sector iirc | 12:47 |
| * TheMue is back after helping his wife buying more and larger plants for our garden | 12:51 | |
| perrito666 | TheMue: sweet, that means better air to breathe | 12:51 |
| jam | perrito666: sure, I just mean you have to know the magic 63 or it doesn't work, and it doesn't default to the right magic value | 12:52 |
| perrito666 | jam: fdisk defaulted to that magic value when your machine was new :p | 12:52 |
| jam | perrito666: yeah, and now it is actually a bad one because of sector alignment, etc. | 12:53 |
| TheMue | perrito666: exactly, it fine recreation in the garden | 12:53 |
| TheMue | s/it/and/ | 12:53 |
| jam | why can I not reproduce what worked 2 days ago... | 12:57 |
| perrito666 | jam: welcome to sinzui's world | 12:58 |
| TheMue | *lol* | 12:59 |
| perrito666 | even with the properly partitioned stick you cannot boot? | 12:59 |
| sinzui | perrito666, jam , speaking of 32bit. If I installed i386 go libs and tools on an amd64 instance, would this machine be valid to run unittests and build i386 juju? | 13:01 |
| jam | sinzui: davecheney is the one to ask that: http://dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go | 13:02 |
| sinzui | We are moving away from cross-compiling | 13:03 |
| sinzui | I make win32 juju by installing 32bit golang on 64bit server. | 13:04 |
| sinzui | the real issue is I cannot get an i386 machine that is powerful enough to run unittests and deliver a binary in 30 minutes | 13:04 |
| jam | sinzui: interesting, I'm ~ ok with using an amd64 in 32-bit mode and going with that | 13:13 |
| jam | I have a small concern that it won't notice if we accidentalyl give it a 64-bit binary and fail to test 32-bit at all | 13:13 |
| jam | could we run some level of smoke test on a real 32 bit ? | 13:13 |
| sinzui | jam, I was thinking of a jenkins slave to act as an i386. After I apt-add-architecture, I change the tests setups to honour it. I would then use the i386 slave to run unit tests, build the binary packages, install, then run lxc tests. | 13:15 |
| sinzui | I think I need i386 juju-mongodb too | 13:15 |
| natefinch | sinzui: 32 bit go on a 64 bit windows should run almost identically to 32 on 32 | 13:20 |
| sinzui | almost? don't say that that way | 13:20 |
| sinzui | natefinch, maybe I don't care. Win users do report bugs, and they are not reporting bugs about the client. | 13:21 |
| natefinch | sinzui: it's only almost in that there are file system and registry differences on 64 bit machines, but those are likely things we'll never run into unless we explicitly do some wacky stuff | 13:22 |
| jam | natefinch: sinzui: so I think the test suite on 32bit is fine, it is just that we could screw it up and not realize we were missing test coverage. | 13:22 |
| sinzui | okay, thank you natefinch. I will try to remember that | 13:23 |
| jam | "test suite in 32-bits on a 64-bit machine" | 13:23 |
| natefinch | sinzui: basically, the registry on a 64 bit windows also has a segregated 32 bit section... the two normally never realize they're segregated unless you specifically write code to go looking for the other section | 13:24 |
| voidspace | still building | 13:25 |
| natefinch | voidspace: since an hour and a half ago? | 13:25 |
| voidspace | natefinch: I think one was already in the queue | 13:26 |
| voidspace | natefinch: so yes, not merged yet as far as I can tell | 13:26 |
| === psivaa-lunch is now known as psivaa | ||
| natefinch | ahh yeah, single threaded, right. | 13:27 |
| voidspace | natefinch: yeah, build 10 has been going for 50 minutes | 13:27 |
| natefinch | Seems this is something we're going to have to address sooner rather than later | 13:27 |
| sinzui | jam: natefinch voidspace : I am setting up dedicated slaves to provide better testing and build resources next week. I will try to provide one for the lander bot to test merges quickly | 13:28 |
| voidspace | sinzui: great | 13:28 |
| jam | sinzui: given the Canonistack instance was only dual-CPU and 4GB data, why is the ec2 instance too slow for us? | 13:29 |
| natefinch | jam, sinzui: isn't it because we're bringing up the machine from scratch for every test? Or am I misunderstanding the infrastructure? | 13:30 |
| mgz | jam: it's a minor mystery | 13:30 |
| natefinch | (for every merge perhaps?_ | 13:30 |
| jam | natefinch: I would hope it doesn't take 35 minutes to bring up a new machine | 13:30 |
| mgz | jam: a good protion is that to get the tests to pass we *have* to run with -p 1 | 13:30 |
| jam | given our test suite was running in ~15-20 min | 13:30 |
| mgz | which doubles the time taken | 13:31 |
| natefinch | jam: also, EC2 is *notorious* for being slower than the specs people expect from it. | 13:31 |
| sinzui | yep | 13:31 |
| jam | natefinch: bad neighbor problem ? | 13:31 |
| natefinch | jam: yeah, basically | 13:31 |
| mgz | my plan of attack starts with moving the landing test running to another cloud | 13:31 |
| wwitzel3 | jam: so the WaitAgentPresence call isn't about actually waiting for anything. In fact, calling it with 1 ns results in the agent status being properly reported, even when doing ensure-availability && ensure-availability | 13:31 |
| wwitzel3 | jam: I just used it there because a) the Presence pinger API was already exposed there and b) I couldn't determine a better place to call it. | 13:32 |
| jam | wwitzel3: I don't see how it affects "ensure-availability && ensure-availability" given the agent hasn't even started yet, but I could see "bootstrap && ensure-availability" is that what you meant? | 13:33 |
| jam | I think the issue is that it forces an early watch of the agent status changing | 13:33 |
| jam | instead of waiting for it to background poll for it. | 13:33 |
| wwitzel3 | jam: sorry, yes bootstrap && ensure-availability | 13:34 |
| jam | wwitzel3: so I think what I'd like to see is something called "RefreshAgentState" that doesn't take a timeout and doesn't have to Watch anything, since it just grabs the current value | 13:35 |
| wwitzel3 | jam: I see, ok, and the just refactor WatchAgent to use that internally as well | 13:36 |
| natefinch | jam: yeah, we're not worrying about ensure-availaiblity getting called twice right now, since that's less of a valid thing to do than bootstrap and ensure-availability | 13:36 |
| jam | natefinch: well, given that we said you could run it in cron, it isn't *that* unexpected. however,sure, the patch wasn't about that, I was just making sure I wasn't missing anything. | 13:39 |
| jam | I think the key bit from wwitzel3's patch is that we currently have a mechanism for tracking presence, but it takes a long time for it to actually notice that the machine agent is running, when we want it to trigger as soon as the agent logs in. | 13:39 |
| natefinch | yep | 13:40 |
| jam | Im slightyl concerned about bouncing agents looking up too much | 13:40 |
| dimitern | jam, poke re that PR | 13:44 |
| jam | dimitern: I posted on it, IIRC | 13:44 |
| dimitern | jam, ah, I can see it now, thanks | 13:44 |
| sinzui | natefinch, jam, mgz, We might need more powerful instances, but giving the git-tester its own queue or resources will prevent it from queuing for 20 minutes while CI and health checks are running | 13:55 |
| voidspace | merged! | 13:56 |
| natefinch | wwitzel3, perrito666, voidspace I have the TOSCA meeting right now, can we postpone the standup until it's done? Probably an hour | 13:59 |
| voidspace | natefinch: fine with me | 13:59 |
| perrito666 | natefinch: sure | 14:00 |
| natefinch | I need to reschedule our standup on wednesdays, but gmail makes it tricky | 14:00 |
| sinzui | voidspace, can I take down the juju env/mongod that is running under ubuntu user on juju-ci? | 14:01 |
| voidspace | sinzui: oh crap | 14:01 |
| voidspace | sinzui: yes - sorry | 14:01 |
| sinzui | no | 14:01 |
| voidspace | sinzui: I thought I destroyed that environment, my apologies | 14:01 |
| sinzui | problem voidspace | 14:01 |
| sinzui | voidspace, you may have. I just see the mongod running | 14:02 |
| voidspace | I hope that is "no problem" and not "no. Problem!" | 14:02 |
| voidspace | ok | 14:02 |
| bodie_ | morning all | 14:19 |
| === alexisb_out is now known as alexisb | ||
| perrito666 | hi bodie_ | 14:20 |
| jcw4 | o/ | 14:20 |
| rogpeppe | mgz: any chance i could get permissions to create repos in github.com/juju ? | 14:26 |
| mgz | rogpeppe: ah, I haven't sent the email yet | 14:26 |
| rogpeppe | mgz: which email? | 14:27 |
| mgz | rogpeppe: maybe, the issue is we can't seperate the right to create a new repo in juju from the right to screw up any branch under juju | 14:27 |
| mgz | which is some what accident-y | 14:27 |
| mgz | I'll re-owner you for now, but please comment on the list when I send this notice :) | 14:28 |
| rogpeppe | mgz: what comment would you like me to make? | 14:28 |
| mgz | rogpeppe: done. | 14:29 |
| rogpeppe | mgz: ta | 14:29 |
| mgz | that you need to be able to create repos... we can find another way on that, perhaps a role-account all or some of us have access to | 14:30 |
| dimitern | jam, if you're still here and can have a look, I've updated https://github.com/juju/juju/pull/13 as you suggested | 14:31 |
| rogpeppe | mgz: that's not a bad idea | 14:32 |
| bodie_ | am I the only one getting this problem in state_test? http://paste.ubuntu.com/7587871/ | 14:33 |
| bodie_ | It has nothing to do with anything I've touched as far as I can tell | 14:33 |
| bodie_ | so I guess that's a yes haha | 14:37 |
| voidspace | local-deploy-precise-amd64 has got as far as bootstrapping the juju machine agent | 14:37 |
| voidspace | dammit, failed | 14:38 |
| voidspace | and for a different reason | 14:38 |
| voidspace | natefinch: sinzui: latest build failed | 14:39 |
| voidspace | Initiate: fetching replicaset status failed: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG) | 14:39 |
| voidspace | natefinch: sinzui: I'm going to prepare a branch backing out the changes that caused this | 14:39 |
| voidspace | I don't think we should follow this rabbit hole any further | 14:39 |
| natefinch | voidspace: ok. Damn. | 14:39 |
| sinzui | :/ | 14:40 |
| sinzui | thank you voidspace | 14:40 |
| lazyPower | Greetings core team, have any of you seen an LXC failure message akin to the following: http://paste.ubuntu.com/7587937/ - something about LXC not understanding the argument 'trusty' ? | 14:47 |
| bodie_ | odd | 14:50 |
| bodie_ | lazyPower, are you on Ubuntu? I had a hell of a time getting everything working properly until I switched my workstation over to 14.04 | 14:50 |
| lazyPower | bodie_: this is our juju flavored vagrant image | 14:50 |
| lazyPower | so its precise atm | 14:50 |
| bodie_ | ah | 14:51 |
| bodie_ | well, that's all I've got, hehe | 14:51 |
| lazyPower | our trusty image seems to be suffering from similiar issues but I don't have enough empiracle evidence to present as to the root cause of the issues yet. | 14:51 |
| adeuring1 | lazyPower: well, I see this error for the Juju vagrant image for precise, for example this one: http://cloud-images.ubuntu.com/vagrant/precise/20140602/precise-server-cloudimg-amd64-juju-vagrant-disk1.box | 14:55 |
| adeuring1 | The trusty images work fine. | 14:55 |
| natefinch | ahhh stupid chrome, man. Had to switch to firefox to get hangouts to be stable. That's pretty sad, Google. | 14:55 |
| wwitzel3 | ahh, was wondering what you did to fix it | 14:55 |
| lazyPower | adeuring1: admittedly its been about 2 weeks since i've looked at the trusty box, if the lxc container issues have been resolved - bueno! | 14:55 |
| bodie_ | natefinch, lol | 14:57 |
| wwitzel3 | natefinch: should we do standup now? | 14:58 |
| bodie_ | hrmn | 15:01 |
| bodie_ | http://paste.ubuntu.com/7588034/ | 15:01 |
| jcw4 | bodie_: go get -u github.com/juju/testing/... | 15:01 |
| bodie_ | ah... derp | 15:02 |
| bodie_ | that's weird though since I did a go get github.com/juju/juju -- ah, maybe I left off the /... | 15:02 |
| bodie_ | yep, looks like that's doing it | 15:03 |
| jcw4 | bodie_: I avoid go get -u github.com/juju/juju because I don't want go get to overwrite my personal repo at that location. | 15:03 |
| jcw4 | bodie_: I don't think it will with git, but still... | 15:03 |
| bodie_ | I had the same concern but I was able to immediately re-checkout my own branch, so I don't think there was an issue | 15:04 |
| bodie_ | hopefully this will do the trick | 15:04 |
| natefinch | wwitzel3: yep | 15:05 |
| natefinch | voidspace, perrito666: standup | 15:05 |
| perrito666 | natefinch: going | 15:06 |
| bodie_ | and all tests are green! BOOYA! | 15:06 |
| natefinch | nice | 15:07 |
| voidspace | natefinch: https://github.com/juju/juju/pull/14 | 15:15 |
| sinzui | I know know what the powerpc debs are. They are the 32bit debs for ppc64el vms. We don't make juju tools for the arch, we could if the ubuntu in ubuntu on ppc64el envisions running juju inside it | 15:16 |
| bodie_ | polishing my nonexistent git rebase skillz: does anyone know if it's possible to use multiple commands per commit? | 15:26 |
| bodie_ | e.g. squash AND edit | 15:26 |
| bodie_ | I figured it would just be something like s,e | 15:27 |
| bodie_ | also, this might be worth looking at (natefinch?) http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html | 15:29 |
| bodie_ | personally I've always used the branch-and-merge-prolifically approach, which might have a more "honest" but noisier / less human readable history | 15:30 |
| mgz | sinzui: what's the oldest version of go the jenkins infrastructure compiles juju with? | 15:43 |
| sinzui | mgz, 1.1.2 used by precise and saucy | 15:44 |
| sinzui | mgz, oh and the win client | 15:44 |
| mgz | sinzui: are we planning to change this for the current dev release? | 15:45 |
| mgz | you had a newer version compile yourself, right? | 15:45 |
| sinzui | mgz, the juju-packaging/devel ppa is building only with 1.2. | 15:46 |
| mgz | sinzui: I guess I'd better take it to the list, but would like to make 1.2 the minimum for trunk | 15:47 |
| bodie_ | https://github.com/juju/juju/pull/15 | 15:59 |
| bodie_ | ^_^ | 15:59 |
| sinzui | mgz, well I think that is doable since I backported 1.2 to precise. None of the 1.19.3 bugs imply a compiler issue. I can promote my package to the stable archive for 1.20. *BUT* We need foundations to accept golang 1.2 into ctools to really make the transition | 15:59 |
| perrito666 | anyone remembers what was the outcome of the discussion about writing the docs as markdown (or anything other than plain text)? | 16:05 |
| voidspace | perrito666: I *thought* we all agreed on markdown | 16:05 |
| voidspace | perrito666: it's pretty plain-text-ish anyway | 16:06 |
| perrito666 | I thougt so too | 16:08 |
| mgz | sinzui: bash help, github-merge-juju/12 failed at the build step but the way I'm calling into the build script didn't get me an exit code to report the failure, it just aborts the job | 16:25 |
| * sinzui looks | 16:26 | |
| sinzui | mgz, I think you are saying that the script should get to "echo "Build failure, reporting on proposal"" | 16:28 |
| mgz | right, but source is wrong | 16:28 |
| mgz | it goes and executes as top level, right? | 16:28 |
| mgz | that whole block is kinda horrid | 16:28 |
| sinzui | mgz make-release-tarball.bash is setting -e and the script is sourcing | 16:29 |
| * mgz <3 sh | 16:29 | |
| sinzui | I think we ca avoid the use of source | 16:29 |
| mgz | okay, yeah, that'd do it | 16:29 |
| mgz | I tried to do it with a || { ..block.. } rather than fiddling with -e but no joy on the syntax | 16:30 |
| sinzui | I try to avoid sourcing because of that. I see the job knows how to find the tarball | 16:30 |
| sinzui | mgz, may I rebuild to get the proper error? | 16:30 |
| mgz | yeah, just add $$merge$$ on the mp | 16:30 |
| mgz | dave won't mind the spam :) | 16:31 |
| sinzui | mgz watching http://juju-ci.vapour.ws:8080/job/github-merge-juju/13/console | 16:31 |
| mgz | ta | 16:31 |
| mgz | that worked. thanks sinzui! | 16:36 |
| sinzui | :) | 16:36 |
| voidspace | natefinch: when I merged your write-majority code I created an mp that I forgot to mark as WIP | 16:47 |
| voidspace | natefinch: so there was some interesting discussion on it :-) | 16:47 |
| voidspace | natefinch: https://code.launchpad.net/~mfoord/juju-core/write-majority/+merge/220823 | 16:48 |
| voidspace | natefinch: part of the problem, which I forgot to mention during standup, is that setting the write mode doesn't return an error | 16:48 |
| voidspace | natefinch: so you can't use *that* to detect whether there's a replica set or not | 16:48 |
| voidspace | natefinch: I'll have to find some analagous operation that does nothing (e.g. replicaset.CurrentConfig() ) but returns an error when there's no replica set | 16:49 |
| mattyw | Is someone able to spare a few moment to talk about how we test long running commands in core? | 16:53 |
| natefinch | voidspace: ahh, dang. So you can set write majority and it won't error out... what happens? | 16:53 |
| voidspace | natefinch: I think everything after that errors :-) | 16:54 |
| voidspace | that's what I was seeing in tests | 16:54 |
| natefinch | haha | 16:54 |
| voidspace | with the noreplset error we saw | 16:54 |
| voidspace | or whatever it was | 16:54 |
| voidspace | no, I think session.SetSafe panics with that error | 16:55 |
| voidspace | something like that | 16:55 |
| voidspace | hooray for no exceptions! | 16:55 |
| voidspace | natefinch: I'll sort it out, not a problem | 16:55 |
| voidspace | natefinch I got an LGTM from jam on my revert PR, so I've gone the magic merge message | 16:58 |
| natefinch | voidspace: cool | 16:58 |
| natefinch | (sorta) | 16:59 |
| voidspace | heh | 16:59 |
| voidspace | jujubot is quick | 16:59 |
| mgz | THANK YOU | 17:00 |
| mgz | beep beep boop | 17:00 |
| voidspace | mgz: heh :-) | 17:00 |
| voidspace | no, thank you (I assume) | 17:00 |
| voidspace | it noticed my magic-merge-message within a few seconds | 17:00 |
| jcw4 | mgz: they said you were a machine... didn't realize it was literal | 17:00 |
| mgz | :) | 17:02 |
| bodie_ | that sounds like a reference to a bad B sci fi flick | 17:02 |
| bodie_ | "My masters built me to be the perfect merge resolver. Now I must kill all humans." | 17:02 |
| jcw4 | quick... someone feed the merge bot a bad whitespace merge... that oughta save mankind | 17:03 |
| alexisb | jam, what networking spec are you and dimiter currently using? | 17:05 |
| alexisb | I should say working off of | 17:05 |
| voidspace | natefinch: specifically: ... Panic: cannot create database index: norepl (PC=0x414676) | 17:08 |
| jam | alexisb: so *right* now Dimiter is working on fixing up what was discussed with Mark S, about not having "juju deploy --exclude-networks" but instead making it a constraint (juju deploy --constraints=network=^foo" | 17:08 |
| jam | I'm trying to find the concrete doc on that | 17:08 |
| natefinch | voidspace: man, not sure who's panicking there, but that's terrible | 17:08 |
| jam | the other actions being worked on are toward: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.h1grzzgqa6st | 17:08 |
| voidspace | natefinch: yeah, it sucks :-) | 17:09 |
| voidspace | natefinch: inside provider/dummy/environs.go I believe | 17:09 |
| natefinch | oh, the dummy provider.... that's our own stupid fault.... quite possibly specifically my stupid fault | 17:10 |
| alexisb | jam, ack, when we get to the point of network modeling work we will need a spec that we can point to that is current and explains the work being done | 17:10 |
| jam | alexisb: so I know of https://docs.google.com/a/canonical.com/document/d/1bHI5ZXbbnGk3xict7d_39ipOcUI2urFVNMKQv1BFlSk/edit and https://docs.google.com/a/canonical.com/document/d/1UzJosV7M3hjRaro3ot7iPXFF9jGe2Rym4lJkeO90-Uo/edit#heading=h.a92u8jdqcrto though I think the actual concrete plan needs to be properly written up. | 17:10 |
| voidspace | natefinch: it's state.Initialize that returns that error and the dummy provider panics | 17:11 |
| voidspace | natefinch: but this is long *after* we set the write mode | 17:11 |
| jam | Which I pointed TheMue towards, but I don't think we've actually started the process of generating the user docs for how we are going to make networking look. | 17:11 |
| alexisb | jam ack | 17:12 |
| alexisb | we will wnat to have a target date for completion of plan write-up that we can communicate to the interlock group + mark s | 17:13 |
| voidspace | natefinch: actually, not *long after*, it's probably immediately after | 17:16 |
| voidspace | natefinch: write majority is set in state.Open, which is called from state.Initialize which is called from the dummy provider | 17:17 |
| voidspace | natefinch: so it's opening the state (newState) after setting write majority that fails | 17:17 |
| voidspace | I'll try guarding it with a replicaset.CurrentConfig call first | 17:17 |
| voidspace | if that errors we won't set write-majority | 17:18 |
| natefinch | voidspace: ok.... sorry, I had hoped it would be more straightforward, but it seems that's rarely the case when interacting with mongo | 17:18 |
| voidspace | natefinch: hah, it's interesting - not a big problem | 17:18 |
| voidspace | at least this one seems solvable | 17:19 |
| natefinch | voidspace: yep | 17:19 |
| voidspace | natefinch: guarding setting the WMode with checking the replicaset config seems to work | 17:23 |
| natefinch | voidspace: ship it! | 17:23 |
| voidspace | natefinch: well, you say that... | 17:23 |
| voidspace | but yes... | 17:23 |
| voidspace | :-D | 17:23 |
| voidspace | is there any way to create a "work in progress" pull request on github? | 17:26 |
| voidspace | so I can view the diff | 17:26 |
| perrito666 | voidspace: sor of | 17:27 |
| voidspace | perrito666: explain :-) | 17:27 |
| perrito666 | voidspace: you can click on pull request button | 17:27 |
| voidspace | perrito666: right | 17:27 |
| perrito666 | and beforre hitting commit | 17:27 |
| voidspace | perrito666: I'd like one I can share | 17:27 |
| perrito666 | you have the diff tab available | 17:27 |
| voidspace | perrito666: clicking "compare & pull request" shows the diff immediately | 17:28 |
| voidspace | perrito666: but there's no "diff tab" anywhere I can see ? | 17:28 |
| perrito666 | mmm hold I think I remember such feature | 17:28 |
| voidspace | another chrome extension perhaps | 17:29 |
| voidspace | perrito666: once you've created the pull request there's a "files changed" tab that shows you the diff | 17:30 |
| voidspace | natefinch: so the actual change is quite simple | 17:30 |
| voidspace | https://github.com/juju/juju/pull/17/files | 17:30 |
| voidspace | natefinch: testing it on the other hand... | 17:30 |
| voidspace | a problem for tomorrow morning I think | 17:31 |
| voidspace | EOD | 17:31 |
| perrito666 | voidspace: | 17:31 |
| natefinch | perrito666: the files changed tab has the diffs | 17:31 |
| perrito666 | ok, this will sound stupid but I know only how to do this via url | 17:31 |
| perrito666 | Idont know how to get there via the gui | 17:31 |
| perrito666 | :p | 17:31 |
| natefinch | perrito666: https://github.com/juju/juju/pull/17/files | 17:31 |
| natefinch | their "tabs" are pretty subtle | 17:31 |
| voidspace | yeah, but you only get that by creating a pull request | 17:32 |
| voidspace | there's no way to specify that it's still a work in progress except by comment (which is what I've done) | 17:32 |
| voidspace | (well - description) | 17:32 |
| perrito666 | I found it | 17:32 |
| perrito666 | voidspace: on your repo | 17:32 |
| * natefinch should learn to read the history before jumping into a conversation | 17:32 | |
| perrito666 | above the list of files | 17:32 |
| perrito666 | there is a greyed link, that says compare | 17:32 |
| voidspace | ah yes! | 17:33 |
| voidspace | perrito666: thank you | 17:33 |
| gQuigs | I'm just curious and couldn't find backstory on the decision to move juju-core from lp to github, anyone know where it took place? (I already tried looking through the ml) | 17:33 |
| voidspace | https://github.com/voidspace/juju/compare/write-majority | 17:33 |
| natefinch | gQuigs: basically an order from On High™ ... the thought is to make the project more visible, and lower the barrier of entry for external contributors, since most people are more familiar with git and github than bzr and launchpad | 17:34 |
| perrito666 | https://github.com/voidspace/juju/compare/juju:master...voidspace:backout-replicaset-changes | 17:34 |
| voidspace | perrito666: yep, thanks - that's helpful | 17:35 |
| perrito666 | we might want to ship that little piece of advice in the code | 17:35 |
| perrito666 | s/code/doc | 17:35 |
| gQuigs | natefinch: oh.. understood.. was adding git support to lp looked at? - or was the complete package important? | 17:35 |
| voidspace | right, really EOD | 17:36 |
| voidspace | g'night all | 17:36 |
| natefinch | gQuigs: it was more the whole package and the fact that more eyes are on github, and we wanted more eyes on juju development | 17:42 |
| gQuigs | natefinch: got it, thanks for explaining | 17:54 |
| jam | alexisb: good job keeping it right at 30min | 18:02 |
| alexisb | there are some things that people need to go off and investigate | 18:03 |
| alexisb | so it made since to keep is to the time | 18:03 |
| perrito666 | alexisb: what? | 18:04 |
| TheMue | jam: just seen you mentioned me. is network documentation higher priorized than API? | 18:08 |
| sinzui | gQuigs, We were hearing that Juju wasn't a public project. Of course it is, but people didn't see it on github, they couldn't fork it nor could they make a pull request. github ~= "open source and looking for new contributors" | 18:08 |
| alexisb | perrito666, it made sense to me, can't you just read what I was thinking and not what I actually typed ;) | 18:12 |
| lifeless | jam: heh interesting :(. | 18:48 |
| sinzui | jam, lifeless All the senior people are ex bzr and Lp. I think jcastro is the only exception being 6 years, but from ubuntu | 19:01 |
| jcastro | jam is older, we established that at the sprint | 19:02 |
| jcastro | sorry, I mean "more experienced" | 19:02 |
| perrito666 | its pretty clear that jam looks younger than all of us, so hopefully he is | 19:11 |
| perrito666 | bbl | 19:34 |
| bodie_ | in order to test an unexported method, I should just use the same package name as the tested file, right? | 19:42 |
| bodie_ | (is there a better word than file to use in this context?) | 19:42 |
| natefinch | bodie_: that's correct | 19:43 |
| jcw4 | bodie_: your test package has to have the same package name as the method | 19:43 |
| jcw4 | s/method/method package/ | 19:43 |
| natefinch | bodie_: there's only two places you can put tests, either the same package as the rest of the directory, or package_test | 19:44 |
| natefinch | bodie_: we usually call them internal and external tests or whitebox and blackbox | 19:45 |
| bodie_ | I see | 19:45 |
| bodie_ | and there's no special name for a file besides "file" since multiple types and so forth could be in it | 19:46 |
| natefinch | bodie_: personally, I just put all my tests in the same package a the rest of the directory. there seems to be no actual reason to use package_test unless you want to have example code that looks like what external packages would use (in other words, functions and types namespaced by the package name) | 19:46 |
| bodie_ | I see | 19:46 |
| natefinch | bodie_: other people like to use blackbox tests as much as possible to ensure they're testing the API rather than the implementation, which I kind of agree with... except that you can still do that in internal tests, except you have a lot more flexibility to mock stuff out and do more focused unit tests | 19:47 |
| hazmat | hey is there a document that maps gemstones to humans ? | 20:06 |
| natefinch | lol | 20:08 |
| natefinch | hazmat: https://directory.canonical.com/list/team/ | 20:08 |
| natefinch | hazmat: they're actual teams :) | 20:09 |
| jcw4 | natefinch: 403 :( | 20:09 |
| jcw4 | :) | 20:09 |
| natefinch | jcw4: haha | 20:10 |
| hazmat | natefinch, yeah.. see how most of those are instantly recognizable ... | 20:10 |
| natefinch | hazmat: maybe it be better if we prefixed them with "Juju Core - " | 20:11 |
| natefinch | hazmat: we just didn't want "Team 1" "Team 2" | 20:11 |
| hazmat | natefinch, yeah.. that would help. at least they'd group together.. | 20:11 |
| natefinch | alexisb: ^^ | 20:12 |
| natefinch | not sure what the process is to get them changed. I agree, it would be nice if they were grouped together, and more descriptive | 20:12 |
| natefinch | I actually hadn't expected them to be made into official HR teams | 20:12 |
| natefinch | but I guess since HR needs to know who's managing who | 20:13 |
| alexisb | natefinch, I can take care of that | 20:13 |
| === vladk is now known as vladk|offline | ||
| === menno0-afk is now known as menn0 | ||
| waigani | morning all | 21:17 |
| menn0 | moring waigani | 21:17 |
| waigani | hey menn0 :) | 21:17 |
| * menn0 sighs | 21:17 | |
| menn0 | morning even | 21:17 |
| * menn0 has had a bad night's sleep (kids) but AC/DC is helping | 21:17 | |
| wallyworld__ | fwereade: sorry, network issues, will reboot and be there soon | 21:30 |
| wallyworld__ | fwereade: thumper sorry, g+ has crapped itself | 21:45 |
| wallyworld__ | trying to get back in | 21:46 |
| === wallyworld is now known as Guest56344 | ||
| wallyworld_ | alexisb: be there in a sec, just finishing another meeting | 22:29 |
| alexisb | me too | 22:30 |
| alexisb | wallyworld_, ^^ | 22:30 |
| wallyworld_ | alexisb: sorry, here now | 22:35 |
| alexisb | wallyworld_, coming | 22:35 |
| alexisb | wallyworld_, sorry | 22:39 |
| alexisb | still on another call | 22:39 |
| * thumper goes to walk the dog and think prior to standup | 22:40 | |
| alexisb | wallyworld_, I see you typing | 22:44 |
| alexisb | but you cant hear me | 22:44 |
| alexisb | wallyworld_, I lost you | 22:58 |
| === wallyworld is now known as Guest68975 | ||
| === sebas538_ is now known as sebas5384 | ||
| waigani | so already I've: tried to push to upstream and been working in the launchpad repo when I thought I was in github | 23:17 |
| waigani | sigh... | 23:17 |
| * thumper heads out for lunch | 23:54 | |
| menn0 | waigani: I moved my old bzr repo well out of the way to avoid exactly that | 23:56 |
| menn0 | waigani: and Tim's tip of setting the push url for upstream to something that doesn't exist is a good idea | 23:56 |
| waigani | menn0: yep, luckily I had done that already, so no harm done | 23:57 |
| menn0 | ok sweet | 23:57 |
| waigani | menn0: I'm now thinking about how to propose three branches, each one relying on the one before it | 23:57 |
| menn0 | I would do them one at a time | 23:58 |
| menn0 | landing one before proposing the next | 23:58 |
| waigani | oh right, yeah | 23:58 |
| menn0 | that way if there's post-review changes for an earlier branch you can adjust the following branch to suit | 23:59 |
| waigani | that will have to do for now | 23:59 |
| menn0 | otherwise it just gets confusing | 23:59 |
| waigani | bzr was a little smarter, but this way is simple and clean and will do for now | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!