Spread test failing due to new syscalls

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


+ 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

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. :slight_smile:

The purpose of the test is to catch when the list here https://github.com/snapcore/snapd/blob/f47a84771ff3184d5441c1665fb3e9f20e165c64/cmd/snap-seccomp/syscalls/syscalls.go needs to be updated to account for new syscalls.

I’ll prepare a PR with an update.

The PR is up https://github.com/snapcore/snapd/pull/7034

Edit: the PR has landed now.