Re: [OE-core] meta-gir issues and maintenance
Hi Tomas, I'm Changhyeok and working with Martin Jansa. Actually I'm using meta-gir layer. So can I take over meta-gir layer? Thanks Changhyeok -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Tomas Frydrych Sent: Friday, March 13, 2015 3:03 AM To: OE-core Subject: Re: [OE-core] meta-gir issues and maintenance Martin, On 12/03/15 14:35, Martin Jansa wrote: > I was trying to use meta-gir in Dizzy release and found out that last > commit in this layer is 16 months ago and many .bbappends no longer > match with their recipes. > > Was this layer superseded by something else or you just didn't have > time to update it for newer Yocto releases? Unfortunately, life has been getting in the way of working on this layer (as well as meta-guacamayo), and it is not going to change in the foreseeable future. :-( It's a pity, as the gir stuff is useful/necessary for things like python bindings to gobject and related. If someone wanted to take over, it would make sense to move the repo somewhere more central (yocto, oe) as well. Tomas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/1] populate_sdk_ext: set noexec flag for some tasks
For the SDK, what we are interested in is the sysroot part. So the
only useful task is do_populate_sysroot. Other tasks like do_package
don't need to run. So mark them as 'noexec' for SDK.
This would result in two benefits:
1) The size of extensible SDK is larged reduced. For example, extensible
SDK for core-image-minimal is reduced from 1.8G to 793M.
2) The installation time is reduced as a lot of tasks are not run.
[YOCTO #7590]
Signed-off-by: Chen Qi
---
meta/classes/populate_sdk_ext.bbclass | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index dc2c58e..6c265b8 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -141,8 +141,18 @@ python copy_buildsystem () {
sigfile = d.getVar('WORKDIR', True) + '/locked-sigs.inc'
oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+# Mark tasks to be 'noexec' for the SDK as we only need the sysroot part
+base_class_path = os.path.join(baseoutpath, core_meta_subdir, 'classes',
'base.bbclass')
+if os.path.exists(base_class_path):
+with open(base_class_path, 'a') as f:
+noexec_tasks = ['do_package', 'do_packagedata', 'do_package_qa',
'do_package_write_rpm',
+'do_package_write_ipk', 'do_package_write_deb',
'do_deploy', 'do_populate_lic',
+'do_rootfs']
+for t in noexec_tasks:
+f.write('%s[noexec] = "1"\n' % t)
+
# Filter the locked signatures file to just the sstate tasks we are
interested in
-allowed_tasks = ['do_populate_lic', 'do_populate_sysroot',
'do_packagedata', 'do_package_write_ipk', 'do_package_write_rpm',
'do_package_write_deb', 'do_package_qa', 'do_deploy']
+allowed_tasks = ['do_populate_sysroot']
excluded_targets = d.getVar('SDK_TARGETS', True)
lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
oe.copy_buildsystem.prune_lockedsigs(allowed_tasks,
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/1] Mark some tasks in extensible SDK as 'noexec'
Changes since V1: Use the 'for' loop to simplify codes. The following changes since commit 2d09cb28f25080ed337d37d2d4381b846bbe6247: gcc5: Add PR65779 patch to fix powerpc compile issues (2015-05-12 13:10:17 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib ChenQi/SDK-noexec http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/SDK-noexec Chen Qi (1): populate_sdk_ext: set noexec flag for some tasks meta/classes/populate_sdk_ext.bbclass | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RESEND][PATCH 1/3] meta: add new qemuarma9 machine definition
On Tue, May 12, 2015 at 7:47 AM, Martin Jansa wrote: > On Tue, May 12, 2015 at 03:25:43PM +0100, Burton, Ross wrote: >> On 11 May 2015 at 20:52, Dmitry Eremin-Solenikov >> wrote: >> >> > Currently qemuarm is limited to 256 Mb of RAM. Sometimes this is too >> > little to run necessary applications. Add a new arm configuration based >> > on Versatile Express board, Cortex-A9 CPU, allowing up to 1Gb of RAM. >> > >> >> Not sure I'm keen on oe-core having two almost-identical qemuarm machines. >> Why not just change the qemuarm machine to use the A9? > > Then we should officially drop thumb1 support, because current qemuarm > builds are quite broken when thumb is enabled and dropping current > qemuarm or replacing it with A9 variant will prevent oe-core to be > testable on autobuilder. See > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717 +1 for updating qemuarm to an ARMv7 CPU. As for dropping thumb1 support that's probably fine too - although technically (if someone really did want to keep thumb1 support alive) I guess nothing prevents testing thumb1 binaries on an ARMv7 CPU? > -- > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] xserver-xorg: disable xwayland
On 13 May 2015 at 02:31, Robert Yang wrote: > I've updated it in the repo: > > git://git.openembedded.org/openembedded-core-contrib rbt/3fixes > Actually looked at the build output this time... we should have each xserver in a separate package really, so can the xwayland binary go into an xwayland package? We don't really want to force the xwayland binary (and extra dependencies) on everyone's X11-based images just because wayland is a default distro feature. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2][2/2] image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package
The following changes since commit 55bd8d189f647443b28f988ccfc9eebffaec84d1:
providers.py: Add PREFERRED_RPROVIDER (2015-05-13 11:29:52 -0400)
are available in the git repository at:
git://github.com/jatedev/poky.git preferred-provider-runtime-2
for you to fetch changes up to 832a47ff79a06a797ddd39db86c792a43cdf0865:
image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package
(2015-05-13 12:24:02 -0400)
Jate Sujjavanich (1):
image.bbclass/rootfs.py: use PREFERRED_RPROVIDER to select package
meta/classes/image.bbclass | 14 ++
meta/lib/oe/rootfs.py |2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 01f8b3f..80484d6 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -283,6 +283,20 @@ python rootfs_process_ignore() {
}
do_rootfs[prefuncs] += "rootfs_process_ignore"
+python rootfs_process_preferred_rproviders() {
+inst_pkgs = d.getVar("PACKAGE_INSTALL", True).split()
+pref_pkgs = list()
+for pkg in inst_pkgs:
+prefervar = d.getVar("PREFERRED_RPROVIDER_%s" % pkg, True)
+if prefervar:
+inst_pkgs.remove(pkg)
+pref_pkgs.append(prefervar)
+bb.note("Selecting %s to provide %s due to
PREFERRED_RPROVIDER" % (prefervar, pkg))
+inst_pkgs.extend(pref_pkgs)
+d.setVar("PACKAGE_INSTALL", ' '.join(inst_pkgs))
+}
+do_rootfs[prefuncs] += "rootfs_process_preferred_rproviders"
+
# We have to delay the runtime_mapping_rename until just before rootfs runs
# otherwise, the multilib renaming could step in and squash any fixups that
# may have occurred.
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 6fb749f..4bad7ef 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -393,7 +393,7 @@ class RpmRootfs(Rootfs):
pass
def _log_check_error(self):
-r = re.compile('(unpacking of archive failed|Cannot find
package|exit 1|ERR|Fail)')
+r = re.compile('(unpacking of archive failed|Cannot find
package|exit 1|ERR(?!ED_RPROVIDER)|Fail)')
log_path = self.d.expand("${T}/log.do_rootfs")
with open(log_path, 'r') as log:
found_error = 0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2][1/2] providers.py: Add PREFERRED_RPROVIDER
The following changes since commit 7a8f37daa7b42905233c31366915b897886a957a:
dev-manual: Updates to add Luna support for Eclipse (2015-05-03 11:49:35
+0100)
are available in the git repository at:
git://github.com/jatedev/poky.git oe-core-image-rdepend-alt-2
for you to fetch changes up to 55bd8d189f647443b28f988ccfc9eebffaec84d1:
providers.py: Add PREFERRED_RPROVIDER (2015-05-13 11:29:52 -0400)
Jate Sujjavanich (1):
providers.py: Add PREFERRED_RPROVIDER
bitbake/lib/bb/providers.py |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/bitbake/lib/bb/providers.py b/bitbake/lib/bb/providers.py
index 637e1fa..910a23e 100644
--- a/bitbake/lib/bb/providers.py
+++ b/bitbake/lib/bb/providers.py
@@ -323,11 +323,12 @@ def filterProvidersRunTime(providers, item, cfgData,
dataCache):
for p in eligible:
pn = dataCache.pkg_fn[p]
provides = dataCache.pn_provides[pn]
+provides.append(item)
for provide in provides:
-prefervar = cfgData.getVar('PREFERRED_PROVIDER_%s' % provide,
True)
-#logger.debug(1, "checking PREFERRED_PROVIDER_%s (value %s)
against %s", provide, prefervar, pns.keys())
+prefervar = cfgData.getVar('PREFERRED_RPROVIDER_%s' % provide,
True)
+#logger.debug(1, "checking PREFERRED_RPROVIDER_%s (value %s)
against %s", provide, prefervar, pns.keys())
if prefervar in pns and pns[prefervar] not in preferred:
-var = "PREFERRED_PROVIDER_%s = %s" % (provide, prefervar)
+var = "PREFERRED_RPROVIDER_%s = %s" % (provide, prefervar)
logger.verbose("selecting %s to satisfy runtime %s due to
%s", prefervar, item, var)
preferred_vars.append(var)
pref = pns[prefervar]
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2][0/2] Yocto Bug #6149
Richard, This version uses PREFERRED_RPROVIDER instead of PREFERRED_PROVIDER to reduce confusion. These patches add PREFERRED_RPROVIDER which specifies a preferred runtime provider for a package when multiple RPROVIDER's are available. It selects the preferred recipe to build and installs the preferred RPROVIDER during image generation. Jate -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V5 3/3] systemd: split modules into packages
Hello Bruno,
On 13.05.2015 23:51, Bruno Bottazzini wrote:
> +
> +# Aggregation of Split Packages
> +
> +PACKAGES =+ "${PN}-services-base"
> +SUMMARY_${PN}-services-base = "Base services aggregation"
> +ALLOW_EMPTY_${PN}-services-base = "1"
> +RDEPENDS_${PN}-services-base = " \
I think it would be better to use RRECOMMENDS, in order to support
BAD_RECOMMENDATIONS per image. This would also remove the need to use
bb.utils.contains, because unavailable recommended packages get ignored
by the package managers.
Besides that, I wonder whether ${PN}-services would be a better name,
because the -base suffix suggests that it contained only the most
important services.
Btw., sorry for commenting late again, but it's quite a big patch.
Regards,
Andreas
> +${@bb.utils.contains('PACKAGECONFIG', 'ask-password',
> '${PN}-services-ask-password', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'backlight',
> '${PN}-services-backlight', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'binfmt',
> '${PN}-services-binfmt', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'dbus', '${PN}-services-dbus',
> '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'firstboot',
> '${PN}-services-firstboot', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'fuse', '${PN}-services-fuse',
> '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'quota',
> '${PN}-services-quota', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'rfkill',
> '${PN}-services-rfkill', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'timesyncd',
> '${PN}-services-timesyncd', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'update',
> '${PN}-services-update', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'vconsole',
> '${PN}-services-vconsole', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'filesystems',
> '${PN}-generators-filesystems', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'preset', '${PN}-preset', '',
> d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'fsck', '${PN}-services-fsck',
> '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'journal',
> '${PN}-services-journal', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'modules-load',
> '${PN}-services-modules-load', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'randomseed',
> '${PN}-services-randomseed', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'sleep',
> '${PN}-services-sleep', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'sysctl',
> '${PN}-services-sysctl', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'sysusers',
> '${PN}-services-sysusers', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'tmpfiles',
> '${PN}-services-tmpfiles', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'udev', '${PN}-services-udev',
> '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'tools', '${PN}-tools', '',
> d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'bash', '${PN}-bash', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'initramfs',
> '${PN}-initramfs', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'kernel-install',
> '${PN}-kernel-install', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'rpm-macros',
> '${PN}-rpm-macros', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'zsh', '${PN}-zsh', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'bootchart',
> '${PN}-services-bootchart', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'debug',
> '${PN}-services-debug', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'machined',
> '${PN}-services-machined', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'nspawn',
> '${PN}-services-nspawn', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'sysvcompat',
> '${PN}-services-sysvcompat', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'getty',
> '${PN}-generators-getty', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'getty',
> '${PN}-services-getty', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'ldconfig',
> '${PN}-services-ldconfig', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'polkit',
> '${PN}-services-hostnamed', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'polkit',
> '${PN}-services-localed', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'polkit',
> '${PN}-services-logind', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'polkit',
> '${PN}-services-timedated', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'pam', '${PN}-pam', '', d)} \
> +${@bb.utils.contains('PACKAGECONFIG', 'networkd',
> '${PN}-services-networkd', '', d)} \
> +
[OE-core] [PATCH V5 3/3] systemd: split modules into packages
if one wants to launch a simple deamon, most modules are not
required.
He will be able to save space and exclude unwanted packages
from the final image.
Signed-off-by: Bruno Bottazzini
---
meta/recipes-core/systemd/systemd_219.bb | 1071 ++
1 file changed, 942 insertions(+), 129 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index 6ed4fe0..894466b 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -19,7 +19,7 @@ PROVIDES = "udev"
PE = "1"
-DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl
readline dbus libcap libcgroup glib-2.0 qemu-native util-linux"
+DEPENDS = "intltool-native gperf-native readline libcgroup libcap qemu-native"
SECTION = "base/shell"
@@ -59,10 +59,57 @@ LDFLAGS_append_libc-uclibc = " -lrt"
GTKDOC_DOCDIR = "${S}/docs/"
-PACKAGECONFIG ??= "xz ldconfig \
+PACKAGECONFIG ??= "ask-password \
+ backlight \
+ bash \
+ binfmt \
+ bootchart \
+ dbus \
+ filesystems \
+ firstboot \
+ fsck \
+ fuse \
+ getty \
+ initramfs \
+ journal \
+ kernel-install \
+ ldconfig \
+ machined \
+ modules-load \
+ nspawn \
+ preset \
+ quota \
+ randomseed \
+ rfkill \
+ rpm-macros \
+ sleep \
+ sysctl \
+ sysusers \
+ sysvcompat \
+ timesyncd \
+ tmpfiles \
+ tools \
+ udev \
+ update \
+ vconsole \
+ xz \
+ zsh \
${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '',
d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon',
'', d)}"
+PACKAGECONFIG[glib] = "--enable-gudev,--disable-gudev,glib-2.0"
+PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl"
+PACKAGECONFIG[blkid] = "--enable-blkid,--disable-blkid,util-linux"
+PACKAGECONFIG[efi] = "--enable-efi,--disable-efi"
+PACKAGECONFIG[kmod] = "--enable-kmod,--disable-kmod,kmod"
+PACKAGECONFIG[polkit] = "--enable-polkit,--disable-polkit"
+PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
+PACKAGECONFIG[smack] = "--enable-smack,--disable-smack"
+PACKAGECONFIG[ima] = "--enable-ima,--disable-ima"
+PACKAGECONFIG[apparmor] = "--enable-apparmor,--disable-apparmor,libapparmor"
+PACKAGECONFIG[seccomp] = "--enable-seccomp,--disable-seccomp,libseccomp"
+PACKAGECONFIG[qrencode] = "--enable-qrencode,--disable-qrencode,libqrencode"
+PACKAGECONFIG[lz4] = "--enable-lz4,--disable-lz4,lz4"
PACKAGECONFIG[journal-upload] = "--enable-libcurl,--disable-libcurl,curl"
# Sign the journal for anti-tampering
PACKAGECONFIG[gcrypt] = "--enable-gcrypt,--disable-gcrypt,libgcrypt"
@@ -200,158 +247,741 @@ do_install_ptest () {
python populate_packages_prepend (){
systemdlibdir = d.getVar("rootlibdir", True)
-do_split_packages(d, systemdlibdir, '^lib(.*)\.so\.*', 'lib%s', 'Systemd
%s library', extra_depends='', allow_links=True)
+do_split_packages(d, systemdlibdir, '^lib(udev|gudev|systemd|nss)\.so\.*',
'lib%s', 'Systemd %s library', extra_depends='', allow_links=True)
}
-PACKAGES_DYNAMIC += "^lib(udev|systemd).*"
+PACKAGES_DYNAMIC += "^lib(udev|gudev|systemd|nss).*"
+
+
+# Base Packages
+
+
+PACKAGES =+ "${PN}-generators-filesystems"
+SUMMARY_${PN}-generators-filesystems = "Unit generator for /etc/fstab"
+RDEPENDS_${PN}-generators-filesystems = "${PN}-services-fsck"
+FILES_${PN}-generators-filesystems = "\
+${rootlibexecdir}/systemd/system-generators/systemd-fstab-generator \
+${rootlibexecdir}/systemd/system-generators/systemd-gpt-auto-generator
\
+${rootlibexecdir}/systemd/systemd-remount-fs \
+
${systemd_unitdir}/system/local-fs.target.wants/systemd-remount-fs.service \
+${systemd_unitdir}/system/systemd-remount-fs.service \
+"
-PACKAGES =+ "${PN}-gui ${PN}-vconsole-setup ${PN}-initramfs ${PN}-analyze
${PN}-kernel-install \
- ${PN}-rpm-macros ${PN}-binfmt ${PN}-pam ${PN}-zsh libgudev"
+PACKAGES =+ "${PN}-generators-getty"
+SUMMARY_${PN}-generators-getty = "Generator for enabling getty instances on
the console"
+RDEPENDS_${PN}-generators-getty = "${PN}-services-getty"
+FILES_${PN}-generators-getty = "\
+${rootlibexecdir}/systemd/system-generators/systemd-getty-generator \
+"
-SYSTEMD_PACKAGES = "${PN}-b
[OE-core] [PATCH V5 2/3] systemd: removing workaround odering journal after remote-fs.target
This workaround is not needed in version 219 since the fix is upstreamed with:
919699ec301ea507edce4a619141ed22e789ac0d
---
meta/recipes-core/systemd/systemd_219.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index c196017..6ed4fe0 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -175,9 +175,6 @@ do_install() {
# Enable journal to forward message to syslog daemon
sed -i -e 's/.*ForwardToSyslog.*/ForwardToSyslog=yes/'
${D}${sysconfdir}/systemd/journald.conf
- # its needed in 216 upstream has fixed it with
919699ec301ea507edce4a619141ed22e789ac0d
- # don't order journal flushing afte remote-fs.target
- sed -i -e 's/ remote-fs.target$//'
${D}${systemd_unitdir}/system/systemd-journal-flush.service
# this file is needed to exist if networkd is disabled but timesyncd is
still in use since timesyncd checks it
# for existence else it fails
if [ -s ${D}${libdir}/tmpfiles.d/systemd.conf ]; then
--
2.4.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V5 1/3] dbus: split tools package.
From: Gustavo Sverzut Barbieri
Most tools are not required if one is launching a simple daemon.
The user will be able to exclude dbus-tool and save some space in his
build
Signed-off-by: Bruno Bottazzini
---
meta/recipes-core/dbus/dbus.inc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index fb5d017..58dd728 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -39,7 +39,7 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf
${sysconfdir}/dbus-1/session
DEBIANNAME_${PN} = "dbus-1"
-PACKAGES =+ "${PN}-lib"
+PACKAGES =+ "${PN}-lib ${PN}-tools"
OLDPKGNAME = "dbus-x11"
OLDPKGNAME_class-nativesdk = ""
@@ -47,6 +47,7 @@ OLDPKGNAME_class-nativesdk = ""
# for compatibility
RPROVIDES_${PN} = "${OLDPKGNAME}"
RREPLACES_${PN} += "${OLDPKGNAME}"
+RRECOMMENDS_${PN}_class-native = ""
FILES_${PN} = "${bindir}/dbus-daemon* \
${bindir}/dbus-uuidgen \
@@ -64,6 +65,12 @@ FILES_${PN} = "${bindir}/dbus-daemon* \
FILES_${PN}-lib = "${libdir}/lib*.so.*"
RRECOMMENDS_${PN}-lib = "${PN}"
FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool"
+FILES_${PN}-tools += "${bindir}/dbus-uuidgen \
+ ${bindir}/dbus-cleanup-sockets \
+ ${bindir}/dbus-monitor \
+ ${bindir}/dbus-launch \
+ ${bindir}/dbus-run-session"
+RRECOMMENDS_${PN} = "${PN}-tools"
pkg_postinst_dbus() {
# If both systemd and sysvinit are enabled, mask the dbus-1 init script
--
2.4.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V5 0/3] systemd: split modules into packages
Differences from V4: - Removing DEPENDS since PACKAGECONFIG will add the dependencies when they are needed. As Anders has suggested. Differences from V3: - Ordering alphabetically PACKAGECONFIG as Andreas has suggested. - DEPENDS not being statically since it may change depending on the PACKAGECONFIG as Anders and Andreas have suggested. - Removing patch that systemd: Verify if journal-flush.service exists and removing the workaround since it is already upstremead on systemd as Andreas has suggested. Differences from V2: - Installing default features with "PACKAGECONFIG" instead of using "DISTRO_FEATURES" as Anders, Leandro and Otavio suggested. - Rebase with master Differences from V1: - Making sure that we don't change default configuration as Anders and Otavio suggested. - Changing EXTRA_OECONF flags to use it with PAKAGECONFIG as Anders pointed in the review. - New patch that verifies if journal-flush.service exists. It may not exists depending on package configuration that the users want to be installed or removed. Bruno Bottazzini (2): systemd: removing workaround odering journal after remote-fs.target systemd: split modules into packages Gustavo Sverzut Barbieri (1): dbus: split tools package. meta/recipes-core/dbus/dbus.inc |9 +- meta/recipes-core/systemd/systemd_219.bb | 1074 ++ 2 files changed, 950 insertions(+), 133 deletions(-) -- 2.4.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Changing external kernel module results in rebuild of whole kernel
On 2015-05-13 11:44 AM, Richard Purdie wrote: On Wed, 2015-05-13 at 11:33 +0100, Richard Purdie wrote: On Tue, 2015-05-12 at 08:01 +0200, Mike Looijmans wrote: As things are now, I'd much prefer the "taring up and then extracting a large (GB) sized sstate object" option, since that at least worked correctly. Sorry for the delayed reply, I didn't understand exactly what was happening without looking at a build. By far the easiest "fix" right now is: RM_WORK_EXCLUDE += "" This won't cost that much diskspace and should avoid the problem you're seeing. The problem is module.bbclass has a DEPENDS on virtual/kernel which means it depends on :do_populate_sysroot. As well as triggering the unpack to repopulate the shared work area for the kernel, this means it will cause the thing to effectively repackage. There are various ideas coming to mind: * We could drop virtual/kernel from DEPENDS which would shorten the kernel dependency chain by removing populate_sysroot from the equation. * We could change the task dependencies of populate_sysroot in kernel.bbclass so that it doesn't depend on do_install (it doesn't handle files any more now anyway). * We could figure out why populate_sysroot from sstate isn't good enough for bitbake and change the sstate code to use sstate more heavily. If I remember rightly, we currently rerun all a task's tasks rather than pull it half from sstate and half not. None of these jumps out at me as an easy or necessarily desirable fix. I do have some patches: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c4aed2ba7ae74e54a4ae8ac7aeda291704bde82a https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=7a20f175c0a1cdec208471e5f7ff5f560f0b609e https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c5f3cdca3e16d90c4e5bbb3abe5e136b8025f1a4 What I've noticed is that rm_work does not remove the data from shared-work. What it does do is remove the stamp file which causes all the tasks to rerun even if the data was there. The above patches make "do_shared_work" a semi sstate task, one which is never generated into the sstate feed but does have the right stamp functionality. This basically stops kernel modules from rerunning kernel tasks even with rm_work. Whether these patches are a good idea, I'm less sure. Bruce: You might want to look at the module.bbclass changes in the first patch. I think there is some duplication between module and module-base I need to remove. I looked at the series, and it looks sane to me. Nice to move that dependency to a common location, rather than requiring and end module recipe (like lttng to get it correct). For the overlap, I assume you were talking about them both now having the do_configure[depends] += "virtual/kernel:do_shared_workdir" ? Since module inherits module base, looks like that can be shuffled down to the lowest class. It's also a bit odd (to my eyes) that module.bbclass has the do_make_scripts dependency, while module-base.bbclass has the actual routines .. Definitely from sorting out that looks to be in order. Bruce Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] opkg and gpg signed ipk packages
Hi > SHA256 is also supported. In OpenEmbedded, use the PACKAGECONFIG > 'sha256' then ensure that your Packages file contains a 'SHA256sum: ...' line > for each package. Does anyone know where do I specify this PACKAGECONFIG configuration? I want all ipk packages to be checksummed using sha256 (in the Packages file that describes the ipk packages). The default seems to be md5: tmp/deploy/ipk/ppce500v2/Packages Package: acl-dbg Version: 2.2.52-r0 Recommends: libc6-dbg, libattr-dbg, libacl-dbg Section: devel Architecture: ppce500v2 Maintainer: Poky MD5Sum: 0903a158d6c7acc825bf7e71b255d7fc < Thanks //Sona -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sanity.bbclass: Increased verbosity for connectivity check
From: Mariano Lopez
The connectivity sanity error doesn't tell you which URL failed to fetch nor
how it failed.
This provides the URL that failed and why it failed using BBFetchException
messages during the connectivity check.
[YOCTO #7592]
Signed-off-by: Mariano Lopez
---
meta/classes/sanity.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index f8b9fac..d601e91 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -278,12 +278,12 @@ def check_connectivity(d):
try:
fetcher = bb.fetch2.Fetch(test_uris, data)
fetcher.checkstatus()
-except Exception:
+except Exception as err:
# Allow the message to be configured so that users can be
# pointed to a support mechanism.
msg = data.getVar('CONNECTIVITY_CHECK_MSG', True) or ""
if len(msg) == 0:
-msg = "Failed to fetch test data from the network. Please
ensure your network is configured correctly.\n"
+msg = "%s. Please ensure your network is configured
correctly.\n" % err
retval = msg
return retval
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] linux-yocto and gcc 5.x
Robert, this was the error I hit last week. There may be a fix I have not tried. https://lkml.org/lkml/2015/2/18/422 - armin On 05/13/2015 12:39 AM, Robert Yang wrote: I think that I met another problem when MACHINE = qemuarm64 with gcc5: linux-yocto_3.19.bb: /tmp/ccWk2lM2.s: Assembler messages: /tmp/ccWk2lM2.s:42: Error: .err encountered /tmp/ccWk2lM2.s:43: Error: .err encountered /tmp/ccWk2lM2.s:44: Error: .err encountered /tmp/ccWk2lM2.s:103: Error: .err encountered /tmp/ccWk2lM2.s:104: Error: .err encountered /tmp/ccWk2lM2.s:105: Error: .err encountered make[3]: *** [arch/arm64/kernel/psci.o] Error 1 make[3]: *** Waiting for unfinished jobs CC mm/mmzone.o CC mm/vmstat.o CC mm/backing-dev.o CC net/socket.o make[2]: *** [arch/arm64/kernel] Error 2 make[2]: *** Waiting for unfinished jobs // Robert On 05/11/2015 09:20 PM, Richard Purdie wrote: Hi Bruce, One of the things we're looking at in 1.9 is gcc 5.x support by default. One of the areas this has significant impact is on the kernels, linux-yocto in particular. I'm starting to see a potential problem here since the kernels don't appear to work well with gcc 5.x: http://errors.yoctoproject.org/Errors/Search/?items=10&query=1426e31f0bcd19f066931d2ecbdec3752b14e88e&limit=150&order_by=RECIPE (this is a test build I ran just to see how bad things were). Are we going to be in a position to get 5.x support backported into 3.14 (and maybe 3.10)? Or was we going to have to wait for later versions? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OEDAM Minutes: March 2015
Minutes from the 2-day OE Developer's (American) Meeting in San Jose, CA in March. All errors are mine. These are also posted on the OE wiki page for OEDAM 2015. OEDAM: OpenEmbedded Developer's (American) Meeting March 27-28, 2015 ___ ATTENDANCE in room: mark hatle michael halstead bill mills paul eggleton denys dmitryenko sean hudson armin kuster tim orling philip balister sona sarmadi martin jansa ken sharp stephen arnold changhyeok bae herb kuta benjamin esquivel grant likely jefro phone: richard purdie belen barros pena beth flanagan bruce ashfield (Apologies if I missed your name - jefro) ___ AGENDA & SUMMARY open issues & action items marked with => OEDAM 2014 summary => Lava - kernel ci can use it, not required; YP QA team experimenting => TSC role - board needs to run election, koen willing to be replaced why is embedded still hard - progress making it marginally easier layer quality - ongoing process lune - setup image replacement, spurred demo discussion next +1 - discussed local.conf from third parties - Security testing security patches high priority, not all in one place => sona proposed security mailing list for monitoring, patches, policy & agreed to investigate possible CVE database owner: sona & fray Infrastructure github repos - obsolete repos going away June 30 make it obvious github is a mirror OE-classic - keeping for historical reasons only => read-only & rename to oe-classic? oe-obsolete? => ok to disable push requests from github.com? owner: crofton Layer maintenance build status reporting is better, incl. blacklisting bad recipes layer index is very positive, does not (yet?) report layer quality possible toaster integration in the future Improving demos noted SDR demo in YP booth at ELC running on different SoCs html5/luna replacement for sato desired what is good for developers vs. what makes a good demo - discussion => bmills suggested a monthly technical meeting to work on these issues => jefro to schedule meeting about demos: test images, sato, etc identify problem, role of sato, suitable alternatives & usage cases Patch review process RP outlined patch review process some aberrations in process illustrated - need tool improvement some resources could be put into improving patchwork to automate some processes that are currently manual paul suggests adding functionality tests => general conclusion to focus on package managers, feeds, tools => sources from bitbake world builds moving to new location crofton/michael will update DNS, should be invisible Tests autobuilder provides many testing featuers, automated qemu, ptests OE self test doesn't run on autobuilder (takes too long) => need more resources from community test mentoring helpful Development cycle paul asks whether the current dev cycle works 4-cycle system w/milestones (in YP) works well testing could be improved as per previous discussion some people still hold things back until last minute, RC process using smart for RPM: => smart needs a new maintainer brief discussion about YP technical call - terse agenda & minutes => jefro to work with sjolley to add RP's readout to minutes discussion about collecting sources for an OE source mirror # packages armin asks, should there be a limit on packages in OE fray & RP suggest OE has a self-imposed feature limit, by testing => discuss within TSC documentation more technical documentation resources needed => crofton to mention to Advisory Board OE eV SPI working well changing eV structure, sean streamlining, possibly moving to US next GA & possible OEDEM after ELCE in October/Dublin Community Development / Team Building Intro / crash course events => jefro to investigate materials, resources for promotion Coordinated bug day sprints note: general feeling that janitors list is misnamed => jefro - remind stephen to add triage info to bug list => crofton/paul - set up bug day US a.m., UK/EU afternoon separate event for Asia => jefro - investigate webinar format website/wiki wiki cleanup needed, Jack's front page work? => jefro - organize as board/TSC administrative issue TSC meetings communication has been very important, now missing => organize issues & meetings every 2 months community metrics => jefro - work with board Other group/meetup activities openhatch, internship programs like opw => all - contribute to Stack Overflow support/discussions next OEDAM concurrent with ELC in San Diego, March 2016 ___ DETAIL Full text minutes available at: http://pastebin.com/
Re: [OE-core] [dizzy][PATCH] mesa: update --with-llvm-shared-libs configure option
On Wed, May 06, 2015 at 11:37:44PM -0700, Khem Raj wrote:
>
> > On May 6, 2015, at 8:39 AM, Martin Jansa wrote:
> >
> > On Fri, May 01, 2015 at 07:47:42PM +0200, Martin Jansa wrote:
> >> From: Andre McCurdy
> >>
> >> As per the Mesa 10.2 release notes, "--with-llvm-shared-libs"
> >> has been renamed to "--enable-llvm-shared-libs".
> >>
> >> http://www.mesa3d.org/relnotes/10.2.html
> >
> > Be aware that this correctly enables gallium-llvm, but then
> > gbm_gallium_drm can fail to find LLVM libs:
> >
> > ld: cannot find -lLLVMMCJIT
> > | collect2: error: ld returned 1 exit status
> > | make[3]: *** [gbm_gallium_drm.la] Error 1
> >
> > at least in some configurations, I'm looking what's the difference in
> > builds I'm seeing failing.
>
> is LLVM_CONFIG set to point to valid llvm-config ?
Yes, but the libraries weren't staged by llvm3.3
sysroots/qemux86/usr/bin/crossscripts/llvm-config --libs
-lLLVMTableGen -lLLVMDebugInfo -lLLVMOption -lLLVMX86Disassembler
-lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter
-lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils
-lLLVMIRReader -lLLVMAsmParser -lLLVMMCDisassembler -lLLVMMCParser
-lLLVMInstrumentation -lLLVMArchive -lLLVMBitReader -lLLVMInterpreter
-lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMBitWriter -lLLVMMCJIT
-lLLVMJIT -lLLVMCodeGen -lLLVMObjCARCOpts -lLLVMScalarOpts
-lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis
-lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC
-lLLVMObject -lLLVMCore -lLLVMSupport
Maybe the LLVM_COMPONENTS passed from mesa configure are a bit wider
now:
sysroots/qemux86/usr/bin/crossscripts/llvm-config --libs engine
bitwriter
-lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser
-lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser
-lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT
-lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMObjCARCOpts
-lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa
-lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore
-lLLVMSupport
sysroots/qemux86/usr/bin/crossscripts/llvm-config --libs engine
bitwriter
-lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser
-lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser
-lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT
-lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMObjCARCOpts
-lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa
-lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore
-lLLVMSupport
sysroots/qemux86/usr/bin/crossscripts/llvm-config --ldflags
-L/sysroots/qemux86/usr/lib/llvm3.3
-lz -lpthread -lrt -ldl -lm
sysroot only has these:
/sysroots/qemux86/usr/lib/libLLVM-3.3.so
/sysroots/qemux86/usr/lib/llvm3.3/libLTO.so
/sysroots/qemux86/usr/lib/llvm3.3/LLVMHello.so
/sysroots/qemux86/usr/lib/llvm3.3/BugpointPasses.so
/sysroots/qemux86/usr/lib/llvm3.3/libprofile_rt.so
/sysroots/qemux86/usr/lib/llvm3.3/libLLVM-3.3.so
/sysroots/qemux86/usr/lib/llvm3.3/
/sysroots/qemux86/usr/lib/
static libs were built:
../../../llvm3.3/3.3-r0/llvm-3.3.build/Release/lib/libLLVMJIT.a
../../../llvm3.3/3.3-r0/image/usr/lib/llvm3.3/libLLVMJIT.a
../../../llvm3.3/3.3-r0/package/usr/lib/llvm3.3/libLLVMJIT.a
but not staged.
I don't see anything obvious in log.do_configure, most suspicious part
is:
llvm3.3/3.3-r0/llvm-3.3.src/configure: line 1990: -O2: command not found
llvm3.3/3.3-r0/llvm-3.3.src/configure: line 1991: -O2: command not found
caused by:
${CFLAGS=}
${CXXFLAGS=}
in configure script
I'll try to downgrade mesa to see what was different there.
Regards,
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
> On May 13, 2015, at 4:03 AM, Paul Eggleton
> wrote:
>
> On Wednesday 13 May 2015 10:27:34 ChenQi wrote:
>> On 05/13/2015 09:56 AM, Khem Raj wrote:
On May 12, 2015, at 6:45 PM, ChenQi wrote:
On 05/13/2015 12:19 AM, Khem Raj wrote:
>> On May 11, 2015, at 11:19 PM, Chen Qi wrote:
>>
>> -install
>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN
>> E_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh
>> ${SDK_OUTPUT}/${SDKPATH} + # find latest buildtools-tarball and
>> install it
>> +buildtools_path=`ls -t1
>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN
>> E_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` +
> install
>> $buildtools_path ${SDK_OUTPUT}/${SDKPATH}
>
> why not create a symink instead of poking using wild chars
Because it's simpler.
>>>
>>> what happens if I touch an older installer ?
>>
>> Hi Khem,
>>
>> I make this patch to avoid installing a non-existent buildools-tarball.
>> If we touch an old buildtools-tarball, the installation would still
>> succeed. The touched one is installed.
>> What would lead to a potential problem is the following situation.
>> The user built buildtools-tarball, after one day, he modified key part
>> of buildtools-tarball recipe, rebuilt it, and then he deliberately
>> touched the old one, and then he built an ext SDK.
>> I don't think that's a situation we need to take care of.
>> But if you insist that we should, you can suggest a reasonable symlink
>> name and I would make a new patch.
>
> Honestly I don't see this is as being a problem we need to handle - who is
> going to touch this file during normal usage? Builds failing under the
> conditions described is a much more pressing issue at this point.
>
It has caused issues when we used such an approach for other artifacts
and debugging it was hard since we lost trackability with wildcads I was just
sharing the experience. Ofcource
the issue at hand is always pressing thats why we are fixing it.
> It could be that we should re-visit whether using buildtools-tarball rather
> than having its contents be part of the native portion of the SDK is the right
> approach. I'm not sure that we need to do that just at this moment though.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Changing external kernel module results in rebuild of whole kernel
On Wed, 2015-05-13 at 11:33 +0100, Richard Purdie wrote: > On Tue, 2015-05-12 at 08:01 +0200, Mike Looijmans wrote: > > As things are now, I'd much prefer the "taring up and then extracting a > > large > > (GB) sized sstate object" option, since that at least worked correctly. > > Sorry for the delayed reply, I didn't understand exactly what was > happening without looking at a build. By far the easiest "fix" right now > is: > > RM_WORK_EXCLUDE += "" > > This won't cost that much diskspace and should avoid the problem you're > seeing. > > The problem is module.bbclass has a DEPENDS on virtual/kernel which > means it depends on :do_populate_sysroot. As well as triggering > the unpack to repopulate the shared work area for the kernel, this means > it will cause the thing to effectively repackage. > > There are various ideas coming to mind: > > * We could drop virtual/kernel from DEPENDS which would shorten the > kernel dependency chain by removing populate_sysroot from the equation. > > * We could change the task dependencies of populate_sysroot in > kernel.bbclass so that it doesn't depend on do_install (it doesn't > handle files any more now anyway). > > * We could figure out why populate_sysroot from sstate isn't good enough > for bitbake and change the sstate code to use sstate more heavily. If I > remember rightly, we currently rerun all a task's tasks rather than pull > it half from sstate and half not. > > None of these jumps out at me as an easy or necessarily desirable fix. I do have some patches: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c4aed2ba7ae74e54a4ae8ac7aeda291704bde82a https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=7a20f175c0a1cdec208471e5f7ff5f560f0b609e https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c5f3cdca3e16d90c4e5bbb3abe5e136b8025f1a4 What I've noticed is that rm_work does not remove the data from shared-work. What it does do is remove the stamp file which causes all the tasks to rerun even if the data was there. The above patches make "do_shared_work" a semi sstate task, one which is never generated into the sstate feed but does have the right stamp functionality. This basically stops kernel modules from rerunning kernel tasks even with rm_work. Whether these patches are a good idea, I'm less sure. Bruce: You might want to look at the module.bbclass changes in the first patch. I think there is some duplication between module and module-base I need to remove. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] linux-yocto and gcc 5.x
I'll do an explicit round of gcc5 support in master for the kernels we have there in the not to distant future. To throw the switch for gcc5, we'll obviously want all the architectures to build and boot. To keep things practical, I'll start from the -dev kernel, then back to the LTSI kernels we still have in master. In the meantime, if anyone has patches, sending them to the linux-yocto mailing list is appreciated. Since everyone has eyes and ears on different lists it makes the effort that much easier if we collect changes in advance on a single list. Bruce On 2015-05-13 03:39 AM, Robert Yang wrote: I think that I met another problem when MACHINE = qemuarm64 with gcc5: linux-yocto_3.19.bb: /tmp/ccWk2lM2.s: Assembler messages: /tmp/ccWk2lM2.s:42: Error: .err encountered /tmp/ccWk2lM2.s:43: Error: .err encountered /tmp/ccWk2lM2.s:44: Error: .err encountered /tmp/ccWk2lM2.s:103: Error: .err encountered /tmp/ccWk2lM2.s:104: Error: .err encountered /tmp/ccWk2lM2.s:105: Error: .err encountered make[3]: *** [arch/arm64/kernel/psci.o] Error 1 make[3]: *** Waiting for unfinished jobs CC mm/mmzone.o CC mm/vmstat.o CC mm/backing-dev.o CC net/socket.o make[2]: *** [arch/arm64/kernel] Error 2 make[2]: *** Waiting for unfinished jobs // Robert On 05/11/2015 09:20 PM, Richard Purdie wrote: Hi Bruce, One of the things we're looking at in 1.9 is gcc 5.x support by default. One of the areas this has significant impact is on the kernels, linux-yocto in particular. I'm starting to see a potential problem here since the kernels don't appear to work well with gcc 5.x: http://errors.yoctoproject.org/Errors/Search/?items=10&query=1426e31f0bcd19f066931d2ecbdec3752b14e88e&limit=150&order_by=RECIPE (this is a test build I ran just to see how bad things were). Are we going to be in a position to get 5.x support backported into 3.14 (and maybe 3.10)? Or was we going to have to wait for later versions? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] README: add "Contributing" section
On Wednesday 13 May 2015 13:07:28 Mario Domenech Goulart wrote: > On Wed, 13 May 2015 09:54:39 +0100 Paul Eggleton wrote: > > On Wednesday 13 May 2015 07:17:01 Anders Darander wrote: > >> * Mario Domenech Goulart [150512 16:58]: > >> > +Contributing > >> > + > >> > + > >> > +To contribute to this layer you should submit the patches for > >> > +review to the mailing list (openembedded-core@lists.openembedded.org). > >> > + > >> > +Please refer to: > >> > +http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > >> > +for some useful guidelines to be followed when submitting patches. > >> > + > >> > +Mailing list: > >> > + > >> > +http://lists.openembedded.org/mailman/listinfo/openembedded-core > >> > + > >> > +Source code: > >> > + > >> > +http://git.openembedded.org/openembedded-core/ > >> > + > >> > +When sending patches, please use something like: > >> > + > >> > +git send-email --to openembedded-core@lists.openembedded.org > >> > > >> > >> Maybe we could add something about the helper scripts: > >> > >> scripts/create-pull-request > >> scripts/send-pull-request > >> > >> or do you think that those scripts might be out of scope for the primary > >> intended audience of this section? > > > > My suggestion would be to link to the following page instead which covers > > all> > > the options and explains how to use them: > > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded > > > > We can probably drop the "commit message guidelines" link at the same time > > since the above page already links to that. > > Thanks guys for the suggestions. > > Paul: do you mean dropping everything and add something like > > > Contributing > > > Please refer to > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded > for guidelines on how to submit patches. > > > ? Or keep everything and just replace the guidelines link? I think the best plan would be to 1) edit the contributing section as you posted above, and 2) drop the "When sending patches..." bit. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] README: add "Contributing" section
Tips on how to submit patches and links to source code and mailing list. Signed-off-by: Mario Domenech Goulart --- README | 14 ++ 1 file changed, 14 insertions(+) diff --git a/README b/README index 665c98f..521916c 100644 --- a/README +++ b/README @@ -13,3 +13,17 @@ which can be found at: http://yoctoproject.org/documentation +Contributing + + +Please refer to +http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded +for guidelines on how to submit patches. + +Mailing list: + +http://lists.openembedded.org/mailman/listinfo/openembedded-core + +Source code: + +http://git.openembedded.org/openembedded-core/ -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] README: add "Contributing" section
On Wed, 13 May 2015 09:54:39 +0100 Paul Eggleton wrote: > On Wednesday 13 May 2015 07:17:01 Anders Darander wrote: >> * Mario Domenech Goulart [150512 16:58]: >> > +Contributing >> > + >> > + >> > +To contribute to this layer you should submit the patches for >> > +review to the mailing list (openembedded-core@lists.openembedded.org). >> > + >> > +Please refer to: >> > +http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines >> > +for some useful guidelines to be followed when submitting patches. >> > + >> > +Mailing list: >> > + >> > +http://lists.openembedded.org/mailman/listinfo/openembedded-core >> > + >> > +Source code: >> > + >> > +http://git.openembedded.org/openembedded-core/ >> > + >> > +When sending patches, please use something like: >> > + >> > +git send-email --to openembedded-core@lists.openembedded.org >> > >> >> Maybe we could add something about the helper scripts: >> >> scripts/create-pull-request >> scripts/send-pull-request >> >> or do you think that those scripts might be out of scope for the primary >> intended audience of this section? > > My suggestion would be to link to the following page instead which covers all > the options and explains how to use them: > > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded > > We can probably drop the "commit message guidelines" link at the same time > since the above page already links to that. Thanks guys for the suggestions. Paul: do you mean dropping everything and add something like Contributing Please refer to http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded for guidelines on how to submit patches. ? Or keep everything and just replace the guidelines link? Best wishes. Mario -- http://www.ossystems.com.br -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] guile, mailx, gcc, opensp, gstreamer1.0-libav, libunwind: disable thumb where it fails for qemuarm
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/gcc/gcc_4.9.bb | 23 ++
meta/recipes-devtools/guile/guile_2.0.11.bb| 19 ++
meta/recipes-devtools/opensp/opensp_1.5.2.bb | 5 +
meta/recipes-extended/mailx/mailx_12.5.bb | 4
.../gstreamer/gstreamer1.0-libav_1.4.5.bb | 9 +
meta/recipes-support/libunwind/libunwind_1.1.bb| 6 ++
6 files changed, 66 insertions(+)
diff --git a/meta/recipes-devtools/gcc/gcc_4.9.bb
b/meta/recipes-devtools/gcc/gcc_4.9.bb
index c4827c6..9561b86 100644
--- a/meta/recipes-devtools/gcc/gcc_4.9.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.9.bb
@@ -4,4 +4,27 @@ require gcc-target.inc
# Building with thumb enabled on armv4t fails with
# | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7438:(.text.unlikely+0x2fa):
relocation truncated to fit: R_ARM_THM_CALL against symbol `fancy_abort(char
const*, int, char const*)' defined in .glue_7 section in linker stubs
# | gcc-4.8.1-r0/gcc-4.8.1/gcc/cp/decl.c:7442:(.text.unlikely+0x318):
additional relocation overflows omitted from the output
+# and on armv5te (qemuarm) it fails with ICE:
+# |
/home/jenkins/oe/world/shr-core/tmp-glibc/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/cse.c:5949:1:
error: unable to generate reloads for:
+# | }
+# | ^
+# | (jump_insn 3586 13095 8302 510 (parallel [
+# | (set (pc)
+# | (if_then_else (lt (plus:SI (reg:SI 4908 [3615])
+# | (reg:SI 4876))
+# | (const_int 0 [0]))
+# | (label_ref 3590)
+# | (pc)))
+# | (set (reg:SI 3252)
+# | (plus:SI (reg:SI 4908 [3615])
+# | (reg:SI 4876)))
+# | (clobber (mem/c:SI (reg:SI 5320) [107 %sfp+-208 S4 A32]))
+# | ])
/home/jenkins/oe/world/shr-core/tmp-glibc/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/cse.c:5174
225 {*addsi3_cbranch}
+# | (expr_list:REG_DEAD (reg:SI 5320)
+# | (expr_list:REG_DEAD (reg:SI 4908 [3615])
+# | (expr_list:REG_DEAD (reg:SI 4876)
+# | (int_list:REG_BR_PROB 2100 (nil)
+# | -> 3590)
+# |
/home/jenkins/oe/world/shr-core/tmp-glibc/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/cse.c:5949:1:
internal compiler error: in curr_insn_transform, at lra-constraints.c:3362
ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
diff --git a/meta/recipes-devtools/guile/guile_2.0.11.bb
b/meta/recipes-devtools/guile/guile_2.0.11.bb
index d1578e0..025eb54 100644
--- a/meta/recipes-devtools/guile/guile_2.0.11.bb
+++ b/meta/recipes-devtools/guile/guile_2.0.11.bb
@@ -104,3 +104,22 @@ guile_sstate_postinst() {
find ${STAGING_DIR_TARGET}/${libdir}/guile/2.0/ccache -type f
| xargs touch
fi
}
+
+# Fails to build for qemuarm:
+# | {standard input}: Assembler messages:
+# | {standard input}:16707: Error: instruction not supported in Thumb16 mode
-- `adds r0,r2,r4'
+# | {standard input}:16707: Error: lo register required -- `str r0,[r8]'
+# | {standard input}:18192: Error: instruction not supported in Thumb16 mode
-- `subs r0,r2,r4'
+# | {standard input}:18192: Error: lo register required -- `str r0,[r8]'
+# | {standard input}:18279: Error: selected processor does not support Thumb
mode `smull r3,r6,r2,r6'
+# | {standard input}:34878: Error: instruction not supported in Thumb16 mode
-- `subs r0,r2,r4'
+# | {standard input}:34878: Error: lo register required -- `str r0,[r8]'
+# | {standard input}:35148: Error: selected processor does not support Thumb
mode `smull r3,r5,r2,r5'
+# | {standard input}:35241: Error: instruction not supported in Thumb16 mode
-- `adds r0,r2,r4'
+# | {standard input}:35241: Error: lo register required -- `str r0,[r8]'
+# | {standard input}:16707: Error: branch out of range
+# | {standard input}:18192: Error: branch out of range
+# | {standard input}:34878: Error: branch out of range
+# | {standard input}:35241: Error: branch out of range
+# | make[3]: *** [libguile_2.0_la-vm.lo] Error 1
+ARM_INSTRUCTION_SET = "arm"
diff --git a/meta/recipes-devtools/opensp/opensp_1.5.2.bb
b/meta/recipes-devtools/opensp/opensp_1.5.2.bb
index a1f115c..a9f03a4 100644
--- a/meta/recipes-devtools/opensp/opensp_1.5.2.bb
+++ b/meta/recipes-devtools/opensp/opensp_1.5.2.bb
@@ -53,3 +53,8 @@ do_install_append_class-native() {
FILES_${PN} += "${datadir}/OpenSP/"
BBCLASSEXTEND = "native"
+
+# Fails to build with thumb-1 (qemuarm)
+# | {standard input}: Assembler messages:
+# | {standard input}: Error: unaligned opcodes detected in executable segment
+ARM_INSTRUCTION_SET = "arm"
diff --git a/meta/recipes-extended/mailx/mailx_12.5.bb
b/meta/recipes-extended/mailx/mailx_12.5.bb
index a53da3a..3b49145 100644
--- a/meta/recipes-extended/mailx/mailx_12.5.bb
+++ b/meta/recipes-extended/mailx/mailx_12.5.bb
@@ -34,3 +34,7 @@ EXTRA_OEMAKE = "SENDMAIL=${sbindir}/sendmail"
# fio.c:56:17: fatal error: ssl.h: No such fi
[OE-core] State of bitbake world, Failed tasks 2015-05-12
After longer delay caused by completely broken builds here is new status
update:
http://www.openembedded.org/wiki/Bitbake_World_Status
== Failed tasks 2015-05-12 ==
INFO: jenkins-job.sh-1.3.1 Complete log available at
http://logs.nslu2-linux.org/buildlogs/oe/world/log.report.20150513_122102.log
=== common () ===
=== common-x86 (0) ===
=== qemuarm (5) ===
* /meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_2.1.4.bb,
do_compile
* /meta-openembedded/meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb, do_compile
* /meta-openembedded/meta-oe/recipes-qt/fingerterm/fingerterm.bb,
do_configure
*
/meta-openembedded/meta-xfce/recipes-apps/xfce4-screenshooter/xfce4-screenshooter_1.8.2.bb,
do_compile
*
/meta-smartphone/meta-aurora/recipes-aurora/aurora/aurora-systemmanager_git.bb,
do_compile
=== qemux86 (4) ===
* /meta-browser/recipes-browser/chromium/cef3_280796.bb, do_package_qa
* /meta-browser/recipes-browser/chromium/cef3_280796.bb, do_populate_sysroot
*
/meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb,
do_compile
* /meta-openembedded/meta-oe/recipes-extended/acpica/acpica_20140828.bb,
do_compile
=== qemux86_64 (3) ===
* /meta-browser/recipes-browser/chromium/cef3_280796.bb, do_configure
* /meta-openembedded/meta-oe/recipes-support/fftw/fftw_3.3.4.bb, do_compile
*
/meta-smartphone/meta-aurora/recipes-aurora/aurora/aurora-systemmanager_git.bb,
do_patch
=== Number of failed tasks (14) ===
{| class=wikitable
|-
|| qemuarm || 5 ||
http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20150511_133237.log//
|| http://errors.yoctoproject.org:80/Errors/Build/5844/
|-
|| qemux86 || 6 ||
http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20150512_032318.log//
|| http://errors.yoctoproject.org:80/Errors/Build/5848/
|-
|| qemux86_64 || 3 ||
http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20150512_200918.log//
|| http://errors.yoctoproject.org:80/Errors/Build/5870/
|}
=== PNBLACKLISTs (69) ===
=== QA issues (603) ===
{| class=wikitable
!| Count||Issue
|-
||1 ||libdir
|-
||14||build-deps
|-
||3 ||already-stripped
|-
||30||file-rdeps
|-
||491 ||version-going-backwards
|-
||64||textrel
|}
PNBLACKLISTs:
openembedded-core/:
meta-browser:
meta-openembedded:
meta-efl/recipes-efl/e17/diskio_svn.bb:PNBLACKLIST[diskio] ?= "broken: switch
to https://git.enlightenment.org/enlightenment/modules/diskio.git/ and fix
0.0.1+svnr82070-r0.0/E-MODULES-EXTRA/diskio/e-module-diskio.edc:58. invalid
state name: 'off'. "default" state must always be first."
meta-efl/recipes-efl/efl/entrance_svn.bb:PNBLACKLIST[entrance] ?= "broken:
switch to https://git.enlightenment.org/misc/entrance.git and fix
0.0.4+svnr82070-r7/entrance/data/themes/old/default.edc:678. invalid state
name: 'defaault'. "default" state must always be first."
meta-efl/recipes-navigation/mcnavi/mcnavi_0.3.4.bb:PNBLACKLIST[mcnavi] ?=
"BROKEN: latest version 0.3.4 is 3 years old and now broken with more strict
ejde_cc from efl-1.13"
meta-filesystems/recipes-filesystems/ifuse/ifuse_1.1.2.bb:PNBLACKLIST[ifuse] ?=
"depends on blacklisted libimobiledevice"
meta-gnome/recipes-apps/gnome-mplayer/gnome-mplayer_1.0.5.bb:PNBLACKLIST[gnome-mplayer]
?= "rdepends on blacklisted mplayer"
meta-gnome/recipes-gnome/gcr/gcr_3.8.2.bb:PNBLACKLIST[gcr] ?= "CONFLICT: 4
files conflict with gnome-keyring"
meta-gnome/recipes-gnome/gnome-menus/gnome-menus3_3.10.1.bb:PNBLACKLIST[gnome-menus3]
?= "CONFLICT: 24 files are conflicting with gnome-menus"
meta-gnome/recipes-gnome/gnome-panel/gnome-panel3_3.0.2.bb:PNBLACKLIST[gnome-panel3]
?= "CONFLICT: depends on libgweather3 which conflicts with libgweather"
meta-gnome/recipes-gnome/gweather/libgweather3_3.0.2.bb:PNBLACKLIST[libgweather3]
?= "CONFLICT: 876 files are conflicting with libgweather"
meta-gnome/recipes-gnome/zenity/zenity_2.32.1.bb:PNBLACKLIST[zenity] ?=
"BROKEN: doesn't build with B!=S"
meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:PNBLACKLIST[xbmc] ?=
"/usr/include/c++/ctime:70:11: error: '::gmtime' has not been declared"
meta-multimedia/recipes-multimedia/coriander/coriander_2.0.2.bb:PNBLACKLIST[coriander]
?= "BROKEN: fails to use SDL probably because libsdl-config was removed,
error: unknown type name 'SDL_Overlay'"
meta-multimedia/recipes-multimedia/dleyna/renderer-service-upnp_0.3.0.bb:PNBLACKLIST[renderer-service-upnp]
?= "BROKEN: doesn't build with B!=S (trying to install rendererconsole.py from
${B} instead of ${S})"
meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb:PNBLACKLIST[snort]
?= "BROKEN: autotools processing causes OOM condition on configure"
meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.16.bb:PNBLACKLIST[lksctp-tools]
?= "${@base_contains('DISTRO_FEATURES', 'ld-is-gold', "BROKEN: fails to link
against sctp_connectx symbol", '', d)}"
meta-networking/recipes-support/nis/yp-tools_3.3.bb:PNBLACKL
Re: [OE-core] [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball
On Wednesday 13 May 2015 10:27:34 ChenQi wrote:
> On 05/13/2015 09:56 AM, Khem Raj wrote:
> >> On May 12, 2015, at 6:45 PM, ChenQi wrote:
> >>
> >> On 05/13/2015 12:19 AM, Khem Raj wrote:
> On May 11, 2015, at 11:19 PM, Chen Qi wrote:
>
> -install
> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN
> E_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh
> ${SDK_OUTPUT}/${SDKPATH} + # find latest buildtools-tarball and
> install it
> +buildtools_path=`ls -t1
> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN
> E_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` +
install
> $buildtools_path ${SDK_OUTPUT}/${SDKPATH}
> >>>
> >>> why not create a symink instead of poking using wild chars
> >>
> >> Because it's simpler.
> >
> > what happens if I touch an older installer ?
>
> Hi Khem,
>
> I make this patch to avoid installing a non-existent buildools-tarball.
> If we touch an old buildtools-tarball, the installation would still
> succeed. The touched one is installed.
> What would lead to a potential problem is the following situation.
> The user built buildtools-tarball, after one day, he modified key part
> of buildtools-tarball recipe, rebuilt it, and then he deliberately
> touched the old one, and then he built an ext SDK.
> I don't think that's a situation we need to take care of.
> But if you insist that we should, you can suggest a reasonable symlink
> name and I would make a new patch.
Honestly I don't see this is as being a problem we need to handle - who is
going to touch this file during normal usage? Builds failing under the
conditions described is a much more pressing issue at this point.
It could be that we should re-visit whether using buildtools-tarball rather
than having its contents be part of the native portion of the SDK is the right
approach. I'm not sure that we need to do that just at this moment though.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] WARNING: The license listed CLOSED was not in the licenses collected for foo
On 08.05.2015 14:39, Paul Eggleton wrote: > Hi Steffen, > > On Friday 08 May 2015 13:07:35 Steffen Sledz wrote: >> Since switching from dizzy to fido we've some warnings related to some of >> our own closed source packages. >> >> WARNING: log_check: There is a warn message in the logfile >> WARNING: log_check: Matched keyword: [WARNING:] >> WARNING: log_check: WARNING: The license listed CLOSED was not in the >> licenses collected for foo >> >> The recipes contain lines like this one: >> >> LICENSE = "CLOSED" >> >> How should we fix the recipe to avoid the warning? > > I think the part of the code that produces this warning probably should be > ignoring the CLOSED value. Can I ask you to please file a bug? Feel free to > add > me on CC. https://bugzilla.yoctoproject.org/show_bug.cgi?id=7752 -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Changing external kernel module results in rebuild of whole kernel
On Tue, 2015-05-12 at 08:01 +0200, Mike Looijmans wrote: > On 06-05-15 14:35, Richard Purdie wrote: > > On Wed, 2015-05-06 at 08:35 +0200, Mike Looijmans wrote: > >> Something in recent OE-core triggered a weird dependency "backfire". > >> > >> If I change a recipe for a kernel module (a bb recipe that does "inherit > >> module") this will trigger a rebuild of the whole kernel. > >> > >> This turns the 5-second job of just updating a single module into a several > >> minute workout for the build machine, and then causes boards to re-write > >> the > >> kernel into flash needlessly when upgrading. > >> > >> I now see this on all projects using OE-core master. I can't really pin > >> what > >> caused it though. Anyone else seen this? > > > > I have a suspicion this may be as a result of the changed kernel build > > process in 1.8. > > > > The idea there is that the modules depend on the kernel source and > > rather than taring up and then extracting a large (GB) sized sstate > > object, we just extract the original kernel source. > > > > So is the kernel really rebuilding, or, is it just extracting source for > > the kernel to build against? I noticed rm_work in your other post and > > this may also be some bad interaction between rm_work and the kernel > > build process changes. > > Any things I can try or provide on this? > > As things are now, I'd much prefer the "taring up and then extracting a large > (GB) sized sstate object" option, since that at least worked correctly. Sorry for the delayed reply, I didn't understand exactly what was happening without looking at a build. By far the easiest "fix" right now is: RM_WORK_EXCLUDE += "" This won't cost that much diskspace and should avoid the problem you're seeing. The problem is module.bbclass has a DEPENDS on virtual/kernel which means it depends on :do_populate_sysroot. As well as triggering the unpack to repopulate the shared work area for the kernel, this means it will cause the thing to effectively repackage. There are various ideas coming to mind: * We could drop virtual/kernel from DEPENDS which would shorten the kernel dependency chain by removing populate_sysroot from the equation. * We could change the task dependencies of populate_sysroot in kernel.bbclass so that it doesn't depend on do_install (it doesn't handle files any more now anyway). * We could figure out why populate_sysroot from sstate isn't good enough for bitbake and change the sstate code to use sstate more heavily. If I remember rightly, we currently rerun all a task's tasks rather than pull it half from sstate and half not. None of these jumps out at me as an easy or necessarily desirable fix. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] opkg-utils: Change alternatives lib path from /usr/lib/opkg to /var/lib/opkg
Please make it respect the variable used in opkg.
On Wed, May 13, 2015 at 11:41 AM, Li Zhou wrote:
> When update-alternatives is moved from opkg to opkg-utils, a line in
> the file is changed
> from
> to .
> But opkglibdir doesn't equal to "/usr/lib" here, but equal to "/var/lib"
> in oe-core build by configuring --with-opkglibdir.
> opkg-utils can't get the var value in opkg, so here change back the
> directory in update-alternatives only.
>
> Signed-off-by: Li Zhou
> ---
> ...Change-alternatives-lib-path-from-usr-lib.patch | 36
>
> meta/recipes-devtools/opkg-utils/opkg-utils_git.bb |4 ++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
> create mode 100644
> meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
>
> diff --git
> a/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
> b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
> new file mode 100644
> index 000..60d2a1f
> --- /dev/null
> +++
> b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
> @@ -0,0 +1,36 @@
> +From 5ca5f2f4a6b1bd82a1349542f4541c017cb5c132 Mon Sep 17 00:00:00 2001
> +From: Li Zhou
> +Date: Wed, 13 May 2015 15:12:10 +0800
> +Subject: [PATCH] opkg-utils: Change alternatives lib path from
> /usr/lib/opkg
> + to /var/lib/opkg
> +
> +When update-alternatives is moved from opkg to opkg-utils, a line in
> +the file is changed
> +from
> +to .
> +But opkglibdir doesn't equal to "/usr/lib" here, but equal to "/var/lib"
> + in oe-core build by configuring --with-opkglibdir.
> +opkg-utils can't get the var value in opkg, so here change back the
> +directory in update-alternatives only.
> +Upstream-Status: Inappropriate [It is related with oe-core configuration.]
> +Signed-off-by: Li Zhou
> +---
> + update-alternatives |2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/update-alternatives b/update-alternatives
> +index c332309..b08ecc0 100644
> +--- a/update-alternatives
> b/update-alternatives
> +@@ -21,7 +21,7 @@
> + set -e
> +
> + # admin dir
> +-ad="$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives"
> ++ad="$OPKG_OFFLINE_ROOT/var/lib/opkg/alternatives"
> +
> + usage() {
> + echo "update-alternatives: $*
> +--
> +1.7.9.5
> +
> diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> index 2800a5d..68d9a19 100644
> --- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
> @@ -10,7 +10,9 @@ PROVIDES += "virtual/update-alternatives"
> SRCREV = "53274f087565fd45d8452c5367997ba6a682a37a"
> PV = "0.1.8+git${SRCPV}"
>
> -SRC_URI = "git://git.yoctoproject.org/opkg-utils"
> +SRC_URI = "git://git.yoctoproject.org/opkg-utils \
> +
> file://0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch \
> +"
>
> S = "${WORKDIR}/git"
>
> --
> 1.7.9.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] opkg-utils: Change alternatives lib path from /usr/lib/opkg to /var/lib/opkg
When update-alternatives is moved from opkg to opkg-utils, a line in
the file is changed
from
to .
But opkglibdir doesn't equal to "/usr/lib" here, but equal to "/var/lib"
in oe-core build by configuring --with-opkglibdir.
opkg-utils can't get the var value in opkg, so here change back the
directory in update-alternatives only.
Signed-off-by: Li Zhou
---
...Change-alternatives-lib-path-from-usr-lib.patch | 36
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb |4 ++-
2 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
diff --git
a/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
new file mode 100644
index 000..60d2a1f
--- /dev/null
+++
b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch
@@ -0,0 +1,36 @@
+From 5ca5f2f4a6b1bd82a1349542f4541c017cb5c132 Mon Sep 17 00:00:00 2001
+From: Li Zhou
+Date: Wed, 13 May 2015 15:12:10 +0800
+Subject: [PATCH] opkg-utils: Change alternatives lib path from /usr/lib/opkg
+ to /var/lib/opkg
+
+When update-alternatives is moved from opkg to opkg-utils, a line in
+the file is changed
+from
+to .
+But opkglibdir doesn't equal to "/usr/lib" here, but equal to "/var/lib"
+ in oe-core build by configuring --with-opkglibdir.
+opkg-utils can't get the var value in opkg, so here change back the
+directory in update-alternatives only.
+Upstream-Status: Inappropriate [It is related with oe-core configuration.]
+Signed-off-by: Li Zhou
+---
+ update-alternatives |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/update-alternatives b/update-alternatives
+index c332309..b08ecc0 100644
+--- a/update-alternatives
b/update-alternatives
+@@ -21,7 +21,7 @@
+ set -e
+
+ # admin dir
+-ad="$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives"
++ad="$OPKG_OFFLINE_ROOT/var/lib/opkg/alternatives"
+
+ usage() {
+ echo "update-alternatives: $*
+--
+1.7.9.5
+
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 2800a5d..68d9a19 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -10,7 +10,9 @@ PROVIDES += "virtual/update-alternatives"
SRCREV = "53274f087565fd45d8452c5367997ba6a682a37a"
PV = "0.1.8+git${SRCPV}"
-SRC_URI = "git://git.yoctoproject.org/opkg-utils"
+SRC_URI = "git://git.yoctoproject.org/opkg-utils \
+
file://0001-opkg-utils-Change-alternatives-lib-path-from-usr-lib.patch \
+"
S = "${WORKDIR}/git"
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] README: add "Contributing" section
On Wednesday 13 May 2015 07:17:01 Anders Darander wrote: > * Mario Domenech Goulart [150512 16:58]: > > +Contributing > > + > > + > > +To contribute to this layer you should submit the patches for > > +review to the mailing list (openembedded-core@lists.openembedded.org). > > + > > +Please refer to: > > +http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > > +for some useful guidelines to be followed when submitting patches. > > + > > +Mailing list: > > + > > +http://lists.openembedded.org/mailman/listinfo/openembedded-core > > + > > +Source code: > > + > > +http://git.openembedded.org/openembedded-core/ > > + > > +When sending patches, please use something like: > > + > > +git send-email --to openembedded-core@lists.openembedded.org > > > > Maybe we could add something about the helper scripts: > > scripts/create-pull-request > scripts/send-pull-request > > or do you think that those scripts might be out of scope for the primary > intended audience of this section? My suggestion would be to link to the following page instead which covers all the options and explains how to use them: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded We can probably drop the "commit message guidelines" link at the same time since the above page already links to that. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] glibc: Fix x32 make race
On x32 builds, sysd-syscalls appears malformed since the make-target-directory
appears on the wrong line. This causes races during the build process where you
can
see failures like:
Assembler messages:
Fatal error: can't create
[...]glibc/2.21-r0/build-x86_64-poky-linux-gnux32/time/gettimeofday.os: No such
file or directory
Assembler messages:
Fatal error: can't create
[...]glibc/2.21-r0/build-x86_64-poky-linux-gnux32/time/time.os: No such file or
directory
The issue is that the carriage return is being escaped when it should
not be. The change to sysd-syscalls with this change:
before:
"""
$(foreach p,$(sysd-rules-targets),$(objpfx)$(patsubst %,$p,time).os): \
$(..)sysdeps/unix/make-syscalls.sh $(make-target-directory)
(echo '#include ';
"""
after:
"""
$(foreach p,$(sysd-rules-targets),$(objpfx)$(patsubst %,$p,time).os): \
$(..)sysdeps/unix/make-syscalls.sh
$(make-target-directory)
(echo '#include ';
"""
which ensures the target directory is correctly created. Only x32 uses the vdso
code which contains the bug which is why the error only really appears on x32.
Signed-off-by: Richard Purdie
diff --git a/meta/recipes-core/glibc/glibc/makesyscall.patch
b/meta/recipes-core/glibc/glibc/makesyscall.patch
new file mode 100644
index 000..9afb75e
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/makesyscall.patch
@@ -0,0 +1,48 @@
+On x32 builds, sysd-syscalls appears malformed since the make-target-directory
+appears on the wrong line. This causes races during the build process where
you can
+see failures like:
+
+Assembler messages:
+Fatal error: can't create
[...]glibc/2.21-r0/build-x86_64-poky-linux-gnux32/time/gettimeofday.os: No such
file or directory
+Assembler messages:
+Fatal error: can't create
[...]glibc/2.21-r0/build-x86_64-poky-linux-gnux32/time/time.os: No such file or
directory
+
+The isue is that the carridge return is being escaped when it should
+not be. The change to sysd-syscalls with this change:
+
+before:
+
+"""
+$(foreach p,$(sysd-rules-targets),$(objpfx)$(patsubst %,$p,time).os): \
+$(..)sysdeps/unix/make-syscalls.sh
$(make-target-directory)
+(echo '#include ';
+"""
+
+after:
+
+"""
+$(foreach p,$(sysd-rules-targets),$(objpfx)$(patsubst %,$p,time).os): \
+$(..)sysdeps/unix/make-syscalls.sh
+$(make-target-directory)
+(echo '#include ';
+"""
+
+which ensures the target directory is correctly created. Only x32 uses the
vdso
+code which contains the bug which is why the error only really appears on x32.
+
+Upstream-Status: Pending
+RP 2015/5/13
+
+Index: git/sysdeps/unix/make-syscalls.sh
+===
+--- git.orig/sysdeps/unix/make-syscalls.sh
git/sysdeps/unix/make-syscalls.sh
+@@ -278,7 +278,7 @@ while read file srcfile caller syscall a
+ vdso_symver=`echo "$vdso_symver" | sed 's/\./_/g'`
+ echo "\
+ \$(foreach p,\$(sysd-rules-targets),\$(objpfx)\$(patsubst %,\$p,$file).os): \\
+- \$(..)sysdeps/unix/make-syscalls.sh\
++ \$(..)sysdeps/unix/make-syscalls.sh
+ \$(make-target-directory)
+ (echo '#include '; \\
+echo 'extern void *${strong}_ifunc (void) __asm (\"${strong}\");'; \\
diff --git a/meta/recipes-core/glibc/glibc_2.21.bb
b/meta/recipes-core/glibc/glibc_2.21.bb
index 58a9601..ac8e8f8 100644
--- a/meta/recipes-core/glibc/glibc_2.21.bb
+++ b/meta/recipes-core/glibc/glibc_2.21.bb
@@ -26,6 +26,7 @@ SRC_URI =
"git://sourceware.org/git/glibc.git;branch=${BRANCH} \
file://0001-When-disabling-SSE-also-make-sure-that-fpmath-is-not.patch \
file://0001-yes-within-the-path-sets-wrong-config-variables.patch \
file://elf-Makefile-fix-a-typo.patch \
+ file://makesyscall.patch \
${EGLIBCPATCHES} \
"
EGLIBCPATCHES = "\
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] kernel: Pull uImage generation into separate class
On Wednesday, May 13, 2015 at 12:27:50 AM, Paul Eggleton wrote: > On Wednesday 13 May 2015 00:18:07 Marek Vasut wrote: > > On Tuesday, May 12, 2015 at 10:57:11 PM, Paul Eggleton wrote: > > [...] > > > > > > > > > To me this is about how we wish to structure these classes. > > > > > > > That's not my call, but to enumerate the options - unless I'm > > > > > > > missing something we have to choose between: > > > > > > > > > > > > > > 1) Hardcode uimage/fitimage. Hard to extend. > > > > > > > > > > > > > > 2) inherit kernel- and just insist that a class for every > > > > > > > image type exists. Ugly and kernel-*.bbclass already exists. > > > > > > > > > > > > > > 3) Try to search for a kernel- class and inherit it if > > > > > > > one is > > > > > > > found. AFAIK we don't do this kind of thing anywhere else so > > > > > > > this doesn't seem right to me. > > > > > > > > > > > > > > 4) Establish some other mechanism for registering kernel image > > > > > > > type > > > > > > > classes > > > > > > > (KERNEL_CLASSES ?). Not sure if we want to do this but it is at > > > > > > > least a > > > > > > > common mechanism elsewhere in the system. > > > > > > > > > > > > I wasn't familiar with an option like this, but if we can do > > > > > > something for the kernel classes that follows the existing > > > > > > patterns .. it makes a lot of sense. I really don't want to > > > > > > invent something new here either. > > > > > > > > > > > > So something along the lines of the way that image.bbclass works > > > > > > with > > > > > > the IMAGE_CLASSES ? > > > > > > > > > > Indeed, that's what I was referring to. > > > > > > > > Doesn't that mean it would be possible for kernel.bbclass to inherit > > > > multiple classes -- for example kernel-uimage.bbclass and > > > > kernel-fitimage.bbclass -- at the same time ? Won't that make it > > > > impossible to remove the kernel type checks in kernel-uimage.bbclass > > > > ? But maybe having those checks in place is the right thing to do > > > > since there might be a target building both fitImage and uImage at > > > > the same time? > > > > > > You will still need these checks, yes. To be honest I don't consider > > > having > > > those to be a bad thing though. > > > > I am not very fond of such "blanket if", it certainly doesn't look very > > nice and it looks confusingly redundant especially if the image type > > implementation is in it's own dedicated class. But if you consider this > > OK, I will thus try and implement the KERNEL_IMAGE_CLASSES (that might > > be a better name) approach. OK ? > > I think this is the best (or perhaps least worst) approach. KERNEL_CLASSES > probably would be a better name - there's nothing inherently image type > specific to this, we're just going to inherit its value. OKi, I will implement this and repost the series. Thanks! Best regards, Marek Vasut -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
