This brings back commit d41097a970e9bfa553cd4bc3c9fad4b9073d7bd5,
which got lost during transition from image.bbclass to rootfs.py.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Extract the common codes of log checking and add the ability of log
checking for deb and ipk package backend.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This patch involves two changes.

1. Extend the regular expression to also catch '^WARNING:' in _log_check_warn.
   Warnings from bb.note or bbnote begin with 'WARNING:'. So if we decide to
   catch warnings at rootfs time, we should not ignore those produced by
   the build system itself.

2. Delay _log_check in rootfs process so that more warnings are likely to be
   catched. Note that we should at least delay the _log_check after the
   execution of ROOTFS_POSTPROCESS_COMMANDS, because we want to catch warnings
   there.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This patch creates a variable for the install_dir name so it can be
something other than /install, also by doing this we can correctly
clean up the empty directories (/install/tmp) during the clean-up
phase. The new default is /oe_install so as to not conflict with other
possible packages that might use /install to place files.

[YOCTO #7353]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The following commit caused log checking for warnings not working for RPM
rootfs.

    rootfs.py: ignore "NOTE:" when catching warnings

The problem is that checking for warnings is always skipped because the
following statement is always true.

    if 'log_check' or 'NOTE:' in line:

This patch fixes the above problem so that warning checking in RPM rootfs
can work again.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The script looks for any warn|Warn pattern in the log. However,
it may happen that the warn|Warn pattern appears as part of the name
of the objects described in the NOTE lines of the log. Thus, to avoid
false positives, ignore the line if it contains the word "NOTE:"

Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

This allows an image to skip the creation of kernel depmod
data. It is useful for creating an image that will run as a
container image inside a host with no knowledge of the parent's
kernel.

Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Since the rewrite of the image construction code in python a few
releases ago, we remove a couple of packages from the image as one of
the final steps when constructing the image (notably update-rc.d and
run-postinsts).  However, because of the order of operations, these
packages are still listed both in the buildhistory
installed_package*.txt files and in the manifest file created next to
the image, which is wrong.

There were two possible solutions to this: (1) change the order such
that the uninstallation occurs before calling ROOTFS_POSTPROCESS_COMMAND
or (2) add another hook variable in such that we can have the
package list collection code run at the right time. Because it's
currently possible (but very much not recommended) to install additional
packages within ROOTFS_POSTPROCESS_COMMAND, which may have postinstall
scripts and thus require the packages we would otherwise uninstall if we
were to take option 1, option 2 is really the least likely to cause
problems. Therefore, add ROOTFS_POSTUNINSTALL_COMMAND and make the image
and buildhistory classes use it.

Fixes [YOCTO #6479].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

Rename it to _uninstall_unneeded.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

Using populate_sysroot for this data was a nice idea but flawed as it
doesn't work in multilib builds. Instead we can use PKGDATA_DIR since
this is consistent over multilib builds. It also turns out to be
slightly neater code too. Hopefully this resolves the problem once and
for all.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>