Hello all, What is the preferred way of overriding an existing class in the 'meta' layer. I tried to add the existing class (say image_types.bbclass) to my custom layer and did some modifications to

It's queued with the rest of my 3.0 updates. I've been spending time on 3.2 and haven't pushed these out yet. Bruce

This is definitely fixed in the meta update I sent today, the "patch.patch" is completely removed. So you'll have to wait for my request to be merged, or cherry pick the change. Bruce

I am building from master branch. Below is the error I see. ERROR: Function failed: do_patch (see

I don't see this in the repository yet, is it still pending? I'm trying to write a BSP that is dependent on it. Thanks, Darren -- Darren Hart Intel Open Source Technology Center Yocto Project -

<bruce.ashfield@...> wrote: Ah, you nailed it! Once I pushed my changes to yocto/standard/beagleboard, the build system picked up my changes. That is the step I hosed up. It is working now

The 3.0 pull request was held up behind 3.2 work. But I just pushed out a meta branch update that contained: commit f1ef128bff854ce2614e655283ecca92d22f0b88 Author: Bruce Ashfield

Hi Bruce, Could you please let me know if the fix is available for this? Thanks Kishore.

From my experience, this is true. Regardless of the SRCI_URI, the downloads directory contains everything that poky/bitbake need to do builds after the initial fetch has been performed. And

What kind of errors? Some details might help understand what the problem is. I think so, but I'm not 100% sure. The way I have my system set up, I never download anything more than once :-) I have

I'm not sure it does. I don't want poky to do more work. I have my download directory, $DL_DIR, outside my build directory so I can keep it run to run, as mentioned in the comments in local.conf. I

Queued. Bruce

The beagle board would be building on the branch listed in the meta-yocto layer. KMACHINE_beagleboard = "yocto/standard/beagleboard" Everything that you've done is fine, but pushing your changes

OK, hate to bring this up again but I must be doing something wrong. My kernel changes don't appear to be getting picked up. I thought it was OK before but then I did some real work on the kernel and

If you set BB_GENERATE_MIRROR_TARBALLS = "1" (e.g. in local.conf) then you'll get tarballs which hold the git repositories after download. You can then reuse these (by sharing the DL_DIR or using a

I have used both git and the tarball methods of bitbaking projects, all of them derivatives of the examples in the Yocto documentation. I was having issues using the local clone of the Yocto kernel

nothing is broken. Its the mono package which uses older version of libtool (pre 2.4) and its trying to link in .la files which are generated by new libtool 2.4+ your best option is that add the mono

Hi Mark! I set up the custom layer following your suggestions and it's building now... By inspecting the logs I see "-march=i486" applied to compiler's command lines. I won't be able to test the

Agenda   * Opens collection - 5 min (Song) * Yocto 1.1.1 point release update - 10 min (Josh/Beth) * Yocto 1.2 M2 status, M3 planning status - 10 min

Jim Abernathy Looks good to me.