[yocto] [meta-security][v2][PATCH 2/2] samhain: add basic runtime test
Signed-off-by: Armin Kuster
---
lib/oeqa/runtime/cases/samhain.py | 20
1 file changed, 20 insertions(+)
create mode 100644 lib/oeqa/runtime/cases/samhain.py
diff --git a/lib/oeqa/runtime/cases/samhain.py
b/lib/oeqa/runtime/cases/samhain.py
new file mode 100644
index 000..e4bae7b
--- /dev/null
+++ b/lib/oeqa/runtime/cases/samhain.py
@@ -0,0 +1,20 @@
+# 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 SamhainTest(OERuntimeTestCase):
+
+@OEHasPackage(['samhain-standalone'])
+@OETestDepends(['ssh.SSHTest.test_ssh'])
+def test_samhain_standalone_help(self):
+status, output = self.target.run('samhain --help')
+match = re.search('Please report bugs to supp...@la-samhna.de.',
output)
+if not match:
+msg = ('samhain-standalone command does not work as expected. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 1, msg = msg)
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][v2][PATCH 1/2] samhain: fix runtime error
fix:
samhain[1652]: FATAL: x_dnmalloc.c: 2790: hashval < AMOUNTHASH
Killed
disable dnmalloc
Signed-off-by: Armin Kuster
---
recipes-security/samhain/samhain.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/recipes-security/samhain/samhain.inc
b/recipes-security/samhain/samhain.inc
index dcd72b9..1b9af39 100644
--- a/recipes-security/samhain/samhain.inc
+++ b/recipes-security/samhain/samhain.inc
@@ -117,6 +117,7 @@ do_configure () {
--enable-network=${SAMHAIN_MODE} \
--with-pid-file=${localstatedir}/run/samhain.pid \
--with-data-file=${localstatedir}/lib/samhain/samhain_file \
+ --disable-dnmalloc \
${EXTRA_OECONF}
}
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][v2][PATCH] suricata: add runtime testing
Today there are no failures so set the trigger to zero.
[v2]
fix match string
and conditional
Signed-off-by: Armin Kuster
---
lib/oeqa/runtime/cases/suricata.py | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 lib/oeqa/runtime/cases/suricata.py
diff --git a/lib/oeqa/runtime/cases/suricata.py
b/lib/oeqa/runtime/cases/suricata.py
new file mode 100644
index 000..17fc8c5
--- /dev/null
+++ b/lib/oeqa/runtime/cases/suricata.py
@@ -0,0 +1,27 @@
+# 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 SuricataTest(OERuntimeTestCase):
+
+@OEHasPackage(['suricata'])
+@OETestDepends(['ssh.SSHTest.test_ssh'])
+def test_suricata_help(self):
+status, output = self.target.run('suricata --help')
+msg = ('suricata command does not work as expected. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 1, msg = msg)
+
+@OETestDepends(['suricata.SuricataTest.test_suricata_help'])
+def test_suricata_unittest(self):
+status, output = self.target.run('suricata -u')
+match = re.search('FAILED: 0 ', output)
+if not match:
+msg = ('suricata unittest had an unexpected failure. '
+ '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] tripwire: add runtime test
Signed-off-by: Armin Kuster
---
lib/oeqa/runtime/cases/tripwire.py | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 lib/oeqa/runtime/cases/tripwire.py
diff --git a/lib/oeqa/runtime/cases/tripwire.py
b/lib/oeqa/runtime/cases/tripwire.py
new file mode 100644
index 000..659724d
--- /dev/null
+++ b/lib/oeqa/runtime/cases/tripwire.py
@@ -0,0 +1,47 @@
+# 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 TripwireTest(OERuntimeTestCase):
+
+@OEHasPackage(['tripwire'])
+@OETestDepends(['ssh.SSHTest.test_ssh'])
+def test_tripwire_help(self):
+status, output = self.target.run('tripwire --help')
+msg = ('tripwire command does not work as expected. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 8, msg = msg)
+
+@OETestDepends(['tripwire.TripwireTest.test_tripwire_help'])
+def test_tripwire_twinstall(self):
+status, output = self.target.run('/etc/tripwire/twinstall.sh')
+match = re.search('The database was successfully generated.', output)
+if not match:
+msg = ('/etc/tripwire/twinstall.sh failed. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestDepends(['tripwire.TripwireTest.test_tripwire_twinstall'])
+def test_tripwire_twadmin(self):
+status, output = self.target.run('twadmin --create-cfgfile --cfgfile
/etc/tripwire/twcfg.enc --site-keyfile /etc/tripwire/site.key -Q tripwire
/etc/tripwire/twcfg.txt')
+status, output = self.target.run('twadmin --create-polfile --cfgfile
/etc/tripwire/twcfg.enc --polfile /etc/tripwire/twpol.enc --site-keyfile
/etc/tripwire/site.key -Q tripwire /etc/tripwire/twpol.txt')
+match = re.search('Wrote policy file: /etc/tripwire/twpol.enc', output)
+if not match:
+msg = ('twadmin --create-profile ; failed. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestDepends(['tripwire.TripwireTest.test_tripwire_twadmin'])
+def test_tripwire_init(self):
+status, hostname = self.target.run('hostname')
+status, output = self.target.run('tripwire --init --cfgfile
/etc/tripwire/twcfg.enc --polfile /etc/tripwire/tw.pol --site-keyfile
/etc/tripwire/site.key --local-keyfile /etc/tripwire/%s-local.key -P tripwire'
% hostname)
+match = re.search('The database was successfully generated.', output)
+if not match:
+msg = ('tripwire --init; Failed for host: %s. '
+ 'Status and output:%s and %s' % (hostname, 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] suricata: add runtime testing
Today there are no failures so set the trigger to zero.
Signed-off-by: Armin Kuster
---
lib/oeqa/runtime/cases/suricata.py | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 lib/oeqa/runtime/cases/suricata.py
diff --git a/lib/oeqa/runtime/cases/suricata.py
b/lib/oeqa/runtime/cases/suricata.py
new file mode 100644
index 000..b6df214
--- /dev/null
+++ b/lib/oeqa/runtime/cases/suricata.py
@@ -0,0 +1,27 @@
+# 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 SuricataTest(OERuntimeTestCase):
+
+@OEHasPackage(['suricata'])
+@OETestDepends(['ssh.SSHTest.test_ssh'])
+def test_suricata_help(self):
+status, output = self.target.run('suricata --help')
+msg = ('suricata command does not work as expected. '
+ 'Status and output:%s and %s' % (status, output))
+self.assertEqual(status, 1, msg = msg)
+
+@OETestDepends(['suricata.SuricataTest.test_suricata_help'])
+def test_suricata_unittest(self):
+status, output = self.target.run('suricata -u')
+match = re.search('FAILED 0 ', output)
+if match:
+msg = ('suricata unittest had an unexpected failure. '
+ '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][v2][PATCH 2/2] sssd: update to 1.16.4
Add systemd pkgconf via DISTRO_FEATURE
Fix uid/gid of sssd.conf
[v2]
drop non update related changes
also, this includes CVE-2019-3811
Signed-off-by: Armin Kuster
---
recipes-security/sssd/{sssd_1.16.3.bb => sssd_1.16.4.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename recipes-security/sssd/{sssd_1.16.3.bb => sssd_1.16.4.bb} (95%)
diff --git a/recipes-security/sssd/sssd_1.16.3.bb
b/recipes-security/sssd/sssd_1.16.4.bb
similarity index 95%
rename from recipes-security/sssd/sssd_1.16.3.bb
rename to recipes-security/sssd/sssd_1.16.4.bb
index e996a61..34bc8c8 100644
--- a/recipes-security/sssd/sssd_1.16.3.bb
+++ b/recipes-security/sssd/sssd_1.16.4.bb
@@ -11,8 +11,8 @@ 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
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][v2][PATCH 1/2] sssd: fix a few runtime issues
include a few more RDEPEND packages. remove init script as there really
isn't one yet.
[v2]
Squish build tweeking done in pkg update into this changeset
Signed-off-by: Armin Kuster
---
recipes-security/sssd/sssd_1.16.3.bb | 19 +--
1 file changed, 17 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..e996a61 100644
--- a/recipes-security/sssd/sssd_1.16.3.bb
+++ b/recipes-security/sssd/sssd_1.16.3.bb
@@ -14,10 +14,13 @@ 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"
+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"
@@ -55,6 +59,17 @@ 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
+chown ${SSSD_UID}:${SSSD_GID} ${sysconfdir}/${BPN}/${BPN}.conf
}
CONFFILES_${PN} = "${sysconfdir}/${BPN}/${BPN}.conf"
@@ -70,4 +85,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 libldb libpam"
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 4/5] sssd: update to 1.16.4
On 3/29/19 12:10 AM, Adrian Bunk wrote:
> On Thu, Mar 28, 2019 at 10:28:20PM -0700, Armin Kuster wrote:
>> Add systemd pkgconf via DISTRO_FEATURE
>>
>> Fix uid/gid of sssd.conf
>>
>> Signed-off-by: Armin Kuster
>> ...
>> -RDEPENDS_${PN} = "bind dbus samba libldb"
>> +RDEPENDS_${PN} = "bind dbus samba libldb libpam"
> Why is this required?
>
> And the way this commit mixes unrelated changes, it is no even clear
> whether this is for the new upstream version or supposed to fix some
> older issue.
I will be squish those extra changes into the clean up patch and just
have the update separate.
thanks,
Armin
> cu
> Adrian
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 2/5] libldb: work around samba libldb packaging issues
On 3/28/19 11:50 PM, Adrian Bunk wrote: > On Thu, Mar 28, 2019 at 10:28:18PM -0700, Armin Kuster wrote: >> Samba and libldb overlap in a few places. This is the simplest fix for >> now. > Adding a quick hack for interaction problems between two packages > that are both in meta-openembedded by adding a .bbappend in > meta-security creates a technical debt while not even helping > users who are not using meta-security. > > The proper solution is likely to make samba use the external libldb > instead of an internal copy. > >> 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" >> ... > So just adding the meta-security layer will turn the pyldb* packages > into empty packages? I think I have a possible solution in libldb. patch out shortly. - armin > > cu > Adrian > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 3/5] sssd: fix a few runtime issues
On 3/28/19 11:51 PM, Adrian Bunk wrote:
> On Thu, Mar 28, 2019 at 10:28:19PM -0700, Armin Kuster wrote:
>> 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
>> ...
>> # The package contains symlinks that trip up insane
>> INSANE_SKIP_${PN} = "dev-so"
>>
>> -RDEPENDS_${PN} += "bind dbus"
>> +RDEPENDS_${PN} = "bind dbus samba libldb"
> Even when samba support is not enabled?
Yeah, that isn't right.
thanks,
Armin
>
> cu
> Adrian
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
Hi Dimitris,
Any kind of procedures, flows, information developed that you think are
useful but not in the current YP documentation can be considered to be
added somewhere (manuals, wiki, etc.). Is your "small tutorial" fully
captured here in your email? Or, do you have a separate document? Any sort
of targeted task can be considered for the YP Development Tasks manual. It
is full of various tasks that over the years have been declared important
or common.
Feel free to respond to me with any documentation suggestions/contributions
and so forth.
Scott
On Fri, Mar 29, 2019 at 1:50 AM Dimitris Tassopoulos
wrote:
> Hi all,
>
> I was thinking that the mail list shouldn't be only for problems and
> questions and that from time to time, it would be nice to see some guides,
> tutorials or success stories from people that follow the list.
>
> Anyway, a few days ago someone had an issue with one of the BSPs I'm
> maintaining and I wrote him a small guide on how to -try- to resolve future
> issues like that. Then I thought that I haven't found a small tutorial
> like this. Maybe it already exists, but nevertheless I haven't seen it.
> Of course, those things are in the documentation, but they are documented
> as individual tools (which is the correct thing to do), but it's not very
> clear how to use all those things together to perform more complex tasks.
>
> So, in my case the issue was that ofono was installed in the image and that
> needed to be removed. Probably a lot of you already know the answer but for
> me that I've never bothered with that I had to track it down how it got in
> there.
>
> Everything from now on assumes that you've setup up your bitbake
> environment
> of your build with whatever setup scripts you're using (e.g.
> *oe-init-build-env*)
>
> There are several ways to do introspection on an image. For example,
> let's say that you found a file in the in rootfs and you want to know which
> recipe added that file. Then you can use this command:
>
> oe-pkgdata-util find-path /usr/sbin/ofonod
>
>
> *oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
> `find-path` is pretty obvious what it does. This will return:
>
> ofono: /usr/sbin/ofonod
>
>
> So now you know that it's indeed the *ofono* recipe that adds this file.
> Next,
> you need how this did get in the image (probably some other dependency
> because you didn't). Then you can use the `-g` parameter with bitbake like
> this:
>
> bitbake -g allwinner-image
>
>
> This will create a file called `recipe-depends.dot`. This is a dot file
> that
> has all the dependencies in the image. You can use the same command to get
> the dependencies for a recipe, but now we care about the image.
>
> Next step is to search in that file, why that key is there. Why is `-w` and
> key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
> and you
> run this command:
>
> oe-depends-dot -k ofono -w recipe-depends.dot
>
>
> This will return the recipe that has this as dependency.
>
>
>> Because: allwinner-image packagegroup-base
>
>
> That means that the key is there because of allwinner-image (this is the
> image
> recipe, but it can be any other image) and because the *allwinner-image*
> inherits the
> *packagegroup-base*. So this packagegroup is the guilty.
>
> Let's find this thing now. Get in the meta layer sources folder and run
> this
>
> find . | grep packagegroup-base
>
>
> This will return
>
>> ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
>
>
> Great. Open this file to an editor and find where is *ofono*. Gotcha, is
> in:
>
> RDEPENDS_packagegroup-base-3g
>
>
> Then it's the *packagegroup-base-3g* that does that. Probably that's a
> recipe
> or package group file, so you can run:
>
> find . | grep packagegroup-base-3g
>
>
> But you get nothing... Then probably this is declared somewhere a file with
> another name, so let's search inside the files in the poky layer:
>
> grep -nriI ackagegroup-base-3g
>
>
> And we get:
>
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
>> ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
>> d)} \
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
>> ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
>> '',d)} \
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:122:
>> d.setVar("ADD_3G", "packagegroup-base-3g")
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316:SUMMARY_packagegroup-base-3g
>> = "Cellular data support"
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317:RDEPENDS_packagegroup-base-3g
>> = "\
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320:RRECOMMENDS_packagegroup-base-3g
>> = "\
>
>
>
> So it's actually in the same file that we already opened. Here you can
> facepalm,
> but we didn't know that, so this would be the procedure anyways to track
> it down.
> Now, search for *packagegroup-base-3g* inside the
>
[yocto] [sumo] [PATCH v1] systemd: fix musl compilation
musl compilation has been broken since systemd: fix CVE-2018-6954. Fixing this
by placing #ifdef for glob definition.
Signed-off-by: Sinan Kaya
---
.../systemd/0036-Fix-musl-compilation.patch | 27 +++
meta/recipes-core/systemd/systemd_237.bb | 1 +
2 files changed, 28 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0036-Fix-musl-compilation.patch
diff --git a/meta/recipes-core/systemd/systemd/0036-Fix-musl-compilation.patch
b/meta/recipes-core/systemd/systemd/0036-Fix-musl-compilation.patch
new file mode 100644
index 000..d12b0415f65
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0036-Fix-musl-compilation.patch
@@ -0,0 +1,27 @@
+From 8795fe183a92e6bc6a1221a5aad4103eaca13823 Mon Sep 17 00:00:00 2001
+From: Sinan Kaya
+Date: Tue, 26 Mar 2019 02:45:53 +
+Subject: [PATCH] Fix musl compilation
+
+Signed-off-by: Sinan Kaya
+---
+ src/tmpfiles/tmpfiles.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
+index d59ccbaa3..8d1ab0767 100644
+--- a/src/tmpfiles/tmpfiles.c
b/src/tmpfiles/tmpfiles.c
+@@ -1899,7 +1899,9 @@ static int glob_item(Item *i, action_t action) {
+
+ static int glob_item_recursively(Item *i, fdaction_t action) {
+ _cleanup_globfree_ glob_t g = {
++#ifdef GLOB_ALTDIRFUNC
+ .gl_opendir = (void *(*)(const char *)) opendir_nomod,
++#endif
+ };
+ int r = 0, k;
+ char **fn;
+--
+2.21.0
+
diff --git a/meta/recipes-core/systemd/systemd_237.bb
b/meta/recipes-core/systemd/systemd_237.bb
index a0e5d512e00..3b5222a2943 100644
--- a/meta/recipes-core/systemd/systemd_237.bb
+++ b/meta/recipes-core/systemd/systemd_237.bb
@@ -65,6 +65,7 @@ SRC_URI += "file://touchscreen.rules \
file://0002-Make-tmpfiles-safe.patch \
file://CVE-2019-6454.patch \
file://sd-bus-if-we-receive-an-invalid-dbus-message-ignore-.patch \
+ file://0036-Fix-musl-compilation.patch \
"
SRC_URI_append_qemuall = "
file://0001-core-device.c-Change-the-default-device-timeout-to-2.patch"
--
2.21.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
On 03/29/2019 05:50 AM, Dimitris Tassopoulos wrote: > Hi Alexander, > > in this case the 3g is added by default from the poky distro in > the DISTRO_FEATURES_DEFAULT var in: > *meta/conf/distro/include/default-distrovars.inc* > > And because the poky distro is the base distro for the image > this is inherited. Therefore it needs to be removed with the > DISTRO_FEATURES_remove unless there is another way, > which I'm not aware to easily remove/adjust without having > to create a new distro. Tweaking poky distro features makes the end result not poky, so the best thing to do is create your own distro. Philip > > Regards, > Dimitris > > On Fri, Mar 29, 2019 at 10:38 AM Alexander Kanavin > wrote: > >> You can do that using >> >> bitbake -e and looking for how DISTRO_FEATURES is formed in >> the output of the command. >> >> Alex >> >> On Fri, 29 Mar 2019 at 10:37, Alexander Kanavin >> wrote: >>> >>> On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos >> wrote: >>> To do that, add this to your build/conf/local.conf file > DISTRO_FEATURES_remove = " 3g" >>> >>> This works around the issue after the fact. It's better to track down >>> where 3g is added in the first place, and adjust that. >>> >>> Alex >> > > > -- ___ 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 12:49, Clemens Eisserer wrote:
> The issue was the _$PN appended to DEPENDS, when I removed it the build
> succeeded:
> changing DEPENDS_${PN} = "luajit" to DEPENDS = "luajit" did the trick.
Right, DEPENDS_${PN} isn't a variable that is used. You'll most
likely have got a warning from bitbake about that.
> However, I am still puzzled what happens here and why it worked before.
Because in the old days, every recipe shared a global sysroot. If
luajit was built at some point, it was in the sysroot. For the last
few releases (almost two years now?) the sysroot is per-recipe, so if
you don't have luajit in DEPENDS then it isn't in the sysroot.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 2/5] libldb: work around samba libldb packaging issues
On Fri, Mar 29, 2019 at 08:50:14AM +0200, Adrian Bunk wrote: > On Thu, Mar 28, 2019 at 10:28:18PM -0700, Armin Kuster wrote: > > Samba and libldb overlap in a few places. This is the simplest fix for > > now. > > Adding a quick hack for interaction problems between two packages > that are both in meta-openembedded by adding a .bbappend in > meta-security creates a technical debt while not even helping > users who are not using meta-security. > > The proper solution is likely to make samba use the external libldb > instead of an internal copy. >... commit a001e465293b36c03d4ca4500857fe0a67d13e20 Date: Fri Jul 27 14:09:10 2018 -0700 samba: Update to 4.8.3 LDB 1.4.0 breaks Samba < 4.9 therefore use internal version So the root cause is that last summer LDB in meta-openembedded was updated to a version not compatible with with the Samba version in meta-openembedded. As workaround Samba was changed to use the internal version of the library. What is now proposed is a workaround to fix a regression caused by the first workaround. The best way forward would be to upgrade Samba to 4.9 or 4.10 and use the external LDB again. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ 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,
Indeed, the luajit package contained the luajit.pc file as expected.
The issue was the _$PN appended to DEPENDS, when I removed it the build
succeeded:
changing DEPENDS_${PN} = "luajit" to DEPENDS = "luajit" did the trick.
However, I am still puzzled what happens here and why it worked before.
Br, Clemens
Am Fr., 29. März 2019 um 11:23 Uhr schrieb Burton, Ross <
ross.bur...@intel.com>:
>
> All I can say is stop digging around random paths and actually ask the
> system the questions you need answers to.
>
> - Does my recipe depend on luajit.
> Check that you have DEPENDS=luajit.
>
> - What files does luajit ship.
> $ oe-pkgdata-util list-pkg-files -p luajit
> Does that include a /usr/lib/pkgconfig/luajit.pc?
>
> Ross
>
> On Fri, 29 Mar 2019 at 00:55, Clemens Eisserer
wrote:
> >
> > 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
[yocto] Proper way to edit bootimg - image
Hi, I have created image for x86 -based hw with Yocto 2.5. Image is using bootimg-pcbios that is then mounted to /boot when image is running. I now need to modify that bootimg that is mounted in /boot. I think it's created by scripts/lib/wic/plugins/source/bootimg-pcbios.py - script. What would be proper way to to modify the bootimg or does it has to do with modifying that bootimg-pcbios.py - script? -Teemu Keskinarkaus -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu segmentation fault on gobject-introspection
On Wed 2019-02-20 @ 11:50:45 PM, João Gonçalves wrote:
> Hello,
> when trying to migrate my build to master branch of oe layers I got this
> qemu segmentation fault during gobject-introspection.
> Does anyone have any clue on this?
>
> Thank you,
> João Gonçalves
>
> | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> | Segmentation fault (core dumped)
> | If the above error message is about missing .so libraries, then setting
> up GIR_EXTRA_LIBS_PATH in the recipe should help.
> | (typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" )
> | Command
> '['/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/g-ir-scanner-qemuwrapper',
> '/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/tmp-introspect5euoldbk/GLib-2.0',
> '--introspect-dump=/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/tmp-introspect5euoldbk/functions.txt,/home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/build/tmp-introspect5euoldbk/dump.xml']'
> returned non-zero exit status 1.
> | ninja: build stopped: subcommand failed.
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> /home/joao/poky_imx6/build/tmp-glibc/work/cortexa9t2hf-neon-angstrom-linux-gnueabi/gobject-introspection/1.58.3-r0/temp/log.do_compile.20894)
> ERROR: Task
> (/home/joao/poky_imx6/poky/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.58.3.bb:do_compile)
> failed with exit code '1'
Is it possible you're building your image with the gold linker? I.e.
DISTRO_FEATURES_append = " ld-is-gold"
It looks like there's a problem using the gold linker with 32-bit ARM targets.
Everything seems to work with the regular/default bfd linker is used instead.
Please see:
http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280537.html
https://patchwork.openembedded.org/patch/159874/
Best regards,
Trevor
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
All I can say is stop digging around random paths and actually ask the system the questions you need answers to. - Does my recipe depend on luajit. Check that you have DEPENDS=luajit. - What files does luajit ship. $ oe-pkgdata-util list-pkg-files -p luajit Does that include a /usr/lib/pkgconfig/luajit.pc? Ross On Fri, 29 Mar 2019 at 00:55, Clemens Eisserer wrote: > > 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] Image introspection
DISTRO_FEATURES_DEFAULT is set using ?= : DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11" So you can override it by setting it using =, which is also a chance to trim other unnecessary features. Alex On Fri, 29 Mar 2019 at 10:50, Dimitris Tassopoulos wrote: > > Hi Alexander, > > in this case the 3g is added by default from the poky distro in > the DISTRO_FEATURES_DEFAULT var in: > meta/conf/distro/include/default-distrovars.inc > > And because the poky distro is the base distro for the image > this is inherited. Therefore it needs to be removed with the > DISTRO_FEATURES_remove unless there is another way, > which I'm not aware to easily remove/adjust without having > to create a new distro. > > Regards, > Dimitris > > On Fri, Mar 29, 2019 at 10:38 AM Alexander Kanavin > wrote: >> >> You can do that using >> >> bitbake -e and looking for how DISTRO_FEATURES is formed in >> the output of the command. >> >> Alex >> >> On Fri, 29 Mar 2019 at 10:37, Alexander Kanavin >> wrote: >> > >> > On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos >> > wrote: >> > >> > > To do that, add this to your build/conf/local.conf file >> > > >> > >> DISTRO_FEATURES_remove = " 3g" >> > >> > This works around the issue after the fact. It's better to track down >> > where 3g is added in the first place, and adjust that. >> > >> > Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
Hi Alexander, in this case the 3g is added by default from the poky distro in the DISTRO_FEATURES_DEFAULT var in: *meta/conf/distro/include/default-distrovars.inc* And because the poky distro is the base distro for the image this is inherited. Therefore it needs to be removed with the DISTRO_FEATURES_remove unless there is another way, which I'm not aware to easily remove/adjust without having to create a new distro. Regards, Dimitris On Fri, Mar 29, 2019 at 10:38 AM Alexander Kanavin wrote: > You can do that using > > bitbake -e and looking for how DISTRO_FEATURES is formed in > the output of the command. > > Alex > > On Fri, 29 Mar 2019 at 10:37, Alexander Kanavin > wrote: > > > > On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos > wrote: > > > > > To do that, add this to your build/conf/local.conf file > > > > > >> DISTRO_FEATURES_remove = " 3g" > > > > This works around the issue after the fact. It's better to track down > > where 3g is added in the first place, and adjust that. > > > > Alex > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
You can do that using bitbake -e and looking for how DISTRO_FEATURES is formed in the output of the command. Alex On Fri, 29 Mar 2019 at 10:37, Alexander Kanavin wrote: > > On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos wrote: > > > To do that, add this to your build/conf/local.conf file > > > >> DISTRO_FEATURES_remove = " 3g" > > This works around the issue after the fact. It's better to track down > where 3g is added in the first place, and adjust that. > > Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos wrote: > To do that, add this to your build/conf/local.conf file > >> DISTRO_FEATURES_remove = " 3g" This works around the issue after the fact. It's better to track down where 3g is added in the first place, and adjust that. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Documentation: unify the spacing for questions in various places e.g. before the [Y/n] there should be a space, and before "?" there should be none. Unify the questions where the syste
Signed-off-by: Gianfranco Costamagna
Signed-off-by: Gianfranco Costamagna
---
documentation/kernel-dev/kernel-dev-common.xml| 2 +-
documentation/sdk-manual/sdk-extensible.xml | 2 +-
documentation/sdk-manual/sdk-using.xml| 2 +-
meta/files/toolchain-shar-extract.sh | 4 ++--
.../initrdscripts/files/init-install-efi-testfs.sh| 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/documentation/kernel-dev/kernel-dev-common.xml
b/documentation/kernel-dev/kernel-dev-common.xml
index 7ff4cba3b0..7d8826fa35 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -185,7 +185,7 @@
Poky (Yocto Project Reference Distro) Extensible SDK installer version
Enter target directory for SDK (default: ~/poky_sdk):
- You are about to install the SDK to "/home/scottrif/poky_sdk".
Proceed[Y/n]? Y
+ You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed
[Y/n]? Y
Extracting SDK..done
Setting it up...
Extracting buildtools...
diff --git a/documentation/sdk-manual/sdk-extensible.xml
b/documentation/sdk-manual/sdk-extensible.xml
index 09f06088d2..9be082d8ba 100644
--- a/documentation/sdk-manual/sdk-extensible.xml
+++ b/documentation/sdk-manual/sdk-extensible.xml
@@ -157,7 +157,7 @@
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.5
==
Enter target directory for SDK (default: ~/poky_sdk):
- You are about to install the SDK to "/home/scottrif/poky_sdk".
Proceed[Y/n]? Y
+ You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed
[Y/n]? Y
Extracting SDK..done
Setting it up...
Extracting buildtools...
diff --git a/documentation/sdk-manual/sdk-using.xml
b/documentation/sdk-manual/sdk-using.xml
index dd220c340b..06fdb573ed 100644
--- a/documentation/sdk-manual/sdk-using.xml
+++ b/documentation/sdk-manual/sdk-using.xml
@@ -149,7 +149,7 @@
Poky (Yocto Project Reference Distro) SDK installer version
===
Enter target directory for SDK (default: /opt/poky/):
- You are about to install the SDK to "/opt/poky/". Proceed[Y/n]? Y
+ You are about to install the SDK to "/opt/poky/". Proceed [Y/n]? Y
Extracting SDK
..done
Setting it up...done
SDK has been successfully set up and is ready to be used.
diff --git a/meta/files/toolchain-shar-extract.sh
b/meta/files/toolchain-shar-extract.sh
index 9eabd62630..156085b500 100644
--- a/meta/files/toolchain-shar-extract.sh
+++ b/meta/files/toolchain-shar-extract.sh
@@ -185,11 +185,11 @@ fi
if [ -e "$target_sdk_dir/environment-setup-@REAL_MULTIMACH_TARGET_SYS@" ]; then
echo "The directory \"$target_sdk_dir\" already contains a SDK for this
architecture."
- printf "If you continue, existing files will be overwritten!
Proceed[y/N]? "
+ printf "If you continue, existing files will be overwritten! Proceed
[y/N]? "
default_answer="n"
else
- printf "You are about to install the SDK to \"$target_sdk_dir\".
Proceed[Y/n]? "
+ printf "You are about to install the SDK to \"$target_sdk_dir\".
Proceed [Y/n]? "
default_answer="y"
fi
diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
index 9c4b263d54..b351985a61 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
@@ -27,7 +27,7 @@ do
# Try sleeping here to avoid getting kernel messages
# obscuring/confusing user
sleep 5
-echo "Found drive at /dev/${device}. Do you want to install
this image there ? [y/n]"
+echo "Found drive at /dev/${device}. Do you want to install
this image there? [y/n]"
read answer
if [ "$answer" = "y" ] ; then
break
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image introspection
Hi Mikko, thanks for pointing out the buildhistory.
I need to have a look at it also as I haven't used it yet.
Also, it's very nice to see it documented so well.
Thanks!
On Fri, Mar 29, 2019 at 9:59 AM wrote:
> On Fri, Mar 29, 2019 at 09:50:20AM +0100, Dimitris Tassopoulos wrote:
> > Hi all,
> >
> > I was thinking that the mail list shouldn't be only for problems and
> > questions and that from time to time, it would be nice to see some
> guides,
> > tutorials or success stories from people that follow the list.
> >
> > Anyway, a few days ago someone had an issue with one of the BSPs I'm
> > maintaining and I wrote him a small guide on how to -try- to resolve
> future
> > issues like that. Then I thought that I haven't found a small tutorial
> > like this. Maybe it already exists, but nevertheless I haven't seen it.
> > Of course, those things are in the documentation, but they are documented
> > as individual tools (which is the correct thing to do), but it's not very
> > clear how to use all those things together to perform more complex tasks.
> >
> > So, in my case the issue was that ofono was installed in the image and
> that
> > needed to be removed. Probably a lot of you already know the answer but
> for
> > me that I've never bothered with that I had to track it down how it got
> in
> > there.
> >
> > Everything from now on assumes that you've setup up your bitbake
> environment
> > of your build with whatever setup scripts you're using (e.g.
> > *oe-init-build-env*)
> >
> > There are several ways to do introspection on an image. For example,
> > let's say that you found a file in the in rootfs and you want to know
> which
> > recipe added that file. Then you can use this command:
> >
> > oe-pkgdata-util find-path /usr/sbin/ofonod
> >
> >
> > *oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
> > `find-path` is pretty obvious what it does. This will return:
> >
> > ofono: /usr/sbin/ofonod
> >
> >
> > So now you know that it's indeed the *ofono* recipe that adds this file.
> > Next,
> > you need how this did get in the image (probably some other dependency
> > because you didn't). Then you can use the `-g` parameter with bitbake
> like
> > this:
> >
> > bitbake -g allwinner-image
> >
> >
> > This will create a file called `recipe-depends.dot`. This is a dot file
> that
> > has all the dependencies in the image. You can use the same command to
> get
> > the dependencies for a recipe, but now we care about the image.
> >
> > Next step is to search in that file, why that key is there. Why is `-w`
> and
> > key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
> > and you
> > run this command:
> >
> > oe-depends-dot -k ofono -w recipe-depends.dot
> >
> >
> > This will return the recipe that has this as dependency.
> >
> >
> > > Because: allwinner-image packagegroup-base
> >
> >
> > That means that the key is there because of allwinner-image (this is the
> > image
> > recipe, but it can be any other image) and because the *allwinner-image*
> > inherits the
> > *packagegroup-base*. So this packagegroup is the guilty.
> >
> > Let's find this thing now. Get in the meta layer sources folder and run
> this
> >
> > find . | grep packagegroup-base
> >
> >
> > This will return
> >
> > > ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
> >
> >
> > Great. Open this file to an editor and find where is *ofono*. Gotcha, is
> in:
> >
> > RDEPENDS_packagegroup-base-3g
> >
> >
> > Then it's the *packagegroup-base-3g* that does that. Probably that's a
> > recipe
> > or package group file, so you can run:
> >
> > find . | grep packagegroup-base-3g
> >
> >
> > But you get nothing... Then probably this is declared somewhere a file
> with
> > another name, so let's search inside the files in the poky layer:
> >
> > grep -nriI ackagegroup-base-3g
> >
> >
> > And we get:
> >
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
> > > ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g",
> "",
> > > d)} \
> > > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
> > > ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
> > > '',d)} \
> > > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:122:
> > > d.setVar("ADD_3G", "packagegroup-base-3g")
> > > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316
> :SUMMARY_packagegroup-base-3g
> > > = "Cellular data support"
> > > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317
> :RDEPENDS_packagegroup-base-3g
> > > = "\
> > > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320
> :RRECOMMENDS_packagegroup-base-3g
> > > = "\
> >
> >
> >
> > So it's actually in the same file that we already opened. Here you can
> > facepalm,
> > but we didn't know that, so this would be the procedure anyways to track
> it
> > down.
> > Now, search for *packagegroup-base-3g* inside the
> > *poky/meta/recipes-core/packagegroups/packagegroup-base.bb
> >
Re: [yocto] Image introspection
On Fri, Mar 29, 2019 at 09:50:20AM +0100, Dimitris Tassopoulos wrote:
> Hi all,
>
> I was thinking that the mail list shouldn't be only for problems and
> questions and that from time to time, it would be nice to see some guides,
> tutorials or success stories from people that follow the list.
>
> Anyway, a few days ago someone had an issue with one of the BSPs I'm
> maintaining and I wrote him a small guide on how to -try- to resolve future
> issues like that. Then I thought that I haven't found a small tutorial
> like this. Maybe it already exists, but nevertheless I haven't seen it.
> Of course, those things are in the documentation, but they are documented
> as individual tools (which is the correct thing to do), but it's not very
> clear how to use all those things together to perform more complex tasks.
>
> So, in my case the issue was that ofono was installed in the image and that
> needed to be removed. Probably a lot of you already know the answer but for
> me that I've never bothered with that I had to track it down how it got in
> there.
>
> Everything from now on assumes that you've setup up your bitbake environment
> of your build with whatever setup scripts you're using (e.g.
> *oe-init-build-env*)
>
> There are several ways to do introspection on an image. For example,
> let's say that you found a file in the in rootfs and you want to know which
> recipe added that file. Then you can use this command:
>
> oe-pkgdata-util find-path /usr/sbin/ofonod
>
>
> *oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
> `find-path` is pretty obvious what it does. This will return:
>
> ofono: /usr/sbin/ofonod
>
>
> So now you know that it's indeed the *ofono* recipe that adds this file.
> Next,
> you need how this did get in the image (probably some other dependency
> because you didn't). Then you can use the `-g` parameter with bitbake like
> this:
>
> bitbake -g allwinner-image
>
>
> This will create a file called `recipe-depends.dot`. This is a dot file that
> has all the dependencies in the image. You can use the same command to get
> the dependencies for a recipe, but now we care about the image.
>
> Next step is to search in that file, why that key is there. Why is `-w` and
> key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
> and you
> run this command:
>
> oe-depends-dot -k ofono -w recipe-depends.dot
>
>
> This will return the recipe that has this as dependency.
>
>
> > Because: allwinner-image packagegroup-base
>
>
> That means that the key is there because of allwinner-image (this is the
> image
> recipe, but it can be any other image) and because the *allwinner-image*
> inherits the
> *packagegroup-base*. So this packagegroup is the guilty.
>
> Let's find this thing now. Get in the meta layer sources folder and run this
>
> find . | grep packagegroup-base
>
>
> This will return
>
> > ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
>
>
> Great. Open this file to an editor and find where is *ofono*. Gotcha, is in:
>
> RDEPENDS_packagegroup-base-3g
>
>
> Then it's the *packagegroup-base-3g* that does that. Probably that's a
> recipe
> or package group file, so you can run:
>
> find . | grep packagegroup-base-3g
>
>
> But you get nothing... Then probably this is declared somewhere a file with
> another name, so let's search inside the files in the poky layer:
>
> grep -nriI ackagegroup-base-3g
>
>
> And we get:
>
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
> > ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> > d)} \
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
> > ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
> > '',d)} \
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:122:
> > d.setVar("ADD_3G", "packagegroup-base-3g")
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316:SUMMARY_packagegroup-base-3g
> > = "Cellular data support"
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317:RDEPENDS_packagegroup-base-3g
> > = "\
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320:RRECOMMENDS_packagegroup-base-3g
> > = "\
>
>
>
> So it's actually in the same file that we already opened. Here you can
> facepalm,
> but we didn't know that, so this would be the procedure anyways to track it
> down.
> Now, search for *packagegroup-base-3g* inside the
> *poky/meta/recipes-core/packagegroups/packagegroup-base.bb
> *
> and you see this line:
>
> ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> > d)} \
>
>
> Therefore the *3g* in the *DISTRO_FEATURES* actually added *ofono*. That
> means that,
> we need to remove the *3g* string from our *DISTRO_FEATURES*.
>
> To do that, add this to your build/conf/local.conf file
>
> DISTRO_FEATURES_remove = " 3g"
>
>
> Now just to be sure, run this to clean *ofono* from cache
[yocto] Image introspection
Hi all,
I was thinking that the mail list shouldn't be only for problems and
questions and that from time to time, it would be nice to see some guides,
tutorials or success stories from people that follow the list.
Anyway, a few days ago someone had an issue with one of the BSPs I'm
maintaining and I wrote him a small guide on how to -try- to resolve future
issues like that. Then I thought that I haven't found a small tutorial
like this. Maybe it already exists, but nevertheless I haven't seen it.
Of course, those things are in the documentation, but they are documented
as individual tools (which is the correct thing to do), but it's not very
clear how to use all those things together to perform more complex tasks.
So, in my case the issue was that ofono was installed in the image and that
needed to be removed. Probably a lot of you already know the answer but for
me that I've never bothered with that I had to track it down how it got in
there.
Everything from now on assumes that you've setup up your bitbake environment
of your build with whatever setup scripts you're using (e.g.
*oe-init-build-env*)
There are several ways to do introspection on an image. For example,
let's say that you found a file in the in rootfs and you want to know which
recipe added that file. Then you can use this command:
oe-pkgdata-util find-path /usr/sbin/ofonod
*oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
`find-path` is pretty obvious what it does. This will return:
ofono: /usr/sbin/ofonod
So now you know that it's indeed the *ofono* recipe that adds this file.
Next,
you need how this did get in the image (probably some other dependency
because you didn't). Then you can use the `-g` parameter with bitbake like
this:
bitbake -g allwinner-image
This will create a file called `recipe-depends.dot`. This is a dot file that
has all the dependencies in the image. You can use the same command to get
the dependencies for a recipe, but now we care about the image.
Next step is to search in that file, why that key is there. Why is `-w` and
key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
and you
run this command:
oe-depends-dot -k ofono -w recipe-depends.dot
This will return the recipe that has this as dependency.
> Because: allwinner-image packagegroup-base
That means that the key is there because of allwinner-image (this is the
image
recipe, but it can be any other image) and because the *allwinner-image*
inherits the
*packagegroup-base*. So this packagegroup is the guilty.
Let's find this thing now. Get in the meta layer sources folder and run this
find . | grep packagegroup-base
This will return
> ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
Great. Open this file to an editor and find where is *ofono*. Gotcha, is in:
RDEPENDS_packagegroup-base-3g
Then it's the *packagegroup-base-3g* that does that. Probably that's a
recipe
or package group file, so you can run:
find . | grep packagegroup-base-3g
But you get nothing... Then probably this is declared somewhere a file with
another name, so let's search inside the files in the poky layer:
grep -nriI ackagegroup-base-3g
And we get:
poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
> ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> d)} \
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
> ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
> '',d)} \
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:122:
> d.setVar("ADD_3G", "packagegroup-base-3g")
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316:SUMMARY_packagegroup-base-3g
> = "Cellular data support"
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317:RDEPENDS_packagegroup-base-3g
> = "\
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320:RRECOMMENDS_packagegroup-base-3g
> = "\
So it's actually in the same file that we already opened. Here you can
facepalm,
but we didn't know that, so this would be the procedure anyways to track it
down.
Now, search for *packagegroup-base-3g* inside the
*poky/meta/recipes-core/packagegroups/packagegroup-base.bb
*
and you see this line:
${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
> d)} \
Therefore the *3g* in the *DISTRO_FEATURES* actually added *ofono*. That
means that,
we need to remove the *3g* string from our *DISTRO_FEATURES*.
To do that, add this to your build/conf/local.conf file
DISTRO_FEATURES_remove = " 3g"
Now just to be sure, run this to clean *ofono* from cache and everywhere
else:
bitbake -c cleanall ofono
And then rebuild the image:
bitbake image-name
Now you'll see that *ofono* won't b e downloaded or get built and it won't
be in your image.
I hope the above guide helps a bit.
I would be glad to get better suggestions or other people experience on
how they introspect their images and solve
Re: [yocto] [meta-security][PATCH 4/5] sssd: update to 1.16.4
On Thu, Mar 28, 2019 at 10:28:20PM -0700, Armin Kuster wrote:
> Add systemd pkgconf via DISTRO_FEATURE
>
> Fix uid/gid of sssd.conf
>
> Signed-off-by: Armin Kuster
>...
> -RDEPENDS_${PN} = "bind dbus samba libldb"
> +RDEPENDS_${PN} = "bind dbus samba libldb libpam"
Why is this required?
And the way this commit mixes unrelated changes, it is no even clear
whether this is for the new upstream version or supposed to fix some
older issue.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 3/5] sssd: fix a few runtime issues
On Thu, Mar 28, 2019 at 10:28:19PM -0700, Armin Kuster wrote:
> 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
>...
> # The package contains symlinks that trip up insane
> INSANE_SKIP_${PN} = "dev-so"
>
> -RDEPENDS_${PN} += "bind dbus"
> +RDEPENDS_${PN} = "bind dbus samba libldb"
Even when samba support is not enabled?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 2/5] libldb: work around samba libldb packaging issues
On Thu, Mar 28, 2019 at 10:28:18PM -0700, Armin Kuster wrote: > Samba and libldb overlap in a few places. This is the simplest fix for > now. Adding a quick hack for interaction problems between two packages that are both in meta-openembedded by adding a .bbappend in meta-security creates a technical debt while not even helping users who are not using meta-security. The proper solution is likely to make samba use the external libldb instead of an internal copy. > 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" >... So just adding the meta-security layer will turn the pyldb* packages into empty packages? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
