[04:16] kadams54 hey u around? [04:16] hatch: yup [04:16] What's up? [04:16] I found a bug in the gui but I remmebr you doing some work on this area so wanted to check b4 I filed it [04:17] so if I D&D a charm, switch to the mv and then click 'auto place' then deploy/confirm [04:17] the machine doesn't get the service icon in it [04:17] I have to switch away from mv then back again [04:23] *sigh* [04:24] You've reproduced this in something other than Chrome? [04:24] It seems like we're constantly squashing "missing icon" bugs [04:25] Huw did some work today that may fix that [04:25] https://github.com/juju/juju-gui/pull/476 [04:26] Or rather, that PR landed today [04:27] kadams54 this was in chrome [04:27] it was this afternoon so running pretty new stuff [04:27] I remember noting when I QA'd it that the icon was added to the machine [04:28] Looks like he landed it at 23 hours ago [04:28] So I suspect we still have bugs to squash [04:28] Though I'd verify it in Safari first [04:28] Since I've seen missing icons only in Chrome [04:28] hmm ok, what's the new comingsoon url? [04:28] Damn you Chrome and your SVG bugginess [04:28] I have no clue [04:29] I didn't know there was a new URL until that discussion this afternoon [04:29] :-) [04:29] haha neither did i [04:30] ok I'll have to remember to test in the am [04:30] I have too many vm's spun up I don't want to risk hitting a kernel panick [04:30] panic even [04:34] I've had that happen multiple times this week. I kinda suspect that's due to water damage, though it seems to happen when I have multiple VMs going. [04:35] lxc within a full trusty virtualbox image + vagrant [04:50] I seem to have added an ubuntu juju vagrant image somehow and it's not shown in the vagrant box list [04:50] and now it's borking new vm's [04:50] argggg hah [04:54] yeah I think our default vagrant image installs and boots juju with the gui by default... [04:55] lazyPower you happen to be kicking around still? [05:04] ahah found it [07:08] rogpeppe1: morning [07:27] urulama: hiya [08:20] hi rogpeppe1 [08:20] frankban: hiya [08:24] frankban: shall we continue? [08:24] rogpeppe1: sure, gogogo [08:24] frankban: i'm there [09:14] jrwren, bac, urulama, Makyo: https://github.com/juju/charmstore/pull/56 [09:59] rogpeppe1: LGTM, but go through comments, please [10:02] urulama: "What do we do with it in the API?" - i don't understand the question [10:02] urulama: thanks a lot for the review, BTW [10:03] so, what do we do with the errgo.Any? [10:03] rogpeppe1: it was fun to see the code and not just images and docs :) [10:04] urulama: we allow resolveURL to return errors with a cause that's passed back to the caller. [10:04] urulama: for example, resolveURL can return a not-found error [10:04] urulama: which will end up as a 404 [10:05] rogpeppe1: oh, now i remember ... all clear ... sorry :) [10:05] urulama: np [10:06] but it could end up as 404, just not in an as elegant way [10:18] urulama: really? [10:20] frankban: https://github.com/juju/charmstore/pull/57 [10:21] urulama, jrwren, Makyo, bac: ^ [10:43] frankban, bac, jrwren: https://github.com/juju/charm/pull/36/files [10:58] frankban, jrwren: https://github.com/juju/charmstore/pull/58 [11:00] jrwren: thanks for your reviews! [11:44] * rogpeppe1 lunches [11:46] * frankban lunches [11:55] * jrwren breakfasts [12:00] * bac has another tea [13:12] rogpeppe1: ready when you are [13:13] hi frankban [13:13] how's it going? [13:14] urulama: very well, we are working on the pub api and we ended up working on some pre-req branches. [13:14] urulama: how is it foing in germany? [13:15] urulama: if you have time, https://github.com/juju/charm/pull/36 [13:16] frankban: lot of talking here :) [13:16] heh [13:16] frankban: good to hear publish api [13:17] frankban: add about in that sentence :) [13:17] frankban: i'll take a look [13:17] urulama: thanks [13:18] frankban: ah, yes, the question about that check was more about the consequences about somehow adding an unverified bundle to the store ... [13:19] and if we didn't use validation before, and there is a good reason that we didn't, it's fine. [13:20] urulama: we didn't use that before. the publish API will take care of validating the bundle with respect to charms also [13:20] frankban: all good then [13:20] urulama: cool [13:22] frankban, rogpeppe1: i'm just thinking ... as there is no client of v3, maybe we don't need v4 ... with this tempo, we'll end up with v192 before end of year :) [13:22] urulama: that was frankban's inclination too [13:23] urulama: perhaps you're right. we haven't published v3 yet. [13:23] i would say, until there is a usage of someone, do not increase version number [13:23] urulama: but in general, i am wary of that approach [13:23] urulama: but we agreed is good to not cheat also to exercise this kind of procedure/api management [13:23] urulama: we actually do not know that noone is using v3 [13:23] urulama: and what frankban says. [13:24] urulama: we need to get in the habit of doing this right. [13:24] urulama: and if there's too much overhead from our procedures when doing this, then perhaps we need to think about how to improve that. [13:25] rogpeppe1, frankban: i agree that from the purity point of view, this is ok, just thinking about the clients ... they use v2, then v12, and then v24 (the only published versions). it looks confusing. [13:25] urulama: all the versions are available and published, really [13:26] urulama: we just haven't announced them. [13:26] urulama: from the p.o.v. of the rest of the world, only the latest version matters, whether it's v1 or v4 [13:33] urulama, rogpeppe1: it seems to me that, given the current "go get" limitations, and given the decision of using gopkg.in as a workaround for API stability and ability to build a project, what we are doing is fine: a new version branch if the public API changes. we kind of agreed on those premises, and if not, we need to find another way IMHO. [13:34] frankban, urulama: i agree with that. we should mostly be able to avoid breaking API changes, I hope. [13:35] rogpeppe1, frankban: sure. i'm just thinking if there's a better practice. for example. As we develop staff the charm API will change, and there is no guarantee that v5 will not hit in next hour. So. What if during "coding sprints" at which we know that they have high probability to change api, we work on a branch [13:35] accumulate all the changes and then push version upgrade [13:35] (unles gopkg.in cant do that) [13:35] urulama: I like that. [13:37] urulama: i have actually come to like the explicit import-path-version-implies-compatible API approach [13:37] urulama: it means that tip is always go-gettable [13:38] urulama: (although it's true that v4 charmstore cannot currently be "go getted" [13:38] ) [13:40] rogpeppe1: sure, i said i like the purity. just not the implications of changing multiple versions in short periods during developments of same end features (it's a different story when new features are rewuired) ... need to think about it [13:40] * urulama needs to go to room for the power plug ... [13:43] urulama: yeah, i'm not entirely sure either. [13:44] urulama: i thought we could try applying the rigorous rule to start with and see how it turned out [13:47] jrwren: for the record, I don't dislike $@ - it's the only way to properly pass through a script or function's arguments to another command. i don't like it when it's not quoted though. [13:48] :) [13:49] I'm lucky package names can't have spaces in them. [13:49] rogpeppe1: so i've talked about this with Gustavo, and he agrees about branches. we all agree with you that having branches in some way breaks the sole purpose of versions, and there you're right [13:49] rogpeppe1: so my suggestion is this. let's try with branches and accumulated changes into one version [13:49] and if it is too painful to use, let's just inc versions [13:50] rogpeppe1: he uses branches as well [13:50] or we can say v3-dev version and mark that it's in changing? [13:50] urulama: that's a good idea [13:50] which one :) [13:50] dev? [13:51] urulama: yeah [13:51] rogpeppe1, frankban, jrwren: ok, let's agree on the -dev one and this is a message to user that it is not stable. You all ok with this? [13:51] urulama: we can just mark on the branch somewhere (perhaps in the package doc at the top level) that the API at that version is currently unstable [13:51] urulama: we can't have -dev as part of the import path [13:52] rogpeppe1: sorry ... v3/dev? === alexpilotti_ is now known as alexpilotti [13:53] urulama: my suggestion is just to write in the package documentation that the API is unstable. When we decide to publish it, we remove that remark from the doc. [13:54] urulama: but that would not require any clients to change [13:54] rogpeppe1: +! [13:54] ah [13:54] rogpeppe1: +1 [13:54] urulama, rogpeppe1: what about using a "develop" branch for development. when required, we merge develop into the latest "v*" branch. if develop breaks the API, then we create the next version branch [13:55] frankban: i'd prefer to use the actual versioned import paths [13:55] frankban: for one thing, it makes it trivial to update with govers [13:55] rogpeppe1: you still use the import path [13:56] frankban: if you use a different branch, then go get can't work [13:58] jrwren: are you still making changes to the charmstore charm? [13:58] rogpeppe1: I know that. I was just suggesting that, rather than working directly on the latest "v*" branch, we could decide to treat those branches as published versions, and work on develop. when develop is ready to be published, we create or update a "v*" branch. clients always use versioned imports [13:59] rogpeppe1: not beyond what is already there. I want to move on. [14:01] morning all [14:02] hi hatch [14:02] frankban have you seen that email from Makyo about the release? Any idea on the error? I'm just about to start on it [14:03] hatch: I didn't [14:03] hatch: to gui peeps? [14:03] oh hah he only sent it to me :D [14:03] sec I'll forward to u [14:04] ok [14:04] ok sent [14:07] hatch: so, did he release the trusty one? [14:07] apparently so [14:08] rogpeppe1, frankban, jrwren: the best practice of using gopkg.in is not here ... we should find one. let's experiment [14:08] hatch: yes he did [14:08] frankban: charmstore is a client [14:09] hatch: I'd suggest to retry running the precise tests, that error can be spurious [14:09] frankban: in our recent situation, what would we have done? [14:09] frankban ok thanks I'll start there [14:11] rogpeppe1: 1) update charm develop. 2) realize there is client code needing the last changes we made 3) start a charm release process 4) check what needs to be released, does it break the API? 5) if so, release a new version branch, if not update the latest version branch 6) update the client [14:13] frankban: how would that change the workflow we just did? [14:13] frankban: after all, charmstore is a client, and needed the changes we made in v3 [14:14] frankban: so in the workflow above, we'd have released a new v3 version. and then the same would have applied to v4. [14:17] rogpeppe1: it does not change the "v*" workflow, it changes how the process is managed. developers know where trunk lives (develop) so they can create their branches form there. creating/updating version branches is now a process per-se, not part of a feature branch. so you have a card for releasing a new version, and everyone knows you are doing that. crazy clients that want to live on the edge can also import th [14:17] e develop branch directly [14:18] frankban, rogpeppe1: ok, let's step back and look at the http://labix.org/gopkg.in [14:19] rogpeppe1: right now it is like 1) let's add this feature, 2) oh man, I need to change the public API 3) I'll just push "vX" to "vX+1", then propose gainst it. at the same time, another developer could do the same. [14:20] frankban: they could, but they would immediately be aware of a problem, because their push would fail [14:22] frankban: i'm just concerned that your proposed workflow makes things more complex (i'm still don't understand how go get would work) and doesn't seem to address urulama's concern about version numbers that increase more frequently than necessary [14:22] rogpeppe1, frankban: ok, what about having v2. adding changes in the development like v2.0.x, v2.0.x+1 ... for small features [14:23] frankban: i'm suggesting that every new API version branch is created as a "development" version. [14:23] and when we finish we either bump that to v2.1 or if change is huge, push it to v3 [14:23] urulama: i don't think that helps [14:23] urulama: we're specifically talking about changes that break the API here [14:23] urulama: for changes that don't break the API, we can just push to the latest version anyway [14:24] urulama: with no need for point versions [14:24] rogpeppe1: I share your concern about complexity of that approach, I'd just like to make the process more clear, by separating the feature branch work from the "new version release" one. [14:24] rogpeppe1: for me v2 to v3 is a huge api change, with old api-s being depricated, not just one ... [14:25] esp. due to the fact that they happened in bulk [14:25] frankban: my proposal is just to have a "// DEVELOPMENT VERSION." comment in the README [14:26] urulama: i don't quite understand. v2 to v3 was just the Reference change, right? [14:26] rogpeppe1: yeah, what I am saying is that usually people knows that a "develop" branch in github is the development version of that project [14:27] frankban: but if we use a "develop" branch, then we can't make it go-gettable AFAICS. [14:27] urulama: any public API change should increase the major version number (at least if we believe in semantic versioning) [14:28] frankban: not quite [14:28] frankban: any *backwardly-incompatible* API changes should increase the major version number [14:29] rogpeppe1: yeah, and that's the rule we are following now [14:30] frankban: agreed. but i'm trying to go along with urulama's suggestion that when there's a new version and we're developing the package in response to feature development in another repository, we might not need to increase the version every time we break the API [14:30] ^^^ [14:31] rogpeppe1: ok, is version v3d allowed? [14:31] urulama: i don't think so [14:31] rogpeppe1: from the short specs i thought so, needed to ask [14:31] urulama: and anyway, i don't think we necessarily want to change the import paths when an API is published [14:32] urulama: the way i think about that is that we "bless" a branch, and from then on we can't change it in a backwardly incompatible way. [14:32] rogpeppe1: ok ... let's end this ... too much time :) let's mark the version as development in the docs as suggested for now [14:33] urulama: ok, so we'll stick with v3 for the time being, and mark the v3 branch as in development [14:33] urulama, frankban: sgty? [14:33] rogpeppe1: at least for now ... i'll try to catch Gustavo and talk about it a bit more [14:33] urulama: good plan [14:33] rogpeppe1: not really, we should make v4 the first development version IMHO [14:34] urulama: i believe we can retrospectively apply the rule here :-) [14:34] oops [14:34] frankban: ^ [14:34] frankban: after all, we are 99.9999% certain no-one else is using v3 [14:35] frankban: i'm in gogogo [14:35] * urulama deletes v3 from disk ... [14:35] :D [14:35] urulama: you don't count :-) [14:35] rogpeppe1: ok, I don't have a real preference, I am just worried about clients starting to use the dev version (like charmstore) and developers keeping changing the API without releasing a new version because, you know, this is a dev version... [14:35] i should probably have said "no other packages are using v3" [14:35] isn't there an open PR for juju to use v3? [14:35] rogpeppe1: i was going for another 9! [14:35] jrwren: actually v2, but yes [14:36] frankban: i agree, that's definitely a potential issue. [14:36] Ah, v2. ok. [14:37] frankban: let's keep an eye on that [14:37] frankban: yes, but the only client could be core ... and we'll talk about this later today ... so. if we don't "bless" new version, it is not stable [14:37] frankban: luckily the charm store isn't usable yet :-) [14:37] frankban: and if it turns out to be PITA, then inc(vers) on every api break will come into practice if no better alternative exists [14:38] urulama: when creating a new version, we'll always add a "WARNING: UNSTABLE DEVELOPMENT VERSION" to the README. [14:38] ^^^ [14:39] urulama: so, when retargeted to v3 and with that warning added, does the charm branch LGTY? [14:39] and if it's README.md with # prefix even [14:39] urulama: SGTM, i think (what does the # prefix mean in markdown?) [14:39] rogpeppe1: title [14:39] large bold letters [14:40] scary bloody letters [14:40] time for a coffee... then gogogo [14:41] frankban: ok [14:44] urulama: i've re-pushed the branch. https://github.com/juju/charm/pull/36 [14:47] rogpeppe1: so the branch will stay at v4? [14:47] urulama: v3 [14:48] rogpeppe wants to merge 2 commits into juju:v4 from rogpeppe:012-no-verify-on-bundle-read [14:48] urulama: ah, i guess the PR needs to be retargetted at v3 [14:48] urulama: will retarget [14:49] urulama: i'll make a new PR [14:49] urulama: if you post a LGTM on the original, i think that should be good enough [14:51] frankban: on https://github.com/CanonicalLtd/charmstore-charm/pull/1 do you feel strongly about the file write v. writelines or can I get a LGTY? [14:52] urulama, frankban: https://github.com/juju/charm/pull/37 [14:53] rogpeppe1: i commented on the #36 ... [14:53] urulama: thanks [14:54] jrwren: just merge it, I was more interested in having unit tests, but as I mentioned, this can be done in another branch [14:54] jujugui call in 6 [14:54] "What if we also add this in a new line? The latest stable version is v2." [14:54] urulama: i don't understand that [14:55] rogpeppe1: i would add "The latest stable version is v2." sentence in a new line after the warning [14:55] urulama: FWIW, i still think the distinction between v2 and v3 is worth it, because they are quite distinct API changes and I don't want to lump the changes for both together when changing juju-core [14:55] urulama: ah! [14:55] v2 vs v3 is ok [14:55] urulama: will do. [14:55] tnx [14:55] urulama: LGTY otherwise? [14:56] rogpeppe1: sure ... it's in #37 [14:58] jrwren, frankban: the details are important, I agree, but could we focus on pushing functionally working charm out, so that we can do proper testing? [14:59] urulama: i just pushed it and moved card. [14:59] jujugui call in 1 [15:01] jrwren: \o/ [15:08] hatch: o/ [15:08] ahoy [15:08] something i can help with still, or did you resolve it? [15:09] jujugui: wifi died; i was on my phone, outside where i get slightly better signal. my connectivity today may be spotty. [15:09] oh I resolved it - for some reason my trusty vagrant images were pulling down the juju image [15:09] jcsackett ohh, party at your place? [15:10] hatch: neighbors place. students are starting to move back into the neighborhood, but classes haven't started yet. [15:10] ohh - are you like that guy in that movie with the frat house next door? :) [15:10] crap now I cn't remmeber what it is called [15:11] not really; they tend to be reasonable about not partying a lot late at night, we try to be reasonable about not getting grumpy other times. [15:12] hatch: ah, ok :) [15:13] lazyPower I did have a question about a charm which always pulls from HEAD being a promoted charm [15:13] there is a thing called Stellar (you may have heard about it, a new currency) [15:13] so I was looking at charming up stellard [15:14] but their iterating so fast that one has to pull from HEAD [15:14] but that unfortunately means that it's likely not stable... [15:14] jcsackett: do you live in East Lansing? [15:14] I dont think there's a problem with the charm being configured to deploy HEAD - ideally we'd rather it be configurable so you can deploy HEAD or a revisionno. [15:14] as thats pretty simple to implement. but HEAD as a default is perfectly acceptable. [15:15] jrwren: i must admit i do not get your reference. [15:16] lazyPower even as a 'promoted' charm? Because currently their get up and running guide is 'git clone, vagrant up' so it would definitely need to be promoted so it could just be `juju deploy stellard` [15:16] urulama, jrwren, bac, Makyo: simple PR: https://github.com/juju/charmstore/pull/59 [15:16] rogpeppe1 Makyo isn't in for the rest of the week fyi [15:16] hatch: ah, ok [15:16] jcsackett: Ooops, I'm getting your geoloc confused with someone else. [15:17] jrwren: dig. :) [15:17] hatch: i'd have to see the charm code before i can commit to anything [15:18] but wrt just deploying head - thats not a blocker. give me config options so i can configure which rev its deploying and you're g2g on that front. [15:19] lazyPower ok cool thanks [15:22] pretty simple copy from old w/ tiny change to make work with new: https://github.com/juju/charmstore/pull/60 [15:24] jcsackett can you take a look at the gui CI...it looks like it's failing on every branch with a isBrowserSupported error - which is usually just a spurious one [15:39] hatch: sure. [15:40] jcsackett thanks - it's failing all over the darn place :/ [15:48] jrwren: mayber PR #60 should be v4 API adapted first before being pushed from _old? [15:48] s/mayber/maybe [15:49] urulama_: it is. I mean, all it does is call NewServer with V4 as a parameter. [15:51] jrwren: sorry, missed it [15:55] frankban, rogpeppe1: could you please take a look at https://github.com/juju/charmstore/pull/60 so that jrwren continues? [15:56] frankban, rogpeppe1: sorry, I know that you are in "go go go" mode :) [15:56] urulama_: :-) [15:56] urulama_: yeah, we are finally free to move forward... [15:58] hi jcsackett [15:59] hi bac. [15:59] bac welcome! [15:59] jcsackett: i see ci is a mess. are you working on it? did you upgrade jenkins? [16:00] bac: i just started looking at it, and i don't have the juju bits for it so about all i can do is check the machine itself. [16:00] it's all pertier now [16:00] bac oh I thought that's what you did [16:00] lol [16:00] since the pretty update I don't think anything has landed [16:00] well who the heck updated it haha [16:01] hatch: i *may* have. rick and i talked about it but i can't recall exactly [16:01] ah, it is indeed updated; perhaps rick did it? [16:01] jcsackett: so you can ssh. [16:01] yeah it's been broken since the update I think [16:01] yeah, i'm on the machine now. [16:02] jcsackett: ok. [16:02] jcsackett: i'm surprised the 'post build step' is not marked 'Run script only if all previous steps were successful' [16:03] jcsackett: but that's not why it is failing [16:04] urulama so I bought parallels [16:04] it has some cool features over fusion, but it has the same delay so it must be an ubuntu thing... [16:05] hatch: so it looks like it's just failed on two branches? that may just be the spurious biting you more often than you would like. [16:05] I can trigger them again I guess [16:06] hatch: i'm running the build again. [16:06] (not the merge job, just the regular test run) [16:06] ohh ok, well I'll try and land one again, see if it's still spurious [16:06] ok [16:06] it's just odd that there were so many failures in a row [16:07] hatch: in both jobs [16:07] right [16:08] hatch, jcsackett: what does 'git branch' -> *(no branch) mean [16:08] i hadn't seen all the failures in merge; this does seem a bit odder. [16:08] bac: wehre do you see that? [16:08] from ~jenkins/workspace/juju-gui-merge [16:11] huh. i have no idea. [16:11] presumably it's checking something out in headless, i think? [16:12] jcsackett: so my assumption is a) the tests pass locally b) they don't pass on jenkins because the workspace is screwed up [16:13] *sigh* [16:13] jcsackett: there are also a ton of branches there. looks like we're never cleaning up. certainly not the problem. === BradCrittenden is now known as bac [16:16] bac: possibly [16:17] ...can we just blow away the dir's contents? [16:17] bac: ^ will jenkins rebuild it, since it checks stuff out? [16:17] jcsackett: probably. there is a button to destroy the workspace on the gui [16:17] votes on whether or not to give it a try? [16:18] but it would be nice to possibly figureout what is actually wrong. [16:18] bac: i don't how to investigate a busted git situation properly. we could give hatch ssh access, as he's our git-ish person, i guess. :p [16:18] jcsackett: why don't you do it on the juju-gui job and not the -merge job [16:18] bac: that was my plan. [16:19] I am thinking it might be a sauce labs issue [16:19] did they update their stuff recently? [16:19] it always fails in chrome with the isBrowserSupported error [16:19] http://ci.jujugui.org:8080/job/juju-gui-merge/545/console [16:19] hatch: can you run them locally? [16:20] bac I'm not set up to run them locally - working on it but new vm and all that [16:20] it'l take me a while [16:20] well, if anyone can try 'make ci-check' to see [16:21] what entails being setup? [16:21] i have an lxc for gui, so i can thrash that, but i don't know what else needs setting up. [16:21] http://sauceio.com/index.php/2014/07/sauce-labs-selenium-chrome-updates-august-2/ [16:21] ^ there is our issue jcsackett bac [16:22] new version of selenium? [16:22] it seems that way [16:23] and new chrome and chrome driver [16:23] which might not have the isBrowserSupported option [16:23] jcsackett, hatch: my battery is about to die and i don't have an outlet available. [16:23] so, it looks like we can a) update our test suite or b) try forcing selenium version. [16:23] good night and good luck. [16:23] bac ok we can take over, have a good night [16:23] bac: night dude. [16:24] yeh lets force it to use the old version [16:24] we are low on man power this week so lets just get it up and running and we can investigate the fix next week or so [16:24] ok, where's our selenium config in the tree? [16:24] I thought you knew? :P [16:26] browser.py maybe... [16:27] hatch: ok, i'll dig into this. [16:27] thanks [16:31] chrome keeps blacking out when I drag the window in Ubuntu, looks like I'm switching to Firefox [16:39] jrwren: for future reference, we don't push the big green button to merge branches into the charm store [16:39] jrwren: instead, add a comment with the sacred rune :shipit: [16:41] jrwren: (we missed a few issues from your PR, which doesn't actually build correctly, unfortunately) [16:43] its the shibolith [16:47] rogpeppe1: yeah, i realized ci system does it AFTER I pushed that tempting shiny green button. [17:03] jrwren: https://github.com/juju/charmstore/pull/61 [17:04] rogpeppe1: ah, i missed adding the old config.go, which is what I was going to do. #fail. [17:50] Anyone know if the pending attribute on a Service is a reliable indicator of uncommitted/ghosted state? [17:50] guihelp: ^ [17:52] kadams54 it will be being changed to be isUncommitted or something [17:52] so that everything can use the same key [17:52] Can I use it as is? [17:53] Or rather, what's the best way currently to know, within a Service instance, if it's in an uncommitted state? [17:54] yeah I believe so [17:54] best is to test it though [17:55] yup [18:38] jcsackett hey any luck with the CI? [18:59] hatch: i think so--browser.py was indeed the place to set things, and i've gotten to a state where i can replicate the error locally. i'm locally testing the fix. [19:00] or i guess "a fix" since i don't know if it works yet. [19:00] excellent [19:00] thanks for doing this! [19:09] ugh still downloading the precise charm repo [19:09] this thing is massssssive [19:09] make that the trusty charm [19:12] you did a getall? [19:23] I followed the instructions [19:23] bzr branch lp: .... [19:23] :) [19:32] i wonder if that is why the juju charm tools has getall. [20:10] jcsackett so.....diditwork?huhhuhdidit?didithuh? [20:11] hatch: no. [20:11] hatch: it creates a new error. [20:11] *sadface* [20:12] it just flat out aborts, claiming the settings conflict with firefox. since the update post only references chrome, i'm trying it only setting the selenium version for chrome, and leaving firefox alone. [20:13]