I think it’s ok to have it in Glibc/localedef not all distros have this
version of util Linux yet and perhaps we should start creating a buildtools
tarballs which is a prerequisite for building OE and collect these
dependencies in there instead
Of sticking them in unusual places
On Fri, Aug 16, 20
On 8/16/19 4:50 PM, richard.pur...@linuxfoundation.org wrote:
On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote:
On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie
wrote:
This was discussed on IRC. We really really want to avoid that as a
dependency if we care about build performance. Its really e
On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote:
> On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie
> wrote:
> > This was discussed on IRC. We really really want to avoid that as a
> > dependency if we care about build performance. Its really easy to
> > just
> > add that in but the implications a
On 8/16/19 4:29 PM, Khem Raj wrote:
> On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie
> wrote:
>>
>> On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote:
>>> On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel <
>>> jason.wes...@windriver.com> wrote:
The hard link resolver that is built into localedef
On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie
wrote:
>
> On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote:
> > On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel <
> > jason.wes...@windriver.com> wrote:
> > > The hard link resolver that is built into localedef cannot be run
> > > in
> > > parallel. I
On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote:
> On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel <
> jason.wes...@windriver.com> wrote:
> > The hard link resolver that is built into localedef cannot be run
> > in
> > parallel. It will search sibling directories (which are be
> > processed
> > in
On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel wrote:
>
> The hard link resolver that is built into localedef cannot be run in
> parallel. It will search sibling directories (which are be processed
> in parallel) and perform a creation of a .tmp file and remove the
> original and move the .tmp file
The locale-processing in cross-localedef was proven to be unsafe to
run in parallel due to the way it tried to make hard links to files
that could disappear before the link operation was completed.
To avoid corruption of the pseudo database, and create a
deterministically generated link tree, the
The hard link resolver that is built into localedef cannot be run in
parallel. It will search sibling directories (which are be processed
in parallel) and perform a creation of a .tmp file and remove the
original and move the .tmp file in. The problem is that if a probe
occurs a hard link can be
On Fri, Aug 16, 2019 at 12:46 PM Wes Lindauer wrote:
>
> Although xz has some files that are GPLv3 licensed, none of them get
> packaged up, and therefore none of it ends up in the final rootfs. Since
> there is no GPLv3 code in the final image, we don't want to include it
> when we collect licens
== Series Details ==
Series: "iw: Fix license field to BSD-2..." and 5 more
Revision: 1
URL : https://patchwork.openembedded.org/series/19323/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
Although xz has some files that are GPLv3 licensed, none of them get
packaged up, and therefore none of it ends up in the final rootfs. Since
there is no GPLv3 code in the final image, we don't want to include it
when we collect licenses, as that would give the incorrect impression
that the image c
BSD license files must include the copyright notice.
---
meta/recipes-extended/shadow/shadow.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/shadow/shadow.inc
b/meta/recipes-extended/shadow/shadow.inc
index 7f82d20826..6d9e300739 100644
--- a/meta/rec
MIT license files must include the copyright notice.
---
meta/recipes-support/libunwind/libunwind.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/libunwind/libunwind.inc
b/meta/recipes-support/libunwind/libunwind.inc
index 36851d07ed..5726589661 100644
BSD license files must include the copyright notice.
---
meta/recipes-extended/sudo/sudo.inc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-extended/sudo/sudo.inc
b/meta/recipes-extended/sudo/sudo.inc
index 90f2039bb8..15075bcefd 100644
--- a/meta/reci
The LICENSE file states that some code is licensed under BSD, some under
ISC, and some under MIT. The LICENSE field should reflect all of these.
---
meta/recipes-connectivity/openssh/openssh_8.0p1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/open
Using just "BSD" license implies BSD-3-Clause and this recipe appears to
be closer to a BSD-2-Clause.
---
meta/recipes-connectivity/iw/iw_5.0.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/iw/iw_5.0.1.bb
b/meta/recipes-connectivity/iw/iw_5.0.1.b
== Series Details ==
Series: "gcc: Search in OE specific tar..." and 1 more
Revision: 1
URL : https://patchwork.openembedded.org/series/19322/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
On Thu, Aug 15, 2019 at 8:45 PM akuster808 wrote:
> On 8/15/19 2:31 PM, Andre McCurdy wrote:
> > On Thu, Aug 15, 2019 at 2:09 PM Richard Purdie
> > wrote:
> >> On Thu, 2019-08-15 at 09:23 +0200, Martin Jansa wrote:
> >>> NAK
> >>>
> >>> Yes, the first part was merged in warrior and is correct.
>
Thanks Martin to fix a bunch of QA issues in meta-openembedded
surfaced after this change in core, there still are some left if
someone wants to take a look at it
https://errors.yoctoproject.org/Errors/Build/87032/
On Tue, Aug 13, 2019 at 11:24 AM Alexander Kanavin
wrote:
>
> Recursive RDEPENDS
libffi 3.1 release has been a bit aged and new architectures, compilers
have since been come on stage to compile it, we have been carrying
patches, but its better to use the latest 3.3 rc0 which has lot of these
issues handled and is in good shape.
Use 3.2.1+3.3-rc0 for PV to keep room for upgrade
We put gcclibir to be /usr/lib//... and not default
usr/lib/gcc/, therefore make the include search path also look
into this directory, this should help in finding gcc headers like omp.h
Signed-off-by: Khem Raj
Cc: Martin Jansa
---
.../0021-Ensure-target-gcc-headers-can-be-included.patch | 8 +
== Series Details ==
Series: YOCTO #12937 - Consistent naming scheme for deployed artifacts
Revision: 1
URL : https://patchwork.openembedded.org/series/19321/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several
On Fri, Aug 16, 2019 at 04:54:48PM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Fri, 2019-08-16 at 17:00 +0200, Martin Jansa wrote:
> > > Will try to bump BB_NUMBER_THREADS from 8 to 72.
> >
> > I've tried to remove icecc.bbclass inherit (because it does things
> > while parsing and RP p
* drop ${PKGE}-${PKGV}-${PR} from kernel artifacts names (this is the
latest build) and add it only in hardlinks created in do_deploy_links
so that we can use PKGR there again (because these links are generally
used only by human operators and they don't have their own TASKHASH or
the IMAGE
* do_install doesn't use whole "version" as do_deploy does, e.g.
${PKGE}-${PKGV}-${PKGR}-${MACHINE}
it installs only the files with only ${KERNEL_VERSION} in filename or
path, so it doesn't need expanded AUTOINC value in PKGV nor
EXPANDPRAUTO in PKGR like do_deploy does
* it was introduced
* otherwise PKGR seen in do_install, do_deploy and do_deploy_links will
have different value in each of them (PRSERV will return different
value of EXTENDPRAUTO because TASKHASH is different for each of these
tasks and also cause unnecessary multiple EXTENDPRAUTO increments for
each build).
* just to make sure it looks like bash variable not bitbake variable in
run.do_* scripts
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes/kernel.bbclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/ker
* just RFC, the part for images isn't finished yet and there is
still some issue with DATETIME when kernel artifacts are used
from sstate, this is just to validate the idea behind
[YOCTO #12937] before finishing the implementation (it's already
finished and used by various LGE builds, but h
* similar to kernel-artifact-names for other recipes/bbclasses which
need to use some deployed artifacts
* bitbake.conf: move IMAGE_BASENAME, IMAGE_VERSION_SUFFIX, IMAGE_NAME,
IMAGE_LINK_NAME variables
* image_types.bbclass: move IMAGE_NAME_SUFFIX variable
* currently IMAGE_NAME_SUFFIX is us
Let me explain a bit what these changes do for us in LGE.
We have jenkins jobs for CI as well for official releases.
All built artifacts are moved from jenkins builder to fileserver after
the build.
Each jobs have some identifier which is then included in the filenames
of all relevant build arti
On Thu, Aug 15, 2019 at 11:40 PM Jacob Kroon wrote:
>
> Hi,
>
> On 8/15/19 11:31 PM, Alistair Francis wrote:
> > Signed-off-by: Alistair Francis
> > ---
> > meta/conf/machine/include/riscv/qemuriscv.inc | 2 +-
> > meta/conf/machine/qemuriscv64.conf| 2 --
> > 2 files changed, 1 i
do_package has PKGDESTWORK as a cleandir and do_packagedata has it as an
sstate-input
dir. This means do_package wipes out the directory at both do_package and
do_package_setscene.
do_package_setscene and do_packagedata_setscene can run in parallel when
installing from
sstate which means they c
The layer checks are designed to work with OEBasicHash so ensure that handler
is in use rather than the new hash equivalency one as an example.
Signed-off-by: Richard Purdie
---
scripts/lib/checklayer/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/lib/che
On Fri, 2019-08-16 at 17:00 +0200, Martin Jansa wrote:
> > Will try to bump BB_NUMBER_THREADS from 8 to 72.
>
> I've tried to remove icecc.bbclass inherit (because it does things
> while parsing and RP probably doesn't have it inherited), but that
> didn't save much time.
>
> All 3 tests were wit
On Fri, Aug 16, 2019 at 5:00 AM Martin Jansa wrote:
>
> Hi,
>
> I have an app which includes omp.h from gomp, it used to find it without
> adding any -I for that (with just -fopenmp to enable openmp).
>
> Now the header file is included in RSS:
> lib32-recipe-sysroot/usr/lib/arm-oemllib32-linux-g
> > I think this supports my point about being more interested in patches
> > allowing people to extend/customise buildhistory than just adding X.
> >
> > Whilst we want to have good defaults, there are always going to be
> > niche cases for people wanting to extend it...
>
>
> Agreed. Then we ca
On Fri, Aug 16, 2019 at 7:48 AM Richard Purdie
wrote:
>
> On Wed, 2019-08-14 at 16:00 -0700, Khem Raj wrote:
> > libffi 3.1 release has been a bit aged and new architectures,
> > compilers
> > have since been come on stage to compile it, we have been carrying
> > patches, but its better to use the
> Will try to bump BB_NUMBER_THREADS from 8 to 72.
I've tried to remove icecc.bbclass inherit (because it does things while
parsing and RP probably doesn't have it inherited), but that didn't save
much time.
All 3 tests were with bitbake 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
94m19.081s 8 BB_N
On Wed, 2019-08-14 at 16:00 -0700, Khem Raj wrote:
> libffi 3.1 release has been a bit aged and new architectures,
> compilers
> have since been come on stage to compile it, we have been carrying
> patches, but its better to use the latest 3.3 rc0 which has lot of
> these
> issues handled and is in
Removed upstreamed patches.
Signed-off-by: Oleksandr Kravchuk
---
...-t-overwrite-src_ofonod_DEPENDENCIES.patch | 50 ---
...Add-check-for-explicit_bzero-support.patch | 27 --
.../0001-build-Fix-a-race-condition.patch | 28 ---
...in-Quiet-ld-errors-with-exte
Hi,
I have an app which includes omp.h from gomp, it used to find it without
adding any -I for that (with just -fopenmp to enable openmp).
Now the header file is included in RSS:
lib32-recipe-sysroot/usr/lib/arm-oemllib32-linux-gnueabi/9.2.0/include/omp.h
but no longer found in default search dir
On Thu, Aug 15, 2019 at 05:05:48PM +0200, Martin Jansa wrote:
> On Tue, Aug 13, 2019 at 10:04:08AM +0100, Richard Purdie wrote:
> > On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote:
> > > Comparing that build to a corresponding do-nothing build with Thud,
> > > the time difference matche
== Series Details ==
Series: dpkg: Use less as pager (rev3)
Revision: 3
URL : https://patchwork.openembedded.org/series/18240/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the
From: Ricardo Ribalda Delgado
Debian traditionaly uses /usr/bin/pager as the system pager, which is a
link to the user preferred pager. This is a Debianism.
Without this patch:
root@qt5122:~# dpkg -l
sh: pager: command not found
dpkg-query: error: showing package list on pager subprocess return
do_prepare_recipe_sysroot may perform groupadd, which requires pseudo.
However, do_prepare_recipe_sysroot does not depend on pseudo explicitly,
which sometimes causes a build error when building a recipe that adds
groups.
This issue only occurs when executing do_prepare_recipe_sysroot for a
recipe
Signed-off-by: Yi Zhao
---
meta/recipes-extended/screen/screen_4.6.2.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/screen/screen_4.6.2.bb
b/meta/recipes-extended/screen/screen_4.6.2.bb
index 24ec751..21b476d 100644
--- a/meta/recipes-extended/scre
hi there.
just a reminder!
cheers
On Tue, Jul 30, 2019 at 4:46 PM Nicolas Dechesne
wrote:
>
> Dear all,
>
> The Community Bridge platform was launched earlier this year by the
> Linux Foundation. It’s a set of services available to LF projects to
> help them build stronger ecosystems, and foster
Hi,
Some DISTRO_FEATURES related to systemd have been enabled in local.conf
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
KERNEL_FEATURES_app
49 matches
Mail list logo
