[07:30] <A-Kaser> Hi
[07:58] <jacekn> hello. marcoceppi marked my bug as "Fix Released" but my charm is still not recommended in the charmstore: https://bugs.launchpad.net/charms/+bug/1538573
[07:58] <mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:Fix Released> <https://launchpad.net/bugs/1538573>
[07:58] <A-Kaser> I would like to have a node with mesos, hadoop, spark to run my charm; I'm using cs:~tads2015dataart/trusty/mesos-master-0 as "scope: container"; but how can I add trusty/apache-spark-7 on the same node ?
[07:58] <jacekn> is there anything I need to do? If not when shoudl I expect my charm to be in the charmstore?
[08:22] <D4RKS1D3> Morning, Someone knows if its possible to re-bootstrap one enviorement? I am trying to install services with juju in maas, and all the time I need to create all
[10:15] <gnuoy> jamespage, anytime for https://review.openstack.org/#/c/301637/ ?
[10:15] <jamespage> gnuoy, my n-ovs review for enabling DPDK is good for initial review; I need to figure out one other thing which is how to get libvirt to switch to using the root user for qemu processes - but that will require a n-compute change as well
[10:15] <jamespage> gnuoy, sure
[10:16] <jamespage> gnuoy, swap you for https://review.openstack.org/#/c/301761
[10:16] <gnuoy> done
[10:16] <gnuoy> well, deal is what I mean
[10:17] <jamespage> gnuoy, :-)
[10:17] <jamespage> gnuoy, also have https://review.openstack.org/#/c/302236/ up as well
[10:17] <jamespage> and https://review.openstack.org/#/c/300384/
[10:20] <jamespage> gnuoy, did you figure out whether the switch to apache+wsgi works OK with https?
[10:20] <gnuoy> jamespage, Yes I did, not it didn't, it does now
[10:20] <jamespage> is the existing support re-used i.e. haproxy -> apache SSL -> apache-wsgi
[10:20] <gnuoy> yes
[10:21] <gnuoy> jamespage, see how I cunningly stole the keystone.conf context which has the port shuffle logic
[10:21] <jamespage> gnuoy, right - so we kinda double hop through apache now?
[10:21] <gnuoy> jamespage, yes we do
[10:21] <jamespage> gnuoy, that's fine - just wanted to check...
[10:22] <gnuoy> jamespage, I think the seperation makes sense tbh. It allows the charm to still talk to the local keystone on localhost without ssl
[10:22] <jamespage> gnuoy, agreed
[10:23] <jamespage> gnuoy, +2 on that review - lgtm
[10:23] <jamespage> landing now
[10:24] <gnuoy> ta
[10:32] <jamespage> gnuoy, going to focus on the network-spaces -> ceph bits now and will come back to sorting out the last bit of dpdk/libvirt/ovs madness after that
[10:32] <gnuoy> jamespage, ok, enjoy
[10:36] <gnuoy> jamespage, can I just clarify that your saying that once a device has been given to dpdk you can still see the device via lspci etc but there is no way of accessing the MAC ?
[10:36] <jamespage> gnuoy, it is still in lspci and there might be a way of discovering it still via /sys
[10:37] <jamespage> but I did not dig that deep
[10:42] <neiljerram> Has someone just broken the mysql-server package on Xenial?  As of this morning, deployment of the mysql charm on Xenial is failing for me, whereas yesterday it was fine.
[10:44] <suchvenu> Hi All
[10:44] <suchvenu> I have a query related to getting values in Interface.
[10:46] <suchvenu> I am trying to get the contents of a file from the consumer charm . In the interace (requires side) can I get this value ?
[10:47] <suchvenu> In require side, I am trying something like this :  subprocess.check_output("sudo cat /root/.ssh/id_rsa.pub")
[10:47] <suchvenu> I am getting the error that the file doesn;t exist , where as actually the file exists.
[11:10] <gnuoy> neiljerram, just had one of our automated tests fail using the mysql charm on xenial. Looking into it now
[11:16] <jamespage> neiljerram, might be that 5.7 landed...
[11:16] <jamespage> rbasak, ?? ^^
[11:16] <rbasak> gnuoy: possibly bug 1566406
[11:16] <mup> Bug #1566406: postinst fails on mysql_upgrade if database is already upgraded <amd64> <apport-package> <package-from-proposed> <xenial> <mysql-5.7 (Ubuntu):In Progress by racb> <https://launchpad.net/bugs/1566406>
[11:18] <jamespage> gnuoy, hmm - are you aware of any test isolation problems in any of the charms?
[11:19] <jamespage> gnuoy, I was expecting mock state to be rest between indivivdual tests, but I'm not seeing that in ceph-mon
[11:19] <jamespage> reset rather
[11:27] <neiljerram> gnuoy, jamespage, thanks - certainly 5.7 is the version now being installed.
[11:33] <neiljerram> gnuoy, jamespage It is still possible to install version 5.6.28-1ubuntu3 of mysql-server, and that appears to go through...
[11:34] <neiljerram> (although a manual step of 'rm -f /var/lib/mysql/debian-*.flag' is needed)
[11:45] <gnuoy> I'm seeing http://paste.ubuntu.com/15667815/
[11:46] <gnuoy> proper context http://paste.ubuntu.com/15667822/
[11:47] <freak_> I'm getting below error when deploying juju-gui
[11:47] <freak_> root@maas61:~/.local/share/juju#  root@maas61:~/.local/share/juju# watch juju status Every 2.0s: juju status                                                                                Thu Apr  7 16:42:06 201  [Services] NAME       STATUS  EXPOSED CHARM juju-gui   unknown true    cs:trusty/juju-gui-52  [Units] ID         WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
[11:49] <freak_> [Machines] ID         STATE DNS INS-ID  SERIES AZ 0          error     pending trusty
[11:51] <freak_> http://paste.ubuntu.com/15667891/
[11:52] <gnuoy> jamespage, yes, I had test isloation problems with the action unit_tests specifically but I don't think the issue is limited to them
[11:53] <freak__> i have deployed juju-gui and also expose it..but when i type watch juju status i get this outputn: http://paste.ubuntu.com/15667891/
[11:53] <freak__> anyone pls help
[11:54] <rick_h_> freak__: see help in #juju-gui
[11:56] <freak__> rick_h thanks
[12:07] <rbasak> gnuoy: a fix for the known mysql-5.7 packaging bug is on its way. Please let me know if you're still broken after that lands.
[12:08] <rbasak> neiljerram: ^^
[12:08] <rbasak> We'll be deleting mysql-5.6 soon.
[12:09] <neiljerram> rbasak, thanks!  But I suggest not deleting mysql-5.6 until you're really sure that 5.7 is good!
[12:09] <rbasak> neiljerram: we don't really have a choice now. Going back would be more effort than fixing whatever's broken in 5.7.
[12:11] <marcoceppi> jacekn: looks like ingestion is broken
[12:11] <neiljerram> rbasak, I don't understand.  I just managed to work around the current 5.7 breakage by installing version 5.6.28-1ubuntu3 of mysql-server.  There is no 'more effort' needed - you just need to leave 5.6 there.
[12:15] <rbasak> neiljerram: the archive is in a pretty inconsistent state.
[12:15] <rbasak> neiljerram: we can't release like this.
[12:16] <rbasak> neiljerram: for example we couldn't do a security update for 5.6 right now without breaking 5.7.
[12:16] <rbasak> (and we wouldn't want double the maintenance effort to support both for five years in any case)
[12:17] <gnuoy> rbasak, will do, thanks
[12:18] <neiljerram> rbasak, OK, but all I said was "I suggest not deleting mysql-5.6 until you're really sure that 5.7 is good!"  That could just mean for the next couple of days - it doesn't have to mean beyond the Xenial releas.
[12:18] <rbasak> If we wanted to go back to 5.6, we'd need to upload a new 5.6 from the 5.6 source and have it build anyway.
[12:19] <rbasak> So deleting it or not deleting it doesn't actually make any difference.
[12:19] <neiljerram> Are you saying that you've deleted 5.6 already?
[12:20] <rbasak> No, but we will.
[12:20] <rbasak> I appreciate your sentiment, but in practice it makes no difference from an archive management perspective.
[12:20] <rbasak> We can't delete 5.6 until all the reverse dependencies are switched to 5.7.
[12:20] <rbasak> I'm working on that actively now.
[12:21] <neiljerram> I'm sorry, I have no clue what you're actually saying.  Sounds like nonsense to me.
[12:21] <rbasak> 5.6 and 5.7 are not independent. They are intertwined. Between each other and with their reverse dependencies.
[12:22] <neiljerram> Right now, I can install 5.6 to work around 5.7 breakage.  If you delete 5.6, I won't be able to do it, and I won't have a working 5.7 either.  To my mind, that definitely does "make a difference".
[12:22] <rbasak> I have uploaded a fixed 5.7.
[12:22] <rbasak> If it does not work, please tell me so that I can fix it.
[12:28] <neiljerram> rbasak, Cool, I will try that.  Probably will be an hour or so, because of my Juju deployment cycle time.
[12:30] <rbasak> neiljerram: make sure you pick up the fix for bug 1566406 please - 5.7.11-0ubuntu5, which isn't built and published yet.
[12:30] <mup> Bug #1566406: postinst fails on mysql_upgrade if database is already upgraded <amd64> <apport-package> <package-from-proposed> <xenial> <mysql-5.7 (Ubuntu):Fix Committed by racb> <https://launchpad.net/bugs/1566406>
[12:30] <rbasak> neiljerram: I don't know that this is your issue either. I only know that we were getting reports and this was a bug. You might have another.
[12:40] <neiljerram> rbasak, I looked at the bug, but can't tell where to get the fixed package from.
[12:41] <rbasak> neiljerram: when the bug is marked Fix Released, wait half an hour and it should be available from archive.ubuntu.com.
[12:41] <rbasak> Just check the version you end up with (it'll be announced in the bug) to be sure you have the fix.
[12:42] <neiljerram> rbasak, BTW it appears that my latest deployment using 5.6 instead doesn't fully work - which I guess is the point that you were making above.
[12:42] <neiljerram> rbasak, Thanks, will do.
[12:48] <jamespage> gnuoy, I think I'm going a little mad
[12:48] <jamespage> I have no idea why I'm suddenly hitting this isolation problem
[12:49] <gnuoy> jamespage, are you adding a new unit_test file ?
[12:49] <jamespage> gnuoy, yes
[12:49] <gnuoy> jamespage, does its name feature alphabetically before the others?
[12:50] <jamespage> gnuoy, kinda in the middle
[12:50] <gnuoy> jamespage, well, I'd try renaming in temporarily test_zzz and go from there
[12:50] <gnuoy> s/in/it/
[12:51] <jamespage> gnuoy, nope - its completely due to when two tests get scheduled on the same testr process
[12:52] <jamespage> gnuoy, its like the cleanup is not getting run between individual tests...
[12:52] <jamespage> afaict
[12:52] <gnuoy> jamespage, engage the tinwood would be my advice
[12:54] <tinwood> jamespage, can you run them both individually? (e.g. tox -e py27 -- -n unit_tests.xxxx)
[12:56] <jamespage> tinwood, no
[12:56] <tinwood> oh
[13:02] <jamespage> tinwood, its really weird - the mocks are different for each test case...
[13:02] <jamespage> but something odd is going on
[13:02] <tinwood> which charm is it?
[13:08] <jamespage> tinwood, ceph-mon
[13:08] <jamespage> tinwood, https://review.openstack.org/#/c/302681/
[13:10]  * tinwood is having a look ...
[13:12] <tinwood> jamespage, do you mind if I pull it down and have a look at it?
[13:12] <jamespage> tinwood, please do
[13:12] <jamespage> I'm baffled
[13:12] <jamespage> what should have taken me 2 hrs todo across three charms is completely blocking me now...
[13:12] <tinwood> okay, will do.
[13:16] <jamespage> tinwood, sorry I'm being a dimwit
[13:16] <jamespage> please stop looking at my complete stooopidity...
[13:16] <tinwood> have you tracked down the problem.
[13:16] <jamespage> @cached - wish I'd never written that decorator...
[13:16] <tinwood> ah.
[13:17] <tinwood> yes, that would do it.
[13:19] <tinwood> tricky to mock as it happens at loadtime.
[13:20] <jamespage> tinwood, yah - I fixed this before
[13:20] <jamespage> tinwood, reseting the cache in tearDown works OK
[13:20] <tinwood> ah, good idea.  Like it.
[13:31] <jamespage> gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces they should all be good now
[13:31] <jamespage> to much copy/paste in the ceph charms atm - cholcombe, icey - it would be nice to try address that next cycle...
[13:32] <icey> jamespage: I'd love to take a whack at layering up the charms, the ceph-mon and ceph inherit from a ceph-base, and then we could maintain the ceph charm as a POS charm because it would just depend on ceph-mon and ceph-osd
[13:32] <jamespage> icey, +1 sounds neat...
[13:33] <jamespage> icey, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces might be of interest to you as well
[13:33] <icey> I'm about to want a review to add the storage hooks (in the ceph charm) to the ceph-osd charm as well :)
[13:43] <jamespage> tinwood, pxc pause/resume lgtm - ok for me to push that through to landing?
[13:43] <tinwood> jamespage, pxc == percona?
[13:44] <jamespage> tinwood, yes
[13:44] <tinwood> yes, it should be.
[13:45] <tinwood> jamespage, I also need to talk to you about ceph and pause/resume.  I'm still unsure about use case now I've dug into it more
[13:57] <jamespage> gnuoy, arghhhhhh
[13:57] <jamespage> gnuoy, how many amulet tests check for 'keystone' as a running service now...
[13:58] <gnuoy> jamespage, ? amulet was passing for me with the move to mod_wsgi or am I missing your point?
[13:58] <jamespage> gnuoy, well yes in keystone
[13:58] <gnuoy> oh
[13:58] <gnuoy> yeah
[13:58] <jamespage> but how many other charms deploy keystone as part of their amulet tests...
[13:58] <jamespage> ceph-mon
[13:58] <jamespage> \o/
[13:59] <gnuoy> jamespage, I don't think other charms should test that tbh
[14:01] <jamespage> gnuoy, yeah - I think our amulet test approach needs a rethink/refactor...
[14:02] <jamespage> beisner and I where chatting about that a while back
[14:09] <jamespage> gnuoy, ok reviews raised for ceph* for that change...
[14:43] <lazyPower> mbruzek - when you get a sec i need a hotfix review on https://github.com/juju-solutions/layer-docker/pull/34
[14:45] <jamespage> gnuoy, I had a run through the apparmor reviews; I don't think they are ready to go in yet...
[14:46] <gnuoy> jamespage, ok, I'll take a look at your review comments
[14:58] <lazyPower> cory_fu nvm on the ping,
[14:58] <jamespage> gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:network-spaces are testing OK
[14:59] <cory_fu> lazyPower: What ping?
[14:59] <lazyPower> from 10:17
[15:00] <lazyPower> sa'll good man, you missed it :)
[15:00] <gnuoy> jamespage, not sure canonical ci agrees with you
[15:00] <jamespage> gnuoy, oh not those ones
[15:01] <jamespage> gnuoy, https://review.openstack.org/#/q/status:open+branch:master+topic:keystone-apache
[15:01] <gnuoy> kk
[15:01] <cory_fu> lazyPower: Odd, I didn't get a ping from you at that time.
[15:01] <cory_fu> Hope I'm not missing other messages
[15:02] <gnuoy> jamespage, are you suggesting an amulet full would be overkill ? I tend to agree is thats what your proposing
[15:02] <jamespage> gnuoy, +`
[15:02] <jamespage> 1 rather
[15:02] <gnuoy> kk
[15:11] <aisrael> What's the status of payloads in juju 2? I'm running beta3 and `juju list-payloads` throws "ERROR unknown object type "payloads" (not implemented)"
[15:11] <aisrael> marcoceppi: lazyPower ^^
[15:11] <lazyPower> :O
[15:12] <lazyPower> cherylj - did payloads get dropped?
[15:15] <aisrael> `juju help payloads` is dead, too. :(
[15:15] <alexisb> lazyPower, no
[15:15] <alexisb> that is a bug
[15:15] <alexisb> can you please open a bug
[15:15] <lazyPower> you betchya alexisb
[15:15] <aisrael> alexisb: will do!
[15:15] <alexisb> we can get eyes on it
[15:19] <icey> cory_fu: how do oyu guys handle the upgrade charm hook in reactive / layers
[15:25] <jamespage> gnuoy, I suspect that our mysql woes are charm related
[15:26] <gnuoy> jamespage, well, a fresh install on xenial without the charm did not result in an error
[15:26] <gnuoy> rbasak, ^
[15:26] <jamespage> gnuoy, yah - confirmed
[15:26] <gnuoy> jamespage, but I can't see what the charm is doing to mess up the install
[15:26] <rbasak> It wouldn't surprise me if some behaviour changed in 5.7 causing this though.
[15:26] <rbasak> Eg. authentication.
[15:26] <jamespage> gnuoy, I think it pushed a config file onto disk prior to install
[15:26] <rbasak> We're using socket auth by default now, so a few bits have changed, especially if automatic.
[15:27] <jamespage> rbasak, did 5.7 just go in?
[15:27] <rbasak> bug 1567098 for example.
[15:27] <gnuoy> jamespage, yes
[15:27] <mup> Bug #1567098: Cannot log in as root user when not root Unix user <mysql-5.7-transition> <mysql-5.7 (Ubuntu):New> <https://launchpad.net/bugs/1567098>
[15:27] <rbasak> jamespage: yes
[15:29] <cory_fu> icey: Basically the same as other hooks, really.  The charm dependencies (wheelhouse) is upgraded automatically, and you can have a @hook('upgrade-charm') decorated block if you need to do anything special during upgrade.
[15:30] <cory_fu> I think upgrade-charm is probably the one remaining case where it really makes more sense to use @hook
[15:42] <jamespage> gnuoy, rbasak: I think its something todo with the fact that the charm writes password files into /var/lib/mysql
[15:42] <beisner> jamespage, gnuoy - yah i'm still +1 for yanking irrelevant checks from amulet tests (focus on the charm and its services only).
[15:43] <beisner> jamespage, gnuoy - we also need to a spike on xenial test enablement.
[15:44] <beisner> gnuoy, looks like the charm writes a conf file, then apt installs with confold.  maybe we're breaking there?
[15:45] <gnuoy> beisner, that sounds likely
[15:46] <rbasak> Do you need to tell apt to tell dpkg to use your conffile and not overwrite? There's an option for that AIUI.
[15:46] <neiljerram> rbasak, Sorry for not asking this earlier - but how long would you expect until that mysql-server bug shows Fix Released ?
[15:46] <rbasak> neiljerram: by now I'd have thought. I see an issue. Looking.
[15:46] <neiljerram> rbasak, Thanks...
[15:48] <beisner> jamespage, gnuoy (ftr consider that a standing +1 to prune such tests as drive-bys with your other changes)
[15:48] <gnuoy> ta :)
[15:59] <A-Kaser> is it possible to have action executed when we remove a service , as an uninstall script ?
[17:04] <kwmonroe> hey suchvenu - you were asking about getting a remote unit name from an interface?
[17:05] <kwmonroe> i'm assuming you want to do this from the "requires" side of the interface.. if the scope of that interface is scopes.UNIT, then you can have a method that simply returns self.conversaion().scope
[17:05] <kwmonroe> (scope will be the name of the unit)
[17:05] <suchvenu> Yes
[17:06] <suchvenu> i want to get the require side unit name
[17:06] <suchvenu> and my scope is global
[17:07] <kwmonroe> (one sec, gotta meet the schoolbus)
[17:07] <suchvenu> ok, np
[17:13] <kwmonroe> sorry abou that suchvenu, i'm back
[17:13] <kwmonroe> ok.. so you have an interface, and in the requires.py, you want to return the remote unit name?
[17:13] <kwmonroe> (bcsaller may have some tips here ^)
[17:14] <suchvenu> in provides.py i want remote unit name
[17:17] <kwmonroe> ok, so you're providing a service, and the provider needs to know the remotely connected unit name?  i'm guessing this is to do something like create a db2 instance name based on whatever requires the db2 relation?
[17:17] <lazyPower> kwmonroe - there's an environment variable for $JUJU_REMOTE_UNIT during a relationship hook sequence
[17:18] <suchvenu> yes, right... kwmonroe
[17:18] <lazyPower> https://jujucharms.com/docs/devel/reference-environment-variables#juju_remote_unit
[17:18] <lazyPower> doc link if its helpful ^
[17:18] <kwmonroe> oh hey!  there's an idea.. that may be an easy thing to do do suchvenu ^
[17:19] <suchvenu> the env variable $JUJU_REMOTE_UNIT will work in the interface a?
[17:19] <suchvenu> I have used it in the reactive layer..
[17:19] <suchvenu> But this i want in the interface
[17:19] <lazyPower> suchvenu - that environment variable is set during the relationship context, so it's important ot remember that you should only depend on that during the @hook('relation-name-joined')  joined/changed/departed/broken
[17:20] <lazyPower> if you attempt to reference that environment variable during say, config-changed, its not going to be there
[17:20] <kwmonroe> suchvenu: in a more complicated example -- say, for example, you needed to know *all* the remote units connected to your interface, you could create an "endpoints" method simliar to how the monitor interface does it: https://github.com/juju-solutions/interface-monitor/blob/master/provides.py
[17:23] <kwmonroe> suchvenu: i think lazyPower's suggestion is that you not worry about the remote unit name in the interface, and use it in the reactive layer during a @when '<required>-relation-changed' state is present.
[17:24] <kwmonroe> ugh, sorry, i meant provides.. so like in the db2 reactive layer, @when 'db2-relation-changed'
[17:24] <kwmonroe> echo $JUJU_REMOTE_UNIT, or whatever you need to do with that
[17:24] <suchvenu> The issue i am facing is, I need to get the remote-unit name to create DB and users based on the unit name. If i miss to set accept_license to true and add-relation between db2 and consumer, I get the remote unit name in the reactive layer. But since accept_license was not set the install will not happen
[17:25] <suchvenu> Then I set the accept_license flag and after this, when it comes to relation hooks I am not getting the $JUJU_REMOTE_UNIT name
[17:26] <suchvenu> Before install, when the add-relation was called, it actually goes to the relation hooks and gives the $JUJU_REMOTE_UNIT name
[17:26] <suchvenu> But not after install. So I thot of getting this value from Interface
[17:26] <kwmonroe> ah yeah, so that gets back to what lazyPower was saying.. when add-relation was called, you were in a "db2-relation-[joined|changed]" hook, which is a relation hook, which is why $JUJU_REMOTE_UNIT was available
[17:27] <suchvenu> right
[17:27] <suchvenu> first time i get it
[17:27] <kwmonroe> when you set accept_license, you were in a "config-chagned" hook, which has no remote relation information available
[17:27] <kwmonroe> so you would need to adjust your states to handle the case when both license is accepted && relation is available
[17:27] <suchvenu> But doesn't it go to relation hook again after config-changed ?
[17:28] <kwmonroe> like "@when 'license.accepted' 'db2-relation.joined'"
[17:28] <kwmonroe> then echo $JUJU_REMOTE_UNIT
[17:28] <kwmonroe> the 2nd clause in that @when decorator will ensure it happens in a relation context, so remote unit info should be available
[17:29] <kwmonroe> no, relation hooks may not fire after a config-changed hook, and even if a conifg and relation hook are both set to fire, you have no guarantee which one will happen first
[17:29] <suchvenu> hmm
[17:29] <kwmonroe> that's the nice part about reactive charming.. you can create a combination of states so that it does not matter which happens first
[17:30] <kwmonroe> simply define a method that requires both states -- in this case, license.accepted and db2.ready (or whatever the db2 state is called) -- and you can do both config and relation-related things in there.
[17:30] <suchvenu> ok..
[17:31] <suchvenu> let me try this way and see
[17:31] <kwmonroe> does that help?  if not, please point me to a repo so i can take a look (it doesn't have to be working code :), or paste the reactive code that isn't working to http://paste.ubuntu.com/
[17:32] <suchvenu> Thanks Kwmonroe and lazypower
[17:32] <suchvenu> I will try and let you know
[17:32] <suchvenu> Sure thanks
[17:34] <jcastro_> mthaddon, https://jujucharms.com/docs/devel/tools-charm-tools
[17:35] <cory_fu> kwmonroe, suchvenu, lazyPower: Sorry I'm late to the party, but I'd highly recommend against using $JUJU_REMOTE_UNIT, because it will *only* be valid within a @hook('*-relation-*') handler and almost certainly not in any @when handler.  Instead, you can always get the list of unit names from a conversation with conv.units
[17:35] <lazyPower> ah thats right
[17:36] <lazyPower> cory_fu - as usual, to the rescue ;)
[17:36] <kwmonroe> oh dear -- sorry suchvenu!  don't do that
[17:36] <cory_fu> kwmonroe: I'm also now recommending *against* ever using conv.scope directly.  That was a bad pattern that I started and now regret.
[17:36] <lazyPower> cory_fu - we need some of that knowledge in the docs, if i bug that can I point you at it?
[17:36] <kwmonroe> heh
[17:36] <cory_fu> lazyPower: Yes, please do.  conv.units isn't even in the docs anywhere and definitely needs ot be
[17:37] <cory_fu> lazyPower: I've also been thinking about scrapping the Conversation pattern entirely (or at least hiding it) because it seems to cause more confusion than it saves
[17:37] <jcastro_> aisrael, can you loop back around to this today? https://bugs.launchpad.net/charms/+bug/1562944
[17:37] <mup> Bug #1562944: Please review and add auditd charm as a recommended charm <Juju Charms Collection:New for charmers> <https://launchpad.net/bugs/1562944>
[17:38] <cory_fu> And there is at least one bug now that's damned hard to fix with people relying on conv.scope
[17:39] <aisrael> jcastro_: Yep, I'll hit it again tonight. The AWS test finally ran and passed. \m/
[17:39] <stub> I'd love to have an example of a relation where the leader sets a password that all units set on their relation, cause then I might understand how I can use conversations ;)
[17:39] <jcastro_> does the review queue bot not post immediately to lp when the test passes?
[17:39] <jcastro_> or is it like a nightly thing or something?
[17:39] <jcastro_> all I see on the bug are the failed tests
[17:40] <aisrael> jcastro_: Not sure. I'm going by this: http://review.juju.solutions/review/2620
[17:40] <jcastro_> mthaddon, ^^
[17:40] <jcastro_> aisrael,  thanks!
[17:40] <cory_fu> stub: You've pretty much convinced me that not only are conversations and scopes harder to understand, but they lead to an incorrect mental model of how relations work under the hood.
[17:40] <aisrael> jcastro_: no worries. I'm on the case
[17:41] <mthaddon> jcastro_: thx, will pass on to Tim
[17:42] <stub> cory_fu: I was hoping I'd missed some important fact that was stopping me grokking it :-(
[17:43] <kwmonroe> cory_fu: how would you get the current remote unit name from a globally scoped provides.py?
[17:43] <suchvenu> cory_fu, kwmonroe -> So are ou suggesting me to use conv.units ?
[17:44] <kwmonroe> cory_fu: conv.units gets me all remote (requiring) units, right?  i just want 1 in particular.
[17:44] <cory_fu> stub: The intention originally was to model the progression of states that one unit assigns to another as a conversation, but the asymmetry of how relations actually work in Juju, and the variation in the use-cases led to it ending up being less useful than we'd originally hoped
[17:46] <cory_fu> kwmonroe: When you're dealing with states (@when), there *is* no "current" remote unit.  You could be in a config-changed hook, if that happened to be the last thing that changed to satisfy all of your @when conditions.  All you know is that the state you referenced applies to a set of one or more remote units
[17:46] <cory_fu> suchvenu: Yes, I am recommending that you use conv.units which will be a list of unit names.
[17:50] <suchvenu> But I want only one unit for which I am creating the DB name and user
[17:52] <cory_fu> suchvenu: If you have two services connect to the database, they should both get a database, right?  So, if the timing works out that you are handling two at once, it means you need to loop over them and create a database for each.
[17:53] <suchvenu> But if I have already created for one ?
[17:53] <cory_fu> suchvenu: Unless you only want to create one database per service and the connected service has multiple units?
[17:56] <cory_fu> In that case, you'll need to convert the unit names to a (shorter) list of service names and create one per service.
[17:59] <kwmonroe> how about this cory_fu suchvenu... in the db2 charm, @when 'db2.ready', loop through all units from conv.units, test if user/db/whatever already exists, and if not, create what you need based the data in the current loop iteration.
[18:00] <cory_fu> +1
[18:00] <A-Kaser> I got this warning : charm URL should include a revision
[18:00] <kwmonroe> because i think you're right in that all units connected to db2 will need a user/db/whatever, so just always loop through all of them and create the missing pieces
[18:00] <suchvenu> yes that will work
[18:00] <A-Kaser> is it in metadata.yaml ?
[18:00] <cory_fu> A-Kaser: Where did you get that warning?
[18:01] <A-Kaser> juju bundle proof
[18:01] <cory_fu> Hrm.  I think that's an out-of-date warning
[18:01] <cory_fu> Oh, bundle proof!
[18:02] <cory_fu> A-Kaser: That means that bundles should include specific revisions for charms.  I.e., "charm: cs:trusty/mysql-5" instead of "charm: cs:trusty/mysql"
[18:02] <A-Kaser> it's my owns charms
[18:02] <cory_fu> A-Kaser: That's to ensure that bundles are a set of specific charm revs that are known to work together
[18:03] <A-Kaser> and there are only local, I'm lookig to how publish it
[18:03] <cory_fu> A-Kaser: Really, that only applies to bundles that you want promulgated.  They will work w/o revs, but for promulgated bundles we basically require them to be rev locked
[18:03] <A-Kaser> ok
[18:04] <A-Kaser> so I can add -1 at the end of "charm:" line
[18:04] <cory_fu> A-Kaser: But you can put a bundle in your own namespace, that refers to charms in your own namespace, w/o rev locking them
[18:04] <A-Kaser> and I suppose I will be able to create this revision
[18:04] <A-Kaser> ok ok, I need to check how to publish it
[18:04] <suchvenu> Cory_fu , do you have any example where I can look at conv.units ?
[18:04] <A-Kaser> launchpad use only bzr ?
[18:05] <cory_fu> A-Kaser: Whenever the charm is published to the store (either by having it be automatically ingested from Launchpad, or using the new `charm push` / `charm publish`, it will create the rev
[18:05] <cory_fu> suchvenu: Not off the top of my head, and I have to step away for a few minutes.  I will find one and get back to you shortly, if kwmonroe doesn't find you one first
[18:05] <cory_fu> bbiab
[18:06] <suchvenu> sure
[18:15] <c0s> kwmonroe: cory_fu : a quick question about ArchiveUrlFetchHandler. If I am using in the form of
[18:15] <c0s>   fetcher.install(my_url, my_dest, checksum="deadbeef", hash_type="md5)
[18:15] <c0s> where the checksum and hash type would be coming from ? Assuming my_url is defined in the config.yaml, shall the other two be defined there as well?
[18:15] <c0s> sorry for the silly question
[18:17] <c0s> oh I see - I guess I just can add the checksum to the url itself.
[18:17] <kjackal> cory_fu, kwmonroe, admcleod-, who is where do we set the "namenode.joined" ?
[18:23] <kwmonroe> suchvenu: i don't know of a conv.units example either, but i think in your provides.py, you'd just define a method that does "return self.conversation().units" and then call that method from your db2 layer when license.accepted and db2.ready.
[18:24] <kjackal> cory_fu, kwmonroe, admcleod-, interface:dfs
[18:24] <kwmonroe> yup c0s, you can either have the sum and hashtype as separate config vars (and only call install when all pieces are configured), or stick those onto the url as url?md5=deadbeef
[18:25] <c0s> k, thanks!
[19:24] <coreycb> jamespage, gnuoy, thedac: way past eod for a few of you but rockstar needs this fix if any of you happen to be free to review. https://review.openstack.org/#/c/302427/
[19:47] <beisner> coreycb, do we have full passing on that ^?
[19:48] <coreycb> beisner, no, I'm waiting for a +2 and full recheck
[19:48] <coreycb> beisner, or can the full passing come first?
[19:48] <beisner> coreycb, yah let's get charm-recheck-full passing
[19:48] <coreycb> beisner, ok
[19:48] <beisner> fyi thedac is on hols today/tomorrow
[19:48] <coreycb> beisner, ok thx
[20:28] <rbasak> neiljerram: mysql-5.7 5.7.11-0ubuntu5 has landed in the release pocket now. If you're using the mysql charm though, I think gnuoy's working on that since it broke something there?
[20:36] <magicaltrout> are charms building to the charmstore?
[20:40] <kwmonroe> magicaltrout: wadda you mean by 'building to the charmstore'?
[20:41] <magicaltrout> push charm to LP -> deploy charm to CS
[20:42] <magicaltrout> just trying to unbreak my saiku charm so I pushed an update 50odd minutes ago but I don't see an update in the CS
[20:44] <kwmonroe> magicaltrout: i believe the LP ingestion process is still a thing, but have seen it take an hour(ish).  however, iiuc, if the charm has ever been published with the new "charm push && charm publish" commands, then the LP ingester doesn't look at that anymore.
[20:45] <kwmonroe> magicaltrout: did you push an update to LP for this one? https://jujucharms.com/u/f-tom-n/saikuanalytics/trusty/3
[20:46] <magicaltrout> https://jujucharms.com/u/spicule/saikuanalytics-enterprise/trusty/
[20:46] <magicaltrout> its its up over an hour, i'll return to twiddling my thumbs, i thought it was ~40mins
[20:49] <marcoceppi> magicaltrout: ingestion is broken at best
[20:49] <marcoceppi> magicaltrout: use new charm workflow
[20:50] <marcoceppi> magicaltrout: and help vet our documentation :)
[20:50] <magicaltrout> that involes me doing things
[20:50] <magicaltrout> link me up
[20:51] <marcoceppi> magicaltrout: https://github.com/juju/docs/pull/975
[20:51] <marcoceppi> magicaltrout: https://github.com/marcoceppi/docs/blob/17b54ba8f49d464a0b26b11fab7087705166c6bf/src/en/authors-charm-store.md
[20:52] <marcoceppi> magicaltrout: doc is very much WIP, but feedback on that pull request would be great
[20:52] <marcoceppi> magicaltrout: hope to hvae it finished up by EOW
[20:52] <magicaltrout> k i'll give it a spin
[20:52] <magicaltrout> thanks
[20:52] <kwmonroe> magicaltrout: the nice thing about the new workflow is that you push and it's immediate.. no waiting on an ingestion process to pull
[20:54] <kwmonroe> dang marcoceppi, really nice job on the wip!  that ascii art and pointer description are really helpful.
[20:56]  * thumper chuckles at the name of magicaltrout
[20:56] <thumper> cracks me up
[20:56] <thumper> morning folks
[21:01] <magicaltrout> er right them marcoceppi problem #1
[21:02] <magicaltrout> where do I get a charm exec thats up to date enough to run charm login?
[21:02] <marcoceppi> magicaltrout: ppa:juju/devel and ppa:juju/stable - you need both
[21:02] <magicaltrout> er
[21:02] <magicaltrout> right
[21:04] <magicaltrout> oh I've got a charm in some anaconda dir stomping on my path
[21:05] <magicaltrout> dont' even know what/how that got there
[21:12] <magicaltrout> alrighty then marcoceppi
[21:12] <magicaltrout> says its published to stable
[21:12] <magicaltrout> whats the lag time on the UI?
[21:14] <magicaltrout> because you said its immediate and either its not or I've ballsed up
[21:16] <jrwren> kwmonroe: magicaltrout looks like ingestion run and your saikuanalytics imported: https://api.jujucharms.com/charmstore/v5/changes/published?start=2016-04-07
[21:16] <magicaltrout> that does indeed jrwren
[21:16] <magicaltrout> oh arse
[21:17] <magicaltrout> wrong bloody bzr launchpad login
[21:18] <magicaltrout> okay so
[21:18] <magicaltrout> help me out here ;)
[21:18] <magicaltrout> logged in with charm login
[21:19] <magicaltrout> but its associated me with ~f-tom-n and not spicule
[21:21] <magicaltrout> ah charm whoami
[21:23] <magicaltrout> okay i'm stuck
[21:23] <magicaltrout>  /usr/bin/charm push . cs:~spicule/saikuanalytics-enterprise
[21:23] <magicaltrout> ERROR cannot post archive: unauthorized: access denied for user "f-tom-n"
[21:24] <rick_h_> magicaltrout: what's f-tom-n?
[21:24] <rick_h_> magicaltrout: do you have more than one login?
[21:24] <rick_h_> magicaltrout: can you charm logout?
[21:24] <rick_h_> magicaltrout: or rm -rf ~/.go-cookies
[21:24] <rick_h_> and relogin
[21:24] <rick_h_> using the spicule account
[21:24] <rick_h_> logout support was added recently, /me goes to look
[21:27] <magicaltrout> rick_h_: I don't have 2 accounts, I did rename my launchpad account though
[21:27] <magicaltrout> but as I logged in like 5 minutes ago for the first time, I do'nt see what a logout would do
[21:28] <rick_h_> magicaltrout: well, charm login thinks your ~f-tom-n and you're trying to submit to the user ~spicule which ~f-tom-n isn't able to
[21:28] <rick_h_> magicaltrout: so which one did you have before and which one is the current username?
[21:28] <magicaltrout> yeah, but that was my old launchpad id
[21:29] <magicaltrout> f-tom-n is the old one, and a few weeks ago I changed it to spicule
[21:30] <magicaltrout> dumped my cookies and did it again
[21:30] <magicaltrout> same output
[22:04] <magicaltrout> well then
[22:04] <magicaltrout> in a nutshell i can't publish to my new launchpad ID and ingestion seems knackered, so, I'm snookered
[22:04] <rick_h_> magicaltrout: sorry, meetings wheee
[22:04] <magicaltrout> aye no worries
[22:04] <rick_h_> magicaltrout: yea, well it doesn't support the LP username change.
[22:05] <magicaltrout> so it appears! :)
[22:05] <rick_h_> magicaltrout: there's work to try to find a path forward, but atm it breaks things since those names are the urls everyone uses to deploy production stuff
[22:05] <rick_h_> it's like a username with a published PPA, it blocks username
[22:05] <magicaltrout> rick_h_: but as I already have saiku deployed under spicule and my LP id is now spicule, why can't charm push just use an alternative url
[22:05] <magicaltrout> even if I have to specify it instead of it being default
[22:47] <magicaltrout> `https://bugs.launchpad.net/juju-core/+bug/1567690 I dunno where charm tool bugs go, so I filed it in juju core
[22:47] <mup> Bug #1567690: Can't push charm to my new LP home <juju-core:New> <https://launchpad.net/bugs/1567690>
[23:15] <c0s> does anyone know if bundletester work with juju 2.0?
[23:20] <LiftedKilt> is there a way to tell juju that if maas reports a machine as failed-deployment, have it add another machine and retry the charm deployment on that machine?
[23:21] <LiftedKilt> otherwise if I deploy a bundle with say 9 machines, and one of the machines fails to deploy properly, the whole bundle is in limbo until I manually add a machine and move the units and relationships
[23:25] <rbasak> jamespage, gnuoy: I've filed bug 1567696 and bug 1567695
[23:25] <mup> Bug #1567696: mysql-server-5.7.postinst is influenced by ~/.my.cnf, causing installation hangs <mysql-5.7-transition> <mysql-5.7 (Ubuntu):Triaged> <https://launchpad.net/bugs/1567696>
[23:25] <mup> Bug #1567695: mysql-server-5.7.postinst is influenced by $HOME, causing installation hangs <mysql-5.7-transition> <mysql-5.7 (Ubuntu):Triaged> <https://launchpad.net/bugs/1567695>
[23:25] <rbasak> I suspect this may be related to your charm problems.


[16:33] <Nivex> lovelace: not off hand, no. Sorry.
[16:33] <Nivex> I used the text installer to install Oneiric Xubuntu, and X won't start.
[16:34] <Nivex> It's an nVidia card, but Natty had no problem with it.
[16:59] <Nivex> oh that is an obnoxious bug
[16:59] <Nivex> the unity-greeter on which it depends was failing to start
[16:59] <Nivex> I hand edited the /etc/lightdm/lightdm.conf to point at lightdm-gtk-greeter and it works


[02:08] <sahil> hi, i am having problem in connecting to this IRC through quassel IRC.
[02:08] <sahil> Help me please
[04:47] <apachelogger> apoi: export QT_SELECT=5
[04:47] <apachelogger> ah wrong one, sorry ^^
[06:40] <apachelogger> oh, one week to final it is already
[06:40] <apachelogger> such magic
[06:44] <lordievader> Good morning.
[06:46] <valorie> I thought Riddell said earlier that there would be no RC?
[06:48] <valorie> also apachelogger, I got a neato quote from the sunday paper for you, from Terry Pratchett: Opera happens when a large number of things amazingly fail to go wrong
[06:49] <apachelogger> indeed
[06:50] <apachelogger> as for RC, dunno, maybe it got canceled ^^
[06:50] <apachelogger> would be peculiar though
[06:50] <valorie> Seattle Opera has a new director
[06:59] <Tm_T> release without RC sounds, err, risky?
[06:59] <apachelogger> *shrug*
[07:00] <valorie> the release after an LTS is always a bit chancy, right?
[07:02] <apachelogger> yeah
[07:06] <Tm_T> don't forget that our release would ofcourse be perfect anyway (:
[07:12] <lordievader> That's a given, indeed ;)
[07:19] <apachelogger> dpkg: error processing archive /var/cache/apt/archives/systemsettings-data_4%3a5.0.2+git20140920.1008.0_amd64.deb (--unpack):
[07:19] <apachelogger>  trying to overwrite '/usr/share/systemsettings/systemsettings.kcfg', which is also in package systemsettings 4:<IP_ADDRESS>+git20141015.0514-0ubuntu0
[07:19] <apachelogger> I am going to throw myself of a cliff
[07:20] <apachelogger> why is that stuck at 5.0.2 anyway
[07:20]  * apachelogger squints
[07:21] <apachelogger> ah, I ripped it out
[07:22]  * valorie straps wings onto apachelogger
[07:23]  * bshah imagines apachelogger with his magic hat and wings..
[07:24] <apachelogger> fairy wizard™
[07:25] <valorie> and the hat
[07:25] <valorie> gotta have the wizard hat
[08:02] <apachelogger> oh btw
[08:02] <apachelogger> am I the only one with klipper problems?
[08:02] <apachelogger> doesn't work half th etime
[08:03] <valorie> I had problems too, but I couldn't pin it down enough to file a bug
[08:12] <Tm_T> apachelogger: haven't had any issues
[10:48] <sgclark> morning
[12:08] <Riddell> hi sgclark
[12:08] <sgclark> hiyas
[12:29] <tazz> tried upgrading a fresh install from kubuntu-14.04-desktop-amd64.iso to 14.10, failed with the following errors ==> http://pastebin.com/Etggx6Pi
[12:36] <BluesKaj_> Hiyas all
[12:36] <sgclark> hiyas
[12:37] <BluesKaj_> what's up today, sgclark ?
[12:39] <sgclark> not much here
[12:43] <BluesKaj_> ok, think there might be a bug in cups with a network printer connected to a router via usb. The printer seems to be recognized, but is always "in use" when trying to print.
[12:45] <apachelogger> ubuntu-bug cups
[12:48] <BluesKaj_> ok apachelogger , collecting info now, thanks
[13:25] <shadeslayer> Riddell: apachelogger kdeconnect upstream author wants a new kdeconnect version in
[13:25] <shadeslayer> but it has new features and stuff
[13:25] <shadeslayer> reckon we can put it in backports?
[13:25] <shadeslayer> or just upload to utopic
[13:31] <soee> shadeslayer: does it work woth Plasma5 systray ?
[13:31] <soee> *with
[13:33] <shadeslayer> not that I know of
[13:34] <Riddell> shadeslayer: FFe it?
[14:03]  * Sick_Rimmit_Test ooo testing testing testing tum tee tum tum ...
[14:27] <Riddell> Sick_Rimmit_Test: what ye testing?
[14:27] <Sick_Rimmit_Test> Riddell: Oooo secret apt repo... stuff
[14:28] <Sick_Rimmit_Test> Riddell: Working really well so far, 2 days using in anger as my desktop at work, looks good. I've had no problems sofar
[14:29] <Riddell> great
[14:31] <Sick_Rimmit_Test> Riddell: I'll keep runing it tomorrow, but to be fair I think the build is good. Where you planning to release in 14.10
[14:32] <Riddell> no too late for 4.14.2, it'll just be in kubuntu-ppa updates and then we'll SRU it
[14:32] <Sick_Rimmit_Test> Riddell: OK, that's fine
[14:33] <Sick_Rimmit_Test> While I think of it fine folks in kubuntu-devel
[14:34] <Sick_Rimmit_Test> I put a tech podcast together atrandom.org.uk
[14:34] <Sick_Rimmit_Test> I would like to get a Kubutnu developer on as a guest to talk about becoming a kubuntu developer
[14:34] <Sick_Rimmit_Test> ping me if you would be up for doing this
[14:35]  * Riddell nudges sgclark in the direction of Sick_Rimmit_Test
[14:44] <Sick_Rimmit_Test> sgclark: Hi Scarlet, would you be interesting in doing a Google Hangout wit me
[14:47] <sgclark> umm I am not a developer yet
[14:47] <Riddell> yes you are!
[14:47] <Riddell> we can do it together if you like
[14:48] <Sick_Rimmit_Test> take a look at atrandom.org.uk
[14:48] <sgclark> when is this? I am going out of town this weekend
[14:48] <Sick_Rimmit_Test> I do this with John, and Jackson.. both nice guys
[14:48] <Sick_Rimmit_Test> plus I can also pick your brains to help me get my skills in place too
[14:48] <Sick_Rimmit_Test> Oh we can arrange it to suit.
[14:48] <Sick_Rimmit_Test> Can be in November if you like
[14:49] <sgclark> Ok I am game if Riddell is
[14:49] <Riddell> awooga
[14:50] <sgclark> anytime but this Saturday -  Monday
[14:50] <Sick_Rimmit_Test> Awesome
[14:50] <sgclark> I otherwise have no life really haha
[14:50] <Sick_Rimmit_Test> Do you guys have G+ accounts ?
[14:50] <Riddell> yes
[14:51] <sgclark> yeah
[14:51] <Riddell> how about friday after the release?
[14:51] <Riddell> a week tomorrow
[14:51] <sgclark> what time is the most important, so I can not be in my jammies haha
[14:51] <Sick_Rimmit_Test> Oo.. How about a week today, at which is our next show
[14:52] <Sick_Rimmit_Test> It's at 9.30pm UK Time
[14:52] <Riddell> that should be ok, release should be done by then
[14:53] <sgclark> ahh yeah that is afternoon for me, I am safe
[14:53] <Sick_Rimmit_Test> OK Grrrrrreat!!
[14:53] <Riddell> Mamarok: what is "gateway/shell/kde"?
[14:56] <Sick_Rimmit_Test> Are Riddell and sgclark on Google+, if so can you ping me your G+ names.
[14:56] <Riddell> jonathan riddell
[14:58] <Sick_Rimmit_Test> OK Cool so I am Rick Timmis will add you to my circles
[15:02] <sgclark> Sick_Rimmit_Test: https://plus.google.com/+ScarlettClark
[15:03] <Sick_Rimmit_Test> Superb, will add you both and then send you invites to the show
[15:03] <sgclark> ok
[15:03] <sgclark> suppose I outta update my profile someday
[15:06] <seaLne> some thing i noticed when trying plasma 5 was that after installing it and rebooting lightdm was trying to use last session which just left you with just the 4.14 or lightdm background after logging in which resulted in it appearing to me that 5 didn't work at all which was disapointing and may have put others off. rather than when i changed manually to a plasma session from the login i got lots of
[15:06] <seaLne> nice shiny plasma 5 working. not sure if there is any way to fix that. sorry if this has already been seen before
[15:07] <seaLne> i guess its a failure on lightdm's part
[15:08] <seaLne> "well i did what you told me to and run stuff that isn't installed anymore"
[15:11] <Riddell> seaLne: mm that's interesting, I havn't thought about that but it probably is a problem
[15:12] <Riddell> seaLne: reported bug 1382096
[15:15] <seaLne> thanks, i wasn't too sure what too blaim :-)
[15:18] <seaLne> if lightdm had complained that it couldn't run plasma 4 or some related error that would have been a lot more obvious what the problem was
[15:20] <seaLne> but i guess this is all down to legacy X workings
[15:23] <Riddell> hmm shouldn't be, it should check if the binary is there
[15:23] <Riddell> I'm about to test a plasma 4 -> 5 upgrade, will look out for it
[15:27] <seaLne> that was on a few weeks old fresh install of utopic
[15:28] <seaLne> with clean  ~
[15:33] <Riddell> seaLne: just did a new install of plasma4 image then installed plasma5 and it all worked great
[15:34] <Riddell> maybe I should have logged out of plasma 4 before installing plasma5, I didn't see it saving the xsession anywhere
[15:34] <Riddell> yeah I had no ~/.dmrc so maybe it didn't have that issue
[15:38] <Riddell> and sddm not working at all
[15:39] <Riddell> come back d_ed, sddm needs your love!
[15:39] <Riddell> seaLne: how did you reboot/log out after installing plasma 5?
[15:40] <d_ed> what's up with SDDM?
[15:41] <Riddell> d_ed: meh doesn't work if you have a plasma 4 kubuntu install and install plasma 5, and sddm.log still not wanting to show much
[15:41] <d_ed> expand on "doesn't work"
[15:41] <d_ed> if you change the theme in the config to "Maui" does it work?
[15:41] <Riddell> it's running according to ps -ef but nothing is on screen
[15:45] <d_ed> what's running
[15:45] <d_ed> sddm or sddm-greeter?
[15:47] <seaLne> Riddell: after installing 5 shutdown/logout wouldn't work so did sudo reboot
[15:47] <Riddell> d_ed: sddm, X and sddm_helper
[15:47] <Riddell> seaLne: yeah, that'll be another bug we'll want to fix before 15.04
[15:48] <Riddell> or I guess the normal release upgrade tool will offer a reboot for us there
[15:51] <seaLne> should it have switched to sddm? i thought i had seen that being installed but never got any select a login manager choice and i still have lightdm
[15:52] <Riddell> d_ed: setting sddm.conf makes no difference, still blank screen
[15:52] <Riddell> [General]
[15:52] <Riddell> CurrentTheme=maui
[15:52] <Riddell> seaLne: yes that was puzzling me too why it was missing but since sddm is broken on installing plasma5 I guess it's for the best for now
[15:54] <seaLne> oh well :)
[15:54] <d_ed> so this is the standard ISO then enabling the PPA to plasma 5 stuff?
[15:54] <Riddell> d_ed: yep
[15:55] <Riddell> d_ed: using plasma5 iso and sddm works fine, at least it did last week maybe I should verify that
[15:55] <Riddell> nothing unusual in sddm.log http://paste.kde.org/pgrhrz1qc
[15:56] <Riddell> qt4 and 5 correctly set to breeze theme, gtk 2 and 3 both set to oxygen
[15:56] <Riddell> which is better than being set to nothing which is what happens if you install plasma5 directly
[15:58] <d_ed> there's no crazy path changing scripts in the plasma 5 iso?
[15:58] <Riddell> d_ed: path of what?
[15:59] <d_ed> anythign.
[15:59] <d_ed> it's weird that code works in once place, but not another.
[15:59] <d_ed> you're using the same version of SDDM in both ISOs?
[15:59] <Riddell> only plasma5 iso has sddm on it
[16:00] <Riddell> normal plasma4 iso has lightdm then sddm gets installed if you install plasma5 from ppa
[16:00] <shadeslayer> Riddell: might want to update sddm from debian git btw
[16:00] <shadeslayer> it has a few PAM fixes
[16:00] <d_ed> and SDDM is in this plasma5 PPA?
[16:00] <Riddell> d_ed: yes
[16:01] <Riddell> shadeslayer: ack
[16:04] <d_ed> shadeslayer: yes please
[16:06] <shadeslayer> d_ed: huh?
[16:07] <shadeslayer> d_ed: and fix your bouncer :p
[16:08] <bshah> yeah.. kde bouncer is crazy today...
[16:09] <sgclark> oh I thought it was me heh
[16:11] <Riddell> what is "gateway/shell/kde" ?
[16:11] <bshah> Riddell: kde bouncer...
[16:12] <bshah> Riddell: https://community.kde.org/Sysadmin/BNC
[16:12] <Riddell> thanks
[16:15] <Sick_Rimmit_Test> Riddell: Hi is this you https://plus.google.com/u/0/101611126337846769384/about
[16:16] <Riddell> um, no
[16:16] <Riddell> how strange
[16:16] <Riddell> Sick_Rimmit_Test: https://plus.google.com/+JonathanRiddell/posts is me
[16:17] <Sick_Rimmit_Test> Great.. glad I checked
[16:26] <d_ed> shadeslayer: what's wrong with my bouncer?
[16:26] <shadeslayer> timeouts
[16:27] <shadeslayer> timeouts everywhere
[16:27] <d_ed> my plane is delayed by an hour :(
[16:27] <bshah> :D
[16:27] <d_ed> bshah: you are not meant to be happy at my misfortune.
[16:27]  * d_ed adds bshah to his hit list.
[16:28]  * sgclark giggles
[16:28] <d_ed> you too
[16:28] <d_ed> depending on who you were giggling at
[16:28] <sgclark> lol
[16:29]  * yofel passes d_ed a cup of coffee
[16:29] <d_ed> thanks. I got myself a "Caramel Mochiatto"
[16:29] <d_ed> I don't think it's even a word
[16:29] <d_ed> it doesn't sound like one.
[16:29] <sgclark> mmm
[16:30] <yofel> first time I hear of a mochiatto..
[16:30] <d_ed> and it was one of those coffee places where you can't just say medium like a normal person, you have to say "grande"
[16:30] <d_ed> which as soon as you open your mouth makes you fear that you come accross as a completely pretentious prick even though that's what it says on the sign
[16:30] <sgclark> lol
[16:30] <d_ed> so you panic, and try and say "medium" at the same time
[16:30] <d_ed> then just collapse on the counter in a pool of sweat.
[16:30] <sgclark> truth
[16:31] <yofel> :D
[16:35] <Riddell> this is why I don't buy coffee
[16:36] <Riddell> sddm working good on plasma5 image
[16:36]  * genii makes another pot of utility coffee
[19:44] <Riddell> Sick_Rimmit: is the podcast available live to watch or something later? video or audio?
[19:44] <Sick_Rimmit> Riddell: Sure, all and both..
[19:44] <Sick_Rimmit> Riddell: Audio from website, or rss. Video on our YouTube Channel
[19:44]  * sgclark crumbles under pressure
[19:45] <Sick_Rimmit> sgclark: relax we've only got 4 followers :-)
[19:45] <Sick_Rimmit> Oh and I am really nice, it's not going to Paxman, it will be really fun
[19:46] <sgclark> :)
[19:46] <Sick_Rimmit> We even have show guest beer
[19:46] <Sick_Rimmit> it's bring your own, and tell us about it
[19:47] <sgclark> nice :) will be to early to drink here, but will have one in spirit
[19:48] <Sick_Rimmit> We're just going chat about the release, about getting involved in Kubuntu, and wrap it up with telling others how they can find us, join in and get involved
[19:48] <Sick_Rimmit> John, and Jackson are both cool guys..
[19:50] <Sick_Rimmit> Here you go
[19:50] <Sick_Rimmit> http://www.youtube.com/watch?v=BKzknavDD9M
[19:50] <sgclark> cool, I am a bit umm shy, but I have met Riddell at akademy so I won't feel so scared lol
[19:50] <Sick_Rimmit> Jump in say 20 minutes, and watch a couple of minutes you'll see its all good
[19:51] <Sick_Rimmit> sgclark: it's all good :-)
[19:51] <Riddell> Sick_Rimmit: I think having some questions sent to us in advance would be good
[19:52] <Sick_Rimmit> Riddell: Yes, we have some notes and I will ensure that you get a share of them
[19:52] <sgclark> yes! please :)
[19:54] <sgclark> sheesh alot of bugs coming in, did I miss testing that is being done today?
[20:06] <soee> hiho
[20:06] <sgclark> hiyas
[20:41]  * Sick_Rimmit returns from collecting Rhiannon from
[20:41]  * Sick_Rimmit guides


[21:00] <MAAS_madness> hey folks.. not many people in here so this may not go anywhere but I am looking for advice on MAAS..  specifically getting it to work in an air-gapped network.
[21:02] <MAAS_madness> I am sure it is something i am missing & has to do with the repo i set up because it works when I connect everything back to the internet..  Once I switch over to the local repo it fails on cannot download packages


[02:26] <jtatum> http://changelog.complete.org/archives/7562-i-introduced-my-5-year-old-and-2-year-old-to-startx-and-xmonad-theyre-delighted
[02:26] <darthrobot> Title: [I introduced my 5-year-old and 2-year-old to startx and xmonad. They’re DELIGHTED! | The Changelog]
[02:27] <pleia2> jtatum: ended up having to work late due to meetings this morning, so no Ubuntu Hour for me, hope you all are having fun :)
[02:27] <jtatum> no worries, pleia2 :) see you another time.
[10:26] <scientes> FREEDOM!!!!!!!!!!!!!!!!!!!!!
[10:26]  * scientes just successfully booted with coreboot ;)
[14:33] <bkerensa> morning Californians
[15:05] <greg-g> oh, and now scientes is gone
[18:40] <philipballew> pleia2, I gotta do some post meeting stuff, but don't fear. Its in a list of things to do when I am back in the Country of California...
[18:41] <pleia2> thanks :)
[18:41] <philipballew> I have a list titled Ubuntu Stuff. All will be done in due time. Now if only my plane would have wifi...
[19:00] <bkerensa> Man Robert Scoble has a magic of sorts :)