Re: [yocto] RFC: poky-tiny: init procedure

[Tomas Frydrych]

Hi Darren,

On 14/06/12 01:33, Darren Hart wrote:
> o Do not include the standard Busybox init
...
> o Do not provide inittab functionality

I am not entirely clear what you are hoping to gain by creating a home
grown init solution?

A system that runs nothing but a shell is really not useful for anything
all, everyone using it will be adding some sort of services, so the
question of how the extending works (or does not work), needs to be in
the forefront of the design. My main reservation is that you are
suggesting to break one of the basic premisses behind the whole
ecosystem, namely that if I add a package that provides a service to an
image, I get that service running; 'fix by documentation' is never a fix.

So back to my original question, what are the expected benefits to the
Poky users of not using initd in such minimal systems, and do you have
any numbers to show it is worth it? Maybe the numbers are compelling,
but considering that currently Poky does not even support systemd,
adding yet another, home grown, init system seems like a step in the
wrong direction (perhaps sorting out the systemd mess is an opportunity
to deal with the init sequence in a more generic way).

(I hear what you are saying about a system that only includes packages
you want and nothing else, but this is orthogonal to the system size; I
for one want to be able to create a midsized system that includes only
packages that I want and nothing else. :) )

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

Re: [yocto] Web HOB planning discussion

[Barros Pena, Belen]

Hi all,

Thanks for the feedback: loads of interesting stuff there. We'll keep it all in 
mind when working on the next iteration.

If you think of anything else, please post it here.

Cheers

Belen

From: , Jeffrey 
mailto:jeffrey.osier-mi...@intel.com>>
Date: Wednesday, 13 June 2012 19:00
To: "Stewart, David C" 
mailto:david.c.stew...@intel.com>>
Cc: Konstantinos Papagiannopoulos 
mailto:he...@konputer.net>>, 
"yocto@yoctoproject.org" 
mailto:yocto@yoctoproject.org>>, Jim Kosem 
mailto:j...@halfman.com>>
Subject: Re: [yocto] Web HOB planning discussion

I agree, it is looking really interesting. Some comments below.

On Wed, Jun 13, 2012 at 10:39 AM, Stewart, David C 
mailto:david.c.stew...@intel.com>> wrote:
* This could be a great way for an organization to implement a workflow process 
using YP, rather than try to invent one themselves. We have gotten the feedback 
that some larger organizations want something like this, so I'm pleased with 
that direction.

Agreed - I have fielded a few questions about this as well

* With the above in mind, a key meta-usage is installing and configuring the 
server. For example, I could imagine an organization wanting to easily 
customize the home page with their own news and design information, etc.

* I could also see the opportunity for an OSV or service provider to brand the 
interface with their own goodness and extending it with their own features so 
this might be another meta-usage.

* And while I'm on a roll... whenever we talk about how the administrator 
installs this, we need consider how they update from a previous version, 
particularly if they have customized the home screen or other bits.

If branding & customization happen in CSS, the whole customization part should 
be portable from one version to another (as long as no one breaks anything 
structural). If we want to enable customization of functionality, though - e.g. 
pre-filter package selection, restrict certain features... - I could see that 
being tricky to implement in a portable way.

* Project creation and member add/remove should perhaps be an administrator 
role and password protected?

I vote yes on user management, but why password-protect project creation?

Other thoughts:

My feeling is that both Hob and WebHob will be most useful as tools to get 
people started. At some point, anyone who is doing more esoteric work than the 
Hob allows will need to learn how to get their hands dirty with recipes, config 
files, etc. For that reason, I really like the workflow focus, as that 
translates directly to the expected workflow of the whole build system. I 
suggest a future step might be guided configuration, guided recipe (and layer?) 
creation, and other progressive types of features that also show the workflow 
in action the way the current Hob does.

And I totally agree that the usability work you guys have done is making a huge 
difference in design. I like it! Want more!
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel 
http://yoctoproject.org

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[yocto] OpenSSL Perl File::Find

[Jack Mitchell]

The OpenSSL recipe halts saying it can't find find.pl however I have 
File::Find installed which brings in file.pl as a perl module (find.pm). 
Could anyone shed any light on why this might not be found?


Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| ERROR: Function failed: do_configure (see 
/home/jack/Projects/poky-denzil.git/r0005/tmp/work/x86_64-linux/openssl-native-1.0.0i-r15.2/temp/log.do_configure.6745 
for further information)
| Can't locate find.pl in @INC (@INC contains: /usr/lib/perl5/site_perl 
/usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl 
/usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl 
/usr/share/perl5/core_perl .) at perlpath.pl line 7.

NOTE: package openssl-native-1.0.0i-r15.2: task do_configure: Failed


The module is located in: /usr/lib/perl5/core_perl

My host is Archlinux 64.

Regards,

--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--

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

[yocto] Discussion: Package testing

[Björn Stenberg]

Hi.

Many source packages include their own package test suites. We are looking at 
running these tests on target in a structured way, and I would like a 
discussion about how to best fit this into the Yocto framework.

The actions that need to be performed for a package test are roughly:

1) Build the test suite
2) Make the test suite appear on target
3) Run the test suite
4) Parse the results

Each action can be done in several ways, and there are different considerations 
for each solution.

1) Build the test suite
---
Many package tests are simply bash scripts that run the packaged binaries in 
various ways, but often the test suites also include binary tools that are not 
part of the normal package build. These tools have to be built for package 
testing to work.

Additionally, many packages build and run the test in a single command, such as 
"make check", which is obviously unsuitable for cross-compiled packages.

We can solve this in different ways:

a) Run the test build+run jobs on target. This avoids the need to modify 
packages, but building code on target can get quite expensive in terms of disk 
space. This in turn means many tests would require a harddisk or network disk 
to run.

b) Patch the makefiles to split test building and test running. Patching 
makefiles mean we get an additional maintenance and/or upstreaming burden, but 
we should be able to do this in ways that are acceptable to upstream. This is 
our suggestion.


2) Make the test suite appear on target
---
The test suite and utilities obviously have to be executable by the target 
system in order to run. There are a few options for this:

a) Copy all test files to the target at test run time, from the build dir, 
using whatever means available (scp, ftp etc). This limits testing to 
targets/images with easy automatic file transfer abilities installed.

b) NFS mount the build dir to access the full work dir and hence the test code. 
this limits testing to targets (and images) with network+nfs support. Plus it 
blends the build env and runtime env in an unpleasant way.

c) Create ${PN}-ptest packages (in the model of -dev and -dbg) that contain all 
test files and add those to the image and hence the rootfs. This is our 
suggestion.


3) Run the test suite
-
Depending on how the test files are presented to the target, the way we run 
them can take different shapes:

a) (scp) A top-level run-all-tests.sh runs on the build host, copies all test 
files from build dir to target, logs in and runs each test.

b) (nfs) run-all-tests.sh is executed in the nfs-mounted build dir on target 
and build-runs each test in its work dir.

c) (-ptest) Install all test files to /opt/ptest/${PN}-${PV} (for example). 
Make a package "ptest-runner" that has a script /opt/ptest/run-all-tests to 
iterate over all installed tests and run them. This is our suggestion.


4) Parse the test results
-
Just running the tests doesn't give us much. We have to be able to look at the 
results and make them meaningful to us on a system-global level. Packages 
present their test results in very different ways, and we need to convert that 
to a generic format:

a) Patch each package test to produce a generic ptest output format. This is 
likely difficult to get accepted upstream.

b) Patch the test code minimally and instead use a simple per-packet translate 
script that converts test suite output from the package-specific format to a 
generic ptest format. This is our suggestion.


Opinions?

Note that this mail is about the test suites for/in/by specific packages. 
Standalone test suites such as LTP are a slightly different topic, since they 
are separate packages (${BPN} == ${PN}) rather than package companion suites.

-- 
Björn
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [PATCH 2/3] busybox: Add setsid and cttyhack for tiny DISTRO_FEATURE

[Darren Hart]

On 06/14/2012 02:41 AM, Phil Blundell wrote:
> On Wed, 2012-06-13 at 22:19 -0700, Darren Hart wrote:
>> diff --git a/meta/recipes-core/busybox/busybox.inc 
>> b/meta/recipes-core/busybox/busybox.inc
>> index 5b83d32..d07ba7e 100644
>> --- a/meta/recipes-core/busybox/busybox.inc
>> +++ b/meta/recipes-core/busybox/busybox.inc
>> @@ -57,6 +57,8 @@ def features_to_busybox_settings(d):
>>  busybox_cfg('nls',  distro_features, 'CONFIG_LOCALE_SUPPORT', cnf, rem)
>>  busybox_cfg('ipv4', distro_features, 'CONFIG_FEATURE_IFUPDOWN_IPV4', 
>> cnf, rem)
>>  busybox_cfg('ipv6', distro_features, 'CONFIG_FEATURE_IFUPDOWN_IPV6', 
>> cnf, rem)
>> +busybox_cfg('tiny', distro_features, 'CONFIG_SETSID', cnf, rem)
>> +busybox_cfg('tiny', distro_features, 'CONFIG_CTTYHACK', cnf, rem)
>>  return "\n".join(cnf), "\n".join(rem)
>>  
>>  # X, Y = ${@features_to_uclibc_settings(d)}
> 
> What exactly is the mission of the "tiny" DISTRO_FEATURE?  It doesn't
> seem very wholesome for it to be enabling a random grab-bag of bits in
> busybox (or anywhere else).

The idea is to avoid having to bbappend busybox and other recipes
basically. I can see how "tiny" is different than "ipv4" as it isn't
explicit it what it enables, making it a "grab-bag" as you put it.

I could come up with a term that describes systems without complex init
systems that need to be able to setup their own shells easily.

Another approach would be to just consider these two features and decide
if they shouldn't just be part of the oe-core busybox defconfig anyway.
I don't see why setsid shouldn't be. I can see arguments against
cttyhack (as it is a hack), but I wouldn't think either should be a huge
deal to just include. I thought the DISTRO_FEATURE was a reasonable
compromise between that and having to maintain a bbappend outside of
oe-core.

> 
> If poky-tiny wants those features enabled then it can, and should, ship
> its own configuration for busybox which turns them on.  I think that
> would be better than further proliferation of switches in oe-core.
> 

How would you feel about just including these two features in the
defconfig then?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


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

[yocto] live image types and qemu machines

[Barros Pena, Belen]

Hi all,

The current Hob allows you to build images for a qemu machine selecting
'live' as your image type. To me (with my pitiful knowledge) this doesn't
make much sense: would I want to deploy an image built for a
virtualisation environment in a real piece of hardware?

So here goes a question: should we allow Hob users, who are mainly people
new to the Yocto project, to select the 'live' image type when building
images for qemu machines?

This might sound like a silly question, but it has a pretty big impact on
the Settings dialog and on the number of variations we need to create for
our 'Image details' screen, which appears after the build finishes and
displays logical next steps (like run the image or deploy your image to
external storage).

Any help with this would be much appreciated.

Thanks!

Belen




-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[yocto] developing with devshell and effect of the bitbake.conf file

[Rifenbark, Scott M]

Hi,

I want to throw this out for discussion.  I recently was looking at a section 
in the YP Reference manual 
(http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell)
 where it talks about developing using devshell.  I asked Darren Hart if this 
was a valid development model and he says it is.  There is a part of the 
section though that talks about the bitbake.conf file.  That section in the 
conf file does not seem to exist anymore.  And, Darren (after some testing) 
doesn't see how what is in the bitbake.conf file affects development with 
devshell.  Any comments welcome.

Thanks,
ScottR

From: Scott Rifenbark [mailto:srifenb...@gmail.com]
Sent: Thursday, June 14, 2012 8:42 AM
To: Rifenbark, Scott M
Subject: Fwd: Next question regarding development practices


-- Forwarded message --
From: Darren Hart mailto:darren.h...@intel.com>>
Date: Wed, Jun 13, 2012 at 2:19 PM
Subject: Re: Next question regarding development practices
To: Scott Rifenbark mailto:srifenb...@gmail.com>>

On 06/12/2012 11:34 AM, Scott Rifenbark wrote:
> Hi Darren,
>
> So check out section
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell.
> This talks about the whole devshell model.  One thing in this section is
> not current and that is the UI/Interfaces Configuration section
> reference in bitbake.conf file.  Regarding the section though, is this
> still a valid development model?  Is it worth keeping around in the docs?
>
> As you can tell, I value your opinions greatly :)
As I understand it, this is still a perfectly valid working model.
Someone was just recommending it this week on the list.

As for the bitbake.conf file... I'm not sure. I thought this would have
been controlled by the following in local.conf.

# If you do not use (or have installed) gnome-terminal you will need to
# uncomment these variables and set them to the terminal you wish to use
# when resolving patches which cannot be applied
# Supported shell prefixes for *_TERMCMD and *_TERMCMDRUN ARE:
# GNOME, SCREEN, XTERM and SCREEN
TERMCMD = "${SCREEN_TERMCMD}"
TERMCMDRUN = "${SCREEN_TERMCMDRUN}"

But... it clearly is not after some testing. Hrm... I don't see anything
matching in bitbake.conf either. Where this has migrated off to would be
a good question for the list, hopefully someone like Paul E. can answer
this quickly.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


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

[yocto] running my qemu images with kvm

[Robert P. J. Day]

  embarrassingly, i only just noticed that if i want my
yocto-generated qemu images to take advantage of kvm, i should add the
arg "kvm" to my "runqemu" invocation, is that correct?

  if that's the case, might it be worth adding that note to the
standard oe-init-build-env output at the bottom?  or perhaps referring
the user to the output of "runqemu -h" for available run-time options?

  at the moment, it seems awfully easy to run your qemu image without
realizing you're not taking advantage of kvm.  or am i misreading
something?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] oddities in "runqemu" script

[Robert P. J. Day]

  just a few observations:

1) usage suggests this possible option:

  MACHINE=xyz

  not sure what that's supposed to accomplish, that will be rejected
by the arg parsing loop, will it not?  or how is one supposed to
interpret that?

2) the process_filename() function appears to accept a filesystem type
of "ext4", but the arg parsing loop immediately after that doesn't
recognize that as valid, only ext[23].

3) the arg parsing script clearly recognizes the option "audio", but
that's not mentioned in the usage() function.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Discussion: Package testing

[Frans Meulenbroeks]

Bjorn, these are some interesting ideas.
Some feedback below.
This is from the perspective of asomeone who develops for embedded systems
boards

2012/6/14 Björn Stenberg 

> Hi.
>
> Many source packages include their own package test suites. We are looking
> at running these tests on target in a structured way, and I would like a
> discussion about how to best fit this into the Yocto framework.
>
> The actions that need to be performed for a package test are roughly:
>
> 1) Build the test suite
> 2) Make the test suite appear on target
> 3) Run the test suite
> 4) Parse the results
>
> Each action can be done in several ways, and there are different
> considerations for each solution.
>
> 1) Build the test suite
> ---
> Many package tests are simply bash scripts that run the packaged binaries
> in various ways, but often the test suites also include binary tools that
> are not part of the normal package build. These tools have to be built for
> package testing to work.
>
> Additionally, many packages build and run the test in a single command,
> such as "make check", which is obviously unsuitable for cross-compiled
> packages.
>
> We can solve this in different ways:
>
> a) Run the test build+run jobs on target. This avoids the need to modify
> packages, but building code on target can get quite expensive in terms of
> disk space. This in turn means many tests would require a harddisk or
> network disk to run.
>
> Not only storage space can be an issue. Some targets also do have limited
RAM and are low on CPU power.


> b) Patch the makefiles to split test building and test running. Patching
> makefiles mean we get an additional maintenance and/or upstreaming burden,
> but we should be able to do this in ways that are acceptable to upstream.
> This is our suggestion.
>
This seems the most plexible approach. I'd say this could generate
additional -test packages

>
>
> 2) Make the test suite appear on target
> ---
> The test suite and utilities obviously have to be executable by the target
> system in order to run. There are a few options for this:
>
> a) Copy all test files to the target at test run time, from the build dir,
> using whatever means available (scp, ftp etc). This limits testing to
> targets/images with easy automatic file transfer abilities installed.
>
It also somewhat couples the building and the copying (or an additional
command or step would be needed.

>
> b) NFS mount the build dir to access the full work dir and hence the test
> code. this limits testing to targets (and images) with network+nfs support.
> Plus it blends the build env and runtime env in an unpleasant way.
>
> c) Create ${PN}-ptest packages (in the model of -dev and -dbg) that
> contain all test files and add those to the image and hence the rootfs.
> This is our suggestion.
>

Agree, then one can decide whether to add them to an image, use a package
feed to install things or whatever means.
In our case some of our systems do not have network support

>
>
> 3) Run the test suite
> -
> Depending on how the test files are presented to the target, the way we
> run them can take different shapes:
>
> a) (scp) A top-level run-all-tests.sh runs on the build host, copies all
> test files from build dir to target, logs in and runs each test.
>
> b) (nfs) run-all-tests.sh is executed in the nfs-mounted build dir on
> target and build-runs each test in its work dir.
>
> c) (-ptest) Install all test files to /opt/ptest/${PN}-${PV} (for
> example). Make a package "ptest-runner" that has a script
> /opt/ptest/run-all-tests to iterate over all installed tests and run them.
> This is our suggestion.
>

Seems good to me. a run-all-tests.sh script is somewhat problematic as
different systems have different packages installed so different tests.
E.g. t is not too interesting to run C++ tests if your target system does
not have/need C++
That makes creating a run-all-tests.sh script somewhat nastier (of course
it could be conditional e.g. test -f ./testA && ./testA)

>
>
> 4) Parse the test results
> -
> Just running the tests doesn't give us much. We have to be able to look at
> the results and make them meaningful to us on a system-global level.
> Packages present their test results in very different ways, and we need to
> convert that to a generic format:
>
> a) Patch each package test to produce a generic ptest output format. This
> is likely difficult to get accepted upstream.
>
> b) Patch the test code minimally and instead use a simple per-packet
> translate script that converts test suite output from the package-specific
> format to a generic ptest format. This is our suggestion.
>

I suspect most tests would indicate success/failure by their return code.
Maybe the test-runner could use the return code. Optionally the recipe
could add  a way to specify how to measure success (e.g by means of
specifying a TEST_SUCCESS variable in the r

Re: [yocto] oddities in "runqemu" script

[Scott Garman]

On 06/14/2012 11:39 AM, Robert P. J. Day wrote:


   just a few observations:

1) usage suggests this possible option:

   MACHINE=xyz

   not sure what that's supposed to accomplish, that will be rejected
by the arg parsing loop, will it not?  or how is one supposed to
interpret that?


This is a bug in the usage() documentation, thanks for reporting it.


2) the process_filename() function appears to accept a filesystem type
of "ext4", but the arg parsing loop immediately after that doesn't
recognize that as valid, only ext[23].


Our QEMU machines only generate .ext3 images, so that would explain why 
this never got tested. It's still not good that it's inconsistent, so 
I've filed a bug to fix that and the above issue:


https://bugzilla.yoctoproject.org/show_bug.cgi?id=2611


3) the arg parsing script clearly recognizes the option "audio", but
that's not mentioned in the usage() function.


That's because we're not yet ready to advertise that the audio option is 
fully supported, see this bug:


https://bugzilla.yoctoproject.org/show_bug.cgi?id=1018

which isn't even slated for work in 1.3, but rather 1.4.

Thanks for these inquiries!

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] running my qemu images with kvm

[Scott Garman]

On 06/14/2012 11:05 AM, Robert P. J. Day wrote:


   embarrassingly, i only just noticed that if i want my
yocto-generated qemu images to take advantage of kvm, i should add the
arg "kvm" to my "runqemu" invocation, is that correct?


Correct.


   if that's the case, might it be worth adding that note to the
standard oe-init-build-env output at the bottom?  or perhaps referring
the user to the output of "runqemu -h" for available run-time options?


Since the oe-init-build-env script gets invoked for many scenarios that 
don't involve running runqemu, I'm not convinced that the info is needed 
- it might be nice to have, but we don't want to clutter the output with 
too much info.



   at the moment, it seems awfully easy to run your qemu image without
realizing you're not taking advantage of kvm.  or am i misreading
something?


I've been running my QEMU sessions without kvm and it hasn't been a big 
deal. Since we do mention its use in the runqemu usage help, IMHO it's 
appropriately documented.


I'm not sure what the status is of kvm support in the various 
environments that Yocto is run in, so enabling kvm by default may not be 
safe. Please correct me if I'm wrong.


Thanks for the feedback,

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/2] meta-intel: fix new layer warning

[tom . zanussi]

From: Tom Zanussi 

This patchset gets rid of the new layer warning for meta-intel
and all contained BSP layers.

The following changes since commit bd00e28dd54b06a1f01f186be168d3af872f96d4:
  Richard Purdie (1):
meta-emenlow: Update qt4 bbappend to 4.8.1

are available in the git repository at:

  git://git.yoctoproject.org/meta-intel.git tzanussi/layer-conf-updates
  http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/layer-conf-updates

Tom Zanussi (2):
  meta-intel: update conf/layer.conf BBPATH/BBFILES for meta-intel
layer
  meta-intel: update conf/layer.conf BBPATH/BBFILES for BSP layers

 conf/layer.conf   |4 ++--
 meta-cedartrail/conf/layer.conf   |4 ++--
 meta-chiefriver/conf/layer.conf   |4 ++--
 meta-crownbay/conf/layer.conf |4 ++--
 meta-emenlow/conf/layer.conf  |4 ++--
 meta-fishriver/conf/layer.conf|4 ++--
 meta-fri2/conf/layer.conf |4 ++--
 meta-jasperforest/conf/layer.conf |4 ++--
 meta-n450/conf/layer.conf |4 ++--
 meta-romley/conf/layer.conf   |4 ++--
 meta-sugarbay/conf/layer.conf |4 ++--
 meta-sys940x/conf/layer.conf  |4 ++--
 meta-tlk/conf/layer.conf  |4 ++--
 13 files changed, 26 insertions(+), 26 deletions(-)

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

[yocto] [PATCH 1/2] meta-intel: update conf/layer.conf BBPATH/BBFILES for meta-intel layer

[tom . zanussi]

From: Tom Zanussi 

Silence the warning:

WARNING: BBPATH references the current directory

as mentioned in [YOCTO #1465].

Signed-off-by: Tom Zanussi 
---
 conf/layer.conf |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index a5db163..bc31236 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a packages directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/common/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/common/recipes-*/*/*.bb \
 ${LAYERDIR}/common/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "intel"
-- 
1.7.0.4

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

[yocto] [PATCH 2/2] meta-intel: update conf/layer.conf BBPATH/BBFILES for BSP layers

[tom . zanussi]

From: Tom Zanussi 

Silence the warning:

WARNING: BBPATH references the current directory

as mentioned in [YOCTO #1465].

Signed-off-by: Tom Zanussi 
---
 meta-cedartrail/conf/layer.conf   |4 ++--
 meta-chiefriver/conf/layer.conf   |4 ++--
 meta-crownbay/conf/layer.conf |4 ++--
 meta-emenlow/conf/layer.conf  |4 ++--
 meta-fishriver/conf/layer.conf|4 ++--
 meta-fri2/conf/layer.conf |4 ++--
 meta-jasperforest/conf/layer.conf |4 ++--
 meta-n450/conf/layer.conf |4 ++--
 meta-romley/conf/layer.conf   |4 ++--
 meta-sugarbay/conf/layer.conf |4 ++--
 meta-sys940x/conf/layer.conf  |4 ++--
 meta-tlk/conf/layer.conf  |4 ++--
 12 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/meta-cedartrail/conf/layer.conf b/meta-cedartrail/conf/layer.conf
index c19c4c1..0166b35 100644
--- a/meta-cedartrail/conf/layer.conf
+++ b/meta-cedartrail/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "cedartrail"
diff --git a/meta-chiefriver/conf/layer.conf b/meta-chiefriver/conf/layer.conf
index 5dc3c02..6164f99 100644
--- a/meta-chiefriver/conf/layer.conf
+++ b/meta-chiefriver/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "chiefriver"
diff --git a/meta-crownbay/conf/layer.conf b/meta-crownbay/conf/layer.conf
index cb17298..e6cc2a0 100644
--- a/meta-crownbay/conf/layer.conf
+++ b/meta-crownbay/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "crownbay"
diff --git a/meta-emenlow/conf/layer.conf b/meta-emenlow/conf/layer.conf
index dda80c0..7675fbd 100644
--- a/meta-emenlow/conf/layer.conf
+++ b/meta-emenlow/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a packages directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "emenlow"
diff --git a/meta-fishriver/conf/layer.conf b/meta-fishriver/conf/layer.conf
index 61e292b..977ea8a 100644
--- a/meta-fishriver/conf/layer.conf
+++ b/meta-fishriver/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "fishriver"
diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
index 4d140f9..0bb29a1 100644
--- a/meta-fri2/conf/layer.conf
+++ b/meta-fri2/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "fri2"
diff --git a/meta-jasperforest/conf/layer.conf 
b/meta-jasperforest/conf/layer.conf
index 09f1647..6d096e7 100644
--- a/meta-jasperforest/conf/layer.conf
+++ b/meta-jasperforest/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "jasperforest"
diff --git a/meta-n450/conf/layer.conf b/meta-n450/conf/layer.conf
index 2c905c2..f4022c9 100644
--- a/meta-n450/conf/layer.conf
+++ b/meta-n450/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a packages directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
  

[yocto] Help needed understanding do_rootfs error

[Chris Tapp]

The log for do_rootfs is showing:

ERROR: Function failed: do_rootfs (see 
/media/SSD-RAID/build-denzil-pi/tmp/work/raspberrypi-poky-linux-gnueabi/sjs-x11-image-1.0-r0/temp/log.do_rootfs.8633
 for further information)
Generating solve db for 
/media/SSD-RAID/build-denzil-pi/tmp/deploy/rpm/raspberrypi...
   total:   1  0.00 MB  1.252061 secs
   fingerprint:  1878  0.011180 MB  0.035400 secs
   install:   626  0.00 MB  0.509277 secs
   dbadd: 626  0.00 MB  0.498577 secs
   dbget:2845  0.00 MB  0.004722 secs
   dbput: 626  2.976128 MB  0.437150 secs
   readhdr:  6261  5.865680 MB  0.016813 secs
   hdrload:  3130  8.701488 MB  0.011505 secs
   hdrget: 112989  0.00 MB  0.079470 secs
Generating solve db for 
/media/SSD-RAID/build-denzil-pi/tmp/deploy/rpm/armv6-vfp...
   total:   1  0.00 MB 10.453264 secs
   fingerprint: 15498  0.161164 MB  0.564440 secs
   install:  5166  0.00 MB  4.552602 secs
   dbadd:5166  0.00 MB  4.466703 secs
   dbget:   51868  0.107568 MB  0.058265 secs
   dbput:5166 25.200376 MB  3.996021 secs
   readhdr: 51661 50.213234 MB  0.411257 secs
   hdrload: 27384 81.464842 MB  0.083968 secs
   hdrget: 926377  0.00 MB  0.500559 secs
Generating solve db for /media/SSD-RAID/build-denzil-pi/tmp/deploy/rpm/all...
   total:   1  0.00 MB  0.061929 secs
   fingerprint:66  0.000926 MB  0.006248 secs
   install:22  0.00 MB  0.024989 secs
   dbadd:  22  0.00 MB  0.023312 secs
   dbget: 186  0.00 MB  0.000215 secs
   dbput:  22  0.103992 MB  0.010762 secs
   readhdr:   221  0.208192 MB  0.001765 secs
   hdrload:   113  0.315548 MB  0.000311 secs
   hdrget:   3236  0.00 MB  0.001714 secs
Generating solve db for /media/SSD-RAID/build-denzil-pi/tmp/deploy/rpm/all...
   total:   1  0.00 MB  0.055491 secs
   fingerprint:66  0.000926 MB  0.001160 secs
   install:22  0.00 MB  0.024206 secs
   dbadd:  22  0.00 MB  0.022726 secs
   dbget: 186  0.00 MB  0.000272 secs
   dbput:  22  0.103992 MB  0.011892 secs
   readhdr:   221  0.208192 MB  0.000313 secs
   hdrload:   113  0.315548 MB  0.000336 secs
   hdrget:   3236  0.00 MB  0.002112 secs
Processing task-core-boot...
Processing dropbear...
Processing task-core-x11-base...
Processing task-core-ssh-dropbear...
Processing task-x...
error: Failed dependencies:
libGL.so.1 is needed by libglut3-7.11-r13.2.armv6
libGL.so.1 is needed by column-wallboard-1.0-r1.armv6
libGL.so.1 is needed by libglu1-7.11-r13.2.armv6

libGL is showing in the work area, so I think I just need to add a dependency. 
But what and where?

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

Re: [yocto] RFC: poky-tiny: init procedure

[Darren Hart]

On 06/14/2012 12:11 AM, Tomas Frydrych wrote:
> Hi Darren,
> 
> On 14/06/12 01:33, Darren Hart wrote:
>> o Do not include the standard Busybox init
> ...
>> o Do not provide inittab functionality
> 
> I am not entirely clear what you are hoping to gain by creating a home
> grown init solution?

Calling it an init "solution" is a bit of a stretch. It's really the
absence of an init system. It's what is there in place of an init
system. Just enough to get the system up.

The gain is really to allow people to do whatever they want here,
without having to undo a major piece like init first. Clean slate.

> 
> A system that runs nothing but a shell is really not useful for anything
> all, everyone using it will be adding some sort of services, so the
> question of how the extending works (or does not work), needs to be in
> the forefront of the design.

Agreed. I thought Tim's proposal of an rc.local script for customization
was a good answer to that question. Anything beyond this and people
should really just use the traditional init system.

> My main reservation is that you are
> suggesting to break one of the basic premisses behind the whole
> ecosystem, namely that if I add a package that provides a service to an
> image, I get that service running; 'fix by documentation' is never a fix.

This is a valid point. However, for something like poky-tiny that is
meant as a building block, and not an ultimate solution, documenting the
process of extending it seems to be a very reasonable thing to me (in
fact it's really required).

> So back to my original question, what are the expected benefits to the
> Poky users of not using initd in such minimal systems, and do you have
> any numbers to show it is worth it?

I don't have numbers for init specifically, and those would be good to
generate.

However, right now poky-tiny just executes /bin/sh, has no job control,
and panics if the shell exits. This solution improves the kick-the-tires
experience with poky-tiny, without pulling in all of init, and provides
a better defined launch point for custom development.

> Maybe the numbers are compelling,
> but considering that currently Poky does not even support systemd,
> adding yet another, home grown, init system seems like a step in the
> wrong direction

Again, we're talking about 14 lines of shell, so "init system" is
overstating it significantly.

> (perhaps sorting out the systemd mess is an opportunity
> to deal with the init sequence in a more generic way).

Agreed, that would be nice, but probably orthogonal to this.

> 
> (I hear what you are saying about a system that only includes packages
> you want and nothing else, but this is orthogonal to the system size;

If so, then it's an ample intersection where they cross :-)

> I
> for one want to be able to create a midsized system that includes only
> packages that I want and nothing else. :) )

I would think the default poky and core-image-minimal would serve that
goal very well.

Thank you for the comments.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


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

Re: [yocto] [OE-core] [PATCH 2/3] busybox: Add setsid and cttyhack for tiny DISTRO_FEATURE

[Darren Hart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 06/13/2012 11:58 PM, Khem Raj wrote:
> On 6/13/2012 10:21 PM, Darren Hart wrote:
>> At some point poky-tiny may need to come into oe-core, until 
>> then...
> 
> why do you think so. micro is also a distro with similar goals
> lives outside of OE-Core infact any distros live outside oe-core

Note I'm not arguing for it one way or the other. I could see people
wanting it to come in with linux-yocto-tiny already in oe-core. Or, it
might make more sense to move linux-yocto-tiny to meta-yocto and just
keep it all contained in meta-yocto. That's fine with me too.

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP2lNoAAoJEKbMaAwKp364GmwH/3wmP5TTnZ2oReLwaNFOkdCh
aKMr7EVm0ZOfb2j8vS2oRBg3C5AQ4aV7CR3w3OmXt+0tRlTF2P/M5XT2WgB90YUA
aeFM9znTs4DWSkUHw0Kr9O+kmb2WE6jXJUMxcmk9rId03XhykZBKKjVjUQXON8hQ
oL8u3s83IOL1fPLIUbJEg28LuOW25O0jQftZBeAqiX5tG8nC10m0HZFry0FqN/UG
MggLVSmUOEVioS1Z3rYHxValFqs/LFEtr3B+8sEgILFOM+kKE0LbJUbup2vS1eoh
YbhA2pzPsqLKswJAdkgv11QLvJ0fT9osrsBTUe7uIEPJHQG0YRawIFk8pS8BxZU=
=OZf4
-END PGP SIGNATURE-
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] live image types and qemu machines

[Darren Hart]

On 06/14/2012 08:09 AM, Barros Pena, Belen wrote:
> Hi all,
> 
> The current Hob allows you to build images for a qemu machine selecting
> 'live' as your image type. To me (with my pitiful knowledge) this doesn't
> make much sense: would I want to deploy an image built for a
> virtualisation environment in a real piece of hardware?
> 
> So here goes a question: should we allow Hob users, who are mainly people
> new to the Yocto project, to select the 'live' image type when building
> images for qemu machines?
> 

In my opinion: YES. The reason is that this allows you to test the live
image format and the boot mechanism on virtualized hardware. This is a
valuable development tool.

--
Darren

> This might sound like a silly question, but it has a pretty big impact on
> the Settings dialog and on the number of variations we need to create for
> our 'Image details' screen, which appears after the build finishes and
> displays logical next steps (like run the image or deploy your image to
> external storage).
> 
> Any help with this would be much appreciated.
> 
> Thanks!
> 
> Belen
> 
> 
> 
> 
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


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

Re: [yocto] Help needed understanding do_rootfs error

[Chris Tapp]

On 14 Jun 2012, at 21:44, Chris Tapp wrote:

> The log for do_rootfs is showing:
> < snip >
> error: Failed dependencies:
>   libGL.so.1 is needed by libglut3-7.11-r13.2.armv6
>   libGL.so.1 is needed by column-wallboard-1.0-r1.armv6
>   libGL.so.1 is needed by libglu1-7.11-r13.2.armv6
> 
> libGL is showing in the work area, so I think I just need to add a 
> dependency. But what and where?

Ah, there was an ERROR right at the start of the build saying there were 
multiple providers for virtual/libgl (mesa-xlib, mesa-dri). How can I track 
down the cause of this? Building virtual/libgl doesn't get this error - it only 
shows when I build the full image.

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

[yocto] Setting architecture of only DEB files (arm vs armel)

[Tyler Jones]

I am compiling a distro for my hardware using DEBs for my package
management. In meta/classes/package_deb.bbclass I need DPKG_ARCH = "armel"
instead of TARGET_ARCH (which is "arm"). When I run dpkg on my device armel
is the architecture, not arm, but yocto wants my TARGET_ARCH to be set to
"arm". Is there a non hackish way to do this from my BSP layer or config
file?

The dpkg error I get is:
  package architecture (arm) does not match system (armel)

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

Re: [yocto] live image types and qemu machines

[An, LimingX L]

Hi Belen,

I only know there have two variables we get from the bitbake to charge which 
image is runnable, now.
"RUNNABLE_IMAGE_TYPES" = ext3, ext2, "RUNNABLE_MACHINE_PATTERNS" = qemu.

Thanks!
--
Liming
-Original Message-
From: Barros Pena, Belen 
Sent: Thursday, June 14, 2012 11:09 PM
To: yocto@yoctoproject.org; An, LimingX L
Subject: live image types and qemu machines

Hi all,

The current Hob allows you to build images for a qemu machine selecting 'live' 
as your image type. To me (with my pitiful knowledge) this doesn't make much 
sense: would I want to deploy an image built for a virtualisation environment 
in a real piece of hardware?

So here goes a question: should we allow Hob users, who are mainly people new 
to the Yocto project, to select the 'live' image type when building images for 
qemu machines?

This might sound like a silly question, but it has a pretty big impact on the 
Settings dialog and on the number of variations we need to create for our 
'Image details' screen, which appears after the build finishes and displays 
logical next steps (like run the image or deploy your image to external 
storage).

Any help with this would be much appreciated.

Thanks!

Belen




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

[yocto] How to build an Qt demo application in Yocto (qt4-demo-image)

[Kha]

1. cd to a /usr/bin/qtopia/demos/mainwindow  (for example)
2. (qmake -project)
3. qmake -o Makefile mainwindow.pro
3'. (uic ui files)
4. make

I do 4 steps above and build successfully a Qt demo program on PC, but in
qt4-demo-image, there are a lot of errors

Can anyone solve this problem

http://imageshack.us/photo/my-images/16/20120613234840.jpg/

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

Re: [yocto] How to build an Qt demo application in Yocto (qt4-demo-image)

[Khem Raj]

On Thu, Jun 14, 2012 at 7:29 PM, Kha  wrote:
>
> I do 4 steps above and build successfully a Qt demo program on PC, but in
> qt4-demo-image, there are a lot of errors
>
> Can anyone solve this problem
>
> http://imageshack.us/photo/my-images/16/20120613234840.jpg/
>
> --

what steps did you use when using yocto ?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/2] meta-emenlow: fix for bug 2507

[tom . zanussi]

From: Tom Zanussi 

The recent upgrade of cairo to 1.12.2 broke meta-emenlow; keeping
the old 1.10.2 recipe around in the meta-emenlow layer gets it
working again.

The following changes since commit bd00e28dd54b06a1f01f186be168d3af872f96d4:
  Richard Purdie (1):
meta-emenlow: Update qt4 bbappend to 4.8.1

are available in the git repository at:

  git://git.yoctoproject.org/meta-intel.git tzanussi/2507-fix
  http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/2507-fix

Tom Zanussi (2):
  meta-emenlow: add 1.10.2 cairo recipe
  meta-emenlow: prefer 1.10.2 cairo

 meta-emenlow/conf/machine/emenlow.conf |1 +
 .../recipes-graphics/cairo/cairo_1.10.2.bb |   39 
 2 files changed, 40 insertions(+), 0 deletions(-)
 create mode 100644 meta-emenlow/recipes-graphics/cairo/cairo_1.10.2.bb

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

[yocto] [PATCH 1/2] meta-emenlow: add 1.10.2 cairo recipe

[tom . zanussi]

From: Tom Zanussi 

The emenlow graphics stack doesn't work with the cairo_1.12.2 library
upgrade; this adds the old 1.10.2 recipe from poky locally to the
emenlow layer in order to get it working again.

Fixes [YOCTO #2507]

Signed-off-by: Tom Zanussi 
---
 .../recipes-graphics/cairo/cairo_1.10.2.bb |   39 
 1 files changed, 39 insertions(+), 0 deletions(-)
 create mode 100644 meta-emenlow/recipes-graphics/cairo/cairo_1.10.2.bb

diff --git a/meta-emenlow/recipes-graphics/cairo/cairo_1.10.2.bb 
b/meta-emenlow/recipes-graphics/cairo/cairo_1.10.2.bb
new file mode 100644
index 000..c832417
--- /dev/null
+++ b/meta-emenlow/recipes-graphics/cairo/cairo_1.10.2.bb
@@ -0,0 +1,39 @@
+require recipes-graphics/cairo/cairo.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77"
+
+PR = "r0"
+
+SRC_URI = "http://cairographics.org/releases/cairo-${PV}.tar.gz";
+
+SRC_URI[md5sum] = "f101a9e88b783337b20b2e26dfd26d5f"
+SRC_URI[sha256sum] = 
"32018c7998358eebc2ad578ff8d8559d34fc80252095f110a572ed23d989fc41"
+
+PACKAGES =+ "cairo-gobject cairo-script-interpreter cairo-perf-utils"
+
+SUMMARY_${PN} = "The Cairo 2D vector graphics library"
+DESCRIPTION_${PN} = "Cairo is a multi-platform library providing anti-aliased \
+vector-based rendering for multiple target backends. Paths consist \
+of line segments and cubic splines and can be rendered at any width \
+with various join and cap styles. All colors may be specified with \
+optional translucence (opacity/alpha) and combined using the \
+extended Porter/Duff compositing algebra as found in the X Render \
+Extension."
+
+SUMMARY_cairo-gobject = "The Cairo library GObject wrapper library"
+DESCRIPTION_cairo-gobject = "A GObject wrapper library for the Cairo API."
+
+SUMMARY_cairo-script-interpreter = "The Cairo library script interpreter"
+DESCRIPTION_cairo-script-interpreter = "The Cairo script interpreter 
implements \
+CairoScript.  CairoScript is used by tracing utilities to enable the ability \
+to replay rendering."
+
+DESCRIPTION_cairo-perf-utils = "The Cairo library performance utilities"
+
+FILES_${PN} = "${libdir}/libcairo.so.*"
+FILES_${PN}-dev += "${libdir}/cairo/*.la ${libdir}/cairo/*.so"
+FILES_${PN}-dbg += "${libdir}/cairo/.debug"
+FILES_${PN}-staticdev += "${libdir}/cairo/*.a"
+FILES_cairo-gobject = "${libdir}/libcairo-gobject.so.*"
+FILES_cairo-script-interpreter = "${libdir}/libcairo-script-interpreter.so.*"
+FILES_cairo-perf-utils = "${bindir}/cairo-trace 
${libdir}/cairo/libcairo-trace.so.*"
-- 
1.7.0.4

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

[yocto] [PATCH 2/2] meta-emenlow: prefer 1.10.2 cairo

[tom . zanussi]

From: Tom Zanussi 

emenlow needs to use the old 1.10.2 cairo library instead of the
upgraded version.

Fixes [YOCTO #2507]

Signed-off-by: Tom Zanussi 
---
 meta-emenlow/conf/machine/emenlow.conf |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/meta-emenlow/conf/machine/emenlow.conf 
b/meta-emenlow/conf/machine/emenlow.conf
index 1362434..26ca43b 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -18,6 +18,7 @@ PREFERRED_PROVIDER_virtual/xserver-xf86 = "xserver-psb"
 PREFERRED_PROVIDER_mesa-dri = "xpsb-glx"
 PREFERRED_VERSION_libva ?= "0.31.0"
 PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
+PREFERRED_VERSION_cairo ?= "1.10.2"
 XSERVER ?= "xserver-psb \
xserver-psb-extension-dri \
xserver-psb-extension-dri2 \
-- 
1.7.0.4

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

Re: [yocto] Help needed understanding do_rootfs error

[Tomas Frydrych]

Hi,

On 14/06/12 22:42, Chris Tapp wrote:
> On 14 Jun 2012, at 21:44, Chris Tapp wrote:
> 
>> The log for do_rootfs is showing: < snip > error: Failed
>> dependencies: libGL.so.1 is needed by libglut3-7.11-r13.2.armv6 
>> libGL.so.1 is needed by column-wallboard-1.0-r1.armv6 libGL.so.1 is
>> needed by libglu1-7.11-r13.2.armv6
>> 
>> libGL is showing in the work area, so I think I just need to add a
>> dependency. But what and where?

There should be no GL on RPI at all, the HW drivers only support GLES/2,
so the short answer is you can't pull in packages that require GL (in
theory you could build mesa with the software rasterizer, but you will
get unacceptable performance, and in the presence of GLES2 that makes no
sense anyway).

Incidentally, the GLES libs are not currently packaged by
meta-raspberrypi, I submitted a pull request for this yesterday.


> Ah, there was an ERROR right at the start of the build saying there
> were multiple providers for virtual/libgl (mesa-xlib, mesa-dri). How
> can I track down the cause of this? Building virtual/libgl doesn't
> get this error - it only shows when I build the full image.

In general, mesa-xlib provides a software GLX emulation, mesa-dri
provides glx based on the GLX extension and each machine conf needs to
choose a preferred provider for virtual/libgl to get rid of this error.
However, in the RPI case, no virtual/libgl should be getting pulled into
the images.

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

Re: [yocto] Setting architecture of only DEB files (arm vs armel)

[Khem Raj]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/14/2012 5:17 PM, Tyler Jones wrote:
> I am compiling a distro for my hardware using DEBs for my package 
> management. In meta/classes/package_deb.bbclass I need DPKG_ARCH =
> "armel" instead of TARGET_ARCH (which is "arm"). When I run dpkg on
> my device armel is the architecture, not arm, but yocto wants my
> TARGET_ARCH to be set to "arm". Is there a non hackish way to do
> this from my BSP layer or config file?
> 
> The dpkg error I get is: package architecture (arm) does not match
> system (armel)
> 

set DPKG_ARCH = "armel" in your local.conf

> -Tyler Jones
> 
> 
> 
> 
> ___ yocto mailing list 
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/a06sACgkQuwUzVZGdMxRBvgCeJAinKceaUDI8gQHPbvzGiOSt
tuQAnRDOpYZvovXfg6UHji6it4YehqvR
=7G4e
-END PGP SIGNATURE-
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: poky-tiny: init procedure

[Tomas Frydrych]

Hi Darren,

On 14/06/12 22:09, Darren Hart wrote:
> This solution improves the kick-the-tires
> experience with poky-tiny, without pulling in all of init, 

I think you really should quantify what 'all of init' means, without
this you are addressing a problem that is merely perceived. Just a quick
look shows that the sysvinit package is about 120KB unpacked, for that
you get a solution that is tested, robust, and supported across Yocto.


> Again, we're talking about 14 lines of shell, so "init system" is
> overstating it significantly.

Sure, but every new wheel starts exactly this way, and we are already
discussing how to make it do things that sysvinit does for you :-)


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