| === amitk_ is now known as amitk | ||
| zyga | which of the kernel trees on kernel.ubuntu.com/git contains the official 16.04 LTS kernel? | 09:27 |
|---|---|---|
| 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:29 |
| zyga | (or if there is one big repo, not sure, for all of ubuntu kernels | 09:30 |
| 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:32 | |
| zyga | apw: and which one should I track? | 09:33 |
| apw | https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial | 09:33 |
| 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:34 |
| apw | zyga, the kernel.u.c repos are mirrors of launchpad for those with old links | 09:35 |
| zyga | ahh | 09:35 |
| zyga | thanks | 09:35 |
| LocutusOfBorg | hello, do you have any ETA for kernel 4.12 in artful? | 12:23 |
| LocutusOfBorg | just to understand when I can send you the virtualbox updated kernel modules | 12:24 |
| apw | LocutusOfBorg, just get the bits uploaded to artful, they would be backwards compatible right ? | 12:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| LocutusOfBorg | ack | 12:34 |
| LocutusOfBorg | seems a good plan, thanks | 12:34 |
| 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:12 |
| ubot5 | bug 1700692 in libreoffice (Ubuntu) "FTBFS on i386: dbaccess_RowSetClones unit test segfaults" [Critical,Triaged] https://launchpad.net/bugs/1700692 | 16:12 |
| cascardo | funny, that expand_stack code is basically what we tried to fix with 4.4.0-83 | 16:18 |
| apw | cascardo, does that imply we know what that expand_stack code looks like ? | 16:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| smb | cascardo, just to point out that these are i386/32bit builds. 32bit is often fragile and nowadays less well looked after | 16:47 |
| 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 | 16:59 |
| cascardo | ah... | 17:13 |
| cascardo | worth taking a look at that | 17:13 |
| 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 | 18:38 |
| cascardo | same thing with the jsvc reproducer | 19:06 |
| === enick_370 is now known as RAOF | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!