sforsheeLocutusOfBorg: reverted the patch, thanks for the heads up13:28
LocutusOfBorgthanks sforshee 13:54
LocutusOfBorgsforshee, just to understand, in case it fails, will some automatic test notify me?13:57
LocutusOfBorgI double checked and virtualbox 6.2.14 in groovy release doesn't call the two functions anymore13:57
LocutusOfBorgbut I don't want to break the world :D13:57
LocutusOfBorg(Debian never applied the patch and sid has 5.8.7 or whatever)13:58
sforsheeLocutusOfBorg: 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 know14:14
LocutusOfBorgthanks! I'm pretty sure it will work15:14
LocutusOfBorgbut better safe than sorry15:14
tyhickshello! 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
tyhicksthe DKMS modules obviously are the majority of the work and, for my purposes, I'm just lumping them all into one bucket18:21
tyhicksthere's the stuff in linux-tools-* that gets updated lockstep with the kernel (such as perf, usbip, etc.)18:21
tyhickswhat I'm trying to remember are the additional packages spread thruoghout the archive18:22
tyhicksI came up with crash, kexec-tools, makedumpfile, ktap, and kpatch18:23
tyhicksare there any others that commonly need to be updated when bumping from 5.x to 5.y?18:23
tyhickssforshee, cascardo, mhcerri: ^ you folks would have more recent memories of this work than I do18:25
sforsheetyhicks: the big one the comes to mind is zfs18:25
tyhicksI had forgotten about that one18:26
tyhicksI'm primarily trying to inventory userspace code that needs to move forward with new kernel releases18:26
sforsheeit is mostly dkms stuff18:27
tyhickssforshee: can you think of anything that broke that's outside of the DKMS module and kernel tool categories?18:27
sforsheetyhicks: I was about to say iproute2, usually not because it broke but to support new things18:28
sforsheeotherwise I can't think of anything which we consistently need to update18:28
tyhickssforshee: I was curious about that one, too. I'll go through the iproute2 changelog.18:28
sforsheejust things which show up with test failures from time to time18:28
tyhickssforshee: yeah, those are the ones that I don't know how to identify very well18:29
sforsheethey are hard to identify, and very often if they break it's because the kernel regressed somehow18:29
sforsheeyou 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.html18:30
sashalsforshee: could you guesstimate how many of these break in your average kernel upgrade?18:30
sforsheesashal: 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 few18:32
sforsheemost commonly glibc and systemd18:32
sforsheeoh and trace things like lttng and sysdig, though that's ususally the dkms parts18:32
sarnoldtyhicks: seccomp syscall rules?18:37
tyhickssarnold: aha! that's right, we've had to bump/patch libseccomp to filter new syscalls18:38
sforsheesarnold: that's not currently one of the testing requirements for our kernels. Should it be?18:39
sarnoldsforshee: jdstrand would be more familiar, but it probably should be -- seccomp is an important part of snapd story18:39
sarnoldtyhicks: I believe a cronjob recently emailed us to let us know about new syscalls in a kernel :) hooray automation18:40
sforsheesarnold: perhaps it is already covered by qa-regression-tests or snapd testing18:40
sforsheeI don't recall ever seeing any kind of test failures related to it though18:41
tyhickssforshee: it is covered by both, I believe18:41
sforsheeok, good18:41
sarnoldah good18:42
tyhickssforshee: 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 syscalls18:42
sforsheetyhicks: 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 update18:43
tyhickssforshee: 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 syscalls18:45
sforsheetyhicks: well libseccomp dep8 tests don't block our kernels, unless they are getting run as part of q-r-t18:46
sforsheewe do have some sort of seccomp test in our autotests stuff, I'm not sure what it runs though18:47
tyhickssforshee: ah, then they probably should block the kernels. the tests are quick and simple.18:47
tyhickssforshee: I don't see anything in there that would fail on new syscalls18:48
sforsheetyhicks: our seccomp test clones the upstream libseccomp source and runs 'make check', essentially18:49
sforsheedoesn't really tell us about the state of the ubuntu package18:49
tyhickssforshee: 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 former18:50
tyhicks(fwiw, the upstream libseccomp tests are pretty good018:50
sforsheeor both :-)18:50
sforsheetyhicks: I mean it might be nice to test both, but yeah I don't know which ends up being tested either18:52
KonDid 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 time22:50
KonOr rather, it still finds all kernels uploaded prior to July 15, but not after22:50
KonI could just download the debs, but I am curious22:57
KonOh, the patches are no longer included in the repo comments23:04
KonNor the BUILD.LOG23:04

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!