**** BEGIN LOGGING AT Mon Sep 20 02:59:57 2010 Sep 20 06:00:06 gm Sep 20 06:40:17 bitbake -k world failed again. ERROR: fork failed: 12 (Cannot allocate memory) Sep 20 06:41:24 interesting, i see a relocatable class, but nothing appears to use it. looks like it's for shuffling libs around and fixing w/ chrpath. the doesn't fix search paths for other resources, though :/ Sep 20 06:41:36 grg: you must build more pylons? ;) Sep 20 06:42:10 grg: too bad. allocate more swap? Sep 20 06:42:26 6gb ram + 2gb swap not enough? Sep 20 06:42:32 didn't make too much progress either, our build server is fairly new and seems to have some stability issues Sep 20 06:42:48 * eFfeM_work blames Xen Sep 20 06:43:05 grg, should be, unless there is a mem leak Sep 20 06:43:14 grg: funny, i'm building w/ much less than that, though i'm not building *much*. Sep 20 06:43:27 Unhelpful, normal image builds are fine Sep 20 06:44:13 grg, is this on a specific recipe? and repeatable ? Sep 20 06:44:22 eFfeM_work: -k world :) Sep 20 06:44:36 i'll have a poke around... Sep 20 06:44:44 Unhelpful: you live up your name :-) I knew *that* Sep 20 06:45:04 eFfeM_work: thanks, the jokes i get whenever i'm useful :/ Sep 20 06:45:21 but the error is given on a task while processing a recipe Sep 20 06:46:02 it might be something related to a specific recipe Sep 20 06:46:39 or might just happen whenever it runs out if there's a leak :/ Sep 20 06:47:29 yes, that's why i was asking about reproducability, if it is a specific recipe I could also try a build here (or @home) Sep 20 06:48:12 or he could try building that recipe, maybe it's not in his normal image builds :) Sep 20 06:48:14 actually due to the server issues I gave up on world for now (although I might kick it off again at my workstation tomorrow as I'll be away for a few days) Sep 20 06:48:55 eFfeM_work, Unhelpful. Its reproducable. recipes/farsight/gst-plugins-farsight_0.10.1.bb, do_configure sucks up all the memory rather quickly Sep 20 06:49:02 but I am now trying a bitbake -c fetchall world, that already gave one issue, plan to continue with -c patchall (assuming it exists) Sep 20 06:49:48 grg, at least that helps to pinpoint the problem Sep 20 06:50:03 yeah, it should be fixable knowing the recipe Sep 20 06:50:18 * grg looks at the configure script Sep 20 06:52:10 its another 4 year old recipe. Sep 20 06:52:28 yeah, just saw that too Sep 20 06:52:36 too many people just creating a recipe and let it rot Sep 20 06:56:51 grg: http://farsight.freedesktop.org/releases/obsolete/gst-plugins-farsight/OBSOLETE Sep 20 06:57:15 eFfeM_work, git rm it? Sep 20 06:57:29 i suggest moving to obsolete Sep 20 06:58:02 unless you prefer the curse of koen casted upon you :-) Sep 20 06:58:24 btw: http://farsight.freedesktop.org/releases/obsolete/gst-plugins-farsight/ Sep 20 06:58:47 and: http://farsight.freedesktop.org/releases/obsolete/farsight/OBSOLETE Sep 20 06:59:18 so maybe retire all this farsight stuff as the project moved on to farsight2 2 years ago Sep 20 07:01:34 eFfeM_work, maybe i should just poke Koen to fix the problem? Sep 20 07:02:10 you can try, i didn't know farsight, but seems like something nice Sep 20 07:03:26 good morning Sep 20 07:03:33 hello Sep 20 07:22:25 morning Sep 20 07:24:19 hrw: hi Sep 20 07:31:08 hi Sep 20 07:37:46 hi ericben, hrw, mckoan, all Sep 20 07:38:21 ericben: peeked at your patches, but what I do not understand is why python-modules would depend on python-dev and not on python Sep 20 07:40:43 eFfeM_work: where does python-modules depends on python-dev ? Sep 20 07:41:16 ericben: mistyped, it is rdepends (it is in the inc file where I send a patch for) Sep 20 07:41:32 yes and my patch removes that Sep 20 07:43:12 + it tunes python-distutils to remove unecessary files and it changes the tools used to generate the python-2.6-manifest.inc Sep 20 07:43:33 ah ok, didn't see the inc file was originally generated Sep 20 07:44:13 morning guys Sep 20 07:44:46 ericben: patch looks fine with me, but afaik mickey is our python wiz Sep 20 07:44:52 hi fraxinath Sep 20 07:46:32 i got a question... has anybody ever tried creating a recipe for aacskeys? i wonder wether i should try to get a native version of that premake utility to run and adapt those lua scripts for oe, or do all the compiling with oe instead Sep 20 07:46:57 * eFfeM_work does not have a clue what aacskeys is Sep 20 07:47:51 uhm consider it a c++ written tool with premake lua scripts which allow it to compile under windows/visual studio, macosx and linux Sep 20 07:48:27 eFfeM_work: so can you ack this python patch series ? Sep 20 07:49:46 ericben, looking at them Sep 20 07:49:55 thanks Sep 20 07:50:08 wrt patch3: we don't want to support static linking (removal of libpython2.6a) Sep 20 07:51:58 ericben & not too sure whether python-modules should depend on python itself Sep 20 07:52:48 eFfeM_work: for patch3 : yes but it's not a directory where the linker can find the .a and that's installed on the target Sep 20 07:52:58 true Sep 20 07:53:19 for the depend on python : maybe, I didn't touch to this yet, I just needed to remove the -dev as this was exploding the image size ! Sep 20 07:54:56 i know had the same issue (actually got quite some messages that other -dev packages were not there when creating the image Sep 20 07:56:38 ok, will send ack Sep 20 08:00:47 ericben: acks have been sent Sep 20 08:02:59 eFfeM_work: thanks Sep 20 08:03:04 yw Sep 20 08:03:20 btw, can you try a bitbake gs to check it also fails in your configuration ? Sep 20 08:03:34 I'm finishing a fix for this Sep 20 08:04:16 actually ideally one would not depend on python-modules but instead depend on only those modules that are really needed Sep 20 08:04:22 ericben: will try to build grg Sep 20 08:19:37 good morning Sep 20 08:25:56 hi florian Sep 20 09:09:51 eFfeM_work, i moved my openembedded work dirs from an arch linux to a ubuntu system and now i get /dream/oe1.6/dm8000/build/tmp/cross/mipsel/libexec/gcc/mipsel-oe-linux/4.4.3/cc1: error while loading shared libraries: libcloog.so.0: cannot open shared object file: No such file or directory Sep 20 09:09:58 how do i fix that? Sep 20 09:10:53 do rebuild Sep 20 09:11:12 you changed host system and your host binaries linked to host libraries. Sep 20 09:11:26 ayee Sep 20 09:11:49 what all do i have to rebuild? all native packages? Sep 20 09:11:54 yes Sep 20 09:12:05 is there a command to do exactly that? Sep 20 09:12:24 one command? no. one line of shell? yes Sep 20 09:12:50 hehe sorry that's what i meant Sep 20 09:13:15 check tmp/stamps/YOURHOSTARCHDIR/*_do_build and do 'bitbake -cclean + bitbake" on each of them Sep 20 09:13:38 okay that's what i thought Sep 20 09:15:25 hm there aren't any *build stamps in there Sep 20 09:17:35 then other stamps Sep 20 09:17:48 it was a bit of time siince my last OE build Sep 20 09:19:36 sure, i used fetch instead Sep 20 09:46:33 hi all Sep 20 09:46:48 I'm starting studying oe Sep 20 09:46:55 hi alx_ Sep 20 09:47:17 I'm testing oe Sep 20 09:47:26 compiling x86 images Sep 20 09:47:31 hi mackoan Sep 20 09:47:31 this may sound weird :) Sep 20 09:47:39 hi mckoan Sep 20 09:47:54 hm x86 and amd64 target isnt tested tough Sep 20 09:48:29 well, I may assure that console-image and helloworld-image Sep 20 09:48:35 compile and works :) Sep 20 09:48:49 cannot say the same for x11-image Sep 20 09:48:58 that compiles Sep 20 09:49:30 but on boot I get a lot of "No space left on device" and even waiting a lot... it doesn't come on a working x11 or console login Sep 20 09:49:48 (using ext2 images) Sep 20 09:50:39 that sounded to me like a misconfiguration Sep 20 09:50:48 but I've no glue on where to start search Sep 20 09:50:58 google didn't help me Sep 20 09:51:00 :( Sep 20 09:51:30 woglinde, any idea where to search ? Sep 20 09:52:41 alx hm Sep 20 09:52:59 now I'm building xorg-image Sep 20 09:53:23 the problem is that we have a board which is Atom :) Sep 20 09:53:30 alx Sep 20 09:53:38 alx_: x86 with x11-image has been broken for ages Sep 20 09:53:45 you know the resizefs command? Sep 20 09:53:57 alx make your partition on the atom Sep 20 09:54:08 dd the oe ext2 image on it Sep 20 09:54:16 run resizefs Sep 20 09:54:17 did it already :) Sep 20 09:54:19 off you go Sep 20 09:54:29 hm than I am puzzeld Sep 20 09:54:59 I've an ext2 image of about 2G in size, which 128M are used Sep 20 09:55:50 mckoan, that isn't good :) so x11-image or xorg-image are either broken ? didn't read that they were broken :( Sep 20 09:58:06 what I'm trying to do is an image for for embedded x86 :) Sep 20 09:58:30 alx yes right Sep 20 09:58:42 but why the hell the resizefs dont works Sep 20 10:02:33 woglinde, it works. but when I boot it still says I've no space :) Sep 20 10:03:01 alx hm on which partition? Sep 20 10:03:09 if I mount the image thru loop (it's an ext2 image) I see a lot of free space Sep 20 10:03:20 one single partition Sep 20 10:03:55 it just says me I've no free space when I boot it Sep 20 10:07:56 hrw: problem persists after having rebuild all native packages Sep 20 10:10:05 fraxinath: all *-cross were part of it? Sep 20 10:11:19 hm no the *cross stamps aren't in my host-architecture dir but in my target-architecture dir Sep 20 10:11:35 i'll rebuild those too Sep 20 10:15:04 woglinde, well Sep 20 10:15:08 xorg-image works :) Sep 20 10:49:16 re Sep 20 10:49:34 alx what did you change? Sep 20 10:57:09 woglinde, built xorg-image instead of x11-image Sep 20 10:57:34 I've a python-qt program to run on top of X Sep 20 10:57:48 in the embedded x86 enviroment :) Sep 20 10:58:15 yeah python-qt is nice Sep 20 11:03:49 the idea is to have a small distro which starts x and the the python-qt Sep 20 11:03:59 I think this is something others already did Sep 20 11:04:05 but I was unable to find them Sep 20 11:04:15 and I feel like I'm reinventing the wheel Sep 20 11:06:01 hehe Sep 20 11:06:22 how do you start X? Sep 20 11:06:31 gdm/kdm with autologin? Sep 20 11:06:36 no windowmanager? Sep 20 11:07:28 that will be next step Sep 20 11:07:36 I'd think no wm Sep 20 11:07:58 because it's a full screen single application Sep 20 11:07:59 hm Sep 20 11:08:16 but you can have problems with some focus stuff Sep 20 11:08:24 true Sep 20 11:08:34 thats why we used blackbox in the end Sep 20 11:08:36 with our app Sep 20 11:08:37 now I'm thinking how to solve loss of power Sep 20 11:08:43 written in java Sep 20 11:08:56 how do you manage loss of power Sep 20 11:09:07 loss of power? Sep 20 11:09:23 like ... ops .. i removed the battery Sep 20 11:09:46 hm shouldnt happen in the setup we have Sep 20 11:09:54 that is something that may happens without breaking filesystem :) Sep 20 11:09:58 but we used ubuntu Sep 20 11:10:02 I see Sep 20 11:10:07 and dropped it to the bare deps Sep 20 11:10:13 our current solution is on ubuntu Sep 20 11:10:36 because we needed to much java deps which arent in oe Sep 20 11:10:38 like cxf Sep 20 11:12:56 I see Sep 20 11:12:58 got to go Sep 20 11:13:05 appointment in 30 minutes :) Sep 20 11:13:07 see later Sep 20 12:35:15 hi Sep 20 12:45:03 so, ich schaue mal ob ich mit diesem image den test nachstellen kann Sep 20 12:45:06 oops wrong window Sep 20 12:45:08 dammit :) Sep 20 12:45:15 hihi Sep 20 12:45:32 BitchX in split mode in a terminal, and I always forget to switch the view :) Sep 20 12:53:30 hm? Sep 20 13:01:05 03Sebastian Krzyszkowiak  07org.openembedded.dev * r7f20d12652 10openembedded.git/recipes/freesmartphone/cornucopia.inc: Sep 20 13:01:05 cornucopia: bump SRCREV for proximity sensor support on N900 Sep 20 13:01:05 Signed-off-by: Martin Jansa Sep 20 13:14:55 do we have any source mirrors where I can upload a source tarball and use it in a recipe, using the debian mirror feels wrong :) Sep 20 13:20:37 mr_nice why? Sep 20 13:24:12 woglinde: I don't know if it is ok to generate network traffic to a debian mirror for a non debian distribution. the debian mirrors ofcourse are very reliable Sep 20 13:28:41 is there a reason for /var/spool being in flash and not in volatile ? Sep 20 13:28:50 in recipe base-files Sep 20 13:29:47 ericben better ask on the ml Sep 20 13:30:03 woglinde: ok Sep 20 13:30:22 does anyone have a working build of util-linux-ng they'd be willing to send me the do_install log from? Sep 20 13:30:55 it's failing for me because of multiple files called (literally) ".8" being installed on the same install command line Sep 20 13:31:37 also looksl ike tinderbox is down Sep 20 13:31:42 mzs: works fine here, do you have the error message ? this seems to be the manpages Sep 20 13:32:08 ericben: yeah, i posted on friday (http://permalink.gmane.org/gmane.comp.handhelds.openembedded/37058) and it's the setarch / rdev manpage links Sep 20 13:32:29 /home/michael/git/newstix/tmp/sysroots/x86_64-linux/usr/bin/install: will not overwrite just-created `/home/michael/git/newstix/tmp/work/i486-oe-linux/util-linux-ng-2.17-r29.2/image/usr/share/man/man8/.8' with `.8' Sep 20 13:32:57 interesting Sep 20 13:33:03 The command line it's running is .../tmp/sysroots/x86_64-linux/usr/bin/install -c -m 644 ctrlaltdel.8 cytune.8 setarch.8 ldattach.8 tunelp.8 rtcwake.8 pivot_root.8 switch_root.8 .8 linux32.8 linux64.8 i386.8 .8 '.../tmp/work/i486-oe-linux/util-linux-ng-2.17-r29.2/image/usr/share/man/man8' Sep 20 13:33:07 /home/ebenard/OEUKREA/tmp_angstrom/sysroots/i686-linux/usr/bin/install -c -m 644 ctrlaltdel.8 cytune.8 \ Sep 20 13:33:10 setarch.8 ldattach.8 tunelp.8 rtcwake.8 pivot_root.8 switch_root.8 linux32.8 linux64.8 '/home/ebenard/OE\ Sep 20 13:33:13 UKREA/tmp_angstrom/work/armv5te-angstrom-linux-gnueabi/util-linux-ng-2.17-r30.2/image/usr/share/man/man8\ Sep 20 13:33:20 'I don't have the .8 you have at the end Sep 20 13:33:38 I'm building for arm Sep 20 13:33:38 Yeah. i have a .8 after switch_root and a .8 after linux64 Sep 20 13:33:43 mzs tinderbox had someplrobels after the debian update Sep 20 13:33:54 woglinde: cool, thanks Sep 20 13:33:59 here .8 avec linux64 but you also have a .8 alone Sep 20 13:34:04 ericben: i'm building for i486 Sep 20 13:34:16 args some problems Sep 20 13:37:03 ericben: I'm using autoconf-native 2.63, automake-native 1.11.1, util-linux-ng 2.17, coreutils-native 8.5 Sep 20 13:37:12 and my build host is running make 3.80 Sep 20 13:38:07 mzs: here autoconf-native 2.65, automake-native 1.11.1 and host has make 3.81 Sep 20 13:38:39 hmm, i wonder if something got tweaked in how make handles blank lines (empty variable expansionss and '\') inside a variable setting Sep 20 13:40:39 wow, make 3.80 is 8 years old! Sep 20 13:42:43 mzs yeah Sep 20 13:43:37 i wonder if i can get oe to build & use its own make Sep 20 13:43:49 make isn't in the default ASSUME_PROVIDED but it doesn't seem to get built Sep 20 13:48:44 Yeah. it's definitely something that changed in make 3.81. Sep 20 14:12:54 03Björn Krombholz  07org.openembedded.dev * r224e984680 10openembedded.git/classes/qt4e.bbclass: (log message trimmed) Sep 20 14:12:54 qt4-embedded: avoid circular dependencies for reciped providing qt4-embedded Sep 20 14:12:54 * qt4e.bbclass did add a dependency on qt4-embedded for recipes Sep 20 14:12:54 providing qt4-embedded. This breaks building of qt4-embedded-gles Sep 20 14:12:54 in 2 ways: Sep 20 14:12:55 1. PREFERRED_PROVIDER_qt4-embedded = qt4-embedded-gles Sep 20 14:12:56 adds a circular dependency. Sep 20 14:47:09 anyone seen this failure in numpy Sep 20 14:47:10 arm-angstrom-linux-gnueabi-gcc: numpy/core/blasdot/_dotblas.c Sep 20 14:47:10 | In file included from /usr/include/features.h:376:0, Sep 20 14:47:10 | from /usr/include/limits.h:27, Sep 20 14:47:11 | from /workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6/Python.h:19, Sep 20 14:47:14 | from numpy/core/blasdot/_dotblas.c:4: Sep 20 14:47:16 | /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Sep 20 14:47:18 | compilation terminated. Sep 20 14:47:20 | In file included from /usr/include/features.h:376:0, Sep 20 14:47:22 | from /usr/include/limits.h:27, Sep 20 14:47:24 | from /workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/python2.6/Python.h:19, Sep 20 14:47:27 | from numpy/core/blasdot/_dotblas.c:4: Sep 20 14:47:29 | /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Sep 20 14:47:31 | compilation terminated. Sep 20 14:47:33 | error: Command "arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -isystem/workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb2 -isystem/workspace/usrp1-e-dev/oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/us Sep 20 14:47:40 r/include -fPIC -DNO_ATLAS_INFO=2 -Inumpy/core/blasdot -I/usr/include -Inumpy/core/include -Ibuild/src.linux-x86_64-2.6/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/workspace/usrp1-e-dev/oe/tmp/sysroots/arm-angstrom-linux-gnueabi/usr/include/python2.6 -I/workspace/usrp1-e-dev/oe/tmp/sysroots Sep 20 14:47:45 /armv7a-angstrom-linux-gnueabi/usr/include/python2.6 -Ibuild/src.linux-x86_64-2.6/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.6/numpy/core/src/umath -c numpy/core/blasdot/_dotblas.c -o build/temp.linux-x86_64-2.6/numpy/core/blasdot/_dotblas.o" failed with exit status 1 Sep 20 14:47:49 | FATAL: python setup.py build_ext execution Sep 20 14:47:51 crap Sep 20 14:47:53 http://pastebin.com/Epii2yuR Sep 20 14:47:55 is what I meant to say Sep 20 14:47:55 I've seen that with natives before, usually when you don't have the 32 bit headers installed on a 64 bit box... seems odd with arm Sep 20 14:56:45 /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Sep 20 14:56:50 sounds familiar Sep 20 14:57:27 Crofton|work: your cross compiler was informed to look in /usr/include? Sep 20 14:58:40 I do not think so Sep 20 14:58:50 this is the python-numpy recipe Sep 20 14:58:55 16:45 < Crofton|work> r/include -fPIC -DNO_ATLAS_INFO=2 -Inumpy/core/blasdot -I/usr/include -Inumpy/core/include Sep 20 14:59:08 -I/usr/include is visible Sep 20 14:59:32 but OE uses sysrooted gcc... Sep 20 15:00:22 yeah, confusing Sep 20 15:00:32 I fear I need to read the recipe Sep 20 15:00:43 he crofton Sep 20 15:00:51 fighting with numpy again Sep 20 15:01:16 ieehks -i/usr/include Sep 20 15:03:08 So, iirc Sep 20 15:03:17 sysroot doesn't mangle -I stuff Sep 20 15:04:48 only does it on one of two machines also Sep 20 15:06:57 fishy Sep 20 15:08:18 yeah Sep 20 15:08:20 bbiab Sep 20 15:43:09 Tartarus: i believe include paths starting w/ '=' will have that replaced w/ sysroot. Sep 20 16:02:32 Unhelpful, interesting.. Sep 20 16:33:10 is there an easy way to overwrite a configuration file from package A by the udpated configuration file from package B ? Sep 20 16:33:27 hm Sep 20 16:33:38 normaly you shouldnt do something like that Sep 20 16:34:07 example : ppp installs /etc/ppp/chap-secrets, but I want to have a myrtc-fai-pppconf, mygprs-fai-pppconf which will provide /etc/ppp/chap-secrets Sep 20 16:34:30 maybe we should always split conf files from packages, so that conf files get easy to override Sep 20 16:35:25 why would you do that, when the package manager already understands that conffiles are special? Sep 20 16:35:45 kergoth_: ok so I missed something Sep 20 16:36:25 CONFFILES_ informs the package manager of configuration files, so it knows not to overwrite the user's changes to them, they're not treated like other files owned by the package Sep 20 16:36:36 not sure how that would affect the behavior of a cross package overwrite, but keep tha tin mind Sep 20 16:36:45 interesting thanks Sep 20 16:37:35 other question : when using amend.inc, should'nt the package arch be MACHINE instead of the CPU arch ? Sep 20 16:37:46 why? Sep 20 16:37:53 using amend.inc doesn't mean its machine specific Sep 20 16:37:57 you can do anything in an amend.inc Sep 20 16:38:12 do you mean an amend.inc that resides inside a machine specific filespath? Sep 20 16:38:18 thats just one of many places you can put it Sep 20 16:38:21 if I have 3 overlay for 3 machines , each having a SRC_URI_append_machine Sep 20 16:38:21 but yes, that would be nice Sep 20 16:38:45 which provides a config file for example. Actually, each time I build, the armv5 package is overwrittent Sep 20 16:39:00 so I put PACKAGE_ARCH = "${MACHINE}" in amend.inc to prevent this Sep 20 16:39:10 yes, as expected Sep 20 16:39:28 the logic in base.bbclass which sets PACKAGE_ARCH automagically doesn't account for overrides, it *only* does it for you in the case wehre you use a file:// file that resides ina machine specific area of filespath Sep 20 16:39:32 everything else is always manual Sep 20 16:39:43 ok Sep 20 16:39:44 amend.inc isn't special, its just another way of setting variables, it doesn't imply machine specific Sep 20 16:39:58 what do you mean by "a machine specific area of filespath" ? Sep 20 16:40:04 FILEPATH_machine_name ? Sep 20 16:40:05 no Sep 20 16:40:12 recipes/foo/foo-1.0// Sep 20 16:40:16 intead of recipes/foo/foo-1.0/ Sep 20 16:40:18 ok thanks Sep 20 16:40:36 here is the trick I missed Sep 20 16:40:44 any override can be used there, filespath is assembled from 1) FILESPATHBASE, 2) FILESPATHPKG, 3) OVERRIDES, in that order Sep 20 16:42:22 ok, last thing : for amend.inc, can I have recipe/package/files/machinename/conffile and nothing in amend.inc if the recipe in OE's tree also have conffile ? Sep 20 16:43:28 in fact I added to my local.conf : INHERIT += "amend" and FILEPATHBASE =. "${BBFILE_PATTERN_mycollection}/:" Sep 20 16:43:34 maybe this is wrong Sep 20 16:46:15 that won't work Sep 20 16:46:23 that'll put the root of your collection into the filespath Sep 20 16:46:29 g'day kergoth Sep 20 16:46:32 not the recipe// dir relative to your collection Sep 20 16:47:18 you'll need a python snippet in filespathbase to add /recipes// for each collection Sep 20 16:47:23 kergoth_: ok so in fact for amend, it's better to create on directory which will contains all the amends ? Sep 20 16:47:27 see the mailing list archives, someone has done it on multiple occasions Sep 20 16:47:32 not sure what you mean Sep 20 16:47:44 supplying different config files using FILESPATH doesn't require amend.inc at all Sep 20 16:47:47 they're two independent things Sep 20 16:48:56 ok thanks for these informations, I better understand and will search again the lists archive for more details. Sep 20 16:49:12 np Sep 20 16:49:15 hey pb_ Sep 20 17:29:33 hi , i tried lsusb to find my huwaei e620 modem path but its just giving ID , no path like : "/dev/ttyUSB2" , how can i get full path of device ? or i need to mount it ? Sep 20 17:31:23 ok kergoth_ : FILESPATHBASE =. "${@ ':'.join([os.path.join(recipedir, os.path.basename(os.path.dirname( d.getVar('FILE', 1)))) for recipedir in d.getVar('COLLECTIONS', 1).split()])}:" seems to be the magic line Sep 20 17:32:25 now if I put initscripts/files/mymachine/alignement.sh I see bitbake initscript uses this file Sep 20 17:33:42 but it still builds a armv5 package, not a mymachine package : isn't files/mymachine the correct place to put the file ? or is it because initscripts is using an overide (_arm) to add this file to the package ? Sep 20 17:49:49 ericben: why dont you use BBLAYERS Sep 20 17:49:57 and BBAPPEND Sep 20 17:50:25 http://sakrah.dontexist.org/node/2 Sep 20 18:02:11 8 Sep 20 18:10:18 I'm trying to figure out the preferred version for a package included in my image, inside the image's recipe -- tried getEnv and that didn't work.. Anyone run into this? Reasoning is I want to tag the OS image not only with the svn of the OS build, but also tag it with the SVN rev of the 'most important package' I'm installing Sep 20 18:10:28 any help would be greatly appreciated Sep 20 18:13:31 loadammo: recipe specific metadata may not be available globally Sep 20 18:14:04 Hmm, noted. Sep 20 18:14:53 loadammo: although you could enquire metadata for the version Sep 20 18:15:09 in a python snippet and see if bitbake allows that Sep 20 18:15:16 ahh, good idea Sep 20 18:17:38 loadammo: PV/PR would have given you this info Sep 20 18:17:43 and they are recipe specific Sep 20 18:18:47 Yeah, I got that part sorted no problem.. I just want to make it part of the image recipe without using an intermediary temp file somewhere.. The image has to know what the preferred version is for do_rootfs, I imagine.. so I think it's 'in there'.. Just gotta find it. Sep 20 18:19:43 loadammo: no image knows there is only 1 version built Sep 20 18:19:56 parsing phase decides the preferred version Sep 20 18:20:04 I dont know if this info is available globally Sep 20 18:20:12 ok Sep 20 18:20:58 may be you can define a new global var Sep 20 18:21:04 for your purpose Sep 20 18:21:11 as the package is important to you Sep 20 18:21:28 then use metadata_scm.bbclass to extract the info Sep 20 18:21:45 and populate this var when this recipe is built Sep 20 18:22:11 Hmm.. Sep 20 19:00:35 khem: I've had some issues with the sdk's I compile. I talked to zecke about it, and I seem to recall him saying you were one of the guys he was going to seek advice with. Does that seem right? Warning: If so, I have a couple of questions :) Sep 20 19:01:00 tasslehoff: sure toss the questions Sep 20 19:03:26 khem: my sdk's have worked well in the past but after a fetch of upstream a month (or two) ago gcc won't launch. it complains about missing libmpfr.so.4, which is a library neither on my Ubuntu 10.04 host, nor in the SDK. It can only be found in my TMPDIR. Sep 20 19:03:45 tasslehoff: yes Sep 20 19:03:58 thats because we use latest version Sep 20 19:04:05 and most distros dont have it yet Sep 20 19:04:20 this so is expected to be on the host Sep 20 19:04:36 khem: does that mean that a compiled sdk cannot be used on most distros? or is there a way around it? Sep 20 19:04:41 tasslehoff: there arw two ways to solve it Sep 20 19:04:59 1. package the required .so with the SDK Sep 20 19:05:11 i.e. your host systroot Sep 20 19:05:30 2. link these into gcc statically Sep 20 19:05:34 3. downgrade Sep 20 19:05:47 I am in favor or 2 Sep 20 19:05:53 s/or/of Sep 20 19:06:04 but that needs some work in gcc Sep 20 19:06:17 easiest would be to downgrade Sep 20 19:06:30 modular would be to package them with SDK Sep 20 19:06:57 khem: hm. downgrade my entire OE you mean? Sep 20 19:07:02 no Sep 20 19:07:06 just mpfr Sep 20 19:07:15 see currently what happens Sep 20 19:07:35 you build the toolchain SDK on a given host and it builds against the libraries that are built by OE Sep 20 19:08:00 then you move the SDK to a different host and it starts to use the libraries provided by host Sep 20 19:08:04 thats wrong IMP Sep 20 19:08:06 IMO Sep 20 19:08:17 because you did not target the SDK for that given host Sep 20 19:08:44 if possible I would suggest that you package these libraries along with SDK Sep 20 19:09:07 khem: yeah. it was a mystery to me for a white that the sdk worked only on my computer. until I found out that the gcc had an rpath into the sysroot-directory of the tree where I built it. Sep 20 19:09:19 yes Sep 20 19:09:39 s/white/while :) Sep 20 19:10:07 we could link these libraries statically into gcc Sep 20 19:10:12 that will make it more portable Sep 20 19:10:17 but beef up gcc Sep 20 19:10:47 and packing them along with SDK is not a bad idea either Sep 20 19:10:48 khem: maybe a stupid Q, but why would it not be possible to package those libraries along with the SDK? do you mean a manual packing, or modifying the sdk-recipes to fix it? Sep 20 19:12:03 khem: I thought about just picking up one compile error at a time, and copy the needed library from sysroot into the lib-folder of my unpacked toolchain. Sep 20 19:12:33 yes that could be a way to find Sep 20 19:12:50 I think it was just 2 or 3 the last time I checked. Sep 20 19:13:14 tasslehoff: yes libelf, libmpfr libmpc libgmp Sep 20 19:13:21 these are 4 thats needed Sep 20 19:13:24 by gcc Sep 20 19:13:27 as of now Sep 20 19:13:34 there may be more that come in future who known Sep 20 19:15:02 The best answer is to make gcc link vs them statically Sep 20 19:15:22 Since shipping them means relocation gets much harder and you have to use chrpath and mangle them Sep 20 19:15:29 which isn't overly hard Sep 20 19:15:32 But is more work Sep 20 19:15:38 Tartarus: right Sep 20 19:15:42 I am all for it Sep 20 19:15:48 and statically linking them is easy Sep 20 19:15:51 I could propose a patch Sep 20 19:16:13 yes and it will speed up compilation a bit Sep 20 19:16:25 Er? Sep 20 19:16:30 Building and using our own static libs? Sep 20 19:16:42 yes if gcc links them statically Sep 20 19:16:55 the resulting gcc will compile stuff faster I meant Sep 20 19:17:14 that almost sounds like noise, heh Sep 20 19:18:31 khem: thanks for the answers. I'll do the ship-libs-with-sdk to begin with Sep 20 19:18:33 I doubt you could measure any performance boost from a static linked gcc versus a regular dynamic one. Sep 20 19:18:58 Static linking would be a win in some ways, a loss in others, but all the effects are going to be miniscule on a program like gcc. Sep 20 19:18:58 pb__: sure Sep 20 19:19:15 thats why I said a bit Sep 20 19:19:39 heh. well, you could equally well argue that it would make it "a bit" slower. :-} Sep 20 19:19:51 haha true Sep 20 19:20:08 It's also really easy to do, more importantly Sep 20 19:20:09 sec Sep 20 19:20:26 http://pastebin.com/PZjdk0Mw Sep 20 19:20:28 yeah, I certainly don't think it's a bad idea Sep 20 19:20:35 + having --enable-static in mpfr-native Sep 20 19:20:39 (and gmp-native) Sep 20 19:20:42 yeah Sep 20 19:20:47 so if we have agreement then we could work on linking gcc with mpfr and friends statically Sep 20 19:21:08 khem: sounds like you are too slow :-) Sep 20 19:21:35 Tartarus: looks like a decent plan. I can't think of any downside to doing that. Sep 20 19:21:43 Tartarus: do you need that Makefile hackery at all Sep 20 19:21:52 pb__: indeed Sep 20 19:21:56 khem, uyes Sep 20 19:21:57 yes Sep 20 19:21:58 iirc Sep 20 19:22:21 Tartarus: --with-mpfr-lib option and friends Sep 20 19:22:26 will be better IMP Sep 20 19:22:28 IMO Sep 20 19:22:35 Don't think it worked Sep 20 19:22:38 kergoth, recall? Sep 20 19:22:52 even when you gave it a/b/c/libmpfr.a ? Sep 20 19:23:10 * Tartarus checks Sep 20 19:24:29 khem, give that a whirl I guess :) Sep 20 19:24:45 I know the above works, but yes, it could be cleaner if --with-mpfr-lib works w/ a full path Sep 20 19:25:12 --disable-shared --enable-static Sep 20 19:25:21 to these libs will also do it Sep 20 19:25:54 That didn't Sep 20 19:26:07 That'd pick up shared from the host Sep 20 19:26:08 hmmm strange so it defaulted to one on the build box ? Sep 20 19:26:12 ok Sep 20 19:26:21 so its hell bent on getting shared Sep 20 19:26:25 yes Sep 20 19:26:41 Don't recall for certain if we tried --with-mpfr-lib=a/b/c/libmpfr.a Sep 20 19:26:50 But I know we tried just doing static only of our libs Sep 20 19:26:52 and it went host Sep 20 19:26:56 Tartarus: but if I put these libraries in gcc src dir then it links them in statically Sep 20 19:27:08 Yes, we also tried that pat Sep 20 19:27:09 hh Sep 20 19:27:14 But it wasn't as clean to implement Sep 20 19:27:39 ends up being a pain to patch the gmp/mpfr/etc sources like we do for -native Sep 20 19:28:30 I kind of see why dynamic is default Sep 20 19:28:45 it's not 1996 anymore, yes ;) Sep 20 19:28:46 a bug fix in mpfr would otherwise trigger gcc update too Sep 20 19:30:15 Tartarus: build/install gmp/mpfr yourself and specify --disable-shared to Sep 20 19:30:16 both. Then use --with-mpfr= to specify using them instead of the system's Sep 20 19:30:16 shared versions. Sep 20 19:30:20 should work Sep 20 19:30:41 lemme try that out Sep 20 19:31:24 I think we just added static libs to mpfr/etc just ot be safe in case of other users Sep 20 19:32:08 Tartarus: other host packages you mean ? Sep 20 19:32:28 we dont loose much if they link with static versions do we ? Sep 20 19:33:13 They'd be in the picking up host shared lib Sep 20 19:33:16 WHich isn't desirable Sep 20 19:34:17 hmm Sep 20 19:41:08 Tartarus: all in all that patch of yours look on Sep 20 19:41:12 ok Sep 20 19:41:34 Tartarus: you may only need to patch Makefile.tpl Sep 20 19:41:41 as Makefile.in is generated from that Sep 20 19:56:40 hi khem, yes I found this blog page about bblayes & bbappend through google this afternoon, are you the author ? Sep 20 19:56:48 khem: Yeah Sep 20 19:56:56 We hit 'em both since other Makefile mangling hit them both Sep 20 19:57:33 ericben: yes Sep 20 19:57:50 Tartarus: I am testing your patch with other bits around it Sep 20 19:58:25 khem: is the bblayer concept applicable to overlay I already have ? Sep 20 19:58:41 ericben: should be Sep 20 19:58:49 ericben: use bitbake master though Sep 20 19:58:50 seems the answer is yes from what I understand on your page Sep 20 19:58:55 I am not sure older bitbake will work Sep 20 19:58:57 ok, I'll try Sep 20 20:00:21 I still don''t understand everything on how the packages get built for PACKAGE_ARCH=MACHINE or for generic arch Sep 20 20:07:57 guys, i've stumbled upon something weird Sep 20 20:08:39 gcc-cross-4.4.3-r0.1/gcc-4.4.3/libjava/classpath/configure always sets a GMP_CFLAGS=-I/usr/include after configure task Sep 20 20:08:46 even though i've fixed it in the configure.ac Sep 20 20:09:11 i have no idea where it takes that from and of course it leads to a "cross compile badness" error in compile task Sep 20 20:09:34 has anybody noticed that already? Sep 20 20:09:46 fraxinath: hmmm are you on latest master Sep 20 20:10:08 no using dreambox-1.6 fork Sep 20 20:10:12 opendreambox Sep 20 20:10:27 there are fixes in upstream OE Sep 20 20:10:37 for that very issue? Sep 20 20:11:48 uhm... master doesn't have 4.4.3 anymore at all ?? Sep 20 20:12:53 fraxinath: its 4.4.4 Sep 20 20:12:59 you could use it Sep 20 20:13:52 ooooh not sure what all that would break though Sep 20 20:14:25 is there a particular reason why the 4.4.3 recipe was taken out of the repo all the way Sep 20 20:14:26 ? Sep 20 20:14:43 it was moved to 4.4.4 Sep 20 20:15:06 4.4.4 is bugfix release which will have all 4.4.3+new bug fixes Sep 20 20:15:24 ah okay only bugfixes, that sounds good Sep 20 20:32:40 kergoth_: earlier, you explained me the logic of PACKAGe_ARCH which is automagically set to MACHINE in case we use a file:// which is in a machine specific are of filespath. I'm trying this with initscripts-1.0/mymachine and I always get a armv5te package for initscripts. I've tested to add the filees to the overlay (with correct FILESPATH) or directly in OE's tree and I always get the same result : the file is included in the package, but Sep 20 20:38:23 ericben: is this recipe machine speicific Sep 20 20:39:39 khem: from what I understood, as soon as it gets a file:// in initscripts-1.0/machine/ directory the package becomes machine specific Sep 20 20:39:47 hmmm Sep 20 20:40:15 seems Cisco is hiring embedded developers.. Sep 20 20:40:28 PACKAGE_ARCH=${MACHINE_ARCH} Sep 20 20:40:31 you need that Sep 20 20:40:36 Jay7: yes indeed they are Sep 20 20:40:49 Jay7: and Cisco uses OE too Sep 20 20:41:33 ericben: I dont think that it will turn the recipe into machine specific recipe automatically Sep 20 20:41:34 I've received proposal.. Sep 20 20:41:57 Jay7: r u interested ? Sep 20 20:42:00 Sr.Software Engineer Sep 20 20:42:21 I don't like idea of relocation into USA.. Sep 20 20:42:31 I dont think they care Sep 20 20:42:37 I like Europe :) Sep 20 20:42:38 you can work whereever you are Sep 20 20:43:09 I'll ask about this Sep 20 20:43:31 khem: in base.bbclass, it tests for is_machine_specific, which is in utils.bbclass and tests if SRC_URI contains machinepath Sep 20 20:44:11 hmm Sep 20 20:44:16 ericben: ok I see Sep 20 20:48:55 03Eric Bénard  07org.openembedded.dev * r907d0ce00d 10openembedded.git/recipes/python/python.inc: Sep 20 20:48:55 python: increase PR Sep 20 20:48:55 Signed-off-by: Eric Bénard Sep 20 20:48:55 03Eric Bénard  07org.openembedded.dev * rbe576ab8af 10openembedded.git/recipes/python/python-2.6-manifest.inc: Sep 20 20:48:55 python-2.6-manifest.inc: regenerate the file Sep 20 20:48:55 the patch is quite large because packages seems to have been reordered Sep 20 20:48:56 in the generator but excepting python-dev everything is still present. Sep 20 20:48:56 Signed-off-by: Eric Bénard Sep 20 20:48:57 Acked-by: Frans Meulenbroeks Sep 20 20:48:57 03Eric Bénard  07org.openembedded.dev * r22c71d47e4 10openembedded.git/recipes/python/python_2.6.5.bb: Sep 20 20:48:58 python_2.6.5: tune python-distutils Sep 20 20:48:58 removing config/libpython2.6.a and distutils/command/win* Sep 20 20:48:59 as suggested by cdricjulien. Sep 20 20:49:00 Signed-off-by: Eric Bénard Sep 20 20:49:00 Acked-by: Frans Meulenbroeks Sep 20 20:49:01 03Eric Bénard  07org.openembedded.dev * re239d07dfc 10openembedded.git/contrib/python/generate-manifest-2.6.py: Sep 20 20:55:01 ericben: hmmm so you are having trouble when using bblayer or in general Sep 20 20:56:24 actually I'm not using bblayer (not yet). I have a machine overly and used FILESPATHBASE to add files into it (after reading explanations from kergoth_ ) Sep 20 20:56:37 this seems to work as my file is used to build initscripts Sep 20 20:57:23 but initscripts's ipk is always armv5te and not machine specific (which is what seems to be the case on angstrom : http://www.angstrom-distribution.org/repo/?pkgname=initscripts Sep 20 20:58:09 so as I was not sure of FILESPATHBASE change, I removed it and put my file in oe's tree in recipes/initscripts/initscripts-1.0/mymachine/ Sep 20 20:58:15 and the package is still armv5 Sep 20 20:59:34 which means if I build 3 different armv5 machines in the same tree, the initscript package will always be the one of the last machine (and be in deploy/glibc/ipk/armv5te instead of deploy/glibc/ipk/mymachine) Sep 20 21:00:23 I'm trying a fresh build to see if that works or if this is because on my overlay or my machine orr something else in my current working tree Sep 20 21:01:10 ericben: it works ok for me to have machine specific recipes e.g. uclibc Sep 20 21:01:14 or sysvinit Sep 20 21:01:16 works ok here Sep 20 21:02:10 here also ok for sysvinit-inittab, but not for initscripts ! Sep 20 21:02:54 well sysvinit-inittab is set as MACHINE_ARCH in the recipe so this is expected Sep 20 21:30:46 hi there - anyone to review patches http://patchwork.openembedded.org/patch/2959/ to 2961 ? Sep 20 21:32:43 I have listed my gnugo patch as defered, there is an issue when cross-compiling from 64bit to 32 and vice versa Sep 20 21:32:55 (discussing a fix with upstream) Sep 20 21:33:09 yann: yes I have Sep 20 21:43:23 khem: any comment ? Sep 20 21:43:56 yann: looks ok to me thougj Sep 20 21:44:07 yann: what DISTRO did you try it on Sep 20 21:48:08 shr-testing Sep 20 22:00:30 yann: could you try it with angstrom Sep 20 22:00:38 and see if the sizes are fixed Sep 20 22:00:42 for git-native Sep 20 22:11:48 khem: gcc-cross_4.4.4 doesn't configure Sep 20 22:12:15 aclocal: /dream/oe1.6/dm8000/build/tmp/work/mipsel-oe-linux/gcc-cross-4.4.4-r6.0/gcc-4.4.4/libstdc++-v3/acinclude.m4:2989: file `../config/tls.m4' does not exist Sep 20 22:13:25 fraxinath: did u build from scratch Sep 20 22:13:45 i built that package Sep 20 22:14:50 do i first need gcc-cross-initial and intermediate? Sep 20 22:14:57 yes Sep 20 22:15:00 aye Sep 20 22:15:02 you need to do it Sep 20 22:15:03 i'll try Sep 20 22:15:30 bitbake -c clean gcc-cross gcc-cross-intermediate gcc-cross-initial glibc glibc-initial Sep 20 22:15:39 then bitbake gcc-cross Sep 20 22:15:58 assuming you have gcc-4.4.4 as your default gcc-cross provider Sep 20 22:16:21 i think 4.4.3 is preferred by something else right now Sep 20 22:16:59 if i just do bitbake gcc-cross-initial then it will try building 4.4.3 again Sep 20 22:17:33 oh i almost forgot that glibc also depends on it Sep 20 22:17:39 that'll take all night :) Sep 20 22:18:34 depending upong your machine Sep 20 22:18:50 some folks build whole OE distro under 2 hrs here Sep 20 22:19:23 conf/distro/opendreambox.conf:PREFERRED_GCC_VERSION ?= "4.4.3" Sep 20 22:19:43 add PREFERRED_GCC_VERSION_local = "4.4.4" in your local.conf Sep 20 22:20:11 i'll try changing it in there for right now Sep 20 22:20:14 AMD Phenom(tm) 9550 Quad-Core Processor Sep 20 22:20:20 with 8 gb ram Sep 20 22:20:27 but it's slow as all hell when it comes to bitbake Sep 20 22:20:45 fraxinath: your machine is decent Sep 20 22:22:31 we had improvements after the cleaning storm... Sep 20 22:22:43 shame tinderbox is broken Sep 20 22:23:07 iirc console-image in 50 mins from scratch (xeon quad + 8GB) Sep 20 22:23:30 old hw nowaday Sep 20 22:23:58 Hmm Sep 20 22:24:00 ImportError: Could not import settings 'tinderbox.settings' (Is it on sys.path? Does it have syntax errors?): No module named oestats.settings Sep 20 22:24:12 I do console-image in about 20 mins here, 16 cores, 16gb ram Sep 20 22:24:23 poser :) Sep 20 22:24:26 shared with a bunch of folks tho Sep 20 22:24:41 okay building 4.4.4 now khem! thanks for the clues Sep 20 22:24:57 <3 OE Sep 20 22:25:40 loadammo: cool Sep 20 22:25:41 lol same configure error Sep 20 22:26:33 Heh, OE is actually the only thing that puts 'real' load on this build machine. Everyone else barely even bothers to use -j Sep 20 22:26:38 khem: found the bug which prevent initscript to automagicaly be in machine_arch instead of generic arch Sep 20 22:26:51 ericben: cool what is it Sep 20 22:26:55 I'll send a patch to the ml for review Sep 20 22:27:28 urldata.path is used instead of urldata.localpath in is_machine_specific Sep 20 22:28:21 ugh thats obvious problem Sep 20 22:28:22 :) Sep 20 22:28:23 and urldata.path does'nt contains the full path, so when compared to the expected path to machine filepathpkg it fails Sep 20 22:28:37 yes this is due to recent fix in bb Sep 20 22:28:44 4 hours to understand this proble :) Sep 20 22:28:45 btw what version of bb are u using Sep 20 22:28:50 bb : head Sep 20 22:28:53 ok Sep 20 22:29:02 also try this with 1.8 if you could Sep 20 22:29:06 I guess it will break Sep 20 22:29:24 khem any idea about aclocal: /dream/oe1.6/dm8000/build/tmp/work/mipsel-oe-linux/gcc-cross-4.4.4-r6.0/gcc-4.4.4/libstdc++-v3/acinclude.m4:2989: file `../config/tls.m4' does not exist ? Sep 20 22:29:43 in fact, the problem seem to be introduced by commit : 2b7ea6f52dfa7c6cdbbb426e13efba1b4914e7b9 (I'm not 100% sure but this is where this function was introduced) Sep 20 22:30:05 trying 1.8.18 Sep 20 22:30:05 khem: about this arches, no way to unbind klibc from machine? Sep 20 22:30:35 ericben: it was the semantic of urldata Sep 20 22:30:56 fraxinath: I havent seen this error before Sep 20 22:31:14 me neither Sep 20 22:31:36 fraxinath: are you seeing it on master Sep 20 22:31:47 or did you do selective port into dreambox Sep 20 22:31:48 branch Sep 20 22:32:08 if you are doing selective backport Sep 20 22:32:13 take complete gcc dire Sep 20 22:32:13 i checked out the whole 4.4.4 stuff into our repo Sep 20 22:32:38 khem: seems to work also with 1.8.18 Sep 20 22:32:45 ericben: perfect Sep 20 22:32:56 i'll try it with entire gcc dir Sep 20 22:32:58 ant_: which arch Sep 20 22:33:07 cleaning the mess I put in class/ to understand it and preparing a patch Sep 20 22:33:24 I wish I had a crystal ball Sep 20 22:33:33 and the hardest thing in the patch : the commit message :) Sep 20 22:34:26 ou yeah Sep 20 22:40:37 ericben: -m "Fix broken recipe" Sep 20 22:40:43 and I will reject it Sep 20 22:41:20 :) Sep 20 22:42:06 testing with the overlay and FILEPATHBASE Sep 20 22:43:30 ericben: ok Sep 20 22:45:15 for tindderboox, if there is interest, I can provide one on one of our servers, I've one private oestat already setup, duplicating it is a matter of minutes Sep 20 22:45:36 ericben: sure Sep 20 22:45:54 khem: i.e. other *libc are armv5te but klibc is c7x0 Sep 20 22:46:01 ericben: if you can help fixing tinderbox.openemebedded.org that will be nice too Sep 20 22:46:16 ant_: same issue with uclibc Sep 20 22:46:20 khem: so is klcc-cross (but the empty package is not created) Sep 20 22:46:52 is any of you guys gonna be at CELF in cambridge next month? Sep 20 22:46:57 khem: if you want, we can try to setup it from sscratch Sep 20 22:47:16 ericben: hmm will be loose the logs Sep 20 22:47:55 no I think we can restore logs after, they are stored in a separated irectory Sep 20 22:48:16 khem: gcc-cross-initial_4.4.4 configures successfully when i overwrite the entire gcc directory from master Sep 20 22:48:32 yes, rename tmp and reate an empty one Sep 20 22:48:50 the major diference is that oe's tinderbox is using mysql and I'm using sqlite here Sep 20 22:49:12 fwiw oe tinderbox is having hard times... Sep 20 22:49:22 ericben: ok Sep 20 22:49:35 MOD_PYTHON ERROR Sep 20 22:49:37 heh Sep 20 22:49:39 ericben: lets try it with sqlite Sep 20 22:49:44 ok that works also in the overlay Sep 20 22:50:00 khew, I can send you the doc I wrote for my setup Sep 20 22:50:32 ericben: ok Sep 20 22:50:44 and also how can we restore the logs Sep 20 22:50:47 i'll let that continue baking and hope for the best for tomorrow morning :) thanks again and cu Sep 20 22:50:49 bugzilla is also boked Sep 20 22:50:59 fraxinath: bye Sep 20 22:51:14 sqlite will be the 1st step Sep 20 22:51:32 after you need to switch back to mysql to restore everything Sep 20 22:52:06 ericben: is sqlite better performant Sep 20 22:52:51 well, cgit.openembedded.org is working, tinderbox not. both on 140.211.169.165 Sep 20 22:53:14 seems just a missing config file Sep 20 22:53:32 ant_: what do you mean by missing file Sep 20 22:53:35 http://tinderbox.openembedded.net/ Sep 20 22:53:42 see here, last line Sep 20 22:53:42 its a different set of beast Sep 20 22:54:26 it the server apache or lighttpd ? Sep 20 22:54:32 apache Sep 20 22:55:36 do you have the apach conf for tinderbox.oe.org ? Sep 20 22:55:42 yes Sep 20 22:55:46 is PythonPath properly setup insode ? Sep 20 22:55:58 and DJANGO_SETTINGS_MODULE ? Sep 20 22:57:22 SetEnv DJANGO_SETTINGS_MODULE tinderbox.settings Sep 20 22:57:31 PythonPath "['/etc/django-oestats'] + sys.path" Sep 20 22:57:43 ls /etc/django-oestats ? Sep 20 23:00:09 settings.py is in there Sep 20 23:00:13 /etc/django-oestats/tinderbox/ Sep 20 23:01:07 from oestats.settings import * Sep 20 23:01:16 thats where it chickens out Sep 20 23:03:59 ok ls /usr/lib/pymodules/python2.6/oestats ? Sep 20 23:04:13 robots.txt Sep 20 23:04:24 only that ? Sep 20 23:04:28 yes Sep 20 23:04:29 :) Sep 20 23:04:37 ok python was updated no ? Sep 20 23:04:42 ok ls /usr/lib/pymodules/python2.5/oestats ? Sep 20 23:04:43 it was Sep 20 23:05:06 no 2.5 Sep 20 23:05:27 search for oestats in /usr/lib Sep 20 23:06:06 /usr/lib/pymodules/python2.6/oestats Sep 20 23:06:08 thats it Sep 20 23:06:26 and it's empty ? Sep 20 23:06:34 yes Sep 20 23:06:48 ok Sep 20 23:07:04 backup /etc/django-oestats Sep 20 23:07:46 then follow the instructions here to build the .deb http://opensource.bolloretelecom.eu/projects/django-oestats/ @ Running a production server Sep 20 23:07:49 then install it Sep 20 23:08:00 then recover backup of settings.py Sep 20 23:08:26 in ls /usr/lib/pymodules/python2.6/oestats Sep 20 23:08:26 admin.py __init__.py models.py settings.pyc templatetags views.pyc Sep 20 23:08:26 admin.pyc __init__.pyc models.pyc shortcuts.py urls.py Sep 20 23:08:26 forms.py middleware.py public shortcuts.pyc urls.pyc Sep 20 23:08:28 forms.pyc middleware.pyc settings.py templates views.py Sep 20 23:08:34 this is what you should have after that Sep 20 23:19:25 ericben: PythonHandler django.core.handlers.modpython Sep 20 23:19:30 is erroring out Sep 20 23:19:40 Invalid command 'PythonHandler', perhaps misspelled or defined by a module not included in the server configuration Sep 20 23:20:39 is django installed from scratch or from debian's package ? Sep 20 23:22:19 if not installed : http://docs.djangoproject.com/en/dev/topics/install/#installing-official-release Sep 20 23:23:16 whaht says django-admin --version Sep 20 23:23:20 ericben: ok installed from .dev Sep 20 23:23:23 .deb Sep 20 23:23:35 1.1.1 Sep 20 23:23:45 ok so we are not far Sep 20 23:23:56 is apache started ? Sep 20 23:24:17 nope Sep 20 23:24:29 same error Sep 20 23:24:47 I don't see anything on http://tinderbox.openembedded.net/ Sep 20 23:25:44 I built a deb of django-oestats Sep 20 23:25:55 I built a deb of django-oestats Sep 20 23:26:01 django-oestats Sep 20 23:26:06 you installed it ? Sep 20 23:26:09 yes Sep 20 23:26:16 ls /usr/lib/pymodules/python2.6/oestat show the files ? Sep 20 23:26:46 yes its populated Sep 20 23:26:46 ok Sep 20 23:27:08 did you restor /etc/django-oestats/tinderbox/settings.py ? Sep 20 23:27:31 actually nothing happened to it Sep 20 23:27:38 I made a copy though Sep 20 23:27:48 before installing django-oestats Sep 20 23:28:04 can you send it to mr or pastebin it ? Sep 20 23:29:33 http://pastebin.com/v0kM3RNy Sep 20 23:32:04 ok the only difference I have here is in TEMMPLATe_DIRS : /usr/share/pyshared/oestats/templates/ Sep 20 23:32:43 ericben: why would apache fail Sep 20 23:33:49 libapache2-mod-python is installed ? Sep 20 23:34:56 and what says the log of apache ? Sep 20 23:35:21 yes I installed it again Sep 20 23:35:40 at the top of settings.py, after import * I have : FORCE_SCRIPT_NAME="" Sep 20 23:35:51 not sure this is needed for apache, but it was for lighttpd Sep 20 23:36:31 you will need to change the myql password now it's on pastebin ;-) Sep 20 23:37:33 can you send me the config file of apache ? Sep 20 23:37:42 email Sep 20 23:37:48 yes Sep 21 00:12:01 tinderbox back, slow but online ... Sep 21 00:16:56 great, thx guys Sep 21 00:18:12 well, yes, console image tool Sep 21 00:18:53 he..two good hours, not 50 mins! Sep 21 02:14:33 hi , is there any library that plays 720p video utilizing both dsp + neon that is free and plays on framebuffer ? ffmpeg sucks and cant play 720p videos with sound. Sep 21 02:44:24 sorry Sep 21 02:46:39 JDuke128, ffmpeg is probably your best bet. I'd suggest poking it and see if their devs are receptive (i suspect they are). **** ENDING LOGGING AT Tue Sep 21 02:59:57 2010