Looks good. I'll let Khem or some who is more familiar with toolchains apply. One suggestion, we have a commit policy (http://wiki.openembedded.net/index.php/Commit_Policy), so if you follow that on

(My first patch generated with git, please be gentle :-). armv5te is mentioned twice in the arm_eabi_supporting_arches list of sane-toolchain.inc. Remove the latter occurance. ak.

We're using automake (1.10.2) on our target machine for rapid prototyping. Calling "autoreconf --install" results in this error: /usr/bin/env: perl -w: No such file or directory autoreconf:

openembedded-devel-request@... wrote: I'll use the svn revision number. I used 1.0 because that's the version number present in the various files of the repository. It may take a

Well, er, because the git tree contains multiple revisions. There's no reason why I mightn't want to package git revision 9324048f648da3b5ac3e507ab5fcc1bb8a3721c9 if that one worked particularly well

I can see what this patch is driving at as I've been in this position before and its ugly. By default you usually want git recipes to have the lowest preference. You then usually want to have some

Ok, but then you can say, that the same problem is when there is two or more packages with PV = "1.0". You can have as many git-based bb files as long as they have different PV prefix like 1.0+git%

I would have thought you would be better off setting a positive DEFAULT_PREFERENCE for your own DISTRO inside the bb file in question. That doesn't require any bitbake changes and doesn't introduce

I wrote a bit more about my problem here: http://article.gmane.org/gmane.comp.handhelds.openembedded/25986 Simply: If I want to prefer bbfile with PV=1.0+gitr${SRCPV} then PV will change with every

I wonder why that version is DEFAULT_PREFERENCE -1 in the first place. Maybe it'd be better just to change that rather than setting it for minimal specifically. p.

Thanks for the patch. Your bb file is named "python-wpactrl_1.0", which would suggest that this is for version 1.0 of the package. But the SRC_URI seems to point to some random-looking svn revision.

I'm not totally comfortable that this patch is semantically well-formed. If you start allowing wildcards then the idea of "the preferred version" becomes somewhat ill-defined since, obviously, the

Hi, For now, our more stable version of linux is a 2.6.28.10 based kernel with several backports from recent releases (like smsc driver, libertas, DSS ...). That does not seem to linux-omap

What's the reason for setting LEAD_SONAME? It looks like it would be unnecessary if you only have that one file in the output package. I'd have thought you might as well continue to ship the .a file

Sorry the patches are attached in other mails I sent Regards, Enric Balletbò i Serra 2009/9/14 Khem Raj <raj.khem@...>

Signed-off-by: Khem Raj <raj.khem@...> --- conf/distro/minimal.conf | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/conf/distro/minimal.conf

* with libint.a the link order matters and generally for uclibc targets we append -lintl to LDFLAGS and sometime it gets specified before the objects and symbols do not get pulled in. Better we

* With dri2proto 2.0 recipe being added now it gets picked up this recipes needs newer version of xorg-utils so we tie down the version of dri2proto to 1.1 Signed-off-by: Khem Raj

I had problem when using _git or _svn versions with AUTOREV. When there is SRCREV or SRCPV in PV of that bb file you would like to use then you need to update PREFERRED_VERSION_pkg with every new

Stuart Gray wrote: PLEASE read this: http://www.anta.net/misc/nnq/nquote.shtml -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad?