Hi Dan, On Thu, 16 Feb 2012 06:39:42 -0800 (PST) Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote: > > > From: Greg KH [mailto:greg@xxxxxxxxx] > > Subject: Re: linux-next: build failure after merge of the staging tree > > > > On Thu, Feb 16, 2012 at 03:23:16PM +1100, Stephen Rothwell wrote: > > > Hi Greg, > > > > > > After merging the staging tree, today's linux-next build (x86_64 > > > allmodconfig) failed like this: > > > > > > drivers/staging/ramster/zcache-main.c:2969:2: error: unknown field 'invalidate_page' specified in > > initializer > > > drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in > > initializer > > > drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in > > initializer > > > > > > I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ... > > Absolutely, against next-20120214, which contained commit > > 91c6cc9b5c216bd067f9af2cc64fcbe190755865 > > 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. > > > Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem"). > > > > > > I have used the staging tree from next-20120215 for today. > > > > Dan, can you please fix this? > > Hmmm... moving target. I'm trying to get in touch with Konrad > to see if we can determine what is going on. See above. > 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. :-( 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?). -- Cheers, Stephen Rothwell sfr@xxxxxxxxxxxxxxxx http://www.canb.auug.org.au/~sfr/
Attachment:
pgpVgooQVn68A.pgp
Description: PGP signature
