On 07/27/11 10:23, Kumar Gala wrote:

I was wondering what distinction qualified for a BSP existing in a meta layer vs in poky directly.

For FSL PPC we currently have MPC8315-RDB in poky. Ideally we'd have one BSP for each major flavor [ associated with a unique compiler / libc target ]. This would end up being something like P2020-RDB (e500v2 core), P204x-RDB (e500mc core), P5020DS (e5500 core - 32/64 bit).

This sort of coverage would be great, and your options
would be the big ones on my hit list as well. It allows
us to at the least ensure that the build coverage is
complete.

Than everything else would live in the meta-fsl-ppc layer.

This makes sense as well.

There are some other options. The BSPs that you see embedded
in meta-yocto could all be split out into layers. It's largely
a matter of time, effort and benefit. There is the risk of
over segmentation and 'layerization', but we aren't there yet.

The point I'm trying to make here is that if a BSP aligns with
linux-yocto and is one that we are actively using as a reference,
it can be directly in meta-yocto or in another layer and it
will work equally well.

Cheers,

Bruce

- k
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

On 07/27/11 10:23, Richard Purdie wrote:

On Wed, 2011-07-27 at 08:55 -0500, Kumar Gala wrote:

Hi Kumar,

As you know, I've been working on several kernel efforts
around the FSL parts as well (in particular the ones that
have enough pieces upstream to work out of the box). I
definitely don't want to overlap in a way that doesn't
create complimentary efforts.

What are your current thoughts around kernels and the
(nearly religious) kernel version question ? It would be
great to get some alignment on features (-rt, tracing,
boot, footprint reduction, etc, etc) and save some effort
on maintenance and validation. Also if we want to create
some yocto reference BSPs, having a kernel version and feature
set match is important as well (i.e. what we've done for
the intel ones).

To that end, do you have an thoughts about using linux-yocto
as a base to any BSP work ? That statement doesn't do it
justice though, since when I say 'use linux-yocto as a base',
it really means that linux-yocto uses your BSPs as an
upstream/official reference and can pull support for them
into branches, and have the configuration and other tooling
get them any functionality that is being developed.

No control over BSP content, or anything like this, is being
suggested or asserted here. Just looking to all push in the
same direction (embedded features and BSPs to upstream) and
re-use the work of BSPs available in the community. If the
base is the same (and hence kernel version), then this relationship
and workflow is very simple.

... and as a bonus, if the workflow doesn't work easily, then
there's a problem with it and we can work on something that
is suitable (change tools, etc).

Thanks,

Bruce

What I'm envisioning as a start is we'd offer a meta layer on yocto
sites for the upstream supported boards& feature set.

I'm still looking at what we do for a FSL delivered BSP (via
freescale.com) that would be based on that. My initial concerns are
that the yocto community will probably move and change things too
frequently for our customer base (kernel version, toolchain version,
etc). Thus my thinking of de-coupling the two a bit. The yocto
versions of BSPs would track yocto development. The FSL delivered
BSPs would probably track to an older yocto version& slower update
cycle.

Just for reference, this is exactly what meta-intel intends to do. The
released versions of the code there are based on a specific release of
Yocto/OE-Core. When new BSPs are developed they are likely developed on
the last stable release of Yocto, not bleeding edge master unless there
is some pressing reason to do so.

Most definitely. Having some sort of alignment on the
kernel versions is nice, but we definitely don't expect
all BSPs to follow every new kernel.

And like Richard said, the model you are thinking about
makes a lot of sense.

If we nominate some important BSPs (one of my post 1.1 tasks),
and they get into the yocto-kernel tree, you have the
advantage that when I uprev the kernel they largely get hauled
along for the ride.

Cheers,

Brice

This is where we start to see major benefits of the layer model.

Cheers,

Richard

On Wed, 2011-07-27 at 08:55 -0500, Kumar Gala wrote:

Hi Kumar,

As you know, I've been working on several kernel efforts
around the FSL parts as well (in particular the ones that
have enough pieces upstream to work out of the box). I
definitely don't want to overlap in a way that doesn't
create complimentary efforts.

What are your current thoughts around kernels and the
(nearly religious) kernel version question ? It would be
great to get some alignment on features (-rt, tracing,
boot, footprint reduction, etc, etc) and save some effort
on maintenance and validation. Also if we want to create
some yocto reference BSPs, having a kernel version and feature
set match is important as well (i.e. what we've done for
the intel ones).

To that end, do you have an thoughts about using linux-yocto
as a base to any BSP work ? That statement doesn't do it
justice though, since when I say 'use linux-yocto as a base',
it really means that linux-yocto uses your BSPs as an
upstream/official reference and can pull support for them
into branches, and have the configuration and other tooling
get them any functionality that is being developed.

No control over BSP content, or anything like this, is being
suggested or asserted here. Just looking to all push in the
same direction (embedded features and BSPs to upstream) and
re-use the work of BSPs available in the community. If the
base is the same (and hence kernel version), then this relationship
and workflow is very simple.

... and as a bonus, if the workflow doesn't work easily, then
there's a problem with it and we can work on something that
is suitable (change tools, etc).

Thanks,

Bruce

What I'm envisioning as a start is we'd offer a meta layer on yocto
sites for the upstream supported boards & feature set.

I'm still looking at what we do for a FSL delivered BSP (via
freescale.com) that would be based on that. My initial concerns are
that the yocto community will probably move and change things too
frequently for our customer base (kernel version, toolchain version,
etc). Thus my thinking of de-coupling the two a bit. The yocto
versions of BSPs would track yocto development. The FSL delivered
BSPs would probably track to an older yocto version & slower update
cycle.

Just for reference, this is exactly what meta-intel intends to do. The
released versions of the code there are based on a specific release of
Yocto/OE-Core. When new BSPs are developed they are likely developed on
the last stable release of Yocto, not bleeding edge master unless there
is some pressing reason to do so.

This is where we start to see major benefits of the layer model.

Cheers,

Richard

I was wondering what distinction qualified for a BSP existing in a meta layer vs in poky directly.

For FSL PPC we currently have MPC8315-RDB in poky. Ideally we'd have one BSP for each major flavor [ associated with a unique compiler / libc target ]. This would end up being something like P2020-RDB (e500v2 core), P204x-RDB (e500mc core), P5020DS (e5500 core - 32/64 bit).

Than everything else would live in the meta-fsl-ppc layer.

- k

On Jul 27, 2011, at 9:06 AM, Tom Zanussi wrote:

On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote:

On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote:

Hi Kumar,

For meta-intel, it's pretty simple and is summarized by this blurb from
the meta-intel MAINTAINERS file:

"Please submit any patches against meta-intel BSPs to the Yocto mailing
list (yocto@...)."

Basically, new patches get submitted to the mailing list, go through the
standard on-list comment and review process, and then get pulled into
master by whoever maintains the BSP when everything looks good.

Hope that helps,

Tom

Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@...' list.

Hmm, I completely forgot about that list, and apparently everybody else
has too (no messages in it). It's also not linked to from anywhere on
the Yocto site that I can see e.g. Community | Mailing Lists.

Personally I'd prefer less fragmentation of lists, and think it would
get better review and exposure on the yocto list, but if it makes more
sense to people to start using the yocto-bsp list, fine with me...

Tom

- k

I'm good w/just using the main yocto list for now until traffic gets to a point we think it makes sense to split it off

- k

On Wed, 2011-07-27 at 06:53 -0700, Kumar Gala wrote:

On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote:

Hi Kumar,

For meta-intel, it's pretty simple and is summarized by this blurb from
the meta-intel MAINTAINERS file:

"Please submit any patches against meta-intel BSPs to the Yocto mailing
list (yocto@...)."

Basically, new patches get submitted to the mailing list, go through the
standard on-list comment and review process, and then get pulled into
master by whoever maintains the BSP when everything looks good.

Hope that helps,

Tom

Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@...' list.

Hmm, I completely forgot about that list, and apparently everybody else
has too (no messages in it). It's also not linked to from anywhere on
the Yocto site that I can see e.g. Community | Mailing Lists.

Personally I'd prefer less fragmentation of lists, and think it would
get better review and exposure on the yocto list, but if it makes more
sense to people to start using the yocto-bsp list, fine with me...

Tom

- k

Hi Kumar,

As you know, I've been working on several kernel efforts
around the FSL parts as well (in particular the ones that
have enough pieces upstream to work out of the box). I
definitely don't want to overlap in a way that doesn't
create complimentary efforts.

What are your current thoughts around kernels and the
(nearly religious) kernel version question ? It would be
great to get some alignment on features (-rt, tracing,
boot, footprint reduction, etc, etc) and save some effort
on maintenance and validation. Also if we want to create
some yocto reference BSPs, having a kernel version and feature
set match is important as well (i.e. what we've done for
the intel ones).

To that end, do you have an thoughts about using linux-yocto
as a base to any BSP work ? That statement doesn't do it
justice though, since when I say 'use linux-yocto as a base',
it really means that linux-yocto uses your BSPs as an
upstream/official reference and can pull support for them
into branches, and have the configuration and other tooling
get them any functionality that is being developed.

No control over BSP content, or anything like this, is being
suggested or asserted here. Just looking to all push in the
same direction (embedded features and BSPs to upstream) and
re-use the work of BSPs available in the community. If the
base is the same (and hence kernel version), then this relationship
and workflow is very simple.

... and as a bonus, if the workflow doesn't work easily, then
there's a problem with it and we can work on something that
is suitable (change tools, etc).

Thanks,

Bruce

What I'm envisioning as a start is we'd offer a meta layer on yocto sites for the upstream supported boards & feature set.

I'm still looking at what we do for a FSL delivered BSP (via freescale.com) that would be based on that. My initial concerns are that the yocto community will probably move and change things too frequently for our customer base (kernel version, toolchain version, etc). Thus my thinking of de-coupling the two a bit. The yocto versions of BSPs would track yocto development. The FSL delivered BSPs would probably track to an older yocto version & slower update cycle.

- k

On Jul 27, 2011, at 8:50 AM, Tom Zanussi wrote:

Hi Kumar,

For meta-intel, it's pretty simple and is summarized by this blurb from
the meta-intel MAINTAINERS file:

"Please submit any patches against meta-intel BSPs to the Yocto mailing
list (yocto@...)."

Basically, new patches get submitted to the mailing list, go through the
standard on-list comment and review process, and then get pulled into
master by whoever maintains the BSP when everything looks good.

Hope that helps,

Tom

Ok, same model would work for meta-fsl-ppc. The one question I have is if it make sense to migrate such patches over to 'yocto-bsp@...' list.

- k

On Wed, 2011-07-27 at 09:30 -0400, Bruce Ashfield wrote:

As you know, I've been working on several kernel efforts
around the FSL parts as well (in particular the ones that
have enough pieces upstream to work out of the box). I
definitely don't want to overlap in a way that doesn't
create complimentary efforts.

What are your current thoughts around kernels and the
(nearly religious) kernel version question ? It would be
great to get some alignment on features (-rt, tracing,
boot, footprint reduction, etc, etc) and save some effort
on maintenance and validation. Also if we want to create
some yocto reference BSPs, having a kernel version and feature
set match is important as well (i.e. what we've done for
the intel ones).

To that end, do you have an thoughts about using linux-yocto
as a base to any BSP work ? That statement doesn't do it
justice though, since when I say 'use linux-yocto as a base',
it really means that linux-yocto uses your BSPs as an
upstream/official reference and can pull support for them
into branches, and have the configuration and other tooling
get them any functionality that is being developed.

No control over BSP content, or anything like this, is being
suggested or asserted here. Just looking to all push in the
same direction (embedded features and BSPs to upstream) and
re-use the work of BSPs available in the community. If the
base is the same (and hence kernel version), then this relationship
and workflow is very simple.

... and as a bonus, if the workflow doesn't work easily, then
there's a problem with it and we can work on something that
is suitable (change tools, etc).

So just to put what Bruce says into other words, there isn't any hard
requirement to use linux-yocto but we are asking people to try it and if
it doesn't work, at least tell us why.

I understand transitions and new ways of working take time and that
meta-fsl-ppc might be enough of a step at first without the linux-yocto
complications. That is fine but please do keep it in mind.

Cheers,

Richard

On Wed, 2011-07-27 at 05:40 -0700, Kumar Gala wrote:

On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote:

On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:

Who is the best person to ask about adding new BSPs into yocto. What
I mean by this is having a meta layer hosted on git.yoctoproject.org
like meta-intel and the mechanics associated with this (getting new
repo on git server, autobuilder support, webpage details, etc.).

This list is as good a place as any! :)

Its relatively easy to arrange for a git repository. The main things we
ask are that it has clearly defined maintainership (a clear maintainer
and submission process) and a clear scope. Do you have any specific BSPs
in mind?

Maintainership would be straight forward. Not sure about submissions process, what is done for meta-intel today?

Hi Kumar,

For meta-intel, it's pretty simple and is summarized by this blurb from
the meta-intel MAINTAINERS file:

"Please submit any patches against meta-intel BSPs to the Yocto mailing
list (yocto@...)."

Basically, new patches get submitted to the mailing list, go through the
standard on-list comment and review process, and then get pulled into
master by whoever maintains the BSP when everything looks good.

Hope that helps,

Tom

BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them.

The wiki is available to host information and we can work out links on
the website as the specific needs come up. Autobuilder support is
something we need to figure out since its a finite resource but we can
likely figure something out there once we understand what kind of BSPs
we're talking about.

Beth Flanagan <elizabeth.flanagan@...> is the person who'd handle
the mechanics of setting up the repository, the name is likely the
hardest bit!

meta-fsl-ppc ;)

- k

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

On 07/27/11 08:40, Kumar Gala wrote:

On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote:

On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:

Who is the best person to ask about adding new BSPs into yocto. What
I mean by this is having a meta layer hosted on git.yoctoproject.org
like meta-intel and the mechanics associated with this (getting new
repo on git server, autobuilder support, webpage details, etc.).

This list is as good a place as any! :)

Its relatively easy to arrange for a git repository. The main things we
ask are that it has clearly defined maintainership (a clear maintainer
and submission process) and a clear scope. Do you have any specific BSPs
in mind?

Maintainership would be straight forward. Not sure about submissions process, what is done for meta-intel today?

BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them.

Hi Kumar,

As you know, I've been working on several kernel efforts
around the FSL parts as well (in particular the ones that
have enough pieces upstream to work out of the box). I
definitely don't want to overlap in a way that doesn't
create complimentary efforts.

What are your current thoughts around kernels and the
(nearly religious) kernel version question ? It would be
great to get some alignment on features (-rt, tracing,
boot, footprint reduction, etc, etc) and save some effort
on maintenance and validation. Also if we want to create
some yocto reference BSPs, having a kernel version and feature
set match is important as well (i.e. what we've done for
the intel ones).

To that end, do you have an thoughts about using linux-yocto
as a base to any BSP work ? That statement doesn't do it
justice though, since when I say 'use linux-yocto as a base',
it really means that linux-yocto uses your BSPs as an
upstream/official reference and can pull support for them
into branches, and have the configuration and other tooling
get them any functionality that is being developed.

No control over BSP content, or anything like this, is being
suggested or asserted here. Just looking to all push in the
same direction (embedded features and BSPs to upstream) and
re-use the work of BSPs available in the community. If the
base is the same (and hence kernel version), then this relationship
and workflow is very simple.

... and as a bonus, if the workflow doesn't work easily, then
there's a problem with it and we can work on something that
is suitable (change tools, etc).

Thanks,

Bruce

The wiki is available to host information and we can work out links on
the website as the specific needs come up. Autobuilder support is
something we need to figure out since its a finite resource but we can
likely figure something out there once we understand what kind of BSPs
we're talking about.

Beth Flanagan<elizabeth.flanagan@...> is the person who'd handle
the mechanics of setting up the repository, the name is likely the
hardest bit!

meta-fsl-ppc ;)

- k

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

On Jul 27, 2011, at 3:45 AM, Richard Purdie wrote:

On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:

Who is the best person to ask about adding new BSPs into yocto. What
I mean by this is having a meta layer hosted on git.yoctoproject.org
like meta-intel and the mechanics associated with this (getting new
repo on git server, autobuilder support, webpage details, etc.).

This list is as good a place as any! :)

Its relatively easy to arrange for a git repository. The main things we
ask are that it has clearly defined maintainership (a clear maintainer
and submission process) and a clear scope. Do you have any specific BSPs
in mind?

Maintainership would be straight forward. Not sure about submissions process, what is done for meta-intel today?

BSP would be for Freescale PowerPC SoC and the reference designs produced by FSL for them.

The wiki is available to host information and we can work out links on
the website as the specific needs come up. Autobuilder support is
something we need to figure out since its a finite resource but we can
likely figure something out there once we understand what kind of BSPs
we're talking about.

Beth Flanagan <elizabeth.flanagan@...> is the person who'd handle
the mechanics of setting up the repository, the name is likely the
hardest bit!

meta-fsl-ppc ;)

- k

On Wed, 2011-07-27 at 00:21 -0500, Kumar Gala wrote:

Who is the best person to ask about adding new BSPs into yocto. What
I mean by this is having a meta layer hosted on git.yoctoproject.org
like meta-intel and the mechanics associated with this (getting new
repo on git server, autobuilder support, webpage details, etc.).

This list is as good a place as any! :)

Its relatively easy to arrange for a git repository. The main things we
ask are that it has clearly defined maintainership (a clear maintainer
and submission process) and a clear scope. Do you have any specific BSPs
in mind?

The wiki is available to host information and we can work out links on
the website as the specific needs come up. Autobuilder support is
something we need to figure out since its a finite resource but we can
likely figure something out there once we understand what kind of BSPs
we're talking about.

Beth Flanagan <elizabeth.flanagan@...> is the person who'd handle
the mechanics of setting up the repository, the name is likely the
hardest bit!

Cheers,

Richard

Who is the best person to ask about adding new BSPs into yocto. What I mean by this is having a meta layer hosted on git.yoctoproject.org like meta-intel and the mechanics associated with this (getting new repo on git server, autobuilder support, webpage details, etc.).

- k

A previous patch changed the default TERM to use xterm. This updates
local.conf.sample to match the change

Signed-off-by: Matthew McClintock <msm@...>
---
meta-yocto/conf/local.conf.sample | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample
index 499c48e..7a0fc89 100644
--- a/meta-yocto/conf/local.conf.sample
+++ b/meta-yocto/conf/local.conf.sample
@@ -205,7 +205,7 @@ ENABLE_BINARY_LOCALE_GENERATION = "1"
# out if that is desired
NO32LIBS = "1"

-# If you do not use (or have installed) gnome-terminal you will need to
+# If you do not use (or have installed) xterm you will need to
# uncomment these variables and set them to the terminal you wish to use
# when resolving patches which cannot be applied
# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN ARE:
--
1.7.5

Several builds are using perl on the host instead of perl built by
poky. This fixes the issue for several packages.

Signed-off-by: Matthew McClintock <msm@...>
---
meta/recipes-connectivity/avahi/avahi.inc | 2 +-
meta/recipes-connectivity/avahi/avahi_0.6.30.bb | 2 +-
meta/recipes-devtools/intltool/intltool.inc | 2 +-
meta/recipes-extended/polkit/polkit_0.101.bb | 4 ++--
meta/recipes-gnome/gnome/gconf-dbus_705.bb | 4 ++--
meta/recipes-gnome/gnome/gnome-desktop.inc | 4 ++--
meta/recipes-gnome/gnome/gnome-doc-utils.inc | 2 +-
meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb | 2 +-
.../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb | 4 ++--
meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb | 4 ++--
.../recipes-gnome/gnome/libgnome-keyring_2.32.0.bb | 4 ++--
.../xorg-lib/xkeyboard-config_2.1.bb | 4 ++--
.../shared-mime-info/shared-mime-info.inc | 2 +-
.../shared-mime-info/shared-mime-info_0.90.bb | 2 +-
14 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
index dc7a5ae..5695403 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -21,7 +21,7 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
file://99avahi-autoipd \
file://initscript.patch"

-inherit autotools pkgconfig update-rc.d gettext
+inherit autotools pkgconfig update-rc.d gettext perlnative

EXTRA_OECONF = "--with-distro=debian \
--with-avahi-priv-access-group=adm \
diff --git a/meta/recipes-connectivity/avahi/avahi_0.6.30.bb b/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
index 05716d0..da40426 100644
--- a/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
+++ b/meta/recipes-connectivity/avahi/avahi_0.6.30.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"

-PR = "r4"
+PR = "r5"

SRC_URI[md5sum] = "e4db89a2a403ff4c47d66ac66fad1f43"
SRC_URI[sha256sum] = "f9e4316c2339d0020726edd846d01bee0c39980906db0c247479e5807457ff1f"
diff --git a/meta/recipes-devtools/intltool/intltool.inc b/meta/recipes-devtools/intltool/intltool.inc
index d8917ad..7885b01 100644
--- a/meta/recipes-devtools/intltool/intltool.inc
+++ b/meta/recipes-devtools/intltool/intltool.inc
@@ -12,5 +12,5 @@ RRECOMMENDS_${PN} = "perl-modules"

inherit autotools pkgconfig perlnative

-export PERL = "/usr/bin/env perl"
+export INTLTOOL_PERL_virtclass-native = "/usr/bin/env perl"
BBCLASSEXTEND = "native"
diff --git a/meta/recipes-extended/polkit/polkit_0.101.bb b/meta/recipes-extended/polkit/polkit_0.101.bb
index 6769914..2dd8f58 100644
--- a/meta/recipes-extended/polkit/polkit_0.101.bb
+++ b/meta/recipes-extended/polkit/polkit_0.101.bb
@@ -8,12 +8,12 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=155db86cdbafa7532b41f390409283eb \

SRC_URI = "http://hal.freedesktop.org/releases/polkit-${PV}.tar.gz \
file://introspection.patch"
-PR = "r0"
+PR = "r1"
DEPENDS = "libpam expat dbus-glib eggdbus intltool"
RDEPENDS_${PN} = "libpam"
EXTRA_OECONF = "--with-authfw=pam --with-os-type=moblin --disable-man-pages --disable-gtk-doc --disable-introspection"

-inherit autotools pkgconfig
+inherit autotools pkgconfig perlnative

FILES_${PN} += "${libdir}/${PN}-1/extensions/*.so \
${datadir}/${PN}-1/actions/* \
diff --git a/meta/recipes-gnome/gnome/gconf-dbus_705.bb b/meta/recipes-gnome/gnome/gconf-dbus_705.bb
index fdfc45f..cbfc42d 100644
--- a/meta/recipes-gnome/gnome/gconf-dbus_705.bb
+++ b/meta/recipes-gnome/gnome/gconf-dbus_705.bb
@@ -10,7 +10,7 @@ RPROVIDES_${PN}-dev = "gconf-dev"

#SRCREV = "705"
#PV = "2.16.0+svnr${SRCPV}"
-PR = "r0"
+PR = "r1"

# This SVN repo is no longer available use a tarball mirror site until
# we move to proper gconf recipe.
@@ -19,7 +19,7 @@ SRC_URI = "http://autobuilder.pokylinux.org/sources/trunk_developer.imendio.com_

S = "${WORKDIR}/trunk"

-inherit pkgconfig autotools
+inherit pkgconfig autotools perlnative

PARALLEL_MAKE = ""

diff --git a/meta/recipes-gnome/gnome/gnome-desktop.inc b/meta/recipes-gnome/gnome/gnome-desktop.inc
index 336b87f..670d56b 100644
--- a/meta/recipes-gnome/gnome/gnome-desktop.inc
+++ b/meta/recipes-gnome/gnome/gnome-desktop.inc
@@ -11,7 +11,7 @@ do_configure_prepend () {

FILES_${PN} += "${datadir}/gnome-about"

-PR = "r1"
+PR = "r2"

-inherit gnome pkgconfig
+inherit gnome pkgconfig perlnative

diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils.inc b/meta/recipes-gnome/gnome/gnome-doc-utils.inc
index bd7c615..525c1b4 100644
--- a/meta/recipes-gnome/gnome/gnome-doc-utils.inc
+++ b/meta/recipes-gnome/gnome/gnome-doc-utils.inc
@@ -2,7 +2,7 @@ LICENSE = "GPL & LGPL"
DEPENDS = "libxml2 libxslt libxslt-native gnome-doc-utils-native"
DEPENDS_virtclass-native = "libxml2-native libxslt-native intltool-native"

-inherit gnome gettext python-dir
+inherit gnome gettext python-dir perlnative

EXTRA_OECONF = "--disable-scrollkeeper"

diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb b/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb
index 1ec1076..c65cf64 100644
--- a/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb
+++ b/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb
@@ -1,7 +1,7 @@
require gnome-doc-utils.inc
LIC_FILES_CHKSUM = "file://COPYING.GPL;md5=eb723b61539feef013de476e68b5c50a \
file://COPYING.LGPL;md5=a6f89e2100d9b6cdffcea4f398e37343"
-PR = "r4"
+PR = "r5"

SRC_URI += "file://xsltproc_nonet.patch \
file://use-usr-bin-env-for-python-in-xml2po.patch"
diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
index 55868ab..e7f17f5 100644
--- a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
+++ b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
@@ -9,7 +9,7 @@ SECTION = "x11/gnome"
DEPENDS = "icon-naming-utils-native glib-2.0 intltool-native"
RDEPENDS_${PN} = "hicolor-icon-theme"
RRECOMMENDS_${PN} = "librsvg-gtk"
-PR = "r1"
+PR = "r2"

FILES_${PN} += "${datadir}/*"

@@ -21,7 +21,7 @@ SRC_URI[sha256sum] = "ea7e05b77ead159379392b3b275ca0c9cbacd7d936014e447cc7c5e27a

EXTRA_OECONF = "--disable-hicolor-check --with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-mapping"

-inherit autotools
+inherit autotools perlnative

# We can't do this until the output is shared into all target sysroots
#PACKAGE_ARCH = "all"
diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
index 3f38401..7ae49c4 100644
--- a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
+++ b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
@@ -11,9 +11,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \

SECTION = "x11/gnome"

-PR = "r2"
+PR = "r3"

-inherit autotools gnome pkgconfig
+inherit autotools gnome pkgconfig perlnative

DEPENDS = "gtk+ libgcrypt libtasn1 libtasn1-native gconf"
RDEPENDS_${PN} = "libgnome-keyring"
diff --git a/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb b/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb
index 09b6d9c..77c82d3 100644
--- a/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb
+++ b/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb
@@ -9,9 +9,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0914b9d3ebaba41ef2e3e0ae16f296cf \
file://egg/egg-dh.h;endline=22;md5=1626c16af2a8da1f88324cf3ced33f08"

SECTION = "x11/gnome/libs"
-PR = "r0"
+PR = "r1"

-inherit gnome
+inherit gnome perlnative

DEPENDS = "dbus eggdbus"

diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.1.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.1.bb
index b077fa3..e4c7dc0 100644
--- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.1.bb
+++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.1.bb
@@ -19,14 +19,14 @@ SRC_URI[sha256sum] = "e293aa4b0dd259dbb4f0e7f56fdd95db5047d052c7b3b80922fe566392
SECTION = "x11/libs"
DEPENDS = "intltool-native xkbcomp-native glib-2.0"

-PR = "r1"
+PR = "r2"

EXTRA_OECONF = "--with-xkb-rules-symlink=xorg"

RDEPENDS_${PN} += "xkbcomp"
FILES_${PN} += "${datadir}/X11/xkb"

-inherit autotools pkgconfig
+inherit autotools pkgconfig perlnative

do_install_append () {
install -d ${D}/usr/share/X11/xkb/compiled
diff --git a/meta/recipes-support/shared-mime-info/shared-mime-info.inc b/meta/recipes-support/shared-mime-info/shared-mime-info.inc
index 64eef9d..8b10535 100644
--- a/meta/recipes-support/shared-mime-info/shared-mime-info.inc
+++ b/meta/recipes-support/shared-mime-info/shared-mime-info.inc
@@ -10,7 +10,7 @@ DEPENDS_virtclass-native = "libxml2-native intltool-native glib-2.0-native"

SRC_URI = "http://freedesktop.org/~hadess/shared-mime-info-${PV}.tar.bz2"

-inherit autotools pkgconfig gettext
+inherit autotools pkgconfig gettext perlnative

EXTRA_OECONF = "--disable-update-mimedb"

diff --git a/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb b/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb
index cbbd0fe..4c852fa 100644
--- a/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb
+++ b/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb
@@ -1,5 +1,5 @@
require shared-mime-info.inc
-PR = "r0"
+PR = "r1"

SRC_URI += "file://fix-parallel-build.patch \
file://fix-parallel-build-backport.patch \
--
1.7.5

On 2011-07-26 11:00, Jeff Mitchell wrote:

On 07/26/2011 12:47 PM, Gary Thomas wrote:

On 2011-07-15 09:30, Jeff Mitchell wrote:

Darren Hart suggested I send this to the list...

Attached is a picture of my screen running Terminal. This is on a BeagleBoard xM rev C connected via its HDMI out to a DVI adapter and then into a Dell UltraSharp monitor. Angstrom
doesn't display these problems, so the setup should be fine.

I'm not quite sure what is causing this. The resolution is also fairly low, and I haven't had any success using boot parameters (either the older video=omapfb:mode variant or the
newer DSS2 omapfb.mode variant).

Did you ever find out what is causing this?

No, but I'll be testing out a new build soon -- haven't been able to for a bit.

When you say that it works on one system (Poky?) vs another (Angstrom?)
are they both running the same version of U-Boot? I'm seeing this same
behaviour on one of my boards, but only when I run U-Boot from 2011.06

Yes -- Yocto/Poky/Sato vs. Angstrom. I doubt they're running the same version of U-Boot, but I don't know the version numbers offhand.

Check the display setup. In my case, my old U-Boot (which works great)
was using dvimode=1024x768-24@60 and the new U-Boot is using dvimode=1024x768MR-16@60
When I switch back to the old setting, even with the new U-Boot, my display
runs great again. n.b. this may be kernel revision sensitive as well.

BTW - why did you send your original query to the Poky list?

Because Darren suggested that I do so, to get various eyes on it :-)

Sounds reasonable - I only asked because your original email didn't
really spell out why it went to the Poky list.

Thanks & good luck

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

On 07/26/2011 12:47 PM, Gary Thomas wrote:

On 2011-07-15 09:30, Jeff Mitchell wrote:

Darren Hart suggested I send this to the list...

Attached is a picture of my screen running Terminal. This is on a BeagleBoard xM rev C connected via its HDMI out to a DVI adapter and then into a Dell UltraSharp monitor. Angstrom
doesn't display these problems, so the setup should be fine.

I'm not quite sure what is causing this. The resolution is also fairly low, and I haven't had any success using boot parameters (either the older video=omapfb:mode variant or the
newer DSS2 omapfb.mode variant).

Did you ever find out what is causing this?

No, but I'll be testing out a new build soon -- haven't been able to for a bit.

When you say that it works on one system (Poky?) vs another (Angstrom?)
are they both running the same version of U-Boot? I'm seeing this same
behaviour on one of my boards, but only when I run U-Boot from 2011.06

Yes -- Yocto/Poky/Sato vs. Angstrom. I doubt they're running the same version of U-Boot, but I don't know the version numbers offhand.

BTW - why did you send your original query to the Poky list?

Because Darren suggested that I do so, to get various eyes on it :-)

Thanks,
jeff

On 2011-07-15 09:30, Jeff Mitchell wrote:

Darren Hart suggested I send this to the list...

Attached is a picture of my screen running Terminal. This is on a BeagleBoard xM rev C connected via its HDMI out to a DVI adapter and then into a Dell UltraSharp monitor. Angstrom
doesn't display these problems, so the setup should be fine.

I'm not quite sure what is causing this. The resolution is also fairly low, and I haven't had any success using boot parameters (either the older video=omapfb:mode variant or the
newer DSS2 omapfb.mode variant).

Did you ever find out what is causing this?

When you say that it works on one system (Poky?) vs another (Angstrom?)
are they both running the same version of U-Boot? I'm seeing this same
behaviour on one of my boards, but only when I run U-Boot from 2011.06

BTW - why did you send your original query to the Poky list?

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------