Please resend it to oe-core ml. Secondly some links which points to the
fact that its under runtime exception
On Mar 10, 2016 9:10 PM, wrote:
> From: Helio Chissini de Castro
>
> Poky jethro has libgomp ( GNU OpenMP ) license marked as GPL-3.0,
> where's in fact the correct is GPL-3.0 with GCC L
Thank you very much!!
On Mon, Mar 7, 2016 at 3:53 PM, Burton, Ross wrote:
>
> On 7 March 2016 at 10:20, Vivek Per wrote:
>
>> i want to add some additional enviroment variables in /etc/profile
>> file. How can i add these while building, so that it reflect in my target
>> image.
>>
>
> bas
On Fri, 11 Mar 2016 07:55:25 Paul Eggleton wrote:
> On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
> > ( using jethro )
> >
> > I have a 'linux-yocto-custom' layer which builds successfully; then I run:
> > devtool modify -x linux-yocto-custom ../../poky-dev/kernel
> > >>
> > >> I see a line:
Fixed a hardcoded statement that had "14.0.1" instead of the correct POKY_VER
variable.
Signed-off-by: Graydon, Tracy
---
bin/release_scripts/relnotes.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/release_scripts/relnotes.py b/bin/release_scripts/relnotes.py
index 3c
Hi,
Turns out updating this and making it work properly is harder than I
thought. I'm running into symlink recursion errors on the
popular_sysroot task on gcc-cross-arm.
[log]
DEBUG: Shell function sysroot_stage_all finished
DEBUG: Executing python function sysroot_strip
ERROR: Error executing a
Hi Steve,
On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
> ( using jethro )
>
> I have a 'linux-yocto-custom' layer which builds successfully; then I run:
> devtool modify -x linux-yocto-custom ../../poky-dev/kernel
>
> >> I see a line:
> Cloning into '/tmp/devtoolfgiLXr/workdir/source'...
On Wed, Mar 02, 2016 at 08:34:06AM -0800, Khem Raj wrote:
> On Wed, Mar 2, 2016 at 7:47 AM, Andrei Gherzan wrote:
> > Hi Khen,
> >
> > I started to merge the ones that were obvious. The rest need rebasing,
> > conflict fixing and so on. And then I test them locally. So it will take a
> > while. Bu
On Sat, Feb 27, 2016 at 03:26:59PM +, Khem Raj wrote:
> Make it default kernel as well
>
> Signed-off-by: Khem Raj
> ---
> conf/machine/include/rpi-default-versions.inc | 2 +-
> recipes-kernel/linux/linux-raspberrypi_4.4.bb | 6 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
> cr
On Sat, Feb 27, 2016 at 03:26:57PM +, Khem Raj wrote:
> Readme change a bit thats why LIC_FILES_CHKSUM changed
>
> Signed-off-by: Khem Raj
> ---
> recipes-bsp/bootfiles/bcm2835-bootfiles.bb | 2 +-
> recipes-bsp/common/firmware.inc| 4 ++--
> 2 files changed, 3 insertions(+), 3 d
From: Helio Chissini de Castro
Poky jethro has libgomp ( GNU OpenMP ) license marked as GPL-3.0,
where's in fact the correct is GPL-3.0 with GCC Library Runtime Exception
Signed-off-by: Helio Chissini de Castro
---
meta/recipes-devtools/gcc/gcc-runtime.inc | 6 +++---
1 file changed, 3 inserti
On 2016-03-10 14:51, Martin Jansa wrote:
On Thu, Mar 10, 2016 at 02:21:42PM +0100, Gary Thomas wrote:
If I have a package X that depends on X-native and they build
from the same sources, doesn't the fetch step duplicate effort
if the sources need to be downloaded from scratch? I just saw
this [
On Thu, Mar 10, 2016 at 02:21:42PM +0100, Gary Thomas wrote:
> If I have a package X that depends on X-native and they build
> from the same sources, doesn't the fetch step duplicate effort
> if the sources need to be downloaded from scratch? I just saw
> this [appear to] happen and it's not clear
On Wed, Mar 09, 2016 at 04:15:02PM +0200, Theodor Gherzan wrote:
> From: Theodor Gherzan
>
> Signed-off-by: Theodor Gherzan
> ---
> recipes-kernel/linux/linux-raspberrypi_4.1.bb | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi_
If I have a package X that depends on X-native and they build
from the same sources, doesn't the fetch step duplicate effort
if the sources need to be downloaded from scratch? I just saw
this [appear to] happen and it's not clear if the sources were
downloaded once or twice.
I this is the case,
Hi,
I'm trying to get my meta-ada layer working with jethro, gcc-4.9. I've
tried to build qemux86, qemumips and qemuarm so far. At this time, I've
added "ada" to --enable-languages and I'm trying to get the thing to
build first. Both qemux86 and qemumips targets have misconfigured
gcc/ada/gcc-inte
On 03/09/2016 05:02 PM, Richard Purdie wrote:
On Wed, 2016-03-09 at 23:50 +0100, Martin Jansa wrote:
What's even more interesting is that even gcc-cross-initial has
different signatures for 2 ARM MACHINEs with different DEFAULTTUNES
OE qemuarm7@ ~/build/oe-core $ grep ^DEFAULTTUNE= env.gdb-cros
Hello,
I appreciate that the TI DM355 is now a very old device (ARM9 based) but I
was wondering what the best starting point would be as I can't see it in the
meta-ti layer.
Any thoughts?
Andy.
--
___
yocto mailing list
yocto@yoctoproject.org
https:/
On 2016-03-10 11:04, Joshua G Lock wrote:
On Thu, 2016-03-10 at 10:43 +0100, Gary Thomas wrote:
On 2016-03-10 10:35, Joshua G Lock wrote:
On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
I've been running local PR servers for my builds. This works
quite well, as long as I don't touch m
On Thu, 2016-03-10 at 10:43 +0100, Gary Thomas wrote:
> On 2016-03-10 10:35, Joshua G Lock wrote:
> >
> > On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
> > >
> > > I've been running local PR servers for my builds. This works
> > > quite well, as long as I don't touch my build trees.
> >
On 2016-03-10 10:35, Joshua G Lock wrote:
On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
I've been running local PR servers for my builds. This works
quite well, as long as I don't touch my build trees.
What's the best way to manage versions long-term? i.e. if I
have a deployed system
On Thu, 2016-03-10 at 09:12 +0100, Gary Thomas wrote:
> I've been running local PR servers for my builds. This works
> quite well, as long as I don't touch my build trees.
>
> What's the best way to manage versions long-term? i.e. if I
> have a deployed system that I build today, but may not tou
Hello,
The latest release of the Yocto Project 2.0.1 (jethro-14.0.1) is now
available
for download at:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.0.1/poky-jethro-14
.0.1.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.0.1/poky-jethro-14.0.1.tar.bz
2
A gpg signed version of th
I've been running local PR servers for my builds. This works
quite well, as long as I don't touch my build trees.
What's the best way to manage versions long-term? i.e. if I
have a deployed system that I build today, but may not touch
for a long time (years?) and I might not want to keep my bui
23 matches
Mail list logo
