[00:00] <thumper> oh?
[00:00] <voidspace> we need to use a new session every time we execute a query against a collection
[00:00] <thumper> voidspace: and put them where?
[00:00] <voidspace> so they shouldn't be long lived
[00:00] <voidspace> we should fetch them when we need them
[00:00] <thumper> fair call
[00:00] <voidspace> but we shouldn't create a new session just to use the name
[00:00] <thumper> correct
[00:00] <voidspace> so I'm just using the name
[00:00] <thumper> make package constants
[00:00] <voidspace> the pattern just seemed a bit odd
[00:01] <thumper> please use a named constant not just a naked string
[00:01] <voidspace> ok, I'll have to go back and change the ones I've done already
[00:01] <thumper> hopefully that would be pretty mechanical
[00:02] <voidspace> sure
[00:04] <wallyworld> voidspace: +1 to constants
[00:04] <voidspace> yep, doing it
[00:05] <wallyworld> you also need to sleep
[00:07] <voidspace> not quite mechanical, the const names will clash with the obvious name for the column collection - so I'll have to append a Col suffix to those
[00:07] <voidspace> wallyworld: soon enough
[00:08] <wallyworld> you have 1 more day to work on this, right?
[00:08] <thumper> voidspace: or "Collection"
[00:08] <wallyworld> lol
[00:08] <voidspace> wallyworld: yep
[00:09] <voidspace> wallyworld: just getting this to compile will be an achievement
[00:09] <wallyworld> voidspace: make it Cxn to piss off thumper
[00:09]  * thumper slaps wallyworld with a wet fish
[00:09] <voidspace> thumper: Col works for Column and Collection - and they're both
[00:09] <voidspace> Columnection
[00:09] <thumper> voidspace: but it isn't both is it?
[00:09] <voidspace> it is
[00:09] <voidspace> it's a collection representing a column
[00:09] <thumper> it is either the name of the collection, or the collection itself
[00:10] <wallyworld> voidspace: non relational dbs don't have columns :-)
[00:10]  * thumper has no time to bikeshed names
[00:10] <thumper> voidspace: call them "a", "b", "c" and so on
[00:10] <voidspace> hah, it's a collection not a column
[00:10]  * thumper leaves
[00:10] <voidspace> correct
[00:10] <voidspace> this is why you need to study maths to be a programmer
[00:10] <thumper> voidspace: and religion
[00:10] <voidspace> if you haven't done algebra how else would you know that variables should have single letter names
[00:11] <voidspace> no-one should study religion
[00:11] <voidspace> either live it or ignore it
[00:13]  * wallyworld afk for a bit
[01:02] <voidspace> wallyworld: made a dent in it
[01:02] <voidspace> wallyworld: into machines.go switching to the new style collection access
[01:02] <voidspace> wallyworld: https://github.com/voidspace/juju/compare/copy-sessions
[01:02] <voidspace> wallyworld: hoping for compilation tomorrow
[01:02] <voidspace> g'night all
[01:41] <axw> wallyworld: https://github.com/juju/juju/pull/331
[02:07] <wallyworld> axw: you free now?
[02:08] <axw> wallyworld: just a sec, making tea
[02:08] <wallyworld> ok, no hurry
[03:57] <thumper> well, that's blown it
[03:58] <davecheney> ?
[03:58] <thumper> at the museum thinking I could work in the cafe while the kids played
[03:58] <thumper> but I need to be in the discovery world with them
[03:58] <thumper> currently propped in the corner with laptop on my lap
[03:58] <thumper> not entirely comfortable
[04:25] <davecheney> thumper: i can't stand it any longer
[04:25] <davecheney> i'm going for afternoon coffee
[04:25] <davecheney> do you want to do HR stuff today ?
[04:33] <menn0> review pls: https://github.com/juju/juju/pull/333/files
[04:49] <axw> wallyworld: part 2: https://github.com/juju/juju/pull/336
[04:49] <axw> I'll do azure in a followup
[04:49] <wallyworld> axw: looking after i finish the current review
[04:50] <axw> thanks
[05:08] <axw> wallyworld: FYI, here's the followup too: https://github.com/juju/juju/pull/337
[05:08] <axw> includes the commit from 336
[05:08] <wallyworld> rightio
[05:08] <wallyworld> axw: i'd love to get rid of the remaining old connection guff from juju/testing/conn.go i think it is
[05:09] <wallyworld> the bit that does all the side effecty state open stuff
[05:10] <wallyworld> i think the only thing we really want to keep from there is PutCharm
[05:10] <axw> wallyworld: which bits can go? MongoInfo/APIInfo? I'm pretty sure things still use them...
[05:11] <axw> JujuConnSuite is everywhere
[05:11] <wallyworld> axw: the newState() stuff
[05:11] <axw> ah, ok
[05:12] <axw> as in collapse State/BackingState
[05:12] <wallyworld> yeah
[05:12] <axw> I can take a look at that after I fix up EnsureNotBootstrapped if you like
[05:12] <wallyworld> and we also do need to fix JujuConnSuite and ConnSuite (there's 2 of them)
[05:12] <wallyworld> sure, it was just a heads up - one of us will get there first
[05:13] <axw> okey dokey
[05:13] <wallyworld> will be great to clean all this shit up
[05:13] <axw> indeed
[05:14] <axw> I was nearly tempted to remove the use of JujuConnSuite in the provisioner code, but didn't want to get too sidetracked
[05:29] <wallyworld> yeah, separate piece of work :-)
[06:18] <axw> fwereade: hey, are you about?
[06:18] <fwereade> axw, hey dude
[06:18] <axw> fwereade: thought you may want to skim https://github.com/juju/juju/pull/336 before I land it
[06:19] <axw> in case you have different ideas about how this should look
[06:19] <fwereade> axw, cheers, I'll take a super-quick look
[06:19] <axw> fwereade: description alone may be enough
[06:20] <fwereade> axw, description LGTM
[06:20] <fwereade> axw, I'd say that I'm not convinced that replacing the storage-based implementations is ideal
[06:21] <fwereade> axw, I would prefer to see us move in a direction in which environs have an explicit SetStateServerInstances method
[06:21] <fwereade> axw, (which can be backed by storage or tagging or whatever)
[06:21] <axw> fwereade: which would add a tag to an instance?
[06:21] <fwereade> axw, but post-bootsrtap, I think it's really up to the HA code to determine who's *really* meant to be a state server, and to keep the env updated with that knowledge
[06:22] <axw> I see
[06:22] <fwereade> axw, yeah -- and remove that tag from non-state-servers, I think
[06:23] <fwereade> axw, I mean, yeah, the storage-based implementation isn't great, I'm not *attached* to it
[06:23] <axw> fwereade: given that we can't do that with azure, I don't think we can get away from tying state-serveryness from provisioning any time soon
[06:23] <rogpeppe> fwereade: does an Environ need to know about the state server instances at all?
[06:23] <fwereade> axw, but I feel like where we really fall short is in maintaining the important info at an env level, and the less-than-ideal implementation backing our attempts isn't my main focus
[06:24]  * axw nods
[06:24] <fwereade> rogpeppe, yes, IMO, I am not willing to discard that functionality
[06:25] <fwereade> rogpeppe, I've heard plenty of arguments as to why it's kind of a hassle, and why we often don't need it, but IMO any time we force people to manage a juju environment via their provider dashboard we have *failed*
[06:25] <rogpeppe> fwereade: i'm not suggesting that an a provider wouldn't be able to provide an implementation of the state-server-instanceid storage, but that it could be something independent of Environ
[06:26] <rogpeppe> fwereade: then one could arbitrarily compose instance id storage and Environ
[06:26] <rogpeppe> fwereade: just a thought. please ignore me :-)
[06:27] <fwereade> rogpeppe, I definitely think it's part of environ's responsibility -- but equally I am fine with the idea that we could/should be able to delegate that functionality elsewhere
[06:27] <axw> rogpeppe: I don't see how it could be independent, unless we require something like storage. it always has to be external to the environment, which means leaning on something provider-specific
[06:28] <fwereade> axw, or just a little remember-my-state-servers web service that we provide independently
[06:28] <fwereade> axw, it's not inextricably tied in *implementation* to any specific provider
[06:28] <axw> right, if we had a global thingy that would work
[06:28] <fwereade> axw, I just remain adamant that it's a responsibility of the environ interface, independent of where we actually storeit
[06:28] <rogpeppe> axw: my thought is that there are many possible ways to do it (e.g. with some external web service). an instance-id storage service could be something that an Environ could be asked for, but wouldn't necessarily have to implement.
[06:28] <axw> fwereade: I agree with that
[06:29] <axw> rogpeppe: ah right, yes.
[06:29] <axw> we could definitely delegate to some provider-independent thing
[06:29] <rogpeppe> axw: rather than forcing all providers to know about all possible kinds of external instance-id storage services
[06:31] <rogpeppe> fwereade: the reason i don't see it as a fundamental part of Environ is that the provider really couldn't care less about where instance-ids are stored. That's why I see it (potentially) as a service that the Environ *can* provide but not one that the Environ *must* provide.
[06:32] <fwereade> rogpeppe, I see it as part of the responsibility of the Environ instance to keep track of what happened when you called Bootstrap -- but indeed not necessarily as something that has to be provider-specific
[06:33] <rogpeppe> fwereade: i would imagine that Bootstrap could take an instance-id storage service as an argument. That storage service might have been provided by the Environ itself, or externally.
[06:45] <wallyworld__> fwereade: the reason the storage based impl was replaced is due to the explicit direction given my mark s
[06:45] <wallyworld__> by
[06:45] <wallyworld__> that we should evolve towards removing cloud storage
[06:46] <fwereade> wallyworld__, hmm, I feel like there's a bit more nuance there
[06:46] <fwereade> wallyworld__, removing juju-level dependency on it is definitely important
[06:46] <wallyworld__> i agree we also want a SetStateServerInstances, but that is somewhat ortogonal to the current work and can come later
[06:47] <fwereade> wallyworld__, this feels like it goes further, and is close to mandating that we shouldn't use provider storage even if it exists
[06:47] <wallyworld__> fwereade: exactly, that was his direction
[06:48] <wallyworld__> he quited the recent swift config issues
[06:48] <wallyworld__> quoted
[06:48] <wallyworld__> as justification for why we need to eliminate it even if it exists
[06:49] <fwereade> wallyworld__, heh, ok then, I don't fully agree but it's not a hill I'm interested in dying on
[06:50] <wallyworld__> fwereade: i'm with you tbh
[06:50] <wallyworld__> but
[06:50] <wallyworld__> we have been told :-)
[06:50] <fwereade> wallyworld__, yep :)
[06:53] <rogpeppe> FWIW, the instance-id storage is the *only* place we *cannot* rely on state-server provided storage
[06:53] <axw> yup
[06:53] <fwereade> rogpeppe, understood, agreed
[06:56] <rogpeppe> ISTR some general agreement that we could potentially move away from instance-id storage and store only instance addresses instead
[06:56] <rogpeppe> or potentially just state server host-ports
[06:57] <axw> rogpeppe: what's the point of storing the addresses if they may be out of date?
[06:57] <rogpeppe> axw: the environment itself keeps them up to date
[06:57] <rogpeppe> axw: if the environment is moribund, there's not that much point in knowing its instance ids
[06:59] <Egoist_> Hi
[06:59] <wallyworld> not sure. if we use instance tagging, we can just query the env's instance pool for the start server instances
[07:00] <rogpeppe> axw: the "keeping them up to date" piece of the HA work is still to do, AFAIK. that was mainly because I wanted to make that change as part of it (otherwise there's an impedance mismatch between StateServerHostPorts and the instance id storage)
[07:01] <Egoist_> Why when I add new unit to service the other units can't get relation data, even if relation-set was executed?
[07:02] <fwereade> Egoist_, expand please? relation-set is not flushed to the state server until the hook in which it was called completes successfully, but I'm not sure that's what you're seeing?
[07:07] <rogpeppe> would anyone like to take a look over this charm store PR? it's the core of the new charm store, and i think it's quite neat actually :-] https://github.com/juju/charmstore/pull/14
[07:07] <fwereade> axw, rogpeppe: fwiw I think that the only impedance mismatch is in trying to use only a single piece of data for two purposes -- agents/clients need to know addresses to connect to, environs need to know instances to manipulate, it's about tuning the info to the context it'll be used in. IMO this implies we want 2 separate methods (and 2 separate watchers that'd probably still just share an impl), not that we should make environs concern it
[07:07] <fwereade> self with addresses when it's fundamentally concerned with instances
[07:08] <Egoist_> fwereade, No, I mean that in peer relation, when I add new unit this new unit can get relation data about other unit, but other units who was in relation before adding new unit can't get relation data
[07:08] <rogpeppe> fwereade: do we ever use the state server instance ids for anything other than turning into a state server address?
[07:09] <Egoist_> btw. what about charm, who is responsible about charms in charmstore?
[07:10] <rogpeppe> Egoist_: the top level ("promulgated") charms are reviewed and gated for quality and appropriacy by folks at Canonical.
[07:12] <Egoist_> rogpeppe: the top level ("promulgated") charms -> You mean charms that are more important for juju like juju-gui?
[07:12] <rogpeppe> Egoist_: i mean any charm that doesn't have "~" in the name
[07:12] <rogpeppe> Egoist_: (which is probably all the charms you've actually seen :-])
[07:12] <fwereade> rogpeppe, not sure we do, that doesn't mean that addresses are the correct expression of the info at the environ level
[07:13] <axw> fwereade, rogpeppe: we currently use StateServerInstances only to generate API addresses (and soon to determine whether the environment is bootstrapped)
[07:13] <fwereade> Egoist_, at the point the old units try to get the data, what hooks have successfully run on the new unit?
[07:14] <axw> I don't think provider implementations should be thinking about API addresses, though. If we somehow pulled instance ID storage out of Environ then we could make it not-the-environ's-concern, but as it is I don't think Environ should know anything about API addresses
[07:14] <fwereade> axw, +1
[07:14] <Egoist_> -relation-joined and -relation-changed
[07:15] <Egoist_> fwereade:
[07:15] <rogpeppe> fwereade: i guess i'm trying to say that this concern is actually entirely independent of the environ. the only exception being, i guess, the fact that Environ.Bootstrap knows about it.
[07:15] <rogpeppe> axw: +1 too
[07:15] <fwereade> rogpeppe, and that we want to know it to tell if the environ's bootstrapped, too, right?
[07:15] <fwereade> rogpeppe, "these are the instances" is a lot more direct and appropriate than "here are some addresses"
[07:16] <fwereade> rogpeppe, (and apart from anything else addresses are deeply problematic anyway, there's this infuriating pervasive assumption that the set of state server addresses is a single property of the environment)
[07:17] <fwereade> rogpeppe, (it's really not: different networks, different scopes -> (potentially) different set of state server addresses per agent)
[07:17] <rogpeppe> fwereade: interesting.
[07:17] <fwereade> rogpeppe, that's one of the this-really-isn't-bulk things that has had me all grumped up for a while
[07:17] <fwereade> rogpeppe, it's not "what are the state server addresses for an environment"
[07:18] <axw> :q
[07:18] <axw> oops
[07:18] <fwereade> rogpeppe, it's "what addresses should X entity use to connect"
[07:18] <fwereade> Egoist_, what's the error you see on the old units when you try to read the relation data you set in joined/changed?
[07:18] <wallyworld__> axw: lucky it wasn't your password :-)
[07:18] <axw> :)
[07:19] <fwereade> brb
[07:19] <rogpeppe> fwereade: yeah, it's a maze of tunnels and there are no universal addresses for anything.
[07:23] <Egoist_> fwereade: nothing error i guess, it's from charm code and it say that relation data is no exist -> In python language relation data is None
[07:23] <Egoist_> fwereade: btw, is there any tool to debug relation problem or something like that?
[07:28] <fwereade> Egoist_, you can use `juju run` to execute arbitrary code in a hook context; and you can use `juju debug-hooks` to start a session that gives you a session that lets you run each hook
[07:28] <fwereade> Egoist_, but, hmm, None is very weird
[07:29] <fwereade> Egoist_, I'd expect at least private-address to be set
[07:35] <Egoist_> fwereade: yeah, and can't get any data set by relation set
[07:36] <fwereade> Egoist_, so, just to be clear: there's a new unit that the old ones know about (they've run its joined hook) but for which they can't see any data?
[07:36] <fwereade> Egoist_, (they've run *or are running*)
[07:37] <Egoist_> rogpeppe: yeah, I don't see charm with '~' in name. But with who I need to speak about bugs in charms/
[07:37] <Egoist_> ?
[07:40] <Egoist_> fwereade: there's a new unit and this unit know about other ones, but old ones can't get any relation even about themself so i don't know is they don't know about this new unit
[07:41] <Egoist_> fwereade: thev've run
[07:42] <Egoist_> fwereade, no no sorry, they are running
[07:42] <fwereade> Egoist_, hmm, that sounds like we can isolate it to just the old units anyway then?
[07:43] <fwereade> Egoist_, what exactly are you running on those units, and in what hook, and where did you get the unit names from?
[07:43] <fwereade> Egoist_, btw https://bugs.launchpad.net/charms ?
[07:47] <TheMue> morning
[07:49] <Egoist_> fwereade: what exactly are you running on those units -> trying to deploy mongodb charm maintain by myself | and in what hook -> in -relation-changed | and where did you get the unit names from -> from relation-list
[07:51] <fwereade> Egoist_, ok, I'm scratching my head here a little bit -- is it possible you could come up with an absolutely minimal charm that repros what you're seeing and report a bug against juju-core that references the charm?
[07:51] <fwereade> bbs
[07:53] <Egoist_> fwereade: yeah, i think i could do that
[08:04] <fwereade> Egoist_, awesome, tyvm
[09:00] <mattyw> rogpeppe, ping?
[09:01] <rogpeppe> mattyw: hiya
[09:36] <TheMue> one trivial one for the OCR: https://github.com/juju/juju/pull/338
[10:00] <TheMue> vds: ping, you’re OCR today ;)
[10:20] <voidspace> how do I push without running the pre-push hook?
[10:21] <voidspace> I need to push a branch that doesn't compile
[10:22] <TheMue> voidspace: eh, why that?
[10:22] <voidspace> TheMue: because I've made a big change and it will be a while before it compiles and I don't want it only on my computer
[10:22] <voidspace> I want to push my wip
[10:22] <voidspace> I think there's a command line flag, can't find it though
[10:22] <TheMue> voidspace: ah, to your personal repo?
[10:23] <voidspace> TheMue: no, to master of course ;-)
[10:23] <voidspace> TheMue: yeah, to my repo - but the pre push check runs for that too
[10:23] <TheMue> voidspace: eh, the question mark has been by accident ;)
[10:23] <voidspace> hehe
[10:24] <TheMue> voidspace: hmm, isn’t the hook already running before commiting? not before pushing?
[10:24] <voidspace> TheMue: no, it's pre-push
[10:25] <voidspace> TheMue: at least if you follow the instructions in CONTRIBUTING
[10:25] <voidspace> the command line flag is --no-verify
[10:25] <TheMue> voidspace: ouch, I only have a pre-commit *blush*
[10:26] <voidspace> pre-commit is even stricter!
[10:26]  * TheMue has to take a deeper look into his git hooks
[10:30] <TheMue> so, added it too
[10:31] <TheMue> I’m running most of it manually from inside vim, so no problems so far
[10:31] <voidspace> cool
[10:32] <TheMue> voidspace: could you please take a look at https://github.com/juju/juju/pull/338? it’s a very trivial one.
[10:32] <voidspace> looking
[10:32] <TheMue> voidspace: thx
[10:32] <voidspace> TheMue: the hash change is markdown syntax?
[10:32] <voidspace> I'm not familiar with markdown
[10:33] <voidspace> TheMue: have you run it through a processor to check the output?
[10:33] <TheMue> voidspace: yep, the [10:33] <voidspace> ok
[10:33] <TheMue> voidspace: yep, and took a look on it in GH itself which renders it fine
[10:34] <voidspace> I think the [10:35] <TheMue> voidspace: maybe, but it’s only habituation. we want to render all docs later from md in GH direkt to HTML on j.u.c
[10:35] <voidspace> well, I think they look more like headings - so not just habituation
[10:36] <TheMue> ok
[10:36] <voidspace> If we need the alternative format then fine
[10:36] <TheMue> in other md docs nick and i use # because very often we need deeper nestings than h2
[10:37] <voidspace> at least we're not using latex
[10:38] <TheMue> voidspace: hey, I wrote my golang book in latex, so please don’t complain :D
[10:38] <voidspace> hah
[10:39] <TheMue> voidspace: btw, my IPv6 info collection so far is at https://docs.google.com/a/canonical.com/document/d/1wfdGL_vyemT2-ncAB7KIySkKI9HbT8efKeC3Sd8ID0I/edit#
[10:39] <voidspace> cool
[10:40] <TheMue> voidspace: very raw, no real concept, only a collection of links and snippets
[10:40] <voidspace> TheMue: I won't get a chance to look at it today - I'm off next week and need to get this branch as close to done as possible
[10:40] <voidspace> even getting it to compile will be a challenge :-/
[10:40] <voidspace> I'll bookmark it for later
[10:40] <TheMue> voidspace: ok, nopro
[10:40] <voidspace> I'll be back with you guys on networking on my return
[10:41] <TheMue> voidspace: a quick vacation? dimiter is diving on malta these days
[10:42] <voidspace> nice
[10:42] <voidspace> I'd love to go diving
[10:42] <TheMue> never done that
[10:42] <voidspace> me neither
[10:43] <TheMue> I would like to do the opposite, flying and parachuting
[10:43] <voidspace> I did a parachute jump last year :-)
[10:43] <TheMue> once done a tandem jump out of 3000m, nice
[10:43] <TheMue> cool
[10:43] <voidspace> TheMue: you've done a tandem jump?
[10:43] <voidspace> that's what I did
[10:43] <voidspace> great fun
[10:44] <TheMue> yeah, during free fall I’ve almost forgot to breathe. and then the silence, when the parachute opened and you’ve haning there in about 1000m
[10:45] <voidspace> yep, exhilarating and amazing
[10:45] <TheMue> hanging
[10:46] <TheMue> voidspace: the right words
[10:52] <voidspace> TheMue: LGTM on your PR by the way
[10:52] <TheMue> voidspace: thx
[10:54] <vladk> dimitern
[10:54] <TheMue> vladk: dimiterm is on vacation already
[10:55] <vds> TheMue, pong, just got back to a decent internet connection
[10:55] <TheMue> vladk: you’re here? have been in the hangout but nobody there
[10:55] <vladk> TheMue: yes, I was late
[10:55] <TheMue> vds: hehe, it’s ok, voidspace already reviewd it
[10:56] <TheMue> vladk: i’ve got nothing special to tell, working on ipv6 for lxc and documentation
[10:57] <vladk> I'm, too. I am working on moving cloudinit stuff to networker.
[10:57] <vladk> TheMue: ^
[11:04] <TheMue> vladk: ah, ok. does the networker also modify /etc/network/interfaces?
[11:04] <TheMue> vladk: and this inside containers?
[11:05] <TheMue> vladk: it could be interesting for routing IPv6 sub-subnets in a container (net yet absolutely shure about it, but found an interesting blog entry)
[11:46] <wwitzel3> I've put off restarting for a couple weeks, guess I should probably listen to the nag window, brb
[11:56] <vladk> TheMue: networker requires the presence of /etc/network/interfaces, but it modifies it only for MAAS, and it creates config files for separate interfaces in interfaces.d/ directory. And this should work for all providers except manual
[11:57] <vladk> TheMue: what is the blog about IPv6?
[12:01] <katco> good morning all
[12:02] <mgz> mornin'
[12:02] <voidspace> katco: o/
[12:02] <voidspace> mgz: thanks for leaving dominion with reception by the way - I got it fine
[12:02] <voidspace> mgz: sorry I missed you for the Boston expedition
[12:02] <voidspace> I hope it was fun
[12:02] <voidspace> I had a very quiet Saturday morning
[12:03] <mgz> voidspace: no probs, hope you have a good night on friday
[12:03] <voidspace> mgz: yeah, pretty epic
[12:03] <voidspace> got in at 5am
[12:03] <voidspace> fwereade: ping
[12:03] <fwereade> voidspace, pong
[12:04] <voidspace> fwereade: I'm part way through what's turning into quite an invasive change
[12:04] <voidspace> fwereade: and I think you at least ought to be aware of it - and ideally give a thumbs up to it
[12:04] <voidspace> fwereade: the basic gist is that we need to be copying sessions in order to use mgo socket pooling
[12:05] <voidspace> fwereade: which means we need to *not* be storing collections (which have a reference to the global session) on state.State
[12:05] <voidspace> fwereade: so I've pulled them out, providing methods to get the collection (using a new session) whenever it's needed
[12:05] <fwereade> voidspace, hmm, ok -- is it just a matter of making them funcs that return suitable collections with new sessions? perfect
[12:05] <fwereade> voidspace, +1
[12:05] <voidspace> fwereade: it's *largely* a mechanical change - with a few places that need careful thought
[12:06] <voidspace> fwereade: work so far https://github.com/voidspace/juju/compare/copy-sessions
[12:06] <voidspace> fwereade: yeah, it's *mostly* that
[12:06] <voidspace> fwereade: the compiler won't tell me how many places I have to change - just that there are too many...
[12:06] <fwereade> voidspace, sounds like a nice commit on its own
[12:06] <TheMue> vladk: http://blog.toxa.de/archives/606
[12:07] <voidspace> fwereade: it needs some support work - for example, when we change the password we need to re-open the state because the existing session has the wrong credentials
[12:07] <voidspace> fwereade: the goal is to eliminate i/o timeout errors which we are pretty certain come from using the one global session
[12:07] <voidspace> fwereade: my lunch date just arrived
[12:07] <voidspace> bad timing
[12:07] <voidspace> biab
[12:08] <voidspace> well, about an hour or so - sorry
[12:33] <wallyworld> mgz: katco: standup?
[12:33] <katco> wallyworld: sure, let me grab another cup of coffee. long night -.-
[12:33] <wallyworld> sure :-)
[12:40] <fwereade> bbmuchl
[12:40] <fwereade> in new zealand :/
[12:52] <perrito666> late morning everyone
[12:56] <wwitzel3> hey perrito666
[13:31] <perrito666> natefinch:
[13:31] <wallyworld> katco: forgot to ask - did you get access to canonicaladmin?
[13:33] <natefinch> perrito666: can we move our meeting later?  I have to call my insurance company about why they didn't cover my wife's $500 ultrasound
[13:33] <perrito666> sure we can
[13:39] <katco> wallyworld: i emailed sarah and she just said to use my login from my new-hire email(s)
[13:39] <katco> wallyworld: and i haven't gone back and checked those yet
[13:39] <wallyworld> ok, np. just wanted to make sure you were ok
[13:40] <katco> wallyworld: ty i will let you know if i have any issues
[13:40] <wallyworld> ok
[13:40] <katco> wallyworld: cheers! :)
[13:41] <katco> mgz: lmk if you have any questions regarding that PR
[13:41] <natefinch> wallyworld: do you know why we have the upstart script redirect jujud's output to a file, rather than just having loggo write to a file?
[13:42] <mgz> katco: sure thing
[13:42] <wallyworld> natefinch: my guess is because bu default, loogo writes to stdout and so it's simpler just to have upstart capture that stdout data and redirect from there
[13:42] <wallyworld> but we could look at changing that
[13:43] <wallyworld> i don't imagine it would be too hard, but it would be extra code
[13:43] <wallyworld> cause we'd need to register a different writer with loggo in each process
[13:43] <natefinch> yeah, but it's code and not text in a string that gets written to a configuration file :)
[13:44] <wallyworld> sure, understood. i'm just guessing the reason :-)
[13:44] <natefinch> :)
[13:44] <natefinch> wallyworld: do we expect multiple jujud processes running on the same machine?
[13:44] <wallyworld> yes
[13:44] <wallyworld> machine agent, unit agent
[13:45] <natefinch> ahh
[13:45] <natefinch> still, one log file each wouldn't be a terrible idea
[13:45] <wallyworld> i think they get one log file each now anyway
[13:45] <wallyworld> machine-x, unit-y etc
[13:45] <natefinch> ahh ok, yeah
[13:46] <wallyworld> natefinch: i updated all the deps and other stuff for the licensing based on the new gojson repos. but then i noticed the readmes in those repos still referenced binary132 and i didn't have the will power to do it all again
[13:47] <natefinch> wallyworld: I can fix the readme files... sorry, guess I forgot about those.
[13:47] <wallyworld> natefinch: np. you will need to update dependencies.tsv in both 1.20 and master
[13:48] <wallyworld> thanks for sorting it out though
[13:50] <natefinch> welcome
[13:53] <katco> wwitzel3: btw ran across this and thought you'd be interested: http://jamescooke.info/git-to-squash-or-not-to-squash.html
[13:53] <katco> wwitzel3: it's an interesting question; not sure where i fall yet. i kind of like squash conceptually
[13:58] <wwitzel3> katco: read that one a while back. if there was a way to persist the reflog and share it for each branch / the entire repo .. well that would be perfect :)
[13:59] <wwitzel3> katco: but it is only a local copy (afaik), so for me, doesn't quite solve the problem of keeping tools like git bisect useful when large feature branches introduce subtle bugs.
[14:00] <katco> wwitzel3: i'm not yet familiar enough with git to comment on that. i haven't used bisect at all.
[14:01] <katco> wwitzel3: sounds like you're a few steps ahead of me in your thinking
[14:17] <perrito666> wwitzel3: your dog is so nice
[14:17]  * perrito666 loves dogs
[14:19] <wwitzel3> perrito666: which dog? one of them isn't mine
[14:19] <perrito666> wwitzel3: a dog just paraded behind you while we where having the stand up
[14:19] <perrito666> like a big sheppard
[14:19] <perrito666> but pixelated :p
[14:21] <wwitzel3> perrito666: yeah, that is a german sheppard, her name is Daisy, watching her for a friend.
[14:36] <sinzui> natefinch, or maybe katco , can you help triage bug 1343318 . I relates to logging which has changed and will change soon
[14:36] <_mup_> Bug #1343318: Node syslog full of rsyslog warnings <logging> <juju-core:New> <https://launchpad.net/bugs/1343318>
[14:36] <sinzui> natefinch, katco : Do we intend to fix this for 1.21.0, or later
[14:38] <katco> sinzui: i have never triaged before; and i don't think i can comment on when things will be fixed yet, but i'm looking at the log none-the-less
[14:40] <katco> sinzui: is there a way to tell what version he was running? i recently fixed a bug where rsyslog could not read from a machine-x.log
[14:40] <sinzui> katco, understood.These are my rules, though they don't list that we can choose medium when we think we think we need to discuss it in relation to other issues in afew months: https://docs.google.com/a/canonical.com/drawings/d/1vPqrgXDduzwV_N01ORF6jdnprwykf1ofiIaEAmIwOuA/edit
[14:40] <katco> sinzui: (version of juju)
[14:41] <katco> sinzui: thanks for that :)
[14:41] <sinzui> katco, The user is Canonical IS, so I believe 1.18.1, but they are also migrating some thing to 1.20.1 They will not run devel juju
[14:41] <ericsnow> sinzui: yeah, thanks :)
[14:43] <sinzui> katco, The easy question to ask is if this work it thematically related to what we are doing, are we will to commit to fixing this in the 1.21.x series, if so, I would mark the bug high and assign it to next-stable milestone. If not, I would mark the bug as Medium because I think we will want this bug closed in the next 6 months
[14:44] <katco> sinzui: gotcha. i really have to defer to a lead. i'm just not on-boarded enough to make a call. however, it's possible that this is a symptom of a regression that has already been fixed.
[14:44] <katco> sinzui: https://bugs.launchpad.net/juju-core/+bug/1339715
[14:44] <_mup_> Bug #1339715: Juju 1.21-alpha1 local provider does not create all-machines.log <local-provider> <logging> <rsyslog> <juju-core:Fix Committed by cox-katherine-e> <https://launchpad.net/bugs/1339715>
[14:45] <sinzui> katco, exactly why I asked you :)
[14:45] <katco> sinzui: aha! ;)
[14:49] <katco> sinzui: so just to make sure the loop is closed; do you mind if i defer to a lead?
[14:50] <sinzui> katco, not at all
[14:54] <sinzui> hazmat, do you want to include this bug in your "usability" mandate . bug 1343569 points out that you cannot dump the config of running service to backup or reuse it to deploy another service the same way
[14:54] <_mup_> Bug #1343569: Juju should have an easy way to dump then reuse service config <charms> <config> <improvement> <usability> <juju-core:New> <https://launchpad.net/bugs/1343569>
[15:14] <mramm> anybody around to help SABDFL debug stuff?
[15:15] <mramm> he is having issues with lxc containers
[15:17] <mgz> not sure what I could usefully suggest
[15:19] <mramm> well, we have lots of load on a machine and would like somebody to look at it to see if they can find anything
[15:19] <mramm> and container starts are failing, and we should get logs
[15:20] <mgz> okay
[15:22] <mramm> do you have access to the garage MAAS?
[15:22] <mgz> ugh, probably in theory, but I haven't checked in ages
[15:23] <mgz> will just search emails quickly
[15:25] <mgz> mramm: nope, I'm not in the right group
[15:26] <mgz> I can file an rt to fix that
[15:26] <mgz> but that's not very immediate
[15:29] <mgz> mramm: are there no americans around?
[15:29] <mgz> nate at least has done maasy things quite recently
[15:46] <katco> mgz: sorry to be a pain, but i want to catch you before your EOD. do you think you will be able to review that PR today?
[15:47] <mgz> katco: sure, sorry, just in other things
[15:47] <katco> mgz: oh no worries... as long as it's in before EOD i'm happy
[15:47] <katco> mgz: i just want to land it by my EOD
[15:49] <mgz> the diff on github is now annoying to read...
[15:49] <katco> mgz: =/ could/should i have done it differently?
[15:50] <mgz> nah, just fallout from having had several rounds of review
[15:51] <katco> ah ok... yeah it was difficult to understand the commenting system, this having been my first multi-push review
[15:51] <katco> i understand review board will be better at this
[16:01] <mgz> katco: done
[16:01] <katco> mgz: ty sir
[16:08] <katco> mgz: regarding the break on 80? what is the style in the project? string literal (`foo`) with line breaks? \n embedded in the string?
[16:16] <mgz> katco: yeah, I'd just try to throw in a \n after the first sentence or something, and trim the second one a bit
[16:18] <katco> mgz: (friday humor) i just did "M-u 80
[16:19] <mgz> katco: let me guess, that transforms your editor into a giant robot?
[16:19] <katco> mgz: LOL
[16:19] <katco> M-u is just a way to tell emacs to do something X number of times
[16:20] <katco> so i say M-u 80 and then hit the right button
[16:20] <bodie_> hmmm, go emacs?  how do you like it?
[16:21] <katco> bodie_: how does one like air? water?
[16:21] <katco> bodie_: hehe no i love emacs. i am typing this from emacs (erc)
[16:21] <bodie_> I guess it depends how problematic it is ;)
[16:21] <bodie_> I like the air here much better than the air in LA
[16:22] <katco> haha
[16:22] <bodie_> I enjoy emacs for clojure but I'm not sure it would feel right for Go, but some people do swear by it
[16:22] <katco> bodie_: i poke fun at my love of emacs often. but i use it for everything. i find writing go in it is wonderful
[16:23] <bodie_> again... best OS with a reasonably tolerable text editor :P
[16:23] <katco> bodie_: lol yup
[16:23] <katco> it was funny, at the sprint axw was reviewing some of my code
[16:23] <katco> and he's a vim user
[16:23] <katco> so i hopped into evil-mode
[16:23] <bodie_> nice
[16:23] <katco> and now i can say axw used emacs ;)
[16:23] <bodie_> emaxw
[16:24] <katco> rofl
[16:24] <katco> but yeah, google's go-mode ties into a lot of great tools
[16:25] <bodie_> oo, there's a google-sponsored package? I might have to check that out
[16:25] <katco> yeah it's in elpa and everything
[16:25] <katco> i think it's distributed with go, but the elpa is more up to date
[16:25] <katco> http://dominik.honnef.co/posts/2013/03/writing_go_in_emacs/
[16:25] <katco> older, but will give you some idea
[16:26] <katco> and on top of that, magit is wonderful for git
[16:26] <bodie_> true, magit is quite nifty from what I've used of it
[16:27] <katco> i don't have to remember all the flags etc
[16:27] <katco> and as i'm building muscle memory, it is _so_ fast
[16:27] <bodie_> I've been using a nice vim plugin set that has code completion, goto-definition, hideable fn and symbol table, and hideable dir tree browser
[16:27] <bodie_> it's actually almost too heavy
[16:27] <bodie_> but, really nice
[16:27] <katco> bodie_: yeah i have all that up right now too... ecb
[16:27] <bodie_> :D
[16:28] <katco> it is heavy if i know where i'm at in the code
[16:28] <katco> but since i'm new, that's almost never, and it's great for holding my hand
[16:28] <katco> also, i run tests from emacs and then C-` to jump to errors
[16:28] <katco> i will go on and on if you let me ;)
[16:28] <bodie_> oooo
[16:29] <katco> flymake highlights errors while i'm typing
[16:29] <bodie_> afai'm concerned, this is the productive opposite of an editor war :P
[16:30] <katco> rofl
[16:30] <katco> i can add imports with C-c Ca, prune them with C-c C-r
[16:30] <katco> *C-c C-a
[16:31] <katco> but by FAR the best is the hook-in with oracle
[16:31] <katco> points out callers, callees, etc... all clickable
[16:31] <jcastro> Error details:
[16:31] <jcastro> invalid Joyent provider config: control-dir: expected string, got nothing
[16:31] <jcastro> did something get added to the joyent provider?
[16:32] <bodie_> katco, now you're talking
[16:32] <bodie_> I definitely have to give this a spin
[16:33] <katco> phew... i was at risk of losing my emacs license. too few converts.
[16:33] <bodie_> unfortunately, my piano skills are a little rusty :P
[16:33] <katco> haha
[16:35] <katco> another thing to check out if you're into productivity tools: org-mode
[16:35] <bodie_> I have heard the ranting and raving about org-mode
[16:35] <katco> my life is in org-mode
[16:35] <bodie_> but haven't taken the time to poke around
[16:35] <bodie_> lol
[16:36] <bodie_> I'm trying to write something a bit like a team enabled org-mode-as-a-service on the side right now
[16:36] <bodie_> would be neat to write a lisp client to interface between that and "real" org-mode
[16:36] <katco> http://blog.kate.cox2.name/2014/01/reflecting-on-2013.html check out the "To-Do System..." header
[16:37] <katco> bodie_: yeah i wish there was an interface into org-mode for leankit
[16:37] <katco> there's one for trello
[16:37] <bodie_> no way, too cool
[16:37] <katco> and i've written some very basic hooks into launchpad just to grab some info
[16:37] <katco> so like i can put the point on a bug id, and then i do M-x kt/browse-launchpad-bug
[16:38] <katco> seems trivial but i use it _so_ much
[16:39] <katco> need to get some food bbiab
[16:39] <bodie_> o/
[18:04] <voidspace> signing off for a few hours. Back on in around 4 hours.
[18:04] <voidspace> g'night everyone
[18:04] <katco> tc voidspace
[18:05] <voidspace> I'm not in next week. Don't have too much fun without me...
[18:05] <voidspace> o/
[18:09] <TheMue> o/
[18:10] <TheMue> bodie_: you’re using vim? I’m an old vimthusiast
[18:11] <TheMue> bodie_: for go I’m using the standard of the go team plus an own little and helpful plugin
[18:12] <TheMue> bodie_: also tagbar is nice for navigation inside a file
[18:17] <katco> hmm.. i'm trying to write a unit test to check if kvm-ok is on the path, but i would rather not have the test fail if the dev running the test doesn't have kvm-ok... any ideas?
[18:18] <katco> perhaps creating a dummy kvm-ok on a dummy path?
[18:19] <perrito666> katco: you can set the path to whatever c.Mkdir() returns and adda kvm-ok there
[18:20] <natefinch> yeah, that's what I'd do.
[18:20] <katco> perrito666: perfect, ty guys
[18:20] <katco> i kinda wish there was a better way to mock this
[18:20] <natefinch> I presume the code is the thing checking for kvm-ok, and you want to make sure it does the right thing?
[18:21] <TheMue> hehe, mocking, always a nice topic
[18:21] <katco> yeah, we're adding the ability to check a given path if it can't find it in the user's path
[18:21] <natefinch> right
[18:22] <natefinch> I think the way mentioned is a good way to do it.  It physically sets the environment to either correct or incorrect.   An alternate way would be to mock out os.Stat, but that's a little more implementation dependent
[18:23] <katco> cool ty natefinch
[18:24] <perrito666> also you can set path to your temp dir, fail, add file, success and is a rather flow explanatory test
[18:24] <katco> perrito666: yeah i'm planning on doing just that
[18:25]  * perrito666 remembers one of his testing mentors "tests should tell a story"
[18:25] <katco> perrito666: that's really interesting; i would listen if you wanted to expound
[18:26] <natefinch> I like tests that only test one thing.  So, one to test the good case, one to test the bad case.   But sometimes setup is a big pain, so you end up testing multiple things along the way.
[18:26] <katco> natefinch: i try to find the "middle way" for that reason
[18:27] <katco> natefinch: an architect i respected once said, "if you ever find yourself thinking in absolutes, that should be a red flag"
[18:27] <natefinch> katco: yep... never ever use absolutes.
[18:28] <ericsnow> natefinch: you can create a new suite for that and write a SetUpTest() that is common to those tests
[18:28] <perrito666> katco: well, you ideally should know how many exits your code has and therefore should tell the story of how data -> box->info flows from shorter to longer path
[18:28] <katco> natefinch: that joke is _always_ funny
[18:28] <natefinch> :)
[18:28] <natefinch> yep
[18:28] <natefinch> ericsnow: I kinda hate suite-based tests, actually.  It seems to encourage really elaborate test setups, rather than refactoring your code to be more testable
[18:29] <perrito666> katco: that should be read with a fake old chinese wise man voice
[18:29] <natefinch> "hey look, I've spent two weeks writing code so that I can start up mongo and a juju server with just three lines of code!"
[18:29] <katco> perrito666: ah, so that touches on something i am familiar with: the tests being a good way for devs to examine your api
[18:29] <katco> perrito666: rofl
[18:29] <katco> perrito666: the argentinian accent is just as effective :)
[18:30] <bodie_> TheMue, I agree about tagbar :)
[18:30] <katco> bodie_: heresy! come to emacs!
[18:30]  * natefinch just installed acme so he could take part in the editor wars.....
[18:31] <katco> haha
[18:31] <katco> natefinch: i will be interested in how you find it
[18:31] <katco> natefinch: personally i don't like how it's mouse driven
[18:33] <natefinch> katco: I'm coming from Visual Studio and Sublime text, so I'm pretty mouse-centric anyway.  I have come to love the command line...  but I like the ability to just look at a word and perform an action on it, like go to definition or whatever
[18:33] <natefinch> but I literally just started acme for the first time, so we'll see
[18:34] <perrito666> natefinch: well be around you when you use your mouse sounds a lot like being near a cs player
[18:34] <bodie_> natefinch, lol
[18:34] <katco> natefinch: yeah i understand; the two are not mutually exclusive fyi; i do M-. to go to defs on word, among other keystrokes
[18:34] <katco> perrito666: haha
[18:34] <bodie_> I may be a CLI fighter but I'm not Acme crazy
[18:34] <TheMue> katco: emacs = eight megabytes and continuously swapping
[18:35] <TheMue> katco: oh, no, today it’s 8 GB, for Atom
[18:35] <katco> TheMue: haha
[18:35]  * katco wonders if that's now a compliment these days
[18:35] <katco> ah darn
[18:35] <bodie_> natefinch, I love sublime too, but I discovered that not having to leave the keyboard reduces friction just that little extra bit... meaning I can be just a little bit lazier ;)
[18:35] <bodie_> lol TheMue
[18:36] <katco> TheMue: actually that came up in the sprint... i went to look and see how much memory emacs was consuming expecting 500MB or so... 29 MB
[18:36] <TheMue> I left Sublime, somehow I came back to vim. love the speed and that it’s availble on GUI and in terminal
[18:36] <natefinch> I've heard a lot of good things about vim-go, but I don't know that I can deal with vim's keyboard navigation stuff
[18:36] <katco> TheMue: it's taking up ~230MB right now, but i have considerably more running
[18:37] <katco> natefinch: emacs can help you there! ;)
[18:37] <TheMue> katco: today the old ones are all small, even with all their plugins
[18:37] <bodie_> natefinch, yeah, it's a little bit of a learning curve for sure, especially for the first week or so
[18:37]  * katco taps fingertips together
[18:37] <bodie_> once you're used to it it's very friendly (same with emacs imo) but getting there is weird and annoying
[18:38] <katco> obligatory http://ergoemacs.org/emacs/i/emacs_learning_curves.png
[18:38] <TheMue> in early times smalltalk had no chance because of the resources they need. when today running pharo you love about the needed resources
[18:38]  * TheMue will stay with vim
[18:39] <bodie_> precisely
[18:39] <bodie_> (katco)
[18:39] <perrito666> if you really want to be part of a good editor war, you need to code your own editor, clearly
[18:39] <bodie_> well...
[18:39] <TheMue> perrito666: good idea
[18:39] <katco> perrito666: seriously speaking, i consider the point of emacs to customize it specifically to you until it is an extension of you
[18:39] <bodie_> emacs is basically just a lisp interpreter, right?
[18:40] <TheMue> perrito666: on your own os with your own language
[18:40] <katco> bodie_: i actually have scripts i run from the command line utilizing emacs as a host
[18:40] <bodie_> bodim on bodhi linux running bodiescript?
[18:40] <katco> bodie_: check this out: http://elnode.org/
[18:40] <katco> sometimes i use that for stubbing web apis
[18:41] <bodie_> oh, M-s-nap
[18:41] <katco> lol
[18:41] <bodie_> ... that was a stretch
[18:41] <TheMue> oh, and today everything has to run in the browser. so even the local editor has to be a server and files are edited by https://localhost:12345/home/themue/code/..
[18:42] <katco> bodie_: i enjoyed it
[18:42] <bodie_> TheMue, you must be thinking of LightTable IDE... :P
[18:42] <katco> loll
[18:42] <TheMue> bodie_: noooooooo /o\
[18:42] <bodie_> I really wanted that to be cool :S
[18:46]  * TheMue ’s first real hard editor has been ISPF on TSO (and his cousin SPF/2 on OS/2), very strange, but powerful once you get it 
[18:46] <bodie_> I was fantasizing the other day about how a keyboardless shell / code editor might be possible
[18:46] <katco> i started out on vim, but have since forgotten all of it
[18:47] <bodie_> to me vim is like a very productive text editor whereas emacs is more like a semantic tree editor
[18:47] <bodie_> and go is not very ... tree-y
[18:47] <bodie_> but it is somewhat verbose (relative to more tree-y things like lisps)
[18:48] <perrito666> bodie_: I have never been into a level of productivity where that degree of speed is useful, I usually spend more time thinking that writing
[18:48] <TheMue> bodie_: never thought about it, but yes
[18:49] <katco> i'm not sure i understand that. what is the relation b/t editor and how close to sexps the language is?
[18:51] <TheMue> Atom will be the next emacs, only js instead of lisp. and node.js as backend *shivver*
[18:51] <bodie_> it seems to me that in a sexpy language your syntax is closer to a semantic tree while in a more imperative style language your syntax is more about editing the state machine.... or something
[18:53] <katco> bodie_: ah ok. i am still not able to make the connection on how the editor impacts that, perhaps b/c i haven't used vim in so long
[18:54] <bodie_> well to me it feels like vim is more about manipulating letters / lines / words while emacs is more about manipulating sexps
[18:55] <bodie_> maybe I'm just used to paredit
[18:56] <katco> hm. again, perhaps it's b/c i haven't used vim in so long, but emacs seems to work just fine editing things at the document level (letters, lines, words, etc.)
[18:56] <katco> it does assign meaning to syntax based on what mode you're in, so you can jump around the document based on functions, etc.
[18:56] <katco> but i don't think that precludes operating at a purely document level
[18:58] <bodie_> I'm probably just more comfy with vim's toolbelt :)
[18:58] <katco> i do get the feeling that vim is better for that kind of thing
[18:58] <katco> vim golf
[18:58] <bodie_> heh
[18:58] <katco> but we have evil-mode! ;)
[18:59]  * bodie_ dramatically keels over clutching his head
[18:59] <katco> haha
[19:00] <katco> quick! M-x revive-developer
[19:02] <natefinch> honestly, the worst thing about emacs users is how they always have to write out all their hotkeys (and call them chords to make them sound more exotic)
[19:02] <natefinch> :D
[19:03] <TheMue> *ROFL*
[19:03] <perrito666> natefinch: nah, chords are easy, you can play a piano with only 10 fingers, its not like emacs
[19:03]  * perrito666 hides
[19:03] <katco> hold on i accidently did the wrong chord and it's reformatting my hard drive
[19:03] <katco> dammit emacs!
[19:03] <bodie_> if you just map c, s, and m to C maj, F maj, G 7....
[19:04] <TheMue> katco: as long as you don’t reformat EC2
[19:04] <bodie_> lol perrito666
[19:04] <katco> TheMue: nah, that's bound to C-S...
[19:05] <bodie_> or was it M-C-S?
[19:05] <TheMue> last time I used emacs I got a knot into my fingers and had been in the hospital for three weeks
[19:05] <katco> M-x describe-key to the rescue!
[19:05] <katco> lol
[19:05] <bodie_> actually
[19:05] <bodie_> I find emacs easier on my hands
[19:05] <bodie_> because I *never* have to leave home row
[19:05] <bodie_> position*
[19:07] <natefinch> evidently acme runs its own virtualized operating system. Take that, emacs!
[19:07] <katco> rofl
[19:07] <katco> editor wars are too fun to take seriously
[19:07] <bodie_> clearly, emacs is superior in that respect, since its primary operating system is the brain of the user
[19:08]  * katco refrains from making a comment about the OS needing an upgrade
[19:08] <bodie_> I'm afraid there is no known remedial action for removing such a virus
[19:10] <katco> i knew when i found that tetris had come bundled with emacs that something was amiss
[19:10] <katco> but it was too late for me
[19:18] <natefinch> rogpeppe: you around?
[19:21] <natefinch> good god ubuntu software center is slow
[19:21] <jcastro> apt-get dude!
[19:21] <natefinch> but if I install stuff from a deb, I have no clue what apt thinks it's called
[19:22] <katco> ok this is stupid. what's a cross platform command i can place in an executable script? very few assumptions can be made about what resides on the system
[19:22] <natefinch> need more context
[19:23] <katco> i'm still working on this stupid test. if i create an empty file and make it executable, i get a "fork/exec (file...) exec format error"
[19:23] <katco> if i fill it in with something, it works
[19:24] <natefinch> katco: I think we have a util for that...
[19:24] <katco> natefinch: i honestly can't tell if you're joking
[19:24] <natefinch> katco: not joking :)
[19:25] <katco> haha ok. please elucidate
[19:25] <natefinch> katco: cross platform is actually pretty tricky... we usually use "exit 0" as the script contents
[19:25] <katco> oh jees... why didn't i think of that
[19:26] <katco> i blame 3 hours of sleep and my baby
[19:26] <natefinch> #!/bin/bash --norc
[19:26] <natefinch> exit 0
[19:26] <katco> that won't work on windows will it?
[19:26] <natefinch> not cross platform, obv
[19:26] <natefinch> correct
[19:26] <katco> trying to be mindful of your windows work :)
[19:27] <natefinch> echo works :)
[19:30] <katco> hmmm... it doesn't like that either
[19:31] <natefinch> might not be possible to be cross platform... that's ok, we can always refactor it so we create an OS-specific script
[19:37] <natefinch> jcastro: how do I list installed stuff with apt-get? I installed a deb I downloaded through the ubuntu software center, but now it's not show it as installed
[19:37] <natefinch> jcastro: (and I don't know what the heck apt-get thinks it's called)
[19:37] <jcastro> natefinch, in this case install synaptic, then look in the "local" section
[19:37] <jcastro> and it will show you all the horrible things from around the web you've installed
[19:38] <katco> natefinch: apt-cache search <regex>
[19:38] <natefinch> that's ok, I was able to guess :)  But that'll be useful later
[19:39] <natefinch> hahah... it's not that ubuntu software center couldn't find the software, it was just so slow and didn't show any progress, I thought it couldn't find it, but I went back to the window a few minutes later, and it was there
[19:44] <rick_h__> sinzui: really awesome email :)
[19:44]  * rick_h__ tosses three cheers to sinzui abentley abel and company
[19:54] <sinzui> thank you rick_h__
[20:17] <TheMue> sinzui: +1
[20:29] <natefinch> sinzui: thank you for that.  There had been grumbling that Juju was unstable, but I didn't know where it was coming from.  Nice to hear someone who uses and tests juju thinks it's pretty stable
[20:40] <natefinch> man our logging infrastructure is overly complicated
[21:03] <perrito666> sinzui: +1 that kind of feedback is very refreshing
[21:04] <katco> where is this very awesome email?
[21:05] <ericsnow> katco: canonical-juju
[21:06] <ericsnow> katco: "Some facts about Juju CI and Juju 1.20.x"
[21:07] <katco> oh that's right... i still don't think i'm on that list
[21:07] <katco> i guess alexis didn't get around to that yesterday
[21:07] <ericsnow> katco: I'll forward it to you
[21:08] <katco> ericsnow: oh thank you!
[21:08] <katco> for now it's past my EOD and i desperately need sleep. have a good weekend all
[23:53] <voidspace> wallyworld: ping
[23:54] <voidspace> hmmm... unless it's now saturday in your world
[23:54] <voidspace> I guess technically it is in mine now
[23:54] <voidspace> wallyworld: anyway, I'll email you tomorrow...