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