[01:03] <john_barleycorn> Anyone here know how/is it possible to colorize text in a wiki page?
[15:01] <elfy> o/
[15:02] <not_found> \o
[20:46] <LHammonds> I suppose the Wiki login is separate from the Forum login?
[20:48] <MrChrisDruif> I suppose
[20:50] <LHammonds> Well, I seem to be stuck trying to create a dag-gum launchpad account.  I fail miserably at the recapcha. (I don't usually have such problems)
[20:51] <LHammonds> Typing my dag-gum password 12 times now along with 6 recaptchas.  Starting to think it is broken.
[20:51] <MrChrisDruif> Maybe reloading the entire page?
[20:51] <MrChrisDruif> It rare but sometimes is the captcha out-of-sync with the page
[20:51] <MrChrisDruif> It's*
[20:53] <LHammonds> Nope.  It's broke.  CTRL+F5 did not fix it.  The recap images are almost perfectly clear so I *know* I typed a combo correctly at least 2 times now.
[21:00] <LHammonds> It worked when I used IE (which caused me to puke a little in my mouth)
[21:12] <LHammonds> Most wiki's I have worked with make use of categories to help find pages.  What/where are the categories?  How are pages arranged?  How do people find various pages on the wiki?


[01:47] <AskUbuntu> Juju on AWS t1.micro (or other) reserved instances | http://askubuntu.com/q/307954
[02:15] <virusuy> hi guys !
[10:46] <BaribalWrk> Hi. I've gotten access to a few racks with rather impressive machines that run KVM/libvirtd. Is there a way to integrate juju in this environment?
[10:48] <Baribal> Also, so far they're only deploying CentOS VMs here, but AFAIK that shouldn't be an issue as juju downloads images itself anyways.
[11:29] <stub> Is the charm cache on the bootstrap node, or in the control bucket?
[13:10] <marcoceppi> stub: I think it's in the control bucket
[13:12] <jhf> hey all - question on best practices. my charm installs a service whose filesystem layout is different depending on version. so for example, if I install to /opt/liferay, then in one version, its "home dir" is /opt/liferay/v1 but in the next version it'll be /opt/liferay/v2.  So I am saving the value of /opt/liferay/v1 into a dot file so that in a future upgrade I can discover the filesystem layout of the "old" version during the upgrade. I considered making i
[13:12] <jhf> part of the charm config but that didn't feel right because this is not a user "tunable" and if one were to change it, it would break badly. so is it cool to save variables in this way during the install so that they can be available during an upgrade?
[13:14] <marcoceppi> jhf: absolutely. A lot of charms that need to keep track of low level data like that typically put them in a dot file in either the services home (not really a good idea in this case) or the $CHARM_DIR
[13:14] <jhf> hmm.. good idea re: charm dir, but when I upgrade the charm, will those files remain during the upgrade of the actual charm unit files?
[13:15] <marcoceppi> jhf: yes, upgrade-charm only overwrites files that are extracted from the new charm. So any files created by the charm are not touched
[13:16] <stub> marcoceppi: Thought so. I discovered the weirdness I was seeing was update-charm deploying revisions I was working on yesterday, despite a fresh bootstrapped environment.
[13:16] <jhf> nice.. I like that better than putting it in the service dir. I'll go with that, thanks!
[13:19] <jhf> btw - I tried to use the "juju debug-hooks" command, but it tries to do fancy things via the terminal, and gets really messed up on a mac: I am running ubuntu in a virtual box vm, so I ssh to the virtual ubuntu instance, and then run juju debug-hooks and my terminal gets all wonky, making juju debug-hooks unusable :(
[13:19] <jhf> I don't think this is juju's fault but just thought I'd mention it. haven't played with terminal settings yet to try and fix it.
[14:42] <jhf> hey all - I am using a local repository for charm testing - I am editing the files and then running juju upgrade-charm but it keeps using old, cached copies of the files so the resulting charm that is copied to the container doesn't have the updates.. is there a way for it not to use the old, cached charm files?
[14:55] <_mup_> Bug #1191030 was filed: Provisioning agent stops working <juju:New> <https://launchpad.net/bugs/1191030>
[15:41] <marcoceppi> jhf: You need to either increment the revision number or use the -f flag to force an uprade
[16:21] <jhf> woo! it works! now time to re-learn bzr to push the fixes :)
[16:38] <marcoceppi> Charm school in 20 mins!
[17:00] <marcoceppi> Charm School is now! http://ubuntuonair.com/
[17:07]  * FunnyLookinHat is watching :D
[17:07] <FunnyLookinHat> and taking notes
[17:20] <jhf> Is there a way to stop a service (not destroy-service)?  That is, something that triggers the stop hook, but otherwise leaves things as they were?
[17:21] <FunnyLookinHat> marcoceppi, select the gray box and double click the color next to "Fill" in the bottom left :)
[17:22] <FunnyLookinHat> But use the arrow tool to select it.
[17:37] <FunnyLookinHat> off-topic question for the charm school today, but I can't find documentation on how to fire a custom hook on a charm that's already deployed
[17:38] <jhf> https://juju.ubuntu.com/docs/policy.html#license refers to the list of OSI-approved licenses at http://opensource.org/licenses/
[17:44] <jhf> question!! Is there a way to stop a service (not destroy-service)?  That is, something that triggers the stop hook, but otherwise leaves things as they were?
[17:44] <FunnyLookinHat> jhf, That's what I'm aiming for...  :)
[17:44] <FunnyLookinHat> with a custom hook
[17:51] <FunnyLookinHat> Ah ok - so you'd write it into config-changed
[17:51] <jhf> Is there a reason there's no charms for any release other than precise?  I assume I'd start with the latest Ubuntu release, but didn't see any raring charms
[17:54] <sarnold> jhf: I'd expect saucy charms to pick up, as people prepare for 14.04 and assume it'll be the next LTS release
[17:54] <jhf> ah ok, thanks
[17:55] <sarnold> jhf: for my part, I did my (very few) charms on precise, because it seemed the most well-tested, and intended to port them to quantal; but I never got around to it, and next thing I know, raring is out...
[17:55] <FunnyLookinHat> Ok - so to do it in juju-core, you would have to fire a config change and handle the flag within config-changed
[17:55] <sarnold> .. and it's easier to ignore two broken things than one broken thing :)
[17:55] <jhf> :)
[17:56] <sarnold> jhf: but I'm in a different position, I don't have hundreds of machines to support, perhaps those people that do are just targetting the newest release that they actually have deployed in their environments
[18:01] <fred> hi
[18:02] <Guest89610> #nick fred
[18:02] <Guest89610> i forgot how to use irc :(
[18:02] <sarnold> Guest89610: /nick
[18:03] <sarnold> Guest89610: but, pick a different nickname, fred must be protected, it'll just change you away again :)
[18:03] <Guest89610> thamks man
[18:03] <Guest89610> *tnx
[18:03] <Guest89610> ah i see. okay
[18:03] <fred1234> fred1234 will do :P
[18:04] <fred1234> how ya all :P
[18:04] <fred1234> how's ubuntu?
[18:09] <fred1234> hi
[18:09] <fred1234> where can i get started?
[18:10] <fred1234> i mean, the flirst v
[18:10] <fred1234> i mean, the first vid of juju?
[18:10] <fred1234> i had not updated or been active with ubuntu lately. i want to catch-up.
[18:11] <FunnyLookinHat> So - if I were to deploy on AWS - is there a way to deploy to two separate regions at once?
[18:11] <fred1234> :-(
[18:12] <FunnyLookinHat> fred1234, I'd probably just read through this stuff: https://juju.ubuntu.com/docs/
[18:12] <FunnyLookinHat> Just go through the table of contents - it paints a picture pretty well and gets you into stuff quickly
[18:13] <fred1234> ah okay, fun :) this coyld help. been using ubuntu since 6.xx, but im not a c or c++ expert :(
[18:14] <fred1234> but had manage through terminal somehow lols :P
[18:14] <fred1234> *could
[18:14] <fred1234> tnx again. i'll carry-on
[18:18] <fred1234> #juju: i'm just finish with the home page. also ventured reading en.wiki -> http://en.wikipedia.org/wiki/Juju_%28software%29
[18:20] <fred1234> nice, like service ilnterfacing and concurrency, and cloukd... still wondering what services and how does it provide those....
[18:20] <fred1234> ... i'll read further lols
[19:08] <marcoceppi> FunnyLookinHat: no, not currently. Cloud (and region) federation is on the roadmap
[19:08] <marcoceppi> fred1234: check out jujucharms.com for a list of charms (services) we have currently!
[19:09] <FunnyLookinHat> marcoceppi, Ok - my worry is that AWS has had outages in the past, and without rackspace support I feel as though we're having to make a bad decision  :-/
[19:10] <marcoceppi> FunnyLookinHat: yeah, it's been on the roadmap for a while. I think with containerization and local provider being worked on that cloud federation will be ready by 14.04. It's kind of a requirment to make the tool truely "production" ready
[19:10] <FunnyLookinHat> yeah - I'm keeping a close eye on the containerization stuff  :)
[20:14] <jake> tes tes
[20:35] <Mage_Dude> How can you delete a node/service if juju status doesn't work?
[20:35] <rnathuji> Hi folks, I have a quick question on bootstrapping juju
[20:36] <rnathuji> I've deployed MaaS and enlisted 3 ARM nodes (shown as ready state).  juju bootstrap fails with "No matching node is available". I did try doing a set-constraint arch=armhf, but then it complains that it's not bootstrapped. Does the boostrap node have to be x86?
[20:40] <rnathuji> nm, figured it out
[20:40] <Mage_Dude> You wouldn't happen to know how to delete a node from maas would you?
[20:42] <rnathuji> I haven't tried it, but it looks like the UI has a "Delete node" button on if you click on the node name from the list of all nodes. Or is that itself not working for you?
[20:43] <Mage_Dude> No, you can't do it that way because the node has been allocated. However, juju status doesn't work so you can't unallocate the node! The *only* way I've found to do it is to wipe the MAAS db and recommission all the nodes again.
[20:44] <rnathuji> Can you use maas-cli to release the node and then delete it?
[20:45] <rnathuji> (I'm not even sure what exactly release does, just saw it on the maas-cli options list)
[20:45] <Mage_Dude> I'll have to look at it
[20:50] <Mage_Dude> That's bizzare. The cli only lists one node as allocated, but the gui shows two.
[20:59] <Mage_Dude> sudo maas-cli nodes release <some-id-value> ... why is that incorrect syntax?
[21:02] <Mage_Dude> Grrr
[22:13] <paraglade> marcoceppi: Just got done watching the vid for the charm school today and wanted to know if I heard you correctly say that we could submit are charms to GitHub.
[23:03] <Mage_Dude> Is maas+juju actually functional or is it a late April Fools joke?
[23:09] <Mage_Dude> So, maas doesn't do anything other than provision machines. Then you have to ssh into one of the provisioned machines and actually bootstrap juju there?
[23:10] <sarnold> Mage_Dude: that doesn't sound right..
[23:10] <sarnold> I don't have enough free hardware laying around to try out maas, but the maas provider for juju should just let you juju bootstrap ; juju deploy ...
[23:11] <Mage_Dude> sarnold: I wish. juju bootstrap (Yay kittens!) juju status (I will throw ambiguous errors!)
[23:12] <sarnold> heh :(
[23:12] <Mage_Dude> I can ssh directly into a 'provisioned' node with the ssh key generated. However, I try juju status and get an ssh key error. That makes no sense.
[23:12] <sarnold> Mage_Dude: it's true that juju status often passes up an opportunity to show something more meaningful from a log file. status is hard to capture in the few states available. :(
[23:14] <Mage_Dude> And it's so great when maas is trying to provision two nodes to do the same thing because it can't actually bootstrap/setup the node. Any thoughts on why my perfectly valid ssh key is being rejected?
[23:20] <m_3> paraglade: yeah, we can handle PRs, they're just a little more manual of a process until we get some things changed around
[23:20] <m_3> paraglade: I'd recommend pinging me or marcoceppi directly when you've submitted one... at least for the next few weeks
[23:38] <bkerensa> jcastro: will local environment work by OSCON? :)
[23:56] <m_3> bkerensa: shit, don't remember... jorge'd probably know
[23:56] <m_3> he's out today
[23:57] <bkerensa> m_3: ok just wondering were planning Juju demo at the booth and its either local enviroment or rackspace cloud neither of which worked last time I checked :P
[23:57] <bkerensa> m_3: unless jorge is expensing AWS :)
[23:57] <m_3> :)
[23:57] <m_3> which conference?
[23:59] <bkerensa> m_3: the one you will be at in July
[23:59] <m_3> bkerensa: awesome
[23:59] <bkerensa> :)


[00:43] <trippeh> my seagates are like that, never caused issues
[00:43] <trippeh> as far as I understand, modern drives are so dense they are correcting all the time.
[00:45] <trippeh> as long as you dont have any pending or reallocated sectors it is prob fine
[01:03] <drab> trippeh: thanks for the data point
[01:03] <drab> trippeh: the output on those seagate is weird and very diff than my HGST or any other disk I've seen really, tyhere's now raw data table
[01:04] <drab> so I can't see the reallocated sectors for example
[01:04] <drab> the link above suggested looking at "Elements in grown defect list: 0"
[01:05] <drab> and several others did the same
[01:05] <drab> these are seagate constellations btqw
[06:18] <cpaelzer> While I'm not up to speed yet I wanted to mention that today is again Bug Squashing Day https://wiki.ubuntu.com/ServerTeam/BugSquashingDay
[06:18] <cpaelzer> chair likely is just me for now
[06:18] <cpaelzer> rbasak: are you around already?
[06:52] <lordievader> Good morning
[06:59] <cpaelzer> hi lordievader, good morning to you as well
[07:12] <Deeps> hiya, is there a way to keep ubuntu from changing /home/$USER/.bash_history ownership back to root on apt upgrade / reboot, and purging the contents?
[07:12] <Deeps> running ubuntu 16.04.2 xenial
[07:13] <Deeps> i've manually reassigned ownership of that file to the user a couple of times, but after a reboot it seems to go back to root and have been blanked
[07:14] <sarnold> Deeps: I have never once seen that.
[07:14] <sarnold> Deeps: what have you installed that didn't come from the archive?
[07:16] <sarnold> Deeps: have you done any funny configuration of ~/.bashrc or ~/.bash_profile? any funny pam modules? any funny /etc/profile or /etc/profile.d/ games?
[07:16] <Deeps> best i can tell, nothing particularly exciting on there at all
[07:16] <Deeps> http://paste.ubuntu.com/24458832/
[07:17] <sarnold> looks pretty normal
[07:20] <sarnold> Deeps: you could install auditd and add a file watch rule on the file. once auditd is installed, edit /etc/audit/audit.rules and add a line -w /home/deeps/.bash_history -p wa
[07:20] <sarnold> Deeps: then /var/log/audit/audit.log would contain information on the process that modified the file
[07:21] <Deeps> http://paste.ubuntu.com/24458844/ like that?
[07:22] <sarnold> looks good; I think now systemctl restart auditd.service
[07:22] <Deeps> timestamping in the log file isn't very friendly, heh
[07:23] <sarnold> no it is not :)
[07:23] <Deeps> looks like it's working, i manually changed it back to ownership of me and got this in the logs http://paste.ubuntu.com/24458852/
[07:24] <Deeps> will see what resets it next time, thanks for the help
[07:24] <sarnold> great, good idea to test right away
[07:25] <sarnold> aureport -f looks like a friendlier output view. neat.
[07:25] <Deeps> realised it's not a reboot that's doing it, as the box has been up 100 days and the bash history only got reset in the last week
[07:25] <Deeps> oh that is nice, cheers
[07:36] <lordievader> Hey cpaelzer, how are you doing?
[07:48] <cpaelzer> lordievader: good enough to complain as I always do :-)
[08:05] <lordievader> cpaelzer: Good, good :)
[08:08] <funabash1> hey guys how can i get more info about this process: tcp        0      0 <IP_ADDRESS>:5005          <IP_ADDRESS>:*               LISTEN      11500/6
[08:10] <cpaelzer> funabash1: 11500 should be the pid
[08:11] <cpaelzer> funabash1: so look around at things like
[08:11] <cpaelzer> ps axlf | less (search for 11500 in there)
[08:11] <cpaelzer> ls /proc/11500/* - ususally comm, exe and stat* are interesting there to start with
[08:19] <funabash1> cpaelzer: check this please, https://pastebin.com/ePPGe532
[09:07] <cpaelzer> funabash1: back now, reading
[09:09] <cpaelzer> funabash1: so the process is your sshd it seems
[09:09] <cpaelzer> not the common port for ssh but well
[09:09] <cpaelzer> funabash1: OTOH you might recheck if you still want to look for 11500, in case the pid just got reused by sshd
[09:10] <cpaelzer> funabash1: the first you posted was netstat output right?
[09:47] <rbasak> cpaelzer: yes, but the electrician's here so I may disappear suddenly :-/
[10:20] <funabash1> cpaelzer: i did kill it
[10:32] <rizonz> this is so strange,m preseeding servers using a 64bits only server cannot find some packages
[10:32] <rizonz> but they are there in 64 bits
[10:54] <Aison> is it possible to remove dash and only use bash?
[10:55] <ikonia> possible yes, sensible no
[10:55] <ikonia> why not just use bash where you want,
[10:58] <Aison> k
[12:27] <rbasak> cpaelzer: add bug 1683237 to your list of why you should have core dev please :)
[12:28] <cpaelzer> hehe, yeah correct
[12:30] <cpaelzer> xnox: are you Mr. systemd now?
[12:30] <xnox> cpaelzer, probably....
[12:30] <cpaelzer> enough commitment :-)
[12:31] <cpaelzer> xnox: fyi I have come to this while triaging server bugs (and duped something onto it) but wanted to make you aware of bug 1624317
[12:32] <cpaelzer> reading the comments there it seems that might get some extra hot-ness now that zesty is releases with systemd-resolved
[12:32] <xnox> cpaelzer, my networking know-how is low; thus most of the resolved/networkd bugs are beyond me =/ i do my best, but some help in that area would be good.
[12:33] <xnox> in like trianging and telling what things do. I can write code and send it upstream, but e.g. i have never knowngly ran split-horizon DNS or how that supposed to work correctly.
[12:35] <cpaelzer> me neither, I just happened to follow the "dns leak argument" in the other bug until I realized they were the same
[12:46] <cpaelzer> TafThorne: thanks for starting to verify the logrotate issue on Xenial
[12:46] <cpaelzer> TafThorne: do you think you can do the other releases as well over the next few days?
[12:46] <TafThorne> cpaelzer: No problem.  I'll need to fire up some fresh VMs after finding install images to do the others.
[12:47] <cpaelzer> TafThorne: no pressure, just wanted to know if that task is with you
[12:47] <cpaelzer> TafThorne: thank you in advance
[12:49] <TafThorne> cpaelzer: I should be able to install a Trusty and Yakkety Vm... although I might also have a Trusty PC somewhere here that I could test on easily enough.  That would be faster.
[12:50] <ahasenack> TafThorne: have you tried lxd instead of vms?
[12:50] <TafThorne> Never before.  I could try that
[12:50] <ahasenack> it's even faster
[12:51] <ahasenack> TafThorne: what's your base distro?
[12:51] <ahasenack> where you work?
[12:52] <ahasenack> TafThorne: http://pastebin.ubuntu.com/24459990/
[12:53] <ahasenack> then import your ssh key, and you can ssh into it
[12:59] <TafThorne> ahasenack: 16.04
[12:59] <TafThorne> ahasenack: Basingstoke, UK
[12:59] <ahasenack> TafThorne: should work just fine
[13:00] <TafThorne> ahasenack:cool thanks.  That would be much faster.
[13:01] <TafThorne> ahasenack: Can I go down as well as up?  So `lxc launch ubuntu:trusty` or somilar?
[13:01] <ahasenack> TafThorne: yes, even precise
[13:01] <ahasenack> or debian
[13:01] <ahasenack> or many others
[13:06] <ahasenack> TafThorne: if this is the first time you are installing lxd, the only gotcha is that you have to add yourself to the lxd group before using the commands, which means a logout/login sequence or some other trick
[13:13] <TafThorne> ahasenack: thank you for the warning.  I have a terminal installing the client.  I'll add myself to the group now.
[13:15] <TafThorne> (i'll have to remember the syntax for that before I add a user named TafT to a a group named useradd but I can work that out with GOogle in a few seconds)
[13:19] <ahasenack> I use gpasswd -a <user> lxd
[13:19] <TafThorne> I have gone with `usermod -a -G lxd <user>`
[13:21] <TafThorne> Should be the same result.  I'll not try and fancy jumping though hoops.  I will just `sudo login` as me again in a terminal.  That should be enough to confuse me tomrro wwhen I look at the console agian.
[13:22] <TafThorne> `groups` suggests I am added. Time to follow he paste.
[13:25] <TafThorne> ahasenack: That was quite quick to get started.  http://pastebin.ubuntu.com/24460153/ Now I guess everthing else is like any other headless terminal.  I go set-up to use -propose, install the package and run the test case?
[13:32] <ahasenack> TafThorne: yeah
[13:32] <ahasenack> it took 27s because it had to download the image, I had it cached already
[13:32] <ahasenack> TafThorne: try "lxc image list" and "lxc list"
[13:33] <ahasenack> TafThorne: since you didn't run "lxd init" before launching the container, I'm not sure how your networking is setup, lxc list should tell if your container got an ip or not
[13:54] <TafThorne> ahasenack: does not look like it has an IP
[13:54] <ahasenack> TafThorne: I'd suggest to tear it down then and then run sudo lxd init and follow through the setup wizard that it runs
[13:55] <TafThorne> ahasenack: will do.  I'll get back to it when I am at a good point to logout and login agian to sort all that out too.
[13:55] <ahasenack> ok
[17:45] <drab> urm
[17:45] <drab> I've been running qemu in console on my desktop for testing and it works fine
[17:46] <drab> I moved the same script to a remote server and when I try to start it I get "Could not initialize SDL(No available video device) - exiting
[17:46] <drab> "
[17:46] <drab> however I was using qemu on my desktop from terminal, with -curses
[17:46] <drab> so not opening the GUI
[17:46] <drab> but you can't use -curses or -nographic with -daemonize (which seems to imply it)
[17:47] <drab> so I'm a bit lost... I can't use the paramters to tell qemu to not start a graphical env if I demonize it, which makes no sense to me
[17:47] <drab> any clue?
[17:48] <drab> I also tried -vga none and still get the same error
[18:04] <ahasenack> drab: what's the command line you are using?
[18:04] <ahasenack> drab: you can test locally on your desktop by unsetting DISPLAY probably, that would replicate the remote case
[18:05] <ahasenack> drab: also try -display none
[18:05] <ahasenack> or -display vnc and the vnc parameters (see manpage), these don't require DISPLAY (the shell var, for X access) and work with -daemonize
[18:06] <drab> ahasenack: /usr/bin/qemu-system-x86_64 -enable-kvm -name test -machine type=ubuntu,accel=kvm,usb=off -cpu host -smp 1 -m 2G -netdev bridge,br=lxdbr0,id=qemubr -device virtio-net-pci,mac=52:54:00:11:01:18,netdev=qemubr,id=eth0 -drive file=test/rootfs.raw,format=raw,id=root,if=none -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=root -boot dn -monitor unix:test/mon.sock,server,nowait -pidfile
[18:06] <drab> test/instance.pid
[18:06] <drab> then with -daemonize at the end or -curses
[18:06] <drab> right now I'm going through an install with -curses on the remote server for testing
[18:07] <drab> so that works fine
[18:07] <drab> ahasenack: I'll try -display none, thanks, vnc seems a good workaround too
[18:08] <ahasenack> drab: do you need the console to drive things interactively?
[18:09] <drab> no, it's all preseeded, ultimately I don't want any console
[18:09] <ahasenack> ok, then -display none should work I think
[18:09] <drab> trying, thanks
[18:09] <ahasenack> -nographic is another one
[18:13] <drab> ahasenack: it worked, thanks a lot
[18:13] <ahasenack> \o/
[18:13] <drab> anothe strange thing I noticed testing
[18:13] <drab> I have -boot dn
[18:13] <drab> but it always seemst o boot from network
[18:13] <drab> even tho the disk install is valid and -boot d will boot just fine
[18:14] <drab> and with -curses I stil see a complaint about not being able to boot cdrom, even tho I never ask it to boot from cdrom
[18:14] <ahasenack> isn't "d" the cdrom?
[18:14] <drab> oh, lol, I thought d was disk, n network
[18:14] <drab> my bad
[18:15] <drab> c cdrom
[18:15] <drab> should have doubel checked
[18:15] <ahasenack> yeah, c is "disk c", from windows fame
[18:15] <ahasenack> or pc bios, if you will
[18:15] <drab> you're right, man says d is cdrom
[18:16] <drab> thanks for catching that
[18:16] <ahasenack> np
[18:16] <drab> now I need to figure out my systemd unit and I'm all set
[18:16] <ahasenack> for systemd I'm not your guy :)
[18:17] <drab> it's actually not too bad to run qemu on its only, only took me 5 days and harassing half of the ppl in here :P
[18:17] <drab> its own*
[18:17] <drab> but there's no provision to start instances at boot so need to write your own glue
[18:17] <drab> this looks promising tho: https://kissmyarch.de/archives/2014/02/28/qemu_systemd_service/index.html
[18:18] <drab> at least that's how that guy did it and it seem a reasonably clean soluition
[18:18] <drab> stop/reset on socket works like a charm, already using that to interact with daemonized instance
[18:18] <ahasenack> have you tried libvirt and virt-manager?
[18:18] <ahasenack> you can use virt-manager to talk to remote qemu instances even, via ssh
[18:18] <drab> I have and I'm against violence
[18:18] <drab> :P
[18:18] <dpb1> lol
[18:19] <ahasenack> I just remembered it because libvit will start vms on boot if you want it to, and it can also be used remotely in a headless scenario
[18:20] <drab> yeah, I read about that, I gave it a try and decided not to go down that path, had too many problems right off the bat and since I'm mostly running lxd to make what looked like a big investment to figure it out didn't seem warranted
[18:21] <drab> basically I like magic as long as I understand the spell
[18:21] <drab> so I didn't trust myself to just point and click, not that it worked tho, couldn't get it to use my existing bridge for one
[18:22] <drab> I'm not saying it's bad, don't get me wrong, I hear lots of ppl happily use it in prod
[18:22] <drab> just didn't seem to be a good fit for me/what I'm doing even tho there was some upfront work involved this way too
[18:23] <ahasenack> sure
[18:37] <drab> anothe trying I'm trying to figure out, so far I always used -drive file=.... as I was dealing with image files
[18:38] <drab> but now I'd like to pass a partition of a disk to be used by KVM as a data mountpoint
[18:38] <drab> file= doesn't seem to be the right thing, but I can't google out what enchantment exactly I should use
[18:40] <drab> or maybe it is, just found something where they use lvm vols straight in file= syntax
[18:47] <drab> \0/ worked
[18:48] <drab> whups, cyclop


[00:33] <bluesabre> ochosi, never understood the locking myself
[00:35] <knome> lol
[06:14] <Unit193> bluesabre: Any progress? :P
[07:32] <flocculant> ochosi: :)
[07:50] <flocculant> ochosi bluesabre I guess we are back where we were last cycle - do we ditch l-l and use something else like xscreensaver or gnome-screensaver
[07:51] <flocculant> Unit193: thanks for reminding me - I think g-s is what I was misrembering as unity-greeter 6 months ago
[07:52] <flocculant> ochosi bluesabre - even assuming we get l-l working this cycle, that's now two cycles it's stopped working completely on us
[07:57] <Unit193> VT switching is bad.
[08:32] <flocculant>  nix g-s - problems there - will detail later
[10:43] <bluesabre> morning all
[10:45] <bluesabre> flocculant, ochosi, As light-locker is in a perpetual state of non-maintenance, VT-switching is terrible, and breaking is typical at least every 6 months, I am totally in favor of switching to something else
[11:02] <bluesabre> Unit193, current opinion on file managers? I still think there's not a patch that actually fixes the issues without creating new ones in Thunar
[11:06] <Unit193> bluesabre: I'll have to consider that at a better time perhaps, but I think I'm personally going to stick with Thunar.
[11:06] <bluesabre> ok
[11:20] <akxwi-dave> hmm a few hours ago we had Zesty A2 on the iso tracker.. now when I go to put up the testing results its gone...
[11:26] <bluesabre> akxwi-dave, maybe flocculant pulled it off since I don't think we were planning on participating
[11:27] <Unit193> [02:29:11] < flocculant> can someone from the release team get Xubuntu removed from this alpha 2 thing please :)
[11:30] <akxwi-dave> lol.. typical..   :-)
[11:32] <akxwi-dave> should have checked.. I thought we were doing A2, but when I saw it .. thought That it had been added for some reason I missed  :-)
[12:18] <flocculant> akxwi-dave: even if it was there we would need to critically fail and not release anyway :p
[12:19] <flocculant> bluesabre: ack - I did do a quick test on g-s but problems there - not got time to look properly now but will thi evening
[12:19] <flocculant> will also check if gnome actually locks ...
[12:20] <flocculant> and will check x-screensaver too
[13:18] <akxwi-dave> aye just tested that suspend on the iso from today..same
[16:56] <flocculant> bluesabre ochosi - ok done some testing - the outlook is poor ... pad.ubuntu.com/xubuntu-locking-zesty
[17:00] <flocculant> I'll try and let r_a know later this evening what I've tried
[19:59] -SwissBot:#xubuntu-devel- ::xubuntu-docs:: [cont1704] r628 Changes to contributor docs following review (by flocculant)
[20:53] <pleia2> http://xubuntu.org/news/winners-lovexubuntu-competition/
[20:53] <pleia2> :D
[20:54] <knome> \o/
[20:58] <pleia2> all social media-ed
[20:58] <knome> hooray
[20:59] <ochosi> flocculant: meh, have you forwarded this also to robert? to me this clearly shows that at least wrt light-locker it's a lightdm problem as the greeter wasnt touched. also: when it works, it seems to work best...
[20:59] <knome> :)
[21:00] <flocculant> ochosi: not specifically - have added it all to the bug though
[21:01] <flocculant> and yea - as you say - seems to definitely point to a lightdm problem
[21:04] <flocculant> have specifically now - I kept looking for him then stopped :p
[21:07] <flocculant> Ask logind to terminate remaining processes in the greeter session on closing, which is more robust than trying to fix every greeter.
[21:07] <flocculant> just broke us ...
[21:10] <ochosi> :]
[21:11] <flocculant> ochosi: as far as I can see now - I'll leave it be, unless I happen to stumble across something, and just wait and see
[21:11] <ochosi> sure
[21:12] <flocculant> not much of anything I could do now - tried greeters, tried losing l-lock and adding others
[21:13] <ochosi> yeah, i think you've done your job well
[21:13] <ochosi> in the worst case we have to try to fix up the greeter
[21:13] <ochosi> bluesabre: ^
[21:43] <flocculant> budgie is broken too ...
[21:49] <flocculant> I didn't try the kde one nor unity8 but I've beaten my head against the rest :p