From: Martin Jansa
* temporary work around for build issue on armv4t:
| cp/decl.o: In function `bad_specifiers':
| gcc-4.8.0-r0/gcc-4.8.0/gcc/cp/decl.c:7171:(.text.unlikely+0x24): relocation
truncated to fit: R_ARM_THM_CALL against symbol `error(char const*, ...)'
defined in .glue_7 section
On 18 September 2013 22:16, Richard Purdie
wrote:
> Thanks for the report. I looked into it and somehow the patch was
> corrupted. I've pushed a fix in.
There was a typo in my patch and instead of re-generating it I did the
transposition in emacs, which presumably decided to be "clever" and
re-wr
On Wed, 2013-09-18 at 22:28 +0200, Eric Bénard wrote:
> Hi Ross,
>
> Le Wed, 18 Sep 2013 17:48:45 +0100,
> Ross Burton a écrit :
> > diff --git a/meta/recipes-devtools/qemu/qemu.inc
> > b/meta/recipes-devtools/qemu/qemu.inc
> > index 97e9b7b..1b861d7 100644
> > --- a/meta/recipes-devtools/qemu/q
On 18 September 2013 21:33, Richard Purdie
wrote:
> On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
>> On 18 September 2013 17:48, Richard Purdie
>> wrote:
>> I'd rather have opkg and opkg-utils merged together or next to each
>> other on the same server if/when I move opkg to git. I think
On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
> On 18 September 2013 17:48, Richard Purdie
> wrote:
> I'd rather have opkg and opkg-utils merged together or next to each
> other on the same server if/when I move opkg to git. I think
> OpenEmbedded/Yocto is probably the main user of opkg bu
Hi Ross,
Le Wed, 18 Sep 2013 17:48:45 +0100,
Ross Burton a écrit :
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index 97e9b7b..1b861d7 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -17,6 +17,7 @
On 18 September 2013 19:44, Phil Blundell wrote:
> On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
>> I am planning on proposing that opkg explicitly
>> follow semantic versioning (http://semver.org/)
>
> I'm not entirely sure I understand what you're saying here. Can you
> expand on what t
On Wed, 2013-09-18 at 18:24 +0100, Paul Barker wrote:
> I am planning on proposing that opkg explicitly
> follow semantic versioning (http://semver.org/)
I'm not entirely sure I understand what you're saying here. Can you
expand on what the practical effect of "following semantic versioning"
wou
Updating the 3.10 SRCREV to import the following MIPS configuration changes
4f689aa meta: remove ftrace/ftrace-disable feature
3058d81 mips: have the mips BSPs disable function tracing instead of ftrace
935f43f meta: add ftrace/ftrace-function-tracer-disable feature
0d72a03 mti-malta64
Richard/Saul,
Here are three fixes for the upcoming RCs and release. Once is a new branch, but
has zero impact on existing boards, so I've gone ahead and added it for this
upcoming release. The other two are bug fixes.
[PATCH 1/3] linux-yocto/3.8: add haswell-wc board config and branch
Bumpin
Bumping the meta branch SRCREV to import the following board support:
meta: add haswell-wc bsp for Intel Haswell Platform (Walnut Canyon CRB) scc
and config files
Signed-off-by Ong Boon Leong
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.8.bb |2 +-
meta
perf's builtin-sched.c triggers extremly long build times on some
architectures due to gcc 4.7+ var-tracking functionality.
To fix this, we can cherry pick the 3.12 commit:
f36f83f94 [perf sched: Move struct perf_sched definition out of cmd_sched()]
With this change build times are reduced fro
On 18 September 2013 17:48, Richard Purdie
wrote:
> On Wed, 2013-09-18 at 17:35 +0100, Paul Barker wrote:
>> As a side question - is there a specific maintainer for opkg-utils?
>> I'd like to discuss whether two separate repositories is a good idea
>> or whether we'd benefit from merging this into
On Wed, 2013-09-18 at 17:35 +0100, Paul Barker wrote:
> My time for this is fairly limited, but felt it was important that
> someone maintain it as it's a critical dependency for a lot of us.
We all suffer from time problems so I appreciate someone stepping up
there, it was certainly a gap.
> As
Use the new QEMU_DONT_GRAB environment variable to disable grabs,
finally/hopefully solving the random hangs that the autobuilder has been hitting
for a while.
[ YOCTO #5131 ]
Signed-off-by: Ross Burton
---
meta/lib/oeqa/utils/qemurunner.py |3 +++
1 file changed, 3 insertions(+)
diff --gi
When the mouse pointer enters the qemu window it takes a pointer grab. This
doesn't sound too dangerous at first but it turns out that SDL will infinitely
busy-loop if it can't get the grab (e.g. if the screen is locked) and the
average autobuilder setup's X server will have locked the screen a few
On 18 September 2013 17:07, Richard Purdie
wrote:
> On Wed, 2013-09-18 at 16:14 +0100, Paul Barker wrote:
>> On 19 August 2013 19:32, Mark Hatle wrote:
>> > On 8/19/13 1:08 PM, Saul Wold wrote:
>> >>
>> >> On 08/14/2013 01:30 PM, Mark Hatle wrote:
>> >>> +Upstream-status: Pending
>> >>
>>
>> I'm
On Wed, Sep 18, 2013 at 1:27 PM, Bruce Ashfield
wrote:
> On Wed, Sep 18, 2013 at 12:23 PM, Richard Purdie
...
>> Isn't that what the patch at the start of this thread is doing though
>> (clobbering, not adding)? :/
>
> It definitely is, and I had put in the bugzilla that it is a compromise for
>
On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
wrote:
> Otavio Salvador writes:
>
>> I don't agree on this. perf is tied to kernel and part of its code so
>> I think same exception rule apply for it as well.
>
> perf ships with the kernel but is a pure userspace program. It does not
> require a
On Wed, 2013-09-18 at 16:14 +0100, Paul Barker wrote:
> On 19 August 2013 19:32, Mark Hatle wrote:
> > On 8/19/13 1:08 PM, Saul Wold wrote:
> >>
> >> On 08/14/2013 01:30 PM, Mark Hatle wrote:
> >>> +Upstream-status: Pending
> >>
>
> I'm the new maintainer for opkg,
Congratulations! :)
> I'd be
On Wed, Sep 18, 2013 at 12:23 PM, Richard Purdie
wrote:
> On Wed, 2013-09-18 at 12:14 -0400, Bruce Ashfield wrote:
>> On Wed, Sep 18, 2013 at 12:02 PM, Richard Purdie
>> wrote:
>> > On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
>> >> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
>> >
On Wed, 2013-09-18 at 12:14 -0400, Bruce Ashfield wrote:
> On Wed, Sep 18, 2013 at 12:02 PM, Richard Purdie
> wrote:
> > On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
> >> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
> >> wrote:
> >> > Otavio Salvador writes:
> >> >
> >> >> I don't
On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
> wrote:
> > Otavio Salvador writes:
> >
> >> I don't agree on this. perf is tied to kernel and part of its code so
> >> I think same exception rule apply for it as well.
> >
> > perf ships
On Wed, Sep 18, 2013 at 12:02 PM, Richard Purdie
wrote:
> On Wed, 2013-09-18 at 11:54 -0400, Bruce Ashfield wrote:
>> On Wed, Sep 18, 2013 at 11:44 AM, Enrico Scholz
>> wrote:
>> > Otavio Salvador writes:
>> >
>> >> I don't agree on this. perf is tied to kernel and part of its code so
>> >> I th
Otavio Salvador writes:
> I don't agree on this. perf is tied to kernel and part of its code so
> I think same exception rule apply for it as well.
perf ships with the kernel but is a pure userspace program. It does not
require any special setup ('make configure'), it links against complex
user
Otavio Salvador writes:
> +# The LDFLAGS is required or some old kernels fails due missing
> +# symbols and this is preferred than requiring patches to every old
> +# supported kernel.
> +LDFLAGS="-ldl -lutil"
LDFLAGS is usually the wrong variable for extra libs (it might conflict
with '-Wl,-as-
On 19 August 2013 19:32, Mark Hatle wrote:
> On 8/19/13 1:08 PM, Saul Wold wrote:
>>
>> On 08/14/2013 01:30 PM, Mark Hatle wrote:
>>> +Upstream-status: Pending
>>
I'm the new maintainer for opkg, I'd be happy to look at this patch
and any others if you could send them to opkg-de...@googlegroups.c
On Wed, Sep 18, 2013 at 12:19 PM, Enrico Scholz
wrote:
> Bruce Ashfield
> writes:
>
+LDFLAGS="-ldl -lutil"
>>>
>>> What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
>>> usually? Perhaps, hacks like
>>
>> We don't want to influence the perf build from the build system, un
Bruce Ashfield
writes:
>>> +LDFLAGS="-ldl -lutil"
>>
>> What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
>> usually? Perhaps, hacks like
>
> We don't want to influence the perf build from the build system, unless we
> absolutely have to. We want to use the flags and configs
On Wed, Sep 18, 2013 at 10:25 AM, Enrico Scholz
wrote:
> Otavio Salvador writes:
>
>> The LDFLAGS is required or some old kernels fails due missing
>> symbols and this is preferred than requiring patches to every old
>> supported kernel.
>> ...
>> +LDFLAGS="-ldl -lutil"
>
> What is with -Wl,-as-n
Otavio Salvador writes:
> The LDFLAGS is required or some old kernels fails due missing
> symbols and this is preferred than requiring patches to every old
> supported kernel.
> ...
> +LDFLAGS="-ldl -lutil"
What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
usually? Perhaps,
On Wed, Sep 18, 2013 at 10:04 AM, Richard Purdie
wrote:
> On Wed, 2013-09-18 at 10:51 -0300, Otavio Salvador wrote:
>> The LDFLAGS is required or some old kernels fails due missing
>> symbols and this is preferred than requiring patches to every old
>> supported kernel.
>>
>> Fixes [YOCTO: #5221]
On Wed, 2013-09-18 at 10:51 -0300, Otavio Salvador wrote:
> The LDFLAGS is required or some old kernels fails due missing
> symbols and this is preferred than requiring patches to every old
> supported kernel.
>
> Fixes [YOCTO: #5221]
>
> Signed-off-by: Otavio Salvador
> ---
> meta/recipes-kern
On Wed, Sep 18, 2013 at 9:51 AM, Otavio Salvador
wrote:
> The LDFLAGS is required or some old kernels fails due missing
> symbols and this is preferred than requiring patches to every old
> supported kernel.
>
> Fixes [YOCTO: #5221]
>
Confirmed here as well, I was able to build my perf tests, and
The LDFLAGS is required or some old kernels fails due missing
symbols and this is preferred than requiring patches to every old
supported kernel.
Fixes [YOCTO: #5221]
Signed-off-by: Otavio Salvador
---
meta/recipes-kernel/perf/perf.bb | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(
While installing a rpm to update kernel on a deployed target, it will update
the boot area and the boot menu with the kernel as the priority but allow
you to fall back to the original kernel as well.
- In kernel-image's preinstall scriptlet, it backs up original kernel to avoid
probable conflict
Change in V2: Create a "kernel-grub.bbclass" to do the job which means
it is disabled by default.
Test Case:
1. Add INHERIT_append = " kernel-grub" to local.conf and build a new kernel
image rpm package.
2. Prepare a deployed target, and make sure your boot area has enough disk
37 matches
Mail list logo
