* Re: [CONSOLIDATED PULL 0/5] Collection of patches
From: Richard Purdie @ 2011-09-07 22:36 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1315329511.git.sgw@linux.intel.com>
On Tue, 2011-09-06 at 10:26 -0700, Saul Wold wrote:
> Richard,
>
> This is a collection of patches that have been sitting around,
> and unless I missed some comments should be good to go.
>
> I bumped gettext's PR in this request.
>
> Sau!
>
>
> The following changes since commit 41b7c955cfdc7b4d5c667c8a8742237d5edaca4f:
>
> icu-3.6: fix building with big make -j (2011-09-05 20:38:50 +0100)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib sgw/stage
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
>
> Denis Carikli (1):
> mtd-utils: update to version to 1.4.6
>
> Kumar Gala (1):
> scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to
> BB_ENV_EXTRAWHITE
>
> Phil Blundell (1):
> pango: use qemu to generate pango.modules during rootfs construction
>
> Saul Wold (2):
> gettext: use included libxml and libcroco
> web: Update SRCREV to address ccs_parser_parse_stylesheet arg
> mismatch
Merged to master with the exception of Kumar's change which I've
followed up with in the original thread.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 0/1] Fix MakeMaker's finding of perl.real
From: Richard Purdie @ 2011-09-07 22:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20110907090750.GE4181@chargestorm.se>
On Wed, 2011-09-07 at 11:07 +0200, Anders Darander wrote:
> * Eric Bénard <eric@eukrea.com> [110907 08:41]:
> > Le 07/09/2011 07:09, Saul Wold a écrit :
> > > When configuring cpan packages, the directories passed to MakeMaker are the
> > > target directories. There was a patch that was applied to the native perl
> > > to find perl.real and convert that to perl. This does not apply for the
> > > target perl modules and therefore MakeMaker find perl.real.
> > >
> > > This patch to cpan configure modifies the Makefile after configure and
> > > changes the perl.real to just straight perl so we have the correct paths
> > > and shared state info in usable.
> > >
> > when sending 1 patch, is it possible to not use cover letter in order to have
> > the explanation in the patch commit ?
> > That's easier to understand what the patch is doing when browsing log.
>
> Cover letter or not, the patch should include a commit message that
> explains the patch. It doesn't really matter if there is only one patch
> or a large patch series.
>
> For a single patch, the cover letter can be usefull to provide some
> extra information and discussion. In other cases, it can be pretty
> useless IMHO.
This commit has slipped into the tree this time but I agree in future
more explanation of a commit is needed...
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] pango: use qemu to generate pango.modules during rootfs construction
From: Saul Wold @ 2011-09-08 1:12 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <1314804932.19905.169.camel@phil-desktop>
On 08/31/2011 08:35 AM, Phil Blundell wrote:
> This allows pango to be installed in an image with read-only-rootfs.
>
> Signed-off-by: Phil Blundell<philb@gnu.org>
> ---
> meta/recipes-graphics/pango/pango.inc | 11 +++++++----
> meta/recipes-graphics/pango/pango_1.28.4.bb | 2 +-
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-graphics/pango/pango.inc b/meta/recipes-graphics/pango/pango.inc
> index a8e99e2..ff3f5dd 100644
> --- a/meta/recipes-graphics/pango/pango.inc
> +++ b/meta/recipes-graphics/pango/pango.inc
> @@ -10,13 +10,13 @@ SECTION = "libs"
> LICENSE = "LGPL"
>
> X11DEPENDS = "virtual/libx11 libxft"
> -DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv gtk-doc-native cairo ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}"
> +DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv gtk-doc-native cairo qemu-native ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}"
>
> PACKAGES_DYNAMIC = "pango-module-*"
>
> RRECOMMENDS_${PN} = "${@base_contains('DISTRO_FEATURES', 'x11', 'pango-module-basic-x', '', d)} pango-module-basic-fc"
>
> -inherit gnome
> +inherit gnome qemu
>
> EXTRA_AUTORECONF = ""
>
> @@ -33,9 +33,12 @@ LIBV = "1.6.0"
>
> postinst_prologue() {
> if [ "x$D" != "x" ]; then
> - exit 1
> + if [ ! -f "$D${sysconfdir}/pango/pango.modules" ]; then
> + mkdir -p $D${sysconfdir}/pango
> + PSEUDO_RELOADED=YES ${@qemu_target_binary(d)} -L $D $D${bindir}/pango-querymodules> "$D${sysconfdir}/pango/pango.modules"
> + fi
> + exit 0
> fi
> -
> }
>
> python populate_packages_prepend () {
> diff --git a/meta/recipes-graphics/pango/pango_1.28.4.bb b/meta/recipes-graphics/pango/pango_1.28.4.bb
> index 68ab700..33eac21 100644
> --- a/meta/recipes-graphics/pango/pango_1.28.4.bb
> +++ b/meta/recipes-graphics/pango/pango_1.28.4.bb
> @@ -2,7 +2,7 @@ require pango.inc
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
>
> -PR = "r1"
> +PR = "r4"
>
> SRC_URI += "file://no-tests.patch"
>
Merged but we found a problem with qemux86-64, a bug was filed and you
should have received an email
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/2] systemtap: upgrade to 1.6
From: Saul Wold @ 2011-09-08 3:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1315025121.31478.140.camel@elmorro>
On 09/02/2011 09:45 PM, Tom Zanussi wrote:
> This patchset upgrades systemtap to 1.6. The 1.6 version of
> systemtap also has improved support for arm, so this also
> enables it for arm and adds it to qemuarm.
>
> This upgrade was successfully tested on qemux86, qemux86-64,
> qemuppc, qemuarm, and sugarbay. The results and the tests
> can be found at the end of the systemtap section on the yocto
> wiki:
>
> https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling#systemtap
>
> Tom Zanussi (2):
> systemtap: upgrade to 1.6
> task-core-tools: add systemtap to qemuarm
>
> meta/recipes-core/tasks/task-core-tools.bb | 4 +-
> .../fix_for_compilation_with_gcc-4.6.0.patch | 119
> --------------------
> meta/recipes-kernel/systemtap/systemtap_git.bb | 15 +--
> 3 files changed, 9 insertions(+), 129 deletions(-)
> delete mode 100644
> meta/recipes-kernel/systemtap/systemtap/fix_for_compilation_with_gcc-4.6.0.patch
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/1] Make initramfs-live-install consistent to grub
From: Saul Wold @ 2011-09-08 3:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1315203166.git.lianhao.lu@intel.com>
On 09/04/2011 11:15 PM, Lianhao Lu wrote:
> This patch fixed bug #1428. Since the grub 0.97 on which the initramfs-live-install
> RDEPENDS doesn't support x86_64 target, remove it from the COMPATIBLE_HOST in
> initramfs-live-install.
>
> The following changes since commit 0616557a8c29b42bae0ffd5fd665a046810047e4:
> Richard Purdie (1):
> populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH
>
> are available in the git repository at:
>
> git://git.yoctoproject.org/poky-contrib llu/bug1428
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=llu/bug1428
>
> Lianhao Lu (1):
> initramfs-live-install: Be consistent with grub.
>
> .../initrdscripts/initramfs-live-install_1.0.bb | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/1] Fix gettext dependency issue
From: Saul Wold @ 2011-09-08 3:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1315069299.git.sgw@linux.intel.com>
On 09/03/2011 10:04 AM, Saul Wold wrote:
> Use gettext's internal libraries for libxml and libcroco to
> ensure that there is not any strange behavior if ordering of
> the build of these items changes.
>
> The gettext-tools configure script looks for a libxml and libcroco
> in sysroot and this can cause an unforseen dependency issue.
>
> Sau!
>
> The following changes since commit 0616557a8c29b42bae0ffd5fd665a046810047e4:
>
> populate_sdk: We need to ensure that the SDK sysroot reflects PACKAGE_ARCH (2011-09-02 23:38:00 +0100)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib sgw/fix
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/fix
>
> Saul Wold (1):
> gettext: use included libxml and libcroco
>
> meta/recipes-core/gettext/gettext_0.18.1.1.bb | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
Merged into OE-Core
Thanks
Myse!f
^ permalink raw reply
* Re: [PATCH 0/2] Fixes for X and site/x86_64
From: Saul Wold @ 2011-09-08 3:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1315276240.git.edwin.zhai@intel.com>
On 09/05/2011 07:36 PM, edwin.zhai@intel.com wrote:
> From: Zhai Edwin<edwin.zhai@intel.com>
>
> All,
> These are some fixes. One is for enabling some HID device for rootless X,
> another is for grub conf error on x86_64. Pls. help to review.
>
> Thanks,
> Edwin
>
> The following changes since commit 314131e472a7d728ea96cbd577d2947d7bc9f50e:
>
> linux-yocto: clean configuration for v3.0.4 (2011-09-05 20:25:46 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib gzhai/master2
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master2
>
> Zhai Edwin (2):
> xserver-nodm-init: Change hidraw mode to allow normal user access
> site/x86_64: Add entries to fix conf error on x86_64
>
> .../x11-common/xserver-nodm-init/xserver-nodm | 4 ++++
> meta/site/x86_64-linux | 10 ++++++++++
> 2 files changed, 14 insertions(+), 0 deletions(-)
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH v2] busybox: update to 1.8.5
From: Saul Wold @ 2011-09-08 3:45 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1315294779-3295-1-git-send-email-denis@eukrea.com>
On 09/06/2011 12:39 AM, Denis Carikli wrote:
> Signed-off-by: Denis Carikli<denis@eukrea.com>
> ---
> .../B921600.patch | 0
> .../busybox-appletlib-dependency.patch | 0
> .../busybox-udhcpc-no_deconfig.patch | 0
> .../{busybox-1.18.4 => busybox-1.18.5}/defconfig | 0
> .../get_header_tar.patch | 0
> .../run-parts.in.usr-bin.patch | 0
> .../udhcpc-fix-nfsroot.patch | 0
> .../udhcpscript.patch | 0
> .../{busybox_1.18.4.bb => busybox_1.18.5.bb} | 6 +++---
> 9 files changed, 3 insertions(+), 3 deletions(-)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/B921600.patch (100%)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/busybox-appletlib-dependency.patch (100%)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/busybox-udhcpc-no_deconfig.patch (100%)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/defconfig (100%)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/get_header_tar.patch (100%)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/run-parts.in.usr-bin.patch (100%)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/udhcpc-fix-nfsroot.patch (100%)
> rename meta/recipes-core/busybox/{busybox-1.18.4 => busybox-1.18.5}/udhcpscript.patch (100%)
> rename meta/recipes-core/busybox/{busybox_1.18.4.bb => busybox_1.18.5.bb} (85%)
>
merged into OE-Core
Thanks
Sau!
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/B921600.patch b/meta/recipes-core/busybox/busybox-1.18.5/B921600.patch
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/B921600.patch
> rename to meta/recipes-core/busybox/busybox-1.18.5/B921600.patch
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/busybox-appletlib-dependency.patch b/meta/recipes-core/busybox/busybox-1.18.5/busybox-appletlib-dependency.patch
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/busybox-appletlib-dependency.patch
> rename to meta/recipes-core/busybox/busybox-1.18.5/busybox-appletlib-dependency.patch
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/busybox-udhcpc-no_deconfig.patch b/meta/recipes-core/busybox/busybox-1.18.5/busybox-udhcpc-no_deconfig.patch
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/busybox-udhcpc-no_deconfig.patch
> rename to meta/recipes-core/busybox/busybox-1.18.5/busybox-udhcpc-no_deconfig.patch
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/defconfig b/meta/recipes-core/busybox/busybox-1.18.5/defconfig
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/defconfig
> rename to meta/recipes-core/busybox/busybox-1.18.5/defconfig
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/get_header_tar.patch b/meta/recipes-core/busybox/busybox-1.18.5/get_header_tar.patch
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/get_header_tar.patch
> rename to meta/recipes-core/busybox/busybox-1.18.5/get_header_tar.patch
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/run-parts.in.usr-bin.patch b/meta/recipes-core/busybox/busybox-1.18.5/run-parts.in.usr-bin.patch
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/run-parts.in.usr-bin.patch
> rename to meta/recipes-core/busybox/busybox-1.18.5/run-parts.in.usr-bin.patch
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/udhcpc-fix-nfsroot.patch b/meta/recipes-core/busybox/busybox-1.18.5/udhcpc-fix-nfsroot.patch
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/udhcpc-fix-nfsroot.patch
> rename to meta/recipes-core/busybox/busybox-1.18.5/udhcpc-fix-nfsroot.patch
> diff --git a/meta/recipes-core/busybox/busybox-1.18.4/udhcpscript.patch b/meta/recipes-core/busybox/busybox-1.18.5/udhcpscript.patch
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-1.18.4/udhcpscript.patch
> rename to meta/recipes-core/busybox/busybox-1.18.5/udhcpscript.patch
> diff --git a/meta/recipes-core/busybox/busybox_1.18.4.bb b/meta/recipes-core/busybox/busybox_1.18.5.bb
> similarity index 85%
> rename from meta/recipes-core/busybox/busybox_1.18.4.bb
> rename to meta/recipes-core/busybox/busybox_1.18.5.bb
> index b2053ee..c0dc1d4 100644
> --- a/meta/recipes-core/busybox/busybox_1.18.4.bb
> +++ b/meta/recipes-core/busybox/busybox_1.18.5.bb
> @@ -1,5 +1,5 @@
> require busybox.inc
> -PR = "r9"
> +PR = "r0"
>
> SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
> file://udhcpscript.patch \
> @@ -25,7 +25,7 @@ SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
> file://umount.busybox \
> file://defconfig"
>
> -SRC_URI[tarball.md5sum] = "b03c5b46ced732679e525a920a1a62f5"
> -SRC_URI[tarball.sha256sum] = "4d24d37bd6f1bd153e8cf9a984ec2f32f18464f73ca535e2cc2e8be9694097fa"
> +SRC_URI[tarball.md5sum] = "96dd43cc7cee4017a6bf31b7da82a1f5"
> +SRC_URI[tarball.sha256sum] = "10954fcd5c48d8a262a3497b16227bf983a05658bf2bf661af2fdeca773f2fc0"
>
> EXTRA_OEMAKE += "V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
^ permalink raw reply
* Re: [PATCH 0/1] Update prelinker to latest upstream version
From: Saul Wold @ 2011-09-08 3:46 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1315326300.git.mark.hatle@windriver.com>
On 09/06/2011 09:26 AM, Mark Hatle wrote:
> Update the prelinker to the latest (yoctoproject) cross_prelinker version.
>
> This syncs to the latest Red Hat version, provides a new rtld emulation, and
> now can identify bad GNU_HASH entries to help detect a bug in the hash
> generation observed on PPC64.
>
> The following changes since commit 41b7c955cfdc7b4d5c667c8a8742237d5edaca4f:
>
> icu-3.6: fix building with big make -j (2011-09-05 20:38:50 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib mhatle/prelink
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/prelink
>
> Mark Hatle (1):
> prelink: Update to latest upstream version
>
> meta/recipes-devtools/prelink/prelink_git.bb | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
Merged to OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/5] patches to fix deb packaging: bug 1070
From: Saul Wold @ 2011-09-08 3:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1315313790.git.dexuan.cui@intel.com>
On 09/06/2011 06:08 AM, Dexuan Cui wrote:
> The DEB packaging for core-image-sato-sdk(previously called poky-image-sdk) and
> meta-toolchain-gmae(previously called meta-toolchain-sdk) has been broken for
> quite a long period of time -- at least it was broken in Oct 2010 (I didn't try
> to test older commits).
>
> The patches try to improve the situation.
>
> With the patches, core-image-sato-sdk for qemu{x86, x86-64, ppc, mips} can
> build fine, but qemuarm still has a do_rootfs issue:
> | The following packages have unmet dependencies:
> | task-base-extended: Depends: task-base but it is not going to be installed
>
> And, meta-toolchain-gmae is still broken. The error is:
> | + apt-get install task-sdk-host-nativesdk --force-yes --allow-unauthenticated
> | Reading package lists...
> | Building dependency tree...
> | Reading state information...
> | E: Couldn't find package task-sdk-host-nativesdk
>
> I'm working on the left issues.
>
> Does anybody know if OE has the similar issue or not?
> Any comment/suggestions for the patch and left isseus are appreciated.
>
> Thanks!
>
> -- Dexuan
>
> The following changes since commit 41b7c955cfdc7b4d5c667c8a8742237d5edaca4f:
>
> icu-3.6: fix building with big make -j (2011-09-05 20:38:50 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib dcui/distro
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/distro
>
> Dexuan Cui (5):
> populate_sdk_deb.bbclass: add the missing parameter - for tar
> package_deb.bbclass: put the stderr into log.do_xxx-attemptonly.xxx
> dpkg, dpkg-native: fix DEPENDS, RDEPENDS and pkg_postinst_dpkg
> opkg: it should Rdepend on update-alternatives-cworth
> default-providers.inc: define update-alternatives and -native
> properly
>
> meta/classes/package_deb.bbclass | 2 +-
> meta/classes/populate_sdk_deb.bbclass | 2 +-
> meta/conf/distro/include/default-providers.inc | 5 ++---
> meta/recipes-devtools/dpkg/dpkg.inc | 23 ++++++++++-------------
> meta/recipes-devtools/opkg/opkg_0.1.8.bb | 4 ++--
> meta/recipes-devtools/opkg/opkg_svn.bb | 4 ++--
> 6 files changed, 18 insertions(+), 22 deletions(-)
>
As requested Populate SDK Deb patch and package_deb patch were merged
with OE-Core, will look for respins on the others.
Thanks
Sau!
^ permalink raw reply
* Re: resolvconf: switch to 1.59 as 1.58 was removed from debian ftp
From: Saul Wold @ 2011-09-08 3:48 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1315377343-5259-1-git-send-email-eric@eukrea.com>
On 09/06/2011 11:35 PM, Eric Bénard wrote:
> Signed-off-by: Eric Bénard<eric@eukrea.com>
> ---
> .../{resolvconf_1.58.bb => resolvconf_1.59.bb} | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-connectivity/resolvconf/{resolvconf_1.58.bb => resolvconf_1.59.bb} (88%)
>
> diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.58.bb b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
> similarity index 88%
> rename from meta/recipes-connectivity/resolvconf/resolvconf_1.58.bb
> rename to meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
> index 46040a0..94231e0 100644
> --- a/meta/recipes-connectivity/resolvconf/resolvconf_1.58.bb
> +++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
> @@ -15,8 +15,8 @@ PR = "r0"
>
> SRC_URI = "${DEBIAN_MIRROR}/main/r/resolvconf/resolvconf_${PV}.tar.gz"
>
> -SRC_URI[md5sum] = "6232b336e6bb05282791b5506bbbfa42"
> -SRC_URI[sha256sum] = "853016a2ef16a8fdd6d1e29ac94bc6391199033235aa8e3b373345979c617431"
> +SRC_URI[md5sum] = "59b20258bb8a3c25b8c4083fc0279547"
> +SRC_URI[sha256sum] = "37691677cea24da66d6664c98668b5f16667c0133f17feb166f246ee923ad756"
>
> do_compile () {
> :
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: Core image recipes
From: Saul Wold @ 2011-09-08 3:53 UTC (permalink / raw)
To: Paul Eggleton; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <201109071418.10285.paul.eggleton@linux.intel.com>
On 09/07/2011 06:18 AM, Paul Eggleton wrote:
> On Friday 26 August 2011 17:39:09 Paul Eggleton wrote:
>> On Friday 26 August 2011 17:18:15 Saul Wold wrote:
>>> On 08/26/2011 02:47 AM, Paul Eggleton wrote:
>>>> meta/recipes-extended/images/core-image-basic.bb
>>>
>>> This image should NOT contain any X11, this is supposed to be an
>>> extention of core-image-minimal with many of the busybox related
>>> commands substituted for the real command set. The intention of this
>>> image is two fold, first it's the largest image that we test against
>>> non-GPLv3 and it's the non-graphical LSB image (I am not sure if there
>>> is a spec test defined for that.
>>
>> Hmm, I'm not sure what I was thinking earlier, you're right it doesn't
>> appear to have X.
>
> Now I know why I thought this. Because task-core.bb defines task packages that
> depend on X applications, any recipe that inherits from core-image will force
> a build of all of the X apps even if it doesn't intend to use them - so both
> core-image-basic and core-image-base suffer from this. This is not really very
> good and I think we ought to be splitting up task-core to avoid this. FYI
> whilst core-image-minimal inherits from core-image it overrides IMAGE_INSTALL
> and thus doesn't use anything from task-core and therefore does not have this
> issue.
>
Now I understand what you are talking about, it might best to split this
into 2 tasks a task-core moved to recipes-core/tasks and a
task-core-x11, what about that?
>> I can't access the LSB specs website right now
>> unfortunately but does this have an official name within LSB? It's not
>> "LSB-Core" is it?
>
> Yep, it's LSB-Core (yet another meaning of "core", sigh...)
>
We could rename basic to task-lsb-core if that's what your thinking, but
as you point out yet another "core".
>>>> Then, we have core-image-base, which whilst it doesn't remove package
>>>> management files, does not have "package-management" in its features,
>>>> so it's not a whole lot different to core-image-minimal AFAICT.
>>>
>>> On this one I might agree, I know that we have not built that image, nor
>>> does it seem to be used by anything else.
>>
>> If there's demand for a minimal image with package management (someone
>> asked for this on IRC just the other day, and it makes sense to me at
>> least) then that's what I'd suggest turning this into. In which case it
>> ought to be called core-image-minimal-pkgmgmt or something similar.
>
> Any opinions on this one?
>
I think this is one that they can create themselves it's would be distro
specific and would require additional space allocated to the rootfs,
best for the distro do. Remember we are trying to provide foundations
and examples. core-image-minimal is supposed to be the smallest possible
image with login and shell. It can be used by someone to build on.
Sau!
> Cheers,
> Paul
>
^ permalink raw reply
* Re: [PATCH] useradd.bbclass: use correct value for $D in postinst functions
From: Saul Wold @ 2011-09-08 3:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <1315426812.4368.1.camel@lenovo.internal.reciva.com>
On 09/07/2011 01:20 PM, Phil Blundell wrote:
> This corrects the location of the password file used during package installation.
>
> See http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/009183.html and subsequent discussion.
>
> Signed-off-by: Phil Blundell<philb@gnu.org>
> ---
> meta/classes/useradd.bbclass | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
> index 5f5b68d..1e03a04 100644
> --- a/meta/classes/useradd.bbclass
> +++ b/meta/classes/useradd.bbclass
> @@ -15,8 +15,8 @@ SYSROOT=""
>
> if test "x$D" != "x"; then
> # Installing into a sysroot
> - SYSROOT="${STAGING_DIR_TARGET}"
> - OPT="--root ${STAGING_DIR_TARGET}"
> + SYSROOT="$D"
> + OPT="--root $D"
>
> # Add groups and users defined for all recipe packages
> GROUPADD_PARAM="${@get_all_cmd_params(d, 'group')}"
> @@ -79,7 +79,7 @@ useradd_sysroot () {
>
> # Explicitly set $D since it isn't set to anything
> # before do_install
> - D=${D}
> + D=${STAGING_DIR_TARGET}
> useradd_preinst
> }
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH] avahi: only use gtk if DISTRO_FEATURES includes x11
From: Saul Wold @ 2011-09-08 3:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <1315427028.4368.2.camel@lenovo.internal.reciva.com>
On 09/07/2011 01:23 PM, Phil Blundell wrote:
> Otherwise avahi isn't buildable for an x11-less DISTRO.
>
> Signed-off-by: Phil Blundell<philb@gnu.org>
> ---
> meta/recipes-connectivity/avahi/avahi.inc | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
> index dc7a5ae..24ea458 100644
> --- a/meta/recipes-connectivity/avahi/avahi.inc
> +++ b/meta/recipes-connectivity/avahi/avahi.inc
> @@ -14,7 +14,8 @@ SECTION = "network"
> # python scripts are under GPLv2+
> LICENSE = "GPLv2+& LGPLv2.1+"
>
> -DEPENDS = "expat libcap libdaemon dbus glib-2.0 gtk+ libglade"
> +X11DEPENDS = "gtk+ libglade"
> +DEPENDS = "expat libcap libdaemon dbus glib-2.0 ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)}"
>
> SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
> file://00avahi-autoipd \
> @@ -30,6 +31,7 @@ EXTRA_OECONF = "--with-distro=debian \
> --disable-mono \
> --disable-monodoc \
> --disable-gtk3 \
> + ${@base_contains('DISTRO_FEATURES', 'x11', '--enable-gtk', '--disable-gtk', d)} \
> --disable-qt3 \
> --disable-qt4 \
> --disable-python \
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH] dbus: fix paths in startup script, use useradd.bbclass for user creation
From: Saul Wold @ 2011-09-08 3:58 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Phil Blundell
In-Reply-To: <1315427297.4368.4.camel@lenovo.internal.reciva.com>
On 09/07/2011 01:28 PM, Phil Blundell wrote:
> Replace various hard-coded references to /usr, /var and /etc with symbolic equivalents.
>
> Also replace adhoc usage of adduser/addgroup with useradd.bbclass
> functionality. This should, in theory, remove the need for a postinst
> to be run at boot time.
>
> Signed-off-by: Phil Blundell<philb@gnu.org>
This one seems to have some problems:
ERROR: Function 'useradd_sysroot' failed (see
/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/x86_64-poky-linux/dbus-1.4.12-r6/temp/log.do_install.19825
for further information)
ERROR: Logfile of failure stored in:
/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/x86_64-poky-linux/dbus-1.4.12-r6/temp/log.do_install.19825
Log data follows:
| DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc',
'bit-64', 'x86_64-linux', 'common']
| ERROR: Function 'useradd_sysroot' failed (see
/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/x86_64-poky-linux/dbus-1.4.12-r6/temp/log.do_install.19825
for further information)
| Running groupadd commands...
| sent invalidate(passwd) request, exiting
| sent invalidate(group) request, exiting
| sent invalidate(group) request, exiting
| sent invalidate(passwd) request, exiting
| sent invalidate(group) request, exiting
| sent invalidate(group) request, exiting
| Running useradd commands...
| useradd: group messagebus exists - if you want to add this user to
that group, use -g.
NOTE: package dbus-1.4.12-r6: task do_install: Failed
ERROR: Task 1684
(/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/meta/recipes-core/dbus/dbus_1.4.12.bb,
do_install) failed with exit code '1'
Please rework and let me know how it was tested, this might not make 1.1
at this point as we are starting to tighten requirements as we go into
the RC phase.
Thanks
Sau!
> ---
> meta/recipes-core/dbus/dbus-1.4.12/dbus-1.init | 14 +++---
> meta/recipes-core/dbus/dbus.inc | 58 ++++++++++++------------
> meta/recipes-core/dbus/dbus_1.4.12.bb | 1 +
> 3 files changed, 37 insertions(+), 36 deletions(-)
>
> diff --git a/meta/recipes-core/dbus/dbus-1.4.12/dbus-1.init b/meta/recipes-core/dbus/dbus-1.4.12/dbus-1.init
> index 4abc4cb..1917ad3 100644
> --- a/meta/recipes-core/dbus/dbus-1.4.12/dbus-1.init
> +++ b/meta/recipes-core/dbus/dbus-1.4.12/dbus-1.init
> @@ -16,22 +16,22 @@
>
> set -e
>
> -DAEMON=/usr/bin/dbus-daemon
> +DAEMON=@BINDIR@/dbus-daemon
> NAME=dbus
> DAEMONUSER=messagebus
> -PIDDIR=/var/run/dbus
> +PIDDIR=@LOCALSTATEDIR@/run/dbus
> PIDFILE=$PIDDIR/pid
> -UUIDDIR=/var/lib/dbus
> +UUIDDIR=@LOCALSTATEDIR@/lib/dbus
> DESC="system message bus"
> -EVENTDIR=/etc/dbus-1/event.d
> +EVENTDIR=@SYSCONFDIR@/dbus-1/event.d
>
> test -x $DAEMON || exit 0
>
> # Source defaults file; edit that file to configure this script.
> ENABLED=1
> PARAMS=""
> -if [ -e /etc/default/dbus ]; then
> - . /etc/default/dbus
> +if [ -e @SYSCONFDIR@/default/dbus ]; then
> + . @SYSCONFDIR@/default/dbus
> fi
>
> test "$ENABLED" != "0" || exit 0
> @@ -113,7 +113,7 @@ case "$1" in
> start_it_up
> ;;
> *)
> - echo "Usage: /etc/init.d/$NAME {start|stop|restart|reload|force-reload}">&2
> + echo "Usage: @SYSCONFDIR@/init.d/$NAME {start|stop|restart|reload|force-reload}">&2
> exit 1
> ;;
> esac
> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
> index a8ecda8..34dbe4a 100644
> --- a/meta/recipes-core/dbus/dbus.inc
> +++ b/meta/recipes-core/dbus/dbus.inc
> @@ -14,11 +14,19 @@ SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
> file://tmpdir.patch; \
> file://dbus-1.init"
>
> -inherit autotools pkgconfig gettext update-rc.d
> +inherit autotools pkgconfig gettext update-rc.d useradd
> +
> +USERADD_PACKAGES = "${PN}"
> +USERADD_PARAM_${PN} = "-d ${MESSAGEHOME} -g ${MESSAGEUSER} -r ${MESSAGEUSER}"
> +GROUPADD_PARAM_${PN} = "${MESSAGEUSER}; netdev"
>
> INITSCRIPT_NAME = "dbus-1"
> INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
>
> +MESSAGEUSER=messagebus
> +MESSAGEHOME="${localstatedir}/run/dbus"
> +UUIDDIR="${localstatedir}/lib/dbus"
> +
> CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session.conf"
>
> DEBIANNAME_${PN} = "dbus-1"
> @@ -34,42 +42,27 @@ FILES_${PN} = "${bindir}/dbus-daemon* \
> ${bindir}/dbus-uuidgen \
> ${bindir}/dbus-cleanup-sockets \
> ${bindir}/dbus-send \
> - ${bindir}/dbus-monitor \
> + ${bindir}/dbus-monitor \
> + ${bindir}/dbus-launch \
> ${libexecdir}/dbus* \
> ${sysconfdir} \
> ${datadir}/dbus-1/services \
> - ${datadir}/dbus-1/system-services"
> + ${datadir}/dbus-1/system-services \
> + ${MESSAGEHOME} \
> + ${UUIDDIR}"
> FILES_${PN}-lib = "${libdir}/lib*.so.*"
> RRECOMMENDS_${PN}-lib = "${PN}"
> FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool"
>
> -pkg_postinst_dbus() {
> - # can't do adduser stuff offline
> - if [ "x$D" != "x" ]; then
> - exit 1
> - fi
> -
> - MESSAGEUSER=messagebus
> - MESSAGEHOME=/var/run/dbus
> - UUIDDIR=/var/lib/dbus
> -
> - mkdir -p $MESSAGEHOME
> - mkdir -p $UUIDDIR
> - chgrp "$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || addgroup "$MESSAGEUSER"
> - chown "$MESSAGEUSER":"$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || \
> - adduser --system --home "$MESSAGEHOME" --no-create-home --disabled-password \
> - --ingroup "$MESSAGEUSER" "$MESSAGEUSER"
> +pkg_postinst_${PN}() {
> + chgrp "${MESSAGEUSER}" "${MESSAGEHOME}"
> + chown "${MESSAGEUSER}":"${MESSAGEUSER}" "${MESSAGEHOME}"
> + chown "${MESSAGEUSER}":"${MESSAGEUSER}" "${UUIDDIR}"
>
> - chown "$MESSAGEUSER":"$MESSAGEUSER" "$UUIDDIR"
> + chown root:"${MESSAGEUSER}" $D${libexecdir}/dbus-daemon-launch-helper
> + chmod 4754 $D${libexecdir}/dbus-daemon-launch-helper
>
> - grep -q netdev: /etc/group || addgroup netdev
> -
> - chown root:"$MESSAGEUSER" /usr/libexec/dbus-daemon-launch-helper
> - chmod 4754 /usr/libexec/dbus-daemon-launch-helper
> -
> - # add volatile after new user/grp are created
> - echo "d messagebus messagebus 0755 /var/run/dbus none"> /etc/default/volatiles/99_dbus
> - if [ -e /etc/init.d/populate-volatile.sh ] ; then
> + if [ -z "$D" ]&& [ -e /etc/init.d/populate-volatile.sh ] ; then
> /etc/init.d/populate-volatile.sh update
> fi
> }
> @@ -90,11 +83,18 @@ do_install() {
> autotools_do_install
>
> install -d ${D}${sysconfdir}/init.d
> - install -m 0755 ${WORKDIR}/dbus-1.init ${D}${sysconfdir}/init.d/dbus-1
> + sed 's:@SYSCONFDIR@:${sysconfdir}:;s:@BINDIR@:${bindir}:;s:@LOCALSTATEDIR@:${localstatedir}:'< ${WORKDIR}/dbus-1.init> ${D}${sysconfdir}/init.d/dbus-1
> + chmod 755 ${D}${sysconfdir}/init.d/dbus-1
>
> # disable dbus-1 sysv script on systemd installs
> # nearly all distros call the initscript plain 'dbus', but OE-core is different
> ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service
> +
> + install -d ${D}${UUIDDIR}
> + install -d ${D}${MESSAGEHOME}
> +
> + install -d ${D}${sysconfdir}/default/volatiles
> + echo "d messagebus messagebus 0755 ${localstatedir}/run/dbus none"> ${D}${sysconfdir}/default/volatiles/99_dbus
> }
>
> do_install_virtclass-native() {
> diff --git a/meta/recipes-core/dbus/dbus_1.4.12.bb b/meta/recipes-core/dbus/dbus_1.4.12.bb
> index ada53c9..51604aa 100644
> --- a/meta/recipes-core/dbus/dbus_1.4.12.bb
> +++ b/meta/recipes-core/dbus/dbus_1.4.12.bb
> @@ -2,3 +2,4 @@ include dbus.inc
> SRC_URI[md5sum] = "104f2ea94c10a896dfb1edecb5714cb1"
> SRC_URI[sha256sum] = "da3c97fd546610558d588799e27c4fa81101e754acbcd34747a42c131f30dbe7"
>
> +PR = "r6"
^ permalink raw reply
* [PATCH 0/1] fix for mesa-* build failures
From: Saul Wold @ 2011-09-08 4:10 UTC (permalink / raw)
To: openembedded-core
Fixes mesa configure scripts finding host (not native)
python2 executable
The following changes since commit fa8dad209247b780590bc8476b5b16e6608d7907:
avahi: only use gtk if DISTRO_FEATURES includes x11 (2011-09-07 23:44:07 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/fix
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/fix
Saul Wold (1):
python-native: add link for python2
.../recipes-devtools/python/python-native_2.6.6.bb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--
1.7.6
^ permalink raw reply
* [PATCH 1/1] python-native: add link for python2
From: Saul Wold @ 2011-09-08 4:10 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1315454900.git.sgw@linux.intel.com>
Add link for python2 as some configuration tools search from a python2
and could find the host python instead of the python-native.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
.../recipes-devtools/python/python-native_2.6.6.bb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/python/python-native_2.6.6.bb b/meta/recipes-devtools/python/python-native_2.6.6.bb
index 2b00d32..503bd96 100644
--- a/meta/recipes-devtools/python/python-native_2.6.6.bb
+++ b/meta/recipes-devtools/python/python-native_2.6.6.bb
@@ -42,4 +42,7 @@ do_install() {
for PYTHSCRIPT in `grep -rIl ${bindir}/python ${D}${bindir}`; do
sed -i -e '1s|^#!.*|#!/usr/bin/env python|' $PYTHSCRIPT
done
+
+ ln -sf ${D}${bindir}/python ${D}${bindir}/python2
+
}
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 1/1] python-native: add link for python2
From: Saul Wold @ 2011-09-08 6:09 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <968b5b20ecf5bf9372217781135ead2acf8013a2.1315454900.git.sgw@linux.intel.com>
On 09/07/2011 09:10 PM, Saul Wold wrote:
> Add link for python2 as some configuration tools search from a python2
> and could find the host python instead of the python-native.
>
> Signed-off-by: Saul Wold<sgw@linux.intel.com>
> ---
> .../recipes-devtools/python/python-native_2.6.6.bb | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/meta/recipes-devtools/python/python-native_2.6.6.bb b/meta/recipes-devtools/python/python-native_2.6.6.bb
> index 2b00d32..503bd96 100644
> --- a/meta/recipes-devtools/python/python-native_2.6.6.bb
> +++ b/meta/recipes-devtools/python/python-native_2.6.6.bb
> @@ -42,4 +42,7 @@ do_install() {
> for PYTHSCRIPT in `grep -rIl ${bindir}/python ${D}${bindir}`; do
> sed -i -e '1s|^#!.*|#!/usr/bin/env python|' $PYTHSCRIPT
> done
> +
> + ln -sf ${D}${bindir}/python ${D}${bindir}/python2
> +
This is the right idea, but clearly this is the wrong execution for
shared state, I tried a ${STAING_DIR...} variant but that also failed,
what am I doing wrong?
I see this type of ln usage in other recipes.
Sau!
> }
^ permalink raw reply
* Re: [PATCH] dbus: fix paths in startup script, use useradd.bbclass for user creation
From: Phil Blundell @ 2011-09-08 6:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E683D5E.70103@linux.intel.com>
On Wed, 2011-09-07 at 20:58 -0700, Saul Wold wrote:
> On 09/07/2011 01:28 PM, Phil Blundell wrote:
> > Replace various hard-coded references to /usr, /var and /etc with symbolic equivalents.
> >
> > Also replace adhoc usage of adduser/addgroup with useradd.bbclass
> > functionality. This should, in theory, remove the need for a postinst
> > to be run at boot time.
> >
> > Signed-off-by: Phil Blundell<philb@gnu.org>
>
> This one seems to have some problems:
>
> ERROR: Function 'useradd_sysroot' failed (see
> /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/x86_64-poky-linux/dbus-1.4.12-r6/temp/log.do_install.19825
> for further information)
> ERROR: Logfile of failure stored in:
> /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/x86_64-poky-linux/dbus-1.4.12-r6/temp/log.do_install.19825
> Log data follows:
> | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc',
> 'bit-64', 'x86_64-linux', 'common']
> | ERROR: Function 'useradd_sysroot' failed (see
> /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/x86_64-poky-linux/dbus-1.4.12-r6/temp/log.do_install.19825
> for further information)
> | Running groupadd commands...
> | sent invalidate(passwd) request, exiting
> | sent invalidate(group) request, exiting
> | sent invalidate(group) request, exiting
> | sent invalidate(passwd) request, exiting
> | sent invalidate(group) request, exiting
> | sent invalidate(group) request, exiting
> | Running useradd commands...
> | useradd: group messagebus exists - if you want to add this user to
> that group, use -g.
> NOTE: package dbus-1.4.12-r6: task do_install: Failed
That sounds a bit like the useradd option parsing bug (in shadow-native)
that I mentioned the other day. I had meant to send a patch for that
but I forgot.
Do any other recipes which use useradd.bbclass work for you?
p.
^ permalink raw reply
* Re: Race condition when building external kernel modules
From: Anders Darander @ 2011-09-08 7:08 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <20110907175510.GB3215@chargestorm.se>
* Anders Darander <anders@chargestorm.se> [110907 19:55]:
> I've seen a race condition when building multiple external kernel
> modules.
>
> We are running with BB_NUMBER_THREADS set to 8 or 16, depending on the
> build host, thus multiple external kernel modules can be built
> simultaneously.
>
> In our layer, we have two small kernel modules, whose recipes inherits
> module.bbclass. Often when doing either a clean build, or after cleaning
> the two packages, we get a race issue.
>
> At the end of the mail is a short excerpt of the bitbake output after
> the failure. The exact failure differs from run to run, but generally it
> is similar to this:
At the end is a new failure, one that is much more like the "standard"
failure that I see when this race occurs. In this case, only one of the
modules fails, and the other module will succeed. (In the previous mail
was an unusual case were both modules failed...).
> i.e. something under scripts in the sysroot gets rebuild in bitbake
> threads, but one will fail as the depfile has been removed. At least
> that's my interpretation of the most common failure. (Previously, it has
> often been the depfile scripts/basic/.fixdeps.d that has been missing).
This (above) is the most common failure, however like in the failure at
the end, scripts/basic/fixdep could error with a "Text file busy",
giving the same symptoms.
> Do there exist any framework (locks?) to disallow two different recipes
> to be build simultaneously?
> Should the compile stage in the module bbclass be guarded with a
> lock/mutex?
>
> Any other ideas at how this should be attacked?
>
> For our developers, this is mostly an annoying issue; the real issue will
> start when we're setting up some autobuilders for our own distro...
Excerpt from new (more standard-like) failure:
NOTE: package at91-bootcount-1.0-r3: task do_compile: Started
NOTE: package ccudrv-1.0-r4: task do_compile: Started
ERROR: Function 'do_compile' failed (see /home/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/at91-bootcount-1.0-r3/temp/log.do_compile.20860 for further information)
ERROR: Logfile of failure stored in: /home/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/at91-bootcount-1.0-r3/temp/log.do_compile.20860
Log data follows:
| + cd /home/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/at91-bootcount-1.0-r3/git
| + do_compile
| + module_do_compile
| + do_make_scripts
| + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
| + oe_runmake 'CC=arm-oe-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb' 'LD=arm-oe-linux-gnueabi-ld ' 'AR=arm-oe-linux-gnueabi-ar ' -C /home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel scripts
| + '[' xmake = x ']'
| + bbnote make -e MAKEFLAGS= 'CC=arm-oe-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb' 'LD=arm-oe-linux-gnueabi-ld ' 'AR=arm-oe-linux-gnueabi-ar ' -C /home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel scripts
| + echo 'NOTE: make -e MAKEFLAGS= CC=arm-oe-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb LD=arm-oe-linux-gnueabi-ld AR=arm-oe-linux-gnueabi-ar -C /home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel scripts'
| NOTE: make -e MAKEFLAGS= CC=arm-oe-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb LD=arm-oe-linux-gnueabi-ld AR=arm-oe-linux-gnueabi-ar -C /home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel scripts
| + make -e MAKEFLAGS= 'CC=arm-oe-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb' 'LD=arm-oe-linux-gnueabi-ld ' 'AR=arm-oe-linux-gnueabi-ar ' -C /home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel scripts
| make: Entering directory `/home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel'
| make[1]: Entering directory `/home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel'
| HOSTCC scripts/basic/fixdep
| /bin/sh: scripts/basic/fixdep: Text file busy
| make[1]: *** [scripts/basic/fixdep] Error 1
| make[1]: Leaving directory `/home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel'
| make: *** [scripts_basic] Error 2
| make: Leaving directory `/home/anders/oe-build/build-ccu/tmp-eglibc/sysroots/ccu/kernel'
| + die 'oe_runmake failed'
| + bbfatal 'oe_runmake failed'
| + echo 'ERROR: oe_runmake failed'
| ERROR: oe_runmake failed
| + exit 1
| ERROR: Function 'do_compile' failed (see /home/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/at91-bootcount-1.0-r3/temp/log.do_compile.20860 for further information)
NOTE: package at91-bootcount-1.0-r3: task do_compile: Failed
ERROR: Task 19 (/home/anders/oe-build/openembedded-core/../chargestorm/recipes/at91-bootcount/at91-bootcount.bb, do_compile) failed with exit code '1'
Waiting for 1 active tasks to finish:
0: ccudrv-1.0-r4 do_compile (pid 20861)
NOTE: package ccudrv-1.0-r4: task do_compile: Succeeded
ERROR: '/home/anders/oe-build/openembedded-core/../chargestorm/recipes/at91-bootcount/at91-bootcount.bb' failed
--
Anders Darander
ChargeStorm AB
^ permalink raw reply
* Re: [PATCH 1/1] image-types: add btrfs as a supported fstype
From: Anders Darander @ 2011-09-08 7:13 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <9DA5872FEF993D41B7173F58FCF6BE94DEFEF755@orsmsx504.amr.corp.intel.com>
* Kamble, Nitin A <nitin.a.kamble@intel.com> [110907 20:28]:
> > -----Original Message----- From:
> > openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> > Of Anders Darander Sent: Wednesday, September 07, 2011 12:16 AM To:
> > openembedded-core@lists.openembedded.org Subject: Re: [OE-core]
> > [PATCH 1/1] image-types: add btrfs as a supported fstype
> >
> > As Joshua already replied, this isn't enough. This raises one
> > question, though. Have you successfully built btrfs-image? If so, I
> > assume that you have more patches locally, otherwise you should
> > resist submitting patches, unless they're clearly marked as RFC
> > (request for comments, and thus not to be applied).
>
> All these pieces Josh mentioned are already in the tree. I found this
> new line, and saw btrfs was not listed in it so added there also. The
> btrfs support in yocto is working with Linux-yocto 3.x kernel. The
> btrfs kernel config needs to be enabled, I have sent a patch for that
> implementing it as a kernel feature, Once that is there then also need
> to enable the btrfs feature in the Linux-yocto kernel recipe. I will
> send a patch for that too.
My apologies.
You're correct in that the pieces mentioned by Josh is already in the
tree.
However, the commit log should probably have included something like
"enabling btrfs support for hob", perhaps worded slightly better.
Cheers,
Anders
--
Anders Darander
ChargeStorm AB
^ permalink raw reply
* [PULL v2 0/1] fix for mesa-* build failures
From: Saul Wold @ 2011-09-08 7:18 UTC (permalink / raw)
To: openembedded-core
Fixes mesa configure scripts finding host (not native)
python2 executable
v2: Bump PR!
Found the right combination of args for link and sstate!
Sau!
The following changes since commit fa8dad209247b780590bc8476b5b16e6608d7907:
avahi: only use gtk if DISTRO_FEATURES includes x11 (2011-09-07 23:44:07 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/fix
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/fix
Saul Wold (1):
python-native: add link for python2
.../recipes-devtools/python/python-native_2.6.6.bb | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
--
1.7.6
^ permalink raw reply
* [PULL v2 1/1] python-native: add link for python2
From: Saul Wold @ 2011-09-08 7:18 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1315466194.git.sgw@linux.intel.com>
Add link for python2 as some configuration tools search from a python2
and could find the host python instead of the python-native.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
.../recipes-devtools/python/python-native_2.6.6.bb | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/python/python-native_2.6.6.bb b/meta/recipes-devtools/python/python-native_2.6.6.bb
index 2b00d32..e0a4fb3 100644
--- a/meta/recipes-devtools/python/python-native_2.6.6.bb
+++ b/meta/recipes-devtools/python/python-native_2.6.6.bb
@@ -1,6 +1,6 @@
require python.inc
DEPENDS = "openssl-native bzip2-full-native zlib-native readline-native sqlite3-native"
-PR = "${INC_PR}.3"
+PR = "${INC_PR}.4"
LIC_FILES_CHKSUM = "file://LICENSE;md5=38fdd546420fab09ac6bd3d8a1c83eb6"
@@ -42,4 +42,7 @@ do_install() {
for PYTHSCRIPT in `grep -rIl ${bindir}/python ${D}${bindir}`; do
sed -i -e '1s|^#!.*|#!/usr/bin/env python|' $PYTHSCRIPT
done
+
+ ln -sf python ${D}${bindir}/python2
+
}
--
1.7.6
^ permalink raw reply related
* Re: [RFC] Layer rework proposal
From: Martin Jansa @ 2011-09-08 7:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <79EAF6DF-304E-43B7-B97B-1FA6FFEBB91C@beagleboard.org>
[-- Attachment #1: Type: text/plain, Size: 3659 bytes --]
On Fri, Sep 02, 2011 at 01:01:44PM +0200, Koen Kooi wrote:
> Hi,
>
> This has come up in the past, but no one has had time to site down and write a proposal yet.
>
> Problem description: The OE-core layer has both too much in it and not enough.
>
> Currently OE-core is basically a relabeling of the poky fork of OE. Due to that heritage is has bits in it that aren't considered 'core', but serve as a testbed for the proper core metadata. The prime example of this is the sato suite. To address this we will need to come up with guidelines what goes into OE-core and what people expect to get out of it. Here's a start:
>
> Highlevel goals:
>
> 1) Have a high quality set of "core" metadata
> 2) OE-core needs to be useful on its own
> 3) OE-core needs to be testable on its own
>
> Concrete rootfs goals:
>
> a) be able to build for the 4 blessed architectures: arm, mips, powerpc, x86
> b) have multilib support
> c) be able to build a rootfs that has:
> o package management (rpm/deb/opkg)
> o networking support (ifupdown/connman/dnsmasq)
> o have remote access (dropbear/openssh)
> o have user management (shadow/pam)
>
> I think it's safe to say that we all agree on that minimum set of goals. The tricky thing is where to put multimedia and GUI stuff. Qt and GTK are important enough to get put in core, but where do we draw the line? Where do we stop splitting things in recipes-* and start splitting them into layers and should those layers live in seperate repositories?
>
> My list of non-BSP, non-distro layers is:
>
> BBLAYERS = " \
> ${TOPDIR}/sources/meta-openembedded/meta-oe \
> ${TOPDIR}/sources/meta-openembedded/meta-efl \
> ${TOPDIR}/sources/meta-openembedded/meta-gpe \
> ${TOPDIR}/sources/meta-openembedded/meta-gnome \
> ${TOPDIR}/sources/meta-openembedded/meta-xfce \
> ${TOPDIR}/sources/openembedded-core/meta \
> "
>
> The gpe, gnome and xfce layers need things like glib-2.0 and gtk, but there's a larger overlay between the 3, so gpe and xfce end up depending on the gnome layer. Meta-oe is the place where people put things they don't want to maintain in a seperate layer, which isn't going to scale longterm.
>
> My not-so-fully-formed idea is:
>
> core - implements above goals
> x11 - base xorg libs, headers, apps. Has bbappends for core recipes to add x11 support via DISTRO_FEATURES
> gtk - base gtk things, libs, themes, icons, modules
> qt - base qt things + qwt
>
> efl - depends on core,x11
> gnome - depends on core,x11,gtk
> gpe - depends on core,x11,gtk
> opie - depends on core,qt
> sato - depends on core,x11,gtk
> xfce - depends on core,x11,gtk, gnome
>
> and finally:
>
> oe - leftovers
>
> With this layer structure as starting point can we start a discussion on how people would like to set it split? I'd like to leave the question of which layer goes into what repository for later.
I like this proposal.
The point of being able to test oe-core also with graphics (sato) is
right, but to test that oe-core is usable in oe-core/x11/gtk/sato layer
stack is IMHO even more important as many people are using oe-core just
as one of the layers.
I've started to merge and upgrade x11 recipes from meta-oe to oe-core
(to be able to create x11 layer from it, if we decide so).
http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/x11
http://git.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=jansa/x11
http://git.shr-project.org/git/?p=meta-smartphone.git;a=shortlog;h=refs/heads/x11
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: Core image recipes
From: Paul Eggleton @ 2011-09-08 7:35 UTC (permalink / raw)
To: Saul Wold; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4E683C38.20506@linux.intel.com>
On Thursday 08 September 2011 04:53:28 you wrote:
> Now I understand what you are talking about, it might best to split this
> into 2 tasks a task-core moved to recipes-core/tasks and a
> task-core-x11, what about that?
I think that's the only way this can really work, yes.
> >> I can't access the LSB specs website right now
> >> unfortunately but does this have an official name within LSB? It's not
> >> "LSB-Core" is it?
> >
> > Yep, it's LSB-Core (yet another meaning of "core", sigh...)
>
> We could rename basic to task-lsb-core if that's what your thinking, but
> as you point out yet another "core".
Then again, if you're talking about LSB it makes sense to use the correct
terminology.
> >> If there's demand for a minimal image with package management (someone
> >> asked for this on IRC just the other day, and it makes sense to me at
> >> least) then that's what I'd suggest turning this into. In which case it
> >> ought to be called core-image-minimal-pkgmgmt or something similar.
> >
> > Any opinions on this one?
>
> I think this is one that they can create themselves it's would be distro
> specific and would require additional space allocated to the rootfs,
> best for the distro do. Remember we are trying to provide foundations
> and examples. core-image-minimal is supposed to be the smallest possible
> image with login and shell. It can be used by someone to build on.
That's exactly what I am thinking about. Since we already have such an image
(core-image-base) that isn't being used for anything else, why not make it
into something useful? Right now since core-image-minimal overrides
IMAGE_INSTALL you can't use IMAGE_FEATURES and POKY_EXTRA_INSTALL to extend
it, nor does it have package management that some users would be expecting; I
think it would be useful to have a base image where those mechanisms do work.
(Maybe the term "minimal" wouldn't apply to this image.)
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox