[07:17] <fwereade_> dimitern, ping
[07:30] <dimitern> hey
[07:30] <dimitern> fwereade_: morning
[07:34] <TheMue> fwereade_, dimitern: morning
[07:34] <dimitern> TheMue: hiya
[07:41] <fwereade_> dimitern, quick chat re relations/upgrade-charm before the meeting?
[07:42] <dimitern> fwereade_: actually, I thought it's better for me to do the other card first: --switch
[07:42] <dimitern> fwereade_: should be simpler, etc. but after the change to use statecmd, i'm a bit lost now
[07:46] <fwereade_> dimitern, ah, is that in now? I thought Makyo|out was planning to revert
[07:47] <dimitern> fwereade_: it landed and probably he'll build on it
[07:47] <fwereade_> dimitern, and, yeah, this is bad timing -- rog will also have something to contribute, I think, he's assigned himself the "allow local charms via api" card
[07:48] <dimitern> fwereade_: hmm..
[07:48] <fwereade_> dimitern, *but* from your perspective it shouldn't be that bad actually
[07:48] <rogpeppe1> mornin' all
[07:48] <fwereade_> rogpeppe1, heyhey
[07:48] <dimitern> fwereade_: actually, i'm lost now
[07:48] <dimitern> rogpeppe1: hey
[07:49] <fwereade_> dimitern, all --switch really needs to do is to send a different charm url in the params
[07:49] <dimitern> rogpeppe1: were you planing to implement upgrade-charm --switch to local repo flag?
[07:49] <rogpeppe1> dimitern: no
[07:49] <rogpeppe1> dimitern: i'm not sure what the planned semantics are
[07:49] <fwereade_> dimitern, sorry unclear: it's just that the api doesn't handle local charms
[07:50] <fwereade_> dimitern, and I thought I saw rogpeppe1 assign that issue to himself
[07:50]  * rogpeppe1 is relieve to see his phone switch from "E" to "H", so may make the meeting after all
[07:50] <dimitern> fwereade_: but since upgrade-charm now uses the api, how will that be possible then?
[07:50] <rogpeppe1> fwereade_, dimitern: ah, local charms is something i was planning to do, as it requires some API thought
[07:50] <dimitern> so i cannot implement it then..
[07:51] <fwereade_> dimitern, it's actually orthogonal, isn't it?
[07:51] <fwereade_> dimitern, the commands don't *really* use the api anyway
[07:52] <dimitern> fwereade_: how about me you and rogpeppe1 have a g+ after the meeting to discuss it?
[07:52] <fwereade_> dimitern, +1
[07:52] <rogpeppe1> dimitern: sgtm
[07:52] <dimitern> great
[07:52]  * rogpeppe1 hopes he might get a decent internet connection again one day
[07:52] <dimitern> rogpeppe: what's E and what's H on your phone line?
[07:55] <davechen1y> https://docs.google.com/a/canonical.com/document/d/1p_OzWxqxaXalHBI3ohkUsB9_iQBPSGWwM-qODm5FSbI/edit#
[07:55] <rogpeppe> dimitern: different network data connectivity levels: E=Edge, 3G=3G and G=HSDPA H=HSDPA+ i think
[07:55] <davechen1y> https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
[07:55] <fwereade_> dimitern, (fwiw the short version is: you have a conn, with state and env, just add the charm yourself and pass a charm url to one that's already in state)
[07:56] <rogpeppe> dimitern: E is good for nothing. H is good enough for a marginal G+
[07:56] <davechen1y> edge is what they used to call 2G before 2G was defined by 3G
[07:56] <rogpeppe> davechen1y: ah, i'm pretty clueless about this, thanks
[07:57] <dimitern> rogpeppe: I see
[07:58]  * davechen1y worked for ericsson during the 2g / 3g wars\
[07:58] <davechen1y> it's all horseshit
[07:59] <davechen1y> the speed available to you is directly diven by the amount of free timeslots on your cell
[07:59] <davechen1y> basically, the more people on their phone, the less data per person
[08:00] <rogpeppe> luckily around here nobody uses much data, i think
[08:56] <mattyw> rogpeppe, hi there me again! does py juju set JUJU_CONTEXT_ID? i.e. to work out if my charm is running under pyju or goju do I just need to find some data in JUJU_CONTEXT_ID or something specific?
[08:57] <davechen1y> mattyw: a quick grep of the source says, no py juju (0.7) does not export JUJU_CONTEXT_ID
[08:58] <mattyw> davechen1y, hi dave, that seemed to be the case when I looked, but wanted to check in case my vimgrep-fu wasn't that great
[09:02] <mattyw> davechen1y, I guess it's a problem the juju-gui charm will have to solve at some point if not already, I'll try to pester hazmat when he's up
[09:02] <davechen1y> +1
[09:02] <fwereade_> dimitern, would you start one? quick bathroom break
[09:02] <dimitern> fwereade_: sure
[09:02] <jam> mgz: you're not climbing the valleys?
[09:03] <dimitern> fwereade_, rogpeppe: https://plus.google.com/hangouts/_/84df1b5aa61d251351d1476839611a33f6aa4f69?authuser=0&hl=en
[09:03] <mgz> woho, it let me leave
[09:06] <mgz> rogpeppe: haven't looked at the route cards yet, but it's normally white peak bit of peak district, around longnor. so, nothing very mountainy really.
[09:29] <rogpeppe> mgz: it is beautiful around there
[09:45] <dimitern> Makyo|out: sorry, i'll be reverting your branch about upgrade-charm API, as agreed with fwereade_ and rogpeppe; please ping me or them when you're here to discuss next steps
[09:46] <dimitern> mgz: what was the easiest bzr way to revert a single rev?
[09:47] <mgz> dimitern: eg, to backout rev 3, `bzr merge -r3..2 .` note the trailing dot
[09:48] <dimitern> mgz: ok, thanks
[09:54] <dimitern> mgz: hmm.. it's not working: bzr: ERROR: Not a branch: "/home/dimitern/work/go/src/launchpad.net/juju-core/.bzr/cobzr/.bzr/branch/": location is a repository.
[09:54] <dimitern> mgz: maybe cobzr interferes somehow; i suspect it's the dot at the end that's confusing it
[10:17] <mgz> you need to reference the branch you're dealing with
[10:18] <mgz> dimitern: so, with native colo I could also use co:trunk if the rev I'm dealing with is on trunk. I presume cobzr has something similar
[10:19] <dimitern> mgz: i got rid of cobzr and now i'm using just plain bzr
[10:27] <TheMue> dimitern: i do so too. switching branches is simple enough.
[10:41]  * TheMue is at lunch, bbiab
[10:49] <dimitern> fwereade_: https://codereview.appspot.com/8958043
[10:59] <fwereade_> dimitern, cheers
[11:00] <fwereade_> dimitern, is that a straight revert?
[11:00] <dimitern> fwereade_: yes
[11:00] <fwereade_> dimitern, excellent, if the tests pass then LGTM trivial
[11:01] <dimitern> fwereade_: running them now
[11:32] <jam> mgz: poke
[11:32] <danilos> jam: mumble is crashing for me :/
[11:32] <jam> danilos: :(
[11:38] <jam> danilos: still no love for mumble?
[11:38] <jam> mgz: still not around yet?
[11:38] <danilos> jam: nope, restarting pulseaudio didn't help either
[11:38] <jam> well, if mgz isn't around, then we can do a hangout, as he is the only one that doesn't have good access.
[11:40] <mgz> er, I'm here, but have turned off my hangout machine
[11:40] <mgz> ...really need to fix the clock on this
[11:40] <danilos> jam: sure, hangout or not?
[11:41] <jam> danilos: mgz made it onto mumble first, so we'll proxy you via irc
[11:41] <danilos> jam: ack
[11:41] <jam> danilos: you go firsrt
[11:41] <jam> to get it out of the way
[11:41] <danilos> jam: heh, fair enough
[11:41] <jam> how was your day
[11:42] <danilos> jam: it was decent, still fighting two remaining test failures with my keypair auth stuff; I also plan to start testing it --live
[11:42] <danilos> jam: I wonder if I need anything to be able to run against hp cloud other than the credentials I already got from you?
[11:43] <mgz> danilos: you shouldn't need anything else
[11:43] <jam> right, you shouldn't need more
[11:43] <danilos> mgz, jam: cool, I'll let you know how that goes then
[11:43] <jam> and the creds I got you should be "safe" from one of the bugs wallyworld_ noticed.
[11:43] <mgz> be a little careful about how you name your env and bucket, as that's a shared account (I assume)
[11:44] <jam> mgz: yes, it is
[11:44] <jam> danilos: sounds good
[11:44] <danilos> mgz, right
[11:51] <mgz> we're discussing non-interactive apt in the hook environments
[11:57] <danilos> mgz, any conclusions out of that discussion?
[11:59] <jam> danilos: it looks like it is actually doing the right thing there, so I'm on to debug why my charm isn't working correctly.
[11:59] <jam> for a sec we thought it wasn't setting DEBIAN_FRONTEND=noninteractive, but it looks like that isn't true
[12:00] <danilos> jam: interesting indeed
[12:08] <wallyworld_> fwereade_: hey, you around?
[12:08] <fwereade_> wallyworld_, hey
[12:09] <fwereade_> wallyworld_, oh crap, this is the same timing as yesterday :(
[12:09] <wallyworld_> wanna have a chat about the constraints stuff?
[12:09] <fwereade_> wallyworld_, would you be ok to chat about it in your morning? I can come on before I go to bed
[12:10] <fwereade_> wallyworld_, unless you'll be around in ~1h20 -- what's the time difference?
[12:11] <fwereade_> wallyworld_, I can't actually remember what city you're in
[12:11]  * danilos goes out to grab a quick bite
[12:12] <jam> anyone know if "juju set --config" actually does anything? It supports the option, but AFAICT it doesn't actually set anything.
[12:12] <jam> Or maybe the contents of the file changed?
[12:12] <fwereade_> jam, the --config format is a bit surprising
[12:12] <wallyworld_> fwereade_: it's 22:10 here now, if i can stay awake i'll ping you later or else let's do it my morning
[12:12] <fwereade_> wallyworld_, hey, I can do 15 mins now
[12:12] <wallyworld_> ok
[12:12] <fwereade_> wallyworld_, I'll start a hangout
[12:14] <jam> fwereade_: I think we broke the format supported by python-juju
[12:14] <jam> which is that the top-level item is "tarmac"
[12:14] <jam> we just do an unmarshal into a map[string][string] and then pass that in to s.SetConfig(options)
[12:14] <fwereade_> jam, oh *fuck*, I could have sworn rogpeppe was doing that?
[12:14] <jam> while we use the same s.SetConfig(options) from the commandline.
[12:15] <jam> sorry not "tarmac" but the name of the service
[12:15] <jam> rogpeppe: poke?
[12:15] <rogpeppe> fwereade_: no, it's an outstanding bug that we decided not to fix at the time
[12:16] <rogpeppe> jam: the top level items refers to the services to set the config options on i think
[12:16] <jam> rogpeppe: that is what it is supposed to be (what it was in python-juju), but doesn't seem to be the case in juju-core today
[12:16] <rogpeppe> jam: indeed
[12:17] <jam> rogpeppe: note that it is also broken for "juju deploy --config" then
[12:17] <rogpeppe> jam: yes
[12:18] <jam> bug #1162122
[12:18] <_mup_> Bug #1162122: deploy --config has no tests <juju-core:Triaged> <https://launchpad.net/bugs/1162122>
[12:18] <rogpeppe> jam: tbh i find the python format a bit weird (we say to a service "please set these config options if there happens to be a matching service name in here") but it should still be fixed to be compatible
[12:19] <rogpeppe> jam: i think there are actually tests
[12:19] <jam> rogpeppe: well, it would let you have all your config in one file for multiple services, and just have it pick out the right one at the right time.
[12:19] <rogpeppe> jam: they're just testing the wrong thing
[12:19] <rogpeppe> jam: it would make more sense if there was a call that said "set all these settings on all these services"
[12:21] <rogpeppe> jam: with just the config file as input
[12:21] <jam> rogpeppe: well, the service could be optional if you specify 'juju set --config'
[12:22] <rogpeppe> jam: yeah, that would make much more sense
[12:22] <jam> :q
[12:22] <rogpeppe> jam: it would be nice if there was some way of reliably telling the two-level config from the one-level config. that way you could have some settings in a config file that would apply to a given charm regardless of its service name.
[12:24] <rogpeppe> jam: (that's the way juju is now, but we're going to remove that possibility by making it compatible)
[12:24] <jam> rogpeppe: well, you could look for a top level key that matches the service name, and if it exists, recurse into it
[12:25] <jam> though it leaves you open to 'interpretation' if you ever had key collisions
[12:25] <rogpeppe> jam: it's quite possible that there's a ... yeah
[12:25] <rogpeppe> jam: i much prefer to avoid heuristics when possible
[12:29] <rogpeppe> jam: bug #1167465
[12:29] <_mup_> Bug #1167465: service set (and deploy) uses wrong YAML config syntax <juju-core:New> <https://launchpad.net/bugs/1167465>
[12:31] <rogpeppe> it's a pity we've got YAML going over the wire at all. if it wasn't such an abstruse format, there would be a decent js parser for it and we wouldn't need to do that.
[12:32] <rogpeppe> because it would make much more sense for the client side to inspect the yaml and decide which settings to use based on the service name, then send just those settings
[13:12] <mgz> er... who has the creds to put tools in canonistack?
[13:12] <gary_poster> Hi all.  I'd like to announce the GUI's compatibility with juju core, but the Raring Juju from the devel PPA fails for me like this: http://pastebin.ubuntu.com/5598967/
[13:12] <gary_poster> Is that known?  Is there some other, better way to suggest that people try out the GUI on juju core?  I didn't figure installing juju from source was the right sales pitch :-)
[13:15] <rogpeppe> gary_poster: yes, it's known and waiting on a fix to cloud-init in raring, i believe
[13:15] <rogpeppe> gary_poster: we did have a fix but it was backed out on request
[13:15] <gary_poster> ok cool rogpeppe thanks.  So we shouldn't announce till that is in backports?
[13:15] <rogpeppe> gary_poster: and we were assured that the lifetime of the bug was "measured in days"
[13:15] <gary_poster> :-)
[13:17] <rogpeppe> gary_poster: i think we could announce but say that we can't currently bootstrap a raring instance (referencing the bug number). you shouldn't see this issue if you set default-series=precise
[13:17] <hazmat> gary_poster, your launching a precise env? rogpeppe if so that  doesn't sound like the raring bug.
[13:17] <hazmat> the raring cloud init bug
[13:17] <rogpeppe> hazmat: i presumed he was launching a raring env
[13:17] <rogpeppe> hazmat: yeah
[13:18] <gary_poster> rogpeppe, sorry, I am launching a precise instance from raring
[13:18] <gary_poster> default-series: precise
[13:18] <gary_poster> in environment
[13:18] <hazmat> rogpeppe, default is precise. he's using raring client
[13:18] <rogpeppe> gary_poster: hmm
[13:18] <hazmat> well dev ppa client
[13:18] <gary_poster> I had to do --upload-tools
[13:18] <rogpeppe> hazmat: doesn't upload-tools make it default to current series?
[13:18] <gary_poster> Maybe that is related?
[13:19] <rogpeppe> gary_poster: have you ssh'd to the bootstrap instance and looked at cloud-init-output.log ?
[13:19] <gary_poster> I think that was changed a while ago: at least on quantal we've been able to launch precise instances with --upload-tools
[13:19] <hazmat> rogpeppe, it also uploads precise.. i hope it doesn't re change default series..
[13:19] <gary_poster> no rogpeppe, will look.  /var/log/...?
[13:20] <hazmat> the result for that error was nothing on the other side..
[13:20] <rogpeppe> gary_poster: yes
[13:20] <gary_poster> k
[13:20] <rogpeppe> hazmat: yup
[13:20] <hazmat> rogpeppe, is "error: cannot log in to admin database: auth fails" cannot connect to remote side?
[13:21]  * hazmat pokes around
[13:21] <rogpeppe> hazmat: it means that we've got as far as starting mongo, but jujud bootstrap-state failed
[13:21] <rogpeppe> hazmat: so yeah, it's not the raring bug
[13:22] <rogpeppe> gary_poster: might be worth doing "cat /etc/os-release" on the remote instance too, just to make sure it really has booted precise
[13:23] <gary_poster> ack rogpeppe.  (restarting instances)
[13:23] <TheMue> gary_poster: also which juju release (1.9.14 or 1.10.0)
[13:23] <rogpeppe> TheMue: he used --upload-tools
[13:24] <rogpeppe> TheMue: so it shouldn't make a deal of difference
[13:24] <gary_poster> TheMue, how do you tell, anyway?  I tried --version but that gave an error message
[13:24] <ahasenack> I just bootstrapped on ec2 and I didn't need to use --upload-tools, fwiw
[13:24] <TheMue> rogpeppe: "shouldn't" is the right answer ;)
[13:24] <rogpeppe> ahasenack: with 1.10 ?
[13:24] <ahasenack> rogpeppe: yes
[13:24] <gary_poster> cool ahasenack.  I'll try that after
[13:24] <rogpeppe> ahasenack: maybe we have got 1.10 in the publiuc bucket after all then
[13:24] <ahasenack> http://pastebin.ubuntu.com/5601017/
[13:25] <ahasenack> rogpeppe: gary_poster ^^^
[13:25] <gary_poster> cool
[13:25] <rogpeppe> ahasenack: cool. i thought noone had acquired the right permissions to do that yet. i guess davecheney might've done it.
[13:27] <ahasenack> rogpeppe: still missing in canonistack, though
[13:27] <ahasenack> but that's a "private" matter ;)
[13:27] <rogpeppe> ahasenack: :-)
[13:27] <ahasenack> as in, private cloud
[13:28] <TheMue> rogpeppe: imho he handled it with martin yesterday
[13:29] <rogpeppe> TheMue: cool
[13:36] <gary_poster> rogpeppe, unsurprisingly juju ssh 0 fails with same error, as does juju status.  There is a clear error in the log though: https://pastebin.canonical.com/89982/ .
[13:37] <gary_poster> rogpeppe, and it definitely is precise
[13:37] <gary_poster> ahasenack, were you starting a precise instance?
[13:37] <rogpeppe> gary_poster: you can't use juju ssh
[13:37] <rogpeppe> gary_poster: you'll have to use ssh directly
[13:37] <gary_poster> rogpeppe, yup, figured that, I did, and that's how I got the pastebin :-)
[13:37] <rogpeppe> gary_poster: try: ssh ubuntu@instance
[13:37] <ahasenack> gary_poster: yes, I have default-series precise
[13:37] <gary_poster> ahasenack, huh.  I may just want to try not using --upload-tools
[13:38] <gary_poster> now that this works
[13:38] <ahasenack> it used ami-d0f89fb9
[13:38] <ahasenack> (us-east-1)
[13:38] <ahasenack> that's 099720109477/ubuntu/images/ebs/ubuntu-precise-12.04-amd64-server-20130411.1
[13:38] <gary_poster> ahasenack, same here
[13:39] <gary_poster> (but I used upload-tools)
[13:39] <rogpeppe> gary_poster: hmm, weird
[13:39] <rogpeppe> gary_poster: ah i know!
[13:39] <rogpeppe> gary_poster: you were using --upload-tools but you hadn't done "go install"
[13:39] <gary_poster> so upload tools doesn't work from PPA
[13:39] <gary_poster> cool, makes sense
[13:40] <gary_poster> I was somewhat surprised when it worked on my quantal machine
[13:40] <gary_poster> ok, will kill and retry without --upload-tools.  Thanks rogpeppe and ahasenack
[13:41] <rogpeppe> gary_poster: juju --upload-tools should check that the command line client is the same version as the tools that have been built.
[13:42] <rogpeppe> gary_poster: although that's not really sufficient either.
[13:43] <rogpeppe> gary_poster: perhaps upload-tools should build the tools and then run them to do the actual bootstrap
[13:46] <gary_poster> rogpeppe, that sounds potentially good.  Alternatively, --upload-tools could simply fail (with helpful message) if you are not running from a devel juju?
[13:46] <ahasenack> hm, juju-log in juju-core does not have a --log-level parameter
[13:46] <ahasenack> pyjuju does
[13:46] <ahasenack> keystone charm failed to deploy:
[13:46] <rogpeppe> gary_poster: that wouldn't fix the most common failure scenario that i encounter
[13:46] <ahasenack> 2013/04/25 13:39:25 INFO worker/uniter: HOOK subprocess.CalledProcessError: Command '['juju-log', '--log-level', 'INFO', 'Configuring Keystone to use a random admin token.']' returned non-zero exit status 2
[13:47] <rogpeppe> ahasenack: hmm, i thought we just ignored that
[13:47] <rogpeppe> pwd
[13:47] <ahasenack> it said
[13:47] <ahasenack> 2013/04/25 13:39:25 INFO worker/uniter: HOOK error: flag provided but not defined: --log-level
[13:47] <ahasenack> should I file a bug?
[13:47] <hazmat> yes
[13:48] <rogpeppe> ahasenack: yeah. we accept (and ignore) -l, but don't define --log-level
[13:48] <rogpeppe> ahasenack: which should be defined as an alias
[13:48] <ahasenack> -l is an alias for --log-level?
[13:48] <ahasenack> ok
[13:48] <rogpeppe> ahasenack: thanks for finding it
[13:49] <ahasenack> #1172717
[13:49] <_mup_> Bug #1172717: juju-log does not accept --log-level <juju-core:New> <https://launchpad.net/bugs/1172717>
[13:55] <ahasenack> hm, found another incompatibility
[13:55] <ahasenack> the charm directory layout changed a bit, and the keystone charm makes some assumptions
[13:55] <ahasenack>     juju_rc_path = "/var/lib/juju/units/%s/charm/%s" % (unit_name, script_path)
[13:55] <ahasenack> that does not exist in units deployed by go-juju
[13:56] <rogpeppe> ahasenack: i think that's an unwarranted assumption on the part of the keystone charm
[13:56] <rogpeppe> ahasenack: i don't think there has every been a guarantee of the current directory
[13:56] <rogpeppe> s/every/ever/
[13:57] <ahasenack> rogpeppe: I agree
[13:57] <rogpeppe> ahasenack: it should really use $CHARM_DIR
[13:59] <ahasenack> rogpeppe: is that an env var exported by both pyjuju and juju-core?
[13:59] <rogpeppe> ahasenack: i think so, yes
[13:59] <ahasenack> ok
[14:00] <rogpeppe> fwereade__: what do you say to removing jujuc log --debug and making --log-level work correctly?
[14:01] <rogpeppe> fwereade__: given that we now do actually have log levels
[14:01] <fwereade__> rogpeppe, do we have no users of --debug? I thought it pre-existed
[14:01] <fwereade__> rogpeppe, if we don't definite +1
[14:01] <rogpeppe> fwereade__: not AFAICS in /juju/hooks/cli.py
[14:01] <fwereade__> rogpeppe, even if we do +1 to using log levels
[14:01] <rogpeppe> fwereade__: but i may be missing another place
[14:02] <fwereade__> rogpeppe, sweet
[14:02] <fwereade__> rogpeppe, kill it kill it kill it
[14:02] <rogpeppe> fwereade__: need to fix general log-level setting first
[14:02] <fwereade__> rogpeppe, agreed
[14:03] <gary_poster> FWIW, verified that juju-gui works.  Do I need to suggest that people install the devel PPA, or should the default Raring juju-core work?  I'm using the devel PPA
[14:03] <gary_poster> I suppose I could uninstall juju-core, uninstall the PPA, reinstall juju-core, and verify...
[14:03] <gary_poster> but if someone knows off hand that would be convenient :-)
[14:05] <mgz> the bucket probably just needs the the version from the archive as welll...
[14:05] <mgz> I can do that and see
[14:05] <ahasenack> gary_poster: the instructions at juju.ubuntu.com already say to install the devel ppa iirc
[14:05] <mgz> some funny versioning business went on, didn't think the juju tool picking loguc would care
[14:06] <gary_poster> ahasenack, right you are, thanks.  But that may be specific to < raring.  So mgz, you are doublechecking to see if default raring juju-core works OK?
[14:08] <mgz> well, people already had, but I'm trying something else to see if it makes a difference for you
[14:25] <rogpeppe> oh wonderful "Your fault is due to major damage to cabling affecting all providers in your area. Engineers are working to resolve ASAP. We apologise for no fix time."
[14:29] <TheMue> rogpeppe: so a wonderful mca
[14:29] <rogpeppe> TheMue: mca?
[14:29] <TheMue> rogpeppe: maximum credible accident
[14:30] <rogpeppe> TheMue: ha.
[14:30] <rogpeppe> TheMue: the fact that most people in the street don't have a problem seems to give the lie to it
[14:30] <TheMue> rogpeppe: or they use lte ;)
[14:31] <rogpeppe> TheMue: lte?
[14:31] <TheMue> rogpeppe: 4g
[14:31] <rogpeppe> TheMue: some do, yeah, but lots don't. my neighbour who's also affected has been canvassing other folks in the street and finding out
[14:32] <TheMue> rogpeppe: http://en.wikipedia.org/wiki/LTE_(telecommunication)
[14:33] <dimitern> https://codereview.appspot.com/8540050
[14:33] <TheMue> rogpeppe: most aren't so depending on it like you (we). so it's inconvenient, but it doesn't really hurts. they then use their mobiles or the internet at work.
[14:33] <dimitern> so there's a mistake in the desc, sorry, the bug is 1040210, not 1040203
[14:36] <rogpeppe> dimitern: looking
[14:37]  * dimitern bbi30m
[14:43] <rogpeppe> dimitern: reviewed
[14:53] <rogpeppe> fwereade__, ahasenack: trivial? https://codereview.appspot.com/8955044
[14:54] <ahasenack> rogpeppe: if that adds --log-level as an alias to -l, +1 :)
[14:55] <rogpeppe> ahasenack: yup, that's it.
[14:55] <fwereade__> rogpeppe, LGTM trivial
[14:56] <rogpeppe> fwereade__: thanks
[15:02] <rogpeppe>  hmm, "package" is not a great name for a type in go
[15:05] <mgz> I try to use "if" as a variable name sometimes
[15:06] <dimitern> rogpeppe, TheMue: thanks
[15:07] <rogpeppe> i always find it interesting how much ambiguity the brain resolves automatically
[15:08] <rogpeppe> i'll have used the same variable name in two entirely different ways in a function and have no problem with it until the compiler tells me
[15:08] <rogpeppe> and then it's like "how tf didn't i notice that?"
[15:09] <fwereade__> dimitern, reviewed
[15:10] <dimitern> fwereade__: cheers
[15:20] <dimitern> enter the saucy salamander (13.10) :D - http://www.markshuttleworth.com/archives/1252
[15:23] <TheMue> dimitern: yeah, just read it
[15:29] <dimitern> fwereade__, rogpeppe: replied to the reviews, will need some help - please take a look
[15:43] <fwereade__> dimitern, responded
[15:45] <dimitern> fwereade__: thanks
[15:51] <Daviey> mgz: Hey, Did i understand correctly that you created the release tarball for juju-core?
[15:52] <mgz> Daviey: yes, all complaints to be directed at me.
[15:53] <Daviey> mgz: That'll have to wait until we have a big bottle of port, and soe fine cheese.
[15:54] <Daviey> mgz: The reason for asking.. Can you wiki-ify what you did, whilst it's still fresh?  (I imagine there was some sausage making, but that is OK).  What you did is a good basis for next time :)
[15:54] <mgz> yeah, I'm writing up release process stuff today
[15:56] <Daviey> mgz: superb
[16:17] <dimitern> i'm off guys
[16:17] <mgz> later dimitern
[16:17] <dimitern> see you tomorrow and good evening
[17:53] <mramm> Two new bugs from end users: 13:52 dpb_: mramm: https://bugs.launchpad.net/juju-core/+bug/1172814, https://bugs.launchpad.net/juju-core/+bug/1172811
[17:53] <_mup_> Bug #1172814: Need a way to run an end-to-end test on a juju environment. <juju-core:New> <https://launchpad.net/bugs/1172814>
[17:53] <_mup_> Bug #1172811: Need a way to watch juju-core environements <juju-core:New> <https://launchpad.net/bugs/1172811>
[18:07] <rogpeppe> mramm: thank. i've responded to the second one.
[18:07] <rogpeppe> thanks, even
[19:13] <rogpeppe> right, that's me for the day
[19:13] <rogpeppe> g'night all
[20:08] <mramm> anybody know anything about the issues folks are reporting with sync-tools ?
[20:08] <mramm> that sounds like a high priority bug to me
[20:11] <ahasenack> http://pastebin.ubuntu.com/5602223/ for reference
[20:13] <mramm> hmm, looks like another issue we've seen caused by a packaging bug in go 1.0.2, we will investigate right away
[20:55] <thumper> morning folks