Re: [OE-core] [PATCH 2/2] xserver-xorg: update to 1.16.1
On Sat, 2014-11-08 at 14:47 +, Richard Purdie wrote:
On Fri, 2014-11-07 at 08:52 +0100, Andreas Müller wrote:
* first version supporting rootless X (not tested yet)
* modesetting working for non PCI gpus (tested on gumstix overo)
Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
.../xorg-xserver/xserver-xorg/crosscompile.patch | 22
.../xserver-xorg/mips64-compiler.patch | 29 --
.../xorg-xserver/xserver-xorg/present-module.patch | 66
--
...erver-xorg_1.15.1.bb = xserver-xorg_1.16.1.bb} | 9 +--
4 files changed, 3 insertions(+), 123 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/crosscompile.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/mips64-compiler.patch
delete mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/present-module.patch
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.15.1.bb =
xserver-xorg_1.16.1.bb} (75%)
Whilst I haven't 100% confirmed it:
https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/96
https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/95
https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/95
https://autobuilder.yoctoproject.org/main/builders/nightly-qa-systemd/builds/94
https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/95
all look like it may well be as a result of this change (which was
included in the master-next build in question). This change will be
delayed merging until we figure out if this patch is responsible and how
to fix whatever the cause is. Obviously any help in doing that is much
appreciated.
It is 100% confirmed now, with the patch reverted there was a green
build.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH] u-boot-mkimage: allow building target version of the tool
Op 9 nov. 2014, om 08:51 heeft Denys Dmytriyenko de...@denix.org het
volgende geschreven:
On Sat, Nov 08, 2014 at 05:12:36PM -0200, Otavio Salvador wrote:
On Fri, Nov 7, 2014 at 8:24 PM, Denys Dmytriyenko de...@denix.org wrote:
From: Denys Dmytriyenko de...@ti.com
u-boot doesn't really support building its tools for the target, as they are
built with HOSTCC compiler, which is also used to compile fixdep utility
that gets executed during the build. Since it might be beneficial to have a
target version of mkimage, let's hack it to build fixdep in a separate step.
Signed-off-by: Denys Dmytriyenko de...@ti.com
...
+ make HOSTCC=${BUILD_CC} HOSTLD=${BUILD_LD}
HOSTLDFLAGS=${BUILD_LDFLAGS} HOSTSTRIP=true dot-config=0 scripts_basic
...
We do it in meta-fsl-arm as below:
That still doesn't work when building tools for the target:
/bin/sh: scripts/basic/fixdep: cannot execute binary file: Exec format error
I guess you are missing the point of this patch, as sandbox_defconfig will
only eliminate dot-config=0 parameter, but not the need to build fixdep
separately with a different host compiler...
On the other hand - is it a real requirement to build mkimage for the target?
I use it a lot when regenerating initramfses on the target.
regards,
Koen
ESCRIPTION = U-boot bootloader mxsboot tool
LICENSE = GPLv2+
LIC_FILES_CHKSUM =
file://Licenses/README;md5=c7383a594871c03da76b3707929d2919
SECTION = bootloader
DEPENDS = openssl
PROVIDES = u-boot-mxsboot
PV = v2014.10+git${SRCPV}
SRCREV = 75ce95e627609c9b9e537e935e69c4ecef26c8f7
SRCBRANCH = patches-2014.10
SRC_URI = git://github.com/Freescale/u-boot-imx.git;branch=${SRCBRANCH}
S = ${WORKDIR}/git
inherit fsl-u-boot-localversion
EXTRA_OEMAKE = 'HOSTCC=${CC} ${CPPFLAGS} HOSTLDFLAGS=-L${libdir}
-L${base_libdir} HOSTSTRIP=true CONFIG_MX28=y'
do_configure () {
oe_runmake sandbox_defconfig
}
do_compile () {
oe_runmake tools-only
}
do_install () {
install -d ${D}${bindir}
install -m 0755 tools/mxsboot ${D}${bindir}/uboot-mxsboot
ln -sf uboot-mxsboot ${D}${bindir}/mxsboot
}
BBCLASSEXTEND = native nativesdk
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Public OE TSC meeting
Hi all, There will be a public OpenEmbedded TSC/workgroup IRC meeting this coming Tuesday (11th November). If you're interested in discussing long-term technical efforts around the OpenEmbedded project please join us on irc.freenode.net in channel #oe at 17:00 GMT (9am PST, 11am CST, 12 EST, 18:00 CET). Possible topics for discussion (based on the last meeting and recent mailing list topics): - Upcoming development cycle - Website and other infrastructure issues New topics for discussion are welcome. Cheers, Paul -- Paul Eggleton Intel Open Source Technology CentreBEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH BEGIN:VEVENT DTSTART:2014T17Z DTEND:2014T18Z TRANSP:TRANSPARENT SUMMARY:Public OE TSC meeting LOCATION:#oe on Freenode IRC URL;VALUE=URI:http://www.timeanddate.com/worldclock/meetingdetails.html?is o=2014T1700p1=136p2=64p3=137p4=195p5=179 UID:http://www.timeanddate.com/worldclock/meetingdetails.html?iso=2014 T1700p1=136p2=64p3=137p4=195p5=179 DTSTAMP:2014T17Z END:VEVENT END:VCALENDAR -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gptfdisk: add 0.8.10+git version
On 8 November 2014 18:55, Koen Kooi k...@dominion.thruhere.net wrote:
I can if you'd like that, the utils were few and small, so I put them all
in ${PN}, let me know if you still want them seperate.
Personally I don't see a reason to split the tools up, but following
tradition and shipping them in $sbindir is sensible.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] building world
On 9 November 2014 04:43, akuster808 akuster...@gmail.com wrote: WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM won't work correctly It seems to me that if one is building 'world' then all DISTRO_FEATURES should be defined, otherwise World isn't really world. If world enabled all distro features then you won't be able to do a world build to verify that everything builds without specific distro features being enabled. If I were building a system that did world builds and alerted on any warnings, I'd have a whitelist. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/25] Add machine qemuarm64
On 8 November 2014 17:07, Mark Hatle mark.ha...@windriver.com wrote: This is why relying on userspace qemu to do postinstall actions isn't good. If the host kernel doesn't have a new enough kernel it'll break. If the qemu does emulate the exact SOC, it'll break.. etc.. etc.. etc.. Do you know how new is new enough for aarch64? My build machine is running 3.2.0 at the moment (Debian stable). So I would expect failures like this on anything that is using QEMU userspace emulation (any arch). Apart from userspace ppc aborting we've done pretty well so far... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: update to version 2014.07
On 7 November 2014 22:30, Denys Dmytriyenko de...@denix.org wrote: I've just sent an RFC patch to allow building mkimage for the target. I'd like to collect feedback for it first, but feel free to squash it with the previous patch, if it's accepted (or commit separately - your choice). The update to 2014.10 will follow shortly, I just want this version to get through first, as it has been in limbo for a few months... Thanks Denys, confirming that his works for me too. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider
On 11/09/2014 02:53 AM, Koen Kooi wrote: Op 7 nov. 2014, om 15:38 heeft Martin Jansa martin.ja...@gmail.com het volgende geschreven: On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote: The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += avahi Why don't you fix your IMAGE_INSTALL instead? I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL. I am afraid it is not the issue of IMAGE_INSTALL As doc said: http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL Variable IMAGE_INSTALL is used to specify the packages to install into an image. While adding some packages to image ,the rpm based do_rootfs failed with '*** not found in the base feeds' The failure was caused by two kinds of situations: 1. Package does not exist (such as python3), but provided by other package (such as python-core), the rpm based do_rootfs could not search its provider. And the deb/ ipk based do_rootfs worked well, it is a defect, and I have fixed it (patch sent to community, YOCTO 6918); 2. Package does not exist, and no other package provides it, the package installation will fail in any type do_rootfs. We met this issue when we set IMAGE_INSTALL = recipe_name, but we don't have the package with that name. I think what I do is to fix the situation 2. Further more, we should add checking at the package generating time, if the package *with recipe name* was empty and not created, trigger a warn and according the warn, we could fix the issue recipes. We already have that checking at the package generating time, but it a note, not warn. I suggest we should use warn instead. //Hongxu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/25] Add machine qemuarm64
On 11/9/14, 4:53 PM, Burton, Ross wrote: On 8 November 2014 17:07, Mark Hatle mark.ha...@windriver.com mailto:mark.ha...@windriver.com wrote: This is why relying on userspace qemu to do postinstall actions isn't good. If the host kernel doesn't have a new enough kernel it'll break. If the qemu does emulate the exact SOC, it'll break.. etc.. etc.. etc.. Do you know how new is new enough for aarch64? My build machine is running 3.2.0 at the moment (Debian stable). From what I found doing a google search 3.7.0 is minimum version for QEMU userspace on aarch64. --Mark So I would expect failures like this on anything that is using QEMU userspace emulation (any arch). Apart from userspace ppc aborting we've done pretty well so far... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qemu: remove task sanitize_sources
There is no dtc/.git and pixman/.git files any longer. So remove task
sanitize_sources which is used to remove these files.
Signed-off-by: Kai Kang kai.k...@windriver.com
---
meta/recipes-devtools/qemu/qemu_2.1.2.bb | 8
1 file changed, 8 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu_2.1.2.bb
b/meta/recipes-devtools/qemu/qemu_2.1.2.bb
index 0e20605..55ae7b6 100644
--- a/meta/recipes-devtools/qemu/qemu_2.1.2.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.1.2.bb
@@ -13,14 +13,6 @@ SRC_URI[sha256sum] =
fd10f5e45cf5a736fa5a3e1c279ae9821534e700beb7d1aab88a07648a
COMPATIBLE_HOST_class-target_mips64 = null
-do_sanitize_sources() {
-# These .git files point to a nonexistent path ../.git/modules and will
confuse git
-# if it tries to recurse into those directories.
-rm -f ${S}/dtc/.git ${S}/pixman/.git
-}
-
-addtask sanitize_sources after do_unpack before do_patch
-
do_install_append() {
# Prevent QA warnings about installed ${localstatedir}/run
if [ -d ${D}${localstatedir}/run ]; then rmdir ${D}${localstatedir}/run; fi
--
2.1.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] apr-native: Set CONFIG_SHELL to /bin/bash
The apr-native provides usr/share/build-1/libtool which is required by
the recipe such as apache2-native. If we don't set the CONFIG_SHELL to
/bin/bash, then:
1) If we build apr-native on a host which is /bin/sh - bash, the
interpreter in usr/share/build-1/libtool would be #!/bin/sh.
2) When we re-use apr-native's sstate on a host which is
/bin/sh - dash, there would be errors.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-support/apr/apr_1.5.1.bb |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/apr/apr_1.5.1.bb
b/meta/recipes-support/apr/apr_1.5.1.bb
index 17dddbc..49a08b0 100644
--- a/meta/recipes-support/apr/apr_1.5.1.bb
+++ b/meta/recipes-support/apr/apr_1.5.1.bb
@@ -86,3 +86,5 @@ do_install_ptest() {
cp ${S}/test/testall $t/
cp ${S}/test/tryread $t/
}
+
+export CONFIG_SHELL=/bin/bash
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] apr-native: Set CONFIG_SHELL to /bin/bash
The following changes since commit 33b7885ecdc8774e34ac3534ec49fed6ffdb3916: oprofile: 0.9.9 - 1.0.0 (2014-11-09 10:19:58 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/apr http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rtb/apr Robert Yang (1): apr-native: Set CONFIG_SHELL to /bin/bash meta/recipes-support/apr/apr_1.5.1.bb |2 ++ 1 file changed, 2 insertions(+) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Bluez5: Add gatttool to new package bluez5-tools
On Fri, 7 Nov 2014 12:42:14 +
Burton, Ross ross.bur...@intel.com wrote:
On 4 November 2014 05:04, Qian Lei qianl.f...@cn.fujitsu.com wrote:
# at_console doesn't really work with the current state of OE, so
punch some more holes so people can actually use BT
+install -m 0755 ${S}/attrib/gatttool ${D}/${bindir}/
install -m 0644 ${WORKDIR}/bluetooth.conf
${D}/${sysconfdir}/dbus-1/system.d/
}
Because of where you put the install, it looks like installing gatttool is
related to the DBus configuration.
Hi Ross, thank you for your review.
Sorry for making you confused, the install should be put before the comment. I
just want to install gatttool to bin directory and it is nothing related to
dbus. I'll correct it in the next version.
ALLOW_EMPTY_libasound-module-bluez = 1
-PACKAGES =+ libasound-module-bluez ${PN}-testtools ${PN}-obex
+PACKAGES =+ libasound-module-bluez ${PN}-testtools ${PN}-obex
${PN}-tools
Two questions:
1) If we're installing gatttool, why not the other tools that are noinst
(obex-client-tool, obexctl, etc). Patching the makefile would install all
the tools that upstream build.
Because in bluez4, gatttool was installed by default but obex-client-tool,
obexctl were not.
2) Do these deserve a separate package, or as they're for testing should
they go into PN-testtools?
gatttool is not a test tool, but a develop tool. In bluez4 it is in package
bluez4(not in bluez4-testtools). I don't think it's good to put it to any
existed package.
Qian Lei.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider
On Mon, Nov 10, 2014 at 10:02:47AM +0800, Hongxu Jia wrote: On 11/09/2014 02:53 AM, Koen Kooi wrote: Op 7 nov. 2014, om 15:38 heeft Martin Jansa martin.ja...@gmail.com het volgende geschreven: On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote: The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += avahi Why don't you fix your IMAGE_INSTALL instead? I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL. I am afraid it is not the issue of IMAGE_INSTALL As doc said: http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL Variable IMAGE_INSTALL is used to specify the packages to install into an image. While adding some packages to image ,the rpm based do_rootfs failed with '*** not found in the base feeds' The failure was caused by two kinds of situations: 1. Package does not exist (such as python3), but provided by other package (such as python-core), the rpm based do_rootfs could not search its provider. And the deb/ ipk based do_rootfs worked well, it is a defect, and I have fixed it (patch sent to community, YOCTO 6918); 2. Package does not exist, and no other package provides it, the package installation will fail in any type do_rootfs. We met this issue when we set IMAGE_INSTALL = recipe_name, but we don't have the package with that name. I think what I do is to fix the situation 2. Further more, we should add checking at the package generating time, if the package *with recipe name* was empty and not created, trigger a warn and according the warn, we could fix the issue recipes. The docs say that IMAGE_INSTALL is for package_name. So I think it's correct that it fails when you put recipe_name in it and sometimes there isn't any package with the same name. It's the same as trying to make RDEPENDS/DEPENDS entries to be interchangeable (putting recipe_names to RDEPENDS and package_names to DEPENDS). Especially with that patch for xinput-pointercal, if user explicitly asks for installing xinput-pointercal, what's the reason to create him completely empty package? IMHO it's only hiding that issue from him and instead of discovering the issue in do_rootfs task, he has to check generated rootfs or even boot the device. We already have that checking at the package generating time, but it a note, not warn. I suggest we should use warn instead. //Hongxu -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider
On 11/10/2014 02:42 PM, Martin Jansa wrote: The docs say that IMAGE_INSTALL is for package_name. So I think it's correct that it fails when you put recipe_name in it and sometimes there isn't any package with the same name. It's the same as trying to make RDEPENDS/DEPENDS entries to be interchangeable (putting recipe_names to RDEPENDS and package_names to DEPENDS). Especially with that patch for xinput-pointercal, if user explicitly asks for installing xinput-pointercal, what's the reason to create him completely empty package? IMHO it's only hiding that issue from him and instead of discovering the issue in do_rootfs task, he has to check generated rootfs or even boot the device. For most recipes, they generate packages with recipe name, it is not convenience to figure out the different between package_name and recipe_name, especially for newbies, which I means we should reduce that convenience, build relationship between recipe and package, especially when the recipe doesn't generate the same name package. As you said, for specific recipes, we don't want to generate packages, it doesn't make sense to install it by setting IMAGE_INSTALL. But if the recipe generate packages, it is reasonable to take one with recipe name, take python3 for example, it choose python-core as the provider. That's why I sent patch for avahi and oprofileui. The avahi didn't generate package avahi, but it is reasonable to choose avahi-daemon, as the SUMMARY said it is a IPv4 configuration daemon. For oprofileui, it only generates package oprofileui-viewer, if we have oprofileui as its nick name, I think it is more convenience for the users. //Hongxu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
