=== amitk_ is now known as amitk [09:27] which of the kernel trees on kernel.ubuntu.com/git contains the official 16.04 LTS kernel? [09:29] zyga, t [09:29] zyga, the xenial GA kernel ? [09:29] t? [09:29] typeo [09:29] the 4.8 kernel that one can get on xenial [09:30] (or if there is one big repo, not sure, for all of ubuntu kernels [09:32] 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] apw: and which one should I track? [09:33] https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial [09:34] oh, so kernel is now on launchpad? [09:34] 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] zyga, was the very first thing ever pushed to git.launchpad.net which was not for testing [09:34] apw: how does it releat to k.u.c/git? [09:35] zyga, the kernel.u.c repos are mirrors of launchpad for those with old links [09:35] ahh [09:35] thanks [12:23] hello, do you have any ETA for kernel 4.12 in artful? [12:24] just to understand when I can send you the virtualbox updated kernel modules [12:29] LocutusOfBorg, just get the bits uploaded to artful, they would be backwards compatible right ? [12:30] LocutusOfBorg, we sync with your packages periodically [12:30] 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] the problem is that virtualbox should be released soon(TM), but I don't know when [12:31] and I prefer to give you the updated modules when it comes out [12:31] usually this is a matter of some days after the new kernel is released [12:32] 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] but as soon as you have bits we can consume them in our ppa builds [12:34] ack [12:34] seems a good plan, thanks [16:12] 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:12] bug 1700692 in libreoffice (Ubuntu) "FTBFS on i386: dbaccess_RowSetClones unit test segfaults" [Critical,Triaged] https://launchpad.net/bugs/1700692 [16:18] funny, that expand_stack code is basically what we tried to fix with 4.4.0-83 [16:19] cascardo, does that imply we know what that expand_stack code looks like ? [16:20] oSoMoN, upstream wnat to know what that expand_stack code thinks it is trying to do [16:20] so they can decide if it is sensible or not [16:22] 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] apw: it's almost the same as the test code I sent on our discussion [16:22] the one sbeattie wanted to include in the testing [16:23] the thing is: the reproducer works fine on the fixed kernel [16:23] 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] no, not that one [16:24] the code just uses /proc/self/maps to look for the stack start and touch it [16:24] hmm [16:24] and you know this test does that ? [16:25] 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] apw: that's what jvm does when creating the main thread stack [16:26] the good news is that the failure is 100% reproducible on launchpad builders [16:26] 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] cascardo, just to point out that these are i386/32bit builds. 32bit is often fragile and nowadays less well looked after [16:59] 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] so 4.4.0-83.106 appears to have reliably fixed the issue for amd64, but not for i386 [17:13] ah... [17:13] worth taking a look at that [18:38] 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] same thing with the jsvc reproducer === enick_370 is now known as RAOF