[03:25] <shannon_> hello, hopefully a quick question here.. but is there updated docs on a single server install of openstack for 16.04?  everything I can find online points to using openstack-install, which is missing from 16.04
[03:25] <shannon_> I got this channel from http://openstack.astokes.org/
[03:26] <shannon_> looks like the installer was possibly replaced by a binary simply called openstack, but I'm not sure how to use it as it appears to be more of an interface for managing a server already setup
[03:27] <sarnold> shannon_: there's this thing, but I haven't tried it myself: http://conjure-up.io/
[03:31] <shannon_> great, thanks. I'll check it out :)
[03:32] <nacc> rbasak: fyi, i put some notes in the share doc
[03:33] <nacc> rbasak: https://git.launchpad.net/~nacc/ubuntu/+source/strongswan
[03:34] <nacc> rharper: --^ that's the full import of all the debian and ubuntu history, if you want to look at it, as an example
[03:34] <nacc> rharper: for strongswan
[03:35] <rstarmer> shannon_: conjure-up does work, but I had (and still have) some issues trying to use it on a KVM based virtual machine.  If you are building it on hardware directly, it should work well.  You might also want to grab the latest from the ppa rather than from the default package, as there are some tweaks to the network service that may be needed.
[03:35] <rstarmer> ppa:conjure/ppa
[03:35] <shannon_> ok thanks, yeah I'm installing on hardware
[03:36] <rstarmer> It's pretty slick, automates juju driving LXD/LXC to deploy the services as containers.
[04:52] <meloc> Hi. I've placed the mitmproxy root ca certificate in every directory i can find documented and have run update-ca-certificates over and over
[04:52] <meloc> yet no new root CA is being added. no new symlinks in /etc/ssl/certs
[04:52] <meloc> I can't find any actual, real documentation on this anywhere. Can someone please advise?
[04:53] <Jordan_U> meloc: What kind of certificate is this file?
[04:54] <meloc> standard PEM certs
[04:54] <meloc> the same certs I use in Nixos and Arch without issue
[04:55] <meloc> wow. just wow. it specifically looks for .crt files
[04:55] <meloc> rename .pem or .cer to .crt and it works. wooo. Thanks for the rubber duck debugging assistance!
[04:56] <Jordan_U> You're welcome :)
[08:08] <OlofL_> I installed sudo apt-get install --no-install-recommends lubuntu-desktop, how do I get to gui?
[08:11] <OlofL_> startx errors
[09:38] <rbasak> nacc: looking good! I'll review the doc but we should probably do a hangout sync today to catch up I think?
[13:07] <rharper> nacc: thanks!
[13:19] <aard> hi, trying to figure out if the newest lts comes with a newer jmicron driver (jme) than 1.0.8 that comes with 14.04.
[13:23] <sdeziel> aard: I'm afraid it's still 1.0.8: https://paste.ubuntu.com/16258501/
[13:23] <aard> aww that's a shame but thanks for the answer sdeziel
[13:23] <sdeziel> aard: you are welcome
[13:32] <rbasak> nacc: I just found out about http://dep.debian.net/deps/dep14/. Might be worth looking into harmonising.
[13:34] <rbasak> It's pretty close to what we're doing lready.
[13:41] <trippeh> aard: in kernel drivers quite rarely actually update their version numbers though.
[13:41] <trippeh> so it can have significant fixes
[13:42] <aard> trippeh: hmm okay thx
[13:45] <trippeh> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/net/ethernet/jme.c there's at least a few fixes since 2014
[13:47] <trippeh> since/during, anyway
[15:14] <nacc> rbasak: ack, i'm around now
[15:14] <nacc> rbasak: if you still are
[15:15] <nacc> trippeh: even in mainline, the version is still 1.0.8
[15:16] <nacc> trippeh: the 'version' of drivers is often nonsensical now that we have git :) just refer to, if you can, of the sha1 of the kernel commit that is the source for the kernel image
[15:16] <nacc> trippeh: since it all moves together if it's in mainline
[15:16] <nacc> aard: --^ actually, sorry
[15:17] <nacc> rbasak: ok, are you ok if we change our naming to match dep14? e.g., s/:/%/ rather than s/:/_/
[15:20] <nacc> rbasak: we should update git-dsc-commit too (i've got a --tree-only patch for that too)
[15:21] <nacc> rbasak: do you want me to default to signed tags? i'm not sure if that will work with the faked authorship?
[15:23] <JanC> maybe they should change the "version" of drivers like that to something like "git" then  ;)
[15:24] <nacc> JanC: heh
[15:48] <trippeh> heh yeah the version strings in in-kernel drivers is causing a bit of confusion.
[15:48] <trippeh> they are pretty much "random"
[15:49] <nacc> trippeh: they are also in the driver source, which relies on the driver vendors to update them; and some drivers don't get many updates (or only get bugfixes)
[15:50] <nacc> and not all of those come from the vendor anymore, which means versions don't change correspondingly
[15:50] <nacc> tbh, i'd ignore any string a driver emits about its own version, if it's from the kernel source :)
[15:50] <nacc> and just trust the uname/git-sha to tell you what the src is
[15:51] <JanC> hence, make a kernel policy to use a version string which makes that obvious for those drivers  :)
[15:51] <JanC> solves the confusion part at least
[15:51] <nacc> i'm sure for some vendors they do use the version string
[15:51] <nacc> it's just not consistent
[15:51] <nacc> JanC: feel free to suggest on LKML :-P
[16:20] <hallyn> smb: you know it's a good thing we didn't try to merge libvirt 1.3.3 last cycle, bc i think it's a bit of a lemon
[16:23] <nacc> rbasak: if you do come back online today, just ping me, or even just set up the hangout, i'll join (in case I don't see the ping)
[17:46] <gQuigs> Can anyone help me understand what update-status does in the nova-compute charm (see bottom of https://api.jujucharms.com/charmstore/v5/trusty/nova-compute-254/archive/hooks/nova_compute_hooks.py)
[17:46] <gQuigs> and what could make it fail..
[17:47] <gQuigs> with http://pastebin.ubuntu.com/16264350/
[18:10] <aard> nacc trippeh: so kernel driver versions doesn't say much really, as far as i understand. well, it states that a driver is "at least" a certain version so to speak
[18:22] <hallyn> smb: jdstrand: arges: so i think i may have the libvirt-bin.service->libvirtd.service rename mostly working, but qrt failures pointed out that any scripts doing service libvirt-bin restart (for instance) will fail...
[18:22] <hallyn> that is, systemctl restart libvirt-bin will work,
[18:22] <hallyn> bc we have libvirtd aliased as libvirt-bin.service.  but 'service' and 'invoke-rc'd don't know about that
[18:23] <hallyn> is that a problem?
[18:23] <arges> hallyn: might be a good way to find obsolete scripts : )
[18:23] <hallyn> roaksoax: jamespage: smoser: ^ will things like maas or subiquity hav ea problem with it?
[18:23] <hallyn> arges: 'obsolete' sadly may not be accurate in our cloud archive world
[18:23] <arges> hallyn: oh yea...
[18:23] <hallyn> :(
[18:24] <smoser> hm.
[18:24] <arges> hmm
[18:24] <hallyn> dunno if there is a way to trick it
[18:24] <hallyn> and don't know what all we 'officially' support
[18:25] <hallyn> sigh @ gratuitous rename
[18:30] <JB_____> I have installed a host with dhcp server and FW server (ufw/iptables). But my rules in ufw are only apply on my host and absolutly not on my NAT... exemple if I block internet acces my host doesn't heave any more internet but on my private network internet stay present.. somebody can help me ? :/
[18:31] <hallyn> all right well lets see how many more different failures i've got (qrt still running).  maybe i can still do better
[18:38] <nacc> aard: it's just a string in the source, basically :)
[18:44] <arges> hallyn: i think we're going to have to do it at some point. better at the first release after an LTS than later
[18:44] <arges> but then cloud archive backporting may need extra logic
[18:50] <hallyn> yeah
[18:50] <hallyn> that may be the way to go
[18:51] <hallyn> so i mihgt just push without extra logic for now while we work out bugs in regular setups, then we can accomodate whatever jamespage and friends need later
[19:01] <jamespage> hallyn, arges: we have capability to support renaming of a service, and I think that on a systemd enabled install, we use systemctl transparently to the charm
[19:01] <jamespage> service_restart(XX) -> systemctl restart XXX
[19:01] <jamespage> but I'll check that
[19:07] <hallyn> sounds good
[19:33] <hallyn> all right, i'm now down to actually fewer qrt failures than with the xenial version.  yay.
[21:55] <LostSoul> Hello
[22:11] <ryankoski> hello all, I'm looking for a way to delay the autoimport of zfs pool in 16.04 to ensure that my devices are up and ready (not working on reboot right now)
[22:11] <ryankoski> any tips?
[22:13] <rattking> you could take alook at rootdelay or rootwait to slow the kernel down a bit
[22:22] <ryankoski> @rattking, thanks for the tip, giving that a shot now
[22:28] <ryankoski> no go