| sforshee | LocutusOfBorg: reverted the patch, thanks for the heads up | 13:28 |
|---|---|---|
| LocutusOfBorg | thanks sforshee | 13:54 |
| LocutusOfBorg | sforshee, just to understand, in case it fails, will some automatic test notify me? | 13:57 |
| LocutusOfBorg | I double checked and virtualbox 6.2.14 in groovy release doesn't call the two functions anymore | 13:57 |
| LocutusOfBorg | but I don't want to break the world :D | 13:57 |
| LocutusOfBorg | (Debian never applied the patch and sid has 5.8.7 or whatever) | 13:58 |
| sforshee | LocutusOfBorg: the automated testing will check that the dkms packages still build, I don't think you will be automatically notifiied but it will block the kernel from promoting, so we will see it and let you know | 14:14 |
| LocutusOfBorg | thanks! I'm pretty sure it will work | 15:14 |
| LocutusOfBorg | but better safe than sorry | 15:14 |
| tyhicks | hello! I'm thinking back, trying to remember the packages that typically needed to be updated when a new enablement kernel is introduced into a given Ubuntu release (or a new upstream kernel is introduced into the dev release) | 18:20 |
| tyhicks | the DKMS modules obviously are the majority of the work and, for my purposes, I'm just lumping them all into one bucket | 18:21 |
| tyhicks | there's the stuff in linux-tools-* that gets updated lockstep with the kernel (such as perf, usbip, etc.) | 18:21 |
| tyhicks | what I'm trying to remember are the additional packages spread thruoghout the archive | 18:22 |
| tyhicks | I came up with crash, kexec-tools, makedumpfile, ktap, and kpatch | 18:23 |
| tyhicks | are there any others that commonly need to be updated when bumping from 5.x to 5.y? | 18:23 |
| tyhicks | sforshee, cascardo, mhcerri: ^ you folks would have more recent memories of this work than I do | 18:25 |
| sforshee | tyhicks: the big one the comes to mind is zfs | 18:25 |
| tyhicks | I had forgotten about that one | 18:26 |
| tyhicks | I'm primarily trying to inventory userspace code that needs to move forward with new kernel releases | 18:26 |
| sforshee | it is mostly dkms stuff | 18:27 |
| tyhicks | sforshee: can you think of anything that broke that's outside of the DKMS module and kernel tool categories? | 18:27 |
| sforshee | tyhicks: I was about to say iproute2, usually not because it broke but to support new things | 18:28 |
| sforshee | otherwise I can't think of anything which we consistently need to update | 18:28 |
| tyhicks | sforshee: I was curious about that one, too. I'll go through the iproute2 changelog. | 18:28 |
| sforshee | just things which show up with test failures from time to time | 18:28 |
| tyhicks | sforshee: yeah, those are the ones that I don't know how to identify very well | 18:29 |
| sforshee | they are hard to identify, and very often if they break it's because the kernel regressed somehow | 18:29 |
| sforshee | you can look at the adt matrix to see the ones we are testing against - https://people.canonical.com/~kernel/status/adt-matrix/groovy-linux-meta.html | 18:30 |
| sashal | sforshee: could you guesstimate how many of these break in your average kernel upgrade? | 18:30 |
| sforshee | sashal: we probably see 10 or so dkms packages which need updated each time, zfs and nvidia pretty much always needs updates. Aside from those it's usually just a few | 18:32 |
| sforshee | most commonly glibc and systemd | 18:32 |
| sforshee | oh and trace things like lttng and sysdig, though that's ususally the dkms parts | 18:32 |
| sarnold | tyhicks: seccomp syscall rules? | 18:37 |
| tyhicks | sarnold: aha! that's right, we've had to bump/patch libseccomp to filter new syscalls | 18:38 |
| sforshee | sarnold: that's not currently one of the testing requirements for our kernels. Should it be? | 18:39 |
| sarnold | sforshee: jdstrand would be more familiar, but it probably should be -- seccomp is an important part of snapd story | 18:39 |
| sarnold | tyhicks: I believe a cronjob recently emailed us to let us know about new syscalls in a kernel :) hooray automation | 18:40 |
| sforshee | sarnold: perhaps it is already covered by qa-regression-tests or snapd testing | 18:40 |
| sforshee | I don't recall ever seeing any kind of test failures related to it though | 18:41 |
| tyhicks | sforshee: it is covered by both, I believe | 18:41 |
| sforshee | ok, good | 18:41 |
| sarnold | ah good | 18:42 |
| tyhicks | sforshee: it wouldn't have been a failure - it would have been a gap in being able to write a seccomp filter that specifies one of the new syscalls | 18:42 |
| sforshee | tyhicks: so if I'm testing e.g. 5.9 right now there wouldn't be anything in the test results that would prompt me to know that we needed a libseccomp update | 18:43 |
| tyhicks | sforshee: I don't think so but let me take a quick look at the autopkgtests because I know Jamie added a few in there but I don't remember if they detect new syscalls | 18:45 |
| sforshee | tyhicks: well libseccomp dep8 tests don't block our kernels, unless they are getting run as part of q-r-t | 18:46 |
| sforshee | we do have some sort of seccomp test in our autotests stuff, I'm not sure what it runs though | 18:47 |
| tyhicks | sforshee: ah, then they probably should block the kernels. the tests are quick and simple. | 18:47 |
| tyhicks | sforshee: I don't see anything in there that would fail on new syscalls | 18:48 |
| sforshee | tyhicks: our seccomp test clones the upstream libseccomp source and runs 'make check', essentially | 18:49 |
| sforshee | doesn't really tell us about the state of the ubuntu package | 18:49 |
| tyhicks | sforshee: I'm not sure if that would build a local (to the git repo) libseccomp and test with that or if it would use the system libseccomp - I'd think the former | 18:50 |
| tyhicks | (fwiw, the upstream libseccomp tests are pretty good0 | 18:50 |
| sforshee | or both :-) | 18:50 |
| sforshee | tyhicks: I mean it might be nice to test both, but yeah I don't know which ends up being tested either | 18:52 |
| Kon | Did something change with the mainline kernel PPA with the July 15 update? I have a utility to check for updates that stopped returning results after that time | 22:50 |
| Kon | Or rather, it still finds all kernels uploaded prior to July 15, but not after | 22:50 |
| Kon | I could just download the debs, but I am curious | 22:57 |
| Kon | Oh, the patches are no longer included in the repo comments | 23:04 |
| Kon | Nor the BUILD.LOG | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!