Date   

Re: IMAGE_FSTYPES that are supported?

Koen Kooi
 

Op 14 jul 2011, om 15:13 heeft Bruce Ashfield het volgende geschreven:

On 07/14/11 09:05, Kumar Gala wrote:
Is there a list of which IMAGE_FSTYPES are supported. I didn't see anything in the docs. Looking to see if a u-boot 'mkimage' wrapped set of images is supported or not.
I'm not 100% where the list is, but I can confirm that
uImages are supported and work nicely. Assuming that
you are talking about the common use case, and not something
more exotic :)

I think he means partitioned uimages where you have a kernel + initrd in a single uimage. We don't support that *yet*, but all the needed blocks are there. And we finally get a usecase for having the loadadresses in the machine.conf files :)


Re: IMAGE_FSTYPES that are supported?

Bruce Ashfield <bruce.ashfield@...>
 

On 07/14/11 09:05, Kumar Gala wrote:
Is there a list of which IMAGE_FSTYPES are supported. I didn't see anything in the docs. Looking to see if a u-boot 'mkimage' wrapped set of images is supported or not.
I'm not 100% where the list is, but I can confirm that
uImages are supported and work nicely. Assuming that
you are talking about the common use case, and not something
more exotic :)

Cheers,

Bruce


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


Re: Menu configuration

Kumar Gala <galak@...>
 

On Jul 12, 2011, at 3:43 AM, Richard Purdie wrote:

On Mon, 2011-07-11 at 10:00 -0700, Turner Randy wrote:
Hello list,

Is there a interactive menu-based configuration for yocto/poky builds
similar to that provided in Buildroot? Or is someone working on this?
At present there is not any interactive menu based configuration but
there is work ongoing on a UI called hob which allows you to select
packages and construct images of those packages so its a graphical front
end to the system.

We're also in the process of starting to better markup configuration
variables in the metadata so that writing some kind of menu based
configuration system would be easier in the future.

We're certainly open to any help in those areas too!

Cheers,

Richard
Are there any docs for hob at this point?

- k


IMAGE_FSTYPES that are supported?

Kumar Gala <galak@...>
 

Is there a list of which IMAGE_FSTYPES are supported. I didn't see anything in the docs. Looking to see if a u-boot 'mkimage' wrapped set of images is supported or not.

- k


Re: docs: how to spell "bitbake", and docbook semantic markup for user input

Richard Purdie
 

On Thu, 2011-07-14 at 05:46 -0400, Robert P. J. Day wrote:
On Wed, 13 Jul 2011, Darren Hart wrote:

On 07/13/2011 03:48 PM, Joshua Lock wrote:
On Wed, 2011-07-13 at 06:57 -0400, Robert P. J. Day wrote:
just perusing the documentation in my typically pedantic fashion and
a couple questions about style. first, is the proper spelling
"Bitbake" or "BitBake" since the doc source seems to bounce back and
forth and it really should be consistent.
I believe it's the latter, at least that's what I've always use.
Agreed:

The man page:
BitBake - simple tool for the execution of tasks

The user manual:
BitBake User Manual

Those seem like the two lines of documentation that are most likely to
be correct :-) So unless Richard or Chris pipe up, I'd go with BitBake.
i thought as much, i'm going with that. not high on any list of
priorities but while i'm perusing the docs, i might as well make notes
of what can change, and submit patches for the more obvious stuff.

are the small changes i've posted here in acceptable format? do
they get ACKed at some point so i can verify they were accepted?
The pieces in poky's documentation directory are part of the yocto-docs
repo which is maintained by Scott (cc'd). Scott is a tech writer rather
than a developer and loves git, er, I mean we might need to help him get
the patches in ;-). Please do send them and we'll figure that bit out
though and will send an acknowledgement when they're merged.

Cheers,

Richard


Re: docs: how to spell "bitbake", and docbook semantic markup for user input

Robert P. J. Day
 

On Wed, 13 Jul 2011, Darren Hart wrote:

On 07/13/2011 03:48 PM, Joshua Lock wrote:
On Wed, 2011-07-13 at 06:57 -0400, Robert P. J. Day wrote:
just perusing the documentation in my typically pedantic fashion and
a couple questions about style. first, is the proper spelling
"Bitbake" or "BitBake" since the doc source seems to bounce back and
forth and it really should be consistent.
I believe it's the latter, at least that's what I've always use.
Agreed:

The man page:
BitBake - simple tool for the execution of tasks

The user manual:
BitBake User Manual

Those seem like the two lines of documentation that are most likely to
be correct :-) So unless Richard or Chris pipe up, I'd go with BitBake.
i thought as much, i'm going with that. not high on any list of
priorities but while i'm perusing the docs, i might as well make notes
of what can change, and submit patches for the more obvious stuff.

are the small changes i've posted here in acceptable format? do
they get ACKed at some point so i can verify they were accepted?

rday

--

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

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


Re: docs: how to spell "bitbake", and docbook semantic markup for user input

Richard Purdie
 

On Wed, 2011-07-13 at 06:57 -0400, Robert P. J. Day wrote:
just perusing the documentation in my typically pedantic fashion and
a couple questions about style. first, is the proper spelling
"Bitbake" or "BitBake" since the doc source seems to bounce back and
forth and it really should be consistent.

and second, this just doesn't seem right as semantic docbook markup:

"When the <filename>bitbake</filename> command completes ..."

in that context, bitbake is not a filename, it's "userinput". is
there a reason all user input like that is marked up as "filename"?
I guess it could have been so certain parts appeared in bold but I
suspect there isn't a good reason.

Cheers,

Richard


Re: docs: how to spell "bitbake", and docbook semantic markup for user input

Richard Purdie
 

On Wed, 2011-07-13 at 20:28 -0700, Darren Hart wrote:

On 07/13/2011 03:48 PM, Joshua Lock wrote:
On Wed, 2011-07-13 at 06:57 -0400, Robert P. J. Day wrote:
just perusing the documentation in my typically pedantic fashion and
a couple questions about style. first, is the proper spelling
"Bitbake" or "BitBake" since the doc source seems to bounce back and
forth and it really should be consistent.
I believe it's the latter, at least that's what I've always use.
Agreed:

The man page:
BitBake - simple tool for the execution of tasks

The user manual:
BitBake User Manual

Those seem like the two lines of documentation that are most likely to
be correct :-) So unless Richard or Chris pipe up, I'd go with BitBake.
I think we've been leaning towards BitBake for a while.

Cheers,

Richard


Re: docs: how to spell "bitbake", and docbook semantic markup for user input

Darren Hart <dvhart@...>
 

On 07/13/2011 03:48 PM, Joshua Lock wrote:
On Wed, 2011-07-13 at 06:57 -0400, Robert P. J. Day wrote:
just perusing the documentation in my typically pedantic fashion and
a couple questions about style. first, is the proper spelling
"Bitbake" or "BitBake" since the doc source seems to bounce back and
forth and it really should be consistent.
I believe it's the latter, at least that's what I've always use.
Agreed:

The man page:
BitBake - simple tool for the execution of tasks

The user manual:
BitBake User Manual

Those seem like the two lines of documentation that are most likely to
be correct :-) So unless Richard or Chris pipe up, I'd go with BitBake.

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


Re: Supporting upcoming distribution releases

niqingliang
 

new version

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ # the 'python -V' need redirect to stdout
+ # once we can ensure every distribution has 'python2' (currently,
except
+ # ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ # and remove this patch.
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+ echo "WARNING: your default python is not 2.x, so autodetect..."
+ PYTHON2_BIN=""
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=$PY_BIN
+ break
+ fi
+ done
+ if [ -n "$PYTHON2_BIN" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ echo "WARNING: poky will use '$PY_BIN' to execute python
code."
+ else
+ echo "ERROR: poky can't find python 2.x."
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi

On Thu, 2011-07-14 at 01:01 +0800, Darren Hart wrote:

On 07/13/2011 01:04 AM, NiQingliang wrote:
first sorry about that, indeed I don't know how to commit a patch, so
just paste the diff result here.

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0da8bc0 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,20 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
Before searching manually, we should attempt to use whatever is set in
the environment.

--
Darren

+ # find the python version 2.x
+ # the 'python -V' need redirect to stdout
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ break
+ fi
+ done
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi


On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
/usr/bin/env python2
/usr/bin/env python2.7
These are both valid on Fedora 15, iirc before distributions started
shipping Python 3 they were less common though...

both of them are ok for archlinux, but I don't know which is ok for
other distributions, maybe both are not.

maybe we can make a shell script to detect the python version, and make
a symbollink to the right one in some directory, and add the directory
into env var "PATH".
Patches welcome :-)

I looked at it briefly and the work would require more time than I have
spare right now just to ensure it worked on all required distributions.

If you'd like to work on a patch I'd be happy to help test and review.

Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
倪庆亮
TEL: 13588371863
E-MAIL: niqingliang@...
BLOG: http://niqingliang2003.wordpress.com


Weekly test report for Yocto1.1 M2 RC2 20110708 build

Fan, WenhuaX <wenhuax.fan@...>
 

Hi all,

This is the weekly test report for Yocto 1.1 M2 RC2 20110708 build. Since all lsb build failed on autobuilder, jasperforest testing is performed against sato-sdk. There are 5 new bugs found in this testing. All compile testing is blocked due to gcc/g++ could not work with a .so file missing. 3D testing is blocked on sugarbay because of a eglic bug. glx* commands are found not work on emenlow. ldd on x86_64 platform could not work due to wrong path for ld.so.

For other open bug, the X server start up failure issue still exists on crownbay. We have updated bug 1211, which is for psplash instead of X server. The rpm/zypper install/removal consume disk space issue still exists.

For bug fixing, the 2 installation issues have been fixed. Bash missing issue is fixed also. cvs configure issue is fixed for mips toolchain

NoteFor different images, they are built against different commit/branch on autobuilder. You can refer to “Commit Information” section for detailed information.

The test report is archived @ https://wiki.pokylinux.org/wiki/Yocto_1.1_Milestone_Test_Report

 

 

Test Summary:

---------------------------------------

 

Test Result Summary

Component

Target

Status

Comments

BSP

SugarBay

BUGGY

Parport_pc probe fail of 00:0b; Gcc can not work;3D testing is blocked by a eglibc bug instead of above sentence.

CrownBay-emgd

BLOCK

X server failed to start up when boot from harddisk;Gcc can not work.

JasperForest

GOOD

I/OAT DMA engine init failed;

Blacksand

BUGGY

Gcc can not work.

eMenlow

BUGGY

I2c_transfer error; Standby failed; Glxinfo and glxgears commands could not work.

Beagleboard

BUGGY

Gcc can not work;

Routerstationpro

BUGGY

Gcc can not work;

Mpc8315e-rdb

BUGGY

Gcc can not work;

QEMU

qemux86

GOOD

Gcc can not work.

qemux86-64

GOOD

Gcc can not work.

qemuarm

GOOD

Gcc can not work;

qemuppc

GOOD

Gcc can not work;

qemumips

GOOD

Gcc can not work;

ADT

 

BUGGY

Unfs does not work with qemuppc;

 

Critical bugs, more than 50% test cases are blocked

 

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

 

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

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Sugarbay Sato-SDK

59

0

49

1 (bug 1187)

6 (bug 1233) 3 (bug 1237)

Jasperforest Sato-SDK

32

0

25

1 (bug 1188)

6 (bug 1233)

n450 Sato-SDK

55

0

49

0

6 (bug 1233)

eMenlow Sato-SDK

55

0

46

2(bug 310, 503)

6 (bug 1233) 1(bug 1235)

Crownbay-Sato-SDK

55

0

28

1 (bug 1207)

20(bug 1207) 6 (bug 1233)

Beagleboard

36

0

30

0

6 (bug 1233)

Routerstationpro

31

0

25

0

6 (bug 1233)

Mpc8315e-rdb

34

0

28

0

6 (bug 1233)

Qemux86-64 Sato

28

0

27

1 (bug 1172)

0

Qemux86-64 Sato-SDK

31

0

28

1 (bug 1233)

2 (bug 1233)

Qemux86 Sato

28

0

27

1 (bug 1172)

0

Qemux86 Sato-SDK

31

0

31

1 (bug 1233)

2 (bug 1233)

Qemumips Sato

28

0

27

1 (bug 1172)

0

Qemumips Sato-SDK

31

0

28

0

3 (bug 1233)

Qemuppc Sato

21

0

19

2 (bug 414, 1172)

0

Qemuppc Sato-SDK

24

0

20

1 (bug 414)

3 (bug 1233)

Qemuarm Sato

28

0

27

1 (bug 1172)

0

Qemuarm Sato-SDK

31

0

28

0

3 (bug 1233)

ADT

6

0

5

1 (bug 414)

0

Total

644

0

547

15

82

 

* 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

---------------------------------------

 

For Emenlow/Blacksand/Crownbay/Sugarbay/Toolchain/Qemex86/Qemux86-64

Tree/Branch: Poky/1.1_M2

Poky Commit id: 8df2a558b4d61778a669705b867969abe3514846

Meta Branch : 1.1_M2

Meta Commit id : 92fc07a5f1b98779806cdcc2341487ff5ea5a238

 

For qemuarm/mips/ppc/beagleboard/mpc8315e-rdb/routerstationpro:
Tree/Branch: Poky/1.1_M2
Poky Commit id: 9f4eaeef33da5595748253d59d95c7ca548e28fa

 

 

Issue Summary

---------------------------------------

 

Component

Bug Number

Target Milestone

System & Core OS

Installation & Boot

Bug 1207 - [Crownbay-emgd] X server failed to start up

1.1 M2

Bug 1211 - [Blacksand] Psplash failed when boot up Yocto

1.1 M2

System Usage

Bug 1172: Perl not exist in sato image

1.1 M2

Bug 1174: [zypper/rpm] package install/removal costs lots of disk space

1.1 M3

New! Bug 1233: gcc can not work due to missing liblto_plugin.so with 20110708 build

1.1 M2

New! Bug 1234: No response when I click the 'Install/Remove Software' icon

1.1 M4

Other

New! Bug 1235 - [Emenlow] Running glxinfo and glxgears commands failed.

1.1 M2

New! Bug 1236 - Broken ldd due to wrong path for ld.so

1.1 M2

New! Bug 1237 - [sugarbay] Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!

1.1 M2

ADT

Bug 414: [PPC] kernel panic when booting poky-image-sdk-qemuppc through UNFS

1.1 M3

 

 

Verified Fixed Bug:

---------------------------------------

 

1.     Bug 1099 - [blacksand/emenlow/crownbay] grub install failed with sato-sdk live image

2.     Bug 1171 - No enough disk space with qemu sato images

3.     Bug 1195 - [mips toolchain] cvs configure fail with no cvs_cv_func_printf_ptr set

4.     Bug 1199 - qemuppc lsb-sdk rootfs image build failed on autobuilder in nightly build 20110625-1

5.       Bug 1205 - [blacksand/emenlow/crownbay] Format swap partition failed when install

6.       Bug 1214 - [Emenlow/Blacksand/Crownbay/Sugarbay] No bash exist in sato-sdk image

 


Re: Supporting upcoming distribution releases

niqingliang
 

You are right, I will fix it.

On Thu, 2011-07-14 at 01:01 +0800, Darren Hart wrote:

On 07/13/2011 01:04 AM, NiQingliang wrote:
first sorry about that, indeed I don't know how to commit a patch, so
just paste the diff result here.

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0da8bc0 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,20 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
Before searching manually, we should attempt to use whatever is set in
the environment.

--
Darren

+ # find the python version 2.x
+ # the 'python -V' need redirect to stdout
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ break
+ fi
+ done
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi


On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
/usr/bin/env python2
/usr/bin/env python2.7
These are both valid on Fedora 15, iirc before distributions started
shipping Python 3 they were less common though...

both of them are ok for archlinux, but I don't know which is ok for
other distributions, maybe both are not.

maybe we can make a shell script to detect the python version, and make
a symbollink to the right one in some directory, and add the directory
into env var "PATH".
Patches welcome :-)

I looked at it briefly and the work would require more time than I have
spare right now just to ensure it worked on all required distributions.

If you'd like to work on a patch I'd be happy to help test and review.

Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
倪庆亮
TEL: 13588371863
E-MAIL: niqingliang@...
BLOG: http://niqingliang2003.wordpress.com


Re: docs: how to spell "bitbake", and docbook semantic markup for user input

Joshua Lock <josh@...>
 

On Wed, 2011-07-13 at 06:57 -0400, Robert P. J. Day wrote:
just perusing the documentation in my typically pedantic fashion and
a couple questions about style. first, is the proper spelling
"Bitbake" or "BitBake" since the doc source seems to bounce back and
forth and it really should be consistent.
I believe it's the latter, at least that's what I've always use.

Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


[PATCH 1/1] poky.conf: perform network sanity check by default for poky distros

Joshua Lock <josh@...>
 

Add CONNECTIVITY_CHECK_URIS to run the network connectivity sanity test for
http, https and git sources.

The variable is soft-assigned so that it's easily overrideable.

Signed-off-by: Joshua Lock <josh@...>
---
meta-yocto/conf/distro/poky.conf | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf
index 1ae94a0..679bef6 100644
--- a/meta-yocto/conf/distro/poky.conf
+++ b/meta-yocto/conf/distro/poky.conf
@@ -48,4 +48,9 @@ http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"


-
+# The CONNECTIVITY_CHECK_URI's are used to test whether we can succesfully
+# fetch from the network (and warn you if not). To disable the test set
+# the variable to be empty.
+CONNECTIVITY_CHECK_URIS ?= "git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD \
+ https://eula-downloads.yoctoproject.org/index.php \
+ http://bugzilla.yoctoproject.org/report.cgi"
--
1.7.6


[PATCH 0/1] Add CONNECTIVITY_CHECK_URIS to Poky derived distros

Joshua Lock <josh@...>
 

Add CONNECTIVITY_CHECK_URIS to run the network connectivity sanity test
against http, https and git sources for Poky derived distrbutions.

The following changes since commit 068839698fe192d8846c0ed4db65861448e8e524:

eglibc: fix runtime assertion failure (2011-07-13 12:34:30 +0100)

are available in the git repository at:
git://git.pokylinux.org/poky-contrib josh/sanity
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=josh/sanity

Joshua Lock (1):
poky.conf: perform network sanity check by default for poky distros

meta-yocto/conf/distro/poky.conf | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

--
1.7.6


Re: [PATCH 1/1] local.conf.sample: add CONNECTIVITY_CHECK_URIS

Joshua Lock <josh@...>
 

On Wed, 2011-07-13 at 10:28 -0700, Darren Hart wrote:

On 07/12/2011 07:32 PM, Joshua Lock wrote:
Add CONNECTIVITY_CHECK_URIS to run the network connectivity sanity test for
http, https and git sources.

Signed-off-by: Joshua Lock <josh@...>
---
meta-yocto/conf/local.conf.sample | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample
index ea32b81..fb20f2c 100644
--- a/meta-yocto/conf/local.conf.sample
+++ b/meta-yocto/conf/local.conf.sample
@@ -214,3 +214,11 @@ NO32LIBS = "1"
# The network based PR service host and port
#PRSERV_HOST = "localhost"
#PRSERV_PORT = "8585"
+
+# Use the following URI's to test whether we can succesfully fetch from the
+# network (and warn you if not). This test will be run each time a new build
+# directory is specfied, if you wish to disable it delete or comment out the
+# following few lines that define CONNECTIVITY_CHECK_URIS.
+CONNECTIVITY_CHECK_URIS = "git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD \
+ https://eula-downloads.yoctoproject.org/index.php \
+ http://bugzilla.yoctoproject.org/report.cgi"

Would this not be better in a distro config file? conf/distro/poky.conf
comes to mind.

Josh pointed out that the lsb variant would then miss out - so perhaps a
network-sanity.inc file could be included by each distro defined in a
layer. It doesn't make sense in layer.conf as multiple layers can be
used - but as I understand it, only a single distro is built at a time?
I was being stupid both when I submitted this patch and when we
discussed it, the poky.conf file is inherited by each of the
distributions in meta-yocto so it makes sense to define this variable
there.


I like the idea of it working by default without any requirements on
local.conf. The user could override this variable in local.conf if they
want, but I don't think it should be required to be there for the checks
to work.
You are entirely correct. I should also set it with ?= so it's easy to
override.

v2 patch imminent.

Thanks,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


Re: [PATCH 1/1] local.conf.sample: add CONNECTIVITY_CHECK_URIS

Darren Hart <dvhart@...>
 

On 07/12/2011 07:32 PM, Joshua Lock wrote:
Add CONNECTIVITY_CHECK_URIS to run the network connectivity sanity test for
http, https and git sources.

Signed-off-by: Joshua Lock <josh@...>
---
meta-yocto/conf/local.conf.sample | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample
index ea32b81..fb20f2c 100644
--- a/meta-yocto/conf/local.conf.sample
+++ b/meta-yocto/conf/local.conf.sample
@@ -214,3 +214,11 @@ NO32LIBS = "1"
# The network based PR service host and port
#PRSERV_HOST = "localhost"
#PRSERV_PORT = "8585"
+
+# Use the following URI's to test whether we can succesfully fetch from the
+# network (and warn you if not). This test will be run each time a new build
+# directory is specfied, if you wish to disable it delete or comment out the
+# following few lines that define CONNECTIVITY_CHECK_URIS.
+CONNECTIVITY_CHECK_URIS = "git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD \
+ https://eula-downloads.yoctoproject.org/index.php \
+ http://bugzilla.yoctoproject.org/report.cgi"

Would this not be better in a distro config file? conf/distro/poky.conf
comes to mind.

Josh pointed out that the lsb variant would then miss out - so perhaps a
network-sanity.inc file could be included by each distro defined in a
layer. It doesn't make sense in layer.conf as multiple layers can be
used - but as I understand it, only a single distro is built at a time?

I like the idea of it working by default without any requirements on
local.conf. The user could override this variable in local.conf if they
want, but I don't think it should be required to be there for the checks
to work.

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


Re: Supporting upcoming distribution releases

Darren Hart <dvhart@...>
 

On 07/13/2011 01:04 AM, NiQingliang wrote:
first sorry about that, indeed I don't know how to commit a patch, so
just paste the diff result here.

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0da8bc0 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,20 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
Before searching manually, we should attempt to use whatever is set in
the environment.

--
Darren

+ # find the python version 2.x
+ # the 'python -V' need redirect to stdout
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ break
+ fi
+ done
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi


On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
/usr/bin/env python2
/usr/bin/env python2.7
These are both valid on Fedora 15, iirc before distributions started
shipping Python 3 they were less common though...

both of them are ok for archlinux, but I don't know which is ok for
other distributions, maybe both are not.

maybe we can make a shell script to detect the python version, and make
a symbollink to the right one in some directory, and add the directory
into env var "PATH".
Patches welcome :-)

I looked at it briefly and the work would require more time than I have
spare right now just to ensure it worked on all required distributions.

If you'd like to work on a patch I'd be happy to help test and review.

Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


[PATCH] scripts: Rename "adt-install" to "adt-installer" in user help.

Robert P. J. Day
 

Signed-off-by: Robert P. J. Day <rpjday@...>

---

i'm hoping the following is correct -- it's just user help output so
it's not fatal but it should still be correct.

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index bc4962a..d278c24 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -118,7 +118,7 @@ Common targets are:
core-image-sato
meta-toolchain
meta-toolchain-sdk
- adt-install
+ adt-installer
meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

--

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

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


[PATCH] DOC: Fix a couple simple typoes in the ADT documentation.

Robert P. J. Day
 

Signed-off-by: Robert P. J. Day <rpjday@...>

--

diff --git a/documentation/adt-manual/adt-package.xml b/documentation/adt-manual/adt-package.xml
index 9f982d1..1e9539f 100644
--- a/documentation/adt-manual/adt-package.xml
+++ b/documentation/adt-manual/adt-package.xml
@@ -24,7 +24,7 @@
information about OPKG.</para></listitem>
<listitem><para><emphasis>RPM</emphasis> – A more widely known PMS intended for GNU/Linux
distributions.
- This PMS works with files packaged in an <filename>.rms</filename> format.
+ This PMS works with files packaged in an <filename>.rpm</filename> format.
The Yocto Project currently installs through this PMS by default.
See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
for more information about RPM.</para></listitem>
diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml
index 7fbc876..2ccae5b 100644
--- a/documentation/adt-manual/adt-prepare.xml
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -13,7 +13,7 @@

<para>
This section describes how to be sure you meet these requirements.
- Througout this section two important terms are used:
+ Throughout this section two important terms are used:
<itemizedlist>
<listitem><para><emphasis>Yocto Project Source Tree:</emphasis>
This term refers to the directory structure created as a result of downloading

rday

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

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