[RFC] linux-yocto: drop machine from SRCREV_FORMAT

Submitted by Martin Jansa on Sept. 25, 2012, 10:51 a.m.

Details

Message ID 1348570313-16920-1-git-send-email-Martin.Jansa@gmail.com
State Awaiting Upstream
Delegated to: Richard Purdie
Headers show

Commit Message

Martin Jansa Sept. 25, 2012, 10:51 a.m.
* otherwise LOCALCOUNT is incremented after each MACHINE switch when 
  machine usually has different SRCREV (e.g. because of different KBRANCH)
* see http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029392.html

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/recipes-kernel/linux/linux-yocto.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 973970d..6efb578 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -16,7 +16,7 @@  LINUX_KERNEL_TYPE ?= "standard"
 # KMETA ?= ""
 KBRANCH ?= "master"
 KMACHINE ?= "${MACHINE}"
-SRCREV_FORMAT ?= "meta_machine" 
+SRCREV_FORMAT ?= "meta" 
 
 LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
 

Comments

Richard Purdie Sept. 25, 2012, 12:25 p.m.
On Tue, 2012-09-25 at 12:51 +0200, Martin Jansa wrote:
> * otherwise LOCALCOUNT is incremented after each MACHINE switch when 
>   machine usually has different SRCREV (e.g. because of different KBRANCH)
> * see http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029392.html
> 
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
>  meta/recipes-kernel/linux/linux-yocto.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
> index 973970d..6efb578 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE ?= "standard"
>  # KMETA ?= ""
>  KBRANCH ?= "master"
>  KMACHINE ?= "${MACHINE}"
> -SRCREV_FORMAT ?= "meta_machine" 
> +SRCREV_FORMAT ?= "meta" 
>  
>  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"

No, absolutely not. I have discussed this with Bruce before and there
are no guarantees that the meta branch gets updated whenever machine
changes. This is necessary to have deterministic builds and correctness
of sstate for example.

Whatever the problem we're trying to fix here, we need to find a
different way. We probably need to fix the git LOCALCOUNT counters in
the fetcher instead.

Cheers,

Richard
Martin Jansa Sept. 25, 2012, 12:36 p.m.
On Tue, Sep 25, 2012 at 01:25:33PM +0100, Richard Purdie wrote:
> On Tue, 2012-09-25 at 12:51 +0200, Martin Jansa wrote:
> > * otherwise LOCALCOUNT is incremented after each MACHINE switch when 
> >   machine usually has different SRCREV (e.g. because of different KBRANCH)
> > * see http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029392.html
> > 
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> >  meta/recipes-kernel/linux/linux-yocto.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
> > index 973970d..6efb578 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto.inc
> > +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> > @@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE ?= "standard"
> >  # KMETA ?= ""
> >  KBRANCH ?= "master"
> >  KMACHINE ?= "${MACHINE}"
> > -SRCREV_FORMAT ?= "meta_machine" 
> > +SRCREV_FORMAT ?= "meta" 
> >  
> >  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
> 
> No, absolutely not. I have discussed this with Bruce before and there
> are no guarantees that the meta branch gets updated whenever machine
> changes. This is necessary to have deterministic builds and correctness
> of sstate for example.

Isn't SRCREV_FORMAT used only to construct PV? So builds are still
deterministic because SRCREV is still locked to same value?

Also PV which keeps changing without any change in source or metadata
doesn't look deterministic to me.

Cheers,

> Whatever the problem we're trying to fix here, we need to find a
> different way. We probably need to fix the git LOCALCOUNT counters in
> the fetcher instead.
> 
> Cheers,
> 
> Richard
> 
>
Richard Purdie Sept. 25, 2012, 12:46 p.m.
On Tue, 2012-09-25 at 14:36 +0200, Martin Jansa wrote:
> On Tue, Sep 25, 2012 at 01:25:33PM +0100, Richard Purdie wrote:
> > On Tue, 2012-09-25 at 12:51 +0200, Martin Jansa wrote:
> > > * otherwise LOCALCOUNT is incremented after each MACHINE switch when 
> > >   machine usually has different SRCREV (e.g. because of different KBRANCH)
> > > * see http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029392.html
> > > 
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > ---
> > >  meta/recipes-kernel/linux/linux-yocto.inc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
> > > index 973970d..6efb578 100644
> > > --- a/meta/recipes-kernel/linux/linux-yocto.inc
> > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> > > @@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE ?= "standard"
> > >  # KMETA ?= ""
> > >  KBRANCH ?= "master"
> > >  KMACHINE ?= "${MACHINE}"
> > > -SRCREV_FORMAT ?= "meta_machine" 
> > > +SRCREV_FORMAT ?= "meta" 
> > >  
> > >  LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
> > 
> > No, absolutely not. I have discussed this with Bruce before and there
> > are no guarantees that the meta branch gets updated whenever machine
> > changes. This is necessary to have deterministic builds and correctness
> > of sstate for example.
> 
> Isn't SRCREV_FORMAT used only to construct PV? So builds are still
> deterministic because SRCREV is still locked to same value?

PV is what triggers the system to rebuild. So if its not included,
rebuilds won't happen when the revisions change.

> Also PV which keeps changing without any change in source or metadata
> doesn't look deterministic to me.

I agree there is a problem, this is just not the right way to fix it,
the problem is elsewhere, likely in the git fetcher. Making the
revisions in the sqlite database respect components of STAMP/WORKDIR is
probably the way we'll end up having to fix this (so some database
entries are machine specific, some arch specific, some allarch).

Cheers,

Richard