[OE-core] [PATCH] mdadm: install the systemd service through Makefile
The original mdadm service may include variable like BINDIR,
It should use the real value of it, since the install method
"install-systemd" in Makefile can easily do such work, so don't
install it in bb file manually, use "make install-systemd" to
install all the service of mdadm.
Signed-off-by: Liwei Song
---
meta/recipes-extended/mdadm/mdadm_4.1.bb | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-extended/mdadm/mdadm_4.1.bb
b/meta/recipes-extended/mdadm/mdadm_4.1.bb
index 4168ce4d0cb8..a4b9ef94799f 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.1.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.1.bb
@@ -55,13 +55,15 @@ do_install() {
do_install_append() {
install -d ${D}/${sysconfdir}/
install -m 644 ${S}/mdadm.conf-example ${D}${sysconfdir}/mdadm.conf
-install -d ${D}/${systemd_unitdir}/system
-install -m 644 ${WORKDIR}/mdmonitor.service
${D}/${systemd_unitdir}/system
-install -m 644 ${S}/systemd/mdmon@.service
${D}/${systemd_unitdir}/system
install -d ${D}/${sysconfdir}/init.d
install -m 755 ${WORKDIR}/mdadm.init ${D}${sysconfdir}/init.d/mdmonitor
}
+do_install_append() {
+oe_runmake install-systemd DESTDIR=${D}
+}
+
+
do_compile_ptest() {
oe_runmake test
}
@@ -88,3 +90,5 @@ RRECOMMENDS_${PN}-ptest += " \
kernel-module-raid10 \
kernel-module-raid456 \
"
+
+FILES_${PN} += "/lib/systemd/*"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] add wic based image installer
On Thu, May 16, 2019 at 02:23:05AM +, Lee, Chee Yang wrote: > Hi Tom, > > Would you mind to share with me how you make the installer image using wic? I ended up using sdimage-bootpart.wks and IMAGE_BOOT_FILES to populate the partition as needed. I can't paste the exact image as it was done for a customer. > > Forwarded Message > From: Tom Rini > To: chee.yang@intel.com > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH 0/4] add wic based image installer > Date: Wed, 15 May 2019 11:33:43 -0400 > > On Wed, May 08, 2019 at 02:40:58PM +0800, chee.yang@intel.com > wrote: > > > From: Chee Yang Lee > > > > Existing installable image (hddimg/ISO) has limit of 4GB size, so to > > build larger installable image, we can build it in wic based image. > > > > 2 partition needed for installable image > > - first partition build using source plugin bootimg-efi and > > configure to run install > > - second partition build with root.img, systemd-boot and kernel to > > be install on target machine (this partition build using new source > > plugin installer-partition) > > > > These patches: > > - add new source plugin for second partition > > - add new .wks > > - add new wic dependency and set default value for required variable > > - allow source plugin bootimg-efi to configure to install > > > > > > To build the image, set WKS_FILE="wic-installer.wks.in" in > > local.conf. > > I'm confused as to why we need most of these changes to support the end > goal. The enhancement to bootimg-efi makes conceptual sense. I don't > see why we need a new plugin to do the rest, however. What's being > done > here that we don't already do today? I say this having made installer > images for EFI machines using wic (in sumo, even). Thanks! > > -- > Tom > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] add wic based image installer
Hi Tom, Would you mind to share with me how you make the installer image using wic? Forwarded Message From: Tom Rini To: chee.yang@intel.com Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH 0/4] add wic based image installer Date: Wed, 15 May 2019 11:33:43 -0400 On Wed, May 08, 2019 at 02:40:58PM +0800, chee.yang@intel.com wrote: > From: Chee Yang Lee > > Existing installable image (hddimg/ISO) has limit of 4GB size, so to > build larger installable image, we can build it in wic based image. > > 2 partition needed for installable image > - first partition build using source plugin bootimg-efi and > configure to run install > - second partition build with root.img, systemd-boot and kernel to > be install on target machine (this partition build using new source > plugin installer-partition) > > These patches: > - add new source plugin for second partition > - add new .wks > - add new wic dependency and set default value for required variable > - allow source plugin bootimg-efi to configure to install > > > To build the image, set WKS_FILE="wic-installer.wks.in" in > local.conf. I'm confused as to why we need most of these changes to support the end goal. The enhancement to bootimg-efi makes conceptual sense. I don't see why we need a new plugin to do the rest, however. What's being done here that we don't already do today? I say this having made installer images for EFI machines using wic (in sumo, even). Thanks! -- Tom -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [V3][Oe-core][PATCH] sysstat: Add PACKAGECONFIG[cron] for '--enable-install-cron' option
Thanks, will update in new rr.
-Original Message-
From: Martin Hundebøll [mailto:mar...@geanix.com]
Sent: 2019年5月15日 15:07
To: Bai, Haiqing; ross.bur...@intel.com;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [V3][Oe-core][PATCH] sysstat: Add PACKAGECONFIG[cron]
for '--enable-install-cron' option
Hi,
On 15/05/2019 08.42, Haiqing Bai wrote:
> If 'cron' is added into PACKAGECONFIG, for sysvinit, the related
> cron scripts will be installed; for systemd, the services of
> data collect and summary will be installed.
>
> Signed-off-by: Haiqing Bai
> ---
> meta/recipes-extended/sysstat/sysstat.inc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-extended/sysstat/sysstat.inc
> b/meta/recipes-extended/sysstat/sysstat.inc
> index 0bc7e14d36..79555e6cf3 100644
> --- a/meta/recipes-extended/sysstat/sysstat.inc
> +++ b/meta/recipes-extended/sysstat/sysstat.inc
> @@ -19,6 +19,7 @@ inherit autotools-brokensep gettext systemd
>
> PACKAGECONFIG ??= ""
> PACKAGECONFIG[lm-sensors] =
> "--enable-sensors,--disable-sensors,lmsensors,lmsensors-libsensors"
> +PACKAGECONFIG[cron] = "--enable-install-cron
> --enable-copy-only,--disable-install-cron --disable-copy-only"
>
> EXTRA_OECONF += "--disable-stripping"
>
> @@ -59,7 +60,6 @@ pkg_postinst_${PN} () {
> fi
> }
>
> -
> -FILES_${PN} += "${libdir}/sa"
> +FILES_${PN} += "${libdir}/sa ${systemd_unitdir}/system/*"
You can use "${systemd_system_unitdir}" instead of
"${systemd_unitdir}/system/". And also no need to append the asterisk.
// Martin
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [V4][Oe-core][PATCH] sysstat: Add PACKAGECONFIG[cron] for '--enable-install-cron' option
If 'cron' is added into PACKAGECONFIG, for sysvinit, the related
cron scripts will be installed; for systemd, the services of
data collect and summary will be installed.
Signed-off-by: Haiqing Bai
---
meta/recipes-extended/sysstat/sysstat.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/sysstat/sysstat.inc
b/meta/recipes-extended/sysstat/sysstat.inc
index 0bc7e14d36..79555e6cf3 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -19,6 +19,7 @@ inherit autotools-brokensep gettext systemd
PACKAGECONFIG ??= ""
PACKAGECONFIG[lm-sensors] =
"--enable-sensors,--disable-sensors,lmsensors,lmsensors-libsensors"
+PACKAGECONFIG[cron] = "--enable-install-cron
--enable-copy-only,--disable-install-cron --disable-copy-only"
EXTRA_OECONF += "--disable-stripping"
@@ -59,7 +60,6 @@ pkg_postinst_${PN} () {
fi
}
-
-FILES_${PN} += "${libdir}/sa"
+FILES_${PN} += "${libdir}/sa ${systemd_system_unitdir}"
TARGET_CC_ARCH += "${LDFLAGS}"
--
2.18.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] add wic based image installer
Any comments on these patches? -Original Message- From: openembedded-core-boun...@lists.openembedded.org On Behalf Of chee.yang@intel.com Sent: Wednesday, May 8, 2019 2:41 PM To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH 0/4] add wic based image installer From: Chee Yang Lee Existing installable image (hddimg/ISO) has limit of 4GB size, so to build larger installable image, we can build it in wic based image. 2 partition needed for installable image - first partition build using source plugin bootimg-efi and configure to run install - second partition build with root.img, systemd-boot and kernel to be install on target machine (this partition build using new source plugin installer-partition) These patches: - add new source plugin for second partition - add new .wks - add new wic dependency and set default value for required variable - allow source plugin bootimg-efi to configure to install To build the image, set WKS_FILE="wic-installer.wks.in" in local.conf. Chee Yang Lee (4): wic: add new installer-partition plugin wic: bootimg-efi: add label source parameter wic: add new wic-installer.wks for wic based image installer image_types_wic: add dependency for wic based image installer meta/classes/image_types_wic.bbclass | 6 + scripts/lib/wic/canned-wks/wic-installer.wks.in| 7 + scripts/lib/wic/plugins/source/bootimg-efi.py | 20 ++- .../lib/wic/plugins/source/installer-partition.py | 192 + 4 files changed, 220 insertions(+), 5 deletions(-) create mode 100644 scripts/lib/wic/canned-wks/wic-installer.wks.in create mode 100644 scripts/lib/wic/plugins/source/installer-partition.py -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2 v2] oeqa/runtime/cases/rpm.py: Enable rpm install dependency testing
Convert manual testcase bsps-hw.bsps-hw.rpm_-__install_dependency_package
from oeqa/manual/bsp-hw.json to runtime automated test.
Signed-off-by: Yeoh Ee Peng
---
meta/lib/oeqa/runtime/cases/rpm.py | 30 ++
1 file changed, 30 insertions(+)
diff --git a/meta/lib/oeqa/runtime/cases/rpm.py
b/meta/lib/oeqa/runtime/cases/rpm.py
index d8cabd3..f71125f 100644
--- a/meta/lib/oeqa/runtime/cases/rpm.py
+++ b/meta/lib/oeqa/runtime/cases/rpm.py
@@ -135,3 +135,33 @@ class RpmInstallRemoveTest(OERuntimeTestCase):
# Check that there's enough of them
self.assertGreaterEqual(int(output), 80,
'Cound not find sufficient amount of rpm
entries in /var/log/messages, found {} entries'.format(output))
+
+@OETestDepends(['rpm.RpmBasicTest.test_rpm_query'])
+def test_rpm_install_dependency(self):
+rpmdir = os.path.join(self.tc.td['DEPLOY_DIR'], 'rpm', 'noarch')
+rpm_tests = {'run-postinsts-dev': '', 'run-postinsts': ''}
+rpm_pattern = 'run-postinsts-*.noarch.rpm'
+for f in fnmatch.filter(os.listdir(rpmdir), rpm_pattern):
+if 'run-postinsts-dev' not in f and 'run-postinsts-dbg' not in f:
+rpm_tests['run-postinsts'] = f
+continue
+if 'run-postinsts-dev' in f:
+rpm_tests['run-postinsts-dev'] = f
+continue
+rpm_dest_dir = '/tmp'
+for rpm in rpm_tests:
+self.tc.target.copyTo(os.path.join(rpmdir, rpm_tests[rpm]),
os.path.join(rpm_dest_dir, rpm_tests[rpm]))
+# remove existing rpm before testing install with dependency
+self.tc.target.run('rpm -e %s' % 'run-postinsts-dev')
+self.tc.target.run('rpm -e %s' % 'run-postinsts')
+status, output = self.tc.target.run('rpm -ivh %s' %
os.path.join(rpm_dest_dir, rpm_tests['run-postinsts-dev']))
+self.assertTrue(status == 1, 'rpm installed should have failed but it
was getting %s' % status)
+self.assertTrue('error: Failed dependencies:' in output,
+'rpm installed should have failed with error but it
was getting: %s' % output)
+# reinstall rpm with dependency
+status, output = self.tc.target.run('rpm -ivh %s' %
os.path.join(rpm_dest_dir, rpm_tests['run-postinsts']))
+self.assertTrue(status == 0, 'rpm (%s) installed with error: %s (%s)'
% (rpm_tests['run-postinsts'], status, output))
+status, output = self.tc.target.run('rpm -ivh %s' %
os.path.join(rpm_dest_dir, rpm_tests['run-postinsts-dev']))
+self.assertTrue(status == 0, 'rpm (%s) installed with error: %s (%s)'
% (rpm_tests['run-postinsts-dev'], status, output))
+for rpm in rpm_tests:
+self.tc.target.run('rm -f %s' % os.path.join(rpm_dest_dir,
rpm_tests[rpm]))
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2 v2] oeqa/manual/bsp-hw.json: Remove rpm install dependency
Remove the bsps-hw.bsps-hw.rpm_-__install_dependency_package
as it was replaced by the test_rpm_install_dependency inside
oeqa/runtime/cases/rpm.py.
Signed-off-by: Yeoh Ee Peng
---
meta/lib/oeqa/manual/bsp-hw.json | 26 --
1 file changed, 26 deletions(-)
diff --git a/meta/lib/oeqa/manual/bsp-hw.json b/meta/lib/oeqa/manual/bsp-hw.json
index 4b7c76f..017de9d 100644
--- a/meta/lib/oeqa/manual/bsp-hw.json
+++ b/meta/lib/oeqa/manual/bsp-hw.json
@@ -1,32 +1,6 @@
[
{
"test": {
-"@alias": "bsps-hw.bsps-hw.rpm_-__install_dependency_package",
-"author": [
-{
-"email": "alexandru.c.george...@intel.com",
-"name": "alexandru.c.george...@intel.com"
-}
-],
-"execution": {
-"1": {
-"action": "Get a not previously installed RPM package or
build one on local machine, which should have run-time dependency.For example,
\"mc\" (Midnight Commander, which is a visual file manager) should depend on
\"ncurses-terminfo\". \n\n$ bitbake mc \n\n\n",
-"expected_results": ""
-},
-"2": {
-"action": "Copy the package into a system folder (for
example /home/root/rpm_packages). \n\n\n",
-"expected_results": ""
-},
-"3": {
-"action": "Run \"rpm -ivh package_name\" and check the
output, for example \"rpm -ivh mc.rpm*\" should report the dependency on
\"ncurses-terminfo\".\n\n\n\n",
-"expected_results": "3 . rpm command should report message
when some RPM installation depends on other packages."
-}
-},
-"summary": "rpm_-__install_dependency_package"
-}
-},
-{
-"test": {
"@alias": "bsps-hw.bsps-hw.boot_and_install_from_USB",
"author": [
{
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libtest-needs-perl: upgrade 0.002005 -> 0.002006
Change SRC_URI to https://cpan.metacpan.org
License-Update: Lines moved further down in README.
Upstream release notes:
0.002006 - 2019-04-04
- added additional references to related modules in pod
- various internal cleanups
- fix backwards compatibility with earlier versions of version.pm
- fix output from test script when tests fail
- added note about RELEASE_TESTING to test message on forced failures
Signed-off-by: Tim Orling
---
...ds-perl_0.002005.bb => libtest-needs-perl_0.002006.bb} | 8
1 file changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-devtools/perl/{libtest-needs-perl_0.002005.bb =>
libtest-needs-perl_0.002006.bb} (72%)
diff --git a/meta/recipes-devtools/perl/libtest-needs-perl_0.002005.bb
b/meta/recipes-devtools/perl/libtest-needs-perl_0.002006.bb
similarity index 72%
rename from meta/recipes-devtools/perl/libtest-needs-perl_0.002005.bb
rename to meta/recipes-devtools/perl/libtest-needs-perl_0.002006.bb
index e5ab7a33c7..3abb9aa8e4 100644
--- a/meta/recipes-devtools/perl/libtest-needs-perl_0.002005.bb
+++ b/meta/recipes-devtools/perl/libtest-needs-perl_0.002006.bb
@@ -11,14 +11,14 @@ LICENSE = "Artistic-1.0 | GPL-1.0+"
CPAN_NAME = "Test-Needs"
CPAN_AUTHOR = "HAARG"
-LIC_FILES_CHKSUM =
"file://README;md5=3f3ccd21a0a48aa313db212cc3b1bc09;beginline=81;endline=82"
+LIC_FILES_CHKSUM =
"file://README;md5=3f3ccd21a0a48aa313db212cc3b1bc09;beginline=88;endline=89"
DEPENDS += "perl"
-SRC_URI =
"http://www.cpan.org/authors/id/H/HA/${CPAN_AUTHOR}/${CPAN_NAME}-${PV}.tar.gz;
+SRC_URI =
"https://cpan.metacpan.org/authors/id/H/HA/${CPAN_AUTHOR}/${CPAN_NAME}-${PV}.tar.gz;
-SRC_URI[md5sum] = "356634a56c99282e8059f290f5d534c8"
-SRC_URI[sha256sum] =
"5a4f33983586edacdbe00a3b429a9834190140190dab28d0f873c394eb7df399"
+SRC_URI[md5sum] = "d5c96d51d8d5510f7c0b7f354c49af1c"
+SRC_URI[sha256sum] =
"77f9fff0c96c5e09f34d0416b3533c3319f7cd0bb1f7fe8f8072ad59f433f0e5"
S = "${WORKDIR}/${CPAN_NAME}-${PV}"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] oeqa/runtime/cases/rpm.py: Enable rpm install dependency testing
On Wed, 2019-05-15 at 21:43 +0200, Alexander Kanavin wrote: > This needs the same condition guard as other rpm tests, e.g. > > @OETestDepends(['rpm.RpmBasicTest.test_rpm_query']) > > should be enough. Yes, there were failures on the autobuilder from this, e.g.: https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/602 https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/596 and so on. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] oeqa/runtime/cases/rpm.py: Enable rpm install dependency testing
This needs the same condition guard as other rpm tests, e.g.
@OETestDepends(['rpm.RpmBasicTest.test_rpm_query'])
should be enough.
Alex
On Wed, 15 May 2019 at 04:48, Yeoh Ee Peng wrote:
>
> Convert manual testcase bsps-hw.bsps-hw.rpm_-__install_dependency_package
> from oeqa/manual/bsp-hw.json to runtime automated test.
>
> Signed-off-by: Yeoh Ee Peng
> ---
> meta/lib/oeqa/runtime/cases/rpm.py | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/meta/lib/oeqa/runtime/cases/rpm.py
> b/meta/lib/oeqa/runtime/cases/rpm.py
> index d8cabd3..fe1b489 100644
> --- a/meta/lib/oeqa/runtime/cases/rpm.py
> +++ b/meta/lib/oeqa/runtime/cases/rpm.py
> @@ -135,3 +135,32 @@ class RpmInstallRemoveTest(OERuntimeTestCase):
> # Check that there's enough of them
> self.assertGreaterEqual(int(output), 80,
> 'Cound not find sufficient amount of rpm
> entries in /var/log/messages, found {} entries'.format(output))
> +
> +def test_rpm_install_dependency(self):
> +rpmdir = os.path.join(self.tc.td['DEPLOY_DIR'], 'rpm', 'noarch')
> +rpm_tests = {'run-postinsts-dev': '', 'run-postinsts': ''}
> +rpm_pattern = 'run-postinsts-*.noarch.rpm'
> +for f in fnmatch.filter(os.listdir(rpmdir), rpm_pattern):
> +if 'run-postinsts-dev' not in f and 'run-postinsts-dbg' not in f:
> +rpm_tests['run-postinsts'] = f
> +continue
> +if 'run-postinsts-dev' in f:
> +rpm_tests['run-postinsts-dev'] = f
> +continue
> +rpm_dest_dir = '/tmp'
> +for rpm in rpm_tests:
> +self.tc.target.copyTo(os.path.join(rpmdir, rpm_tests[rpm]),
> os.path.join(rpm_dest_dir, rpm_tests[rpm]))
> +# remove existing rpm before testing install with dependency
> +self.tc.target.run('rpm -e %s' % 'run-postinsts-dev')
> +self.tc.target.run('rpm -e %s' % 'run-postinsts')
> +status, output = self.tc.target.run('rpm -ivh %s' %
> os.path.join(rpm_dest_dir, rpm_tests['run-postinsts-dev']))
> +self.assertTrue(status == 1, 'rpm installed should have failed but
> it was getting %s' % status)
> +self.assertTrue('error: Failed dependencies:' in output,
> +'rpm installed should have failed with error but it
> was getting: %s' % output)
> +# reinstall rpm with dependency
> +status, output = self.tc.target.run('rpm -ivh %s' %
> os.path.join(rpm_dest_dir, rpm_tests['run-postinsts']))
> +self.assertTrue(status == 0, 'rpm (%s) installed with error: %s
> (%s)' % (rpm_tests['run-postinsts'], status, output))
> +status, output = self.tc.target.run('rpm -ivh %s' %
> os.path.join(rpm_dest_dir, rpm_tests['run-postinsts-dev']))
> +self.assertTrue(status == 0, 'rpm (%s) installed with error: %s
> (%s)' % (rpm_tests['run-postinsts-dev'], status, output))
> +for rpm in rpm_tests:
> +self.tc.target.run('rm -f %s' % os.path.join(rpm_dest_dir,
> rpm_tests[rpm]))
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] meta: handle UBOOT_CONFIG in image.bbclass
From: Ming Liu
The code dealing with IMAGE_FSTYPES in uboot-config.bbclass would not
take any effect since it's in a uboot particular class, but it's not
being inherited by any image recipes.
Move the IMAGE_FSTYPES handling part to image.bbclass would make it
really work.
Also drop some trivial debug code.
Signed-off-by: Ming Liu
---
meta/classes/image.bbclass| 12
meta/classes/uboot-config.bbclass | 17 -
meta/conf/documentation.conf | 2 +-
3 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index d2b2fb9..b1d63c6 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -365,6 +365,18 @@ python () {
return basetype
+# Check UBOOT_CONFIG
+ubootconfig = (d.getVar('UBOOT_CONFIG') or "").split()
+ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
+ubootconfigflags.pop('doc', None)
+if len(ubootconfig) > 0:
+for config in ubootconfig:
+for f, v in ubootconfigflags.items():
+if config == f:
+items = v.split(',')
+if len(items) > 1 and items[1]:
+d.appendVar('IMAGE_FSTYPES', ' ' + items[1])
+
basetypes = {}
alltypes = d.getVar('IMAGE_FSTYPES').split()
typedeps = {}
diff --git a/meta/classes/uboot-config.bbclass
b/meta/classes/uboot-config.bbclass
index 89ff970..59dcd04 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -15,18 +15,15 @@ UBOOT_BINARY ?= "u-boot.${UBOOT_SUFFIX}"
python () {
ubootmachine = d.getVar("UBOOT_MACHINE")
-ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
ubootbinary = d.getVar('UBOOT_BINARY')
ubootbinaries = d.getVar('UBOOT_BINARIES')
+ubootconfig = (d.getVar('UBOOT_CONFIG') or "").split()
+ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')
+
# The "doc" varflag is special, we don't want to see it here
ubootconfigflags.pop('doc', None)
-ubootconfig = (d.getVar('UBOOT_CONFIG') or "").split()
if not ubootmachine and not ubootconfig:
-PN = d.getVar("PN")
-FILE = os.path.basename(d.getVar("FILE"))
-bb.debug(1, "To build %s, see %s for instructions on \
- setting up your machine config" % (PN, FILE))
raise bb.parse.SkipRecipe("Either UBOOT_MACHINE or UBOOT_CONFIG must
be set in the %s machine configuration." % d.getVar("MACHINE"))
if ubootmachine and ubootconfig:
@@ -40,18 +37,12 @@ python () {
for f, v in ubootconfigflags.items():
if config == f:
items = v.split(',')
-if items[0] and len(items) > 3:
+if len(items) == 0 or len(items) > 3:
raise bb.parse.SkipRecipe('Only config,images,binary
can be specified!')
d.appendVar('UBOOT_MACHINE', ' ' + items[0])
-# IMAGE_FSTYPES appending
-if len(items) > 1 and items[1]:
-bb.debug(1, "Appending '%s' to IMAGE_FSTYPES." %
items[1])
-d.appendVar('IMAGE_FSTYPES', ' ' + items[1])
if len(items) > 2 and items[2]:
-bb.debug(1, "Appending '%s' to UBOOT_BINARIES." %
items[2])
d.appendVar('UBOOT_BINARIES', ' ' + items[2])
else:
-bb.debug(1, "Appending '%s' to UBOOT_BINARIES." %
ubootbinary)
d.appendVar('UBOOT_BINARIES', ' ' + ubootbinary)
break
}
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 550df20..048ce12 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -439,7 +439,7 @@ TUNEVALID[doc] = "Descriptions, stored as flags, of valid
tuning features."
#U
-UBOOT_CONFIG[doc] = "Configures the UBOOT_MACHINE and can also define
IMAGE_FSTYPES for individual cases."
+UBOOT_CONFIG[doc] = "Configures the UBOOT_MACHINE and can also define
IMAGE_FSTYPES, UBOOT_BINARIES for individual cases."
UBOOT_ENTRYPOINT[doc] = "Specifies the entry point for the U-Boot image."
UBOOT_LOADADDRESS[doc] = "Specifies the load address for the U-Boot image."
UBOOT_LOCALVERSION[doc] = "Appends a string to the name of the local version
of the U-Boot image."
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] valgrind: do not strip the package or ptests
On 5/14/19 10:22 PM, Randy MacLeod wrote:
...
It's tempting to just bump the timeout to 300 seconds
since anything that fails with that timeout really should
be fixed. The right thing is to pass the timeout from ptest-runner
down to valgrind's vg_regtest script. If we have people who set
timeouts to a non-default value and will be running valgrind's
ptest then I could do that.
Since I'm a completist, I'm going to try qemumips64 next! :)
Okay, so maybe I'm not a MIPS64 completist!
qemumips64 hangs on drd/tests/annotate_barrier. I'm not sure why.
When run under gdb:
(gdb) bt
#0 vgPlain_machine_get_hwcaps () at
../../valgrind-3.15.0/coregrind/m_machine.c:1910
#1 0x580b5a80 in valgrind_main (argc=, argv=0x580bb430
<_start_in_C_linux+224>, envp=0x120015520)
at ../../valgrind-3.15.0/coregrind/m_main.c:1375
#2 0x580bb430 in _start_in_C_linux (pArgc=0xffabe0) at
../../valgrind-3.15.0/coregrind/m_main.c:2985
#3 0x580b47e8 in __start ()
Backtrace stopped: frame did not save the PC
(gdb) bt full
#0 vgPlain_machine_get_hwcaps () at
../../valgrind-3.15.0/coregrind/m_machine.c:1910
have_MSA = 1 '\001'
saved_set = {sig = {0, 0}}
tmp_set = {sig = {8, 0}}
saved_sigill_act = {sa_flags = 0, ksa_handler = 0x0, sa_mask = {sig =
{0, 0}}, sa_restorer = 0xffae8e}
tmp_sigill_act = {sa_flags = 1073741824, ksa_handler = 0x58036f90
, sa_mask = {sig = {0, 0}}, sa_restorer = 0xffae8e}
r =
__PRETTY_FUNCTION__ = "vgPlain_machine_get_hwcaps"
1905 /* MSA instructions */
1906 have_MSA = True;
1907 if (VG_MINIMAL_SETJMP(env_unsup_insn)) {
1908 have_MSA = False;
1909 }else {
1910 __asm__ __volatile__(".word 0x7800088E");/* addv.b w2, w1, w0
*/
1911 }
The qemumips64 ptests for valgrind are now on the back burner.
--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior][PATCH 2/2] perf: make sure that the tools/include/uapi/asm-generic directory exists
* before trying to copy unistd.h into it
* older kernels don't have uapi in tools/include and do_configure fails
with:
DEBUG: Executing shell function do_configure
cp: cannot create regular file
'.../perf/1.0-r9/perf-1.0/tools/include/uapi/asm-generic/unistd.h':
No such file or directory
WARNING: exit code 1 from a shell command.
* tools/include/uapi was added in kernel 4.8 with
https://github.com/torvalds/linux/commit/c4b6014e8bb0c8d47fe5c71ebc604f31091e5d3f
tools: Add copy of perf_event.h to tools/include/linux/
Signed-off-by: Martin Jansa
---
meta/recipes-kernel/perf/perf.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 546076f84b..4e603f1a32 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -238,7 +238,7 @@ do_configure_prepend () {
# unistd.h can be out of sync between libc-headers and the captured
version in the perf source
# so we copy it from the sysroot unistd.h to the perf unistd.h
-cp ${STAGING_INCDIR}/asm-generic/unistd.h
${S}/tools/include/uapi/asm-generic/unistd.h
+install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
${S}/tools/include/uapi/asm-generic/unistd.h
}
python do_package_prepend() {
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior][PATCH 1/2] glib-networking: add PACKAGECONFIG for openssl
* gnutls from meta-gplv2 isn't new enough for this version of glib-networking: meson.build:74:0: ERROR: Invalid version of dependency, need 'gnutls' ['>= 3.4.6'] found '3.3.30' * disabling gnutls PACKAGECONFIG isn't an option either: meson.build:131:2: ERROR: Problem encountered: No TLS backends enabled. Please enable at least one TLS backend * add an option to replace gnutls with openssl Signed-off-by: Martin Jansa --- meta/recipes-core/glib-networking/glib-networking_2.60.1.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/glib-networking/glib-networking_2.60.1.bb b/meta/recipes-core/glib-networking/glib-networking_2.60.1.bb index 09af229d69..e2b4cffb2b 100644 --- a/meta/recipes-core/glib-networking/glib-networking_2.60.1.bb +++ b/meta/recipes-core/glib-networking/glib-networking_2.60.1.bb @@ -15,6 +15,7 @@ SRC_URI[archive.sha256sum] = "d71c6b2faa5ac29100314f08a1be020a2afd0291f025614c0a PACKAGECONFIG ??= "gnutls" PACKAGECONFIG[gnutls] = "-Dgnutls=enabled,-Dgnutls=disabled,gnutls" +PACKAGECONFIG[openssl] = "-Dopenssl=enabled,-Dopenssl=disabled,openssl" PACKAGECONFIG[libproxy] = "-Dlibproxy=enabled,-Dlibproxy=disabled,libproxy" EXTRA_OEMESON = "-Dgnome_proxy=disabled" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] core-image-sato-sdk-ptest: Tweak size to stay within 4GB limit
Adding the valgrind debug symbol information caused the genericx86-64 image to
overflow the 4GB boundary. Tweak the sizes to avoid autobuilder failures yet
leave enough space all the tests still run successfully.
Signed-off-by: Richard Purdie
---
meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
index 2497fc42aee..e84beda6ce1 100644
--- a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
+++ b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
@@ -12,10 +12,10 @@ IMAGE_INSTALL += "${PTESTS_FAST} ${PTESTS_SLOW}"
# This image is sufficiently large (~1.8GB) that we need to be careful that it
fits in a live
# image (which has a 4GB limit), so nullify the overhead factor (1.3x out of
the
-# box) and explicitly add just 1300MB.
+# box) and explicitly add just 1200MB.
# strace-ptest in particular needs more than 500MB
IMAGE_OVERHEAD_FACTOR = "1.0"
-IMAGE_ROOTFS_EXTRA_SPACE = "1324288"
+IMAGE_ROOTFS_EXTRA_SPACE = "1224288"
# ptests need more memory than standard to avoid the OOM killer
QB_MEM = "-m 1024"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mesa: Convert recipe to use meson build system
From: Fabio Berton
- Remove all non related meson patches
- Change radeon driver to r100
- Add python3-mako-native gettext-native to DEPENDS
Based on https://patchwork.openembedded.org/patch/158748/
Alex: added a patch to restore glx-tls option, which
addresses the musl runtime issue.
Signed-off-by: Fabio Berton
Signed-off-by: Alexander Kanavin
---
...0001-Simplify-wayland-scanner-lookup.patch | 44 -
...k-for-all-linux-host_os-combinations.patch | 51 +++
...on.build-make-TLS-GLX-optional-again.patch | 44 +
...-winsys-svga-drm-Include-sys-types.h.patch | 35 --
...M-version-when-using-LLVM-Git-releas.patch | 45 -
...R-for-defining-WAYLAND_PROTOCOLS_DAT.patch | 38 ---
meta/recipes-graphics/mesa/mesa.inc | 64 +--
meta/recipes-graphics/mesa/mesa_19.0.3.bb | 8 +--
8 files changed, 129 insertions(+), 200 deletions(-)
delete mode 100644
meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
create mode 100644
meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
create mode 100644
meta/recipes-graphics/mesa/files/0001-meson.build-make-TLS-GLX-optional-again.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0004-use-PKG_CHECK_VAR-for-defining-WAYLAND_PROTOCOLS_DAT.patch
diff --git
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
deleted file mode 100644
index d065e2285c6..000
---
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From e53837ad7b01364f34a533b95f4817c1795789de Mon Sep 17 00:00:00 2001
-From: Fabio Berton
-Date: Wed, 20 Feb 2019 16:17:00 -0300
-Subject: [PATCH 1/4] Simplify wayland-scanner lookup
-Organization: O.S. Systems Software LTDA.
-
-Don't use pkg-config to lookup the path of a binary that's in the path.
-
-Alternatively we'd have to prefix the path returned by pkg-config with
-PKG_CONFIG_SYSROOT_DIR.
-
-Upstream-Status: Pending
-Signed-off-by: Jussi Kukkonen
-Signed-off-by: Otavio Salvador
-Signed-off-by: Fabio Berton
- configure.ac | 7 +--
- 1 file changed, 1 insertion(+), 6 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 1ef68fe68e6..1816a4cd475 100644
a/configure.ac
-+++ b/configure.ac
-@@ -1854,16 +1854,11 @@ for plat in $platforms; do
- fi
- WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir
wayland-protocols`
-
--PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
-- WAYLAND_SCANNER=`$PKG_CONFIG
--variable=wayland_scanner wayland-scanner`,
-- WAYLAND_SCANNER='')
- PKG_CHECK_EXISTS([wayland-scanner >= 1.15],
- AC_SUBST(SCANNER_ARG, 'private-code'),
- AC_SUBST(SCANNER_ARG, 'code'))
-
--if test "x$WAYLAND_SCANNER" = x; then
--AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
--fi
-+AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
-
- if test "x$WAYLAND_SCANNER" = "x:"; then
- AC_MSG_ERROR([wayland-scanner is needed to compile the
wayland platform])
---
-2.21.0
-
diff --git
a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
new file mode 100644
index 000..61e24c6e9fa
--- /dev/null
+++
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
@@ -0,0 +1,51 @@
+From 498f230c9446fc7a1b4dc77ff6b84ee1a3b53bf4 Mon Sep 17 00:00:00 2001
+From: Fabio Berton
+Date: Wed, 24 Apr 2019 17:01:24 -0300
+Subject: [PATCH] meson.build: check for all linux host_os combinations
+Organization: O.S. Systems Software LTDA.
+
+Make sure that we are also looking for our host_os combinations like
+linux-musl etc. when assuming support for DRM/KMS.
+
+Also delete a duplicate line.
+
+Signed-off-by: Anuj Mittal
+Signed-off-by: Fabio Berton
+---
+ meson.build | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index 53d02e31097..c41f6b4e402 100644
+--- a/meson.build
b/meson.build
+@@ -34,6 +34,8 @@ cpp = meson.get_compiler('cpp')
+
+ null_dep = dependency('', required : false)
+
++system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd',
'dragonfly'].contains(host_machine.system()) or
host_machine.system().startswith('linux')
++
+ # Arguments for the preprocessor, put these in a separate array from the C and
+ # C++ (cpp in
Re: [OE-core] [PATCH v2] wic/bootimg-efi: replace hardcoded volume name with label
On Mon, May 13, 2019 at 12:07:09PM +0800, chee.yang@intel.com wrote: > From: Chee Yang Lee > > volume name should refer to --label in .wks. > Replace the hardcoded volume name with label. > set "ESP" as default name when no lable specified. > > Signed-off-by: Chee Yang Lee Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] add wic based image installer
On Wed, May 08, 2019 at 02:40:58PM +0800, chee.yang@intel.com wrote: > From: Chee Yang Lee > > Existing installable image (hddimg/ISO) has limit of 4GB size, so to build > larger installable image, we can build it in wic based image. > > 2 partition needed for installable image > - first partition build using source plugin bootimg-efi and configure to run > install > - second partition build with root.img, systemd-boot and kernel to be > install on target machine (this partition build using new source plugin > installer-partition) > > These patches: > - add new source plugin for second partition > - add new .wks > - add new wic dependency and set default value for required variable > - allow source plugin bootimg-efi to configure to install > > > To build the image, set WKS_FILE="wic-installer.wks.in" in local.conf. I'm confused as to why we need most of these changes to support the end goal. The enhancement to bootimg-efi makes conceptual sense. I don't see why we need a new plugin to do the rest, however. What's being done here that we don't already do today? I say this having made installer images for EFI machines using wic (in sumo, even). Thanks! -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] autotools.bbclass: output failed config.log
On 5/15/19 10:01 PM, richard.pur...@linuxfoundation.org wrote: On Wed, 2019-05-15 at 21:32 +0800, Hongxu Jia wrote: If do_configure failed, output content of config.log to configure log, it is helpful to trace the do_configure failure on the build system which is hard to login. (such as autobuilder) Add a knob OUTPUT_CONFIG_LOG to control config.log output Signed-off-by: Hongxu Jia --- meta/classes/autotools.bbclass | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) We did used to do this, it was removed: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/autotools.bbclass?id=ba837f10555998a8677eb99bfc6698e0cc1f7942 OK, I got it //Hongxu Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On Wed, May 15, 2019 at 09:50:35PM +0800, Hongxu Jia wrote: > > After applying my fix, here is the sample > > ... > > checking for i586-wrs-linux-gcc... i586-wrs-linux-gcc -m32 -march=i586 > --sysroot=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/recipe-sysroot > checking whether the C compiler works... no > configure: error: in > `/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build': > configure: error: C compiler cannot create executables > See `config.log' for more details > NOTE: The following config.log files may provide further information. > NOTE: > /buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build/config.log > NOTE: This file contains any messages produced by compilers while > NOTE: running configure, to aid debugging if configure makes a mistake. > > ... > > The content of config.log has prefix `NOTE:' and also tells user >... The problem is that the last > 1000 lines are NOTE: - and they all get dumped to the terminal. It is a problem when you have to scroll up through more than a thousand lines of mostly irrelvant information before you are seeing the most relevant information. > //Hongxu 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] autotools.bbclass: output failed config.log
On Wed, 2019-05-15 at 21:32 +0800, Hongxu Jia wrote: > If do_configure failed, output content of config.log > to configure log, it is helpful to trace the do_configure > failure on the build system which is hard to login. > (such as autobuilder) > > Add a knob OUTPUT_CONFIG_LOG to control config.log output > > Signed-off-by: Hongxu Jia > --- > meta/classes/autotools.bbclass | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > We did used to do this, it was removed: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/autotools.bbclass?id=ba837f10555998a8677eb99bfc6698e0cc1f7942 Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On 5/15/19 9:50 PM, Hongxu Jia wrote: The best available option might be to have a knob with default off, and autobuilders might be configured to dump config.log. See my V2 for detail //Hongxu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On 5/15/19 9:42 PM, Adrian Bunk wrote:
On Wed, May 15, 2019 at 08:30:03PM +0800, Hongxu Jia wrote:
On 5/15/19 7:08 PM, Adrian Bunk wrote:
The end of config.log often contains expected error messages completely
unrelated to the actual problem.
I am afraid you did not suffer pain from it, the most related message
with do_configure failure is config.log. Take a example, as my previous
commit [grub/grub-efi: fix unrecognized command line option
'-pipe-Wno-error' in CFLAGS]
It takes me hours to reproduce grub/grub-efi build faiure (only
...
I fully understand your pain, and have already suffered it many times.
Debian autobuilders already dump config.log when when configuring failed,
and there it is a common problem that people end up searching for the
problem in the wrong places due to that.
It's another story, it is better that autobuilder provide sufficient and
necessary info and data, not only config.log, but also local.conf,
all available log.do_***, sources in ${B} and ${S}, even data in ${WORKDIR},
result of `bitbake -e'
but before we got there, the fix is best choice for do_configure failure
There is no universal best choice here.
Let me give you an example when building a more recent ofono locally
with and without your patch.
When a configure task fails, the last lines from log.do_configure
are dumped to the shell.
Without your patch I get when building in a shell:
...
| checking whether to build shared libraries... yes
| checking whether to build static libraries... no
| checking for signalfd... yes
| checking for dlopen in -ldl... yes
| checking for glib-2.0 >= 2.32... yes
| checking for dbus-1 >= 1.4... yes
| checking for libudev >= 143... yes
| checking for mobile-broadband-provider-info... yes
| checking for ell >= 0.12... no
| configure: error: Embedded Linux library >= 0.12 is required
...
The problem is immediately visible.
With your patch, one has to scroll up through the whole config.log for
getting this information.
And the config.log contains plenty of other (expected) errors a user
might mistake as cause of the problem.
For autobuilders dumping config.log can be OK if there is no better
option available, but people looking at autobuilder logs should be
aware what to scroll over when starting to look at the log.
For anyone building manually in a shell these should really not be done,
it has a high potential of confuding the user and the config.log is
easily available.
The best available option might be to have a knob with default off,
and autobuilders might be configured to dump config.log.
After applying my fix, here is the sample
...
checking for i586-wrs-linux-gcc... i586-wrs-linux-gcc -m32 -march=i586
--sysroot=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/recipe-sysroot
checking whether the C compiler works... no
configure: error: in
`/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build':
configure: error: C compiler cannot create executables
See `config.log' for more details
NOTE: The following config.log files may provide further information.
NOTE:
/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build/config.log
NOTE: This file contains any messages produced by compilers while
NOTE: running configure, to aid debugging if configure makes a mistake.
...
The content of config.log has prefix `NOTE:' and also tells user
See `config.log' for more dettails and balabala
//Hongxu
//Hongxu
cu
Adrian
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On Wed, May 15, 2019 at 08:30:03PM +0800, Hongxu Jia wrote:
> On 5/15/19 7:08 PM, Adrian Bunk wrote:
> > The end of config.log often contains expected error messages completely
> > unrelated to the actual problem.
>
> I am afraid you did not suffer pain from it, the most related message
>
> with do_configure failure is config.log. Take a example, as my previous
>
> commit [grub/grub-efi: fix unrecognized command line option
>
> '-pipe-Wno-error' in CFLAGS]
>
> It takes me hours to reproduce grub/grub-efi build faiure (only
>...
I fully understand your pain, and have already suffered it many times.
> > Debian autobuilders already dump config.log when when configuring failed,
> > and there it is a common problem that people end up searching for the
> > problem in the wrong places due to that.
>
> It's another story, it is better that autobuilder provide sufficient and
>
> necessary info and data, not only config.log, but also local.conf,
>
> all available log.do_***, sources in ${B} and ${S}, even data in ${WORKDIR},
>
> result of `bitbake -e'
>
> but before we got there, the fix is best choice for do_configure failure
There is no universal best choice here.
Let me give you an example when building a more recent ofono locally
with and without your patch.
When a configure task fails, the last lines from log.do_configure
are dumped to the shell.
Without your patch I get when building in a shell:
...
| checking whether to build shared libraries... yes
| checking whether to build static libraries... no
| checking for signalfd... yes
| checking for dlopen in -ldl... yes
| checking for glib-2.0 >= 2.32... yes
| checking for dbus-1 >= 1.4... yes
| checking for libudev >= 143... yes
| checking for mobile-broadband-provider-info... yes
| checking for ell >= 0.12... no
| configure: error: Embedded Linux library >= 0.12 is required
...
The problem is immediately visible.
With your patch, one has to scroll up through the whole config.log for
getting this information.
And the config.log contains plenty of other (expected) errors a user
might mistake as cause of the problem.
For autobuilders dumping config.log can be OK if there is no better
option available, but people looking at autobuilder logs should be
aware what to scroll over when starting to look at the log.
For anyone building manually in a shell these should really not be done,
it has a high potential of confuding the user and the config.log is
easily available.
The best available option might be to have a knob with default off,
and autobuilders might be configured to dump config.log.
> //Hongxu
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] autotools.bbclass: output failed config.log
If do_configure failed, output content of config.log
to configure log, it is helpful to trace the do_configure
failure on the build system which is hard to login.
(such as autobuilder)
Add a knob OUTPUT_CONFIG_LOG to control config.log output
Signed-off-by: Hongxu Jia
---
meta/classes/autotools.bbclass | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 8768a6a..5fc9d0a 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -82,6 +82,7 @@ CONFIGURE_SCRIPT ?= "${AUTOTOOLS_SCRIPT_PATH}/configure"
AUTOTOOLS_AUXDIR ?= "${AUTOTOOLS_SCRIPT_PATH}"
+OUTPUT_CONFIG_LOG ??= ""
oe_runconf () {
# Use relative path to avoid buildpaths in files
cfgscript_name="`basename ${CONFIGURE_SCRIPT}`"
@@ -90,7 +91,11 @@ oe_runconf () {
bbnote "Running $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
if ! ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS}
${EXTRA_OECONF} "$@"; then
bbnote "The following config.log files may provide
further information."
- bbnote `find ${B} -ignore_readdir_race -type f -name
config.log`
+ config_log="`find ${B} -ignore_readdir_race -type f
-name config.log`"
+ bbnote "$config_log"
+ [ -n "${OUTPUT_CONFIG_LOG}" ] && [ -e "$config_log" ]
&& while read line; do
+ bbnote "$line"
+ done <"$config_log"
bbfatal_log "configure failed"
fi
else
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] grub-mkconfig: Use -c instead of --printf for stat
On 14.05.2019 00:51, Burton, Ross wrote:
This isn't OE-specific, can you try and send that upstream so we don't
carry the patch forever?
Also needs rebasing to current master.
Hi,
I have sent the patch upstream:
http://lists.gnu.org/archive/html/grub-devel/2019-05/msg00079.html
And I rebased to the current master.
Thanks,
Ovidiu
Ross
On Wed, 17 Apr 2019 at 03:52, Ovidiu Panait wrote:
"--printf" only works with the stat variant provided by coreutils.
With busybox, when running grub-mkconfig, stat will fail with the
following error:
stat: unrecognized option '--printf=%T'
Usage: stat [OPTIONS] FILE...
Signed-off-by: Ovidiu Panait
---
...fig-Use-c-instead-of-printf-for-stat.patch | 36 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 37 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
diff --git
a/meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
b/meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
new file mode 100644
index 00..0700911b78
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
@@ -0,0 +1,36 @@
+From b5011ea2bc57d80b3e5a42bc308fa2000e85eab1 Mon Sep 17 00:00:00 2001
+From: Ovidiu Panait
+Date: Wed, 17 Apr 2019 12:10:28 +0300
+Subject: [PATCH] grub-mkconfig: Use -c instead of --printf for stat
+
+"--printf" only works with the stat variant provided by coreutils.
+
+With busybox, when running grub-mkconfig, stat will fail with the
+following error:
+stat: unrecognized option '--printf=%T'
+
+Usage: stat [OPTIONS] FILE...
+
+Upstream-Status: Inappropriate [OE specific]
+
+Signed-off-by: Ovidiu Panait
+---
+ util/grub-mkconfig.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
+index f8496d2..628706d 100644
+--- a/util/grub-mkconfig.in
b/util/grub-mkconfig.in
+@@ -144,7 +144,7 @@ GRUB_DEVICE_BOOT_UUID="`${grub_probe} --device
${GRUB_DEVICE_BOOT} --target=fs_u
+ GRUB_FS="`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2> /dev/null || echo
unknown`"
+
+ if [ x"$GRUB_FS" = xunknown ]; then
+-GRUB_FS="$(stat -f --printf=%T / || echo unknown)"
++GRUB_FS="$(stat -f -c %T / || echo unknown)"
+ fi
+
+ if test -f ${sysconfdir}/default/grub ; then
+--
+2.20.1
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index c6994723f9..a6909c31ca 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -23,6 +23,7 @@ SRC_URI = "https://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://0001-grub-setup-Debug-message-cleanup.patch \
file://disable-address-of-packed-member.patch \
file://fix.build.with.squashfs.patch \
+ file://0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch \
"
SRC_URI[md5sum] = "1116d1f60c840e6dbd67abbc99acb45d"
SRC_URI[sha256sum] =
"660ee136fbcee08858516ed4de2ad87068bfe1b6b8b37896ce3529ff054a726d"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] grub-mkconfig: Use -c instead of --printf for stat
"--printf" only works with the stat variant provided by coreutils.
With busybox, when running grub-mkconfig, stat will fail with the
following error:
stat: unrecognized option '--printf=%T'
Usage: stat [OPTIONS] FILE...
Signed-off-by: Ovidiu Panait
---
...fig-Use-c-instead-of-printf-for-stat.patch | 36 +++
meta/recipes-bsp/grub/grub2.inc | 1 +
2 files changed, 37 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
diff --git
a/meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
b/meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
new file mode 100644
index 00..9acddb73c8
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch
@@ -0,0 +1,36 @@
+From b5011ea2bc57d80b3e5a42bc308fa2000e85eab1 Mon Sep 17 00:00:00 2001
+From: Ovidiu Panait
+Date: Wed, 17 Apr 2019 12:10:28 +0300
+Subject: [PATCH] grub-mkconfig: Use -c instead of --printf for stat
+
+"--printf" only works with the stat variant provided by coreutils.
+
+With busybox, when running grub-mkconfig, stat will fail with the
+following error:
+stat: unrecognized option '--printf=%T'
+
+Usage: stat [OPTIONS] FILE...
+
+Upstream-Status: Submitted
[http://lists.gnu.org/archive/html/grub-devel/2019-05/msg00079.html]
+
+Signed-off-by: Ovidiu Panait
+---
+ util/grub-mkconfig.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
+index f8496d2..628706d 100644
+--- a/util/grub-mkconfig.in
b/util/grub-mkconfig.in
+@@ -144,7 +144,7 @@ GRUB_DEVICE_BOOT_UUID="`${grub_probe} --device
${GRUB_DEVICE_BOOT} --target=fs_u
+ GRUB_FS="`${grub_probe} --device ${GRUB_DEVICE} --target=fs 2> /dev/null ||
echo unknown`"
+
+ if [ x"$GRUB_FS" = xunknown ]; then
+-GRUB_FS="$(stat -f --printf=%T / || echo unknown)"
++GRUB_FS="$(stat -f -c %T / || echo unknown)"
+ fi
+
+ if test -f ${sysconfdir}/default/grub ; then
+--
+2.20.1
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index 7d8c280b3f..7eb9e9c491 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -20,6 +20,7 @@ SRC_URI = "https://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://gcc8.patch \
file://0001-x86-64-Treat-R_X86_64_PLT32-as-R_X86_64_PC32.patch \
file://0001-grub-setup-Debug-message-cleanup.patch \
+ file://0001-grub-mkconfig-Use-c-instead-of-printf-for-stat.patch \
"
SRC_URI[md5sum] = "1116d1f60c840e6dbd67abbc99acb45d"
SRC_URI[sha256sum] =
"660ee136fbcee08858516ed4de2ad87068bfe1b6b8b37896ce3529ff054a726d"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On 5/15/19 7:08 PM, Adrian Bunk wrote:
The end of config.log often contains expected error messages completely
unrelated to the actual problem.
I am afraid you did not suffer pain from it, the most related message
with do_configure failure is config.log. Take a example, as my previous
commit [grub/grub-efi: fix unrecognized command line option
'-pipe-Wno-error' in CFLAGS]
It takes me hours to reproduce grub/grub-efi build faiure (only
happen while DEBUG_BUILD = "1"), and from log.do_configure, I can't
tell the root cause
...
checking for i586-wrs-linux-gcc... i586-wrs-linux-gcc -m32 -march=i586
--sysroot=TOPDIR/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/recipe-sysroot
checking whether the C compiler works... no
configure: error: in
`TOPDIR/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build':
configure: error: C compiler cannot create executables
...
But from config.log, I got more detail '-pipe-Wno-error'
which helps me to locate the issue
...
configure:5094: i586-wrs-linux-gcc -m32 -march=i586
--sysroot=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/recipe-sysroot
-Og -g -feliminate-unused-debug-types
-fmacro-prefix-map=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0=/usr/src/debug/grub/2.02-r0
-fdebug-prefix-map=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0=/usr/src/debug/grub/2.02-r0
-fdebug-prefix-map=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/recipe-sysroot=
-fdebug-prefix-map=/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/recipe-sysroot-native=
-pipe-Wno-error -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-fstack-protector-strong -Wl,-z,relro,-z,now conftest.c >&5
i586-wrs-linux-gcc: error: unrecognized command line option
'-pipe-Wno-error'; did you mean '-Wno-error'?
...
configure:5141: error: in
`/buildarea1/hjia/wrlinux-1019/build_master-wr_qemux86_2019051509/build/tmp-glibc/work/i586-wrs-linux/grub/2.02-r0/build':
configure:5143: error: C compiler cannot create executables
...
Debian autobuilders already dump config.log when when configuring failed,
and there it is a common problem that people end up searching for the
problem in the wrong places due to that.
It's another story, it is better that autobuilder provide sufficient and
necessary info and data, not only config.log, but also local.conf,
all available log.do_***, sources in ${B} and ${S}, even data in ${WORKDIR},
result of `bitbake -e'
but before we got there, the fix is best choice for do_configure failure
//Hongxu
i
//Hongxu
If possible, it would therefore be better to make it accessible separately.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On 5/15/19 6:54 PM, Andreas Müller wrote:
On Wed, May 15, 2019 at 11:50 AM Hongxu Jia wrote:
On 5/15/19 5:32 PM, Andreas Müller wrote:
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -90,7 +90,11 @@ oe_runconf () {
bbnote "Running $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
if ! ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF}
"$@"; then
bbnote "The following config.log files may provide further
information."
- bbnote `find ${B} -ignore_readdir_race -type f -name
config.log`
+ config_log="`find ${B} -ignore_readdir_race -type f -name
config.log`"
+ bbnote "$config_log"
+ [ -e "$config_log" ] && cat "$config_log" | while read
line; do
+ bbnote "$line"
+ done
bbfatal_log "configure failed"
fi
else
--
2.7.4
That output is useful only sometimes and extremly verbose. I'd suggest
to introduce a switch to enable/disable (even as newbie user I am able
to find config.log). How about making autobuilder's WORKDIR
accessible?
The output only happens while do_configure failure, it does nothing when build
succeed,
while failure occurs, I believe related message is the more the better.
The autobuilder is just an example, for community development, it is hard to
login
others build host to debug issue, and we have to take time to reproduce it
if we could trace it with a simple glance from the log, why not
Errors are common at recipe creation. I am asking for a knob to
prevent me from scrolling through endless wallpapers (confg.logs can
be >> 100K) to find simple errors.
I think a knob does make sense, I will add it in V2
//Hongxu
And it just works around an autobuilder hiding useful information,
My 2ct
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On Wed, May 15, 2019 at 05:50:44PM +0800, Hongxu Jia wrote:
> On 5/15/19 5:32 PM, Andreas Müller wrote:
> > > --- a/meta/classes/autotools.bbclass
> > > +++ b/meta/classes/autotools.bbclass
> > > @@ -90,7 +90,11 @@ oe_runconf () {
> > > bbnote "Running $cfgscript ${CONFIGUREOPTS}
> > > ${EXTRA_OECONF} $@"
> > > if ! ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS}
> > > ${EXTRA_OECONF} "$@"; then
> > > bbnote "The following config.log files may
> > > provide further information."
> > > - bbnote `find ${B} -ignore_readdir_race -type f
> > > -name config.log`
> > > + config_log="`find ${B} -ignore_readdir_race -type
> > > f -name config.log`"
> > > + bbnote "$config_log"
> > > + [ -e "$config_log" ] && cat "$config_log" | while
> > > read line; do
> > > + bbnote "$line"
> > > + done
> > > bbfatal_log "configure failed"
> > > fi
> > > else
> > > --
> > > 2.7.4
> > >
> > That output is useful only sometimes and extremly verbose. I'd suggest
> > to introduce a switch to enable/disable (even as newbie user I am able
> > to find config.log). How about making autobuilder's WORKDIR
> > accessible?
>
> The output only happens while do_configure failure, it does nothing when
> build succeed,
>
> while failure occurs, I believe related message is the more the better.
>
> The autobuilder is just an example, for community development, it is hard to
> login
>
> others build host to debug issue, and we have to take time to reproduce it
>
> if we could trace it with a simple glance from the log, why not
The end of config.log often contains expected error messages completely
unrelated to the actual problem.
Debian autobuilders already dump config.log when when configuring failed,
and there it is a common problem that people end up searching for the
problem in the wrong places due to that.
If possible, it would therefore be better to make it accessible separately.
> //Hongxu
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
Hi,
On Wed, May 15, 2019 at 12:53:44PM +0200, Martin Jansa wrote:
> Can we restore meta/files/common-licenses/Elfutils-Exception in oe-core to
> be used by meta-gplv2 version:
>
> recipes-devtools/elfutils/elfutils_0.148.bb:LICENSE = "(GPL-2+ &
> Elfutils-Exception)"
> causing:
> do_rootfs: The license listed Elfutils-Exception was not in the licenses
> collected for recipe elfutils
>
> or should I send patch for meta-gplv2 to restore it there together with
> another LICENSE_PATH += "${LAYERDIR}/licenses"?
I would do the latter and add the license to meta-gplv2.
-Mikko
> On Thu, Apr 11, 2019 at 6:01 PM Mikko Rapeli wrote:
>
> > Elfutils-Exception no longer exists after upstream release 0.154
> > and commit:
> >
> > commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2
> > Author: Mark Wielaard
> > Date: Tue Jun 5 17:15:16 2012 +0200
> >
> > NEWS file in the sources says this about switch from GPLv2 to
> > GPLv3 license:
> >
> >
> > https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
> >
> > 362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
> > stand-alone
> > 363 programs. There is now also a formal CONTRIBUTING document describing
> > how to
> > 364 submit patches.
> >
> > libasm, libdw and libelf are thus covered optionally by GPLv2 license.
> >
> > See also Debian copyright summary for elfutils:
> >
> > https://tracker.debian.org/media/packages/e/elfutils/copyright-0.176-1
> >
> > Signed-off-by: Mikko Rapeli
> > ---
> > meta/conf/licenses.conf | 2 +-
> > meta/files/common-licenses/Elfutils-Exception| 12
> > meta/recipes-devtools/elfutils/elfutils_0.176.bb | 14 +-
> > 3 files changed, 14 insertions(+), 14 deletions(-)
> > delete mode 100644 meta/files/common-licenses/Elfutils-Exception
> >
> > v1:
> > http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281124.html
> >
> > v2:
> > http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281127.html
> > * removed Elfutils-Exception
> >
> > v3:
> > http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281137.html
> > * rebase to latest master branch with elfutils 0.176
> >
> > v4:
> > * fixed typo in comment; GPLv3+ -> LGPLv3+
> > * update commit message Debian copyright URL to same 0.176 version
> >
> > diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
> > index 1058084..7b01c57 100644
> > --- a/meta/conf/licenses.conf
> > +++ b/meta/conf/licenses.conf
> > @@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0
> > CC-BY-SA-2.5 CC-BY-SA-3.0
> > SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B
> > CECILL-C"
> > SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
> > SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0
> > EFL-2.0"
> > -SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0
> > ErlPL-1.1"
> > +SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
> > SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair
> > Frameworx-1.0"
> > SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
> > SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"
> > diff --git a/meta/files/common-licenses/Elfutils-Exception
> > b/meta/files/common-licenses/Elfutils-Exception
> > deleted file mode 100644
> > index 627d769..000
> > --- a/meta/files/common-licenses/Elfutils-Exception
> > +++ /dev/null
> > @@ -1,12 +0,0 @@
> > - This file describes the limits of the Exception under which you are
> > allowed
> > - to distribute Non-GPL Code in linked combination with Red Hat elfutils.
> > - For the full text of the license, please see one of the header files
> > - included with the source distribution or the file COPYING found in the
> > - top level directory of the source.
> > -
> > - The Approved Interfaces are the functions declared in the files:
> > -
> > - libelf.h
> > - libdw.h
> > - libdwfl.h
> > -
> > diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> > b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> > index fd901c9..4602544 100644
> > --- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> > +++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> > @@ -1,7 +1,7 @@
> > SUMMARY = "Utilities and libraries for handling compiled object files"
> > HOMEPAGE = "https://sourceware.org/elfutils;
> > SECTION = "base"
> > -LICENSE = "(GPLv3 & Elfutils-Exception)"
> > +LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"
> > LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> > DEPENDS = "libtool bzip2 zlib virtual/libintl"
> > DEPENDS_append_libc-musl = " argp-standalone fts "
> > @@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
> >
> > # Package utilities separately
> > PACKAGES =+ "${PN}-binutils libelf libasm libdw"
> > +
> > +# shared libraries are licensed
Re: [OE-core] [PATCH] elfutils: remove Elfutils-Exception and include GPLv2 for shared libraries
Can we restore meta/files/common-licenses/Elfutils-Exception in oe-core to
be used by meta-gplv2 version:
recipes-devtools/elfutils/elfutils_0.148.bb:LICENSE = "(GPL-2+ &
Elfutils-Exception)"
causing:
do_rootfs: The license listed Elfutils-Exception was not in the licenses
collected for recipe elfutils
or should I send patch for meta-gplv2 to restore it there together with
another LICENSE_PATH += "${LAYERDIR}/licenses"?
On Thu, Apr 11, 2019 at 6:01 PM Mikko Rapeli wrote:
> Elfutils-Exception no longer exists after upstream release 0.154
> and commit:
>
> commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2
> Author: Mark Wielaard
> Date: Tue Jun 5 17:15:16 2012 +0200
>
> NEWS file in the sources says this about switch from GPLv2 to
> GPLv3 license:
>
>
> https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
>
> 362 The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
> stand-alone
> 363 programs. There is now also a formal CONTRIBUTING document describing
> how to
> 364 submit patches.
>
> libasm, libdw and libelf are thus covered optionally by GPLv2 license.
>
> See also Debian copyright summary for elfutils:
>
> https://tracker.debian.org/media/packages/e/elfutils/copyright-0.176-1
>
> Signed-off-by: Mikko Rapeli
> ---
> meta/conf/licenses.conf | 2 +-
> meta/files/common-licenses/Elfutils-Exception| 12
> meta/recipes-devtools/elfutils/elfutils_0.176.bb | 14 +-
> 3 files changed, 14 insertions(+), 14 deletions(-)
> delete mode 100644 meta/files/common-licenses/Elfutils-Exception
>
> v1:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281124.html
>
> v2:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281127.html
> * removed Elfutils-Exception
>
> v3:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-April/281137.html
> * rebase to latest master branch with elfutils 0.176
>
> v4:
> * fixed typo in comment; GPLv3+ -> LGPLv3+
> * update commit message Debian copyright URL to same 0.176 version
>
> diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
> index 1058084..7b01c57 100644
> --- a/meta/conf/licenses.conf
> +++ b/meta/conf/licenses.conf
> @@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0
> CC-BY-SA-2.5 CC-BY-SA-3.0
> SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B
> CECILL-C"
> SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
> SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0
> EFL-2.0"
> -SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0
> ErlPL-1.1"
> +SRC_DISTRIBUTE_LICENSES += "Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
> SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair
> Frameworx-1.0"
> SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
> SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"
> diff --git a/meta/files/common-licenses/Elfutils-Exception
> b/meta/files/common-licenses/Elfutils-Exception
> deleted file mode 100644
> index 627d769..000
> --- a/meta/files/common-licenses/Elfutils-Exception
> +++ /dev/null
> @@ -1,12 +0,0 @@
> - This file describes the limits of the Exception under which you are
> allowed
> - to distribute Non-GPL Code in linked combination with Red Hat elfutils.
> - For the full text of the license, please see one of the header files
> - included with the source distribution or the file COPYING found in the
> - top level directory of the source.
> -
> - The Approved Interfaces are the functions declared in the files:
> -
> - libelf.h
> - libdw.h
> - libdwfl.h
> -
> diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> index fd901c9..4602544 100644
> --- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> +++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
> @@ -1,7 +1,7 @@
> SUMMARY = "Utilities and libraries for handling compiled object files"
> HOMEPAGE = "https://sourceware.org/elfutils;
> SECTION = "base"
> -LICENSE = "(GPLv3 & Elfutils-Exception)"
> +LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> DEPENDS = "libtool bzip2 zlib virtual/libintl"
> DEPENDS_append_libc-musl = " argp-standalone fts "
> @@ -53,6 +53,18 @@ BBCLASSEXTEND = "native nativesdk"
>
> # Package utilities separately
> PACKAGES =+ "${PN}-binutils libelf libasm libdw"
> +
> +# shared libraries are licensed GPLv2 or LGPLv3+, binaries GPLv3+
> +# according to NEWS file:
> +# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for
> stand-alone
> +# programs. There is now also a formal CONTRIBUTING document describing
> how to
> +# submit patches."
> +LICENSE_${PN}-binutils = "GPLv3+"
> +LICENSE_${PN} = "GPLv3+"
> +LICENSE_libelf = "GPLv2 | LGPLv3+"
>
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On Wed, May 15, 2019 at 11:50 AM Hongxu Jia wrote:
>
> On 5/15/19 5:32 PM, Andreas Müller wrote:
>
> --- a/meta/classes/autotools.bbclass
> +++ b/meta/classes/autotools.bbclass
> @@ -90,7 +90,11 @@ oe_runconf () {
> bbnote "Running $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF}
> $@"
> if ! ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS}
> ${EXTRA_OECONF} "$@"; then
> bbnote "The following config.log files may provide
> further information."
> - bbnote `find ${B} -ignore_readdir_race -type f -name
> config.log`
> + config_log="`find ${B} -ignore_readdir_race -type f
> -name config.log`"
> + bbnote "$config_log"
> + [ -e "$config_log" ] && cat "$config_log" | while
> read line; do
> + bbnote "$line"
> + done
> bbfatal_log "configure failed"
> fi
> else
> --
> 2.7.4
>
> That output is useful only sometimes and extremly verbose. I'd suggest
> to introduce a switch to enable/disable (even as newbie user I am able
> to find config.log). How about making autobuilder's WORKDIR
> accessible?
>
> The output only happens while do_configure failure, it does nothing when
> build succeed,
>
> while failure occurs, I believe related message is the more the better.
>
> The autobuilder is just an example, for community development, it is hard to
> login
>
> others build host to debug issue, and we have to take time to reproduce it
>
> if we could trace it with a simple glance from the log, why not
>
Errors are common at recipe creation. I am asking for a knob to
prevent me from scrolling through endless wallpapers (confg.logs can
be >> 100K) to find simple errors.
And it just works around an autobuilder hiding useful information,
My 2ct
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [ v2] mesa: Add backport of freedreno dmabuf modifiers patch.
This is required to get weston-simple-dmabuf-drm to work
and also now required by Chromium v73 ozone-wayland backend.
It is present in mesa 19.0, backporting to Thud which is
on 18.1.9.
Signed-off-by: Peter Griffin
---
...-freedreno-add-query-for-dmabuf-modifiers.patch | 101 +
meta/recipes-graphics/mesa/mesa_18.1.9.bb | 1 +
2 files changed, 102 insertions(+)
create mode 100644
meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
diff --git
a/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
new file mode 100644
index 000..57ebd8f
--- /dev/null
+++
b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
@@ -0,0 +1,101 @@
+From c4bee1a1b3fb224002fe8c263bedbce1b705ed49 Mon Sep 17 00:00:00 2001
+From: Peter Griffin
+Date: Mon, 13 May 2019 19:18:56 +0100
+Subject: [PATCH] freedreno: add query for dmabuf modifiers
+
+Backport of mesa 7c4b9510d by Fritz Koenig. Tested with Weston
+and weston-simple-dmabuf-drm client.
+
+Upstream-Status: Backport from 19.0
+
+Signed-off-by: Peter Griffin
+---
+ src/gallium/drivers/freedreno/freedreno_screen.c | 43
+ src/gallium/drivers/freedreno/freedreno_screen.h | 3 ++
+ 2 files changed, 46 insertions(+)
+
+diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
+index f338d75..cbb5b8a 100644
+--- a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
+@@ -40,6 +40,7 @@
+
+ #include "util/os_time.h"
+
++#include
+ #include
+ #include
+ #include
+@@ -732,6 +733,37 @@ fd_screen_bo_get_handle(struct pipe_screen *pscreen,
+ }
+ }
+
++static void
++fd_screen_query_dmabuf_modifiers(struct pipe_screen *pscreen,
++ enum pipe_format format,
++ int max, uint64_t *modifiers,
++ unsigned int *external_only,
++ int *count)
++{
++ struct fd_screen *screen = fd_screen(pscreen);
++ int i, num = 0;
++
++ max = MIN2(max, screen->num_supported_modifiers);
++
++ if (!max) {
++ max = screen->num_supported_modifiers;
++ external_only = NULL;
++ modifiers = NULL;
++ }
++
++ for (i = 0; i < max; i++) {
++ if (modifiers)
++ modifiers[num] = screen->supported_modifiers[i];
++
++ if (external_only)
++ external_only[num] = 0;
++
++ num++;
++ }
++
++ *count = num;
++}
++
+ struct fd_bo *
+ fd_screen_bo_from_handle(struct pipe_screen *pscreen,
+ struct winsys_handle *whandle)
+@@ -921,6 +953,17 @@ fd_screen_create(struct fd_device *dev)
+ pscreen->fence_finish = fd_fence_finish;
+ pscreen->fence_get_fd = fd_fence_get_fd;
+
++ pscreen->query_dmabuf_modifiers = fd_screen_query_dmabuf_modifiers;
++
++ if (!screen->supported_modifiers) {
++ static const uint64_t supported_modifiers[] = {
++ DRM_FORMAT_MOD_LINEAR,
++ };
++
++ screen->supported_modifiers = supported_modifiers;
++ screen->num_supported_modifiers =
ARRAY_SIZE(supported_modifiers);
++ }
++
+ slab_create_parent(>transfer_pool, sizeof(struct fd_transfer),
16);
+
+ return pscreen;
+diff --git a/src/gallium/drivers/freedreno/freedreno_screen.h
b/src/gallium/drivers/freedreno/freedreno_screen.h
+index 6be739a..5558066 100644
+--- a/src/gallium/drivers/freedreno/freedreno_screen.h
b/src/gallium/drivers/freedreno/freedreno_screen.h
+@@ -89,6 +89,9 @@ struct fd_screen {
+ struct fd_batch_cache batch_cache;
+
+ bool reorder;
++
++ unsigned num_supported_modifiers;
++ const uint64_t *supported_modifiers;
+ };
+
+ static inline struct fd_screen *
+--
+2.7.4
+
diff --git a/meta/recipes-graphics/mesa/mesa_18.1.9.bb
b/meta/recipes-graphics/mesa/mesa_18.1.9.bb
index 86d6a6b..0558690 100644
--- a/meta/recipes-graphics/mesa/mesa_18.1.9.bb
+++ b/meta/recipes-graphics/mesa/mesa_18.1.9.bb
@@ -7,6 +7,7 @@ SRC_URI =
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0004-Use-Python-3-to-execute-the-scripts.patch \
file://0005-dri-i965-Add-missing-time.h-include.patch \
file://0006-use-PKG_CHECK_VAR-for-defining-WAYLAND_PROTOCOLS_DAT.patch \
+ file://0001-freedreno-add-query-for-dmabuf-modifiers.patch \
"
SRC_URI[md5sum] = "2f8d2098ab478bc3907e42130577b54a"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On 5/15/19 5:32 PM, Andreas Müller wrote:
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -90,7 +90,11 @@ oe_runconf () {
bbnote "Running $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
if ! ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF}
"$@"; then
bbnote "The following config.log files may provide further
information."
- bbnote `find ${B} -ignore_readdir_race -type f -name
config.log`
+ config_log="`find ${B} -ignore_readdir_race -type f -name
config.log`"
+ bbnote "$config_log"
+ [ -e "$config_log" ] && cat "$config_log" | while read
line; do
+ bbnote "$line"
+ done
bbfatal_log "configure failed"
fi
else
--
2.7.4
That output is useful only sometimes and extremly verbose. I'd suggest
to introduce a switch to enable/disable (even as newbie user I am able
to find config.log). How about making autobuilder's WORKDIR
accessible?
The output only happens while do_configure failure, it does nothing when
build succeed,
while failure occurs, I believe related message is the more the better.
The autobuilder is just an example, for community development, it is
hard to login
others build host to debug issue, and we have to take time to reproduce it
if we could trace it with a simple glance from the log, why not
//Hongxu
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] autotools.bbclass: output failed config.log
On Wed, May 15, 2019 at 11:23 AM Hongxu Jia wrote:
>
> If do_configure failed, output content of config.log
> to configure log, it is helpful to trace the do_configure
> failure on the build system which is hard to login.
> (such as autobuilder)
>
> Signed-off-by: Hongxu Jia
> ---
> meta/classes/autotools.bbclass | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
> index 8768a6a..03cbe1b 100644
> --- a/meta/classes/autotools.bbclass
> +++ b/meta/classes/autotools.bbclass
> @@ -90,7 +90,11 @@ oe_runconf () {
> bbnote "Running $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF}
> $@"
> if ! ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS}
> ${EXTRA_OECONF} "$@"; then
> bbnote "The following config.log files may provide
> further information."
> - bbnote `find ${B} -ignore_readdir_race -type f -name
> config.log`
> + config_log="`find ${B} -ignore_readdir_race -type f
> -name config.log`"
> + bbnote "$config_log"
> + [ -e "$config_log" ] && cat "$config_log" | while
> read line; do
> + bbnote "$line"
> + done
> bbfatal_log "configure failed"
> fi
> else
> --
> 2.7.4
>
That output is useful only sometimes and extremly verbose. I'd suggest
to introduce a switch to enable/disable (even as newbie user I am able
to find config.log). How about making autobuilder's WORKDIR
accessible?
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: Add backport of freedreno dmabuf modifiers patch.
Email subject should include [thud], otherwise it won't be noticed.
Alex
On Wed, 15 May 2019 at 11:07, Peter Griffin wrote:
>
> This is required to get weston-simple-dmabuf-drm to work
> and also now required by Chromium v73 ozone-wayland backend.
>
> It is present in mesa 19.0, backporting to Thud which is
> on 18.1.9.
>
> Signed-off-by: Peter Griffin
> ---
> ...ckport-of-freedreno-dmabuf-modifiers-patc.patch | 140
> +
> ...-freedreno-add-query-for-dmabuf-modifiers.patch | 101 +++
> meta/recipes-graphics/mesa/mesa_18.1.9.bb | 1 +
> 3 files changed, 242 insertions(+)
> create mode 100644
> meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
> create mode 100644
> meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
>
> diff --git
> a/meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
>
> b/meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
> new file mode 100644
> index 000..1a5aa68
> --- /dev/null
> +++
> b/meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
> @@ -0,0 +1,140 @@
> +From 6de2fe7bdd1bbe7a1d56c91fabe32a3dbcb736ac Mon Sep 17 00:00:00 2001
> +From: Peter Griffin
> +Date: Wed, 15 May 2019 10:07:49 +0200
> +Subject: [PATCH] mesa: Add backport of freedreno dmabuf modifiers patch.
> +
> +This is required to get weston-simple-dmabuf-drm to work
> +and also now required by Chromium v73 ozone-wayland backend.
> +
> +It is present in mesa 19.0, backporting to Thud which is
> +on 18.1.9.
> +
> +Signed-off-by: Peter Griffin
> +---
> + ...-freedreno-add-query-for-dmabuf-modifiers.patch | 101
> +
> + meta/recipes-graphics/mesa/mesa_18.1.9.bb | 1 +
> + 2 files changed, 102 insertions(+)
> + create mode 100644
> meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
> +
> +diff --git
> a/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
>
> b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
> +new file mode 100644
> +index 000..57ebd8f
> +--- /dev/null
>
> b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
> +@@ -0,0 +1,101 @@
> ++From c4bee1a1b3fb224002fe8c263bedbce1b705ed49 Mon Sep 17 00:00:00 2001
> ++From: Peter Griffin
> ++Date: Mon, 13 May 2019 19:18:56 +0100
> ++Subject: [PATCH] freedreno: add query for dmabuf modifiers
> ++
> ++Backport of mesa 7c4b9510d by Fritz Koenig. Tested with Weston
> ++and weston-simple-dmabuf-drm client.
> ++
> ++Upstream-Status: Backport from 19.0
> ++
> ++Signed-off-by: Peter Griffin
> ++---
> ++ src/gallium/drivers/freedreno/freedreno_screen.c | 43
>
> ++ src/gallium/drivers/freedreno/freedreno_screen.h | 3 ++
> ++ 2 files changed, 46 insertions(+)
> ++
> ++diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> ++index f338d75..cbb5b8a 100644
> ++--- a/src/gallium/drivers/freedreno/freedreno_screen.c
> + b/src/gallium/drivers/freedreno/freedreno_screen.c
> ++@@ -40,6 +40,7 @@
> ++
> ++ #include "util/os_time.h"
> ++
> +++#include
> ++ #include
> ++ #include
> ++ #include
> ++@@ -732,6 +733,37 @@ fd_screen_bo_get_handle(struct pipe_screen *pscreen,
> ++ }
> ++ }
> ++
> +++static void
> +++fd_screen_query_dmabuf_modifiers(struct pipe_screen *pscreen,
> +++ enum pipe_format format,
> +++ int max, uint64_t *modifiers,
> +++ unsigned int *external_only,
> +++ int *count)
> +++{
> +++ struct fd_screen *screen = fd_screen(pscreen);
> +++ int i, num = 0;
> +++
> +++ max = MIN2(max, screen->num_supported_modifiers);
> +++
> +++ if (!max) {
> +++ max = screen->num_supported_modifiers;
> +++ external_only = NULL;
> +++ modifiers = NULL;
> +++ }
> +++
> +++ for (i = 0; i < max; i++) {
> +++ if (modifiers)
> +++ modifiers[num] = screen->supported_modifiers[i];
> +++
> +++ if (external_only)
> +++ external_only[num] = 0;
> +++
> +++ num++;
> +++ }
> +++
> +++ *count = num;
> +++}
> +++
> ++ struct fd_bo *
> ++ fd_screen_bo_from_handle(struct pipe_screen *pscreen,
> ++ struct winsys_handle *whandle)
> ++@@ -921,6 +953,17 @@ fd_screen_create(struct fd_device *dev)
> ++ pscreen->fence_finish = fd_fence_finish;
> ++ pscreen->fence_get_fd = fd_fence_get_fd;
> ++
> +++ pscreen->query_dmabuf_modifiers = fd_screen_query_dmabuf_modifiers;
> +++
> +++ if (!screen->supported_modifiers) {
> +++ static const uint64_t supported_modifiers[] = {
> +++ DRM_FORMAT_MOD_LINEAR,
> +++ };
> +++
> +++
[OE-core] [PATCH] autotools.bbclass: output failed config.log
If do_configure failed, output content of config.log
to configure log, it is helpful to trace the do_configure
failure on the build system which is hard to login.
(such as autobuilder)
Signed-off-by: Hongxu Jia
---
meta/classes/autotools.bbclass | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 8768a6a..03cbe1b 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -90,7 +90,11 @@ oe_runconf () {
bbnote "Running $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
if ! ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS}
${EXTRA_OECONF} "$@"; then
bbnote "The following config.log files may provide
further information."
- bbnote `find ${B} -ignore_readdir_race -type f -name
config.log`
+ config_log="`find ${B} -ignore_readdir_race -type f
-name config.log`"
+ bbnote "$config_log"
+ [ -e "$config_log" ] && cat "$config_log" | while read
line; do
+ bbnote "$line"
+ done
bbfatal_log "configure failed"
fi
else
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake.bbclass: pass mandatory compiler flags through CMAKE__COMPILER_ARG1
Hi Pascal,
I very often saw in proprietary projects the following code
> set(CMAKE_C_FLAGS "list of flags that developer want to add")
where package developer overwrite default CMAKE_C_FLAGS or CMAKE_CXX_FLAGS
variables.
There are several examples from github:
https://github.com/psi4/psi4archive/blob/1.0.x/cmake/compilers/CFlags.cmake
https://github.com/eloraiby/dna-cross-platform/blob/master/src/DNA/native/CMakeLists.txt
https://github.com/JWZepf/bfsdk/blob/master/cmake/CMakeFlags_Native_GCC.txt
https://github.com/redcurrant/metacd-http/blob/master/CMakeLists.txt
https://github.com/HabanaAI/hl-thunk/blob/master/CMakeLists.txt
https://github.com/chrisz/librain/blob/master/CMakeLists.txt
https://github.com/chrishoen/Dev_RisLibLx/blob/master/CMakeLists.txt
https://github.com/Farigh/yasc/blob/master/config/GccCompileOptions.cmake
I suggest my changes in order to reduce risk of failure with such CMake
projects.
In same time suggested changes will logically tie this flags to the compiler in
same manner as it tied in the CC and CXX variables.
Regards,
Nikolai
- Original Message -
From: "Bach, Pascal"
To: "n merinov" ,
openembedded-core@lists.openembedded.org
Sent: Tuesday, May 14, 2019 8:49:57 PM
Subject: RE: [OE-core] [PATCH] cmake.bbclass: pass mandatory compiler flags
through CMAKE__COMPILER_ARG1
Hi Nikolai,
I think this would work. However I would like to understand the problem you are
trying to solve with this.
Do you have an example of a recipe this would be needed?
Pascal
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> On Behalf Of
> Nikolai Merinov
> Sent: Dienstag, 14. Mai 2019 17:04
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] cmake.bbclass: pass mandatory compiler flags
> through CMAKE__COMPILER_ARG1
>
> The CMake takes mandatory compiler arguments from the following
> variables:
> - CMAKE_SYSROOT -- path to sysroot that should be passed to compiler.
> - CMAKE__COMPILER_TARGET -- target architecture, used for
> compilers
> that supports several targets through command line options.
> e.g. "clang --target ${CMAKE_C_COMPILER_TARGET}".
> - CMAKE__COMPILER_EXTERNAL_TOOLCHAIN -- path to external
> toolchain,
> used for compilers that support build with external toolchain.
> e.g. "clang --gcc-toolchain
> ${CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN}".
> - CMAKE__COMPILER_ARG1 -- other mandatory arguments to a
> compiler
> command.
>
> CMAKE__COMPILER_ARG1 is the most suitable variable to pass
> mandatory arguments, that belongs to CC variable with other build systems,
> to a compiler.
>
> Additionally usage of CMAKE__COMPILER_ARG1 instead of
> CMAKE__FLAGS reduce the risk that a variable can be overrided by
> CMakeLists.txt files.
> ---
> meta/classes/cmake.bbclass | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass index
> d3f0d70847..4da4c00a09 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -27,27 +27,33 @@ python() {
> cc_list = d.getVar('CC').split()
> if cc_list[0] == 'ccache':
> d.setVar('OECMAKE_C_COMPILER', '%s %s' % (cc_list[0],
> cc_list[1]))
> +cc_arg1 = ' '.join(cc_list[2:])
> else:
> d.setVar('OECMAKE_C_COMPILER', cc_list[0])
> +cc_arg1 = ' '.join(cc_list[1:])
> +if not d.getVar('OECMAKE_C_COMPILER_ARG1'):
> +d.setVar('OECMAKE_C_COMPILER_ARG1', cc_arg1)
>
> if not d.getVar('OECMAKE_CXX_COMPILER'):
> cxx_list = d.getVar('CXX').split()
> if cxx_list[0] == 'ccache':
> d.setVar('OECMAKE_CXX_COMPILER', '%s %s' % (cxx_list[0],
> cxx_list[1]))
> +cxx_arg1 = ' '.join(cxx_list[2:])
> else:
> d.setVar('OECMAKE_CXX_COMPILER', cxx_list[0])
> +cxx_arg1 = ' '.join(cxx_list[1:])
> +if not d.getVar('OECMAKE_CXX_COMPILER_ARG1'):
> +d.setVar('OECMAKE_CXX_COMPILER_ARG1', cxx_arg1)
> }
> OECMAKE_AR ?= "${AR}"
>
> # Compiler flags
> -OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${CFLAGS}"
> -OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${CXXFLAGS}"
> +OECMAKE_C_FLAGS ?= "${CFLAGS}"
> +OECMAKE_CXX_FLAGS ?= "${CXXFLAGS}"
> OECMAKE_C_FLAGS_RELEASE ?= "-DNDEBUG"
> OECMAKE_CXX_FLAGS_RELEASE ?= "-DNDEBUG"
> -OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${CPPFLAGS} ${LDFLAGS}"
> -OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH}
> ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} ${LDFLAGS}"
> -CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
> -CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
> +OECMAKE_C_LINK_FLAGS ?= "${CPPFLAGS} ${LDFLAGS}"
> +OECMAKE_CXX_LINK_FLAGS ?= "${CXXFLAGS} ${LDFLAGS}"
>
> OECMAKE_RPATH ?= ""
> OECMAKE_PERLNATIVE_DIR ??= ""
> @@ -85,8 +91,11 @@ $cmake_crosscompiling set( CMAKE_SYSTEM_NAME
> `echo ${TARGET_OS} | sed
[OE-core] [PATCH v2] mesa: Add backport of freedreno dmabuf modifiers patch.
This is required to get weston-simple-dmabuf-drm to work
and also now required by Chromium v73 ozone-wayland backend.
It is present in mesa 19.0, backporting to Thud which is
on 18.1.9.
Signed-off-by: Peter Griffin
---
...-freedreno-add-query-for-dmabuf-modifiers.patch | 101 +
meta/recipes-graphics/mesa/mesa_18.1.9.bb | 1 +
2 files changed, 102 insertions(+)
create mode 100644
meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
diff --git
a/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
new file mode 100644
index 000..57ebd8f
--- /dev/null
+++
b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
@@ -0,0 +1,101 @@
+From c4bee1a1b3fb224002fe8c263bedbce1b705ed49 Mon Sep 17 00:00:00 2001
+From: Peter Griffin
+Date: Mon, 13 May 2019 19:18:56 +0100
+Subject: [PATCH] freedreno: add query for dmabuf modifiers
+
+Backport of mesa 7c4b9510d by Fritz Koenig. Tested with Weston
+and weston-simple-dmabuf-drm client.
+
+Upstream-Status: Backport from 19.0
+
+Signed-off-by: Peter Griffin
+---
+ src/gallium/drivers/freedreno/freedreno_screen.c | 43
+ src/gallium/drivers/freedreno/freedreno_screen.h | 3 ++
+ 2 files changed, 46 insertions(+)
+
+diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
+index f338d75..cbb5b8a 100644
+--- a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
+@@ -40,6 +40,7 @@
+
+ #include "util/os_time.h"
+
++#include
+ #include
+ #include
+ #include
+@@ -732,6 +733,37 @@ fd_screen_bo_get_handle(struct pipe_screen *pscreen,
+ }
+ }
+
++static void
++fd_screen_query_dmabuf_modifiers(struct pipe_screen *pscreen,
++ enum pipe_format format,
++ int max, uint64_t *modifiers,
++ unsigned int *external_only,
++ int *count)
++{
++ struct fd_screen *screen = fd_screen(pscreen);
++ int i, num = 0;
++
++ max = MIN2(max, screen->num_supported_modifiers);
++
++ if (!max) {
++ max = screen->num_supported_modifiers;
++ external_only = NULL;
++ modifiers = NULL;
++ }
++
++ for (i = 0; i < max; i++) {
++ if (modifiers)
++ modifiers[num] = screen->supported_modifiers[i];
++
++ if (external_only)
++ external_only[num] = 0;
++
++ num++;
++ }
++
++ *count = num;
++}
++
+ struct fd_bo *
+ fd_screen_bo_from_handle(struct pipe_screen *pscreen,
+ struct winsys_handle *whandle)
+@@ -921,6 +953,17 @@ fd_screen_create(struct fd_device *dev)
+ pscreen->fence_finish = fd_fence_finish;
+ pscreen->fence_get_fd = fd_fence_get_fd;
+
++ pscreen->query_dmabuf_modifiers = fd_screen_query_dmabuf_modifiers;
++
++ if (!screen->supported_modifiers) {
++ static const uint64_t supported_modifiers[] = {
++ DRM_FORMAT_MOD_LINEAR,
++ };
++
++ screen->supported_modifiers = supported_modifiers;
++ screen->num_supported_modifiers =
ARRAY_SIZE(supported_modifiers);
++ }
++
+ slab_create_parent(>transfer_pool, sizeof(struct fd_transfer),
16);
+
+ return pscreen;
+diff --git a/src/gallium/drivers/freedreno/freedreno_screen.h
b/src/gallium/drivers/freedreno/freedreno_screen.h
+index 6be739a..5558066 100644
+--- a/src/gallium/drivers/freedreno/freedreno_screen.h
b/src/gallium/drivers/freedreno/freedreno_screen.h
+@@ -89,6 +89,9 @@ struct fd_screen {
+ struct fd_batch_cache batch_cache;
+
+ bool reorder;
++
++ unsigned num_supported_modifiers;
++ const uint64_t *supported_modifiers;
+ };
+
+ static inline struct fd_screen *
+--
+2.7.4
+
diff --git a/meta/recipes-graphics/mesa/mesa_18.1.9.bb
b/meta/recipes-graphics/mesa/mesa_18.1.9.bb
index 86d6a6b..0558690 100644
--- a/meta/recipes-graphics/mesa/mesa_18.1.9.bb
+++ b/meta/recipes-graphics/mesa/mesa_18.1.9.bb
@@ -7,6 +7,7 @@ SRC_URI =
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0004-Use-Python-3-to-execute-the-scripts.patch \
file://0005-dri-i965-Add-missing-time.h-include.patch \
file://0006-use-PKG_CHECK_VAR-for-defining-WAYLAND_PROTOCOLS_DAT.patch \
+ file://0001-freedreno-add-query-for-dmabuf-modifiers.patch \
"
SRC_URI[md5sum] = "2f8d2098ab478bc3907e42130577b54a"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mesa: Add backport of freedreno dmabuf modifiers patch.
This is required to get weston-simple-dmabuf-drm to work
and also now required by Chromium v73 ozone-wayland backend.
It is present in mesa 19.0, backporting to Thud which is
on 18.1.9.
Signed-off-by: Peter Griffin
---
...ckport-of-freedreno-dmabuf-modifiers-patc.patch | 140 +
...-freedreno-add-query-for-dmabuf-modifiers.patch | 101 +++
meta/recipes-graphics/mesa/mesa_18.1.9.bb | 1 +
3 files changed, 242 insertions(+)
create mode 100644
meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
create mode 100644
meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
diff --git
a/meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
b/meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
new file mode 100644
index 000..1a5aa68
--- /dev/null
+++
b/meta/recipes-graphics/mesa/0001-mesa-Add-backport-of-freedreno-dmabuf-modifiers-patc.patch
@@ -0,0 +1,140 @@
+From 6de2fe7bdd1bbe7a1d56c91fabe32a3dbcb736ac Mon Sep 17 00:00:00 2001
+From: Peter Griffin
+Date: Wed, 15 May 2019 10:07:49 +0200
+Subject: [PATCH] mesa: Add backport of freedreno dmabuf modifiers patch.
+
+This is required to get weston-simple-dmabuf-drm to work
+and also now required by Chromium v73 ozone-wayland backend.
+
+It is present in mesa 19.0, backporting to Thud which is
+on 18.1.9.
+
+Signed-off-by: Peter Griffin
+---
+ ...-freedreno-add-query-for-dmabuf-modifiers.patch | 101 +
+ meta/recipes-graphics/mesa/mesa_18.1.9.bb | 1 +
+ 2 files changed, 102 insertions(+)
+ create mode 100644
meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
+
+diff --git
a/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
+new file mode 100644
+index 000..57ebd8f
+--- /dev/null
b/meta/recipes-graphics/mesa/files/0001-freedreno-add-query-for-dmabuf-modifiers.patch
+@@ -0,0 +1,101 @@
++From c4bee1a1b3fb224002fe8c263bedbce1b705ed49 Mon Sep 17 00:00:00 2001
++From: Peter Griffin
++Date: Mon, 13 May 2019 19:18:56 +0100
++Subject: [PATCH] freedreno: add query for dmabuf modifiers
++
++Backport of mesa 7c4b9510d by Fritz Koenig. Tested with Weston
++and weston-simple-dmabuf-drm client.
++
++Upstream-Status: Backport from 19.0
++
++Signed-off-by: Peter Griffin
++---
++ src/gallium/drivers/freedreno/freedreno_screen.c | 43
++ src/gallium/drivers/freedreno/freedreno_screen.h | 3 ++
++ 2 files changed, 46 insertions(+)
++
++diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
++index f338d75..cbb5b8a 100644
++--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+ b/src/gallium/drivers/freedreno/freedreno_screen.c
++@@ -40,6 +40,7 @@
++
++ #include "util/os_time.h"
++
+++#include
++ #include
++ #include
++ #include
++@@ -732,6 +733,37 @@ fd_screen_bo_get_handle(struct pipe_screen *pscreen,
++ }
++ }
++
+++static void
+++fd_screen_query_dmabuf_modifiers(struct pipe_screen *pscreen,
+++ enum pipe_format format,
+++ int max, uint64_t *modifiers,
+++ unsigned int *external_only,
+++ int *count)
+++{
+++ struct fd_screen *screen = fd_screen(pscreen);
+++ int i, num = 0;
+++
+++ max = MIN2(max, screen->num_supported_modifiers);
+++
+++ if (!max) {
+++ max = screen->num_supported_modifiers;
+++ external_only = NULL;
+++ modifiers = NULL;
+++ }
+++
+++ for (i = 0; i < max; i++) {
+++ if (modifiers)
+++ modifiers[num] = screen->supported_modifiers[i];
+++
+++ if (external_only)
+++ external_only[num] = 0;
+++
+++ num++;
+++ }
+++
+++ *count = num;
+++}
+++
++ struct fd_bo *
++ fd_screen_bo_from_handle(struct pipe_screen *pscreen,
++ struct winsys_handle *whandle)
++@@ -921,6 +953,17 @@ fd_screen_create(struct fd_device *dev)
++ pscreen->fence_finish = fd_fence_finish;
++ pscreen->fence_get_fd = fd_fence_get_fd;
++
+++ pscreen->query_dmabuf_modifiers = fd_screen_query_dmabuf_modifiers;
+++
+++ if (!screen->supported_modifiers) {
+++ static const uint64_t supported_modifiers[] = {
+++ DRM_FORMAT_MOD_LINEAR,
+++ };
+++
+++ screen->supported_modifiers = supported_modifiers;
+++ screen->num_supported_modifiers =
ARRAY_SIZE(supported_modifiers);
+++ }
+++
++ slab_create_parent(>transfer_pool, sizeof(struct fd_transfer),
16);
++
++ return pscreen;
++diff --git a/src/gallium/drivers/freedreno/freedreno_screen.h
b/src/gallium/drivers/freedreno/freedreno_screen.h
++index 6be739a..5558066
Re: [OE-core] RDEPENDS kernel-image-zimage & kernel.bbclass PKG name
Hi Bruce,
On Tue, 2019-05-14 at 20:50 -0400, Bruce Ashfield wrote:
>
>
> On Tue, May 14, 2019 at 12:32 PM André Draszik wrote:
> > On Tue, 2019-05-14 at 14:35 +0100, André Draszik wrote:
> > > Hi,
> > >
> > > As part of the build, kernel packages are renamed, e.g.
> > > kernel-image-zimage basically becomes
> > > kernel-image-zimage-${KERNEL_VERSION}
> > >
> > > When a package created by recipe B RDEPENDS on kernel-image-zimage,
> > > the ipk generated ultimately depends on
> > > kernel-image-zimage-${KERNEL_VERSION} (not kernel-image-zimage).
> > > Once the kernel is updated, it appears as though recipe B is not
> > > repackaged, so the package still runtime depends on the original
> > > kernel, which doesn't exist anymore, and thus building the image
> > > fails.
> > >
> > > Specifically, I have
> > > MACHINE_EXTRA_RDEPENDS += "kernel-image-zimage"
> > > in my BSP, and hence packagegroup-machine-base runtime depends on
> > > kernel-image-zimage-4.9.11-cl-som-imx7-5.1+gc27010d99a3d.
> > > Updating the kernel doesn't trigger a rebuild of
> > > packagegroup-machine-base,
> > > so things fail for me.
> > >
> > >
> > > Am I missing something in my BSP? I could probably do a bbappend
> > > on packagegroup-base.bb and add something like
> > > do_packagedata[depends] += "virtual/kernel:do_packagedata"
> >
> > BTW, I've tried the following packagegroup-base.bbappend to no avail:
> >
> > python do_get_kernel_zimage_name() {
> > new_dep = get_package_mapping('kernel-image-zimage',
> > 'packagegroup-machine-base', d)
> > d.appendVarFlag('do_package_write_ipk', 'vardeps', new_dep)
> > }
> > addtask get_kernel_zimage_name after do_package before do_package_write_ipk
> > do_get_kernel_zimage_name[depends] += "virtual/kernel:do_packagedata"
> >
>
>
> Hi Andre,
>
> I chased (And fixed) something very similar to this with postinst scripts and
> kernel-image that showed a similar
> symptom (you couldn't add a postinst to kernel-image- without throwing
> an error since the PKG_ variables change
> the package name to kernel-image--version).
>
> My fix was specific to the postinst, but I bet this would be a similar fix.
>
> I don't suppose you have a sample set of layers and a build config that I
> could kick off here ? That would make it a
> lot easier to test my theory.
Thanks for the offer Bruce, I'll try. Shouldn't be too hard I hope.
A.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS kernel-image-zimage & kernel.bbclass PKG name
On Tue, 2019-05-14 at 17:32 +0100, André Draszik wrote:
> On Tue, 2019-05-14 at 14:35 +0100, André Draszik wrote:
> > Hi,
> >
> > As part of the build, kernel packages are renamed, e.g.
> > kernel-image-zimage basically becomes
> > kernel-image-zimage-${KERNEL_VERSION}
> >
> > When a package created by recipe B RDEPENDS on kernel-image-zimage,
> > the ipk generated ultimately depends on
> > kernel-image-zimage-${KERNEL_VERSION} (not kernel-image-zimage).
> > Once the kernel is updated, it appears as though recipe B is not
> > repackaged, so the package still runtime depends on the original
> > kernel, which doesn't exist anymore, and thus building the image
> > fails.
> >
> > Specifically, I have
> > MACHINE_EXTRA_RDEPENDS += "kernel-image-zimage"
> > in my BSP, and hence packagegroup-machine-base runtime depends on
> > kernel-image-zimage-4.9.11-cl-som-imx7-5.1+gc27010d99a3d.
> > Updating the kernel doesn't trigger a rebuild of packagegroup-machine-base,
> > so things fail for me.
> >
> >
> > Am I missing something in my BSP? I could probably do a bbappend
> > on packagegroup-base.bb and add something like
> > do_packagedata[depends] += "virtual/kernel:do_packagedata"
>
> BTW, I've tried the following packagegroup-base.bbappend to no avail:
>
> python do_get_kernel_zimage_name() {
> new_dep = get_package_mapping('kernel-image-zimage',
> 'packagegroup-machine-base', d)
> d.appendVarFlag('do_package_write_ipk', 'vardeps', new_dep)
> }
> addtask get_kernel_zimage_name after do_package before do_package_write_ipk
> do_get_kernel_zimage_name[depends] += "virtual/kernel:do_packagedata"
The above snippet was wrong, I meant to post this snippet:
KERNEL_ZIMAGE_PKG_NAME = ""
do_package_write_ipk[vardeps] += "KERNEL_ZIMAGE_PKG_NAME"
python do_get_kernel_zimage_name() {
new_dep = get_package_mapping('kernel-image-zimage',
'packagegroup-machine-base', d)
bb.warn ('new dep is %s' % new_dep)
d.setVar('KERNEL_ZIMAGE_PKG_NAME', new_dep)
}
addtask get_kernel_zimage_name after do_package before do_package_write_ipk
do_get_kernel_zimage_name[depends] += "virtual/kernel:do_package_write_ipk"
(still with the same behaviour)
A.
>
>
> I suspect adding the varflag happens too late in this case, as the package
> still isn't rebuilt on kernel updates.
>
> > This doesn't seem right, though.
>
> A.
>
> >
> > Any ideas or thoughts?
> >
> >
> > Cheers,
> > Andre'
> >
> >
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] ptest: Add RDEPENDS frpm PN-ptest to PN package
On Tue, May 14, 2019 at 10:56:04PM +0100, Richard Purdie wrote:
> Many different ptests are breaking as they assume that ${PN}-ptest
> depends on ${PN}. It doesn't currently but should. If we fix this, many
> different ptests start passing when they previously failed.
>
> It does depend on fixing an issue in the dbus-test recipe which is done
> in the preceeding patch (mentioned in case this gets backported).
Awesome! Thanks for this. In our case we build many packages and their
ptests but they may not be installed to images by default. Thus this helps.
Same also applies to our SDK. We build more stuff for the SDK than what is
installed by default.
Reviewed-by: Mikko Rapeli
> Signed-off-by: Richard Purdie
> ---
> meta/classes/ptest.bbclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
> index 936bf82736e..fa4c36ec769 100644
> --- a/meta/classes/ptest.bbclass
> +++ b/meta/classes/ptest.bbclass
> @@ -13,6 +13,7 @@ PTEST_ENABLED = "${@bb.utils.contains('DISTRO_FEATURES',
> 'ptest', '1', '0', d)}"
> PTEST_ENABLED_class-native = ""
> PTEST_ENABLED_class-nativesdk = ""
> PTEST_ENABLED_class-cross-canadian = ""
> +RDEPENDS_${PN}-ptest += "${PN}"
> RDEPENDS_${PN}-ptest_class-native = ""
> RDEPENDS_${PN}-ptest_class-nativesdk = ""
> RRECOMMENDS_${PN}-ptest += "ptest-runner"
> --
> 2.20.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [V3][Oe-core][PATCH] sysstat: Add PACKAGECONFIG[cron] for '--enable-install-cron' option
Hi,
On 15/05/2019 08.42, Haiqing Bai wrote:
If 'cron' is added into PACKAGECONFIG, for sysvinit, the related
cron scripts will be installed; for systemd, the services of
data collect and summary will be installed.
Signed-off-by: Haiqing Bai
---
meta/recipes-extended/sysstat/sysstat.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/sysstat/sysstat.inc
b/meta/recipes-extended/sysstat/sysstat.inc
index 0bc7e14d36..79555e6cf3 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -19,6 +19,7 @@ inherit autotools-brokensep gettext systemd
PACKAGECONFIG ??= ""
PACKAGECONFIG[lm-sensors] =
"--enable-sensors,--disable-sensors,lmsensors,lmsensors-libsensors"
+PACKAGECONFIG[cron] = "--enable-install-cron
--enable-copy-only,--disable-install-cron --disable-copy-only"
EXTRA_OECONF += "--disable-stripping"
@@ -59,7 +60,6 @@ pkg_postinst_${PN} () {
fi
}
-
-FILES_${PN} += "${libdir}/sa"
+FILES_${PN} += "${libdir}/sa ${systemd_unitdir}/system/*"
You can use "${systemd_system_unitdir}" instead of
"${systemd_unitdir}/system/". And also no need to append the asterisk.
// Martin
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [V3][Oe-core][PATCH] sysstat: Add PACKAGECONFIG[cron] for '--enable-install-cron' option
If 'cron' is added into PACKAGECONFIG, for sysvinit, the related
cron scripts will be installed; for systemd, the services of
data collect and summary will be installed.
Signed-off-by: Haiqing Bai
---
meta/recipes-extended/sysstat/sysstat.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/sysstat/sysstat.inc
b/meta/recipes-extended/sysstat/sysstat.inc
index 0bc7e14d36..79555e6cf3 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -19,6 +19,7 @@ inherit autotools-brokensep gettext systemd
PACKAGECONFIG ??= ""
PACKAGECONFIG[lm-sensors] =
"--enable-sensors,--disable-sensors,lmsensors,lmsensors-libsensors"
+PACKAGECONFIG[cron] = "--enable-install-cron
--enable-copy-only,--disable-install-cron --disable-copy-only"
EXTRA_OECONF += "--disable-stripping"
@@ -59,7 +60,6 @@ pkg_postinst_${PN} () {
fi
}
-
-FILES_${PN} += "${libdir}/sa"
+FILES_${PN} += "${libdir}/sa ${systemd_unitdir}/system/*"
TARGET_CC_ARCH += "${LDFLAGS}"
--
2.18.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libinput:upgrade 1.13.1 -> 1.13.2
-Upgrade from libinput_1.13.1.bb to libinput_1.13.2.bb.
Signed-off-by: Zang Ruochen
---
.../wayland/{libinput_1.13.1.bb => libinput_1.13.2.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/wayland/{libinput_1.13.1.bb =>
libinput_1.13.2.bb} (86%)
diff --git a/meta/recipes-graphics/wayland/libinput_1.13.1.bb
b/meta/recipes-graphics/wayland/libinput_1.13.2.bb
similarity index 86%
rename from meta/recipes-graphics/wayland/libinput_1.13.1.bb
rename to meta/recipes-graphics/wayland/libinput_1.13.2.bb
index 5a6dd9aecb..049674c098 100644
--- a/meta/recipes-graphics/wayland/libinput_1.13.1.bb
+++ b/meta/recipes-graphics/wayland/libinput_1.13.2.bb
@@ -8,8 +8,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=1f2ea9ebff3a2c6d458faf58492efb63"
DEPENDS = "libevdev udev mtdev"
SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz;
-SRC_URI[md5sum] = "869a7e68c4290d99868500a369645def"
-SRC_URI[sha256sum] =
"e1d487d478ee2bb118890a64211c2b7f2348aaed7363b214bed4d642274841ab"
+SRC_URI[md5sum] = "8b745894f5d1b2e883bfc686aebadcfe"
+SRC_URI[sha256sum] =
"1d9fa0698348dea46f75321d98788f8ac7181c069b70c4d10736910a12bb6a6d"
UPSTREAM_CHECK_REGEX = "libinput-(?P\d+\.\d+\.(?!9\d+)\d+)"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
