Hi Jessica
Zhang, Jessica wrote, On 24.06.2013 07:25:
Hi Timo,
For case 1, I think we probably should bring back the grey out
option. In my opinion, it's more consistent. The property window
should be the centralized place for user to setup the settings. The
drop down list is for user to
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
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
From: Bruce Ashfield
There's no technical reason at all. In fact, pre 3.8 the -rt
kernel used
to inherit more of the standard kernel's configuration and
hence enabled
cgroups. In 3.8, we defined a new policy for the -rt kernel, that used
parts of the standard kernel's configuration, but
Hi,
Thank you for the answer.
I've tried
- by commenting RDEPENDS_kernel-base ?= kernel-image from kernel.bbclass
- and/or adding RDEPENDS_kernel-base = in my image definition
But neither worked.
For confirmation, this bitbake -e outptut and it doesn't have the
kernel-base
insop@neon
On Mon, Jun 24, 2013 at 5:29 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
On 13-06-23 7:08 PM, Insop Song wrote:
Hi,
- Question
How NOT to include kernel image to the rootfs?
- Background
In our application, we use u-boot to load kernel and rootfs from nand
flash separately.
* Insop Song insop.s...@gmail.com [130624 10:56]:
I've tried
- by commenting RDEPENDS_kernel-base ?= kernel-image from kernel.bbclass
- and/or adding RDEPENDS_kernel-base = in my image definition
You should add this line in either your local.conf, or in a .bbappend
for the kernel recipe in
Insop,
You can check the actual dependency in the output file of bitbake -g
fsl-image-min-net2.
Best Regards,
Zhenhua
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Anders Darander
Sent: Monday, June 24, 2013 5:05
Thank you all for the help.
I've added RDEPENDS_kernel-base = at conf/local.conf
Also I had to take out oprofile in my image, as oprofile needs
kernel-vmlinux ...
Then it worked.
Thank you all.
Regards,
Insop
On Mon, Jun 24, 2013 at 2:12 AM, Luo Zhenhua-B19537
b19...@freescale.com wrote:
On Mon, Jun 24, 2013 at 1:41 AM, Rudolf Streif
rstr...@linuxfoundation.org wrote:
Hi Trever et al:
If I were writing a book about Yocto/OE,
This is a project I am currently working on, a book about the Yocto Project.
The goal is to enable readers to do practical projects with YP. As the
Hi Rudi,
On 24 June 2013 01:41, Rudolf Streif rstr...@linuxfoundation.org wrote:
If I were writing a book about Yocto/OE,
This is a project I am currently working on, a book about the Yocto Project.
Awesome! That's great news! I was hoping someone would beat me to it
:-) I look forward to
Scott,
I think the general diagram looks pretty good, although I'd argue there's a
little too much detail in the file list being shown, or else some of this
new stuff is going to be useful in 1.5 when it's not doing anything in 1.4.
Here are the files I see as excessive:
In meta-yocto:
-
On 13-06-24 03:09 AM, Paul D. DeRocco wrote:
From: Bruce Ashfield
There's no technical reason at all. In fact, pre 3.8 the -rt
kernel used
to inherit more of the standard kernel's configuration and
hence enabled
cgroups. In 3.8, we defined a new policy for the -rt kernel, that used
parts of the
On 06/23/2013 11:52 PM, Rifenbark, Scott M wrote:
Hi,
I am going to start throwing these diagrams out to the mailing list and see
if I can get any feedback. This attached figure dives into user
configuration. Any and all discussion, correction, suggestions are welcome.
It appears the
On 24 June 2013 13:59, Jerrod Peach pea...@lexmark.com wrote:
auto.conf (That's not even present in my 1.4 workspace. Is this going to be
something new in 1.5?)
auto.conf is read along with site.conf and local.conf, and is intended
to be automatically created and maintained by autobuilders.
Jerrod,
Thanks for the feedback in this area. Your observations are pretty much in
line with what I got from Paul Eggleton, who is on the YP Team. I am going to
reduce what is revealed file-wise in the meta-yocto layer. Turns out that
auto.conf and site.conf are files that a user would have
What I was trying to convey here is that oe-init-build-env draws on some files
in the meta-yocto layer. The script oe-init-build-env is in the poky
repository (or refered to as Source Directory in the documentation). The
sample files are in the meta-yocto layer. I thought the meta-yocto
Hi,
I apologize in advance if I'm not posting this to correct place or in the
correct manner.
I have a question regarding the shared state code optimizations in yocto 1.4.
I'm in the process of upgrading one of our projects from Edison (6.0) to Dylan
(9.0.0) and am running into an issue with
My figure is for Yocto Project documentation so I am going to show that
oe-init-build-env gets information from meta-yocto. I understand that OE-Core
sample files are in meta. There is a single oe-init-build-env script and it
looks in one of two places.
Scott
-Original Message-
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:
What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env is
in the poky repository (or refered to as Source Directory in the
documentation). The sample files are in the
On 24 June 2013 15:47, Robert P. J. Day rpj...@crashcourse.ca wrote:
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:
What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env is
in the poky repository (or refered to as
Hi Brian,
On Monday 24 June 2013 11:01:31 Brian Karcz wrote:
I have a question regarding the shared state code optimizations in yocto
1.4. I'm in the process of upgrading one of our projects from Edison (6.0)
to Dylan (9.0.0) and am running into an issue with our existing image
recipe.
The
Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
Hi Timo,
Your finding is described in my case 3. For reproduce the double selection,
you need to select project specific apply exit the property window. Then go
back to property window, deselect project specific apply, exit the window.
Then check the drop down list, I can consistently
On 13-06-24 11:59 AM, Hans Beckérus wrote:
Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the
On 24 June 2013 17:19, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 13-06-24 11:59 AM, Hans Beckérus wrote:
Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really
On Mon, Jun 24, 2013 at 6:29 PM, Paul Barker p...@paulbarker.me.uk wrote:
On 24 June 2013 17:19, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 13-06-24 11:59 AM, Hans Beckérus wrote:
Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see
On 06/24/2013 11:08 AM, Rifenbark, Scott M wrote:
My figure is for Yocto Project documentation so I am going to show that
oe-init-build-env gets information from meta-yocto. I understand that
OE-Core sample files are in meta. There is a single oe-init-build-env
script and it looks in one
On 24 June 2013 17:55, Philip Balister phi...@balister.org wrote:
Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.
Agreed - explaining clearly that
Ok - I was told there was just a single version of oe-init-build-env. So that
must be not quite right. What I will likely do is in the supporting text for
the figure get into some detail on just where these pieces are. That would be
a good opportunity to maybe present some text around that.
On 06/24/2013 12:59 PM, Burton, Ross wrote:
On 24 June 2013 17:55, Philip Balister phi...@balister.org wrote:
Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they
On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister phi...@balister.org wrote:
Showing how Poky (the reference distribution) is built would be a nice
way to introduce people to building their own custom distributions using
OpenEmbedded.
Totally agree, but I would relegate that to a separate
Thanks for sending these out! Nice to see it before the meeting tomorrow
On 6/24/13 11:37 AM, Michael Halstead mich...@yoctoproject.org wrote:
The trend graphs for work week 25 are up at
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend with two new charts.
Versions of the weighted defect
That would be to copy a single file, provided in the files subdirectory of
the recipe, into a particular place in the target tree. Is there any bbclass
that automates this? Or do I just write a recipe with a do_install function
that executes the install command?
My only guide is 5.3.1 in the
On 06/24/2013 02:37 PM, Jeff Osier-Mixon wrote:
On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister phi...@balister.org wrote:
Showing how Poky (the reference distribution) is built would be a nice
way to introduce people to building their own custom distributions using
OpenEmbedded.
Totally
Hi Trevor,
On Mon, Jun 24, 2013 at 5:56 AM, Trevor Woerner
trevor.woer...@linaro.orgwrote:
Awesome! That's great news! I was hoping someone would beat me to it
:-) I look forward to reading it once it's done. Do you have a
publisher or an expected release date?
Yes, I do. Pearson and the
Add touchscreen-composite support to machines based on common-pc and
common-pc-64, along with several other Atom boards that don't inherit
from those, thus providing those machines with the out-of-the-box
ability to make use of the set of USB touchscreen devices supported by
the composite USB
This patchset adds support for USB touchscreens that can use the
'composite' touchscreen driver.
Build-tested only (nuc and crownbay) since I don't have a USB
touchscreen to test.
Fixes Yocto Bug 4770 - Enable USB touchscreens
The following changes since commit
38 matches
Mail list logo
