Date   

librt within Yocto Recipe (beagle)

Thomas Besemer
 

I'm working with Beagleboard right now, stock top of tree from Yocto
pull. GCC 4.7.2 builds fine.

I am able to use tools built during this process to link with librt
(-lrt) (as librt is in), but can't figure out how to do it from within
a Yocto/OE recipe. I created a recipe to build my application, but it
complains that I don't have dependencies for librt (wants something).
My recipe:

DESCRIPTION = "GCPY Server application"
SECTION = "gcsim"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PV = "1_0"

SRC_URI = "file://gcpy.tar"

S = "${WORKDIR}"

do_install() {
install -d ${D}${base_libdir}
install -m 0755 libgcpy_gc6016.so ${D}${base_libdir}
install -d ${D}${bindir}
install -m 0755 gcpy_gc6016_server ${D}${bindir}
}

There is a Makefile within tarball, and when I use the Yocto generated
tools outside of Yocto, builds fine. Thus, I know librt is present
(and I see it).

What do I need in recipe to make this work?


Build external module against Yocto kernel

Patrick Turley <PatrickTurley@...>
 

I have to build a module from a third-party that has nothing to do with Yocto.

I want to build this module against the kernel Yocto is giving me.

The Make file for this module has a build command like this:

make -C $(LINUX_DIR) M=`pwd` $(ENV) \
EXTRA_CFLAGS="$(EXTRA_CFLAGS)" modules

Obviously, this command needs to connect with either the Linux source tree or something like a "kernel-headers" package.

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Unfortunately, I don't see a "kernel-header" equivalent in there.

This leads me to imagine I must point this command at some sub-tree within the Yocto output (probably under tmp/sysroots). And, if I want that tree available elsewhere, I have to package it up into a tarball and transport it.

Usually, Yocto is way ahead of me on these sorts of things, and there's already a graceful way to deal with this -- I just haven't figure it out yet.

What am I missing?


YP Linux Kernel Development Manual

Rifenbark, Scott M <scott.m.rifenbark@...>
 

All,

There is a new YP manual under development. It is a development manual for Linux kernels in the YP. Darren Hart is the original author of the manual as you probably know. It is still being worked on but it is in HTML form and now part of the yocto-docs/master branch. It is published at http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html. Feel free to access it and comment.

Thanks,
Scott

Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)


Agenda: Yocto Project Technical Team Meeting - Tuesday, January 15, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Liu, Song <song.liu@...>
 

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto Project 1.2.2 status - 10 min (Scott/AlexG)
* Yocto Project 1.3.1 status - 10 min (Ross)
* Yocto 1.4 status - 10 min (Song/team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Overview
* SWAT team rotation: Radu Moisan -> Constantin Musca
* 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


Agenda: Yocto Project Technical Team Meeting - Tuesday, January 15, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Liu, Song <song.liu@...>
 

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto Project 1.2.2 status - 10 min (Scott/AlexG)
* Yocto Project 1.3.1 status - 10 min (Ross)
* Yocto 1.4 status - 10 min (Song/team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.4_Status#Overview
* SWAT team rotation: Radu Moisan -> Constantin Musca
* 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


Re: SRCPV description

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Thanks for the explanations for this variable all.

Scott

-----Original Message-----
From: Martin Jansa [mailto:martin.jansa@...]
Sent: Monday, January 14, 2013 8:19 AM
To: Jerrod Peach
Cc: Rifenbark, Scott M; Yocto discussion list
Subject: Re: [yocto] SRCPV description

On Mon, Jan 14, 2013 at 10:10:58AM -0500, Jerrod Peach wrote:
On Mon, Jan 14, 2013 at 9:52 AM, Rifenbark, Scott M <
scott.m.rifenbark@...> wrote:

Hi,

I need a description of the SRCPV variable for the YP reference
glossary.
I have been told that it is generated and not assigned and that it
is used to define PV values that include the source revisions from
an RCS. By default it is set to the following in the
conf/bitbake.conf file:

SRCPV = "${@bb.fetch2.get_srcrev(d)}"

Can anyone provide more information on this variable?

Thanks,
Scott



Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)

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

Off the top of my head, I know SRCPV is a combination of the VCS type
and revision used in the actual build. Most interestingly, SRCPV will
always contain the real revision used in the build, even if ${AUTOREV}
is specified as the SRCREV for a given package. Note that if a package
does not include SRCPV somewhere within its recipe, I believe setting
SRCREV to ${AUTOREV} will have no effect, as ${AUTOREV} by itself
simply resolves to the string "AUTOINC", which does not permute the
hash of the recipe.

Note that I'm not really a Yocto expert nor am I sitting with the code
in front of me right now, so someone can jump in if I missed something
or got a detail incorrect. I don't remember the exact format of the
string, but I want to say its a combination of the VCS name, a
Yocto-internal VCS identification number (just like 1 or 2, not some
huge int), and the revision (be it a hash it git or an integer in SVN
or whatever else is used by a supported VCS).
There isn't VCS type in SRCPV (that's why there is always prefix like
1.0+git${SRCPV}, 1.0+svn${SRCPV}). Some recipes even in oe-core are
using wrong prefix like -git or ~git:
meta/recipes-connectivity/ofono/ofono_git.bb:PV = "0.12-git${SRCPV}"
meta/recipes-extended/libzypp/libzypp_git.bb:PV = "0.0-git${SRCPV}"
meta/recipes-extended/sat-solver/sat-solver_git.bb:PV = "0.0-
git${SRCPV}"
meta/recipes-extended/zypper/zypper_git.bb:PV = "1.5.3-git${SRCPV}"
meta/recipes-graphics/mesa/mesa-git.inc:PV = "9.1~git${SRCPV}"

And +git/+gitr, +svn/+svnr prefixes are inconsistently used.

AUTOINC is used instead of LOCALCOUNT only after
http://git.openembedded.org/bitbake/commit/?id=61cf01c5c236b4218f40cfae7
c059c2b86765dbd

And AUTOREV should expand to latest revision in SRCREV even without
SRCPV in recipe (SRCPV is already used in bitbake.conf
meta/conf/bitbake.conf:SRCPV = "${@bb.fetch2.get_srcrev(d)}").

Cheers,

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...


Re: [ANOUNCEMENT] bmaptool

Artem Bityutskiy <dedekind1@...>
 

On Mon, 2013-01-14 at 18:56 +0100, Wolfgang Denk wrote:
Thanks for doing this, as the links on the page referenced above are
broken: both [1] "Introduction" and [2] "Usage" give just a 404 to
me...

[1] https://source.tizen.org/documentation/reference/bmap-tool/bmap-introduction
[2] https://source.tizen.org/documentation/reference/bmap-tool/usage
Very embarrassing, sorry. The links are broken, I'll try to fix them
tomorrow. Please, so far use the links at the left-side frame of the web
page. You should see them there like this:

The bmaptool
* Introduction
* Usage
- bmaptool copy
- bmaptool create
* Bmap-tools project

Sorry for inconvenience. The direct links are:

https://source.tizen.org/documentation/reference/bmaptool/bmap-introduction
https://source.tizen.org/documentation/reference/bmaptool/bmaptool-usage
https://source.tizen.org/documentation/reference/bmaptool/usage/bmaptool-copy
https://source.tizen.org/documentation/reference/bmaptool/usage/bmaptool-create
https://source.tizen.org/documentation/reference/bmaptool/bmap-tools-project

--
Best Regards,
Artem Bityutskiy


Re: [meta-ivi][PATCH 01/23] base-passwd: Modify patch as home directory of root user is /root

Andrei Gherzan
 

On Mon, Jan 7, 2013 at 5:22 AM, ChenQi <Qi.Chen@...> wrote:
Home directory is now configurable now.
You could specify it in local.conf.

See the following commits for more details.

845c2c0 oprofile: use dynamic root home directory
2af073a base-passwd: use configurable root home directory
07b842f base-files: use dynamic root home directory
de5b44a bitbake.conf: import var ROOT_HOME


This bbappend was added to modify the default password of root. And we modify the whole root line from passwd.master which includes the home directory. And as home directory was moved to /home we had to rebase this patch too.

ag


Re: [ANOUNCEMENT] bmaptool

Wolfgang Denk <wd@...>
 

Dear Artem,

In message <1358167593.2731.66.camel@...> you wrote:

Please, read all the details in the project wiki page:
https://source.tizen.org/documentation/reference/bmaptool

The project was created for Tizen IVI, but it is generic and is not
bounded to Tizen in any way.

I do not want to duplicate the bmap-tools documentation here, but
instead, let me just describe how we use it in Tizen IVI.
Thanks for doing this, as the links on the page referenced above are
broken: both [1] "Introduction" and [2] "Usage" give just a 404 to
me...

[1] https://source.tizen.org/documentation/reference/bmap-tool/bmap-introduction
[2] https://source.tizen.org/documentation/reference/bmap-tool/usage


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@...
If the odds are a million to one against something occuring, chances
are 50-50 it will.


Re: Enabling shared state mirrors

McClintock Matthew-B29882 <B29882@...>
 

On Fri, Jan 11, 2013 at 4:06 PM, Thornburg, Christopher A
<christopher.a.thornburg@...> wrote:
Struggling to get shared state mirrors to work. I can see files with the
same file name (and therefore the same hash) in my mirror and, after a
build, in my local sstate cache direcotry. Ala:

/storage/yocto-cache/sstate-toolchain/Ubuntu-10.04/95/sstate-bzip2-native-i686-linux-1.0.6-r5-i686-2-95b6058a3f3f35386c8593e8447c59da_populate-lic.tgz.siginfo

and

<build
dir>/sstate-cache/Ubuntu-10.04/95/sstate-bzip2-native-i686-linux-1.0.6-r5-i686-2-95b6058a3f3f35386c8593e8447c59da_populate-lic.tgz.siginfo



bitbake-diffsigs confirms that the signatures match. I have the following in
my local.conf:

SSTATE_MIRRORS ?= "\

file://.* file:///storage/yocto-cache/sstate-toolchain/PATH \

file://.* file:///storage/yocto-cache/sstate-kernel/PATH"



…and yet bitbake insists on rebuilding everything every time. I had this
working yesterday, and today it fails again.



Any suggestions?
Try running with bitbake -DDD and look for SState: messages. It will
tell you the command used to test for sstate on the mirror and if it
failed/passed.

-M


Re: SRCPV description

Martin Jansa
 

On Mon, Jan 14, 2013 at 10:10:58AM -0500, Jerrod Peach wrote:
On Mon, Jan 14, 2013 at 9:52 AM, Rifenbark, Scott M <
scott.m.rifenbark@...> wrote:

Hi,

I need a description of the SRCPV variable for the YP reference glossary.
I have been told that it is generated and not assigned and that it is used
to define PV values that include the source revisions from an RCS. By
default it is set to the following in the conf/bitbake.conf file:

SRCPV = "${@bb.fetch2.get_srcrev(d)}"

Can anyone provide more information on this variable?

Thanks,
Scott



Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)

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

Off the top of my head, I know SRCPV is a combination of the VCS type and
revision used in the actual build. Most interestingly, SRCPV will always
contain the real revision used in the build, even if ${AUTOREV} is
specified as the SRCREV for a given package. Note that if a package does
not include SRCPV somewhere within its recipe, I believe setting SRCREV to
${AUTOREV} will have no effect, as ${AUTOREV} by itself simply resolves to
the string "AUTOINC", which does not permute the hash of the recipe.

Note that I'm not really a Yocto expert nor am I sitting with the code in
front of me right now, so someone can jump in if I missed something or got
a detail incorrect. I don't remember the exact format of the string, but I
want to say its a combination of the VCS name, a Yocto-internal VCS
identification number (just like 1 or 2, not some huge int), and the
revision (be it a hash it git or an integer in SVN or whatever else is used
by a supported VCS).
There isn't VCS type in SRCPV (that's why there is always prefix like
1.0+git${SRCPV}, 1.0+svn${SRCPV}). Some recipes even in oe-core are
using wrong prefix like -git or ~git:
meta/recipes-connectivity/ofono/ofono_git.bb:PV = "0.12-git${SRCPV}"
meta/recipes-extended/libzypp/libzypp_git.bb:PV = "0.0-git${SRCPV}"
meta/recipes-extended/sat-solver/sat-solver_git.bb:PV = "0.0-git${SRCPV}"
meta/recipes-extended/zypper/zypper_git.bb:PV = "1.5.3-git${SRCPV}"
meta/recipes-graphics/mesa/mesa-git.inc:PV = "9.1~git${SRCPV}"

And +git/+gitr, +svn/+svnr prefixes are inconsistently used.

AUTOINC is used instead of LOCALCOUNT only after
http://git.openembedded.org/bitbake/commit/?id=61cf01c5c236b4218f40cfae7c059c2b86765dbd

And AUTOREV should expand to latest revision in SRCREV even without
SRCPV in recipe (SRCPV is already used in bitbake.conf
meta/conf/bitbake.conf:SRCPV = "${@bb.fetch2.get_srcrev(d)}").

Cheers,

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...


Re: SRCPV description

Robert P. J. Day
 

it might be worth tweaking the comment in fetch2/__init__.py, which
currently reads:

def get_srcrev(d):
"""
Return the version string for the current package
(usually to be used as PV)


no, it's primarily used not *as* PV but in the *construction* of PV,
as in:

meta/conf/bitbake.conf:SRCPV = "${@bb.fetch2.get_srcrev(d)}"
...
meta/recipes-bsp/x-load/x-load_git.bb:PV = "1.5.0+git${SRCPV}"

so, pedantically, that routine is used as SRCPV, which is
subsequently used in the final construction of PV. QED.

rday

--

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

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


Re: SRCPV description

Jerrod Peach <peachj@...>
 

On Mon, Jan 14, 2013 at 9:52 AM, Rifenbark, Scott M <scott.m.rifenbark@...> wrote:
Hi,

I need a description of the SRCPV variable for the YP reference glossary.  I have been told that it is generated and not assigned and that it is used to define PV values that include the source revisions from an RCS.  By default it is set to the following in the conf/bitbake.conf file:

SRCPV = "${@bb.fetch2.get_srcrev(d)}"

Can anyone provide more information on this variable?

Thanks,
Scott



Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)

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

Scott,

Off the top of my head, I know SRCPV is a combination of the VCS type and revision used in the actual build. Most interestingly, SRCPV will always contain the real revision used in the build, even if ${AUTOREV} is specified as the SRCREV for a given package. Note that if a package does not include SRCPV somewhere within its recipe, I believe setting SRCREV to ${AUTOREV} will have no effect, as ${AUTOREV} by itself simply resolves to the string "AUTOINC", which does not permute the hash of the recipe.

Note that I'm not really a Yocto expert nor am I sitting with the code in front of me right now, so someone can jump in if I missed something or got a detail incorrect.  I don't remember the exact format of the string, but I want to say its a combination of the VCS name, a Yocto-internal VCS identification number (just like 1 or 2, not some huge int), and the revision (be it a hash it git or an integer in SVN or whatever else is used by a supported VCS).

Kind regards,

Jerrod


Fullpass Test Report for Yocto 1.2.2 denzil 20130106 Build

Palalau, AlexandruX <alexandrux.palalau@...>
 

 

 

Hello,


Here is the Fullpass Test Report for Yocto 1.2.2 denzil 20130106

There are some new issues regarding the following:

è CBS: libowl fetch still fails and also the lib32 connman-gnome built for qemux86-64 – ipk test fails. Also there are some new fetch issues regarding x32 image build.

è ADT: Clutter C/C++ template issues. Also, there is an issue regarding Yocto BSP tool and headless build.

è Sugarbay: Video play mpeg

 

 

Attached you can find the full test report.

Test Summary
-------------------------

Test Result Summary

Component

Target

Status

Comments

QEMU

qemu

GOOD

Everything runs well

BSP

Sugarbay

GOOD

MPEG video play issue

e-Menlow

GOOD

No USB notification

 

Hurronriver

GOOD

Everything runs well

 

Jasperforest

GOOD

Everything runs well

 

FRI 2

BUGGY

Stanby fails.
3G connman connection not available in connman.

 

Crownbay

GOOD

Standby fails.

 

Hurronriver

GOOD

Switch among windows fails with numlock on

Core Build System

BUGGY

libowl do_fetch fails
x32 image build fails due to fetch error
lib32 connman-gnome built for qemux86-64 – ipk fails

ADT Toolchain

BUGGY

Clutter C/C++ template fails
Headless Build fails
Yocto BSP Tool fails

HOB

 

BUGGY

toolchain arch in settings is not saved
Hob recipe build from terminal fails

 

BLOCK

Critical bugs, more than 50% test cases are blocked

GOOD

Only Normal, Minor or Enhancement bugs, less than 10% test cases failed

BUGGY

Normal, Major and Critical bugs, more than 10% test cases failed

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Qemu

334

0

334

0

0

Core Build System

62

0

57

5(2821,3453,3715,3714)

0

ADT Toolchain

53

7

42

4(3690,3686,3693)

7

HOB

38

0

36

2(2695,3001)

0

Stress

3

0

3

0

0

Compliance

2

0

2

0

0

Distro

14

0

14

0

0

e-Menlow

66

0

65

1(2643)

0

Hurronriver

68

0

67

1(2646)

0

Jasperforest

35

0

35

0

0

FRI2

87

6

78

3(2646,2037,2415)

6

Sugarbay

66

0

65

1(3704)

0

Crownbay

66

1

62

3(2792,1258)

1

Beagleboard

41

0

41

0

0

Routestationpro

31

0

31

0

0

Mpc8315e

34

0

34

0

0

P1022ds

31

0

31

0

0

Total

1031

14

997

20

14


* You can check the detailed test result in attachment for each target.
** The failed/blocked case number is listed with failed cases’ bug number.


Commit information
--------------------------------

Location: http://autobuilder.pokylinux.org/nightly/20130105-1/
Tree/Branch: denzil
Commit: 3456295898bf157e40ea1f8c335f0b7285d3d8a7
Issue Summary
-----------------------------------

Component

Bug Number

Target Milestone

Core Build System

Bug 2821 - libowl do_fetch error
Bug 3714 - Fetch fail linux-libc-headers-3.1
Bug 3715 - Fetch fail linux-korg-3.1
Bug 3453 - lib32 connman-gnome built for qemux86-64 - ipk

1.4 M1
---
---
1.4

HOB

Bug 2695 - [HOB]toolchain arch in settings is not saved
Bug 3001 – Hob recipe build from terminal fails

1.3 M4
---

ADT

Bug 3686 - errors when building headless build for eclipse-plugin 1.2.2
Bug 3693 - BUILDDIR error - when selecting kernel version in yocto bsp tool for denzil
Bug 3690 - Clutter - Unable to find suitable fbconfig for the GLX context

1.2.2
1.2.2
1.2.2

FRI2

Bug 2415 – No connman 3G connection

1.4

Sugarbay

Bug 3704 – able to play .MPG file when it should not

---

Crownbay - noemgd

Bug 2792 - X fails to start after standby on Crownbay

1.4

 

Best Regards,


--

Alexandru Palalau

QA Contractor @ Yocto Project

Open-source Technology Center Romania

System Software Division

 

 


SRCPV description

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Hi,

I need a description of the SRCPV variable for the YP reference glossary. I have been told that it is generated and not assigned and that it is used to define PV values that include the source revisions from an RCS. By default it is set to the following in the conf/bitbake.conf file:

SRCPV = "${@bb.fetch2.get_srcrev(d)}"

Can anyone provide more information on this variable?

Thanks,
Scott



Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)


[ANOUNCEMENT] bmaptool

Artem Bityutskiy <dedekind1@...>
 

Hi Yocto people,

I would like to announce the bmap-tools project here, because I think it
may be very useful for Yocto and some of the people who are using Yocto.

The bmap-tools project is about disk images, like direct HDD images, or
Virtual-machine images like vdmk or qcow2, etc. The project uses simple
ideas in a clever way to copy/flash these kind of images quickly.

Please, read all the details in the project wiki page:
https://source.tizen.org/documentation/reference/bmaptool

The project was created for Tizen IVI, but it is generic and is not
bounded to Tizen in any way.

I do not want to duplicate the bmap-tools documentation here, but
instead, let me just describe how we use it in Tizen IVI.

1. We produce raw images of 4GB in size.
2. Images have 3 partitions inside.
3. Images are rather sparse, we have only 1.2GB of data inside (total)
4. We publish compressed images, they take 300MiB
5. We also publish bmap file for the image, e.g., see the ".bmap" file
here:
http://download.tizen.org/snapshots/2.0alpha/ivi/tizen-2.0_20130111.3/images/ivi-2.0-alpha/

Now the key point: when users flash the 4GiB images using bmaptool, they
actually copy only 1.1GiB of data. E.g, when flashing to slow USB
sticks, it reducing writing time from 20Min to 4Min.

The other key point here: if we or others decide to produce 64GiB or
1TiB images instead, with the same amount of data (1.2GiB), the flashing
time will be almost the same.

The third key point here: images are compressed, and rather small, which
saves space and network traffic. When/if we make images 64GiB or 1TiB,
their .bz2 files will still be almost as small, because zeroes compress
very well.

If you think about a production factory case, you may see a lot of
benefits of using bmap.

Anyway, for the Yocto project, it would probably be nice if in the
window where you select the type of image to generate and its size,
there was a "generate bmap" check-box (on by default :-)).

Comments, questions?

Thanks,
Artem.

--
Best Regards,
Artem Bityutskiy


Re: [PATCH] matchbox-wm: Fix build with automake-1.13

Burton, Ross <ross.burton@...>
 

On 12 January 2013 09:09, Marko Lindqvist <cazfi74@...> wrote:
Automake-1.13 fix to matchbox-wm git attached.
Committed in git, thanks.

Ross


Re: [meta-intel][PATCH 2/2] fri2.conf: mesa-dri was updated to 9.0.1

Andrei Gherzan
 

On Sun, Jan 13, 2013 at 10:03 PM, Ross Burton <ross.burton@...> wrote:
On Sunday, 13 January 2013 at 19:39, Andrei Gherzan wrote:
> Tested with a new sato build on master. Everything seems to be OK.

glxinfo/glxgears or something that actually uses the hardware?

Yes. That too. 


Re: [meta-intel][PATCH 2/2] fri2.conf: mesa-dri was updated to 9.0.1

Ross Burton <ross.burton@...>
 

On Sunday, 13 January 2013 at 19:39, Andrei Gherzan wrote:
Tested with a new sato build on master. Everything seems to be OK.
glxinfo/glxgears or something that actually uses the hardware?

Ross


Re: [meta-intel][PATCH 2/2] fri2.conf: mesa-dri was updated to 9.0.1

Andrei Gherzan
 

On Sun, Jan 13, 2013 at 6:44 PM, Ross Burton <ross.burton@...> wrote:
Sorry for top posting... Have you verified that GL still works with this major version bump?

Ross
-- 
Ross Burton
Sent with Sparrow

On Sunday, 13 January 2013 at 16:23, Andrei Gherzan wrote:

Signed-off-by: Andrei Gherzan <andrei@...>
---
meta-fri2/conf/machine/fri2.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf
index 0efba2a..07ad750 100644
--- a/meta-fri2/conf/machine/fri2.conf
+++ b/meta-fri2/conf/machine/fri2.conf
@@ -27,7 +27,7 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
"
PREFERRED_VERSION_xserver-xorg ?= "1.9.3"
-PREFERRED_VERSION_mesa-dri ?= "8.0.4"
+PREFERRED_VERSION_mesa-dri ?= "9.0.1"
PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
PREFERRED_VERSION_emgd-driver-bin ?= "1.14"
Tested with a new sato build on master. Everything seems to be OK. 

ag