[00:39] http://juju-ci.vapour.ws:8080/job/github-merge-juju/35/? [00:39] what the heck happened ? [00:41] davecheney: well first of all, it would seem that the bot is not properly merging stuff since at some point i in detached mode [00:41] can anyone just hulk smash this [00:41] this is blocking a fix [00:41] i've been trying to merge this SOB for 3 days [00:43] davecheney: wallyworld_ is the man you are looking for [00:43] well perhaps its mgz but I hink at thi time you can only get wallyworld_ [00:44] * wallyworld_ is having network issues :-( [00:44] so i missed the question [00:44] wallyworld_: can you land https://github.com/juju/juju/pull/10 manually [00:44] i've been stuck on this for days [00:44] sure, why? [00:45] http://juju-ci.vapour.ws:8080/job/github-merge-juju/35 [00:46] so don't you need to fix the merge conflict first? [00:46] thanks [00:46] i'll try again [00:46] that probably means someone already bumped the versino of juju testing [00:46] so I probablky don't need to do this at all [00:47] i am happy to help if needed [00:49] wallyworld_: thanks for your help, I think I have it now [00:49] ok, i didn't do anything though :-) [00:50] wallyworld_: your sole presence is enough [00:51] debatable :-) [01:05] hey, what's happening with juju/names ? [01:07] looks like the job is 1/2 done [01:07] davecheney: how so? [01:07] is there a job to nuke the copy in juju/juju ? [01:07] + ./bin/lander-merge-result --ini development.ini --pr=10 --job-name=github-merge-juju --build-number=36 [01:07] Failed to add comment: Failed to merge: {u'sha': u'6bbbdb86e38120549487326600e16bc1a340d59d', u'message': u'Pull Request successfully merged', u'merged': True} [01:07] ++ date [01:07] + echo Finished: Fri Jun 6 01:07:08 UTC 2014 [01:07] Finished: Fri Jun 6 01:07:08 UTC 2014 [01:07] + exit 0 [01:08] Description set: davecheney 101-update-juju-testing-dependency [01:08] Finished: SUCCESS [01:08] wallyworld_: failed, but success ? [01:09] otp, sec [01:10] davecheney: sorry, I thought you were talking about in your own repo/branch [01:10] :) [01:13] davecheney: yeah, dumb message, github seems to think it's merged from what i can see. i'll get martin to look into it as he's tidying up all that stuff at the moment [01:14] wallyworld_: i'm moving on to finishing the juju/names package [01:14] that is blocking me today [01:15] davecheney: ok, but at least your dep change got merged even if the console message sucked [01:15] \o/ [01:15] i'll go close the bug on LP then [01:52] axw: so i have a large set of changes i want to split up into 2 branches (like a bzr pipeline). i want to add a pre-req branch to my current one. the work is currently not committed. do you know how to do that efficiently with git? do a need that stacked git addon? [01:54] wallyworld_: why do you want to do it in two branches - just to split up the review? [01:54] yeah [01:54] like we do in launchpad and bzr [01:55] and i want to switch between the 2 [01:55] make changes in the upstream one and push those to the other [01:55] so there's no prereq sort of thing in GH. if they're small enough, you could just put them in one review as separate commits. you can then see commit-specific changes in the review [01:56] I don't know much about stacked git, just that it exists [01:56] ok, ta [01:56] i'm really missing bzr and launchpad already [01:59] https://github.com/juju/juju/pull/34 [01:59] ^ finishes the move to juju/names [02:00] davecheney: https://github.com/juju/juju/pull/27 [02:01] thumper: I don't get it [02:01] my working copy doesn't have this [02:01] oh fuck [02:01] git fetch upstream? [02:01] how do you set that up ? [02:01] davecheney: what do you have now? [02:02] just editied .git/config to set original to my fork [02:02] thats it [02:02] git remote -v [02:02] lucky(~/src/github.com/juju/juju) % git remote -v [02:02] origin https://github.com/davecheney/juju (fetch) [02:02] origin https://github.com/davecheney/juju (push) [02:02] ok... [02:02] git remote add upstream https://github.com/juju/juju.git [02:02] davecheney: were there supposed to be so many changes to dependencies.tsv in you mp? [02:03] wallyworld_: supposed to only be one change [02:03] davecheney: git remote set-url origin git@github.com:davecheney/juju.git [02:03] the diff has a few more than that [02:03] i do godeps -t $SOMEPKG >> dependencies.tsv [02:03] davecheney: and what axw said [02:03] then do: [02:03] then hand edit dependencies.tsv afterwards [02:03] because godeps is so pickup about the file format [02:03] i just always hand edit it [02:03] git branch --set-upstream-to remotes/upstream/master [02:04] % git branch --set-upstream-to remotes/upstream/master [02:04] error: the requested upstream branch 'remotes/upstream/master' does not exist [02:04] but do "git fetch upstream " first [02:04] sorry [02:04] ordering [02:04] ok [02:04] davecheney: also "git remote set-url --push upstream no-pushing" will mean you can't accidentally push upstream [02:05] davecheney: so i think you need to fix the tsv file so the diff only shows one change [02:05] there is no way i'll remember this [02:05] if anyone cares, I have a local branch called "master" that tracks upstream/master. I pull into this and branch off there for my feature branches [02:05] is this writtne down anywhere [02:05] davecheney: you only have to do it once [02:05] and I think it is written down [02:05] if not, it should be [02:06] wtf is git so obtuse and difficult? [02:11] thumper: do I need to do the updates upstream thing for every juju repo ? [02:12] yes [02:12] ok [03:28] menn0: great feedback so far... let me know when you're done and I'll respond to them all [03:30] jcw4: will do [03:44] CI Loves trunk after 9 days. Blessed: gitbranch:master:github.com/juju/juju 6bbbdb86 (Build #1451) [03:45] sinzui: yay [03:51] thumper: https://github.com/juju/juju/pull/35 [03:53] axw: I have the same setup [04:04] thumper: you about? [04:09] jcw4: all done [04:09] menn0: sweet, all good comments thanks [04:09] jcw4: sorry that I don't feel like I can LGTM it (due to my lack of background, not a problem with the code) [04:10] I'll address the stuff you brought up and then ask fwereade for review too.. [04:10] cool [04:10] menn0: no worries, I appreciated all your feedback [04:10] hopefully I've caught a few things fwereade would have otherwise [04:12] davecheney: regarding https://github.com/juju/juju/pull/34 [04:13] davecheney: I've seen your comment. Is the diff shown no longer accurate? [04:14] menn0: it is accurate [04:14] davecheney: ok, the comment confused me a little. I will review! [04:15] if anyone's able to review goose changes, I need one please: https://codereview.appspot.com/103900045 [04:16] davecheney: why the changes of errors.New to fmt.Errorf? [04:16] menn0: why have two differnt ways of making an error ? [04:17] davecheney: ok. so because fmt.Errorf is more flexible you're standardising to that? [04:18] just reducing the number of imports [04:18] why import errors to make one call to it [04:18] when fmt is already imported and does the smae job [04:18] why not use the new juju/errors package which gives tracing? [04:19] davecheney: ^^ [04:19] menn0: it was just a cleanup [04:19] i'm not trying to boil the ocean [04:19] davecheney: fair enough. but in general we should be using juju/errors right? esp for new stuff? [04:19] menn0: nfi [04:20] davecheney: I think we are but that doesn't matter for this change ;-) [04:20] afaik the errors package is for wrapping other errors [04:21] davecheney: it also generates new errors with the source information recorded [04:21] there's New and Errorf which are compatible with the standard library functions [04:23] davecheney: anyway, review done. [04:23] ta [04:35] waigani: here now [04:35] and missed the ping from before [04:35] was collecting daughter [05:12] davecheney: creating a test for the error, I can't see how to do this. d.dir is not exported, so I can't override that ... ? [05:15] menn0: thumper: github is erasing my backslashes. The regex in the comment *should* read: ^.+\.jenv$ === revagomes_ is now known as revagoems [05:17] waigani: regardless I still think you should consider using Glob instead of a regex :) [05:17] menn0, thumper: what are we doing for review fixes? amending? rebasing? or just pushing? [05:19] waigani: I've generally been editing history (either git commit --amend or some kind of rebase) and pushing with --force. Github handles that pretty well and it's not like anyone is going to be checking out your PR on their machine. [05:19] menn0: Cool I'll amend and push -f [05:19] waigani: if there was a large change in response to a review comment then I would probably commit it was a separate rev [05:20] yeah, fair enough, makes sense [05:28] menn0: I'm going to run some smoke tests on my changes and push an update to PR https://github.com/juju/juju/pull/33 [05:28] menn0: I did make one comment and asked one question in there though [05:28] jcw4: cool. I'm about to finish up but can hang around for a little longer [05:33] no worries menn0 I'm eod'ing right after I push... [05:37] jcw4: I've responded to your comments. I thought of more potential issues with the ActionResults() lookup unfortunately. [05:38] heh... thanks menn0 [05:40] menn0: how about ActionResultsForUnit(globalKey), and ActionResultsForAction(actionId)? [05:40] jcw4: yes, that sounds good [05:40] cool, tx [05:42] jcw4: another thought: a comment describing the structure the of the action ids might be useful [05:42] menn0: +1 [05:42] right I'm done [05:43] ta [05:43] * menn0 thinks review duty is hard work (but rewarding) [05:44] have a good weekend all [06:14] Okay I pushed latest changes for PR https://github.com/juju/juju/pull/33 [06:16] fwereade: if you get a chance today your input would be appreciated [06:25] axw: i'm getting errors trying to push a feature branch (missing packages). so i changed to master, did a git pull upstream master. i want to push that to my fork on gh using git push origin but still it says packages are missing. do you know what i need to do? [06:26] wallyworld_: sounds like the pre-push hook is failing [06:26] wallyworld_: some packages have been moved around (out of juju/juju) [06:26] you probably just need to go get them [06:27] ok, will try. git is so easy to use [06:42] wallyworld_: sorted? [06:44] no :-( sort of. i was working on branch A. I committed some files. I stahsed the rest. I checkout -b branch B. I pop the stash. I commit and push. Now branch B in the pull request has all the stuff from branch A as well [06:44] and I can't do anything with branch B because it depends on changes in branch A [06:44] this sucks [06:46] so ideally i want to delete stuff from branch B (all of the branch A work) [06:47] but nothing in the log seems to indicate where the branch A stuff came from to get into branch B [06:56] fwereade, jam, please take a last look at https://github.com/juju/juju/pull/13 i really need an approval to land it already [07:02] wallyworld_: if you "checkout -b", that's coming off the branch you were previously on [07:02] wallyworld_: if you didn't want the stuff from A, branch off master [07:03] wallyworld_: now that you've done that, you can just "git rebase -i master" and delete the commits you don't want in that branch [07:08] axw: thank, will do that after soccer [07:26] does anyone know if the issues with the jenkins bot are fixed yet? [07:26] axw: ^ [07:27] rogpeppe1: issues? [07:28] axw: there was a checksum issue which was causing all builds to fail like this http://juju-ci.vapour.ws:8080/job/github-merge-juju/30/consoleText [07:28] axw: because the go tool wasn't available [07:28] axw: if you've succeeded in landing stuff, i guess it's fixed [07:29] rogpeppe1: I'm pretty sure I've seen things landed today [07:29] axw: ok, i'll try again [07:32] could someone please take a quick look at this bug and say what more information i can add to it, before i shutdown the failed instance? https://bugs.launchpad.net/juju-core/+bug/1327078 [07:32] <_mup_> Bug #1327078: Failed to bring up an LXC with 1.19.3

[07:46] anyone know what happened to lbox.check? i'd like to run the checks locally that the bot runs remotely, so i don't do silly things like forget to gofmt or govet. [07:47] (having just realised i failed to gofmt my last merge req) [07:47] BjornT: if there's no /var/lib/juju, then I think cloud-init-output is all we can work with [07:47] rogpeppe1: symlink scripts/pre-push.bash as .git/hooks/pre-push [07:47] axw: ok, thanks [07:48] axw: ah, excellent, thanks - i'd have taken ages to find that [07:48] np [07:49] axw: is the pre-push script guaranteed to run in the root dir of the repo> [07:49] ? [07:49] axw: (when doing git push) [07:49] sinzui: interesting thing I found - the HA-failing-on-precise thing only occurs on your machine when the mongo db is on the ephemeral disk [07:49] rogpeppe1: yes, I confirmed that [07:50] pushed from some other subdir, it always was run in the root [07:51] hmm, pity it takes 30s to run [07:54] cp /bin/true $(go tool -n vet) [08:07] morning all [08:12] morning [08:16] TheMue, hey [08:17] TheMue, I need an LGTM on this if you can take a look - I fixed all that was suggested earlier https://github.com/juju/juju/pull/13 [08:19] dimitern: yep, will take a look [08:19] voidspace: I've had a breakthrough on the local-provider/replicaset issue [08:19] TheMue, thanks [08:19] voidspace: I can reproduce it on my own m2.xlarge instance [08:19] voidspace: the trick is to use the ephemeral disk as the root-dir [08:19] if you use the EBS disk it works fine [08:30] is there any way of telling jenkins to stop retrying tests because i've pushed a new version of the branch? [08:32] axw: ah right [08:32] axw: interesting [08:40] dimitern: a bit hard to follow now on GH. the comment by william yesterday at 10:16 (at the bottom), is it covered? [08:44] TheMue, about constraints? [08:44] TheMue, yes [08:44] TheMue, there are a few things i'll do in follow-ups as agreed as well [08:44] dimitern: fine [08:45] dimitern: done [08:45] TheMue, cheers [08:45] dimitern: does GH provide a side-by-side diff too? [08:46] TheMue, no, but menno found some chrome extension that gives you that - check the mailing list [08:53] dimitern: chrome is a no-go for me, it’s a resource hog. since changing to ff everything runs better, even the google apps like mail or hangout [08:56] axw: any idea *why* that should make a difference - IO performance? [08:57] voidspace: not really. I wouldn't think it'dbe iops, because the ephemeral disk should be faster [08:57] * axw checks hdparm [08:58] ffs, it's *still* retrying the tests [08:58] axw: can you reproduce it with trusty? [08:58] axw: or is it just precise [08:58] voidspace: I did, same issue. I sent instructions to juju-dev on how to repro [08:58] axw: ah yes, I see [08:58] voidspace: EBS on that machine gets 80.33MB/s, ephemeral gets 552.59MB/s [08:59] voidspace: I tried it on m3.xlarge and the ephemral disk was fine. on there it's an SSD though [09:00] it seems like a failed test delays the merge queue by at least 30 minutes. that's really not great. [09:00] rogpeppe1: we are working on improving it, there are still some intermittent failures [09:01] axw: it would be great if it was possible to tell jenkins "please kill this job now - i know it's going to fail" [09:01] hmm yes, that would be nice... [09:04] axw: even with intermittent failures, it might still be better if it didn't retry automatically [09:04] axw: then at least the person responsible can look at the failure and see if it looks like it's correctly intermittent, or if it's just a bad test [09:05] initially it was so bad that we had to, but now, yeah, I think you may be right [09:07] right, hoping for 5th time lucky [09:09] dimitern: your branch failed to merge: tmp.ZRpISWCH5X/RELEASE/src/github.com/juju/juju/juju/testing/instance.go:119: undefined: includeNetworks [09:10] dimitern: (i can't say i'm unhappy because if yours had succeeded, mine would probably have failed. again) [09:10] rogpeppe1, yep, some merge didn't go well i'm fixing it [09:11] axw: hmmm... maybe my Friday project can be to diagnose this [09:11] heh :) [09:12] well it sure is mystefying, so it's gotta be educational if you can figure it out [09:12] right [09:12] not useful education, but education none-the-less ;-) === vladk|offline is now known as vladk [09:36] i love my ISP [09:36] ssh: Could not resolve hostname github.com: Name or service not known === vladk is now known as vladk|offline [10:01] rogpeppe1: stop using their dns? [10:02] voidspace: i think it's just the whole thing's flaky. i get random delays, even when i'm not using their dns [10:34] dimitern: provider/ec2/local_test.go:359: too many arguments in call to "github.com/juju/juju/juju/testing".StartInstanceWithParams [10:34] rogpeppe1, just fixed that, but I can't stop the ci job [10:34] mgz: would it be possible to turn off the automatic test retry on the bot? [10:34] mgz: it's taking over an hour to process a commit with a test failure [10:36] rogpeppe1: maybe [10:36] I ill at least cut down to two I think [10:37] we have still got bogus failures [10:37] mgz: i think one would be better [10:37] mgz: we've got to look at the failure status anyway [10:38] mgz: and it takes 18 minutes to process a job if all goes well [10:38] mgz: but doubling that when a test fails seems wrong [10:38] I prefer to inconvience on failing test run, rather than on good branhc that hits a random issue [10:39] mgz: it inconveniences everyone though [10:39] mgz: i've spent the entire morning waiting for the bot [10:40] mgz: can we *try* not retrying [10:40] ? [10:40] mgz: and if the sporadic failures turn out to be a real problem, going back to retrying [10:41] mgz: alternatively, try to diagnose the sporadic failures and only retry if it looks like one of those [10:41] and I can't merge my PR for 2 days because everything keeps changing across the codebase - imports mostly [10:41] dimitern: yeah, sorry about that [10:41] dimitern: nothing i can do to help about that, but it does mean that we *can't* submit PRs that will definitely work [10:42] dimitern: because we have fundamentally clashing branches [10:42] rogpeppe1: we've already had runs that have only landed successfully because of the retry [10:42] see build 34 for instance [10:43] mgz: any other examples? [10:43] I'mm trying to find the graph thingy [10:44] mgz, we need accounts on the jenkins ci instance for cases like this - stopping a build that'll never succeed [10:44] dimitern: we don't really [10:44] we just need our tests to not be so flakey [10:44] then 10-15mins for a run is fine [10:44] and the retry logic can detect build failures and do not attempt to retry [10:46] juju-ci.vapour.ws:8080/job/github-merge-juju/buildTimeTrend [10:46] I've changed the job to do a single retry, it should fail in around 30-35 mins now [10:46] haha :) beat you to it rogpeppe1 :) [10:46] sorry about that [10:46] dimitern: frick [10:47] #36 #23 #21 all required the rerun [10:47] mgz: could we please change it to no retries at least for today [10:47] ? [10:48] mgz: because dimitern and i are conflicting and we're constantly watching the jobs and a failing job can double the time we're going to need for all this overhead [10:48] rogpeppe1: I feel you two could work out a better solution between yourselves.. [10:49] but okay, I'll put it back in after y'all have sorted out your mess [10:49] good morning everyone [10:50] mgz: so, all those intermittent failures failed with "panic: Session already closed" [10:50] rogpeppe1, I think changes like this (extracting a dependency and changing all imports) is very frustrating to deal with, especially when they are several like that in a row [10:50] mgz: wouldn't it be possible to see that and retry only in that case? [10:50] dimitern: yeah, particularly when the dependency is widely used [10:50] perrito666: hiya [10:51] crazy internet today :-/ [10:51] yeay rural england? [10:51] mgz: yeah, and yay talktalk [10:51] rogpeppe1, we should've handled that better - announce it on the ML, perhaps pick a day to do a few of these in sequence, so it can be expected and we can fix our PRs after that [10:52] rogpeppe1: got a minute to help me diagnose a problem? [10:52] voidspace: sure [10:52] voidspace: yay talktalk :-\ [10:52] yeah [10:52] dimitern: missed our hangout, but now nobady is there. has it already been? [10:52] voidspace: my talktalk connection is really crappy today too [10:53] voidspace: do you have slow/crappy DNS issues too? [10:53] rogpeppe1: heh, maybe coincidence maybe not === vladk|offline is now known as vladk [10:53] rogpeppe1: I don't use their DNS [10:53] voidspace: 8.8.8.8 ? [10:53] TheMue, i haven't bothered today :) my bad - we can still do it, though if we need [10:53] rogpeppe1: this test passes [10:53] http://pastebin.ubuntu.com/7601025/ [10:53] rogpeppe1: but note the 20 second sleep [10:53] * dimitern is not ipv6 capable :) [10:53] without that it fails [10:54] dimitern: I’ve got nothing special, so it’s ok for me to not do it [10:54] ;) === vladk is now known as vladk|offline [10:54] my shiny new hurricane electric tunnel just works [10:54] (after a few issues resolved) [10:54] rogpeppe1: without it state.Open fails with [10:54] ... value *errors.errorString = &errors.errorString{s:"no reachable servers"} ("no reachable servers") [10:54] rogpeppe1: so I need some way of polling for when mongo is ready [10:55] I suspect it is waiting for replica set initiation [10:55] who's most git-savvy around? [10:55] voidspace: does it work if you increate the DialOpts timeout to 30s from 10? [10:55] dimitern: me! *chortle* [10:55] rogpeppe1: ah... [10:55] i have this issue almost every time i need to push changes from a PR branch after fixing stuff/review comments === vladk|offline is now known as vladk [10:56] it tells me Updates were rejected because the tip of your current branch is behind [10:56] rogpeppe1: it's set to testing.LongWait [10:56] how can my local branch be behind my origin/samebranch ? [10:56] rogpeppe1: which is ten seconds [10:56] voidspace: exactly [10:56] rogpeppe1: should I create a VeryLongWait ? [10:56] or hard code 30 seconds? [10:56] voidspace: just hardcode it [10:56] ok [10:56] what do you guys use as a workflow? we need to document it somewhere more extensively === vladk is now known as vladk|offline [10:57] voidspace: is that git complaining? [10:57] voidspace: when you try to do the push? === vladk|offline is now known as vladk [10:57] oops [10:57] dimitern: ^ [10:57] (i.e. more than what you do initially, but also how you do specific steps) [10:57] rogpeppe1, yep [10:57] dimitern: are you rebasing before pushing? [10:57] rogpeppe1, the only way i found around it is push -f [10:58] rogpeppe1, sometimes, but not always [10:58] dimitern: if you rebase, you'll have that problem [10:58] rogpeppe1: that passes [10:58] ship it! [10:58] rogpeppe1: thanks [10:58] dimitern: if you don't, you should not [10:58] dimitern: i've stopped doing any rebasing [10:58] dimitern: after the discussion on juju-dev [10:59] rogpeppe1, without rebasing you get a lot of pollution in the commit log [10:59] dimitern: if you're going to rebase, then do it a) before starting the review and/or b) just before sending the $$merge$$ message [10:59] rogpeppe1, like your PR might land from a branch which last commit was "Fixed merge conflicts", which you'll see in the upstream master commit log, rather than your nicely formatted commit message [10:59] dimitern: but i think i'd go with just the former [11:00] dimitern: yup [11:00] dimitern: this is the world we've moved into [11:00] rogpeppe1, i really don't like that [11:00] dimitern: if you rebase you'll have to push -f [11:00] dimitern: because push will only step forward in time [11:01] rogpeppe1: I already had an LGTM, the only change I've made since is increased that timeout [11:01] rogpeppe1, there has to be a better way to have both sane commit logs eventually and the ability to go over a reviewed branch fixing stuff [11:01] rogpeppe1: so I'm going to merge, unless you want to take a look first... [11:01] dimitern: rebase just before sending the $$merge$$ message [11:01] voidspace: sgtm [11:01] rogpeppe1: thanks [11:02] dimitern: but as discussed on juju-dev, you can still see sane commit logs even when all commits go in [11:02] dimitern: and i'd prefer not to all the extra overhead of rebasing [11:02] s/not to/not to add/ [11:02] I think it's worth not rebasing if we still have a way to see sane logs of all the merges going in [11:02] natefinch: +1 [11:03] rogpeppe1, how's that going to work? [11:03] natefinch: morning [11:03] fwereade: ping [11:03] voidspace: morning [11:03] rogpeppe1, examples? [11:03] voidspace, pong [11:03] dimitern: see the juju-dev thread [11:03] dimitern: called not rebasing after PR === vladk is now known as vladk|offline [11:04] rogpeppe1, natefinch, will do, thanks [11:18] can anyone thing of a particular reason why juju/testing/charm.go should not live inside charm/testing ? [11:18] s/thing/think/ [11:20] it doesn't seem like it should live in github.com/juju/testing, to my mind [11:20] although... i suppose we could move charm/testing into github.com/juju/testing/charmtesting [11:20] jam, jam1: ^ [11:27]