I would suggest to use separate build directories but let these builds
to share downloads and sstate.
Regards,
Chen Qi
On 11/30/2014 12:49 PM, Qiang Yu wrote:
Hi all,
I'm maintaining a Yocto build system to produce these outputs:
1. ARM SOC 1
1). board 1 image
2). board 2 image
3). SDK
Create a bbappend file for core-image-minimal-initramfs, and add the
following line to the bbappend file.
PACKAGE_INSTALL += "linux-firmware"
Best Regards,
Chen Qi
On 11/28/2014 08:37 PM, Chris Tapp wrote:
I'm network booting a system using iPXE. The process uses a
core-image-minimal-initra
I am using poky 1.6.1. I have built the follwing images successfully :
core-image-sato-sdk & atmel-qt5-demo-image. I am tying to build the
following image without success: atmel-qt5-demo-image -c populate_sdk
I get the error:
-
ERROR: Function failed: do_popu
Hi everyone,
I am trying to build an application using Qt5 Multimedia (playing a
video). Yocto is latest 1.6. Qt and my application compile just fine but
when I run the application I get this error:
This application failed to start because it could not find or load the
Qt platform plugin "xcb"
I solved this problem my own: The package qtbase-plugins has to be added
to the image to install the plugins.
I also had to add the package qtmultimedia-plugins to install gstreamer
plugins and add the line
PACKAGECONFIG_append_pn-qtmultimedia = " gstreamer010 "
to my local.conf to add gstreamer
Why share the sstate? Does it contain previously build ipk packages in
other build directories for reuse?
Regards,
Qiang
On Sun, Nov 30, 2014 at 4:03 PM, ChenQi wrote:
> I would suggest to use separate build directories but let these builds
> to share downloads and sstate.
>
> Regards,
> Chen
If using yocto 1.6.1 plugin for Eclipse then selecting help->install
new software->add then
using http://downloads.yoctoproject.org/releases/eclipse-plugin/1.6.1/kepler
[1] works fine.
For V1.7 I have tried:- doing the above but using 1.7 instead of
1.6.1 -> does not work- I try follwing the dev-
[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On
14.11.29 (Sat 20:51) akuster808 wrote:
> Joe,
>
> I went a head and updated to 7.4 which included the security fix.
> Thanks for the reminder.
Yeah, that's on my to-do list for meta-selinux, too. That's the right
cours
Hi,
I build a core-image-x11 with beaglebone as machine. I added gstreamer
0.10 support which I will need in Qt. However, I am not able to play a
video using xvimagesink like this:
gst-launch filesrc location=/home/root/centaur_1.ogv ! oggdemux !
theoradec ! ffmpegcolorspace ! xvimagesink
I g
On 11/30/2014 11:45 AM, Joe MacDonald wrote:
[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On
14.11.29 (Sat 20:51) akuster808 wrote:
Joe,
I went a head and updated to 7.4 which included the security fix.
Thanks for the reminder.
Yeah, that's on my to-do list for
On 30 Nov 2014, at 08:06, ChenQi wrote:
> Create a bbappend file for core-image-minimal-initramfs, and add the
> following line to the bbappend file.
>
> PACKAGE_INSTALL += "linux-firmware"
Thanks, PACKAGE_INSTALL works great :-)
I've gone with the following in my local.conf:
PACKAGE_INS
Now after study share state cache in yocto document, I know it can be used
by multi build dir
to share IPK files. But if all the build dir share the same sstate_cache,
why don't they just use
the same build dir? I can only think one reason: needn't change conf/ files
when switching output.
But when
This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers
believe some of them needn't to upgrade this time, they can fill in
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this
recipe remainder until newer u
This mail was sent out by Package Report System.
It will list all the recipes which can't check upstream version by script, and
will show how long it is since their last mannual version check.
You can check the detail information at
http://packages.yoctoproject.org/manuallychkinfo
PackageName
Hi Paul,
Your approach worked and I thank you for that.
However I have some more unrelated questions (if you don't mind):
1. I noticed some mainstream Python modules that are supposed to come
with default Python installation are not present. I take the example
of sqlite3 module not present in de
Hi Chen Qi,
Thanks for your suggestion.
I mean the tmp/deploy/ipk dir will have one copy each build dir. And two
boards of the same SOC will
share most of them, so the disk space of the tmp/deploy/ipk part is wasted.
Regards,
Qiang
On Mon, Dec 1, 2014 at 10:01 AM, ChenQi wrote:
> Sharing ss
[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On
14.11.30 (Sun 13:21) akuster808 wrote:
>
>
> On 11/30/2014 11:45 AM, Joe MacDonald wrote:
> >[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On
> >14.11.29 (Sat 20:51) akuster808 wrote:
> >
> >
Hi Qiang,
It's possible that you are using (or might use) different layer
configurations for different builds.
One build might have a bbappend file that another build doesn't need.
Also, different builds may have different DISTRO_FEATURES.
Thus, having different deploy directories is better. Ot
>
>
> It's possible that you are using (or might use) different layer
> configurations for different builds.
> One build might have a bbappend file that another build doesn't need.
>
Yes, you are right. I use different conf/bblayers.conf for different SOC.
But within the same SOC's different output
On 12/01/2014 12:45 PM, Qiang Yu wrote:
It's possible that you are using (or might use) different layer
configurations for different builds.
One build might have a bbappend file that another build doesn't need.
Yes, you are right. I use different conf/bblayers.conf for different
S
Hi,
In poky master, FILESOVERRIDES is constructed as follows:
"${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
For my current build, I get:
FILESOVERRIDES="powerpc:custom-machine:e500v2:qoriq-ppc:poky"
FILESPATH is built by calling base_set_filespath(), which is in
utils.bb
What about MACHINE_FEATURES and IMAGE_FEATURES?
On Mon, Dec 1, 2014 at 1:28 PM, ChenQi wrote:
> On 12/01/2014 12:45 PM, Qiang Yu wrote:
>
>
>> It's possible that you are using (or might use) different layer
>> configurations for different builds.
>> One build might have a bbappend file that an
On 12/01/2014 03:04 PM, Qiang Yu wrote:
What about MACHINE_FEATURES and IMAGE_FEATURES?
IMAGE_FEATURES is OK.
MACHINE_FEATURES is like DISTRO_FEATURES. Things are not ensured to work
correctly if you change it in the same build directory.
If I were you, I would jut let builds to share sstat
23 matches
Mail list logo