date:20130620

Re: [yocto] Toolchain... Issues with systemd (probably)

2013-06-20 Thread DAMARLA Satya Swaroop

Any reasons why toolchains compile wihtout any issues on sysvinit and not
with systemd?


On Wed, Jun 19, 2013 at 3:11 PM, DAMARLA Satya Swaroop <
swaroop.dama...@gmail.com> wrote:

> Yes... I thought the same and so, I made two build directories , one for
> sysvinit and the other for systemd and the errors I get abosulte no error
> when I try to *populate_sdk* under sysvinit but I get the following
> errors when I run the same under systemd.
>
> *| The following packages have unmet dependencies:*
> *|  udev-dev : Depends: udev (= 182-r7) but 1:204-r0 is to be installed*
> *| Recommends: libusb-dev but it is not installable*
> *| Recommends: module-init-tools-dev but it is not installable
> *
> *| Recommends: libkmod-dev but it is not installable*
> *| E: Unable to correct problems, you have held broken packages.*
> *| DEBUG: Python function do_populate_sdk finished*
> *| ERROR: Function failed: populate_sdk_image (log file is located at
> /home/damarla/openYocto/poky/buildSmartCPUsystemd/tmp/work/smartcpu-poky-linux-gnueabi/rootfs-smartcpu-sdk/1.0-r0/temp/log.do_populate_sdk.17015)
> *
> *ERROR: Task 10
> (/home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/
> rootfs-smartcpu-sdk.bb, do_populate_sdk) failed with exit code '1'*
> *NOTE: Tasks Summary: Attempted 4961 tasks of which 4960 didn't need to
> be rerun and 1 failed.*
> *
> *
> *Summary: 1 task failed:*
> *  /home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/
> rootfs-smartcpu-sdk.bb, do_populate_sdk*
> *Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> *
> *
> *
> * *I don't understand why I dont get an error with sysvinit and get an
> error here
>
>
> On Wed, Jun 19, 2013 at 2:11 PM, Burton, Ross wrote:
>
>> On 19 June 2013 13:08, DAMARLA Satya Swaroop 
>> wrote:
>> > I think I had to open the issue as its not closed... Here is more
>> > clarity
>> >
>> > The issue is I decided the problem may be with init_manager. I did two
>> > builds one with sysvinit using traditional Poky distro and other one is
>> > uisng systemd using new distribution which is different as we need a new
>> > distribution for using systemd
>> >
>> > .. I didno t get any errors when i build using bitbake -c populate_sdk
>> > rootfs-smartcpu with sysvinit and got build errors using systemd...
>> >
>> > Any possible resons what could have caused failure to build the
>> toolchain?
>>
>> It really helps when you tell us what the errors are.
>>
>> Note that changing DISTRO_FEATURES in an existing build directory
>> isn't supported and may well cause problems.
>>
>> Ross
>>
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Toolchain... Issues with systemd (probably)

2013-06-20 Thread Khem Raj


On Jun 20, 2013, at 12:12 AM, DAMARLA Satya Swaroop 
 wrote:

> Any reasons why toolchains compile wihtout any issues on sysvinit and not 
> with systemd?
> 
> 
> On Wed, Jun 19, 2013 at 3:11 PM, DAMARLA Satya Swaroop 
>  wrote:
> Yes... I thought the same and so, I made two build directories , one for 
> sysvinit and the other for systemd and the errors I get abosulte no error 
> when I try to populate_sdk under sysvinit but I get the following errors when 
> I run the same under systemd.
> 
> | The following packages have unmet dependencies:
> |  udev-dev : Depends: udev (= 182-r7) but 1:204-r0 is to be installed
> | Recommends: libusb-dev but it is not installable
> | Recommends: module-init-tools-dev but it is not installable
> | Recommends: libkmod-dev but it is not installable
> | E: Unable to correct problems, you have held broken packages.


it seems you did not choose systemd as provider for udev. You should do that 
when you use systemd


> | DEBUG: Python function do_populate_sdk finished
> | ERROR: Function failed: populate_sdk_image (log file is located at 
> /home/damarla/openYocto/poky/buildSmartCPUsystemd/tmp/work/smartcpu-poky-linux-gnueabi/rootfs-smartcpu-sdk/1.0-r0/temp/log.do_populate_sdk.17015)
> ERROR: Task 10 
> (/home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/rootfs-smartcpu-sdk.bb,
>  do_populate_sdk) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 4961 tasks of which 4960 didn't need to be 
> rerun and 1 failed.
> 
> Summary: 1 task failed:
>   
> /home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/rootfs-smartcpu-sdk.bb,
>  do_populate_sdk
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> 
>  I don't understand why I dont get an error with sysvinit and get an error 
> here
> 
> 
> On Wed, Jun 19, 2013 at 2:11 PM, Burton, Ross  wrote:
> On 19 June 2013 13:08, DAMARLA Satya Swaroop  
> wrote:
> > I think I had to open the issue as its not closed... Here is more
> > clarity
> >
> > The issue is I decided the problem may be with init_manager. I did two
> > builds one with sysvinit using traditional Poky distro and other one is
> > uisng systemd using new distribution which is different as we need a new
> > distribution for using systemd
> >
> > .. I didno t get any errors when i build using bitbake -c populate_sdk
> > rootfs-smartcpu with sysvinit and got build errors using systemd...
> >
> > Any possible resons what could have caused failure to build the toolchain?
> 
> It really helps when you tell us what the errors are.
> 
> Note that changing DISTRO_FEATURES in an existing build directory
> isn't supported and may well cause problems.
> 
> Ross
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] Toolchain... Issues with systemd (probably)

2013-06-20 Thread DAMARLA Satya Swaroop

Hi Khem,

May I ask you where I have to set that because I dont see anything like
sysvinit has been set ... would be greatfull if you can tell me that

Greets,
Satya


On Thu, Jun 20, 2013 at 9:29 AM, Khem Raj  wrote:

>
> On Jun 20, 2013, at 12:12 AM, DAMARLA Satya Swaroop <
> satyaswaroop.dama...@gmail.com> wrote:
>
> Any reasons why toolchains compile wihtout any issues on sysvinit and not
> with systemd?
>
>
> On Wed, Jun 19, 2013 at 3:11 PM, DAMARLA Satya Swaroop <
> swaroop.dama...@gmail.com> wrote:
>
>> Yes... I thought the same and so, I made two build directories , one for
>> sysvinit and the other for systemd and the errors I get abosulte no error
>> when I try to *populate_sdk* under sysvinit but I get the following
>> errors when I run the same under systemd.
>>
>> *| The following packages have unmet dependencies:*
>> *|  udev-dev : Depends: udev (= 182-r7) but 1:204-r0 is to be installed*
>> *| Recommends: libusb-dev but it is not installable*
>> *| Recommends: module-init-tools-dev but it is not
>> installable*
>> *| Recommends: libkmod-dev but it is not installable*
>> *| E: Unable to correct problems, you have held broken packages.*
>>
>
>
> it seems you did not choose systemd as provider for udev. You should do
> that when you use systemd
>
>
> *| DEBUG: Python function do_populate_sdk finished*
>> *| ERROR: Function failed: populate_sdk_image (log file is located at
>> /home/damarla/openYocto/poky/buildSmartCPUsystemd/tmp/work/smartcpu-poky-linux-gnueabi/rootfs-smartcpu-sdk/1.0-r0/temp/log.do_populate_sdk.17015)
>> *
>> *ERROR: Task 10
>> (/home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/
>> rootfs-smartcpu-sdk.bb, do_populate_sdk) failed with exit code '1'*
>>  *NOTE: Tasks Summary: Attempted 4961 tasks of which 4960 didn't need to
>> be rerun and 1 failed.*
>> *
>> *
>> *Summary: 1 task failed:*
>> *  /home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/
>> rootfs-smartcpu-sdk.bb, do_populate_sdk*
>> *Summary: There was 1 ERROR message shown, returning a non-zero exit
>> code.*
>> *
>> *
>> * *I don't understand why I dont get an error with sysvinit and get an
>> error here
>>
>>
>> On Wed, Jun 19, 2013 at 2:11 PM, Burton, Ross wrote:
>>
>>> On 19 June 2013 13:08, DAMARLA Satya Swaroop 
>>> wrote:
>>> > I think I had to open the issue as its not closed... Here is more
>>> > clarity
>>> >
>>> > The issue is I decided the problem may be with init_manager. I did two
>>> > builds one with sysvinit using traditional Poky distro and other one is
>>> > uisng systemd using new distribution which is different as we need a
>>> new
>>> > distribution for using systemd
>>> >
>>> > .. I didno t get any errors when i build using bitbake -c populate_sdk
>>> > rootfs-smartcpu with sysvinit and got build errors using systemd...
>>> >
>>> > Any possible resons what could have caused failure to build the
>>> toolchain?
>>>
>>> It really helps when you tell us what the errors are.
>>>
>>> Note that changing DISTRO_FEATURES in an existing build directory
>>> isn't supported and may well cause problems.
>>>
>>> Ross
>>>
>>
>>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Toolchain... Issues with systemd (probably)

2013-06-20 Thread Paul Eggleton

On Thursday 20 June 2013 00:29:23 Khem Raj wrote:
> On Jun 20, 2013, at 12:12 AM, DAMARLA Satya Swaroop
>  wrote:
> > Any reasons why toolchains compile wihtout any issues on sysvinit and not
> > with systemd?
> > 
> > 
> > On Wed, Jun 19, 2013 at 3:11 PM, DAMARLA Satya Swaroop
> >  wrote: Yes... I thought the same and so, I
> > made two build directories , one for sysvinit and the other for systemd
> > and the errors I get abosulte no error when I try to populate_sdk under
> > sysvinit but I get the following errors when I run the same under
> > systemd.> 
> > | The following packages have unmet dependencies:
> > |  udev-dev : Depends: udev (= 182-r7) but 1:204-r0 is to be installed
> > |  
> > | Recommends: libusb-dev but it is not installable
> > | Recommends: module-init-tools-dev but it is not installable
> > | Recommends: libkmod-dev but it is not installable
> > | 
> > | E: Unable to correct problems, you have held broken packages.
> 
> it seems you did not choose systemd as provider for udev. You should do that
> when you use systemd

default-providers.inc already does this so you should not need to:

meta/conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_udev ?= 
"${@base_contains('DISTRO_FEATURES','systemd','systemd','udev',d)}"

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Rifenbark, Scott M

Hi, 

Recently, Paul, Ross, Richard and I had a video conference meeting where we had 
some initial discussion on how to satisfy YOCTO #2808 
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=2808), which calls for an 
illustration showing source and destination directories during a build using 
YP.  This bug originated from a discussion Dave Stewart and I had a while back 
around an idea of a more detailed "flow diagram" that would go into greater 
detail than the now famous and ubiquitous "The Yocto Project Development 
Environment" illustration, which appears in the YP Quick Start 
(http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html) 
and has been used in many other places and in many other forms (some quite 
elaborate).

We can't really create a completely accurate, all-encompassing illustration 
that breaks apart the entire build process.  It is not a static thing and it is 
quite complicated inside the BitBake process.  We can, however, show where 
metadata comes from, how it is provided, what it defines, where and how source 
files are found, what processes occur, what output is produced, and where it 
ends up.  We can also provide some sort of idea of how key BitBake and 
environment variables affect things along the way.  The idea here is to dig 
deeper into this conceptual figure and root out the details to a level that 
would be useful to the user but not impossible to maintain or develop. This 
type of information can be communicated through a mix of several illustrations 
with supporting text.

This first meeting started with some detailed discussion of the configuration 
inputs for a typical YP build but soon migrated to discussing the bigger 
picture and possible ways to provide more information.  It became obvious we 
were not going to dig the solution and all the needed information out in one 
short meeting. Consequently, I am sending out this email to help open up some 
discussion on the issue and to also solicit information for some basic blocks 
of information.

Two things are needed at this point:  1) a presentation solution for this new 
and more detailed information, and 2) a starting point on some of the 
information itself.  

PRESENTATION SOLUTION

Here are some thoughts on how to present this information.  There are 
disadvantages and advantages to each of these methods of which I will not list. 
 I would like to see what people think about them:

 * Manual - Create a section in the "Technical Details" Chapter of the YP 
Reference Manual that holds this information.  The section would be pretty much 
self-contained and would consist of several illustrations that would stem from 
an overall figure that is similar to the figure we now have in the YP Quick 
Start.  However, we would use a drill-down strategy that would progressively 
reveal more detail through subsequent figures.  This method is similar to how 
hardware devices used to be documented where functional blocks would be 
connected and described in one area and then subsequent areas would elaborate 
more deeply on a particular block.  Linking within the manual could connect up 
the various functional blocks (inputs, outputs, and tasks) that comprise the 
overall flow.

* Manual / Website Mix - Devise a mix between the YP Reference Manual and some 
pages in the YP Website that provide the information.  Create a section in the 
"Technical details" Chapter of the YP Reference Manual that covers this 
information at a high level.  For example, the overall flow of the system with 
its "big-block" inputs and outputs and tasks could be discussed at some length. 
 Links in the text could go to the YP website where more detail would be 
revealed.  This strategy effectively splits the content into "overview" and 
"details" between the manual and website, respectively.  

* Website - With this strategy, everything is pretty much in the YP website.  
This area would exist in a stand-alone fashion.  However, you could link to the 
website from within the existing YP documentation set from existing areas that 
deal with the build process.  Several exit points from within the manual set 
already exist.  We would obviously add a primary one as well that would likely 
originate from the YP Reference Manual's "Technical Details" Chapter.

SOLICITATION FOR INFORMATION

We can get started now on this by starting to define details for some obvious 
points or large areas of the flow.  What would be nice to get would be some 
graphical breakdowns of these areas of concern:

* User-defined layers
* YP provided layers
* User configuration
* Machine Configuration
* Policy Configuration
* Patches
* YP provided recipes
* User provided source code
* YP provided source code
* SCMs
* Generated images
* Generated SDKs/toolchains
* Package Output
* Source fetching process
* Patch application process
* Configuration process (fragments, etc.)
* Key variable use and effects
* User-initiated commands along the way

Much of this list

Re: [yocto] Toolchain... Issues with systemd (probably)

2013-06-20 Thread DAMARLA Satya Swaroop

Yeah.. I checked it and its true. In the errror its totally different issue

*| The following packages have unmet dependencies:*
*|  udev-dev : Depends: udev (= 182-r7) but 1:204-r0 is to be installed*
*| Recommends: libusb-dev but it is not installable*
*| Recommends: module-init-tools-dev but it is not installable*
*| Recommends: libkmod-dev but it is not installable*
*| E: Unable to correct problems, you have held broken packages.*
*| DEBUG: Python function do_populate_sdk finished*
*| ERROR: Function failed: populate_sdk_image (log file is located at
/home/damarla/openYocto/poky/buildSmartCPUsystemd/tmp/work/smartcpu-poky-linux-gnueabi/rootfs-smartcpu-sdk/1.0-r0/temp/log.do_populate_sdk.6675)
*
*ERROR: Task 10
(/home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/
rootfs-smartcpu-sdk.bb, do_populate_sdk) failed with exit code '1'*
*NOTE: Tasks Summary: Attempted 4961 tasks of which 4596 didn't need to be
rerun and 1 failed.*

The udev version to ve installed is 182-r7 bu I dont understand why
1:204-r0 is trying to get installed..


On Thu, Jun 20, 2013 at 10:31 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Thursday 20 June 2013 00:29:23 Khem Raj wrote:
> > On Jun 20, 2013, at 12:12 AM, DAMARLA Satya Swaroop
> >  wrote:
> > > Any reasons why toolchains compile wihtout any issues on sysvinit and
> not
> > > with systemd?
> > >
> > >
> > > On Wed, Jun 19, 2013 at 3:11 PM, DAMARLA Satya Swaroop
> > >  wrote: Yes... I thought the same and so, I
> > > made two build directories , one for sysvinit and the other for systemd
> > > and the errors I get abosulte no error when I try to populate_sdk under
> > > sysvinit but I get the following errors when I run the same under
> > > systemd.>
> > > | The following packages have unmet dependencies:
> > > |  udev-dev : Depends: udev (= 182-r7) but 1:204-r0 is to be installed
> > > |
> > > | Recommends: libusb-dev but it is not installable
> > > | Recommends: module-init-tools-dev but it is not
> installable
> > > | Recommends: libkmod-dev but it is not installable
> > > |
> > > | E: Unable to correct problems, you have held broken packages.
> >
> > it seems you did not choose systemd as provider for udev. You should do
> that
> > when you use systemd
>
> default-providers.inc already does this so you should not need to:
>
> meta/conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_udev ?=
> "${@base_contains('DISTRO_FEATURES','systemd','systemd','udev',d)}"
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Toolchain... Issues with systemd (probably)

2013-06-20 Thread Burton, Ross

On 20 June 2013 10:07, DAMARLA Satya Swaroop  wrote:
> The udev version to ve installed is 182-r7 bu I dont understand why 1:204-r0
> is trying to get installed..

This is because your deploy directory contains the systemd "udev"
package, which is version 204 and so newer than the sysvinit "udev"
package, version 182.  This is why we say that switching distro
features in an existing build directory isn't supported.

If you delete your tmp directory it will rebuild everything quickly
using the sstate-cache (don't delete that!).

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

Re: [yocto] Installing .deb file in Build

2013-06-20 Thread Paul Eggleton

On Wednesday 19 June 2013 09:10:20 DAMARLA Satya Swaroop wrote:
> I have a .deb file which has to be installed. It installs properly on the
> target image but I want to install it at the build itself by creating a
> bitbake recipe.. Is it possible to install .deb files or not? If possible,
> please suggest me so that I can make it..

I think the bin_package class is designed explicitly to help with this. Have a 
look at classes/bin_package.bbclass.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] core-image-x11 works on QEMU and not on real hardware

2013-06-20 Thread Burton, Ross

On 19 June 2013 13:33, Alex M <0xf...@gmail.com> wrote:
> I just built core-image-x11 and able to run it on qemux86, but all my
> attempts to run image on real hardware with nVidia GTX465 or AMD
> HD6320 - failed. In X11 logs I see errors about GLX module.
>
> What I should do to add GLX and OpenGL 2.1 3D acceleration with Mesa
> and opensource drivers for nVidia, Intel and AMD cards at the same
> time?

Details of the errors are always useful.  We don't have a machine
(yet) that supported nVidia or AMD hardware out of the box which is
why it's probably not working very well, so you'll have to add the
Mesa drivers to the image yourself, such as mesa-driver-radeon or
mesa-driver-nouveau-vieux.

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

Re: [yocto] Build doesn't interrupt cleanly

2013-06-20 Thread Gary Thomas


On 2013-06-20 06:22, Gary Thomas wrote:

Using Yocto master (1dd643b142c69ac9035e29bff11d02201638dc65)

I forcefully interrupted a bitbake build with ^C^C.  When it
shut down, I made some changes to my local.conf and then tried
to fire it up again, only to get this error:
   ERROR: Only one copy of bitbake should be run against a build directory

It looks like bitbake didn't totally get cleaned up in this case.
   $ ps ax | grep bit
   16319 pts/4S  0:01 python 
/home/local/poky-multi/bitbake/bin/bitbake-worker decafbad

Killing this left over worker let me continue.

I've never seen this before, so perhaps it's new behaviour.
If it happens again, I'll file a bug.



Looks like this was reported as bug #4750 only yesterday :-)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Toolchain... Issues with systemd (probably)

2013-06-20 Thread DAMARLA Satya Swaroop

I think you guys are right and now I am able to build the toolchain
perfectly


On Thu, Jun 20, 2013 at 12:06 PM, Burton, Ross wrote:

> On 20 June 2013 10:07, DAMARLA Satya Swaroop 
> wrote:
> > The udev version to ve installed is 182-r7 bu I dont understand why
> 1:204-r0
> > is trying to get installed..
>
> This is because your deploy directory contains the systemd "udev"
> package, which is version 204 and so newer than the sysvinit "udev"
> package, version 182.  This is why we say that switching distro
> features in an existing build directory isn't supported.
>
> If you delete your tmp directory it will rebuild everything quickly
> using the sstate-cache (don't delete that!).
>
> Ross
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] No crosscompiler in Toolchain

2013-06-20 Thread DAMARLA Satya Swaroop

This thread is closed as I have identified that the error is becuase of
issues concerned with using the same build environment for two build , one
that uses sysvinit and the other that uses systemd So, I deleted the *
tmp* and rebuild the toolchain and it got solved..


On Fri, Jun 14, 2013 at 7:40 PM, Zhang, Jessica wrote:

>  Hi Satya,
>
> ** **
>
> If bitbake meta_toolchain didn’t generate the correct cross compiler, then
> it’s a bug, would you mind open a bug in bugzilla.yoctoproject.org for us
> with detailed info e.g. what release, what are the cross toolchain that you
> were trying to build, etc?  As to your image particular toolchain, since
> we’re lacking the data how you customize your image, it’s really hard for
> us to nail down your issue unfortunately.
>
> ** **
>
> Thanks,
>
> Jessica
>
> ** **
>
> *From:* DAMARLA Satya Swaroop [mailto:satyaswaroop.dama...@gmail.com]
> *Sent:* Friday, June 14, 2013 4:21 AM
> *To:* Zhang, Jessica
> *Cc:* Jeff Osier-Mixon; yocto@yoctoproject.org
>
> *Subject:* Re: [yocto] No crosscompiler in Toolchain
>
> ** **
>
> Hi Everyone,
>
> ** **
>
> I solved the issue, but I don't know if its right or wrong but for the
> moment I am happy... The following didnot work for me
>
> ** **
>
> *bitbake core-image-skidata -c populate_sdk*
>
> *  *nor
>
> *bitbake meta-toolchain*
>
> ** **
>
> but *bitbake meta-toolchain-sdk * worked for me and created a toolchain
> with the crosscompiler... I have no idea why the others didnot create a
> toolchain with cross compiler for me. I think this has to be discussed in
> more detail..
>
> ** **
>
> For now have a wonderful weekend
>
> ** **
>
> Warm regards from Austria,
>
> Satya
>
> ** **
>
> On Thu, Jun 13, 2013 at 9:16 AM, DAMARLA Satya Swaroop <
> satyaswaroop.dama...@gmail.com> wrote:
>
> Hi,
>
> ** **
>
> Any updates on this issue why there is no cross compiler in the toolchain
> we build... I think this is pretty important unfortunately I am not able to
> find the cause.. Help is deeply appreciated..
>
> ** **
>
> Greets,
>
> Satya
>
> ** **
>
> On Wed, Jun 12, 2013 at 7:12 AM, DAMARLA Satya Swaroop <
> satyaswaroop.dama...@gmail.com> wrote:
>
> Hi Jessica,
>
> ** **
>
> By the sentence "No crosscompiler for my target installed in my
> toolchain", I mean I don't find the binaries for crosscompiling which are
> usually present in the directory as shown below
>
> ** **
>
> *damarla@linuxbuildsrv:~/yocto/myToolchain/sysroots/x86_64-pokysdk-linux/usr/bin$
> ls*
>
> *aclocalautoreconfflash2raw.terrier   opkg-key
>  pseudolog  qemu-mipsel   qemu-system-mipsel  raw2flash.terrier
>  runqemu-ifup*
>
> *aclocal-1.12   autoscan  gnu-configize   perl
>  qemu-arm   qemu-mips.realqemu-system-ppc runqemu
>  runqemu-internal*
>
> *autoconf   autoupdateifnames perl5.14.3
>  qemu-gaqemu-nbd  qemu-system-x86_64  runqemu-addptable2image
>  tunctl*
>
> *autoheader dtc   libtoolize  perl.real
> qemu-i386  qemu-ppc  qemu-x86_64 runqemu-export-rootfs
>  update-alternatives*
>
> *autom4te   flash2raw.akita   m4  pkg-config
>  qemu-img   qemu-system-arm   raw2flash.akita runqemu-extract-sdk
>  x86_64-pokysdk-linux-libtool*
>
> *automake   flash2raw.borzoi  oe-find-native-sysroot  pseudo
>  qemu-ioqemu-system-i386  raw2flash.borzoirunqemu-gen-tapdevs*
>
> *automake-1.12  flash2raw.spitz   opkg-cl pseudodb
>  qemu-mips  qemu-system-mips  raw2flash.spitz runqemu-ifdown*
>
> ** **
>
> ** **
>
> I don't have a directory and the list is empty
>
> ** **
>
> *damarla@linuxbuildsrv:~/yocto/myToolchain/sysroots/x86_64-pokysdk-linux/usr/bin$
> ls -la| egrep '^d'*
>
> *drwxr-xr-x 2 damarla damarla4096 Jun 11 14:27 .*
>
> *drwxr-xr-x 7 damarla damarla4096 Jun 11 14:15 ..*
>
> ** **
>
> I want to know what could be the potential issue that my toolchain has no
> crosscompiler for my target
>
> ** **
>
> Greets,
>
> Satya
>
> ** **
>
> On Tue, Jun 11, 2013 at 9:05 PM, Zhang, Jessica 
> wrote:
>
> Hi Satya,
>
>  
>
> What is your cross compiler that you said it’s not installed? For example,
> on my development host e.g. x86, after I install the toolchain, there’s an
> environment-setup-*** file, inside it specifies what is your cross
> compiler, e.g. arm-poky-linux-gnueabi-gcc for my case, after I source the
> environment file, and do which arm-poky-linux-gnueabi-gcc, I can see it’s
> under
> path_to_toolchain/sysroots/i686_pokysdk_linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc…
> so you’re seeing things differently?
>
>  
>
> Jessica
>
>  
>
> *From:* yocto-boun...@yoctoproject.org [mailto:
> yocto-boun...@yoctoproject.org] *On Behalf Of *DAMARLA Satya Swaroop

Re: [yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Bruce Ashfield

On 13-06-20 04:40 AM, Rifenbark, Scott M wrote:

Hi,

Recently, Paul, Ross, Richard and I had a video conference meeting where we had some initial
discussion on how to satisfy YOCTO #2808 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2808),
which calls for an illustration showing source and destination directories during a build using YP.
This bug originated from a discussion Dave Stewart and I had a while back around an idea of a more
detailed "flow diagram" that would go into greater detail than the now famous and
ubiquitous "The Yocto Project Development Environment" illustration, which appears in the
YP Quick Start (http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html) and
has been used in many other places and in many other forms (some quite elaborate).

We can't really create a completely accurate, all-encompassing illustration
that breaks apart the entire build process. It is not a static thing and it is
quite complicated inside the BitBake process. We can, however, show where
metadata comes from, how it is provided, what it defines, where and how source
files are found, what processes occur, what output is produced, and where it
ends up. We can also provide some sort of idea of how key BitBake and
environment variables affect things along the way. The idea here is to dig
deeper into this conceptual figure and root out the details to a level that
would be useful to the user but not impossible to maintain or develop. This
type of information can be communicated through a mix of several illustrations
with supporting text.

This first meeting started with some detailed discussion of the configuration
inputs for a typical YP build but soon migrated to discussing the bigger
picture and possible ways to provide more information. It became obvious we
were not going to dig the solution and all the needed information out in one
short meeting. Consequently, I am sending out this email to help open up some
discussion on the issue and to also solicit information for some basic blocks
of information.

Two things are needed at this point: 1) a presentation solution for this new
and more detailed information, and 2) a starting point on some of the
information itself.

PRESENTATION SOLUTION

Here are some thoughts on how to present this information. There are
disadvantages and advantages to each of these methods of which I will not list.
I would like to see what people think about them:

* Manual - Create a section in the "Technical Details" Chapter of the YP
Reference Manual that holds this information. The section would be pretty much
self-contained and would consist of several illustrations that would stem from an overall
figure that is similar to the figure we now have in the YP Quick Start. However, we
would use a drill-down strategy that would progressively reveal more detail through
subsequent figures. This method is similar to how hardware devices used to be documented
where functional blocks would be connected and described in one area and then subsequent
areas would elaborate more deeply on a particular block. Linking within the manual could
connect up the various functional blocks (inputs, outputs, and tasks) that comprise the
overall flow.

* Manual / Website Mix - Devise a mix between the YP Reference Manual and some pages in the YP Website that provide the
information. Create a section in the "Technical details" Chapter of the YP Reference Manual that covers this
information at a high level. For example, the overall flow of the system with its "big-block" inputs and
outputs and tasks could be discussed at some length. Links in the text could go to the YP website where more detail
would be revealed. This strategy effectively splits the content into "overview" and "details"
between the manual and website, respectively.

* Website - With this strategy, everything is pretty much in the YP website. This area
would exist in a stand-alone fashion. However, you could link to the website from within
the existing YP documentation set from existing areas that deal with the build process.
Several exit points from within the manual set already exist. We would obviously add a
primary one as well that would likely originate from the YP Reference Manual's
"Technical Details" Chapter.

SOLICITATION FOR INFORMATION

We can get started now on this by starting to define details for some obvious
points or large areas of the flow. What would be nice to get would be some
graphical breakdowns of these areas of concern:

* User-defined layers
* YP provided layers
* User configuration
* Machine Configuration
* Policy Configuration
* Patches
* YP provided recipes
* User provided source code
* YP provided source code
* SCMs
* Generated images
* Generated SDKs/toolchains
* Package Output
* Source fetching process
* Patch application process
* Configuration process (fragments, etc.)

Hi Scott,

Just so I'm clear .. are you looking

Re: [yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Richard Purdie

On Thu, 2013-06-20 at 09:49 -0400, Bruce Ashfield wrote:
> On 13-06-20 04:40 AM, Rifenbark, Scott M wrote:
> > Hi,
> >
> > Recently, Paul, Ross, Richard and I had a video conference meeting where we 
> > had some initial discussion on how to satisfy YOCTO #2808 
> > (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2808), which calls for 
> > an illustration showing source and destination directories during a build 
> > using YP.  This bug originated from a discussion Dave Stewart and I had a 
> > while back around an idea of a more detailed "flow diagram" that would go 
> > into greater detail than the now famous and ubiquitous "The Yocto Project 
> > Development Environment" illustration, which appears in the YP Quick Start 
> > (http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html)
> >  and has been used in many other places and in many other forms (some quite 
> > elaborate).
> >
> > We can't really create a completely accurate, all-encompassing illustration 
> > that breaks apart the entire build process.  It is not a static thing and 
> > it is quite complicated inside the BitBake process.  We can, however, show 
> > where metadata comes from, how it is provided, what it defines, where and 
> > how source files are found, what processes occur, what output is produced, 
> > and where it ends up.  We can also provide some sort of idea of how key 
> > BitBake and environment variables affect things along the way.  The idea 
> > here is to dig deeper into this conceptual figure and root out the details 
> > to a level that would be useful to the user but not impossible to maintain 
> > or develop. This type of information can be communicated through a mix of 
> > several illustrations with supporting text.
> >
> > This first meeting started with some detailed discussion of the 
> > configuration inputs for a typical YP build but soon migrated to discussing 
> > the bigger picture and possible ways to provide more information.  It 
> > became obvious we were not going to dig the solution and all the needed 
> > information out in one short meeting. Consequently, I am sending out this 
> > email to help open up some discussion on the issue and to also solicit 
> > information for some basic blocks of information.
> >
> > Two things are needed at this point:  1) a presentation solution for this 
> > new and more detailed information, and 2) a starting point on some of the 
> > information itself.
> >
> > PRESENTATION SOLUTION
> >
> > Here are some thoughts on how to present this information.  There
> are disadvantages and advantages to each of these methods of which I
> will not list.  I would like to see what people think about them:
> >
> >   * Manual - Create a section in the "Technical Details" Chapter of
> the YP Reference Manual that holds this information.  The section
> would be pretty much self-contained and would consist of several
> illustrations that would stem from an overall figure that is similar
> to the figure we now have in the YP Quick Start.  However, we would
> use a drill-down strategy that would progressively reveal more detail
> through subsequent figures.  This method is similar to how hardware
> devices used to be documented where functional blocks would be
> connected and described in one area and then subsequent areas would
> elaborate more deeply on a particular block.  Linking within the
> manual could connect up the various functional blocks (inputs,
> outputs, and tasks) that comprise the overall flow.
> >
> > * Manual / Website Mix - Devise a mix between the YP Reference
> Manual and some pages in the YP Website that provide the information.
> Create a section in the "Technical details" Chapter of the YP
> Reference Manual that covers this information at a high level.  For
> example, the overall flow of the system with its "big-block" inputs
> and outputs and tasks could be discussed at some length.  Links in the
> text could go to the YP website where more detail would be revealed.
> This strategy effectively splits the content into "overview" and
> "details" between the manual and website, respectively.
> >
> > * Website - With this strategy, everything is pretty much in the YP
> website.  This area would exist in a stand-alone fashion.  However,
> you could link to the website from within the existing YP
> documentation set from existing areas that deal with the build
> process.  Several exit points from within the manual set already
> exist.  We would obviously add a primary one as well that would likely
> originate from the YP Reference Manual's "Technical Details" Chapter.

I'm wondering if a hybrid is possible here. Can we for example embed
image maps into the docbook so that if you hover over areas of the
image, you can then have links to the different sections?

> > SOLICITATION FOR INFORMATION
> >
> > We can get started now on this by starting to define details for
> some obvious points or large areas of the flow.  What would be nice to
> ge

Re: [yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Bruce Ashfield

On 13-06-20 10:25 AM, Richard Purdie wrote:

On Thu, 2013-06-20 at 09:49 -0400, Bruce Ashfield wrote:

On 13-06-20 04:40 AM, Rifenbark, Scott M wrote:

Hi,

Two things are needed at this point: 1) a presentation solution for this new
and more detailed information, and 2) a starting point on some of the
information itself.

PRESENTATION SOLUTION

Here are some thoughts on how to present this information. There

are disadvantages and advantages to each of these methods of which I
will not list. I would like to see what people think about them:

* Manual - Create a section in the "Technical Details" Chapter of

the YP Reference Manual that holds this information. The section
would be pretty much self-contained and would consist of several
illustrations that would stem from an overall figure that is similar
to the figure we now have in the YP Quick Start. However, we would
use a drill-down strategy that would progressively reveal more detail
through subsequent figures. This method is similar to how hardware
devices used to be documented where functional blocks would be
connected and described in one area and then subsequent areas would
elaborate more deeply on a particular block. Linking within the
manual could connect up the various functional blocks (inputs,
outputs, and tasks) that comprise the overall flow.

* Manual / Website Mix - Devise a mix between the YP Reference

Manual and some pages in the YP Website that provide the information.
Create a section in the "Technical details" Chapter of the YP
Reference Manual that covers this information at a high level. For
example, the overall flow of the system with its "big-block" inputs
and outputs and tasks could be discussed at some length. Links in the
text could go to the YP website where more detail would be revealed.
This strategy effectively splits the content into "overview" and
"details" between the manual and website, respectively.

* Website - With this strategy, everything is pretty much in the YP

website. This area would exist in a stand-alone fashion. However,
you could link to the website from within the existing YP
documentation set from existing areas that deal with the build
process. Several exit points from within the manual set already
exist. We would obviously add a primary one as well that would likely
originate from the YP Reference Manual's "Technical Details" Chapter.

I'm wondering if a hybrid is possible here. Can we for example embed
image maps into the docbook so that if you hover over areas of the
image, you can then have links to the different sections?

SOLICITATION FOR INFORMATION

We can get started now on this by starting to define details for

some obvious points or large areas of the flow. What would be nice to
get would be some graphical breakdowns of these areas of concern:

* User-defined layers
* YP provided layers
* User configuration
* Machine Configuration
* Policy Configuration
* Patches
* YP pr

Re: [yocto] This one can't be me...

2013-06-20 Thread Darren Hart



On 04/04/2013 12:14 PM, Bodke, Kishore K wrote:

> Hi Bruce/Darren,
> 
> I do not see Linux-yocto-3.0 kernel branch in git repo.
> Is it no longer available?
> Cedartrail BSP for 1.3 Yocto (danny) supports only 3.0 kernel.
> 
> I am not sure how Paul is able to build this bsp?
> 

Do you mean you don't see the linux-yocto-3.0 recipe? It was removed in
later releases, but is still available in danny.


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Bill Traynor

On Thu, Jun 20, 2013 at 10:25 AM, Richard Purdie
 wrote:
> On Thu, 2013-06-20 at 09:49 -0400, Bruce Ashfield wrote:
>> On 13-06-20 04:40 AM, Rifenbark, Scott M wrote:
>> > Hi,
>> >
>> > Recently, Paul, Ross, Richard and I had a video conference meeting where 
>> > we had some initial discussion on how to satisfy YOCTO #2808 
>> > (https://bugzilla.yoctoproject.org/show_bug.cgi?id=2808), which calls for 
>> > an illustration showing source and destination directories during a build 
>> > using YP.  This bug originated from a discussion Dave Stewart and I had a 
>> > while back around an idea of a more detailed "flow diagram" that would go 
>> > into greater detail than the now famous and ubiquitous "The Yocto Project 
>> > Development Environment" illustration, which appears in the YP Quick Start 
>> > (http://www.yoctoproject.org/docs/1.4/yocto-project-qs/yocto-project-qs.html)
>> >  and has been used in many other places and in many other forms (some 
>> > quite elaborate).
>> >
>> > We can't really create a completely accurate, all-encompassing 
>> > illustration that breaks apart the entire build process.  It is not a 
>> > static thing and it is quite complicated inside the BitBake process.  We 
>> > can, however, show where metadata comes from, how it is provided, what it 
>> > defines, where and how source files are found, what processes occur, what 
>> > output is produced, and where it ends up.  We can also provide some sort 
>> > of idea of how key BitBake and environment variables affect things along 
>> > the way.  The idea here is to dig deeper into this conceptual figure and 
>> > root out the details to a level that would be useful to the user but not 
>> > impossible to maintain or develop. This type of information can be 
>> > communicated through a mix of several illustrations with supporting text.
>> >
>> > This first meeting started with some detailed discussion of the 
>> > configuration inputs for a typical YP build but soon migrated to 
>> > discussing the bigger picture and possible ways to provide more 
>> > information.  It became obvious we were not going to dig the solution and 
>> > all the needed information out in one short meeting. Consequently, I am 
>> > sending out this email to help open up some discussion on the issue and to 
>> > also solicit information for some basic blocks of information.
>> >
>> > Two things are needed at this point:  1) a presentation solution for this 
>> > new and more detailed information, and 2) a starting point on some of the 
>> > information itself.
>> >
>> > PRESENTATION SOLUTION
>> >
>> > Here are some thoughts on how to present this information.  There
>> are disadvantages and advantages to each of these methods of which I
>> will not list.  I would like to see what people think about them:
>> >
>> >   * Manual - Create a section in the "Technical Details" Chapter of
>> the YP Reference Manual that holds this information.  The section
>> would be pretty much self-contained and would consist of several
>> illustrations that would stem from an overall figure that is similar
>> to the figure we now have in the YP Quick Start.  However, we would
>> use a drill-down strategy that would progressively reveal more detail
>> through subsequent figures.  This method is similar to how hardware
>> devices used to be documented where functional blocks would be
>> connected and described in one area and then subsequent areas would
>> elaborate more deeply on a particular block.  Linking within the
>> manual could connect up the various functional blocks (inputs,
>> outputs, and tasks) that comprise the overall flow.
>> >
>> > * Manual / Website Mix - Devise a mix between the YP Reference
>> Manual and some pages in the YP Website that provide the information.
>> Create a section in the "Technical details" Chapter of the YP
>> Reference Manual that covers this information at a high level.  For
>> example, the overall flow of the system with its "big-block" inputs
>> and outputs and tasks could be discussed at some length.  Links in the
>> text could go to the YP website where more detail would be revealed.
>> This strategy effectively splits the content into "overview" and
>> "details" between the manual and website, respectively.
>> >
>> > * Website - With this strategy, everything is pretty much in the YP
>> website.  This area would exist in a stand-alone fashion.  However,
>> you could link to the website from within the existing YP
>> documentation set from existing areas that deal with the build
>> process.  Several exit points from within the manual set already
>> exist.  We would obviously add a primary one as well that would likely
>> originate from the YP Reference Manual's "Technical Details" Chapter.
>
> I'm wondering if a hybrid is possible here. Can we for example embed
> image maps into the docbook so that if you hover over areas of the
> image, you can then have links to the different sections?

FWIW, docbook supports image maps via the

Re: [yocto] [PATCH] ecryptfs-utils: Modify systemd service file to 'simple'.

2013-06-20 Thread Mikhail Durnev

ecryptfsd is a resident program, i.e. daemon. According to systemd
documentation, Type=oneshot/RemainAfterExit=yes should be used for programs
that do not remain working after exit. But for daemons we should use
Type=forked to indicate that the service remains running in background.
ecryptfs provides option -f to run in foreground. This option is preferred
when the service is started from init/systemd. That is why we use
Type=simple (default) to indicate that the service runs in foreground. To
manage the service properly systemd uses its type. E.g. if ecryptfsd
silently dies, systemd will recognize its failure in case of simple or
forked, but not in case of oneshot.

Best regards,
Mikhail

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Thursday, 20 June, 2013 13:32
To: Noor, Ahsan
Cc: holger.behr...@windriver.com; florin.sa...@windriver.com;
yocto@yoctoproject.org; Mikhail Durnev
Subject: Re: [yocto] [PATCH] ecryptfs-utils: Modify systemd service file to
'simple'.

reasoning why it is being turned into simple service would be nice

On Jun 19, 2013, at 3:53 AM, "Noor, Ahsan"  wrote:

> From: Noor 
> 
> Signed-off-by: Mikhail Durnev 
> Signed-off-by: Noor Ahsan 
> ---
> .../ecryptfs-utils/ecryptfs-utils/ecryptfs.service |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git 
> a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.service 
> b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.service
> index ba12aa3..52f3397 100644
> --- 
> a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.service
> +++ b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.servi
> +++ ce
> @@ -3,9 +3,7 @@ Description=A userspace daemon that runs as the user 
> perform file operations und After=udev.service
> 
> [Service]
> -Type=oneshot
> -ExecStart=/usr/bin/ecryptfsd
> -RemainAfterExit=yes
> +ExecStart=/usr/bin/ecryptfsd -f
> 
> [Install]
> WantedBy=multi-user.target
> --
> 1.7.9.5
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Rifenbark, Scott M



>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Bill Traynor
>Sent: Thursday, June 20, 2013 8:12 AM
>To: Richard Purdie
>Cc: yocto@yoctoproject.org; Paul Eggleton; Osier-mixon, Jeffrey
>Subject: Re: [yocto] Documenting YP Development Environment in more
>detail
>
>On Thu, Jun 20, 2013 at 10:25 AM, Richard Purdie
> wrote:
>> On Thu, 2013-06-20 at 09:49 -0400, Bruce Ashfield wrote:
>>> On 13-06-20 04:40 AM, Rifenbark, Scott M wrote:
>>> > Hi,
>>> >
>>> > Recently, Paul, Ross, Richard and I had a video conference meeting
>where we had some initial discussion on how to satisfy YOCTO #2808
>(https://bugzilla.yoctoproject.org/show_bug.cgi?id=2808), which calls
>for an illustration showing source and destination directories during a
>build using YP.  This bug originated from a discussion Dave Stewart and
>I had a while back around an idea of a more detailed "flow diagram" that
>would go into greater detail than the now famous and ubiquitous "The
>Yocto Project Development Environment" illustration, which appears in
>the YP Quick Start (http://www.yoctoproject.org/docs/1.4/yocto-project-
>qs/yocto-project-qs.html) and has been used in many other places and in
>many other forms (some quite elaborate).
>>> >
>>> > We can't really create a completely accurate, all-encompassing
>illustration that breaks apart the entire build process.  It is not a
>static thing and it is quite complicated inside the BitBake process.  We
>can, however, show where metadata comes from, how it is provided, what
>it defines, where and how source files are found, what processes occur,
>what output is produced, and where it ends up.  We can also provide some
>sort of idea of how key BitBake and environment variables affect things
>along the way.  The idea here is to dig deeper into this conceptual
>figure and root out the details to a level that would be useful to the
>user but not impossible to maintain or develop. This type of information
>can be communicated through a mix of several illustrations with
>supporting text.
>>> >
>>> > This first meeting started with some detailed discussion of the
>configuration inputs for a typical YP build but soon migrated to
>discussing the bigger picture and possible ways to provide more
>information.  It became obvious we were not going to dig the solution
>and all the needed information out in one short meeting. Consequently, I
>am sending out this email to help open up some discussion on the issue
>and to also solicit information for some basic blocks of information.
>>> >
>>> > Two things are needed at this point:  1) a presentation solution
>for this new and more detailed information, and 2) a starting point on
>some of the information itself.
>>> >
>>> > PRESENTATION SOLUTION
>>> >
>>> > Here are some thoughts on how to present this information.  There
>>> are disadvantages and advantages to each of these methods of which I
>>> will not list.  I would like to see what people think about them:
>>> >
>>> >   * Manual - Create a section in the "Technical Details" Chapter of
>>> the YP Reference Manual that holds this information.  The section
>>> would be pretty much self-contained and would consist of several
>>> illustrations that would stem from an overall figure that is similar
>>> to the figure we now have in the YP Quick Start.  However, we would
>>> use a drill-down strategy that would progressively reveal more detail
>>> through subsequent figures.  This method is similar to how hardware
>>> devices used to be documented where functional blocks would be
>>> connected and described in one area and then subsequent areas would
>>> elaborate more deeply on a particular block.  Linking within the
>>> manual could connect up the various functional blocks (inputs,
>>> outputs, and tasks) that comprise the overall flow.
>>> >
>>> > * Manual / Website Mix - Devise a mix between the YP Reference
>>> Manual and some pages in the YP Website that provide the information.
>>> Create a section in the "Technical details" Chapter of the YP
>>> Reference Manual that covers this information at a high level.  For
>>> example, the overall flow of the system with its "big-block" inputs
>>> and outputs and tasks could be discussed at some length.  Links in
>the
>>> text could go to the YP website where more detail would be revealed.
>>> This strategy effectively splits the content into "overview" and
>>> "details" between the manual and website, respectively.
>>> >
>>> > * Website - With this strategy, everything is pretty much in the YP
>>> website.  This area would exist in a stand-alone fashion.  However,
>>> you could link to the website from within the existing YP
>>> documentation set from existing areas that deal with the build
>>> process.  Several exit points from within the manual set already
>>> exist.  We would obviously add a primary one as well that would
>likely
>>> originate from the YP Reference Manual's "Technical Details" C

[yocto] [PATCH] Fix Eclipse workspace deadlock when restoring

2013-06-20 Thread Ioana Grigoropol

From: Ioana Grigoropol 

- when creating a new bitbake commander project, a bunch of information 
relevant for the project is set in the project information map
- when closing & restarting Eclipse, having a Bitbake commander project in the 
workspace an deadlock occurs due to the following:
- Eclipse Resources container tries to restore all projects that were 
previously in the workspace
- when trying to restore our BB project, we will try to determine what 
was the remote connection for that specific project, given its URI
- we can only determine the connection by calling RSE plugin & 
we must wait for it to be initialized
- the RSE plugin is initialized after the Resource container is 
finishes, and since this process is blocked waiting for a later one, a deadlock 
occurs

- in order to fix this problem, perform the following steps:
- when the Eclipse Resource container asks for the store of our project
- return a NullFileStore
- register as a listener of the RSEInitJob in order to get 
notified when the job is finished
- restore the project information when the RSE API is up by 
triggering the internal file system core manager
- restoring the information:
- for the local implementation:
- the connection of the project is missing -> retrive 
it by invoking RSE
- for the remote implementation:
- the only URI for the project is the oefs one
- we cannot change this uri to point to the real one 
since it will block the refresh on the project
- we cannot determine the real URI form the oefs one 
since we have no clue what is the host(ip)
   -> solution:
- when creating the BBC project
- save the information about the real URI of 
the project in the metadata of the workspace
- when restoring the project
- retrieve the information from the metadata 
location
- fixed also the Project Description of the Location to display the real URI of 
the files

Signed-off-by: Ioana Grigoropol 
---
 .../src/org/yocto/bc/bitbake/ShellSession.java |2 +-
 .../src/org/yocto/bc/ui/Activator.java |4 +-
 .../org/yocto/bc/ui/filesystem/OEFileSystem.java   |   10 +--
 .../src/org/yocto/bc/ui/model/ProjectInfo.java |   11 ++-
 .../src/org/yocto/bc/ui/model/YoctoHostFile.java   |   10 +++
 .../yocto/bc/ui/wizards/install/InstallWizard.java |1 +
 .../org.yocto.remote.utils/META-INF/MANIFEST.MF|6 +-
 .../src/org/yocto/remote/utils/RemoteHelper.java   |   77 
 8 files changed, 111 insertions(+), 10 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
index 11d677a..724b7d0 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
@@ -18,7 +18,7 @@ import java.io.InputStream;
 import java.io.InputStreamReader;
 import java.io.OutputStream;
 import java.io.Writer;
-
+   
 import org.eclipse.core.runtime.IProgressMonitor;
 import org.eclipse.core.runtime.NullProgressMonitor;
 import org.eclipse.rse.core.model.IHost;
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
index 5c43ba8..f53592c 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
@@ -108,7 +108,7 @@ public class Activator extends AbstractUIPlugin {

BBSession bbs = (BBSession) bbSessionMap.get(projectRoot);

-   if (bbs == null) {
+   if (bbs == null || bbs.getShell() == null) {
bbs = new BBSession(getShellSession(projectInfo, null, 
monitor), projectRoot);
bbSessionMap.put(projectRoot, bbs);
}
@@ -190,7 +190,7 @@ public class Activator extends AbstractUIPlugin {

ShellSession ss = (ShellSession) shellMap.get(absolutePath);

-   if (ss == null) {
+   if (ss == null && 
RemoteHelper.isInitialized(projInfo.getOriginalURI())) {
IHostFile remoteHostFile = 
RemoteHelper.getRemoteHostFile(projInfo.getConnection(), 
absolutePath.getPath(), monitor);
ss = new ShellSession(projInfo, remoteHostFile, 
ProjectInfoHelper.getInitScriptPath(absolutePath));
}
diff --git 
a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/filesystem/OEFileSystem.java 
b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/filesystem/OEFileSystem.java
index 357edc1..b814c4c 100644

Re: [yocto] Cedartrail and Dylan?

2013-06-20 Thread Paul D. DeRocco

> From: Tom Zanussi
> 
> I actually used yocto-bsp to create a brand new cedartrail BSP, called
> meta-cdt, with just a vesa graphics machine called 'cdt-vesa':
> 
>
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi
/meta-cdt-v0
> 
> It built fine here, but it wouldn't boot on my Aspire One, but I
> couldn't boot either of the official 'danny' cedartrail 
> (cedartrail and
> cedartrail-nopvr) images I built either.
> 
> I'd be curious if the meta-cdt layer would work for you, though.

This builds and boots fine on an Intel DN2800MT. Now to start modifying it,
and seeing what happens.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

[yocto] FW: cannot bitbake/build.compile tcf-agent for use with fsl-image-gui-sdk

2013-06-20 Thread Thanassis Silis

From: djnass...@hotmail.com
To: jessica.zh...@intel.com
Subject: RE: [yocto] cannot bitbake/build.compile tcf-agent for use with 
fsl-image-gui-sdk
Date: Thu, 20 Jun 2013 17:48:14 +

Hi jessica,
I will try with SSH too,
but for now it seems there are some bugs with "packages_deb " being the primary 
packaging scheme.
so apart from adding 
IMAGE_INSTALL_append = " tcf-agent"

moving "packages_rpm" to be the primary scheme ended up succeeding in making an 
image that had tcf-agent included.

Thank you for your help.
I will post back when I generate an image with openssh (I have dropbear enabled 
ATM). 

From: jessica.zh...@intel.com
To: djnass...@hotmail.com; meta-freesc...@yoctoproject.org; 
yocto@yoctoproject.org
Subject: RE: [yocto] cannot bitbake/build.compile tcf-agent for use with 
fsl-image-gui-sdk
Date: Wed, 19 Jun 2013 16:25:03 +

Hi Thanassis,

I don’t know why tcf-agent  is not included in your sdk image.  But you also 
can use ssh to create a rse remote connection that allows you to do remote 
interaction.
  When you create remote connection, instead of choosing tcf, use ssh.  You’ll 
need openssh in your target image for this to work.

Cheers,
Jessica

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Thanassis Silis

Sent: Tuesday, June 18, 2013 6:56 AM

To: meta-freesc...@yoctoproject.org; yocto@yoctoproject.org

Subject: [yocto] cannot bitbake/build.compile tcf-agent for use with 
fsl-image-gui-sdk

Hello everyone,

it seems tcf-agent is not provided. Not even in the -sdk image I created. And 
that is where my problems start:

using this in my local.conf: IMAGE_INSTALL_append = " tcf-agent"

I expected to be able to automate the process of generating the tcf-agent and 
deploying it in my image with command:
bitbake fsl-image-gui-sdk

this fails with:
| Reading package lists...

| Building dependency tree...

| Reading state information...

| Some packages could not be installed. This may mean that you have

| requested an impossible situation or if you are using the unstable

| distribution that some required packages have not yet been created

| or been moved out of Incoming.

| The following information may help to resolve the situation:

| 

| The following packages have unmet dependencies:

|  packagegroup-core-x11-base : Depends: packagegroup-core-x11-utils but it is 
not going to be installed

| W: Ignoring Provides line with DepCompareOp for package 
pkgconfig__pkg-config__

| W: You may want to run apt-get update to correct these problems

| E: Unable to correct problems, you have held broken packages.

| ERROR: Function failed: do_rootfs (see 
/home/nass/yocto/build/tmp/work/imx6qsabrelite-poky-linux-gnueabi/fsl-image-gui-sdk/1.0-r0/temp/log.do_rootfs.26945
 for further information)

ERROR: Task 7 
(/home/nass/yocto/sources/meta-fsl-demos/recipes-fsl/images/fsl-image-gui-sdk.bb,
 do_rootfs) failed with exit code '1'

NOTE: Tasks Summary: Attempted 7418 tasks of which 7417 didn't need to be rerun 
and 1 failed.

No currently running tasks (7417 of 7419)

Summary: 1 task failed:

/home/nass/yocto/sources/meta-fsl-demos/recipes-fsl/images/fsl-image-gui-sdk.bb,
 do_rootfs

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

I then went on to try and compile it manually:
bitbake fsl-image-gui-sdk -c compile tcf-agent

bitbake fsl-image-gui-sdk -c deploy

this fails with:
ERROR: Task do_deploy does not exist for target fsl-image-gui-sdk
Then I tried compiling it manually using this info

http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#getting-the-images
 , by sourcing my toolchain from /opt/poky/1.4.1/env* file, and then

runnning 'make' in org.eclipse.tcf.agent/agent/ . I explicitly assign the 
$MACHINE variable to be 'arm' in the beginning of the Makefile.inc.

this fails with
arm-poky-linux-gnueabi-gcc  -march=armv7-a -mthumb-interwork -mfloat-abi=softfp 
-mfpu=neon 
--sysroot=/opt/poky/1.4.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi 
 -O2 -pipe -g -feliminate-unused-debug-types -g -D_FILE_OFFSET_BITS=64 -Wall 
-Wmissing-prototypes -I./. -I./system/GNU/Linux -I./machine/arm -o 
obj/GNU/Linux/arm/Debug/tcf/framework/channel_tcp.o -c 
tcf/framework/channel_tcp.c

tcf/framework/channel_tcp.c:38:27: fatal error: openssl/ssl.h: No such file or 
directory

compilation terminated.

At this point I have run out of ideas about how to prepare tcf-agent to install 
on my sabrelite fsl-image-gui-sdk rootfs

Any help would be most welcome.

for example in the 1st case how could I run apt-get as is suggested in a manner 
that would be appropriate to update yocto sources?

Thank you.

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

Re: [yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Stewart, David C



On 6/20/13 8:23 AM, "Rifenbark, Scott M" 
wrote:

>
>
>>-Original Message-
>>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>>boun...@yoctoproject.org] On Behalf Of Bill Traynor
>>Sent: Thursday, June 20, 2013 8:12 AM
>>To: Richard Purdie
>>Cc: yocto@yoctoproject.org; Paul Eggleton; Osier-mixon, Jeffrey
>>Subject: Re: [yocto] Documenting YP Development Environment in more
>>detail
>>
>>On Thu, Jun 20, 2013 at 10:25 AM, Richard Purdie
>> wrote:
>>> On Thu, 2013-06-20 at 09:49 -0400, Bruce Ashfield wrote:
 On 13-06-20 04:40 AM, Rifenbark, Scott M wrote:
 > Hi,
 >
 > Recently, Paul, Ross, Richard and I had a video conference meeting
>>where we had some initial discussion on how to satisfy YOCTO #2808
>>(https://bugzilla.yoctoproject.org/show_bug.cgi?id=2808), which calls
>>for an illustration showing source and destination directories during a
>>build using YP.  This bug originated from a discussion Dave Stewart and
>>I had a while back around an idea of a more detailed "flow diagram" that
>>would go into greater detail than the now famous and ubiquitous "The
>>Yocto Project Development Environment" illustration, which appears in
>>the YP Quick Start (http://www.yoctoproject.org/docs/1.4/yocto-project-
>>qs/yocto-project-qs.html) and has been used in many other places and in
>>many other forms (some quite elaborate).
 >
 > We can't really create a completely accurate, all-encompassing
>>illustration that breaks apart the entire build process.  It is not a
>>static thing and it is quite complicated inside the BitBake process.  We
>>can, however, show where metadata comes from, how it is provided, what
>>it defines, where and how source files are found, what processes occur,
>>what output is produced, and where it ends up.  We can also provide some
>>sort of idea of how key BitBake and environment variables affect things
>>along the way.  The idea here is to dig deeper into this conceptual
>>figure and root out the details to a level that would be useful to the
>>user but not impossible to maintain or develop. This type of information
>>can be communicated through a mix of several illustrations with
>>supporting text.
 >
 > This first meeting started with some detailed discussion of the
>>configuration inputs for a typical YP build but soon migrated to
>>discussing the bigger picture and possible ways to provide more
>>information.  It became obvious we were not going to dig the solution
>>and all the needed information out in one short meeting. Consequently, I
>>am sending out this email to help open up some discussion on the issue
>>and to also solicit information for some basic blocks of information.

I would recommend that we don't over-engineer this thing if we can avoid
it.
Remember the goal: People have told me that they are confused about which
directories
are "active" in the build process, i.e. Where does stuff come from and
where does it go?
My advice would be to think of bitbake as a black box with inputs and
outputs.
I know that any directory could be *potentially* an input or output (why
else would it be there?)
But I'm hoping we can up level a little.

 >
 > Two things are needed at this point:  1) a presentation solution
>>for this new and more detailed information, and 2) a starting point on
>>some of the information itself.
 >
 > PRESENTATION SOLUTION
 >
 > Here are some thoughts on how to present this information.  There
 are disadvantages and advantages to each of these methods of which I
 will not list.  I would like to see what people think about them:
 >
 >   * Manual - Create a section in the "Technical Details" Chapter of
 the YP Reference Manual that holds this information.  The section
 would be pretty much self-contained and would consist of several
 illustrations that would stem from an overall figure that is similar
 to the figure we now have in the YP Quick Start.  However, we would
 use a drill-down strategy that would progressively reveal more detail
 through subsequent figures.  This method is similar to how hardware
 devices used to be documented where functional blocks would be
 connected and described in one area and then subsequent areas would
 elaborate more deeply on a particular block.  Linking within the
 manual could connect up the various functional blocks (inputs,
 outputs, and tasks) that comprise the overall flow.
 >
 > * Manual / Website Mix - Devise a mix between the YP Reference
 Manual and some pages in the YP Website that provide the information.
 Create a section in the "Technical details" Chapter of the YP
 Reference Manual that covers this information at a high level.  For
 example, the overall flow of the system with its "big-block" inputs
 and outputs and tasks could be discussed at some length.  Links in
>>the
 text could go to the YP website where more detail would be revealed.
 This strate

Re: [yocto] Cedartrail and Dylan?

2013-06-20 Thread Tom Zanussi

On Thu, 2013-06-20 at 10:26 -0700, Paul D. DeRocco wrote:
> > From: Tom Zanussi
> > 
> > I actually used yocto-bsp to create a brand new cedartrail BSP, called
> > meta-cdt, with just a vesa graphics machine called 'cdt-vesa':
> > 
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi
> /meta-cdt-v0
> > 
> > It built fine here, but it wouldn't boot on my Aspire One, but I
> > couldn't boot either of the official 'danny' cedartrail 
> > (cedartrail and
> > cedartrail-nopvr) images I built either.
> > 
> > I'd be curious if the meta-cdt layer would work for you, though.
> 
> This builds and boots fine on an Intel DN2800MT. Now to start modifying it,
> and seeing what happens.
> 

Great, glad to hear it!  Now I need to figure out what's going on with
the Aspire One, now that I know it should work..

Thanks,

Tom

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

Re: [yocto] Documenting YP Development Environment in more detail

2013-06-20 Thread Sean Liming




> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Stewart, David C
> Sent: Thursday, June 20, 2013 11:23 AM
> To: Rifenbark, Scott M; Bill Traynor; Richard Purdie
> Cc: yocto@yoctoproject.org; Paul Eggleton; Osier-mixon, Jeffrey
> Subject: Re: [yocto] Documenting YP Development Environment in more
> detail
> 
> 
> 
> On 6/20/13 8:23 AM, "Rifenbark, Scott M" 
> wrote:
> 
> >
> >
> >>-Original Message-
> >>From: yocto-boun...@yoctoproject.org [mailto:yocto-
> >>boun...@yoctoproject.org] On Behalf Of Bill Traynor
> >>Sent: Thursday, June 20, 2013 8:12 AM
> >>To: Richard Purdie
> >>Cc: yocto@yoctoproject.org; Paul Eggleton; Osier-mixon, Jeffrey
> >>Subject: Re: [yocto] Documenting YP Development Environment in more
> >>detail
> >>
> >>On Thu, Jun 20, 2013 at 10:25 AM, Richard Purdie
> >> wrote:
> >>> On Thu, 2013-06-20 at 09:49 -0400, Bruce Ashfield wrote:
>  On 13-06-20 04:40 AM, Rifenbark, Scott M wrote:
>  > Hi,
>  >
>  > Recently, Paul, Ross, Richard and I had a video conference
>  > meeting
> >>where we had some initial discussion on how to satisfy YOCTO #2808
> >>(https://bugzilla.yoctoproject.org/show_bug.cgi?id=2808), which calls
> >>for an illustration showing source and destination directories during
> >>a build using YP.  This bug originated from a discussion Dave Stewart
> >>and I had a while back around an idea of a more detailed "flow
> >>diagram" that would go into greater detail than the now famous and
> >>ubiquitous "The Yocto Project Development Environment" illustration,
> >>which appears in the YP Quick Start
> >>(http://www.yoctoproject.org/docs/1.4/yocto-project-
> >>qs/yocto-project-qs.html) and has been used in many other places and
> >>in many other forms (some quite elaborate).
>  >
>  > We can't really create a completely accurate, all-encompassing
> >>illustration that breaks apart the entire build process.  It is not a
> >>static thing and it is quite complicated inside the BitBake process.
> >>We can, however, show where metadata comes from, how it is provided,
> >>what it defines, where and how source files are found, what processes
> >>occur, what output is produced, and where it ends up.  We can also
> >>provide some sort of idea of how key BitBake and environment variables
> >>affect things along the way.  The idea here is to dig deeper into this
> >>conceptual figure and root out the details to a level that would be
> >>useful to the user but not impossible to maintain or develop. This
> >>type of information can be communicated through a mix of several
> >>illustrations with supporting text.
>  >
>  > This first meeting started with some detailed discussion of the
> >>configuration inputs for a typical YP build but soon migrated to
> >>discussing the bigger picture and possible ways to provide more
> >>information.  It became obvious we were not going to dig the solution
> >>and all the needed information out in one short meeting. Consequently,
> >>I am sending out this email to help open up some discussion on the
> >>issue and to also solicit information for some basic blocks of
information.
> 
> I would recommend that we don't over-engineer this thing if we can avoid
it.
> Remember the goal: People have told me that they are confused about
> which directories are "active" in the build process, i.e. Where does stuff
> come from and where does it go?
> My advice would be to think of bitbake as a black box with inputs and
> outputs.
> I know that any directory could be *potentially* an input or output (why
else
> would it be there?) But I'm hoping we can up level a little.
> 
>  >
>  > Two things are needed at this point:  1) a presentation solution
> >>for this new and more detailed information, and 2) a starting point on
> >>some of the information itself.
>  >
>  > PRESENTATION SOLUTION
>  >
>  > Here are some thoughts on how to present this information.  There
>  are disadvantages and advantages to each of these methods of which
>  I will not list.  I would like to see what people think about them:
>  >
>  >   * Manual - Create a section in the "Technical Details" Chapter
>  > of
>  the YP Reference Manual that holds this information.  The section
>  would be pretty much self-contained and would consist of several
>  illustrations that would stem from an overall figure that is
>  similar to the figure we now have in the YP Quick Start.  However,
>  we would use a drill-down strategy that would progressively reveal
>  more detail through subsequent figures.  This method is similar to
>  how hardware devices used to be documented where functional
> blocks
>  would be connected and described in one area and then subsequent
>  areas would elaborate more deeply on a particular block.  Linking
>  within the manual could connect up the various functional blocks
>  (inputs,

[yocto] -rt and COMPATIBLE_MACHINES

2013-06-20 Thread Paul D. DeRocco

I was able to build core-image-base from Dylan with no problem. I then added
my own layer that specifies an RT kernel by including "linux-yocto-rt" in my
top-level recipe, and then setting PREFERRED_PROVIDER_virtual/kernel to
"linux-yocto-rt" in bblayers.conf. It complained that none of the available
kernel recipes (linux-yocto-rt_*) were compatible with my machine, because
they all set COMPATIBLE_MACHINE to a list of qemu machines, which isn't what
I'm building for. So I created a linux-yocto-rt_3.8.bbappend file that just
sets COMPATIBLE_MACHINE to what I'm building for, and now it's building
away.

My question is this: why was I able to build core-image base without
complaint in the first place? The kernel recipes it has available
(linux-yocto_*) also set COMPATIBLE_MACHINE to a list of qemu machines.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 
 

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

[yocto] [meta-ivi][PATCH 1/1] dlt-daemon: Fix issue when recompiling is needed for this package

2013-06-20 Thread Andrei Gherzan

Signed-off-by: Andrei Gherzan 
---
 .../dlt-daemon/fix-in-build-builds.patch   | 148 +
 recipes-extended/dlt-daemon/dlt-daemon_2.9.0.bb|   6 +-
 2 files changed, 152 insertions(+), 2 deletions(-)
 create mode 100644 
recipes-extended/dlt-daemon/dlt-daemon/fix-in-build-builds.patch

diff --git a/recipes-extended/dlt-daemon/dlt-daemon/fix-in-build-builds.patch 
b/recipes-extended/dlt-daemon/dlt-daemon/fix-in-build-builds.patch
new file mode 100644
index 000..b944d14
--- /dev/null
+++ b/recipes-extended/dlt-daemon/dlt-daemon/fix-in-build-builds.patch
@@ -0,0 +1,148 @@
+Index: git/src/adaptor/CMakeLists.txt
+===
+--- git.orig/src/adaptor/CMakeLists.txt2013-06-11 17:27:50.367489635 
+0300
 git/src/adaptor/CMakeLists.txt 2013-06-11 17:27:57.735489371 +0300
+@@ -14,12 +14,12 @@
+ # @licence end@
+ 
+ 
+-set(dlt_adaptor_stdin_SRCS dlt-adaptor-stdin)
++set(dlt_adaptor_stdin_SRCS dlt-adaptor-stdin.c)
+ add_executable(dlt-adaptor-stdin ${dlt_adaptor_stdin_SRCS})
+ target_link_libraries(dlt-adaptor-stdin dlt)
+ set_target_properties(dlt-adaptor-stdin PROPERTIES LINKER_LANGUAGE C)
+ 
+-set(dlt_adaptor_udp_SRCS dlt-adaptor-udp)
++set(dlt_adaptor_udp_SRCS dlt-adaptor-udp.c)
+ add_executable(dlt-adaptor-udp ${dlt_adaptor_udp_SRCS})
+ target_link_libraries(dlt-adaptor-udp dlt)
+ set_target_properties(dlt-adaptor-udp PROPERTIES LINKER_LANGUAGE C)
+Index: git/src/system/CMakeLists.txt
+===
+--- git.orig/src/system/CMakeLists.txt 2013-06-11 17:23:40.467498576 +0300
 git/src/system/CMakeLists.txt  2013-06-11 17:24:04.311497723 +0300
+@@ -18,9 +18,9 @@
+ message( STATUS "Added ${systemd_SRCS} to dlt-system")
+ endif(WITH_SYSTEMD_WATCHDOG OR WITH_SYSTEMD)
+ 
+-set(dlt_system_SRCS dlt-system dlt-system-options dlt-system-process-handling 
+-  dlt-system-filetransfer dlt-system-logfile dlt-system-processes 
dlt-system-shell
+-  dlt-system-syslog dlt-system-watchdog)
++set(dlt_system_SRCS dlt-system.c dlt-system-options.c 
dlt-system-process-handling.c 
++  dlt-system-filetransfer.c dlt-system-logfile.c dlt-system-processes.c 
dlt-system-shell.c
++  dlt-system-syslog.c dlt-system-watchdog.c)
+ add_executable(dlt-system ${dlt_system_SRCS} ${systemd_SRCS})
+ target_link_libraries(dlt-system dlt z)
+ set_target_properties(dlt-system PROPERTIES LINKER_LANGUAGE C)
+Index: git/src/tests/CMakeLists.txt
+===
+--- git.orig/src/tests/CMakeLists.txt  2013-06-11 17:22:05.139501987 +0300
 git/src/tests/CMakeLists.txt   2013-06-11 17:22:30.711501072 +0300
+@@ -13,42 +13,42 @@
+ #
+ # @licence end@
+ 
+-set(dlt_test_multi_process_SRCS dlt-test-multi-process)
++set(dlt_test_multi_process_SRCS dlt-test-multi-process.c)
+ add_executable(dlt-test-multi-process ${dlt_test_multi_process_SRCS})
+ target_link_libraries(dlt-test-multi-process dlt)
+ set_target_properties(dlt-test-multi-process PROPERTIES LINKER_LANGUAGE C)
+ 
+-set(dlt_test_multi_process_client_SRCS dlt-test-multi-process-client)
++set(dlt_test_multi_process_client_SRCS dlt-test-multi-process-client.c)
+ add_executable(dlt-test-multi-process-client 
${dlt_test_multi_process_client_SRCS})
+ target_link_libraries(dlt-test-multi-process-client dlt)
+ set_target_properties(dlt-test-multi-process-client PROPERTIES 
LINKER_LANGUAGE C)
+ 
+-set(dlt_test_user_SRCS dlt-test-user)
++set(dlt_test_user_SRCS dlt-test-user.c)
+ add_executable(dlt-test-user ${dlt_test_user_SRCS})
+ target_link_libraries(dlt-test-user dlt)
+ set_target_properties(dlt-test-user PROPERTIES LINKER_LANGUAGE C)
+ 
+-set(dlt_test_client_SRCS dlt-test-client)
++set(dlt_test_client_SRCS dlt-test-client.c)
+ add_executable(dlt-test-client ${dlt_test_client_SRCS})
+ target_link_libraries(dlt-test-client dlt)
+ set_target_properties(dlt-test-client PROPERTIES LINKER_LANGUAGE C)
+ 
+-set(dlt_test_stress_user_SRCS dlt-test-stress-user)
++set(dlt_test_stress_user_SRCS dlt-test-stress-user.c)
+ add_executable(dlt-test-stress-user ${dlt_test_stress_user_SRCS})
+ target_link_libraries(dlt-test-stress-user dlt)
+ set_target_properties(dlt-test-stress-user PROPERTIES LINKER_LANGUAGE C)
+ 
+-set(dlt_test_stress_client_SRCS dlt-test-stress-client)
++set(dlt_test_stress_client_SRCS dlt-test-stress-client.c)
+ add_executable(dlt-test-stress-client ${dlt_test_stress_client_SRCS})
+ target_link_libraries(dlt-test-stress-client dlt)
+ set_target_properties(dlt-test-stress-client PROPERTIES LINKER_LANGUAGE C)
+ 
+-set(dlt_test_stress_SRCS dlt-test-stress)
++set(dlt_test_stress_SRCS dlt-test-stress.c)
+ add_executable(dlt-test-stress ${dlt_test_stress_SRCS})
+ target_link_libraries(dlt-test-stress dlt)
+ set_target_properties(dlt-test-stress PROPERTIES LINKER_LANGUAGE C)
+ 
+-set(dlt_test_filetransfer_SRCS dlt-test-filetransfer)
++set(dlt_test_filetransfer_S

[yocto] [meta-ivi][PATCH v2 1/1] gpu-viv-bin-mx6q.inc: Add linked libraries to libGAL to DEPENDS

2013-06-20 Thread Andrei Gherzan

Signed-off-by: Andrei Gherzan 
---
 recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc 
b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index e1f10b6..91d93e6 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -126,6 +126,7 @@ FILES_libegl-mx6-dbg = "${libdir}/.debug/libEGL${SOLIBS}"
 FILES_libgal-mx6 = "${libdir}/libGAL${SOLIBS}"
 FILES_libgal-mx6-dev = "${libdir}/libGAL${SOLIBSDEV}"
 FILES_libgal-mx6-dbg = "${libdir}/.debug/libGAL${SOLIBS}"
+DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 
libxdamage libxext libxfixes', '', d)}"
 
 FILES_libgl-mx6 = "${libdir}/libGL${SOLIBS}"
 FILES_libgl-mx6-dbg = "${libdir}/.debug/libGL.${SOLIBS}"
-- 
1.8.1.4

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

Re: [yocto] [meta-ivi][PATCH v2 1/1] gpu-viv-bin-mx6q.inc: Add linked libraries to libGAL to DEPENDS

2013-06-20 Thread Andrei Gherzan

Sorry for this. Please disregard.


On Thu, Jun 20, 2013 at 11:08 PM, Andrei Gherzan  wrote:

> Signed-off-by: Andrei Gherzan 
> ---
>  recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> index e1f10b6..91d93e6 100644
> --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> @@ -126,6 +126,7 @@ FILES_libegl-mx6-dbg =
> "${libdir}/.debug/libEGL${SOLIBS}"
>  FILES_libgal-mx6 = "${libdir}/libGAL${SOLIBS}"
>  FILES_libgal-mx6-dev = "${libdir}/libGAL${SOLIBSDEV}"
>  FILES_libgal-mx6-dbg = "${libdir}/.debug/libGAL${SOLIBS}"
> +DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11
> libxdamage libxext libxfixes', '', d)}"
>
>  FILES_libgl-mx6 = "${libdir}/libGL${SOLIBS}"
>  FILES_libgl-mx6-dbg = "${libdir}/.debug/libGL.${SOLIBS}"
> --
> 1.8.1.4
>
>


-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Compiling a simple command

2013-06-20 Thread Paul D. DeRocco

I've tried to add a single small executable to my image, based on what it
says in 5.3.1. of the Project Development Manual, and while the image gets
built with no error messages, it never compiles my executable. I'm not doing
_exactly_ what it says, so I assume some difference is accounting for this
failure. What I'm doing different:

1) Since I'm only adding one tiny little program to an otherwise default
image, I'm not creating a separate .bb file for it, but placing it in the
top-level .bb file that I invoke with the bitbake command.

2) Since I only have one .bb file, I'm sticking it in the layer directory,
not two levels down, and adding ${LAYERDIR}/*.bb to BBFILES.

It's finding the recipe okay, because the image is being built, but it's
never executing do_compile or do_install. The recipe looks like this:

-- 
require recipes-core/images/core-image-base.bb

DESCRIPTION = "A basic image with a realtime kernel."
DEPENDS = "linux-yocto-rt"
LICENSE = "MIT"
PR = "r0"

SRC_URI = "file://fastuart.cpp"

S = "${WORKDIR}"

do_compile() {
${CC} fastuart.cpp -o fastuart
}

do_install() {
install -d ${D}${bindir}
install -m 0755 fastuart ${D}${bindir}
}
-- 

The source is one level down from the recipe file, in files/fastuart.cpp. Is
there some reason that one can't do a compilation from a top-level recipe
that makes an image? Or is it because of the location of the .bb file in the
tree? Or am I doing something else wrong?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 
 

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

Re: [yocto] Compiling a simple command

2013-06-20 Thread Nicolas Dechesne

On Thu, Jun 20, 2013 at 6:08 PM, Paul D. DeRocco wrote:

> I've tried to add a single small executable to my image, based on what it
> says in 5.3.1. of the Project Development Manual, and while the image gets
> built with no error messages, it never compiles my executable. I'm not
> doing
> _exactly_ what it says, so I assume some difference is accounting for this
> failure. What I'm doing different:
>
> 1) Since I'm only adding one tiny little program to an otherwise default
> image, I'm not creating a separate .bb file for it, but placing it in the
> top-level .bb file that I invoke with the bitbake command.
>
> 2) Since I only have one .bb file, I'm sticking it in the layer directory,
> not two levels down, and adding ${LAYERDIR}/*.bb to BBFILES.
>
> It's finding the recipe okay, because the image is being built, but it's
> never executing do_compile or do_install. The recipe looks like this:
>
> --
> require recipes-core/images/core-image-base.bb
>
> DESCRIPTION = "A basic image with a realtime kernel."
> DEPENDS = "linux-yocto-rt"
> LICENSE = "MIT"
> PR = "r0"
>
> SRC_URI = "file://fastuart.cpp"
>
> S = "${WORKDIR}"
>
> do_compile() {
> ${CC} fastuart.cpp -o fastuart
> }
>
> do_install() {
> install -d ${D}${bindir}
> install -m 0755 fastuart ${D}${bindir}
> }
>

here you are mixing a recipe for an image with a recipe for a 'package',
and that's wrong. you have recipes for images, and recipes for packages.
 for package, bitbake will actually do the standard
fetch/unpack/patch/configure/compile/package steps, but not for images. all
images recipe inherit from image.bbclass, and if you check that file you
can see that all 'normal package' tasks are disabled (toward the end of the
file)

so, while your recipe is indeed syntactically correct, the do_compile() and
do_install() aren't never really called.

you need to make a separate recipe for your package, e.g.
fastuart_1.0.bb(and removes the 'require' at the beginning).

then you can create your image recipe, and request your package to be
installed in the image , you can do something like that:

require recipes-core/images/core-image-base.bb
IMAGE_INSTALL += 'fastuart'
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] ecryptfs-utils: create symlinks for mount file in expected path

2013-06-20 Thread Florin Sarbu


Hi,
thanks for pointing this out. I've changed the configure flags for this 
to be fixed, rather than modifying the do_install. Please update the 
master/4.0 branch, the fix for this issue is there now.


Florin

On 06/19/2013 01:54 PM, Noor, Ahsan wrote:

From: Noor 

* mounting ecryptfs drive was failing because it was looking for mount.ecryptfs
   binary in /sbin/ however in our file-system, it was present in /usr/sbin/. 
So,
   create symlinks of required binaries in /sbin/ as well

Signed-off-by: Noor Ahsan 
---
  .../ecryptfs-utils/ecryptfs-utils_100.bb   |4 
  1 file changed, 4 insertions(+)

diff --git a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb 
b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
index e23f32c..c05cd84 100644
--- a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
+++ b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
@@ -40,4 +40,8 @@ do_install_append() {
  install -d ${D}${systemd_unitdir}/system/
  install -m 0644 ${WORKDIR}/ecryptfs.service 
${D}${systemd_unitdir}/system
  fi
+
+install -d ${D}${base_sbindir}
+ln -sf ${sbindir}/mount.ecryptfs ${D}${base_sbindir}/
+ln -sf ${sbindir}/umount.ecryptfs ${D}${base_sbindir}/
  }


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

Re: [yocto] Compiling a simple command

2013-06-20 Thread Paul D. DeRocco

> From: Nicolas Dechesne
> 
> here you are mixing a recipe for an image with a recipe for a 
> 'package', and that's wrong. you have recipes for images, and 
> recipes for packages.  for package, bitbake will actually do 
> the standard fetch/unpack/patch/configure/compile/package 
> steps, but not for images. all images recipe inherit from 
> image.bbclass, and if you check that file you can see that 
> all 'normal package' tasks are disabled (toward the end of the file)
> 
> so, while your recipe is indeed syntactically correct, the 
> do_compile() and do_install() aren't never really called.
> 
> you need to make a separate recipe for your package, e.g. 
> fastuart_1.0.bb (and removes the 'require' at the beginning).
> 
> then you can create your image recipe, and request your 
> package to be installed in the image , you can do something like that:
> 
> require recipes-core/images/core-image-base.bb 
>  
> 
> IMAGE_INSTALL += 'fastuart'

Thanks, that appears to work.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

Re: [yocto] cannot bitbake/build.compile tcf-agent for use with fsl-image-gui-sdk

2013-06-20 Thread Anna Dushistova

Hi everyone,

On Tue, Jun 18, 2013 at 7:24 PM, Khem Raj  wrote:

> <...>
>
> Seems a missing dep on OpenSSL btw does tcf-agent work on anything other
> than x86 ?
>
>
 First of all, it's possible to compile the agent with OpenSSL disabled,
you will need to set ENABLE_SSL to 0 in your CFLAGS, see
http://git.eclipse.org/c/tcf/org.eclipse.tcf.agent.git/tree/agent/tcf/config.h#n213
.

Then, tcf-agent as the means of communication works on all the main
platforms, and as of this upcoming release,
there is an initial debug support on ARM, see
http://wiki.eclipse.org/TCF/NewIn11.

Anna.

>
> At this point I have run out of ideas about how to prepare tcf-agent to
> install on my sabrelite fsl-image-gui-sdk rootfs
> Any help would be most welcome.
>
> for example in the 1st case how could I run apt-get as is suggested in a
> manner that would be appropriate to update yocto sources?
>
> Thank you.
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] ecryptfs-utils: create symlinks for mount file in expected path

2013-06-20 Thread Ahsan, Noor

Hello,

Thanks for taking care of this. I was looking at meta-ivi/4.0.

Noor

-Original Message-
From: Florin Sarbu [mailto:florin.sa...@windriver.com] 
Sent: Friday, June 21, 2013 11:10 AM
To: Ahsan, Noor
Cc: holger.behr...@windriver.com; yocto@yoctoproject.org
Subject: Re: [PATCH] ecryptfs-utils: create symlinks for mount file in expected 
path

Hi,
thanks for pointing this out. I've changed the configure flags for this to be 
fixed, rather than modifying the do_install. Please update the
master/4.0 branch, the fix for this issue is there now.

Florin

On 06/19/2013 01:54 PM, Noor, Ahsan wrote:
> From: Noor 
>
> * mounting ecryptfs drive was failing because it was looking for 
> mount.ecryptfs
>binary in /sbin/ however in our file-system, it was present in /usr/sbin/. 
> So,
>create symlinks of required binaries in /sbin/ as well
>
> Signed-off-by: Noor Ahsan 
> ---
>   .../ecryptfs-utils/ecryptfs-utils_100.bb   |4 
>   1 file changed, 4 insertions(+)
>
> diff --git a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb 
> b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
> index e23f32c..c05cd84 100644
> --- a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
> +++ b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
> @@ -40,4 +40,8 @@ do_install_append() {
>   install -d ${D}${systemd_unitdir}/system/
>   install -m 0644 ${WORKDIR}/ecryptfs.service 
> ${D}${systemd_unitdir}/system
>   fi
> +
> +install -d ${D}${base_sbindir}
> +ln -sf ${sbindir}/mount.ecryptfs ${D}${base_sbindir}/
> +ln -sf ${sbindir}/umount.ecryptfs ${D}${base_sbindir}/
>   }

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

Re: [yocto] Toolchain... Issues with systemd (probably)

Re: [yocto] Toolchain... Issues with systemd (probably)

Re: [yocto] Toolchain... Issues with systemd (probably)

Re: [yocto] Toolchain... Issues with systemd (probably)

[yocto] Documenting YP Development Environment in more detail

Re: [yocto] Toolchain... Issues with systemd (probably)

Re: [yocto] Toolchain... Issues with systemd (probably)

Re: [yocto] Installing .deb file in Build

Re: [yocto] core-image-x11 works on QEMU and not on real hardware

Re: [yocto] Build doesn't interrupt cleanly

Re: [yocto] Toolchain... Issues with systemd (probably)

Re: [yocto] No crosscompiler in Toolchain

Re: [yocto] Documenting YP Development Environment in more detail

Re: [yocto] Documenting YP Development Environment in more detail

Re: [yocto] Documenting YP Development Environment in more detail

Re: [yocto] This one can't be me...

Re: [yocto] Documenting YP Development Environment in more detail

Re: [yocto] [PATCH] ecryptfs-utils: Modify systemd service file to 'simple'.

Re: [yocto] Documenting YP Development Environment in more detail

[yocto] [PATCH] Fix Eclipse workspace deadlock when restoring

Re: [yocto] Cedartrail and Dylan?

[yocto] FW: cannot bitbake/build.compile tcf-agent for use with fsl-image-gui-sdk

Re: [yocto] Documenting YP Development Environment in more detail

Re: [yocto] Cedartrail and Dylan?

Re: [yocto] Documenting YP Development Environment in more detail

[yocto] -rt and COMPATIBLE_MACHINES

[yocto] [meta-ivi][PATCH 1/1] dlt-daemon: Fix issue when recompiling is needed for this package

[yocto] [meta-ivi][PATCH v2 1/1] gpu-viv-bin-mx6q.inc: Add linked libraries to libGAL to DEPENDS

Re: [yocto] [meta-ivi][PATCH v2 1/1] gpu-viv-bin-mx6q.inc: Add linked libraries to libGAL to DEPENDS

[yocto] Compiling a simple command

Re: [yocto] Compiling a simple command

Re: [yocto] [PATCH] ecryptfs-utils: create symlinks for mount file in expected path

Re: [yocto] Compiling a simple command

Re: [yocto] cannot bitbake/build.compile tcf-agent for use with fsl-image-gui-sdk

Re: [yocto] [PATCH] ecryptfs-utils: create symlinks for mount file in expected path

35 matches

Site Navigation

Mail list logo

Footer information