[yocto] How to find Log
How to locate Log file while a error occur. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
James W. wrote on 2012-02-14:
> How to locate Log file while a error occur.
It's under the directory ${WORKDIR}/temp/. Actually when an error occurs, you
can find the specific log file in the output, something like.
ERROR: Logfile of failure stored in:
/intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
Best Regards,
Lianhao
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
On Feb 14, 2012, at 4:04 AM, Lu, Lianhao wrote:
> James W. wrote on 2012-02-14:
>> How to locate Log file while a error occur.
>
> It's under the directory ${WORKDIR}/temp/. Actually when an error occurs, you
> can find the specific log file in the output, something like.
>
> ERROR: Logfile of failure stored in:
> /intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
>
> Best Regards,
> Lianhao
>
>
I have a similar questions. If the error occurs and the console log information
scrolls too far to get back to, how do I find the error log file then? I know
what directory all the logs will be, but is there an easy way to find the one
with the error??
Jim A
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
>>> How to locate Log file while a error occur.
>>
>> It's under the directory ${WORKDIR}/temp/. Actually when an error occurs,
>> you can find the specific log file in the output, something like.
>>
>> ERROR: Logfile of failure stored in:
>> /intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
>>
>> Best Regards,
>> Lianhao
>>
>>
> I have a similar questions. If the error occurs and the console log
> information scrolls too far to get back to, how do I find the error log file
> then? I know what directory all the logs will be, but is there an easy way to
> find the one with the error??
This is true - I set my terminal scrollback to lines to avoid this.
May be that error line should be displayed both before and after the log.
I will see if I can find where this happens and create a patch. But
that will have to wait until after ELC 2012.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Segmentation fault with "hob"-command
Hello,I am evaluating Yocto, therefore sorry, if it is a beginner fault; I have a problem starting "hob".After the command "hob" the system tells that some tools have to be built. The build endswith the following lines:- snip ---...NOTE: package pseudo-native-1.1.1-r2: task do_populate_sysroot: StartedNOTE: package pseudo-native-1.1.1-r2: task do_populate_sysroot: SucceededNOTE: Tasks Summary: Attempted 126 tasks of which 0 didn't need to be rerun and 0 failed./Yocto/poky-edison-6.0/scripts/bitbake: Zeile 86: 14880 Speicherzugriffsfehler PSEUDO_BINDIR=$PSEUDOBINDIR PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo $BITBAKE $@- snap ---German output: "Speicherzugriffsfehler" = "segmentation fault"System-infos:Build-System: OpenSuSE 11.3, 32bitYocto version: "poky-edison-6.0-tar-bz2" from the Yokto download serverThe absolute same problem also appears with the following constellation:Build system: OpenSuSE 11.3 64bitYocto version: "poky-edison-6.0-tar-bz2 'from yocto download serverOn the 64-bit system, I have the "nightly build" ("http://autobuilder.yoctoproject.org/nightly/20120213-1/yocto.tar.bz2")reinstalled.Here I get the following output:- snip ---...NOTE: package tar-replacement-native-1.26-r0: task do_populate_sysroot: StartedNOTE: package tar-replacement-native-1.26-r0: task do_populate_sysroot: SucceededNOTE: Tasks Summary: Attempted 126 tasks of which 0 didn't need to be rerun and 0 failed./Yocto/yocto/scripts/bitbake: Zeile 95: 29888 Speicherzugriffsfehler PSEUDO_BINDIR=$PSEUDOBINDIR PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo $BITBAKE $@- snap ---From a gdb session (evaluation of the core dump) of the nightly build I get the following output:- snip ---...Core was generated by `python /Yocto/yocto/bitbake/bin/bitbake -r conf/hob-pre.conf -R conf/hob-post.c'.Program terminated with signal 11, Segmentation fault.#0 0x7f0254626c9e in gdk_window_enable_synchronized_configure () from /usr/lib64/libgdk-x11-2.0.so.0(gdb)- snap ---The error occurred in each case at the first attempt after a new installation.Commands:- snip ---source oe-init-build-envhob- snap ---Changes in "local.conf":- snip ---MACHINE ?= "atom-pc"- snap ---Is it a bug, or a beginner's mistake?Thanks in advance,Siegfried SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-oracle-java
Hello All, I see that a meta-oracle-java layer showed up recently in the yocto repositories. That's great. Was there an announcement about this new layer sent on a mailing list or posted in a blog? I had thought I was on all the yocto-related mail lists (https://lists.yoctoproject.org/), but I wasn't aware of this layer until I just read through the repository list (http://git.yoctoproject.org/cgit/cgit.cgi/). I did find a mention about some jdk work in the technical team meeting notes on 1/24, but it was sort of cryptic. By any chance, is there an openjdk layer coming soon? If only I had gone to ELC this week Thanks, Bob ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] OpenEmbedded/Yocto Freescale ARM BSP Layer
On Sat, Feb 11, 2012 at 11:19 AM, Adrian Alonso wrote: > *We are proud to announce the creation of a mailing list to easy the > communication of people using Freescale’s ARM* Hi Adrian, As one of these users, thank you for helping to create a support structure around OpenEmbedded and the Freescale portfolio! I noticed that the i.MX51 is all that is in there right now. Would this be an appropriate place for the i.MX23 as well? I wasn't sure if the scope was being limited or if this was an artifact of the newness of the repository. Again, many thanks! Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Design: build fails scenario
I've finally managed to put something together on how to handle build failure in Hob 1.2. The document is here: https://wiki.yoctoproject.org/wiki/File:Build-fail-flow-v1.0.pdf Let me know if anything doesn't make sense or you have any suggestions. Thanks! Belen - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Segmentation fault with "hob"-command (now no html)
Sorry for the last post in HTML-Format.
I didn't recognize that my provider has changed the format and doesn't send
text-messages any more.
Perhaps the admin may delete my wrong post.
Hello,
I am evaluating Yocto, therefore sorry, if it is a beginner fault; I have a
problem starting "hob".
After the command "hob" the system tells that some tools have to be built.
The build ends
with the following lines:
- snip ---
...
NOTE: package pseudo-native-1.1.1-r2: task do_populate_sysroot: Started
NOTE: package pseudo-native-1.1.1-r2: task do_populate_sysroot: Succeeded
NOTE: Tasks Summary: Attempted 126 tasks of which 0 didn't need to be rerun
and 0 failed.
/Yocto/poky-edison-6.0/scripts/bitbake: Zeile 86: 14880
Speicherzugriffsfehler PSEUDO_BINDIR=$PSEUDOBINDIR
PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib
PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo
$BITBAKE $@
- snap ---
German output: "Speicherzugriffsfehler" = "segmentation fault"
System-infos:
Build-System: OpenSuSE 11.3, 32bit
Yocto version: "poky-edison-6.0-tar-bz2" from the Yokto download server
The absolute same problem also appears with the following constellation:
Build system: OpenSuSE 11.3 64bit
Yocto version: "poky-edison-6.0-tar-bz2 'from yocto download server
On the 64-bit system, I have the "nightly build"
("http://autobuilder.yoctoproject.org/nightly/20120213-1/yocto.tar.bz2";)
reinstalled.
Here I get the following output:
- snip ---
...
NOTE: package tar-replacement-native-1.26-r0: task do_populate_sysroot:
Started
NOTE: package tar-replacement-native-1.26-r0: task do_populate_sysroot:
Succeeded
NOTE: Tasks Summary: Attempted 126 tasks of which 0 didn't need to be rerun
and 0 failed.
/Yocto/yocto/scripts/bitbake: Zeile 95: 29888 Speicherzugriffsfehler
PSEUDO_BINDIR=$PSEUDOBINDIR PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib
PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo
$BITBAKE $@
- snap ---
>From a gdb session (evaluation of the core dump) of the nightly build I get
the following output:
- snip ---
...
Core was generated by `python /Yocto/yocto/bitbake/bin/bitbake -r
conf/hob-pre.conf -R conf/hob-post.c'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f0254626c9e in gdk_window_enable_synchronized_configure ()
from /usr/lib64/libgdk-x11-2.0.so.0
(gdb)
- snap ---
The error occurred in each case at the first attempt after a new
installation.
Commands:
- snip ---
source oe-init-build-env
hob
- snap ---
Changes in "local.conf":
- snip ---
MACHINE ?= "atom-pc"
- snap ---
Is it a bug, or a beginner's mistake?
Thanks in advance,
Siegfried
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Design: build fails scenario
On Tuesday 14 February 2012 16:13:46 Barros Pena, Belen wrote: > I've finally managed to put something together on how to handle build > failure in Hob 1.2. > > The document is here: > > https://wiki.yoctoproject.org/wiki/File:Build-fail-flow-v1.0.pdf Looking through this document and talking to Belen there are a couple of things worth noting: * There will be build failures resulting from user configuration errors (e.g. network connection is unavailable -> fetch fails, or perhaps the sanity checker catches this earlier); however I suspect for the majority of people using Hob an error indicates a bug or some host system incompatibility (which is probably a bug). In this case all we can do for the user if they aren't capable of fixing the problem themselves is to provide them with an easy way to report the issue. * We plan to investigate implementing a "kerneloops" style build failure reporting system for 1.3 (see bug #1562). Part of this is about having the backend infrastructure to manage submitted issues, but the other is to have an interface to submit them and that will involve extensions to Hob. However as this won't be done for 1.2, in the mean time it might be possible to provide some other way of submitting build errors; but the question is where should they go? I'm not sure we want to default to filing a bug report or sending an email to the mailing list, for example. * We will probably need to embark on an exercise of enumerating the errors that can be produced by the build system (BitBake and metadata), after which we can analyse if certain errors can be handled in a better way, if specific handling can be added to a frontend such as Hob for some errors, and even if we can extend the documentation to cover how to troubleshoot certain classes of errors. This is of course not a small undertaking as a "git grep" of "bb\.*error" and "bb\.*fatal" and even scarier "raise " demonstrates. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to re-use sstate.
On Tue, Feb 07, 2012 at 02:59:54PM +, McClintock Matthew-B29882 wrote: > The paths issue your are speculating on was fixed by myself and Richard last > November. > > I would suggest running bitbake-diffsig to determine the actual sstate > differences. > Usually I'm complaining that sstate cache is not used enough, but today I got pretty decent percentage of reuse while building from scratch 2 similar machines (nokia900 and om-gta04) but also few wrong sysroot references which slipped in (I thought those were fixed). First I've built my image for nokia900, then for om-gta04 (with rm_work disabled to reuse sstate). OE @ ~/shr-core/tmp-eglibc/sysroots/om-gta04 $ grep -R nokia900 . 2>/dev/null >nokia900.log $ wc -l nokia900.log 1673 nokia900.log now lot's of binaries have some reference to nokia900 sysroot, grep shows e.g. "Binary file ./lib/ld-2.15.so matches" $ grep "^Binary file " nokia900.log | wc -l 1637 which is maybe fine.. An then there is few crossscripts and headers some are already in SSTATE_SCAN_FILES some are missing I guess: $ grep -v "^Binary file " nokia900.log | wc -l 36 $ grep -v "^Binary file " nokia900.log | sed 's/:.*//g' | sort -u ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool ./usr/bin/crossscripts/curl-config ./usr/bin/crossscripts/libgcrypt-config ./usr/bin/crossscripts/libtoolize ./usr/include/gmp.h ./usr/lib/gcc/arm-oe-linux-gnueabi/4.6.3/plugin/include/configargs.h ./usr/lib/python2.7/config/Makefile Complete output attached -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ./usr/bin/crossscripts/libgcrypt-config:gpg_error_libs="-L/OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib -lgpg-error" ./usr/bin/crossscripts/libgcrypt-config:gpg_error_cflags="-I/OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/include" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:LTCC="arm-oe-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/OE/shr-core/tmp-eglibc/sysroots/nokia900" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:lt_sysroot=/OE/shr-core/tmp-eglibc/sysroots/nokia900 ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:sys_lib_search_path_spec="/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv7a-vfp-neon-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.3 /OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/arm-oe-linux-gnueabi/lib /OE/shr-core/tmp-eglibc/sysroots/nokia900/lib /OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib/arm-oe-linux-gnueabi/4.6.3 /OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib " ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:LD="arm-oe-linux-gnueabi-ld --sysroot=/OE/shr-core/tmp-eglibc/sysroots/nokia900" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:CC="arm-oe-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/OE/shr-core/tmp-eglibc/sysroots/nokia900" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:LD="arm-oe-linux-gnueabi-ld --sysroot=/OE/shr-core/tmp-eglibc/sysroots/nokia900" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:CC="arm-oe-linux-gnueabi-g++ -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/OE/shr-core/tmp-eglibc/sysroots/nokia900" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:compiler_lib_search_dirs="/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv7a-vfp-neon-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.3 /OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv7a-vfp-neon-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.3/../../../../../arm-oe-linux-gnueabi/lib /OE/shr-core/tmp-eglibc/sysroots/nokia900/lib /OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib/arm-oe-linux-gnueabi/4.6.3 /OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:predep_objects="/OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib/crti.o /OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib/arm-oe-linux-gnueabi/4.6.3/crtbeginS.o" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:postdep_objects="/OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib/arm-oe-linux-gnueabi/4.6.3/crtendS.o /OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib/crtn.o" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:compiler_lib_search_path="-L/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv7a-vfp-neon-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.3 -L/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv7a-vfp-neon-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.6.3/../../../../../arm-oe-linux-gnueabi/lib -L/OE/shr-core/tmp-eglibc/sysroots/nokia900/lib -L/OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib/arm-oe-linux-gnueabi/4.6.3 -L/OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/lib" ./usr/bin/crossscripts/arm-oe-linux-gnueabi-libtool:LD="arm-oe-linux-gnueabi-ld --sysroot=/OE/shr-core/tmp-eglibc/sysroots/nokia900" ./usr/bin/cr
Re: [yocto] How to find Log
On 02/14/2012 04:47 AM, James Abernathy wrote:
On Feb 14, 2012, at 4:04 AM, Lu, Lianhao wrote:
James W. wrote on 2012-02-14:
How to locate Log file while a error occur.
It's under the directory ${WORKDIR}/temp/. Actually when an error occurs, you
can find the specific log file in the output, something like.
ERROR: Logfile of failure stored in:
/intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
Best Regards,
Lianhao
I have a similar questions. If the error occurs and the console log information
scrolls too far to get back to, how do I find the error log file then? I know
what directory all the logs will be, but is there an easy way to find the one
with the error??
In Poky master, we now save the output from bitbake in cooker.log files,
kept under build/tmp/. This will be a feature of our upcoming 1.2
release of Yocto.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
On 02/14/2012 03:00 PM, Scott Garman wrote:
On 02/14/2012 04:47 AM, James Abernathy wrote:
On Feb 14, 2012, at 4:04 AM, Lu, Lianhao wrote:
James W. wrote on 2012-02-14:
How to locate Log file while a error occur.
It's under the directory ${WORKDIR}/temp/. Actually when an error
occurs, you can find the specific log file in the output, something
like.
ERROR: Logfile of failure stored in:
/intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
Best Regards,
Lianhao
I have a similar questions. If the error occurs and the console log
information scrolls too far to get back to, how do I find the error
log file then? I know what directory all the logs will be, but is
there an easy way to find the one with the error??
In Poky master, we now save the output from bitbake in cooker.log
files, kept under build/tmp/. This will be a feature of our upcoming
1.2 release of Yocto.
Scott
Found them! great idea!
Jim A
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] missing USB gadget support on beagleboard?
Hi, I'm sure I'm missing something simple, but I just built Poky from git for beagleboard, and can't figure out USB networking. I expected to find g_cdc and g_ether modules in /lib/modules/3.0.18-yocto-standard+/kernel/drivers/usb, but that directory doesn't actually exist (I guess the drivers are built-in to this kernel). I have MACHINE ??= beagleboard in local.conf, and "bitbake core-image-minimal" did produce a working kernel, uboot, etc. I see some USB messages at boot (see below), but although cdc_ether is mentioned, ifconfig -a lists only loopback. Any suggestions? Thanks! usbcore: registered new interface driver kaweth pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver usbcore: registered new interface driver pegasus usbcore: registered new interface driver asix usbcore: registered new interface driver cdc_ether usbcore: registered new interface driver dm9601 usbcore: registered new interface driver smsc75xx usbcore: registered new interface driver smsc95xx usbcore: registered new interface driver net1080 usbcore: registered new interface driver cdc_subset usbcore: registered new interface driver zaurus usbcore: registered new interface driver MOSCHIP usb-ethernet driver usbcore: registered new interface driver int51x1 cdc_ncm: 04-Aug-2011 usbcore: registered new interface driver cdc_ncm console [netcon0] enabled netconsole: network logging started ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver _regulator_get: ehci-omap.0 supply hsusb0 not found, using dummy regulator _regulator_get: ehci-omap.0 supply hsusb1 not found, using dummy regulator ehci-omap ehci-omap.0: OMAP-EHCI Host Controller ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. -- Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
thank you for your help .
so ,i think log mechanism is very important for such a large build system.
We may should do better on this point.
On Wed, Feb 15, 2012 at 4:23 AM, jfabernathy wrote:
> On 02/14/2012 03:00 PM, Scott Garman wrote:
>>
>> On 02/14/2012 04:47 AM, James Abernathy wrote:
>>>
>>>
>>> On Feb 14, 2012, at 4:04 AM, Lu, Lianhao wrote:
>>>
James W. wrote on 2012-02-14:
>
> How to locate Log file while a error occur.
It's under the directory ${WORKDIR}/temp/. Actually when an error
occurs, you can find the specific log file in the output, something like.
ERROR: Logfile of failure stored in:
/intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
Best Regards,
Lianhao
>>> I have a similar questions. If the error occurs and the console log
>>> information scrolls too far to get back to, how do I find the error log file
>>> then? I know what directory all the logs will be, but is there an easy way
>>> to find the one with the error??
>>
>>
>> In Poky master, we now save the output from bitbake in cooker.log files,
>> kept under build/tmp/. This will be a feature of our upcoming 1.2 release of
>> Yocto.
>>
>> Scott
>>
> Found them! great idea!
>
> Jim A
>
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
James W. wrote on 2012-02-15: > thank you for your help . > so ,i think log mechanism is very important for such a large build system. > We may should do better on this point. I think the utility "tee" works pretty fine for me , e.g., I use something like $ bitbake core-image-minimal | tee my.log. Thanks, -- Dexuan ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Segmentation fault with "hob"-command (now no html)
poldi871.li...@progserv.de wrote on 2012-02-15:
> Sorry for the last post in HTML-Format.
> I didn't recognize that my provider has changed the format and doesn't
> send text-messages any more.
> Perhaps the admin may delete my wrong post.
>
>
> Hello, I am evaluating Yocto, therefore sorry, if it is a beginner
> fault; I have a problem starting "hob". After the command "hob" the
> system tells that some tools have to be built. The build ends with the
> following lines:
>
> - snip --- ... NOTE:
> package pseudo-native-1.1.1-r2: task do_populate_sysroot: Started NOTE:
> package pseudo-native-1.1.1-r2: task do_populate_sysroot: Succeeded
> NOTE: Tasks Summary: Attempted 126 tasks of which 0 didn't need to be
> rerun and 0 failed. /Yocto/poky-edison-6.0/scripts/bitbake: Zeile 86:
> 14880 Speicherzugriffsfehler PSEUDO_BINDIR=$PSEUDOBINDIR
> PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib
> PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1
> $PSEUDOBINDIR/pseudo $BITBAKE $@
>
> - snap ---
> German output: "Speicherzugriffsfehler" = "segmentation fault"
>
> System-infos: Build-System: OpenSuSE 11.3, 32bit Yocto version:
> "poky-edison-6.0-tar-bz2" from the Yokto download server
>
> The absolute same problem also appears with the following constellation:
> Build system: OpenSuSE 11.3 64bit
> Yocto version: "poky-edison-6.0-tar-bz2 'from yocto download server
>
> On the 64-bit system, I have the "nightly build"
> ("http://autobuilder.yoctoproject.org/nightly/20120213-1/yocto.tar.bz2
> ") reinstalled. Here I get the following output: - snip
> --- ... NOTE: package
> tar-replacement-native-1.26-r0: task do_populate_sysroot: Started NOTE:
> package tar-replacement-native-1.26-r0: task do_populate_sysroot:
> Succeeded NOTE: Tasks Summary: Attempted 126 tasks of which 0 didn't
> need to be rerun and 0 failed. /Yocto/yocto/scripts/bitbake: Zeile 95:
> 29888 Speicherzugriffsfehler PSEUDO_BINDIR=$PSEUDOBINDIR
> PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib
> PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1
> $PSEUDOBINDIR/pseudo $BITBAKE $@
>
> - snap ---
>
> From a gdb session (evaluation of the core dump) of the nightly build
> I get the following output:
> - snip ---
> ...
> Core was generated by `python /Yocto/yocto/bitbake/bin/bitbake -r
> conf/hob-pre.conf -R conf/hob-post.c'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x7f0254626c9e in gdk_window_enable_synchronized_configure
> ()
>from /usr/lib64/libgdk-x11-2.0.so.0
> (gdb)
> - snap ---
>
> The error occurred in each case at the first attempt after a new
> installation. Commands: - snip
> --- source oe-init-build-env hob
> - snap ---
>
> Changes in "local.conf":
>
> - snip ---
> MACHINE ?= "atom-pc"
> - snap ---
>
> Is it a bug, or a beginner's mistake?
This seems a pygtk bug of bitbake that only appears on some Linux distribution?
In my Ubuntu 11.04, I don't get the SegFault.
Thanks,
-- Dexuan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto weekly bug trend charts -- WW06
Hi all, The overall open bug trend keep flat during last several weeks. WDD number and Open Bug number are 718 and 145. Bug status of WW06 could be found on https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend. Best Regards, Jiajun ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] missing USB gadget support on beagleboard?
On Tue, Feb 14, 2012 at 4:12 PM, Hollis Blanchard wrote: > Hi, I'm sure I'm missing something simple, but I just built Poky from git > for beagleboard, and can't figure out USB networking. I expected to find > g_cdc and g_ether modules in > /lib/modules/3.0.18-yocto-standard+/kernel/drivers/usb, but that directory > doesn't actually exist (I guess the drivers are built-in to this kernel). > > I have MACHINE ??= beagleboard in local.conf, and "bitbake > core-image-minimal" did produce a working kernel, uboot, etc. I see some USB > messages at boot (see below), but although cdc_ether is mentioned, ifconfig > -a lists only loopback. > > Any suggestions? Thanks! You can look at the default defconfig to see which kernel modules are selected and also make sure the kernel modules are actually included on core-image-minimal. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] missing USB gadget support on beagleboard?
On Tue, Feb 14, 2012 at 10:23 PM, Matthew McClintock wrote: > You can look at the default defconfig to see which kernel modules are > selected and also make sure the kernel modules are actually included > on core-image-minimal. By making sure kernel modules are included... I mean the kernel recipes creates a kernel-modules package. You can see if it's generated, what it contains, and then determine if that is actually whats included on the root file system. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] RDEPENDS fails to find an existing package
Hello all,
I've been trying to package libharu for yocto. So, wrote a recipe for
its latest version libharu_2.2.1.bb. The generated .so, .la and .a files
for this are in the name 'libhpdf'. (I guess this will not cause any
problem.) These files are found in ${WORKDIR}/image/usr/lib
My custom-image RDEPENDS for libharu. While building the custom-image
bitbake complains
| error: Failed dependencies:
| libharu is needed by task-custom-hdb-1.0-r3.ekino
How do I fix this issue?
There were no errors reported while building libharu recipe.
Any pointers in this regard would be very helpful
Regards
Joshua
--
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in
signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
