[13:28] <sforshee> LocutusOfBorg: reverted the patch, thanks for the heads up
[13:54] <LocutusOfBorg> thanks sforshee 
[13:57] <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:58] <LocutusOfBorg> (Debian never applied the patch and sid has 5.8.7 or whatever)
[14:14] <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
[15:14] <LocutusOfBorg> thanks! I'm pretty sure it will work
[15:14] <LocutusOfBorg> but better safe than sorry
[18:20] <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:21] <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:22] <tyhicks> what I'm trying to remember are the additional packages spread thruoghout the archive
[18:23] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:32] <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:37] <sarnold> tyhicks: seccomp syscall rules?
[18:38] <tyhicks> sarnold: aha! that's right, we've had to bump/patch libseccomp to filter new syscalls
[18:39] <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:40] <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:41] <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:42] <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:43] <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:45] <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:46] <sforshee> tyhicks: well libseccomp dep8 tests don't block our kernels, unless they are getting run as part of q-r-t
[18:47] <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:48] <tyhicks> sforshee: I don't see anything in there that would fail on new syscalls
[18:49] <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:50] <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:52] <sforshee> tyhicks: I mean it might be nice to test both, but yeah I don't know which ends up being tested either
[22:50] <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:57] <Kon> I could just download the debs, but I am curious
[23:04] <Kon> Oh, the patches are no longer included in the repo comments
[23:04] <Kon> Nor the BUILD.LOG