Signed-off-by: Martin Jansa
---
meta/recipes-devtools/qemu/qemu_1.2.0.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/qemu/qemu_1.2.0.bb
b/meta/recipes-devtools/qemu/qemu_1.2.0.bb
index 7091f6d..191ee48 100644
--- a/meta/recipes-devtools/qemu/qem
On Fri, 2012-09-21 at 17:18 +0200, Martin Jansa wrote:
> On Fri, Sep 21, 2012 at 03:27:48PM +0100, Phil Blundell wrote:
> > On Fri, 2012-09-21 at 15:24 +0100, Richard Purdie wrote:
> > > As per the previous patch, this is really a request for comments, I can
> > > see pros and cons...
> >
> > I've
On Fri, 2012-09-21 at 17:52 +0200, Martin Jansa wrote:
> Even with last version of jansa/tune it does not really help with
> rebuilds
>
> $ bitbake-diffsigs
> stamps.1348241943/*/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure*
> basehash changed from 82dd3229952508550532e9ab37e
On Fri, 2012-09-21 at 17:40 +0100, Paul Eggleton wrote:
> We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for
> the value of BPN) can derive the bare name from the multilib-extended
> name for image recipes. BPN being set correctly avoids missing file
> warnings during parse fro
On Saturday 22 September 2012 12:55:53 Richard Purdie wrote:
> On Fri, 2012-09-21 at 17:40 +0100, Paul Eggleton wrote:
> > We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for
> > the value of BPN) can derive the bare name from the multilib-extended
> > name for image recipes. BP
We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for
the value of BPN) can derive the bare name from the multilib-extended
name for image recipes. BPN being set correctly avoids missing file
warnings during parse from the file checksum code for (unusual) images
that set SRC_URI,
The following changes since commit 5e03d1e83d0536a2fc69a88d3e5407108836203f:
gcc: Use 4.7.2 release tarball (2012-09-21 14:55:26 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/multilib
http://cgit.openembedded.org/cgit.cgi/openemb
It isn't supported to mix multilib and nativesdk in the same target, so
explicitly skip multilib processing if nativesdk is inherited. As a
bonus this fixes a bunch of related "missing file" warnings from the
file checksum code during parsing because BPN was not correctly stripped
for these targets
* without this you it's harder to see which kernel is newer version
e.g. after branch change LOCALCOUNT in SRCPV is reset to 0, so it needs PE
bump for upgrade path
but then it's clear why gitr1+HASH has newer DATETIME then gitrN+HASH, so
include PE in name
* using PE not EXTENDPE to sort it
Need to pass the path explicitly to "make install" to ensure that the binaries
end up
in the right locations.
Signed-off-by: Phil Blundell
---
meta/recipes-support/libcap/libcap.inc |2 +-
meta/recipes-support/libcap/libcap_2.22.bb |2 +-
2 files changed, 2 insertions(+), 2 deletion
For reasons that are now shrouded in obscurity, autotools.bbclass
has long contained a special heuristic to avoid attempting to run
autoreconf when building autoconf or automake themselves. However,
the wildcard test against PN which is used there is problematic when
trying to build another packag
The configure script uses a hard-coded value for ${usrsbin_execdir},
which is the path that we know as ${sbindir}. Adjust configure to take
this from the environment if it's set there, and have do_configure()
pass it in.
Signed-off-by: Phil Blundell
---
meta/recipes-core/util-linux/util-linux.i
This patchset is just RFC because I've modified and tested it only for
tune-arm926ejs and tune-xscale (because I've tried to build qemuarm and
same builddir).
Also I have no strong opinion about used TUNE as suffix (see 1. patch)
or as ARMPKGARCH (see last patch, which reverts most of 1. patch).
* without this tune-xscale and tune-arm926ejs were both creating
packages in armv5te feed, but each with different -mtune, with
OEBasicHash enabled it was causing each package to rebuild with new
-mtune after MACHINE switch, but that doesn't make sense with output
stored in the same armv5te
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine
includes its tune*.inc, but it's easy for DISTRO to say it wants
OPTDEFAULTTUNE for some packages or always (if they don't want to
share built packa
* selects more optimized DEFAULTTUNE for some packages
* for some machines it could be de same as DEFAULTTUNE
Signed-off-by: Martin Jansa
---
meta/conf/distro/include/optimized-tune.inc | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 meta/conf/distro/include/optimized-tune.inc
diff
* we don't care about expression but value
* e.g. tune-xscale and tune-arm926ejs have different expression
in TUNE_CCARGS but with the same DEFAULTTUNE the result is the same
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030032.html
Signed-off-by: Martin Jansa
---
me
* xscale will be prefix not suffix, but also we need to show other flags
like thumb/dsp/fpu/eabi/endian
Signed-off-by: Martin Jansa
---
meta/conf/machine/include/arm/README | 5 +
meta/conf/machine/include/arm/arch-arm.inc | 4 +---
meta/conf/machine/include/tune-arm926ejs.inc |
This gives a small but measureable performance improvement for
I/O heavy workloads.
Signed-off-by: Phil Blundell
---
meta/recipes-support/sqlite/sqlite3.inc |4
meta/recipes-support/sqlite/sqlite3_3.7.13.bb |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/
* there needs to be space between '<' and PV, see:
>>> bb.utils.explode_dep_versions('xserver-xorg (<1.11.2)')
{'xserver-xorg': None}
>>> bb.utils.explode_dep_versions('xserver-xorg (< 1.11.2)')
{'xserver-xorg': '< 1.11.2'}
Signed-off-by: Martin Jansa
---
meta/recipes-graphics/xorg-xserv
* it doesn't make much sense with PV, because xserver-xorg-module-exa
was introduced in
http://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver?id=1a666ee1cda3c0b74daba5881fc5f62e13deec66
so our xserver-xorg-module-exa RCONFLICTS with xserver-xorg (<= 1.11.2-r
On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> * this way xscale or arm926ejs is not used by default when some machine
> includes its tune*.inc, but it's easy for DISTRO to say it wants
> OPTDEFAULTTUNE for som
On Sat, Sep 22, 2012 at 5:29 AM, Paul Eggleton
wrote:
> It isn't supported to mix multilib and nativesdk in the same target, so
> explicitly skip multilib processing if nativesdk is inherited. As a
> bonus this fixes a bunch of related "missing file" warnings from the
> file checksum code during p
We don't DEPEND on openssl but configure will try to use it if
pkg-config thinks it might be installed. This can lead to failing
and/or nondeterministic builds, so let's force it off.
Signed-off-by: Phil Blundell
---
meta/recipes-multimedia/pulseaudio/pulseaudio.inc |1 +
.../pulseaudio/pu
Use ${bindir} to locate the binary instead.
Signed-off-by: Phil Blundell
---
meta/recipes-core/dbus/dbus-1.6.4/dbus-1.init |2 +-
meta/recipes-core/dbus/dbus.inc |5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus-1.6.4/dbus-
On Sat, Sep 22, 2012 at 9:18 AM, Phil Blundell wrote:
> For reasons that are now shrouded in obscurity, autotools.bbclass
> has long contained a special heuristic to avoid attempting to run
> autoreconf when building autoconf or automake themselves. However,
> the wildcard test against PN which i
On Fri, Sep 21, 2012 at 11:53 PM, Florin Sarbu
wrote:
> What exactly do you wanna see in the output? I can post the variables you
> are looking for.
why cant you pastebin the whole file ? anyhow you are probably looking
at a red herring
build will create three linker binaries
1. Default linker -
27 matches
Mail list logo
