|
Re: Bugzilla Changes
Darren Hart <dvhart@...>
On 11/01/2010 02:40 PM, Bruce Ashfield wrote:
On 10-11-01 4:13 PM, Saul Wold wrote:Agree in principle.On 11/01/2010 12:17 PM, Darren Hart wrote:This is too much separation, having over categorizationOn 10/30/2010 01:50 AM, Saul Wold wrote:Good point. (See my reply to Mark's email)The divide between User Space and Tool Chain is a bit vague. For I'd suggest three categories:Let me confirm: - kernel runtime (this includes all errors, panics, BUGs, etc. from the three categories I listed above - no objection). It's still 3 categories, but separate by type of bug instead of area of bug. It's still fine with me. My biggest concern was keeping the kernel separate, and it is in either form. I'll happily defer to Bruce with respect to an efficient set of kernel bug categories for an embedded "not-a-distribution". Let's keep it simple.Agreed. -- Darren Hart Embedded Linux Kernel
|
|
|
|
Poky weekly bug trend charts -- WW44
Xu, Jiajun <jiajun.xu@...>
Hi all,
This is the Poky weekly bug trend charts for last week (WW44). The open bug number increased to 133. There were only few bugs submitted/fixed in last week. The 1st chart indicates the total open bug number. The 2nd chart indicates the new bug submission and bug fixing count every week. Best Regards, Jiajun
|
|
|
|
Re: nightly-release takes more than 24 hours to build.
Tian, Kevin <kevin.tian@...>
From: Richard PurdieIn case you didn't note Qing's investigation last week, attach his mail for your reference. Thanks Kevin
|
|
|
|
Re: Build failures on yocto
Hector Oron <hector.oron@...>
Hi,
2010/11/1 Hector Oron <hector.oron@...>: #! /bin/sh case $Debian_build_system inNOTE: package libtool-cross-2.2.10-r1: task do_package_write: Succeeded NOTE: Running task 1448 of 1529 (ID: 433, /srv/build/builds/menuconfig2-test/build/rootfs/yocto/laverne-4.0/meta/recipes-kernel/linux/linux-dummy.bb, do_package_write_ipk) NOTE: package linux-dummy-1.0-r1: task do_package_write_ipk: Started ERROR: Task failed: opkg-build execution failed NOTE: package linux-dummy-1.0-r1: task do_package_write_ipk: Failed ERROR: Task 433 (/srv/build/builds/menuconfig2-test/build/rootfs/yocto/laverne-4.0/meta/recipes-kernel/linux/linux-dummy.bb, do_package_write_ipk) failed with 1 Waiting for 1 active tasks to finish: 1: perl-5.8.8-r20 do_package_write_ipk (pid 6797) NOTE: Not creating empty archive for perl-module-cgi-eg-make-links-5.8.8-r20 NOTE: package perl-5.8.8-r20: task do_package_write_ipk: Succeeded ERROR: '/srv/build/builds/menuconfig2-test/build/rootfs/yocto/laverne-4.0/meta/recipes-kernel/linux/linux-dummy.bb' failed make: *** [/srv/build/builds/menuconfig2-test/build/rootfs/yocto/laverne-4.0/foo] Error 1 EOFBest regards,
|
|
|
|
Re: Build failures on yocto
Richard Purdie <rpurdie@...>
On Tue, 2010-11-02 at 09:17 +0000, Hector Oron wrote:
Hi,Which MACHINE is that set for? Its unusual for the system to be using linux-dummy. Cheers, Richard
|
|
|
|
Re: Build failures on yocto
Hector Oron <hector.oron@...>
Hello,
2010/11/1 Richard Purdie <rpurdie@...>: I don't have answers to all of the failures but let me try and respond On Mon, 2010-11-01 at 18:23 +0000, Hector Oron wrote:Yes, it is 64 bit kernel host running a 32 bit userland.lenny_i386)At a guess this is a 64 bit kernel and a 32 bit userspace? What does Linux enorme 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux I suspect if you addBuild attempted with BUILD_ARCH="i686" BB_NUMBER_THREADS="2" PARALLEL_MAKE="-j 2" MACHINE=$(BOARD) bitbake $(YOCTO_IMAGE) got same result as above. Same as the above failure (64 bit kernel and 32 bit userspace)?Sure. If it was not set, scripts warn about it, once you set it up, it goes through.others|*)Right, but it detected that? Best regards, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
|
|
|
|
Re: Build failures on yocto
Hector Oron <hector.oron@...>
Hello,
2010/11/2 Richard Purdie <rpurdie@...>: Which MACHINE is that set for? Its unusual for the system to be usingIt is a balloon3 [1]. I think you have not official support for it. I also got an Intel Embedded Devkit 1-N450 (Black Sand) which I could attempt to build for it. [1] http://balloonboard.org/ Best regards, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
|
|
|
|
Re: Build failures on yocto
Richard Purdie <rpurdie@...>
On Tue, 2010-11-02 at 10:03 +0000, Hector Oron wrote:
Only certainly variables can be passed through the environment. Can youAt a guess this is a 64 bit kernel and a 32 bit userspace? What doesYes, it is 64 bit kernel host running a 32 bit userland. put the line in local.conf please and retry as otherwise it won't have any effect. Ok, good.Same as the above failure (64 bit kernel and 32 bit userspace)?Sure.If it was not set, scripts warn about it, once you set it up, it goes through.others|*)Right, but it detected that? Cheers, Richard
|
|
|
|
Re: Build failures on yocto
Richard Purdie <rpurdie@...>
On Tue, 2010-11-02 at 10:08 +0000, Hector Oron wrote:
Hello,So to be clear, you set MACHINE="balloon3"? You're therefore building with some layer or additional metadata? I'd suggest trying a supported machine like "atom-pc" first before trying to add your own. Cheers, Richard
|
|
|
|
Re: Build failures on yocto
Hector Oron <hector.oron@...>
Hello,
2010/11/2 Richard Purdie <rpurdie@...>: So to be clear, you set MACHINE="balloon3"? You're therefore buildingYes and yes. I'll attempt "atom-pc" later on, but that is not much of interest for me. Thanks. Best regards, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
|
|
|
|
Re: Build failures on yocto
Richard Purdie <rpurdie@...>
On Tue, 2010-11-02 at 11:39 +0000, Hector Oron wrote:
2010/11/2 Richard Purdie <rpurdie@...>:I'd just appreciate people being a little clearer about what they'reSo to be clear, you set MACHINE="balloon3"? You're therefore buildingYes and yes. I'll attempt "atom-pc" later on, but that is not much of attempting to do. Obviously I don't know how you've setup this balloon3 target but knowing this isn't an out the box configuration might help me target my replies to you. There would appear to be a problem with the kernel provision for your board. As a hint, either have a kernel recipe and point to it with PREFERRED_PROVIDER_virtual/kernel setting in the machine configuration or ensure the machine in question is listed in COMPATIBLE_MACHINE of the kernel recipe you want to use. Cheers, Richard
|
|
|
|
Re: yocto tools on a nokia n800
tiagoprn <tiagoprn@...>
Hello again!
toggle quoted messageShow quoted text
I think nokia n8xx could be a nice example of what yocto/poky are capable of. Especially now that Nokia has abandoned this devices, it would be cool to have a new OS being supported on it. I'm new to poky, so, if you could make it easier to build the toochain to build it to a n800, me and many other n8xx owners would be quite happy. Regards, 2010/11/1 Bruce Ashfield <bruce.ashfield@...>
--
*** TIAGOPRN Desenvolvedor Web, Linux e Windows (Django, Python, Delphi, Lazarus, MySQL, SQLite) E-mail: tiagoprn@... Blog: http://tgplima.net84.net LinkedIn (profile público): http://br.linkedin.com/in/tiagoparanhoslima twitter: https://twitter.com/tiagoprn
|
|
|
|
Re: yocto tools on a nokia n800
Tom Zanussi <tom.zanussi@...>
On Tue, 2010-11-02 at 06:20 -0700, tiagoprn wrote:
Hello again!Yes, I agree. I'm new to poky, so, if you could make it easier to build the toochainRight, it doesn't seem to be working out of the box - I'll take a look and see if we can't rescue it from meta-extras... BTW, I'd actually like to have one of these for myself - can you suggest a source for them other than eBay? Thanks, Tom
|
|
|
|
Re: yocto tools on a nokia n800
Richard Purdie <rpurdie@...>
On Tue, 2010-11-02 at 09:48 -0500, Tom Zanussi wrote:
On Tue, 2010-11-02 at 06:20 -0700, tiagoprn wrote:Let me chip in with some information here. Poky used to support the n800Hello again!Yes, I agree. machine semi-officially and it ran sato quite well including the wiki and touchscreen. The problem has been that the xserver and kernel recipes were not updated, Poky moved on and these older versions no longer worked/interacted well. For this reason, the machine was moved to meta-extras as it no longer worked. I know its possible to make it work again and there shouldn't be massive amounts of effort needed. If someone does step up and fixes it up and agrees to maintain it, the machine can come back. It is going to need someone to give it some TLC though. Cheers, Richard
|
|
|
|
Re: Bugzilla Changes
Bruce Ashfield <bruce.ashfield@...>
On 10-11-01 07:42 PM, Darren Hart wrote:
On 11/01/2010 02:40 PM, Bruce Ashfield wrote:It does. What we can also do, is split it betweenOn 10-11-01 4:13 PM, Saul Wold wrote:Agree in principle.On 11/01/2010 12:17 PM, Darren Hart wrote:This is too much separation, having over categorizationOn 10/30/2010 01:50 AM, Saul Wold wrote:Good point. (See my reply to Mark's email)The divide between User Space and Tool Chain is a bit vague. For 'kernel' and 'BSP'. I've been triaging bugs like this for 6 years now, and typically it is very hard for the submitters to categorize properly. But typically they do know if it is particular to a board (BSP) or everywhere (kernel). The BSP would also cover the drivers category that you had listed above .. since often, drivers are exercised by one (or few) boards and those are the ones that have problems. Agreed. We are aligned here. We'll adjust these as we go forward to whatever makes sense. Bruce Let's keep it simple.Agreed.
|
|
|
|
Re: World Package List
Saul Wold <sgw@...>
I have updated the spreadsheet and removed items that should not have been included (-natives and other tools). I have also added annotation to the first column to show some potential adjustments and existing inter-dependencies within the list.
toggle quoted messageShow quoted text
Again, please review the remaining items and provide any input. Thanks Sau!
On 10/30/2010 01:44 AM, Saul G. Wold wrote:
|
|
|
|
Python version problems
Richard Purdie <rpurdie@...>
Hi,
I've seen a few comments that people are struggling with the python version Poky requires not being present in certain distros. I can now point to one potential solution in the form of a standalone install of python (in /opt/poky) which Poky itself can generate. I've shared prebuilt 32 and 64 bit versions of these at: http://autobuilder.yoctoproject.org/downloads/miscsupport/python-nativesdk-standalone-i586.tar.bz2 http://autobuilder.yoctoproject.org/downloads/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2 They are not statically linked but are self contained with all the libraries they need so should work on pretty much any Linux system. To use them, extract as root in / and then just run: export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH or export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH before running bitbake and the version of python in these tarballs will be used by bitbake instead. For reference, you can generate these tarballs by running: SDKMACHINE=i586 bitbake external-python-tarball or SDKMACHINE=x86_64 bitbake external-python-tarball using Poky's master branch. Cheers, Richard
|
|
|
|
Re: zypper and poky architectures
Qing He <qing.he@...>
On Mon, 2010-11-01 at 23:37 +0800, Mark Hatle wrote:
(Sorry for the late response, today's my first day back from CELF)This is good. I may test if this works and let's see if Richard has any comments on it. It seems to be an elegant solution, but need some efforts to find outThanks for the info. If we are going for dynamic platform specs, itYa, if we are able to do things dynamically, then the naming is no longer how this can fit in current zypper. Hmm, this is not quite what I've been thinking about. The problem isSince Poky does not yet have the ability to deal with Multiarch builds, this isI don't really have ideas how this is done. I think on debian this isThat would be some work to do, maybe 1.0 is a good time to get zypperYes, we also need to get multi-arch as well.. (i.e. 32-bit and 64-bit at the the shared library, and the library path renaming. The above winner works fine for executables, nobody needs different arch versions of a same binary, but it's possible that several different archs are used for different binaries, that's where the library problem comes in. Let's say we have an i586 `ls', and an x86_64 `cp' that coexist in the same box, they would possibly link to two different ld-linux.so and libc.so (this scenario is common requirement on x86, esp. x86_64). If 32bit rpms can be installed to 64bit platforms directly without any modification, that would be great. I guess the deb way to solve this is to create a special kind of package, namely `lib32c_2.10.1-r1.x86_64.deb', which installs something like /lib32/ld-linux-i586.so.2. If the executable can links to it, the dedicated ld.so cache can get most of its library path right. However, sadly, this special lib32 and maybe the 32bit executable package, may not be installable on pure i586 archs. So should this kind of multiarch be concerned, where multiarch packages coexist instead of being exlusive? Thanks, Qing
|
|
|
|
some yocto/poky issues and errors
Frans Meulenbroeks <fransmeulenbroeks@...>
Dear all,
Not sure whether I should sent this here or to the poky ML. Trying here first, fee free to forward/redirect. After my initial success of building poky 4.0 with the delivered config, I decided to try to add my own layer (with some private recipes), meanwhile also switching to MACHINE = "beagleboard". These recipes build under OE. In order to get things parsing I had to rework a few legacy staging things (no big deal). Also I got an error: NOTE: Handling BitBake files: - (0053/0886) [ 5 %]NOTE: Error expanding variable do_package ERROR: string index out of range while parsing /home/frans/yocto/poky-laverne-4.0/tv.axon.openembedded.2010/recipes/linux/linux-factory-sygtd1_2.6.34.bb For now I removed the do_package function. No idea if that is sound. After doing so the parsing goes well but I get an interesting traceback, even if no recipe is given. See the log below. I suspect this is because a var is referenced somewhere but the var is not initialised. Guess this should not happen. Then again my pythonese is not good enough to diagnose this. Any suggestion is appreciated (meanwhile I'll try to use bisecting to find the cause). Best regards, Frans frans@frans-desktop:~/yocto/poky-laverne-4.0$ bitbake -v -v -v -D -D -D DEBUG: Removed the following variables from the environment: GDM_KEYBOARD_LAYOUT, GNOME_DESKTOP_SESSION_ID, LESSOPEN, CVS_RSH, GNOME_KEYRING_CONTROL, SPEECHD_PORT, SHLVL, MANDATORY_PATH, WINDOWID, CVSROOT, GDMSESSION, LESSCLOSE, ORBIT_SOCKETDIR, GTK_MODULES, HISTIGNORE, XDG_CONFIG_DIRS, DEFAULTS_PATH, OLDPWD, GDM_LANG, HISTCONTROL, BUILDDIR, OE_TOPDIR, LS_COLORS DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/bitbake.conf DEBUG: CONF conf/bitbake.conf:637: including conf/site.conf DEBUG: CONF file 'conf/site.conf' not found DEBUG: CONF conf/bitbake.conf:638: including conf/auto.conf DEBUG: CONF file 'conf/auto.conf' not found DEBUG: CONF conf/bitbake.conf:639: including conf/local.conf DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/tv.axon.openembedded.gtd100/conf/local.conf DEBUG: CONF conf/bitbake.conf:640: including conf/build/x86_64-linux.conf DEBUG: CONF file 'conf/build/x86_64-linux.conf' not found DEBUG: CONF conf/bitbake.conf:641: including conf/target/INVALID-INVALID.conf DEBUG: CONF file 'conf/target/INVALID-INVALID.conf' not found DEBUG: CONF conf/bitbake.conf:642: including conf/machine/beagleboard.conf DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/beagleboard.conf DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/beagleboard.conf:17: including conf/machine/include/tune-cortexa8.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/include/tune-cortexa8.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/machine/include/tune-cortexa8.inc DEBUG: CONF conf/bitbake.conf:643: including conf/machine-sdk/${SDKMACHINE}.conf DEBUG: CONF file 'conf/machine-sdk/${SDKMACHINE}.conf' not found DEBUG: CONF conf/bitbake.conf:644: including conf/distro/poky.conf DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:57: including conf/distro/include/poky-default.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-default.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-default.inc DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-default.inc:52: including conf/distro/include/as-needed.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/as-needed.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/as-needed.inc DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:60: including conf/distro/include/poky-eglibc.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-eglibc.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-eglibc.inc DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:95: including conf/distro/include/poky-fixed-revisions.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-fixed-revisions.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/poky-fixed-revisions.inc DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:96: including conf/distro/include/preferred-xorg-versions.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/preferred-xorg-versions.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/preferred-xorg-versions.inc DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:139: including conf/distro/include/world-broken.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/world-broken.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/world-broken.inc DEBUG: CONF /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/poky.conf:140: including conf/distro/include/distro_tracking_fields.inc DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/distro_tracking_fields.inc: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/distro/include/distro_tracking_fields.inc DEBUG: CONF conf/bitbake.conf:645: including conf/documentation.conf DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/documentation.conf DEBUG: CONF conf/bitbake.conf:646: including conf/sanity.conf DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/sanity.conf DEBUG: CONF conf/bitbake.conf:647: including conf/abi_version.conf DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/conf/abi_version.conf DEBUG: BB classes/base.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/base.bbclass DEBUG: BB :0: inheriting classes/patch.bbclass DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/patch.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/patch.bbclass DEBUG: BB :0: inheriting classes/staging.bbclass DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/staging.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/staging.bbclass DEBUG: BB :0: inheriting classes/mirrors.bbclass DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/mirrors.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/mirrors.bbclass DEBUG: BB :0: inheriting classes/utils.bbclass DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/utils.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/utils.bbclass DEBUG: BB :0: inheriting classes/utility-tasks.bbclass DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/utility-tasks.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/utility-tasks.bbclass DEBUG: BB :0: inheriting classes/metadata_scm.bbclass DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/metadata_scm.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/metadata_scm.bbclass DEBUG: BB classes/devshell.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/devshell.bbclass DEBUG: BB classes/package_ipk.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/package_ipk.bbclass DEBUG: BB :0: inheriting classes/package.bbclassmachine DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/package.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/package.bbclass DEBUG: BB :0: inheriting classes/packagedata.bbclass DEBUG: BB /home/frans/yocto/poky-laverne-4.0/meta/classes/packagedata.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/packagedata.bbclass DEBUG: BB classes/debian.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/debian.bbclass DEBUG: BB classes/poky.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/poky.bbclass DEBUG: BB classes/devshell.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/devshell.bbclass DEBUG: BB classes/insane.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/insane.bbclass DEBUG: BB classes/sstate.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/sstate.bbclass DEBUG: BB classes/sanity.bbclass: handle(data, include) DEBUG: LOAD /home/frans/yocto/poky-laverne-4.0/meta/classes/sanity.bbclass DEBUG: Using '${OE_TOPDIR}/tmp/cache/bb_persist_data.sqlite3' as the persistent data cache DEBUG: Clearing SRCREV cache due to cache policy of: clear DEBUG: mkdirhier(${OE_TOPDIR}/tmp/cache) DEBUG: Using cache in '${OE_TOPDIR}/tmp/cache/bb_codeparser.dat' for codeparser cache FATAL: Traceback (most recent call last): File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake//bin/bitbake", line 216, in <module> ret = main() File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake//bin/bitbake", line 177, in main cooker = bb.cooker.BBCooker(configuration, server) File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/cooker.py", line 85, in __init__ self.parseConfigurationFiles(self.configuration.file) File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/cooker.py", line 555, in parseConfigurationFiles bb.event.fire(bb.event.ConfigParsed(), self.configuration.data) File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/event.py", line 98, in fire fire_class_handlers(event, d) File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/event.py", line 68, in fire_class_handlers ret = bb.utils.better_eval("tmpHandler(e)", locals) File "/home/frans/yocto/poky-laverne-4.0/scripts/..//bitbake/lib/bb/utils.py", line 373, in better_eval return eval(source, _context, locals) File "<string>", line 1, in <module> AttributeError: 'NoneType' object has no attribute 'find'
|
|
|
|
Re: some yocto/poky issues and errors
Frans Meulenbroeks <fransmeulenbroeks@...>
2010/11/3 Frans Meulenbroeks <fransmeulenbroeks@...>:
Dear all,Nevermind, already found the cause of the traceback. I accidently ran bitbake in the wrong dir. My default setup is such that BBPATH etc is set in such a way that I can effectively run bitbake from any dir once the env is set. Guess it would be nice if bitbake would have given a decent error msg though. Frans (btw: still confused on the do_package thing)
|
|
|