Libseccomp: 问：v2.4.2 的补丁从 master 到 release-2.4

候选人：

• 0d73daf07490656130e0f5311ad12ca8818752c5
• 3f214cbbbbd663dd4e7fe90638af4971b436ec00
• d390edad9a8540c2e2dd0b12732cc8dd3fe1cc69
• 5fc22428507ecea00ee9e2215d972777da9a99b6
• 4bec773fb401433bbfbbef111a49e1d2acbc4fcf
• ff7fc73bdf4602323ce320a2094c006c9c3e4d42
• 2b406e3b274407ceef53fa3de9469cfbd0fd0ddb

0d73daf - 同意
3f214cb - 同意
d390eda - 同意
5fc2242 - 同意
4bec773 - 同意
ff7fc73 - 同意
2b406e3 - 同意

我不记得这次提交的细节 - 3570b5cf9acbd1711d417e08ec608eea7b83d416。 我们需要向后移植它吗？

我不记得这次提交的细节 - 3570b5c。 我们需要向后移植它吗？

release-2.4 分支包含 SECCOMP_FILTER_FLAG_LOG/log_enable 属性，因此我们需要确保正确重置它。 SPEC_ALLOW/spec_allow 属性不在 release-2.4 分支中，因此需要删除它，但这非常简单。

作为对您的新写访问@drakenclimber的测试，您是否要向后移植这些补丁并为 release-2.4 分支组合一个 PR； 我会给你 ACK（假设一切看起来都不错），你可以提交吗？

顺便说一句，向后移植很简单，只需从主分支中挑选补丁（如果您使用的是 stgit，它是stg pick命令）并记下任何必要的编辑。 如果您有任何问题，或遇到任何问题，请告诉我。

当然。 我可以试一试。

这是包含所有向后移植提交的分支。 我在上次提交中提到了“问题 #161”，这样它就会自动连接到这个线程。

https://github.com/drakenclimber/libseccomp/tree/issues/161

谢谢。 是否有理由不为此创建 PR？

现在我们有两个人，我认为坚持_稍微_更正式的过程对于保持我们（和树的）理智很重要:)

谢谢。 是否有理由不为此创建 PR？

好决定。 我会做一个公关。 这是相当漫长的一天:(

抱歉，我之前在您对 3570b5cf9acbd1711d417e08ec608eea7b83d416 的评论中间隔了一段时间 - 很好地抓住了那个，我错误地认为它来自我放在一起的列表：/

合并到 release-2.4 分支。

https://github.com/seccomp/libseccomp/commit/0f11bb83d92ae74669f4a5e9c240b1e353d5a596