[00:00] <sarnold> mason: what does kvm-ok in the guest report?
[00:00] <mason> sarnold: Is there an EL equivalent? The guest is running RHEL 6.
[00:00] <monokrome> sarnold: It's using dialog, same way that most `dpkg-reconfigure` stuff works?
[00:01] <mason> I don't see vmx or svm in feature flags in /proc/cpuinfo, but I'm not sure if that's a comprehensive list.
[00:01] <mason> ah, it's a script - moving it over
[00:03] <mason> Yeah, that's looking for vmx and/or svm too. vmx given that I'm on Intel I guess.
[00:06] <mason> Oh well. I'll dig for how to pass through VMX to guests after dinner.
[00:08] <sarnold> mason: how about /sys/module/kvm_intel/parameters/nested ?
[00:26] <mason> sarnold: Looking.
[00:28] <mason> Hm, no go - I assume because it needs vmx passed in: FATAL: Error inserting kvm_intel (/lib/modules/2.6.32-696.20.1.el6.x86_64/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported
[00:31] <sarnold> mason: on the host?
[00:32] <mason> oh
[00:32] <mason> 'Y' on the host
[00:32] <sarnold> very confused.
[00:32] <sarnold> maybe it has to do with the guest type? or guest cpu type?
[00:33] <mason> I didn't see any obvious options, but I'll look again.
[00:34] <mason> http://www.rdoxenham.com/?p=275 is interesting
[00:35] <mason> Looks like maybe I want  <feature policy='require' name='vmx'/> in my config.
[00:35] <mason> for the VM
[00:36] <mason> Hm. Everything I'm seeing says to do that manually.
[00:42] <mason> virsh edit for the win, as there's no way to specify that in virt-manager. My laziness finally fails me.
[00:43] <mason> Anyway, with that feature policy line shoved into the VM config, kvm-ok sees vmx in the guest, and I can nest.
[00:43] <sarnold> woot
[00:43] <mason> \o/
[00:43] <sarnold> I'm surprised it's not the default
[00:43] <sarnold> but maybe it comes with consequences I don't know about
[00:43] <mason> Yeah, interesting choice.
[00:45] <mason> Hm, still not seeing SPEC_CTRL in guests... I think I need to restart things perhaps.
[01:16] <mason> For those playing along at home, my VM defaulted to Broadwell, but it needed to be Broadwell-IBRS.
[06:26] <cpaelzer> sarnold: mason: it actually is the default of libvirt to have a type with vmx/svm
[06:26] <cpaelzer> sarnold: mason: but that is a virtual cpu type that has almost no other features
[06:27] <cpaelzer> sarnold: mason: virt-manager does detection and selects a defined cpu type, like broadwell in this case
[06:27] <cpaelzer> the definition of that type doesn't have it by default as you have realized
[07:10] <lordievader> Good morning
[07:43] <cpaelzer> jamespage: could it be that nova/2:17.0.0~b3-0ubuntu3 is borked - I see all dep8 tests fail
[08:09] <cpaelzer> jamespage: analyzed, see bug 1748123
[08:09] <ubottu> bug 1748123 in nova (Ubuntu) "Policy "os_compute_api:os-server-usage":"rule:admin_or_owner" was deprecated for removal in 17.0.0" [Undecided,New] https://launchpad.net/bugs/1748123
[08:24] <cpaelzer> jamespage: coreycb: bug 1748123 now has a MP linked that would need your ack if possible
[08:24] <ubottu> bug 1748123 in nova (Ubuntu) "Policy "os_compute_api:os-server-usage":"rule:admin_or_owner" was deprecated for removal in 17.0.0" [High,New] https://launchpad.net/bugs/1748123
[09:08] <jamespage> cpaelzer: looking now
[09:09] <jamespage> cpaelzer: meh lets just do allow-stderr for nova - it won't inpair the testing in any way IMHO
[09:09] <jamespage> cpaelzer: I'll sort that now
[09:10] <cpaelzer> jamespage: I'm ok with that as well
[09:11] <cpaelzer> jamespage: please ping me once the new version is in proposed so that we can retrigger all the blocked packages
[09:11] <cpaelzer> jamespage: ok ?
[09:12] <jamespage> cpaelzer: yes - uploading now
[09:12] <cpaelzer> ok, that was fast :-)
[09:12] <cpaelzer> I wonder when exactly I can retrigger all the fails then - probably once it shows up as published on all arches in proposed
[09:13] <jamespage> cpaelzer: its a pretty trivial change
[09:13] <cpaelzer> jamespage: will it be 2:17.0.0~b3-0ubuntu4 ?
[09:14] <cpaelzer> ok I see it, tracking that then - thanks
[09:15] <cpaelzer> hmm actually I think hte nova needs to fully migrate
[09:15] <cpaelzer> as testing is "only the testee from proposed"
[09:15] <cpaelzer> jamespage: do you think it would be correct to still mark ..ubuntu3 as bad-test?
[09:15] <cpaelzer> that would help to resolve that quicker and with les sload to the machines
[09:16] <cpaelzer> all logs I checked had the ok on the actual test
[09:16] <jamespage> cpaelzer: I think that's fine
[09:16] <cpaelzer> jamespage: I'll update the MP with that
[09:16] <cpaelzer> the bug will get auto-updated as soon as you migrate
[09:16] <cpaelzer> thanks
[09:16] <jamespage> Commented to that effect
[09:17] <cpaelzer> oh that is even better
[09:18] <cpaelzer> apw: if you are around a merge of https://code.launchpad.net/~paelzer/britney/hints-ubuntu-mask-nova-for-oslo-policy-deprecation/+merge/337331 would free up at least a small portion of the current proposed migration stall
[11:00] <rbasak> cpaelzer: did you have a uvtool MP for me to review? I can't find it.
[11:02] <cpaelzer> rbasak: there was an acked one that isn't merged
[11:03] <cpaelzer> rbasak: https://code.launchpad.net/~paelzer/uvtool/+git/uvtool/+merge/335884
[11:03] <cpaelzer> the approved state might mask it from your usual search for open todo's
[11:03] <cpaelzer> but it isn't in git afaict
[11:12] <rbasak> Thanks!
[11:33] <rbasak> cpaelzer: pushed to git and built in https://code.launchpad.net/~uvtool-dev/+archive/ubuntu/master
[11:34] <cpaelzer> thanks rbasak!
[11:34] <rbasak> cpaelzer: if you'd like me to upload I can do that two but if so please could you test the PPA works as expected? The only two changes vs. bionic are your last two commits :)
[11:34] <rbasak> I can do that oo
[11:34] <rbasak> I can do that too
[11:34]  * rbasak seems to have lost the ability to write proper English in the last couple of days :(
[11:35] <cpaelzer> I realize that for a non native speaker too and two sound similar, but you ?
[11:35]  * cpaelzer checks if rbasak has fever
[11:35] <rbasak> They sound the same for me too
[11:35] <rbasak> I think the typing part of my brain just doesn't do grammar and just types what it hears me say internally or something.
[11:35] <cpaelzer> but for you correct words should flow out of your soul, and not go the "sounds like, could be, lets write that" process
[11:36] <cpaelzer> I'll check the ppa later on
[11:36] <cpaelzer> rbasak: can I just check bionic ?
[11:37] <rbasak> Sure
[11:37] <rbasak> I only expect to upload Bionic anyway
[11:37] <rbasak> For the older series there's the PPA. I've never done anything more than that.
[12:31] <cpaelzer> rbasak: tests complete
[12:31] <cpaelzer> rbasak: http://paste.ubuntu.com/26540860/
[12:31] <cpaelzer> rbasak: I'll have a new MP soon for the other issue I found (arm64 only)
[12:35] <cpaelzer> rbasak: fix is here https://code.launchpad.net/~paelzer/uvtool/+git/uvtool/+merge/337352
[12:36] <cpaelzer> rbasak: if you are doing the effort to push a new ver anyway we should include that right away :-)
[12:36] <cpaelzer> I missed that when we did initial arm support as my /tmp was set up special
[12:36] <cpaelzer> but on my new maas deployed arm system I today saw the issue
[12:36] <cpaelzer> anyway fix is easy, please review and merge rbasak
[12:40] <rbasak> cpaelzer: merged and pushed
[12:41] <rbasak> cpaelzer: do you want a PPA rebuild? Or are you happy for an upload without that?
[12:41] <cpaelzer> the fix is trivial and I tested by changing the template locally
[12:41] <rbasak> OK I'll upload
[12:41] <cpaelzer> so unless there is a typo it is good
[12:42] <cpaelzer> you might check if the xml is still valid xml
[12:42] <cpaelzer> for typos on closing /> or such
[12:42] <cpaelzer> other than that good for upload I'd think
[12:43] <cpaelzer> checked it with xmllint in my branch
[12:43] <cpaelzer> it is good
[12:43] <cpaelzer> go for an uplaod rbasak
[12:50] <rbasak> Uploaded.
[13:05] <frickler> jamespage: are you planning to upload ceph-12.2.2 for artful, too? I need to rebuild ceph for our pike-uca, using the version from bionic fails because it depends on newer boost versions
[13:07] <tobasco> jamespage: was any gnocchi changes able to make it into queens m3, cannot see anything in the uca queens repo
[13:13] <frickler> jamespage: actually building 12.2.1 from artful fails on xenial+uca-pike, too. seems you have some special tricks to build these
[13:18] <frickler> found https://bugs.launchpad.net/cloud-archive/pike/+bug/1739002 , will comment there
[13:18] <ubottu> Launchpad bug 1739002 in ceph (Ubuntu Artful) "[SRU] ceph 12.2.2" [Undecided,Confirmed]
[13:21] <ahasenack> rbasak: hi, do you know if debian's new salsa infrastructure is taking MPs for packages?
[13:21] <ahasenack> it does look like it
[13:22] <rbasak> Generally yes, _if_ the maintainers have moved to salsa.
[13:23] <ahasenack> they have
[13:23] <ahasenack> ok, thx
[13:23] <ahasenack> should I file a corresponding debian bug?
[13:24] <ahasenack> I see salsa has its own "issues" tab
[13:24] <ahasenack> project in question is samba, and the vcs url in the package already points at salsa
[13:30] <rbasak> I don't think Debian has really figured out the answer to that yet :)
[13:32] <rbasak> Depending on the maintainer, I imagine a Debian BTS bug in addition to a salsa merge request is either an extra unnecessary thing to close or an essential thing to track everything that needs doing.
[13:32] <ahasenack> then I think a normal debian bug is still a good thing to have
[13:32] <ahasenack> if it's not figured out yet
[13:32] <ahasenack> I'm also checking for existing "issues" in these projects
[13:32] <ahasenack> I see none open
[13:33] <ahasenack> I also don't know if they merge-then-upload, or upload-then-merge
[13:33] <ahasenack> they might be staging commits in the git tree and then someone uploads eventually
[13:33] <rbasak> I imagine most salsa users would merge-then-upload
[13:33] <ahasenack> anyway, I'll experiment
[14:06] <ahasenack> cpaelzer: hi, do you know if uvt-kvm can create debian vms?
[14:11] <cpaelzer> ahasenack: if you have debian cloud images
[14:11] <cpaelzer> ahasenack: so no
[14:12] <ahasenack> k
[14:12] <cpaelzer> ahasenack: https://wiki.debian.org/KVM#Creating_a_new_guest
[14:13] <ahasenack> I'll try virt-install
[14:23] <mason> cpaelzer: Thank you for the clarification!
[14:26] <cpaelzer> better late than never mason :-)
[14:26] <cpaelzer> as an excuse - I was sleeping well while you discussed that :-)
[14:26] <mason> heh
[14:27] <mason> To balance things out, I was sleeping while you clarified.
[14:27] <cpaelzer> fair enough :-)
[14:29] <mason> cpaelzer: So, is this a virt-manager quirk, and I'd end up with the default if I build something with virt-install?
[14:30] <ahasenack> cpaelzer: hm, virt-install is not an automated install :/
[14:33] <cpaelzer> ahasenack: no it is not
[14:34] <cpaelzer> ahasenack: you realize why people love uvtool :-)
[14:34] <cpaelzer> well I do
[14:34]  * cpaelzer hugs rbasak for uvt-kvm
[14:34] <mason> Hrm, I've not heard of uvtool. Looking.
[14:34] <cpaelzer> mason: TL;DR - it is the "give me a ubuntu guest" command
[14:35] <mason> ah, kk
[14:36] <cpaelzer> mason: this is the three lines to a guest http://paste.ubuntu.com/26541379/
[14:36] <cpaelzer> from there you'll see the flexibility it provides if you often need to spawn guests base on cloud image
[14:37] <cpaelzer> s/this is/these are/
[14:37] <mason> Seeing a checkmark on a command line is unusual. But, neat.
[14:37] <cpaelzer> oh I might have copied to omuch :-)
[14:37] <cpaelzer> yeah kill from the bracket in front of the checkmark
[14:38] <mason> Alright, that makes it seem more approachable. :)
[14:38] <cpaelzer> my console reports last RC in this - checkmark is 0, otherwise it is  an x=$rc
[14:38] <mason> Oh, that's clever.
[14:39] <cpaelzer> and time when I did the command and command number for reference - the usual stuff
[14:39] <cpaelzer> normal people have nice office, we all have nice (and very different) console prompts :-)
[14:40] <mason> Mine is a boring PS1="$USER@$HOSTNAME$WIN\${PWD}\$ "
[14:41] <cpaelzer> still much better as a "cmd:>"
[14:54] <jamespage> frickler: use the version from the pike uca - it has a patch to use the bundled boost version
[14:55] <jamespage> tobasco: sorry I've been bogged down in unsticking a load of other bits
[15:00] <frickler> jamespage: oooh, nasty hack ;) well, at least you get more upstream-y packages that way I guess. thx for the hint
[15:01] <jamespage> frickler: https://code.launchpad.net/~ubuntu-cloud-archive/ubuntu/+source/ca-patches/+git/ca-patches
[15:01] <jamespage> contains series aligned patches required for backporting
[15:02] <jamespage> frickler: well if avoids a) patching for older boost and b) carrying boost in the UCA (which I won't do - we did it for trusty and it was a nightmare)
[15:08] <frickler> jamespage: yeah, I do see your point. I'm still wondering why ceph needs to be in UCA in the first place, though, that does cause some issues for our deployments
[15:09] <jamespage> frickler: well technically it might not need to be but it does create online intermediate update points for LTS users
[15:10] <frickler> jamespage: it also creates complicated upgrade scenarios when running a ceph cluster with mixed openstack and non-openstack use :(
[16:11] <tobasco> jamespage: okok
[16:12] <jamespage> tobasco: I have a time critical thing to get done today (summit talk submissions) so hopefully I'll get to it tomorrow
[16:12] <tobasco> jamespage: no worries, let me know if i can help with anything
[16:54] <ahasenack> rbasak: hm, that autopkgtest cmdline doesn't work so well out of the box
[16:54] <ahasenack> autopkgtest -U samba -- lxd images:debian/sid/amd64
[16:54] <ahasenack> ...
[16:54] <ahasenack> E: You must put some 'source' URIs in your sources.list
[16:54] <ahasenack> E: You must put some 'source' URIs in your sources.list
[16:54] <ahasenack> autopkgtest [14:53:13]: ERROR: testbed failure: rules extract failed with exit code 100 (apt failure)
[16:54] <ahasenack> afaik autopkgtest needs to change the image a bit, does it not?
[17:18] <rbasak> ahasenack: perhaps the images changed to drop the deb-src lines?
[17:18] <rbasak> I'm pretty sure it used to work.
[17:23] <rbasak> ahasenack: though I'm not really sure why autopkgtest needs deb-src lines.
[17:24] <ahasenack> there was another command which required src lines and I never understood why
[17:24] <ahasenack> ah, apt-get build-dep iirc
[17:25] <rbasak> build-dep needs to see the source package metadata to see the Build-Depends header which isn't available in binary package metadata.
[17:26] <rbasak> But autopkgtest shouldn't need that if it's only building from your .dsc.
[17:26] <ahasenack> but not when I'm using it like "apt-get build-dep ./"
[17:26] <rbasak> (from your _local_ dsc)
[17:26] <ahasenack> it just needs to peek into debian/control
[17:26] <rbasak> I didn't know it could do that.
[17:26] <rbasak> I guess that's a bug.
[17:26] <ahasenack> doesn't work in trusty, but xenial+ works
[17:26] <ahasenack> maybe something in between trusty and x also worked
[18:05] <ahasenack> meh
[18:05] <ahasenack> https://github.com/lxc/lxc/issues/1799
[18:05] <ahasenack> debci + lxc does not work out of the box
[18:06] <ahasenack> (and it does not have lxd support)
[18:33] <pankaj_> How to install modules in irssi. It is saying me to install Text::charwidth module.
[18:56] <ahasenack> rbasak: hey, got a good bug in my samba dep8 tests when running them on debian
[18:56] <ahasenack> cannot create /home/ubuntu/data: Directory nonexistent
[18:56] <ahasenack> :)
[18:56] <ahasenack> assumption about the ubuntu user being there :)
[18:59] <Odd_Bloke> smoser: Does sstream-query use GPG by default?
[19:02] <smoser> Odd_Bloke: no.
[19:02] <smoser> well... yes.
[19:03] <smoser> by default it uses streams/v1/index.sjson
[19:03] <Odd_Bloke> Pick one. ;)
[19:03] <smoser> and verifies that signed inline json with 'gpgv' (from gpg-verify)
[19:03] <smoser> and cries if it doesnt work
[19:03] <smoser> it does not by default assume any keyring not assumed by gpgv.
[19:04] <smoser> ie, it wont use --keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg
[19:04] <Odd_Bloke> So why doesn't it cry all the time, given most people don't have the appropriate key?
[19:05] <smoser> but if you hae added those keys to the keyring ~/.gpg then those will be used.
[19:05] <Odd_Bloke> Or is this the yes/no duality? :p
[19:05] <smoser> well, it does cry most of the time.
[19:06] <smoser> http://paste.ubuntu.com/26542581/
[19:07] <smoser> you can pass '--no-verify' and it wont verify
[19:07] <Odd_Bloke> OK, so maybe it just works for me because I've done something in the past.
[19:07]  * Odd_Bloke checks in a container.
[19:09] <Odd_Bloke> OK, yes, there we go.
[19:09] <smoser> Odd_Bloke: i assume 'gpg --list-public-keys' shows the 4A3CE3CD565D7EB5C810E2B97FF3F408476CF100 for you
[19:09] <smoser> or D2EB44626FDDC30B513D5BB71A5D6C4C7DB87C81
[19:09] <smoser> whichever one its signed by
[19:10] <Odd_Bloke> Yep, the former.
[19:10] <Odd_Bloke> smoser: Thanks for the help. :)
=== E-pod is now known as EP0D
=== TJ- is now known as Guest27109
=== TJ_Remix is now known as TJ-
[22:39] <blizzow> I'm running a bunch of 16.04 servers with the 4.13.0-32-lowlatency #35~16.04.1-Ubuntu SMP PREEMPT (hwe-16.04-lowlatency-edge) kernel. The spectre/meltdown checker is telling me I'm still vulnerable and I've downloaded all the latest and greatest updates. My BIOS is up to date as well. What can I do to mitigate the problem?
[22:39] <sarnold> hey blizzow, I've got to run, hope this helps https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown
[22:42] <mason> blizzow: What bits are showing vulnerable?
[22:45] <sdeziel> blizzow: the 4.13 kernel with mitigation for all 3 vulns is currently in artful-proposed. Presumably, it will land shortly in artful-updates and will then be backported to 16.04
[22:45] <mason> Oh, didn't see the newer kernel.
[22:46] <sdeziel> blizzow: otherwise, you may want to use that PPA https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/spectre/?field.series_filter=xenial
[22:49] <blizzow> the script puts out that Spectre Variant 2 is still vulnerable.
[22:50] <blizzow> I think that's the one that requires a microcode update and Dell doesn't seem to have released a new BIOS yet for the poweredge 620.
[22:51] <blizzow> I also have some supermicros that I have to look up.
[22:52] <sdeziel> blizzow: retpoline mitigations do not depend on updated microcode
[22:53] <sdeziel> blizzow: this machine runs an old microcode but has the 4.4 kernel from the above PPA: https://paste.ubuntu.com/26543638/
[22:57] <blizzow> I guess I'm not understanding what you're trying to tell me sdeziel. I am running the HWE lowlatency 4.13 kernel and the table (column 5 row 2) shows that spectre variant 2 is "F" (updates have been published to mitigate the issue but require updated firmware/microcode).
[22:58] <blizzow> I have to install this script to get a kernel with retpoline?
[22:58] <blizzow> sorry *PPA* not script.
[22:59] <sdeziel> blizzow: what I'm saying is that a retpoline enabled kernel (from the PPA) should mitigate spectre V2 (https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown#Pre-release_Updates_Available_For_Testing)
[22:59] <sdeziel> blizzow: so yeah :)
[22:59] <sdeziel> gotta run
[22:59] <blizzow> Is there a due date for HWE lowlatency with retpoline to be released to the standard repos without using the PPA? I'm not too keen on adding a new ppa to all of my servers.
[23:01] <sdeziel> blizzow: as I said, it's currently baking in artful-proposed
[23:01] <sdeziel> I am not aware of an official due date, sorry
[23:01] <sdeziel> blizzow: maybe someone in #ubuntu-hardened will be able to tell you