The previous code assumes that bitbake/ directory is under the core layer.
This is the case for Yocto project. But users might clone oe-core and bitbake
separately. So we use bb.__file__ to locate the bitbake directory to make sure
it's copied into the extensible SDK.
(From OE-Core rev: 1be1db87343a48e9c25297245a2749d9df25d23c)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we do `bitbake buildtools-tarball' and then after one day do `bitbake
core-image-minimal -c populate_sdk_ext', we would meet errors like below.
| install: cannot stat '/buildarea2/chenqi/poky/build-systemd/tmp/deploy/sdk/
poky-glibc-x86_64-buildtools-tarball-core2-64-buildtools-nativesdk-standalone
-1.8+snapshot-20150429.sh': No such file or directory
The problem is that the output name for buildtools-tarball has ${DATE} in it.
So if populate_sdk_ext task is executed but buildtools-tarball is not rebuilt,
the above error appears.
Instead of hardcoding ${DISTRO_VERSION} which consists of ${DATE} in the
install_tools() function, we should find the latest buildtools-tarball based
on the modification time and install it.
[YOCTO #7674]
(From OE-Core rev: fa708504d71e0b01ee97a172ac17ad16a9e3b897)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only poky sets SDK_NAME to include ${IMAGE_BASENAME} (i.e. ${PN}), so we
can't assume the buildtools filename will include it here. Change it to
look for a file with "buildtools-nativesdk-standalone" in the name
(the buildtools-tarball recipe itself sets TOOLCHAIN_OUTPUTNAME to
include this.)
(From OE-Core rev: 78ea4fcdea468888c0faef22a95dea7015a91df2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extensible SDK cannot be installed as root so by default offer to install it in
user's home directory under distro/distro_version replacing the normal SDK
version '+' char with a '_' as that's a restricted character for bitbake
(From OE-Core rev: 5486e76cd8abb946b81cff78719d67cfb87cddc6)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the current state if a SIGTERM is sent to
the testimage worker, the worker will exit but
runqemu and qemu won't exit and the processes
need to be killed manually to free the
bitbake lock.
This allows to catch the SIGTERM signal in
testimage, this way it is possible to stop
runqemu and qemu and allow to free the bitbake lock.
Also this allows to skip the rest of the tests
when running the tests in qemu or real hardware.
This also solves minimal breaks in the setup of the
runtime test when checking if qemu is alive.
[YOCTO #8239]
(From OE-Core rev: 2694d2f17d597b44fcc7aed5f6836081fa88a6b3)
Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com>
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* trying to pass foo="a b" through postinst_intercept ends
with the actual script header to containing:
b
foo=a
which fails because "b" command doesn't exist.
(From OE-Core rev: c66d7d85b7225be8c838449324d506565dd0081d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* useful when we need to overlay/extend intercept scripts from oe-core
(From OE-Core rev: 7d08d2d5c0ae686e3bb8732ea82f30fd189b1cd8)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ETA we show for builds in progress is woefully
inaccurate. In the 1.8 release we replaced it with
the % of tasks completed. Somehow, we regressed to
the ETA, so bringing the task % back.
(Bitbake rev: a841dc85770ea5c6fa8cf06ba5fdfe214e69afb2)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure that the project name we show for each build
in the latest builds section of the all builds page:
* Has the same styles as the build, depending on the
build status (in progress, failed or success)
* Links to the project page
(Bitbake rev: 09abcf3199b2e86758a974a47ebe31f5fb79440a)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was too much white space above the first
heading in the all builds page. This patch removes
the class that was adding the extra space.
(Bitbake rev: c9b20009c5e161987a143b00ee22218a4c9c0692)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pseudo 1.7 adds an experimental feature (which I think needs more testing
before it becomes the default) allowing the pseudo client to store modes
and uid/gid values in extended attributes rather than using the sqlite
database. On most Linux-like systems, this works only if the underlying
file is a plain file or a directory.
Also added is a profiling feature to allow some amount of reporting on
the wall-clock time the client spends in wrappers, processing operations,
or in IPC. This feature is not intendeded to be precisely accurate, but
gives a good overview of where time is going.
Based on the results from the profiling feature, the client now suppresses
OP_OPEN and OP_EXEC messages if the server is not logging messages, and
no longer uses constant dynamic allocation and free cycles for canonicalized
paths.
There's a few other likely-looking optimizations being considered, but
this seemed like a good cutoff for now.
1.7.1 fixes two bugs, one affecting mostly XFS systems with 64-bit
inode values, and one affecting code that called realpath(x, NULL), such
as the RPM backend.
1.7.2 fixes an indirect side-effect of the chmod fixes to deal with
umask 0700, which had no effect with opkg 0.2.4 but appears to cause
failures with 0.3.0.
1.7.3 prevents mkdirat() (and mkfifoat()) from setting errno on success,
because glibc's localedef inexplicably errors out if errno was set, even
if the operation's actual return code (which it tests) indicated
success.
(From OE-Core rev: 8402958cd2cb87b8283c8ee4e2d08e1a6717d67a)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To provide some element of integrity to sstate archives, allow sstate archives
to be GPG signed with a specified key (detached signature to a sidecar .sig
file), and verify the signatures when sstate archives are unpacked.
(From OE-Core rev: 237b6c51b42b0c64434dc45685e10f757ac939c2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Specify a value via PACKAGECONFIG[gui]. The default is
--diable-event-gui.
(From OE-Core rev: d80babce1ed23f647d118ad4ce3860c0e9f6fec2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This changes the default SYSLINUX_ROOTFS such that the rootfs is no
longer expected under a fixed device path. Instead, the UUID is used
to find it. This makes the resulting .hdddirect (and thus also the
vdi/vdmk/qcow2 images derived from that) more flexible.
(From OE-Core rev: 8ca8e2e5bf4a9f01dc48300149a8e1d71d715400)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.
To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file
system.
The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.
(From OE-Core rev: 1e29d77d0d33ee216b43022439876863f0db39bb)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set INITRD_IMAGE to automatically add a custom initramfs to the boot
partition.
(From OE-Core rev: 7fa76bd923fd643cf0984077321d6064d8ec3a2b)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of the SYSLINUX defaults are the same as in the underlying
syslinux.bbclass. Let's not duplicate them, because that makes
changing the default harder.
(From OE-Core rev: 7418709450e428010545dc9943802dd64c9582e1)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Kernel parameters like "uvesafb.mode_option=640x480-32" were turned
into shell variables named "bootparam_uvesafb.mode_option", which
triggered errors from the shell because the name is not valid. Now
points get replaced with underscores, leading to
bootparam_uvesafb_mode_option in this example.
(From OE-Core rev: de81e804f0654092d20ccb8e6e40f4ff614c4b09)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some kernels, for example linux-yocto 3.19 for qemux86, fail to
execute /init in an initramfs unless there is already a /dev/console
char device in the initramfs. Booting then fails with:
Kernel panic - not syncing: /dev/console is missing or not a character device!
Please ensure your rootfs is properly configured
The panic itself comes from a linux-yocto specific patch to
kernel_init_freeable in init/main.c, but even without it, that
function will print an error when /dev/console is missing. The
kernel's Documentation/initrd.txt also mentions creating that device.
It remained unclear why this is not a problem on other machines. On
intel-corei7-64 from meta-intel, something (the kernel?) creates
/dev/console and /dev/[012] before transfering control to the init
script. In that case, creating /dev/console in advance is not
necessary, but does not cause any problem either.
(From OE-Core rev: 1b64664f0c388f41084f5db6e46e3e68c53fb6d9)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some kernels, for example linux-yocto 3.19 for qemux86, fail to
execute /init in an initramfs unless there is already a /dev/console
char device in the initramfs. Booting then fails with:
Kernel panic - not syncing: /dev/console is missing or not a character device!
Please ensure your rootfs is properly configured
The panic itself comes from a linux-yocto specific patch to
kernel_init_freeable in init/main.c, but even without it, that
function will print an error when /dev/console is missing. The
kernel's Documentation/initrd.txt also mentions creating that device.
It remained unclear why this is not a problem on other machines. On
intel-corei7-64 from meta-intel, something (the kernel?) creates
/dev/console and /dev/[012] before transfering control to the init
script. In that case, creating /dev/console in advance is not
necessary, but does not cause any problem either.
(From OE-Core rev: 0352841cd92f6316bcac092e2fff9d28c352b36b)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it possible to boot images with multiple partitions (the
ones ending in .hddimg or .hdddirect) in several ways:
runqemu qemux86 core-image-minimal hddimg
runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg
VM=tmp-glibc/deploy/images/qemux86/iot-os-image-qemux86.hddimg FSTYPE=hddimg runqemu
Same for hdddirect.
This is useful for testing initramfs scripts, secure boot (when
switching to UEFI), or boot loaders like syslinux. For testing the
content of the rootfs, the ext4 image is better because that approach
is faster (no need to create another large image during build, rootfs
can be read directly instead of reading boot.img through loop device).
When booting a live image, the kernel, initramfs (if any) and kernel
parameters are taken from the image by the virtual machine's BIOS, so any
additional kernel parameters given to runqemu are ignored. This can be
avoided (already without this change) in a slightly hacky runqemu setup:
ROOTFS=tmp/deploy/images/qemux86/core-image-minimal-qemux86.hddimg \
FSTYPE=ext4 \
KERNEL=tmp/deploy/images/qemux86/bzImage-initramfs-qemux86.bin \
MACHINE=qemux86 \
runqemu serial kvm nographic 'bootparams=root=/dev/ram0'
The additional bzImage-initramfs-qemux86.bin kernel here was created
by adding this to local.conf:
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"
In the code, the new FSTYPE=hddimg resp. hdddirect behaves almost
exactly like the older vmdk FSTYPE. New types were chosen because it
seemed cleaner than using FSTYPE=vmdk when the actual image pointed to
by VM is not in that format. The downside is that several checks for
FSTYPE=vmdk had to be duplicated for FSTYPE=hddimg.
The VM variable now gets interpreted as "virtual machine disk image"
instead of "vmdk image".
(From OE-Core rev: 37741c539f5d3021e59828b49e968cd42b89a368)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oprofileui uses gettext during the configuration task so should be inherit
gettext. This issue appears when an older version of gettext is used do to
pinning to the older non-gplv3 version.
[YOCTO #7795]
(From OE-Core rev: 4734ebef1c5259791daba8ce2ce6dd4ddd5d087b)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When two or more tests had the same name but different classes then
the decorator log whould have the output all wrong. This was because
a comparison which was made only between method names but now it
compares classes too.
[YOCTO #8029]
(From OE-Core rev: 2b475f82d13b5c04d0c483d11a7df5e9352caa75)
Signed-off-by: Lucian Musat <george.l.musat@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* otherwise whole build report submission is rejected because it's too big
(From OE-Core rev: 3544b4d4d72330eb12bb3cda25cb99ed52c8a2eb)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An rmdir call in do_install_append was trying to remove the
sbindir, however in a system with a merged usr this directory
is not empty and therefore failing to rm it causes an ERROR.
Instead check that sbindir != base_sbindir before trying to
remove the directory.
(From OE-Core rev: 2daab2114a0bee1268ce8f7d973ea81d5a530dfd)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Makefile for mount and osd_login utilities forces
/sbin as asbindir, however on a merged /usr system this directory
might not exist. Instead sed in the system sbindir.
(From OE-Core rev: da8269ed0fd609699b23c2e3e6c61bc54f7b2832)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.
(From OE-Core rev: aa761ddad6643ac755de0b8e9841f19245b3f5c1)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.
(From OE-Core rev: 9a55950eee49d1105d3593efed719a0a21dc3da3)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.
(From OE-Core rev: 7fe7f94da1af7a350ad2240da405dad829d49d71)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.
(From OE-Core rev: 7ff40fff4cb6b735ceb27c6b736c2d13656fedec)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Replace all hard-coded paths with variables
* Run sed over busybox.links.* to replace /bin with ${base_bindir}
(From OE-Core rev: c61463a45441315b0006a28bb9f6069a393a8309)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, if qemu segfaults, the tests merrily continue trying to execute
which takes time for them to timeout and is a bit silly. Worse, no logs about
the segfault are shown to the user, its silent!
This patch tries to unravel the tangled web of issues and ensures that we:
* install a SIGCHLD handler which tells the user qemu exited
* check if qemu is running, if it isn't fail the test outright
* don't leave processes behind in sshcontrol which would hold
bitbake.lock and block shutdown
(From OE-Core rev: 5c04b1ca1e989f569d5755a646734d01a0c56cae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc 5.X is now working in all the places we test it in, its been in
testing for quite some time. Time to make it the default (we have some
room in M4 for any other bugfixes). Its easy to switch back to 4.9, we
should really remove 4.8 at this point (to meta-oe?).
(From OE-Core rev: 039211f0d8fe79d07b65f2f02e299b9656034214)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When our clone exists, but is out of date, and the attempt to update it fails,
we don't necessarily want to remove the entire clone, particularly if it's
a large repository.
(Bitbake rev: 19af272ba5256653edeff6acbceeb09e3e478d61)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the main fetch method doesn't support checksums, the user will not be
defining them in the recipe, so we don't want to check them for
premirrors/mirrors either. This ensures that we never error due to missing
checksums on a git mirror tarball.
(Bitbake rev: 24c79bbed361b37f12d3351af13602e3d4386f4c)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using an absolute file URI, there's no host, and the path starts with
'/', the dir under ${DL_DIR}/git2/ ends up starting with '.', so is hidden.
Remove any leading '.' to fix this.
(Bitbake rev: 8dce6964d56b36a77fb113f2ad496cc992a5ff36)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Show the user only the portion of the traceback which was from the metadata,
nothing from bitbake's internal calls.
(Bitbake rev: c45054aef03393fa0bf70e853ddcfc55988493cf)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This gives us the needed context of the original ExpansionError, which is
invaluable when we have a chain of function calls in the expansion.
(Bitbake rev: c514b6fbea77ede1b7871b89592a33ed39b1d71c)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The output of "bitbake, -c listtasks pkg" lists tasks with their real names
(starting with "do_"), but then "bitbake -c do_task" fails, as "do_" always
gets unconditionally prepended to task names. This patch handles this error
by checking whether a task starts with "do_" prior to prepending it with it
when the task runlist is being constructed (and a few other corner cases).
[YOCTO #7818]
(Bitbake rev: dd3050ceef37ac556546e940aa596ce96ef6c8df)
Signed-off-by: Alex Franco <alejandro.franco@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the explanation we show to users during set up
when asking them to set the layers checkout directory.
The patch also makes minor changes in text formatting to
improve legibility.
[YOCTO #7740]
(Bitbake rev: dd9284944ae0f0feecb70adab880fed636f7cd59)
Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you start and suspend a bitbake execution so the bitbake lock is held,
then try and run "bitbake -w '' X", you will see bitbake return an error exit
code but print no message about what happened at all.
The reason is that the -w option creates a "UI" which swallows the messages. The
code which handles this exit failure mode thinks a UI has printed the messages
and therefore doesn't do so.
This adds in an extra parameter to the UI registration code so that we
can figure out whether its a primary UI or not and base decisions on whether
to display information on that instead. This fixes the error shown above and
some bizarre failures on the Yocto Project Autobuilder.
[YOCTO #8239]
(Bitbake rev: d1d60a68c2de40c2984d5040d14251c1be121b0b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake utils' movefile is now prone to malform the destination
file with duplicated file name strings. Fixing it to force a file
name append iff the dest argument is a dir not a file name
(Bitbake rev: 38dd27f7191da002a16c561be3790ce487045b01)
Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When QEMU starts the RCU thread executes qemu_mutex_lock_thread
causing error "qemu:qemu_cpu_kick_thread: No such process" and exits.
For detail explanation see upstream patch.
[YOCTO #8143]
(From OE-Core rev: e4bbd98bf9648bbf3ffa7c4338f2302a92a413ef)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
