Re: linux-next: Tree for Oct 14 (bcache)

Re: linux-next: Tree for Oct 14 (bcache)

[Randy Dunlap]

On 10/14/13 07:48, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131014 tag is also provided for convenience.
> 
> Gained a few conflicts, but nothing too exciting. x86 and ARM default
> configurations build fine. There were some build failures unrelated to

Maybe you could build allmodconfig instead of a default config
for more better coverage?  I am seeing lots of build problems.

> the merge, most of which I fixed and added as patches on top of the
> final merge.


on x86_64:

drivers/md/bcache/request.c: In function 'cached_dev_write':
drivers/md/bcache/request.c:1076:8: error: 'struct btree_op' has no member named 'cache_bio'


-- 
~Randy

Re: linux-next: Tree for Oct 14 (bcache)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> On 10/14/13 07:48, Thierry Reding wrote:

> > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > configurations build fine. There were some build failures unrelated to

> Maybe you could build allmodconfig instead of a default config
> for more better coverage?  I am seeing lots of build problems.

I'd say in addition - if you look at the last tree I did it's got fixes
for all these tihngs I think.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Mon, Oct 14, 2013 at 09:27:23PM +0100, Mark Brown wrote:
> On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> > On 10/14/13 07:48, Thierry Reding wrote:
> 
> > > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > > configurations build fine. There were some build failures unrelated to
> 
> > Maybe you could build allmodconfig instead of a default config
> > for more better coverage?  I am seeing lots of build problems.
> 
> I'd say in addition - if you look at the last tree I did it's got fixes
> for all these tihngs I think.

Strange, I didn't see any build fixes in it.

Oh wait, they were applied right after the merges that broke. I hadn't
checked for that.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On Tue, Oct 15, 2013 at 10:46:32AM +0200, Thierry Reding wrote:

> Oh wait, they were applied right after the merges that broke. I hadn't
> checked for that.

Yeah, it's because I've been doing incremental build checks - the builds
fail at the point the tree gets merged in.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> On 10/14/13 07:48, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131014 tag is also provided for convenience.
> > 
> > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > configurations build fine. There were some build failures unrelated to
> 
> Maybe you could build allmodconfig instead of a default config
> for more better coverage?  I am seeing lots of build problems.

Ideally I'd be able to run allmodconfig for each merge, but I have
neither the computing power nor the time to do that. I can add
allmodconfig to the set of configurations that I build after the final
merge, but I don't know how much good that is if I don't actually have
any time to fix them up.

Furthermore I'm beginning to think that perhaps we should create some
infrastructure around this that would make it easier to submit requests
for build coverage. Quite a few people seem to run autobuilders, so if
all those could be harnessed to build linux-next (perhaps even on a per
merge basis) that would give great coverage.

> > the merge, most of which I fixed and added as patches on top of the
> > final merge.
> 
> 
> on x86_64:
> 
> drivers/md/bcache/request.c: In function 'cached_dev_write':
> drivers/md/bcache/request.c:1076:8: error: 'struct btree_op' has no member named 'cache_bio'

It's quite possible that I messed that up during the merge. The bcache
conflicts weren't very trivial. This one in particular seems to be
caused by a commit that went into 3.12-rc5 and one in the block tree's
linux-next branch.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]