We need to use 'purge' instead of 'remove' for debian package backend when
removing packages at rootfs time. This is because that 'remove' command for
'dpkg' and 'apt-get' does not remove configuration files.
(From OE-Core rev: 14e8d826c4a5231ef331d8064d150737fe3ed656)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometimes you do not want certain packages to be installed when
installing complementary packages, e.g. when using dev-pkgs in
IMAGE_FEATURES you may not want to install all packages from a
particular multilib. This introduces a new PACKAGE_EXCLUDE_COMPLEMENTARY
variable to allow specifying regexes to match packages to exclude.
(From OE-Core rev: d4fe8f639d87d5ff35e50d07d41d0c1e9f12c4e3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Use argparse instead of optparse for standardised help output, options
and a much cleaner code structure
* Look up pkgdata directory automatically so the user doesn't have to
specify it
* Use standard logging
NOTE: this does mean a slight change in syntax - if you do want to
specify the pkgdata directory (usually only necessary if you're calling
it from within the build process) you need to use the parameter -p (or
--pkgdata-dir) and specify this before the command, not after it.
Examples:
oe-pkgdata-util find-path /sbin/mke2fs
oe-pkgdata-util lookup-recipe libelf1
oe-pkgdata-util read-value PKGSIZE libc6
oe-pkgdata-util -p /home/user/oe/build/tmp/sysroots/qemux86-64/pkgdata read-value PKGSIZE libc6
(From OE-Core rev: 04dc571ac7c26f0dcf1a1fcd466482e22519998d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the leading -e when using dash which does not use -e with echo
(From OE-Core rev: 105280d58f7be50e5aee6a33ef1aa89dd6485cbf)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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:"
(From OE-Core rev: 0387d0957909a9977efd8b2008e4d1c6d81ceb2a)
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new terminal type that makes a new window in the running tmux
session instead of splitting the window. 80x25 is not enough to run
menuconfig inside a split window, so add the option to create a new
window instead.
Use the new window option by default when the split window would be
less than 19 lines high.
(From OE-Core rev: d7ef9e49b1c687279f6eb2c7abc32ff915714177)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Strictly speaking not all of these characters are operators, so reword
the message to describe them as separators. Also use the standard
"recipename: message" format.
(From OE-Core rev: 9e5da3e83f2a5d43620e07a31728b7427329d8f4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the current code, if we use debian package backend and enable
multilib support, the do_rootfs process would always fail with error
messages like below.
E: Unable to locate package packagegroup-core-boot
This patch fixes the above problem.
(From OE-Core rev: d140d556ae30b6dbd0ffce8882c3e22b17050820)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When resolving a patch, a new process of gnome-terminal
is created for every patch to be resolved, it "waits"
for the previous one to end, instead of launching
multiple windows at the same time.
[YOCTO #7254]
(From OE-Core rev: b457e0b028418260aee25858b8af8938dd038fac)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: ca641aedff5f6bd155796ead02cb2eb871f8c17a)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An invalid value in IMAGE_FSTYPES was triggering a traceback. Add a
check and a reasonable error message instead.
(From OE-Core rev: f38c35b925d6eab0d5a41b8592b0eb8b0a3b7b72)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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].
(From OE-Core rev: b198a189228648057c3be7d068598f50841b3bf9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename it to _uninstall_unneeded.
(From OE-Core rev: cb217f442b8143d88112bebe4011051efbd905a3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 6cccae3ca54c1177a1d91d23c3e151d74e735ee9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the rpm package backend enabled, running:
bitbake <image>
bitbake virtual/kernel -c clean
bitbake <image> -c rootfs -f
results in an image with incorrect kernel module dependency information.
The problem is that the System.map and kernel-abiversion files are needed
for depmod and after the recent kernel changes, these are no longer in
sstate.
Its reasonable to require the kernel to unpack/build if you're
about to build a module against it. It is not reasonable to require this
just to build a rootfs.
Therefore stash the needed files specifically for depmod.
Also fix some STAGING_KERNEL_DIR references which were incorrect, found
whilst sorting through his change.
(From OE-Core rev: b851504dcf5e147c9efb1c7b6a4d22c1a1a87cd7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Normally, strip preserves hardlinks which in the case of the way our hardlink
rather than copy functionality works, is a disadvantage and leads to non-deterministic
builds. This adds a move into place after the strip operation to ensure hardlinks
are broken and we bring back build determinism.
(From OE-Core rev: 7c0fd561bad0250a00cef63e3d787573112a59cf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Creating an SDK by means of do_populate_sdk, complementary packages
(SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs") are not installed when using
the deb packaging system.
The reason is that the call to install the complementary packages is missing
from the deb backend. This patch fixes that.
[YOCTO #7160]
(From OE-Core rev: 0bcca69ea97ac51acf290f8f1da1bde715ab51c4)
(From OE-Core rev: 6755935e58b0414870adb7c7abab1aa331596209)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the changes to kernel layout, we need to refer to the correct
location of the kernel abiversion file.
Thanks to Saul, Randy, Darren and Bruce to figuring out the issue.
(From OE-Core rev: 6541799c2e9a5a1586676c207d62f885c70e24dc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When computing the dependency graph for the image generation, we need
to take into account the compression type and identify the base type
it relates to. This allow for a more robust graph generation even when
using composed image types.
(From OE-Core rev: 6e7d1de6cc99ed2def346dc40310573f5f0ce5ca)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a module to help provide utility functions for dealing with recipes.
This would typically be used by external tools.
Substantial portions of this module were borrowed from the OE Layer
index code; other functions originally contributed by
Markus Lehtonen <markus.lehtonen@intel.com>.
(From OE-Core rev: fd970c3b42b39601f379300d83354d42d5a536ba)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When patches from a recipe have been written out to a git tree, we also
want to be able to do the reverse so we can update the patches next to
the recipe. This is implemented by adding a comment to each commit
message (using git hooks) which we can extract later on.
(From OE-Core rev: 765b7bad50eae5b79d13a3f4988dc440c3d9787f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't do this, you may still be in the git am resolution mode at
the end of applying patches, which is not desirable.
(From OE-Core rev: 630a393d01950a0d00b5d30ac376472911e50ff9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Preserving carriage returns is important where the patch contains them.
(From OE-Core rev: 1cfcae0cd0bc776f5bb91a75bb8ffdad3d7bf200)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When PATCHTOOL = "git", if we're not able to use "git am" to apply a
patch and fall back to "git apply" or "patch", it is desirable to
actually commit the changes, attempting to preserve (and interpret) the
patch header as part of the commit message if present. As a bonus, the
code for extracting the commit message is callable externally in case it
is useful elsewhere.
(From OE-Core rev: 8c522846093809a8deb866079e73fa317266c80e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When PATCHTOOL = "git", git apply doesn't support fuzzy application, so
if a patch requires that it's better to be able to apply it rather than
just failing.
(From OE-Core rev: a8143f33d3104adcd10968e3b05df2024e723f5a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows us to use this function elsewhere in the code.
(From OE-Core rev: 657cff8a0f0e5db171b2ed9388a790ee0b135842)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multiple arguments to string formats need to be in a tuple.
Reported by Lorenz <lqb.list@gmail.com>.
(From OE-Core rev: e30a4650beabac215b6d867070b7acdb3601a4d7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While invoking create_index failed, there was no error output
and didn't break the build until the package installation.
...
|ERROR: run-postinsts not found in the base feeds (qemux86 i586 x86
noarch any all).
...
The reason is we used multiprocessing to execute create_index, and
did not check its invoking result.
(From OE-Core rev: d8921e4ea68647dfcf02ae046c9e09bf59f3e6e4)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a BSP supports two or more multilibs, for example:
MULTILIBS = "multilib:lib32 multilib:lib64"
and a variable is already extended to include multilib variants,
for example in populate_sdk_base:
commit 396371588c7fd2d691ca9c39cd02287e43cb665b
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Thu Jul 24 22:09:09 2014 +0100
populate_sdk_base: Extend TOOLCHAIN_TARGET_TASK to include multilib variants
Most people expect the toolchain from a multilib build to contain multilib
components. This change makes that happen and is easy for users to override
should they want something different.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The mapping clsextend.map_depends_variable("TOOLCHAIN_TARGET_TASK")
ends up with a wrong double extended package name like:
lib32-lib64-packagegroup-core-standalone-sdk-target
This patch avoid such issues.
(From OE-Core rev: c4e9b2aa894d59fe951038b3b73795b6891df70a)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
DpkgPM change all_arch_list variable set from PACKAGE_ARCHS to passed
archs variable because is different when is executed from rootfs.py
and sdk.py.
Credits to: Ricardo Ribalda <ricardo.ribalda@gmail.com>
(From OE-Core rev: f6fb8c16f49fd9a2b124ad55f5c4fed82d7e6dca)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Writes build information to target filesystem on /etc/build such as enabled
layers, their current status and commit.
squashspaces was moved to oe/utils.py to make it available to different classes
and avoid code duplication.
[YOCTO #6770]
(From OE-Core rev: c9cc652e88ddedddf8a2f23fb9b8c024616526d7)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The fix filters out irrelevant messages, and makes the catching more
accurate, the inner warn message in do_rootfs usually comes from the
output of complementary install, and pattern the format to catch it.
Here is the example of irrelevant messages:
...
|WARNING: log_check: There is a warn message in the logfile
|WARNING: log_check: Matched keyword: [warn]
|WARNING: log_check: `tmp/deploy/rpm/core2_64/pam-plugin-warn
-1.1.6-r5.0.core2_64.rpm' -> `tmp/work/intel_x86_64-wrs-linux/
wrlinux-image-installer/1.0-r0/rootfs/Packages.intel/./core2_64/
pam-plugin-warn-1.1.6-r5.0.core2_64.rpm'
...
(From OE-Core rev: 4ceb3b5f928af7f631294c83b83e3a3c89cbf890)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In package_manager.py, when using opkg as the packager, the command 'opkg <args>
info <pkg>' is called to get information about each pkg in BAD_RECOMMENDATIONS
in a format that can be written to the status file. The 'Status: ...' line is
modified and all other lines are passed through. Changing the verbosity level
argument for this command will change what it written into the status file.
Crucially, with the default verbosity level, no blank lines are being printed by
the opkg command and so no blank lines are being written to the status file to
separate each package entry.
The package parsing code in opkg expects package entries in the status file to
be separated by at least one blank line. If no blank line is seen, the next
package entry is interpreted as a continuation of the last package entry, but
the new values overwrite the old values.
So with the default verbosity level, a blank line follows some package entries
and these are parsed. The others are dropped due to the lack of blank lines. As
the verbosity increases, more debugging messages add blank lines and more
packages are parsed.
The solution to ensure that this works correctly regardless of the verbosity
level is simply add a blank line after the output of 'opkg info' is written to
the status file, ensuring that the next package is separated from the current
package.
[YOCTO #6816]
(From OE-Core rev: 3fa24eee41c26fecd5e4f680082288ec772d2de9)
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
Cc: Chris Carr <chris.carr@ge.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...
In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32'
is used to process multilib image/toolchain. But for the build of lib32-
meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is
deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...
|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|# set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|# "x86"
|# del data_smart.py:406 [finalize]
|# ""
|# pre-expansion value:
|# "None"
...
The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted
it at DataSmart.finalize
...
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Tue May 31 23:52:50 2011 +0100
bitbake/data_smart: Change overrides behaviour to remove
expanded variables from the datastore
...
We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the
value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.
For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib
-lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>
[YOCTO #6842]
(From OE-Core rev: 9c59d3d8b538d3a98ff4b5e5b189a4a23a85da2d)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The graph sorting algorithm for image dependencies does a look for an
occurrence of a searched string instead of comparing the chunk to the
searched string. This leads to the problem that ubifs is recognized as ubi aswell.
This fixes this by splitting up the string into chunks.
(From OE-Core rev: cec9725c540c2d54c27092e40d159694cea75b5f)
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The do_rootfs takes a very long time when build host has mounted many NFS
devices. syscall lstat() was being called on every filesystem mounted on the
build host during building.
The reason for the lstat() is that rpm is verifying that enough free disk space
is available to do the install. However, since the install is into the target
rootfs it should not matter how much free space there is in the host mounts.
Add checking for "rpm-ignoresize", by it, smart can make whether RPM skip
checking for diskspace when install a rpm package.
(From OE-Core rev: fc0668a019eca422540ceab3efcd2b2a27dd79e0)
Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake meta-toolchain
ls tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-i586-toolchain-1.7.manifest -al
...
|-rw-rw-r-- 1 root root 0 Oct 10 15:05 tmp/deploy/sdk/poky-glibc-x86_64-
meta-toolchain-i586-toolchain-1.7.manifest
...
The manifest is empty, the reason is target's ipk config path is
d.getVar('IPKGCONF_TARGET') rather than d.getVar('IPKGCONF_Target')
(From OE-Core rev: 81b3cc448f040dcb4c2f2b05983231ac53270663)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Package Manager implementation for deb didn't
take a look about multilib enabled variants.
Changes are made for generate apt.conf, sources.list and
debian repo index Release and Packages files.
[YOCTO #1502]
(From OE-Core rev: b5fb879b351cc23977f3e441f758101551297566)
Signed-off-by: Anibal Limon <anibal.ezau.limon.belmares@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Package managements (smart/apt-get/opkg-cl) generate some warn messages
to stdout, and we need to catch them and output by bb.warn.
Here is an example, while invoking smart to attempt install doc packages,
if install failed, it generates warn message to stdout.
...
|warning: Can't install util-linux-doc-2.24.2-r1@i586: Can't
install util-linux-doc-2.24.2-r1@i586: no package provides info
...
The fix catches it and outputs:
...
|WARNING: log_check: There is a warn message in the logfile
|WARNING: log_check: Matched keyword: [warn]
|WARNING: log_check: warning: Can't install util-linux-doc-2.24.2-r1@
i586: Can't install util-linux-doc-2.24.2-r1@i586: no package provides
info
...
(From OE-Core rev: f8d725f49f2be4b854f523a5ee3a5c4357e67e30)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Require a sig file which SIGGEN_LOCKEDSIGS_i586 is not null, but
the actual SIGGEN_LOCKEDSIGS_i586 is null.
Invoking 'bitbake -e' and we got:
...
3935 # $SIGGEN_LOCKEDSIGS_i586 [2 operations]
3936 # set /path/to/locked-sigs.inc:8576
3938 # del data_smart.py:406 [finalize]
3939 # ""
...
It was caused by the following commit:
...
(Bitbake rev: 899d45b90061eb3cf3e71029072eee42cd80930c)
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Tue May 31 23:52:50 2011 +0100
bitbake/data_smart: Change overrides behaviour to remove expanded
variables from the datastore
...
We add prefix 't-' to type to workaround the overrides behaviour.
(From OE-Core rev: f6a39cc957bf85ff43513f0b76afc3b2c9c906b6)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using underscores in the "types" parts of the variable names can cause
unexpected issues with overrides. For example, if you have both
SSTATE_LOCKEDSIGS_x86_64 and SSTATE_LOCKEDSIGS_x86_64_i586, and i586
is in OVERRIDES, then you lose all of the contents in
SSTATE_LOCKEDSIGS_x86_64 and thus don't get some of the locked sstate.
Using '-'s in the variable names instead, eliminates these issues.
(From OE-Core rev: 6662c412a949a9f6b602c848e6303b19db7e5272)
(From OE-Core rev: 65f558a6f762fb13224091dc22903b58eeb9b392)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add code in the sstate hash validation code to ensure it really did
install these from sstate since if it didn't should to warn/abort
the build. The judgment condition is:
1) If a build is replaced by locked sstate-cache, it will triger a
warn/error;
2) If objects are not used from the locked cache, it will triger a
warn/error;
3) Use SIGGEN_LOCKEDSIGS_CHECK_LEVEL variable controls whether this
is just a warning or a fatal error or nothing to report.
[YOCTO #6639]
(From OE-Core rev: 305912dce61c4fed0cbf631aa98a9e6f29db88e4)
(From OE-Core rev: 1683815695f39d4bad352348913f927ac8a1bcf5)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of a single monolithic SIGGEN_LOCKEDSIGS, split this into
separate variables, one per sstate package architecture. Add in
a new SIGGEN_LOCKEDSIGS_TYPES variable which lists the package
architectures to load in.
SIGGEN_LOCKEDSIGS_TYPES is made machine specific using overrides.
Also sort the hashes in the lists by PN to make diffing them easier.
(From OE-Core rev: d8b0ce35981931a39e7db9d8e78de6e009b34688)
(From OE-Core rev: b42f305ce38b9e0f1a2b7cb9586bbabcd2d27429)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I've been giving things some thought, specifically why sstate doesn't
get used more and why we have people requesting external toolchains. I'm
guessing the issue is that people don't like how often sstate can change
and the lack of an easy way to lock it down.
Locking it down is actually quite easy so patch implements some basics
of how you can do this (for example to a specific toolchain). With an
addition like this to local.conf (or wherever):
SIGGEN_LOCKEDSIGS = "\
gcc-cross:do_populate_sysroot:a8d91b35b98e1494957a2ddaf4598956 \
eglibc:do_populate_sysroot:13e8c68553dc61f9d67564f13b9b2d67 \
eglibc:do_packagedata:bfca0db1782c719d373f8636282596ee \
gcc-cross:do_packagedata:4b601ff4f67601395ee49c46701122f6 \
"
the code at the end of the email will force the hashes to those values
for the recipes mentioned. The system would then find and use those
specific objects from the sstate cache instead of trying to build
anything.
Obviously this is a little simplistic, you might need to put an override
against this to only apply those revisions for a specific architecture
for example. You'd also probably want to put code in the sstate hash
validation code to ensure it really did install these from sstate since
if it didn't you'd want to abort the build.
This patch also implements support to add to bitbake -S which dumps the
locked sstate checksums for each task into a ready prepared include file
locked-sigs.inc (currently placed into cwd). There is a function,
bb.parse.siggen.dump_lockedsigs() which can be called to trigger the
same functionality from task space.
A warning is added to sstate.bbclass through a call back into the siggen
class to warn if objects are not used from the locked cache. The
SIGGEN_ENFORCE_LOCKEDSIGS variable controls whether this is just a warning
or a fatal error.
A script is provided to generate sstate directory from a locked-sigs file.
(From OE-Core rev: 7e14784f2493a19c6bfe3ec3f05a5cf9797a2f22)
(From OE-Core rev: 884d4fa3e77cf32836f14a113c11489076f4a84d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use RPM_PREFER_ELF_ARCH to instead of RPM_PREFER_COLOR as rpm upstream
suggested, and use "4" to instead of "3" since it is a bit mask (not
enumeration), so we need "4" here.
(From OE-Core rev: 8dcfa7143a6690455c3bd5772621f142f2d9e559)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do not set the rpm_version to 5 if it is not provided, instead
determine the real rpm version.
(From OE-Core rev: 48beaee2e5b2b4ae35c596c19f8a38e0ff4427e9)
(From OE-Core rev: fe4ad726d0dc63be73f885598e216b8eb927668a)
Signed-off-by: Kévin THIERRY <kevin.thierry@open.eurogiciel.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the package manager code only supports rpm v5. To be useful outside
of OE or with OE layers using v4, it makes sense to add in rpm v4 support. This
takes a patch from "Bartosh, Eduard" <eduard.bartosh@intel.com> and enhances
it to also include versions of the workarounds from poky-eurogiciel to
allow rpm v4 usage with the class for image construction.
(From OE-Core rev: fe21804c296bbb8b2b8b0c29e6e4890bc17f07fc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added --quiet option to smart command line.
Without this option smart 1.4.1 turns into interactive mode, i.e.
start asking questions and expecting answers.
Internally within smart, this changes the default UI to one which
just prints to stderr, the naming of the parameter is a little
odd but does what we need.
(From OE-Core rev: 7a8d88b73d35ac86198a1092c49b33c378416a03)
Signed-off-by: Ed Bartosh <eduard.bartosh@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable "results" was accidentally used for multiple different
things at the same time, which unintentionally discarded anything that
was supposed to be returned from the function...
(From OE-Core rev: abf4eb613eba0892a5f240de7aa3a9a1b2879354)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of squashing packagegroup dependencies was to avoid allarch
packages rebuilding upon tune/arch changes. Now that the allarch class
inclusion is conditional, we can narrow down the packagegroup squashing
to be specifically applied to allarch recipes.
(From OE-Core rev: bd8018792155ae842952432900c8431feeaffe30)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our usage of multitprocessing is problematic. In particular, there is a bug
in python 2.7 multiprocessing where signals are not handled until command
completion instead of immediately.
This factors the multiprocess code into a function which is enhanced with
a workaround to ensure immediate signal handling and also better SIGINT
handling which should happen in the parent, not the children to ensure
clean exits. The workaround for the signals is being added to the core
bb.utils function so it can benefit all users.
package_manager is then converted to use the new code.
(From OE-Core rev: 72d153a3a90d31d9f4e41d77da24e44ccb33c56e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was iterating over the variable character-by-character rather than
word-by-word.
(From OE-Core rev: 207f2cc0b0fc53b22e1dedfa26905ab143fb0de6)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using the RPM packaging backend to generate a rootfs there needs to
be a way to configure the preferred ABI to resolve ELF file conflicts.
Currently RPM resolves ELF file conflicts with the last-installed wins.
Using SMART it's difficult to know what the last installed will be.
There are three specific policies that can be selected:
1: ELF32 wins
2: ELF64 wins
3: ELF64 N32 wins (mips64 or mips64el only)
Another option "0" is uncontrollable, which means that if two are being
installed at once Elf64 is preferred, but if they're being installed in
two different transactions, last in wins, so we don't document it.
Add RPM_PREFER_COLOR to let the user config the preferred ABI.
[YOCTO #4073]
(From OE-Core rev: f56d7be2c35cedcd763ba66913982aa4c425d561)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Variables like RDEPENDS can contain EXTENDPKGV which in turn uses AUTOPR
based values. This gets set during do_package execution so we want to
defer expansion until then. The only way we can do this in the RDEPENDS
(and friends) mapping code is to subsitute a dummy value, then change it
back again. Horrible but I can't see any other way.
This resolves multilib build failures with inconsistent PR values.
(From OE-Core rev: 5aea553e6eaa3b9647f26944976d2a9da79cba42)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added base variables and package backend specific variables to
rootfs[vardeps] in order for rootfs to rebuild when changes are made.
Set some variables as [func] to inform bitbake that they are shell
scripts, so that it invokes its shell dependency parsing. Without
marking them as functions, changes in the actual function body would
not trigger rootfs rebuilds.
[YOCTO #6502]
(From OE-Core rev: b8b6214b885a0757f0e628937f8fe21c92c45155)
Signed-off-by: Roxana Ciobanu <roxana.ciobanu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The /install/tmp diectory is created during installation by
the smart package manager, we need to clean it up here
[YOCTO #6497]
(From OE-Core rev: d4f4ad5edd8914e696722c1a1c3ba7de091d4c19)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Check the rootfs size against IMAGE_ROOTFS_MAXSIZE (if set)
* Add comments for IMAGE_ROOTFS_SIZE to not confuse with IMAGE_ROOTFS_MAXSIZE
[YOCTO #2610]
(From OE-Core rev: 6acd4fc8d5e642b5c6c75fcc40dd8f37caf7ddcf)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For the meta-mingw layer, we need to process alternative SDK_OS, since this
is not a Linux based OS.
(From OE-Core rev: b31e015d2e379c24610948d345c5970545887468)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable was only partially implemented, and the part that was there
was named incorrectly to, missing the 'TASK' piece.
(From OE-Core rev: d0cb34cfe9a51fd8bc1e6e28c8eda60a25adc1ec)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its possible sstate symlinks to other sstate mirrors which then my get
removed/cleaned. If we find invalid symlinks, skip over them rather
than error with a backtrace.
(From OE-Core rev: 5ed9bb42abf93aa084dd23ca68cc996a94a51a10)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, if we have 'package-management' and 'read-only-rootfs'
both in IMAGE_FEATRUES, we would meet the following error at system
start-up.
rm: can't remove '/etc/rcS.d/S99run-postinsts': Read-only file system
However, what's really expected is that when there's no postinstall
script at system start-up, the /etc/rcS.d/S99run-postinsts should not
even be there.
Whether or not to remove the init script symlinks to run-postinsts should
not depend on whether we have 'package-management' in IMAGE_FEATURES; rather,
it should only depend on whether we have any postinstall script left to run
at system start-up.
This patch changes the _uninstall_unneeded function based on the logic
stated above.
[YOCTO #6257]
(From OE-Core rev: 6c2f7ecee754ff3f29fdde17c0363f5d138057ff)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multilib builds only require one crosssdk toolchain. We therefore shouldn't
be remapping crosssdk names. This resolves build failures looking for
weird multilib crosssdk toolchains.
(From OE-Core rev: aa8b93e2db06866529d20939452f81fb9e18aaab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to use the saferecipedeps handling code to allow gcc-cross-* to
work on multiple different tunes. Its currently in target only code
so it needs to be earlier to allow it to work on native-> target
dependencies.
This change has no effect on existing uses but makes gcc-cross become
shared as desired.
(From OE-Core rev: 9e03db2dfab0b534b86fd48c9190b2d7d0d21238)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the renaming of the cross packages, its no longer possible to use
endswith("-cross") and similar to detect cross packages. Replace these
references with other techniques.
This resolves certain build from sstate failures which were due to the
system believing cross packages were target packages and therefore
dependency handling was altered.
(From OE-Core rev: 91edf4cac223298e50a4b8e59dd19f1b272e3418)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BitBake has the exact same code as oe.utils.contains so there's no
reason to duplicate it. We now rely on the bb.utils.contains code for
metadata.
(From OE-Core rev: 93499ebc46547f5bf6dcecd5a786ead9f726de28)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xfce terminal was renamed 'Terminal' -> 'xfce4-teminal' mainline end of 2012,
so the distros supporting 'Terminal' will dissapear. The distros not
mentionied in __init__ do (e.g fedora 19 - tested) fail - or will fail
sooner or later.
(From OE-Core rev: d07f3812ec371da6f18fa1dd920cdde470bd89ad)
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since commit a83144bac8d67704ff66f5dc0fc56f5b63979694 (2014-02-11), USE_DEVFS is not considered anymore.
For compatibility, let's restore USE_DEVFS semantic.
Also add USE_DEVFS to documentation.conf.
(From OE-Core rev: d12a5e38a02abe3feb3db8ae5ffd9a5005124294)
Signed-off-by: Matthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a nasty sstate hash corruption issue occurring where the
fact the testimage bbclass was inherited meant that the checksum
changed due to testimage.bbclass being confused with image.bbclass.
This patch anchors the bbclass names to avoid this confusion.
(From OE-Core rev: 943a75a4f3b6877e4092dae14b59b7afef8cad3d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When RM_OLD_IMAGE = "1", we delete old images but we didn't check they
actually exist...
[YOCTO #6029]
(From OE-Core rev: 8910d3cc94899ab4d509e681b438ae96218fa777)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit adds a new _cleanup() internal method that will be called at
the end of rootfs creation, so that each backend can delete various
files that were probably generated during rootfs postprocess execution,
etc.
[YOCTO #6049]
(From OE-Core rev: 6151d69875f3f4f097b6e2fdef2a0f3ab391e2fd)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do not delete the __db.00* files in the PackageManager class. Leave this
operation up to the client classes. One side effect of this deletion was
the following message appearing in the output of the next rpm command
executed:
rpmdb: BDB1540 configured environment flags incompatible with existing
environment
We might also gain some time here by not deleting/creating those files
very often.
[YOCTO #6049]
(From OE-Core rev: 12e300f0af2a27c15d80298d3fbb27b092c35154)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The native sysroot should not be used as a store for the lists files since
multiple images running at once would conflict over this. Instead redirect
this to WORKDIR. This means some extra directories need to be created.
Also create apt.conf.d to silence some warnings.
(From OE-Core rev: dc4abfc8f99c08e0c1ac9d098ce17838d0eda028)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
a) There were missing parameters to the release and package commands (".")
b) The commands need to be executed as one block since they build upon each other
(From OE-Core rev: a3965b76ed4361455c89c982761263be03e1a8e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Processing directories twice is both pointless and introduces a race condition.
When building the list, ensure duplicates (like "all" and "noarch") are handled
correctly.
(From OE-Core rev: 4c487543422ae471a01a573bab44e3f6a6d2497a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we created a new PkgsList object that will deal with listing the
installed packages in a rootfs, use the new class both for images and
SDKs in the wrapper functions.
The old list_installed_packages() wrapper listed only the packages inside
an image rootfs. It didn't deal with target/host SDK rootfs's.
(From OE-Core rev: 8fc18e67504db5b6df3fdd239c6187a71af52656)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit creates a new class that has the only purpose to generate
various listings of installed packages in the rootfs.
Basically, the methods involved in listing the installed packages, that
were part of each backend PM class implementation, were moved to this
new class.
This change avoids instantiating a new PM object just to get the list of
installed packages in a certain rootfs.
(From OE-Core rev: a7290ed13378826723d1edc7e828eab848eaad10)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use apt-ftparchive to create a Release file compatible with SecureApt.
apt-ftparchive is also a more efficient replacement of
dpkg-scanpackages:
root@neopili:~/curro/qtec/qt5022/build-qt5022-cesium/build/tmp/deploy/deb/bobcat
_64# time PSEUDO_UNLOAD=1 apt-ftparchive packages . >/tmp/kkk
real 0m26.873s
user 0m20.968s
sys 0m1.212s
root@neopili:~/curro/qtec/qt5022/build-qt5022-cesium/build/tmp/deploy/deb/bobcat
_64# time PSEUDO_UNLOAD=1 dpkg-scanpackages . >/tmp/kkk
dpkg-scanpackages: info: Wrote 6022 entries to output Packages file.
real 0m59.721s
user 0m16.668s
sys 0m11.164s
apt-ftparchive is not compatible with libpseudo. The calls to ftw()
returns the path in absolute format instead of relative. This
produces
wrong Packages and Release files.
ie:
MD5Sum:
d20227a958f6870137ce0e41b7b84307 1453
/home/ricardo/curro/qtec/qt5022/build-qt5022-cesium/build/tmp/deploy/deb/all/Release
This is why it is called with PSEUDO_UNLOAD.
(From OE-Core rev: c9899a7605f15f7f1ae30c4624d53c7da825b00a)
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will let folks extend the oe package with modules from other layers.
Given openembedded consists of more than just oe-core, I think this makes
sense, and adds some useful flexibility.
(From OE-Core rev: 8dfd28925fc47d8a4a1f10ec65df665c8326edc4)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding a common interface to add predefined package manager
channels to prebuilt rootfs:es.
Adding PACKAGE_FEED_URIS = "http://myre.po/repo/, will
assume repo directories named (rpm,ipk,deb) as subdirectories
and statically add them to the rootfs, using the same PKG_ARCHs
as the build which produced the images.
Tested with RPM, IPK and DEB.
deb feed functionality seem broken, is anyone using this ?
(From OE-Core rev: 9b8811045546ad67b4695d980f09636d5506e50c)
Signed-off-by: David Nyström <david.c.nystrom@gmail.com>
Signed-off-by: David Nyström <david.nystrom@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* I've noticed errors like this in log.do_package:
DEBUG: Executing python function package_do_filedeps
sh: 1: Syntax error: "(" unexpected
sh: 1: Syntax error: "(" unexpected
DEBUG: Python function package_do_filedeps finished
which are actually caused by some filenames included in package
containing '()' characters
Maybe we should change meta/classes/package.bbclass to
fail when some filedeprunner call fails like this and fix
filedeprunner to escape '()' and other possibly dangerous chars
it's called like this:
processed = list(pool.imap(oe.package.filedeprunner, pkglist))
* don't use shell=True
* show the command when it fails and let do_package task to fail
(From OE-Core rev: 148c04c1bf39ca0d21288fdce61c51dc8e1c3226)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As we now require Python 2.7 and os.path.relpath() was added in 2.6 we can now
drop the reimplementation in oe.path.
oe.path.relative is simple now a wrapper that changes the order of the arguments
and it's use discouraged.
(From OE-Core rev: 1a03cd16401d2926bba902ffc5df30911b5c9394)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a command executed with subprocess.check_output() fails, the
subprocess.CalledProcessError.output contains only STDOUT and the user
needs to check the log.do_rootfs to see any other details.
This commit forwards stderr to stdout so that, in case of failure, the
entire error output will be displayed in terminal.
[YOCTO #5902]
(From OE-Core rev: 4661f1441429952f30e19cebd93dc42ce31fd868)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since tasks were renamed to packagegroups some time ago, this variable
name implies that its usage is necessarily related to them which is not
the case. Rename the variable to more closely represent what it does
(whilst still providing backwards-compatibility with a warning for
PACKAGE_GROUP).
(From OE-Core rev: d703e07ea5056624101e1bc48f10d25b602635e9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure the channel was not already added, before attempting to add.
[YOCTO #5890]
(From OE-Core rev: 0574f5390fb8958db5864f41a7bd8037ac046ac5)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Converting a list to a set does not keep the order of the items, as they
were added, which might result in the wrong packages being installed in
the final image...
This reverts commit 12f47c23df.
[YOCTO #5890]
(From OE-Core rev: 495cce9c9e63484c740aa669facb995b0ef74f85)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous implementation was checking IMAGE_PKGTYPE and created the
index files just for the backend used to create the image. Apparently,
'bitbake package-index' should attempt to create the index files for all
backends specified in PACKAGE_CLASSES.
[YOCTO #5827]
(From OE-Core rev: 0521d48a1612bfc735e2c86acc9b685c1dc389ef)
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the output from opkg-query-helper.py is empty, output.split('\n')
would result in a list containing one element which is an empty string
while iterating over each line in the output. An exception is then
thrown by the line:
pkg, pkg_file, pkg_arch = line.split()
with the message:
Exception: ValueError: need more than 0 values to unpack
To avoid this, we add a condition to only split the output if it isn't
empty.
(From OE-Core rev: ee7b75c895e77ab20f728423c8efc2ced92265e8)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We shouldn't be running this if it expands to None or "" or False
so update the code accordingly.
(From OE-Core rev: 255079780729f0dd9df6f35302169e0c8480eced)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The import oe.package_manager line is redundant, let's remove it.
(From OE-Core rev: ade1f3ce34489bba5a7ab23793c1d82559150583)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The _multilib_sanity_test installs multilib packages in a temporary
root fs, and compare with the current image to figure out duplicated
files that come from different packages.
While incremental image generation enabled and the previous image
was existed, there was an Multilib check error:
...
ERROR: Multilib check error: duplicate files tmp/work/qemux86_64-poky-
linux/core-image-minimal/1.0-r0/multilib/lib32/lib/libc.so.6 tmp/work/
qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/lib/libc.so.6
is not the same
...
The reason is the file in the existing image has been prelinked by
previous image generation and the file in a temporary root fs is not
prelinked, even though both of them came from the same package, the
Multilib check failed.
[YOCTO #1894]
(From OE-Core rev: 8d813f614cdfda31c85bbaf133f2822f90a4a78a)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While incremental image generation enabled and the previous image is
existed, if BAD_RECOMMENDATIONS is changed, the operation on the
existing image is complicated, so remove the old image in this situation.
The same with PACKAGE_EXCLUDE and NO_RECOMMENDATIONS.
[YOCTO #1894]
(From OE-Core rev: 0566de3fa424af3bdfadcd0a08ce4c214abda083)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The incremental image generation is based on the previous existing
image, adds new packages, upgrades existing packages, and removes unused
packages.
[YOCTO #1894]
(From OE-Core rev: adf587e55c0f9bc74f0bef415273c937401baebb)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the following three functions to OpkgPM class:
- The 'dummy_install' is used to dummy install pkgs, and returns the log
of output;
- The 'backup_packaging_data' is used to back up the current opkg
database;
- The 'recover_packaging_data' is used to recover the opkg database
which backed up by the previous image creation;
Tweak 'remove' function in OpkgPM class, which the options for remove
with dependencies was incorrect.
Tweak 'handle_bad_recommendations' function in OpkgPM class:
- Fix none value check;
- Add the existance check of opkg status file;
[YOCTO #1894]
(From OE-Core rev: 5df18065e267a7e55a990ac3728414bb6e28a723)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Chen Qi
Paul Eggleton
Saul Wold
Ricardo Neri
Dan McGregor
Rodrigo Chiossi
Alejandro Hernandez
Richard Purdie
Pau Espin Pedrol
Otavio Salvador
Ross Burton
Hongxu Jia
Jackie Huang
Aníbal Limón
Paul Barker
Pascal Bach
Chong Lu
Anibal Limon
Randy Witt
Robert Yang
Kévin THIERRY
Ed Bartosh
Peter Kjellerstedt
Christopher Larson
Roxana Ciobanu
Mark Hatle
Ricardo Ribalda Delgado
Andreas Müller
Matthieu Crapet
Laurentiu Palcu
Christopher Larson
David Nyström
Martin Jansa
Jonathan Liu