Re: [OE-core] [oe] [PATCH v2][meta-perl] libxml-sax-writer-perl: add recipe
On 07/24/2014 07:14 PM, Martin Jansa wrote:
On Tue, Jul 22, 2014 at 03:06:53PM +0800, rongqing...@windriver.com wrote:
From: Roy Li
Sorry, but it still isn't correct even with allarch, because there is
dependency on TUNE_PKGARCH perl:
ERROR: libxml-filter-buffertext-perl different signature for task
do_configure.sigdata between qemux86copy and qemuarm
Hash for dependent task perl_5.20.0.bb.do_populate_sysroot changed from
a5827c8deafb0ace555794c62c44e19f to 1a07f7ac7ad2a2750b58dfa60136114b
ERROR: libxml-sax-writer-perl different signature for task do_configure.sigdata
between qemux86copy and qemuarm
Hash for dependent task perl_5.20.0.bb.do_populate_sysroot changed from
a5827c8deafb0ace555794c62c44e19f to 1a07f7ac7ad2a2750b58dfa60136114b
1. I can not reproduce it, where are my steps be wrong?
$ ../scripts/sstate-diff-machines.sh --tmpdir=tmp/ --machines="qemuarm
qemux86copy qemux86-64" --targets=libxml-sax
-writer-perl
...
NOTE: Preparing runqueue
NOTE: Reparsing files to collect dependency data
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be
rerun and all succeeded.
INFO: Output written in:
/buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562
$cd /buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562
$
builder@pek-yocto-build1:/buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562$
find . |grep writer-perl|grep sysroot
./qemux86copy/all-poky-linux/libxml-sax-writer-perl/0.54-r0.do_populate_sysroot.sigdata.323a1635a2b08060e64815de8e009281
./qemuarm/all-poky-linux/libxml-sax-writer-perl/0.54-r0.do_populate_sysroot.sigdata.323a1635a2b08060e64815de8e009281
./qemux86-64/all-poky-linux/libxml-sax-writer-perl/0.54-r0.do_populate_sysroot.sigdata.323a1635a2b08060e64815de8e009281
builder@pek-yocto-build1:/buildarea1/lirq/new/5/poky/build-next/tmp/sstate-diff/1406264562$
2. the cause maybe the below:
perl module will depend on perl, but perl is not allarch, so make your
error.
meta/classes/cpan-base.bbclass
7 DEPENDS += "${@["perl",
"perl-native"][(bb.data.inherits_class('native', d))]}"
8 RDEPENDS_${PN} += "${@["perl",
""][(bb.data.inherits_class('native', d))]}"
3. no perl modules inherit allarch in oe-core;
oe-core$ find ./ -name "*perl*bb" -exec grep allarch {} \;
oe-core$
but I think some module should be allarch, like: libxml-simple-perl
https://packages.debian.org/search?keywords=libxml-simple-perl&searchon=names&suite=stable§ion=all
-Roy
Signed-off-by: Roy Li
---
.../libxml/libxml-sax-writer-perl_0.54.bb | 25
1 file changed, 25 insertions(+)
create mode 100644
meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
diff --git a/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
new file mode 100644
index 000..52458e4
--- /dev/null
+++ b/meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.54.bb
@@ -0,0 +1,25 @@
+SUMMARY = "XML::SAX::Writer - SAX2 Writer"
+DESCRIPTION = "\
+XML::SAX::Writer helps to serialize SAX2 representations of XML documents to \
+strings, files, and other flat representations. It handles charset encodings, \
+XML escaping conventions, and so forth. It is still considered alpha, \
+although it has been put to limited use in settings such as XML::LibXML and \
+the AxKit XML Application Server. \
+"
+SECTION = "libs"
+LICENSE = "Artistic-1.0 | GPLv1+"
+HOMEPAGE = "http://search.cpan.org/dist/XML-SAX-Writer/";
+DEPENDS += "libxml-filter-buffertext-perl-native"
+RDEPENDS_${PN} += "libxml-filter-buffertext-perl"
+
+SRC_URI =
"http://search.cpan.org/CPAN/authors/id/P/PE/PERIGRIN/XML-SAX-Writer-${PV}.tar.gz";
+SRC_URI[md5sum] = "383139d76418a82b9800dc4f8b568891"
+SRC_URI[sha256sum] =
"a1b4d959aed8f8337523c4cef4b431e56e619c795dc6f99a868548952101cf3d"
+
+LIC_FILES_CHKSUM =
"file://README;beginline=45;endline=46;md5=d41d8cd98f00b204e9800998ecf8427e"
+
+S = "${WORKDIR}/XML-SAX-Writer-${PV}"
+
+inherit cpan allarch
+
+BBCLASSEXTEND = "native"
--
1.7.10.4
--
___
Openembedded-devel mailing list
openembedded-de...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Best Reagrds,
Roy | RongQing Li
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gstreamer1.0: pass rate of input segment to output segment in gstbaseparse.
Hello Ross, Hello Zidan, On Tue, Jul 22, 2014 at 7:28 PM, Burton, Ross wrote: > On 22 July 2014 07:49, Wang Zidan wrote: >> +Upstream Status: Backported > > Presumably this made it into 1.4.0 so should we instead simply upgrade? I fully agree. Zidan, could you work on this? -- 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 4/8] linux-yocto-dev: bump to v3.16+
On Thu, Jul 24, 2014 at 11:36 PM, Bruce Ashfield
wrote:
> On 2014-07-24, 11:35 PM, Saul Wold wrote:
>>
>> On 07/24/2014 01:41 PM, Bruce Ashfield wrote:
>>>
>>> Signed-off-by: Bruce Ashfield
>>> ---
>>> meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
>>> b/meta/recipes-kernel/linux/linux-yocto-dev.bb
>>> index 9b49eee87651..10f3d234ed25 100644
>>> --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
>>> +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
>>> @@ -36,7 +36,7 @@ SRC_URI =
>>> "git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=${K
>>> SRCREV_machine ?=
>>> '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
>>> "linux-yocto-dev", "${AUTOREV}",
>>> "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
>>> SRCREV_meta ?=
>>> '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
>>> "linux-yocto-dev", "${AUTOREV}",
>>> "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
>>>
>>> -LINUX_VERSION ?= "3.14+"
>>> +LINUX_VERSION ?= "3.16+"
>>> LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>
>>>
>>
>> So far the Autobuilder has found 1 issue with this and the x32 build
>>
>>
>> https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/182/steps/BuildImages/logs/stdio
>>
>
> Adding Tom, Darren and Nitin .. since this is something they need to handle
I retract my overly quick analysis.
I dropped this by mistake in 3.14, and didn't make the same change in my master
meta data repository .. hence it also dropped in 3.16. I've restored
this in both
locations now.
Bruce
>
> Bruce
>
>
>>
>> I will send more failures as I see them.
>>
>> Sau!
>>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] linux-yocto-dev: bump to v3.16+
On 2014-07-24, 11:35 PM, Saul Wold wrote:
On 07/24/2014 01:41 PM, Bruce Ashfield wrote:
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 9b49eee87651..10f3d234ed25 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -36,7 +36,7 @@ SRC_URI =
"git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=${K
SRCREV_machine ?=
'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
SRCREV_meta ?=
'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
-LINUX_VERSION ?= "3.14+"
+LINUX_VERSION ?= "3.16+"
LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
PV = "${LINUX_VERSION}+git${SRCPV}"
So far the Autobuilder has found 1 issue with this and the x32 build
https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/182/steps/BuildImages/logs/stdio
Adding Tom, Darren and Nitin .. since this is something they need to handle
Bruce
I will send more failures as I see them.
Sau!
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/8] linux-yocto-dev: bump to v3.16+
On 07/24/2014 01:41 PM, Bruce Ashfield wrote:
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 9b49eee87651..10f3d234ed25 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -36,7 +36,7 @@ SRC_URI =
"git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=${K
SRCREV_machine ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-yocto-dev",
"${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
-LINUX_VERSION ?= "3.14+"
+LINUX_VERSION ?= "3.16+"
LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
PV = "${LINUX_VERSION}+git${SRCPV}"
So far the Autobuilder has found 1 issue with this and the x32 build
https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/182/steps/BuildImages/logs/stdio
I will send more failures as I see them.
Sau!
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] lttng-modules: re-enable ARM builds
On Thu, Jul 24, 2014 at 6:02 PM, Martin Jansa wrote: > On Thu, Jul 24, 2014 at 04:41:52PM -0400, Bruce Ashfield wrote: >> With lttng 2.4.2 and gcc 4.9, we can now enable lttng-modules for ARM. >> >> Signed-off-by: Bruce Ashfield >> --- >> meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb >> b/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb >> index 5a99a5adae8b..d87374163556 100644 >> --- a/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb >> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb >> @@ -12,8 +12,7 @@ inherit module >> >> SRCREV = "789fd1d06d07aeb9a403bdce1b3318560cfc6eca" >> >> -# lttng currently blacklists arm with gcc-4.8 >> -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips).*-linux' >> +COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|arm).*-linux' > > Please squash this to 2/8 otherwise there is no arm version between 2/8 > and 6/8. I'd rather not, since they are separate activities. I updated to 2.5, and then enable ARM. One isolated change per commit. Bisectability in a small series is one thing, but also is the isolation of changes. Richard can squash on merge is he wants, but I'm going to leave it as is. Bruce > >> SRC_URI = "git://git.lttng.org/lttng-modules.git;branch=stable-2.5 \ >> file://lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch \ >> -- >> 1.8.1.2 >> >> -- >> ___ >> 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 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perl: strip RPATH from libxml-parser-perl Expat.so
Hi, On 17-07-2014 09:51, Richard Purdie wrote: First we need to understand the problem exactly. Do you have a reproducer that always works? This happens on daisy. And my test case was: 1) add meta-intel and meta-crownbay layers 2) build MACHINE=qemux86 bitbake libxml-parser-perl 3) build MACHINE=genericx86 bitbake libxml-parser-perl 4) build MACHINE=crownbay-noemgd bitbake libxml-parser-perl The step 4 wont complete because rpath issues. To get it work: MACHINE=crownbay-noemgd bitbake libxml-parser-perl perl -c cleanssate Then MACHINE=crownbay-noemgd bitbake libxml-parser-perl Until now master is not affected. I am working to fix the libxml-parser-perl (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=joaohf/daisy-libxml-parser-perl-rpath). But I am not sure if it solves the root problem. Because OE should build using three differents MACHINEs using the same workdir, sstate-cache. Thanks. -- João Henrique Ferreira de Freitas - joaohf_at_gmail.com Campinas-SP-Brasil -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] wic: do not overwrite autogenerated /etc/fstab with original too early
On Thu, 2014-07-24 at 14:27 +0200, Maciej Borzecki wrote:
> DirectImageCreator.__write_fstab() generates new /etc/fstab in sysroot
> with rootfs contents. The fstab entries are generated base on the
> initialn contents of /etc/fstab, plus any extra (other than / or
> /boot) partitions listed in *.wks. A backup of original /etc/fstab is
> done in a temp location. Subsequent call to __restore_fstab() restores
> the backup copy, replacing the autogenerated one.
>
> Calling __restore_fstab() before Wic_PartData.prepare() brings back the
> original fstab before the partition image file actually is created. As
> such, the autogenerated /etc/fstab will not make it to the partition.
>
OK, I knew there was something funny about this, and it wasn't really
fixing the problem. I also knew that it had previously worked, and
digging around realized that the problem was that the recent patch 'wic:
Extend --rootfs-dir to connect rootfs-dirs' is what actually broke
things.
So this patch shouldn't be applied - I need to look at it a bit more and
come up with a proper fix..
Tom
> Signed-off-by: Maciej Borzecki
> Signed-off-by: Maciek Borzecki
> ---
>
> Notes:
> Previous version got messed up during merges and faulty code was sent
> out. This one works as expected.
>
> scripts/lib/mic/imager/direct.py | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/lib/mic/imager/direct.py
> b/scripts/lib/mic/imager/direct.py
> index 2cf4c8d..77a118a 100644
> --- a/scripts/lib/mic/imager/direct.py
> +++ b/scripts/lib/mic/imager/direct.py
> @@ -262,10 +262,12 @@ class DirectImageCreator(BaseImageCreator):
> # when/if we need to actually do package selection we
> # should modify things to use those objects, but for now
> # we can avoid that.
> +
> +fstab = self.__write_fstab(self.rootfs_dir.get("ROOTFS_DIR"))
> +
> p.prepare(self, self.workdir, self.oe_builddir, self.rootfs_dir,
>self.bootimg_dir, self.kernel_dir, self.native_sysroot)
>
> -fstab = self.__write_fstab(p.get_rootfs())
> self._restore_fstab(fstab)
>
> self.__instimage.add_partition(int(p.size),
> @@ -278,6 +280,7 @@ class DirectImageCreator(BaseImageCreator):
> boot = p.active,
> align = p.align,
> part_type = p.part_type)
> +
> self.__instimage.layout_partitions(self._ptable_format)
>
> self.__imgdir = self.workdir
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] wic: --fsoptions handling
On Thu, 2014-07-24 at 14:17 +0200, Maciej Borzecki wrote: > Add handling of --fsoptions in parition definition. If no options are > specified, 'defaults' is used. > > Signed-off-by: Maciej Borzecki > Signed-off-by: Maciek Borzecki Acked-by: Tom Zanussi > --- > scripts/lib/mic/imager/direct.py | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/scripts/lib/mic/imager/direct.py > b/scripts/lib/mic/imager/direct.py > index 77a118a..7e2b63a 100644 > --- a/scripts/lib/mic/imager/direct.py > +++ b/scripts/lib/mic/imager/direct.py > @@ -113,7 +113,15 @@ class DirectImageCreator(BaseImageCreator): > device_name = "/dev/" + p.disk + str(num + 1) > else: > device_name = "/dev/" + p.disk + str(num) > -fstab_entry = device_name + "\t" + p.mountpoint + "\t" + > p.fstype + "\tdefaults\t0\t0\n" > + > +opts = "defaults" > +if p.fsopts: > +opts = p.fsopts > + > +fstab_entry = device_name + "\t" + \ > + p.mountpoint + "\t" + \ > + p.fstype + "\t" + \ > + opts + "\t0\t0\n" > fstab_lines.append(fstab_entry) > > def _write_fstab(self, fstab, fstab_lines): -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [dora][PATCHv2] gcc-4.8: backport fix for ICE when building opus
On Fri, Jul 18, 2014 at 01:16:39AM +0200, Martin Jansa wrote:
> From: Martin Jansa
>
> * backported from 4.8.2, so daisy isn't affected
Robert, any eta on this one? If we cannot expect this to be merged in
dora in next few days, let me know and I'll temporary add it to
.bbappends in our layers.
Regards,
> Signed-off-by: Martin Jansa
> ---
> meta/recipes-devtools/gcc/gcc-4.8.inc | 1 +
> .../gcc-4.8/0001-fix-ICE-when-building-opus.patch | 121
> +
> 2 files changed, 122 insertions(+)
> create mode 100644
> meta/recipes-devtools/gcc/gcc-4.8/0001-fix-ICE-when-building-opus.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc
> b/meta/recipes-devtools/gcc/gcc-4.8.inc
> index f1260af..ac205de 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.8.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.8.inc
> @@ -79,6 +79,7 @@ SRC_URI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
> file://0047-repomembug.patch \
> file://0048-PR57532.patch \
> file://0048-PR58854_fix_arm_apcs_epilogue.patch \
> + file://0001-fix-ICE-when-building-opus.patch \
> "
> SRC_URI[md5sum] = "3b2386c114cd74185aa3754b58a79304"
> SRC_URI[sha256sum] =
> "545b44be3ad9f2c4e90e6880f5c9d4f0a8f0e5f67e1ffb0d45da9fa01bb05813"
> diff --git
> a/meta/recipes-devtools/gcc/gcc-4.8/0001-fix-ICE-when-building-opus.patch
> b/meta/recipes-devtools/gcc/gcc-4.8/0001-fix-ICE-when-building-opus.patch
> new file mode 100644
> index 000..9d3aeaa
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-4.8/0001-fix-ICE-when-building-opus.patch
> @@ -0,0 +1,121 @@
> +From 8d8ba86c70381f7c34c22ac6994234d0f3e7 Mon Sep 17 00:00:00 2001
> +From: xguo
> +Date: Fri, 9 Aug 2013 06:59:01 +
> +Subject: [PATCH] gcc/ChangeLog:
> +
> +Backport from mainline:
> +2013-08-09 Zhenqiang Chen
> +
> +* config/arm/neon.md (vcond): Fix floating-point vector
> +comparisons against 0.
> +
> +gcc/testsuite/ChangeLog:
> +
> +Backport from mainline:
> +2013-08-09 Zhenqiang Chen
> +
> +* gcc.target/arm/lp1189445.c: New testcase.
> +
> +Upstream-Status: Backport from 4.8.2
> +Signed-off-by: Martin Jansa
> +
> +More details in:
> +http://gcc.1065356.n5.nabble.com/PATCH-ARM-Fix-unrecognizable-vector-comparisons-td947064.html
> +
> +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@201620
> 138bc75d-0d04-0410-961f-82ee72b054a4
> +---
> + gcc/ChangeLog| 8
> + gcc/config/arm/neon.md | 34
> +++-
> + gcc/testsuite/ChangeLog | 7 +++
> + gcc/testsuite/gcc.target/arm/lp1189445.c | 18 +
> + 4 files changed, 62 insertions(+), 5 deletions(-)
> + create mode 100644 gcc/testsuite/gcc.target/arm/lp1189445.c
> +
> +diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
> +index d8d4202..86a5932 100644
> +--- a/gcc/config/arm/neon.md
> b/gcc/config/arm/neon.md
> +@@ -1732,6 +1732,7 @@
> + ? 3 : 1;
> + rtx magic_rtx = GEN_INT (magic_word);
> + int inverse = 0;
> ++ int use_zero_form = 0;
> + int swap_bsl_operands = 0;
> + rtx mask = gen_reg_rtx (mode);
> + rtx tmp = gen_reg_rtx (mode);
> +@@ -1742,12 +1743,16 @@
> + switch (GET_CODE (operands[3]))
> + {
> + case GE:
> ++case GT:
> + case LE:
> ++case LT:
> + case EQ:
> +- if (!REG_P (operands[5])
> +- && (operands[5] != CONST0_RTX (mode)))
> +-operands[5] = force_reg (mode, operands[5]);
> +- break;
> ++ if (operands[5] == CONST0_RTX (mode))
> ++{
> ++ use_zero_form = 1;
> ++ break;
> ++}
> ++ /* Fall through. */
> + default:
> + if (!REG_P (operands[5]))
> + operands[5] = force_reg (mode, operands[5]);
> +@@ -1798,7 +1803,26 @@
> + a GT b -> a GT b
> + a LE b -> b GE a
> + a LT b -> b GT a
> +- a EQ b -> a EQ b */
> ++ a EQ b -> a EQ b
> ++ Note that there also exist direct comparison against 0 forms,
> ++ so catch those as a special case. */
> ++ if (use_zero_form)
> ++{
> ++ inverse = 0;
> ++ switch (GET_CODE (operands[3]))
> ++{
> ++case LT:
> ++ base_comparison = gen_neon_vclt;
> ++ break;
> ++case LE:
> ++ base_comparison = gen_neon_vcle;
> ++ break;
> ++default:
> ++ /* Do nothing, other zero form cases already have the correct
> ++ base_comparison. */
> ++ break;
> ++}
> ++}
> +
> + if (!inverse)
> + emit_insn (base_comparison (mask, operands[4], operands[5], magic_rtx));
> +diff --git a/gcc/testsuite/gcc.target/arm/lp1189445.c
> b/gcc/testsuite/gcc.target/arm/lp1189445.c
> +new file mode 100644
> +index 000..766748e
> +--- /dev/null
> b/gcc/testsuite/gcc.target/arm/lp1189445.c
> +@@ -0,0 +1,18 @@
> ++/* { dg-do compile } */
> ++/* { dg-r
Re: [OE-core] [PATCH v2] wic: squashfs partition support
On Thu, 2014-07-24 at 14:11 +0200, Maciej Borzecki wrote:
> It is possible to instruct wic to create a squashfs partition by setting
> --fstype=squashfs in *.wks. For now this is only useable for rootfs
> partitions (note that you must have squashfs support in the kernel). An
> attempt to create an empty partition will produce a warning.
>
> Signed-off-by: Maciej Borzecki
Acked-by: Tom Zanussi
> ---
> .../lib/mic/kickstart/custom_commands/partition.py | 61
> ++
> 1 file changed, 61 insertions(+)
>
> diff --git a/scripts/lib/mic/kickstart/custom_commands/partition.py
> b/scripts/lib/mic/kickstart/custom_commands/partition.py
> index d0f1b78..ce90aa1 100644
> --- a/scripts/lib/mic/kickstart/custom_commands/partition.py
> +++ b/scripts/lib/mic/kickstart/custom_commands/partition.py
> @@ -25,6 +25,8 @@
> #
>
> import shutil
> +import os
> +import tempfile
>
> from pykickstart.commands.partition import *
> from mic.utils.oe.misc import *
> @@ -192,6 +194,10 @@ class Wic_PartData(Mic_PartData):
> return self.prepare_rootfs_vfat(cr_workdir, oe_builddir,
> rootfs_dir, native_sysroot,
> pseudo)
> +elif self.fstype.startswith("squashfs"):
> +return self.prepare_rootfs_squashfs(cr_workdir, oe_builddir,
> +rootfs_dir, native_sysroot,
> +pseudo)
>
> def prepare_rootfs_ext(self, cr_workdir, oe_builddir, rootfs_dir,
> native_sysroot, pseudo):
> @@ -324,6 +330,28 @@ class Wic_PartData(Mic_PartData):
> self.set_size(rootfs_size)
> self.set_source_file(rootfs)
>
> +def prepare_rootfs_squashfs(self, cr_workdir, oe_builddir, rootfs_dir,
> +native_sysroot, pseudo):
> +"""
> +Prepare content for a squashfs rootfs partition.
> +"""
> +image_rootfs = rootfs_dir
> +rootfs = "%s/rootfs_%s.%s" % (cr_workdir, self.label ,self.fstype)
> +
> +squashfs_cmd = "mksquashfs %s %s -noappend" % \
> + (image_rootfs, rootfs)
> +rc, out = exec_native_cmd(pseudo + squashfs_cmd, native_sysroot)
> +
> +# get the rootfs size in the right units for kickstart (Mb)
> +du_cmd = "du -Lbms %s" % rootfs
> +rc, out = exec_cmd(du_cmd)
> +rootfs_size = out.split()[0]
> +
> +self.size = rootfs_size
> +self.source_file = rootfs
> +
> +return 0
> +
> def prepare_empty_partition(self, cr_workdir, oe_builddir,
> native_sysroot):
> """
> Prepare an empty partition.
> @@ -337,6 +365,9 @@ class Wic_PartData(Mic_PartData):
> elif self.fstype.startswith("vfat"):
> return self.prepare_empty_partition_vfat(cr_workdir, oe_builddir,
> native_sysroot)
> +elif self.fstype.startswith("squashfs"):
> +return self.prepare_empty_partition_squashfs(cr_workdir,
> oe_builddir,
> + native_sysroot)
>
> def prepare_empty_partition_ext(self, cr_workdir, oe_builddir,
> native_sysroot):
> @@ -398,6 +429,36 @@ class Wic_PartData(Mic_PartData):
>
> return 0
>
> +def prepare_empty_partition_squashfs(self, cr_workdir, oe_builddir,
> + native_sysroot):
> +"""
> +Prepare an empty squashfs partition.
> +"""
> +msger.warning("Creating of an empty squashfs %s partition was
> attempted. " \
> + "Proceeding as requested." % self.mountpoint)
> +
> +fs = "%s/fs_%s.%s" % (cr_workdir, self.label, self.fstype)
> +
> +# it is not possible to create a squashfs without source data,
> +# thus prepare an empty temp dir that is used as source
> +tmpdir = tempfile.mkdtemp()
> +
> +squashfs_cmd = "mksquashfs %s %s -noappend" % \
> + (tmpdir, fs)
> +rc, out = exec_native_cmd(squashfs_cmd, native_sysroot)
> +
> +os.rmdir(tmpdir)
> +
> +# get the rootfs size in the right units for kickstart (Mb)
> +du_cmd = "du -Lbms %s" % fs
> +rc, out = exec_cmd(du_cmd)
> +fs_size = out.split()[0]
> +
> +self.size = fs_size
> +self.source_file = fs
> +
> +return 0
> +
> def prepare_swap_partition(self, cr_workdir, oe_builddir,
> native_sysroot):
> """
> Prepare a swap partition.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Cristian Iorga : qemu: fix qemu-native pkg-config paths
On Fri, Jul 18, 2014 at 10:50:12PM +0200, Martin Jansa wrote:
> On Thu, Jul 03, 2014 at 04:47:08PM +, g...@git.openembedded.org wrote:
> > Module: openembedded-core.git
> > Branch: master
> > Commit: 68a5ed337f8f7ee8e5bf55542ec82d786eb754db
> > URL:
> > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=68a5ed337f8f7ee8e5bf55542ec82d786eb754db
> >
> > Author: Cristian Iorga
> > Date: Thu Jul 3 15:57:32 2014 +0300
> >
> > qemu: fix qemu-native pkg-config paths
> >
> > For qemu-native, the pkg-config paths do not
> > include build host paths.
>
> This breaks qemu-native builds on hosts without pkg-config.
>
> pkg-config isn't in sanity.bbclass's SANITY_REQUIRED_UTILITIES
> and this is first recipe which cannot use pkgconfig-native.
>
> Please add test that it exists before forcing recipe to use it.
ping
> > This is an issue for libsdl for example, where SDL is
> > used by qemu, but for qemu-native libsdl-native is not
> > built, but assumed to be provided by the build host.
> > Because pkg-config do not search for libsdl config files
> > on the build host sysroot, the configure stage of qemu-native
> > will fail because it will not find SDL as being installed.
> > Usually, the isssue is masked by a functional sdl-config that
> > will be interogated instead of pkg-config. However, on Build
> > Appliance, sdl-config is deliberately made non-functional,
> > so the issue manifests itself.
> >
> > The fix will create an extended PKG_CONFIG_PATH, which does
> > include the build host sysroot paths for pkg-config.
> >
> > Fix for [YOCTO #6495].
> >
> > Signed-off-by: Cristian Iorga
> > Signed-off-by: Richard Purdie
> >
> > ---
> >
> > meta/recipes-devtools/qemu/qemu.inc | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/qemu/qemu.inc
> > b/meta/recipes-devtools/qemu/qemu.inc
> > index 076e8ad..611ee61 100644
> > --- a/meta/recipes-devtools/qemu/qemu.inc
> > +++ b/meta/recipes-devtools/qemu/qemu.inc
> > @@ -33,6 +33,10 @@ EXTRA_OECONF_class-nativesdk =
> > "--target-list=${@get_qemu_target_list(d)} --disa
> > export LIBTOOL="${HOST_SYS}-libtool"
> >
> > do_configure_prepend_class-native() {
> > + # Append build host pkg-config paths for native target since the host
> > may provide sdl
> > + BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config --variable pc_path
> > pkg-config)
> > + export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
> > +
> > # Undo the -lX11 added by linker-flags.patch, don't assume that host
> > has libX11 installed
> > sed -i 's/-lX11//g' Makefile.target
> > }
> >
> > --
> > ___
> > Openembedded-commits mailing list
> > openembedded-comm...@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-commits
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
--
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] ptest formatting
Hi, On 7/24/2014 19:40, Eric Yu wrote: > Hello, >My name is Eric Yu, and I am an intern at National Instruments for > this summer. The project I am currently > working on involves integrating ptest with our current automated testing > framework to help test our open- > embedded distributions. On the Yocto Project wiki, it states that one major > point of ptest is to consolidate the > output of different package tests in a common “: ” format. > I was hoping that this common > format would allow ptest results to be easily machine parsed and integrated > with our current testing framework. > However, after enabling and running the ptests, I discovered that the > formatting of the results was not as > friendly to automation as I had hoped. > > It appears that each separate package prints out its own errors, warnings, > and other output along with these > test results, burying the common output in lots of other text. Indeed (one of) the purpose of ptest is to facilitate automation by using the common : format. However, ptest should not filter the output of a package test (so that the automation could be done easier). That output might be useful in later investigation about why a test failed and further improving the package (testing). Is should be easier to implement this filter in your automation scripts. > > Also, one package (gdk-pixbuff) used “FAILED” when reporting results rather > than the expected “FAIL”. This sounds like a bug. You can help us sending a patch for this. :) > > In the bash ptests, several tests print warnings saying to ignore failures > where the output differs only by > whitespace. This seems to be bad practice for test writing and is not > friendly to automated analysis of test > results. This is a good example to support my statement above: While automation scripts may easily add some PASS, FAIL, SKIP, XFAIL, XPASS and ERROR entries into a database, those (additional) warning are helpful for people interested in improving bash (an bash testing), hence the output should be kept along with the results. > > At the conclusion of each ptest, some packages give a summary of how many > tests were passed, skipped, and > failed, while others do not. I find that having these summaries gives a > useful overview of how the test went > overall and is a good reference in case some tests fail to produce the common > “: ” output. > > I understand that much of this is due to the fact that separate developers > write the tests for different packages, > but it would be beneficial if ptest was friendlier to automated parsing and > analysis of test results. Currently, I > have addressed some of these obstacles by writing a simple script that parses > the output of each ptest and only > outputs only the “: ” results while accounting for both > “FAIL” and “FAILED”. The script keeps > a running count of how many tests were reported as failed, skipped or passed, > and at the conclusion of each > ptest, the script prints a summary including the number of tests passed, > skipped, and failed along with a total > number of tests run. While this works with the current set of ptests, as more > and more packages add ptest > functionality, this script may not scale well if more inconsistencies in > formatting are introduced. Therefore, I > believe it would be a good idea to enforce a more consistent formatting of > ptest results to assist in the use of > ptest for automated testing. Are there any plans to further consolidate the > ptest result format such that it is > more accessible for automated testing? I hope I have answered at least partially to your questions above. Kind regards, Tudor. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/8] lttng-modules: re-enable ARM builds
On Thu, Jul 24, 2014 at 04:41:52PM -0400, Bruce Ashfield wrote: > With lttng 2.4.2 and gcc 4.9, we can now enable lttng-modules for ARM. > > Signed-off-by: Bruce Ashfield > --- > meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb > b/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb > index 5a99a5adae8b..d87374163556 100644 > --- a/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb > +++ b/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb > @@ -12,8 +12,7 @@ inherit module > > SRCREV = "789fd1d06d07aeb9a403bdce1b3318560cfc6eca" > > -# lttng currently blacklists arm with gcc-4.8 > -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips).*-linux' > +COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|arm).*-linux' Please squash this to 2/8 otherwise there is no arm version between 2/8 and 6/8. > SRC_URI = "git://git.lttng.org/lttng-modules.git;branch=stable-2.5 \ > file://lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch \ > -- > 1.8.1.2 > > -- > ___ > 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] eglibc: Make ld.so.conf more flexible
On Wed, 23 Jul 2014 20:59:27 -0500 Mark Hatle wrote: > The later has been requested of me many times, but we've not implemented it > generically. I think it's time to do so -- but it should be tied to > USE_LDCONFIG at a minimum, I just don't know if it should always be enabled > or > just sometimes. (Always means the ld.so.conf file gets the include line, so > it's NOT a lot of bytes.) It's not a lot of bytes, but it's a non-zero increase in effort for ldconfig compared to an empty file. Although I assume ldconfig checks /usr/lib* automatically, so this would be <1% anyway. -s -- Listen, get this. Nobody with a good compiler needs to be justified. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cross-canadian: Copy target_ definitions from cross.bbclass
On 7/24/14, 4:09 PM, Richard Purdie wrote:
A while back we fixed the cross definitions to work better in multilib
configurations, apply the same fixes to cross-candian.bbclass
Signed-off-by: Richard Purdie
Tested this
Acked-by: Mark Hatle
diff --git a/meta/classes/cross-canadian.bbclass
b/meta/classes/cross-canadian.bbclass
index e536118..6da43fe 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -84,11 +84,12 @@ EXTRANATIVEPATH += "chrpath-native"
# Path mangling needed by the cross packaging
# Note that we use := here to ensure that libdir and includedir are
# target paths.
-target_libdir := "${libdir}"
-target_includedir := "${includedir}"
-target_base_libdir := "${base_libdir}"
+target_base_prefix := "${base_prefix}"
target_prefix := "${prefix}"
target_exec_prefix := "${exec_prefix}"
+target_base_libdir = "${target_base_prefix}/${baselib}"
+target_libdir = "${target_exec_prefix}/${baselib}"
+target_includedir := "${includedir}"
# Change to place files in SDKPATH
base_prefix = "${SDKPATHNATIVE}"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] populate_sdk_base: Extend TOOLCHAIN_TARGET_TASK to include multilib variants
On 7/24/14, 4:09 PM, Richard Purdie wrote:
Most people expect the toolchain from a multilib build to contain multilib
components. This change makes that happen and is easy for users to override
should they want something different.
Signed-off-by: Richard Purdie
I tested this (with ipk works, with rpm doesn't work any less then it did
before...)
Acked-by: Mark Hatle
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index 0df98db..4b489a6 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -32,7 +32,10 @@ SDKTARGETSYSROOT =
"${SDKPATH}/sysroots/${REAL_MULTIMACH_TARGET_SYS}"
TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host
packagegroup-cross-canadian-${MACHINE}"
TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
-TOOLCHAIN_TARGET_TASK ?= "packagegroup-core-standalone-sdk-target
packagegroup-core-standalone-sdk-target-dbg"
+TOOLCHAIN_TARGET_TASK ?= " \
+${@multilib_pkg_extend(d, 'packagegroup-core-standalone-sdk-target')} \
+${@multilib_pkg_extend(d, 'packagegroup-core-standalone-sdk-target-dbg')} \
+"
TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] binutils-cross-canadian: Explicitly DEPEND on nativesdk-flex, we require it anyway
Signed-off-by: Richard Purdie
diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
index 52c573e..ae14642 100644
--- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
+++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
@@ -4,7 +4,7 @@ SUMMARY = "GNU binary utilities (cross-canadian for
${TARGET_ARCH} target)"
PN = "binutils-cross-canadian-${TRANSLATED_TARGET_ARCH}"
BPN = "binutils"
-DEPENDS = "flex-native bison-native virtual/${HOST_PREFIX}gcc-crosssdk
virtual/nativesdk-libc nativesdk-zlib nativesdk-gettext"
+DEPENDS = "flex-native bison-native virtual/${HOST_PREFIX}gcc-crosssdk
virtual/nativesdk-libc nativesdk-zlib nativesdk-gettext nativesdk-flex"
EXTRA_OECONF +=
"--with-sysroot=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}
\
"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qemu: Use PACKAGECONFIG for libusb to avoid floating dependency
Signed-off-by: Richard Purdie diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index ccd7908..3cb8536 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -100,6 +100,7 @@ PACKAGECONFIG[gtk+] = "--enable-gtk,--disable-gtk,gtk+ libvte," PACKAGECONFIG[libcap-ng] = "--enable-cap-ng,--disable-cap-ng,libcap-ng," PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,libsdl," PACKAGECONFIG[ssh2] = "--enable-libssh2,--disable-libssh2,libssh2," +PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1" # Qemu target will not build in world build for ARM or Mips BROKEN_qemuarm = "1" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cross-canadian: Copy target_ definitions from cross.bbclass
A while back we fixed the cross definitions to work better in multilib
configurations, apply the same fixes to cross-candian.bbclass
Signed-off-by: Richard Purdie
diff --git a/meta/classes/cross-canadian.bbclass
b/meta/classes/cross-canadian.bbclass
index e536118..6da43fe 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -84,11 +84,12 @@ EXTRANATIVEPATH += "chrpath-native"
# Path mangling needed by the cross packaging
# Note that we use := here to ensure that libdir and includedir are
# target paths.
-target_libdir := "${libdir}"
-target_includedir := "${includedir}"
-target_base_libdir := "${base_libdir}"
+target_base_prefix := "${base_prefix}"
target_prefix := "${prefix}"
target_exec_prefix := "${exec_prefix}"
+target_base_libdir = "${target_base_prefix}/${baselib}"
+target_libdir = "${target_exec_prefix}/${baselib}"
+target_includedir := "${includedir}"
# Change to place files in SDKPATH
base_prefix = "${SDKPATHNATIVE}"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oe/classextend: Avoid early expansion of PR values
Variables like RDEPENDS can contain EXTENDPKGV which in turn uses AUTOPR
based values. This gets set during do_package execution so we want to
defer expansion until then. The only way we can do this in the RDEPENDS
(and friends) mapping code is to subsitute a dummy value, then change it
back again. Horrible but I can't see any other way.
This resolves multilib build failures with inconsistent PR values.
Signed-off-by: Richard Purdie
diff --git a/meta/lib/oe/classextend.py b/meta/lib/oe/classextend.py
index 71c7759..68efca3 100644
--- a/meta/lib/oe/classextend.py
+++ b/meta/lib/oe/classextend.py
@@ -60,17 +60,22 @@ class ClassExtender(object):
return self.extend_name(dep)
def map_depends_variable(self, varname, suffix = ""):
+# We need to preserve EXTENDPKGV so it can be expanded correctly later
if suffix:
varname = varname + "_" + suffix
+orig = self.d.getVar("EXTENDPKGV", False)
+self.d.setVar("EXTENDPKGV", "EXTENDPKGV")
deps = self.d.getVar(varname, True)
if not deps:
+self.d.setVar("EXTENDPKGV", orig)
return
deps = bb.utils.explode_dep_versions2(deps)
newdeps = {}
for dep in deps:
newdeps[self.map_depends(dep)] = deps[dep]
-self.d.setVar(varname, bb.utils.join_deps(newdeps, False))
+self.d.setVar(varname, bb.utils.join_deps(newdeps,
False).replace("EXTENDPKGV", "${EXTENDPKGV}"))
+self.d.setVar("EXTENDPKGV", orig)
def map_packagevars(self):
for pkg in (self.d.getVar("PACKAGES", True).split() + [""]):
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc-multilib: Simply/fix MULTILIB_OPTIONS handling
MULTILIB_OPTIONS takes the parameters which trigger a given multilib to be
selected. It supports *one* option per multilib, '/' separated. Spaces
separate options used to generate additional multilib combinations.
Adding in all of CFLAGS to this is therefore clearly a really bad idea
but how do we fix things?
The best option I've come up with so far is a list of whitelist variables
to use to trigger the multilibs. Its populated with the standard multilibs
we support, anyone setting up an advanced multilib can populate the variable
with the correct trigger parameters.
This has the advantage of simplifying the code and allowing us to remove
the code filtering blocks since there is no longer option duplication. Testing
after this change shows a much improved sdk toolchain functionality.
Signed-off-by: Richard Purdie
diff --git a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
index acea6d8..b8c705a 100644
--- a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
+++ b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
@@ -14,6 +14,8 @@
#gcc/config/mips/linux64.h
#gcc/config/rs6000/linux64.h
+MULTILIB_OPTION_WHITELIST ??= "-m32 -m64 -mx32 -mabi=n32 -mabi=32 -mabi=64"
+
python gcc_multilib_setup() {
import re
import shutil
@@ -187,30 +189,19 @@ python gcc_multilib_setup() {
bb.error('Unknown libdir (%s) of the tune : %s' % (tune_baselib,
tune))
# take out '-' mcpu='s and march='s from parameters
-options.append(re.sub(r'mcpu=[^ ]+ *', '',
- re.sub(r'march=[^ ]+ *', '',
- re.sub(r' +\-+', ' ',
- re.sub(r'^ *\-+', '',
tune_parameters['ccargs'])
+opts = []
+whitelist = (d.getVar("MULTILIB_OPTION_WHITELIST", True) or "").split()
+for i in tune_parameters['ccargs'].split():
+if i in whitelist:
+opts.append(i)
+options.append(" ".join(opts))
+
if tune_baselib == 'lib':
dirnames.append('32') # /lib => 32bit lib
else:
dirnames.append(tune_baselib.replace('lib', ''))
osdirnames.append('../' + tune_baselib)
-if len(options) > 1:
-for optstr in options:
-optsets.append(optstr.split())
-
-#get common options present in all the tune parameters
-common_opt_set = set.intersection(*map(set, optsets))
-
-#common options will be added at the end of the options string only once
-if (len(common_opt_set) > 0):
-rex = re.compile(''.join(['\\b(', '|'.join(common_opt_set),
')\\W']), re.I)
-options = [rex.sub("", optstr) for optstr in options]
-options = [optstr.strip() for optstr in options]
-options[len(options)-1] = ' '.join((options[len(options)-1], '
'.join(common_opt_set)))
-
write_config(builddir, target_config_files, options, dirnames, osdirnames)
write_headers(builddir, header_config_files, libdir32, libdir64,
libdirx32, libdirn32)
}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk_base: Extend TOOLCHAIN_TARGET_TASK to include multilib variants
Most people expect the toolchain from a multilib build to contain multilib
components. This change makes that happen and is easy for users to override
should they want something different.
Signed-off-by: Richard Purdie
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index 0df98db..4b489a6 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -32,7 +32,10 @@ SDKTARGETSYSROOT =
"${SDKPATH}/sysroots/${REAL_MULTIMACH_TARGET_SYS}"
TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host
packagegroup-cross-canadian-${MACHINE}"
TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
-TOOLCHAIN_TARGET_TASK ?= "packagegroup-core-standalone-sdk-target
packagegroup-core-standalone-sdk-target-dbg"
+TOOLCHAIN_TARGET_TASK ?= " \
+${@multilib_pkg_extend(d, 'packagegroup-core-standalone-sdk-target')} \
+${@multilib_pkg_extend(d, 'packagegroup-core-standalone-sdk-target-dbg')} \
+"
TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/8] kernel: linux-yocto 3.14, linux-yocto-dev 3.16 and dependencies
Richard/Saul,
Here are my consolidated changes for kernel updates.
For 3.14:
linux-yocto/3.14: vexpress and MVM firmware support
linux-yocto: x86_64: expand kernel stack to 16K
linux-yocto/3.14: libata and generic CPU modalias handling
For linux-yocto-dev:
linux-yocto-dev: bump to v3.16+
lttng-modules: update to 2.5.0
kernel: don't copy .so.dbg files into kernel source install
kern-tools: adjust to full history meta-data
And for lttng on ARM:
lttng-modules: re-enable ARM builds
I've built and booted 3.16 on all the architectures, and also build my
kernel-dev image type (which includes package that often break with
kernel updates, and which I'll submit to oe-core separately). That's
where the .so.db change for kernel.bbclass and the lttng update
have come from.
Cheers,
Bruce
The following changes since commit 8b7116d25ed6255a03895d835e5a0560858ab496:
bitbake: Updated the the example 'bitbake -h' output to match the actual
output, which has been recently patched to fix the '-S SIGNATURE_HANDLER,
--dump-signatures=SIGNATURE_HANDLER' option. (2014-07-22 08:33:25 +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 (8):
linux-yocto/3.14: vexpress and MVM firmware support
lttng-modules: update to 2.5.0
linux-yocto: x86_64: expand kernel stack to 16K
linux-yocto-dev: bump to v3.16+
kernel: don't copy .so.dbg files into kernel source install
lttng-modules: re-enable ARM builds
linux-yocto/3.14: libata and generic CPU modalias handling
kern-tools: adjust to full history meta-data
meta/classes/kernel.bbclass| 2 +-
.../kern-tools/kern-tools-native_git.bb| 2 +-
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb | 6 +-
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 4 +-
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 16 ++---
...compaction-instrumentation-to-3.16-kernel.patch | 83 ++
...ate-vmscan-instrumentation-to-3.16-kernel.patch | 70 ++
meta/recipes-kernel/lttng/lttng-modules_2.3.3.bb | 36 --
...tng-modules_2.4.1.bb => lttng-modules_2.5.0.bb} | 10 +--
10 files changed, 174 insertions(+), 57 deletions(-)
create mode 100644
meta/recipes-kernel/lttng/lttng-modules/Update-compaction-instrumentation-to-3.16-kernel.patch
create mode 100644
meta/recipes-kernel/lttng/lttng-modules/Update-vmscan-instrumentation-to-3.16-kernel.patch
delete mode 100644 meta/recipes-kernel/lttng/lttng-modules_2.3.3.bb
rename meta/recipes-kernel/lttng/{lttng-modules_2.4.1.bb =>
lttng-modules_2.5.0.bb} (80%)
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/8] kernel: don't copy .so.dbg files into kernel source install
In 3.16+ x86-64 kernel builds produce a vdso64.so.dbg file. If this file is
copied into the kernel source install multiple QA failures are triggered.
Specifically, this file triggers a debug package split that results in
files installed but not shipped, and invalid .debug file errors.
By ensuring that .so files are not copied, we avoid this incorrect split
with no impact on future build phases.
Signed-off-by: Bruce Ashfield
---
meta/classes/kernel.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b2e9d4cb3631..128987303233 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -232,7 +232,7 @@ kernel_do_install() {
# dir. This ensures the original Makefiles are used and not the
# redirecting Makefiles in the build directory.
#
- find . -depth -not -name "*.cmd" -not -name "*.o" -not -path
"./Documentation*" -not -path "./source*" -not -path "./.*" -print0 | cpio
--null -pdlu $kerneldir
+ find . -depth -not -name "*.cmd" -not -name "*.o" -not -name "*.so.dbg"
-not -path "./Documentation*" -not -path "./source*" -not -path "./.*" -print0
| cpio --null -pdlu $kerneldir
cp .config $kerneldir
if [ "${S}" != "${B}" ]; then
pwd="$PWD"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/8] lttng-modules: re-enable ARM builds
With lttng 2.4.2 and gcc 4.9, we can now enable lttng-modules for ARM. Signed-off-by: Bruce Ashfield --- meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb b/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb index 5a99a5adae8b..d87374163556 100644 --- a/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb +++ b/meta/recipes-kernel/lttng/lttng-modules_2.5.0.bb @@ -12,8 +12,7 @@ inherit module SRCREV = "789fd1d06d07aeb9a403bdce1b3318560cfc6eca" -# lttng currently blacklists arm with gcc-4.8 -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips).*-linux' +COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|arm).*-linux' SRC_URI = "git://git.lttng.org/lttng-modules.git;branch=stable-2.5 \ file://lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch \ -- 1.8.1.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/8] linux-yocto: x86_64: expand kernel stack to 16K
Updating to backport the following mainline commit:
[
x86_64: expand kernel stack to 16K
commit 6538b8ea886e472f4431db8ca1d60478f838d14b upstream
While I play inhouse patches with much memory pressure on qemu-kvm,
3.14 kernel was randomly crashed. The reason was kernel stack overflow.
When I investigated the problem, the callstack was a little bit deeper
by involve with reclaim functions but not direct reclaim path.
]
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 14 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
index 61f9dbc9a14e..da84c787f0ec 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
@@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = "standard/preempt-rt/base"
KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
-SRCREV_machine ?= "568f018a22474939695a31709802bb8863c483d9"
-SRCREV_machine_qemuppc ?= "6af424a3a76a7fcf0cc7718b93f7a9db52383c25"
+SRCREV_machine ?= "a70496be11fee0166481b1917745496e7eed863f"
+SRCREV_machine_qemuppc ?= "e8684b6b9919daea3e87c1e28efec0b3f39a3da7"
SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
index 98381606ebb0..3c116e4be0ad 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -8,7 +8,7 @@ LINUX_VERSION ?= "3.14.5"
KMETA = "meta"
-SRCREV_machine ?= "686b9ddf58ea6b533be70fe9f4a6407557b263d2"
+SRCREV_machine ?= "5bee7e1583d4f075ac5a96d121271b347b384fd7"
SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
index 02909b79c029..031d2e546185 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -10,13 +10,13 @@ KBRANCH_qemux86 = "standard/common-pc/base"
KBRANCH_qemux86-64 = "standard/common-pc-64/base"
KBRANCH_qemumips64 = "standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "e3cbee86dcbc6c9b23a7cf69fe579da77c3836d1"
-SRCREV_machine_qemumips ?= "431de4758042fab2d62269574bb4ec3a783b43a0"
-SRCREV_machine_qemuppc ?= "1fc7009c9c8de594d75090b188c11a6ddd0d369e"
-SRCREV_machine_qemux86 ?= "116dacb5cebba538bc70e8056ebfa81d7ca6c061"
-SRCREV_machine_qemux86-64 ?= "686b9ddf58ea6b533be70fe9f4a6407557b263d2"
-SRCREV_machine_qemumips64 ?= "966c54ceb8cb797eafe987f9a16d306735057b42"
-SRCREV_machine ?= "686b9ddf58ea6b533be70fe9f4a6407557b263d2"
+SRCREV_machine_qemuarm ?= "ed834b297cd5d36b303d36119549b90789e2890e"
+SRCREV_machine_qemumips ?= "12eba41a9a3bb017dcb45e721f20d7e68903b1c3"
+SRCREV_machine_qemuppc ?= "e2dbfaf796b18b0b9918f194e2a4c9e9eded0c2c"
+SRCREV_machine_qemux86 ?= "e8eb08d85050a944582e974cd461f741191bd07c"
+SRCREV_machine_qemux86-64 ?= "5bee7e1583d4f075ac5a96d121271b347b384fd7"
+SRCREV_machine_qemumips64 ?= "4ecb96fcb1826a127d6afbf67b8e69cccd7ccc8e"
+SRCREV_machine ?= "5bee7e1583d4f075ac5a96d121271b347b384fd7"
SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/8] linux-yocto/3.14: libata and generic CPU modalias handling
Updating the 3.14 yocto kernel to incorporate the following fix
and feature of interest.
5724bf17acbf x86: align x86 arch with generic CPU modalias handling
6b9a52451a78 cpu: add generic support for CPU feature based module
38367de316bb libata: support the ata host which implements a queue depth less
than 32
[YOCTO: #6489]
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 14 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
index da84c787f0ec..77215f6a517e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
@@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = "standard/preempt-rt/base"
KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
-SRCREV_machine ?= "a70496be11fee0166481b1917745496e7eed863f"
-SRCREV_machine_qemuppc ?= "e8684b6b9919daea3e87c1e28efec0b3f39a3da7"
+SRCREV_machine ?= "8ef1733b66a1646b85338a310f787e0057a6a4e9"
+SRCREV_machine_qemuppc ?= "3079c794c30b0de82bc87b19cf477d82405a9094"
SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
index 3c116e4be0ad..e28054fc4cf4 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -8,7 +8,7 @@ LINUX_VERSION ?= "3.14.5"
KMETA = "meta"
-SRCREV_machine ?= "5bee7e1583d4f075ac5a96d121271b347b384fd7"
+SRCREV_machine ?= "5724bf17acbf54cf61003ab242448fd96d189384"
SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
index 031d2e546185..7b8b65382775 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -10,13 +10,13 @@ KBRANCH_qemux86 = "standard/common-pc/base"
KBRANCH_qemux86-64 = "standard/common-pc-64/base"
KBRANCH_qemumips64 = "standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "ed834b297cd5d36b303d36119549b90789e2890e"
-SRCREV_machine_qemumips ?= "12eba41a9a3bb017dcb45e721f20d7e68903b1c3"
-SRCREV_machine_qemuppc ?= "e2dbfaf796b18b0b9918f194e2a4c9e9eded0c2c"
-SRCREV_machine_qemux86 ?= "e8eb08d85050a944582e974cd461f741191bd07c"
-SRCREV_machine_qemux86-64 ?= "5bee7e1583d4f075ac5a96d121271b347b384fd7"
-SRCREV_machine_qemumips64 ?= "4ecb96fcb1826a127d6afbf67b8e69cccd7ccc8e"
-SRCREV_machine ?= "5bee7e1583d4f075ac5a96d121271b347b384fd7"
+SRCREV_machine_qemuarm ?= "b38b84aebf889d84e65e81ac11122b977f0c5155"
+SRCREV_machine_qemumips ?= "c9d827207d8dfab330787659b2842485dbd36d77"
+SRCREV_machine_qemuppc ?= "58b7cb00580985410ba8491c61e80d2572552ed9"
+SRCREV_machine_qemux86 ?= "5b327970eb1dba02c65cb8330dc8f3049c4fa580"
+SRCREV_machine_qemux86-64 ?= "5724bf17acbf54cf61003ab242448fd96d189384"
+SRCREV_machine_qemumips64 ?= "34837892b66eaa034cd3e3d339cab0ea6f594511"
+SRCREV_machine ?= "5724bf17acbf54cf61003ab242448fd96d189384"
SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/8] linux-yocto-dev: bump to v3.16+
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 9b49eee87651..10f3d234ed25 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -36,7 +36,7 @@ SRC_URI =
"git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=${K
SRCREV_machine ?=
'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e",
d)}'
SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e",
d)}'
-LINUX_VERSION ?= "3.14+"
+LINUX_VERSION ?= "3.16+"
LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
PV = "${LINUX_VERSION}+git${SRCPV}"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/8] lttng-modules: update to 2.5.0
During the uprev of the yocto kernel to 3.16, lttng-modules failed to build.
To grab the latest stable content, we update to 2.5.0, and add two patches
to also make it build against 3.16+.
We also drop the older 2.3.3 lttng-modules, since it is no longer required
to support ARM builds.
Signed-off-by: Bruce Ashfield
---
...compaction-instrumentation-to-3.16-kernel.patch | 83 ++
...ate-vmscan-instrumentation-to-3.16-kernel.patch | 70 ++
meta/recipes-kernel/lttng/lttng-modules_2.3.3.bb | 36 --
...tng-modules_2.4.1.bb => lttng-modules_2.5.0.bb} | 7 +-
4 files changed, 157 insertions(+), 39 deletions(-)
create mode 100644
meta/recipes-kernel/lttng/lttng-modules/Update-compaction-instrumentation-to-3.16-kernel.patch
create mode 100644
meta/recipes-kernel/lttng/lttng-modules/Update-vmscan-instrumentation-to-3.16-kernel.patch
delete mode 100644 meta/recipes-kernel/lttng/lttng-modules_2.3.3.bb
rename meta/recipes-kernel/lttng/{lttng-modules_2.4.1.bb =>
lttng-modules_2.5.0.bb} (85%)
diff --git
a/meta/recipes-kernel/lttng/lttng-modules/Update-compaction-instrumentation-to-3.16-kernel.patch
b/meta/recipes-kernel/lttng/lttng-modules/Update-compaction-instrumentation-to-3.16-kernel.patch
new file mode 100644
index ..0a056a947570
--- /dev/null
+++
b/meta/recipes-kernel/lttng/lttng-modules/Update-compaction-instrumentation-to-3.16-kernel.patch
@@ -0,0 +1,83 @@
+From 0007344741ef65259bc52dea72259173dfbf96c0 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers
+Date: Sun, 13 Jul 2014 13:33:21 -0400
+Subject: [PATCH 2/2] Update compaction instrumentation to 3.16 kernel
+
+Signed-off-by: Mathieu Desnoyers
+---
+ instrumentation/events/lttng-module/compaction.h | 45 +++-
+ 1 file changed, 44 insertions(+), 1 deletion(-)
+
+diff --git a/instrumentation/events/lttng-module/compaction.h
b/instrumentation/events/lttng-module/compaction.h
+index 1b237fa45ab0..22024e9ee582 100644
+--- a/instrumentation/events/lttng-module/compaction.h
b/instrumentation/events/lttng-module/compaction.h
+@@ -6,6 +6,7 @@
+
+ #include
+ #include
++#include
+ #include
+
+ DECLARE_EVENT_CLASS(mm_compaction_isolate_template,
+@@ -45,6 +46,48 @@ DEFINE_EVENT(mm_compaction_isolate_template,
mm_compaction_isolate_freepages,
+ TP_ARGS(nr_scanned, nr_taken)
+ )
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0))
++TRACE_EVENT(mm_compaction_migratepages,
++
++ TP_PROTO(unsigned long nr_all,
++ int migrate_rc,
++ struct list_head *migratepages),
++
++ TP_ARGS(nr_all, migrate_rc, migratepages),
++
++ TP_STRUCT__entry(
++ __field(unsigned long, nr_migrated)
++ __field(unsigned long, nr_failed)
++ ),
++
++ TP_fast_assign(
++ tp_assign(nr_migrated,
++ nr_all -
++ (migrate_rc >= 0 ? migrate_rc :
++ ({
++ unsigned long nr_failed = 0;
++ struct list_head *page_lru;
++
++ list_for_each(page_lru, migratepages)
++ nr_failed++;
++ nr_failed;
++ })))
++ tp_assign(nr_failed,
++ ({
++ unsigned long nr_failed = 0;
++ struct list_head *page_lru;
++
++ list_for_each(page_lru, migratepages)
++ nr_failed++;
++ nr_failed;
++ }))
++ ),
++
++ TP_printk("nr_migrated=%lu nr_failed=%lu",
++ __entry->nr_migrated,
++ __entry->nr_failed)
++)
++#else /* #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0)) */
+ TRACE_EVENT(mm_compaction_migratepages,
+
+ TP_PROTO(unsigned long nr_migrated,
+@@ -66,7 +109,7 @@ TRACE_EVENT(mm_compaction_migratepages,
+ __entry->nr_migrated,
+ __entry->nr_failed)
+ )
+-
++#endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0)) */
+
+ #endif /* _TRACE_COMPACTION_H */
+
+--
+1.8.1.2
+
diff --git
a/meta/recipes-kernel/lttng/lttng-modules/Update-vmscan-instrumentation-to-3.16-kernel.patch
b/meta/recipes-kernel/lttng/lttng-modules/Update-vmscan-instrumentation-to-3.16-kernel.patch
new file mode 100644
index ..5f02270e89c1
--- /dev/null
+++
b/meta/recipes-kernel/lttng/lttng-modules/Update-vmscan-instrumentation-to-3.16-kernel.patch
@@ -0,0 +1,70 @@
+From 5defe623568273e9b87da1b817e373ff087fd862 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers
+Date: Sun, 13 Jul 2014 13:27:01 -0400
+Subject: [PATCH 1/2] Update vmscan instrumentation to 3.16 kernel
+
+Signed-off-by: Mathieu Desnoyers
+---
+ instrumentation/events/ltt
[OE-core] [PATCH 1/8] linux-yocto/3.14: vexpress and MVM firmware support
Updating the 3.14 SRCREVs to integrate the following changes:
meta: iwlwifi: Add MVM firmware support
vexpress: Pass LOADADDR to Makefile
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb | 6 +++---
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto_3.14.bb | 16
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
index 6d5096cd8565..61f9dbc9a14e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
@@ -3,9 +3,9 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = "standard/preempt-rt/base"
KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
-SRCREV_machine ?= "5c79217cdf1c16a3cacd28968e8c3e417e994c86"
-SRCREV_machine_qemuppc ?= "1ad208565754a1122df5500246f3142e2a3eff39"
-SRCREV_meta ?= "602be954ac45e8aea06cb93d6766bbf83c242090"
+SRCREV_machine ?= "568f018a22474939695a31709802bb8863c483d9"
+SRCREV_machine_qemuppc ?= "6af424a3a76a7fcf0cc7718b93f7a9db52383c25"
+SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
index 7eb90a6929a8..98381606ebb0 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -8,8 +8,8 @@ LINUX_VERSION ?= "3.14.5"
KMETA = "meta"
-SRCREV_machine ?= "96930820e0cb6d4b31d5e0c8f3174805f4a868b3"
-SRCREV_meta ?= "602be954ac45e8aea06cb93d6766bbf83c242090"
+SRCREV_machine ?= "686b9ddf58ea6b533be70fe9f4a6407557b263d2"
+SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
index 1bdf520a9249..02909b79c029 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -10,14 +10,14 @@ KBRANCH_qemux86 = "standard/common-pc/base"
KBRANCH_qemux86-64 = "standard/common-pc-64/base"
KBRANCH_qemumips64 = "standard/mti-malta64"
-SRCREV_machine_qemuarm ?= "2489f1f4d7aa27bf0808d7fa80a50399c643516d"
-SRCREV_machine_qemumips ?= "63b4ca3223d9481baa77f527f50d906d15747141"
-SRCREV_machine_qemuppc ?= "e5dfe8f89b45effe445d04e0f9b391948eb108ae"
-SRCREV_machine_qemux86 ?= "41d5fe27dc3d3e769cb6af01770cac3d75a91e1a"
-SRCREV_machine_qemux86-64 ?= "96930820e0cb6d4b31d5e0c8f3174805f4a868b3"
-SRCREV_machine_qemumips64 ?= "103df748c6e83d5874a8385592f758feeb818324"
-SRCREV_machine ?= "96930820e0cb6d4b31d5e0c8f3174805f4a868b3"
-SRCREV_meta ?= "602be954ac45e8aea06cb93d6766bbf83c242090"
+SRCREV_machine_qemuarm ?= "e3cbee86dcbc6c9b23a7cf69fe579da77c3836d1"
+SRCREV_machine_qemumips ?= "431de4758042fab2d62269574bb4ec3a783b43a0"
+SRCREV_machine_qemuppc ?= "1fc7009c9c8de594d75090b188c11a6ddd0d369e"
+SRCREV_machine_qemux86 ?= "116dacb5cebba538bc70e8056ebfa81d7ca6c061"
+SRCREV_machine_qemux86-64 ?= "686b9ddf58ea6b533be70fe9f4a6407557b263d2"
+SRCREV_machine_qemumips64 ?= "966c54ceb8cb797eafe987f9a16d306735057b42"
+SRCREV_machine ?= "686b9ddf58ea6b533be70fe9f4a6407557b263d2"
+SRCREV_meta ?= "b2af4e3528e65583c98f3a08c6edb0cad7a120b0"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 8/8] kern-tools: adjust to full history meta-data
In order to generate and support kernel trees with full history, we need
to modify the kernel tools
e914d570232a kgit-checkpoint: ensure that full meta-data artifacts are
maintained
192be836d318 kgit-scc: allow meta-data history to be maintained
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 1a2f881c7abf..24263e5d2b7e 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 = "a42509b01ccfe5020a226b23d3a52c07b3fb2051"
+SRCREV = "e914d570232a5a6aa47b721dafbab4af4209d93c"
PR = "r12"
PV = "0.2+git${SRCPV}"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] allarch: Generate same package for MIPS and non-MIPS targets
On Thu, Jul 24, 2014 at 4:24 AM, Mike Crowe wrote:
> LINKER_HASH_STYLE differs between MIPS and non-MIPS targets. This means
> that LDFLAGS differs too. LDFLAGS is exported so it influences all task
> hashes. Unfortunately this means that packages with architecture "all"
> differ depending on whether they are built for a MIPS or non-MIPS target.
> This causes a lot of unnecessary churn in the ipk/all directory when
> switching build targets.
>
> The simplest way to fix this is to ensure that LDFLAGS stays the same for
> architecture "all" packages by clearing it. It shouldn't being used by such
> packages anyway.
>
> Signed-off-by: Mike Crowe
> ---
> meta/classes/allarch.bbclass | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> index d41dd4b..c953e7c 100644
> --- a/meta/classes/allarch.bbclass
> +++ b/meta/classes/allarch.bbclass
> @@ -28,6 +28,11 @@ python () {
> d.setVar("SDK_ARCH", "none")
> d.setVar("SDK_CC_ARCH", "none")
>
> +# Avoid this being unnecessarily different due to nuances of
> +# the target machine that aren't important for "all" arch
> +# packages.
> +d.setVar("LDFLAGS", "")
> +
Looks good.
> # No need to do shared library processing or debug symbol handling
> d.setVar("EXCLUDE_FROM_SHLIBS", "1")
> d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
> --
> 2.0.1
>
> --
> ___
> 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] [PATCH] libice: fix non-deterministic libbsd dependency
libice 1.0.9 added automatic detection of arc4random(), which is in libbsd on Linux. As this is automatic and leads to failing builds when ssstate is reused, seed the autoconf cache as relevant to implement a PACKAGECONFIG for the functionality. Default to not using arc4random() as the fallback has been in use for many years, but people interested in security may wish to turn this on to increase the security of the X authentication cookies. Signed-off-by: Ross Burton --- meta/recipes-graphics/xorg-lib/libice_1.0.9.bb |3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-graphics/xorg-lib/libice_1.0.9.bb b/meta/recipes-graphics/xorg-lib/libice_1.0.9.bb index 314d281..c55f5a1 100644 --- a/meta/recipes-graphics/xorg-lib/libice_1.0.9.bb +++ b/meta/recipes-graphics/xorg-lib/libice_1.0.9.bb @@ -22,3 +22,6 @@ BBCLASSEXTEND = "native" SRC_URI[md5sum] = "addfb1e897ca8079531669c7c7711726" SRC_URI[sha256sum] = "8f7032f2c1c64352b5423f6b48a8ebdc339cc63064af34d66a6c9aa79759e202" + +PACKAGECONFIG ??= "arc4" +PACKAGECONFIG[arc4] = "ac_cv_lib_bsd_arc4random_buf=yes,ac_cv_lib_bsd_arc4random_buf=no,libbsd" -- 1.7.10.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ptest formatting
Hello, My name is Eric Yu, and I am an intern at National Instruments for this summer. The project I am currently working on involves integrating ptest with our current automated testing framework to help test our open-embedded distributions. On the Yocto Project wiki, it states that one major point of ptest is to consolidate the output of different package tests in a common “: ” format. I was hoping that this common format would allow ptest results to be easily machine parsed and integrated with our current testing framework. However, after enabling and running the ptests, I discovered that the formatting of the results was not as friendly to automation as I had hoped. It appears that each separate package prints out its own errors, warnings, and other output along with these test results, burying the common output in lots of other text. Also, one package (gdk-pixbuff) used “FAILED” when reporting results rather than the expected “FAIL”. In the bash ptests, several tests print warnings saying to ignore failures where the output differs only by whitespace. This seems to be bad practice for test writing and is not friendly to automated analysis of test results. At the conclusion of each ptest, some packages give a summary of how many tests were passed, skipped, and failed, while others do not. I find that having these summaries gives a useful overview of how the test went overall and is a good reference in case some tests fail to produce the common “: ” output. I understand that much of this is due to the fact that separate developers write the tests for different packages, but it would be beneficial if ptest was friendlier to automated parsing and analysis of test results. Currently, I have addressed some of these obstacles by writing a simple script that parses the output of each ptest and only outputs only the “: ” results while accounting for both “FAIL” and “FAILED”. The script keeps a running count of how many tests were reported as failed, skipped or passed, and at the conclusion of each ptest, the script prints a summary including the number of tests passed, skipped, and failed along with a total number of tests run. While this works with the current set of ptests, as more and more packages add ptest functionality, this script may not scale well if more inconsistencies in formatting are introduced. Therefore, I believe it would be a good idea to enforce a more consistent formatting of ptest results to assist in the use of ptest for automated testing. Are there any plans to further consolidate the ptest result format such that it is more accessible for automated testing? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] shadow-securetty: add freescale lpuart
On 07/24/2014 07:03 AM, Mark Hatle wrote: We should probably be setting up the securetty file in a machine specific way. Doing it generically just pollutes the file with more stuff a specific user won't want. (Note, you aren't the first to do this.. so right now it's probably the best answer, but we should fix this in the future.) Mark, can you please file a bug to track this, I will mark it as an unassigned future / low for someone to pick up. Sau! --Mark On 7/24/14, 2:44 AM, Stefan Agner wrote: Add Freescale lpuart tty's (ttyLPx) to securetty. Freescale Vybrid devices running upstream kernel use this driver. Signed-off-by: Stefan Agner --- meta/recipes-extended/shadow/files/securetty | 8 1 file changed, 8 insertions(+) diff --git a/meta/recipes-extended/shadow/files/securetty b/meta/recipes-extended/shadow/files/securetty index 0b1629f..d919993 100644 --- a/meta/recipes-extended/shadow/files/securetty +++ b/meta/recipes-extended/shadow/files/securetty @@ -137,6 +137,14 @@ ttymxc3 ttymxc4 ttymxc5 +# Freescale lpuart ports +ttyLP0 +ttyLP1 +ttyLP2 +ttyLP3 +ttyLP4 +ttyLP5 + # Standard serial ports, with devfs tts/0 tts/1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] archiver: delete the tail slash in directory name
On Wed, Jul 23, 2014 at 10:37 PM, Liu Jian wrote:
> local = fetch.localpath(url)
> + local = local.rstrip("/")
may be you could just do local = fetch.localpath(url).rstrip("/") in
the same line
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES
On Thu, Jul 24, 2014 at 02:52:45PM +0100, Burton, Ross wrote: > On 24 July 2014 14:42, Martin Jansa wrote: > > +REQUIRED_DISTRO_FEATURES = "x11" > > Now I'm wondering why this is the solution. > > If you attempt to build e.g. gnome-desktop explicitly without the x11 > distro feature you understandably get an error message, because > gnome-desktop depends on libx11 which sanity checks the distro > features. This seems correct. > > Presumably you're problem is that you're running world builds and > they're producing errors on gnome-desktop because they can't satisfy a > dependency on libx11. It seems that bubbling up the > REQUIRED_DISTRO_FEATURES tests isn't the right thing to do here - why > can't SkipPackage be handled specially, so if you do bitbake -k world > and libx11 emits SkipPackage, anything that has unsatisfiable > dependencies because of this is also skipped? We discussed this many months ago and IIRC the conclusion was that user should explicitly say that he wants to skip the recipes which depend on something skipped (so that he is aware of what he is missing). At that time there wasn't REQUIRED_DISTRO_FEATURES support, so I've created huge list of PNBLACKLISTs to blacklist everything not available in our setup - so I can do world builds without ERRORs at the beginning. REQUIRED_DISTRO_FEATURES seems to me like reasonable compromise, that's why I've sent this patchset to replace small part of my huge blacklist. This is the list: https://github.com/openwebos/meta-webos/blob/master/conf/distro/include/webos-recipe-blacklist-world.inc If someone has time to improve SkipPackage and we really want to skip all depending packages, I would be glad to test such patch (because it allows to easily drop all those blacklists for "depends-on-broken" components) 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
[OE-core] [PATCH V2 1/2] Revert "libomxil-0.9.3: Remove versioning for .so files."
The previous version of this fix was too aggressive and removed versioning from too many of the .so files in the libomxil package. This reverts commit 0ef3734c2f279bf463ba4d1aef5241cd4882d483. --- .../libomxil-0.9.3/disable-so-versioning.patch | 69 -- meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb | 17 ++ 2 files changed, 6 insertions(+), 80 deletions(-) delete mode 100644 meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch diff --git a/meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch b/meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch deleted file mode 100644 index 9c63b4d..000 --- a/meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch +++ /dev/null @@ -1,69 +0,0 @@ -Disable so versioning since they are really not a versioned shared lib. - -Upstream-Status: Submitted @ https://sourceforge.net/p/omxil/bugs/59/ - -Signed-off-by: Drew Moseley - -diff -rub libomxil-bellagio-0.9.3-orig/src/components/audio_effects/Makefile.am libomxil-bellagio-0.9.3/src/components/audio_effects/Makefile.am libomxil-bellagio-0.9.3-orig/src/components/audio_effects/Makefile.am 2014-07-20 15:22:00.858425234 -0400 -+++ libomxil-bellagio-0.9.3/src/components/audio_effects/Makefile.am 2014-07-20 15:25:42.687525225 -0400 -@@ -10,4 +10,5 @@ - libomxaudio_effects_la_CFLAGS = -I$(top_srcdir)/include \ - -I$(top_srcdir)/src \ - -I$(top_srcdir)/src/base -+libomxaudio_effects_la_LDFLAGS = -avoid-version - -diff -rub libomxil-bellagio-0.9.3-orig/src/components/clocksrc/Makefile.am libomxil-bellagio-0.9.3/src/components/clocksrc/Makefile.am libomxil-bellagio-0.9.3-orig/src/components/clocksrc/Makefile.am 2014-07-20 15:22:00.858425234 -0400 -+++ libomxil-bellagio-0.9.3/src/components/clocksrc/Makefile.am 2014-07-20 15:24:49.151259753 -0400 -@@ -10,4 +10,4 @@ - -I$(top_srcdir)/include \ - -I$(top_srcdir)/src \ - -I$(top_srcdir)/src/base -- -+libomxclocksrc_la_LDFLAGS = -avoid-version -diff -rub libomxil-bellagio-0.9.3-orig/src/components/videoscheduler/Makefile.am libomxil-bellagio-0.9.3/src/components/videoscheduler/Makefile.am libomxil-bellagio-0.9.3-orig/src/components/videoscheduler/Makefile.am 2014-07-20 15:22:00.862425254 -0400 -+++ libomxil-bellagio-0.9.3/src/components/videoscheduler/Makefile.am 2014-07-20 15:22:36.462601786 -0400 -@@ -6,7 +6,7 @@ - library_entry_point.c - - libomxvideosched_la_LIBADD = $(top_builddir)/src/libomxil-bellagio.la --libomxvideosched_la_LDFLAGS = -+libomxvideosched_la_LDFLAGS = -avoid-version - libomxvideosched_la_CFLAGS = -I$(top_srcdir)/include \ - -I$(top_srcdir)/src \ - -I$(top_srcdir)/src/base -diff -rub libomxil-bellagio-0.9.3-orig/src/dynamic_loader/Makefile.am libomxil-bellagio-0.9.3/src/dynamic_loader/Makefile.am libomxil-bellagio-0.9.3-orig/src/dynamic_loader/Makefile.am 2014-07-20 15:22:00.862425254 -0400 -+++ libomxil-bellagio-0.9.3/src/dynamic_loader/Makefile.am 2014-07-20 15:22:36.462601786 -0400 -@@ -3,7 +3,7 @@ - omxdynamicloader_LTLIBRARIES = libomxdynamicloader.la - libomxdynamicloader_la_SOURCES = ste_dynamic_component_loader.c ste_dynamic_component_loader.h - --libomxdynamicloader_la_LDFLAGS = -lomxil-bellagio -L$(top_builddir)/src/.libs -+libomxdynamicloader_la_LDFLAGS = -lomxil-bellagio -L$(top_builddir)/src/.libs -avoid-version - libomxdynamicloader_la_CFLAGS = -I$(top_srcdir)/include \ - -I$(top_srcdir)/src \ - -I$(top_srcdir)/src/base \ -diff -rub libomxil-bellagio-0.9.3-orig/src/Makefile.am libomxil-bellagio-0.9.3/src/Makefile.am libomxil-bellagio-0.9.3-orig/src/Makefile.am 2014-07-20 15:22:00.862425254 -0400 -+++ libomxil-bellagio-0.9.3/src/Makefile.am2014-07-20 15:22:36.462601786 -0400 -@@ -8,7 +8,7 @@ - omxregister_bellagio_CFLAGS = -DOMXILCOMPONENTSPATH=\"$(plugindir)/\" \ - -I$(top_srcdir)/include - omxregister_bellagio_LDADD = $(lib_LTLIBRARIES) --omxregister_bellagio_LDFLAGS = -lomxil-bellagio -L$(builddir) -+omxregister_bellagio_LDFLAGS = -lomxil-bellagio -L$(builddir) -avoid-version - - lib_LTLIBRARIES = libomxil-bellagio.la - libomxil_bellagio_la_SOURCES = component_loader.h \ -@@ -29,7 +29,7 @@ - libomxil_bellagio_la_CFLAGS = -I$(top_srcdir)/include -I$(srcdir)/base -I$(srcdir)/core_extensions \ - -DINSTALL_PATH_STR=\"$(plugindir)\" -DOMX_LOADERS_DIRNAME=\"$(libdir)/omxloaders\/\" - libomxil_bellagio_la_LIBADD = base/libomxbase.la core_extensions/libomxcoreext.la -lpthread --libomxil_bellagio_la_LDFLAGS = -version-info @SHARED_VERSION_INFO@ -+libomxil_bellagio_la_LDFLAGS = -avoid-versi
[OE-core] [PATCH V2 2/2] libomxil-0.9.3: Remove versioning for bellagio .so files.
The so files installed under ${libdir}/bellagio are not versioned and should
be installed without version-based symlinks so that omxregister-bellagio
can properly find and register them.
Signed-off-by: Drew Moseley
---
.../libomxil-0.9.3/disable-so-versioning.patch | 36 ++
meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb | 10 --
2 files changed, 43 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch
diff --git
a/meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch
b/meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch
new file mode 100644
index 000..f408e4a
--- /dev/null
+++
b/meta/recipes-multimedia/libomxil/libomxil-0.9.3/disable-so-versioning.patch
@@ -0,0 +1,36 @@
+Disable so versioning since they are really not a versioned shared lib.
+
+Upstream-Status: Submitted @ https://sourceforge.net/p/omxil/bugs/59/
+
+Signed-off-by: Drew Moseley
+
+diff -rub
libomxil-bellagio-0.9.3-orig/src/components/audio_effects/Makefile.am
libomxil-bellagio-0.9.3/src/components/audio_effects/Makefile.am
+--- libomxil-bellagio-0.9.3-orig/src/components/audio_effects/Makefile.am
2014-07-20 15:22:00.858425234 -0400
libomxil-bellagio-0.9.3/src/components/audio_effects/Makefile.am
2014-07-20 15:25:42.687525225 -0400
+@@ -10,4 +10,5 @@
+ libomxaudio_effects_la_CFLAGS = -I$(top_srcdir)/include \
+ -I$(top_srcdir)/src \
+ -I$(top_srcdir)/src/base
++libomxaudio_effects_la_LDFLAGS = -avoid-version
+
+diff -rub libomxil-bellagio-0.9.3-orig/src/components/clocksrc/Makefile.am
libomxil-bellagio-0.9.3/src/components/clocksrc/Makefile.am
+--- libomxil-bellagio-0.9.3-orig/src/components/clocksrc/Makefile.am
2014-07-20 15:22:00.858425234 -0400
libomxil-bellagio-0.9.3/src/components/clocksrc/Makefile.am
2014-07-20 15:24:49.151259753 -0400
+@@ -10,4 +10,4 @@
+ -I$(top_srcdir)/include \
+ -I$(top_srcdir)/src \
+ -I$(top_srcdir)/src/base
+-
++libomxclocksrc_la_LDFLAGS = -avoid-version
+diff -rub
libomxil-bellagio-0.9.3-orig/src/components/videoscheduler/Makefile.am
libomxil-bellagio-0.9.3/src/components/videoscheduler/Makefile.am
+--- libomxil-bellagio-0.9.3-orig/src/components/videoscheduler/Makefile.am
2014-07-20 15:22:00.862425254 -0400
libomxil-bellagio-0.9.3/src/components/videoscheduler/Makefile.am
2014-07-20 15:22:36.462601786 -0400
+@@ -6,7 +6,7 @@
+
library_entry_point.c
+
+ libomxvideosched_la_LIBADD = $(top_builddir)/src/libomxil-bellagio.la
+-libomxvideosched_la_LDFLAGS =
++libomxvideosched_la_LDFLAGS = -avoid-version
+ libomxvideosched_la_CFLAGS = -I$(top_srcdir)/include \
+ -I$(top_srcdir)/src \
+ -I$(top_srcdir)/src/base
diff --git a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
index 103d789..40d6df8 100644
--- a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
+++ b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb
@@ -12,7 +12,8 @@ SRC_URI =
"${SOURCEFORGE_MIRROR}/omxil/libomxil-bellagio-${PV}.tar.gz \
file://configure-fix.patch \
file://parallel-make.patch \
file://makefile-docdir-fix.patch \
- file://dynamicloader-linking.patch"
+ file://dynamicloader-linking.patch \
+ file://disable-so-versioning.patch"
SRC_URI[md5sum] = "a1de827fdb75c02c84e55f740ca27cb8"
SRC_URI[sha256sum] =
"593c0729c8ef8c1467b3bfefcf355ec19a46dd92e31bfc280e17d96b0934d74c"
@@ -23,12 +24,15 @@ inherit autotools
EXTRA_OECONF += "--disable-doc --disable-Werror"
-FILES_${PN} += "${libdir}/bellagio/*${SOLIBS} \
+#
+# The .so files under ${libdir}/bellagio are not intended to be versioned and
symlinked.
+# Make sure they get packaged in the main package.
+#
+FILES_${PN} += "${libdir}/bellagio/*.so \
${libdir}/omxloaders/*${SOLIBS}"
FILES_${PN}-staticdev += "${libdir}/bellagio/*.a \
${libdir}/omxloaders/*.a"
FILES_${PN}-dev += "${libdir}/bellagio/*.la \
-${libdir}/bellagio/*${SOLIBSDEV} \
${libdir}/omxloaders/*.la \
${libdir}/omxloaders/*${SOLIBSDEV}"
FILES_${PN}-dbg += "${libdir}/bellagio/.debug/ \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/2] util-linux: break out new package util-linux-findfs
From: Richard Tollerton
We'd like to include the util-linux version of findfs in images without
having to include all of util-linux. To make this possible, break out
findfs into its own package.
Signed-off-by: Richard Tollerton
Signed-off-by: Ben Shelton
---
meta/recipes-core/util-linux/util-linux.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index d640a5f..ffb84c4 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -36,7 +36,8 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk
util-linux-cfdisk util-linux-sfd
util-linux-uuidgen util-linux-lscpu util-linux-fsck
util-linux-blkid \
util-linux-mkfs util-linux-mcookie util-linux-reset \
util-linux-mkfs.cramfs util-linux-fsck.cramfs util-linux-fstrim \
- util-linux-partx ${PN}-bash-completion util-linux-hwclock"
+ util-linux-partx ${PN}-bash-completion util-linux-hwclock \
+ util-linux-findfs"
SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-makeinstall-chown \
@@ -79,6 +80,7 @@ FILES_util-linux-uuidd = "${sbindir}/uuidd"
FILES_util-linux-reset = "${base_bindir}/reset"
FILES_util-linux-partx = "${sbindir}/partx"
FILES_util-linux-hwclock = "${base_sbindir}/hwclock.${BPN}"
+FILES_util-linux-findfs = "${sbindir}/findfs"
FILES_util-linux-libblkid = "${base_libdir}/libblkid.so.*"
FILES_util-linux-libmount = "${base_libdir}/libmount.so.*"
--
2.0.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/2] util-linux: break out new package util-linux-hwclock
From: Alejandro del Castillo
We'd like to include the util-linux version of hwclock in images without
having to include all of util-linux. To make this possible, break out
hwclock into its own package.
Signed-off-by: Richard Tollerton
Signed-off-by: Ben Shelton
---
meta/recipes-core/util-linux/util-linux.inc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 83bb4a6..d640a5f 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -36,7 +36,7 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk
util-linux-cfdisk util-linux-sfd
util-linux-uuidgen util-linux-lscpu util-linux-fsck
util-linux-blkid \
util-linux-mkfs util-linux-mcookie util-linux-reset \
util-linux-mkfs.cramfs util-linux-fsck.cramfs util-linux-fstrim \
- util-linux-partx ${PN}-bash-completion"
+ util-linux-partx ${PN}-bash-completion util-linux-hwclock"
SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-makeinstall-chown \
@@ -78,6 +78,7 @@ FILES_util-linux-uuidgen = "${bindir}/uuidgen"
FILES_util-linux-uuidd = "${sbindir}/uuidd"
FILES_util-linux-reset = "${base_bindir}/reset"
FILES_util-linux-partx = "${sbindir}/partx"
+FILES_util-linux-hwclock = "${base_sbindir}/hwclock.${BPN}"
FILES_util-linux-libblkid = "${base_libdir}/libblkid.so.*"
FILES_util-linux-libmount = "${base_libdir}/libmount.so.*"
@@ -166,7 +167,7 @@ ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_${PN} = "dmesg kill more mkswap blockdev pivot_root"
ALTERNATIVE_${PN} += "mkfs.minix hexdump last logger mesg renice wall"
-ALTERNATIVE_${PN} += "setsid chrt flock hwclock utmpdump eject getopt sulogin"
+ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject getopt sulogin"
ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
ALTERNATIVE_LINK_NAME[kill] = "${base_bindir}/kill"
@@ -190,6 +191,7 @@ ALTERNATIVE_LINK_NAME[sulogin.8] =
"${mandir}/man8/sulogin.8"
ALTERNATIVE_LINK_NAME[utmpdump.1] = "${mandir}/man1/utmpdump.1"
ALTERNATIVE_LINK_NAME[wall.1] = "${mandir}/man1/wall.1"
+ALTERNATIVE_util-linux-hwclock = "hwclock"
# There seems to be problem, atleast on nslu2, with these, untill they are
# fixed the busybox ones have higher priority
ALTERNATIVE_PRIORITY[hwclock] = "10"
--
2.0.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] shadow-securetty: add freescale lpuart
We should probably be setting up the securetty file in a machine specific way. Doing it generically just pollutes the file with more stuff a specific user won't want. (Note, you aren't the first to do this.. so right now it's probably the best answer, but we should fix this in the future.) --Mark On 7/24/14, 2:44 AM, Stefan Agner wrote: Add Freescale lpuart tty's (ttyLPx) to securetty. Freescale Vybrid devices running upstream kernel use this driver. Signed-off-by: Stefan Agner --- meta/recipes-extended/shadow/files/securetty | 8 1 file changed, 8 insertions(+) diff --git a/meta/recipes-extended/shadow/files/securetty b/meta/recipes-extended/shadow/files/securetty index 0b1629f..d919993 100644 --- a/meta/recipes-extended/shadow/files/securetty +++ b/meta/recipes-extended/shadow/files/securetty @@ -137,6 +137,14 @@ ttymxc3 ttymxc4 ttymxc5 +# Freescale lpuart ports +ttyLP0 +ttyLP1 +ttyLP2 +ttyLP3 +ttyLP4 +ttyLP5 + # Standard serial ports, with devfs tts/0 tts/1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES
On 24 July 2014 14:42, Martin Jansa wrote: > +REQUIRED_DISTRO_FEATURES = "x11" Now I'm wondering why this is the solution. If you attempt to build e.g. gnome-desktop explicitly without the x11 distro feature you understandably get an error message, because gnome-desktop depends on libx11 which sanity checks the distro features. This seems correct. Presumably you're problem is that you're running world builds and they're producing errors on gnome-desktop because they can't satisfy a dependency on libx11. It seems that bubbling up the REQUIRED_DISTRO_FEATURES tests isn't the right thing to do here - why can't SkipPackage be handled specially, so if you do bitbake -k world and libx11 emits SkipPackage, anything that has unsatisfiable dependencies because of this is also skipped? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] python: fix _json module arbitrary process memory read vulnerability
http://bugs.python.org/issue21529
Python 2 and 3 are susceptible to arbitrary process memory reading by
a user or adversary due to a bug in the _json module caused by
insufficient bounds checking.
The sole prerequisites of this attack are that the attacker is able to
control or influence the two parameters of the default scanstring
function: the string to be decoded and the index.
The bug is caused by allowing the user to supply a negative index
value. The index value is then used directly as an index to an array
in the C code; internally the address of the array and its index are
added to each other in order to yield the address of the value that is
desired. However, by supplying a negative index value and adding this
to the address of the array, the processor's register value wraps
around and the calculated value will point to a position in memory
which isn't within the bounds of the supplied string, causing the
function to access other parts of the process memory.
Signed-off-by: Benjamin Peterson
Applied to python-native recipe in order to fix the above mentioned
vulnerability.
Upstream-Status: Submitted
Signed-off-by: Daniel BORNAZ
---
.../recipes-devtools/python/python-native_2.7.3.bb | 1 +
.../python/python/json-flaw-fix.patch | 27 ++
meta/recipes-devtools/python/python_2.7.3.bb | 1 +
3 files changed, 29 insertions(+)
create mode 100644 meta/recipes-devtools/python/python/json-flaw-fix.patch
diff --git a/meta/recipes-devtools/python/python-native_2.7.3.bb
b/meta/recipes-devtools/python/python-native_2.7.3.bb
index 0571d3a..827654d 100644
--- a/meta/recipes-devtools/python/python-native_2.7.3.bb
+++ b/meta/recipes-devtools/python/python-native_2.7.3.bb
@@ -19,6 +19,7 @@ SRC_URI += "\
file://parallel-makeinst-create-bindir.patch \
file://python-fix-build-error-with-Readline-6.3.patch \
file://gcc-4.8-fix-configure-Wformat.patch \
+ file://json-flaw-fix.patch \
"
S = "${WORKDIR}/Python-${PV}"
diff --git a/meta/recipes-devtools/python/python/json-flaw-fix.patch
b/meta/recipes-devtools/python/python/json-flaw-fix.patch
new file mode 100644
index 000..e9a6cca
--- /dev/null
+++ b/meta/recipes-devtools/python/python/json-flaw-fix.patch
@@ -0,0 +1,27 @@
+
+python: fix _json module arbitrary process memory read vulnerability
+
+Upstream-Status: submitted
+
+Signed-off-by: Daniel BORNAZ
+
+--- a/Modules/_json.c 2014-07-15 15:37:17.151046356 +0200
b/Modules/_json.c 2014-07-15 15:38:37.335605042 +0200
+@@ -1491,7 +1491,7 @@ scan_once_str(PyScannerObject *s, PyObje
+ PyObject *res;
+ char *str = PyString_AS_STRING(pystr);
+ Py_ssize_t length = PyString_GET_SIZE(pystr);
+-if (idx >= length) {
++if ( idx < 0 || idx >= length) {
+ PyErr_SetNone(PyExc_StopIteration);
+ return NULL;
+ }
+@@ -1578,7 +1578,7 @@ scan_once_unicode(PyScannerObject *s, Py
+ PyObject *res;
+ Py_UNICODE *str = PyUnicode_AS_UNICODE(pystr);
+ Py_ssize_t length = PyUnicode_GET_SIZE(pystr);
+-if (idx >= length) {
++if ( idx < 0 || idx >= length) {
+ PyErr_SetNone(PyExc_StopIteration);
+ return NULL;
+ }
diff --git a/meta/recipes-devtools/python/python_2.7.3.bb
b/meta/recipes-devtools/python/python_2.7.3.bb
index 0d64172..5be9073 100644
--- a/meta/recipes-devtools/python/python_2.7.3.bb
+++ b/meta/recipes-devtools/python/python_2.7.3.bb
@@ -36,6 +36,7 @@ SRC_URI += "\
file://python-2.7.3-CVE-2013-1752-smtplib-fix.patch \
file://python-fix-build-error-with-Readline-6.3.patch \
file://python-2.7.3-CVE-2014-1912.patch \
+ file://json-flaw-fix.patch \
"
S = "${WORKDIR}/Python-${PV}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] xorg-driver: add x11 to required DISTRO_FEATURES
On 24 July 2014 14:42, Martin Jansa wrote: > +# depends on virtual/libx11 I think these comments are fairly redundant - it's an X11 driver, of course it depends on X11. :) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] xorg-driver: add x11 to required DISTRO_FEATURES
* it's not complete, but recipes depending on virtual/libx11 are easiest
to spot, I've long list of PNBLACKLIST for all recipes which cannot
be built in distro without x11 in DISTRO_FEATURES
Signed-off-by: Martin Jansa
---
meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.15.bb | 4
meta/recipes-graphics/xorg-driver/xf86-video-intel_2.99.912.bb | 4
meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb | 4
meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb | 4
meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.3.bb | 4
meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.2.bb | 4
6 files changed, 24 insertions(+)
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.15.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.15.bb
index cd8fd63..de6a4d8 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.15.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.15.bb
@@ -11,6 +11,10 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=8730ad58d11c7bbad9a7066d69f7808e"
DEPENDS += "virtual/libx11 drm libpciaccess pixman"
+inherit distro_features_check
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
SRC_URI += "file://disable-dri2-tests.patch \
file://compat-api-Map-changes-of-DamageUnregister-API-in-1..patch \
"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.99.912.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.99.912.bb
index 544de4a..34912f3 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.99.912.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.99.912.bb
@@ -17,6 +17,10 @@ SRC_URI[sha256sum] =
"7c8ffc492d59f34cac64093deb70717b4d9223cf416ecc6fa016ab2e8b
DEPENDS += "virtual/libx11 drm libpciaccess pixman"
+inherit distro_features_check
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
PACKAGECONFIG ??= "sna udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
'dri dri1 dri2', '', d)}"
PACKAGECONFIG[dri] = "--enable-dri,--disable-dri"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
index 454d0a1..3c92ae0 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-omap_git.bb
@@ -24,6 +24,10 @@ LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=10ce5de3b111315ea652a5f74ec0c602"
DEPENDS += "virtual/libx11 libdrm xf86driproto"
+inherit distro_features_check
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
SRCREV = "ae0394e687f1a77e966cf72f895da91840dffb8f"
PR = "${INC_PR}.3"
PV = "0.4.2+gitr${SRCPV}"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
index 50ce4c2..a2141e9 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-omapfb_git.bb
@@ -9,6 +9,10 @@ LICENSE = "MIT-X & GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=63e2cbac53863f60e2f43343fb34367f"
DEPENDS += "virtual/libx11"
+inherit distro_features_check
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
SRCREV = "28c006c94e57ea71df11ec4fff79d7ffcfc4860f"
PR = "${INC_PR}.7"
PV = "0.1.1+gitr${SRCPV}"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.3.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.3.bb
index 4052f70..cd17068 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.3.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-vesa_2.3.3.bb
@@ -13,6 +13,10 @@ PR = "${INC_PR}.0"
DEPENDS += "virtual/libx11 randrproto libpciaccess"
+inherit distro_features_check
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
RRECOMMENDS_${PN} += "xserver-xorg-module-libint10"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.2.bb
b/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.2.bb
index 24041b5..619d9fe 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.2.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.2.bb
@@ -11,6 +11,10 @@ DEPENDS += "virtual/libx11 xineramaproto videoproto
libpciaccess"
SRC_URI += "file://0001-configure-fix-build-without-xatracker.patch \
file://0002-add-option-for-vmwgfx.patch"
+inherit distro_features_check
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
SRC_URI[md5sum] = "91d1d7d33181766714405ab013d31244"
SRC_URI[sha256sum] =
"c8ba3d2cead3620dba2cbf5defb7f1759b2b96f4fe209f4bf6976832b6763c54"
--
2.0.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES
* it's not complete, but recipes depending on virtual/libx11 are easiest
to spot, I've long list of PNBLACKLIST for all recipes which cannot
be built in distro without x11 in DISTRO_FEATURES
Signed-off-by: Martin Jansa
---
meta/recipes-gnome/gnome/gnome-desktop.inc | 5 -
meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.bb | 4
meta/recipes-graphics/fstests/fstests_git.bb | 5 -
meta/recipes-graphics/glew/glew_1.10.0.bb| 4 +++-
meta/recipes-graphics/libmatchbox/libmatchbox_1.11.bb| 5 -
.../recipes-graphics/libxsettings-client/libxsettings-client_0.10.bb | 5 -
meta/recipes-graphics/matchbox-wm/matchbox-wm_1.2.bb | 5 -
meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb | 5 -
meta/recipes-graphics/piglit/piglit_git.bb | 5 -
meta/recipes-graphics/pong-clock/pong-clock_1.0.bb | 4
.../startup-notification/startup-notification_0.12.bb| 5 -
meta/recipes-graphics/x11vnc/x11vnc_0.9.13.bb| 5 -
meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 5 -
13 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/meta/recipes-gnome/gnome/gnome-desktop.inc
b/meta/recipes-gnome/gnome/gnome-desktop.inc
index 3853022..4aa664f 100644
--- a/meta/recipes-gnome/gnome/gnome-desktop.inc
+++ b/meta/recipes-gnome/gnome/gnome-desktop.inc
@@ -3,6 +3,9 @@ SECTION = "x11/gnome"
LICENSE = "GPLv2 & LGPLv2"
DEPENDS = "gconf libxrandr virtual/libx11 gtk+ glib-2.0 gnome-doc-utils
startup-notification"
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
EXTRA_OECONF = "--disable-scrollkeeper --disable-desktop-docs"
do_configure_prepend () {
@@ -13,7 +16,7 @@ FILES_${PN} += "${datadir}/gnome-about
${datadir}/libgnome-desktop/pnp.ids"
PR = "r6"
-inherit gnomebase
+inherit gnomebase distro_features_check
do_install_append () {
sed -i -e's,${STAGING_BINDIR_NATIVE},${bindir},g'
${D}${bindir}/gnome-about
diff --git a/meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.bb
b/meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.bb
index 18fc893..3427fdf 100644
--- a/meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.bb
+++ b/meta/recipes-graphics/eglinfo/eglinfo-x11_1.0.bb
@@ -5,4 +5,8 @@ include eglinfo.inc
DEPENDS += "virtual/libx11"
+inherit distro_features_check
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
SUMMARY += "(X11 version)"
diff --git a/meta/recipes-graphics/fstests/fstests_git.bb
b/meta/recipes-graphics/fstests/fstests_git.bb
index 57ff9f6..5da7986 100644
--- a/meta/recipes-graphics/fstests/fstests_git.bb
+++ b/meta/recipes-graphics/fstests/fstests_git.bb
@@ -4,6 +4,9 @@ SECTION = "devel"
LICENSE = "Zlib"
DEPENDS = "pango libxext libxft virtual/libx11 gtk+"
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
SRCREV = "e5939ff608b95cdd4d0ab0e1935781ab9a276ac0"
PV = "0.1+git${SRCPV}"
@@ -13,4 +16,4 @@ LIC_FILES_CHKSUM =
"file://test-pango-gdk.c;endline=24;md5=1ee74ec851ecda57eb7ac
S = "${WORKDIR}/git/tests"
-inherit autotools pkgconfig
+inherit autotools pkgconfig distro_features_check
diff --git a/meta/recipes-graphics/glew/glew_1.10.0.bb
b/meta/recipes-graphics/glew/glew_1.10.0.bb
index 94f1bc1..4470f99 100644
--- a/meta/recipes-graphics/glew/glew_1.10.0.bb
+++ b/meta/recipes-graphics/glew/glew_1.10.0.bb
@@ -8,6 +8,8 @@ LIC_FILES_CHKSUM =
"file://LICENSE.txt;md5=2ac251558de685c6b9478d89be3149c2"
DEPENDS = "virtual/libx11 virtual/libgl libglu libxext libxi libxmu"
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
SRC_URI = "${SOURCEFORGE_MIRROR}/project/glew/glew/${PV}/glew-${PV}.tgz \
file://autotools.patch \
@@ -18,4 +20,4 @@ SRC_URI =
"${SOURCEFORGE_MIRROR}/project/glew/glew/${PV}/glew-${PV}.tgz \
SRC_URI[md5sum] = "2f09e5e6cb1b9f3611bcac79bc9c2d5d"
SRC_URI[sha256sum] =
"99c41320b63f6860869b5fb9af9a1854b15582796c64ee3dfd7096dc0c89f307"
-inherit autotools lib_package pkgconfig
+inherit autotools lib_package pkgconfig distro_features_check
diff --git a/meta/recipes-graphics/libmatchbox/libmatchbox_1.11.bb
b/meta/recipes-graphics/libmatchbox/libmatchbox_1.11.bb
index 4acac39..f688b4e 100644
--- a/meta/recipes-graphics/libmatchbox/libmatchbox_1.11.bb
+++ b/meta/recipes-graphics/libmatchbox/libmatchbox_1.11.bb
@@ -10,13 +10,16 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34 \
DEPENDS = "virtual/libx11 libxext"
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
SRC_URI =
"http://downloads.yoctoproject.org/releases/matchbox/${BPN}/${PV}/${BPN}-${PV}.tar.bz2
\
file://libpng.patch"
SRC_URI[md5sum] = "fc6cc807f55a3e7c752d8013176875d7"
SRC_URI[sha256sum] =
"254cab52e304a3512c8df4be59d690cf3921bbb68a28ede7fe26b93534217b53"
-inherit autotools pkgconf
[OE-core] [PATCH 4/4] recipes-qt: add x11 to required DISTRO_FEATURES
* it's not complete, but recipes depending on virtual/libx11 are easiest
to spot, I've long list of PNBLACKLIST for all recipes which cannot
be built in distro without x11 in DISTRO_FEATURES
Signed-off-by: Martin Jansa
---
meta/classes/qt4x11.bbclass | 5 -
meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.bb | 4
meta/recipes-qt/qt4/qt4-x11-free.inc | 5 -
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/meta/classes/qt4x11.bbclass b/meta/classes/qt4x11.bbclass
index 65d196a..bdbfc4a 100644
--- a/meta/classes/qt4x11.bbclass
+++ b/meta/classes/qt4x11.bbclass
@@ -1,7 +1,10 @@
QT4DEPENDS ?= "qt4-x11 "
DEPENDS_prepend = "${QT4DEPENDS}"
-inherit qmake2
+# depends on qt4-x11
+REQUIRED_DISTRO_FEATURES = "x11"
+
+inherit qmake2 distro_features_check
QT_BASE_NAME = "qt4"
QT_DIR_NAME = "qt4"
diff --git a/meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.bb
b/meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.bb
index 0e7c800..772c151 100644
--- a/meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.bb
+++ b/meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.bb
@@ -4,6 +4,10 @@ QTLIBPREFIX = ""
require packagegroup-qt-toolchain-target.inc
+inherit distro_features_check
+# depends on qt4-x11-free
+REQUIRED_DISTRO_FEATURES = "x11"
+
RDEPENDS_${PN} += " \
qt4-x11-free-dev \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'libqtopengl4-dev',
'', d)} \
diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
b/meta/recipes-qt/qt4/qt4-x11-free.inc
index 3b1e0fe..b621f8e 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free.inc
+++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
@@ -8,6 +8,9 @@ DEPENDS += "virtual/libgl virtual/libx11 fontconfig libxft
libxext libxrender li
PROVIDES += "qt4-x11"
QT4DEPENDS = ""
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
INC_PR = "r50"
QT_GLFLAGS ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', '-opengl',
'-no-opengl', d)} "
@@ -21,7 +24,7 @@ QT_BASE_LIB ?= "libqt"
QT_KDE_FLAGS ?= "-accessibility -sm"
QT_DISTRO_FLAGS ?= "${QT_KDE_FLAGS}"
-inherit qt4x11
+inherit qt4x11 distro_features_check
do_install_append() {
# fix pkgconfig, libtool and prl files
--
2.0.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] xorg-app: add x11 to required DISTRO_FEATURES and cleanup dependencies
Signed-off-by: Martin Jansa
---
meta/recipes-graphics/xorg-app/xeyes_1.1.1.bb | 2 +-
meta/recipes-graphics/xorg-app/xorg-app-common.inc | 5 -
meta/recipes-graphics/xorg-app/xprop_1.2.2.bb | 2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/xorg-app/xeyes_1.1.1.bb
b/meta/recipes-graphics/xorg-app/xeyes_1.1.1.bb
index 96ea030..84d0cb8 100644
--- a/meta/recipes-graphics/xorg-app/xeyes_1.1.1.bb
+++ b/meta/recipes-graphics/xorg-app/xeyes_1.1.1.bb
@@ -11,4 +11,4 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=3ea51b365051ac32d1813a7dbaa4bfc6"
SRC_URI[md5sum] = "a3035dcecdbdb89e864177c080924981"
SRC_URI[sha256sum] =
"975e98680cd59e1f9439016386609546ed08c284d0f05a95276f96aca6e8a521"
-DEPENDS += " virtual/libx11 libxau libxt libxext libxmu libxrender"
+DEPENDS += "libxau libxt libxext libxmu libxrender"
diff --git a/meta/recipes-graphics/xorg-app/xorg-app-common.inc
b/meta/recipes-graphics/xorg-app/xorg-app-common.inc
index 524a2d3..59a04fa 100644
--- a/meta/recipes-graphics/xorg-app/xorg-app-common.inc
+++ b/meta/recipes-graphics/xorg-app/xorg-app-common.inc
@@ -5,12 +5,15 @@ SECTION = "x11/apps"
LICENSE = "MIT-X"
DEPENDS = "util-macros-native virtual/libx11"
+# depends on virtual/libx11
+REQUIRED_DISTRO_FEATURES = "x11"
+
INC_PR = "r8"
SRC_URI = "${XORG_MIRROR}/individual/app/${BPN}-${PV}.tar.bz2"
S = "${WORKDIR}/${BPN}-${PV}"
-inherit autotools pkgconfig
+inherit autotools pkgconfig distro_features_check
FILES_${PN} += " ${libdir}/X11/${BPN} ${datadir}/X11/app-defaults/"
diff --git a/meta/recipes-graphics/xorg-app/xprop_1.2.2.bb
b/meta/recipes-graphics/xorg-app/xprop_1.2.2.bb
index efbb1b3..d78bf04 100644
--- a/meta/recipes-graphics/xorg-app/xprop_1.2.2.bb
+++ b/meta/recipes-graphics/xorg-app/xprop_1.2.2.bb
@@ -10,7 +10,7 @@ formatting information."
LIC_FILES_CHKSUM = "file://COPYING;md5=e226ab8db88ac0bc0391673be40c9f91"
-DEPENDS += " libxmu virtual/libx11"
+DEPENDS += "libxmu"
PE = "1"
--
2.0.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] oeqa: Refactor test skipping decorators to use the unittest result object
In order to make the test skipping decorators independent of the oeTest object
we rely on the unittest result object to construct skip, fail and error lists
used by these decorators.
Created a new object getResults that analyses upper frames and retrieves the
unittest result object instance, then return a list of failed, skipped and
error tests.
Also removed the oetest import from decorators.py because it was no longer
required.
Signed-off-by: Lucian Musat
---
meta/lib/oeqa/oetest.py | 17 -
meta/lib/oeqa/utils/decorators.py | 40 +--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index 0db6cb8..ecb8e53 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -11,7 +11,6 @@ import os, re, mmap
import unittest
import inspect
-
def loadTests(tc):
# set the context object passed from the test class
@@ -36,24 +35,9 @@ def runTests(tc):
return result
-
class oeTest(unittest.TestCase):
longMessage = True
-testFailures = []
-testSkipped = []
-testErrors = []
-
-def run(self, result=None):
-super(oeTest, self).run(result)
-
-# we add to our own lists the results, we use those for decorators
-if len(result.failures) > len(oeTest.testFailures):
-oeTest.testFailures.append(str(result.failures[-1][0]).split()[0])
-if len(result.skipped) > len(oeTest.testSkipped):
-oeTest.testSkipped.append(str(result.skipped[-1][0]).split()[0])
-if len(result.errors) > len(oeTest.testErrors):
-oeTest.testErrors.append(str(result.errors[-1][0]).split()[0])
@classmethod
def hasPackage(self, pkg):
@@ -71,7 +55,6 @@ class oeTest(unittest.TestCase):
else:
return False
-
class oeRuntimeTest(oeTest):
def __init__(self, methodName='runTest'):
diff --git a/meta/lib/oeqa/utils/decorators.py
b/meta/lib/oeqa/utils/decorators.py
index a0d94e6..439e80a 100644
--- a/meta/lib/oeqa/utils/decorators.py
+++ b/meta/lib/oeqa/utils/decorators.py
@@ -6,9 +6,34 @@
# Most useful is skipUnlessPassed which can be used for
# creating dependecies between two test methods.
-from oeqa.oetest import *
import logging
import sys
+import unittest
+
+#get the "result" object from one of the upper frames provided that one of
these upper frames is a unittest.case frame
+class getResults(object):
+def __init__(self):
+#dynamically determine the unittest.case frame and use it to get the
name of the test method
+upperf = sys._current_frames().values()[0]
+while (upperf.f_globals['__name__'] != 'unittest.case'):
+upperf = upperf.f_back
+self.faillist = [ seq[0]._testMethodName for seq in
upperf.f_locals['result'].failures ]
+self.errorlist = [ seq[0]._testMethodName for seq in
upperf.f_locals['result'].errors ]
+#ignore the _ErrorHolder objects from the skipped tests list
+self.skiplist = []
+for seq in upperf.f_locals['result'].skipped:
+try:
+self.skiplist.append(seq[0]._testMethodName)
+except: pass
+
+def getFailList(self):
+return self.faillist
+
+def getErrorList(self):
+return self.errorlist
+
+def getSkipList(self):
+return self.skiplist
class skipIfFailure(object):
@@ -17,7 +42,8 @@ class skipIfFailure(object):
def __call__(self,f):
def wrapped_f(*args):
-if self.testcase in (oeTest.testFailures or oeTest.testErrors):
+res = getResults()
+if self.testcase in (res.getFailList() or res.getErrorList()):
raise unittest.SkipTest("Testcase dependency not met: %s" %
self.testcase)
return f(*args)
wrapped_f.__name__ = f.__name__
@@ -30,7 +56,8 @@ class skipIfSkipped(object):
def __call__(self,f):
def wrapped_f(*args):
-if self.testcase in oeTest.testSkipped:
+res = getResults()
+if self.testcase in res.getSkipList():
raise unittest.SkipTest("Testcase dependency not met: %s" %
self.testcase)
return f(*args)
wrapped_f.__name__ = f.__name__
@@ -43,9 +70,10 @@ class skipUnlessPassed(object):
def __call__(self,f):
def wrapped_f(*args):
-if self.testcase in oeTest.testSkipped or \
-self.testcase in oeTest.testFailures or \
-self.testcase in oeTest.testErrors:
+res = getResults()
+if self.testcase in res.getSkipList() or \
+self.testcase in res.getFailList() or \
+self.testcase in res.getErrorList():
raise unittest.SkipTest("Testcase dependency not met: %s" %
self.testcase)
return f(*args)
wrapped_f.__name__ = f.__name__
--
1.9.1
--
_
[OE-core] [PATCH 2/2] oeqa/runtime: Added skipModule import for test modules that use it.
The modules that use skipModule should import it themselves and not rely on
somebody else to import it.
Signed-off-by: Lucian Musat
---
meta/lib/oeqa/runtime/buildcvs.py | 2 +-
meta/lib/oeqa/runtime/buildiptables.py | 2 +-
meta/lib/oeqa/runtime/buildsudoku.py | 2 +-
meta/lib/oeqa/runtime/ldd.py | 2 +-
meta/lib/oeqa/runtime/pam.py | 8
meta/lib/oeqa/runtime/skeletoninit.py | 2 +-
meta/lib/oeqa/runtime/smart.py | 2 +-
meta/lib/oeqa/runtime/vnc.py | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/meta/lib/oeqa/runtime/buildcvs.py
b/meta/lib/oeqa/runtime/buildcvs.py
index f1fbf19..6201ed1 100644
--- a/meta/lib/oeqa/runtime/buildcvs.py
+++ b/meta/lib/oeqa/runtime/buildcvs.py
@@ -1,4 +1,4 @@
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipModule
from oeqa.utils.decorators import *
from oeqa.utils.targetbuild import TargetBuildProject
diff --git a/meta/lib/oeqa/runtime/buildiptables.py
b/meta/lib/oeqa/runtime/buildiptables.py
index f6061a7..c77b114 100644
--- a/meta/lib/oeqa/runtime/buildiptables.py
+++ b/meta/lib/oeqa/runtime/buildiptables.py
@@ -1,4 +1,4 @@
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipModule
from oeqa.utils.decorators import *
from oeqa.utils.targetbuild import TargetBuildProject
diff --git a/meta/lib/oeqa/runtime/buildsudoku.py
b/meta/lib/oeqa/runtime/buildsudoku.py
index a754f1d..f51af92 100644
--- a/meta/lib/oeqa/runtime/buildsudoku.py
+++ b/meta/lib/oeqa/runtime/buildsudoku.py
@@ -1,4 +1,4 @@
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipModule
from oeqa.utils.decorators import *
from oeqa.utils.targetbuild import TargetBuildProject
diff --git a/meta/lib/oeqa/runtime/ldd.py b/meta/lib/oeqa/runtime/ldd.py
index 4374530..079130f 100644
--- a/meta/lib/oeqa/runtime/ldd.py
+++ b/meta/lib/oeqa/runtime/ldd.py
@@ -1,5 +1,5 @@
import unittest
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipModule
from oeqa.utils.decorators import *
def setUpModule():
diff --git a/meta/lib/oeqa/runtime/pam.py b/meta/lib/oeqa/runtime/pam.py
index cc5c1bd..c26e6ea 100644
--- a/meta/lib/oeqa/runtime/pam.py
+++ b/meta/lib/oeqa/runtime/pam.py
@@ -2,7 +2,7 @@
# Note that the image under test must have "pam" in DISTRO_FEATURES
import unittest
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipModule
from oeqa.utils.decorators import *
def setUpModule():
@@ -17,8 +17,8 @@ class PamBasicTest(oeRuntimeTest):
(status, output) = self.target.run('login --help')
self.assertEqual(status, 1, msg = "login command does not work as
expected. Status and output:%s and %s" %(status, output))
(status, output) = self.target.run('passwd --help')
-self.assertEqual(status, 0, msg = "passwd command does not work as
expected. Status and output:%s and %s" %(status, output))
+self.assertEqual(status, 6, msg = "passwd command does not work as
expected. Status and output:%s and %s" %(status, output))
(status, output) = self.target.run('su --help')
-self.assertEqual(status, 0, msg = "su command does not work as
expected. Status and output:%s and %s" %(status, output))
+self.assertEqual(status, 2, msg = "su command does not work as
expected. Status and output:%s and %s" %(status, output))
(status, output) = self.target.run('useradd --help')
-self.assertEqual(status, 0, msg = "useradd command does not work as
expected. Status and output:%s and %s" %(status, output))
+self.assertEqual(status, 2, msg = "useradd command does not work as
expected. Status and output:%s and %s" %(status, output))
diff --git a/meta/lib/oeqa/runtime/skeletoninit.py
b/meta/lib/oeqa/runtime/skeletoninit.py
index 557e715..ddcad20 100644
--- a/meta/lib/oeqa/runtime/skeletoninit.py
+++ b/meta/lib/oeqa/runtime/skeletoninit.py
@@ -2,7 +2,7 @@
# Note that the image under test must have meta-skeleton layer in bblayers and
IMAGE_INSTALL_append = " service" in local.conf
import unittest
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipModule
from oeqa.utils.decorators import *
def setUpModule():
diff --git a/meta/lib/oeqa/runtime/smart.py b/meta/lib/oeqa/runtime/smart.py
index 195f117..3130373 100644
--- a/meta/lib/oeqa/runtime/smart.py
+++ b/meta/lib/oeqa/runtime/smart.py
@@ -1,6 +1,6 @@
import unittest
import re
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipModule
from oeqa.utils.decorators import *
from oeqa.utils.httpserver import HTTPService
diff --git a/meta/lib/oeqa/runtime/vnc.py b/meta/lib/oeqa/runtime/vnc.py
index 5ed1072..1b4652b 100644
--- a/meta/lib/oeqa/runtime/vnc.py
+++ b/meta/lib/oeqa/runtime/vnc.py
@@ -1,4 +1,4 @@
-from oeqa.oetest import oeRuntimeTest
+from oeqa.oetest import oeRuntimeTest, skipMod
[OE-core] [PATCH v2] wic: do not overwrite autogenerated /etc/fstab with original too early
DirectImageCreator.__write_fstab() generates new /etc/fstab in sysroot
with rootfs contents. The fstab entries are generated base on the
initialn contents of /etc/fstab, plus any extra (other than / or
/boot) partitions listed in *.wks. A backup of original /etc/fstab is
done in a temp location. Subsequent call to __restore_fstab() restores
the backup copy, replacing the autogenerated one.
Calling __restore_fstab() before Wic_PartData.prepare() brings back the
original fstab before the partition image file actually is created. As
such, the autogenerated /etc/fstab will not make it to the partition.
Signed-off-by: Maciej Borzecki
Signed-off-by: Maciek Borzecki
---
Notes:
Previous version got messed up during merges and faulty code was sent
out. This one works as expected.
scripts/lib/mic/imager/direct.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/mic/imager/direct.py b/scripts/lib/mic/imager/direct.py
index 2cf4c8d..77a118a 100644
--- a/scripts/lib/mic/imager/direct.py
+++ b/scripts/lib/mic/imager/direct.py
@@ -262,10 +262,12 @@ class DirectImageCreator(BaseImageCreator):
# when/if we need to actually do package selection we
# should modify things to use those objects, but for now
# we can avoid that.
+
+fstab = self.__write_fstab(self.rootfs_dir.get("ROOTFS_DIR"))
+
p.prepare(self, self.workdir, self.oe_builddir, self.rootfs_dir,
self.bootimg_dir, self.kernel_dir, self.native_sysroot)
-fstab = self.__write_fstab(p.get_rootfs())
self._restore_fstab(fstab)
self.__instimage.add_partition(int(p.size),
@@ -278,6 +280,7 @@ class DirectImageCreator(BaseImageCreator):
boot = p.active,
align = p.align,
part_type = p.part_type)
+
self.__instimage.layout_partitions(self._ptable_format)
self.__imgdir = self.workdir
--
1.9.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] simple dependency question
On Thu, 24 Jul 2014, Richard Purdie wrote: > On Thu, 2014-07-24 at 07:13 -0400, Robert P. J. Day wrote: > > i realize that "DEPENDS" represents build-time dependencies, as in > > ... all of the DEPENDS recipes must build *completely* before this > > recipe can *begin* to build, is that correct? > > > > however, in something like module.bbclass where one finds: > > > > do_make_scripts[deptask] = "do_populate_sysroot" > > > > does that now *override* the normal build-time dependency to say only > > that this recipe's do_make_scripts task need only wait until all of > > the "DEPENDS" recipes have completed their do_populate_sysroot tasks? > > The original DEPENDS meaning remains unchanged and applies to the > configure task. The behaviour of DEPENDS comes from: > > do_configure[deptask] = "do_populate_sysroot" > > which means the configure task waits for all the populate_sysroot tasks > of DEPENDS to complete before executing this task. > > do_make_scripts[deptask] = "do_populate_sysroot" > > Adds constraints to the make_scripts task where it also must wait until > all DEPENDS populate_sysroot have run before it can. > > > in other words, the instant i define an inter-task dependency, does > > that relax the normal strong build dependency? since, if it didn't, > > this wouldn't make any sense. > > and hence no, it doesn't relax other rules. ah, i should have known/remembered that. thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] wic: --fsoptions handling
Add handling of --fsoptions in parition definition. If no options are specified, 'defaults' is used. Signed-off-by: Maciej Borzecki Signed-off-by: Maciek Borzecki --- scripts/lib/mic/imager/direct.py | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/scripts/lib/mic/imager/direct.py b/scripts/lib/mic/imager/direct.py index 77a118a..7e2b63a 100644 --- a/scripts/lib/mic/imager/direct.py +++ b/scripts/lib/mic/imager/direct.py @@ -113,7 +113,15 @@ class DirectImageCreator(BaseImageCreator): device_name = "/dev/" + p.disk + str(num + 1) else: device_name = "/dev/" + p.disk + str(num) -fstab_entry = device_name + "\t" + p.mountpoint + "\t" + p.fstype + "\tdefaults\t0\t0\n" + +opts = "defaults" +if p.fsopts: +opts = p.fsopts + +fstab_entry = device_name + "\t" + \ + p.mountpoint + "\t" + \ + p.fstype + "\t" + \ + opts + "\t0\t0\n" fstab_lines.append(fstab_entry) def _write_fstab(self, fstab, fstab_lines): -- 1.9.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] wic: squashfs partition support
It is possible to instruct wic to create a squashfs partition by setting
--fstype=squashfs in *.wks. For now this is only useable for rootfs
partitions (note that you must have squashfs support in the kernel). An
attempt to create an empty partition will produce a warning.
Signed-off-by: Maciej Borzecki
---
.../lib/mic/kickstart/custom_commands/partition.py | 61 ++
1 file changed, 61 insertions(+)
diff --git a/scripts/lib/mic/kickstart/custom_commands/partition.py
b/scripts/lib/mic/kickstart/custom_commands/partition.py
index d0f1b78..ce90aa1 100644
--- a/scripts/lib/mic/kickstart/custom_commands/partition.py
+++ b/scripts/lib/mic/kickstart/custom_commands/partition.py
@@ -25,6 +25,8 @@
#
import shutil
+import os
+import tempfile
from pykickstart.commands.partition import *
from mic.utils.oe.misc import *
@@ -192,6 +194,10 @@ class Wic_PartData(Mic_PartData):
return self.prepare_rootfs_vfat(cr_workdir, oe_builddir,
rootfs_dir, native_sysroot,
pseudo)
+elif self.fstype.startswith("squashfs"):
+return self.prepare_rootfs_squashfs(cr_workdir, oe_builddir,
+rootfs_dir, native_sysroot,
+pseudo)
def prepare_rootfs_ext(self, cr_workdir, oe_builddir, rootfs_dir,
native_sysroot, pseudo):
@@ -324,6 +330,28 @@ class Wic_PartData(Mic_PartData):
self.set_size(rootfs_size)
self.set_source_file(rootfs)
+def prepare_rootfs_squashfs(self, cr_workdir, oe_builddir, rootfs_dir,
+native_sysroot, pseudo):
+"""
+Prepare content for a squashfs rootfs partition.
+"""
+image_rootfs = rootfs_dir
+rootfs = "%s/rootfs_%s.%s" % (cr_workdir, self.label ,self.fstype)
+
+squashfs_cmd = "mksquashfs %s %s -noappend" % \
+ (image_rootfs, rootfs)
+rc, out = exec_native_cmd(pseudo + squashfs_cmd, native_sysroot)
+
+# get the rootfs size in the right units for kickstart (Mb)
+du_cmd = "du -Lbms %s" % rootfs
+rc, out = exec_cmd(du_cmd)
+rootfs_size = out.split()[0]
+
+self.size = rootfs_size
+self.source_file = rootfs
+
+return 0
+
def prepare_empty_partition(self, cr_workdir, oe_builddir, native_sysroot):
"""
Prepare an empty partition.
@@ -337,6 +365,9 @@ class Wic_PartData(Mic_PartData):
elif self.fstype.startswith("vfat"):
return self.prepare_empty_partition_vfat(cr_workdir, oe_builddir,
native_sysroot)
+elif self.fstype.startswith("squashfs"):
+return self.prepare_empty_partition_squashfs(cr_workdir,
oe_builddir,
+ native_sysroot)
def prepare_empty_partition_ext(self, cr_workdir, oe_builddir,
native_sysroot):
@@ -398,6 +429,36 @@ class Wic_PartData(Mic_PartData):
return 0
+def prepare_empty_partition_squashfs(self, cr_workdir, oe_builddir,
+ native_sysroot):
+"""
+Prepare an empty squashfs partition.
+"""
+msger.warning("Creating of an empty squashfs %s partition was
attempted. " \
+ "Proceeding as requested." % self.mountpoint)
+
+fs = "%s/fs_%s.%s" % (cr_workdir, self.label, self.fstype)
+
+# it is not possible to create a squashfs without source data,
+# thus prepare an empty temp dir that is used as source
+tmpdir = tempfile.mkdtemp()
+
+squashfs_cmd = "mksquashfs %s %s -noappend" % \
+ (tmpdir, fs)
+rc, out = exec_native_cmd(squashfs_cmd, native_sysroot)
+
+os.rmdir(tmpdir)
+
+# get the rootfs size in the right units for kickstart (Mb)
+du_cmd = "du -Lbms %s" % fs
+rc, out = exec_cmd(du_cmd)
+fs_size = out.split()[0]
+
+self.size = fs_size
+self.source_file = fs
+
+return 0
+
def prepare_swap_partition(self, cr_workdir, oe_builddir, native_sysroot):
"""
Prepare a swap partition.
--
1.9.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] Mention package_tar packaging in local.conf.sample
On Thu, 2014-07-24 at 05:10 -0400, Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day > > --- > > is this the appropriate comment for tarball packaging? > > diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample > index 555f8db..a22 100644 > --- a/meta/conf/local.conf.sample > +++ b/meta/conf/local.conf.sample > @@ -78,7 +78,8 @@ MACHINE ??= "qemux86" > # - 'package_deb' for debian style deb files > # - 'package_ipk' for ipk files are used by opkg (a debian style embedded > package manager) > # - 'package_rpm' for rpm style packages > -# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk" > +# - 'package_tar' for tarball packages > +# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk package_tar" > # We default to ipk: > PACKAGE_CLASSES ?= "package_ipk" > The class is pretty useless, lets leave this one less documented ;-) I keep thinking we should delete it instead to be honest... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] simple dependency question
On Thu, 2014-07-24 at 07:13 -0400, Robert P. J. Day wrote: > i realize that "DEPENDS" represents build-time dependencies, as in > ... all of the DEPENDS recipes must build *completely* before this > recipe can *begin* to build, is that correct? > > however, in something like module.bbclass where one finds: > > do_make_scripts[deptask] = "do_populate_sysroot" > > does that now *override* the normal build-time dependency to say only > that this recipe's do_make_scripts task need only wait until all of > the "DEPENDS" recipes have completed their do_populate_sysroot tasks? The original DEPENDS meaning remains unchanged and applies to the configure task. The behaviour of DEPENDS comes from: do_configure[deptask] = "do_populate_sysroot" which means the configure task waits for all the populate_sysroot tasks of DEPENDS to complete before executing this task. do_make_scripts[deptask] = "do_populate_sysroot" Adds constraints to the make_scripts task where it also must wait until all DEPENDS populate_sysroot have run before it can. > in other words, the instant i define an inter-task dependency, does > that relax the normal strong build dependency? since, if it didn't, > this wouldn't make any sense. and hence no, it doesn't relax other rules. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] allarch: Generate same package for MIPS and non-MIPS targets
LINKER_HASH_STYLE differs between MIPS and non-MIPS targets. This means
that LDFLAGS differs too. LDFLAGS is exported so it influences all task
hashes. Unfortunately this means that packages with architecture "all"
differ depending on whether they are built for a MIPS or non-MIPS target.
This causes a lot of unnecessary churn in the ipk/all directory when
switching build targets.
The simplest way to fix this is to ensure that LDFLAGS stays the same for
architecture "all" packages by clearing it. It shouldn't being used by such
packages anyway.
Signed-off-by: Mike Crowe
---
meta/classes/allarch.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index d41dd4b..c953e7c 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -28,6 +28,11 @@ python () {
d.setVar("SDK_ARCH", "none")
d.setVar("SDK_CC_ARCH", "none")
+# Avoid this being unnecessarily different due to nuances of
+# the target machine that aren't important for "all" arch
+# packages.
+d.setVar("LDFLAGS", "")
+
# No need to do shared library processing or debug symbol handling
d.setVar("EXCLUDE_FROM_SHLIBS", "1")
d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
--
2.0.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] State of bitbake world, wrong PACKAGE_ARCHs 2014-07-24
This is new report generated with oe-core/scripts/sstate-diff-machines.sh To reproduce it, you need "qemux86copy" MACHINE which is the same as qemux86 only with different name (to simulate 2 MACHINEs with same TUNE_PKGARCH in oe-core). You can find commit adding "qemux86copy" in jansa/master branch: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/master Current logs: http://logs.nslu2-linux.org/buildlogs/oe/world/log.signatures.20140724_010942.log/ jansa/master branches are containing couple of pending changes (mostly to remove allarch), so if you try it with current master branches it will be (a lot) worse. > ERROR: 43 issues were found in these recipes: android-tools dracut > font-alias initscripts ipsec-tools libxml-filter-buffertext-perl > libxml-sax-writer-perl lmsensors oprofile oprofileui oprofileui-server > polkit-group-rule-datetime polkit-group-rule-network shr-theme-neo > sysvinit tipcutils vpnc xfce4-session xl2tpd xserver-common > xserver-nodm-init xuser-account ERROR: 57 issues were found in these recipes: android-tools dracut font-alias initscripts ipsec-tools libxml-filter-buffertext-perl libxml-sax-writer-perl lmsensors oprofile oprofileui oprofileui-server polkit-group-rule-datetime polkit-group-rule-network shr-theme-neo sysvinit terminus-font tipcutils ttf-arphic-uming ttf-dejavu ttf-droid ttf-gentium ttf-hunkyfonts ttf-inconsolata ttf-liberation ttf-mplus ttf-sazanami ttf-ubuntu-font-family ttf-wqy-zenhei vpnc xfce4-session xl2tpd xserver-common xserver-nodm-init xuser-account no improvement on this front, it even got a bit worse because ttf* allarch recipes gained runtime dependency on TUNE_PKGARCH fontconfig > The best way to read and fix this issues is to fix do_configure > signatures first, because otherwise the same recipes are listed also in > do_populate_sysroot and do_package_write_ipk logs (I've tried to remove > "duplicities" in this e-mail) === Comparing signatures for task do_configure.sigdata between qemux86copy and qemux86 === ERROR: ipsec-tools different signature for task do_configure.sigdata between qemux86copy and qemux86 Hash for dependent task linux-yocto_3.14.bb.do_populate_sysroot changed from 0446075964867e62e8e631878de6832d to 9d2e475ed80a276182d16181d81f8639 ERROR: oprofile different signature for task do_configure.sigdata between qemux86copy and qemux86 Hash for dependent task linux-yocto_3.14.bb.do_populate_sysroot changed from 0446075964867e62e8e631878de6832d to 9d2e475ed80a276182d16181d81f8639 ERROR: tipcutils different signature for task do_configure.sigdata between qemux86copy and qemux86 Hash for dependent task linux-yocto_3.14.bb.do_populate_sysroot changed from 0446075964867e62e8e631878de6832d to 9d2e475ed80a276182d16181d81f8639 ERROR: xl2tpd different signature for task do_configure.sigdata between qemux86copy and qemux86 Hash for dependent task linux-yocto_3.14.bb.do_populate_sysroot changed from 0446075964867e62e8e631878de6832d to 9d2e475ed80a276182d16181d81f8639 ERROR: 4 errors found in /home/jenkins/oe/world/shr-core/tmp-eglibc/sstate-diff/1406164182/signatures.qemux86.do_configure.sigdata.log === Comparing signatures for task do_populate_sysroot.sigdata between qemux86copy and qemux86 === ERROR: initscripts different signature for task do_populate_sysroot.sigdata between qemux86copy and qemux86 Hash for dependent task initscripts_1.0.bb.do_install changed from 170c1ec29ccecf61834957d8baf77cfd to 0b7e40649be9c13355a440a00cd86489 ERROR: ipsec-tools different signature for task do_populate_sysroot.sigdata between qemux86copy and qemux86 Hash for dependent task ipsec-tools_0.8.1.bb.do_install changed from c0dce8c3763ecaf499b4ac84d1f6b93a to 8e0024ff3a924e118861252574d745bf ERROR: oprofile different signature for task do_populate_sysroot.sigdata between qemux86copy and qemux86 Hash for dependent task oprofile_0.9.9.bb.do_install changed from de26574c09b5d5ec3dfbc0673eff4e55 to 2e970d5a2406ec721ae882184d8054b5 ERROR: tipcutils different signature for task do_populate_sysroot.sigdata between qemux86copy and qemux86 Hash for dependent task tipcutils_2.0.6.bb.do_install changed from 038cac0745f61713f579657b1f32a82d to 4c4f76d3617aa8c8b11af7452aa63aac ERROR: xl2tpd different signature for task do_populate_sysroot.sigdata between qemux86copy and qemux86 Hash for dependent task xl2tpd_git.bb.do_install changed from c9e55b16445f72b1717e8eacb1fd87de to 804f93bffd8a9ec62c67660c36452a11 ERROR: 5 errors found in /home/jenkins/oe/world/shr-core/tmp-eglibc/sstate-diff/1406164182/signatures.qemux86.do_populate_sysroot.sigdata.log === Comparing signatures for task do_package_write_ipk.sigdata between qemux86copy and qemux86 === ERROR: android-tools different signature for task do_package_write_ipk.sigdata between qemux86copy and qemux86 Hash for dependent task android-tools-conf_1.0.bb.do_packagedata changed from 195da381fa622a602e2291e5546adac9 to a044baf70a14323659d5cd9a752928d2 ERROR: dracut dif
Re: [OE-core] simple dependency question
On Thu, 24 Jul 2014, Robert P. J. Day wrote: > > i realize that "DEPENDS" represents build-time dependencies, as in > ... all of the DEPENDS recipes must build *completely* before this > recipe can *begin* to build, is that correct? > > however, in something like module.bbclass where one finds: > > do_make_scripts[deptask] = "do_populate_sysroot" > > does that now *override* the normal build-time dependency to say only > that this recipe's do_make_scripts task need only wait until all of > the "DEPENDS" recipes have completed their do_populate_sysroot tasks? > > in other words, the instant i define an inter-task dependency, does > that relax the normal strong build dependency? since, if it didn't, > this wouldn't make any sense. sorry, i shouldn't have described that as an "inter-task" dependency, i realize that's different, as in: ncurses.inc:do_test[depends] = "unifdef-native:do_populate_sysroot" rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] simple dependency question
i realize that "DEPENDS" represents build-time dependencies, as in ... all of the DEPENDS recipes must build *completely* before this recipe can *begin* to build, is that correct? however, in something like module.bbclass where one finds: do_make_scripts[deptask] = "do_populate_sysroot" does that now *override* the normal build-time dependency to say only that this recipe's do_make_scripts task need only wait until all of the "DEPENDS" recipes have completed their do_populate_sysroot tasks? in other words, the instant i define an inter-task dependency, does that relax the normal strong build dependency? since, if it didn't, this wouldn't make any sense. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ 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 2014-07-24
http://www.openembedded.org/wiki/Bitbake_World_Status
mkvtoolnix is review for new version, it builds fine on 2/3 builders I
have access too, I'll investigate before merging it
firefox is probably fixed by
http://patchwork.openembedded.org/patch/75173/
I'll include this work around in my next world builds
monkey issue is in new review and looked at by submitter
lttng-modules issue was reported on ML and it seems that we can expect
upgrade to newer version soon
openal-soft, gst-ffmpeg aren't compatible with libav-9 now used by world
builds.
python-efl and llvm* were fixed just before qemux86_64 and qemuarm
== Failed tasks 2014-07-24 ==
=== common (5) ===
* meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile
*
meta-openembedded/meta-multimedia/recipes-mkv/mkvtoolnix/mkvtoolnix_7.0.0.bb,
do_configure
*
meta-openembedded/meta-multimedia/recipes-multimedia/openal/openal-soft_1.15.1.bb,
do_compile
* meta-openembedded/meta-webserver/recipes-httpd/monkey/monkey_1.5.1.bb,
do_package_write_ipk
*
openembedded-core/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb,
do_compile
=== common-x86 (4) ===
* meta-browser/recipes-browser/chromium/chromium_35.0.1916.114.bb,
do_compile
*
meta-openembedded/meta-initramfs/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.10.bb,
do_package_qa
*
meta-openembedded/meta-networking/recipes-connectivity/snort/snort_2.9.6.0.bb,
do_configure
*
meta-openembedded/meta-oe/recipes-devtools/concurrencykit/concurrencykit_git.bb,
do_compile
=== qemuarm (3) ===
*
meta-openembedded/meta-xfce/recipes-apps/xfce4-screenshooter/xfce4-screenshooter_1.8.1.bb,
do_compile
* meta-smartphone/meta-shr/recipes-shr/games/mokomaze_0.5.5.bb, do_configure
* openembedded-core/meta/recipes-kernel/lttng/lttng-modules_2.3.3.bb,
do_compile
=== qemux86 (4) ===
* meta-openembedded/meta-efl/recipes-devtools/python/python-efl_1.10.0.bb,
do_compile
*
meta-openembedded/meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.16.bb,
do_compile
* meta-openembedded/meta-oe/recipes-core/llvm/llvm2.9_2.9.bb, do_package_qa
* meta-openembedded/meta-oe/recipes-core/llvm/llvm3.3_3.3.bb, do_package_qa
=== qemux86_64 (2) ===
*
meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb,
do_compile
* meta-qt5/recipes-qt/qt5/qtwebengine_git.bb, do_compile
=== Number of failed tasks ===
{| class=wikitable
|-
||qemuarm ||8
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140723_074225.log/||http://errors.yoctoproject.org:80/Errors/Search/1/1417/
|-
||qemux86 ||13
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140721_190633.log/||
|-
||qemux86_64||12
||http://logs.nslu2-linux.org/buildlogs/oe/world//log.world.20140722_123448.log/||
|}
--
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] State of bitbake world, test-dependencies 2014-07-24
Another incremental with many fixes for foreign automake and missing dependencies for m4 macro providers and couple of PNBLACKLISTs. Complete logs: http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20140724_013722.log/ mkvtoolnix is review for new version, it builds fine on 2/3 builders I have access too, I'll investigate before merging it firefox is probably fixed by http://patchwork.openembedded.org/patch/75173/ I'll include this work around in my next world builds monkey issue is in new review and looked at by submitter lttng-modules issue was reported on ML and it seems that we can expect upgrade to newer version soon openal-soft, gst-ffmpeg aren't compatible with libav-9 now used by world builds. packagegroup-shr-feed is here just because of firefox ERROR: 17 issues were found in these recipes: firefox gst-ffmpeg lttng-modules mkvtoolnix monkey openal-soft packagegroup-shr-feed So it looks like we're again in better shape, but something is strange with this new insane_qa check for build dependencies, since it was introduced in master-next it finds more issues than test-dependencies.sh did and vice-versa test-dependencies.sh now doesn't report some issues which IIRC weren't properly fixed yet. So we need to double check why. insane_qa check: dconf-0.18.0: dconf-editor rdepends on libxml2 but its not a build dependency? [build-deps] directfb-1.7.4: directfb rdepends on libdrm but its not a build dependency? [build-deps] directfb-1.7.4: directfb rdepends on libdrm-kms but its not a build dependency? [build-deps] directfb-1.7.4: directfb rdepends on liblzma but its not a build dependency? [build-deps] directfb-1.7.4: directfb rdepends on tiff but its not a build dependency? [build-deps] engrave-0.0.0+svnr82070: engrave rdepends on flex but its not a build dependency? [build-deps] epiphany-2.30.6: epiphany rdepends on libavahi-client but its not a build dependency? [build-deps] epiphany-2.30.6: epiphany rdepends on libavahi-common but its not a build dependency? [build-deps] epiphany-2.30.6: epiphany rdepends on libavahi-gobject but its not a build dependency? [build-deps] epiphany-2.30.6: epiphany rdepends on libnotify but its not a build dependency? [build-deps] evopedia-0.4.2+gitrAUTOINC+36ca70acb4: evopedia rdepends on libbz2 but its not a build dependency? [build-deps] expedite-1.7.9: expedite rdepends on evas-engine-fb but its not a build dependency? [build-deps] expedite-1.7.9: expedite rdepends on evas-engine-software-generic but its not a build dependency? [build-deps] expedite-1.7.9: expedite rdepends on evas-loader-png but its not a build dependency? [build-deps] expedite-1.7.9: expedite rdepends on libsdl but its not a build dependency? [build-deps] gd-2.1.0: gd rdepends on liblzma but its not a build dependency? [build-deps] gd-2.1.0: gd rdepends on tiff but its not a build dependency? [build-deps] gimp-2.8.10: gimp rdepends on libbz2 but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on gtk+3 but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on json-c but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on libcap but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on libpulse but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on libpulse-mainloop-glib but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on libsndfile1 but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on libxi but its not a build dependency? [build-deps] gmtk-1.0.5: gmtk rdepends on libxtst but its not a build dependency? [build-deps] gnome-disk-utility-2.32.0: gnome-disk-utility-libs rdepends on libgnome-keyring but its not a build dependency? [build-deps] gtksourceview2-2.10.5: gtksourceview2 rdepends on libxml2 but its not a build dependency? [build-deps] guile-2.0.11: guile rdepends on ncurses-libncurses but its not a build dependency? [build-deps] guile-2.0.11: guile rdepends on readline but its not a build dependency? [build-deps] kernelshark-1.2+gitAUTOINC+7055ffd37b: kernelshark rdepends on libxml2 but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-cat rdepends on libklibc but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-chroot rdepends on libklibc but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-cpio rdepends on libklibc but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-dd rdepends on libklibc but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-dmesg rdepends on libklibc but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-false rdepends on libklibc but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-fstype rdepends on libklibc but its not a build dependency? [build-deps] klibc-utils-2.0.3: klibc-utils-gunzip rdepends on libklibc but its not a build depen
[OE-core] [PATCH] kernel.bbclass: don't install initramfs bundled kernel image
There is no dependency relationship between the tasks bundle_initramfs
and package so far, therefore we never should install the bundled image
anyway, otherwise we will end up with a implicit kernel-image package
that sometimes it contains the initramfs bundled image or it doesn't at
other times.
Signed-off-by: Ming Liu
---
meta/classes/kernel.bbclass | 4
1 file changed, 4 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b2e9d4c..bb19b5c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -135,10 +135,6 @@ do_bundle_initramfs () {
kernel_do_compile
mv -f ${KERNEL_OUTPUT} ${KERNEL_OUTPUT}.initramfs
mv -f ${KERNEL_OUTPUT}.bak ${KERNEL_OUTPUT}
- # Update install area
- echo "There is kernel image bundled with initramfs:
${B}/${KERNEL_OUTPUT}.initramfs"
- install -m 0644 ${B}/${KERNEL_OUTPUT}.initramfs
${D}/boot/${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin
- echo "${B}/${KERNEL_OUTPUT}.initramfs"
fi
}
--
1.8.4.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] Mention package_tar packaging in local.conf.sample
On Thursday 24 July 2014 10:16:02 Burton, Ross wrote: > On 24 July 2014 10:10, Robert P. J. Day wrote: > > +# - 'package_tar' for tarball packages > > +# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk > > package_tar" > package_tar is pretty limited (no dependencies, so images don't work) > - is there a good reason to keep it around? If we're going to delete > it, now is the time to do it... I've really not heard of anyone using it recently. I have at least kept it working over the last little while, and it might possibly be useful on a limited basis if you want the output of certain recipes to be in the form of a tarball; without dependencies though as you say it's of no use beyond that. I'd be fine with dropping it as well if it's simply not going to be used. 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
[OE-core] [PATCH] autotools.bbclass: Enhance sed regexp to avoid extra subshell
head -n1 can be done using sed.
Signed-off-by: Matthieu Crapet
---
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 19edc54..afca760 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -195,7 +195,7 @@ autotools_do_configure() {
else
acpaths="${acpaths}"
fi
- AUTOV=`automake --version |head -n 1 |sed "s/.*
//;s/\.[0-9]\+$//"`
+ AUTOV=`automake --version | sed -e '1{s/.*
//;s/\.[0-9]\+$//};q'`
automake --version
echo "AUTOV is $AUTOV"
if [ -d ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV ]; then
--
2.0.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] Mention package_tar packaging in local.conf.sample
On Thu, 24 Jul 2014, Burton, Ross wrote: > On 24 July 2014 10:10, Robert P. J. Day wrote: > > +# - 'package_tar' for tarball packages > > +# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk > > package_tar" > > package_tar is pretty limited (no dependencies, so images don't work) > - is there a good reason to keep it around? If we're going to delete > it, now is the time to do it... i'm fine with that, just trying to be consistent. i'm always a big fan of throwing stuff away. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] Mention package_tar packaging in local.conf.sample
On 24 July 2014 10:10, Robert P. J. Day wrote: > +# - 'package_tar' for tarball packages > +# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk package_tar" package_tar is pretty limited (no dependencies, so images don't work) - is there a good reason to keep it around? If we're going to delete it, now is the time to do it... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH] Mention package_tar packaging in local.conf.sample
Signed-off-by: Robert P. J. Day --- is this the appropriate comment for tarball packaging? diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample index 555f8db..a22 100644 --- a/meta/conf/local.conf.sample +++ b/meta/conf/local.conf.sample @@ -78,7 +78,8 @@ MACHINE ??= "qemux86" # - 'package_deb' for debian style deb files # - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager) # - 'package_rpm' for rpm style packages -# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk" +# - 'package_tar' for tarball packages +# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk package_tar" # We default to ipk: PACKAGE_CLASSES ?= "package_ipk" -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] shadow-securetty: add freescale lpuart
Add Freescale lpuart tty's (ttyLPx) to securetty. Freescale Vybrid devices running upstream kernel use this driver. Signed-off-by: Stefan Agner --- meta/recipes-extended/shadow/files/securetty | 8 1 file changed, 8 insertions(+) diff --git a/meta/recipes-extended/shadow/files/securetty b/meta/recipes-extended/shadow/files/securetty index 0b1629f..d919993 100644 --- a/meta/recipes-extended/shadow/files/securetty +++ b/meta/recipes-extended/shadow/files/securetty @@ -137,6 +137,14 @@ ttymxc3 ttymxc4 ttymxc5 +# Freescale lpuart ports +ttyLP0 +ttyLP1 +ttyLP2 +ttyLP3 +ttyLP4 +ttyLP5 + # Standard serial ports, with devfs tts/0 tts/1 -- 2.0.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
