| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In the community it was discussed having a field that would contain the
date of when an image was built (timestamp) so that it could be used to
generate a unique version id during firmware updates, and that could
also be used to display the specific date of a build such as when it was
released or the general availability date.
The yocto recipe for os-release sets BUILD_ID to DATETIME by default.
The current implementation of BUILD_ID duplicates the output of VERSION,
therefore remove the openbmc implementation of BUILD_ID to pick up the
default value of DATETIME.
The value can be overwritten in a machine's conf file, or set to what it
was before in an os-release.bbappend in a meta layer.
Tested:
- The os-release BUILD_ID has a timestamp value by default, ex:
BUILD_ID="20211025151654".
- The os-release BUILD_ID is set to the value specified in a machine conf
file, ex:
Ex: In: meta-ibm/conf/machine/p10bmc.conf
BUILD_ID = "20211231120000"
- The os-release BUILD_ID is set to the value specified in a meta-layer
os-release bbappend:
Ex: In: meta-ibm/recipes-core/os-release/os-release.bbappend
BUILD_ID = "${@run_git(d, 'describe --abbrev=0')}"
Change-Id: If5238c53e0c3463c181788afc713c560fb5fe034
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|
|
The `run_git` in phosphor's os-release.bbappend assumes that the
git repository is in `${COREBASE}`, which is the location of the
`meta/` subdirectory. This is true when building exclusively the
`openbmc` tree but may not be the case when external users attempt
to use the `openbmc` tree as a git-submodule. Create an indirection
(`OS_RELEASE_ROOTPATH`) which defaults to `COREBASE`, but allows
an override for those other use-cases.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I4e0171e065379c5030a36ea5be774b5db78bfe34
|
|
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I588025b614416c43aa2d053765ab53bacf890cb5
|
|
It was reported that the following sequence would not cause
`os-release` to rebuild:
```
bitbake os-release
git commit --amend
bitbake os-release
```
This is due to how bitbake task hashing is implemented with respect
to weak variables. In 439c59b, DISTRO_VERSION was changed to a
weak variable, but it is included in the 'vardeps' chain for
'do_compile'. When bitbake computes the hash for a task, typically
the contents of the variables are used for the hashing, but for weak
variables only the definition is used. (Confirmed by adding bb.note
debugs to `poky/bitbake/lib/bb/data.py`)
The new, weak DISTRO_VERSION is intended to be populated with contents
from a `git describe` operation. Those contents must be used in the
hashing of the 'do_compile' task and not the definition. This can be
accomplished by creating an indirection using a strong variable.
The dependency chain and hash evaluation will be as follows:
```
do_compile -> DISTRO_VERSION -> PHOSPHOR_OS_RELEASE_DISTRO_VERSION
hash(do_compile) = ... +
DISTRO_VERSION:${PHOSPHOR_OS_RELEASE_DISTRO_VERSION} +
PHOSPHOR_...DISTRO_VERSION=2.11.0-dev-...
```
Prior to this fix the hash evaluation was:
```
hash(do_compile) = ... +
DISTRO_VERSION:${@run_git...}
```
Fixes 439c59b425cf403355571875b3fa714782dcf15b.
Tested: Ensure the above reported sequence causes a rebuild of
os-release with expected data.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I0bd93d3d88bf62dfe03549419fe98ab85f10a68c
|
|
Improved practice to use DISTRO_VERSION instead of the undocumented
VERSION_ID.
DISTRO_VERSION is documented in yocto
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html
and specified in this section about creating your own distribution.
https://docs.yoctoproject.org/dev-manual/common-tasks.html#creating-your-own-distribution
VERSION_ID is undocumented and will more likely be changed compared
to the documented DISTRO_VERSION.
The VERSION_ID is set to DISTRO_VERSION in poky/.../os-release.bb
Use weak default to DISTRO_VERSION instead of overriding VERSION_ID.
This allows other layers to override in *.bbappend or *.conf.
Tested:
```
root@romulus:~# cat /etc/os-release
ID=openbmc-openpower
NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)"
VERSION="2.11.0-dev"
VERSION_ID=2.11.0-dev-165-g20885c497
PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 2.11.0-dev"
BUILD_ID="2.11.0-dev"
OPENBMC_TARGET_MACHINE="romulus"
```
Signed-off-by: Willy Tu <wltu@google.com>
Change-Id: I25b5a165b764e6562fa8008c9d2a75a82fb09139
|
|
This adds a new OS identification parameter (EXTENDED_VERSION) to
the /etc/os-release file in the generated OpenBMC image to indicate
the extended version of the OpenBMC image.
Note the extended version is typically set in the
openbmc/meta-*/meta-MACHINE/conf/local.conf.sample file
(This is where TEMPLATECONF points to.) by "EXTENDED_VERSION"
variable.
Tested: On the build system, `cat $IMAGE_ROOTFS/etc/os-release`
shows the correct value.
Signed-off-by: Chanh Nguyen <chanh@amperemail.onmicrosoft.com>
Change-Id: I34d52e3799d83902e12be95d12f4036b70d721cd
|
|
The --long was added to address the issue described in
openbmc/openbmc#1692 where a tag name may not have a '-' separator, ex:
v1.99.6. The parsing of the tag name would then fail. But the parsing
was recently refactored so it no longer fails, we can remove the extra
verbosity of the VERSION_ID field now.
In simplified form, the previous parsing:
"version = versionList[0] + "-" + versionList[1]"
Current parsing that doesn't fail if versionList[1] doesn't exist:
"versionList[0:2]"
Tested: Created a tag 2.10.99 and verified the build succeeded and
the output of os-release reflected the change in the VERSION_ID:
ID=openbmc-witherspoon
NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)"
VERSION="2.10.99"
VERSION_ID=2.10.99
PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 2.10.99"
BUILD_ID="2.10.99"
OPENBMC_TARGET_MACHINE="witherspoon"
Change-Id: I502c72a5c3bfd49913b34bbaa041086c11845421
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|
|
bitbake recipes are run under a process monitor called 'pseudo'.
We are observing cases where these are triggering a "Pseudo Abort" due
to inode reuse (https://wiki.yoctoproject.org/wiki/Pseudo_Abort) of
some sort. 'pseudo' is used for running operations which may require
higher levels of privledge and recording them so they can be re-applied
when building a file system. The `git` calls we are doing are to
determine the revision of the repository and therefore do not need
'pseudo' support. Disable it with the PSEUDO_DISABLED=1 env var.
Also, add a bb.warn call of any exception that is caused by the `git`
call for future debugging.
(From meta-phosphor rev: 64cdbcfa62b5009f7282091b54d10e1149cf0689)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I6ac3fbb1ee15f435ce53ce8f82830120446205a9
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
The previous implementation of the OpenBMC os-release.bbappends
used a python function to inject `git` results into Python
variables. Since the python function is then executed at multiple
task phases, it can result in the hash value changing between tasks,
which causes bitbake failures.
Rewrite the os-release implementation to use forced immediate
variable expansion, rather than a python function. This, combined
with BB_DONT_CACHE, allows the variables to be expanded once at
recipe parse time and the values to continue through to the rest of
the task phases without affecting the hash.
Fixes openbmc/openbmc#3720.
(From meta-phosphor rev: 5266d02bd2a8a6d3a6e047b212f06c7e7aaacb36)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: If221573cdfefc2b0496a0ef2aca4d3cbc82abb7b
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
This reverts commit f2b07859cc9586f96b072678d1f5f4586e77850b.
This turned out to only help hide the issue. Builds would pass but the
os-release value in the flash image would not be correct when this bug
hit.
(From meta-phosphor rev: aae84925dc578f2025aa19c90a718d012aee2577)
Change-Id: I4d6c436297687469116709ebc535bf1d343936f4
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Chasing an intermittent os-release build failure via
openbmc/openbmc#3720. Not clear if this fix will resolve
that issue but there does not appear to be any reason to
run the logic in the bbappend outside of the do_compile
step since that is the only place the OS_RELEASE_FIELDS
are utilized by the base recipe.
(From meta-phosphor rev: f2b07859cc9586f96b072678d1f5f4586e77850b)
Change-Id: I5f14da2babc852f3d39f2ca6bae4bf993d5e22da
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
This adds a new OS identification parameter (OPENBMC_TARGET_MACHINE) to
the /etc/os-release file in the generated OpenBMC image to indicate the
kind of device the OpenBMC image is targeted to control.
This is needed to be able to track the image back to its source code: the
distro and version indicate the exact source code that was used, and the
target machine says which Bitbake layer configuration within that source
was used.
Note the target machine name is typically set in the
openbmc/meta-*/meta-MACHINE/conf/local.conf.sample file.
(This is where TEMPLATECONF points to.)
The "uname" command options -m (machine) and -i (hardware platform) will
continue to refer to the BMC and not its target machine.
Tested: On the build system, `cat $IMAGE_ROOTFS/etc/os-release` shows
the correct value.
(From meta-phosphor rev: e9319a8c4b7bc9b737fbb6e5359f878d5ab13e7a)
Change-Id: I29483ef4a72ae80c30399c795177ed446456740d
Signed-off-by: Joseph Reynolds <jrey@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Adopt a more conventional directory hierarchy. meta-phosphor is still
a _long_ way from suitable for hosting on yoctoproject.org but things
like this don't help.
(From meta-phosphor rev: 471cfcefa74b8c7ceb704cb670e6d915cf27c63b)
Change-Id: I3f106b2f6cdc6cec734be28a6090800546f362eb
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
