Re: [OE-core] [PATCH] cronie 1.4.7: fix packaging

[Richard Purdie]

On Thu, 2011-04-21 at 11:24 +0200, Koen Kooi wrote:
> Syslog is full with entries like:
> 
> /usr/sbin/crond[773]: (CRON) STAT FAILED (/etc/cron.d): No such file or 
> directory
> 
> Checking the package yields
> 
> Package cronie (1.4.6-r0) is installed on root and has the following files:
> /usr/sbin/crond
> /etc/init.d/crond
> /usr/bin/crontab
> /etc/sysconfig/crond
> 
> Which is missing most of what do_install_append installs, this commit fixes 
> that
> 
> Signed-off-by: Koen Kooi 

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC] meta-handheld

[Richard Purdie]

On Thu, 2011-04-21 at 19:27 +0200, Koen Kooi wrote:
> Op 21 apr 2011, om 18:57 heeft Graeme Gregory het volgende geschreven:
> 
> > On Thu, Apr 21, 2011 at 05:04:37PM +0100, Paul Eggleton wrote:
> >> Hi all,
> >> 
> >> I've discussed the possibility with a few people on IRC of creating a meta-
> >> handheld layer for support of older handheld devices - this would include 
> >> Zaurus, iPAQ, SimPad, etc; possibly even EZX phones if they aren't in a 
> >> layer 
> >> of their own. These machines share a fair amount of commonality and I 
> >> don't 
> >> think that they will all survive if each one has to be put into a BSP of 
> >> its 
> >> own. Response so far seems to be positive but I'd like to hear thoughts 
> >> from 
> >> others on this.
> >> 
> >> I have access to many of these devices, and this is something I am 
> >> prepared to 
> >> maintain on my own time, although I would appreciate help from others. I 
> >> have 
> >> the basis of a layer from what was left in oe-core and meta-extras but 
> >> quite a 
> >> lot of it would need to be brought over from OE.
> >> 
> >> If people agree that this is a good idea, the next question would be where 
> >> to 
> >> host it - is this something that could be within the meta-oe repository?
> >> 
> > Grabbing all of these barely supported machines into their own layer sounds
> > like a good plan to me.
> > 
> > Id suggest just hosting it on gitorious, if its inside OE then there is the
> > magic assumption from the public that they should work (which is what 
> > happens
> > now). Then people get really dissapointed when I tell them getting it to 
> > work
> > is likely to be a hard slog.
> 
> I agree with Graeme on the hosting bit. I also have all the devices you 
> mentioned near my desk, so testing should be easy :)

I'm going to disagree, this is exactly the kind of layer fragmentation
I'd not like to see layers cause. Which website do I go to where I can
see a list of layers that exist? Who is going to maintain that list? If
its off on gitorious nobody will be able to easily find it.

The easiest solution is if git.openembedded.org or git.yoctoproject.org
can host the majority of the meta-* repositories.

Equally, I don't really see why this can't be a specific meta- group in
meta-oe. The README can clearly spell out what the expectations of the
layer are...

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC] Working toward a GNOME layer

[Richard Purdie]

On Thu, 2011-04-21 at 09:40 -0700, Joshua Lock wrote:
> On Thu, 2011-04-21 at 16:05 +0100, Paul Eggleton wrote:
> > On Thursday 21 April 2011 15:02:49 Koen Kooi wrote:
> > > and possibly more. I would like to create a meta-gnome layer in the
> > > meta-openembedded repository where new recipes get added and things from
> > > meta-demoapps can get moved over into. Long term recipes-gnome in oe-core
> > > should move there as well.
> > > 
> > > What are your thoughts on this?
> 
> +1
> 
> > 
> > From my perspective this sounds like a great idea. The only question would 
> > be 
> > how much of the "GNOME" libs would remain in oe-core as some of them are 
> > quite 
> > widely used outside of GNOME proper; however that can easily be worked out 
> > as 
> > these things mature.
> 
> +1
> 
> My personal opinion would be that we start with glib & gtk+ (plus their
> dependencies, i.e. pango, atk, etc) in core and move the rest out to a
> layer.

Do we move out sato as well?

> I feel that Gtk+ is used by enough non-gnome software that it belongs in
> core but others may disagree?

I think it needs to be in the core as we need something there to test
X/graphics and so forth. This implies we need sato and its dependencies
there too though (which are thankfully minimal by design).

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] pcmciautils: Upgrade 017 -> 018

[Richard Purdie]

On Thu, 2011-04-21 at 11:59 -0700, Khem Raj wrote:
> version workaround is done in recipe itself
> by adding PV to CFLAGS
> 
> Since we define LIBC and pcmciutils use it too
> which hinders build when we define LIBC in
> environment. Its not used in the builds anyway
> so we get rid of depending on it

Why are you defining LIBC in the environment? That sounds like a
seriously bad idea. Our current environment handling should stop it
leaking into a build anyway shouldn't it?

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 37/37] create-lsb-image:Rename creat-lsb-image and fix some bugs

[Richard Purdie]

On Fri, 2011-04-22 at 23:29 -0700, Saul Wold wrote:
> From: Xiaofeng Yan 
> 
> Rename creat-lsb-image to create-lsb-image
> Fix some fuctions for more practical

Please in future make renames separate to commits so people can more
easily see what changed.

Cheers,

Richard


>  scripts/creat-lsb-image  |  198 
>  scripts/create-lsb-image |  228 
> ++
>  2 files changed, 228 insertions(+), 198 deletions(-)
>  delete mode 100755 scripts/creat-lsb-image
>  create mode 100755 scripts/create-lsb-image
> 
> diff --git a/scripts/creat-lsb-image b/scripts/creat-lsb-image
> deleted file mode 100755
> index 657784c..000
> --- a/scripts/creat-lsb-image
> +++ /dev/null
> @@ -1,198 +0,0 @@
> -#!/bin/bash
> -#
> -# Copyright (c) 2005-2010 Wind River Systems, Inc.
> -#
> -# This program is free software; you can redistribute it and/or modify
> -# it under the terms of the GNU General Public License version 2 as
> -# published by the Free Software Foundation.
> -#
> -# This program is distributed in the hope that it will be useful,
> -# but WITHOUT ANY WARRANTY; without even the implied warranty of
> -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> -# See the GNU General Public License for more details.
> -#
> -# You should have received a copy of the GNU General Public License
> -# along with this program; if not, write to the Free Software
> -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> -
> -
> -red='\E[31;40m'
> -green='\E[32;40m'
> -USER=`whoami`
> -ARCH=$1
> -MACHINE_ARCH=` bitbake -e | grep ^MACHINE_ARCH | cut -d '=' -f2 | cut -d '"' 
> -f2`
> -IMAGE_PATH=` bitbake -e | grep ^COREBASE | cut -d '=' -f2 | cut -d '"' 
> -f2`/build/tmp/deploy/images/
> -
> -
> -ECHO()
> -{
> -echo -e "${green}$@"
> -tput sgr0
> -}
> -
> -exit_check()
> -{
> -if [ ! $? -eq 0 ]; then
> -exit $?
> -fi
> -}
> -
> -usage()
> -{
> -ECHO "${red}usage:you should input one of the next commmands according 
> to detailed target platform:"
> -ECHO "creat-lsb-image x86"
> -ECHO "creat-lsb-image x86_64"
> -ECHO "creat-lsb-image ppc32"
> -}
> -
> -#There should be a patameter to get machine type
> -if [ $# -ne 1 ]; then
> -usage
> -exit 1
> -fi
> -
> -#check lsb image
> -if [ ! -d $IMAGE_PATH ];then
> -ECHO "${red}There isn't image directory"
> -exit 1
> -fi
> -ECHO "Enter directory $IMAGE_PATH"
> -cd $IMAGE_PATH
> -
> -#get architecture
> -PN=`find . -name core-image-lsb-${MACHINE_ARCH}\*.rootfs.tar.bz2 -type f | 
> awk -F- 'BEGIN{ max=0;} {if( NR!=0 && $5>max ) max=$5 }END{ printf "%d" ,max 
> ;}'`
> -if [ "XPN" == "X" ];then
> -   ECHO "${red}Don't find lsb image on platform, Please run 
> \"core-image-lsb\" to generate lsb image"
> -   exit 1
> -fi
> -
> -if [ $PN -eq 0 ];then
> - ECHO "${red}Can't ${MACHINE_ARCH} rootfs.tar.gz,Please run 
> core-image-lsb to get lsb image"
> - exit 1
> -fi
> -#set varible ARCH
> -if [ ${ARCH} == x86 ];then
> - T_ARCH=ia32
> -P_ARCH=i486
> -elif [ ${ARCH} == x86_64 ];then
> - T_ARCH=ia64
> -P_ARCH=ia64
> -else
> - P_ARCH=ppc
> - T_ARCH=${ARCH}
> -fi
> -
> -#umount lsbtmp 
> -if [ -d lsbtmp ];then
> - sudo umount lsbtmp
> -fi
> - 
> -#download lsb test suite
> -mkdir -p lsb-test-suite-${MACHINE_ARCH} 
> -if [ -d lsb-test-suite-${MACHINE_ARCH} ];then
> - cd lsb-test-suite-${MACHINE_ARCH}
> - ECHO "Download lsb test suite, it could take some time..."
> -wget -c -t 5  
> http://ftp.linuxfoundation.org/pub/lsb/bundles/released-4.1.0/dist-testkit/lsb-dist-testkit-4.1.0-5.${T_ARCH}.tar.gz
> -exit_check
> - ECHO "Download lsb-xdg-utils-4.0.0-2.${P_ARCH}.rpm"
> - wget -c -t 5 
> http://ftp.linux-foundation.org/pub/lsb/lsbdev/released-4.1.0/binary/${T_ARCH}/lsb-xdg-utils-4.0.0-2.${P_ARCH}.rpm
> -exit_check
> - ECHO "Downlocad lsb-apache-2.2.8-2.lsb4.${P_ARCH}.rpm"
> - wget -c -t 5 
> http://ftp.linux-foundation.org/pub/lsb/app-battery/released-4.1.0/${T_ARCH}/lsb-apache-2.2.14-3.lsb4.${P_ARCH}.rpm
> -exit_check
> - ECHO "Downlocad lsb-tcl-8.5.1-2.lsb4.${P_ARCH}.rpm"
> - wget -c -t 5 
> http://ftp.linux-foundation.org/pub/lsb/app-battery/released-4.1.0/${T_ARCH}/lsb-tcl-8.5.7-6.lsb4.${P_ARCH}.rpm
> -exit_check
> - ECHO "Downlocad lsb-expect-5.43.0-7.lsb4.${P_ARCH}.rpm"
> - wget -c -t 5 
> http://ftp.linux-foundation.org/pub/lsb/app-battery/released-4.1.0/${T_ARCH}/lsb-expect-5.43.0-11.lsb4.${P_ARCH}.rpm
>  
> -exit_check
> - ECHO "Downlocad lsb-groff-1.19.2-4.lsb4.${P_ARCH}.rpm"
> - wget -c -t 5 
> http://ftp.linux-foundation.org/pub/lsb/app-battery/released-4.1.0/${T_ARCH}/lsb-groff-1.20.1-5.lsb4.${P_ARCH}.rpm
>   
> -exit_check
> - ECHO "Downlocad lsb-raptor-1.4.16-2.lsb4.${P_ARCH}.rpm"
> - wget -c -t 5 
> http://ftp.linux-foundation.org/pub/lsb/app-battery/released-4.1.0/${T_ARCH}/lsb-raptor-1.4.19-3.lsb4.${P_ARCH}.rpm
>  

Re: [OE-core] [PATCH 35/37] task-base: allow distribution to define apm provider

[Richard Purdie]

On Fri, 2011-04-22 at 23:29 -0700, Saul Wold wrote:
> From: Martin Jansa 
> 
> Signed-off-by: Martin Jansa 
> ---
>  meta/recipes-core/tasks/task-base.bb |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/recipes-core/tasks/task-base.bb 
> b/meta/recipes-core/tasks/task-base.bb
> index 599fa4b..af49153 100644
> --- a/meta/recipes-core/tasks/task-base.bb
> +++ b/meta/recipes-core/tasks/task-base.bb
> @@ -179,8 +179,11 @@ RDEPENDS_task-base-acpi = "\
>  acpid \
>  libacpi "
>  
> +# Distro can override apm provider
> +DISTRO_APM ?= "apm"
> +
>  RDEPENDS_task-base-apm = "\
> -apm \
> +${DISTRO_APM} \
>  apmd"

I think I replied about this one previously and Martin suggested we use
a different VIRTUAL* name for the variable. I'd appreciate doing that as
DISTRO* is an overloaded namespace. Can someone repsin the patch
please? :)

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/37] V2 - Consolidated Pull Request

[Richard Purdie]

On Fri, 2011-04-22 at 23:28 -0700, Saul Wold wrote:
> Please pull this request, based on some cleanups and
> additional changes.  This has been built on multiple 
> machines.
[...]
> Dexuan Cui (9):
>   libxfixes: upgrade from 4.0.5 to the latest version 5.0
>   util-macros: upgrade from 1.11.0 to 1.13.0
>   preferred-xorg-versions.inc: update libxfixes, util-macros,
> xorg-cf-files
>   mdadm: upgrade from 3.1.4 to the latest version 3.2.1
>   liburcu: upgrade from 0.5.2 to 0.5.4
>   lttng-ust: upgrade from 0.11 to the latest version 0.12
>   task-poky-tools.bb, task-sdk-gmae.inc: enable lttng-ust for ARM
>   lttng-viewer: upgrade from 0.12.36 to the latest version 0.12.38
>   distro_tracking_fields.inc: update the info for the following recipes
> 
> Gary Thomas (1):
>   Control over when package init scripts are run
> 
> Kang Kai (1):
>   lsbsetup: add some workaround for LSB tests
> 
> Khem Raj (1):
>   pcmciautils: Upgrade 017 -> 018
> 
> Koen Kooi (1):
>   librsvg 2.32.1: fix postinst script
> 
> Martin Jansa (3):
>   gconf-dbus: add SRCREV to recipe
>   xf86-video-omapfb: add SRCREV to recipe
>   task-base: allow distribution to define apm provider

I've given some feedback on these.

> Nitin A Kamble (8):
>   mpfr: upgrade from 3.0.0 to 3.0.1
>   python-gst: upgrade from 0.10.19 to 0.10.21
>   git: upgrade from 1.7.3.4 to 1.7.4.3
>   python-pycairo: fix installation path of __init__.py
>   perl-5.12.2: use of PERLHOSTLIB var fix
>   cpan.bbclass: export PERLHOSTLIB for perl modules
>   libxml-parser-perl: upgrade from 2.36 to 2.40
>   distro_tracking: recipe information update
> 
> Petr Štetiar (1):
>   modutils-initscripts: fix wrong order of module loading happening in
> udev
> 
> Saul Wold (4):
>   slang: Fix host contamination issue
>   qemu: disable sdl for target build
>   ofono: add bluez4 to DEPENDS list
>   qemu-helper-nativesdk: Update LIC_FILE_CHKSUM for renamed helper
> 
> Tom Zanussi (1):
>   linux-tools.inc: turn off newt and dwarf for perf
> 
> Xiaofeng Yan (1):
>   create-lsb-image:Rename creat-lsb-image and fix some bugs
> 
> Zhai Edwin (6):
>   tasks: Upgrade to 0.19 (from 0.18)
>   avahi: Upgrade to 0.6.30 (from 0.6.28)
>   consolekit: Upgrade to 0.4.4 (from 0.4.3)
>   libgpg-error: Upgrade to 1.10 (from 1.9)
>   jpeg: Upgrade to 8c (from 8b)
>   puzzles: Upgrade to svn r9151 (from r9084)

but I merged everything else, thanks!

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 33/37] gconf-dbus: add SRCREV to recipe

[Richard Purdie]

On Fri, 2011-04-22 at 23:29 -0700, Saul Wold wrote:
> From: Martin Jansa 
> 
> * taken from meta/conf/distro/include/poky-default-revisions.inc for
>   those who want gconf-dbus and are not using poky
> 
> Signed-off-by: Martin Jansa 

I've like to hold off this SRCREV change and the other one for just a
little longer. Yu Ke is doing some investigation to confirm that global
include file is no longer required and assuming we find it isn't, we'll
move everything to the recipes in one go. I'd rather not do this
piecemeal and risk confusion so I'd appreciate patience for another few
days on this one.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] task-base: allow distribution to define apm provider

[Richard Purdie]

On Mon, 2011-04-25 at 00:25 +0200, Martin Jansa wrote:
> * use VIRTUAL-RUNTIME_apm instead of apm directly
> 
> Signed-off-by: Martin Jansa 
> ---
>  meta/recipes-core/tasks/task-base.bb |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 37/52] insane.bbclass: Move code to add function to tasks toward the end

[Richard Purdie]

On Wed, 2011-04-27 at 00:29 -0700, Saul Wold wrote:
> From: Khem Raj 
> 
> Cosmetic change to make syntax highlighters happy
> 
> Signed-off-by: Khem Raj 

I'll take the patch but shouldn't someone fix the syntax highlighters as
the syntax is obviously correct and works ;-).

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/52] gcc: Add recipes for 4.6.0

[Richard Purdie]

On Wed, 2011-04-27 at 00:29 -0700, Saul Wold wrote:
> From: Khem Raj 
> 
> Hi
> 
> This is initial set of patches for testing them out
> The patches need documentation is pending
> Some patches especially uclibc related are not
> needed they must be dropped.
> 
> This is not the final version yet. But I would like
> folks to help trying them out and report issues
> 
> I have tried to boot uclibc/arm on it but qemu
> died on me. so please boot the images you build
> and I would be interested to know the results.
> 
> -Khem
> 
> Signed-off-by: Khem Raj 
> Signed-off-by: Saul Wold 

I trimmed this commit message a little - I'm hoping Saul did intend to
include this patch but the commit message makes me wonder ;-).

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 36/52] gettext.bbclass: Use _append instead of =+

[Richard Purdie]

On Wed, 2011-04-27 at 00:29 -0700, Saul Wold wrote:
> From: Khem Raj 
> 
> Ensure gettext and gettext-native are removed from DEPENDS when
> not using NLS
> 
> Use append instead of += to get gettext dependecies processed
> correctly in all cases
> 
> Dont remove gettext-native for native recipes as ENABLE_NLS is
> only for target and not for native recipes
> 
> Replace using 1 for a boolean type with True
> 
> Honor INHIBIT_DEFAULT_DEPS
> 
> Remove the added dependencies for gettext if INHIBIT_DEFAULT_DEPS is non
> null
> 
> operate on virtclass overrides individually
> 
> virtclass classes are parsed at the end hence
> just doing DEPENDS munging is not enough since
> it will be overridden

This patch is better but I have a couple of things I'd like to see
tweaked.

> Signed-off-by: Khem Raj 
> ---
>  meta/classes/gettext.bbclass |   38 ++
>  1 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
> index a40e74f..f7b84ec 100644
> --- a/meta/classes/gettext.bbclass
> +++ b/meta/classes/gettext.bbclass
> @@ -1,17 +1,31 @@
>  def gettext_after_parse(d):
> -# Remove the NLS bits if USE_NLS is no.
> -if bb.data.getVar('USE_NLS', d, 1) == 'no':
> -cfg = oe_filter_out('^--(dis|en)able-nls$', 
> bb.data.getVar('EXTRA_OECONF', d, 1) or "", d)
> -cfg += " --disable-nls"
> -depends = bb.data.getVar('DEPENDS', d, 1) or ""
> -bb.data.setVar('DEPENDS', 
> oe_filter_out('^(virtual/libiconv|virtual/libintl)$', depends, d), d)
> -bb.data.setVar('EXTRA_OECONF', cfg, d)
> -
> +   # Remove the NLS bits if USE_NLS is no.
> +   if bb.data.getVar('USE_NLS', d, True) == 'no':
> +   cfg = oe_filter_out('^--(dis|en)able-nls$', 
> bb.data.getVar('EXTRA_OECONF', d, 1) or "", d)
> +   cfg += " --disable-nls"
> +   depends = bb.data.getVar('DEPENDS', d, True) or ""

These lines all look the same but the indentation is different. Python
should always be four spaces and indentation changes should always be as
a separate patch from code changes anyway. Please fix :)

> +   depends = 
> oe_filter_out('^(virtual/libiconv|virtual/libintl|virtual/gettext|gettext)$', 
> depends, d)
> +   if not oe.utils.inherits(d, 'native', 'nativesdk', 'cross', 
> 'crosssdk'):
> +   depends = oe_filter_out('^(gettext-native)$', depends, d)
> +   bb.data.setVar('DEPENDS', depends, d)
> +   bb.data.setVar('EXTRA_OECONF', cfg, d)
> +   # check if INHIBIT_DEFAULT_DEPS is 1 then we forcibly remove dependencies
> +   # added by this class through DEPENDS_GETTEXT
> +   if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True):
> +   depends_native = bb.data.getVar('DEPENDS_virtclass-native', d, True) 
> or ""
> +   depends_nativesdk = bb.data.getVar('DEPENDS_virtclass-nativesdk', d, 
> True) or ""
> +   depends = bb.data.getVar('DEPENDS', d, True) or ""
> +   gettext_deps = bb.data.getVar('DEPENDS_GETTEXT', d, True).replace(' 
> ','|')
> +   gettext_deps = '^(' + gettext_deps + ')$'
> +   depends_native = oe_filter_out(gettext_deps, depends_native, d)
> +   depends_nativesdk = oe_filter_out(gettext_deps, depends_nativesdk, d)
> +   depends = oe_filter_out(gettext_deps, depends, d)
> +   bb.data.setVar('DEPENDS_virtclass-native', depends, d)
> +   bb.data.setVar('DEPENDS_virtclass-nativesdk', depends, d)
> +   bb.data.setVar('DEPENDS', depends, d)

We can make this simpler. We should just setVar("DEPENDS_GETTEXT", "")
in the INHIBIT_DEFAULT_DEPS case. If anything is expanding the variables
somewhere, we should fix that.

In fact, rather than all this ugly manipulation can't we just set
DEPENDS_GETTEXT to "" in the INHIBIT_DEFAULT_DEPS or USE_NLS cases? If
that doesn't work, the recipes dependencies are broken and should be
fixed to inherit this class, right? 

>  python () {
>  gettext_after_parse(d)
>  }
> -
> -DEPENDS_GETTEXT = "gettext gettext-native"
> -
> -DEPENDS =+ "${DEPENDS_GETTEXT}"
>  EXTRA_OECONF += "--enable-nls"
> +DEPENDS_GETTEXT ?= "virtual/gettext"
> +DEPENDS_append = " ${DEPENDS_GETTEXT} "

I think this needs to be:

DEPENDS_GETTEXT ?= "virtual/gettext virtual/gettext-native"

as I'm sure we're been bitten by a lack of the native dependency
before :/. Target packages using gettext do definitely need both to be
available.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 38/52] insane.bbclass: Checking for NLS too when checking gettext dependency

[Richard Purdie]

On Wed, 2011-04-27 at 00:29 -0700, Saul Wold wrote:
> From: Khem Raj 
> 
> Checking for gettext is not needed when --disable-nls is used
> 
> Let user know what variant of gettext is missing e.g. gettext-native,
> gettext-nativesdk etc, reveals a bit more for user
> 
> Check for virtual/gettext
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/classes/insane.bbclass |9 +
>  1 files changed, 5 insertions(+), 4 deletions(-)

This depends on the gettext.bbclass changes so I didn't take this
either.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 44/52] util-linux.inc: remove virtual/libintl from DEPENDS

[Richard Purdie]

On Wed, 2011-04-27 at 00:30 -0700, Saul Wold wrote:
> From: Khem Raj 
> 
> inherit gettext should do it.
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/util-linux/util-linux.inc |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-core/util-linux/util-linux.inc 
> b/meta/recipes-core/util-linux/util-linux.inc
> index 913bb1b..447e5b7 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -13,10 +13,10 @@ LIC_FILES_CHKSUM = 
> "file://README.licensing;md5=1530e36fe1304d4535513de90a290df9
>  
> file://licenses/COPYING.UCB;md5=263860f8968d8bafa5392cab74285262 \
>  
> file://getopt/COPYING;md5=8ca43cbc842c2336e835926c2166c28b"
>  
> -DEPENDS = "zlib ncurses virtual/libintl"
> -DEPENDS_virtclass-native = "zlib-native ncurses-native lzo-native 
> gettext-native"
> -
>  inherit autotools gettext
> +DEPENDS = "zlib ncurses"
> +DEPENDS_virtclass-native_append = " lzo-native"
> +
>  
>  SRC_URI = 
> "${KERNELORG_MIRROR}/linux/utils/util-linux-ng/v${MAJOR_VERSION}/util-linux-ng-${PV}.tar.bz2
>  \
> file://MCONFIG \

I wasn't sure if this depended on the gettext.bbclass changes so again,
I didn't take it.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 34/52] logging: add bb* logging mechanisms for bash recipe functions

[Richard Purdie]

Hi Darren,

On Wed, 2011-04-27 at 00:29 -0700, Saul Wold wrote:
> The following logging mechanisms are to be used in bash functions of recipes.
> They are intended to map one to one in intention and output format with the
> python recipe logging functions of a similar naming convention: bb.plain(),
> bb.note(), etc.
> 
> For the time being, all of these print only to the task logs. Future
> enhancements may integrate these calls with the bitbake logging 
> infrastructure,
> allowing for printing to the console as appropriate. The interface and 
> intention
> statements reflect that future goal. Once it is in place, no changes will be
> necessary to recipes using these logging mechanisms.

This looks good but could you do a search and replace of any existing
users of the oe* functions and then remove them from base.bbclass
please? At the very least they should be calling the bb* equivalents.
I'd like to clean up this kind of thing as we go.

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/52] Updated Consolidated pull

[Richard Purdie]

Hi Saul,

On Wed, 2011-04-27 at 00:29 -0700, Saul Wold wrote:
> This has been reviewed and build on x86 and ARM, I have worked also to build
> full world, it's almost there, qemu on the target needs a few more tweaks, 
> it's
> closer!

Thanks, I merged apart from 3 patches which I've replied to with the
details of why not.

Cheers,

Richard




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/52] gcc: Add recipes for 4.6.0

[Richard Purdie]

On Wed, 2011-04-27 at 11:23 -0700, Saul Wold wrote:
> On 04/27/2011 01:17 AM, Antonio Ospite wrote:
> > On Wed, 27 Apr 2011  0:29:21 -0700
> > Saul Wold  wrote:
> >
> >> From: Khem Raj
> >>
> >> Hi
> >>
> >> This is initial set of patches for testing them out
> >> The patches need documentation is pending
> >> Some patches especially uclibc related are not
> >> needed they must be dropped.
> >>
> >> This is not the final version yet. But I would like
> >> folks to help trying them out and report issues
> >>
> >
> > If these changes turned to be the final ones then the commit message
> > should be updated, shouldn't it?
> >
> Not final yet, I am pushing it now so people can set their local 
> GCCVERSION and SDKGCCVERSION to test if they would like.

Independently, I also thought the commit messaged should have been
tweaked, see the other emails ;-).

The original message read like a request for testing but it wasn't ready
for merging into the repo. Now its being submitted, it either is ready
or it was a mistake and it could easily look like the latter.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 07/37] modutils-initscripts: fix wrong order of module loading happening in udev

[Richard Purdie]

On Tue, 2011-04-26 at 10:51 -0700, Khem Raj wrote:
> On Mon, Apr 25, 2011 at 10:47 PM, Darren Hart  wrote:
> > On 04/25/2011 10:14 AM, Gary Thomas wrote:
> >
> > Right, so for clarification, for 2.4 kernels, images should be built
> > using just the modutils_2.4.27.bb recipe. For 2.6 kernels, images should
> > be built using module_init_tools and modutils-initscripts.
> >
> > In oe-core, task-base requires module-init-tools and task-core-boot
> > requires modutils-initscripts. That actually seems backwards to me as
> > modutils-initscripts is useless without module-init-tools.
> >
> > There is a considerable amount of cruft in the kernel base classes
> > related to older kernels which I'd like to see purged. Perhaps a
> > meta-linux-2.4 layer would be a good place to keep things like these as
> > well as the modutils_2.4.27 recipe.
> 
> Do we have usecases to even support 2.4 anymore ? I would suggest
> to remove it if no use cases are reported.

I think the time has come for OE-Core to clean out kernel.bbclass of the
2.4 code. If anyone does want to support 2.4, they can do it with a
separate kernel-2.4 class.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH]] python: Unbreak Python third-party extensions

[Richard Purdie]

On Fri, 2011-04-29 at 12:44 +0200, Michael Lippautz wrote:
> This fixes compilation/linking of Python 3rd party extensions.
> 
> ${STAGING_LIBDIR}/python/config/Makefile needs the correct
> INCDIR and LIBDIR settings to be used in cross compilation for the
> target. 3rd party module use distutils.sysconfig which uses this
> Makefile to create compiler/linker flags.
> 
> Workflow:
> 1) compile needs the staged/sysroot Makefile since it is needed
>for compilation/linking
> 2) install needs the unmodified Makefile to install files (i.e.
>headers) into the right directores. (otherwise they would be
>installed in ${D}/${STAGING_...}
> 3) staging needs modified Makefile again
> 4) packaging needs unmodified to make compilation on the target
>possible
> 
> Signed-off-by: Michael Lippautz 
> ---
>  meta/recipes-devtools/python/python_2.6.6.bb |   25 +++--
>  1 files changed, 19 insertions(+), 6 deletions(-)

I'm ok with this patch but I am a little worried looking at the python
recipe that it won't interact well with sstate. I'd therefore like to
fix this whilst we have someone who understands this code around.

The problem is that do_compile_prepend() is poking files directly into
staging. Instead, do_install should be manipulating things in ${D}
instead and then PACKAGE_PREPROCESS_FUNCS and SYSROOT_PREPROCESS_FUNCS
should be taking care of any fixups for the target/sysroot cases.

Can we add the code in the do_compile_prepend() to the start of the
do_install() ?

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 36/52] gettext.bbclass: Use _append instead of =+

[Richard Purdie]

On Fri, 2011-04-29 at 09:11 -0700, Khem Raj wrote:
> On Thu, Apr 28, 2011 at 2:01 AM, Richard Purdie
>  wrote:
> > We can make this simpler. We should just setVar("DEPENDS_GETTEXT", "")
> > in the INHIBIT_DEFAULT_DEPS case. If anything is expanding the variables
> > somewhere, we should fix that.
> >
> 
> Infact the virtclass stuff complicates this since they are evaluated
> specially and I am not clear weather _append gets
> evaluation before that or after and also the anon python function
> evaluation as the one we are defining in this class.
> 
> I tried to empty out DEPENDS_GETTEXT but it does not work in nativesdk cases.

I still think we can simplify this. Could you try the following patch
please?:

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 4f20bc2..3b83e42 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -89,9 +89,11 @@ def base_dep_prepend(d):
deps += " virtual/${TARGET_PREFIX}gcc 
virtual/${TARGET_PREFIX}compilerlibs virtual/libc "
return deps
 
-DEPENDS_prepend="${@base_dep_prepend(d)} "
-DEPENDS_virtclass-native_prepend="${@base_dep_prepend(d)} "
-DEPENDS_virtclass-nativesdk_prepend="${@base_dep_prepend(d)} "
+BASEDEPENDS = "${@base_dep_prepend(d)}"
+
+DEPENDS_prepend="${BASEDEPENDS} "
+DEPENDS_virtclass-native_prepend="${BASEDEPENDS} "
+DEPENDS_virtclass-nativesdk_prepend="${BASEDEPENDS} "
 
 FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", 
"${FILE_DIRNAME}/${P}", "${FILE_DIRNAME}/${PN}", "${FILE_DIRNAME}/${BP}", 
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files", "${FILE_DIRNAME}" ], d)}"
 # THISDIR only works properly with imediate expansion as it has to run
diff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
index a40e74f..57b551e 100644
--- a/meta/classes/gettext.bbclass
+++ b/meta/classes/gettext.bbclass
@@ -1,17 +1,17 @@
 def gettext_after_parse(d):
 # Remove the NLS bits if USE_NLS is no.
-if bb.data.getVar('USE_NLS', d, 1) == 'no':
-cfg = oe_filter_out('^--(dis|en)able-nls$', 
bb.data.getVar('EXTRA_OECONF', d, 1) or "", d)
-cfg += " --disable-nls"
-depends = bb.data.getVar('DEPENDS', d, 1) or ""
-bb.data.setVar('DEPENDS', 
oe_filter_out('^(virtual/libiconv|virtual/libintl)$', depends, d), d)
-bb.data.setVar('EXTRA_OECONF', cfg, d)
+if bb.data.getVar('USE_NLS', d, True) == 'no':
+bb.data.setVar('DEPENDS_GETTEXT', "", d)
+bb.data.setVar('OECONFNLSOPTION', '--disable-nls', d)
+if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not 
oe.utils.inherits(d, 'cross-canadian'):
+bb.data.setVar('DEPENDS_GETTEXT', "", d)
 
 python () {
 gettext_after_parse(d)
 }
 
-DEPENDS_GETTEXT = "gettext gettext-native"
+DEPENDS_GETTEXT = "virtual/gettext gettext-native"
+OECONFNLSOPTION = "--enable-nls"
 
-DEPENDS =+ "${DEPENDS_GETTEXT}"
-EXTRA_OECONF += "--enable-nls"
+BASEDEPENDS =+ "${DEPENDS_GETTEXT}"
+EXTRA_OECONF += "${OECONFNLSOPTION}"




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] OpenEmbedded eV membership drive

[Richard Purdie]

On Tue, 2011-05-03 at 22:05 +0200, Frans Meulenbroeks wrote:
> 2011/5/3 Philip Balister 
> 
> [...]
> 
> People ask me why they should join the eV. Besides being a
> good way to show your support for the OpenEmbedded project,
> the Technical Steering Committee is elected by the eV members.
> 
> Sorry but the current TSC is NOT elected by the eV members. 

The current situation was making the best of a bad set of circumstances,
the plan is to hold elections and nothing has changed in that regard.

> Actually the board even fails to meet its own "rules" stipulated when
> they installed this interim TSC.
> 
> From Philip's email from feb 10:
> This interim TSC will operate for 2 months when we shall start elections
> at two month intervals for the 5 positions on the TSC. The new elected
> TSC members will operate under the charter detailed on the wiki here
> 
> http://wiki.openembedded.org/index.php/TSCCharter.
> We're now almost 3 months later and no election has been held!

This was discussed at the last TSC meeting and we reviewed the TSC
meeting minutes where it was recorded that:

"""
Election wise, we'll elect the seats in the order from the board
announcement email until we have 5 elected members. We will rely on the
board to call the first election in May. 
"""

which the TSC has reminded the board about last week.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] OpenEmbedded eV membership drive

[Richard Purdie]

On Tue, 2011-05-03 at 23:15 +0200, Frans Meulenbroeks wrote:
> 2011/5/3 Richard Purdie 

> This was discussed at the last TSC meeting and we reviewed the
> TSC
> meeting minutes where it was recorded that:
> 
> """
> Election wise, we'll elect the seats in the order from the
> board
> announcement email until we have 5 elected members. We will
> rely on the
> board to call the first election in May.
> """
> 
> which the TSC has reminded the board about last week.

> 
> I don't think it is up to the TSC to decide on the re-election
> timeframe. As it stands the TSC got a 2 month mandate. See the quote
> above (from Philip's email from feb 10).
> That is all I wanted to indicate.

The TSC was asked by the board to figure out the details of the election
which we did in the first meeting as requested and provided our feedback
back to the board. The board naturally has the ultimate say in this.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 36/52] gettext.bbclass: Use _append instead of =+

[Richard Purdie]

On Tue, 2011-05-03 at 11:04 -0700, Khem Raj wrote:
> This has the same problem It empties out DEPENDS_GETTEXT after they have
> have already been added to DEPENDS via virtclass e.g. when you build
> gcc-runtime-nativesdk it will report a dep loop since now it depends on
> virtual/gettext-nativesdk (added by gettext class)
> and virtual/gettext-nativesdk depends on compilerlibs
> provided by gcc-runtime-nativesdk. This was same problem I was trying to
> circumvent

Ok, how about this version:

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 4f20bc2..3b83e42 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -89,9 +89,11 @@ def base_dep_prepend(d):
deps += " virtual/${TARGET_PREFIX}gcc 
virtual/${TARGET_PREFIX}compilerlibs virtual/libc "
return deps
 
-DEPENDS_prepend="${@base_dep_prepend(d)} "
-DEPENDS_virtclass-native_prepend="${@base_dep_prepend(d)} "
-DEPENDS_virtclass-nativesdk_prepend="${@base_dep_prepend(d)} "
+BASEDEPENDS = "${@base_dep_prepend(d)}"
+
+DEPENDS_prepend="${BASEDEPENDS} "
+DEPENDS_virtclass-native_prepend="${BASEDEPENDS} "
+DEPENDS_virtclass-nativesdk_prepend="${BASEDEPENDS} "
 
 FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", 
"${FILE_DIRNAME}/${P}", "${FILE_DIRNAME}/${PN}", "${FILE_DIRNAME}/${BP}", 
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files", "${FILE_DIRNAME}" ], d)}"
 # THISDIR only works properly with imediate expansion as it has to run
diff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
index a40e74f..6f79e5e 100644
--- a/meta/classes/gettext.bbclass
+++ b/meta/classes/gettext.bbclass
@@ -1,17 +1,17 @@
-def gettext_after_parse(d):
-# Remove the NLS bits if USE_NLS is no.
-if bb.data.getVar('USE_NLS', d, 1) == 'no':
-cfg = oe_filter_out('^--(dis|en)able-nls$', 
bb.data.getVar('EXTRA_OECONF', d, 1) or "", d)
-cfg += " --disable-nls"
-depends = bb.data.getVar('DEPENDS', d, 1) or ""
-bb.data.setVar('DEPENDS', 
oe_filter_out('^(virtual/libiconv|virtual/libintl)$', depends, d), d)
-bb.data.setVar('EXTRA_OECONF', cfg, d)
+def gettext_dependencies(d):
+if d.getVar('USE_NLS', True) == 'no':
+return ""
+if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not 
oe.utils.inherits(d, 'cross-canadian'):
+return ""
+return d.getVar('DEPENDS_GETTEXT', False)
 
-python () {
-gettext_after_parse(d)
-}
+def gettext_oeconf(d):
+# Remove the NLS bits if USE_NLS is no.
+if d.getVar('USE_NLS', True) == 'no':
+return '--disable-nls'
+return "--enable-nls"
 
-DEPENDS_GETTEXT = "gettext gettext-native"
+DEPENDS_GETTEXT = "virtual/gettext gettext-native"
 
-DEPENDS =+ "${DEPENDS_GETTEXT}"
-EXTRA_OECONF += "--enable-nls"
+BASEDEPENDS =+ "${@gettext_dependencies(d)}"
+EXTRA_OECONF += "${@gettext_oeconf(d)}"


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/33] Consolidated Pull Request

[Richard Purdie]

On Tue, 2011-05-03 at 16:44 -0700, Saul Wold wrote:
> This has a dependency on your tweaks to gettext.bbclass
> and base.bbclass.  Otherwise this set has been well tested.
> It also contains patches that need to backported to bernard.

I merged these apart from:

> Koen Kooi (1):
>   git: make it work on the target
> 
> Saul Wold (5):
>   git: Disable gitk from by default

Since I don't think having tcltk-native as a dependency for git-native
is particularly desireable (but its ok for the target package) yet the
attempt to change this above still needs work.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv2] python: Unbreak Python third-party extensions

[Richard Purdie]

On Tue, 2011-05-03 at 18:40 +0200, Michael Lippautz wrote:
> This patch fixes compilation/linking of python third-party extensions, i.e.
> Extensions that ship with C code.
> 
> Problem:
> Python uses distutils(-native) to compile third-party extensions. distutils
> uses its own sysconfig module to get the options for compiling and linking.
> Since third-party extensions have to be linked against this libpython it
> important that -L points into staging. This is not the case because
> distutils.sysconfig uses a special Makefile that is shipped with python
> determine the paths. The Makefile is the same that would be used on the
> target to build third-party extensions. It therefore points into /usr/lib
> instead of staging.
> 
> Solution:
> Stage a modified version of the Makefile where the paths (incdir, libdir) have
> been replaced by ones that point into staging.
> 
> Side-problem:
> The recipe actually should not stage files itself in do_compile, but rather
> handle everything that needs to be staged in do_install. This is currently not
> possible because python compiles itself using distutils-native. Distutils on
> the other hand does only allow to add a path, but not to substitute it,
> requiring a staged Makefile and libpython.so before the actual python
> compilation is triggered.
> 
> The second step to solve this would be to either patch distutils, or split
> python into python-initial and python. The -initial part could create the
> Makefile and the library, while the main part focuses on the target.
> 
> For further references see:
>  http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/001752.html
> 
> Signed-off-by: Michael Lippautz 
> Acked-by: Martin Jansa 
> ---
>  meta/recipes-devtools/python/python_2.6.6.bb |   41 
> +-
>  1 files changed, 27 insertions(+), 14 deletions(-)

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] poky-default-revisions: move SRCREV to every recipe

[Richard Purdie]

On Wed, 2011-05-04 at 22:05 +0800, Yu Ke wrote:
> From: Yu Ke 
> 
> move the SRCREV from poky-default-revisions.inc to its corresponding recipe,
> in this case, those non poky distro can also use its SRCREV.
> 
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>   Branch: kyu3/srcrev-recipe
>   Browse: 
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/srcrev-recipe
> 
> Thanks,
> Yu Ke 
> ---
> 
> 
> Yu Ke (1):
>   poky-default-revisions: move the SRCREV to recipe file

Merged to master, thanks for resolving this issue! :)

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] poky-default-revisions: move SRCREV to every recipe

[Richard Purdie]

On Wed, 2011-05-04 at 16:24 +0200, Frans Meulenbroeks wrote:
> Most of the time the SRCREV is before the PV, but not always (and sometimes
> separated with an empty line and sometimes not).

Patches welcome...

> Also there is at least one error introduced:
> 
> diff --git 
> a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bbb/meta/recipes-devtools/yaffs2/
> yaffs2-utils_cvs.bb
> index 6171fe5..c729c7c 100644
> --- 
> a/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb
> +++ 
> b/meta/recipes-devtools/yaffs2/yaffs2-utils_cvs.bb
> @@ -1,3 +1,4 @@
> require yaffs2-utils.inc
> PR = "r1"
> +SRCDAT = "20071107"
> 
> That should be SRCDATE. There might be more of these, my eye just fell on
> this one.

Good catch, we need to fix that.

> Frans
> 
> PS: speaking of yaffs2 utils: it could be considered to move to a somewhat
> newer version (not that I care as I do not use yaffs2)

It is something we should look at going, yes although I don't think
yaffs2 has changed that much in a while.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 36/52] gettext.bbclass: Use _append instead of =+

[Richard Purdie]

On Wed, 2011-05-04 at 18:07 -0700, Khem Raj wrote:
> a build from scratch revealed few more issues with this patch too.
> 
> 1. We have to only remove gettext from dependencies if its a target
> package for all other it still it needed otherwise all native and
> cross tools start failing to build
>  e.g. binutils-cross this can be easily solved by a patch
> 
> iff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
> index 6f79e5e..cc39204 100644
> --- a/meta/classes/gettext.bbclass
> +++ b/meta/classes/gettext.bbclass
> @@ -1,5 +1,5 @@
>  def gettext_dependencies(d):
> -if d.getVar('USE_NLS', True) == 'no':
> +if d.getVar('USE_NLS', True) == 'no' and not oe.utils.inherits(d,
> 'native', 'nativesdk', 'cross')
>  return ""
>  if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not
> oe.utils.inherits(d, 'cross-canadian')
>  return ""

This looks reasonable, its still much clearer what is happening and why
compared to the original version...

> second problem is that EXTRA_OECONF when recipes override it instead
> of += or appending etc.
> then --enable|--disable-nls that we added via gettext_oeconf() is lost
> as a result some packages complain about config.rpath
> when USE_NLS is set to no the reason is their configure is missing the
> argument --disable-nls this works ok
> for eglibc based targets since default is to enable-nls if nothing is
> specified but uclibc fails. As a testcase try to preprocess
> utils-linux
> recipe and check the contents of EXTRA_OECONF

I suspect we can fix this with:

-EXTRA_OECONF += "${@gettext_oeconf(d)}"
+EXTRA_OECONF_append = " ${@gettext_oeconf(d)}"

?

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 12/26] Remove machine-specific metadata for machines no longer in oe-core

[Richard Purdie]

On Thu, 2011-05-05 at 00:57 -0700, Saul Wold wrote:
> From: Paul Eggleton 
> 
> Signed-off-by: Paul Eggleton 
> ---
>  meta/recipes-core/base-files/base-files_3.0.14.bb |   19 +++
>  1 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb 
> b/meta/recipes-core/base-files/base-files_3.0.14.bb
> index 4445081..c80faaa 100644
> --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
> +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
> @@ -131,6 +131,25 @@ do_install_basefilesissue () {
>   fi
>  }
>  
> +<<< HEAD
> +===
> +do_install_append_nylon() {
> + printf "" "" >${D}${sysconfdir}/resolv.conf
> + rm -r ${D}/mnt/*
> + rm -r ${D}/media
> + rm -rf ${D}/tmp
> + ln -sf /var/tmp ${D}/tmp
> +}
> +
> +do_install_append_slugos() {
> + printf "" "" >${D}${sysconfdir}/resolv.conf
> + rm -r ${D}/mnt/*
> + rmdir ${D}/home/root
> + install -m 0755 -d ${D}/root
> + ln -s ../root ${D}/home/root
> +}
> +
> +>>> d67f12d... Remove machine-specific metadata for machines no longer 
> in oe-core
>  do_install_append_linuxstdbase() {
>   for d in ${dirs3755}; do
>  install -m 0755 -d ${D}$d

Er, I didn't take this ;-)

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 19/26] linux-yocto_git.bb: Backport upstream fix for gcc 4.6 compilation

[Richard Purdie]

On Thu, 2011-05-05 at 00:57 -0700, Saul Wold wrote:
> From: Khem Raj 
> 
> Signed-off-by: Khem Raj 
> ---
>  .../perf-tool-Fix-gcc-4.6.0-issues.patch   |  266 
> 
>  meta/recipes-kernel/linux/linux-yocto_git.bb   |4 +-
>  2 files changed, 269 insertions(+), 1 deletions(-)
>  create mode 100644 
> meta/recipes-kernel/linux/linux-yocto/perf-tool-Fix-gcc-4.6.0-issues.patch
> 
> diff --git 
> a/meta/recipes-kernel/linux/linux-yocto/perf-tool-Fix-gcc-4.6.0-issues.patch 
> b/meta/recipes-kernel/linux/linux-yocto/perf-tool-Fix-gcc-4.6.0-issues.patch
> new file mode 100644
> index 000..c3510ad
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/linux/linux-yocto/perf-tool-Fix-gcc-4.6.0-issues.patch
> @@ -0,0 +1,266 @@
> +Backported to linux-yocto kernel git version
> +
> +Signed-off-by: Khem Raj 
> +
> +
> +From patchwork Tue Apr 19 20:09:19 2011
> +Content-Type: text/plain; charset="utf-8"
> +MIME-Version: 1.0
> +Content-Transfer-Encoding: 7bit
> +Subject: [70/70] perf tool: Fix gcc 4.6.0 issues
> +Date: Tue, 19 Apr 2011 20:09:19 -
> +From: Greg Kroah-Hartman 
> +X-Patchwork-Id: 719212
> +Message-Id: <20110419201050.665258...@clark.kroah.org>
> +To: linux-ker...@vger.kernel.org, sta...@kernel.org
> +Cc: stable-rev...@kernel.org, torva...@linux-foundation.org,
> + a...@linux-foundation.org, a...@lxorguk.ukuu.org.uk,
> + Ingo Molnar , Kyle McMartin ,
> + Arnaldo Carvalho de Melo , Thomas Meyer 
> +
> +2.6.38-stable review patch.  If anyone has any objections, please let us 
> know.

Bruce, can you confirm that with your SRCREV change, this patch isn't
required as you've integrated it directly?

I've not taken it for now...

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/26] Consolidated Pull for 05-May-2011

[Richard Purdie]

On Thu, 2011-05-05 at 00:55 -0700, Saul Wold wrote:
> This has some major updates for cleaning up machine and distro
> usage in oe-core, it also includes the SRC_REV removal.
> 
> In addition, a updated set of kernel recipes and GCC4.6 fixes.
> There are also fixes that will be targeted for Bernard and general
> build and lsb fixes.
> 
> Community Folks, if you are up for testing GCC 4.6, please take
> this opportinuty to check out what Khem as provide, if need please
> file bugs in bugzilla.
> 
> This has been build for x86 and ARM (world builds, minus target qemu).

I merged this with the exceptions I've replied to or where it was
requested I skip the patch. The meta-yocto patch was only merged to
poky.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] poky-default-revisions: move SRCREV to every recipe

[Richard Purdie]

On Wed, 2011-05-04 at 11:39 -0400, Bruce Ashfield wrote:
> On Wed, May 4, 2011 at 10:05 AM, Yu Ke  wrote:
> > From: Yu Ke 
> >
> > move the SRCREV from poky-default-revisions.inc to its corresponding recipe,
> > in this case, those non poky distro can also use its SRCREV.
> >
> > Pull URL: git://git.pokylinux.org/poky-contrib.git
> >  Branch: kyu3/srcrev-recipe
> >  Browse: 
> > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/srcrev-recipe
> >
> > Thanks,
> >Yu Ke 
> > ---
> >
> >
> > Yu Ke (1):
> >  poky-default-revisions: move the SRCREV to recipe file
> >
> >  meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb |1 +
> >  .../recipes-graphics/clutter/table_git.bb  |1 +
> >  meta-demoapps/recipes-graphics/clutter/tidy_git.bb |1 +
> 
> 
> 
> >  meta/recipes-kernel/blktrace/blktrace_git.bb   |2 +
> >  meta/recipes-kernel/dtc/dtc_git.inc|2 +
> >  .../kern-tools/kern-tools-native_git.bb|1 +
> >  .../linux-firmware/linux-firmware_git.bb   |1 +
> >  .../linux-libc-headers-yocto_git.bb|1 +
> >  .../recipes-kernel/linux/linux-yocto-stable_git.bb |   12 ++
> >  meta/recipes-kernel/linux/linux-yocto_git.bb   |   14 ++\
> 
> Would it be possible to get direct cc on changes to the linux-yocto
> recipes ? I didn't expect this and it is causing me a bit of pain at
> the moment. A direct cc' would have helped, since I would have
> preferred to stage the change in with my other items.

Sorry about that. Hopefully everyone agrees the end result is worth it
though as we're rid of that central file finally :)

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] meta-yocto: add pieces removed from oe-core for beagleboard & atom-pc

[Richard Purdie]

Hi Paul,

Great work in doing this, thanks. I was just looking at it with a view
to making machine support cleaner and I think there are still things we
can likely to do help with this. As one example:

On Wed, 2011-05-04 at 15:51 +0100, Paul Eggleton wrote:
> +++ b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
> @@ -0,0 +1,2 @@
> +QT_GLFLAGS_atom-pc = "-opengl"
> +
> diff --git a/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend 
> b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
> new file mode 100644
> index 000..076ade2
> --- /dev/null
> +++ b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
> @@ -0,0 +1,2 @@
> +QT_GLFLAGS_atom-pc = "-opengl"

could we set QT_GLFLAGS in the machine.conf file instead of using a
bbappend?

We could also do with finding a way to clean up clutter...

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [poky] [PATCH 1/3] Remove machine-specific metadata for machines no longer in oe-core

[Richard Purdie]

On Wed, 2011-05-04 at 16:21 +0100, Paul Eggleton wrote:
> On Wednesday 04 May 2011 16:07:17 Gary Thomas wrote:
> > Perhaps it makes sense to always package netbase in ${MACHINE_ARCH} since
> > it almost always will have machine specific data?
> 
> I'll let someone else comment on this, I don't have a hard opinion either way.

Since the exception machines are clearly listed I think its fine as it
stands at the moment. If we start getting lots of overrides there we can
rethink it though. Lets see how it goes...

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [poky] [PATCH 3/3] meta-yocto: add pieces removed from oe-core for beagleboard & atom-pc

[Richard Purdie]

On Thu, 2011-05-05 at 13:46 +0200, Koen Kooi wrote:
> Op 5 mei 2011, om 13:38 heeft Richard Purdie het volgende geschreven:
> 
> > Hi Paul,
> > 
> > Great work in doing this, thanks. I was just looking at it with a view
> > to making machine support cleaner and I think there are still things we
> > can likely to do help with this. As one example:
> > 
> > On Wed, 2011-05-04 at 15:51 +0100, Paul Eggleton wrote:
> >> +++ b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
> >> @@ -0,0 +1,2 @@
> >> +QT_GLFLAGS_atom-pc = "-opengl"
> >> +
> >> diff --git a/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend 
> >> b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
> >> new file mode 100644
> >> index 000..076ade2
> >> --- /dev/null
> >> +++ b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
> >> @@ -0,0 +1,2 @@
> >> +QT_GLFLAGS_atom-pc = "-opengl"
> > 
> > could we set QT_GLFLAGS in the machine.conf file instead of using a
> > bbappend?
> 
> Putting such USEFLAGS in machines sounds like a bad idea. In this case
> enabling it globally and falling back to mesa sw rendering at runtime
> is a better idea. The GL flag only enables extra API and libs, so it's
> good to have.

Agreed, longer term I think this is going to be the better way to handle
this. In this day and age, defaulting to sw rendering is probably the
sane thing to do.

Equally, moving this from a .bbappend to the machine file is a bit
cleaner too though :)

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [poky] [PATCH 3/3] meta-yocto: add pieces removed from oe-core for beagleboard & atom-pc

[Richard Purdie]

On Thu, 2011-05-05 at 14:31 +0200, Koen Kooi wrote:
> Op 5 mei 2011, om 14:21 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-05-05 at 13:46 +0200, Koen Kooi wrote:
> >> Op 5 mei 2011, om 13:38 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> Hi Paul,
> >>> 
> >>> Great work in doing this, thanks. I was just looking at it with a view
> >>> to making machine support cleaner and I think there are still things we
> >>> can likely to do help with this. As one example:
> >>> 
> >>> On Wed, 2011-05-04 at 15:51 +0100, Paul Eggleton wrote:
> >>>> +++ b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.6.3.bbappend
> >>>> @@ -0,0 +1,2 @@
> >>>> +QT_GLFLAGS_atom-pc = "-opengl"
> >>>> +
> >>>> diff --git a/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend 
> >>>> b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
> >>>> new file mode 100644
> >>>> index 000..076ade2
> >>>> --- /dev/null
> >>>> +++ b/meta-yocto/recipes-qt/qt4/qt4-x11-free_4.7.2.bbappend
> >>>> @@ -0,0 +1,2 @@
> >>>> +QT_GLFLAGS_atom-pc = "-opengl"
> >>> 
> >>> could we set QT_GLFLAGS in the machine.conf file instead of using a
> >>> bbappend?
> >> 
> >> Putting such USEFLAGS in machines sounds like a bad idea. In this case
> >> enabling it globally and falling back to mesa sw rendering at runtime
> >> is a better idea. The GL flag only enables extra API and libs, so it's
> >> good to have.
> > 
> > Agreed, longer term I think this is going to be the better way to handle
> > this. In this day and age, defaulting to sw rendering is probably the
> > sane thing to do.
> 
> Something like SOC_FAMILY would help here.

In some cases.

> > Equally, moving this from a .bbappend to the machine file is a bit
> > cleaner too though :)
> 
> Is it? Do you really want the machine to know about all the knobs in
> all the different layers? The .bbappends clearly signals a change to
> the recipe, hiding it in the machine.conf will just confuse people.
> And when changing options you need to edit the machine and then use
> PR_INC in a different file. Using a bbappend limits that to a single
> file

I'm not saying this makes sense for every bbappend option. For something
like QT and which is a part of OECore, I'm leaning towards being less
concerned about it though and making *every* QT machine write a bbappend
seems a little extreme the other way.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native

[Richard Purdie]

On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
> (Sorry for my delay for the task as I was working on other bugs...)
> Recently I have been looking into it and I've made some commits (the
> top 5 small commits) in
> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native
>  
> BTW: the work is not done completely as some recipes don't build
> with the changes. Please have a look anyway to see if I'm in the correct 
> direction.
> 
> However, I've got some difficulties and hope to get your help:
> 1)  As you said, after we install perl-native into its own directory,
> any recipe not depending on perl-native doesn't see
> ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
> However, if we keep the current code, what's the bad consequence if
> the recipe not depending on perl-native does see perl of perl-native?
> looks no?

We have an assumption that perl is already on the system we're building
on. Perl is a relatively stable language with defined compatibility and
interoperability. Most recipes are therefore fine using perl from the
build system directly and don't need perl-native. I think we defined a
special name for the build system perl (perl-native-runtime?). Better
names are welcome but we should ensure we use the right dependency in
the right places.

The time to use perl-native instead of perl-native-runtime is where any
perl module is being built, perl itself is being built or anything that
has an explicit dependency on the perl version present.

> 2) In poky, I see many places hardcodedly use the system
> perl(i.e., /usr/bin/perl) explicitly or implicitly(e.g,
> meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in
> contains /usr/bin/perl; another example,  in perl-5.12.3's source
> code, Cross/generate_config_sh also contains #!/usr/bin/perl). Should
> we fix all of them?

Most of these should be generated locations and I think this is fine
since most of these are "perl-native-runtime" uses and its fine to use
the build system perl.

>And what's the relationship between the system perl and
> perl-native? Since perl-native is not less functional than the system
> perl, will we eliminate the system perl as a prerequisite to bitbake
> in future?

No, I think you have this backwards. The intent is to have
"perl-native-runtime" denoting a requirement on the build system perl
and "perl-native" being a perl that exactly the same as the target perl
for cross purposes.

> 3) In gnu-config_20080123.bb's do_install, I don't understand this lines: 
> here the "!=" should be "="?
> if [ "${BUILD_ARCH}" != "${TARGET_ARCH}" ]; then
> sed -i -e 's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize
> fi

This means it only applies for non-native packages. (native has
BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
with things like the nativesdk packages where bindir != "/usr/bin".

> e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
> host,  BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
> when building gnu-config, the sed will be invoked, but bindir is
> just /usr/bin, so the replacement operation actually does nothing.

You can define a system where exec_prefix is "" and bindir is hence
"/bin" when it wouldn't do nothing.

> And for gnu-config-native, I think we need do a 
> sed -i -e 's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g' 
> ${D}${bindir}/gnu-configize
> Correct?

No, the whole point is to stop it seeing perl-native. Only perl itself
and modules should be using perl-native.

> 4) My last commit of the top 5 commits is a chaos... I'm trying to
> replace every "DEPENDS on perl-native" with "inherit perlnative".
> I'm now stuck in fixing the build issues for libxml-parser-perl and 
> libxml-parser-perl-native.
> I don't know how to fix get_perl_version and perl_get_libdirs in
> cpan-base.bbclass -- for libxml-parser-perl-native, I have to manage
> to add a "/perl-native" into STAGING_LIBDIR and libdir, but for
> libxml-parser-perl, I can't change STAGING_LIBDIR and libdir. Can you
> please help me out?

I'd suggest splitting this into two steps:

a) Check through all perl-native references and correct the ones that 
   should be perl-native-runtime.
b) Replace all remaining perl-native references with the class 
   dependency.

In step a), gnu-config would have a dependency on perl-native-runtime so
wouldn't use the perlnative class.

Just for reference, using perl-native-runtime means that someone can
remove it from ASSUME_PROVIDED and provide a version of it themselves if
they so wish (using perl-native or otherwise).

I suspect you'll still have the libxml-parser-perl problem but lets take
this one step at a time! :)

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native

[Richard Purdie]

On Fri, 2011-05-06 at 16:52 +0800, Cui, Dexuan wrote:
> Richard Purdie wrote:
> >> 3) In gnu-config_20080123.bb's do_install, I don't understand this
> >> lines: here the "!=" should be "="? if [ "${BUILD_ARCH}" !=
> >> "${TARGET_ARCH}" ]; then sed -i -e
> >> 's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
> > 
> > This means it only applies for non-native packages. (native has
> > BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
> > with things like the nativesdk packages where bindir != "/usr/bin".
> Thanks for the explanation!
> My understanding about "non-native package" is target recipe (in this case 
> bindir=/usr/bin)
> and -nativesdk recipe.
> gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
> contain nativesdk), so looks the sed replacement is useless at present?

Not useless but not heavily used directly in Poky at this time.
DISTRO=minimal in OE for example sets exec_prefix="" so bindir
becomes /bin.

> >> e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
> >> host,  BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
> >> when building gnu-config, the sed will be invoked, but bindir is
> >> just /usr/bin, so the replacement operation actually does nothing.
> > 
> > You can define a system where exec_prefix is "" and bindir is hence
> > "/bin" when it wouldn't do nothing.

As I mentioned here :)

> >> And for gnu-config-native, I think we need do a
> >> sed -i -e
> >> 's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g'
> >> ${D}${bindir}/gnu-configize Correct? 
> > 
> > No, the whole point is to stop it seeing perl-native. Only perl itself
> > and modules should be using perl-native.
> So gnu-config-native should use perl-native-runtime(i.e., the system perl) and
> shouldn't depend on perl-native.

Correct.

> Howeve, there is a sed replacement in gnu-config-native's do_install:
> -e 's,@autom4te_perllibdir@,${datadir}/autoconf,g

Don't confuse the data files that autoconf installs and references with
a program that is mixing the perl-native binary and libraries with the
host system ones. I think the above change is harmless as its just
linking in some perl files.

> and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is intened
> to be run with "#! /usr/bin/env perl" -- this incurs some race conditions:

This is more problematic though as it does this but also references
perl's full path more directly further in the file. This is the real
problem as its mixing and matching two different perl versions.

> 1) if perl-natvie does populate_sysroot later than
> ${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is used
> but perl-native's modules are used due to the "unshift @INC, $datadir" in 
> gnu-configize.in.
> This is just http://bugzilla.pokylinux.org/show_bug.cgi?id=941
> 2)  if perl-natvie does populate_sysroot earlier than the gnu-configize
> is invokded, we don't meet bug 941.
> 
> The above is the current situation. If we install perl-native into its own
> sysroot, in the gnu-configize, the system perl is always found and used,
> and we always meet with bug 941.

It doesn't matter which perl we use but we do need to use the same perl
consistently.

> How can we fix bug 941 then?
> 
> BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
> eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S 
> "$0" "$@";; esac'
> if 0;
> I'm new to the synax of perl, but I believe the string after the "eval" is
> not executed due to "if 0".
> Can we remove the 2 lines?

I ended up getting some other opinions on this code as it makes no sense
to me either. The best guess I've heard is its allowing the script to
work in shell and perl. I then looked at other autoconf scripts and they
use this same construct so its obviously copied from there. I agree the
style is pointless and we could remove it but it is at least consistent
with the rest of autoconf.

I went digging and was surprised to see many hardcoded paths to perl in
the autoconf scripts. It turns out path_prog_fixes.patch isn't being
applied to autoconf-native, only the target version. When we do apply
it, it turns out the patch is buggy in the native case and I had to
change @bindir@/env to /usr/bin/env to make it work since we don't have
a "env" in the STAGING_BINDIR_NATIVE.

My point is that we need to be consisten

Re: [OE-core] [PATCH] Add support for remote layering.

[Richard Purdie]

Hi Jeremy,

Sorry for the delayed response, I took the opportunity to take some
vacation for a change and its taken me a few days to catch up on email.

Thanks for posting this. Whilst some of what I mention below may sound
negative, its not meant this way and what you have gives a nice basis to
start some discussion from on this topic. I do want to take a step back
and ensure we integrate this functionality at the right level within the
stack. I've made comments below.

On Thu, 2011-04-28 at 11:09 -0700, Jeremy Puhlman wrote:
> The bulk of this patch is based on Chris Larson's collection.inc,
> but refactored for use inside bitbake, and for layers.
> 
> Adds two new configuration options:
> 
> LAYER_UNPACKDIR - directory to unpack downloaded layers for use in 
> configuration.
> LAYER_REMOTE_STASH - location to store downloaded layers for use in 
> configuration.
> 
> Layers can be specified in the current manner:
> BBLAYERS = " \
>/path/to/layer/one \
>/path/to/layer/two \
> "
> 
> Or you can specify uris:
> 
> BBLAYERS = " \
>   http://url.to.my.tarball/tarball.tar.gz \
>   git://gitserver.com/git/repo;proto=http \
> /path/to/layer/three \
> file:///path/to/layer/four \
> "

This is good but what I don't really like about this is that whilst you
can specify where to get the layer from, it isn't clear where the layer
ends up locally. Compare the above to something like:

BBLAYERS = " \
/path/to/layer/one;srcuri=http://url.to.my.tarball/tarball.tar.gz \
/path/to/layer/two;srcuri=git://gitserver.com/git/repo;proto=http \
/path/to/layer/three \
/path/to/layer/four \
"

This is more ugly but it does clearly set an expectation for both where
its coming from and where it ends up on disk. It also means we can then
set specific revisions to checkout or other information e.g. whether the
revisions should auto-increment. The syntax would probably come
naturally to anyone who has used SRC_URI (and hence it also flows nicely
into the fetcher code).

> Currently there is a single layer option, that can be added to a uri, 
> layerBase=.
> This option would be used to specify if a layer starts somewhere other then 
> the base of the
> tarball/scm repository. For example if you wanted to add oe-core you would do:

Ideally this could become an option that any of our fetchers would
support...

>  lib/bb/cooker.py   |3 +-
>  lib/bb/fetch/layer.py  |   65 
>  lib/bb/fetch2/layer.py |   76 ++
>  lib/bb/remotelayer.py  |  197 
> 

I'm not going to dive into the patches at this point but "layer" isn't
really a fetcher as such as it doesn't correspond to a specific source
type, its just a wrapper around other fetch methods. I'm therefore a
little worried this confuses the abstraction we currently have there.

Going back to the high level approach discussion, I'm also wondering if
there should be some "bblayers" tool which gets run prior to bitbake
(maybe automatically in some cases) which handles the parsing of the
BBLAYERS options and does whatever is needed to handle the setup there,
then hands off to bitbake itself.

I'm very keen to get the abstraction level of this code right so I'd be
interested in your (and others) thoughts on this...

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC] systemd units packaging

[Richard Purdie]

On Fri, 2011-05-06 at 15:39 +0200, Koen Kooi wrote:
> Now onto my issues:
> 
> packaging:
>   In OE .dev I added FILES_${PN} += "${base_libdir}/systemd" to udev,
> dbus, rsyslog and avahi. This means we end up with both sysV script
> and systemd units. What I would like to have is ${PN}-sysvinit and
> ${PN}-systemd and the image recipe can choose which init systems gets
> used. Is something like that possible?

I'm not sure that it is to be honest. We simply don't have the
capability in the package managers to be able to say "if systemd is
installed, install *-systemd where * is any currently installed
package". Its the same problem we have with locales.

Now if we had that functionality, great, but we simply don't :(.

>  Are there better ways? Note that systemd support sysV initscripts as
> well, but it needs some care with naming. As I understand it, if a
> unit is found with the same name as a sysV script, only the unit will
> get used.
> A rootfs postprocess command that deletes /etc/init.d won't work,
> since it will come back when upgrading the packages.
> 
> building:
>   At the moment systemd enabled software installs the units regardless
> or config options. What should be do with software that has an option
> for that? And what if we need to patch the units files in? The
> initsystem is a choice at the image level, so artificially limiting it
> to a distro choice is not a good idea.

Its an artificial limit but our tools don't give us any other option,
for now I think this has to be a distro config choice.

> And related to this: how do I get the "installed but not packaged"
> output back? The bitbake logging changes are hiding it now, which is
> counterproductive. 

As others have said, this should be a bb.warn.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] Unable to push to the repository?

[Richard Purdie]

Hi,

It seems something on the server was broken and I'm unable to push to the 
repository:

$ git push origin master:master
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 490 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: sed: can't read ./description: No such file or directory
remote: *** Project description file hasn't been set
remote: error: hook declined to update refs/heads/master
To ssh://g...@git.openembedded.org/openembedded-core
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 
'ssh://g...@git.openembedded.org/openembedded-core'

Any ideas what's wrong?

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Unable to push to the repository?

[Richard Purdie]

On Sat, 2011-05-07 at 01:21 -0700, Khem Raj wrote:
> On Sat, May 7, 2011 at 1:13 AM, Khem Raj  wrote:
> > On Sat, May 7, 2011 at 1:08 AM, Richard Purdie
> >  wrote:
> >> Hi,
> >>
> >> It seems something on the server was broken and I'm unable to push to the 
> >> repository:
> >>
> >> $ git push origin master:master
> >> Counting objects: 9, done.
> >> Delta compression using up to 2 threads.
> >> Compressing objects: 100% (5/5), done.
> >> Writing objects: 100% (5/5), 490 bytes, done.
> >> Total 5 (delta 4), reused 0 (delta 0)
> >> remote: sed: can't read ./description: No such file or directory
> >> remote: *** Project description file hasn't been set
> >> remote: error: hook declined to update refs/heads/master
> >> To ssh://g...@git.openembedded.org/openembedded-core
> >>  ! [remote rejected] master -> master (hook declined)
> >> error: failed to push some refs to 
> >> 'ssh://g...@git.openembedded.org/openembedded-core'
> >>
> >> Any ideas what's wrong?
> >
> > hmmm I added ml hooks but they are same as classic oe so it should
> > have worked but let me see.
> 
> OK I think I used wrong repo name probably that was it. Please retry
> and see if it works

No, still the same error :(

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Unable to push to the repository?

[Richard Purdie]

On Sat, 2011-05-07 at 01:37 -0700, Khem Raj wrote:
> On Sat, May 7, 2011 at 1:24 AM, Richard Purdie
>  wrote:
> > On Sat, 2011-05-07 at 01:21 -0700, Khem Raj wrote:
> >> On Sat, May 7, 2011 at 1:13 AM, Khem Raj  wrote:
> >> > On Sat, May 7, 2011 at 1:08 AM, Richard Purdie
> >> >  wrote:
> >> >> Hi,
> >> >>
> >> >> It seems something on the server was broken and I'm unable to push to 
> >> >> the repository:
> >> >>
> >> >> $ git push origin master:master
> >> >> Counting objects: 9, done.
> >> >> Delta compression using up to 2 threads.
> >> >> Compressing objects: 100% (5/5), done.
> >> >> Writing objects: 100% (5/5), 490 bytes, done.
> >> >> Total 5 (delta 4), reused 0 (delta 0)
> >> >> remote: sed: can't read ./description: No such file or directory
> >> >> remote: *** Project description file hasn't been set
> >> >> remote: error: hook declined to update refs/heads/master
> >> >> To ssh://g...@git.openembedded.org/openembedded-core
> >> >>  ! [remote rejected] master -> master (hook declined)
> >> >> error: failed to push some refs to 
> >> >> 'ssh://g...@git.openembedded.org/openembedded-core'
> >> >>
> >> >> Any ideas what's wrong?
> >> >
> >> > hmmm I added ml hooks but they are same as classic oe so it should
> >> > have worked but let me see.
> >>
> >> OK I think I used wrong repo name probably that was it. Please retry
> >> and see if it works
> >
> > No, still the same error :(
> 
> one more time. Now I have added description files.

It worked this time, thanks.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] package.bbclass: convert unpackaged file message from 'info' to 'warn' so that it shows up on the console

[Richard Purdie]

On Sat, 2011-05-07 at 09:50 -0700, Darren Hart wrote:
> According to my discussion with RP, bb.note() is supposed to appear on
> the console. If it doesn't, that is a bug in bitbake, not the recipe
> logging. I used this information to document the intended use of the
> similarly named bbnote() in logging.bbclass.

What we said was that bb.note from "core" context appears on the
console, bb.note from task context does not as it makes the default
console too verbose.

I'm in agreement that unpackaged files should be a warning.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/20] Consolidated Pull for 5/8/2011

[Richard Purdie]

On Sun, 2011-05-08 at 23:59 -0700, Saul Wold wrote:
> Here is a batch of changes from last week.
> 
> This contains a fix for gnu-config that is a workaround
> for a Bernard Bug that we need to back port.
> 
> I have test built for x86, arm and the toolchains

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 26/30] qmake_base.bbclass: add generate_qt_config_file task

[Richard Purdie]

On Mon, 2011-05-09 at 22:26 -0700, Saul Wold wrote:
> From: Otavio Salvador 
> 
> This writes a qt.conf inside WORKDIR to properly configure projects
> based on CMake. This is required since qmake variables (returned
> by -query command) are fixed into the binary and can only be
> changed using a qt.conf file.
> 
> Signed-off-by: Otavio Salvador 
> ---
>  meta/classes/qmake_base.bbclass |   15 +++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/qmake_base.bbclass b/meta/classes/qmake_base.bbclass
> index 24a0f11..37c44c7 100644
> --- a/meta/classes/qmake_base.bbclass
> +++ b/meta/classes/qmake_base.bbclass
> @@ -31,6 +31,21 @@ oe_qmake_mkspecs () {
>  done
>  }
>  
> +do_generate_qt_config_file() {
> + export QT_CONF_PATH=${WORKDIR}/qt.conf
> + bbwarn "${WORKDIR}/qt.conf"
> + cat > ${WORKDIR}/qt.conf < +[Paths]
> +Prefix = ${STAGING_DIR}
> +Binaries = ${BUILD_SYS}${bindir_native}
> +Headers = ${MACHINE}${prefix}/include/qt4
> +Plugins = ${MACHINE}${prefix}/lib/qt4/plugins/
> +Mkspecs = ${MACHINE}${prefix}/share/qt4/mkspecs/

Can we simplify this to use STAGING_BINDIR_NATIVE, STAGING_INCDIR,
STAGING_LIBDIR and STAGING_DATADIR?

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 25/30] cmake.bbclass: fix qmake and rpath issues

[Richard Purdie]

On Mon, 2011-05-09 at 22:26 -0700, Saul Wold wrote:
> From: Otavio Salvador 
> 
> Sync with OE at 3b7d83362027fde4f6850533ab83277d95dda961 however
> without changing the way of generating the toolchain file and making
> it branding agnostic.
> 
> Signed-off-by: Otavio Salvador 
> ---
>  meta/classes/cmake.bbclass |   19 +--
>  1 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index a4b0c12..ac7bd62 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -24,15 +24,23 @@ OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} 
> ${TOOLCHAIN_OPTIONS} ${TARGET_CPPFLAGS} -f
>  OECMAKE_C_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} -DNDEBUG"
>  OECMAKE_CXX_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} -DNDEBUG"
>  
> +OECMAKE_RPATH ?= ""
> +python __anonymous() {
> +# Only set OECMAKE_RPATH if we build a native recipe
> +if bb.data.inherits_class('native', d) and not 
> bb.data.inherits_class('cross', d):
> +bb.data.setVar('OECMAKE_RPATH', '${libdir}', d)
> +}

Firstly, I don't understand why the "not bb.data.inherits_class('cross',
d)" part of the condition is there as I can't think of a case we inherit
native and cross.

Secondly, can you not just set OECMAKE_RPATH = "${libdir}" in
native.bbclass? I dislike having anonymous python doing simple things we
could do more simply although I can understand the desire to do this in
the same file. Perhaps we should use:

OECMAKE_RPATH = ""
OECMAKE_RPATH_virtclass-native = "${libdir}"

which assumes anything would use BBCLASSEXTEND but we're encouraging
that strongly anyway.

We could unconditionally make native.bbclass set the override too...

Cheers,

Richard


>  cmake_do_generate_toolchain_file() {
>   cat > ${WORKDIR}/toolchain.cmake <  # CMake system name must be something like "Linux".
>  # This is important for cross-compiling.
>  set( CMAKE_SYSTEM_NAME `echo ${SDK_OS} | sed 's/^./\u&/'` )
> +set( CMAKE_SYSTEM_PROCESSOR ${TARGET_ARCH} )
>  set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
>  set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
> -set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "poky CFLAGS" )
> -set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "poky CXXFLAGS" )
> +set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
> +set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
>  set( CMAKE_C_FLAGS_RELEASE "${OECMAKE_C_FLAGS_RELEASE}" CACHE STRING "CFLAGS 
> for release" )
>  set( CMAKE_CXX_FLAGS_RELEASE "${OECMAKE_CXX_FLAGS_RELEASE}" CACHE STRING 
> "CXXFLAGS for release" )
>  
> @@ -43,6 +51,13 @@ set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
>  set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
>  set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
>  
> +# Use qt.conf settings
> +set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
> +
> +# We need to set the rpath to the correct directory as cmake does not 
> provide any
> +# directory as rpath by default
> +set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
> +
>  # Use native cmake modules
>  set( CMAKE_MODULE_PATH ${STAGING_DATADIR}/cmake/Modules/ )
>  EOF



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 13/30] readline: update version

[Richard Purdie]

On Mon, 2011-05-09 at 22:26 -0700, Saul Wold wrote:
> From: Adrian Alonso 
> 
> * Readline new recipe version 6.2
> 
> Signed-off-by: Adrian Alonso 
> ---
>  meta/recipes-core/readline/readline_6.2.bb |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>  create mode 100644 meta/recipes-core/readline/readline_6.2.bb

Why is readline 6.1 being kept?

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/30] conf/layer.conf: Use .= to append to BBPATH and =+ for BBFILES

[Richard Purdie]

On Mon, 2011-05-09 at 22:26 -0700, Saul Wold wrote:
> From: Khem Raj 
> 
> Appending to BBPATH gives a definite order to BBLAYERS which
> means paths are preferred in order from left to right.
> 
> [sgw: merged in comment]
> Signed-off-by: Khem Raj 
> Signed-off-by: Saul Wold 
> ---
>  meta/conf/layer.conf |   10 +-
>  1 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index 3f63c7d..10a6948 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -2,7 +2,15 @@ BBPATH ?= ""
>  # We have a conf and classes directory, add to BBPATH
>  BBPATH .= ":${LAYERDIR}"
>  # We have a packages directory, add to BBFILES
> -BBFILES += "${LAYERDIR}/packages/*/*.bb ${LAYERDIR}/recipes-*/*/*.bb"
> +# packages is still there because metadata_scm.bbclass still uses
> +# it to deduce the repo directory and thats the reason to prepend
> +# to BBFILES here because this class uses the first entry in
> +# BBFILES to calculate the scm base.
> +# since the order of BBFLILES is not that important its acted upon
> +# using BBFILES_PRIORITY we are ok to keep the oe-core BBFILES dir
> +# at top

Er, how about we actually fix metadata_scm.bbclass instead of making the
world more complicated and fragile? :)

I suspect metadata_scm could use the COREBASE variable and be much nicer
code...

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/30] Consolidated Pull Request for 5/10/2011

[Richard Purdie]

On Mon, 2011-05-09 at 22:26 -0700, Saul Wold wrote:
> There is a matching request to poky - master for the kernel
> recipe, please ensure you pull that one also.
> 
> This contains support for the microblaze from Adrian and some 
> uclibc from Khem, along with some changes from Otavio. I passed
> through the insane LICENSE == CLOSED check, but need to think more
> about this (ie we should never see this kind of license in oe-core).

I think its ok to allow handling of it though.

I took most of this and provided feedback on the 4 patches I didn't
take.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/6] bitbake.conf: Include the new default-providers.inc and default-versions.inc files

[Richard Purdie]

From: Richard Purdie 

These are the minimal defaults to allow OE-Core to function standalone with
no distro set and are constucted such that the distro can either override 
values,
or totally replace the include file entirely as needed.

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf|3 +
 meta/conf/distro/include/default-providers.inc|   34 
 meta/conf/distro/include/default-versions.inc |   18 ++
 meta/conf/distro/include/poky-fixed-revisions.inc |   27 -
 meta/conf/distro/poky.conf|   59 +
 5 files changed, 56 insertions(+), 85 deletions(-)
 create mode 100644 meta/conf/distro/include/default-providers.inc
 create mode 100644 meta/conf/distro/include/default-versions.inc
 delete mode 100644 meta/conf/distro/include/poky-fixed-revisions.inc

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 4a1bfa1..d843e70 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -627,6 +627,9 @@ include conf/build/${BUILD_SYS}.conf
 include conf/target/${TARGET_SYS}.conf
 include conf/machine/${MACHINE}.conf
 include conf/machine-sdk/${SDKMACHINE}.conf
+include conf/distro/include/default-providers.inc
+include conf/distro/include/default-versions.inc
+include conf/distro/include/world-broken.inc
 include conf/distro/${DISTRO}.conf
 include conf/documentation.conf
 require conf/sanity.conf
diff --git a/meta/conf/distro/include/default-providers.inc 
b/meta/conf/distro/include/default-providers.inc
new file mode 100644
index 000..d51ac64
--- /dev/null
+++ b/meta/conf/distro/include/default-providers.inc
@@ -0,0 +1,34 @@
+#
+# Default virtual providers
+#
+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/libgl ?= "mesa-xlib"
+PREFERRED_PROVIDER_virtual/update-alternatives ?= "update-alternatives-cworth"
+PREFERRED_PROVIDER_virtual/update-alternatives-native ?= "opkg-native"
+PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
+PREFERRED_PROVIDER_xf86-video-intel ?= "xf86-video-intel"
+
+#
+# Default virtual runtime providers
+#
+VIRTUAL-RUNTIME_update-alternatives ?= "update-alternatives-cworth"
+
+#
+# Default recipe providers
+#
+PREFERRED_PROVIDER_dbus-glib ?= "dbus-glib"
+PREFERRED_PROVIDER_dbus-glib-native ?= "dbus-glib-native"
+PREFERRED_PROVIDER_gconf ?= "gconf-dbus"
+PREFERRED_PROVIDER_gdk-pixbuf ?= "gdk-pixbuf"
+PREFERRED_PROVIDER_libgcc ?= "libgcc"
+PREFERRED_PROVIDER_libgcc-nativesdk ?= "libgcc-nativesdk"
+PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers"
+PREFERRED_PROVIDER_linux-libc-headers-nativesdk ?= 
"linux-libc-headers-nativesdk"
+PREFERRED_PROVIDER_matchbox-panel ?= "matchbox-panel-2"
+PREFERRED_PROVIDER_opkg ?= "opkg"
+PREFERRED_PROVIDER_opkg-native ?= "opkg-native"
+PREFERRED_PROVIDER_opkg-nativesdk ?= "opkg-nativesdk"
+
diff --git a/meta/conf/distro/include/default-versions.inc 
b/meta/conf/distro/include/default-versions.inc
new file mode 100644
index 000..0abbd8f
--- /dev/null
+++ b/meta/conf/distro/include/default-versions.inc
@@ -0,0 +1,18 @@
+#
+# Default preferred versions
+#
+PULSEAUDIOVERSION ?= "0.9.22"
+PULSEAUDIOVERSION_arm ?= "0.9.15"
+PREFERRED_VERSION_pulseaudio ?= "${PULSEAUDIOVERSION}"
+
+# Force the python versions in one place
+PYTHON_BASEVERSION ?= "2.6"
+PREFERRED_VERSION_python ?= "2.6.6"
+PREFERRED_VERSION_python-native ?= "2.6.6"
+
+# Force the older version of liberation-fonts until we fix the fontforge issue
+PREFERRED_VERSION_liberation-fonts ?= "1.04"
+
+
+
+
diff --git a/meta/conf/distro/include/poky-fixed-revisions.inc 
b/meta/conf/distro/include/poky-fixed-revisions.inc
deleted file mode 100644
index 9486080..000
--- a/meta/conf/distro/include/poky-fixed-revisions.inc
+++ /dev/null
@@ -1,27 +0,0 @@
-# Preferred Versions:
-#
-PREFERRED_VERSION_libmatchbox ?= "1.9"
-PREFERRED_VERSION_matchbox-theme-sato ?= "0.1"
-PREFERRED_VERSION_elfutils ?= "0.89"
-PREFERRED_VERSION_hal ?= "0.5.14"
-PREFERRED_VERSION_hal-info ?= "20091130"
-PREFERRED_VERSION_udev ?= "164"
-PREFERRED_VERSION_wpa-supplicant ?= "0.7.3"
-PREFERRED_VERSION_pseudo = "1.0"
-PREFERRED_VERSION_pseudo-native = "1.0"
-
-PULSEAUDIOVERSION ?= "0.9.22"
-PULSEAUDIOVERSION_arm ?= "0.9.15"
-PREFERRED_VERSION_pulseaudio ?= "${PULSEAUDIOVERSION}"
-
-# Force the python versions in one place
-PYTHON_BASEVERSION ?= "2.6"
-PREFERRED_VERSION_python 

[OE-core] [PATCH 4/6] machine/qemu: Add qemu-config as an essential machine speicfic dependency and drop specific distro config

[Richard Purdie]

From: Richard Purdie 

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/poky.conf |7 ---
 meta/conf/machine/include/qemu.inc |1 +
 meta/conf/machine/qemux86-64.conf  |2 +-
 meta/conf/machine/qemux86.conf |2 +-
 4 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/meta/conf/distro/poky.conf b/meta/conf/distro/poky.conf
index f13a67f..3a66a76 100644
--- a/meta/conf/distro/poky.conf
+++ b/meta/conf/distro/poky.conf
@@ -32,13 +32,6 @@ LOCALE_UTF8_ONLY = "0"
 DISTRO_FEATURES = "alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs 
zeroconf pci"
 
 POKY_EXTRA_RDEPENDS = "task-core-boot"
-POKY_EXTRA_RDEPENDS_qemuarm = "qemu-config"
-POKY_EXTRA_RDEPENDS_qemuarmv6 = "qemu-config"
-POKY_EXTRA_RDEPENDS_qemuarmv7 = "qemu-config"
-POKY_EXTRA_RDEPENDS_qemumips = "qemu-config"
-POKY_EXTRA_RDEPENDS_qemuppc = "qemu-config"
-POKY_EXTRA_RDEPENDS_qemux86 = "qemu-config"
-POKY_EXTRA_RDEPENDS_qemux86-64 = "qemu-config"
 
 DISTRO_EXTRA_RDEPENDS += "${POKY_EXTRA_RDEPENDS}"
 DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet"
diff --git a/meta/conf/machine/include/qemu.inc 
b/meta/conf/machine/include/qemu.inc
index 61281bf..bd40983 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -19,3 +19,4 @@ PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 #PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
 
 EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "qemu-config"
diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index 182759a..ca91388 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -30,6 +30,6 @@ XSERVER ?= "xserver-xf86-dri-lite \
 GLIBC_ADDONS = "nptl"
 GLIBC_EXTRA_OECONF = "--with-tls"
 
-MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "v86d"
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
 
 TARGET_CC_ARCH = "-m64"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index f1a0939..8b14731 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -29,6 +29,6 @@ XSERVER ?= "xserver-xf86-dri-lite \
 GLIBC_ADDONS = "nptl"
 GLIBC_EXTRA_OECONF = "--with-tls"
 
-MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "v86d"
+MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
 
 TARGET_CC_ARCH = "-march=i586"
-- 
1.7.4.1


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/6] RFC Distro config changes

[Richard Purdie]

From: Richard Purdie 

As discussed, we want to make OE-Core usable with no distro set. This patch 
series
makes some big steps towards that goal. I'd be interested in feedback on 
whether it
does the right things and would be usable by others.

The key is the inclusion of a distro/defaultsetup.conf file by bitbake.conf and 
in turn this pulls in a variety of other common include files which can likely 
be
shared. Any point of this cycle can be overridden by another layer so its 
totally
customisable. I'd encourage users to use the pieces they can where possible so 
we
all share best practises but obviously people have choice.

I did dump a load of "default" variables into default-distrovars.inc, I'm not
calling that file finished, I just had to draw the line somewhere and start a 
discussion about this :)

Also, I'm aware there are still a few poky-* files in meta/conf/distro/include.
Some of these can just be deleted, others renamed tcmode-* and I'll take care 
of that. I'll also delete the poky.conf file since it no longer contains 
anything
required to make OE-Core build as far as I know (wider testing needed).

Pull URL: git://git.openembedded.org/openembedded-core-contrib
  Branch: rpurdie/distro
  Browse: 
http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/distro

Richard Purdie (6):
  Drop poky-floating-revisions.inc, poky-bleeding.conf and
poky-lsb.conf
  bitbake.conf: Include the new default-providers.inc and
default-versions.inc files
  distro: Add defaultsetup.conf, a set of default configuration
providing sane overrridable default for commonly used options
  machine/qemu: Add qemu-config as an essential machine speicfic
dependency and drop specific distro config
  conf/distro/include/default-distrovars.inc: Create set of default
'distro' variable values
  preferred-xorg-versions.inc: Drop this, it makes no sense given we
only have one version of these recipes

 meta/conf/bitbake.conf |1 +
 meta/conf/distro/defaultsetup.conf |   24 +++
 meta/conf/distro/include/default-distrovars.inc|   41 ++
 meta/conf/distro/include/default-providers.inc |   34 +
 meta/conf/distro/include/default-versions.inc  |   18 +++
 meta/conf/distro/include/poky-fixed-revisions.inc  |   27 
 .../distro/include/poky-floating-revisions.inc |   83 ---
 .../distro/include/preferred-xorg-versions.inc |  150 
 .../include/{poky-eglibc.inc => tclibc-eglibc.inc} |6 +-
 .../include/{poky-glibc.inc => tclibc-glibc.inc}   |6 +-
 .../include/{poky-uclibc.inc => tclibc-uclibc.inc} |4 +
 .../{poky-default.inc => tcmode-default.inc}   |   13 +-
 meta/conf/distro/poky-bleeding.conf|8 -
 meta/conf/distro/poky-lsb.conf |9 --
 meta/conf/distro/poky.conf |  150 ++--
 meta/conf/machine/include/qemu.inc |1 +
 meta/conf/machine/qemux86-64.conf  |2 +-
 meta/conf/machine/qemux86.conf |2 +-
 18 files changed, 149 insertions(+), 430 deletions(-)
 create mode 100644 meta/conf/distro/defaultsetup.conf
 create mode 100644 meta/conf/distro/include/default-distrovars.inc
 create mode 100644 meta/conf/distro/include/default-providers.inc
 create mode 100644 meta/conf/distro/include/default-versions.inc
 delete mode 100644 meta/conf/distro/include/poky-fixed-revisions.inc
 delete mode 100644 meta/conf/distro/include/poky-floating-revisions.inc
 delete mode 100644 meta/conf/distro/include/preferred-xorg-versions.inc
 rename meta/conf/distro/include/{poky-eglibc.inc => tclibc-eglibc.inc} (92%)
 rename meta/conf/distro/include/{poky-glibc.inc => tclibc-glibc.inc} (91%)
 rename meta/conf/distro/include/{poky-uclibc.inc => tclibc-uclibc.inc} (86%)
 rename meta/conf/distro/include/{poky-default.inc => tcmode-default.inc} (85%)
 delete mode 100644 meta/conf/distro/poky-bleeding.conf
 delete mode 100644 meta/conf/distro/poky-lsb.conf

-- 
1.7.4.1


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 5/6] conf/distro/include/default-distrovars.inc: Create set of default 'distro' variable values

[Richard Purdie]

From: Richard Purdie 

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/defaultsetup.conf  |1 +
 meta/conf/distro/include/default-distrovars.inc |   43 
 meta/conf/distro/poky.conf  |   48 +--
 3 files changed, 46 insertions(+), 46 deletions(-)
 create mode 100644 meta/conf/distro/include/default-distrovars.inc

diff --git a/meta/conf/distro/defaultsetup.conf 
b/meta/conf/distro/defaultsetup.conf
index af5ef7b..8da6c0a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -1,5 +1,6 @@
 include conf/distro/include/default-providers.inc
 include conf/distro/include/default-versions.inc
+include conf/distro/include/default-distrovars.inc
 include conf/distro/include/world-broken.inc
 
 TARGET_VENDOR ?= "-oecore"
diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
new file mode 100644
index 000..ab26a30
--- /dev/null
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -0,0 +1,43 @@
+QA_LOGFILE = "${TMPDIR}/qa.log"
+
+IMAGE_ROOTFS_SIZE_ext2 ?= "131072"
+
+OEINCLUDELOGS ?= "yes"
+KERNEL_CONSOLE ?= "ttyS0"
+
+require conf/distro/include/preferred-xorg-versions.inc
+
+PCMCIA_MANAGER ?= "pcmciautils"
+
+IMAGE_LINGUAS ?= "en-us en-gb"
+LIMIT_BUILT_LOCALES ?= "POSIX en_US en_GB"
+ENABLE_BINARY_LOCALE_GENERATION ?= "1"
+LOCALE_UTF8_ONLY ?= "0"
+
+DISTRO_FEATURES ?= "alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs 
zeroconf pci"
+
+DISTRO_EXTRA_RDEPENDS += "task-core-boot"
+DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet"
+
+IMAGE_FEATURES ?= ""
+
+# This is a list of packages that are used by the build system to build the 
distribution, they are not
+# directly part of the distribution. 
+HOSTTOOLS_WHITELIST_GPLv3 ?= ""
+WHITELIST_GPLv3 ?= "less"
+LGPLv2_WHITELIST_GPLv3 ?= "libassuan gnutls libtasn1 libidn libgcc 
gcc-runtime" 
+
+# This is a list of packages that require a commercial license to ship
+# product. If shipped as part of an image these packages may have 
+# implications so they are disabled by default
+COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp"
+COMMERCIAL_AUDIO_PLUGINS ?= ""
+# COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad 
gst-plugins-ugly-mpegaudioparse"
+COMMERCIAL_VIDEO_PLUGINS ?= ""
+# COMMERCIAL_VIDEO_PLUGINS ?= "gst-plugins-ugly-mpeg2dec 
gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
+COMMERCIAL_QT ?= ""
+# COMMERCIAL_QT ?= "qmmp"
+# Set of common licenses used for license.bbclass
+COMMON_LICENSE_DIR ??= "${COREBASE}/meta/files/common-licenses"
+
+BB_GENERATE_MIRROR_TARBALLS ??= "0"
diff --git a/meta/conf/distro/poky.conf b/meta/conf/distro/poky.conf
index 3a66a76..fd0a936 100644
--- a/meta/conf/distro/poky.conf
+++ b/meta/conf/distro/poky.conf
@@ -8,59 +8,13 @@ MAINTAINER = "Poky "
 
 TARGET_VENDOR = "-poky"
 
-QA_LOGFILE = "${TMPDIR}/qa.log"
-
-IMAGE_ROOTFS_SIZE_ext2 ?= "131072"
-
 LOCALCONF_VERSION = "1"
 
-OEINCLUDELOGS = "yes"
-KERNEL_CONSOLE = "ttyS0"
-
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${TARGET_ARCH}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
 
-require conf/distro/include/preferred-xorg-versions.inc
-
-PCMCIA_MANAGER ?= "pcmciautils"
-
-IMAGE_LINGUAS ?= "en-us en-gb"
-LIMIT_BUILT_LOCALES ?= "POSIX en_US en_GB"
-ENABLE_BINARY_LOCALE_GENERATION ?= "1"
-LOCALE_UTF8_ONLY = "0"
-
-DISTRO_FEATURES = "alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs 
zeroconf pci"
-
-POKY_EXTRA_RDEPENDS = "task-core-boot"
-
-DISTRO_EXTRA_RDEPENDS += "${POKY_EXTRA_RDEPENDS}"
-DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet"
-
-IMAGE_FEATURES ?= ""
-
 EXTRAOPKGCONFIG = "poky-feed-config-opkg"
 
-# This is a list of packages that are used by poky to build the distribution, 
they are not
-# directly part of the distribution. 
-HOSTTOOLS_WHITELIST_GPLv3 ?= ""
-WHITELIST_GPLv3 ?= "less"
-LGPLv2_WHITELIST_GPLv3 ?= "libassuan gnutls libtasn1 libidn libgcc 
gcc-runtime" 
-
-# This is a list of packages that require a commercial license to ship
-# product. If shipped as part of an image these packages may have 
-# implications so they are disabled by default
-COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp"
-COMMERCIAL_AUDIO_PLUGINS ?= ""
-# COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad 
gst-plugins-ugly-mpegaudioparse"
-COMMERCIAL_VIDEO_PLUGINS ?= ""
-# COMMERCIAL_VIDEO_PLUGINS ?= "gst-plugins-ug

[OE-core] [PATCH 1/6] Drop poky-floating-revisions.inc, poky-bleeding.conf and poky-lsb.conf

[Richard Purdie]

From: Richard Purdie 

Signed-off-by: Richard Purdie 
---
 .../distro/include/poky-floating-revisions.inc |   83 
 meta/conf/distro/poky-bleeding.conf|8 --
 meta/conf/distro/poky-lsb.conf |9 --
 3 files changed, 0 insertions(+), 100 deletions(-)
 delete mode 100644 meta/conf/distro/include/poky-floating-revisions.inc
 delete mode 100644 meta/conf/distro/poky-bleeding.conf
 delete mode 100644 meta/conf/distro/poky-lsb.conf

diff --git a/meta/conf/distro/include/poky-floating-revisions.inc 
b/meta/conf/distro/include/poky-floating-revisions.inc
deleted file mode 100644
index 22b4c38..000
--- a/meta/conf/distro/include/poky-floating-revisions.inc
+++ /dev/null
@@ -1,83 +0,0 @@
-#
-# Package Versions for cutting edge testing:
-#
-
-SRCREV_pn-exmap-console ?= "${AUTOREV}"
-#SRCREV_pn-opkg-native ?= "${AUTOREV}"
-#SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
-#SRCREV_pn-opkg ?= "${AUTOREV}"
-#SRCREV_pn-opkg-utils-naitve ?= "${AUTOREV}"
-#SRCREV_pn-opkg-utils ?= "${AUTOREV}"
-SRCREV_pn-gconf-dbus ?= "${AUTOREV}"
-SRCREV_pn-contacts ?= "${AUTOREV}"
-SRCREV_pn-dates ?= "${AUTOREV}"
-#SRCREV_pn-gtkhtml2 ?= "${AUTOREV}"
-SRCREV_pn-web ?= "${AUTOREV}"
-SRCREV_pn-eds-dbus ?= "${AUTOREV}"
-SRCREV_pn-matchbox-common ?= "${AUTOREV}"
-SRCREV_pn-matchbox-config-gtk ?= "${AUTOREV}"
-SRCREV_pn-matchbox-desktop ?= "${AUTOREV}"
-SRCREV_pn-matchbox-keyboard ?= "${AUTOREV}"
-SRCREV_pn-matchbox-panel ?= "${AUTOREV}"
-SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"
-SRCREV_pn-matchbox-stroke ?= "${AUTOREV}"
-SRCREV_pn-matchbox-themes-extra ?= "${AUTOREV}"
-SRCREV_pn-matchbox-terminal ?= "${AUTOREV}"
-SRCREV_pn-matchbox-wm ?= "${AUTOREV}"
-SRCREV_pn-matchbox-wm-2 ?= "${AUTOREV}"
-SRCREV_pn-settings-daemon ?= "${AUTOREV}"
-SRCREV_pn-screenshot ?= "${AUTOREV}"
-SRCREV_pn-libfakekey ?= "${AUTOREV}"
-SRCREV_pn-oprofileui ?= "${AUTOREV}"
-SRCREV_pn-zaurusd ?= "${AUTOREV}"
-SRCREV_pn-libowl-av ?= "${AUTOREV}"
-SRCREV_pn-owl-video ?= "${AUTOREV}"
-SRCREV_pn-psplash ?= "${AUTOREV}"
-SRCREV_pn-exmap-console ?= "${AUTOREV}"
-SRCREV_pn-gtk-sato-engine ?= "${AUTOREV}"
-SRCREV_pn-matchbox-theme-sato ?= "${AUTOREV}"
-SRCREV_pn-matchbox-theme-sato-2 ?= "${AUTOREV}"
-SRCREV_pn-tasks ?= "${AUTOREV}"
-SRCREV_pn-sato-icon-theme ?= "${AUTOREV}"
-SRCREV_pn-matchbox-desktop-sato ?= "${AUTOREV}"
-SRCREV_pn-oh-puzzles ?= "${AUTOREV}"
-SRCREV_pn-libowl ?= "${AUTOREV}"
-SRCREV_pn-matchbox-applet-light ?= "${AUTOREV}"
-SRCREV_pn-fstests ?= "${AUTOREV}"
-SRCREV_pn-xvideo-tests ?= "${AUTOREV}"
-SRCREV_pn-clutter ?= "${AUTOREV}"
-SRCREV_pn-clutter-gst ?= "${AUTOREV}"
-SRCREV_pn-gaku ?= "${AUTOREV}"
-SRCREV_pn-gypsy ?= "${AUTOREV}"
-#SRCREV_pn-webkit-gtk ?= "${AUTOREV}"
-SRCREV_pn-aaina ?= "${AUTOREV}"
-SRCREV_pn-clutter-cairo ?= "${AUTOREV}"
-SRCREV_pn-table ?= "${AUTOREV}"
-SRCREV_pn-libmatchbox ?= "${AUTOREV}"
-SRCREV_pn-tasks ?= "${AUTOREV}"
-SRCREV_pn-mutter ?= "${AUTOREV}"
-SRCREV_pn-ofono ?= "${AUTOREV}"
-
-SRCREV_pn-dri2proto = "${AUTOREV}"
-#PREFERRED_VERSION_dri2proto ?= "1.99.1+git${SRCREV}"
-SRCREV_pn-libdrm = "${AUTOREV}"
-#PREFERRED_VERSION_libdrm ?= "2.4.0+git${SRCREV}"
-SRCREV_pn-libxcb = "${AUTOREV}"
-#PREFERRED_VERSION_libxcb ?= "1.1.90.1+gitr${SRCREV}"
-SRCREV_pn-lib-proto = "${AUTOREV}"
-#PREFERRED_VERSION_xcb-proto ?= "1.2+gitr${SRCREV}"
-SRCREV_pn-libxcb-sdk = "${AUTOREV}"
-#PREFERRED_VERSION_libxcb-sdk ?= "1.1.90.1+gitr${SRCREV}"
-SRCREV_pn-xf86-input-evdev = "${AUTOREV}"
-#PREFERRED_VERSION_xf86-input-evdev ?= "2.0.4"
-SRCREV_pn-xf86-input-mouse = "${AUTOREV}"
-#PREFERRED_VERSION_xf86-input-mouse ?= "1.3.0+git${SRCREV}"
-SRCREV_pn-xf86-input-keyboard = "${AUTOREV}"
-#PREFERRED_VERSION_xf86-input-keyboard ?= "1.3.1+git${SRCREV}"
-SRCREV_pn-xf86-input-synaptics = "${AUTOREV}"
-#PREFERRED_VERSION_xf86-input-synaptics ?= "0.15.2+git${SRCREV}"
-
-#SRCDATE_oprofile ?= "${DATE}"
-
-PREFERRED_VERSION_oprofile ?= "0.9.4+cvs${SRCDATE_oprofile}"
-
diff --git a/meta/conf/distro/poky-bleeding.conf 
b/meta/conf/distro/poky-bleeding.conf
deleted file mode 100644
index 328acfe..000
--- a/meta/conf/distro/poky-bleeding.conf
+++ /dev/null
@@ -1,8 +0,0 @@
-PREFERRED_VERSION_glib-2.0 ?= "2.17.4"
-PREFERRED_VERSION_glib-2.0-native ?= "2.1

[OE-core] [PATCH 6/6] preferred-xorg-versions.inc: Drop this, it makes no sense given we only have one version of these recipes

[Richard Purdie]

From: Richard Purdie 

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/default-distrovars.inc|2 -
 .../distro/include/preferred-xorg-versions.inc |  150 
 2 files changed, 0 insertions(+), 152 deletions(-)
 delete mode 100644 meta/conf/distro/include/preferred-xorg-versions.inc

diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
index ab26a30..9b1d0ee 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -5,8 +5,6 @@ IMAGE_ROOTFS_SIZE_ext2 ?= "131072"
 OEINCLUDELOGS ?= "yes"
 KERNEL_CONSOLE ?= "ttyS0"
 
-require conf/distro/include/preferred-xorg-versions.inc
-
 PCMCIA_MANAGER ?= "pcmciautils"
 
 IMAGE_LINGUAS ?= "en-us en-gb"
diff --git a/meta/conf/distro/include/preferred-xorg-versions.inc 
b/meta/conf/distro/include/preferred-xorg-versions.inc
deleted file mode 100644
index da730e6..000
--- a/meta/conf/distro/include/preferred-xorg-versions.inc
+++ /dev/null
@@ -1,150 +0,0 @@
-#
-# The latest Xorg package versions
-#
-
-PREFERRED_VERSION_applewmproto ?= "1.4.1"
-PREFERRED_VERSION_bigreqsproto ?= "1.1.1"
-PREFERRED_VERSION_bigreqsproto-native ?= "1.1.1"
-PREFERRED_VERSION_bigreqsproto-nativesdk ?= "1.1.1"
-PREFERRED_VERSION_compositeproto ?= "0.4.2"
-PREFERRED_VERSION_damageproto ?= "1.2.1"
-PREFERRED_VERSION_dmxproto ?= "2.3.1"
-PREFERRED_VERSION_evieext ?= "1.1.1"
-PREFERRED_VERSION_fixesproto ?= "5.0"
-PREFERRED_VERSION_fontcacheproto ?= "0.1.3"
-PREFERRED_VERSION_fontcacheproto-native ?= "0.1.3"
-PREFERRED_VERSION_fontsproto ?= "2.1.1"
-PREFERRED_VERSION_fontsproto-native ?= "2.1.1"
-PREFERRED_VERSION_gccmakedep ?= "1.0.2"
-PREFERRED_VERSION_glproto ?= "1.4.12"
-PREFERRED_VERSION_imake ?= "1.0.4"
-PREFERRED_VERSION_inputproto ?= "2.0.1"
-PREFERRED_VERSION_inputproto-native ?= "2.0.1"
-PREFERRED_VERSION_inputproto-nativesdk ?= "2.0.1"
-PREFERRED_VERSION_kbproto ?= "1.0.5"
-PREFERRED_VERSION_kbproto-native ?= "1.0.5"
-PREFERRED_VERSION_kbproto-nativesdk ?= "1.0.5"
-PREFERRED_VERSION_libapplewm ?= "1.0.0"
-PREFERRED_VERSION_libdmx ?= "1.1.1"
-PREFERRED_VERSION_libfontenc ?= "1.1.0"
-PREFERRED_VERSION_libfontenc-native ?= "1.1.0"
-PREFERRED_VERSION_libice ?= "1.0.7"
-PREFERRED_VERSION_liblbxutil ?= "1.1.0"
-PREFERRED_VERSION_liboldx ?= "1.0.1"
-PREFERRED_VERSION_libsm ?= "1.2.0"
-PREFERRED_VERSION_libwindowswm ?= "1.0.0"
-PREFERRED_VERSION_libx11 ?= "1.3.4"
-PREFERRED_VERSION_libx11-diet ?= "1.3"
-PREFERRED_VERSION_libx11-native ?= "1.3.4"
-PREFERRED_VERSION_libx11-nativesdk ?= "1.3.4"
-PREFERRED_VERSION_libx11-trim ?= "1.3.4"
-PREFERRED_VERSION_libxau ?= "1.0.6"
-PREFERRED_VERSION_libxau-native ?= "1.0.6"
-PREFERRED_VERSION_libxau-nativesdk ?= "1.0.6"
-PREFERRED_VERSION_libxaw ?= "1.0.5"
-PREFERRED_VERSION_libxcomposite ?= "0.4.3"
-PREFERRED_VERSION_libxcursor ?= "1.1.11"
-PREFERRED_VERSION_libxdamage ?= "1.1.3"
-PREFERRED_VERSION_libxdmcp ?= "1.1.0"
-PREFERRED_VERSION_libxdmcp-native ?= "1.1.0"
-PREFERRED_VERSION_libxdmcp-nativesdk ?= "1.1.0"
-PREFERRED_VERSION_libxevie ?= "1.0.2"
-PREFERRED_VERSION_libxext ?= "1.2.0"
-PREFERRED_VERSION_libxext-nativesdk ?= "1.2.0"
-PREFERRED_VERSION_libxfixes ?= "5.0"
-PREFERRED_VERSION_libxfont ?= "1.4.3"
-PREFERRED_VERSION_libxfont-native ?= "1.4.3"
-PREFERRED_VERSION_libxfontcache ?= "1.0.5"
-PREFERRED_VERSION_libxft ?= "2.2.0"
-PREFERRED_VERSION_libxi ?= "1.4.2"
-PREFERRED_VERSION_libxinerama ?= "1.1.1"
-PREFERRED_VERSION_libxkbfile ?= "1.0.7"
-PREFERRED_VERSION_libxkbui ?= "1.0.2"
-PREFERRED_VERSION_libxmu ?= "1.1.0"
-PREFERRED_VERSION_libxp ?= "1.0.1"
-PREFERRED_VERSION_libxpm ?= "3.5.9"
-PREFERRED_VERSION_libxprintapputil ?= "1.0.1"
-PREFERRED_VERSION_libxprintutil ?= "1.0.1"
-PREFERRED_VERSION_libxrandr ?= "1.3.1"
-PREFERRED_VERSION_libxrandr-nativesdk ?= "1.3.1"
-PREFERRED_VERSION_libxrender ?= "0.9.6"
-PREFERRED_VERSION_libxrender-nativesdk ?= "0.9.6"
-PREFERRED_VERSION_libxres ?= "1.0.5"
-PREFERRED_VERSION_libxscrnsaver ?= "1.2.1"
-PREFERRED_VERSION_libxt ?= "1.1.1"
-PREFERRED_VERSION_libxtrap ?= "1.0.0"
-PREFERRED_VERSION_libxtst ?= "1.2.0"
-PREFERRED_VERSION_libxv ?= "1.0.6"
-PREFERRED_VERSION_libxvmc ?= "1.0

[OE-core] [PATCH 3/6] distro: Add defaultsetup.conf, a set of default configuration providing sane overrridable default for commonly used options

[Richard Purdie]

From: Richard Purdie 

The intent is to allow distros to share common core config but still allow
customisations. The core should work with no distro set but users
can still customise in any ways needed.

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf |4 +-
 meta/conf/distro/defaultsetup.conf |   23 ++
 .../include/{poky-eglibc.inc => tclibc-eglibc.inc} |6 ++-
 .../include/{poky-glibc.inc => tclibc-glibc.inc}   |6 ++-
 .../include/{poky-uclibc.inc => tclibc-uclibc.inc} |4 ++
 .../{poky-default.inc => tcmode-default.inc}   |   13 +++---
 meta/conf/distro/poky.conf |   46 +--
 7 files changed, 54 insertions(+), 48 deletions(-)
 create mode 100644 meta/conf/distro/defaultsetup.conf
 rename meta/conf/distro/include/{poky-eglibc.inc => tclibc-eglibc.inc} (92%)
 rename meta/conf/distro/include/{poky-glibc.inc => tclibc-glibc.inc} (91%)
 rename meta/conf/distro/include/{poky-uclibc.inc => tclibc-uclibc.inc} (86%)
 rename meta/conf/distro/include/{poky-default.inc => tcmode-default.inc} (85%)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d843e70..ce74a9b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -627,9 +627,7 @@ include conf/build/${BUILD_SYS}.conf
 include conf/target/${TARGET_SYS}.conf
 include conf/machine/${MACHINE}.conf
 include conf/machine-sdk/${SDKMACHINE}.conf
-include conf/distro/include/default-providers.inc
-include conf/distro/include/default-versions.inc
-include conf/distro/include/world-broken.inc
+include conf/distro/defaultsetup.conf
 include conf/distro/${DISTRO}.conf
 include conf/documentation.conf
 require conf/sanity.conf
diff --git a/meta/conf/distro/defaultsetup.conf 
b/meta/conf/distro/defaultsetup.conf
new file mode 100644
index 000..af5ef7b
--- /dev/null
+++ b/meta/conf/distro/defaultsetup.conf
@@ -0,0 +1,23 @@
+include conf/distro/include/default-providers.inc
+include conf/distro/include/default-versions.inc
+include conf/distro/include/world-broken.inc
+
+TARGET_VENDOR ?= "-oecore"
+
+TARGET_FPU_arm ?= "soft"
+TARGET_FPU_armeb ?= "soft"
+
+TCMODE ?= "default"
+require conf/distro/include/tcmode-${TCMODE}.inc
+
+TCLIBC ?= "eglibc"
+require conf/distro/include/tclibc-${TCLIBC}.inc
+
+CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + 
str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d, 
1))]}${@['', '/' + str(bb.data.getVar('SDKMACHINE', d, 
1))][bool(bb.data.getVar('SDKMACHINE', d, 1))]}"
+
+USER_CLASSES ?= ""
+PACKAGE_CLASSES ?= "package_ipk"
+INHERIT_INSANE ?= "insane"
+INHERIT_DISTRO ?= "debian devshell sstate license"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_INSANE} 
${INHERIT_DISTRO}"
+
diff --git a/meta/conf/distro/include/poky-eglibc.inc 
b/meta/conf/distro/include/tclibc-eglibc.inc
similarity index 92%
rename from meta/conf/distro/include/poky-eglibc.inc
rename to meta/conf/distro/include/tclibc-eglibc.inc
index 3d2c362..16625e3 100644
--- a/meta/conf/distro/include/poky-eglibc.inc
+++ b/meta/conf/distro/include/tclibc-eglibc.inc
@@ -2,6 +2,10 @@
 # eglibc specific configuration
 #
 
+TARGET_OS = "linux"
+TARGET_OS_arm = "linux-gnueabi"
+TARGET_OS_armeb = "linux-gnueabi"
+
 # Add glibc overrides to the overrides for eglibc.
 OVERRIDES .= ":libc-glibc"
 
@@ -17,8 +21,6 @@ PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= 
"eglibc-nativesdk"
 PREFERRED_PROVIDER_virtual/libc-nativesdk ?= "eglibc-nativesdk"
 PREFERRED_PROVIDER_virtual/${SDK_PREFIX}libc-initial-nativesdk ?= 
"eglibc-initial-nativesdk"
 
-TARGET_OS = "${GLIBCTARGETOS}"
-
 CXXFLAGS += "-fvisibility-inlines-hidden"
 
 LIBC_DEPENDENCIES = "libsegfault \
diff --git a/meta/conf/distro/include/poky-glibc.inc 
b/meta/conf/distro/include/tclibc-glibc.inc
similarity index 91%
rename from meta/conf/distro/include/poky-glibc.inc
rename to meta/conf/distro/include/tclibc-glibc.inc
index 4be7122..79da986 100644
--- a/meta/conf/distro/include/poky-glibc.inc
+++ b/meta/conf/distro/include/tclibc-glibc.inc
@@ -2,6 +2,10 @@
 # glibc specific configuration
 #
 
+TARGET_OS = "linux"
+TARGET_OS_arm = "linux-gnueabi"
+TARGET_OS_armeb = "linux-gnueabi"
+
 # Add glibc to the overrides.
 OVERRIDES =. "libc-glibc:"
 
@@ -16,8 +20,6 @@ PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= 
"glibc-nativesdk"
 PREFERRED_PROVIDER_virtual/libc-nativesdk ?= "glibc-nativesdk"
 PREFERRED_PROVIDER_virtual/${SDK_PREFIX}libc-initial-nativesdk ?= 
"glibc-initial-nativesdk"
 
-TARGET_OS = "${GLIBCTARGETOS}"
-
 CXXFLAGS += "-fvisibility-inlines-hidden

Re: [OE-core] [PATCH 0/6] RFC Distro config changes

[Richard Purdie]

On Tue, 2011-05-10 at 16:05 +0200, Frans Meulenbroeks wrote:
> > Pull URL: git://git.openembedded.org/openembedded-core-contrib
> >  Branch: rpurdie/distro
> >  Browse:
> > http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/distro
> >
> 
> THere is something wrong with git.
> If I browse to the 2nd url I get:
> Bad object id: rpurdie/distro
> going to git and navigating to the branch gives the same result.
> 
>  Anyway, although I am not able to review the changes on git, a thumbs up
> for the initiative.

I've noticed this happening with branches on that repository for the
past couple of days, its not just this branch.

Khem/Cliff/Tom: Who might be able to look into and help fix this?

Frans: You can still checkout the branch and look, its just the web
interface that has issues.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native

[Richard Purdie]

On Tue, 2011-05-10 at 22:02 +0800, Cui, Dexuan wrote:
> > or we hardcode to /usr/bin/perl. Since the perl-native binary won't be
> > in the path for any of these, autodetecting and letting it hardcode is
> > probably fine. It has the advantage that if there are any binary
> > modules ever involved, they'll match the version of perl they were
> > built for regardless of whether perl-native is a dependency or not.
> > If someone adds a perl-native dependency to autoconf-native, it will
> > also still select the "correct" perl.
> > 
> > Whilst doing this we need to keep bug #968 in mind and ensure that if
> > perl-native is used, all of perl-native is in the sysroot. That bug is
> > where the perl binary was installed, the library was not and an error
> > occurred. If it is in its own directory which is only added to the
> > PATH for users with the correct dependency, we avoid this.
> > 
> > As for bug #941, the bottom line is that however autoconf-native
> > selects its perl version, the strings encoded in gnu-config should
> > really match those in the other autoconf-native scripts.
> I saw a commit that was once suspended was pushed into poky
> master yesterday:
> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=605141a93443df042634b2219a8628a9004be023
> Actually it does fix(or at least workaround) bug #941 and bug #968.
> 
> Looks there are much work to do if we install perl-native to its own sysroot.
> At present we can use the above commit as a workaround.

Its merged as a workaround but I still think we need to clean this up
properly and we need to continue working on it.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/30] conf/layer.conf: Use .= to append to BBPATH and =+ for BBFILES

[Richard Purdie]

On Tue, 2011-05-10 at 10:56 -0700, Chris Larson wrote:
> On Tue, May 10, 2011 at 1:54 AM, Richard Purdie
>  wrote:
> > Er, how about we actually fix metadata_scm.bbclass instead of making the
> > world more complicated and fragile? :)
> >
> > I suspect metadata_scm could use the COREBASE variable and be much nicer
> > code...
> 
> I'd really like to see it gather information about the current state
> of all layers which are scm working copies and summarize this in the
> build summary, rather than grabbing one specific bit of information,
> personally.

I'd also agree with this and have said as much somewhere (layer tooling
discussions?) but I'll take the COREBASE change short term.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Pull request with misc changes

[Richard Purdie]

On Tue, 2011-05-10 at 11:33 -0700, Tom Rini wrote:
> On 05/10/2011 11:13 AM, Martin Jansa wrote:
> > I'm using slightly modified script for pull requests from gitorious.
> > 
> > send-pull-request are the same as long as you use git send-email and
> > have sendemail.to defined in repo.
> > 
> > To modify it for github is as simple as this I guess.
> > 
> > $ diff -uNr shr-core/openembedded-core/scripts/create-pull-request 
> > ~/bin/meta-efl-create-pull-request 
> > --- shr-core/openembedded-core/scripts/create-pull-request 2011-04-04 
> > 09:35:47.973626385 +0200
> > +++ /OE/bin/meta-efl-create-pull-request2011-05-10 
> > 13:33:20.349688815 +0200
> > @@ -2,9 +2,11 @@
> >  ODIR=pull-$$
> >  RELATIVE_TO="master"
> >  COMMIT_ID="HEAD"
> > -PULL_URL="git://git.openembedded.org/openembedded-core-contrib"
> > -WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=";
> > -PREFIX="PATCH"
> > +#PULL_URL="git://git.openembedded.org/meta-openembedded-contrib"
> > +#WEB_URL_PREFIX="http://git.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=";
> > +PULL_URL="git://gitorious.org/shr/meta-openembedded.git"
> > +WEB_URL_PREFIX="http://gitorious.org/shr/meta-openembedded/commits/";
> > +PREFIX="meta-efl][PATCH"
> >  
> >  usage() {
> >  CMD=$(basename $0)
> 
> Hmmm.  I'm going to take a stab at making this a create-pull-request
> option...

Martin/Tom: Serious question - why not use the contrib repo for this?

I have nightmares about all the development being spread to all the
corners of the globe and people not being able to see what is being
worked on. For short lived branches its not so much of a problem but as
we take on longer lived feature development it will be a problem. I'd
therefore like to understand why the dislike of it...

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Pull request with misc changes

[Richard Purdie]

On Tue, 2011-05-10 at 16:15 -0300, Otavio Salvador wrote:
> On Tue, May 10, 2011 at 16:03, Richard Purdie
>  wrote:
> >> Hmmm.  I'm going to take a stab at making this a create-pull-request
> >> option...
> >
> > Martin/Tom: Serious question - why not use the contrib repo for this?
> >
> > I have nightmares about all the development being spread to all the
> > corners of the globe and people not being able to see what is being
> > worked on. For short lived branches its not so much of a problem but as
> > we take on longer lived feature development it will be a problem. I'd
> > therefore like to understand why the dislike of it...
> 
> Welcome to Distribute Source Control Management World; this is the
> beauty of it and I see no reason to restrict or enforce people to use
> a repository.

Nobody wants to force anyone. I just asked for the reasons why people
weren't using it as if there was anything we could fix, we could look
into it.

> In my personal case we have been using GitHub as a central place to
> put projects that O.S. Systems is contributing and this is good to
> gather us some visibility so OE will be there too.
> 
> So I won't use contrib to share patches. I can send them to mailing
> list (as I have been doing). A merge on a topic branch is a git pull
> command from you so I see not much problem for you or whom is doing
> the pull job.
> 
> As an example:
> 
>  git checkout -b otavio-20110510-review
>  git pull git://github.com/OSSystems/oe-core.git master
>  git shortlog origin/master..
> 
> Is that so difficult?

I didn't say it was difficult ;-).

Thanks for answering the question, there is little we can do to change
your reasons for what you do and that's fine. I've ensured we're not
doing something that forces you elsewhere at least.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/6] conf/distro/include/default-distrovars.inc: Create set of default 'distro' variable values

[Richard Purdie]

On Tue, 2011-05-10 at 16:26 +0200, Frans Meulenbroeks wrote:
> Some minor remarks on the default-distrovars.inc contents:

To quote the email prefacing this patch series:

"""
I did dump a load of "default" variables into default-distrovars.inc,
I'm not calling that file finished, I just had to draw the line
somewhere and start a discussion about this :)
"""

but we can have this discussion.

> 2011/5/10 Richard Purdie 
> [...]
> 
> > diff --git a/meta/conf/distro/include/default-distrovars.inc
> > b/meta/conf/distro/include/default-distrovars.inc
> > new file mode 100644
> > index 000..ab26a30
> > --- /dev/null
> > +++ b/meta/conf/distro/include/default-distrovars.inc
> > @@ -0,0 +1,43 @@
> > +QA_LOGFILE = "${TMPDIR}/qa.log"
> >
> Should this be here? I would expect the class file that uses this to have
> this as default and/or have this in local.conf.sample.
> This does not seem too distro specific

If this is unset, the logfile isn't generated at all with the current
defaults. I don't claim the current defaults are correct but its a
separate patch if we do want to change the defaults.

> > +
> > +IMAGE_ROOTFS_SIZE_ext2 ?= "131072"
> >
> Hm, again something that is probalby not distro related. And why only for
> _ext2 and not eg for _ext3 or for _jffs2
> Personally I always stuff this in my image recipe

Left there pending a review of where various image sizes are set.

> > +
> > +OEINCLUDELOGS ?= "yes"
> >
> in local.conf.sample?

If its there, this can be dropped, yes. I think forcing it on by default
may be a good thing though. I'm not 100% sure that variable even still
exists tbh.

> > +KERNEL_CONSOLE ?= "ttyS0"
> >
> I'm inclined to put this into the machine conf. Is this really a distro
> thing?

No, left for compatibility pending cleanup.

> > +
> > +require conf/distro/include/preferred-xorg-versions.inc
> > +
> > +PCMCIA_MANAGER ?= "pcmciautils"
> > +
> > +IMAGE_LINGUAS ?= "en-us en-gb"
> > +LIMIT_BUILT_LOCALES ?= "POSIX en_US en_GB"
> > +ENABLE_BINARY_LOCALE_GENERATION ?= "1"
> > +LOCALE_UTF8_ONLY ?= "0"
> >
> Again something I tend to do in image recipes; then again this might be
> because I do not use feeds, only make images.

These ones are more distro policy and whilst an image can change them a
default is good in those cases. If there are defaults set elsewhere we
should review and pick the correct ones.

> > +DISTRO_FEATURES ?= "alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi
> > nfs zeroconf pci"
> >
> Is this the complete range? I would expect all features to be enabled by
> default (and let MACHINE_FEATURES reduce that set)

Needs further investigation.

> > +
> > +DISTRO_EXTRA_RDEPENDS += "task-core-boot"
> > +DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet"
> > +
> > +IMAGE_FEATURES ?= ""
> >
> Has a var with ?= assignment of an empty string any meaning. Thought an
> empty string would be the default.

No, its not.

> > +
> > +# This is a list of packages that are used by the build system to build
> > the distribution, they are not
> > +# directly part of the distribution.
> > +HOSTTOOLS_WHITELIST_GPLv3 ?= ""
> > +WHITELIST_GPLv3 ?= "less"
> >
> I'm not sure why less is listed in the line above:
> the less license is not gpl (at least not less 443)
> 
> 
> > +LGPLv2_WHITELIST_GPLv3 ?= "libassuan gnutls libtasn1 libidn libgcc
> > gcc-runtime"
> > +
> > +# This is a list of packages that require a commercial license to ship
> > +# product. If shipped as part of an image these packages may have
> > +# implications so they are disabled by default
> > +COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp"
> > +COMMERCIAL_AUDIO_PLUGINS ?= ""
> > +# COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad
> > gst-plugins-ugly-mpegaudioparse"
> > +COMMERCIAL_VIDEO_PLUGINS ?= ""
> > +# COMMERCIAL_VIDEO_PLUGINS ?= "gst-plugins-ugly-mpeg2dec
> > gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
> > +COMMERCIAL_QT ?= ""
> > +# COMMERCIAL_QT ?= "qmmp"
> > +# Set of common licenses used for license.bbclass
> > +COMMON_LICENSE_DIR ??= "${COREBASE}/meta/files/common-licenses"
> >
> maybe the above could be in a separate license.inc file or so.

Possibly, setting these to defaults is good though.

> > +
> > +BB_GENERATE_MIRROR_TARBALLS ??= "0"
> >
> local.conf.sample ?

I regard local.conf.sample as things a new user cares about. I don't
think this fits that category. Its here pending the creation of a more
"advanced settings" version of local.conf.sample we've talked about
being created.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] Do not depend on BBFILES to compute scm dirs

[Richard Purdie]

On Tue, 2011-05-10 at 21:35 -0700, Khem Raj wrote:
> This fixes the problem that I described in 
> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/001966.html
> 
> Additionally we do not need directories with */packages/* in BBFILES
> anymore
> 
> Pull URL: git://git.openembedded.org/openembedded-core-contrib
>   Branch: kraj/misc-fixes
>   Browse: 
> http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/misc-fixes
> 
> Thanks,
> Khem Raj 
> ---
> 
> 
> Khem Raj (2):
>   metadata_scm.bbclass: Use COREBASE to grok for SCM operations
>   meta/conf/layer.conf: Remove packages/*bb from BBFILES

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] conf/bitbake.conf: use --no-check-certificate to avoid errors when wgetting from https

[Richard Purdie]

On Tue, 2011-05-10 at 23:30 -0700, Khem Raj wrote:
> From: Otavio Salvador 
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/conf/bitbake.conf |8 
>  1 files changed, 4 insertions(+), 4 deletions(-)

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/6] bitbake.conf: Include the new default-providers.inc and default-versions.inc files

[Richard Purdie]

On Tue, 2011-05-10 at 16:20 +0200, Koen Kooi wrote:
> Op 10 mei 2011, om 16:00 heeft Richard Purdie het volgende geschreven:
> 
> > From: Richard Purdie 
> > 
> > These are the minimal defaults to allow OE-Core to function standalone with
> > no distro set and are constucted such that the distro can either override 
> > values,
> > or totally replace the include file entirely as needed.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> > meta/conf/bitbake.conf|3 +
> > meta/conf/distro/include/default-providers.inc|   34 
> > meta/conf/distro/include/default-versions.inc |   18 ++
> > meta/conf/distro/include/poky-fixed-revisions.inc |   27 -
> > meta/conf/distro/poky.conf|   59 
> > +
> > 5 files changed, 56 insertions(+), 85 deletions(-)
> > create mode 100644 meta/conf/distro/include/default-providers.inc
> > create mode 100644 meta/conf/distro/include/default-versions.inc
> > delete mode 100644 meta/conf/distro/include/poky-fixed-revisions.inc
> > 
> 
> > diff --git a/meta/conf/distro/include/default-providers.inc 
> > b/meta/conf/distro/include/default-providers.inc
> > new file mode 100644
> > index 000..d51ac64
> > --- /dev/null
> > +++ b/meta/conf/distro/include/default-providers.inc
> > @@ -0,0 +1,34 @@
> > 
> > +PREFERRED_PROVIDER_gconf ?= "gconf-dbus"
> 
> the dbus port has long been merged upstream, so proper gconf would be
> a better choice. We could ignore it and just use dconf in meta-gnome,
> though ;)

I agree we should be using gconf, could someone send me the recipe
though? ;-).

> > +PREFERRED_PROVIDER_opkg ?= "opkg"
> 
> We should sync with OE and drop the ssl/gpg stuff noone seems to be
> using.

You mean disable ssl/gpg in all cases?

> > diff --git a/meta/conf/distro/include/default-versions.inc 
> > b/meta/conf/distro/include/default-versions.inc
> > new file mode 100644
> > index 000..0abbd8f
> > --- /dev/null
> > +++ b/meta/conf/distro/include/default-versions.inc
> > @@ -0,0 +1,18 @@
> > +#
> > +# Default preferred versions
> > +#
> > +PULSEAUDIOVERSION ?= "0.9.22"
> > +PULSEAUDIOVERSION_arm ?= "0.9.15"
> > +PREFERRED_VERSION_pulseaudio ?= "${PULSEAUDIOVERSION}
> 
> AIUI 0.9.15 is the last version that doesn't need atomic ops. In OE we
> backported the necessary bits to gcc 4.3.x, gcc 4.5.x already has
> them. So lets drop the _arm override or atleast document why.

If we don't need 0.9.15, lets get rid of it...

> > +# Force the python versions in one place
> > +PYTHON_BASEVERSION ?= "2.6"
> > +PREFERRED_VERSION_python ?= "2.6.6"
> > +PREFERRED_VERSION_python-native ?= "2.6.6"
> 
> Not really related, but update to 2.7.x?

Sure. Patches welcome :)

Just to be clear, these are a reflection of what is in OECore today.
These things are good imrovements and  I'm more than happy to change or
remove these entries as needed but they're all further standalone
changes in their own right so I'm not going to hold the patch series on
them.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Pull request with misc changes

[Richard Purdie]

On Tue, 2011-05-10 at 22:24 +0200, Martin Jansa wrote:
> On Tue, May 10, 2011 at 08:03:57PM +0100, Richard Purdie wrote:
> > Martin/Tom: Serious question - why not use the contrib repo for this?
> 
> I have nothing against contrib repo and I'm using oe-core-contrib for
> oe-core stuff, but I had gitorious repos for meta-oe before
> meta-oe-contrib was created and now I didn't feel the need to change it
> and update my modified meta-oe-create-pull-request header :) but I will
> if you or koen find it better to pull from *-contrib (I'm pushing shr
> branch there already anyways).

I have a habit of using the cgit web interface to visualise patches so
using the contrib repo does help me a little. As you say, you're using
oe-core-contrib though so thats fine :)

FWIW, I find the gitorious web interface extremely painful to the point
of being unusable to get the information I want from it. Could just be
me but I have to pull trees somewhere else to look at them I find it
that painful.

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/6] distro: Add defaultsetup.conf, a set of default configuration providing sane overrridable default for commonly used options

[Richard Purdie]

On Tue, 2011-05-10 at 16:31 +0200, Koen Kooi wrote:
> Op 10 mei 2011, om 16:00 heeft Richard Purdie het volgende geschreven:
> 
> > From: Richard Purdie 
> > 
> > The intent is to allow distros to share common core config but still allow
> > customisations. The core should work with no distro set but users
> > can still customise in any ways needed.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> > meta/conf/bitbake.conf |4 +-
> > meta/conf/distro/defaultsetup.conf |   23 ++
> > .../include/{poky-eglibc.inc => tclibc-eglibc.inc} |6 ++-
> > .../include/{poky-glibc.inc => tclibc-glibc.inc}   |6 ++-
> > .../include/{poky-uclibc.inc => tclibc-uclibc.inc} |4 ++
> > .../{poky-default.inc => tcmode-default.inc}   |   13 +++---
> > meta/conf/distro/poky.conf |   46 
> > +--
> > 7 files changed, 54 insertions(+), 48 deletions(-)
> > create mode 100644 meta/conf/distro/defaultsetup.conf
> > rename meta/conf/distro/include/{poky-eglibc.inc => tclibc-eglibc.inc} (92%)
> > rename meta/conf/distro/include/{poky-glibc.inc => tclibc-glibc.inc} (91%)
> > rename meta/conf/distro/include/{poky-uclibc.inc => tclibc-uclibc.inc} (86%)
> > rename meta/conf/distro/include/{poky-default.inc => tcmode-default.inc} 
> > (85%)
> > 
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index d843e70..ce74a9b 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -627,9 +627,7 @@ include conf/build/${BUILD_SYS}.conf
> > include conf/target/${TARGET_SYS}.conf
> > include conf/machine/${MACHINE}.conf
> > include conf/machine-sdk/${SDKMACHINE}.conf
> > -include conf/distro/include/default-providers.inc
> > -include conf/distro/include/default-versions.inc
> > -include conf/distro/include/world-broken.inc
> > +include conf/distro/defaultsetup.conf
> > include conf/distro/${DISTRO}.conf
> 
> Please include it after $DISTRO, otherwise ?= in $DISTRO won't work as 
> intended.

Fixed, thanks.


> > include conf/documentation.conf
> > require conf/sanity.conf
> > diff --git a/meta/conf/distro/defaultsetup.conf 
> > b/meta/conf/distro/defaultsetup.conf
> > new file mode 100644
> > index 000..af5ef7b
> > --- /dev/null
> > +++ b/meta/conf/distro/defaultsetup.conf
> > @@ -0,0 +1,23 @@
> > +include conf/distro/include/default-providers.inc
> > +include conf/distro/include/default-versions.inc
> > +include conf/distro/include/world-broken.inc
> > +
> > +TARGET_VENDOR ?= "-oecore"
> > +
> > +TARGET_FPU_arm ?= "soft"
> > +TARGET_FPU_armeb ?= "soft"
> 
> Something more elaborate would be better, this is what angstrom has:
> 
> conf/distro/include/angstrom.inc:TARGET_FPU_arm = "soft"
> conf/distro/include/angstrom.inc:TARGET_FPU_armeb = "soft"
> conf/distro/include/angstrom.inc:TARGET_FPU_ixp4xx = "soft"
> conf/distro/include/angstrom.inc:TARGET_FPU_ppc405 = "soft"
> conf/distro/include/angstrom.inc:TARGET_FPU_armv6 = "hard"
> conf/distro/include/angstrom.inc:TARGET_FPU_armv6-novfp = "soft"
> conf/distro/include/angstrom.inc:TARGET_FPU_armv7a = "hard"
> conf/distro/include/angstrom.inc:TARGET_FPU_ppc603e = "hard"
> 
> you really want to use hard (don't confuse it with hardfp) on armv7a.

Agreed but we have a problem here as the default OVERRIDES in OECore
don't include BASE_PACKAGE_ARCH. I'm kind of reluctant to do so too as
the number of cases we need this are small and the strings aren't very
unique. I'b feel happier if the override was something like
parch-${BASE_PACKAGE_ARCH} as you could at least easily spot where it
was being used.

I appreciate we need to do something here, its just a question of what.

> > --- a/meta/conf/distro/include/poky-eglibc.inc
> > +++ b/meta/conf/distro/include/tclibc-eglibc.inc
> > @@ -2,6 +2,10 @@
> > # eglibc specific configuration
> > #
> > 
> > +TARGET_OS = "linux"
> > +TARGET_OS_arm = "linux-gnueabi"
> > +TARGET_OS_armeb = "linux-gnueabi"
> 
> Maybe something like angstroms version:
> 
> TARGET_OS = "linux"
> TARGET_OS .= "${@['','-gnueabi'][bb.data.getVar('TARGET_ARCH',d,1) in ['arm', 
> 'armeb']]}"
> TARGET_OS .= "${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in 
> ['ppce500', &#x

Re: [OE-core] [PATCH 0/6] RFC Distro config changes

[Richard Purdie]

On Tue, 2011-05-10 at 17:58 +0200, Koen Kooi wrote:
> Op 10 mei 2011, om 16:00 heeft Richard Purdie het volgende geschreven:
> 
> > From: Richard Purdie 
> > 
> > As discussed, we want to make OE-Core usable with no distro set. This patch 
> > series
> > makes some big steps towards that goal. I'd be interested in feedback on 
> > whether it
> > does the right things and would be usable by others.
> > 
> > The key is the inclusion of a distro/defaultsetup.conf file by bitbake.conf 
> > and 
> > in turn this pulls in a variety of other common include files which can 
> > likely be
> > shared. Any point of this cycle can be overridden by another layer so its 
> > totally
> > customisable. I'd encourage users to use the pieces they can where possible 
> > so we
> > all share best practises but obviously people have choice.
> > 
> > I did dump a load of "default" variables into default-distrovars.inc, I'm 
> > not
> > calling that file finished, I just had to draw the line somewhere and start 
> > a 
> > discussion about this :)
> 
> For angstrom we had to change a few things, have a look at
> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-angstrom/tree/conf/distro/include/angstrom-core-tweaks.inc
>  , specifically lines 12-18 and 53-54

I don't understand what TOOLCHAIN_PATH and TOOLCHAIN_SYSPATH do, I can't
find any reference to them in OECore. For the uclibc bits, I'm proposing
to add:

+DEPLOY_DIR_append = "-uclibc"
+STAGING_DIR_TARGET_append = "-uclibc"
+STAGING_DIR_HOST_append = "-uclibc"
+SSTATE_MANIFESTS_append = "-uclibc"

to tclibc-uclibc.inc.

For the SDK/TOOLCHAIN bits, I need to have a close look at the SDK and
figure out what the implications are there as I want to ensure that they
can all be parallel installed as well as being in separate tarballs but
its something we need to look at.

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/6] RFC Distro config changes

[Richard Purdie]

On Wed, 2011-05-11 at 12:13 +0200, Koen Kooi wrote:
> Op 11 mei 2011, om 11:45 heeft Richard Purdie het volgende geschreven:
> > For the uclibc bits, I'm proposing
> > to add:
> > 
> > +DEPLOY_DIR_append = "-uclibc"
> > +STAGING_DIR_TARGET_append = "-uclibc"
> > +STAGING_DIR_HOST_append = "-uclibc"
> > +SSTATE_MANIFESTS_append = "-uclibc"
> > 
> > to tclibc-uclibc.inc.
> 
> Can we use _append_libc-uclibc = "uclibc" or even plain ${TCLIBC} in a
> generic include file? That would be a lot more readable and fix glibc
> vs eglibc.

Changing uclibc around is ok as its not something that has worked well
in with OE-Core for a while. What I'm trying to avoid is having to bump
all the versions of the sstate files, the sysroot layout and associated
version numbers which is what would have to happen if we change the
eglibc layout :(.

Obviously, if angstrom switches layout its pain for you though so I
suspect someone loses with this either way :/.

> > For the SDK/TOOLCHAIN bits, I need to have a close look at the SDK and
> > figure out what the implications are there as I want to ensure that they
> > can all be parallel installed as well as being in separate tarballs but
> > its something we need to look at.
> 
> I needed 'armv5te' and 'armv7a' in the tarball name, so that's how
> this is derived. It matched the OE names, but Khem found some bugs and
> changed it a little.

Makes sense and I see the need, I just want to ensure the tarballs we
have can be parallel installed.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/6] bitbake.conf: Include the new default-providers.inc and default-versions.inc files

[Richard Purdie]

On Wed, 2011-05-11 at 12:08 +0200, Koen Kooi wrote:
> Op 11 mei 2011, om 11:09 heeft Richard Purdie het volgende geschreven:
> 
> > On Tue, 2011-05-10 at 16:20 +0200, Koen Kooi wrote:
> >> Op 10 mei 2011, om 16:00 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> From: Richard Purdie 
> >>> 
> >>> These are the minimal defaults to allow OE-Core to function standalone 
> >>> with
> >>> no distro set and are constucted such that the distro can either override 
> >>> values,
> >>> or totally replace the include file entirely as needed.
> >>> 
> >>> Signed-off-by: Richard Purdie 
> >>> ---
> >>> meta/conf/bitbake.conf|3 +
> >>> meta/conf/distro/include/default-providers.inc|   34 
> >>> meta/conf/distro/include/default-versions.inc |   18 ++
> >>> meta/conf/distro/include/poky-fixed-revisions.inc |   27 -
> >>> meta/conf/distro/poky.conf|   59 
> >>> +
> >>> 5 files changed, 56 insertions(+), 85 deletions(-)
> >>> create mode 100644 meta/conf/distro/include/default-providers.inc
> >>> create mode 100644 meta/conf/distro/include/default-versions.inc
> >>> delete mode 100644 meta/conf/distro/include/poky-fixed-revisions.inc
> >>> 
> >> 
> >>> diff --git a/meta/conf/distro/include/default-providers.inc 
> >>> b/meta/conf/distro/include/default-providers.inc
> >>> new file mode 100644
> >>> index 000..d51ac64
> >>> --- /dev/null
> >>> +++ b/meta/conf/distro/include/default-providers.inc
> >>> @@ -0,0 +1,34 @@
> >>> 
> >>> +PREFERRED_PROVIDER_gconf ?= "gconf-dbus"
> >> 
> >> the dbus port has long been merged upstream, so proper gconf would be
> >> a better choice. We could ignore it and just use dconf in meta-gnome,
> >> though ;)
> > 
> > I agree we should be using gconf, could someone send me the recipe
> > though? ;-).
> 
> I think we want to keep gconf in meta-gnome and pull the dependants out of 
> oe-core

We have a slight dependency conflict here as we've said we want sato in
OECore so we have something we can actually test.

Are we now saying sato also needs to be separated out into its own
layer?

Or can we define meta-gnome as being the gnome pieces without direct
requirements in OECore for a minimal gtk desktop?

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/6] RFC Distro config changes

[Richard Purdie]

On Tue, 2011-05-10 at 15:00 +0100, Richard Purdie wrote:
> From: Richard Purdie 
> 
> As discussed, we want to make OE-Core usable with no distro set. This patch 
> series
> makes some big steps towards that goal. I'd be interested in feedback on 
> whether it
> does the right things and would be usable by others.
> 
> The key is the inclusion of a distro/defaultsetup.conf file by bitbake.conf 
> and 
> in turn this pulls in a variety of other common include files which can 
> likely be
> shared. Any point of this cycle can be overridden by another layer so its 
> totally
> customisable. I'd encourage users to use the pieces they can where possible 
> so we
> all share best practises but obviously people have choice.
> 
> I did dump a load of "default" variables into default-distrovars.inc, I'm not
> calling that file finished, I just had to draw the line somewhere and start a 
> discussion about this :)
> 
> Also, I'm aware there are still a few poky-* files in 
> meta/conf/distro/include.
> Some of these can just be deleted, others renamed tcmode-* and I'll take care 
> of that. I'll also delete the poky.conf file since it no longer contains 
> anything
> required to make OE-Core build as far as I know (wider testing needed).
> 
> Pull URL: git://git.openembedded.org/openembedded-core-contrib
>   Branch: rpurdie/distro
>   Browse: 
> http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/distro
> 
> Richard Purdie (6):
>   Drop poky-floating-revisions.inc, poky-bleeding.conf and
> poky-lsb.conf
>   bitbake.conf: Include the new default-providers.inc and
> default-versions.inc files
>   distro: Add defaultsetup.conf, a set of default configuration
> providing sane overrridable default for commonly used options
>   machine/qemu: Add qemu-config as an essential machine speicfic
> dependency and drop specific distro config
>   conf/distro/include/default-distrovars.inc: Create set of default
> 'distro' variable values
>   preferred-xorg-versions.inc: Drop this, it makes no sense given we
> only have one version of these recipes

I've taken feedback on board, tweaked the series and then merged it. My
reasoning is that whilst this might not be 100% perfect in every way, it
moves us a lot closer to where we want to be. We were going to start
seeing patch conflicts if it was out of tree for too long and that
didn't seem worthwhile.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/6] bitbake.conf: Include the new default-providers.inc and default-versions.inc files

[Richard Purdie]

On Wed, 2011-05-11 at 13:43 +0200, Koen Kooi wrote:
> Op 11 mei 2011, om 13:24 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2011-05-11 at 12:08 +0200, Koen Kooi wrote:
> >> Op 11 mei 2011, om 11:09 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> On Tue, 2011-05-10 at 16:20 +0200, Koen Kooi wrote:
> >>>> Op 10 mei 2011, om 16:00 heeft Richard Purdie het volgende geschreven:
> >>>>> +++ b/meta/conf/distro/include/default-providers.inc
> >>>>> @@ -0,0 +1,34 @@
> >>>>> 
> >>>>> +PREFERRED_PROVIDER_gconf ?= "gconf-dbus"
> >>>> 
> >>>> the dbus port has long been merged upstream, so proper gconf would be
> >>>> a better choice. We could ignore it and just use dconf in meta-gnome,
> >>>> though ;)
> >>> 
> >>> I agree we should be using gconf, could someone send me the recipe
> >>> though? ;-).
> >> 
> >> I think we want to keep gconf in meta-gnome and pull the dependants out of 
> >> oe-core
> > 
> > We have a slight dependency conflict here as we've said we want sato in
> > OECore so we have something we can actually test.
> > 
> > Are we now saying sato also needs to be separated out into its own
> > layer?
> 
> I think that's the best way forward.
> 
> > Or can we define meta-gnome as being the gnome pieces without direct
> > requirements in OECore for a minimal gtk desktop?
> 
> If it's using gconf, it's not a minimal gtk desktop anymore. I see the
> point in having something like sato in oe-core, but I don't think
> that's worth having gconf(-dbus) in oe-core. But this is a different
> discussion, since there are other things that can use gconf (e.g.
> gstreamer) in oe-core, which we would need to take a look at.

It could be argued that gtk with no way to store settings is a little
useless. I'm in favour of having the core graphics testable so I'm not
100% convinced of your argument above. It certainly goes against the
viewpoint that came out of the TSC meetings so we need further
discussion.

In the meantime, replacing gconf-dbus with gconf would seem to move us
closer to where we want to be overall.

> Let's get your distro set merged and then improve on it.

Done :)

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] How does openembedded-core-contrib/master relate to openembedded-core/master?

[Richard Purdie]

On Wed, 2011-05-11 at 14:37 +0200, Leon Woestenberg wrote:
> how does the master branch of openembedded-core-contrib relate to the
> master branch of openembedded-core?
> 
> Is -core-contrib tracking -core 1-to-1?

I probably shouldn't have pushed that at all to be honest, its just
likely to get out of date quickly :/. I was fiddling with some
configuration, trying to allow easiest comparisons of trees in the
contrib repo and the creation of it was an artefact of that, sorry.

Certainly there would always need to be a 1:1 mapping. The current
server config won't actually allow me to delete the master branch either
as its the "current" branch of the repo and would be used in git clones.

> The reason I ask is that user contribution go into feature branches
> (name/feature) of -core-contrib, but should ideally be based against
> core itself, as RP pulls there, and we want clean pulls.
> 
> http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/
> http://git.openembedded.org/cgit.cgi/openembedded-core/log/
> 
> My first feature branch (likewise/gnuspe) was cloned from, branched,
> and pushes against openembedded-core-contrib, is that the correct
> approach?

The pull request you sent looked fine. This only works if that master
branch is kept in sync with the main repo though.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] Re-add powerpc-linux-gnuspe support.

[Richard Purdie]

On Wed, 2011-05-11 at 12:29 +0200, Leon Woestenberg wrote:
> From: Leon Woestenberg 
> 
> (Re-)add powerpc-linux-gnuspe support, as from OpenEmbedded.
> 
> Pull URL: git://git.openembedded.org/openembedded-core-contrib
>   Branch: likewise/gnuspe
>   Browse: 
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=likewise/gnuspe
> 
> Thanks,
> Leon Woestenberg 
> ---
> 
> 
> Leon Woestenberg (1):
>   siteinfo.bbclass: Add powerpc-linux-gnuspe.

Merged to master but I had to sync this up against the recent distro
config files re-org.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] cmake.bbclass: fix qmake and rpath issues

[Richard Purdie]

On Tue, 2011-05-10 at 17:04 -0300, Otavio Salvador wrote:
> On Tue, May 10, 2011 at 16:59, Saul Wold  wrote:
> > In Richard's email he proposed one or the other be set, why do you need to
> > set both here?  If both need to be set then you don't need the override.
> 
> Because they're different no? Otherwise native.bbclass has those for others 
> too:
> 
> ...
> PACKAGES = ""
> PACKAGES_virtclass-native = ""
> PACKAGES_DYNAMIC = ""
> PACKAGES_DYNAMIC_virtclass-native = ""
> ...
> 
> Seems logical, no?

What I'm proposing is that native.bbclass should probably set the
override even when its not being used as a BBCLASSEXTEND.

All things considered lets make that a separate change and I'll take
this as is though because as you point out, there are other variables
with this issue too.

Cheers,

Richard




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] cmake.bbclass: fix qmake and rpath issues

[Richard Purdie]

On Tue, 2011-05-10 at 14:51 +, Otavio Salvador wrote:
> Sync with OE at 3b7d83362027fde4f6850533ab83277d95dda961 however
> without changing the way of generating the toolchain file and making
> it branding agnostic.
> 
> Signed-off-by: Otavio Salvador 
> ---
>  meta/classes/cmake.bbclass  |   14 --
>  meta/classes/native.bbclass |4 
>  2 files changed, 16 insertions(+), 2 deletions(-)

I've merged this to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] qmake_base.bbclass: add generate_qt_config_file task

[Richard Purdie]

On Tue, 2011-05-10 at 14:51 +, Otavio Salvador wrote:
> This writes a qt.conf inside WORKDIR to properly configure projects
> based on CMake. This is required since qmake variables (returned
> by -query command) are fixed into the binary and can only be
> changed using a qt.conf file.
> 
> Signed-off-by: Otavio Salvador 
> ---
>  meta/classes/qmake_base.bbclass |   14 ++
>  1 files changed, 14 insertions(+), 0 deletions(-)

I've merged this to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] cmake: add support for oe qt4 tools names

[Richard Purdie]

On Tue, 2011-05-10 at 14:51 +, Otavio Salvador wrote:
> Signed-off-by: Otavio Salvador 
> ---
>  meta/recipes-devtools/cmake/cmake-native_2.8.3.bb  |2 +-
>  meta/recipes-devtools/cmake/cmake.inc  |3 +-
>  .../cmake/cmake/support-oe-qt4-tools-names.patch   |   90 
> 
>  3 files changed, 93 insertions(+), 2 deletions(-)
>  create mode 100644 
> meta/recipes-devtools/cmake/cmake/support-oe-qt4-tools-names.patch

This looks ok but could you please give more details in the patch about
why its needed. Saul should be able to point you at the details of where
that information is.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][v2] readline: update version

[Richard Purdie]

On Tue, 2011-05-10 at 13:16 -0500, Adrian Alonso wrote:
> * v2 redo commit to include remove previous version
> * Readline new recipe version 6.2
> * Readline remove version 6.1
> 
> Signed-off-by: Adrian Alonso 

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] git: RDEPENDS are transitive, so remove tk so it builds with just OE-core

[Richard Purdie]

On Tue, 2011-05-10 at 19:43 +0200, Koen Kooi wrote:
> Signed-off-by: Koen Kooi 
> ---
>  meta/recipes-devtools/git/git.inc |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/recipes-devtools/git/git.inc 
> b/meta/recipes-devtools/git/git.inc
> index 7f12859..9c7375f 100644
> --- a/meta/recipes-devtools/git/git.inc
> +++ b/meta/recipes-devtools/git/git.inc
> @@ -41,7 +41,7 @@ RDEPENDS_${PN}-perltools = "${PN} perl 
> perl-module-file-path findutils"
>  
>  # git-tk package with gitk and git-gui
>  PACKAGES =+ "${PN}-tk"
> -RDEPENDS_${PN}-tk = "${PN} tk tcl"
> +#RDEPENDS_${PN}-tk = "${PN} tk tcl"
>  EXTRA_OEMAKE = "TCL_PATH=${STAGING_BINDIR_CROSS}/tclsh"
>  FILES_${PN}-tk = " \
>  ${bindir}/gitk \

Merged to master but I tweaked it to also disable the EXTRA_OEMAKE.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/5] recipes upgrade: xserver, sqlite3, xf86-video-intel

[Richard Purdie]

On Wed, 2011-05-11 at 15:27 +0800, Yu Ke wrote:
> From: Yu Ke 
> 
> Test with qemux86, qemuarm, and atom-pc
> 
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>   Branch: kyu3/upgrade-05-11
>   Browse: 
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kyu3/upgrade-05-11
> 
> Thanks,
> Yu Ke 
> ---
> 
> 
> Yu Ke (5):
>   xf86-video-intel: upgrade from 2.14.0 to 2.15.0
>   sqlite: upgrade from 3.7.5 to 3.7.6.2
>   xserver-xf86-dri-lite: upgrade from 1.9.3 to 1.10.1
>   xserver-xf86-dri-lite_git: upgrade to 1.10.2 RC1 snapshot
>   xserver-xf86-lite: upgrade to from 1.7 RC2 to 1.10.1

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] python-native: Add ctypes patch to native build (as in cross-compilation)

[Richard Purdie]

On Wed, 2011-05-11 at 10:40 +0200, Michael Lippautz wrote:
> This fix makes ctypes build for python-native which may be needed by 
> extensions
> that utilize ctypes and use setuptools/distutils as their build system.
> 
> Tested building pyudev for beagleboard target using Ângstrom distro.
> 
> Signed-off-by: Michael Lippautz 

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] Some fixes, Edwin, May11, 2011,

[Richard Purdie]

On Wed, 2011-05-11 at 10:57 +0800, Zhai Edwin wrote:
> From: Zhai Edwin 
> 
> Upgrade qemu git to fix bug 1013, and removed some unused files.
> 
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>   Branch: gzhai/fix3
>   Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix3
> 
> Thanks,
> Zhai Edwin 
> ---
> 
> 
> Zhai Edwin (2):
>   qemu: Upgrade qemu git to the latest 0.14 branch
>   clutter-cairo: remove remaining files from this obsolete recipe

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] one high prio bugfix

[Richard Purdie]

On Tue, 2011-05-10 at 19:23 -0700, Nitin A Kamble wrote:
> From: Nitin A Kamble 
> 
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>   Branch: nitin/bugfixes
>   Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/bugfixes
> 
> Thanks,
> Nitin A Kamble 
> ---
> 
> 
> Nitin A Kamble (1):
>   poky-defaults: fix defaults for libgcc recipes

Merged to master with the appropriate layout changes.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/5] more fixes related to gcc 4.6.0

[Richard Purdie]

On Tue, 2011-05-10 at 22:40 -0700, Nitin A Kamble wrote:
> From: Nitin A Kamble 
> 
> 
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>   Branch: nitin/misc
>   Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc
> 
> Thanks,
> Nitin A Kamble 
> ---
> 
> 
> Nitin A Kamble (5):
>   libunique: Fix for compilation with gcc 4.6.0
>   matchbox-wm-2: fix typo in Makefile
>   web: fix typo in Makefile
>   zaurusd: fix a typo in Makefile
>   dtc: fix compilation with gcc 4.6.0

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 00/16] fixes related to gcc 4.6.0 & patch upstream-status fields

[Richard Purdie]

On Tue, 2011-05-10 at 14:16 -0700, Nitin A Kamble wrote:
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>   Branch: nitin/misc
>   Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc

> Khem Raj (1):
>   gcc-4.6.0: Apply linaro patches
> 
> Nitin A Kamble (15):
>   mdadm: compilation fix for gcc 4.6.0
>   pax: fix for compiling with gcc 4.6.0
>   systemtap: fix for compilation with gcc 4.6.0
>   kexec-tools: fix compiler errors with gcc 4.6.0
>   libzypp: fix compilatoin with gcc 4.6.0
>   libpcre: fix the Upstream-Status format
>   tar: fix Upstream-Status format
>   sat-solver: fix Upstream-Status format
>   cpio: fix upstream-status format
>   subversion: fix upstream-status format
>   python-imaging: fix upstream-status format
>   patch-2.5.9: fix upstream-status format
>   patch-2.6.1: fix upstream-status format
>   binutils: fix upstream status format
>   gcc-4.5.1: fix upstream-status format

Merged to master but I squashed all the upstream-status patches into one
patch since I didn't see the need for as many commits all making the
same logical change.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcmode-default: lock also versions for eglibc

[Richard Purdie]

On Wed, 2011-05-11 at 17:55 +0200, Martin Jansa wrote:
> * there is section for glibc but eglibc was missing
> 
> Signed-off-by: Martin Jansa 
> ---
>  meta/conf/distro/include/tcmode-default.inc |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][RFC] nativesdk.bbclass: define empty PACKAGES/PACKAGES_DYNAMIC

[Richard Purdie]

On Tue, 2011-05-10 at 13:57 +0200, Martin Jansa wrote:
> * we had similar patch for native.bbclass
>   41d77ac37f606e54293826ba1e94a4254bddbfa6
>   I have no idea if the same could be used for nativesdk, because I'm
>   not using generated SDKs at all, that's why it's RFC and if there are
>   better ways to hide such errors, please let me know
> 
> * maybe PACKAGES just don't get extra prefix -nativesdk like
>   glib-2.0-utils-nativesdk
> 
> * those errors are shown like this:
>   ERROR: Trying to resolve runtime dependency glibc-charmap-utf-8 resulted
>   in conflicting PREFERRED_PROVIDER entries being found.
>   The providers found were: 
> ['/OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc_2.12.bb', 
> 'virtual:nativesdk:/OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc_2.12.bb']
>   The PREFERRED_PROVIDER entries resulting in this conflict were: 
> ['PREFERRED_PROVIDER_virtual/libc = eglibc', 
> 'PREFERRED_PROVIDER_virtual/libc-nativesdk = eglibc-nativesdk']
> 
>   NOTE: multiple providers are available for runtime glibc-charmap-utf-8 
> (eglibc-nativesdk, eglibc, glibc, glibc-nativesdk)
>   NOTE: consider defining a PREFERRED_PROVIDER entry to match 
> glibc-charmap-utf-8
>   NOTE: multiple providers are available for runtime glib-2.0-utils 
> (glib-2.0-nativesdk, glib-2.0)
>   NOTE: consider defining a PREFERRED_PROVIDER entry to match glib-2.0-utils

This patch is certainly incorrect as we expect nativesdk to be packaged
and use the resulting packages. It sounds like some value in PACKAGES is
using a hardcoded reference to glibc instead of ${PN}.

Cheers,

Richard




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH] procps: use u-a for pmap, otherwise conflicts with pmap from busybox

[Richard Purdie]

On Tue, 2011-05-10 at 13:52 +0200, Martin Jansa wrote:
> Signed-off-by: Martin Jansa 
> ---
>  meta/recipes-extended/procps/procps_3.2.8.bb |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] create-pull-request: Add -l location switch

[Richard Purdie]

On Tue, 2011-05-10 at 16:01 -0700, Tom Rini wrote:
> On 05/10/2011 12:18 PM, Otavio Salvador wrote:
> > On Tue, May 10, 2011 at 15:55, Tom Rini  wrote:
> >> Add a -l switch that takes an argument of either github or gitorious
> >> and will make the cover letter have a fill-in-the-blank of where the
> >> changes are on either github or gitorious.
> > 
> > Another possibility would be to use git config interface to store
> > those. You might have something like:
> > 
> > [oe-core-pull-request]
> > mode = github
> > user = foo
> > 
> > or
> > 
> > [oe-core-pull-request]
> > mode = gitorious
> > user = bar
> > 
> > This could be used to fill the fields in a proper way since those are
> > predictable.
> 
> If I had a good bit more time, I might re-write the script in python and
> parse .ini files (same syntax as gitconfig) so that lots of useful
> defaults could be saved.  But here's the real test, given that you're an
> intended user, would you use the -l switch or just make a local change
> to the script like Martin showed?

FWIW, we could at least extract a url from the .config of the git
repository with a command like "git remote -v show oe-core-pull-request"

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: create-pull-request / send-pull-request updates

[Richard Purdie]

On Wed, 2011-05-11 at 10:01 -0700, Khem Raj wrote:
> On Wed, May 11, 2011 at 9:15 AM, Darren Hart  wrote:
> >
> > Thoughts/Comments?
> >
> 
> I would suggest to alter the process a bit and get rid of the scripts
> completely. Patches are sent to mailing list for review once reviewed
> the final patches are
> sent as git pull-request. It would simplify things.

I'd argue that it doesn't. It just means the requests come in different
formats, sometimes with key pieces of information missing which means
the people trying to handle the requests (like me) get frustrated.

I find it easiest to deal with requests that have come through those
scripts.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] siteinfo.bbclass: Add powerpc-linux-gnuspe.

[Richard Purdie]

On Thu, 2011-05-12 at 20:50 -0700, Khem Raj wrote:
> On Wed, May 11, 2011 at 3:29 AM, Leon Woestenberg
>  wrote:
> > From: Leon Woestenberg 
> >
> > Re-add powerpc-linux-gnuspe, from OpenEmbedded. Also adds support
> > to poky.conf so that minimal-core-image builds with DISTRO=poky,
> >
> 
> you need to rebase this patch on latest oe-core

I resolved the conflict when I merged this:

http://git.openembedded.net/cgit.cgi/openembedded-core/commit/?id=701a725d118c1a2edd1e54798d85e864b45e19a2

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/8] 13-May Consolidated Pulls

[Richard Purdie]

On Thu, 2011-05-12 at 22:06 -0700, Saul Wold wrote:
> From: Saul Wold 
> 
> Richard,
> 
> Here is a set of patch upstream status updates along with some
> GCC 4.6 fixes and a kern-tools SRCREV tweak from Bruce.
> 
> 
> 
> Pull URL: git://git.openembedded.org/openembedded-core-contrib
>   Branch: sgw/stage
>   Browse: 
> http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] Fix SRC_URI for distcc which moved to googlecode.com

[Richard Purdie]

On Thu, 2011-05-12 at 10:20 -0700, Saul Wold wrote:
> From: Saul Wold 
> 
> Subject sez it all!
> 
> Pull URL: git://git.openembedded.org/openembedded-core-contrib
>   Branch: sgw/stage
>   Browse: 
> http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
> 
> Thanks,
> Saul Wold 
> ---
> 
> 
> Saul Wold (1):
>   distcc: Update SRC_URI

Merged to master, thanks.

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] siteinfo.bbclass: Add powerpc-linux-gnuspe.

[Richard Purdie]

On Fri, 2011-05-13 at 12:28 +0200, Leon Woestenberg wrote:
> Hello Khem,
> 
> On Fri, May 13, 2011 at 5:50 AM, Khem Raj  wrote:
> > On Wed, May 11, 2011 at 3:29 AM, Leon Woestenberg
> >  wrote:
> >> From: Leon Woestenberg 
> >> Re-add powerpc-linux-gnuspe, from OpenEmbedded. Also adds support
> >> to poky.conf so that minimal-core-image builds with DISTRO=poky,
> >
> > you need to rebase this patch on latest oe-core
> >
> Yes, I was using oe-core-contrib/master as a base, wrongly assuming
> that that is the correct base for -contrib fixes/additions.

To be fair when you wrote the patch, the conflicting distro changes were
not in either branch so in that case it didn't matter.

It was easier to take the distro changes and fix this up than the other
way around though.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Mon, 2011-05-16 at 02:55 -0700, Khem Raj wrote:
> On Sun, May 15, 2011 at 11:58 PM, Koen Kooi  
> wrote:
> >
> > Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
> >
> >> Do not define DEPLOY_DIR_IMAGE
> >> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
> >> recipes
> >> Append -uclibc to STAGING_DIR_HOST only for target recipes.
> >>
> >> These changes make sure that we still share the native sysroot
> >
> > I still stay we append tclibc unconditionally.
> 
> yes thats would simplify things if we agree to use TCLIBC in bitbake.conf

We can't depend on TCLIBC in bitbake.conf since someone still has the
option of not using the standard configuration boilerplate we're
providing.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] Performance - Staus and plans

[Richard Purdie]

I'm going to cover both disk usage and build time in this list with a
summary of the currently identified tasks we're working on and their
status as I understand them:

a) Split libc locale generation from libc do_install/do_package

   Status: Dongxiao has a WIP patch. Do we have an ETA on that?

b) Share the source directories for gcc, glibc and maybe others

   Status: RP wrote a proof of concept patch, needs further work, on 
   Yocto schedule for 1.1

c) Set CCACHE on a per recipe basis. need to figure out whether ccache 
   data can be shared and under what circumstances.

   Status: Idea talked about, no code yet

d) Cache do_configure autoreconf result

   Status: We know this is about 50% of the time on configure, no code 
   yet. Need fixes to SRC_URI variable dependency code to include 
   checksums (which we need to fix regardless)

e) Remove perl-native from most build dependencies by installing it 
   into its own sysroot

   Status: WIP

f) Document performance best practises (e.g. no premempt in kernel, 
   use server kernel on ubuntu)

   Status: Not done yet.

Further investigative ideas I've been wondering about:

a) Consider current dependency tree and see if any dependencies could 
   be avoided?

b) Consider contents of our standard images and what could be removed 
   for what build time improvement?

c) Find a system with complete symbol data present, then run a minimal 
   build under oprofile and see if anything significant bottle necks 
   appear? To get good debug data we might do a build under a poky 
   generated image! :)

d) Consider better ways to enable pseudo to be prebuilt in parallel 
   with other native recipes as this takes a significant chunk of time 
   when we aren't using parallelism.

e) Compare the build time of "bitbake glibc -c populate_sysroot; 
   bitbake core-image-sato" with "bitbake core-image-sato"

My big concern is that whilst I think if we keep working at it, we can
get the standard build time to 90 minutes (currently master is 102), we
don't currently have any gain identified that could get us to the 60
minute build time.

Cheers,

Richard





___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/6] RFC Distro config changes

[Richard Purdie]

On Sun, 2011-05-15 at 17:27 -0300, Otavio Salvador wrote:
> On Wed, May 11, 2011 at 10:30, Richard Purdie
>  wrote:
> > I've taken feedback on board, tweaked the series and then merged it. My
> > reasoning is that whilst this might not be 100% perfect in every way, it
> > moves us a lot closer to where we want to be. We were going to start
> > seeing patch conflicts if it was out of tree for too long and that
> > didn't seem worthwhile.
> 
> I have expected at least another review cycle since this is a huge
> change and potential to change a lot of stuff for users...

Its a process of iterative improvement. I'm not calling what is there
now 100% complete, just a lot better than what preceded it. If there are
further changes needed, lets discuss them! :)

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Mon, 2011-05-16 at 15:11 +0200, Koen Kooi wrote:
> Op 16 mei 2011, om 13:41 heeft Richard Purdie het volgende geschreven:
> 
> > On Mon, 2011-05-16 at 02:55 -0700, Khem Raj wrote:
> >> On Sun, May 15, 2011 at 11:58 PM, Koen Kooi  
> >> wrote:
> >>> 
> >>> Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
> >>> 
> >>>> Do not define DEPLOY_DIR_IMAGE
> >>>> Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross
> >>>> recipes
> >>>> Append -uclibc to STAGING_DIR_HOST only for target recipes.
> >>>> 
> >>>> These changes make sure that we still share the native sysroot
> >>> 
> >>> I still stay we append tclibc unconditionally.
> >> 
> >> yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
> > 
> > We can't depend on TCLIBC in bitbake.conf since someone still has the
> > option of not using the standard configuration boilerplate we're
> > providing.
> 
> So we can't add TCLIBC ??= eglibc to bitbake.conf?

No, I can just see the bug reports for uclibc building in a directory
called XXX-eglibc as the user had only set the PREFERRED_PROVIDER
variables.

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core