Re: [PATCH] sitara-linux-ti-staging_3.14.bb: Update commit to pull in suspend/standby fix

[Denys Dmytriyenko <denys@ti.com>]

On Thu, Jan 29, 2015 at 09:56:28AM -0500, Cooper Jr., Franklin wrote:
> 
> 
> > -----Original Message-----
> > From: Dmytriyenko, Denys
> > Sent: Wednesday, January 28, 2015 6:50 PM
> > To: Cooper Jr., Franklin
> > Cc: meta-ti@yoctoproject.org
> > Subject: Re: [meta-ti] [PATCH] sitara-linux-ti-staging_3.14.bb: Update
> > commit to pull in suspend/standby fix
> > 
> > On Wed, Jan 28, 2015 at 06:27:38PM -0600, Franklin S. Cooper Jr wrote:
> > > From: "Franklin S. Cooper Jr" <fcooper@ti.com>
> > >
> > > Signed-off-by: Franklin S. Cooper Jr <fcooper@ti.com>
> > > ---
> > >  .../linux/sitara-linux-ti-staging_3.14.bb          |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/recipes-kernel/linux/sitara-linux-ti-staging_3.14.bb b/recipes-
> > kernel/linux/sitara-linux-ti-staging_3.14.bb
> > > index f9c4641..991f694 100644
> > > --- a/recipes-kernel/linux/sitara-linux-ti-staging_3.14.bb
> > > +++ b/recipes-kernel/linux/sitara-linux-ti-staging_3.14.bb
> > > @@ -35,7 +35,7 @@ S = "${WORKDIR}/git"
> > >
> > >  BRANCH = "sitara-ti-linux-3.14.y"
> > >
> > > -SRCREV = "2d7148a3a95a2811604611f6c66a8826a61b8b12"
> > > +SRCREV = "99b50bfb0f3fb0e43de31a6735989d31660b0835"
> > >  PV = "3.14.26"
> > 
> > No PV or PR bump? Are you sure?

> [Franklin] I still get confused by the "smarter" bitbake determining when it 
> needs to rebuild a recipe.

Well, bitbake is smart and it will rebuild the recipe if it changes.


> Is the problem that all other kernel driver recipes still won't be rebuilt 
> even though bitbake may know to rebuild the kernel recipe?

The problem might be with out-of-tree kernel modules (graphics, cryptodev, 
etc.) and with the binary packages and the proper upgrade path (which you 
probably don't care for now), since package upgrade is handled by the package 
manager (opkg) and not bitbake. From opkg perspective, only the version and 
the revision matter and should be sorted properly, so if SRCREV is in PR, it 
may go lower (not in this case though) and won't get updated.

-- 
Denys