=== kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away [07:24] Bug #1442493 was opened: Openstack services failing on 1 node while deploying using JUJU [07:26] TheMue: morning! o/ [07:27] dooferlad: morning o/ [07:27] TheMue: Could you review this for me? http://reviews.vapour.ws/r/1406/ [07:28] dooferlad: so the sapphire group is complete for today ;) [07:28] TheMue: yep! [07:28] dooferlad: yes, will do [07:28] TheMue: thanks [07:38] dooferlad: uff, reading the bug is longer than the fix :) [07:39] TheMue: the effort of testing it on EC2 was larger than that by many times. MAAS just worked. Our lack of support for when there is no default VPC really screwed me over [07:39] dooferlad: do you know why this SNAT rule has been in there? so doesn't its removal crash something? [07:39] TheMue: not that I have found. [07:41] dooferlad: hmm, ok. here I definitely need some good networking lessons to get more safe in understanding it [07:41] TheMue: I am sure I can arrange that :-) [07:42] dooferlad: would be great. in my past I mostly have done typical business software, absolutely different area ;) [07:43] dooferlad: you've got you ship it [07:43] TheMue: thanks! [07:44] yw [08:13] * fwereade out for an hour or two [09:00] TheMue: hangout? [09:01] dooferlad: coming, just had phone [09:05] this PR removes the testing deps from the production juju code: http://reviews.vapour.ws/r/1407/ [09:05] reviews appreciated (it's pretty trivial) [09:05] rogpeppe1: will do after hangout [09:06] TheMue: ta! [09:30] TheMue: http://reviews.vapour.ws/r/1408/ is very similar to the last change :-) [09:30] *click* [09:32] dooferlad: thinking you're right, so ship it. alternatively %T is also valid, but no combination [09:33] dooferlad, TheMue: there's nothing wrong with %#T [09:33] http://play.golang.org/p/8XAOJVdeO2 [09:34] natefinch: why would you use %#T - it's identical to %T [09:35] rogpeppe1: because I always forget it's the same [09:35] natefinch: rogpeppe1: %#T is not documented, and %#v and %T behave different in showing also the values with %#v [09:36] Bug #1442541 was opened: hook name ommitted using juju-log [09:36] hmm, does vet complain about it? [09:37] TheMue: %T is the correct fix then. I just got done fixing that error message so it *didn't* use %v. It's doing type checking, so it should print out the type if it's incorrect, not the error's string, which doesn't tell you anything. [09:37] dooferlad: ^ [09:38] natefinch: ic, so dooferlad, fix it, then ship it ;) [09:38] dooferlad: and thanks for fixing my go vet mistake [09:42] natefinch: no problem - shame I didn't ask you what your intention was before the first review :-) [09:45] dooferlad: np :) [09:51] dooferlad: $$merge$$, not %% [09:52] TheMue: darn it! [09:55] dooferlad: no wonder, after all this %... discussion [10:07] natefinch: looks like go vet doesn't like the %#T [10:08] mgz: ping [10:15] natefinch: i think in the place you've used it, %#v would be a better bet, as if the test fails you really want to see the actual value there not just the type [10:15] rogpeppe1: very true [10:16] natefinch: the test isn't doing type checking, it's doing value checking, BTW [10:16] anyone have any idea how this build failure might be happening? http://juju-ci.vapour.ws:8080/job/github-merge-juju/2845/console [10:17] Extant directories unknown: [10:17] gopkg.in/juju/charm.v5 [10:17] rogpeppe1: regardless, printing out the string value of the error is quite a bit less than useful [10:17] i'm presuming that's the reason for the build failure, not the vet message: apiserver/server_test.go:88: unrecognized printf flag for verb 'T': '#' [10:17] natefinch: that's why i'd use %#v [10:17] rogpeppe1: yep [10:18] natefinch: the string value is almost certainly going to be more useful than just the type though [10:18] natefinch: which will usually be just *errors.Err [10:19] rogpeppe1: let's just agree that %#v is the correct fix :) [10:19] natefinch: :) [10:19] dooferlad: is that code already committed? [10:19] natefinch: yes [10:20] natefinch: as %T [10:20] I did wonder about %T: %#v... [10:21] dooferlad: %#v includes the type...%#v is basically %T with %v [10:21] well.. no that;s a bad description [10:23] dooferlad: %#v prints out the value as if it were go code to construct the value [10:23] dooferlad: http://play.golang.org/p/6HKt-7atpL [10:24] except of course, ignore the "type:" string on the beginning of each line, since that was just copied from the old text I had in there [10:24] fixed example: http://play.golang.org/p/FtEYRp1dJS [10:24] I need to stop trying to explain things before 7am [10:25] natefinch: no worries :-) [10:25] natefinch: actually the merge job failed, so I can easily switch back to %#v if you like [10:26] dooferlad: yes please :) [10:31] rogpeppe1: about that error in the console... note that error message is looking for gopkg.in/juju/charm.v5, not gopkg.in/juju/charm.v5-unstable [10:31] natefinch: yes, i think i know what's going on now [10:32] natefinch: i've updated that branch to change everything to use charm.v5 [10:32] natefinch: which should fix the issue (although it makes that branch quite a bit bulkier) [10:32] natefinch: i've also changed it to fix your %#T thing [10:33] rogpeppe1: I think dooferlad is making the %#v fix, though I suppose it can't hurt [10:33] rogpeppe1: hey [10:33] mgz: hiya [10:33] mgz: too late! :) [10:33] you're just loving breaking deps at the moment [10:34] mgz: it's one of my favourite activities [10:34] well, at least this one was an actual catch by the bot [10:34] mgz: not really [10:34] mgz: it's actually a bug in godeps [10:35] mgz: because godeps uses go get to fetch new deps [10:35] mgz: and there's no way to tell go get not to fetch recursively [10:35] yeah, which just pulls in everything [10:35] mgz: so really i think godeps needs to fork the go get vcs fetch functionality [10:35] so, tells you to fix the imports, no? [10:35] mgz: no, the imports are right [10:36] rogpeppe1: I agree with that though, we need to not go get really [10:36] mgz: the problem is that the tip of the repo has a different set of deps from the dep we wanted to use [10:36] rogpeppe1: ah, that one again [10:36] er... i can sort that for now I guess [10:37] mgz: i'm fixing it my updating to use the latest deps [10:37] I have a flip that just removes unkniwn deps rather than complaining, and assumes that if things build the godep stated deps were in fact the intended ones [10:37] mgz: the branch was all about updating deps anyway [10:37] fair enough [10:37] mgz: so here's the branch, updated (and now huge 'cos of all the import path changes): http://reviews.vapour.ws/r/1407 [10:39] mgz: if i want to change the description of a PR, should I do it in reviews.vapour or in github ? [10:39] rogpeppe1: well, reviews is the one people read [10:39] mgz: i care mostly about the commit log message [10:40] I guess change on github then [10:41] * rogpeppe1 $$merge$$s === rogpeppe1 is now known as rogpeppe [12:00] mgz: https://go-review.googlesource.com/#/c/8725/ [12:00] mgz: it won't fix it for now but sometime in the future, i hope [12:00] mgz: (assuming it's accepted) [12:35] fwereade, rogpeppe is one or both of you packing dominion? [12:36] mattyw, I will surely pack a set or two [12:36] mattyw, hopefully so will rogpeppe or dimitern as well [13:13] fwereade: i definitely intend to bring some, probably seaside, prosperity, maybe intrigue too [13:14] rogpeppe, intrigue is probably my favourite -- hopefully dimitern will bring his :) [13:14] rogpeppe, any of mine you'd be particularly interested to see? [13:14] TheMue: Another review for you... http://reviews.vapour.ws/r/1400/ [13:15] fwereade: i haven't played many real life games with alchemy, and dark ages is always good [13:15] rogpeppe, I don;t have alchemy actually -- I'll probably go with hinterlands/dark ages [13:15] fwereade: sgtm [13:17] fwereade: BTW i came across your recent dependency engine thing - cool stuff! [13:17] rogpeppe, glad you like it -- it borrows heavily from worker.Runner [13:17] fwereade: i like that it fits in with the worker framework too [13:18] rogpeppe, and I *suspect* will come closer still to it as I need to cover some of the more baroque cases I want in jujud [13:18] rogpeppe, yeah, absolutely, the worker approach has been fantastic -- it's just organising them clearly where we've really fallen down [13:18] fwereade: i still don't quite understand the overall motivation behind it mind [13:19] rogpeppe, I want to run something to take over some of the uniter's responsibilities when certain resources (like an api conn) are not available [13:19] fwereade: the output value thing could probably do with a little more documentation [13:20] rogpeppe, the thought of coordinating two distinct workers that ran at such very different levels made me cry [13:20] rogpeppe, noted, thanks [13:21] fwereade: i found the term "manifold" somewhat opaque; was this the meaning you had in mind "a manifold is a topological space that resembles Euclidean space near each point. More precisely, each point of an n-dimensional manifold has a neighbourhood that is homeomorphic to the Euclidean space of dimension n" [13:31] ? [13:32] rogpeppe, no, it's a mechanism with pipes going in and oout of it [13:32] fwereade: ah "a chamber having several outlets through which a liquid or gas is distributed or gathered." [13:32] fwereade: not a term i'm familiar with [13:33] fwereade: (which isn't to say that it's not entirely appropriate!) [13:33] rogpeppe, I could swear I made a point of documenting that... [13:33] / Manifold defines the behaviour of a node in an Engine's dependency graph. It's [13:33] / named for the "device that connects multiple inputs or outputs" sense of the [13:33] / word. [13:34] fwereade: ha, i evidently skipped over that :) [13:34] rogpeppe, ;p [13:45] katco, dooferlad : the commit that reverted the container SNAT rule in 1.23 may be causing aws bundle tests to fail exactly like bug 1441319 [13:45] Bug #1441319: intermittent: failed to retrieve the template to clone: template container juju-trusty-lxc-template did not stop

[13:45] * sinzui tries to get container log [13:47] sinzui: no, that is because we don't support container cloning. [13:47] dooferlad, this test passed on the previous version on 1.23 and we know the landscape bundle we are deploying hs not changed [13:48] dooferlad: just seen your message, reviewing it now [13:48] this test passed on joyent and maas 1.7 and hp cloud [13:48] sinzui: it was also reported before the SNAT rule change was reverted [13:49] dooferlad, not be CI and not with 1.23 [13:50] dooferlad, Until your commit, CI has never seen this error. This test is voting, so 1.23 will not be blessed for a release. I need to get more information about what is wrong. [13:57] sinzui: OK, the only thing that should have changed in terms of what other machines see, is that traffic from containers comes from the containers IP address, not the host machine's address. This used to be the case before rev b584fcb85b9bcce3dadba97d32fe50e8f3680e40 [13:57] on that commit we added an SNAT rule to modify all traffic leaving a container host to look as if it came from that host [13:58] dooferlad, yes, I agree and this test was happy when that change was made. I don't know why but would appear. could there have been another change made inconjuction for aws [14:01] * natefinch almost doesn't know what to do now that the HA code finally made it in. [14:03] sinzui: so it worked OK on the 8th after the proxy change? That would seem more likely. [14:03] dooferlad, yep [14:04] sinzui: what would you say is the correct behavior for this bug? https://bugs.launchpad.net/juju-core/+bug/1441904 just failing? [14:04] Bug #1441904: juju upgrade-juju goes into an infinite loop if apt-get fails for any reason

[14:05] natefinch, yes, say it failed [14:05] sinzui: wonder if we should retry a few times in case of network problems etc [14:07] natefinch, I thought all apt calls were retried 3 times. dimitern fixed an issue a few months ago where juju wasn't retrying [14:08] sinzui: hmm.. good question, I can check, I don't know offhand [14:15] katco, I added the container.log you requested on https://bugs.launchpad.net/juju-core/+bug/1441319 [14:15] Bug #1441319: intermittent: failed to retrieve the template to clone: template container juju-trusty-lxc-template did not stop

[14:16] sinzui: ty... that's from the machine that failed? [14:17] katco, no larry's. the latest commit to 1.23 broken the aws deployer test in CI [14:18] sinzui: confused... isn't larry the one who reported the failure? and this is the one we're thinking is intermittent? [14:18] katco, yes, but now CI is affected. I am providing a log [14:18] sinzui: ah ok. so we're sure it's the same issue? [14:19] yep. we can reproduce it on command with 1.23 tip deploying the landscape bundle to aws [14:19] I have 5 failures [14:19] sinzui: i thought larry's issue was an lxc container problem... [14:19] * katco apologizes if she's being dense [14:20] rogpeppe, fwereade: FWIW, I have Alchemy, it's just not that great, so I kinda hesitate to lug it 3000 miles :) [14:21] natefinch: i've quite enjoyed it on occasion in Androminion [14:21] katco, oh, sorry, my error is not the same. I will report another bug. [14:22] sinzui: k, thanks for walking me around the block on that one [14:22] it looks like that container is having problems because of apparmor. The peer has disconnected message is because https://github.com/dotcloud/lxc/blob/master/src/lxc/af_unix.c -> lxc_af_unix_rcv_credential is failing. [14:22] sinzui: still working on some caffeien here :p [14:22] caffeine even [14:22] katco, thank you for questioning me. I am low on caffeine. [14:22] sinzui: a toast! [14:23] rogpeppe: at least it's small. I could probably leave the box at home and it would be less of a big deal. [14:23] dooferlad: are you refering to 1441319? [14:23] katco: yes [14:24] dooferlad: which log on that bug? [14:24] katco: https://bugs.launchpad.net/juju-core/+bug/1441319/+attachment/4371597/+files/container.log (the last attachment, from sinzui) [14:24] Bug #1441319: intermittent: failed to retrieve the template to clone: template container juju-trusty-lxc-template did not stop

[14:25] dooferlad: ah ok. so that will be relavant to sinzui's new bug he's opening, not 1441319 [14:25] katco: yea, indeed [14:25] relevant even [14:25] jees with the spelling this morning [14:29] dooferlad, can you work iwth sinzui on a bug as a result of your lastest commit [14:33] alexisb: sure [14:33] and dooferlad I just finished reading the backscroll :) [14:35] dooferlad, katco sorry, more caffeine and CI's error is the same as oil's 'failed to retrieve the template to clone: template container [14:35] "juju-trusty-lxc-template" did not stop' [14:35] instance-id: pending so https://bugs.launchpad.net/juju-core/+bug/1441319 is the issue [14:35] Bug #1441319: intermittent: failed to retrieve the template to clone: template container juju-trusty-lxc-template did not stop

[14:37] sinzui: that's actually great! repeatable! [14:49] TheMue: thanks for that review. Fixes commited. [14:54] anyone have an opinion on the best way to get a PR merged into master into the 1.23 branch? I could re-PR to 1.23, or I could cherry-pick from master to 1.23... not sure which was is "better" (or if there's a better third way) [14:56] mgz: ^ any thoughts? [14:56] (should say "to get a PR that was merged into master, into the 1.23 branch" [14:59] sinzui: for the record, we try apt installs *30* times, with 10 second delays between each. Wowza. [14:59] natefinch, well we tried. juju can admit it failed [14:59] natefinch: i always like to cherry pick from master, but that's just my workflow [14:59] natefinch: if it's important that it be done fast for 1.23, land it there first and forward port [15:00] sinzui: yep, it shouldn't be a big deal to have the error from apt-get just tell the command to fail. If it doesn't work after trying for 5 minutes, it's not going to work. [15:00] katco: I thought forward porting was the new normal. Maybe just for Saphire. [15:00] no, we're supposed to land on 1.23 first and forward port ,from what I remember... I just did the wrong thing [15:00] dooferlad: could be? i don't think it really matters... isn't it personal preference? [15:01] katco: I don't think it really matters, which is not the same as saying no one cares ;) [15:01] natefinch: hey. you paint that shed blue dammit. [15:03] I have an email from alexisb about making sure to land on stable and then forward port to master.... but it was only sent to me and wwitzel3, but I think that's The Way It's Supposed To Be™ [15:17] natefinch, bug 1394755 says it is fixed in 1.23, but I don't see the commit. I do see the commit in master though [15:17] Bug #1394755: juju ensure-availability should be able to target existing machines

[15:22] Bug #1436863 was opened: test failure replicaset_test.go:52: SetUpTest.pN42_github_com_juju_juju_replicaset.MongoSuite

[15:31] sinzui: working on that, sorry [15:36] katco: how do I cherry-pick the PR without listing out the 37 commits? Picking just the merge commit says I'm missing -m, and using -m says it expects a numerical value, but I have no idea what the number should be [15:37] also probably doesn't help that I have merge commits from master into that branch... sigh [16:04] mgz, can your review http://reviews.vapour.ws/r/1409/ [16:05] natefinch: sorry i was in a meeting [16:06] natefinch: i am the worst person to ask for advice on git, because i use an emacs mode which does it all for me [16:06] katco: haha no problem [16:06] sinzui: on it [16:06] katco: I think I'm getting it. I just ended up doing a cherry pick of all ~34 non-merge commits [16:07] sinzui: lgtm, hold till when you need it [16:07] thank you mgz [16:13] natefinch, "git help -a" should have what you are looking for [16:13] though I must admit that it has been a long time since i have done a kernel patch and used git [16:15] alexisb: git help doesn't always. [16:15] alexisb: you used to work on the linux kernel? [16:15] yes mam [16:15] alexisb: that's awesome! [16:16] alexisb: I thought i had it, but somehow my cherry pick left this branch in a bad state... some code referring to packages that don't exist. Sigh. [16:16] it was fun, there are days I think about going back :) [16:16] alexisb: nooo! we need you! [16:17] katco, it has been long enough I would have to really work to get back into it, my last public commit was in 2008 I believe [16:17] alexisb: I'm sure it's mostly the same ;) [16:18] natefinch, I have paused CI because I have a change merging now, and I don't want CI to be busy when you change arrives [16:18] sinzui: thanks, I guess. I don't know that my change will make it in terribly soon, given the troubles I'm having with git, and I need to go pick up my daughter from preschool in 20 minutes [16:19] :( [16:19] natefinch: is it checked into 1.23? [16:19] natefinch, I assume CI will take 3 hours to test my version change. [16:20] katco: no, it's in master, that's the problem... I developed it off of master, merged master into my branch a couple times, and then PR'd into master [16:20] natefinch: so you're trying to backport? [16:20] katco: yes [16:20] natefinch: what's the commit hash? [16:21] katco: b228e89dd3ef9a3fe0f14b958db123e87a68bc48 [16:22] katco: I presume there's some magic command line that'll do the right thing... but I'll be damned if I can figure it out. [16:22] natefinch: from what i can remember, it's not a single command [16:22] natefinch: you set cherry head, and upstream [16:22] natefinch: and then start picking commits [16:25] natefinch, katco if we have someone that can help out natefinch on this that would be great [16:25] we gotta get 1.23 out [16:25] alexisb: i am backporting now [16:28] Bug #1258485 changed: support leader election for charms [16:29] natefinch: ptal: http://reviews.vapour.ws/r/1410/ [16:29] natefinch: especially make sure i didn't mess up the merge [16:31] katco: hmm.... I think I must have given you the wrong hash.... that's not what needed to get ported... well, that may still need to get ported, but that's not all of it [16:31] natefinch: is there more than one commit? [16:31] katco: there's two different merges... one is the test fixes and one is the HA --to code [16:32] natefinch: k i'll pull the other commit too [16:33] katco: there's Merge pull request #1962 from natefinch/ha3 which contains 37 commits :/ [16:33] natefinch: k tal [16:34] it is possible to charrypick an entire merged branch with git, I don't recall the spelling off the top of my head [16:35] mgz: it's the spelling that I'm not sure of... plus the branch contains commits that are merges from master to that branch, which would contain changes that shouldn't go into 1.23 (presumably) [16:35] natefinch: right, but the diff from merged to master commit vs previous commit to master should be the right thing [16:37] so the dumb version is just take that diff and apply it, but cherry-pick does have a one-step of that [16:37] mgz: I would think so, but I'm always disappointed in what vcs figures out on its own [16:38] git just doesn't record mainline, so talking about three-way merges in the commandline is more annoying [16:38] unfortunately, I gotta run to pick up my daughter.... I'll be back in like an hour. That's about the best I can do. [16:44] gosh... it's going to be hard for me to merge this much in without knowing anything about what i'm merging [16:48] katco: how conflicty is the `git cherry-pick -m `? [16:56] natefinch, mgz, I think I had to use patch or format-patch once [16:58] mgz: 47 unmerged files [16:59] Bug #1442719 was opened: juju sync-tools fails

[16:59] mgz: i (or rather emacs) ended up doing "git --no-pager -c core.preloadindex=true merge master~2 --no-commit" [17:01] hm, I wonder if that's actually right without specifying the mainline? [17:01] mgz: i'm merging it into a branch off of 1.23 upstream [17:02] maybe the ~2 just happens to be resolving right on sha1 alpha order [17:02] mgz: it is; that's emacs doing magic [17:02] mgz: i found the merge master hash, hit m and it does the right thing [17:02] mgz: i would hate doing all of this manually [17:03] mgz: which is to say via the command line [17:03] well resolving conflicts is always going to need an editor [17:03] you can use an OS if you want :P [17:03] mgz: haha [17:03] mgz: i'll show you this workflow in nuremberg. it's quite nice [17:04] neat [17:04] mgz: merge dumps me into a buffer with all merge conflicts. pressing "e" on an unmerged file dumps me into a visual diff [17:04] mgz: and i hit "a" or "b" depending on which side i want. and can edit in 3rd pane at bottom [17:05] alexisb: i can't perform this backport. i don't know enough about the patch to perform the requisite merges. [17:05] katco, just fyi, the juju-core leadership team advocates the process of forward porting as juju has historically seen more issues with back porting then forward porting === psivaa_ is now known as psivaa-afk [17:05] katco, ack, we will have to wait for natefinch then [17:05] alexisb: ok, duly noted. [17:05] as wwitzel3 is traveling [17:06] mgz, sinzui if need be we will have to add the HA working in a point release [17:07] sinzui, mgz, dooferlad, where are we with the aws container failure? [17:08] alexisb, If Ubuntu deem the patch to be a feature, they will not accept it. natefinch is the patch more like a bug than a feature [17:10] sinzui, in many of the "bugs" we fix for stakeholders there is a fine line between feature and bug [17:11] I see your point, but thought we had decided this was a bug [17:12] alexisb, yes, and Ubuntu doesn't honour that line they have reject our streams change in 1.20 and our right refused to package the backup/restore changes to 1.16.4 [17:14] katco, get with natefinch when he is back and lets get this merged [17:14] sinzui, I see this impacting our ability to deliver by weds [17:14] sinzui, where do we stand on the aws failure mentioned this morning? [17:14] No progress. [17:15] alexisb, and this bug was just moved to juju-core https://bugs.launchpad.net/juju-core/+bug/1439535 [17:15] Bug #1439535: 1.23-beta2 websocket incompatibility

[17:16] ^ There are contradictions about beta3 being affected [17:16] so sinzui adding bugs is not helping get the release out :) [17:17] so lets start with the bug from this morning, what does no progress mean? [17:17] is there no one from core looking at it? is there something blocking us from debugging the issue? [17:18] alexisb, neither katco or dooferlad have asked for more information from me after I provided the log that was requested. [17:18] alexisb, I am at a critical moment in the release, so I cannot let myself get too distracted [17:19] sinzui, that is fine, I understand [17:19] dooferlad, are you still around? [17:19] alexisb: just. In the middle of feeding the baby [17:20] :) that is a fun task [17:20] I know it is close to your eod but have you had a chance to take a look at the logs sinzui provided [17:21] alexisb: As I said above, the failure seems to be to do with LXC and apparmor having a bad interaction. [17:21] alexisb: and I haven't touched code anywhere near that [17:22] dooferlad, ack, katco is this similar to the issue you looked at earlier this week? [17:22] alexisb: yeah... looks to be exactly the same [17:23] which we determined was not a juju issue, correct? [17:23] dooferlad, really. great. let me check to see if an apparmor change was delivered to trusty in the last day ( and see if the aws mirrors are our of sync [17:24] alexisb: we were leaning that way because we hadn't touched the code in that area; however, sinzui indicated that a commit caused this to be repeatable? [17:24] dooferlad: or was sinzui saying the change was your commit? [17:24] dooferlad, katco. apparmor did change last week: [17:24] 2.8.95~2430-0ubuntu5 release (main) 2014-04-04 [17:25] sinzui: if we haven't done any commits that touch that area of code, i'm blaming that [17:25] We have testing this week that says aws was fine, but let me see if I can find evidence that the mirrors are stale [17:25] sinzui: i apologize, i still don't understand the connection between aws and an lxc issue? [17:26] katco, I am sorry about the situation [17:26] sinzui: i'm assuming that i'm missing something; nothing to be sorry for [17:30] OK all, see you in Germany! [17:30] dooferlad: see you there! [17:31] katco: back [17:31] mgz: here's the start of the fix to godeps - copying a bunch of code from the go tool: https://codereview.appspot.com/223390043/ [17:32] natefinch: hey, i can't backport that change... there are too many merge conflicts i don't understand [17:32] katco: I was worried about that [17:33] rogpeppe: neat! I had a look at your get upstream change earlier, that seems like a good idea regardless [17:39] natefinch: try "git --no-pager -c core.preloadindex=true merge master~2 --no-commit" but tweak the ~2 to point to the correct merge hash for your branch of master [17:40] katco: man, how did I miss something so obvious? [17:40] natefinch: (shrugs) it's easy to get blinders on that you have to cherry [17:41] natefinch: obviously you dont use emacs, there most likely is a shortcut for that, smth like: Ctrl-M gnpccptmmnc2 [17:41] perrito666: lol i put my cursor over the merge hash and pressed "m" [17:41] some of those command line flags are probably superfluous [17:42] * katco somewhat embarrassingly just realized natefinch was joking. [17:42] katco: how do I figure out the number after ~? That stuff confuses the hell out of me [17:42] katco: lol yes [17:42] natefinch: it's just an offset from head [17:43] natefinch: so however many commits back from head that merge hash is for you [17:43] katco: you say that, but sometimes ~2 brings in like 1000 changes if you've done a merge [17:43]