ttrs-exclude and --xattr-include.
>
> Is there a need to copy extended attributes except for Smack?
In theory file-based capabilities. In practice those probably don't
occur in a home directory template.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only
On Tue, 2018-01-09 at 11:51 -0600, Mark Hatle wrote:
> On 1/4/18 4:41 AM, Patrick Ohly wrote:
> > On Thu, 2018-01-04 at 11:18 +0100, José Bollo wrote:
> > > > Do you agree to move the patch to Smack specific layer? Such
> > > > as
> > > > meta-securit
ttrs are those? Do you agree with the proposed
solution?
Jose, can you look into updating your patch accordingly?
--
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 th
active? In other words, why
should it be disabled when using SELinux?
File capabilities are also stored in xattrs. It might be relevant to
copy those when using SELinux. Or do I miss something?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I
ot;Yocto Compatible 2.0"
rules.
Besides, it would be harder to maintain in a separate layer - for the
maintainer of that layer.
I still think this patch belong into OE-core, even though it is then
more work for the OE-core maintainer.
--
Best Regards, Patrick Ohly
The content of this message
This aligns TPM support in OE with the approach accepted and merged
upstream.
An update for swtpm in meta-security was already sent
("[meta-security][PATCH 1/1] swtpm/libtpm: update to latest master").
Changes:
-v2: rebased
Patrick Ohly (1):
qemu: use upstream swtpm support
me
This aligns TPM support in OE with the approach accepted and merged
upstream.
An update for swtpm in meta-security was already sent
("[meta-security][PATCH 1/1] swtpm/libtpm: update to latest master").
Patrick Ohly (1):
qemu: use upstream swtpm support
meta/recipes-devtools/qemu
When read-only-rootfs is active, we need to ensure that the rootfs
does not get mounted read/write by the kernel or initramfs. Adding
"ro" to the boot parameters achieves that.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/rootfs-postcommands.bbclass | 8
to be created via tmpfiles.d when booting a
read-only rootfs. In my tests that is not necessary (anymore?),
something (connman itself?) creates the missing directory.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-connectivity/connman/connman.inc | 3 ---
1 file changed, 3 del
ality together, so I
decided to put that into rootfs-postcommands.bbclass next to the fstab
change. It could also go into image.bbclass itself.
The special case in connman.inc doesn't seem to be needed, therefore I
propose to remove it without trying to find a different solution.
Patrick Ohly (2
ether that should go into image.bbclass or
elsewhere.
--
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
e Rocko at the moment).
Something has created /var/run/connman (perhaps connman itself?) and
the resolv.conf inside it, so /etc/resolv.conf -> /etc/resolv-
conf.connman -> ../run/connman/resolv.conf = /run/connman/resolv.conf
exists.
But the bogus lines should be removed nonetheles
On Tue, 2017-11-21 at 10:06 -0200, Otavio Salvador wrote:
> On Tue, Nov 21, 2017 at 6:04 AM, Patrick Ohly <patrick.o...@intel.com
> > wrote:
> > On Thu, 2017-02-09 at 21:38 +0200, Jussi Kukkonen wrote:
> > There is https://bugzilla.yoctoproject.org/show_bug.cgi?id=9883
re taken from the host, which
means they use the host defaults for SSL. That native tools built with
bitbake then try to use ca-certificates-native looks inconsistent to
me.
There is https://bugzilla.yoctoproject.org/show_bug.cgi?id=9883 open
about some aspect of this, but it doesn't actual
On Tue, 2017-11-14 at 11:42 -0600, Leonardo Sandoval wrote:
> On Tue, 14 Nov 2017 17:09:28 +0100
> Patrick Ohly <patrick.o...@intel.com> wrote:
> > Is oe-selftest-internal even going to be in the default PATH? It
> > probably shouldn't be, once it truly becomes an i
On Tue, 2017-11-14 at 10:09 -0600, Leonardo Sandoval wrote:
> On Tue, 14 Nov 2017 09:24:30 +0100
> Patrick Ohly <patrick.o...@intel.com> wrote:
>
> > On Mon, 2017-11-13 at 10:17 -0800,
> > leonardo.sandoval.gonza...@linux.intel.com wrote:
> > > From: Leonardo
at first boot (%s)' % (fileboot_name, output))
run_serial has the quirk that status == 1 on *success*. Yes, weird.
The test probably passed because it was testing for failure, and the
missing "test" ensured that the command failed.
--
Best Regards, Patrick Ohly
The content of this
On Mon, 2017-11-13 at 12:18 -0800, Andre McCurdy wrote:
> On Mon, Nov 13, 2017 at 6:48 AM, Patrick Ohly <patrick.o...@intel.com
> > wrote:
> > On Thu, 2017-11-09 at 21:54 -0800, Andre McCurdy wrote:
> > > The default systemd-tmpfiles config file expects to be able to
&
u
g.cgi?id=9789), but it should at least create the wheel group.
--
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
ing this to "buffer = False" and still get buffering would be
surprising.
--
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
tools. If
something is odd, investigate.
What was odd in this case is that it looked like a patch was partially
merged. Why would anyone do that? And indeed, it was merged completely.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an em
patch.
1 out of 1 hunk ignored
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in:
.../devtooltmp-6_22hcm3/temp/log.do_patch.31897
NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun
and 1 failed.
ERROR: Extracting source for qemu-native failed
--
-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/useradd-staticids.bbclass | 62 ---
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/meta/classes/useradd-staticids.bbclass
b/meta/classes/useradd-staticids.bbclass
index 3d0bc09..589a99f 100644
---
then don't get used.
Triggering a stricter error already during parsing or build time would
still be possible. I'm just not sure how useful that is - perhaps to
catch potential problems without actually having to install the packages.
Patrick Ohly (2):
useradd-staticids: skip recipes without
e is a bit more
obscure:
ERROR: Nothing RPROVIDES 'nfs-utils-client' (but
.../meta/recipes-core/packagegroups/packagegroup-core-nfs.bb RDEPENDS
on or otherwise requires it)
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/useradd-staticids.bbclass | 12
1
extract and list support") but it is not clear whether that
can be merged in time for 2.4.
--
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 issu
This patch is needed for meta-swupd. Without it, some bsdtar
invocations fail with:
bsdtar: Option -n is not permitted in mode -x
The patch was removed in the update to 3.3.1 with the claim that it
had been merged upstream, but that is not the case.
Signed-off-by: Patrick Ohly <patric
TCH] ovmf: enable long path file
> +
> +Upstream-Status: Pending
Pending which action? I.e. what's the next step?
To me this patch looks more like local customization to fit into path
lengths used by the OE build system, so "Inappropriate" might be more
reasonable.
--
Best Regards,
haven't checked) linux-yocto for intel-corei7-64?
What would be the right way of enabling it? On by default as part of
some existing kernel feature perhaps? Or a new feature?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel
On Mon, 2017-09-04 at 09:46 -0300, Otavio Salvador wrote:
> On Mon, Sep 4, 2017 at 3:35 AM, Patrick Ohly <patrick.o...@intel.com>
> wrote:
> > On Sat, 2017-09-02 at 15:17 -0300, Otavio Salvador wrote:
> > > On Fri, Sep 1, 2017 at 9:04 PM, California Sullivan
> > &
o rebuild
these two small recipes vs. the additional complexity of the layer.conf
and having to keep that up-to-date.
--
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
On Wed, 2017-08-30 at 11:39 +0200, Patrick Ohly wrote:
> As I said before ("Re: [OE-core] [PATCH v6 1/1] initramfs-framework:
> module to support boot live image" from July 31st), I consider it a
> mistake that support for live boot with all its dependencies was
> added
On Wed, 2017-08-30 at 09:46 -0300, Otavio Salvador wrote:
> On Wed, Aug 30, 2017 at 6:39 AM, Patrick Ohly <patrick.o...@intel.co
> wrote:
> > Let's not dig us deeper into this hole and instead split out the
> > live
> > boot module into its own, arch-specific reci
nitramfs-framework->eudev \
> + initramfs-framework->parted \
> + initramfs-framework->systemd \
> + initramfs-framework->util-linux \
Let's not dig us deeper into this hole and instead split out the live
boot module into its own, arch-specific recipe.
Then initramfs-fra
uniq wc wget which xargs \
> "
Is run-parts guaranteed to be available on the host?
IMHO it would be better to ensure that run-parts is in recipe-sysroot-
native when installing ca-certificates. PACKAGE_WRITE_DEPS can be set
in ca-certificates.bb for that. I'm just not sure about what pr
upport code" mail thread for details. At
that time I had missed that there was already a pending patch for it.
--
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
On Fri, 2017-06-09 at 10:12 +0200, Patrick Ohly wrote:
> I also get for all recipes (i.e. the error is in the base
> configuration):
>
> meta/conf/bitbake.conf:752: include/require/inherit
> "conf/target/${TARGET_SYS}.conf" resulted in including
> "conf/t
? That would also prevent
rebuilding software when updating autoconf-archive, which may or may
not be the right thing to do - I'm undecided myself.
--
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
;/init.d/80-setup-live"
Same problem as with install-efi: this RDEPENDS in initramfs-framework
makes building the recipe more complicated than strictly necessary.
Please move setup-live to its own recipe.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion o
plit out into its own recipe?
Alternatively one could add a PACKAGECONFIG for it, but that's less
flexible.
--
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 pos
.org/licenses/GPL-3.0-with-autoconf-exception.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
a/meta/recipes-devtools/autoconf-archiv
.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/autoconf-archive/autoconf-archive.inc | 13
+
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 13
+
2 files changed, 26 insertions(+)
create mode 10064
file.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/autoconf-archive/autoconf-archive.inc | 13
-
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 19
++-
2 files changed, 10 insertions(+), 22
V2:
- removed the gnome-common dependency that was still in V1
- merged the .inc file into the .bb file and cleaned up the recipe
V3:
- LICENSE = "GPL-3.0-with-autoconf-exception"
Patrick Ohly (2):
autoconf-archive: move from meta-oe to OE-core
autoconf-archive: simplify and
On Fri, 2017-07-28 at 09:44 -0700, Khem Raj wrote:
> On Fri, Jul 28, 2017 at 7:49 AM, Patrick Ohly <patrick.o...@intel.com
> > +LICENSE = "GPLv3"
>
> Perhaps GPL-3.0-with-autoconf-exception would be more accurate here.
I wasn't sure whether such a thing existed
V2:
- removed the gnome-common dependency that was still in V1
- merged the .inc file into the .bb file and cleaned up the recipe
Patrick Ohly (2):
autoconf-archive: move from meta-oe to OE-core
autoconf-archive: simplify and fix recipe
meta/recipes-devtools/autoconf-archive/autoconf
ipes either, so all of that gets
removed.
It also built fine without the m4 and parallel build workarounds.
There's no need to have a separate .inc file.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/autoconf-archive/autoconf-archive.inc | 13
+
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 13
+
2 files changed, 26 insertions(+)
create mode 10064
: the patch which
disabled the installation of ax_code_coverage.m4 and
ax_check_enable_debug.m4 was removed.
So now autoconf-archive in OE-core provides them. gnome-common in
meta-oe will be changed to not install them and instead depend on
autoconf-archive.
Signed-off-by: Patrick Ohly <patric
On Wed, 2017-07-26 at 19:21 +0300, Ed Bartosh wrote:
> Added e2fsprogs-native to the list of default dependencies for
> wic (WKS_FILE_DEPENDS_DEFAULT) as all fs-related utilities
> have to be in this list.
>
> Thanks to Patrick Ohly for noticing this.
>
> [YOCTO #11817]
&
s that will be removed in the generated shell
> command.
> We fix this by calling sorted() on the set of rm_tmp_images so that
> we
> will have a stable hash again.
>
> Cc: Patrick Ohly <patrick.o...@intel.com>
> Signed-off-by: Tom Rini <tr...@konsulko.com>
Acked-by:
in the recipe-sysroot. Otherwise it only
uses the GETTEXTDATADIR set by the gettext-native tool wrappers, and
that only points to the files provided by gettext-native itself.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/gettext.bbclass | 5 +
1 file changed, 5 inse
On Mon, 2017-07-24 at 07:19 -0400, Tom Rini wrote:
> On Mon, Jul 24, 2017 at 10:35:37AM +0200, Patrick Ohly wrote:
> > On Fri, 2017-07-21 at 18:06 -0400, Tom Rini wrote:
> > > The fix for this inadvertently broke chaining
> > > compression/conversion. First, co
o <zhenhua@nxp.com>
> Cc: Richard Purdie <richard.pur...@linuxfoundation.org>
> Cc: Patrick Ohly <patrick.o...@intel.com>
> Signed-off-by: Tom Rini <tr...@konsulko.com>
> ---
> This change is fairly important and, imho, innocuous and should be
> populated to py
On Fri, 2017-07-21 at 16:52 -0400, Tom Rini wrote:
> On Fri, Jul 21, 2017 at 03:01:33PM +0200, Patrick Ohly wrote:
> > On Fri, 2017-07-21 at 07:21 -0400, Tom Rini wrote:
> > > On Fri, Jul 21, 2017 at 09:47:21AM +0200, Patrick Ohly wrote:
> > > > On Thu, 2017-07-20
On Fri, 2017-07-21 at 07:21 -0400, Tom Rini wrote:
> On Fri, Jul 21, 2017 at 09:47:21AM +0200, Patrick Ohly wrote:
> > On Thu, 2017-07-20 at 18:43 -0400, Tom Rini wrote:
> > > The support for writing vmdk/vdi/qcow2 images has not been converted to
> > > make
nges how IMAGE_FSTYPES = "vmdk" is implemented.
The current patch has its merits as it simplifies the implementation,
but I think it would be worthwhile to go all the way, even if it changes
how images are going to be named.
--
Best Regards, Patrick Ohly
The content of this mes
The image consists only of the EFI system partition, therefore
we can avoid depending on the default wic tools.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf-shell-image.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
On Mon, 2017-07-17 at 14:41 -0500, Aníbal Limón wrote:
>
> On 07/17/2017 02:14 PM, Patrick Ohly wrote:
> > On Fri, 2017-07-14 at 10:27 -0500, Aníbal Limón wrote:
> >>
> >> On 07/14/2017 04:52 AM, Patrick Ohly wrote:
> >>> On Tue, 201
On Fri, 2017-07-14 at 10:27 -0500, Aníbal Limón wrote:
>
> On 07/14/2017 04:52 AM, Patrick Ohly wrote:
> > On Tue, 2017-07-11 at 15:23 -0500, Aníbal Limón wrote:
> >> This was a mistake of me to define wrong what methods needs
> >> to be defined by certain pyt
n _make_failed_test(name, ImportError(message),
suiteClass)
00:07:10.313 TypeError: _make_failed_test() missing 1 required positional
argument: 'suiteClass'
Can this particular patch please be merged into OE-core master
independently from the patch series? It's not really related to it
anyway.
--
s.commands, only the "import"
statements for it in selftest test cases. There might be legitimate uses
for oeqa.utils.commands outside of selftests.
--
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
On Wed, 2017-07-12 at 10:44 -0500, Aníbal Limón wrote:
>
> On 07/12/2017 01:51 AM, Patrick Ohly wrote:
> > On Tue, 2017-07-11 at 15:23 -0500, Aníbal Limón wrote:
> >> def setUpClass(cls):
> >> +super(VersionOrdering, cls).setUpClass()
> >> +
When using distrooverrides.bbclass without setting
DISTRO_FEATURES_OVERRIDES, the code failed because of a spelling error
in the default.
[YOCTO #11759]
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/distrooverrides.bbclass | 4 ++--
1 file changed, 2 insertions
Ran into this while experimenting with stateless logins
Patrick Ohly (2):
util-linux: fix "su -" and package su separately
base-files: ignore "mesg n" error messages
meta/recipes-core/base-files/base-files/share/dot.profile | 3 +-
meta/recipes-core/util-
created when su.util-linux really gets built.
[YOCTO #11126]
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/util-linux/util-linux.inc | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
sages get dumped to /dev/null.
[YOCTO #11127]
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/base-files/base-files/share/dot.profile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/base-files/base-files/share/dot.profile
b/meta/r
OUT = "10"
> )
>
> if not RunqemuTests.image_is_ready:
> -RunqemuTests.deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
> -bitbake(self.recipe)
> +RunqemuTests.deploy_dir_image =
> self.get_bb_var('DEPLOY_DIR_IMAGE')
>
id import OETestID
>
> class TinfoilTests(OESelftestTestCase):
> """ Basic tests for the tinfoil API """
> -
> @OETestID(1568)
> def test_getvar(self):
> with bb.tinfoil.Tinfoil() as tinfoil:
There's just a line removal in thi
his patch which could be simplified like this.
--
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
4 = "syslinux grub-efi systemd-boot"
WKS_FILE_DEPENDS ??= "${WKS_FILE_DEPENDS_DEFAULT}
${WKS_FILE_DEPENDS_BOOTLOADERS}"
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an
/var/run/connman/resolv.conf
That happens even if systemd-resolved has a higher priority and should
be used.
Maxin, do you agree? Can you finish this work and patch the ConnMan
recipe so that it behaves as expected?
--
Best Regards, Patrick Ohly
The content of this message is my personal op
On Mon, 2017-07-03 at 15:44 +0300, Ed Bartosh wrote:
> On Mon, Jul 03, 2017 at 11:27:53AM +0200, Patrick Ohly wrote:
> > On Mon, 2017-07-03 at 11:36 +0300, Ed Bartosh wrote:
> > > On Fri, Jun 30, 2017 at 10:53:30AM -0700, Alejandro Hernandez wrote:
> > > > When usi
()))
> +bb.warn('Invalid mirror variable value for %s: %s, should
> contain paired members.' % (mirror_var, str(mirrors).strip()))
.strip() is redundant here, because str(mirrors) will produce [...],
i.e. the string will never have leading or trailing spaces.
--
Best Regards, Patrick
mage_cpio share the
same deploy task.
--
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 spe
On Mon, 2017-07-03 at 10:31 +0300, Ed Bartosh wrote:
> On Fri, Jun 30, 2017 at 08:34:30PM +0200, Patrick Ohly wrote:
> > then I don't see a need for any additional flags. Just
> > don't use the features which result in a rootfs modification.
>
> I also didn't see it till las
On Sat, 2017-07-01 at 16:48 -0500, Alejandro Hernandez wrote:
>
> On 07/01/2017 10:09 AM, Patrick Ohly wrote:
> > Is it really intended that do_image_wic runs for
> > core-image-tiny-initramfs? How and where is the output of
> > core-image-tiny-initramfs used?
> Ye
On Fri, 2017-06-30 at 15:38 -0500, Alejandro Hernandez wrote:
> Hey Patrick,
>
>
> On 06/30/2017 01:43 PM, Patrick Ohly wrote:
> > On Fri, 2017-06-30 at 10:53 -0700, Alejandro Hernandez wrote:
> >> When using wic to create an image from a certain build, wic is ex
minimal
can only find the .cpio.gz in the DEPLOY_DIR_IMAGE. So to me, the
current approach seems correct.
--
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 o
nderstand under which circumstances wic modifies
the rootfs. If that happens only when explicitly requested in the wks
file as Ed said, then I don't see a need for any additional flags. Just
don't use the features which result in a rootfs modification.
--
Best Regards, Patrick Ohly
Th
On Fri, 2017-06-30 at 15:23 +0300, Ed Bartosh wrote:
> On Fri, Jun 30, 2017 at 11:02:13AM +0200, Patrick Ohly wrote:
> > On Fri, 2017-06-30 at 11:37 +0300, Ed Bartosh wrote:
> > > > I'm not sure I understand this. If you don't want fstab to be
> > > changed
> &
hat a
conceptual problem or an implementation problem?
If I'm not mistaken, --exclude-path merely means "take this rootfs, but
exclude certain parts". That's in line with --no-rootfs-update == "do
not modify the content of the rootfs", as it just helps with choosing
where content
On Wed, 2017-06-28 at 11:08 +0200, Mark Hatle wrote:
> On 6/27/17 5:33 PM, Patrick Ohly wrote:
> > Software layers were previously allowed to change signatures, but
> > that's not desired for those layers either. The rule that a layer
> > which is "Yocto Compatible 2.0&q
On Tue, 2017-06-27 at 15:46 -0700, Christopher Larson wrote:
>
> On Tue, Jun 27, 2017 at 8:33 AM, Patrick Ohly <patrick.o...@intel.com>
> wrote:
> add_layer_dependencies() might get called more than once, or
> one of
> the layer dependencies
--
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 Intel on th
the
"finally" block?
--
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 b
On Tue, 2017-06-27 at 21:11 +1000, Jonathan Liu wrote:
> Hi Patrick,
>
> On 27 June 2017 at 20:38, Patrick Ohly <patrick.o...@intel.com> wrote:
> > On Tue, 2017-06-27 at 20:24 +1000, Jonathan Liu wrote:
> >> Hi Patrick,
> >>
> >> The original pr
This moves the main content of test_signature into a helper
function. It can be reused by arbitrary tests that need to do
a before/after signature comparison. Long-term this might even
be useful in oeqa itself.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compa
with the shortest name as the main one which must not be
empty.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/cases/common.py | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/scripts/lib/compatlayer/cases/common.py
b/scripts/lib/compa
pends, etc.).
This is similar to the BSP test_machine_world. The difference is
that test_world doesn't change the MACHINE.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/cases/common.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/scripts
The "test_signatures" test ignored a broken world build when getting
signatures, but the code which then tried to analyze a difference
found by the test didn't, which prevented printing the difference.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatl
ill change, the tool now has both a with/without
parameter so that users of the tool can choose the desired behavior
without being affected by future changes to the default.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/cases/common.py | 5 +++--
scripts/
/meta_oe_security_flags.inc in
.../meta-openembedded/meta-oe/conf/layer.conf
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/lib/compatlayer/__init__.py | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/compatlayer/__init__.py
b/scrip
covers a refkit specific case
(including refkit-config.inc must not change signatures).
Changes in V2:
- turn signature checking in software layers on/off via command line flags
Patrick Ohly (6):
yocto-compat-layer.py: avoid adding layers more than once
yocto-compat-layer.py: tolerate broken
hanging result.error to be treated the same
as result.output (i.e. decoded to a normal strings) seems like a
relatively safe API change (or rather, implementation fix).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
merge: wait()
---
meta/lib/oeqa/utils/commands.py | 107 ++
This covers the traditional API as well as the new output_log feature.
While testing, it was noticed that killing hanging commands does not
work when a shell is used to run the command(s). This might be worth
fixing.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/oeqa/se
t semantic
(joined stdout/stderr) gets explicitly tested.
Change in V2:
- fix race condition between "process has closed stdout/stderr" and
"process has terminated" by calling wait() instead of poll()
Patrick Ohly (2):
commands.py: live output logging + result.error encoding
ich is unnecessary and potentially introduces back host
contamination.
It is unnecessary because the qemu recipe has special code that enables
the use of the host SDL when told to do so via ASSUME_PROVIDED.
Can you come up with a better solution, probably by patching
sanity.bbclass?
--
Best
On Tue, 2017-06-27 at 11:05 +0200, Patrick Ohly wrote:
> Even if you had checked the right variable, is that really necessary?
> I'm building qemu with ASSUME_PROVIDED += "libsdl-native" just fine on
> Debian Jessie, without sdl-config in HOSTTOOLS.
I'm still interested in le
ly for devshell (and only for devshell)
because developers expect to have access to all host tools.
--
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
1 - 100 of 785 matches
Mail list logo
