[00:21] <davecheney> thumper: http://stackoverflow.com/questions/7222062/mongodb-composite-key
[00:30] <jcw4> davecheney, thumper wow... that looks very intriguing
[00:30] <thumper> jcw4: yeah, I'm going to write an email to juju-dev about keys in multi-environment servers
[00:31] <thumper> I'd like agreement and consistency before we dive head-first into schema changes
[00:31] <jcw4> +1
[00:32] <davecheney> thumper: oh, I thought we were all going to propose out champion
[00:32] <davecheney> then fight it out, thunderdome style
[00:32] <davecheney> oh wait
[00:32] <davecheney> that would be a bad idea
[00:32] <jcw4> mad max did come from down under didn't he?
[00:33] <davecheney> http://upload.wikimedia.org/wikipedia/commons/9/9d/07._Mad_Max_Car_at_Silverton_Hotel,_Silverton,_NSW,_07.07.2007.jpg
[00:34] <davecheney> last of the V8 interceptors
[00:34] <jcw4> sweet... I've been through that town dozens of times and never saw that
[00:34] <jcw4> not
[00:35] <thumper> davecheney: I love that car
[00:35] <katco> hmm... why am i staring down a variable named x if i'm not dealing with a coordinate system...
[00:35] <thumper> looks awesome
[00:35] <thumper> katco: haha, +1 on making it mean something
[00:40] <katco> it is now named fishAndChips
[00:40] <katco> (or configKeyValues... one or the other)
[00:47] <jcw4> katco: like schrodingers cat?
[00:47] <katco> well, it's definitely one or the other :)
[00:48] <jcw4> hehe
[00:55] <stokachu> does the Machiner api expose http://godoc.org/github.com/juju/juju/state#Machine?
[00:57] <stokachu> btw, im working on a python3 api client for juju https://github.com/battlemidget/cloud-installer/blob/patch-split-core-logic/cloudinstall/juju/client.py
[00:57] <stokachu> now trying to figure out the api requests for accessing the Machine data
[01:01] <stokachu> or maybe api call to pull http://godoc.org/github.com/juju/juju/state/api#MachineStatus
[01:04] <thumper> stokachu: only the client api end points are callable by non-agents
[01:04] <thumper> stokachu: what is it you are really trying to do?
[01:04] <davecheney> 17 minutew to land a change
[01:04] <davecheney> NOICE
[01:04] <thumper> davecheney: \o/
[01:04] <davecheney> a grand improvement from this time last week
[01:04] <stokachu> thumper, want to access the machine data without having to call juju status
[01:05] <davecheney> o/ axw and wallyworld
[01:05] <thumper> stokachu: I don't think we allow that
[01:05] <axw> davecheney: howdy
[01:05] <stokachu> thumper, b/c no code exists or some other reason?
[01:05] <axw> davecheney: yeah, I wish I made that change ages ago :/
[01:06] <axw> I think the fastest I've seen so far is 16m. It should be considerably faster again when we have a dedicated instance for the lander
[01:06] <stokachu> our cloud-installer relies on calling out to juju <cmd> and i want to remove all that in favor of the api
[01:07] <stokachu> like i do with maas
[01:07] <thumper> stokachu: it think it was more to do with security
[01:07] <thumper> stokachu: so we didn't expose things to people who don't need them
[01:08] <stokachu> so if i file a bug will it get closed wontfix?
[01:08] <thumper> not if there is a clear and useful need for it
[01:08] <thumper> and it doesn't expose places where we can get screwed up
[01:09] <stokachu> if you're just exposing mostly read only it should be ok right?
[01:09] <stokachu> and its already exposed in juju status so we could just mimic that
[01:10] <stokachu> besides there is an api call to forcedestroy machines so i think you couldnt do worse than that :)
[01:11] <thumper> stokachu: could you not just use the status API?
[01:11] <thumper> why do you need another one?
[01:11] <stokachu> thumper, the status api only returns machine_id: {InstanceId}
[01:11] <stokachu> our cloud-installer requires information that isn't exposed by the api
[01:12] <axw> stokachu: you want to get machine status? http://godoc.org/github.com/juju/juju/state/api#Client.Status ?
[01:12] <stokachu> {"RequestId":2,"Response":{"Machines":{"0":{"InstanceId":"localhost"},"1":{"InstanceId":"adam-local-machine-1"},"2":{"InstanceId":"adam-local-machine-2"},"3":{"InstanceId":"adam-local-machine-3"}}}}
[01:12] <stokachu> thats all thats returned from the Status api call
[01:12] <axw> huh
[01:13] <axw> stokachu: what version of juju?
[01:13] <stokachu> 1.18.4
[01:13] <axw> menn0: ^^ does this have anything to do with the FullStatus changes?
[01:13] <axw> I think there may be some fallback code for 1.18
[01:13] <thumper> stokachu: that just seems wrong
[01:13] <stokachu> theres a LegacyStatus call
[01:14] <thumper> status definitely returns more than that
[01:14] <thumper> godoc.org/github.com/juju/juju/state/api#MachineStatus
[01:14] <stokachu> https://github.com/battlemidget/cloud-installer/blob/patch-split-core-logic/cloudinstall/juju/client.py#L80-L83
[01:14] <stokachu> thats the request parameters i use
[01:15] <axw> stokachu: I think you actually want to call "FullStatus" from 1.18+
[01:15] <stokachu> lemme try that
[01:15] <axw> it's hidden by the API
[01:16] <thumper> https://github.com/juju/juju/blob/master/state/api/client.go#L145
[01:16] <thumper> line 157 shows "FullStatus" being called
[01:17] <stokachu> axw, calling FullStatus works
[01:17] <thumper> \o/
[01:17] <stokachu> should Status call that in later versions I guess?
[01:18] <axw> cool
[01:18] <stokachu> or is FullStatus in process of being documented
[01:18] <axw> stokachu: in the Go code it does: the client method is called Status, but it calls FullStatus under the hood
[01:19] <stokachu> was that introduced after 1.18.x?
[01:19] <stokachu> just trying to understand why calling Status failed
[01:19] <stokachu> well failed to pull FullStatus
[01:20] <stokachu> i see where its called in the latest api code
[01:20] <axw> we don't have versioning (yet) on APIs, so if the structure of the parameters becomes incompatible we have to change the API name
[01:21] <stokachu> ah ok
[01:21] <stokachu> thumper, yea this was what i was looking for
[01:22] <axw> stokachu: so it was actually introduced as a stub in 1.16, but I think full functionality didn't arrive till 1.18
[01:22] <stokachu> gotcha
[01:23] <stokachu> func (c *Client) Status() (api.LegacyStatus, error) { < - this api.LegacyStatus why it doesn't show the FullStatus properly?
[01:28] <axw> stokachu: I don't really recall whether that was all it ever had, or if it was purposefully hobbled. We used to go directly to mongo to get the status of entities, but I can't remember what part the API had
[01:28] <stokachu> ok cool
[01:43] <waigani> you don't need to explicitly call setupsuite on an embedded suite if you only have one right?
[01:44] <thumper> waigani: correct
[01:46] <waigani> thumper: thanks
[02:12] <waigani> what are some examples of jujuconnsuite being overused/wrongly used?
[02:12] <waigani> menn0: ^?
[02:14] <menn0> waigani: I believe there's some suites that don't actually use an API connection but still embed JujuConnSuite (probably due to copy and paste)
[02:14] <menn0> waigani: there's also a bunch of suites that should be mocking the API instead of using a real API connection
[02:14] <waigani> menn0: ah right, thanks
[02:18] <waigani> when testing ops on docs, should that be mocked or not (that sounds like a bad Dr Seuss rhyme)?
[03:13] <bigjools> a bunch of NUCs with SSDs actually makes deployment with juju and maas quite painless
[03:20] <davecheney> waigani: wallyworld axw thumper https://github.com/juju/testing/pull/19
[03:20] <davecheney> small cleanups for the testing package
[03:22] <thumper> davecheney: given that you are always telling us not to throw away the err...
[03:22] <thumper> why are you?
[03:24] <davecheney> i can't be bothered extending that massive if condition
[03:24] <davecheney> someone else can later if they want
[03:54] <thumper> axw: is the environment name for machine placement actually every checked?
[03:54] <axw> thumper: I forget. it's mainly there for future usage
[03:54] <axw> I'll check
[03:54] <thumper> hmm...
[03:54] <thumper> I'm trying to hide the EnvName from the environment command
[03:55] <thumper> so I can allow passing of everything through command line or environment
[03:55] <thumper> so may not have a name referring to something on disk
[03:56] <axw> thumper: it is checked in apiserver/client.Client.addOneMachine
[03:57] <axw> thumper: why do you want to hide EnvName?
[03:57] <axw> I don't quite understand
[03:57] <thumper> because env name is getting confused
[03:57] <thumper> it isn't really the env name at all
[03:58] <thumper> but a local alias to an environment uuid/username pair
[03:58] <thumper> in order to support better scripting
[03:58] <axw> right
[03:58] <thumper> we want to be able to have a script define an environment
[03:58] <thumper> a set of env vars
[03:58] <thumper> that the juju commands can just use
[03:58] <thumper> so the machine that the script is run on
[03:58]  * axw nods
[03:58] <thumper> doesn't need the cached environment connection files
[03:58] <thumper> so...
[03:58] <thumper> EnvName may well be blank
[03:59] <thumper> so in a prep branch
[03:59] <thumper> I'm trying to hide it
[03:59] <axw> ok
[03:59] <thumper> and provide functions to get a client api
[03:59] <thumper> and other bits where it is used
[03:59] <thumper> it is surprising how much data creep there is
[04:00] <axw> thumper: I *guess* the placement scope should be translated from environment name (alias) to uuid+username then
[04:00] <thumper> if you have something public, people will use it
[04:00] <axw> heh :)
[04:00] <axw> and use it in unexpected ways
[04:00] <thumper> right
[04:00] <thumper> axw: uuid would probably be sufficient
[04:00] <axw> yeah I guess, user is implied
[04:00]  * thumper nods
[04:08] <thumper> axw: actually, there is a problem with this code...
[04:08] <thumper> axw: if I rename my connection file
[04:09] <thumper> axw: this won't work
[04:09] <thumper> axw: because it will say "invalid environment name"
[04:10] <axw> yeah... that will need to change if we're not requiring the .jenv to be there
[04:10] <thumper> axw: also if I just rename my jenv file
[04:11] <thumper> my local aliase won't match the environment name
[04:11] <thumper> oh man
[04:11] <thumper> so much for being a quick and easy branch
[04:11] <thumper> fucking tenticles everywhere
[04:12] <axw> thumper: I thought we were going to have a command to create a .jenv file from connection settings?
[04:12] <thumper> we probably are
[04:12] <thumper> but if I specify everything on the environment
[04:12] <thumper> I don't want it touching the file system
[04:12] <axw> fair enough
[04:35] <thumper> coffee time
[06:48] <TheMue> morning
[07:46] <voidspace> morning
[08:37] <TheMue> voidspace: morning
[08:56] <dimitern> TheMue, voidspace, hey
[08:57] <dimitern> I'd love a review on this https://github.com/juju/juju/pull/243/
[08:57] <urulama> the parsing of environment.yaml fails if there is a line with a tab ('\t') but without entry of attributes. looked at LP for such bug and couldn't find one. using juju 1.19.4
[08:58] <urulama> let me know if this is not reported yet
[09:05] <TheMue> dimitern: *click*
[09:06] <dimitern> urulama, so is it valid yaml?
[09:06] <dimitern> TheMue, ta
[09:06] <urulama> dimitern: yes, replacing tabs with spaces worked
[09:07] <urulama> dimitern: the parsing only fails if there are tabs as prefixes to attributes
[09:07] <dimitern> urulama, using tabs in a yaml file is forbidden
[09:07] <dimitern> urulama, http://www.yaml.org/faq.html
[09:08] <urulama> dimitern: yes, however, imagine user with an editor that automatically ads tabs ...
[09:09] <dimitern> urulama, I'm not saying it can't happen, but this is like saying "invalid html should still show up correctly" :)
[09:10] <dimitern> urulama, what's the error you're getting?
[09:10] <urulama> dimitern: not saying it's a bug, maybe a "usability error" ... maybe adding "don't use tabs" in description could help a bit
[09:11] <urulama> dimitern: it's simply "ERROR: couldn't read the environment"
[09:11] <dimitern> urulama, right, I agree it's a usability issue and please, file a bug for it, so we can keep it in mind
[09:11] <urulama> dimitern: ok
[09:14] <rogpeppe> urulama: yaml is a ridiculous format :-)
[09:20] <dimitern> mgz, hey
[09:20] <dimitern> mgz, is goose still on launchpad ?
[09:22] <TheMue> dimitern: you’ve got a review
[09:23] <TheMue> voidspace: still troubles merging the replica set test?
[09:26] <dimitern> TheMue, thanks
[09:28] <TheMue> dimitern: it’s nice to see how IPv6 soaks into the code (hope I took the correct verb)
[09:31] <dimitern> TheMue, yeah :)
[09:58] <voidspace> TheMue: yep
[09:58] <voidspace> mgz: ping
[10:00] <perrito666> morning
[10:00] <voidspace> perrito666: morning
[10:00] <voidspace> mgz: https://github.com/juju/juju/pull/238
[10:00] <voidspace> mgz: this got a "merge request accepted" 18 hours ago but hasn't been run
[10:00] <voidspace> mgz: meanwhile other ones have
[10:11] <mgz> voidspace: looking
[10:13] <mgz> voidspace: see job 371
[10:13] <mgz> ec2 fell over, I'll requeue on the bot
[10:15] <voidspace> ah, I did have a look to see if it ran
[10:15] <voidspace> I must have missed that
[10:15] <voidspace> mgz: ah, but it was marked as failure - the bot didn't see it though?
[10:16] <voidspace> "
[10:16] <voidspace> InvalidInstanceID.NotFound: The instance ID 'i-7444355f' does not exist"
[10:16] <mgz> yeah, made teh job fall over in such a waay as it didn't get to the reporting back step
[10:17] <voidspace> wwitzel3: ping for when you're around
[10:17] <voidspace> wwitzel3: and fully caffinated
[10:45] <voidspace> dimitern: TheMue: I'll be five minutes late to stdup - sorry
[10:45] <dimitern> voidspace, no worries
[10:47] <dimitern> vladk, standup?
[10:58] <ChrisW> how do standups work when everyone's remote?
[11:02] <perrito666> I would greatly appreciate a second look at https://github.com/juju/testing/pull/18
[11:02] <perrito666> ChrisW: hangout
[11:03] <TheMue> voidspace: it failed again, really strange
[11:04] <TheMue> perrito666: will take a look in a few moments, just have to change place (too warm on the verranda)
[11:04] <perrito666> TheMue: 1st world problems :p
[11:04] <TheMue> hehe, indeed
[11:08] <voidspace> TheMue: yep, they look completely unrelated though
[11:08] <voidspace> TheMue: I tried again locally and everything passes
[11:10] <TheMue> voidspace: so there seems to be something different on the ec2 hosts
[11:10] <mgz> voidspace: looks like the run's tests failed, but the pr should be back in a sane state now
[11:11] <voidspace> TheMue: mgz: yeah, I've tried again in the hope that it's spurious
[11:12] <mgz> that one of the failures is in a new test (..BothIPv4AndIPv6) isn't encouraging
[11:12] <ChrisW> juju-gui totally written in JS?
[11:12] <mgz> looks like new flakiness
[11:14] <frankban> ChrisW: yes, it uses a Python server when deployed using the Juju GUI charm, which enables some additional features (like bundle deployments) but the core application is client-side JS
[11:15] <ChrisW> fascinating :-) Interesting to see that most of the juju-gui team appear to be ex plone/zope people :-)
[11:18] <frankban> ChrisW: :-) it used to be like that, but now we have some great JS guys in the team
[11:19] <TheMue> perrito666: review done, with a minor comment.
[11:19] <perrito666> TheMue: thank you very much
[11:19] <TheMue> perrito666: yw
[11:19] <ChrisW> heh, you saying plone/zope guys aren't great with JS? ;-)
[11:54] <TheMue> voidspace: yay, it merged
[11:58] <voidspace> awsome
[11:58] <voidspace> TheMue: at last :-)
[12:01] <TheMue> voidspace: somehow strange that it had so much troubles. if it would be a failing test, and always the same, then the problem can easily be located
[12:01] <TheMue> voidspace: but it looks absolutely strange here, once even a panic during build
[12:42] <frankban> hi all, it seems 1.20 inadvertently changed the structure returned by the mega-watcher for machines. please see bug 1337831. Even if the quickstart fix should be easy enough, it's worth noting this seems to be an accidental change to the public API
[12:42] <_mup_> Bug #1337831: Quickstart crashes when used with juju 1.20 <juju-quickstart:In Progress by frankban> <https://launchpad.net/bugs/1337831>
[12:42] <frankban> fwereade: ^^^
[13:35] <rogpeppe> fwereade: shall we have that chat some time?
[13:38] <perrito666> people anyone would like to take a second look to https://github.com/juju/utils/pull/4 before I merge it? It has only been reviewed by me
[13:42] <TheMue> perrito666: *click*
[13:43] <perrito666> TheMue: you are the on call reviewer and I am making your day hell?
[13:43] <perrito666> uh, I am on call reivewer
[13:44] <perrito666> :p
[13:44] <perrito666> its a good thing I have been reviewing since I got up
[13:44] <TheMue> *lol*
[14:34] <bodie_> morning all
[14:34] <bodie_> blam blam 'murca
[14:35] <katco> good morning all :)
[14:38] <katco> i came across a curious few lines. should this panic be removed? c.Assert(scripts[0].line, gc.Matches, pats[0].line, gc.Commentf("line %d", scripts[0].index))
[14:38] <katco> 				panic("unreachable")
[14:39] <perrito666> katco: morning, isnt today a holiday for you?
[14:39] <katco> perrito666: it is
[14:39] <katco> but i want this change in before boston so i don't lose that velocity. i'm almost done. really should have finished it yesterday
[14:40] <katco> plus coding is what i do for fun :)
[14:41] <katco> i promise i'm not this much of a workaholic... i just like to do deep dives to get going. i hope i'm not giving a bad impression =/
[14:42] <jcw4> katco: you're on probation... too much of this workaholic stuff and BAM
[14:42] <jcw4> :)
[14:42] <katco> lol
[14:42] <TheMue> katco: morning
[14:42] <katco> no really, back when i was a lead i actively discouraged this kind of thing.
[14:43] <katco> but i don't like staying new for too long ;p
[14:43] <katco> TheMue: good morning :)
[14:43] <jcw4> katco: +1
[14:44] <TheMue> katco: those unreachable-panics are from earlier times, when Go wanted a return (or panic). today it detects when a code is unreachable.
[14:44] <TheMue> katco: so IMHO they can be removed
[14:44] <katco> TheMue: ahh! ok that makes a lot more sense
[14:46] <katco> gosh... changing upstart config files just breaks all kinds of tests
[14:46] <katco> spending more time fixing the tests than the bug
[14:47] <perrito666> that is true for almost anything in juju
[14:47] <perrito666> I am still fixing ripples from 2 lines I changed on agent
[14:47] <katco> hmm... i have been watching with great interest discussions about what level of testing is sane, and how not impact architecture just for the sake of testing
[15:12] <TheMue> so, preparing for football, I’m off
[15:12] <rogpeppe> katco: that's a very interesting subject
[15:12] <rogpeppe> katco: it's something i struggle with all the time
[15:12] <katco> rogpeppe: i really think so. testing has kind of crept in and become this thing you automatically do
[15:12] <katco> rogpeppe: as always, have to find the middle way :)
[15:13] <rogpeppe> katco: i think that 100% testing is often a necessity in dynamically typed languages, but i think can be overkill in a statically type lang
[15:14] <rogpeppe> katco: i personally don't mind leaving "obviously trivial" pieces of code untested, particularly when the impact of failure will be obvious when the code is actually run
[15:14] <rogpeppe> katco: but then again, i have also had my share of places where those pieces of code were actually wrong in some way
[15:15] <katco> rogpeppe: yeah, same here
[15:16] <rogpeppe> katco: the classic example is: func SomeValue() string {return "some value"}; then the test is func TestSomeValue(c *gc.C) {c.Assert(pkg.SomeValue(), gc.Equals, "some value")}
[15:16] <rogpeppe> katco: is that test really worth writing?
[15:16] <katco> i would say no on that one :)
[15:16] <rogpeppe> katco: it's a slippery slope :-)
[15:16] <katco> i operate on the philosophy that tests reduce velocity, so they need to be on trial
[15:16] <katco> but yes, definitely a slipperly slope
[15:17] <katco> i also operate on the philosophy that smart devs are smart, and we should rely on their good judgement and not make uniform statements like, "all code should be tested" :)
[15:17] <rogpeppe> katco: i agree entirely. i love tests of tricky code, but the tests in juju are also a real burden we are constantly having to bear
[15:18] <katco> i have spent the last day trying to understand a test... i don't know, i know i'm new, but that seems like an issue
[15:19] <bodie_> heheh...  there are some really hairy ones
[15:19] <katco> this particular one sets up a giant string, then there's a function that splits it on newlines, loops over the newlines, and performs regex escaping magic
[15:19] <katco> about drove me batty! :p
[15:20] <bodie_> check out worker/uniter/uniter_test.go.... that's where I've been poking around for a week or two
[15:20] <bodie_> I've never seen anything quite like it
[15:20] <katco> lol
[15:20] <katco> should tests be more complicated than the code they're testing?
[15:20] <katco> interesting question
[15:21] <bodie_> there's a cost/benefit between ease of test creation, vs simple extendability if you're testing a very featureful package, I think
[15:22] <bodie_> that uniter test is a great example, because while it looks huge, and weird, and complicated at first glance, it makes it very simple to add new tests as sequences of steps
[15:23] <katco> yeah, i see the benefit of that angle
[15:23] <bodie_> and, there are tons of tests in it (which is itself probably not a great thing)
[15:23] <katco> i suppose in that case a few comments explaining the framework would go a long way
[15:23] <bodie_> yes... lol
[15:24] <katco> well this is very interesting. i don't feel quite as dumb as i did yesterday ;)
[15:24] <katco> having said that... i think i'm _finally_ ready to land this change
[15:25] <katco> and then i can get on with my holiday! :p
[15:25] <bodie_> it was a bit of a ramp up for me as well, but somehow the illusion of complexity keeps dissolving into clear simplicity as I keep digging
[15:25] <bodie_> I'm not sure whether to blame Go or the smart people writing this code :)
[15:26] <katco> go does seem to force me towards good simple code. it's one of the reasons i love it
[15:27] <perrito666> katco: usually that is the programmers skill, I have yet to see a language that forces people into writing good code
[15:28] <katco> perrito666: i definitely agree. but i have hit brick walls in go, and a week later i realize it's because there's a much simpler way. i.e.: i was fighting the language
[15:29] <katco> ok here we go... 2nd PR: https://github.com/juju/juju/pull/245
[15:29] <katco> definitely appreciate feedback on this one
[15:31] <perrito666> katco: did you do the autosquash part before submitting this?
[15:31] <katco> perrito666: no i forgot... i thought about going back, but the documentation says "optionally"
[15:31] <katco> i can definitely go back and do it if you like
[15:33] <perrito666> katco: hey, if it says optionally, who am I to say something :p
[15:34] <katco> perrito666: lol i really don't mind. i plan on doing it in the future. i just want to land this thing!
[15:53] <katco> perrito666: happy to discuss in addition to the comment i just made. just lmk. i think it's a relatively safe change.
[15:59] <katco> perrito666: i have to step away for a bit. please lmk if/when i can land this so i can sign off for the weekend!
[15:59] <katco> bbiab
[16:05] <perrito666> katco: ok, with context now, it seems fine, if you want to get another review from someone here even better if not, go ahead and merge it, I trust you ran all the tests :)
[16:11] <jcw4> perrito666, katco I scanned through and it LGTM too
[16:11] <jcw4> I can add a comment if wanted
[16:33] <rogpeppe> fwereade: are you done yet, or time for a little more resources discussion?
[16:34] <fwereade> rogpeppe, let's, but gimme 5 mins
[16:34] <rogpeppe> fwereade: sure
[16:37] <katco> perrito666: jcw4: tyvm; i did run through all the tests. landing now
[16:42] <mgz> katco: you're being a guinea pig for me, don't be alarmed by spam on or pr
[16:43] <katco> mgz: haha ok
[16:43] <katco> keep in mind that after this lands i'm outta here!
[16:44] <mgz> katco: ideally, you won't see anything, so it should be fine :)
[16:44] <mgz> jsut futzing with the landing job
[16:44] <katco> mgz: sure, sure! i've heard that before! ;)
[16:48] <katco> pro tip: vivaldi's "summer" makes anticipating the build result much more exciting
[16:50] <jcw4> katco: not The Ride of the Valkyrie's ?
[16:50] <katco> rofl
[16:50] <mgz> hm, labix.org seems to be being not super-reliable
[16:50] <katco> summer is more dynamic... will it build? it will! or will it?? (bites nails)
[16:50] <jcw4> hehe
[16:50] <katco> mgz: his cert expired
[16:50] <mgz> ah, thanks
[16:59] <katco> workflow question: supposing this lands successfully, do i mark the bug on launchpad as "Fix Committed"?
[17:01] <mgz> katco: yup
[17:16] <katco> hallelujia i'm done with this change! lol
[17:16] <katco> alright all, i will see you fine people next week!
[17:16] <jcw4> happy 4th!
[17:16] <katco> same!
[17:18] <mgz> katco: see you next week :)
[18:42] <mfoord> g'night all
[18:42] <mfoord> some of you I'll see on Monday
[19:38] <bac> fwereade_: you around?
[19:38] <fwereade_> bac, kinda sorta
[19:38] <fwereade_> bac, what can I do for you?
[19:38] <bac> fwereade_: should be quick.  can you explain ian's point in the last comment at https://bugs.launchpad.net/juju-core/+bug/1316174
[19:38] <_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
[19:39] <bac> fwereade_: on precise i have installed juju-core and juju-local.  i expect that to be sufficient but i cannot bootstrap an lxc environment due to this bug.
[19:41] <fwereade_> bac, I think he's saying "we will fix this by checking whether the user can get the right version of mongodb and fail before getting that far", and I hope it also implies "we will explain what the problem is and how to resolve it in the error message""
[19:41] <bac> fwereade_: is there a work-around?
[19:43] <fwereade_> bac, I'm not immediately sure, I'm afraid, but I had *thought* that installing juju-local should be sufficient
[19:43] <bac> fwereade_: ok.  i'm trying to qa juju-quickstart and it is currently broken on precise.  i'll update the bug with questions for ian.  thanks for your time past eod.
[19:45] <fwereade_> bac, i suspect that https://bugs.launchpad.net/juju-core/+bug/1289316 and https://bugs.launchpad.net/juju-core/+bug/1290890 are also relevant, but I don't have enough context to know what';s really going on
[19:45] <_mup_> Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise <lxc> <maas> <precise> <regression> <juju-core:Fix Released by wwitzel3> <https://launchpad.net/bugs/1289316>
[19:45] <_mup_> Bug #1290890: juju 1.17.5 RC cannot deploy to precise <ci> <deploy> <precise> <regression> <juju-core:Fix Released by wwitzel3> <https://launchpad.net/bugs/1290890>
[19:45] <fwereade_> wwitzel3, ^^