[00:32] <faekjarz> Hi! (16.04) Can i us an MTU >1500 and DHCP? I mean, "mtu 9000" in /etc/network/interfaces doesn't seem to be used when the IF isn't set to static.
[00:35] <sarnold> faekjarz: this suggests two approaches: http://askubuntu.com/q/350992/33812
[00:35] <sarnold> faekjarz: either add a post-up command to set the mtu 'manually'
[00:35] <sarnold> faekjarz: or remove a setting from the dhcp client configuration so that it won't apply the value from the server
[00:36] <sarnold> faekjarz: any reason why your server is handing out wrong sizes?
[00:38] <faekjarz> sarnold: it's a pfsense box, and its DHCP server (well, the UI, at least) doesn't provide configuration of MTUs …or i'm too blind to see it
[00:40] <sarnold> faekjarz: I wonder if it just hands out 'ethernet default' unless you configure it otherwise
[00:40] <sarnold> I wouldn't be surprised..
[00:51] <faekjarz> ok, i _was_ too blind, and maybe a little stubborn. pfSense lets me set "Additional BOOTP/DHCP Options" (it's option 26), but not per client, only per port (i.e. LAN, WLAN, ..)
[00:51] <faekjarz> i'll go with the post-up hook …thanks sarnold :)
[00:51] <sarnold> oh -of course- option 26 :) haha
[00:52] <sarnold> faekjarz: curious, wouldn't it be a feature of e.g. a port?
[00:52] <faekjarz> haha :D yes, but it links to the appropriate IANA doc http://www.iana.org/assignments/bootp-dhcp-parameters/
[00:54] <sarnold> handy list
=== MrBIOS_ is now known as MrBIOS
=== sikun is now known as txeru
=== cpaelzer_ is now known as cpaelzer
[07:43] <melomane> hi, i have ubuntu server 12.04 installed on a VPS server. the filesystem goes to read-only mode very frequently. what's the problem? it it a good idea to remove read only on error in fstab?
=== Thorn__ is now known as Thorn
[10:00] <frickler> jamespag`: coreycb: I've failed to find an ubuntu specific source for python-glance-store, do you build this type of packages directly from the debian source pkg?
[10:01] <jamespag`> frickler, not always
[10:01] <jamespag`> frickler, sometimes we're in sync, sometimes not
[10:01] <jamespag`> frickler, having issues? I know there is an SRU held up in xenial-proposed atm
[10:01]  * jamespag` reminds himself to chase that
[10:01] <frickler> jamespag`: I'm asking because I need a package with https://review.openstack.org/373155 built in.
[10:03] <frickler> this is the bug being worked around https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1625489
[10:03] <ubottu> Launchpad bug 1625489 in ceph (Ubuntu) "image.stat() call sometimes fails" [Undecided,Confirmed]
[10:03] <frickler> jamespag`: I've also tried to rebuild the ceph package with the patch upstream came up there, built it failed after 3h. also the workaround seems much less intrusive to me
[10:10] <jamespag`> frickler, https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/python-glance-store/+git/python-glance-store
[10:10] <jamespag`> master = newton
[10:10] <jamespag`> stable/mitaka - mitaka
[10:11] <jamespag`> frickler, that's an import of the latest source packages from xenial and yakkety
[10:13] <frickler> jamespag`: that's exactly the place I was looking at earlier, did you just create it?
[10:16] <jamespag`> frickler, I did - we generally create them on demand when we need to fork from Debian in some way
[10:17] <jamespag`> frickler, pulling the source packages from ubuntu, and re-creating the git repos that way
=== jamespag` is now known as jamespage
[10:22] <jamespage> ddellav, coreycb: headsup we might have to deal with a defaults switch for cinder/iscsi from tgt to lio
[10:22] <jamespage> performance looks good, discussion about deprecating tgt driver on openstack-dev
[10:22] <jamespage> but next cycle
[10:22] <jamespage> :)
=== Thorn__ is now known as Thorn
[11:08] <jamespage> coreycb, ddellav: we're still broken atm - https://bugs.launchpad.net/ceilometer/+bug/1626006
[11:08] <ubottu> Launchpad bug 1626006 in ceilometer (Ubuntu) "wsgi_script based ceilometer-api binary does not support the same CLI arguments as console_script version" [High,New]
[11:17] <frickler> jamespage: ok, that built fine for me, thx. if you want to reuse it for your version: https://git.launchpad.net/~j-rosenboom-j/+git/python-glance-store/commit/?id=3f68dbadc2a9eebfbaf5ff1e37f128c7847dbddd
[11:18] <jamespage> frickler, ta
[11:21] <coreycb> jamespage, great..
[11:21] <jamespage> coreycb, I pinged jd in openstack-telemetry
[11:22] <jamespage> I don't have an easy fix for this
[11:46] <caribou> rbasak: would you have a few minutes to help me out with the tomsfastmath MIR required to unblock clamav merge ?
[12:10] <rbasak> caribou: sure
[12:10] <caribou> rbasak: hold on, Need to switch desks & I'll be back
[12:11] <rbasak> OK
[12:33] <caribou> rbasak: ok, I'm back
[12:35] <caribou> rbasak: so as  you may recall, the clamav merge is stucked on the fact that it has an Universe dependancy on libtfm (tomsfastmath)
[12:35] <rbasak> Yes
[12:38] <caribou> I'm trying to make sense of what's required for the MIR
[12:40] <caribou> rbasak: or if it is even possible given the timeframe
[12:45] <caribou> rbasak: debian switched from libtommath to libtfm which is in Universe; they used to carry an in-package copy of libstomfastmath
[12:45] <rbasak> Yeah I've been digging.
[12:46] <rbasak> AFAICT, they used to use libgmp before 2009-01-26, and have been using an embedded copy of libtommath since
[12:46] <rbasak> Upstream, that is.
[12:48] <rbasak> clamav entered main in around 2008.
[12:49] <caribou> rbasak: yes until recently where 0.99.2's upstream switched to libtomsmath
[12:50] <caribou> rbasak: actually no, it was in 0.98
[12:50] <rbasak> switched to libtomsmath from what?
[12:52] <caribou> rbasak: no sorry switched from libtommath to libtfm (tomsfastmath)
[12:52] <rbasak> Anyway, I think this might be a little academic. I would do a proper MIR, but I imagine it may be fairly quick for what it is. However, in the context of clamav the library will presumably be handling unvalidated input, so the security team may want to look.
[12:53] <rbasak> libtommath to libtfm (tomsfastmath)> ah, OK. They do seem to come from the same upstream, though.
[12:53] <rbasak> caribou: so I'd file a MIR, explain what we've discovered above, and see if the security team feel that a review is necessary.
[12:54] <rbasak> clamav has a major release exception for stable releases, so that might affect things too.
[12:55] <caribou> rbasak: ok, I started on the MIR : LP: #1619239
[12:55] <ubottu> Launchpad bug 1619239 in tomsfastmath (Ubuntu) "[MIR] tomsfastmath (runtime dependency of clamav)" [High,Incomplete] https://launchpad.net/bugs/1619239
[12:56] <caribou> doko is talking to me about backports of the library, not sure what he means to I need to dig into this a bit deepere
[12:56] <caribou> deeper
[12:58] <caribou> rbasak: hmm, strange, the latest clamav source pkg still have the embedded copy of tomsfastmath
=== petevg_afk is now known as petevg
[13:04] <rbasak> caribou: yeah I think the Debian package just started using the external one instead, due to the general distribution aversion to embedded dependencies.
[13:05] <caribou> rbasak: the external tomsfastmath package is fairly recent, Dec 2015. My guess is that they packaged it to remove the embedded one
[13:07] <caribou> rbasak: when 0.99 got in Debian (0.99 is Xenial), the tomsfastmath pkg did not exist yet
[13:08] <rbasak> caribou: yeah that sounds likely
[13:08] <caribou> rbasak: and both clamav 0.99 and tomsfastmath pkg  have the same importer
[13:24] <jamespage> coreycb, apparently we need a newer pbr version in order for the wsgi_script thing todo the right stuff
[13:26] <coreycb> jamespage, ahh. well then global-requirements should be updated
[13:26] <jamespage> coreycb, upper-constraints.txt is at 1.10.0
[13:26] <jamespage> pbr >= 1.6
[13:27] <coreycb> jamespage, I can bump that to 1.10.0
[13:27] <jamespage> coreycb, yah - just pondering the risk
[13:28] <coreycb> jamespage, yeah... hate to do it so late
[13:28] <jamespage> the release team will want to know why - its has alot of reverse-depends
[13:28] <coreycb> jamespage, it's used everywhere in openstack
[13:28] <jamespage> coreycb, yeah - less concerned about that - we can sniff a few pkgs in ppa to de-risk
[13:29] <coreycb> jamespage, yeah holy reverse depends.  they're mostly all openstack at least.
[13:29] <jamespage> coreycb, can I leave this with you?
[13:29] <jamespage> I'm trying to wriggle though charm reviews today
[13:29] <coreycb> jamespage, sure. you ok with bumping it if the release team is ok?
[13:30] <jamespage> yah
[13:48] <Pawni> Hi guys, anyone else experience problems with pip on 16.04.1? I upgraded from 15.10 to 16.04.1 and my python upgraded from 3.4 to 3.5.2, now every pip install gives permission errors?
[13:49] <Pawni> I can still install packages if going sudo, but I feel that there probably is a better fix for this, and it's annoying because I'm trying to install them using an account that can't sudo
=== iberezovskiy|off is now known as iberezovskiy
[14:55] <setuid> What's the magical syntax to uvt-kvm to export the details of a uca image?
[14:56] <setuid> Something that I can use to diff against another image, to see what configuration values may be different
[14:57] <setuid> virsh dumpxml, I suppose?
[15:27] <rbasak> setuid: that'll tell you how the VM is configured on your system, not about changes within the image itself. Which are you after?
[15:27] <rbasak> setuid: you might be interested in the mount-image-callback command from cloud-image-utils
[15:28] <setuid> Just trying to debug a client's reported issue with firefox and a missing dep on libgl1-mesa
[15:29] <setuid> I can repro it, so that's good, but I'm wondering if their uca image is different in some way
[16:01] <jamespage> coreycb, pbr got a +1 from pitti
[16:02] <coreycb> jamespage, great, I hadn't heard back from him in #ubuntu-release.
[16:02] <jamespage> coreycb, its in the bug erport
[16:02] <coreycb> jamespage, ok, thanks for opening a bug
[16:03] <jamespage> coreycb, i added a task to https://bugs.launchpad.net/ubuntu/+source/python-pbr/+bug/1626006
[16:03] <ubottu> Launchpad bug 1626006 in ceilometer (Ubuntu) "wsgi_script based ceilometer-api binary does not support the same CLI arguments as console_script version" [High,Triaged]
[16:06] <coreycb> jamespage, ddellav offered to do pbr so he's working on it as we speak
[16:09] <hallyn> cpaelzer: fwiw i think we want to just keep all qemu machine types which do not predate the earliest supported TLS
[16:10] <cpaelzer> hallyn: hi
[16:10] <cpaelzer> hallyn: interim dev types, really
[16:10] <hallyn> lol.  LTS even
[16:10] <cpaelzer> well all LTS is fine
[16:10] <hallyn> yes.  it's not worth saving 10loc to drop those
[16:10] <cpaelzer> hehe
[16:10] <hallyn> no, i'm saying keep the interims back to the earliest supported lts
[16:11] <cpaelzer> yeah I got you
[16:11] <cpaelzer> hallyn: stating that everything older than that is really really too old
[16:11] <hallyn> it's still gonna hurt ppl at some point, but updating machine types just isn't something ppl like to do
[16:11] <hallyn> yeah
[16:11] <hallyn> cool - ttyl :)
[16:12] <cpaelzer> hallyn: in the discussion the sugegstion was dropping all prior to latest LTS, but I see we could shift some pain further to the future
[16:12] <cpaelzer> when people will hopefully agree it is late enough to finally restart/update some things
[16:12] <cpaelzer> I
[16:13] <cpaelzer> 'll tihnk about it in regard to the bug I'm currently fixing
[16:13] <cpaelzer> hallyn: thanks for the comment
[16:32] <ddellav> coreycb jamespage python-pbr ready for review: lp:~ddellav/ubuntu/+source/python-pbr
[16:34] <coreycb> ddellav, looking
[16:41] <coreycb> ddellav, the patch lost some code but I'll add that and push/upload.  thanks very much for doing this.
[17:02] <coreycb> ddellav, jamespage: python-pbr 1.10.0 uploaded
=== iberezovskiy is now known as iberezovskiy|off
=== degorenko is now known as _degorenko|afk
=== jge_ is now known as bitfury
=== Guest66320 is now known as IdleOne
[20:22] <faekjarz> Hey there! What are possible reasons for a link (sym/hard), to /dev/dm-0, to not "survive" a reboot?
[20:24] <nacc> faekjarz: where does the link live?
[20:25] <faekjarz> nacc: below /dev (grub-update, for some reason, needs /dev/sda2_crypt, which is a link to /dev/mapper/sda2_crypt, which points to /dev/dm-0)
[20:27] <nacc> faekjarz: /dev is not a true filesystem, but lives in memory
[20:27] <nacc> faekjarz: it's technically a view into the kernel's perspective on devices
[20:27] <nacc> faekjarz: so it will of course not maintain state over reboots
[20:30] <faekjarz> nacc: i see :\ …thanks for the explanation …so then, i'll just re-create that link on boot: where should i put my one-liner?
[20:33] <rattking> udev makes the rest of those symlinks, so thats probably the correct place.
[20:33] <nacc> faekjarz: udev would be my guess, but if it's something that update-grub is expecting to exist alraedy, why doesn't it?
[20:36] <faekjarz> it's a somewhat custom installation of ubuntu server 16.04 with root on zfs on luks. i.e. creating manually creating partitions and stuff and running "debootstrap xenial /mnt". I followed a guide on github
[20:37] <rattking> oh my, I ran into problems installing grub of a zfs root a while back.. I bet this is what I needed :)
[20:38] <faekjarz> :)
[20:46] <nacc> faekjarz: yeah, i'm not sure, udev is probably what you need, but given zfs root isn't really supported here, can't help too much more :/
[20:50] <faekjarz> nacc: no worries, that missing link only bites me when package updates create run grub-update. in this case i'll notice it, create the link and start over. …i'll look into udev, thank you & rattking
[20:55] <nacc> faekjarz: gl!
=== bitfury is now known as jge
[22:31] <JanC> faekjarz: I assume you mean update-grub instead of grub-update?
[22:32] <JanC> there might be a way to tell that or other parts of grub where to look
=== tikund is now known as txeru
[22:53] <faekjarz> JanC: yes, update-grub, indeed. I had grub-install in mind and thought it's similar. (right now i'm learning systemd to figure the least hackish implementation of my plan out ;)
[22:57] <JanC> update-grub calls grub-mkconfig, which calls a bunch of config-generation-scripts under /etc/grub.d/ which use configuration variables in /etc/default/grub
[22:58] <JanC> it might be useful to figure out why it looks for /dev/sda2_crypt instead of /dev/mapper/sda2_crypt