**** BEGIN LOGGING AT Sun Nov 27 02:59:57 2011 Nov 27 08:50:51 Q: I building linux-omap (HEAD) for testing my machine. I have my old .config for 3.0. I tried using it as the old config for 3.2-rc2, but that fails with memory exception. Is it possible to generate a completely new config from the beginning? I remember there -c menuconfig step, but that should open gnome terminal while I have on shell/ssh access. Nov 27 08:51:38 sakoman: ping Nov 27 08:58:00 davidlt: set it to open screen session istead Nov 27 08:58:03 instead Nov 27 08:58:39 TERMCMD = "${SCREEN_TERMCMD}" Nov 27 08:58:39 TERMCMDRUN = "${SCREEN_TERMCMDRUN}" Nov 27 08:59:13 I saw something like that on bitbake.conf Nov 27 08:59:59 It looks like defining those two variables in my local.conf would do the trick Nov 27 09:00:04 JaMa|Off: Thanks! Nov 27 10:35:27 03Richard Purdie  07master * r9f7978ca4d 10bitbake.git/ (23 files in 8 dirs): Nov 27 10:35:27 Update users of getVar/setVar to use the data store functions directly Nov 27 10:35:27 (From Poky rev: affd0907253387cee0ba0c7e9f92bcc109895446) Nov 27 10:35:27 Signed-off-by: Richard Purdie Nov 27 11:29:40 Q: I wrote linux-omap recipie to use latest linux-omap.git dev tree. It boots on my machine with some problems, but the main problem is kernel modules being from 2.6.39 kernel, but currently I am building 3.0 from GIT. Nov 27 11:30:30 I would think that PREFERED_VERSION-kernel-modules is wrong or PREFERED_PROVIDER-kernel-modules. Nov 27 11:32:09 On the system I find /lib/modules/2.6.39, but on the /tmp/rootfs 3.0.0 Nov 27 11:38:25 sakoman: ping Nov 27 11:38:39 davidlt: usually this problem is only because 2.6.39 defconfig has something as module while 3.0 has it included or not built at all Nov 27 11:39:15 PREFERED_VERSION is used only to decide version to build Nov 27 11:39:31 target package management will try to use newest version available Nov 27 11:39:34 in feeds Nov 27 11:44:02 mornin Nov 27 11:46:10 hmm, my do_populate_sdk task is failing, can I somehow tell OE (or opkg? who does it?) to use /var/tmp instead of /tmp? http://pastebin.mozilla.org/1388583 Nov 27 11:47:11 JaMa|Off: even /proc/config.gz is different than .config I have Nov 27 11:47:18 * davidlt has unstable WiFi Nov 27 11:52:53 davidlt, that's normal the kernel .inc should modify some options Nov 27 11:56:03 GNUtoo: Hi Nov 27 11:56:24 GNUtoo: Different wireless drivers are enabled Nov 27 11:57:05 On machine I have 2.6.39 and kernel config shows that libertas_tf is enabled Nov 27 11:57:54 I checked config of the kernel I just build (.../git/.config) and libertas is enabled, not libertas_tf Nov 27 11:59:24 Hmm... I jusked rootfs: tmp/rootfs/emetergateway-console-image/lib/modules/3.0.0/kernel/net/wireless Nov 27 11:59:47 libertas.ko, libertas_sdio.ko are missing Nov 27 12:00:54 modinfo confirms that kernel modules on NAND are for 2.6.39, not for 3.0.0 Nov 27 12:01:56 Oh, i messed up something Nov 27 12:05:06 My apologies everyone, I was looking on the wrong path. NAND also has 3.0.0 and modules are for 3.0.0 also. I can confirm my kernel booting: Image Name: Angstrom/3.0+gitr02f8c6aee8df3cd Nov 27 12:05:26 can I tell meta-toolchain to create an rpm instead of a tar.bz2? :> Nov 27 12:06:07 Jin^eLD: Bitbake does not support RPMs, I think Nov 27 12:06:49 I think it does, for the target it should, I would guess for the sdk stuff too, googling.. Nov 27 12:07:55 ah, there is a populate_sdk_rpm.bbclass Nov 27 12:07:59 that should be it Nov 27 12:11:41 GNUtoo: looks like wireless module is missing Nov 27 12:12:57 Here: /proc/config.gz shows: CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m Nov 27 12:13:16 But I don't see those kernel modules on rootfs and of course on NAND Nov 27 12:13:41 And during the boot ir fails: ibertas_sdio: Unknown symbol lbs_notify_command_response (err 0) libertas_sdio: Unknown symbol release_firmware (err 0) ... Nov 27 12:13:46 hmm, inheriting the populate_sdk_rpm in bbappend of meta-toolchain did not do anything... Nov 27 12:13:50 there is a variable in machine config for that Nov 27 12:13:57 just created an empty rpm dir in deploy Nov 27 12:15:03 MACHINE_EXTRA_RRECOMMENDS Nov 27 12:15:18 + module_autoload_foo = "foo" Nov 27 12:16:25 GNUtoo: But why would I need this? Shouldn't it be done automatically? I worked fine with other kernel recipies Nov 27 12:17:31 maybe the second part is done automatically if you have udev tough Nov 27 12:18:46 GNUtoo: Under machine conf I have MACHINE_EXTRE_RE... = "kernel-modules" Nov 27 12:19:26 Shouldn't that work too? Nov 27 12:19:36 yes it should Nov 27 12:19:43 that should ship all kernel modules Nov 27 12:19:50 The only missing drivers are all libertas modules Nov 27 12:20:08 no idea Nov 27 12:20:49 Okay, I will add kernel-modules-libertas and kernel-modules-libertas-sdio to check it will force them to be added Nov 27 12:25:08 GNUtoo: just checked older log.build_rootfs: Installing kernel-module-libertas-sdio (3.0+gitr02f8c6aee8df3cdc935e9bdd4f2d020306035dbe-r97.6) to root... Nov 27 12:27:20 I don't see kernel-module-libertas installed Nov 27 13:00:48 GNUtoo: It's very strage... Nov 27 13:01:01 *strange Nov 27 13:02:05 There are 2-3 missing kernel modules, all from libertas. Adding kernel-modules-libertas and kernel-modules-libertas-sdio did not do anything Nov 27 13:02:13 Those modules are built Nov 27 13:02:53 There are records of two of them in /lib/modules/3.0.0/* files Nov 27 13:03:00 But modules are missing Nov 27 13:03:23 And the main part, libertas is completely missing, no kernel module and no record about it Nov 27 13:06:00 davidlt, Jin^eLD, bitbake supports RPMs Nov 27 13:07:20 GNUtoo: I could not get meta-toolchain to spit out an rpm, I inherited the appropriate class but it only created an empty "rpm" dir in deploy Nov 27 13:08:04 * davidlt rebuilding image with 2.6.34 for now... Nov 27 13:09:06 Jin^eLD, I don't know I never used rpm but I know it's supported Nov 27 13:09:27 me neither, tried it for the first time now Nov 27 13:09:35 was helping a friend to create a meta toolchain Nov 27 13:10:00 which basically worked but he'd like to have an rpm of it, and from what I see it is supported... but did not work out somehow Nov 27 13:13:05 hii Nov 27 13:21:12 hi Nov 27 13:50:58 GNUtoo: I changed back to use 2.6.34 Nov 27 13:51:08 Now I still see /lib/modules/3.0.0 Nov 27 13:51:28 But I see 2 of the missing libertas kernel modules, but still missing libertas main module Nov 27 13:51:34 Something is messed up Nov 27 13:54:15 Hehe Nov 27 13:54:32 Some why image picks kernel-modules-3.0 instead of 2.6.34 Nov 27 14:02:11 How to find out who is messing up? Nov 27 14:04:26 Gonna try making a clean build Nov 27 15:10:38 bluelightning: hi, I've just unbricked my h1940, will test 3.1 sometime soon :) Nov 27 15:10:53 anarsoul: cool, great to hear :) Nov 27 15:48:43 Would I be save moving from 1.12 Bitbake to 1.14 with older oe.dev ? Nov 27 15:49:40 It has been 9 months since 1.12.0 was released. Nov 27 15:59:07 bluelightning: do you have rootfs with opie, dropbear and alsa-utils somewhere near? Nov 27 15:59:33 anarsoul: not an up-to-date one, but I can build one for you Nov 27 15:59:59 I'm OK with not-up-to-date Nov 27 16:00:53 and some mp3 player would also be nice (mpg123?) Nov 27 16:01:03 or ogg123 :) Nov 27 16:06:10 anarsoul: the last one I sent is probably the most up-to-date one I have already built Nov 27 16:09:51 bluelightning: but it lacks alsa-utils Nov 27 16:12:25 davidlt: there's a slight problem with oe-classic with 1.14.0 in that there are instances where comments are in the middle of multi-line strings; this is no longer allowed Nov 27 16:44:29 jo Nov 27 16:54:05 hms Nov 27 16:54:15 come back stefan_schmidt Nov 27 18:15:25 bluelightning: 3.1 works on h1940 Nov 27 18:15:29 bluelightning: do you need kernel config? Nov 27 18:15:46 anarsoul: yes please, we should update the one in meta-handheld for h1940 Nov 27 18:15:51 thanks for testing :) Nov 27 18:16:03 no pb :) Nov 27 18:16:39 will try to fix h1940 bluetooth issues this week Nov 27 19:42:05 hmm, I have a software package, compiled fine in OE classic, but in OE core it's configure is failing at finding IEEE math support Nov 27 19:42:16 hm Nov 27 19:42:26 is the core toolchain built with some different options or what do I look for Nov 27 19:42:27 ? Nov 27 19:42:28 header maybee missing? Nov 27 19:43:42 hmm I think configure may be using obsolete checks Nov 27 19:44:08 that could be Nov 27 19:44:10 http://pastebin.mozilla.org/1388590 Nov 27 19:44:57 hm rddtool Nov 27 19:45:01 yes :P Nov 27 19:45:15 I got it to build in OE classic Nov 27 19:45:20 now doing the same in OE core Nov 27 19:45:25 you know it? Nov 27 19:45:38 sure Nov 27 19:46:04 I am not that familiar with it yet Nov 27 19:46:26 do you have the recipe? Nov 27 19:46:36 sure Nov 27 19:47:02 maybe you are not running autoreconf Nov 27 19:47:17 https://gitorious.digitalstrom.org/dss-oe/dss-oe/trees/master/targets/dss11-testing/recipes/rrdtool Nov 27 19:47:18 or the m4 macro is to old for this test Nov 27 19:47:45 I tried both; I tried running autoreconf and then I tried skipping it using do_configure() { oe_runconf } Nov 27 19:47:56 but had the same result; however it fails only with the nwer toolchain on OE core Nov 27 19:48:04 the 2-year old OE-classic build has no problems Nov 27 19:50:55 mhm I am not quite sure how to approach this Nov 27 19:51:03 hm could please pastebin the m4 macro for fpclassify Nov 27 19:51:43 let me look for it... Nov 27 19:52:06 I have the test program from the config.log of course Nov 27 19:52:54 hm no Nov 27 19:53:01 Jin^eLD: what is compiler version of old oe Nov 27 19:53:02 from configure.ac please Nov 27 19:53:24 Jin^eLD: sometimes tests were poorly written and compiler optimized away the very calls one was testing Nov 27 19:53:34 that may not be the case anymore Nov 27 19:53:46 hi khem Nov 27 19:53:54 hi khem, arm-angstrom-linux-gnueabi-gcc (GCC) 4.3.3 Nov 27 19:53:55 woglinde_: hello Nov 27 19:54:06 Jin^eLD: ok what test does fail Nov 27 19:54:17 here already pastebin Nov 27 19:54:22 fpclassify Nov 27 19:54:24 find the small test program from configure Nov 27 19:54:30 *sigh* Nov 27 19:54:33 is that with glibc ? Nov 27 19:54:36 or uclibc Nov 27 19:54:37 that I already told Nov 27 19:54:54 no, that's eglibc Nov 27 19:54:56 new one Nov 27 19:54:57 old one was glibc Nov 27 19:54:59 generally one has to link with -lm Nov 27 19:55:09 for this to succeed if its a link time test Nov 27 19:55:20 eglibc or glibc ist egal Nov 27 19:55:24 khem: this is the failuer http://pastebin.mozilla.org/1388590 Nov 27 19:55:28 and it does use -lm Nov 27 19:55:32 let me look up the test code Nov 27 19:55:50 .o(why khem totally ignores what I am writing) Nov 27 19:56:06 woglinde_: because my scroll does not work on mac Nov 27 19:56:13 lol Nov 27 19:56:21 it garbles all screen windows Nov 27 19:56:24 in one Nov 27 19:56:27 :) Nov 27 19:56:31 and you paid 2000 bucks for such shit Nov 27 19:57:12 woglinde_: heh, it belongs to my wife Nov 27 19:57:47 here's the larger part from config.log http://pastebin.mozilla.org/1388591 Nov 27 19:58:22 and Ithink I found the macros too, one sec Nov 27 19:58:32 *sigh* again Nov 27 19:58:56 please pastebin the configure.ac code or the m4 macro code Nov 27 19:59:03 Jin^eLD: now are you using angstrom-bleeding ? Nov 27 19:59:08 on top of oe-core ? Nov 27 19:59:30 khem: no, core with angstrom-2010.x Nov 27 19:59:40 config.log dont help this much Nov 27 19:59:46 woglinde_: that's the macro from acinclude http://pastebin.mozilla.org/1388592 Nov 27 19:59:48 and configure.ac must be changed anyway Nov 27 20:00:51 woglinde_: here'S the configure.ac part, found that too http://pastebin.mozilla.org/1388593 Nov 27 20:02:22 hm Nov 27 20:02:24 onflicting types for built-in function 'isinf' Nov 27 20:03:55 yeah that too Nov 27 20:04:23 I never worked with those IEEE math things so not sure where it should be coming from and what those things are Nov 27 20:04:23 from isinf manpage Nov 27 20:04:25 isinf(): _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L; or cc -std=c99 Nov 27 20:04:31 Jin^eLD: does this http://pastebin.com/jCwiL5x3 compile and link with your new toolchain Nov 27 20:04:42 khem: let me test... Nov 27 20:06:06 * khem has been watching Federer Vs. Tsonga Nov 27 20:06:19 I wonder what beers does Federer drink Nov 27 20:07:11 khem why? Nov 27 20:07:15 where is the "cross" stuff in OE core? :) in classic I knew where to look for the cross copmiler Nov 27 20:07:24 in the tmp directory that is Nov 27 20:08:40 $TMPDIR/sysroot/x86_64-linux/usr/bin/arm-angstrom-linux-gnueabi-gcc/arm-angstrom-linux-gnueabi-gcc Nov 27 20:09:29 stupid google search Nov 27 20:09:36 how to include "-ieee" Nov 27 20:09:44 hahaha Nov 27 20:10:24 hmm not quite, I don't have an arm-angstrom-linux-gnueabi-gcc in this dir, still looking... Nov 27 20:10:34 nothing can start with a - that can take you to google's intranet so its blocked :) Nov 27 20:10:58 just do a find for arm-angstrom-linux-gnueabi-gcc in that native sysroot Nov 27 20:11:35 already on it... Nov 27 20:12:25 ok finally found it :> Nov 27 20:12:28 http://gcc.gnu.org/wiki/FloatingPointMath Nov 27 20:12:56 so rewrite or extend the macro yourself Nov 27 20:13:10 khem: your code works Nov 27 20:13:12 maybee there is already a bugfix for rrdtool Nov 27 20:15:49 khem fpclassify is not the real problem Nov 27 20:16:25 woglinde_: does not look like it, I already took some fixes from trunk for configure and also sent them a patch to fix some things, but IEE was not there unfortunately... Nov 27 20:19:30 khem: hmm, I don't get it, your code is exactly the same that is used in configure in AC_LINK_IFELSE...? Nov 27 20:19:40 how come that compiling it standalone works, but fails from configure? Nov 27 20:20:15 or are these the #define things that woglinde_ mentioned... Nov 27 20:24:22 fpclassify is found anyway Nov 27 20:24:23 doh, I think I was wrong anyway, it finds fpclassify in the second attempt Nov 27 20:24:26 yes! Nov 27 20:24:40 it's the AC_FULL_IEEE macro that is failing Nov 27 20:24:49 http://gcc.gnu.org/wiki/FloatingPointMath#x86note Nov 27 20:24:54 ups Nov 27 20:25:00 http://gcc.gnu.org/wiki/FloatingPointMath Nov 27 20:25:27 yeah I was reading that but obviously I did not understand the meaning :) Nov 27 20:26:02 so actually I am missing the right switch Nov 27 20:26:08 yes Nov 27 20:26:11 -ieee is gone Nov 27 20:26:31 and beaware of Nov 27 20:26:33 -fsignaling-nans is still experimental and may not disable all optimizations that affect signaling NaN behavior. Nov 27 20:27:10 do I need both? -frounding-math and -fsignaling-nans ? Nov 27 20:27:34 I would say run with -frounding-math Nov 27 20:27:40 and that should be okay Nov 27 20:37:08 hmm still does not work Nov 27 20:37:17 to be honest I do not quite understand this AC_FULL_IEEE macro Nov 27 20:37:26 that macro was broken Nov 27 20:37:49 yes, I added the parameters that woglinde_ suggested Nov 27 20:37:57 but I do not see it doing anything useful, not in config.log at least Nov 27 20:37:59 sure Nov 27 20:38:04 do you mean the macro is broken as a whole? Nov 27 20:38:08 we need definition of AC_IEEE Nov 27 20:38:13 macro Nov 27 20:38:52 pasted it already, already looking into it http://pastebin.mozilla.org/1388592 Nov 27 20:40:04 seems to be broken as I do not see the code that this macro should be compiling in the config.log Nov 27 20:41:27 uhm sorry Nov 27 20:41:32 didnt see it was above Nov 27 20:42:26 hm try to compile it in your own file Nov 27 20:42:36 indeed Nov 27 20:42:46 it's just strange that it's not appearing as a failed program in config.log at all Nov 27 20:42:52 and see whats happening Nov 27 20:44:33 hm or you set the macro default to yes Nov 27 20:44:47 rd_cv_ieee_works=yes Nov 27 20:44:51 via site info Nov 27 20:45:14 and force the flags to the new gcc stuff hmm Nov 27 20:45:37 first try to compile it Nov 27 20:45:40 and see whats happen Nov 27 20:45:44 yeah that's what I am doing now Nov 27 20:47:30 ok first error - clearly missing math.h include for sin() Nov 27 20:48:20 an then it does not even work on the host Nov 27 20:52:11 hmm funny, it works from within configure on the host, but not if I try it "standalone" Nov 27 20:53:09 hm Nov 27 20:53:19 crosscompiler broken? Nov 27 20:53:36 no I mean - if I try it on the host, not with the crosscompiler, but with my gcc Nov 27 20:53:40 native gcc for my host Nov 27 20:53:47 I still can not get it to work Nov 27 20:54:04 I mean the piece of code that I extracted from the macro Nov 27 20:54:19 however it does work from within configure, on the host, just by doing ./configure (no cross things involved) Nov 27 20:56:40 I guess I'll try to just patch it out Nov 27 21:03:37 hack works, have to test the software though, hope there are no bad implications onthe code Nov 27 21:04:17 thank for all the pointers btw Nov 27 21:42:43 anarsoul: thanks, have updated meta-hh now Nov 27 21:42:55 btw does OE support dietlibc? Nov 27 21:43:26 jineld a bit Nov 27 21:43:46 but I didnt update the recipe for a long time Nov 27 21:44:18 I see... friend of mine is trying out OE, hence the question... Nov 27 21:44:26 not sure why he needs it though Nov 27 21:45:12 woglinde_: I assume your recpie was written for OE classic? Nov 27 21:46:17 yes Nov 27 21:46:38 found it already Nov 27 21:49:48 bluelightning: no pb Nov 27 21:56:43 bluelightning: I have some extra patches for h1940 (DMA-related), they need some extra testing, but I can send them to you Nov 27 22:02:13 anarsoul: sure, I can't promise to test them immediately though Nov 27 22:19:16 is dietlibc even maintained? Nov 27 22:20:26 no idea... Nov 27 22:20:53 my buddy did not really tell the reasons why he wanted to use it, just said there were some good reasons and I did not ask any further :) Nov 27 22:23:35 but it indeed looks abandoned **** ENDING LOGGING AT Mon Nov 28 02:59:56 2011