All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] base.bbclass: add named SRCREVs to the sstate hash
@ 2019-05-08 14:02 Michael Ho
  2019-05-08 15:16 ` Christopher Larson
  2019-05-27 15:42 ` [PATCH v2] " Michael Ho
  0 siblings, 2 replies; 8+ messages in thread
From: Michael Ho @ 2019-05-08 14:02 UTC (permalink / raw)
  To: openembedded-core; +Cc: Michael Ho

Several fetchers support named sources that require setting a SRCREV with
the source name as a suffix. These named SRCREV variables are not captured
in the sstate hash calculation because they're only referenced within the
bitbake fetcher function.

Add a snippet to the base.bbclass anonymous python to add all named SRCREV
variables to the vardeps of do_fetch to capture them in the sstate hash
calculation.

Testing of the bug can be shown by running the following bitbake commands
with this patch set not applied:

bitbake vulkan-demos | tee
sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
  ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb
bitbake vulkan-demos | tee;

Results in no errors despite a broken SRCREV because the vulkan-demos is
considered unchanged.

After applying this patch the above commands instead result in a fetcher
error which is correct.
---
 meta/classes/base.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1636c6e..84a27f5 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -638,6 +638,16 @@ python () {
 
     if needsrcrev:
         d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
+        # Gather all SRCREV_* references to add to the sstate hash calculation
+        # This may capture SRCREVs not used but it's difficult to try to restrict it
+        # to only what is needed
+        for dkey in d.keys():
+            if dkey.startswith("SRCREV_"):
+                # This anonymous python snippet is called multiple times so we
+                # need to be careful to not double up the appends here and cause
+                # the base hash to mismatch the task hash
+                if dkey not in (d.getVarFlag("do_fetch", "vardeps") or '').split():
+                    d.appendVarFlag("do_fetch", "vardeps", " {}".format(dkey))
 
     set_packagetriplet(d)
 
-- 
2.7.4



^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] base.bbclass: add named SRCREVs to the sstate hash
  2019-05-08 14:02 [PATCH] base.bbclass: add named SRCREVs to the sstate hash Michael Ho
@ 2019-05-08 15:16 ` Christopher Larson
  2019-05-27 15:37   ` Michael.Ho
  2019-05-27 15:42 ` [PATCH v2] " Michael Ho
  1 sibling, 1 reply; 8+ messages in thread
From: Christopher Larson @ 2019-05-08 15:16 UTC (permalink / raw)
  To: Michael Ho; +Cc: Patches and discussions about the oe-core layer

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

Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT
controls how the multiple revs end up in PV, and the change to PV results
in rebuilding anyway. And iterating over d.keys() is inefficient, *if*
you’re going to do this, operate on SRCREV, gather up the name= parameters
from scm urls, and use that to drive it.

On Wed, May 8, 2019 at 7:10 AM Michael Ho <Michael.Ho@bmw.de> wrote:

> Several fetchers support named sources that require setting a SRCREV with
> the source name as a suffix. These named SRCREV variables are not captured
> in the sstate hash calculation because they're only referenced within the
> bitbake fetcher function.
>
> Add a snippet to the base.bbclass anonymous python to add all named SRCREV
> variables to the vardeps of do_fetch to capture them in the sstate hash
> calculation.
>
> Testing of the bug can be shown by running the following bitbake commands
> with this patch set not applied:
>
> bitbake vulkan-demos | tee
> sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
>   ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb
> bitbake vulkan-demos | tee;
>
> Results in no errors despite a broken SRCREV because the vulkan-demos is
> considered unchanged.
>
> After applying this patch the above commands instead result in a fetcher
> error which is correct.
> ---
>  meta/classes/base.bbclass | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 1636c6e..84a27f5 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -638,6 +638,16 @@ python () {
>
>      if needsrcrev:
>          d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
> +        # Gather all SRCREV_* references to add to the sstate hash
> calculation
> +        # This may capture SRCREVs not used but it's difficult to try to
> restrict it
> +        # to only what is needed
> +        for dkey in d.keys():
> +            if dkey.startswith("SRCREV_"):
> +                # This anonymous python snippet is called multiple times
> so we
> +                # need to be careful to not double up the appends here
> and cause
> +                # the base hash to mismatch the task hash
> +                if dkey not in (d.getVarFlag("do_fetch", "vardeps") or
> '').split():
> +                    d.appendVarFlag("do_fetch", "vardeps", "
> {}".format(dkey))
>
>      set_packagetriplet(d)
>
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 3860 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] base.bbclass: add named SRCREVs to the sstate hash
  2019-05-08 15:16 ` Christopher Larson
@ 2019-05-27 15:37   ` Michael.Ho
  2019-05-27 15:44     ` Martin Jansa
  0 siblings, 1 reply; 8+ messages in thread
From: Michael.Ho @ 2019-05-27 15:37 UTC (permalink / raw)
  To: kergoth; +Cc: openembedded-core

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

Hi Christopher,

Thank you for the feedback. Since SRCPV is not always enforced (correct me if I’m wrong), it seems easy to trip over this bug when just following the documentation on multiple named source uri’s (also if you purposely don’t want to include the secondary source revisions in the package version). I’ll give it another shot to make it more efficient. If it’s not expected to be an encounterable bug case you can ignore the patch.

Thanks.

Kind regards,
Michael

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de<mailto:michael.ho@bmw-carit.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------


From: Christopher Larson <kergoth@gmail.com>
Date: Wednesday, 8 May 2019 at 5:17 pm
To: "Ho Michael, JC-3UL" <Michael.Ho@bmw.de>
Cc: Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT controls how the multiple revs end up in PV, and the change to PV results in rebuilding anyway. And iterating over d.keys() is inefficient, *if* you’re going to do this, operate on SRCREV, gather up the name= parameters from scm urls, and use that to drive it.

On Wed, May 8, 2019 at 7:10 AM Michael Ho <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>> wrote:
Several fetchers support named sources that require setting a SRCREV with
the source name as a suffix. These named SRCREV variables are not captured
in the sstate hash calculation because they're only referenced within the
bitbake fetcher function.

Add a snippet to the base.bbclass anonymous python to add all named SRCREV
variables to the vardeps of do_fetch to capture them in the sstate hash
calculation.

Testing of the bug can be shown by running the following bitbake commands
with this patch set not applied:

bitbake vulkan-demos | tee
sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
  ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb<http://vulkan-demos_git.bb>
bitbake vulkan-demos | tee;

Results in no errors despite a broken SRCREV because the vulkan-demos is
considered unchanged.

After applying this patch the above commands instead result in a fetcher
error which is correct.
---
 meta/classes/base.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1636c6e..84a27f5 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -638,6 +638,16 @@ python () {

     if needsrcrev:
         d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
+        # Gather all SRCREV_* references to add to the sstate hash calculation
+        # This may capture SRCREVs not used but it's difficult to try to restrict it
+        # to only what is needed
+        for dkey in d.keys():
+            if dkey.startswith("SRCREV_"):
+                # This anonymous python snippet is called multiple times so we
+                # need to be careful to not double up the appends here and cause
+                # the base hash to mismatch the task hash
+                if dkey not in (d.getVarFlag("do_fetch", "vardeps") or '').split():
+                    d.appendVarFlag("do_fetch", "vardeps", " {}".format(dkey))

     set_packagetriplet(d)

--
2.7.4

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 9981 bytes --]

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH v2] base.bbclass: add named SRCREVs to the sstate hash
  2019-05-08 14:02 [PATCH] base.bbclass: add named SRCREVs to the sstate hash Michael Ho
  2019-05-08 15:16 ` Christopher Larson
@ 2019-05-27 15:42 ` Michael Ho
  1 sibling, 0 replies; 8+ messages in thread
From: Michael Ho @ 2019-05-27 15:42 UTC (permalink / raw)
  To: openembedded-core; +Cc: Michael Ho

Several fetchers support named sources that require setting a SRCREV with
the source name as a suffix. These named SRCREV variables are not captured
in the sstate hash calculation because they're only referenced within the
bitbake fetcher function. Several recipes avoid this bug by adding the
different SRCREVs to their packaging versioning but this is not enforced so
it is very trivial to trip this bug case.

Add a snippet to the base.bbclass anonymous python to add all named SRCREV
variables to the vardeps of do_fetch to capture them in the sstate hash
calculation.

Testing of the bug can be shown by running the following bitbake commands
with this patch set not applied:

bitbake vulkan-demos | tee
sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
  ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb
bitbake vulkan-demos | tee;

The above results in no errors despite a broken SRCREV because the recipe  is
considered unchanged by the bitbake sstate hash.

After applying this patch the above commands instead result in a fetcher
error which is correct.
---
 meta/classes/base.bbclass | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1636c6e..25d5fff 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -639,6 +639,18 @@ python () {
     if needsrcrev:
         d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
 
+        # Gather all named SRCREVs to add to the sstate hash calculation
+        # This anonymous python snippet is called multiple times so we
+        # need to be careful to not double up the appends here and cause
+        # the base hash to mismatch the task hash
+        for uri in srcuri.split():
+            parm = bb.fetch.decodeurl(uri)[5]
+            uri_names = parm.get("name", "").split(",")
+            for uri_name in filter(None, uri_names):
+                srcrev_name = "SRCREV_{}".format(uri_name)
+                if srcrev_name not in (d.getVarFlag("do_fetch", "vardeps") or "").split():
+                    d.appendVarFlag("do_fetch", "vardeps", " {}".format(srcrev_name))
+
     set_packagetriplet(d)
 
     # 'multimachine' handling
-- 
2.7.4



^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] base.bbclass: add named SRCREVs to the sstate hash
  2019-05-27 15:37   ` Michael.Ho
@ 2019-05-27 15:44     ` Martin Jansa
  2019-05-27 16:34       ` Michael.Ho
  0 siblings, 1 reply; 8+ messages in thread
From: Martin Jansa @ 2019-05-27 15:44 UTC (permalink / raw)
  To: Michael.Ho; +Cc: Patches and discussions about the oe-core layer

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

In those recipes which don't include SRCPV in PV (for whatever reason) we
usually add them explicitly with:
do_fetch[vardeps] += "SRCREV_common"
it's not ideal as people sometimes forget about this. Good practice is to
add this next to the SRCREV_FORMAT (if you set one, to clearly show which
revs are and aren't included).

On Mon, May 27, 2019 at 5:37 PM <Michael.Ho@bmw.de> wrote:

> Hi Christopher,
>
>
>
> Thank you for the feedback. Since SRCPV is not always enforced (correct me
> if I’m wrong), it seems easy to trip over this bug when just following the
> documentation on multiple named source uri’s (also if you purposely don’t
> want to include the secondary source revisions in the package version).
> I’ll give it another shot to make it more efficient. If it’s not expected
> to be an encounterable bug case you can ignore the patch.
>
>
>
> Thanks.
>
>
>
> Kind regards,
>
> Michael
>
>
>
> --
>
> *BMW Car IT GmbH*
> Michael Ho
> Spezialist Entwicklung – Build and Release Engineering
> Lise-Meitner-Straße 14
> 89081 Ulm
>
> Tel.: ­+49-731-37804-071
>
> Mobil: +49-152-54980-471
> Fax: +49-731-37804-001
> Mail: michael.ho@bmw-carit.de
> Web: http://www.bmw-carit.de
> -------------------------------------------------------------------------
> BMW Car IT GmbH
> Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
> Sitz und Registergericht: München HRB 134810
> -------------------------------------------------------------------------
>
>
>
>
>
> *From: *Christopher Larson <kergoth@gmail.com>
> *Date: *Wednesday, 8 May 2019 at 5:17 pm
> *To: *"Ho Michael, JC-3UL" <Michael.Ho@bmw.de>
> *Cc: *Patches and discussions about the oe-core layer <
> openembedded-core@lists.openembedded.org>
> *Subject: *Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the
> sstate hash
>
>
>
> Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT
> controls how the multiple revs end up in PV, and the change to PV results
> in rebuilding anyway. And iterating over d.keys() is inefficient, *if*
> you’re going to do this, operate on SRCREV, gather up the name= parameters
> from scm urls, and use that to drive it.
>
>
>
> On Wed, May 8, 2019 at 7:10 AM Michael Ho <Michael.Ho@bmw.de> wrote:
>
> Several fetchers support named sources that require setting a SRCREV with
> the source name as a suffix. These named SRCREV variables are not captured
> in the sstate hash calculation because they're only referenced within the
> bitbake fetcher function.
>
> Add a snippet to the base.bbclass anonymous python to add all named SRCREV
> variables to the vardeps of do_fetch to capture them in the sstate hash
> calculation.
>
> Testing of the bug can be shown by running the following bitbake commands
> with this patch set not applied:
>
> bitbake vulkan-demos | tee
> sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
>   ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb
> bitbake vulkan-demos | tee;
>
> Results in no errors despite a broken SRCREV because the vulkan-demos is
> considered unchanged.
>
> After applying this patch the above commands instead result in a fetcher
> error which is correct.
> ---
>  meta/classes/base.bbclass | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 1636c6e..84a27f5 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -638,6 +638,16 @@ python () {
>
>      if needsrcrev:
>          d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
> +        # Gather all SRCREV_* references to add to the sstate hash
> calculation
> +        # This may capture SRCREVs not used but it's difficult to try to
> restrict it
> +        # to only what is needed
> +        for dkey in d.keys():
> +            if dkey.startswith("SRCREV_"):
> +                # This anonymous python snippet is called multiple times
> so we
> +                # need to be careful to not double up the appends here
> and cause
> +                # the base hash to mismatch the task hash
> +                if dkey not in (d.getVarFlag("do_fetch", "vardeps") or
> '').split():
> +                    d.appendVarFlag("do_fetch", "vardeps", "
> {}".format(dkey))
>
>      set_packagetriplet(d)
>
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
> --
>
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Senior Software Engineer, Mentor Graphics
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 9523 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] base.bbclass: add named SRCREVs to the sstate hash
  2019-05-27 15:44     ` Martin Jansa
@ 2019-05-27 16:34       ` Michael.Ho
  2019-05-27 16:56         ` Martin Jansa
  0 siblings, 1 reply; 8+ messages in thread
From: Michael.Ho @ 2019-05-27 16:34 UTC (permalink / raw)
  To: martin.jansa; +Cc: openembedded-core

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

Hi Martin,

It seems a little tricky though to need to know about the sstate hashing in order to use named
source revisions and it could be a bit confusing that using a normal SRCREV doesn’t require any
extra effort but named SRCREVs require additional lines of metadata. As you can see in the
commit message of my patches, the vulkan-demos recipe in poky also has this issue so it might
be quite easy to forget.

Thanks for the feedback. If the patch idea isn’t good, let me know if you think I should instead
post a patch for the documentation to try to more explicitly note the need for the additional vardeps
statements when using named SRCREVs.

Thanks.

Kind regards,
Michael

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de<mailto:michael.ho@bmw-carit.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------


From: Martin Jansa <martin.jansa@gmail.com>
Date: Monday, 27 May 2019 at 5:44 pm
To: "Ho Michael, JC-3UL" <Michael.Ho@bmw.de>
Cc: Chris Larson <kergoth@gmail.com>, Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

In those recipes which don't include SRCPV in PV (for whatever reason) we usually add them explicitly with:
do_fetch[vardeps] += "SRCREV_common"
it's not ideal as people sometimes forget about this. Good practice is to add this next to the SRCREV_FORMAT (if you set one, to clearly show which revs are and aren't included).

On Mon, May 27, 2019 at 5:37 PM <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>> wrote:
Hi Christopher,

Thank you for the feedback. Since SRCPV is not always enforced (correct me if I’m wrong), it seems easy to trip over this bug when just following the documentation on multiple named source uri’s (also if you purposely don’t want to include the secondary source revisions in the package version). I’ll give it another shot to make it more efficient. If it’s not expected to be an encounterable bug case you can ignore the patch.

Thanks.

Kind regards,
Michael

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de<mailto:michael.ho@bmw-carit.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------


From: Christopher Larson <kergoth@gmail.com<mailto:kergoth@gmail.com>>
Date: Wednesday, 8 May 2019 at 5:17 pm
To: "Ho Michael, JC-3UL" <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>>
Cc: Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Subject: Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT controls how the multiple revs end up in PV, and the change to PV results in rebuilding anyway. And iterating over d.keys() is inefficient, *if* you’re going to do this, operate on SRCREV, gather up the name= parameters from scm urls, and use that to drive it.

On Wed, May 8, 2019 at 7:10 AM Michael Ho <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>> wrote:
Several fetchers support named sources that require setting a SRCREV with
the source name as a suffix. These named SRCREV variables are not captured
in the sstate hash calculation because they're only referenced within the
bitbake fetcher function.

Add a snippet to the base.bbclass anonymous python to add all named SRCREV
variables to the vardeps of do_fetch to capture them in the sstate hash
calculation.

Testing of the bug can be shown by running the following bitbake commands
with this patch set not applied:

bitbake vulkan-demos | tee
sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
  ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb<http://vulkan-demos_git.bb>
bitbake vulkan-demos | tee;

Results in no errors despite a broken SRCREV because the vulkan-demos is
considered unchanged.

After applying this patch the above commands instead result in a fetcher
error which is correct.
---
 meta/classes/base.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1636c6e..84a27f5 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -638,6 +638,16 @@ python () {

     if needsrcrev:
         d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
+        # Gather all SRCREV_* references to add to the sstate hash calculation
+        # This may capture SRCREVs not used but it's difficult to try to restrict it
+        # to only what is needed
+        for dkey in d.keys():
+            if dkey.startswith("SRCREV_"):
+                # This anonymous python snippet is called multiple times so we
+                # need to be careful to not double up the appends here and cause
+                # the base hash to mismatch the task hash
+                if dkey not in (d.getVarFlag("do_fetch", "vardeps") or '').split():
+                    d.appendVarFlag("do_fetch", "vardeps", " {}".format(dkey))

     set_packagetriplet(d)

--
2.7.4

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[-- Attachment #2: Type: text/html, Size: 17337 bytes --]

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] base.bbclass: add named SRCREVs to the sstate hash
  2019-05-27 16:34       ` Michael.Ho
@ 2019-05-27 16:56         ` Martin Jansa
  2019-05-28  9:31           ` Michael.Ho
  0 siblings, 1 reply; 8+ messages in thread
From: Martin Jansa @ 2019-05-27 16:56 UTC (permalink / raw)
  To: Michael.Ho; +Cc: Patches and discussions about the oe-core layer

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

Hi Michael,

sorry I wasn't clear in the reply, I meant that it's easy to work around
this issue, but it's error prone.

Your patch does it automatically and I don't see any cases where we
wouldn't want all the SRCREVs included in do_fetch signature, so I like
your patch.

+1 from me.

Cheers,

On Mon, May 27, 2019 at 6:34 PM <Michael.Ho@bmw.de> wrote:

> Hi Martin,
>
>
>
> It seems a little tricky though to need to know about the sstate hashing
> in order to use named
> source revisions and it could be a bit confusing that using a normal
> SRCREV doesn’t require any
> extra effort but named SRCREVs require additional lines of metadata. As
> you can see in the
> commit message of my patches, the vulkan-demos recipe in poky also has
> this issue so it might
> be quite easy to forget.
>
>
>
> Thanks for the feedback. If the patch idea isn’t good, let me know if you
> think I should instead
> post a patch for the documentation to try to more explicitly note the need
> for the additional vardeps
> statements when using named SRCREVs.
>
>
>
> Thanks.
>
>
>
> Kind regards,
>
> Michael
>
>
>
> --
>
> *BMW Car IT GmbH*
> Michael Ho
> Spezialist Entwicklung – Build and Release Engineering
> Lise-Meitner-Straße 14
> 89081 Ulm
>
> Tel.: ­+49-731-37804-071
>
> Mobil: +49-152-54980-471
> Fax: +49-731-37804-001
> Mail: michael.ho@bmw-carit.de
> Web: http://www.bmw-carit.de
> -------------------------------------------------------------------------
> BMW Car IT GmbH
> Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
> Sitz und Registergericht: München HRB 134810
> -------------------------------------------------------------------------
>
>
>
>
>
> *From: *Martin Jansa <martin.jansa@gmail.com>
> *Date: *Monday, 27 May 2019 at 5:44 pm
> *To: *"Ho Michael, JC-3UL" <Michael.Ho@bmw.de>
> *Cc: *Chris Larson <kergoth@gmail.com>, Patches and discussions about the
> oe-core layer <openembedded-core@lists.openembedded.org>
> *Subject: *Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the
> sstate hash
>
>
>
> In those recipes which don't include SRCPV in PV (for whatever reason) we
> usually add them explicitly with:
>
> do_fetch[vardeps] += "SRCREV_common"
>
> it's not ideal as people sometimes forget about this. Good practice is to
> add this next to the SRCREV_FORMAT (if you set one, to clearly show which
> revs are and aren't included).
>
>
>
> On Mon, May 27, 2019 at 5:37 PM <Michael.Ho@bmw.de> wrote:
>
> Hi Christopher,
>
>
>
> Thank you for the feedback. Since SRCPV is not always enforced (correct me
> if I’m wrong), it seems easy to trip over this bug when just following the
> documentation on multiple named source uri’s (also if you purposely don’t
> want to include the secondary source revisions in the package version).
> I’ll give it another shot to make it more efficient. If it’s not expected
> to be an encounterable bug case you can ignore the patch.
>
>
>
> Thanks.
>
>
>
> Kind regards,
>
> Michael
>
>
>
> --
>
> *BMW Car IT GmbH*
> Michael Ho
> Spezialist Entwicklung – Build and Release Engineering
> Lise-Meitner-Straße 14
> 89081 Ulm
>
> Tel.: ­+49-731-37804-071
>
> Mobil: +49-152-54980-471
> Fax: +49-731-37804-001
> Mail: michael.ho@bmw-carit.de
> Web: http://www.bmw-carit.de
> -------------------------------------------------------------------------
> BMW Car IT GmbH
> Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
> Sitz und Registergericht: München HRB 134810
> -------------------------------------------------------------------------
>
>
>
>
>
> *From: *Christopher Larson <kergoth@gmail.com>
> *Date: *Wednesday, 8 May 2019 at 5:17 pm
> *To: *"Ho Michael, JC-3UL" <Michael.Ho@bmw.de>
> *Cc: *Patches and discussions about the oe-core layer <
> openembedded-core@lists.openembedded.org>
> *Subject: *Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the
> sstate hash
>
>
>
> Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT
> controls how the multiple revs end up in PV, and the change to PV results
> in rebuilding anyway. And iterating over d.keys() is inefficient, *if*
> you’re going to do this, operate on SRCREV, gather up the name= parameters
> from scm urls, and use that to drive it.
>
>
>
> On Wed, May 8, 2019 at 7:10 AM Michael Ho <Michael.Ho@bmw.de> wrote:
>
> Several fetchers support named sources that require setting a SRCREV with
> the source name as a suffix. These named SRCREV variables are not captured
> in the sstate hash calculation because they're only referenced within the
> bitbake fetcher function.
>
> Add a snippet to the base.bbclass anonymous python to add all named SRCREV
> variables to the vardeps of do_fetch to capture them in the sstate hash
> calculation.
>
> Testing of the bug can be shown by running the following bitbake commands
> with this patch set not applied:
>
> bitbake vulkan-demos | tee
> sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
>   ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb
> bitbake vulkan-demos | tee;
>
> Results in no errors despite a broken SRCREV because the vulkan-demos is
> considered unchanged.
>
> After applying this patch the above commands instead result in a fetcher
> error which is correct.
> ---
>  meta/classes/base.bbclass | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 1636c6e..84a27f5 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -638,6 +638,16 @@ python () {
>
>      if needsrcrev:
>          d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
> +        # Gather all SRCREV_* references to add to the sstate hash
> calculation
> +        # This may capture SRCREVs not used but it's difficult to try to
> restrict it
> +        # to only what is needed
> +        for dkey in d.keys():
> +            if dkey.startswith("SRCREV_"):
> +                # This anonymous python snippet is called multiple times
> so we
> +                # need to be careful to not double up the appends here
> and cause
> +                # the base hash to mismatch the task hash
> +                if dkey not in (d.getVarFlag("do_fetch", "vardeps") or
> '').split():
> +                    d.appendVarFlag("do_fetch", "vardeps", "
> {}".format(dkey))
>
>      set_packagetriplet(d)
>
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
> --
>
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Senior Software Engineer, Mentor Graphics
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

[-- Attachment #2: Type: text/html, Size: 15164 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] base.bbclass: add named SRCREVs to the sstate hash
  2019-05-27 16:56         ` Martin Jansa
@ 2019-05-28  9:31           ` Michael.Ho
  0 siblings, 0 replies; 8+ messages in thread
From: Michael.Ho @ 2019-05-28  9:31 UTC (permalink / raw)
  To: martin.jansa; +Cc: openembedded-core

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

Hi Martin,

Ah okay, sorry, I misread and thought you meant it was a known issue and it is expected to set vardeps manually.

Thanks for the +1.

Kind regards,
Michael Ho

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de<mailto:michael.ho@bmw-carit.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------


From: Martin Jansa <martin.jansa@gmail.com>
Date: Monday, 27 May 2019 at 6:56 pm
To: "Ho Michael, JC-3UL" <Michael.Ho@bmw.de>
Cc: Chris Larson <kergoth@gmail.com>, Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

Hi Michael,

sorry I wasn't clear in the reply, I meant that it's easy to work around this issue, but it's error prone.

Your patch does it automatically and I don't see any cases where we wouldn't want all the SRCREVs included in do_fetch signature, so I like your patch.

+1 from me.

Cheers,

On Mon, May 27, 2019 at 6:34 PM <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>> wrote:
Hi Martin,

It seems a little tricky though to need to know about the sstate hashing in order to use named
source revisions and it could be a bit confusing that using a normal SRCREV doesn’t require any
extra effort but named SRCREVs require additional lines of metadata. As you can see in the
commit message of my patches, the vulkan-demos recipe in poky also has this issue so it might
be quite easy to forget.

Thanks for the feedback. If the patch idea isn’t good, let me know if you think I should instead
post a patch for the documentation to try to more explicitly note the need for the additional vardeps
statements when using named SRCREVs.

Thanks.

Kind regards,
Michael

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de<mailto:michael.ho@bmw-carit.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------


From: Martin Jansa <martin.jansa@gmail.com<mailto:martin.jansa@gmail.com>>
Date: Monday, 27 May 2019 at 5:44 pm
To: "Ho Michael, JC-3UL" <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>>
Cc: Chris Larson <kergoth@gmail.com<mailto:kergoth@gmail.com>>, Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Subject: Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

In those recipes which don't include SRCPV in PV (for whatever reason) we usually add them explicitly with:
do_fetch[vardeps] += "SRCREV_common"
it's not ideal as people sometimes forget about this. Good practice is to add this next to the SRCREV_FORMAT (if you set one, to clearly show which revs are and aren't included).

On Mon, May 27, 2019 at 5:37 PM <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>> wrote:
Hi Christopher,

Thank you for the feedback. Since SRCPV is not always enforced (correct me if I’m wrong), it seems easy to trip over this bug when just following the documentation on multiple named source uri’s (also if you purposely don’t want to include the secondary source revisions in the package version). I’ll give it another shot to make it more efficient. If it’s not expected to be an encounterable bug case you can ignore the patch.

Thanks.

Kind regards,
Michael

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de<mailto:michael.ho@bmw-carit.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------


From: Christopher Larson <kergoth@gmail.com<mailto:kergoth@gmail.com>>
Date: Wednesday, 8 May 2019 at 5:17 pm
To: "Ho Michael, JC-3UL" <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>>
Cc: Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Subject: Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT controls how the multiple revs end up in PV, and the change to PV results in rebuilding anyway. And iterating over d.keys() is inefficient, *if* you’re going to do this, operate on SRCREV, gather up the name= parameters from scm urls, and use that to drive it.

On Wed, May 8, 2019 at 7:10 AM Michael Ho <Michael.Ho@bmw.de<mailto:Michael.Ho@bmw.de>> wrote:
Several fetchers support named sources that require setting a SRCREV with
the source name as a suffix. These named SRCREV variables are not captured
in the sstate hash calculation because they're only referenced within the
bitbake fetcher function.

Add a snippet to the base.bbclass anonymous python to add all named SRCREV
variables to the vardeps of do_fetch to capture them in the sstate hash
calculation.

Testing of the bug can be shown by running the following bitbake commands
with this patch set not applied:

bitbake vulkan-demos | tee
sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
  ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb<http://vulkan-demos_git.bb>
bitbake vulkan-demos | tee;

Results in no errors despite a broken SRCREV because the vulkan-demos is
considered unchanged.

After applying this patch the above commands instead result in a fetcher
error which is correct.
---
 meta/classes/base.bbclass | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1636c6e..84a27f5 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -638,6 +638,16 @@ python () {

     if needsrcrev:
         d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
+        # Gather all SRCREV_* references to add to the sstate hash calculation
+        # This may capture SRCREVs not used but it's difficult to try to restrict it
+        # to only what is needed
+        for dkey in d.keys():
+            if dkey.startswith("SRCREV_"):
+                # This anonymous python snippet is called multiple times so we
+                # need to be careful to not double up the appends here and cause
+                # the base hash to mismatch the task hash
+                if dkey not in (d.getVarFlag("do_fetch", "vardeps") or '').split():
+                    d.appendVarFlag("do_fetch", "vardeps", " {}".format(dkey))

     set_packagetriplet(d)

--
2.7.4

--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[-- Attachment #2: Type: text/html, Size: 24009 bytes --]

^ permalink raw reply related	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-05-28  9:31 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-08 14:02 [PATCH] base.bbclass: add named SRCREVs to the sstate hash Michael Ho
2019-05-08 15:16 ` Christopher Larson
2019-05-27 15:37   ` Michael.Ho
2019-05-27 15:44     ` Martin Jansa
2019-05-27 16:34       ` Michael.Ho
2019-05-27 16:56         ` Martin Jansa
2019-05-28  9:31           ` Michael.Ho
2019-05-27 15:42 ` [PATCH v2] " Michael Ho

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.