On Wed, Jan 29, 2020 at 5:52 PM Kent Dorfman
wrote:
> OK guys. I was able to make it work with a higher priority layer and
> a bbappend file.
>
> The difference with my config file is that mine actually defines all
> the CONFIG_ options but many of them are =n to override selections
> made
On 1/29/20 8:49 PM, Mark Hatle wrote:
> Should this be applied only to the warrior branch? I don't typically build
> warrior branch, but I'm happy to accept patches if you can verify it's working
> properly.
I tried to apply this patch, but unfortunately it's corrupt. Likely by an
exchange
Sorry, I missed this when it was originally sent.
I've updated master with these patches. Thanks!
Please check master, if you see anything missing please let me know.
--Mark
On 1/20/20 8:00 PM, Yi Zhao wrote:
> From: Hongxu Jia
>
> Since upstream oe-core upgraded openssh to 8.1p1,
> refresh
On 1/29/20 2:40 PM, Richard Purdie wrote:
> This hardware is old/obsolete and unobtainable. Its proving hard to support
> with nobody fixing bugs or helping keep the platform running/up to date.
>
> Whilst there is value in real hardware testing, this platform ist just too
> old and obsolete to
Inherits mime.bbclass to fixe the QA issue: "do_package_qa: QA Issue:
package contains mime types but does not inherit mime"
Signed-off-by: Joshua Watt
---
recipes-support/shared-mime-info/shared-mime-info.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
OK guys. I was able to make it work with a higher priority layer and
a bbappend file.
The difference with my config file is that mine actually defines all
the CONFIG_ options but many of them are =n to override selections
made elsewhere. I just hope that the kernel config is smart enough in
all
Kent,
On 1/29/20 4:53 AM, Kent Dorfman wrote:
> I'd prefer to not go that route.It's a modified "vendor supplied"
> kernel from an internal tarball source, and for IA/QA reasons we're
> NOT going to refer to any external GIT repos.
Well that could be an internal git repository too. You
In message: [linux-yocto-dev v5.5] Rebase the Marvell cn96xx support on v5.5
kernel
on 28/01/2020 Kevin Hao wrote:
> Hi Bruce,
>
> Here is the support for the Marvell cn96xx for v5.5 kernel. Most of the
> patches
> are the same as the ones in v5.4 kernel.
>
> The following changes since
Hi Kent,
On Wed, Jan 29, 2020 at 1:53 PM Kent Dorfman
wrote:
> I'd prefer to not go that route.It's a modified "vendor supplied"
> kernel from an internal tarball source, and for IA/QA reasons we're
> NOT going to refer to any external GIT repos.
>
> There must be a recipe for your "vendor
Hi Kent,
On Wed, Jan 29, 2020 at 07:53:38AM -0500, Kent Dorfman wrote:
> I'd prefer to not go that route.It's a modified "vendor supplied"
> kernel from an internal tarball source, and for IA/QA reasons we're
> NOT going to refer to any external GIT repos.
>
> Can someone tell me how to just
The idea is that when a recipe build completes, you get not just the
packages from that recipe, but also all packages that are in its recursive
dependencies. So that you can install any package from your recipe, and not
have a broken dependency chain.
Alex
On Wed, 29 Jan 2020 at 12:11, Alexandru
Hi Denys,
Thanks for the clarification.
Would it be accurate to complete your statement about do_build by saying
that "do_build depends on all other normal tasks required to build a
recipe, recursively including those of the build and run-time dependencies
of the recipe being built"?
My
For anyone having some similar issue with the linux-msm please notice
https://source.codeaurora.org/quic/le/meta-qti-bsp/tree/recipes-kernel/linux-msm/linux-msm.inc?id=cbe4d954a9a37dd15e78e3dfdc823ffc6776d746
do_kernel_checkout[noexec] = "1"
This will result in issues if you don't already have a
13 matches
Mail list logo
