[OE-core] [PATCH] lttng-modules: update to 2.4.1 version
*This updates lttng-modules for 2.4.1 and
it also fixes the build with 3.13 Linux kernel.
Signed-off-by: Chunrong Guo
---
.../lttng/lttng-modules/bio-bvec-iter.patch| 156 -
meta/recipes-kernel/lttng/lttng-modules_2.4.0.bb | 38 -
meta/recipes-kernel/lttng/lttng-modules_2.4.1.bb | 38 +
3 files changed, 38 insertions(+), 194 deletions(-)
delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/bio-bvec-iter.patch
delete mode 100644 meta/recipes-kernel/lttng/lttng-modules_2.4.0.bb
create mode 100644 meta/recipes-kernel/lttng/lttng-modules_2.4.1.bb
diff --git a/meta/recipes-kernel/lttng/lttng-modules/bio-bvec-iter.patch
b/meta/recipes-kernel/lttng/lttng-modules/bio-bvec-iter.patch
deleted file mode 100644
index d6c66e4..000
--- a/meta/recipes-kernel/lttng/lttng-modules/bio-bvec-iter.patch
+++ /dev/null
@@ -1,156 +0,0 @@
-Upstream-Status: Pending
-
-In 3.14, bi_sector and bi_size were moved into an iterator, thus
-breaking any tracepoints that still expect them in the bio. Fix up
-the lttng-module tracepoints to use the new scheme when the kernel
-version is >= 3.14.
-
-Signed-off-by: Tom Zanussi
-
-diff --git a/instrumentation/events/lttng-module/block.h
b/instrumentation/events/lttng-module/block.h
-index f3b8bff..0a61543 100644
a/instrumentation/events/lttng-module/block.h
-+++ b/instrumentation/events/lttng-module/block.h
-@@ -341,9 +341,15 @@ TRACE_EVENT(block_bio_bounce,
- TP_fast_assign(
- tp_assign(dev, bio->bi_bdev ?
- bio->bi_bdev->bd_dev : 0)
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0))
-+ tp_assign(sector, bio->bi_iter.bi_sector)
-+ tp_assign(nr_sector, bio->bi_iter.bi_size >> 9)
-+ blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_iter.bi_size)
-+#else /* #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- tp_assign(sector, bio->bi_sector)
- tp_assign(nr_sector, bio->bi_size >> 9)
- blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_size)
-+#endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- tp_memcpy(comm, current->comm, TASK_COMM_LEN)
- ),
-
-@@ -385,14 +391,24 @@ TRACE_EVENT(block_bio_complete,
-
- TP_fast_assign(
- tp_assign(dev, bio->bi_bdev->bd_dev)
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0))
-+ tp_assign(sector, bio->bi_iter.bi_sector)
-+ tp_assign(nr_sector, bio->bi_iter.bi_size >> 9)
-+#else /* #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- tp_assign(sector, bio->bi_sector)
- tp_assign(nr_sector, bio->bi_size >> 9)
-+#endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
-+
- #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,38))
- tp_assign(error, error)
- #else
- tp_assign(error, 0)
- #endif
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0))
-+ blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_iter.bi_size)
-+#else /* #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_size)
-+#endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- ),
-
- TP_printk("%d,%d %s %llu + %u [%d]",
-@@ -419,9 +435,15 @@ DECLARE_EVENT_CLASS(block_bio_merge,
-
- TP_fast_assign(
- tp_assign(dev, bio->bi_bdev->bd_dev)
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0))
-+ tp_assign(sector, bio->bi_iter.bi_sector)
-+ tp_assign(nr_sector, bio->bi_iter.bi_size >> 9)
-+ blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_iter.bi_size)
-+#else /* #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- tp_assign(sector, bio->bi_sector)
- tp_assign(nr_sector, bio->bi_size >> 9)
- blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_size)
-+#endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- tp_memcpy(comm, current->comm, TASK_COMM_LEN)
- ),
-
-@@ -485,9 +507,15 @@ TRACE_EVENT(block_bio_queue,
-
- TP_fast_assign(
- tp_assign(dev, bio->bi_bdev->bd_dev)
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0))
-+ tp_assign(sector, bio->bi_iter.bi_sector)
-+ tp_assign(nr_sector, bio->bi_iter.bi_size >> 9)
-+ blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_iter.bi_size)
-+#else /* #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- tp_assign(sector, bio->bi_sector)
- tp_assign(nr_sector, bio->bi_size >> 9)
- blk_fill_rwbs(rwbs, bio->bi_rw, bio->bi_size)
-+#endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,14,0)) */
- tp_memcpy(comm, current->comm, TASK_COMM_LEN)
- ),
-
-@@ -513,9 +541,15 @@ DECLARE_EVENT_CLASS(block_bio,
-
- TP_fast_assign(
- tp_assign(dev, bio->bi_bdev ? bio->bi_bdev->bd_dev : 0)
-+#if (L
Re: [OE-core] [PATCH 1/1] tar: set acpaths to avoid "Argument list too long" error
ping
On 04/09/2014 05:44 PM, Chong Lu wrote:
There would be an error when the TMPDIR is long/deep, for example when
len(TMPDIR) = 410 while our supported longest value is 410:
aclocal: error: cannot open xxx
autoreconf: aclocal failed with exit status: 1
ERROR: autoreconf execution failed.
Let aclocal use the relative path for the m4 file rather than the
absolute would fix the problem.
[YOCTO #6138]
Signed-off-by: Chong Lu
---
meta/recipes-extended/tar/tar.inc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-extended/tar/tar.inc
b/meta/recipes-extended/tar/tar.inc
index 30a1373..75c3518 100644
--- a/meta/recipes-extended/tar/tar.inc
+++ b/meta/recipes-extended/tar/tar.inc
@@ -10,6 +10,12 @@ inherit autotools gettext
EXTRA_OECONF += "DEFAULT_RMT_DIR=${base_sbindir}"
+# Let aclocal use the relative path for the m4 file rather than the
+# absolute since tar has a lot of m4 files, otherwise there might
+# be an "Argument list too long" error when it is built in a long/deep
+# directory.
+acpaths = "-I ./m4"
+
EXTRAINSTALL = "do_install_extra"
EXTRAINSTALL_class-nativesdk = ""
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V4 1/1] dbus: fix a hard dependency about dbus-ptest
ping
On 04/08/2014 11:30 AM, Chong Lu wrote:
If image contains dbus and ptest is in DISTRO_FEATURES, dbus-ptest package
is installed, regardless of whether ptest-pkgs is in IMAGE_FEATURES. This
issue will increase size for most small images.
This patch fixes this problem.
[YOCTO #5702]
Signed-off-by: Chong Lu
---
meta/recipes-core/dbus/{dbus-ptest_1.6.18.bb => dbus-test_1.6.18.bb} | 0
meta/recipes-core/dbus/dbus.inc | 4 +++-
2 files changed, 3 insertions(+), 1 deletion(-)
rename meta/recipes-core/dbus/{dbus-ptest_1.6.18.bb => dbus-test_1.6.18.bb}
(100%)
diff --git a/meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
b/meta/recipes-core/dbus/dbus-test_1.6.18.bb
similarity index 100%
rename from meta/recipes-core/dbus/dbus-ptest_1.6.18.bb
rename to meta/recipes-core/dbus/dbus-test_1.6.18.bb
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 5727ae7..9a9a00a 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -6,9 +6,11 @@ LICENSE = "AFL-2 | GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb3c"
DEPENDS = "expat virtual/libintl"
-RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest-ptest',
'', d)}"
RDEPENDS_dbus_class-native = ""
RDEPENDS_dbus_class-nativesdk = ""
+PACKAGES += "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest', '',
d)}"
+ALLOW_EMPTY_dbus-ptest = "1"
+RDEPENDS_dbus-ptest_class-target = "dbus-test-ptest"
SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
file://tmpdir.patch \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] pixbuff.bbclass: check for gdk-pixbuf-query-loaders errors
If we do not see all the bits we need during populate_sysroot_setscene,
we do not want to keep quiet about it and let somebody get screwed
later. By error exiting, we let bitbake try to recover by
rebuilding the package. This will, hopefully, fix any dependency
issues, etc, but if not, at least we tried.
Signed-off-by: Joe Slater
---
meta/classes/pixbufcache.bbclass |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/classes/pixbufcache.bbclass b/meta/classes/pixbufcache.bbclass
index 414fd30..edbb948 100644
--- a/meta/classes/pixbufcache.bbclass
+++ b/meta/classes/pixbufcache.bbclass
@@ -53,7 +53,10 @@ SSTATEPOSTINSTFUNCS_append_class-native = "
pixbufcache_sstate_postinst"
pixbufcache_sstate_postinst() {
if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" =
"populate_sysroot_setscene" ]
then
- gdk-pixbuf-query-loaders --update-cache
+ if ! gdk-pixbuf-query-loaders --update-cache
+ then
+ exit 1
+ fi
fi
}
--
1.7.3.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Patch v2 1/1] meta-skeleton: linux-yocto-custom.bb: use machine overrides
On Sun, 2014-04-13 at 15:43 +, Hart, Darren wrote:
> Indeed, because the SRCURI was made machine specific. In the case of
> Linux Yocto custom... Their is no namespace pollution to worry about,
> as there is with Linux Yocto... Should we perhaps drop all the
> overrides and provide comented examples instead?
That, or we ask Beth to mask out this recipe in the nightly-qa-skeleton
build...
Cheers,
Richard
>
> On Apr 13, 2014 8:39 AM, Richard Purdie
> wrote:
> On Fri, 2014-04-11 at 10:59 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble
> >
> > Use machine overrides for variables for this skeleton kernel recipe
> > so that people following skeleton do it right at the beginning.
> >
> > The machine overrides for the variables reduces variable name-space
> > pollution and avoids unintentional influences on other layers.
> >
> > Signed-off-by: Nitin A Kamble
> > ---
> > meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 16
> > +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> > b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> > index c329106..16db4a3 100644
> > --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> > +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> > @@ -44,21 +44,23 @@
> > inherit kernel
> > require recipes-kernel/linux/linux-yocto.inc
> >
> > +#Note: Replace the yourmachine string with your actual machine name here
> > +
> > # Override SRC_URI in a bbappend file to point at a different source
> > # tree if you do not want to build from Linus' tree.
> > -SRC_URI =
> > "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=machine"
> > +SRC_URI_yourmachine =
> > "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=yourmachine"
> >
> > -LINUX_VERSION ?= "3.4"
> > -LINUX_VERSION_EXTENSION ?= "-custom"
> > +LINUX_VERSION_yourmachine ?= "3.4"
> > +LINUX_VERSION_EXTENSION_yourmachine ?= "-custom"
> >
> > # Override SRCREV to point to a different commit in a bbappend file to
> > # build a different release of the Linux kernel.
> > # tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
> > -SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"
> > +SRCREV_yourmachine="76e10d158efb6d4516018846f60c2ab5501900bc"
> >
> > PR = "r1"
> > PV = "${LINUX_VERSION}+git${SRCPV}"
> >
> > -# Override COMPATIBLE_MACHINE to include your machine in a bbappend
> > -# file. Leaving it empty here ensures an early explicit build failure.
> > -COMPATIBLE_MACHINE = "(^$)"
> > +# Override COMPATIBLE_MACHINE to include your yourmachine in a bbappend
> > +# file.
> > +COMPATIBLE_MACHINE_yourmachine = "yourmachine"
>
> This breaks the autobuilder:
>
> http://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/43/steps/BuildImages/logs/stdio
>
> Cheers,
>
> Richard
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Package sambaserver_3.0.37-r9_mips32el
Hi, there seem to be a bug within the provided Samba server in the package sambaserver_3.0.37-r9_mips32el.ipk. When trying to access Samba server as a non root user, the following appears in the log: [1] On the Samba mailing list I found a hint that the problem rises during the "./configure" command within the cross compile environment. I described the problem in more detail in a thread in the Openpli forum [2]. I'm coming directly to this mailing list because it has been mentioned within the maintainer info in the package manager. So could someone please take a look into that? If you need more info about that issue, please ask. Thanks, Michael Neurohr [1] [2014/04/10 17:16:49, 0] lib/util_sec.c:assert_gid(119) Failed to set gid privileges to (-1,1000) now set to (0,0) uid=(0,0) [2014/04/10 17:16:49, 0] lib/util.c:smb_panic(1633) PANIC (pid 16280): failed to set gid [2014/04/10 17:16:49, 0] lib/util.c:log_stack_trace(1737) BACKTRACE: 1 stack frames: #0 /usr/sbin/smbd(log_stack_trace+0x40) [0x778aca58] [2014/04/10 17:16:49, 0] lib/fault.c:dump_core(181) dumping core in /var/log/cores/smbd [2014/04/10 17:16:49, 0] lib/util_sec.c:assert_gid(119) Failed to set gid privileges to (-1,1000) now set to (0,0) uid=(0,0) [2014/04/10 17:16:49, 0] lib/util.c:smb_panic(1633) PANIC (pid 16281): failed to set gid [2014/04/10 17:16:49, 0] lib/util.c:log_stack_trace(1737) BACKTRACE: 1 stack frames: #0 /usr/sbin/smbd(log_stack_trace+0x40) [0x778aca58] [2014/04/10 17:16:49, 0] lib/fault.c:dump_core(181) dumping core in /var/log/cores/smbd [2014/04/10 17:17:04, 0] lib/util_sec.c:assert_gid(119) Failed to set gid privileges to (-1,1000) now set to (0,0) uid=(0,0) [2014/04/10 17:17:04, 0] lib/util.c:smb_panic(1633) PANIC (pid 16286): failed to set gid [2014/04/10 17:17:04, 0] lib/util.c:log_stack_trace(1737) BACKTRACE: 1 stack frames: #0 /usr/sbin/smbd(log_stack_trace+0x40) [0x778aca58] [2014/04/10 17:17:04, 0] lib/fault.c:dump_core(181) dumping core in /var/log/cores/smbd [2] http://openpli.org/forums/topic/33264-use-samba-as-non-root/ -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Patch v2 1/1] meta-skeleton: linux-yocto-custom.bb: use machine overrides
Indeed, because the SRCURI was made machine specific. In the case of Linux
Yocto custom... Their is no namespace pollution to worry about, as there is
with Linux Yocto... Should we perhaps drop all the overrides and provide
comented examples instead?
On Apr 13, 2014 8:39 AM, Richard Purdie
wrote:
On Fri, 2014-04-11 at 10:59 -0700, nitin.a.kam...@intel.com wrote:
> From: Nitin A Kamble
>
> Use machine overrides for variables for this skeleton kernel recipe
> so that people following skeleton do it right at the beginning.
>
> The machine overrides for the variables reduces variable name-space
> pollution and avoids unintentional influences on other layers.
>
> Signed-off-by: Nitin A Kamble
> ---
> meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 16
> +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> index c329106..16db4a3 100644
> --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> @@ -44,21 +44,23 @@
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> +#Note: Replace the yourmachine string with your actual machine name here
> +
> # Override SRC_URI in a bbappend file to point at a different source
> # tree if you do not want to build from Linus' tree.
> -SRC_URI =
> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=machine"
> +SRC_URI_yourmachine =
> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=yourmachine"
>
> -LINUX_VERSION ?= "3.4"
> -LINUX_VERSION_EXTENSION ?= "-custom"
> +LINUX_VERSION_yourmachine ?= "3.4"
> +LINUX_VERSION_EXTENSION_yourmachine ?= "-custom"
>
> # Override SRCREV to point to a different commit in a bbappend file to
> # build a different release of the Linux kernel.
> # tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
> -SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"
> +SRCREV_yourmachine="76e10d158efb6d4516018846f60c2ab5501900bc"
>
> PR = "r1"
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> -# Override COMPATIBLE_MACHINE to include your machine in a bbappend
> -# file. Leaving it empty here ensures an early explicit build failure.
> -COMPATIBLE_MACHINE = "(^$)"
> +# Override COMPATIBLE_MACHINE to include your yourmachine in a bbappend
> +# file.
> +COMPATIBLE_MACHINE_yourmachine = "yourmachine"
This breaks the autobuilder:
http://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/43/steps/BuildImages/logs/stdio
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Patch v2 1/1] meta-skeleton: linux-yocto-custom.bb: use machine overrides
On Fri, 2014-04-11 at 10:59 -0700, nitin.a.kam...@intel.com wrote:
> From: Nitin A Kamble
>
> Use machine overrides for variables for this skeleton kernel recipe
> so that people following skeleton do it right at the beginning.
>
> The machine overrides for the variables reduces variable name-space
> pollution and avoids unintentional influences on other layers.
>
> Signed-off-by: Nitin A Kamble
> ---
> meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 16
> +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> index c329106..16db4a3 100644
> --- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> +++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> @@ -44,21 +44,23 @@
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> +#Note: Replace the yourmachine string with your actual machine name here
> +
> # Override SRC_URI in a bbappend file to point at a different source
> # tree if you do not want to build from Linus' tree.
> -SRC_URI =
> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=machine"
> +SRC_URI_yourmachine =
> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=yourmachine"
>
> -LINUX_VERSION ?= "3.4"
> -LINUX_VERSION_EXTENSION ?= "-custom"
> +LINUX_VERSION_yourmachine ?= "3.4"
> +LINUX_VERSION_EXTENSION_yourmachine ?= "-custom"
>
> # Override SRCREV to point to a different commit in a bbappend file to
> # build a different release of the Linux kernel.
> # tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
> -SRCREV_machine="76e10d158efb6d4516018846f60c2ab5501900bc"
> +SRCREV_yourmachine="76e10d158efb6d4516018846f60c2ab5501900bc"
>
> PR = "r1"
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> -# Override COMPATIBLE_MACHINE to include your machine in a bbappend
> -# file. Leaving it empty here ensures an early explicit build failure.
> -COMPATIBLE_MACHINE = "(^$)"
> +# Override COMPATIBLE_MACHINE to include your yourmachine in a bbappend
> +# file.
> +COMPATIBLE_MACHINE_yourmachine = "yourmachine"
This breaks the autobuilder:
http://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/43/steps/BuildImages/logs/stdio
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
