Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.4 status - 20 min (Song/team)
* SWAT team rotation: LaurentiuP -> Ioana Grigoropol
* Opens - 10 min
* Team Sharing - 20 min


-----Original Appointment-----

We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html

Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
76994298
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x76994298#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 89957777 Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 26, 2012
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 21, 2013, 10:40 AM CDT

Thanks, Gary!  That did the trick.

On 2012-12-03 12:01, r10kindsofpeople wrote:

I seem to have figured out how to add the dhcp-server to my image, including my own dhcpd.conf and default-server files by creating a "dhcp_4.2.4-P1.bbappend" recipe. Everything
works, except the dhcp-server doesn't run on boot.

If I login and run "update-rc.d dhcp-server defaults" on the target, then it creates the entries in /etc/rc0.d (etc) and the service starts on the next boot.

The question is, how can I get bitbake to create those entries when it creates the image? I'm open to completely different ways of going about this as well. Looking at other
recipes, I thought this recipe would do, but it doesn't:

{named dhcp_4.2.4-P1.bbappend}
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

inherit update-rc.d

INITSCRIPT_NAME = "dhcp-server"
INITSCRIPT_PARAMS = "defaults"

# Not sure this is needed, since I'm not adding files, just replacing the default copies
SRC_URI += "file://dhcpd.conf \
file://default-server \
"
{end file}

I'm using the 8.0 "danny" release with Crown-bay BSP. The "layer.conf" file includes IMAGE_INSTALL_append = " dhcp-server" (among other things).

Thanks in advance for any assistance you can offer,

You just missed one piece. I have this working using these extra lines in my .bbappend:

inherit update-rc.d
INITSCRIPT_PACKAGES = "dhcp-server"
INITSCRIPT_NAME = "dhcp-server"
INITSCRIPT_PARAMS = "start 50 S . stop 50 0 6 1 ."

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

I seem to have figured out how to add the dhcp-server to my image, including my own dhcpd.conf and default-server files by creating a "dhcp_4.2.4-P1.bbappend" recipe.  Everything works, except the dhcp-server doesn't run on boot.  

On 12/03/2012 09:43 AM, Tomas Frydrych wrote:

On 02/12/12 22:51, Scott Garman wrote:

Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.

This meta-yocto setup is intentional (there was thread about that a
while back). meta-yocto is a distro layer, and for any distro layer it
is reasonable to enforce its own precedence over any other layers is may
use, and meta-yocto chooses to do this. Non-distro layers, including all
bsp layers, are expected to always use an append operation so that they
can be stacked together.

Thanks for the concise explanation.

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Hi Marco,

Can you filed a bug about this in bugzilla? Also, you don't need to sudo to run the install script, if you choose the default location which is /opt/poky/1.3, it'll prompt you for the password, or you can specify a directory under your $HOME dir. In your bug, can you provide some detail how you build the toolchain, e.g. the local.conf file changes, etc.?

Thanks,
Jessica

On 02/12/12 22:51, Scott Garman wrote:

Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.

This meta-yocto setup is intentional (there was thread about that a
while back). meta-yocto is a distro layer, and for any distro layer it
is reasonable to enforce its own precedence over any other layers is may
use, and meta-yocto chooses to do this. Non-distro layers, including all
bsp layers, are expected to always use an append operation so that they
can be stacked together.

Tomas

--
http://sleepfive.com

All,

Is there a simple way to disable the use of PREMIRRORS and MIRRORS
within a recipe?

(Perhaps the answer here might be worth mentioning in Section 12.23 of the
Poky Reference Manual?)

My use case for this is the situation where the code hasn't been released yet,
so there's no point in checking mirrors.

Thank you,
Jon

Hi,
after build meta-toolchain (for beagleboard, for example) I have this script

15:32 koan@quad:~/yocto-8-danny/poky/build
$ ll tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh
-rwxr-xr-x 1 koan koan 16143 2012-12-03 15:25 tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh

Then I argued I had to launch it to install the Yocto toolchain, but I get an error

15:32 koan@quad:~/yocto-8-danny/poky/build
$ sudo tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh
[sudo] password for koan:
Enter target directory for SDK (default: /opt/poky/1.3):
You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
Extracting SDK...done
Setting it up...find: `/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/lib': No such file or directory
SDK could not be set up. Relocate script failed. Abort!

What's wrong?
I wasn't able to find any document about it in YP website.

TIA
--
Marco

I've been running into "Fetcher failures" for my recipes using
mercurial recently. They only seem to crop up the first time a package
that comes from a hg repo is fetched.

I believe the issue stems from the combination of the arguments used
by the hg fetcher and the fact that I specified a tag rather than
revision number.

I've included a "trimmed" log at the end of this post, where I've
pruned out useless and personal information. Here are some of of my
comments and questions. I'm no mercurial expert, so please do correct
me if and where I'm wrong!

- Why is GIT_CONFIG being exported for mercurial invocations?
- I think the 'clone -r v1.1.0' followed by the 'update -C -r v1.1.0'
is possibly responsible for the failure.
- In mercurial, the tag is a commit after the revision that's being tagged.
tip 41:58b8f368be68
v1.1.0 40:a925b596c163
v1.0.4 39:6bf84da2571e
- In the above, rev 41 contains the action of tagging 40 as 'v1.1.0'
- Therefore, if we clone the version associated with tag v1.1.0, we
get rev 40 and earlier. At this point, there's no "knowledge" of there
being a 'v1.1.0' tag!
- As such, the 'hg update -C -r v1.1.0' that follows the 'hg clone
-r v1.1.0' fails.

- One possible fix might be to remove the "-r <rev>" usage from the hg
fetcher. (lines 101 and 102 in bitbake/lib/bb/fetch2/hg.py)
- A fetch always follows an update to the revision anyway, doesn't
it. (Per comment @ lines 142-143).
- Con: You have to fetch the whole darn repo. It makes sense that we
wouldn't want to do that when we don't have to. :)
- Pro: You'll have the revision you wanted.
- Disclaimer: I'm not familiar enough with this code to know whether
this would cause undesired side effects or break things!

- Workaround: Don't use tags in SRCREV
- This stinks, because I like to write my .bb's as follows, so that
updating a version is just a matter of copy/renaming the .bb
require <my_package>.inc
PR = "${INC_PR}.0"
SRCREV = "v${PV}"

DEBUG: Fetch: checking for module directory
'/export/home/jon/projects/yocto/poky/build/test/downloads/hg/host/some_dir/my_package'
NOTE: Fetch hg://hg@host/some_dir;module=my_package;protocol=ssh
DEBUG: Running /usr/bin/env hg clone -r v1.1.0
ssh://hg@host/some_dir/my_package my_package
DEBUG: Fetcher accessed the network with the command /usr/bin/env hg
clone -r v1.1.0 ssh://hg@host/some_dir/my_package my_package
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export
GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>";
/usr/bin/env hg clone -r v1.1.0 ssh://hg@host/some_dir/my_package
my_package
DEBUG: Running /usr/bin/env hg update -C -r v1.1.0
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export
GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>";
/usr/bin/env hg update -C -r v1.1.0
WARNING: Failed to fetch URL
hg://hg@host/some_dir;module=my_package;protocol=ssh, attempting
MIRRORS if available
DEBUG: Fetcher failure: Fetch command failed with exit code 255, output:
abort: unknown revision 'v1.1.0'!

DEBUG: Python function base_do_fetch finished
DEBUG: Python function do_fetch finished
ERROR: Function failed: Fetcher failure for URL:
'hg://hg@host/some_dir;module=my_package;protocol=ssh'. Unable to
fetch URL from any source.


Thank you,
Jon

Hello,

according to the documentation [1] the right way to debug applications
on the target is to load the target library information in GDB using

set solib-absolute-prefix /path/to/tmp/rootfs

i. e. referring it to the libraries in the target root file system
image. Assuming the target root file system uses by defualt stripped
libraries, we need to set up a copy of the rootfs with debug
information included.

But do we really have to? Why cannot we use the libraries present in
the SDK's sysroot directory (i. e. what OECORE_TARGET_SYSROOT points
to) ?

Trying to do so, we see that it fails. Our current suspicion is that
maybe prelinking of the target images and libraries introduces some
incompatibility. Is this a reasonable assumption, and if so, is this
a problem that should be fixed, or unavoidable for some reason? Or is
there a problem with the libraries in OECORE_TARGET_SYSROOT ?

All help welcome - thanks in advance.

[1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdb


Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Beware of bugs in the above code; I have only proved it correct, not
tried it." - Donald Knuth

Hi Ross,

On 3 Dec 2012, at 09:51, Burton, Ross wrote:

On 1 December 2012 22:39, Chris Tapp <opensource@keylevel.com> wrote:

Is there a recipe available for a library which can load image files into memory / GL textures?

Into memory, the lowest level would be libjpeg or libpng, but then
it's your responsibility to match the pixel formats.

If you're using GL and you don't have a higher level abstraction, you
might want to look at Cogl (GL specifics abstraction and sanity layer)
or Clutter (toolkit based on Cogl). Both of these are in oe-core.

Thanks, I'll have a look at that.

I've been using libsdl-image to get me going as I can use that to get at the image data and it's fairly easy to work out the pixel format.

Ross

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Hi Ross,

On 3 Dec 2012, at 09:51, Burton, Ross wrote:

On 1 December 2012 22:39, Chris Tapp <opensource@keylevel.com> wrote:

Is there a recipe available for a library which can load image files into memory / GL textures?

Into memory, the lowest level would be libjpeg or libpng, but then
it's your responsibility to match the pixel formats.

If you're using GL and you don't have a higher level abstraction, you
might want to look at Cogl (GL specifics abstraction and sanity layer)
or Clutter (toolkit based on Cogl). Both of these are in oe-core.

Thanks, I'll have a look at that.

I've been using libsdl-image to get me going as I can use that to get at the image data and it's fairly easy to work out the pixel format.

Ross

Chris Tapp

opensource@keylevel.com
www.keylevel.com

On Monday 03 December 2012 03:16:10 Robert P. J. Day wrote:

On Sun, 2 Dec 2012, Paul Eggleton wrote:

On Sunday 02 December 2012 15:35:54 you wrote:

On 12/02/2012 03:24 PM, Paul Eggleton wrote:

On Sunday 02 December 2012 14:51:28 Scott Garman wrote:

Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this
different
ordering in meta-yocto's layer.conf, I will submit a patch to make
this
more consistent.

I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"

Oh? Would this apply just to meta-yocto or all layer.conf files?

All, really. Functionally it makes no real difference, but I think it's
preferred stylistically based on previous discussions.

hang on ... i thought the ordering of BBPATH would affect the
processing of "include" directives. no?

Yes, it does. What I mean is, functionally _within layer.conf_ the following
two are equivalent:

BBPATH := "${BBPATH}:${LAYERDIR}"

BBPATH .= ":${LAYERDIR}"

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On 1 December 2012 22:39, Chris Tapp <opensource@keylevel.com> wrote:

Is there a recipe available for a library which can load image files into memory / GL textures?

Into memory, the lowest level would be libjpeg or libpng, but then
it's your responsibility to match the pixel formats.

If you're using GL and you don't have a higher level abstraction, you
might want to look at Cogl (GL specifics abstraction and sanity layer)
or Clutter (toolkit based on Cogl). Both of these are in oe-core.

Ross

On Sun, 2 Dec 2012, Paul Eggleton wrote:

On Sunday 02 December 2012 15:35:54 you wrote:

On 12/02/2012 03:24 PM, Paul Eggleton wrote:

On Sunday 02 December 2012 14:51:28 Scott Garman wrote:

Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.

I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"

Oh? Would this apply just to meta-yocto or all layer.conf files?

All, really. Functionally it makes no real difference, but I think it's
preferred stylistically based on previous discussions.

hang on ... i thought the ordering of BBPATH would affect the
processing of "include" directives. no?

rday

--

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

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

On Sunday 02 December 2012 15:35:54 you wrote:

On 12/02/2012 03:24 PM, Paul Eggleton wrote:

On Sunday 02 December 2012 14:51:28 Scott Garman wrote:

Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.

I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"

Oh? Would this apply just to meta-yocto or all layer.conf files?

All, really. Functionally it makes no real difference, but I think it's
preferred stylistically based on previous discussions.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On 12/02/2012 03:24 PM, Paul Eggleton wrote:

On Sunday 02 December 2012 14:51:28 Scott Garman wrote:

Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.

I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"

Oh? Would this apply just to meta-yocto or all layer.conf files?

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

On Sunday 02 December 2012 14:51:28 Scott Garman wrote:

Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.

I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre