pre-5.25.0 perl by default tries to link to an antiquated libnm (new
math) which is not used anymore since the early 1990's. After 2014
another libnm appeared for NetworkManager causing build failures.
(From OE-Core rev: 97d2ba227044571408151f84cfe611e1a72dd816)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refresh add-geometry-input-when-calibrating.patch to remove
bashism from it.
(From OE-Core rev: c0b8e1ff40af05b29780164c860c68da35e7fc32)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The preparation script itself prints out an error on failure, and we
aren't redirecting its output anymore, so we no longer need to print out
a message here when it fails. At the same time, make the message printed
out by the script a little clearer - we're just writing the log out to
the file, we shouldn't give the user an expectation that there will be
extra details in there (other than the output produced by
oe-init-build-env there won't be).
(From OE-Core rev: 80dfaf40e087b34d6360188df372c1c3805a00bd)
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>
Check a number of things as early as possible in the eSDK installer
script so that the user gets an error up front rather than waiting for
the build system to be extracted and then have the error produced:
* Check for missing utilities specified in SANITY_REQUIRED_UTILITIES
(along with gcc and g++), taking into account that some of these are
satisfied by buildtools which ships as part of the SDK. We use the
newly added capability to list an SDK's contents to allow us to see
exactly which binaries are inside the buildtools installer.
* Check that Python is available (since the buildtools installer's
relocate script is written in Python).
* Check that locale value set by the script is actually available
* Check that the install path is not on NFS
This does duplicate some of the checks in sanity.bbclass but it's
difficult to avoid that given that here they have to be written in shell
and there they are written in Python, as well as the fact that we only
need to run some of the checks here and not all (i.e. the ones that
relate to the host system or install path, and not those that check the
configuration or metadata). Given those issues and the fact that the
amount of code is fairly small I elected to just re-implement the checks
here.
Fixes [YOCTO #8657].
(From OE-Core rev: 6e6999a920b913ad9fdd2751100219c07cd14e54)
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>
Add a -l command-line option for SDK installers to get a list of files
that will be extracted by the SDK - internally this just runs "tar tv"
on the embedded tarball. This can be used to look at which files the SDK
provides without actually installing it. The initial user of this is the
extensible SDK build process which needs to know what binaries are going
to be installed by the buildtools installer without installing it.
(From OE-Core rev: 1d3e874f191f011eb9d7b0e12e513433c126036e)
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>
Determine the name of the current buildtools installer ahead of time,
set it in a variable and use that variable rather than the wildcarded
version everywhere, since it's much tidier.
(From OE-Core rev: d5a601db41ba3c561aced7f5a38689f6b4c9a87c)
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>
If the buildtools installation failed, we were using a subshell instead
of a compound command and thus the subshell exited but the script
continued on, which is really not what we want to happen. Additionally
log the buildtools installer output to a file and cat it if it fails so
that you can actually see what went wrong, as well as amending the
environment setup script to print a warning as we do when the
preparation fails.
(From OE-Core rev: 8fb8adf309823660c3943df973c216621a71850d)
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>
When we don't have uninative enabled there's more merging to be done in
the default configuration (SDK_EXT_TYPE = "full" which by default means
SDK_INCLUDE_TOOLCHAIN = "1") and there are likely files that already
exist in the sstate feed we're assembling, so we need to take care to
merge the directory contents rather than just moving the directories
over. Additionally we now only run this if uninative genuinely isn't
enabled (i.e. NATIVELSBSTRING is different to the fixed value of
"universal".)
In the process of fixing this I discovered an unusual behaviour in
os.rename() - when we're merging these feeds we're dealing with
hard-linked sstate artifacts, and whilst os.rename() is supposed to
silently overwrite an existing destination (permissions allowing), if
you have the source and destination as hardlinks to the same file then
the os.rename() call will just silently fail. As a result the code now
just checks if the destination exists and deletes the source if so
(since we know it will be the same file, we don't need to check in this
case.)
(From OE-Core rev: 2b5b920c6b4f4d5c243192aa75beff402fd704d3)
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>
A couple of fixes for the recent sstate filtering implemented in OE-Core
revision 4b7b48fcb9b39fccf8222650c2608325df2a4507:
* We shouldn't be deleting the downloads directory here, since it
contains the uninative tarball that we will need
* TMPDIR might not be named "tmp" - in OE-Core the default is tmp-glibc
so use the actual name of TMPDIR here instead.
(From OE-Core rev: 71ecd3bea680ef8c589257844512a14b65e979d3)
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>
If the build in which the eSDK is being built isn't using uninative,
this will have an effect on NATIVELSBSTRING, which will mean that the
eSDK installer won't be able to find any of the native sstate packages.
To keep things simple, under this scenario just disable uninative
temporarily while we run the SDK installer to help us check the presence
of the sstate artifacts we need. Ideally I'd rather not have things like
this that are artificial in this verification step, but on the other
hand this was the least ugly way to solve the problem.
(From OE-Core rev: 9f39deea7c4af5244dbfa824a52e11590a1d4df6)
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>
We were relying on uninative being enabled in the build in which the
eSDK was being produced, which is not the case for example for OE-Core's
default configuration. Move the code that copies the uninative tarball
and writes the checksum to copy_buildsystem so that it happens early
enough for that part of the configuration to be set up when we do the
filtering (which requires running bitbake).
(From OE-Core rev: 7bc95253098aca2ff195b159b34d9ac041806c75)
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>
If you set up a local mirror in SSTATE_MIRRORS then you can end up with
symlinks in SSTATE_DIR rather than real files. We don't want these
symlinks in the sstate-cache prodcued by gen-lockedsig-cache, so
dereference any symlinks before copying.
(From OE-Core rev: d65a6ee9e7a9c63b9a16bdb5025af8a7c6433c4f)
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>
If you check out OE-Core and then run oe-init-build-env you get an error
about not having bitbake checked out in a "bitbake" subdirectory,
however it's possible to specify the bitbake path on the
oe-init-build-env command line, so hint at that in the error message
rather than implying it has to be in the default location.
(From OE-Core rev: 5a1efa91a418e3206b047564d0fd6d5bac22a8d3)
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>
Removing the ccache directory as part of do_clean is unnecessarily
conservative and defeats many of the benefits of ccache.
The original justification for this behaviour was to avoid confusion
in the corner case that the ccache directory becomes corrupted.
However the standard approach for dealing with such highly unlikely
corner cases (ie manually removing tmp) would also recover from
corruption of the ccache directories, without the negative impact of
defeating ccache during normal development.
(From OE-Core rev: 6ae6680ad8d51eff756dcb6500fca2530e3e3e73)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch 0015-systemd-user-avoid-using-system-auth.patch
makes PAM session for systemd-user include common-account file
which doesn't contain any session related lines and that breaks
launching "systemd --user" with the error:
Jul 29 13:03:24 intel-corei7-64 systemd[691]: user@0.service: Failed
at step PAM spawning /lib/systemd/systemd: Operation not permitted
This change fixes the patch by including common-session file
instead.
(From OE-Core rev: ecff74ab68ffca27ed856be6117124b8bc1ef2d6)
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some eMMC devices show special sub-devices such as mmcblk0boot0
etc. The installation script currently pick all of them up and
displays it to the user which makes some confusions because these
sub-devices are pretty small and complete installation including
rootfs won't be possible in most cases.
We simply now drop these sub-devices and only present the user
with the root of such mmc devices.
(From OE-Core rev: 4b4d80306de8d8a2e3a2d784890f34e4a0ecfcf0)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If /bin/sh is a regular file (and not a symlink), we assume it's a
reasonable shell and allow it.
(From OE-Core rev: eaa0dc21a5f058a39bd7867bd3cafdb3407abe36)
Signed-off-by: Olof Johansson <olof.johansson@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the path to "ROOT_SYSCONFDIR /mke2fs.conf" has a permission denied problem,
then the get_dirlist() call will return EACCES. But the code in profile_init
will treat that as a fatal error and all executions will fail with:
Couldn't init profile successfully (error: 13).
But the problem should not really be visible for the target package as the path
then will be "/etc/mke2fs.conf", and it is not likely that a user have no
permission to read /etc.
(From OE-Core rev: 9d7c32a88e0670a09e5e1097ff8bca58e9a7943f)
Signed-off-by: Jian Liu <jian.liu@windriver.com>
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>
It can take a bit for USB devices to be detected, so if a USB device is
your rootfs and you don't set rootwait you will most likely get a kernel
panic. Fix this by adding rootwait to the kernel command line on
installation.
Fixes [YOCTO #9462].
(From OE-Core rev: 40e2d36573a7a6bce377b1f9653607065ba5ffb6)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds DROPBEAR_RSAKEY_ARGS and DROPBEAR_DSSKEY_ARGS optional
parameters to /etc/default/dropbear. The contents are simply passed to
the 'dropbearkey' program when generating a host key.
The default keysize for RSA is currently 2048 bits. It takes a CortexA9
running at 700MHz between 4 and 10 seconds to calculate a keypair. The
board boots Linux in about a second, but you have to wait for several
seconds because of the keypair generation. This patch allows one to put
the line DROPBEAR_RSAKEY_ARGS="-s 1024" into /etc/default/dropbear, and
have a host key generated in about 0.2 seconds on the same CPU. This is
particulary useful for read-only rootfs systems which generate a key on
each boot.
(From OE-Core rev: c0efbcb47ab37c2d9c298fcd40ecaadd3ca050a7)
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When live booting, we need to make sure the running udev processes are killed
to avoid unexepected behavior, we do this just before switching root,
once we do, a new udev process will be spawned from init and will take care
of whatever work was still missing
[YOCTO #9520]
(From OE-Core rev: e88d9e56952414e6214804f9b450c7106d04318d)
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>
By default the system will expand the extra os entries for uclibc and musl
even if they are not enabled in the build. There was no way to prevent this
behavior while still getting the expansion for things like x32 or spe.
The change adds a new setting which a distribution creator can override
easily, setting the base set of canadianextraos components. The other
expansions are then based on this setting.
(From OE-Core rev: ea24d69fdf7ebbd7f2d9811cff8a77bffc19a75c)
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>
Without this, we get to know the command failed and the exit code but
have no idea how the command failed since we don't get the output by
default.
This makes it much easier to see what went wrong and stand a chance of
fixing it.
(From OE-Core rev: b020b01d41ccaae5d679f1f7950af2e1a1788d39)
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 code gives tracebacks if there are no recipes to be built in a
BuildStarted event. Parse the list into a string rather than just taking the
first item. There is nothing special about the first time.
(From OE-Core rev: 684a3d56ef393b56f38d3272f8865f6225a282ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Uninative 1.2 didn't contain the nativesdk locale fix we really needed
to release and update to uninative 1.3 which does contain that fix
and also uses glibc 2.24 final release.
(From OE-Core rev: e0516960925e93f1801620897743b1cebcd806bc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10117]
Applied a re-write to better clarify the behavior of dependencies.
(Bitbake rev: 28bb8ef7f737034055f3485795179cfdcdb9a41f)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10095]
I added a third case to the "Conditional Metadata" section to
describe setting a variable for a single task.
(Bitbake rev: 24d648ce62b35f7d2b23fde732703c060579a0d2)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10093]
Provided much more detail on how these functions work.
(Bitbake rev: dbe25523d899850f85acb6986eca98bf1b0ef52a)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10071]
The use of any flags throughout the manual was very inconsistent.
I changed all references to any named flag in the text to be
formatted as code and to be enclosed in square brackets.
(Bitbake rev: be0fb616e64e54ae3e2420249f21f4edfd97d648)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10071]
Provided more clear descriptions for these two flags.
(Bitbake rev: c85c9a468dc3ce606a5f8797e6be8b411a9f3bdb)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's not a whole lot of point showing how many tasks are running when
we're in quiet mode, it just looks a bit strange particularly when it's
not running any tasks.
(Bitbake rev: 5317200d9cd73c6f971bc1b0cfe8692749e27e3a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we have the task number here we need to subtract 1 to get the number
of tasks completed.
(Bitbake rev: 7c78a1cd3f0638ae76f7c7a469b7f667c7c58090)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A couple of fixes for the "Initialising tasks" progress bar behaviour:
* Properly finish the progress bar when using bitbake -S
* Finish the progress bar before calling BB_HASHCHECK_FUNCTION (so that
in OE when that shows its own "Checking sstate mirror object
availability" progress bar it gets shown on the next line as it
should).
(Bitbake rev: de6759d8e9990e426e6d6464a2e05381cd4c12d6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CUPS ipptool URL we were checking now redirects to github where the tarball
isn't present, so remove it from the test suite.
(Bitbake rev: 4b50895fb3462b21e3874a2e99c363c8d05e89e6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The layer index update command has a special case for the
updating 'openembedded-core' layer, and it was missing reading
and updating the git web URL fields.
[YOCTO #8037]
(Bitbake rev: ce2f990a366d2d939e93e01f67688f12740c5fee)
Signed-off-by: David Reyna <david.reyna@windriver.com>
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Give each rootfs its own RPM channel to use. This puts the RPM metadata
in a private subdirectory of $WORKDIR, rather than living in DEPLOY_DIR
where other tasks may race with it.
This allows us to reduce the time that the rpm.lock is held to only the
time needed to hardlink the RPMs, allowing the majority of the rootfs
operation to run in parallel.
Also, this fixes the smart tests by generating an index for all packages
at the time of the test, rather than using the one provided by the
rootfs process.
Original credit for the enhancement should go to Steven Walter
stevenrwalter@gmail.com.
(From OE-Core rev: a92c196449c516fe51786d429078bbb1213bb029)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Module systemd_boot created wtih a class "Systemdboot"
and a test case "test_efi_systemdboot_images_can_be_built"
to test new systemd bootloader.
[YOCTO #9706]
(From meta-yocto rev: 4366060660f15592261227ca47088b492383f8cc)
Signed-off-by: Jose Perez Carranza <jose.perez.carranza@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 3f859816aef3c3dba35cfbea15f0c56483205544, applied
to the wrong repo.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds handling of the non-git layers to create and update the
corresponding layer objects in Toaster.
(Bitbake rev: 0a9b5d7d9655dbb09d458fc6e330e932f0f9dab6)
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sync the BRLayer object with the new field added to the Layer object.
The BRLayer (BuildRequest Layers) are snapshots of the layers in the
project at build time and therefore need to mirror the required fields
of the layer object.
(Bitbake rev: a3112c922f036425977abffa0137b9133f61fcd6)
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update xhr_import_layer test to use locally imported
layer in local_source_dir.
[YOCO #9911]
(Bitbake rev: f855490dd04281beb5ae65d82430203d9fd263fc)
Signed-off-by: Sujith H <sujith.h@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update layer branch and layer commit section
in the build configuration page for locally
imported layers. For locally imported layers
this secion goes as "Not applicable".
[YOCO #9911]
(Bitbake rev: 4ca3f602a955e01d445fb4789496e925f8d4234b)
Signed-off-by: Sujith H <sujith.h@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
