OK, let me take a stab at this. base image: The image recipe to build, this defines the content of the image such as which packages are installed. For example: core-image-minimal core-image-base

I'll try to explain: Your answer to my question was that we should allow outputting live images when building qemu machines because it could be useful to run those live images in the emulator, but

Hi Kai, I have a question about the image-writer and I was wondering if you could help. We are working on the Hob screen we will display after finishing a build. If the build creates a live image

You suggested that this had a significant impact on the dialog for selecting images. I thought knowing that qemu+live should/will be a support situation would prevent you having to redesign the dialog

Thanks for clarifying this, Darren. I think right now we need to design for what the current emulator can do. When things change, we should remember to update

With the current implementation of the runqemu command and the current configuration of the qemu hardware, this is true. However, this will change in the future as people have run into this and asked

Hi Juergen, The -c argument specifies a specific task you want bitbake to execute, it accepts values from the listtasks command, compile is one of them. The -f argument forces the task to execute

Sorry, Darren and Liming: I have one more question about this. Liming, correct me if I am wrong, but you mentioned that the only files that can be run on the qemu emulator are ext2 and ext3. But

The reorganization of bugzilla has been refined and the new layout is available for preview at https://bugzilla.yoctodev.org/. After a quick review I plan to make this change live on production.

as i claw my way through the QEMU stuff in yocto, some pedantic thoughts on how to make the shell scripts more readable, so more observations from the "runqemu" script. * all those multiple "echo"

Thanks Darren and Liming. It sounds like we should keep things as they are, and that we'll need a screen that gives you options to both run and deploy an image when you have built for qemu selecting

Dear Darren You suggested in Bug 2256 the following: $ bitbake virtual/kernel -c cleansstate $ bitbake virtual/kernel -c menuconfig $ bitbake virtual/kernel -c compile -f; bitbake

Frans Meulenbroeks wrote: The idea is that the top level run-all script looks in the /opt/ptest directory and runs all package tests that are installed there. It has no built-in knowledge of any

Tomas Frydrych <tf+lists.yocto@...> a écrit : FWIW, Busybox comes with its own implementation of a very simple and basic init, which only takes a few KB of space inside the Busybox binary.

Hi Darren, I think you really should quantify what 'all of init' means, without this you are addressing a problem that is merely perceived. Just a quick look shows that the sysvinit package is about

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 set DPKG_ARCH = "armel" in your local.conf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla -

Hi, There should be no GL on RPI at all, the HW drivers only support GLES/2, so the short answer is you can't pull in packages that require GL (in theory you could build mesa with the software

From: Tom Zanussi <tom.zanussi@...> emenlow needs to use the old 1.10.2 cairo library instead of the upgraded version. Fixes [YOCTO #2507] Signed-off-by: Tom Zanussi

From: Tom Zanussi <tom.zanussi@...> The emenlow graphics stack doesn't work with the cairo_1.12.2 library upgrade; this adds the old 1.10.2 recipe from poky locally to the emenlow layer in

From: Tom Zanussi <tom.zanussi@...> The recent upgrade of cairo to 1.12.2 broke meta-emenlow; keeping the old 1.10.2 recipe around in the meta-emenlow layer gets it working again. The