**** BEGIN LOGGING AT Thu Apr 29 02:59:56 2010 Apr 29 06:16:56 03sledz  07org.openembedded.dev * r99b9d61487 10openembedded.git/recipes/sysvinit/sysvinit/hipox/rcS-default: Apr 29 06:16:56 sysvinit: we don't like volatile cache at hipox machine Apr 29 06:16:56 Signed-off-by: Steffen Sledz Apr 29 07:14:26 morning Apr 29 07:14:39 hrw: morning Apr 29 07:14:45 hi JaMa Apr 29 07:16:43 hrw: with http://gitorious.org/~jama/angstrom/jama-shr-experimental/commit/b5c28a47cbbfcb35b2fafb389d739391b1e04566 and 3 parent commits I'm trying to use xserver-common in SHR, for some reason /etc/X11/Xinit.d/89xTs_Calibrate is not executed while starting xserver-nodm, do you have any idea? Apr 29 07:17:29 strace shows that whole Xinit.d is ignored (as sort of expected 'xinit /etc/X11/Xsession') but with -kdrive-common it was executed Apr 29 07:18:47 I do not remember details of it - did hack and then I just used it Apr 29 07:20:12 ok, I'll investigate more Apr 29 11:08:04 morning all Apr 29 11:08:17 pb_: any chance of a jabber address? Apr 29 11:11:01 RP: yeah, I need to set one up. the meeting isn't until next week, right? Apr 29 11:11:09 or am I confused and it is actually this afternoon? Apr 29 11:11:39 pb_: no, its next week but I need to ensure you and zecke can access the meeting room Apr 29 11:12:20 pb_: I'm trying to get this sorted before XorA goes away Apr 29 11:12:38 ah, fair enough. I hadn't realised it was that urgent. I'll try to do that today then. Apr 29 11:12:43 any suggestions for a good jabber host to use? Apr 29 11:13:02 pb_: I ended up with a gmail account :/ Apr 29 11:13:55 pb_: xmpp.org/services ? Apr 29 11:15:03 RP: ah, my fault, I got the wrong thursday Apr 29 11:15:07 Looks like jabber.org stopped creating accounts in Jan 2009 Apr 29 11:15:16 RP: I meant Ill be around until about 5pm before the meeting :-) Apr 29 11:15:26 google mail is a valid jabber account Apr 29 11:15:47 XorA: ah, we had a slightly different interpretation of those timings then... Apr 29 11:15:51 okay, cool. I think I have a couple of google accounts, I will try to exhume their details and I can use one of them. Apr 29 11:16:01 RP: I had in my head meeting was this week Apr 29 11:16:11 RP: Im dumb sometimes :-) Apr 29 11:16:12 pb_: If you already have one of them it would make sense to use that Apr 29 11:17:46 03Martin Jansa  07org.openembedded.dev * r4026dde0da 10openembedded.git/recipes/tasks/task-shr-feed.bb: Apr 29 11:17:47 task-shr-feed: add spojegui app Apr 29 11:17:47 Signed-off-by: Martin Jansa Apr 29 11:17:48 03Martin Jansa  07org.openembedded.dev * r796a08fbf4 10openembedded.git/recipes/dillo/dillo2_2.1.1.bb: Apr 29 11:17:48 dillo2: enable experimental ssl Apr 29 11:17:48 Signed-off-by: Martin Jansa Apr 29 11:17:49 03Martin Jansa  07org.openembedded.dev * r92227b57ee 10openembedded.git/recipes/openmoko-3rdparty/spojegui_svn.bb: Apr 29 11:17:49 spojegui: add recipe for app searching public transport connections in Czech Republic. Apr 29 11:17:49 Signed-off-by: Martin Jansa Apr 29 11:19:18 ah, hm, I don't seem to have gmail enabled on any of my google accounts. let me create a new one then. Apr 29 11:19:31 pb_: Can you not enable it somehow? Apr 29 11:22:56 ok. philb.tsc@googlemail.com Apr 29 11:24:47 pb_: thanks Apr 29 11:26:58 someone using gcc-4.5.0 with armv4t? Apr 29 11:28:49 JaMa: Angstrom is, but I dont know state of compile Apr 29 11:29:42 XorA: seen your commit in angstrom-next, but after todays rebuild from scratch resulting image is a bit creepy http://paste.pocoo.org/show/207479/ Apr 29 11:30:21 JaMa: thats why we did it in -next, at moment I cant get u-boot to boot kernel on my dev platform :-( Apr 29 11:31:19 I'm building gpe image for my spitz to see if the problem is related only to armv4 or it's the same with armv5 Apr 29 11:32:35 03Koen Kooi  07org.openembedded.dev * r08f6c724a0 10openembedded.git/recipes/mythtv/mythtv_0.22+fixes.bb: mythtv 0.22+fixes: bump SRCREV to head of .22 fixes branch Apr 29 11:33:15 and this breakage is tested only from on chroot from old image.. I'll try to reboot later from home.. it it can change something.. Apr 29 11:34:53 I get compile errors on expat: http://pastebin.org/191893. Anyone else haveing this issue? Apr 29 11:47:29 03Thomas Zimmermann  07org.openembedded.dev * r1bce226d2d 10openembedded.git/recipes/pjproject/ (pjproject-1.0_1.0.3.bb pjproject_1.5.5.bb): Apr 29 11:47:29 pjproject: add version 1.5.5 Apr 29 11:47:29 Signed-off-by: Thomas Zimmermann Apr 29 11:51:28 03Thomas Zimmermann  07org.openembedded.dev * r44b961e5b6 10openembedded.git/recipes/dbus/ (dbus-c++-native_svn.bb dbus-c++_svn.bb): Apr 29 11:51:28 dbus-c++: dev.openwengo.org is gone Apr 29 11:51:28 * add patch as anounced on ML 10 days ago Apr 29 11:51:28 * switch host to new git repo Apr 29 11:51:28 * define correct verion Apr 29 11:51:29 * bump PE because no PV was defined before Apr 29 11:51:29 Signed-off-by: Thomas Zimmermann Apr 29 11:57:39 03Martin Jansa  07org.openembedded.dev * r4b5faf3bc7 10openembedded.git/conf/checksums.ini: Apr 29 11:57:40 checksums.ini: remove all entries, all were moved to recipes Apr 29 11:57:40 * if corresponding recipe still existed Apr 29 11:57:40 * don't add new entries, use in-recipe checksums instead Apr 29 11:57:40 Signed-off-by: Martin Jansa Apr 29 12:40:01 Anyone else having crc-problems with expat 2.0.1 with latest org.openembedded.dev? When I manually run sha256sum and md5sum on the downloaded tar.gz they match the ones in the recipe, but the unpack fails. Apr 29 12:46:47 tasslehoff: I've had similar problems with udev Apr 29 12:47:36 with stable/2009 though Apr 29 12:49:30 akheron: have you found a way around it? Apr 29 12:50:28 03Steve Sakoman  07org.openembedded.dev * re65d011707 10openembedded.git/recipes/overo-scripts/ (files/writeprom.sh overo-writeprom.bb): overo-writeprom: add utility to write expansion board config eeproms Apr 29 12:50:31 03Koen Kooi  07org.openembedded.dev * r58fa34bf8a 10openembedded.git/recipes/ (3 files in 3 dirs): overo-writeprom: rename to omap3-writeprom and make it work on both overo and beagleboard Apr 29 12:56:45 tasslehoff: no Apr 29 12:56:51 well, yes Apr 29 12:57:13 disabling my own premirror and allowing it to download from upstream helped Apr 29 12:57:31 but that doesn't tell why the file passes the checksum checks but is still corrupted Apr 29 12:57:40 s/tell/explain/ Apr 29 13:07:22 akheron: in my case I think it's the checksum that fails. it says "gzip: expat-2.0.1.tar.gz: invalid compressed data--crc error" Apr 29 13:08:39 akheron: forget that last sentence :) Apr 29 13:16:10 jo gnutoo Apr 29 13:17:03 tasslehoff :) Apr 29 13:17:16 woglinde, hi Apr 29 13:18:23 hi woglinde,you are also in #navit? I've this bug: https://bugzilla.redhat.com/show_bug.cgi?id=506840 Apr 29 13:18:44 what should I bump if I fix it? Apr 29 13:18:54 only freetype is ok? Apr 29 13:19:01 its a duplicate by the way Apr 29 13:19:06 yes I know Apr 29 13:19:31 bestway is to update to freetype 2.3.11 Apr 29 13:19:42 dont know why nobody bumped it on oe Apr 29 13:19:58 same problem occurs on maemo5 Apr 29 13:20:23 ah ok thanks a lot Apr 29 13:20:58 but maemo is tricky because you must be compatible with old libs no? Apr 29 13:21:18 yes Apr 29 13:21:24 ok Apr 29 13:21:28 but dont have time for maemo yet Apr 29 13:21:49 btw am I the only one using illume-image, can I remove the alarm that depends on waker_svn that is unbuildable? Apr 29 13:22:00 I already asked in the list long time ago Apr 29 13:22:04 I was told to fix it Apr 29 13:22:12 and not to remove it Apr 29 13:28:23 Hmm. I only get crc-errors from gunzip on Ubuntu 10.04 RC. On 9.10 expat unpacks fine with the same version of gunzip. Apr 29 13:49:00 GNUtoo: lets remove waker Apr 29 13:49:09 noone is using it Apr 29 13:49:19 ok thanks a lot Apr 29 13:49:32 np Apr 29 13:49:50 all the swisscom stuff is in limbo atm. Apr 29 13:49:52 hi mickeyl Apr 29 13:49:55 or rather abandoned Apr 29 13:49:57 hi woglinde Apr 29 13:49:59 ok Apr 29 13:50:27 when Openmoko dropped the ball, all their budget for openmoko stuff was frozen Apr 29 13:50:32 then later reassigned Apr 29 13:50:55 ok Apr 29 14:18:25 03Michael 'Mickey' Lauer  07org.openembedded.dev * r4275a8734f 10openembedded.git/recipes/dbus/dbus-daemon-proxy_git.bb: dbus-daemon-proxy: new recipe; dbus-forwarder Apr 29 14:18:27 03Michael 'Mickey' Lauer  07org.openembedded.dev * rb3b29999cd 10openembedded.git/recipes/tasks/task-cli-tools.bb: task-cli-tools: add dbus-daemon-proxy Apr 29 14:59:23 mickey|zzZzz: is waker swisscom stuff? i think it's part of raster's elementary-alarm Apr 29 15:00:25 hmm /usr/lib/libstdc++.so.6.0.14-gdb.py is part of Package libstdc++6 (4.5.0-r0.4) and ldconfig is not happy "/sbin/ldconfig: /usr/lib/libstdc++.so.6.0.14-gdb.py is not an ELF file" Apr 29 15:15:53 hi all - i'm doing a trivial little package - libjsw - but it is getting packaged as libjsw1.5.8, rather than libjsw_1.5.8 - P, PN, PV - all correct. must be something simple - ideas? Apr 29 15:16:15 is it because it's a lib* ?? Apr 29 15:17:02 hi has anybody problems building gtk-webcore/osb-nrcit_svn ? Apr 29 15:17:06 got a webi.cc:737: error: 'GTK_WIDGET_VISIBLE' was not declared in this scope Apr 29 15:17:13 while compiling Apr 29 15:23:54 dos1: all that stuff has been sponsored by swisscom. elementary is the only thing though that raster keeps alive Apr 29 15:23:59 as they found new sponsors Apr 29 15:29:49 HopsNBarley, yes it's because it's a lib Apr 29 15:30:48 dos1, indeed and it doesn't compile Apr 29 15:31:48 03Denys Dmytriyenko  07org.openembedded.dev * r62d4a145ff 10openembedded.git/recipes/powervr-drivers/libgles-omap3.inc: libgles-omap3: add dm3730-am3715-evm to the list of supported machines Apr 29 15:44:58 gm Apr 29 15:48:01 hrm Apr 29 15:48:41 if i only look for d.getVar() and bb.data.getVar() that pass a string literal, this shouldn't be too painful.. if I try to track assignments to allow handling of passing of variables instead, then my head will explode Apr 29 15:48:52 particularly since I don't know much about how python handles its contexts.. Load()/Store() Apr 29 16:32:15 kergoth: Can we error if its not a string? :) Apr 29 16:32:30 or somehow warn about it. It can't be that common we do that Apr 29 16:32:36 yeah, thats what i was leaning toward too Apr 29 16:32:41 of course there are expand calls too Apr 29 16:32:42 probably just not good to be doing that Apr 29 16:32:52 i can see using vars for the value of a setvar, but not for the name of the var to a getVar Apr 29 16:32:57 true Apr 29 16:33:40 hmm Apr 29 16:33:43 I can think of some python functions that do it but not ones that matter much in this context Apr 29 16:33:53 most could probably be adjusted Apr 29 16:37:31 course, there could be 'from bb import data; data.getVar()' too, i'm not sure if those are worth trying to deal with Apr 29 16:37:43 might not be to terrible to support, would have to visit the import Apr 29 16:38:23 hi, how much someone should test before pushing someone else's recipe? runtime test is ok? Apr 29 16:39:08 GNUtoo idealy testing on 2 diffrent hw-platforms Apr 29 16:39:28 ok thanks Apr 29 16:39:32 x86 and an arm then Apr 29 16:40:06 because eric bernard made some interesting patches/recipes and no one seem to push them Apr 29 16:40:32 okay, i have it catching d.getVar() and bb.data.getVar() passed a string literal.. that's a start Apr 29 16:41:19 ugh, i forgot about def'd functions Apr 29 16:41:26 likely want to try to spot those Apr 29 16:41:34 lets see.. Apr 29 16:43:08 okay, mostly easy, just need to visit the actual function definitions to exclude the local funcs from it.. course, that won't be ideal without figuring out which context the function was defined in, but its better than nothing Apr 29 16:43:09 hrm Apr 29 16:44:22 could only exclude the calls to functions defined in this context, rather than parent contexts.. that would be easy enough, i suspect.. Apr 29 16:44:30 still not ideal, but.. Apr 29 16:47:34 gnutoo is someone really using libsvga anymore? Apr 29 16:47:48 no but mplayer and nano are interesting Apr 29 16:48:19 I started to care about x86 since I got my eee701 running under oe Apr 29 16:48:24 s/oe/angstrom/ Apr 29 16:48:25 *g* Apr 29 16:48:28 lol yes Apr 29 16:48:36 I've lot of space Apr 29 16:48:42 a free sd slot Apr 29 16:48:49 but I've issues with sd detection Apr 29 16:48:54 hm how fast do it boot these days? Apr 29 16:49:13 boot time is a lot faster than ubuntu on an usb key Apr 29 16:49:21 ubuntu is really slow to boot Apr 29 16:49:26 eee701 is fast Apr 29 16:49:39 I meant eee701 with angstroem Apr 29 16:49:50 yes it's fast apart java Apr 29 16:49:57 hm Apr 29 16:50:20 openjdk? Apr 29 16:50:28 s/eee701 is fast/eee701 is fast to boot/ Apr 29 16:50:29 yes Apr 29 16:50:35 I did nasty hack Apr 29 16:50:39 and it worked at the end Apr 29 16:50:48 but I did not use JIT Apr 29 16:50:52 that's why it's slow as hell Apr 29 16:50:52 tse Apr 29 16:50:55 yes Apr 29 16:51:04 hotspot is compiling Apr 29 16:51:16 you could use icetead6-native Apr 29 16:51:18 I must take some time to look into it Apr 29 16:51:36 I didnt port my sane-x86-patches to the real openjdk Apr 29 16:51:41 hotspots build fine Apr 29 16:51:45 ok Apr 29 16:52:09 my patches were mostly oe recipes patches Apr 29 16:52:16 but they were dirty patches Apr 29 16:52:20 uncommitable I guess Apr 29 16:52:35 llvm 2.7 is now really out Apr 29 16:52:42 gnutoo??? Apr 29 16:52:44 I saw that Apr 29 16:52:54 I was in a hurry to make it work Apr 29 16:52:57 neither icedtea6 nor openjdk recipes are in oe Apr 29 16:53:01 and I don't have much time theses days Apr 29 16:53:06 commitable in jalimo I mean Apr 29 16:53:06 they are still in jalimo Apr 29 16:53:25 If I had good patches I would have sent them into the mailing list Apr 29 16:53:31 okay Apr 29 16:53:35 I still need to fix fastjar btw Apr 29 16:53:41 hu? Apr 29 16:53:43 why? Apr 29 16:53:49 site files Apr 29 16:53:53 ????? Apr 29 16:54:01 basically it does some tests Apr 29 16:54:08 and doesn't handle the cross compilation test Apr 29 16:54:14 ac try run or something like that Apr 29 16:54:18 so we need site files Apr 29 16:54:38 hm native recipe didnt had any problems with this Apr 29 16:54:38 hm Apr 29 16:54:43 ah ok Apr 29 16:54:46 amd64? Apr 29 16:54:55 x86 Apr 29 16:55:19 and it was target recipe If I remmber well Apr 29 16:55:23 I'll look Apr 29 16:55:49 hm but you need only native for building Apr 29 16:55:50 or do you intend to use fastjar on the eeepc? Apr 29 16:56:15 ah ok Apr 29 16:56:17 I'll look Apr 29 16:56:38 indeed you're right Apr 29 16:56:42 strange then Apr 29 16:56:47 hm uh llvm can now use NEON Apr 29 16:57:06 http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-and.html Apr 29 16:57:45 wow Apr 29 16:57:50 Clang does not yet support NEON. Patches are welcome! Apr 29 16:57:51 hms Apr 29 16:57:55 but I've no neon in any of my machines Apr 29 16:58:01 gcc-4.2.1 is too old Apr 29 16:59:13 mmm there is a non native recipe of fastjar Apr 29 16:59:14 hi woglinde, gnutoo Apr 29 16:59:22 hi Apr 29 16:59:39 * khem runs to meeting Apr 29 16:59:43 hikhem Apr 29 17:01:19 I'll try to look again but kernel hacking(debugging,porting forward backward etc) on htcdream in order to run SHR takes me most of my time Apr 29 17:07:33 RP: http://gist.github.com/381004#file_test.py - see compare_name, pydata, and test_python - getting there Apr 29 17:17:43 jo jama Apr 29 17:17:44 Hi, I created a Gnome X11 image using Narcissus. Is there a default login for this? The root and empty password don't seem to work Apr 29 17:18:05 root root? Apr 29 17:18:40 that doesn't work either Apr 29 17:18:53 for Narcissus you should ask your colleague koen Apr 29 17:19:26 jo woglinde Apr 29 17:19:29 thanks, let me check with him Apr 29 17:20:00 ~lart ti-codec-package Apr 29 17:20:00 * ibot urinates on ti-codec-package Apr 29 17:20:01 hmm, will have to take this python visiting code and pull it into the class which does the python snippet evaluation, so its info is included there too, not just in python functions Apr 29 17:20:28 hoorray fglrx now supports xserver 1.7 Apr 29 17:20:45 one week before xserver 1.8 Apr 29 17:20:47 hahaa Apr 29 17:21:39 * woglinde wonders if xvba is now working again Apr 29 17:27:55 before? or after :) Apr 29 17:27:58 anyone using a at91sam9g20ek these days? Apr 29 17:28:33 jama it worked sometime aroud 9.2 Apr 29 17:28:45 after this all release where broken again Apr 29 17:29:04 hm reading through phoronix forum seems it working again Apr 29 17:29:59 supper now Apr 29 17:30:01 till later Apr 29 17:34:18 progress! now it grabs 'inexpand' out of "bb.data.expand('${inexpand} foo', d)" Apr 29 17:34:26 hmm Apr 29 17:40:49 hi djwillis Apr 29 17:42:33 Bah Apr 29 17:42:49 minimal + efika fails with a gcc / eglibc wasn't happy combo Apr 29 17:43:37 Tartarus what is your eglich failure? Apr 29 17:43:41 args eglibc Apr 29 17:43:46 The _restfpr_14_x one Apr 29 17:43:52 hm Apr 29 17:44:01 Trying just moving up to 2.11 from 2.10 Apr 29 17:44:16 * Tartarus is trying to find a set of non-ARM machines to build before and after the RP branch merge Apr 29 17:45:01 howdi woglinde Apr 29 17:48:37 hmm, think i'll add a special case to handle the occasionally used data.getVar() Apr 29 17:53:12 03Martin Jansa  07org.openembedded.dev * rcd499daebd 10openembedded.git/conf/distro/include/sane-srcrevs.inc: freesmartphone: bump SRCREV for cornucopia bugfix Apr 29 18:24:57 :!python test.py Apr 29 18:24:57 Warning: ignoring execution of $testval as it appears to be a shell variable expansion Apr 29 18:24:57 Warning: non-literal string argument foo used in 'getVar' call, unable to track reference Apr 29 18:24:57 Warning: non-literal string argument bb.data.getVar('something', False, d) used in 'expand' call, unable to trac Apr 29 18:24:57 k reference Apr 29 18:24:58 Warning: non-literal string argument a() used in 'getVar' call, unable to track reference Apr 29 18:25:00 nice. Apr 29 18:25:08 slowly getting there Apr 29 18:25:36 kergoth - we feel your pain. Apr 29 18:30:06 Tartarus: its ppc right ? Apr 29 18:30:13 yeah Apr 29 18:30:16 efika is ppc603e Apr 29 18:30:18 Tartarus: I think I fixed libgcc for it Apr 29 18:30:25 khem: what gcc? Apr 29 18:30:26 which gcc version Apr 29 18:30:30 This was 4.4.2 + eglibc 2.10 Apr 29 18:30:35 (defaults from sane-toolchain) Apr 29 18:30:40 hmmm Apr 29 18:31:16 Tartarus: I have to search my memory what and where I fixed it Apr 29 18:31:28 meanwhile can you try 4.5.0 Apr 29 18:31:57 Tartarus: I think qemumips would be another non arm machine to test for and qemux86 Apr 29 18:32:29 yeah, got qemux86 and building for malta Apr 29 18:33:14 and may be some sh4 box like titan Apr 29 18:34:34 Tartarus: is ppc603e having an FPU Apr 29 18:35:10 your problem is same as this one here http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg03069.html Apr 29 18:36:15 Yeah Apr 29 18:36:21 I thought you fixed it too :) Apr 29 18:36:26 And yes, 603e is classic ppc Apr 29 18:44:00 Tartarus: you could also try to remove -mhard-float as well as -msoft-float from compiler options mcpu should set it Apr 29 18:44:34 if this blows up, k Apr 29 18:45:25 problem is that libgcc is confused between configuring for hardfloat and softfloat Apr 29 18:45:42 how it ends up there I dont know unless I do a build myself Apr 29 18:45:45 k Apr 29 18:45:55 It'll probably fail again and I'll poke the tune file Apr 29 18:46:03 yeah Apr 29 18:46:21 Tartarus: are you trying 4.5 now ? Apr 29 18:46:32 4.4.2 still but eglibc 2.11 Apr 29 18:46:36 That was my stab in the dark :) Apr 29 18:46:42 that will fail for sure :) Apr 29 18:46:46 its not eglibc issue Apr 29 18:48:20 Hello ... do someone recall which packages I need to cleanup to rebuild glibc? Apr 29 18:48:34 Are them glibc and glibc-initial? Or am I missing anything? Apr 29 18:48:42 otavio: in theory also gcc-cross* Apr 29 18:48:56 Yay for pstaging? Blow away rest of $TMPDIR instead is easier for me Apr 29 18:48:56 Tartarus: gcc-cross humm Apr 29 18:49:00 all of 'em Apr 29 18:49:05 initial and intermediate too Apr 29 18:49:15 Tartarus: I'm still using stable Apr 29 18:49:20 Tartarus: that's why I can't do it Apr 29 18:49:36 Tartarus: intermediate for which? gcc? Apr 29 18:49:46 yes Apr 29 18:49:54 gcc-cross-initial and gcc-cross-intermediate and gcc-cross Apr 29 18:50:23 Tartarus: good; thx Apr 29 18:50:28 Tartarus: let me try that all Apr 29 19:36:21 Hello. I'm trying to get a kernel module compiled and I'm a bit stumped. My problem is that my compiles are resulting in vermagics of "2.6.32 mod_unload modversions ARMv5" and I need "2.6.32 mod_unload modversions ARMv7" ... I'm new to working with Kernel modules and could really use some advice... any help? Apr 29 19:36:47 Yes, this is a known issue currently, for external kernel modules at least Apr 29 19:37:12 Is the module that's not working an external one or one that's in the kernel tree? Apr 29 19:37:21 It is my own. Apr 29 19:37:37 I have just a simple makefile that lists obj-m := whatever.c Apr 29 19:37:38 So an external to the kernel tree module? Apr 29 19:37:40 Yeah Apr 29 19:37:42 Sec.. Apr 29 19:37:42 Yes. Apr 29 19:38:06 You need something like: http://patchwork.openembedded.org/patch/1978/ Apr 29 19:38:58 Let me read that, one sec. Apr 29 19:39:31 Then bitbake -f -c populate_staging virtual/kernel Apr 29 19:39:37 and bitbake -c rebuild on your module Apr 29 19:43:57 Having trouble building gst-rtsp from recipe. Error from configure.ac: possibly undefined macro: PKG_CHECK_MODULES. I googled, but couldn't find anything. I even updated my autoconf to latest version thinking that might help. Anyone have a pointer? I'm running ubuntu 9.04 host. Apr 29 19:44:14 machine type is overo. Apr 29 19:46:16 Tartarus: At the moment, I'm just trying to build without a BB script from linux-omap3-2.6.32-r51 with a make ARCH=arm CROSS_COMPILE=arm-ang... M=mymoduledir Apr 29 19:46:56 em386: A BB recipe is trivial tho :) Apr 29 19:47:04 And will help make sure you get the right stuff Apr 29 19:47:39 It's little more than: Apr 29 19:47:43 inherit module Apr 29 19:48:00 FILES_${PN} = "${base_libdir}/modules/" Apr 29 19:48:14 * Tartarus tries to find a good'ish example Apr 29 19:50:00 recipes/robostix-module/robostix-module.bb is functional at least Apr 29 19:50:31 Great, I have that and I'll take a look at it now. Thanks. Apr 29 19:55:41 Note that you will need that change I first pointed at, for it to work Apr 29 19:55:45 Known issue being discussed now Apr 29 19:57:51 Thanks. I'm also trying to figure out what is the best way for getting the omap ISP (webcam) stuff supported. There seems to be a bit of flux with v4l2 and this (new?) structure for SoC-camera? Apr 29 19:59:00 emm386: I'm trying to understand what SoC Camera is changing into, also. Apr 29 20:00:33 * woglinde needs tear and fedders for the buildscript authors of ti-dsplink Apr 29 20:01:14 There is a git branch called omap3camera that seems to have the files I need, but our hardware used a sensor that's not supported (mt9p031). Should I be trying to write something for SoC for this sensor? Apr 29 20:02:51 khem: No help Apr 29 20:03:07 khem: Put it to just -mcpu=603e Apr 29 20:04:57 * Tartarus does a git grep on TARGET_FPU since sane-toolchain is munging that Apr 29 20:07:16 khem: Quick grepping doesn't show -mhard-float nor -msoft-float being used Apr 29 20:08:07 hi , i want to use omapfbplay on highest performance , therefore i disabled X window system and i want to do is , force omapfbplay to use L1 and L2 caches and highest priority , how can i do these all on angstrom linux with highest performance video play ? Apr 29 20:22:45 03Denys Dmytriyenko  07org.openembedded.dev * ra5d3960e03 10openembedded.git/recipes/bluez/ (ussp-push-0.11/hci_remote_name.patch ussp-push_0.11.bb): Apr 29 20:22:45 ussp-push: add OBEX object pusher app Apr 29 20:22:45 Signed-off-by: Denys Dmytriyenko Apr 29 20:24:46 ping denis Apr 29 20:26:23 woglinde, hi Apr 29 20:26:26 which denis? Apr 29 20:26:47 I'll push soon if that's what you want to ask me Apr 29 20:26:55 I'm testing a change on illume-image Apr 29 20:27:16 but rebooting takes some time Apr 29 20:27:20 denix Apr 29 20:27:24 ah ok Apr 29 20:27:30 so den*y*s Apr 29 20:43:07 incomming... Apr 29 20:43:17 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * rf3438bd86a 10openembedded.git/recipes/freetype/ (3 files in 2 dirs): Apr 29 20:43:17 freetype 2.3.11: add new version Apr 29 20:43:17 This version fixes the following issue with navit: Apr 29 20:43:17 https://bugzilla.redhat.com/show_bug.cgi?id=506840 Apr 29 20:43:17 Thanks woglinde for pointing out that the new version had the fixes: Apr 29 20:43:17 bestway is to update to freetype 2.3.11 Apr 29 20:43:21 03Denis 'GNUtoo' Carikli  07org.openembedded.dev * red9973300f 10openembedded.git/recipes/images/illume-image.bb: (log message trimmed) Apr 29 20:43:21 illume-image: fix compilation and desktop icons issue Apr 29 20:43:21 *adding e-wm-menu fix the issue where your couldn't add icons Apr 29 20:43:21 on the desktop. the icon you add during the first setup now Apr 29 20:43:21 appear on the desktop Apr 29 20:43:21 *removing elementary-alarm fixes compilation issue: Apr 29 20:43:22 elementary-alarm depends on waker which does not compile: Apr 29 20:51:02 Tartarus: Did all that you said, bitbaked, (didn't install), but ended up with a .ko file built with the same vermagic ARMv5 problem. Apr 29 20:52:18 woglinde: pong Apr 29 20:52:31 em386: Matches the kernel that was built tho... Apr 29 20:52:40 denix query Apr 29 20:54:54 03Koen Kooi  07org.openembedded.dev * ra2011275a2 10openembedded.git/recipes/powervr-drivers/libgles-omap3.inc: libgles-omap3: packages WSEGL drivers seperately to kill X11 runtime dep for ${PN} Apr 29 21:05:54 Tartarus: It matches the other kernel modules in tmp/staging, but I'm running the kernel from tmp/work (the one that was compiled into an image?) Apr 29 21:06:31 You want the kernel image in deploy Apr 29 21:06:51 ~seen ant Apr 29 21:06:54 ant was last seen on IRC in channel #oe, 422d 20h 59m 19s ago, saying: 'nite all'. Apr 29 21:09:16 I untarred the modules from deploy/glibc/images/overo to get deploy/glibc/image/overo/lib/modules/2.6.32/kernel/drivers/media/video/v4l2-common.ko with modinfo says is ARMv7. Apr 29 21:09:47 Or, do I need to recompile all the modules? Apr 29 21:10:09 Isn't there anyway to just get my module to be ARMv7; seems like that would be easier. Apr 29 21:10:26 (Thanks, by the way; as you can see I'm a bit over my head on this) Apr 29 21:24:45 Tartarus: hmm so removing -mhard-float did not help ? Apr 29 21:25:42 Tartarus: conf/machine/include/tune-ppc603e.inc remove -mhard-float from TARGET_CC_ARCH Apr 29 21:27:27 hmmmm Apr 29 21:40:49 khem: Yeah, that's what I did, no change Apr 29 21:48:23 khem: any thought about -g3 ? Apr 29 21:49:45 I was thinking about DISTRO_TYPE = "debug" Apr 29 21:50:01 perhaps DISTRO_TYPE = "anal"...and -g3 Apr 29 21:50:29 ehm.. a.k.a. analysys **** ENDING LOGGING AT Thu Apr 29 21:57:51 2010 **** BEGIN LOGGING AT Thu Apr 29 21:58:15 2010 **** ENDING LOGGING AT Thu Apr 29 21:58:51 2010 **** BEGIN LOGGING AT Thu Apr 29 22:00:14 2010 Apr 29 22:36:35 ant__: you could use minimal I think it does not have -g3 stuff Apr 29 22:36:49 Tartarus: so you tried gcc 4.5.0 as well ? Apr 29 22:38:36 khem: No Apr 29 22:38:43 just 4.4.2 and removing the -mhard-float line Apr 29 22:38:48 Tartarus: I will try gcc 4.5.0 and efika on minimal and try to reproduce the problem. I think there was a problem with -Os Apr 29 22:38:56 I'll try an e300 target instead soon Apr 29 22:39:01 which ended up in emitting these prologue calls Apr 29 22:39:08 khem: k Apr 29 22:39:37 Something got confused when whoever added the c603e stuff perhaps to gcc? Apr 29 22:39:51 'cuz that's apparently 603e + soft-float Apr 29 22:43:02 Tartarus: may be not, I am more doubtful about OE passing wrong config Apr 29 22:43:33 We'll see Apr 29 22:43:39 Just passing in -mcpu=603e does it Apr 29 22:44:55 I dont see any info on 60e having a fpu Apr 29 22:45:04 I am still trying to be google smart Apr 29 22:45:27 * Tartarus dusts off brain Apr 29 22:45:33 http://domino.watson.ibm.com/tchjr/journalindex.nsf/600cc5649e2871db852568150060213c/09c0e93af0b7332e85256bfa0067fb2f!OpenDocument Apr 29 22:46:26 there you go :) Apr 29 22:47:00 OK let me reproduce it locally Apr 29 22:47:13 Tartarus: the machine efika wud choose it for me ? Apr 29 22:47:32 yes Apr 29 22:48:20 e300 is 603e - fpu + SPE Apr 29 22:48:52 he khem are you familiar with custom linkerscripts? Apr 29 22:49:22 I get did you forget -T? undefined reference to `atexit' Apr 29 22:49:26 with ld Apr 29 22:49:39 woglinde: yes bring it on Apr 29 22:49:41 khem, depends on which e300 class? Apr 29 22:49:43 c2 or c3 Apr 29 22:49:44 iirc Apr 29 22:49:50 yeah c2 is fpuless Apr 29 22:49:54 do you know I need to change in the linkerscripts? Apr 29 22:49:57 c1 and c3 have fpu Apr 29 22:50:00 But yes, the "603e" core has been reused by PPC for forever Apr 29 22:50:00 its eglibc Apr 29 22:50:44 woglinde: change for what ? and which ver of eglibc is it Apr 29 22:51:27 khem I found this here Apr 29 22:51:34 which sounds reasonable http://old.nabble.com/Undefined-reference-to-atexit-td28029636.html Apr 29 22:51:39 woglinde: generally eglibc linker scripts dont change so often Apr 29 22:51:54 oh eglibc 2.9? Apr 29 22:52:07 yes there was a change which I have already committed Apr 29 22:52:12 to 2.9 Apr 29 22:52:28 its 2.10 Apr 29 22:52:40 gcc 4.33 Apr 29 22:52:52 binutils 2.20 Apr 29 22:53:15 as I said the eglibc linkerscripts get overwritten Apr 29 22:53:18 are you getting same error Apr 29 22:53:25 yes Apr 29 22:53:55 with OE ? Apr 29 22:54:12 hm ah I have this section too Apr 29 22:54:13 xdc.meta (COPY) : {*(xdc.meta)} Apr 29 22:54:20 in this linkerscript Apr 29 22:55:02 hm should I remove it Apr 29 22:55:19 wait so you are trying to link a given app Apr 29 22:55:24 which uses this linker script Apr 29 22:55:32 not eglibc itself has the problem right ? Apr 29 22:55:36 yes Apr 29 22:55:42 I see Apr 29 22:55:48 its the same as in this post Apr 29 22:56:10 I need to see the linker script Apr 29 22:56:14 which project is it Apr 29 22:56:46 ti-codec stuff Apr 29 22:58:39 woglinde: this section does not seem familiar to me what does xdc.meta contain Apr 29 22:59:38 where do I find what xdc.meta is Apr 29 22:59:49 but maybee the copyline has changed Apr 29 23:00:59 must be in ti-codec Apr 29 23:01:29 I dont think such a section exist in eglibc that would make it pull stuff Apr 29 23:01:41 so it must be something in the codecs that pulls in stuff Apr 29 23:02:02 as I said this the linkerscript they use Apr 29 23:02:09 woglinde: what happens if you change it to xdc.meta: type = COPY Apr 29 23:02:57 hm whole line please Apr 29 23:03:21 can you paste the existing linker script for me somewhere Apr 29 23:04:32 http://pastebin.com/EymM11uv Apr 29 23:04:48 this seems the stuff in question Apr 29 23:05:35 woglinde: ok and where is it used on commandline can you also paste the commandline for me Apr 29 23:06:22 http://pastebin.com/1Zt1SGuD Apr 29 23:07:22 ah xda stuff is in the .map Apr 29 23:07:23 file Apr 29 23:07:44 http://pastebin.com/NZFdB9Zn Apr 29 23:07:51 linux/audio_decode_io1_omap3530_config/linker.cmd is specified as normal file to it Apr 29 23:07:59 its confusing Apr 29 23:08:16 it should have been using -T if its really meant to be the linker script Apr 29 23:08:23 ah Apr 29 23:08:29 I am stupid Apr 29 23:08:55 hm Apr 29 23:09:22 but then if you are going to have your own linker script then you better make sure that stuff goes into right places Apr 29 23:09:23 -Wl,-T, I guess Apr 29 23:09:34 just -T is also ok Apr 29 23:09:36 gcc knows it Apr 29 23:09:51 hm nope Apr 29 23:09:51 but -Wl,-T will work too Apr 29 23:09:56 dont works Apr 29 23:10:40 plus this linker script is not complete Apr 29 23:10:53 http://pastebin.com/35GpMt8Q Apr 29 23:10:56 so make sure that you dump the default linker script Apr 29 23:11:03 and add this output section to it Apr 29 23:11:05 how? Apr 29 23:11:08 and that becomes your linker script Apr 29 23:11:52 you added -Wl,-T, infront of wrong file Apr 29 23:12:06 it should be added before linux/audio_decode_io1_omap3530_config/linker.cmd Apr 29 23:12:13 not before linux/main.omap3530.o470MV Apr 29 23:12:26 ????? Apr 29 23:12:30 I did Apr 29 23:12:43 -Wl,-T,linux/main.omap3530.o470MV linux/audio_decode_io1_omap3530_config/linker.cmd Apr 29 23:12:45 doesnt seems to Apr 29 23:12:55 there is a space Apr 29 23:12:58 uüs Apr 29 23:13:03 *hides* Apr 29 23:13:27 * khem *smack* Apr 29 23:13:38 okay Apr 29 23:13:51 now how do I dump the default linkerscript Apr 29 23:13:53 woglinde: do -ld -verbose Apr 29 23:14:05 that will dump the default linker script that ld uses Apr 29 23:14:12 so redirect that to a file Apr 29 23:14:18 and that becomes your ld script Apr 29 23:14:26 and then you can tinker it Apr 29 23:14:50 so I should use -T twice? Apr 29 23:14:53 tright Apr 29 23:14:56 no Apr 29 23:15:07 the step I mentioned last is done once Apr 29 23:15:12 to get the initial script Apr 29 23:15:20 you dont have to do it again and again Apr 29 23:15:27 ??????? Apr 29 23:15:40 how do I merge both scripts? Apr 29 23:15:48 by hand Apr 29 23:16:08 dump the default script to a file Apr 29 23:16:12 yes Apr 29 23:16:37 and then add xdc.meta (COPY) : {*(xdc.meta)} somewhere under SECTIONS Apr 29 23:16:50 hm and the stuff before too? Apr 29 23:16:51 paste the dump of default script somehwere Apr 29 23:16:57 I can tell where you can add it then Apr 29 23:17:45 there is an INPUT section too Apr 29 23:17:58 ok Apr 29 23:17:58 can I put it where I want? Apr 29 23:18:15 what you pasted for me was just 4 lines Apr 29 23:18:22 jupp Apr 29 23:18:24 I thought that was the linker script Apr 29 23:18:27 sorry Apr 29 23:18:37 paste it completely then Apr 29 23:18:39 I only pasted the part I tought was relevant Apr 29 23:19:16 http://pastebin.com/HcZewBTz Apr 29 23:19:54 is that the other half ? Apr 29 23:20:01 yes Apr 29 23:20:34 ok first keep using the same script Apr 29 23:20:40 and then do the -T stuff Apr 29 23:20:48 as we discussed earlier Apr 29 23:20:51 and see where you end up Apr 29 23:20:56 ?????? Apr 29 23:21:05 ah okay Apr 29 23:21:09 -Wl,-T,linux/audio_decode_io1_omap3530_config/linker.cmd Apr 29 23:21:30 My guess is that the existing script is enough for what is needed Apr 29 23:21:56 http://pastebin.com/5LVQP2nQ Apr 29 23:23:03 ok seems not Apr 29 23:23:18 woglinde: try to dump the default linker script then Apr 29 23:23:24 and add the sections in there Apr 29 23:25:32 http://pastebin.com/1SRLwbV5 Apr 29 23:26:32 put xdc.meta (COPY) : {*(xdc.meta)} at the end Apr 29 23:26:46 before ? Apr 29 23:26:50 argh Apr 29 23:26:55 before } Apr 29 23:27:07 hm at the end of SECTIONS? Apr 29 23:27:13 yes Apr 29 23:27:18 should be the last Apr 29 23:27:49 is this linker script for gnu ld btw Apr 29 23:27:54 I mean the TI linker script Apr 29 23:29:20 hm shouldnt it .xdc.meta then? Apr 29 23:29:50 well dont worry Apr 29 23:30:02 add the INPUT at the top Apr 29 23:30:17 copy is right there too? Apr 29 23:30:17 after SEARCH_DIR Apr 29 23:30:21 yes Apr 29 23:30:29 or should it be like the keep? Apr 29 23:32:46 hm that seemed to work Apr 29 23:33:04 well I havent seen people use COPY in these days Apr 29 23:33:15 it just means NOLOAD in currenr ld Apr 29 23:33:16 whats copy doing? Apr 29 23:33:45 it marks section as not allocatable Apr 29 23:34:11 at runtime no memory is allocated for this Apr 29 23:34:20 sorry it does not mean noloa Apr 29 23:34:23 noload Apr 29 23:34:49 and there is no easy way to merge it? Apr 29 23:35:09 I have to understand what this section is about Apr 29 23:35:18 to comment Apr 29 23:35:55 but may be this is some metadata thats not used at runtime Apr 30 01:52:32 So Apr 30 01:52:38 Should DISTRO=minimal work on non-arm? :) Apr 30 01:53:26 Aside from the efika (ppc603e) general issue, qemux85, malta, calamari and qemumips all have some failure or another Apr 30 01:53:31 * Tartarus does the loop again, logging stdout Apr 30 01:55:03 * kergoth wonders if anyone is even maintaining minimal nowadays Apr 30 02:05:41 bah, malta isn't in OE, which would explain that one :) Apr 30 02:05:51 heh, oops Apr 30 02:05:54 * Tartarus does db1200 like he intended, but expects same problem as qemumimps Apr 30 02:06:13 which is a vala / libfso-glib has too old a vala config problem or so Apr 30 02:06:15 man, emit_data is *so* handy for signature crap Apr 30 02:39:46 hmm, mips vs mipsel issue, heh Apr 30 02:39:49 mipsel is ok so far :) Apr 30 02:42:54 quick question about time optimization, trying to reduce build time Apr 30 02:43:38 our build machine is 8 cores, 16GB ram, BB_NUM_THREADS=10 and PARALLEL_MAKE is 12 Apr 30 02:43:50 that's potentially 120 make threads going at once Apr 30 02:44:00 which seems like a bad aidea Apr 30 02:45:03 well, its unlikely that it'll be do_compile on all the bitbake threads at all times. there are a lot of tasks to be run Apr 30 02:45:20 right Apr 30 02:45:34 and dependencies do stack up Apr 30 02:45:50 i.e. everyone is waiting for gcc-cross Apr 30 02:45:55 ideally we'd be a bit smarter about it. say no more than 3 unpacks at a time, no more than N compiles at a time, .. since different tasks have different primary resources Apr 30 02:47:04 i was curious if anyone had any anecdotal advice. i could empirically measure i guess but there are lots of combinations ;D Apr 30 02:47:12 that's be a sweet feature tho Apr 30 02:47:25 there might be some who know better than I, I don't have any machines that hefty :) Apr 30 02:47:58 me either, thanks Bug Labs Apr 30 02:50:58 http://svr-alm-svn-01.alm.mentorg.com:8080/svn/ea/easi_oe/projects/veracruz/sand Apr 30 02:51:20 Hmm Apr 30 02:51:23 Ga Apr 30 02:51:35 So, jconnolly, it kinda depends Apr 30 02:51:55 I've done 8 threads, make -j 6 and not had issues Apr 30 02:52:35 In general, I say NCPUS for threads, NCPUS*2 for jobs Apr 30 02:52:40 er, 1.5 Apr 30 02:53:31 yeah, but i was curious the relationship of the PARALLEL_MAKE to BB_NUM_THREADS. looking at htop though it doesn't seem all that load-heavy, not perpetually pegged Apr 30 02:53:48 I think it might be interesting to do some task-level profiling Apr 30 02:53:57 see just what % of the time is taken up by, say, unpack, or compile, or install Apr 30 02:54:14 Yeah Apr 30 02:54:46 It also really depends on how beefy your HW is Apr 30 02:54:57 def Apr 30 02:54:58 my desktop quadcore, t4/j6 is about it Apr 30 02:55:15 On some enterprise level stuff at work, we go with 6/8 Apr 30 02:55:21 on 4 CPUs Apr 30 02:55:36 And that's reasonable speed enough that I don't want to add more CPUs to the mix Apr 30 02:55:57 we even got SSD's for a DL_DIR partition and TMP_DIR Apr 30 02:56:04 (saw marginal improvement) Apr 30 02:56:16 What were you on before tho? Apr 30 02:56:28 We did some profiling and found disk just wan't an issue Apr 30 02:56:51 yeah I suspected that diskio wasn't going to be a source of much latency Apr 30 02:57:08 sharing DL_DIR was a nice feature Apr 30 02:57:15 One of those someday things, imho, would be a more OE-specific scheduler for bitbake Apr 30 02:57:17 vs the general one Apr 30 02:57:49 i naively thought that bitbake was an OE artifact Apr 30 02:57:52 not so? Apr 30 02:58:11 While I don't know of other users, no, they're separate Apr 30 02:58:27 interesting Apr 30 02:58:44 So, dumb question Apr 30 02:59:02 In Linux, do we still do ext[34] on SSDs or something else? Apr 30 02:59:24 i just had to look Apr 30 02:59:30 * Tartarus sometimes winks out on the various flash magic stuff Apr 30 02:59:56 ext4 **** ENDING LOGGING AT Fri Apr 30 02:59:57 2010