[OE-core] [PATCH 0/3] Fixes regarding oeqa/sdk
The following changes since commit a8368651ffed1bd6c4715a37dfe9f40c48ca23c4: bitbake: fetcher: Fixed remote removal not throwing exception. (2018-08-28 10:32:08 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/oeqa-sdk http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/oeqa-sdk Chen Qi (3): sdk/context.py: add ability to check for multilib version of target package sdk/buldgalculator.py: check against multilib for gtk+3 oeqa/sdk: fixes related to hasPackage semantics meta/lib/oeqa/sdk/cases/buildgalculator.py | 4 ++-- meta/lib/oeqa/sdk/cases/buildlzip.py | 4 ++-- meta/lib/oeqa/sdk/cases/gcc.py | 4 ++-- meta/lib/oeqa/sdk/context.py | 29 + 4 files changed, 27 insertions(+), 14 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] oeqa/sdk: fixes related to hasPackage semantics
The current _hasPackage does a regex match when checking for the
existence of packages. This will sometimes result in unexpected
result. For example, the condition hasTargetPackage('gcc') is likely
to be always true as it matches libgcc1.
For most of the time, we should do exact match instead of regex match.
So change _hasPackage function to do that. For the current sdk test
cases, the only place that needs regex match is '^gcc-'. This is because
there's no easy way to get multilib tune arch (e.g. i686) from testdata.json
file.
Besides, packagegroup-cross-canadian-xxx and gcc-xxx should be check in
host manifest instead of the target one. So fix to use hasHostPackage.
Also, as we are doing exact match, there's no need to use r'gtk\+3',
just 'gtk+3' is enough.
Signed-off-by: Chen Qi
---
meta/lib/oeqa/sdk/cases/buildgalculator.py | 4 ++--
meta/lib/oeqa/sdk/cases/buildlzip.py | 4 ++--
meta/lib/oeqa/sdk/cases/gcc.py | 4 ++--
meta/lib/oeqa/sdk/context.py | 21 ++---
4 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/meta/lib/oeqa/sdk/cases/buildgalculator.py
b/meta/lib/oeqa/sdk/cases/buildgalculator.py
index 3714825..050d1b3 100644
--- a/meta/lib/oeqa/sdk/cases/buildgalculator.py
+++ b/meta/lib/oeqa/sdk/cases/buildgalculator.py
@@ -8,8 +8,8 @@ class GalculatorTest(OESDKTestCase):
@classmethod
def setUpClass(self):
-if not (self.tc.hasTargetPackage(r"gtk\+3", multilib=True) or\
-self.tc.hasTargetPackage(r"libgtk-3.0", multilib=True)):
+if not (self.tc.hasTargetPackage("gtk+3", multilib=True) or \
+self.tc.hasTargetPackage("libgtk-3.0", multilib=True)):
raise unittest.SkipTest("GalculatorTest class: SDK don't support
gtk+3")
if not (self.tc.hasHostPackage("nativesdk-gettext-dev")):
raise unittest.SkipTest("GalculatorTest class: SDK doesn't contain
gettext")
diff --git a/meta/lib/oeqa/sdk/cases/buildlzip.py
b/meta/lib/oeqa/sdk/cases/buildlzip.py
index 3a89ce8..b28cc3a 100644
--- a/meta/lib/oeqa/sdk/cases/buildlzip.py
+++ b/meta/lib/oeqa/sdk/cases/buildlzip.py
@@ -17,8 +17,8 @@ class BuildLzipTest(OESDKTestCase):
machine = self.td.get("MACHINE")
-if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" %
machine) or
-self.tc.hasTargetPackage("gcc")):
+if not (self.tc.hasHostPackage("packagegroup-cross-canadian-%s" %
machine) or
+self.tc.hasHostPackage("^gcc-", regex=True)):
raise unittest.SkipTest("SDK doesn't contain a cross-canadian
toolchain")
def test_lzip(self):
diff --git a/meta/lib/oeqa/sdk/cases/gcc.py b/meta/lib/oeqa/sdk/cases/gcc.py
index d11f4b6..b32b01f 100644
--- a/meta/lib/oeqa/sdk/cases/gcc.py
+++ b/meta/lib/oeqa/sdk/cases/gcc.py
@@ -18,8 +18,8 @@ class GccCompileTest(OESDKTestCase):
def setUp(self):
machine = self.td.get("MACHINE")
-if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" %
machine) or
-self.tc.hasTargetPackage("gcc")):
+if not (self.tc.hasHostPackage("packagegroup-cross-canadian-%s" %
machine) or
+self.tc.hasHostPackage("^gcc-", regex=True)):
raise unittest.SkipTest("GccCompileTest class: SDK doesn't contain
a cross-canadian toolchain")
def test_gcc_compile(self):
diff --git a/meta/lib/oeqa/sdk/context.py b/meta/lib/oeqa/sdk/context.py
index ec8972d..adc4166 100644
--- a/meta/lib/oeqa/sdk/context.py
+++ b/meta/lib/oeqa/sdk/context.py
@@ -20,23 +20,30 @@ class OESDKTestContext(OETestContext):
self.target_pkg_manifest = target_pkg_manifest
self.host_pkg_manifest = host_pkg_manifest
-def _hasPackage(self, manifest, pkg):
-for host_pkg in manifest.keys():
-if re.search(pkg, host_pkg):
+def _hasPackage(self, manifest, pkg, regex=False):
+if regex:
+# do regex match
+pat = re.compile(pkg)
+for p in manifest.keys():
+if pat.search(p):
+return True
+else:
+# do exact match
+if pkg in manifest.keys():
return True
return False
-def hasHostPackage(self, pkg):
-return self._hasPackage(self.host_pkg_manifest, pkg)
+def hasHostPackage(self, pkg, regex=False):
+return self._hasPackage(self.host_pkg_manifest, pkg, regex=regex)
-def hasTargetPackage(self, pkg, multilib=False):
+def hasTargetPackage(self, pkg, multilib=False, regex=False):
if multilib:
# match multilib according to sdk_env
mls = self.td.get('MULTILIB_VARIANTS', '').split()
for ml in mls:
if ('ml'+ml) in self.sdk_env:
pkg = ml + '-' + pkg
-return self._hasPackage(self.target_pkg_manifest, pkg)
+return self._hasPackage(self.target_pkg_manifest, pkg,
[OE-core] [PATCH 2/3] sdk/buldgalculator.py: check against multilib for gtk+3
When determining whether to skip the test case, the check should be
done with consideration of multilib. Otherwise, we will meet the
following error when testing against lib32 environment.
No package 'gtk+-3.0' found
Signed-off-by: Chen Qi
---
meta/lib/oeqa/sdk/cases/buildgalculator.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/sdk/cases/buildgalculator.py
b/meta/lib/oeqa/sdk/cases/buildgalculator.py
index 4c02ea4..3714825 100644
--- a/meta/lib/oeqa/sdk/cases/buildgalculator.py
+++ b/meta/lib/oeqa/sdk/cases/buildgalculator.py
@@ -8,8 +8,8 @@ class GalculatorTest(OESDKTestCase):
@classmethod
def setUpClass(self):
-if not (self.tc.hasTargetPackage(r"gtk\+3") or\
-self.tc.hasTargetPackage(r"libgtk-3.0")):
+if not (self.tc.hasTargetPackage(r"gtk\+3", multilib=True) or\
+self.tc.hasTargetPackage(r"libgtk-3.0", multilib=True)):
raise unittest.SkipTest("GalculatorTest class: SDK don't support
gtk+3")
if not (self.tc.hasHostPackage("nativesdk-gettext-dev")):
raise unittest.SkipTest("GalculatorTest class: SDK doesn't contain
gettext")
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] sdk/context.py: add ability to check for multilib version of target package
Add a named argument 'multilib' for the hasTargetPackage function. Its default
value is False. When setting to True, it will try to get the correct multilib
prefix from the sdk_env, the environment setup script.
We need this because we don't want unexpected run of some sdk test cases.
The following steps will generate error.
1. Enable multilib for qemux86-64
require conf/multilib.conf
MULTILIBS ?= "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "core2-32"
2. bitbake core-image-sato -c populate_sdk
3. bitbake core-image-sato -c testsdk
The error message is like below.
No package 'gtk+-3.0' found
RESULTS - buildgalculator.GalculatorTest.test_galculator - Testcase -1: FAILED
As we don't have lib32-gtk+3 installed, the test case should be skipped when
testing against the lib32 environment setup script.
Signed-off-by: Chen Qi
---
meta/lib/oeqa/sdk/context.py | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/sdk/context.py b/meta/lib/oeqa/sdk/context.py
index 7c091c0..ec8972d 100644
--- a/meta/lib/oeqa/sdk/context.py
+++ b/meta/lib/oeqa/sdk/context.py
@@ -29,7 +29,13 @@ class OESDKTestContext(OETestContext):
def hasHostPackage(self, pkg):
return self._hasPackage(self.host_pkg_manifest, pkg)
-def hasTargetPackage(self, pkg):
+def hasTargetPackage(self, pkg, multilib=False):
+if multilib:
+# match multilib according to sdk_env
+mls = self.td.get('MULTILIB_VARIANTS', '').split()
+for ml in mls:
+if ('ml'+ml) in self.sdk_env:
+pkg = ml + '-' + pkg
return self._hasPackage(self.target_pkg_manifest, pkg)
class OESDKTestContextExecutor(OETestContextExecutor):
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [rocko][PATCH] module-base.bbclass: fix out-of-tree module builds with custom EXTRA_OEMAKE
On Thu, Aug 23, 2018 at 09:15:55PM -0400, Denys Dmytriyenko wrote:
> On Wed, Aug 15, 2018 at 07:27:50PM -0700, akuster808 wrote:
> >
> >
> > On 08/15/2018 06:22 PM, Denys Dmytriyenko wrote:
> > > From: Denys Dmytriyenko
> > >
> > > Commit d2aa88a6a92985f21414fceea2dc0facbf7f8779 was meant to backport
> > > build
> > > dependencies on bc-native and openssl-native, but it also changed
> > > execution
> > > of do_make_scripts() from calling make directly to using oe_runmake. That
> > > change was made in master/sumo as part of a separate make-mod-scripts
> > > recipe.
> > >
> > > Unfortunately, that doesn't work here in rocko in the context of
> > > module-base
> > > class, as it gets executed inside out-of-tree module environment. Quite
> > > often
> > > those out-of-tree modules provide own Makefile with custom EXTRA_OEMAKE
> > > var
> > > defined. But do_make_scripts() gets executed within STAGING_KERNEL_DIR and
> > > cannot simply use custom EXTRA_OEMAKE set by a module.
> > >
> > > Move back to calling make and passing HOSTCC/HOSTCPP directly w/o using
> > > EXTRA_OEMAKE.
> >
> > Got this stagged it my rocko mut branch for testing.
>
> Ping
Ping again - are there any problems with this patch?
> > thanks
> > Armin
> > >
> > > For more details please see:
> > > http://lists.openembedded.org/pipermail/openembedded-core/2018-August/154189.html
> > >
> > > Signed-off-by: Denys Dmytriyenko
> > > Cc: Bruce Ashfield
> > > Cc: Richard Purdie
> > > Cc: Anuj Mittal
> > > Cc: Armin Kuster
> > > ---
> > > meta/classes/module-base.bbclass | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/meta/classes/module-base.bbclass
> > > b/meta/classes/module-base.bbclass
> > > index 9f3465e..c1fa3ad 100644
> > > --- a/meta/classes/module-base.bbclass
> > > +++ b/meta/classes/module-base.bbclass
> > > @@ -13,7 +13,6 @@ export CROSS_COMPILE = "${TARGET_PREFIX}"
> > > export KBUILD_OUTPUT = "${STAGING_KERNEL_BUILDDIR}"
> > >
> > > DEPENDS += "bc-native"
> > > -EXTRA_OEMAKE += " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
> > > HOSTCPP="${BUILD_CPP}""
> > >
> > > export KERNEL_VERSION =
> > > "${@base_read_file('${STAGING_KERNEL_BUILDDIR}/kernel-abiversion')}"
> > > KERNEL_OBJECT_SUFFIX = ".ko"
> > > @@ -25,6 +24,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> > > # be called before do_compile. See module.bbclass for an example.
> > > do_make_scripts() {
> > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> > > - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> > > + make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> > > +HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
> > > HOSTCPP="${BUILD_CPP}" \
> > > -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> > > scripts prepare
> > > }
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost: add ptest support
On 08/29/2018 01:22 AM, openembedded-core-boun...@lists.openembedded.org wrote: > On 08/28/2018 10:25 AM, Yang Wang wrote: >> On 08/27/2018 08:57 PM, Randy MacLeod wrote: >>> On 08/27/2018 06:17 PM, Yang Wang wrote: Not sure if it's worth to run the Ptest on QEMU though, I also run Ptest on SIMICS simulators, thousands of tests didn't get run, looks like the result was not good as well. Now my nightly Ptest runs on x86 device and gets consistent result every day: 2018-08-27T06:26 -- 2018-08-27T09:52 Passed: 40518 Failed: 289 Skipped: 1876 >>> >>> Consistent results are good and > 90% pass rate is very good. >>> What are the stats using qemux86-64 and/or simics? >>> >>> I don't expect that qemu results would be as close to real hardware >>> as Simics but it is quite good and freely available. >>> >> Actually, Ptest has 37 test suites as far as I know, different test >> suites spent different time on QEMU and hardware, here is a list of >> Ptest suites and their case number and spent time for running: >> >> > Just want to make it look better: > == > # Suite Name Case # Time to Run Case # Time to Run > qemu-x86-64 intel-xeon-core2 > 1 acl 2 1m 380 1m > 2 attr 143 1m 143 1m > 3 bash 79 8m 79 4m > 4 bluez5 7 6m 7 6m > 5 bzip2 6 1m 6 1m > 6 dbus-test 15 3m 15 1m > 7 diffutils 20 1m 20 2m > 8 e2fsprogs 147 9m 335 10m > 9 ethtool 2 1m 2 1m > 10 flex 114 3m 114 1m > 11 gawk 300 3m 298 2m > 12 gdbm 30 2m 25 2m > 13 glib-2.0 62 14m 220 6m > 14 gzip 51 4m 18 1m > 15 kbd 15 1m 7 1m > 16 libevent 22 6m 1 3m > 17 libpcre 34 3m 3 1m > 18 libxml2 1 1m 0 1m > 19 lzo 75 8m 5 3m > 20 mdadm 6m 6m > 21 nettle 90 3m 90 3m > 22 numactl 8 3m > 23 openssh 13 27m 47 52m > 24 openssl 87 47m 56 15m > 25 parted 64 5m 38 10m > 26 perl 101 20m 2440 47m > 27 perl5 110 17m 2406 29m > 28 python 10961 1h 5m 32323 20m > 29 rsyslog 2200 3h 37m 25 8m > 30 sed 147 1m 86 3m > 31 slang 96 1m > 32 strace 1557 1h 13m 431 6m > 33 systemd 305 9m 155 3m > 34 tcl 869 53m 206 6m > 35 tcpdump 451 7m 413 3m > 36 util-linux 516 25m 514 13m > 37 zlib 2 1m 2 1m > Overall 18080 10h 30m 40415 4h 15m > >> >> As you can see, running subset of them on QEMU could be a solution if >> people do not want to spend too much time on it or simulator is the >> preferred test device. Would it make sense using qemu to run the `make check` tests (when available) and together with ptests and auto upgrade bot (which is run every two weeks?), automate upgrading of recipes to some extent? If auto upgrade helper manages to use devtool to upgrade successfully, run these tests on image/qemu and if the tests pass (as compared against last good baseline which can be stored as metadata in AUH or the test result log repository), just send the upgraded recipe patch to list instead of sending to the recipe maintainer listed, reducing manual intervention to some extent and perhaps tested (to some extent), frequent and smaller upgrades ... Thanks, Anuj -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] libsdl2: Fix left rotated display for RaspPi/VC4/GLES2
The patch should increase performance for libsdl2 on GLES2 too.
Signed-off-by: Andreas Müller
---
...01-GLES2-Get-sin-cos-out-of-vertex-shader.patch | 141 +
meta/recipes-graphics/libsdl2/libsdl2_2.0.8.bb | 1 +
2 files changed, 142 insertions(+)
create mode 100644
meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
diff --git
a/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
b/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
new file mode 100644
index 00..621b7ea1a0
--- /dev/null
+++
b/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
@@ -0,0 +1,141 @@
+From c215ba1d52a3d4ef03af3ab1a5baa1863f812aed Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?=
+Date: Fri, 24 Aug 2018 23:10:25 +0200
+Subject: [PATCH] GLES2: Get sin/cos out of vertex shader
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The only place angle is activated and causes effect is RenderCopyEx. All other
+methods which use vertex shader, leave angle disabled and cause useless sin/cos
+calculation in shader.
+
+To get around shader's interface is changed to a vector that contains results
+of sin and cos. To behave properly when disabled, cos value is set with offset
+-1.0 making 0.0 default when deactivated.
+
+As nice side effect it simplifies GLES2_UpdateVertexBuffer: All attributes are
+vectors now.
+
+Additional background:
+
+* On RaspberryPi it gives a performace win for operations. Tested with
+ [1] numbers go down for 5-10% (not easy to estimate due to huge variation).
+* SDL_RenderCopyEx was tested with [2]
+* It works around left rotated display caused by low accuracy sin implemetation
+ in RaspberryPi/VC4 [3]
+
+Upstream-Status: Submitted [4]
+
+[1] https://github.com/schnitzeltony/sdl2box
+[2] https://github.com/schnitzeltony/sdl2rendercopyex
+[3] https://github.com/anholt/mesa/issues/110
+[4] https://hg.libsdl.org/SDL/rev/e5a666405750
+
+Signed-off-by: Andreas Müller
+---
+ src/render/opengles2/SDL_render_gles2.c | 17 -
+ src/render/opengles2/SDL_shaders_gles2.c | 14 +-
+ 2 files changed, 21 insertions(+), 10 deletions(-)
+
+diff --git a/src/render/opengles2/SDL_render_gles2.c
b/src/render/opengles2/SDL_render_gles2.c
+index 14671f7c8..7c54a7333 100644
+--- a/src/render/opengles2/SDL_render_gles2.c
b/src/render/opengles2/SDL_render_gles2.c
+@@ -1530,7 +1530,7 @@ GLES2_UpdateVertexBuffer(SDL_Renderer *renderer,
GLES2_Attribute attr,
+ GLES2_DriverContext *data = (GLES2_DriverContext *)renderer->driverdata;
+
+ #if !SDL_GLES2_USE_VBOS
+-data->glVertexAttribPointer(attr, attr == GLES2_ATTRIBUTE_ANGLE ? 1 : 2,
GL_FLOAT, GL_FALSE, 0, vertexData);
++data->glVertexAttribPointer(attr, 2, GL_FLOAT, GL_FALSE, 0, vertexData);
+ #else
+ if (!data->vertex_buffers[attr]) {
+ data->glGenBuffers(1, >vertex_buffers[attr]);
+@@ -1545,7 +1545,7 @@ GLES2_UpdateVertexBuffer(SDL_Renderer *renderer,
GLES2_Attribute attr,
+ data->glBufferSubData(GL_ARRAY_BUFFER, 0, dataSizeInBytes,
vertexData);
+ }
+
+-data->glVertexAttribPointer(attr, attr == GLES2_ATTRIBUTE_ANGLE ? 1 : 2,
GL_FLOAT, GL_FALSE, 0, 0);
++data->glVertexAttribPointer(attr, 2, GL_FLOAT, GL_FALSE, 0, 0);
+ #endif
+
+ return 0;
+@@ -1853,6 +1853,8 @@ GLES2_RenderCopy(SDL_Renderer *renderer, SDL_Texture
*texture, const SDL_Rect *s
+ return GL_CheckError("", renderer);
+ }
+
++#define PI 3.14159265f
++
+ static int
+ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture *texture, const
SDL_Rect *srcrect,
+ const SDL_FRect *dstrect, const double angle, const
SDL_FPoint *center, const SDL_RendererFlip flip)
+@@ -1861,8 +1863,9 @@ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture
*texture, const SDL_Rect
+ GLfloat vertices[8];
+ GLfloat texCoords[8];
+ GLfloat translate[8];
+-GLfloat fAngle[4];
++GLfloat fAngle[8];
+ GLfloat tmp;
++float radian_angle;
+
+ GLES2_ActivateRenderer(renderer);
+
+@@ -1872,7 +1875,11 @@ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture
*texture, const SDL_Rect
+
+ data->glEnableVertexAttribArray(GLES2_ATTRIBUTE_CENTER);
+ data->glEnableVertexAttribArray(GLES2_ATTRIBUTE_ANGLE);
+-fAngle[0] = fAngle[1] = fAngle[2] = fAngle[3] = (GLfloat)(360.0f - angle);
++
++radian_angle = PI * (360.0f - angle) / 180.f;
++fAngle[0] = fAngle[2] = fAngle[4] = fAngle[6] =
(GLfloat)sin(radian_angle);
++/* render expects cos value - 1 (see GLES2_VertexSrc_Default_) */
++fAngle[1] = fAngle[3] = fAngle[5] = fAngle[7] =
(GLfloat)cos(radian_angle) - 1.0f;
+ /* Calculate the center of rotation */
+ translate[0] = translate[2] = translate[4] = translate[6] = (center->x +
dstrect->x);
+ translate[1] = translate[3] = translate[5] =
[OE-core] ✗ patchtest: failure for libsdl2: Fix left rotated display for RaspberryPi/VC4
== Series Details == Series: libsdl2: Fix left rotated display for RaspberryPi/VC4 Revision: 1 URL : https://patchwork.openembedded.org/series/13787/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Upstream-Status is in incorrect format [test_upstream_status_presence_format] Suggested fixFix Upstream-Status format in 0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch Current Upstream-Status: Applied [4] Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libsdl2: Fix left rotated display for RaspberryPi/VC4
The patch should increase performance for GLES2 too.
Signed-off-by: Andreas Müller
---
...01-GLES2-Get-sin-cos-out-of-vertex-shader.patch | 141 +
meta/recipes-graphics/libsdl2/libsdl2_2.0.8.bb | 1 +
2 files changed, 142 insertions(+)
create mode 100644
meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
diff --git
a/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
b/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
new file mode 100644
index 00..621b7ea1a0
--- /dev/null
+++
b/meta/recipes-graphics/libsdl2/libsdl2/0001-GLES2-Get-sin-cos-out-of-vertex-shader.patch
@@ -0,0 +1,141 @@
+From c215ba1d52a3d4ef03af3ab1a5baa1863f812aed Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?=
+Date: Fri, 24 Aug 2018 23:10:25 +0200
+Subject: [PATCH] GLES2: Get sin/cos out of vertex shader
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The only place angle is activated and causes effect is RenderCopyEx. All other
+methods which use vertex shader, leave angle disabled and cause useless sin/cos
+calculation in shader.
+
+To get around shader's interface is changed to a vector that contains results
+of sin and cos. To behave properly when disabled, cos value is set with offset
+-1.0 making 0.0 default when deactivated.
+
+As nice side effect it simplifies GLES2_UpdateVertexBuffer: All attributes are
+vectors now.
+
+Additional background:
+
+* On RaspberryPi it gives a performace win for operations. Tested with
+ [1] numbers go down for 5-10% (not easy to estimate due to huge variation).
+* SDL_RenderCopyEx was tested with [2]
+* It works around left rotated display caused by low accuracy sin implemetation
+ in RaspberryPi/VC4 [3]
+
+Upstream-Status: Applied [4]
+
+[1] https://github.com/schnitzeltony/sdl2box
+[2] https://github.com/schnitzeltony/sdl2rendercopyex
+[3] https://github.com/anholt/mesa/issues/110
+[4] https://hg.libsdl.org/SDL/rev/e5a666405750
+
+Signed-off-by: Andreas Müller
+---
+ src/render/opengles2/SDL_render_gles2.c | 17 -
+ src/render/opengles2/SDL_shaders_gles2.c | 14 +-
+ 2 files changed, 21 insertions(+), 10 deletions(-)
+
+diff --git a/src/render/opengles2/SDL_render_gles2.c
b/src/render/opengles2/SDL_render_gles2.c
+index 14671f7c8..7c54a7333 100644
+--- a/src/render/opengles2/SDL_render_gles2.c
b/src/render/opengles2/SDL_render_gles2.c
+@@ -1530,7 +1530,7 @@ GLES2_UpdateVertexBuffer(SDL_Renderer *renderer,
GLES2_Attribute attr,
+ GLES2_DriverContext *data = (GLES2_DriverContext *)renderer->driverdata;
+
+ #if !SDL_GLES2_USE_VBOS
+-data->glVertexAttribPointer(attr, attr == GLES2_ATTRIBUTE_ANGLE ? 1 : 2,
GL_FLOAT, GL_FALSE, 0, vertexData);
++data->glVertexAttribPointer(attr, 2, GL_FLOAT, GL_FALSE, 0, vertexData);
+ #else
+ if (!data->vertex_buffers[attr]) {
+ data->glGenBuffers(1, >vertex_buffers[attr]);
+@@ -1545,7 +1545,7 @@ GLES2_UpdateVertexBuffer(SDL_Renderer *renderer,
GLES2_Attribute attr,
+ data->glBufferSubData(GL_ARRAY_BUFFER, 0, dataSizeInBytes,
vertexData);
+ }
+
+-data->glVertexAttribPointer(attr, attr == GLES2_ATTRIBUTE_ANGLE ? 1 : 2,
GL_FLOAT, GL_FALSE, 0, 0);
++data->glVertexAttribPointer(attr, 2, GL_FLOAT, GL_FALSE, 0, 0);
+ #endif
+
+ return 0;
+@@ -1853,6 +1853,8 @@ GLES2_RenderCopy(SDL_Renderer *renderer, SDL_Texture
*texture, const SDL_Rect *s
+ return GL_CheckError("", renderer);
+ }
+
++#define PI 3.14159265f
++
+ static int
+ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture *texture, const
SDL_Rect *srcrect,
+ const SDL_FRect *dstrect, const double angle, const
SDL_FPoint *center, const SDL_RendererFlip flip)
+@@ -1861,8 +1863,9 @@ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture
*texture, const SDL_Rect
+ GLfloat vertices[8];
+ GLfloat texCoords[8];
+ GLfloat translate[8];
+-GLfloat fAngle[4];
++GLfloat fAngle[8];
+ GLfloat tmp;
++float radian_angle;
+
+ GLES2_ActivateRenderer(renderer);
+
+@@ -1872,7 +1875,11 @@ GLES2_RenderCopyEx(SDL_Renderer *renderer, SDL_Texture
*texture, const SDL_Rect
+
+ data->glEnableVertexAttribArray(GLES2_ATTRIBUTE_CENTER);
+ data->glEnableVertexAttribArray(GLES2_ATTRIBUTE_ANGLE);
+-fAngle[0] = fAngle[1] = fAngle[2] = fAngle[3] = (GLfloat)(360.0f - angle);
++
++radian_angle = PI * (360.0f - angle) / 180.f;
++fAngle[0] = fAngle[2] = fAngle[4] = fAngle[6] =
(GLfloat)sin(radian_angle);
++/* render expects cos value - 1 (see GLES2_VertexSrc_Default_) */
++fAngle[1] = fAngle[3] = fAngle[5] = fAngle[7] =
(GLfloat)cos(radian_angle) - 1.0f;
+ /* Calculate the center of rotation */
+ translate[0] = translate[2] = translate[4] = translate[6] = (center->x +
dstrect->x);
+ translate[1] = translate[3] = translate[5] = translate[7] =
Re: [OE-core] [PATCH 1/5] mesa: Enable gallium-llvm on x86 and x86_64
On Tue, Aug 28, 2018 at 10:20 PM, Khem Raj wrote:
> Hi Andreas
> On Tue, Aug 28, 2018 at 11:28 AM Andreas Müller
> wrote:
>>
>> On Tue, Aug 28, 2018 at 7:36 PM, Khem Raj wrote:
>> > Hi Andreas
>> >
>> > On Tue, Aug 28, 2018 at 10:21 AM Andreas Müller
>> > wrote:
>> >>
>> >> On Tue, Aug 28, 2018 at 8:43 AM, Andreas Müller
>> >> wrote:
>> >> > On Tue, Aug 28, 2018 at 12:55 AM, Khem Raj wrote:
>> >> >> On Mon, Aug 27, 2018 at 2:15 PM Andreas Müller
>> >> >> wrote:
>> >> >>>
>> >> >>> On Mon, Aug 20, 2018 at 8:59 PM, Khem Raj wrote:
>> >> >>> > Signed-off-by: Khem Raj
>> >> >>> > ---
>> >> >>> > meta/recipes-graphics/cairo/cairo.inc | 3 ++-
>> >> >>> > meta/recipes-graphics/mesa/mesa.inc | 3 +++
>> >> >>> > 2 files changed, 5 insertions(+), 1 deletion(-)
>> >> >>> >
>> >> >>> > diff --git a/meta/recipes-graphics/cairo/cairo.inc
>> >> >>> > b/meta/recipes-graphics/cairo/cairo.inc
>> >> >>> > index 20e0d2c92a..7347f223ff 100644
>> >> >>> > --- a/meta/recipes-graphics/cairo/cairo.inc
>> >> >>> > +++ b/meta/recipes-graphics/cairo/cairo.inc
>> >> >>> > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender
>> >> >>> > libxext"
>> >> >>> > DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>> >> >>> >
>> >> >>> > PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
>> >> >>> > 'x11 xcb', '', d)} \
>> >> >>> > - ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
>> >> >>> > + ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
>> >> >>> > + ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
>> >> >>> > 'opengl', '', d)}"
>> >> >>> >
>> >> >>> > PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
>> >> >>> > --disable-xlib,${X11DEPENDS}"
>> >> >>> > PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
>> >> >>> > diff --git a/meta/recipes-graphics/mesa/mesa.inc
>> >> >>> > b/meta/recipes-graphics/mesa/mesa.inc
>> >> >>> > index 5afd0db4b7..dd626d9f00 100644
>> >> >>> ^ I think this came in accidentaly and it breaks builds when adding
>> >> >>> packageconfig glesv2:
>> >> >>>
>> >> >>> | configure: error: use either --enable-gl=yes or --enable-glesv2=yes.
>> >> >>> Not both at the same time.
>> >> >>
>> >> >> do you remove opengl from DISTRO_FEATURES when enabling glesv2 ?
>> >> >> try that out.
>> >> >>
>> >> >>>
>> >> > Yes of course I can. But this patch is wrong - we don't have gles as
>> >> > distro feature - and it is not even mentioned in commit message why
>> >> > this is done.
>> >> >
>> >> I am tempted to send a revert for the cairo part:
>> >>
>> >> * Cross: It changes defaults valid for long time
>> >> * Native: As far as I can remember it causes trouble for cairo-native
>> >> * It went through without mentioning
>> >
>> > opengl as a DISTRO_FEATURE should tie into packageconfigs, the
>> > situation before this patch was not ideal, people got to work with it.
>> >
>> > as seen in the example you cited, we can't mix opengl and gles support
>> > in packages. other layers have solved your kind of usecase like below
>> >
>> > https://github.com/WebPlatformForEmbedded/meta-wpe/blob/master/recipes-graphics/cairo/cairo_%.bbappend
>> * ^The link is broken
>
> ah see cairo bbappend here
> https://github.com/WebPlatformForEmbedded/meta-wpe/tree/master/recipes-graphics/cairo
That is more or less the same I am doing in
https://github.com/schnitzeltony/meta-misc/blob/master/appends-packageconfig/oe-core/cairo_%25.bbappend
So meta-wpe will break from now on when used together with a distro
layer enabling opengl in DISTRO_FEATURES - right?
Meanwhile I've checked the native case: It builds fine. To understand why I did:
| bitbake -e cairo | grep ^DISTRO_FEATURES
| <...>
| DISTRO_FEATURES="<...> opengl <...>'
| <...>
and
| bitbake -e cairo-native | grep ^DISTRO_FEATURES
| <...>
DISTRO_FEATURES="ipv6 x11 xattr pulseaudio bluez5
gobject-introspection-data ldconfig"
| <...>
Some magic which I can't find right now, removes opengl from
DISTRO_FEATURES => You patch does not break anything.
Maybe you should send some patch to meta-wpe :)
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] mesa: Enable gallium-llvm on x86 and x86_64
Hi Andreas
On Tue, Aug 28, 2018 at 11:28 AM Andreas Müller wrote:
>
> On Tue, Aug 28, 2018 at 7:36 PM, Khem Raj wrote:
> > Hi Andreas
> >
> > On Tue, Aug 28, 2018 at 10:21 AM Andreas Müller
> > wrote:
> >>
> >> On Tue, Aug 28, 2018 at 8:43 AM, Andreas Müller
> >> wrote:
> >> > On Tue, Aug 28, 2018 at 12:55 AM, Khem Raj wrote:
> >> >> On Mon, Aug 27, 2018 at 2:15 PM Andreas Müller
> >> >> wrote:
> >> >>>
> >> >>> On Mon, Aug 20, 2018 at 8:59 PM, Khem Raj wrote:
> >> >>> > Signed-off-by: Khem Raj
> >> >>> > ---
> >> >>> > meta/recipes-graphics/cairo/cairo.inc | 3 ++-
> >> >>> > meta/recipes-graphics/mesa/mesa.inc | 3 +++
> >> >>> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >> >>> >
> >> >>> > diff --git a/meta/recipes-graphics/cairo/cairo.inc
> >> >>> > b/meta/recipes-graphics/cairo/cairo.inc
> >> >>> > index 20e0d2c92a..7347f223ff 100644
> >> >>> > --- a/meta/recipes-graphics/cairo/cairo.inc
> >> >>> > +++ b/meta/recipes-graphics/cairo/cairo.inc
> >> >>> > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender
> >> >>> > libxext"
> >> >>> > DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
> >> >>> >
> >> >>> > PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> >> >>> > 'x11 xcb', '', d)} \
> >> >>> > - ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
> >> >>> > + ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
> >> >>> > + ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
> >> >>> > 'opengl', '', d)}"
> >> >>> >
> >> >>> > PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
> >> >>> > --disable-xlib,${X11DEPENDS}"
> >> >>> > PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
> >> >>> > diff --git a/meta/recipes-graphics/mesa/mesa.inc
> >> >>> > b/meta/recipes-graphics/mesa/mesa.inc
> >> >>> > index 5afd0db4b7..dd626d9f00 100644
> >> >>> ^ I think this came in accidentaly and it breaks builds when adding
> >> >>> packageconfig glesv2:
> >> >>>
> >> >>> | configure: error: use either --enable-gl=yes or --enable-glesv2=yes.
> >> >>> Not both at the same time.
> >> >>
> >> >> do you remove opengl from DISTRO_FEATURES when enabling glesv2 ?
> >> >> try that out.
> >> >>
> >> >>>
> >> > Yes of course I can. But this patch is wrong - we don't have gles as
> >> > distro feature - and it is not even mentioned in commit message why
> >> > this is done.
> >> >
> >> I am tempted to send a revert for the cairo part:
> >>
> >> * Cross: It changes defaults valid for long time
> >> * Native: As far as I can remember it causes trouble for cairo-native
> >> * It went through without mentioning
> >
> > opengl as a DISTRO_FEATURE should tie into packageconfigs, the
> > situation before this patch was not ideal, people got to work with it.
> >
> > as seen in the example you cited, we can't mix opengl and gles support
> > in packages. other layers have solved your kind of usecase like below
> >
> > https://github.com/WebPlatformForEmbedded/meta-wpe/blob/master/recipes-graphics/cairo/cairo_%.bbappend
> * ^The link is broken
ah see cairo bbappend here
https://github.com/WebPlatformForEmbedded/meta-wpe/tree/master/recipes-graphics/cairo
> * Am quite sure that it breaks cairo-native or dependants (have no
> logs at hand - it is some time ago)
> * Again: I consider this a major change and it was not even
> mentioned/discussed. To me it has nothing to do with 'mesa: Enable
> gallium-llvm on x86 and x86_64' - btw: what does that fix?
>
gallium is for enabling Gallium llvmpipe driver as rasterizer using llvm IR
code generator.
> Let's close discussion here - I think after all these years here I am
> able to find a workaround in case of further issues. Thanks for
> support.
>
> Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt
On 08/27/2018 02:42 AM, Andrej Valek wrote: Did you find some final solution? Since no one has replied, it seems that the answer is to omit the virtual/crypt dependency. For me, we can make it enabled by default. Anyone could use custom defconfig in own layer. Right. I would be nice get the package update done since 1.27.x is about a year old and M3 is yesterday/this week. We can settle this potential dependency as a defect if someone finds such a bug. ../Randy Cheers, Andrej On 08/20/18 23:28, Andre McCurdy wrote: On Mon, Aug 20, 2018 at 2:03 PM, Peter Kjellerstedt wrote: -Original Message- From: Andre McCurdy Sent: den 20 augusti 2018 22:23 To: Khem Raj Cc: Richard Purdie ; Peter Kjellerstedt ; Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj wrote: On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie wrote: On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote: busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined. Signed-off-by: Peter Kjellerstedt --- meta/recipes-core/busybox/busybox.inc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes- core/busybox/busybox.inc index 8c6dbbaf9b..a8ba10d21c 100644 --- a/meta/recipes-core/busybox/busybox.inc +++ b/meta/recipes-core/busybox/busybox.inc @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into HOMEPAGE = "http://www.busybox.net; BUGTRACKER = "https://bugs.busybox.net/; -DEPENDS += "kern-tools-native" +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not defined +DEPENDS += "kern-tools-native virtual/crypt" I'm not a bug fan of adding dependencies which might not be needed. How common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't our default config? yes perhaps it should be packageconfig Busybox doesn't use PACKAGECONFIG. Conditional configuration is handled by adding / removing cfg fragments and testing whether SRC_URI contains "foo.cfg" (and also parsing the final .config within tasks such as do_install). Unfortunately that approach doesn't work so well for conditional build dependencies... Our Busybox defconfig does enable CONFIG_USE_BB_CRYPT (and there's no cfg fragment to disable it) so the virtual/crypt dependency isn't needed in our default builds. In our case we have our own defconfig. I am not responsible for it, it is maintained by our busybox maintainer, and he has apparently decided that we don't want CONFIG_USE_BB_CRYPT enabled. Could you ask him about it? Maybe there's some advantage to it that isn't clear. The general OE approach is to use system libraries when possible so using external libcrypt does actually align to that. Maybe we should use external libcrypt by default (with the option to switch back to the built-in crypt functions via a cfg fragment)? I can of course add the dependency via a bbappend, but having to do that seems wrong given how the rest of busybox is configured (with defconfig and cfg fragments) and where enabling some options that don't happen to be enabled in the OE-Core default configuration will then break the build. Disabling busybox's internal crypt functions doesn't seem like a very common thing to want to do. config USE_BB_CRYPT bool "Use internal crypt functions" default y help Busybox has internal DES and MD5 crypt functions. They produce results which are identical to corresponding standard C library functions. If you leave this disabled, busybox will use the system's crypt functions. Most C libraries use large (~70k) static buffers there, and also combine them with more general DES encryption/decryption. For busybox, having large static buffers is undesirable, especially on NOMMU machines. Busybox also doesn't need DES encryption/decryption and can do with smaller code. If you enable this option, it will add about 4.8k of code if you are building dynamically linked executable. In static build, it makes code _smaller_ by about 1.2k, and likely many kilobytes less of bss. //Peter -- # Randy MacLeod # Wind River Linux -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] mesa: Enable gallium-llvm on x86 and x86_64
On Tue, Aug 28, 2018 at 7:36 PM, Khem Raj wrote:
> Hi Andreas
>
> On Tue, Aug 28, 2018 at 10:21 AM Andreas Müller
> wrote:
>>
>> On Tue, Aug 28, 2018 at 8:43 AM, Andreas Müller
>> wrote:
>> > On Tue, Aug 28, 2018 at 12:55 AM, Khem Raj wrote:
>> >> On Mon, Aug 27, 2018 at 2:15 PM Andreas Müller
>> >> wrote:
>> >>>
>> >>> On Mon, Aug 20, 2018 at 8:59 PM, Khem Raj wrote:
>> >>> > Signed-off-by: Khem Raj
>> >>> > ---
>> >>> > meta/recipes-graphics/cairo/cairo.inc | 3 ++-
>> >>> > meta/recipes-graphics/mesa/mesa.inc | 3 +++
>> >>> > 2 files changed, 5 insertions(+), 1 deletion(-)
>> >>> >
>> >>> > diff --git a/meta/recipes-graphics/cairo/cairo.inc
>> >>> > b/meta/recipes-graphics/cairo/cairo.inc
>> >>> > index 20e0d2c92a..7347f223ff 100644
>> >>> > --- a/meta/recipes-graphics/cairo/cairo.inc
>> >>> > +++ b/meta/recipes-graphics/cairo/cairo.inc
>> >>> > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender
>> >>> > libxext"
>> >>> > DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>> >>> >
>> >>> > PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
>> >>> > 'x11 xcb', '', d)} \
>> >>> > - ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
>> >>> > + ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
>> >>> > + ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
>> >>> > 'opengl', '', d)}"
>> >>> >
>> >>> > PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
>> >>> > --disable-xlib,${X11DEPENDS}"
>> >>> > PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
>> >>> > diff --git a/meta/recipes-graphics/mesa/mesa.inc
>> >>> > b/meta/recipes-graphics/mesa/mesa.inc
>> >>> > index 5afd0db4b7..dd626d9f00 100644
>> >>> ^ I think this came in accidentaly and it breaks builds when adding
>> >>> packageconfig glesv2:
>> >>>
>> >>> | configure: error: use either --enable-gl=yes or --enable-glesv2=yes.
>> >>> Not both at the same time.
>> >>
>> >> do you remove opengl from DISTRO_FEATURES when enabling glesv2 ?
>> >> try that out.
>> >>
>> >>>
>> > Yes of course I can. But this patch is wrong - we don't have gles as
>> > distro feature - and it is not even mentioned in commit message why
>> > this is done.
>> >
>> I am tempted to send a revert for the cairo part:
>>
>> * Cross: It changes defaults valid for long time
>> * Native: As far as I can remember it causes trouble for cairo-native
>> * It went through without mentioning
>
> opengl as a DISTRO_FEATURE should tie into packageconfigs, the
> situation before this patch was not ideal, people got to work with it.
>
> as seen in the example you cited, we can't mix opengl and gles support
> in packages. other layers have solved your kind of usecase like below
>
> https://github.com/WebPlatformForEmbedded/meta-wpe/blob/master/recipes-graphics/cairo/cairo_%.bbappend
* ^The link is broken
* Am quite sure that it breaks cairo-native or dependants (have no
logs at hand - it is some time ago)
* Again: I consider this a major change and it was not even
mentioned/discussed. To me it has nothing to do with 'mesa: Enable
gallium-llvm on x86 and x86_64' - btw: what does that fix?
Let's close discussion here - I think after all these years here I am
able to find a workaround in case of further issues. Thanks for
support.
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Troubleshooting sstate cache
The problem may be a result of executables being built with absolute paths to their shared libraries. When I do the following: ldd -v ./tmp/sysroots/x86_64-linux/usr/bin/powerpc-poky-linux/powerpc-poky-linux-ar I see the Library runpath for a shared library is an absolute path to the original Jenkins job that was building the sstate cache, not the current one that I am building. How do I configure Yocto not to use absolute paths to the shared libraries? Nick -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Troubleshooting sstate cache
Thanks for your response Alex. Below is an excerpt of one failure I've encountered. When attempting to do_rootfs, the following error occurs: error while loading shared libraries: libopkg.so.1: cannot open shared object file: No such file or directory Below is more detail: NOTE: recipe core-image-biamp-linux-ppc-1.0-r0: task do_rootfs: Started ERROR: Unable to update the package index files. Command '/var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/sysroots/x86_64-linux/usr/bin/opkg-cl -f /var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/work/mpc83xx-poky-linux/core-image-biamp-linux-ppc/1.0-r0/opkg.conf -o /var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/work/mpc83xx-poky-linux/core-image-biamp-linux-ppc/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-exclude linux-dummy --add-exclude opkg --add-exclude dbus --add-exclude gdbm --force-overwrite update' returned 127: /var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/sysroots/x86_64-linux/usr/bin/opkg-cl: error while loading shared libraries: libopkg.so.1: cannot open shared object file: No such file or directory ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/work/mpc83xx-poky-linux/core-image-biamp-linux-ppc/1.0-r0/temp/log.do_rootfs.4871 NOTE: recipe core-image-biamp-linux-ppc-1.0-r0: task do_rootfs: Failed ERROR: Task 7 (/var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/../meta-biamp/recipes-ppc/images/ core-image-biamp-linux-ppc.bb, do_rootfs) failed with exit code '1' When I execute ldd on opkg-cl, I get the following: linux-vdso.so.1 (0x7ffda9bd8000) libopkg.so.1 => not found libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f72dbac3000) /lib64/ld-linux-x86-64.so.2 (0x7f72dc067000) Looking inside the tmp/sysroots directory, I can find libopkg.so.1. It appears as though opkg-cl was built to look for the shared library in the host path rather than the tmp/sysroots path. My guess is that this is something other than an sstate-cache problem but when I clear the sstate-cache, everything builds fine. Nick On Tue, Aug 28, 2018 at 12:10 AM Alexander Kanavin wrote: > 2018-08-28 7:53 GMT+02:00 Nick Winters : > > Often when I use an sstate cache from another build, I run into problems > > where builds fail. Usually the failure is a result of not being able to > find > > a shared library. If I delete the sstate cache, the build succeeds, > although > > it is 8 hours later. I switched to using sstate mirrors and had similar > > problems. > > If you provide an example of a specific failure, we might be better > able to help you. > > It's fine to use one global sstate cache for absolutely everything. > You can share between builds, target machines and distros. > > Alex > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] systemd: Fix qsort_r patch for function return mismatch
clang is fussy and complains that a valueless return is used from a
function which should return a value
Signed-off-by: Khem Raj
---
.../0002-don-t-use-glibc-specific-qsort_r.patch | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
a/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch
b/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch
index f07211bd8a..8e0d669e83 100644
---
a/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch
+++
b/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch
@@ -1,7 +1,7 @@
-From d43faf6d253db789225b7c454c8f255fbc68857e Mon Sep 17 00:00:00 2001
+From d74a4de6daea5a511c2b5636bbb552c15b3a4ad9 Mon Sep 17 00:00:00 2001
From: Emil Renner Berthing
Date: Thu, 18 Sep 2014 15:24:56 +0200
-Subject: [PATCH 02/19] don't use glibc-specific qsort_r
+Subject: [PATCH] don't use glibc-specific qsort_r
Upstream-Status: Inappropriate [musl specific]
@@ -14,7 +14,7 @@ Signed-off-by: Khem Raj
4 files changed, 37 insertions(+), 31 deletions(-)
diff --git a/src/basic/format-table.c b/src/basic/format-table.c
-index 94e796d1c..f7b4eade9 100644
+index 94e796d1ca..9b3f35c29a 100644
--- a/src/basic/format-table.c
+++ b/src/basic/format-table.c
@@ -745,29 +745,29 @@ static int cell_data_compare(TableData *a, size_t
index_a, TableData *b, size_t
@@ -63,7 +63,7 @@ index 94e796d1c..f7b4eade9 100644
-qsort_r_safe(sorted, n_rows, sizeof(size_t),
table_data_compare, t);
+if (n_rows <= 1)
-+return;
++return 0;
+assert(sorted);
+user_table = t;
+qsort(sorted, n_rows, sizeof(size_t), table_data_compare);
@@ -72,7 +72,7 @@ index 94e796d1c..f7b4eade9 100644
if (t->display_map)
diff --git a/src/basic/util.h b/src/basic/util.h
-index 9699d228f..40eaf518c 100644
+index 9699d228f9..40eaf518cb 100644
--- a/src/basic/util.h
+++ b/src/basic/util.h
@@ -105,13 +105,6 @@ static inline void qsort_safe(void *base, size_t nmemb,
size_t size, comparison_
@@ -90,7 +90,7 @@ index 9699d228f..40eaf518c 100644
/**
* Normal memcpy requires src to be nonnull. We do nothing if n is 0.
diff --git a/src/hwdb/hwdb.c b/src/hwdb/hwdb.c
-index 317cad8a6..701d59a1e 100644
+index 317cad8a67..701d59a1eb 100644
--- a/src/hwdb/hwdb.c
+++ b/src/hwdb/hwdb.c
@@ -135,13 +135,12 @@ static void trie_free(struct trie *trie) {
@@ -135,7 +135,7 @@ index 317cad8a6..701d59a1e 100644
}
diff --git a/src/udev/udevadm-hwdb.c b/src/udev/udevadm-hwdb.c
-index 02408a428..491d367d1 100644
+index 02408a4285..491d367d12 100644
--- a/src/udev/udevadm-hwdb.c
+++ b/src/udev/udevadm-hwdb.c
@@ -114,13 +114,13 @@ static void trie_node_cleanup(struct trie_node *node) {
@@ -179,5 +179,5 @@ index 02408a428..491d367d1 100644
}
--
-2.11.0
+2.18.0
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] gpgme: Inherit distutils3-base
its building a module therefore its important to provide correct cross
build environment, distutils3-base automatically inherits python3native
this is seen when using clang where it tried to link with gcc since the
environment falls back to builtin LDSHARED variable
Signed-off-by: Khem Raj
---
meta/recipes-support/gpgme/gpgme_1.11.1.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/gpgme/gpgme_1.11.1.bb
b/meta/recipes-support/gpgme/gpgme_1.11.1.bb
index 151fc03f55..ac9fccf133 100644
--- a/meta/recipes-support/gpgme/gpgme_1.11.1.bb
+++ b/meta/recipes-support/gpgme/gpgme_1.11.1.bb
@@ -48,8 +48,8 @@ LANGUAGES ?= "${DEFAULT_LANGUAGES}"
LANGUAGES .= "${@bb.utils.contains('PACKAGECONFIG', 'python2', ' python2', '',
d)}"
LANGUAGES .= "${@bb.utils.contains('PACKAGECONFIG', 'python3', ' python3', '',
d)}"
-PYTHON_INHERIT = "${@bb.utils.contains('PACKAGECONFIG', 'python2',
'pythonnative', '', d)}"
-PYTHON_INHERIT .= "${@bb.utils.contains('PACKAGECONFIG', 'python3',
'python3native', '', d)}"
+PYTHON_INHERIT = "${@bb.utils.contains('PACKAGECONFIG', 'python2', '
distutils-base', '', d)}"
+PYTHON_INHERIT .= "${@bb.utils.contains('PACKAGECONFIG', 'python3', '
distutils3-base', '', d)}"
EXTRA_OECONF += '--enable-languages="${LANGUAGES}" \
--disable-gpgconf-test \
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] musl: Update to latest
Important regression fixes for mips and pthreads
https://git.musl-libc.org/cgit/musl/log/?qt=range=1ad8138819ced49851e618c9c063aa0ffc86718c..767f7a1091af3a3dcee2f7a49d0713359a81961c
Signed-off-by: Khem Raj
---
meta/recipes-core/musl/musl_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/musl/musl_git.bb
b/meta/recipes-core/musl/musl_git.bb
index c13371014a..f4f156042a 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -3,7 +3,7 @@
require musl.inc
-SRCREV = "1ad8138819ced49851e618c9c063aa0ffc86718c"
+SRCREV = "767f7a1091af3a3dcee2f7a49d0713359a81961c"
PV = "1.1.19+git${SRCPV}"
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] distutils-common-base.bbclass: Define commonly used compiler variables
This is inspired from
https://github.com/python/cpython/blob/master/configure.ac
Helps cross compiling python C modules in some cases where they do
not respect normal CFLAGS
Errors like using gcc to link when compiler is clang is fixed
Signed-off-by: Khem Raj
---
meta/classes/distutils-common-base.bbclass | 12
1 file changed, 12 insertions(+)
diff --git a/meta/classes/distutils-common-base.bbclass
b/meta/classes/distutils-common-base.bbclass
index 824a1b68b1..94b5fd426d 100644
--- a/meta/classes/distutils-common-base.bbclass
+++ b/meta/classes/distutils-common-base.bbclass
@@ -1,6 +1,18 @@
export STAGING_INCDIR
export STAGING_LIBDIR
+# LDSHARED is the ld *command* used to create shared library
+export LDSHARED = "${CCLD} -shared"
+# LDXXSHARED is the ld *command* used to create shared library of C++
+# objects
+export LDCXXSHARED = "${CXX} -shared"
+# CCSHARED are the C *flags* used to create objects to go into a shared
+# library (module)
+export CCSHARED = "-fPIC -DPIC"
+# LINKFORSHARED are the flags passed to the $(CC) command that links
+# the python executable
+export LINKFORSHARED = "{SECURITY_CFLAGS} -Xlinker -export-dynamic"
+
FILES_${PN} += "${libdir}/* ${libdir}/${PYTHON_DIR}/*"
FILES_${PN}-staticdev += "\
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/4] Misc Fixes
Musl has some important fixes distutils fix is taking care of some missed flags for C/C++ plugins, helps builds with PIE/PIC Systemd patch fix is found out by clang v2: Add gpgme fix The following changes since commit a5439ff9627d309f6980947f5ee573d85e672228: cpan.bbclass: make RPATH fix more general (2018-08-28 10:27:15 +0100) are available in the Git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/pu http://cgit.openembedded.org/openembedded-core-contrib/log/?h=kraj/pu Khem Raj (4): distutils-common-base.bbclass: Define commonly used compiler variables systemd: Fix qsort_r patch for function return mismatch musl: Update to latest gpgme: Inherit distutils3-base meta/classes/distutils-common-base.bbclass | 12 meta/recipes-core/musl/musl_git.bb | 2 +- .../0002-don-t-use-glibc-specific-qsort_r.patch | 16 meta/recipes-support/gpgme/gpgme_1.11.1.bb | 4 ++-- 4 files changed, 23 insertions(+), 11 deletions(-) -- 2.18.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] mesa: Enable gallium-llvm on x86 and x86_64
Hi Andreas
On Tue, Aug 28, 2018 at 10:21 AM Andreas Müller wrote:
>
> On Tue, Aug 28, 2018 at 8:43 AM, Andreas Müller
> wrote:
> > On Tue, Aug 28, 2018 at 12:55 AM, Khem Raj wrote:
> >> On Mon, Aug 27, 2018 at 2:15 PM Andreas Müller
> >> wrote:
> >>>
> >>> On Mon, Aug 20, 2018 at 8:59 PM, Khem Raj wrote:
> >>> > Signed-off-by: Khem Raj
> >>> > ---
> >>> > meta/recipes-graphics/cairo/cairo.inc | 3 ++-
> >>> > meta/recipes-graphics/mesa/mesa.inc | 3 +++
> >>> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >>> >
> >>> > diff --git a/meta/recipes-graphics/cairo/cairo.inc
> >>> > b/meta/recipes-graphics/cairo/cairo.inc
> >>> > index 20e0d2c92a..7347f223ff 100644
> >>> > --- a/meta/recipes-graphics/cairo/cairo.inc
> >>> > +++ b/meta/recipes-graphics/cairo/cairo.inc
> >>> > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
> >>> > DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
> >>> >
> >>> > PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
> >>> > xcb', '', d)} \
> >>> > - ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
> >>> > + ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
> >>> > + ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
> >>> > 'opengl', '', d)}"
> >>> >
> >>> > PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
> >>> > --disable-xlib,${X11DEPENDS}"
> >>> > PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
> >>> > diff --git a/meta/recipes-graphics/mesa/mesa.inc
> >>> > b/meta/recipes-graphics/mesa/mesa.inc
> >>> > index 5afd0db4b7..dd626d9f00 100644
> >>> ^ I think this came in accidentaly and it breaks builds when adding
> >>> packageconfig glesv2:
> >>>
> >>> | configure: error: use either --enable-gl=yes or --enable-glesv2=yes.
> >>> Not both at the same time.
> >>
> >> do you remove opengl from DISTRO_FEATURES when enabling glesv2 ?
> >> try that out.
> >>
> >>>
> > Yes of course I can. But this patch is wrong - we don't have gles as
> > distro feature - and it is not even mentioned in commit message why
> > this is done.
> >
> I am tempted to send a revert for the cairo part:
>
> * Cross: It changes defaults valid for long time
> * Native: As far as I can remember it causes trouble for cairo-native
> * It went through without mentioning
opengl as a DISTRO_FEATURE should tie into packageconfigs, the
situation before this patch was not ideal, people got to work with it.
as seen in the example you cited, we can't mix opengl and gles support
in packages. other layers have solved your kind of usecase like below
https://github.com/WebPlatformForEmbedded/meta-wpe/blob/master/recipes-graphics/cairo/cairo_%.bbappend
>
> Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost: add ptest support
On 08/28/2018 10:25 AM, Yang Wang wrote: On 08/27/2018 08:57 PM, Randy MacLeod wrote: On 08/27/2018 06:17 PM, Yang Wang wrote: Not sure if it's worth to run the Ptest on QEMU though, I also run Ptest on SIMICS simulators, thousands of tests didn't get run, looks like the result was not good as well. Now my nightly Ptest runs on x86 device and gets consistent result every day: 2018-08-27T06:26 -- 2018-08-27T09:52 Passed: 40518 Failed: 289 Skipped: 1876 Consistent results are good and > 90% pass rate is very good. What are the stats using qemux86-64 and/or simics? I don't expect that qemu results would be as close to real hardware as Simics but it is quite good and freely available. Actually, Ptest has 37 test suites as far as I know, different test suites spent different time on QEMU and hardware, here is a list of Ptest suites and their case number and spent time for running: Just want to make it look better: == # Suite Name Case # Time to Run Case # Time to Run qemu-x86-64 intel-xeon-core2 1 acl 2 1m 380 1m 2 attr 143 1m 143 1m 3 bash 79 8m 79 4m 4 bluez5 7 6m 7 6m 5 bzip2 6 1m 6 1m 6 dbus-test 15 3m 15 1m 7 diffutils 20 1m 20 2m 8 e2fsprogs 147 9m 335 10m 9 ethtool 2 1m 2 1m 10 flex 114 3m 114 1m 11 gawk 300 3m 298 2m 12 gdbm 30 2m 25 2m 13 glib-2.0 62 14m 220 6m 14 gzip 51 4m 18 1m 15 kbd 15 1m 7 1m 16 libevent 22 6m 1 3m 17 libpcre 34 3m 3 1m 18 libxml2 1 1m 0 1m 19 lzo 75 8m 5 3m 20 mdadm 6m 6m 21 nettle 90 3m 90 3m 22 numactl 8 3m 23 openssh 13 27m 47 52m 24 openssl 87 47m 56 15m 25 parted 64 5m 38 10m 26 perl 101 20m 2440 47m 27 perl5 110 17m 2406 29m 28 python 10961 1h 5m 32323 20m 29 rsyslog 2200 3h 37m 25 8m 30 sed 147 1m 86 3m 31 slang 96 1m 32 strace 1557 1h 13m 431 6m 33 systemd 305 9m 155 3m 34 tcl 869 53m 206 6m 35 tcpdump 451 7m 413 3m 36 util-linux 516 25m 514 13m 37 zlib 2 1m 2 1m Overall 18080 10h 30m 40415 4h 15m As you can see, running subset of them on QEMU could be a solution if people do not want to spend too much time on it or simulator is the preferred test device. Thanks, -Yang Thanks, Yang Wang -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] mesa: Enable gallium-llvm on x86 and x86_64
On Tue, Aug 28, 2018 at 8:43 AM, Andreas Müller wrote:
> On Tue, Aug 28, 2018 at 12:55 AM, Khem Raj wrote:
>> On Mon, Aug 27, 2018 at 2:15 PM Andreas Müller
>> wrote:
>>>
>>> On Mon, Aug 20, 2018 at 8:59 PM, Khem Raj wrote:
>>> > Signed-off-by: Khem Raj
>>> > ---
>>> > meta/recipes-graphics/cairo/cairo.inc | 3 ++-
>>> > meta/recipes-graphics/mesa/mesa.inc | 3 +++
>>> > 2 files changed, 5 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/meta/recipes-graphics/cairo/cairo.inc
>>> > b/meta/recipes-graphics/cairo/cairo.inc
>>> > index 20e0d2c92a..7347f223ff 100644
>>> > --- a/meta/recipes-graphics/cairo/cairo.inc
>>> > +++ b/meta/recipes-graphics/cairo/cairo.inc
>>> > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
>>> > DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>>> >
>>> > PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
>>> > xcb', '', d)} \
>>> > - ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
>>> > + ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
>>> > + ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
>>> > 'opengl', '', d)}"
>>> >
>>> > PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
>>> > --disable-xlib,${X11DEPENDS}"
>>> > PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
>>> > diff --git a/meta/recipes-graphics/mesa/mesa.inc
>>> > b/meta/recipes-graphics/mesa/mesa.inc
>>> > index 5afd0db4b7..dd626d9f00 100644
>>> ^ I think this came in accidentaly and it breaks builds when adding
>>> packageconfig glesv2:
>>>
>>> | configure: error: use either --enable-gl=yes or --enable-glesv2=yes.
>>> Not both at the same time.
>>
>> do you remove opengl from DISTRO_FEATURES when enabling glesv2 ?
>> try that out.
>>
>>>
> Yes of course I can. But this patch is wrong - we don't have gles as
> distro feature - and it is not even mentioned in commit message why
> this is done.
>
I am tempted to send a revert for the cairo part:
* Cross: It changes defaults valid for long time
* Native: As far as I can remember it causes trouble for cairo-native
* It went through without mentioning
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Revert "cpan.bbclass: adopt to recent EU::MM"
Hi Khem, I put the alternative fix into master as it passed OE-Core testing. Could you see how the perl failures are looking in meta-oe now please? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Revert "cpan.bbclass: adopt to recent EU::MM"
On Tue, Aug 28, 2018 at 12:21 AM Jens Rehsack wrote:
>
>
> Am 24.08.2018 um 10:07 schrieb Khem Raj :
>
> This reverts commit 2e61533e7c1b1cfd49dc771e907207f11a15c44f.
> ---
> meta/classes/cpan.bbclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/cpan.bbclass b/meta/classes/cpan.bbclass
> index 926c6358a6..8e079e0d55 100644
> --- a/meta/classes/cpan.bbclass
> +++ b/meta/classes/cpan.bbclass
> @@ -16,7 +16,8 @@ export PERL_ARCHLIB =
> "${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
> export PERLHOSTLIB =
> "${STAGING_LIBDIR_NATIVE}/perl-native/perl/${@get_perl_version(d)}/"
>
> cpan_do_configure () {
> - yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor
> NO_PERLLOCAL=1 NO_PACKLIST=1 ${EXTRA_CPANFLAGS}
> + export PERL5LIB="${PERL_ARCHLIB}"
> + yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor
> ${EXTRA_CPANFLAGS}
>
> # Makefile.PLs can exit with success without generating a
> # Makefile, e.g. in cases of missing configure time
> --
> 2.18.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
> This one shouldn't get tested together with
>2387c0d3 cpan.bbclass: make RPATH fix more general
> since the hacked PERL5LIB="${PERL_ARCHLIB}" hides the broken RPATH
> behavior.
>
Yes it won’t this was actsully meant for master-next only
> --
> Jens Rehsack - rehs...@gmail.com
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW35’18
Current Dev Position: YP 2.6 M3. - This is feature freeze for YP 2.6! Next Deadline: YP 2.6 M3 Build Target is Aug. 27, 2018 SWAT Team Rotation: · SWAT lead is currently: Paul · SWAT team rotation: Paul -> Ross on Aug. 31, 2018 · SWAT team rotation: Ross -> Amanda on Sept. 7, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · We’re now into M3 feature freeze so new feature patches, particularly for unplanned changes will be much less likely to be merged until 2.7 now. · Fixes merged for hardlinked files and their debug symbol links including new test cases to ensure this does not regress · Pending kernel upgrades (to 4.18) and other kernel changes for 2.6 merged · There was a change to the cpan class code which broke various external perl recipes. A secondary fix has been merged but needs testing, if it fails we may need to revert the original change. · Some key changes in toaster merged · Some oeqa race/logging output issues were identified and fixed · The sstate equivalency server work from Joshua/Garmin has review still pending and identifying/fixing persist_data fork issues (it's partly tracked down but not completely). · 2.4 (rocko) series stabilization continues for the next point release 2.4.4 · Autobuilder2 now includes instructions on setting up and rebuilding the Yocto Console UI plugin · We have a build speed performance regression where the llvm build time and python pgo optimisation time added by new recent features mean builds are now taking around 45 minutes longer on our standard benchmarking system (1:26 -> 2:11). · This llvm dependency addition to mesa by default means image size for core-image-sato also increased substantially (230MB -> 309MB). Planned Releases for YP 2.6: · YP 2.6 M3 Build Target is Aug. 27, 2018 · YP 2.6 M3 Release Target is Sept. 7, 2018 · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. Tracking Metrics: · WDD 2610 (last week 2578) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1636 (last week 1623) oPercentage of patches in the Pending State: 737 (45%) [last week 737 (45%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/12] linux-yocto: introduce 4.18 recipes
On 2018-08-28 9:27 AM, He Zhe wrote:
On 2018年08月24日 22:59, Bruce Ashfield wrote:
Introducing the 4.18 kernel as the 'newest' kernel for the oe core
release.
This update includes tweaked configs, carried forward BSPs, features
(aufs, yaffs2, preempt-rt) and has been tested on all arches for boot
and performance sanity.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb | 43 +++
meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb | 29 +
meta/recipes-kernel/linux/linux-yocto_4.18.bb | 48 ++
3 files changed, 120 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.18.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
new file mode 100644
index ..f740b1dcd892
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
@@ -0,0 +1,43 @@
+KBRANCH ?= "v4.18/standard/preempt-rt/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# Skip processing of this recipe if it is not explicitly specified as the
+# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying
+# to build multiple virtual/kernel providers, e.g. as dependency of
+# core-image-rt-sdk, core-image-rt.
+python () {
+if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and
d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
+raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
+}
+
+SRCREV_machine ?= "8a990322beb7b3aa5a06d7bd630f819b70911587"
+SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
+
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
+
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
+
+LINUX_VERSION ?= "4.18.3"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+LINUX_KERNEL_TYPE = "preempt-rt"
+
+COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
Should qemuarm64 be in here?
It boots, so I'll add it to the compatible machines in my next queue.
qemuarm64 login: root
root@qemuarm64:~# uname -a
Linux qemuarm64 4.18.3-rt1-yocto-preempt-rt #1 SMP PREEMPT RT Tue Aug 28
14:10:55 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
root@qemuarm64:~#
Bruce
Zhe
+
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
features/taskstats/taskstats.scc"
+KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
new file mode 100644
index ..1f0b35ec25ec
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
@@ -0,0 +1,29 @@
+KBRANCH ?= "v4.18/standard/tiny/common-pc"
+LINUX_KERNEL_TYPE = "tiny"
+KCONFIG_MODE = "--allnoconfig"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+LINUX_VERSION ?= "4.18.3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+SRCREV_machine ?= "eba03655e8e436ef6090100423bcea43e4911478"
+SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
+
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
+
+COMPATIBLE_MACHINE = "qemux86|qemux86-64"
+
+# Functionality flags
+KERNEL_FEATURES = ""
+
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.18.bb
b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
new file mode 100644
index ..b42c124c87da
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
@@ -0,0 +1,48 @@
+KBRANCH ?= "v4.18/standard/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# board specific branches
+KBRANCH_qemuarm ?= "v4.18/standard/arm-versatile-926ejs"
+KBRANCH_qemuarm64 ?= "v4.18/standard/qemuarm64"
+KBRANCH_qemumips ?= "v4.18/standard/mti-malta32"
+KBRANCH_qemuppc ?= "v4.18/standard/qemuppc"
+KBRANCH_qemux86 ?= "v4.18/standard/base"
[OE-core] [PATCH 2/2] lib/oe/package_manager: turn postinst failure warnings into bitbake failures
From: Alexander Kanavin
Sumo release provides a transition period so that deferrals to first boot
via 'exit 1' can be converted to pkg_postinst_ontarget(). For the next release
however, postinst script failures should be treated as such.
[YOCTO #12607]
Signed-off-by: Alexander Kanavin
---
meta/lib/oe/package_manager.py | 22 +++---
meta/lib/oeqa/selftest/cases/runtime_test.py | 4 ++--
2 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 3988388..a17de5d 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -84,10 +84,10 @@ def opkg_query(cmd_output):
return output
-# Note: this should be bb.fatal in the future.
-def failed_postinsts_warn(pkgs, log_path):
-bb.warn("""Intentionally failing postinstall scriptlets of %s to defer
them to first boot is deprecated. Please place them into
pkg_postinst_ontarget_${PN} ().
-If deferring to first boot wasn't the intent, then scriptlet failure may mean
an issue in the recipe, or a regression elsewhere.
+def failed_postinsts_abort(pkgs, log_path):
+bb.fatal("""Postinstall scriptlets of %s have failed. If the intention is
to defer them to first boot,
+then please place them into pkg_postinst_ontarget_${PN} ().
+Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in %s.""" %(pkgs, log_path))
def generate_locale_archive(d, rootfs, target_arch, localedir):
@@ -858,9 +858,7 @@ class RpmPM(PackageManager):
failed_scriptlets_pkgnames[line.split()[-1]] = True
if len(failed_scriptlets_pkgnames) > 0:
-failed_postinsts_warn(list(failed_scriptlets_pkgnames.keys()),
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
-for pkg in failed_scriptlets_pkgnames.keys():
-self.save_rpmpostinst(pkg)
+failed_postinsts_abort(list(failed_scriptlets_pkgnames.keys()),
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
def remove(self, pkgs, with_dependencies = True):
if len(pkgs) == 0:
@@ -1341,7 +1339,7 @@ class OpkgPM(OpkgDpkgPM):
bb.warn(line)
failed_pkgs.append(line.split(".")[0])
if failed_pkgs:
-failed_postinsts_warn(failed_pkgs,
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
+failed_postinsts_abort(failed_pkgs,
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
except subprocess.CalledProcessError as e:
(bb.fatal, bb.warn)[attempt_only]("Unable to install packages. "
"Command '%s' returned %d:\n%s" %
@@ -1594,7 +1592,6 @@ class DpkgPM(OpkgDpkgPM):
os.environ['INTERCEPT_DIR'] = self.intercepts_dir
os.environ['NATIVE_ROOT'] = self.d.getVar('STAGING_DIR_NATIVE')
-failed_pkgs = []
for pkg_name in installed_pkgs:
for control_script in control_scripts:
p_full = os.path.join(info_dir, pkg_name +
control_script.suffix)
@@ -1609,12 +1606,7 @@ class DpkgPM(OpkgDpkgPM):
bb.warn("%s for package %s failed with %d:\n%s" %
(control_script.name, pkg_name, e.returncode,
e.output.decode("utf-8")))
-failed_postinsts_warn([pkg_name],
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
-failed_pkgs.append(pkg_name)
-break
-
-if len(failed_pkgs):
-self.mark_packages("unpacked", failed_pkgs)
+failed_postinsts_abort([pkg_name],
self.d.expand("${T}/log.do_${BB_CURRENTTASK}"))
def update(self):
os.environ['APT_CONFIG'] = self.apt_conf_file
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 30fd9b2..376c3c5 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -249,8 +249,8 @@ class Postinst(OESelftestTestCase):
features = 'CORE_IMAGE_EXTRA_INSTALL =
"postinst-rootfs-failing"\n'
features += 'PACKAGE_CLASSES = "%s"\n' % classes
self.write_config(features)
-bb_result = bitbake('core-image-minimal')
-self.assertGreaterEqual(bb_result.output.find("Intentionally
failing postinstall scriptlets of ['postinst-rootfs-failing'] to defer them to
first boot is deprecated."), 0,
+bb_result = bitbake('core-image-minimal', ignore_status=True)
+self.assertGreaterEqual(bb_result.output.find("Postinstall
scriptlets of ['postinst-rootfs-failing'] have failed."), 0,
"Warning about a failed scriptlet not found in bitbake
output: %s" %(bb_result.output))
self.assertTrue(os.path.isfile(os.path.join(hosttestdir,
[OE-core] [PATCH 1/2] kmod: do not reset $bindir/sbindir, use EXTRA_OECONF instead
This was causing issues with classes that use $bindir to find
already installed binaries in rootfs (manpages class in particular).
$bindir needs to be the same for all recipes.
Signed-off-by: Alexander Kanavin
---
meta/recipes-kernel/kmod/kmod_git.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/kmod/kmod_git.bb
b/meta/recipes-kernel/kmod/kmod_git.bb
index 69185b2..b256793 100644
--- a/meta/recipes-kernel/kmod/kmod_git.bb
+++ b/meta/recipes-kernel/kmod/kmod_git.bb
@@ -13,9 +13,7 @@ RREPLACES_${PN} += "module-init-tools-insmod-static
module-init-tools-depmod mod
RCONFLICTS_libkmod2 += "module-init-tools-insmod-static
module-init-tools-depmod module-init-tools"
# autotools set prefix to /usr, however we want them in /bin and /sbin
-bindir = "${base_bindir}"
-sbindir = "${base_sbindir}"
-# libdir = "${base_libdir}"
+EXTRA_OECONF += " --bindir=${base_bindir} --sbindir=${base_sbindir}"
do_install_append () {
install -dm755 ${D}${base_bindir}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost: add ptest support
On 08/27/2018 08:57 PM, Randy MacLeod wrote: On 08/27/2018 06:17 PM, Yang Wang wrote: Not sure if it's worth to run the Ptest on QEMU though, I also run Ptest on SIMICS simulators, thousands of tests didn't get run, looks like the result was not good as well. Now my nightly Ptest runs on x86 device and gets consistent result every day: 2018-08-27T06:26 -- 2018-08-27T09:52 Passed: 40518 Failed: 289 Skipped: 1876 Consistent results are good and > 90% pass rate is very good. What are the stats using qemux86-64 and/or simics? I don't expect that qemu results would be as close to real hardware as Simics but it is quite good and freely available. Actually, Ptest has 37 test suites as far as I know, different test suites spent different time on QEMU and hardware, here is a list of Ptest suites and their case number and spent time for running: # Suite Name Suite Location Case # Time to Run Case # Time to Run qemu-x86-64 intel-xeon-core2 1 acl /lib64/acl/ptest/run-ptest 2 1m 380 1m 2 attr /lib64/attr/ptest/run-ptest 143 1m 143 1m 3 bash /lib64/bash/ptest/run-ptest 79 8m 79 4m 4 bluez5 /lib64/bluez5/ptest/run-ptest 7 6m 7 6m 5 bzip2 /lib64/bzip2/ptest/run-ptest 6 1m 6 1m 6 dbus-test /lib64/dbus-test/ptest/run-ptest 15 3m 15 1m 7 diffutils /lib64/diffutils/ptest/run-ptest 20 1m 20 2m 8 e2fsprogs /lib64/e2fsprogs/ptest/run-ptest 147 9m 335 10m 9 ethtool /lib64/ethtool/ptest/run-ptest 2 1m 2 1m 10 flex /lib64/flex/ptest/run-ptest 114 3m 114 1m 11 gawk /lib64/gawk/ptest/run-ptest 300 3m 298 2m 12 gdbm /lib64/gdbm/ptest/run-ptest 30 2m 25 2m 13 glib-2.0 /lib64/glib-2.0/ptest/run-ptest 62 14m 220 6m 14 gzip /lib64/gzip/ptest/run-ptest 51 4m 18 1m 15 kbd /lib64/kbd/ptest/run-ptest 15 1m 7 1m 16 libevent /lib64/libevent/ptest/run-ptest 22 6m 1 3m 17 libpcre /lib64/libpcre/ptest/run-ptest 34 3m 3 1m 18 libxml2 /lib64/libxml2/ptest/run-ptest 1 1m 0 1m 19 lzo /lib64/lzo/ptest/run-ptest 75 8m 5 3m 20 mdadm /lib64/mdadm/ptest/run-ptest 6m 6m 21 nettle /lib64/nettle/ptest/run-ptest 90 3m 90 3m 22 numactl /lib64/numactl/ptest/run-ptest 8 3m 23 openssh /lib64/openssh/ptest/run-ptest 13 27m 47 52m 24 openssl /lib64/openssl/ptest/run-ptest 87 47m 56 15m 25 parted /lib64/parted/ptest/run-ptest 64 5m 38 10m 26 perl /lib64/perl/ptest/run-ptest 101 20m 2440 47m 27 perl5 /lib64/perl5/ptest/run-ptest 110 17m 2406 29m 28 python /lib64/python/ptest/run-ptest 10961 1h 5m 32323 20m 29 rsyslog /lib64/rsyslog/ptest/run-ptest 2200 3h 37m 25 8m 30 sed /lib64/sed/ptest/run-ptest 147 1m 86 3m 31 slang /lib64/slang/ptest/run-ptest 96 1m 32 strace /lib64/strace/ptest/run-ptest 1557 1h 13m 431 6m 33 systemd /lib64/systemd/ptest/run-ptest 305 9m 155 3m 34 tcl /lib64/tcl/ptest/run-ptest 869 53m 206 6m 35 tcpdump /lib64/tcpdump/ptest/run-ptest 451 7m 413 3m 36 util-linux /lib64/util-linux/ptest/run-ptest 516 25m 514 13m 37 zlib /lib64/zlib/ptest/run-ptest 2 1m 2 1m Overall 18080 10h 30m 40415 4h 15m As you can see, running subset of them on QEMU could be a solution if people do not want to spend too much time on it or simulator is the preferred test device. Thanks, -Yang Thanks, Yang Wang -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/12] linux-yocto: introduce 4.18 recipes
On 2018-08-28 9:27 AM, He Zhe wrote:
On 2018年08月24日 22:59, Bruce Ashfield wrote:
Introducing the 4.18 kernel as the 'newest' kernel for the oe core
release.
This update includes tweaked configs, carried forward BSPs, features
(aufs, yaffs2, preempt-rt) and has been tested on all arches for boot
and performance sanity.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb | 43 +++
meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb | 29 +
meta/recipes-kernel/linux/linux-yocto_4.18.bb | 48 ++
3 files changed, 120 insertions(+)
create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.18.bb
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
new file mode 100644
index ..f740b1dcd892
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
@@ -0,0 +1,43 @@
+KBRANCH ?= "v4.18/standard/preempt-rt/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# Skip processing of this recipe if it is not explicitly specified as the
+# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying
+# to build multiple virtual/kernel providers, e.g. as dependency of
+# core-image-rt-sdk, core-image-rt.
+python () {
+if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and
d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
+raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
+}
+
+SRCREV_machine ?= "8a990322beb7b3aa5a06d7bd630f819b70911587"
+SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
+
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
+
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
+
+LINUX_VERSION ?= "4.18.3"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+LINUX_KERNEL_TYPE = "preempt-rt"
+
+COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
Should qemuarm64 be in here?
It could be. But I haven't tested it so it hasn't made its way into
the list.
I can do a build boot of it today and send a patch to add it if it works.
Bruce
Zhe
+
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
features/taskstats/taskstats.scc"
+KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
new file mode 100644
index ..1f0b35ec25ec
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
@@ -0,0 +1,29 @@
+KBRANCH ?= "v4.18/standard/tiny/common-pc"
+LINUX_KERNEL_TYPE = "tiny"
+KCONFIG_MODE = "--allnoconfig"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+LINUX_VERSION ?= "4.18.3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+SRCREV_machine ?= "eba03655e8e436ef6090100423bcea43e4911478"
+SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
+
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
+
+COMPATIBLE_MACHINE = "qemux86|qemux86-64"
+
+# Functionality flags
+KERNEL_FEATURES = ""
+
+KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.18.bb
b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
new file mode 100644
index ..b42c124c87da
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
@@ -0,0 +1,48 @@
+KBRANCH ?= "v4.18/standard/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# board specific branches
+KBRANCH_qemuarm ?= "v4.18/standard/arm-versatile-926ejs"
+KBRANCH_qemuarm64 ?= "v4.18/standard/qemuarm64"
+KBRANCH_qemumips ?= "v4.18/standard/mti-malta32"
+KBRANCH_qemuppc ?= "v4.18/standard/qemuppc"
+KBRANCH_qemux86 ?= "v4.18/standard/base"
+KBRANCH_qemux86-64 ?= "v4.18/standard/base"
+KBRANCH_qemumips64 ?= "v4.18/standard/mti-malta64"
+
+SRCREV_machine_qemuarm ?=
Re: [OE-core] [PATCH 10/12] linux-yocto: introduce 4.18 recipes
On 2018年08月24日 22:59, Bruce Ashfield wrote:
> Introducing the 4.18 kernel as the 'newest' kernel for the oe core
> release.
>
> This update includes tweaked configs, carried forward BSPs, features
> (aufs, yaffs2, preempt-rt) and has been tested on all arches for boot
> and performance sanity.
>
> Signed-off-by: Bruce Ashfield
> ---
> meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb | 43 +++
> meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb | 29 +
> meta/recipes-kernel/linux/linux-yocto_4.18.bb | 48
> ++
> 3 files changed, 120 insertions(+)
> create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
> create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
> create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.18.bb
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
> b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
> new file mode 100644
> index ..f740b1dcd892
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
> @@ -0,0 +1,43 @@
> +KBRANCH ?= "v4.18/standard/preempt-rt/base"
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +# Skip processing of this recipe if it is not explicitly specified as the
> +# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying
> +# to build multiple virtual/kernel providers, e.g. as dependency of
> +# core-image-rt-sdk, core-image-rt.
> +python () {
> +if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and
> d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
> +raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
> linux-yocto-rt to enable it")
> +}
> +
> +SRCREV_machine ?= "8a990322beb7b3aa5a06d7bd630f819b70911587"
> +SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
> +
> +SRC_URI =
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> +
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
> +
> +LINUX_VERSION ?= "4.18.3"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
> +
> +DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
> +DEPENDS += "openssl-native util-linux-native"
> +
> +PV = "${LINUX_VERSION}+git${SRCPV}"
> +
> +KMETA = "kernel-meta"
> +KCONF_BSP_AUDIT_LEVEL = "2"
> +
> +LINUX_KERNEL_TYPE = "preempt-rt"
> +
> +COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
Should qemuarm64 be in here?
Zhe
> +
> +KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
> +
> +# Functionality flags
> +KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
> features/taskstats/taskstats.scc"
> +KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
> +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
> +KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
> +KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
> b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
> new file mode 100644
> index ..1f0b35ec25ec
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
> @@ -0,0 +1,29 @@
> +KBRANCH ?= "v4.18/standard/tiny/common-pc"
> +LINUX_KERNEL_TYPE = "tiny"
> +KCONFIG_MODE = "--allnoconfig"
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +LINUX_VERSION ?= "4.18.3"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
> +
> +DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
> +DEPENDS += "openssl-native util-linux-native"
> +
> +KMETA = "kernel-meta"
> +KCONF_BSP_AUDIT_LEVEL = "2"
> +
> +SRCREV_machine ?= "eba03655e8e436ef6090100423bcea43e4911478"
> +SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
> +
> +PV = "${LINUX_VERSION}+git${SRCPV}"
> +
> +SRC_URI =
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> +
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
> +
> +COMPATIBLE_MACHINE = "qemux86|qemux86-64"
> +
> +# Functionality flags
> +KERNEL_FEATURES = ""
> +
> +KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.18.bb
> b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
> new file mode 100644
> index ..b42c124c87da
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
> @@ -0,0 +1,48 @@
> +KBRANCH ?= "v4.18/standard/base"
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +# board specific branches
> +KBRANCH_qemuarm ?= "v4.18/standard/arm-versatile-926ejs"
> +KBRANCH_qemuarm64 ?= "v4.18/standard/qemuarm64"
> +KBRANCH_qemumips ?= "v4.18/standard/mti-malta32"
> +KBRANCH_qemuppc ?= "v4.18/standard/qemuppc"
> +KBRANCH_qemux86 ?= "v4.18/standard/base"
> +KBRANCH_qemux86-64 ?= "v4.18/standard/base"
> +KBRANCH_qemumips64 ?=
[OE-core] [PATCH] ltp: Remove unnecessary check from creat08 and open10
From: He Zhe
Issue: LIN1018-1797
At the point of the following failure, the file being checked, setgid,
is owned by "nobody" in the "nogroup" and tries to inherit SGID from
its parent directory who is in group of "bin". This is forbidden since
Linux kernel v4.18-rc4, unless current process is given CAP_FSETID
beforehand. See "Fix up non-directory creation in SGID directories" in
the kernel. The check in Block3 succeeds since it becomes root again
then.
creat08 3 TFAIL : creat08.c:368: testdir.B.1026/setgid: Incorrect modes, setgid
bit should be set
creat08 4 TFAIL : creat08.c:376: Test failed in block2.
open10 3 TFAIL : open10.c:352: open10.testdir.B.1045/setgid: Incorrect modes,
setgid bit not set
open10 4 TFAIL : open10.c:359: Test failed in block2.
open10 6 TFAIL : open10.c:443: Test failed because of above failures.
Backport a patch from upstream.
Signed-off-by: He Zhe
---
...skip-S_ISGID-check-on-files-created-by-no.patch | 81 ++
meta/recipes-extended/ltp/ltp_20180515.bb | 1 +
2 files changed, 82 insertions(+)
create mode 100644
meta/recipes-extended/ltp/ltp/0043-open-creat-skip-S_ISGID-check-on-files-created-by-no.patch
diff --git
a/meta/recipes-extended/ltp/ltp/0043-open-creat-skip-S_ISGID-check-on-files-created-by-no.patch
b/meta/recipes-extended/ltp/ltp/0043-open-creat-skip-S_ISGID-check-on-files-created-by-no.patch
new file mode 100644
index 000..dc61fcc
--- /dev/null
+++
b/meta/recipes-extended/ltp/ltp/0043-open-creat-skip-S_ISGID-check-on-files-created-by-no.patch
@@ -0,0 +1,81 @@
+From 3c87ef2961dedb10d1f674c6a530e00dbab8ec1b Mon Sep 17 00:00:00 2001
+From: Jan Stancek
+Date: Tue, 17 Jul 2018 10:26:39 +0200
+Subject: [PATCH] open|creat: skip S_ISGID check on files created by non-group
+ members
+
+0fa3ecd87848 ("Fix up non-directory creation in SGID directories")
+fixes problem described in CVE-2018-13405. This commit is getting
+backported to older streams as well.
+
+This patch removes S_ISGID check for files created by non-group members
+in LTP tests creat08 and open10.
+
+Once 0fa3ecd87848 will be in non-rc kernel, we could add a new test
+for this CVE that would be limited to 4.18+ kernels.
+
+Signed-off-by: Jan Stancek
+Acked-by: Cyril Hrubis
+Reviewed-by: Naresh Kamboju
+
+Upstream-Status: Backport
+[ git://github.com/linux-test-project/ltp.git
+ 3c87ef2961dedb10d1f674c6a530e00dbab8ec1b
+ "open|creat: skip S_ISGID check on files created by non-group members" ]
+
+Signed-off-by: He Zhe
+---
+ testcases/kernel/syscalls/creat/creat08.c | 13 ++---
+ testcases/kernel/syscalls/open/open10.c | 12 +---
+ 2 files changed, 11 insertions(+), 14 deletions(-)
+
+diff --git a/testcases/kernel/syscalls/creat/creat08.c
b/testcases/kernel/syscalls/creat/creat08.c
+index 50f2b3993..d22558ac3 100644
+--- a/testcases/kernel/syscalls/creat/creat08.c
b/testcases/kernel/syscalls/creat/creat08.c
+@@ -361,13 +361,12 @@ int main(int ac, char **av)
+ local_flag = FAILED;
+ }
+
+- /* Verify modes */
+- if (!(buf.st_mode & S_ISGID)) {
+- tst_resm(TFAIL,
+- "%s: Incorrect modes, setgid bit should be
set",
+- setgid_B);
+- local_flag = FAILED;
+- }
++ /*
++ * Skip S_ISGID check
++ * 0fa3ecd87848 ("Fix up non-directory creation in SGID
directories")
++ * clears S_ISGID for files created by non-group members
++ */
++
+ close(fd);
+
+ if (local_flag == PASSED) {
+diff --git a/testcases/kernel/syscalls/open/open10.c
b/testcases/kernel/syscalls/open/open10.c
+index 613f2288f..14feec9e1 100644
+--- a/testcases/kernel/syscalls/open/open10.c
b/testcases/kernel/syscalls/open/open10.c
+@@ -345,13 +345,11 @@ int main(int ac, char *av[])
+ local_flag = FAILED;
+ }
+
+- /* Verify modes */
+- if (!(buf.st_mode & S_ISGID)) {
+- tst_resm(TFAIL,
+- "%s: Incorrect modes, setgid bit not set",
+- setgid_B);
+- local_flag = FAILED;
+- }
++ /*
++ * Skip S_ISGID check
++ * 0fa3ecd87848 ("Fix up non-directory creation in SGID
directories")
++ * clears S_ISGID for files created by non-group members
++ */
+
+ if (local_flag == PASSED) {
+ tst_resm(TPASS, "Test passed in block2.");
+--
+2.11.0
+
diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb
b/meta/recipes-extended/ltp/ltp_20180515.bb
index 978d3cd..7c364a6 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -50,6 +50,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
Re: [OE-core] devtool recipe not working outside workspace
2018-08-28 14:29 GMT+02:00 Marco Oman : > > That's from version 2.2 (morty), right? > Any alternative option for version 2.1? > I don't know - devtool is constantly evolving. I know best how it works in the master branch, I'd suggest you try from there if possible. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] devtool recipe not working outside workspace
On 28/08/2018 14:02, Alexander Kanavin wrote: 2018-08-28 13:44 GMT+02:00 Marco Oman via Openembedded-core : So I gave the command devtool add https://github.com/Unitech/pm2.git and then bitbake pm2 Then added a patch. Everything is OK. At the end I moved the recipe under my layer (sources/meta-mycompany/recipes-devtools/pm2) and issued the command devtool reset pm2 That's not how you should be using devtool. Once you are satisfied with the recipe and sources in devtool's workspace, issue 'devtool finish' instead of moving the recipe manually etc. Alex That's from version 2.2 (morty), right? Any alternative option for version 2.1? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] devtool recipe not working outside workspace
2018-08-28 13:44 GMT+02:00 Marco Oman via Openembedded-core : > So I gave the command > > devtool add https://github.com/Unitech/pm2.git > > and then > > bitbake pm2 > > Then added a patch. Everything is OK. At the end I moved the recipe under my > layer (sources/meta-mycompany/recipes-devtools/pm2) > and issued the command > > devtool reset pm2 That's not how you should be using devtool. Once you are satisfied with the recipe and sources in devtool's workspace, issue 'devtool finish' instead of moving the recipe manually etc. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] devtool recipe not working outside workspace
Hi to all, I am trying to build a recipe for pm2 (process manager for nodejs tasks). I have followed what described here: https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM, section "NPM projects in Development" (projects under git) So I gave the command devtool add https://github.com/Unitech/pm2.git and then bitbake pm2 Then added a patch. Everything is OK. At the end I moved the recipe under my layer (sources/meta-mycompany/recipes-devtools/pm2) and issued the command devtool reset pm2 But from here on nothing seems to work. For example I have the following error while applying a patch (that exists, and I can apply a .txt version of it by a python do_patch_append). Without the patch I get a different error (pm2-3.0.4+gitAUTOINC+5a8dd7dd4f-r0 do_populate_lic: QA Issue: pm2: LIC_FILES_CHKSUM points to an invalid file: /home/user/yocto/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/pm2/3.0.4+gitAUTOINC+5a8dd7dd4f-r0/npmpkg/GNU-AGPL-3.0.txt). It looks like it is pointing to the wrong place, the overall impression is of a basic underlying flaw that pops out in different forms. Any hint or debugging suggestions? Excerpt from the error log: ERROR: pm2-3.0.4+gitAUTOINC+5a8dd7dd4f-r0 do_patch: Command Error: 'quilt --quiltrc /home/user/yocto/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/pm2/3.0.4+gitAUTOINC+5a8dd7dd4f-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output: Applying patch 0001-Removed-openrc-deps.patch can't find file to patch at input line 14 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |From 5cb1a8599eca3588d62da4619e82f7356ee6cefb Mon Sep 17 00:00:00 2001 |From: xxx |Date: Tue, 28 Aug 2018 11:18:04 +0200 |Subject: [PATCH] Removed openrc deps | |--- | lib/templates/init-scripts/openrc.tpl | 52 --- | 1 file changed, 52 deletions(-) | |diff --git a/lib/templates/init-scripts/openrc.tpl b/lib/templates/init-scripts/openrc.tpl |index 2f6d8bd..8b13789 100755 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM
On 24 August 2018 at 11:43, Mike Looijmans wrote:
> I think this should be solved in the driver actually. It probably "knows"
> which variant is there (or could be taught using devicetree or so).
I agree. That's a longer term change that will take quite some time to
filter through, if at all.
The device doesn't know which variant it is, but I'm *hoping* to add a
device tree attribute to cover this, but there has been resistance this in
the past, so it may not be an easy change to get accepted.
>
> On 24-08-18 11:04, Martin Jansa wrote:
>
>> One way to keep it allarch would be to package
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
>> in 2 separate packages and handle
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
>> symlink with update-alternatives
>>
>> most MACHINEs won't install either of these packages and those which need
>> it will pull the right one (e.g. through MACHINE_EXTRA_RRECOMMENDS).
>>
>> In worst case someone will try to install both packages and based on u-a
>> priority one of them will win (use higher priority for the more common
>> version).
>>
>> Cheers,
>>
>> On Fri, Aug 24, 2018 at 4:53 AM Andre McCurdy > > wrote:
>>
>> On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin > > wrote:
>> >
>> > So now the ln issue is resolved, I'm not convinced my
>> MACHINEOVERRIDES is
>> > the correct approach. Does anyone have any feedback on how I can
>> improve
>> > that?
>>
>> If you want to make a configurable symlink then perhaps the more usual
>> approach would be to just use a variable in the linux-firmware recipe
>> to weakly define a default target for the symlink. Machine config
>> files could then either do nothing (ie use the default) or provide
>> their own value. For example, in the linux-firmware recipe:
>>
>>BCM43430_NVRAM_SYMLINK ?= "brcmfmac43430-sdio.AP6212.txt"
>>
>>FILES_${PN}-bcm43430-nvram = " \
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt
>> \
>> ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
>> \
>>"
>>
>>do_install() {
>> ...
>> ln -sf ${BCM43430_NVRAM_SYMLINK}
>> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
>>}
>>
>> And then in the machine config files of machines which need the MUR1DX
>> firmware instead of the default, add:
>>
>>BCM43430_NVRAM_SYMLINK = "brcmfmac43430-sdio.MUR1DX.txt"
>>
>> However... note that currently the linux-firmware recipe is
>> architecture independent (ie it won't be rebuilt if the target is
>> changed). Adding a machine specific symlink is going to cause problems
>> with that, so the above is still not a full solution.
>>
>>
>>
>>
> --
> ___
> 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] [RFC PATCH 6/6] ca-certificates: update to 20180409
From: Alexander Kanavin
License-Update: URI fix
Signed-off-by: Alexander Kanavin
---
.../{ca-certificates_20170717.bb => ca-certificates_20180409.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/ca-certificates/{ca-certificates_20170717.bb =>
ca-certificates_20180409.bb} (95%)
diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
b/meta/recipes-support/ca-certificates/ca-certificates_20180409.bb
similarity index 95%
rename from meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
rename to meta/recipes-support/ca-certificates/ca-certificates_20180409.bb
index 24d3a6e..0d57083 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20180409.bb
@@ -5,7 +5,7 @@ This derived from Debian's CA Certificates."
HOMEPAGE = "http://packages.debian.org/sid/ca-certificates;
SECTION = "misc"
LICENSE = "GPL-2.0+ & MPL-2.0"
-LIC_FILES_CHKSUM =
"file://debian/copyright;md5=e7358b9541ccf3029e9705ed8de57968"
+LIC_FILES_CHKSUM =
"file://debian/copyright;md5=aeb420429b1659507e0a5a1b123e8308"
# This is needed to ensure we can run the postinst at image creation time
DEPENDS = ""
@@ -14,7 +14,7 @@ DEPENDS_class-nativesdk = "openssl-native"
# Need c_rehash from openssl and run-parts from debianutils
PACKAGE_WRITE_DEPS += "openssl-native debianutils-native"
-SRCREV = "34b8e19e541b8af4076616b2e170c7a70cdaded0"
+SRCREV = "dbbd11e56af93bb79f21d0ee6059a901f83f70a5"
SRC_URI = "git://salsa.debian.org/debian/ca-certificates.git;protocol=https \
file://0002-update-ca-certificates-use-SYSROOT.patch \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 5/6] openssh: depend on libressl
From: Alexander Kanavin
Please see the previous commit for the libressl rationale.
Signed-off-by: Alexander Kanavin
---
meta/recipes-connectivity/openssh/openssh_7.7p1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
index b3da5f6..db5e437 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
@@ -9,7 +9,7 @@ LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://LICENCE;md5=429658c6612f3a9b1293782366ab29d8"
# openssl 1.1 patches are proposed at
https://github.com/openssh/openssh-portable/pull/48
-DEPENDS = "zlib openssl10"
+DEPENDS = "zlib libressl"
DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
SRC_URI =
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.gz \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 4/6] libressl: add a recipe to support openssh
From: Alexander Kanavin
After reading through this:
https://github.com/openssh/openssh-portable/pull/48
and this thread:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html
I've concluded that this is the best of the three not-great options. The
alternatives:
- bundle libressl inside openssh packages
- keep openssh dependent on openssl 1.0 and wait until upstream does something
are both inferior. Libressl is used with openssh in OpenBSD and in OS X,
so it did get at least some testing in the real world.
Signed-off-by: Alexander Kanavin
---
meta/conf/distro/include/maintainers.inc | 1 +
...c-libraries-with-their-library-dependenci.patch | 73 ++
.../libressl/libressl_2.8.0.bb | 35 +++
3 files changed, 109 insertions(+)
create mode 100644
meta/recipes-connectivity/libressl/libressl/0001-Link-dynamic-libraries-with-their-library-dependenci.patch
create mode 100644 meta/recipes-connectivity/libressl/libressl_2.8.0.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index c76f81f..de4f9af 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -344,6 +344,7 @@ RECIPE_MAINTAINER_pn-libpng = "Maxin B. John
"
RECIPE_MAINTAINER_pn-libproxy = "Maxin B. John "
RECIPE_MAINTAINER_pn-libpthread-stubs = "Alexander Kanavin
"
RECIPE_MAINTAINER_pn-librepo = "Alexander Kanavin "
+RECIPE_MAINTAINER_pn-libressl = "Alexander Kanavin "
RECIPE_MAINTAINER_pn-librsvg = "Maxin B. John "
RECIPE_MAINTAINER_pn-libsamplerate0 = "Tanu Kaskinen "
RECIPE_MAINTAINER_pn-libsdl = "Yi Zhao "
diff --git
a/meta/recipes-connectivity/libressl/libressl/0001-Link-dynamic-libraries-with-their-library-dependenci.patch
b/meta/recipes-connectivity/libressl/libressl/0001-Link-dynamic-libraries-with-their-library-dependenci.patch
new file mode 100644
index 000..50b795d
--- /dev/null
+++
b/meta/recipes-connectivity/libressl/libressl/0001-Link-dynamic-libraries-with-their-library-dependenci.patch
@@ -0,0 +1,73 @@
+From 0dd486ba596fea07742a9317542bce27e18fd830 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin
+Date: Mon, 9 Apr 2018 18:02:56 +0300
+Subject: [PATCH] Link dynamic libraries with their library dependencies.
+
+It does seem like outside of OpenBSD, no one has actually used libressl yet.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin
+
+---
+ CMakeLists.txt| 5 +
+ crypto/CMakeLists.txt | 1 +
+ ssl/CMakeLists.txt| 2 +-
+ 3 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 549849f..0f9d8f5 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -266,15 +266,19 @@ set(OPENSSL_LIBS tls ssl crypto)
+
+ # Add additional required libs
+ if(WIN32)
++ set(OPENSSL_LIB_LIBS ws2_32)
+ set(OPENSSL_LIBS ${OPENSSL_LIBS} ws2_32)
+ endif()
+ if(CMAKE_SYSTEM_NAME MATCHES "Linux")
++ set(OPENSSL_LIB_LIBS pthread)
+ set(OPENSSL_LIBS ${OPENSSL_LIBS} pthread)
+ endif()
+ if(CMAKE_SYSTEM_NAME MATCHES "HP-UX")
++ set(OPENSSL_LIB_LIBS pthread)
+ set(OPENSSL_LIBS ${OPENSSL_LIBS} pthread)
+ endif()
+ if(CMAKE_SYSTEM_NAME MATCHES "SunOS")
++ set(OPENSSL_LIB_LIBS nsl socket)
+ set(OPENSSL_LIBS ${OPENSSL_LIBS} nsl socket)
+ endif()
+
+@@ -282,6 +286,7 @@ if(CMAKE_SYSTEM_NAME MATCHES "Linux")
+ # Check if we need -lrt to get clock_gettime on Linux
+ check_library_exists(rt clock_gettime "time.h" HAVE_CLOCK_GETTIME)
+ if (HAVE_CLOCK_GETTIME)
++ set(OPENSSL_LIB_LIBS ${OPENSSL_LIB_LIBS} rt)
+ set(OPENSSL_LIBS ${OPENSSL_LIBS} rt)
+ endif()
+ else()
+diff --git a/crypto/CMakeLists.txt b/crypto/CMakeLists.txt
+index 90e127e..08eceda 100644
+--- a/crypto/CMakeLists.txt
b/crypto/CMakeLists.txt
+@@ -813,6 +813,7 @@ target_include_directories(crypto
+ ../include)
+
+ if (BUILD_SHARED_LIBS)
++ target_link_libraries(crypto ${OPENSSL_LIB_LIBS})
+ export_symbol(crypto ${CMAKE_CURRENT_BINARY_DIR}/crypto_p.sym)
+ if (WIN32)
+ target_link_libraries(crypto Ws2_32.lib)
+diff --git a/ssl/CMakeLists.txt b/ssl/CMakeLists.txt
+index 1a559e6..ed17223 100644
+--- a/ssl/CMakeLists.txt
b/ssl/CMakeLists.txt
+@@ -51,7 +51,7 @@ target_include_directories(ssl
+
+ if (BUILD_SHARED_LIBS)
+ export_symbol(ssl ${CMAKE_CURRENT_SOURCE_DIR}/ssl.sym)
+- target_link_libraries(ssl crypto)
++ target_link_libraries(ssl crypto ${OPENSSL_LIB_LIBS})
+ if (WIN32)
+ target_link_libraries(ssl Ws2_32.lib)
+ set(SSL_POSTFIX -${SSL_MAJOR_VERSION})
diff --git a/meta/recipes-connectivity/libressl/libressl_2.8.0.bb
b/meta/recipes-connectivity/libressl/libressl_2.8.0.bb
new file mode 100644
index 000..b45f16a
--- /dev/null
+++ b/meta/recipes-connectivity/libressl/libressl_2.8.0.bb
@@ -0,0 +1,35 @@
+SUMMARY = "Drop-in replacement for
[OE-core] [RFC PATCH 2/6] cryptodev-tests: port to openssl 1.1
From: Alexander Kanavin
This leaves openssh as the only recipe that requires openssl 1.0 (or libressl).
Signed-off-by: Alexander Kanavin
---
.../cryptodev/cryptodev-tests_1.9.bb | 3 +-
.../files/0001-Port-tests-to-openssl-1.1.patch | 103 +
2 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch
diff --git a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb
b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb
index 9afb3de..617db6c 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.9.bb
@@ -2,10 +2,11 @@ require cryptodev.inc
SUMMARY = "A test suite for /dev/crypto device driver"
-DEPENDS += "openssl10"
+DEPENDS += "openssl"
SRC_URI += " \
file://0001-Add-the-compile-and-install-rules-for-cryptodev-test.patch \
+file://0001-Port-tests-to-openssl-1.1.patch \
"
EXTRA_OEMAKE='KERNEL_DIR="${STAGING_EXECPREFIXDIR}" PREFIX="${D}"'
diff --git
a/meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch
b/meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch
new file mode 100644
index 000..c969126
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/0001-Port-tests-to-openssl-1.1.patch
@@ -0,0 +1,103 @@
+From 2fe4bdeb8cdd0b0f46d9caed807812855d51ea56 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin
+Date: Wed, 28 Mar 2018 20:11:05 +0300
+Subject: [PATCH] Port tests to openssl 1.1
+
+Upstream-Status: Accepted
[https://github.com/cryptodev-linux/cryptodev-linux/pull/36]
+Signed-off-by: Alexander Kanavin
+
+---
+ tests/openssl_wrapper.c | 33 +
+ 1 file changed, 33 insertions(+)
+
+diff --git a/tests/openssl_wrapper.c b/tests/openssl_wrapper.c
+index 038c58f..dea2496 100644
+--- a/tests/openssl_wrapper.c
b/tests/openssl_wrapper.c
+@@ -4,6 +4,7 @@
+ #include
+ #include
+ #include
++#include
+
+ //#define DEBUG
+
+@@ -23,10 +24,17 @@ enum ctx_type {
+ ctx_type_md,
+ };
+
++#if OPENSSL_VERSION_NUMBER >= 0x1010L
++union openssl_ctx {
++ HMAC_CTX *hmac;
++ EVP_MD_CTX *md;
++};
++#else
+ union openssl_ctx {
+ HMAC_CTX hmac;
+ EVP_MD_CTX md;
+ };
++#endif
+
+ struct ctx_mapping {
+ __u32 ses;
+@@ -63,6 +71,16 @@ static void remove_mapping(__u32 ses)
+ switch (mapping->type) {
+ case ctx_type_none:
+ break;
++#if OPENSSL_VERSION_NUMBER >= 0x1010L
++ case ctx_type_hmac:
++ dbgp("%s: calling HMAC_CTX_free\n", __func__);
++ HMAC_CTX_free(mapping->ctx.hmac);
++ break;
++ case ctx_type_md:
++ dbgp("%s: calling EVP_MD_CTX_free\n", __func__);
++ EVP_MD_CTX_free(mapping->ctx.md);
++ break;
++#else
+ case ctx_type_hmac:
+ dbgp("%s: calling HMAC_CTX_cleanup\n", __func__);
+ HMAC_CTX_cleanup(>ctx.hmac);
+@@ -71,6 +89,7 @@ static void remove_mapping(__u32 ses)
+ dbgp("%s: calling EVP_MD_CTX_cleanup\n", __func__);
+ EVP_MD_CTX_cleanup(>ctx.md);
+ break;
++#endif
+ }
+ memset(mapping, 0, sizeof(*mapping));
+ }
+@@ -127,10 +146,17 @@ static int openssl_hmac(struct session_op *sess, struct
crypt_op *cop)
+
+ mapping->ses = sess->ses;
+ mapping->type = ctx_type_hmac;
++#if OPENSSL_VERSION_NUMBER >= 0x1010L
++ ctx = mapping->ctx.hmac;
++
++ dbgp("calling HMAC_CTX_new");
++ ctx = HMAC_CTX_new();
++#else
+ ctx = >ctx.hmac;
+
+ dbgp("calling HMAC_CTX_init");
+ HMAC_CTX_init(ctx);
++#endif
+ dbgp("calling HMAC_Init_ex");
+ if (!HMAC_Init_ex(ctx, sess->mackey, sess->mackeylen,
+ sess_to_evp_md(sess), NULL)) {
+@@ -172,10 +198,17 @@ static int openssl_md(struct session_op *sess, struct
crypt_op *cop)
+
+ mapping->ses = sess->ses;
+ mapping->type = ctx_type_md;
++#if OPENSSL_VERSION_NUMBER >= 0x1010L
++ ctx = mapping->ctx.md;
++
++ dbgp("calling EVP_MD_CTX_new");
++ ctx = EVP_MD_CTX_new();
++#else
+ ctx = >ctx.md;
+
+ dbgp("calling EVP_MD_CTX_init");
+ EVP_MD_CTX_init(ctx);
++#endif
+ dbgp("calling EVP_DigestInit");
+ EVP_DigestInit(ctx, sess_to_evp_md(sess));
+ }
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 3/6] openssl: update to 1.1.1
At the moment 1.1.1 is in pre-release stage, however the final release
should be available within a few weeks. The major selling point is that
it supports the new TLS 1.3 specification. It will also be the new long
term support version. More information:
https://www.openssl.org/policies/releasestrat.html
Signed-off-by: Alexander Kanavin
---
...1-Take-linking-flags-from-LDFLAGS-env-var.patch | 43 --
...SLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch | 39
.../{openssl_1.1.0i.bb => openssl_1.1.1-pre9.bb} | 23 +++-
3 files changed, 14 insertions(+), 91 deletions(-)
delete mode 100644
meta/recipes-connectivity/openssl/openssl/0001-Take-linking-flags-from-LDFLAGS-env-var.patch
delete mode 100644
meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
rename meta/recipes-connectivity/openssl/{openssl_1.1.0i.bb =>
openssl_1.1.1-pre9.bb} (83%)
diff --git
a/meta/recipes-connectivity/openssl/openssl/0001-Take-linking-flags-from-LDFLAGS-env-var.patch
b/meta/recipes-connectivity/openssl/openssl/0001-Take-linking-flags-from-LDFLAGS-env-var.patch
deleted file mode 100644
index 6ce4e47..000
---
a/meta/recipes-connectivity/openssl/openssl/0001-Take-linking-flags-from-LDFLAGS-env-var.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 08face4353d80111973aba9c1304c92158cfad0e Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin
-Date: Tue, 28 Mar 2017 16:40:12 +0300
-Subject: [PATCH] Take linking flags from LDFLAGS env var
-
-This fixes "No GNU_HASH in the elf binary" issues.
-
-Upstream-Status: Inappropriate [oe-core specific]
-Signed-off-by: Alexander Kanavin
- Configurations/unix-Makefile.tmpl | 2 +-
- Configure | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/Configurations/unix-Makefile.tmpl
b/Configurations/unix-Makefile.tmpl
-index c029817..43b769b 100644
a/Configurations/unix-Makefile.tmpl
-+++ b/Configurations/unix-Makefile.tmpl
-@@ -173,7 +173,7 @@ CROSS_COMPILE= {- $config{cross_compile_prefix} -}
- CC= $(CROSS_COMPILE){- $target{cc} -}
- CFLAGS={- our $cflags2 = join(" ",(map { "-D".$_} @{$target{defines}},
@{$config{defines}}),"-DOPENSSLDIR=\"\\\"\$(OPENSSLDIR)\\\"\"","-DENGINESDIR=\"\\\"\$(ENGINESDIR)\\\"\"")
-} {- $target{cflags} -} {- $config{cflags} -}
- CFLAGS_Q={- $cflags2 =~ s|([\\"])|\\$1|g; $cflags2 -} {- $config{cflags} -}
--LDFLAGS= {- $target{lflags} -}
-+LDFLAGS= {- $target{lflags}." ".$ENV{'LDFLAGS'} -}
- PLIB_LDFLAGS= {- $target{plib_lflags} -}
- EX_LIBS= {- $target{ex_libs} -} {- $config{ex_libs} -}
- LIB_CFLAGS={- $target{shared_cflag} || "" -}
-diff --git a/Configure b/Configure
-index aee7cc3..274d236 100755
a/Configure
-+++ b/Configure
-@@ -979,7 +979,7 @@ $config{build_file} = $target{build_file};
- $config{defines} = [];
- $config{cflags} = "";
- $config{ex_libs} = "";
--$config{shared_ldflag} = "";
-+$config{shared_ldflag} = $ENV{'LDFLAGS'};
-
- # Make sure build_scheme is consistent.
- $target{build_scheme} = [ $target{build_scheme} ]
---
-2.11.0
-
diff --git
a/meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
b/meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
deleted file mode 100644
index 67d06fc..000
---
a/meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From 26e98beb8a987cdc69699aaffc5599926fb1b293 Mon Sep 17 00:00:00 2001
-From: Andre McCurdy
-Date: Fri, 17 Aug 2018 20:33:44 -0700
-Subject: [PATCH] allow OPENSSLDIR and ENGINESDIR CFLAGS to be controlled
-
-Upstream-Status: Inappropriate [OE Specific]
-
-Signed-off-by: Andre McCurdy
- Configurations/unix-Makefile.tmpl | 6 +-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
-diff --git a/Configurations/unix-Makefile.tmpl
b/Configurations/unix-Makefile.tmpl
-index 034d93e..2310d12 100644
a/Configurations/unix-Makefile.tmpl
-+++ b/Configurations/unix-Makefile.tmpl
-@@ -156,6 +156,10 @@ LIBDIR={- #
- ENGINESDIR={- use File::Spec::Functions;
- catdir($prefix,$libdir,"engines-$sover") -}
-
-+# Intermediate variables so the values defined via CFLAGS can be controlled.
-+OE_DOPENSSLDIR=$(OPENSSLDIR)
-+OE_DENGINESDIR=$(ENGINESDIR)
-+
- # Convenience variable for those who want to set the rpath in shared
- # libraries and applications
- LIBRPATH=$(INSTALLTOP)/$(LIBDIR)
-@@ -174,7 +178,7 @@ HTMLSUFFIX=html
-
- CROSS_COMPILE= {- $config{cross_compile_prefix} -}
- CC= $(CROSS_COMPILE){- $target{cc} -}
--CFLAGS={- our $cflags2 = join(" ",(map { "-D".$_} @{$target{defines}},
@{$config{defines}}),"-DOPENSSLDIR=\"\\\"\$(OPENSSLDIR)\\\"\"","-DENGINESDIR=\"\\\"\$(ENGINESDIR)\\\"\"")
-} {- $target{cflags} -} {- $config{cflags} -}
-+CFLAGS={- our $cflags2 = join(" ",(map { "-D".$_} @{$target{defines}},
[OE-core] [RFC PATCH 1/6] openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the default version
From: Alexander Kanavin
I believe the time has come to do this: openssl 1.0 upstream support stops at
the end
of 2019, and we do not want a situation where a supported YP release contains an
unsupported version of a critical security component.
Openssl 1.0 can still be utilized by depending on 'openssl10' recipe.
Signed-off-by: Alexander Kanavin
---
meta/conf/distro/include/default-versions.inc | 3 ---
meta/conf/distro/include/maintainers.inc | 1 +
.../{openssl => files}/environment.d-openssl.sh| 0
...build-with-clang-using-external-assembler.patch | 0
.../0001-allow-manpages-to-be-disabled.patch | 0
...penssl-force-soft-link-to-avoid-rare-race.patch | 0
.../Makefiles-ptest.patch | 0
.../Use-SHA256-not-MD5-as-default-digest.patch | 0
.../configure-musl-target.patch| 0
.../configure-targets.patch| 0
.../debian/c_rehash-compat.patch | 0
.../debian/debian-targets.patch| 0
.../debian/man-dir.patch | 0
.../debian/man-section.patch | 0
.../debian/no-rpath.patch | 0
.../debian/no-symbolic.patch | 0
.../{openssl-1.0.2p => openssl10}/debian/pic.patch | 0
.../debian1.0.2/block_digicert_malaysia.patch | 0
.../debian1.0.2/block_diginotar.patch | 0
.../debian1.0.2/soname.patch | 0
.../debian1.0.2/version-script.patch | 0
.../engines-install-in-libdir-ssl.patch| 0
.../{openssl-1.0.2p => openssl10}/oe-ldflags.patch | 0
.../openssl-c_rehash.sh| 0
.../openssl-fix-des.pod-error.patch| 0
.../openssl_fix_for_x32.patch | 0
.../{openssl-1.0.2p => openssl10}/parallel.patch | 0
.../{openssl-1.0.2p => openssl10}/ptest-deps.patch | 0
.../ptest_makefile_deps.patch | 0
.../reproducible-cflags.patch | 0
.../reproducible-mkbuildinf.patch | 0
.../{openssl-1.0.2p => openssl10}/run-ptest| 0
.../shared-libs.patch | 0
.../{openssl_1.0.2p.bb => openssl10_1.0.2p.bb} | 31 --
34 files changed, 24 insertions(+), 11 deletions(-)
rename meta/recipes-connectivity/openssl/{openssl =>
files}/environment.d-openssl.sh (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/0001-Fix-build-with-clang-using-external-assembler.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/0001-allow-manpages-to-be-disabled.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/0001-openssl-force-soft-link-to-avoid-rare-race.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/Makefiles-ptest.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/Use-SHA256-not-MD5-as-default-digest.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/configure-musl-target.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/configure-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/c_rehash-compat.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/debian-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/man-dir.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/man-section.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/no-rpath.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/no-symbolic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/pic.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian1.0.2/block_digicert_malaysia.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian1.0.2/block_diginotar.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian1.0.2/soname.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian1.0.2/version-script.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/engines-install-in-libdir-ssl.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/oe-ldflags.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/openssl-c_rehash.sh (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/openssl-fix-des.pod-error.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
[OE-core] [RFC PATCH 0/6] openssl 1.1.1 update
This patch series updates openssl to the soon-to-be released 1.1.1 version
(latest news is 11 September), sets it as default, and removes dependencies
on openssl 1.0 entirely from oe-core. openssl 1.0 remains available as openssl10
recipe.
The following changes since commit a8368651ffed1bd6c4715a37dfe9f40c48ca23c4:
bitbake: fetcher: Fixed remote removal not throwing exception. (2018-08-28
10:32:08 +0100)
are available in the git repository at:
git://push.yoctoproject.org/poky-contrib akanavin/openssl-1.1.1
Alexander Kanavin (6):
openssl: rename openssl 1.0.x to openssl10 and make openssl 1.1.x the
default version
cryptodev-tests: port to openssl 1.1
openssl: update to 1.1.1
libressl: add a recipe to support openssh
openssh: depend on libressl
ca-certificates: update to 20180409
meta/conf/distro/include/default-versions.inc | 3 -
meta/conf/distro/include/maintainers.inc | 2 +
...c-libraries-with-their-library-dependenci.patch | 73 +++
.../libressl/libressl_2.8.0.bb | 35 +++
meta/recipes-connectivity/openssh/openssh_7.7p1.bb | 2 +-
.../{openssl => files}/environment.d-openssl.sh| 0
...1-Take-linking-flags-from-LDFLAGS-env-var.patch | 43 -
...SLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch | 39
...build-with-clang-using-external-assembler.patch | 0
.../0001-allow-manpages-to-be-disabled.patch | 0
...penssl-force-soft-link-to-avoid-rare-race.patch | 0
.../Makefiles-ptest.patch | 0
.../Use-SHA256-not-MD5-as-default-digest.patch | 0
.../configure-musl-target.patch| 0
.../configure-targets.patch| 0
.../debian/c_rehash-compat.patch | 0
.../debian/debian-targets.patch| 0
.../debian/man-dir.patch | 0
.../debian/man-section.patch | 0
.../debian/no-rpath.patch | 0
.../debian/no-symbolic.patch | 0
.../{openssl-1.0.2p => openssl10}/debian/pic.patch | 0
.../debian1.0.2/block_digicert_malaysia.patch | 0
.../debian1.0.2/block_diginotar.patch | 0
.../debian1.0.2/soname.patch | 0
.../debian1.0.2/version-script.patch | 0
.../engines-install-in-libdir-ssl.patch| 0
.../{openssl-1.0.2p => openssl10}/oe-ldflags.patch | 0
.../openssl-c_rehash.sh| 0
.../openssl-fix-des.pod-error.patch| 0
.../openssl_fix_for_x32.patch | 0
.../{openssl-1.0.2p => openssl10}/parallel.patch | 0
.../{openssl-1.0.2p => openssl10}/ptest-deps.patch | 0
.../ptest_makefile_deps.patch | 0
.../reproducible-cflags.patch | 0
.../reproducible-mkbuildinf.patch | 0
.../{openssl-1.0.2p => openssl10}/run-ptest| 0
.../shared-libs.patch | 0
.../{openssl_1.0.2p.bb => openssl10_1.0.2p.bb} | 31 +--
.../{openssl_1.1.0i.bb => openssl_1.1.1-pre9.bb} | 23 +++--
.../cryptodev/cryptodev-tests_1.9.bb | 3 +-
.../files/0001-Port-tests-to-openssl-1.1.patch | 103 +
...tes_20170717.bb => ca-certificates_20180409.bb} | 4 +-
43 files changed, 255 insertions(+), 106 deletions(-)
create mode 100644
meta/recipes-connectivity/libressl/libressl/0001-Link-dynamic-libraries-with-their-library-dependenci.patch
create mode 100644 meta/recipes-connectivity/libressl/libressl_2.8.0.bb
rename meta/recipes-connectivity/openssl/{openssl =>
files}/environment.d-openssl.sh (100%)
delete mode 100644
meta/recipes-connectivity/openssl/openssl/0001-Take-linking-flags-from-LDFLAGS-env-var.patch
delete mode 100644
meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/0001-Fix-build-with-clang-using-external-assembler.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/0001-allow-manpages-to-be-disabled.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/0001-openssl-force-soft-link-to-avoid-rare-race.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/Makefiles-ptest.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/Use-SHA256-not-MD5-as-default-digest.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/configure-musl-target.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/configure-targets.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
openssl10}/debian/c_rehash-compat.patch (100%)
rename meta/recipes-connectivity/openssl/{openssl-1.0.2p =>
[OE-core] ✗ patchtest: failure for ca-certificates:update to 20180409 (rev3)
== Series Details == Series: ca-certificates:update to 20180409 (rev3) Revision: 3 URL : https://patchwork.openembedded.org/series/13775/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Patches not removed from tree [test_src_uri_left_files] Suggested fixAmend the patch containing the software patch file removal Patch0001-Drop-introspection-macros-from-acinclude.m4.patch If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for ca-certificates:update to 20180409
== Series Details == Series: ca-certificates:update to 20180409 Revision: 1 URL : https://patchwork.openembedded.org/series/13775/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue LIC_FILES_CHKSUM changed on target ca-certificates but there is no "License-Update" tag in commit message [test_lic_files_chksum_modified_not_mentioned] Suggested fixInclude "License-Update: " into the commit message with a brief description Current checksum file://debian/copyright;md5=e7358b9541ccf3029e9705ed8de57968 New checksum file://debian/copyright;md5=aeb420429b1659507e0a5a1b123e8308 If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] [PATCH]ca-certificates:update to 20180409
2018-08-28 11:43 GMT+02:00 Hong Liu : > 1.Upgrade ca-certificates from 20170717 to 20180409. The new version of ca-certificates requires openssl 1.1. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] test-result-log: testcase management tool to store test result
These scripts were developed as an alternative testcase management
tool to Testopia. Using these scripts, user can store test result
from OEQA automated testcase execution.
These scripts will store test result & log in GIT repository.
To use these scripts, first source oe environment, then run the
entry point script to look for help.
$ test-result-log
To store test result for OEQA automated testcase, execute the below
$ test-result-log store-auto /
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/testresultlog/__init__.py | 1 +
scripts/lib/testresultlog/gitstore.py | 250 ++
scripts/lib/testresultlog/oeqalogparser.py| 97 ++
scripts/lib/testresultlog/oeqatestdiscover.py | 51 ++
scripts/lib/testresultlog/storeauto.py| 125 +
scripts/test-result-log | 97 ++
6 files changed, 621 insertions(+)
create mode 100644 scripts/lib/testresultlog/__init__.py
create mode 100644 scripts/lib/testresultlog/gitstore.py
create mode 100644 scripts/lib/testresultlog/oeqalogparser.py
create mode 100644 scripts/lib/testresultlog/oeqatestdiscover.py
create mode 100644 scripts/lib/testresultlog/storeauto.py
create mode 100755 scripts/test-result-log
diff --git a/scripts/lib/testresultlog/__init__.py
b/scripts/lib/testresultlog/__init__.py
new file mode 100644
index 000..d3f5a12
--- /dev/null
+++ b/scripts/lib/testresultlog/__init__.py
@@ -0,0 +1 @@
+
diff --git a/scripts/lib/testresultlog/gitstore.py
b/scripts/lib/testresultlog/gitstore.py
new file mode 100644
index 000..866d7d6
--- /dev/null
+++ b/scripts/lib/testresultlog/gitstore.py
@@ -0,0 +1,250 @@
+# test case management tool - store test result to git repository
+#
+# Copyright (c) 2018, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+# more details.
+#
+import tempfile
+import os
+import pathlib
+import json
+import subprocess
+import shutil
+import scriptpath
+scriptpath.add_bitbake_lib_path()
+scriptpath.add_oe_lib_path()
+from oeqa.utils.git import GitRepo, GitError
+
+class GitStore(object):
+
+def __init__(self):
+self.script_path = os.path.dirname(os.path.realpath(__file__))
+self.base_path = self.script_path + '/../../..'
+
+def _get_project_environment_directory_path(self, project_dir,
test_environment_list):
+project_env_dir = project_dir
+for env in test_environment_list:
+project_env_dir = os.path.join(project_env_dir, env)
+return project_env_dir
+
+def _get_testmodule_list(self, testmodule_testsuite_dict):
+return sorted(list(testmodule_testsuite_dict.keys()))
+
+def _get_testcase_list(self, testsuite_list, testsuite_testcase_dict):
+testcase_list = []
+for testsuite in sorted(testsuite_list):
+if testsuite in testsuite_testcase_dict:
+for testcase in testsuite_testcase_dict[testsuite]:
+testcase_list.append(testcase)
+return testcase_list
+
+def _get_testcase_status(self, testcase, testcase_status_dict):
+if testcase in testcase_status_dict:
+return testcase_status_dict[testcase]
+return ""
+
+def _create_testcase_dict(self, testcase_list, testcase_status_dict):
+testcase_dict = {}
+for testcase in sorted(testcase_list):
+testcase_status = self._get_testcase_status(testcase,
testcase_status_dict)
+testcase_dict[testcase] = {"testresult": testcase_status,"bugs":
""}
+return testcase_dict
+
+def _create_testsuite_testcase_teststatus_json_object(self,
testsuite_list, testsuite_testcase_dict, testcase_status_dict):
+json_object = {'testsuite':{}}
+testsuite_dict = json_object['testsuite']
+for testsuite in sorted(testsuite_list):
+testsuite_dict[testsuite] = {'testcase': {}}
+testsuite_dict[testsuite]['testcase'] =
self._create_testcase_dict(testsuite_testcase_dict[testsuite],
testcase_status_dict)
+return json_object
+
+def _create_testsuite_json_formatted_string(self, testsuite_list,
testsuite_testcase_dict, testcase_status_dict):
+testsuite_testcase_list =
self._create_testsuite_testcase_teststatus_json_object(testsuite_list,
testsuite_testcase_dict, testcase_status_dict)
+return json.dumps(testsuite_testcase_list, sort_keys=True, indent=4)
+
+def _write_testsuite_testcase_json_formatted_string_to_file(self,
file_path, file_content):
+with open(file_path, 'w') as the_file:
+
Re: [OE-core] [PATCH] [PATCH] pango:1.40.14 -> 1.42.4
Hi,
On Tue, Aug 28, 2018 at 05:43:17PM +0800, Hong Liu wrote:
> 1.Upgrade pango from 1.40.14 to 1.42.4
>
> 2.Add new depends fribidi
>
> Signed-off-by: Hong Liu
> ---
> meta/recipes-graphics/pango/{pango_1.40.14.bb => pango_1.42.4.bb} | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
> rename meta/recipes-graphics/pango/{pango_1.40.14.bb => pango_1.42.4.bb}
> (87%)
>
> diff --git a/meta/recipes-graphics/pango/pango_1.40.14.bb
> b/meta/recipes-graphics/pango/pango_1.42.4.bb
> similarity index 87%
> rename from meta/recipes-graphics/pango/pango_1.40.14.bb
> rename to meta/recipes-graphics/pango/pango_1.42.4.bb
> index 3bd9c64..d889431 100644
> --- a/meta/recipes-graphics/pango/pango_1.40.14.bb
> +++ b/meta/recipes-graphics/pango/pango_1.42.4.bb
> @@ -14,13 +14,12 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
> inherit gnomebase gtk-doc ptest-gnome upstream-version-is-even
> gobject-introspection
>
> SRC_URI += "file://run-ptest \
> -file://0001-Drop-introspection-macros-from-acinclude.m4.patch \
>
> file://0001-Enforce-recreation-of-docs-pango.types-it-is-build-c.patch \
> "
> -SRC_URI[archive.md5sum] = "18d7eb8d52e7e445e733c109ddaa7b78"
> -SRC_URI[archive.sha256sum] =
> "90af1beaa7bf9e4c52db29ec251ec4fd0a8f2cc185d521ad1f88d01b3a6a17e3"
> +SRC_URI[archive.md5sum] = "deb171a31a3ad76342d5195a1b5bbc7c"
> +SRC_URI[archive.sha256sum] =
> "1d2b74cd63e8bd41961f2f8d952355aa0f9be6002b52c8aa7699d9f5da597c9d"
>
> -DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv
> cairo harfbuzz"
> +DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv
> cairo harfbuzz fribidi"
>
> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> PACKAGECONFIG[x11] = "--with-xft,--without-xft,virtual/libx11 libxft"
ERROR: Nothing PROVIDES 'fribidi' (but
/home/maxin/poky/meta/recipes-graphics/pango/pango_1.42.4.bb DEPENDS on or
otherwise requires it)
ERROR: Required build target 'pango' has no buildable providers.
Missing or unbuildable dependency chain was: ['pango', 'fribidi']
Can we move fribidi dependency to another PACKAGECONFIG ?
Best Regards,
Maxin
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH]python-setuptools:upgrade to 40.2.0
Upgrade python-setuptools from 40.0.0 to 40.2.0
Signed-off-by: Hong Liu
---
meta/recipes-devtools/python/python-setuptools.inc| 4 ++--
.../{python-setuptools_40.0.0.bb => python-setuptools_40.2.0.bb} | 0
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python-setuptools_40.0.0.bb =>
python-setuptools_40.2.0.bb} (100%)
diff --git a/meta/recipes-devtools/python/python-setuptools.inc
b/meta/recipes-devtools/python/python-setuptools.inc
index 315ba31..c3924b0 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -10,8 +10,8 @@ inherit pypi
SRC_URI_append_class-native = "
file://0001-conditionally-do-not-fetch-code-by-easy_install.patch"
-SRC_URI[md5sum] = "260630ae1a64bafa39dcc53404d63829"
-SRC_URI[sha256sum] =
"012adb8e25fbfd64c652e99e7bab58799a3aaf05d39ab38561f69190a909015f"
+SRC_URI[md5sum] = "592efabea3a65d8e97a025ed52f69b12"
+SRC_URI[sha256sum] =
"47881d54ede4da9c15273bac65f9340f8929d4f0213193fa7894be384f2dcfa6"
DEPENDS += "${PYTHON_PN}"
diff --git a/meta/recipes-devtools/python/python-setuptools_40.0.0.bb
b/meta/recipes-devtools/python/python-setuptools_40.2.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python-setuptools_40.0.0.bb
rename to meta/recipes-devtools/python/python-setuptools_40.2.0.bb
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] pango:1.40.14 -> 1.42.4
1.Upgrade pango from 1.40.14 to 1.42.4
2.Add new depends fribidi
Signed-off-by: Hong Liu
---
meta/recipes-graphics/pango/{pango_1.40.14.bb => pango_1.42.4.bb} | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
rename meta/recipes-graphics/pango/{pango_1.40.14.bb => pango_1.42.4.bb} (87%)
diff --git a/meta/recipes-graphics/pango/pango_1.40.14.bb
b/meta/recipes-graphics/pango/pango_1.42.4.bb
similarity index 87%
rename from meta/recipes-graphics/pango/pango_1.40.14.bb
rename to meta/recipes-graphics/pango/pango_1.42.4.bb
index 3bd9c64..d889431 100644
--- a/meta/recipes-graphics/pango/pango_1.40.14.bb
+++ b/meta/recipes-graphics/pango/pango_1.42.4.bb
@@ -14,13 +14,12 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
inherit gnomebase gtk-doc ptest-gnome upstream-version-is-even
gobject-introspection
SRC_URI += "file://run-ptest \
-file://0001-Drop-introspection-macros-from-acinclude.m4.patch \
file://0001-Enforce-recreation-of-docs-pango.types-it-is-build-c.patch \
"
-SRC_URI[archive.md5sum] = "18d7eb8d52e7e445e733c109ddaa7b78"
-SRC_URI[archive.sha256sum] =
"90af1beaa7bf9e4c52db29ec251ec4fd0a8f2cc185d521ad1f88d01b3a6a17e3"
+SRC_URI[archive.md5sum] = "deb171a31a3ad76342d5195a1b5bbc7c"
+SRC_URI[archive.sha256sum] =
"1d2b74cd63e8bd41961f2f8d952355aa0f9be6002b52c8aa7699d9f5da597c9d"
-DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv cairo
harfbuzz"
+DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv cairo
harfbuzz fribidi"
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
PACKAGECONFIG[x11] = "--with-xft,--without-xft,virtual/libx11 libxft"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH]ca-certificates:update to 20180409
1.Upgrade ca-certificates from 20170717 to 20180409.
2.Modify debain homepage from http to https
Signed-off-by: Hong Liu
---
.../{ca-certificates_20170717.bb => ca-certificates_20180409.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/ca-certificates/{ca-certificates_20170717.bb =>
ca-certificates_20180409.bb} (95%)
diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
b/meta/recipes-support/ca-certificates/ca-certificates_20180409.bb
similarity index 95%
rename from meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
rename to meta/recipes-support/ca-certificates/ca-certificates_20180409.bb
index 24d3a6e..0d57083 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20180409.bb
@@ -5,7 +5,7 @@ This derived from Debian's CA Certificates."
HOMEPAGE = "http://packages.debian.org/sid/ca-certificates;
SECTION = "misc"
LICENSE = "GPL-2.0+ & MPL-2.0"
-LIC_FILES_CHKSUM =
"file://debian/copyright;md5=e7358b9541ccf3029e9705ed8de57968"
+LIC_FILES_CHKSUM =
"file://debian/copyright;md5=aeb420429b1659507e0a5a1b123e8308"
# This is needed to ensure we can run the postinst at image creation time
DEPENDS = ""
@@ -14,7 +14,7 @@ DEPENDS_class-nativesdk = "openssl-native"
# Need c_rehash from openssl and run-parts from debianutils
PACKAGE_WRITE_DEPS += "openssl-native debianutils-native"
-SRCREV = "34b8e19e541b8af4076616b2e170c7a70cdaded0"
+SRCREV = "dbbd11e56af93bb79f21d0ee6059a901f83f70a5"
SRC_URI = "git://salsa.debian.org/debian/ca-certificates.git;protocol=https \
file://0002-update-ca-certificates-use-SYSROOT.patch \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libcroco: patch for CVE-2017-7960
From: Changqing Li
Signed-off-by: Changqing Li
---
.../libcroco/libcroco/CVE-2017-7960.patch | 56 ++
meta/recipes-support/libcroco/libcroco_0.6.12.bb | 2 +
2 files changed, 58 insertions(+)
create mode 100644 meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch
diff --git a/meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch
b/meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch
new file mode 100644
index 000..f6f43c3
--- /dev/null
+++ b/meta/recipes-support/libcroco/libcroco/CVE-2017-7960.patch
@@ -0,0 +1,56 @@
+input: check end of input before reading a byte
+
+When reading bytes we weren't check that the index wasn't
+out of bound and this could produce an invalid read which
+could deal to a security bug.
+
+Upstream-Status: Backport[https://gitlab.gnome.org/GNOME/libcroco/
+ commit/898e3a8c8c0314d2e6b106809a8e3e93cf9d4394]
+
+CVE: CVE-2017-7960
+
+Signed-off-by: Changqing Li
+
+diff --git a/src/cr-input.c b/src/cr-input.c
+index
49000b1f5f07fe057135f1b8fc69bdcf9613e300..3b63a88ee3b1c56778e58172d147d958951bf099
100644
+--- a/src/cr-input.c
b/src/cr-input.c
+@@ -256,7 +256,7 @@ cr_input_new_from_uri (const gchar * a_file_uri, enum
CREncoding a_enc)
+ *we should free buf here because it's own by CRInput.
+ *(see the last parameter of cr_input_new_from_buf().
+ */
+-buf = NULL ;
++buf = NULL;
+ }
+
+ cleanup:
+@@ -404,6 +404,8 @@ cr_input_get_nb_bytes_left (CRInput const * a_this)
+ enum CRStatus
+ cr_input_read_byte (CRInput * a_this, guchar * a_byte)
+ {
++gulong nb_bytes_left = 0;
++
+ g_return_val_if_fail (a_this && PRIVATE (a_this)
+ && a_byte, CR_BAD_PARAM_ERROR);
+
+@@ -413,6 +415,12 @@ cr_input_read_byte (CRInput * a_this, guchar * a_byte)
+ if (PRIVATE (a_this)->end_of_input == TRUE)
+ return CR_END_OF_INPUT_ERROR;
+
++nb_bytes_left = cr_input_get_nb_bytes_left (a_this);
++
++if (nb_bytes_left < 1) {
++return CR_END_OF_INPUT_ERROR;
++}
++
+ *a_byte = PRIVATE (a_this)->in_buf[PRIVATE (a_this)->next_byte_index];
+
+ if (PRIVATE (a_this)->nb_bytes -
+@@ -477,7 +485,6 @@ cr_input_read_char (CRInput * a_this, guint32 * a_char)
+ if (*a_char == '\n') {
+ PRIVATE (a_this)->end_of_line = TRUE;
+ }
+-
+ }
+
+ return status;
diff --git a/meta/recipes-support/libcroco/libcroco_0.6.12.bb
b/meta/recipes-support/libcroco/libcroco_0.6.12.bb
index d86ddd6..5b962ee 100644
--- a/meta/recipes-support/libcroco/libcroco_0.6.12.bb
+++ b/meta/recipes-support/libcroco/libcroco_0.6.12.bb
@@ -16,5 +16,7 @@ BINCONFIG = "${bindir}/croco-0.6-config"
inherit gnomebase gtk-doc binconfig-disabled
+SRC_URI += "file://CVE-2017-7960.patch"
+
SRC_URI[archive.md5sum] = "bc0984fce078ba2ce29f9500c6b9ddce"
SRC_URI[archive.sha256sum] =
"ddc4b5546c9fb4280a5017e2707fbd4839034ed1aba5b7d4372212f34f84f860"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] image_types_wic: Add variable WIC_EXTENSION
On Tue, 28 Aug 2018, Richard Purdie wrote:
> On Mon, 2018-08-27 at 17:31 +0300, Alexandru Vasiu wrote:
>> Used to specify what extention will have the image file which
>> is created using wic. The default value is wic. For creating an
>> ISO image, WIC_EXTENSION will be iso.
>>
>> Signed-off-by: Alexandru Vasiu
>> ---
>> meta/classes/image.bbclass | 2 ++
>> meta/classes/image_types_wic.bbclass | 3 ++-
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 024d2d4c96..c6833a6770 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -607,6 +607,8 @@ python create_symlinks() {
>> if not link_name:
>> return
>> for type in subimages:
>> +if type == 'wic':
>> +type = d.getVar('WIC_EXTENSION')
>> dst = os.path.join(deploy_dir, link_name + "." + type)
>> src = img_name + imgsuffix + type
>> if os.path.exists(os.path.join(deploy_dir, src)):
>
> This is hardcoding an image type specific issue into common code. I
> really want to avoid doing that.
>
> In the past I started the process of trying to untangle the spaghetti
> we had in image.bbclass and abstract it into common building blocks.
> The hope was to eventually have proper APIs around this.
>
> I never really got back to do further rounds of cleanup/improvement to
> get to that goal but the more image type specific pieces we add back
> in, the harder it will make those goals and the less maintainable the
> coed will become.
>
> So is there some other way we can handle this. It looks like we don't
> even use this iso mode in OE-Core which is bad from a testing
> perspective too? I don't see WIC_EXTENSION being set to iso anywhere?
Our problem is this: all WIC images built & symlinked under
${DEPLOY_DIR_IMAGE} have the extension .wic, including the iso's.
We want our build pipeline to output an iso directly after issuing
"bitbake " by adding IMAGE_FSTYPES += "wic" and having an
..wks which speficfies the isoimage-isohybrid plugin.
I agree this solution is hacky. An alternative would be to just rename
the image .wic extension to .iso in our piepline outside bitbake and be
done with it.
How about adding an IMAGE_FSTYPES += "iso" and creating the associated
logic/bbclasses? Is that amount of code justified to have .iso
extensions to wic-built images or are we better of just renaming .wic
to .iso?
>
> Cheers,
>
> Richard
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_mailman_listinfo_openembedded-2Dcore=DwICAg=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=fzwh7IUt7VYYiD6094geII0kSDP3DkEnN0B8zB62AxE=TX1s2gOuF5JVPXLJ60USSIym1ujQ2VDP00KcC-1c-_c=pYCCOX_mHEmd8jE8DN3zmrnoYuL35Wz_sA2MuuYDNrw=
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost: add ptest support
On Mon, 2018-08-27 at 20:57 -0400, Randy MacLeod wrote: > On 08/27/2018 06:17 PM, Yang Wang wrote: > > Not sure if it's worth to run the Ptest on QEMU though, I also run > > Ptest > > on SIMICS simulators, thousands of tests didn't get run, looks like > > the > > result was not good as well. > > > > Now my nightly Ptest runs on x86 device and gets consistent result > > every > > day: > > > > 2018-08-27T06:26 -- 2018-08-27T09:52 > > Passed: 40518 > > Failed: 289 > > Skipped: 1876 > > Consistent results are good and > 90% pass rate is very good. > What are the stats using qemux86-64 and/or simics? > > I don't expect that qemu results would be as close to real hardware > as Simics but it is quite good and freely available. I think this is an example of where we may need to start adding "stage 2" testing to the autobuilder. The first stage tests would be enough to get patches merged and be the faster ones, the second stage would be the longer running things which we'd only trigger when stage one had passed, maybe on milestone releases. We'd put off doing this due to the old creaking codebase. With the new autobuilder codebase, this should be much more straightforward to do... boost ptest would be something I'd put in the second stage. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] squashfs-tools: patch for CVE-2015-4645(4646)
From: Changqing Li
Signed-off-by: Changqing Li
---
...-squashfs-tools-patch-for-CVE-2015-4645-6.patch | 47 ++
.../squashfs-tools/squashfs-tools_git.bb | 1 +
2 files changed, 48 insertions(+)
create mode 100644
meta/recipes-devtools/squashfs-tools/squashfs-tools/0001-squashfs-tools-patch-for-CVE-2015-4645-6.patch
diff --git
a/meta/recipes-devtools/squashfs-tools/squashfs-tools/0001-squashfs-tools-patch-for-CVE-2015-4645-6.patch
b/meta/recipes-devtools/squashfs-tools/squashfs-tools/0001-squashfs-tools-patch-for-CVE-2015-4645-6.patch
new file mode 100644
index 000..2261ea9
--- /dev/null
+++
b/meta/recipes-devtools/squashfs-tools/squashfs-tools/0001-squashfs-tools-patch-for-CVE-2015-4645-6.patch
@@ -0,0 +1,47 @@
+From 3c0d67184d6edb63f3b7d6d5eb81531daa6388f3 Mon Sep 17 00:00:00 2001
+From: Changqing Li
+Date: Tue, 28 Aug 2018 16:25:36 +0800
+Subject: [PATCH] squashfs-tools: patch for CVE-2015-4645(6)
+
+Upstream-Status: Backport[https://github.com/devttys0/sasquatch/pull/
+ 5/commits/6777e08cc38bc780d27c69c1d8c272867b74524f]
+
+CVE: CVE-2015-4645 CVE-2015-4646
+
+Signed-off-by: Changqing Li
+---
+ squashfs-tools/unsquash-4.c | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/squashfs-tools/unsquash-4.c b/squashfs-tools/unsquash-4.c
+index ecdaac7..692ae25 100644
+--- a/squashfs-tools/unsquash-4.c
b/squashfs-tools/unsquash-4.c
+@@ -31,9 +31,9 @@ static unsigned int *id_table;
+ int read_fragment_table_4(long long *directory_table_end)
+ {
+ int res, i;
+- int bytes = SQUASHFS_FRAGMENT_BYTES(sBlk.s.fragments);
+- int indexes = SQUASHFS_FRAGMENT_INDEXES(sBlk.s.fragments);
+- long long fragment_table_index[indexes];
++ size_t bytes = SQUASHFS_FRAGMENT_BYTES(sBlk.s.fragments);
++ size_t indexes = SQUASHFS_FRAGMENT_INDEXES(sBlk.s.fragments);
++ long long *fragment_table_index;
+
+ TRACE("read_fragment_table: %d fragments, reading %d fragment indexes "
+ "from 0x%llx\n", sBlk.s.fragments, indexes,
+@@ -43,6 +43,11 @@ int read_fragment_table_4(long long *directory_table_end)
+ *directory_table_end = sBlk.s.fragment_table_start;
+ return TRUE;
+ }
++
++ fragment_table_index = malloc(indexes*sizeof(long long));
++ if(fragment_table_index == NULL)
++ EXIT_UNSQUASH("read_fragment_table: failed to allocate "
++ "fragment table index\n");
+
+ fragment_table = malloc(bytes);
+ if(fragment_table == NULL)
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
index 4bee371..2f41263 100644
--- a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
+++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
@@ -15,6 +15,7 @@ SRC_URI =
"git://github.com/plougher/squashfs-tools.git;protocol=https \
file://0001-mksquashfs.c-get-inline-functions-work-with-C99.patch;striplevel=2 \
file://squashfs-tools-4.3-sysmacros.patch;striplevel=2 \
file://fix-compat.patch \
+
file://0001-squashfs-tools-patch-for-CVE-2015-4645-6.patch;striplevel=2 \
"
UPSTREAM_CHECK_COMMITS = "1"
SRC_URI[lzma.md5sum] = "29d5ffd03a5a3e51aef6a74e9eafb759"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libexif: patch for CVE-2017-7544
From: Changqing Li
Signed-off-by: Changqing Li
---
.../libexif/libexif/CVE-2017-7544.patch| 40 ++
meta/recipes-support/libexif/libexif_0.6.21.bb | 3 +-
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
diff --git a/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
b/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
new file mode 100644
index 000..e49481f
--- /dev/null
+++ b/meta/recipes-support/libexif/libexif/CVE-2017-7544.patch
@@ -0,0 +1,40 @@
+From 8a92f964a66d476ca8907234359e92a70fc1325b Mon Sep 17 00:00:00 2001
+From: Changqing Li
+Date: Tue, 28 Aug 2018 15:12:10 +0800
+Subject: [PATCH] On saving makernotes, make sure the makernote container tags
+ has a type with 1 byte components.
+
+Fixes (at least):
+ https://sourceforge.net/p/libexif/bugs/130
+ https://sourceforge.net/p/libexif/bugs/129
+
+Upstream-Status: Backport[https://github.com/libexif/libexif/commit/
+c39acd1692023b26290778a02a9232c873f9d71a#diff-830e348923810f00726700b083ec00cd]
+
+CVE: CVE-2017-7544
+
+Signed-off-by: Changqing Li
+---
+ libexif/exif-data.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/libexif/exif-data.c b/libexif/exif-data.c
+index 67df4db..6bf89eb 100644
+--- a/libexif/exif-data.c
b/libexif/exif-data.c
+@@ -255,6 +255,12 @@ exif_data_save_data_entry (ExifData *data, ExifEntry *e,
+ exif_mnote_data_set_offset (data->priv->md, *ds - 6);
+ exif_mnote_data_save (data->priv->md, >data,
>size);
+ e->components = e->size;
++if (exif_format_get_size (e->format) != 1) {
++ /* e->format is taken from input code,
++ * but we need to make sure it is a 1 byte
++ * entity due to the multiplication below. */
++ e->format = EXIF_FORMAT_UNDEFINED;
++ }
+ }
+ }
+
+--
+2.7.4
+
diff --git a/meta/recipes-support/libexif/libexif_0.6.21.bb
b/meta/recipes-support/libexif/libexif_0.6.21.bb
index cff4cae..b550a11 100644
--- a/meta/recipes-support/libexif/libexif_0.6.21.bb
+++ b/meta/recipes-support/libexif/libexif_0.6.21.bb
@@ -4,7 +4,8 @@ SECTION = "libs"
LICENSE = "LGPLv2.1"
LIC_FILES_CHKSUM = "file://COPYING;md5=243b725d71bb5df4a1e5920b344b86ad"
-SRC_URI = "${SOURCEFORGE_MIRROR}/libexif/libexif-${PV}.tar.bz2"
+SRC_URI = "${SOURCEFORGE_MIRROR}/libexif/libexif-${PV}.tar.bz2 \
+ file://CVE-2017-7544.patch"
SRC_URI[md5sum] = "27339b89850f28c8f1c237f233e05b27"
SRC_URI[sha256sum] =
"16cdaeb62eb3e6dfab2435f7d7bccd2f37438d21c5218ec4e58efa9157d4d41a"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Revert "cpan.bbclass: adopt to recent EU::MM"
> Am 24.08.2018 um 10:07 schrieb Khem Raj :
>
> This reverts commit 2e61533e7c1b1cfd49dc771e907207f11a15c44f.
> ---
> meta/classes/cpan.bbclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/cpan.bbclass b/meta/classes/cpan.bbclass
> index 926c6358a6..8e079e0d55 100644
> --- a/meta/classes/cpan.bbclass
> +++ b/meta/classes/cpan.bbclass
> @@ -16,7 +16,8 @@ export PERL_ARCHLIB =
> "${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
> export PERLHOSTLIB =
> "${STAGING_LIBDIR_NATIVE}/perl-native/perl/${@get_perl_version(d)}/"
>
> cpan_do_configure () {
> - yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor
> NO_PERLLOCAL=1 NO_PACKLIST=1 ${EXTRA_CPANFLAGS}
> + export PERL5LIB="${PERL_ARCHLIB}"
> + yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor
> ${EXTRA_CPANFLAGS}
>
> # Makefile.PLs can exit with success without generating a
> # Makefile, e.g. in cases of missing configure time
> --
> 2.18.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
This one shouldn't get tested together with
2387c0d3 cpan.bbclass: make RPATH fix more general
since the hacked PERL5LIB="${PERL_ARCHLIB}" hides the broken RPATH
behavior.
--
Jens Rehsack - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Troubleshooting sstate cache
2018-08-28 7:53 GMT+02:00 Nick Winters : > Often when I use an sstate cache from another build, I run into problems > where builds fail. Usually the failure is a result of not being able to find > a shared library. If I delete the sstate cache, the build succeeds, although > it is 8 hours later. I switched to using sstate mirrors and had similar > problems. If you provide an example of a specific failure, we might be better able to help you. It's fine to use one global sstate cache for absolutely everything. You can share between builds, target machines and distros. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] mesa: Enable gallium-llvm on x86 and x86_64
On Tue, Aug 28, 2018 at 12:55 AM, Khem Raj wrote:
> On Mon, Aug 27, 2018 at 2:15 PM Andreas Müller
> wrote:
>>
>> On Mon, Aug 20, 2018 at 8:59 PM, Khem Raj wrote:
>> > Signed-off-by: Khem Raj
>> > ---
>> > meta/recipes-graphics/cairo/cairo.inc | 3 ++-
>> > meta/recipes-graphics/mesa/mesa.inc | 3 +++
>> > 2 files changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/meta/recipes-graphics/cairo/cairo.inc
>> > b/meta/recipes-graphics/cairo/cairo.inc
>> > index 20e0d2c92a..7347f223ff 100644
>> > --- a/meta/recipes-graphics/cairo/cairo.inc
>> > +++ b/meta/recipes-graphics/cairo/cairo.inc
>> > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
>> > DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>> >
>> > PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11
>> > xcb', '', d)} \
>> > - ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
>> > + ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
>> > + ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
>> > 'opengl', '', d)}"
>> >
>> > PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
>> > --disable-xlib,${X11DEPENDS}"
>> > PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
>> > diff --git a/meta/recipes-graphics/mesa/mesa.inc
>> > b/meta/recipes-graphics/mesa/mesa.inc
>> > index 5afd0db4b7..dd626d9f00 100644
>> ^ I think this came in accidentaly and it breaks builds when adding
>> packageconfig glesv2:
>>
>> | configure: error: use either --enable-gl=yes or --enable-glesv2=yes.
>> Not both at the same time.
>
> do you remove opengl from DISTRO_FEATURES when enabling glesv2 ?
> try that out.
>
>>
Yes of course I can. But this patch is wrong - we don't have gles as
distro feature - and it is not even mentioned in commit message why
this is done.
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
