Re: linux-next: the selinux tree needs cleaning up
On 06/26/2014 08:12 AM, Stephen Rothwell wrote:
Hi James,
On Wed, 25 Jun 2014 20:51:43 +1000 James Morris
wrote:
I haven't pulled in Paul's tree, I merged with the latest Linus release.
Ummm, yesterday your security tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
moved from commit 2fd4e6698f08 ("Merge branch 'smack-for-3.16' of
git://git.gitorious.org/smack-next/kernel into next") (which is
included in v3.16-rc1) to commit f01387d26938 ("Merge commit 'v3.15'
into next"). The commit between those 2 commits is 92953ff38ba5
("Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux
into next").
Ok, I thought you meant pulled in more recently.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On 06/26/2014 08:12 AM, Stephen Rothwell wrote: Hi James, On Wed, 25 Jun 2014 20:51:43 +1000 James Morris james.l.mor...@oracle.com wrote: I haven't pulled in Paul's tree, I merged with the latest Linus release. Ummm, yesterday your security tree (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next) moved from commit 2fd4e6698f08 (Merge branch 'smack-for-3.16' of git://git.gitorious.org/smack-next/kernel into next) (which is included in v3.16-rc1) to commit f01387d26938 (Merge commit 'v3.15' into next). The commit between those 2 commits is 92953ff38ba5 (Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux into next). Ok, I thought you meant pulled in more recently. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi James,
On Wed, 25 Jun 2014 20:51:43 +1000 James Morris
wrote:
>
> I haven't pulled in Paul's tree, I merged with the latest Linus release.
Ummm, yesterday your security tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next)
moved from commit 2fd4e6698f08 ("Merge branch 'smack-for-3.16' of
git://git.gitorious.org/smack-next/kernel into next") (which is
included in v3.16-rc1) to commit f01387d26938 ("Merge commit 'v3.15'
into next"). The commit between those 2 commits is 92953ff38ba5
("Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux
into next").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
On Wednesday, June 25, 2014 09:59:28 AM Stephen Rothwell wrote: > Well, I see that James has pulled your tree, so past problems are now > moot. He has some duplicate commits in his tree now and Linus will get > a few more when he next pulls James' tree. We just need to avoid this > going forward. And given that James or Serge will, from now on, *pull* > your tree (not cherry-pick from it), things should be fine. Okay, sorry again for the confusion, hopefully we won't have to worry about this again. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On 06/25/2014 09:59 AM, Stephen Rothwell wrote:
Hi Paul,
On Tue, 24 Jun 2014 14:03:08 -0400 Paul Moore wrote:
On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
{big snip}
Stephen, assuming for a moment that I created a fresh branch, based against
3.15, and then added the SELinux patches for 3.16 (basically the few new
patches that were in the ole #next branch) would that serve as a reasonable
basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
send a pull request to James to pull from this next branch into the Linux
Security branch for 3.17. Once 3.16 is released, I would merge that into
this new #next branch and continue with the next round of patches.
FYI, more or less, the above is the process we've settled upon for all of
the trees that get accumulated into the Linux Security tree.
Does the above work for you in linux-next? I'd like to try and resolve this
sooner rather than later and I imagine you feel the same ...
Well, I see that James has pulled your tree, so past problems are now
moot. He has some duplicate commits in his tree now and Linus will get
a few more when he next pulls James' tree. We just need to avoid this
going forward. And given that James or Serge will, from now on, *pull*
your tree (not cherry-pick from it), things should be fine.
I haven't pulled in Paul's tree, I merged with the latest Linus release.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On 06/25/2014 09:59 AM, Stephen Rothwell wrote:
Hi Paul,
On Tue, 24 Jun 2014 14:03:08 -0400 Paul Moore p...@paul-moore.com wrote:
On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
{big snip}
Stephen, assuming for a moment that I created a fresh branch, based against
3.15, and then added the SELinux patches for 3.16 (basically the few new
patches that were in the ole #next branch) would that serve as a reasonable
basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
send a pull request to James to pull from this next branch into the Linux
Security branch for 3.17. Once 3.16 is released, I would merge that into
this new #next branch and continue with the next round of patches.
FYI, more or less, the above is the process we've settled upon for all of
the trees that get accumulated into the Linux Security tree.
Does the above work for you in linux-next? I'd like to try and resolve this
sooner rather than later and I imagine you feel the same ...
Well, I see that James has pulled your tree, so past problems are now
moot. He has some duplicate commits in his tree now and Linus will get
a few more when he next pulls James' tree. We just need to avoid this
going forward. And given that James or Serge will, from now on, *pull*
your tree (not cherry-pick from it), things should be fine.
I haven't pulled in Paul's tree, I merged with the latest Linus release.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On Wednesday, June 25, 2014 09:59:28 AM Stephen Rothwell wrote: Well, I see that James has pulled your tree, so past problems are now moot. He has some duplicate commits in his tree now and Linus will get a few more when he next pulls James' tree. We just need to avoid this going forward. And given that James or Serge will, from now on, *pull* your tree (not cherry-pick from it), things should be fine. Okay, sorry again for the confusion, hopefully we won't have to worry about this again. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi James, On Wed, 25 Jun 2014 20:51:43 +1000 James Morris james.l.mor...@oracle.com wrote: I haven't pulled in Paul's tree, I merged with the latest Linus release. Ummm, yesterday your security tree (git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git#next) moved from commit 2fd4e6698f08 (Merge branch 'smack-for-3.16' of git://git.gitorious.org/smack-next/kernel into next) (which is included in v3.16-rc1) to commit f01387d26938 (Merge commit 'v3.15' into next). The commit between those 2 commits is 92953ff38ba5 (Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux into next). -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
Hi Paul,
On Tue, 24 Jun 2014 14:03:08 -0400 Paul Moore wrote:
>
> On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
>
> {big snip}
>
> > Stephen, assuming for a moment that I created a fresh branch, based against
> > 3.15, and then added the SELinux patches for 3.16 (basically the few new
> > patches that were in the ole #next branch) would that serve as a reasonable
> > basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
> > send a pull request to James to pull from this next branch into the Linux
> > Security branch for 3.17. Once 3.16 is released, I would merge that into
> > this new #next branch and continue with the next round of patches.
> >
> > FYI, more or less, the above is the process we've settled upon for all of
> > the trees that get accumulated into the Linux Security tree.
>
> Does the above work for you in linux-next? I'd like to try and resolve this
> sooner rather than later and I imagine you feel the same ...
Well, I see that James has pulled your tree, so past problems are now
moot. He has some duplicate commits in his tree now and Linus will get
a few more when he next pulls James' tree. We just need to avoid this
going forward. And given that James or Serge will, from now on, *pull*
your tree (not cherry-pick from it), things should be fine.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
{big snip}
> Stephen, assuming for a moment that I created a fresh branch, based against
> 3.15, and then added the SELinux patches for 3.16 (basically the few new
> patches that were in the ole #next branch) would that serve as a reasonable
> basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
> send a pull request to James to pull from this next branch into the Linux
> Security branch for 3.17. Once 3.16 is released, I would merge that into
> this new #next branch and continue with the next round of patches.
>
> FYI, more or less, the above is the process we've settled upon for all of
> the trees that get accumulated into the Linux Security tree.
Hi Stephen,
Does the above work for you in linux-next? I'd like to try and resolve this
sooner rather than later and I imagine you feel the same ...
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
{big snip}
Stephen, assuming for a moment that I created a fresh branch, based against
3.15, and then added the SELinux patches for 3.16 (basically the few new
patches that were in the ole #next branch) would that serve as a reasonable
basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
send a pull request to James to pull from this next branch into the Linux
Security branch for 3.17. Once 3.16 is released, I would merge that into
this new #next branch and continue with the next round of patches.
FYI, more or less, the above is the process we've settled upon for all of
the trees that get accumulated into the Linux Security tree.
Hi Stephen,
Does the above work for you in linux-next? I'd like to try and resolve this
sooner rather than later and I imagine you feel the same ...
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi Paul,
On Tue, 24 Jun 2014 14:03:08 -0400 Paul Moore p...@paul-moore.com wrote:
On Friday, June 20, 2014 12:06:28 PM Paul Moore wrote:
{big snip}
Stephen, assuming for a moment that I created a fresh branch, based against
3.15, and then added the SELinux patches for 3.16 (basically the few new
patches that were in the ole #next branch) would that serve as a reasonable
basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would
send a pull request to James to pull from this next branch into the Linux
Security branch for 3.17. Once 3.16 is released, I would merge that into
this new #next branch and continue with the next round of patches.
FYI, more or less, the above is the process we've settled upon for all of
the trees that get accumulated into the Linux Security tree.
Does the above work for you in linux-next? I'd like to try and resolve this
sooner rather than later and I imagine you feel the same ...
Well, I see that James has pulled your tree, so past problems are now
moot. He has some duplicate commits in his tree now and Linus will get
a few more when he next pulls James' tree. We just need to avoid this
going forward. And given that James or Serge will, from now on, *pull*
your tree (not cherry-pick from it), things should be fine.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
On Friday, June 20, 2014 08:59:31 AM Stephen Rothwell wrote: > Hi Paul, Hello again. > On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore wrote: > > I want to avoid use a -rcX release as the foundation of any of my trees; > > the -rc releases aren't as stable and it goes against what we're trying > > to do with the different Linux Security trees. Unfortunately, based on > > what I've read above, this seems to be incompatible with linux-next. > > The problem with basing your development for v3.17 on v3.15 is that > you do not take into account any of the changes done by others during > v3.16-rc1 (or even your upstream tree) some of which may be core API > changes. The way I currently do things - merge the latest major release on top of the existing #next and then start applying the new #next patches - does leave the SELinux tree a bit behind when it comes to other subsystems, but it does at least include all of the SELinux relevant patches. I'll admit it isn't perfect, but it seems to work reasonably well for SELinux development, and it was the process used by the previous SELinux maintainer. > > While I hate to split my development branch from the #next branch, it > > seems > > I don't want that either ... > > > like that is the only way to accomplish both a reasonably current and > > stable development tree and get the patches into linux-next. Unless you, > > or anyone else for that matter, has a different suggestion I'm going to > > go ahead and turn the current SELinux #next branch into a development > > branch and create a new #next branch that will be based on the most > > current -rc1, this new #next branch will be created new for each major > > release. Not exactly what I was hoping for, but will that work? > > Do you mean that your #next branch will just be a merge of -rc1 and > your development branch? That would not actually change anything > (except that you would possibly take care of some conflicts for me). Sort of, I would basically create a new #next branch for linux-next which would be created fresh from the latest -rc1 and I would cherry-pick the patches for linux-next from my development branch. It would be a bit of a mess to be honest, but I'm trying to reconcile the SELinux development needs/wants with the linux-next needs/wants. > At the core, what is in linux-next should just be exactly what will be > merged by your upstream. That has been, and remains the goal for me as well. However, there have been a number of problems with this in the past, even excluding the latest merge window; I believe these past problems are what you are seeing now. I am hopeful that these issues are behind us now, at least for the most part. > My real point here is that that is not what has happened recently. The > patches in your tree have been cherry-picked or rebased into James' or > Serge's trees, not merged so we now have duplication. This is what you need > to solve with James and Serge. linux-next is a side issue - I can cope with > a lot. See above. This issue has been solved with James a few months ago, this merge window was actually on track to go off without a problem, and it sorta did, but there were some out-of-band issues which caused some confusion in the linux-security world. Let's try to move on a bit, discussing why the SELinux #next branch has some cruft in it doesn't help us resolve things since we all acknowledge there were problems for a while that should now be resolved ... Stephen, assuming for a moment that I created a fresh branch, based against 3.15, and then added the SELinux patches for 3.16 (basically the few new patches that were in the ole #next branch) would that serve as a reasonable basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would send a pull request to James to pull from this next branch into the Linux Security branch for 3.17. Once 3.16 is released, I would merge that into this new #next branch and continue with the next round of patches. FYI, more or less, the above is the process we've settled upon for all of the trees that get accumulated into the Linux Security tree. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Quoting Stephen Rothwell (s...@canb.auug.org.au): > Hi Serge, > > On Fri, 20 Jun 2014 05:43:56 +0200 "Serge E. Hallyn" wrote: > > > > The duplicates were the result of several misunderstandings and general > > naivity all on my part. I'm actually still not clear on what usually > > happens with the selinux tree - it feeds into linux-next, then gets > > 'pull'ed by James into security-next for a pull request? Do you usually > > send a request to James when ready, he pulls, then he sends pull request > > to Linus? (Or am I wrong, and you usually send your own requests to > > Linus?) > > If "you" is Paul, then I am pretty sure he asks James to pull and then > James in turn asks Linus to pull. > > If "you" is me, then no :-) Thanks :) -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Quoting Stephen Rothwell (s...@canb.auug.org.au): Hi Serge, On Fri, 20 Jun 2014 05:43:56 +0200 Serge E. Hallyn se...@hallyn.com wrote: The duplicates were the result of several misunderstandings and general naivity all on my part. I'm actually still not clear on what usually happens with the selinux tree - it feeds into linux-next, then gets 'pull'ed by James into security-next for a pull request? Do you usually send a request to James when ready, he pulls, then he sends pull request to Linus? (Or am I wrong, and you usually send your own requests to Linus?) If you is Paul, then I am pretty sure he asks James to pull and then James in turn asks Linus to pull. If you is me, then no :-) Thanks :) -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On Friday, June 20, 2014 08:59:31 AM Stephen Rothwell wrote: Hi Paul, Hello again. On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore p...@paul-moore.com wrote: I want to avoid use a -rcX release as the foundation of any of my trees; the -rc releases aren't as stable and it goes against what we're trying to do with the different Linux Security trees. Unfortunately, based on what I've read above, this seems to be incompatible with linux-next. The problem with basing your development for v3.17 on v3.15 is that you do not take into account any of the changes done by others during v3.16-rc1 (or even your upstream tree) some of which may be core API changes. The way I currently do things - merge the latest major release on top of the existing #next and then start applying the new #next patches - does leave the SELinux tree a bit behind when it comes to other subsystems, but it does at least include all of the SELinux relevant patches. I'll admit it isn't perfect, but it seems to work reasonably well for SELinux development, and it was the process used by the previous SELinux maintainer. While I hate to split my development branch from the #next branch, it seems I don't want that either ... like that is the only way to accomplish both a reasonably current and stable development tree and get the patches into linux-next. Unless you, or anyone else for that matter, has a different suggestion I'm going to go ahead and turn the current SELinux #next branch into a development branch and create a new #next branch that will be based on the most current -rc1, this new #next branch will be created new for each major release. Not exactly what I was hoping for, but will that work? Do you mean that your #next branch will just be a merge of -rc1 and your development branch? That would not actually change anything (except that you would possibly take care of some conflicts for me). Sort of, I would basically create a new #next branch for linux-next which would be created fresh from the latest -rc1 and I would cherry-pick the patches for linux-next from my development branch. It would be a bit of a mess to be honest, but I'm trying to reconcile the SELinux development needs/wants with the linux-next needs/wants. At the core, what is in linux-next should just be exactly what will be merged by your upstream. That has been, and remains the goal for me as well. However, there have been a number of problems with this in the past, even excluding the latest merge window; I believe these past problems are what you are seeing now. I am hopeful that these issues are behind us now, at least for the most part. My real point here is that that is not what has happened recently. The patches in your tree have been cherry-picked or rebased into James' or Serge's trees, not merged so we now have duplication. This is what you need to solve with James and Serge. linux-next is a side issue - I can cope with a lot. See above. This issue has been solved with James a few months ago, this merge window was actually on track to go off without a problem, and it sorta did, but there were some out-of-band issues which caused some confusion in the linux-security world. Let's try to move on a bit, discussing why the SELinux #next branch has some cruft in it doesn't help us resolve things since we all acknowledge there were problems for a while that should now be resolved ... Stephen, assuming for a moment that I created a fresh branch, based against 3.15, and then added the SELinux patches for 3.16 (basically the few new patches that were in the ole #next branch) would that serve as a reasonable basis for a new SELinux #next branch? Around the -rc5/6/7 timeframe I would send a pull request to James to pull from this next branch into the Linux Security branch for 3.17. Once 3.16 is released, I would merge that into this new #next branch and continue with the next round of patches. FYI, more or less, the above is the process we've settled upon for all of the trees that get accumulated into the Linux Security tree. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi Serge, On Fri, 20 Jun 2014 05:43:56 +0200 "Serge E. Hallyn" wrote: > > The duplicates were the result of several misunderstandings and general > naivity all on my part. I'm actually still not clear on what usually > happens with the selinux tree - it feeds into linux-next, then gets > 'pull'ed by James into security-next for a pull request? Do you usually > send a request to James when ready, he pulls, then he sends pull request > to Linus? (Or am I wrong, and you usually send your own requests to > Linus?) If "you" is Paul, then I am pretty sure he asks James to pull and then James in turn asks Linus to pull. If "you" is me, then no :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
Quoting Stephen Rothwell (s...@canb.auug.org.au): > Hi Paul, > > On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore wrote: > > > > I want to avoid use a -rcX release as the foundation of any of my trees; > > the - > > rc releases aren't as stable and it goes against what we're trying to do > > with > > the different Linux Security trees. Unfortunately, based on what I've read > > above, this seems to be incompatible with linux-next. > > The problem with basing your development for v3.17 on v3.15 is that > you do not take into account any of the changes done by others during > v3.16-rc1 (or even your upstream tree) some of which may be core API > changes. > > > While I hate to split my development branch from the #next branch, it seems > > I don't want that either ... > > > like that is the only way to accomplish both a reasonably current and > > stable > > development tree and get the patches into linux-next. Unless you, or > > anyone > > else for that matter, has a different suggestion I'm going to go ahead and > > turn the current SELinux #next branch into a development branch and create > > a > > new #next branch that will be based on the most current -rc1, this new > > #next > > branch will be created new for each major release. Not exactly what I was > > hoping for, but will that work? > > Do you mean that your #next branch will just be a merge of -rc1 and > your development branch? That would not actually change anything > (except that you would possibly take care of some conflicts for me). > > At the core, what is in linux-next should just be exactly what will be > merged by your upstream. My real point here is that that is not what > has happened recently. The patches in your tree have been > cherry-picked or rebased into James' or Serge's trees, not merged so we > now have duplication. This is what you need to solve with James and > Serge. linux-next is a side issue - I can cope with a lot. The duplicates were the result of several misunderstandings and general naivity all on my part. I'm actually still not clear on what usually happens with the selinux tree - it feeds into linux-next, then gets 'pull'ed by James into security-next for a pull request? Do you usually send a request to James when ready, he pulls, then he sends pull request to Linus? (Or am I wrong, and you usually send your own requests to Linus?) -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi Paul, On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore wrote: > > I want to avoid use a -rcX release as the foundation of any of my trees; the - > rc releases aren't as stable and it goes against what we're trying to do with > the different Linux Security trees. Unfortunately, based on what I've read > above, this seems to be incompatible with linux-next. The problem with basing your development for v3.17 on v3.15 is that you do not take into account any of the changes done by others during v3.16-rc1 (or even your upstream tree) some of which may be core API changes. > While I hate to split my development branch from the #next branch, it seems I don't want that either ... > like that is the only way to accomplish both a reasonably current and stable > development tree and get the patches into linux-next. Unless you, or anyone > else for that matter, has a different suggestion I'm going to go ahead and > turn the current SELinux #next branch into a development branch and create a > new #next branch that will be based on the most current -rc1, this new #next > branch will be created new for each major release. Not exactly what I was > hoping for, but will that work? Do you mean that your #next branch will just be a merge of -rc1 and your development branch? That would not actually change anything (except that you would possibly take care of some conflicts for me). At the core, what is in linux-next should just be exactly what will be merged by your upstream. My real point here is that that is not what has happened recently. The patches in your tree have been cherry-picked or rebased into James' or Serge's trees, not merged so we now have duplication. This is what you need to solve with James and Serge. linux-next is a side issue - I can cope with a lot. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
On Friday, June 20, 2014 01:08:37 AM Stephen Rothwell wrote: > Hi Paul, Howdy. > On Wed, 18 Jun 2014 14:26:27 -0400 Paul Moore wrote: > > On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote: I'm going to chop up your email a bit so it makes more sense when replying, my apologies if I make things worse. > As for your current tree, it contains the following commits: > > (1) 5c7001b84be5 SELinux: use ARRAY_SIZE > (2) aa65506f198c selinux, kbuild: remove unnecessary $(hostprogs-y) from > clean-files 170b5910d9fb Merge tag 'v3.15' into next > (3) 47dd0b76ace9 selinux: conditionally reschedule in hashtab_insert while > loading selinux policy (4) 612c353178c4 selinux: conditionally reschedule > in mls_convert_context while loading selinux policy (5) 4f189988a0a5 > selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES (6) > 626b9740fa73 selinux: Report permissive mode in avc: denied messages. > 6d32c850621b Merge tag 'v3.14' into next > (7) eee3094683fb selinux: correctly label /proc inodes in use before the > policy is loaded (8) 0909c0ae999c selinux: put the mmap() DAC controls > before the MAC controls (9) 81c94e76ce8e selinux: fix the output of > ./scripts/get_maintainer.pl for SELinux 41be702a542a Merge tag 'v3.13' into > next > > 1 and 2 are new Yes, these are the "new" SELinux patches that should be in linux-next. > 3 is in Linus' tree as commit ed1c96429a6a > 4 9a591f39a9d1 > 5 5b589d44fad1 > 6 ca7786a2f916 > 7 f64410ec6654 > 8 and 9 are subsumed by something in Linus' tree. These are likely caused by the problems we talked about earlier. > > So, back to your concerns - what do you want to see in linux-next? My > > practice for the SELinux #next branch has been to apply patches on top of > > the latest "major" release from Linus, e.g. 3.15, and when a new major > > release is made I merge it into #next and restart the process. I > > generally send James' a pull request in the -rc6/7 timeframe using the > > #next branch. While this has resulted in some ugliness (see above > > comments) it keeps the SELinux #next branch steady so others can pull > > from it without major problems. > > > > Does this approach not work for you and linux-next? > > OK, you should probably base your tree on -rc1 or 2, that way all your > stuff for the previous merge window is upstream and you don't need to > worry about it any more. ... > So, the easiest way for you to clean up from this is to now rebase onto > v3.16-rc1 (which will leave you with just commits 1 and 2) and then > ensure that in the future James (or whoever is handling the security > tree) pulls your tree (and doesn't cherry-pick the patches). Then > after that has happened, you can fast forward your tree onto that > upstream tree, or wait until the next -rc1 and fast forward to that. I want to avoid use a -rcX release as the foundation of any of my trees; the - rc releases aren't as stable and it goes against what we're trying to do with the different Linux Security trees. Unfortunately, based on what I've read above, this seems to be incompatible with linux-next. While I hate to split my development branch from the #next branch, it seems like that is the only way to accomplish both a reasonably current and stable development tree and get the patches into linux-next. Unless you, or anyone else for that matter, has a different suggestion I'm going to go ahead and turn the current SELinux #next branch into a development branch and create a new #next branch that will be based on the most current -rc1, this new #next branch will be created new for each major release. Not exactly what I was hoping for, but will that work? -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi Paul, On Wed, 18 Jun 2014 14:26:27 -0400 Paul Moore wrote: > > On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote: > > > > The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next) > > contains some commits going back to January and also has merges of > > v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1, > > you find that it has onlt 2 unique commits (the most recent 2) which > > means that the others were merged upstream after being rewritten. :-( > > Without going through each of the differences between the SELinux tree and > what is in Linus' tree in this email, I can assure you there is nothing > nefarious going on here, just some differences in tree management between > James' Linux Security tree and the SELinux tree which resulted in some > backports and other mess. The good news is that James' and the rest of us > under the Linux Security tree have now established a protocol moving forward > which should avoid these nasties. Sounds good. I usually assume that these issues are misunderstandings or oversights. > So, back to your concerns - what do you want to see in linux-next? My > practice for the SELinux #next branch has been to apply patches on top of the > latest "major" release from Linus, e.g. 3.15, and when a new major release is > made I merge it into #next and restart the process. I generally send James' > a > pull request in the -rc6/7 timeframe using the #next branch. While this has > resulted in some ugliness (see above comments) it keeps the SELinux #next > branch steady so others can pull from it without major problems. > > Does this approach not work for you and linux-next? OK, you should probably base your tree on -rc1 or 2, that way all your stuff for the previous merge window is upstream and you don't need to worry about it any more. As for your current tree, it contains the following commits: (1) 5c7001b84be5 SELinux: use ARRAY_SIZE (2) aa65506f198c selinux, kbuild: remove unnecessary $(hostprogs-y) from clean-files 170b5910d9fb Merge tag 'v3.15' into next (3) 47dd0b76ace9 selinux: conditionally reschedule in hashtab_insert while loading selinux policy (4) 612c353178c4 selinux: conditionally reschedule in mls_convert_context while loading selinux policy (5) 4f189988a0a5 selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES (6) 626b9740fa73 selinux: Report permissive mode in avc: denied messages. 6d32c850621b Merge tag 'v3.14' into next (7) eee3094683fb selinux: correctly label /proc inodes in use before the policy is loaded (8) 0909c0ae999c selinux: put the mmap() DAC controls before the MAC controls (9) 81c94e76ce8e selinux: fix the output of ./scripts/get_maintainer.pl for SELinux 41be702a542a Merge tag 'v3.13' into next 1 and 2 are new 3 is in Linus' tree as commit ed1c96429a6a 4 9a591f39a9d1 5 5b589d44fad1 6 ca7786a2f916 7 f64410ec6654 8 and 9 are subsumed by something in Linus' tree. So every time I merge your tree into linux-next I get duplicates (whcih can cause conflicts if there are other changes to the same areas of the the files effected). Also, if James really merged you tree (i.e. with a "git pull" or "git fetch; get merge") then we would end up with duplicates in his tree (and then Linus' tree). I can see that part of the problem this time round is that Serge cherry-picked (or rebased) your commits 3-6 above onto James' tree before asking Linus to pull. So, the easiest way for you to clean up from this is to now rebase onto v3.16-rc1 (which will leave you with just commits 1 and 2) and then ensure that in the future James (or whoever is handling the security tree) pulls your tree (and doesn't cherry-pick the patches). Then after that has happened, you can fast forward your tree onto that upstream tree, or wait until the next -rc1 and fast forward to that. I hope that is sort of clear and makes some sense? (As an aside, if you do a git pull on a tag, it will create a merge commit even if it doesn't need to, so for example doing "git merge " will create a merge rather than just fast forwarding.) -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi Paul, On Wed, 18 Jun 2014 14:26:27 -0400 Paul Moore p...@paul-moore.com wrote: On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote: The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next) contains some commits going back to January and also has merges of v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1, you find that it has onlt 2 unique commits (the most recent 2) which means that the others were merged upstream after being rewritten. :-( Without going through each of the differences between the SELinux tree and what is in Linus' tree in this email, I can assure you there is nothing nefarious going on here, just some differences in tree management between James' Linux Security tree and the SELinux tree which resulted in some backports and other mess. The good news is that James' and the rest of us under the Linux Security tree have now established a protocol moving forward which should avoid these nasties. Sounds good. I usually assume that these issues are misunderstandings or oversights. So, back to your concerns - what do you want to see in linux-next? My practice for the SELinux #next branch has been to apply patches on top of the latest major release from Linus, e.g. 3.15, and when a new major release is made I merge it into #next and restart the process. I generally send James' a pull request in the -rc6/7 timeframe using the #next branch. While this has resulted in some ugliness (see above comments) it keeps the SELinux #next branch steady so others can pull from it without major problems. Does this approach not work for you and linux-next? OK, you should probably base your tree on -rc1 or 2, that way all your stuff for the previous merge window is upstream and you don't need to worry about it any more. As for your current tree, it contains the following commits: (1) 5c7001b84be5 SELinux: use ARRAY_SIZE (2) aa65506f198c selinux, kbuild: remove unnecessary $(hostprogs-y) from clean-files 170b5910d9fb Merge tag 'v3.15' into next (3) 47dd0b76ace9 selinux: conditionally reschedule in hashtab_insert while loading selinux policy (4) 612c353178c4 selinux: conditionally reschedule in mls_convert_context while loading selinux policy (5) 4f189988a0a5 selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES (6) 626b9740fa73 selinux: Report permissive mode in avc: denied messages. 6d32c850621b Merge tag 'v3.14' into next (7) eee3094683fb selinux: correctly label /proc inodes in use before the policy is loaded (8) 0909c0ae999c selinux: put the mmap() DAC controls before the MAC controls (9) 81c94e76ce8e selinux: fix the output of ./scripts/get_maintainer.pl for SELinux 41be702a542a Merge tag 'v3.13' into next 1 and 2 are new 3 is in Linus' tree as commit ed1c96429a6a 4 9a591f39a9d1 5 5b589d44fad1 6 ca7786a2f916 7 f64410ec6654 8 and 9 are subsumed by something in Linus' tree. So every time I merge your tree into linux-next I get duplicates (whcih can cause conflicts if there are other changes to the same areas of the the files effected). Also, if James really merged you tree (i.e. with a git pull or git fetch; get merge) then we would end up with duplicates in his tree (and then Linus' tree). I can see that part of the problem this time round is that Serge cherry-picked (or rebased) your commits 3-6 above onto James' tree before asking Linus to pull. So, the easiest way for you to clean up from this is to now rebase onto v3.16-rc1 (which will leave you with just commits 1 and 2) and then ensure that in the future James (or whoever is handling the security tree) pulls your tree (and doesn't cherry-pick the patches). Then after that has happened, you can fast forward your tree onto that upstream tree, or wait until the next -rc1 and fast forward to that. I hope that is sort of clear and makes some sense? (As an aside, if you do a git pull on a tag, it will create a merge commit even if it doesn't need to, so for example doing git merge tag from Linus' tree after your commits are merged upstream will create a merge rather than just fast forwarding.) -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On Friday, June 20, 2014 01:08:37 AM Stephen Rothwell wrote: Hi Paul, Howdy. On Wed, 18 Jun 2014 14:26:27 -0400 Paul Moore p...@paul-moore.com wrote: On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote: I'm going to chop up your email a bit so it makes more sense when replying, my apologies if I make things worse. As for your current tree, it contains the following commits: (1) 5c7001b84be5 SELinux: use ARRAY_SIZE (2) aa65506f198c selinux, kbuild: remove unnecessary $(hostprogs-y) from clean-files 170b5910d9fb Merge tag 'v3.15' into next (3) 47dd0b76ace9 selinux: conditionally reschedule in hashtab_insert while loading selinux policy (4) 612c353178c4 selinux: conditionally reschedule in mls_convert_context while loading selinux policy (5) 4f189988a0a5 selinux: reject setexeccon() on MNT_NOSUID applications with -EACCES (6) 626b9740fa73 selinux: Report permissive mode in avc: denied messages. 6d32c850621b Merge tag 'v3.14' into next (7) eee3094683fb selinux: correctly label /proc inodes in use before the policy is loaded (8) 0909c0ae999c selinux: put the mmap() DAC controls before the MAC controls (9) 81c94e76ce8e selinux: fix the output of ./scripts/get_maintainer.pl for SELinux 41be702a542a Merge tag 'v3.13' into next 1 and 2 are new Yes, these are the new SELinux patches that should be in linux-next. 3 is in Linus' tree as commit ed1c96429a6a 4 9a591f39a9d1 5 5b589d44fad1 6 ca7786a2f916 7 f64410ec6654 8 and 9 are subsumed by something in Linus' tree. These are likely caused by the problems we talked about earlier. So, back to your concerns - what do you want to see in linux-next? My practice for the SELinux #next branch has been to apply patches on top of the latest major release from Linus, e.g. 3.15, and when a new major release is made I merge it into #next and restart the process. I generally send James' a pull request in the -rc6/7 timeframe using the #next branch. While this has resulted in some ugliness (see above comments) it keeps the SELinux #next branch steady so others can pull from it without major problems. Does this approach not work for you and linux-next? OK, you should probably base your tree on -rc1 or 2, that way all your stuff for the previous merge window is upstream and you don't need to worry about it any more. ... So, the easiest way for you to clean up from this is to now rebase onto v3.16-rc1 (which will leave you with just commits 1 and 2) and then ensure that in the future James (or whoever is handling the security tree) pulls your tree (and doesn't cherry-pick the patches). Then after that has happened, you can fast forward your tree onto that upstream tree, or wait until the next -rc1 and fast forward to that. I want to avoid use a -rcX release as the foundation of any of my trees; the - rc releases aren't as stable and it goes against what we're trying to do with the different Linux Security trees. Unfortunately, based on what I've read above, this seems to be incompatible with linux-next. While I hate to split my development branch from the #next branch, it seems like that is the only way to accomplish both a reasonably current and stable development tree and get the patches into linux-next. Unless you, or anyone else for that matter, has a different suggestion I'm going to go ahead and turn the current SELinux #next branch into a development branch and create a new #next branch that will be based on the most current -rc1, this new #next branch will be created new for each major release. Not exactly what I was hoping for, but will that work? -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi Paul, On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore p...@paul-moore.com wrote: I want to avoid use a -rcX release as the foundation of any of my trees; the - rc releases aren't as stable and it goes against what we're trying to do with the different Linux Security trees. Unfortunately, based on what I've read above, this seems to be incompatible with linux-next. The problem with basing your development for v3.17 on v3.15 is that you do not take into account any of the changes done by others during v3.16-rc1 (or even your upstream tree) some of which may be core API changes. While I hate to split my development branch from the #next branch, it seems I don't want that either ... like that is the only way to accomplish both a reasonably current and stable development tree and get the patches into linux-next. Unless you, or anyone else for that matter, has a different suggestion I'm going to go ahead and turn the current SELinux #next branch into a development branch and create a new #next branch that will be based on the most current -rc1, this new #next branch will be created new for each major release. Not exactly what I was hoping for, but will that work? Do you mean that your #next branch will just be a merge of -rc1 and your development branch? That would not actually change anything (except that you would possibly take care of some conflicts for me). At the core, what is in linux-next should just be exactly what will be merged by your upstream. My real point here is that that is not what has happened recently. The patches in your tree have been cherry-picked or rebased into James' or Serge's trees, not merged so we now have duplication. This is what you need to solve with James and Serge. linux-next is a side issue - I can cope with a lot. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
Quoting Stephen Rothwell (s...@canb.auug.org.au): Hi Paul, On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore p...@paul-moore.com wrote: I want to avoid use a -rcX release as the foundation of any of my trees; the - rc releases aren't as stable and it goes against what we're trying to do with the different Linux Security trees. Unfortunately, based on what I've read above, this seems to be incompatible with linux-next. The problem with basing your development for v3.17 on v3.15 is that you do not take into account any of the changes done by others during v3.16-rc1 (or even your upstream tree) some of which may be core API changes. While I hate to split my development branch from the #next branch, it seems I don't want that either ... like that is the only way to accomplish both a reasonably current and stable development tree and get the patches into linux-next. Unless you, or anyone else for that matter, has a different suggestion I'm going to go ahead and turn the current SELinux #next branch into a development branch and create a new #next branch that will be based on the most current -rc1, this new #next branch will be created new for each major release. Not exactly what I was hoping for, but will that work? Do you mean that your #next branch will just be a merge of -rc1 and your development branch? That would not actually change anything (except that you would possibly take care of some conflicts for me). At the core, what is in linux-next should just be exactly what will be merged by your upstream. My real point here is that that is not what has happened recently. The patches in your tree have been cherry-picked or rebased into James' or Serge's trees, not merged so we now have duplication. This is what you need to solve with James and Serge. linux-next is a side issue - I can cope with a lot. The duplicates were the result of several misunderstandings and general naivity all on my part. I'm actually still not clear on what usually happens with the selinux tree - it feeds into linux-next, then gets 'pull'ed by James into security-next for a pull request? Do you usually send a request to James when ready, he pulls, then he sends pull request to Linus? (Or am I wrong, and you usually send your own requests to Linus?) -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
Hi Serge, On Fri, 20 Jun 2014 05:43:56 +0200 Serge E. Hallyn se...@hallyn.com wrote: The duplicates were the result of several misunderstandings and general naivity all on my part. I'm actually still not clear on what usually happens with the selinux tree - it feeds into linux-next, then gets 'pull'ed by James into security-next for a pull request? Do you usually send a request to James when ready, he pulls, then he sends pull request to Linus? (Or am I wrong, and you usually send your own requests to Linus?) If you is Paul, then I am pretty sure he asks James to pull and then James in turn asks Linus to pull. If you is me, then no :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: linux-next: the selinux tree needs cleaning up
On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote: > Hi Paul, > > The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next) > contains some commits going back to January and also has merges of > v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1, > you find that it has onlt 2 unique commits (the most recent 2) which > means that the others were merged upstream after being rewritten. :-( Without going through each of the differences between the SELinux tree and what is in Linus' tree in this email, I can assure you there is nothing nefarious going on here, just some differences in tree management between James' Linux Security tree and the SELinux tree which resulted in some backports and other mess. The good news is that James' and the rest of us under the Linux Security tree have now established a protocol moving forward which should avoid these nasties. So, back to your concerns - what do you want to see in linux-next? My practice for the SELinux #next branch has been to apply patches on top of the latest "major" release from Linus, e.g. 3.15, and when a new major release is made I merge it into #next and restart the process. I generally send James' a pull request in the -rc6/7 timeframe using the #next branch. While this has resulted in some ugliness (see above comments) it keeps the SELinux #next branch steady so others can pull from it without major problems. Does this approach not work for you and linux-next? -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: the selinux tree needs cleaning up
On Wednesday, June 18, 2014 08:40:46 AM Stephen Rothwell wrote: Hi Paul, The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next) contains some commits going back to January and also has merges of v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1, you find that it has onlt 2 unique commits (the most recent 2) which means that the others were merged upstream after being rewritten. :-( Without going through each of the differences between the SELinux tree and what is in Linus' tree in this email, I can assure you there is nothing nefarious going on here, just some differences in tree management between James' Linux Security tree and the SELinux tree which resulted in some backports and other mess. The good news is that James' and the rest of us under the Linux Security tree have now established a protocol moving forward which should avoid these nasties. So, back to your concerns - what do you want to see in linux-next? My practice for the SELinux #next branch has been to apply patches on top of the latest major release from Linus, e.g. 3.15, and when a new major release is made I merge it into #next and restart the process. I generally send James' a pull request in the -rc6/7 timeframe using the #next branch. While this has resulted in some ugliness (see above comments) it keeps the SELinux #next branch steady so others can pull from it without major problems. Does this approach not work for you and linux-next? -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: the selinux tree needs cleaning up
Hi Paul, The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next) contains some commits going back to January and also has merges of v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1, you find that it has onlt 2 unique commits (the most recent 2) which means that the others were merged upstream after being rewritten. :-( Please clean this up. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
linux-next: the selinux tree needs cleaning up
Hi Paul, The selinux tree (git://git.infradead.org/users/pcmoore/selinux#next) contains some commits going back to January and also has merges of v3.13, v3.14 and v3.15 in it. If you rebase that tree onto v3.16-rc1, you find that it has onlt 2 unique commits (the most recent 2) which means that the others were merged upstream after being rewritten. :-( Please clean this up. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
