Re: [OE-core] [Pull v2 2/4] xserver-nodm-init: Add xuser (hardcoded)
Hi Saul,
On 11/01/2011 11:44 PM, Saul Wold wrote:
Signed-off-by: Saul Wolds...@linux.intel.com
---
.../x11-common/xserver-nodm-init.bb| 30 +++
1 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
index ea4222d..5b06bc6 100644
--- a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
+++ b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Simple Xserver Init Script (no dm)
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
SECTION = x11
-PR = r26
+PR = r28
RDEPENDS_${PN} = sudo
SRC_URI = file://xserver-nodm \
@@ -19,27 +19,19 @@ do_install() {
install xserver-nodm ${D}/etc/init.d
if [ ${ROOTLESS_X} = 1 ] ; then
install -d ${D}/etc/X11
-install Xusername ${D}/etc/X11
+ install Xusername ${D}/etc/X11
Is this indentation change a typo?
Lauri
fi
}
-pkg_postinst_${PN} () {
-if [ x$D != x ] ; then
-exit 1
-fi
-
-if [ -f /etc/X11/Xusername ]; then
-# create the rootless X user, and add user to group tty, video, audio
-username=`cat /etc/X11/Xusername`
-adduser --disabled-password $username
-# FIXME: use addgroup if busybox addgroup is ready
-sed -i -e s/^video:.*/${username}/g /etc/group
-sed -i -e s/^tty:.*/${username}/g /etc/group
-sed -i -e s/^audio:.*/${username}/g /etc/group
-fi
-}
-
-inherit update-rc.d
+inherit update-rc.d useradd
INITSCRIPT_NAME = xserver-nodm
INITSCRIPT_PARAMS = start 9 5 2 . stop 20 0 1 6 .
+
+# Use fixed Xusername of xuser for now, this will need to be
+# fixed if the Xusername changes from xuser
+USERADD_PACKAGES = ${PN}
+USERADD_PARAM_${PN} = --system --no-create-home \
+ --shell /bin/false --groups video,tty,audio \
+ --user-group xuser
+
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] [Yocto Bug 1700] Fix for buildstats diskio on non physical disks
From: Elizabeth Flanagan elizabeth.flana...@intel.com tmpfs/encryptfs/ramfs have no entry in /proc/diskstats. This modifies buildstats to not collect diskio statistics when we encounter a case where the os.major/os.minor is not represented with an entry in /proc/diskstats. Longer term solution to this is to: - Identify all fs types that don't have representation in /proc/diskstats - Gather meaningful iostats of these fs types if possible. The following changes since commit 4a951e0433a99cd985515843f0a48fadc7050aca: Fix HOMEPAGE values in libzypp and sat-solver .bb files (2011-11-01 18:28:19 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib eflanagan/diskio_bug1700 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=eflanagan/diskio_bug1700 Elizabeth Flanagan (1): [Yocto Bug 1700] Fix for buildstats on tmpfs meta/classes/buildstats.bbclass | 37 ++--- 1 files changed, 26 insertions(+), 11 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] [Yocto Bug 1700] Fix for buildstats on tmpfs
From: Elizabeth Flanagan elizabeth.flana...@intel.com
tmpfs/encryptfs/(and most likely, but not confirmed)ramfs TMPDIRs
cause diskstats to choke. No device entry ends up in /proc/diskstats
for these fs types, which ends up causing the failure.
The short term solution is to exclude these fs types from diskstat
collection. Longer term we will want to see if we can collect
meaningful diskio for each of these, and other, use cases, but for
this cleans up Bug 1700.
Signed-off-by: Elizabeth Flanagan elizabeth.flana...@intel.com
---
meta/classes/buildstats.bbclass | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/meta/classes/buildstats.bbclass b/meta/classes/buildstats.bbclass
index 55cbb3c..96c98d4 100644
--- a/meta/classes/buildstats.bbclass
+++ b/meta/classes/buildstats.bbclass
@@ -48,13 +48,24 @@ def set_device(e):
# something like stick DL_DIR on a different partition and this would
# throw stats gathering off. The same goes with SSTATE_DIR. However, let's
# get the basics in here and work on the cornercases later.
+# A note. /proc/diskstats does not contain info on encryptfs, tmpfs, etc.
+# If we end up hitting one of these fs, we'll just skip diskstats
collection.
device=os.stat(tmpdir)
majordev=os.major(device.st_dev)
minordev=os.minor(device.st_dev)
+
+# Bug 1700:
+# Because tmpfs/encryptfs/ramfs etc inserts no entry in /proc/diskstats
+# we set rdev to NoLogicalDevice and search for it later. If we find NLD
+# we do not collect diskstats as the method to collect meaningful
statistics
+# for these fs types requires a bit more research.
+
for line in open(/proc/diskstats, r):
if majordev == int(line.split()[0]) and minordev ==
int(line.split()[1]):
rdev=line.split()[2]
+else:
+ rdev=NoLogicalDevice
file = open(bb.data.getVar('DEVFILE', e.data, True), w)
file.write(rdev)
file.close()
@@ -133,10 +144,11 @@ def write_task_data(status, logfile, dev, e):
# For the best information, running things with BB_TOTAL_THREADS = 1
# would return accurate per task results.
-diskdata = get_diskdata(__diskdata_task, dev, e.data)
-if diskdata:
-for key in sorted(diskdata.iterkeys()):
-file.write(key + : + diskdata[key] + \n)
+if dev != NoLogicalDevice:
+diskdata = get_diskdata(__diskdata_task, dev, e.data)
+if diskdata:
+for key in sorted(diskdata.iterkeys()):
+file.write(key + : + diskdata[key] + \n)
if status is passed:
file.write(Status: PASSED \n)
else:
@@ -169,7 +181,8 @@ python run_buildstats () {
bb.mkdirhier(bsdir)
except:
pass
-set_diskdata(__diskdata_build, device, e.data)
+if device != NoLogicalDevice:
+set_diskdata(__diskdata_build, device, e.data)
set_timedata(__timedata_build, e.data)
build_time = os.path.join(bsdir, build_stats)
# write start of build into build_time
@@ -185,7 +198,7 @@ python run_buildstats () {
elif isinstance(e, bb.event.BuildCompleted):
bn = get_bn(e)
-dev = get_device(e)
+device = get_device(e)
bsdir = os.path.join(bb.data.getVar('BUILDSTATS_BASE', e.data, True),
bn)
taskdir = os.path.join(bsdir, bb.data.expand(${PF}, e.data))
build_time = os.path.join(bsdir, build_stats)
@@ -201,10 +214,11 @@ python run_buildstats () {
file.write(Elapsed time: %0.2f seconds \n % (time))
if cpu:
file.write(CPU usage: %0.1f%% \n % cpu)
-diskio = get_diskdata(__diskdata_build, dev, e.data)
-if diskio:
-for key in sorted(diskio.iterkeys()):
-file.write(key + : + diskio[key] + \n)
+if device != NoLogicalDevice:
+diskio = get_diskdata(__diskdata_build, device, e.data)
+if diskio:
+for key in sorted(diskio.iterkeys()):
+file.write(key + : + diskio[key] + \n)
file.close()
if isinstance(e, bb.build.TaskStarted):
@@ -212,7 +226,8 @@ python run_buildstats () {
device = get_device(e)
bsdir = os.path.join(bb.data.getVar('BUILDSTATS_BASE', e.data, True),
bn)
taskdir = os.path.join(bsdir, bb.data.expand(${PF}, e.data))
-set_diskdata(__diskdata_task, device, e.data)
+if device != NoLogicalDevice:
+set_diskdata(__diskdata_task, device, e.data)
set_timedata(__timedata_task, e.data)
try:
Re: [OE-core] [PATCH 1/1] bash: make job control really work
Richard Purdie wrote on 2011-11-01:
On Tue, 2011-11-01 at 16:05 +0800, Dexuan Cui wrote:
It turns out 9393ff833f44570fd5f500bc9de6c72db94b0296 didn't really
fix the bug.
This patch is made and tested after I read the link below
http://www.mail-archive.com/bug-bash@gnu.org/msg03107.html
[YOCTO #487]
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/recipes-extended/bash/bash.inc|1 +
meta/recipes-extended/bash/bash_4.2.bb |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/bash/bash.inc
b/meta/recipes-extended/bash/bash.inc
index d55e517..d495538 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -23,6 +23,7 @@ ALTERNATIVE_LINK = ${base_bindir}/sh
ALTERNATIVE_PRIORITY = 100
do_configure () { + export bash_cv_job_control_missing=present
gnu-configize oe_runconf }
This really should go into the common site files...
Hi Richard,
I found we do define the variable:
meta/site/common-linux:33:bash_cv_job_control_missing=${bash_cv_job_control_missing=present}
but looks autoconf doesn't realize the variable has been assigned the value
'present'?
I think this is because of the below do_configure in bash.inc -- looks
autoreconf is skipped?
do_configure () {
gnu-configize
oe_runconf
}
Why do we need a customized do_configure to replace autotools_do_configure?
Later, after I added
do_configure_prepend () {
autoreconf -f -i -s
}
The generated config.log does show bash_cv_job_control_missing is assigned with
'present'.
(BTW, common-linux also introduces many other variables -- would this be safe?
Actually here I only need to introduce bash_cv_job_control_missing.)
However, finally, do_compile got a strange failure:
| shell.c: In function 'shell_reinitialize':
| shell.c:1742:20: error: 'PPROMPT' undeclared (first use in this function)
| shell.c:1742:20: note: each undeclared identifier is reported only once for
each function it appears in
| shell.c:1743:22: error: 'SPROMPT' undeclared (first use in this function)
Could you please give some suggestions?
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libxslt: use Copyright in LIC_FILES_CHKSUM instead of COPYING
* COPYING is replaced by symlink to Copyright during do_configure
(see configure.in), then we end with link to nonexistent file like this:
OE om-gta02@shr ~/shr-core $ ll tmp/deploy/licenses/libxslt/
total 40
drwxr-xr-x 2 bitbake bitbake 4096 Nov 2 00:27 ./
drwxr-xr-x 818 bitbake bitbake 32768 Nov 2 00:27 ../
lrwxrwxrwx 1 bitbake bitbake 9 Nov 2 00:27 COPYING - Copyright
lrwxrwxrwx 1 bitbake bitbake52 Nov 2 00:27 generic_MIT -
/OE/shr-core/tmp/deploy/licenses/common-licenses/MIT
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-support/libxslt/libxslt_1.1.26.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/libxslt/libxslt_1.1.26.bb
b/meta/recipes-support/libxslt/libxslt_1.1.26.bb
index 96bffc6..addc863 100644
--- a/meta/recipes-support/libxslt/libxslt_1.1.26.bb
+++ b/meta/recipes-support/libxslt/libxslt_1.1.26.bb
@@ -3,11 +3,11 @@ HOMEPAGE = http://xmlsoft.org/XSLT/;
BUGTRACKER = https://bugzilla.gnome.org/;
LICENSE = MIT
-LIC_FILES_CHKSUM = file://COPYING;md5=0cd9a07afbeb24026c9b03aecfeba458
+LIC_FILES_CHKSUM = file://Copyright;md5=0cd9a07afbeb24026c9b03aecfeba458
SECTION = libs
DEPENDS = libxml2
-PR = r3
+PR = r4
SRC_URI = ftp://xmlsoft.org/libxslt//libxslt-${PV}.tar.gz \
file://pkgconfig_fix.patch
--
1.7.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] udev-164: Update init script to do an explicit add action
With udev 152 or greater the default action for 'udevadm trigger' was modified to be 'change' instead of 'add. To ensure initial coldplug events at boot are seen be scripts the are expecting them as 'add' events we invoke udevadm with an explicit '--action=add'. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- meta/recipes-core/udev/udev-164/init |4 ++-- meta/recipes-core/udev/udev_164.bb |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/udev/udev-164/init b/meta/recipes-core/udev/udev-164/init index 9ce95ee..073942f 100644 --- a/meta/recipes-core/udev/udev-164/init +++ b/meta/recipes-core/udev/udev-164/init @@ -48,10 +48,10 @@ kill_udevd /dev/null 21 /sbin/udevadm control --env=STARTUP=1 if [ $not_first_boot != ];then - /sbin/udevadm trigger --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform + /sbin/udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform (/sbin/udevadm settle --timeout=3; /sbin/udevadm control --env=STARTUP=) else - /sbin/udevadm trigger + /sbin/udevadm trigger --action=add /sbin/udevadm settle fi diff --git a/meta/recipes-core/udev/udev_164.bb b/meta/recipes-core/udev/udev_164.bb index 7cbe4d8..d487add 100644 --- a/meta/recipes-core/udev/udev_164.bb +++ b/meta/recipes-core/udev/udev_164.bb @@ -1,6 +1,6 @@ include udev-new.inc -PR = r6 +PR = r7 SRC_URI += file://udev-166-v4l1-1.patch -- 1.7.3.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lame: add SRC_URI checksums
---
meta/recipes-multimedia/lame/lame_3.98.4.bb |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-multimedia/lame/lame_3.98.4.bb
b/meta/recipes-multimedia/lame/lame_3.98.4.bb
index 6e098c6..680ea48 100644
--- a/meta/recipes-multimedia/lame/lame_3.98.4.bb
+++ b/meta/recipes-multimedia/lame/lame_3.98.4.bb
@@ -10,6 +10,9 @@ PR = r0
SRC_URI = ${SOURCEFORGE_MIRROR}/lame/lame-${PV}.tar.gz \
file://no-gtk1.patch
+SRC_URI[md5sum] = 8e9866ad6b570c6c95c8cba48060473f
+SRC_URI[sha256sum] =
ac3144c76617223a9be4aaa3e28a66b51bcab28141050c3af04cb06836f772c8
+
inherit autotools
PACKAGES += libmp3lame libmp3lame-dev
--
1.7.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lame: add SRC_URI checksums
On Wed, 2011-11-02 at 09:11 +0100, Martin Jansa wrote: --- meta/recipes-multimedia/lame/lame_3.98.4.bb |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libxslt: use Copyright in LIC_FILES_CHKSUM instead of COPYING
On Wed, 2011-11-02 at 08:42 +0100, Martin Jansa wrote: * COPYING is replaced by symlink to Copyright during do_configure (see configure.in), then we end with link to nonexistent file like this: OE om-gta02@shr ~/shr-core $ ll tmp/deploy/licenses/libxslt/ total 40 drwxr-xr-x 2 bitbake bitbake 4096 Nov 2 00:27 ./ drwxr-xr-x 818 bitbake bitbake 32768 Nov 2 00:27 ../ lrwxrwxrwx 1 bitbake bitbake 9 Nov 2 00:27 COPYING - Copyright lrwxrwxrwx 1 bitbake bitbake52 Nov 2 00:27 generic_MIT - /OE/shr-core/tmp/deploy/licenses/common-licenses/MIT Signed-off-by: Martin Jansa martin.ja...@gmail.com Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Pull v2 2/4] xserver-nodm-init: Add xuser (hardcoded)
On Wed, 2011-11-02 at 08:11 +0200, Lauri Hintsala wrote:
Hi Saul,
On 11/01/2011 11:44 PM, Saul Wold wrote:
Signed-off-by: Saul Wolds...@linux.intel.com
---
.../x11-common/xserver-nodm-init.bb| 30
+++
1 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
index ea4222d..5b06bc6 100644
--- a/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
+++ b/meta/recipes-graphics/x11-common/xserver-nodm-init.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Simple Xserver Init Script (no dm)
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
SECTION = x11
-PR = r26
+PR = r28
RDEPENDS_${PN} = sudo
SRC_URI = file://xserver-nodm \
@@ -19,27 +19,19 @@ do_install() {
install xserver-nodm ${D}/etc/init.d
if [ ${ROOTLESS_X} = 1 ] ; then
install -d ${D}/etc/X11
-install Xusername ${D}/etc/X11
+ install Xusername ${D}/etc/X11
Is this indentation change a typo?
Saul fixed this in the v3 which I've taken.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta: glib-2.0: don't apply qsort_r test removable patch for native version
On Tue, Nov 01, 2011 at 11:08:10PM +0100, Simon Busch wrote:
On some buildhosts with an older version of native glib-2.0 installed (in
this case
2.16.6) the qsort_r test removable patch leads to a compilation error:
| ./.libs/libglib-2.0.so: undefined reference to `qsort_r'
| collect2: ld returned 1 exit status
This patch fixes this so the patch gets only applied for the native version
of this
recipe.
Signed-off-by: Simon Busch morp...@gravedo.de
Acked-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-core/glib-2.0/glib-2.0_2.30.0.bb |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.30.0.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.30.0.bb
index 566355d..0efce40 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.30.0.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.30.0.bb
@@ -1,6 +1,6 @@
require glib.inc
-PR = r2
+PR = r3
PE = 1
DEPENDS += libffi python-argparse-native
@@ -9,11 +9,14 @@ DEPENDS_virtclass-nativesdk += libffi-nativesdk
python-argparse-native zlib-nat
SHRT_VER =
${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,1).split('.')[1]}
+QSORT_PATCH = file://remove.test.for.qsort_r.patch
+QSORT_PATCH_virtclass-native =
+
SRC_URI = ${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.bz2 \
file://configure-libtool.patch \
file://60_wait-longer-for-threads-to-die.patch \
file://g_once_init_enter.patch \
- file://remove.test.for.qsort_r.patch \
+ ${QSORT_PATCH} \
SRC_URI[md5sum] = fee101d9d7daa8ddfbae00325f307f3b
SRC_URI[sha256sum] =
ca9c731017ab370859e847f8b70079bc6dcf389dc0ccb0d0419925aff81b9687
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] keymaps: use VIRTUAL-RUNTIME_kbd instead of console-tools directly
* nowadays kbd seems more active and it's available ie in meta-openembedded
* other option is to move kbd from meta-openembedded to
openembedded-core and changed DEPENDS
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-bsp/keymaps/keymaps_1.0.bb |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-bsp/keymaps/keymaps_1.0.bb
b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
index 4fe7987..754bec6 100644
--- a/meta/recipes-bsp/keymaps/keymaps_1.0.bb
+++ b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
@@ -5,11 +5,14 @@ SECTION = base
# Distro can override initscripts provider
VIRTUAL-RUNTIME_initscripts ?= initscripts
-RDEPENDS_${PN} = ${VIRTUAL-RUNTIME_initscripts} console-tools
+# Distro can override kbd provider
+VIRTUAL-RUNTIME_kbd ?= console-tools
+
+RDEPENDS_${PN} = ${VIRTUAL-RUNTIME_initscripts} ${VIRTUAL-RUNTIME_kbd}
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
PACKAGE_ARCH = ${MACHINE_ARCH}
-PR = r19
+PR = r20
INHIBIT_DEFAULT_DEPS = 1
--
1.7.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] task-core-boot, keymaps: add another VIRTUAL-RUNTIME to allow distributions to use different set of initscripts or no initscripts at all
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-bsp/keymaps/keymaps_1.0.bb |6 +-
meta/recipes-core/tasks/task-core-boot.bb |6 --
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-bsp/keymaps/keymaps_1.0.bb
b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
index 23a3051..4fe7987 100644
--- a/meta/recipes-bsp/keymaps/keymaps_1.0.bb
+++ b/meta/recipes-bsp/keymaps/keymaps_1.0.bb
@@ -1,7 +1,11 @@
SUMMARY = Keyboard maps
DESCRIPTION = Keymaps and initscript to set the keymap on bootup.
SECTION = base
-RDEPENDS_${PN} = initscripts console-tools
+
+# Distro can override initscripts provider
+VIRTUAL-RUNTIME_initscripts ?= initscripts
+
+RDEPENDS_${PN} = ${VIRTUAL-RUNTIME_initscripts} console-tools
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
PACKAGE_ARCH = ${MACHINE_ARCH}
diff --git a/meta/recipes-core/tasks/task-core-boot.bb
b/meta/recipes-core/tasks/task-core-boot.bb
index 9e63ebb..05c280d 100644
--- a/meta/recipes-core/tasks/task-core-boot.bb
+++ b/meta/recipes-core/tasks/task-core-boot.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3
PACKAGE_ARCH = ${MACHINE_ARCH}
DEPENDS = virtual/kernel
ALLOW_EMPTY = 1
-PR = r8
+PR = r9
#
# Set by the machine configuration with packages essential for device bootup
@@ -23,6 +23,8 @@ VIRTUAL-RUNTIME_dev_manager ?= udev
VIRTUAL-RUNTIME_login_manager ?= tinylogin
# Distro can override init_manager provider
VIRTUAL-RUNTIME_init_manager ?= sysvinit
+# Distro can override initscripts provider
+VIRTUAL-RUNTIME_initscripts ?= initscripts
PACKAGES = \
task-core-boot \
@@ -34,7 +36,7 @@ RDEPENDS_task-core-boot = \
base-files \
base-passwd \
busybox \
-initscripts \
+${VIRTUAL-RUNTIME_initscripts} \
${@base_contains(MACHINE_FEATURES, keyboard, keymaps, , d)} \
modutils-initscripts \
netbase \
--
1.7.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] task-core-x11: use VIRTUAL-RUNTIME variables for xserver_common and graphical_init_manager
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-sato/tasks/task-core-x11.bb | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-sato/tasks/task-core-x11.bb
b/meta/recipes-sato/tasks/task-core-x11.bb
index 26d550a..106bc0f 100644
--- a/meta/recipes-sato/tasks/task-core-x11.bb
+++ b/meta/recipes-sato/tasks/task-core-x11.bb
@@ -30,6 +30,12 @@ ALLOW_EMPTY = 1
FILEMANAGER ?= pcmanfm
FILEMANAGER_mips ?=
+# xserver-common, x11-common
+VIRTUAL-RUNTIME_xserver_common ?= x11-common
+
+# elsa, xserver-nodm-init
+VIRTUAL-RUNTIME_graphical_init_manager ?= xserver-nodm-init
+
RDEPENDS_task-core-x11-base = \
dbus \
@@ -42,8 +48,8 @@ RDEPENDS_task-core-x11-base = \
matchbox-desktop \
matchbox-session \
${XSERVER} \
-x11-common \
-xserver-nodm-init \
+${VIRTUAL-RUNTIME_xserver_common} \
+${VIRTUAL-RUNTIME_graphical_init_manager} \
liberation-fonts \
xauth \
xhost \
--
1.7.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta: glib-2.0: don't apply qsort_r test removable patch for native version
On Tue, 2011-11-01 at 23:08 +0100, Simon Busch wrote: On some buildhosts with an older version of native glib-2.0 installed (in this case 2.16.6) the qsort_r test removable patch leads to a compilation error: | ./.libs/libglib-2.0.so: undefined reference to `qsort_r' | collect2: ld returned 1 exit status This patch fixes this so the patch gets only applied for the native version of this recipe. Signed-off-by: Simon Busch morp...@gravedo.de --- meta/recipes-core/glib-2.0/glib-2.0_2.30.0.bb |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 01/16] libnl2: Fix a race on route/pktloc_syntax.h
On Tue, Oct 11, 2011 at 08:57:47PM +, McClintock Matthew-B29882 wrote: On Tue, Oct 11, 2011 at 3:47 PM, Saul Wold saul.w...@intel.com wrote: On 09/30/2011 10:21 AM, Matthew McClintock wrote: From: Tom Rinitom_r...@mentor.com At issue is that route/pktloc.c (not generated) depends on route/pktloc_syntax.h (generated). Signed-off-by: Tom Rinitom_r...@mentor.com Signed-off-by: Matthew McClintockm...@freescale.com --- .../libnl/fix-pktloc_syntax_h-race.patch | 26 I just noticed that this patch get put in the libnl directory, not the libnl-2.0 directory. Can you pull all the libnl changes together and resbumit this, also is there a reason you can not just update this to the latest libnl 3.2.1? Are you referring to this: http://patches.openembedded.org/patch/12749/ This pach is moving fix-makefile.patch from libnl-2.0 to libnl dir as Saul mentioned and patch wasn't even formated with -M to make it easier to review such move, please move it back to libnl-2.0 and send it again. .../libnl/libnl-2.0/fix-makefile.patch | 32 .../recipes-support/libnl/libnl/fix-makefile.patch | 32 Cheers, Cab you test that against the wpa-supplicant which seems to be libnl's sole dependee. I can't - don't have a board with wireless - dont't have a wireless network... -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] keymaps: use VIRTUAL-RUNTIME_kbd instead of console-tools directly
Op 2 nov. 2011, om 09:58 heeft Martin Jansa het volgende geschreven: * nowadays kbd seems more active and it's available ie in meta-openembedded * other option is to move kbd from meta-openembedded to openembedded-core and changed DEPENDS Since I really dislike VIRTUAL_RUNTIME_*, let's move kbd into OE-core. regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] bash: make job control really work
On Wed, 2011-11-02 at 15:10 +0800, Cui, Dexuan wrote:
Richard Purdie wrote on 2011-11-01:
On Tue, 2011-11-01 at 16:05 +0800, Dexuan Cui wrote:
It turns out 9393ff833f44570fd5f500bc9de6c72db94b0296 didn't really
fix the bug.
This patch is made and tested after I read the link below
http://www.mail-archive.com/bug-bash@gnu.org/msg03107.html
[YOCTO #487]
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/recipes-extended/bash/bash.inc|1 +
meta/recipes-extended/bash/bash_4.2.bb |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/bash/bash.inc
b/meta/recipes-extended/bash/bash.inc
index d55e517..d495538 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -23,6 +23,7 @@ ALTERNATIVE_LINK = ${base_bindir}/sh
ALTERNATIVE_PRIORITY = 100
do_configure () { + export bash_cv_job_control_missing=present
gnu-configize oe_runconf }
This really should go into the common site files...
Hi Richard,
I found we do define the variable:
meta/site/common-linux:33:bash_cv_job_control_missing=${bash_cv_job_control_missing=present}
but looks autoconf doesn't realize the variable has been assigned the value
'present'?
I think this is because of the below do_configure in bash.inc -- looks
autoreconf is skipped?
do_configure () {
gnu-configize
oe_runconf
}
Why do we need a customized do_configure to replace autotools_do_configure?
Later, after I added
do_configure_prepend () {
autoreconf -f -i -s
}
The generated config.log does show bash_cv_job_control_missing is assigned
with 'present'.
(BTW, common-linux also introduces many other variables -- would this be
safe? Actually here I only need to introduce bash_cv_job_control_missing.)
However, finally, do_compile got a strange failure:
| shell.c: In function 'shell_reinitialize':
| shell.c:1742:20: error: 'PPROMPT' undeclared (first use in this function)
| shell.c:1742:20: note: each undeclared identifier is reported only once for
each function it appears in
| shell.c:1743:22: error: 'SPROMPT' undeclared (first use in this function)
Could you please give some suggestions?
This is why its a really bad idea for recipes to have their own
configure rather than using our core one :/.
I had a go at this problem myself and it took a bit of figuring out. The
problem is that bash ships config.h.in but autoheader overwrites it.
This removes the start/end includes from config.h or config-bot.h and
config-top.h. We can do something like this:
export AUTOHEADER = true
do_configure_prepend () {
if [ ! -e acinclude.m4 ]; then
cat aclocal.m4 acinclude.m4
fi
}
instead of the current do_configure override. The _prepend ensures the
bash specific macros are preserved and the export AUTOHEADER stops
autoheader from running at all.
Could you test those changes against bash 4.x and bash 3.x (replacing
the current do_configure in bash.inc) and then if that works send a
patch please?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] dbus broken again
After last attempt to fix dbus there is new issue I have talked with Richard on IRC already, but will repeat it here just to warn other dbus users. Updated list of available packages in /var/lib/opkg/lists/jama-om_gta02. Upgrading dbus-1 on root from 1.4.12-r2 to 1.4.12-r7... Downloading http://jama.dyndns-home.com/org.openembedded.shr-core//armv4t/dbus-1_1.4.12-r7_armv4t.ipk. Running groupadd commands... Note: group netdev already exists, not re-creating it Running useradd commands... Note: username messagebus already exists, not re-creating it Upgrading libdbus-1-3 on root from 1.4.12-r2 to 1.4.12-r7... Downloading http://jama.dyndns-home.com/org.openembedded.shr-core//armv4t/libdbus-1-3_1.4.12-r7_armv4t.ipk. Upgrading libglib-2.0-0 on root from 1:2.30.0-r2 to 1:2.30.0-r3... Downloading http://jama.dyndns-home.com/org.openembedded.shr-core//armv4t/libglib-2.0-0_2.30.0-r3_armv4t.ipk. Configuring dbus-1. System startup links for /etc/init.d/dbus-1 already exist. Configuring libdbus-1-3. Configuring libglib-2.0-0. SHR root@gjama / $ ll /usr/libexec/dbus-daemon-launch-helper -rwsr-xr-- 1 root 998 142748 Nov 2 10:12 /usr/libexec/dbus-daemon-launch-helper SHR root@gjama / $ ll -d /var/lib/dbus drwxr-xr-x 2 999 998 4096 Nov 2 10:12 /var/lib/dbus SHR root@gjama / $ grep message /etc/group messagebus:x:101: SHR root@gjama / $ grep message /etc/passwd messagebus:x:42:101:Linux User,,,:/var/run/dbus:/bin/sh and that's because useradd.bbclass is using UID/GID from sysroots OE om-gta02@shr ~/shr-core $ grep message tmp/sysroots/om-gta02/etc/group messagebus:x:998: OE om-gta02@shr ~/shr-core $ grep message tmp/sysroots/om-gta02/etc/passwd messagebus:!:999:998::/var/lib/dbus: and nothing is updating /etc/passwd /etc/group IDs on target. The possible solution would be to force specified UID/GID in useradd.bbclass to make it consistent during rebuild from scratch or teach useradd postinst to update UID/GIDs and chown all runtime created files to new values instead of skiping useradd/groupadd commnads when user already exists, like it did now: Note: username messagebus already exists, not re-creating it Note: group netdev already exists, not re-creating it Also reported here: http://bugzilla.pokylinux.org/show_bug.cgi?id=1711 -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bash: Ensure we fully reautoconf the recipes so site data is used
This ensures bug 487 (missing job control functionality) really gets fixed.
[YOCTO #487]
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-extended/bash/bash.inc
b/meta/recipes-extended/bash/bash.inc
index d55e517..876be1e 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -22,9 +22,12 @@ ALTERNATIVE_PATH = ${base_bindir}/bash
ALTERNATIVE_LINK = ${base_bindir}/sh
ALTERNATIVE_PRIORITY = 100
-do_configure () {
- gnu-configize
- oe_runconf
+export AUTOHEADER = true
+
+do_configure_prepend () {
+ if [ ! -e acinclude.m4 ]; then
+ cat aclocal.m4 acinclude.m4
+ fi
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-extended/bash/bash_3.2.48.bb
b/meta/recipes-extended/bash/bash_3.2.48.bb
index 1520c4e..f2ba572 100644
--- a/meta/recipes-extended/bash/bash_3.2.48.bb
+++ b/meta/recipes-extended/bash/bash_3.2.48.bb
@@ -6,7 +6,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=fd5d9bcabd8ed5a54a01ce8d183d592a
DEPENDS = ncurses
-PR = r7
+PR = r8
SRC_URI = ${GNU_MIRROR}/bash/bash-${PV}.tar.gz \
${GNU_MIRROR}/bash/bash-3.2-patches/bash32-049;apply=yes;striplevel=0 \
@@ -23,9 +23,12 @@ sbindir = /sbin
EXTRA_OECONF = --with-ncurses
export CC_FOR_BUILD = ${BUILD_CC}
-do_configure () {
- gnu-configize
- oe_runconf
+export AUTOHEADER = true
+
+do_configure_prepend () {
+ if [ ! -e acinclude.m4 ]; then
+ cat aclocal.m4 acinclude.m4
+ fi
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-extended/bash/bash_4.2.bb
b/meta/recipes-extended/bash/bash_4.2.bb
index a0f5e4e..8070918 100644
--- a/meta/recipes-extended/bash/bash_4.2.bb
+++ b/meta/recipes-extended/bash/bash_4.2.bb
@@ -1,6 +1,6 @@
require bash.inc
-PR = r0
+PR = r1
SRC_URI = ${GNU_MIRROR}/bash/${BPN}-${PV}.tar.gz;name=tarball \
${GNU_MIRROR}/bash/bash-4.2-patches/bash42-001;apply=yes;striplevel=0;name=patch001
\
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libcense.bbclass: fix OpenSSL mapping [BUGID# 1712]
Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/classes/license.bbclass |2 +- .../recipes-connectivity/openssl/openssl_0.9.8r.bb |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass index 3f93bf5..baf35f0 100644 --- a/meta/classes/license.bbclass +++ b/meta/classes/license.bbclass @@ -44,7 +44,7 @@ SPDXLICENSEMAP[MPLv1.1] = MPL-1 SPDXLICENSEMAP[MIT-X] = MIT #Openssl variations -SPDXLICENSEMAP[openssl] = Openssl +SPDXLICENSEMAP[openssl] = OpenSSL #Other variations SPDXLICENSEMAP[AFL2.1] = AFL-2 diff --git a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb b/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb index 5add70e..555bacf 100644 --- a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb +++ b/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb @@ -1,6 +1,6 @@ require openssl.inc -PR = r6 +PR = r7 SRC_URI += file://debian/ca.patch \ file://debian/config-hurd.patch;apply=no \ file://debian/debian-targets.patch \ -- 1.7.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image_types bbclass: use 4k bytes per inode so we don't run out of space immediately
genext2fs only creates the minimum number of inodes, after this patch it will
scale with the rootfs size
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/classes/image_types.bbclass | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 0d64705..9549a9e 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -38,36 +38,36 @@ IMAGE_CMD_jffs2 = mkfs.jffs2 --root=${IMAGE_ROOTFS}
--faketime --output=${DEPLO
IMAGE_CMD_cramfs = mkcramfs ${IMAGE_ROOTFS}
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cramfs ${EXTRA_IMAGECMD}
-IMAGE_CMD_ext2 = genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS}
${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2
+IMAGE_CMD_ext2 = genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS}
${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2
IMAGE_CMD_ext2.gz () {
rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN} mkdir
${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}
- genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2
+ genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2
gzip -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2
mv ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext2.gz
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2.gz
rmdir ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}
}
IMAGE_CMD_ext2.bz2 () {
rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz mkdir ${DEPLOY_DIR_IMAGE}/tmp.gz
- genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
+ genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
bzip2 -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
mv ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2.bz2
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2.bz2
rmdir ${DEPLOY_DIR_IMAGE}/tmp.gz
}
IMAGE_CMD_ext2.lzma () {
rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz mkdir ${DEPLOY_DIR_IMAGE}/tmp.gz
- genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
+ genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
lzma -f -7 ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
mv ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2.lzma
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2.lzma
rmdir ${DEPLOY_DIR_IMAGE}/tmp.gz
}
IMAGE_CMD_ext3 () {
- genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
+ genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
tune2fs -j ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
}
IMAGE_CMD_ext3.gz () {
rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN} mkdir
${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}
- genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
+ genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
tune2fs -j ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
gzip -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3
mv ${DEPLOY_DIR_IMAGE}/tmp.gz-${PN}/${IMAGE_NAME}.rootfs.ext3.gz
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3.gz
@@ -75,7 +75,7 @@ IMAGE_CMD_ext3.gz () {
}
oe_mkext4fs () {
- genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} $1
+ genext2fs -b $ROOTFS_SIZE -i 4096 -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD}
$1
tune2fs -O extents,uninit_bg,dir_index,has_journal $1
e2fsck -yfDC0 $1 || chk=$?
case $chk in
--
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] [PATCH] image_types bbclass: use 4k bytes per inode so we don't run out of space immediately
Op 2 nov. 2011, om 15:16 heeft Koen Kooi het volgende geschreven: genext2fs only creates the minimum number of inodes, after this patch it will scale with the rootfs size Signed-off-by: Koen Kooi k...@dominion.thruhere.net The matching OE classic commit is: koen@dominion:/OE/org.openembedded.dev$ git show 12275a16 commit 12275a1604e2a5e9e66c7ef900c450b01e5cf622 Author: Tom Rini tom_r...@mentor.com Date: Fri Dec 17 10:45:32 2010 -0700 bitbake.conf: Use normal bytes per inode param to genext2fs Without this we get an unusably small number of inodes in our filesystem images. Signed-off-by: Tom Rini tom_r...@mentor.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] image_types bbclass: use 4k bytes per inode so we don't run out of space immediately
On Wed, Nov 2, 2011 at 7:16 AM, Koen Kooi k...@dominion.thruhere.net wrote: genext2fs only creates the minimum number of inodes, after this patch it will scale with the rootfs size Signed-off-by: Koen Kooi k...@dominion.thruhere.net Acked-by: Tom Rini tom.r...@gmail.com -- Tom ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add new IMAGE_CLASSES variable for classes for image generation
On Tue, Nov 1, 2011 at 7:56 PM, Saul Wold saul.w...@intel.com wrote: Right I understood that part from before I think. But why can't you have IMAGE_CLASSES ?= image_types and then in the local.conf override that with IMAGE_CLASSES = image_types_uboot since image_types_uboot inherits image_types. IMAGE_CLASSES += image_types_uboot and leave the other bit as is... I have to admit I like this a little better with the possible thought of breaking up image_types a little more, keep more used ones in image_types, but move lesser used ones to their on .bbclass Them IMAGE_CLASSES truly is a list of image_type classes. I think this is best, let the user override IMAGE_CLASSES to (eventually) be able to add individual image_types_XYZ. Will send new patch. -M ___ 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] bash: make job control really work
Richard Purdie wrote on 2011-11-02:
On Wed, 2011-11-02 at 15:10 +0800, Cui, Dexuan wrote:
Richard Purdie wrote on 2011-11-01:
On Tue, 2011-11-01 at 16:05 +0800, Dexuan Cui wrote:
I had a go at this problem myself and it took a bit of figuring out.
The problem is that bash ships config.h.in but autoheader overwrites it.
This removes the start/end includes from config.h or config-bot.h and
config-top.h. We can do something like this:
export AUTOHEADER = true
do_configure_prepend () {
if [ ! -e acinclude.m4 ]; then
cat aclocal.m4 acinclude.m4
fi
}
instead of the current do_configure override. The _prepend ensures the
bash specific macros are preserved and the export AUTOHEADER stops
autoheader from running at all.
Could you test those changes against bash 4.x and bash 3.x (replacing
the current do_configure in bash.inc) and then if that works send a patch
please?
Looks bug 487 only happens to bash 4.x and bash 3.x doesn't have such a bug (the
recipe of bash 3.x doesn't use bash.inc, either)
RP, thanks a lot for the help! Here is the new patch:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bug487id=b524337ed5670de2c0d294c3f6970e24f23847eb
Thanks,
-- Dexuan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] Add new IMAGE_CLASSES variable for classes for image generation
Allows us to import classes only for images and not to the global
namespace
Signed-off-by: Matthew McClintock m...@freescale.com
---
Change IMAGE_CLASSES definition to use ?= instead of =
so it's clear we want to override this variable. This worked
before because the value in my distro.conf file overwrote
this value regardless of the fact it was set with =
meta-yocto/conf/local.conf.sample |6 ++
meta/classes/image.bbclass|3 ++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/meta-yocto/conf/local.conf.sample
b/meta-yocto/conf/local.conf.sample
index da3f8df..8177713 100644
--- a/meta-yocto/conf/local.conf.sample
+++ b/meta-yocto/conf/local.conf.sample
@@ -163,6 +163,12 @@ EXTRA_IMAGE_FEATURES = debug-tweaks
# NOTE: mklibs also needs to be explicitly enabled for a given image, see
local.conf.extended
USER_CLASSES ?= image-mklibs image-prelink
+# Additional image generation features
+#
+# The following is a list of classes to import to use in the generation of
images
+# currently an example class is image_types_uboot
+# IMAGE_CLASSES = image_types_uboot
+
#
# Runtime testing of images
#
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 05f4331..a2770a4 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -111,7 +111,8 @@ def get_devtable_list(d):
str += %s % bb.which(bb.data.getVar('BBPATH', d, 1), devtable)
return str
-inherit image_types
+IMAGE_CLASSES ?= image_types
+inherit ${IMAGE_CLASSES}
IMAGE_POSTPROCESS_COMMAND ?=
MACHINE_POSTPROCESS_COMMAND ?=
--
1.7.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] distro_tracking_fields: updates for sudo, mtools, grep, and openssh
Signed-off-by: Scott Garman scott.a.gar...@intel.com --- .../conf/distro/include/distro_tracking_fields.inc | 32 ++-- 1 files changed, 16 insertions(+), 16 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index 998eabf..b2808a5 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -813,12 +813,12 @@ RECIPE_MAINTAINER_pn-pax-utils = Scott Garman scott.a.gar...@intel.com RECIPE_STATUS_pn-sudo = green RECIPE_DEPENDENCY_CHECK_pn-sudo = not done -RECIPE_LATEST_VERSION_pn-sudo = 1.8.1p2 +RECIPE_LATEST_VERSION_pn-sudo = 1.8.3 RECIPE_INTEL_SECTION_pn-sudo = base utils -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-sudo = 1 month -RECIPE_LATEST_RELEASE_DATE_pn-sudo = May 16, 2011 +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-sudo = 2 months +RECIPE_LATEST_RELEASE_DATE_pn-sudo = Oct 21, 2011 RECIPE_COMMENTS_pn-sudo = -RECIPE_LAST_UPDATE_pn-sudo = Jun 14, 2011 +RECIPE_LAST_UPDATE_pn-sudo = Oct 25, 2011 RECIPE_MAINTAINER_pn-sudo = Scott Garman scott.a.gar...@intel.com RECIPE_STATUS_pn-blktool = green @@ -1290,12 +1290,12 @@ DISTRO_PN_ALIAS_pn-msynctool = OpenSuse=msynctool Mandriva=msynctool RECIPE_STATUS_pn-mtools = green RECIPE_DEPENDENCY_CHECK_pn-mtools = not done -RECIPE_LATEST_VERSION_pn-mtools = 4.0.16 +RECIPE_LATEST_VERSION_pn-mtools = 4.0.17 RECIPE_INTEL_SECTION_pn-mtools = optional -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-mtools = 6 months -RECIPE_LATEST_RELEASE_DATE_pn-mtools = Apr 16, 2011 +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-mtools = 2 months +RECIPE_LATEST_RELEASE_DATE_pn-mtools = Jun 28, 2011 RECIPE_COMMENTS_pn-mtools = -RECIPE_LAST_UPDATE_pn-mtools = Jun 15, 2011 +RECIPE_LAST_UPDATE_pn-mtools = Oct 25, 2011 RECIPE_MAINTAINER_pn-mtools = Scott Garman scott.a.gar...@intel.com RECIPE_STATUS_pn-pm-utils = green @@ -2016,22 +2016,22 @@ RECIPE_MAINTAINER_pn-cronie = Dexuan Cui dexuan@intel.com RECIPE_STATUS_pn-grep = green RECIPE_DEPENDENCY_CHECK_pn-grep = not done -RECIPE_LATEST_VERSION_pn-grep = 2.8 +RECIPE_LATEST_VERSION_pn-grep = 2.9 RECIPE_INTEL_SECTION_pn-grep = base RECIPE_NO_OF_PATCHES_pn-grep = 0 -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-grep = 8 months -RECIPE_LATEST_RELEASE_DATE_pn-grep = May 01, 2011 -RECIPE_LAST_UPDATE_pn-grep = Jun 5, 2011 +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-grep = 1 month +RECIPE_LATEST_RELEASE_DATE_pn-grep = Jun 01, 2011 +RECIPE_LAST_UPDATE_pn-grep = Oct 25, 2011 RECIPE_MAINTAINER_pn-grep = Scott Garman scott.a.gar...@intel.com RECIPE_STATUS_pn-openssh = green RECIPE_DEPENDENCY_CHECK_pn-openssh = not done -RECIPE_LATEST_VERSION_pn-openssh = 5.8p2 +RECIPE_LATEST_VERSION_pn-openssh = 5.9p1 RECIPE_INTEL_SECTION_pn-openssh = base RECIPE_NO_OF_PATCHES_pn-openssh = 1 -RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-openssh = 3 months -RECIPE_LATEST_RELEASE_DATE_pn-openssh = May 01, 2011 -RECIPE_LAST_UPDATE_pn-openssh = Jun 5, 2011 +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-openssh = 4 months +RECIPE_LATEST_RELEASE_DATE_pn-openssh = Sep 01, 2011 +RECIPE_LAST_UPDATE_pn-openssh = Oct 25, 2011 RECIPE_MAINTAINER_pn-openssh = Scott Garman scott.a.gar...@intel.com RECIPE_STATUS_pn-tar = green -- 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] how to set time zone
On Mon, Oct 31, 2011 at 1:44 AM, Ni Qingliang niqingli...@insigma.com.cnwrote:
I'd like the 'system level configuration' solution.
the /etc/localtime/ link can be done when packaging rootfs (using the
system level configuration).
On Fri, 2011-10-28 at 22:43 +0800, Mark Hatle wrote:
Setting the default TZ for the image is something that should be done in
a post
install script for the tzdata package or something similar.
Since the /etc/localtime is usually a copy/hardlink or symlink to the
timezone
data we don't want to package it up. Instead we want to perform the
actions
that a program running on the target system itself would use to change
the timezone.
So I think the easiest approach is to add a system level configuration
variable
(set the default).
Then use this variable to populate the configuration file that specifies
the
system timezone... and then use the post install process to check the
contents
of a text file.
Alternatively do this via an initscript -- but for folks w/ read-only
filesystems I'm not sure that will work.
--Mark
cut
Maybe I misunderstand system level configuration but in the meta-oe
recipe we have
DEFAULT_TIMEZONE ?= Europe/London
Maybe UTC would be better?
Note how the variable is weak thus can be overridden in local.conf.
Secondly, why do it as post-install or at image do_rootfs stage when we
have set the variable and are therefore able to provide sane defaults in
do_install?
Other points before starting to write a patch:
-why is the recipe in oe-core doing chown -R root:root ${D} ?
-the logic around # libc is removing zoneinfo files from package
Is it only eglibc?
Regards
Andrea
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [Pull v2 3/4] connman: create xuser
On Tue, Nov 1, 2011 at 19:44, Saul Wold s...@linux.intel.com wrote: We create xuser here as a backup incase that xerver-nodm-init is not on the system. This is wrong. If xserver-nodm-init (btw, there's a typo on the commit message) is not in the image user is suppose to know what he/she is doing so we shouldn't add users not required to make their life easier. -- 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] how to set time zone
On 11/2/11 12:32 PM, Andrea Adami wrote:
On Mon, Oct 31, 2011 at 1:44 AM, Ni Qingliang niqingli...@insigma.com.cn
mailto:niqingli...@insigma.com.cn wrote:
I'd like the 'system level configuration' solution.
the /etc/localtime/ link can be done when packaging rootfs (using the
system level configuration).
On Fri, 2011-10-28 at 22:43 +0800, Mark Hatle wrote:
Setting the default TZ for the image is something that should be done
in a
post
install script for the tzdata package or something similar.
Since the /etc/localtime is usually a copy/hardlink or symlink to the
timezone
data we don't want to package it up. Instead we want to perform the
actions
that a program running on the target system itself would use to change
the
timezone.
So I think the easiest approach is to add a system level configuration
variable
(set the default).
Then use this variable to populate the configuration file that
specifies the
system timezone... and then use the post install process to check the
contents
of a text file.
Alternatively do this via an initscript -- but for folks w/ read-only
filesystems I'm not sure that will work.
--Mark
cut
Maybe I misunderstand system level configuration but in the meta-oe recipe
we have
DEFAULT_TIMEZONE ?= Europe/London
Maybe UTC would be better?
To me no timezone (which is UTC) is preferable as the system designer can then
set the timezone, externally to the package(s).
Note how the variable is weak thus can be overridden in local.conf.
Secondly, why do it as post-install or at image do_rootfs stage when we have
set
the variable and are therefore able to provide sane defaults in do_install?
If it's done within a do_install, then the file (/etc/timezone) itself gets
placed into the package. If it's in the package, then if/when someone upgrades
the package from a feed the timezone gets reset to the previous value. That's a
bug IMHO.
If it's done as a post-install script, then the timezone configuration can be
evaluated and if one isn't set -- or there is no timezone file -- then we can
set it to UTC or a similar default timezone.. (the value in the DEFAULT_TIMEZONE
variable is reasonable in this approach.)
Other points before starting to write a patch:
-why is the recipe in oe-core doing chown -R root:root ${D} ?
There was an issue with the way the timezone data was extracted/constructed that
it was have all of the build system's uid/gid preserved in the copy to the final
install directory -- so when packaging incorrect usernames and groups were fed
into the process causing issues.
A simple chown -R root:root ${D} ensured that all of the timezone data was owned
by the root user (on the target).
-the logic around # libc is removing zoneinfo files from package
Is it only eglibc?
Timezone info is updated more often then the system libc. So the zoneinfo files
are handled externally of the libc. This allows for easier updates over time..
(This is my guess, as I'm not familiar with exactly what this comment refers
to.)
Regards
Andrea
|
|
___
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] Uprev to pseudo 1.2
Uprev to pseudo 1.2.
This was heavily tested by building oe-core with numerous image
configurations. Each configuration generated the same image before and
after the change from the current to new version of pseudo.
The primary purpose of this change is to enable the PSEUDO_UNLOAD
functionality that may be used for performance enhancements in future
versions of oe-core.
The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755:
meta: glib-2.0: don't apply qsort_r test removable patch for native version
(2011-11-02 09:08:21 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/pseudo
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo
Mark Hatle (1):
pseudo: Uprev pseudo to version 1.2
.../conf/distro/include/distro_tracking_fields.inc |6 +-
.../pseudo/pseudo/realpath_fix.patch | 165
.../pseudo/{pseudo_1.1.1.bb = pseudo_1.2.bb} |7 +-
meta/recipes-devtools/pseudo/pseudo_git.bb |6 +-
4 files changed, 9 insertions(+), 175 deletions(-)
delete mode 100644 meta/recipes-devtools/pseudo/pseudo/realpath_fix.patch
rename meta/recipes-devtools/pseudo/{pseudo_1.1.1.bb = pseudo_1.2.bb} (48%)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Uprev to pseudo 1.2
On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote:
Uprev to pseudo 1.2.
This was heavily tested by building oe-core with numerous image
configurations. Each configuration generated the same image before and
after the change from the current to new version of pseudo.
The primary purpose of this change is to enable the PSEUDO_UNLOAD
functionality that may be used for performance enhancements in future
versions of oe-core.
The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755:
meta: glib-2.0: don't apply qsort_r test removable patch for native version
(2011-11-02 09:08:21 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/pseudo
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo
Is there branch with pseudo-1.2 for oe-core?
I would like to try it because we have strange errors when libstc++
isn't found when building with pseudo, but same binaries are working
fine without pseudo (seems related to /etc/ld.so.cache being ignored
sometimes from pseudo env).
And while I was trying to debug it I've noticed that files.db and
pseudo.log is quite big.
-rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db
-rw-r--r-- 1 bitbake bitbake 91K Aug 15 13:50 logs.db
-rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log
with pseudo.log full of errors like this
pseudo: path mismatch [12 links]: ino 39721500 db
'/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor'
req
'/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'.
Cheers,
Mark Hatle (1):
pseudo: Uprev pseudo to version 1.2
.../conf/distro/include/distro_tracking_fields.inc |6 +-
.../pseudo/pseudo/realpath_fix.patch | 165
.../pseudo/{pseudo_1.1.1.bb = pseudo_1.2.bb} |7 +-
meta/recipes-devtools/pseudo/pseudo_git.bb |6 +-
4 files changed, 9 insertions(+), 175 deletions(-)
delete mode 100644 meta/recipes-devtools/pseudo/pseudo/realpath_fix.patch
rename meta/recipes-devtools/pseudo/{pseudo_1.1.1.bb = pseudo_1.2.bb} (48%)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Uprev to pseudo 1.2
On 11/2/11 4:22 PM, Martin Jansa wrote:
On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote:
Uprev to pseudo 1.2.
This was heavily tested by building oe-core with numerous image
configurations. Each configuration generated the same image before and
after the change from the current to new version of pseudo.
The primary purpose of this change is to enable the PSEUDO_UNLOAD
functionality that may be used for performance enhancements in future
versions of oe-core.
The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755:
meta: glib-2.0: don't apply qsort_r test removable patch for native
version (2011-11-02 09:08:21 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib mhatle/pseudo
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo
Is there branch with pseudo-1.2 for oe-core?
git://git.pokylinux.org/poky-contrib mhatle/pseudo
Grab that -- or simply grab the top commit and add it to your oe-core checkout.
I would like to try it because we have strange errors when libstc++
isn't found when building with pseudo, but same binaries are working
fine without pseudo (seems related to /etc/ld.so.cache being ignored
sometimes from pseudo env).
And while I was trying to debug it I've noticed that files.db and
pseudo.log is quite big.
-rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db
-rw-r--r-- 1 bitbake bitbake 91K Aug 15 13:50 logs.db
-rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log
The files.db is based on the number of files accessed during the time pseudo is
running.
logs.db and pseudo.log are based on the debug settings of pseudo. If you don't
have debugging enabled (you would have to do this manually) and the logs are
that big, something is going seriously wrong with the path/inode translation...
It's fairly normal to have a set of logs that are in the 10-20k range for
complex packages.. (These are documenting cases where pseudo has to guess about
inode to path mapping..)
with pseudo.log full of errors like this
pseudo: path mismatch [12 links]: ino 39721500 db
'/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor'
req
'/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'.
Are you building on a NFS filesystem? NFS (and a few other filesystems) have a
habit of remapping inodes out from under the filesystem. pseudo uses the inodes
as a validation that the file hasn't changed. If these inodes are changing,
pseudo will do it's best to keep things in sync, but there is a chance it won't
always succeed.
(This is done because someone could access a file in pseudo control that was
created outside.. so pseudo could only capture the inode.. then if in a future
action the file is accessed the inode/path can be checked. If the inode matches
it assumes it's the same file and now a path name exists.. if someone makes
changes outside of pseudo control a similar check happens.. this time it'll see
the path is the same but inode has changed.. so it guesses the file was modified
and I believe resets everything based on the new inode. Each of these will
generate a warning in the logs.)
--Mark
Cheers,
Mark Hatle (1):
pseudo: Uprev pseudo to version 1.2
.../conf/distro/include/distro_tracking_fields.inc |6 +-
.../pseudo/pseudo/realpath_fix.patch | 165
.../pseudo/{pseudo_1.1.1.bb = pseudo_1.2.bb} |7 +-
meta/recipes-devtools/pseudo/pseudo_git.bb |6 +-
4 files changed, 9 insertions(+), 175 deletions(-)
delete mode 100644 meta/recipes-devtools/pseudo/pseudo/realpath_fix.patch
rename meta/recipes-devtools/pseudo/{pseudo_1.1.1.bb = pseudo_1.2.bb} (48%)
--
1.7.3.4
___
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
Re: [OE-core] [PATCH 0/1] Uprev to pseudo 1.2
On Wed, Nov 02, 2011 at 04:39:42PM -0500, Mark Hatle wrote: On 11/2/11 4:22 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote: Uprev to pseudo 1.2. This was heavily tested by building oe-core with numerous image configurations. Each configuration generated the same image before and after the change from the current to new version of pseudo. The primary purpose of this change is to enable the PSEUDO_UNLOAD functionality that may be used for performance enhancements in future versions of oe-core. The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755: meta: glib-2.0: don't apply qsort_r test removable patch for native version (2011-11-02 09:08:21 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/pseudo http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo Is there branch with pseudo-1.2 for oe-core? git://git.pokylinux.org/poky-contrib mhatle/pseudo Grab that -- or simply grab the top commit and add it to your oe-core checkout. Yes, but git cherry-pick would be faster and adding poky-contrib as another git remote is not very efficient as it doesn't share any git objects with oe-core repo so it checkouts whole poky again :/. So I'll use 2nd easiest option pw-am.sh 14227. I would like to try it because we have strange errors when libstc++ isn't found when building with pseudo, but same binaries are working fine without pseudo (seems related to /etc/ld.so.cache being ignored sometimes from pseudo env). And while I was trying to debug it I've noticed that files.db and pseudo.log is quite big. -rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db -rw-r--r-- 1 bitbake bitbake 91K Aug 15 13:50 logs.db -rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log The files.db is based on the number of files accessed during the time pseudo is running. Ah ok, this was in sysroot which was created Aug 9 so it gets pretty big fast, lets hope that sqlite3 can handle it efficiently, or is there some way to cleanup stale entries in files table? ie I'm using eglibc-2.14, but files table is full of eglibc-2.13 entries and _none_ from eglibc-2.14, is it supposed to be like this or is it sign of some pseudo problems? sqlite select count(*) from files where path like '%eglibc-2.13%'; 20221 sqlite select count(*) from files where path like '%eglibc-2.14%'; 0 sqlite select count(*) from files; 1085380 logs.db and pseudo.log are based on the debug settings of pseudo. If you don't have debugging enabled (you would have to do this manually) and the logs are that big, something is going seriously wrong with the path/inode translation... It's fairly normal to have a set of logs that are in the 10-20k range for complex packages.. (These are documenting cases where pseudo has to guess about inode to path mapping..) This was generated without debug enabled.. but maybe because of rm_work, see below... with pseudo.log full of errors like this pseudo: path mismatch [12 links]: ino 39721500 db '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor' req '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'. Are you building on a NFS filesystem? NFS (and a few other filesystems) have a habit of remapping inodes out from under the filesystem. pseudo uses the inodes as a validation that the file hasn't changed. If these inodes are changing, pseudo will do it's best to keep things in sync, but there is a chance it won't always succeed. No I'm building on local ext3 filesystem, but I'm also using rm_work, so /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor is probably long gone and inode 39721500 wasn't marked as unused in pseudo world or do I read it wrong? (This is done because someone could access a file in pseudo control that was created outside.. so pseudo could only capture the inode.. then if in a future action the file is accessed the inode/path can be checked. If the inode matches it assumes it's the same file and now a path name exists.. if someone makes changes outside of pseudo control a similar check happens.. this time it'll see the path is the same but inode has changed.. so it guesses the file was modified and I believe resets everything based on the new inode. Each of these will generate a warning in the logs.) Thanks for clarifying that. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Uprev to pseudo 1.2
On 11/2/11 5:11 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 04:39:42PM -0500, Mark Hatle wrote: On 11/2/11 4:22 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote: Uprev to pseudo 1.2. This was heavily tested by building oe-core with numerous image configurations. Each configuration generated the same image before and after the change from the current to new version of pseudo. The primary purpose of this change is to enable the PSEUDO_UNLOAD functionality that may be used for performance enhancements in future versions of oe-core. The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755: meta: glib-2.0: don't apply qsort_r test removable patch for native version (2011-11-02 09:08:21 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/pseudo http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo Is there branch with pseudo-1.2 for oe-core? git://git.pokylinux.org/poky-contrib mhatle/pseudo Grab that -- or simply grab the top commit and add it to your oe-core checkout. Yes, but git cherry-pick would be faster and adding poky-contrib as another git remote is not very efficient as it doesn't share any git objects with oe-core repo so it checkouts whole poky again :/. So I'll use 2nd easiest option pw-am.sh 14227. I would like to try it because we have strange errors when libstc++ isn't found when building with pseudo, but same binaries are working fine without pseudo (seems related to /etc/ld.so.cache being ignored sometimes from pseudo env). And while I was trying to debug it I've noticed that files.db and pseudo.log is quite big. -rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db -rw-r--r-- 1 bitbake bitbake 91K Aug 15 13:50 logs.db -rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log The files.db is based on the number of files accessed during the time pseudo is running. Ah ok, this was in sysroot which was created Aug 9 so it gets pretty big fast, lets hope that sqlite3 can handle it efficiently, or is there some way to cleanup stale entries in files table? When you clean the build it will restart the pseudo DB. ie I'm using eglibc-2.14, but files table is full of eglibc-2.13 entries and _none_ from eglibc-2.14, is it supposed to be like this or is it sign of some pseudo problems? sqlite select count(*) from files where path like '%eglibc-2.13%'; 20221 sqlite select count(*) from files where path like '%eglibc-2.14%'; 0 sqlite select count(*) from files; 1085380 The pseudo DB is specific to the tmp work directory. If the work directory hasn't changed (i.e. you aren't updating versions and pr) then the pseudo DB will continue to grow to accommodate the new files. There are flags within the DB if an erase operation occurs, but entries are only tagged as erased -- but not removed. This is due to speed issues. pseudo is significantly slower on remove and replace operations if the DB entries are removed. logs.db and pseudo.log are based on the debug settings of pseudo. If you don't have debugging enabled (you would have to do this manually) and the logs are that big, something is going seriously wrong with the path/inode translation... It's fairly normal to have a set of logs that are in the 10-20k range for complex packages.. (These are documenting cases where pseudo has to guess about inode to path mapping..) This was generated without debug enabled.. but maybe because of rm_work, see below... with pseudo.log full of errors like this pseudo: path mismatch [12 links]: ino 39721500 db '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor' req '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'. Are you building on a NFS filesystem? NFS (and a few other filesystems) have a habit of remapping inodes out from under the filesystem. pseudo uses the inodes as a validation that the file hasn't changed. If these inodes are changing, pseudo will do it's best to keep things in sync, but there is a chance it won't always succeed. No I'm building on local ext3 filesystem, but I'm also using rm_work, so /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor is probably long gone and inode 39721500 wasn't marked as unused in pseudo world or do I read it wrong? If you use rm_work, then the pseudo DB located within the work directory will also be removed. So I'm not sure why you would be having such a large DB. (This is done because someone could access a file in pseudo control that was created outside.. so pseudo could only capture the inode.. then if in a future action the file is accessed the inode/path can be checked. If the inode matches it assumes it's the same file and now a path name exists.. if someone makes changes
Re: [OE-core] [PATCH 0/1] Uprev to pseudo 1.2
On Wed, Nov 02, 2011 at 05:31:59PM -0500, Mark Hatle wrote: On 11/2/11 5:11 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 04:39:42PM -0500, Mark Hatle wrote: On 11/2/11 4:22 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote: Uprev to pseudo 1.2. This was heavily tested by building oe-core with numerous image configurations. Each configuration generated the same image before and after the change from the current to new version of pseudo. The primary purpose of this change is to enable the PSEUDO_UNLOAD functionality that may be used for performance enhancements in future versions of oe-core. The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755: meta: glib-2.0: don't apply qsort_r test removable patch for native version (2011-11-02 09:08:21 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/pseudo http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo Is there branch with pseudo-1.2 for oe-core? git://git.pokylinux.org/poky-contrib mhatle/pseudo Grab that -- or simply grab the top commit and add it to your oe-core checkout. Yes, but git cherry-pick would be faster and adding poky-contrib as another git remote is not very efficient as it doesn't share any git objects with oe-core repo so it checkouts whole poky again :/. So I'll use 2nd easiest option pw-am.sh 14227. I would like to try it because we have strange errors when libstc++ isn't found when building with pseudo, but same binaries are working fine without pseudo (seems related to /etc/ld.so.cache being ignored sometimes from pseudo env). And while I was trying to debug it I've noticed that files.db and pseudo.log is quite big. -rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db -rw-r--r-- 1 bitbake bitbake 91K Aug 15 13:50 logs.db -rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log The files.db is based on the number of files accessed during the time pseudo is running. Ah ok, this was in sysroot which was created Aug 9 so it gets pretty big fast, lets hope that sqlite3 can handle it efficiently, or is there some way to cleanup stale entries in files table? When you clean the build it will restart the pseudo DB. ie I'm using eglibc-2.14, but files table is full of eglibc-2.13 entries and _none_ from eglibc-2.14, is it supposed to be like this or is it sign of some pseudo problems? sqlite select count(*) from files where path like '%eglibc-2.13%'; 20221 sqlite select count(*) from files where path like '%eglibc-2.14%'; 0 sqlite select count(*) from files; 1085380 The pseudo DB is specific to the tmp work directory. If the work directory hasn't changed (i.e. you aren't updating versions and pr) then the pseudo DB will continue to grow to accommodate the new files. There are flags within the DB if an erase operation occurs, but entries are only tagged as erased -- but not removed. This is due to speed issues. pseudo is significantly slower on remove and replace operations if the DB entries are removed. logs.db and pseudo.log are based on the debug settings of pseudo. If you don't have debugging enabled (you would have to do this manually) and the logs are that big, something is going seriously wrong with the path/inode translation... It's fairly normal to have a set of logs that are in the 10-20k range for complex packages.. (These are documenting cases where pseudo has to guess about inode to path mapping..) This was generated without debug enabled.. but maybe because of rm_work, see below... with pseudo.log full of errors like this pseudo: path mismatch [12 links]: ino 39721500 db '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor' req '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'. Are you building on a NFS filesystem? NFS (and a few other filesystems) have a habit of remapping inodes out from under the filesystem. pseudo uses the inodes as a validation that the file hasn't changed. If these inodes are changing, pseudo will do it's best to keep things in sync, but there is a chance it won't always succeed. No I'm building on local ext3 filesystem, but I'm also using rm_work, so /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor is probably long gone and inode 39721500 wasn't marked as unused in pseudo world or do I read it wrong? If you use rm_work, then the pseudo DB located within the work directory will also be removed. So I'm not sure why you would be having such a large DB. But I was talking about pseudo db here: tmp/sysroots/x86_64-linux/var/pseudo/ now with pseudo-1.2 I still have quite a few warnings about inodes in
[OE-core] [PATCH] python: improve packaging
* move 2to3 to separate package and include lib2to3 (was in python-misc)
* fix pattern for python-unittest (was in python-misc because it's in
subdirectory now)
* add pydoc_data to python-pydoc (was in python-misc)
* add more stuff to smtpd, audio, codecs, ctypes, html, io, json, mime,
pickle, stringold, xmlrpc
* move all FILES_ details from python recipe to manifest generator so it's in
one place
* added manual line break in FILES_${PN}-core, because git send-email
doesn't like too long lines
$ git send-email -1 dfaae65839f0ab23e5b2ae2a68df0f370bca84d2
fatal: /tmp/k8zbDajUNP/0001-python-improve-packaging.patch: 64: patch
contains a line longer than 998 characters
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../python/python-2.7-manifest.inc | 43 ++
meta/recipes-devtools/python/python_2.7.2.bb | 22 +-
scripts/contrib/python/generate-manifest-2.7.py| 47 ---
3 files changed, 55 insertions(+), 57 deletions(-)
diff --git a/meta/recipes-devtools/python/python-2.7-manifest.inc
b/meta/recipes-devtools/python/python-2.7-manifest.inc
index 69cb3c7..e4017ba 100644
--- a/meta/recipes-devtools/python/python-2.7-manifest.inc
+++ b/meta/recipes-devtools/python/python-2.7-manifest.inc
@@ -1,17 +1,21 @@
# WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I
regenerate the file.
-# Generator: 'scripts/contrib/python/generate-manifest-2.7.py' Version
20110222.1 (C) 2002-2010 Michael 'Mickey' Lauer mla...@vanille-media.de
+# Generator: 'scripts/contrib/python/generate-manifest-2.7.py' Version
20110222.2 (C) 2002-2010 Michael 'Mickey' Lauer mla...@vanille-media.de
# Visit the Python for Embedded Systems Site =
http://www.Vanille.de/projects/python.spy
-PROVIDES+=${PN}-audio ${PN}-bsddb ${PN}-codecs ${PN}-compile ${PN}-compiler
${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses
${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib ${PN}-distutils
${PN}-doctest ${PN}-elementtree ${PN}-email ${PN}-fcntl ${PN}-gdbm
${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image ${PN}-io ${PN}-json ${PN}-lang
${PN}-logging ${PN}-mailbox ${PN}-math ${PN}-mime ${PN}-mmap
${PN}-multiprocessing ${PN}-netclient ${PN}-netserver ${PN}-numbers
${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re
${PN}-readline ${PN}-resource ${PN}-robotparser ${PN}-shell ${PN}-smtpd
${PN}-sqlite3 ${PN}-sqlite3-tests ${PN}-stringold ${PN}-subprocess ${PN}-syslog
${PN}-terminal ${PN}-tests ${PN}-textutils ${PN}-threading ${PN}-tkinter
${PN}-unittest ${PN}-unixadmin ${PN}-xml ${PN}-xmlrpc ${PN}-zlib
+PROVIDES+=${PN}-2to3 ${PN}-audio ${PN}-bsddb ${PN}-codecs ${PN}-compile
${PN}-compiler ${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes
${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib
${PN}-distutils ${PN}-doctest ${PN}-elementtree ${PN}-email ${PN}-fcntl
${PN}-gdbm ${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image ${PN}-io ${PN}-json
${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math ${PN}-mime ${PN}-mmap
${PN}-multiprocessing ${PN}-netclient ${PN}-netserver ${PN}-numbers
${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re
${PN}-readline ${PN}-resource ${PN}-robotparser ${PN}-shell ${PN}-smtpd
${PN}-sqlite3 ${PN}-sqlite3-tests ${PN}-stringold ${PN}-subprocess ${PN}-syslog
${PN}-terminal ${PN}-tests ${PN}-textutils ${PN}-threading ${PN}-tkinter
${PN}-unittest ${PN}-unixadmin ${PN}-xml ${PN}-xmlrpc ${PN}-zlib
-PACKAGES=${PN}-dbg ${PN}-audio ${PN}-bsddb ${PN}-codecs ${PN}-compile
${PN}-compiler ${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes
${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib
${PN}-distutils ${PN}-doctest ${PN}-elementtree ${PN}-email ${PN}-fcntl
${PN}-gdbm ${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image ${PN}-io ${PN}-json
${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math ${PN}-mime ${PN}-mmap
${PN}-multiprocessing ${PN}-netclient ${PN}-netserver ${PN}-numbers
${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re
${PN}-readline ${PN}-resource ${PN}-robotparser ${PN}-shell ${PN}-smtpd
${PN}-sqlite3 ${PN}-sqlite3-tests ${PN}-stringold ${PN}-subprocess ${PN}-syslog
${PN}-terminal ${PN}-tests ${PN}-textutils ${PN}-threading ${PN}-tkinter
${PN}-unittest ${PN}-unixadmin ${PN}-xml ${PN}-xmlrpc ${PN}-zlib ${PN}-modules
+PACKAGES=${PN}-dbg ${PN}-2to3 ${PN}-audio ${PN}-bsddb ${PN}-codecs
${PN}-compile ${PN}-compiler ${PN}-compression ${PN}-core ${PN}-crypt
${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev
${PN}-difflib ${PN}-distutils ${PN}-doctest ${PN}-elementtree ${PN}-email
${PN}-fcntl ${PN}-gdbm ${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image ${PN}-io
${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math ${PN}-mime
${PN}-mmap ${PN}-multiprocessing ${PN}-netclient ${PN}-netserver ${PN}-numbers
${PN}-pickle
Re: [OE-core] [Pull v2 3/4] connman: create xuser
On 11/02/2011 11:54 AM, Otavio Salvador wrote: On Tue, Nov 1, 2011 at 19:44, Saul Wolds...@linux.intel.com wrote: We create xuser here as a backup incase that xerver-nodm-init is not on the system. This is wrong. If xserver-nodm-init (btw, there's a typo on the commit message) is not in the image user is suppose to know what he/she is doing so we shouldn't add users not required to make their life easier. Otavio, The situation is that when xserver-nodm-init is not installed or this is not a ROOTLESS_X, dbus still requires the xuser be available for connmand to run correctly. Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] how to set time zone
maybe we can do the link in system booting, use the variable TZ to
create the symlink /etc/localtime, just like archlinux.
e.g. providing one script in /etc/rcS.d/ to create the symlink.
On Thu, 2011-11-03 at 03:15 +0800, Mark Hatle wrote:
On 11/2/11 12:32 PM, Andrea Adami wrote:
On Mon, Oct 31, 2011 at 1:44 AM, Ni Qingliang niqingli...@insigma.com.cn
mailto:niqingli...@insigma.com.cn wrote:
I'd like the 'system level configuration' solution.
the /etc/localtime/ link can be done when packaging rootfs (using the
system level configuration).
On Fri, 2011-10-28 at 22:43 +0800, Mark Hatle wrote:
Setting the default TZ for the image is something that should be done
in a
post
install script for the tzdata package or something similar.
Since the /etc/localtime is usually a copy/hardlink or symlink to the
timezone
data we don't want to package it up. Instead we want to perform the
actions
that a program running on the target system itself would use to
change the
timezone.
So I think the easiest approach is to add a system level configuration
variable
(set the default).
Then use this variable to populate the configuration file that
specifies the
system timezone... and then use the post install process to check the
contents
of a text file.
Alternatively do this via an initscript -- but for folks w/ read-only
filesystems I'm not sure that will work.
--Mark
cut
Maybe I misunderstand system level configuration but in the meta-oe
recipe we have
DEFAULT_TIMEZONE ?= Europe/London
Maybe UTC would be better?
To me no timezone (which is UTC) is preferable as the system designer can then
set the timezone, externally to the package(s).
Note how the variable is weak thus can be overridden in local.conf.
Secondly, why do it as post-install or at image do_rootfs stage when we
have set
the variable and are therefore able to provide sane defaults in do_install?
If it's done within a do_install, then the file (/etc/timezone) itself gets
placed into the package. If it's in the package, then if/when someone
upgrades
the package from a feed the timezone gets reset to the previous value.
That's a
bug IMHO.
If it's done as a post-install script, then the timezone configuration can be
evaluated and if one isn't set -- or there is no timezone file -- then we can
set it to UTC or a similar default timezone.. (the value in the
DEFAULT_TIMEZONE
variable is reasonable in this approach.)
Other points before starting to write a patch:
-why is the recipe in oe-core doing chown -R root:root ${D} ?
There was an issue with the way the timezone data was extracted/constructed
that
it was have all of the build system's uid/gid preserved in the copy to the
final
install directory -- so when packaging incorrect usernames and groups were fed
into the process causing issues.
A simple chown -R root:root ${D} ensured that all of the timezone data was
owned
by the root user (on the target).
-the logic around # libc is removing zoneinfo files from package
Is it only eglibc?
Timezone info is updated more often then the system libc. So the zoneinfo
files
are handled externally of the libc. This allows for easier updates over
time..
(This is my guess, as I'm not familiar with exactly what this comment refers
to.)
Regards
Andrea
|
|
___
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
--
Yi Qingliang
niqingli...@insigma.com.cn
https://niqingliang2003.wordpress.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] how to set time zone
On Wed, Nov 2, 2011 at 22:47, Ni Qingliang niqingli...@insigma.com.cn wrote: maybe we can do the link in system booting, use the variable TZ to create the symlink /etc/localtime, just like archlinux. e.g. providing one script in /etc/rcS.d/ to create the symlink. This ought to be done by image IMO; so a kind of post rootfs generation hook might be use allowing it to be set per-image. I personally have this exactly use-case here at work. -- 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] how to set time zone
what is IMO? On Thu, 2011-11-03 at 09:19 +0800, Otavio Salvador wrote: On Wed, Nov 2, 2011 at 22:47, Ni Qingliang niqingli...@insigma.com.cn wrote: maybe we can do the link in system booting, use the variable TZ to create the symlink /etc/localtime, just like archlinux. e.g. providing one script in /etc/rcS.d/ to create the symlink. This ought to be done by image IMO; so a kind of post rootfs generation hook might be use allowing it to be set per-image. I personally have this exactly use-case here at work. -- 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 -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] Uprev to pseudo 1.2
On 11/2/11 5:47 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 05:31:59PM -0500, Mark Hatle wrote: On 11/2/11 5:11 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 04:39:42PM -0500, Mark Hatle wrote: On 11/2/11 4:22 PM, Martin Jansa wrote: On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote: Uprev to pseudo 1.2. This was heavily tested by building oe-core with numerous image configurations. Each configuration generated the same image before and after the change from the current to new version of pseudo. The primary purpose of this change is to enable the PSEUDO_UNLOAD functionality that may be used for performance enhancements in future versions of oe-core. The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755: meta: glib-2.0: don't apply qsort_r test removable patch for native version (2011-11-02 09:08:21 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib mhatle/pseudo http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo Is there branch with pseudo-1.2 for oe-core? git://git.pokylinux.org/poky-contrib mhatle/pseudo Grab that -- or simply grab the top commit and add it to your oe-core checkout. Yes, but git cherry-pick would be faster and adding poky-contrib as another git remote is not very efficient as it doesn't share any git objects with oe-core repo so it checkouts whole poky again :/. So I'll use 2nd easiest option pw-am.sh 14227. I would like to try it because we have strange errors when libstc++ isn't found when building with pseudo, but same binaries are working fine without pseudo (seems related to /etc/ld.so.cache being ignored sometimes from pseudo env). And while I was trying to debug it I've noticed that files.db and pseudo.log is quite big. -rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db -rw-r--r-- 1 bitbake bitbake 91K Aug 15 13:50 logs.db -rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log The files.db is based on the number of files accessed during the time pseudo is running. Ah ok, this was in sysroot which was created Aug 9 so it gets pretty big fast, lets hope that sqlite3 can handle it efficiently, or is there some way to cleanup stale entries in files table? When you clean the build it will restart the pseudo DB. ie I'm using eglibc-2.14, but files table is full of eglibc-2.13 entries and _none_ from eglibc-2.14, is it supposed to be like this or is it sign of some pseudo problems? sqlite select count(*) from files where path like '%eglibc-2.13%'; 20221 sqlite select count(*) from files where path like '%eglibc-2.14%'; 0 sqlite select count(*) from files; 1085380 The pseudo DB is specific to the tmp work directory. If the work directory hasn't changed (i.e. you aren't updating versions and pr) then the pseudo DB will continue to grow to accommodate the new files. There are flags within the DB if an erase operation occurs, but entries are only tagged as erased -- but not removed. This is due to speed issues. pseudo is significantly slower on remove and replace operations if the DB entries are removed. logs.db and pseudo.log are based on the debug settings of pseudo. If you don't have debugging enabled (you would have to do this manually) and the logs are that big, something is going seriously wrong with the path/inode translation... It's fairly normal to have a set of logs that are in the 10-20k range for complex packages.. (These are documenting cases where pseudo has to guess about inode to path mapping..) This was generated without debug enabled.. but maybe because of rm_work, see below... with pseudo.log full of errors like this pseudo: path mismatch [12 links]: ino 39721500 db '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor' req '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'. Are you building on a NFS filesystem? NFS (and a few other filesystems) have a habit of remapping inodes out from under the filesystem. pseudo uses the inodes as a validation that the file hasn't changed. If these inodes are changing, pseudo will do it's best to keep things in sync, but there is a chance it won't always succeed. No I'm building on local ext3 filesystem, but I'm also using rm_work, so /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor is probably long gone and inode 39721500 wasn't marked as unused in pseudo world or do I read it wrong? If you use rm_work, then the pseudo DB located within the work directory will also be removed. So I'm not sure why you would be having such a large DB. But I was talking about pseudo db here: tmp/sysroots/x86_64-linux/var/pseudo/ I just checked my system and the logs in the sysroot isn't very large. I'm curious as to why things are as big on your system. now with
Re: [OE-core] how to set time zone
On 11/02/2011 09:35 PM, Ni Qingliang wrote: what is IMO? In my opinion See http://www.internetslang.com/ I'm not suggesting reading the entire thing and using the slang in email though :) Philip On Thu, 2011-11-03 at 09:19 +0800, Otavio Salvador wrote: On Wed, Nov 2, 2011 at 22:47, Ni Qingliang niqingli...@insigma.com.cn wrote: maybe we can do the link in system booting, use the variable TZ to create the symlink /etc/localtime, just like archlinux. e.g. providing one script in /etc/rcS.d/ to create the symlink. This ought to be done by image IMO; so a kind of post rootfs generation hook might be use allowing it to be set per-image. I personally have this exactly use-case here at work. -- 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] how to set time zone
thanks! :) On Thu, 2011-11-03 at 09:58 +0800, Philip Balister wrote: On 11/02/2011 09:35 PM, Ni Qingliang wrote: what is IMO? In my opinion See http://www.internetslang.com/ I'm not suggesting reading the entire thing and using the slang in email though :) Philip On Thu, 2011-11-03 at 09:19 +0800, Otavio Salvador wrote: On Wed, Nov 2, 2011 at 22:47, Ni Qingliang niqingli...@insigma.com.cn wrote: maybe we can do the link in system booting, use the variable TZ to create the symlink /etc/localtime, just like archlinux. e.g. providing one script in /etc/rcS.d/ to create the symlink. This ought to be done by image IMO; so a kind of post rootfs generation hook might be use allowing it to be set per-image. I personally have this exactly use-case here at work. -- 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 -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
