[13:28] LocutusOfBorg: reverted the patch, thanks for the heads up [13:54] thanks sforshee [13:57] sforshee, just to understand, in case it fails, will some automatic test notify me? [13:57] I double checked and virtualbox 6.2.14 in groovy release doesn't call the two functions anymore [13:57] but I don't want to break the world :D [13:58] (Debian never applied the patch and sid has 5.8.7 or whatever) [14:14] 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 [15:14] thanks! I'm pretty sure it will work [15:14] but better safe than sorry [18:20] 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:21] 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] there's the stuff in linux-tools-* that gets updated lockstep with the kernel (such as perf, usbip, etc.) [18:22] what I'm trying to remember are the additional packages spread thruoghout the archive [18:23] I came up with crash, kexec-tools, makedumpfile, ktap, and kpatch [18:23] are there any others that commonly need to be updated when bumping from 5.x to 5.y? [18:25] sforshee, cascardo, mhcerri: ^ you folks would have more recent memories of this work than I do [18:25] tyhicks: the big one the comes to mind is zfs [18:26] I had forgotten about that one [18:26] I'm primarily trying to inventory userspace code that needs to move forward with new kernel releases [18:27] it is mostly dkms stuff [18:27] sforshee: can you think of anything that broke that's outside of the DKMS module and kernel tool categories? [18:28] tyhicks: I was about to say iproute2, usually not because it broke but to support new things [18:28] otherwise I can't think of anything which we consistently need to update [18:28] sforshee: I was curious about that one, too. I'll go through the iproute2 changelog. [18:28] just things which show up with test failures from time to time [18:29] sforshee: yeah, those are the ones that I don't know how to identify very well [18:29] they are hard to identify, and very often if they break it's because the kernel regressed somehow [18:30] 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] sforshee: could you guesstimate how many of these break in your average kernel upgrade? [18:32] 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] most commonly glibc and systemd [18:32] oh and trace things like lttng and sysdig, though that's ususally the dkms parts [18:37] tyhicks: seccomp syscall rules? [18:38] sarnold: aha! that's right, we've had to bump/patch libseccomp to filter new syscalls [18:39] sarnold: that's not currently one of the testing requirements for our kernels. Should it be? [18:39] sforshee: jdstrand would be more familiar, but it probably should be -- seccomp is an important part of snapd story [18:40] tyhicks: I believe a cronjob recently emailed us to let us know about new syscalls in a kernel :) hooray automation [18:40] sarnold: perhaps it is already covered by qa-regression-tests or snapd testing [18:41] I don't recall ever seeing any kind of test failures related to it though [18:41] sforshee: it is covered by both, I believe [18:41] ok, good [18:42] ah good [18:42] 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:43] 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:45] 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:46] tyhicks: well libseccomp dep8 tests don't block our kernels, unless they are getting run as part of q-r-t [18:47] we do have some sort of seccomp test in our autotests stuff, I'm not sure what it runs though [18:47] sforshee: ah, then they probably should block the kernels. the tests are quick and simple. [18:48] sforshee: I don't see anything in there that would fail on new syscalls [18:49] tyhicks: our seccomp test clones the upstream libseccomp source and runs 'make check', essentially [18:49] doesn't really tell us about the state of the ubuntu package [18:50] 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] (fwiw, the upstream libseccomp tests are pretty good0 [18:50] or both :-) [18:52] tyhicks: I mean it might be nice to test both, but yeah I don't know which ends up being tested either [22:50] 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] Or rather, it still finds all kernels uploaded prior to July 15, but not after [22:57] I could just download the debs, but I am curious [23:04] Oh, the patches are no longer included in the repo comments [23:04] Nor the BUILD.LOG