[09:27] <zyga> which of the kernel trees on kernel.ubuntu.com/git contains the official 16.04 LTS kernel?
[09:29] <apw> zyga, t
[09:29] <apw> zyga, the xenial GA kernel ?
[09:29] <zyga> t?
[09:29] <apw> typeo
[09:29] <zyga> the 4.8 kernel that one can get on xenial
[09:30] <zyga> (or if there is one big repo, not sure, for all of ubuntu kernels
[09:32] <apw> zyga, there is one for each series yes
[09:32]  * zyga thinks about editing the description fields to cleary differentiate *personal* development repositories from official ubuntu kernel repositories
[09:33] <zyga> apw: and which one should I track?
[09:33] <apw> https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
[09:34] <zyga> oh, so kernel is now on launchpad?
[09:34] <apw> zyga, there is no branch (now) for the 4.8 kernel as that is about to die, but there are tags for the versions we have published
[09:34] <apw> zyga, was the very first thing ever pushed to git.launchpad.net which was not for testing
[09:34] <zyga> apw: how does it releat to k.u.c/git?
[09:35] <apw> zyga, the kernel.u.c repos are mirrors of launchpad for those with old links
[09:35] <zyga> ahh
[09:35] <zyga> thanks
[12:23] <LocutusOfBorg> hello, do you have any ETA for kernel 4.12 in artful?
[12:24] <LocutusOfBorg> just to understand when I can send you the virtualbox updated kernel modules
[12:29] <apw> LocutusOfBorg, just get the bits uploaded to artful, they would be backwards compatible right ?
[12:30] <apw> LocutusOfBorg, we sync with your packages periodically
[12:30] <apw> LocutusOfBorg, or to look at it another way, the 4.12 kernel is evolving in our unstable PPA so you could give us what we need for that
[12:31] <LocutusOfBorg> the problem is that virtualbox should be released soon(TM), but I don't know when
[12:31] <LocutusOfBorg> and I prefer to give you the updated modules when it comes out
[12:31] <LocutusOfBorg> usually this is a matter of some days after the new kernel is released
[12:32] <apw> LocutusOfBorg, we are pusihng to get 4.11 in the archive, so iw oudl not expect to be trying to reupdate that in the next week
[12:32] <apw> but as soon as you have bits we can consume them in our ppa builds
[12:34] <LocutusOfBorg> ack
[12:34] <LocutusOfBorg> seems a good plan, thanks
[16:12] <oSoMoN> smb, apw: following up on the conversation we had yesterday about bug #1700692, what would be the best way to make a case for it upstream?
[16:18] <cascardo> funny, that expand_stack code is basically what we tried to fix with 4.4.0-83
[16:19] <apw> cascardo, does that imply we know what that expand_stack code looks like ?
[16:20] <apw> oSoMoN, upstream wnat to know what that expand_stack code thinks it is trying to do
[16:20] <apw> so they can decide if it is sensible or not
[16:22] <smb> apw, roughly I would think that one would need the test that fails in a isolated way (described so one can run things without hunting for missing pieces). And then they surely want some prove that the actual application suffers from the problem, too
[16:22] <cascardo> apw: it's almost the same as the test code I sent on our discussion
[16:22] <cascardo> the one sbeattie wanted to include in the testing
[16:23] <cascardo> the thing is: the reproducer works fine on the fixed kernel
[16:23] <apw> cascardo, where they were assuming they could expand down two pages or something right, when the stack pointer is not in the page
[16:23] <cascardo> no, not that one
[16:24] <cascardo> the code just uses /proc/self/maps to look for the stack start and touch it
[16:24] <apw> hmm
[16:24] <apw> and you know this test does that ?
[16:25] <oSoMoN> isolating the test case is not gonna be an easy task, as it involves the libreoffice launcher, which is quite a beast (and my knowledge of that codebase is inexistent)
[16:25] <cascardo> apw: that's what jvm does when creating the main thread stack
[16:26] <oSoMoN> the good news is that the failure is 100% reproducible on launchpad builders
[16:26] <cascardo> so it affected any jvm... now, that's something else in this libreoffice build test, if it really fails with 4.4.0-83
[16:47] <smb> cascardo, just to point out that these are i386/32bit builds. 32bit is often fragile and nowadays less well looked after
[16:59] <oSoMoN> one potentially interesting data point is that the same test was failing on amd64 when I built a snap with kernel 4.4.0-81.104, and it passed with 4.4.0-83.106
[16:59] <oSoMoN> so 4.4.0-83.106 appears to have reliably fixed the issue for amd64, but not for i386
[17:13] <cascardo> ah...
[17:13] <cascardo> worth taking a look at that
[18:38] <cascardo> hum... reproducer works on i686 kernel 4.4.0-79, breaks in 4.4.0-81 and works again in 4.4.0-83
[19:06] <cascardo> same thing with the jsvc reproducer