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 0/1] Integrate ccache-native
From: Wenzong Fan 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/'. The following changes since commit 2163461ec94528ecf046a04edc5db3d2dd3a6b8b: Tom Zanussi (1): systemtap: remove non-core COMPATIBLE_MACHINES are available in the git repository at: git://git.pokylinux.org/poky-contrib wenzong/ccache http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/ccache Wenzong Fan (1): ccache: Integrate ccache-native 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 ___ 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
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
---
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 = "file://LICENSE.txt;md5=8
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 Fix confirmed: Acked-by: Koen Kooi ___ 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 Thu, 2011-06-16 at 16:18 -0700, Khem Raj wrote: > On 06/16/2011 07:29 AM, Phil Blundell wrote: > > On Thu, 2011-06-16 at 06:41 -0700, Khem Raj wrote: > >> I nfsmount eglibc builddir on target and run the testsuite. I see aroung > >> 10-15 fails. Havent run the testsuite in a while > > > > Maybe the right thing to do with eglibc would be to build a rootfs > > containing the testsuite, run it up in qemu-system-arm, and then > > engineer some IPC mechanism to get the test results back to the host. > > using nfs isnt bad either since the tests excercise libraries from /lib > on target IOW installed eglibc. True, though I can't think of any instances where the libc behaviour will change depending on where it's installed. The thing about nfs is that it's awkward to set up in an automated way. What I want is to arrive at a situation where you can just do: $ bitbake -c check micro-base-image (or whatever) and have it build all the necessary components, run their respective testsuites, and generate a report of both the current status and any regressions. Ideally I want this to be doable without a lot of installation-specific fiddling around with networking configuration and suchlike, and I definitely want an arrangement which doesn't rely on having target hardware on hand. Practically speaking I think that means it basically has to be qemu of some kind or another. > Yes I think I should put together my mechanism somewhere and post it > and dejaGNU setup I use for cross testing That would be cool. p. ___ 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:13 +0100, Phil Blundell wrote: > On Thu, 2011-06-16 at 16:18 -0700, Khem Raj wrote: > > On 06/16/2011 07:29 AM, Phil Blundell wrote: > > > On Thu, 2011-06-16 at 06:41 -0700, Khem Raj wrote: > > >> I nfsmount eglibc builddir on target and run the testsuite. I see aroung > > >> 10-15 fails. Havent run the testsuite in a while > > > > > > Maybe the right thing to do with eglibc would be to build a rootfs > > > containing the testsuite, run it up in qemu-system-arm, and then > > > engineer some IPC mechanism to get the test results back to the host. > > > > using nfs isnt bad either since the tests excercise libraries from /lib > > on target IOW installed eglibc. > > True, though I can't think of any instances where the libc behaviour > will change depending on where it's installed. > > 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... > What I want is to arrive at a situation where you can just do: > > $ bitbake -c check micro-base-image (or whatever) > > and have it build all the necessary components, run their respective > testsuites, and generate a report of both the current status and any > regressions. Ideally I want this to be doable without a lot of > installation-specific fiddling around with networking configuration and > suchlike, and I definitely want an arrangement which doesn't rely on > having target hardware on hand. Practically speaking I think that means > it basically has to be qemu of some kind or another. > > > Yes I think I should put together my mechanism somewhere and post it > > and dejaGNU setup I use for cross testing > > That would be cool. We have the automated image QA tests in OE-Core already so perhaps we could extend these to handle the tests somehow? Cheers, Richard ___ 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
This adds a ClassRegistry utility metaclass, as maintaining a class registry
is a fairly common thing to do.
Signed-off-by: Chris Larson
Signed-off-by: Otavio Salvador
---
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
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
Signed-off-by: Otavio Salvador
---
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 = {}
+type.__init__(cls, name, ba
[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
---
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
- 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
Signed-off-by: Otavio Salvador
---
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 5/9] cmake: refactor recipe
* use INC_PR;
* show configure's failure on error;
* gather major version from PV;
Signed-off-by: Otavio Salvador
---
meta/recipes-devtools/cmake/cmake-native_2.8.3.bb |4 ++--
meta/recipes-devtools/cmake/cmake.inc |6 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
b/meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
index 29b3d87..a68a25f 100644
--- a/meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_2.8.3.bb
@@ -1,7 +1,7 @@
-CMAKE_MAJOR_VERSION="2.8"
require cmake.inc
inherit native
-PR = "r1"
+
+PR = "${INC_PR}.1"
SRC_URI[md5sum] = "a76a44b93acf5e3badda9de111385921"
SRC_URI[sha256sum] =
"689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288"
diff --git a/meta/recipes-devtools/cmake/cmake.inc
b/meta/recipes-devtools/cmake/cmake.inc
index eed9346..ec37a10 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -9,11 +9,15 @@ LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://Copyright.txt;md5=f372516292ff7c7bf16a74a5f9a8 \
file://Source/cmake.h;beginline=1;endline=10;md5=341736dae83c9e344b53eeb1bc7d7bc2"
+INC_PR = "r1"
+
+CMAKE_MAJOR_VERSION = "${@'.'.join(bb.data.getVar('PV',d,1).split('.')[0:2])}"
+
SRC_URI =
"http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://support-oe-qt4-tools-names.patch"
inherit autotools
do_configure () {
- ./configure --prefix=${prefix} || die "./bootstrap failed"
+ ./configure --prefix=${prefix}
}
--
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
---
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
[OE-core] [PATCH 7/9] libxml: extend nativesdk class
Signed-off-by: Otavio Salvador
---
meta/recipes-core/libxml/libxml2.inc |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/libxml/libxml2.inc
b/meta/recipes-core/libxml/libxml2.inc
index d9ea816..1187644 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -21,6 +21,7 @@ inherit autotools pkgconfig binconfig
EXTRA_OECONF = "--without-python --without-debug --without-legacy
--without-catalog --without-docbook --with-c14n"
EXTRA_OECONF_virtclass-native = "--with-python=${STAGING_BINDIR}/python
--without-legacy --with-catalog --without-docbook --with-c14n"
+EXTRA_OECONF_virtclass-nativesdk = "--with-python=${STAGING_BINDIR}/python
--without-legacy --with-catalog --without-docbook --with-c14n"
EXTRA_OECONF_linuxstdbase = "--without-python --with-debug --with-legacy
--with-catalog --with-docbook --with-c14n"
# required for pythong binding
@@ -42,4 +43,4 @@ PACKAGES = "${PN}-dbg ${PN}-dev ${PN}-utils ${PN} ${PN}-doc
${PN}-locale"
FILES_${PN}-dev += "${bindir}/*-config ${libdir}/xml2Conf.sh"
FILES_${PN}-utils += "${bindir}/*"
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
--
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 9/9] cmake: add nativesdk and target versions
Adds a recipe that provides the nativesdk and target versions of
CMake.
This recipe is based on code from OpenEmbeeded (rev
b1f2e1501c19540617a829b37415c0616101c7ad).
Signed-off-by: Otavio Salvador
---
.../cmake/cmake/dont-run-cross-binaries.patch | 22 +
meta/recipes-devtools/cmake/cmake_2.8.3.bb | 48
2 files changed, 70 insertions(+), 0 deletions(-)
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
diff --git a/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
b/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
new file mode 100644
index 000..4eb1794
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake/dont-run-cross-binaries.patch
@@ -0,0 +1,22 @@
+cmake: don't run cross-binaries on host machine
+
+When doing the cross build we obviously cannot run those binaries on
+host since they can be binary incompatible.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Otavio Salvador
+
+diff -ru cmake-2.8.2.orig/CMakeLists.txt cmake-2.8.2/CMakeLists.txt
+--- cmake-2.8.2.orig/CMakeLists.txt2010-07-28 00:48:42.0 +0200
cmake-2.8.2/CMakeLists.txt 2010-07-28 01:05:17.0 +0200
+@@ -518,7 +518,8 @@
+
+ # build the remaining subdirectories
+ ADD_SUBDIRECTORY(Source)
+-ADD_SUBDIRECTORY(Utilities)
++# Come on! Running the cross-binaries on host is not a good idea.
++#ADD_SUBDIRECTORY(Utilities)
+ ADD_SUBDIRECTORY(Tests)
+
+ # add a test
diff --git a/meta/recipes-devtools/cmake/cmake_2.8.3.bb
b/meta/recipes-devtools/cmake/cmake_2.8.3.bb
new file mode 100644
index 000..93c98c3
--- /dev/null
+++ b/meta/recipes-devtools/cmake/cmake_2.8.3.bb
@@ -0,0 +1,48 @@
+require cmake.inc
+
+inherit cmake
+
+DEPENDS += "curl expat zlib libarchive ncurses"
+
+PR = "${INC_PR}.0"
+
+SRC_URI += "file://dont-run-cross-binaries.patch"
+
+SRC_URI[md5sum] = "a76a44b93acf5e3badda9de111385921"
+SRC_URI[sha256sum] =
"689ed02786b5cefa5515c7716784ee82a82e8ece6be5a3d629ac3cc0c05fc288"
+
+# Strip ${prefix} from ${docdir}, set result into docdir_stripped
+python () {
+prefix=bb.data.getVar("prefix", d, 1)
+docdir=bb.data.getVar("docdir", d, 1)
+
+if not docdir.startswith(prefix):
+ raise bb.build.FuncFailed('docdir must contain prefix as its prefix')
+
+docdir_stripped = docdir[len(prefix):]
+if len(docdir_stripped) > 0 and docdir_stripped[0] == '/':
+ docdir_stripped = docdir_stripped[1:]
+
+bb.data.setVar("docdir_stripped", docdir_stripped, d)
+}
+
+EXTRA_OECMAKE=" \
+-DCMAKE_DOC_DIR=${docdir_stripped}/cmake-${CMAKE_MAJOR_VERSION} \
+-DCMAKE_USE_SYSTEM_LIBRARIES=1 \
+# This is compiler & target dependant, but it seems cmake does not in fact use
this value.
+-DKWSYS_CHAR_IS_SIGNED=1 \
+# This disables large file support. Hopefully nobody processes >2G files on
the target.
+# If you want to enable this, add -DWKSYS_LFS_WORKS=1
+-DKWSYS_LFS_DISABLE=1 \
+"
+
+# FIXME: Hack due gcc-crosssdk not being able to detect those automatically
+CXXFLAGS_virtclass-nativesdk += " \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++ \
+ -I${STAGING_DIR_HOST}${SDKPATHNATIVE}/usr/include/c++/${TARGET_SYS} \
+ "
+
+FILES_${PN} += "${datadir}/cmake-${CMAKE_MAJOR_VERSION}"
+FILES_${PN}-doc += "${docdir}/cmake-${CMAKE_MAJOR_VERSION}"
+
+BBCLASSEXTEND = "nativesdk"
--
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 8/9] libarchive: add 2.8.4 version
This recipe has been imported from OpenEmbedded (rev
6db4b9050e0e8b963e2a6b63790e48e3042ea99e).
Signed-off-by: Otavio Salvador
---
.../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
8 files changed, 284 insertions(+), 0 deletions(-)
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
diff --git
a/meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
b/meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
new file mode 100644
index 000..f65f89f
--- /dev/null
+++
b/meta/recipes-extended/libarchive/libarchive/0001-Patch-from-upstream-revision-1990.patch
@@ -0,0 +1,42 @@
+libarchive: Backport patch from upstream (revision 1990)
+
+Upstream-Status: Backport
+
+Signed-off-by: Otavio Salvador
+
+diff --git a/libarchive/archive_read_disk_entry_from_file.c
b/libarchive/archive_read_disk_entry_from_file.c
+index 7473c50..27671df 100644
+--- a/libarchive/archive_read_disk_entry_from_file.c
b/libarchive/archive_read_disk_entry_from_file.c
+@@ -163,15 +163,26 @@ archive_read_disk_entry_from_file(struct archive *_a,
+
+ #ifdef HAVE_READLINK
+ if (S_ISLNK(st->st_mode)) {
+- char linkbuffer[PATH_MAX + 1];
+- int lnklen = readlink(path, linkbuffer, PATH_MAX);
++ size_t linkbuffer_len = st->st_size + 1;
++ char *linkbuffer;
++ int lnklen;
++
++ linkbuffer = malloc(linkbuffer_len);
++ if (linkbuffer == NULL) {
++ archive_set_error(&a->archive, ENOMEM,
++ "Couldn't read link data");
++ return (ARCHIVE_FAILED);
++ }
++ lnklen = readlink(path, linkbuffer, linkbuffer_len);
+ if (lnklen < 0) {
+ archive_set_error(&a->archive, errno,
+ "Couldn't read link data");
++ free(linkbuffer);
+ return (ARCHIVE_FAILED);
+ }
+ linkbuffer[lnklen] = 0;
+ archive_entry_set_symlink(entry, linkbuffer);
++ free(linkbuffer);
+ }
+ #endif
+
+--
+1.7.1
+
diff --git
a/meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
b/meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
new file mode 100644
index 000..6ece7f3
--- /dev/null
+++
b/meta/recipes-extended/libarchive/libarchive/0002-Patch-from-upstream-revision-1991.patch
@@ -0,0 +1,31 @@
+libarchive: Backport patch from upstream (revision 1991)
+
+Upstream-Status: Backport
+
+Signed-off-by: Otavio Salvador
+
+diff --git a/libarchive/archive_write_disk.c b/libarchive/archive_write_disk.c
+index caf958e..60699e0 100644
+--- a/libarchive/archive_write_disk.c
b/libarchive/archive_write_disk.c
+@@ -434,7 +434,7 @@ _archive_write_header(struct archive *_a, struct
archive_entry *entry)
+ if (ret != ARCHIVE_OK)
+ goto done;
+ }
+-#ifdef HAVE_FCHDIR
++#if defined(HAVE_FCHDIR) && defined(PATH_MAX)
+ /* If path exceeds PATH_MAX, shorten the path. */
+ edit_deep_directories(a);
+ #endif
+@@ -866,7 +866,7 @@ archive_write_disk_new(void)
+ * object creation is likely to fail, but any error will get handled
+ * at that time.
+ */
+-#ifdef HAVE_FCHDIR
++#if defined(HAVE_FCHDIR) && defined(PATH_MAX)
+ static void
+ edit_deep_directories(struct archive_write_disk *a)
+ {
+--
+1.7.1
+
diff --git
a/meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev-2516.patch
b/meta/recipes-extended/libarchive/libarchive/0003-Patch-from-upstream-rev
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
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.
> sysvinit depends on
>
> * libc-inet
> * libc-sunrpc
> * libc-crypt
>
> I don't how to resolve them, so as you said, remove it and use busybox init
> ins
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
Re: [OE-core] [PATCH 1/1] base-passwd: disable problematic login.defs options
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 Garman --- .../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. Thus, a default login.defs needs to be shipped with base-passwd now. As a side note, my first iteration on this design used a base-passwd-cross recipe instead. Richard suggested that maintaining a separate -cross recipe was not necessary, and to integrate the target sysroot changes into the base-passwd recipe (given that otherwise there were no meaningful differences). If anyone feels strongly about this, now would be the time to make your case. 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] [PATCH 1/1] base-passwd: disable problematic login.defs options
On Fri, Jun 17, 2011 at 9:34 AM, Scott Garman 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 Garman >>> --- >>> .../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 ? -Khem ___ 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 Garman 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 Garman --- .../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] [PATCH 1/1] base-passwd: disable problematic login.defs options
On Fri, Jun 17, 2011 at 17:19, Scott Garman 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? -- 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] 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 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 Garman 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 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 >> 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 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_COUNTER
[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
---
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
---
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
Re: [OE-core] [RFC PATCH 0/2] Sanity testing network connectivity
On Fri, 2011-06-17 at 20:04 -0700, Joshua Lock wrote: > 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. I cunningly forgot the url's I referenced. Friday evening, sorry. 1. http://bugzilla.pokylinux.org/show_bug.cgi?id=933 2. https://wiki.yoctoproject.org/wiki/Connectivity_Troubleshooting Joshua -- Joshua Lock Yocto Build System Monkey Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
