| axw | thumper: re "This kind of goes against a lot of our coding standards." -- it wasn't intentional :) | 03:08 |
|---|---|---|
| axw | I have fixed it. | 03:08 |
| thumper | cool | 03:12 |
| thumper | I sort of noticed that in the next file when I saw william's comment | 03:12 |
| thumper | and realised what you had done | 03:12 |
| thumper | wallyworld_: cc'ed you on the email with robie about kvm | 04:24 |
| thumper | as there is some simplestream stuff there | 04:24 |
| wallyworld_ | ok | 04:24 |
| thumper | for how the infrastructure syncs the images for kvm | 04:24 |
| thumper | ok, I'm off for the monday afternoon ice-skating / shopping time | 04:25 |
| thumper | back later to chat to william | 04:25 |
| === thumper is now known as thumper-afk | ||
| axw | wallyworld_, jam: https://codereview.appspot.com/13532047 | 05:37 |
| axw | can't lbox propose at the moment without this | 05:37 |
| jam | axw: doesn't that mean there is a Logf function that is being used incorrectly? | 05:39 |
| axw | jam: no, there's two types of Logf | 05:39 |
| axw | the vet catches one, and errors on the other which is being used correctly | 05:39 |
| axw | loggo.Logf takes a first parameter of the log level | 05:40 |
| axw | then the log format | 05:40 |
| axw | gocheck's C.Logf takes the log format as the first arg | 05:40 |
| axw | AFAICT there's no way of telling go vet how to distinguish between the two Logfs | 05:40 |
| jam | ax | 05:45 |
| jam | axw: how did the original get proposed at all then? | 05:45 |
| jam | I'm fine with the change, but I'm curious what happened | 05:46 |
| axw | jam: yeah I'm not too sure. I will investigate; only thing I can think is that it was proposed, then .lbox.check modified, and a bzr push done | 05:47 |
| axw | or there was a merge, but I don't think so | 05:48 |
| * axw gets tea and investigates | 05:48 | |
| axw | jam: it was the latter; there were two independent MPs that got merged | 05:53 |
| wallyworld_ | axw: sorry, was doing school pickup, do you still need me to look? | 05:53 |
| axw | wallyworld_: s'ok, jam's looking | 05:53 |
| wallyworld_ | ok | 05:53 |
| jam | axw: LGTM | 06:07 |
| axw | thanks jam | 06:07 |
| === tasdomas_afk is now known as tasdomas | ||
| jam | axw: poke | 07:49 |
| jam | axw: I'm looking at your localstorage and ssh storage stuff, and really *I* think that the temp directory should be in or at least next-to the storage location. Because there is 0 guarantee that /tmp is going to be on the same filesystem. (often /tmp is a tmpfs, etc) | 07:49 |
| jam | So I'm happy with "ssh storage uses it until the local provider takes it over", but I think the tmp dir should be under storage | 07:50 |
| jam | I'm fine with 'tmp' vs '.tmp' I don't think it really matters. | 07:50 |
| rogpeppe | mornin' all | 07:52 |
| jam | good morning rogpeppe | 07:52 |
| rogpeppe | jam: hiya | 07:52 |
| TheMue | heyho all | 07:57 |
| axw | jam: sorry, was taking a break before. reading now | 08:00 |
| axw | jam: it will be in /tmp only if you don't tell it where to go | 08:01 |
| axw | and for the only usage, I will be telling it where to go | 08:02 |
| jam | axw: but why make that the default rather than next to the storage, since then you are much more sure it will be on the same fs | 08:02 |
| axw | jam: for sshstorage, the default is next to it. I could make it the same for filestorage too | 08:03 |
| axw | I didn't do that because it'll pollute the local filesystem for sync/generate-tools metadata | 08:03 |
| axw | probably not a big deal | 08:03 |
| axw | for sshstorage, the default is the remote storagedir with ".tmp" appended | 08:03 |
| jam | axw: I think it makes sense to have them match, and I think putting it inside is nice if it is something we will be managing. | 08:04 |
| axw | jam: I'll take a look at how feasible it'll be. environs/localstorage may need to change to do something similar. I'm hesitant to change that, because that'll require upgrade checks | 08:05 |
| jam | axw: why? | 08:05 |
| jam | if it is the temporary dir, we don't see content in it until it is finalized and then moved into place | 08:06 |
| jam | right? | 08:06 |
| axw | right | 08:06 |
| axw | so the way I did it before was | 08:06 |
| axw | sshstorage wrote to ${storage}/content, with a staging in ${storage}/tmp | 08:07 |
| axw | localstorage expects everything to be directly under ${storage} | 08:07 |
| axw | so I changed sshstorage back to doing that | 08:07 |
| axw | with a tmp dir as a peer of ${storage} | 08:07 |
| axw | if I were to not do that, I'd either need to change localstorage to have content/tmp subdirs, or check the feasibility of pointing localstorage at ${storage}/content | 08:08 |
| jam | axw: so from what you've said, localstorage needs to take over what sshstorage uploaded, right? | 08:11 |
| axw | jam: correct | 08:11 |
| jam | and even if you pointed it at .../content it wouldn't use .../tmp for its temp dir | 08:11 |
| axw | yes | 08:12 |
| axw | localstorage doesn't do any of this tempdir stuff at the moment | 08:12 |
| axw | it probably should, if we're being paranoid | 08:12 |
| axw | sorry jam, maybe I confused things. there are three storage implementations things to consider | 08:16 |
| axw | sshstorage, filestorage, localstorage | 08:16 |
| axw | filestorage was only updated on william's request, and doesn't interact with sshstorage at all | 08:17 |
| axw | localstorage is the one that takes over. localstorage does not currently have the write-to-tmp-then-mv behaviour | 08:17 |
| axw | and since localstorage is existing, and used by the local provider, I was hesitant to change its layout | 08:18 |
| jam | axw: so right now localstorage just writes directly to the final location, and interrupted transfers will see partial data? | 08:22 |
| axw | jam: yup | 08:23 |
| jam | axw: I think we want to fix that regardless the rest. | 08:23 |
| jam | even if it is $TMP or whatever | 08:24 |
| axw | fair enough | 08:24 |
| axw | jam: I was thinking of modifying localstorage to become something more generic, exposing another storage via HTTP. I might as well bite the bullet and do that now. | 08:25 |
| === thumper-afk is now known as thumper | ||
| thumper | fwereade: ping | 08:47 |
| fwereade | thumper, pong | 08:47 |
| thumper | hangout? | 08:47 |
| fwereade | thumper, sure, a quick one, just a mo | 08:48 |
| * thumper waits | 08:48 | |
| * fwereade has found his headphones and is starting one | 08:49 | |
| fwereade | thumper, https://plus.google.com/hangouts/_/b68108f32c53bcd9634bd39560203820f2029809?hl=en | 08:50 |
| jam | dimitern, fwereade: I will not make it to the standup today, I have to go sign my son up for after school activities | 08:56 |
| jam | wallyworld_: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/environs/storage.go#L62 (line 62) | 09:01 |
| jam | shouldn't that be "if err == nil" then set dataURL = fullURL ? | 09:02 |
| jam | (I think we're missing some tests about the return value of Fetch()) | 09:02 |
| wallyworld_ | seems so :-( | 09:02 |
| jam | wallyworld_: well, you have "datasourceSuite.Fetch()" which is asserting it gets the relative path back | 09:03 |
| jam | but I think that assertion is actually incorrect. | 09:03 |
| wallyworld_ | could be, i'll look into it | 09:03 |
| jam | wallyworld_: k, I was trying to do some assertions that we are properly connecting to an HTTPS location, etc. | 09:03 |
| jam | but ran into that. | 09:04 |
| wallyworld_ | sorry :-( will fix | 09:04 |
| jam | np | 09:04 |
| dimitern | wallyworld_, rogpeppe , mgz , fwereade, natefinch : standup | 10:46 |
| mgz | ta | 10:46 |
| * TheMue => lunch | 11:25 | |
| === tasdomas is now known as tasdomas_afk | ||
| === tasdomas_afk is now known as tasdomas | ||
| === gary_poster|away is now known as gary_poster | ||
| jam | mgz: poke | 12:24 |
| yolanda | hi, i'm having a problem with juju config vars. Doing a config-get for one of the vars throw: subprocess.CalledProcessError: Command '['config-get', 'admin_pubkey', '--format=json']' returned non-zero exit status 2 | 12:59 |
| yolanda | i tested with juju get nameofservice, and this var has a value | 12:59 |
| yolanda | any idea on what can be failing? | 12:59 |
| mgz | yolanda: did you look at what the stderr output was? | 13:23 |
| yolanda | mgz, i only saw that exit status 2 | 13:23 |
| mgz | right, but you're the one deploying the charm | 13:25 |
| mgz | so, make the charm give you useful output instead of just the exit code | 13:25 |
| rogpeppe | axw: trivial change to environs/sshstorage: https://codereview.appspot.com/13321046 | 13:30 |
| natefinch | is there a way to get gocheck to be less spammy? It prints out like 100 lines per failure, when really all I want is the line of the test that failed | 13:30 |
| mgz | sed | 13:31 |
| mgz | only slightly joking... | 13:31 |
| natefinch | mgz: that was going to be my next move :/ | 13:31 |
| rogpeppe | natefinch: gocheck can't know how much to print, because it doesn't know about tests within tests | 13:33 |
| rogpeppe | natefinch: i agree it's a problem | 13:33 |
| natefinch | rogpeppe: it appears to be printing logging, though... is that our fault for how we're using it? | 13:33 |
| rogpeppe | natefinch: we deliberately print logging, because otherwise there's no easy way to see what's happening underneath when a test fails | 13:34 |
| rogpeppe | natefinch: it's easy enough to get rid of the log lines though | 13:34 |
| natefinch | rogpeppe: most of the time I know why something is failing, or can tell when I get there. I'd much rather have logging be an optional flag than on all the time... it obscures the actual failureas | 13:35 |
| rogpeppe | natefinch: it's an interesting possibliity - you could add a flag that LoggingSuite inspects to determine whether to print log messages, perhaps | 13:36 |
| rogpeppe | natefinch: i'm not sure whether the default should be on or off though - when i get a random unexpected (and perhaps only occasionally reproducible) error in the tests, i actually want to see as much info as possible | 13:37 |
| rogpeppe | natefinch: for example when something fails in the bot | 13:37 |
| === Guest8446 is now known as wedgwood | ||
| rogpeppe | natefinch: actually, on balance, i think an environment variable would probably work better | 13:37 |
| natefinch | rogpeppe: the bot could always run with --verbose since in theory it shouldn't see failures | 13:37 |
| natefinch | rogpeppe: as long as I have a toggle, I don't care where it is :) | 13:38 |
| rogpeppe | natefinch: because then it would be just ignored for any package that doesn't happen to use LoggingSuite | 13:38 |
| natefinch | rogpeppe: fair enough | 13:38 |
| rogpeppe | natefinch: quick review of the above CL? https://codereview.appspot.com/13321046 | 13:39 |
| rogpeppe | natefinch: it just fixes the build for me | 13:39 |
| natefinch | reviewed | 13:40 |
| natefinch | rogpeppe: where is the logging currently turned on? I can at least go poke at it locally to make my life easier right now | 13:40 |
| rogpeppe | natefinch: see testing.LoggingSuite | 13:40 |
| natefinch | rogpeppe: thanks.. that is so much better. What do you think about me submitting a CL for an environment variable that turns off logging? (default would be same behavior as now) | 13:47 |
| rogpeppe | natefinch: seems like an good idea | 13:48 |
| rogpeppe | natefinch: perhaps a way to set the logging level actually | 13:48 |
| rogpeppe | natefinch: in fact, doesn't loggo accept some kind of config syntax | 13:48 |
| rogpeppe | ? | 13:48 |
| natefinch | rogpeppe: yeah, there's a SetLogLevel... we could just have that settable via the env variable. Right now it defaults to DEBUG. | 13:49 |
| rogpeppe | natefinch: i was actually thinking of ConfigureLoggers | 13:50 |
| natefinch | rogpeppe: ahh yeah... setting that seems like a lot of work. I've used similar per-package log levels in other projects... and never have I ever done anything but set the global log level :) | 13:55 |
| rogpeppe | natefinch: well, yeah | 13:55 |
| rogpeppe | natefinch: it will potentially be useful in a real juju environment - to enable low level logging in some problematic packages only | 13:56 |
| rogpeppe | natefinch: because some low level logging can be extremely verbose | 13:56 |
| rogpeppe | natefinch: so a single global log level too big a hammer sometimes | 13:57 |
| rogpeppe | natefinch: but for tests, i think i agree | 13:57 |
| natefinch | We can always add another env variable later if people need a smaller hammer for their tests | 13:57 |
| axw | rogpeppe: thanks for fixing that | 14:01 |
| rogpeppe | axw: i guess not many people don't use bash :-) | 14:02 |
| axw | what'cha running? rc? :) | 14:02 |
| rogpeppe | axw: yeah | 14:02 |
| rogpeppe | axw: it's the shell i've used since... jeeze, maybe 1991? | 14:03 |
| axw | can't say I've ever used anything apart from bash, really | 14:03 |
| axw | zsh briefly | 14:03 |
| rogpeppe | axw: rc has some definite advantages for scripting in particular | 14:03 |
| axw | csh when I had to at my old job | 14:04 |
| axw | *shudder* | 14:04 |
| rogpeppe | axw: the semantics are much much cleaner | 14:04 |
| * axw has a look at some docs | 14:04 | |
| rogpeppe | axw: good intro: http://plan9.bell-labs.com/sys/doc/rc.html | 14:04 |
| axw | ta | 14:05 |
| rogpeppe | axw: in particular see section 28 for a good overview of why it works the way it does | 14:05 |
| rogpeppe | i'd appreciate a review of this if possible: https://codereview.appspot.com/13535045 | 14:07 |
| axw | rogpeppe: what will ConfigStorage be used by? | 14:12 |
| rogpeppe | axw: the command line commands | 14:12 |
| rogpeppe | axw: the environments.yaml stuff is due to change to allow extra information to be associated with an environment | 14:13 |
| rogpeppe | axw: created when an environment is bootstrapped | 14:13 |
| rogpeppe | axw: and also to cache current endpoint info so that we don't need to talk to the provider to try to find out the API address for an environment | 14:14 |
| rogpeppe | axw: here's my idea for the eventual form of the ConfigStorage interface: http://paste.ubuntu.com/6115093/ | 14:15 |
| rogpeppe | axw: it'll probably change as it encounters reality | 14:16 |
| axw | thanks rogpeppe, reading now | 14:17 |
| rogpeppe | axw: thanks | 14:17 |
| yolanda | mgz, i was able to debug error message, it shows: panic: version: cannot read forced version: open FORCE-VERSION: permission denied | 14:25 |
| yolanda | maybe i'm conflicting with some other var? i'm using admin_fullname, maybe is that reserved? | 14:26 |
| yolanda | full log here: http://paste.ubuntu.com/6115131/ | 14:27 |
| === tasdomas is now known as tasdomas_afk | ||
| mgz | yolanda: thanks, that's useful | 14:37 |
| yolanda | mgz, what can be causing that? seems a bit unrelated with a simple config-get | 14:37 |
| yolanda | other vars are working ok, so i'm thinking that the name may be conflicting, but not sure | 14:37 |
| mgz | indeed. seems to be an args parsing thing somehow. | 14:38 |
| mgz | the logic in version/version.go is: | 14:38 |
| mgz | get the dir of args[0] as the location of tools, open the FORCE-VERSION file there | 14:39 |
| mgz | but if other config-get invocations work something funky is going on | 14:40 |
| mgz | but I don't much like that logic regardless | 14:42 |
| yolanda | mgz, should i file a bug? | 14:43 |
| mgz | yolanda: yes, and it probably needs more context on what exactly that charm hook is doing | 14:44 |
| yolanda | just trying to change the name of config vars and redeploy now | 14:44 |
| yolanda | changing admin_xxx for another prefix | 14:44 |
| mgz | it seems more likely that the hook is accidentally changing pwd or something to break stuff | 14:44 |
| yolanda | mgz, the hook just happens after a db joined, and tries to render some content with these vars, it's first config-get called in the hook | 14:46 |
| rogpeppe | lunch | 14:48 |
| yolanda | mgz, indeed, i changed the var for something different like "defaultname" but still the same problem | 14:57 |
| yolanda | i can't imagine what's causing config-get to fail there | 14:58 |
| mgz | yolanda: not sure what to suggest as next debugging step. have you filed that bug yet? | 15:05 |
| yolanda | mgz, no, because i don't know what's the cause | 15:06 |
| mgz | some bugs are just symptoms :) | 15:07 |
| yolanda | mgz, trying to filter a bit, now i'm deploying without external config file | 15:08 |
| yolanda | just using defaults | 15:08 |
| yolanda | same problem, i'll file the bug | 15:14 |
| yolanda | mgz, https://bugs.launchpad.net/juju-core/+bug/1226088 | 15:19 |
| _mup_ | Bug #1226088: config-get fails with "open FORCE-VERSION: permission denied" <juju-core:New> <https://launchpad.net/bugs/1226088> | 15:19 |
| mgz | yolanda: thanks. what's the charm? the hook code seems more relevent than the config. | 15:20 |
| yolanda | mgz, it's gerrit charm, it's not still public | 15:20 |
| yolanda | can i send it to somewhere private? | 15:21 |
| mgz | is it actually pviate, or just not ready? can either push to ~yolanda.robla namespace or I guess just one of the canonical datacenter machines if it's really not to be revealed | 15:22 |
| yolanda | mgz, we are currently pushing to canonical-ci private team | 15:23 |
| yolanda | we are keeping that private at the moment | 15:23 |
| arosales | rogpeppe, fwereade outlooks on cutting a 1.14 release today? | 15:24 |
| arosales | I see rogpeppe has a branch out for https://bugs.launchpad.net/juju-core/+bug/1220027 | 15:24 |
| _mup_ | Bug #1220027: worker/provisioner: cannot restart cleanly due to hard dependency on api server <papercut> <juju-core:In Progress by rogpeppe> <juju-core 1.14:In Progress by rogpeppe> <juju-core trunk:In Progress by rogpeppe> <https://launchpad.net/bugs/1220027> | 15:24 |
| arosales | which is the last bug for the milestone https://launchpad.net/juju-core/+milestone/1.14.0 | 15:24 |
| rogpeppe | arosales: i think that's all merged | 15:24 |
| arosales | rogpeppe, bug is still in progress, could you update the bug status? | 15:25 |
| yolanda | mgz, checking with the team about that | 15:25 |
| rogpeppe | arosales: and *should* be fixed, though i wasn't able to reproduce the original issue, so i'm not absolutely sure | 15:25 |
| arosales | fwereade, robbiew well at this point we need to push 1.14 out | 15:25 |
| arosales | if we need to do a 1.14.1 we can address that there if any bits are missing | 15:25 |
| robbiew | huh...oh... rogpeppe^ | 15:26 |
| robbiew | ;) | 15:26 |
| arosales | robbiew, sorry | 15:26 |
| arosales | auto complete | 15:26 |
| robbiew | np | 15:26 |
| rogpeppe | arosales: i didn't mark the bug as fixed, because although i sincerely believe that it is, i need someone who can verify that | 15:27 |
| mgz | yolanda: see /query | 15:29 |
| arosales | hmm davecheney reported the bug initially | 15:30 |
| arosales | rogpeppe, did you say the branch is in 1.14? | 15:30 |
| rogpeppe | arosales: yes | 15:30 |
| arosales | rogpeppe, so if we cut a 1.14 release today it would have 1220027 fix in it, just untested | 15:32 |
| rogpeppe | arosales: yes. | 15:32 |
| rogpeppe | arosales: so... worth marking as "fix released", i guess? | 15:32 |
| arosales | rogpeppe, I think so if the branch is in 1.14, trunk, and 1.15 | 15:33 |
| rogpeppe | arosales: ok,marked as "fix committed" | 15:33 |
| arosales | rogpeppe, thanks. if we need to return to is we can issue a 1.14. 1 or in subsequent 1.15 releases | 15:51 |
| natefinch | rogpeppe: btw, it looks like some of the tests rely on logging being enabled during testing | 15:54 |
| rogpeppe | natefinch: ah, damn, yes, they do | 15:54 |
| natefinch | rogpeppe: that seems like a weakness in the tests, honestly. | 15:54 |
| rogpeppe | natefinch: they should probably explicitly enable it, or use a different log channel or something | 15:54 |
| natefinch | rogpeppe: yep | 15:55 |
| rogpeppe | anyone up for a review? nothing earth shaking, just part on-going config cleanup.: https://codereview.appspot.com/13421050 | 16:45 |
| mgz | looking | 16:48 |
| arosales | sinzui, it looks like the bugs needed for the 1.14 are in fix committed https://launchpad.net/juju-core/+milestone/1.14.0 | 16:48 |
| arosales | sinzui, thus I would like to start working with you to for the 1.14 and the associated QA. | 16:49 |
| arosales | sinzui, we can sync with davecheney when he comes on-line later in the day. | 16:49 |
| arosales | sinzui, but wanted to give you a heads up that we'll need to cut a release today. | 16:49 |
| mgz | rogpeppe: all makes sense to me | 16:51 |
| rogpeppe | mgz: thanks | 16:51 |
| sinzui | thank you arosales | 16:52 |
| === Makyo1 is now known as Makyo | ||
| * rogpeppe reaches eod | 17:40 | |
| rogpeppe | g'night all | 17:40 |
| natefinch | rogpeppe: g'night | 17:42 |
| === FunnyLookinHat_ is now known as FunnyLookinHat | ||
| === _mup__ is now known as _mup_ | ||
| sinzui | I cannot build juju core 1.14. I can build and run trunk. Make build for 1.14 exists with an error | 20:24 |
| sinzui | # launchpad.net/juju-core/provider/azure | 20:24 |
| sinzui | provider/azure/storage.go:96: multiple-value context.GetAnonymousFileURL() in single-value context | 20:24 |
| natefinch | sinzui: looking.... | 20:36 |
| natefinch | sinzui: I think it's a difference in the supported version of gwacl | 20:46 |
| sinzui | ah | 20:46 |
| natefinch | sinzui: yeah, just update gwacl and that should fix it. Sorta surprised it built in one place and not the other | 20:48 |
| sinzui | natefinch, This is a case of me downgrading. I just pulled the 1.14 branch and switched to it. | 20:50 |
| sinzui | I don't think the build-release-tarball.bash script will be happy with non-trunk and it always pulls gwacl tip | 20:52 |
| === _thumper_ is now known as thumper | ||
| thumper | mramm: ping | 20:53 |
| natefinch | sinzui: what's weird is that we cut 1.14 after the change to gwacl | 20:53 |
| sinzui | oh? | 20:54 |
| natefinch | sinzui: at least, according to the timestamps on each. the gwacl change was on 9/11 and 1.14 was cut on 9/13 | 20:54 |
| sinzui | natefinch, trunk clearly has a change to make it compatible: http://pastebin.ubuntu.com/6116619/ | 20:55 |
| natefinch | sinzui: actually... nevermind, that's the latest change on 1.14, not when it was cut | 20:55 |
| sinzui | It is getting selected merged | 20:55 |
| sinzui | merged | 20:55 |
| sinzui | merges | 20:55 |
| natefinch | sinzui: yeah, that definitely needs to be on 1.14. This is actually sort of a problem with Go in general... | 20:57 |
| natefinch | sinzui: I'll ping the juju list and it'll get fixed ASAP... it's EOD for me, or I'd look more into it | 20:58 |
| sinzui | I think the immediate solution is to update the release script to acknowledge and use dependencies.tsv. Pulling tip for each is zany | 20:58 |
| natefinch | sinzui: yeah, that sounds like the right thing to do | 20:59 |
| thumper | fwereade_: ping | 21:01 |
| * thumper recalls fwereade_'s move and packing | 21:02 | |
| thumper | ah crap | 21:10 |
| * thumper makes a mental not to check the logrotate code | 21:11 | |
| mramm | thumper: pong | 21:47 |
| thumper | mramm: hey, see email about timing clashes :) | 21:48 |
| mramm | ok | 21:48 |
| mramm | I am also free later tonight, and might have to go out and help my friend get migraine medication | 21:51 |
| mramm | so perhaps it will all work out for the best ;) | 21:51 |
| thumper | mramm: so lets just try to touch base later? | 21:52 |
| mramm | sure | 21:52 |
| thumper | ok | 21:52 |
| * thumper taking last daughter to the doctor | 22:05 | |
| === thumper is now known as thumper-afk | ||
| === bigjools_ is now known as bigjools | ||
| hazmat | jam, fwiw filed bug 1226307 re tool upload | 22:26 |
| _mup_ | Bug #1226307: juju-core lazily get tools if from public bucket <juju-core:New> <https://launchpad.net/bugs/1226307> | 22:26 |
| === thumper-afk is now known as thumper | ||
| thumper | mramm: I'm around now for a bit if you are free | 23:08 |
| mramm | I am | 23:08 |
| thumper | otherwise it'll be after lunch | 23:08 |
| thumper | got time now? | 23:08 |
| thumper | mramm: I'm in the one on one hangout | 23:10 |
| davecheney | bigjools: hey | 23:39 |
| davecheney | can you fix permissions in gwacl | 23:39 |
| bigjools | davecheney: helleau | 23:39 |
| davecheney | https://launchpad.net/~gwacl-hackers | 23:39 |
| davecheney | ^ can you add juju-hackers to that | 23:39 |
| davecheney | or trasfer ownership | 23:39 |
| davecheney | please | 23:39 |
| bigjools | who wants to own it? | 23:40 |
| davecheney | juju-hackers | 23:40 |
| davecheney | make the owner mark ramm | 23:40 |
| davecheney | he loves code | 23:40 |
| bigjools | I generally dislike teams being members of other teams | 23:41 |
| bigjools | because it makes email management harder | 23:41 |
| davecheney | bigjools: please, this is a matter of urgency | 23:41 |
| bigjools | I'll add you and make you admin | 23:41 |
| davecheney | ta | 23:41 |
| bigjools | done | 23:42 |
| bigjools | but consider the team mess -it's the reason I quit juju hackers | 23:42 |
| bigjools | email from other teams that it's also part of.... PITA | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!