report such failures in a separate test_machine_world
V4: - avoid DEPENDS_remove for go-cross
- commit message spelling fixes
Patrick Ohly (8):
go-cross: avoid libgcc dependency
gdb-cross: avoid tune specific paths
recipes/*-cross recipes: ignore TARGET_ARCH sstate hash
yocto-compat-layer: incl
recipes which inherit
that.
Because go-cross*.bb includes go*.bb, moving the DEPENDS into a .inc
file that only gets included for the target recipes doesn't
work. Reshuffling the content of three .bb files seems too intrusive
at this point.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
On Tue, 2017-04-11 at 19:25 +0100, Richard Purdie wrote:
> I'd tweak the subject line to recipes/*-cross:
>
> On Tue, 2017-04-11 at 16:56 +0200, Patrick Ohly wrote:
> > "yocto-compat-layer.py --machines" showed that shared packages like
> > gcc-cross-powerpc64 have
On Tue, 2017-04-11 at 10:01 -0700, Khem Raj wrote:
> On Tue, Apr 11, 2017 at 9:52 AM, Patrick Ohly <patrick.o...@intel.com> wrote:
> > On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
> >> I think TUNE_PKGARCH is the granularity it needs for setting GOARM
> >>
On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote:
> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly <patrick.o...@intel.com> wrote:
> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote:
> >> Hello!
> >>
> >> I'm currently extending the yocto-compat-l
On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote:
> Hello!
>
> I'm currently extending the yocto-compat-layer.py so that it can detect
> invalid signature changes when changing MACHINE. go-cross-x86_64 shows
> up as broken when comparing signatures for MACHINE=intel-corei7-6
On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote:
> On 4/11/17 9:56 AM, Patrick Ohly wrote:
> > gdb-cross used to be specific to the tune flags, but isn't
> > anymore. Therefore it is enough to use TARGET_SYS instead of
> > TUNE_PKGARCH to create a unique path.
&g
broken.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/__init__.py | 16 ++--
scripts/lib/compatlayer/cases/bsp.py | 26 ++
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/compatlayer/__init__.py
-64 imx6slevk -- .../meta-freescale
The test has already found issues in go-cross (depended on
tune-specific libgcc) and gdb-cross (had a tune-specific path
unnecessarily), so it is also useful to uncover issues that are not
caused by the BSP layer itself.
Signed-off-by: Patrick Ohly <patric
to some other machines
As before, test_signatures only warns about signature changes
introduced by the layer which is under testing, and not those changes
introduced by the additional layers.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/yocto-compat-layer.p
locked-sigs.inc groups tasks according to their tune flags (allarch,
i586, etc.). Also retrieve that information while getting signatures,
it will be needed to determine when setting a machine changes tasks
that aren't machine-specific.
Signed-off-by: Patrick Ohly <patrick.o...@intel.
ult.pa" ]; then
+install -m 0644 ${WORKDIR}/daemon.conf
${D}${sysconfdir}/pulse/daemon.conf
+install -m 0644 ${WORKDIR}/default.pa
${D}${sysconfdir}/pulse/default.pa
+fi
[YOCTO #11161]
Signed-off-by: Patrick Ohly <patrick.o...@int
ll causing signature differences
for go-cross-powerpc64 and machines b4420qds-64b and p5020ds-64b. This
needs further investigation.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/binutils/binutils-cross.inc | 3 +++
meta/recipes-devtools/gcc/gcc-cross.inc
showed up as unnecessarily rebuilding gdb-cross when
switching between machines like intel-corei7-64 and qemux86-64.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/gdb/gdb-cross.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-de
that.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/go/go-cross.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-devtools/go/go-cross.inc
b/meta/recipes-devtools/go/go-cross.inc
index 68f5efd..9b49738 100644
--- a/meta/recipes-devtools
report such failures in a separate test_machine_world
Patrick Ohly (8):
go-cross: avoid libgcc dependency
gdb-cross: avoid tune specific paths
-cross recipes: ignore TARGET_ARCH sstate hash
yocto-compat-layer: include bitbake-diffsigs output
yocto-compat-layer: also determine tune flags for each
this. Now that you mentioned it, I can keep an
eye on it and sent a separate warning once it enters master, but usually
a patch submitter doesn't even get a notification himself that something
was merged.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and alth
On Mon, 2017-04-10 at 08:59 -0400, Bruce Ashfield wrote:
>
>
> On Mon, Apr 10, 2017 at 8:49 AM, Patrick Ohly <patrick.o...@intel.com>
> wrote:
[...]
> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> index 85f71a2e9a6..ac41c80d377 100
ss-${TUNE_PKGARCH}"
FILESEXTRAPATHS =. "${FILE_DIRNAME}/go-cross:"
The alternative would be to drop the libgcc dependency, but I have no
idea whether that would work at all.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I a
and
ROOTFS_POSTUNINSTALL_COMMAND entries. Those need to be excluded both
via vardepvalueexclude and vardepsexclude.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/buildhistory.bbclass | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/meta/c
, 'TUNE_PKGARCH_tune-corei7-64'}
Dependency on variable TUNE_PKGARCH_tune-core2-64 was added
Dependency on Variable TUNE_PKGARCH_tune-corei7-64 was removed
Variable DEFAULTTUNE value changed from 'corei7-64' to 'core2-64'
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/l
ult.pa" ]; then
+install -m 0644 ${WORKDIR}/daemon.conf
${D}${sysconfdir}/pulse/daemon.conf
+install -m 0644 ${WORKDIR}/default.pa
${D}${sysconfdir}/pulse/default.pa
+fi
[YOCTO #11161]
Signed-off-by: Patrick Ohly <patrick.o...@int
locked-sigs.inc groups tasks according to their tune flags (allarch,
i586, etc.). Also retrieve that information while getting signatures,
it will be needed to determine when setting a machine changes tasks
that aren't machine-specific.
Signed-off-by: Patrick Ohly <patrick.o...@intel.
the code.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/__init__.py | 23 ---
scripts/lib/compatlayer/cases/common.py | 25 +
2 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/scripts/lib/compa
nitially. They will be found when fixing the reported tasks
and re-running the check.
For a developer it seems better to have something listed which
definitely is a problem and needs fixing instead of everything,
including the tasks which don't need fixes.
Signed-off-by: Patrick Ohly <patr
hat show up in test_signatures look harmless at first
glance, but probably would need to be done differently to avoid a
false positive when doing the signature check.
V2: - use self.fail() instead of self.assertTrue(False, ...)
- test_machine_signatures check (work in progress)
Patrick Ohly (5):
ge that in a V2.
--
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
or comment: there is no need for the 'if' check,
> because the try and the except bodies set the output variable.
I added that for the case that the command prints nothing (output ==
''). It's unlikely, but I prefer explicit, easy checking over making
assumptions.
--
Best Regards, Patrick Oh
ult.pa" ]; then
+install -m 0644 ${WORKDIR}/daemon.conf
${D}${sysconfdir}/pulse/daemon.conf
+install -m 0644 ${WORKDIR}/default.pa
${D}${sysconfdir}/pulse/default.pa
+fi
[YOCTO #11161]
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
nitially. They will be found when fixing the reported tasks
and re-running the check.
For a developer it seems better to have something listed which
definitely is a problem and needs fixing instead of everything,
including the tasks which don't need fixes.
Signed-off-by: Patrick Ohly <patr
the code.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/__init__.py | 23 ---
scripts/lib/compatlayer/cases/common.py | 25 +
2 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/scripts/lib/compa
hat show up in test_signatures look harmless at first
glance, but probably would need to be done differently to avoid a
false positive when doing the signature check.
Patrick Ohly (3):
yocto-compat-layer: fix also other command invocations
yocto-compat-layer: limit report of signature changes
Argh. V3 incoming.
I'm so glad that this can happen even to the best of us and not just
me ;-}
--
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
On Thu, 2017-03-30 at 10:03 -0600, Aníbal Limón wrote:
>
> On 03/30/2017 12:02 AM, Patrick Ohly wrote:
> > On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
> > ...
> >> +show_help() {
> >> + printf "Usage: %s [-o output_log] [-h] LAYER_DIR ...\n
net-tools-native is needed by swtpm-wrappers (in meta-security)
because swtpm_setup.sh calls netstat, which cannot be assumed to be
present in all Linux installations (for example, it is not in OpenSUSE
minimal base).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-ex
xit code: 1)! See log for
> details! (Output: b'')
>
>
>
> What does that b'' mean?
A empty binary string - that's what Python 3 uses when it deals with raw
bytes instead of text with a known encoding.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinio
is done
unconditionally.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 8
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 898c5b7..73fdfc6 100644
---
ld" still fails, for example. Doing one after
the other works.
Fixes: [YOCTO 11042]
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/populate_sdk_ext.bbclass | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_ext.bb
as do_build, minus do_rm_work and do_rm_work_all.
This may also be useful in a test build of a recipe where one wants
to preserve the work directory without having to modify configuration
settings:
bitbake foobar:do_build_without_rm_work
Signed-off-by: Patrick Ohly <patrick.o...@intel.
to populate_sdk_ext.
Patrick Ohly (2):
rm_work.bbclass: introduce do_build_without_rm_work
populate_sdk_ext.bbclass: enhance compatibility with rm_work.bbclass
meta/classes/populate_sdk_ext.bbclass | 7 ++-
meta/classes/rm_work.bbclass | 27 ---
2 files ch
try to 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.
--
Best R
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.
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 authorized to
ent (when
not using the special "-n", let's also avoid the special "-z" and use
the more general "!" instead.
--
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
dditional parameters.
One potential usage is to attach additional disks.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils
() to write into it.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 3dfff0f..88c9bb1 100644
--- a/meta/lib/oeqa
like discard_writes must be ignored, i.e. not get passed to
launch().
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/targetcontrol.py| 4 ++--
meta/lib/oeqa/utils/commands.py | 4 ++--
meta/lib/oeqa/utils/qemurunner.py | 4 ++--
meta/lib/oeqa
+ Robert's "runqemu: add selftest" series,
no other changes (merge V1 if not taking Robert's patches first)
V3: rebased on top of current master
V4: QemuTinyRunner.start() also needs to accept the new "discard_writes"
parameter
V5: discard_writes must not be passed to launc
be used, and perhaps QemuRunner and QemuTinyRunner
can be merged into one again to avoid code duplication. But for now
the patch follows the exiting style.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/targetcontrol.py| 6 +++---
meta/lib/oeqa/utils/comma
() to write into it.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 3dfff0f..88c9bb1 100644
--- a/meta/lib/oeqa
dditional parameters.
One potential usage is to attach additional disks.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils
+ Robert's "runqemu: add selftest" series,
no other changes (merge V1 if not taking Robert's patches first)
V3: rebased on top of current master
V4: QemuTinyRunner.start() also needs to accept the new "discard_writes"
parameter
Patrick Ohly (3):
oeqa: allow extending qemuparams
e shell window (mine
is a tiling window manager and reorders and resizes windows automatically)
Ignoring the interrupted system calls avoids the problem. Code elsewhere (for
example,
run() in ssh.py) already does the same thing.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/li
n addition, QEMU_USE_KVM
can be set to a list of space-separated MACHINE names for which kvm is
to be enabled.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/testimage.bbclass | 4 +++-
meta/lib/oeqa/targetcontrol.py | 7 ---
2 files changed, 7 insertions(+), 4 deletion
Just something that I happened to notice when using oe-selftest a bit
more... Both patches are non-essential enhancements and thus can wait
until after 2.4.
Patrick Ohly (2):
oeqa: tolerate interrupted select() while waiting for qemu
oeqa: QEMU_USE_KVM can list machines
meta/classes
() to write into it.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 3dfff0f..88c9bb1 100644
--- a/meta/lib/oeqa
dditional parameters.
One potential usage is to attach additional disks.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils
+ Robert's "runqemu: add selftest" series,
no other changes (merge V1 if not taking Robert's patches first)
V3: rebased on top of current master
Patrick Ohly (3):
oeqa: allow extending qemuparams="..."
oeqa: allow customizing image used by runqemu()
oeqa: allow persistent ima
first and then booting with that copy. It's also useful when testing
with additional drives attached to a virtual machine.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/targetcontrol.py| 6 +++---
meta/lib/oeqa/utils/commands.py | 4 ++--
meta/lib/oeqa
dditional parameters.
One potential usage is to attach additional disks.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils
() to write into it.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 4a71ba4..9bae48b 100644
--- a/meta/lib/oeqa
ect() right before the final deadline.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/targetcontrol.py| 4 ++--
meta/lib/oeqa/utils/qemurunner.py | 17 ++---
meta/lib/oeqa/utils/qemutinyrunner.py | 8 +---
3 files changed, 17 insertio
first and then booting with that copy. It's also useful when testing
with additional drives attached to a virtual machine.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/targetcontrol.py| 6 +++---
meta/lib/oeqa/utils/commands.py | 4 ++--
meta/lib/oeqa
+ Robert's "runqemu: add selftest" series,
no other changes (merge V1 if not taking Robert's patches first)
Patrick Ohly (4):
qemurunner: configurable timeout for run_serial()
oeqa: allow extending qemuparams="..."
oeqa: allow customizing image used by runqemu()
oeqa: al
dn't have an efi/boot/bootx64.efi. That's an unrelated problem with
the original test.
I'm fine with merging this patch series.
--
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
r
first and then booting with that copy. It's also useful when testing
with additional drives attached to a virtual machine.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/targetcontrol.py| 4 ++--
meta/lib/oeqa/utils/commands.py | 4 ++--
meta/lib/oeqa/utils/qemurun
with the patches that Robert posted.
If those are meant to go in first, then I'll post a rebased V2.
Patrick Ohly (4):
qemurunner: configurable timeout for run_serial()
oeqa: allow extending qemuparams="..."
oeqa: allow customizing image used by runqemu()
oeqa: allow persistent im
dditional parameters.
One potential usage is to attach additional disks.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils
() to write into it.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/utils/commands.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index d5607d9..ed99d0e 100644
--- a/meta/lib/oeqa
ect() right before the final deadline.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/targetcontrol.py| 4 ++--
meta/lib/oeqa/utils/qemurunner.py | 17 ++---
meta/lib/oeqa/utils/qemutinyrunner.py | 8 +---
3 files changed, 17 insertio
TURES_BACKFILL_CONSIDERED = "${MACHINE_FEATURES_BACKFILL}"
>
> I guess it doesn't work if MACHINE_FEATURES_BACKFILL_CONSIDERED is set
> elsewhere using _append.
>
> The real solution would probably be to skip backfilling
> MACHINE_FEATURES entirely for class-native?
Perhaps set MACHINE_FEATURES_forcevariab
On Thu, 2017-03-23 at 12:28 -0600, Daniel Díaz wrote:
> Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
Can you extend your commit message and add an explanation of why this
change is desirable?
--
Best Regards, Patrick Ohly
The content of this message is my personal opi
removed. This merely hasn't been attempted yet.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
| 48
meta/rec
On Mon, 2017-03-20 at 22:02 +0100, Patrick Ohly wrote:
> However, TARGET_PREFIX is empty in ovmf-native. So instead of
> i586-poky-linux-musl-gcc or i586-poky-linux-musl-gcc-ar we end up
> building with gcc and gcc-ar from the host, which probably wasn't the
> intention.
>
> B
)#${HOST_PREFIX}#' \
+${S}/BaseTools/Conf/tools_def.template
}
GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
@@ -129,6 +157,7 @@ do_compile_class-target() {
fi
FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
bbnote FIXED_GCCVER is ${FIXED_GCCVE
In a stateless image, /etc is not a good place for the "build"
file. By definining the location with a variable it becomes possible
to have the file created elsewhere on a per-image basis. The default
is the same as before.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
-
an libsolv && bitbake libsolv" will help in
your case. If it doesn't, try "rm -rf tmp" next (might be faster and
easier too, if more recipes are affected).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an em
g back an update of musl until someone can figure it out does not
very attractive. But nor is disabling the building of ovmf when musl is
selected, because then the wic tests which rely on ovmf will fail or
also need to get disabled.
--
Best Regards, Patrick Ohly
The content of this messag
e/fstab.h'
As the image recipe only needs the sysroot of wic-tools and does not
need to wait for the build of wic-tools to finish, depending on
do_populate_sysroot is the better choice and happens to avoid
the problem above.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
--
from
glibc-initial.
I couldn't reproduce it at that time. I'll check whether I can trigger
it now.
--
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
On Wed, 2017-03-15 at 16:47 +0200, Ed Bartosh wrote:
> On Wed, Mar 15, 2017 at 04:01:43PM +0200, Ed Bartosh wrote:
> > On Wed, Mar 15, 2017 at 02:41:34PM +0100, Patrick Ohly wrote:
> > > On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> > > > On Wed, 2017-03
On Wed, 2017-03-15 at 16:01 +0200, Ed Bartosh wrote:
> On Wed, Mar 15, 2017 at 02:41:34PM +0100, Patrick Ohly wrote:
> > On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> > > On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > > > Regarding do_rm_wo
On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > Regarding do_rm_work. It should not touch rootfs directories, I believe.
>
> It does, and it should by default because a rootfs can be quite large.
> If it's not
est 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
on behalf of Intel on this mat
t qemu slirp networking because that also does port
mapping, but I think ssh port forwarding is better.
--
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 posi
, so as long as bitbake can parse it you can use anything.
Unfortunately bitbake has problems parsing useful things like $( ). Are
there open bugs about that and/or is it worth filing enhancement
requests?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and a
t-dev']
...
Summary: There were 5 ERROR messages shown, returning a non-zero exit code.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/__init__.py | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/scripts/lib/comp
On Tue, 2017-03-14 at 20:06 +0200, Ed Bartosh wrote:
> On Tue, Mar 14, 2017 at 06:49:45PM +0100, Patrick Ohly wrote:
> >
> > > It's not a big deal to run wic sequentially to produce multiple images,
> > > but it will create more problems than it solves I believ
tinguished with
an additional suffix (".efi.wic", ".live.wiC", etc.) where the suffix is
either specified by the WKS file or the configuration where the WKS file
is selected - the latter might be a bit more flexible.
--
Best Regards, Patrick Ohly
The content of this message is
do_populate_sysroot.
The real solution would be to have two kinds of relationships: a weak
ordering relationship ("if A and B are enabled, A must run before B,
but B can also run without A") and hard dependencies ("B cannot run
unless A has run before").
Signed-off-by: Patrick Ohly <
On Fri, 2017-03-10 at 10:32 -0300, Otavio Salvador wrote:
> On Fri, Mar 10, 2017 at 4:33 AM, Patrick Ohly <patrick.o...@intel.com> wrote:
> > Suppose IMAGE_FSTYPES = "ext4 wic", and the WKS_FILE has multiple
> > partitions and thus needs more entries in /etc/fsta
On Fri, 2017-03-10 at 13:27 +, Joshua Lock wrote:
> On Thu, 2017-03-09 at 21:05 +0100, Patrick Ohly wrote:
> > On Wed, 2017-03-08 at 17:24 +, Joshua Lock wrote:
> > > The oe-selftest oescripts.TestScripts.test_cleanup_workdir was
> > > using
> > > gzip a
one can do is assume (or perhaps check) that the right
IMAGE_FSTYPES are set.
> The mangled fstab is disastrous if someone uses an image upgrade. The
> generated tarball or filesystem WILL NOT be the same running on the
> device as wic will add entries.
When do you take a snapshot of the ro
with busybox, or the tests
can detect busybox and skip the part that depends on real diff and less?
--
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 is
misunderstand something and the selftest doesn't really build
ed?
--
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
On Thu, 2017-03-09 at 17:48 +0100, José Bollo wrote:
> On Thu, 09 Mar 2017 17:07:54 +0100
> Patrick Ohly <patrick.o...@intel.com> wrote:
> > Can't you reorder and rebase the patches so that this
> > 0001-useradd.c-create-parent-directories-when-necessary.patch applies
>
with "devtool
update-recipe shadow-native". I haven't tried whether "update-recipe"
handles re-ordering patches. If it doesn't, just fix it manually.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, th
On Mon, 2017-03-06 at 21:58 +0200, Ed Bartosh wrote:
> On Mon, Mar 06, 2017 at 08:31:55PM +0100, Patrick Ohly wrote:
> > On Mon, 2017-03-06 at 19:50 +0200, Ed Bartosh wrote:
> > > On Mon, Mar 06, 2017 at 04:49:25PM +, Burton, Ross wrote:
> > > > On 6 March 2017
&& echo 'fstab is a symlink'
}
foo
echo $?
$ bash -xe test.sh
+ set -e
+ foo
+ '[' -h /foobar ']'
$ echo $?
1
Making the intend explicit with || true avoids that.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Inte
e that tries
> to use it, and at first boot i am seeing in systemctl status:
>
> ConditionFirstBoot=yes was not met
When the rootfs is read-only permanently, does this condition still make
sense? Probably not, because each boot would be considered a "first
boot". Just wonder
201 - 300 of 785 matches
Mail list logo
