[External] Changing the os-release BUILD_ID back to its default value of DATETIME

Adriana Kobylak anoo at linux.ibm.com
Tue Oct 26 07:17:06 AEDT 2021


Thanks everybody. Changes up for review:

https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48204 <https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48204>
https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48205 <https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48205>


> On Oct 12, 2021, at 4:45 AM, William Kennington <wak at google.com> wrote:
> 
> Personally I would rather have deterministic builds and don't like
> arbitrary build timestamp injection into images. But we can announce
> the plan to change this behavior and adjust build processes
> accordingly.

Sounds like a plan. To keep the current behavior, I tested that adding a os-release.bbappend with BUILD_ID set to the current git command would build the image with the value as it is today.

> 
> On Mon, Oct 11, 2021 at 10:34 PM Lei Yu <yulei.sh at bytedance.com> wrote:
>> 
>> On Tue, Oct 12, 2021 at 6:00 AM Adriana Kobylak <anoo at linux.ibm.com> wrote:
>>> 
>>> Hi,
>>> 
>>> There has been some discussion in Discord on how to work around the "Same version" limitation during fw updates, and having a timestamp field that could be used to generate a different version id (commit id plus timestamp field) for every build seemed had positive support in the discussion.
>> 
>> So the hash will be calculated as the `VERSION_ID` and `BUILD_ID` (as
>> timestamp), is it?
>> +1 for this proposal.

Right, we’ll add BUILD_ID to the hash calculation.

>> 
>> --
>> BRs,
>> Lei YU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20211025/f8a76809/attachment.htm>


More information about the openbmc mailing list