I believe so, yes. Any place we refer to "packages" we are talking about the root filesystem. One exception below is LAYERDEPENDS, that one does not impact the root filesystem. -- Darren -- Darren

Mark Hatle said: Mark & everyone else listening: Would you say that (1) the need for a recipe and (2) the requirement to cross-compile are two of the most major usability or learning-curve

Darren, Regarding *DEPENDS.... Right now these variables are documented in the YP Reference Manual. Your email says that the *DEPENDS variables impact the root filesystem. That is sort of vague.

Automotive release cycles are -very- long.. in the 4-5 year development time frame and 10-15 year product support time frame. As I understand it, the Yocto Project does not intend to continue support

Tracey, I think IVI folks will be keen to know we make point releases with bug, security and build fixes - we should see Bernard 1.0.2 and Edison 1.1.1 releases this quarter. Cheers, Joshua --

Hi Sergey, Couple questions: 1. So did you extract your qemuarm rootfs using runquem-extract-sdk to a directory? 2. Point to that directory as sysroot in your Eclipse preference

Each of those packages contains a shell script that is invoked with: #!/usr/bin/env ... Likely the "..." bit is python. Usually busybox or coreutils will provide the /usr/bin/env binary. If your

RPM packages contain more dependency information then ipk and deb packages. This is not a bug, but a feature. When using RPM packages not only are specified dependencies there, but also soname and

For the situation where a recipe is required to build a final image, but the output is not needed in the root filesystem, the EXTRA_IMAGEDEPENDS variable can be used to define this dependency.

Sorry for the short reply, I was being pulled away and couldn't elaborate. I don't see the two issues as being tied together or at least not signifcantly. If two people are debugging a kernel issue,

With which part? That they should be able to use all the available resources? Or that custom kernel messages restrict where they can get help? I don't see how you can really argue against either of

I have no plans to drop this. It's a value add, and simply because not everyone wants it, doesn't mean we let it go. We can carry it and try again if it doesn't make it upstream. I

I we can't get it upstream, I'd argue we drop this. As Paul said, it is cosmetic. When people see this error, the only place they'll find help is here on the yocto list. They should be able to debug

Hello, I've faced the following problem: "VFS: unable to mount root fs via NFS" during staring pre-compiled kernel/rootfs images in quemu. The screen-shot: http://imgur.com/XtvRc I'm trying to start

Works for me as well, I'll update the variant in the yocto kernel trees, while we wait to see if anyone upstream has any interest. Bruce

Hello, I'm trying to build my own image for my own machine configuration ( based on beagleboard ) and get some errors. Please tell me what package is missing? error: Failed dependencies: |

As a bit more information, I found that when I changed to "package_ipk" vs rpm in my local.conf, I was able to do image build and sdk builds without incident. So this problem looks like something

I think that's a reasonable thing to do, yes. -- Darren -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel

I haven't heard more on this. Should I adjust the documents to suggest 2x for both these variables? Scott

Hi, I am looking at the YP Reference manual and the example in this section uses meta/recipes-sato/tasks/task-poky.bb, which doesn’t seem to exist in the Poky tree. Since the example in the