pam is a DISTRO_FEATURE as below, not a package as you've added above.

- Ryzen based for core count - No dedicated GPU as more wattage available for CPU + less heat for cpu boosting - Dual NVMe slots, or at least on-board emmc + NVMe slot, hold tmp in NVMe, replace if it

and a short example of how it's used inherit rubygems LICENSE = "BSD-2-Clause" LIC_FILES_CHKSUM = "file://License.txt;md5=8f085d0bb9ef0d1705dc5fd61aaaffa1" SRC_URI[sha256sum] = "8b79d9baa303a9747e8387

Please find attached, it's basically the old ruby class with only support for pure RubyGems (i.e. no cross-compiling) with some influence from the pypi class for grabbing and compiling a SRC_URI. Chee

Hi Robert, This is something I would be interested in. I have a developed a much more basic rubygems class privately which I had intended to opensource and create a similar later, so it would be nice

I wasn't going to be blamed for the bike shedding of this but as we've gotten started I'll stick my oar in. My suggestion would be meta-mainline-kernel, meta-linux-kernel or potentially meta-upstream-

There is also already a recipe for libsoc in meta-oe. http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/libsoc/libsoc_0.8.2.bb?h=master Regards, Jack.

I have a small layer I use for booting mainline components on the tinker, so i can confirm that works with current upstream. https://github.com/jackmitch/meta-tinker

An issue with not having separate recipes is going to cause problems with OTA package updates. I currently have a node package that I maintain for a client and it's so big (excess of 30,000 files with

Someone has already started having a go. https://github.com/watatuki/meta-jetson-tx1 Easiest way to check for support in OE is to google meta + devboard name. Usually turns something up :) Cheers, Jac