=== kadams54 is now known as kadams54-away [05:43] morning folks, I get the following error in the tip of juju/errors - is it just me or can someone else see it? [05:43] ^^ not gccgo [05:44] mattyw: what error? [05:44] anastasiamac, ah - dammit - sorry forgot to past the paste :/ [05:44] anastasiamac, http://paste.ubuntu.com/10085832/ [05:44] anastasiamac, sorry - it's still early (1:44pm) [05:48] mattyw: m running with juju/errors that juju/juju depended on yesterday [05:48] mattyw: and get [05:48] mattyw: ok github.com/juju/errors 0.008s [05:49] anastasiamac, what version of go? [05:49] anastasiamac, (starting to clutch at straws now :) ) [05:50] mattyw: go version go1.2.1 linux/amd64 [05:51] anastasiamac, ok - I might try running an earlier version and see what happens, it's not blocking me, just an observation [05:51] I'll keep an eye on it though [05:51] :D [09:41] davecheney, done https://github.com/juju/errors/pull/16 [10:08] dimitern: nice logo :) [10:08] axw, :) it took 15m [10:08] axw, yeah I think goose deserves a logo now heh [10:10] katco: FYI, https://github.com/go-goose/goose [10:10] dimitern: katco has some Cinder support in the works [10:11] dimitern: and what she's doing is auto-generating bindings off WADL provided by OpenStack. may be useful to use more generally [10:13] axw, oh, ok - I'll sync up with her next week then [10:13] my current plan is to just migrate existing trunk to GH and change imports to use gopkg.in [10:18] axw, katco ^^ [10:18] dimitern: no worries, that's what I expected [10:19] axw, ok, cheers [10:19] we'll use gated merges as well with the bot like for juju/juju [10:20] dimitern: not using Travis? [10:24] axw, nope, I really don't want to, if it can be avoided [10:24] okey dokey [10:24] axw, our merge bot does a more consistent job I think [10:25] (a bit of handwavyiness here ofc.. :) [10:25] dimitern: I'm happy with that, was just wondering if this would be handled the same as go-amz [10:30] axw, I got bashed a bit for taking this decision frankly (travis over our bot) and want to do it "properly" this time :) [10:30] dimitern: I see :) [12:00] dimitern: morning, I was looking at this regression we have on the GUI: bug 1418433 [12:00] Bug #1418433: unit information pane lost port information [12:01] dimitern: it seems that newer versions of juju-core no longer populate the unit ports in the mega-watcher. unitDoc.Ports is also marked as no-longer used, but it's still used by the mega-watcher [12:03] dimitern: note that this breaks API backward compatibility [12:16] frankban, hey, I was afk for a while, reading back [12:17] frankban, unitDoc.Ports is no longer there (or at least no longer used) [12:18] frankban, but i'll have a look to recall what should've be used instead [12:18] dimitern: it's no longer populated, and assumed to be no longer used, but instead it's still used by the megawatcher for units [12:18] dimitern: and therefore it's always empty [12:19] dimitern: I guess we should use unit.OpenedPorts(), but that would still be a backward incompatible API change [12:19] dimitern: because the ports are now ranges (FromPort/ToPort) while before they were just numbers (Number) [12:20] frankban, fair point [12:21] frankban, we should fix this to be wire-format-compatible [12:22] frankban, but by doing this we'll lose some precision - if from=to port, that's fine, if not - what? [12:22] dimitern: we could make the mega-watcher use an ad-hoc function that return a slightly different slice of port ranges, in which we have both the From/To and the Number, in the case From==To [12:22] frankban, and the gui should definitely use unit.OpenedPorts to get them [12:23] frankban, I mean .. it should expect port ranges at least [12:23] dimitern: the GUI uses the mega-watcher to get them, so we need to modify the mega-watcher to call OpenedPorts, and then maybe modify the result as I described [12:23] frankban, ah, that's a good idea - adding PortRanges to the MW changes struct for units [12:24] dimitern: yes, we need a fix to the GUI too, but introducing a Number in the struct returned by the mega-watcher would make it easy for the GUI to be backward compatible, i.e. if there is a number, use that, otherwise handle the range [12:24] frankban, so the Ports *can* be wrong, but PortRanges slice won't be [12:24] frankban, thanks for the heads up, I'll tackle this with priority [12:25] dimitern: I can help if you want [12:26] frankban, I need to have a chat with william first, but I'll get back to you [12:26] dimitern: ok thanks [12:36] dimitern: anyway, something like this prototype would work, with a subsequent change to the GUI: https://github.com/frankban/juju/compare/restore-megawatcher-unit-ports?expand=1 [12:41] hi, anyone in for a trivial text only rev https://github.com/juju/testing/pull/50 ? [12:41] frankban, ok, so I'm filing a bug about it first, then I have a clear plan how to fix it in a backwards compatible way [12:42] perrito666, reviewed [12:43] frankban, unfortunately what you're suggesting is not sufficient, as it introduces another change into the struct format [12:43] dimitern: tx done [12:44] dimitern: I know it's still backward incompatible, but it can be good enough for the GUI, which is your main API consumer [12:44] frankban, I'd rather have a new PortRanges slice field and revert Ports to how it was, while having a piece of code that converts from=to ranges to ports and drops the rest [12:45] dimitern: sounds good, at that point no change is required GUI side [12:45] frankban, exactly; ok, cheers [12:46] dimitern: thanks for looking at that, could you ping when you have a fix? [12:50] dimitern: same thing for utils? [12:54] perrito666, what thing? [12:55] dimitern: If I where a smarter person, I would not have forgotten to paste the link [12:55] https://github.com/juju/utils/pull/113 [12:55] perrito666, :) [12:56] perrito666, lgtm [12:56] ta [12:58] lool, did yo see what shows in github when you say :shipit: ? [13:19] perrito666, I saw but couldn't quite get it [13:20] is it a mob-frog of some sort? [13:20] looks like a squirrel with a hat [13:20] oh is it a frog? [13:20] ha, could be :) [13:20] ok, gtg - CPT sprint is officially over [13:20] dimitern: cheers [13:21] ta ;) [13:24] perrito666, dimitern: Ship It Squirrel - added to github - https://github.com/github/hubot-scripts/commit/247310f83e8f0a33230c4a2ceb5e68ca86006e18 [14:42] ok, las licencing fix, I promisse http://reviews.vapour.ws/r/889/ [15:45] anyone around with mongodb knowledge jujuer on #juju has an interesting bootstrap error http://paste.ubuntu.com/10092884/ please come over there === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === makyo_ is now known as Makyo [19:07] rogpeppe: I didnt parse half of your mail [19:08] perrito666: sorry, my fault, i've had beer :) [19:08] I do agree though that we could/should move to gopkg.in yet that does not change the fact that our internal repo should branch when this happens (as I did) [19:08] rogpeppe: I envy you, I had wather only [19:08] perrito666: is wather low alcohol? [19:09] perrito666: ( :-) ) [19:09] dont try wather, is terrible, produces oxidation :p [19:09] perrito666: what do you mean by "our internal repo"? [19:10] well, see, when we tag juju for release, lets say 1.21 [19:10] we deppend on a set of versions of ilbraries [19:10] that we support ourselves [19:11] like juju/utils or juju/testing [19:11] perrito666: ok [19:11] so, as development advances for new versions, these all grow in code but we keep maintaining 1.21 [19:11] perrito666: ok [19:11] so at some point we will neet to backport a dependency fix to 1.21, say a licence issue [19:12] and there you have two options, you add that fix on top of the dependency and make 1.21 deppend on that, with a subset of unknown/unwanted changes in the dependency [19:12] perrito666: is that a problem? [19:12] or, branch the dependency at the point that is used in 1.21 and apply changes there [19:12] perrito666: (option 2, that is) [19:12] rogpeppe: exactly that [19:13] perrito666: the only time i can think it would be a problem is if the dep hasn't changed in a backwardly compatible way [19:14] that was the case [19:14] perrito666: right [19:14] perrito666: that's why i'm suggesting the use of gopkg.in [19:14] but if it wherent and the distance is too big, you are adding a lot of unwilling changes to a minor release which is a bit icky [19:15] perrito666: i don't think it should be [19:15] perrito666: backwardly compatible should be backwardly compatible [19:15] perrito666: and maintaining forks is a significant use of time and resources [19:16] well, they are called maintenance branches for something, you just add whatever fix you backport to those or close them :p [19:16] * perrito666 ponders having beer to stop mosquitoes from bitting him [19:17] * rogpeppe accepts another beer [19:19] IPA is dead: citra [19:19] mmm [19:20] * perrito666 settles for mosquito repellent === kadams54 is now known as kadams54-away [19:26] perrito666: the more branches the more effort and the more likelihood of getting things wrong between branches, in my experience anyway. [19:27] rogpeppe: ¯\_(ツ)_/¯ [19:27] perrito666: that looks rude to me [19:27] * perrito666 suspects that the fonts dont translate the message too well :( [19:29] rogpeppe: its a very strange not really ascii face for "yup, what to do about it" [19:30] I now realize I only know the expression in spanish :p which means it might not go past local boundaries [19:30] perrito666: ah, it's a face! i thought it looked like legs... :) [19:30] rogpeppe: the face seems to be a pretty odd unicode character [19:31] rogpeppe: something that, thinking of it, most people not having a language that needs of it might not have installed [19:31] perrito666: my suggestion is that we move to gopkg.in and always update to the latest branch of any package whenever possible [19:31] perrito666: no, the character worked [19:32] rogpeppe: even though we might be backporting a load of changes as a collateral? [19:32] perrito666: yes [19:32] perrito666: because we should guarantee backward compatibility [19:32] its a bit like: hey I fixed the typo on the kernel, lets release a minor... and you might have a news scheduler too [19:32] perrito666: for gopkg.in branches [19:33] perrito666: we're talking about deps here, not core functionaliryt [19:33] ity [19:33] perrito666: if deps implement extra (backwardly compatible) core functionality, then why not? [19:34] perrito666: i don't really understand what your real concern is here? increased binary size? [19:36] rogpeppe: not really, I think my concern is mostly bureaucratic so I should drop it [19:37] perrito666: if using the latest version turns out to be a problem in practice, we always have the *option* of forking it [19:37] about bugs and the probability of those being added when adding code there [19:37] rogpeppe: agreed there [19:37] rogpeppe: btw, the icon -> http://s3-ec.buzzfed.com/static/2014-05/enhanced/webdr07/21/15/enhanced-29943-1400699227-1.jpg [19:37] perrito666: hopefully, later versions of the same package should remove bugs, not add them... [19:37] perrito666: :) [19:38] perrito666: the emoticon looked correct in my IRC client [19:38] rogpeppe: then your internal emoticon interpreter does not really work :p [19:38] perrito666: yeah, i think i need an upgrade [19:38] I have seen some machines render a square for some of those [19:43] rogpeppe: I meant to ask in brusselles, what was the editor you where using, at first it seemed like a heaviy customized vi, but then I doubted [19:43] perrito666: http://en.wikipedia.org/wiki/Acme_%28text_editor%29 [19:44] perrito666: this is a nice intro: https://www.youtube.com/watch?v=dP1xVpMPn8M [19:45] perrito666: there is a small but select group of people that use it :) [19:45] Well Ill take you on the small :p [19:46] perrito666: it's actually kind of the opposte of vi [19:46] do you use a linux port or run plan9? [19:46] opposite [19:46] perrito666: i'm currently using trusty [19:46] rogpeppe: the opposite of vi is emacs :p I have been in countless flamewars about the subject [19:47] perrito666: actually the reason vi and emacs inspire flamewars is that they are similar [19:47] perrito666: like how the worst religious wars are between related faiths [19:47] I attribute the amount of flame on those to the fact that they attract people who like to flame [19:48] * perrito666 goes for the intro on video [19:52] when you combine rogpeppe with beer it gives him great power and he will attempt to lure you to the darkside, don't fall for it perrito666 [19:52] lol [19:53] wwitzel3: lool, well for starters that editor seems to require for me to use a mouse [19:53] actually, lololololol [19:53] which sits at more than an arms lenght from where I sit [19:53] so no chance :p [19:53] perrito666: the mouse is an instrument of the Force [19:54] rogpeppe: the xbox kinect is an instrument of the force, the mouse is too far [19:54] perrito666: but seriously, the mouse transmits more information than a keyboard [19:54] rogpeppe: I could do with a touchpad :p [19:55] rogpeppe: well I do have a layout set for keyboard mostly, which makes the mouse a bit irrelevant, I only use it when using things like inkscape or gimp [19:55] perrito666: i use it quite successfully with a thinkpad nipple [19:56] perrito666: i know people that use it successfully with a touchpad (and some keys set up for button chording) [19:56] rogpeppe: yup, I like the thinkpads thinguie, but all of my thinkpads kbs are in es_ES which sucks for coding, next trip to an english speaking country ill get a thinkpad wireless kb [19:56] perrito666: but the mouse power is probably the essence of acme [19:57] perrito666: just change the keyboard layout and don't look at your fingers [19:57] rogpeppe: the shape is different sadly [19:57] perrito666: orly? [19:57] spanish kb lacks |\ [19:57] it has a large return instead [19:58] perrito666: that's a bit rubbish [19:58] I currently use an apple blueetooth kb [19:58] not wonderful but light and en_US [19:58] perrito666: well, that's a reasonable option [19:59] perrito666: anyway, acme is the embodiment of mouse-is-faster-than-keyboard. http://www.asktog.com/TOI/toi06KeyboardVMouse1.html [19:59] yup, borrowed from a friend that became a full time manager and suddenly lost need for his coding station :p [19:59] perrito666: and it really does seem to work (for me anyway :-]) [20:00] I wont counter a man that can succesfully climb a palm tree while drunk [20:01] success is in the eye of the beholder [20:02] rogpeppe: well you did not fall or get arrested, that is success [20:04] perrito666: in which case i am succeeding all the time, wa hay! [20:05] I cant believe you do that often and not get arrested of fall [20:10] perrito666: i am not falling or getting arrested [20:12] * rogpeppe wonders why the video is a query parameter on the youtube video url [20:23] rogpeppe: it is a curious choice [20:24] perrito666: it makes a mockery of REST :) [20:24] well, they never said it was restful :p [20:25] perrito666: and in the end, who cares? [20:25] rogpeppe: well I do, I like nice urls :) [20:26] perrito666: "?" "/" ... what's the difference in the end? === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away