[05:17] <teward> well... that's gonna be a problem...
[05:17] <teward> *apparently* the software that nginx uses for the Lua module in universe isn't found in LD at all
[05:17] <teward> so FTBFS majorly.
[05:18] <teward> that's... concerning.
[05:18] <teward> at least, for Bionic.
[06:02] <rbasak> nacc: now that git has its own namespaces, I'd like to avoid using the term "namespace" if possible. I'm not sure a full rename/refactor across the code is warranted, but I figured that "ref_prefix" made sense in my case.
[06:02] <rbasak> It's unambiguous as to what it means
[06:03] <rbasak> (I felt namespace wasn't clear as to whether '/' separator was included or intended to be added)
[06:04] <teward> rbasak: FYI, the above.
[06:04] <teward> also see #u-release
[06:58] <albech> been very happy in the past with Nagios/Icinga, but wondering if there are other players on the monitoring area worth looking into. We are planning to rebuild our monitoring setup over the next few months so now is the time to do a little research.
[07:07] <lordievader> Good morning
[09:01] <hateball> albech: well there's Zabbix (I dont like it)
[09:02] <hateball> and there's zenoss, opennms, pandorafms
[09:02] <hateball> personally I quite like pandorafms, what I've tried it
[09:02] <hateball> we use icinga2 here tho
[09:17]  * lordievader likes zabbix
[09:17] <lordievader> hateball (IRC): How does pandorafms compare to zabbix?
[09:18] <hateball> lordievader: I just like the interface better
[09:34] <Slashman> hello, is there a way to deactivate the keeping of crash dump in the directory /var/crash? I had the nasty surprise of a full /var volume because of that :/
[09:47] <albech> thanks hateball and lordievader. I think ill try Icinca2. Not sure about opennms. Dont really like the whole java idea.
[09:50] <hateball> albech: suppose it depends what you need for your monitoring solution also
[09:51] <hateball> I havent personally setup Director, but I think that makes icinga2 more user friendly
[09:51] <hateball> pandorafms is configured through gui by default, and it has nice graphs and what not for managment types :p
[09:51] <hateball> stuff you need to manually setup with graphite or whatever, for icinga
[09:59] <albech> pretty much everything in a modern datacenter with a strong focus on linux. so network, storage, iron, security, gues os's etc.
[10:00] <pankaj_> Hello, guys. Where can I get gtk3 manpages. I have tried to do 'apt-cache' for its doc but it is still not there.
[10:23] <pankaj_> Hello, guys. Where can I get gtk3 manpages. I have tried to do 'apt-cache' for its doc but it is still not there.
[10:29] <lordievader> pankaj_: I don't think this is the right channel for gtk related things.
[10:30] <hateball> I'm not sure there are any man-pages for GTK either
[10:40] <lordievader> pankaj_: What are you actually looking for? Gtk documentation or something?
[15:48] <nacc> rbasak: +1
[15:55] <coreycb> jamespage: seems i'm hitting this withhttps://bugs.launchpad.net/glance/+bug/1728368 glance -
[15:55] <coreycb> jamespage: with glance unit tests
[15:55] <jamespage> coreycb: \o/
[15:55] <jamespage> coreycb: I figured out my neutron problem
[15:56] <coreycb> jamespage: oh?
[15:57] <jamespage> coreycb: yeah a new version of flake8 was causing the discovery process to fail, which stalled the test execution upfront
[15:58] <coreycb> jamespage: ah geez
[15:58] <jamespage> coreycb: tbh the state of flake8 usage upstream vs what we have in distro is poor
[15:58] <jamespage> we have 3.x, upstream still uses 2.x
[15:59] <coreycb> jamespage: interesting, i wonder why that is
[16:08] <mecotri> I have two public IPv6 addresses on one interface and need to change which one is the default for outgoing traffic. How can I do that? I've tried all sorts of ip route commands with no success.
[16:10] <nacc> rbasak: where did you get :param: from? are we switchig to sphinx docstring?
[16:13] <rbasak> nacc: I've been trying to be consistent all along but never knew the actual syntax. Yesterday I looked it up :-)
[16:14] <nacc> rbasak: that's the sphinx specific syntax
[16:14] <nacc> rbasak: is that what we want to use?
[16:14] <rbasak> nacc: if we were to settle on something concrete, any other candidates apart from sphinx?
[16:14] <nacc> rbasak: no, just want to know what you want to use and ask that you put it in the style guide if you're changing it :)
[17:16] <nacc> rbasak: do you want me to keep your commits separate for the devel branch stuff? or can i squash?
[17:27] <axisys> how do I upgrade dig on trusty to allow caa type query? I get Warning, ignoring invalid type caa when doing dig -t caa example.com
[17:34] <sdeziel> axisys: I don't think you can get a fresher version on Trusty. You can still lookup the CAA records with "dig -t type257" though
[17:37] <axisys> sdeziel: right.. but seems like they are pushing new code and want to rely on dig query for caa.. it works on some systems but those are running centos 7.. we have quite a few ubuntu servers around that are still trusty .. works fine on xenial
[17:37] <axisys> may be there is a ppa .. I have not found one
[18:16] <TJ-> axisys: how about a shell wrapper and a diversion? e.g. http://pastebin.ubuntu.com/25975772/
[18:19] <powersj> cyphermox: I have it narrowed down to the cmdline... tests are using debconf/priority=critical and that doesn't seem to work with bionic. Works with artful. Changing it to priority=critical makes it work.
[19:01] <axisys> TJ-: genious!
[19:01] <axisys> so whats the diff between that divert and symlink ?
[19:05] <TJ-> axisys: the dpkg-divert ensure any package updates update /usr/bin/dig.real not your /usr/bin/dig script
[19:08] <sdeziel> putting the dig wrapper in /usr/local/bin might be a viable option as well
[19:10] <cyphermox> powersj: that's very bad
[19:10] <cyphermox> priority is supposed to be an alias to debconf/priority, not the other way around
[19:17] <TJ-> sdeziel: yes. I was trying to protect against anything using the exact path. been caught by that in the past
[19:17] <TJ-> sdeziel: also makes it clear there's something been changed on the system
[19:18] <sdeziel> TJ-: true
[19:24] <powersj> cyphermox: where should I file a bug?
[19:24] <powersj> or to be more clear, what should I file a bug against
[19:26] <cyphermox> powersj: I'd say debconf for now, I'll look more into it
[19:31] <cyphermox> powersj: actually, let's do a hangout and have a look at something?
[19:31] <powersj> ok
[19:31] <cyphermox> if you have the time
[19:31] <powersj> I do
[19:57] <powersj> cyphermox: LP: #1732776 with an example not using a preseed
[21:23] <axisys> TJ-: gotcha
[21:41] <rbasak> nacc: feel free to squash
[21:41] <nacc> rbasak: i ended up just pushing up
[21:41] <nacc> i reviewed the squashed version :)
[21:41] <nacc> and then kept your changes
[21:42] <rbasak> axisys, sdeziel: FWIW, an update to dig on Trusty may be acceptable under current SRU policy (change to the Internet environment).
[21:43] <rbasak> It'd need someone to drive it, and for the change to be minimal etc though. Which may not be practical.
[21:43] <rbasak> nacc: np
[21:44] <sdeziel> rbasak: yeah, backporting just the CAA RR support I guess
[22:39] <Epx998> https://www.top500.org/system/179068
[22:39] <Epx998> probably running precise /smirk