Marek, This might indeed indicate a configuration mismatch. Lots of stuff comes up on Google that you might want to check. One is a change in systemd that affects this. Sorry I don't have a link ready

Hi Kent, Most of these providers provide an IMAP interface as well, such as gmail. Also, in gmail you can tag messages to move into a separate folder for easy delete. For devs and users, the patches a

Hello, What's obvious? There are no package names there, only recipe names that I am aware of. So for the non-obvious packages it still is a bit of guesswork, or the responses in this thread. Regards,

#yocto

Hello Alexander, I have two ideas that might get you closer. 1) First, I noticed that using TOOLCHAIN_HOST_TASK += "xxx" is broken on Yocto dunfell for me (non-extensible SDK). The issue is that even

#sdk

Hello Dave, I copied that error report into Google. Maybe you are hitting a similar case to this? https://www.yoctoproject.org/pipermail/meta-xilinx/2018-January/003638.html Regards, Leon,

Hello Damien, I have this in my local.conf: IMAGE_FSTYPES = "tar ext4" INITRAMFS_FSTYPES = "cpio.xz" It does depend a bit on your image recipes and classes if this works for you. Regards, Leon.

Hello Henrik, As far as I known: - The -dev packages do not end up in target rootfs, unless you specify them in your target image. - The -dev packages end up in the standard SDK target sysroot if you

#yocto #sdk

Hello Aashik, I recognize the issue that CTRL-C does not pass from the console, but only with *very* minimal configurations. How does your local.conf look like, or better yet how can we reproduce your

Hi Aashik, Zoran, Aashik, how are you sending the signal? Using CTRL-C or using the "kill" command? That reads to use sigaction() instead of signal() I would assume. Zoran, are you suggesting that pro

Hello Steven, you mention you use CMake with the Yocto (standard) SDK. After you sourced the SDK environment script, what is the output of "which cmake" ? Do you use the cmake toolchain configuration

#sdk #yocto

Hi all, For a more generic solution, could this be made a weak assignment? I am on a SMARC x86-64 module which only one serial is useful, so I would like to downtune this variable as well. Regards, Le

Hello Robert, <rpjday@...> wrote: Yes, this should be re-worded. This is actually a FAQ. (I remember more sentences like this exist, that especially for non-English speakers might be diffic

Hello Robert, My understanding is that: means "I provide both "libpcre" as well as "pcre". I am assuming that PROVIDES = "${PN}" is already set by a core BitBake rule somewhere. (Didn't check...) So I

My finding is: ...only if *artifacts* (also) includes a rootfs. The image class dependency on rootfs seems very hardcoded. I cannot create a recipe that works without *creating* a rootfs. (even though

<holzmayr@...> wrote: Yes, up to there everything is clean and nice. And I understand I can build multiple images. I have used this feature since 2006. My point is, that we do not su

So let's then consider the case that the WKS is machine specific. I am fine with that. - Does Yocto support building multiple images from one configuration? - (How) can I build multiple WIC images wit

<holzmayr@...> wrote: IMAGE_FSTYPES += "wic" goes in the image recipe, yes. WKS_FILE is there as well for this image, because I need to create multiple images with different WKS's. I

Let me then first describe the issue I am having, which I think results from my misunderstanding then. I would like to package a UEFI bootloader (GRUB), bzImage and initramfs.cpio.gz into an FAT parti

Hello all, What is the intended approach of building images using WIC? Most image types (except .wic) build a (root or initial ram) filesystem from *packages*, then create the respective archive or fi

Hello, We found stressapptest (by Google) the most reliable test for DDR calibration problems. We have seen unreliable systems pass other memory tests such as in U-Boot. Regards, Leon