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
l.
Wenzong, which xattrs 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
re
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
---
meta/classes/rootfs-postcommands.bbclass | 8
1 file changed, 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
---
meta/recipes-connectivity/connman/connman.inc | 3 ---
1 file changed, 3 deletions(-)
diff --git a
ctionality 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 O
;, d)} "
I'm just not sure whether 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
esn't get created
when setting IMAGE_FEATURES only for some images.
It still works for me (refkit, based on OE-core Rocko at the moment).
Something has created /var/run/connman (perhaps connman itself?) and
the resolv.conf inside it, so /etc/resolv.conf
On Tue, 2017-11-21 at 10:06 -0200, Otavio Salvador wrote:
> On Tue, Nov 21, 2017 at 6:04 AM, Patrick Ohly > wrote:
> > On Thu, 2017-02-09 at 21:38 +0200, Jussi Kukkonen wrote:
> > There is https://bugzilla.yoctoproject.org/show_bug.cgi?id=9883
> > open
> > abo
ch
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 actually address the
underlying quest
On Tue, 2017-11-14 at 11:42 -0600, Leonardo Sandoval wrote:
> On Tue, 14 Nov 2017 17:09:28 +0100
> Patrick Ohly wrote:
> > Is oe-selftest-internal even going to be in the default PATH? It
> > probably shouldn't be, once it truly becomes an implementation
> > detail
On Tue, 2017-11-14 at 10:09 -0600, Leonardo Sandoval wrote:
> On Tue, 14 Nov 2017 09:24:30 +0100
> Patrick Ohly wrote:
>
> > On Mon, 2017-11-13 at 10:17 -0800,
> > leonardo.sandoval.gonza...@linux.intel.com wrote:
> > > From: Leonardo Sandoval > > om>
&
File %s was not created
> 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, P
uot;bitbake some-image" and that is
usually fast because the image already exists. Reusing sstate and
download dir also is important for speed.
Forcing all tests to run in a clean environment would make the overall
CI run slower.
--
Best Regards, Patrick Ohly
The content of this message is my
On Mon, 2017-11-13 at 12:18 -0800, Andre McCurdy wrote:
> On Mon, Nov 13, 2017 at 6:48 AM, Patrick Ohly > wrote:
> > On Thu, 2017-11-09 at 21:54 -0800, Andre McCurdy wrote:
> > > The default systemd-tmpfiles config file expects to be able to
> > > create
> >
ow_bu
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
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
t the 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
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
--
Best Regards, Patrick
ff-by: Patrick Ohly
---
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
--- a/meta/classes/us
kages 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
ror message 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
---
meta/classes/useradd-staticids.bbclass | 12
1 file changed
rsive 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 o
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
---
meta
+
> +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, Patrick Ohly
The content o
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
On Mon, 2017-09-04 at 09:46 -0300, Otavio Salvador wrote:
> On Mon, Sep 4, 2017 at 3:35 AM, Patrick Ohly
> wrote:
> > On Sat, 2017-09-02 at 15:17 -0300, Otavio Salvador wrote:
> > > On Fri, Sep 1, 2017 at 9:04 PM, California Sullivan
> > > wrote:
> > >
et them as allarch.
I would prefer to keep initramfs-framework-setup-live/install-efi as
arch-specific and only make initramfs-framework itself allarch. It's
just a gut feeling about the (minor) advantage of not having to rebuild
these two small recipes vs. the additional complexity of the laye
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 wrote:
> > Let's not dig us deeper into this hole and instead split out the
> > live
> > boot module into its own, arch-specific recipe.
> >
> > Then
t;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-framework can become
arts 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 provides
run-parts in OE.
--
Best Regards, Patrick
hread 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 Int
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 ma
/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 only a
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
.org/licenses/GPL-3.0-with-autoconf-exception.
Signed-off-by: Patrick Ohly
---
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-archive/autoconf-archive_2016.09.16.bb
b/meta/rec
.
Signed-off-by: Patrick Ohly
---
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 100644 meta/recipes-devtools/autoconf
rate .inc file.
Signed-off-by: Patrick Ohly
---
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 deletions(-)
delete mo
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 > +LICENSE = "GPLv3"
>
> Perhaps GPL-3.0-with-autoconf-exception would be more accurate here.
I wasn't sure whether such a thing existed already, but yes, as it does
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
e recipes 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
---
meta/recipes-devtools/autoconf-archive/autoconf-archive.inc | 13
-
meta/re
.
Signed-off-by: Patrick Ohly
---
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 100644 meta/recipes-devtools/autoconf
: 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
---
meta
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]
&
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
> Signed-off-by: Tom Rini
Acked-by: Patrick Ohly
--
Best Regards, Patrick Ohly
The content
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
---
meta/classes/gettext.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes
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
> Cc: Richard Purdie
> Cc: Patrick Ohly
> Signed-off-by: Tom Rini
> ---
> This change is fairly important and, imho, innocuous and should be
> populated to pyro/etc, once merged to master. The next part of the
> series is clean-up and while with my U-Boot hat on, I would
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
y
changes 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 me
The image consists only of the EFI system partition, therefore
we can avoid depending on the default wic tools.
Signed-off-by: Patrick Ohly
---
meta/recipes-core/ovmf/ovmf-shell-image.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/ovmf/ovmf-shell
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, 2017-07-11 at 15:23 -0
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
:07:10.313 return _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 no
.utils.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 stateme
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
---
meta/classes/distrooverrides.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
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
---
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
b/meta/recipes-core/util-linu
rtant, now error messages get dumped to /dev/null.
[YOCTO #11127]
Signed-off-by: Patrick Ohly
---
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/recipes-co
= "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
> 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 this patch. Tha
tside of this 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
KS_FILE_DEPENDS_BOOTLOADERS = ""
WKS_FILE_DEPENDS_BOOTLOADERS_x86 = "syslinux grub-efi systemd-boot"
WKS_FILE_DEPENDS_BOOTLOADERS_x86-64 = "syslinux grub-efi systemd-boot"
WKS_FILE_DEPENDS ??= "${WKS_FILE_DEPENDS_DEF
gt;
/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
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 using
()))
> +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.
--
Bes
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 t
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
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?
> Yes,
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 expec
mal
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 posit
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
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
> > > chan
with --no-rootfs-update? Is that 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 jus
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
On Tue, 2017-06-27 at 15:46 -0700, Christopher Larson wrote:
>
> On Tue, Jun 27, 2017 at 8:33 AM, Patrick Ohly
> wrote:
> add_layer_dependencies() might get called more than once, or
> one of
> the layer dependencies might already be present. The functio
equired).
--
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
p code in 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 authorize
On Tue, 2017-06-27 at 21:11 +1000, Jonathan Liu wrote:
> Hi Patrick,
>
> On 27 June 2017 at 20:38, Patrick Ohly wrote:
> > On Tue, 2017-06-27 at 20:24 +1000, Jonathan Liu wrote:
> >> Hi Patrick,
> >>
> >> The original problem was that bitbake would print
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
---
scripts/lib/compatlayer/__init__.py | 66
shortest name as the main one which must not be
empty.
Signed-off-by: Patrick Ohly
---
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/compatlayer/cases/common.py
index
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
---
scripts/lib/compatlayer/cases/common.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/scripts/lib/compatlayer/cases/commo
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
---
scripts/lib/compatlayer/__init__.py | 7 +
As it might still 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
---
scripts/lib/compatlayer/cases/common.py | 5 +++--
scripts/lib/compatlaye
/meta_oe_security_flags.inc in
.../meta-openembedded/meta-oe/conf/layer.conf
Signed-off-by: Patrick Ohly
---
scripts/lib/compatlayer/__init__.py | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/compatlayer/__init__.py
b/scripts/lib/compatlayer/__init__.py
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
ment, so changing 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
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
---
meta/lib/oeqa/selftest/cases/runcmd.py | 117
efault 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 enc
ecipes, which 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?
--
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 intere
1 - 100 of 788 matches
Mail list logo
