[YOCTO #5408]
The reference manual should only refer to functionality which is available in
oe-core. Currently, this passage requires the user to add a package from, and
use facilities of, meta-oe. This fix describes how to use facilities in
oe-core to the same end.
Signed-off-by: Trevor Woerner
On Sat, 2 Nov 2013, Trevor Woerner wrote:
> [YOCTO #5408]
>
> The reference manual should only refer to functionality which is available in
> oe-core. Currently, this passage requires the user to add a package from, and
> use facilities of, meta-oe. This fix describes how to use facilities in
> oe
i figure the answer is obvious but i'll ask it anyway -- is it
reasonable to encourage new developers to use the general packagename
variables such as PN and BPN rather than hardcoding packagenames in
their recipe files?
typically, you see things like this in recipe files:
ALLOW_EMPTY_${PN}
on my quest to spiff up the ref manual variables glossary, a question
about ALTERNATIVE_LINK_NAME, explained here:
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ALTERNATIVE_LINK_NAME
at first glance, that explanation *suggests* that the purpose of that
variable is to s
(i can see it's going to be that kind of weekend.) ref manual reads:
BB_DANGLINGAPPENDS_WARNONLY = "1"
but some layers define:
meta-linaro/meta-aarch64/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY = "true"
meta-linaro/meta-linaro-toolchain/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY =
"t
most of the way thru the variable glossary and this one confuses me.
from here:
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PACKAGECONFIG
we have:
"This variable provides a means of enabling or disabling features of a
recipe on a per-recipe basis. PACKAGECONFIG bloc
On 2 November 2013 01:35, Robert P. J. Day wrote:
> that's not the reference manual, that's the dev manual.
Whoops! Thanks
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[YOCTO #5408]
The developer's manual should only refer to functionality which is available
in oe-core. Currently, this passage requires the user to add a package from,
and use facilities of, meta-oe. This fix describes how to use facilities in
oe-core to the same end.
Signed-off-by: Trevor Woerne
On Sat, Nov 02, 2013 at 01:15:04PM -0400, Robert P. J. Day wrote:
>
> most of the way thru the variable glossary and this one confuses me.
> from here:
>
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PACKAGECONFIG
>
> we have:
>
> "This variable provides a means of
On Sat, 2 Nov 2013, Martin Jansa wrote:
> On Sat, Nov 02, 2013 at 01:15:04PM -0400, Robert P. J. Day wrote:
> >
> > most of the way thru the variable glossary and this one confuses me.
> > from here:
> >
> > http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PACKAGECONFIG
> >
On Thu, 31 Oct 2013, Alex J Lennon wrote:
> I see that Mono no longer seems to be building against Yocto head /
> qemux86 (for me at least) and am considering looking at a recipe to
> build the current release of Mono whilst I dig into why this is.
>
> I wondered if you'd made any progress with
Hello All,
This is a continued effort with adding a "udev entry for a camera" &
"uImage instead of zImage" posting in Oct 13.
2 of my with dora 1.5 are showing same problem
lsusb --verbose
unable to initialize libusb: -99
Error opening /dev/fb0: No such file or directory during boot.
These builds
On Sat, Nov 2, 2013 at 3:06 PM, Edward Vidal wrote:
> Hello All,
> This is a continued effort with adding a "udev entry for a camera" & "uImage
> instead of zImage" posting in Oct 13.
> 2 of my with dora 1.5 are showing same problem
> lsusb --verbose
> unable to initialize libusb: -99
>
> Error o
13 matches
Mail list logo
