linux-next: manual merge of the apparmor tree with the security tree

Paul Moore paul at paul-moore.com
Sun Nov 5 23:36:49 UTC 2023


On Sun, Nov 5, 2023 at 6:14 PM Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>
> Hi Paul,
>
> [Sorry for the slow reply]
>
> On Mon, 30 Oct 2023 17:04:01 -0400 Paul Moore <paul at paul-moore.com> wrote:
> >
> > On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> > >
> > > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul at paul-moore.com> wrote:
> > > >
> > > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen at canonical.com> wrote:
> > > > >
> > > > > is part of the Three basic syscalls series, the plan is still to have that
> > > > > series bake in next for a full cycle?
> > > >
> > > > Yes, that's still the plan.  Once v6.7-rc1 is out I'll rebase the LSM
> > > > syscall patches and I expect the vast majority of these conflicts to
> > > > disappear, although I'm sure we'll pick up some new ones with the rest
> > > > of the v6.7-rcX cycle :)
> > >
> > > These patches should not be in linux-next until after v6.7-rc1.
> >
> > What if we wanted additional testing beyond the typical?  Do you not
> > support that?
>
> No, I try hard not to.  It just complicates things when I and others
> have to cope with conflicts and build problems caused by
> patches/features destined for next+1 while trying to stabilise the
> current/next release.

The LSM, SELinux, and audit dev-staging branches will no longer flow
into the next branches, and I've reset the current lsm/next branch so
this should not be an issue the next time you pull.

> Sometimes it happens that a feature slips after being added to -next,
> but please don't do it deliberately.

-- 
paul-moore.com



More information about the Linux-security-module-archive mailing list