yocto@lists.yoctoproject.org

Unable to find package mio-lib (mio-lib)!

蔡振军 <caizhenjun@...>

#2589

Hello All,

Yesterday I got an error on “task_do_rootfs”. It notice that yocto unable to find package “mio-lib” which I just add to system.However,

the “mio-lib” package is built smoothly with no error. I spend whole day to try to resolve this problem and have no progress indeed.

here is the error log:

NOTE: Running task 1003 of 1298 (ID: 137, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_fetch)

NOTE: package mio-lib-0.1-r0: task do_fetch: Started

NOTE: package mio-lib-0.1-r0: task do_fetch: Succeeded

NOTE: Running task 1289 of 1298 (ID: 134, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_unpack)

NOTE: package mio-lib-0.1-r0: task do_unpack: Started

NOTE: package mio-lib-0.1-r0: task do_unpack: Succeeded

NOTE: Running task 1290 of 1298 (ID: 135, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_patch)

NOTE: package mio-lib-0.1-r0: task do_patch: Started

NOTE: package mio-lib-0.1-r0: task do_patch: Succeeded

NOTE: Running task 1291 of 1298 (ID: 141, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_populate_lic)

NOTE: Running task 1292 of 1298 (ID: 138, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_configure)

NOTE: package mio-lib-0.1-r0: task do_populate_lic: Started

NOTE: package mio-lib-0.1-r0: task do_configure: Started

NOTE: package mio-lib-0.1-r0: task do_populate_lic: Succeeded

NOTE: package mio-lib-0.1-r0: task do_configure: Succeeded

NOTE: Running task 1293 of 1298 (ID: 139, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_compile)

NOTE: package mio-lib-0.1-r0: task do_compile: Started

NOTE: package mio-lib-0.1-r0: task do_compile: Succeeded

NOTE: Running task 1294 of 1298 (ID: 136, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_install)

NOTE: package mio-lib-0.1-r0: task do_install: Started

NOTE: package mio-lib-0.1-r0: task do_install: Succeeded

NOTE: Running task 1295 of 1298 (ID: 140, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_package)

NOTE: package mio-lib-0.1-r0: task do_package: Started

NOTE: package mio-lib-0.1-r0: task do_package: Succeeded

NOTE: Running task 1296 of 1298 (ID: 142, /home/ll/work/optimus/meta-imx28/recipes-extended/mio-lib/mio-lib_0.1.bb, do_package_write_rpm)

NOTE: package mio-lib-0.1-r0: task do_package_write_rpm: Started

NOTE: package mio-lib-0.1-r0: task do_package_write_rpm: Succeeded

NOTE: Running task 1297 of 1298 (ID: 8, /home/ll/work/optimus/meta-imx28/recipes-core/images/core-image-imx28.bb, do_rootfs)

NOTE: package core-image-imx28-1.0-r0: task do_rootfs: Started

ERROR: Function 'do_rootfs' failed (see /home/ll/work/optimus-imx28-build/tmp/work/mx28evk-insigma-linux-gnueabi/core-image-imx28-1.0-r0/temp/log.do_rootfs.17769 for further information)

ERROR: Logfile of failure stored in: /home/ll/work/optimus-imx28-build/tmp/work/mx28evk-insigma-linux-gnueabi/core-image-imx28-1.0-r0/temp/log.do_rootfs.17769

Log data follows:

| Generating solve db for /home/ll/work/optimus-imx28-build/tmp/deploy/rpm/mx28evk...

| total: 1 0.000000 MB 0.767100 secs

| fingerprint: 312 0.002844 MB 0.032388 secs

| install: 104 0.000000 MB 0.217042 secs

| dbadd: 104 0.000000 MB 0.207174 secs

| dbget: 1021 0.000000 MB 0.001158 secs

| dbput: 104 0.488224 MB 0.136671 secs

| readhdr: 1041 0.982912 MB 0.169746 secs

| hdrload: 520 1.447744 MB 0.004313 secs

| hdrget: 18405 0.000000 MB 0.018025 secs

| Generating solve db for /home/ll/work/optimus-imx28-build/tmp/deploy/rpm/armv5te...

| total: 1 0.000000 MB 7.642331 secs

| fingerprint: 1677 0.044516 MB 0.138877 secs

| install: 559 0.000000 MB 1.274561 secs

| dbadd: 559 0.000000 MB 1.239767 secs

| dbget: 17048 0.000000 MB 0.011212 secs

| dbput: 559 4.296544 MB 1.043691 secs

| readhdr: 5591 8.601994 MB 4.089920 secs

| hdrload: 3343 17.026066 MB 0.045179 secs

| hdrget: 102529 0.000000 MB 0.118865 secs

| Generating solve db for /home/ll/work/optimus-imx28-build/tmp/deploy/rpm/all...

| total: 1 0.000000 MB 0.294207 secs

| fingerprint: 18 0.000024 MB 0.000412 secs

| install: 6 0.000000 MB 0.064882 secs

| dbadd: 6 0.000000 MB 0.058694 secs

| dbget: 19 0.000000 MB 0.000081 secs

| dbput: 6 0.018576 MB 0.005771 secs

| readhdr: 61 0.037992 MB 0.145214 secs

| hdrload: 30 0.055128 MB 0.000311 secs

| hdrget: 983 0.000000 MB 0.001172 secs

| Generating solve db for /home/ll/work/optimus-imx28-build/tmp/deploy/rpm/all...

| total: 1 0.000000 MB 0.117318 secs

| fingerprint: 18 0.000024 MB 0.000665 secs

| install: 6 0.000000 MB 0.062555 secs

| dbadd: 6 0.000000 MB 0.055995 secs

| dbget: 19 0.000000 MB 0.000080 secs

| dbput: 6 0.018576 MB 0.005078 secs

| readhdr: 61 0.037992 MB 0.000263 secs

| hdrload: 30 0.055128 MB 0.000242 secs

| hdrget: 983 0.000000 MB 0.000723 secs

| Processing task-core-boot...

| Processing u-boot...

| Processing mio-lib...

| Unable to find package mio-lib (mio-lib)!

| ERROR: Function 'do_rootfs' failed (see /home/ll/work/optimus-imx28-build/tmp/work/mx28evk-insigma-linux-gnueabi/core-image-imx28-1.0-r0/temp/log.do_rootfs.17769 for further information)

NOTE: package core-image-imx28-1.0-r0: task do_rootfs: Failed

ERROR: Task 8 (/home/ll/work/optimus/meta-imx28/recipes-core/images/core-image-imx28.bb, do_rootfs) failed with exit code '1'

ERROR: '/home/ll/work/optimus/meta-imx28/recipes-core/images/core-image-imx28.bb' failed

Some information maybe helpful I acquire in my terrible trip. Add “–v” option to bitbake ,log show unable to find package name from solve

db. Use “grep –rn” to check, it show as below:

grep -rn "mio-lib" ./

Binary file ./armv5te/mio-lib-dbg-0.1-r0.armv5te.rpm matches

Binary file ./armv5te/mio-lib-dev-0.1-r0.armv5te.rpm matches

Binary file ./armv5te/solvedb/Nvra matches

Binary file ./armv5te/solvedb/__db.006 matches

Binary file ./armv5te/solvedb/__db.003 matches

Binary file ./armv5te/solvedb/Providename matches

Binary file ./armv5te/solvedb/Packages matches

Binary file ./armv5te/solvedb/Name matches

./armv5te/solvedb/manifest:7:/home/ll/work/optimus-imx28-build/tmp/deploy/rpm/armv5te/mio-lib-dbg-0.1-r0.armv5te.rpm

./armv5te/solvedb/manifest:351:/home/ll/work/optimus-imx28-build/tmp/deploy/rpm/armv5te/mio-lib-dev-0.1-r0.armv5te.rpm

./armv5te/solvedb/manifest:474:/home/ll/work/optimus-imx28-build/tmp/deploy/rpm/armv5te/mio-lib-staticdev-0.1-r0.armv5te.rpm

Binary file ./armv5te/solvedb/Requirename matches

Binary file ./armv5te/solvedb/__db.005 matches

Binary file ./armv5te/mio-lib-staticdev-0.1-r0.armv5te.rpm matches

I use another package which reside in yocto originally named “libaio” to compare.by changing something in bb file and makefile, the

error appear when I delete some line in makefile’s install target.Fllow is my operation:

install: $(all_targets)

install -D -m 644 libaio.h $(includedir)/libaio.h

install -D -m 644 libaio.a $(libdir)/libaio.a

install -D -m 755 $(libname) $(libdir)/$(libname) ===============original one

ln -sf $(libname) $(libdir)/$(soname)

ln -sf $(libname) $(libdir)/libaio.so

||

\/

install: $(all_targets)

install -D -m 644 libaio.h $(includedir)/libaio.h

install -D -m 644 libaio.a $(libdir)/libaio.a ===================== bad work

install: $(all_targets)

install -D -m 755 $(libname) $(libdir)/$(libname) =======================google work

I cann’t find real reason for this error. What happen to me?

Best reagards

feye

蔡振军

网新技术有限公司物联网事业部

杭州天目山路226号网新大厦

电话-138 6745 1910

Re: linux-yocto-rt build fail for sugarbay bsp on grub recipe

Darren Hart <darren.hart@...>

#2581

On 08/30/2011 05:11 PM, Richard Purdie wrote:
On Tue, 2011-08-30 at 16:59 -0700, Bodke, Kishore K wrote:
Hello All,

 

I am trying to build linux-yocto with rt kernel for sugarbay bsp and
it fails for the grub recipe.

 

Attached is the build log.  

 

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^WARN_QA="

WARN_QA="dev-so rpaths debug-deps dev-deps debug-files arch la2
pkgconfig desktop la ldflags perms useless-rpaths"

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^ERROR_QA="

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$

 

Please let me know what could be the issue.Could you include the config.log file mentioned in the error report
please?

This should be somewhere like
usr/local/src/crf/test/buildsugarbayrt/tmp/work/x86_64-poky-linux/grub-1.98-r1/*/config.log
I replied with this and a comparison file, but it was rejected due to
being over 200k :(.

Short of it is that Kishore's config.log shows it picking up the
freetype libs from his host system. The patch I proposed adds a DEPENDS
to grub on freetype.

Cheers,

Richard


_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: linux-yocto-rt build fail for sugarbay bsp on grub recipe

Darren Hart <darren.hart@...>

#2580

Kishore, can you try this patch? You can just checkout this branch in
your meta-intel repository after adding the meta-intel-contrib remote,
or you can add it manually.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/commit/?h=dvhart/grubfix&id=60652a51878cbd0327c5f828acdbb73e31caafba

Thanks,

Darren

Show quoted text

On 08/30/2011 06:39 PM, Darren Hart wrote:
On 08/30/2011 05:11 PM, Richard Purdie wrote:
On Tue, 2011-08-30 at 16:59 -0700, Bodke, Kishore K wrote:
Hello All,

 

I am trying to build linux-yocto with rt kernel for sugarbay bsp and
it fails for the grub recipe.

 

Attached is the build log.  

 

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^WARN_QA="

WARN_QA="dev-so rpaths debug-deps dev-deps debug-files arch la2
pkgconfig desktop la ldflags perms useless-rpaths"

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^ERROR_QA="

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$

 

Please let me know what could be the issue.Could you include the config.log file mentioned in the error report
please?I've attached mine and Kishore's. Mine builds grub, while his does not.

I noticed that Kishore's config.log differs from mine in some configure tests. For example:

Mine contains (config.log-dvhart):

configure:8739: checking for __bswapsi2
configure:8739: gcc -o conftest -O2 -pipe -g -feliminate-unused-debug-types -DGRUB_MACHINE_PCBIOS=1 -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -nostdlib -Wl,--defsym,___main=0x8100 -Wl,--defsym,abort=main -Wno-error  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -m32 conftest.c -lgcc >&5
In file included from /usr/include/features.h:387,
                 from /usr/include/limits.h:27,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed/limits.h:122,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed/limits.h:11,
                 from conftest.c:62:
/usr/include/gnu/stubs.h:7: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated.
configure:8739: $? = 1


While there is no reference to stubs.h in Kishore's config.log (confi-1.log):

configure:8739: checking for __bswapsi2
configure:8739: gcc -o conftest -O2 -pipe -g -feliminate-unused-debug-types -DGRUB_MACHINE_PCBIOS=1 -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector -Werror -nostdlib -Wl,--defsym,___main=0x8100 -Wl,--defsym,abort=main -Wno-error  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -m32 conftest.c -lgcc >&5
conftest.c:75: warning: function declaration isn't a prototype
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000080480c0
configure:8739: $? = 0
configure:8739: result: yes


I also found that Kishore's config.log includes:
freetype_cflags='-I/usr/include/freetype2'
freetype_libs='-lfreetype -lz'

While mine includes:
freetype_cflags='-I/build/poky/sugarbay/tmp/sysroots/sugarbay/usr/include/freetype2 -I/build/poky/sugarbay/tmp/sysroots/sugarbay/usr/include'
freetype_libs='-L/build/poky/sugarbay/tmp/sysroots/sugarbay/usr/lib -lfreetype'

This would certainly be cause for a QA test failure.

Perhaps a DEPENDS=freetype in the grub recipe is in order?

Alternatively, we could see about configuring it without freetype.

Kishore, can you check to see if freetype is built on your system? Should be located at:

/usr/local/src/crf/test/buildsugarbayrt/tmp/work/x86_64-poky-linux/freetype-2.4.6-r0

Kishore, finally, we can confirm this is the problem by having you try this:
$ bitbake freetype
$ bitbake grub

I suspect this will complete.


This should be somewhere like
usr/local/src/crf/test/buildsugarbayrt/tmp/work/x86_64-poky-linux/grub-1.98-r1/*/config.log

Cheers,

Richard

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

Re: linux-yocto-rt build fail for sugarbay bsp on grub recipe

Darren Hart <darren.hart@...>

#2588

On 08/30/2011 05:11 PM, Richard Purdie wrote:
On Tue, 2011-08-30 at 16:59 -0700, Bodke, Kishore K wrote:
Hello All,

 

I am trying to build linux-yocto with rt kernel for sugarbay bsp and
it fails for the grub recipe.

 

Attached is the build log.  

 

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^WARN_QA="

WARN_QA="dev-so rpaths debug-deps dev-deps debug-files arch la2
pkgconfig desktop la ldflags perms useless-rpaths"

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^ERROR_QA="

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$

 

Please let me know what could be the issue.Could you include the config.log file mentioned in the error report
please?I've attached mine and Kishore's. Mine builds grub, while his does not.

I noticed that Kishore's config.log differs from mine in some configure tests. For example:

Mine contains (config.log-dvhart):

configure:8739: checking for __bswapsi2
configure:8739: gcc -o conftest -O2 -pipe -g -feliminate-unused-debug-types -DGRUB_MACHINE_PCBIOS=1 -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector -mno-stack-arg-probe -Werror -nostdlib -Wl,--defsym,___main=0x8100 -Wl,--defsym,abort=main -Wno-error  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -m32 conftest.c -lgcc >&5
In file included from /usr/include/features.h:387,
                 from /usr/include/limits.h:27,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed/limits.h:122,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed/limits.h:11,
                 from conftest.c:62:
/usr/include/gnu/stubs.h:7: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated.
configure:8739: $? = 1


While there is no reference to stubs.h in Kishore's config.log (confi-1.log):

configure:8739: checking for __bswapsi2
configure:8739: gcc -o conftest -O2 -pipe -g -feliminate-unused-debug-types -DGRUB_MACHINE_PCBIOS=1 -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector -Werror -nostdlib -Wl,--defsym,___main=0x8100 -Wl,--defsym,abort=main -Wno-error  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -m32 conftest.c -lgcc >&5
conftest.c:75: warning: function declaration isn't a prototype
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000080480c0
configure:8739: $? = 0
configure:8739: result: yes


I also found that Kishore's config.log includes:
freetype_cflags='-I/usr/include/freetype2'
freetype_libs='-lfreetype -lz'

While mine includes:
freetype_cflags='-I/build/poky/sugarbay/tmp/sysroots/sugarbay/usr/include/freetype2 -I/build/poky/sugarbay/tmp/sysroots/sugarbay/usr/include'
freetype_libs='-L/build/poky/sugarbay/tmp/sysroots/sugarbay/usr/lib -lfreetype'

This would certainly be cause for a QA test failure.

Perhaps a DEPENDS=freetype in the grub recipe is in order?

Alternatively, we could see about configuring it without freetype.

Kishore, can you check to see if freetype is built on your system? Should be located at:

/usr/local/src/crf/test/buildsugarbayrt/tmp/work/x86_64-poky-linux/freetype-2.4.6-r0

Kishore, finally, we can confirm this is the problem by having you try this:
$ bitbake freetype
$ bitbake grub

I suspect this will complete.


This should be somewhere like
usr/local/src/crf/test/buildsugarbayrt/tmp/work/x86_64-poky-linux/grub-1.98-r1/*/config.log

Cheers,

Richard


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

confi-1.log

config.log-dvhart

Re: linux-yocto-rt build fail for sugarbay bsp on grub recipe

Richard Purdie

#2579

On Tue, 2011-08-30 at 16:59 -0700, Bodke, Kishore K wrote:
Hello All,

I am trying to build linux-yocto with rt kernel for sugarbay bsp and
it fails for the grub recipe.

Attached is the build log.  

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^WARN_QA="

WARN_QA="dev-so rpaths debug-deps dev-deps debug-files arch la2
pkgconfig desktop la ldflags perms useless-rpaths"

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$
bitbake -e | egrep "^ERROR_QA="

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$

Please let me know what could be the issue.Could you include the config.log file mentioned in the error report
please?

This should be somewhere like
usr/local/src/crf/test/buildsugarbayrt/tmp/work/x86_64-poky-linux/grub-1.98-r1/*/config.log

Cheers,

Richard

linux-yocto-rt build fail for sugarbay bsp on grub recipe

Bodke, Kishore K <kishore.k.bodke@...>

#2578

Hello All,

I am trying to build linux-yocto with rt kernel for sugarbay bsp and it fails for the grub recipe.

Attached is the build log.

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$ bitbake -e | egrep "^WARN_QA="

WARN_QA="dev-so rpaths debug-deps dev-deps debug-files arch la2 pkgconfig desktop la ldflags perms useless-rpaths"

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$ bitbake -e | egrep "^ERROR_QA="

kishore@kishore-desktop:/usr/local/src/crf/test/buildsugarbayrt$

Please let me know what could be the issue.

Thanks

Kishore.

buld.log

Re: [PATCH 0/1] script/runqemu: change boot command line for qemuppc

Richard Purdie

#2577

On Wed, 2011-08-24 at 14:33 -0400, Bruce Ashfield wrote:
On 11-08-24 04:48 AM, Liming Wang wrote:
This patch is just a workaround to speed up boot time of qemuppc, because
qemuppc has no framebuffer support, no need to start X server for qemuppc.

Richard suggested to fix the X scripts so that if an fbdev X server is in use and
the framebuffer device node does not exist, it just exits cleanly with a
suitable message and doesn't timeout on boot.

But I think it needs more time to implement and test.
X scripts serve for all the boards. And we also can't assume all the
boards use the same
framebuffer device. So how to detect whether the framebuffer device
exists is board dependent.
Maybe we can see whether the device /dev/fb0 exists(it could be created
manually, so we should try to open it to verify)
or the file /proc/fb exists to confirm the framebuffer device. Anyway,
any modification should be
tested on all boards to see whether it works. I prefer to mark it as
todo task in 1.1We need to cc Richard/Saul on this, so they can re-consider
and merge this as appropriate. But for me, I'm acking this
change.I've reluctantly merged this but I consider this a bit of a cop-out :(

Cheers,

Richard

Re: [PATCH RESEND v2 1/1] scripts/runqemu: disable unfs boot mode for qemuppc

Richard Purdie

#2576

On Thu, 2011-08-25 at 22:45 +0800, Liming Wang wrote:
Because unfs boot mode is unstable for qemuppc, disable
it temporarily.

Signed-off-by: Liming Wang <liming.wang@...>
---
 scripts/runqemu |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)Merged to master, thanks.

Richard

Re: [PATCH 0/1] [YOCTO #1396] Fix adt-installer for consistent naming for powerpc and add all arch template for installation

Richard Purdie

#2575

On Thu, 2011-08-25 at 11:49 -0700, Jessica Zhang wrote:
The following changes since commit 1759d6dac3fe4022183f73898c035322c3f49865:
  Jessica Zhang (1):
        Merge branch 'master' of ssh://git.yoctoproject.org/poky

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jzhang/1396
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jzhang/1396

Jessica Zhang (1):
  [YOCTO #1396] Fix adt-installer for consistent naming for powerpc and
    add all arch template for installationMerged to master, thanks.

Richard

Re: bbappend - Where should my file be?

Richard Purdie

#2574

On Fri, 2011-08-12 at 00:51 +0100, Chris Tapp wrote:
I've got a linux-wrs_git.bbappend file in a layer (under poky laverne  
4.0.1) that contains:

COMPATIBLE_MACHINE_Vortex86DX = "Vortex86DX"
WRMACHINE_Vortex86DX  = "common_pc"

FILESEXTRAPATHS := "${THISDIR}/${PN}"

SRC_URI += " file://defconfig"

Where should the defconfig file be relative to the bbappend?

I've tried:

MyLayer
       +--- recipies
                   +--- linux
                            +--- linux-wrs_git.bbappend
                            +--- linux-wrs_git
                                             +--- defconfig


However, my defconfig file isn't being picked up during do_unpack:

cp: cannot stat `/home/chris/yocto/yocto-versions/laverne-4.0.1/meta/ 
recipes-kernel/linux/files/defconfig': No such file or directory
NOTE: Unpacking /home/chris/yocto/yocto-downloads/ 
git_git.pokylinux.org.linux-2.6-windriver.git.tar.gz to /home/chris/ 
yocto/mbox-3300-build/tmp/work/Vortex86DX-poky-linux/linux- 
wrs 
-2.6.34 
+ 
git0 
+ 
b67e060194a38c6331da1532bd06446087a42b3b_0 
+0431115c9d720fee5bb105f6a7411efb4f851d26-r12/
NOTE: Unpacking /home/chris/yocto/yocto-versions/laverne-4.0.1/meta/ 
recipes-kernel/linux/files/defconfig to /home/chris/yocto/mbox-3300- 
build/tmp/work/Vortex86DX-poky-linux/linux- 
wrs 
-2.6.34 
+ 
git0 
+ 
b67e060194a38c6331da1532bd06446087a42b3b_0 
+0431115c9d720fee5bb105f6a7411efb4f851d26-r12/
ERROR: Task failed:

Which seems to show that it's not looking in FILESEXTRAPATHS.

The .bbappend file seems to be processed, as commenting out the  
SRC_URI line gets rid of the error.

What have I got wrong?I've just been looking at the open bug related to this
(http://bugzilla.yoctoproject.org/show_bug.cgi?id=1379) and I can't
reproduce an issue with layers ending with -numeric causing a
problem :/.

In the above example, 

recipies/linux/linux-wrs/defconfig

is the correct path since PN == "linux-wrs". (you had linux-wrs_git).
Could you check whether the layer numeric part is a red herring please
and whether the above path works?

Cheers,

Richard

Minutes: Yocto Technical Team Meeting - (August 30, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

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

#2573

Attendees:
Paul, Beth, Jessica, Tom,  Scott, Richard, Darren, Denys, Mark, Josh, Matthew, Dave, Bruce
 
Minutes:
 
* Opens collection - 5 min (Song)
* Yocto 1.1 M4 status review and issues - 20 min (team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria#Milestone_ 
    - Status summary
       1. We are making good progress on bug fixes. Fixed 10 more bugs last week than the week before. (if we keep this acceleration, we should not have many medium bugs left before RC1). If you look at the bug trend chart, our weighted defect density number is pretty close to our lowest point in history. So great work, thank you all for your hard work in the past weeks.
      2. All M4 tasks on schedule are still on track. 
      3. ScottR will follow up with Jessica on ADT and HOB videos.      
    - Build status (Beth)
      * Have some issues with autobuilder master, resolving them. In the process of upgrading autobuilder infrastructure. Will run autobuilder on both the existing and upgraded infrastructure. Will compare build images this Wednesday, if everything is well, will complete the upgrade this week. New infrastructure will improve build performance significantly.  
      * Will have autobuilder down time this Thursday. 
    - Build performance: We had many new features in Yocto 1.1, which impacted our build performance.  At this point, there seems nothing we can do for this in the 1.1 timeframe. So we don't have any release target for build performance.  Although, Dongxiao has signed up to do some analysis and improvement on build performance.
 
*  Opens
   1. Paul: supported distros for yocto 1.1
       - Song will send the list of distros we support to Paul and Scott. (done, also updated the wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria#Milestone_4 with this )
       - We should create a list of distros that the community have tested and include that list in our release document. (Song will talk to Jiajun about this)
       - Beth will add this list in the release check list. 
       - Dave will consider adding a new feature for Yocto 1.2: automating distros we test

lttng-ust fails to build in current mainline for beagleboard.

Enric Balletbò i Serra <eballetbo@...>

#2572

Hi all,

Seems the package lttng-ust fails to build in current mainline, is
currently the build for beagleboard broken ?

The log looks like:

ERROR: Function 'do_compile' failed (see
/home/eballetbo/Workspace/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lttng-ust-0.15-r2/temp/log.do_compile.24087
for further information)
ERROR: Logfile of failure stored in:
/home/eballetbo/Workspace/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lttng-ust-0.15-r2/temp/log.do_compile.24087
Log data follows:
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
| NOTE: make -j 4
| make  all-recursive
| make[1]: Entering directory
`/home/eballetbo/Workspace/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lttng-ust-0.15-r2/ust-0.15'
| Making all in snprintf
| make[2]: Entering directory
`/home/eballetbo/Workspace/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lttng-ust-0.15-r2/ust-0.15/snprintf'
| /bin/sh ../arm-poky-linux-gnueabi-libtool  --tag=CC   --mode=compile
arm-poky-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize
-mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8
--sysroot=/home/eballetbo/Workspace/yocto/build/tmp/sysroots/igep0020
-DHAVE_CONFIG_H -I. -I.. -I../include/ust  -I../include
-I../libustcomm  -DUST_COMPONENT="ust_snprintf" -fPIC
-fno-strict-aliasing -Wall -O2 -pipe -g -feliminate-unused-debug-types
-MT libustsnprintf_la-vfprintf.lo -MD -MP -MF
.deps/libustsnprintf_la-vfprintf.Tpo -c -o
libustsnprintf_la-vfprintf.lo `test -f 'vfprintf.c' || echo
'./'`vfprintf.c
| arm-poky-linux-gnueabi-libtool: compile:  arm-poky-linux-gnueabi-gcc
-march=armv7-a -fno-tree-vectorize -mthumb-interwork
-mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8
--sysroot=/home/eballetbo/Workspace/yocto/build/tmp/sysroots/igep0020
-DHAVE_CONFIG_H -I. -I.. -I../include/ust -I../include -I../libustcomm
-DUST_COMPONENT=ust_snprintf -fPIC -fno-strict-aliasing -Wall -O2
-pipe -g -feliminate-unused-debug-types -MT
libustsnprintf_la-vfprintf.lo -MD -MP -MF
.deps/libustsnprintf_la-vfprintf.Tpo -c vfprintf.c  -fPIC -DPIC -o
.libs/libustsnprintf_la-vfprintf.o
| vfprintf.c: In function 'ust_safe_vfprintf':
| vfprintf.c:956:1: error: unrecognizable insn:
| (insn 3968 3967 3969 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
|         (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg ])
|                         (const_int 8 [0x8]))
|                     (reg/f:SI 370 [ argtable.7 ])) [0 *D.6937_569+0
S1 A32]))) vfprintf.c:555 -1
|      (nil))
| vfprintf.c:956:1: internal compiler error: in extract_insn, at recog.c:2109
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See <http://gcc.gnu.org/bugs.html> for instructions.
| make[2]: *** [libustsnprintf_la-vfprintf.lo] Error 1
| make[2]: Leaving directory
`/home/eballetbo/Workspace/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lttng-ust-0.15-r2/ust-0.15/snprintf'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
`/home/eballetbo/Workspace/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lttng-ust-0.15-r2/ust-0.15'
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| ERROR: Function 'do_compile' failed (see
/home/eballetbo/Workspace/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lttng-ust-0.15-r2/temp/log.do_compile.24087
for further information)
NOTE: package lttng-ust-0.15-r2: task do_compile: Failed
ERROR: Task 2016
(/home/eballetbo/Workspace/yocto/meta/recipes-kernel/lttng/lttng-ust_0.15.bb,
do_compile) failed with exit code '1'

Cheers,
   Enric

Re: Yocto weekly bug trend charts -- WW35

David Stewart

#2571

Very cool to see the trend continue in a good direction - thanks everyone for your hard work - it really counts!!

Show quoted text

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Xu, Jiajun
Sent: Sunday, August 28, 2011 6:24 PM
To: yocto@...
Subject: [yocto] Yocto weekly bug trend charts -- WW35

Hi all,
	The overall open bug trend continue to decrease last week. The new-
submit vs. fixed bug is 35 vs. 40. Open bug number decreased to 136. WDD
number decreased to 675, which is close to the number of 1.0 release. Bug
status of WW35 could be found on
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend.

Best Regards,
Jiajun
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

Re: Best way to override EXTRA_OECONF

Gary Thomas

#2570

On 2011-08-29 15:28, Chris Tapp wrote:
I'm using libGL provided by mesa-xlib, which includes mesa-common.

I also want to use libglu, but mesa-common says:

EXTRA_OECONF = "--disable-glu \

Is there a way I can override this without having to alter mesa-common.inc.

Would a mesa-xlib.bbappend file with

EXTRA_OECONF += "--enable-glu \

do it?Try something like this in your .bbappend file:
  EXTRA_OECONF := "${@oe_filter_out('--disable-glu', '${EXTRA_OECONF}', d)}"
  EXTRA_OECONF += "--enable-glu "

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

Best way to override EXTRA_OECONF

Chris Tapp

#2569

I'm using libGL provided by mesa-xlib, which includes mesa-common.

I also want to use libglu, but mesa-common says:

EXTRA_OECONF = "--disable-glu \

Is there a way I can override this without having to alter mesa- common.inc.

Would a mesa-xlib.bbappend file with

EXTRA_OECONF += "--enable-glu \

do it?

Chris Tapp

opensource@...
www.keylevel.com