| Message ID | 20210219195719.29037-3-Vijaikumar_Kanagarajan@mentor.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | Custom base-files | expand |
Am Sat, 20 Feb 2021 01:27:19 +0530 schrieb Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>: > /etc/os-release is a symlink to /usr/lib/os-release and belongs to > the base-files package. > > ISAR has been modifying the /etc/os-release during postprocessing > to inject custom data onto it. > > Since this file belongs to base-files, an update/reinstall of the > package would overwrite the file with the one provided by base-files. To some degree such an update would be right to do so. The BUILD_ID will for sure be invalidated, other custom fields might still be valid though. > Instead of modifying the contents of /etc/os-release during > post-processing, provide a modified base-files recipe in ISAR which > provides the similar changes in os-release. I am beginning to wonder if we have to write certain bits to other files. Bits that need to go into /etc/os-release could be appended with a hook See isar-disable-apt-cache, or we use the divert that Silvano proposed. > Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com> > --- > .../recipes-core/images/isar-image-base.bb | 2 + > meta/classes/image-postproc-extension.bbclass | 40 -------------- > meta/classes/image.bbclass | 20 ------- > meta/recipes-core/base-files/base-files.bb | 6 ++ > meta/recipes-core/base-files/base-files.inc | 55 > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 deletions(-) > create mode 100644 meta/recipes-core/base-files/base-files.bb > create mode 100644 meta/recipes-core/base-files/base-files.inc > > diff --git a/meta-isar/recipes-core/images/isar-image-base.bb > b/meta-isar/recipes-core/images/isar-image-base.bb index > b381d85..4aa7e66 100644 --- > a/meta-isar/recipes-core/images/isar-image-base.bb +++ > b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 +11,5 @@ > LIC_FILES_CHKSUM = > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > "1.0" inherit image > + > +IMAGE_INSTALL += "base-files" > diff --git a/meta/classes/image-postproc-extension.bbclass > b/meta/classes/image-postproc-extension.bbclass index > 3f00c21..22c6a95 100644 --- > a/meta/classes/image-postproc-extension.bbclass +++ > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 @@ > # This software is a part of ISAR. > # Copyright (C) Siemens AG, 2019 > > -update_etc_os_release() { > - OS_RELEASE_BUILD_ID="" > - OS_RELEASE_VARIANT="" > - OS_RELEASE_VARIANT_VERSION="" > - while true; do > - case "$1" in > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > - -*) bbfatal "$0: invalid option specified: $1" ;; > - *) break ;; > - esac > - shift > - done > - > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > - sudo sed -i '/^BUILD_ID=.*/d' > '${IMAGE_ROOTFS}/etc/os-release' > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > - fi > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > - sudo sed -i '/^VARIANT=.*/d' '${IMAGE_ROOTFS}/etc/os-release' > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > - fi > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > '${IMAGE_ROOTFS}/etc/os-release' > - echo "VARIANT_VERSION=\"${PV}\"" | \ > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > - fi > -} This is in the image for a good reason, it can not be part of a package, otherwise it would already be and we might not have that evil postprocess feature. Try a run, append a package to IMAGE_PREINSTALL, build again I kind of bet that BUILD_ID will be wrong and not show your new commit or "dirty" > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" > image_postprocess_configure() { > # Configure root filesystem > @@ -45,14 +13,6 @@ image_postprocess_configure() { > fi > } > > -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" > - > -image_postprocess_mark() { > - BUILD_ID=$(get_build_id) > - update_etc_os_release \ > - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" > --version "${PV}" -} > - > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" > image_postprocess_machine_id() { > # systemd(1) takes care of recreating the machine-id on first > boot diff --git a/meta/classes/image.bbclass > b/meta/classes/image.bbclass index eddc444..d849175 100644 > --- a/meta/classes/image.bbclass > +++ b/meta/classes/image.bbclass > @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" > > DEPENDS += "${IMAGE_INSTALL}" > > -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags > --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= > "${ISAR_RELEASE_CMD_DEFAULT}" - > image_do_mounts() { > sudo flock ${MOUNT_LOCKFILE} -c ' \ > mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" > "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): > > return base_size + rootfs_extra * 1024 > > -# here we call a command that should describe your whole build > system, -# this could be "git describe" or something similar. > -# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to > do something -# completely different > -get_build_id() { > - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > - [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" > ]; then > - bbwarn "You are using external layers that will not > be" \ > - "considered in the build_id. Consider > changing" \ > - "ISAR_RELEASE_CMD." > - fi > - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning > empty build_id." > - echo "" > - fi > -} > - > python set_image_size () { > rootfs_size = get_rootfs_size(d) > d.setVar('ROOTFS_SIZE', str(rootfs_size)) > diff --git a/meta/recipes-core/base-files/base-files.bb > b/meta/recipes-core/base-files/base-files.bb new file mode 100644 > index 0000000..d250fc5 > --- /dev/null > +++ b/meta/recipes-core/base-files/base-files.bb > @@ -0,0 +1,6 @@ > +# This software is a part of ISAR. > +# Copyright (c) Mentor, A Siemens Business, 2021 > +# > +# SPDX-License-Identifier: MIT > + > +require base-files.inc > diff --git a/meta/recipes-core/base-files/base-files.inc > b/meta/recipes-core/base-files/base-files.inc new file mode 100644 > index 0000000..68d0e3a > --- /dev/null > +++ b/meta/recipes-core/base-files/base-files.inc > @@ -0,0 +1,55 @@ > +# This software is a part of ISAR. > +# Copyright (c) Mentor, A Siemens Business, 2021 > +# > +# SPDX-License-Identifier: MIT > + > +inherit dpkg > + > +SRC_URI = "apt://${PN}" > + > +S="${WORKDIR}/${PN}" > + > +MAINTAINER = "isar-users <isar-users@googlegroups.com>" > +CHANGELOG_V = "<orig-version>+isar" Just one such package. We will need for for every single image we build in the tree. There can be multiple, especially when multiconfig comes into play, but even without. Think of the internal layer you just helped with for a release, it builds the product and the debug variant, which differ in their DESCRIPTION and must not share that package. I am afraid a package will not work. We would need a package per image. And that package would need to rebuild every time the BUILD_ID changes. But now you still have the problem that someone could install a more recent "base-files" ... Might as well use preferences to pin it forever, instead of forking it and giving it a number that will hopefully never be smaller than the one from debian Henning > +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags > --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= > "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar target > filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" > + > +# here we call a command that should describe your whole build > system, +# this could be "git describe" or something similar. > +# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to > do something +# completely different > +get_build_id() { > + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > + [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; > then > + bbwarn "You are using external layers that will not be" \ > + "considered in the build_id. Consider changing" \ > + "ISAR_RELEASE_CMD." > + fi > + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty > build_id." > + echo "" > + fi > +} > + > +do_prepare_build() { > + deb_add_changelog > + OS_RELEASE_BUILD_ID=$(get_build_id) > + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' > + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > + tee -a '${S}/etc/os-release' > + fi > + if [ -n "${OS_RELEASE_VARIANT}" ]; then > + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' > + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > + tee -a '${S}/etc/os-release' > + fi > + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' > + echo "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" | \ > + tee -a '${S}/etc/os-release' > + fi > +}
19.02.2021 22:57, Vijai Kumar K wrote: > /etc/os-release is a symlink to /usr/lib/os-release and belongs to > the base-files package. > > ISAR has been modifying the /etc/os-release during postprocessing > to inject custom data onto it. > > Since this file belongs to base-files, an update/reinstall of the > package would overwrite the file with the one provided by base-files. > > Instead of modifying the contents of /etc/os-release during > post-processing, provide a modified base-files recipe in ISAR which > provides the similar changes in os-release. > > Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com> Hello, base-files package failed to build for qemuarm64-focal target during CI: 15:12:37 dh_strip 15:12:37 aarch64-linux-gnu-objcopy: Unable to recognise the format of the input file `debian/base-files/usr/bin/locale-check' 15:12:37 dh_strip: error: aarch64-linux-gnu-objcopy --only-keep-debug --compress-debug-sections debian/base-files/usr/bin/locale-check debian/.debhelper/base-files/dbgsym-root/usr/lib/debug/.build-id/71/aa3df0a7e05817cb7e212513aeae7db21d8593.debug returned exit code 1 15:12:37 dh_strip: error: Aborting due to earlier error 15:12:37 make: *** [debian/rules:15: binary] Error 25 15:12:37 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 15:12:37 WARNING: exit code 2 from a shell command. Full log: http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console
On Sat, Feb 20, 2021 at 1:59 PM Henning Schild <henning.schild@siemens.com> wrote: > > Am Sat, 20 Feb 2021 01:27:19 +0530 > schrieb Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>: > > > /etc/os-release is a symlink to /usr/lib/os-release and belongs to > > the base-files package. > > > > ISAR has been modifying the /etc/os-release during postprocessing > > to inject custom data onto it. > > > > Since this file belongs to base-files, an update/reinstall of the > > package would overwrite the file with the one provided by base-files. > > To some degree such an update would be right to do so. The BUILD_ID > will for sure be invalidated, other custom fields might still be valid > though. > > > Instead of modifying the contents of /etc/os-release during > > post-processing, provide a modified base-files recipe in ISAR which > > provides the similar changes in os-release. > > I am beginning to wonder if we have to write certain bits to other > files. Bits that need to go into /etc/os-release could be appended with > a hook > See isar-disable-apt-cache, or we use the divert that Silvano proposed. I have not used hooks before, but looks like it might help in our case. > > > Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com> > > --- > > .../recipes-core/images/isar-image-base.bb | 2 + > > meta/classes/image-postproc-extension.bbclass | 40 -------------- > > meta/classes/image.bbclass | 20 ------- > > meta/recipes-core/base-files/base-files.bb | 6 ++ > > meta/recipes-core/base-files/base-files.inc | 55 > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 deletions(-) > > create mode 100644 meta/recipes-core/base-files/base-files.bb > > create mode 100644 meta/recipes-core/base-files/base-files.inc > > > > diff --git a/meta-isar/recipes-core/images/isar-image-base.bb > > b/meta-isar/recipes-core/images/isar-image-base.bb index > > b381d85..4aa7e66 100644 --- > > a/meta-isar/recipes-core/images/isar-image-base.bb +++ > > b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 +11,5 @@ > > LIC_FILES_CHKSUM = > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > > "1.0" inherit image > > + > > +IMAGE_INSTALL += "base-files" > > diff --git a/meta/classes/image-postproc-extension.bbclass > > b/meta/classes/image-postproc-extension.bbclass index > > 3f00c21..22c6a95 100644 --- > > a/meta/classes/image-postproc-extension.bbclass +++ > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 @@ > > # This software is a part of ISAR. > > # Copyright (C) Siemens AG, 2019 > > > > -update_etc_os_release() { > > - OS_RELEASE_BUILD_ID="" > > - OS_RELEASE_VARIANT="" > > - OS_RELEASE_VARIANT_VERSION="" > > - while true; do > > - case "$1" in > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > - *) break ;; > > - esac > > - shift > > - done > > - > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > - sudo sed -i '/^BUILD_ID=.*/d' > > '${IMAGE_ROOTFS}/etc/os-release' > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > - fi > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > - sudo sed -i '/^VARIANT=.*/d' '${IMAGE_ROOTFS}/etc/os-release' > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > - fi > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > '${IMAGE_ROOTFS}/etc/os-release' > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > - fi > > -} > > This is in the image for a good reason, it can not be part of a > package, otherwise it would already be and we might not have that evil > postprocess feature. > > Try a run, append a package to IMAGE_PREINSTALL, build again > > I kind of bet that BUILD_ID will be wrong and not show your new commit > or "dirty" Yes, It is wrong. Since we definitely know that we are bringing in a variable that changes everytime when there is a change to the source code, we could very well do do_prepare_build[nostamp]="1". That with some changes should solve this problem. Thanks, Vijai Kumar K > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" > > image_postprocess_configure() { > > # Configure root filesystem > > @@ -45,14 +13,6 @@ image_postprocess_configure() { > > fi > > } > > > > -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" > > - > > -image_postprocess_mark() { > > - BUILD_ID=$(get_build_id) > > - update_etc_os_release \ > > - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" > > --version "${PV}" -} > > - > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" > > image_postprocess_machine_id() { > > # systemd(1) takes care of recreating the machine-id on first > > boot diff --git a/meta/classes/image.bbclass > > b/meta/classes/image.bbclass index eddc444..d849175 100644 > > --- a/meta/classes/image.bbclass > > +++ b/meta/classes/image.bbclass > > @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" > > > > DEPENDS += "${IMAGE_INSTALL}" > > > > -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags > > --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= > > "${ISAR_RELEASE_CMD_DEFAULT}" - > > image_do_mounts() { > > sudo flock ${MOUNT_LOCKFILE} -c ' \ > > mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" > > "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): > > > > return base_size + rootfs_extra * 1024 > > > > -# here we call a command that should describe your whole build > > system, -# this could be "git describe" or something similar. > > -# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to > > do something -# completely different > > -get_build_id() { > > - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > - [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" > > ]; then > > - bbwarn "You are using external layers that will not > > be" \ > > - "considered in the build_id. Consider > > changing" \ > > - "ISAR_RELEASE_CMD." > > - fi > > - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning > > empty build_id." > > - echo "" > > - fi > > -} > > - > > python set_image_size () { > > rootfs_size = get_rootfs_size(d) > > d.setVar('ROOTFS_SIZE', str(rootfs_size)) > > diff --git a/meta/recipes-core/base-files/base-files.bb > > b/meta/recipes-core/base-files/base-files.bb new file mode 100644 > > index 0000000..d250fc5 > > --- /dev/null > > +++ b/meta/recipes-core/base-files/base-files.bb > > @@ -0,0 +1,6 @@ > > +# This software is a part of ISAR. > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > +# > > +# SPDX-License-Identifier: MIT > > + > > +require base-files.inc > > diff --git a/meta/recipes-core/base-files/base-files.inc > > b/meta/recipes-core/base-files/base-files.inc new file mode 100644 > > index 0000000..68d0e3a > > --- /dev/null > > +++ b/meta/recipes-core/base-files/base-files.inc > > @@ -0,0 +1,55 @@ > > +# This software is a part of ISAR. > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > +# > > +# SPDX-License-Identifier: MIT > > + > > +inherit dpkg > > + > > +SRC_URI = "apt://${PN}" > > + > > +S="${WORKDIR}/${PN}" > > + > > +MAINTAINER = "isar-users <isar-users@googlegroups.com>" > > +CHANGELOG_V = "<orig-version>+isar" > > Just one such package. We will need for for every single image we build > in the tree. There can be multiple, especially when multiconfig comes > into play, but even without. > > Think of the internal layer you just helped with for a release, it > builds the product and the debug variant, which differ in their > DESCRIPTION and must not share that package. > > I am afraid a package will not work. We would need a package per image. > And that package would need to rebuild every time the BUILD_ID changes. > > But now you still have the problem that someone could install a more > recent "base-files" ... Might as well use preferences to pin it > forever, instead of forking it and giving it a number that will > hopefully never be smaller than the one from debian > > Henning > > > +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags > > --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= > > "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar target > > filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" > > + > > +# here we call a command that should describe your whole build > > system, +# this could be "git describe" or something similar. > > +# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to > > do something +# completely different > > +get_build_id() { > > + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > + [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; > > then > > + bbwarn "You are using external layers that will not be" \ > > + "considered in the build_id. Consider changing" \ > > + "ISAR_RELEASE_CMD." > > + fi > > + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty > > build_id." > > + echo "" > > + fi > > +} > > + > > +do_prepare_build() { > > + deb_add_changelog > > + OS_RELEASE_BUILD_ID=$(get_build_id) > > + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' > > + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > + tee -a '${S}/etc/os-release' > > + fi > > + if [ -n "${OS_RELEASE_VARIANT}" ]; then > > + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' > > + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > + tee -a '${S}/etc/os-release' > > + fi > > + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' > > + echo "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" | \ > > + tee -a '${S}/etc/os-release' > > + fi > > +} > > -- > You received this message because you are subscribed to the Google Groups "isar-users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/20210220092859.382eeb3a%40md1za8fc.ad001.siemens.net.
On Monday, February 22, 2021 at 6:10:08 PM UTC+5:30 ami...@ilbers.de wrote: > 19.02.2021 22:57, Vijai Kumar K wrote: > > /etc/os-release is a symlink to /usr/lib/os-release and belongs to > > the base-files package. > > > > ISAR has been modifying the /etc/os-release during postprocessing > > to inject custom data onto it. > > > > Since this file belongs to base-files, an update/reinstall of the > > package would overwrite the file with the one provided by base-files. > > > > Instead of modifying the contents of /etc/os-release during > > post-processing, provide a modified base-files recipe in ISAR which > > provides the similar changes in os-release. > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > Hello, base-files package failed to build for qemuarm64-focal target > during CI: > > 15:12:37 dh_strip > 15:12:37 aarch64-linux-gnu-objcopy: Unable to recognise the format of > the input file `debian/base-files/usr/bin/locale-check' > 15:12:37 dh_strip: error: aarch64-linux-gnu-objcopy --only-keep-debug > --compress-debug-sections debian/base-files/usr/bin/locale-check > debian/.debhelper/base-files/dbgsym-root/usr/lib/debug/.build-id/71/aa3df0a7e05817cb7e212513aeae7db21d8593.debug > > returned exit code 1 > 15:12:37 dh_strip: error: Aborting due to earlier error > 15:12:37 make: *** [debian/rules:15: binary] Error 25 > 15:12:37 dpkg-buildpackage: error: fakeroot debian/rules binary > subprocess returned exit status 2 > 15:12:37 WARNING: exit code 2 from a shell command. > > Full log: http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console > Thank you Anton, for quickly running this through our CI. I will try to replicate the issue in my local build and will fix it in next version. Best, Vijai Kumar K > -- > Anton Mikanovich > Promwad Ltd. > External service provider of ilbers GmbH > Maria-Merian-Str. 8 > 85521 Ottobrunn, Germany > +49 (89) 122 67 24-0 > Commercial register Munich, HRB 214197 > General Manager: Baurzhan Ismagulov > >
On Tuesday, February 23, 2021 at 2:11:02 PM UTC+5:30 vijaikumar....@gmail.com wrote: > On Monday, February 22, 2021 at 6:10:08 PM UTC+5:30 ami...@ilbers.de > wrote: > >> 19.02.2021 22:57, Vijai Kumar K wrote: >> > /etc/os-release is a symlink to /usr/lib/os-release and belongs to >> > the base-files package. >> > >> > ISAR has been modifying the /etc/os-release during postprocessing >> > to inject custom data onto it. >> > >> > Since this file belongs to base-files, an update/reinstall of the >> > package would overwrite the file with the one provided by base-files. >> > >> > Instead of modifying the contents of /etc/os-release during >> > post-processing, provide a modified base-files recipe in ISAR which >> > provides the similar changes in os-release. >> > >> > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> >> >> Hello, base-files package failed to build for qemuarm64-focal target >> during CI: >> >> 15:12:37 dh_strip >> 15:12:37 aarch64-linux-gnu-objcopy: Unable to recognise the format of >> the input file `debian/base-files/usr/bin/locale-check' >> 15:12:37 dh_strip: error: aarch64-linux-gnu-objcopy --only-keep-debug >> --compress-debug-sections debian/base-files/usr/bin/locale-check >> debian/.debhelper/base-files/dbgsym-root/usr/lib/debug/.build-id/71/aa3df0a7e05817cb7e212513aeae7db21d8593.debug >> >> returned exit code 1 >> 15:12:37 dh_strip: error: Aborting due to earlier error >> 15:12:37 make: *** [debian/rules:15: binary] Error 25 >> 15:12:37 dpkg-buildpackage: error: fakeroot debian/rules binary >> subprocess returned exit status 2 >> 15:12:37 WARNING: exit code 2 from a shell command. >> >> Full log: http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console >> > > Thank you Anton, for quickly running this through our CI. I will try to > replicate the issue in my local build and will fix it in next version. > > This seems to be like a qemu issue. https://www.mail-archive.com/debian-glibc@lists.debian.org/msg59230.html We could work around it by setting ISAR_CROSS_COMPILE. But ubuntu base-files cross compilation is failing. That needs to be fixed first. Maybe should raise an issue in ubuntu. Thanks, Vijai Kumar K > Best, > Vijai Kumar K > > >> -- >> Anton Mikanovich >> Promwad Ltd. >> External service provider of ilbers GmbH >> Maria-Merian-Str. 8 >> 85521 Ottobrunn, Germany >> +49 (89) 122 67 24-0 >> Commercial register Munich, HRB 214197 >> General Manager: Baurzhan Ismagulov >> >>
On 24.02.21 10:20, vijaikumar....@gmail.com wrote: > > > On Tuesday, February 23, 2021 at 2:11:02 PM UTC+5:30 > vijaikumar....@gmail.com wrote: > > On Monday, February 22, 2021 at 6:10:08 PM UTC+5:30 ami...@ilbers.de > wrote: > > 19.02.2021 22:57, Vijai Kumar K wrote: > > /etc/os-release is a symlink to /usr/lib/os-release and > belongs to > > the base-files package. > > > > ISAR has been modifying the /etc/os-release during postprocessing > > to inject custom data onto it. > > > > Since this file belongs to base-files, an update/reinstall of the > > package would overwrite the file with the one provided by > base-files. > > > > Instead of modifying the contents of /etc/os-release during > > post-processing, provide a modified base-files recipe in ISAR > which > > provides the similar changes in os-release. > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > Hello, base-files package failed to build for qemuarm64-focal > target > during CI: > > 15:12:37 dh_strip > 15:12:37 aarch64-linux-gnu-objcopy: Unable to recognise the > format of > the input file `debian/base-files/usr/bin/locale-check' > 15:12:37 dh_strip: error: aarch64-linux-gnu-objcopy > --only-keep-debug > --compress-debug-sections debian/base-files/usr/bin/locale-check > debian/.debhelper/base-files/dbgsym-root/usr/lib/debug/.build-id/71/aa3df0a7e05817cb7e212513aeae7db21d8593.debug > > returned exit code 1 > 15:12:37 dh_strip: error: Aborting due to earlier error > 15:12:37 make: *** [debian/rules:15: binary] Error 25 > 15:12:37 dpkg-buildpackage: error: fakeroot debian/rules binary > subprocess returned exit status 2 > 15:12:37 WARNING: exit code 2 from a shell command. > > Full log: > http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console > <http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console> > > > Thank you Anton, for quickly running this through our CI. I will > try to replicate the issue in my local build and will fix it in next > version. > > > This seems to be like a qemu issue. > https://www.mail-archive.com/debian-glibc@lists.debian.org/msg59230.html > > We could work around it by setting ISAR_CROSS_COMPILE. But ubuntu > base-files cross compilation is failing. > That needs to be fixed first. Maybe should raise an issue in ubuntu. > Are we running qemu-user-static from bullseye here already? That is what we do in kas-isar for a while. Jan
On Wednesday, February 24, 2021 at 2:51:43 PM UTC+5:30 Jan Kiszka wrote: > On 24.02.21 10:20, vijaikumar....@gmail.com wrote: > > > > > > On Tuesday, February 23, 2021 at 2:11:02 PM UTC+5:30 > > vijaikumar....@gmail.com wrote: > > > > On Monday, February 22, 2021 at 6:10:08 PM UTC+5:30 ami...@ilbers.de > > wrote: > > > > 19.02.2021 22:57, Vijai Kumar K wrote: > > > /etc/os-release is a symlink to /usr/lib/os-release and > > belongs to > > > the base-files package. > > > > > > ISAR has been modifying the /etc/os-release during postprocessing > > > to inject custom data onto it. > > > > > > Since this file belongs to base-files, an update/reinstall of the > > > package would overwrite the file with the one provided by > > base-files. > > > > > > Instead of modifying the contents of /etc/os-release during > > > post-processing, provide a modified base-files recipe in ISAR > > which > > > provides the similar changes in os-release. > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > > > Hello, base-files package failed to build for qemuarm64-focal > > target > > during CI: > > > > 15:12:37 dh_strip > > 15:12:37 aarch64-linux-gnu-objcopy: Unable to recognise the > > format of > > the input file `debian/base-files/usr/bin/locale-check' > > 15:12:37 dh_strip: error: aarch64-linux-gnu-objcopy > > --only-keep-debug > > --compress-debug-sections debian/base-files/usr/bin/locale-check > > > debian/.debhelper/base-files/dbgsym-root/usr/lib/debug/.build-id/71/aa3df0a7e05817cb7e212513aeae7db21d8593.debug > > > > > returned exit code 1 > > 15:12:37 dh_strip: error: Aborting due to earlier error > > 15:12:37 make: *** [debian/rules:15: binary] Error 25 > > 15:12:37 dpkg-buildpackage: error: fakeroot debian/rules binary > > subprocess returned exit status 2 > > 15:12:37 WARNING: exit code 2 from a shell command. > > > > Full log: > > http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console > > <http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console> > > > > > > Thank you Anton, for quickly running this through our CI. I will > > try to replicate the issue in my local build and will fix it in next > > version. > > > > > > This seems to be like a qemu issue. > > https://www.mail-archive.com/debian...@lists.debian.org/msg59230.html > <https://www.mail-archive.com/debian-glibc@lists.debian.org/msg59230.html> > > > > We could work around it by setting ISAR_CROSS_COMPILE. But ubuntu > > base-files cross compilation is failing. > > That needs to be fixed first. Maybe should raise an issue in ubuntu. > > > > Are we running qemu-user-static from bullseye here already? That is what > we do in kas-isar for a while. Just now tried in kas. It works as expected. Maybe we might need to update ISAR docs to denote the need for the latest qemu? That leaves the cross-building issue. Raised a bug report in ubuntu for that. https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1916714 I will also see if I can send a patch for this. Till then we might need to disable ISAR_CROSS_COMPILE for base-files for ubuntu. Thanks, Vijai Kumar K > > > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux >
Am Wed, 24 Feb 2021 03:40:48 -0800 (PST) schrieb "vijaikumar....@gmail.com" <vijaikumar.kanagarajan@gmail.com>: > On Wednesday, February 24, 2021 at 2:51:43 PM UTC+5:30 Jan Kiszka > wrote: > > > On 24.02.21 10:20, vijaikumar....@gmail.com wrote: > > > > > > > > > On Tuesday, February 23, 2021 at 2:11:02 PM UTC+5:30 > > > vijaikumar....@gmail.com wrote: > > > > > > On Monday, February 22, 2021 at 6:10:08 PM UTC+5:30 > > > ami...@ilbers.de wrote: > > > > > > 19.02.2021 22:57, Vijai Kumar K wrote: > > > > /etc/os-release is a symlink to /usr/lib/os-release and > > > belongs to > > > > the base-files package. > > > > > > > > ISAR has been modifying the /etc/os-release during > > > > postprocessing to inject custom data onto it. > > > > > > > > Since this file belongs to base-files, an update/reinstall of > > > > the package would overwrite the file with the one provided by > > > base-files. > > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > post-processing, provide a modified base-files recipe in ISAR > > > which > > > > provides the similar changes in os-release. > > > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > > > > > Hello, base-files package failed to build for qemuarm64-focal > > > target > > > during CI: > > > > > > 15:12:37 dh_strip > > > 15:12:37 aarch64-linux-gnu-objcopy: Unable to recognise the > > > format of > > > the input file `debian/base-files/usr/bin/locale-check' > > > 15:12:37 dh_strip: error: aarch64-linux-gnu-objcopy > > > --only-keep-debug > > > --compress-debug-sections debian/base-files/usr/bin/locale-check > > > > > debian/.debhelper/base-files/dbgsym-root/usr/lib/debug/.build-id/71/aa3df0a7e05817cb7e212513aeae7db21d8593.debug > > > > > > > > returned exit code 1 > > > 15:12:37 dh_strip: error: Aborting due to earlier error > > > 15:12:37 make: *** [debian/rules:15: binary] Error 25 > > > 15:12:37 dpkg-buildpackage: error: fakeroot debian/rules binary > > > subprocess returned exit status 2 > > > 15:12:37 WARNING: exit code 2 from a shell command. > > > > > > Full log: > > > http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console > > > <http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console> > > > > > > > > > Thank you Anton, for quickly running this through our CI. I will > > > try to replicate the issue in my local build and will fix it in > > > next version. > > > > > > > > > This seems to be like a qemu issue. > > > https://www.mail-archive.com/debian...@lists.debian.org/msg59230.html > > > > > <https://www.mail-archive.com/debian-glibc@lists.debian.org/msg59230.html> > > > > > > > > We could work around it by setting ISAR_CROSS_COMPILE. But ubuntu > > > base-files cross compilation is failing. > > > That needs to be fixed first. Maybe should raise an issue in > > > ubuntu. > > > > Are we running qemu-user-static from bullseye here already? That is > > what we do in kas-isar for a while. > > > Just now tried in kas. It works as expected. Maybe we might need to > update ISAR > docs to denote the need for the latest qemu? > > That leaves the cross-building issue. > Raised a bug report in ubuntu for that. > https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1916714 > I will also see if I can send a patch for this. Till then we might > need to disable > ISAR_CROSS_COMPILE for base-files for ubuntu. Nice to see those reports and doc updates coming out (vijai, please send that doc patch) But the general approach of this packages seems to be a dead end https://groups.google.com/g/isar-users/c/maMS_p5Ep2o/m/lWSgTr7TAgAJ Henning > Thanks, > Vijai Kumar K > > > > > > > > Jan > > > > -- > > Siemens AG, T RDA IOT > > Corporate Competence Center Embedded Linux > > >
Am Tue, 23 Feb 2021 14:08:29 +0530 schrieb vijai kumar <vijaikumar.kanagarajan@gmail.com>: > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > <henning.schild@siemens.com> wrote: > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > schrieb Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>: > > > > > /etc/os-release is a symlink to /usr/lib/os-release and belongs to > > > the base-files package. > > > > > > ISAR has been modifying the /etc/os-release during postprocessing > > > to inject custom data onto it. > > > > > > Since this file belongs to base-files, an update/reinstall of the > > > package would overwrite the file with the one provided by > > > base-files. > > > > To some degree such an update would be right to do so. The BUILD_ID > > will for sure be invalidated, other custom fields might still be > > valid though. > > > > > Instead of modifying the contents of /etc/os-release during > > > post-processing, provide a modified base-files recipe in ISAR > > > which provides the similar changes in os-release. > > > > I am beginning to wonder if we have to write certain bits to other > > files. Bits that need to go into /etc/os-release could be appended > > with a hook > > See isar-disable-apt-cache, or we use the divert that Silvano > > proposed. > > I have not used hooks before, but looks like it might help in our > case. > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com> > > > --- > > > .../recipes-core/images/isar-image-base.bb | 2 + > > > meta/classes/image-postproc-extension.bbclass | 40 -------------- > > > meta/classes/image.bbclass | 20 ------- > > > meta/recipes-core/base-files/base-files.bb | 6 ++ > > > meta/recipes-core/base-files/base-files.inc | 55 > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > deletions(-) create mode 100644 > > > meta/recipes-core/base-files/base-files.bb create mode 100644 > > > meta/recipes-core/base-files/base-files.inc > > > > > > diff --git a/meta-isar/recipes-core/images/isar-image-base.bb > > > b/meta-isar/recipes-core/images/isar-image-base.bb index > > > b381d85..4aa7e66 100644 --- > > > a/meta-isar/recipes-core/images/isar-image-base.bb +++ > > > b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 +11,5 > > > @@ LIC_FILES_CHKSUM = > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > > > "1.0" inherit image > > > + > > > +IMAGE_INSTALL += "base-files" > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > b/meta/classes/image-postproc-extension.bbclass index > > > 3f00c21..22c6a95 100644 --- > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 @@ > > > # This software is a part of ISAR. > > > # Copyright (C) Siemens AG, 2019 > > > > > > -update_etc_os_release() { > > > - OS_RELEASE_BUILD_ID="" > > > - OS_RELEASE_VARIANT="" > > > - OS_RELEASE_VARIANT_VERSION="" > > > - while true; do > > > - case "$1" in > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > - *) break ;; > > > - esac > > > - shift > > > - done > > > - > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > '${IMAGE_ROOTFS}/etc/os-release' > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > - fi > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > - sudo sed -i '/^VARIANT=.*/d' > > > '${IMAGE_ROOTFS}/etc/os-release' > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > - fi > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > '${IMAGE_ROOTFS}/etc/os-release' > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > - fi > > > -} > > > > This is in the image for a good reason, it can not be part of a > > package, otherwise it would already be and we might not have that > > evil postprocess feature. > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > commit or "dirty" > > Yes, It is wrong. > > Since we definitely know that we are bringing in a variable > that changes everytime when there is a change to the source code, we > could very well do do_prepare_build[nostamp]="1". > > That with some changes should solve this problem. It will mean that every change will trigger a full reinstall of the image, many changes do that, but it sounds bad. And the false-sharing between images and multiconfigs still remains. Try two images in one layer with differing DESCRIPTIONS and see what happens. That would be the simple case without even thinking mc Henning > Thanks, > Vijai Kumar K > > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" > > > image_postprocess_configure() { > > > # Configure root filesystem > > > @@ -45,14 +13,6 @@ image_postprocess_configure() { > > > fi > > > } > > > > > > -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" > > > - > > > -image_postprocess_mark() { > > > - BUILD_ID=$(get_build_id) > > > - update_etc_os_release \ > > > - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" > > > --version "${PV}" -} > > > - > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" > > > image_postprocess_machine_id() { > > > # systemd(1) takes care of recreating the machine-id on first > > > boot diff --git a/meta/classes/image.bbclass > > > b/meta/classes/image.bbclass index eddc444..d849175 100644 > > > --- a/meta/classes/image.bbclass > > > +++ b/meta/classes/image.bbclass > > > @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" > > > > > > DEPENDS += "${IMAGE_INSTALL}" > > > > > > -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > --tags --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= > > > "${ISAR_RELEASE_CMD_DEFAULT}" - > > > image_do_mounts() { > > > sudo flock ${MOUNT_LOCKFILE} -c ' \ > > > mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" > > > "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): > > > > > > return base_size + rootfs_extra * 1024 > > > > > > -# here we call a command that should describe your whole build > > > system, -# this could be "git describe" or something similar. > > > -# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs > > > to do something -# completely different > > > -get_build_id() { > > > - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > - [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" > > > ]; then > > > - bbwarn "You are using external layers that will not > > > be" \ > > > - "considered in the build_id. Consider > > > changing" \ > > > - "ISAR_RELEASE_CMD." > > > - fi > > > - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning > > > empty build_id." > > > - echo "" > > > - fi > > > -} > > > - > > > python set_image_size () { > > > rootfs_size = get_rootfs_size(d) > > > d.setVar('ROOTFS_SIZE', str(rootfs_size)) > > > diff --git a/meta/recipes-core/base-files/base-files.bb > > > b/meta/recipes-core/base-files/base-files.bb new file mode 100644 > > > index 0000000..d250fc5 > > > --- /dev/null > > > +++ b/meta/recipes-core/base-files/base-files.bb > > > @@ -0,0 +1,6 @@ > > > +# This software is a part of ISAR. > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > +# > > > +# SPDX-License-Identifier: MIT > > > + > > > +require base-files.inc > > > diff --git a/meta/recipes-core/base-files/base-files.inc > > > b/meta/recipes-core/base-files/base-files.inc new file mode 100644 > > > index 0000000..68d0e3a > > > --- /dev/null > > > +++ b/meta/recipes-core/base-files/base-files.inc > > > @@ -0,0 +1,55 @@ > > > +# This software is a part of ISAR. > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > +# > > > +# SPDX-License-Identifier: MIT > > > + > > > +inherit dpkg > > > + > > > +SRC_URI = "apt://${PN}" > > > + > > > +S="${WORKDIR}/${PN}" > > > + > > > +MAINTAINER = "isar-users <isar-users@googlegroups.com>" > > > +CHANGELOG_V = "<orig-version>+isar" > > > > Just one such package. We will need for for every single image we > > build in the tree. There can be multiple, especially when > > multiconfig comes into play, but even without. > > > > Think of the internal layer you just helped with for a release, it > > builds the product and the debug variant, which differ in their > > DESCRIPTION and must not share that package. > > > > I am afraid a package will not work. We would need a package per > > image. And that package would need to rebuild every time the > > BUILD_ID changes. > > > > But now you still have the problem that someone could install a more > > recent "base-files" ... Might as well use preferences to pin it > > forever, instead of forking it and giving it a number that will > > hopefully never be smaller than the one from debian > > > > Henning > > > > > +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > --tags --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= > > > "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar target > > > filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" > > > + > > > +# here we call a command that should describe your whole build > > > system, +# this could be "git describe" or something similar. > > > +# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs > > > to do something +# completely different > > > +get_build_id() { > > > + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > + [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; > > > then > > > + bbwarn "You are using external layers that will not > > > be" \ > > > + "considered in the build_id. Consider > > > changing" \ > > > + "ISAR_RELEASE_CMD." > > > + fi > > > + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty > > > build_id." > > > + echo "" > > > + fi > > > +} > > > + > > > +do_prepare_build() { > > > + deb_add_changelog > > > + OS_RELEASE_BUILD_ID=$(get_build_id) > > > + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' > > > + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > + tee -a '${S}/etc/os-release' > > > + fi > > > + if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' > > > + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > + tee -a '${S}/etc/os-release' > > > + fi > > > + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' > > > + echo "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" > > > | \ > > > + tee -a '${S}/etc/os-release' > > > + fi > > > +} > > > > -- > > You received this message because you are subscribed to the Google > > Groups "isar-users" group. To unsubscribe from this group and stop > > receiving emails from it, send an email to > > isar-users+unsubscribe@googlegroups.com. To view this discussion on > > the web visit > > https://groups.google.com/d/msgid/isar-users/20210220092859.382eeb3a%40md1za8fc.ad001.siemens.net. > >
On Wed, Feb 24, 2021 at 5:43 PM Henning Schild <henning.schild@siemens.com> wrote: > > Am Tue, 23 Feb 2021 14:08:29 +0530 > schrieb vijai kumar <vijaikumar.kanagarajan@gmail.com>: > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > <henning.schild@siemens.com> wrote: > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > schrieb Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>: > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and belongs to > > > > the base-files package. > > > > > > > > ISAR has been modifying the /etc/os-release during postprocessing > > > > to inject custom data onto it. > > > > > > > > Since this file belongs to base-files, an update/reinstall of the > > > > package would overwrite the file with the one provided by > > > > base-files. > > > > > > To some degree such an update would be right to do so. The BUILD_ID > > > will for sure be invalidated, other custom fields might still be > > > valid though. > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > post-processing, provide a modified base-files recipe in ISAR > > > > which provides the similar changes in os-release. > > > > > > I am beginning to wonder if we have to write certain bits to other > > > files. Bits that need to go into /etc/os-release could be appended > > > with a hook > > > See isar-disable-apt-cache, or we use the divert that Silvano > > > proposed. > > > > I have not used hooks before, but looks like it might help in our > > case. > > > > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com> > > > > --- > > > > .../recipes-core/images/isar-image-base.bb | 2 + > > > > meta/classes/image-postproc-extension.bbclass | 40 -------------- > > > > meta/classes/image.bbclass | 20 ------- > > > > meta/recipes-core/base-files/base-files.bb | 6 ++ > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > deletions(-) create mode 100644 > > > > meta/recipes-core/base-files/base-files.bb create mode 100644 > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > diff --git a/meta-isar/recipes-core/images/isar-image-base.bb > > > > b/meta-isar/recipes-core/images/isar-image-base.bb index > > > > b381d85..4aa7e66 100644 --- > > > > a/meta-isar/recipes-core/images/isar-image-base.bb +++ > > > > b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 +11,5 > > > > @@ LIC_FILES_CHKSUM = > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > > > > "1.0" inherit image > > > > + > > > > +IMAGE_INSTALL += "base-files" > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > 3f00c21..22c6a95 100644 --- > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 @@ > > > > # This software is a part of ISAR. > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > -update_etc_os_release() { > > > > - OS_RELEASE_BUILD_ID="" > > > > - OS_RELEASE_VARIANT="" > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > - while true; do > > > > - case "$1" in > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > - *) break ;; > > > > - esac > > > > - shift > > > > - done > > > > - > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > - fi > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > - fi > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > - fi > > > > -} > > > > > > This is in the image for a good reason, it can not be part of a > > > package, otherwise it would already be and we might not have that > > > evil postprocess feature. > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > > commit or "dirty" > > > > Yes, It is wrong. > > > > Since we definitely know that we are bringing in a variable > > that changes everytime when there is a change to the source code, we > > could very well do do_prepare_build[nostamp]="1". > > > > That with some changes should solve this problem. > > It will mean that every change will trigger a full reinstall of the > image, many changes do that, but it sounds bad. > > And the false-sharing between images and multiconfigs still remains. > > Try two images in one layer with differing DESCRIPTIONS and see what > happens. That would be the simple case without even thinking mc So basically os-release varies based on the image built. With a single package like this, it is no longer possible. At anypoint we could have only one version of the package. Then, again, it makes me wonder if os-release is an apt place for such information. We lose updatability with the other approach. We definitely leave one file (/etc/os-release or /usr/lib/os-release) outdated on a dist upgrade. Thanks, Vijai Kumar K > > Henning > > > Thanks, > > Vijai Kumar K > > > > > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" > > > > image_postprocess_configure() { > > > > # Configure root filesystem > > > > @@ -45,14 +13,6 @@ image_postprocess_configure() { > > > > fi > > > > } > > > > > > > > -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" > > > > - > > > > -image_postprocess_mark() { > > > > - BUILD_ID=$(get_build_id) > > > > - update_etc_os_release \ > > > > - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" > > > > --version "${PV}" -} > > > > - > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" > > > > image_postprocess_machine_id() { > > > > # systemd(1) takes care of recreating the machine-id on first > > > > boot diff --git a/meta/classes/image.bbclass > > > > b/meta/classes/image.bbclass index eddc444..d849175 100644 > > > > --- a/meta/classes/image.bbclass > > > > +++ b/meta/classes/image.bbclass > > > > @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" > > > > > > > > DEPENDS += "${IMAGE_INSTALL}" > > > > > > > > -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > --tags --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= > > > > "${ISAR_RELEASE_CMD_DEFAULT}" - > > > > image_do_mounts() { > > > > sudo flock ${MOUNT_LOCKFILE} -c ' \ > > > > mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" > > > > "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): > > > > > > > > return base_size + rootfs_extra * 1024 > > > > > > > > -# here we call a command that should describe your whole build > > > > system, -# this could be "git describe" or something similar. > > > > -# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs > > > > to do something -# completely different > > > > -get_build_id() { > > > > - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > - [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" > > > > ]; then > > > > - bbwarn "You are using external layers that will not > > > > be" \ > > > > - "considered in the build_id. Consider > > > > changing" \ > > > > - "ISAR_RELEASE_CMD." > > > > - fi > > > > - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning > > > > empty build_id." > > > > - echo "" > > > > - fi > > > > -} > > > > - > > > > python set_image_size () { > > > > rootfs_size = get_rootfs_size(d) > > > > d.setVar('ROOTFS_SIZE', str(rootfs_size)) > > > > diff --git a/meta/recipes-core/base-files/base-files.bb > > > > b/meta/recipes-core/base-files/base-files.bb new file mode 100644 > > > > index 0000000..d250fc5 > > > > --- /dev/null > > > > +++ b/meta/recipes-core/base-files/base-files.bb > > > > @@ -0,0 +1,6 @@ > > > > +# This software is a part of ISAR. > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > +# > > > > +# SPDX-License-Identifier: MIT > > > > + > > > > +require base-files.inc > > > > diff --git a/meta/recipes-core/base-files/base-files.inc > > > > b/meta/recipes-core/base-files/base-files.inc new file mode 100644 > > > > index 0000000..68d0e3a > > > > --- /dev/null > > > > +++ b/meta/recipes-core/base-files/base-files.inc > > > > @@ -0,0 +1,55 @@ > > > > +# This software is a part of ISAR. > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > +# > > > > +# SPDX-License-Identifier: MIT > > > > + > > > > +inherit dpkg > > > > + > > > > +SRC_URI = "apt://${PN}" > > > > + > > > > +S="${WORKDIR}/${PN}" > > > > + > > > > +MAINTAINER = "isar-users <isar-users@googlegroups.com>" > > > > +CHANGELOG_V = "<orig-version>+isar" > > > > > > Just one such package. We will need for for every single image we > > > build in the tree. There can be multiple, especially when > > > multiconfig comes into play, but even without. > > > > > > Think of the internal layer you just helped with for a release, it > > > builds the product and the debug variant, which differ in their > > > DESCRIPTION and must not share that package. > > > > > > I am afraid a package will not work. We would need a package per > > > image. And that package would need to rebuild every time the > > > BUILD_ID changes. > > > > > > But now you still have the problem that someone could install a more > > > recent "base-files" ... Might as well use preferences to pin it > > > forever, instead of forking it and giving it a number that will > > > hopefully never be smaller than the one from debian > > > > > > Henning > > > > > > > +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > --tags --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= > > > > "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar target > > > > filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" > > > > + > > > > +# here we call a command that should describe your whole build > > > > system, +# this could be "git describe" or something similar. > > > > +# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs > > > > to do something +# completely different > > > > +get_build_id() { > > > > + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > + [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; > > > > then > > > > + bbwarn "You are using external layers that will not > > > > be" \ > > > > + "considered in the build_id. Consider > > > > changing" \ > > > > + "ISAR_RELEASE_CMD." > > > > + fi > > > > + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty > > > > build_id." > > > > + echo "" > > > > + fi > > > > +} > > > > + > > > > +do_prepare_build() { > > > > + deb_add_changelog > > > > + OS_RELEASE_BUILD_ID=$(get_build_id) > > > > + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' > > > > + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > + tee -a '${S}/etc/os-release' > > > > + fi > > > > + if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' > > > > + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > + tee -a '${S}/etc/os-release' > > > > + fi > > > > + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' > > > > + echo "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" > > > > | \ > > > > + tee -a '${S}/etc/os-release' > > > > + fi > > > > +} > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "isar-users" group. To unsubscribe from this group and stop > > > receiving emails from it, send an email to > > > isar-users+unsubscribe@googlegroups.com. To view this discussion on > > > the web visit > > > https://groups.google.com/d/msgid/isar-users/20210220092859.382eeb3a%40md1za8fc.ad001.siemens.net. > > > >
On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 vijaikumar....@gmail.com wrote: > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > <henning...@siemens.com> wrote: > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > <henning...@siemens.com> wrote: > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and belongs to > > > > > the base-files package. > > > > > > > > > > ISAR has been modifying the /etc/os-release during postprocessing > > > > > to inject custom data onto it. > > > > > > > > > > Since this file belongs to base-files, an update/reinstall of the > > > > > package would overwrite the file with the one provided by > > > > > base-files. > > > > > > > > To some degree such an update would be right to do so. The BUILD_ID > > > > will for sure be invalidated, other custom fields might still be > > > > valid though. > > > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > > post-processing, provide a modified base-files recipe in ISAR > > > > > which provides the similar changes in os-release. > > > > > > > > I am beginning to wonder if we have to write certain bits to other > > > > files. Bits that need to go into /etc/os-release could be appended > > > > with a hook > > > > See isar-disable-apt-cache, or we use the divert that Silvano > > > > proposed. > > > > > > I have not used hooks before, but looks like it might help in our > > > case. > > > > > > > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > > > > --- > > > > > .../recipes-core/images/isar-image-base.bb | 2 + > > > > > meta/classes/image-postproc-extension.bbclass | 40 -------------- > > > > > meta/classes/image.bbclass | 20 ------- > > > > > meta/recipes-core/base-files/base-files.bb | 6 ++ > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > deletions(-) create mode 100644 > > > > > meta/recipes-core/base-files/base-files.bb create mode 100644 > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > diff --git a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb index > > > > > b381d85..4aa7e66 100644 --- > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb +++ > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 +11,5 > > > > > @@ LIC_FILES_CHKSUM = > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > > > > > "1.0" inherit image > > > > > + > > > > > +IMAGE_INSTALL += "base-files" > > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > 3f00c21..22c6a95 100644 --- > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 @@ > > > > > # This software is a part of ISAR. > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > -update_etc_os_release() { > > > > > - OS_RELEASE_BUILD_ID="" > > > > > - OS_RELEASE_VARIANT="" > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > - while true; do > > > > > - case "$1" in > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > - *) break ;; > > > > > - esac > > > > > - shift > > > > > - done > > > > > - > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > -} > > > > > > > > This is in the image for a good reason, it can not be part of a > > > > package, otherwise it would already be and we might not have that > > > > evil postprocess feature. > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > > > commit or "dirty" > > > > > > Yes, It is wrong. > > > > > > Since we definitely know that we are bringing in a variable > > > that changes everytime when there is a change to the source code, we > > > could very well do do_prepare_build[nostamp]="1". > > > > > > That with some changes should solve this problem. > > > > It will mean that every change will trigger a full reinstall of the > > image, many changes do that, but it sounds bad. > > > > And the false-sharing between images and multiconfigs still remains. > > > > Try two images in one layer with differing DESCRIPTIONS and see what > > happens. That would be the simple case without even thinking mc > > So basically os-release varies based on the image built. With a single > package > like this, it is no longer possible. At anypoint we could have only one > version > of the package. > Basically we just considered each image to be a "derivative" . Which I don't suppose is the case, at least with upstream ISAR. > > Then, again, it makes me wonder if os-release is an apt place for such > information. > We lose updatability with the other approach. We definitely leave one > file (/etc/os-release or /usr/lib/os-release) > outdated on a dist upgrade. > Thanks, > Vijai Kumar K > > > > > Henning > > > > > Thanks, > > > Vijai Kumar K > > > > > > > > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" > > > > > image_postprocess_configure() { > > > > > # Configure root filesystem > > > > > @@ -45,14 +13,6 @@ image_postprocess_configure() { > > > > > fi > > > > > } > > > > > > > > > > -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" > > > > > - > > > > > -image_postprocess_mark() { > > > > > - BUILD_ID=$(get_build_id) > > > > > - update_etc_os_release \ > > > > > - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" > > > > > --version "${PV}" -} > > > > > - > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" > > > > > image_postprocess_machine_id() { > > > > > # systemd(1) takes care of recreating the machine-id on first > > > > > boot diff --git a/meta/classes/image.bbclass > > > > > b/meta/classes/image.bbclass index eddc444..d849175 100644 > > > > > --- a/meta/classes/image.bbclass > > > > > +++ b/meta/classes/image.bbclass > > > > > @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" > > > > > > > > > > DEPENDS += "${IMAGE_INSTALL}" > > > > > > > > > > -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > > --tags --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" - > > > > > image_do_mounts() { > > > > > sudo flock ${MOUNT_LOCKFILE} -c ' \ > > > > > mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" > > > > > "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): > > > > > > > > > > return base_size + rootfs_extra * 1024 > > > > > > > > > > -# here we call a command that should describe your whole build > > > > > system, -# this could be "git describe" or something similar. > > > > > -# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs > > > > > to do something -# completely different > > > > > -get_build_id() { > > > > > - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > > - [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" > > > > > ]; then > > > > > - bbwarn "You are using external layers that will not > > > > > be" \ > > > > > - "considered in the build_id. Consider > > > > > changing" \ > > > > > - "ISAR_RELEASE_CMD." > > > > > - fi > > > > > - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > > - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning > > > > > empty build_id." > > > > > - echo "" > > > > > - fi > > > > > -} > > > > > - > > > > > python set_image_size () { > > > > > rootfs_size = get_rootfs_size(d) > > > > > d.setVar('ROOTFS_SIZE', str(rootfs_size)) > > > > > diff --git a/meta/recipes-core/base-files/base-files.bb > > > > > b/meta/recipes-core/base-files/base-files.bb new file mode 100644 > > > > > index 0000000..d250fc5 > > > > > --- /dev/null > > > > > +++ b/meta/recipes-core/base-files/base-files.bb > > > > > @@ -0,0 +1,6 @@ > > > > > +# This software is a part of ISAR. > > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > > +# > > > > > +# SPDX-License-Identifier: MIT > > > > > + > > > > > +require base-files.inc > > > > > diff --git a/meta/recipes-core/base-files/base-files.inc > > > > > b/meta/recipes-core/base-files/base-files.inc new file mode 100644 > > > > > index 0000000..68d0e3a > > > > > --- /dev/null > > > > > +++ b/meta/recipes-core/base-files/base-files.inc > > > > > @@ -0,0 +1,55 @@ > > > > > +# This software is a part of ISAR. > > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > > +# > > > > > +# SPDX-License-Identifier: MIT > > > > > + > > > > > +inherit dpkg > > > > > + > > > > > +SRC_URI = "apt://${PN}" > > > > > + > > > > > +S="${WORKDIR}/${PN}" > > > > > + > > > > > +MAINTAINER = "isar-users <isar-...@googlegroups.com>" > > > > > +CHANGELOG_V = "<orig-version>+isar" > > > > > > > > Just one such package. We will need for for every single image we > > > > build in the tree. There can be multiple, especially when > > > > multiconfig comes into play, but even without. > > > > > > > > Think of the internal layer you just helped with for a release, it > > > > builds the product and the debug variant, which differ in their > > > > DESCRIPTION and must not share that package. > > > > > > > > I am afraid a package will not work. We would need a package per > > > > image. And that package would need to rebuild every time the > > > > BUILD_ID changes. > > > > > > > > But now you still have the problem that someone could install a more > > > > recent "base-files" ... Might as well use preferences to pin it > > > > forever, instead of forking it and giving it a number that will > > > > hopefully never be smaller than the one from debian > > > > > > > > Henning > > > > > > > > > +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > > --tags --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar target > > > > > filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" > > > > > + > > > > > +# here we call a command that should describe your whole build > > > > > system, +# this could be "git describe" or something similar. > > > > > +# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs > > > > > to do something +# completely different > > > > > +get_build_id() { > > > > > + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > > + [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; > > > > > then > > > > > + bbwarn "You are using external layers that will not > > > > > be" \ > > > > > + "considered in the build_id. Consider > > > > > changing" \ > > > > > + "ISAR_RELEASE_CMD." > > > > > + fi > > > > > + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > > + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty > > > > > build_id." > > > > > + echo "" > > > > > + fi > > > > > +} > > > > > + > > > > > +do_prepare_build() { > > > > > + deb_add_changelog > > > > > + OS_RELEASE_BUILD_ID=$(get_build_id) > > > > > + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' > > > > > + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > + tee -a '${S}/etc/os-release' > > > > > + fi > > > > > + if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' > > > > > + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > + tee -a '${S}/etc/os-release' > > > > > + fi > > > > > + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' > > > > > + echo "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" > > > > > | \ > > > > > + tee -a '${S}/etc/os-release' > > > > > + fi > > > > > +} > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "isar-users" group. To unsubscribe from this group and stop > > > > receiving emails from it, send an email to > > > > isar-users+...@googlegroups.com. To view this discussion on > > > > the web visit > > > > > https://groups.google.com/d/msgid/isar-users/20210220092859.382eeb3a%40md1za8fc.ad001.siemens.net. > > > > > > > >
Am Thu, 25 Feb 2021 09:27:38 +0530 schrieb vijai kumar <vijaikumar.kanagarajan@gmail.com>: > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > <henning.schild@siemens.com> wrote: > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > schrieb vijai kumar <vijaikumar.kanagarajan@gmail.com>: > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > <henning.schild@siemens.com> wrote: > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > schrieb Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>: > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and > > > > > belongs to the base-files package. > > > > > > > > > > ISAR has been modifying the /etc/os-release during > > > > > postprocessing to inject custom data onto it. > > > > > > > > > > Since this file belongs to base-files, an update/reinstall of > > > > > the package would overwrite the file with the one provided by > > > > > base-files. > > > > > > > > To some degree such an update would be right to do so. The > > > > BUILD_ID will for sure be invalidated, other custom fields > > > > might still be valid though. > > > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > > post-processing, provide a modified base-files recipe in ISAR > > > > > which provides the similar changes in os-release. > > > > > > > > I am beginning to wonder if we have to write certain bits to > > > > other files. Bits that need to go into /etc/os-release could be > > > > appended with a hook > > > > See isar-disable-apt-cache, or we use the divert that Silvano > > > > proposed. > > > > > > I have not used hooks before, but looks like it might help in our > > > case. > > > > > > > > > > > > Signed-off-by: Vijai Kumar K > > > > > <Vijaikumar_Kanagarajan@mentor.com> --- > > > > > .../recipes-core/images/isar-image-base.bb | 2 + > > > > > meta/classes/image-postproc-extension.bbclass | 40 > > > > > -------------- meta/classes/image.bbclass > > > > > | 20 ------- meta/recipes-core/base-files/base-files.bb | > > > > > 6 ++ meta/recipes-core/base-files/base-files.inc | 55 > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > deletions(-) create mode 100644 > > > > > meta/recipes-core/base-files/base-files.bb create mode 100644 > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > diff --git a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb index > > > > > b381d85..4aa7e66 100644 --- > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb +++ > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 > > > > > +11,5 @@ LIC_FILES_CHKSUM = > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 > > > > > PV = "1.0" inherit image > > > > > + > > > > > +IMAGE_INSTALL += "base-files" > > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > 3f00c21..22c6a95 100644 --- > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 > > > > > @@ # This software is a part of ISAR. > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > -update_etc_os_release() { > > > > > - OS_RELEASE_BUILD_ID="" > > > > > - OS_RELEASE_VARIANT="" > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > - while true; do > > > > > - case "$1" in > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > - *) break ;; > > > > > - esac > > > > > - shift > > > > > - done > > > > > - > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > -} > > > > > > > > This is in the image for a good reason, it can not be part of a > > > > package, otherwise it would already be and we might not have > > > > that evil postprocess feature. > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > > > commit or "dirty" > > > > > > Yes, It is wrong. > > > > > > Since we definitely know that we are bringing in a variable > > > that changes everytime when there is a change to the source > > > code, we could very well do do_prepare_build[nostamp]="1". > > > > > > That with some changes should solve this problem. > > > > It will mean that every change will trigger a full reinstall of the > > image, many changes do that, but it sounds bad. > > > > And the false-sharing between images and multiconfigs still remains. > > > > Try two images in one layer with differing DESCRIPTIONS and see what > > happens. That would be the simple case without even thinking mc > > So basically os-release varies based on the image built. With a > single package like this, it is no longer possible. At anypoint we > could have only one version of the package. > > Then, again, it makes me wonder if os-release is an apt place for such > information. > We lose updatability with the other approach. We definitely leave one > file (/etc/os-release or /usr/lib/os-release) > outdated on a dist upgrade. Exactly what i said earlier. We should use another file. And in case we want to keep some information really in /etc/os-release we need to write a hook to merge our bits in every single time apt owns it again. Henning > Thanks, > Vijai Kumar K > > > > > Henning > > > > > Thanks, > > > Vijai Kumar K > > > > > > > > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" > > > > > image_postprocess_configure() { > > > > > # Configure root filesystem > > > > > @@ -45,14 +13,6 @@ image_postprocess_configure() { > > > > > fi > > > > > } > > > > > > > > > > -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" > > > > > - > > > > > -image_postprocess_mark() { > > > > > - BUILD_ID=$(get_build_id) > > > > > - update_etc_os_release \ > > > > > - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" > > > > > --version "${PV}" -} > > > > > - > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" > > > > > image_postprocess_machine_id() { > > > > > # systemd(1) takes care of recreating the machine-id on > > > > > first boot diff --git a/meta/classes/image.bbclass > > > > > b/meta/classes/image.bbclass index eddc444..d849175 100644 > > > > > --- a/meta/classes/image.bbclass > > > > > +++ b/meta/classes/image.bbclass > > > > > @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" > > > > > > > > > > DEPENDS += "${IMAGE_INSTALL}" > > > > > > > > > > -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > > --tags --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" - > > > > > image_do_mounts() { > > > > > sudo flock ${MOUNT_LOCKFILE} -c ' \ > > > > > mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" > > > > > "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): > > > > > > > > > > return base_size + rootfs_extra * 1024 > > > > > > > > > > -# here we call a command that should describe your whole > > > > > build system, -# this could be "git describe" or something > > > > > similar. -# set ISAR_RELEASE_CMD to customize, or override > > > > > do_mark_rootfs to do something -# completely different > > > > > -get_build_id() { > > > > > - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > > - [ "${ISAR_RELEASE_CMD}" = > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" ]; then > > > > > - bbwarn "You are using external layers that will > > > > > not be" \ > > > > > - "considered in the build_id. Consider > > > > > changing" \ > > > > > - "ISAR_RELEASE_CMD." > > > > > - fi > > > > > - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > > - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, > > > > > returning empty build_id." > > > > > - echo "" > > > > > - fi > > > > > -} > > > > > - > > > > > python set_image_size () { > > > > > rootfs_size = get_rootfs_size(d) > > > > > d.setVar('ROOTFS_SIZE', str(rootfs_size)) > > > > > diff --git a/meta/recipes-core/base-files/base-files.bb > > > > > b/meta/recipes-core/base-files/base-files.bb new file mode > > > > > 100644 index 0000000..d250fc5 > > > > > --- /dev/null > > > > > +++ b/meta/recipes-core/base-files/base-files.bb > > > > > @@ -0,0 +1,6 @@ > > > > > +# This software is a part of ISAR. > > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > > +# > > > > > +# SPDX-License-Identifier: MIT > > > > > + > > > > > +require base-files.inc > > > > > diff --git a/meta/recipes-core/base-files/base-files.inc > > > > > b/meta/recipes-core/base-files/base-files.inc new file mode > > > > > 100644 index 0000000..68d0e3a > > > > > --- /dev/null > > > > > +++ b/meta/recipes-core/base-files/base-files.inc > > > > > @@ -0,0 +1,55 @@ > > > > > +# This software is a part of ISAR. > > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > > +# > > > > > +# SPDX-License-Identifier: MIT > > > > > + > > > > > +inherit dpkg > > > > > + > > > > > +SRC_URI = "apt://${PN}" > > > > > + > > > > > +S="${WORKDIR}/${PN}" > > > > > + > > > > > +MAINTAINER = "isar-users <isar-users@googlegroups.com>" > > > > > +CHANGELOG_V = "<orig-version>+isar" > > > > > > > > Just one such package. We will need for for every single image > > > > we build in the tree. There can be multiple, especially when > > > > multiconfig comes into play, but even without. > > > > > > > > Think of the internal layer you just helped with for a release, > > > > it builds the product and the debug variant, which differ in > > > > their DESCRIPTION and must not share that package. > > > > > > > > I am afraid a package will not work. We would need a package per > > > > image. And that package would need to rebuild every time the > > > > BUILD_ID changes. > > > > > > > > But now you still have the problem that someone could install a > > > > more recent "base-files" ... Might as well use preferences to > > > > pin it forever, instead of forking it and giving it a number > > > > that will hopefully never be smaller than the one from debian > > > > > > > > Henning > > > > > > > > > +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > > --tags --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar > > > > > target filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" > > > > > + > > > > > +# here we call a command that should describe your whole > > > > > build system, +# this could be "git describe" or something > > > > > similar. +# set ISAR_RELEASE_CMD to customize, or override > > > > > do_mark_rootfs to do something +# completely different > > > > > +get_build_id() { > > > > > + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > > + [ "${ISAR_RELEASE_CMD}" = > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" ]; then > > > > > + bbwarn "You are using external layers that will > > > > > not be" \ > > > > > + "considered in the build_id. Consider > > > > > changing" \ > > > > > + "ISAR_RELEASE_CMD." > > > > > + fi > > > > > + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > > + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning > > > > > empty build_id." > > > > > + echo "" > > > > > + fi > > > > > +} > > > > > + > > > > > +do_prepare_build() { > > > > > + deb_add_changelog > > > > > + OS_RELEASE_BUILD_ID=$(get_build_id) > > > > > + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' > > > > > + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > + tee -a '${S}/etc/os-release' > > > > > + fi > > > > > + if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' > > > > > + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > + tee -a '${S}/etc/os-release' > > > > > + fi > > > > > + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' > > > > > + echo > > > > > "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" | \ > > > > > + tee -a '${S}/etc/os-release' > > > > > + fi > > > > > +} > > > > > > > > -- > > > > You received this message because you are subscribed to the > > > > Google Groups "isar-users" group. To unsubscribe from this > > > > group and stop receiving emails from it, send an email to > > > > isar-users+unsubscribe@googlegroups.com. To view this > > > > discussion on the web visit > > > > https://groups.google.com/d/msgid/isar-users/20210220092859.382eeb3a%40md1za8fc.ad001.siemens.net. > > > > > >
On 25.02.21 06:08, vijaikumar....@gmail.com wrote: > > > On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 > vijaikumar....@gmail.com wrote: > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > <henning...@siemens.com> wrote: > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > <henning...@siemens.com> wrote: > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and > belongs to > > > > > the base-files package. > > > > > > > > > > ISAR has been modifying the /etc/os-release during > postprocessing > > > > > to inject custom data onto it. > > > > > > > > > > Since this file belongs to base-files, an update/reinstall > of the > > > > > package would overwrite the file with the one provided by > > > > > base-files. > > > > > > > > To some degree such an update would be right to do so. The > BUILD_ID > > > > will for sure be invalidated, other custom fields might still be > > > > valid though. > > > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > > post-processing, provide a modified base-files recipe in ISAR > > > > > which provides the similar changes in os-release. > > > > > > > > I am beginning to wonder if we have to write certain bits to > other > > > > files. Bits that need to go into /etc/os-release could be > appended > > > > with a hook > > > > See isar-disable-apt-cache, or we use the divert that Silvano > > > > proposed. > > > > > > I have not used hooks before, but looks like it might help in our > > > case. > > > > > > > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > > > > --- > > > > > .../recipes-core/images/isar-image-base.bb > <http://isar-image-base.bb> | 2 + > > > > > meta/classes/image-postproc-extension.bbclass | 40 > -------------- > > > > > meta/classes/image.bbclass | 20 ------- > > > > > meta/recipes-core/base-files/base-files.bb > <http://base-files.bb> | 6 ++ > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > deletions(-) create mode 100644 > > > > > meta/recipes-core/base-files/base-files.bb > <http://base-files.bb> create mode 100644 > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > diff --git > a/meta-isar/recipes-core/images/isar-image-base.bb > <http://isar-image-base.bb> > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > <http://isar-image-base.bb> index > > > > > b381d85..4aa7e66 100644 --- > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > <http://isar-image-base.bb> +++ > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > <http://isar-image-base.bb> @@ -11,3 +11,5 > > > > > @@ LIC_FILES_CHKSUM = > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > > > > > "1.0" inherit image > > > > > + > > > > > +IMAGE_INSTALL += "base-files" > > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > 3f00c21..22c6a95 100644 --- > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 > +1,6 @@ > > > > > # This software is a part of ISAR. > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > -update_etc_os_release() { > > > > > - OS_RELEASE_BUILD_ID="" > > > > > - OS_RELEASE_VARIANT="" > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > - while true; do > > > > > - case "$1" in > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > - *) break ;; > > > > > - esac > > > > > - shift > > > > > - done > > > > > - > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > -} > > > > > > > > This is in the image for a good reason, it can not be part of a > > > > package, otherwise it would already be and we might not have that > > > > evil postprocess feature. > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > > > commit or "dirty" > > > > > > Yes, It is wrong. > > > > > > Since we definitely know that we are bringing in a variable > > > that changes everytime when there is a change to the source > code, we > > > could very well do do_prepare_build[nostamp]="1". > > > > > > That with some changes should solve this problem. > > > > It will mean that every change will trigger a full reinstall of the > > image, many changes do that, but it sounds bad. > > > > And the false-sharing between images and multiconfigs still remains. > > > > Try two images in one layer with differing DESCRIPTIONS and see what > > happens. That would be the simple case without even thinking mc > > So basically os-release varies based on the image built. With a > single package > like this, it is no longer possible. At anypoint we could have only > one version > of the package. > > > Basically we just considered each image to be a "derivative" . Which I > don't suppose > is the case, at least with upstream ISAR. > > > > Then, again, it makes me wonder if os-release is an apt place for such > information. > We lose updatability with the other approach. We definitely leave one > file (/etc/os-release or /usr/lib/os-release) > outdated on a dist upgrade. > So far, we did not consider os-release in package-based update scenarios (likely because all our updates were partition based - which doesn't mean package-based will not come one day as well). If we include package-based updates, os-release should be updated by a package as well. Our os-release modification (ISAR_RELEASE_CMD) is bound to an image. An image is not a package, but we could make it depend on an image-specific package carrying or generating that os-release data. That package should definitely NOT be base-files. We need to divert that file and keep it under our control. Obviously, if the user decides to do a an upgrade of the Debian version on the device without pulling a new image version package, things will really divert - but that is no reasonable use case IMHO. Jan
On Thursday, February 25, 2021 at 1:50:04 PM UTC+5:30 Henning Schild wrote: > Am Thu, 25 Feb 2021 09:27:38 +0530 > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > > <henning...@siemens.com> wrote: > > > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > > <henning...@siemens.com> wrote: > > > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and > > > > > > belongs to the base-files package. > > > > > > > > > > > > ISAR has been modifying the /etc/os-release during > > > > > > postprocessing to inject custom data onto it. > > > > > > > > > > > > Since this file belongs to base-files, an update/reinstall of > > > > > > the package would overwrite the file with the one provided by > > > > > > base-files. > > > > > > > > > > To some degree such an update would be right to do so. The > > > > > BUILD_ID will for sure be invalidated, other custom fields > > > > > might still be valid though. > > > > > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > > > post-processing, provide a modified base-files recipe in ISAR > > > > > > which provides the similar changes in os-release. > > > > > > > > > > I am beginning to wonder if we have to write certain bits to > > > > > other files. Bits that need to go into /etc/os-release could be > > > > > appended with a hook > > > > > See isar-disable-apt-cache, or we use the divert that Silvano > > > > > proposed. > > > > > > > > I have not used hooks before, but looks like it might help in our > > > > case. > > > > > > > > > > > > > > > Signed-off-by: Vijai Kumar K > > > > > > <Vijaikumar_...@mentor.com> --- > > > > > > .../recipes-core/images/isar-image-base.bb | 2 + > > > > > > meta/classes/image-postproc-extension.bbclass | 40 > > > > > > -------------- meta/classes/image.bbclass > > > > > > | 20 ------- meta/recipes-core/base-files/base-files.bb | > > > > > > 6 ++ meta/recipes-core/base-files/base-files.inc | 55 > > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > > deletions(-) create mode 100644 > > > > > > meta/recipes-core/base-files/base-files.bb create mode 100644 > > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > > > diff --git a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb index > > > > > > b381d85..4aa7e66 100644 --- > > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb +++ > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 > > > > > > +11,5 @@ LIC_FILES_CHKSUM = > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 > > > > > > PV = "1.0" inherit image > > > > > > + > > > > > > +IMAGE_INSTALL += "base-files" > > > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > > 3f00c21..22c6a95 100644 --- > > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 > > > > > > @@ # This software is a part of ISAR. > > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > > > -update_etc_os_release() { > > > > > > - OS_RELEASE_BUILD_ID="" > > > > > > - OS_RELEASE_VARIANT="" > > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > > - while true; do > > > > > > - case "$1" in > > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > > - *) break ;; > > > > > > - esac > > > > > > - shift > > > > > > - done > > > > > > - > > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - fi > > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - fi > > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - fi > > > > > > -} > > > > > > > > > > This is in the image for a good reason, it can not be part of a > > > > > package, otherwise it would already be and we might not have > > > > > that evil postprocess feature. > > > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > > > > commit or "dirty" > > > > > > > > Yes, It is wrong. > > > > > > > > Since we definitely know that we are bringing in a variable > > > > that changes everytime when there is a change to the source > > > > code, we could very well do do_prepare_build[nostamp]="1". > > > > > > > > That with some changes should solve this problem. > > > > > > It will mean that every change will trigger a full reinstall of the > > > image, many changes do that, but it sounds bad. > > > > > > And the false-sharing between images and multiconfigs still remains. > > > > > > Try two images in one layer with differing DESCRIPTIONS and see what > > > happens. That would be the simple case without even thinking mc > > > > So basically os-release varies based on the image built. With a > > single package like this, it is no longer possible. At anypoint we > > could have only one version of the package. > > > > Then, again, it makes me wonder if os-release is an apt place for such > > information. > > We lose updatability with the other approach. We definitely leave one > > file (/etc/os-release or /usr/lib/os-release) > > outdated on a dist upgrade. > > Exactly what i said earlier. We should use another file. And in case we > want to keep some information really in /etc/os-release we need to > write a hook to merge our bits in every single time apt owns it again. > Then we are back to having something like /etc/isar_info. > > Henning > > > Thanks, > > Vijai Kumar K > > > > > > > > Henning > > > > > > > Thanks, > > > > Vijai Kumar K > > > > > > > > > > > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" > > > > > > image_postprocess_configure() { > > > > > > # Configure root filesystem > > > > > > @@ -45,14 +13,6 @@ image_postprocess_configure() { > > > > > > fi > > > > > > } > > > > > > > > > > > > -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" > > > > > > - > > > > > > -image_postprocess_mark() { > > > > > > - BUILD_ID=$(get_build_id) > > > > > > - update_etc_os_release \ > > > > > > - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" > > > > > > --version "${PV}" -} > > > > > > - > > > > > > ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" > > > > > > image_postprocess_machine_id() { > > > > > > # systemd(1) takes care of recreating the machine-id on > > > > > > first boot diff --git a/meta/classes/image.bbclass > > > > > > b/meta/classes/image.bbclass index eddc444..d849175 100644 > > > > > > --- a/meta/classes/image.bbclass > > > > > > +++ b/meta/classes/image.bbclass > > > > > > @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" > > > > > > > > > > > > DEPENDS += "${IMAGE_INSTALL}" > > > > > > > > > > > > -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > > > --tags --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= > > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" - > > > > > > image_do_mounts() { > > > > > > sudo flock ${MOUNT_LOCKFILE} -c ' \ > > > > > > mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" > > > > > > "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): > > > > > > > > > > > > return base_size + rootfs_extra * 1024 > > > > > > > > > > > > -# here we call a command that should describe your whole > > > > > > build system, -# this could be "git describe" or something > > > > > > similar. -# set ISAR_RELEASE_CMD to customize, or override > > > > > > do_mark_rootfs to do something -# completely different > > > > > > -get_build_id() { > > > > > > - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > > > - [ "${ISAR_RELEASE_CMD}" = > > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" ]; then > > > > > > - bbwarn "You are using external layers that will > > > > > > not be" \ > > > > > > - "considered in the build_id. Consider > > > > > > changing" \ > > > > > > - "ISAR_RELEASE_CMD." > > > > > > - fi > > > > > > - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > > > - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, > > > > > > returning empty build_id." > > > > > > - echo "" > > > > > > - fi > > > > > > -} > > > > > > - > > > > > > python set_image_size () { > > > > > > rootfs_size = get_rootfs_size(d) > > > > > > d.setVar('ROOTFS_SIZE', str(rootfs_size)) > > > > > > diff --git a/meta/recipes-core/base-files/base-files.bb > > > > > > b/meta/recipes-core/base-files/base-files.bb new file mode > > > > > > 100644 index 0000000..d250fc5 > > > > > > --- /dev/null > > > > > > +++ b/meta/recipes-core/base-files/base-files.bb > > > > > > @@ -0,0 +1,6 @@ > > > > > > +# This software is a part of ISAR. > > > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > > > +# > > > > > > +# SPDX-License-Identifier: MIT > > > > > > + > > > > > > +require base-files.inc > > > > > > diff --git a/meta/recipes-core/base-files/base-files.inc > > > > > > b/meta/recipes-core/base-files/base-files.inc new file mode > > > > > > 100644 index 0000000..68d0e3a > > > > > > --- /dev/null > > > > > > +++ b/meta/recipes-core/base-files/base-files.inc > > > > > > @@ -0,0 +1,55 @@ > > > > > > +# This software is a part of ISAR. > > > > > > +# Copyright (c) Mentor, A Siemens Business, 2021 > > > > > > +# > > > > > > +# SPDX-License-Identifier: MIT > > > > > > + > > > > > > +inherit dpkg > > > > > > + > > > > > > +SRC_URI = "apt://${PN}" > > > > > > + > > > > > > +S="${WORKDIR}/${PN}" > > > > > > + > > > > > > +MAINTAINER = "isar-users <isar-...@googlegroups.com>" > > > > > > +CHANGELOG_V = "<orig-version>+isar" > > > > > > > > > > Just one such package. We will need for for every single image > > > > > we build in the tree. There can be multiple, especially when > > > > > multiconfig comes into play, but even without. > > > > > > > > > > Think of the internal layer you just helped with for a release, > > > > > it builds the product and the debug variant, which differ in > > > > > their DESCRIPTION and must not share that package. > > > > > > > > > > I am afraid a package will not work. We would need a package per > > > > > image. And that package would need to rebuild every time the > > > > > BUILD_ID changes. > > > > > > > > > > But now you still have the problem that someone could install a > > > > > more recent "base-files" ... Might as well use preferences to > > > > > pin it forever, instead of forking it and giving it a number > > > > > that will hopefully never be smaller than the one from debian > > > > > > > > > > Henning > > > > > > > > > > > +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe > > > > > > --tags --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= > > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar > > > > > > target filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" > > > > > > + > > > > > > +# here we call a command that should describe your whole > > > > > > build system, +# this could be "git describe" or something > > > > > > similar. +# set ISAR_RELEASE_CMD to customize, or override > > > > > > do_mark_rootfs to do something +# completely different > > > > > > +get_build_id() { > > > > > > + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && > > > > > > + [ "${ISAR_RELEASE_CMD}" = > > > > > > "${ISAR_RELEASE_CMD_DEFAULT}" ]; then > > > > > > + bbwarn "You are using external layers that will > > > > > > not be" \ > > > > > > + "considered in the build_id. Consider > > > > > > changing" \ > > > > > > + "ISAR_RELEASE_CMD." > > > > > > + fi > > > > > > + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then > > > > > > + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning > > > > > > empty build_id." > > > > > > + echo "" > > > > > > + fi > > > > > > +} > > > > > > + > > > > > > +do_prepare_build() { > > > > > > + deb_add_changelog > > > > > > + OS_RELEASE_BUILD_ID=$(get_build_id) > > > > > > + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > > + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' > > > > > > + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > > + tee -a '${S}/etc/os-release' > > > > > > + fi > > > > > > + if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > > + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' > > > > > > + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > > + tee -a '${S}/etc/os-release' > > > > > > + fi > > > > > > + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > > + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' > > > > > > + echo > > > > > > "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" | \ > > > > > > + tee -a '${S}/etc/os-release' > > > > > > + fi > > > > > > +} > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the > > > > > Google Groups "isar-users" group. To unsubscribe from this > > > > > group and stop receiving emails from it, send an email to > > > > > isar-users+...@googlegroups.com. To view this > > > > > discussion on the web visit > > > > > > https://groups.google.com/d/msgid/isar-users/20210220092859.382eeb3a%40md1za8fc.ad001.siemens.net. > > > > > > > > > > >
On 25.02.21 09:20, Jan Kiszka wrote: > On 25.02.21 06:08, vijaikumar....@gmail.com wrote: >> >> >> On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 >> vijaikumar....@gmail.com wrote: >> >> On Wed, Feb 24, 2021 at 5:43 PM Henning Schild >> <henning...@siemens.com> wrote: >> > >> > Am Tue, 23 Feb 2021 14:08:29 +0530 >> > schrieb vijai kumar <vijaikumar....@gmail.com>: >> > >> > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild >> > > <henning...@siemens.com> wrote: >> > > > >> > > > Am Sat, 20 Feb 2021 01:27:19 +0530 >> > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: >> > > > >> > > > > /etc/os-release is a symlink to /usr/lib/os-release and >> belongs to >> > > > > the base-files package. >> > > > > >> > > > > ISAR has been modifying the /etc/os-release during >> postprocessing >> > > > > to inject custom data onto it. >> > > > > >> > > > > Since this file belongs to base-files, an update/reinstall >> of the >> > > > > package would overwrite the file with the one provided by >> > > > > base-files. >> > > > >> > > > To some degree such an update would be right to do so. The >> BUILD_ID >> > > > will for sure be invalidated, other custom fields might still be >> > > > valid though. >> > > > >> > > > > Instead of modifying the contents of /etc/os-release during >> > > > > post-processing, provide a modified base-files recipe in ISAR >> > > > > which provides the similar changes in os-release. >> > > > >> > > > I am beginning to wonder if we have to write certain bits to >> other >> > > > files. Bits that need to go into /etc/os-release could be >> appended >> > > > with a hook >> > > > See isar-disable-apt-cache, or we use the divert that Silvano >> > > > proposed. >> > > >> > > I have not used hooks before, but looks like it might help in our >> > > case. >> > > >> > > > >> > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> >> > > > > --- >> > > > > .../recipes-core/images/isar-image-base.bb >> <http://isar-image-base.bb> | 2 + >> > > > > meta/classes/image-postproc-extension.bbclass | 40 >> -------------- >> > > > > meta/classes/image.bbclass | 20 ------- >> > > > > meta/recipes-core/base-files/base-files.bb >> <http://base-files.bb> | 6 ++ >> > > > > meta/recipes-core/base-files/base-files.inc | 55 >> > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 >> > > > > deletions(-) create mode 100644 >> > > > > meta/recipes-core/base-files/base-files.bb >> <http://base-files.bb> create mode 100644 >> > > > > meta/recipes-core/base-files/base-files.inc >> > > > > >> > > > > diff --git >> a/meta-isar/recipes-core/images/isar-image-base.bb >> <http://isar-image-base.bb> >> > > > > b/meta-isar/recipes-core/images/isar-image-base.bb >> <http://isar-image-base.bb> index >> > > > > b381d85..4aa7e66 100644 --- >> > > > > a/meta-isar/recipes-core/images/isar-image-base.bb >> <http://isar-image-base.bb> +++ >> > > > > b/meta-isar/recipes-core/images/isar-image-base.bb >> <http://isar-image-base.bb> @@ -11,3 +11,5 >> > > > > @@ LIC_FILES_CHKSUM = >> > > > > >> "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = >> > > > > "1.0" inherit image >> > > > > + >> > > > > +IMAGE_INSTALL += "base-files" >> > > > > diff --git a/meta/classes/image-postproc-extension.bbclass >> > > > > b/meta/classes/image-postproc-extension.bbclass index >> > > > > 3f00c21..22c6a95 100644 --- >> > > > > a/meta/classes/image-postproc-extension.bbclass +++ >> > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 >> +1,6 @@ >> > > > > # This software is a part of ISAR. >> > > > > # Copyright (C) Siemens AG, 2019 >> > > > > >> > > > > -update_etc_os_release() { >> > > > > - OS_RELEASE_BUILD_ID="" >> > > > > - OS_RELEASE_VARIANT="" >> > > > > - OS_RELEASE_VARIANT_VERSION="" >> > > > > - while true; do >> > > > > - case "$1" in >> > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; >> > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; >> > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; >> > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; >> > > > > - *) break ;; >> > > > > - esac >> > > > > - shift >> > > > > - done >> > > > > - >> > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then >> > > > > - sudo sed -i '/^BUILD_ID=.*/d' >> > > > > '${IMAGE_ROOTFS}/etc/os-release' >> > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ >> > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' >> > > > > - fi >> > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then >> > > > > - sudo sed -i '/^VARIANT=.*/d' >> > > > > '${IMAGE_ROOTFS}/etc/os-release' >> > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ >> > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' >> > > > > - fi >> > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then >> > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' >> > > > > '${IMAGE_ROOTFS}/etc/os-release' >> > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ >> > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' >> > > > > - fi >> > > > > -} >> > > > >> > > > This is in the image for a good reason, it can not be part of a >> > > > package, otherwise it would already be and we might not have that >> > > > evil postprocess feature. >> > > > >> > > > Try a run, append a package to IMAGE_PREINSTALL, build again >> > > > >> > > > I kind of bet that BUILD_ID will be wrong and not show your new >> > > > commit or "dirty" >> > > >> > > Yes, It is wrong. >> > > >> > > Since we definitely know that we are bringing in a variable >> > > that changes everytime when there is a change to the source >> code, we >> > > could very well do do_prepare_build[nostamp]="1". >> > > >> > > That with some changes should solve this problem. >> > >> > It will mean that every change will trigger a full reinstall of the >> > image, many changes do that, but it sounds bad. >> > >> > And the false-sharing between images and multiconfigs still remains. >> > >> > Try two images in one layer with differing DESCRIPTIONS and see what >> > happens. That would be the simple case without even thinking mc >> >> So basically os-release varies based on the image built. With a >> single package >> like this, it is no longer possible. At anypoint we could have only >> one version >> of the package. >> >> >> Basically we just considered each image to be a "derivative" . Which I >> don't suppose >> is the case, at least with upstream ISAR. >> >> >> >> Then, again, it makes me wonder if os-release is an apt place for such >> information. >> We lose updatability with the other approach. We definitely leave one >> file (/etc/os-release or /usr/lib/os-release) >> outdated on a dist upgrade. >> > > So far, we did not consider os-release in package-based update scenarios > (likely because all our updates were partition based - which doesn't > mean package-based will not come one day as well). If we include > package-based updates, os-release should be updated by a package as well. > > Our os-release modification (ISAR_RELEASE_CMD) is bound to an image. An > image is not a package, but we could make it depend on an image-specific > package carrying or generating that os-release data. That package should > definitely NOT be base-files. We need to divert that file and keep it > under our control. Obviously, if the user decides to do a an upgrade of > the Debian version on the device without pulling a new image version > package, things will really divert - but that is no reasonable use case > IMHO. > In fact, we could make our image-version package depend on the specific base-files version it diverted from. Then we would still encode the need to update both in lock-step, but without having to pointlessly recompile the base-files package. Jan
On Thursday, February 25, 2021 at 1:56:02 PM UTC+5:30 Jan Kiszka wrote: > On 25.02.21 06:08, vijaikumar....@gmail.com wrote: > > > > > > On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 > > vijaikumar....@gmail.com wrote: > > > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > > <henning...@siemens.com> wrote: > > > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > > <henning...@siemens.com> wrote: > > > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and > > belongs to > > > > > > the base-files package. > > > > > > > > > > > > ISAR has been modifying the /etc/os-release during > > postprocessing > > > > > > to inject custom data onto it. > > > > > > > > > > > > Since this file belongs to base-files, an update/reinstall > > of the > > > > > > package would overwrite the file with the one provided by > > > > > > base-files. > > > > > > > > > > To some degree such an update would be right to do so. The > > BUILD_ID > > > > > will for sure be invalidated, other custom fields might still be > > > > > valid though. > > > > > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > > > post-processing, provide a modified base-files recipe in ISAR > > > > > > which provides the similar changes in os-release. > > > > > > > > > > I am beginning to wonder if we have to write certain bits to > > other > > > > > files. Bits that need to go into /etc/os-release could be > > appended > > > > > with a hook > > > > > See isar-disable-apt-cache, or we use the divert that Silvano > > > > > proposed. > > > > > > > > I have not used hooks before, but looks like it might help in our > > > > case. > > > > > > > > > > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > > > > > --- > > > > > > .../recipes-core/images/isar-image-base.bb > > <http://isar-image-base.bb> | 2 + > > > > > > meta/classes/image-postproc-extension.bbclass | 40 > > -------------- > > > > > > meta/classes/image.bbclass | 20 ------- > > > > > > meta/recipes-core/base-files/base-files.bb > > <http://base-files.bb> | 6 ++ > > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > > deletions(-) create mode 100644 > > > > > > meta/recipes-core/base-files/base-files.bb > > <http://base-files.bb> create mode 100644 > > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > > > diff --git > > a/meta-isar/recipes-core/images/isar-image-base.bb > > <http://isar-image-base.bb> > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > <http://isar-image-base.bb> index > > > > > > b381d85..4aa7e66 100644 --- > > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > <http://isar-image-base.bb> +++ > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > <http://isar-image-base.bb> @@ -11,3 +11,5 > > > > > > @@ LIC_FILES_CHKSUM = > > > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > > > > > > "1.0" inherit image > > > > > > + > > > > > > +IMAGE_INSTALL += "base-files" > > > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > > 3f00c21..22c6a95 100644 --- > > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 > > +1,6 @@ > > > > > > # This software is a part of ISAR. > > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > > > -update_etc_os_release() { > > > > > > - OS_RELEASE_BUILD_ID="" > > > > > > - OS_RELEASE_VARIANT="" > > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > > - while true; do > > > > > > - case "$1" in > > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > > - *) break ;; > > > > > > - esac > > > > > > - shift > > > > > > - done > > > > > > - > > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - fi > > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - fi > > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > - fi > > > > > > -} > > > > > > > > > > This is in the image for a good reason, it can not be part of a > > > > > package, otherwise it would already be and we might not have that > > > > > evil postprocess feature. > > > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > > > > commit or "dirty" > > > > > > > > Yes, It is wrong. > > > > > > > > Since we definitely know that we are bringing in a variable > > > > that changes everytime when there is a change to the source > > code, we > > > > could very well do do_prepare_build[nostamp]="1". > > > > > > > > That with some changes should solve this problem. > > > > > > It will mean that every change will trigger a full reinstall of the > > > image, many changes do that, but it sounds bad. > > > > > > And the false-sharing between images and multiconfigs still remains. > > > > > > Try two images in one layer with differing DESCRIPTIONS and see what > > > happens. That would be the simple case without even thinking mc > > > > So basically os-release varies based on the image built. With a > > single package > > like this, it is no longer possible. At anypoint we could have only > > one version > > of the package. > > > > > > Basically we just considered each image to be a "derivative" . Which I > > don't suppose > > is the case, at least with upstream ISAR. > > > > > > > > Then, again, it makes me wonder if os-release is an apt place for such > > information. > > We lose updatability with the other approach. We definitely leave one > > file (/etc/os-release or /usr/lib/os-release) > > outdated on a dist upgrade. > > > > So far, we did not consider os-release in package-based update scenarios > (likely because all our updates were partition based - which doesn't > mean package-based will not come one day as well). If we include > package-based updates, os-release should be updated by a package as well. > > Our os-release modification (ISAR_RELEASE_CMD) is bound to an image. An > image is not a package, but we could make it depend on an image-specific > package carrying or generating that os-release data. That package should > definitely NOT be base-files. We need to divert that file and keep it > under our control. Obviously, if the user decides to do a an upgrade of > the Debian version on the device without pulling a new image version > package, things will really divert - but that is no reasonable use case > IMHO. > I am not quite sure if I get all that. We are now talking about a new file in a new package that depends on image recipe and have it diverted? So that package would not be in the final image. But incase you need to upgrade you would make sure that the package is pulled by making it depend on a specific base-files package. When base-files upgrades the package would be upgraded to? Thanks, Vijai Kumar K > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux >
Am Thu, 25 Feb 2021 01:06:16 -0800 (PST) schrieb "vijaikumar....@gmail.com" <vijaikumar.kanagarajan@gmail.com>: > On Thursday, February 25, 2021 at 1:56:02 PM UTC+5:30 Jan Kiszka > wrote: > > > On 25.02.21 06:08, vijaikumar....@gmail.com wrote: > > > > > > > > > On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 > > > vijaikumar....@gmail.com wrote: > > > > > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > > > <henning...@siemens.com> wrote: > > > > > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > > > <henning...@siemens.com> wrote: > > > > > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and > > > belongs to > > > > > > > the base-files package. > > > > > > > > > > > > > > ISAR has been modifying the /etc/os-release during > > > postprocessing > > > > > > > to inject custom data onto it. > > > > > > > > > > > > > > Since this file belongs to base-files, an > > > > > > > update/reinstall > > > of the > > > > > > > package would overwrite the file with the one provided by > > > > > > > base-files. > > > > > > > > > > > > To some degree such an update would be right to do so. The > > > > > > > > > BUILD_ID > > > > > > will for sure be invalidated, other custom fields might > > > > > > still be valid though. > > > > > > > > > > > > > Instead of modifying the contents of /etc/os-release > > > > > > > during post-processing, provide a modified base-files > > > > > > > recipe in ISAR which provides the similar changes in > > > > > > > os-release. > > > > > > > > > > > > I am beginning to wonder if we have to write certain bits > > > > > > to > > > other > > > > > > files. Bits that need to go into /etc/os-release could be > > > appended > > > > > > with a hook > > > > > > See isar-disable-apt-cache, or we use the divert that > > > > > > Silvano proposed. > > > > > > > > > > I have not used hooks before, but looks like it might help in > > > > > our case. > > > > > > > > > > > > > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > > > > > > --- > > > > > > > .../recipes-core/images/isar-image-base.bb > > > <http://isar-image-base.bb> | 2 + > > > > > > > meta/classes/image-postproc-extension.bbclass | 40 > > > -------------- > > > > > > > meta/classes/image.bbclass | 20 ------- > > > > > > > meta/recipes-core/base-files/base-files.bb > > > <http://base-files.bb> | 6 ++ > > > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > > > deletions(-) create mode 100644 > > > > > > > meta/recipes-core/base-files/base-files.bb > > > <http://base-files.bb> create mode 100644 > > > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > > > > > diff --git > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > <http://isar-image-base.bb> > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > <http://isar-image-base.bb> index > > > > > > > b381d85..4aa7e66 100644 --- > > > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > <http://isar-image-base.bb> +++ > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > <http://isar-image-base.bb> @@ -11,3 +11,5 > > > > > > > @@ LIC_FILES_CHKSUM = > > > > > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV > > > = > > > > > > > "1.0" inherit image > > > > > > > + > > > > > > > +IMAGE_INSTALL += "base-files" > > > > > > > diff --git > > > > > > > a/meta/classes/image-postproc-extension.bbclass > > > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > > > 3f00c21..22c6a95 100644 --- > > > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 > > > > > > > > > > +1,6 @@ > > > > > > > # This software is a part of ISAR. > > > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > > > > > -update_etc_os_release() { > > > > > > > - OS_RELEASE_BUILD_ID="" > > > > > > > - OS_RELEASE_VARIANT="" > > > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > > > - while true; do > > > > > > > - case "$1" in > > > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > > > - *) break ;; > > > > > > > - esac > > > > > > > - shift > > > > > > > - done > > > > > > > - > > > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > - fi > > > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > - fi > > > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > - fi > > > > > > > -} > > > > > > > > > > > > This is in the image for a good reason, it can not be part > > > > > > of a package, otherwise it would already be and we might > > > > > > not have that evil postprocess feature. > > > > > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build > > > > > > again > > > > > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your > > > > > > new commit or "dirty" > > > > > > > > > > Yes, It is wrong. > > > > > > > > > > Since we definitely know that we are bringing in a variable > > > > > that changes everytime when there is a change to the source > > > code, we > > > > > could very well do do_prepare_build[nostamp]="1". > > > > > > > > > > That with some changes should solve this problem. > > > > > > > > It will mean that every change will trigger a full reinstall of > > > > the image, many changes do that, but it sounds bad. > > > > > > > > And the false-sharing between images and multiconfigs still > > > > remains. > > > > > > > > Try two images in one layer with differing DESCRIPTIONS and see > > > > what happens. That would be the simple case without even > > > > thinking mc > > > > > > So basically os-release varies based on the image built. With a > > > single package > > > like this, it is no longer possible. At anypoint we could have > > > only one version > > > of the package. > > > > > > > > > Basically we just considered each image to be a "derivative" . > > > Which I don't suppose > > > is the case, at least with upstream ISAR. > > > > > > > > > > > > Then, again, it makes me wonder if os-release is an apt place for > > > such information. > > > We lose updatability with the other approach. We definitely leave > > > one file (/etc/os-release or /usr/lib/os-release) > > > outdated on a dist upgrade. > > > > > > > So far, we did not consider os-release in package-based update > > scenarios (likely because all our updates were partition based - > > which doesn't mean package-based will not come one day as well). If > > we include package-based updates, os-release should be updated by a > > package as well. > > > > Our os-release modification (ISAR_RELEASE_CMD) is bound to an > > image. An image is not a package, but we could make it depend on an > > image-specific package carrying or generating that os-release data. > > That package should definitely NOT be base-files. We need to divert > > that file and keep it under our control. Obviously, if the user > > decides to do a an upgrade of the Debian version on the device > > without pulling a new image version package, things will really > > divert - but that is no reasonable use case IMHO. > > > > I am not quite sure if I get all that. We are now talking about a new > file in a > new package that depends on image recipe and have it diverted? So that > package would not be in the final image. But incase you need to > upgrade you would > make sure that the package is pulled by making it depend on a > specific base-files > package. When base-files upgrades the package would be upgraded to? My suggestion is to not package that, just like we used to. We just put our stuff in a file via the image postinst. We write a package to "reserve" that file name against collision, that file will be empty in the package, but the hook and its script will live there. Say we had a package isar-base-files that would contain /etc/isar-release and /etc/apt/...hook.conf -> /usr/bin/merger.sh merger.sh: trigger on every base-files update for key in isar-release and key starts with "OS_": if key in os-release: update else append Now we might write DESCRIPTION to /etc/os-release and isar-release and BUILD_ID just to os-release ... because the latter is invalidated with any sort of live update. And yes you can use that to give Debian another name and that will survive updates ... because branding is very important! Henning > Thanks, > Vijai Kumar K > > > > Jan > > > > -- > > Siemens AG, T RDA IOT > > Corporate Competence Center Embedded Linux > > >
On Thursday, February 25, 2021 at 10:07:55 PM UTC+5:30 Henning Schild wrote: > Am Thu, 25 Feb 2021 01:06:16 -0800 (PST) > schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>: > > > On Thursday, February 25, 2021 at 1:56:02 PM UTC+5:30 Jan Kiszka > > wrote: > > > > > On 25.02.21 06:08, vijaikumar....@gmail.com wrote: > > > > > > > > > > > > On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 > > > > vijaikumar....@gmail.com wrote: > > > > > > > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > > > > <henning...@siemens.com> wrote: > > > > > > > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > > > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > > > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > > > > <henning...@siemens.com> wrote: > > > > > > > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and > > > > belongs to > > > > > > > > the base-files package. > > > > > > > > > > > > > > > > ISAR has been modifying the /etc/os-release during > > > > postprocessing > > > > > > > > to inject custom data onto it. > > > > > > > > > > > > > > > > Since this file belongs to base-files, an > > > > > > > > update/reinstall > > > > of the > > > > > > > > package would overwrite the file with the one provided by > > > > > > > > base-files. > > > > > > > > > > > > > > To some degree such an update would be right to do so. The > > > > > > > > > > > BUILD_ID > > > > > > > will for sure be invalidated, other custom fields might > > > > > > > still be valid though. > > > > > > > > > > > > > > > Instead of modifying the contents of /etc/os-release > > > > > > > > during post-processing, provide a modified base-files > > > > > > > > recipe in ISAR which provides the similar changes in > > > > > > > > os-release. > > > > > > > > > > > > > > I am beginning to wonder if we have to write certain bits > > > > > > > to > > > > other > > > > > > > files. Bits that need to go into /etc/os-release could be > > > > appended > > > > > > > with a hook > > > > > > > See isar-disable-apt-cache, or we use the divert that > > > > > > > Silvano proposed. > > > > > > > > > > > > I have not used hooks before, but looks like it might help in > > > > > > our case. > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com> > > > > > > > > --- > > > > > > > > .../recipes-core/images/isar-image-base.bb > > > > <http://isar-image-base.bb> | 2 + > > > > > > > > meta/classes/image-postproc-extension.bbclass | 40 > > > > -------------- > > > > > > > > meta/classes/image.bbclass | 20 ------- > > > > > > > > meta/recipes-core/base-files/base-files.bb > > > > <http://base-files.bb> | 6 ++ > > > > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > > > > deletions(-) create mode 100644 > > > > > > > > meta/recipes-core/base-files/base-files.bb > > > > <http://base-files.bb> create mode 100644 > > > > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > > > > > > > diff --git > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > > <http://isar-image-base.bb> > > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > > <http://isar-image-base.bb> index > > > > > > > > b381d85..4aa7e66 100644 --- > > > > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > > <http://isar-image-base.bb> +++ > > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > > <http://isar-image-base.bb> @@ -11,3 +11,5 > > > > > > > > @@ LIC_FILES_CHKSUM = > > > > > > > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV > > > > = > > > > > > > > "1.0" inherit image > > > > > > > > + > > > > > > > > +IMAGE_INSTALL += "base-files" > > > > > > > > diff --git > > > > > > > > a/meta/classes/image-postproc-extension.bbclass > > > > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > > > > 3f00c21..22c6a95 100644 --- > > > > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 > > > > > > > > > > > > +1,6 @@ > > > > > > > > # This software is a part of ISAR. > > > > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > > > > > > > -update_etc_os_release() { > > > > > > > > - OS_RELEASE_BUILD_ID="" > > > > > > > > - OS_RELEASE_VARIANT="" > > > > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > > > > - while true; do > > > > > > > > - case "$1" in > > > > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > > > > - *) break ;; > > > > > > > > - esac > > > > > > > > - shift > > > > > > > > - done > > > > > > > > - > > > > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > - fi > > > > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > - fi > > > > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > - fi > > > > > > > > -} > > > > > > > > > > > > > > This is in the image for a good reason, it can not be part > > > > > > > of a package, otherwise it would already be and we might > > > > > > > not have that evil postprocess feature. > > > > > > > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build > > > > > > > again > > > > > > > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your > > > > > > > new commit or "dirty" > > > > > > > > > > > > Yes, It is wrong. > > > > > > > > > > > > Since we definitely know that we are bringing in a variable > > > > > > that changes everytime when there is a change to the source > > > > code, we > > > > > > could very well do do_prepare_build[nostamp]="1". > > > > > > > > > > > > That with some changes should solve this problem. > > > > > > > > > > It will mean that every change will trigger a full reinstall of > > > > > the image, many changes do that, but it sounds bad. > > > > > > > > > > And the false-sharing between images and multiconfigs still > > > > > remains. > > > > > > > > > > Try two images in one layer with differing DESCRIPTIONS and see > > > > > what happens. That would be the simple case without even > > > > > thinking mc > > > > > > > > So basically os-release varies based on the image built. With a > > > > single package > > > > like this, it is no longer possible. At anypoint we could have > > > > only one version > > > > of the package. > > > > > > > > > > > > Basically we just considered each image to be a "derivative" . > > > > Which I don't suppose > > > > is the case, at least with upstream ISAR. > > > > > > > > > > > > > > > > Then, again, it makes me wonder if os-release is an apt place for > > > > such information. > > > > We lose updatability with the other approach. We definitely leave > > > > one file (/etc/os-release or /usr/lib/os-release) > > > > outdated on a dist upgrade. > > > > > > > > > > So far, we did not consider os-release in package-based update > > > scenarios (likely because all our updates were partition based - > > > which doesn't mean package-based will not come one day as well). If > > > we include package-based updates, os-release should be updated by a > > > package as well. > > > > > > Our os-release modification (ISAR_RELEASE_CMD) is bound to an > > > image. An image is not a package, but we could make it depend on an > > > image-specific package carrying or generating that os-release data. > > > That package should definitely NOT be base-files. We need to divert > > > that file and keep it under our control. Obviously, if the user > > > decides to do a an upgrade of the Debian version on the device > > > without pulling a new image version package, things will really > > > divert - but that is no reasonable use case IMHO. > > > > > > > I am not quite sure if I get all that. We are now talking about a new > > file in a > > new package that depends on image recipe and have it diverted? So that > > package would not be in the final image. But incase you need to > > upgrade you would > > make sure that the package is pulled by making it depend on a > > specific base-files > > package. When base-files upgrades the package would be upgraded to? > > My suggestion is to not package that, just like we used to. We just put > our stuff in a file via the image postinst. We write a package > to "reserve" that file name against collision, that file will be empty > in the package, but the hook and its script will live there. > > Say we had a package isar-base-files that would contain > /etc/isar-release and /etc/apt/...hook.conf -> /usr/bin/merger.sh > > merger.sh: trigger on every base-files update > for key in isar-release and key starts with "OS_": > if key in os-release: > update > else > append > > Now we might write DESCRIPTION to /etc/os-release and isar-release and > BUILD_ID just to os-release ... because the latter is invalidated with > any sort of live update. > And yes you can use that to give Debian another name and that will > survive updates ... because branding is very important! > > Henning > Thanks for the pointer Henning. I will try this implementation out. I hope no one else is working on this approach. > > Thanks, > > Vijai Kumar K > > > > > > > Jan > > > > > > -- > > > Siemens AG, T RDA IOT > > > Corporate Competence Center Embedded Linux > > > > > > >
Am Sun, 28 Feb 2021 21:07:05 -0800 (PST) schrieb "vijaikumar....@gmail.com" <vijaikumar.kanagarajan@gmail.com>: > On Thursday, February 25, 2021 at 10:07:55 PM UTC+5:30 Henning Schild > wrote: > > > Am Thu, 25 Feb 2021 01:06:16 -0800 (PST) > > schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>: > > > > > On Thursday, February 25, 2021 at 1:56:02 PM UTC+5:30 Jan Kiszka > > > wrote: > > > > > > > On 25.02.21 06:08, vijaikumar....@gmail.com wrote: > > > > > > > > > > > > > > > On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 > > > > > vijaikumar....@gmail.com wrote: > > > > > > > > > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > > > > > <henning...@siemens.com> wrote: > > > > > > > > > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > > > > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > > > > > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > > > > > <henning...@siemens.com> wrote: > > > > > > > > > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release > > > > > > > > > and > > > > > belongs to > > > > > > > > > the base-files package. > > > > > > > > > > > > > > > > > > ISAR has been modifying the /etc/os-release during > > > > > postprocessing > > > > > > > > > to inject custom data onto it. > > > > > > > > > > > > > > > > > > Since this file belongs to base-files, an > > > > > > > > > update/reinstall > > > > > of the > > > > > > > > > package would overwrite the file with the one > > > > > > > > > provided by base-files. > > > > > > > > > > > > > > > > To some degree such an update would be right to do so. > > > > > > > > The > > > > > BUILD_ID > > > > > > > > will for sure be invalidated, other custom fields might > > > > > > > > still be valid though. > > > > > > > > > > > > > > > > > Instead of modifying the contents of /etc/os-release > > > > > > > > > during post-processing, provide a modified base-files > > > > > > > > > recipe in ISAR which provides the similar changes in > > > > > > > > > os-release. > > > > > > > > > > > > > > > > I am beginning to wonder if we have to write certain > > > > > > > > bits to > > > > > other > > > > > > > > files. Bits that need to go into /etc/os-release could > > > > > > > > be > > > > > appended > > > > > > > > with a hook > > > > > > > > See isar-disable-apt-cache, or we use the divert that > > > > > > > > Silvano proposed. > > > > > > > > > > > > > > I have not used hooks before, but looks like it might > > > > > > > help in our case. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vijai Kumar K > > > > > > > > > <Vijaikumar_...@mentor.com> --- > > > > > > > > > .../recipes-core/images/isar-image-base.bb > > > > > <http://isar-image-base.bb> | 2 + > > > > > > > > > meta/classes/image-postproc-extension.bbclass | 40 > > > > > -------------- > > > > > > > > > meta/classes/image.bbclass | 20 ------- > > > > > > > > > meta/recipes-core/base-files/base-files.bb > > > > > <http://base-files.bb> | 6 ++ > > > > > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > > > > > +++++++++++++++++++ 5 files changed, 63 > > > > > > > > > insertions(+), 60 deletions(-) create mode 100644 > > > > > > > > > meta/recipes-core/base-files/base-files.bb > > > > > <http://base-files.bb> create mode 100644 > > > > > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > > > > > > > > > diff --git > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > <http://isar-image-base.bb> > > > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > > > <http://isar-image-base.bb> index > > > > > > > > > b381d85..4aa7e66 100644 --- > > > > > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > <http://isar-image-base.bb> +++ > > > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > > > <http://isar-image-base.bb> @@ -11,3 +11,5 > > > > > > > > > @@ LIC_FILES_CHKSUM = > > > > > > > > > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 > > > > > PV = > > > > > > > > > "1.0" inherit image > > > > > > > > > + > > > > > > > > > +IMAGE_INSTALL += "base-files" > > > > > > > > > diff --git > > > > > > > > > a/meta/classes/image-postproc-extension.bbclass > > > > > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > > > > > 3f00c21..22c6a95 100644 --- > > > > > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > > > > > b/meta/classes/image-postproc-extension.bbclass @@ > > > > > > > > > -1,38 > > > > > +1,6 @@ > > > > > > > > > # This software is a part of ISAR. > > > > > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > > > > > > > > > -update_etc_os_release() { > > > > > > > > > - OS_RELEASE_BUILD_ID="" > > > > > > > > > - OS_RELEASE_VARIANT="" > > > > > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > > > > > - while true; do > > > > > > > > > - case "$1" in > > > > > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > > > > > - *) break ;; > > > > > > > > > - esac > > > > > > > > > - shift > > > > > > > > > - done > > > > > > > > > - > > > > > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > - fi > > > > > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > - fi > > > > > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > - fi > > > > > > > > > -} > > > > > > > > > > > > > > > > This is in the image for a good reason, it can not be > > > > > > > > part of a package, otherwise it would already be and we > > > > > > > > might not have that evil postprocess feature. > > > > > > > > > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build > > > > > > > > again > > > > > > > > > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show > > > > > > > > your new commit or "dirty" > > > > > > > > > > > > > > Yes, It is wrong. > > > > > > > > > > > > > > Since we definitely know that we are bringing in a > > > > > > > variable that changes everytime when there is a change to > > > > > > > the source > > > > > code, we > > > > > > > could very well do do_prepare_build[nostamp]="1". > > > > > > > > > > > > > > That with some changes should solve this problem. > > > > > > > > > > > > It will mean that every change will trigger a full > > > > > > reinstall of the image, many changes do that, but it sounds > > > > > > bad. > > > > > > > > > > > > And the false-sharing between images and multiconfigs still > > > > > > remains. > > > > > > > > > > > > Try two images in one layer with differing DESCRIPTIONS and > > > > > > see what happens. That would be the simple case without > > > > > > even thinking mc > > > > > > > > > > So basically os-release varies based on the image built. With > > > > > a single package > > > > > like this, it is no longer possible. At anypoint we could > > > > > have only one version > > > > > of the package. > > > > > > > > > > > > > > > Basically we just considered each image to be a "derivative" > > > > > . Which I don't suppose > > > > > is the case, at least with upstream ISAR. > > > > > > > > > > > > > > > > > > > > Then, again, it makes me wonder if os-release is an apt place > > > > > for such information. > > > > > We lose updatability with the other approach. We definitely > > > > > leave one file (/etc/os-release or /usr/lib/os-release) > > > > > outdated on a dist upgrade. > > > > > > > > > > > > > So far, we did not consider os-release in package-based update > > > > scenarios (likely because all our updates were partition based > > > > - which doesn't mean package-based will not come one day as > > > > well). If we include package-based updates, os-release should > > > > be updated by a package as well. > > > > > > > > Our os-release modification (ISAR_RELEASE_CMD) is bound to an > > > > image. An image is not a package, but we could make it depend > > > > on an image-specific package carrying or generating that > > > > os-release data. That package should definitely NOT be > > > > base-files. We need to divert that file and keep it under our > > > > control. Obviously, if the user decides to do a an upgrade of > > > > the Debian version on the device without pulling a new image > > > > version package, things will really divert - but that is no > > > > reasonable use case IMHO. > > > > > > I am not quite sure if I get all that. We are now talking about a > > > new file in a > > > new package that depends on image recipe and have it diverted? So > > > that package would not be in the final image. But incase you need > > > to upgrade you would > > > make sure that the package is pulled by making it depend on a > > > specific base-files > > > package. When base-files upgrades the package would be upgraded > > > to? > > > > My suggestion is to not package that, just like we used to. We just > > put our stuff in a file via the image postinst. We write a package > > to "reserve" that file name against collision, that file will be > > empty in the package, but the hook and its script will live there. > > > > Say we had a package isar-base-files that would contain > > /etc/isar-release and /etc/apt/...hook.conf -> /usr/bin/merger.sh > > > > merger.sh: trigger on every base-files update > > for key in isar-release and key starts with "OS_": > > if key in os-release: > > update > > else > > append > > > > Now we might write DESCRIPTION to /etc/os-release and isar-release > > and BUILD_ID just to os-release ... because the latter is > > invalidated with any sort of live update. > > And yes you can use that to give Debian another name and that will > > survive updates ... because branding is very important! > > > > Henning > > > > > Thanks for the pointer Henning. I will try this implementation out. I > hope no one else is working on this approach. I do not think anyone else is currently working on that. And i hope it can work like i described. One thing seems pretty certain ... it is a very bad idea to "brand" debian. Modifications to that file should probably be kept to an absolute minimum. Additional stuff should probably go into additional files. Just to keep that in mind, because the projects you work on seem to have a strong desire on branding. That should be questioned instead of implemented. The initial idea to go for /etc/os-release was limited to two variables and "no updates with apt". regards, Henning > > > > Thanks, > > > Vijai Kumar K > > > > > > > > > > Jan > > > > > > > > -- > > > > Siemens AG, T RDA IOT > > > > Corporate Competence Center Embedded Linux > > > > > > > > > > > >
On Monday, March 1, 2021 at 1:10:10 PM UTC+5:30 Henning Schild wrote: > Am Sun, 28 Feb 2021 21:07:05 -0800 (PST) > schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>: > > > On Thursday, February 25, 2021 at 10:07:55 PM UTC+5:30 Henning Schild > > wrote: > > > > > Am Thu, 25 Feb 2021 01:06:16 -0800 (PST) > > > schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>: > > > > > > > On Thursday, February 25, 2021 at 1:56:02 PM UTC+5:30 Jan Kiszka > > > > wrote: > > > > > > > > > On 25.02.21 06:08, vijaikumar....@gmail.com wrote: > > > > > > > > > > > > > > > > > > On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 > > > > > > vijaikumar....@gmail.com wrote: > > > > > > > > > > > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > > > > > > <henning...@siemens.com> wrote: > > > > > > > > > > > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > > > > > > schrieb vijai kumar <vijaikumar....@gmail.com>: > > > > > > > > > > > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > > > > > > <henning...@siemens.com> wrote: > > > > > > > > > > > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > > > > > > schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>: > > > > > > > > > > > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release > > > > > > > > > > and > > > > > > belongs to > > > > > > > > > > the base-files package. > > > > > > > > > > > > > > > > > > > > ISAR has been modifying the /etc/os-release during > > > > > > postprocessing > > > > > > > > > > to inject custom data onto it. > > > > > > > > > > > > > > > > > > > > Since this file belongs to base-files, an > > > > > > > > > > update/reinstall > > > > > > of the > > > > > > > > > > package would overwrite the file with the one > > > > > > > > > > provided by base-files. > > > > > > > > > > > > > > > > > > To some degree such an update would be right to do so. > > > > > > > > > The > > > > > > BUILD_ID > > > > > > > > > will for sure be invalidated, other custom fields might > > > > > > > > > still be valid though. > > > > > > > > > > > > > > > > > > > Instead of modifying the contents of /etc/os-release > > > > > > > > > > during post-processing, provide a modified base-files > > > > > > > > > > recipe in ISAR which provides the similar changes in > > > > > > > > > > os-release. > > > > > > > > > > > > > > > > > > I am beginning to wonder if we have to write certain > > > > > > > > > bits to > > > > > > other > > > > > > > > > files. Bits that need to go into /etc/os-release could > > > > > > > > > be > > > > > > appended > > > > > > > > > with a hook > > > > > > > > > See isar-disable-apt-cache, or we use the divert that > > > > > > > > > Silvano proposed. > > > > > > > > > > > > > > > > I have not used hooks before, but looks like it might > > > > > > > > help in our case. > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vijai Kumar K > > > > > > > > > > <Vijaikumar_...@mentor.com> --- > > > > > > > > > > .../recipes-core/images/isar-image-base.bb > > > > > > <http://isar-image-base.bb> | 2 + > > > > > > > > > > meta/classes/image-postproc-extension.bbclass | 40 > > > > > > -------------- > > > > > > > > > > meta/classes/image.bbclass | 20 ------- > > > > > > > > > > meta/recipes-core/base-files/base-files.bb > > > > > > <http://base-files.bb> | 6 ++ > > > > > > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > > > > > > +++++++++++++++++++ 5 files changed, 63 > > > > > > > > > > insertions(+), 60 deletions(-) create mode 100644 > > > > > > > > > > meta/recipes-core/base-files/base-files.bb > > > > > > <http://base-files.bb> create mode 100644 > > > > > > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > > > > > > > > > > > diff --git > > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > > <http://isar-image-base.bb> > > > > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > > > > <http://isar-image-base.bb> index > > > > > > > > > > b381d85..4aa7e66 100644 --- > > > > > > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > > <http://isar-image-base.bb> +++ > > > > > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > > > > > > <http://isar-image-base.bb> @@ -11,3 +11,5 > > > > > > > > > > @@ LIC_FILES_CHKSUM = > > > > > > > > > > > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 > > > > > > PV = > > > > > > > > > > "1.0" inherit image > > > > > > > > > > + > > > > > > > > > > +IMAGE_INSTALL += "base-files" > > > > > > > > > > diff --git > > > > > > > > > > a/meta/classes/image-postproc-extension.bbclass > > > > > > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > > > > > > 3f00c21..22c6a95 100644 --- > > > > > > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > > > > > > b/meta/classes/image-postproc-extension.bbclass @@ > > > > > > > > > > -1,38 > > > > > > +1,6 @@ > > > > > > > > > > # This software is a part of ISAR. > > > > > > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > > > > > > > > > > > -update_etc_os_release() { > > > > > > > > > > - OS_RELEASE_BUILD_ID="" > > > > > > > > > > - OS_RELEASE_VARIANT="" > > > > > > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > > > > > > - while true; do > > > > > > > > > > - case "$1" in > > > > > > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > > > > > > - *) break ;; > > > > > > > > > > - esac > > > > > > > > > > - shift > > > > > > > > > > - done > > > > > > > > > > - > > > > > > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > > - fi > > > > > > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > > - fi > > > > > > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > > > > > > - fi > > > > > > > > > > -} > > > > > > > > > > > > > > > > > > This is in the image for a good reason, it can not be > > > > > > > > > part of a package, otherwise it would already be and we > > > > > > > > > might not have that evil postprocess feature. > > > > > > > > > > > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build > > > > > > > > > again > > > > > > > > > > > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show > > > > > > > > > your new commit or "dirty" > > > > > > > > > > > > > > > > Yes, It is wrong. > > > > > > > > > > > > > > > > Since we definitely know that we are bringing in a > > > > > > > > variable that changes everytime when there is a change to > > > > > > > > the source > > > > > > code, we > > > > > > > > could very well do do_prepare_build[nostamp]="1". > > > > > > > > > > > > > > > > That with some changes should solve this problem. > > > > > > > > > > > > > > It will mean that every change will trigger a full > > > > > > > reinstall of the image, many changes do that, but it sounds > > > > > > > bad. > > > > > > > > > > > > > > And the false-sharing between images and multiconfigs still > > > > > > > remains. > > > > > > > > > > > > > > Try two images in one layer with differing DESCRIPTIONS and > > > > > > > see what happens. That would be the simple case without > > > > > > > even thinking mc > > > > > > > > > > > > So basically os-release varies based on the image built. With > > > > > > a single package > > > > > > like this, it is no longer possible. At anypoint we could > > > > > > have only one version > > > > > > of the package. > > > > > > > > > > > > > > > > > > Basically we just considered each image to be a "derivative" > > > > > > . Which I don't suppose > > > > > > is the case, at least with upstream ISAR. > > > > > > > > > > > > > > > > > > > > > > > > Then, again, it makes me wonder if os-release is an apt place > > > > > > for such information. > > > > > > We lose updatability with the other approach. We definitely > > > > > > leave one file (/etc/os-release or /usr/lib/os-release) > > > > > > outdated on a dist upgrade. > > > > > > > > > > > > > > > > So far, we did not consider os-release in package-based update > > > > > scenarios (likely because all our updates were partition based > > > > > - which doesn't mean package-based will not come one day as > > > > > well). If we include package-based updates, os-release should > > > > > be updated by a package as well. > > > > > > > > > > Our os-release modification (ISAR_RELEASE_CMD) is bound to an > > > > > image. An image is not a package, but we could make it depend > > > > > on an image-specific package carrying or generating that > > > > > os-release data. That package should definitely NOT be > > > > > base-files. We need to divert that file and keep it under our > > > > > control. Obviously, if the user decides to do a an upgrade of > > > > > the Debian version on the device without pulling a new image > > > > > version package, things will really divert - but that is no > > > > > reasonable use case IMHO. > > > > > > > > I am not quite sure if I get all that. We are now talking about a > > > > new file in a > > > > new package that depends on image recipe and have it diverted? So > > > > that package would not be in the final image. But incase you need > > > > to upgrade you would > > > > make sure that the package is pulled by making it depend on a > > > > specific base-files > > > > package. When base-files upgrades the package would be upgraded > > > > to? > > > > > > My suggestion is to not package that, just like we used to. We just > > > put our stuff in a file via the image postinst. We write a package > > > to "reserve" that file name against collision, that file will be > > > empty in the package, but the hook and its script will live there. > > > > > > Say we had a package isar-base-files that would contain > > > /etc/isar-release and /etc/apt/...hook.conf -> /usr/bin/merger.sh > > > > > > merger.sh: trigger on every base-files update > > > for key in isar-release and key starts with "OS_": > > > if key in os-release: > > > update > > > else > > > append > > > > > > Now we might write DESCRIPTION to /etc/os-release and isar-release > > > and BUILD_ID just to os-release ... because the latter is > > > invalidated with any sort of live update. > > > And yes you can use that to give Debian another name and that will > > > survive updates ... because branding is very important! > > > > > > Henning > > > > > > > > > Thanks for the pointer Henning. I will try this implementation out. I > > hope no one else is working on this approach. > > I do not think anyone else is currently working on that. And i hope it > can work like i described. One thing seems pretty certain ... it is a > very bad idea to "brand" debian. Modifications to that file should > probably be kept to an absolute minimum. Additional stuff > should probably go into additional files. > Just to keep that in mind, because the projects you work on seem to > have a strong desire on branding. That should be questioned instead of > implemented. The initial idea to go for /etc/os-release was limited to > two variables and "no updates with apt". > I am not sure why you feel it is a bad idea, there has always been a lot of derivatives of Debian. And ISAR as a tool could provide an example on how to do it. Branding is another discussion, and irrespective of that, we are just trying to find a way to add additional fields to /etc/os-release and fix this upgrade issue :) Having custom base-files was one such approach(had limitations). Since you have an entirely new suggestion, I would like to try that out to see how it becomes a candidate to solve the problem in hand. :) Thanks, Vijai Kumar K > > regards, > Henning > > > > > > > Thanks, > > > > Vijai Kumar K > > > > > > > > > > > > > Jan > > > > > > > > > > -- > > > > > Siemens AG, T RDA IOT > > > > > Corporate Competence Center Embedded Linux > > > > > > > > > > > > > > > > > > >
diff --git a/meta-isar/recipes-core/images/isar-image-base.bb b/meta-isar/recipes-core/images/isar-image-base.bb index b381d85..4aa7e66 100644 --- a/meta-isar/recipes-core/images/isar-image-base.bb +++ b/meta-isar/recipes-core/images/isar-image-base.bb @@ -11,3 +11,5 @@ LIC_FILES_CHKSUM = "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = "1.0" inherit image + +IMAGE_INSTALL += "base-files" diff --git a/meta/classes/image-postproc-extension.bbclass b/meta/classes/image-postproc-extension.bbclass index 3f00c21..22c6a95 100644 --- a/meta/classes/image-postproc-extension.bbclass +++ b/meta/classes/image-postproc-extension.bbclass @@ -1,38 +1,6 @@ # This software is a part of ISAR. # Copyright (C) Siemens AG, 2019 -update_etc_os_release() { - OS_RELEASE_BUILD_ID="" - OS_RELEASE_VARIANT="" - OS_RELEASE_VARIANT_VERSION="" - while true; do - case "$1" in - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; - --variant) OS_RELEASE_VARIANT=$2; shift ;; - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; - -*) bbfatal "$0: invalid option specified: $1" ;; - *) break ;; - esac - shift - done - - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then - sudo sed -i '/^BUILD_ID=.*/d' '${IMAGE_ROOTFS}/etc/os-release' - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' - fi - if [ -n "${OS_RELEASE_VARIANT}" ]; then - sudo sed -i '/^VARIANT=.*/d' '${IMAGE_ROOTFS}/etc/os-release' - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' - fi - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' '${IMAGE_ROOTFS}/etc/os-release' - echo "VARIANT_VERSION=\"${PV}\"" | \ - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' - fi -} - ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure" image_postprocess_configure() { # Configure root filesystem @@ -45,14 +13,6 @@ image_postprocess_configure() { fi } -ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark" - -image_postprocess_mark() { - BUILD_ID=$(get_build_id) - update_etc_os_release \ - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" --version "${PV}" -} - ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id" image_postprocess_machine_id() { # systemd(1) takes care of recreating the machine-id on first boot diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index eddc444..d849175 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }" DEPENDS += "${IMAGE_INSTALL}" -ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags --dirty --match 'v[0-9].[0-9]*'" -ISAR_RELEASE_CMD ?= "${ISAR_RELEASE_CMD_DEFAULT}" - image_do_mounts() { sudo flock ${MOUNT_LOCKFILE} -c ' \ mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" "${BUILDROOT_WORK}" @@ -91,23 +88,6 @@ def get_rootfs_size(d): return base_size + rootfs_extra * 1024 -# here we call a command that should describe your whole build system, -# this could be "git describe" or something similar. -# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to do something -# completely different -get_build_id() { - if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && - [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; then - bbwarn "You are using external layers that will not be" \ - "considered in the build_id. Consider changing" \ - "ISAR_RELEASE_CMD." - fi - if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then - bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty build_id." - echo "" - fi -} - python set_image_size () { rootfs_size = get_rootfs_size(d) d.setVar('ROOTFS_SIZE', str(rootfs_size)) diff --git a/meta/recipes-core/base-files/base-files.bb b/meta/recipes-core/base-files/base-files.bb new file mode 100644 index 0000000..d250fc5 --- /dev/null +++ b/meta/recipes-core/base-files/base-files.bb @@ -0,0 +1,6 @@ +# This software is a part of ISAR. +# Copyright (c) Mentor, A Siemens Business, 2021 +# +# SPDX-License-Identifier: MIT + +require base-files.inc diff --git a/meta/recipes-core/base-files/base-files.inc b/meta/recipes-core/base-files/base-files.inc new file mode 100644 index 0000000..68d0e3a --- /dev/null +++ b/meta/recipes-core/base-files/base-files.inc @@ -0,0 +1,55 @@ +# This software is a part of ISAR. +# Copyright (c) Mentor, A Siemens Business, 2021 +# +# SPDX-License-Identifier: MIT + +inherit dpkg + +SRC_URI = "apt://${PN}" + +S="${WORKDIR}/${PN}" + +MAINTAINER = "isar-users <isar-users@googlegroups.com>" +CHANGELOG_V = "<orig-version>+isar" + +ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags --dirty --match 'v[0-9].[0-9]*'" +ISAR_RELEASE_CMD ?= "${ISAR_RELEASE_CMD_DEFAULT}" +OS_RELEASE_VARIANT = "Isar target filesystem" +OS_RELEASE_VARIANT_VERSION = "1.0" + +# here we call a command that should describe your whole build system, +# this could be "git describe" or something similar. +# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to do something +# completely different +get_build_id() { + if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] && + [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; then + bbwarn "You are using external layers that will not be" \ + "considered in the build_id. Consider changing" \ + "ISAR_RELEASE_CMD." + fi + if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then + bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty build_id." + echo "" + fi +} + +do_prepare_build() { + deb_add_changelog + OS_RELEASE_BUILD_ID=$(get_build_id) + if [ -n "${OS_RELEASE_BUILD_ID}" ]; then + sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release' + echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ + tee -a '${S}/etc/os-release' + fi + if [ -n "${OS_RELEASE_VARIANT}" ]; then + sed -i '/^VARIANT=.*/d' '${S}/etc/os-release' + echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ + tee -a '${S}/etc/os-release' + fi + if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then + sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release' + echo "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" | \ + tee -a '${S}/etc/os-release' + fi +}
/etc/os-release is a symlink to /usr/lib/os-release and belongs to the base-files package. ISAR has been modifying the /etc/os-release during postprocessing to inject custom data onto it. Since this file belongs to base-files, an update/reinstall of the package would overwrite the file with the one provided by base-files. Instead of modifying the contents of /etc/os-release during post-processing, provide a modified base-files recipe in ISAR which provides the similar changes in os-release. Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com> --- .../recipes-core/images/isar-image-base.bb | 2 + meta/classes/image-postproc-extension.bbclass | 40 -------------- meta/classes/image.bbclass | 20 ------- meta/recipes-core/base-files/base-files.bb | 6 ++ meta/recipes-core/base-files/base-files.inc | 55 +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 deletions(-) create mode 100644 meta/recipes-core/base-files/base-files.bb create mode 100644 meta/recipes-core/base-files/base-files.inc