s, i.e.
which IOException.java is meant to be used when compiling openjdk-boot.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I a
On Tue, 2016-11-29 at 13:16 -0700, Christopher Larson wrote:
> On Tue, Nov 29, 2016 at 9:48 AM, Cody P Schafer wrote:
>
> > bb.data.getVar was removed, need to use the modern mechanism.
> >
> > Signed-off-by: Cody P Schafer
> > ---
> > classes/java-library.bbclass | 4 ++--
> > re
further testing can be done once someone starts
using it again.
If you disagree, then please at least merge the compile fix.
Patrick Ohly (2):
multipath-tools: fix building of shared objects
multipath-tools: update to 0.6.4
meta-oe/recipes-support/multipath-tools/files/0001-multipathd.ser
needed to avoid building libcheckerrdb, which depends
on the (currently) unavailable librados.
The other patches had to be refreshed.
Signed-off-by: Patrick Ohly
---
.../files/0001-multipathd.service-Error-fix.patch | 10 ++--
.../files/always-use-libdevmapper-kpartx.patch | 25 ++
.../f
When -pie is in CFLAGS, it overrides the -shared compiler
flag, leading to link errors (undefined main) for shared
objects. Parameters must be ordered so that -shared comes
last.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/multipath-tools/files/shared-libs-avoid-linking-.so-as
needed to avoid building libcheckerrdb, which depends
on the (currently) unavailable librados.
The other patches had to be refreshed.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/multipath-tools/files/0001-multipathd.service-Error-fix.patch
| 10 +-
meta-oe/recipes-su
On Fri, 2017-01-27 at 11:11 +0100, Patrick Ohly wrote:
> No particular reason for updating besides following upstream.
Please ignore. It's a duplicate of the same patch from the patch series.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and al
On Mon, 2017-01-30 at 13:18 +0100, Martin Jansa wrote:
> On Fri, Jan 27, 2017 at 11:11:23AM +0100, Patrick Ohly wrote:
> > No particular reason for updating besides following upstream.
> >
> > Only kpartx has been tested after updating! Seems to work as before;
> > un
[Patchwork-Status: Superseded]
https://patchwork.openembedded.org/patch/136794/
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I
On Tue, 2017-02-07 at 11:25 +0100, Martin Jansa wrote:
> On Tue, Feb 07, 2017 at 08:41:14AM +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-06 at 09:10 -0800, akuster808 wrote:
> > > please drop. this is fixed via a change in master-next.
> > >
> > > http://cgi
On Tue, 2017-02-07 at 12:32 -0600, Jose Lamego wrote:
>
> On 02/07/2017 04:59 AM, Patrick Ohly wrote:
> > What about this use case here: the original author wants to retract a
> > patch. Can he do that via email and/or the web interface?
> >
> Patch submitter (and proj
The patches defined in lvm2.inc no longer apply cleanly to 2.02.138
and as no-one has complained, the old version is probably obsolete
and can be removed.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/lvm2/lvm2_2.02.138.bb | 4
1 file changed, 4 deletions(-)
delete mode 100644
the old lvm2 2.02.138 I noticed a build
error; let's remove it.
Patrick Ohly (4):
lvm2: remove unbuildable 2.02.138
fuse: support native compilation
lvm2: enable native compilation
cryptsetup: enable native compilation
meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb| 6 +-
me
Required for cryptsetup-native, which useful for setting up dm-verity
during a build.
"native-sdk" gets added just in case that this may also be used in an
SDK.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/lvm2/lvm2.inc | 28
meta-oe/recipes-su
Useful for setting up dm-verity during a build.
"native-sdk" gets added just in case that this may also be used in an
SDK.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/cryptsetup/cryptsetup_1.7.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-oe/recip
This is required for swtpm-native (from meta-security) and
simulating a virtual TPM in qemu. Right now, accessing
swtpm only works via CUSE and thus needs fuse.
Signed-off-by: Patrick Ohly
---
meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb | 6 --
1 file changed, 4 insertions(+), 2
Found with verify-bashisms.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/procmail/procmail_3.22.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta-oe/recipes-support/procmail/procmail_3.22.bb
b/meta-oe/recipes-support/procmail/procmail_3.22.bb
index
r, but Reply-To to the list defeats that.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
o
On Thu, 2017-02-09 at 09:17 -0800, Khem Raj wrote:
> On Thu, Feb 9, 2017 at 9:11 AM, Patrick Ohly wrote:
> > BTW, do all mails from openembedded-devel have Reply-To:
> > set? openembedded-core
> > doesn't seem to have that.
>
> yeah I guess reply-all will se
f those cases where it depends on the native patch
tool whether patching still works?
Anyway, the changes that I'd like to see merged are the others. So if
there's no consensus that 2.02.138 can and/or should be removed, let's
keep it.
--
Best Regards, Patrick Ohly
The content of this m
up a build in the
meantime.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I au
[dropping OE-core mailing list]
On Tue, 2017-02-14 at 16:35 +0100, Patrick Ohly wrote:
> On Fri, 2017-02-10 at 09:28 +0100, Martin Jansa wrote:
> > *
> > meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb:do_compile
>
> This is http://er
has to be to disable the use of these
valgrind macros. Should I do that unconditionally?
Doing it conditionally would imply copying the logic from valgrind.bb:
# valgrind supports armv7 and above
COMPATIBLE_HOST_armv4 = 'null'
COMPATIBLE_HOST_armv5 = 'null'
COMPATIBLE_HOST_armv6 =
On Tue, 2017-02-14 at 21:06 +0100, Martin Jansa wrote:
> Or you can try to force arm mode for multipath-tools build (by setting
> ARM_INSTRUCTION_SET in the recipe).
That's probably the easiest solution - I'll do that. Thanks for the
hint.
--
Best Regards, Patrick Ohly
The
E-core] Does recipe specific
sysrooot (or whatelse in current oe) break native dependencies?"
I don't know how long it might take to resolve this, nor how urgent this
problem is for you, therefore I don't have an opinion whether merging a
(temporary?) workaround is better than waitin
when compiling for ARM with thumb.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb | 9 +--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
b/meta-oe/recipes-support
pushed yet). The right mailing list
for future patches is yo...@yoctoproject.org - I had gotten that wrong
when summarizing the patch submission procedure for you.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statem
On Thu, 2017-02-16 at 02:42 -0800, Andre McCurdy wrote:
> On Thu, Feb 16, 2017 at 2:29 AM, Patrick Ohly wrote:
> > Updating to 0.6.4 introduced a build failure on ARM when thumb was
> > enabled because of the embedded valgrind.h macro calls. The easiest
> > solution and thus
calls out of
the code when compiling for ARM with thumb.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb | 10 +--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
b
servers and Patchwork itself
It still relies on the original submitter to watch out for breakages in
the processes, but I guess that can't be avoided with an asynchronous,
mail-based process.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and altho
is the wrong solution. See https://bugzilla
.yoctoproject.org/show_bug.cgi?id=11725
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am
? It works fine for me with wpa-supplicant:
wpa-supplicant_2.6.bb: SYSTEMD_AUTO_ENABLE = "disable"
wpa-supplicant_2.6.bbappend: SYSTEMD_AUTO_ENABLE = "enable"
=> bitbake -e shows "enable"
--
Best Regards, Patrick Ohly
The content of this message is my personal opin
On Thu, 2017-11-16 at 15:00 -0500, Mark Asselstine wrote:
> On Thursday, November 16, 2017 7:28:06 PM EST Patrick Ohly wrote:
> > On Thu, 2017-11-16 at 10:19 -0500, Mark Asselstine wrote:
> > > The current assignment does not allow a bbappend to be used to
> > > overwr
en building qemu 2.8.0 for intel-corei7-64
with gcc 6.3.0.
The reason seems to be that somewhere there's a
#define isnan __builtin_isnan
which doesn't work in C++ because std::__builtin_isnan does not
exist.
I'm still looking for the define... if someone has suggestions, I&
On Wed, 2018-01-17 at 12:09 +0100, Patrick Ohly wrote:
> On Tue, 2017-10-03 at 19:45 -0400, Denys Dmytriyenko wrote:
> > Martin, Khem,
> >
> > Have you tried building Qt 5.9 with gcc 6.3 from oe-core? I'm
> > seeing
> > bunch ofÂ
> > what seems to be
enabled.
The approach used by meta-freescale works with older releases.
BBFILES_DYNAMIC [1] (supported by bitbake 1.36/Yocto 2.4) is a bit more
robust.
[1] https://patchwork.openembedded.org/patch/140532/
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only an
pported init
system, so sysvinit wasn't listed as supported. This is something that
cannot realistically be achieved by splitting up layers and/or repos
containing layers.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of In
On Wed, 2018-02-21 at 20:33 +0100, Andreas Oberritter wrote:
> On Wed, 21 Feb 2018 15:58:17 +0100
> Patrick Ohly wrote:
> > The approach used by meta-freescale works with older releases.
> > BBFILES_DYNAMIC [1] (supported by bitbake 1.36/Yocto 2.4) is a bit
> > more
> &
e is "external" and
which is "internal".
> "env" is a script containing just the following:
> . ./oe-core/oe-init-build-env build/ bitbake/
We ended up with a top-level "oe-init-build-env" wrapper script around
the actual oe-core/oe-init-build-env. Th
The libjpeg-turbo update to 1.5.0 broke components which embedd their
own, conflicting definitions of the jpeg_mem functions.
Signed-off-by: Patrick Ohly
---
.../jpeg_memsrcdest-extend-feature-check.patch | 97 ++
.../recipes-graphics/gphoto2/libgphoto2_2.5.8.bb | 1
The libjpeg-turbo update to 1.5.0 broke components which embedd their
own, conflicting definitions of the jpeg_mem functions.
Signed-off-by: Patrick Ohly
---
.../jpeg_memsrcdest-extend-feature-check.patch | 62 ++
.../recipes-multimedia/v4l2apps/v4l-utils_1.6.2.bb | 1
On Wed, 2016-06-15 at 17:08 +0200, Patrick Ohly wrote:
> +Upstream-Status: Submitted [https://github.com/gphoto/libgphoto2/pull/64]
FWIW, the patch was merged, so "Backported" is now more accurate.
--
Best Regards, Patrick Ohly
The content of this message is my personal opi
did the combination above stop
working?
[please reply also directly, I'm not receiving list emails]
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position
Dan McGregor gmail.com> writes:
> From: Daniel McGregor vecima.com>
>
> GCC 6 sets the default C++ standard to C++14 and introduces dead store
> elimination by default. OpenJDK 8 is not ready for either of these
> changes, so set the C++ standard back to gnu++98 and disable dead
> store eliminat
Dan McGregor gmail.com> writes:
> On 11 July 2016 at 05:29, Patrick Ohly intel.com> wrote:
> > Dan McGregor gmail.com> writes:
> >> From: Daniel McGregor vecima.com>
> >>
> >> GCC 6 sets the default C++ standard to C++14 and introduces dead sto
Dan McGregor gmail.com> writes:
> From: Daniel McGregor vecima.com>
>
> Some supported hosts still use GCC 4.X. These don't support the flags
> needed to make GCC 6 work, so check the GCC version and add appropriate
> compiler flags.
>
> This implementation will append flags for any gcc versi
ant: extraflags already is a string. It
happened to work because Python treats a string as sequence of
single-character strings, and thus ''.join() re-created the original
string.
Signed-off-by: Patrick Ohly
---
recipes-core/openjdk/openjdk-8-common.inc | 6 ++
1 file changed, 2 i
bitbake rev 67a7b8b02 "build: don't use $B as the default cwd for
functions" (included in current bitbake master) breaks the assumption
that do_unpackpost runs inside the build directory. Now that has to be
set explicitly, which is also okay for older bitbake versions.
Signed-off-b
This revision of the recipe was moved to OE-core in openemedded-core
commit 020f7ea3aa5 and enhance there since then. It now needs to be
removed here to avoid issues when the older copy from meta-oe gets
picked for building things like ovmf.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes
_MACHINE)
...
Missing or unbuildable dependency chain was: ['openssl-qat-dev']
...
Summary: There were 5 ERROR messages shown, returning a non-zero exit code.
Signed-off-by: Patrick Ohly
---
scripts/lib/compatlayer/__init__.py | 20 +---
1 file changed, 9 insertions(+
On Wed, 2017-03-15 at 10:48 +0100, Patrick Ohly wrote:
> When "bitbake -k -S none world" failed, the error printed by
> yocto-compat-layer.py contained the stack trace multiple times and did not
> contain the stderr output from bitbake, making the error hard to understand
> a
My initial attempt with moving just
the udev rules to the libdevicemapper packages was either flawed or
incomplete.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel&#x
On Thu, 2017-03-16 at 16:42 +0100, Patrick Ohly wrote:
> On Sat, 2017-02-18 at 03:10 +0100, Peter Kjellerstedt wrote:
> > This allows, e.g., cryptsetup to use libdevmapper without having to
> > pull in all of lvm2.
>
> I'm experiencing an issue where both kpartx and cr
ps
counter-intuitive, but necessary to keep the package functioning. A
full lvm2 installation is guaranteed to pull them in, too, both
because of implicit library dependencies and (just to be sure) an
explicit RDEPENDS.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/lvm2/lvm2.inc | 7 +
it)
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/lvm2/lvm2.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc
b/meta-oe/recipes-support/lvm2/lvm2.inc
index cfa74d4..d0be296 100644
--- a/meta-oe/recipes-support/lvm2/lvm2.in
t case.
Signed-off-by: Patrick Ohly
---
meta-oe/recipes-support/lvm2/lvm2.inc | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-support/lvm2/lvm2.inc
b/meta-oe/recipes-support/lvm2/lvm2.inc
index 3e79552..cfa74d4 100644
--- a/meta-oe/recipes-support/lvm2
ix.
Did ovmf really fail in the latest world build?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorize
On Wed, 2017-03-29 at 11:14 +0200, Martin Jansa wrote:
> On Wed, Mar 29, 2017 at 10:35:23AM +0200, Patrick Ohly wrote:
> > On Wed, 2017-03-29 at 09:23 +0200, Martin Jansa wrote:
> > > INFO: jenkins-job.sh-1.8.19 Complete log available at
> > > http://logs.nslu2-linux.
do something similar.
> but it was working with older binutils, so maybe worth tracking down
> where it got borken.
Before my OE-core fix, it was always using /usr/bin/gcc and thus ld. Now
that it actually uses the compiler intended for the target, it ends up
using gold, which fails.
--
B
oe.utils.filter('-pie',
'${SECURITY_CFLAGS}') } ${SECURITY_LDFLAGS}"
SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
--
Best Regards, Patrick Ohly
The content of th
On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
>
> On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly
> wrote:
>
> On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
> > My guess is that the problem stems from the fact that
> security_fl
On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
> On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
> >
> > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly
> > wrote:
> >
> > On Wed, 2017-06-07 at 21:44 +, Peter Kjellerstedt wrote:
> >
On Fri, 2017-06-09 at 19:32 +0200, Patrick Ohly wrote:
> On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
> > On Fri, 2017-06-09 at 13:24 +, Khem Raj wrote:
> > >
> > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly
> > > wrote:
> > >
&g
This complements the corresponding patch in OE-core.
gnome-common is affected and must be modified together with the move
because of the conflict over who provides ax_code_coverage.m4 and
ax_check_enable_debug.m4. They now come from autoconf-archive in
OE-core.
Signed-off-by: Patrick Ohly
64 matches
Mail list logo
