> From: Stephen Rothwell [mailto:sfr@xxxxxxxxxxxxxxxx] > Subject: Re: linux-next: build failure after merge of the staging tree > > Hi Dan, Hi Stephen -- Thanks for the reply and sorry for the hassle. See below for important question. > > which changed the names of those fields from "flush*" to "invalidate*". > > I am the author of that commit but it is pulled through Konrad Wilk > > (cc'ed). Perhaps Konrad's pull succeeded in next-20120214 but > > failed in next-20120215? > > If a fetch fails for a particular tree on a particular day, I use the > version of that tree from the day before, so that is not the problem (and > in any case, the fetch did not fail). > > > Kernel.org seems to be down so I can't see if that commit is > > in next-20120215 but if it is not that would likely cause > > the above errors. > > It is in next-20120215 (and has been since next-20120124). However, I > merge Konrad's (tmem) tree *after* I merge the staging tree, so that commit > was not present when I tried to build linux-next after merging the > staging tree. Huh? Do you do allyesconfig/allmodconfig build testing after you pull each individual tree or only after all trees are pulled? (Apparently the former, as otherwise the ordering shouldn't matter, right?) > > The good news is that there seems to be an increasing number > > of people contributing to and building things on top of > > cleancache/frontswap stuff. The bad news is that it is difficult > > to avoid ordering dependencies that affect -next. My apologies > > and if you have any dependency-savvy processes that would solve > > this that we are not using, please let me/us know. > > Well, if anyone had bothered to tell me, I could have reordered the > trees. However, that does not change the fact that the staging tree is > now broken on its own. Which means that Greg can't even do unit testing > on his tree with your code in it. :-( If you are doing the after-every-individual-tree build testing, yes, if you could pull konrad's tmem tree first, that would solve this problem I believe.** I suspect unit testing doesn't make much as much sense in staging as it does in the core kernel. I did testing of ramster in my public git tree (which includes the tmem patchset coming to you via konrad) but, since it is a staging driver, the bits have to go through Greg. > One solutions is for Greg to merge Konrad's tree (or a subset of it) into > the staging tree. Another is for this work to become a separate tree > (however, I think other stuff in the staging tree depends on this work, > right?). Yes, there are a number of parts from different companies/timezones now flying in close formation. The name change (flush->invalidate) causing this problem was insisted upon by Andrew Morton (and has been in linux-next for several months), otherwise it wouldn't have happened and wouldn't be causing these issues :-( But better to work through them in -next than in Linus' merge window I guess. Thanks, Dan ** I just found another problem that occurs with allmodconfig so will be submitting a patch for that to GregKH shortly and will cc you. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
