Re: [OE-core] [oe-core][PATCH v3 2/3] systemd.bbclass: Use systemd_system_unitdir
On Fri, 2015-07-24 at 17:10 +0200, Pau Espin Pedrol wrote:
Hi,
actually this breaks build of systemd.bb itself, because it installs
its system recipes using paths from Makefile.am:
userunitdir=$(prefix)/lib/systemd/user
systemunitdir=$(rootprefix)/lib/systemd/system
And in the recipe for systemd_219.bb we have:
# Helper variables to clarify locations. This mirrors the
logic in systemd's
# build system.
rootprefix ?= ${base_prefix}
rootlibdir ?= ${base_libdir}
rootlibexecdir = ${rootprefix}/lib
So, that means it installs its own services into /lib, not /usr/lib.
The changes done in systemd.bbclass in this patch remove the search
path of /lib, allowing only ${system_system_unitdir} which is
/usr/lib/systemd/system.
I tried changing rootprefix to use ${prefix} but then I get other
problems:
ERROR: QA Issue: systemd: Files/directories were installed but
not shipped
/usr/bin/udevadm
/usr/bin/journalctl
/usr/bin/loginctl
/usr/bin/machinectl
/usr/bin/systemctl
/usr/lib/udev/.debug
/usr/lib/udev/.debug/cdrom_id
/usr/lib/udev/.debug/collect
/usr/lib/udev/.debug/ata_id
/usr/lib/udev/.debug/v4l_id
/usr/lib/udev/.debug/mtd_probe
/usr/lib/udev/.debug/scsi_id
/usr/lib/udev/.debug/accelerometer
/usr/lib/udev/rules.d/70-uaccess.rules
/usr/lib/udev/rules.d/73-seat-late.rules
/usr/lib/udev/rules.d/71-seat.rules
/usr/lib/udev/rules.d/99-systemd.rules
Which at the end makes me think... is it really a good idea to set
systemd_unitdir and system_system_unitdir to use ${nonarch_libdir}?
I think we should be better using ${nonarch_base_libdir} for those, as
systemd guys themselves make distinction between both (prefix vs
rootprefix).
I agree. ${nonarch_base_libdir} seems to be definitely the right place
to put system service files. This may change if some day nobody will
have a separate /usr partition any more (which is what the systemd
developers are pushing for, AFAIK), but as long as we have to deal with
systems with a separate /usr partition, I think using /lib is the only
safe choice.
--
Tanu
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sed: Make locale depenencies glibc specific
Only glibc provides this base locale so make the dependency glibc
specific to avoid build failures with other libcs.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/recipes-extended/sed/sed_4.2.2.bb
b/meta/recipes-extended/sed/sed_4.2.2.bb
index 5da3355..5aa7d8a 100644
--- a/meta/recipes-extended/sed/sed_4.2.2.bb
+++ b/meta/recipes-extended/sed/sed_4.2.2.bb
@@ -16,7 +16,7 @@ SRC_URI[sha256sum] =
fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf079
inherit autotools texinfo update-alternatives gettext ptest
RDEPENDS_${PN}-ptest += make ${PN}
-RRECOMMENDS_${PN}-ptest += locale-base-ru-ru
+RRECOMMENDS_${PN}-ptest_append_libc-glibc = locale-base-ru-ru
EXTRA_OECONF = --disable-acl \
${@bb.utils.contains('PTEST_ENABLED', '1',
'--enable-regex-tests', '', d)}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] perf: Fix config file conflict with 4.1 kernels
If you setup mutlitlibs and then:
bitbake perf libb32-perf
bitbake perf libb32-perf -c cleansstate
bitbake perf libb32-perf
you will see races where the two builds get confused about which directory
they should be using and they corrupt each other.
The issue is that .config-detected is created in ${S}, not $(OUTPUT).
We can fix this by moving the file to $(OUTPUT).
[YCOTO #8043]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index f18178c..056ac83 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -127,12 +127,27 @@ do_configure_prepend () {
# 64 bit build (and library) are not exected. To ensure that libraries are
# installed to the correct location, we can use the weak assignment in the
# config/Makefile.
+#
+# Also need to relocate .config-detected to $(OUTPUT)/config-detected
+# as two builds (e.g. perf and lib32-perf from mutlilib can conflict
+# with each other if its in the shared source directory
+#
if [ -e ${S}/tools/perf/config/Makefile ]; then
# Match $(prefix)/$(lib) and $(prefix)/lib
sed -i -e 's,^libdir = \($(prefix)/.*lib\),libdir ?= \1,' \
-e 's,^perfexecdir = \(.*\),perfexecdir ?= \1,' \
+ -e 's,\.config-detected,$(OUTPUT)/config-detected,g' \
${S}/tools/perf/config/Makefile
fi
+if [ -e ${S}/tools/perf/Makefile.perf ]; then
+sed -i -e 's,\.config-detected,$(OUTPUT)/config-detected,g' \
+${S}/tools/perf/Makefile.perf
+fi
+if [ -e ${S}/tools/build/Makefile.build ]; then
+sed -i -e 's,\.config-detected,$(OUTPUT)/config-detected,g' \
+${S}/tools/build/Makefile.build
+fi
+
# We need to ensure the --sysroot option in CC is preserved
if [ -e ${S}/tools/perf/Makefile.perf ]; then
sed -i 's,CC = $(CROSS_COMPILE)gcc,#CC,' ${S}/tools/perf/Makefile.perf
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] toolchain-scripts: For non-glibc, pass compiler options to ensure the correct libc selection
gcc-cross-canadian-arch is only built once. It needs to target all the
different libcs, not just the currently selected one. This change ensures
that if another libc is used, the compiler correctly selects the right one.
[YOCTO #8025]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index a6ad041..d0b2b91 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -3,6 +3,8 @@ inherit siteinfo kernel-arch
# We want to be able to change the value of MULTIMACH_TARGET_SYS, because it
# doesn't always match our expectations... but we default to the stock value
REAL_MULTIMACH_TARGET_SYS ?= ${MULTIMACH_TARGET_SYS}
+TARGET_CC_ARCH_append_libc-uclibc = -muclibc
+TARGET_CC_ARCH_append_libc-musl = -mmusl
# This function creates an environment-setup-script for use in a deployable SDK
toolchain_create_sdk_env_script () {
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cross-canadian: Put links in place for uclibc and musl
gcc-cross-canadian-arch is only built once. It needs to target all the
different libcs, not just the currently selected one. This change
ensures that if another libc is used, symlinks are present such that the
compiler can be found. The base version is always assumed to be glibc
with symlinks from musl and uclibc compiler names.
This means gcc-cross-canadian is consistent regardless of which libc is
selected when its build in multimachine builds.
[YOCTO #8025]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/cross-canadian.bbclass
b/meta/classes/cross-canadian.bbclass
index 18d9d9a..9e06884 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -16,7 +16,7 @@ STAGING_BINDIR_TOOLCHAIN =
${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S
# Update BASE_PACKAGE_ARCH and PACKAGE_ARCHS
#
PACKAGE_ARCH = ${SDK_ARCH}-${SDKPKGSUFFIX}
-CANADIANEXTRAOS =
+CANADIANEXTRAOS = linux-uclibc linux-musl
MODIFYTOS ??= 1
python () {
archs = d.getVar('PACKAGE_ARCHS', True).split()
@@ -28,25 +28,26 @@ python () {
# Allow the following code segment to be disabled, e.g. meta-environment
if d.getVar(MODIFYTOS, True) != 1:
return
+tos = d.getVar(TARGET_OS, True)
+if (tos != linux and tos != linux-gnuspe
+and tos != linux-uclibc and tos != linux-uclibcspe
+and tos != linux-musl and tos != linux-muslspe):
+bb.fatal(Building cross-candian powerpc for an unknown TARGET_SYS
(%s), please update cross-canadian.bbclass % d.getVar(TARGET_SYS, True))
+for n in [PROVIDES, DEPENDS]:
+d.setVar(n, d.getVar(n, True))
+d.setVar(STAGING_BINDIR_TOOLCHAIN, d.getVar(STAGING_BINDIR_TOOLCHAIN,
True))
+for prefix in [AR, AS, DLLTOOL, CC, CXX, GCC, LD, LIPO,
NM, OBJDUMP, RANLIB, STRIP, WINDRES]:
+n = prefix + _FOR_TARGET
+d.setVar(n, d.getVar(n, True))
# PowerPC can build linux and linux-gnuspe
tarch = d.getVar(TARGET_ARCH, True)
if tarch == powerpc:
-tos = d.getVar(TARGET_OS, True)
-if (tos != linux and tos != linux-gnuspe
-and tos != linux-uclibc and tos != linux-uclibcspe
-and tos != linux-musl and tos != linux-muslspe):
-bb.fatal(Building cross-candian powerpc for an unknown TARGET_SYS
(%s), please update cross-canadian.bbclass % d.getVar(TARGET_SYS, True))
# This is a bit ugly. We need to zero LIBC/ABI extension which will
change TARGET_OS
# however we need the old value in some variables. We expand those
here first.
-d.setVar(DEPENDS, d.getVar(DEPENDS, True))
-d.setVar(STAGING_BINDIR_TOOLCHAIN,
d.getVar(STAGING_BINDIR_TOOLCHAIN, True))
-for prefix in [AR, AS, DLLTOOL, CC, CXX, GCC, LD,
LIPO, NM, OBJDUMP, RANLIB, STRIP, WINDRES]:
-n = prefix + _FOR_TARGET
-d.setVar(n, d.getVar(n, True))
-
d.setVar(LIBCEXTENSION, )
d.setVar(ABIEXTENSION, )
-d.setVar(CANADIANEXTRAOS, linux-gnuspe)
+d.appendVar(CANADIANEXTRAOS, linux-gnuspe linux-uclibcspe
linux-muslspe)
+d.setVar(TARGET_OS, linux)
}
MULTIMACH_TARGET_SYS = ${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3 0/6] recipetool/devtool/oe-selftest: pull from BBPATH
On Thu, 2015-07-23 at 12:57 -0700, Christopher Larson wrote: From: Christopher Larson chris_lar...@mentor.com Ensures that recipetool and devtool pull plugins from layers, and oe-selftest will pull tests from layers. Unrelated to that, also prevents a traceback on parsing failure, and adds a tiny feature to appendsrc to facilitate reuse by other sub-commands. [v3 Update] Fixed the commit message for `devtool: also load plugins from BBPATH` to match the implementation. Split up `recipetool: also load plugins from BBPATH` into two commits with clear commit messages. [v2 Update] `devtool: also load plugins from BBPATH` was fixed, so it no longer breaks the devtool selftests. I know there are some issues with oe-selftest on the autobuilder at the moment, specifically master results in things like: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/93 however when I apply this and your other series, the autobuilder oe-selftest does this: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/92/steps/Running%20oe-selftest/logs/stdio which is substantially worse. I can't immediately see what the issue is but the two runs above pretty much bisect this down to the patch series. I'm therefore reluctant to merge these until we can figure out what is going on... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/25] Dizzy next for .3
On Fri, 2015-07-24 at 22:28 -0700, akuster808 wrote: On 07/24/2015 12:34 AM, Richard Purdie wrote: On Sat, 2015-07-18 at 08:16 -0700, Armin Kuster wrote: We therefore need to decide whether to backport the gcc5 host fixes back to 1.7.3 or whether we have to disable autobuilders in order to be able to build it... I found the answer on https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance The primary focus for stable branches is bugfixing, security updates, and making sure that builds on recently released Ubuntu, Fedora, and OpenSUSE distros work so we should back port the gcc5 host fixes. Is that something I need to ? If we choose to do it (the above says its within policy) then someone needs to. It would certainly make life easier on the autobuilder. I've attempted the low hanging fruit with the patches in: http://git.yoctoproject.org/cgit.cgi/poky/log/?h=dizzy-next which get ncurses-native, cross-localedef-native and binutils-native working at least... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] update-rc.d: Include updated-rc.d in DEPENDS
If you build a user of updated-rc.d like udev, as things stand currently
nothing pulls in updated-rc.d but there is a dependency added on the
package at do_package time. This can lead to errors during rootfs
construction either with licensing. The fact its a RRECOMMEND means
the image are not deterministic.
A particularly good test case for reproducing this is:
MACHINE=A bitbake core-image-minimal
MACHINE=B bitbake core-image-minimal-initramfs
and since the second machine can find the package but not the license
manifest, a failure will result.
Extending the DEPENDS is the easy way to fix the issues.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 5d67a48..7bdc0e2 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -1,6 +1,6 @@
UPDATERCPN ?= ${PN}
-DEPENDS_append = update-rc.d-native
+DEPENDS_append = update-rc.d-native update-rc.d
VIRTUAL-RUNTIME_initscripts ?= initscripts
DEPENDS_append_class-target = ${VIRTUAL-RUNTIME_initscripts}
UPDATERCD = update-rc.d
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3 0/6] recipetool/devtool/oe-selftest: pull from BBPATH
On Sat, Jul 25, 2015 at 9:09 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2015-07-23 at 12:57 -0700, Christopher Larson wrote: From: Christopher Larson chris_lar...@mentor.com Ensures that recipetool and devtool pull plugins from layers, and oe-selftest will pull tests from layers. Unrelated to that, also prevents a traceback on parsing failure, and adds a tiny feature to appendsrc to facilitate reuse by other sub-commands. [v3 Update] Fixed the commit message for `devtool: also load plugins from BBPATH` to match the implementation. Split up `recipetool: also load plugins from BBPATH` into two commits with clear commit messages. [v2 Update] `devtool: also load plugins from BBPATH` was fixed, so it no longer breaks the devtool selftests. I know there are some issues with oe-selftest on the autobuilder at the moment, specifically master results in things like: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/93 however when I apply this and your other series, the autobuilder oe-selftest does this: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/92/steps/Running%20oe-selftest/logs/stdio which is substantially worse. I can't immediately see what the issue is but the two runs above pretty much bisect this down to the patch series. I'm therefore reluctant to merge these until we can figure out what is going on... Given that both failures have nothing to do with devtool, recipetool, or oe-selftest and are simply bitbake build failures as called by tests, I don’t really see how these could have anything to do with that, but understood. -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
