It was definitely an architecture mismatch. I checked the architecture of the files with objdump. That is what threw me off in the first place. I simply checked the versions. They were off but I could

Thanks, Richard. I was sidetracked by other stuff, hence the delay. Please see below. That's the objdump on libc.so.6 on the target (aarch64, Honister): Version definitions: 1 0x01 0x0865f4e6 libc.so.

It's Yocto that creates the spec file for rpm. Apparently, besides relying on what is declared in RDEPENDS, it actually iterates over the files and appends the dependencies (and their versions). It re

Yes, thank you. ERROR: xxx-single-group-0.1-r0 do_package_qa: QA Issue: /opt/binstuf/linux-allwinneryocto-armle-opengles_2.0-obj/lib/libfbxsdk.so contained in package xxx-single-group requires libpthr

Not exactly as is because of customer names, but below is a sanitized version: SUMMARY = "Binary Stuff" LICENSE = "CLOSED" SRC_URI = "file://binary_installer.tgz \ " do_install() { install -d -m 0755

I have been handed a binary package that I am integrating into a Yocto build. When dnf runs it complains about missing dependencies. These are standard libraries of course but the culprit is the incom

Hello, Topposting since the problem is in the screenshot. The issue is the naming of the shared object. Linux convention is that a shared object contains the version number e.g. log_wrapper.so.1 and l

Thanks, Khem. The image class defines IMAGE_CMD. There is not much to it for now: OTA_ROOTFS_MD5 ?= "rootfs.md5" IMAGE_CMD:ota () { build_ota="${WORKDIR}/build-ota" # rootfs md5sum ${IMAGE_ROOTFS} > $

I ran into a problem with a custom image type class. I called the class image_types_ota.bbclass. When I try to use it I am getting these error messages for two predefined image recipes (but only for t

Thanks, Khem. I sent a patch to OE.

I got a question about the linux-firmware-bcm4373 package. The link /lib/firmware/brcm/brcmfmac4373-sdio.clm_blob -> ../cypress/cyfmac4373-sdio.clm_blob is packaged into linux-firmware and not into li

Hi JH, This would typically mean that you are actually connected to a wifi network but the interface did not receive a DHCP lease for the IP address. the 169.254. is local IPv4 IP address which the in

Hi JH, Yes, I have, but with Network Manager instead of connman. WiFi works just fine. There are a lot of pieces in the chain and it is not obvious from your description where it is broken. If you run

A not so well-known feature of the WIC bootimg-partition plugin is that it can install files into different partitions. For that the variable IMAGE_BOOT_FILES has to be defined as one of the following

What does your 'Hello World' service do? Just print 'Hello World' to the console and then exit? If so that would be the reason why it is inactive. Systemd starts it and then it exits. Typically, servi

#yocto

Not that I know of. Why anyway?

Preferred method for local configuration is using /etc/systemd/network. However, the probable reason why it did not work is that the file should be eth0.network. The name of the file(s) do not matter

Create the file /etc/systemd/network/eth0.conf: [Match] Name=eth0 [Network] Address=<ip> Gateway=<ip> DNS=<ip> Restart systemd-networkd # systemctl restart systemd-networkd or reboot. :rjs

What is your startup manager? systemd or SysVInit?

Hi there, That depends on whether or not you are using a network manager and if so which one. You haven't told us much about your board and it's network interfaces and how you built your system. To st