Hi Adrian,
Thanks for explaining things and helping me out.
Once I have stable builds then will try your suggestion as well.
Ankur
On Mon, Nov 25, 2019 at 1:10 PM Adrian Bunk wrote:
> On Mon, Nov 25, 2019 at 07:26:58PM +, Ross Burton wrote:
> > On 25/11/2019 18:37, Ankur Tyagi wrote:
> >
Hi Ross,
I just used arago distro as it is but you are right, once I have stable
builds
with default configuration then I will try your suggestion.
Thanks for your help
Ankur
On Mon, Nov 25, 2019 at 12:58 PM Ross Burton wrote:
> On 25/11/2019 20:22, Ankur Tyagi wrote:
> > # Select external
From: Wang Mingyu
-Added PACKAGECONFIG to solve compilation problems with musl.
Signed-off-by: Wang Mingyu
---
meta/recipes-extended/cronie/{cronie_1.5.4.bb => cronie_1.5.5.bb} | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
rename meta/recipes-extended/cronie/{cronie_1.5.4.bb =>
On 2019/11/19 上午11:15, kai.k...@windriver.com wrote:
From: Kai Kang
When kernel-devicetree is in RRECOMMENDS such as via variable
MACHINE_EXTRA_RRECOMMENDS for some bsp, it shows QA warning of multilib:
| WARNING: lib32-packagegroup-base-1.0-r83 do_package: QA Issue:
| lib32-packagegroup-base
Hi, Alex
OK, I will remake the patch of cmake and cmake-native and resubmit.
Wang
From: Alexander Kanavin [mailto:alex.kana...@gmail.com]
Sent: Friday, November 22, 2019 7:56 PM
To: Wang, Mingyu/王 鸣瑜
Cc: OE-core
Subject: Re: [OE-core] [PATCH v2] cmake-native:upgrade 3.15.3 -> 3.15.5
On Fri,
It seems like libcap wants to support use of pthread by the linking application
without mandating it, so we can’t pass -pthread, and I’m not sure a configure
check would help, unless it wants to pull in pthread unconditionally. But I may
be misunderstanding the libcap commits, and am
Good call, no idea how I missed that one.
On Nov 25, 2019, 3:28 PM -0700, Khem Raj , wrote:
> On Mon, Nov 25, 2019 at 2:12 PM Christopher Larson wrote:
> >
> > From: Christopher Larson
> >
> > Fix this error seen when using dosfsck -l to list fs contents:
> >
> > CP437: Invalid argument
> >
> >
== Series Details ==
Series: "acpica: correct flex/bison dep..." and 2 more
Revision: 1
URL : https://patchwork.openembedded.org/series/21349/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
On Mon, Nov 25, 2019 at 2:12 PM Christopher Larson wrote:
>
> From: Christopher Larson
>
> Fix this error seen when using dosfsck -l to list fs contents:
>
> CP437: Invalid argument
>
> Signed-off-by: Christopher Larson
> ---
> meta/recipes-devtools/dosfstools/dosfstools_4.1.bb | 3 +++
>
On Mon, Nov 25, 2019 at 2:13 PM Christopher Larson wrote:
>
> From: Christopher Larson
>
> The libcap-ng build doesn't pass -pthread and can fail to link.
>
perhaps, adding a configure time check for pthread.h would be possible
AC_CHECK_HEADERS(pthread.h, [], [AC_MSG_WARN(pthread.h not found,
From: Christopher Larson
The libcap-ng build doesn't pass -pthread and can fail to link.
Signed-off-by: Christopher Larson
---
meta/recipes-support/libcap-ng/libcap-ng.inc | 1 +
.../libcap-ng/revert-pthread_atfork-fix.patch | 56 ++
2 files changed, 57
From: Christopher Larson
Fix this error seen when using dosfsck -l to list fs contents:
CP437: Invalid argument
Signed-off-by: Christopher Larson
---
meta/recipes-devtools/dosfstools/dosfstools_4.1.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: Christopher Larson
This project doesn't require target flex or bison, just the natives,
and it uses m4 explicitly in its configuration.
Signed-off-by: Christopher Larson
---
meta/recipes-extended/acpica/acpica_20191018.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Change all recipes to https where we get an http 301 permanent redirect.
Signed-off-by: Stefan Müller-Klieser
---
meta/recipes-core/busybox/busybox.inc | 2 +-
meta/recipes-core/busybox/busybox_1.31.0.bb | 2 +-
meta/recipes-core/dbus/dbus-glib_0.110.bb
On Mon, Nov 25, 2019 at 07:26:58PM +, Ross Burton wrote:
> On 25/11/2019 18:37, Ankur Tyagi wrote:
> > Hi,
> >
> > Based upon "thud" branch, I created core-image-minimal for am335x-evm
> > board and resulting image size is very big(71M)
>
> If disk size is important then a good first step is
On 25/11/2019 20:22, Ankur Tyagi wrote:
# Select external binary prebuilt Arm toolchain
TCMODE = "external-arm"
TCLIBC = "external-arm-toolchain"
FWIW, I don't see what the value in external toolchains actually is.
You might get better results by simply setting:
TCMODE = "default"
TCLIB =
On 25/11/2019 19:54, Ankur Tyagi wrote:
That could be it.
How can I make sure debug stripping is enabled?
It's on by default. I'd look at your configuration to see what you've
done to turn it off...
--
___
Openembedded-core mailing list
Hi,
tl;dr: Afaict, using DATETIME in PV is currently impossible due to
commit 9ca2fad2 ("image: Expand PV to avoid AUTOREV parsing failures").
Do not use DATETIME in PV.
In an effort to use timestamps for development builds we tried to use
DATETIME in the PV variable of an image recipe
Hi Adrian,
Seems you are correct. My distro is based upon TI's Arago distro which uses
following
# Select external binary prebuilt Arm toolchain
TCMODE = "external-arm"
TCLIBC = "external-arm-toolchain"
And external-arm-toolchain.bb recipe has following
require
On Tue, Nov 26, 2019 at 07:37:48AM +1300, Ankur Tyagi wrote:
> Hi,
>
> Based upon "thud" branch, I created core-image-minimal for am335x-evm board
> and resulting image size is very big (71M)
>
> /lib dir is 39M and /usr/lib is 24M.
>...
> -rwxr-xr-x 1 ankur ankur *16537400* Nov 26 06:41
That could be it.
How can I make sure debug stripping is enabled?
thanks
Ankur
On Tue, Nov 26, 2019 at 8:49 AM Ross Burton wrote:
> On 25/11/2019 19:33, Ankur Tyagi wrote:
> > Thanks for the suggestion.
> > But curious why libs are so big now?
>
> The same files on my system:
>
> -rwxr-xr-x
On 25/11/2019 19:33, Ankur Tyagi wrote:
Thanks for the suggestion.
But curious why libs are so big now?
The same files on my system:
-rwxr-xr-x root/root 1806504 2019-11-04 21:14 ./lib64/libc-2.30.so
-rwxr-xr-x root/root113296 2019-11-04 21:14 ./lib64/libpthread-2.30.so
-rw-r--r--
Hi Ross,
Thanks for the suggestion.
But curious why libs are so big now?
Regards
Ankur
On Tue, Nov 26, 2019 at 8:27 AM Ross Burton wrote:
> On 25/11/2019 18:37, Ankur Tyagi wrote:
> > Hi,
> >
> > Based upon "thud" branch, I created core-image-minimal for am335x-evm
> > board and resulting
On 25/11/2019 18:37, Ankur Tyagi wrote:
Hi,
Based upon "thud" branch, I created core-image-minimal for am335x-evm
board and resulting image size is very big(71M)
If disk size is important then a good first step is to use musl instead
of glibc:
TCLIBC = "musl"
The C++ runtime is also
Hi,
Based upon "thud" branch, I created core-image-minimal for am335x-evm board
and resulting image size is very big (71M)
/lib dir is 39M and /usr/lib is 24M.
How can the libraries be trimmed down to fit image inside 40M partition? I
can see duplicacy in /usr/lib and symlink should help but
On Mon, Nov 25, 2019 at 8:33 AM Alexander Kanavin
wrote:
>
> I have reproduced it with gcc and musl. The omp.h is in a non-standard
> location in recipe-sysroot/usr/lib, which works ok with glibc, but breaks
> with musl. How gcc is able to find it (or not) is too arcane for my knowledge
> :(
>
All,
The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:
From: Ross Burton
When cross-compiling Python 2 you need a native pgen binary, but the cross
recipe can't do this on it's own so we build it in python-native and install it.
The rule to build pgen was also causing a complete rebuild of all of the
generated sources, which meant that building
With this change, python 2.x recipes are ready to be moved to an external layer.
Once that happens, they will be removed from oe-core.
Signed-off-by: Alexander Kanavin
---
meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 2 --
1 file changed, 2 deletions(-)
diff --git
From: Ross Burton
There's no need to add HOSTPGEN or HOSTPYTHON variables when we can just
override the existing PGEN and PYTHON_FOR_BUILD variables.
Signed-off-by: Ross Burton
---
.../01-use-proper-tools-for-cross-build.patch | 65 +--
.../fix_for_using_different_libdir.patch
Signed-off-by: Alexander Kanavin
---
meta/classes/base.bbclass| 5 -
meta/conf/bitbake.conf | 5 ++---
scripts/oe-buildenv-internal | 7 ---
3 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index
Signed-off-by: Alexander Kanavin
---
meta/recipes-bsp/u-boot/u-boot-common.inc | 5 -
...-boot-fw-utils_2019.10.bb => u-boot-fw-utils_2020.01.bb} | 0
.../{u-boot-tools_2019.10.bb => u-boot-tools_2020.01.bb}| 0
meta/recipes-bsp/u-boot/u-boot.inc
On Sun, 24 Nov 2019 at 00:04, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Wed, 2019-11-20 at 14:44 +0100, Alexander Kanavin wrote:
> > Signed-off-by: Alexander Kanavin
> > ---
> > .../p11-kit/p11-kit_0.23.18.1.bb | 26 +++
> >
> > 1 file
I have reproduced it with gcc and musl. The omp.h is in a non-standard
location in recipe-sysroot/usr/lib, which works ok with glibc, but breaks
with musl. How gcc is able to find it (or not) is too arcane for my
knowledge :(
I added --disable-openmp for musl; the major use for openmp is to speed
On Mon, Nov 25, 2019 at 7:19 AM Alexander Kanavin
wrote:
>
> omp.h is coming from gcc-runtime. Which compiler are you using? Probably an
> override (specific for that compiler) is needed.
if you looked into logs then you must have noticed its clang. I was
wonder is openMP a hard dependency
for
I'd like to use a single set of device tree sources for both the kernel and
U-Boot. I'd like to take the dtb files generated when compiling the kernel
and use it for U-Boot. This means that I need to able to find them from the
U-Boot recipe - ideally without having a list of them there.
So, I
omp.h is coming from gcc-runtime. Which compiler are you using? Probably an
override (specific for that compiler) is needed.
Alex
On Sat, 23 Nov 2019 at 18:48, Khem Raj wrote:
> breaks with needing openmp
>
> http://errors.yoctoproject.org/Errors/Details/282827/
>
> perhaps needs explicit
Hi Ross,
On Nov 25, 2019, at 2:55 PM, Ross Burton ross.bur...@intel.com wrote:
> On 22/11/2019 11:08, Jean-Marie LEMETAYER wrote:
>> I based my work on the current implementation, but I never thought of
>> refactoring as much. I have however some concerns about the management
>> of the registry
On 19/11/2019 15:21, nick83ola wrote:
Dear Openembedded developer,
a lot of python recipes need to add the
BBCLASSEXTEND = "native nativesdk"
To the recipe to build the native version of the package.
Wouldn't be better to add it to the pythonnative.bbclass by default?
No.
On 20/11/2019 09:33, Jean-Marie LEMETAYER wrote:
+python do_fetch_append() {
+"""
+Fetch all dependencies tarball to DL_DIR.
+"""
+bb.fetch2.npm.fetch_dependencies(d)
+}
+
+python do_unpack_append() {
+"""
+Unpack all dependencies tarball to the 'node_modules'
On 22/11/2019 11:08, Jean-Marie LEMETAYER wrote:
I based my work on the current implementation, but I never thought of
refactoring as much. I have however some concerns about the management
of the registry and the development dependencies. I will try to come
back with a v4.
There's a lot of
On 21/11/2019 13:59, Phil Blundell wrote:
I also have at least a passing fondness for lrzsz and if a small amount
of maintenance now will suffice to keep it working for another 21 years
then I think I would consider that a good outcome. I will have a quick
look at the code and see if I can fix
The last user of this obsolete recipe (abandoned upstream in 2010, removed from
oe-core build dependencies in 2012) has now been deleted from oe-core, so delete
the recipe too.
Signed-off-by: Ross Burton
---
meta/conf/distro/include/maintainers.inc | 1 -
texi2html isn't a build requirement and hasn't been since 2012 (oe-core
aa1c451).
Signed-off-by: Ross Burton
---
meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
Intltool is deprecated these days, as gettext can handle almost everything
intltool could. Remove it from the SDK packagegroups, if it is needed then the
user can add it explicitly.
Signed-off-by: Ross Burton
---
meta/recipes-core/packagegroups/packagegroup-core-sdk.bb | 1 -
1 file changed, 1
Very little software needs intltool to build, and we don't need it on the host
to build Poky.
Signed-off-by: Ross Burton
---
meta/recipes-core/packagegroups/packagegroup-self-hosted.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
This avoids including irrelevant information when calculating the
license checksum.
License-Update: Trim the text part used for the license file checksum
Signed-off-by: Peter Kjellerstedt
---
meta/recipes-devtools/opkg/opkg_0.4.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This avoids including irrelevant information when calculating the
license checksum.
License-Update: Trim the text part used for the license file checksum
Signed-off-by: Peter Kjellerstedt
---
meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This avoids including irrelevant information when calculating the
license checksum.
License-Update: Trim the text part used for the license file checksum
Signed-off-by: Peter Kjellerstedt
---
meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The LICENSE file contains all the license information so there is no
need to also include it from the png.h file (and additionally some
lines were left out from the latter).
License-Update: Remove duplicate license information
Signed-off-by: Peter Kjellerstedt
---
Hi,
On 2019-11-15 17:09, Stefan Agner wrote:
> From: Stefan Agner
>
> Make sure that the (newer) /dev/pts/ptmx is accessible by users. This
> is useful e.g. when running containers which symlink /dev/ptmx to
> /dev/pts/ptmx on start. The default mode (000) does not allow to
> create ptys inside
There is python gdb script for static libstdc++ archives as well
fixes
ERROR: gcc-runtime-9.2.0-r0 do_package: QA Issue: gcc-runtime:
Files/directories were installed but not shipped in any package:
/usr/lib/libstdc++.a-gdb.py
Signed-off-by: Khem Raj
---
Signed-off-by: Khem Raj
---
...64bit-time_t-for-32bit-architectures.patch | 77 +++
meta/recipes-graphics/wayland/mtdev_1.1.5.bb | 4 +-
2 files changed, 80 insertions(+), 1 deletion(-)
create mode 100644
Signed-off-by: Khem Raj
---
...64bit-time_t-for-32bit-architectures.patch | 386 ++
.../wayland/libinput_1.14.3.bb| 4 +-
2 files changed, 389 insertions(+), 1 deletion(-)
create mode 100644
Signed-off-by: Khem Raj
---
.../64bit_time_t_support.patch| 51 +++
.../xorg-driver/xf86-input-synaptics_1.9.1.bb | 2 +
2 files changed, 53 insertions(+)
create mode 100644
meta/recipes-graphics/xorg-driver/xf86-input-synaptics/64bit_time_t_support.patch
diff
Ping on this, it hasn't been accepted yet but also hasn't had any review.
On Mon, 11 Nov 2019, at 14:16, Paul Barker wrote:
> 6 new test cases are added to cover the various archiver modes
> documented at the top of archiver.bbclass. Each test sets the
> appropriate configuration options, runs
56 matches
Mail list logo
