Four days ago, libseccomp master gained some new syscalls: https://github.com/seccomp/libseccomp/commit/5fc22428507ecea00ee9e2215d972777da9a99b6
This breaks spread due to: https://github.com/snapcore/snapd/blob/master/tests/main/snap-seccomp-syscalls/task.yaml#L30
Ie:
+ go run listcalls.go
+ diff -up syscalls.uniq syscalls.known
--- syscalls.uniq 2019-06-25 18:29:08.508014717 +0000
+++ syscalls.known 2019-06-25 18:29:08.768037666 +0000
@@ -141,9 +141,6 @@ io_getevents
io_pgetevents
io_setup
io_submit
-io_uring_enter
-io_uring_register
-io_uring_setup
ioctl
ioperm
iopl
The spread test says “both lists should be identical, otherwise we need an update”, but it isn’t clear what needs updating (the test, snapd, libseccomp, …). Put another way, the spread test is pulling down libseccomp master and looking for new syscalls and in this case seeing that some new ones were added in 5.1-- is the test meant to say that libseccomp in the Ubuntu archive needs to be updated for these new syscalls (since snapd is built against the Ubuntu archive)? If so, who is performing that update in Ubuntu? It would take at least a week to go through the SRU process so I wonder if it is acceptable to have PRs breaking during this period. Also, how is that supposed to work with cross-distro on distros with no re-exec support or Ubuntu releases where the deb is the same version as core/core18/snapd (ie, when it doesn’t re-exec and uses the deb instead)? Perhaps I am misinterpreting the comment?
@mborzecki - git blame tells me you added the test; can you comment on what update you had in mind? I was prepared to create a PR for it, but then didn’t know what you wanted. 