While you cannot *enforce* a change for one package/in another recipe file
based on whether another package is included in an image, you can have recipes
(and their bbappends) respond to configuration settings. Two such mechanisms
are FEATURES and OVERRIDES. In this particular case I would
Mike Looijmans Wrote:
> Just attempting to revive this dead horse again...
>
> Anyone made any proress here?
>
> Since cross-compiling turned out to be really really painful, I tried if
> compiling on the board would be an option. No such luck, apparently
> the Fortran compiler isn't being
Quick _workaround_:
1. Modify/extend your Repo manifest to pull your mirror repos to the
appropriate place under downloads/git2.
2. Override the non-sha1 SRCREVs with an appropriate SHA1.
Either in .bbappend files or via conf file extensions.
The mega-manual describes the latter in
Discussing only the question of making a SciPy recipe today:
> > Is there a current or relatively recent recipe for SciPy and related
> > libraries?
>
> People have worked on it at least once before but found some problems with
> blas and atlas:
>
Is there a current or relatively recent recipe for SciPy and related libraries?
Further and more importantly, is having a maintainer for (recipes for) those
libraries a priority for the active members of the Project?
(i.e. does interest rise above the general welcoming of participants to
Is there a way to configure meta-mono to ahead of time (AOT) compile the system
assemblies for the target?
Specifically, I would like to not have to run the following on my targets.
sudo mono --aot /usr/lib/mono/4.5/mscorlib.dll
for f in /usr/lib/mono/gac/*/*/*.dll; do sudo mono --aot "$f"; done
See the Yocto Wiki Question "How do I create my own source download mirror?"
https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F
That does not answer why you are getting intermittent download errors, but the
stark fact is that to some degree this must
"How do you prefer a provider out of two different versions of a package?"
PREFERRED_VERSION
http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-PREFERRED_VERSION
Notice to recipient: This email is meant for only the intended recipient of the
The recommendations on your blog suggest modifying image-buildinfo.bbclass to
change IMAGE_BUILDINFO_VARS.
You /should/ be able to avoid this by simply adding something like
IMAGE_BUILDINFO_VARS_append = " MACHINE DEVICE_MODEL DEVICE_TYPE"
or
IMAGE_BUILDINFO_VARS = "DISTRO DISTRO_VERSION MACHINE
The following is roughly the procedure I follow and that works for me. Maybe
someone could chime in with how some of this should be trimmed based on
yocto/bitbake intent/design.
Even so I'd probably stick with this level of extremism because without a known
good backup of your
$ bitbake meta-toolchain-qt5
well SDKIMAGE_FEATURES only work when you generate SDKs using -
cpopulate_sdk out of real images and not meta-toolchain-* targets which IMO
should no longer be used.
As a (non-expert/non-maintainer) user, I'm happy to hear it said [by Khem Raj]
that
Perhaps someone could improve on this, but
you can build a dtb from a source dts using a bbappend for your linux kernel.
1. drop a copy of your new dts in ${S}/arch/arm/boot/dts
2. add the name of your dtb to the KERNEL_DEVICETREE variable.
If you are modifying an existing dts file, the cleanest
Change
IMAGE_INSTALL += “canlogger”
to
IMAGE_INSTALL_append = “ canlogger”
or possibly better
EXTRA_IMAGE_INSTALL_append = “ canlogger”
if you're putting this in local.conf, i'm pretty sure the preferred syntax
is just:
EXTRA_IMAGE_INSTALL = canlogger
Yes, I think rday is
This seems to bite a lot of people (myself included).
Change
IMAGE_INSTALL += “canlogger”
to
IMAGE_INSTALL_append = “ canlogger”
or possibly better
EXTRA_IMAGE_INSTALL_append = “ canlogger”
+= is evaluated immediately during parsing just like = and therefore behaves
just like = if the variable
I want to customize various config file of an image I'm building (e.g.
network interfaces, sshd banner, hostapd, etc..).
Paul Eggleton just gave a response to a similar question Force install package
last
https://lists.yoctoproject.org/pipermail/yocto/2015-April/024548.html
- If not possible
This is not true in the general case. You definitely can use
IMAGE_INSTALL_append with a leading space to add items to an image, I just
verified that now.
I'm not clear on exactly what happened in the case we're discussing, at least
initially it sounded like IMAGE_INSTALL = rather than
OK, it turned out that prepending the space before lib32-connman does
not do any good. However, commenting out the line which contains the
IMAGE_INSTALL_append does. That begs the question; what does
lib32-connman do?
It's not lib32-connman that's the problem. The problem is that you
17 matches
Mail list logo
