Similar to rpm, use copies of the ipk/deb directories for rootfs construction.
This means the image creation code can no longer "see" recipes wich aren't in its
dependency chain which is good for a variety of reasons including determinism,
incompatible recipe (e.g. systemd/sysvinit) package conflicts and locking
performance.
(From OE-Core rev: c7c5f4065c102fde4e11d138fb0b6e25bffe0379)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function is generic, tweak the variable names and move out the rpm specific
directory name to make it truly generic and reusable for deb/ipk.
(From OE-Core rev: dba876639b1fb8ea3ccb182c91e19966c4052115)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refactor the locale archive function from the SDK to also make it work during
general image creation. This reduces the size of the locales from 900MB to 220MB
in core-image-lsb-sdk.
The exception handling around subprocess was dropped as the standard subprocess
exception printing is better handled than the catchall exception.
(From OE-Core rev: 8ffd93bdb09b0a4a84b27dafcd684c6abba392ed)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Prefer collections.abc (new in Python 3.3) over collections for abstract base classes
- In Python 3.8, the abstract base classes in collections.abc will no longer be exposed in
the regular collections module. This will help create a clearer distinction between
the concrete classes and the abstract base classes."
- https://docs.python.org/3.7/whatsnew/3.7.html#deprecated
- see c66f9f8d39
(From OE-Core rev: e763151e1f7cfe9ea56de06f41769f8a3d74d219)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Executing strip action on kernel modules removes the signature.
Is not possible to strip and keep the signature, therefore avoid
strip signed kernel modules.
(From OE-Core rev: 4c47e5f171fa2603355e2f9183065ce8137a18c7)
Signed-off-by: Omar Ocampo <omar.ocampo.coronado@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch enables multiconfig dependencies (mcdepends) to be used on
recipes using the following format:
task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend-on"
For the sake of simplicity consider the following example:
Assuming we have set up multiconfig builds, one for qemux86 and one for
qemuarm, named x86 and arm respectively.
Adding the following line to an image recipe (core-image-sato):
do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs"
Would state that core-image-sato:do_image from x86 will depend on
core-image-minimal:do_rootfs from arm so it can be executed.
This patch makes modifications to bitbake.conf to enable mcdepends, and
to sstatesig and staging.bbclass to avoid conflicts between packages from
different multiconfigs.
[YOCTO #10681]
(From OE-Core rev: f71bfe833c657244d2fd07b3b71e86081d7d1c04)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The warn method is deprecated. We should use the documented warning instead.
Quoting from the python's official doc:
"""
Note: There is an obsolete method warn which is functionally identical to warning.
As warn is deprecated, please do not use it - use warning instead.
"""
(From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb)
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>
After this replacement, the parent exception handling works so we don't
need subprocess wrapping with bb.error in the underlying functions.
The underlying contexts also have better module handling so the imports
can be cleaned up.
(From OE-Core rev: aa8260adf53139d776a2affe6118d28b295c1fab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows the calls to is_elf (which calls file) to happen in parallel
allowing a speedup of do_package and do_populate_sysroot for native
recipes.
(From OE-Core rev: bbe0d3e26484f3f347262d40a8a9d415ce21fb43)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are probably further cleanups needed here but this at least removes
the major code duplication between these two similar funcitons, keeping the
kernel module ".ko" extension check for efficiency to avoid opening and
reading file contents in the general case.
(From OE-Core rev: 7ad0c0d6ab12bebeac097fc0f5210c876dcfe9be)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't need any functionality from the shell here, its just extra fork
overhead. Therefore remove it and use subprocess directly.
(From OE-Core rev: bcc03ea19e103f6aa93bada2f49fcc5cc7bc0790)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current methods of spawning processes for parallel execution have
issues around collection of results or exceptions.
Take the code from package_ipk/deb, make it generic, add a results
collection mechanism, fix the exception handling and for it into a
standard library function.
Also add a test case which tests both the success and failure modes
of operation to stop this functionality regressiing again.
In particular, compared to multiprocess_exec, this fork off the parent
approach means we can pass in the datastore and functions work in the
same scope as the parent. This removes some of the complexities
found trying to scale multiprocess_exec to wider use.
(From OE-Core rev: 88f0c214e593a45566df5131bda4c946f5ccc8c2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The FILELIST field of the package info file in the buildhistory
repository is a space-separated list of all of the files in the package.
If a name of a file packaged by a recipe contains a space character then
of course the result was that we didn't handle its name properly. To fix
that, use quotes around any filename containing spaces and at the other
end use these quotes to extract the proper entries.
Fixes [YOCTO #12742].
(From OE-Core rev: 801b705957dc683030d11393f43407d0b3506b6a)
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>
The original idea here was that changes to certain fields might be able
to be explained if there was a change to another field, for example if
RDEPENDS changed it might be because DEPENDS changed. Thus we were
printing this kind of thing out with each change. Unfortunately in
practice this turned out to be noisy and not particularly useful, so we
might as well remove it.
Fixes [YOCTO #7336].
(From OE-Core rev: 8658b3677b9f7cb70806061c41570c709086ef05)
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>
It is helpful when exclude a lot of layers. It uses python re, and
supports multiple patterns (separated by space).
(From OE-Core rev: b5170882feb0f3bc2dddc213b6d115dfa87b7cc1)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is better to return False for None. E.g. checking an undefined
variable returned d.getVar().
(From OE-Core rev: 3048e9fa0df6b1edf79bd1723e0fc022c3332af1)
Signed-off-by: Binghua Guan <freebendy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a function much like shutil.which or bb.utils.which, retaining
shutil.which-like function semantics, bb.utils.which's support for
returning available candidates for signatures, and most importantly,
supports wildcards, returning only the first occurrance of each found
pathname in the search path.
(From OE-Core rev: ca276fe139129eec383d77768ba91b808c462b04)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're in a multilib context already and want a non-multilib context
this function returned incorrect values.
Try and retain optimisations for the common case not needing to request
a datastore but allow the different multilib/non-multilib combinations
to work too.
This fixes bugs where rootfs generation of a multilib image would
write into incorrect locations, or be unable to find sstate manifest
files due to incorrect data stores being used to expand data.
(From OE-Core rev: af7cd7823a8cc95c9f849498b2416cdb0d4d103e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently this function assumes that no multilib is applied and that
we're applying a multilib. This means if we're in multilib context
and want the non-multilib context we can't obtain it (and no other
function exists for this either).
Improve the function to allow this to be requested.
(From OE-Core rev: 295c5a3d19834a2fac255346d0a373449cfdd776)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As of commit 2c5c6e3ff we create multilib variants of intercept
hooks but we did not account for delay_to_first_boot variants.
This was covered up until commit a335e7867, but will now cause
an error.
(From OE-Core rev: 77f7c75481dceec36b7373f277c3bac811de9ef2)
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Exception: TypeError: boolean accepts a string, not '<class 'bool'>
is a bit annoying if you pass in True/False. Tweak the function
to make it forgive that situation.
(From OE-Core rev: 147f5a665fe5073027d92e4acac631f15f08f79f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously a warning was printed regardless of context and nature
of the failure, and because it was only a warning, it was mostly ignored.
Now, the following is considered when a failure happens:
1) whether we are installing packages into a target image, or populating
a SDK with host or target packages.
2) whether the failure was due to qemu not supporting the target machine.
Accordingly, warnings, notes, and failures are printed, and postponing
to first boot happens if possible.
(From OE-Core rev: a335e78672b1e1ae3ea6427f6a805218e513bb52)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If package management is present opkg/dpkg will bring the original
copy of the postinsts scripts with the metadata and will be able to
handle postinsts just fine. In fact, it is preferred to let package
management handle the postinsts scripts in this case since it will
keep the package managers database up-to-date too. The run-postinsts
scripts will make sure the package manager gets invoked instead of
the scripts directly.
Note: Before commit 5aae19959a44 ("rootfs.py: Change logic to
unistall packages") rootfs.py did not install /etc/$pm-postinsts
too. It is not clear whether that change was intentionally or just
a bug. This commit fixes/reverts that aspect of the commit.
(From OE-Core rev: 4b571c59e3e6bd8b22a63f547a95757aeba5b638)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When generating the extended SDK, there is a copy step where this class
goes through the layers and other stuff that have been copied to
generate the SDK. The corebase; ie. the folder that contains the core
layer 'meta' is treated in a special way. Unfortunately in our tree, we
have:
sources/meta/meta
| `- core layer
`------- corebase
In populate_sdk_ext's copy_buildsystem, the heuristic to determine which
element of the list returned by copy_bitbake_and_layers is corebase is
fooled by such layout.
In copy_bitbake_and_layers, corebase is already handled specifically and
reliably, so we should let that function tell us which folder is
corebase instead of trying to determine it.
To do so, change the return type of copy_bitbake_and_layers to a tuple
that contains (corebase, copied_layers). It also simplifies the code on
the caller side.
(From OE-Core rev: 5368bc5d0d3606198b93e877bcafcd77bb5f4fd1)
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was undocumented, and it's better to just always enable
full debug output, as this allows immediate generation of logs
with full diagnostics when things go not as expected.
Also, change the output of dnf from note to debug level; this
does not affect what is written to log file, but does reduce the
verbosity of bitbake -v.
(From OE-Core rev: 9128fd1396729a71b4832a597cf070c2be922d63)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If package management has been disabled then we've already removed all the
state, and running 'dnf clean all' again will simply recreate a lot of the
files.
(From OE-Core rev: 4524068ad2248b37fb08a24828d018e2f7e6a761)
(From OE-Core rev: f23332dc6a0c5b49246b4d17ec4e6fcad0cb7d47)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If package management is disabled we remove the state and configuration for the
package manager after the rootfs has been populated. This list wasn't complete
and the DNF/RPM configuration files were left behind.
As we've added files to the list (and not just directories), expand the
backup/restore package management state code to handle this.
(From OE-Core rev: c8a6422457b4d29e6afd1e193b8b921287472137)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The isELF function works by running:
result = file <pathname>
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
(From OE-Core rev: 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously this wasn't done, and so any packages installed from
populate_sdk would not have the postinsts fully executed
(particularly generation of various caches via running nativesdk or target
binaries with qemu wasn't working).
[YOCTO #12630]
(From OE-Core rev: a484ff072eea3f47de2c3348048201249cefa46b)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows running the intercepts when creating SDKs, which previously
wasn't possible, as SDK code does not use the rootfs class, and calls
into PackageManager methods directly.
(From OE-Core rev: f830388c5e9125f385a42acd7365d1235967b57c)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow handling postinst_intercepts when populating SDKs (which
use PackageManager class directly, and do not utilize RootFS class).
(From OE-Core rev: 9454fd328040fd58c981d028a74fcf181bde8e89)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will be useful when also moving postinst_intercept handling to
package manager class from rootfs class.
(From OE-Core rev: a4cd69bdd5b9dfa1125887f4d9038d41996e39c7)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, RPM_SIGN_PACKAGES is not defined. Add gpgcheck=0 to
oe-remote-repo.repo file, otherwise dnf will complain during
install operation on target
Note, RPM_SIGN_PACKAGES is set only when you inherit sign_rpm explicitly
(From OE-Core rev: 002a71eaa7606828c399972d8fd35e19e7b71929)
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of assuming order has changed if no package has been added or
removed, loop through packages to check if order has changed. This will
prevent the script from falsely reporting "changed order" if a version
has increased.
Fixes [YOCTO #12334]
(From OE-Core rev: 77d701c5fb5961bd818810a4d4cb3a9bd2432fae)
Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* --no-signature saves unnecessary .patch modifications when executed on
host with different git version
* --no-numbered saves unnecessary .patch modifications when number of the
applied patches is changed (the number is still in the filename so the
order how they should be applied is still preserved)
* both options exist for very long time, I've tested them with git 1.9.1
from Ubuntu 14.04 and I'm quite sure they were available even in much
older releases, so there shouldn't be any issue on relatively new sanity
tested distros
(From OE-Core rev: ad76fa92c3a5be38962aff09df070ffd9756f777)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ignoring patch context increases the chances of patches being
applied incorrectly. Depending on what code is being patched, this can go
completely unnoticed and create subtle bugs, sometimes with security implications.
Please see here for a specific example:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
On the other hand, we cannot simply force all patch context to match exactly:
doing this would break a lot of recipes suddenly, across all layers.
So let's try a softer approach: issue a warning, and gently update
patches over a longer span of time. When most of the warnings are eliminated,
we can start enforcing a strict patch application policy.
I do understand that this patch creates a lot of warnings all of a sudden, however
I believe the problem does need to be addressed. All of oe-core recipes have their
context already fixed.
Sample warning:
WARNING: vulkan-1.0.61.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored).
Details:
Applying patch demos-Don-t-build-tri-or-cube.patch
patching file demos/CMakeLists.txt
Hunk #1 succeeded at 63 (offset 2 lines).
Hunk #2 succeeded at 76 with fuzz 1 (offset 2 lines).
[YOCTO #10450]
(From OE-Core rev: 5133fd46bccf14e21680f8d94e952914edccb113)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously this was done only for rpm packages; now also ipk/deb scriptlet
failures are reported.
In the future this will become a hard error, but it can't yet happen
due to the legacy 'exit 1' way of deferring scriptlet execution to first boot which
needs a deprecation period.
(From OE-Core rev: a36671faf6e0b7623185b0e22814a786d5444592)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Particularly, this was causing 'devtool modify' to erroneously add those
.orig files into commits. This was getting in the way, if the goal
was to amend/update those existing patches.
(From OE-Core rev: f4f3406c3bd9599d7a19275475d52bda4c42f2ab)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running bitbake -c populate_sdk <image_name>, it is expected that
packages matching SDKIMAGE_INSTALL_COMPLEMENTARY name mask (unless
declared in PACKAGE_EXCLUDE_COMPLEMENTARY) are installed to resulting
SDK. Underlying mechanism issues a package manager install call for set
of complementary packages. However the mechanism doesn't seem to inform
the user all too obviously in case the package manager command behind
install_complementary() method fails -- and since it is combined with
attempt_only=True option, user might end up wondering why several *-dev,
*-dbg packages are missing from resulting SDK.
Improve associated install() method behaviour in affected OpkgPM and
DpkgPM classes so that a problematic state of affairs becomes directly
obvious for bitbake user, resulting in shell output like:
WARNING: someimage-1.0-r0 do_populate_sdk: Unable to install packages.
Command '...' returned 1:
Collected errors:
* Solver encountered 1 problem(s):
* Problem 1/1:
* - package somepkg-dev-1.0-r0.x86 requires somepkg = 1.0-r0, but
none of the providers can be installed
*
* Solution 1:
* - allow deinstallation of someotherpkg-1.1-r1.x86
* - do not ask to install a package providing somepkg-dev
* Solution 2:
* - do not ask to install a package providing somepkg-dev
(From OE-Core rev: 2502bd591c37bf532d02dc6b37fc1e8b5224fb0a)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In cases when a package like qemu might have files with same names
in multiple directories, the rename logic might go wrong and create
multiple rename pair for a single directory.
Make sure that we process each rename pair once. Also, don't print
FILELIST as part of PKGSIZE to ensure that it gets printed only once
when reporting package changes.
Fixes [YOCTO #12559]
(From OE-Core rev: cff000c43d6e9a183911338951026dfbef88f838)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you have a package that does not generate a manifest due to using a
noexec rule, the package name should be printed so the problem can be
tracked down. With out the patch you get an error that makes it look
more like the package_manager is broken as shown below.
oe-core/meta/lib/oe/package_manager.py', lineno: 534, function: create_packages_dir
0530:
0531: for dep in rpmdeps:
0532: c = taskdepdata[dep][0]
0533: manifest, d2 = oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d, multilibs)
*** 0534: if not os.path.exists(manifest):
0535: continue
0536: with open(manifest, "r") as f:
0537: for l in f:
0538: l = l.strip()
File: '/usr/lib/python3.5/genericpath.py', lineno: 19, function: exists
0015:# This is false for dangling symbolic links on systems that support them.
0016:def exists(path):
0017: """Test whether a path exists. Returns False for broken symbolic links"""
0018: try:
*** 0019: os.stat(path)
0020: except OSError:
0021: return False
0022: return True
0023:
Exception: TypeError: stat: can't specify None for path argument
(From OE-Core rev: 21924fdba286e5962b1680601664dc0491527e25)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using glibc-locale to install locales only makes sense if we're using glibc.
(From OE-Core rev: 8fc80734053645fa893694dfe33ddaee99aa9a1a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
