* Re: [PATCHv3 00/31] Xorg related changes
From: Martin Jansa @ 2011-10-11 7:08 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <A8FC601D-2A25-46D0-8AB0-3FE9E8561B01@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]
On Mon, Oct 10, 2011 at 12:40:08PM +0200, Koen Kooi wrote:
>
> Op 7 okt. 2011, om 19:05 heeft Martin Jansa het volgende geschreven:
>
> > this patchset brings meta-oe and oe-core xorg stuff together and most of
> > xorg recipes will be removed from meta-oe (sending another pull request now).
> >
> > This step is needed to be able to separate common x11 to meta-x11 or whatever later.
> >
> > The following changes since commit 808b3123e359f1aebabb8af44694275e4075e031:
> >
> > gnutls: Disable p11-kit dependency explicitly to resolve build failures (2011-10-07 15:40:42 +0100)
> >
> > are available in the git repository at:
> > git://git.openembedded.org/openembedded-core-contrib jansa/x11-v2
> > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/x11-v2
> >
> > Martin Jansa (31):
> >
> > xserver-xorg-common: move RDEPENDS_${PN} += xorg-minimal-fonts to
> > shared .inc
>
> I have been running X images without minimal fonts for some time now, so AFAICS it can be dropped completely.
I'm also fine without (as it was in meta-oe and OE-classic), but it's
quite small:
276 KiB /all/xorg-minimal-fonts_1.0-r1_all.ipk
so I've kept it as it was..
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCHv3 01/31] xserver-xf86(-dri)-lite: rename to xserver-xorg and xserver-xorg-lite
From: Martin Jansa @ 2011-10-11 7:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E93E69A.7070402@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]
On Tue, Oct 11, 2011 at 02:47:54PM +0800, Kang Kai wrote:
> On 2011?10?08? 01:04, Martin Jansa wrote:
> > * xserver-xorg is closer to upstream naming and
> > that's how it's named in OE-classic and meta-oe? It would make meta-oe
> > transition easier and better to do it now then convert meta-oe to
> > xserver-xf86 and then rename it back later.
> >
> > Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
> > ---
> > diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
> > index 7b6c4a9..8af80c7 100644
> > --- a/meta/conf/distro/include/distro_tracking_fields.inc
> > +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> > @@ -3683,14 +3683,14 @@ RECIPE_INTEL_SECTION_pn-mesa-xlib="graphic core"
> > RECIPE_LAST_UPDATE_pn-mesa-xlib = "Nov 27, 2010"
> > RECIPE_MAINTAINER_pn-mesa-xlib="Yu Ke<ke.yu@intel.com>"
> >
> > -RECIPE_STATUS_pn-xserver-xf86-dri-lite="green" # no update needed
> > -RECIPE_LATEST_VERSION_pn-xserver-xf86-dri-lite="1.8.99.904"
> > -RECIPE_NO_OF_PATCHES_pn-xserver-xf86-dri-lite="2"
> > -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-xserver-xf86-dri-lite="2 monthes"
> > -RECIPE_LATEST_RELEASE_DATE_pn-xserver-xf86-dri-lite="2010/07/01"
> > -RECIPE_INTEL_SECTION_pn-xserver-xf86-dri-lite="graphic core"
> > -RECIPE_LAST_UPDATE_pn-xserver-xf86-dri-lite = "Jan 18, 2011"
> > -RECIPE_MAINTAINER_pn-xserver-xf86-dri-lite="Yu Ke<ke.yu@intel.com>"
> > +RECIPE_STATUS_pn-xserver-xorg="green" # no update needed
> > +RECIPE_LATEST_VERSION_pn-xserver-xorg="1.8.99.904"
> > +RECIPE_NO_OF_PATCHES_pn-xserver-xorg="2"
> > +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-xserver-xorg="2 monthes"
> > +RECIPE_LATEST_RELEASE_DATE_pn-xserver-xorg="2010/07/01"
> > +RECIPE_INTEL_SECTION_pn-xserver-xorg="graphic core"
> > +RECIPE_LAST_UPDATE_pn-xserver-xorg = "Jan 18, 2011"
> > +RECIPE_MAINTAINER_pn-xserver-xorg="Yu Ke<ke.yu@intel.com>"
> >
> > RECIPE_STATUS_pn-xf86-input-synaptics = "red"
> > DISTRO_PN_ALIAS_pn-xf86-input-synaptics = "Meego=xorg-x11-drv-synaptics Fedora=xorg-x11-drv-synaptics Ubuntu=xserver-xorg-input-synaptics Mandriva=x11-driver-input-synaptics Debian=xfree86-driver-synaptics"
> > @@ -5908,8 +5908,8 @@ DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
> >
> > DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
> > DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> > -DISTRO_PN_ALIAS_pn-xserver-xf86-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
> > -DISTRO_PN_ALIAS_pn-xserver-xf86-dri-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
>
> Hi Martin,
> > +DISTRO_PN_ALIAS_pn-xserver-xorg = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
> I guess this should be xserver-xorg-lite.
>
> Regards,
> Kai
You're right, I've added patch for that on top of jansa/x11-v2.
RP: I'll squash it to 01/31 if you want, but I didn't want to rebase as
you already have it in master-next.. so it's on top.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCHv3 01/31] xserver-xf86(-dri)-lite: rename to xserver-xorg and xserver-xorg-lite
From: Kang Kai @ 2011-10-11 6:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <8267017169d00aaa5a487a6f5d72cd67dad9c327.1318007055.git.Martin.Jansa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 18507 bytes --]
On 2011?10?08? 01:04, Martin Jansa wrote:
> * xserver-xorg is closer to upstream naming and
> that's how it's named in OE-classic and meta-oe? It would make meta-oe
> transition easier and better to do it now then convert meta-oe to
> xserver-xf86 and then rename it back later.
>
> Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
> ---
> meta/conf/distro/include/default-providers.inc | 4 ++--
> .../conf/distro/include/distro_tracking_fields.inc | 20 ++++++++++----------
> meta/conf/machine/qemux86-64.conf | 6 +++---
> meta/conf/machine/qemux86.conf | 6 +++---
> meta/conf/multilib.conf | 2 +-
> ...ver-xf86-common.inc => xserver-xorg-common.inc} | 1 +
> ...xserver-xf86-lite.inc => xserver-xorg-lite.inc} | 4 +---
> .../crosscompile.patch | 0
> .../fix_open_max_preprocessor_error.patch | 0
> .../macro_tweak.patch | 2 +-
> ...-lite_1.10.1.bb => xserver-xorg-lite_1.10.1.bb} | 2 +-
> ...{xserver-xf86-dri-lite.inc => xserver-xorg.inc} | 2 +-
> .../cache-xkbcomp-output-for-fast-start-up.patch | 0
> .../crosscompile.patch | 0
> .../fix_macros1.patch | 0
> .../fix_open_max_preprocessor_error.patch | 0
> .../macro_tweak.patch | 2 +-
> ...6-dri-lite_1.10.1.bb => xserver-xorg_1.10.1.bb} | 2 +-
> ...er-xf86-dri-lite_git.bb => xserver-xorg_git.bb} | 2 +-
> 19 files changed, 27 insertions(+), 28 deletions(-)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-common.inc => xserver-xorg-common.inc} (96%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite.inc => xserver-xorg-lite.inc} (95%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite => xserver-xorg-lite}/crosscompile.patch (100%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite => xserver-xorg-lite}/fix_open_max_preprocessor_error.patch (100%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite => xserver-xorg-lite}/macro_tweak.patch (93%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite_1.10.1.bb => xserver-xorg-lite_1.10.1.bb} (89%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite.inc => xserver-xorg.inc} (97%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite => xserver-xorg}/cache-xkbcomp-output-for-fast-start-up.patch (100%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite => xserver-xorg}/crosscompile.patch (100%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite => xserver-xorg}/fix_macros1.patch (100%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite => xserver-xorg}/fix_open_max_preprocessor_error.patch (100%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite => xserver-xorg}/macro_tweak.patch (93%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_1.10.1.bb => xserver-xorg_1.10.1.bb} (93%)
> rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_git.bb => xserver-xorg_git.bb} (94%)
>
> diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc
> index d51ac64..a5cdb5b 100644
> --- a/meta/conf/distro/include/default-providers.inc
> +++ b/meta/conf/distro/include/default-providers.inc
> @@ -3,8 +3,8 @@
> #
> PREFERRED_PROVIDER_virtual/db ?= "db"
> PREFERRED_PROVIDER_virtual/db-native ?= "db-native"
> -PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86"
> -PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite"
> +PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> +PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xorg"
> PREFERRED_PROVIDER_virtual/libgl ?= "mesa-xlib"
> PREFERRED_PROVIDER_virtual/update-alternatives ?= "update-alternatives-cworth"
> PREFERRED_PROVIDER_virtual/update-alternatives-native ?= "opkg-native"
> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc
> index 7b6c4a9..8af80c7 100644
> --- a/meta/conf/distro/include/distro_tracking_fields.inc
> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> @@ -3683,14 +3683,14 @@ RECIPE_INTEL_SECTION_pn-mesa-xlib="graphic core"
> RECIPE_LAST_UPDATE_pn-mesa-xlib = "Nov 27, 2010"
> RECIPE_MAINTAINER_pn-mesa-xlib="Yu Ke<ke.yu@intel.com>"
>
> -RECIPE_STATUS_pn-xserver-xf86-dri-lite="green" # no update needed
> -RECIPE_LATEST_VERSION_pn-xserver-xf86-dri-lite="1.8.99.904"
> -RECIPE_NO_OF_PATCHES_pn-xserver-xf86-dri-lite="2"
> -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-xserver-xf86-dri-lite="2 monthes"
> -RECIPE_LATEST_RELEASE_DATE_pn-xserver-xf86-dri-lite="2010/07/01"
> -RECIPE_INTEL_SECTION_pn-xserver-xf86-dri-lite="graphic core"
> -RECIPE_LAST_UPDATE_pn-xserver-xf86-dri-lite = "Jan 18, 2011"
> -RECIPE_MAINTAINER_pn-xserver-xf86-dri-lite="Yu Ke<ke.yu@intel.com>"
> +RECIPE_STATUS_pn-xserver-xorg="green" # no update needed
> +RECIPE_LATEST_VERSION_pn-xserver-xorg="1.8.99.904"
> +RECIPE_NO_OF_PATCHES_pn-xserver-xorg="2"
> +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-xserver-xorg="2 monthes"
> +RECIPE_LATEST_RELEASE_DATE_pn-xserver-xorg="2010/07/01"
> +RECIPE_INTEL_SECTION_pn-xserver-xorg="graphic core"
> +RECIPE_LAST_UPDATE_pn-xserver-xorg = "Jan 18, 2011"
> +RECIPE_MAINTAINER_pn-xserver-xorg="Yu Ke<ke.yu@intel.com>"
>
> RECIPE_STATUS_pn-xf86-input-synaptics = "red"
> DISTRO_PN_ALIAS_pn-xf86-input-synaptics = "Meego=xorg-x11-drv-synaptics Fedora=xorg-x11-drv-synaptics Ubuntu=xserver-xorg-input-synaptics Mandriva=x11-driver-input-synaptics Debian=xfree86-driver-synaptics"
> @@ -5908,8 +5908,8 @@ DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
>
> DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
> DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
> -DISTRO_PN_ALIAS_pn-xserver-xf86-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
> -DISTRO_PN_ALIAS_pn-xserver-xf86-dri-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
Hi Martin,
> +DISTRO_PN_ALIAS_pn-xserver-xorg = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
I guess this should be xserver-xorg-lite.
Regards,
Kai
>
> +DISTRO_PN_ALIAS_pn-xserver-xorg = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
> DISTRO_PN_ALIAS_pn-xserver-kdrive = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
> DISTRO_PN_ALIAS_pn-dtc = "Fedora=dtc Ubuntu=dtc"
> DISTRO_PN_ALIAS_pn-dtc-native = "Fedora=dtc Ubuntu=dtc"
> diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf
> index 18a7513..f28cf08 100644
> --- a/meta/conf/machine/qemux86-64.conf
> +++ b/meta/conf/machine/qemux86-64.conf
> @@ -4,8 +4,8 @@
>
> PREFERRED_PROVIDER_virtual/libgl = "mesa-dri"
> PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
> -PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
> -PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite"
> +PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> +PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xorg"
>
> require conf/machine/include/tune-x86_64.inc
> require conf/machine/include/qemu.inc
> @@ -17,7 +17,7 @@ KERNEL_IMAGETYPE = "bzImage"
> SERIAL_CONSOLE = "115200 ttyS0"
>
> # We bypass swrast but we need it to be present for X to load correctly
> -XSERVER ?= "xserver-xf86-dri-lite \
> +XSERVER ?= "xserver-xorg \
> mesa-dri-driver-swrast \
> xf86-input-vmmouse \
> xf86-input-keyboard \
> diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
> index 5d0d03e..75c9042 100644
> --- a/meta/conf/machine/qemux86.conf
> +++ b/meta/conf/machine/qemux86.conf
> @@ -4,8 +4,8 @@
>
> PREFERRED_PROVIDER_virtual/libgl = "mesa-dri"
> PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
> -PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
> -PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite"
> +PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> +PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xorg"
>
> require conf/machine/include/tune-i586.inc
> require conf/machine/include/qemu.inc
> @@ -17,7 +17,7 @@ KERNEL_IMAGETYPE = "bzImage"
> SERIAL_CONSOLE = "115200 ttyS0"
>
> # We bypass swrast but we need it to be present for X to load correctly
> -XSERVER ?= "xserver-xf86-dri-lite \
> +XSERVER ?= "xserver-xorg \
> mesa-dri-driver-swrast \
> xf86-input-vmmouse \
> xf86-input-keyboard \
> diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
> index b9da33a..5e4b435 100644
> --- a/meta/conf/multilib.conf
> +++ b/meta/conf/multilib.conf
> @@ -442,7 +442,7 @@ BBCLASSEXTEND_append_pn-xrandr = " ${MULTILIBS}"
> BBCLASSEXTEND_append_pn-xrestop = " ${MULTILIBS}"
> BBCLASSEXTEND_append_pn-xserver-nodm-init = " ${MULTILIBS}"
> BBCLASSEXTEND_append_pn-xserver-xf86-config = " ${MULTILIBS}"
> -BBCLASSEXTEND_append_pn-xserver-xf86-dri-lite = " ${MULTILIBS}"
> +BBCLASSEXTEND_append_pn-xserver-xorg = " ${MULTILIBS}"
> BBCLASSEXTEND_append_pn-xset = " ${MULTILIBS}"
> BBCLASSEXTEND_append_pn-xtrans = " ${MULTILIBS}"
> BBCLASSEXTEND_append_pn-xtscal = " ${MULTILIBS}"
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc
> similarity index 96%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc
> index 17d456c..78c5f2e 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc
> @@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=3dd2bbe3563837f80ed8926b06c1c353"
>
> # xf86-*-* packages depend on an X server built with the xfree86 DDX
> # so we have a virtual to represent that:
> +# deprecated, we should use virtual/xserver instead
> PROVIDES = "virtual/xserver-xf86"
>
> # Other packages tend to just care that there is *an* X server:
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite.inc
> similarity index 95%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg-lite.inc
> index 131c258..f1cef1b 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite.inc
> @@ -1,6 +1,4 @@
> -require xserver-xf86-common.inc
> -
> -PROVIDES += "xserver-xf86-lite"
> +require xserver-xorg-common.inc
>
> PROTO_DEPS = "randrproto renderproto fixesproto damageproto xextproto xproto xf86dgaproto xf86miscproto xf86rushproto xf86vidmodeproto xf86bigfontproto compositeproto recordproto resourceproto videoproto scrnsaverproto evieext trapproto xineramaproto fontsproto kbproto inputproto bigreqsproto xcmiscproto glproto"
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/crosscompile.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite/crosscompile.patch
> similarity index 100%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/crosscompile.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg-lite/crosscompile.patch
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite/fix_open_max_preprocessor_error.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite/fix_open_max_preprocessor_error.patch
> similarity index 100%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-lite/fix_open_max_preprocessor_error.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg-lite/fix_open_max_preprocessor_error.patch
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite/macro_tweak.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite/macro_tweak.patch
> similarity index 93%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-lite/macro_tweak.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg-lite/macro_tweak.patch
> index 2b75427..2b32d4e 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite/macro_tweak.patch
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite/macro_tweak.patch
> @@ -2,7 +2,7 @@ This is the revised version of files/macro_tweak.patch for
> xorg-server 1.8.99.904.
>
> the files/macro_tweak.patch can not removed now since it is used by
> -xserver-kdrive-1.7.99.2 and xserver-xf86-lite_1.7.99.2. Once they
> +xserver-kdrive-1.7.99.2 and xserver-xorg(-lite). Once they
> are all upgraded to 1.8.99.904, the the files/macro_tweak.patch
> can be safely replace by this patch.
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.10.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite_1.10.1.bb
> similarity index 89%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.10.1.bb
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg-lite_1.10.1.bb
> index e42f27d..63b2c38 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.10.1.bb
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite_1.10.1.bb
> @@ -1,4 +1,4 @@
> -require xserver-xf86-lite.inc
> +require xserver-xorg-lite.inc
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=74df27b6254cc88d2799b5f4f5949c00"
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> similarity index 97%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> index 6b13873..9bc0ee4 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> @@ -1,4 +1,4 @@
> -require xserver-xf86-common.inc
> +require xserver-xorg-common.inc
>
> PROTO_DEPS = "randrproto renderproto fixesproto damageproto xextproto xproto xf86dgaproto xf86miscproto xf86rushproto xf86vidmodeproto xf86bigfontproto compositeproto recordproto resourceproto videoproto scrnsaverproto evieext trapproto xineramaproto fontsproto kbproto inputproto bigreqsproto xcmiscproto glproto"
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/cache-xkbcomp-output-for-fast-start-up.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/cache-xkbcomp-output-for-fast-start-up.patch
> similarity index 100%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/cache-xkbcomp-output-for-fast-start-up.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg/cache-xkbcomp-output-for-fast-start-up.patch
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite/crosscompile.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
> similarity index 100%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-lite/crosscompile.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/fix_macros1.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/fix_macros1.patch
> similarity index 100%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/fix_macros1.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg/fix_macros1.patch
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/fix_open_max_preprocessor_error.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/fix_open_max_preprocessor_error.patch
> similarity index 100%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/fix_open_max_preprocessor_error.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg/fix_open_max_preprocessor_error.patch
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/macro_tweak.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/macro_tweak.patch
> similarity index 93%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/macro_tweak.patch
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg/macro_tweak.patch
> index 2b75427..2b32d4e 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite/macro_tweak.patch
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/macro_tweak.patch
> @@ -2,7 +2,7 @@ This is the revised version of files/macro_tweak.patch for
> xorg-server 1.8.99.904.
>
> the files/macro_tweak.patch can not removed now since it is used by
> -xserver-kdrive-1.7.99.2 and xserver-xf86-lite_1.7.99.2. Once they
> +xserver-kdrive-1.7.99.2 and xserver-xorg(-lite). Once they
> are all upgraded to 1.8.99.904, the the files/macro_tweak.patch
> can be safely replace by this patch.
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.10.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.10.1.bb
> similarity index 93%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.10.1.bb
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg_1.10.1.bb
> index b797f97..0194798 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.10.1.bb
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.10.1.bb
> @@ -1,4 +1,4 @@
> -require xserver-xf86-dri-lite.inc
> +require xserver-xorg.inc
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=74df27b6254cc88d2799b5f4f5949c00"
>
> diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_git.bb b/meta/recipes-graphics/xorg-xserver/xserver-xorg_git.bb
> similarity index 94%
> rename from meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_git.bb
> rename to meta/recipes-graphics/xorg-xserver/xserver-xorg_git.bb
> index 87ba040..beef06a 100644
> --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_git.bb
> +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_git.bb
> @@ -1,4 +1,4 @@
> -require xserver-xf86-dri-lite.inc
> +require xserver-xorg.inc
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=74df27b6254cc88d2799b5f4f5949c00"
>
[-- Attachment #2: Type: text/html, Size: 19430 bytes --]
^ permalink raw reply
* [PATCH] bluez4: Add ending quote of FILES_${PN}-dbg
From: Noor, Ahsan @ 2011-10-11 5:51 UTC (permalink / raw)
To: openembedded-core
From: Noor Ahsan <noor_ahsan@mentor.com>
* .debug directory was being moved in bluez4 package. Although we have asked to move it in bluez4-dbg package but as FILES_${PN}-dbg was not having ending quote, .debug folder was not being moved to correct directory in packages-split.
Signed-off-by: Noor Ahsan <noor_ahsan@mentor.com>
---
meta/recipes-connectivity/bluez/bluez4_4.96.bb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-connectivity/bluez/bluez4_4.96.bb b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
index 5c170c1..420a525 100644
--- a/meta/recipes-connectivity/bluez/bluez4_4.96.bb
+++ b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
@@ -30,4 +30,4 @@ FILES_${PN}-dbg += "\
${libdir}/bluetooth/plugins/.debug \
${libdir}/*/.debug \
${base_libdir}/udev/.debug \
-
+ "
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 0/1] QEMU 0.15 update please test
From: Khem Raj @ 2011-10-11 5:15 UTC (permalink / raw)
To: Saul Wold; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4E938B7E.8030105@intel.com>
On 10/10/2011 5:19 PM, Saul Wold wrote:
> On 10/10/2011 05:08 PM, Khem Raj wrote:
>> On Sun, Oct 9, 2011 at 9:59 PM, Saul Wold<saul.wold@intel.com> wrote:
>>> On 10/05/2011 12:45 PM, Khem Raj wrote:
>>>>
>>>> This brings in qemu-0.15 into OE-core I have had limited testing
>>>> on it and mainly on qemuarm. Please help testing it on other
>>>> architectures
>>>> I will also work on getting it more solidified and bring some backports
>>>> as needed.
>>>>
>>> Khem,
>>>
>>> Did you do any kind of non-native build, I know it may not make
>>> sense, but
>>> we can support qemu within the target image with 0.14.
>>>
>>
>> no I have not done target builds. Only qemu-native
>
> It looks like it actually it was qemu-nativesdk.
ALright. It needs glib-2.0 therefore I have extended glibc-2.0
recipes to provide glib-2.0-nativesdk and added it to DEPENDS
of qemu-nativesdk as well.
Please pull the patches from same branch again. I have refreshed it
>
>>
>>> My initial testing on the autobuilder seems to imply some dependency on
>>> glib-2.0.
>>>
>>
>> hmmm can you point me to logs
>>
> http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/178/steps/shell_50/logs/stdio
>
>
>>
>>> Thanks
>>> Sau!
>>>
>>>> The following changes since commit
>>>> abde9f65b1617ec61e964c4b3502fd4ad2215dcf:
>>>>
>>>> shared-mime-info: Upgrade recipes from 0.90 -> 0.91 (2011-10-05
>>>> 12:39:47 -0700)
>>>>
>>>> are available in the git repository at:
>>>> git://git.openembedded.org/openembedded-core-contrib kraj/qemu-update
>>>>
>>>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/qemu-update
>>>>
>>>>
>>>> Khem Raj (1):
>>>> qemu-0.15: Add recipe and forward port patches from 0.14
>>>>
>>>> .../qemu/qemu-0.15.0/arm-bgr.patch | 30 +
>>>> .../qemu/qemu-0.15.0/enable-i386-linux-user.patch | 55 +
>>>> .../fallback-to-safe-mmap_min_addr.patch | 39 +
>>>> .../qemu/qemu-0.15.0/fix-configure-checks.patch | 22 +
>>>> .../qemu/qemu-0.15.0/fix-nogl.patch | 127 +
>>>> .../qemu/qemu-0.15.0/glflags.patch | 15 +
>>>> .../qemu/qemu-0.15.0/init-info.patch | 18 +
>>>> .../qemu/qemu-0.15.0/larger_default_ram_size.patch | 22 +
>>>> .../qemu/qemu-0.15.0/linker-flags.patch | 25 +
>>>> .../qemu/qemu-0.15.0/no-strip.patch | 15 +
>>>> .../qemu/qemu-0.15.0/opengl-sdl-fix.patch | 43 +
>>>> .../qemu/qemu-0.15.0/powerpc_rom.bin | Bin 0 -> 4096
>>>> bytes
>>>> .../qemu/qemu-0.15.0/qemu-git-qemugl-host.patch |34368
>>>> ++++++++++++++++++++
>>>> .../qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch | 118 +
>>>> .../qemugl-allow-glxcontext-release.patch | 65 +
>>>> .../qemu/qemu-0.15.0/qemugl-fix.patch | 74 +
>>>> meta/recipes-devtools/qemu/qemu_0.15.0.bb | 45 +
>>>> 17 files changed, 35081 insertions(+), 0 deletions(-)
>>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/arm-bgr.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/enable-i386-linux-user.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/fallback-to-safe-mmap_min_addr.patch
>>>>
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/fix-configure-checks.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/fix-nogl.patch
>>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/glflags.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/init-info.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/larger_default_ram_size.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/linker-flags.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/no-strip.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/opengl-sdl-fix.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/powerpc_rom.bin
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-git-qemugl-host.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-allow-glxcontext-release.patch
>>>>
>>>> create mode 100644
>>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-fix.patch
>>>> create mode 100644 meta/recipes-devtools/qemu/qemu_0.15.0.bb
>>>>
>>>
>>>
>
^ permalink raw reply
* Re: [PATCH 0/1] QEMU 0.15 update please test
From: Saul Wold @ 2011-10-11 0:19 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soHxwjCx4U9xErYXnwYdRo1ksawSZGBZgF8iXDODjeLfA@mail.gmail.com>
On 10/10/2011 05:08 PM, Khem Raj wrote:
> On Sun, Oct 9, 2011 at 9:59 PM, Saul Wold<saul.wold@intel.com> wrote:
>> On 10/05/2011 12:45 PM, Khem Raj wrote:
>>>
>>> This brings in qemu-0.15 into OE-core I have had limited testing
>>> on it and mainly on qemuarm. Please help testing it on other architectures
>>> I will also work on getting it more solidified and bring some backports
>>> as needed.
>>>
>> Khem,
>>
>> Did you do any kind of non-native build, I know it may not make sense, but
>> we can support qemu within the target image with 0.14.
>>
>
> no I have not done target builds. Only qemu-native
It looks like it actually it was qemu-nativesdk.
>
>> My initial testing on the autobuilder seems to imply some dependency on
>> glib-2.0.
>>
>
> hmmm can you point me to logs
>
http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/178/steps/shell_50/logs/stdio
>
>> Thanks
>> Sau!
>>
>>> The following changes since commit
>>> abde9f65b1617ec61e964c4b3502fd4ad2215dcf:
>>>
>>> shared-mime-info: Upgrade recipes from 0.90 -> 0.91 (2011-10-05
>>> 12:39:47 -0700)
>>>
>>> are available in the git repository at:
>>> git://git.openembedded.org/openembedded-core-contrib kraj/qemu-update
>>>
>>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/qemu-update
>>>
>>> Khem Raj (1):
>>> qemu-0.15: Add recipe and forward port patches from 0.14
>>>
>>> .../qemu/qemu-0.15.0/arm-bgr.patch | 30 +
>>> .../qemu/qemu-0.15.0/enable-i386-linux-user.patch | 55 +
>>> .../fallback-to-safe-mmap_min_addr.patch | 39 +
>>> .../qemu/qemu-0.15.0/fix-configure-checks.patch | 22 +
>>> .../qemu/qemu-0.15.0/fix-nogl.patch | 127 +
>>> .../qemu/qemu-0.15.0/glflags.patch | 15 +
>>> .../qemu/qemu-0.15.0/init-info.patch | 18 +
>>> .../qemu/qemu-0.15.0/larger_default_ram_size.patch | 22 +
>>> .../qemu/qemu-0.15.0/linker-flags.patch | 25 +
>>> .../qemu/qemu-0.15.0/no-strip.patch | 15 +
>>> .../qemu/qemu-0.15.0/opengl-sdl-fix.patch | 43 +
>>> .../qemu/qemu-0.15.0/powerpc_rom.bin | Bin 0 -> 4096
>>> bytes
>>> .../qemu/qemu-0.15.0/qemu-git-qemugl-host.patch |34368
>>> ++++++++++++++++++++
>>> .../qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch | 118 +
>>> .../qemugl-allow-glxcontext-release.patch | 65 +
>>> .../qemu/qemu-0.15.0/qemugl-fix.patch | 74 +
>>> meta/recipes-devtools/qemu/qemu_0.15.0.bb | 45 +
>>> 17 files changed, 35081 insertions(+), 0 deletions(-)
>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/arm-bgr.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/enable-i386-linux-user.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/fallback-to-safe-mmap_min_addr.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/fix-configure-checks.patch
>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/fix-nogl.patch
>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/glflags.patch
>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/init-info.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/larger_default_ram_size.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/linker-flags.patch
>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/no-strip.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/opengl-sdl-fix.patch
>>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/powerpc_rom.bin
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-git-qemugl-host.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-allow-glxcontext-release.patch
>>> create mode 100644
>>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-fix.patch
>>> create mode 100644 meta/recipes-devtools/qemu/qemu_0.15.0.bb
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH 0/1] QEMU 0.15 update please test
From: Khem Raj @ 2011-10-11 0:08 UTC (permalink / raw)
To: Saul Wold; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4E927BBE.3030908@intel.com>
On Sun, Oct 9, 2011 at 9:59 PM, Saul Wold <saul.wold@intel.com> wrote:
> On 10/05/2011 12:45 PM, Khem Raj wrote:
>>
>> This brings in qemu-0.15 into OE-core I have had limited testing
>> on it and mainly on qemuarm. Please help testing it on other architectures
>> I will also work on getting it more solidified and bring some backports
>> as needed.
>>
> Khem,
>
> Did you do any kind of non-native build, I know it may not make sense, but
> we can support qemu within the target image with 0.14.
>
no I have not done target builds. Only qemu-native
> My initial testing on the autobuilder seems to imply some dependency on
> glib-2.0.
>
hmmm can you point me to logs
> Thanks
> Sau!
>
>> The following changes since commit
>> abde9f65b1617ec61e964c4b3502fd4ad2215dcf:
>>
>> shared-mime-info: Upgrade recipes from 0.90 -> 0.91 (2011-10-05
>> 12:39:47 -0700)
>>
>> are available in the git repository at:
>> git://git.openembedded.org/openembedded-core-contrib kraj/qemu-update
>>
>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/qemu-update
>>
>> Khem Raj (1):
>> qemu-0.15: Add recipe and forward port patches from 0.14
>>
>> .../qemu/qemu-0.15.0/arm-bgr.patch | 30 +
>> .../qemu/qemu-0.15.0/enable-i386-linux-user.patch | 55 +
>> .../fallback-to-safe-mmap_min_addr.patch | 39 +
>> .../qemu/qemu-0.15.0/fix-configure-checks.patch | 22 +
>> .../qemu/qemu-0.15.0/fix-nogl.patch | 127 +
>> .../qemu/qemu-0.15.0/glflags.patch | 15 +
>> .../qemu/qemu-0.15.0/init-info.patch | 18 +
>> .../qemu/qemu-0.15.0/larger_default_ram_size.patch | 22 +
>> .../qemu/qemu-0.15.0/linker-flags.patch | 25 +
>> .../qemu/qemu-0.15.0/no-strip.patch | 15 +
>> .../qemu/qemu-0.15.0/opengl-sdl-fix.patch | 43 +
>> .../qemu/qemu-0.15.0/powerpc_rom.bin | Bin 0 -> 4096
>> bytes
>> .../qemu/qemu-0.15.0/qemu-git-qemugl-host.patch |34368
>> ++++++++++++++++++++
>> .../qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch | 118 +
>> .../qemugl-allow-glxcontext-release.patch | 65 +
>> .../qemu/qemu-0.15.0/qemugl-fix.patch | 74 +
>> meta/recipes-devtools/qemu/qemu_0.15.0.bb | 45 +
>> 17 files changed, 35081 insertions(+), 0 deletions(-)
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/arm-bgr.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/enable-i386-linux-user.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/fallback-to-safe-mmap_min_addr.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/fix-configure-checks.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/fix-nogl.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/glflags.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/init-info.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/larger_default_ram_size.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/linker-flags.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/no-strip.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/opengl-sdl-fix.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/powerpc_rom.bin
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-git-qemugl-host.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-allow-glxcontext-release.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-fix.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu_0.15.0.bb
>>
>
>
^ permalink raw reply
* [PATCH 1/2, v2] autotools: fix multi-word arguments for EXTRA_OECONF
From: Christopher Larson @ 2011-10-10 21:13 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318281075.git.kergoth@gmail.com>
This is needed to better support things like the following (with a
multi-word BUILD_CC):
EXTRA_OECONF += '"ac_cv_prog_CC_FOR_BUILD=${BUILD_CC}"'
Signed-off-by: Christopher Larson <kergoth@gmail.com>
---
meta/classes/autotools.bbclass | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index a4ce851..937e2ba 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -71,10 +71,8 @@ CONFIGUREOPT_DEPTRACK = "--disable-dependency-tracking"
oe_runconf () {
if [ -x ${S}/configure ] ; then
- cfgcmd="${S}/configure \
- ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
- bbnote "Running $cfgcmd..."
- $cfgcmd || bbfatal "oe_runconf failed"
+ bbnote "Running ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
+ ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} "$@" || bbfatal "oe_runconf failed"
else
bbfatal "no configure script found"
fi
--
1.7.3.2.430.g208247
^ permalink raw reply related
* [PATCH 2/2] autoconf: no need to hardcode the full path to m4
From: Christopher Larson @ 2011-10-10 21:13 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318281075.git.kergoth@gmail.com>
This way autom4te uses m4 as it finds it in the PATH, rather than
hardcoding any particular path.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
---
meta/recipes-devtools/autoconf/autoconf_2.68.bb | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/autoconf/autoconf_2.68.bb b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
index c6209a3..21b5fb3 100644
--- a/meta/recipes-devtools/autoconf/autoconf_2.68.bb
+++ b/meta/recipes-devtools/autoconf/autoconf_2.68.bb
@@ -1,6 +1,6 @@
require autoconf.inc
-PR = "r2"
+PR = "r3"
PARALLEL_MAKE = ""
@@ -27,4 +27,6 @@ RDEPENDS_${PN}_virtclass-native = "m4-native gnu-config-native"
SRC_URI_append_virtclass-native = " file://fix_path_xtra.patch"
+EXTRA_OECONF += "ac_cv_path_M4=m4"
+
BBCLASSEXTEND = "native"
--
1.7.3.2.430.g208247
^ permalink raw reply related
* [PATCH 0/2] Minor autoconf & autotools.bbclass fixes (supercedes previous misc fixes request)
From: Christopher Larson @ 2011-10-10 21:13 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 4732222c46652951e66aae377631f4a361179d8f:
Fix sysprof for powerpc64 (2011-10-10 09:54:03 +0100)
are available in the git repository at:
http://github.com/kergoth/oe-core misc-fixes
Christopher Larson (2):
autotools: fix multi-word arguments for EXTRA_OECONF
autoconf: no need to hardcode the full path to m4
meta/classes/autotools.bbclass | 6 ++----
meta/recipes-devtools/autoconf/autoconf_2.68.bb | 4 +++-
2 files changed, 5 insertions(+), 5 deletions(-)
--
1.7.3.2.430.g208247
^ permalink raw reply
* Re: [PATCH 3/3] oe.patch: drop bb.msg.domain reference
From: Chris Larson @ 2011-10-10 21:09 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAGiJk9ceiROvLEL-FsT2kLR50rG16xCDo-__cRyqryfSAO0AOQ@mail.gmail.com>
On Mon, Oct 10, 2011 at 12:17 AM, Samuel Stirtzel
<s.stirtzel@googlemail.com> wrote:
> Hi,
> there was already a patch for this [1] (Yes I know, I should have
> added more descriptions), according to the patch from Richard [2] the
> message domain can be constructed dynamical now.
> Since your patch seems a little bit different (dropping the message
> domain completely) I can't tell if my resolution was inadequate.
>
> For this patch I think it wouldn't make a big difference for the user,
> feel free to apply the one that best suits in resolving the problem.
>
>
> [1] http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/009474.html
> [2] http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a6c48298b17e6a5844b3638b422fe226e3b67b89
Indeed, your version is superior.
For what it's worth, consider both of those patches of yours acked by
me. Getting useful error messages rather than python syntax errors is
rather important.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: [PATCH] util-linux 2.19.1: split blkid out into its own subpackage
From: Philip Balister @ 2011-10-10 21:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318241454-10545-1-git-send-email-koen@dominion.thruhere.net>
On 10/10/2011 06:10 AM, Koen Kooi wrote:
> Recent udev versions require blkid from u-l, not from e2fsprogs. In general all the non fsck related binaries from e2fsprogs are deprecated.
>
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Acked-by: Philip Balister < philip@balister.org>
> ---
> meta/recipes-core/util-linux/util-linux.inc | 15 ++++++++++++++-
> meta/recipes-core/util-linux/util-linux_2.19.1.bb | 2 +-
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
> index 8762ac6..67d81b9 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -29,7 +29,7 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk util-linux-sfd
> util-linux-swaponoff util-linux-losetup util-linux-umount \
> util-linux-mount util-linux-readprofile util-linux-libblkid \
> util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev \
> - util-linux-uuidgen util-linux-lscpu util-linux-fsck"
> + util-linux-uuidgen util-linux-lscpu util-linux-fsck util-linux-blkid"
>
> EXTRA_OECONF = "--disable-use-tty-group --disable-makeinstall-chown --enable-elvtune --enable-init --enable-kill --enable-last \
> --enable-mesg --enable-partx --enable-raw --enable-rdev --enable-reset \
> @@ -56,6 +56,11 @@ FILES_util-linux-lscpu = "${bindir}/lscpu"
>
> FILES_util-linux-fsck = "${base_sbindir}/fsck*"
>
> +# Util-linux' blkid replaces the e2fsprogs one
> +FILES_util-linux-blkid = "${base_sbindir}/blkid*"
> +RCONFLICTS_util-linux-blkid = "e2fsprogs-blkid"
> +RREPLACES_util-linux-blkid = "e2fsprogs-blkid"
> +
> RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile "
> RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup perl"
>
> @@ -262,4 +267,12 @@ pkg_prerm_util-linux-fsck () {
> update-alternatives --remove fsck fsck.${PN}
> }
>
> +pkg_postinst_util-linux-blkid () {
> + update-alternatives --install ${base_sbindir}/blkid blkid blkid.${PN} 100
> +}
> +
> +pkg_prerm_util-linux-blkid () {
> + update-alternatives --remove blkid blkid.${PN}
> +}
> +
> BBCLASSEXTEND = "native"
> diff --git a/meta/recipes-core/util-linux/util-linux_2.19.1.bb b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
> index 39ff68c..04f4457 100644
> --- a/meta/recipes-core/util-linux/util-linux_2.19.1.bb
> +++ b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
> @@ -1,5 +1,5 @@
> MAJOR_VERSION = "2.19"
> -PR = "r7"
> +PR = "r8"
> require util-linux.inc
>
> # note that `lscpu' is under GPLv3+
^ permalink raw reply
* Some further build dependency timings
From: Richard Purdie @ 2011-10-10 20:45 UTC (permalink / raw)
To: openembedded-core
Just for reference, with a base configuration, sato image:
real 50m8.223s
user 298m41.450s
sys 52m42.200s
adding:
ASSUME_PROVIDED =+ "bison-native flex-native sqlite3-native git-native"
(and hacking the pseudo recipe to use a sqlite3-native):
real 42m6.740s
user 296m21.940s
sys 52m25.220s
We continue to have real dependency issues around gettext in both the
native and target builds...
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] bitbake.conf: Exclude MACHINE from OVERRIDES variable dependency list
From: Richard Purdie @ 2011-10-10 20:41 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <694CEF86-6C03-49B8-BB8A-9C03E0E30D03@dominion.thruhere.net>
On Mon, 2011-10-10 at 17:53 +0200, Koen Kooi wrote:
> Op 10 okt. 2011, om 17:40 heeft Richard Purdie het volgende geschreven:
>
> > On Mon, 2011-10-10 at 17:02 +0200, Koen Kooi wrote:
> >> Op 10 okt. 2011, om 16:06 heeft Richard Purdie het volgende geschreven:
> >>
> >>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>> ---
> >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>> index a1420cf..11d76b8 100644
> >>> --- a/meta/conf/bitbake.conf
> >>> +++ b/meta/conf/bitbake.conf
> >>> @@ -669,6 +669,7 @@ AUTO_LIBNAME_PKGS = "${PACKAGES}"
> >>> OVERRIDES = "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
> >>> DISTROOVERRIDES ?= "${DISTRO}"
> >>> MACHINEOVERRIDES ?= "${MACHINE}"
> >>> +OVERRIDES[vardepsexclude] = "MACHINE"
> >>>
> >>> CPU_FEATURES ?= ""
> >>> CPU_FEATURES_arm ?= "vfp"
> >>
> >>
> >> MACHINE=omap4430-panda bitbake bash -c cleansstate
> >> MACHINE=beagleboard bitbake bash
> >> MACHINE=omap4430-panda bitbake bash
> >>
> >> It fully built bash in both case, the diffsig sleuthing I was able to do:
> >>
> >> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/stamps/armv7a-angstrom-linux-gnueabi$ ls | grep bash | grep sigdata | sort
> >> bash-4.1-r2.do_cleansstate.sigdata.dade34525ff3d7567b7e86b24a36307b
> >> bash-4.1-r2.do_fetch.sigdata.15f6bc3de53f1de78303e73688c4f340
> >> bash-4.1-r2.do_unpack.sigdata.980bf1d8267fee1ac36b68c96c4f268c
> >> bash-4.1-r2.do_patch.sigdata.0185f3c332733ffa162bc38244f2f0b4
> >> bash-4.1-r2.do_configure.sigdata.4527bef6d2e22f73a51628c2ac5e7d4e
> >> bash-4.1-r2.do_compile.sigdata.d5cb0399ec5f76911c78cfc99a05663a
> >> bash-4.1-r2.do_install.sigdata.b1781f7a0718ba9922a970820d565455
> >> bash-4.1-r2.do_package.sigdata.2a38d9a1a086e31e620321c1b346514f
> >> bash-4.1-r2.do_package.sigdata.4c4f326e3ba2029d207aca186c9ea332
> >> bash-4.1-r2.do_package_write_ipk.sigdata.191dbf64100c3b552a86c361a07e134f
> >> bash-4.1-r2.do_populate_sysroot.sigdata.1643e8bfc8905ff3f269b8ca40d16d17
> >> bash-4.1-r2.do_rm_work_all.sigdata.25cbc1786f8d193c1569e77497d098af
> >> bash-4.1-r2.do_rm_work_all.sigdata.d019b1e392601856aa407615da0c54af
> >> bash-4.1-r2.do_rm_work.sigdata.1453d491285d51b9a88a913bcc6cc72c
> >> bash-4.1-r2.do_rm_work.sigdata.b8f0f9e26355b721638b66069ad83e4e
> >> bash-4.1-r2.do_populate_lic.sigdata.c7c785ae2f366e5a0d8bea4e144e43d0
> >>
> >> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/stamps/armv7a-angstrom-linux-gnueabi$ bitbake-diffsigs bash-4.1-r2.do_package.sigdata.2a38d9a1a086e31e620321c1b346514f bash-4.1-r2.do_package.sigdata.4c4f326e3ba2029d207aca186c9ea332
> >> basehash changed from da302dbd386f214d39fbd6fb01267c8d to 1b439cf1d8c12894e96e96b299a27c12
> >> Variable MACHINE value changed from beagleboard to omap4430-panda
> >
> > So this tells us what changed but it doesn't tell us why its being
> > depended upon. Could you share the output of:
> >
> > /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/stamps/armv7a-angstrom-linux-gnueabi$ bitbake-diffsigs bash-4.1-r2.do_package.sigdata.2a38d9a1a086e31e620321c1b346514f
> >
> > please so we can see why bash is depending on MACHINE?
>
> More than 2500 lines:
>
> http://dominion.thruhere.net/koen/angstrom/diffsigs.txt
>
> Some grepping shows:
>
> List of dependencies for variable OVERRIDES is set(['OVERRIDE_INTERWORK', 'OVERRIDE_THUMB', 'DISTROOVERRIDES', 'TARGET_ARCH', 'BUILD_OS', 'PN', 'TARGET_OS', 'MACHINEOVERRIDES'])
> List of dependencies for variable MACHINE is set([])
> List of dependencies for variable MACHINEOVERRIDES is set(['MACHINE', 'SOC_FAMILY', 'FEED_ARCH'])
> Variable OVERRIDES value is ${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}:libc-glibc:libc-glibc
> Variable MACHINE value is omap4430-panda
> Variable MACHINEOVERRIDES value is ${MACHINE}:${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}:${SOC_FAMILY}
>
> So does MACHINEOVERRIDES need to get whitelisted as well?
I suspect so, yes. My patch shouldn't have really worked at all :/.
Cheers,
Richard
^ permalink raw reply
* Re: [RFC] Fix typo in meta/classes/sanity.bbclass
From: Richard Purdie @ 2011-10-10 20:37 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNfpf97anznqn8ZqgOXmJEZp3sA4pK7aALT2w=3G2SjPbA@mail.gmail.com>
On Mon, 2011-10-10 at 18:21 +0000, McClintock Matthew-B29882 wrote:
> Ping? Any comments?
>
> -M
>
> On Mon, Oct 3, 2011 at 6:48 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
> > On Mon, Oct 3, 2011 at 6:39 PM, Matthew McClintock <msm@freescale.com> wrote:
> >> Signed-off-by: Matthew McClintock <msm@freescale.com>
> >
> > Whoops =)
> >
> >> ---
> >> Not sure if this is correct but it looks like a typo, also
> >> there appears to be some issues with the fix as well
> >>
> >> meta/classes/sanity.bbclass | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> >> index 4067408..cf30927 100644
> >> --- a/meta/classes/sanity.bbclass
> >> +++ b/meta/classes/sanity.bbclass
> >> @@ -169,7 +169,7 @@ def check_sanity_validmachine(e):
> >> messages = messages + 'TUNE_ARCH is unset. Please ensure your MACHINE configuration includes a valid tune configuration file which will set this correctly.\n'
> >>
> >> # Check TARGET_ARCH is set correctly
> >> - if data.getVar('TARGE_ARCH', e.data, False) == '${TUNE_ARCH}':
> >> + if data.getVar('TARGET_ARCH', e.data, False) == '${TUNE_ARCH}':
> >> messages = messages + 'TARGET_ARCH is being overwritten, likely by your MACHINE configuration files.\nPlease use a valid tune configuration file which should set this correctly automatically\nand avoid setting this in the machine configuration. See the OE-Core mailing list for more information.\n'
> >>
> >> # Check TARGET_OS is set
> >
> > After fixing this I see the following:
> >
> > ERROR: Poky's config sanity checker detected a potential misconfiguration.
> > Either fix the cause of this error or at your own risk disable the
> > checker (see sanity.conf).
> > Following is the list of potential problems / advisories:
> >
> > TARGET_ARCH is being overwritten, likely by your MACHINE
> > configuration files.
> > Please use a valid tune configuration file which should set this
> > correctly automatically
> > and avoid setting this in the machine configuration. See the OE-Core
> > mailing list for more information.
> >
> > ERROR: Execution of event handler 'check_sanity_eventhandler' failed
I've been meaning to check OECore to ensure this isn't going to cause
failures before adding the patch. I then forgot I needed to do this,
sorry :/. What I don't want to do is merge something which breaks things
for everyone...
Cheers,
Richard
^ permalink raw reply
* Re: Multiple git repos in SRC_URI and/or git submodules support
From: Richard Purdie @ 2011-10-10 20:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKq+9Bhu9A8jZhYH-uBVSWcncsNQvAxyNxLnG133J237iA@mail.gmail.com>
On Mon, 2011-10-10 at 16:40 -0300, Otavio Salvador wrote:
> On Mon, Oct 10, 2011 at 15:19, Koen Kooi <koen@dominion.thruhere.net> wrote:
> ...
> > I'm not going to do 1), 3) is unlikely, so I want to ask if 2) is
> already supported. I've seen various patches that add an 'unpackdir'
> or similar, but I can't find any docs on it. Can someone enlighten me
> on the current status of that?
> ...
>
> Yes, this works. I have added support to SRCREV_FORMAT into gitpkgv too ;-)
Just to be clear, something like:
SRC_URI = "\
git://foo.git?subpath=bar \
git://foo2.git?subpath=bar2 \
"
should work but I can think of reasons why it might get confused. Try
it, report back and if it fails we can figure out ways to fix it...
Cheers,
Richard
^ permalink raw reply
* Re: Multiple git repos in SRC_URI and/or git submodules support
From: Otavio Salvador @ 2011-10-10 20:14 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CDD7988D-2486-484F-B1A5-347A38D64F01@dominion.thruhere.net>
On Mon, Oct 10, 2011 at 17:01, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 10 okt. 2011, om 21:40 heeft Otavio Salvador het volgende geschreven:
>
>> On Mon, Oct 10, 2011 at 15:19, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> ...
>>> I'm not going to do 1), 3) is unlikely, so I want to ask if 2) is already supported. I've seen various patches that add an 'unpackdir' or similar, but I can't find any docs on it. Can someone enlighten me on the current status of that?
>> ...
>>
>> Yes, this works. I have added support to SRCREV_FORMAT into gitpkgv too ;-)
>
> So what's the magic param I need to pass to the fetcher to make this work?
Basic example:
SRCREV_main = "..."
SRCREV_core = "...."
SRC_URI = " \
git://fooserver/git/foo.git;name=main \
git://fooserver/git/foo-core.git;name=core;destsuffix=git/foo-core"
S = "${WORKDIR}/git"
SRCREV_FORMAT = "main-core"
Enjoy ;-)
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: Multiple git repos in SRC_URI and/or git submodules support
From: Koen Kooi @ 2011-10-10 20:01 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKq+9Bhu9A8jZhYH-uBVSWcncsNQvAxyNxLnG133J237iA@mail.gmail.com>
Op 10 okt. 2011, om 21:40 heeft Otavio Salvador het volgende geschreven:
> On Mon, Oct 10, 2011 at 15:19, Koen Kooi <koen@dominion.thruhere.net> wrote:
> ...
>> I'm not going to do 1), 3) is unlikely, so I want to ask if 2) is already supported. I've seen various patches that add an 'unpackdir' or similar, but I can't find any docs on it. Can someone enlighten me on the current status of that?
> ...
>
> Yes, this works. I have added support to SRCREV_FORMAT into gitpkgv too ;-)
So what's the magic param I need to pass to the fetcher to make this work?
^ permalink raw reply
* Use of mingetty
From: Otavio Salvador @ 2011-10-10 19:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hello,
I've trying to build a minimal image here and found that it fails with
getty being not available.
I want to know how this is suppose to work since the only way I got it
more or less working is doing:
...
ROOTFS_POSTPROCESS_COMMAND += "(cd ${IMAGE_ROOTFS}/sbin ; ln -s
mingetty getty); "
...
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: Multiple git repos in SRC_URI and/or git submodules support
From: Otavio Salvador @ 2011-10-10 19:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <678AE8F3-DBF3-4315-83A5-AA2CA040C5D8@dominion.thruhere.net>
On Mon, Oct 10, 2011 at 15:19, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
> I'm not going to do 1), 3) is unlikely, so I want to ask if 2) is already supported. I've seen various patches that add an 'unpackdir' or similar, but I can't find any docs on it. Can someone enlighten me on the current status of that?
...
Yes, this works. I have added support to SRCREV_FORMAT into gitpkgv too ;-)
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [RFC] Fix typo in meta/classes/sanity.bbclass
From: McClintock Matthew-B29882 @ 2011-10-10 18:21 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
In-Reply-To: <CAEsOVNdbpyesRT7UHdcXWMmp8fv1Wiyx6dUiTi40AVNgaOogGQ@mail.gmail.com>
Ping? Any comments?
-M
On Mon, Oct 3, 2011 at 6:48 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Mon, Oct 3, 2011 at 6:39 PM, Matthew McClintock <msm@freescale.com> wrote:
>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>
> Whoops =)
>
>> ---
>> Not sure if this is correct but it looks like a typo, also
>> there appears to be some issues with the fix as well
>>
>> meta/classes/sanity.bbclass | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
>> index 4067408..cf30927 100644
>> --- a/meta/classes/sanity.bbclass
>> +++ b/meta/classes/sanity.bbclass
>> @@ -169,7 +169,7 @@ def check_sanity_validmachine(e):
>> messages = messages + 'TUNE_ARCH is unset. Please ensure your MACHINE configuration includes a valid tune configuration file which will set this correctly.\n'
>>
>> # Check TARGET_ARCH is set correctly
>> - if data.getVar('TARGE_ARCH', e.data, False) == '${TUNE_ARCH}':
>> + if data.getVar('TARGET_ARCH', e.data, False) == '${TUNE_ARCH}':
>> messages = messages + 'TARGET_ARCH is being overwritten, likely by your MACHINE configuration files.\nPlease use a valid tune configuration file which should set this correctly automatically\nand avoid setting this in the machine configuration. See the OE-Core mailing list for more information.\n'
>>
>> # Check TARGET_OS is set
>
> After fixing this I see the following:
>
> ERROR: Poky's config sanity checker detected a potential misconfiguration.
> Either fix the cause of this error or at your own risk disable the
> checker (see sanity.conf).
> Following is the list of potential problems / advisories:
>
> TARGET_ARCH is being overwritten, likely by your MACHINE
> configuration files.
> Please use a valid tune configuration file which should set this
> correctly automatically
> and avoid setting this in the machine configuration. See the OE-Core
> mailing list for more information.
>
> ERROR: Execution of event handler 'check_sanity_eventhandler' failed
>
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Multiple git repos in SRC_URI and/or git submodules support
From: Koen Kooi @ 2011-10-10 18:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hi,
In meta-oe we have a recipe that is using git submodules to drag it parts of the source and to do it is doing the submodule fetching in do_configure. This is bad for various reasons, so I'd like to fix it. The options I see:
1) Make fetch2 to do git clone --recursive and later realize it is now non-determistic
2) Use multiple git repos in SRC_URI and then to cp/mv/etc to emulate submodules
3) convince upstream submodules are bad
I'm not going to do 1), 3) is unlikely, so I want to ask if 2) is already supported. I've seen various patches that add an 'unpackdir' or similar, but I can't find any docs on it. Can someone enlighten me on the current status of that?
regards,
Koen
^ permalink raw reply
* Re: PREFERRED_PROVIDER weirdness with libltdl-dev
From: Chris Larson @ 2011-10-10 17:23 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <5313791D-358D-4280-967E-8F622071C091@dominion.thruhere.net>
On Mon, Oct 10, 2011 at 9:54 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> NOTE: multiple providers are available for runtime libltdl-dev (libtool-nativesdk, libtool)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match libltdl-dev
>
> So I added that do angstrom:
>
> koen@dominion:/OE/tentacle/sources/meta-angstrom$ git grep libltdl
> conf/distro/include/angstrom-core-tweaks.inc:PREFERRED_PROVIDER_libltdl-dev = "libtool"
>
> But the warning remains:
>
> koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ MACHINE=beagleboard bitbake -e task-sdk-target | grep PREFERRED_PROVIDER | grep ltdl
> NOTE: consider defining a PREFERRED_PROVIDER entry to match libltdl-dev
> # PREFERRED_PROVIDER_libltdl-dev=libtool
> PREFERRED_PROVIDER_libltdl-dev="libtool"
>
> And it keeps trying to build -sdk stuff
The warning is referring to the *runtime* package, but there's
actually no existing syntax to specify a runtime preference directly.
You can't say I want this recipe as the provider for that runtime
package, not this other one. The only thing you can do is specify a
build time preference on that same recipe, which will be seen as an
implicit preference on the runtime. E.g.:
PREFERRED_PROVIDER_libtool = "libtool"
This is a glaring weak spot in bitbake's preference configuration, in
my opinion. It would be nice to address this more directly.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* PREFERRED_PROVIDER weirdness with libltdl-dev
From: Koen Kooi @ 2011-10-10 16:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Hi,
I'm trying to build a toolchain that work on my target and I'm running into this:
NOTE: multiple providers are available for runtime libltdl-dev (libtool-nativesdk, libtool)
NOTE: consider defining a PREFERRED_PROVIDER entry to match libltdl-dev
So I added that do angstrom:
koen@dominion:/OE/tentacle/sources/meta-angstrom$ git grep libltdl
conf/distro/include/angstrom-core-tweaks.inc:PREFERRED_PROVIDER_libltdl-dev = "libtool"
But the warning remains:
koen@dominion:/OE/tentacle/sources/openembedded-core/meta$ MACHINE=beagleboard bitbake -e task-sdk-target | grep PREFERRED_PROVIDER | grep ltdl
NOTE: consider defining a PREFERRED_PROVIDER entry to match libltdl-dev
# PREFERRED_PROVIDER_libltdl-dev=libtool
PREFERRED_PROVIDER_libltdl-dev="libtool"
And it keeps trying to build -sdk stuff
regards,
Koen
^ permalink raw reply
* Re: [PATCH] bitbake.conf: Exclude MACHINE from OVERRIDES variable dependency list
From: Koen Kooi @ 2011-10-10 15:53 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318261226.23801.49.camel@ted>
Op 10 okt. 2011, om 17:40 heeft Richard Purdie het volgende geschreven:
> On Mon, 2011-10-10 at 17:02 +0200, Koen Kooi wrote:
>> Op 10 okt. 2011, om 16:06 heeft Richard Purdie het volgende geschreven:
>>
>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>> ---
>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>>> index a1420cf..11d76b8 100644
>>> --- a/meta/conf/bitbake.conf
>>> +++ b/meta/conf/bitbake.conf
>>> @@ -669,6 +669,7 @@ AUTO_LIBNAME_PKGS = "${PACKAGES}"
>>> OVERRIDES = "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
>>> DISTROOVERRIDES ?= "${DISTRO}"
>>> MACHINEOVERRIDES ?= "${MACHINE}"
>>> +OVERRIDES[vardepsexclude] = "MACHINE"
>>>
>>> CPU_FEATURES ?= ""
>>> CPU_FEATURES_arm ?= "vfp"
>>
>>
>> MACHINE=omap4430-panda bitbake bash -c cleansstate
>> MACHINE=beagleboard bitbake bash
>> MACHINE=omap4430-panda bitbake bash
>>
>> It fully built bash in both case, the diffsig sleuthing I was able to do:
>>
>> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/stamps/armv7a-angstrom-linux-gnueabi$ ls | grep bash | grep sigdata | sort
>> bash-4.1-r2.do_cleansstate.sigdata.dade34525ff3d7567b7e86b24a36307b
>> bash-4.1-r2.do_fetch.sigdata.15f6bc3de53f1de78303e73688c4f340
>> bash-4.1-r2.do_unpack.sigdata.980bf1d8267fee1ac36b68c96c4f268c
>> bash-4.1-r2.do_patch.sigdata.0185f3c332733ffa162bc38244f2f0b4
>> bash-4.1-r2.do_configure.sigdata.4527bef6d2e22f73a51628c2ac5e7d4e
>> bash-4.1-r2.do_compile.sigdata.d5cb0399ec5f76911c78cfc99a05663a
>> bash-4.1-r2.do_install.sigdata.b1781f7a0718ba9922a970820d565455
>> bash-4.1-r2.do_package.sigdata.2a38d9a1a086e31e620321c1b346514f
>> bash-4.1-r2.do_package.sigdata.4c4f326e3ba2029d207aca186c9ea332
>> bash-4.1-r2.do_package_write_ipk.sigdata.191dbf64100c3b552a86c361a07e134f
>> bash-4.1-r2.do_populate_sysroot.sigdata.1643e8bfc8905ff3f269b8ca40d16d17
>> bash-4.1-r2.do_rm_work_all.sigdata.25cbc1786f8d193c1569e77497d098af
>> bash-4.1-r2.do_rm_work_all.sigdata.d019b1e392601856aa407615da0c54af
>> bash-4.1-r2.do_rm_work.sigdata.1453d491285d51b9a88a913bcc6cc72c
>> bash-4.1-r2.do_rm_work.sigdata.b8f0f9e26355b721638b66069ad83e4e
>> bash-4.1-r2.do_populate_lic.sigdata.c7c785ae2f366e5a0d8bea4e144e43d0
>>
>> koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/stamps/armv7a-angstrom-linux-gnueabi$ bitbake-diffsigs bash-4.1-r2.do_package.sigdata.2a38d9a1a086e31e620321c1b346514f bash-4.1-r2.do_package.sigdata.4c4f326e3ba2029d207aca186c9ea332
>> basehash changed from da302dbd386f214d39fbd6fb01267c8d to 1b439cf1d8c12894e96e96b299a27c12
>> Variable MACHINE value changed from beagleboard to omap4430-panda
>
> So this tells us what changed but it doesn't tell us why its being
> depended upon. Could you share the output of:
>
> /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/stamps/armv7a-angstrom-linux-gnueabi$ bitbake-diffsigs bash-4.1-r2.do_package.sigdata.2a38d9a1a086e31e620321c1b346514f
>
> please so we can see why bash is depending on MACHINE?
More than 2500 lines:
http://dominion.thruhere.net/koen/angstrom/diffsigs.txt
Some grepping shows:
List of dependencies for variable OVERRIDES is set(['OVERRIDE_INTERWORK', 'OVERRIDE_THUMB', 'DISTROOVERRIDES', 'TARGET_ARCH', 'BUILD_OS', 'PN', 'TARGET_OS', 'MACHINEOVERRIDES'])
List of dependencies for variable MACHINE is set([])
List of dependencies for variable MACHINEOVERRIDES is set(['MACHINE', 'SOC_FAMILY', 'FEED_ARCH'])
Variable OVERRIDES value is ${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}:libc-glibc:libc-glibc
Variable MACHINE value is omap4430-panda
Variable MACHINEOVERRIDES value is ${MACHINE}:${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}:${SOC_FAMILY}
So does MACHINEOVERRIDES need to get whitelisted as well?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox