On Fri, Mar 09, 2018 at 11:56:58PM +, Bystricky, Juro wrote:
> I forgot to mention that if there are no objections against this patchset, I
> intend to do the same/equivalent upgrades for other releases with gcc 6x
> (rocko, pyro, ...) and also upgrade gcc5.x and 4.9x where present.
Thanks
On Fri, Mar 9, 2018 at 6:55 PM Andre McCurdy wrote:
> On Fri, Mar 9, 2018 at 6:25 PM, Bystricky, Juro
> wrote:
> > This was morty upgrade, which did not have those patches to begin with,
> I did not remove them. The patches were not in rocko either, in the end I
> got them from master (gcc6.4
On Wed, Feb 21, 2018 at 1:40 PM, Andre McCurdy wrote:
> On Tue, Jan 23, 2018 at 12:16 PM, Andre McCurdy wrote:
>> On Tue, Dec 5, 2017 at 5:35 PM, Andre McCurdy wrote:
>>> From: Ming Liu
>>>
>>> A flaw was found on my Ubuntu 14.04.5 LTS, on which that gnome-terminal is
>>> the default terminal,
On Fri, Mar 9, 2018 at 4:00 PM, Patchwork
wrote:
> == Series Details ==
>
> Series: gcc6: Upgrade to 6.4.0 (latest stable series release) (rev3)
> Revision: 3
> URL : https://patchwork.openembedded.org/series/11226/
> State : failure
>
> == Summary ==
>
> Thank you for submitting this patch seri
On Fri, Mar 9, 2018 at 6:25 PM, Bystricky, Juro
wrote:
> This was morty upgrade, which did not have those patches to begin with, I did
> not remove them. The patches were not in rocko either, in the end I got them
> from master (gcc6.4 was eventually removed completely),
> Backporting of ARM s
This was morty upgrade, which did not have those patches to begin with, I did
not remove them. The patches were not in rocko either, in the end I got them
from master (gcc6.4 was eventually removed completely),
Backporting of ARM specific patches was not the objective. ( I was not aware
that 6
On Fri, Mar 9, 2018 at 3:49 PM, Juro Bystricky wrote:
> Second attempt. Added some more patches, mostly ARM specific.
> AFAIK this patchset passed all x86-64 tests.
>
> I also did some limited testing with meta-raspberrypi and musl library.
>
> (raspberrypi did not build with v1 of the patchset)
Juro,
On 03/09/2018 03:56 PM, Bystricky, Juro wrote:
> I forgot to mention that if there are no objections against this patchset, I
> intend to do the same/equivalent upgrades for other releases with gcc 6x
> (rocko, pyro, ...) and also upgrade gcc5.x and 4.9x where present.
Thanks for this w
Most distros have switched to this, and we're seeing better results in
some areas as well. E.g., on a NUC6CAYS the x11perf -aa10text and
-rgb10text results see a 20x increase.
[YOCTO #12019].
[YOCTO #12590].
Signed-off-by: California Sullivan
---
meta/conf/machine/include/x86-base.inc | 4 ++--
== Series Details ==
Series: gcc6: Upgrade to 6.4.0 (latest stable series release) (rev3)
Revision: 3
URL : https://patchwork.openembedded.org/series/11226/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several te
I forgot to mention that if there are no objections against this patchset, I
intend to do the same/equivalent upgrades for other releases with gcc 6x
(rocko, pyro, ...) and also upgrade gcc5.x and 4.9x where present.
From: Bystricky, Juro
Sent: Friday, M
Second attempt. Added some more patches, mostly ARM specific.
AFAIK this patchset passed all x86-64 tests.
I also did some limited testing with meta-raspberrypi and musl library.
(raspberrypi did not build with v1 of the patchset)
Juro Bystricky (1):
gcc6: Upgrade to 6.4.0 (latest stable seri
On 03/09/2018 10:55 PM, Victor Kamensky wrote:
I've set to write response why systemtap-utils is really
needed and ended up doing below :). Does it look acceptable
direction to you?
Yes.
The only controvercial item left from my original ask is
IMAGE_GEN_COMBINED_DEBUGFS build option that is s
Ignoring patch context increases the chances of patches being
applied incorrectly. Depending on what code is being patched, this can go
completely unnoticed and create subtle bugs, sometimes with security
implications.
Please see here for a specific example:
https://bugzilla.yoctoproject.org/show
Hi Alex,
On Tue, 6 Mar 2018, Alexander Kanavin wrote:
On 03/06/2018 07:50 PM, Victor Kamensky wrote:
I am a fan of SystemTap and big fan of OE. Systemtap and OE use case I have
on my mind is the following:
Hello Victor,
even though I'm listed as the maintainer of systemtap, I do not actuall
Some architectures e.g. riscv gcc does not add -D_REENTRANT
when enabling pthreads. Help it here by adding these options
while gcc gets fixed
Signed-off-by: Khem Raj
---
meta/recipes-support/liburcu/liburcu_0.10.1.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/libu
Signed-off-by: Khem Raj
---
meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb | 2 ++
meta/recipes-devtools/gdb/gdb-common.inc | 1 +
meta/recipes-kernel/lttng/lttng-tools_2.10.2.bb| 1 +
3 files changed, 4 insertions(+)
diff --git a
Dont build yet
Signed-off-by: Khem Raj
---
meta/recipes-core/packagegroups/packagegroup-core-sdk.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
index 393f0d3d13..a137e7748
These packages found failing on building extended images on riscv64
The following changes since commit e4da78229f0bd67fd34928eafe48dbdc9e8da050:
e2fsprogs: Add comment on why touch is needed (2018-03-09 11:09:39 -0800)
are available in the Git repository at:
git://git.openembedded.org/opene
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
On Fri, 2018-03-09 at 17:56 +, Manjukumar Harthikote Matha wrote:
>
> >
> > -Original Message-
> > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> > Sent: Friday, March 09, 2018 5:27 AM
> > To: Bhargava Sreekantappa Gayathri ;
> > openembedded-
> > c...@lists.openem
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
It became out of date (missing newly added files), and seems no longer
necessary for builds.
Signed-off-by: Alexander Kanavin
---
meta/recipes-extended/acpica/acpica_20170303.bb| 1 -
meta/recipes-extended/acpica/files/no-werror.patch | 32 --
2 files changed, 33 deleti
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
Due to patch fuzz it was applied again in a different place.
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/qemu/qemu/glibc-2.25.patch | 74
meta/recipes-devtools/qemu/qemu_2.11.1.bb| 1 -
2 files changed, 75 deletions(-)
delete mode 100644 meta/rec
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
The patch was applied in a completely incorrect spot (due to fuzz),
no one noticed or complained. Meanwhile upstream says the issue
has been resolved differently:
https://rt.openssl.org/Ticket/Display.html?id=3759&user=guest&pass=guest
Signed-off-by: Alexander Kanavin
---
.../openssl-1.0.2n/open
Due to patch fuzz, it was applied again, so the same code sequence was
repeated twice. Not sure if that caused any bugs, but certainly wasn't
the right thing to do.
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/gcc/gcc-7.3.inc | 1 -
...le-non-legitimate-address-in-ris
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
The new rule was patched into the makefile twice.
Signed-off-by: Alexander Kanavin
---
.../pcmciautils/pcmciautils-018/makefile_race.patch| 14 --
1 file changed, 14 deletions(-)
diff --git a/meta/recipes-bsp/pcmciautils/pcmciautils-018/makefile_race.patch
b/meta/recipes-bs
From: Ross Burton
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patc
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Friday, March 09, 2018 5:27 AM
> To: Bhargava Sreekantappa Gayathri ; openembedded-
> c...@lists.openembedded.org; Manjukumar Harthikote Matha
>
> Subject: Re: [OE-core] [PATCH] own-mirrors.bb
On Fri, Mar 9, 2018 at 7:56 AM, Richard Purdie
wrote:
> On Fri, 2018-03-09 at 03:00 -0800, Khem Raj wrote:
>> Some architectures e.g. riscv gcc does not add -D_REENTRANT
>> when enabling pthreads. Help it here by adding these options
>> while gcc gets fixed
>>
>> Signed-off-by: Khem Raj
>> ---
>>
On Fri, 2018-03-09 at 03:00 -0800, Khem Raj wrote:
> Some architectures e.g. riscv gcc does not add -D_REENTRANT
> when enabling pthreads. Help it here by adding these options
> while gcc gets fixed
>
> Signed-off-by: Khem Raj
> ---
> meta/recipes-support/liburcu/liburcu_0.10.1.bb | 2 ++
> 1 fi
On Thu, 2018-03-08 at 17:49 -0800, Bhargava Sreekantappa Gayathri
wrote:
> If BB_NO_NETWORK is set to 1, and local download directory is added
> as
> PREMIRRORS_prepend in conf file, PREMIRRORS variable will have
> SOURCE_MIRROR_URL as the first url. This causes build to fail as
> network
> access
From: André Draszik
The testdata.json is being written to DEPLOY_DIR_IMAGE directly,
thus bypassing sstate, which results in an ever growing list
of files.
Write them to IMGDEPLOYDIR instead, so as to benefit from the
automatic management via sstate.
Signed-off-by: André Draszik
---
meta/clas
Ncurses doesn't honour ${libdir} for terminfo, so try more options to remove it.
Signed-off-by: Koen Kooi
---
meta/recipes-core/ncurses/ncurses.inc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.i
Particularly, this was causing 'devtool modify' to erroneously add those
.orig files into commits. This was getting in the way, if the goal
was to amend/update those existing patches.
Signed-off-by: Alexander Kanavin
---
meta/lib/oe/patch.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is very useful for updating patch context so that any fuzz is eliminated.
Simply issue:
devtool modify
devtool finish --force-patch-refresh
Without this flag, devtool will not deem the commits in the workspace
different to patches in the layer, even if the commits have different,
up-to-da
Signed-off-by: Khem Raj
---
meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb | 2 ++
meta/recipes-devtools/gdb/gdb-common.inc | 1 +
meta/recipes-kernel/lttng/lttng-tools_2.10.2.bb| 1 +
3 files changed, 4 insertions(+)
diff --git a
Some architectures e.g. riscv gcc does not add -D_REENTRANT
when enabling pthreads. Help it here by adding these options
while gcc gets fixed
Signed-off-by: Khem Raj
---
meta/recipes-support/liburcu/liburcu_0.10.1.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/libu
Dont build yet
Signed-off-by: Khem Raj
---
meta/recipes-core/packagegroups/packagegroup-core-sdk.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
b/meta/recipes-core/packagegroups/packagegroup-core-sdk.bb
index 393f0d3d13..a137e7748
The recipes were using 'basename' to turn '/usr/lib' into 'lib', which breaks
when libdir is '/usr/lib/tuple', leading to libraries ending up in
'/usr/tuple', which isn't in FILES_*. Change the logic to use sed to strip the
prefix instead.
Signed-off-by: Koen Kooi
---
meta/recipes-connectivit
Other sections of the .inc already use mkdir -p, so use it here as well.
Signed-off-by: Koen Kooi
---
meta/recipes-core/ncurses/ncurses.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index 1f2
I see this, too.
BTW, some more info:
This looks similar to
https://github.com/systemd/systemd/issues/234
and was worked-around in systemd commit aac7c5ed8bc6
("build-sys: hide magic section variables from exported symbols")
until reverted in commit 780950a2ba58 ("Revert "build-sys: hide
mag
70 matches
Mail list logo
