[OE-core] [PATCH 0/1] linux-yocto/3.4: make uprobes select perf events
Richard/Saul, This update addresses YOCTO #3111, which is a build a failure on the mpc8315 after uprobes was enabled. We ended up fixing this twice (but both are good fixes), there's a kernel Kconfig fix from me and a kernel configuration fix by TomZ. Both fix the problem for the board showing the build error and have no impact on the other (already building) boards. cc: Tom Zanussi tom.zanu...@intel.com Cheers, Bruce The following changes since commit 1d5e637e32e10d7dabd19fbff9f4b25cc280daa2: linux-yocto: virtio and KVM guest configuration (2012-09-13 15:04:32 -0400) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/uprobes http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/uprobes Bruce Ashfield (1): linux-yocto/3.4: make uprobes select perf events meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |6 +++--- meta/recipes-kernel/linux/linux-yocto_3.4.bb| 14 +++--- 2 files changed, 10 insertions(+), 10 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] insane.bbclass: add library dir sanity check
Check in ${PKGD} for libraries in other locations
then ${libdir}. Trigger a warning if so.
[Yocto #2038]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/classes/insane.bbclass | 17 +
1 file changed, 17 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index e74eb3f..3a1b469 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -212,6 +212,17 @@ def package_qa_check_staticdev(path, name, d, elf,
messages):
messages.append(non -staticdev package contains static .a library: %s
path '%s' % \
(name, package_qa_clean_path(path,d)))
+def package_qa_check_libdir(path,libdir):
+
+
+import re
+lib_re = re.compile(^.*\.(so|a))
+for root, dirs, files in os.walk(path):
+if libdir not in root:
+for file in files:
+if lib_re.match(file):
+bb.warn(Found library in wrong location: %s %
os.path.join(root,file))
+
QAPATHTEST[debug-files] = package_qa_check_dbg
def package_qa_check_dbg(path, name, d, elf, messages):
@@ -688,6 +699,12 @@ python do_package_qa () {
rdepends_sane = False
+ml = d.getVar(MLPREFIX, True) or
+if ml:
+pkgd = d.getVar('PKGD', True)
+libdir = d.getVar(libdir, True)
+package_qa_check_libdir(pkgd,libdir)
+
if not walk_sane or not rdepends_sane:
bb.fatal(QA run found fatal errors. Please consider fixing them.)
bb.note(DONE with PACKAGE QA)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED REQUEST 00/26] Update Fixes (cover only)
On Fri, 2012-09-14 at 00:04 -0700, Saul Wold wrote:
Richard,
THis is a continuation of yesterday's Fix list. It includes
some patches for some AB related issues such as the MPC8315
and Multilib (really license.bbclass failure).
I have also included the patch you suggested for the SRCPV
issue in sstate hash, it does change now, that commit message
might need somemore info from you since I just tried it.
Hope you can pull most of these during your day!
Andrei Dinu (1):
libffi upgrade to 3.0.11
Andrei Gherzan (2):
image_types.bbclass: Round up ROOTFS_SIZE after base_size check
taglib: Update to v1.8
Bruce Ashfield (3):
kernel-yocto: fix kernel configuration audit for custom yocto kernels
linux-yocto: virtio and KVM guest configuration
linux-yocto/3.4: make uprobes select perf events
Constantin Musca (1):
patch.bbclass: Use one TMPDIR per patching process
Jack Mitchell (1):
git: define NO_PYTHON=1 to stop git requiring python as a dependancy
Khem Raj (4):
kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC
There are a number of questions about this one, I've left it for now.
uclibc: Revert systemd regressing patch from upsteam uclibc and uprev
SRCREV
runqemu: Explicitly specify MACHINE when calling bitbake
binutils-2.22: Backport PR fixes from 2.22 branch
Matthew McClintock (1):
valgrind_3.7.0.bb: fix missing leading space on _append
Paul Eggleton (3):
gst-fluendo-mpegdemux: add LICENSE_FLAGS
scripts/combo-layer: use last_revision if specified in init
scripts/combo-layer: ensure we validate branch/revision on init
Peter Seebach (1):
pseudo_1.4.1.bb: update to pseudo 1.4.1, fixing 32-bit host problems
Richard Purdie (1):
opkg: Fix package dependency issue for preinsts
Ross Burton (4):
connman: remove trailing whitespace
librsvg: --disable-gnome-vfs doesn't exist anymore, remove
librsvg: remove spurious popt dependency
libx11: update patch to a backport from upstream git
Saul Wold (4):
oprofileui: Add Icons to oprofileui-viewer package
kernelshark: add missing ${D}
license: Ensure we find multilib packages also
This one looks like it might introduce other issues...
bitbake.conf: Assign SRCPV so that it will be tracked in siginfo
I tweaked this one as discussed.
Otherwise I merged things, thanks.
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 1/1] linux-yocto/3.4: make uprobes select perf events
On Fri, 2012-09-14 at 00:57 -0400, Bruce Ashfield wrote: uprobes depends on functionality provided by perf events. After uprobes was enabled in the standard kernel the mpc8315 board showed link errors due to missing perf event functions. This problem isn't isolated to the board or powerpc arch, but all other boards have PERF_EVENTS enabled. To fix this, we make UPROBE_EVENT select PERF_EVENTS, and any new boards will be protected from the same failure. We also update the configuration fragments since CONFIG_UPROBES depends on CONFIG_PERF_EVENTS being set, so PERF_EVENTS needs to be added whenever uprobes are enabled. [YOCTO #3111] Signed-off-by: Tom Zanussi tom.zanu...@intel.com Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com --- meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |6 +++--- meta/recipes-kernel/linux/linux-yocto_3.4.bb| 14 +++--- 2 files changed, 10 insertions(+), 10 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
[OE-core] [PATCH v2] insane.bbclass: add library dir sanity check
Check in ${PKGD} for libraries in other locations
then ${libdir}. Trigger a warning if so.
[Yocto #2038]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/classes/insane.bbclass | 18 ++
1 file changed, 18 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index e74eb3f..6388609 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -212,6 +212,18 @@ def package_qa_check_staticdev(path, name, d, elf,
messages):
messages.append(non -staticdev package contains static .a library: %s
path '%s' % \
(name, package_qa_clean_path(path,d)))
+def package_qa_check_libdir(path,libdir):
+
+Check in path for libraries in other locations then libdir. Trigger a
warning if so.
+
+import re
+lib_re = re.compile(^.*\.(so|a))
+for root, dirs, files in os.walk(path):
+if libdir not in root:
+for file in files:
+if lib_re.match(file):
+bb.warn(Found library in wrong location: %s %
os.path.join(root,file))
+
QAPATHTEST[debug-files] = package_qa_check_dbg
def package_qa_check_dbg(path, name, d, elf, messages):
@@ -688,6 +700,12 @@ python do_package_qa () {
rdepends_sane = False
+ml = d.getVar(MLPREFIX, True) or
+if ml:
+pkgd = d.getVar('PKGD', True)
+libdir = d.getVar(libdir, True)
+package_qa_check_libdir(pkgd,libdir)
+
if not walk_sane or not rdepends_sane:
bb.fatal(QA run found fatal errors. Please consider fixing them.)
bb.note(DONE with PACKAGE QA)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] insane.bbclass: add library dir sanity check
Added comments.
radu
On 09/14/2012 12:03 PM, Radu Moisan wrote:
Check in ${PKGD} for libraries in other locations
then ${libdir}. Trigger a warning if so.
[Yocto #2038]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/classes/insane.bbclass | 18 ++
1 file changed, 18 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index e74eb3f..6388609 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -212,6 +212,18 @@ def package_qa_check_staticdev(path, name, d, elf,
messages):
messages.append(non -staticdev package contains static .a library: %s
path '%s' % \
(name, package_qa_clean_path(path,d)))
+def package_qa_check_libdir(path,libdir):
+
+Check in path for libraries in other locations then libdir. Trigger a
warning if so.
+
+import re
+lib_re = re.compile(^.*\.(so|a))
+for root, dirs, files in os.walk(path):
+if libdir not in root:
+for file in files:
+if lib_re.match(file):
+bb.warn(Found library in wrong location: %s %
os.path.join(root,file))
+
QAPATHTEST[debug-files] = package_qa_check_dbg
def package_qa_check_dbg(path, name, d, elf, messages):
@@ -688,6 +700,12 @@ python do_package_qa () {
rdepends_sane = False
+ml = d.getVar(MLPREFIX, True) or
+if ml:
+pkgd = d.getVar('PKGD', True)
+libdir = d.getVar(libdir, True)
+package_qa_check_libdir(pkgd,libdir)
+
if not walk_sane or not rdepends_sane:
bb.fatal(QA run found fatal errors. Please consider fixing them.)
bb.note(DONE with PACKAGE QA)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] librsvg: make the libcroco dependency a PACKAGECONFIG option
On Thu, 2012-09-13 at 23:25 -0700, Saul Wold wrote: On 09/13/2012 03:04 AM, Ross Burton wrote: Default to enabling it as we were build-depending on it already. If a user needs the disk space and the limitations imposed by not using libcroco are acceptable they can override this. Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-gnome/librsvg/librsvg_2.32.1.bb |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb index 6bb5fe2..012b3ba 100644 --- a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb +++ b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb @@ -7,15 +7,18 @@ LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ file://rsvg.h;beginline=3;endline=24;md5=20b4113c4909bbf0d67e006778302bc6 SECTION = x11/utils -DEPENDS = gtk+ libcroco cairo libxml2 +DEPENDS = gtk+ cairo libxml2 DEPENDS_virtclass-native = cairo-native pango-native gdk-pixbuf-native BBCLASSEXTEND = native -PR = r9 +PR = r10 inherit autotools pkgconfig gnome gtk-doc -EXTRA_OECONF = --disable-mozilla-plugin --without-svgz --without-croco +EXTRA_OECONF = --disable-mozilla-plugin --without-svgz + +PACKAGECONFIG ??= croco Needs a +PACKAGECONFIG_class-native ??= +PACKAGECONFIG[croco] = --with-croco,--without-croco,libcroco This change seems to introduce a new native dependency on libcroco-native. ERROR: Nothing PROVIDES 'libcroco-native' (but virtual:native:/srv/home/pokybuild/yocto-autobuilder/yocto-slave/build-appliance/build/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb DEPENDS on or otherwise requires it) This was during a bitbake -c fetch universe 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 1/2] gst-ffmpeg: add LICENSE_FLAGS
On 14 September 2012 07:28, Saul Wold s...@linux.intel.com wrote: ERROR: Nothing RPROVIDES 'gst-ffmpeg' (but /srv/home/pokybuild/yocto-autobuilder/yocto-slave/meta-intel-gpl/build/yocto/meta-intel/common/recipes-multimedia/gstreamer/gst-va-intel.bb RDEPENDS on or otherwise requires it) That's interesting, I wasn't aware gst-va required ffmpeg. At the most it should be a recommends as elements are pluggable, and to be honest I'm pretty sure that's a bad dependency. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] librsvg: make the libcroco dependency a PACKAGECONFIG option
Default to enabling it as we were build-depending on it already. If a user needs the disk space and the limitations imposed by not using libcroco are acceptable they can override this. Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-gnome/librsvg/librsvg_2.32.1.bb | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb index 6bb5fe2..b118805 100644 --- a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb +++ b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb @@ -7,15 +7,21 @@ LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ file://rsvg.h;beginline=3;endline=24;md5=20b4113c4909bbf0d67e006778302bc6 SECTION = x11/utils -DEPENDS = gtk+ libcroco cairo libxml2 +DEPENDS = gtk+ cairo libxml2 DEPENDS_virtclass-native = cairo-native pango-native gdk-pixbuf-native BBCLASSEXTEND = native -PR = r9 +PR = r10 inherit autotools pkgconfig gnome gtk-doc -EXTRA_OECONF = --disable-mozilla-plugin --without-svgz --without-croco +EXTRA_OECONF = --disable-mozilla-plugin --without-svgz + +PACKAGECONFIG ??= croco +# When native we can manage without croco, as it's only for GTK+ +PACKAGECONFIG_class-native ??= + +PACKAGECONFIG[croco] = --with-croco,--without-croco,libcroco SRC_URI += file://doc_Makefile.patch -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] insane.bbclass: add library dir sanity check
Check in ${PKGD} for libraries in other locations
then ${libdir}. Trigger a warning if so.
[Yocto #2038]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/classes/insane.bbclass | 18 ++
1 file changed, 18 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index e74eb3f..d748c26 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -212,6 +212,18 @@ def package_qa_check_staticdev(path, name, d, elf,
messages):
messages.append(non -staticdev package contains static .a library: %s
path '%s' % \
(name, package_qa_clean_path(path,d)))
+def package_qa_check_libdir(path,libdir):
+
+Check in path for libraries in other locations then libdir. Trigger a
warning if so.
+
+import re
+lib_re = re.compile(^.*\.(so))
+for root, dirs, files in os.walk(path):
+if libdir not in root:
+for file in files:
+if lib_re.match(file):
+bb.warn(Found library in wrong location: %s %
os.path.join(root,file))
+
QAPATHTEST[debug-files] = package_qa_check_dbg
def package_qa_check_dbg(path, name, d, elf, messages):
@@ -688,6 +700,12 @@ python do_package_qa () {
rdepends_sane = False
+ml = d.getVar(MLPREFIX, True) or
+if ml:
+pkgd = d.getVar('PKGD', True)
+libdir = d.getVar(libdir, True)
+package_qa_check_libdir(pkgd,libdir)
+
if not walk_sane or not rdepends_sane:
bb.fatal(QA run found fatal errors. Please consider fixing them.)
bb.note(DONE with PACKAGE QA)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] insane.bbclass: add library dir sanity check
has problems with re pattern.
preparing v4
radu
On 09/14/2012 12:50 PM, Radu Moisan wrote:
Check in ${PKGD} for libraries in other locations
then ${libdir}. Trigger a warning if so.
[Yocto #2038]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/classes/insane.bbclass | 18 ++
1 file changed, 18 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index e74eb3f..d748c26 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -212,6 +212,18 @@ def package_qa_check_staticdev(path, name, d, elf,
messages):
messages.append(non -staticdev package contains static .a library: %s
path '%s' % \
(name, package_qa_clean_path(path,d)))
+def package_qa_check_libdir(path,libdir):
+
+Check in path for libraries in other locations then libdir. Trigger a
warning if so.
+
+import re
+lib_re = re.compile(^.*\.(so))
+for root, dirs, files in os.walk(path):
+if libdir not in root:
+for file in files:
+if lib_re.match(file):
+bb.warn(Found library in wrong location: %s %
os.path.join(root,file))
+
QAPATHTEST[debug-files] = package_qa_check_dbg
def package_qa_check_dbg(path, name, d, elf, messages):
@@ -688,6 +700,12 @@ python do_package_qa () {
rdepends_sane = False
+ml = d.getVar(MLPREFIX, True) or
+if ml:
+pkgd = d.getVar('PKGD', True)
+libdir = d.getVar(libdir, True)
+package_qa_check_libdir(pkgd,libdir)
+
if not walk_sane or not rdepends_sane:
bb.fatal(QA run found fatal errors. Please consider fixing them.)
bb.note(DONE with PACKAGE QA)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] patch.bbclass: Use one TMPDIR per patching process
On Fri, 2012-09-14 at 13:28 +0200, Enrico Scholz wrote:
Constantin Musca
constantinx.musca-ral2jqcrhueavxtiumw...@public.gmane.org writes:
+process_tmpdir = os.path.join('/tmp', str(os.getpid()))
+if os.path.exists(process_tmpdir):
+shutil.rmtree(process_tmpdir)
+os.makedirs(process_tmpdir)
ooo... this violates trivial rules regarding secure generation of
tempfiles. Better use 'mkdtemp()' from the 'tempfile' module.
The problem is that the internal temp directory creation inside patch
can be broken. We *really* don't want to start building patch-native so
this workaround gives patch a fighting chance of not conflicting with
other instances of itself. Its only being used as a prefix, not as the
full directory path name so it isn't quite as insecure as it would first
appear.
I'm fine if we want to use the mkdtemp approach though and further
randomise this. I'd also suggest any updated version adds a comment to
the code about *why* we need a separate TMPDIR and which versions of
patch have this problem.
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 1/4] gcc: Switch SRC_URI to use svn
On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg b...@enea.com wrote: Khem Raj wrote: I agree but then 1.7 GB is noticeably huge too and it will only become larger in future so I don't think fetching from git will be a good solution for gcc ever. Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. I did not check if the fetcher has this support but it would be a nice solution. Shallow clones won't be able to support SRCREV properly, as you can only clone shallowly from HEAD, not from an arbitrary point in history, AFAIK. Right, shallow clones are a can of worms from a variety of angles. My current thinking is a ;allowsinglerev=1 parameter to the git fetcher which: a) Generates tarballs of single git revisions if tarball generation is turned on b) Searches for single revision tarballs before trying the main checkout approach. This would mean that WORKDIR may or may not have a .git directory for any SRC_URI marked with this. I think we should all be able to live with that and it shouldn't break too much? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Nothing provides libxcb-*
I am trying to use the package libxcb-xfixes in a recipe however when I add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides libxcb-xfixes however the libxcb package clearly has it in the PACKAGES variable recipes-graphics/xcb/libxcb.inc:PACKAGES =+ libxcb-composite libxcb-damage libxcb-dpms libxcb-glx \ recipes-graphics/xcb/libxcb.inc: libxcb-randr libxcb-record libxcb-render libxcb-res \ recipes-graphics/xcb/libxcb.inc: libxcb-screensaver libxcb-shape libxcb-shm libxcb-sync \ recipes-graphics/xcb/libxcb.inc: libxcb-xevie libxcb-xf86dri libxcb-xfixes libxcb-xlib \ recipes-graphics/xcb/libxcb.inc: libxcb-xprint libxcb-xtest libxcb-xv libxcb-xvmc \ recipes-graphics/xcb/libxcb.inc: libxcb-dri2 I have also tried using others in this package list to no avail, can anybody comment on how I should be using these packages? Regards, -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Nothing provides libxcb-*
On 14 September 2012 13:09, Jack Mitchell m...@communistcode.co.uk wrote: I am trying to use the package libxcb-xfixes in a recipe however when I add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides libxcb-xfixes however the libxcb package clearly has it in the PACKAGES variable Build-time dependencies are on source recipes, so you'll DEPEND on just libxcb. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Nothing provides libxcb-*
On Fri, 2012-09-14 at 13:09 +0100, Jack Mitchell wrote:
I am trying to use the package libxcb-xfixes in a recipe however when I
add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides
libxcb-xfixes however the libxcb package clearly has it in the PACKAGES
variable
recipes-graphics/xcb/libxcb.inc:PACKAGES =+ libxcb-composite
libxcb-damage libxcb-dpms libxcb-glx \
recipes-graphics/xcb/libxcb.inc: libxcb-randr libxcb-record
libxcb-render libxcb-res \
recipes-graphics/xcb/libxcb.inc: libxcb-screensaver libxcb-shape
libxcb-shm libxcb-sync \
recipes-graphics/xcb/libxcb.inc: libxcb-xevie libxcb-xf86dri
libxcb-xfixes libxcb-xlib \
recipes-graphics/xcb/libxcb.inc: libxcb-xprint libxcb-xtest libxcb-xv
libxcb-xvmc \
recipes-graphics/xcb/libxcb.inc: libxcb-dri2
I have also tried using others in this package list to no avail, can
anybody comment on how I should be using these packages?
You're mixing up the build time and runtime namespaces. You would add
DEPENDS = libxcb or RDEPENDS_${PN}-xxx = libxcb-xfixes.
DEPENDS is build time and you use PN
RDEPENDS/RRECOMMENDS/R* is runtime and values from PACKAGES
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] patch.bbclass: Use one TMPDIR per patching process
Richard Purdie richard.pur...@linuxfoundation.org writes:
+process_tmpdir = os.path.join('/tmp', str(os.getpid()))
+shutil.rmtree(process_tmpdir)
Its only being used as a prefix, not as the full directory path name
so it isn't quite as insecure as it would first appear.
It *is* insecure as it would first appear. 'shutil.rmtree()' does not
traverse the directory in a secure way so that an attacker could:
1. touch /tmp/2-32767/a
2. mkdir /tmp/2-32767/Z
3. wait for an inotify which triggers on deletion of the 'a' files
4. rmdir /tmp/$dir/Z
5. ln -s /home/user /tmp/$dir/Z
When steps 4+5 are executed between
| $ strace python -c 'import shutil; shutil.rmtree(/tmp/2);'
| ...
| lstat(/tmp/2/Z, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
| steps 4+5 here
| openat(AT_FDCWD, /tmp/2/Z, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
| getdents(3, /* 3 entries */, 32768) = 72
| ...
| unlink(/tmp/2/Z/foo) = 0
user writable directories will be removed.
There have been established some rules regarding secure tmpfile/dir
generation in the last 10-20 years which should never be violated.
Beside the obvious security issues, build will be aborted when somebody
else creates a /tmp/number file and number matches the bitbake pid.
Enrico
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Nothing provides libxcb-*
On 14/09/12 13:16, Richard Purdie wrote:
On Fri, 2012-09-14 at 13:09 +0100, Jack Mitchell wrote:
I am trying to use the package libxcb-xfixes in a recipe however when I
add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides
libxcb-xfixes however the libxcb package clearly has it in the PACKAGES
variable
recipes-graphics/xcb/libxcb.inc:PACKAGES =+ libxcb-composite
libxcb-damage libxcb-dpms libxcb-glx \
recipes-graphics/xcb/libxcb.inc: libxcb-randr libxcb-record
libxcb-render libxcb-res \
recipes-graphics/xcb/libxcb.inc: libxcb-screensaver libxcb-shape
libxcb-shm libxcb-sync \
recipes-graphics/xcb/libxcb.inc: libxcb-xevie libxcb-xf86dri
libxcb-xfixes libxcb-xlib \
recipes-graphics/xcb/libxcb.inc: libxcb-xprint libxcb-xtest libxcb-xv
libxcb-xvmc \
recipes-graphics/xcb/libxcb.inc: libxcb-dri2
I have also tried using others in this package list to no avail, can
anybody comment on how I should be using these packages?
You're mixing up the build time and runtime namespaces. You would add
DEPENDS = libxcb or RDEPENDS_${PN}-xxx = libxcb-xfixes.
DEPENDS is build time and you use PN
RDEPENDS/RRECOMMENDS/R* is runtime and values from PACKAGES
Cheers,
Richard
Ok, thanks! I guess I have a bigger problem then, the error I am
recieving is:
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| ERROR: Xfixes not found
|
| If you think configure made a mistake, make sure you are using the latest
| version from Git. If the latest version fails, report the problem to the
| libav-u...@libav.org mailing list or IRC #libav on irc.freenode.net.
| Include the log file config.log produced by configure as this will help
| solving the problem.
Now, I have libxcb in DEPENDS and I have the following configure options:
EXTRA_OECONF = \
--cross-prefix=${TARGET_PREFIX} \
--enable-cross-compile \
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
--target-os=linux \
--extra-cflags=${TARGET_CFLAGS}
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} \
--extra-ldflags=${TARGET_LDFLAGS} \
--arch=${TARGET_ARCH} \
--enable-hardcoded-tables \
--enable-shared \
--enable-pthreads \
--enable-gpl \
--enable-avfilter \
--prefix=${prefix} \
--enable-x11grab \
--enable-libtheora \
--enable-libvorbis \
${EXTRA_FFCONF} \
Is there anything glaringly wrong?I am worried about these two:
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
Cheers,
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Nothing provides libxcb-*
On 14/09/12 13:36, Jack Mitchell wrote:
On 14/09/12 13:32, Jack Mitchell wrote:
On 14/09/12 13:16, Richard Purdie wrote:
On Fri, 2012-09-14 at 13:09 +0100, Jack Mitchell wrote:
I am trying to use the package libxcb-xfixes in a recipe however
when I
add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides
libxcb-xfixes however the libxcb package clearly has it in the
PACKAGES
variable
recipes-graphics/xcb/libxcb.inc:PACKAGES =+ libxcb-composite
libxcb-damage libxcb-dpms libxcb-glx \
recipes-graphics/xcb/libxcb.inc: libxcb-randr libxcb-record
libxcb-render libxcb-res \
recipes-graphics/xcb/libxcb.inc: libxcb-screensaver libxcb-shape
libxcb-shm libxcb-sync \
recipes-graphics/xcb/libxcb.inc: libxcb-xevie libxcb-xf86dri
libxcb-xfixes libxcb-xlib \
recipes-graphics/xcb/libxcb.inc: libxcb-xprint libxcb-xtest libxcb-xv
libxcb-xvmc \
recipes-graphics/xcb/libxcb.inc: libxcb-dri2
I have also tried using others in this package list to no avail, can
anybody comment on how I should be using these packages?
You're mixing up the build time and runtime namespaces. You would add
DEPENDS = libxcb or RDEPENDS_${PN}-xxx = libxcb-xfixes.
DEPENDS is build time and you use PN
RDEPENDS/RRECOMMENDS/R* is runtime and values from PACKAGES
Cheers,
Richard
Ok, thanks! I guess I have a bigger problem then, the error I am
recieving is:
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| ERROR: Xfixes not found
|
| If you think configure made a mistake, make sure you are using the
latest
| version from Git. If the latest version fails, report the problem
to the
| libav-u...@libav.org mailing list or IRC #libav on irc.freenode.net.
| Include the log file config.log produced by configure as this
will help
| solving the problem.
Now, I have libxcb in DEPENDS and I have the following configure
options:
EXTRA_OECONF = \
--cross-prefix=${TARGET_PREFIX} \
--enable-cross-compile \
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
--target-os=linux \
--extra-cflags=${TARGET_CFLAGS}
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} \
--extra-ldflags=${TARGET_LDFLAGS} \
--arch=${TARGET_ARCH} \
--enable-hardcoded-tables \
--enable-shared \
--enable-pthreads \
--enable-gpl \
--enable-avfilter \
--prefix=${prefix} \
--enable-x11grab \
--enable-libtheora \
--enable-libvorbis \
${EXTRA_FFCONF} \
Is there anything glaringly wrong?I am worried about these two:
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
Cheers,
Possibly of use?
check_lib X11/extensions/Xfixes.h XFixesGetCursorImage -lXfixes
check_header X11/extensions/Xfixes.h
check_cpp
BEGIN /tmp/ffconf.RboCj6pF.c
1 #include X11/extensions/Xfixes.h
2 int x;
END /tmp/ffconf.RboCj6pF.c
arm-poky-linux-gnueabi-gcc
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -O2 -pipe -g
-feliminate-unused-debug-types -O2 -pipe -g
-feliminate-unused-debug-types -march=armv6 -mthumb-interwork
-mfloat-abi=softfp -mtune=arm1176jzf-s
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-std=c99 -fomit-frame-pointer -marm -pthread -E -o
/tmp/ffconf.IQTkUVuf.o /tmp/ffconf.RboCj6pF.c
/tmp/ffconf.RboCj6pF.c:1:35: fatal error: X11/extensions/Xfixes.h: No
such file or directory
compilation terminated.
ERROR: Xfixes not found
I can confirm that there is indeed no X11/extensions/Xfixes.h:
[jack@archHP raspberrypi]$ find . -name X11
./usr/include/X11
./usr/lib/X11
./usr/share/X11
[jack@archHP raspberrypi]$ find . -name Xfixes.h
[jack@archHP raspberrypi]$
Even though I have:
RDEPENDS_${PN} = libxcb-xfixes
What do I have to do to get it in the sysroot so it can compile against it?
Thanks,
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Nothing provides libxcb-*
On Fri, 2012-09-14 at 14:01 +0100, Jack Mitchell wrote:
On 14/09/12 13:36, Jack Mitchell wrote:
On 14/09/12 13:32, Jack Mitchell wrote:
On 14/09/12 13:16, Richard Purdie wrote:
On Fri, 2012-09-14 at 13:09 +0100, Jack Mitchell wrote:
I am trying to use the package libxcb-xfixes in a recipe however
when I
add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides
libxcb-xfixes however the libxcb package clearly has it in the
PACKAGES
variable
recipes-graphics/xcb/libxcb.inc:PACKAGES =+ libxcb-composite
libxcb-damage libxcb-dpms libxcb-glx \
recipes-graphics/xcb/libxcb.inc: libxcb-randr libxcb-record
libxcb-render libxcb-res \
recipes-graphics/xcb/libxcb.inc: libxcb-screensaver libxcb-shape
libxcb-shm libxcb-sync \
recipes-graphics/xcb/libxcb.inc: libxcb-xevie libxcb-xf86dri
libxcb-xfixes libxcb-xlib \
recipes-graphics/xcb/libxcb.inc: libxcb-xprint libxcb-xtest libxcb-xv
libxcb-xvmc \
recipes-graphics/xcb/libxcb.inc: libxcb-dri2
I have also tried using others in this package list to no avail, can
anybody comment on how I should be using these packages?
You're mixing up the build time and runtime namespaces. You would add
DEPENDS = libxcb or RDEPENDS_${PN}-xxx = libxcb-xfixes.
DEPENDS is build time and you use PN
RDEPENDS/RRECOMMENDS/R* is runtime and values from PACKAGES
Cheers,
Richard
Ok, thanks! I guess I have a bigger problem then, the error I am
recieving is:
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| ERROR: Xfixes not found
|
| If you think configure made a mistake, make sure you are using the
latest
| version from Git. If the latest version fails, report the problem
to the
| libav-u...@libav.org mailing list or IRC #libav on irc.freenode.net.
| Include the log file config.log produced by configure as this
will help
| solving the problem.
Now, I have libxcb in DEPENDS and I have the following configure
options:
EXTRA_OECONF = \
--cross-prefix=${TARGET_PREFIX} \
--enable-cross-compile \
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
--target-os=linux \
--extra-cflags=${TARGET_CFLAGS}
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} \
--extra-ldflags=${TARGET_LDFLAGS} \
--arch=${TARGET_ARCH} \
--enable-hardcoded-tables \
--enable-shared \
--enable-pthreads \
--enable-gpl \
--enable-avfilter \
--prefix=${prefix} \
--enable-x11grab \
--enable-libtheora \
--enable-libvorbis \
${EXTRA_FFCONF} \
Is there anything glaringly wrong?I am worried about these two:
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
Cheers,
Possibly of use?
check_lib X11/extensions/Xfixes.h XFixesGetCursorImage -lXfixes
check_header X11/extensions/Xfixes.h
check_cpp
BEGIN /tmp/ffconf.RboCj6pF.c
1 #include X11/extensions/Xfixes.h
2 int x;
END /tmp/ffconf.RboCj6pF.c
arm-poky-linux-gnueabi-gcc
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -O2 -pipe -g
-feliminate-unused-debug-types -O2 -pipe -g
-feliminate-unused-debug-types -march=armv6 -mthumb-interwork
-mfloat-abi=softfp -mtune=arm1176jzf-s
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-std=c99 -fomit-frame-pointer -marm -pthread -E -o
/tmp/ffconf.IQTkUVuf.o /tmp/ffconf.RboCj6pF.c
/tmp/ffconf.RboCj6pF.c:1:35: fatal error: X11/extensions/Xfixes.h: No
such file or directory
compilation terminated.
ERROR: Xfixes not found
I can confirm that there is indeed no X11/extensions/Xfixes.h:
[jack@archHP raspberrypi]$ find . -name X11
./usr/include/X11
./usr/lib/X11
./usr/share/X11
[jack@archHP raspberrypi]$ find . -name Xfixes.h
[jack@archHP raspberrypi]$
Even though I have:
RDEPENDS_${PN} = libxcb-xfixes
What do I have to do to get it in the sysroot so it can compile against it?
You didn't say you were doing that ;-).
You need -dev packages, try libxcb-dev?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Nothing provides libxcb-*
On Fri, 2012-09-14 at 13:36 +0100, Jack Mitchell wrote:
On 14/09/12 13:32, Jack Mitchell wrote:
On 14/09/12 13:16, Richard Purdie wrote:
On Fri, 2012-09-14 at 13:09 +0100, Jack Mitchell wrote:
I am trying to use the package libxcb-xfixes in a recipe however when I
add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides
libxcb-xfixes however the libxcb package clearly has it in the PACKAGES
variable
recipes-graphics/xcb/libxcb.inc:PACKAGES =+ libxcb-composite
libxcb-damage libxcb-dpms libxcb-glx \
recipes-graphics/xcb/libxcb.inc: libxcb-randr libxcb-record
libxcb-render libxcb-res \
recipes-graphics/xcb/libxcb.inc: libxcb-screensaver libxcb-shape
libxcb-shm libxcb-sync \
recipes-graphics/xcb/libxcb.inc: libxcb-xevie libxcb-xf86dri
libxcb-xfixes libxcb-xlib \
recipes-graphics/xcb/libxcb.inc: libxcb-xprint libxcb-xtest libxcb-xv
libxcb-xvmc \
recipes-graphics/xcb/libxcb.inc: libxcb-dri2
I have also tried using others in this package list to no avail, can
anybody comment on how I should be using these packages?
You're mixing up the build time and runtime namespaces. You would add
DEPENDS = libxcb or RDEPENDS_${PN}-xxx = libxcb-xfixes.
DEPENDS is build time and you use PN
RDEPENDS/RRECOMMENDS/R* is runtime and values from PACKAGES
Cheers,
Richard
Ok, thanks! I guess I have a bigger problem then, the error I am
recieving is:
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| ERROR: Xfixes not found
|
| If you think configure made a mistake, make sure you are using the
latest
| version from Git. If the latest version fails, report the problem
to the
| libav-u...@libav.org mailing list or IRC #libav on irc.freenode.net.
| Include the log file config.log produced by configure as this will
help
| solving the problem.
Now, I have libxcb in DEPENDS and I have the following configure options:
EXTRA_OECONF = \
--cross-prefix=${TARGET_PREFIX} \
--enable-cross-compile \
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
--target-os=linux \
--extra-cflags=${TARGET_CFLAGS}
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} \
--extra-ldflags=${TARGET_LDFLAGS} \
--arch=${TARGET_ARCH} \
--enable-hardcoded-tables \
--enable-shared \
--enable-pthreads \
--enable-gpl \
--enable-avfilter \
--prefix=${prefix} \
--enable-x11grab \
--enable-libtheora \
--enable-libvorbis \
${EXTRA_FFCONF} \
Is there anything glaringly wrong?I am worried about these two:
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
Cheers,
Possibly of use?
check_lib X11/extensions/Xfixes.h XFixesGetCursorImage -lXfixes
check_header X11/extensions/Xfixes.h
check_cpp
BEGIN /tmp/ffconf.RboCj6pF.c
1 #include X11/extensions/Xfixes.h
2 int x;
END /tmp/ffconf.RboCj6pF.c
arm-poky-linux-gnueabi-gcc
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -O2 -pipe -g
-feliminate-unused-debug-types -O2 -pipe -g
-feliminate-unused-debug-types -march=armv6 -mthumb-interwork
-mfloat-abi=softfp -mtune=arm1176jzf-s
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-std=c99 -fomit-frame-pointer -marm -pthread -E -o
/tmp/ffconf.IQTkUVuf.o /tmp/ffconf.RboCj6pF.c
/tmp/ffconf.RboCj6pF.c:1:35: fatal error: X11/extensions/Xfixes.h: No
such file or directory
compilation terminated.
ERROR: Xfixes not found
Sorry, I misunderstood this, ignore my last reply. That header comes
from libxfixes so you probably need a DEPENDS on that too.
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 1/4] gcc: Switch SRC_URI to use svn
On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg b...@enea.com wrote: Khem Raj wrote: I agree but then 1.7 GB is noticeably huge too and it will only become larger in future so I don't think fetching from git will be a good solution for gcc ever. Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. I did not check if the fetcher has this support but it would be a nice solution. Shallow clones won't be able to support SRCREV properly, as you can only clone shallowly from HEAD, not from an arbitrary point in history, AFAIK. Right, shallow clones are a can of worms from a variety of angles. My current thinking is a ;allowsinglerev=1 parameter to the git fetcher which: a) Generates tarballs of single git revisions if tarball generation is turned on b) Searches for single revision tarballs before trying the main checkout approach. This would mean that WORKDIR may or may not have a .git directory for any SRC_URI marked with this. I think we should all be able to live with that and it shouldn't break too much? We'll end with multiple tarballs, aren't we? Yes. I'm not seeing that as a big problem for most of the usecases where we'd use this feature. You could skip shipping the big tarball of the whole repo at distribution time. 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 1/4] gcc: Switch SRC_URI to use svn
On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg b...@enea.com wrote: Khem Raj wrote: I agree but then 1.7 GB is noticeably huge too and it will only become larger in future so I don't think fetching from git will be a good solution for gcc ever. Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. I did not check if the fetcher has this support but it would be a nice solution. Shallow clones won't be able to support SRCREV properly, as you can only clone shallowly from HEAD, not from an arbitrary point in history, AFAIK. Right, shallow clones are a can of worms from a variety of angles. My current thinking is a ;allowsinglerev=1 parameter to the git fetcher which: a) Generates tarballs of single git revisions if tarball generation is turned on b) Searches for single revision tarballs before trying the main checkout approach. This would mean that WORKDIR may or may not have a .git directory for any SRC_URI marked with this. I think we should all be able to live with that and it shouldn't break too much? We'll end with multiple tarballs, aren't we? Yes. I'm not seeing that as a big problem for most of the usecases where we'd use this feature. You could skip shipping the big tarball of the whole repo at distribution time. By the way, there're any tool to clean the repo? (as we do for sstate-cache)? -- 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] Nothing provides libxcb-*
On 14/09/12 14:22, Richard Purdie wrote:
On Fri, 2012-09-14 at 13:36 +0100, Jack Mitchell wrote:
On 14/09/12 13:32, Jack Mitchell wrote:
On 14/09/12 13:16, Richard Purdie wrote:
On Fri, 2012-09-14 at 13:09 +0100, Jack Mitchell wrote:
I am trying to use the package libxcb-xfixes in a recipe however when I
add 'libxcb-xfixes' to DEPENDS I get the error that nothing provides
libxcb-xfixes however the libxcb package clearly has it in the PACKAGES
variable
recipes-graphics/xcb/libxcb.inc:PACKAGES =+ libxcb-composite
libxcb-damage libxcb-dpms libxcb-glx \
recipes-graphics/xcb/libxcb.inc: libxcb-randr libxcb-record
libxcb-render libxcb-res \
recipes-graphics/xcb/libxcb.inc: libxcb-screensaver libxcb-shape
libxcb-shm libxcb-sync \
recipes-graphics/xcb/libxcb.inc: libxcb-xevie libxcb-xf86dri
libxcb-xfixes libxcb-xlib \
recipes-graphics/xcb/libxcb.inc: libxcb-xprint libxcb-xtest libxcb-xv
libxcb-xvmc \
recipes-graphics/xcb/libxcb.inc: libxcb-dri2
I have also tried using others in this package list to no avail, can
anybody comment on how I should be using these packages?
You're mixing up the build time and runtime namespaces. You would add
DEPENDS = libxcb or RDEPENDS_${PN}-xxx = libxcb-xfixes.
DEPENDS is build time and you use PN
RDEPENDS/RRECOMMENDS/R* is runtime and values from PACKAGES
Cheers,
Richard
Ok, thanks! I guess I have a bigger problem then, the error I am
recieving is:
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| ERROR: Xfixes not found
|
| If you think configure made a mistake, make sure you are using the
latest
| version from Git. If the latest version fails, report the problem
to the
| libav-u...@libav.org mailing list or IRC #libav on irc.freenode.net.
| Include the log file config.log produced by configure as this will
help
| solving the problem.
Now, I have libxcb in DEPENDS and I have the following configure options:
EXTRA_OECONF = \
--cross-prefix=${TARGET_PREFIX} \
--enable-cross-compile \
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
--target-os=linux \
--extra-cflags=${TARGET_CFLAGS}
${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} \
--extra-ldflags=${TARGET_LDFLAGS} \
--arch=${TARGET_ARCH} \
--enable-hardcoded-tables \
--enable-shared \
--enable-pthreads \
--enable-gpl \
--enable-avfilter \
--prefix=${prefix} \
--enable-x11grab \
--enable-libtheora \
--enable-libvorbis \
${EXTRA_FFCONF} \
Is there anything glaringly wrong?I am worried about these two:
--sysroot=${STAGING_DIR_TARGET} \
--sysinclude=${STAGING_DIR_TARGET}${includedir} \
Cheers,
Possibly of use?
check_lib X11/extensions/Xfixes.h XFixesGetCursorImage -lXfixes
check_header X11/extensions/Xfixes.h
check_cpp
BEGIN /tmp/ffconf.RboCj6pF.c
1 #include X11/extensions/Xfixes.h
2 int x;
END /tmp/ffconf.RboCj6pF.c
arm-poky-linux-gnueabi-gcc
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -O2 -pipe -g
-feliminate-unused-debug-types -O2 -pipe -g
-feliminate-unused-debug-types -march=armv6 -mthumb-interwork
-mfloat-abi=softfp -mtune=arm1176jzf-s
--sysroot=/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi
-std=c99 -fomit-frame-pointer -marm -pthread -E -o
/tmp/ffconf.IQTkUVuf.o /tmp/ffconf.RboCj6pF.c
/tmp/ffconf.RboCj6pF.c:1:35: fatal error: X11/extensions/Xfixes.h: No
such file or directory
compilation terminated.
ERROR: Xfixes not found
Sorry, I misunderstood this, ignore my last reply. That header comes
from libxfixes so you probably need a DEPENDS on that too.
Cheers,
Richard
Sigh That is indeed what I was looking for.
Cheers all!
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] patch.bbclass: Use one TMPDIR per patching process
On Fri, 2012-09-14 at 14:24 +0200, Enrico Scholz wrote:
Richard Purdie richard.pur...@linuxfoundation.org writes:
+process_tmpdir = os.path.join('/tmp', str(os.getpid()))
+shutil.rmtree(process_tmpdir)
Its only being used as a prefix, not as the full directory path name
so it isn't quite as insecure as it would first appear.
It *is* insecure as it would first appear. 'shutil.rmtree()' does not
traverse the directory in a secure way so that an attacker could:
1. touch /tmp/2-32767/a
2. mkdir /tmp/2-32767/Z
3. wait for an inotify which triggers on deletion of the 'a' files
4. rmdir /tmp/$dir/Z
5. ln -s /home/user /tmp/$dir/Z
When steps 4+5 are executed between
| $ strace python -c 'import shutil; shutil.rmtree(/tmp/2);'
| ...
| lstat(/tmp/2/Z, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
| steps 4+5 here
| openat(AT_FDCWD, /tmp/2/Z, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
| getdents(3, /* 3 entries */, 32768) = 72
| ...
| unlink(/tmp/2/Z/foo) = 0
user writable directories will be removed.
There have been established some rules regarding secure tmpfile/dir
generation in the last 10-20 years which should never be violated.
Beside the obvious security issues, build will be aborted when somebody
else creates a /tmp/number file and number matches the bitbake pid.
Firstly, I agree that we need to fix this and I know Constantin is
working on a patch.
I would point out that the build process is likely full of such races
though. We execute an absolute *ton* of code, much of which is part of
upstream projects and which we don't directly control (think of all the
configure scripts and makefiles). I'd therefore suggest that builds be
considered insecure in themselves and run in environments appropriate to
that.
So build time security, I make *no* claims to and I find it hard to get
worked up about this lest it create some illusion builds are secure.
Runtime security of the build output, very different question,
naturally.
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 1/2] gst-ffmpeg: add LICENSE_FLAGS
On Fri, 2012-09-14 at 10:23 +0100, Burton, Ross wrote: On 14 September 2012 07:28, Saul Wold s...@linux.intel.com wrote: ERROR: Nothing RPROVIDES 'gst-ffmpeg' (but /srv/home/pokybuild/yocto-autobuilder/yocto-slave/meta-intel-gpl/build/yocto/meta-intel/common/recipes-multimedia/gstreamer/gst-va-intel.bb RDEPENDS on or otherwise requires it) That's interesting, I wasn't aware gst-va required ffmpeg. At the most it should be a recommends as elements are pluggable, and to be honest I'm pretty sure that's a bad dependency. So some of the meta-intel BSPs add this as RRECOMMENDS to get video acceleration support under gstreamer: MACHINE_EXTRA_RRECOMMENDS += gst-va-intel and that adds a runtime dependency on gst-ffmpeg, which in turn uses a local ffmpeg that does this to enable video video acceleration: --enable-vaapi \ but also does this to avoid being 'commercial': --enable-gpl \ So unless there's something that requires gst-ffmpeg to be commercial, I don't think gst-ffmpeg actually needs commercial LICENSE_FLAGS. What was the reason it was added now after all this time in the first place? Tom Ross ___ 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] patch.bbclass: Use one TMPDIR per patching process
Richard Purdie richard.pur...@linuxfoundation.org writes: I would point out that the build process is likely full of such races though. Yes; I know. But there is really no excuse to introduce insecure tmpfile creation; especially because safe techniques are well known, available and cheap. All the build tools (gcc, make, autoconf) got patches in the last years to avoid such races. Enrico ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] patch.bbclass: increase security
- Use mkdtemp for generating temp dir names
- Use bb.utils.remove for removing temp dirs
- Add comment for explaining the patch workaround
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/classes/patch.bbclass | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index d010438..4b535d9 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -139,10 +139,14 @@ python patch_do_patch() {
path = os.getenv('PATH')
os.putenv('PATH', d.getVar('PATH', True))
-import shutil
-process_tmpdir = os.path.join('/tmp', str(os.getpid()))
+# We must use one TMPDIR per process (/tmp/${PID}${random_chars})
+# so that the patch processes don't generate the same temp
+# file name.
+
+import tempfile
+process_tmpdir = tempfile.mkdtemp(prefix=str(os.getpid()))
if os.path.exists(process_tmpdir):
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
os.makedirs(process_tmpdir)
os.environ['TMPDIR'] = process_tmpdir
@@ -168,15 +172,15 @@ python patch_do_patch() {
try:
patchset.Import({file:local, strippath: parm['striplevel']},
True)
except Exception as exc:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(exc))
try:
resolver.Resolve()
except bb.BBHandledException as e:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(e))
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
}
patch_do_patch[vardepsexclude] = PATCHRESOLVE
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] patch.bbclass: increase security
Constantin Musca constantinx.musca-ral2jqcrhueavxtiumw...@public.gmane.org writes: +process_tmpdir = tempfile.mkdtemp(prefix=str(os.getpid())) fwiw, prefix is usually something which identifies the origin of the tempfile. getpid() does not make much sense here; it might be better to use something like 'bitbake-patch' or so. if os.path.exists(process_tmpdir): this will trigger everytime becuase 'mkdtemp()' creates the directory. +bb.utils.remove(process_tmpdir, True) this lowers the just gained security... :( os.makedirs(process_tmpdir) not needed --- a plain | process_tmpdir = tempfile.mkdtemp() | os.environ['TMPDIR'] = process_tmpdir suffices (add a custom prefix when you really want it). Enrico -- SIGMA Chemnitz GmbH Registergericht: Amtsgericht Chemnitz HRB 1750 Am Erlenwald 13 Geschaeftsfuehrer: Grit Freitag, Frank Pyritz 09128 Chemnitz ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] patch.bbclass: increase security
- Use mkdtemp for generating temp dir names
- Use bb.utils.remove for removing temp dirs
- Add comment for explaining the patch workaround
[YOCTO #3070]
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/classes/patch.bbclass | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index d010438..9601260 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -139,11 +139,12 @@ python patch_do_patch() {
path = os.getenv('PATH')
os.putenv('PATH', d.getVar('PATH', True))
-import shutil
-process_tmpdir = os.path.join('/tmp', str(os.getpid()))
-if os.path.exists(process_tmpdir):
-shutil.rmtree(process_tmpdir)
-os.makedirs(process_tmpdir)
+# We must use one TMPDIR per process (/tmp/${PID}${random_chars})
+# so that the patch processes don't generate the same temp
+# file name.
+
+import tempfile
+process_tmpdir = tempfile.mkdtemp(prefix=bitbake_patch)
os.environ['TMPDIR'] = process_tmpdir
for patch in src_patches(d):
@@ -168,15 +169,15 @@ python patch_do_patch() {
try:
patchset.Import({file:local, strippath: parm['striplevel']},
True)
except Exception as exc:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(exc))
try:
resolver.Resolve()
except bb.BBHandledException as e:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(e))
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
}
patch_do_patch[vardepsexclude] = PATCHRESOLVE
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] patch.bbclass: increase security
On 09/14/2012 05:18 PM, Enrico Scholz wrote: Constantin Musca constantinx.musca-ral2jqcrhueavxtiumw...@public.gmane.org writes: +process_tmpdir = tempfile.mkdtemp(prefix=str(os.getpid())) fwiw, prefix is usually something which identifies the origin of the tempfile. getpid() does not make much sense here; it might be better to use something like 'bitbake-patch' or so. if os.path.exists(process_tmpdir): this will trigger everytime becuase 'mkdtemp()' creates the directory. +bb.utils.remove(process_tmpdir, True) this lowers the just gained security... :( os.makedirs(process_tmpdir) not needed --- a plain | process_tmpdir = tempfile.mkdtemp() | os.environ['TMPDIR'] = process_tmpdir suffices (add a custom prefix when you really want it). Enrico Is it ok now ? ([PATCH v2] patch.bbclass: increase security) Constantin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] patch.bbclass: increase security
- Use mkdtemp for generating temp dir names
- Use bb.utils.remove for removing temp dirs
- Add comment for explaining the patch workaround
[YOCTO #3070]
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/classes/patch.bbclass | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index d010438..a66a0a7 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -139,11 +139,11 @@ python patch_do_patch() {
path = os.getenv('PATH')
os.putenv('PATH', d.getVar('PATH', True))
-import shutil
-process_tmpdir = os.path.join('/tmp', str(os.getpid()))
-if os.path.exists(process_tmpdir):
-shutil.rmtree(process_tmpdir)
-os.makedirs(process_tmpdir)
+# We must use one TMPDIR per process so that the patch processes
+# don't generate the same temp file name.
+
+import tempfile
+process_tmpdir = tempfile.mkdtemp()
os.environ['TMPDIR'] = process_tmpdir
for patch in src_patches(d):
@@ -168,15 +168,15 @@ python patch_do_patch() {
try:
patchset.Import({file:local, strippath: parm['striplevel']},
True)
except Exception as exc:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(exc))
try:
resolver.Resolve()
except bb.BBHandledException as e:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(e))
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
}
patch_do_patch[vardepsexclude] = PATCHRESOLVE
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] patch.bbclass: increase security
- Use mkdtemp for generating temp dir names
- Use bb.utils.remove for removing temp dirs
- Add comment for explaining the patch workaround
[YOCTO #3070]
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/classes/patch.bbclass | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index d010438..ed12802 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -139,11 +139,11 @@ python patch_do_patch() {
path = os.getenv('PATH')
os.putenv('PATH', d.getVar('PATH', True))
-import shutil
-process_tmpdir = os.path.join('/tmp', str(os.getpid()))
-if os.path.exists(process_tmpdir):
-shutil.rmtree(process_tmpdir)
-os.makedirs(process_tmpdir)
+# We must use one TMPDIR per process so that the patch processes
+# don't generate the same temp file name.
+
+import tempfile
+process_tmpdir = tempfile.mkdtemp()
os.environ['TMPDIR'] = process_tmpdir
for patch in src_patches(d):
@@ -168,15 +168,15 @@ python patch_do_patch() {
try:
patchset.Import({file:local, strippath: parm['striplevel']},
True)
except Exception as exc:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(exc))
try:
resolver.Resolve()
except bb.BBHandledException as e:
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
bb.fatal(str(e))
-shutil.rmtree(process_tmpdir)
+bb.utils.remove(process_tmpdir, True)
}
patch_do_patch[vardepsexclude] = PATCHRESOLVE
--
1.7.9.5
___
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] Update to taglib v1.8
On 09/13/2012 03:22 PM, Andrei Gherzan wrote:
The following changes since commit 7401ed019196313a7ae7cab0b9f3820356cfee29:
Update to upstream_tracking.inc (2012-09-12 17:56:58 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib ag/taglib
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/taglib
Andrei Gherzan (1):
taglib: Update to v1.8
.../taglib/taglib-1.6.3/configuretweak.patch | 73 -
.../taglib/taglib-1.6.3/nolibtool.patch| 5916
.../taglib/{taglib_1.6.3.bb = taglib_1.8.bb} | 17 +-
3 files changed, 8 insertions(+), 5998 deletions(-)
delete mode 100644
meta/recipes-support/taglib/taglib-1.6.3/configuretweak.patch
delete mode 100644 meta/recipes-support/taglib/taglib-1.6.3/nolibtool.patch
rename meta/recipes-support/taglib/{taglib_1.6.3.bb = taglib_1.8.bb} (56%)
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman: remove trailing whitespace
On 09/11/2012 02:57 AM, Ross Burton wrote: Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-connectivity/connman/connman.inc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/connman/connman.inc b/meta/recipes-connectivity/connman/connman.inc index 59ec1fa..5b94a1e 100644 --- a/meta/recipes-connectivity/connman/connman.inc +++ b/meta/recipes-connectivity/connman/connman.inc @@ -1,5 +1,5 @@ SUMMARY = A daemon for managing internet connections within embedded devices -DESCRIPTION = The ConnMan project provides a daemon for managing \ +DESCRIPTION = The ConnMan project provides a daemon for managing \ internet connections within embedded devices running the Linux \ operating system. The Connection Manager is designed to be slim and \ to use as few resources as possible, so it can be easily integrated. \ Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 3/3] uclibc: Revert systemd regressing patch from upsteam uclibc and uprev SRCREV
On 09/12/2012 12:55 AM, Khem Raj wrote:
This patch is causing systemd based systemd to not boot
Revert of patch has been tested on tip of master hence the new SRCREV
New SRCREV brings in one another regression fix as described here
http://lists.uclibc.org/pipermail/uclibc/2012-August/046993.html
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-core/uclibc/uclibc-git.inc|5 +-
...nt.c-wtent.c-move-functions-from-utxent.c.patch | 321
2 files changed, 324 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
Merged into OE-Core
Thanks
Sau!
diff --git a/meta/recipes-core/uclibc/uclibc-git.inc
b/meta/recipes-core/uclibc/uclibc-git.inc
index eec4ded..4da9c58 100644
--- a/meta/recipes-core/uclibc/uclibc-git.inc
+++ b/meta/recipes-core/uclibc/uclibc-git.inc
@@ -1,9 +1,9 @@
-SRCREV=555ae2e88cd16a83f854634b6c3f35715b11d3d4
+SRCREV=cb43f2afba0633400387fa7c55dda3396517f58a
DEFAULT_PREFERENCE = -1
PV = 0.9.33+git${SRCPV}
-PR = ${INC_PR}.3
+PR = ${INC_PR}.4
FILESPATH = ${@base_set_filespath([ '${FILE_DIRNAME}/uclibc-git' ], d)}
@@ -26,5 +26,6 @@ SRC_URI =
git://uclibc.org/uClibc.git;branch=master;protocol=git \
file://0001-nptl-atfork-Hide-pthread_atfork-in-shared-versions.patch \
file://0001-librt-Use-nodefaultlibs-instead-of-nostdlib.patch \
file://mount.h-update.patch \
+ file://0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch \
S = ${WORKDIR}/git
diff --git
a/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
b/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
new file mode 100644
index 000..8c202ac
--- /dev/null
+++
b/meta/recipes-core/uclibc/uclibc-git/0001-Revert-utent.c-wtent.c-move-functions-from-utxent.c.patch
@@ -0,0 +1,321 @@
+Upstream-Status: Pending
+
+From 096abf14d2dc978607ccd8a0d7f42da65d8991f3 Mon Sep 17 00:00:00 2001
+From: Khem Raj raj.k...@gmail.com
+Date: Sun, 9 Sep 2012 22:00:04 -0700
+Subject: [PATCH] Revert utent.c, wtent.c: move functions from utxent.c
+
+This reverts commit 84135275cfeebc0b233c1c96eeada4d4178a0b18.
+---
+ include/utmp.h |8 +
+ libc/misc/utmp/utent.c | 80 +++
+ libc/misc/utmp/utxent.c |4 +--
+ libc/misc/utmp/wtent.c | 14 ++---
+ 4 files changed, 30 insertions(+), 76 deletions(-)
+
+diff --git a/include/utmp.h b/include/utmp.h
+index cb8e08f..10b75c9 100644
+--- a/include/utmp.h
b/include/utmp.h
+@@ -57,29 +57,37 @@ extern void logwtmp (__const char *__ut_line, __const char
*__ut_name,
+ /* Append entry UTMP to the wtmp-like file WTMP_FILE. */
+ extern void updwtmp (__const char *__wtmp_file, __const struct utmp *__utmp)
+ __THROW;
++libc_hidden_proto(updwtmp)
+
+ /* Change name of the utmp file to be examined. */
+ extern int utmpname (__const char *__file) __THROW;
++libc_hidden_proto(utmpname)
+
+ /* Read next entry from a utmp-like file. */
+ extern struct utmp *getutent (void) __THROW;
++libc_hidden_proto(getutent)
+
+ /* Reset the input stream to the beginning of the file. */
+ extern void setutent (void) __THROW;
++libc_hidden_proto(setutent)
+
+ /* Close the current open file. */
+ extern void endutent (void) __THROW;
++libc_hidden_proto(endutent)
+
+ /* Search forward from the current point in the utmp file until the
+next entry with a ut_type matching ID-ut_type. */
+ extern struct utmp *getutid (__const struct utmp *__id) __THROW;
++libc_hidden_proto(getutid)
+
+ /* Search forward from the current point in the utmp file until the
+next entry with a ut_line matching LINE-ut_line. */
+ extern struct utmp *getutline (__const struct utmp *__line) __THROW;
++libc_hidden_proto(getutline)
+
+ /* Write out entry pointed to by UTMP_PTR into the utmp file. */
+ extern struct utmp *pututline (__const struct utmp *__utmp_ptr) __THROW;
++libc_hidden_proto(pututline)
+
+
+ #if 0 /* def __USE_MISC */
+diff --git a/libc/misc/utmp/utent.c b/libc/misc/utmp/utent.c
+index a35bb2b..07ca44e 100644
+--- a/libc/misc/utmp/utent.c
b/libc/misc/utmp/utent.c
+@@ -19,9 +19,6 @@
+ #include errno.h
+ #include string.h
+ #include utmp.h
+-#ifdef __UCLIBC_HAS_UTMPX__
+-# include utmpx.h
+-#endif
+ #include not-cancel.h
+
+ #include bits/uClibc_mutex.h
+@@ -34,7 +31,7 @@ static const char default_file_name[] = _PATH_UTMP;
+ static const char *static_ut_name = default_file_name;
+
+ /* This function must be called with the LOCK held */
+-static void __setutent_unlocked(void)
++static void __setutent(void)
+ {
+ if (static_fd 0) {
+ static_fd = open_not_cancel_2(static_ut_name, O_RDWR | O_CLOEXEC);
+@@ -53,24 +50,19 @@ static void __setutent_unlocked(void)
+ lseek(static_fd, 0, SEEK_SET);
+ }
+ #if defined __UCLIBC_HAS_THREADS__
+-static void
Re: [OE-core] [PATCH 2/3] runqemu: Explicitly specify MACHINE when calling bitbake
On 09/11/2012 10:59 PM, Khem Raj wrote:
When using runqemu with distros outside oe-core then
MACHINE may not be there in local.conf so use the one
thats available in environment of runqemu which is actually
the correct one.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
scripts/runqemu |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index a3c3509..e843946 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -281,7 +281,7 @@ setup_tmpdir() {
exit 1; }
# We have bitbake in PATH, get OE_TMPDIR from bitbake
-OE_TMPDIR=`bitbake -e | grep ^TMPDIR=\ | cut -d '=' -f2 | cut -d ''
-f2`
+OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\ | cut -d '=' -f2 |
cut -d '' -f2`
if [ -z $OE_TMPDIR ]; then
echo Error: this script needs to be run from your build
directory,
echo or you need to explicitly set OE_TMPDIR in your environment
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 0/1] Round up ROOTFS_SIZE after base_size check
On 09/13/2012 10:18 AM, Andrei Gherzan wrote: V3: Do the whole thing in the same awk The following changes since commit 0f55a5868457300a3defc7fa7451ef191d19e018: adt-installer: Allow changing YOCTOADT_REPO (2012-09-05 23:28:10 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib ag/rootfs_size http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ag/rootfs_size Andrei Gherzan (1): image_types.bbclass: Round up ROOTFS_SIZE after base_size check meta/classes/image_types.bbclass |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] valgrind_3.7.0.bb: fix missing leading space on _append
On 09/12/2012 02:07 PM, Matthew McClintock wrote:
Signed-off-by: Matthew McClintock m...@freescale.com
---
meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index 651ae60..3def11d 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c46082167a314d785d012a244748d803 \
X11DEPENDS = virtual/libx11
DEPENDS = ${@base_contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '',
d)}
-PR = r6
+PR = r7
SRC_URI = http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
file://fix_issue_caused_by_ccache.patch \
@@ -22,7 +22,7 @@ SRC_URI =
http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
SRC_URI_append_powerpc =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
-SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
+SRC_URI_append_powerpc64 =
file://valgrind-3.7.0-fix-error-of-reading-debug-info.patch
SRC_URI[md5sum] = a855fda56edf05614f099dca316d1775
SRC_URI[sha256sum] =
5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6
Merged into OE-Core
Thanks
Sau!
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libffi upgrade to 3.0.11
On 09/13/2012 01:26 AM, Andrei Dinu wrote:
Changes :
- Added ax_append_flags.m4 and ax_check_compile_flag.m4 to the m4 directory.
The files were missing and aclocal.m4 was generated without those two macros.
- Added a new license md5 checksum to the recipe because the old LICENSE file
differs from the new one here :
OLD : libffi - Copyright (c) 1996-2011
NEW : libffi - Copyright (c) 1996-2012
Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
---
.../libffi/0001-libffi-update-for-3.0.11.patch | 171
.../libffi/{libffi_3.0.10.bb = libffi_3.0.11.bb} |9 +-
2 files changed, 176 insertions(+), 4 deletions(-)
create mode 100644
meta/recipes-gnome/libffi/0001-libffi-update-for-3.0.11.patch
rename meta/recipes-gnome/libffi/{libffi_3.0.10.bb = libffi_3.0.11.bb} (72%)
Merged into OE-Core
Thanks
Sau!
diff --git a/meta/recipes-gnome/libffi/0001-libffi-update-for-3.0.11.patch
b/meta/recipes-gnome/libffi/0001-libffi-update-for-3.0.11.patch
new file mode 100644
index 000..9592048
--- /dev/null
+++ b/meta/recipes-gnome/libffi/0001-libffi-update-for-3.0.11.patch
@@ -0,0 +1,171 @@
+From 936ab07cec90243a6a336c5aa6205f4edbeb00d5 Mon Sep 17 00:00:00 2001
+From: Andrei Dinu andrei.adrianx.d...@intel.com
+Date: Wed, 12 Sep 2012 17:42:29 +0300
+Subject: [PATCH] libffi update for 3.0.11
+
+Upstream status : Pending
+
+Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
+---
+ m4/ax_append_flag.m4| 69 +
+ m4/ax_check_compile_flag.m4 | 72 +++
+ 2 files changed, 141 insertions(+)
+ create mode 100644 m4/ax_append_flag.m4
+ create mode 100644 m4/ax_check_compile_flag.m4
+
+diff --git a/m4/ax_append_flag.m4 b/m4/ax_append_flag.m4
+new file mode 100644
+index 000..1d38b76
+--- /dev/null
b/m4/ax_append_flag.m4
+@@ -0,0 +1,69 @@
++# ===
++# http://www.gnu.org/software/autoconf-archive/ax_append_flag.html
++# ===
++#
++# SYNOPSIS
++#
++# AX_APPEND_FLAG(FLAG, [FLAGS-VARIABLE])
++#
++# DESCRIPTION
++#
++# FLAG is appended to the FLAGS-VARIABLE shell variable, with a space
++# added in between.
++#
++# If FLAGS-VARIABLE is not specified, the current language's flags (e.g.
++# CFLAGS) is used. FLAGS-VARIABLE is not changed if it already contains
++# FLAG. If FLAGS-VARIABLE is unset in the shell, it is set to exactly
++# FLAG.
++#
++# NOTE: Implementation based on AX_CFLAGS_GCC_OPTION.
++#
++# LICENSE
++#
++# Copyright (c) 2008 Guido U. Draheim gui...@gmx.de
++# Copyright (c) 2011 Maarten Bosmans mkbosm...@gmail.com
++#
++# This program is free software: you can redistribute it and/or modify it
++# under the terms of the GNU General Public License as published by the
++# Free Software Foundation, either version 3 of the License, or (at your
++# option) any later version.
++#
++# This program is distributed in the hope that it will be useful, but
++# WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
++# Public License for more details.
++#
++# You should have received a copy of the GNU General Public License along
++# with this program. If not, see http://www.gnu.org/licenses/.
++#
++# As a special exception, the respective Autoconf Macro's copyright owner
++# gives unlimited permission to copy, distribute and modify the configure
++# scripts that are the output of Autoconf when processing the Macro. You
++# need not follow the terms of the GNU General Public License when using
++# or distributing such scripts, even though portions of the text of the
++# Macro appear in them. The GNU General Public License (GPL) does govern
++# all other use of the material that constitutes the Autoconf Macro.
++#
++# This special exception to the GPL applies to versions of the Autoconf
++# Macro released by the Autoconf Archive. When you make and distribute a
++# modified version of the Autoconf Macro, you may extend this special
++# exception to the GPL to apply to your modified version as well.
++
++#serial 2
++
++AC_DEFUN([AX_APPEND_FLAG],
++[AC_PREREQ(2.59)dnl for _AC_LANG_PREFIX
++AS_VAR_PUSHDEF([FLAGS], [m4_default($2,_AC_LANG_PREFIX[FLAGS])])dnl
++AS_VAR_SET_IF(FLAGS,
++ [case AS_VAR_GET(FLAGS) in
++* $1 *)
++ AC_RUN_LOG([: FLAGS already contains $1])
++ ;;
++*)
++ AC_RUN_LOG([: FLAGS=$FLAGS $1])
++ AS_VAR_SET(FLAGS, [AS_VAR_GET(FLAGS) $1])
++ ;;
++ esac],
++ [AS_VAR_SET(FLAGS,[$1])])
++AS_VAR_POPDEF([FLAGS])dnl
++])dnl AX_APPEND_FLAG
+diff --git a/m4/ax_check_compile_flag.m4 b/m4/ax_check_compile_flag.m4
+new file mode 100644
+index 000..c3a8d69
+--- /dev/null
b/m4/ax_check_compile_flag.m4
+@@ -0,0 +1,72 @@
++#
Re: [OE-core] [PATCH] libx11: update patch to a backport from upstream git
On 09/13/2012 03:10 AM, Ross Burton wrote: Signed-off-by: Ross Burton ross.bur...@intel.com --- .../xorg-lib/libx11/keysymdef_include.patch| 35 +--- 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch b/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch index ba65319..8c50bb7 100644 --- a/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch +++ b/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch @@ -1,7 +1,7 @@ -From 547937d82084f2cce7e3f0849b5112a20c467146 Mon Sep 17 00:00:00 2001 +From d45b3fc19fbe95c41afc4e51d768df6d42332010 Mon Sep 17 00:00:00 2001 From: Ross Burton ross.bur...@intel.com -Date: Tue, 11 Sep 2012 17:39:12 +0100 -Subject: [PATCH] Allow overriding location of keysymdef.h +Date: Wed, 12 Sep 2012 13:39:40 + +Subject: Allow overriding location of keysymdef.h Currently keysymdef.h is found by using the includedir of xproto. This doesn't work when cross-compiling with a sysroot as that ends up being /usr/include/X11, @@ -12,36 +12,31 @@ and verify that the specified or found path exists. (original patch by Martin Jansa martin.ja...@gmail.com, revised by myself) -Upstream-Status: Submitted [xorg-devel] +Upstream-Status: Backport Signed-off-by: Ross Burton ross.bur...@intel.com +Reviewed-by: Dan Nicholson dbn.li...@gmail.com +Reviewed-by: Daniel Stone dan...@fooishbar.org --- - configure.ac | 13 - - 1 file changed, 12 insertions(+), 1 deletion(-) - diff --git a/configure.ac b/configure.ac -index 48a0c8a..200db15 100644 +index 48a0c8a..a45f9d9 100644 --- a/configure.ac +++ b/configure.ac -@@ -306,7 +306,18 @@ AC_CHECK_FUNC(poll, [AC_DEFINE(USE_POLL, 1, [poll() function is available])], ) +@@ -306,7 +306,15 @@ AC_CHECK_FUNC(poll, [AC_DEFINE(USE_POLL, 1, [poll() function is available])], ) # Find keysymdef.h # AC_MSG_CHECKING([keysym definitions]) -KEYSYMDEFDIR=`$PKG_CONFIG --variable=includedir xproto`/X11 -+AC_ARG_WITH(keysymdefdir, -+AC_HELP_STRING([--with-keysymdefdir=DIR], [The location of keysymdef.h (defaults to xproto include dir)]), -+KEYSYMDEFDIR=$withval, KEYSYMDEFDIR=) -+ -+if test x$KEYSYMDEFDIR = x; then -+ KEYSYMDEFDIR=`$PKG_CONFIG --variable=includedir xproto`/X11 -+fi ++AC_ARG_WITH([keysymdefdir], ++[AC_HELP_STRING([--with-keysymdefdir=DIR], [The location of keysymdef.h (defaults to xproto include dir)])], ++[KEYSYMDEFDIR=$withval], ++[KEYSYMDEFDIR=`$PKG_CONFIG --variable=includedir xproto`/X11]) + -+if test ! -d $KEYSYMDEFDIR; then ++if test ! -d $KEYSYMDEFDIR; then + AC_MSG_ERROR([$KEYSYMDEFDIR doesn't exist or isn't a directory]) +fi + FILES=keysymdef.h XF86keysym.h Sunkeysym.h DECkeysym.h HPkeysym.h for i in $FILES; do if test -f $KEYSYMDEFDIR/$i; then --- -1.7.10.4 - +-- +cgit v0.9.0.2-2-gbebe Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Couple of fixes for combo-layer
On 09/13/2012 09:23 AM, Paul Eggleton wrote: The following changes since commit 835654994574c158d6324218ebe000bd2ef9a792: rt: Add hwlatdetect to rt images (2012-09-12 15:11:12 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/combo-layer-fixes8 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/combo-layer-fixes8 Paul Eggleton (2): scripts/combo-layer: use last_revision if specified in init scripts/combo-layer: ensure we validate branch/revision on init scripts/combo-layer | 31 --- 1 file changed, 20 insertions(+), 11 deletions(-) Merged into OE-Core Thanks Sau! ___ 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] pseudo update to 1.4.1
On 09/13/2012 11:29 AM, Peter Seebach wrote: The patches here are trivial. The upstream fixes are pretty non-trivial, but have been used moderately extensively on a handful of hosts, and appear to work. Long story short, pseudo could cause rm to fail on files 2GB on 32-bit hosts which didn't use a 64-bit off_t. Fixing this required addressing a surprising number of assumptions, but it appears to work now. The following changes since commit 835654994574c158d6324218ebe000bd2ef9a792: Darren Hart (1): rt: Add hwlatdetect to rt images are available in the git repository at: git://git.yoctoproject.org/poky-contrib seebs/pseudo141 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/pseudo141 Peter Seebach (1): pseudo_1.4.1.bb: update to pseudo 1.4.1, fixing 32-bit host problems meta/recipes-devtools/pseudo/pseudo_1.4.1.bb |8 meta/recipes-devtools/pseudo/pseudo_1.4.bb |8 meta/recipes-devtools/pseudo/pseudo_git.bb |6 +++--- 3 files changed, 11 insertions(+), 11 deletions(-) create mode 100644 meta/recipes-devtools/pseudo/pseudo_1.4.1.bb delete mode 100644 meta/recipes-devtools/pseudo/pseudo_1.4.bb Merged into OE-Core Thanks Sau! ___ 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/2] linux-yocto: consolidated update
On 09/13/2012 12:34 PM, Bruce Ashfield wrote: Richard/Saul, A small ``consolidated'' update this time. Two fixes, one to the build/tools, one meta branch update for KVM guests. The tools fix is something that I've been wanting to get to for a month now .. and I finally did. Matthew Foster reported the strange messages when working with linux-yocto-custom. It is now fixed, and no more nasty looking messages. The details of the messages and fix are in the patch. The second meta/config patch is to embed some fragments for use by a KVM guest. These will be used by other updates to the tools/scripts to follow. Cheers, Bruce The following changes since commit 7401ed019196313a7ae7cab0b9f3820356cfee29: Update to upstream_tracking.inc (2012-09-12 17:56:58 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (2): kernel-yocto: fix kernel configuration audit for custom yocto kernels linux-yocto: virtio and KVM guest configuration meta/classes/kernel-yocto.bbclass |7 ++- .../kern-tools/kern-tools-native_git.bb|2 +- meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb|2 +- meta/recipes-kernel/linux/linux-yocto_3.4.bb |2 +- 4 files changed, 9 insertions(+), 4 deletions(-) Merged into OE-Core Thanks Sau! ___ 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] Binutils fixes
On 09/13/2012 02:58 PM, Khem Raj wrote: This patch is backporting strictly the patches that has gone into 2.22 release branch since 2.22 was released last year. I have dropped the patches for AVR,CRIS and HPPA which does not concern OE-Core's primary architecture. Majority fixes are for ld and mips and ppc architecture Binutils testruns are better after these bugfixes and also all architectures booted console-image successfully The following changes since commit 835654994574c158d6324218ebe000bd2ef9a792: rt: Add hwlatdetect to rt images (2012-09-12 15:11:12 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib kraj/binutils-backports http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/binutils-backports Khem Raj (1): binutils-2.22: Backport PR fixes from 2.22 branch meta/recipes-devtools/binutils/binutils-2.22.inc | 16 +- ...print_insn_micromips-Rename-local-variabl.patch | 634 +++ .../binutils/binutils/0019-PR-ld-13468.patch | 46 + .../binutils/0028-Backport-from-mainline.patch | 139 ++ ...19-Chung-Lin-Tang-cltang-codesourcery.com.patch | 47 + ...19-Chung-Lin-Tang-cltang-codesourcery.com.patch | 214 +++ ...19-Chung-Lin-Tang-cltang-codesourcery.com.patch | 1068 +++ ...opy-from-mainline-to-binutils-2.22-branch.patch | 1944 ...elf32bmip.sh-OTHER_SECTIONS-Put-.mdebug.-.patch | 49 + .../binutils/binutils/0052-gas.patch | 83 + ...55-Remove-ABI_64_P-check-on-R_X86_64_PCXX.patch | 176 ++ .../binutils/binutils/0078-PR-binutils-13622.patch | 48 + .../binutils/0144-timer.cc-include-unistd.h.patch | 32 + ...-2012-04-27-Doug-Kwan-dougkwan-google.com.patch | 169 ++ .../binutils/binutils/0182-PR-ld-13991.patch | 1617 15 files changed, 6281 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/binutils/binutils/0006-mips-dis.c-print_insn_micromips-Rename-local-variabl.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0019-PR-ld-13468.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0028-Backport-from-mainline.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0035-2011-12-19-Chung-Lin-Tang-cltang-codesourcery.com.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0036-2011-12-19-Chung-Lin-Tang-cltang-codesourcery.com.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0037-2011-12-19-Chung-Lin-Tang-cltang-codesourcery.com.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0038-Copy-from-mainline-to-binutils-2.22-branch.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0039-emulparams-elf32bmip.sh-OTHER_SECTIONS-Put-.mdebug.-.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0052-gas.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0055-Remove-ABI_64_P-check-on-R_X86_64_PCXX.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0078-PR-binutils-13622.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0144-timer.cc-include-unistd.h.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0166-2012-04-27-Doug-Kwan-dougkwan-google.com.patch create mode 100644 meta/recipes-devtools/binutils/binutils/0182-PR-ld-13991.patch Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] librsvg: --disable-gnome-vfs doesn't exist anymore, remove
On 09/13/2012 03:04 AM, Ross Burton wrote: Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-gnome/librsvg/librsvg_2.32.1.bb |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb index 6eba686..364f6f2 100644 --- a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb +++ b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb @@ -11,11 +11,11 @@ DEPENDS = gtk+ libcroco cairo libxml2 popt DEPENDS_virtclass-native = cairo-native pango-native gdk-pixbuf-native BBCLASSEXTEND = native -PR = r7 +PR = r8 inherit autotools pkgconfig gnome gtk-doc -EXTRA_OECONF = --disable-mozilla-plugin --without-svgz --without-croco --disable-gnome-vfs +EXTRA_OECONF = --disable-mozilla-plugin --without-svgz --without-croco SRC_URI += file://doc_Makefile.patch Merged 2 of the 3 into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] license: Ensure we find multilib packages also
On Thu, 2012-09-13 at 15:43 -0700, Saul Wold wrote:
On 09/13/2012 03:31 PM, Paul Eggleton wrote:
On Thursday 13 September 2012 12:26:19 Saul Wold wrote:
Make sure to find -package, this was causing a failure
in the multi-lib build license generation during rootfs.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/license.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 29fe938..b29067c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -88,7 +88,7 @@ license_create_manifest() {
# list of installed packages is broken for deb
for pkg in ${INSTALLED_PKGS}; do
# not the best way to do this but licenses are not arch
dependant iirc
- filename=`ls ${TMPDIR}/pkgdata/*/runtime-reverse/${pkg}| head
-1`
+ filename=`ls ${TMPDIR}/pkgdata/*/runtime-reverse/*${pkg}| head
-1`
pkged_pn=$(sed -n 's/^PN: //p' ${filename})
# exclude locale recipes
Surely this could end up matching a the wrong file when one package name is
a
substring of another?
I am open to ideas here, I tried the ${MLPREFIX}, but it seems to be
empty when rootfs runs, that did not help, I thought about adding the
'-', but that would fail in the non-multilib case, how can I determine
what the prefix will be to get a more accurate match?
I would observe here that this probably works for ipk and multilib and
only breaks for multilib+rpm. The reason is that rpm collapses the
namespace when it creates the package list so lib32-bash becomes bash.
I think this might be an error in however we generate the INSTALLED_PKGS
list and we might need to revisit the rpm mechanism and ensure the
multilib prefixes get added.
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] patch.bbclass: Use one TMPDIR per patching process
On 09/12/2012 04:58 AM, Constantin Musca wrote:
We must use one TMPDIR per process (/tmp/${PID}) so that the patching
processes don't generate the same temp file name (the patch program
uses the TMPDIR environment variable for deciding where to create the
temp files).
[YOCTO #3070]
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/classes/patch.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index a724972..d010438 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -139,6 +139,13 @@ python patch_do_patch() {
path = os.getenv('PATH')
os.putenv('PATH', d.getVar('PATH', True))
+import shutil
+process_tmpdir = os.path.join('/tmp', str(os.getpid()))
+if os.path.exists(process_tmpdir):
+shutil.rmtree(process_tmpdir)
+os.makedirs(process_tmpdir)
+os.environ['TMPDIR'] = process_tmpdir
+
for patch in src_patches(d):
_, _, local, _, _, parm = bb.decodeurl(patch)
On 09/12/2012 04:58 AM, Constantin Musca wrote: We must use one TMPDIR per
process (/tmp/${PID}) so that the patching
processes don't generate the same temp file name (the patch program
uses the TMPDIR environment variable for deciding where to create the
temp files).
[YOCTO #3070]
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/classes/patch.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
index a724972..d010438 100644
--- a/meta/classes/patch.bbclass
+++ b/meta/classes/patch.bbclass
@@ -139,6 +139,13 @@ python patch_do_patch() {
path = os.getenv('PATH')
os.putenv('PATH', d.getVar('PATH', True))
+import shutil
+process_tmpdir = os.path.join('/tmp', str(os.getpid()))
+if os.path.exists(process_tmpdir):
+shutil.rmtree(process_tmpdir)
+os.makedirs(process_tmpdir)
+os.environ['TMPDIR'] = process_tmpdir
+
for patch in src_patches(d):
_, _, local, _, _, parm = bb.decodeurl(patch)
@@ -161,11 +168,15 @@ python patch_do_patch() {
try:
patchset.Import({file:local, strippath: parm['striplevel']},
True)
except Exception as exc:
+shutil.rmtree(process_tmpdir)
bb.fatal(str(exc))
try:
resolver.Resolve()
except bb.BBHandledException as e:
+shutil.rmtree(process_tmpdir)
bb.fatal(str(e))
+
+shutil.rmtree(process_tmpdir)
}
patch_do_patch[vardepsexclude] = PATCHRESOLVE
This initial version was merged into OE-Core
Thanks
Sau!
@@ -161,11 +168,15 @@ python patch_do_patch() {
try:
patchset.Import({file:local, strippath: parm['striplevel']},
True)
except Exception as exc:
+shutil.rmtree(process_tmpdir)
bb.fatal(str(exc))
try:
resolver.Resolve()
except bb.BBHandledException as e:
+shutil.rmtree(process_tmpdir)
bb.fatal(str(e))
+
+shutil.rmtree(process_tmpdir)
}
patch_do_patch[vardepsexclude] = PATCHRESOLVE
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] license: Ensure we find multilib packages also
On 9/14/12 11:01 AM, Richard Purdie wrote:
On Thu, 2012-09-13 at 15:43 -0700, Saul Wold wrote:
On 09/13/2012 03:31 PM, Paul Eggleton wrote:
On Thursday 13 September 2012 12:26:19 Saul Wold wrote:
Make sure to find -package, this was causing a failure
in the multi-lib build license generation during rootfs.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/license.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 29fe938..b29067c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -88,7 +88,7 @@ license_create_manifest() {
# list of installed packages is broken for deb
for pkg in ${INSTALLED_PKGS}; do
# not the best way to do this but licenses are not arch
dependant iirc
- filename=`ls ${TMPDIR}/pkgdata/*/runtime-reverse/${pkg}| head
-1`
+ filename=`ls ${TMPDIR}/pkgdata/*/runtime-reverse/*${pkg}| head
-1`
pkged_pn=$(sed -n 's/^PN: //p' ${filename})
# exclude locale recipes
Surely this could end up matching a the wrong file when one package name is a
substring of another?
I am open to ideas here, I tried the ${MLPREFIX}, but it seems to be
empty when rootfs runs, that did not help, I thought about adding the
'-', but that would fail in the non-multilib case, how can I determine
what the prefix will be to get a more accurate match?
I would observe here that this probably works for ipk and multilib and
only breaks for multilib+rpm. The reason is that rpm collapses the
namespace when it creates the package list so lib32-bash becomes bash.
I think this might be an error in however we generate the INSTALLED_PKGS
list and we might need to revisit the rpm mechanism and ensure the
multilib prefixes get added.
RPM has internal mechanisms to tag both the filetypes and architectures as being
different, unlike most of the other packaging formats which assume a package
with the same name is the same.
The way to deal with this is via the mapping actions. You should be able to map
from ML_PREFIX-${PN} to ${PN}.${ARCH} and of course the reverse...
How it works
So during package generation we know the package arch is unique and just strip
off the mlprefix. To do the reverse iterate over all of the available
MULTILIBS, there is code in rootfs_rpm.bbclass already to do this. Then
reconstruct the package name based on the multilib configuration.
--Mark
Cheers,
Richard
___
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] xserver-xorg: remove broken RREPLACES
Unfortunately with rpm at least, this results in xserver-xorg-module-exa
being installed in preference to xserver-xorg when constructing the root
filesystem, which is clearly not desirable.
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
.../xorg-xserver/xserver-xorg-1.11.2.inc |2 +-
.../recipes-graphics/xorg-xserver/xserver-xorg.inc |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
index c71896a..35cb33a 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.2.inc
@@ -8,4 +8,4 @@ SRC_URI += file://crosscompile.patch \
SRC_URI[md5sum] = 8796fff441e5435ee36a72579008af24
SRC_URI[sha256sum] =
fa415decf02027ca278b06254ccfbcceba2a83c2741405257ebf749da4a73cf2
-PR = r7
+PR = r8
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 210abad..3ec38b7 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -66,7 +66,6 @@ PACKAGES =+ ${PN}-security-policy \
RRECOMMENDS_${PN} += ${PN}-security-policy xkeyboard-config rgb
xserver-xf86-config
RDEPENDS_${PN}-xvfb += xkeyboard-config
-RREPLACES_${PN}-module-exa = ${PN}
FILES_${PN} = ${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards
${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so
${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt
${datadir}/X11/xorg.conf.d
FILES_${PN}-dev += ${libdir}/xorg/modules/*.la ${libdir}/xorg/modules/*/*.la
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [bitbake-devel] [PATCH 1/4] gcc: Switch SRC_URI to use svn
On Fri, Sep 14, 2012 at 8:25 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote: On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote: On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg b...@enea.com wrote: Khem Raj wrote: I agree but then 1.7 GB is noticeably huge too and it will only become larger in future so I don't think fetching from git will be a good solution for gcc ever. Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB tar.gz when cloned with --depth 1. I did not check if the fetcher has this support but it would be a nice solution. Shallow clones won't be able to support SRCREV properly, as you can only clone shallowly from HEAD, not from an arbitrary point in history, AFAIK. Right, shallow clones are a can of worms from a variety of angles. My current thinking is a ;allowsinglerev=1 parameter to the git fetcher which: a) Generates tarballs of single git revisions if tarball generation is turned on b) Searches for single revision tarballs before trying the main checkout approach. This would mean that WORKDIR may or may not have a .git directory for any SRC_URI marked with this. I think we should all be able to live with that and it shouldn't break too much? We'll end with multiple tarballs, aren't we? Yes. I'm not seeing that as a big problem for most of the usecases where we'd use this feature. You could skip shipping the big tarball of the whole repo at distribution time. By the way, there're any tool to clean the repo? (as we do for sstate-cache)? scripts/clean-workdir cleans tmp/ - not sure about downloads -M -- 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 ___ bitbake-devel mailing list bitbake-de...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] license: Ensure we find multilib packages also
On Fri, Sep 14, 2012 at 9:48 AM, Mark Hatle mark.ha...@windriver.com wrote:
On 9/14/12 11:01 AM, Richard Purdie wrote:
On Thu, 2012-09-13 at 15:43 -0700, Saul Wold wrote:
On 09/13/2012 03:31 PM, Paul Eggleton wrote:
On Thursday 13 September 2012 12:26:19 Saul Wold wrote:
Make sure to find -package, this was causing a failure
in the multi-lib build license generation during rootfs.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/license.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/license.bbclass
b/meta/classes/license.bbclass
index 29fe938..b29067c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -88,7 +88,7 @@ license_create_manifest() {
# list of installed packages is broken for deb
for pkg in ${INSTALLED_PKGS}; do
# not the best way to do this but licenses are not arch
dependant iirc
- filename=`ls
${TMPDIR}/pkgdata/*/runtime-reverse/${pkg}| head -1`
+ filename=`ls
${TMPDIR}/pkgdata/*/runtime-reverse/*${pkg}| head -1`
pkged_pn=$(sed -n 's/^PN: //p' ${filename})
# exclude locale recipes
Surely this could end up matching a the wrong file when one package name
is a
substring of another?
I am open to ideas here, I tried the ${MLPREFIX}, but it seems to be
empty when rootfs runs, that did not help, I thought about adding the
'-', but that would fail in the non-multilib case, how can I determine
what the prefix will be to get a more accurate match?
I'm not particularly happy with how we've been doing manifests for a
while now and have been hacking at a revamp of it for the past 2
months on and off.
We really shouldn't be relying on package data at all for license
manifests. As the manifests are relying on list_installed_packages,
they end up inaccurate anyway as list_installed_packages does exactly
that. List software installed via package. Not installed via the
package manager? Then you aren't in the manifest. This ends up missing
quite a few things necessary from a release engineering standpoint
(like, hey, modutils? The kernel? Not listed in the manifest. IMHO
this is wrong.)
As a release engineer, I kind of don't really care if the software on
my image was installed via the packaging system. I just want a list of
what is on the images so I can audit my images to ensure GPL
commitments.
One way I've been looking at fixing this is via event handlers. I'll
have some code for RFC on this hopefully soon, but a preview (which
may or may not work it's still a WIP) is at:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=eflanagan/license_manifest
One thing the patch I've been working on does other than creates
accurate manifests is it also tries to create a semi-compliant SPDX
1.0 manifest.
I know this is late in the cycle so it might not make 1.3, but this
may be something we want to look at to end up solving this issue once
and for all.
-b
I would observe here that this probably works for ipk and multilib and
only breaks for multilib+rpm. The reason is that rpm collapses the
namespace when it creates the package list so lib32-bash becomes bash.
I think this might be an error in however we generate the INSTALLED_PKGS
list and we might need to revisit the rpm mechanism and ensure the
multilib prefixes get added.
RPM has internal mechanisms to tag both the filetypes and architectures as
being different, unlike most of the other packaging formats which assume a
package with the same name is the same.
The way to deal with this is via the mapping actions. You should be able to
map from ML_PREFIX-${PN} to ${PN}.${ARCH} and of course the reverse...
How it works
So during package generation we know the package arch is unique and just
strip off the mlprefix. To do the reverse iterate over all of the available
MULTILIBS, there is code in rootfs_rpm.bbclass already to do this. Then
reconstruct the package name based on the multilib configuration.
--Mark
Cheers,
Richard
___
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
--
Elizabeth Flanagan
Yocto Project
Build and Release
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: remove broken RREPLACES
On Fri, 2012-09-14 at 18:29 +0100, Paul Eggleton wrote: Unfortunately with rpm at least, this results in xserver-xorg-module-exa being installed in preference to xserver-xorg when constructing the root filesystem, which is clearly not desirable. Surely this is a bug in the rpm packaging backend and ought to be fixed there. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: remove broken RREPLACES
On 9/14/12 4:50 PM, Phil Blundell wrote: On Fri, 2012-09-14 at 18:29 +0100, Paul Eggleton wrote: Unfortunately with rpm at least, this results in xserver-xorg-module-exa being installed in preference to xserver-xorg when constructing the root filesystem, which is clearly not desirable. Surely this is a bug in the rpm packaging backend and ought to be fixed there. If a package replaces another, it has priority. What is the desired behavior in this case? If a package can't be installed at the same time as another package, then it conflicts. p. ___ 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] [RFC PATCH] license: Ensure we find multilib packages also
On Fri, 2012-09-14 at 13:50 -0700, Flanagan, Elizabeth wrote:
On Fri, Sep 14, 2012 at 9:48 AM, Mark Hatle mark.ha...@windriver.com wrote:
On 9/14/12 11:01 AM, Richard Purdie wrote:
On Thu, 2012-09-13 at 15:43 -0700, Saul Wold wrote:
On 09/13/2012 03:31 PM, Paul Eggleton wrote:
On Thursday 13 September 2012 12:26:19 Saul Wold wrote:
Make sure to find -package, this was causing a failure
in the multi-lib build license generation during rootfs.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/license.bbclass |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/classes/license.bbclass
b/meta/classes/license.bbclass
index 29fe938..b29067c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -88,7 +88,7 @@ license_create_manifest() {
# list of installed packages is broken for deb
for pkg in ${INSTALLED_PKGS}; do
# not the best way to do this but licenses are not arch
dependant iirc
- filename=`ls
${TMPDIR}/pkgdata/*/runtime-reverse/${pkg}| head -1`
+ filename=`ls
${TMPDIR}/pkgdata/*/runtime-reverse/*${pkg}| head -1`
pkged_pn=$(sed -n 's/^PN: //p' ${filename})
# exclude locale recipes
Surely this could end up matching a the wrong file when one package name
is a
substring of another?
I am open to ideas here, I tried the ${MLPREFIX}, but it seems to be
empty when rootfs runs, that did not help, I thought about adding the
'-', but that would fail in the non-multilib case, how can I determine
what the prefix will be to get a more accurate match?
I'm not particularly happy with how we've been doing manifests for a
while now and have been hacking at a revamp of it for the past 2
months on and off.
We really shouldn't be relying on package data at all for license
manifests. As the manifests are relying on list_installed_packages,
they end up inaccurate anyway as list_installed_packages does exactly
that. List software installed via package. Not installed via the
package manager? Then you aren't in the manifest. This ends up missing
quite a few things necessary from a release engineering standpoint
(like, hey, modutils? The kernel? Not listed in the manifest. IMHO
this is wrong.)
As a release engineer, I kind of don't really care if the software on
my image was installed via the packaging system. I just want a list of
what is on the images so I can audit my images to ensure GPL
commitments.
One way I've been looking at fixing this is via event handlers. I'll
have some code for RFC on this hopefully soon, but a preview (which
may or may not work it's still a WIP) is at:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=eflanagan/license_manifest
One thing the patch I've been working on does other than creates
accurate manifests is it also tries to create a semi-compliant SPDX
1.0 manifest.
I know this is late in the cycle so it might not make 1.3, but this
may be something we want to look at to end up solving this issue once
and for all.
This depends whether this is a release manifest or an image manifest.
You likely want *both* under different circumstances. If the kernel is
installed in the image, it will be listed in the image manifest. We just
need to be really clear about what the manifest is for.
As for modutils, we use kmod now. Basically anything doing deployment
should have a manifest associated with it. That is do_deploy (kernel,
uboot, some small list of others) and do_rootfs. do_package_write_* are
also arguably deployment in another form, as are sstate feeds.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] license: Ensure we find multilib packages also
On Friday 14 September 2012 13:50:22 Flanagan, Elizabeth wrote: We really shouldn't be relying on package data at all for license manifests. As the manifests are relying on list_installed_packages, they end up inaccurate anyway as list_installed_packages does exactly that. List software installed via package. Not installed via the package manager? Then you aren't in the manifest. This ends up missing quite a few things necessary from a release engineering standpoint (like, hey, modutils? The kernel? Not listed in the manifest. IMHO this is wrong.) What do you mean by modutils? If you mean the earlier suggestion that module- init-tools was missing from the manifest, I'm fairly certain that was a misunderstanding because of it being replaced by kmod. The thing is, we have no other means of accurately determining the contents of the image than the installed package list, given that the package manager is ultimately in charge of resolving and installing dependencies during image creation. The list may not cover additional files copied into tmp/deploy as part of building the image (kernel, bootloader, etc.) - however, that does not make it inaccurate as to the contents of the image, let's be clear about that. I agree we do need to write out the license information for these additional files; however, since they aren't actually *in* the image itself, I think we need to list these in a separate file. What happens for example if the system builds u-boot as a result of building my image, but I don't ever end up distributing that with the image? As to the mechanism for picking these up, the only real possibility I can see is to hook into do_deploy; this is not currently straightforward though since that's not something that is implemented generically at the moment. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: remove broken RREPLACES
On 9/14/12 5:03 PM, Phil Blundell wrote: On Fri, 2012-09-14 at 16:56 -0500, Mark Hatle wrote: On 9/14/12 4:50 PM, Phil Blundell wrote: On Fri, 2012-09-14 at 18:29 +0100, Paul Eggleton wrote: Unfortunately with rpm at least, this results in xserver-xorg-module-exa being installed in preference to xserver-xorg when constructing the root filesystem, which is clearly not desirable. Surely this is a bug in the rpm packaging backend and ought to be fixed there. If a package replaces another, it has priority. What is the desired behavior in this case? The conventional behaviour has been that: - if a package RREPLACES another (without declaring any other dependencies) then it is allowed to overwrite files in that package without producing an error. This is necessary when files move from one package to another but both should remain installed. - if a package wishes to entirely replace another one, it should both RREPLACE and RCONFLICT with the old one in order to force it off. Generally it would also want to RPROVIDE that package otherwise the replacement is liable to cause broken dependencies. Coming from the RPM world, that behavior is entirely unexpected. There is no way (by design) for an RPM package to be tagged as being allowed to replace files of another package. You can either replace a package, or you can conflict with another. Replace automatically creates a conflict (even though most people specify them both.) In the RPM world, files are verified, and two packages can not write to the same file -- unless the md5sum of the file is the same in both packages. The only exception is when a file is tagged as a configuration file or a ghost. (Ghost means a package owns a file, but doesn't actually provide the file itself.) Even that semantic is different. --Mark p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: remove broken RREPLACES
On Fri, 2012-09-14 at 17:13 -0500, Mark Hatle wrote: Coming from the RPM world, that behavior is entirely unexpected. There is no way (by design) for an RPM package to be tagged as being allowed to replace files of another package. How would rpm conventionally deal with the situation at hand here (a file which was previously in xserver-xorg and is now in xserver-xorg-module-exa)? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] license: Ensure we find multilib packages also
On Fri, Sep 14, 2012 at 3:11 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 14 September 2012 13:50:22 Flanagan, Elizabeth wrote: We really shouldn't be relying on package data at all for license manifests. As the manifests are relying on list_installed_packages, they end up inaccurate anyway as list_installed_packages does exactly that. List software installed via package. Not installed via the package manager? Then you aren't in the manifest. This ends up missing quite a few things necessary from a release engineering standpoint (like, hey, modutils? The kernel? Not listed in the manifest. IMHO this is wrong.) What do you mean by modutils? If you mean the earlier suggestion that module- init-tools was missing from the manifest, I'm fairly certain that was a misunderstanding because of it being replaced by kmod. Correct. Even so, there are things obviously missing from the manifests. Kernel is the most obvious. The thing is, we have no other means of accurately determining the contents of the image than the installed package list, given that the package manager is ultimately in charge of resolving and installing dependencies during image creation. The list may not cover additional files copied into tmp/deploy as part of building the image (kernel, bootloader, etc.) - however, that does not make it inaccurate as to the contents of the image, let's be clear about that. No, but it's like the joke about the two software managers in a hot air balloon asking the engineer on the group where they are only to be told In a hot air balloon. It's technically correct but the user case I keep running into here is that people want to know what they're deploying with a product. The expectation people have (and right or wrong, it's what I keep running into) is that everything that's on the hddimg is what is on the manifest. I agree we do need to write out the license information for these additional files; however, since they aren't actually *in* the image itself, I think we need to list these in a separate file. What happens for example if the system builds u-boot as a result of building my image, but I don't ever end up distributing that with the image? Then you have a manifest that has software that you end up complying with the GPL (when you don't really need to) verses having a manifest that doesn't list software which you do need to comply with the GPL. Both are wrong, but one is more wrong. RP is right here. We probably need to list a few different use cases here and support the most common ones. As to the mechanism for picking these up, the only real possibility I can see is to hook into do_deploy; this is not currently straightforward though since that's not something that is implemented generically at the moment. I'm currently hooking into do_package because, as best I can figure it out, everything ends up getting packaged, even if it's not installed via package. I'm happy for other suggestions though. -b Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- Elizabeth Flanagan Yocto Project Build and Release ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: remove broken RREPLACES
On 9/14/12 5:16 PM, Phil Blundell wrote:
On Fri, 2012-09-14 at 17:13 -0500, Mark Hatle wrote:
Coming from the RPM world, that behavior is entirely unexpected. There is no
way (by design) for an RPM package to be tagged as being allowed to replace
files of another package.
How would rpm conventionally deal with the situation at hand here (a
file which was previously in xserver-xorg and is now in
xserver-xorg-module-exa)?
You would have one or more packages dedicate to that or a set of files.. and
only one of them could be installed at a given time (using conflicts).
Alternatively, if the file is a configuration file, the file is tagged as a
such. (But I'm not completely sure even that would work.)
The case I'm most familiar with in proprietary OpenGL drivers. (In an RPM based
distro...) By default it used to be that the mesa-libs package would include
all of the mesa libraries including libGL, and libGLU. When the proprietary
versions of those files came around, it was necessary to split off the libGL and
libGLU into specific packages.. so now you had: mesa-libs, mesa-libGL, and
mesa-libGLU. The proprietary stuff provided it's own libGL/libGLU and contained
a replaces (or conflict) on the libGL/libGLU from mesa. [besides w/o the
conflict, the user would get an install error that two files conflicted between
the packages]
Looking at the item in context:
(meta/recipes-graphics/xserver-xorg/xserver-xorg.inc)
PACKAGES =+ ... \
${PN}-module-exa \
...
RREPLACES_${PN}-module-exa = ${PN}
FILES_${PN}-module-exa = ${libdir}/xorg/modules/libexa.so
Based on that, I'm not sure what RREPLACES is being used for:
FILES_${PN} = ${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards
${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so
${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt
${datadir}/X11/xorg.conf.d
Since under the packaging rules, that one file will only exist in the one
package, and it won't ever exist in both packages.
So Replaces is wrong under either definition from what I can tell.
--Mark
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] license: Ensure we find multilib packages also
On 9/14/12 5:26 PM, Flanagan, Elizabeth wrote: On Fri, Sep 14, 2012 at 3:11 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 14 September 2012 13:50:22 Flanagan, Elizabeth wrote: We really shouldn't be relying on package data at all for license manifests. As the manifests are relying on list_installed_packages, they end up inaccurate anyway as list_installed_packages does exactly that. List software installed via package. Not installed via the package manager? Then you aren't in the manifest. This ends up missing quite a few things necessary from a release engineering standpoint (like, hey, modutils? The kernel? Not listed in the manifest. IMHO this is wrong.) What do you mean by modutils? If you mean the earlier suggestion that module- init-tools was missing from the manifest, I'm fairly certain that was a misunderstanding because of it being replaced by kmod. Correct. Even so, there are things obviously missing from the manifests. Kernel is the most obvious. The thing is, we have no other means of accurately determining the contents of the image than the installed package list, given that the package manager is ultimately in charge of resolving and installing dependencies during image creation. The list may not cover additional files copied into tmp/deploy as part of building the image (kernel, bootloader, etc.) - however, that does not make it inaccurate as to the contents of the image, let's be clear about that. No, but it's like the joke about the two software managers in a hot air balloon asking the engineer on the group where they are only to be told In a hot air balloon. It's technically correct but the user case I keep running into here is that people want to know what they're deploying with a product. The expectation people have (and right or wrong, it's what I keep running into) is that everything that's on the hddimg is what is on the manifest. From thinking about the deployment of the rootfs through images, it seems to me it should be the responsibility of the components populating the items to produce a manifest of what they've done. Be it install a package, or copy a file. Then at the end collect together these manifest fragments to describe exactly what was done (and where it was done to!). I agree we do need to write out the license information for these additional files; however, since they aren't actually *in* the image itself, I think we need to list these in a separate file. What happens for example if the system builds u-boot as a result of building my image, but I don't ever end up distributing that with the image? Then you have a manifest that has software that you end up complying with the GPL (when you don't really need to) verses having a manifest that doesn't list software which you do need to comply with the GPL. Both are wrong, but one is more wrong. RP is right here. We probably need to list a few different use cases here and support the most common ones. As to the mechanism for picking these up, the only real possibility I can see is to hook into do_deploy; this is not currently straightforward though since that's not something that is implemented generically at the moment. I'm currently hooking into do_package because, as best I can figure it out, everything ends up getting packaged, even if it's not installed via package. I'm happy for other suggestions though. -b Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: remove broken RREPLACES
On Fri, 2012-09-14 at 17:28 -0500, Mark Hatle wrote:
Based on that, I'm not sure what RREPLACES is being used for:
FILES_${PN} = ${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards
${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so
${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt
${datadir}/X11/xorg.conf.d
Since under the packaging rules, that one file will only exist in the one
package, and it won't ever exist in both packages.
So Replaces is wrong under either definition from what I can tell.
The point is that it was in older versions of xserver-xorg. It's indeed
not in the current version, and in fact it can't be since (due to the
way that FILES works) there is no way for a single file to end up in
more than one of the PACKAGES for a given recipe.
In the particular case at hand I think the problem is relatively minor,
since folks who have an old xserver-xorg installed can upgrade by first
installing the new xserver-xorg (which doesn't ship libexa.so) and then
installing xserver-xorg-module-exa. But, if the new xserver-xorg had
depended on xserver-xorg-module-exa then this wouldn't have worked
without the RREPLACES.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xorg: remove broken RREPLACES
On 9/14/12 5:37 PM, Phil Blundell wrote:
On Fri, 2012-09-14 at 17:28 -0500, Mark Hatle wrote:
Based on that, I'm not sure what RREPLACES is being used for:
FILES_${PN} = ${bindir} ${libdir}/X11/Options ${libdir}/X11/Cards
${libdir}/X11/getconfig ${libdir}/X11/etc ${libdir}/modules/*.so
${libdir}/xorg/modules/*.so /etc/X11 ${libdir}/xorg/protocol.txt
${datadir}/X11/xorg.conf.d
Since under the packaging rules, that one file will only exist in the one
package, and it won't ever exist in both packages.
So Replaces is wrong under either definition from what I can tell.
The point is that it was in older versions of xserver-xorg. It's indeed
not in the current version, and in fact it can't be since (due to the
way that FILES works) there is no way for a single file to end up in
more than one of the PACKAGES for a given recipe.
Ahh, thats easy.. It conflicts or replaces an older version..
RCONFLICTS_... = ${PN} (${PV})
or something like that. Once updated to the current version of ${PN} no
conflict.
In the particular case at hand I think the problem is relatively minor,
since folks who have an old xserver-xorg installed can upgrade by first
installing the new xserver-xorg (which doesn't ship libexa.so) and then
installing xserver-xorg-module-exa. But, if the new xserver-xorg had
depended on xserver-xorg-module-exa then this wouldn't have worked
without the RREPLACES.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] license: Ensure we find multilib packages also
On Friday 14 September 2012 15:26:14 Flanagan, Elizabeth wrote: The thing is, we have no other means of accurately determining the contents of the image than the installed package list, given that the package manager is ultimately in charge of resolving and installing dependencies during image creation. The list may not cover additional files copied into tmp/deploy as part of building the image (kernel, bootloader, etc.) - however, that does not make it inaccurate as to the contents of the image, let's be clear about that. No, but it's like the joke about the two software managers in a hot air balloon asking the engineer on the group where they are only to be told In a hot air balloon. It's technically correct but the user case I keep running into here is that people want to know what they're deploying with a product. Again, I absolutely agree we need to report the licenses for these files. I'm just advocating not commingling two separate things. The expectation people have (and right or wrong, it's what I keep running into) is that everything that's on the hddimg is what is on the manifest. hddimg files are a special situation anyway though. To handle those properly we would have to use some special license reporting in the same place where the hddimg is composed, because we cannot really tell for certain anywhere else in the code as to what is in it. I agree we do need to write out the license information for these additional files; however, since they aren't actually *in* the image itself, I think we need to list these in a separate file. What happens for example if the system builds u-boot as a result of building my image, but I don't ever end up distributing that with the image? Then you have a manifest that has software that you end up complying with the GPL (when you don't really need to) verses having a manifest that doesn't list software which you do need to comply with the GPL. Both are wrong, but one is more wrong. RP is right here. We probably need to list a few different use cases here and support the most common ones. I think we can satisfy all of these cases in the manner I described - a manifest for the image (what we already have) and an additional manifest beside it that lists all of the additionally deployed files along with their license information. If the files are right next to eachother with the same base name there can't be any confusion. As to the mechanism for picking these up, the only real possibility I can see is to hook into do_deploy; this is not currently straightforward though since that's not something that is implemented generically at the moment. I'm currently hooking into do_package because, as best I can figure it out, everything ends up getting packaged, even if it's not installed via package. I'm happy for other suggestions though. pkgdata (which writes files into TMPDIR/pkgdata) already hooks into do_package and already lists LICENSE on a per-package basis for every package written out. Clearly we can't just take absolutely every package produced as the list for the manifest though, because not all of that gets installed into the image. Another more serious issue is that it's not guaranteed that everything that gets deployed is packaged, so this probably wouldn't satisfactorily solve the issue anyway. As far as I can see, do_deploy is the only way, since we want to know what is deployed and which recipe deployed it. We'll just have to adjust things so that there is a central point we can tap into for do_deploy in order to collect the desired information - I haven't looked into how yet but I don't anticipate it being too hard. I think we're also going to have to add a specific call that can be made from anywhere during do_rootfs that adds a recipe to be reported in the manifest. We can use this for custom cases such as hddimg and provide it for anyone doing anything similar to call manually (e.g. adding non-packaged files into their image in a post-processing function - not really recommended but I know people do do it). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] runqemu: show bitbake errors to user
In certain edge cases, bitbake may fail to run and cause setup_tmpdir()
within runqemu to fail, and not give the user a helpful error message.
Catch this case and show the user the output of bitbake -e.
This fixes [YOCTO #3112]
Signed-off-by: Scott Garman scott.a.gar...@intel.com
---
scripts/runqemu | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index e843946..8bb77ff 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -283,8 +283,16 @@ setup_tmpdir() {
# We have bitbake in PATH, get OE_TMPDIR from bitbake
OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\ | cut -d '='
-f2 | cut -d '' -f2`
if [ -z $OE_TMPDIR ]; then
-echo Error: this script needs to be run from your build
directory,
-echo or you need to explicitly set OE_TMPDIR in your environment
+# Check for errors from bitbake that the user needs to know about
+BITBAKE_OUTPUT=`bitbake -e`
+if [ -z $BITBAKE_OUTPUT ]; then
+echo Error: this script needs to be run from your build
directory,
+echo or you need to explicitly set OE_TMPDIR in your
environment
+else
+echo There was an error running bitbake to determine TMPDIR
+echo Here is the output from 'bitbake -e':
+bitbake -e
+fi
exit 1
fi
fi
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] runqemu bugfix
Hello, This is a fix for Yocto bug #3112, where there are certain edge cases where the bitbake command is avalable to fails to run. Previously we mistakenly treated that as the same case as if bitbake didn't exist in the user's $PATH, and this fix causes us to show the user the output of bitbake so they can view the error message. Scott The following changes since commit 7887b99646d8e1e736ad6e4a306e47df9955221e: local.conf.sample: change valgrind support architecture comment (2012-09-14 17:05:59 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib sgarman/runqemu-bitbake-fix-oe http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgarman/runqemu-bitbake-fix-oe Scott Garman (1): runqemu: show bitbake errors to user scripts/runqemu | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 1.7.9.5 ___ 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] runqemu: show bitbake errors to user
On 9/14/12 6:15 PM, Scott Garman wrote:
In certain edge cases, bitbake may fail to run and cause setup_tmpdir()
within runqemu to fail, and not give the user a helpful error message.
Catch this case and show the user the output of bitbake -e.
This fixes [YOCTO #3112]
Signed-off-by: Scott Garman scott.a.gar...@intel.com
---
scripts/runqemu | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index e843946..8bb77ff 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -283,8 +283,16 @@ setup_tmpdir() {
# We have bitbake in PATH, get OE_TMPDIR from bitbake
OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\ | cut -d '=' -f2
| cut -d '' -f2`
if [ -z $OE_TMPDIR ]; then
-echo Error: this script needs to be run from your build
directory,
-echo or you need to explicitly set OE_TMPDIR in your environment
+# Check for errors from bitbake that the user needs to know about
+BITBAKE_OUTPUT=`bitbake -e`
I'm not sure that is a good idea. If there is a failure (anything on stderr) it
will just be dumped to the screen...
If it does succeed, it could attempt to load that variable with many MB of data,
which also likely isn't what is desired.
It might be better to dump the items to a tmp file (securely created of course)
;) and then keep processing the same file for error messages, warnings, etc...
+if [ -z $BITBAKE_OUTPUT ]; then
+echo Error: this script needs to be run from your build
directory,
+echo or you need to explicitly set OE_TMPDIR in your
environment
+else
+echo There was an error running bitbake to determine TMPDIR
+echo Here is the output from 'bitbake -e':
+bitbake -e
+fi
exit 1
fi
fi
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
