* Re: base.bbclass: Implement PACKAGECONFIG
From: Martin Jansa @ 2011-10-06 14:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317910715.6398.84.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
On Thu, Oct 06, 2011 at 03:18:27PM +0100, Richard Purdie wrote:
> These enabled options to be specified in the form:
>
> PACKAGECONFIG ?? = "<default options>"
> PACKAGECONFIG[foo] = "--enable-foo,--disable-foo,foo_depends,foo_runtime_depends"
>
> So that DEPENDS, RDEPENDS_${PN} and EXTRA_OECONF can be automatically
> built from specific options. Those options can easily be customised
> by the distro config or the user.
>
> Based on some ideas from Chris Elston <celston@katalix.com> but with
> an improved easier to use one line interface.
1) How can user check on target if his package was built with foo enabled?
- is there some plan to keep this in ipk/deb metadata?
2) Is it possible to force some PACKAGECONFIG enable/disabled from
DEPENDS/RDEPENDS, ie bar_1.0.bb with foo enabled, depends not only on
abc recipe but needs abc also with foo enabled.
Regards,
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 7cd6efa..f539744 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -291,6 +291,44 @@ do_build () {
> python () {
> import exceptions, string, re
>
> + # Handle PACKAGECONFIG
> + #
> + # These take the form:
> + #
> + # PACKAGECONFIG ?? = "<default options>"
> + # PACKAGECONFIG[foo] = "--enable-foo,--disable-foo,foo_depends,foo_runtime_depends"
> + pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
> + if pkgconfig:
> + def appendVar(varname, appends):
> + if not appends:
> + return
> + varname = bb.data.expand(varname, d)
> + content = d.getVar(varname, False) or ""
> + content = content + " " + " ".join(appends)
> + d.setVar(varname, content)
> +
> + extradeps = []
> + extrardeps = []
> + extraconf = []
> + for flag, flagval in (d.getVarFlags("PACKAGECONFIG") or {}).items():
> + if flag == "defaultval":
> + continue
> + items = flagval.split(",")
> + if len(items) == 3:
> + enable, disable, depend = items
> + rdepend = ""
> + elif len(items) == 4:
> + enable, disable, depend, rdepend = items
> + if flag in pkgconfig:
> + extradeps.append(depend)
> + extrardeps.append(rdepend)
> + extraconf.append(enable)
> + else:
> + extraconf.append(disable)
> + appendVar('DEPENDS', extradeps)
> + appendVar('RDEPENDS_${PN}', extrardeps)
> + appendVar('EXTRA_OECONF', extraconf)
> +
> # If PRINC is set, try and increase the PR value by the amount specified
> princ = bb.data.getVar('PRINC', d, True)
> if princ:
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCH] xserver-xf86: Use PACKAGECONFIG for udev/hal choice and default to udev
From: Richard Purdie @ 2011-10-06 14:21 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc b/meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc
index 000aea3..4c8b732 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-common.inc
@@ -35,3 +35,8 @@ FILES_${PN}-dbg += "${libdir}/xorg/modules/.debug \
SRC_URI += "file://macro_tweak.patch"
EXTRA_OECONF = "--with-fop=no"
+
+PACKAGECONFIG ??= "udev"
+PACKAGECONFIG[hal] = "--enable-config-hal,--disable-config-hal,,hal"
+PACKAGECONFIG[udev] = "--enable-config-udev,--disable-config-udev,,udev"
+
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
index 3aca760..6b13873 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite.inc
@@ -6,7 +6,7 @@ LIB_DEPS = "pixman virtual/libgl libxfont xtrans libxau libxext libxdmcp libdrm
DEPENDS = "${PROTO_DEPS} ${LIB_DEPS}"
-RDEPENDS_${PN} += "hal xorg-minimal-fonts"
+RDEPENDS_${PN} += "xorg-minimal-fonts"
FILES_${PN} += "${bindir}/Xorg "
@@ -34,4 +34,3 @@ EXTRA_OECONF += "--disable-static \
# Due to mesa-dri
COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
-
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.10.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.10.1.bb
index 035e39c..b797f97 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.10.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.10.1.bb
@@ -7,7 +7,7 @@ PROTO_DEPS += "xf86driproto dri2proto"
DEPENDS += "font-util"
PE = "1"
-PR = "r1"
+PR = "r3"
SRC_URI += "file://crosscompile.patch"
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_git.bb b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_git.bb
index 066ff13..87ba040 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_git.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=74df27b6254cc88d2799b5f4f5949c00"
SRCREV = "6689e8add183835274a70ee013e5d3bc8023681f"
PE = "1"
-PR = "r1"
+PR = "r3"
PV = "1.10+git${SRCPV}"
PROTO_DEPS += "xf86driproto dri2proto"
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc b/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc
index 5447058..131c258 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite.inc
@@ -8,7 +8,7 @@ LIB_DEPS = "pixman libxfont xtrans libxau libxext libxdmcp libdrm libxkbfile lib
DEPENDS = "${PROTO_DEPS} ${LIB_DEPS}"
-RDEPENDS_${PN} += "hal xorg-minimal-fonts"
+RDEPENDS_${PN} += "xorg-minimal-fonts"
FILES_${PN} += "${bindir}/Xorg "
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.10.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.10.1.bb
index 5575c0f..e42f27d 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.10.1.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-lite_1.10.1.bb
@@ -2,7 +2,7 @@ require xserver-xf86-lite.inc
LIC_FILES_CHKSUM = "file://COPYING;md5=74df27b6254cc88d2799b5f4f5949c00"
-PR = "r1"
+PR = "r3"
DEPENDS += "font-util"
^ permalink raw reply related
* [PATCH] native.bbclass: Ensure native recipes have a deterministic baselib value
From: Richard Purdie @ 2011-10-06 14:20 UTC (permalink / raw)
To: openembedded-core
Changes to baselib by specific machine configuration were resulting
in sstate cache invalidation, particularly in multilib configurations.
This patch ensures this doesn't happen and native sstate cache files
are reusable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 5e45aed..ba8b0bf 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -69,6 +69,8 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
libdir = "${STAGING_DIR_NATIVE}${libdir_native}"
+baselib = "lib"
+
# Libtool's default paths are correct for the native machine
lt_cv_sys_lib_dlsearch_path_spec[unexport] = "1"
^ permalink raw reply related
* sstate.bbclass: Ensure machine specific stamps are only wiped for the current task
From: Richard Purdie @ 2011-10-06 14:19 UTC (permalink / raw)
To: openembedded-core
sstate was being a little too ethusiastic about removing stamp files and
was removing stamp files for other machines when it shouldn't have been.
This patch teaches sstate about machine specific stamp extensions and
allows it to only remove the current task's stampfiles.
Based on a patch from Phil Blundell <philb@gnu.org> with some tweaks
from me.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index eee04ab..6abf55b 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -259,10 +259,15 @@ def sstate_clean(ss, d):
bb.utils.unlockfile(lock)
stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
+ extrainf = d.getVarFlag("do_" + ss['task'], 'stamp-extra-info')
oe.path.remove(stfile)
oe.path.remove(stfile + "_setscene")
- oe.path.remove(stfile + ".*")
- oe.path.remove(stfile + "_setscene" + ".*")
+ if extrainf:
+ oe.path.remove(stfile + ".*" + extrainf)
+ oe.path.remove(stfile + "_setscene" + ".*" + extrainf)
+ else:
+ oe.path.remove(stfile + ".*")
+ oe.path.remove(stfile + "_setscene" + ".*")
CLEANFUNCS += "sstate_cleanall"
^ permalink raw reply related
* image.bbclass: No need to run most tasks except do_rootfs
From: Richard Purdie @ 2011-10-06 14:19 UTC (permalink / raw)
To: openembedded-core
Running fetch/unpack/patch/compile/install etc. is pointless
since the only image task that does anything is the rootfs task.
Hence mark the useless tasks as noexec so we don't bother running them.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 0b75dce..05f4331 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -315,4 +315,16 @@ rootfs_trim_schemas () {
EXPORT_FUNCTIONS zap_root_password remove_init_link do_rootfs make_zimage_symlink_relative set_image_autologin rootfs_update_timestamp rootfs_no_x_startup
-addtask rootfs before do_build after do_install
+do_fetch[noexec] = "1"
+do_unpack[noexec] = "1"
+do_patch[noexec] = "1"
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+do_install[noexec] = "1"
+do_populate_sysroot[noexec] = "1"
+do_package[noexec] = "1"
+do_package_write_ipk[noexec] = "1"
+do_package_write_deb[noexec] = "1"
+do_package_write_rpm[noexec] = "1"
+
+addtask rootfs before do_build
^ permalink raw reply related
* base.bbclass: Implement PACKAGECONFIG
From: Richard Purdie @ 2011-10-06 14:18 UTC (permalink / raw)
To: openembedded-core
These enabled options to be specified in the form:
PACKAGECONFIG ?? = "<default options>"
PACKAGECONFIG[foo] = "--enable-foo,--disable-foo,foo_depends,foo_runtime_depends"
So that DEPENDS, RDEPENDS_${PN} and EXTRA_OECONF can be automatically
built from specific options. Those options can easily be customised
by the distro config or the user.
Based on some ideas from Chris Elston <celston@katalix.com> but with
an improved easier to use one line interface.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 7cd6efa..f539744 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -291,6 +291,44 @@ do_build () {
python () {
import exceptions, string, re
+ # Handle PACKAGECONFIG
+ #
+ # These take the form:
+ #
+ # PACKAGECONFIG ?? = "<default options>"
+ # PACKAGECONFIG[foo] = "--enable-foo,--disable-foo,foo_depends,foo_runtime_depends"
+ pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
+ if pkgconfig:
+ def appendVar(varname, appends):
+ if not appends:
+ return
+ varname = bb.data.expand(varname, d)
+ content = d.getVar(varname, False) or ""
+ content = content + " " + " ".join(appends)
+ d.setVar(varname, content)
+
+ extradeps = []
+ extrardeps = []
+ extraconf = []
+ for flag, flagval in (d.getVarFlags("PACKAGECONFIG") or {}).items():
+ if flag == "defaultval":
+ continue
+ items = flagval.split(",")
+ if len(items) == 3:
+ enable, disable, depend = items
+ rdepend = ""
+ elif len(items) == 4:
+ enable, disable, depend, rdepend = items
+ if flag in pkgconfig:
+ extradeps.append(depend)
+ extrardeps.append(rdepend)
+ extraconf.append(enable)
+ else:
+ extraconf.append(disable)
+ appendVar('DEPENDS', extradeps)
+ appendVar('RDEPENDS_${PN}', extrardeps)
+ appendVar('EXTRA_OECONF', extraconf)
+
# If PRINC is set, try and increase the PR value by the amount specified
princ = bb.data.getVar('PRINC', d, True)
if princ:
^ permalink raw reply related
* base.bbclass: Minor cleanup
From: Richard Purdie @ 2011-10-06 14:17 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 57f1c3f..7cd6efa 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -202,7 +202,6 @@ def preferred_ml_updates(d):
addhandler base_eventhandler
python base_eventhandler() {
- from bb import note, error, data
from bb.event import getName
name = getName(e)
@@ -212,7 +211,7 @@ python base_eventhandler() {
statusvars = ['BB_VERSION', 'TARGET_ARCH', 'TARGET_OS', 'MACHINE', 'DISTRO', 'DISTRO_VERSION','TUNE_FEATURES', 'TARGET_FPU']
statuslines = ["%-17s = \"%s\"" % (i, bb.data.getVar(i, e.data, 1) or '') for i in statusvars]
- layers = (data.getVar("BBLAYERS", e.data, 1) or "").split()
+ layers = (bb.data.getVar("BBLAYERS", e.data, 1) or "").split()
layers_branch_rev = ["%-17s = \"%s:%s\"" % (os.path.basename(i), \
base_get_metadata_git_branch(i, None).strip(), \
base_get_metadata_git_revision(i, None)) \
@@ -248,9 +247,6 @@ python base_eventhandler() {
generate_git_config(e)
pkgarch_mapping(e.data)
preferred_ml_updates(e.data)
-
- if not data in e.__dict__:
- return
}
addtask configure after do_patch
^ permalink raw reply related
* [PATCH] qt4: Added support for QtMobility 1.2
From: Dmitry Cherukhin @ 2011-10-06 13:56 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <18ec3fbf0667f2780460bad2d4d100849c1239ca>
The QtMobility is a Qt add-on which allows to include standard mobile
functionality to Qt applications. For details, see
http://qt.nokia.com/products/qt-addons/mobility/
The patch is intended to add support for the QtMobility 1.2 package to OE.
Added two recipes:
1) qt-mobility-x11 builds the QtMobility 1.2 package
on the basis of Qt/X11 using the qt4-x11-free package;
2) qt-mobility-embedded builds the QtMobility 1.2 package
on the basis of Qt/Embedded using the qt4-embedded package.
Signed-off-by: Dmitry Cherukhin <dima_ch@emcraft.com>
---
meta/recipes-qt/qt4/qt-mobility-embedded_1.2.0.bb | 11 ++++
meta/recipes-qt/qt4/qt-mobility-x11_1.2.0.bb | 10 +++
meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 62 +++++++++++++++++++++
3 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-qt/qt4/qt-mobility-embedded_1.2.0.bb
create mode 100644 meta/recipes-qt/qt4/qt-mobility-x11_1.2.0.bb
create mode 100644 meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
diff --git a/meta/recipes-qt/qt4/qt-mobility-embedded_1.2.0.bb b/meta/recipes-qt/qt4/qt-mobility-embedded_1.2.0.bb
new file mode 100644
index 0000000..0c30e5f
--- /dev/null
+++ b/meta/recipes-qt/qt4/qt-mobility-embedded_1.2.0.bb
@@ -0,0 +1,11 @@
+DESCRIPTION = "Qt Mobility 1.2.0 - version for Qt/Embedded"
+DEPENDS = "qt4-embedded"
+SECTION = "libs"
+qtm_embedded := "embedded"
+qtm_dir = "qtopia"
+qtm_glflags := "-=opengl"
+qtm_extra_config := "gstreamer-photography_enabled = no"
+
+inherit qt4e
+require qt-mobility_${PV}.inc
+
diff --git a/meta/recipes-qt/qt4/qt-mobility-x11_1.2.0.bb b/meta/recipes-qt/qt4/qt-mobility-x11_1.2.0.bb
new file mode 100644
index 0000000..cd7d5b5
--- /dev/null
+++ b/meta/recipes-qt/qt4/qt-mobility-x11_1.2.0.bb
@@ -0,0 +1,10 @@
+DESCRIPTION = "Qt Mobility 1.2.0 - version for Qt/X11"
+DEPENDS = "qt4-x11-free"
+SECTION = "x11/libs"
+qtm_embedded := ""
+qtm_dir = "qt4"
+qtm_glflags := "${@base_contains('DISTRO_FEATURES', 'opengl', '+=opengl', '-=opengl', d)} "
+qtm_extra_config := ""
+
+inherit qt4x11
+require qt-mobility_${PV}.inc
diff --git a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
new file mode 100644
index 0000000..f665e64
--- /dev/null
+++ b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
@@ -0,0 +1,62 @@
+HOMEPAGE = "http://qt.nokia.com"
+DEPENDS += "pulseaudio bluez4"
+
+LICENSE = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://LICENSE.LGPL;md5=fbc093901857fcd118f065f900982c24 \
+ file://LGPL_EXCEPTION.txt;md5=411080a56ff917a5a1aa08c98acae354"
+
+SRC_URI = "http://get.qt.nokia.com/qt/add-ons/qt-mobility-opensource-src-${PV}.tar.gz "
+
+SRC_URI[md5sum]="ea5db5a8d3dd4709c2926dceda646bd8"
+SRC_URI[sha256sum]="ee3c88975e04139ac9589f76d4be646d44fcbc4c8c1cf2db621abc154cf0ba44"
+
+S = "${WORKDIR}/qt-mobility-opensource-src-${PV}"
+
+qtm_bin := "/usr/bin/${qtm_dir}"
+qtm_lib := "/usr/lib"
+qtm_include := "/usr/include/${qtm_dir}"
+qtm_examples := "/usr/bin/${qtm_dir}/examples/QtMobility"
+qtm_demos := "/usr/bin/${qtm_dir}/demos/QtMobility"
+qtm_plugins := "/usr/lib/${qtm_dir}/plugins/QtMobility"
+qtm_data := "/usr/share/${qtm_dir}"
+qtm_imports := "/usr/lib/${qtm_dir}/imports"
+
+do_configure_prepend() {
+ cp qtmobility.pro qtmobility.pro.old
+ sed -e 's@...QT_INSTALL_DATA.@${qtm_data}@' <qtmobility.pro.old >qtmobility.pro
+ for NAME in plugins/declarative/*/*.pro
+ do
+ cp $NAME $NAME.old
+ sed -e 's@...QT_INSTALL_IMPORTS.@${qtm_imports}@' <$NAME.old >$NAME
+ done
+ cp staticconfig.pri staticconfig.pri.old
+ echo "include(${STAGING_DATADIR}/${qtm_dir}/mkspecs/qconfig.pri)" >staticconfig.pri
+ cat staticconfig.pri.old >>staticconfig.pri
+ ./configure -qmake-exec qmake2 -prefix /usr -examples -demos
+ echo QT_MOBILITY_BIN = ${qtm_bin} >>./config.pri
+ echo QT_MOBILITY_LIB = ${qtm_lib} >>./config.pri
+ echo QT_MOBILITY_INCLUDE = ${qtm_include} >>./config.pri
+ echo QT_MOBILITY_PLUGINS = ${qtm_plugins} >>./config.pri
+ echo QT_MOBILITY_EXAMPLES = ${qtm_examples} >>./config.pri
+ echo QT_MOBILITY_DEMOS = ${qtm_demos} >>./config.pri
+ echo QT_CONFIG ${qtm_glflags} >>./config.pri
+ echo bluez_enabled = yes >>./config.pri
+ echo ${qtm_extra_config} >>./config.pri
+ echo CONFIG += ${qtm_embedded} >>./config.pri
+}
+
+do_install() {
+ for NAME in */*.prf
+ do
+ cp $NAME $NAME.old
+ sed -e 's@/usr@${STAGING_BINDIR}/..@' <$NAME.old >$NAME
+ done
+ oe_runmake install INSTALL_ROOT=${D}
+}
+
+PACKAGES = "${PN}-dbg ${PN} ${PN}-dev"
+
+FILES_${PN}-dbg = "${qtm_bin}/.debug ${qtm_examples}/.debug ${qtm_demos}/.debug ${qtm_lib}/.debug ${qtm_plugins}/*/.debug \
+ ${qtm_imports}/*/.debug ${qtm_imports}/*/*/.debug /usr/src/debug"
+FILES_${PN} = "${qtm_bin} ${qtm_examples} ${qtm_demos} ${qtm_lib}/*.so.1* ${qtm_plugins} ${qtm_imports}"
+FILES_${PN}-dev = "/usr"
--
1.7.6.2
^ permalink raw reply related
* [PATCH] util-linux: split fsck* into its own subpackage
From: Koen Kooi @ 2011-10-06 12:09 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
This will allow systemd to run /sbin/fsck without dragging in all of util-linux
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta/recipes-core/util-linux/util-linux.inc | 16 +++++++++++++---
meta/recipes-core/util-linux/util-linux_2.19.1.bb | 2 +-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index afce673..4818d6f 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -29,7 +29,7 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk util-linux-sfd
util-linux-swaponoff util-linux-losetup util-linux-umount \
util-linux-mount util-linux-readprofile util-linux-libblkid \
util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev \
- util-linux-uuidgen util-linux-lscpu"
+ util-linux-uuidgen util-linux-lscpu util-linux-fsck"
EXTRA_OECONF = "--disable-use-tty-group --disable-makeinstall-chown --enable-elvtune --enable-init --enable-kill --enable-last \
--enable-mesg --enable-partx --enable-raw --enable-rdev --enable-reset \
@@ -54,6 +54,8 @@ FILES_util-linux-libuuid = "${libdir}/libuuid.so.*"
FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${libdir}/libuuid.a ${libdir}/libuuid.la ${includedir}/uuid"
FILES_util-linux-lscpu = "${bindir}/lscpu"
+FILES_util-linux-fsck = "${base_sbindir}/fsck*"
+
RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile "
RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup perl"
@@ -172,7 +174,6 @@ pkg_postinst_${PN} () {
update-alternatives --install ${base_sbindir}/pivot_root pivot_root pivot_root.${PN} 100
# update-alternatives --install ${base_sbindir}/sln sln sln.${PN} 100
update-alternatives --install ${base_sbindir}/mkfs.minix mkfs.minix mkfs.minix.${PN} 100
- update-alternatives --install ${base_sbindir}/fsck.minix fsck.minix fsck.minix.${PN} 100
update-alternatives --install ${bindir}/hexdump hexdump hexdump.${PN} 100
update-alternatives --install ${bindir}/last last last.${PN} 100
update-alternatives --install ${bindir}/logger logger logger.${PN} 100
@@ -201,7 +202,6 @@ pkg_prerm_${PN} () {
update-alternatives --remove shutdown shutdown.${PN}
# update-alternatives --remove sln sln.${PN}
update-alternatives --remove mkfs.minix mkfs.minix.${PN}
- update-alternatives --remove fsck.minix fsck.minix.${PN}
update-alternatives --remove hexdump hexdump.${PN}
update-alternatives --remove last last.${PN}
update-alternatives --remove logger logger.${PN}
@@ -252,4 +252,14 @@ pkg_prerm_util-linux-swaponoff () {
update-alternatives --remove swapon swapon.${PN}
}
+pkg_postinst_util-linux-fsck () {
+ update-alternatives --install ${base_sbindir}/fsck.minix fsck.minix fsck.minix.${PN} 100
+ update-alternatives --install ${base_sbindir}/fsck fsck.${PN} 100
+}
+
+pkg_prerm_util-linux-fsck () {
+ update-alternatives --remove fsck.minix fsck.minix.${PN}
+ update-alternatives --remove /fsck fsck.${PN}
+}
+
BBCLASSEXTEND = "native"
diff --git a/meta/recipes-core/util-linux/util-linux_2.19.1.bb b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
index 5b327cb..f6ddf37 100644
--- a/meta/recipes-core/util-linux/util-linux_2.19.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
@@ -1,5 +1,5 @@
MAJOR_VERSION = "2.19"
-PR = "r5"
+PR = "r6"
require util-linux.inc
# note that `lscpu' is under GPLv3+
--
1.6.6.1
^ permalink raw reply related
* Re: pkg-config bug crashes 'bitbake glib-2.0-native' in FC15.x86_64
From: dashesy @ 2011-10-06 8:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317809123.14671.127.camel@ted>
On Wed, Oct 5, 2011 at 4:05 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2011-10-05 at 11:01 +0100, Richard Purdie wrote:
>> On Wed, 2011-10-05 at 03:21 -0600, dashesy wrote:
>> > Hi,
>> >
>> > I am using these in my local.conf with master branch of oe-core:
>> > DISTRO="angstrom-2010.x"
>> > MACHINE="beagleboard"
>> >
>> > The build for 'bitbake glib-2.0-native' (or actually 'bitbake
>> > meta-toolchain') will finally reach a run.do_configure for 'package
>> > glib-2.0-native-1_2.28.8-r5: task do_configure: Started'
>> > which runs the "oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/pkg-config"
>> > for auto build
>> > This leads to the following chain
>> > pkg-config(cross)->gnome-config->pkg-config->glib-config->pkg-config->...
>> >
>> > dashesy 21266 21265 21266 0 1 01:56 pts/0 00:00:00 /bin/sh -e
>> > /home/dashesy/buildroot/oe-core/build/tmp-eglibc/work/x86_64-linux/glib-2.0-native-1_2.28.8-r5/temp/run.do_configure.21265
>> > root 21870 935 21870 0 1 01:56 ? 00:00:00 sleep 60
>> > dashesy 22246 21266 22246 0 1 01:56 pts/0 00:00:00 /bin/sh
>> > /home/dashesy/buildroot/oe-core/build/tmp-eglibc/work/x86_64-linux/glib-2.0-native-1_2.28.8-r5/glib-2.28.8/configure
>> > --build=x86_64-linux --host=x86_64-linux --target=x86_64-linux
>> > --prefix=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr
>> > --exec_prefix=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr
>> > --bindir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin
>> > --sbindir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/sbin
>> > --libexecdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec
>> > --datadir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share
>> > --sysconfdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/etc
>> > --sharedstatedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/com
>> > --localstatedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/var
>> > --libdir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/lib
>> > --includedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include
>> > --oldincludedir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include
>> > --infodir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/info
>> > --mandir=/home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/man
>> > --disable-silent-rules --disable-dependency-tracking --disable-dtrace
>> > --disable-systemtap --enable-nls --enable-dtrace=no
>> > dashesy 22671 22246 22671 0 1 01:56 pts/0 00:00:00
>> > /home/dashesy/buildroot/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/pkg-config
>> > --exists --print-errors zlib
>> > dashesy 22672 22671 22672 0 1 01:56 pts/0 00:00:00 sh -c
>> > gnome-config --libs zlib > /dev/null 2>&1
>>
>> Something odd is happening here. We have a patch in OE-Core against
>> pkg-config which should disable "leagacy" pkg-config functionality.
>>
>> I took a look and it somehow looks like the patch got broken. Could you
>> try again with
>>
>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip8&id=de51d6ffae1d6a4f594687d5bdef25e731f44dfa
>>
>> applied please? I think this should fix this problem.
>
> Sorry, this should be:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip8&id=8d04d67271e5698ede8c08d3b6e3d4d7e38ffb0c
>
The patch worked, no more recursive calls and bitbake succeeds too, thanks!
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Regards,
dashesy
^ permalink raw reply
* Re: [PATCH 3/6] Add new IMAGE_CLASSES variable for classes for image generation
From: McClintock Matthew-B29882 @ 2011-10-06 0:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317858811.6398.36.camel@ted>
On Wed, Oct 5, 2011 at 6:53 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> So this does not work properly, I thought I tested it but... need to
>> do something like this:
>>
>> IMAGE_CLASSES = "image_types"
>> inherit ${IMAGE_CLASSES}
>>
>> then let the user added via
>>
>> IMAGE_CLASESS += "image_types_uboot"
>>
>> then there will always be something that is expanded to avoid this issue:
>>
>> ERROR: Could not inherit file classes/$IMAGE_CLASSES.bbclass
>> | ETA: --:--:--
>> ERROR: Command execution failed: Exited with 1
>
> Its not expanding the variables? :/ This happened even when
> IMAGE_CLASSES had a value before the inherit?
If I added a IMAGE_CLASSES to something other than "" it worked fine.
If I left it as "" it tried to expand the blank var and look in the
BBPATHS or wherever it looks for classes for an unnamed ".bbclass"
file.
-M
^ permalink raw reply
* Re: [PATCH 3/6] Add new IMAGE_CLASSES variable for classes for image generation
From: Richard Purdie @ 2011-10-05 23:53 UTC (permalink / raw)
To: McClintock Matthew-B29882,
Patches and discussions about the oe-core layer
In-Reply-To: <CAEsOVNeNerChRP+bA8D354J2M+og5TPkWO9e_83rNLLbRZS4Jw@mail.gmail.com>
On Wed, 2011-10-05 at 22:52 +0000, McClintock Matthew-B29882 wrote:
> On Tue, Oct 4, 2011 at 5:03 PM, Matthew McClintock <msm@freescale.com> wrote:
> > -inherit image_types
> > +IMAGE_CLASESS ??= ""
> > +inherit image_types ${IMAGE_CLASSES}
>
> So this does not work properly, I thought I tested it but... need to
> do something like this:
>
> IMAGE_CLASSES = "image_types"
> inherit ${IMAGE_CLASSES}
>
> then let the user added via
>
> IMAGE_CLASESS += "image_types_uboot"
>
> then there will always be something that is expanded to avoid this issue:
>
> ERROR: Could not inherit file classes/$IMAGE_CLASSES.bbclass
> | ETA: --:--:--
> ERROR: Command execution failed: Exited with 1
Its not expanding the variables? :/ This happened even when
IMAGE_CLASSES had a value before the inherit?
> or
>
> ERROR: Could not inherit file classes/.bbclass
> | ETA: --:--:--
> ERROR: Command execution failed: Exited with 1
I'd be prepared to call this last one a bitbake bug...
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 3/6] Add new IMAGE_CLASSES variable for classes for image generation
From: McClintock Matthew-B29882 @ 2011-10-05 22:52 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
In-Reply-To: <1317765787-19127-3-git-send-email-msm@freescale.com>
On Tue, Oct 4, 2011 at 5:03 PM, Matthew McClintock <msm@freescale.com> wrote:
> -inherit image_types
> +IMAGE_CLASESS ??= ""
> +inherit image_types ${IMAGE_CLASSES}
So this does not work properly, I thought I tested it but... need to
do something like this:
IMAGE_CLASSES = "image_types"
inherit ${IMAGE_CLASSES}
then let the user added via
IMAGE_CLASESS += "image_types_uboot"
then there will always be something that is expanded to avoid this issue:
ERROR: Could not inherit file classes/$IMAGE_CLASSES.bbclass
| ETA: --:--:--
ERROR: Command execution failed: Exited with 1
or
ERROR: Could not inherit file classes/.bbclass
| ETA: --:--:--
ERROR: Command execution failed: Exited with 1
-M
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Saul Wold @ 2011-10-05 22:51 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8CB801.7050003@balister.org>
On 10/05/2011 01:03 PM, Philip Balister wrote:
> On 10/05/2011 03:35 PM, Khem Raj wrote:
>> On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<philip@balister.org>
>> wrote:
>>>
>>> 1) I do not want rpm in the image. This would confuse my customer base.
>>> 2) I am tired of dropbear, I want openssh only.
>>> 3) I need the full versions of tools, not the busybox ones.
>>> 4) I am not limited to gpv2 software.
>>>
>>> Richard, it looks to me like we should add an item for the next Yocto
>>> development cycle to review how images are built and try to make the
>>> base
>>> stuff in oe-core more usable by everyone. We need to define what
>>> choices are
>>> made by distros. For example opkg, rpm, no package management in image.
>>> Images may want dropbear or openssh.
>>>
>>> Short term, I think I'll copy the tasks/images into my bsp and get some
>>> stuff together for testing. I'd like a better long term solution though.
>>
>> There always will be customizations needed. But we can strive for
>> better basic blocks
>
> Sure. The immediate things I noticed are rpm being installed and lack of
> a way to chose between dropbear/openssh.
>
> I think it is worth having a conversation to find out if when can make
> it easier for users to create images, with a small number of knobs to turn.
>
I agree, your 4 items above make sense and we could create a set of
tasks that can be use it as building blocks, I think that
task-core-basic could be a starting point for that.
We did work to enable the selection of either openssh/dropbear but at an
IMAGE_FEATURE level, not as a DISTRO_FEATURE or virtual.
Let's see what you come up with for your tasks and we can go from there.
Thanks
Sau!
> Philip
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH v2 1/6] Fix mdadm for powerpc64
From: McClintock Matthew-B29882 @ 2011-10-05 22:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E8CD4A9.5020802@gmail.com>
On Wed, Oct 5, 2011 at 5:05 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On 10/5/2011 2:26 PM, Matthew McClintock wrote:
>>
>> This takes an upstream fix for compiling on powerpc64
>
> where is the patch ? Did you forget git add
Ugh yes, resent.
-M
^ permalink raw reply
* [PATCH v3 1/6] Fix mdadm for powerpc64
From: Matthew McClintock @ 2011-10-05 22:13 UTC (permalink / raw)
To: openembedded-core
This takes an upstream fix for compiling on powerpc64
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
.../0001-mdadm-fix-build-failures-ppc64.patch | 50 ++++++++++++++++++++
meta/recipes-extended/mdadm/mdadm_3.2.2.bb | 6 ++-
2 files changed, 54 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch
diff --git a/meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch b/meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch
new file mode 100644
index 0000000..931ecbc
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/0001-mdadm-fix-build-failures-ppc64.patch
@@ -0,0 +1,50 @@
+From 19986c721c9ac4b353c8592998d70d0dc8860bfd Mon Sep 17 00:00:00 2001
+From: Milan Broz <mbroz@redhat.com>
+Date: Thu, 14 Jul 2011 13:58:36 +1000
+Subject: [PATCH] mdadm: fix build failures (ppc64)
+
+This patch fixes these build issues:
+
+super-intel.c: In function 'getinfo_super_imsm_volume':
+super-intel.c:2327:4: error: format '%llu' expects argument of type 'long long
+unsigned int', but argument 3 has type '__u64' [-Werror=format]
+
+super-intel.c: In function 'imsm_reshape_super':
+super-intel.c:8665:7: error: 'devnum' may be used uninitialized in this function [-Werror=uninitialized]
+
+Signed-off-by: Milan Broz <mbroz@redhat.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+---
+ super-intel.c | 9 ++++++---
+ 1 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/super-intel.c b/super-intel.c
+index 5ea3b36..70cf993 100644
+--- a/super-intel.c
++++ b/super-intel.c
+@@ -2326,7 +2326,9 @@ static void getinfo_super_imsm_volume(struct supertype *st, struct mdinfo *info,
+
+ dprintf("IMSM: General Migration checkpoint : %llu "
+ "(%llu) -> read reshape progress : %llu\n",
+- units, blocks_per_unit, info->reshape_progress);
++ (unsigned long long)units,
++ (unsigned long long)blocks_per_unit,
++ info->reshape_progress);
+
+ used_disks = imsm_num_data_members(dev, 1);
+ if (used_disks > 0) {
+@@ -8661,8 +8663,9 @@ static int imsm_reshape_super(struct supertype *st, long long size, int level,
+ dprintf("imsm: info: Volume operation\n");
+ /* find requested device */
+ while (dev) {
+- imsm_find_array_minor_by_subdev(dev->index, st->container_dev, &devnum);
+- if (devnum == geo.dev_id)
++ if (imsm_find_array_minor_by_subdev(
++ dev->index, st->container_dev, &devnum) == 0
++ && devnum == geo.dev_id)
+ break;
+ dev = dev->next;
+ }
+--
+1.7.6.1
+
diff --git a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
index 5d29ae7..492cc8e 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
@@ -8,9 +8,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://mdmon.c;beginline=4;endline=18;md5=af7d8444d9c4d3e5c7caac0d9d34039d \
file://mdadm.h;beglinlne=4;endline=22;md5=462bc9936ac0d3da110191a3f9994161"
-PR = "r0"
+PR = "r1"
-SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2"
+SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2 \
+ file://0001-mdadm-fix-build-failures-ppc64.patch \
+ "
SRC_URI[md5sum] = "12ee2fbf3beddb60601fb7a4c4905651"
SRC_URI[sha256sum] = "0d1a04e688b082bc88846e3f524abd50bc782b6ffc06123140f7d358c8f9b906"
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH v2 1/6] Fix mdadm for powerpc64
From: Khem Raj @ 2011-10-05 22:05 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1317850009-7714-1-git-send-email-msm@freescale.com>
On 10/5/2011 2:26 PM, Matthew McClintock wrote:
> This takes an upstream fix for compiling on powerpc64
where is the patch ? Did you forget git add
>
> Signed-off-by: Matthew McClintock<msm@freescale.com>
> ---
> meta/recipes-extended/mdadm/mdadm_3.2.2.bb | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
> index 5d29ae7..492cc8e 100644
> --- a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
> +++ b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
> @@ -8,9 +8,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
> file://mdmon.c;beginline=4;endline=18;md5=af7d8444d9c4d3e5c7caac0d9d34039d \
> file://mdadm.h;beglinlne=4;endline=22;md5=462bc9936ac0d3da110191a3f9994161"
>
> -PR = "r0"
> +PR = "r1"
>
> -SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2"
> +SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2 \
> + file://0001-mdadm-fix-build-failures-ppc64.patch \
> + "
>
> SRC_URI[md5sum] = "12ee2fbf3beddb60601fb7a4c4905651"
> SRC_URI[sha256sum] = "0d1a04e688b082bc88846e3f524abd50bc782b6ffc06123140f7d358c8f9b906"
^ permalink raw reply
* [PATCH v2 5/6] Fix sysprof for powerpc64
From: Matthew McClintock @ 2011-10-05 21:26 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1317850009-7714-1-git-send-email-msm@freescale.com>
__ppc64__ is not defined on powerpc64, rather __powerpc64__ is, this
uses a patch that is already upstream to fix builds for powerpc64
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
...PowerPC-checks-for-__NR_perf_counter_open.patch | 35 ++++++++++++++++++++
meta/recipes-kernel/sysprof/sysprof_git.bb | 1 +
2 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch
diff --git a/meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch b/meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch
new file mode 100644
index 0000000..041054e
--- /dev/null
+++ b/meta/recipes-kernel/sysprof/files/0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch
@@ -0,0 +1,35 @@
+Upstream-Status: Backport
+
+From 4708a509aa9d65ae93e9824e42ddbc6e8d42d90c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel@daenzer.net>
+Date: Sat, 27 Aug 2011 20:04:44 +0200
+Subject: [PATCH] Fix PowerPC checks for __NR_perf_counter_open.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+__ppc__ isn't defined here on Debian powerpc. Grepping through the headers
+installed in /usr/include, there are a few references to __ppc__ and
+__ppc64__, but I suspect they're for other OSs.
+
+Signed-off-by: Michel Dänzer <michel@daenzer.net>
+---
+ collector.c | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/collector.c b/collector.c
+index b28964f..fe16967 100644
+--- a/collector.c
++++ b/collector.c
+@@ -175,7 +175,7 @@ sysprof_perf_counter_open (struct perf_counter_attr *attr,
+ #define __NR_perf_counter_open 337
+ #elif defined(__hppa__)
+ #define __NR_perf_counter_open 318
+-#elif defined(__ppc__) || defined(__ppc64__)
++#elif defined(__powerpc__) || defined(__powerpc64__)
+ #define __NR_perf_counter_open 319
+ #elif defined(__s390__)
+ #define __NR_perf_counter_open 331
+--
+1.7.6.1
+
diff --git a/meta/recipes-kernel/sysprof/sysprof_git.bb b/meta/recipes-kernel/sysprof/sysprof_git.bb
index 10bde04..c553263 100644
--- a/meta/recipes-kernel/sysprof/sysprof_git.bb
+++ b/meta/recipes-kernel/sysprof/sysprof_git.bb
@@ -10,6 +10,7 @@ PV = "1.1.8+git${SRCPV}"
SRC_URI = "git://git.gnome.org/sysprof;protocol=git \
file://define-NT_GNU_BUILD_ID.patch \
+ file://0001-Fix-PowerPC-checks-for-__NR_perf_counter_open.patch \
"
SRC_URI_append_arm = " file://rmb-arm.patch"
--
1.7.6.1
^ permalink raw reply related
* [PATCH v2 1/6] Fix mdadm for powerpc64
From: Matthew McClintock @ 2011-10-05 21:26 UTC (permalink / raw)
To: openembedded-core
This takes an upstream fix for compiling on powerpc64
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
meta/recipes-extended/mdadm/mdadm_3.2.2.bb | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
index 5d29ae7..492cc8e 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
@@ -8,9 +8,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://mdmon.c;beginline=4;endline=18;md5=af7d8444d9c4d3e5c7caac0d9d34039d \
file://mdadm.h;beglinlne=4;endline=22;md5=462bc9936ac0d3da110191a3f9994161"
-PR = "r0"
+PR = "r1"
-SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2"
+SRC_URI = "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2 \
+ file://0001-mdadm-fix-build-failures-ppc64.patch \
+ "
SRC_URI[md5sum] = "12ee2fbf3beddb60601fb7a4c4905651"
SRC_URI[sha256sum] = "0d1a04e688b082bc88846e3f524abd50bc782b6ffc06123140f7d358c8f9b906"
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH v2 10/16] Fix mdadm for powerpc64
From: McClintock Matthew-B29882 @ 2011-10-05 21:15 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1sqwRyc3M53NNjk+usgwtWWcz=gcV9rxqdQCAiRqcMiq7Q@mail.gmail.com>
On Wed, Oct 5, 2011 at 2:21 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Oct 5, 2011 at 4:34 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Tue, 2011-10-04 at 21:52 +0000, McClintock Matthew-B29882 wrote:
>>> On Mon, Oct 3, 2011 at 4:17 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> >> I can't find a log of this anywhere, it's probably the default
>>> >> compiler warnings for our platform are different?
>>> >
>>> > It would be handy to understand them since I dont see gcc differentiating
>>> > formats between ppc64 and x86_64 which both are 64bit hosts. But obviously
>>> > there is something missing.
>>>
>>> I finally got around to rerunning this without my patch and the errors
>>> are below.
>>
>> I dug into this a bit. To quote asm/types.h:
>>
>> /*
>> * This is here because we used to use l64 for 64bit powerpc
>> * and we don't want to impact user mode with our change to ll64
>> * in the kernel.
>> */
>> #if defined(__powerpc64__) && !defined(__KERNEL__)
>> # include <asm-generic/int-l64.h>
>> #else
>> # include <asm-generic/int-ll64.h>
>> #endif
>>
>> So ppc64 kernel space uses ll64 and userspace uses l64.
>>
>
> thanks this is what I was interested in.
>
>> This means __u64 is a long for ppc64 but a long long for x86_64. The
>> format errors occurs rightly because a ull is being printed from a ul
>> variable. This will happen to work but its messy.
>
> havent seen the code but if its printf like then PRIu64 macro could help.
Well there is an upstream fix for this as well... I've learned my
lesson now to check upstream repo's..
-M
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Philip Balister @ 2011-10-05 21:07 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1763F0CC-3233-4C5B-A933-7A00805D7CF4@dominion.thruhere.net>
On 10/05/2011 12:20 PM, Koen Kooi wrote:
>
>
> Op 5 okt. 2011 om 09:14 heeft Philip Balister<philip@balister.org> het volgende geschreven:
>
>> On 10/04/2011 06:43 PM, Mark Hatle wrote:
>>> On 10/4/11 3:32 PM, Saul Wold wrote:
>>>> On 10/04/2011 01:27 PM, Philip Balister wrote:
>>>>> On 10/04/2011 04:08 PM, Saul Wold wrote:
>>>>>> On 10/04/2011 12:58 PM, Philip Balister wrote:
>>>>>>> I'm about to start bringing some images I use from OE to OE-core. The
>>>>>>> first issue I saw is there is no task-proper-tools in oe-core (where
>>>>>>> oe-core means the set of layers created by the Angstrom setup scripts).
>>>>>>>
>>>>>> Philip,
>>>>>>
>>>>>> Have you looked at task-core-basic, it is supposed to be more of a
>>>>>> desktop like set of tools, the idea being it's heavier weight than core,
>>>>>> will move to supporting the non-graphical part of LSB.
>>>>>>
>>>>>> Another caveat for task-core-basic is that it's the largetest non-gplv3
>>>>>> task that is used by core-image-basic.
>>>>>>
>>>>>> Does this task approach what you are looking for?
>>>>>
>>>>> It looks like a start, but I notice it brings in rpm. I'm not sure if I
>>>>> want that. I would have thought that the package manager would be a
>>>>> distro decision.
>>>>>
>>>> That's a bug that I would certainly take a patch for, unless rpm is
>>>> required as part of LSB, that will need to be verified.
>>>
>>> The ability to install RPM packages is required by the LSB. The LSB does not
>>> require RPM however. (yes I know, odd requirement, but with things like alien
>>> it's doable on debian systems.)
>>>
>>> But yes, RPM is included to satisfy that requirement.
>>
>> This is beginning to look like a trickier problem than I would like. Between oe-core and meta-angstrom, there are a number of tasks/images to start from, but they each have something I don't like:
>>
>> 1) I do not want rpm in the image. This would confuse my customer base.
>> 2) I am tired of dropbear, I want openssh only.
>
> fwiw 0.53 fixed most of my problems (e.g x11 forwarding), does it fix your issues as well?
It is more that users know openssh and sometimes have issues with
dropbear. And image size is not an issue.
Philip
^ permalink raw reply
* Re: Workaround to compile linux-omap_2.6.39.bb?
From: Tasslehoff Kjappfot @ 2011-10-05 20:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317814733.14671.139.camel@ted>
> OE-Core uses fetch2 and that is a tarball from fetch1. You'd need to
> convert that tarball into the form that fetch2 expects and rename it,
> then you stand some chance of it working.
>
> Also note that your recipes needs to be using a fixed source revision
> and that revision needs to be present in that tarball.
>
Thanks for the response, but I managed to find a mirror of linux-omap in the end, and I think I read on the linux-omap ML that the tmlind-repos will be back at kernel.org soon.
- Tasslehoff
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Khem Raj @ 2011-10-05 20:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1317845927.10776.3.camel@scimitar>
On Wed, Oct 5, 2011 at 1:18 PM, Joshua Lock <josh@linux.intel.com> wrote:
> Core images automatically include the correct package manager when the
> image feature package-management is defined for the image.
>
> It would be nice to define a variable/feature to control SSH server.
>
virtual providers could help here.
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Joshua Lock @ 2011-10-05 20:18 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <4E8CB801.7050003@balister.org>
On Wed, 2011-10-05 at 16:03 -0400, Philip Balister wrote:
> On 10/05/2011 03:35 PM, Khem Raj wrote:
> > On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<philip@balister.org> wrote:
> >>
> >> 1) I do not want rpm in the image. This would confuse my customer base.
> >> 2) I am tired of dropbear, I want openssh only.
> >> 3) I need the full versions of tools, not the busybox ones.
> >> 4) I am not limited to gpv2 software.
> >>
> >> Richard, it looks to me like we should add an item for the next Yocto
> >> development cycle to review how images are built and try to make the base
> >> stuff in oe-core more usable by everyone. We need to define what choices are
> >> made by distros. For example opkg, rpm, no package management in image.
> >> Images may want dropbear or openssh.
> >>
> >> Short term, I think I'll copy the tasks/images into my bsp and get some
> >> stuff together for testing. I'd like a better long term solution though.
> >
> > There always will be customizations needed. But we can strive for
> > better basic blocks
>
> Sure. The immediate things I noticed are rpm being installed and lack of
> a way to chose between dropbear/openssh.
Core images automatically include the correct package manager when the
image feature package-management is defined for the image.
It would be nice to define a variable/feature to control SSH server.
Regards,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply
* Re: Bringing an image from OE to OE-Core
From: Philip Balister @ 2011-10-05 20:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soVx-m6aa0xhHeSvPDSBQvwc+L37r1xgTs58ZuCs+XhzQ@mail.gmail.com>
On 10/05/2011 03:35 PM, Khem Raj wrote:
> On Wed, Oct 5, 2011 at 7:14 AM, Philip Balister<philip@balister.org> wrote:
>>
>> 1) I do not want rpm in the image. This would confuse my customer base.
>> 2) I am tired of dropbear, I want openssh only.
>> 3) I need the full versions of tools, not the busybox ones.
>> 4) I am not limited to gpv2 software.
>>
>> Richard, it looks to me like we should add an item for the next Yocto
>> development cycle to review how images are built and try to make the base
>> stuff in oe-core more usable by everyone. We need to define what choices are
>> made by distros. For example opkg, rpm, no package management in image.
>> Images may want dropbear or openssh.
>>
>> Short term, I think I'll copy the tasks/images into my bsp and get some
>> stuff together for testing. I'd like a better long term solution though.
>
> There always will be customizations needed. But we can strive for
> better basic blocks
Sure. The immediate things I noticed are rpm being installed and lack of
a way to chose between dropbear/openssh.
I think it is worth having a conversation to find out if when can make
it easier for users to create images, with a small number of knobs to turn.
Philip
^ 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