20:03:12 <wilcal> #startmeeting
20:03:12 <Inigo_Montoya> Meeting started Thu Jan 11 20:03:12 2018 UTC.  The chair is wilcal. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:12 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:03:23 <wilcal> #chair lewyssmith
20:03:23 <Inigo_Montoya> Current chairs: lewyssmith wilcal
20:03:35 <wilcal> #topic Who's new?
20:03:42 <wilcal> anyone new?
20:04:06 <lewyssmith> If anyone here is new to one of these meetings, please do speak up.
20:04:49 <lewyssmith> Looks not...
20:05:02 <wilcal> Lets get right to it then
20:05:10 <wilcal> #topic testing kernel 4.14.13-1
20:05:26 <wilcal> https://bugs.mageia.org/show_bug.cgi?id=22334
20:05:28 <[mbot> [ 22334 – Update request: kernel 4.14.13 ]
20:05:36 <brian_> it's been interesting, but for me working
20:05:45 <brian_> but at moment testing mga5's
20:05:48 <wilcal> I've spent all morning over a Hot testing computer on this one in frustration
20:06:01 <wilcal> actually a couple of computers
20:06:03 <brian_> :0(
20:06:07 <wilcal> overall it's fine
20:06:12 <lewyssmith> I have nothing to say beyond ... more kernels! Which should one start with?
20:06:27 <wilcal> except when you mix, as you guessed, Vbox and nvidia in there
20:06:59 <lewyssmith> Do you mean Vbox host + nVidia?
20:06:59 <wilcal> I just added a bunch of comments at the end of this bug so do look them over and add what you can
20:07:05 <wilcal> yes
20:07:29 <tmb> no such issues here
20:07:36 <wilcal> It appears I cannot create a working vbox client on my Intel i7 Vbox nvidia platform
20:07:46 <wilcal> It has to be a brand new client
20:07:54 <lewyssmith> I feel guilty not having nVidia to share the suffering a bit.
20:08:12 <wilcal> I used the easiest iso the m6 x86_64 Live-DVD
20:08:36 <wilcal> If I create the client on a non-nvidia platform it works fine
20:09:03 <wilcal> even if I export that to a vdi and crate a new client with that on the nvidia platform
20:09:18 <wilcal> that works fine too
20:09:31 <wilcal> so I gotta push away from the table for a day or two on this one
20:09:54 <lewyssmith> Very curious. There should be nothing of nVidia in the client, surely.
20:10:08 <tmb> Anyway, we can/have to expect some issues with the kernel lockdown... but we will have to live with it so far as they fix extremely critical issue
20:10:09 <wilcal> I saw this with the last kernel change and kind didn't believe it so I figured it was an error on my part
20:10:12 <wilcal> maybe still is
20:10:24 <wilcal> I agree with that tmb
20:10:48 <wilcal> I can work around this for now and just create clients on my non-nvidia platform
20:10:52 <lewyssmith> Hello Ben.
20:11:03 <wilcal> makes me crazy
20:11:10 <tmb> problem is the fallout of this security issues will expand to months/years... depending issue...
20:11:32 <lewyssmith> wil Please do not go crazy, Bill: we need you.
20:11:41 <wilcal> I'm sure others will see what I'm seeing and something will get fixt
20:11:43 <wilcal> fixed
20:11:45 <Benmc> Lewis,  Qa, Good morning
20:12:03 <hviaene|2> But we cann't go on fixing M5, cann't we?
20:12:09 <tmb> upstream is now on revision 8 or so with the spectre parts... but we still need the matching stuff for gcc/binutils too...
20:12:32 <wilcal> Still more kernels on the way right tmb?
20:12:52 <tmb> no, for mga5 we only fix the most easy exploited meltdown
20:13:09 <lewyssmith> hviaene|2, I think we are agreed to see the vital fixes done for M5, Herman.
20:13:13 <wilcal> And that's the end for M5 for sure?
20:13:25 <hviaene|2> I hopr-pray
20:13:27 <tmb> then we lock mga5 back down.
20:13:28 <lewyssmith> Essentially.
20:13:52 <wilcal> If you have a problem with Vbox on M5 the fix will be to move to M6
20:14:08 <tmb> becuse there is not even a guarantee yet that the spectre fixes will even land in upstream 4.4 as they need a lot of stuff from newer kernels...
20:14:21 <lewyssmith> I have no problem with M5 updates beyond the extra work. I keep M5 anyway.
20:14:30 <wilcal> And none of this is being exploted yet right?
20:15:01 <tmb> the poc for meltdown is published, so ....
20:15:16 <wilcal> so.... it's a maybe for now
20:15:32 <tmb> the other bits are only "spectre-like" exploits so far...
20:16:09 <wilcal> We're kinda like waiting for the "Mother" of all explots to appear
20:16:18 <tmb> it will get fixed in 4.14 and newer kernels + more microcode updates depending on Intel/AMD work
20:16:37 <lewyssmith> No exploit cannot affect most users.
20:17:01 <wilcal> Cross fingers my Raspberry Pi won't get bonked
20:18:20 <wilcal> So I will test M5 sans Vbox and leave it at that
20:18:32 <tmb> also note the nvidia-current is for mga5 too as it exposes memory the same way
20:18:56 <wilcal> I am really getting to dislike nvidia
20:19:05 <tmb> so some test on atleat x86_&4 would be good
20:19:27 <lewyssmith> Is M5 more urgent than M6?
20:19:34 <wilcal> Do we still have a large base of nvidia users
20:19:41 <wilcal> probably so
20:20:04 <brian_> yes
20:20:11 <hviaene|2> Yes, me, but not on my test machines
20:20:38 <tmb> nah, I think we can prioritize mga6 but it depends on how fast you want to close down mga5 :)
20:21:00 <lewyssmith> ASAP.
20:21:10 <wilcal> Anyway keep work'n it as the list, bless David, has gotten quite short
20:21:36 <wilcal> Lets move away from this
20:21:37 <wilcal> #topic Testing Updates & Backports
20:21:43 <wilcal> not kernel testing
20:21:58 <wilcal> I see Flash has reared it's ugly head again
20:22:14 <wilcal> Easy test with notes from previous testing
20:22:36 <wilcal> FWIW brick wall EOL Jan 2020 for Flash
20:22:50 <lewyssmith> Good news indeed.
20:23:01 <wilcal> Browser won't support it from that date on
20:23:13 <wilcal> Browsers that is as in all of them
20:23:20 <hviaene|2> All browsers???
20:23:23 <wilcal> Yes
20:23:33 <hviaene|2> I wonder
20:23:42 <lewyssmith> [wise]
20:23:49 <wilcal> I'm sure people will find a way around that but officially Adobe brick wall EOL it
20:24:01 <wilcal> Hello Luigi
20:24:02 <lewyssmith> Welcom David.
20:24:08 * Luigi12_work has been spotted
20:24:15 <wilcal> Thank you for being here
20:24:24 <tmb> btw, I've also pushed new graphical stack to mga6 (mesa/libdrm/amdgpu/ati/intel/...) to add more hw support matching the 4.14 series kernels,  but I wont assign it to QA yet as current kernel stuff is more important
20:24:35 <Luigi12_work> yeah I saw your e-mail, figured I'd stop by just in case you need me
20:24:56 <wilcal> We're deep in the weeds on the Kernel things
20:24:58 <lewyssmith> Nice to have you - so long as you not a bringer of doom.
20:25:07 <Luigi12_work> nah I don't have anything
20:25:12 <wilcal> Actually moved on
20:25:24 <hviaene|2> Phew
20:25:28 <wilcal> Any thoughts Luigi
20:25:30 <lewyssmith> Luigi12_work, Are you satisfied with the state of play?
20:26:47 <Luigi12_work> I was a little disappointed to see that we haven't picked up any kernel patches for Spectre, but not really surprised
20:27:17 <brian_> what I've read, spectre is pretty complicated to clean-up, even more so than meltdown
20:27:18 <Luigi12_work> fortunately that one's a lot harder to exploit, Meltdown was the really big deal
20:27:30 <Luigi12_work> brian_: oh yeah, inifinitely more complicated to clean up
20:27:32 <lewyssmith> It seemed more difficult & more obscure.
20:27:54 <Luigi12_work> the patches other distros added to their kernels is very preliminary work for it, but there's also adjustments being made in web browser and other apps
20:28:02 <tmb> yep, that's why I'm waiting it out... spectre set is currently on revision 8+ or so...
20:28:03 <brian_> Luigi - my interpretation of meltdown is more of an exposure on machines supporting VM type multi-user work.  What's your take?
20:28:16 <Luigi12_work> there will also be adjustments made to apps to mitigate the performance issues, so it'll be an ongoing thing for a while
20:28:55 <Luigi12_work> brian_: actually the other way around
20:29:27 <Luigi12_work> Meltdown lets a process read from kernel space's memory, Spectre can allow reading memory from other processes or from beyond VM boundaries
20:29:33 <brian_> so more risk on individual machines and hardware
20:29:36 <tmb> there will be patches for toolchain (binutils/gcc) to add full support for spectre but that to is still going through reviews
20:30:10 <Luigi12_work> yeah that too, and then everything will eventually need to be recompiled with those changes (but just recompiling kernel and a few other select things with the patched compilers can help a lot)
20:30:42 <Luigi12_work> but Meltdown is more risk in terms of being much easier to exploit, but it was also much easier to fix, which our current set of kernel updates will do
20:31:04 <Luigi12_work> Spectre has more far-ranging consequences if you can exploit it, but that's a lot harder (but as you said, it's harder to clean up too)
20:31:10 <tmb> then there are wip in progress for libvirt/qemu/xen to properly support the hardened kernels/microcodes/... so it will be fun...
20:31:18 <lewyssmith> tjandrews, Welcome TJ.
20:31:25 <tjandrews> Hi.
20:31:28 <Luigi12_work> yeah and our libvirt package in mga6 won't even build right now
20:31:43 <Luigi12_work> it's not obvious to me why it won't
20:31:51 <wilcal> gracious
20:32:00 <hviaene|2> So assembler code could get around all corrective gcc etc ...???
20:32:03 <Luigi12_work> NVIDIA also released 384.111 to cope with Spectre changes
20:32:11 <tmb> Luigi12_work, yeah, I checked it out and have mitigation fixes added too but it breaks tests so they need to be adjusted a bit
20:32:35 <Luigi12_work> yeah, and it was already breaking before you added anything
20:32:45 <tmb> Yep, I have 384.111 in testing for both mga5/6
20:32:50 <Luigi12_work> the patch I added was only a one-liner, so I wouldn't think that would have broken it
20:33:37 <Luigi12_work> the Linux community has done a pretty amazing job dealing with all this stuff so far
20:33:48 <lewyssmith> So quickly.
20:33:53 <kekePower> so many smart folks out there
20:33:56 <kekePower> I'm amazed
20:34:19 <lewyssmith> Hello Leen!
20:34:20 <tmb> depending on the needed changes for properly supporting spectre fixes/bits... I'm thinking of simplly breaking current version policy and update to properly fixed code from upstream...
20:34:35 <tarazed> Sorry I'm late.
20:34:39 <Luigi12_work> tmb: for which package?
20:34:48 <lewyssmith> tmb, Sounds like a good idea to me.
20:34:59 <tmb> Luigi12_work, for libvirt/qemu/xen
20:35:04 <Luigi12_work> tmb: yeah I think that's a good idea
20:35:28 <tarazed> Hi Leewis
20:35:36 <Luigi12_work> it's good we've updated the kernel to 4.14.x as it is.  I saw greg-kh's warnings about the backports to older kernels.
20:36:35 <tmb> yeah... and he even pointed out he might switch to 4.15 or so as LTS in a mail thread depending of how the securitty fixes go :)
20:37:04 <wilcal> We going to see kernels every couple weeks or so?
20:37:11 <Luigi12_work> tmb: oh wow
20:37:33 <brian_> wow
20:37:35 <tmb> wilcal, probably
20:37:46 <wilcal> All critical probably
20:37:50 <lewyssmith> wilcal, I wondered whether we could agree among ourselves who test what.
20:37:51 <Luigi12_work> wilcal: yeah probably for the next couple months
20:38:04 <Luigi12_work> not critical necessary, just fixing fallout from the new changes, mainly
20:38:13 <wilcal> Not a good thing for me. Notes at end of meeting
20:38:14 <lewyssmith> There are simply too many.
20:38:46 <tarazed> As long as we cover a range of hardware
20:38:50 <lewyssmith> tmb, Could we suspend linus & tmb kernels until things settle down?
20:39:11 <brian_> so - could this be a planned schedule - a monthly release of a kernel fix, versus rushing a weekly in
20:39:13 <brian_> ?
20:39:36 <kekePower> tmb: in light of this possibility, is it an idea to try out 4.15-rc now?
20:39:56 <brian_> <<of course>> unless there known exploits
20:39:58 <tmb> lewyssmith, yeah, I will keep them updated but I can keep them in testing only
20:40:19 <lewyssmith> It would help a lot not having to test them all the time.
20:40:31 <lewyssmith> Unntil the dust settles.
20:40:38 <brian_> agreed
20:40:39 <tmb> as the core kernel is the most importan one... as long as we get the 4.14.13 validated
20:41:28 <brian_> :wilcal - I have nvidia antiques, but nothing with VBox capability on ... unless I steal my son's machine
20:41:40 <tmb> (to close down the meltdown on all kernels)
20:41:51 <wilcal> I would be agreeable to releasing the present kernel bug knowing of the nvidia issue
20:42:06 <brian_> ...with vbox new builds
20:42:21 <wilcal> Ya it's a problem a very confusing one
20:42:42 <wilcal> https://bugs.mageia.org/show_bug.cgi?id=22334
20:42:44 <[mbot> [ 22334 – Update request: kernel 4.14.13 ]
20:42:45 <tmb> I also have a feeling we will see new virtualbox next week when nect oracle cpu is published...
20:43:08 <wilcal> wilcal hangs his head :-0
20:43:43 <Luigi12_work> yeah probably
20:43:43 <lewyssmith> So: I take it that the 4.4.13 kernels - all of them - 'fix' the Meltown issue.
20:43:55 <Luigi12_work> yes
20:44:02 <wilcal> And more a coming
20:44:02 <Luigi12_work> as do the 4.4.111
20:44:20 <lewyssmith> Just to stop my head spinning.
20:44:22 <brian_> dumb question - does the kernel disable meltodwn by default on AMD?
20:44:57 <tmb> brian_, yep
20:45:11 <brian_> cool!
20:45:12 <Luigi12_work> meltdown didn't affect most AMDs I thought...
20:45:24 <Luigi12_work> oh you mean does it disable the mitigations for performance reasons
20:45:26 <Luigi12_work> yeah it does
20:45:27 <brian_> yes, but code might still be in loop otherwise
20:45:50 <tmb> according to what is know so far AMD is not vulnerable to meltdown... but time will tell
20:46:06 <lewyssmith> {Smug]
20:46:11 <brian_> that's my take on meltdown.  Was curious if Kernel did that or if we needed the parameter
20:47:06 <Luigi12_work> the parameter is for disabling it on intel if you feel you're not exposed to the issue
20:47:39 <brian_> I run more intel than AMD these days ....
20:48:03 <tmb> note that the microcode update also mitigates some parts of spectre and adds bits to support mitigations for kernels (and to get some performance back)
20:48:31 <Luigi12_work> maybe my newest PC might have updated firmware, but they probably haven't gotten to the CPUs in most of my machines
20:48:34 <brian_> good as I did see pauses in firefox after patch
20:48:46 <brian_> on intel i3 2100 series
20:49:18 <brian_> my new stuff is gen-7, but not touchable yet
20:49:18 <Luigi12_work> Firefox 52.6 will just have an adjustment to make the timing API less precise, so you can't use it for timing attacks
20:49:28 <tmb> brian_, you think that is bad... some network services looses up to 50% of performance due to this :)
20:49:54 <brian_> yeah - servers for net, io and dbms sound like nightmares
20:50:01 <wilcal> AWS?
20:50:03 <tmb> Like haproxy running on vm setups
20:50:06 <hviaene|2> I have to go, g'night all
20:50:10 <brian_> night
20:50:14 <wilcal> night
20:50:37 <wilcal> Amazon Web Services people have got to be sweating all this
20:51:07 <tmb> wilcal, not they, but their customers that have to buy more performance...
20:51:52 <brian_> yeah  - plus google, M$
20:52:01 <wilcal> I remember back in the day when you had to live within 1028 bytes :-))
20:52:05 <brian_> hi everyone - gotta drop
20:52:11 <tmb> anyway... should we get back on topic for non-kernel stuff :)
20:52:12 <wilcal> bye brian
20:52:17 <lewyssmith> Goodbye Brian.
20:52:24 <wilcal> Ya lets move on
20:52:29 <wilcal> too stressful
20:52:39 <lewyssmith> wilcal, Shall we kill this topic now & move on?
20:52:40 <wilcal> #topic Anything else?
20:52:49 <lewyssmith> Yes - you move?
20:52:55 <wilcal> Couple of announcements from me
20:53:03 <wilcal> Starting on Mon 22 Jan and running probably until the following Monday, 29 Jan my availablity will be very sporatic as I will be moving. I will for sure not be here on Thurs 25 Jan ( move in day ). I should be fully moved in and settled down by Thurs 1 Feb. All my test computers should ( fingers crossed ) be up and running by then.
20:53:30 <lewyssmith> Best of luck with it all.
20:53:32 <wilcal> and to answer the obvious
20:53:34 <wilcal> I am moving to a City I have been to many times during my Career. I am moving to ( North ) Las Vegas NV. About 8 miles North of "The Strip". There is a very nice retirement community there and the cost of living is low, stable, quiet and safe. A person would be fine there as long as they didn't partake of the obvious that's going on all around them.
20:54:15 <wilcal> And ya it gets really hot there May -> Sept
20:54:20 <wilcal> 100's
20:54:37 <lewyssmith> !
20:55:11 <tjandrews> So, are you going to change your nickname? How about "Vegas Bill?"
20:55:28 <wilcal> Better would be "Sin City Bill" :-))
20:55:28 <kekePower> I've heard Houston only has 3 seasons, Spring, Summer and Houston
20:55:55 <wilcal> Houston was one of my choices when I came out of School in 68
20:55:57 <tmb> wilcal, you'll need watercooling for your computers then :)
20:56:15 <kekePower> wilcal: and BeerCooling for yourself
20:56:17 <wilcal> Air Conditioning for sure
20:56:49 <wilcal> Always something to do, 24/7/360 in Vegas
20:57:07 <wilcal> Anything else
20:57:15 <lewyssmith> Not frp me.
20:57:20 <wilcal> I'm done
20:57:27 <tmb> not for me
20:57:28 <tjandrews> We have four seasons here. Not Winter, Almost Winter, Winter, and Mud.
20:57:35 <wilcal> bye all count down time
20:57:38 <wilcal> T-5
20:57:42 <kekePower> tjandrews: heh
20:57:45 <lewyssmith> Goodby everyone.
20:57:48 <wilcal> T-4
20:57:49 <kekePower> until next time
20:57:52 <tarazed> Cheerio
20:57:52 <wilcal> T-3
20:57:56 <wilcal> T-2
20:58:00 <wilcal> T-1
20:58:03 <wilcal> bye all
20:58:05 <wilcal> #endmeeting