We use a custom yocto-style kernel recipe to build our non-yocto-style kernel.
To do this we add a defconfig file to the SRC_URI variable and then a bunch of
scc files to the KERNEL_FEATURES variable.
I guess this makes our BSP description auto generated. Can we have an option
to turn the warn
The patch 0056-top-level-reorder_gcc-bug-61144.patch looks wrong.
It looks like a mistake, we shoud patch gcc/varpool.c not create the file
meta/recipes-devtools/gcc/gcc-4.9/0056-top-level-reorder_gcc-bug-61144.patch
Signed-off-by: Bian Naimeng
---
.../0056-top-level-reorder_gcc-bug-61144.patc
- man-1.6e-whatis2.patch does not delete the tail "fi"
fix it to avoid syntax error
- Use the command "which" to get the path of awk
Signed-off-by: Jian Liu
---
meta/recipes-extended/man/man/man-1.6e-whatis2.patch | 7 +++
meta/recipes-extended/man/man/man-1.6g-whatis3.patch | 20
Adds symlink-to-sysroot check to QA_WARN to detect symlinks that
point to locations under TMPDIR, which are most likely broken.
Changes filerdepends from set() to dict(), hence methods for adding
or deleting items had to change too. Now it keeps track of key:value
relationship, flags the QA issue;
On 23/02/15 13:49, Otavio Salvador wrote:
@@ -34,7 +34,7 @@ WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir
xorg-driver-abi \
ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
On Wed, 2015-02-25 at 12:23 +, Burton, Ross wrote:
>
> On 24 February 2015 at 22:17, Benjamin Esquivel
> wrote:
> > So the configure file does not get regenerated as part of
> the standard
> > auto-reconf?
> >
> No, if the fix is only applied at the con
Hello Armin,
This patch is in master. Can you backport it to dizzy branch too?
Thanks,
Daniel
From: openembedded-core-boun...@lists.openembedded.org
[openembedded-core-boun...@lists.openembedded.org] on behalf of Dragomir,
Daniel [daniel.drago...@windriver.com]
On Wed, 2015-02-25 at 06:51 -0800, Patrick Ohly wrote:
> diff --git a/meta/classes/package_rpm.bbclass
> b/meta/classes/package_rpm.bbclass
> index 4f9f813..e305e8b 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -199,10 +199,13 @@ python write_specfil
oe.utils.both_contain() just does a find() on the value
rather than splitting the value and then looking in the
list of split items. The result is that if you add a
feature to MACHINE_FEATURES that itself has a substring
that matches one of the values looked for when building
COMBINED_FEATURES, you
The following changes since commit 40d80f9e019118ac7bcd268f21e350bc154a4a63:
build-appliance-image: Update to master head revision (2015-02-24 23:38:02
+)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib ciorga/YB6888_t2
http://git.yoctoproject.org/cgit.
os.walk() returns symlinks to directories in the "dirs" lists, but then never
enters them by default. As a result, the old code applied neither the
directory handling (because that is active once a directory gets entered) nor
the file handling, and thus never packaged such symlinks.
The fix is sim
os.walk() returns symlinks to directories in the "dirs" lists, but then never
enters them by default. As a result, the old code applied neither the
directory handling (because that is active once a directory gets entered) nor
the file handling, and thus never packaged such symlinks.
The fix is sim
On 24 February 2015 at 22:17, Benjamin Esquivel <
benjamin.esqui...@linux.intel.com> wrote:
> > So the configure file does not get regenerated as part of the standard
> > auto-reconf?
> >
> No, if the fix is only applied at the configure.ac file the unwanted
> behavior still shows up from the conf
Fix up some issues introduced by OE-Core commit
818c94f5b9882c2028ef9f056714a0a3c9045551:
* If we want to support versions with more than two parts, versions with
only one part, or versions with non-integer parts, then we have to
stay with strings. We can use distutils.version.LooseVersion() t
It seems that the --nofork option genuinely stops konsole from going
into the background now; I'm not sure when this changed but it does seem
to be working so we can use it. (Tested with Konsole 2.10 and 2.14.2).
Fixes [YOCTO #4934].
Signed-off-by: Paul Eggleton
---
meta/lib/oe/terminal.py | 8
Fix up some regressions and Konsole 2.x+ support. The Konsole patch can
be left until M4 if we want to be conservative.
These were tested with both old and new versions of konsole and
gnome-terminal.
The following changes since commit c578f5d34ce1718aaeb7dcbf3fc014fd48bac5fc:
build-appliance-
recently began looking at someone's else layer and noticed that that
layer defined a new kernel recipe by (yeesh) creating its very own
"linux-yocto_3.14.bb" file. not a bbappend file -- its very own .bb
file, which i thought was kind of weird.
just to make sure i'm not missing any subtleties
On Wednesday 25 February 2015 09:46:07 Paul Eggleton wrote:
> Hi Sven,
>
> On Monday 23 February 2015 20:39:41 Sven Ebenfeld wrote:
> > --disable-factory has been disabled in earlier versions of gnome-terminal
> > but from version 3.10 it raises an error and quits. This makes devshell
> > unusable
Hi Sven,
On Monday 23 February 2015 20:39:41 Sven Ebenfeld wrote:
> --disable-factory has been disabled in earlier versions of gnome-terminal
> but from version 3.10 it raises an error and quits. This makes devshell
> unusable with gnome-terminal >= 3.10. This patch checks for the version and
> re
On Wed, 25 Feb 2015, Richard Purdie wrote:
> On Wed, 2015-02-25 at 03:25 -0500, Robert P. J. Day wrote:
> > for the sake of reducing build time in the classroom, what are some
> > of the potential (and relatively safe) candidates to add to
> > ASSUME_PROVIDED for a build from scratch?
>
> This p
On Wed, 2015-02-25 at 03:25 -0500, Robert P. J. Day wrote:
> for the sake of reducing build time in the classroom, what are some
> of the potential (and relatively safe) candidates to add to
> ASSUME_PROVIDED for a build from scratch?
This path is fraught with danger to be honest. There are some
for the sake of reducing build time in the classroom, what are some
of the potential (and relatively safe) candidates to add to
ASSUME_PROVIDED for a build from scratch?
i do recall that, once one starts adding more native packages to
that variable, QA becomes an issue but, given a modern dis
22 matches
Mail list logo
