All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on

Hello all, This is the full report for yocto-3.2_M3.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== Beaglebone

From: "Mah, Yock Gen" <yock.gen.mah@...> Signed-off-by: Mah, Yock Gen <yock.gen.mah@...> --- classes/zephyr-kernel-src.bbclass | 16 ++++++--- .../{qemu_4.2.%.bbappend =>

Hi Greg, .so files are installed in the -dev package even with the line above. Please have a look here:

Yocto project supports sysvinit as init system option as well so no there are no leftovers. Usually you use socket activation for sshd then you would enable sshd.socket and not sshd.service, socket

it seems you want to bundle unstalled packages ( rpms ) in your firmware, perhaps you can look at adding a ROOTFS_POSTPROCESS_COMMAND and copy the needed packages, but you need to be sure that all

You could try with PROVIDES:https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PROVIDES -- Maciej PijanowskiEmbedded Systems EngineerGPG:

URLs no longer point to a valid location. Update to the current location. Signed-off-by: Jon Mason <jon.mason@...> --- classes/zephyr-kernel-src.bbclass | 2 +-

Zephyr refuses to compile due to missing python dependencies. Signed-off-by: Jon Mason <jon.mason@...> Signed-off-by: Ross Burton <ross.burton@...> ---

I have a custom recipe that copies a .so, that libMotors.so calls functions in another libcanfestival.so. When I first added in the copy of the .so I didn't have an RDEPENDS and Yocto printed out an

Add DEPENDS += "libzip" in failing recipe ( .bb) file. On Mon, Sep 21, 2020 at 12:40 AM Jaymin Dabhi via lists.yoctoproject.org <jaymin.dabhi=vivaldi.net@...> wrote:

Hi Mike, Could you send your tailscale recipe to meta-openembedded/meta-networking? Email: OpenEmbedded Development mailing list <openembedded-devel@...>

Seems strange to me too...I had been troubleshooting the sshd.service issue for two days. There was no logs, nothing. I was just hitting the wall. I tried a lot of combinations to get it to work but

Interesting... Pushed/forced me to think. There is no formal dependency between sshd.service and sshd.socket! [vuser@fedora32-ssd systemd]$ systemctl list-dependencies sshd.service | grep

Thanks. I figured that was the case. This is testing on the AB.

This enables it for both x86_64-mingw32 and i686-mingw32 targets and it makes sense since it's not about the target bitness but the mingw implementation. w64 has support for both targets and provides

Does this enable it for the i686 toolchain also? Does that make sense?

Not sure about that. The problem I faced was because there was a sshd.socket that had the following line in it. The sshd.socket comes with openssh. Conflicts=sshd.service So I had two options.

Are you trying to use it with openssl-1.0.*? Either use openssl-1.1 or revert the changes from https://github.com/apenwarr/wvstreams/pull/2/commits.

Hi, I was messing around with wvdial & wvstream for a while. Now the patches are at the correct locations, but still there is a compile error: Here is the error