Re: Overriding SDE_FILE

[Joshua Watt <jpewhacker@gmail.com>]

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


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.



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