[yocto] [meta-security][PATCH 5/5] sssd: Add basic runtime test
This does some basic testing and checks.
Signed-off-by: Armin Kuster
---
lib/oeqa/runtime/cases/sssd.py | 37 ++
1 file changed, 37 insertions(+)
create mode 100644 lib/oeqa/runtime/cases/sssd.py
diff --git a/lib/oeqa/runtime/cases/sssd.py b/lib/oeqa/runtime/cases/sssd.py
new file mode 100644
index 000..4644836
--- /dev/null
+++ b/lib/oeqa/runtime/cases/sssd.py
@@ -0,0 +1,37 @@
+# Copyright (C) 2019 Armin Kuster
+#
+import re
+
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.runtime.decorator.package import OEHasPackage
+
+
+class SSSDTest(OERuntimeTestCase):
+
+@OEHasPackage(['sssd'])
+@OETestDepends(['ssh.SSHTest.test_ssh'])
+def test_sssd_help(self):
+status, output = self.target.run('sssctl --help')
+msg = ('sssctl command does not work as expected. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 1, msg = msg)
+
+@OETestDepends(['sssd.SSSDTest.test_sssd_help'])
+def test_sssd_sssctl_conf_perms_chk(self):
+status, output = self.target.run('sssctl domain-status')
+match = re.search('ConfDB initialization has failed', output)
+if match:
+msg = ('sssctl domain-status failed, check sssd.conf perms. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestDepends(['sssd.SSSDTest.test_sssd_sssctl_conf_perms_chk'])
+def test_sssd_sssctl_deamon(self):
+status, output = self.target.run('sssctl domain-status')
+match = re.search('No domains configured, fatal error!', output)
+if match:
+msg = ('sssctl domain-status failed, sssd.conf not setup
correctly. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH 3/5] sssd: fix a few runtime issues
include a few more RDEPEND packages. remove init script as there really
isn't one yet.
Signed-off-by: Armin Kuster
---
recipes-security/sssd/sssd_1.16.3.bb | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/recipes-security/sssd/sssd_1.16.3.bb
b/recipes-security/sssd/sssd_1.16.3.bb
index 8f7f805..e3fb254 100644
--- a/recipes-security/sssd/sssd_1.16.3.bb
+++ b/recipes-security/sssd/sssd_1.16.3.bb
@@ -14,7 +14,7 @@ SRC_URI =
"https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz\
SRC_URI[md5sum] = "af4288c9d1f9953e3b3b6e0b165a5ece"
SRC_URI[sha256sum] =
"ee5d17a0c663c09819cbab9364085b9e57faeca02406cc30efe14cc0cfc04ec4"
-inherit autotools pkgconfig gettext update-rc.d python-dir
distro_features_check
+inherit autotools pkgconfig gettext python-dir distro_features_check
REQUIRED_DISTRO_FEATURES = "pam"
@@ -55,6 +55,16 @@ do_install () {
rmdir --ignore-fail-on-non-empty "${D}/${bindir}"
install -d ${D}/${sysconfdir}/${BPN}
install -m 600 ${WORKDIR}/${BPN}.conf ${D}/${sysconfdir}/${BPN}
+
+# Remove /var/run as it is created on startup
+rm -rf ${D}${localstatedir}/run
+}
+
+pkg_postinst_ontarget_${PN} () {
+if [ -e /etc/init.d/populate-volatile.sh ] ; then
+${sysconfdir}/init.d/populate-volatile.sh update
+fi
+
}
CONFFILES_${PN} = "${sysconfdir}/${BPN}/${BPN}.conf"
@@ -70,4 +80,4 @@ FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la
${libdir}/*/*la"
# The package contains symlinks that trip up insane
INSANE_SKIP_${PN} = "dev-so"
-RDEPENDS_${PN} += "bind dbus"
+RDEPENDS_${PN} = "bind dbus samba libldb"
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH 4/5] sssd: update to 1.16.4
Add systemd pkgconf via DISTRO_FEATURE
Fix uid/gid of sssd.conf
Signed-off-by: Armin Kuster
---
.../sssd/{sssd_1.16.3.bb => sssd_1.16.4.bb} | 12
1 file changed, 8 insertions(+), 4 deletions(-)
rename recipes-security/sssd/{sssd_1.16.3.bb => sssd_1.16.4.bb} (88%)
diff --git a/recipes-security/sssd/sssd_1.16.3.bb
b/recipes-security/sssd/sssd_1.16.4.bb
similarity index 88%
rename from recipes-security/sssd/sssd_1.16.3.bb
rename to recipes-security/sssd/sssd_1.16.4.bb
index e3fb254..3fa3426 100644
--- a/recipes-security/sssd/sssd_1.16.3.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -11,13 +11,16 @@ DEPENDS += "libldb dbus libtalloc libpcre glib-2.0 popt
e2fsprogs libtevent"
SRC_URI = "https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz\
file://sssd.conf "
-SRC_URI[md5sum] = "af4288c9d1f9953e3b3b6e0b165a5ece"
-SRC_URI[sha256sum] =
"ee5d17a0c663c09819cbab9364085b9e57faeca02406cc30efe14cc0cfc04ec4"
+SRC_URI[md5sum] = "757bbb6f15409d8d075f4f06cb678d50"
+SRC_URI[sha256sum] =
"6bb212cd6b75b918e945c24e7c3f95a486fb54d7f7d489a9334cfa1a1f3bf959"
inherit autotools pkgconfig gettext python-dir distro_features_check
REQUIRED_DISTRO_FEATURES = "pam"
+SSSD_UID ?= "root"
+SSSD_GID ?= "root"
+
CACHED_CONFIGUREVARS = "ac_cv_member_struct_ldap_conncb_lc_arg=no \
ac_cv_path_NSUPDATE=${bindir} \
ac_cv_path_PYTHON2=${PYTHON_DIR} ac_cv_prog_HAVE_PYTHON3=${PYTHON_DIR} \
@@ -25,6 +28,7 @@ CACHED_CONFIGUREVARS =
"ac_cv_member_struct_ldap_conncb_lc_arg=no \
PACKAGECONFIG ?="nss nscd"
PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux',
'selinux', '', d)}"
+PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'systemd', '', d)}"
PACKAGECONFIG[ssh] = "--with-ssh, --with-ssh=no, "
PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
@@ -64,7 +68,7 @@ pkg_postinst_ontarget_${PN} () {
if [ -e /etc/init.d/populate-volatile.sh ] ; then
${sysconfdir}/init.d/populate-volatile.sh update
fi
-
+chown ${SSSD_UID}:${SSSD_GID} ${sysconfdir}/${BPN}/${BPN}.conf
}
CONFFILES_${PN} = "${sysconfdir}/${BPN}/${BPN}.conf"
@@ -80,4 +84,4 @@ FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la
${libdir}/*/*la"
# The package contains symlinks that trip up insane
INSANE_SKIP_${PN} = "dev-so"
-RDEPENDS_${PN} = "bind dbus samba libldb"
+RDEPENDS_${PN} = "bind dbus samba libldb libpam"
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH 2/5] libldb: work around samba libldb packaging issues
Samba and libldb overlap in a few places. This is the simplest fix for
now.
Signed-off-by: Armin Kuster
---
recipes-support/libldb/libldb_%.bbappend | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 recipes-support/libldb/libldb_%.bbappend
diff --git a/recipes-support/libldb/libldb_%.bbappend
b/recipes-support/libldb/libldb_%.bbappend
new file mode 100644
index 000..2633a1e
--- /dev/null
+++ b/recipes-support/libldb/libldb_%.bbappend
@@ -0,0 +1,22 @@
+# This fixes this issue:
+#ERROR: sssd-1.16.3-r0 do_prepare_recipe_sysroot: The file
/usr/lib/python2.7/site-packages/_ldb_text.py is installed by both libldb and
samba, aborting
+
+EXTRA_OECONF += "--disable-python"
+
+#Error: Transaction check error:
+# file /usr/bin/ldbadd conflicts between attempted installs of
samba-4.8.4-r0.cortexa15t2hf_neon_vfpv4 and
libldb-1.4.1-r0.cortexa15t2hf_neon_vfpv4
+# file /usr/bin/ldbdel conflicts between attempted installs of
samba-4.8.4-r0.cortexa15t2hf_neon_vfpv4 and
libldb-1.4.1-r0.cortexa15t2hf_neon_vfpv4
+# file /usr/bin/ldbedit conflicts between attempted installs of
samba-4.8.4-r0.cortexa15t2hf_neon_vfpv4 and
libldb-1.4.1-r0.cortexa15t2hf_neon_vfpv4
+# file /usr/bin/ldbmodify conflicts between attempted installs of
samba-4.8.4-r0.cortexa15t2hf_neon_vfpv4 and
libldb-1.4.1-r0.cortexa15t2hf_neon_vfpv4
+# file /usr/bin/ldbrename conflicts between attempted installs of
samba-4.8.4-r0.cortexa15t2hf_neon_vfpv4 and
libldb-1.4.1-r0.cortexa15t2hf_neon_vfpv4
+# file /usr/bin/ldbsearch conflicts between attempted installs of
samba-4.8.4-r0.cortexa15t2hf_neon_vfpv4 and
libldb-1.4.1-r0.cortexa15t2hf_neon_vfpv4
+
+do_install_append() {
+ rm -f ${D}${bindir}/ldbadd
+ rm -f ${D}${bindir}/ldbdel
+ rm -f ${D}${bindir}/ldbedit
+ rm -f ${D}${bindir}/ldbmodify
+ rm -f ${D}${bindir}/ldbrename
+ rm -f ${D}${bindir}/ldbsearch
+ rmdir ${D}${bindir}
+}
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH 1/5] Revert "sssd: fix libcrypto version used"
This reverts commit 2488c965d6b1b440734f43326fb33ac642ac7b82.
This corrects an incorrect fix as pointed out by Adrian Bunk.
---
recipes-security/sssd/sssd_1.16.3.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/sssd/sssd_1.16.3.bb
b/recipes-security/sssd/sssd_1.16.3.bb
index d39fa23..8f7f805 100644
--- a/recipes-security/sssd/sssd_1.16.3.bb
+++ b/recipes-security/sssd/sssd_1.16.3.bb
@@ -33,7 +33,7 @@ PACKAGECONFIG[manpages] = "--with-manpages,
--with-manpages=no"
PACKAGECONFIG[python2] = "--with-python2-bindings, --without-python2-bindings"
PACKAGECONFIG[python3] = "--with-python3-bindings, --without-python3-bindings"
PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
-PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto10"
+PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto"
PACKAGECONFIG[nscd] = "--with-nscd=${sbindir}, --with-nscd=no "
PACKAGECONFIG[nl] = "--with-libnl, --with-libnl=no, libnl"
PACKAGECONFIG[systemd] = "--with-systemdunitdir=${systemd_unitdir}/system/,
--with-systemdunitdir="
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 2/2] sssd: fix libcrypto version used
On 3/27/19 12:16 AM, Adrian Bunk wrote: > On Tue, Mar 26, 2019 at 03:52:39PM -0700, akuster808 wrote: >> >> On 3/26/19 3:24 AM, Adrian Bunk wrote: >>> On Mon, Mar 25, 2019 at 09:58:55AM -0700, Armin Kuster wrote: Signed-off-by: Armin Kuster --- recipes-security/sssd/sssd_1.16.3.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-security/sssd/sssd_1.16.3.bb b/recipes-security/sssd/sssd_1.16.3.bb index 8f7f805..d39fa23 100644 --- a/recipes-security/sssd/sssd_1.16.3.bb +++ b/recipes-security/sssd/sssd_1.16.3.bb @@ -33,7 +33,7 @@ PACKAGECONFIG[manpages] = "--with-manpages, --with-manpages=no" PACKAGECONFIG[python2] = "--with-python2-bindings, --without-python2-bindings" PACKAGECONFIG[python3] = "--with-python3-bindings, --without-python3-bindings" PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss," -PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto" +PACKAGECONFIG[cyrpto] = "--with-crypto=libcrypto, , libcrypto10" ... >>> This looks wrong for multiple reasons, and it still gave the same error >>> when I tried it. >> That is troubling. I don't see any errors here. Thanks for the feed >> back. I will have to dig at this a bit more. >> >> Can you provide some build detail so that I can reproduce it? > Try building the package without nss but with cyrpto (sic) in PACKAGECONFIG. Ok. I see it now. > >>> How has this change been tested? >> Not for this change. >> >> Which reminds me I should automate some testing for this package. > This is not about automating testing. > > This is about first reproducing the problem you are trying to fix, > and then verifying that your fix actually fixes this problem. And that is what i thought I was doing. > > Which is the fundamental way to do any kind of bugfixing.[1] Thanks for the reminder. > > This one line already contained two bugs,[2] and the commit added a > third problem (usage of OpenSSL 1.0) without fixing any of these bugs. > > The commit message not stating any reason why this change was done only > adds to the confusion. > I thought originally this was a workaround for code not building with > OpenSSL 1.1, which would then also be required for thud. I will keep that in mind. thanks, Armin > >> regards, >> Armin > cu > Adrian > > [1] this is not one of the harder cases where reproducing the problem > would be a problem > [2] "cyrpto", and "libcrypto" instead of "openssl p11-kit" > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
Hello Burton, > Check what luajit is shipping and compare that to what the pkgconfig > is looking for. Calling pkgconfig directly in your recipe's devshell > is useful for this. Thanks for the hint regarding the devshell. Indeed, pkgconfig can not find luajit in the devshell - the path specified as PKG_CONFIG_PATH is: build/tmp-angstrom-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/xpcompiler/0.1-r0/recipe-sysroot/usr/lib/pkgconfig - however the folder pkgconfig does not even exist in there. Inside work/armv7.../ there is also a luajit directory, and there I was able to find the pc-file: /2.0.5-r0/sysroot-destdir/usr/lib/pkgconfig/luajit.pc So i wonder, are there some extra steps required to make the luajit sysroot-destdir visible to luajit's recipe-sysroot? Thanks & br, Clemens -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
On Fri, 29 Mar 2019 at 00:06, Clemens Eisserer wrote:
> Hi Burton,
>
> > > RDEPENDS_${PN} = "luajit"
> > > inherit autotools pkgconfig
> >
> > Considering you're trying to use luajit at build time, it's probably
> > sensible to have it as a build dependency instead (DEPENDS).
>
> I've just tried it without success - it still fails stating luajit can
> not be found - despite the fact that "bitbake luajit" seems to work
> without any issues.
>
> I am not sure it makes a difference, I additionally use the
> meta-altera layer and I am running inside a debian chroot (in the same
> environment where the build with angstrom-v2016.06-yocto2 actually
> succeeds).
>
> Could it have something to do with pkg-config not beeing prefixed -
> like mentioned in the configure log?
>
> Best regard, Clemens
>
> checking for arm-angstrom-linux-gnueabi-pkg-config... no
> | checking for pkg-config...
> /home/ce/yocto_xposure2019/build/tmp-angstrom-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/xpcompiler/0.1-r0/recipe-sysroot-native/usr/bin/pkg-config
> | configure: WARNING: using cross tools not prefixed with host triplet
Nope.
Check what luajit is shipping and compare that to what the pkgconfig
is looking for. Calling pkgconfig directly in your recipe's devshell
is useful for this.
Not having luajit in DEPENDS *is* a bug though, having it in RDEPENDS
alone means you've been lucky with task scheduling before.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
Hi Burton,
> > RDEPENDS_${PN} = "luajit"
> > inherit autotools pkgconfig
>
> Considering you're trying to use luajit at build time, it's probably
> sensible to have it as a build dependency instead (DEPENDS).
I've just tried it without success - it still fails stating luajit can
not be found - despite the fact that "bitbake luajit" seems to work
without any issues.
I am not sure it makes a difference, I additionally use the
meta-altera layer and I am running inside a debian chroot (in the same
environment where the build with angstrom-v2016.06-yocto2 actually
succeeds).
Could it have something to do with pkg-config not beeing prefixed -
like mentioned in the configure log?
Best regard, Clemens
checking for arm-angstrom-linux-gnueabi-pkg-config... no
| checking for pkg-config...
/home/ce/yocto_xposure2019/build/tmp-angstrom-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/xpcompiler/0.1-r0/recipe-sysroot-native/usr/bin/pkg-config
| configure: WARNING: using cross tools not prefixed with host triplet
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
On Thu, 28 Mar 2019 at 23:45, Clemens Eisserer wrote:
> The bb-file specifies luajit as runtime-dependency as well as inherits
> pkgconfig:
>
> RDEPENDS_${PN} = "luajit"
> inherit autotools pkgconfig
Considering you're trying to use luajit at build time, it's probably
sensible to have it as a build dependency instead (DEPENDS).
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] pkg-config does not find "luajit" since upgrade to sumo
Hi,
I am trying to compile an autotools based in-house project which
compiled as expected on angstrom-v2016.06-yocto2.
It is a rather boring setup where configure.ac checks for luajit using
the following line: "PKG_CHECK_MODULES([LJ], [luajit])".
The bb-file specifies luajit as runtime-dependency as well as inherits
pkgconfig:
RDEPENDS_${PN} = "luajit"
inherit autotools pkgconfig
This all seems to work as intended - when building the project I first
see luajit-2.0.5 being fetched and successfully compiled.
However the project itself fails to build, during configure pkg-config
states it is unable to find luajit.
Exactly the same sources + bb-files worked well with angstrom-v2016.06-yocto2.
Any ideas what could be going wrong here?
Thank you in advance, Clemens
checking for arm-angstrom-linux-gnueabi-pkg-config... no
| checking for pkg-config...
/home/ce/yocto_xposure2019/build/tmp-angstrom-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/xpcompiler/0.1-r0/recipe-sysroot-native/usr/bin/pkg-config
| configure: WARNING: using cross tools not prefixed with host triplet
| checking pkg-config is at least version 0.9.0... yes
| checking for luajit... no
| configure: error: Package requirements (luajit) were not met:
|
| No package 'luajit' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
| Alternatively, you may set the environment variables LJ_CFLAGS
| and LJ_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| NOTE: The following config.log files may provide further information.
| NOTE:
/home/ce/yocto_xposure2019/build/tmp-angstrom-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/xpcompiler/0.1-r0/build/config.log
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] libselinux.inc: Add python-shell to libselinux-python RDEPENDS.
The libselinux SWIG wrapper imports shutil.
Signed-off-by: Chris PeBenito
---
recipes-security/selinux/libselinux.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/selinux/libselinux.inc
b/recipes-security/selinux/libselinux.inc
index 33621cc..6e115e3 100644
--- a/recipes-security/selinux/libselinux.inc
+++ b/recipes-security/selinux/libselinux.inc
@@ -9,7 +9,7 @@ inherit lib_package pythonnative
DEPENDS += "libsepol python libpcre swig-native"
DEPENDS_append_libc-musl = " fts"
-RDEPENDS_${PN}-python += "python-core"
+RDEPENDS_${PN}-python += "python-core python-shell"
PACKAGES += "${PN}-python"
FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}/site-packages/*"
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] machine: clean up config files
Beautify the machine config files by making the names and descriptions
more uniform and verbose
Signed-off-by: Jon Mason
---
meta/conf/machine/qemuarm.conf| 4 ++--
meta/conf/machine/qemuarm64.conf | 4 ++--
meta/conf/machine/qemuarmv5.conf | 6 +++---
meta/conf/machine/qemumips.conf | 4 ++--
meta/conf/machine/qemumips64.conf | 4 ++--
meta/conf/machine/qemuppc.conf| 4 ++--
meta/conf/machine/qemux86-64.conf | 4 ++--
meta/conf/machine/qemux86.conf| 4 ++--
8 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
index 9555046189..0a2c995312 100644
--- a/meta/conf/machine/qemuarm.conf
+++ b/meta/conf/machine/qemuarm.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: generic Arm Cortex-A15 machine
-#@DESCRIPTION: Machine configuration for running a generic armv7
+#@NAME: QEMU Arm Cortex-A15 machine
+#@DESCRIPTION: Machine configuration for running an ARMv7 system on QEMU
require conf/machine/include/tune-cortexa15.inc
require conf/machine/include/qemu.inc
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 22f6cb742b..5c8aac1511 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: generic armv8 machine
-#@DESCRIPTION: Machine configuration for running a generic armv8
+#@NAME: QEMU ARMv8 machine
+#@DESCRIPTION: Machine configuration for running an ARMv8 system on QEMU
require conf/machine/include/arm/arch-armv8a.inc
require conf/machine/include/qemu.inc
diff --git a/meta/conf/machine/qemuarmv5.conf b/meta/conf/machine/qemuarmv5.conf
index e3948a25da..1c21d3342d 100644
--- a/meta/conf/machine/qemuarmv5.conf
+++ b/meta/conf/machine/qemuarmv5.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: arm_versatile_926ejs
-#@DESCRIPTION: arm_versatile_926ejs
+#@NAME: QEMU ARM9 machine
+#@DESCRIPTION: Machine configuration for running an ARMv5 system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-arm926ejs.inc
@@ -20,4 +20,4 @@ QB_OPT_APPEND += "-object
rng-random,filename=/dev/urandom,id=rng0 -device virti
PREFERRED_VERSION_linux-yocto ??= "5.0%"
QB_DTB = "${@oe.utils.version_less_or_equal('PREFERRED_VERSION_linux-yocto',
'4.7', '', 'zImage-versatile-pb.dtb', d)}"
-KMACHINE_qemuarmv5 = "qemuarm"
\ No newline at end of file
+KMACHINE_qemuarmv5 = "qemuarm"
diff --git a/meta/conf/machine/qemumips.conf b/meta/conf/machine/qemumips.conf
index a60f67aa87..48d9f41d9d 100644
--- a/meta/conf/machine/qemumips.conf
+++ b/meta/conf/machine/qemumips.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: mti_malta32_be MIPS
-#@DESCRIPTION: mti_malta32_be
+#@NAME: QEMU MIPS32 machine
+#@DESCRIPTION: Machine configuration for running a MIPS system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-mips32r2.inc
diff --git a/meta/conf/machine/qemumips64.conf
b/meta/conf/machine/qemumips64.conf
index 970c0ce7ae..1872e7b62d 100644
--- a/meta/conf/machine/qemumips64.conf
+++ b/meta/conf/machine/qemumips64.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: mti-malta64-be MIPS64
-#@DESCRIPTION: mti-malta64-be
+#@NAME: QEMU MIPS64 machine
+#@DESCRIPTION: Machine configuration for running a MIPS64 system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-mips64r2.inc
diff --git a/meta/conf/machine/qemuppc.conf b/meta/conf/machine/qemuppc.conf
index 743d26170e..bd88eeb12a 100644
--- a/meta/conf/machine/qemuppc.conf
+++ b/meta/conf/machine/qemuppc.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: qemu PPC Emulator setup
-#@DESCRIPTION: Machine configuration for running an PPC system under qemu
emulation
+#@NAME: QEMU PPC machine
+#@DESCRIPTION: Machine configuration for running a PPC system on QEMU
require conf/machine/include/qemu.inc
require conf/machine/include/tune-ppc7400.inc
diff --git a/meta/conf/machine/qemux86-64.conf
b/meta/conf/machine/qemux86-64.conf
index 9966d1a04c..383e3bd6f3 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: common_pc
-#@DESCRIPTION: Machine configuration for running a common x86
+#@NAME: QEMU x86-64 machine
+#@DESCRIPTION: Machine configuration for running an x86-64 system on QEMU
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index e78fb6e87b..ae5187cbd5 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -1,6 +1,6 @@
#@TYPE: Machine
-#@NAME: common_pc
-#@DESCRIPTION: Machine configuration for running a common x86
+#@NAME: QEMU x86 machine
+#@DESCRIPTION: Machine configuration for running an x86 system on QEMU
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
--
2.17.2
--
___
yocto
[yocto] [PATCH 1/2] meta-yocto-bsp: clean up machine config files
Beautify the machine config files by making the names and descriptions more uniform and verbose Signed-off-by: Jon Mason --- meta-yocto-bsp/conf/machine/edgerouter.conf| 2 +- meta-yocto-bsp/conf/machine/genericx86-64.conf | 5 ++--- meta-yocto-bsp/conf/machine/genericx86.conf| 5 ++--- meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 3 ++- 4 files changed, 7 insertions(+), 8 deletions(-) diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf b/meta-yocto-bsp/conf/machine/edgerouter.conf index 78c87f2f87..88592dbc85 100644 --- a/meta-yocto-bsp/conf/machine/edgerouter.conf +++ b/meta-yocto-bsp/conf/machine/edgerouter.conf @@ -1,6 +1,6 @@ #@TYPE: Machine #@NAME: Edgerouter -#@DESCRIPTION: Edgerouter +#@DESCRIPTION: Machine configuration for a generic edgerouter require conf/machine/include/tune-mips64.inc diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf b/meta-yocto-bsp/conf/machine/genericx86-64.conf index 12f7c0d200..c489462dca 100644 --- a/meta-yocto-bsp/conf/machine/genericx86-64.conf +++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf @@ -1,7 +1,6 @@ #@TYPE: Machine -#@NAME: Generic X86_64. - -#@DESCRIPTION: Machine configuration for generic X86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. +#@NAME: Generic x86_64 +#@DESCRIPTION: Machine configuration for generic x86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. DEFAULTTUNE ?= "core2-64" require conf/machine/include/tune-core2.inc diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf index 798b62ec2b..9929d2788a 100644 --- a/meta-yocto-bsp/conf/machine/genericx86.conf +++ b/meta-yocto-bsp/conf/machine/genericx86.conf @@ -1,7 +1,6 @@ #@TYPE: Machine -#@NAME: Generic X86. - -#@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. +#@NAME: Generic x86 +#@DESCRIPTION: Machine configuration for generic x86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on "typical" hardware. DEFAULTTUNE ?= "core2-32" require conf/machine/include/tune-core2.inc diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf index 54a34be3aa..e2dce56738 100644 --- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf +++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf @@ -1,5 +1,6 @@ #@TYPE: Machine -#@DESCRIPTION: Machine configuration for running +#@NAME: Freescale MPC8315E-RDB +#@DESCRIPTION: Machine configuration for Freescale MPC8315E-RDB TARGET_FPU = "" -- 2.17.2 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2] clean up machine config files
General clean-up of the machine config files present in Yocto. Since this encompasses files that would natively be in the oe-core and meta-yocto-bsp repositories, I split them into 2 commits. However, since they are similar, I sent them in the same email thread. I hope this is acceptable. Jon Mason (2): meta-yocto-bsp: clean up machine config files machine: clean up config files meta-yocto-bsp/conf/machine/edgerouter.conf| 2 +- meta-yocto-bsp/conf/machine/genericx86-64.conf | 5 ++--- meta-yocto-bsp/conf/machine/genericx86.conf| 5 ++--- meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 3 ++- meta/conf/machine/qemuarm.conf | 4 ++-- meta/conf/machine/qemuarm64.conf | 4 ++-- meta/conf/machine/qemuarmv5.conf | 6 +++--- meta/conf/machine/qemumips.conf| 4 ++-- meta/conf/machine/qemumips64.conf | 4 ++-- meta/conf/machine/qemuppc.conf | 4 ++-- meta/conf/machine/qemux86-64.conf | 4 ++-- meta/conf/machine/qemux86.conf | 4 ++-- 12 files changed, 24 insertions(+), 25 deletions(-) -- 2.17.2 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Basic Yocto+CMake Usage question
On Thu, 28 Mar 2019 12:51:54 -0400 A wrote: > Thank you for the quick suggestion. > > Unfortunately, I tried setting OECMAKE_FIND_ROOT_PATH_MODE_LIBRARY to > "ONLY", "NEVER", and "BOTH" separately, and none of the above > worked. I must be doing something fundamentally wrong. > > Any other suggestions? More information would be needed: What fails? When does it fail? How does it fails? You should find these details in the log-files. Could you provide parts of it? -- Patrick. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Basic Yocto+CMake Usage question
Thank you for the quick suggestion.
Unfortunately, I tried setting OECMAKE_FIND_ROOT_PATH_MODE_LIBRARY to
"ONLY", "NEVER", and "BOTH" separately, and none of the above worked. I
must be doing something fundamentally wrong.
Any other suggestions?
On Thu, Mar 28, 2019 at 12:30 PM Patrick Boettcher <
patrick.boettc...@posteo.de> wrote:
> Hi
>
> On Thu, 28 Mar 2019 12:20:43 -0400
> A wrote:
>
> > I'm having issues with a yocto build that is combining recipes that
> > should depend on each other, and I need a sanity check. Is this an
> > ok forum for stupid user questions?
> >
> > The main idea is to have one recipe install some prebuilt libraries,
> > and have another cmake-based recipe use those libraries.
> >
> > As a caveat, this is a native version of the build that I seem to be
> > having trouble with, but I assume that is mostly irrelevant:
> >
> > In ProjectA, the meat of the matter is a do_install that copies
> > ProjectA*.so into STAGING_LIBDIR. I don't recall why I chose that
> > instead of ${D}${libdir}... is it ok this way?
> > In ProjectB, I'd like CMake's find_library() to find Project A's
> > libraries, and I seem to be having trouble.
> >
> > How would you approach this? The recipe for Project B contains
> > "inherit cmake" and some variables I pass in with an EXTRA_OECMAKE
> > and an EXTRA_OECMAKE-native.
> >
> > I also have there:
> > DEPENDS += "ProjectA"
> > DEPENDS_class-native = "ProjectA-native"
> >
> > However,in ProjectB's find_library() call, I am uncertain how to
> > direct it to find those libraries - what PATHS or HINTS or whatever?
>
> I was having similar problems with this (a dependency for zeromq in my
> case).
>
> DEPENDS = "zeromq" # build dependency
>
> I had to add the following variable to my recipes:
>
> OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH"
>
> this, iiuc, tells cmake that in case of cross-compiling (via a
> toolchain-file) that it shall also look in the sysroot for header
> and library-files when doing find_library(). Not sure if it will work
> with all find_package()-modules.
>
> It worked, I haven't investigated further why, but I should have.
>
> HTH.
> --
> Patrick.
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Basic Yocto+CMake Usage question
I'm having issues with a yocto build that is combining recipes that should
depend on each other, and I need a sanity check. Is this an ok forum for
stupid user questions?
The main idea is to have one recipe install some prebuilt libraries, and
have another cmake-based recipe use those libraries.
As a caveat, this is a native version of the build that I seem to be having
trouble with, but I assume that is mostly irrelevant:
In ProjectA, the meat of the matter is a do_install that copies
ProjectA*.so into STAGING_LIBDIR. I don't recall why I chose that instead
of ${D}${libdir}... is it ok this way?
In ProjectB, I'd like CMake's find_library() to find Project A's libraries,
and I seem to be having trouble.
How would you approach this? The recipe for Project B contains "inherit
cmake" and some variables I pass in with an EXTRA_OECMAKE and an
EXTRA_OECMAKE-native.
I also have there:
DEPENDS += "ProjectA"
DEPENDS_class-native = "ProjectA-native"
However,in ProjectB's find_library() call, I am uncertain how to direct it
to find those libraries - what PATHS or HINTS or whatever?
Any help is gladly appreciated.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Basic Yocto+CMake Usage question
Hi
On Thu, 28 Mar 2019 12:20:43 -0400
A wrote:
> I'm having issues with a yocto build that is combining recipes that
> should depend on each other, and I need a sanity check. Is this an
> ok forum for stupid user questions?
>
> The main idea is to have one recipe install some prebuilt libraries,
> and have another cmake-based recipe use those libraries.
>
> As a caveat, this is a native version of the build that I seem to be
> having trouble with, but I assume that is mostly irrelevant:
>
> In ProjectA, the meat of the matter is a do_install that copies
> ProjectA*.so into STAGING_LIBDIR. I don't recall why I chose that
> instead of ${D}${libdir}... is it ok this way?
> In ProjectB, I'd like CMake's find_library() to find Project A's
> libraries, and I seem to be having trouble.
>
> How would you approach this? The recipe for Project B contains
> "inherit cmake" and some variables I pass in with an EXTRA_OECMAKE
> and an EXTRA_OECMAKE-native.
>
> I also have there:
> DEPENDS += "ProjectA"
> DEPENDS_class-native = "ProjectA-native"
>
> However,in ProjectB's find_library() call, I am uncertain how to
> direct it to find those libraries - what PATHS or HINTS or whatever?
I was having similar problems with this (a dependency for zeromq in my
case).
DEPENDS = "zeromq" # build dependency
I had to add the following variable to my recipes:
OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH"
this, iiuc, tells cmake that in case of cross-compiling (via a
toolchain-file) that it shall also look in the sysroot for header
and library-files when doing find_library(). Not sure if it will work
with all find_package()-modules.
It worked, I haven't investigated further why, but I should have.
HTH.
--
Patrick.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.33
On Wed, Mar 27, 2019 at 9:34 AM Paul Gortmaker wrote: > > Bruce, Yocto kernel folks: > > Here is the next 4.18.x stable update "extension" primarily created > for the Yocto project, continuing from the previous v4.18.32 release. > > There are about 260 commits here, based on commits chosen from what > was used in the recent 4.19.31 stable release. So, yes, another > bigger one, but still no one big feature/area was responsible. > > I've put this 4.18.x queue through the usual testing; build testing > on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis > and finally some sanity runtime tests on x86-64. > > I did the signed tag just as per the previously released versions. > Please find a signed v4.18.33 tag using this key: > > http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6 > > in the repo in the kernel.org directory here: > >https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/ >git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git > Merged. I had a minor conflict on the -rt branches, but looking at 4.19-rt my resolution of it should be consistent with what upstream did as well. Worth double checking and sending me a fixup patch if I did mess it up. Bruce > for merge to standard/base in linux-yocto-4.18 and then out from there > into the other base and BSP branches. > > For those who are interested, the evolution of the commits is here: > >https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/ > > This repo isn't needed for anything; it just exists for transparency and > so people can see the evolution of the raw commits that were originally > selected to create this 4.18.x release. > > Paul. -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH] cgl: audit: Remove CONFIG_AUDIT_WATCH and CONFIG_AUDIT_WATCH
This is now merged.
Bruce
On Mon, Mar 25, 2019 at 2:36 AM He Zhe wrote:
>
> This for 5.0 and master.
>
> Zhe
>
> On 3/25/19 2:33 PM, zhe...@windriver.com wrote:
> > From: He Zhe
> >
> > In the following commits, these two options have been replaced by
> > CONFIG_AUDITSYSCALL which is in audit.cfg.
> >
> > c8fc5d49c341 ("audit: remove WATCH and TREE config options")
> > cb74ed278f80 ("audit: always enable syscall auditing when supported and
> > audit is enabled")
> >
> > Signed-off-by: He Zhe
> > ---
> > cgl/features/audit/audit.cfg | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/cgl/features/audit/audit.cfg b/cgl/features/audit/audit.cfg
> > index 3397cc5..e0c6e19 100644
> > --- a/cgl/features/audit/audit.cfg
> > +++ b/cgl/features/audit/audit.cfg
> > @@ -1,6 +1,4 @@
> > CONFIG_AUDIT=y
> > CONFIG_AUDITSYSCALL=y
> > -CONFIG_AUDIT_WATCH=y
> > -CONFIG_AUDIT_TREE=y
> > # CONFIG_NETFILTER_XT_TARGET_AUDIT is not set
> > CONFIG_AUDIT_GENERIC=y
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [v4.19 rt branch] x86: Drop the duplicate define of TIF_NEED_RESCHED_LAZY
Thanks Kevin,
This is now merged.
Bruce
On Thu, Mar 28, 2019 at 2:28 AM Kevin Hao wrote:
>
> The two merge commits 107b161b1cbaf ("Merge branch 'v4.19/standard/base'
> into v4.19/standard/preempt-rt/base") and dc37b7080cd55 ("Merge tag
> 'v4.19.8' into linux-4.19.y-rt") almost have the same content, but
> introduce two define of TIF_NEED_RESCHED_LAZY for x86 arch. Drop one of
> them to fix the build warning.
>
> Signed-off-by: Kevin Hao
> ---
> arch/x86/include/asm/thread_info.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/thread_info.h
> b/arch/x86/include/asm/thread_info.h
> index 70b08abcd6d0..dc267291f131 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -95,7 +95,6 @@ struct thread_info {
> #define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return
> */
> #define TIF_UPROBE 12 /* breakpointed or singlestepping */
> #define TIF_PATCH_PENDING 13 /* pending live patching update */
> -#define TIF_NEED_RESCHED_LAZY 14 /* lazy rescheduling necessary */
> #define TIF_NOCPUID15 /* CPUID is not accessible in
> userland */
> #define TIF_NOTSC 16 /* TSC is not accessible in userland
> */
> #define TIF_IA32 17 /* IA32 compatibility process */
> @@ -126,7 +125,6 @@ struct thread_info {
> #define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
> #define _TIF_UPROBE(1 << TIF_UPROBE)
> #define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
> -#define _TIF_NEED_RESCHED_LAZY (1 << TIF_NEED_RESCHED_LAZY)
> #define _TIF_NOCPUID (1 << TIF_NOCPUID)
> #define _TIF_NOTSC (1 << TIF_NOTSC)
> #define _TIF_IA32 (1 << TIF_IA32)
> --
> 2.14.4
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Fwd: Trimming BOOST libraries installed
On Thu, 28 Mar 2019 at 12:40, Gabriele Zampieri wrote: > So I just specify the dependencies in my recipes, and then remove > IMAGE_INSTALL_append = " boost". Am I right? Yes. Your recipe that uses boost just needs DEPENDS=boost as a build-dependency. The linkage will be examined and the appropriate runtime dependencies created for you. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: Trimming BOOST libraries installed
Forgot to include the mailing list -- Forwarded message - Da: Gabriele Zampieri Date: gio 28 mar 2019 alle ore 13:38 Subject: Re: [yocto] Trimming BOOST libraries installed To: Burton, Ross Thank you for the fast reply. So I just specify the dependencies in my recipes, and then remove IMAGE_INSTALL_append = " boost". Am I right? Which name should I use with DEPEND? Thanks, Gabriele Il giorno gio 28 mar 2019 alle ore 13:15 Burton, Ross ha scritto: > On Thu, 28 Mar 2019 at 10:59, Gabriele Zampieri > wrote: > > I'm building a custom image that install boost libraries: > > > > IMAGE_INSTALL_append = " boost" > > > > How can I trim the installed libraries? I see inside > meta/recipes-support/boost/boost.inc a variable called BOOST_LIBS that > lists all the boost components, so in my custom-image.bb I tried: > > The easy solution is to not do that. The application you're building > should DEPEND on boost and then the RDEPENDS will be populated for > you, and be the required set not the full set. > > If you really want to explicitly install some packages, then don't > install "boost" which is a meta-package depending on all boost > libraries. The sub-libraries are called eg boost-atomic. > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trimming BOOST libraries installed
On Thu, 28 Mar 2019 at 10:59, Gabriele Zampieri wrote: > I'm building a custom image that install boost libraries: > > IMAGE_INSTALL_append = " boost" > > How can I trim the installed libraries? I see inside > meta/recipes-support/boost/boost.inc a variable called BOOST_LIBS that lists > all the boost components, so in my custom-image.bb I tried: The easy solution is to not do that. The application you're building should DEPEND on boost and then the RDEPENDS will be populated for you, and be the required set not the full set. If you really want to explicitly install some packages, then don't install "boost" which is a meta-package depending on all boost libraries. The sub-libraries are called eg boost-atomic. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trimming BOOST libraries installed
Hi all, I'm building a custom image that install boost libraries: IMAGE_INSTALL_append = " boost" How can I trim the installed libraries? I see inside meta/recipes-support/boost/boost.inc a variable called BOOST_LIBS that lists all the boost components, so in my custom-image.bb I tried: BOOST_LIBS_remove = " atomic" but the produced image still integrate the libboost_atomic. My layer have an higher priority (11) than meta (5). Any tips? Thanks, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [rauc] create a rescue image
Thanks Mike, Patrick, I have been much clearer about the options to update the system and the cost involved. a greeting Jairo -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [rauc] create a rescue image
On 26-03-19 11:02, jairo wrote: > El mar, 26-03-2019 a las 09:14 +0100, Patrick Boettcher escribió: >> On Tue, 26 Mar 2019 09:05:47 +0100 >> jairo wrote: ... > Yes, I know, it is somewhat risky, but I have only 512MB of nand > memory, and we are getting a lot of software. I think we have to > evaluate the move to a hardware with more memory, at the moment is what > we have. I think it is practically impossible to put 2 systems in so > little memory. With NAND you'll probably have a filesystem (jffs2 or UBI) in place. With that, you could just use a package manager like opkg to update sofware. If the box has a network connection, just running "opkg update && opkg upgrade" will install the current releases with the minimum effort. We've been using this on a million boxes and it works fine (until someone decides to patch libc and you get a 300+ package upgrade). Linux is also capable of upgrading a running system. Basically, copy some executables to a tmp filesystem, remount everything read-only, and change root to the tmp part. Then you can rewrite partitions and reboot. In any case, you should have a u-boot configuration that allows it to be debricked. Typically a USB stick or DFU will do nicely if your board has USB. Or even serial... -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [v4.19 rt branch] x86: Drop the duplicate define of TIF_NEED_RESCHED_LAZY
The two merge commits 107b161b1cbaf ("Merge branch 'v4.19/standard/base'
into v4.19/standard/preempt-rt/base") and dc37b7080cd55 ("Merge tag
'v4.19.8' into linux-4.19.y-rt") almost have the same content, but
introduce two define of TIF_NEED_RESCHED_LAZY for x86 arch. Drop one of
them to fix the build warning.
Signed-off-by: Kevin Hao
---
arch/x86/include/asm/thread_info.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 70b08abcd6d0..dc267291f131 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -95,7 +95,6 @@ struct thread_info {
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
-#define TIF_NEED_RESCHED_LAZY 14 /* lazy rescheduling necessary */
#define TIF_NOCPUID15 /* CPUID is not accessible in userland
*/
#define TIF_NOTSC 16 /* TSC is not accessible in userland */
#define TIF_IA32 17 /* IA32 compatibility process */
@@ -126,7 +125,6 @@ struct thread_info {
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
-#define _TIF_NEED_RESCHED_LAZY (1 << TIF_NEED_RESCHED_LAZY)
#define _TIF_NOCPUID (1 << TIF_NOCPUID)
#define _TIF_NOTSC (1 << TIF_NOTSC)
#define _TIF_IA32 (1 << TIF_IA32)
--
2.14.4
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
