On Tue, Nov 27, 2012 at 12:24 PM, Robert P. J. Day
<rpjday@...> wrote:

and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.

Thank you for your testing and observations.

But I'd like to point out that in my tests, all the relevant files
have already been fetched. My DL_DIR already contains everything to
do with bash, trace-cmd, and various others that I have been
testing. The errors I am getting are not fetching-related errors,
but are errors because do_rootfs can't find any packages (since
packages relating to the recently-appended recipes have not been
built).

Somewhere in the guts of bitbake a modified IMAGE_INSTALL_append
variable is not being noticed; packages aren't being created (as
I've noticed) and sources aren't being downloaded (as you have just
noticed). But somehow do_rootfs is noticing the change and
complaining it can't find the necessary packages.

Hi Maxin - it would be good to coordinate your effort with the rest of the community.

Can you let us know what you have in mind before starting?

Also, please let me know if you have trouble with access. I don't see any account requests being held.

thanks

Hi Alex,

Hello all,

I can't help but notice that the main page of the Yocto Wiki looks somewhat underwhelming compared to the new site face.
Can we please have a volunteer to update and beautify a bit the main page ?

I am interested in this task. I have already sent a request for access to the Yocto Wiki.

I'd think that we need to list current 1.4 pages, add/verify links to all main sections, and the Yocto logo, etc...

We can discuss the list of activities in this mailing-list or in irc
(nickname: maxin)

Cheers,
Alex

Best Regards,
Maxin
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

On Tue, Nov 27, 2012 at 12:24 PM, Robert P. J. Day
<rpjday@...> wrote:

and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.

Thank you for your testing and observations.

But I'd like to point out that in my tests, all the relevant files
have already been fetched. My DL_DIR already contains everything to
do with bash, trace-cmd, and various others that I have been
testing. The errors I am getting are not fetching-related errors,
but are errors because do_rootfs can't find any packages (since
packages relating to the recently-appended recipes have not been
built).

Somewhere in the guts of bitbake a modified IMAGE_INSTALL_append
variable is not being noticed; packages aren't being created (as
I've noticed) and sources aren't being downloaded (as you have just
noticed). But somehow do_rootfs is noticing the change and
complaining it can't find the necessary packages.

and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.

and ran the fetchall again. this time, no strace source was fetched,
so it looks like an issue with simple fetching.

On Fri, Nov 23, 2012 at 5:13 PM, Otavio Salvador
<otavio@...> wrote:

Hi,

Could patchwork support be added to meta-freescale? It'd allow for
easy handle of patches.

Ping?

On Tue, Nov 27, 2012 at 08:40:26AM -0500, Trevor Woerner wrote:

Thank you, Eric, for the confirmation.

Just to clarify for anyone following along: the problem isn't with
bash or trace-cmd themselves. If I perform the same steps but use
'bash' first, then 'trace-cmd', adding 'bash' succeeds but later
adding 'trace-cmd' causes 'trace-cmd' to fail in the same way
'bash' did when it was added second.

Since it's confirmed from different people, I think it would be
better to report it using bugzilla. I guess that it's not an
intended behaviour/feature of bitbake. Please inform the bug number
so that anyone who is interested can follow.

Reply inline

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@...]
Sent: Tuesday, November 20, 2012 8:53 PM
To: Venkata ramana gollamudi
Cc: yocto@...; Sanil kumar; Hatle, Mark
Subject: Re: [yocto] Need for offline binary configuration

On 12-11-20 10:09 AM, Venkata ramana gollamudi wrote:

Poky allows to build custom Linux for you, but we have cases where

the post build customization is required, like user-addition, network
configuration, service control. Even selecting the required packages
can be a post build activity.

The current model requires the image to be rebuilt to support these

configuration.

Offline Configuration tool (OCT), which allows a binary image

customization before making a final target image. This case will be
more evident in larger companies, where platform teams, product teams ,
application teams are distributed and Linux build from source will be
owned and lab tested by a single team, like platform team. Other teams
just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated

from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages

into final target image.

b) Provision to select external binary packages like ADT compiled

applications as input and add them to final target image.

c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format
etc..

Considering the methods to support these in our current yocto model,

following changes can be done.

1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and

Hob can work on this package pool to select packages, configure and
generate image.

So HOB can support opening HOB in Binary(or OCT) mode i.e., without

build options but only with binary package selection. Configuration GUI
needs to be added to HOB.

Note:HOB+OCT is together or separate, needs a bit more thought and

overall organization as they will be intended for different users.

Is there some overlap between this point and the other ongoing
discussions
about image construction, deployment and package management ?

i.e. this thread:

[OE-core] RFC: OE-Core image creation and deployment

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-
July/026938.html

These may already be coordinated, but I do see some common threads and
it would be nice to make sure everything will work together and that we
aren't duplicating effort!

Cheers,

Bruce

Bruce, Thanks for the information. After your reply, I have gone through the discussions and agree that binary pool is in similar lines. Great to see that the realization happening in yocto1.4.
Understood that package-feed can be used to generate the target image.

Is there any RFC/mail/wiki available explaining how the configuration(like fstype) during image generation will be realized?

I am looking for post build configuration tool, which allows the product team users also to configure users, network, services etc .

Image type, file system and Partition configuration can be one of them.
I expect the product team users who configures image and generates target image, will have a little or no knowledge of bitbake, also needs easy installation and less dependencies.

Can look in this context, how HOB will fit into this scenario or needs a new tool.

2) Binary package pool can be a minimal/partial sstate-cache, as

complete sstate-cache is quite big and not required for product teams
as they are not expected to build but just need to select and
configure.

I think it is sufficient to keep the minimal binaries from

sstate-cache which are required to execute image.bbclass, do_rootfs
task to generate image.

Point 2, No longer applicable as package-feed is a binary pool.

3) Along with specific configuration UI implementation, a generic

configuration model similar to kernel kconfig and menuconfig can be
considered, in cases where more detailed offline configurations is
required like detailed security configuration.

Point 3, still can be thought about.

Regards,
Ramana
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

Thank you, Eric, for the confirmation.

Just to clarify for anyone following along: the problem isn't with
bash or trace-cmd themselves. If I perform the same steps but use
'bash' first, then 'trace-cmd', adding 'bash' succeeds but later
adding 'trace-cmd' causes 'trace-cmd' to fail in the same way 'bash'
did when it was added second.

I started looking at Yocto 2 weeks back. Despite the complexity in
kernel building, I found it quite hard to locate information on
preempt-rt build. I was trying to build linux-yocto-rt for beagleboard
from "danny" and the linux-yocto-3.4 kernel, and it seems to be working.
I'd like to share how one can do that in this thread.

Since the kernel does not include an official preempt-rt branch for
beagleboard yet, I choose to directly use the standard/preempt-rt/base
branch. I guess this should work for the preempt-rt kernel, from the
fact that the standard kernel (non preempt-rt) used for beagleboard from
the standard/beagleboard branch is basically identical to that from the
standard/base branch.

Here is what I did.
1. Under poky/meta-yocto-bsp/recipes-kernel/linux, I added a
linux-yocto-rt_3.4.bbappend recipe containing the following lines. The
SRCREV value used is the same as the one in the base
linux-yocto-rt_3.4.bb <http://linux-yocto-rt_3.4.bb> under
poky/meta/recipes/kernel.

KBRANCH_beagleboard = "standard/preempt-rt/base"
SRCREV_machine_beagleboard ?= "5705c8037d2c47938034ead87c70ae3ebef552f7"
COMPATIBLE_MACHINE_beagleboard = "beagleboard"

2. Modified the PREFERRED_PROVIDER_virtual/kernel variable in
poky/meta-yocto-bsp/conf/machine/beagleboard.conf to "linux-yocto-rt".

3. "bitbake linux-yocto-rt -c menuconfig" to set the Preemption Model to
"Fully Preemptible Kernel (RT)".

4. "bitbake linux-yocto-rt"

5. "bitbake core-image-rt" which includes some realtime test programs on
top of core-image-minimal.

I did some cyclictest on beagleboard using the generated kernel and
image with "/usr/bin/cyclictest -p95 -m". The results did show huge
improvement on max latency especially under load.

Hope it helps.

Cheers
Pan Yu


_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto