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

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

[Adriana Kobylak]

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.
Also at IBM we were looking for a field that could display the date of a build, such as the release or general availability date.

Looking at the BUILD_ID description[1]:

BUILD_ID=
A string uniquely identifying the system image originally used as the installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an update. BUILD_ID may be used in distributions where the original installation image version is important: VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional.
Examples: "BUILD_ID="2013-03-20.3"", "BUILD_ID=201303203".

The yocto recipe for os-release sets BUILD_ID to DATETIME by default[2].

At the beginning of time, the BUILD_ID in openbmc was set to have the contents of git describe[3]. Its contents now are the same as VERSION so we have duplicate information:
VERSION="2.11.0-dev"
VERSION_ID=2.11.0-dev-566-g263df7f852
PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 2.11.0-dev"
BUILD_ID="2.11.0-dev"

If we let the default DATETIME value be built, it'd show in this format:
BUILD_ID="20211007135305"

To re-generate the same image, BUILD_ID can be determined from the image file names, such as:
obmc-phosphor-image-p10bmc-20211007135305.ext4.mmc.tar

Then BUILD_ID can be set in the conf file, and the image for that timestamp can be built.

Also individual meta layers can choose to set BUILD_ID to any date that they seem relevant for their releases.

Any opinions on changing BUILD_ID to its yocto default of being a timestamp?


1. https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID=
2. https://github.com/openbmc/openbmc/blob/3fc98fdca6aa7512a4656bec7422f557c8e17555/poky/meta/recipes-core/os-release/os-release.bb#L23
3. https://github.com/openbmc/openbmc/pull/78

Re: Changing the os-release BUILD_ID back to its default value of DATETIME

[Ed Tanous]

On Mon, Oct 11, 2021 at 3:00 PM Adriana Kobylak <anoo@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.
> Also at IBM we were looking for a field that could display the date of a build, such as the release or general availability date.
>
> Looking at the BUILD_ID description[1]:
>
> BUILD_ID=
> A string uniquely identifying the system image originally used as the installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an update. BUILD_ID may be used in distributions where the original installation image version is important: VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional.
> Examples: "BUILD_ID="2013-03-20.3"", "BUILD_ID=201303203".
>
> The yocto recipe for os-release sets BUILD_ID to DATETIME by default[2].
>
> At the beginning of time, the BUILD_ID in openbmc was set to have the contents of git describe[3]. Its contents now are the same as VERSION so we have duplicate information:
> VERSION="2.11.0-dev"
> VERSION_ID=2.11.0-dev-566-g263df7f852
> PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 2.11.0-dev"
> BUILD_ID="2.11.0-dev"
>
> If we let the default DATETIME value be built, it'd show in this format:
> BUILD_ID="20211007135305"
>
> To re-generate the same image, BUILD_ID can be determined from the image file names, such as:
> obmc-phosphor-image-p10bmc-20211007135305.ext4.mmc.tar
>
> Then BUILD_ID can be set in the conf file, and the image for that timestamp can be built.
>
> Also individual meta layers can choose to set BUILD_ID to any date that they seem relevant for their releases.
>
> Any opinions on changing BUILD_ID to its yocto default of being a timestamp?

+1

>
>
> 1. https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID=
> 2. https://github.com/openbmc/openbmc/blob/3fc98fdca6aa7512a4656bec7422f557c8e17555/poky/meta/recipes-core/os-release/os-release.bb#L23
> 3. https://github.com/openbmc/openbmc/pull/78

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

[Lei Yu]

On Tue, Oct 12, 2021 at 6:00 AM Adriana Kobylak <anoo@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.

-- 
BRs,
Lei YU

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

[William Kennington]

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.

On Mon, Oct 11, 2021 at 10:34 PM Lei Yu <yulei.sh@bytedance.com> wrote:
>
> On Tue, Oct 12, 2021 at 6:00 AM Adriana Kobylak <anoo@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.
>
> --
> BRs,
> Lei YU

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

[Adriana Kobylak]

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

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@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@bytedance.com> wrote:
>> 
>> On Tue, Oct 12, 2021 at 6:00 AM Adriana Kobylak <anoo@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


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

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

[Patrick Williams]

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

On Mon, Oct 25, 2021 at 03:17:06PM -0500, Adriana Kobylak wrote:
> 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@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.

I don't actually have very strong opinions on this and didn't realize right away
that this meant we _weren't_ making a change.  I avoided weighing in before to
just be another "+1".

Shouldn't we attempt to match what upstream Yocto does?  Doesn't doing (mostly)
nothing cause us to not fix the usability issue that keeps getting raised about
the code-update flow not accepting a simple rebuild?

I don't believe that you can currently make a 100% reproducible build as it is,
so I don't see this as a hard requirement to deviate from Yocto and if someone
does want to avoid a changing BUILD_ID we already give them the tools for it.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]