This provides git large file storage (lfs) extension.
Include git-lfs conditionally. If git-lfs is present on host and repo
has lfs pointers, then git-lfs will be used. If git-lfs is not present
on host, it will be ignored.
[YOCTO #13198]
(From OE-Core rev: 2968ad8514721ec06e67aaf3fd5ec7b247b343
== Series Details ==
Series: "[V2] util-linux: Make pam spec..." and 1 more
Revision: 1
URL : https://patchwork.openembedded.org/series/19285/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
== Series Details ==
Series: "util-linux: Make pam specific ..." and 1 more
Revision: 1
URL : https://patchwork.openembedded.org/series/19284/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
This helps with a case where a distro builds one image with systemd and
another with sysvinit, it ends up recompiling almost everything since
python3-native gets rebuilt and tracing dependencies with
bitbake-diffsigs shows that the chain ends at util-linux-native being
recompiled because distro fea
These postfuncs cause native recipes to rebuild when changing system
init provider between sysvinit and systemd. Some of these native recipes
are pretty early in dependency chain ( e.g. util-linux ) which can casue
rebuild of pretty much everything including compiler.
Found with bitbake-diffsigs
This helps with a case where a distro builds one image with systemd and
another with sysvinit, it ends up recompiling almost everything since
python3-native gets rebuilt and tracing dependencies with
bitbake-diffsigs shows that the chain ends at util-linux-native being
recompiled because distro fea
These postfuncs cause native recipes to rebuild when changing system
init provider between sysvinit and systemd. Some of these native recipes
are pretty early in dependency chain ( e.g. util-linux ) which can casue
rebuild of pretty much everything including compiler.
Found with bitbake-diffsigs
Signed-off-by: Khem Raj
---
.../0005-src-basic-missing.h-check-for-missing-strndupa.patch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch
b/meta/recipes-core/systemd/systemd/0005-s
On 8/14/19 11:33 PM, Bruce Ashfield wrote:
On Wed, Aug 14, 2019 at 5:48 AM Hongzhi, Song
wrote:
On 8/14/19 11:48 AM, Bruce Ashfield wrote:
On Tue, Aug 13, 2019 at 11:39 PM Bruce Ashfield
wrote:
On Tue, Aug 13, 2019 at 11:04 PM Bruce Ashfield
wrote:
On Tue, Aug 13, 2019 at 11:01 PM Hon
Fixes build regressions on risc-v
Detailed changelog is here [1]
[1]
https://git.musl-libc.org/cgit/musl/log/?qt=range&q=d0b547dfb5f7678cab6bc39dd736ed6454357ca4..29e8737f81ccc9fbadcf61a75318aa3d0516aafa
Signed-off-by: Khem Raj
---
meta/recipes-core/musl/musl_git.bb | 2 +-
1 file changed, 1 i
This API is now implemented in musl [1]
[1]
https://git.musl-libc.org/cgit/musl/commit/?id=7844ecb590893f8344324837956718001402d297
Signed-off-by: Khem Raj
---
...en-secure-versions-are-not-available.patch | 32 ---
meta/recipes-core/systemd/systemd_242.bb | 2 +-
2 files
This helps in enabling them via packageconfig from SOC layers
Signed-off-by: Khem Raj
---
meta/recipes-graphics/mesa/mesa.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 60d07f536c..fcd19884f5 100644
---
== Series Details ==
Series: linux-yocto/4.19: make drm-bochs feature available
Revision: 1
URL : https://patchwork.openembedded.org/series/19280/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have b
From: Bruce Ashfield
The other active kernel versions have this feature available. To
consistently enable the same video output for qemu, we can cherry
pick the feature to 4.19.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +-
meta/recipes-kernel/lin
On Wed, Aug 14, 2019 at 6:21 PM Richard Purdie
wrote:
>
> On Wed, 2019-08-14 at 17:26 +0200, Alexander Kanavin wrote:
> > This allows better modesetting support for the '-vga std'
> > emulated hardware provided by Qemu, which we want to
> > standardize on.
> >
> > See here for background:
> > http
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
On Wed, Aug 14, 2019 at 3:42 PM akuster808 wrote:
>
>
>
> On 8/14/19 3:29 PM, 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 whi
On 8/14/19 3:29 PM, 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 good shape.
Wil
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.
Signed-off-by: Khem Raj
---
.../libffi/0001-New
On Wed, 2019-08-14 at 17:26 +0200, Alexander Kanavin wrote:
> This allows better modesetting support for the '-vga std'
> emulated hardware provided by Qemu, which we want to
> standardize on.
>
> See here for background:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
>
> Signed-off-by
On Wed, 2019-08-14 at 22:27 +0200, Alexander Kanavin wrote:
> On Wed, 14 Aug 2019 at 14:55,
> wrote:
> > You followed up mentioning this wasn't with master-next. I think
> > there
> > is a patch in -next which will help with the empty task spin so
> > both
> > together might get us back to more no
On Wed, 14 Aug 2019 at 14:55, wrote:
> You followed up mentioning this wasn't with master-next. I think there
> is a patch in -next which will help with the empty task spin so both
> together might get us back to more normal numbers.
>
As all of these patches are now in master, I re-ran the test
On Wed, 14 Aug 2019 at 18:42, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> I'm not sure I agree with this.
>
> We are meant to work on embedded systems and 256MB should be enough to
> let us bring up X under qemu.
>
> I'm fine with some sdk/ptest images having more memory, that ma
"qmake -install qinstall" reproducer from the bugzilla ticket still
reproduces the issues every time even with latest pseudo, but that might be
different root cause than glibc-locale issue.
On Wed, Aug 14, 2019 at 6:02 PM Randy MacLeod
wrote:
> On 8/6/19 2:51 AM, Martin Jansa wrote:
> > This is
== Series Details ==
Series: gcc-cross-canadian: Drop obsolete shlibs exclusion
Revision: 1
URL : https://patchwork.openembedded.org/series/19277/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have b
On Wed, 2019-08-14 at 17:26 +0200, Alexander Kanavin wrote:
> This was already the case for various specific qemu machines,
> and 256M was found to be no longer sufficient for x86 either when
> switching X from vmware to standard vga+bochs vesa driver as provided
> by qemu (Xorg would then attempt
This is a very old change as and be inferred from the name in the comment.
We've since had many changes to pkgdata including separating it
to its own sysroot now so the reasons for this blanket exclusion are
likely long gone.
If the shlib provides were really the problem I'd much rather have
a ded
On 8/6/19 2:51 AM, Martin Jansa wrote:
This is the same reproducer I am using in:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
but with this SRCREV I haven't reproduced it yet in first 500
iterations, so it's definitely improving for me (used to reproduce it at
least once in first 50
== Series Details ==
Series: kernel-yocto: misc build / config changes
Revision: 1
URL : https://patchwork.openembedded.org/series/19276/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been execu
On Wed, Aug 14, 2019 at 5:48 AM Hongzhi, Song
wrote:
>
>
> On 8/14/19 11:48 AM, Bruce Ashfield wrote:
> > On Tue, Aug 13, 2019 at 11:39 PM Bruce Ashfield
> > wrote:
> >> On Tue, Aug 13, 2019 at 11:04 PM Bruce Ashfield
> >> wrote:
> >>>
> >>> On Tue, Aug 13, 2019 at 11:01 PM Hongzhi,
> >>> Son
== Series Details ==
Series: cmake.bbclass: add HOSTTOOLS_DIR to CMAKE_FIND_ROOT_PATH
Revision: 1
URL : https://patchwork.openembedded.org/series/19273/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests
From: Bruce Ashfield
As reported in https://bugzilla.yoctoproject.org/show_bug.cgi?id=12563,
the regex that matches valid CONFIG_ options was missing some of the
ones in net/netfilter/ipvs/Kconfig, and hence triggering invalid
option warnings.
By dropping the trailing space on the regex, we'll c
From: Bruce Ashfield
Integrating the following commit:
Add SPDX license headers to source files
Kconfiglib/* were under ISC license before they were imported
here from https://github.com/ulfalizer/Kconfiglib
Adjusting SPDX header to reflect that fact.
tools/* all have some
From: Bruce Ashfield
>From the kernel patch:
[
It was observed that the kernel embeds the path in the x86 boot
artifacts.
From https://bugzilla.yoctoproject.org/show_bug.cgi?id=13458:
[
If you turn on the buildpaths QA test, or try a reproducible build, you
discov
From: Bruce Ashfield
Adding the following fragments from meta-security to make them
centrally available and easier to maintain:
283939d5c9e kernel-cache: add yama security fragments
0b86f3fa241 kernel-cache: add ima fragments
731b466654d kernel-cache: add smack
813afe8ff47 kernel-cac
From: Bruce Ashfield
The 5.3 kernel has two changes that require tweaks to the minimal
kernel-devsrc package.
- 4ce97317f [x86/purgatory: Do not use __builtin_memcpy and __builtin_memset]
This change removes the need for arch/x86/purgatory/string.c and
instead reuses a copy in arch/x86/boot
From: Bruce Ashfield
Hi all,
This pull request is a collection of smaller fixes that I've been collecting
while I work through the 5.2/5.3 kernel intro, new libc-headers, etc. There's
no reason to make them wait while I finish that work, so here they are in a
single branch.
There's nothing majo
This is the qemu default since qemu 2.2, is generally supported better,
and is recommended by upstream. It also has already been in use for arm/risc
and ovmf.
Additional information:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-consi
This allows better modesetting support for the '-vga std'
emulated hardware provided by Qemu, which we want to
standardize on.
See here for background:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
Signed-off-by: Alexander Kanavin
---
meta/recipes-kernel/linux/linux-yocto-dev.bb |
This was already the case for various specific qemu machines,
and 256M was found to be no longer sufficient for x86 either when
switching X from vmware to standard vga+bochs vesa driver as provided
by qemu (Xorg would then attempt to clone() itself with ENOMEM returned).
Let's just accept this new
On Wed, Aug 14, 2019 at 7:57 AM Peter Kjellerstedt
wrote:
>
> > -Original Message-
> > From: richard.pur...@linuxfoundation.org
> >
> > Sent: den 14 augusti 2019 14:56
> > To: Alexander Kanavin
> > Cc: Peter Kjellerstedt ; Khem Raj
> > ; OE-core > c...@lists.openembedded.org>
> > Subjec
Since stress-ng replaces and is compatible with stress,
provide stress to be compatible with the old recipe
and binary packages.
Signed-off-by: Mikko Rapeli
---
meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb | 5 +
1 file changed, 5 insertions(+)
v2: added RCONFLICTS and RREPLACES, re
The find_program command will fail if it is used on a tool that is listed in
ASSUME_PROVIDED. This is because these tools are in the hosttools directory
which is not listed in CMAKE_FIND_ROOT_PATH so cmake will not find them.
Adding the directory HOSTTOOLS_DIR to the CMAKE_FIND_ROOT_PATH variable
Hi all,
I wanted to ask what would be a good way to fix an issue with cmake
find_program and the tools listed in ASSUME_PROVIDED. I checked against the
Warrior branch and it seems that currently find_program does not search the
hosttools directory for programs because HOSTTOOLS_DIR is not listed
> -Original Message-
> From: richard.pur...@linuxfoundation.org
>
> Sent: den 14 augusti 2019 14:56
> To: Alexander Kanavin
> Cc: Peter Kjellerstedt ; Khem Raj
> ; OE-core c...@lists.openembedded.org>
> Subject: Re: [OE-core] Long delays with latest bitbake (was: [PATCH
> 1/7] insane.bbc
On Wed, Aug 14, 2019 at 03:38:56PM +0100, Richard Purdie wrote:
> On Wed, 2019-08-14 at 15:56 +0300, Mikko Rapeli wrote:
> > Since stress-ng replaces and is compatible with stress,
> > provide stress to be compatible with the old recipe
> > and binary packages.
> >
> > Signed-off-by: Mikko Rapeli
On Wed, 2019-08-14 at 15:56 +0300, Mikko Rapeli wrote:
> Since stress-ng replaces and is compatible with stress,
> provide stress to be compatible with the old recipe
> and binary packages.
>
> Signed-off-by: Mikko Rapeli
> ---
> meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb | 4
> 1
On 8/13/19 4:25 PM, Kevin Weng via Openembedded-core wrote:
> Signed-off-by: Kevin Weng
> ---
> .../curl/curl/CVE-2018-16890.patch| 50 +
> .../curl/curl/CVE-2019-3822.patch | 47
> .../curl/curl/CVE-2019-3823.patch | 55
Since stress-ng replaces and is compatible with stress,
provide stress to be compatible with the old recipe
and binary packages.
Signed-off-by: Mikko Rapeli
---
meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-extended/stre
On Wed, 2019-08-14 at 14:08 +0200, Alexander Kanavin wrote:
> On Wed, 14 Aug 2019 at 13:36,
> wrote:
> > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > richard.pur...@linuxfoundation.org> wrote:
> > > > I had a glance at the p
On Wed, Aug 14, 2019 at 02:08:01PM +0200, Alexander Kanavin wrote:
> On Wed, 14 Aug 2019 at 13:36, wrote:
>
> > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > richard.pur...@linuxfoundation.org> wrote:
> > > > I had a glance
On Wed, 14 Aug 2019 at 14:08, Alexander Kanavin
wrote:
>
> This might sound slightly crazy but can you try commenting out this
>> line in runqueue.py:
>>
>> logger.debug(2, "Holding off tasks %s" %
>> pprint.pformat(self.holdoff_tasks))
>>
>> ?
>>
>
> Even crazier is the outcome: it helped! The w
On Wed, 14 Aug 2019 at 13:36, wrote:
> On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> > > I had a glance at the profile output from master-next and the
> > > problem
> > > wasn't where
On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> > I had a glance at the profile output from master-next and the
> > problem
> > wasn't where I thought it would be, it was in the scheduler cod
On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> I had a glance at the profile output from master-next and the problem
> wasn't where I thought it would be, it was in the scheduler code. That
> is good as those classes are effectively independent of the o
55 matches
Mail list logo
