Date   

[PATCH 0/1] emenlow glx bugfix

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

This is a fix for Yocto bug #1235.

The following changes since commit 92fc07a5f1b98779806cdcc2341487ff5ea5a238:
Dexuan Cui (1):
emenlow: fix some .bbappend files' name: poky -> core, etc.

are available in the git repository at:

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

Tom Zanussi (1):
meta-emenlow: fix glx bug

.../libdrm-poulsbo/libdrm-poulsbo_2.3.0.bb | 6 +++++-
.../recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)


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

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

Robert,

I know that and will work towards that end as well. There are a lot of holdover things in our docs.

Thanks,
Scott

-----Original Message-----
From: Robert P. J. Day [mailto:rpjday@...]
Sent: Thursday, July 14, 2011 7:29 AM
To: Rifenbark, Scott M
Cc: Richard Purdie; Darren Hart; yocto@...
Subject: RE: [yocto] docs: how to spell "bitbake", and docbook semantic markup for user input

On Thu, 14 Jul 2011, Rifenbark, Scott M wrote:

Agreed that BitBake is the correct spelling. I will be sure to make
a sweep through our Yocto manuals and make sure that when we are
referring to the tool and not indicating the command they say
"BitBake".
and while you're at it, i was once lectured sternly that the proper
spelling is "Git" when talking about the tool and "git" when referring
to the actual command. never "GIT". at least that what i was told.
do with that what you wish.

rday

p.s. since i am, at this very moment, immersed in an XML publishing
toolchain, i will probably have some thoughts on docbook markup in the
near future. stay tuned ...


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

Robert P. J. Day
 

On Thu, 14 Jul 2011, Rifenbark, Scott M wrote:

Agreed that BitBake is the correct spelling. I will be sure to make
a sweep through our Yocto manuals and make sure that when we are
referring to the tool and not indicating the command they say
"BitBake".
and while you're at it, i was once lectured sternly that the proper
spelling is "Git" when talking about the tool and "git" when referring
to the actual command. never "GIT". at least that what i was told.
do with that what you wish.

rday

p.s. since i am, at this very moment, immersed in an XML publishing
toolchain, i will probably have some thoughts on docbook markup in the
near future. stay tuned ...


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

Richard Purdie
 

On Wed, 2011-07-13 at 07:43 -0400, Robert P. J. Day wrote:
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'
Merged to master, thanks.

Richard


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

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

Agreed that BitBake is the correct spelling. I will be sure to make a sweep through our Yocto manuals and make sure that when we are referring to the tool and not indicating the command they say "BitBake".

Thanks,
ScottR

-----Original Message-----
From: Richard Purdie [mailto:richard.purdie@...]
Sent: Thursday, July 14, 2011 3:02 AM
To: Robert P. J. Day
Cc: Darren Hart; yocto@...; Rifenbark, Scott M
Subject: Re: [yocto] docs: how to spell "bitbake", and docbook semantic markup for user input

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: IMAGE_FSTYPES that are supported?

Bruce Ashfield <bruce.ashfield@...>
 

On 07/14/11 09:40, Koen Kooi wrote:

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 :)
Yah, that's what I wondered as well. I've done this locally,
but nothing out of the box .. so I had nagging doubts!

Cheers,

Bruce


Re: Menu configuration

Richard Purdie
 

On Thu, 2011-07-14 at 08:06 -0500, Kumar Gala wrote:
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?
Not specifically. "bitbake -u hob" should let you see where things are
at. Please keep in mind that its under active development at the moment
and can be considered "alpha" quality but feedback is welcome.

Cheers,

Richard


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