[oe] FYI: cmake introduction

Hi,
I just found a recording of the talk about cmake at FOSDEM 2009. I was
at this presentation and it helped me a lot understanding how to use it.

... and now just weeks later I can fumble around with our cmake.bbclass
and add a recipe that is using it (llvm 2.5).

Highly recommended:
http://free-electrons.com/pub/video/2009/fosdem/fosdem2009-neundorf-cmake.ogv

Regards
Robert

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel <at> lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [beagleboard] Re: Avahi recipe

On 03/10/2009 09:00 AM, Koen Kooi wrote:
>
> BAD_RECOMMENDATIONS works at image time, not at dependency time.

So in that case there is absolutely nothing that can be done to 
eliminate about a days worth of unnecessary compilation without editing 
task-base.bb? Something doesn't seem right with this picture. Why is 
there no way to eliminate recommendations at build time? Building all of 
Gnome just for the sake of building it seems a little absurd. Is this 
just a known limitation of BAD_RECOMMENDATIONS?

Problem building avahi

_______________________________________________
Openembedded-users mailing list
Openembedded-users <at> lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users

Discussion regarding the future of OpenEmbedded mailing lists

Hi All,

This email is mainly targeted at those who are subscribed to the "openembedded-users" mailing list, who
are not also subscribed to the "openembedded-devel" list.

There has been a proposal on the openembedded-devel mailing list to re-organise the lists provided on
openembedded.org. The re-organisation has been discussed as part of a larger discussion into the
procedures that are used to review patches/changes to Openembedded, that aim to make the process more
efficient and transparent.

A proposal has been put forward to merge a number of the mailing lists. There are currently 7 OpenEmbeddded
mailing lists with the following purposes:

Openembedded-announce - (no description available)
Openembedded-commits - Commits to the OpenEmbedded metadata repository
Openembedded-devel - Using the OpenEmbedded metadata to build Distributions
Openembedded-issues - OE Issues
Openembedded-stablebranch - Discussion and review of changes to the stable branch and its policy
Openembedded-users - Using OE
Openembedded-private - (no description available)

The role each of these lists is currently poorly defined and in some cases either a list has too few
knowledgeable/key subscribers to properly answer the questions asked, have overlapping objectives or
would better serve the larger Openembedded community by being merged into a more active list. The
proposal is to merge the list to form 3 better defined lists:

Openembedded-devel - for humans to post patches and ask questions
Openembedded-commits - commits, bugs, logs, etc
Openembedded-private - core team

The plan (as I understand it - please correct me if I'm wrong) is to:
* Close OpenEmbedded Announce, It seems to have received no traffic since April 2007.
* Merge OpenEmbedded-issues into Openembedded-commits. This list will be for fairly verbose automated
messages and as such high traffic.
* Merge Openembedded-users and Openembedded-stablebranch in to Openembedded-devel. This will form a
single list for the discussion of changes and issues regarding the Openembedded platform and to ensure
all users and developers are aware of up coming changes and have a chance to be involved in any discussions.
It is believed this will also aid with spotting changes that should be ported from the development branch
to the stable branch and visa-versa.
* Retain Openembedded-private for private core-team discussions.

Initial support on Openembedded-devel has been very positive, though the views of those subscribed on the
Openembedded-users list are also important. Objections, suggestions and support for these plans are welcome.

Martyn

--

-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,        |Registered in England and Wales
Tove Valley Business Park, Towcester,      |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476

Problem building bootstrap image for mx31ads

_______________________________________________
Openembedded-users mailing list
Openembedded-users <at> lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users

building for dm7025 fails

_______________________________________________
Openembedded-users mailing list
Openembedded-users <at> lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users

building net-snmp on arm target fails on configure (missing config.sub)

Hi,

I got an error building net-snmp-5.4.1 with up-to-date openembedded 
repository. Log complains about not be able to running a configuration 
script, which do not exists after fetching and patching.

I'm suspicious about that I 've to add an entry in checksums.ini, due 
mirror used  was not in it.
Anyway, it's the same checksum than original mirror.

Any thoughs about if is this a bug? Or I'm tainted something adding 
entry to checksums.ini?

Regards,

*EXISTING ENTRY IN CHECKSUMS.INI*
[http://heanet.dl.sourceforge.net/net-snmp/net-snmp-5.4.1.tar.gz]
md5=6c974df7a5a5b1579f72115e6b045bda
sha256=0ea976722c993c87dede8eb6348e6feb059e3851bbef2de824bf18ac97cdb565

*ADDED ENTRY TO CHECKSUMS.INI*
[http://downloads.sourceforge.net/net-snmp/net-snmp-5.4.1.tar.gz]
md5=6c974df7a5a5b1579f72115e6b045bda
sha256=0ea976722c993c87dede8eb6348e6feb059e3851bbef2de824bf18ac97cdb565

*BUILD LOG*

NOTE: Handling BitBake files: \ (6341/6341) [100 %]
NOTE: Parsing finished. 6055 cached, 0 parsed, 286 skipped, 0 masked.
NOTE: build 200902190741: started

OE Build Configuration:
BB_VERSION        = "1.8.10"
METADATA_BRANCH   = "org.openembedded.dev"
METADATA_REVISION = "55391f25a601adc1fc235bf1abc30017f10cd956"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "colibri"
DISTRO            = "angstrom"
DISTRO_VERSION    = "2008.1-test-20090219"
TARGET_FPU        = "soft"

<snip>
*****************************************************************************************************
| configure: error: cannot run /bin/sh 
/home/vpalacio/bsp/oe_colibri/build/work/armv5te-angstrom-linux-gnueabi/net-snmp-5.4.1-r1/net-snmp-5.4.1/config.sub
**********************************************************************************************************
NOTE: Task failed: 
/home/vpalacio/bsp/oe_colibri/build/work/armv5te-angstrom-linux-gnueabi/net-snmp-5.4.1-r1/temp/log.do_configure.19005
NOTE: package net-snmp-5.4.1-r1: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package net-snmp-5.4.1: failed
ERROR: Build of 
/home/vpalacio/bsp//oe_colibri/openembedded/packages/net-snmp/net-snmp_5.4.1.bb 
do_configure failed
ERROR: Task 8 
(/home/vpalacio/bsp//oe_colibri/openembedded/packages/net-snmp/net-snmp_5.4.1.bb, 
do_configure) failed
NOTE: Tasks Summary: Attempted 332 tasks of which 332 didn't need to be 
rerun and 1 failed.

--

-- 

//*Víctor M. Palacio Tárrega*//

building angstrom with uclibc fails

Hi,

I have been trying to build an initramfs image using angstrom for an
ARM based board. If I set ANGSTROMLIBC = "uclibc" in my local.conf,
the build failes exactly like this:

  http://tinderbox.openembedded.net/packages/339702/

When I manually changed conf/distro/include/angstrom.inc so that
ANGSTROM_ARM_INSTRUCTION_SET_armv5te = "arm" instead of "thumb", then
the build is ok.

In googling for a fix, I came across a reference which suggested
compiling uclibc as arm and then using thumb interworking for
applications. I was unable to figure out how to do this via a change
to some recipes or setting of some variable. Is this possible?

Also, it appears that I can not override the
ANGSTROM_ARM_INSTRUCTION_SET_armv5te variable without a patch like
this:

diff --git a/conf/distro/include/angstrom.inc b/conf/distro/include/angstrom.inc
index 60f2e55..50f15d4 100644
--- a/conf/distro/include/angstrom.inc
+++ b/conf/distro/include/angstrom.inc
@@ -31,9 +31,9 @@ require conf/distro/include/angstrom-${ANGSTROMLIBC}.inc

 # We can't do ARM_INSTRUCTION_SET_armv4t since that will
un-overridable in recipes like gcc
 ANGSTROM_ARM_INSTRUCTION_SET ?= "arm"
-ANGSTROM_ARM_INSTRUCTION_SET_armv4t = "thumb"
-ANGSTROM_ARM_INSTRUCTION_SET_armv5te = "thumb"
-ANGSTROM_ARM_INSTRUCTION_SET_armv5teb = "thumb"
+ANGSTROM_ARM_INSTRUCTION_SET_armv4t ?= "thumb"
+ANGSTROM_ARM_INSTRUCTION_SET_armv5te ?= "thumb"
+ANGSTROM_ARM_INSTRUCTION_SET_armv5teb ?= "thumb"

 ARM_INSTRUCTION_SET = "${ANGSTROM_ARM_INSTRUCTION_SET}"
(END)

So, this post boils down to two questions:

1: Should I just build all of angstrom with uClibc as arm by changing
the instruction set variable?

2: Is there a fix to allow building of uClibc as thumb?

My local setup is available here:
  http://github.com/troth/oe-setup/tree/master

My branch of org.openembedded.dev for the ts7800 board I am working
with is here:
  http://github.com/troth/oe-ts7xxx/tree/ts7800

Thanks,

Ted Roth

Running "issue" on at91sam9263ek

_______________________________________________
Openembedded-users mailing list
Openembedded-users <at> lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-users

Building a chrooted system with OpenEmbedded

Hello,

I am in the process of building a chrooted system with OpenEmbedded: the 
device I target already runs an embedded linux distributions, but for 
various reasons I need to install a chrooted system inside it.

I would like to avoid building things I do not need, such as the kernel, 
but I can't find a way to disable it. Is it possible to avoid building 
the kernel?

Regards,
Aurélien

New hardware with a Mips processor

Hello all,
    I'm trying to find  some information on how you would add a totally
new development board to Openembedded so that I could build for the
board. There are some very brief outlines but I can't find anything that
looks like it's got all the info.

Don't I have to specify hardware specifics like memory maps and the like?

Any hints would be very gratefully received.

John