| thumper | screw git... | 00:10 |
|---|---|---|
| thumper | how to I reset hard? | 00:10 |
| thumper | ... | 00:10 |
| jw4 | git reset --hard | 00:10 |
| thumper | leaves me with lots of untraced files | 00:10 |
| thumper | jw4: did that | 00:10 |
| jw4 | hmm; were they added files? | 00:11 |
| thumper | how do I get rid of the untracked files? | 00:11 |
| thumper | from a screwed up pull | 00:11 |
| jw4 | well if you don't have any changes you want to keep: | 00:11 |
| jw4 | git rm -r --cached . | 00:12 |
| thumper | what does that do? | 00:12 |
| jw4 | step 1 | 00:12 |
| thumper | I want the equivalent of "bzr clean-tree" | 00:12 |
| jw4 | yep | 00:12 |
| jw4 | wait | 00:12 |
| jw4 | even easier | 00:12 |
| jw4 | git ls-files -o --exclude-standard | 00:13 |
| jw4 | | rm | 00:13 |
| jw4 | *should* remove all the untracked files | 00:13 |
| jw4 | the git rm -r --cached . removes all the files from the stage | 00:13 |
| jw4 | but you just need "git ls-files -o --exclude standard | rm" | 00:14 |
| jw4 | if you did do the rm --cached command you follow it with "git reset --hard " again to get your working copy back | 00:14 |
| menn0 | jcw, thumper: does the "git clean" command not help? | 00:15 |
| jw4 | menn0: ;-p | 00:15 |
| jw4 | thumper: just do git clean | 00:15 |
| jw4 | menn0: I've just spent hours figting line ending conflicts so my head was in the "cleanup stage" mode | 00:16 |
| jw4 | thumper: did 'git clean -fdx' work? | 00:20 |
| waigani | thumper: http://pastebin.ubuntu.com/9108069/ save that as git-clean-tree (no .sh) in your path | 00:23 |
| waigani | thumper: you can the go `git clean-tree` | 00:23 |
| thumper | waigani: I'd prefer not to have a bunch of special aliases | 00:23 |
| thumper | it makes it hard to work with others | 00:23 |
| waigani | thumper: okay, it's just two commands | 00:24 |
| thumper | git clean -df worked | 00:24 |
| waigani | 1. `git clean -df` removes any [d]irectories and [f]iles not added | 00:24 |
| waigani | 2. git checkout . discards any uncommited changes | 00:25 |
| waigani | davecheney, menn0: I've hit a bug in manual testing that I can't reproduce (yet) in the unit tests on this openPorts, so I might not get to the other tasks for a bit | 00:27 |
| waigani | "on this openPorts branch" I mean | 00:28 |
| === liam_ is now known as Guest89217 | ||
| davecheney | kk | 00:48 |
| waigani | ah, menn0 it wasn't just the tests. st.Ports is used in the actual (1.21) upgrade step to get all the ports to upgrade. That explains the bug I'm hitting in manual testing. | 00:48 |
| === Spads_ is now known as Spads | ||
| thumper | menn0: http://reviews.vapour.ws/r/497/ | 01:19 |
| thumper | menn0: if you want to look at it since you looked at the 1.20 one | 01:19 |
| thumper | menn0: actually, I'll propose it for trunk first | 01:19 |
| thumper | menn0: that is the 1.21 branch | 01:20 |
| thumper | menn0: this is the trunk comit - http://reviews.vapour.ws/r/498/ | 01:24 |
| menn0 | thumper: looking | 01:25 |
| thumper | ta | 01:25 |
| * thumper is running all the tests... | 01:38 | |
| thumper | again | 01:38 |
| thumper | had a missing import statement | 01:38 |
| menn0 | thumper: review done | 01:40 |
| * thumper is wondering why the tests aren't seeming to progress... | 01:41 | |
| thumper | normally they are done by now... | 01:42 |
| davecheney | thumper: mongo pooped itself, then you have to wait for the timeout ? | 01:42 |
| menn0 | thumper: and other review done | 01:43 |
| * thumper grunts | 01:44 | |
| thumper | ffs | 01:44 |
| thumper | why are we testing this shit in two places | 01:44 |
| davecheney | thumper: my favorite is the way that api/* and apiserver/* have the same set of tests | 01:45 |
| waigani | this is ugly ugly ugly | 01:54 |
| thumper | WT actual F | 01:56 |
| thumper | I have a test failure where it says it writes the file, but then says it doesn't exist... | 02:03 |
| thumper | I don't see anywhere where it removes it it between | 02:03 |
| thumper | and this time it panics | 02:05 |
| thumper | panic: API not available from this context | 02:06 |
| thumper | how can that work sometimes and not others? | 02:06 |
| thumper | fucking weird... the real upgrades work, but the tests for jujud fail | 02:12 |
| menn0 | hmmmm | 02:15 |
| menn0 | you can't destroy a 1.22 env with a 1.20 client | 02:15 |
| menn0 | $ /usr/bin/juju destroy-environment --force --yes local | 02:15 |
| menn0 | WARNING unknown config field "block-destroy-environment" | 02:15 |
| menn0 | WARNING unknown config field "agent-metadata-url" | 02:15 |
| menn0 | WARNING unknown config field "uuid" | 02:15 |
| menn0 | WARNING unknown config field "prefer-ipv6" | 02:15 |
| menn0 | WARNING unknown config field "set-numa-control-policy" | 02:15 |
| menn0 | WARNING unknown config field "block-destroy-environment" | 02:15 |
| menn0 | WARNING unknown config field "uuid" | 02:15 |
| menn0 | WARNING unknown config field "agent-metadata-url" | 02:15 |
| menn0 | WARNING unknown config field "set-numa-control-policy" | 02:16 |
| menn0 | WARNING unknown config field "prefer-ipv6" | 02:16 |
| menn0 | WARNING unknown config field "prefer-ipv6" | 02:16 |
| menn0 | WARNING unknown config field "block-destroy-environment" | 02:16 |
| menn0 | WARNING unknown config field "agent-metadata-url" | 02:16 |
| menn0 | WARNING unknown config field "uuid" | 02:16 |
| menn0 | WARNING unknown config field "set-numa-control-policy" | 02:16 |
| menn0 | ERROR cannot find network interface "": net: invalid interface name | 02:16 |
| menn0 | ERROR failure setting config: cannot find address of network-bridge: "": net: invalid interface name | 02:16 |
| menn0 | 1.22 client works | 02:16 |
| axw | wallyworld_: that MAAS API meeting is going to be difficult for me to attend, I have to take my daughter to school then | 02:17 |
| wallyworld_ | ah | 02:17 |
| thumper | ah... | 02:18 |
| * thumper pokes the mock | 02:18 | |
| wallyworld_ | axw: would 30 minutes later work? | 02:18 |
| axw | wallyworld_: worse :) 2 hours earlier would be good... | 02:18 |
| axw | 1 hour earlier at a stretch | 02:18 |
| wallyworld_ | that clashes with the sprint schedule i think, i'll check | 02:19 |
| wallyworld_ | yeah, sprint sessions are earlier | 02:21 |
| axw | wallyworld_: I could go an hour later too | 02:21 |
| wallyworld_ | maybe an hour later? that would be 7pm for them | 02:21 |
| * thumper stabs this tangled mess repeatedly | 02:21 | |
| wallyworld_ | they can delay their dinner maybe, or eat earlier | 02:21 |
| wallyworld_ | i'll check with alexis | 02:21 |
| thumper | menn0: ok, need some help here | 02:26 |
| menn0 | thumper: ok | 02:28 |
| menn0 | thumper: standup channel? | 02:28 |
| thumper | yep | 02:28 |
| menn0 | thumper, davecheney: here's the env UUID upgrade for the meterStatus collection | 03:09 |
| menn0 | http://reviews.vapour.ws/r/499/diff/ | 03:09 |
| menn0 | waigani: here's the meterstatus env uuid work http://reviews.vapour.ws/r/499/diff/ | 03:14 |
| * menn0 is off to run some errands | 03:15 | |
| waigani | menn0: done | 03:30 |
| === noodles785 is now known as noodles775 | ||
| thumper | menn0: http://reviews.vapour.ws/r/497/diff/# has been updated to unblock 1.21 release | 03:55 |
| thumper | menn0: I'll fix for 1.22 with different patch that splits out the work | 03:55 |
| === Spads_ is now known as Spads | ||
| menn0 | thumper: looking | 04:18 |
| menn0 | thumper: i see you've already submitted so all good. | 04:25 |
| menn0 | thumper: good idea to get this in and then do the split. | 04:25 |
| menn0 | wallyworld_: ping | 04:28 |
| wallyworld_ | hi, otp, one sec | 04:28 |
| menn0 | wallyworld_: np | 04:29 |
| wallyworld_ | menn0: hiya | 04:38 |
| menn0 | wallyworld_: so I discovered earlier that a 1.20 client can't destroy a 1.22 env | 04:39 |
| menn0 | wallyworld_: would you call that a bug? | 04:39 |
| wallyworld_ | i think so | 04:40 |
| wallyworld_ | yes | 04:40 |
| wallyworld_ | sigh | 04:40 |
| wallyworld_ | raise a bug and we'll fix it for 1.22 | 04:40 |
| menn0 | there emitted error is: | 04:40 |
| menn0 | ERROR cannot find network interface "": net: invalid interface name | 04:40 |
| menn0 | ERROR failure setting config: cannot find address of network-bridge: "": net: invalid interface name | 04:40 |
| menn0 | writing up a bug now | 04:40 |
| wallyworld_ | ok, so some new config was introduced in 1.22 | 04:40 |
| wallyworld_ | ta | 04:40 |
| wallyworld_ | 1.22 needs to be more robust to such situation | 04:41 |
| menn0 | wallyworld_: here tis: bug 1394450 | 04:48 |
| mup | Bug #1394450: 1.20 client can't destroy a 1.22 environment <juju-core:New> <https://launchpad.net/bugs/1394450> | 04:48 |
| wallyworld_ | ta | 04:48 |
| anastasiamac | menn0:curiosity kills me - would this happen often that a client is of older version than environment? | 04:53 |
| anastasiamac | menn0: i would have assumed that more often u'd encounter 1.20 env and 1.22 client, for eg... | 04:54 |
| anastasiamac | menn0: apart from devs?.. | 04:54 |
| wallyworld_ | this also affect 1.21 | 04:55 |
| menn0 | anastasiamac: good question. I guess it's not that common. I just noticed it by accident after I made a mistake while testing upgrades. | 04:57 |
| menn0 | anastasiamac: still worth fixing if we can I think. | 04:57 |
| menn0 | wallyworld_: i haven't tested with 1.21 but you're probably correct. | 04:57 |
| menn0 | wallyworld_: let me check | 04:57 |
| anastasiamac | menn0: of course ;-) whether fix is needed or not is not even a question :-) | 04:57 |
| wallyworld_ | this fix would be to make the network-bridge attribute have a default of lxcbr0 instead of "" i think | 04:58 |
| wallyworld_ | although it appears the code does use lxcbr0 if network bridge is "" | 05:00 |
| wallyworld_ | so i'm not sure off hand how this occurs | 05:00 |
| === kadams54 is now known as kadams54-away | ||
| menn0 | wallyworld_, anastasiamac : i've tried destroying with a 1.21 client and that works fine | 05:02 |
| menn0 | so it looks like it's just the 1.20 client that has a problem | 05:02 |
| wallyworld_ | menn0: ah, i meant destroying a 1.21 env ith a 1.20 client | 05:02 |
| menn0 | ok right | 05:03 |
| menn0 | wallyworld_: i'll try that then :) | 05:03 |
| anastasiamac | wallyworld_: it's coming from utils.network.go ;-( | 05:03 |
| wallyworld_ | not sure if the issue needs fixing in both 1.21 and 1.22 | 05:03 |
| wallyworld_ | network.go won't work though if we pass in "" for networkName | 05:04 |
| anastasiamac | wallyworld_: we find network interface fine (i dont think we r passing "") | 05:05 |
| anastasiamac | wallyworld_: we cannot find addrs for the network interface... | 05:05 |
| wallyworld_ | the bug seems to indicate otherwise | 05:05 |
| wallyworld_ | but i could be wrong | 05:05 |
| wallyworld_ | ERROR failure setting config: cannot find address of network-bridge: "" | 05:06 |
| wallyworld_ | seems to indicate that networkBridge := config.networkBridge() returned "" | 05:06 |
| menn0 | wallyworld_, anastasiamac: as suspected, a 1.20 client can't delete a 1.21 env either | 05:07 |
| menn0 | wallyworld_, anastasiamac: ticket updated | 05:07 |
| wallyworld_ | thanks menn0 | 05:07 |
| wallyworld_ | we'll need to fix this for the 1.21 release | 05:07 |
| anastasiamac | wallyworld_: yep ;( | 05:07 |
| anastasiamac | wallyworld_: and yes ;( | 05:07 |
| anastasiamac | wallyworld_: as u suggested, config var "network-bridge" should probably b defaulted to something other than "" | 05:10 |
| wallyworld_ | yeah, do it at the schema level instead of in the getter | 05:10 |
| wallyworld_ | but, i'm not 100% sure why the current code doesn't work | 05:10 |
| anastasiamac | wallyworld_: well, wher r we assuming that network bridge is lxcbr0 if we get ""? | 05:12 |
| anastasiamac | wallyworld_: from what m seeing we r relying that network bridge is provided | 05:13 |
| wallyworld_ | before calling getAddressForInterface(), the network bridge value is gotten like so: networkBridge := config.networkBridge() | 05:14 |
| wallyworld_ | that should have resulted in a non "" being returned | 05:14 |
| wallyworld_ | so more digging is needed to find out why it is failing | 05:15 |
| anastasiamac | wallyworld_: that's easy. network-bridge in config defaults to "" | 05:15 |
| wallyworld_ | yes, but the getter turns it into a value | 05:16 |
| wallyworld_ | the getter has code: | 05:16 |
| wallyworld_ | if name == "" { | 05:16 |
| wallyworld_ | return lxc.DefaultLxcBridge | 05:16 |
| anastasiamac | wallyworld_: assuming instance.LXC | 05:17 |
| anastasiamac | wallyworld_: can c.container b something other than LXC or KVM | 05:17 |
| wallyworld_ | no | 05:17 |
| jw4 | Actions refactor PR - large, but much of it is mechanical. PTAL http://reviews.vapour.ws/r/502/ | 06:03 |
| jw4 | fwereade_, TheMue ptal too ^^^ | 06:04 |
| jw4 | but I welcome anyone's feedback :) | 06:05 |
| mattyw | morning all | 08:08 |
| TheMue | morning | 09:02 |
| TheMue | jw4: will take a look (in case you're still awake *g*) | 09:03 |
| dimitern | morning TheMue , mattyw | 09:44 |
| TheMue | dimitern: o/ | 09:45 |
| mattyw | dimitern, TheMue good morning! | 09:45 |
| dimitern | does anyone know off hand how to file bugs for subrepos? I found an issue with juju/utils.. maybe I'll just file it against juju-core | 09:46 |
| davecheney | dimitern: depends | 09:49 |
| davecheney | i've logged them against the repo on GH | 09:49 |
| davecheney | ... when it's thumpers stuff :) | 09:49 |
| dimitern | davecheney, right ;) so I'll file an issue in GH and a link to a bug in LP then | 09:50 |
| davecheney | dimitern: sgtm | 09:50 |
| TheMue | davecheney: thanks for editing right for the diary doc | 09:57 |
| davecheney | TheMue: no worries | 09:58 |
| davecheney | i was surprised that @canonical didn't ahve edit already | 09:58 |
| davecheney | ¯\_(ã)_/¯ | 09:58 |
| davecheney | urgh | 09:59 |
| TheMue | davecheney: yes, I wondered too | 09:59 |
| davecheney | y are none of you in the hangout ? | 09:59 |
| davecheney | Y U NO JOIN HANGOUT | 10:00 |
| TheMue | oh, now? sh** | 10:00 |
| TheMue | joining | 10:00 |
| voidspace | omw | 10:00 |
| jam | fwereade_: team call ? | 10:02 |
| voidspace | dimitern: when you get a chance | 10:02 |
| voidspace | dimitern: http://reviews.vapour.ws/r/504/ | 10:02 |
| dimitern | voidspace, will look in a bit | 10:03 |
| voidspace | dimitern: and then I need to talk to you about "what next" | 10:03 |
| voidspace | dimitern: there are several tasks that look achievable for me, but all with some "hand holding" :-) | 10:03 |
| jam | axw: ping for team call ? | 10:04 |
| axw | doh | 10:05 |
| axw | jam: thanks | 10:05 |
| jam | wwitzel3: perrito666: are you coming to the team meeting ? | 10:06 |
| dimitern | mattyw, team call? | 10:06 |
| voidspace | cold in my room - time to run the whole juju test suite and warm up the computer a bit | 10:07 |
| tasdomas | dimitern, mattyw has taken an early lunch | 10:08 |
| voidspace | davecheney: thanks for the review | 10:30 |
| perrito666 | jam: sorry had to solve a couple of last minute issues did not make it | 10:34 |
| perrito666 | the public transport went on strike the same day the city is flooding with rain.. have to love these people | 10:35 |
| davecheney | voidspace: no wuks | 10:38 |
| natefinch | ahh crap, I guess the core team meeting moved an 3 | 11:04 |
| natefinch | hour earlier? | 11:04 |
| natefinch | stupid daylight savings | 11:05 |
| natefinch | dammit, utopic broke fullscreen.... any app that goes fullscreen now lags like hell | 11:21 |
| perrito666 | natefinch: from my viewpoint it has not moved | 11:22 |
| natefinch | perrito666: likely because your country does do stupid daylight savings crap | 11:22 |
| perrito666 | but 3 hs is a bit much | 11:23 |
| davecheney | has anyone tried ubuntu.next ? | 11:24 |
| natefinch | davecheney: like post utopic? | 11:26 |
| natefinch | dammit now my mouse is invisible | 11:28 |
| davecheney | yup | 11:28 |
| davecheney | the one that jane talked about in the canonical newsletter | 11:28 |
| natefinch | tried switching video drivers to see if that would help the fullscreen problem | 11:29 |
| davecheney | unity 8 is the default | 11:29 |
| natefinch | maybe you should ask first if anyone has read the newsletter ;) | 11:29 |
| natefinch | I haven't heard of anyone using ijt. | 11:30 |
| perrito666 | natefinch: just pat down your desk, must be around | 11:30 |
| natefinch | lol | 11:30 |
| voidspace | :-) | 11:30 |
| natefinch | brb gonna reboot | 11:30 |
| perrito666 | davecheney: I am curious about unity yet I do need some stability on the rest of my system | 11:31 |
| natefinch | I'm willing, I'm a glutton for punishment ;) | 11:31 |
| davecheney | perrito666: natefinch don't be a stooge, install it in a vm | 11:40 |
| davecheney | you'll know what I mean | 11:40 |
| === natefinch is now known as nate-tablet | ||
| nate-tablet | well this is going well | 11:41 |
| nate-tablet | can't log in to Ubuntu because it errors when trying to switch monitor config and dumpsme back at login | 11:42 |
| nate-tablet | nice error handling there | 11:42 |
| nate-tablet | is there a trick to login without the log in screen? | 11:45 |
| davecheney | gotta enable auto login ? | 11:45 |
| davecheney | that is part of gdm | 11:45 |
| nate-tablet | or is there a way to with from the guest session? that log in works fine | 11:47 |
| nate-tablet | s/with/with/ | 11:47 |
| nate-tablet | auth | 11:47 |
| nate-tablet | stupid tablet | 11:48 |
| * nate-tablet goes to google "switch display driver from terminal" | 11:51 | |
| voidspace | nate-tablet: so, the utopic upgrade went well then... | 11:52 |
| nate-tablet | it might be mostly a driver issue and one egregious | 11:53 |
| nate-tablet | ly | 11:53 |
| nate-tablet | bad error handling | 11:53 |
| voidspace | right | 11:53 |
| voidspace | I hope you get it sorted | 11:53 |
| voidspace | sounds like the opposite of fun | 11:53 |
| davecheney | i don't mean to swear in church | 11:53 |
| davecheney | but ubuntu only really works on thinkpads | 11:54 |
| voidspace | it works great on my desktop | 11:54 |
| davecheney | intel graphics ? | 11:54 |
| voidspace | but then I picked all the components for compatibility and built myself | 11:54 |
| voidspace | nope, amd I think | 11:54 |
| voidspace | maybe I've just been lucky | 11:54 |
| voidspace | driving four monitors from one card though | 11:54 |
| perrito666 | nate-tablet: enter a session in your shell | 11:57 |
| perrito666 | then DISPLAY=:1 startx& | 11:57 |
| perrito666 | then DISPLAY=:1 whateverthewmiscalledthesedays | 11:58 |
| perrito666 | davecheney: to be honest it sometimes fails on mine, but yes, I have a preference for thinkpads when using linux, just in case | 11:59 |
| nate-tablet | davecheney - this is the first major problem I've had | 12:01 |
| nate-tablet | (that wasn't caused by juju) | 12:02 |
| nate-tablet | besides, I figured it's pretty safe using the same model laptop as Mark S ;) | 12:04 |
| perrito666 | nate-tablet: well, you seem to have a bit different one | 12:05 |
| perrito666 | nate-tablet: the right trick, is to have the same laptop linus torvalds has, so when everything else fails, at least the kernel still works | 12:06 |
| nate-tablet | maybe he's not running two external monitors | 12:07 |
| perrito666 | nate-tablet: maybe, I can only run one and it works well enough | 12:08 |
| perrito666 | to solve that I am tempted to get a desktop machine, but I am to picky about hardware | 12:08 |
| davecheney | nate-tablet: i like that qualification | 12:13 |
| davecheney | ther is a reason i have a 8gb /tmp partition | 12:13 |
| davecheney | in ram | 12:13 |
| davecheney | (stupud test runner bug) | 12:13 |
| nate-tablet | my two biggest problems with Ubuntu have been back error handling | 12:14 |
| nate-tablet | bad | 12:14 |
| nate-tablet | no etc/networks? no network! ....what ever happened to sane defaults? | 12:16 |
| davecheney | nate-tablet: yeah, no desktop | 12:16 |
| davecheney | no network manager | 12:16 |
| davecheney | no network | 12:16 |
| davecheney | catch 22 | 12:16 |
| dimitern | any reviewers willing to take a look at a trivial fix for bug 1394524? https://github.com/juju/utils/pull/91 | 12:46 |
| mup | Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1394524> | 12:46 |
| TheMue | dimitern: will do | 12:47 |
| dimitern | TheMue, cheers | 12:48 |
| dimitern | jw4, bodie_, hey guys, if you can have a look perhaps ^^ as the fix might have some implications for windows? | 12:49 |
| TheMue | dimitern: done | 12:51 |
| dimitern | TheMue, thanks | 12:52 |
| dimitern | rogpeppe, ping | 12:52 |
| TheMue | yw | 12:52 |
| rogpeppe | dimitern: pong | 12:52 |
| dimitern | rogpeppe, hey, do you know if juju/utils is running under the landing bot? How to land a patch on that subrepo? | 12:52 |
| rogpeppe | dimitern: i don't think so | 12:53 |
| rogpeppe | dimitern: i can land patches there | 12:53 |
| rogpeppe | dimitern: isn't the landing bot intended for repos that actually build binaries? | 12:54 |
| rogpeppe | dimitern: (rather than just packages) | 12:54 |
| rogpeppe | dimitern: i think the landing bot for juju-core should actually run go test github.com/juju/... | 12:54 |
| rogpeppe | dimitern: or at any rate for the packages juju-core depends on | 12:55 |
| dimitern | rogpeppe, yeah it does | 12:55 |
| rogpeppe | dimitern: ah, cool | 12:55 |
| dimitern | rogpeppe, ok, so how will you land it? | 12:55 |
| rogpeppe | dimitern: i push the big green button :) | 12:55 |
| dimitern | rogpeppe, ha :) ok, I'll try, thanks! | 12:56 |
| dimitern | but first let's try a $$merge$$ comment to see if the bot will pick it up | 12:56 |
| mattyw | folks - sorry I missed the core hangout - I have my reasons - but there is no excuse | 13:21 |
| jam | mattyw: there is *no* excuse, you let us all down. In fact, we could barely even have the meeting at all without you. | 13:22 |
| jam | :) | 13:22 |
| perrito666 | mattyw: happens, I did too, anyway I think there is no room for all of us | 13:22 |
| dimitern | TheMue, another related trivial - http://reviews.vapour.ws/r/506/ ? | 13:22 |
| mattyw | jam, most of all I let myself down | 13:23 |
| TheMue | dimitern: ok, if it's trivial I can jump in. ;) | 13:23 |
| dimitern | TheMue, :) it's just updating dependencies.tsv | 13:23 |
| TheMue | dimitern: ic, and where is the unit test for it? *lol* | 13:24 |
| dimitern | TheMue, :D I wish we had some | 13:24 |
| TheMue | dimitern: also all those leading spaces/tabs | 13:24 |
| TheMue | dimitern: somehow 6bfed5692f0d524bab3be5976f26d24bd4d3f677 is very self-documenting | 13:25 |
| dimitern | TheMue, yeah, indeed | 13:25 |
| TheMue | dimitern: so, done | 13:25 |
| dimitern | TheMue, thanks! | 13:25 |
| TheMue | dimitern: always a pleasure | 13:25 |
| * TheMue currently does another, larger review, so has been in the right mode | 13:26 | |
| jw4 | TheMue: I trust your other larger review is mine :) | 13:35 |
| TheMue | jw4: eh, ehm, why do you think so? *grin* | 13:36 |
| jw4 | TheMue: :) | 13:36 |
| TheMue | jw4: you already work on daves feedback? | 13:40 |
| jw4 | TheMue: I'm starting to go through it... | 13:40 |
| TheMue | jw4: fine, it's catching most of the points | 13:41 |
| jw4 | TheMue: a lot of his feedback is about things that are bigger than my change | 13:41 |
| jw4 | TheMue: but I'll respond to each one in the PR | 13:41 |
| TheMue | jw4: yep, so for some of the we may need to create a follow-up | 13:42 |
| jw4 | kk | 13:42 |
| rogpeppe | hmm, so i've just discovered that juju deploy local:trusty/foo can totally ignore the directory $JUJU_REPOSITORY/trusty/foo if there's another charm in there with Meta().Name == "foo" | 13:53 |
| rogpeppe | fwereade_: does that seem right to you? it certainly surprised me | 13:54 |
| fwereade_ | rogpeppe, it's insane but As Designed :/ | 13:54 |
| rogpeppe | fwereade_: can we just change it please? :) | 13:54 |
| rogpeppe | fwereade_: can you think of something it might break? | 13:55 |
| fwereade_ | rogpeppe, well, it opens the issue of meta name not matching the url we use | 13:56 |
| rogpeppe | fwereade_: we could make it complain if the meta name didn't match the dir name | 13:56 |
| fwereade_ | rogpeppe, it's never been *quite* annoying enough to reach the top of the list; in principle I'd be glad to see it improved; in practice I think we'd need to talk to the people who actually use local repos | 13:57 |
| rogpeppe | fwereade_: i think that having meta name in there is silly anyway, but at least then we wouldn't be in such a ridiculous situation (i created the directory, deployed the charm, then wondered wtf was going on) | 13:57 |
| fwereade_ | rogpeppe, the other reason not to do it is the hope that we'll be able to transition to just publishing directories directly, and forget the whole local repo thing entirely | 13:58 |
| rogpeppe | fwereade_: i'm guessing we'll still want a local repo | 13:59 |
| rogpeppe | fwereade_: i guess it depends how important the naming-after-series thing is | 13:59 |
| fwereade_ | rogpeppe, don't we end up needing series in the metadata in the general case though? | 14:00 |
| rogpeppe | fwereade_: that is, as we know, a controversial topic :) | 14:00 |
| rogpeppe | fwereade_: FWIW I'm +1 | 14:00 |
| fwereade_ | rogpeppe, well, it's only lp-based charms where we get the magic series-from-name thing -- where else is it going to come from? | 14:00 |
| fwereade_ | rogpeppe, I'm probably just blanking, but I don't recall the controversy | 14:01 |
| fwereade_ | rogpeppe, multiple-series charms are controversial for usre | 14:01 |
| fwereade_ | rogpeppe, (lp-based and local-based, I suppose, but local is just aping lp, I think) | 14:01 |
| rogpeppe | fwereade_: except... all the official charms are multiple series AFAIK. | 14:02 |
| fwereade_ | rogpeppe, IMO the only ones where that's really defensible are the subordinates | 14:02 |
| rogpeppe | fwereade_: i'd like to robustly defend the ability to create portable software :) | 14:03 |
| rogpeppe | fwereade_: and we're not even talking portability across different unix flavours here | 14:04 |
| fwereade_ | rogpeppe, I'd like to dismissively pooh-pooh the notion that anyone cares what OS they use, so long as their workloads function properly | 14:04 |
| fwereade_ | ;) | 14:04 |
| fwereade_ | rogpeppe, subordinates come crashing hard against that statement though | 14:04 |
| rogpeppe | fwereade_: i care that i understand something about the OS so i can debug it. i.e. not windows.. | 14:05 |
| rogpeppe | fwereade_: yeah, subordinates imply we want a single service that can be deployed to multiple series | 14:05 |
| fwereade_ | rogpeppe, and if we can fix it for subordinates, we can fix it for everything | 14:05 |
| fwereade_ | rogpeppe, it's just not looming particularly large in my mind atm | 14:05 |
| fwereade_ | rogpeppe, because, well, subordinates potentially need to be *really* cross-platform | 14:06 |
| rogpeppe | fwereade_: it's something that's looming large in my mind, with some possibly significant changes in the charm store needed | 14:06 |
| rogpeppe | fwereade_: well, yes | 14:06 |
| rogpeppe | fwereade_: i'd like to take the series out of the charm name entirely. that would help quite a lot of things. | 14:07 |
| fwereade_ | rogpeppe, series feels like a pretty useful part of a charm url tbh | 14:09 |
| fwereade_ | rogpeppe, but I'm looking at it from a different perspective, I suspect, keen to hear more | 14:09 |
| rogpeppe | [14:04:13] <fwereade_> rogpeppe, I'd like to dismissively pooh-pooh the notion that anyone cares what OS they use, so long as their workloads function properly | 14:09 |
| rogpeppe | :) | 14:09 |
| rogpeppe | fwereade_: it assumes that the OS is just as important as the workload | 14:09 |
| fwereade_ | rogpeppe, "juju deploy whatever" | 14:10 |
| rogpeppe | fwereade_: yup | 14:10 |
| fwereade_ | rogpeppe, *we* have to care about the charm url, so that our users don't ;) | 14:10 |
| fwereade_ | rogpeppe, the series, I mean | 14:10 |
| fwereade_ | rogpeppe, and having the series part of the url is convenient for us, at least | 14:10 |
| rogpeppe | fwereade_: yup. that, for me, means that the URL (*the* user-visible part of a charm) shouldn't contain the series | 14:11 |
| rogpeppe | fwereade_: it's *kinda* convenient for us, but i don't think we gain that much from it | 14:11 |
| fwereade_ | rogpeppe, well, we want some way to distinguish between charms for the same workload with different targets, don't we? | 14:12 |
| fwereade_ | rogpeppe, series does that | 14:12 |
| rogpeppe | fwereade_: isn't that what constraints do? | 14:12 |
| fwereade_ | rogpeppe, and it's easier to read than a hash or something | 14:12 |
| rogpeppe | fwereade_: i see series as just one aspect of the "aspects of the target that i care about" continuum | 14:13 |
| fwereade_ | rogpeppe, the centos, windows, and ubuntu apache charms will actively differ in a number of respects, though, right? | 14:14 |
| rogpeppe | fwereade_: oh yes. but that's our problem - the user should be oblivious to their differences, i think. | 14:14 |
| fwereade_ | rogpeppe, distinguishing by version number is terrifyingly opaque | 14:14 |
| fwereade_ | rogpeppe, and jamming the target into the name feels strictly inferior to making it a separate component | 14:15 |
| fwereade_ | rogpeppe, I can't really see other options | 14:15 |
| rogpeppe | fwereade_: i think i'd provide a way to publish several charms (with different series) under the same name, and let juju select the appropriate one. | 14:16 |
| rogpeppe | fwereade_: that's *kinda* what happens already | 14:16 |
| fwereade_ | rogpeppe, right, but if you happen to deploy the same workload on different OSs, you want to be aware that they're running different charms | 14:16 |
| rogpeppe | fwereade_: i'm not sure | 14:17 |
| rogpeppe | fwereade_: only when things go wrong | 14:17 |
| rogpeppe | fwereade_: but there are all sorts of things you want to know in that case | 14:17 |
| fwereade_ | rogpeppe, well, they *are* different charms... if every charm "url" really points to an opaquely context-sensitive redirect (to something without a url?), I think it will be... confusing | 14:19 |
| rogpeppe | fwereade_: i guess it depends how much you care about the workload vs how it's implemented | 14:20 |
| fwereade_ | rogpeppe, for me it's more about a charm url being unambiguous | 14:21 |
| fwereade_ | rogpeppe, I *don't* actually care about the series, any more than I care about the revision | 14:22 |
| fwereade_ | rogpeppe, but both those components disambiguate usefully | 14:22 |
| === katco` is now known as katco | ||
| rogpeppe | fwereade_: in the end, what the charm *does* can be arbitrarily different depending on platform anyway, regardless of what the contents of the charm are | 14:24 |
| sinzui | dimitern, does bug 1394524 need to merged into the 1.21 branch? | 14:24 |
| mup | Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1394524> | 14:24 |
| fwereade_ | rogpeppe, as it can be depending on revision too, right? | 14:24 |
| rogpeppe | fwereade_: yeah. | 14:25 |
| anastasiamac | sinzui: ping | 14:29 |
| === enterprisedc_ is now known as enterprisedc | ||
| sinzui | hi anastasiamac | 14:31 |
| anastasiamac | sinzui: about bug 1394450 | 14:32 |
| mup | Bug #1394450: 1.20 client can't destroy a 1.21 or 1.22 environment <destroy-environment> <regression> <juju-core:Triaged by anastasia-macmood> <juju-core 1.21:Triaged by anastasia-macmood> <https://launchpad.net/bugs/1394450> | 14:32 |
| anastasiamac | sinzui: m not convinced it needs backporting | 14:32 |
| sinzui | :) | 14:32 |
| anastasiamac | sinzui: different version had different defaults for network bridge names | 14:32 |
| anastasiamac | sinzui: this ione is specifically about default in 1.22 changing to "" | 14:33 |
| anastasiamac | sinzui:1.22 works fine because we specify container specific defaults in the getter | 14:34 |
| sinzui | anastasiamac, so 1.22 needs to change to allow any older juju to destroy it? | 14:34 |
| anastasiamac | sinzui: however, older clients don't use getter but rather schema default and hence get "" | 14:34 |
| jw4 | TheMue: responded to davecheney 's feedback - any further feedback on this PR? http://reviews.vapour.ws/r/502/ | 14:34 |
| anastasiamac | sinzui: kind of - 1.22 needs to set container specific defaults when it sets up env config | 14:35 |
| jw4 | fwereade_: I'd appreciate your review of ^^ too | 14:35 |
| anastasiamac | sinzui: so I am hoping that it's just the change on 1.22 ;-) | 14:35 |
| sinzui | me too. thank you anastasiamac | 14:35 |
| anastasiamac | sinzui: gr8 :) thnx! | 14:36 |
| TheMue | jw4: so far mostly more simple comments, dave already found most | 14:36 |
| jw4 | tx TheMue | 14:36 |
| TheMue | jw4: will submit in a few minutes | 14:37 |
| jw4 | kk | 14:37 |
| TheMue | sometimes diffs are really strange, when new functions are shown as placed inside an existing function and only two lines of the old code are shown afterwards | 14:39 |
| jw4 | TheMue: I know, I've noticed that too :( | 14:39 |
| === kadams54 is now known as kadams54-away | ||
| TheMue | jw4: so, published my comments and now go through your answers to daves comments | 14:54 |
| jw4 | TheMue: perfect | 14:54 |
| fwereade_ | jw4, sent a few thoughts/questions | 14:57 |
| jw4 | fwereade_: excellent, thanks | 14:57 |
| rogpeppe | fwereade_: if i do a juju upgrade-charm --force when a unit is an error state, should i expect to get an upgrade-charm hook called at some point in the future? | 14:59 |
| fwereade_ | rogpeppe, no | 15:02 |
| fwereade_ | rogpeppe, if upgrade-charm is important you basically have to prefix all your hooks with an effective maybe-upgrade-hook :/ | 15:03 |
| rogpeppe | fwereade_: how do you know if the charm has been upgraded? | 15:03 |
| fwereade_ | rogpeppe, heh. | 15:04 |
| fwereade_ | rogpeppe, copy the charm url file somewhere in the upgrade-charm hook? | 15:04 |
| fwereade_ | rogpeppe, not that, as a charm author, you're really meant to know about or depend upon that file | 15:05 |
| rogpeppe | fwereade_: yeah, i didn't know that existed | 15:05 |
| rogpeppe | fwereade_: i guess i could hash the contents of the charm directory | 15:05 |
| rogpeppe | fwereade_: or look at the mtime of the metadata.yaml file | 15:05 |
| fwereade_ | rogpeppe, or, hmm, copy the revision file somewhere? | 15:06 |
| fwereade_ | rogpeppe, although that *could* fail if you --switch | 15:06 |
| rogpeppe | fwereade_: is there guaranteed to be a revision file? maybe, i guess | 15:06 |
| fwereade_ | rogpeppe, in a deployed charm, yes, I think so | 15:06 |
| rogpeppe | fwereade_: yeah, doesn't seem too reliable given switch | 15:07 |
| === liam_ is now known as Guest73106 | ||
| rogpeppe | fwereade_: perhaps this is worth fixing. i think it may be woth guaranteeing that upgrade-charm will be called when the charm is upgraded | 15:08 |
| rogpeppe | fwereade_: the problem is there's no decent way around it. if a charm dies in a relation hook and the only way to fix it is to upgrade the charm, there's no way of triggering the upgrade-charm hook *and* retrying the relation hook AFAICS | 15:09 |
| perrito666 | nate-tablet: did you fix your computer? | 15:12 |
| nate-tablet | I'm still on my ta let | 15:12 |
| nate-tablet | tablet | 15:12 |
| nate-tablet | support is trying to help | 15:13 |
| fwereade_ | rogpeppe, just a mo, sorry, laura just got home | 15:15 |
| rogpeppe | fwereade_: np | 15:15 |
| jw4 | fwereade_: at your convenience, after reading my responses to your review, we can chat about your issues raised? | 15:16 |
| fwereade_ | rogpeppe, so, yes, that was essentially the issue | 15:18 |
| fwereade_ | rogpeppe, we don't really want to run upgrade-charm in the middle of an incomplete, errored hook | 15:18 |
| rogpeppe | fwereade_: my expectation was that you'd upgrade the charm, retry the hook, and then upgrade-charm would be run | 15:19 |
| fwereade_ | rogpeppe, really, honestly, there are only two answers -- either don't depend on upgrade-charm, or make your charm bulletproof enough that no user will have to force-upgrade it :/ | 15:19 |
| fwereade_ | rogpeppe, yay preserving compatibility | 15:20 |
| fwereade_ | rogpeppe, fwiw that *is* documented, I'm pretty sure | 15:20 |
| fwereade_ | rogpeppe, not saying it's *good* though | 15:20 |
| fwereade_ | rogpeppe, ok, that is not an unreasonable expectation, but let's dig in | 15:20 |
| fwereade_ | rogpeppe, if we do that | 15:20 |
| fwereade_ | rogpeppe, we're implicitly denying the need for an upgrade-charm to ever happen, aren't we? | 15:21 |
| rogpeppe | fwereade_: i wouldn't mind your "treat every hook as if it might be run after an upgrade" solution *if* there was a way of finding out whether a charm's been upgraded | 15:21 |
| fwereade_ | rogpeppe, because we're assuming that any hook can be rerun safely after an upgrade *without* an upgrade-charm | 15:21 |
| rogpeppe | fwereade_: yeah | 15:21 |
| rogpeppe | fwereade_: i'd realised that | 15:21 |
| fwereade_ | rogpeppe, it would really feel *safer*, I think, to require that upgrade-charm be able to handle running in any state... | 15:23 |
| rogpeppe | fwereade_: yes, and then just run it and leave the current error state unaffected | 15:23 |
| fwereade_ | rogpeppe, but then we guarantee that config-changed will run after upgrade-charm, so we can either relax *that* restriction or raise the spectre of a double-nested error state with a queued config-changed lurkingin there somewhere too | 15:24 |
| rogpeppe | fwereade_: ha | 15:24 |
| fwereade_ | rogpeppe, happy fun times, eh? | 15:24 |
| rogpeppe | fwereade_: happy fun times indeed | 15:24 |
| rogpeppe | fwereade_: when we have charm status, i'm going to write charms such that their hooks never fail | 15:25 |
| fwereade_ | rogpeppe, +100 to that | 15:25 |
| ericsnow | nate-tablet: FYI, I'll be here sporadically again today (feeling a bit better) | 15:25 |
| nate-tablet | ericsnow: ok | 15:29 |
| nate-tablet | now I have managed to install lubuntu (which didn't help) and can't get it to go away | 15:30 |
| * nate-tablet is a special flower | 15:31 | |
| wwitzel3 | my upgrade went about the same as nate's | 15:32 |
| wwitzel3 | looked ok, then just progressively degraded everytime i used my laptop, until I had to reinstall | 15:32 |
| nate-tablet | luckily I just backed everything up to a USB drive | 15:34 |
| nate-tablet | so if worse comes to worse..... | 15:34 |
| katco | nate-tablet: borked upgrade from 10.04 .10? | 15:45 |
| fwereade_ | jw4, yeah, I think all those things are fine for followups | 15:45 |
| jw4 | fwereade_: okay; I'll add issues to our leankit board and drop the issues here | 15:46 |
| fwereade_ | jw4, a thought about the notifications, though -- would it be sane to encode the statuses in the notification _ids, and to add unconditional remove-other-possible-notification-kind ops to the transactions that notify? | 15:47 |
| jw4 | fwereade_: interesting | 15:47 |
| fwereade_ | jw4, that might be insane or it might be brilliant or it might just be meh, I just want us to think about the possibility space a bit here | 15:47 |
| TheMue | rogpeppe: ping | 15:47 |
| jw4 | fwereade_: yeah I like it. Requires a little more bookkeeping but seems worth it | 15:48 |
| fwereade_ | jw4, and saves us the expensive-style watcher | 15:48 |
| jw4 | fwereade_: and the beauty is there is a logic hole in the expensive watcher that would be addressed by this approach | 15:49 |
| TheMue | rogpeppe: could you tell me a bit more about the yaml change so that I change the test? | 15:49 |
| rogpeppe | TheMue: pong | 15:49 |
| * fwereade_ cheers | 15:49 | |
| rogpeppe | TheMue: you need to change the tests so that they don't depend on the specific marshaling details of YAML | 15:49 |
| rogpeppe | TheMue: have you run the tests yet, with the latest version of yaml.v1 ? | 15:49 |
| TheMue | rogpeppe: no, want to start now | 15:50 |
| TheMue | rogpeppe: afaik today the tests are based on yaml strings. so it would be better to let them base on types that are marshalled and unmarshalled? | 15:51 |
| rogpeppe | TheMue: no, you don't need to do that in general | 15:51 |
| rogpeppe | TheMue: i pointed you to a possible solution yesterday | 15:51 |
| TheMue | rogpeppe: have to see if I have a log | 15:52 |
| fwereade_ | jw4, actually, though | 15:54 |
| fwereade_ | jw4, I am wondering about the nolongeravailable thing | 15:54 |
| jw4 | fwereade_: as in what kind of error it should be? | 15:55 |
| fwereade_ | jw4, it feels kinda overspecific -- should we maybe be using NotFound directly there? | 15:55 |
| TheMue | rogpeppe: ah, the YAMLEquals checker, found the log ;) | 15:55 |
| rogpeppe | TheMue: yeah | 15:55 |
| jw4 | fwereade_: that sounds plausible | 15:55 |
| fwereade_ | jw4, it will be all the clearer, I think, when we call it PendingActions | 15:56 |
| fwereade_ | jw4, agree? | 15:56 |
| jw4 | fwereade_: +1 | 15:56 |
| dimitern | sinzui, hey | 15:59 |
| dimitern | sinzui, I'll backport the fix for bug 1394524 into 1.21 as well | 15:59 |
| mup | Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1394524> | 15:59 |
| sinzui | Thank you dimitern | 16:00 |
| dimitern | sinzui, hmm looking at how much 1.21 has changed from 1.22 wrt juju/utils/ it might be safer not to backport perhaps? | 16:04 |
| sinzui | dimitern, I respect your decision, and I am happy to remove the issue from the milestone if you think it is best | 16:05 |
| dimitern | sinzui, juju/utils for 1.21 is more than 10 commits behind master and some interface changes were introduced during some of these | 16:05 |
| dimitern | sinzui, yeah, thanks - I think it's safer | 16:06 |
| sinzui | okay | 16:07 |
| voidspace | dimitern: ping | 16:15 |
| voidspace | dimitern: you still around? | 16:15 |
| dimitern | voidspace, yep | 16:16 |
| natefinch | huzzah | 16:18 |
| natefinch | and the answer is... fucked up .profile | 16:18 |
| natefinch | no idea why that caused the whole "could not switch monitor configuration" error... but there was a little .xsession-errors file in my home directory that said "your .profile is fubared" | 16:19 |
| natefinch | /usr/sbin/lightdm-session: 30: /home/nate/.profile: source: not found | 16:20 |
| natefinch | /usr/sbin/lightdm-session: 32: /home/nate/.profile: function: not found | 16:20 |
| natefinch | /usr/sbin/lightdm-session: 35: /home/nate/.profile: __git_ps1: not found | 16:20 |
| natefinch | /usr/sbin/lightdm-session: 36: /home/nate/.profile: Syntax error: "}" unexpected | 16:20 |
| natefinch | this is what I get for copying a shell script into my .profile | 16:20 |
| wwitzel3 | natefinch: wb :) | 16:21 |
| natefinch | ironcically, while this all happened, my mother called me to ask for help getting malware off her laptop | 16:22 |
| natefinch | one of those "malware masquerading as anti-malware" things | 16:22 |
| jw4 | fwereade_, TheMue LGTM on review 502? | 16:31 |
| TheMue | fwereade_: just seen your all-watchers-in-one-file-statement in jw4's proposal, laughed loud | 16:37 |
| TheMue | jw4: from my side it's ok now as the cards for the missing parts are created. but would like to wait for fwereade_ to check your answers on his review | 16:40 |
| fwereade_ | jw4, if you've done what I suggested and it LGT TheMue I'm happy | 16:42 |
| jw4 | fwereade_ TheMue cool tx | 16:43 |
| jw4 | (yes, I've addressed all comments and issues) | 16:44 |
| === kadams54_ is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54_ | ||
| === kadams54_ is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54_ | ||
| mattyw | night all | 17:54 |
| mgz | cmars: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1368/ plus 1369 plus 1370 | 18:11 |
| * perrito666 is back to the land of the bad but bearable internet | 18:33 | |
| voidspace | g'night all | 18:54 |
| lazyPower | does anyone have a minute to help debug proxy issues with a users juju env? | 19:06 |
| natefinch | lazyPower: you're on the wrong time of day to find people that know about proxies and juju, unfortunately | 19:15 |
| lazyPower | i figured as much - but i think its a config issue fortunately | 19:15 |
| lazyPower | not something juju isn't respecting | 19:15 |
| lazyPower | thanks for the reply natefinch | 19:16 |
| natefinch | lazyPower: wish I had a better reply. | 19:16 |
| perrito666 | wiii, I have an upgrade resistent restore, I am a happy man | 19:21 |
| perrito666 | :D | 19:21 |
| natefinch | yay | 19:22 |
| jw4 | fwereade_: don't know if the new name I picked is the best, but it's clearer : http://reviews.vapour.ws/r/508/ | 19:26 |
| perrito666 | go fmt not taking a list of paths as parameter makes me sad | 19:30 |
| natefinch | you can do go fmt ./... | 19:31 |
| natefinch | (or other package wildcards) | 19:32 |
| perrito666 | natefinch: that I did not know | 19:32 |
| natefinch | note, that's go fmt not gofmt | 19:32 |
| perrito666 | natefinch: http://reviews.vapour.ws/r/298/ | 19:33 |
| natefinch | perrito666: also, you can give multiple paths to gofmt gofmt *.go foo/*.go seems to work, for example | 19:35 |
| natefinch | (note that one is gofmt, not go fmt | 19:35 |
| perrito666 | natefinch: go fmt, which I prefer does not like multiple paths | 19:35 |
| === kadams54 is now known as kadams54-away | ||
| perrito666 | well, being blessed as I am with having no power and using internet from a cellphone tethering I think I might call a stop here and return later | 19:56 |
| perrito666 | wow, reviewboard sucks badly in bad internet situations | 19:56 |
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| natefinch | not sure if waigani is trolling or actually means it | 20:29 |
| perrito666 | natefinch: cmon it wont affect you unless you decide to code in an old english typeset | 20:31 |
| perrito666 | :p | 20:31 |
| waigani | natefinch: I put it to the vote, and this was the result. It's a stupid minor point and the best way to avoid ongoing time loss on the issue is to reach a decision and get on with coding. | 20:33 |
| natefinch | waigani: isn't the best way to avoid wasting time on it.... to not waste time on it? | 20:35 |
| waigani | natefinch: isn't that what we are doing now? | 20:36 |
| jw4 | natefinch: or to make a decision and not revisit it? | 20:36 |
| waigani | +1 | 20:36 |
| natefinch | waigani: my point is, we're adding something else we have to check for in a code review that offers ZERO benefit to the quality of the code. | 20:36 |
| natefinch | or to the quality of the comments | 20:36 |
| jw4 | natefinch: except that new folks not party to this debate may raise it again unless it's spelled out | 20:37 |
| katco | is this about the one-space after periods? | 20:37 |
| jw4 | katco: yep | 20:37 |
| katco | why is this something we're even discussing? | 20:37 |
| natefinch | I have never (previously) in my 15 years of development experience had anyone ask about number of spaces after a period. | 20:38 |
| waigani | natefinch: sigh. The reason I put it to the vote is because there were debates about it, that were distracting. The solution to such debates is to make a decision and not revisit it (without good reason) | 20:38 |
| waigani | that is the role of the style guide I think | 20:38 |
| katco | i'm with nate on this... my solution would be to tell the person bringing this up that there are more important things to discuss | 20:39 |
| katco | why are we reviewing the # spaces in a comment? | 20:39 |
| mgz | katco: because it's fun! | 20:39 |
| jw4 | katco: except you'd have to say it again everytime someone who didn't know asked | 20:39 |
| waigani | OMG | 20:39 |
| perrito666 | yay bikeshedding | 20:40 |
| katco | jw4: i don't know... i've never seen this ever come up either | 20:40 |
| natefinch | if we want to end the discussion, state in the style guide that we don't care | 20:40 |
| waigani | the intention was to put the issue to bed and move on - that is what I'm doing now. If it does not get a ship it does not land. I'm not fussed. | 20:40 |
| jw4 | katco: I know, but Go is the first language I've used that has one-true-way of formatting code too | 20:40 |
| jw4 | katco: for this exact reason I believe | 20:41 |
| katco | jw4: yeah, but that's to handle major stylistic differences in actual code | 20:41 |
| katco | jw4: this is... a space... b/t sentences | 20:41 |
| perrito666 | jw4: all languages have one true way of formating code... mine | 20:41 |
| katco | jw4: writers can't even agree on this lol | 20:41 |
| jw4 | katco: :) | 20:41 |
| jw4 | I for one favour one sentence per line | 20:42 |
| katco | natefinch: i really like that stance. "we don't care" | 20:42 |
| katco | natefinch: removes the additional review point, and puts the issue to bed as well | 20:42 |
| natefinch | we don't even have style guides for things that actually kinda sorta matter, like formatting long lines of function declarations | 20:42 |
| jw4 | natefinch: I missed that - I'm okay with that stance too | 20:42 |
| davecheney | "implementation defined" | 20:42 |
| katco | natefinch: +1 +1 +1 | 20:42 |
| natefinch | we just said "as long as it passes gofmt, it's ok" | 20:42 |
| katco | waigani: i'm sorry if i'm causing you some pain. this isn't directed at you at all | 20:43 |
| katco | waigani: i was just very surprised to see this | 20:43 |
| jw4 | katco, natefinch my main support of this is to address it so that newcomers know what the stance is. "We don't care" is great if it's in the docs. (IMVHO) | 20:44 |
| natefinch | let's make it a tab after a space, that way the spacing is customizable to everyone's own tastes ;) | 20:45 |
| natefinch | sorry, tab after a period | 20:45 |
| jw4 | natefinch: oh no you didn't | 20:46 |
| jw4 | :) | 20:46 |
| natefinch | lol | 20:46 |
| perrito666 | I have never seen someone dont care so strongly about something | 20:46 |
| jw4 | perrito666: :) | 20:46 |
| katco | tabs are better than spaces, but only if you're using the best editor: emacs | 20:46 |
| katco | ^ the most contentious sentence ever written | 20:46 |
| jw4 | katco: oh no you didn't | 20:46 |
| perrito666 | even more this seems to be the longest not argument about something I have ever been | 20:46 |
| katco | perrito666: i respectfully hear your viewpoint! | 20:47 |
| natefinch | for the record, if we have to pick one, I do prefer 2 spaces after a period. But I'd much rather just let everyone do whatever they want. | 20:48 |
| perrito666 | oh, no, I feel offended, I demand that you ignore me in the spirit of this conversation amd I will definitely not say that using vim I dont care because I can easily turn one into the other | 20:48 |
| jw4 | natefinch: I think the ship sailed | 20:48 |
| katco | natefinch: i believe in the annals of typography, one space is actually correct | 20:48 |
| perrito666 | natefinch: 2 spaces? who are you, guttemberg= | 20:48 |
| perrito666 | ? | 20:48 |
| katco | but i guarantee you i'm not going to check for this lol | 20:49 |
| perrito666 | katco: lets ignore typography in favor of proper language and just read thoroughly the comment as we should | 20:50 |
| perrito666 | said by the guy that sucks at english <-- | 20:50 |
| katco | haha | 20:50 |
| katco | i've found your english to be quite good perrito666 | 20:50 |
| katco | better than some americans | 20:50 |
| perrito666 | katco: heh, most of the reviews I get are people correcting my grammar | 20:51 |
| perrito666 | also my english is like a health bar in videogames, certain things can make me loose it | 20:51 |
| katco | well, you know... go is a unicode language. write in Portuguese :) | 20:51 |
| jw4 | perrito666: "most of the reviews I get are *from* people correcting my grammar" | 20:51 |
| perrito666 | katco: my kb lacks a few chars for it I believe | 20:52 |
| katco | perrito666: i'm actually afraid of that happening. right now code is wonderfully unified with latin characters | 20:52 |
| katco | i read code this japanese guy wrote all the time. in the future, maybe it's written in hirigana | 20:53 |
| katco | and that avenue will be closed to me | 20:53 |
| perrito666 | katco: here, code in spanish is is usually considered bad | 20:53 |
| katco | i mean i know it's a bit ethnocentric, but it is nice that anyone anywhere can read any code | 20:53 |
| perrito666 | katco: no offense intended, we consider English to be a simple, undecorated and sufficiently small language to be practical in technical things | 20:54 |
| natefinch | I think it's pretty great that people in other languages can write code that uses their own alphabet. | 20:54 |
| natefinch | I do find it quite amusing that the standard time format in Go is in US month/day/year order, though | 20:54 |
| katco | perrito666: none taken... wow is that really true? | 20:54 |
| katco | perrito666: funny, some people say that same thing about Go :) | 20:55 |
| perrito666 | katco: well spanish has accents and this -> ñ and º for degrees and many things like the fact that words have gender | 20:55 |
| perrito666 | which makes a pain to code and comment in it | 20:56 |
| katco | i see | 20:56 |
| perrito666 | and also, you most likely never thought of this because you speak english but programming languages are also in english :p | 20:56 |
| katco | natefinch: that is odd | 20:56 |
| perrito666 | which makes constructions in prog lang+my lang very ugly | 20:56 |
| katco | it will be interesting to see what happens as time goes on | 20:57 |
| natefinch | katco: rob pike apologized for it, he just wasn't thinking. The canonical date is 01/02 3:45pm 2006 tz +7 | 20:57 |
| perrito666 | I spent some time reading code in spanish, and the SQL sentences where hilarious | 20:57 |
| natefinch | (that's jan 2) | 20:58 |
| katco | natefinch: i kind of like how they implemented the parsing stuff, but i wish they would have picked a date that is easier to remember | 20:58 |
| katco | natefinch: oh god | 20:58 |
| perrito666 | Is there any rationale why you ppl use mm/dd/yy? | 20:58 |
| katco | natefinch: and as i say that i just now realize it's 1-8 | 20:58 |
| katco | ^7 | 20:58 |
| natefinch | yep | 20:58 |
| katco | yuk yuk | 20:59 |
| katco | good job katherine | 20:59 |
| katco | perrito666: i don't know that there is... it's just what i grew up with | 20:59 |
| natefinch | I like the idea, but the actual date is hard to remember unless you know the order in which the timestamp parts are put in the canonical string | 20:59 |
| katco | i prefer coarse to fine, e.g.: yyyy-mm-dd | 20:59 |
| natefinch | katco: absolutely | 20:59 |
| jw4 | katco: +1 | 20:59 |
| katco | it's just like numbers... i don't know why we don't do that | 21:00 |
| katco | i think that is the ISO standard though isn't it? | 21:00 |
| natefinch | there's a lot of ISO standards for time :) | 21:00 |
| jw4 | katco: I belive so. I try to always use that format : writing cheques, notes, etc. | 21:01 |
| natefinch | a better time format might be 9999 08 07 06:54pm tz +3 | 21:01 |
| katco | jw4: i admit i use what i grew up with, unless i'm producing documents for the interwebs | 21:01 |
| natefinch | for august 7th, 9999 | 21:02 |
| jw4 | katco: I grew up with dd/mm/yyyy and I still have to make a concious choice every time I write a date | 21:02 |
| natefinch | I just noticed I can (possibly?) delete waigani's review request on reviewboard. I guess there's no permissions for that kind of thing? | 21:03 |
| jw4 | natefinch: what about 9988 07 06 etc. | 21:03 |
| natefinch | jw4: don't need it, you only use the amount of resolution in the year as you get, so 99 would be a 2 year date | 21:03 |
| katco | natefinch: review by fiat? | 21:03 |
| perrito666 | ericsnow: ping? alive? | 21:04 |
| katco | natefinch: "i DIS-AGREE!" (delete) | 21:04 |
| natefinch | katco: I wouldn't, I just thought it was amusing that it was possible :) | 21:04 |
| jw4 | natefinch: interesting | 21:04 |
| natefinch | haha, I AM willing to change the title of the review, though | 21:05 |
| alexisb | thumper, ping | 21:05 |
| thumper | alexisb: hey | 21:05 |
| alexisb | hey there thumper I have a couple of things I need to discuss with you | 21:05 |
| alexisb | can you spare me a few minutes | 21:06 |
| alexisb | ? | 21:06 |
| thumper | yep | 21:06 |
| alexisb | ok, let me find a corner | 21:06 |
| alexisb | ok thumper our 1x1 hangout | 21:07 |
| thumper | ok | 21:07 |
| natefinch | sinzui: slight typo in that email subject ;) | 21:10 |
| sinzui | yeah, we well need a few years to get to that number :) | 21:11 |
| jw4 | davecheney: do you have any more details on how you're reproducing bug 1394066 ? | 21:30 |
| mup | Bug #1394066: FAIL: action_test.go:254: ActionSuite.TestActionsWatcherEmitsInitialChanges <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1394066> | 21:30 |
| katco | if api/* is finding my facade, but not my method in apiserver/*, what have i most likely overlooked? | 21:57 |
| wallyworld | thumper: can we delay by 1 hr today? I have a meeting clash | 22:02 |
| thumper | wallyworld: sure | 22:02 |
| wallyworld | \o/ | 22:02 |
| === arosales__ is now known as arosales | ||
| thumper | oh fuck... | 22:22 |
| thumper | fuckity fuck fuck | 22:22 |
| * thumper head desks | 22:22 | |
| jw4 | mooommm; thumper is doing it again | 22:22 |
| thumper | ah, no, panic over | 22:24 |
| jw4 | haha | 22:24 |
| thumper | i think we're still good | 22:24 |
| * thumper goes back to the 1.22 upgrade malarky | 22:24 | |
| * fwereade_ driveby: any less than 7 spaces after a period is unacceptable | 22:25 | |
| jw4 | fwereade_: smart alec | 22:25 |
| menn0 | fwereade_: but surely it's 8.5 if you're using a comic sans font? ;-p | 22:28 |
| benji | fwereade_: you mean "fewer"; spaces are countable | 22:29 |
| fwereade_ | menn0, comic sans users have to use at least 37 as a penance | 22:29 |
| menn0 | thumper: are all the docstrings in factory.go wrong? they all say, "If more than one params struct is passed to the function, it panics." | 22:29 |
| * fwereade_ fails at pedantry forever, tips hat to benji | 22:29 | |
| benji | :) | 22:30 |
| thumper | menn0: yeah | 22:30 |
| thumper | menn0: obviously the person that changed the factory failed to update the doc strings | 22:30 |
| menn0 | thumper: but there's no way to pass in more param structs | 22:30 |
| menn0 | thumper: is that left over from a previous implementation? | 22:30 |
| thumper | yep | 22:30 |
| menn0 | thumper: k, i'll fix. i'm in there anyway | 22:32 |
| thumper | oh god... | 22:34 |
| * thumper just had a horrible thought | 22:35 | |
| * thumper tries to work out if he cares | 22:35 | |
| thumper | shit shit shit | 22:36 |
| thumper | bugger | 22:36 |
| thumper | balls | 22:36 |
| * thumper pretends the problem doesn't exist | 22:36 | |
| * jw4 can't help but be intrigued when thumper goes off | 22:37 | |
| menn0 | thumper: that works... sometimes | 22:37 |
| jw4 | it's like a shiny object or a squirrel to me | 22:37 |
| katco | asking again in the hopes someone can help me out: if api/* is finding my facade, but not my method in apiserver/*, what have i most likely overlooked? | 22:48 |
| katco | fwereade_: ^ ? | 22:48 |
| thumper | katco: is it a new end point? | 22:48 |
| katco | thumper: it is | 22:48 |
| thumper | then you have probably forgotten to hook up the end point with the root | 22:48 |
| katco | thumper: i've been using the usermanager as a guide... can you point me to a line of code maybe? | 22:49 |
| * thumper goes to look | 22:49 | |
| katco | thumper: ty sir. hopefully i am providing a distraction from what sounds like fun problems :) | 22:50 |
| menn0 | thumper, waigani: here's Factory.MakeEnvironment() https://github.com/juju/juju/pull/1201 | 22:50 |
| fwereade_ | katco, thumper: if you're seeing the facade but not the method, failing to register seems unlikely, and I don't immediately have good ideas... mm, versioning maybe? | 22:53 |
| katco | fwereade_: i registered as 0 | 22:54 |
| * thumper goes back to his horrible problem | 22:54 | |
| katco | thumper: haha i'm sorry. ty so much for responding | 22:54 |
| katco | fwereade_: common.RegisterStandardFacade( | 22:54 |
| katco | FacadeName, | 22:54 |
| katco | 0, | 22:54 |
| katco | NewLeadershipServiceFn(leaderMgr), | 22:54 |
| katco | ) | 22:54 |
| katco | where FacadeName is "LeadershipService" | 22:54 |
| ericsnow | perrito666: you still looking for me? | 22:55 |
| katco | fwereade_: the only thing i could think of is i am returning an interface, so maybe the reflection is failing | 22:55 |
| katco | fwereade_: so i returned a pointer to the actual type, and that didn't work | 22:55 |
| katco | fwereade_: but the type is not exposed | 22:56 |
| katco | fwereade_: not sure if that matters | 22:56 |
| fwereade_ | katco, I don't *think* the type matters so long as the methods are exposed | 22:56 |
| katco | fwereade_: they're there on the interface alright | 22:57 |
| perrito666 | ericsnow: nope, solved it | 22:57 |
| perrito666 | :D | 22:58 |
| katco | fwereade_: i should have mentioned this; i tracked the failure to rpc/rpcreflect/type.go Method(...) | 22:58 |
| ericsnow | \o/ | 22:58 |
| katco | fwereade_: line 180 | 22:58 |
| waigani | menn0: done | 22:59 |
| * fwereade_ scratches head expressively at katco | 23:00 | |
| fwereade_ | katco, hold on a moment | 23:00 |
| menn0 | waigani: thanks | 23:00 |
| fwereade_ | katco, I'm unconvinced that we need a new facade for what you're doing -- but then I don't *actually* know *exactly* what you're doing | 23:01 |
| fwereade_ | katco, oh wait scratch that | 23:01 |
| fwereade_ | katco, we agreed leadership could & shoudl be handled by a worker that's not the uniter, hence a separate facade | 23:01 |
| fwereade_ | katco, ignore me | 23:01 |
| * katco always prefers to have hard conversations when it's late where fwereade_ is | 23:01 | |
| katco | ;) | 23:01 |
| fwereade_ | in vino veritas, or sometimes just nonsense | 23:03 |
| thumper | ah ffs | 23:03 |
| katco | haha | 23:03 |
| thumper | fwereade_: is the translation of that "in wine we find the truth?" | 23:05 |
| fwereade_ | thumper, yeah :) | 23:06 |
| thumper | I agree | 23:06 |
| thumper | bit early for wine here | 23:06 |
| thumper | being just after noon | 23:06 |
| thumper | but I'm tempted | 23:06 |
| wallyworld | thumper: if you get a moment, you you please look at https://code.launchpad.net/~wallyworld/golxc/support-cmd-env/+merge/242438 | 23:09 |
| thumper | wallyworld: kinda deep in it right now | 23:09 |
| wallyworld | np | 23:10 |
| katco | fwereade_: ahoy... all the functions live in the "discarded" array | 23:10 |
| fwereade_ | katco, ahhh | 23:10 |
| katco | fwereade_: they feel so abandoned :( | 23:10 |
| fwereade_ | katco, you will have failed to have "appropriate" signatures | 23:10 |
| katco | fwereade_: yeah well the troublemakers are always the interesting ones | 23:10 |
| katco | fwereade_: how do i know what's appropriate? | 23:10 |
| fwereade_ | katco, I feel somewhat justified in my ages-ago belief that this would cause someone trouble sometime | 23:11 |
| fwereade_ | katco, looking, oping I can remember | 23:11 |
| katco | fwereade_: i think in rpc/rpcreflect/type.go newMethod(...) there lies a truth | 23:12 |
| fwereade_ | katco, look at newMethod in rpcreflect/type.go I thinl? | 23:12 |
| katco | first! | 23:12 |
| fwereade_ | katco, jinx | 23:12 |
| katco | first again! | 23:12 |
| * fwereade_ is evidently outclassed | 23:12 | |
| katco | ahaha | 23:12 |
| katco | fwereade_: i will pursue this. thank you, as always, for your support :) | 23:13 |
| fwereade_ | katco, cheers :) | 23:14 |
| katco | fwereade_: do you mind if when i find out what is wrong i add some helpful error message? | 23:14 |
| fwereade_ | katco, go for it | 23:14 |
| katco | fwereade_: it would appear i do not fit the template for # of return values or some such thing | 23:15 |
| * fwereade_ looks at the code he was writing before he started the evening, remembers he decided to change the signature of an abundantly-used method, grumbles quietly to himself | 23:15 | |
| fwereade_ | katco, it's either (result, err) or (err) IIRC | 23:16 |
| fwereade_ | katco, I think it would have been nicer if it'd been (err) only tbh, at least that would have matched the golang rpc package | 23:16 |
| * fwereade_ shrugs, resolves not to whine further | 23:16 | |
| waigani | menn0: ship it | 23:17 |
| katco | fwereade_: gosh... is it because i'm using *params.Error, and not *error? | 23:18 |
| fwereade_ | katco, ha | 23:18 |
| fwereade_ | katco, most likley | 23:18 |
| katco | fwereade_: so now i am thoroughly confused. i thought i was supposed to use params.Error b/c that's our over-the-wire protocol? | 23:18 |
| fwereade_ | katco, the params.Errors should probably be in a slice in the result somewhere | 23:18 |
| katco | fwereade_: aha | 23:19 |
| fwereade_ | katco, errors out of the actual methods are OMG-EVERYTHING-IS-BROKEN errors | 23:19 |
| katco | fwereade_: right | 23:19 |
| katco | fwereade_: thought we were still supposed to use params.Error for some reason | 23:19 |
| fwereade_ | katco, I *think* that's handled elsewhere -- it's the distinction between a this-element-is-problematic (where we expect you to have created a sane result) and this-whole-call-is-broken where the transport does something about it | 23:21 |
| * fwereade_ waves hands vaguely, tries to look wise | 23:21 | |
| katco | fwereade_: mmm yes, i see, i see. i do not comprehend your brilliance of course, but i think i can fix this. | 23:21 |
| thumper | menn0: FWIW the jujud upgrade test starts with a version of 1.16.something and upgrades to current | 23:23 |
| thumper | menn0: and makes sure everything passes | 23:23 |
| thumper | menn0: so it is testing full upgrades | 23:24 |
| thumper | and jumping versions | 23:24 |
| menn0 | thumper: that sounds good | 23:25 |
| menn0 | thumper: given that Factory is your baby, can you PTAL at http://reviews.vapour.ws/r/511/? waigani has already given it the ok. | 23:25 |
| perrito666 | ericsnow: if you have some time, many of your changes just pushed to http://reviews.vapour.ws/r/298 | 23:25 |
| thumper | menn0: ok | 23:25 |
| perrito666 | ericsnow: make notes for all you feel needs moving so we do it after this lands | 23:26 |
| * thumper bangs and the desk and leaves the office for a bit | 23:30 | |
| menn0 | thumper: before you go | 23:31 |
| mgz | bangs hard enough that the desk leaves the office? | 23:32 |
| mgz | that's some serious table flip | 23:32 |
| menn0 | thumper: never mind | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!