Re: [OE-core] [PATCH 1/6] connman: Upgrade to version 0.75
Op 17 jun 2011, om 09:08 heeft Xu, Dongxiao het volgende geschreven: I would say put ofono as a DISTRO_FEATURE You don't need to build ofono to have ofono support in connman. Angstrom (and hence meta-oe) build with it enabled by default to support people who want to use the plugin on their phones. Since it's a nicely seperated plugin, Do you mean connman-plugin-ofono could work correctly without the ofono recipe? According to my understanding, connman-plugin-ofono controls the telephony device by talking with ofonod daemon through dbus mechanism. On another aspect, ofono project has support for different types of modems, and I don't think connman-plugin-ofono has the ability. Therefore I think the ofono recipe is needed. I'm saying that ofono is not a *build* dependency for the connman-ofono plugin. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] connman: Upgrade to version 0.75
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Khem Raj
Sent: Friday, June 17, 2011 7:13 AM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 1/6] connman: Upgrade to version 0.75
On 06/16/2011 07:00 AM, Koen Kooi wrote:
Op 16 jun 2011, om 15:44 heeft Khem Raj het volgende geschreven:
On 6/16/2011 2:35 AM, Phil Blundell wrote:
On Thu, 2011-06-16 at 17:20 +0800, Dongxiao Xu wrote:
Enable ofono plugin into sato image.
[...]
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://src/main.c;beginline=1;endline=20;md5=4b55b550fa6b33cc2055ef30dd2
62b3e
DEPENDS = libgdbus dbus glib-2.0 hal iptables
-RDEPENDS_${PN} = wpa-supplicant resolvconf
+RDEPENDS_${PN} = wpa-supplicant resolvconf ofono
--- a/meta/recipes-connectivity/connman/connman_0.65.bb
+++ b/meta/recipes-connectivity/connman/connman_0.75.bb
@@ -16,14 +16,14 @@ EXTRA_OECONF += \
--disable-udev \
--disable-polkit \
--enable-client \
+ --enable-ofono \
--prefix=/usr --sysconfdir=/etc --localstatedir=/var
These changes look like they will have a rather wider impact than
just the sato image. I'm not sufficiently au fait with connman to
say whether this is a good thing or not (although my immediate
reaction to adding extra RDEPENDS tends to be that it is not), but
if they're going to be added globally then the checkin comment ought
to reflect that and explain why it's being done. Alternatively, you
could do this in your distro layer and/or image recipes.
Yes, the description in commit is not accurate and I will modify it.
Also globally add ofono in connman's RDEPENDS is not good enough. In actual, it
is connman-plugin-ofono who rdepends on ofono recipe.
I will revise it in next version of pull request.
I would say put ofono as a DISTRO_FEATURE
You don't need to build ofono to have ofono support in connman.
Angstrom (and hence meta-oe) build with it enabled by default to
support people who want to use the plugin on their phones. Since it's
a nicely seperated plugin,
Do you mean connman-plugin-ofono could work correctly without the ofono recipe?
According to my understanding, connman-plugin-ofono controls the telephony
device by talking with ofonod daemon through dbus mechanism.
On another aspect, ofono project has support for different types of modems, and
I don't think connman-plugin-ofono has the ability.
Therefore I think the ofono recipe is needed.
even better
DISTRO_FEATURE would be the wrong thing to do.
in such case DISTRO_FEATURE might be secondary choice yes
That's why I keep saying look at the connman recipe in meta-oe, that's
being used by angstrom and SHR with good success.
Thanks Koen for the information.
It has good mechanism to add RDEPENDS to specific connman plugin.
I will include this logic in my next pull request.
Thanks,
Dongxiao
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] ccache: Integrate ccache-native
From: Wenzong Fan wenzong@windriver.com
1) Add ccache as a native tool, for getting it built automatically make
it as the dependency of bzip2; Also, the ccache will be included by SDK
images;
2) Set CCACHE on a per recipe basis and add task 'mkccachedir' to create
the CCACHE_DIR while start a package building;
3) Remove the duplicate 'ccache.inc' from 'meta/class/'.
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
meta/classes/base.bbclass|1 +
meta/classes/ccache.bbclass | 21 +
meta/classes/ccache.inc | 11 ---
meta/conf/bitbake.conf |1 +
meta/recipes-core/tasks/task-core-sdk.bb |1 +
meta/recipes-devtools/ccache/ccache.inc | 16
meta/recipes-devtools/ccache/ccache_3.1.5.bb |8
meta/recipes-extended/bzip2/bzip2_1.0.6.bb |2 ++
8 files changed, 50 insertions(+), 11 deletions(-)
create mode 100644 meta/classes/ccache.bbclass
delete mode 100644 meta/classes/ccache.inc
create mode 100644 meta/recipes-devtools/ccache/ccache.inc
create mode 100644 meta/recipes-devtools/ccache/ccache_3.1.5.bb
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 119b052..a329b4e 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -2,6 +2,7 @@ BB_DEFAULT_TASK ?= build
inherit patch
inherit staging
+inherit ccache
inherit mirrors
inherit utils
diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass
new file mode 100644
index 000..be37c18
--- /dev/null
+++ b/meta/classes/ccache.bbclass
@@ -0,0 +1,21 @@
+# Make ${CCACHE_DIR} if it is not existing
+
+python ccache_do_mkccachedir(){
+ import os
+
+ ccache = bb.data.getVar('CCACHE', d, True)
+ ccache_dir = bb.data.getVar('CCACHE_DIR', d, True)
+ if len(ccache) == 0 or len(ccache_dir) == 0:
+ return
+
+ try:
+ if not os.path.isdir(ccache_dir):
+ bb.note(Creating + ccache_dir)
+ os.makedirs(ccache_dir)
+ except bb.fetch2.BBFetchException, e:
+ raise bb.build.FuncFailed(e)
+}
+
+addtask mkccachedir before do_configure
+
+EXPORT_FUNCTIONS do_mkccachedir
diff --git a/meta/classes/ccache.inc b/meta/classes/ccache.inc
deleted file mode 100644
index d830a1b..000
--- a/meta/classes/ccache.inc
+++ /dev/null
@@ -1,11 +0,0 @@
-# Make ccache use a TMPDIR specific ccache directory if using the
crosscompiler,
-# since it isn't likely to be useful with any other toolchain than the one we
just
-# built, and would otherwise push more useful things out of the default cache.
-
-CCACHE_DIR_TARGET = ${TMPDIR}/ccache
-
-python () {
-if not bb.data.inherits_class('native', d) and not
bb.data.inherits_class('cross', d):
-bb.data.setVar('CCACHE_DIR', '${CCACHE_DIR_TARGET}', d)
-bb.data.setVarFlag('CCACHE_DIR', 'export', '1', d)
-}
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6d8a674..64b3651 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -391,6 +391,7 @@ export PATH
CCACHE = ${@bb.which(bb.data.getVar('PATH', d, 1), 'ccache') and 'ccache '}
TOOLCHAIN_OPTIONS = --sysroot=${STAGING_DIR_TARGET}
+export CCACHE_DIR = ${TMPDIR}/ccache/${TARGET_SYS}/${PN}
export CC = ${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}
export CXX = ${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}
export F77 = ${CCACHE}${HOST_PREFIX}g77 ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}
diff --git a/meta/recipes-core/tasks/task-core-sdk.bb
b/meta/recipes-core/tasks/task-core-sdk.bb
index 4aee0c2..52fdd75 100644
--- a/meta/recipes-core/tasks/task-core-sdk.bb
+++ b/meta/recipes-core/tasks/task-core-sdk.bb
@@ -25,6 +25,7 @@ RDEPENDS_task-core-sdk = \
coreutils \
cpp \
cpp-symlinks \
+ccache \
diffutils \
gcc \
gcc-symlinks \
diff --git a/meta/recipes-devtools/ccache/ccache.inc
b/meta/recipes-devtools/ccache/ccache.inc
new file mode 100644
index 000..e9f7344
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache.inc
@@ -0,0 +1,16 @@
+SUMMARY = a fast C/C++ compiler cache
+DESCRIPTION = ccache is a compiler cache. It speeds up recompilation \
+by caching the result of previous compilations and detecting when the \
+same compilation is being done again. Supported languages are C, C\+\+, \
+Objective-C and Objective-C++.
+HOMEPAGE = http://ccache.samba.org;
+SECTION = devel
+LICENSE = GPLv3+
+
+SRC_URI = http://samba.org/ftp/ccache/ccache-${PV}.tar.gz;
+
+inherit autotools
+
+BBCLASSEXTEND = native
+
+TARGET_CC_ARCH += ${LDFLAGS}
diff --git a/meta/recipes-devtools/ccache/ccache_3.1.5.bb
b/meta/recipes-devtools/ccache/ccache_3.1.5.bb
new file mode 100644
index 000..9a967b2
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache_3.1.5.bb
@@ -0,0 +1,8 @@
+require ccache.inc
+
+PR = r0
+LICENSE = GPLv3+
+LIC_FILES_CHKSUM =
Re: [OE-core] [PATCH 1/1] base-passwd: disable problematic login.defs options
Op 16 jun 2011, om 20:50 heeft Scott Garman het volgende geschreven: This resolves the following runtime errors when various shadow-utils binaries are run: configuration error - unknown item 'FAILLOG_ENAB' (notify administrator) configuration error - unknown item 'LASTLOG_ENAB' (notify administrator) configuration error - unknown item 'OBSCURE_CHECKS_ENAB' (notify administrator) configuration error - unknown item 'PORTTIME_CHECKS_ENAB' (notify administrator) configuration error - unknown item 'QUOTAS_ENAB' (notify administrator) configuration error - unknown item 'MOTD_FILE' (notify administrator) configuration error - unknown item 'FTMP_FILE' (notify administrator) configuration error - unknown item 'NOLOGINS_FILE' (notify administrator) configuration error - unknown item 'ENV_HZ' (notify administrator) configuration error - unknown item 'PASS_MIN_LEN' (notify administrator) configuration error - unknown item 'SU_WHEEL_ONLY' (notify administrator) configuration error - unknown item 'CRACKLIB_DICTPATH' (notify administrator) configuration error - unknown item 'PASS_CHANGE_TRIES' (notify administrator) configuration error - unknown item 'PASS_ALWAYS_WARN' (notify administrator) configuration error - unknown item 'CHFN_AUTH' (notify administrator) configuration error - unknown item 'ENVIRON_FILE' (notify administrator) This fixes bug [YOCTO #1170] Signed-off-by: Scott Garman scott.a.gar...@intel.com Fix confirmed: Acked-by: Koen Kooi k...@dominion.thruhere.net ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] eglibc testing?
On Fri, 2011-06-17 at 11:25 +0100, Richard Purdie wrote: On Fri, 2011-06-17 at 11:13 +0100, Phil Blundell wrote: The thing about nfs is that it's awkward to set up in an automated way. The qemu scripts in OE-Core use usermode NFS by default for booting qemu images... Yeah, indeed, and I think the mechanism that they use to do this supports my assessment of awkward. But presumably it does at least work and I guess that might be the easiest way to do glibc testing as well. For gcc testing I think a dedicated qemu harness is probably a better answer. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] call for participation on openembedded-users mailing list
Fellow Devs We have a mailing list for OE users and of late there has been new users trying to use OE posting questions and calling for help there as developers of OE we are also users by default and it would immensely help the new users from experiences of folks. I would request that we try to help the new users to get upto speed and existing users to keep it using. This will also help in spreading the use of OpenEmbedded technology userbase. You could use gmane to post replies to newsgroup if you dont want to subscribe to the mailing list. Thank you -Khem ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] call for participation on openembedded-users mailing list
Op 17 jun 2011, om 16:26 heeft Khem Raj het volgende geschreven: Fellow Devs We have a mailing list for OE users and of late there has been new users trying to use OE posting questions and calling for help there as developers of OE we are also users by default and it would immensely help the new users from experiences of folks. I would request that we try to help the new users to get upto speed and existing users to keep it using Ehm, that goes against the decission to shut down oe-user we made in the past. The reasoning was that real developers shun user lists, making them useless. And it seems that that hasn't changed. So let's really close that list and discuss things on oe-devel and oe-core ml ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] call for participation on openembedded-users mailing list
On Friday 17 June 2011 15:28:56 Koen Kooi wrote: So let's really close that list and discuss things on oe-devel and oe-core ml I'm on the oe-users mailing list and occasionally help people out, but I have to agree with Koen here. It hardly gets any traffic and the nature of OE is that every user is a developer or considers themselves so. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/9] oe.classutils: add module
From: Chris Larson chris_lar...@mentor.com
This adds a ClassRegistry utility metaclass, as maintaining a class registry
is a fairly common thing to do.
Signed-off-by: Chris Larson chris_lar...@mentor.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/lib/oe/classutils.py | 24
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 meta/lib/oe/classutils.py
diff --git a/meta/lib/oe/classutils.py b/meta/lib/oe/classutils.py
new file mode 100644
index 000..855d2fa
--- /dev/null
+++ b/meta/lib/oe/classutils.py
@@ -0,0 +1,24 @@
+class ClassRegistry(type):
+Maintain a registry of classes, indexed by name.
+
+The name in the registry can be overridden via the 'name' attribute of the
+class, and the 'priority' attribute controls priority. The prioritized()
+method returns the registered classes in priority order.
+registry = {}
+priority = 0
+
+def __init__(cls, name, bases, attrs):
+super(ClassRegistry, cls).__init__(name, bases, attrs)
+if not hasattr(cls, name):
+cls.name = name
+cls.registry[cls.name] = cls
+
+@classmethod
+def prioritized(tcls):
+return sorted(tcls.registry.values(),
+ key=lambda v: v.priority, reverse=True)
+
+def unregister(cls):
+for key in cls.registry.keys():
+if cls.registry[key] is cls:
+del cls.registry[key]
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/9] Rework how the devshell functions
From: Chris Larson chris_lar...@mentor.com
In the new implementation, each known terminal is defined as a class in
oe.terminal, as a subclass of bb.process.Popen. terminal.bbclass wraps this
functionality, providing the metadata pieces. It obeys the OE_TERMINAL
variable, which is a 'choice' typed variable. This variable may be 'auto',
'none', or any of the names of the defined terminals.
When using 'auto', or requesting an unsupported terminal, we attempt to spawn
them in priority order until we get one that's available on this system (and
in the case of the X terminals, has DISPLAY defined). The 'none' value is
used when we're doing things like automated builds, and want to ensure that no
terminal is *ever* spawned, under any circumstances.
Current available terminals:
gnome
konsole
xterm
rxvt
screen
Signed-off-by: Chris Larson chris_lar...@mentor.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/devshell.bbclass | 26 ---
meta/classes/terminal.bbclass | 30
meta/lib/oe/classutils.py | 33 +++--
meta/lib/oe/terminal.py | 102 +
4 files changed, 168 insertions(+), 23 deletions(-)
create mode 100644 meta/classes/terminal.bbclass
create mode 100644 meta/lib/oe/terminal.py
diff --git a/meta/classes/devshell.bbclass b/meta/classes/devshell.bbclass
index 5f262f4..7317d64 100644
--- a/meta/classes/devshell.bbclass
+++ b/meta/classes/devshell.bbclass
@@ -1,22 +1,14 @@
-do_devshell[dirs] = ${S}
-do_devshell[nostamp] = 1
+inherit terminal
-XAUTHORITY ?= ${HOME}/.Xauthority
-devshell_do_devshell() {
- export DISPLAY='${DISPLAY}'
- export DBUS_SESSION_BUS_ADDRESS='${DBUS_SESSION_BUS_ADDRESS}'
- export XAUTHORITY='${XAUTHORITY}'
- export TERMWINDOWTITLE=Bitbake Developer Shell
- export EXTRA_OEMAKE='${EXTRA_OEMAKE}'
- export SHELLCMDS=bash
- ${TERMCMDRUN}
- if [ $? -ne 0 ]; then
- echo Fatal: '${TERMCMD}' not found. Check TERMCMD variable.
- exit 1
- fi
+export XAUTHORITY ?= ${HOME}/.Xauthority
+export SHELL ?= 'bash'
+
+python do_devshell () {
+oe_terminal(d.getVar('SHELL', True), 'OpenEmbedded Developer Shell', d)
}
-addtask devshell after do_patch
-EXPORT_FUNCTIONS do_devshell
+addtask devshell after do_patch
+do_devshell[dirs] = ${S}
+do_devshell[nostamp] = 1
diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
new file mode 100644
index 000..93646f7
--- /dev/null
+++ b/meta/classes/terminal.bbclass
@@ -0,0 +1,30 @@
+OE_TERMINAL ?= 'auto'
+OE_TERMINAL[type] = 'choice'
+OE_TERMINAL[choices] = 'auto none \
+${@ .join(o.name \
+for o in oe.terminal.prioritized())}'
+
+
+def oe_terminal(command, title, d):
+import oe.data
+import oe.terminal
+
+terminal = oe.data.typed_value('OE_TERMINAL', d).lower()
+if terminal == 'none':
+bb.fatal('Devshell usage disabled with OE_TERMINAL')
+elif terminal != 'auto':
+try:
+oe.terminal.spawn(terminal, command, title)
+return
+except oe.terminal.UnsupportedTerminal:
+bb.warn('Unsupported terminal %s, defaulting to auto' %
+terminal)
+except oe.terminal.ExecutionError as exc:
+bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
+
+try:
+oe.terminal.spawn_preferred(command, title)
+except oe.terminal.NoSupportedTerminals:
+bb.fatal('No valid terminal found, unable to open devshell')
+except oe.terminal.ExecutionError as exc:
+bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
diff --git a/meta/lib/oe/classutils.py b/meta/lib/oe/classutils.py
index 855d2fa..922d304 100644
--- a/meta/lib/oe/classutils.py
+++ b/meta/lib/oe/classutils.py
@@ -1,15 +1,36 @@
+__author__ = 'kergoth'
+
class ClassRegistry(type):
Maintain a registry of classes, indexed by name.
-The name in the registry can be overridden via the 'name' attribute of the
-class, and the 'priority' attribute controls priority. The prioritized()
-method returns the registered classes in priority order.
-registry = {}
+Note that this implementation requires that the names be unique, as it uses
+a dictionary to hold the classes by name.
+
+The name in the registry can be overridden via the 'name' attribute of the
+class, and the 'priority' attribute controls priority. The prioritized()
+method returns the registered classes in priority order.
+
+Subclasses of ClassRegistry may define an 'implemented' property to exert
+control over whether the class will be added to the registry (e.g. to keep
+abstract base classes out of the registry).
priority = 0
+class __metaclass__(type):
+Give each ClassRegistry their own registry
+def __init__(cls, name, bases, attrs):
+cls.registry = {}
+
[OE-core] [PATCH 4/9] cmake.bbclass: use CPPFLAGS and CXXFLAGS
Some classes, as for example nativesdk, defines CPPFLAGS and CXXFLAGS
to be passed to compiler. Using those makes more sense and avoid some
hacks on packages using CMake.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/cmake.bbclass |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 011c232..672325e 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -19,10 +19,10 @@ OECMAKE_C_COMPILER ?= `echo ${CC} | sed 's/^\([^
]*\).*/\1/'`
OECMAKE_CXX_COMPILER ?= `echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`
# Compiler flags
-OECMAKE_C_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${TARGET_CPPFLAGS}
-OECMAKE_CXX_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${TARGET_CPPFLAGS}
-fpermissive
-OECMAKE_C_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} -DNDEBUG
-OECMAKE_CXX_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} -DNDEBUG
+OECMAKE_C_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS}
+OECMAKE_CXX_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS}
-fpermissive
+OECMAKE_C_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} ${CPPFLAGS} -DNDEBUG
+OECMAKE_CXX_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} ${CXXFLAGS} -DNDEBUG
OECMAKE_RPATH ?=
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/9] oe.terminal: improve how we spawn screen
From: Chris Larson chris_lar...@mentor.com
- Name the screen session 'devshell', to avoid confusion if running bitbake
itself under a screen session.
- Display a warning message when spawning screen, so it's clear to the user
that screen has been run (otherwise do_devshell just appears to hang).
Signed-off-by: Chris Larson chris_lar...@mentor.com
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/lib/oe/terminal.py |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
index 5336167..bbff8d0 100644
--- a/meta/lib/oe/terminal.py
+++ b/meta/lib/oe/terminal.py
@@ -71,7 +71,12 @@ class Rxvt(XTerminal):
priority = 1
class Screen(Terminal):
-command = 'screen -D -m -t {title} {command}'
+command = 'screen -D -m -t {title} -S devshell {command}'
+
+def __init__(self, command, title=None):
+Terminal.__init__(self, command, title)
+logger.warn('Screen started. Please connect in another terminal with '
+'screen -r devshell')
def prioritized():
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/9] Patches pending on O.S. Systems tree
The following changes since commit 835d817f1ba7b99167743fdb86ba80f3a07bd82d:
systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16 22:12:40 +0100)
are available in the git repository at:
git://github.com/OSSystems/oe-core master
https://github.com/OSSystems/oe-core/tree/master
Chris Larson (3):
oe.classutils: add module
Rework how the devshell functions
oe.terminal: improve how we spawn screen
Otavio Salvador (6):
cmake.bbclass: use CPPFLAGS and CXXFLAGS
cmake: refactor recipe
lib_package.bbclass: move static libraries to ${PN}-staticdev
libxml: extend nativesdk class
libarchive: add 2.8.4 version
cmake: add nativesdk and target versions
meta/classes/cmake.bbclass |8 +-
meta/classes/devshell.bbclass | 26 ++---
meta/classes/lib_package.bbclass |2 +-
meta/classes/terminal.bbclass | 30 ++
meta/lib/oe/classutils.py | 45
meta/lib/oe/terminal.py| 107
meta/recipes-core/libxml/libxml2.inc |3 +-
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb |4 +-
meta/recipes-devtools/cmake/cmake.inc |6 +-
.../cmake/cmake/dont-run-cross-binaries.patch | 22
meta/recipes-devtools/cmake/cmake_2.8.3.bb | 48 +
.../0001-Patch-from-upstream-revision-1990.patch | 42
.../0002-Patch-from-upstream-revision-1991.patch | 31 ++
.../0003-Patch-from-upstream-rev-2516.patch| 63
.../0004-Patch-from-upstream-rev-2514.patch| 33 ++
.../0005-Patch-from-upstream-rev-2520.patch| 31 ++
.../0006-Patch-from-upstream-rev-2521.patch| 28 +
...YS-error-when-setting-up-xattrs.-Closes-5.patch | 31 ++
.../libarchive/libarchive_2.8.4.bb | 25 +
19 files changed, 559 insertions(+), 26 deletions(-)
create mode 100644 meta/classes/terminal.bbclass
create mode 100644 meta/lib/oe/classutils.py
create mode 100644 meta/lib/oe/terminal.py
create mode 100644
meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
create mode 100644 meta/recipes-devtools/cmake/cmake_2.8.3.bb
create mode 100644
meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0004-Patch-from-upstream-rev-2514.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0005-Patch-from-upstream-rev-2520.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0006-Patch-from-upstream-rev-2521.patch
create mode 100644
meta/recipes-extended/libarchive/libarchive/0007-Ignore-ENOSYS-error-when-setting-up-xattrs.-Closes-5.patch
create mode 100644 meta/recipes-extended/libarchive/libarchive_2.8.4.bb
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/9] lib_package.bbclass: move static libraries to ${PN}-staticdev
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/lib_package.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/lib_package.bbclass b/meta/classes/lib_package.bbclass
index 82c9370..5ce8727 100644
--- a/meta/classes/lib_package.bbclass
+++ b/meta/classes/lib_package.bbclass
@@ -5,6 +5,6 @@ FILES_${PN} = ${libexecdir} ${libdir}/lib*${SOLIBS} \
${base_libdir}/*${SOLIBS} \
${datadir}/${PN} ${libdir}/${PN}
FILES_${PN}-dev = ${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
- ${libdir}/*.a ${libdir}/pkgconfig /lib/*.a /lib/*.o \
+ ${libdir}/*.o ${libdir}/pkgconfig /lib/*.o \
${datadir}/aclocal ${bindir}/*-config
FILES_${PN}-bin = ${bindir}/* ${sbindir}/* /bin/* /sbin/*
--
1.7.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] call for participation on openembedded-users mailing list
On 06/17/2011 07:37 AM, Paul Eggleton wrote: On Friday 17 June 2011 15:28:56 Koen Kooi wrote: So let's really close that list and discuss things on oe-devel and oe-core ml I'm on the oe-users mailing list and occasionally help people out, but I have to agree with Koen here. It hardly gets any traffic and the nature of OE is that every user is a developer or considers themselves so. I am fine with closing it down and leaving sort of banner asking folks to join oe-devel. as long as they get some help it serves my concern Cheers, Paul ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Question about apply eglibc configurability to create minimal image
Op 17 jun 2011, om 17:46 heeft Mark Hatle het volgende geschreven:
On 6/17/11 5:05 AM, Kang Kai wrote:
On 2011年06月09日 23:20, Mark Hatle wrote:
On 6/9/11 5:57 AM, Kang Kai wrote:
Hi Mark,
I am focus on eglibc itself compilation with disabling all the
configurable options, right now eglibc can be compiled with disable all
the configurable options.
But when I build core-image-minimal in a clear new directory, some
packages build failed and they need eglibc supports, such as
core-image-minimal is simply to large of an image to see some of the
advantages
of the eglibc configuration. Realistically the advantages come on single
application or small (busybox + single application) systems.
gcc-runtimedepends on libc-libm
The above looks like a bug to me and should be investigated.. (a bug in gcc
that
is..)
ncursedepends onlibc-posix-wchar-io libc-posix-clang-wchar
ncurses can be configured WITHOUT wide character support, the needs to be
done
with any of the wchar options disabled in eglibc.
openssl depends onlibc-inet libc-nsswitch
I'm not sure why openssl needs either inet or nsswitch. inet perhaps if it
tries to make certain socket calls, but libc-nsswitch should never be
required
outside of eglibc. This is likely a configuration issue in openssl -- or a
bug
in eglibc.
gettextdepends onlibc-spawn libc-locale-code
libc-getlogin libc-utmp
...
Once we introduce gettext (beyond simply it's m4 macros) we're no longer in
small system territory. gettext and many others really want some of the
larger system capabilities as they are designed for multilingual systems.
After enable those options, the image size only decrease from 9.6M to
9.4M(qemux86). And the dependencies on eglibc is hard to break,
something like libcrypt getlogin(function) can't be breaken.
Could you give me some directions what should I do with eglibc
configurability?
My suggest is to start with a new custom configuration. (ignore the
gcc-runtime
for right now and enable libm.) The goal of this configuration is a small,
local system -- without network connectivity.
Walk through the core-image-minimal, and you'll see:
IMAGE_INSTALL = task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}
Looking at task-core-boot:
RDEPENDS_task-core-boot = \
base-files \
base-passwd \
busybox \
initscripts \
${@base_contains(MACHINE_FEATURES, keyboard, keymaps, , d)} \
modutils-initscripts \
netbase \
sysvinit \
tinylogin \
udev \
${VIRTUAL-RUNTIME_update-alternatives} \
${MACHINE_ESSENTIAL_EXTRA_RDEPENDS}
RRECOMMENDS_task-core-boot = \
${MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS}
From the above, I'm pretty sure that netbase will require a lot of
networking
components, specifically adding things like libc-inet. So avoid netbase.
It's possible that keyboard/keymaps may cause additional stuff to come in
due to
locale requirements.. so I'd dump those as well..
sysvinit may also introduce some additional items -- so if it causes
problems,
remove it and switch to the init located within busybox.
update-alternatives is what included gettext -- so this might need some
enhancement to avoid gettext as a requirement. So I'd suggest skipping it.
(Note without it, it's likely busybox, tinylogin may not get setup
properly...)
udev is quite complex and drags in a number of components -- so drop that..
Leaving:
base-files \
base-passwd \
busybox \
initscripts \
modutils-initscripts \
sysvinit \
tinylogin
Hi Mark,
According this list, expand with their run time depency(show in the
attachment
minimal-image-runtime-dependies.png) , and the list is:
base-files \
base-passwd \
busybox \
busybox-syslog \
busybox-udhcpc \
initscripts \
makedevs \
modutils-initscripts \
sysvinit \
sysvinit-pidof \
sysvinit-inittab \
tinylogin
When only enable eglibc libm, busybox, sysvinit and tinylogin can't be
compiled.
busybox depends on
* libc-crypt
* libc-getlogin
* libc-inet
* libc-posix-regexp
I wonder that maybe libc-crypt can NOT be disabled? Other 3 options can be
disabled by closing some busybox feature and builtin commands.
I would guess that there are options within busybox that are enabled that make
use of each of these. Do you get a failure in compilation, configuration, or?
You will likely have to shrink busybox down to a shell and a few simple
commands, instead of the normal config.
THat should be straightforward now that we have this one:
http://cgit.openembedded.org/cgit.cgi/openembedded-core/commit/?id=383d94222e8cfc85d0885f60c88c064091866296
and please don't cross-post between poky and oe-core lists...
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base-passwd: disable problematic login.defs options
On 06/17/2011 09:43 AM, Khem Raj wrote: On Fri, Jun 17, 2011 at 9:34 AM, Scott Garmanscott.a.gar...@intel.com wrote: On 06/16/2011 04:54 PM, Khem Raj wrote: On 06/16/2011 11:50 AM, Scott Garman wrote: This resolves the following runtime errors when various shadow-utils binaries are run: configuration error - unknown item 'FAILLOG_ENAB' (notify administrator) configuration error - unknown item 'LASTLOG_ENAB' (notify administrator) configuration error - unknown item 'OBSCURE_CHECKS_ENAB' (notify administrator) configuration error - unknown item 'PORTTIME_CHECKS_ENAB' (notify administrator) configuration error - unknown item 'QUOTAS_ENAB' (notify administrator) configuration error - unknown item 'MOTD_FILE' (notify administrator) configuration error - unknown item 'FTMP_FILE' (notify administrator) configuration error - unknown item 'NOLOGINS_FILE' (notify administrator) configuration error - unknown item 'ENV_HZ' (notify administrator) configuration error - unknown item 'PASS_MIN_LEN' (notify administrator) configuration error - unknown item 'SU_WHEEL_ONLY' (notify administrator) configuration error - unknown item 'CRACKLIB_DICTPATH' (notify administrator) configuration error - unknown item 'PASS_CHANGE_TRIES' (notify administrator) configuration error - unknown item 'PASS_ALWAYS_WARN' (notify administrator) configuration error - unknown item 'CHFN_AUTH' (notify administrator) configuration error - unknown item 'ENVIRON_FILE' (notify administrator) This fixes bug [YOCTO #1170] Signed-off-by: Scott Garmanscott.a.gar...@intel.com --- .../base-passwd/base-passwd-3.5.22/login.defs | 32 ++-- .../recipes-core/base-passwd/base-passwd_3.5.22.bb | 2 +- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs b/meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs index 1d392ac..2708eb6 100644 --- a/meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs +++ b/meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs I wonder if login.defs should be provided at all by base-passwd package. It should come from shadow isnt it ? Hi Khem, The reason for including the login.defs file with base-passwd has to do with the new useradd.bbclass that I developed (Richard is still holding it for code review, but we should see it here soon). The way it works is custom users/groups get added to the passwd/group files in the target machine's sysroot. The shadow utils require a login.defs in order to work. hence it should come from shadow isnt it ? why from base-passwd ? if someone is not using using shadow this file will be useless for him/her isnt it ? Sorry, I forgot to mention that shadow-utils-native is what is used to modify the passwd/group files in the target sysroot. It seems that having a -native recipe install files into a target sysroot would be worse than including an optional file with base-passwd that may or may not be used in target systems. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] call for participation on openembedded-users mailing list
On 06/17/2011 08:41 AM, Khem Raj wrote: On 06/17/2011 07:37 AM, Paul Eggleton wrote: On Friday 17 June 2011 15:28:56 Koen Kooi wrote: So let's really close that list and discuss things on oe-devel and oe-core ml I'm on the oe-users mailing list and occasionally help people out, but I have to agree with Koen here. It hardly gets any traffic and the nature of OE is that every user is a developer or considers themselves so. I am fine with closing it down and leaving sort of banner asking folks to join oe-devel. as long as they get some help it serves my concern I think I am on the users list, but I filter it into my OE folder so I can't quickly see the user verus dev split, but I also agree we should shut down users. We should look at all the OE/Yocto lists and make sure we consolidate lists as things evolve to reduce the number of lists we need to monitor. Philip Cheers, Paul ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] call for participation on openembedded-users mailing list
On Fri, Jun 17, 2011 at 17:31, Philip Balister phi...@balister.org wrote: ... We should look at all the OE/Yocto lists and make sure we consolidate lists as things evolve to reduce the number of lists we need to monitor. May I suggest we to revisit the oe-core mailing list need? On the beggining it made sense since it was clear a new project with too many unclear things going on but what is really the difference to us now between it and oe-devel now? It seems that patches might use a prefix and be good with it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] RFC - combo layer repo tool
Hi Ke, Great work. Here's my review so far: On Monday 13 June 2011 14:15:04 Yu, Ke wrote: --- /dev/null +++ b/scripts/combo-layer-hook-default.sh @@ -0,0 +1,14 @@ +#!/bin/sh +# Take a patch from bitbake and apply to poky This text should be a bit more generic. Maybe Hook to add source component/revision info to commit message --- /dev/null +++ b/scripts/combo-layer.conf.example @@ -0,0 +1,38 @@ +# repo name This should be component name +# leave it empty if no commit updated yet, and then the tool +# will start from the first commit Change this to If empty, the tool will start from the first commit +# hook: if provided, the tool will call the hook to proceed the generated patch from upstream, proceed - process --- /dev/null +++ b/scripts/combo-layer.py Remove the .py extension from the script name, to match our other scripts. (The hook script extension can stay however, it's not meant to be executed directly.) +# Step 2: generate the patch list stored in patch dir +if dest_dir != .: +prefix = --src-prefix=a/%s/ --dst-prefix=b/%s/ % (dest_dir, dest_dir) +else: +prefix = +if repo['last_revision'] == : +logger.info(Warning: last_revision of repo %s is not set, so start from the first commit % name) +patch_cmd_range = --root master +rev_cmd_range = master +else: +patch_cmd_range = master +rev_cmd_range = %s..master % repo['last_revision'] I tested the tool by checking out an older revision of poky, and setting up components for oe-core and bitbake in the config file with last_revisions based on the most recent revisions merged into in my older poky checkout. After running init then update, no changes were applied. Once I changed the else: part of the above code to make patch_cmd_range = rev_cmd_range instead of master the update process worked. I haven't yet tested the filtering or splitpatch but I will do so and let you know the results. Some other suggestions: * During update, print out which component it is updating from as it goes through them (in case the operation fails) * The tool should clean up the temporary patch subdirectory after finishing Cheers, Paul - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base-passwd: disable problematic login.defs options
On 06/17/2011 10:22 AM, Otavio Salvador wrote: On Fri, Jun 17, 2011 at 17:19, Scott Garmanscott.a.gar...@intel.com wrote: Sorry, I forgot to mention that shadow-utils-native is what is used to modify the passwd/group files in the target sysroot. It seems that having a -native recipe install files into a target sysroot would be worse than including an optional file with base-passwd that may or may not be used in target systems. Why not make an shadow-target package with this? To just install a login.defs file? I'm open to it if a few more people think this is a better idea. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] qemu* kernel configs
On Mon, Jun 13, 2011 at 10:41 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 13 jun 2011, om 15:57 heeft Bruce Ashfield het volgende geschreven: On Mon, Jun 13, 2011 at 9:27 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 13 jun 2011, om 14:54 heeft Bruce Ashfield het volgende geschreven: On Mon, Jun 13, 2011 at 8:10 AM, Koen Kooi k...@dominion.thruhere.net wrote: Hi, After finding the bug Scott was running into with systemd-image (no DEVTMPFS support) I have a closer look at the qemarm kernel config and it looks dated to me. If we want to have tools like udev, powertop, iotop, latencytop working we need to revisit the config. From a quick look I found the following items missing/incomplete: * devtmpfs + devtmpfs automounting. Recent udev versions require it * cgroups, systemd requires it * process accounting, *top uses it * fuse, gvfs requires it * autofs4, systemd works a lot better with it So what are people's thoughts on enabling the items that weren't set before and moving modules to built-in were needed? And if it's wanted, does anyone have a quickstart on how these changes should be done properly? My 5 minutes of google and 30 minutes of staring at the meta/ subdir didn't yield results. Hi Koen, The base configuration for the qemu* machines is kept as minimal as possible by design. It is supposed to be used as a building block, not cater to all the different image types we can throw at them by default. It sounds we need to remove the qemu machines from OE-core and replace them with more useful ones if we want people to actually test images with the machine present in OE-core. The current kernel config blocks me from merging a recent udev and systemd into oe-core since it can't be tested with only oe-core in bblayers.conf. I don't think we need to go this far. The configuration as it currently stands is not a golden standard, and in fact is already scheduled for some improvements in the yocto 1.1 timeframe. I'd consider this a suggestion for some new feature groups. I wouldn't considering enabling groups of functionality that the community needs for common higher level functional testing being extra or the kitchen sink. If we come up with feature groups, and name those groups, it is possible to disable them as well as enable them conditionally. I've found minimalistic kernel configs a huge pain since you need to know the mapping between userspace error X and CONFIG_SOMETHING=y, which most people don't know or want to know. With superset configs customers (and users) can tweak it till it breaks, instead of tweaking till it works. There's definitely two sides to this. Keeping the configuration tight and minimal is the embedded roots of these configurations. The problem with large configurations is the test matrix, which is something that we try to take seriously. If there's an explicitly enabled configuration, there's a known test for it and core functionality that can enable it (and for the record, I won't claim that this is 100% followed, but that's something we aim to improve). Having named groups (where they names are the high level functionality) that provide optional configuration that can be enabled, tends to hit the middle ground between these two issues. Users can see the name and grab onto the functionality, while the core set of configs stays clean and small. I'm not saying the qemu kernel configs needs to have everything enabled, since they are emulated machines which simply cannot have various extras (PCI cards) or have a hard time using them (USB devices are a pain in qemu). But having 'basic' things like devtmpfs disabled is counterproductive as Scott and I found out. Agreed. This goes back to the functionality to enable common use cases and requirements. If you want to send suggestions via patches (config fragments and SRC_URI updates) or just send lists of missing functionality and a mapping to the higher level requirement, we can work together to enable what we need and move the rest to optional features or other layers. The changes I made are (diffing the result from extract-ikconfig): An update to this: devtmpfs: -# CONFIG_DEVTMPFS is not set +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y These are good options to have. I've recently turned them on for other kernels, for all arch. I'll be adding this in shortly. cgroups: -# CONFIG_CGROUPS is not set -# CONFIG_NAMESPACES is not set +CONFIG_CGROUPS=y +CONFIG_CGROUP_DEBUG=y +CONFIG_CGROUP_NS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CPUSETS=y +# CONFIG_PROC_PID_CPUSET is not set +CONFIG_CGROUP_CPUACCT=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_CGROUP_MEM_RES_CTLR=y +CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y +CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y +CONFIG_CGROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_BLK_CGROUP=y +#
[OE-core] [RFC PATCH 0/2] Sanity testing network connectivity
In response to a Yocto Bugzilla request[1] I've written a sanity test to check whether BitBake is able to fecth from http, https and git sources. The idea being that if the user is behing a proxy and this test fails we can more easily help them diagnose and fix their problem. I've built on the existing infrastructure for less frequent sanity tests so whilst this test is reasonably heavy it will only run when TMPDIR changes (usually first run?). Further I added a variable to disable just this sanity check. People shipping offline installs to customers should just be able to set the variable in their shipped configuration and not worry about this sanity check irritating people. The error message points to a wiki page[2] which is pretty vanilla right now but the intention would be to flesh it out with guidance on common proxy/nat/etc issues. Please review the following changes for suitability for inclusion. If you have any objections or suggestions for improvement, please respond to the patches. If you agree with the changes, please provide your Acked-by. The following changes since commit 835d817f1ba7b99167743fdb86ba80f3a07bd82d: systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16 22:12:40 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib josh/connection-test http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/connection-test Joshua Lock (2): sanity.bbclass: pass the data object to the less frequent test harnesses sanity: implement network connectivity test meta/classes/sanity.bbclass | 45 +++--- 1 files changed, 37 insertions(+), 8 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 2/2] sanity: implement network connectivity test
Sanity test to verify files can be fetched from the network using git, http and
https fetchers point users at a page to help get set up in the case of a failure
Addresses [YOCTO #933]
Signed-off-by: Joshua Lock j...@linux.intel.com
---
meta/classes/sanity.bbclass | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index bffa4f5..83a9887 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -35,6 +35,8 @@ def check_sanity_tmpdir_change(tmpdir, data):
# Check that TMPDIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
testmsg = check_create_long_filename(tmpdir, TMPDIR)
+# Check that we can fetch from various network transports
+testmsg = testmsg + check_connectivity(data)
return testmsg
def check_sanity_version_change(data):
@@ -75,6 +77,33 @@ def check_create_long_filename(filepath, pathname):
return Failed to create a file in %s: %s % (pathname, strerror)
return
+def check_connectivity(d):
+test_uris= [http://yoctoproject.org/about;,
+
https://eula-downloads.yoctoproject.org/crownbay/crownbay-bernard-5.0.0;,
+
git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD]
+retval =
+
+# Only check connectivity if network and this check enabled
+# Because it's a fairy heavy test allow disabling of just this sanity test
+# by setting DISABLE_NETWORK_SANITY
+data = bb.data.createCopy(d)
+network_disabled = not bb.data.getVar('BB_NO_NETWORK', data, True)
+check_disabled = bb.data.getVar('DISABLE_NETWORK_SANITY', data, True)
+if check_disabled or network_disabled:
+dldir = bb.data.expand('${TMPDIR}/sanity', data)
+bb.data.setVar('DL_DIR', dldir, data)
+
+try:
+fetcher = bb.fetch2.Fetch(test_uris, data)
+fetcher.download()
+ fetcher.clean(test_uris)
+except Exception, e:
+retval = Error connecting to the network to fetch, http/https and
git checked.\nPlease check the wiki
(https://wiki.yoctoproject.org/wiki/Connectivity%20Troubleshooting) for more
suggestions.\n % e
+finally:
+# Make sure we tidy up the cruft
+oe.path.remove(dldir)
+return retval
+
def check_sanity(e):
from bb import note, error, data, __version__
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/2] sanity.bbclass: pass the data object to the less frequent test harnesses
By passing the data object to the less frequently run test harnesses
(check_sanity_tmpdir_change(), check_sanity_sstate_dir_change() and
check_sanity_version_change()) we can run tests against BitBake data here
too.
Signed-off-by: Joshua Lock j...@linux.intel.com
---
meta/classes/sanity.bbclass | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index fc005aa..bffa4f5 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -21,7 +21,7 @@ def check_conf_exists(fn, data):
return True
return False
-def check_sanity_sstate_dir_change(sstate_dir):
+def check_sanity_sstate_dir_change(sstate_dir, data):
# Sanity checks to be done when the value of SSTATE_DIR changes
# Check that SSTATE_DIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
@@ -30,14 +30,14 @@ def check_sanity_sstate_dir_change(sstate_dir):
testmsg = check_create_long_filename(sstate_dir, SSTATE_DIR)
return testmsg
-def check_sanity_tmpdir_change(tmpdir):
+def check_sanity_tmpdir_change(tmpdir, data):
# Sanity checks to be done when the value of TMPDIR changes
# Check that TMPDIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
testmsg = check_create_long_filename(tmpdir, TMPDIR)
return testmsg
-def check_sanity_version_change():
+def check_sanity_version_change(data):
# Sanity checks to be done when SANITY_VERSION changes
return
@@ -262,14 +262,14 @@ def check_sanity(e):
sanity_version = int(data.getVar('SANITY_VERSION', e.data, True) or 1)
if last_sanity_version sanity_version:
-messages = messages + check_sanity_version_change()
-messages = messages + check_sanity_tmpdir_change(tmpdir)
-messages = messages + check_sanity_sstate_dir_change(sstate_dir)
+messages = messages + check_sanity_version_change(e.data)
+messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
+messages = messages + check_sanity_sstate_dir_change(sstate_dir,
e.data)
else:
if last_tmpdir != tmpdir:
-messages = messages + check_sanity_tmpdir_change(tmpdir)
+messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
if last_sstate_dir != sstate_dir:
-messages = messages + check_sanity_sstate_dir_change(sstate_dir)
+messages = messages + check_sanity_sstate_dir_change(sstate_dir,
e.data)
if os.path.exists(conf):
f = file(sanityverfile, 'w')
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
