Bruce Ashfield [Sun, 19 Aug 2018 02:50:44 +0000 (22:50 -0400)]
kernel-devsrc: restructure for out of tree (and on target) module builds
The existing kernel-devsrc package starts with a full copy of the kernel
source and then starts to strip out elements that are not required.
This results in extra time (I/O) and extra space being taken up in the
final package. The main purpose of the kernel-devsrc package has been to
build modules against the running kernel, not to include a full copy of
the source code for re-building the kernel. The end result was a
600M kernel-devsrc package.
This restructuring of the package uses an approach similar to other
distros, where the kernel-devsrc package is for building against the
running kernel and uses a curated set of copied infrastructure, versus
a mass copy of the entire kernel.
The differences in this approach versus other is largely due to the
architecture support and the split build/source directory of the
kernel.
The result is a kernel-devsrc package of about 10M, which is capable
of running "make scripts" and compiling kernel modules against the
running kernel.
Along with the changes to the copying of the infrascture, we also
have the following changes:
- a better/more explicit listing of dependencies for on-target
builds of "make scripts" or "make modules_prepare"
- The kernel source is installed into /lib/modules/<version>/build
and a symlink created from /usr/src/kernel to the new location.
This aligns with the standard location for module support
code
- There is also a symlink from /lib/modules/<version>/source -> build
to reserve a spot for a new package that is simply the kernel
source. That package is not part of this update.
Maxin B. John [Thu, 16 Aug 2018 10:41:30 +0000 (13:41 +0300)]
vala: refresh patch
Refresh the following patch:
"disable-graphviz.patch" to fix this warning:
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:
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). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
checking file configure.ac
checking file libvaladoc/Makefile.am
checking file libvaladoc/html/basicdoclet.vala
checking file libvaladoc/html/htmlmarkupwriter.vala
Hunk #1 succeeded at 51 with fuzz 1 (offset 8 lines).
Chen Qi [Thu, 16 Aug 2018 10:37:58 +0000 (18:37 +0800)]
glibc: re-package for libnss-db
On other distros like ubuntu/centos, libnss-db usually provides:
- The libraries
- The Makefile to create database
(in /var/db for centos, /var/lib/misc/ for ubuntu)
- The makedb command (it's in glibc-common for centos7)
What we had is:
- The libraries are in glibc-extra-nss
- The Makefile is removed
- The makedb command is in glibc-utils (lack of dependency)
So when glibc-extra-nss is installed but glibc-utils is not,
we see error like:
nscd[165]: 165 checking for monitored file `/var/db/group.db': No such file or directory
nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No such file or directory
And there is not an easy way to create these databases.
To fix the issue:
- Re-package the libraries into libnss-db
- Don't remove the Makefile and add it in libnss-db
- Add RDEPENDS for libnss-db on glibc-utils
- Provide a shell script, makedbs.sh, to generate the db files.
This is to avoid dependency on 'make'.
Notes:
1. For external toolchain, an extra package 'libnss-db' need to be provided
If replacing glibc from core.
2. I've check the git history of nss/db-Makefile, the last two functionality
fix is as below.
- fix non-portable `echo -n` usage -- Date: Thu Aug 6 04:14:20 2015 -0400
- Fix db makefile rule for group.db -- Date: Fri Nov 11 14:43:36 2011 +0100
So I think this file is stable enough. And using makedbs.sh which is crafted according
to that file is not likely to cause maintanence problem.
Hongzhi.Song [Thu, 16 Aug 2018 07:38:48 +0000 (00:38 -0700)]
runtime selftest: limit kernel hw bp arches
1. So far, only qemux86[-64] support hw breakpoint, no matter whether or
not with kvm.
qemuppc: The oe-core configuration uses a PPC G4 system as the
default cpu but qemu doesn't simulate the hw breakpoint register for G4.
qemuarm: The arch more than v7 supports hw breakpoint, however arm use
v5 as default.
qemuarm64: We temporarily drop qemuarm64 for the moment. Normally it
will print debug info once, but endlessly when we trigger the break
point. Now it is hard to located the issue, but we will confirm it
later.
qemumips*: Kernel dosen't support hw bp for mips.
2. Syslog maybe not started, so we use dmesg to confirm.
3. Running 'ls' to trigger the hardware breakpoint test.
Anuj Mittal [Thu, 16 Aug 2018 06:26:33 +0000 (14:26 +0800)]
python3: enable profile optimized builds
Enable profile guided optimization (pgo) for python3. Enabling pgo in
python is generally as simple as invoking the target profile-opt which:
- builds python binaries with profile instrumentation enabled,
- runs a specific profile task using that python to get the profile
data and,
- feeds the compiler with this profile data and rebuilds python.
This change invokes qemu-user for the second step of running a profile
task using target python. Depending on how long profile task takes to
run, this might add a significant time to compilation (which would be
true for native builds too). The default profile task can be changed by
the users depending on what makes sense for their use case (or can be
left empty). In case qemu-user isn't supported, profile task won't be run.
Avoid adding bison-native to the sysroot without a specific
dependency in the recipe. This means indirect dependencies
(e.g. X -> Y -> binutils-cross -> bison-native) no longer meet the
dependency incidentally. This improves determinism and avoids build
failures when people switch to external toolchains.
Based on an idea by Richard Purdie:
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146324.html
Robert Yang [Thu, 16 Aug 2018 02:25:46 +0000 (10:25 +0800)]
prelink: use ehdr.e_shstrndx as index rather than ehdr.e_shnum
[YOCTO #12791]
According to struct elf32_hd, the e_shnum is section header number, and the
index is e_shstrndx, not e_shnum.
This can fix segmention fault when handle libqb.so.0.18.2 from libqb_1.0.3.
It fails to handle libqb.so.0.18.2 and get errors:
Symbol section index outside of section numbers
Then segmentation fault, this is because the e_shnum is 34, while e_shstrndx is
27 (it would be 33 when no errors), I've checked several elf files to confirm
that the ones after e_shstrndx is NULL, so use e_shstrndx should be correct.
Fixed:
MACHINE="qemux86-64"
IMAGE_INSTALL_append = " libqb" #libqp is from meta-openembedded
$ bitbake core-image-minimal
Segmention fault
Robert Yang [Thu, 16 Aug 2018 02:54:39 +0000 (10:54 +0800)]
binutils: Improve check for input file matching output file
When the assembler reports that the input and output are the same, report the
file names involved, in order to help debugging. Also do not equate two files
are the same if the have the same inode value but reside on different file
systems.
bb.utils.copyfile is called in a few places with identical src and dst
in order to create an st_nlinks==1 version of the file. That that even
works relies on an implementation detail of copyfile (namely, that it
creates a temporary file and then does a rename). Moreover, it's a waste
of time if the file already has st_nlinks==1.
So create a helper that optimizes away the copy in the st_nlinks==1
case. Of course, this helper relies on the same implementation detail,
but that's now contained within bb.utils itself.
To test that we do at least sometimes hit the no-copy path, I tested
locally with
This class sets POSTINST_INTERCEPTS and POSTINST_INTERCEPTS_CHECKSUMS,
to allow us to pull intercepts from BBPATH. This is kept as a separate
class, as it's needed by both image construction and sdk construction,
the latter to support meta-toolchain & similar recipes.
oe.package_manager: support loading intercepts from multiple paths
- if POSTINST_INTERCEPTS is set, use the listed intercept files, or
- if POSTINST_INTERCEPTS_PATH is set, load from the listed paths, or
- if POSTINST_INTERCEPTS_DIR is set, load from it (for compatibility), or
- load from ${COREBASE}/meta/postinst-intercepts
André Draszik [Tue, 22 May 2018 12:25:50 +0000 (13:25 +0100)]
sstate: allow specifying indirect dependencies to exclude from sysroot
Currently, a dependency on any -native recipe will pull in
all dependencies of that -native recipe in the recipe
sysroot. This behaviour might not always be wanted, e.g.
when that -native recipe depends on build-tools that are
not relevant for the current recipe.
This change adds a SSTATE_EXCLUDEDEPS_SYSROOT variable,
which will be evaluated for such recursive dependencies to
be excluded. The idea is similar to
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146324.html
except that the list is not hard-coded anymore.
SSTATE_EXCLUDEDEPS_SYSROOT is evaluated as two regular
expressions of recipe and dependency to ignore, e.g. in
the above flex-native / bison-native use-case, one would
specify
Another anticipated user is meta-java, where certain newer
JDKs can only be bootstrapped (built) using older JDKs,
but it doesn't make much sense to copy all those older
JDKs and their own build tools (ant, etc.) into the
sysroot of recipes wanting to be built using the newer JDK
(only), e.g.:
Khem Raj [Wed, 15 Aug 2018 01:40:05 +0000 (18:40 -0700)]
security_flags: Add PIC to cflags for some recipes on ppc
Fixes issues related out of range R_PPC_REL24
e.g.
/usr/lib/xorg/modules/input/libinput_drv.so: /usr/lib/libinput.so.10: R_PPC_REL24 relocation at 0x0e8602c4 for symbol `libevdev_has_event_code' out of range
Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Marko Peter <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andrej Valek [Tue, 17 Jul 2018 09:10:34 +0000 (11:10 +0200)]
openssl-1.1: rework packaging
The main idea is to have libssl and libcrypto in separate packages.
This saves space if only single library is needed and also some recipes
(in other layers) depend on these library packages.
Together with this other packages like in 1.0.x were created.
The only difference is that openssl 1.1 has additional package openssl-bin.
Add missing dependency to perl for openssl-bin pkg, c_rehash requires it.
Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Marko Peter <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andrej Valek [Tue, 17 Jul 2018 09:10:33 +0000 (11:10 +0200)]
openssl-1.1: fix c_rehash perl errors
Patch original c_rehash script with Debian patch instead
of overriding it with own version.
Error output from c_reshah without patching:
Unknown regexp modifier "/b" at ./c_rehash line 15, at end of line
Unknown regexp modifier "/W" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/3" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/2" at ./c_rehash line 28, at end of line
No such class installdir at ./c_rehash line 63, near "Prefix our
installdir"
(Might be a runaway multi-line // string starting on line 28)
syntax error at ./c_rehash line 63, near "Prefix our installdir"
Can't redeclare "my" in "my" at ./c_rehash line 68, near ""
Execution of ./c_rehash aborted due to compilation errors.
Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Marko Peter <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SERIAL_CONSOLE was already deprecated in 2013, yet still some
machine configuration files were using it. This patch replaces
it with SERIAL_CONSOLES, which is the successor.
The default value in systemd-serialgetty.bb can also be safely
transitioned from SERIAL_CONSOLE to SERIAL_CONSOLES, as this
recipe already uses SERIAL_CONSOLES within do_install().
The documentation seems to be already up do date.
beaglebone-yocto.conf in the bsp-guide already uses
SERIAL_CONSOLES. The ref-manual redirects from SERIAL_CONSOLE
to SERIAL_CONSOLES.
cve-check.bbclass: do not download the CVE DB in package-specific tasks
Disable downloading of the vulnerability DB in do_check_cves() task.
When invoked in this task, cve-check-tool attempts re-download of the CVE DB
if the latter is older than certain threshold. While reasonable for a
stand-alone CVE checker, this behavior can cause errors in parallel builds
if the build time is longer than this threshold:
* Other tasks might be using the DB.
* Several packages can start the download of the same file at the same time.
This check is not really needed, as the DB has been downloaded by
cve_check_tool:do_populate_cve_db() which is a prerequisite of any do_build().
The DB will be at most (threshold + build_time) old.
Alex Kiernan [Fri, 20 Jul 2018 04:33:17 +0000 (04:33 +0000)]
image: Use ${COREBASE}/meta for timestamp, fallback to bitbake.conf
To handle the case where ${COREBASE} isn't the git directory, avoid
erroring out when the git command fails. If we don't have a timestamp
after this, fall back to the timestamp from conf/bitbake.conf.
This turns out to be because the automatic moving of the -dbg package to
the beginning of the package list is disabled in that case, so the
python3-gpg packages that the recipe prepends to PACKAGES ends up before
the -dbg package.
It's not clear why the "and not split_source_package" was added when
debug-with-srcpkg was introduced. Presumably the intention was to
prevent the -dbg package to end up before the -src package, which we of
course need to. But at the same time, we still need -dbg packages to end
up before all other packages.
Using list.insert(0, ...) also means that if there happens to more than
one -dbg package, their relative ordering gets inverted in the new list.
This tries to fix these issues by sorting the packages by (priority,
original position), where priority is 10 for -src, 30 for -dbg and 50
for everything else. That guarantees that packages of the same "type"
preserve their relative ordering, while also ensuring that -dbg always
preceed other packages. This scheme is also quite extensible, and,
should the need arise, one could even expose the priorities as a knob
the recipe author could use to ensure specific orderings of packages
instead of the somewhat fragile and coarse-grained method of "prepend or
append, and ensure you do that in a proper order".
Probably the autodebug condition needs to stay, but I think the
split_source_package condition in the preceding elif should be removed,
so that that logic applies to all packages called -src, not just the one
we might have created a few lines above.
Martin Jansa [Tue, 14 Aug 2018 10:53:11 +0000 (10:53 +0000)]
weston: add dependency on virtual/libgbm for kms PACKAGECONFIG
* gbm is checked in configure.ac:
AC_ARG_ENABLE(drm-compositor, [ --enable-drm-compositor],,
enable_drm_compositor=yes)
AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes)
if test x$enable_drm_compositor = xyes; then
AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm mtdev >= 1.1.0])
PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit that capability])])
fi
Kevin Hao [Tue, 14 Aug 2018 01:31:24 +0000 (09:31 +0800)]
wic: bootimg-partition: Add support to create the u-boot boot config file
By leveraging the distro boot command feature in the u-boot, we can
compose the corresponding extlinux.conf when creating the wic image,
and let u-boot boot the kernel automatically. For more detail about
the u-boot distro boot command feature, please see doc/README.distro
in u-boot source files.
We want to add some u-boot specific config file. Before doing this,
we need know what files will be installed into this partition. So
move the codes about parsing the IMAGE_BOOT_FILES into
do_configure_partition(). No function change.
Kevin Hao [Tue, 14 Aug 2018 01:31:21 +0000 (09:31 +0800)]
wic: Remove the unused variable Partition.sourceparams_dict
We choose to pass the source parameters to the source plugins' hooks
via a local variable srcparams_dict. So the Partition.sourceparams_dict
is not used by anyone and seems pretty confused. So drop it.
Yevgeny Popovych [Tue, 14 Aug 2018 17:32:24 +0000 (10:32 -0700)]
ref-manual: Removed misleading paragraph in siteinfo.bbclass
The section on the siteinfo.bbclass file had a paragraph indicating
base.bbclass included siteinfo.class. This is not true since
2010. I removed the paragraph.
Scott Rifenbark [Thu, 19 Jul 2018 21:29:14 +0000 (14:29 -0700)]
sdk-manual: Provided better wording for sharing HTTP or HTTPS server
Step 1 of the "Providing Updates to the Extensible SDK After Installation"
section really did not do much for the reader regarding setting up a
HTTP or HTTPS directory. I added more detail on how to generally do
that.
This variable is the default installation directory for the
Extensible SDK. By default, it is "poky_sdk". You can override
this variable so it needed to be documented. The ideal place to
override it is in the distribution configuration file.
Scott Rifenbark [Mon, 16 Jul 2018 21:28:52 +0000 (14:28 -0700)]
sdk-manual: Updates to sections for updating installed Ext SDKs
There are two sections that deal with this topic. One is from the
standpoint of a user using a 3rd party published and installed
extensible SDK ("Applying Updates to an Installed Extensible SDK").
The other is from the standpoint of a person providing Extensible
SDKs for consumption ("Providing Updates to the Extensible SDK
After Installation"). These sections needed some closer examination
regarding fully describing what was going on. I provided some
re-writes to both.
Scott Rifenbark [Mon, 16 Jul 2018 20:22:10 +0000 (13:22 -0700)]
sdk-manual: Changed title to updating the SDK after install
The title for the section on how to effect changes to an installed
extensible SDK is better suited as "Providing Updates to the
Extensible SDK AFter Installation."
Scott Rifenbark [Mon, 16 Jul 2018 20:15:43 +0000 (13:15 -0700)]
sdk-manual: Fixed grammar error
In "Providing Updates After Installing the Extensible SDK" section,
Step 1 had a bit of a grammar error. Not technically, but it
could have been written better. I fixed that.
Scott Rifenbark [Wed, 11 Jul 2018 22:28:52 +0000 (15:28 -0700)]
ref-manual: Updated the SDK_INHERIT_BLACKLIST variable description
Added information on the class in which the default is set. Also,
put in a reference for more information on customizing the
extensible SDK configuration.
Scott Rifenbark [Wed, 11 Jul 2018 22:09:07 +0000 (15:09 -0700)]
ref-manual: Updated the SDK_LOCAL_CONF_WHITELIST variable description
Enhanced this description by indicating the class that it is set in
and by including a pointer back into the sdk-manual where filters
are described for extending the extensible SDK.
Scott Rifenbark [Tue, 10 Jul 2018 21:24:07 +0000 (14:24 -0700)]
sdk-manual, mega-manual: Updated standard SDK install directory figure
The figure was incorrect for the installed file and folder hierarchy
for a standard SDK. I updated it. This figure goes in both the sdk-manual
and the mega-manual.
Scott Rifenbark [Mon, 9 Jul 2018 21:05:28 +0000 (14:05 -0700)]
sdk-manual: Added note in step to set SDKMACHINE
The value of SDKMACHINE must match the architecture of the machine
on which the SDK installer is being built if you are building an
installer for an extensible SDK. I added a note to this effect.
Opening a file in binary mode and iterating it seems like the simple solution
but will still break on newlines, which for binary files isn't really useful as
the size of the chunks could be huge or tiny.
Instead, let's be a bit more clever: we'll be MD5ing lots of files, but we don't
want to fill up memory: use mmap() to open the file and read the file in 8k
blocks.
Andrej Valek [Tue, 14 Aug 2018 10:21:19 +0000 (12:21 +0200)]
systemd: fixes for the compatibility interface
Use a heap allocated string to set arg_ifname, since a stack allocated
one would be lost after the function returns. (This last one broke the
case where an interface name was suffixed with a dot, such as in
`resolvconf -a tap0.dhcp`.)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com> Signed-off-by: Simon Ausserlechner <simon.ausserlechner@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it more suitable to work with, e.g., devtool. It also
prepares for the update to 0.47.0 when the first patch will no longer be
needed (as it is a backport).