Re: linux-next: build failure after merge of the final tree(sparc, ptrace trees related)

[Matt Fleming]

On Fri, 2011-10-14 at 03:54 -0400, David Miller wrote:
> Ptrace folks can we not operate like this?  The only reason I found
> out about the set_current_blocked() transformations was by accident,
> because the original patch was posted to linux-kernel only so it never
> got queued up into sparc patchwork.
> 
> Then once Oleg mentioned it to me, it didn't even compile so I fixed
> it up and put the fixed up copy into my tree.  It also didn't
> transform the TS_RESTORE_SIGMASK cases in the sparc signal code, so I
> also added a patch to the sparc tree which took care of that.
> 
> Now you guys are creating conflicts against those fixed up patches in
> another non-sparc tree, and adding new kinds of build failures as
> well.
> 
> This doesn't work.

Sorry David, this is my fault.

The reason that these patches couldn't be taken through the arch trees
was because they were dependent on the non-arch patch that introduced
block_sigmask(). I figured it would make more sense to put all the
patches through Oleg's tree. It's now pretty clear I was wrong about
that.

In hindsight, what I should have done was got the first patch that
introduced block_sigmask() into 3.1, then waited till the next release
cycle and sent out all the arch patches to the arch maintainers. That
way the patches could have been pulled into the respective arch trees.

Guys, how did you want to sort this out? Should we get the first patch
into 3.1, then get all the arch maintainers to pick up their patches?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/