<div dir="ltr">In those recipes which don&#39;t include SRCPV in PV (for whatever reason) we usually add them explicitly with:<div>do_fetch[vardeps] += &quot;SRCREV_common&quot;<br></div><div>it&#39;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&#39;t included).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 27, 2019 at 5:37 PM &lt;<a href="mailto:Michael.Ho@bmw.de">Michael.Ho@bmw.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-AU">
<div class="gmail-m_7714810984505935552WordSection1">
<p class="MsoNormal">Hi Christopher,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Kind regards,<u></u><u></u></p>
<p class="MsoNormal">Michael<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal"><b><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)">BMW Car IT GmbH</span></b><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)"><br>
<span style="background:white">Michael Ho</span><br>
Spezialist Entwicklung – Build and Release Engineering<br>
<span style="background:white">Lise-Meitner-Straße 14</span><br>
<span style="background:white">89081 Ulm</span><br>
<br>
<span style="background:white">Tel.: ­+49-731-37804-071<u></u><u></u></span></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51);background:white">Mobil: +49-152-54980-471</span><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)"><br>
<span style="background:white">Fax: +49-731-37804-001</span><br>
<span style="background:white">Mail: </span></span><span style="font-size:10.5pt;font-family:Arial,sans-serif"><a href="mailto:michael.ho@bmw-carit.de" target="_blank"><span style="color:rgb(5,99,193)">michael.ho@bmw-carit.de</span></a><span style="color:rgb(51,51,51);background:white"> </span><span style="color:rgb(51,51,51)"><br>
<span style="background:white">Web: </span></span></span><a href="http://www.bmw-carit.de/" target="_blank"><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(50,108,166)">http://www.bmw-carit.de</span></a><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)"><br>
<span style="background:white">-------------------------------------------------------------------------</span><br>
<span style="background:white">BMW Car IT GmbH</span><br>
<span style="background:white">Geschäftsführer: Kai-Uwe Balszuweit und</span></span><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(153,153,153)"> </span><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51);background:white">Christian
 Salzmann</span><span style="font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,51,51)"><br>
<span style="background:white">Sitz und Registergericht: München HRB 134810</span><br>
<span style="background:white">-------------------------------------------------------------------------</span></span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">Christopher Larson &lt;<a href="mailto:kergoth@gmail.com" target="_blank">kergoth@gmail.com</a>&gt;<br>
<b>Date: </b>Wednesday, 8 May 2019 at 5:17 pm<br>
<b>To: </b>&quot;Ho Michael, JC-3UL&quot; &lt;<a href="mailto:Michael.Ho@bmw.de" target="_blank">Michael.Ho@bmw.de</a>&gt;<br>
<b>Cc: </b>Patches and discussions about the oe-core layer &lt;<a href="mailto:openembedded-core@lists.openembedded.org" target="_blank">openembedded-core@lists.openembedded.org</a>&gt;<br>
<b>Subject: </b>Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, May 8, 2019 at 7:10 AM Michael Ho &lt;<a href="mailto:Michael.Ho@bmw.de" target="_blank">Michael.Ho@bmw.de</a>&gt; wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Several fetchers support named sources that require setting a SRCREV with<br>
the source name as a suffix. These named SRCREV variables are not captured<br>
in the sstate hash calculation because they&#39;re only referenced within the<br>
bitbake fetcher function.<br>
<br>
Add a snippet to the base.bbclass anonymous python to add all named SRCREV<br>
variables to the vardeps of do_fetch to capture them in the sstate hash<br>
calculation.<br>
<br>
Testing of the bug can be shown by running the following bitbake commands<br>
with this patch set not applied:<br>
<br>
bitbake vulkan-demos | tee<br>
sed -i &#39;s/SRCREV_gli = &quot;.*&quot;/SRCREV_gli = &quot;xxx&quot;/&#39; \<br>
  ../meta/recipes-graphics/vulkan/<a href="http://vulkan-demos_git.bb" target="_blank">vulkan-demos_git.bb</a><br>
bitbake vulkan-demos | tee;<br>
<br>
Results in no errors despite a broken SRCREV because the vulkan-demos is<br>
considered unchanged.<br>
<br>
After applying this patch the above commands instead result in a fetcher<br>
error which is correct.<br>
---<br>
 meta/classes/base.bbclass | 10 ++++++++++<br>
 1 file changed, 10 insertions(+)<br>
<br>
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass<br>
index 1636c6e..84a27f5 100644<br>
--- a/meta/classes/base.bbclass<br>
+++ b/meta/classes/base.bbclass<br>
@@ -638,6 +638,16 @@ python () {<br>
<br>
     if needsrcrev:<br>
         d.setVar(&quot;SRCPV&quot;, &quot;${@bb.fetch2.get_srcrev(d)}&quot;)<br>
+        # Gather all SRCREV_* references to add to the sstate hash calculation<br>
+        # This may capture SRCREVs not used but it&#39;s difficult to try to restrict it<br>
+        # to only what is needed<br>
+        for dkey in d.keys():<br>
+            if dkey.startswith(&quot;SRCREV_&quot;):<br>
+                # This anonymous python snippet is called multiple times so we<br>
+                # need to be careful to not double up the appends here and cause<br>
+                # the base hash to mismatch the task hash<br>
+                if dkey not in (d.getVarFlag(&quot;do_fetch&quot;, &quot;vardeps&quot;) or &#39;&#39;).split():<br>
+                    d.appendVarFlag(&quot;do_fetch&quot;, &quot;vardeps&quot;, &quot; {}&quot;.format(dkey))<br>
<br>
     set_packagetriplet(d)<br>
<br>
-- <br>
2.7.4<br>
<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Christopher Larson<br>
kergoth at gmail dot com<br>
Founder - BitBake, OpenEmbedded, OpenZaurus<br>
Senior Software Engineer, Mentor Graphics<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>

-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>