From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6519062226403328000 Date: Mon, 5 Feb 2018 06:37:37 -0800 (PST) From: chombourger@gmail.com To: isar-users Message-Id: <8e70c8a5-8e12-4683-b9b3-955becd36571@googlegroups.com> In-Reply-To: <368032d9-2506-d7c8-9d99-fdd909e1f565@siemens.com> References: <20180205133041.69108-1-Cedric_Hombourger@mentor.com> <20180205133041.69108-2-Cedric_Hombourger@mentor.com> <368032d9-2506-d7c8-9d99-fdd909e1f565@siemens.com> Subject: Re: [PATCH 1/1] image: create an image manifest listing installed packages MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_30990_486796208.1517841457214" X-Google-Token: ELHY4dMFvFHoMoik9cc0 X-Google-IP: 81.14.33.59 X-TUID: 2A8q5ZbfiJjE ------=_Part_30990_486796208.1517841457214 Content-Type: multipart/alternative; boundary="----=_Part_30991_1429438954.1517841457214" ------=_Part_30991_1429438954.1517841457214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Jan, Yes I agree that we should "version" the artifacts we produce but this should be done for all of them starting with the image binary itself. IMO - this would warrant another patchset / topic Cedric On Monday, February 5, 2018 at 2:38:57 PM UTC+1, Jan Kiszka wrote: > > On 2018-02-05 14:30, Cedric_H...@mentor.com wrote: > > From: Cedric Hombourger > > > > > Produce an image manifest that lists all packages installed into the > > image. Note the architecture, version and (when specified) the source > > package. The package details are tab-separated and may easily be > > imported into a spreadsheet (e.g. should you need to provide a Bill > > Of Material). > > > > Signed-off-by: Cedric Hombourger > > > --- > > meta/classes/image.bbclass | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass > > index 2c2bafc..c7aa698 100644 > > --- a/meta/classes/image.bbclass > > +++ b/meta/classes/image.bbclass > > @@ -84,6 +84,16 @@ do_populate() { > > addtask populate before do_build after do_unpack > > do_populate[deptask] = "do_deploy_deb" > > > > +# Create a manifest of installed packages and their versions > > +do_manifest() { > > + install -m 755 -d ${DEPLOY_DIR_IMAGE} > > + sudo chroot ${IMAGE_ROOTFS} dpkg-query \ > > + -W -f '${Package}\t${Architecture}\t${Version}\t${Source}\n' \ > > + >${DEPLOY_DIR_IMAGE}/${PN}-${DISTRO}-${MACHINE}.manifest > > +} > > + > > +addtask manifest before do_build after do_populate > > + > > Makes sense. But we should also include the hash of the repo that > initiated the build. We do this in several of out Yocto projects to > resolve the usual question: "Am I really running the latest version?" > > The key problem, though, is to establish a way to define the top-level > layer and, thus, the repo we are interested in. For the yocto cases, we > hard-coded that into the product layers, but there are surely better > approaches. > > > do_copy_boot_files() { > > KERNEL_IMAGE=${@get_image_name(d, 'vmlinuz')} > > if [ -n "${KERNEL_IMAGE}" ]; then > > > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux > ------=_Part_30991_1429438954.1517841457214 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Jan,

Yes I agree that we should "version&qu= ot; the artifacts we produce but this should be done for all of them starti= ng with the image binary itself.
IMO - this would warrant another patchs= et / topic

Cedric

On Monday, February 5, 2018 at 2:38:57 PM U= TC+1, Jan Kiszka wrote:
On 2018= -02-05 14:30, Cedric_H...@mentor.com wrote:
> From: Cedric Hombourger <Cedric_H...@mentor.com>
>=20
> Produce an image manifest that lists all packages installed into t= he
> image. Note the architecture, version and (when specified) the sou= rce
> package. The package details are tab-separated and may easily be
> imported into a spreadsheet (e.g. should you need to provide a Bil= l
> Of Material).
>=20
> Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com>
> ---
> =C2=A0meta/classes/image.bbclass | 10 ++++++++++
> =C2=A01 file changed, 10 insertions(+)
>=20
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbcla= ss
> index 2c2bafc..c7aa698 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -84,6 +84,16 @@ do_populate() {
> =C2=A0addtask populate before do_build after do_unpack
> =C2=A0do_populate[deptask] =3D "do_deploy_deb"
> =C2=A0
> +# Create a manifest of installed packages and their versions
> +do_manifest() {
> + =C2=A0 =C2=A0install -m 755 -d ${DEPLOY_DIR_IMAGE}
> + =C2=A0 =C2=A0sudo chroot ${IMAGE_ROOTFS} dpkg-query \
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0-W -f '${Package}\t${Architecture= }\t${Version}\t${Source}\n' \
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0>${DEPLOY_DIR_IMAGE}/${PN}-${= DISTRO}-${MACHINE}.manifest
> +}
> +
> +addtask manifest before do_build after do_populate
> +

Makes sense. But we should also include the hash of the repo that
initiated the build. We do this in several of out Yocto projects to
resolve the usual question: "Am I really running the latest versio= n?"

The key problem, though, is to establish a way to define the top-level
layer and, thus, the repo we are interested in. For the yocto cases, we
hard-coded that into the product layers, but there are surely better
approaches.

> =C2=A0do_copy_boot_files() {
> =C2=A0 =C2=A0 =C2=A0KERNEL_IMAGE=3D${@get_image_name(d, '= vmlinuz')}
> =C2=A0 =C2=A0 =C2=A0if [ -n "${KERNEL_IMAGE}" ]; then
>=20

Jan

--=20
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
------=_Part_30991_1429438954.1517841457214-- ------=_Part_30990_486796208.1517841457214--