openembedded-core.git/meta/classes/rootfs_rpm.bbclass, branch dylan

rpm: split out run-postinsts

2013-03-29T10:40:18+00:00

1. Split out run-postinsts script into separated package, sometimes only the
   postinsts script is required to run all postinsts scripts in /etc/rpm-postinsts/
   instead of the whole rpm package.
2. Set ROOTFS_PKGMANAGE_BOOTSTRAP to rpm-postinsts

Signed-off-by: Zhenhua Luo 
Signed-off-by: Richard Purdie

classes/buildhistory: implement history collection for SDKs

2013-03-23T11:40:50+00:00

SDKs are constructed in a similar manner to images, and the contents can
be influenced by a number of different factors, thus tracking the
contents of produced SDKs when buildhistory is enabled can help detect
the same kinds of issues as with images.

This required adding POPULATE_SDK_POST_HOST_COMMAND and
SDK_POSTPROCESS_COMMAND variables so that data collection functions can
be injected at the appropriate points in the SDK construction process,
as well as moving the list_installed_packages and
rootfs_list_installed_depends functions from the rootfs_{rpm,ipk,deb} to
the package_{rpm,ipk,deb} classes so they can also be called during
do_populate_sdk as well as do_rootfs.

Implements [YOCTO #3964].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

rootfs_xxx.bbclass: fix bitbake -S hashes mismatch error

2013-03-12T18:26:05+00:00

The bitbake -S  has errors, e.g.:

NOTE: Reparsing files to collect dependency data
ERROR: Bitbake's cached basehash does not match the one we just generated
(/buildarea/lyang1/poky/meta/recipes-core/images/core-image-minimal.bb.do_rootfs)!
ERROR: The mismatched hashes were 8e44f2296f2d6cdf2ccb0236910ef59b and
46357d5e36713646b47b0fe2233e3c8c

This is caused by the BUILDNAME which is defined in cooker.py:

if not self.configuration.data.getVar("BUILDNAME"):
    self.configuration.data.setVar("BUILDNAME", time.strftime('%Y%m%d%H%M'))

The time changes during the first parsing and reparsing, so there is the
error, we already have:

do_rootfs[vardepsexclude] += "BUILDNAME"

but what we need is
rootfs_xxx_do_rootfs[vardepsexclude] +=  "BUILDNAME"

The do_rootfs doesn't depend on BUILDNAME directly, but indirectly, the
depends tree is:

do_rootfs -> rootfs_xxx_do_rootfs -> BUILDNAME

So add BUILDNAME to rootfs_xxx_do_rootfs[vardepsexclude] would fix the
problem.

[YOCTO #3299]

Signed-off-by: Robert Yang 
Signed-off-by: Saul Wold

rootfs_rpm: move run-postinsts scripts to rpm recipe

2013-03-01T12:52:54+00:00

Move run-postinsts scripts from rootfs_rpm.bbclass to rpm recipe. That
is the same way for dpkg and opkg to deal the post install scripts.

Signed-off-by: Kang Kai 
Signed-off-by: Saul Wold

rootfs_rpm.bbclass: Handle multilib configures with different OS values

2013-02-22T14:32:44+00:00

[ CQID: WIND00404082 ]

It is possible for the TARGET_OS to change dependending on the multilib used
for a given package build.  mips64 has two potential TARGET_OS values: linux
and linux-gnun32.  The RPM and Smart setup needs to distinguish between the
two otherwise packages of the "non-default" TARGET_OS may be ignored as
incompatible.

Signed-off-by: Mark Hatle 
Signed-off-by: Richard Purdie

rootfs_rpm.bbclass: Reorder feed priority based on multilib image setting

2013-02-22T14:09:14+00:00

[ YOCTO #3915 ]
[ CQID: WIND00404309 ]

When doing a multilib image build, such as bitbake lib32-core-image-sato, the
system needs to reorder the priority level of the feeds.  If it does not
reorder the priorities, then 64-bit items can be selected by the automatic
dependency resolution in Smart.

Signed-off-by: Mark Hatle 
Signed-off-by: Saul Wold

rootfs_(ipk|deb|rpm).bbclass: check package installation status after ROOTFS_POSTPROCESS_COMMAND

2013-02-12T16:35:13+00:00

Since the intercept fall-back procedure will change the package
installation status, do the checking after ROOTFS_POSTPROCESS_COMMAND
ends.

Signed-off-by: Laurentiu Palcu 
Signed-off-by: Richard Purdie

rootfs_rpm: Escape the backtick to ensure the ls runs on the target

2013-01-29T23:51:49+00:00

This change ensures that the ls /etc/rpm-postinsts runs in the target
at first boot time, rather than at the creation time of the script on
the host.

This was causing the following error in the rootfs log:

+ install -d /srv/ssd/sgw/machines/fri2/tmp/work/fri2-poky-linux/core-image-minimal/1.0-r0/rootfs//etc/rcS.d
+ i=
+ ls /etc/rpm-postinsts/
ls: cannot access /etc/rpm-postinsts/: No such file or directory

Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

rootfs_rpm.bbclass: fix the unexpected postinst error

2013-01-22T15:54:26+00:00

If the /etc/rpm-postinsts/ directory was empty, the following error
would occur at system startup.

      ERROR: postinst /etc/rpm-postinsts/* failed

This patch fixes this issue.

[YOCTO #3767]

Signed-off-by: Chen Qi 
Signed-off-by: Richard Purdie

classes/rootfs_*: error out if postinstalls exist with read-only rootfs

2013-01-18T13:01:42+00:00

If there are postinstall scripts to be run on first boot and
IMAGE_FEATURES contains "read-only-rootfs", we know this will fail on
the target device so just error out during do_rootfs. This check was
already implemented for ipk, so add it to the deb and rpm backends. Also
make all backends use bberror rather than just echo to display the
error.

Fixes [YOCTO #3407].

Signed-off-by: Paul Eggleton 
Signed-off-by: Saul Wold