07:25 < jdstrand> mvo: I'm not familiar with the 'tsync bit' error. It seems to be 
                  a libseccomp-golang thing though: 
https://github.com/seccomp/libseccomp-golang/blob/master/seccomp.go#L497
07:27 -!- caiortp [~inatel@131.221.240.233] has joined #snappy
07:27 < jdstrand> mvo: strike that. I see libseccomp-golang give that error string, 
                  but libseccomp does reference tsync
07:28 < jdstrand> mvo: I did see this: 
                  https://github.com/seccomp/libseccomp/issues/20
07:29 < jdstrand> mvo: which may me wonder if libseccomp on trusty is built with a 
                  3.13 kernel (as opposed to lts kernel), perhaps it isn't being 
                  built with tsync support
07:29 < jdstrand> mvo: (guess)
07:30 < jdstrand> mvo: I then saw 
https://github.com/seccomp/libseccomp/commit/a1f144a9a28aa1b831f7d3f481fb3e0e5e3de3aa
07:30 < jdstrand> "The seccomp() syscall was first added in Linux 3.17 so most 
                  systems
07:30 < jdstrand> should now support this syscall.  Most importantly, the use of the
07:30 < jdstrand> seccomp() syscall enabled the thread sync functionality which 
                  isn't
07:30 < jdstrand> possible with prctl(); although callers still need to enable the 
                  flag
07:30 < jdstrand> per-filter as the thread sync default is disabled."
07:31 < jdstrand> mvo: with snap-seccomp, we moved to prctl
07:32 < jdstrand> mvo: maybe if we appropriately used the seccomp syscall, this 
                  would resolve itself?