On Wed, Oct 17, 2018 at 6:08 PM Douglas Royds
wrote:
>
> This patch is already on meta-openembedded master:
>
>
> http://git.openembedded.org/meta-openembedded/commit/?id=ed5c1c19963546f09201747b11b94b71729b0bcd
>
> For the record, I have just submitted it upstream:
>
>
This patch is already on meta-openembedded master:
http://git.openembedded.org/meta-openembedded/commit/?id=ed5c1c19963546f09201747b11b94b71729b0bcd
For the record, I have just submitted it upstream:
http://www.openldap.org/its/index.cgi/Incoming?id=8928
Should I submit a new patch,
On Wed, Oct 17, 2018 at 10:03:53PM +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-devel-boun...@lists.openembedded.org > devel-boun...@lists.openembedded.org> On Behalf Of Martin Jansa
> > Sent: den 17 oktober 2018 23:34
> > To: Peter Kjellerstedt
> > Cc:
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org devel-boun...@lists.openembedded.org> On Behalf Of Martin Jansa
> Sent: den 17 oktober 2018 23:34
> To: Peter Kjellerstedt
> Cc: y...@blade-group.com; openembedded-devel de...@lists.openembedded.org>
>
While digging around this, I noticed that BLUEZ is set depending on
DISTRO_FEATURES only, wouldn't it make more sense to check
COMBINED_FEATURES instead ?
Le mer. 17 oct. 2018 à 23:34, Martin Jansa a
écrit :
> I wouldn't say that supporting bluez6 as BLUEZ value before
> RDEPENDS_bluez6 is
I wouldn't say that supporting bluez6 as BLUEZ value before RDEPENDS_bluez6
is defined here is really better.
Whole bluez4 support here is a bit useless considering that all bluez4
related recipes were removed more than a year ago with:
commit 007498ac72e26e9f7064de74f7fe96e91ae6c969
Author:
> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> On Behalf Of
> yann.dir...@blade-group.com
> Sent: den 17 oktober 2018 22:57
> To: openembedded-devel@lists.openembedded.org
> Cc: Yann Dirson
> Subject: [oe] [PATCH v3] packagegroup-tools-bluetooth: work
From: Yann Dirson
Otherwise the build fails with:
NOTE: Runtime target '${RDEPENDS_}' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['${RDEPENDS_}']
This restores some truth in the "Otherwise install nothing" comment in the
recipe.
Signed-off-by: Yann Dirson
Signed-off-by: Maxime Roussin-Bélanger
---
.../libeigen/{libeigen_3.3.4.bb => libeigen_3.3.5.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta-oe/recipes-support/libeigen/{libeigen_3.3.4.bb =>
libeigen_3.3.5.bb} (79%)
diff --git
---
.../libeigen/{libeigen_3.3.4.bb => libeigen_3.3.5.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta-oe/recipes-support/libeigen/{libeigen_3.3.4.bb =>
libeigen_3.3.5.bb} (79%)
diff --git a/meta-oe/recipes-support/libeigen/libeigen_3.3.4.bb
Signed-off-by: Maxime Roussin-Bélanger
---
.../libeigen/{libeigen_3.3.4.bb => libeigen_3.3.5.bb} | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
rename meta-oe/recipes-support/libeigen/{libeigen_3.3.4.bb =>
libeigen_3.3.5.bb} (65%)
diff --git
Right.
This is being discussed following v1 of the patch which I had sent to
-core, to which I had send the patch by mistake at first.
Le mer. 17 oct. 2018 à 20:39, Khem Raj a écrit :
> On Wed, Oct 17, 2018 at 8:41 AM wrote:
> >
> > From: Yann Dirson
> >
> > Otherwise the build fails with:
>
If you try to build a system with multiple BSPs, one of which is qemux86
or qemux86-64, the gstreamer package will change. This will trigger
anything using gstream to also be rebuilt.
For a package based system, the PR values will also be incremented each
time. The end result will be an ever
While working on a system with multiple BSPs, but a single distro configuration,
I struggled with an issue of PR numbers increasing quickly and different
behavior from boot to boot.
Most of the issues were from oe-core and similar problems. The gstreamer in
oe-core has -exactly- the same code as
On Wed, Oct 17, 2018 at 8:41 AM wrote:
>
> From: Yann Dirson
>
> Otherwise the build fails with:
>
> NOTE: Runtime target '${RDEPENDS_}' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['${RDEPENDS_}']
>
> This restores some truth in the "Otherwise install nothing"
From: Yann Dirson
Otherwise the build fails with:
NOTE: Runtime target '${RDEPENDS_}' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['${RDEPENDS_}']
This restores some truth in the "Otherwise install nothing" comment in the
recipe.
Signed-off-by: Yann Dirson
Please rebase the unwind fix on top of
https://patchwork.openembedded.org/patch/155662/
On Wed, Oct 17, 2018 at 3:40 PM Vyacheslav Yurkov
wrote:
> Build glog as a shared library by default. Backported CMake patch
> from master that sets SONAME properly. Updated the patch for libunwind
> look up
Build glog as a shared library by default. Backported CMake patch
from master that sets SONAME properly. Updated the patch for libunwind look up
and added libunwind as a run-time dependency
Signed-off-by: Vyacheslav Yurkov
---
...0001-find-libunwind-during-configure.patch | 80 +
From: Mingli Yu
This is a bugfix release for UDisks 2.7. Included fixes:
- Fix string format vulnerability
- Fix CVE-2018-17336
Signed-off-by: Mingli Yu
---
.../udisks/{udisks2_2.7.7.bb => udisks2_2.7.8.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename
Hi,
here is a PR to support erlang version 21.1.0.
https://github.com/joaohf/meta-erlang/pull/19
kind regards,
Maurice Franke
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
On Tue, Oct 16, 2018 at 11:12 PM Tim Orling <
timothy.t.orl...@linux.intel.com> wrote:
> * Add UPSTREAM_CHECK_REGEX to ignore DEV releases
> * Add RDEPENDS that were missing
> * Enable ptest and add RDEPENDS for tests
> * Add RRECOMMENDS for libnet-dns-sec-perl
>
> * Upstream release notes:
> """
* Add UPSTREAM_CHECK_REGEX to ignore DEV releases
* Add RDEPENDS that were missing
* Enable ptest and add RDEPENDS for tests
* Add RRECOMMENDS for libnet-dns-sec-perl
* Upstream release notes:
"""
1.18 Sep 21, 2018
Documentation revised to remove ambigous use of "answer" which
Net::DNS::SEC is installed as an extension to an existing Net::DNS
installation providing packages to support DNSSEC as specified in
RFC4033, RFC4034, RFC4035 and related documents.
It also provides support for SIG0 which is useful for dynamic updates.
Implements cryptographic signature
23 matches
Mail list logo
