On 4/16/19 2:36 PM, Adrian Bunk wrote:
> On Tue, Apr 16, 2019 at 12:02:04PM +, John Ernberg wrote:
>> ...
>> --- a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
>> +++ b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
>> ...
>> -PACKAGES =+ "${PN}-misc"
>> +PACKAGES =+ "${PN}-misc ${PN}-u
Hi RP,
Any comments here?
Thanks,
On 2019年04月16日 11:14, Yu, Mingli wrote:
On 2019年04月15日 19:08, richard.pur...@linuxfoundation.org wrote:
On Mon, 2019-04-15 at 17:05 +0800, mingli...@windriver.com wrote:
@@ -33,6 +29,8 @@ EXTRA_OECONF = "--disable-openssl"
CFLAGS_append = " -std=c99"
On 4/18/19 6:01 AM, Richard Purdie wrote:
On Wed, 2019-04-17 at 16:38 +0800, changqing...@windriver.com wrote:
From: Changqing Li
1. since one bug in run-ptest, testcase test-bus have never been
actually run (althrough it's result is PASS).
After commit 0828850, test-bus can actually run but
On Apr 17, 2019 5:56 PM, Richard Purdie wrote:I mentioned differences in numbers of pass/fail depending on whichimage you install ptests into. The recipes which have the issues andthe numbers are:core-image-sato with ptest installed:Recipe | Passed | Failed | Skipped
This patch series provides support for the user to run menuconfig command in the
devtool flow. This would allow the user to modify the current configurations and
generate a config fragment to update the recipe using devtool finish. Devtool
menuconfig command will work on all packages that contain m
On Wed, 2019-04-17 at 16:38 +0800, changqing...@windriver.com wrote:
> From: Changqing Li
>
> 1. since one bug in run-ptest, testcase test-bus have never been
> actually run (althrough it's result is PASS).
>
> After commit 0828850, test-bus can actually run but it
> did not install:
> test-se
I mentioned differences in numbers of pass/fail depending on which
image you install ptests into. The recipes which have the issues and
the numbers are:
core-image-sato with ptest installed:
Recipe | Passed | Failed | Skipped |
diffutils| 20
evince fails see
https://errors.yoctoproject.org/Errors/Details/237724/
and reported elsewhere as well
https://gitlab.gnome.org/GNOME/gobject-introspection/issues/229
On Mon, Apr 15, 2019 at 3:55 AM Alexander Kanavin
wrote:
>
> Drop upstreamed patches:
> 0010-meson-add-option-gir-dir-prefix.pat
The PYTHON variable is already being passed to u-boot in EXTRA_OEMAKE
("PYTHON=nativepython"), perhaps is should be changed to pass PYTHON2
instead of patching u-boot?
On Wed, 2019-04-17 at 04:56 +, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> ...rt-pylibfdt-Use-Python-2
Forgot the link
[1] https://bugzilla.xfce.org/show_bug.cgi?id=14789
On Wed, Apr 17, 2019 at 10:33 PM Andreas Müller wrote:
>
> On Wed, Apr 17, 2019 at 8:22 PM Mark Asselstine
> wrote:
> Seems that there are configurations where it xfconf causes trouble
> even at runtime (not only at headless bu
On Wed, Apr 17, 2019 at 8:22 PM Mark Asselstine
wrote:
Seems that there are configurations where it xfconf causes trouble
even at runtime (not only at headless builds) [1]
So adding a PACKAGECONFIG disabled by default is OK.
Could you please send this to meta-oe with
PACKAGECONFIG[gsettings-bac
Signed-off-by: Alistair Francis
---
...rt-pylibfdt-Use-Python-2-in-Makefile.patch | 37 +++
meta/recipes-bsp/u-boot/u-boot-common.inc | 4 +-
2 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-bsp/u-boot/files/0001-Revert-pylibfdt-Use-Python-2-
When UBOOT_DTB_BINARY is empty and because the code now changes
directory into ${B}, the test for the existence becomes `[ -f ]` which
succeeds and subsequently the install fails.
Reorder the code so it's clear that UBOOT_DTB_BINARY empty is an
expected configuration and then quote UBOOT_DTB_BINAR
Packages such as gdk-pixbuf can result in the following error during
the rootfs construction:
CRITICAL **: 16:51:57.223: Failed to get connection to xfconfd: Cannot
autolaunch D-Bus without X11 $DISPLAY
This is hit during the postinst-intercepts/update_pixbuf_cache.
Based on discussions upstre
On Wed, Apr 17, 2019 at 12:45 AM Yu, Mingli wrote:
>
>
>
> On 2019年04月17日 02:00, Khem Raj wrote:
> > On Tue, Apr 16, 2019 at 1:40 AM Yu, Mingli wrote:
> >>
> >>
> >>
> >> On 2019年04月16日 00:21, Adrian Bunk wrote:
> >>> On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
>
> What ar
On 4/17/19 8:59 AM, Richard Purdie wrote:
> Create a common include file which lists recipes that have ptests divided
> into 'fast' and 'slow' groups. This allows us to include ptests which
> otherwise
> may not get included in images and allows us to test the faster running things
> more regul
On Wed, 2019-04-17 at 16:59 +0100, Richard Purdie wrote:
> Move the ptest image to be based off core-image-sato instead of core-
> image-sato-sdk.
>
> This gives a better test of the ptest package dependencies and
> reduces the overall
> image size so it only contains the things we need.
>
> Sign
There are recipes not included in core-image-sato-sdk which have ptests, include
these in our ptest test image using the new include file.
Signed-off-by: Richard Purdie
---
meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-
Move the ptest image to be based off core-image-sato instead of
core-image-sato-sdk.
This gives a better test of the ptest package dependencies and reduces the
overall
image size so it only contains the things we need.
Signed-off-by: Richard Purdie
---
.../{core-image-sato-sdk-ptest.bb => cor
Create a common include file which lists recipes that have ptests divided
into 'fast' and 'slow' groups. This allows us to include ptests which otherwise
may not get included in images and allows us to test the faster running things
more regularly.
The new image allows access to these faster execu
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of
> richard.pur...@linuxfoundation.org
> Sent: den 12 april 2019 10:18
> To: Seebs
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH]
This fixes:
* gtk-icon-browser: for symbolic view almost all icons were missing
* xfce's thunar: 'home' and 'up' icons were missing. Had a long discussion with
XFCE-people [1] and asked here [2].
How could I overlook the most obvious...
[1] https://bugzilla.xfce.org/show_bug.cgi?id=14443
[2]
h
gt; > >
> > > Summary: There was 1 WARNING message shown.
> > > NOTE: Resolving any missing task queue dependencies
> > >
> > > Build Configuration:
> > > BB_VERSION = "1.43.0"
> > > BUILD_SYS= "x86_64-linux"
>
ot;
> > NATIVELSBSTRING = "universal"
> > TARGET_SYS = "i586-poky-linux"
> > MACHINE = "qemux86"
> > DISTRO = "poky"
> > DISTRO_VERSION = "2.7+snapshot-20190417"
> > TUN
quot;i586-poky-linux"
> MACHINE = "qemux86"
> DISTRO = "poky"
> DISTRO_VERSION = "2.7+snapshot-20190417"
> TUNE_FEATURES= "m32 i586"
> TARGET_FPU = ""
> meta
Would it make sense to at least as temporary work around add a flag saying
that git-lfs does or doesn't exist in HOSTTOOLS after it being added
to HOSTTOOLS_NONFATAL and then let those few recipes which already use
git-lfs to check this flag and fail early with meaningful error message
about git-lf
"--printf" only works with the stat variant provided by coreutils.
With busybox, when running grub-mkconfig, stat will fail with the
following error:
stat: unrecognized option '--printf=%T'
Usage: stat [OPTIONS] FILE...
Signed-off-by: Ovidiu Panait
---
...fig-Use-c-instead-of-printf-for-stat.p
Yes, that definitely looks wrong. Fortunately for us, we are only using SoCs
based on Cortex A53 so far so it is not something that has affected us (yet)…
Oh, and for some more messy fun, take a look at tune-cortexa32.inc. Cortex A32
uses ARMv8 but only supports aarch32. However, the tune file s
On Wed, Apr 17, 2019 at 09:57:50AM +, Bach, Pascal wrote:
> > > > Your "everyone has to install it" worry misses the much bigger
> > > > problem that git-lfs is a relatively new tool and not available in
> > > > distributions like Debian 9 or Ubuntu 16.04.
> > >
> > > Someone could certainly wr
> > > Your "everyone has to install it" worry misses the much bigger
> > > problem that git-lfs is a relatively new tool and not available in
> > > distributions like Debian 9 or Ubuntu 16.04.
> >
> > Someone could certainly write a native recipe for lfs and add that as
> > a dependency which would
On Wed, Apr 17, 2019 at 10:37:45AM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Wed, 2019-04-17 at 12:35 +0300, Adrian Bunk wrote:
>...
> > Your "everyone has to install it" worry misses the much bigger
> > problem
> > that git-lfs is a relatively new tool and not available in
> > distri
On Wed, 2019-04-17 at 12:35 +0300, Adrian Bunk wrote:
> On Wed, Apr 17, 2019 at 09:46:25AM +0100,
> richard.pur...@linuxfoundation.org wrote:
> > On Wed, 2019-04-17 at 10:20 +0800, Saini, Naveen Kumar wrote:
> > ...
> > > Should this be added to HOSTTOOLS instead so lfs files are always
> > > fetc
On Wed, Apr 17, 2019 at 09:46:25AM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Wed, 2019-04-17 at 10:20 +0800, Saini, Naveen Kumar wrote:
>...
> > Should this be added to HOSTTOOLS instead so lfs files are always
> > fetched for packages that use it?
>
> No, that would mean everyone has
On Wed, 2019-04-17 at 10:20 +0800, Saini, Naveen Kumar wrote:
>
> On Selasa 16 Apr 2019 06:23 , Richard Purdie wrote:
> > On Tue, 2019-04-16 at 13:59 +0800, Naveen Saini wrote:
> > > This provides git large file storage (lfs) extension.
> > >
> > > Include git-lfs conditionally. If git-lfs is pre
From: Changqing Li
1. since one bug in run-ptest, testcase test-bus have never been
actually run (althrough it's result is PASS).
After commit 0828850, test-bus can actually run but it
did not install:
test-service, test-shell-service, test-segfault, and
dbus-daemon-launch-helper-test
Add th
It's not caused by this change (not the previous one I believe), but today
I've noticed that aarch64 tunes don't set TUNE_PKGARCH correctly.
e.g. with raspberrypi3-64 which since this commit:
https://github.com/agherzan/meta-raspberrypi/commit/9cc89cb7341d633b6fc3a92b937b5560d26257a1
uses conf/mac
On Wed, Apr 17, 2019 at 3:06 AM Changqing Li wrote:
>
>
> On 4/16/19 6:22 PM, Richard Purdie wrote:
> > On Tue, 2019-04-16 at 17:49 +0800, changqing...@windriver.com wrote:
> >> From: Changqing Li
> >>
> >> current default locale is set to C.UTF-8, but glibc not support
> >> locale C.UTF-8. so se
On 2019年04月17日 02:00, Khem Raj wrote:
On Tue, Apr 16, 2019 at 1:40 AM Yu, Mingli wrote:
On 2019年04月16日 00:21, Adrian Bunk wrote:
On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
What are you trying to convey ? That’s what I mentioned before I began my
reply however to reiterate
On 4/16/19 9:18 PM, Adrian Bunk wrote:
On Tue, Apr 16, 2019 at 05:49:44PM +0800, changqing...@windriver.com wrote:
From: Changqing Li
* This patch is get from fedora project, link:
https://src.fedoraproject.org/rpms/glibc/blob/0457f649e3fe6299efe384da13dfc923bbe65707/f/glibc-c-utf8-locale.pat
On 4/16/19 2:36 PM, Adrian Bunk wrote:
> On Tue, Apr 16, 2019 at 12:02:04PM +, John Ernberg wrote:
>> ...
>> --- a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
>> +++ b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
>> ...
>> -PACKAGES =+ "${PN}-misc"
>> +PACKAGES =+ "${PN}-misc ${PN}-u
40 matches
Mail list logo