01.03.2017 10:31, Christian Ehrhardt wrote: > > b 7a257a6a46 Enable seccomp for ppc64el > > This one isn't for stretch, delaying for now. > Why only ppc64el, why not other ppc variants? > > > Because ppc64el was the only one I could test/verify on. > If you can check more we can enable more, but I had no way to do so.
I think we can enable seccomp for all architectures where libseccomp is available, and see what'll break. Once stretch will come out. Personally I see absolutely no reason in seccomp anymore, since it covers pretty much every syscall nowadays, and its usefulness is pretty much near zero. > On the acl change, while I agree the right fix is the bug you filed it is > kind of unclear when this will happen. > If not a maintenance burden for you I'd ask you to accept the minimal change > which modifies the dependencies behind an :ubunu: label only for now > (84dc4d05d3). Yeah, I'll do that for sure. > Checking if my timing/approach works for you: > - I thought I saw you preparing a new upload (many bugs merged / assigned, > CVEs lining up in debian-unstable branch) > - I expect (please correct me) that to be a 1:2.8+dfsg-3 upload Yes, and yes. > - If the changes discussed here would be applied there that would be great > and I wanted to remerge > - not sure since they are no criticals for you, you might push the changes > discussed here only for the next release > - but even if the changes we discussed here are not in there I'd plan me to > merge that for the CVEs I already merged a few, I mentioned that in my previous email too :) > - After some testing I'd get back to you with any additional Delta/Fixes I > identified to be needed for 2.8. > - preview: there is already one in my queue which is based on > http://patchwork.ozlabs.org/patch/721974/ (I can't wait that to hit next > stable) Picked up from upstream and applied to debian-unstable. Do you happen to have a bug# reference for this? Do you have other bugs which are worth fixing too? Thanks, /mjt