Re: [yocto] Adding systemd to yocto
On 03/05/2022 11:57, Edgar Mobile wrote: > Apparently, this is not enough: > > bitbake core-image-weston > /usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't > resolve package from __spec__ or __package__, falling back on __name__ > and __path__ > return f(*args, **kwds) > Loading cache: 100% || Time: > 0:00:00 > Loaded 1472 entries from dependency cache. > NOTE: Resolving any missing task queue dependencies > ERROR: Nothing RPROVIDES 'pam' (but > /media/user/SSD1TB/yoctoqemu/poky/meta/recipes-graphics/images/core-image-weston.bb > RDEPENDS on or otherwise requires it) > NOTE: Runtime target 'pam' is unbuildable, removing... > Missing or unbuildable dependency chain was: ['pam'] > ERROR: Required build target 'core-image-weston' has no buildable providers. > Missing or unbuildable dependency chain was: ['core-image-weston', 'pam'] > > These are my current additions to local.conf: > > INIT_MANAGER="systemd" > CORE_IMAGE_EXTRA_INSTALL += " mesa-demos gdb" > IMAGE_INSTALL:append += " pam" pam is a DISTRO_FEATURE as below, not a package as you've added above. > DISTRO_FEATURES:append = " systemd wayland pam x11" > VIRTUAL-RUNTIME_init_manager = "systemd" > DISTRO_FEATURES_BACKFILL_CONSIDERED = > "sysvinit"VIRTUAL-RUNTIME_initscripts = "" > IMAGE_ROOTFS_EXTRA_SPACE = "38048576" > > > > *From:* Scott Murray > *Sent:* Monday, May 2, 2022 2:32 PM > *To:* Edgar Mobile > *Cc:* Joel Winarske ; Yocto-mailing-list > > *Subject:* Re: [yocto] Adding systemd to yocto > > On Mon, 2 May 2022, Edgar Mobile wrote: > >> Ok, correction: I complains about pam missing. > > My apologies, I'd forgotten that wrinkle as we'd been sidestepping it for > a while in AGL with some custom Weston startup. There are a few recipes > in the Weston stuff that explicitly mark pam as a required feature when > using systemd, so you'll also need to have: > > DISTRO_FEATURES:append = " pam" > > Scott > > > > -- Jack Mitchell, Consultant https://www.tuxable.co.uk -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56976): https://lists.yoctoproject.org/g/yocto/message/56976 Mute This Topic: https://lists.yoctoproject.org/mt/90758452/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] thoughts on YP-friendly developer laptop?
- 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 dies. Probably not going to be an issue, I have a 1TB NVMe drive which I've been doing multiple daily builds on for 2 years which is still at 99% health. For a decent manufacturer? Dell aren't recommended at the moment as the QA due to pandemic conditions is lacking and machines are arriving broken. HP do some decent Ryzen based laptops, as do Lenovo. For a wild card you can also check out System76 but they're just OEM rebrands. Good luck, it's a minefield out there. Regards, Jack On 14/06/2021 12:58, Robert P. J. Day wrote: > > starting to think about a new laptop that will, among other things, > do lots of OE/YP builds, and i'll start with this as the basis for a > few questions about hard drives: > > https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e > > while an SSD would be delightful, i'm concerned about how doing > frequent 40-50G builds would wear out an SSD. so i was considering > looking for something with a fast regular HD for the actual build > directories, but room to put in an M.2 NVMe that would hold fairly > static content, like the OS itself, all the layers, a local source > mirror and so on. > > am i overthinking this? anyone have a laptop setup that is smokin' > fast (yeah, 8 core AMD ryzen :-), and a dual drive layout that seems > to work well with lots and lots of OE builds? > > rday > > > > > -- Jack Mitchell, Consultant https://www.tuxable.co.uk -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53860): https://lists.yoctoproject.org/g/yocto/message/53860 Mute This Topic: https://lists.yoctoproject.org/mt/83528013/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in an official "meta-rubygems" layer?
On 27/01/2021 09:17, Jack Mitchell wrote: > On 27/01/2021 09:09, Robert P. J. Day wrote: >> On Wed, 27 Jan 2021, Jack Mitchell wrote: >> ... snip ... >> >>> 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 to have a >>> central place to contribute Ruby/RubyGems improvements. As you have >>> found there are many layers with spotty Ruby support and a >>> particular copy of an old class that is being banded about which is >>> often insufficient. >> >> cool ... care to share your rubygems.bbclass file? be great to >> combine the best of both worlds. >> >> rday >> > > 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. > > Cheers, > Jack. > > and a short example of how it's used > cat recipes-devtools/ruby/ruby-pqueue_2.1.0.bb inherit rubygems LICENSE = "BSD-2-Clause" LIC_FILES_CHKSUM = "file://License.txt;md5=8f085d0bb9ef0d1705dc5fd61aaaffa1" SRC_URI[sha256sum] = "8b79d9baa303a9747e83877def5a698e0e61d145d4c4275487c79fb1642102a9" -- Jack Mitchell, Consultant https://www.tuxable.co.uk -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52112): https://lists.yoctoproject.org/g/yocto/message/52112 Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in an official "meta-rubygems" layer?
On 27/01/2021 09:09, Robert P. J. Day wrote:
> On Wed, 27 Jan 2021, Jack Mitchell wrote:
> ... snip ...
>
>> 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 to have a
>> central place to contribute Ruby/RubyGems improvements. As you have
>> found there are many layers with spotty Ruby support and a
>> particular copy of an old class that is being banded about which is
>> often insufficient.
>
> cool ... care to share your rubygems.bbclass file? be great to
> combine the best of both worlds.
>
> rday
>
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.
Cheers,
Jack.
--
Jack Mitchell, Consultant
https://www.tuxable.co.uk
def get_rubygemsversion(p):
import re
from os.path import isfile
import subprocess
found_version = "SOMETHING FAILED!"
cmd = "%s/gem" % p
if not isfile(cmd):
return found_version
version = subprocess.Popen([cmd, "env", "gemdir"],
stdout=subprocess.PIPE).communicate()[0]
r = re.compile(".*([0-9]+\.[0-9]+\.[0-9]+)$")
m = r.match(version.decode("utf-8"))
if m:
found_version = m.group(1)
return found_version
RUBY_GEM_VERSION ?= "${@get_rubygemsversion("${STAGING_BINDIR_NATIVE}")}"
def rubygems_gem(d):
bpn = d.getVar('BPN')
if bpn.startswith('ruby-'):
return bpn[5:]
return bpn
RUBYGEMS_GEM_NAME ?= "${@rubygems_gem(d)}"
RUBYGEMS_GEM_EXT ?= "gem"
RUBYGEMS_GEM ?= "${RUBYGEMS_GEM_NAME}-${PV}.${RUBYGEMS_GEM_EXT}"
def rubygems_src_uri(d):
package = d.getVar('RUBYGEMS_GEM_NAME')
package_ext = d.getVar('RUBYGEMS_GEM_EXT')
pv = d.getVar('PV')
return 'https://rubygems.org/downloads/%s-%s.%s' % (package, pv,
package_ext)
RUBYGEMS_SRC_URI ?= "${@rubygems_src_uri(d)}"
HOMEPAGE ?= "https://rubygems.org/gems/${RUBYGEMS_GEM_NAME};
SRC_URI += "${RUBYGEMS_SRC_URI}"
S = "${WORKDIR}/${RUBYGEMS_GEM_NAME}-${PV}"
DEPENDS += " \
ruby-native \
"
RDEPENDS_${PN} += " \
ruby \
"
rubygems_do_compile() {
:
}
do_unpack[depends] += "ruby-native:do_populate_sysroot"
rubygems_do_unpack() {
gem unpack --target ${WORKDIR} ${DL_DIR}/${RUBYGEMS_GEM}
}
RUBY_GEM_DIR="${libdir}/ruby/gems/${RUBY_GEM_VERSION}"
GEM_DEST="${D}/${RUBY_GEM_DIR}"
rubygems_do_install() {
gem install --ignore-dependencies --local --env-shebang --install-dir
${GEM_DEST}/ ${DL_DIR}/${RUBYGEMS_GEM}
rm -rf ${GEM_DEST}/cache
}
FILES_${PN}-doc = "${RUBY_GEM_DIR}/doc"
FILES_${PN} = "${RUBY_GEM_DIR}"
EXPORT_FUNCTIONS do_unpack do_compile do_install
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52111): https://lists.yoctoproject.org/g/yocto/message/52111
Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in an official "meta-rubygems" layer?
On 27/01/2021 06:33, Robert P. J. Day wrote: > > since it appears that i will be diving head-first into messing with > ruby in some current YP builds, is there any interest in creating a > meta-rubygems layer to start collecting recipes based on what konrad > weihmann has done in his meta-sca layer here? > > https://github.com/priv-kweihmann/meta-sca > > i've been swapping emails with konrad over the last few days and, > first, it seems clear that it's not appropriate to start dumping > general ruby recipes into meta-sca as that layer is clearly defined as > being for "static code analysis and security hardening", so a new, > more general layer is obviously more appropriate. > > also, konrad focuses on using his own "rubygems.bbclass" class file: > > https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass > > to define recipes that pull from rubygems.org exclusively, and he > agrees that it would keep things simpler to stick with that model; > hence, the proposal of the layer name "meta-rubygems" and not just > "meta-ruby". > > konrad already offered to do the maintenance of such a new layer, as > long as there is standard infrastructure support for testing, that > sort of thing. and i'm sure that would make his meta-sca layer simpler > as all the more generic rubygems-based recipes could be moved into the > meta-rubygems layer, leaving his meta-sca layer to focus exclusively > on the code analysis and security recipes, however he wants to do > that. > > thoughts? it seems that a new layer could be populated almost > instantly with a large chunk of meta-sca, and we could take it from > there. > > rday > 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 to have a central place to contribute Ruby/RubyGems improvements. As you have found there are many layers with spotty Ruby support and a particular copy of an old class that is being banded about which is often insufficient. Regards, Jack. -- Jack Mitchell, Consultant https://www.tuxable.co.uk -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52106): https://lists.yoctoproject.org/g/yocto/message/52106 Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] RFC: Changes to meta-kernel layer
On 17/09/2020 10:40, Bas Mevissen wrote: > On 2020-09-17 10:43, Paul Barker wrote: > >> Hi folks, >> >> After a bit of a break I'm looking again at the meta-kernel layer and >> I've got some changes planned. I'd like to get some feedback on these >> from anyone who has looked at or used the meta-kernel layer. >> >> 1) Change the name to meta-vanilla-kernel. This reflects the focus on >> providing a fast moving layer for vanilla kernel recipes, covering >> only what is available on kernel.org. Other common kernel recipes >> (e.g. Linaro or Android common kernels) will no longer be considered >> for acceptance into this layer. This clear focus should hopefully >> reduce some of the confusion about the goals of this layer. >> > > I would suggest calling it something like meta-kernel.org then. Naming > something "vanilla" might cause confusion as well. 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-kernel but I'm not so keen on that. Vanilla is a confusing term for people not in the game and you know at some point there will be a "vanilla-pi" or "vanilla" board where you're going to hit confusion. As an aside I saw no issues with meta-kernel as it's _the_ Linux kernel from _the_ Linux kernel git repositories. Confusion due to doublespeak from downstream kernel vendors should be corrected and not adhered to. > >> 2) The dunfell branch will no longer get new non-LTS kernel recipes. >> Providing non-LTS recipes on a stable branch has led to people >> depending on kernels which are now out of their support period - I'd >> like to drop the recipes for the 5.3.y and 5.6.y kernels but users are >> depending on them so I'll have to keep them. To avoid this >> proliferating, only LTS kernels and the bleeding edge mainline recipe >> will be updated on the stable branch from now >> >> 3) Aggressively drop end-of-life kernels on the master branch. >> >> 4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is >> created. >> I think these are fair, I can't speak for how other people are using the layer but I would imagine as with most embedded boards, they're using the tooling rather than the plain upstream recipes and the real value is in catching problems with -next kernel compilation early and the fixes/features pushed back to kernel.bbclass. >> 5) Document the test coverage for meta-kernel. We don't test perf, >> lttng or any out-of-tree modules. This layer isn't meant to replace >> the linux-yocto recipes, the goals are different. If you're releasing >> products based on meta-kernel you obviously need to do your own >> testing on the components you're actually using. I wouldn't be expecting anything more than basic build and boot on qemu to be fair. Again, IMO the value of this is in the toolchain test and tooling. >> >> 6) Document the policy for kernel patches. Patches for the kernel will >> only be carried in this layer as a last resort. Kernel patches should >> be submitted upstream and go through the usual process for inclusion >> in the stable kernel releases. Compilation patches only I would say. >> >> 7) Disable GitLab CI for this layer. It's costing me about £70 per >> month to run CI for this layer and I need to eliminate that expense. >> If anyone can sponsor this or host the CI service that would be welcome. >> >> 8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers >> to reduce the bus factor for the layer. I'll continue to be the >> primary maintainer for this layer but this will give some coverage if >> I'm unable to continue working on it. >> >> Thanks, >> >> -- >> >> Paul Barker >> Konsulko Group >> Cheers, Jack. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50708): https://lists.yoctoproject.org/g/yocto/message/50708 Mute This Topic: https://lists.yoctoproject.org/mt/76905426/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
