Re: [OE-core] [PATCH 1/1] qt4: remove already merged patch
On Fri, Sep 18, 2015 at 7:16 AM, Paul Eggleton wrote: > This patch was merged into the 4.8.7 release. This was missed on > upgrade, and we didn't notice because our quilt-based patch handling > code ignores already-applied patches. this is a problem. My host quilt fails on me on duplicate patching, this should be default otherwise we will accumulate dead code. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 0/3] Dynamic common utilities
On vie, 2015-09-18 at 23:31 +0100, Richard Purdie wrote:
> On Fri, 2015-09-18 at 16:09 -0500, Alejandro Joya wrote:
> > It provide a virtual reference for the common utilities.
> > it replace of the lock to busybox, it will be simple exchange between other
> > common utilities like gnu core utils or toybox among others.
> >
> > In order to enable its required to fill at the distro conf or local.conf
> >
> > VIRTUAL-RUNTIME_login_manager ?= "busybox"
> > PREFERRED_PROVIDER_virtual/base-utils?= "busybox"
> > PREFERRED_RPROVIDER_virtual/base-utils?= "busybox"
> > VIRTUAL-RUNTIME_base-utils?= "busybox"
> > VIRTUAL-RUNTIME_base-utils-hwclock ?= "busybox-hwclock"
>
> As I understand it, you don't actually define defaults anywhere. This
> means OE would break "out the box" which isn't acceptable and that alone
> means I can't merge this.
you are totally right, one of my doubts still is, where is the most
suitable place to defined this as single point?
>
> Secondly, the virtual/xxx namespace is *only* for DEPENDS/PROVIDES, not
> RDEPENDS or PACKAGE_INSTALL. For runtime packages, you need to use
> ${VIRTUAL-RUNTIME_base-utils}.
>
thanks I appreciated the correction.
> Cheers,
>
> Richard
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 0/3] Dynamic common utilities
On Fri, 2015-09-18 at 16:09 -0500, Alejandro Joya wrote:
> It provide a virtual reference for the common utilities.
> it replace of the lock to busybox, it will be simple exchange between other
> common utilities like gnu core utils or toybox among others.
>
> In order to enable its required to fill at the distro conf or local.conf
>
> VIRTUAL-RUNTIME_login_manager ?= "busybox"
> PREFERRED_PROVIDER_virtual/base-utils?= "busybox"
> PREFERRED_RPROVIDER_virtual/base-utils?= "busybox"
> VIRTUAL-RUNTIME_base-utils?= "busybox"
> VIRTUAL-RUNTIME_base-utils-hwclock ?= "busybox-hwclock"
As I understand it, you don't actually define defaults anywhere. This
means OE would break "out the box" which isn't acceptable and that alone
means I can't merge this.
Secondly, the virtual/xxx namespace is *only* for DEPENDS/PROVIDES, not
RDEPENDS or PACKAGE_INSTALL. For runtime packages, you need to use
${VIRTUAL-RUNTIME_base-utils}.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] testimage.bbclass: Fix break introduced with SIGTERM handling
From: Mariano Lopez
The SIGTERM introduced another break into runexported test,
the handler is in the class TestContext while exporting it
will try to convert the singnal handler to JSON, and this
will throw an exception.
The SIGTERM handler is not needed in the exported test, so this
change will remove the handler before exporting the test. Also
when a test is exported the target is not deployed/started
anymore, it is not necessary.
[YOCTO #8239]
Signed-off-by: Mariano Lopez
---
meta/classes/testimage.bbclass | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index a1918ba..fd4143d 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -305,13 +305,15 @@ def testimage_main(d):
import traceback
bb.fatal("Loading tests failed:\n%s" % traceback.format_exc())
-target.deploy()
-try:
-target.start()
-if export:
-exportTests(d,tc)
-else:
+if export:
+signal.signal(signal.SIGTERM, tc.origsigtermhandler)
+tc.origsigtermhandler = None
+exportTests(d,tc)
+else:
+target.deploy()
+try:
+target.start()
starttime = time.time()
result = runTests(tc)
stoptime = time.time()
@@ -324,9 +326,9 @@ def testimage_main(d):
bb.plain(msg)
else:
raise bb.build.FuncFailed("%s - FAILED - check the task log
and the ssh log" % pn )
-finally:
-signal.signal(signal.SIGTERM, tc.origsigtermhandler)
-target.stop()
+finally:
+signal.signal(signal.SIGTERM, tc.origsigtermhandler)
+target.stop()
testimage_main[vardepsexclude] =+ "BB_ORIGENV"
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] python3-debugger: Adds pkgutils dependency to pdb
python3-debugger fails to be invoked to debug other scripts complaining about
not being able to import pkutil, this patch adds pkgutil as a dependency for
python3-debugger
fixing the issue.
[YOCTO #8334]
Signed-off-by: Alejandro Hernandez
---
meta/recipes-devtools/python/python-3.4-manifest.inc | 2 +-
scripts/contrib/python/generate-manifest-3.4.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/python/python-3.4-manifest.inc
b/meta/recipes-devtools/python/python-3.4-manifest.inc
index f828623..97070b6 100644
--- a/meta/recipes-devtools/python/python-3.4-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.4-manifest.inc
@@ -58,7 +58,7 @@ RDEPENDS_${PN}-db="${PN}-core"
FILES_${PN}-db="${libdir}/python3.4/anydbm.* ${libdir}/python3.4/dumbdbm.*
${libdir}/python3.4/whichdb.* ${libdir}/python3.4/dbm
${libdir}/python3.4/lib-dynload/_dbm.*.so "
SUMMARY_${PN}-debugger="Python debugger"
-RDEPENDS_${PN}-debugger="${PN}-core ${PN}-io ${PN}-lang ${PN}-re
${PN}-stringold ${PN}-shell ${PN}-pprint ${PN}-importlib"
+RDEPENDS_${PN}-debugger="${PN}-core ${PN}-io ${PN}-lang ${PN}-re
${PN}-stringold ${PN}-shell ${PN}-pprint ${PN}-importlib ${PN}-pkgutil"
FILES_${PN}-debugger="${libdir}/python3.4/bdb.* ${libdir}/python3.4/pdb.* "
SUMMARY_${PN}-dev="Python development package"
diff --git a/scripts/contrib/python/generate-manifest-3.4.py
b/scripts/contrib/python/generate-manifest-3.4.py
index 9e9debd..ca2fa61 100755
--- a/scripts/contrib/python/generate-manifest-3.4.py
+++ b/scripts/contrib/python/generate-manifest-3.4.py
@@ -238,7 +238,7 @@ if __name__ == "__main__":
m.addPackage( "${PN}-db", "Python file-based database support",
"${PN}-core",
"anydbm.* dumbdbm.* whichdb.* dbm lib-dynload/_dbm.*.so" )
-m.addPackage( "${PN}-debugger", "Python debugger", "${PN}-core ${PN}-io
${PN}-lang ${PN}-re ${PN}-stringold ${PN}-shell ${PN}-pprint ${PN}-importlib",
+m.addPackage( "${PN}-debugger", "Python debugger", "${PN}-core ${PN}-io
${PN}-lang ${PN}-re ${PN}-stringold ${PN}-shell ${PN}-pprint ${PN}-importlib
${PN}-pkgutil",
"bdb.* pdb.*" )
m.addPackage( "${PN}-difflib", "Python helpers for computing deltas
between objects", "${PN}-lang ${PN}-re",
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] python3-debugger: fix importlib dependency
python3-debugger (pdb) needs importlib as a dependency, if not included
it produces an error when importing pdb, making pdb unusable, this patch
adds importlib dependency fixing the issue.
{YOCT0 #8333]
Signed-off-by: Alejandro Hernandez
---
meta/recipes-devtools/python/python-3.4-manifest.inc | 2 +-
scripts/contrib/python/generate-manifest-3.4.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/python/python-3.4-manifest.inc
b/meta/recipes-devtools/python/python-3.4-manifest.inc
index 07e1490..f828623 100644
--- a/meta/recipes-devtools/python/python-3.4-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.4-manifest.inc
@@ -58,7 +58,7 @@ RDEPENDS_${PN}-db="${PN}-core"
FILES_${PN}-db="${libdir}/python3.4/anydbm.* ${libdir}/python3.4/dumbdbm.*
${libdir}/python3.4/whichdb.* ${libdir}/python3.4/dbm
${libdir}/python3.4/lib-dynload/_dbm.*.so "
SUMMARY_${PN}-debugger="Python debugger"
-RDEPENDS_${PN}-debugger="${PN}-core ${PN}-io ${PN}-lang ${PN}-re
${PN}-stringold ${PN}-shell ${PN}-pprint"
+RDEPENDS_${PN}-debugger="${PN}-core ${PN}-io ${PN}-lang ${PN}-re
${PN}-stringold ${PN}-shell ${PN}-pprint ${PN}-importlib"
FILES_${PN}-debugger="${libdir}/python3.4/bdb.* ${libdir}/python3.4/pdb.* "
SUMMARY_${PN}-dev="Python development package"
diff --git a/scripts/contrib/python/generate-manifest-3.4.py
b/scripts/contrib/python/generate-manifest-3.4.py
index 06eecdc..9e9debd 100755
--- a/scripts/contrib/python/generate-manifest-3.4.py
+++ b/scripts/contrib/python/generate-manifest-3.4.py
@@ -238,7 +238,7 @@ if __name__ == "__main__":
m.addPackage( "${PN}-db", "Python file-based database support",
"${PN}-core",
"anydbm.* dumbdbm.* whichdb.* dbm lib-dynload/_dbm.*.so" )
-m.addPackage( "${PN}-debugger", "Python debugger", "${PN}-core ${PN}-io
${PN}-lang ${PN}-re ${PN}-stringold ${PN}-shell ${PN}-pprint",
+m.addPackage( "${PN}-debugger", "Python debugger", "${PN}-core ${PN}-io
${PN}-lang ${PN}-re ${PN}-stringold ${PN}-shell ${PN}-pprint ${PN}-importlib",
"bdb.* pdb.*" )
m.addPackage( "${PN}-difflib", "Python helpers for computing deltas
between objects", "${PN}-lang ${PN}-re",
--
1.8.4.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/3] Dynamic common utilities
It provide a virtual reference for the common utilities.
it replace of the lock to busybox, it will be simple exchange between other
common utilities like gnu core utils or toybox among others.
In order to enable its required to fill at the distro conf or local.conf
VIRTUAL-RUNTIME_login_manager ?= "busybox"
PREFERRED_PROVIDER_virtual/base-utils?= "busybox"
PREFERRED_RPROVIDER_virtual/base-utils?= "busybox"
VIRTUAL-RUNTIME_base-utils?= "busybox"
VIRTUAL-RUNTIME_base-utils-hwclock ?= "busybox-hwclock"
The following changes since commit 72682d72b52355c3fed947167ca3c6064340ead1:
autotools.bbclass: mkdir ${B} -> mkdir -p ${B} (2015-09-16 22:17:19 +0100)
are available in the git repository at:
git://github.com/Ajoyacr/openembedded-core base-utils
https://github.com/Ajoyacr/openembedded-core/tree/base-utils
Alejandro Joya (3):
core-mage-minimal-initramfs: replace dependency
initramfs-framework:add virtual reference
packagegroup-core-boot:change to virtual reference
meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +-
meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 2 +-
meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 2/3] initramfs-framework:add virtual reference
This recipe have a hardcoded dependency to busybox, in order to be able to have
a flexible selection,
instead of the hardcoded dependency,now is point to virtual reference
base-utils.
Signed-off-by: Alejandro Joya
---
meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 6c37b9a..5a6e254 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -1,7 +1,7 @@
SUMMARY = "Modular initramfs system"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-RDEPENDS_${PN} += "busybox"
+RDEPENDS_${PN} += "virtual/base-utils"
PR = "r2"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 3/3] packagegroup-core-boot:change to virtual reference
This recipe have a hardcoded dependency to busybox, in order to be able to have
a flexible selection,
instead of the hardcoded dependency,now is point to virtual reference
base-utils.
Signed-off-by: Alejandro Joya
---
meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
index 09f5373..38f29ce 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
@@ -19,12 +19,12 @@ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""
# Distro can override the following VIRTUAL-RUNTIME providers:
VIRTUAL-RUNTIME_dev_manager ?= "udev"
-VIRTUAL-RUNTIME_login_manager ?= "busybox"
+VIRTUAL-RUNTIME_login_manager ?= "${VIRTUAL-RUNTIME_base-utils}"
VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
VIRTUAL-RUNTIME_initscripts ?= "initscripts"
VIRTUAL-RUNTIME_keymaps ?= "keymaps"
-SYSVINIT_SCRIPTS = "${@bb.utils.contains('MACHINE_FEATURES', 'rtc',
'busybox-hwclock', '', d)} \
+SYSVINIT_SCRIPTS = "${@bb.utils.contains('MACHINE_FEATURES', 'rtc',
'${VIRTUAL-RUNTIME_base-utils-hwclock}', '', d)} \
modutils-initscripts \
init-ifupdown \
${VIRTUAL-RUNTIME_initscripts} \
@@ -33,7 +33,7 @@ SYSVINIT_SCRIPTS = "${@bb.utils.contains('MACHINE_FEATURES',
'rtc', 'busybox-hwc
RDEPENDS_${PN} = "\
base-files \
base-passwd \
-busybox \
+${VIRTUAL-RUNTIME_base-utils} \
${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "${SYSVINIT_SCRIPTS}",
"", d)} \
${@bb.utils.contains("MACHINE_FEATURES", "keyboard",
"${VIRTUAL-RUNTIME_keymaps}", "", d)} \
netbase \
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/3] core-mage-minimal-initramfs: replace dependency
This recipe have a hardcoded dependency to busybox, in order to be able to have
a flexible selection,
instead of the hardcoded dependency,now is point to virtual reference.
Signed-off-by: Alejandro Joya
---
meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
index 1f0fa95..50eca53 100644
--- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
+++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "Small image capable of booting a device. The
kernel includes \
the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \
first 'init' program more efficiently."
-PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install
initramfs-live-install-efi busybox udev base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}"
+PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install
initramfs-live-install-efi virtual/base-utils udev base-passwd
${ROOTFS_BOOTSTRAP_INSTALL}"
# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = ""
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 11/12] waffle: upgrade waffle_1.5.1.bb -> waffle_1.5.2.bb
On Fri, Sep 18, 2015 at 1:21 PM, Burton, Ross wrote:
> Hi Khem,
>
> On 14 September 2015 at 17:31, Khem Raj wrote:
>>
>> .../waffle/{waffle_1.5.1.bb => waffle_1.5.2.bb}| 8 ++--
>
>
> Sorry but you missed the M3 build, can you backport the fixes to 1.5.1
> instead?
>
OK, ignore this one for now then I will queue the new fix with next
lot which is all about fixes and no upgrades
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] gtk+/cairo: enable x11 or directfb
On 16 September 2015 at 11:34, Robert Yang wrote: > Make the world build OK when possible, for example, when no x11 in > DISTRO_FEATURE. > But now you're just explicitly ignoring the directfb DISTRO_FEATURE. Maybe if you want to do a world build without X11 enabled the you should add directfb to DISTRO_FEATURES? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 11/12] waffle: upgrade waffle_1.5.1.bb -> waffle_1.5.2.bb
Hi Khem,
On 14 September 2015 at 17:31, Khem Raj wrote:
> .../waffle/{waffle_1.5.1.bb => waffle_1.5.2.bb}| 8 ++--
>
Sorry but you missed the M3 build, can you backport the fixes to 1.5.1
instead?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] package.bbclass: add summary line to installed-vs-shipped QA check
On Fri, Sep 18, 2015 at 6:14 AM, Martin Jansa wrote: > * there is PN at the beginning, then possibly long list of files and > at the end we don't see which recipe has this issue, add another > line which says which PN and how many files > > Signed-off-by: Martin Jansa > Nice. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] kern-tools: optimize patching peformance
Updating the kern-tools SRCREV to integrat the following commit:
patching: only validate user supplied patches by default
Previously the patching tools would consider both system and user
supplied patches in the same manner .. they are simply a series of
patches to be applied to a branch, and that the scripts should determine
where in the series to start (based on what is already on the
branch).
This detection was causing a few problems:
- time consuming
- starting in the middle of a series when intermediate patches
were merged to a branch.
To solve both the performance and start detection, we instead simply
note the transition from system (i.e. already defined features and
series) and user/recipe supplied patches. When the transition is noted,
the system will start pushing ALL patches without doing autoresume
detection.
Control in keeping the series up to date is passed to the user, and
consistent behaviour/performance is achieved.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 4753094aa40c..27df02ab7a44 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
"file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
DEPENDS = "git-native"
-SRCREV = "bd144d43ca5b1eaf9e727bced4ce3b61b642297c"
+SRCREV = "b7642a7c3f685850ffbb961313e6a593adb05370"
PR = "r12"
PV = "0.2+git${SRCPV}"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] linux-yocto/4.1: aufs, yaffs2 and driver fixes
Updating the 4.1 SRCREVs to integrate the following changes:
f830ab33799d aufs: call mutex.owner only when DEBUG_MUTEXES or
MUTEX_SPIN_ON_OWNER is defined
87df2e93ed65 Bluetooth: Delay check for conn->smp in smp_conn_security()
b09c3eab3e50 cc2520: set the default fifo pin value from platform data
62b01c325d42 fs/yaffs2: Fix a judgement logic for ACL operations
1d19c4e95cfc yaffs2: remove read and write methods
2c822dbc43b9 yaffs2: replace f_dentry to f_path.dentry
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto_4.1.bb | 18 +-
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index 06483c3ee8b9..7265cde3fa83 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -2,8 +2,8 @@ KBRANCH ?= "standard/preempt-rt"
require recipes-kernel/linux/linux-yocto.inc
-SRCREV_machine ?= "59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e"
-SRCREV_meta ?= "429f9e2ff0649b8c9341345622545d874d5e303a"
+SRCREV_machine ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_meta ?= "ef417dc3dbac098e2273b9157bf7ea8b1ade0ec5"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 061205e92088..b0619702f7a1 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.1.6"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine ?= "59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e"
-SRCREV_meta ?= "429f9e2ff0649b8c9341345622545d874d5e303a"
+SRCREV_machine ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_meta ?= "ef417dc3dbac098e2273b9157bf7ea8b1ade0ec5"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index 46d46165b359..d974842810e9 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86 ?= "standard/base"
KBRANCH_qemux86-64 ?= "standard/base"
KBRANCH_qemumips64 ?= "standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "3c1245d162ccb55de1af42bcf3dbf690457bf9e4"
-SRCREV_machine_qemuarm64 ?= "59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e"
-SRCREV_machine_qemumips ?= "4132a691d0908d10b8f07ce7ece02e6dc94e17bc"
-SRCREV_machine_qemuppc ?= "59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e"
-SRCREV_machine_qemux86 ?= "59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e"
-SRCREV_machine_qemux86-64 ?= "59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e"
-SRCREV_machine_qemumips64 ?= "033e1aa633465449edf544eb81adda0caf16ec60"
-SRCREV_machine ?= "59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e"
-SRCREV_meta ?= "429f9e2ff0649b8c9341345622545d874d5e303a"
+SRCREV_machine_qemuarm ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_machine_qemuarm64 ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_machine_qemumips ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_machine_qemuppc ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_machine_qemux86 ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_machine_qemux86-64 ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_machine_qemumips64 ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_machine ?= "f830ab33799d6e0b5433c18c5c6c3c68dce17815"
+SRCREV_meta ?= "ef417dc3dbac098e2273b9157bf7ea8b1ade0ec5"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH};
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] linux-yocto: consolidated pull request
Hi all, It's a rather small 'consolidated' pull request, but there are some other fixes I'm working on that I just couldn't get done in time for this request .. so I'm not going to sit on these two any longer. The changes to 4.1 are patches we've received to fix the build of some filsystems (yaffs2, aufs) for the updated kernel, as well as some bluetooth and driver support changes. Note: the kern-tools update is required for the linux-4.1 update to work The changes to the tools address YOCTO #7282, as well as speeding up the overall patch process. The change is simple, the tools no longer audit the series to ensure that you are building every patch that is referenced in the series. They now only consider patches that are in addition to the changes that are part of the tree's meta data .. i.e. patches that are in the SRC_URI. That removes significant looping and validation, as well unexpected resume points and 'skipped' patches. Cheers, Bruce The following changes since commit 5b4e380b9b4335f4607d78d97345bbbda4c66e0e: bitbake: data_smart: Ensure OVERRIDES dependencies account for contains() (2015-09-18 15:14:04 +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): linux-yocto/4.1: aufs, yaffs2 and driver fixes kern-tools: optimize patching peformance .../recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb| 4 ++-- meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 4 ++-- meta/recipes-kernel/linux/linux-yocto_4.1.bb | 18 +- 4 files changed, 14 insertions(+), 14 deletions(-) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world, Failed tasks 2015-09-13
On 09/18/2015 04:54 AM, Martin Jansa wrote: > On Wed, Aug 26, 2015 at 03:56:04PM +0200, Martin Jansa wrote: >> Time for even more PNBLACKLISTs.. > > And it got even worse. > > This run was built without sstate, so QA issues should be more complete. > I need to update the report script to show new types of QA issues (and some > old ones which weren't parsed before, because they were all fixed). > > While checking qa logs I've noticed that some issues report whole path (so the > same issue is reported multiple times, once for each architecture because of > different WORKDIR - anyone against using path relative to WORKDIR?) and some > check show the name of sanity check on line without any useful information > like > pkgname and installed-not-shipped tests, I'll try to send some fixes or at > least > keep them included in my world builds to get more useful logs. > > OE @ ~/openembedded-core $ git log --oneline origin/master..jansa/master > c3cc2a3 fontcache: allow to pass extra parameters and environment to > fc-cache > a9ab2c3 Fix recursive mode -st on BUILDDIR setup > 3963029 guile, mailx, gcc, opensp, gstreamer1.0-libav, libunwind: > disable thumb where it fails for qemuarm > 70981e4 icu: force arm mode > c0441fd gdb: force arm mode > 07a20f5 DO-NOT-MERGE: distutils3.bbclass: Don't use MACHINE variable > a4e29ea libsdl: Add support for libsdl-native > 0f9eca4 WIP: Add KERNEL_EXTRA_ARGS? > 504d2cb sstate-sysroot-cruft: Add /usr/src/kernel/.* to whitelist > 506990d report-error: Allow to upload reports automatically > 199ec66 qemux86: Add identical qemux86copy variant for tests > > http://www.openembedded.org/wiki/Bitbake_World_Status > > == Failed tasks 2015-09-13 == > > INFO: jenkins-job.sh-1.3.1 Complete log available at > http://logs.nslu2-linux.org/buildlogs/oe/world/log.report.20150915_163214.log > > === common (23) === > * /meta-openembedded/meta-efl/recipes-efl/efl/azy_svn.bb, do_compile > * /meta-openembedded/meta-efl/recipes-efl/efl/epdf_svn.bb, do_compile > * > /meta-openembedded/meta-gnome/recipes-gnome/epiphany/epiphany_2.30.6.bb, > do_fetch > * > /meta-openembedded/meta-gnome/recipes-gnome/gnome-power-manager/gnome-power-manager_2.32.0.bb, > do_compile > * > /meta-openembedded/meta-gnome/recipes-gnome/nautilus/nautilus3_3.2.1.bb, > do_configure > * > /meta-openembedded/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb, > do_compile > * > /meta-openembedded/meta-multimedia/recipes-mkv/mkvtoolnix/mkvtoolnix_git.bb, > do_compile > * > /meta-openembedded/meta-multimedia/recipes-multimedia/musicpd/mpd_0.19.1.bb, > do_compile > * /meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_2.2.1.bb, > do_compile > * > /meta-openembedded/meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb, > do_patch > * > /meta-openembedded/meta-networking/recipes-daemons/lldpad/lldpad_0.9.46.bb, > do_compile > * > /meta-openembedded/meta-networking/recipes-support/sshguard/sshguard_git.bb, > do_compile > * > /meta-openembedded/meta-oe/recipes-benchmark/tiobench/tiobench_0.3.3.bb, > do_compile > * > /meta-openembedded/meta-oe/recipes-connectivity/libimobiledevice/libimobiledevice_1.1.4.bb, > do_compile > * > /meta-openembedded/meta-oe/recipes-devtools/packagekit/packagekit_0.5.6.bb, > do_compile > * /meta-openembedded/meta-oe/recipes-extended/libuio/libuio_0.2.1.bb, > do_compile > * /meta-openembedded/meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb, > do_compile > * /meta-openembedded/meta-oe/recipes-graphics/xorg-app/sessreg_1.1.0.bb, > do_compile > * /meta-openembedded/meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb, > do_compile > * /meta-openembedded/meta-oe/recipes-navigation/gdal/gdal_1.11.1.bb, > do_compile > * > /meta-openembedded/meta-oe/recipes-support/libdbi/libdbi-drivers_0.8.3-1.bb, > do_compile > * > /meta-openembedded/meta-perl/recipes-perl/libnet/libnet-dns-perl_0.81.bb, > do_configure > * > /meta-webos-ports/meta-luneui/recipes-webos/luna-service2/luna-service2.bb, > do_compile > > === common-x86 (2) === > * /meta-browser/recipes-browser/chromium/chromium_40.0.2214.91.bb, > do_compile > * /meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_1.11.0.bb, > do_compile > > === qemuarm (5) === > * /meta-openembedded/meta-oe/recipes-extended/efivar/efivar_git.bb, > do_compile > * /meta-openembedded/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb, > do_compile > * /meta-openembedded/meta-oe/recipes-qt/qt-creator/qt-creator_2.8.1.bb, > do_compile > * /openembedded-core/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb, do_compile > * /openembedded-core/meta/recipes-support/libunwind/libunwind_1.1.bb, > do_compile > > === qemux86 (9) === > * /meta-browser/recipes-browser/chromium/cef3_280796.bb, do_compile > * > /meta-openembedded/meta-networking/recipes-extended/iscsitarget/iscsitarget_1.4.20.3+svn502.bb, >
Re: [OE-core] [PATCH 3/3] prserv/db: Use DELETE instead of WAL journal mode
On 09/18/2015 11:42 AM, Leonardo Sandoval wrote:
On 09/17/2015 03:01 PM, Burton, Ross wrote:
On 15 September 2015 at 15:59,
wrote:
-self.connection.execute("PRAGMA journal_mode = WAL;")
+self.connection.execute("PRAGMA journal_mode = DELETE;")
Richard probably has a better memory than me but I seem to recall that
WAL
was a pretty serious speed improvement for the local host case. Did you
benchmark the impact this change has?
Unfortunately, I didn't do any benchmark.
The problem with WAL is the following "All processes using a database
must be on the same host computer; WAL does not work over a network
filesystem." Using WAL, all PR values get lost after a PR server reboot,
so we need a rollback journal. According to the documentation, the
fastest of the these is "MEMORY" but it has its pros/cons:
"The MEMORY journaling mode stores the rollback journal in volatile RAM.
This saves disk I/O but at the expense of database safety and integrity.
If the application using SQLite crashes in the middle of a transaction
when the MEMORY journaling mode is set, then the database file will very
likely go corrupt."
Ross: ignore my comment. The limitation "all process using a database
must be on the same host" is not a limitation for us, because the
PRserver is the only one talking to the database and this daemon/process
is at the same place as the DB. So the root reason why WAL is not
working is still unknown. Sending a V2 soon.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
Martin, Randy et.al.: I'm moving around things such that I can give Martin a full builder: 24Cores, 256GB RAM, up to 3TB storage from the donation that HP made to WebOS-Ports (as I consider it essential to webOS-Ports that OE has a strong foundation) Tom On Fri, Sep 18, 2015 at 10:30 AM, Martin Jansa wrote: > On Fri, Sep 18, 2015 at 12:24:00PM -0400, Randy MacLeod wrote: > > On 2015-09-07 11:14 AM, Martin Jansa wrote: > > > Full jenkins build test takes over 3 days (depending on sstate reuse, > > > one MACHINE can take more than 24 hours), so if I add them to > > > master-next after it's merged to oe-core it will take 3-6 days to > > > build-test them (6 days if they are sent just after current queue is > > > sent for build). > > > > Hi Martin, > > Hi Randy, > > > Replying privately but you can add the list back in your > > reply if you like. > > OK, adding both MLs > > > I never build all of meta-oe but a day seems like a long time. > > On a 3-4 year old 24 core system, with 64 GB RAM and > > 2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in > > 5 hours using 18.3 of the 24 cores on average. > > What are the specs of your build machine? > > It's one of VMs running on box donated by HP to webos-ports project. It > has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO > which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G > RAM, so I'm using 72G for tmpfs. > > Tom: please fill-in the gaps, I don't know any details about the real HW > it's running on. > > The same machine is also running some webos-ports builds sometimes. > > BUT be aware that my world build is much bigger than what you're > probably building and changes in oe-core almost always ensure very low > sstate reuse. > > e.g. last build with only small oe-core upgrade since previous build: > NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be > rerun and 33 failed. > NOTE: Build completion summary: > NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) > NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) > NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) > NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) > NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) > NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch) > > real1485m40.070s > user4166m49.125s > sys 2825m50.068s > > BTW: you can see all this information in the world logs I'm sending to MLs > (but not all the builds make it to ML report). > > > A decent build box these days has 32+ cores, 64+ GB RAM and > > and SSD or RAID disk filesystem. The costs of such a system > > are significant but worth it given the number of people's time > > involved in meta-oe. > > That's true, but I have to do with what I have available :). > > > Also, it would be nice if OE had a few such machines each > > working on builds for a MACHINE to reduce your turn-around > > to more like a day or so. :) > > Yes, it would be nice, I'm trying to get Tom King to set another VM like > this in another location (another HP donated server), hopefully he will > finish it soon. > > It's all hosted together with OE infrastructure, bandwidth is limited, but > all I need for these builds is to fetch sources and upload the logs, there > are no package feeds or sstate from these builds usable outside, but now it > rsync the downloaded sources to sources.openembedded.org > > If you know about some idling build servers, I would like to give them > something to do :). > > Regards, > > -- > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
On Fri, Sep 18, 2015 at 11:38:30AM -0600, Gary Thomas wrote: > On 2015-09-18 11:30, Martin Jansa wrote: > > On Fri, Sep 18, 2015 at 12:24:00PM -0400, Randy MacLeod wrote: > >> On 2015-09-07 11:14 AM, Martin Jansa wrote: > >>> Full jenkins build test takes over 3 days (depending on sstate reuse, > >>> one MACHINE can take more than 24 hours), so if I add them to > >>> master-next after it's merged to oe-core it will take 3-6 days to > >>> build-test them (6 days if they are sent just after current queue is > >>> sent for build). > >> > >> Hi Martin, > > > > Hi Randy, > > > >> Replying privately but you can add the list back in your > >> reply if you like. > > > > OK, adding both MLs > > > >> I never build all of meta-oe but a day seems like a long time. > >> On a 3-4 year old 24 core system, with 64 GB RAM and > >> 2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in > >> 5 hours using 18.3 of the 24 cores on average. > >> What are the specs of your build machine? > > > > It's one of VMs running on box donated by HP to webos-ports project. It > > has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO > > which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G > > RAM, so I'm using 72G for tmpfs. > > > > Tom: please fill-in the gaps, I don't know any details about the real HW > > it's running on. > > > > The same machine is also running some webos-ports builds sometimes. > > > > BUT be aware that my world build is much bigger than what you're > > probably building and changes in oe-core almost always ensure very low > > sstate reuse. > > > > e.g. last build with only small oe-core upgrade since previous build: > > NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be > > rerun and 33 failed. > > NOTE: Build completion summary: > > NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) > > NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) > > NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) > > NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) > > NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) > > NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch) > > (slightly off topic): How did you get this report? inherit buildstats-summary > > real1485m40.070s > > user4166m49.125s > > sys 2825m50.068s > > > > BTW: you can see all this information in the world logs I'm sending to MLs > > (but not all the builds make it to ML report). > > > >> A decent build box these days has 32+ cores, 64+ GB RAM and > >> and SSD or RAID disk filesystem. The costs of such a system > >> are significant but worth it given the number of people's time > >> involved in meta-oe. > > > > That's true, but I have to do with what I have available :). > > > >> Also, it would be nice if OE had a few such machines each > >> working on builds for a MACHINE to reduce your turn-around > >> to more like a day or so. :) > > > > Yes, it would be nice, I'm trying to get Tom King to set another VM like > > this in another location (another HP donated server), hopefully he will > > finish it soon. > > > > It's all hosted together with OE infrastructure, bandwidth is limited, but > > all I need for these builds is to fetch sources and upload the logs, there > > are no package feeds or sstate from these builds usable outside, but now it > > rsync the downloaded sources to sources.openembedded.org > > > > If you know about some idling build servers, I would like to give them > > something to do :). > > > > Regards, > > > > > > > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Dynamic common utilities
On Fri, Sep 18, 2015 at 12:44 PM, Mark Hatle wrote: > On 9/18/15 4:35 AM, Jack Mitchell wrote: >> On 17/09/15 17:20, Alejandro Joya wrote: >>> It provide a virtual reference for the common utilities. >>> it replace of the lock to busybox, it will be simple exchange between other >>> common utilities like gnu core utils or toybox among others. >>> >>> In order to enable its required to fill at the distro conf or local.conf >>> >>> VIRTUAL-RUNTIME_login_manager ?= "busybox" >>> PREFERRED_PROVIDER_virtual/anybox ?= "busybox" >>> PREFERRED_RPROVIDER_virtual/anybox ?= "busybox" >>> VIRTUAL-RUNTIME_anybox ?= "busybox" >>> VIRTUAL-RUNTIME_anybox-hwclock ?= "busybox-hwclock" >>> >>> The following changes since commit f0189829498e30231d826c9f55aad73e622d076e: >>> >>>qemu: Update to upstream patches (2015-09-14 11:22:02 +0100) >>> >>> are available in the git repository at: >>> >>>git://github.com/Ajoyacr/openembedded-core anybox >>>https://github.com/Ajoyacr/openembedded-core/tree/anybox >>> >>> Alejandro Joya (3): >>>core-mage-minimal-initramfs: overwrite hardcoded dependency to virtual >>> reference >>>initramfs-framework: overwrite hardcoded dependency to virtual >>> reference >>>packagegroup-core-boot: overwrite hardcoded dependency to virtual >>> reference >>> >>> meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +- >>> meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 2 +- >>> meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 6 +++--- >>> 3 files changed, 5 insertions(+), 5 deletions(-) >>> >> >> is 'anybox' a good name for the virtual provider? What happens if we have a >> new >> suite of core utility replacements without box in the name, I assume it will >> be >> a nightmare to retroactivly change the name so we should probably come up >> with a >> more generic one now. virtual/core-utils, virtual/base-utils? > > Personally I like this better -- however, I think we're "too late" in the > current development cycle to do it.. but for the next cycle, we should > certainly consider going through the system and doing this instead. > > (It will definitely make it easier in the future to get rid of a "box" based > system if desired.) Agreed; this should be postponed for 2.1 and than we come up with a proper virtual name when revisiting this patchset. -- 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
Re: [OE-core] [PATCH 1/1] qt4: remove already merged patch
On Fri, Sep 18, 2015 at 11:16 AM, Paul Eggleton wrote: > This patch was merged into the 4.8.7 release. This was missed on > upgrade, and we didn't notice because our quilt-based patch handling > code ignores already-applied patches. > > Signed-off-by: Paul Eggleton Acked-by: Otavio Salvador -- 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
Re: [OE-core] [PATCH 2/2] initramfs-framework: better error reporting for invalid root boot parameter
On Fri, Sep 18, 2015 at 8:49 AM, Patrick Ohly wrote: > When the "boot" parameter refers to a non-existent device, the only > visible output at normal log levels was a rather confusing: >ERROR: There's no '/dev' on rootfs. > > That's because the actual error, not being able to find the root > device, was only a debug message, which gets ignored in the default > mode. > > Promoting the "root '$bootparam_root' doesn't exist." message from > "debug" to "msg" gives sufficient context to understand the error. A > more intrusive change would be to change also the control flow. > > Signed-off-by: Patrick Ohly Acked-by: Otavio Salvador -- 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
Re: [OE-core] [PATCH 1/2] initramfs-framework: fix "support dropping into shell on failure"
On Fri, Sep 18, 2015 at 8:49 AM, Patrick Ohly wrote: > Due to a missing $ before the variable name, all fatal errors ended up > invoking a shell, instead of only doing that when init_fatal_sh is set > as boot parameter. > > Signed-off-by: Patrick Ohly Acked-by: Otavio Salvador -- 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
Re: [OE-core] World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
On 2015-09-18 11:30, Martin Jansa wrote: On Fri, Sep 18, 2015 at 12:24:00PM -0400, Randy MacLeod wrote: On 2015-09-07 11:14 AM, Martin Jansa wrote: Full jenkins build test takes over 3 days (depending on sstate reuse, one MACHINE can take more than 24 hours), so if I add them to master-next after it's merged to oe-core it will take 3-6 days to build-test them (6 days if they are sent just after current queue is sent for build). Hi Martin, Hi Randy, Replying privately but you can add the list back in your reply if you like. OK, adding both MLs I never build all of meta-oe but a day seems like a long time. On a 3-4 year old 24 core system, with 64 GB RAM and 2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in 5 hours using 18.3 of the 24 cores on average. What are the specs of your build machine? It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs. Tom: please fill-in the gaps, I don't know any details about the real HW it's running on. The same machine is also running some webos-ports builds sometimes. BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse. e.g. last build with only small oe-core upgrade since previous build: NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed. NOTE: Build completion summary: NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch) (slightly off topic): How did you get this report? real1485m40.070s user4166m49.125s sys 2825m50.068s BTW: you can see all this information in the world logs I'm sending to MLs (but not all the builds make it to ML report). A decent build box these days has 32+ cores, 64+ GB RAM and and SSD or RAID disk filesystem. The costs of such a system are significant but worth it given the number of people's time involved in meta-oe. That's true, but I have to do with what I have available :). Also, it would be nice if OE had a few such machines each working on builds for a MACHINE to reduce your turn-around to more like a day or so. :) Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon. It's all hosted together with OE infrastructure, bandwidth is limited, but all I need for these builds is to fetch sources and upload the logs, there are no package feeds or sstate from these builds usable outside, but now it rsync the downloaded sources to sources.openembedded.org If you know about some idling build servers, I would like to give them something to do :). Regards, -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] World builds HW Was: [PATCH 04/12] gnome-icon-theme: remove the recipe
On Fri, Sep 18, 2015 at 12:24:00PM -0400, Randy MacLeod wrote: > On 2015-09-07 11:14 AM, Martin Jansa wrote: > > Full jenkins build test takes over 3 days (depending on sstate reuse, > > one MACHINE can take more than 24 hours), so if I add them to > > master-next after it's merged to oe-core it will take 3-6 days to > > build-test them (6 days if they are sent just after current queue is > > sent for build). > > Hi Martin, Hi Randy, > Replying privately but you can add the list back in your > reply if you like. OK, adding both MLs > I never build all of meta-oe but a day seems like a long time. > On a 3-4 year old 24 core system, with 64 GB RAM and > 2 large disks, I build oe-core + a whitelist of meta-oe + misc layers in > 5 hours using 18.3 of the 24 cores on average. > What are the specs of your build machine? It's one of VMs running on box donated by HP to webos-ports project. It has access to 8 E5-2630L 0 @ 2.00GHz cores (from IIRC 24) and slow IO which we try to compensate a bit by using tmpfs for TMPDIR, VM has 80G RAM, so I'm using 72G for tmpfs. Tom: please fill-in the gaps, I don't know any details about the real HW it's running on. The same machine is also running some webos-ports builds sometimes. BUT be aware that my world build is much bigger than what you're probably building and changes in oe-core almost always ensure very low sstate reuse. e.g. last build with only small oe-core upgrade since previous build: NOTE: Tasks Summary: Attempted 33283 tasks of which 5252 didn't need to be rerun and 33 failed. NOTE: Build completion summary: NOTE: do_populate_sysroot: 21% sstate reuse (485 setscene, 1750 scratch) NOTE: do_package_qa: 12% sstate reuse (262 setscene, 1760 scratch) NOTE: do_package: 4% sstate reuse (76 setscene, 1750 scratch) NOTE: do_packagedata: 13% sstate reuse (281 setscene, 1750 scratch) NOTE: do_package_write_ipk: 12% sstate reuse (262 setscene, 1756 scratch) NOTE: do_populate_lic: 22% sstate reuse (521 setscene, 1806 scratch) real1485m40.070s user4166m49.125s sys 2825m50.068s BTW: you can see all this information in the world logs I'm sending to MLs (but not all the builds make it to ML report). > A decent build box these days has 32+ cores, 64+ GB RAM and > and SSD or RAID disk filesystem. The costs of such a system > are significant but worth it given the number of people's time > involved in meta-oe. That's true, but I have to do with what I have available :). > Also, it would be nice if OE had a few such machines each > working on builds for a MACHINE to reduce your turn-around > to more like a day or so. :) Yes, it would be nice, I'm trying to get Tom King to set another VM like this in another location (another HP donated server), hopefully he will finish it soon. It's all hosted together with OE infrastructure, bandwidth is limited, but all I need for these builds is to fetch sources and upload the logs, there are no package feeds or sstate from these builds usable outside, but now it rsync the downloaded sources to sources.openembedded.org If you know about some idling build servers, I would like to give them something to do :). Regards, -- 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 2/3] prserv/serv.py: Better messaging when starting/stopping the server with port=0
On 09/17/2015 03:01 PM, Burton, Ross wrote:
On 15 September 2015 at 15:59,
wrote:
+sys.stderr.write("WARNING: Server is listening at port %s instead
of %s\n"
+ % (rport,port))
I wouldn't call this a warning: port=0 means "pick your own", so it's not a
warning that a different port was changed, it's useful information.
I add the WARNING string so user notices the new port taken. This info
is important when trying to stop the server, but you are right, is not a
warning, it should be just an info. Sending V2 right now.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] prserv/db: Use DELETE instead of WAL journal mode
On 09/17/2015 03:01 PM, Burton, Ross wrote:
On 15 September 2015 at 15:59,
wrote:
-self.connection.execute("PRAGMA journal_mode = WAL;")
+self.connection.execute("PRAGMA journal_mode = DELETE;")
Richard probably has a better memory than me but I seem to recall that WAL
was a pretty serious speed improvement for the local host case. Did you
benchmark the impact this change has?
Unfortunately, I didn't do any benchmark.
The problem with WAL is the following "All processes using a database
must be on the same host computer; WAL does not work over a network
filesystem." Using WAL, all PR values get lost after a PR server reboot,
so we need a rollback journal. According to the documentation, the
fastest of the these is "MEMORY" but it has its pros/cons:
"The MEMORY journaling mode stores the rollback journal in volatile RAM.
This saves disk I/O but at the expense of database safety and integrity.
If the application using SQLite crashes in the middle of a transaction
when the MEMORY journaling mode is set, then the database file will very
likely go corrupt."
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] selftest/buildoptions: pexpect not a builtin module
put the import of pexpect around a try statement so it can tell you
why it failed to import when in a system that has the module unreachable
the message that outputs is:
"No module named pexpect, import failed"
"Please install pexpect (python-pexpect)"
Signed-off-by: Benjamin Esquivel
---
meta/lib/oeqa/selftest/buildoptions.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/buildoptions.py
b/meta/lib/oeqa/selftest/buildoptions.py
index 483803b..1fa4802 100644
--- a/meta/lib/oeqa/selftest/buildoptions.py
+++ b/meta/lib/oeqa/selftest/buildoptions.py
@@ -3,7 +3,14 @@ import os
import logging
import re
import glob as g
-import pexpect as p
+
+try:
+import pexpect as p
+except ImportError as e:
+import sys
+sys.stderr.write("{}, import failed\n".format(e))
+sys.stderr.write("Please install pexpect (python-pexpect)\n")
+raise e
from oeqa.selftest.base import oeSelfTest
from oeqa.selftest.buildhistory import BuildhistoryBase
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] selftest/buildoptions: pexpect not a builtin module
On Fri, 2015-09-18 at 12:05 +0100, Burton, Ross wrote: > > On 17 September 2015 at 21:38, Benjamin Esquivel < > benjamin.esqui...@linux.intel.com> wrote: > > put the import of pexpect around a try statement so it can tell you > > why it failed to import when in a system that has the module > > unreachable > > > As the failing import is throwing an exception, can't the calling > code display the exception correctly? This is the logging without the change: 2015-09-18 08:27:44,233 - selftest - INFO - Loading tests from: oeqa.selftest.buildhistory 2015-09-18 08:27:44,234 - selftest - INFO - Loading tests from: oeqa.selftest.buildoptions 2015-09-18 08:27:44,236 - selftest - ERROR - Failed to import oeqa.selftest.buildoptions 2015-09-18 08:27:44,236 - selftest - ERROR - 'module' object has no attribute 'buildoptions' This is the logging with the proposed change and including Paul's comment: 2015-09-18 08:27:44,233 - selftest - INFO - Loading tests from: oeqa.selftest.buildhistory 2015-09-18 08:27:44,234 - selftest - INFO - Loading tests from: oeqa.selftest.buildoptions No module named pexpect, import failed Please install pexpect (python-pexpect) 2015-09-18 08:27:44,236 - selftest - ERROR - Failed to import oeqa.selftest.buildoptions 2015-09-18 08:27:44,236 - selftest - ERROR - 'module' object has no attribute 'buildoptions' I'm sending the patch V2 > > Ross > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Dynamic common utilities
On 9/18/15 4:35 AM, Jack Mitchell wrote: > On 17/09/15 17:20, Alejandro Joya wrote: >> It provide a virtual reference for the common utilities. >> it replace of the lock to busybox, it will be simple exchange between other >> common utilities like gnu core utils or toybox among others. >> >> In order to enable its required to fill at the distro conf or local.conf >> >> VIRTUAL-RUNTIME_login_manager ?= "busybox" >> PREFERRED_PROVIDER_virtual/anybox ?= "busybox" >> PREFERRED_RPROVIDER_virtual/anybox ?= "busybox" >> VIRTUAL-RUNTIME_anybox ?= "busybox" >> VIRTUAL-RUNTIME_anybox-hwclock ?= "busybox-hwclock" >> >> The following changes since commit f0189829498e30231d826c9f55aad73e622d076e: >> >>qemu: Update to upstream patches (2015-09-14 11:22:02 +0100) >> >> are available in the git repository at: >> >>git://github.com/Ajoyacr/openembedded-core anybox >>https://github.com/Ajoyacr/openembedded-core/tree/anybox >> >> Alejandro Joya (3): >>core-mage-minimal-initramfs: overwrite hardcoded dependency to virtual >> reference >>initramfs-framework: overwrite hardcoded dependency to virtual >> reference >>packagegroup-core-boot: overwrite hardcoded dependency to virtual >> reference >> >> meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +- >> meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 2 +- >> meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 6 +++--- >> 3 files changed, 5 insertions(+), 5 deletions(-) >> > > is 'anybox' a good name for the virtual provider? What happens if we have a > new > suite of core utility replacements without box in the name, I assume it will > be > a nightmare to retroactivly change the name so we should probably come up > with a > more generic one now. virtual/core-utils, virtual/base-utils? Personally I like this better -- however, I think we're "too late" in the current development cycle to do it.. but for the next cycle, we should certainly consider going through the system and doing this instead. (It will definitely make it easier in the future to get rid of a "box" based system if desired.) --Mark > Cheers, > Jack. > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW38
Current Dev Position: YP 2.0 Final Next Deadline: 2.0 Cut off: Sept. 28, 2015 noon GMT SWAT team rotation: Saul -> Paul https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * The Milestone M3 release is now undergoing QA * The M3 build was not clean, there were a further three failures which had never been encountered before. These have bug entries and we're continuing to work through them as fast as we can. * Issues were found in the datastore around override expansion, particularly in multilib configurations. Patches have merged to address this. * There is risk to the 2.0 release date unless we can get these failures under control. * The project is now feature frozen as we move towards the 2.0 release. All enhancements now will be pushed YP 2.1. * * Reminder: We have renamed YP 1.9 to YP 2.0. * The current version that is in development will launch as YP 2.0 in October, 2015. * The release name for YP 2.0 is 'jethro'. Key YP 1.9/2.0 Dates: YP 2.0 Final - 2.0 Cut off: Sept. 28, 2015 noon GMT YP 2.0 final Release Target: Before Oct. 30, 2015 Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features Tracking Metrics: WDD 2151 (last week 2154 ) (https://wiki.yoctoproject.org/charts/combo.html) [If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Dynamic common utilities
On Fri, Sep 18, 2015 at 2:35 AM, Jack Mitchell wrote: > is 'anybox' a good name for the virtual provider? What happens if we have a > new suite of core utility replacements without box in the name, I assume it > will be a nightmare to retroactivly change the name so we should probably > come up with a more generic one now. virtual/core-utils, virtual/base-utils? I think thats a fair point. I think virtual/busybox could be another option but it might confuse some people seeing the word busybox virtual/core-utilities will make it sufficiently not confuse with coreutils. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 1/3] insane.bbclass: show PN and relative path in package_qa_check_host_user
* show PN as other QA checks
* strip PKGDEST prefix from shown path as other QA checks
Signed-off-by: Martin Jansa
---
meta/classes/insane.bbclass | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5c8629a..c984fae 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -980,6 +980,7 @@ def package_qa_check_host_user(path, name, d, elf,
messages):
return
dest = d.getVar('PKGDEST', True)
+pn = d.getVar('PN', True)
home = os.path.join(dest, 'home')
if path == home or path.startswith(home + os.sep):
return
@@ -991,14 +992,15 @@ def package_qa_check_host_user(path, name, d, elf,
messages):
if exc.errno != errno.ENOENT:
raise
else:
+rootfs_path = path[len(dest):]
check_uid = int(d.getVar('HOST_USER_UID', True))
if stat.st_uid == check_uid:
-messages["host-user-contaminated"] = "%s is owned by uid %d, which
is the same as the user running bitbake. This may be due to host contamination"
% (path, check_uid)
+messages["host-user-contaminated"] = "%s: %s is owned by uid %d,
which is the same as the user running bitbake. This may be due to host
contamination" % (pn, rootfs_path, check_uid)
return False
check_gid = int(d.getVar('HOST_USER_GID', True))
if stat.st_gid == check_gid:
-messages["host-user-contaminated"] = "%s is owned by gid %d, which
is the same as the user running bitbake. This may be due to host contamination"
% (path, check_gid)
+messages["host-user-contaminated"] = "%s: %s is owned by gid %d,
which is the same as the user running bitbake. This may be due to host
contamination" % (pn, rootfs_path, check_gid)
return False
return True
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] insane.bbclass: show PN and relative path in package_qa_check_host_user
On Fri, Sep 18, 2015 at 03:41:47PM +0200, Mike Looijmans wrote:
> On 18-09-15 15:14, Martin Jansa wrote:
> > * show PN as other QA checks
> > * strip PKGDEST prefix from shown path as other QA checks
> >
> > Signed-off-by: Martin Jansa
> > ---
> > meta/classes/insane.bbclass | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> > index 5c8629a..a35e546 100644
> > --- a/meta/classes/insane.bbclass
> > +++ b/meta/classes/insane.bbclass
> > @@ -980,6 +980,7 @@ def package_qa_check_host_user(path, name, d, elf,
> > messages):
> > return
> >
> > dest = d.getVar('PKGDEST', True)
> > +pn = d.getVar('PN', True)
> > home = os.path.join(dest, 'home')
> > if path == home or path.startswith(home + os.sep):
> > return
> > @@ -991,14 +992,15 @@ def package_qa_check_host_user(path, name, d, elf,
> > messages):
> > if exc.errno != errno.ENOENT:
> > raise
> > else:
> > +rootfs_path = path[len(dest):]
> > check_uid = int(d.getVar('HOST_USER_UID', True))
> > if stat.st_uid == check_uid:
> > -messages["host-user-contaminated"] = "%s is owned by uid %d,
> > which is the same as the user running bitbake. This may be due to host
> > contamination" % (path, check_uid)
> > +messages["host-user-contaminated"] = "%s: %s is owned by uid
> > %d, which is the same as the user running bitbake. This may be due to host
> > contamination" % (pn, rootfs_path, check_uid)
> > return False
> >
> > check_gid = int(d.getVar('HOST_USER_GID', True))
> > if stat.st_gid == check_gid:
> > -messages["host-user-contaminated"] = "%s is owned by gid %d,
> > which is the same as the user running bitbake. This may be due to host
> > contamination" % (path, check_gid)
> > +messages["host-user-contaminated"] = "$s: %s is owned by gid
> > %d, which is the same as the user running bitbake. This may be due to host
> > contamination" % (pn, rootfs_path, check_gid)
>
> I think "$s" is a typo (that will lead to a Python exception).
You're right, but doesn't lead to python exception here
even the pn was printed out in my test build with this, e.g.:
NOTE: recipe e-wm-0.18.8-r0: task do_package_qa: Started
WARNING: QA Issue: e-wm:
/e-wm-dbg/usr/src/debug/e-wm/0.18.8-r0/build/src/bin/e_fm_shared_types.h is
owned by uid 1026, which is the same as the user running bitbake. This may be
due to host contamination [host-user-contaminated]
NOTE: recipe e-wm-0.18.8-r0: task do_package_qa: Succeeded
But v2 comming with %s. Thanks
--
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
[OE-core] [PATCH 0/1] Remove already merged patch
The following changes since commit 72682d72b52355c3fed947167ca3c6064340ead1:
autotools.bbclass: mkdir ${B} -> mkdir -p ${B} (2015-09-16 22:17:19 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib
paule/qt4-remove-merged-patch
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt4-remove-merged-patch
Paul Eggleton (1):
qt4: remove already merged patch
meta/recipes-qt/qt4/qt4-4.8.7.inc | 1 -
.../0028-Don-t-crash-on-broken-GIF-images.patch| 47 --
2 files changed, 48 deletions(-)
delete mode 100644
meta/recipes-qt/qt4/qt4-4.8.7/0028-Don-t-crash-on-broken-GIF-images.patch
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] qt4: remove already merged patch
This patch was merged into the 4.8.7 release. This was missed on
upgrade, and we didn't notice because our quilt-based patch handling
code ignores already-applied patches.
Signed-off-by: Paul Eggleton
---
meta/recipes-qt/qt4/qt4-4.8.7.inc | 1 -
.../0028-Don-t-crash-on-broken-GIF-images.patch| 47 --
2 files changed, 48 deletions(-)
delete mode 100644
meta/recipes-qt/qt4/qt4-4.8.7/0028-Don-t-crash-on-broken-GIF-images.patch
diff --git a/meta/recipes-qt/qt4/qt4-4.8.7.inc
b/meta/recipes-qt/qt4/qt4-4.8.7.inc
index 5257e76..10f87a7 100644
--- a/meta/recipes-qt/qt4/qt4-4.8.7.inc
+++ b/meta/recipes-qt/qt4/qt4-4.8.7.inc
@@ -21,7 +21,6 @@ SRC_URI =
"http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever
file://0018-configure-make-pulseaudio-a-configurable-option.patch \
file://0019-Fixes-for-gcc-4.7.0-particularly-on-qemux86.patch \
file://0027-tools.pro-disable-qmeegographicssystemhelper.patch \
- file://0028-Don-t-crash-on-broken-GIF-images.patch \
file://0030-aarch64_arm64_qatomic_support.patch \
file://0031-aarch64_arm64_mkspecs.patch \
file://0032-aarch64_add_header.patch \
diff --git
a/meta/recipes-qt/qt4/qt4-4.8.7/0028-Don-t-crash-on-broken-GIF-images.patch
b/meta/recipes-qt/qt4/qt4-4.8.7/0028-Don-t-crash-on-broken-GIF-images.patch
deleted file mode 100644
index 906e2fd..000
--- a/meta/recipes-qt/qt4/qt4-4.8.7/0028-Don-t-crash-on-broken-GIF-images.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From f1b76c126c476c155af8c404b97c42cd1a709333 Mon Sep 17 00:00:00 2001
-From: Lars Knoll
-Date: Thu, 24 Apr 2014 15:33:27 +0200
-Subject: [PATCH] Don't crash on broken GIF images
-
-Broken GIF images could set invalid width and height
-values inside the image, leading to Qt creating a null
-QImage for it. In that case we need to abort decoding
-the image and return an error.
-
-Initial patch by Rich Moore.
-
-Backport of Id82a4036f478bd6e49c402d6598f57e7e5bb5e1e from Qt 5
-
-Task-number: QTBUG-38367
-Change-Id: I0680740018aaa8356d267b7af3f01fac3697312a
-Security-advisory: CVE-2014-0190
-Reviewed-by: Richard J. Moore
-
-Upstream-Status: Backport
-Signed-off-by: Paul Eggleton
-
- src/gui/image/qgifhandler.cpp | 7 +++
- 1 file changed, 7 insertions(+)
-
-diff --git a/src/gui/image/qgifhandler.cpp b/src/gui/image/qgifhandler.cpp
-index 3324f04..5199dd3 100644
a/src/gui/image/qgifhandler.cpp
-+++ b/src/gui/image/qgifhandler.cpp
-@@ -359,6 +359,13 @@ int QGIFFormat::decode(QImage *image, const uchar
*buffer, int length,
- memset(bits, 0, image->byteCount());
- }
-
-+// Check if the previous attempt to create the image failed.
If it
-+// did then the image is broken and we should give up.
-+if (image->isNull()) {
-+state = Error;
-+return -1;
-+}
-+
- disposePrevious(image);
- disposed = false;
-
---
-1.9.3
-
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: remove redundant libx11 DEPENDS line
Hi Richard, On Friday 18 September 2015 14:32:13 Richard Purdie wrote: > On Fri, 2015-09-18 at 13:51 +0200, Carlos Rafael Giani wrote: > > The x11 packageconfig already takes care of the X11 dependency, and also > > respects the DISTRO_FEATURES > > > > Signed-off-by: Carlos Rafael Giani > > --- > > > > meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb > > b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb index > > 07c2dce..bdf173a 100644 > > --- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb > > +++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb > > @@ -9,7 +9,6 @@ LIC_FILES_CHKSUM = > > "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7 \> > > SECTION = "libs" > > > > DEPENDS = "glib-2.0" > > > > -DEPENDS_append_linuxstdbase = " virtual/libx11" > > Do we not need something like: > > PACKAGECONFIG_append_linuxstdbase = "x11" > > to ensure that this is enabled for LSB? The recipe already does something like this further down. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] insane.bbclass: show PN and relative path in package_qa_check_host_user
On 18-09-15 15:14, Martin Jansa wrote:
* show PN as other QA checks
* strip PKGDEST prefix from shown path as other QA checks
Signed-off-by: Martin Jansa
---
meta/classes/insane.bbclass | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5c8629a..a35e546 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -980,6 +980,7 @@ def package_qa_check_host_user(path, name, d, elf,
messages):
return
dest = d.getVar('PKGDEST', True)
+pn = d.getVar('PN', True)
home = os.path.join(dest, 'home')
if path == home or path.startswith(home + os.sep):
return
@@ -991,14 +992,15 @@ def package_qa_check_host_user(path, name, d, elf,
messages):
if exc.errno != errno.ENOENT:
raise
else:
+rootfs_path = path[len(dest):]
check_uid = int(d.getVar('HOST_USER_UID', True))
if stat.st_uid == check_uid:
-messages["host-user-contaminated"] = "%s is owned by uid %d, which is
the same as the user running bitbake. This may be due to host contamination" % (path,
check_uid)
+messages["host-user-contaminated"] = "%s: %s is owned by uid %d, which
is the same as the user running bitbake. This may be due to host contamination" % (pn,
rootfs_path, check_uid)
return False
check_gid = int(d.getVar('HOST_USER_GID', True))
if stat.st_gid == check_gid:
-messages["host-user-contaminated"] = "%s is owned by gid %d, which is
the same as the user running bitbake. This may be due to host contamination" % (path,
check_gid)
+messages["host-user-contaminated"] = "$s: %s is owned by gid %d, which
is the same as the user running bitbake. This may be due to host contamination" % (pn,
rootfs_path, check_gid)
I think "$s" is a typo (that will lead to a Python exception).
return False
return True
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: remove redundant libx11 DEPENDS line
On Fri, 2015-09-18 at 13:51 +0200, Carlos Rafael Giani wrote: > The x11 packageconfig already takes care of the X11 dependency, and also > respects the DISTRO_FEATURES > > Signed-off-by: Carlos Rafael Giani > --- > meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb > b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb > index 07c2dce..bdf173a 100644 > --- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb > +++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb > @@ -9,7 +9,6 @@ LIC_FILES_CHKSUM = > "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7 \ > SECTION = "libs" > > DEPENDS = "glib-2.0" > -DEPENDS_append_linuxstdbase = " virtual/libx11" Do we not need something like: PACKAGECONFIG_append_linuxstdbase = "x11" to ensure that this is enabled for LSB? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] insane.bbclass: show PN and relative path in package_qa_check_host_user
* show PN as other QA checks
* strip PKGDEST prefix from shown path as other QA checks
Signed-off-by: Martin Jansa
---
meta/classes/insane.bbclass | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5c8629a..a35e546 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -980,6 +980,7 @@ def package_qa_check_host_user(path, name, d, elf,
messages):
return
dest = d.getVar('PKGDEST', True)
+pn = d.getVar('PN', True)
home = os.path.join(dest, 'home')
if path == home or path.startswith(home + os.sep):
return
@@ -991,14 +992,15 @@ def package_qa_check_host_user(path, name, d, elf,
messages):
if exc.errno != errno.ENOENT:
raise
else:
+rootfs_path = path[len(dest):]
check_uid = int(d.getVar('HOST_USER_UID', True))
if stat.st_uid == check_uid:
-messages["host-user-contaminated"] = "%s is owned by uid %d, which
is the same as the user running bitbake. This may be due to host contamination"
% (path, check_uid)
+messages["host-user-contaminated"] = "%s: %s is owned by uid %d,
which is the same as the user running bitbake. This may be due to host
contamination" % (pn, rootfs_path, check_uid)
return False
check_gid = int(d.getVar('HOST_USER_GID', True))
if stat.st_gid == check_gid:
-messages["host-user-contaminated"] = "%s is owned by gid %d, which
is the same as the user running bitbake. This may be due to host contamination"
% (path, check_gid)
+messages["host-user-contaminated"] = "$s: %s is owned by gid %d,
which is the same as the user running bitbake. This may be due to host
contamination" % (pn, rootfs_path, check_gid)
return False
return True
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] insane.bbclass: drop extra line-feed in pkgname check
* it was causing QA checck name to be shown on separate line like this:
sblim-sfcCommon-1.0.1: sblim-sfcCommon-dev doesn't match the [a-z0-9.+-]+
regex
[pkgname]
Signed-off-by: Martin Jansa
---
meta/classes/insane.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index a35e546..c01c34a 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1091,7 +1091,7 @@ python do_package_qa () {
# Check package name
if not pkgname_pattern.match(package):
package_qa_handle_error("pkgname",
-"%s doesn't match the [a-z0-9.+-]+ regex\n" % package, d)
+"%s doesn't match the [a-z0-9.+-]+ regex" % package, d)
path = "%s/%s" % (pkgdest, package)
if not package_qa_walk(path, warnchecks, errorchecks, skip, package,
d):
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] package.bbclass: add summary line to installed-vs-shipped QA check
* there is PN at the beginning, then possibly long list of files and
at the end we don't see which recipe has this issue, add another
line which says which PN and how many files
Signed-off-by: Martin Jansa
---
meta/classes/package.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index cd92beb..09230b5 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1146,7 +1146,8 @@ python populate_packages () {
else:
for f in unshipped:
msg = msg + "\n " + f
-msg = msg + "\nPlease set FILES such that these items are
packaged. Alternatively if they are unneeded, avoid installing them or delete
them within do_install."
+msg = msg + "\nPlease set FILES such that these items are
packaged. Alternatively if they are unneeded, avoid installing them or delete
them within do_install.\n"
+msg = msg + "%s: %d installed and not shipped files." % (pn,
len(unshipped))
package_qa_handle_error("installed-vs-shipped", msg, d)
}
populate_packages[dirs] = "${D}"
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][dizzy 1/2] perf: mkdir ${B} -> mkdir -p ${B}
From: Robert Yang
${B} is the default cwd of tasks, so there might be race issues such as:
| mkdir: cannot create directory
`/path/to/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/': File exists
[snip]
NOTE: recipe perf-1.0-r9: task do_configure: Failed
Signed-off-by: Robert Yang
Signed-off-by: Richard Purdie
---
meta/recipes-kernel/perf/perf.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 1f1f552..cf75918 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -119,7 +119,7 @@ do_install() {
do_configure_prepend () {
# Fix for rebuilding
rm -rf ${B}/
-mkdir ${B}/
+mkdir -p ${B}/
#kernels before 3.1 do not support WERROR env variable
sed -i 's,-Werror ,,' ${S}/tools/perf/Makefile
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][dizzy 2/2] autotools.bbclass: mkdir ${B} -> mkdir -p ${B}
From: Robert Yang
${B} is the default cwd of tasks, so there might be race issues such as:
| mkdir: cannot create directory `${B}': File exists
[snip]
NOTE: recipe perf-1.0-r9: task do_configure: Failed
Signed-off-by: Robert Yang
Signed-off-by: Richard Purdie
---
meta/classes/autotools.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index b5f4516..dbe5e91 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -105,7 +105,7 @@ autotools_preconfigure() {
if [ "${S}" != "${B}" ]; then
echo "Previously configured separate build
directory detected, cleaning ${B}"
rm -rf ${B}
- mkdir ${B}
+ mkdir -p ${B}
else
# At least remove the .la files since automake
won't automatically
# regenerate them even if CFLAGS/LDFLAGS are
different
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][fido 1/2] perf: mkdir ${B} -> mkdir -p ${B}
From: Robert Yang
${B} is the default cwd of tasks, so there might be race issues such as:
| mkdir: cannot create directory
`/path/to/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/': File exists
[snip]
NOTE: recipe perf-1.0-r9: task do_configure: Failed
Signed-off-by: Robert Yang
Signed-off-by: Richard Purdie
---
meta/recipes-kernel/perf/perf.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index e7ddfff..9982589 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -118,7 +118,7 @@ do_install() {
do_configure_prepend () {
# Fix for rebuilding
rm -rf ${B}/
-mkdir ${B}/
+mkdir -p ${B}/
#kernels before 3.1 do not support WERROR env variable
sed -i 's,-Werror ,,' ${S}/tools/perf/Makefile
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][fido 2/2] autotools.bbclass: mkdir ${B} -> mkdir -p ${B}
From: Robert Yang
${B} is the default cwd of tasks, so there might be race issues such as:
| mkdir: cannot create directory `${B}': File exists
[snip]
NOTE: recipe perf-1.0-r9: task do_configure: Failed
Signed-off-by: Robert Yang
Signed-off-by: Richard Purdie
---
meta/classes/autotools.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index f213e89..24a0114 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -105,7 +105,7 @@ autotools_preconfigure() {
if [ "${S}" != "${B}" ]; then
echo "Previously configured separate build
directory detected, cleaning ${B}"
rm -rf ${B}
- mkdir ${B}
+ mkdir -p ${B}
else
# At least remove the .la files since automake
won't automatically
# regenerate them even if CFLAGS/LDFLAGS are
different
--
2.5.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] initramfs-framework: fix "support dropping into shell on failure"
Due to a missing $ before the variable name, all fatal errors ended up
invoking a shell, instead of only doing that when init_fatal_sh is set
as boot parameter.
Signed-off-by: Patrick Ohly
---
meta/recipes-core/initrdscripts/initramfs-framework/init | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init
b/meta/recipes-core/initrdscripts/initramfs-framework/init
index 9291ad5..204f237 100755
--- a/meta/recipes-core/initrdscripts/initramfs-framework/init
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
@@ -58,7 +58,7 @@ fatal() {
echo $1 >/dev/console
echo >/dev/console
-if [ -n "bootparam_init_fatal_sh" ]; then
+if [ -n "$bootparam_init_fatal_sh" ]; then
sh
else
while [ "true" ]; do
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] State of bitbake world, Failed tasks 2015-09-13
On Wed, Aug 26, 2015 at 03:56:04PM +0200, Martin Jansa wrote: > Time for even more PNBLACKLISTs.. And it got even worse. This run was built without sstate, so QA issues should be more complete. I need to update the report script to show new types of QA issues (and some old ones which weren't parsed before, because they were all fixed). While checking qa logs I've noticed that some issues report whole path (so the same issue is reported multiple times, once for each architecture because of different WORKDIR - anyone against using path relative to WORKDIR?) and some check show the name of sanity check on line without any useful information like pkgname and installed-not-shipped tests, I'll try to send some fixes or at least keep them included in my world builds to get more useful logs. OE @ ~/openembedded-core $ git log --oneline origin/master..jansa/master c3cc2a3 fontcache: allow to pass extra parameters and environment to fc-cache a9ab2c3 Fix recursive mode -st on BUILDDIR setup 3963029 guile, mailx, gcc, opensp, gstreamer1.0-libav, libunwind: disable thumb where it fails for qemuarm 70981e4 icu: force arm mode c0441fd gdb: force arm mode 07a20f5 DO-NOT-MERGE: distutils3.bbclass: Don't use MACHINE variable a4e29ea libsdl: Add support for libsdl-native 0f9eca4 WIP: Add KERNEL_EXTRA_ARGS? 504d2cb sstate-sysroot-cruft: Add /usr/src/kernel/.* to whitelist 506990d report-error: Allow to upload reports automatically 199ec66 qemux86: Add identical qemux86copy variant for tests http://www.openembedded.org/wiki/Bitbake_World_Status == Failed tasks 2015-09-13 == INFO: jenkins-job.sh-1.3.1 Complete log available at http://logs.nslu2-linux.org/buildlogs/oe/world/log.report.20150915_163214.log === common (23) === * /meta-openembedded/meta-efl/recipes-efl/efl/azy_svn.bb, do_compile * /meta-openembedded/meta-efl/recipes-efl/efl/epdf_svn.bb, do_compile * /meta-openembedded/meta-gnome/recipes-gnome/epiphany/epiphany_2.30.6.bb, do_fetch * /meta-openembedded/meta-gnome/recipes-gnome/gnome-power-manager/gnome-power-manager_2.32.0.bb, do_compile * /meta-openembedded/meta-gnome/recipes-gnome/nautilus/nautilus3_3.2.1.bb, do_configure * /meta-openembedded/meta-initramfs/recipes-bsp/kexecboot/kexecboot_0.6.bb, do_compile * /meta-openembedded/meta-multimedia/recipes-mkv/mkvtoolnix/mkvtoolnix_git.bb, do_compile * /meta-openembedded/meta-multimedia/recipes-multimedia/musicpd/mpd_0.19.1.bb, do_compile * /meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_2.2.1.bb, do_compile * /meta-openembedded/meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb, do_patch * /meta-openembedded/meta-networking/recipes-daemons/lldpad/lldpad_0.9.46.bb, do_compile * /meta-openembedded/meta-networking/recipes-support/sshguard/sshguard_git.bb, do_compile * /meta-openembedded/meta-oe/recipes-benchmark/tiobench/tiobench_0.3.3.bb, do_compile * /meta-openembedded/meta-oe/recipes-connectivity/libimobiledevice/libimobiledevice_1.1.4.bb, do_compile * /meta-openembedded/meta-oe/recipes-devtools/packagekit/packagekit_0.5.6.bb, do_compile * /meta-openembedded/meta-oe/recipes-extended/libuio/libuio_0.2.1.bb, do_compile * /meta-openembedded/meta-oe/recipes-gnome/gtkextra/gtkextra_3.0.5.bb, do_compile * /meta-openembedded/meta-oe/recipes-graphics/xorg-app/sessreg_1.1.0.bb, do_compile * /meta-openembedded/meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb, do_compile * /meta-openembedded/meta-oe/recipes-navigation/gdal/gdal_1.11.1.bb, do_compile * /meta-openembedded/meta-oe/recipes-support/libdbi/libdbi-drivers_0.8.3-1.bb, do_compile * /meta-openembedded/meta-perl/recipes-perl/libnet/libnet-dns-perl_0.81.bb, do_configure * /meta-webos-ports/meta-luneui/recipes-webos/luna-service2/luna-service2.bb, do_compile === common-x86 (2) === * /meta-browser/recipes-browser/chromium/chromium_40.0.2214.91.bb, do_compile * /meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_1.11.0.bb, do_compile === qemuarm (5) === * /meta-openembedded/meta-oe/recipes-extended/efivar/efivar_git.bb, do_compile * /meta-openembedded/meta-oe/recipes-navigation/gpsd/gpsd_3.14.bb, do_compile * /meta-openembedded/meta-oe/recipes-qt/qt-creator/qt-creator_2.8.1.bb, do_compile * /openembedded-core/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb, do_compile * /openembedded-core/meta/recipes-support/libunwind/libunwind_1.1.bb, do_compile === qemux86 (9) === * /meta-browser/recipes-browser/chromium/cef3_280796.bb, do_compile * /meta-openembedded/meta-networking/recipes-extended/iscsitarget/iscsitarget_1.4.20.3+svn502.bb, do_make_scripts * /meta-openembedded/meta-networking/recipes-kernel/netmap/netmap-modules_git.bb, do_configure * /meta-openembedded/meta-networking/recipes-kernel/netmap/netmap-modules_git.bb, do_make_scripts * /meta-openembedded/meta-oe/recipes-graphics/xorg-driver/xf86-video-geo
Re: [OE-core] [PATCH] gdk-pixbuf: remove redundant libx11 DEPENDS line
On Fri, Sep 18, 2015 at 8:51 AM, Carlos Rafael Giani wrote: > The x11 packageconfig already takes care of the X11 dependency, and also > respects the DISTRO_FEATURES > > Signed-off-by: Carlos Rafael Giani Acked-by: Otavio Salvador -- 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
[OE-core] [PATCH] gdk-pixbuf: remove redundant libx11 DEPENDS line
The x11 packageconfig already takes care of the X11 dependency, and also
respects the DISTRO_FEATURES
Signed-off-by: Carlos Rafael Giani
---
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb
index 07c2dce..bdf173a 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb
@@ -9,7 +9,6 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7 \
SECTION = "libs"
DEPENDS = "glib-2.0"
-DEPENDS_append_linuxstdbase = " virtual/libx11"
MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] fix error handling in initramfs-framework
While debugging the root=UUID failure when using IDE disks I noticed
that the error messages from initramfs-module did not really explain
the problem, and that my "drop to shell" patch was faulty. Here are the
improvement respectively fix.
The following changes since commit 72682d72b52355c3fed947167ca3c6064340ead1:
autotools.bbclass: mkdir ${B} -> mkdir -p ${B} (2015-09-16 22:17:19 +0100)
are available in the git repository at:
git://github.com/pohly/openembedded-core initramfs-rootfs-failure
https://github.com/pohly/openembedded-core/tree/initramfs-rootfs-failure
Patrick Ohly (2):
initramfs-framework: fix "support dropping into shell on failure"
initramfs-framework: better error reporting for invalid root boot
parameter
meta/recipes-core/initrdscripts/initramfs-framework/finish | 2 +-
meta/recipes-core/initrdscripts/initramfs-framework/init | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] initramfs-framework: better error reporting for invalid root boot parameter
When the "boot" parameter refers to a non-existent device, the only
visible output at normal log levels was a rather confusing:
ERROR: There's no '/dev' on rootfs.
That's because the actual error, not being able to find the root
device, was only a debug message, which gets ignored in the default
mode.
Promoting the "root '$bootparam_root' doesn't exist." message from
"debug" to "msg" gives sufficient context to understand the error. A
more intrusive change would be to change also the control flow.
Signed-off-by: Patrick Ohly
---
meta/recipes-core/initrdscripts/initramfs-framework/finish | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/finish
b/meta/recipes-core/initrdscripts/initramfs-framework/finish
index e712ff0..d09bbb8 100755
--- a/meta/recipes-core/initrdscripts/initramfs-framework/finish
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/finish
@@ -37,7 +37,7 @@ finish_run() {
fi
mount $flags $bootparam_root $ROOTFS_DIR
else
- debug "root '$bootparam_root' doesn't exist."
+ msg "root '$bootparam_root' doesn't exist."
fi
fi
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] selftest/buildoptions: pexpect not a builtin module
On Friday 18 September 2015 12:05:35 Burton, Ross wrote: > On 17 September 2015 at 21:38, Benjamin Esquivel < > > benjamin.esqui...@linux.intel.com> wrote: > > put the import of pexpect around a try statement so it can tell you > > why it failed to import when in a system that has the module unreachable > > As the failing import is throwing an exception, can't the calling code > display the exception correctly? If we're going to trap this I think we should be displaying something like "Please install pexpect (python-pexpect)". Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] selftest/buildoptions: pexpect not a builtin module
On 17 September 2015 at 21:38, Benjamin Esquivel < benjamin.esqui...@linux.intel.com> wrote: > put the import of pexpect around a try statement so it can tell you > why it failed to import when in a system that has the module unreachable > As the failing import is throwing an exception, can't the calling code display the exception correctly? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225
On Fri, Sep 18, 2015 at 12:33 PM, Adrian Freihofer
wrote:
> Hi Martin, hi Andreas
>
> You are right, my patches are almost obsolete. Just some details might be
> worth to be noticed:
>
> libgudev might be improved by adding:
> RCONFLICTS_${PN} = "systemd (<= 220)"
>
> NetworkManager and ModemManager depend on udev instead of libgudev as well.
>
Hi Adrian,
Checked the configure.ac of NetworkManager and ModemManager: You are
right - guess I missed the rdepends warnings due to bloated log. For
RCONFLICTS I have no strong opinion. I think it is correct but am not
sure if it is really necessary. On the other hands no harm is expected
- so why not? other opinions?
Can you please send patches with improvements based on master-next?
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] Fixes for oe-git-proxy
This fixes a couple of problems with the oe-git-proxy script. See the
respective commits for more information.
//Peter
The following changes since commit 3a5e46b6ed483e43251da7e328b9299189997722:
bitbake: bb.fetch2.{git, hg}: remove tarball if it needs updating (2015-09-18
09:05:36 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib pkj/oe-git-proxy
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=pkj/oe-git-proxy
Peter Kjellerstedt (3):
oe-git-proxy: Allow explicit IP addresses in $NO_PROXY
oe-git-proxy: Correct the parsing of a port in $ALL_PROXY
oe-git-proxy: Allow socks4 as protocol in $ALL_PROXY
scripts/oe-git-proxy | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] oe-git-proxy: Correct the parsing of a port in $ALL_PROXY
Due to an error in the regular expression used to extract a port number specified in $ALL_PROXY, rather than allowing the port number to be followed by an optional "/", the port was required to be followed by "/?". This corrects the regular expression to allow an optional "/". It also allows the odd "/?" suffix for backwards compatibility. Signed-off-by: Peter Kjellerstedt --- scripts/oe-git-proxy | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/oe-git-proxy b/scripts/oe-git-proxy index 2473282..b971c88 100755 --- a/scripts/oe-git-proxy +++ b/scripts/oe-git-proxy @@ -113,7 +113,9 @@ done # Proxy is necessary, determine protocol, server, and port PROTO=$(echo $ALL_PROXY | sed -e 's/\([^:]*\):\/\/.*/\1/') PROXY=$(echo $ALL_PROXY | sed -e 's/.*:\/\/\([^:]*\).*/\1/') -PORT=$(echo $ALL_PROXY | sed -e 's/.*:\([0-9]*\)\/?$/\1/') +# For backwards compatibility, this allows the port number to be followed by /? +# in addition to the customary optional / +PORT=$(echo $ALL_PROXY | sed -e 's/.*:\([0-9]*\)\(\/?\?\)\?$/\1/') if [ "$PORT" = "$ALL_PROXY" ]; then PORT="" fi -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] oe-git-proxy: Allow explicit IP addresses in $NO_PROXY
Without this fix, if one specified, e.g., 127.0.0.1 in $NO_PROXY, the
oe-git-proxy script would fail with a message like this:
/home/pkj/yocto/poky/scripts/oe-git-proxy: line 64: 32-127.0.0.1: syntax error:
invalid arithmetic operator (error token is ".0.0.1")
Signed-off-by: Peter Kjellerstedt
---
scripts/oe-git-proxy | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/oe-git-proxy b/scripts/oe-git-proxy
index 4873455..2473282 100755
--- a/scripts/oe-git-proxy
+++ b/scripts/oe-git-proxy
@@ -53,6 +53,7 @@ match_ipv4() {
# Determine the mask bitlength
BITS=${CIDR##*/}
+ [ "$BITS" != "$CIDR" ] || BITS=32
if [ -z "$BITS" ]; then
return 1
fi
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] oe-git-proxy: Allow socks4 as protocol in $ALL_PROXY
The current default is to use SOCKS4a when socks is specified as protocol in $ALL_PROXY. However, not all socks servers support SOCKS4a. By allowing socks4 as an additional protocol, this script will happily work with SOCKS4 only servers. Signed-off-by: Peter Kjellerstedt --- scripts/oe-git-proxy | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/scripts/oe-git-proxy b/scripts/oe-git-proxy index b971c88..d2e9f92 100755 --- a/scripts/oe-git-proxy +++ b/scripts/oe-git-proxy @@ -120,11 +120,16 @@ if [ "$PORT" = "$ALL_PROXY" ]; then PORT="" fi -if [ "$PROTO" = "socks" ]; then +if [ "$PROTO" = "socks" ] || [ "$PROTO" = "socks4a" ]; then if [ -z "$PORT" ]; then PORT="1080" fi METHOD="SOCKS4A:$PROXY:$1:$2,socksport=$PORT" +elif [ "$PROTO" = "socks4" ]; then + if [ -z "$PORT" ]; then + PORT="1080" + fi + METHOD="SOCKS4:$PROXY:$1:$2,socksport=$PORT" else # Assume PROXY (http, https, etc) if [ -z "$PORT" ]; then -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] bind: 9.10.2-P4 -> 9.10.3
On 18 September 2015 at 04:22, wrote: > Upgrade bind to 9.10.3 to fix CVE issues. > Sorry, but we just had the M3 build so can you submit this as a patch to 9.10.2-P4 instead of an upgrade? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225
Hi Martin, hi Andreas
You are right, my patches are almost obsolete. Just some details might be worth
to be noticed:
libgudev might be improved by adding:
RCONFLICTS_${PN} = "systemd (<= 220)"
NetworkManager and ModemManager depend on udev instead of libgudev as well.
Von: "Martin Jansa"
An: "Adrian Freihofer"
CC: "Khem Raj" , "openembedded-devel"
, "Patches and discussions about the
oe-core layer"
Gesendet: Freitag, 18. September 2015 11:02:35
Betreff: Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225
Hi Adrian,
we're not accepting github's pull requests, see README.
Andreas already send many fixes for gudev, please check master-next if
something is missing from your changes and resend to ML.
On Fri, Sep 18, 2015 at 9:46 AM, Adrian Freihofer <
adrian.freiho...@neratec.com > wrote:
Hi Andreas
Here is a first patchset ready for pulling...
https://github.com/openembedded/meta-openembedded/pull/16
Von: "Khem Raj" < raj.k...@gmail.com >
An: "Andreas Müller" < schnitzelt...@googlemail.com >
CC: openembedded-de...@lists.openembedded.org , "Patches and discussions about
the oe-core layer" < openembedded-core@lists.openembedded.org >
Gesendet: Mittwoch, 16. September 2015 23:18:50
Betreff: Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225
On Wed, Sep 16, 2015 at 2:17 PM, Andreas Müller
< schnitzelt...@googlemail.com > wrote:
> Is anybody preparing patches for gudev (many packets in meta-oe require it)?
>
> If not I can do so. Is the home for libgudev oe-core or better meta-oe?
meta-oe is better for now. I am not working on it.
--
___
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dylan] Backport Request
Hi,
I'm not sure if there are many other poor souls still using dylan, but if there
are I'd like to request a backport of the following commit. In our case it is
needed to ensure that a package is rebuilt when INITSCRIPT_NAME or
INITSCRIPT_PARAMS is changed in a recipe.
Hopefully we'll be able to upgrade soon, but if so it will probably be only as
far as daisy...
commit 4003218f774c38bb5de0d95a43153f8b8d7fc4ce
Author: Richard Purdie
Date: Fri Oct 4 12:29:08 2013 +0100
udpated-rc.d: Track postinst/prerm/postrm in task checksum
When these functions change, the package should rebuild but currently it
does not. We need to add the dependencies manually as the dependency
code can't track dynamically created variables.
Signed-off-by: Richard Purdie
diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 5588569..f726f2f 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -54,6 +54,8 @@ python __anonymous() {
PACKAGESPLITFUNCS_prepend = "populate_packages_updatercd "
+populate_packages_updatercd[vardeps] += "updatercd_prerm updatercd_postrm
updatercd_postinst"
+
python populate_packages_updatercd () {
def update_rcd_package(pkg):
bb.debug(1, 'adding update-rc.d calls to postinst/postrm for %s' % pkg)
--
Paul Barker
Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
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] [dylan] Backport Request
Hi Paul, On Friday 18 September 2015 08:52:41 Paul Barker wrote: > I'm not sure if there are many other poor souls still using dylan, but if > there are I'd like to request a backport of the following commit. In our > case it is needed to ensure that a package is rebuilt when INITSCRIPT_NAME > or INITSCRIPT_PARAMS is changed in a recipe. Sure, whilst dylan is nominally no longer maintained in this case the change is fairly self-contained and straightforward so in theory it should be OK. > Hopefully we'll be able to upgrade soon, but if so it will probably be only > as far as daisy... I'd urge you to consider upgrading further than that; daisy is already out of support (and will be one release further out by October). If there are things that prevent you from doing that we should discuss them as it might be something we need to address in terms of making upgrades easier. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Dynamic common utilities
On 17/09/15 17:20, Alejandro Joya wrote: It provide a virtual reference for the common utilities. it replace of the lock to busybox, it will be simple exchange between other common utilities like gnu core utils or toybox among others. In order to enable its required to fill at the distro conf or local.conf VIRTUAL-RUNTIME_login_manager ?= "busybox" PREFERRED_PROVIDER_virtual/anybox ?= "busybox" PREFERRED_RPROVIDER_virtual/anybox ?= "busybox" VIRTUAL-RUNTIME_anybox ?= "busybox" VIRTUAL-RUNTIME_anybox-hwclock ?= "busybox-hwclock" The following changes since commit f0189829498e30231d826c9f55aad73e622d076e: qemu: Update to upstream patches (2015-09-14 11:22:02 +0100) are available in the git repository at: git://github.com/Ajoyacr/openembedded-core anybox https://github.com/Ajoyacr/openembedded-core/tree/anybox Alejandro Joya (3): core-mage-minimal-initramfs: overwrite hardcoded dependency to virtual reference initramfs-framework: overwrite hardcoded dependency to virtual reference packagegroup-core-boot: overwrite hardcoded dependency to virtual reference meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 +- meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb | 2 +- meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) is 'anybox' a good name for the virtual provider? What happens if we have a new suite of core utility replacements without box in the name, I assume it will be a nightmare to retroactivly change the name so we should probably come up with a more generic one now. virtual/core-utils, virtual/base-utils? Cheers, Jack. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] openssl: remove lock data_word from x86cpuid.pl
On 17 September 2015 at 18:03, Kinsella, Ray wrote:
> The cmpxchg instruction is encoded in functions such as OPENSSL_atomic_add
> as a perlasm data_word. This has the effect of hiding the instruction from
> the assembler. Stripping the LOCK prefix on cmpxchg via the assembler with
> --momit-lock-prefix=yes then becomes impossible (required on the Intel
> X1000).
> This patch converts the data_word into perlasm instructions.
>
Could you resend this following the advice here:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines : mainly
the patch file you add needs a message explaining the change as well as
headers Upstream-Status & Signed-off-by.
Thanks,
Jussi
Signed-off-by: Ray Kinsella
> ---
> .../openssl/remove-lock-data_word-from-x86cpuid.pl.patch | 12
>
> meta/recipes-connectivity/openssl/openssl_1.0.2d.bb|1 +
> 2 files changed, 13 insertions(+)
> create mode 100644
> meta/recipes-connectivity/openssl/openssl/remove-lock-data_word-from-x86cpuid.pl.patch
>
> diff --git
> a/meta/recipes-connectivity/openssl/openssl/remove-lock-data_word-from-x86cpuid.pl.patch
> b/meta/recipes-connectivity/openssl/openssl/remove-lock-data_word-from-x86cpuid.pl.patch
> new file mode 100644
> index 000..e969e91
> --- /dev/null
> +++
> b/meta/recipes-connectivity/openssl/openssl/remove-lock-data_word-from-x86cpuid.pl.patch
> @@ -0,0 +1,12 @@
> +--- openssl-1.0.2d/crypto/x86cpuid.pl.orig 2015-09-16
> 21:11:01.927322252 +0100
> openssl-1.0.2d/crypto/x86cpuid.pl 2015-09-16 21:14:45.795314992
> +0100
> +@@ -275,7 +275,8 @@
> + &set_label("spin");
> + &lea("ebx",&DWP(0,"eax","ecx"));
> + &nop();
> +- &data_word(0x1ab10ff0); # lock; cmpxchg %ebx,(%edx) # %eax is
> envolved and is always reloaded
> ++ &lock ();
> ++ &cmpxchg(&DWP(0,"edx"), "ebx"); # %eax is envolved and is always
> reloaded
> + &jne(&label("spin"));
> + &mov("eax","ebx"); # OpenSSL expects the new value
> + &pop("ebx");
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb
> b/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb
> index 32d8dce..de2ec1a 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.0.2d.bb
> @@ -33,6 +33,7 @@ SRC_URI += "file://configure-targets.patch \
> file://openssl-fix-des.pod-error.patch \
> file://Makefiles-ptest.patch \
> file://ptest-deps.patch \
> +file://remove-lock-data_word-from-x86cpuid.pl.patch \
> file://run-ptest \
> file://crypto_use_bigint_in_x86-64_perl.patch \
> file://openssl-1.0.2a-x32-asm.patch \
> --
> 1.7.10.4
>
> --
> ___
> 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
Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225
Hi Adrian, we're not accepting github's pull requests, see README. Andreas already send many fixes for gudev, please check master-next if something is missing from your changes and resend to ML. On Fri, Sep 18, 2015 at 9:46 AM, Adrian Freihofer < adrian.freiho...@neratec.com> wrote: > Hi Andreas > > Here is a first patchset ready for pulling... > https://github.com/openembedded/meta-openembedded/pull/16 > > -- > *Von: *"Khem Raj" > *An: *"Andreas Müller" > *CC: *openembedded-de...@lists.openembedded.org, "Patches and discussions > about the oe-core layer" > *Gesendet: *Mittwoch, 16. September 2015 23:18:50 > *Betreff: *Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225 > > On Wed, Sep 16, 2015 at 2:17 PM, Andreas Müller > wrote: > > Is anybody preparing patches for gudev (many packets in meta-oe require > it)? > > > > If not I can do so. Is the home for libgudev oe-core or better meta-oe? > > meta-oe is better for now. I am not working on it. > -- > ___ > 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 > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225
Hi Andreas Here is a first patchset ready for pulling... https://github.com/openembedded/meta-openembedded/pull/16 Von: "Khem Raj" An: "Andreas Müller" CC: openembedded-de...@lists.openembedded.org, "Patches and discussions about the oe-core layer" Gesendet: Mittwoch, 16. September 2015 23:18:50 Betreff: Re: [OE-core] [PATCH V2 2/3] systemd: Upgrade 219 -> 225 On Wed, Sep 16, 2015 at 2:17 PM, Andreas Müller wrote: > Is anybody preparing patches for gudev (many packets in meta-oe require it)? > > If not I can do so. Is the home for libgudev oe-core or better meta-oe? meta-oe is better for now. I am not working on it. -- ___ 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
