<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 28/02/20 11:34 am, Joshua Watt wrote:
<blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 2/27/20 4:29 PM, Douglas Royds
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:47d8bb87-b3be-1789-c1cb-124b446462d8@taitradio.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>On 28/02/20 10:49 am, Joshua Watt wrote: </p>
<blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 2/27/20 3:22 PM, Douglas
Royds wrote:<br>
</div>
<blockquote type="cite"
cite="mid:baae3c8f-219f-03eb-6f6c-a488ae22230b@taitradio.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>On 28/02/20 5:45 am, Joshua Watt wrote: </p>
<blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">On 2/27/20 9:01 AM, Joshua
Watt wrote:<br>
</div>
<blockquote type="cite"
cite="mid:cce62b8e-b135-6daa-0c47-3e91955d248c@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">On 2/26/20 11:46 PM,
Douglas Royds wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0319e121-7546-e456-50d6-4b224e87363f@taitradio.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>On 26/02/20 4:53 am, Jacob Kroon wrote: </p>
<blockquote type="cite">On 2/24/20 8:25 AM, Jacob
Kroon wrote: <br>
<blockquote type="cite">Hi Douglas, <br>
<br>
You updated a comment in
reproducible_build.bbclass, commit
e7b891b76954c784f5a93bd0a1c91315673ce40d: <br>
<br>
<blockquote type="cite">-# Once the value of
SOURCE_DATE_EPOCH is determined, it is stored
in the recipe's ${SDE_FILE}. <br>
+# Once the value of SOURCE_DATE_EPOCH is
determined, it is stored in the recipe's
SDE_FILE. <br>
+# If none of these mechanisms are suitable,
replace the do_deploy_source_date_epoch task <br>
+# with recipe-specific functionality to write
the appropriate SOURCE_DATE_EPOCH into the
SDE_FILE. <br>
+# <br>
</blockquote>
<br>
But I can't really get this to work. What did
work for me was to replace
"do_create_source_date_epoch_stamp()" in my
recipe: <br>
<br>
do_create_source_date_epoch_stamp() { <br>
mkdir -p ${SDE_DIR} <br>
date -d "1981-03-03" "+%s" > ${SDE_FILE}
<br>
} <br>
<br>
What is the intended way to achieve the thing
I'm trying to do here ? <br>
<br>
</blockquote>
<br>
FYI, JPEW has a proposed patch here <br>
<br>
<a class="moz-txt-link-freetext"
href="http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=d091d2aa53ea417f70c10f5ce89151820c3db9ce"
moz-do-not-send="true">http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=d091d2aa53ea417f70c10f5ce89151820c3db9ce</a>
<br>
<br>
for allowing a recipe to just set
SOURCE_DATE_EPOCH directly. <br>
<br>
But maybe that currently is at odds with
SOURCE_DATE_EPOCH being in BB_HASHBASE_WHITELIST ?
<br>
<br>
/Jacob <br>
</blockquote>
<p><br>
</p>
<p>On the surface of it, my comment appears to be
just wrong: It does make sense to replace
do_create_source_date_epoch_stamp() as you
suggest.</p>
<p>Joshua's proposed patch looks promising:</p>
<ul>
<li>Should the new function not be called first,
so that it takes priority over the git, known
files, and youngest file functions? If someone
has explicitly set SOURCE_DATE_EPOCH, then they
want it to take priority.<br>
</li>
</ul>
</blockquote>
<p>Having that be the first option makes sense. The
only case in which that might not work, is if a
recipe does something like:</p>
<p> SOURCE_DATE_EPOCH =
"${@my_awesome_sde_calculation(d)}"</p>
<p>e.g. uses a function to get the SDE instead of
setting to a fixed value, but that's probably going
to be extremely rare.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:0319e121-7546-e456-50d6-4b224e87363f@taitradio.com">
<ul>
<li> <br>
</li>
<li>As you observe, SOURCE_DATE_EPOCH would need
to be removed from BB_HASHBASE_WHITELIST. I'm
not sure why it was in the whitelist in the
first place.<br>
</li>
</ul>
</blockquote>
<p>I'm not sure why exactly it is whitelisted; I
didn't write the original code that whitelisted it,
but I've CC'd Juro in case he happens to remember.<br>
</p>
</blockquote>
<p>After a discussion with Richard, we figured out why
SOURCE_DATE_EPOCH has to be whitelisted. The value of
the variable *must* be calculable at parse time before
any task is ran, but in practice it's value is only
available once the __source_date_epoch.txt file is
present, which is after parsing. This causes the
taskhash to be calculated differently during parsing
and task execution which causes taskhash mismatch
errors.</p>
</blockquote>
<p><br>
</p>
<p>True.</p>
<p>What to do? Would it work to use a different
non-whitelisted variable in the recipe, eg.
SOURCE_DATE_EPOCH_FIXED?<br>
</p>
</blockquote>
<p><br>
</p>
<p>Ya, that would work. You'd have to figure out how to get
the variable to be included in each taskhash even though
it's not directly referenced, but I'm sure that's
possible.</p>
<p><br>
</p>
<p>Another option that's at lot more "magic" would be
something like this: <a class="moz-txt-link-freetext"
href="http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=2b524916cf35238ff3deea34017e8a4cd73926cd"
moz-do-not-send="true">http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=2b524916cf35238ff3deea34017e8a4cd73926cd</a>
<br>
</p>
<p>That's really weird, and I'm not sure I like it, but
worth a thought.<br>
</p>
</blockquote>
<p>If it works, it's good. I like the fact that the user can
just set SOURCE_DATE_EPOCH directly in their recipe.<br>
</p>
<p>How about ...</p>
<blockquote>
<p>BB_HASHBASE_WHITELIST += "${@'SOURCE_DATE_EPOCH' if not
source_date_epoch_var(d) else ''}"</p>
</blockquote>
</blockquote>
<p>Ya, that works. The only reason I chose "is None" was in case
a user really wanted to do <br>
</p>
<p> SOURCE_DATE_EPOCH = "0"<br>
</p>
</blockquote>
True, best to allow for that.<br>
</p>
</body>
</html>