2019. 09. 26. 23:02 keltezéssel, richard.pur...@linuxfoundation.org írta:
On Thu, 2019-09-26 at 19:09 +0200, Böszörményi Zoltán wrote:
2019. 09. 26. 19:02 keltezéssel, Böszörményi Zoltán via Openembedded-
core írta:
2019. 09. 26. 18:50 keltezéssel, Böszörményi Zoltán via
Openembedded-core írta:
2019. 09. 26. 17:45 keltezéssel, Richard Purdie írta:
I'm a little worried that INITRAMFS_FSTYPES can contain
multiple values
by the sounds of its name...
From the looks of the current value, it's already contains
multiple values
delimited by that dot. "cpio" + "gz".
Also, according to meta/conf/documentation.conf, line 228:
INITRAMFS_FSTYPES[doc] = "Defines the format for the output image
of an initial RAM disk
(initramfs), which is used during boot."
Also, image-live.bbclass uses this variable this way:
INITRD_LIVE ?= "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-
${MACHINE}.${INITRAMFS_FSTYPES}"
The initrd/initramfs file name would definitely look strange if
this variable could contain multiple space delimited settings.
Also, openembedded-core/scripts/lib/wic/plugins/source/isoimage-
isohybrid.py
has that _build_initramfs_path function from line 143. The usage of
the same variable in this python function also points back to the
documentation line, i.e. it's a filename suffix and not multiple
settings delimited by space.
This does look ok given the above. Thanks for confirming.
Thanks for merging it into master-next.
I have also sent a patch for warrior separately with [warrior][PATCH]
yesterday, as I experienced the error there first.
Can you please apply it to warrior-next so I won't have to carry
the patch locally for long?
Thanks in advance,
Zoltán Böszörményi
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core