[OE-core] Overriding SDE_FILE
Douglas Royds
douglas.royds at taitradio.com
Thu Feb 27 21:22:51 UTC 2020
On 28/02/20 5:45 am, Joshua Watt wrote:
> On 2/27/20 9:01 AM, Joshua Watt wrote:
>> On 2/26/20 11:46 PM, Douglas Royds wrote:
>>>
>>> On 26/02/20 4:53 am, Jacob Kroon wrote:
>>>
>>>> On 2/24/20 8:25 AM, Jacob Kroon wrote:
>>>>> Hi Douglas,
>>>>>
>>>>> You updated a comment in reproducible_build.bbclass, commit
>>>>> e7b891b76954c784f5a93bd0a1c91315673ce40d:
>>>>>
>>>>>> -# Once the value of SOURCE_DATE_EPOCH is determined, it is
>>>>>> stored in the recipe's ${SDE_FILE}.
>>>>>> +# Once the value of SOURCE_DATE_EPOCH is determined, it is
>>>>>> stored in the recipe's SDE_FILE.
>>>>>> +# If none of these mechanisms are suitable, replace the
>>>>>> do_deploy_source_date_epoch task
>>>>>> +# with recipe-specific functionality to write the appropriate
>>>>>> SOURCE_DATE_EPOCH into the SDE_FILE.
>>>>>> +#
>>>>>
>>>>> 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:
>>>>>
>>>>> do_create_source_date_epoch_stamp() {
>>>>> mkdir -p ${SDE_DIR}
>>>>> date -d "1981-03-03" "+%s" > ${SDE_FILE}
>>>>> }
>>>>>
>>>>> What is the intended way to achieve the thing I'm trying to do here ?
>>>>>
>>>>
>>>> FYI, JPEW has a proposed patch here
>>>>
>>>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=d091d2aa53ea417f70c10f5ce89151820c3db9ce
>>>>
>>>>
>>>> for allowing a recipe to just set SOURCE_DATE_EPOCH directly.
>>>>
>>>> But maybe that currently is at odds with SOURCE_DATE_EPOCH being in
>>>> BB_HASHBASE_WHITELIST ?
>>>>
>>>> /Jacob
>>>
>>>
>>> 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.
>>>
>>> Joshua's proposed patch looks promising:
>>>
>>> * 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.
>>>
>> Having that be the first option makes sense. The only case in which
>> that might not work, is if a recipe does something like:
>>
>> SOURCE_DATE_EPOCH = "${@my_awesome_sde_calculation(d)}"
>>
>> 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.
>>
>>
>>> *
>>>
>>>
>>>
>>> * 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.
>>>
>> 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.
>>
> 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.
>
True.
What to do? Would it work to use a different non-whitelisted variable in
the recipe, eg. SOURCE_DATE_EPOCH_FIXED?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200228/2db9bc05/attachment.html>
More information about the Openembedded-core
mailing list