|
should all "IMAGE_INSTALL +=" become "IMAGE_INSTALL_append"?
yes, i see your point now. rday
yes, i see your point now. rday
|
By
Robert P. J. Day
· #48403
·
|
|
should all "IMAGE_INSTALL +=" become "IMAGE_INSTALL_append"?
no, section 3.2.1 in current git version of YP development tasks manual. that manual doesn't even have a section 5. we better make sure we're looking at the same manual. rday
no, section 3.2.1 in current git version of YP development tasks manual. that manual doesn't even have a section 5. we better make sure we're looking at the same manual. rday
|
By
Robert P. J. Day
· #48401
·
|
|
should all "IMAGE_INSTALL +=" become "IMAGE_INSTALL_append"?
again, some nitpickiness, but in the current YP dev manual, section 3.2.1, the manual is quite explicit about using "_append" with IMAGE_INSTALL: "Furthermore, you must use _append instead of the += o
again, some nitpickiness, but in the current YP dev manual, section 3.2.1, the manual is quite explicit about using "_append" with IMAGE_INSTALL: "Furthermore, you must use _append instead of the += o
|
By
Robert P. J. Day
· #48398
·
|
|
[PATCH] dev-manual: layer priority takes precedence over PV
Clarify that if there are multiple recipes with the same name, the recipe with the highest PV from the highest priority layer will be the one selected. Signed-off-by: Robert P. J. Day <rpjday@crashcou
Clarify that if there are multiple recipes with the same name, the recipe with the highest PV from the highest priority layer will be the one selected. Signed-off-by: Robert P. J. Day <rpjday@crashcou
|
By
Robert P. J. Day
· #48397
·
|
|
dev-manual: differing versions of same recipe in different priority layers?
i'm betting i'm going to find all of them eventually. :-) right ... higher layer priority takes precedence over higher version number. i'll submit something for that. rday
i'm betting i'm going to find all of them eventually. :-) right ... higher layer priority takes precedence over higher version number. i'll submit something for that. rday
|
By
Robert P. J. Day
· #48394
·
|
|
dev-manual: differing versions of same recipe in different priority layers?
in the YP dev manual, section 3.1.6, there is a maddeningly vague note: "It is possible for a recipe with a lower version number PV in a layer that has a higher priority to take precedence." so does i
in the YP dev manual, section 3.1.6, there is a maddeningly vague note: "It is possible for a recipe with a lower version number PV in a layer that has a higher priority to take precedence." so does i
|
By
Robert P. J. Day
· #48391
·
|
|
[PATCH] dev-manual: chs 1,2; rewording, cleanup
Also removal of way too much unnecessary capitalization. Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manu
Also removal of way too much unnecessary capitalization. Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/documentation/dev-manual/dev-manual-intro.xml b/documentation/dev-manu
|
By
Robert P. J. Day
· #48390
·
|
|
[PATCH] overview-manual: minor editing, rendering, wording changes
Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/documentation/overview-manual/overview-manual-concepts.xml b/documentation/overview-manual/overview-manual-concepts.xml index f
Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/documentation/overview-manual/overview-manual-concepts.xml b/documentation/overview-manual/overview-manual-concepts.xml index f
|
By
Robert P. J. Day
· #48388
·
|
|
reviving an old suggestion about YP docs markup
heh ... i remember it took me a few reads once upon a time to finally grok the proper usage of a lot of docbook markup. in any event, i'm not pushing for a bunch of stuff to happen all at once, i'm ju
heh ... i remember it took me a few reads once upon a time to finally grok the proper usage of a lot of docbook markup. in any event, i'm not pushing for a bunch of stuff to happen all at once, i'm ju
|
By
Robert P. J. Day
· #48375
·
|
|
[PATCH] overview-manual: chs 1-3, various minor tweaks/cleanups
Minor fixes: - punctuation - capitalization - markup - wording Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/documentation/overview-manual/overview-manual-development-enviro
Minor fixes: - punctuation - capitalization - markup - wording Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/documentation/overview-manual/overview-manual-development-enviro
|
By
Robert P. J. Day
· #48361
·
|
|
why is poky described as not something you can use "out of the box"?
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
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
|
By
Robert P. J. Day
· #48355
·
|
|
reviving an old suggestion about YP docs markup
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 introduced
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 introduced
|
By
Robert P. J. Day
· #48353
·
|
|
reviving an old suggestion about YP docs markup
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 resear
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 resear
|
By
Robert P. J. Day
· #48351
·
|
|
clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)
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
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
|
By
Robert P. J. Day
· #48350
·
|
|
reviving an old suggestion about YP docs markup
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 a
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 a
|
By
Robert P. J. Day
· #48347
·
|
|
[PATCH] ref-manual: update PROVIDES entry, "+=" -> "="
Change the use of "+=" to the more proper "="; also, use a different recipe example that actually exists in OE-Core at the moment. Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --gi
Change the use of "+=" to the more proper "="; also, use a different recipe example that actually exists in OE-Core at the moment. Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --gi
|
By
Robert P. J. Day
· #48343
·
|
|
clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)
to summarize (and one last question), first, it would be utterly superfluous for any recipe to "PROVIDES" its own exact name. i'm not saying i've seen that in any of the OE/YP recipes, but i have taug
to summarize (and one last question), first, it would be utterly superfluous for any recipe to "PROVIDES" its own exact name. i'm not saying i've seen that in any of the OE/YP recipes, but i have taug
|
By
Robert P. J. Day
· #48342
·
|
|
more nitpicky pedantry: question about DEFAULT_PREFERENCE
ah, so if you don't specify a PREFERRED_PROVIDER, then *some* provider will ultimately be selected, is that it? you just won't have any gurarantee which one it will be. rday
ah, so if you don't specify a PREFERRED_PROVIDER, then *some* provider will ultimately be selected, is that it? you just won't have any gurarantee which one it will be. rday
|
By
Robert P. J. Day
· #48337
·
|
|
more nitpicky pedantry: question about DEFAULT_PREFERENCE
sorry, i mistyped the above, i should have written: "the pkgconfig recipe file does *not* contain a PROVIDES setting, while pkgconf_1.6.3.bb does:" so that PROVIDES line *would* be necessary, yes? (ju
sorry, i mistyped the above, i should have written: "the pkgconfig recipe file does *not* contain a PROVIDES setting, while pkgconf_1.6.3.bb does:" so that PROVIDES line *would* be necessary, yes? (ju
|
By
Robert P. J. Day
· #48332
·
|
|
wanting to clarify combination of overrides and appends
moving on to the next nitpicky issue i want to clarify, and that's *precisely* how overrides and appends are combined. i'm looking at section 3.3 in the bitbake manual and i don't think the examples t
moving on to the next nitpicky issue i want to clarify, and that's *precisely* how overrides and appends are combined. i'm looking at section 3.3 in the bitbake manual and i don't think the examples t
|
By
Robert P. J. Day
· #48316
·
|