|
Adding systemd to yocto
Line 30-36 include changes to convert a sysvinit image to systemd. https://github.com/jwinarske/manifests/blob/honister/conf/rpi64_config#L30
Line 30-36 include changes to convert a sysvinit image to systemd. https://github.com/jwinarske/manifests/blob/honister/conf/rpi64_config#L30
|
By
Joel Winarske
· #56950
·
|
|
NPM support on Dunfell
The takeaways using inherit npm: 1. Does not support 'scoped packages' 2. fetching is not multi-threaded. A NPM based recipe will run uni-proc with a considerable amount of overhead; each package is p
The takeaways using inherit npm: 1. Does not support 'scoped packages' 2. fetching is not multi-threaded. A NPM based recipe will run uni-proc with a considerable amount of overhead; each package is p
|
By
Joel Winarske
· #56804
·
|
|
NPM support on Dunfell
I'm seeing some gaps and performance issues. Examples: 1. Setting NPM_INSTALL_DEV = "1" I am rewarded with: 169npm ERR! Could not install from "../../__w/meta-flutter/rpi4-drm-dunfell-latest/raspberry
I'm seeing some gaps and performance issues. Examples: 1. Setting NPM_INSTALL_DEV = "1" I am rewarded with: 169npm ERR! Could not install from "../../__w/meta-flutter/rpi4-drm-dunfell-latest/raspberry
|
By
Joel Winarske
· #56737
·
|
|
Google GN support
I had to revisit this for Google Flutter LTS support as upstream (Google Flutter team) wasn't interested in providing tar.xz releases. We have two working solutions for Flutter gclient as of today. 1.
I had to revisit this for Google Flutter LTS support as upstream (Google Flutter team) wasn't interested in providing tar.xz releases. We have two working solutions for Flutter gclient as of today. 1.
|
By
Joel Winarske
· #56413
·
|
|
[dunfell] hidden files/folders in WORKDIR
I'm finding that if I create files/folders (prefixed with '.') in WORKDIR, they don't get cleaned up with INHERIT += "rm_work". Is this a feature or a bug?
I'm finding that if I create files/folders (prefixed with '.') in WORKDIR, they don't get cleaned up with INHERIT += "rm_work". Is this a feature or a bug?
|
By
Joel Winarske
· #55595
·
|
|
raspberrypi0-2w
https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi0-2w-64.conf
https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi0-2w-64.conf
|
By
Joel Winarske
· #55468
·
|
|
Building -native with clang
Thanks, I'll check it out. This works: DEPENDS += "\ compiler-rt \ libcxx \ llvm \ " RUNTIME = "llvm" TOOLCHAIN = "clang" PREFERRED_PROVIDER:libgcc = "compiler-rt" RUNTIME:class-native = "llvm" TOOLCH
Thanks, I'll check it out. This works: DEPENDS += "\ compiler-rt \ libcxx \ llvm \ " RUNTIME = "llvm" TOOLCHAIN = "clang" PREFERRED_PROVIDER:libgcc = "compiler-rt" RUNTIME:class-native = "llvm" TOOLCH
|
By
Joel Winarske
· #55365
·
|
|
Building -native with clang
How do I get a -native recipe to use clang-native? I have this in my recipe, and target variant builds with clang: RUNTIME = "llvm" TOOLCHAIN = "clang" PREFERRED_PROVIDER:libgcc = "compiler-rt" All th
How do I get a -native recipe to use clang-native? I have this in my recipe, and target variant builds with clang: RUNTIME = "llvm" TOOLCHAIN = "clang" PREFERRED_PROVIDER:libgcc = "compiler-rt" All th
|
By
Joel Winarske
· #55362
·
|
|
pre-built native only tool for native and nativesdk
My solution was to use recipe name without `-native`, and simply use empty packages (no-op) for target. Only nativesdk- and -native variants have an affect. Then add `TOOLCHAIN_HOST_TASK:append = " na
My solution was to use recipe name without `-native`, and simply use empty packages (no-op) for target. Only nativesdk- and -native variants have an affect. Then add `TOOLCHAIN_HOST_TASK:append = " na
|
By
Joel Winarske
· #55298
·
|
|
pre-built native only tool for native and nativesdk
Actually by removing `inherit native` and adding -native to the recipe name doesn't make it build for native.
Actually by removing `inherit native` and adding -native to the recipe name doesn't make it build for native.
|
By
Joel Winarske
· #55296
·
|
|
pre-built native only tool for native and nativesdk
To eliminate target option from the recipe I just need to make sure the name of the recipe ends with -native, then removing inherit native works fine.
To eliminate target option from the recipe I just need to make sure the name of the recipe ends with -native, then removing inherit native works fine.
|
By
Joel Winarske
· #55295
·
|
|
pre-built native only tool for native and nativesdk
I'm trying to sort out how to install a pre-built host-only tool for native and nativesdk only. Using `inherit native` my-recipe-native and nativesdk-my-recipe both build fine, only -c populate_sdk ge
I'm trying to sort out how to install a pre-built host-only tool for native and nativesdk only. Using `inherit native` my-recipe-native and nativesdk-my-recipe both build fine, only -c populate_sdk ge
|
By
Joel Winarske
· #55293
·
|
|
virtual/egl on Raspberry Pi 4
Hi Greg, Do you have this in your local.conf? DISTRO_FEATURES_append = " opengl"
Hi Greg, Do you have this in your local.conf? DISTRO_FEATURES_append = " opengl"
|
By
Joel Winarske
· #54978
·
|
|
Google GN support
> look at meta-browser/meta-chromium as well. The download archive (tar.xz) approach may be the easiest solution. Then one would just need to make a versioned recipe for each LTS. Thanks Khem!
> look at meta-browser/meta-chromium as well. The download archive (tar.xz) approach may be the easiest solution. Then one would just need to make a versioned recipe for each LTS. Thanks Khem!
|
By
Joel Winarske
· #54974
·
|
|
Google GN support
I'm looking into best practice LTS support for Google GN based projects. This includes Chromium, Flutter, SKIA, etc. The weakness I see today for GN projects is that it's a build system within a build
I'm looking into best practice LTS support for Google GN based projects. This includes Chromium, Flutter, SKIA, etc. The weakness I see today for GN projects is that it's a build system within a build
|
By
Joel Winarske
· #54971
·
|
|
[poky][master][PATCH} VirGL: depends on virtual/gbm
It looks like a Mesa dependency is looming for NVIDIA: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902 Thanks
It looks like a Mesa dependency is looming for NVIDIA: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902 Thanks
|
By
Joel Winarske
· #53697
·
|
|
[poky][master][PATCH} VirGL: depends on virtual/gbm
This addresses cases where the platform doesn't depend on Mesa. Tegra is one example. From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001 From: Joel Winarske <joel.winarske@...
This addresses cases where the platform doesn't depend on Mesa. Tegra is one example. From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001 From: Joel Winarske <joel.winarske@...
|
By
Joel Winarske
· #53695
·
|
|
Problem with YOCTO Dunfell and host Fedora 33
Hi Zoran, Your cannelloni recipe is set to autorev, meaning it's not locked to a commit. So when something changes upstream you have to manage it. Chances are Canelloni introduced a CMake change which
Hi Zoran, Your cannelloni recipe is set to autorev, meaning it's not locked to a commit. So when something changes upstream you have to manage it. Chances are Canelloni introduced a CMake change which
|
By
Joel Winarske
· #53606
·
|
|
project that builds target and host
Yeah i don't want to disable stripping the Target files. Well actually, I'll take a look at patching the tree with a custom CMakeLists.txt file. It may not be that bad. Thanks Ross
Yeah i don't want to disable stripping the Target files. Well actually, I'll take a look at patching the tree with a custom CMakeLists.txt file. It may not be that bad. Thanks Ross
|
By
Joel Winarske
· #49405
·
|
|
project that builds target and host
What are some nasty hack options? The major surgery would be less maintainable.
What are some nasty hack options? The major surgery would be less maintainable.
|
By
Joel Winarske
· #49403
·
|