quot;Upstream-Status: Pending")
That's the problem with "Pending" - it doesn't really mean that the
original author has specific plans in place to get the patches upstream,
and because there's no systematic tracking of "Pending" patches there's
also no pressure to do so o
_rm_work at the end is a bit unexpected, I
thought it added all tasks of a recipe in sequence. As a result of that,
the reordered completion priorities do not have
quilt-native_0.65.bb:do_rm_work quite as high as it would be otherwise.
I don't think it matters in practice, though.
--
Bes
On Wed, 2017-03-01 at 16:52 +0100, Martin Jansa wrote:
> On Thu, Feb 16, 2017 at 11:26:54AM +0100, Patrick Ohly wrote:
> > On Wed, 2017-02-15 at 19:32 +0100, Martin Jansa wrote:
> > > Are all changes necessary for this to work already in master?
> >
> > Yes.
>
On Wed, 2017-03-01 at 16:01 +, Richard Purdie wrote:
> On Wed, 2017-03-01 at 16:51 +0100, Patrick Ohly wrote:
> > On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote:
> > >
> > > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote:
> > > &g
On Wed, 2017-03-01 at 16:52 +0100, Martin Jansa wrote:
> On Thu, Feb 16, 2017 at 11:26:54AM +0100, Patrick Ohly wrote:
> > On Wed, 2017-02-15 at 19:32 +0100, Martin Jansa wrote:
> > > Are all changes necessary for this to work already in master?
> >
> > Yes.
>
On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote:
> On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote:
> > Is the "build single distro for different machines" scenario that I
> > described part of the Yocto Compliance 2.0? Should there be tests for
> > i
On Wed, 2017-03-01 at 04:00 +, Richard Purdie wrote:
> On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
> > >
> > > common.test_signatures: Test executed in BSP and DISTRO layers to
> >
On Tue, 2017-02-28 at 14:33 -0600, Aníbal Limón wrote:
>
> On 02/28/2017 02:09 PM, Patrick Ohly wrote:
> > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
> >> common.test_signatures: Test executed in BSP and DISTRO layers to review
> >> doesn't c
_samesigs in
sstatetests.py, has the same limitation of its scope, i.e. doesn't
actually test with real machine definitions.
--
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 In
it'll remain uncertain how complete it is. As it is
fairly simple, it's probably worth merging until someone has the time to
investigate the whitelisting approach further.
Richard had some code for it in some of his experimental branches.
--
Best Regards, Patrick Ohly
The content of this mes
l:
"Compatible with OpenSSH ~/.ssh/authorized_keys public key
authentication"
--
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'
ny
> pointers?
For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
INHERIT += "rootfsdebugfiles"
ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub
${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
This copies my id_rsa.pub into authorized_keys and thus let's me log
i
dded by the script. This way user input has priority over runqemu's
> default params.
Presumably the user's bootparams then would include "ip="?
Either way, the change looks good to me. I did something similar for the
qemu parameters in "runqemu: let command line parameters ove
ns('TUNE_FEATURES', 'e6500', 'qemu-usermode', '',
> d)}"
The existing line is better because it avoids adding a space when
nothing needs to be added.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of I
On Fri, 2017-02-24 at 15:33 +0100, Gary Thomas wrote:
> On 2017-02-24 15:21, Patrick Ohly wrote:
> > On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote:
> >>
> >> On 02/22/2017 02:55 PM, Michael Halstead wrote:
> >>> I've seen several issues with
ers 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 although
I am a
The VfrCompile tool has a hard-coded maximum length for path names
which turned out to be too small by around 20 characters in the
Yocto autobuilder setup. Increasing the maximum by a factor of 4
is relatively easy and makes the problem less likely.
Signed-off-by: Patrick Ohly <patric
On Thu, 2017-02-23 at 18:48 +0100, Patrick Ohly wrote:
> The VfrCompile tool has a hard-coded maximum length for path names
> which turned out to be too small by around 20 characters in the
> Yocto autobuilder setup. Increasing the maximum by a factor of 4
> is relatively ea
Manipulating stderr after freopen() fails as done by upstream
does not work with musl. The replacement is Unix specific
and uses open()/dup2().
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/acpica/acpica_20150515.bb| 1 +
.../files/manipulate-fds-i
The VfrCompile tool has a hard-coded maximum length for path names
which turned out to be too small by around 20 characters in the
Yocto autobuilder setup. Increasing the maximum by a factor of 4
is relatively easy and makes the problem less likely.
Signed-off-by: Patrick Ohly <patric
On Fri, 2017-02-17 at 18:04 -0800, Khem Raj wrote:
> On 17-02-17 13:10:56, Richard Purdie wrote:
> > On Fri, 2017-01-27 at 16:30 +0100, Patrick Ohly wrote:
> > > From: meta-luv <l...@lists.01.org>
> > >
> > > This is an unmodified copy of
> > &g
On Tue, 2017-02-21 at 17:23 +0200, Ed Bartosh wrote:
> This patchset improves handling of wic native tool dependencies and
> fixes minor bugs in the wic code.
I haven't tested it, but the patches themselves look good to me. Thanks!
--
Best Regards, Patrick Ohly
The content of this m
ot definitely needs to be improved.
--
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 authoriz
On Sun, 2017-02-19 at 14:26 -0800, Richard Purdie wrote:
> On Tue, 2017-02-14 at 11:26 +0100, Patrick Ohly wrote:
> > My testing was flawed: in addition to the RDEPENDS there also was a
> > DEPENDS with the same entry, and despite what was said earlier about
> > build depende
On Sun, 2017-02-19 at 10:47 -0800, Richard Purdie wrote:
> On Fri, 2017-02-17 at 08:25 +0100, Patrick Ohly wrote:
> > On Thu, 2017-02-16 at 15:46 -0800, Saul Wold wrote:
> > >
> > > This allows a native package's recipe-sysroot-native to be
> > > populated w
Hello Ricardo,
another issue with the UEFI recipes. See also Khem's comment (attached).
Bye, Patrick
On Fri, 2017-02-17 at 13:10 -0800, Richard Purdie wrote:
> On Fri, 2017-01-27 at 16:30 +0100, Patrick Ohly wrote:
> > From: meta-luv <l...@lists.01.org>
> >
> >
Hello Ricardo,
can you perhaps help?
I'm traveling next week and don't have much time.
Thanks, Patrick
On Fri, 2017-02-17 at 13:13 -0800, Richard Purdie wrote:
> On Fri, 2017-01-27 at 16:30 +0100, Patrick Ohly wrote:
> > From: Fathi Boudra <fathi.bou...@linaro.org>
> &
.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/libarchive/libarchive_3.2.2.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/libarchive/libarchive_3.2.2.bb
b/meta/recipes-extended/libarchive/libarchive_3.2.2.bb
On Fri, 2017-02-17 at 15:21 +, Mike Crowe wrote:
> On Monday 13 February 2017 at 11:54:32 +0100, Patrick Ohly wrote:
> > On Fri, 2017-02-10 at 18:32 +, Mike Crowe wrote:
> > > On Thursday 09 February 2017 at 17:24:39 +0100, Patrick Ohly wrote:
> > > > On
intending to be used like that also needs to
exclude itself from do_rm_work:
RM_WORK_EXCLUDE += "${PN}"
Or perhaps more selectively exclude the RSS:
RM_WORK_EXCLUDE_ITEMS += "recipe-sysroot-native" (is there a variable
for this name?)
--
Best Regards, Patrick Ohly
The conten
WORK_TASKS_WHITELIST = "do_build do_package_qa"
deps = set(bb.build.preceedtask('do_build', True, d))
whitelist = d.getVar('RM_WORK_TASKS_WHITELIST').split()
deps.difference_update(whitelist)
# In practice, addtask() here merely updates the dependencies.
bb.build.add
On Tue, 2017-02-14 at 10:12 -0500, Robert P. J. Day wrote:
> On Tue, 14 Feb 2017, Patrick Ohly wrote:
>
> > On Tue, 2017-02-14 at 09:31 -0500, Robert P. J. Day wrote:
> > > i recall, once upon a time, a discussion of how to best support a
> > > non-volatile /var/lo
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
lity is
here: https://patchwork.openembedded.org/patch/90839/
--
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
on beh
On Mon, 2017-02-13 at 18:03 +0100, Patrick Ohly wrote:
> On Mon, 2017-02-13 at 16:24 +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > > Hi Andreas,
> > >
> > >
> > > I think it's feature which was already
On Mon, 2017-02-13 at 18:03 +0100, Patrick Ohly wrote:
> On Mon, 2017-02-13 at 16:24 +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > > Hi Andreas,
> > >
> > >
> > > I think it's feature which was already
On Mon, 2017-02-13 at 16:24 +0100, Patrick Ohly wrote:
> On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > Hi Andreas,
> >
> >
> > I think it's feature which was already there, but almost never
> > triggered (even in test-dependencies.sh tests), b
On Mon, 2017-02-13 at 16:32 +0100, Martin Jansa wrote:
> On Mon, Feb 13, 2017 at 04:24:15PM +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > > Hi Andreas,
> > >
> > >
> > > I think it's feature which was al
when "packaging" the native recipe wouldn't even produce
that package).
--
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 posit
On Mon, 2017-02-13 at 12:19 +, Mike Crowe wrote:
> On Monday 13 February 2017 at 11:54:32 +0100, Patrick Ohly wrote:
> > To me it seems like the right solution. Inheriting
> > release-source.bbclass could be limited to builds which produce
> > releases, for exa
On Fri, 2017-02-10 at 18:32 +, Mike Crowe wrote:
> On Thursday 09 February 2017 at 17:24:39 +0100, Patrick Ohly wrote:
> > On Wed, 2017-02-08 at 13:48 +, Mike Crowe wrote:
> > > On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote:
> The part I'd missed
Backup are files sometimes are inconsistent and then cannot be
sorted (YOCTO #11043), and more importantly, are not needed in
the initial rootfs, so they get deleted.
Fixes: [YOCTO #11007]
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/rootfspostcommands.p
On Wed, 2017-02-08 at 13:48 +, Mike Crowe wrote:
> On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote:
> > On Wed, 2017-02-08 at 11:50 +, Mike Crowe wrote:
> > > On Friday 13 January 2017 at 15:52:33 +0100, Patrick Ohly wrote:
> > > > T
On Wed, 2017-02-08 at 11:50 +, Mike Crowe wrote:
> On Friday 13 January 2017 at 15:52:33 +0100, Patrick Ohly wrote:
> > Having do_rm_work depend on do_build had one major disadvantage:
> > do_build depends on the do_build of other recipes, to ensure that
> > runtime depend
ake master, see commit 25df3db5 "build.py:
avoid exception when function is not defined". Sorry, only now saw your
original email.
--
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 n
On Fri, 2017-02-03 at 16:24 -0500, Robert P. J. Day wrote:
> On Fri, 3 Feb 2017, Patrick Ohly wrote:
>
> > On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote:
> > > is there a command that will tell you how much shared state info a
> > > given build w
--
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
on behalf of Inte
On Thu, 2017-02-02 at 13:11 -0600, Seebs wrote:
> On Thu, 02 Feb 2017 18:17:29 +0100
> Patrick Ohly <patrick.o...@intel.com> wrote:
>
> > On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote:
> > > > But I find mapping to root:root more attractive because it make
On Thu, 2017-02-02 at 18:49 +0100, Enrico Scholz wrote:
> Patrick Ohly <patrick.ohly-ral2jqcrhueavxtiumw...@public.gmane.org>
> writes:
>
> > Recently the host-user-contaminated QA check triggered for the trousers
> > recipe in meta-security:
> >
> > WARNING
the owner of the file is the same as the user who did the
build, but because root isn't (normally) used for building, files
accidentally owned by root on the target won't trigger the warning.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and a
On Thu, 2017-02-02 at 10:21 -0600, Seebs wrote:
> On Thu, 02 Feb 2017 11:38:00 +0100
> Patrick Ohly <patrick.o...@intel.com> wrote:
>
> > Why do we make the real user ID on the build system visible at all
> > when running under pseudo? The uid and user name have no mea
On Wed, 2017-02-01 at 08:56 -0800, Khem Raj wrote:
>
> On 1/31/17 1:05 AM, Patrick Ohly wrote:
> > This fixes a potential pollution by the build host and build error
> > when yacc isn't installed on the build host:
> >
> > | ../../libtasn1-4.9/build-aux/ylwrap: lin
On Wed, 2017-02-01 at 09:03 -0800, Khem Raj wrote:
>
> On 1/31/17 4:29 AM, Patrick Ohly wrote:
> > Hello!
> >
> > verify-bashisms (after some fixing of the script) reports:
> >
> > /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/guile/g
cp" where "install" would be better, and it might be
slightly confusing at first when working under devshell.
Any thoughts?
Seebs, I suppose this wouldn't be hard to implement in pseudo, would it?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion onl
must work
properly in a read-only rootfs configuration. So the test is partly for
image creation, partly for the components, and thus more comprehensive
when using a larger image.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, th
On Tue, 2017-01-31 at 13:50 +0100, Patrick Ohly wrote:
> The script broke when introducing tinfoil2. The patches also include
> several usability enhancements, like making the output less redundant
> and including information about the actual file and line where the
> offending script
Found via verify-bashisms.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/populate_sdk_ext.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index 39e0c83..9
le-config.cross
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index 7283980..dab64ef 100755
--- a/scripts/verify-
= a'):
if [ "${SDK_INCLUDE_TOOLCHAIN}" == "1" -a ! -e $unfsd_path ] ; then
possible bashism in install_tools line 521 (type):
type fixme
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 56 +++---
1 file cha
ore creating the pool to avoid:
AttributeError: Can't get attribute 'func' on
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 44 +++---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/scripts/verify-bash
The actual code recently changed to:
if ${@use_updatercd(d)} && type update-rc.d >/dev/null 2>/dev/null; then
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/verif
installation.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index 1bda60c..28795f4 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-ba
Current tinfoil2 requires manually shutting down the server.
Without that, the script hangs during exit. This might change
in the future.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/verify-bash
Variable was renamed, it's now called "output".
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index a8f761d..1bda60c 1007
The script broke when introducing tinfoil2. The patches also include
several usability enhancements, like making the output less redundant
and including information about the actual file and line where the
offending script can be found.
Patrick Ohly (8):
verify-bashisms: fix typo
verify
his looks rather strange to me and I've no idea how the Linux kernel
will interpret that first shebang line, which literally ends in
...guile$ \
Is the content as intended?
It builds, whatever that means.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only
This fixes a potential pollution by the build host and build error
when yacc isn't installed on the build host:
| ../../libtasn1-4.9/build-aux/ylwrap: line 175: yacc: command not found
| Makefile:1116: recipe for target 'ASN1.c' failed
| make[3]: *** [ASN1.c] Error 127
Signed-off-by: Patrick
On Mon, 2017-01-30 at 17:12 +, Bystricky, Juro wrote:
>
> > -Original Message-
> > From: Patrick Ohly [mailto:patrick.o...@intel.com]
> > Sent: Friday, January 27, 2017 11:22 AM
> > To: Bystricky, Juro <juro.bystri...@intel.com>
> > Cc: o
age-minimal ext4 qemux86
runqemu - ERROR - Can't handle two unknown args: core-image-minimal qemux86
runqemu - ERROR - Try 'runqemu help' on how to use it
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the stat
On Thu, 2017-01-26 at 19:25 -0800, Ricardo Neri wrote:
> On Mon, 2017-01-23 at 08:45 +0100, Patrick Ohly wrote:
> > > On the other hand, this is a new recipe and this may not be super
> > > critical. Especially if you meant that only OVMF will not support
> > >
This patch was added to meta-luv for kernel testing purposes and
probably is not relevant for OE-core.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch
the initializer.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf-shell-image.bb
| 17 +-
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-appli
s.qcow2 my-machine/
$ runqemu qemux86 qcow2 ovmf.code my-machine/ovmf.vars.qcow2
When Secure Boot was enabled in ovmf, one can pick that instead of
the non-Secure-Boot enabled ovmf.code:
$ runqemu qemux86 qcow2 ovmf.secboot.code
my-machine/ovmf.vars.qcow2
Signed-off-by
searches a bit (no need for re; any()+map() a bit closer to the
intended logic).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 17d79e9..4d7168c 100755
---
ith
it.
In contrast to Fedora, no attempt is made to strip potentially patent
encumbered algorithms out of the OpenSSL archive. OVMF does not use
the ones considered problematic for Fedora, so this shouldn't be a
problem.
Fixes: luv-yocto/#38
Signed-off-by: Patrick Ohly <patrick.o...@intel
eant to be used as flash drive in qemu. See the "runqemu:
support UEFI with OVMF firmware" patch for details on how to use OVMF
that way.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 42 ++-
1 file changed,
'arg' isn't defined, the right name there is 'p'.
This fixes a rather obscure error message when that code path
ends up being taken:
$ runqemu some/existing-file-name
runqemu - ERROR - name 'arg' is not defined
runqemu - ERROR - Try 'runqemu help' on how to use it
Signed-off-by: Patrick Ohly
] https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_
From: meta-luv <l...@lists.01.org>
This is an unmodified copy of
github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision
4be4329.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.pa
Fixes a build issue when nasm was not build already because of
something else.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-cor
in flex is the easiest solution for now.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/acpica/acpica_20150515.bb | 1 +
meta/recipes-extended/acpica/files/rename-yy_scan_string-manually.patc
rent master (for real, this time!)
- reordered patches a bit
Changes since V4:
- revised the commit message of "ovmf: deploy firmware in image directory"
to clarify expected usage
Fathi Boudra (1):
acpica: move from meta-oe to OE-core
Patrick Ohly (10):
acpica: work around fle
m meta-openembedded rev fa65be9ba (current master).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/acpica/acpica_20150515.bb | 46 +-
meta/recipes-extended/acpica/acpitests/aapits-linux.patch| 336 +++-
meta/recipes-extended/acpica/acpi
to fix locally by adding
>
> RM_WORK_EXCLUDE = "wic-tools"
>
> however, I think this deserves a more permanent fix, and I'm not sure
> which approach is best.
wic-tools.bb can have:
RM_WORK_EXCLUDE += "${PN}"
--
Best Regards, Patrick Ohly
The content of this mes
skhash mismatch ... for
bb.do_write_wks_template"
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/image_types.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5b1746a68ce..50545d9fdf0
skhash mismatch ... for
bb.do_write_wks_template"
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/image_types.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5b1746a68ce..9bc1996cdb0
On Mon, 2017-01-23 at 16:01 +0200, Alexander Kanavin wrote:
> On 01/20/2017 09:44 PM, Patrick Ohly wrote:
>
> > In contrast to Alexander, I would also keep
> > http://wiki.qemu-project.org/download/${BP}.tar.bz2 in qemu_2.7.1.bb
> > with SRC_URI =+ because then th
This is needed for building the swtpm TPM simulator (recipe
in meta-security).
Native compilation disables tcp-wrappers by default to simplify
the build.
"nativesdk" is added just in case that someone also wants this
in an SDK.
Signed-off-by: Patrick Ohly <patrick.o...@intel.c
This is needed for building the swtpm TPM simulator (recipe
in meta-security).
"nativesdk" is added just in case that someone also wants this
in an SDK.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/expect/expect_5.45.bb | 9 -
1
swtpm (from meta-security) can be compiled for the host and then be
used to provide a virtual TPM device in qemu. However, it depends on
the native flavor of some recipes in OE-core.
Patrick Ohly (2):
expect: support native compilation
socat: support native compilation
meta/recipes
c/deploy/images/intel-corei7-64/core-image-mimimal-intel-corei7-64.qemuboot.conf
(wrong image name or BSP does not support running under qemu?).
The comment about the BSP is included because that would be the real
reason why the file might be missing.
Signed-off-by: Patrick Ohly <patrick.o...@i
On Sun, 2017-01-22 at 23:23 -0800, Ricardo Neri wrote:
> On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote:
> > The traditional usage of ovmf via the qemu bios parameter is no longer
> > supported
>
> I don't see dropping support for this option in this series.
>
/wiki.qemu-project.org/download/${BP}.tar.bz2;
> +
> +SRC_URI[md5sum] = "a315bc51ed443a08d2cf1416d76b9ab4"
> +SRC_URI[sha256sum] =
> "68636788eb69bcb0b44ba220b32b50495d6bd5712a934c282217831c4822958f"
Looks good to me, thanks.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and al
1.bb. At least that's how I
would do it.
In contrast to Alexander, I would also keep
http://wiki.qemu-project.org/download/${BP}.tar.bz2 in qemu_2.7.1.bb
with SRC_URI =+ because then there can be a qemu_git.bb with a different
URL than the one above.
--
Best Regards, Patrick Ohly
The content of this me
On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote:
> Without this patch, linking fails with a missing implementation of
> yy_scan_string. This looks like a regression in flex, because 2.6.0 generated
> different code that called PrParser_scan_string
> resp. DtParser_scan_string.
From: meta-luv <l...@lists.01.org>
This is an unmodified copy of
github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision
4be4329.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.pa
searches a bit (no need for re; any()+map() a bit closer to the
intended logic).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 17d79e9..4d7168c 100755
---
the initializer.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf-shell-image.bb
| 17 +-
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-appli
This patch was added to meta-luv for kernel testing purposes and
probably is not relevant for OE-core.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch
s.qcow2 my-machine/
$ runqemu qemux86 qcow2 ovmf.code my-machine/ovmf.vars.qcow2
When Secure Boot was enabled in ovmf, one can pick that instead of
the non-Secure-Boot enabled ovmf.code:
$ runqemu qemux86 qcow2 ovmf.secboot.code
my-machine/ovmf.vars.qcow2
Signed-off-by
301 - 400 of 785 matches
Mail list logo
