[05:44] <stub> TheFezzer: I'm currently using webup8's Oracle JVM packages, but still need to run the approach past legal. If legal disagrees, I'm stuck with requiring users to provide the tarball.
[05:45] <stub> TheFezzer: Look for jvm in https://bazaar.launchpad.net/~stub/charms/trusty/cassandra/spike/view/head:/hooks/helpers.py
[05:46] <stub> TheFezzer: It is also an example of supporting proprietary software, since the DataStax edition of Cassandra can be used.
[05:46] <TheFezzer> I think that if I require the user to actively flip the config flag, we’re good. Otherwise… wait a minute. Is there a single developer alive who hasn’t yet signed the Oracle EULA at some point or another?
[05:47] <TheFezzer> it’s free to try, and we’re not even stuffy about licenses.
[05:47] <TheFezzer> We give it to ASF for free, even. ;)
[05:47] <stub> TheFezzer: Well... it is probably a statistically insignificant number, so statistically it is 100%. So yes, everyone has signed the license even if they haven't :)
[05:48] <stub> The most annoying part is testing
[05:48] <TheFezzer> the particular product I’m working on today is okay with open-jdk so pshaw. ;)
[05:48] <stub> How can an automated test runner accept a license agreement?
[05:48] <TheFezzer> I’m making my first Python charm, and wow the features.
[05:49] <TheFezzer> It seems like someone was saying earlier that IBM was okay with someone flipping a config flag and that released the charm to do it?
[05:49] <TheFezzer> websphere-liberty
[05:49] <TheFezzer> but one would presume that Amulet would be empowered to flip a flag
[05:50] <stub> I imagine, as the author of the test and person who installed it into the test runner, I would be the person who accepted the license. If I lived in a jurisdiction where it had any effect, which I don't.
[05:51] <stub> Which is why I punt it to legal later, since I'm not the person who would get sued :)
[05:51] <stub> But yeah, websphere should have already jumped any hurdles. I'll have a look myself later.
[05:52] <TheFezzer> :D
[07:03] <catbus11> why the icon bounces back to where it was in the juju gui canvas? Why doesn't it stay where I dragged it to?
[07:18] <catbus11> I can't see all the icons without moving the canvas left or right. It's been zoomed out to the max.
[10:13] <gnuoy> jamespage, do you have anytime to take a look at https://code.launchpad.net/~gnuoy/charm-helpers/nrpe-service-functions/+merge/246104 ?
[10:18] <jamespage> gnuoy, +1
[10:18] <jamespage> gnuoy, https://code.launchpad.net/~james-page/charm-helpers/kilo-enable/+merge/245870
[10:18] <jamespage> if you have time please
[10:24] <gnuoy> jamespage, +1
[10:28] <gnuoy> jamespage, I'll merge yours while I'm at it
[10:28] <jamespage> gnuoy, thanks
[10:28] <jamespage> gnuoy, are you going todo a general charm helper sync post that?
[10:29] <gnuoy> jamespage, I am as part of this nrpe work
[10:29] <jamespage> gnuoy, awesome - I won't bother then
[10:29] <gnuoy> kk
[11:14] <gnuoy> jamespage, a small mp if you have a moment https://code.launchpad.net/~gnuoy/charm-helpers/add-nrpe-gethostname/+merge/246110
[14:12] <gnuoy> jamespage, dosaboy, coreycb I have a bunch of mps based on bradm s work to add nrpe. Most of the logic has landed in charmhelpers so mostly it's a charmsync plus a bit. There are a few of them but any reviews greatly appreciated https://pastebin.canonical.com/123178/
[14:17] <jamespage> gnuoy, as they are re-syncs + tweaks to the nrpe stuff in the charms, I'm happy to give a conditional +1 across the board based on osci checking things out OK
[14:17] <gnuoy> jamespage, I'll take that! thanks
[16:10] <jamespage> gnuoy, have those syncs for nrpe landed yet? going to start testing kilo support tomorrow
[16:13] <gnuoy> jamespage, osci is still working through. But on the subject of those mps, does your +1 stand for branches with no amulet tests?
[16:13] <jamespage> gnuoy, yes
[16:13] <gnuoy> ta
[17:53] <gnuoy>  jamespage those mps are merged with the exception of cinder. The amulet tests are failing atm. I don't think it's related but I'm checking.
[21:27] <beisner> lazyPower, around?
[21:42] <lazyPower> beisner: in a pairing session, replies may be latent. whats happening?
[21:43] <beisner> hi lazyPower nothing urgent.  just want to pick your brain a bit some time re: bundletester - i've gotten onto another track as well, will holler another time.
[21:43] <lazyPower> beisner: sounds good - ping me whenever and i'll be happy to respond with what i know
[22:18] <jose> guys, would you say advertisement is allowed in a charm's readme? found something that looks like it.
[22:21] <sarnold> tastefully on-topic might be alright..
[22:29] <noise][> hi, I'm just getting started w/mojo and trying to figure out how to make mojo run work w/locally modified a spec, but it seems to be pulling from the latest commit even when I specify my spec_url as a local file path
[22:32] <skay> noise][: is your local file path a local bzr repo?
[22:32] <skay> noise][: I have been using a local bzr repo successfully
[22:32] <noise][> skay: it's a bzr repo, yes
[22:33] <skay> noise][: have you committed the changes you wnat it to run?
[22:33] <skay> if yes and yes, then I am out of suggestions
[22:33] <noise][> no, uncommitted
[22:33] <skay> I am very new myself
[22:33] <skay> oh, okay. commit them and then run
[22:34] <noise][> :( , kinda tedious for each change and going to make for a long commit history
[22:34] <skay> :( yeah
[22:35] <noise][> skay: well thx for the tip in any case
[22:35] <skay> there is probably something I'm missing, and hopefully you'll get a reply with a proper response
[22:35] <skay> meanwhile this maybe be a workaround
[22:38] <roadmr> noise][, skay : since mojo uses bzr to fetch (think: branch) the spec from the target repo, it will pull only committed changes. Yes, it would make for a somewhat longish history but that's how bzr works anyway
[22:38] <noise][> roadmr: ok, an unpleasant debug cycle,. but i'll press ahead
[22:38] <skay> roadmr: the history drives me crazy :)
[22:39] <roadmr> noise][: you could always work until you have amassed a good set of changes, then bzr uncommit until you have a blob you like, and recommit everything in a single commit. Not as powerful as git history manipulation but could do the trick
[22:39] <skay> roadmr: I admit I sometimes play around with a completely local repo until I've flogged something to death THEN I go commit it to the real place
[22:40] <noise][> roadmr: my kingdom for git rebase :)
[22:40] <roadmr> noise][: ah, if you test, then flip something minor then test again, you could bzr uncommit, do the tweak, then bzr commit again. That will keep your history from growing too much. Only problem is, if you want to change something you committed N revisions ago (N > 1) it will be more painful
[22:40] <skay> noise][: did anyone tell you about git-lp? sometimes I use it
[22:40] <skay> it won't help with this though
[22:40] <roadmr> skay: yea, that'd be the other option (using a scratch bzr repo)
[22:44] <skay> noise][: where did you learn about mojo?
[22:44] <skay> I only recently started using it