Post/* all ( except Post/migrations/* , __init__.py and templatetags/* ) have some sort of MIT headers; adding SPDX header to make it obvious. project/* & test-data/* all ( except __init__.py ) have

Images are supposed to be all custom. It means if you cannot easily use one of the existing images, you create your own. There are ways to bbappend an existing image and mangle its content, but it's

was able to modify the vendor's machine/inc file to remove the offending package. Since the whole tree is in git now, I suppose that's OK, but I do wish yocto had better tools for managing inclusions

On 2/11/20 11:16 AM, rpjday@... wrote: Wrong ML. We have a docs@... with patchwork support. - armin

Minor fixes: - punctuation - capitalization - markup - wording Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git

You need to modify the image recipe so that those packagegroups are not pulled in. If you cannot do that because it's in a layer controlled by someone else etc, then make a new image recipe, and build

My vendor finally realized that I needed a full yocto release and not the eSDK. Anyway, I can build their image, but when I modify the kernel to remove CAN drivers I get the errors

From: Sergey 'Jin' Bostandzhyan <jin@...> Currently machine configs define the partition layout for each machine by setting the WKS_FILE variable. However, there are situations where it may

From: Sergey 'Jin' Bostandzhyan <jin@...> Currently machine configs define the partition layout for each machine by setting the WKS_FILE variable. However, there are situations where it may

Current Dev Position: YP 3.1 M3 Next Deadline: YP 3.1 M3 build date 2/24/2020 Next Team Meetings: Bug Triage meeting Thursday Feb. 13th at 7:30am PDT (https://zoom.us/j/454367603) Monthly

from the overview manual, section 2.5, "Reference Embedded Distribution (Poky)", there is the note: "While Poky is a "complete" distribution specification and is tested and put through QA, you cannot

Ah gotcha. My docbook-fu is somewhat hazy. Yes, seems sensible. Ross

but that's not the way it's normally used ... <firstterm> doesn't necessarily mean the physically first time a term is used, it's more typically used to identify where the term is formally

My problem with <firstterm> is that you need to keep on reviewing to verify it is the first usage. Better to post-process that, surely. Ross

yes, that's along the lines of using <firstterm> when appropriate. i'm not suggesting trying to dig into every corner of docbook, just the judicious usage of the most obvious tags. i'll do some

oh, i wasn't suggesting any sort of massive cleanup; i just wanted to make sure i was explaining it properly to any potential students to make sure they appreciated corner cases like this. rday

I think the original intent was that bitbake.conf defines the basic PROVIDES/DEPENDS and then the recipes adjust as needed. As such, PROVIDES and DEPENDS would then always use +=. Unfortunately over

<rpjday@...> wrote: I'd say fine, patches welcome. Maybe Scott chose a subset of Docbook to ease the formatting? Either way, I can't see a good argument *against* using a broader set of

with the recent loss of scott rifenbark, since i used to be fairly active in working on the docs, i figure it's time to get off my a** and get involved again and contribute. to that end, i once made

Hey, I’m debugging a issue in the sdcard generation recipe of a NXP provided class (image_types_fsl). So I’m only interested in their workings of the do_image_sdcard step, however yocto