* Changing the os-release BUILD_ID back to its default value of DATETIME
@ 2021-10-11 21:59 Adriana Kobylak
2021-10-11 23:54 ` Ed Tanous
2021-10-12 5:33 ` [External] " Lei Yu
0 siblings, 2 replies; 6+ messages in thread
From: Adriana Kobylak @ 2021-10-11 21:59 UTC (permalink / raw)
To: OpenBMC Maillist
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Changing the os-release BUILD_ID back to its default value of DATETIME
2021-10-11 21:59 Changing the os-release BUILD_ID back to its default value of DATETIME Adriana Kobylak
@ 2021-10-11 23:54 ` Ed Tanous
2021-10-12 5:33 ` [External] " Lei Yu
1 sibling, 0 replies; 6+ messages in thread
From: Ed Tanous @ 2021-10-11 23:54 UTC (permalink / raw)
To: Adriana Kobylak; +Cc: OpenBMC Maillist
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [External] Changing the os-release BUILD_ID back to its default value of DATETIME
2021-10-11 21:59 Changing the os-release BUILD_ID back to its default value of DATETIME Adriana Kobylak
2021-10-11 23:54 ` Ed Tanous
@ 2021-10-12 5:33 ` Lei Yu
2021-10-12 9:45 ` William Kennington
1 sibling, 1 reply; 6+ messages in thread
From: Lei Yu @ 2021-10-12 5:33 UTC (permalink / raw)
To: Adriana Kobylak; +Cc: OpenBMC Maillist
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [External] Changing the os-release BUILD_ID back to its default value of DATETIME
2021-10-12 5:33 ` [External] " Lei Yu
@ 2021-10-12 9:45 ` William Kennington
2021-10-25 20:17 ` Adriana Kobylak
0 siblings, 1 reply; 6+ messages in thread
From: William Kennington @ 2021-10-12 9:45 UTC (permalink / raw)
To: Lei Yu; +Cc: OpenBMC Maillist
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [External] Changing the os-release BUILD_ID back to its default value of DATETIME
2021-10-12 9:45 ` William Kennington
@ 2021-10-25 20:17 ` Adriana Kobylak
2021-10-27 21:50 ` Patrick Williams
0 siblings, 1 reply; 6+ messages in thread
From: Adriana Kobylak @ 2021-10-25 20:17 UTC (permalink / raw)
To: William Kennington, edtanous, 郁雷; +Cc: OpenBMC Maillist
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [External] Changing the os-release BUILD_ID back to its default value of DATETIME
2021-10-25 20:17 ` Adriana Kobylak
@ 2021-10-27 21:50 ` Patrick Williams
0 siblings, 0 replies; 6+ messages in thread
From: Patrick Williams @ 2021-10-27 21:50 UTC (permalink / raw)
To: Adriana Kobylak
Cc: edtanous, 郁雷, OpenBMC Maillist, William Kennington
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-27 21:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-11 21:59 Changing the os-release BUILD_ID back to its default value of DATETIME Adriana Kobylak
2021-10-11 23:54 ` Ed Tanous
2021-10-12 5:33 ` [External] " Lei Yu
2021-10-12 9:45 ` William Kennington
2021-10-25 20:17 ` Adriana Kobylak
2021-10-27 21:50 ` Patrick Williams
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).