[05:21] bcsaller, for tomorrow.. could use a review on the annotation support for persistent positions https://codereview.appspot.com/6936063/ [12:48] hi frankban [12:53] morning bac [12:54] morning frankban. can we have a quick chat to discuss your branch and getting mine out of your way? [12:56] bac: sure [12:56] juju-ui then [12:56] frankban: joining [13:03] bac: bzr+ssh://bazaar.launchpad.net/~frankban/charms/precise/juju-gui/bug-1088618-serve-releases/ [13:04] bac: https://code.launchpad.net/~frankban/charms/precise/juju-gui/bug-1088618-serve-releases [13:05] frankban, bac, I hope I'm not making unnecessary problems. Happy to do whatever you think might help [13:06] gary_poster: join G+ juju-ui [13:06] please [13:06] :-) [13:23] hey benji. I wanted to make sure we were on the same page for your new card. you have a second for juju-ui hangout? [13:23] gary_poster: sure, let me plug up my camera [13:23] cool thanks [13:36] goodspud, hey. any timeline for getting the designer assets (hopefully largely CSS) for the login page? We don't have to have it this week, but it would be convenient if we had it today or tomorrow morning at the latest. [13:40] hazmat, just to let you know so you are not surprised: you made a "read-only mode" card in the primary story tasks. that card/bug already exists in the secondary story. it is in the secondary story because the refactoring is supposed to assist in that card, and so it is one of the user-facing improvements I associated with the refactoring. shared position is also down in the secondary story for the same logic. [13:40] gary_poster - quite conveniently I've just been handed them [13:40] Therefore I deleted the primary lane's version [13:40] goodspud, yay :-) [13:41] gary_poster, just in the process of uploading.... please hold caller [13:43] :-) goodspud, benji is working on this. As a heads up, I encouraged him to divide this up into a first cut effort that incorporated the functionality plus the low-hanging fruit of the design in one pass, and then a full-on design match in a second pass. (Someone else might even do the second pass.) [13:47] gary_poster, benji - all the assets and guides are here: https://drive.google.com/a/canonical.com/#folders/0B1IM--9A1RkTd21pN2RxUHU3WEU [13:48] I'm about to leave the office for the afternoon but buzz Alejandra if you need any help. Greg (designer) isn't set up on IRC or email yet so best to go through her [13:49] ack goodspud & thanks. good luck at the dr [13:49] goodspud: thanks [13:50] gary_poster, cool, thanks [13:51] the kanban search is kind of cool [13:51] the pan to card effect [13:51] yeah [13:52] https://docs.google.com/a/canonical.com/file/d/0B1IM--9A1RkTRmw5NVBxeUgwZzA/edit looks liek an old-style macbook pro trackpad, upsidedown. [13:52] if anyone is up for a pyjuju review... this is the annotation support for persistent positions and landscape.. https://codereview.appspot.com/6936063/ [13:53] I'll look at it, at least for a non-pyjuju-reviewer review [13:53] gary_poster, on the subject of kanban org.. in the primary story we have (proto, code, & review) in the secondary (proto, code, review code).. are those meant to be the same? [13:54] hazmat, yeah [13:54] changed hazmat, thanks [13:55] np [13:56] i'm going to be out for our daily today to attend an omnibus review, for my next gui task i'm looking at working on read-only support [13:56] hazmat in GUI or in rapi? That's only in GUI, do I remember correctly? [13:58] In GUI, the read-only support would conflict with the refactoring work; that will either be largely done by Jan 3 (per blog post definitions of this week's goals) or pushed aside for later if we have time in the future [13:58] gary_poster, it shouldn't conflict [13:58] you would only be doing env changes? [13:58] gary_poster, i'll be adding another store impl [13:58] s/store/env [13:58] right, ok cool [13:58] thanks [13:59] gary_poster: i've updated my branch and just tested it. the new nginx upstart config seems to have fixed the issue i talked about. [13:59] yay, bac! Want an official approve from me? [13:59] gary_poster, re rapi support, long term vision would be the cli uses rapi too, so read only support there would still be advisory based on the gui [13:59] switching the conn to read only mode [14:00] i changed the juju-gui-branch out from under it and also switch from production to staging. all worked. this isn't to be confused with thorough testing, of course. [14:00] gary_poster: yes but waiting for a second from frankban [14:00] bac, cool, real config support! [14:00] i think "real" needs scare quotes. it is a good start. [14:05] oh, hazmat, I had a question about config-changed. I saw confirmation from you somewher on the web that config-changed is called after install and before start [14:06] if that's the case [14:06] then in the common case install can be very very small, I would think [14:06] because there's no need to dupe work in install and config [14:06] More controversially, [14:07] it also can replace start in some cases [14:07] because that's in fact the simple way to implement it if config-changed has to restart [14:07] a more sophisticated config-changed in that case woudl notice that nothing had been started yet [14:07] and not restart [14:08] but the super simple implementation is to just start/restart always [14:08] which means that in that case start is redendant [14:08] redundant [14:08] hazmat, could you confirm or correct the above? [14:13] gary_poster, confirmed config-changed called b4 start [14:13] hook logic ordering is whatever make sense to the charm [14:14] many charms just have a single file symlinked to hook names so they can share logic easily [14:15] so what I said makes sense to you, but is not the only way to look at it, is what you are saying? [14:20] bac: is your branch ready for review? [14:26] hazmat: ping; I am trying to get the latest version of rapi-rollup to send "state": "login-required" and I am not having any luck [14:29] benji, poking [14:29] benji, using improv? [14:31] benji, atm login isn't required [14:31] hazmat, out of curiosity, if we were doing it within the charm, how would you turn login on? [14:31] /usr/bin/python -m juju.agents.api --help shows --secure [14:31] since it would break all the extant without gui support, what's there is to support implementing the gui bits [14:32] gary_poster, there will be a separate branch to require login for all rapi access [14:32] gary_poster, secure is for tls [14:32] hazmat I thought we had a switch to turn on the login so we could test? [14:33] gary_poster, you can still login now [14:33] hazmat, oh, but there is no way to turn on a challenge as in line 7 of http://paste.ubuntu.com/1397723/ [14:33] ? [14:33] I was asking benji to make the GUI able to handle either the challenge [14:34] or not the challenge [14:34] which ought to be no problem [14:34] gary_poster, no... but the gui also needs to keep track of a user state [14:34] AFAIK :-) [14:34] meeting.. [14:34] ok [14:35] benji, I'm not sure id this is what hazmat means by user state, but one other aspect of this is that we want to stash the authentication credentials in memory [14:35] ok, I can fake it for the time being [14:35] that way, if the socket dies [14:35] we can reconnect [14:35] makes sense [14:35] (but if the user refreshes the browser window, they have to reauthenticate) [14:36] gary_poster, auth creds in browser is what i meant by user state [14:36] gary_poster, session storage [14:36] or not... [14:36] hazmat, we said session storage then you changed your mind in my memory [14:37] browser in memory makes sense to me fwiw [14:37] gary_poster, yeah.. i recall as well. thinking now it would be nice to give a voice to ux.. unless security is paramount [14:37] hazmat, I think we can have rapi have a switch turn on login challenge. let's talk when you are out of meeting [14:37] agree on ux [14:38] though a reasonable and easy first cut is browser in-memory [14:38] gary_poster, i'd rather avoid a switch for something not meant to be configurable... [14:38] but let's talk in 1hr [14:38] hazmat, right it would be for the transition period [14:38] ok cool [14:39] OIC [14:39] So benji, I guess hazmat is saying that you can just always show the challenge [14:39] it doesn't do anything really now [14:39] but that's the transition story [14:40] that's fine too [14:40] make sense benji? [14:40] so we will always prompt for login but only relay it to the server if it asks? [14:41] will we land it that way (without validating that it actually works against the real server)? [14:43] benji, no the server accepts the login now is what Kapil is saying [14:43] benji so after line 7 of http://paste.ubuntu.com/1397723/ [14:43] I mean [14:44] line 7 would not have a challenge [14:44] but you would send line 11 anyway [14:44] expect lines 15-17 [14:44] or 21 [14:44] benji, I'm sure you will verify experimentally, but that's my understanding [14:45] oh, it accepts it but it does not challenge? so my branch would always prompt for credentials but only send them if... what? [14:45] you'd always send them after the greeting [14:45] or send them and ignore any "what you talkin' about Willis" errors? [14:45] you'd treat the greeting response as if it had a challenge--as if it looked like line 7 [14:46] everything else (except for the rejection in line 28) should behave as described [14:46] AIUI [14:47] If I'm correct, there should be no "what you talkin' 'bout Willis" errors when you send line 11, benji [14:47] if there are, we'll need to circle back around with Kapil [14:47] is that clear? [14:47] gary_poster: even if the server does not understand credentials? or are we ignoring non-credential-understanding backends? [14:47] yes benji [14:48] we control that particular horizontal/vertical [14:48] we are ignoring non-credential-understanding backends [14:48] k [14:48] * gary_poster withholds backend jokes [14:49] heh [14:50] hey bcsaller, sorry. are you already in another hangout or do you want to join me in our calendar hangout? [14:50] gary_poster, I have to leave in ten minutes, I likely won't be back in time for the daily call, only shortly thereafter [14:50] ok teknico. can you give me status on your branch? [14:51] gary_poster, I gathered together the commands and config changes needed, am now tracking bac's branch to put my changes in [14:52] teknico, oh! you have to modify charm too, of course. :-/ [14:52] gary_poster, yep [14:53] gary_poster: mine is ready to land pending a second review [14:53] teknico, if bac's branch lands in the next hour or so will you be able to land soon after, or will integration be more involved that that? [14:53] bac, other than mine? [14:53] gary_poster: yes. two required, right [14:53] y [14:54] bac, so do you know of any more issues lurking in your branch, or is everything hunky dory as far as you know? You expressed reservations earlier today [14:55] gary_poster: i think it is good [14:55] gary_poster, I hope to be able to propose today, yes [14:55] teknico have you followed bac's branch closely, enough to give it a fast review before you leave, or should we just wait for frankban's return? [14:55] teknico, great thanks [14:55] gary_poster, yes, I was trying to do that [14:56] bac, is there a rietveld proposal, or just lp? [14:56] teknico, and I am keeping you from it. :-P sorry. Just lp teknico [14:56] just lp teknico [14:56] lbox blew up on me when authenticating to google [14:56] ok, thanks [14:57] gary_poster, bac: I am here [14:58] hey frankban, we've got a second review from teknico, thank you. You can keep on doing good stuff on your own branch :-) [14:59] gary_poster, frankban, well, mine is more like a half review, though :-) [14:59] and now I gotta go [14:59] ok teknico see you in a bit [15:02] bac, I think it's two reviews. ;-) [15:03] gary_poster: yep. landing now. [15:03] thanks bac [15:03] bcsaller, ping [15:03] gary_poster: hey [15:04] oh hey, there you are bcsaller. I was running late, then couldn't connect with you earlier. Meet briefly in our usual hangout, or are you already somewhere else? [15:05] gary_poster: usual is fine, grabbing the link [15:05] cool [15:08] gary_poster, hazmat: i just pushed my branch. unfortunately, since lbox is broken for me atm i had to do it manually and i inadvertantly polluted the revision history by including all of my development revisions. [15:09] :-/ [15:14] bac, I don't know how to do that surgery, butr hazmat does. mm, I think you can uncommit bac [15:14] bac, try that: get a checkout of the trunk [15:14] uncommit [15:14] gary_poster: i think i could fix it locally and do an --overwrite [15:14] bac, if you have a plan then go for it [15:15] all ears if there is a better way [15:15] bac, fwiw, I always do manual merges with a checkout. That always seems to be more obvious to me [15:15] Maybe just me though [15:16] gary_poster: yes, it is. but i was lulled by lbox and then when it failed i messed up [15:16] bac, cool. but anyway, it is worth fixing, and it soulds like you have a reasonable plan for doing so, so go for it [15:16] and let us know when you are done :-) [15:16] bac note that you may need to fix up staging [15:17] uistage [15:17] manually [15:17] ok [15:22] gary_poster: my plan won't work as i'd merged from trunk last night and those revisions that it pulled in are not easily recovered as discrete checkins [15:22] bac my plan was this: [15:22] get checkout [15:22] uncommit until we are where we were before you pushed [15:23] merge your branch [15:23] would that work? [15:23] no, #2 is the problem since one of my revisions is a merge from trunk. it collapsed several revisions [15:24] you can see it here: http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/changes [15:24] at r 20 [15:24] right [15:24] um [15:26] bac, I have trunk as of r15, but lbox messages are not there for r 14 and r15 [15:27] frankban do you have a pristine charm trunk hanging around on your machine anywhere by chance? [15:28] gary_poster: yes [15:28] bac bcsaller benji frankban hazmat Makyo teknico (not here): call in 2 [15:28] ok, I made it :-) [15:28] gary_poster: last revision: 15: Gary Poster 2012-12-17 [merge] Move markdown files to .md extension [15:29] frankban, yeah that's it, I think. bac, frankban has pristine charm trunk. Could he push --overwrite to bzr+ssh://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/ and get us back to a good place? [15:29] gary_poster: yes, i think so [15:30] bac, gary_poster, trying: bzr push --overwrite bzr+ssh://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/ [15:31] bac, frankban has fixed the world [15:31] http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/changes [15:32] benji, hazmat starting without you [15:33] http://jujucharms.com/~juju-gui/precise/juju-gui [15:35] bcsaller: where is the lbox auth file? [15:35] bac: I think its .lpad.auth or similar, checking [15:35] bac: ~/.lpad_oauth [15:36] bcsaller: hmm, don't have one of those [15:42] gary_poster: my apologies for missing the meeting; I really wish my sound worked when not plugged in [16:09] s'ok benji. if it happens again, try an alarm :-) [16:44] hazmat, I did a two stage review of https://codereview.appspot.com/6936063/but am done. I saw at least one thing you might want to address, but everything I wrote is just for your consideration, since I don't know all the details. [16:45] gary_poster, thanks, thats awesome.. naming is hard :-) [16:45] :-) [16:45] gary_poster, i went with add because its clearly cumulative.. while set might be taken for an equality/total value [16:46] * hazmat heads to reitveld to respond [16:46] mm, I see what you mean :-/ [16:50] gary_poster, s/(add|set)/update ? [16:50] update_annotations...hazmat I like it better than add, but I think it falls into the same trap you mentioned for set: it is not clear that the annotations are merged [16:52] true though update tends to imply a merge to existing more than set [16:53] hazmat, I think it is an improvement. like you said, naming is hard [17:06] hi frankban, want to pair in a little while? [17:06] bac, sure [17:06] frankban: ok, i'll ping you in a few minutes [17:17] gary_poster: it seems that "make distfile" produces a tarball containing the "build" dir but not the "build-prod" and "build-debug" ones (which, AFAICT, are required by the charm) [17:18] frankban: i started a hangout and invited you [17:19] bac: joining [17:43] bac, just noticed your comment from earlier [17:43] re history.. eek [17:43] hazmat: it is cleaned now [17:43] bac, cool [17:44] bac, is that possible without an push --overwrite? [17:44] bac, just ping me when your done w/ frankban .. i've got some idle curiosity about it [17:45] gary_poster, benji did you want to discuss login challenges? [17:50] hazmat: I think I have a handle on things now. [17:51] benji, cool [17:52] benji, i was figuring the app needs a user object if it doesn't its doing login form, and retaining the creds, and using them on the conn, on a reconnect, it can just reauth with those creds on challenge [17:53] the reauth bit might need another branch after login-required lands in rapi [17:53] although possibly hanging off the reconnect logic callback in lib/reconnecting-ws.js [17:53] at the moment I don't have a distinct user object, but am retaining the creds so they can be resubmitted [17:53] explicit seems nicer though [17:53] benji, sounds good [18:02] hi hazmat [18:03] bac, greetings.. so this was an accidental push instead of merge that augmented the trunk history with your branch commits? [18:04] hazmat: yes, since lbox was broken for me i accidentally did a push from my dev branch. [18:04] bac, what went wrong with lbox? [18:04] hazmat: i've moved a vm to a new computer and here lbox throws exceptions when trying to authenticate with google [18:05] anyway, had i been working manually i would've merged into a local clean version of trunk and then pushed it. [18:09] bac, it should recover from that.. but you can manually delete the lbox google cache @ ~/.goetveld_codereview.appspot.com [18:11] bac, remember that "build" function in the charm "install" hook? I lengthened it a bit :-) (but still no test) [18:11] teknico: that's ok, frankban has redone it anyway [18:11] bac, oh no... [18:11] bac, if it happens again its probably helpful to pastebin the lbox -debug output [18:12] bac, thanks [18:12] ok, more conflicts, get 'em all to me, I can handle them! [18:12] teknico, don't you need to change exposing 80 to 443 [18:12] teknico, you will win :-) [18:12] gary_poster, I'm sure there's broken stuff in there; unfortunately, I cannot seem to run charm tests :-/ [18:13] brace yourself, conflicts are coming... [18:13] :-) [18:13] * gary_poster hangs on to treadmill desk for dear life [18:13] :-) [18:14] gary_poster, and yes, that's one of them [18:17] teknico, I had another few small comments from a code review, which I posted. You should receive them soon if you have not already. trying the charm itself now. [18:17] teknico, incidentally the rapi tls branches from frankban are merged and support specifying the cert directory [18:18] gary_poster, yes, I just pushed a few changes [18:19] cool [18:19] hazmat, great, that's useful for the next card [18:24] teknico, if your having issues with the test runner jimbaker might be able to help [18:24] gary_poster, i've been thinking of getting a treadmill desk in the new year [18:25] hazmat, there were a few problems in my code, and then it's the usual slowness [18:25] jimbaker, lately it's been a standing desk, but I generally like it and have gotten a lot of use out of it. I had an existing treadmill and then added the desk on top of it [18:25] I'm hoping frankban is fixing that, or has already fixed it by now [18:26] teknico, re test runner (i assume using jitsu test), definitely interested in feedback [18:26] I sure hope all those conflicts won't be for nothing! [18:26] teknico, you fixing the conditional I pointed out too? [18:26] note that there's some outstanding work on it, but seems like everything has a current workaround [18:26] gary_poster, yes, thanks for that too [18:26] before i push in the next version [18:26] cool teknico [18:26] welcome [18:27] gary_poster, i use the bar in my kitchen as my standing desk [18:27] jimbaker, we've been heavy users of it i think, doing tdd on the gui charm [18:27] hazmat, excellent to hear that [18:27] i suspect some of the issues are just slowness around juju.. it would be nice if the apt_update/upgrade cloud config thing where an option.. because that eats up significant time on an instance startup and adds to test time [18:28] hazmat, is that a controllable option from juju? [18:28] hi benji, got a second for a quick call regarding making releases? [18:28] jimbaker, no.. its a hard code [18:28] hazmat, got it [18:28] bac: sure [18:29] iirc there was a thread on this [18:29] jimbaker, we originally defaulted to not doing, do to an accidental key mispeling, but spampas fixed it in oct i think, now its pretty arn slow to do things. [18:29] ok, I'm running tests again, let's see what happens [18:29] benji: normal hangout [18:29] k [18:29] it magnified the hp cloud instance startup time by almost double [18:29] hazmat, got it [18:29] bac: email sent [18:30] tahnks frankban [18:30] ack jimbaker. :-) re: speed, a big part of it is building the gui itself, we are pretty sure, so using releases should help a bunch. re: testing with jitsu test, we have http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/view/head:/HACKING.md jimbaker, which might be good for other people to follow to get experience with the test command [18:30] before it lands [18:31] frankban, is your card out of the woo... I mean, prototyping now? ;-) Are those conflicts coming? :-P [18:32] gary_poster, btw that version of jitsu test is in the ppa; however, i believe running it that way gets around a problem w/ autotools [18:32] jimbaker, you mean running it the way we document gets around a problem? [18:32] gary_poster, correct [18:33] bac: one of us froze [18:33] ok cool. [18:33] teknico: yes and yes, moving the card to "coding" [18:33] gary_poster, i'm sad to see the 40m timeout ! [18:34] but purely a function of the env [18:35] jimbaker, yeah :-/ like I said, hopefully that is largely on our side. I'm sure it will be slower than we want still, but we think a good chunk of that time is spent over the network getting things our build needs [18:35] so we are fixing that [18:35] gary_poster, yeah, it's definitely on the extreme side of things. i believe the default timeout for jitsu test is 10m, and this was based on empirical observation [18:35] teknico: nice to have would be redirect from 80 to 443 [18:35] mediawiki on ec2 [18:36] teknico, easy nginx? [18:36] easy on nginx I mean? [18:36] jimbaker, yeah 10 would be a lot better than 40 :-) [18:36] :) [18:37] teknico, starting charm fwiw, to see how it works in practice [18:46] gary_poster, yes, we can redirect from 80 to 443 if useful, it's easy [18:46] gary_poster, I started it 25 minutes ago, still no dice :-/ [18:50] teknico, let's do the redirect. I have an install-error. want to look at it with me? I have a call in 10 [18:52] teknico, http://pastebin.ubuntu.com/1448193/ [18:52] a naughty, naughty s [18:52] gary_poster, looking [18:53] oh, nice :-/ [18:54] gary_poster, no, the "s" is intended [18:54] benji: man, even having a shelve makes 'make distfile' unhappy [18:54] ? [18:54] shelf? [18:54] bac: it may be that the current approach is too paranoid about checking cleanlyness; we may need to dial it back [18:55] drats, it was os.makedirs :-P [18:55] right [18:55] changing locally and retrying [18:55] yeah, i think having shelves is pretty clean [18:56] gary_poster, in what logfile did you get that output? [18:57] teknico, on unit in /var/lib/juju/units/juju-gui/charm.log, or something like that [18:58] teknico, /var/lib/juju/units/juju-gui-0/charm.log [18:58] trying install again, from debug-hooks... [18:58] uhm, why do I have no /var/lib/juju/ ? [18:59] oh, on unit [18:59] teknico, did you start on unit? IOW, juju -hooks [18:59] right [18:59] juju debug-hooks, that is [19:00] dum da dum. waiting on install. [19:00] alsohave call now [19:06] pushed the directory creation fix, gotta go now [19:07] I'll add the redirect tomorrow, with the conflict resolutions === gary_poster|away is now known as gary_poster [19:46] bac approved [19:46] https://code.launchpad.net/~bac/juju-gui/1091787/+merge/140528 [19:46] hazmat: lbox errors https://pastebin.canonical.com/80719/ and https://pastebin.canonical.com/80720/ [19:46] gary_poster: thanks. [19:46] benji: quick look ^^ ? [19:46] * benji looks. [19:47] hazmat: it says auth fails but it is different if i use a clearly bad password [19:47] bac: my two-factor auth is broken, I will look if you put them somewhere I don't have to log in [19:47] * benji goes to ask to get that fixed [19:48] sorry benji, i meant the MP link that gary posted [19:48] ah [19:48] sure [19:48] i hope you can still get to LP === gary_poster is now known as gary_poster|away [19:51] my browser has stored credentials === gary_poster|away is now known as gary_poster [19:53] hazmat: it looks like the same lbox problem y'all discussed here: http://irclogs.ubuntu.com/2012/10/11/%23juju-dev.html [19:56] gary_poster: what version of the lbox package do you have? [19:59] benji: is there still a 'make release' target? i don't see it [19:59] maybe it is now 'make dist' [20:00] bac: right! it is "make dist"; thanks for realizing my mistake [20:01] so i need to s/make distfile/make dist/ and then add a description of 'make distfile' [20:02] exactly [20:03] bac, distfile is still valuable [20:04] distfile is what frankban will need to make a local, temporary dist in the charm [20:04] gary_poster: yes. that is included in what i said [20:04] yes [20:04] ok sorry [20:04] buttinsky! :) [20:04] trying to see version of lbox now. was on call... [20:04] :-) [20:04] looks like the bug may have been fixed in precise but not quantal. are you on Q? [20:05] bac, I am on lbox 1.0-57.64.39.11~quantal1 [20:05] hmm, me too [20:05] weirdness [20:06] am going to try to build my own [20:06] k [20:17] bac, as i recall that was an issue with a golang broken http impl.. afaik that's been resolved (though it regressed and was subsequently fixed again) [20:18] bac, if you have a pastebin output of the error that with -v or -debug flags that would be helpful [20:18] hazmat: well, it sure looks the same [20:18] hazmat: i pasted them above [20:18] ah [20:18] * hazmat backtracks more [20:18] 15:46 [20:19] rogpeppe, ping [20:19] doh.. he's done already [20:21] bac, for your local compile what's the version from $ go version [20:22] hazmat: haven't gotten a local compile to work yet [20:22] i set GOPATH=/usr/lib/go but that isn't working [20:23] hazmat: but it is go1.0.2 [20:24] bac, hmm... i show go1.0.3 [20:26] hazmat: it looks like my golang did not come from the PPA [20:26] hazmat: assuming i get 1.0.3, how do i actually build lbox? [20:26] my lbox is from the gophers ppa [20:26] bac, i think the all in one command for it is.. [20:26] set gopath to a user writeable directory and then just -> go get -v launchpad.net/lbox [20:27] hazmat: oh, i downloaded it and tried to use 'make' [20:27] * hazmat tries it out as well [20:27] which throws up [20:27] bac, yeah.. the go toolchain has evolved from makefiles to a builtin tool [20:28] hazmat: so the Makefile is just a trap? [20:28] * hazmat nods [20:28] bac, for compiling on disk src.. go install [20:29] or go build [20:29] IANAGE [20:29] i am not a go expert ;-) [20:29] its got some magic syntax for recursive compile of dependencies .. like go install ... [20:29] triple dot is recurse to deps [20:30] anyways... the all in one command is much nicer ;-) [20:30] you have to set GOBIN to a place it can install lbox binary [20:31] yup.. that worked for me... GOBIN=$HOME/bin GOPATH=$HOME/golib go get launchpad.net/lbox [20:33] the nice part is that it pull source, so you can modify it.. and then just go install launchpad.net/lbox and it does the recompile install thing [20:35] hazmat: i made a local version and it still fails: https://pastebin.canonical.com/80724/ [20:35] bac, yeah.. i think go1.0.2 is the one with the regression around http client [20:35] bac, i'd try the go version from the ppa [20:36] oh, right, i need to grab 1.03 first [20:36] righto [20:38] bac, you might have to blow away the $GOPATH/pkg dir.. its got the link library for the go reitveld lib that's barfiing and needs recompilation [20:38] yep [20:39] so if gary has the same lbox from PPA for quantal, i wonder why he isn't seeing this problem? [20:50] so, the periodic issue we have with d3.v2.min.js is something to do with the symlink not being created properly... [20:50] charm/juju-gui/app/assets/javascripts/d3.v2.min.js -> /var/lib/juju/units/juju-gui-0/charm/node_modules/d3/d3.v2.min.js [20:51] That second path should have 'juju-gui' in it, like /var/lib/juju/units/juju-gui-0/charm/juju-gui/node_modules/d3/d3.v2.min.js [20:51] s/periodic/intermittent/ [20:52] it makes me suspect that the problem is the makefile not being run from the working directory we expect [20:52] which could be addressed pretty simply in the charm [20:57] the charm tries to address it... [20:57] I wonder if -c would work better [20:57] some tools don't honor the form of cd that we use [21:14] hazmat: got go1.0.3 from golang-stable PPA, rebuilt lbox, same issue. frustrating. [21:14] bac, argh! [21:14] lands by hand. stand back. [21:16] bac, sorry, i'll rendevous with some go folks in the AM and try to dig deeper.. afaics their predominantly europe based @ juju-core [21:24] Voila [21:24] >>> with shelltoolbox.environ(NO_BZR='1'): [21:24] ... with shelltoolbox.cd('juju-gui'): [21:24] ... shelltoolbox.run('make', 'pwd') [21:24] ... [21:24] '/var/lib/juju/units/juju-gui-0/charm\n' [21:26] actually make -C juju-gui isn't any better [21:26] interesting [21:26] cool [21:27] >>> with shelltoolbox.environ(NO_BZR='1'): [21:27] ... shelltoolbox.run('make', '-C', 'juju-gui', 'pwd') [21:27] ... [21:27] "make: Entering directory `/var/lib/juju/units/juju-gui-0/charm/juju-gui'\n/var/lib/juju/units/juju-gui-0/charm\nmake: Leaving directory `/var/lib/juju/units/juju-gui-0/charm/juju-gui'\n" [21:27] We want to see /var/lib/juju/units/juju-gui-0/charm/juju-gui [21:28] oh, wow, weird [21:28] >>> with shelltoolbox.environ(NO_BZR='1'): [21:28] ... with shelltoolbox.cd('juju-gui'): [21:28] ... shelltoolbox.run('pwd') [21:28] ... [21:28] '/var/lib/juju/units/juju-gui-0/charm/juju-gui\n' [21:28] so it's the makefile's use of pwd in a variable that breaks things [21:29] This [21:29] ifeq ($(PWD),) [21:29] PWD=$(shell pwd) [21:29] endif [21:32] ah ha [21:32] $(shell pwd) is always correct [21:32] $(PWD), if it is set, may be wrong [21:33] So simply setting PWD=$(shell pwd) should fix this [21:34] unconditionally [21:41] gary_poster: it's not so much that PWD may be wrong, it is that sudo clenses the environment before invoking the subprocess, removing PWD [21:41] benji, no [21:41] this is a separate issue [21:42] oh [21:42] how is PWD wrong? [21:43] it shows the PWD that you ran Make in, benji. It ignores -C tricks, like make -C juju-gui, and it ignores the trick we use in our shelltoolbox to change the current directory [21:43] ah, yep