| === imbrando1 is now known as imbrandon | ||
| thumper | davecheney: what would your recommendation be around wanting a max that works with ints? | 01:39 |
|---|---|---|
| davecheney | thumper: what is the question ? | 01:42 |
| thumper | davecheney: well, math.max works on float64 | 01:42 |
| thumper | but I'm trying to find the longest int | 01:42 |
| davecheney | you'll find lots of | 01:43 |
| davecheney | func max(a, b int) int { if a > b { return a } return b } 's | 01:43 |
| davecheney | in the codebase | 01:43 |
| davecheney | that is the current standard | 01:43 |
| thumper | I just realized that codereview.appspot was sending email to my gmail account (that I don't actually read) | 01:48 |
| thumper | and I can't configure it to send email to my normal address | 01:48 |
| * thumper chalks up another mark against rietveld | 01:49 | |
| thumper | davecheney: so why did your last comment not go to the merge proposal? | 01:52 |
| davecheney | thumper: i have no idea | 01:52 |
| davecheney | to be honest, when I joined, the attitude was to ignore the MP and use Rietveld | 01:52 |
| davecheney | the comment should arrive on the MP evnetually, it was cc'd on the review | 01:52 |
| davecheney | so you should have got the comments via the route of | 01:53 |
| davecheney | rietveld -> mp -> gophers group -> you | 01:53 |
| thumper | it is faster... | 01:59 |
| thumper | rietveld -> mp -> me (as I proposed the merge) | 01:59 |
| thumper | but it doesn't arrive on the mp | 01:59 |
| thumper | since I wrote all that email shit with abentley, I know how it works | 01:59 |
| thumper | oh I know what it is | 02:00 |
| thumper | the email address that it is coming from is not linked to any known launchpad user | 02:00 |
| thumper | so it drops them on the floor | 02:00 |
| thumper | since my gmail account isn't linked to my LP user, LP ignores all email from it | 02:01 |
| davecheney | bzzt | 02:01 |
| thumper | obviously roger has linked his gmail to LP user | 02:01 |
| thumper | his default email address for the LP user is his canonical one | 02:01 |
| thumper | which is what the outgoing MP email is sent as | 02:02 |
| davecheney | maybe, he was winging for months that he wasn't getting any updates | 02:02 |
| thumper | that is what it is | 02:02 |
| * thumper knows it | 02:02 | |
| thumper | so what I have to do is to add my google mail address to LP | 02:02 |
| thumper | and so does every other user | 02:02 |
| thumper | which sounds crackful | 02:03 |
| thumper | would be better if rietveld would allow me to configure my email address | 02:03 |
| davecheney | hmm, that might be unpossible | 02:04 |
| davecheney | canonical.com is a gapps domain | 02:04 |
| davecheney | but the email portion is disabled | 02:04 |
| davecheney | to send/recieve as your canonical identity you would need a google identity on canonical.com | 02:05 |
| thumper | davecheney: OK, my question around this latest MP is that I have four different LGTM calls, but there is still a little contention around the init command AFAICS | 02:05 |
| davecheney | fuckem | 02:05 |
| davecheney | it's called source control | 02:05 |
| davecheney | you can always propose another change | 02:05 |
| thumper | heh | 02:06 |
| * thumper emails juju-dev with this email revalation | 02:07 | |
| thumper | davecheney: so you reckon submit this alias branch for merging now? | 02:08 |
| davecheney | thumper: +1 | 02:10 |
| thumper | kk | 02:10 |
| davecheney | what is the worse people can do ? | 02:10 |
| davecheney | they are miles away | 02:10 |
| thumper | well... from past experience, the worst they can do is revert the merge, and yell publicly on the mailing list at how shit you are | 02:12 |
| * thumper says mostly in jest | 02:12 | |
| davecheney | you don't need to commit code for that | 02:12 |
| davecheney | :P | 02:12 |
| thumper | fucking conflicts... | 02:13 |
| * thumper fixes | 02:13 | |
| * thumper goes to find his child | 02:17 | |
| === wedgwood_away is now known as wedgwood | ||
| * thumper is confused | 03:32 | |
| thumper | davecheney: ping | 03:35 |
| davecheney | ack | 03:45 |
| davecheney | thumper: ack | 03:45 |
| thumper | davecheney: nm, found that go build doesn't report all the errors | 03:45 |
| thumper | which is why I was confused | 03:46 |
| thumper | go test found them | 03:46 |
| davecheney | ok | 03:46 |
| davecheney | offline for 5-10 mins | 03:46 |
| davecheney | rebooting + MOAR RAM! | 03:46 |
| davecheney | mmm, 8gb | 04:09 |
| davecheney | i had forgotten that I had donated some to my other machine a while back | 04:09 |
| davecheney | and only remembereed that when the said donated ram failed | 04:09 |
| === wedgwood is now known as wedgwood_away | ||
| TheMue | Morning | 08:05 |
| === TheRealMue is now known as TheMue | ||
| fwereade | TheMue, morning | 08:21 |
| fwereade | TheMue, can you think of any reason we have the --upload-tools flag on bootstrap/upgrade, instead of just an upload-tools command that puts stuff into the appropriate "public-bucket" (wtf? why not "tools-bucket"?) for the environment? | 09:51 |
| TheMue | fwereade: First, yeah, tools-bucket is more clear than public bucket. +1 on that. ;) | 09:52 |
| fwereade | TheMue, do you recall anything else that it's used for? | 09:53 |
| TheMue | fwereade: I think the basic idea has been to upload the tools "on the fly", but I don't know if it's really better than having an explicit command for it. | 09:53 |
| TheMue | fwereade: Can't remember the discussion which led to this decision. | 09:54 |
| fwereade | TheMue, I think it's way back before I even started on go | 09:54 |
| TheMue | fwereade: Yip, it's in there for a long time. Is our IRC archive searchable? | 09:55 |
| fwereade | TheMue, I think it's just cargo-culting from python tbh :( | 09:55 |
| fwereade | TheMue, (the public/private buckets, anyway) | 09:55 |
| TheMue | fwereade: Think so too. In the beginning we've ported much 1:1. | 09:56 |
| fwereade | TheMue, the tools stuff was done round about lisbon 1 but I wasn't closely involved... guess I should talk to niemeyer this pm, see if he has context I lack | 09:56 |
| TheMue | fwereade: I'm sure he can answer your question. | 09:57 |
| TheMue | fwereade: http://irclogs.ubuntu.com/2012/05/01/%23juju-dev.txt | 09:58 |
| frankban | hi fwereade: is there a bug for the default-series problem? | 10:11 |
| fwereade | frankban, not yet, I'm looking into it more closely just now | 10:12 |
| frankban | fwereade: ack thanks | 10:12 |
| fwereade | frankban, quick check: were you using --upload-tools? because that seems to work in quite a surprising way | 10:19 |
| frankban | fwereade: yes | 10:19 |
| fwereade | frankban, right, yeah, ISTM that upload-tools is crack, because it just forces everything to run with the tools that have been uploaded regardless | 10:19 |
| frankban | fwereade: so it takes the series I am running in the local machine? | 10:20 |
| fwereade | frankban, yeah, and it looks like it's totally infectious | 10:20 |
| frankban | fwereade: so, in theory, if I compile and run juju in a precise lxc it should work... | 10:21 |
| fwereade | frankban, I have a nasty suspicion that even without upload-tools it will force the series/arch of the bootstrap node onto everything it provisions, but I'm still verifying that | 10:21 |
| fwereade | frankban, hmm, yes, worth a try | 10:23 |
| frankban | fwereade: I will | 10:23 |
| fwereade | frankban, you will still be stuck with whatever you uploaded for absolutely everything you deploy, but at least you should be able to progress | 10:27 |
| mariusko | Hi, where should charm settings be saved? | 11:05 |
| fwereade | mariusko, I'd expect charm settings to be declared in the charm's config and set individually for each service running the charm | 11:06 |
| fwereade | mariusko, what sort of settings are you thinking of? | 11:06 |
| mariusko | fwereade: these are more locally cached ones | 11:19 |
| mariusko | actually, they are from the relation to mongodb, but they needs to be reused in config-changed hook | 11:20 |
| mariusko | I could not find an easy way to find it there without knowing the unit number | 11:21 |
| mariusko | When there is just one relation possible to mongodb, I would expect to be ablo te get those relation config options easily | 11:22 |
| fwereade | mariusko, there's a relation-list tool that will tell you what units are on the other side of the relation | 11:22 |
| mariusko | I.e. in this case I would expect to write the example "user=`relation-get -r db:42 user mysql/0`" as "user=`relation-get -r db user mysql`" if there is a one-to-many relationship from mysql | 11:25 |
| fwereade | mariusko, there's `relation-ids <name>` to tell you what relations exist; `relation-list <id>` to tell you what units are in each relation; and then you can `relation-get <id> <unit>` | 11:26 |
| fwereade | mariusko, except I've done the syntax completely wrong, sorry | 11:26 |
| mariusko | fwereade: ok, let me see if it can solve the problem. Is there a way to debug these commands interactively? | 11:27 |
| fwereade | mariusko, what version of juju are you using? | 11:27 |
| mariusko | They did not work in "juju debug-hooks" | 11:27 |
| fwereade | mariusko, ok, you're using python... and that would have been what I suggested next | 11:27 |
| mariusko | 0.6.0.1+bzr616-0juju2 from the ppa | 11:27 |
| fwereade | mariusko, do you have a transcript of what didn't work by any chance? | 11:28 |
| mariusko | fwereade: "juju debug-hooks testapp4/0", then "relation-ids" gives "No JUJU_AGENT_SOCKET/-s option found" | 11:31 |
| fwereade | mariusko, does any hook tools work at all? | 11:32 |
| fwereade | mariusko, eg juju-log? | 11:32 |
| mariusko | nope, just when run automatically | 11:32 |
| fwereade | mariusko, huh, that rather sounds like debug-hooks is just plain broken | 11:36 |
| * fwereade tries to think who might be up to date with the python and awake at this hour | 11:36 | |
| fwereade | mariusko, you might be able to iterate *reasonably* quickly if you keep upgrading your config-changed hook from a local repo | 11:39 |
| mariusko | fwereade: pushed the current code: https://code.launchpad.net/~mariusko/charms/precise/node-app/lp1123939_procfile_support | 11:42 |
| mariusko | Caching now happens in "/etc/juju_nodejs_app_${app_name}_mongodb.env" | 11:43 |
| fwereade | mariusko, I'm not quite sure how well that will work when there are multiple mongodbs | 11:51 |
| fwereade | mariusko, it seems like every unit of node_app will just store the most-recently-changed mongodb server? | 11:51 |
| mariusko | I think there only could be one associated with one node app | 11:51 |
| fwereade | mariusko, I'd better go take a look at the mongodb charm ;) | 11:53 |
| mariusko | Hmm japp, "app_name" is set by the user, so it could be other charm instances with the same app_name... | 11:53 |
| mariusko | Maybe service name should have been included | 11:53 |
| mariusko | That would also break some of the existing stuff in the charm too | 11:55 |
| mariusko | Maybe "$JUJU_SERVICE" should have been used instead | 12:00 |
| fwereade | mariusko, that should definitely be unique, yeah | 12:00 |
| fwereade | mariusko, and it does rather look as though it is just storing the most-recently-changed info | 12:02 |
| fwereade | mariusko, which I think might be a problem is the most-recently-changed on ever goes offline | 12:03 |
| mariusko | there are a lot of issues in the charm japp | 12:03 |
| * TheMue is at lunch | 12:04 | |
| mariusko | it looks more like in a demo state now | 12:04 |
| mariusko | Anyway, there should just run one instance on each machine anyway | 12:05 |
| fwereade | mariusko, yeah, I'm not too bothered by the machine-sharing issue right now | 12:05 |
| fwereade | mariusko, I think it would be noticeably better if it maintained an up-to-date seed list (I'm pretty sure the node.js drivers can work with replicasets, right?) | 12:06 |
| mariusko | but if the mongodb dies, I hope that juju fires up a new one and then run the relation hook again to set the new info? | 12:06 |
| fwereade | mariusko, if you've got 3 in a replicaset and the last one to change goes down, I fear that the node apps will only try to connect to that one and fail ignominiously | 12:07 |
| mariusko | Seems it reads it: "replset=`relation-get replset`" | 12:07 |
| fwereade | mariusko, that's just a string | 12:07 |
| fwereade | mariusko, taken straing from the config | 12:07 |
| fwereade | mariusko, AFAICT, anyway | 12:08 |
| fwereade | s/straing/straight/ | 12:08 |
| mariusko | haven't started playing with mongo yet, so I don't know much about it | 12:08 |
| mariusko | It is now set to ""myset" | 12:09 |
| fwereade | mariusko, I'm having some trouble spelunking through the mongodb charm -- it is certainly doing sane things in the replset relation hooks | 12:09 |
| mariusko | I thought the relationship was many nodeapp->one mongodb->many mongodb nodes | 12:09 |
| fwereade | mariusko, building up host:post,host:port lists... but I haven't figured out if/how they pass them on to database clients | 12:10 |
| mariusko | I have a replica-set relation from mongodb | 12:10 |
| fwereade | mariusko, that relation looks like it's being sensible -- ie it's causing the individual mongos to keep track of their replica sets, which is good | 12:11 |
| fwereade | mariusko, so if you successfully connect to any one, your driver should be able to figure out the current rs state and go from there | 12:12 |
| fwereade | mariusko, but if a node app only has one mongo address stored, and that address stops working for any reason, I don't think it'll be able to connect | 12:13 |
| mariusko | fwereade: firing up one more mongo unit now to see what happens | 12:19 |
| mariusko | But it was like that before my hacking too :) | 12:19 |
| mariusko | Japp, the mongodb IP changed to the last added mongodb node | 12:20 |
| fwereade | mariusko, sure, sorry, I think I've derailed you quite badly :( | 12:22 |
| mariusko | fwereade: japp, it seems like the client should list all nodes when connecting: "MongoClient.connect("mongodb://localhost:30000,localhost:30001/integration_test_?w=0&readPreference=secondary", function(err, db) {" | 12:23 |
| mariusko | At least more than one | 12:23 |
| fwereade | mariusko, re uniqueness, incidentally, it's more-or-less ok to store that sort of cached information inside the charm dir | 12:24 |
| fwereade | mariusko, the important bit is that if it's stored in the charm dir, it's for the consumption of the *charm* (which can then use it to write config files in /etc or wherever, in response to hooks) | 12:24 |
| mariusko | If all should be listed, it is maybe easier to try to do it properly and fetch all of them | 12:24 |
| fwereade | mariusko, if it's for the consumption of the service in any way -- eg an actual config.js, definitely don't store it in the charm dir | 12:25 |
| fwereade | mariusko, +1 to that, I think | 12:26 |
| fwereade | mariusko, no sure how to handle connections to multiple mongodb *services* though... that might be a case where the "limit" setting on the charm would be helpful | 12:27 |
| fwereade | mariusko, if only limit restrictions were actually implemented :/ | 12:27 |
| mariusko | Hehe, juju looks a bit in alpha state at this time | 12:28 |
| mariusko | But seems to work in simple cases for test/development purposes | 12:28 |
| mariusko | Hope it will change for Raring | 12:28 |
| fwereade | mariusko, hopefully we'll have something solid for you... but I'm not sure limit will make the cut | 12:29 |
| fwereade | mariusko, on the plus side, I think that it's reasonably clear that the tools to get node_app doing the right thing are in place | 12:29 |
| fwereade | mariusko, it takes a little while to get used to charm-writing though | 12:30 |
| mariusko | fwereade: tried to describe the problem here: https://bugs.launchpad.net/charms/+source/node-app/+bug/1131188 | 12:30 |
| _mup_ | Bug #1131188: Does not support multiple mongodb units <node-app (Juju Charms Collection):New> < https://launchpad.net/bugs/1131188 > | 12:30 |
| fwereade | mariusko, thank yu, that's extremely helpful | 12:30 |
| mariusko | Japp, Heroku etc. seems to have a more complete service just now, but AFAIK it does not allow hacking on it like Juju :) | 12:31 |
| fwereade | mariusko, I don't want to bash those at all, they do what they do just as they should, but we're not trying to do quite the same things :) | 12:32 |
| mariusko | Sure, those services also have their own proprietary tools so it is harder to change cloud providers. Sent a merge requst | 12:37 |
| * dimitern lunch | 12:39 | |
| bac | hi jam, thanks for the review. | 12:43 |
| bac | i don't understand your comment in the README about --upload-tools | 12:43 |
| bac | even if you use --upload-tools, i think it will complain if it sees a juju-origin | 12:44 |
| jam | bac: for juju-core you can do 'juju bootstrap --upload-tools' which is how you get the 'current' version of tools available for things to use. | 12:44 |
| jam | With Python juju | 12:44 |
| bac | so for people coming from pyjuju with a pre-existing environments.yaml they will see that complaint | 12:44 |
| jam | you had to specify a source | 12:44 |
| jam | like ppa | 12:44 |
| jam | bac: sure, my point is, if someone was *using* a custom source for juju (like juju-origin: ppa) they most likely want "juju bootstrap --upload-tools". | 12:45 |
| bac | jam: gotcha | 12:45 |
| jam | I was mentioning it as "do we want to include a side reference so people can figure out where to get similar functionality" | 12:45 |
| jam | though I imagine people tend to have that line because it was the magic voodoo that made things work | 12:45 |
| jam | (because precise has an old version of juju that is incompatible with lots of python-juju clients) | 12:46 |
| bac | jam: with the two positive reviews am i free to make the changes requested and then submit or do i need to re-propose? | 12:46 |
| bac | for this one i will definitely re-propose. just asking about the expectation for this project. | 12:47 |
| jam | If you have 2 LGTM, then submit (though you should respond to make it clear that you've done the requested actions, etc.) | 12:47 |
| fwereade | bac, generally we take the string "LGTM" to be the indicator of sufficient positivity, so I'm not quite sure dfc's counts | 12:58 |
| fwereade | bac, I think his "weird API" comment has some legs... not because the API is weird, IMO it's a perfectly sensible one, but I'm not sure how nicely it will play with rog's RPC magic | 12:59 |
| fwereade | bac, jam: I'm also a little bit reluctant to recommend --upload-tools too loudly, but I have not yet figured out whether it breaks juju *enough* worse than it already is re series/arch selection | 13:01 |
| fwereade | bac, jam: and I am afraid I've just been called to lunch | 13:02 |
| fwereade | niemeyer, heyhey | 13:41 |
| niemeyer | fwereade: Heya | 13:42 |
| fwereade | niemeyer, I liked your ubuntu finder sketch :) | 13:43 |
| dimitern | niemeyer: hey | 13:43 |
| niemeyer | fwereade: Neat :) | 13:44 |
| niemeyer | dimitern: Heya | 13:44 |
| bac | dimitern: hi, thanks for the review. i removed the 'cobzr branch -b' part b/c i found it did not work. does it work for you? | 13:49 |
| dimitern | bac: yw, actually I never used it like that, I always use bzr checkout -b branchname (that's with cobzr) | 13:49 |
| dimitern | that's maybe worth mentioning (if it's not there already) | 13:50 |
| bac | dimitern: i'll try that | 13:50 |
| === wedgwood_away is now known as wedgwood | ||
| TheMue | re | 14:57 |
| TheMue | Argh, my system crashed. *grmpf* | 14:57 |
| dimitern | fwereade: ping | 16:13 |
| fwereade | dimitern, pong | 16:15 |
| dimitern | fwereade: i couldn't find anywhere Service.SetCharm is used, except for a few tests | 16:15 |
| fwereade | dimitern, it will be used by upgrade-charm | 16:15 |
| dimitern | fwereade: but a lot of the things it has to do are uniter operations | 16:16 |
| fwereade | dimitern, its current total lack of safety is the primary reason for the lack of upgrade-charm | 16:16 |
| fwereade | dimitern, sorry, restate? | 16:16 |
| dimitern | fwereade: e.g. downloading a charm to see what it implements, its config, etc. | 16:16 |
| fwereade | dimitern, the uniter should already handle those changes once they've happened | 16:16 |
| fwereade | dimitern, the upgrade-charm story is all about making sure those changes are sane | 16:17 |
| fwereade | dimitern, so that the uniter will itself respond sanely ;) | 16:17 |
| dimitern | fwereade: so all the things you described about changes to Service.SetCharm (well, most of them) will in fact happen in the uniter, before calling it | 16:17 |
| fwereade | dimitern, I don;t think so -- can I talk properly in a mo? | 16:18 |
| dimitern | fwereade: what, hangout? | 16:18 |
| mgz | dimitern: if you're not hanging out yet, can you hop on mumble quickly and tell me if my settings on this box are working okay? | 16:23 |
| dimitern | mgz: sure | 16:23 |
| fwereade | dimitern, ping | 17:05 |
| fwereade | dimitern, sorry | 17:05 |
| dimitern | fwereade: pong | 17:05 |
| fwereade | dimitern, quick hangout? | 17:05 |
| dimitern | fwereade: ok, i'll send you a link | 17:05 |
| fwereade | dimitern, with you in 2 mins | 17:05 |
| jtv | Is anyone else having trouble running "make check" in pyjuju? | 18:31 |
| jtv | And "make review" etc? | 18:31 |
| dimitern | fwereade: it seems there's no clean way to stop a watcher without a panic :( | 18:34 |
| dimitern | fwereade: am I to expect that? and check for a panic in the tests? | 18:35 |
| fwereade | dimitern, hmm, sorry good point: that's a line saying watcher.MustErr(relationsw) or something? | 18:37 |
| fwereade | dimitern, change that bit | 18:38 |
| dimitern | fwereade: yeah, that one | 18:38 |
| === deryck is now known as deryck[lunch] | ||
| fwereade | dimitern, that's checking that no sneaky git stops the watcher underneath us; now that we're deliberately stopping it you should be fine with an err or nil | 18:38 |
| fwereade | dimitern, maybe only start the new watcher once the old one has stopped? that might actually be neatest | 18:39 |
| dimitern | fwereade: :) | 18:39 |
| fwereade | dimitern, to be clearer: if there's an err, return it; if it's nil, start a new one | 18:39 |
| dimitern | fwereade: hmm | 18:39 |
| fwereade | dimitern, that could probably use a comment though, it's a bit subtle, and don't forget to fix up the defer stop (or defer a new one) | 18:40 |
| dimitern | fwereade: yeah, ok | 18:40 |
| dimitern | fwereade: i was thinking exactly of the defer | 18:40 |
| dimitern | fwereade: so it'll call MustErr instead | 18:41 |
| fwereade | dimitern, hmm, no, I don;t think you want MustErr at all for relationsw | 18:41 |
| fwereade | dimitern, I think you probably want a defer that stops the current value of relationsw, rather than snapshotting it | 18:41 |
| dimitern | fwereade: ISTM the only place MustErr is called on relationsw is in the <-Changes() case | 18:42 |
| fwereade | defer func() {relationsw.Stop()}() rather than defer relationsw.Stop() | 18:42 |
| dimitern | fwereade: ah! got you - yeah, it'll be different | 18:42 |
| dimitern | fwereade: so filter.go: 223 that if should be gone | 18:43 |
| dimitern | oops 213 | 18:43 |
| dimitern | no | 18:44 |
| dimitern | sorry, finally 221 :) | 18:44 |
| dimitern | on the relationsw | 18:44 |
| fwereade | dimitern, yeah, around 222: if err == nil { relationsw = service.WatchRelations() } else { return err } | 18:46 |
| fwereade | dimitern, something like that | 18:47 |
| dimitern | fwereade: won't that screw up the defer above? | 18:47 |
| dimitern | fwereade: ah, no - because we'll be out already! | 18:48 |
| fwereade | dimitern, depends if relationsw is naked or only evaluated inside the deferred func | 18:48 |
| fwereade | dimitern, if it's `defer relationsw.Stop()` then it's *that* specific relationsw that will be stopped; if it's inside a func it'll take the value of relationsw at the time it's finally executed | 18:48 |
| dimitern | fwereade: no, I mean I though I saw a inf loop there, but then I realized <-Changes() and the restarting won't happen again while in the defer | 18:50 |
| fwereade | dimitern, yeah, exactly, once we're in the defer we can't go back :) | 18:50 |
| dimitern | fwereade: neat :) | 18:51 |
| dimitern | fwereade: and I can get the err from relationsw.Err(), right? | 18:51 |
| dimitern | fwereade: right, so to test the watcher was restarted, I should stick a change just before the upgrade is fired | 18:55 |
| dimitern | fwereade: or you don't think this needs testing? | 18:55 |
| dimitern | fwereade: sorry it seems you dropped off | 18:59 |
| jtv | Could anyone give me a review for these Makefile changes? https://code.launchpad.net/~jtv/juju/makefile-fixups/+merge/149907 | 19:09 |
| === deryck[lunch] is now known as deryck | ||
| bac | . | 21:01 |
| bac | fwereade: when you have a moment could you do a second pass on my branch? if you think it is ok do i need to wait for dfc to re-review too? | 21:01 |
| bac | fwereade: https://codereview.appspot.com/7401043/ | 21:02 |
| fwereade | bac, sure, just a mo | 21:04 |
| fwereade | bac, LGTM, couple of trivial typos | 21:07 |
| fwereade | bac, I think you're fine re dfc, you did address his point | 21:07 |
| bac | fwereade: thanks | 21:12 |
| _thumper_ | mramm: ok, at home now, hangout? | 21:26 |
| _thumper_ | mramm: needs to be personal one though | 21:26 |
| _thumper_ | as the laptop is upgrading :) | 21:26 |
| mramm | ok | 21:26 |
| mramm | shoot me an invite? | 21:26 |
| _thumper_ | I'll try... | 21:27 |
| BradCrittenden | fwereade: i have made the final changes. i cannot submit the branch b/c i'm not in ~gophers. can you merge it for me? | 21:28 |
| _thumper_ | mramm: the ipad app won't let me add you :( | 21:28 |
| _thumper_ | don't know why | 21:28 |
| mramm | ok | 21:28 |
| mramm | let me try inviting you | 21:28 |
| _thumper_ | ok | 21:28 |
| * _thumper_ tries to recall which image is the personal one | 21:29 | |
| mramm | invite sent | 21:29 |
| _thumper_ | which did you use? | 21:29 |
| _thumper_ | I don't see it | 21:29 |
| mramm | though perhaps to your canonical acount | 21:29 |
| _thumper_ | perhaps invite the other me :) | 21:29 |
| mramm | looking for your personal... | 21:30 |
| === BradCrittenden is now known as bac | ||
| gary_poster | Hey mramm, could you please add ~juju-gui to ~gophers so we can propose? | 21:30 |
| gary_poster | mramm alternatvely I can give you individual people, as you wish | 21:31 |
| mramm | _thumper_: trying again, seems that I lost google hangout | 21:39 |
| _thumper_ | ack | 21:39 |
| _thumper_ | mramm: you disappeared again | 21:40 |
| mramm | hmm | 21:40 |
| mramm | google hangout is not my friend today | 21:40 |
| mramm | trying again with another browser | 21:43 |
| mramm | yea, nothing working, trying a reboot | 21:45 |
| mramm | be back in 2 min | 21:45 |
| === _thumper_ is now known as thumper | ||
| thumper | I home mramm isn | 21:51 |
| thumper | isn't having shell issues too | 21:51 |
| thumper | s/home/hope | 21:51 |
| thumper | I have a horrible feeling that this day is going to be a write-off | 21:52 |
| thumper | I hope not... | 21:52 |
| hatch | arrrrgggggggg | 22:01 |
| * hatch smashes things in hope that it solves his problem | 22:02 | |
| thumper | hi mramm | 22:02 |
| thumper | mramm: long two minutes :) | 22:02 |
| mramm | yea | 22:02 |
| mramm | computer hung on reboot | 22:02 |
| mramm | :( | 22:02 |
| thumper | :( | 22:03 |
| thumper | but you got a shell ok? | 22:03 |
| mramm | eventually | 22:05 |
| mramm | not sure why but it just took forever to get there | 22:06 |
| mramm | but then all is good | 22:06 |
| thumper | mramm: are you going to try a hangout again? | 22:07 |
| mramm | thumper: I'm in a hangout with dave at the moment | 22:12 |
| thumper | mramm: ok | 22:15 |
| mramm | thumper: you still around? | 23:17 |
| davecheney | thumper: when you get done with mramm, can we have a chat ? | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!