**** BEGIN LOGGING AT Wed Jan 17 02:59:57 2007
Jan 17 07:08:42 <hrw> Laibsch: bitbake -i;parse;getvar MACHINE_FEATURES
Jan 17 07:13:55 <Cockroach-> Morning
Jan 17 07:16:18 <Cockroach-> lardman|gone: Well, not much progress. I've tried to figure out how to install the kernel modules somewhere else than /lib/modules in the .jffs2 image
Jan 17 10:28:01 <XorA> all quiet on the Angstrom front this morning then
Jan 17 10:31:21 <_law_> XorA, yes my bluetooth works now ;-)
Jan 17 10:38:39 <XorA> _law_: I saw
Jan 17 10:38:47 <XorA> ~lart bluetooth
Jan 17 11:42:29 <lardman> Cockroach-: If you flash the rootfs with the modules in /lib/modules, are they visible (or does it not boot)?
Jan 17 11:42:54 <lardman> Cockroach-: what are the modules we're talking about anyway, could you install them manually after flashing the rootfs?
Jan 17 12:05:19 <Cockroach-> lardman: the modules in /lib/modules are not visible because the initfs seems to symlink /mnt/initfs/lib/modules to /lib/modules
Jan 17 12:05:59 <Cockroach-> the initfs of course is the one supplied in the original maemo Fiasco-image
Jan 17 12:08:16 <Cockroach-> ... I might be wrong when saying "symlink", but anyway when the device has booted, I cannot access the /lib/modules which was in my OE built .jffs2
Jan 17 12:12:56 <lardman> Cockroach-: I wonder what would happen if you deleted the symlink...?
Jan 17 12:13:15 <Cockroach-> then there would be no /lib/modules
Jan 17 12:13:19 <lardman> (after copying the modules contained therein somewhere else first)
Jan 17 12:13:45 <lardman> Is that what happens with symlinks to directories? I thought the underlying directory would then be exposed?
Jan 17 12:14:25 <Cockroach-> That's why I said I'm not sure if "symlinked" is what is actually done, since the /lib/modules in .jffs2 still stays hidden
Jan 17 12:14:44 <lardman> ah, okay
Jan 17 12:14:52 <lardman> What are the modules you want to use from the rootfs?
Jan 17 12:15:29 <lardman> Could you manually install them elsewhere?
Jan 17 12:15:39 <lardman> (I know it's a bit messy)
Jan 17 12:17:10 <Cockroach-> Well I have problems with getting the fbdev to work, so I've compiled it as a kernel module. I just thought I might get more verbose error message when trying to load it, instead of it being compiled in the kernel.
Jan 17 12:17:39 <lardman> Ah yes, I remember you saying that
Jan 17 12:17:48 <Cockroach-> And I'm trying to create the .jffs2 image so that the modules would be somewhere else, I suppose I need to modify the INSTALL_MOD_PATH 
Jan 17 12:18:31 <lardman> It would be nicer if /lib/modules could be moved to the rootfs, but it's not a major priority I don't think
Jan 17 12:18:53 <lardman> So what problems are you having with the fb? Are you using a gpe-image?
Jan 17 12:19:08 <lardman> Still the problem with the xserver?
Jan 17 12:20:09 <Cockroach-> I couldn't get the angstrom-xserver-image to compile (the xserver-kdrive-omap dependencies-issue) so I just first built the angstrom-bootstrap-image. 
Jan 17 12:21:20 <Cockroach-> the bootstrap image builds and it's supposed to have the framebuffer active, but I get errors on boot "Unable to open frame buffer device /dev/fb0" several times
Jan 17 12:21:56 <lardman> hmm, I wonder what's changed between this and the previous familiar based images
Jan 17 12:24:25 <Cockroach-> as far as the Xserver issue goes, I did google up some oe mailinglist conversation which stated that 770 build will be broken. Some required packages are moved to org.openembedded.dev/packages/obsolete/freedesktop-premodular-xlibs/ but I could not get things to work even when trying to use them.
Jan 17 12:24:47 <koen> nokia has sources for the xorg versions of those
Jan 17 12:25:37 <lardman> The other option is to build the xserver manually and add it to the ASSUME_PROVIDED list
Jan 17 12:25:46 <Cockroach-> But if the "normal" kdrive & fb should work in 770, I would like to try to get that to work. 
Jan 17 12:26:08 <lardman> Ah, but it may require some starup magic to get it to work
Jan 17 12:26:32 <lardman> I was wondering whether there would also be fb warnings produced in the older familiar images
Jan 17 12:27:20 <Cockroach-> I'm just wondering why the "vanilla" bootstrap-image which does compile OK straight out from OE metadata (well ok, had to change the preferred gcc compiler version) does boot but complains about the framebuffer and also something about udev
Jan 17 12:28:46 <lardman> I see mention of omapfb in dmesg on my 770 running Maemo
Jan 17 12:30:15 <lardman> Is this the name of your kernel module?
Jan 17 12:32:45 <Cockroach-> I'll check, hold on. Have to rebuild virtual/kernel first
Jan 17 12:35:17 <koen> lardman: the trouble is the epson chip driving the actual lcd
Jan 17 12:35:37 <lardman> koen: Ah, okay. Why did things work before then?
Jan 17 12:36:14 <koen> lardman: there should be a kernel feature that enables auto-update of the lcd
Jan 17 12:36:31 <koen> lardman: without that switch you need Xomap to tell the epson to update the lcd
Jan 17 12:37:10 <lardman> ok
Jan 17 12:37:38 <koen> with that switch you can use plain kdrive
Jan 17 12:39:59 <lardman> the source is available though is it not? (for the Epson chip and the Xomap server)
Jan 17 12:42:43 <koen> yes
Jan 17 12:43:15 <koen> OE needs 2 new things: the lcd backbuffer switch enabled in the kernel defconfig and and update Xomap
Jan 17 12:43:37 <lardman> okay
Jan 17 12:44:38 * lardman needs to fix his subversion issues and download the Angstrom metadata
Jan 17 12:44:47 <lardman> lunch time
Jan 17 12:44:49 <koen> subversion?
Jan 17 12:44:50 <koen> eeew
Jan 17 12:45:03 <koen> lardman|lunch: angstrom is in OE mtn :)
Jan 17 12:45:41 <lardman|lunch> ~lart me
Jan 17 12:45:45 <lardman|lunch> not subversion, monotone
Jan 17 12:46:12 <lardman|lunch> Mandrake update didn't update correctly, monotone falls over
Jan 17 12:46:34 <lardman|lunch> Serve me right for letting someone else build it for me
Jan 17 12:49:39 * koen uses the static builds from venge.net/monotone
Jan 17 12:57:10 * XorA does too
Jan 17 13:16:10 <_law_> juhuu bluetooth works after suspend/resume again :-)
Jan 17 13:18:08 <_law_> with nokia dtl1_cs :-)
Jan 17 13:46:30 * XorA will have to try and get his BT card working again
Jan 17 13:46:35 <XorA> or use usb-bt
Jan 17 13:53:07 <den-ros> hi all
Jan 17 14:01:09 <Cockroach-> yo
Jan 17 14:01:19 <Cockroach-> hmm
Jan 17 14:01:28 <Cockroach-> I got travel-fever :P
Jan 17 14:01:41 <Cockroach-> Well, there is only one cure for it
Jan 17 14:04:31 <Cockroach-> Perhaps I can find some 2nd hand Zauruses this time. Too bad I don't know much japanese
Jan 17 14:09:03 <Laibsch> Cockroach-: What do you need the Japanese for?
Jan 17 14:09:52 <Cockroach-> Laibsch: people there tend to talk even less and worse english than Borat
Jan 17 14:10:03 <Laibsch> Going to Japan?
Jan 17 14:10:18 <Cockroach-> If everything goes as planned
Jan 17 14:10:32 <Cockroach-> Finnair has a nice campaign at the moment
Jan 17 14:11:09 <Laibsch> Really?
Jan 17 14:11:14 <Laibsch> TEll me more?
Jan 17 14:11:19 <Laibsch> I might be going , too
Jan 17 14:11:27 <Laibsch> I was planning about alitalia
Jan 17 14:11:31 <Laibsch> Private chat?
Jan 17 14:11:34 <Laibsch> brb
Jan 17 14:11:44 <Cockroach-> Well, Helsinki - Osaka - Helsinki ticket 465e
Jan 17 14:12:22 <Cockroach-> Maybe next time, I got to go home. I'm being expected by my car so don't want to keep people waiting. ->
Jan 17 14:12:45 <Laibsch> AMAZING!
Jan 17 14:45:43 * lardman has installed this that and the other and is currently building angstrom-gpe-image
Jan 17 14:46:00 <lardman> ~lart psycho for not supporting x86_64
Jan 17 14:46:20 <hrw|work> psyco?
Jan 17 14:46:42 <lardman> hrw|work: Python JIT tool I think
Jan 17 14:46:48 <lardman> Used by bitbake
Jan 17 14:46:52 <hrw|work> I know
Jan 17 14:47:02 <lardman> ah, sorry, spelling
Jan 17 14:47:08 <lardman> I'm stunned at the speed of cache re-read, ~1s
Jan 17 14:48:07 <lardman> Also quite nice to run bitbake on a dual core with 2Gb of RAM & 8Mbit/s link, a relevation in fact :)
Jan 17 14:48:18 <hrw|work> dual core...
Jan 17 18:31:18 <lardman|home> hmm, I've got module-init-tools-cross-3.2.2-r2 failing to build
Jan 17 18:31:23 <lardman|home> any ideas?
Jan 17 18:36:42 <lardman|home> "/usr/bin/ld: cannot find -lc" to be exact
Jan 17 18:38:45 <Laibsch> lardman|home: Let me see if I get the same problem
Jan 17 18:39:56 <Laibsch> BB>> getvar MACHINE_FEATURES
Jan 17 18:39:56 <Laibsch> kernel24 apm pcmcia screen irda
Jan 17 18:40:11 <Laibsch> hrw: Sorry, I am late to reply.  I was out most of today.
Jan 17 18:41:08 <lardman|home> Laibsch: Thanks
Jan 17 18:50:13 <lardman|home> Curious, module-init-tools-cross shows DEFAULT_PREFERENCE = "0"
Jan 17 18:50:47 <lardman|home> I wonder why it's specified in the nokia770's conf file?
Jan 17 18:51:14 <hrw> re
Jan 17 18:51:19 <lardman|home> hi hrw
Jan 17 18:51:33 <hrw> Laibsch: edit local.conf and set MACHINE_KERNEL_VERSION = "2.6"
Jan 17 18:51:37 <hrw> Laibsch: then rebuild
Jan 17 18:52:04 <lardman|home> hrw: Any ideas on my little gem?
Jan 17 18:52:44 <hrw> lardman|home: m-i-t-cross failure one?
Jan 17 18:52:55 <lardman|home> hrw: yep
Jan 17 18:53:02 <hrw> works for me
Jan 17 18:53:08 <lardman|home> hmm
Jan 17 18:53:16 <hrw> lardman|home: you have libc6-dev on host system?
Jan 17 18:54:10 <lardman|home> ah, looks like I don't
Jan 17 18:54:20 <lardman|home> perhaps I should re-read the required software page
Jan 17 18:54:34 <hrw> ;D
Jan 17 18:56:13 <lardman|home> no, looks like I do have glibc-devel
Jan 17 18:56:34 * lardman|home has always wondered about the difference between libc and glibc
Jan 17 18:57:05 <hrw> uclibc also provide libc
Jan 17 18:57:10 <hrw> bsd provide own libc
Jan 17 18:57:17 <lardman|home> g stands gor gnu?
Jan 17 18:57:22 <hrw> yes
Jan 17 18:58:09 <lardman|home> The actual error message I get is odd: /usr/bin/ld: cannot find -lc
Jan 17 18:58:29 <hrw> lardman|home: can you compile helloworld.c on host?
Jan 17 18:58:31 <lardman|home> I guess that may mean I don't have a static libc library
Jan 17 18:58:38 <lardman|home> hrw: yep
Jan 17 18:58:53 <hrw> then something is fucked
Jan 17 18:59:52 <lardman|home> I'm on x86_64
Jan 17 19:00:16 <lardman|home> I see that libc doesn't live in the standard location, I wonder if that's it
Jan 17 19:00:20 <hrw> I'm too
Jan 17 19:00:24 <lardman|home> oh
Jan 17 19:00:54 <hrw> but arm build here only for .oz354x
Jan 17 19:02:38 <lardman|home> I just tried linking /usr/lib/libc_nonshared.a to libc.a, but now it complains: /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
Jan 17 19:03:15 <lardman|home> as this is part of the insmod.static section in the Makefile
Jan 17 19:03:18 <hrw> it is /lib/libc rather
Jan 17 19:03:39 <hrw> no .dev arm build here
Jan 17 19:04:51 <lardman|home> hrw: thanks anyway
Jan 17 19:04:55 <hrw> np
Jan 17 19:05:46 <lardman|home> Why is depmod required to be built anyway?
Jan 17 19:06:05 <hrw> dependencies in modules
Jan 17 19:06:16 <lardman|home> But -native ?
Jan 17 19:06:17 <hrw> they are created by depmod or modinfo output parsing
Jan 17 19:06:23 <hrw> native?
Jan 17 19:06:40 <lardman|home> Ah, it;s cross, ignore me
Jan 17 19:08:37 <lardman|home> So is it looking for a native -lc, or a cross -lc?
Jan 17 19:08:44 <hrw> native
Jan 17 19:08:54 <hrw> native and cross use host environment
Jan 17 19:18:56 <lardman|home> What does ld use to determine its search directories?
Jan 17 19:19:11 <hrw> -Ldir -Ldir2 and gcc specs
Jan 17 19:19:38 <lardman|home> okay, I'll try some hacking at the .run file
Jan 17 19:24:38 <lardman|home> hmm altering the .run file doesn't propogate
Jan 17 19:24:57 <lardman|home> and sylinking into the existing -L location doesn't make any difference
Jan 17 19:25:13 <hrw> .run is generated each time
Jan 17 19:25:26 <lardman|home> I ran it explicitly
Jan 17 19:25:29 <hrw> ah
Jan 17 19:28:40 <Laibsch> hrw: Thanks
Jan 17 19:29:49 <hrw> Laibsch: 2.6 on collie is not tested from OE so machine is configured to be 2.4 
Jan 17 19:31:04 <Laibsch> hrw: I guess you were talking about 
Jan 17 19:31:10 <Laibsch> !oebug 1794
Jan 17 19:31:11 <Laibsch> ?
Jan 17 19:31:12 <cdbot2> * * Bug 1794, Status: NEW, Created: 2007-01-16 19:56
Jan 17 19:31:13 <cdbot2> * * bugs.openembedded.org(AT)rolf.leggewie.biz: esound-gpe crashes bitbake
Jan 17 19:31:14 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=1794
Jan 17 19:32:00 <hrw> no
Jan 17 19:32:23 <Laibsch> Cockroach-: Are you still there?  Do you have a minute for a private chat about those great tickets to Japan?
Jan 17 19:33:18 <Laibsch> http://rafb.net/p/0zD4Ke53.html, I guess?
Jan 17 19:33:53 <Laibsch> hrw: Your question was about my failed hostap-modules for angstrom, right?
Jan 17 19:34:02 <hrw> yes
Jan 17 19:34:21 <Laibsch> OK, made the changes.  Restarted compilation.
Jan 17 19:34:28 <Laibsch> But maybe you can bake an image for me?
Jan 17 19:34:41 <Laibsch> I think it will take my computer a couple of days.
Jan 17 19:34:52 <hrw> Laibsch: 2.6 one?
Jan 17 19:35:02 <Laibsch> Either way suits me fine.
Jan 17 19:35:23 <Laibsch> 2.4 has the advantage of SD available, but this is purely for testing purposes anyway.
Jan 17 19:35:33 <hrw> w8 a moment then
Jan 17 19:35:34 <Laibsch> 2.4 I could run as altboot image, right?
Jan 17 19:35:55 <Laibsch> Then I think 2.4 would be easier for me since I can kind without constant reflashing.
Jan 17 19:36:13 <lardman|home> wierd, when I simply cd to the correct directory and copy the failing command line, it still fails, even if I add -L/lib
Jan 17 19:36:21 <hrw> I can build 2.6 image in <hour
Jan 17 19:38:59 <Laibsch> hrw: Then go ahead.
Jan 17 19:39:06 <Laibsch> Looking forward to it.
Jan 17 19:41:03 <lardman|home> In angstrom-2007-1.conf there is the line: PREFERRED_VERSION_glibc ?= "2.5", but I keep getting NOTE: preferred version 2.5 of glibc not available
Jan 17 19:41:14 <lardman|home> Is this expected behaviour?
Jan 17 19:41:16 <Laibsch> lardman|home: Sorry to keep you waiting.  I had no trouble compiling module-init-tools-cross, version 3.2.2-r2 which is the same as yours.
Jan 17 19:41:38 <hrw> lardman|home: yes
Jan 17 19:42:29 <lardman|home> hrw: shame :(
Jan 17 19:42:33 <lardman|home> Laibsch: thanks for trying
Jan 17 19:50:03 <lardman|home> Last shot, can anyone see the problem with this command?: http://pastebin.ca/319824
Jan 17 19:52:04 <hrw> I'm rebuilding m-i-t now on rhel system
Jan 17 19:53:00 <hrw> NOTE: package module-init-tools-3.2.2-r2: task do_rebuild: completed
Jan 17 19:54:05 <hrw> ccache arm-angstrom-linux-gcc -march=armv4 -mtune=xscale  -isystem/a/home/hrw/devel/build/angstrom/tmp/staging/arm-angstrom-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -Wunused -Wall  -L/a/home/hrw/devel/build/angstrom/tmp/staging/arm-angstrom-linux/lib -Wl,-rpath-link,/a/home/hrw/devel/build/angstrom/tmp/staging/arm-angstrom-linux/lib -Wl,-O1 -o insmod.static -static insmod.o  
Jan 17 19:54:24 <hrw> why it used arm gcc?
Jan 17 19:56:04 <lardman|home> hmm
Jan 17 19:56:27 <lardman|home> m-i-t-cross?
Jan 17 20:15:00 <lardman|home> hrw: did you see my comment? I'm having issues with module-init-tools-cross-3.2.2-r2, not module-init-tools
Jan 17 20:15:27 <hrw> ah. sory
Jan 17 20:16:18 <hrw> NOTE: package module-init-tools-cross-3.2.2-r2: task do_rebuild: started
Jan 17 20:18:34 <hrw> NOTE: package module-init-tools-cross-3.2.2-r2: task do_rebuild: completed
Jan 17 20:18:53 <lardman|home> hrw: That's your 64bit system?
Jan 17 20:19:15 <hrw> that was on i686 one
Jan 17 20:19:25 <hrw> I will look at my amd64
Jan 17 20:19:31 <lardman|home> ah, okay, thanks
Jan 17 20:19:49 * lardman|home wonders whether opting for x86_64 was such a good idea
Jan 17 20:20:26 <hrw> for me amd64 was cheaper then going into faster i686
Jan 17 20:21:12 <lardman|home> I've got a Core 2 Duo
Jan 17 20:22:03 <hrw> core2duo == new mainboard, cpu, memory
Jan 17 20:22:09 <lardman|home> but no flash (not a bad thing most of the time, and I could install 32bit firefox), no psyco, qemu problems, etc
Jan 17 20:22:15 <hrw> amd64 == new mainboard, cpu, old memory
Jan 17 20:22:36 <lardman|home> hrw: Yep, I needed an upgrade though. My old PC was 1.4GHz w/ 256Mb of RAMBUS
Jan 17 20:22:51 <hrw> rambus... argh
Jan 17 20:22:53 <lardman|home> it was a mistake opting for that memory
Jan 17 20:23:01 <hrw> I had once worst machine
Jan 17 20:23:32 <hrw> <1GHz pentium + i820 + MTH + sdram
Jan 17 20:23:50 <hrw> MTH = memory translation hub (sdram -> i820 (rambus chipset))
Jan 17 20:23:50 <lardman|home> MTH?
Jan 17 20:23:55 <lardman|home> ah :)
Jan 17 20:24:07 <hrw> shit total
Jan 17 20:24:18 <lardman|home> urgh, at least the memory was cheap though
Jan 17 20:24:33 <hrw> I had 128M ram because company admins were unable to find any memory which this mainboard will accept
Jan 17 20:24:40 <lardman|home> too old?
Jan 17 20:25:06 <hrw> too shitty - ram needed to be exaclty selected
Jan 17 20:25:21 <hrw> and no one had a time and heap of ram sticks to test
Jan 17 20:26:48 <lardman|home> Cockroach-: You about? Is the init symlink (iirc) patch built-ing for the nokia770 builds? (if I ever get mine to work!)
Jan 17 20:27:09 <hrw> lardman|home: it was in sysvinit iirc added
Jan 17 20:27:09 <lardman|home> s/built-ing/built-in
Jan 17 20:27:32 <lardman|home> hrw: cool, just thinking about the next hurdle
Jan 17 20:35:03 <hrw> Laibsch: it will take more time - my last collie build was not success so I have to rebuild most of image
Jan 17 20:36:27 <Laibsch> hrw: no problem.
Jan 17 20:36:43 <Laibsch> If you can make a 2.4 image, I think that would make it easier for me.
Jan 17 20:41:51 <hrw> Laibsch: 2.4 image I will make for OZ 3.5.5 during next week/two
Jan 17 21:05:07 <Laibsch> hrw: The compilation for my collie image aborted yesterday and I think you will likely hit the same issue.
Jan 17 21:05:22 <Laibsch> http://rafb.net/p/0zD4Ke53.html
Jan 17 21:06:01 <Laibsch> hostap will not build
Jan 17 21:06:40 <hrw> 17 20:22 < hrw> Laibsch: edit local.conf and set MACHINE_KERNEL_VERSION = "2.6"
Jan 17 21:06:43 <hrw> 17 20:22 < hrw> Laibsch: then rebuild
Jan 17 21:07:33 <Laibsch> Did not do it.
Jan 17 21:08:07 <Laibsch> Or do I need to clean out tmp?
Jan 17 21:08:07 <Laibsch> Sorry about getting confused what resolution was addressing what issue.
Jan 17 21:08:18 <Laibsch> Fact is just that it still does not build.
Jan 17 21:09:08 <Laibsch> "*** Can't build for 2.6 with a non-2.6 source!" from hostap
Jan 17 21:12:13 <hrw> edit and run build
Jan 17 21:12:34 <Laibsch> That is what I did (and redo now)
Jan 17 21:12:40 <Laibsch> But it just did not do it.
Jan 17 21:13:40 <hrw> show me MACHINE_FEATURES
Jan 17 21:14:15 <Laibsch> brb
Jan 17 21:19:59 <hrw|gone> cu
Jan 17 21:36:39 <Laibsch> hrw|gone: kernel26 apm pcmcia screen irda usbgadget keyboard touchscreen
Jan 17 22:19:27 <lardman|home> koen: ping
Jan 17 22:21:56 <lardman|home> koen: Do you still have a c700? Interesting bug #1801
Jan 17 22:26:35 <hvontres|poodle> !oebug 1801
Jan 17 22:26:37 <cdbot2> * * Bug 1801, Status: NEW, Created: 2007-01-17 14:49
Jan 17 22:26:38 <cdbot2> * * highpostsf-oz(AT)yahoo.com: contrast problem on SL-C700 w/ 3.5.4.1 OPIE
Jan 17 22:26:38 <cdbot2> * * http://bugs.openembedded.org/show_bug.cgi?id=1801
Jan 17 22:50:05 <lardman|home> XorA: Are you running on x86_64?
Jan 17 23:02:16 <XorA> whoever spoke to me, my machine crashed so I never saw message
Jan 17 23:11:47 <lardman|home> XorA: 'twas me
Jan 17 23:11:57 <lardman|home> I was asking whether you're building on x86_64
Jan 17 23:12:06 <XorA> lardman|home: yes, at work and at home
Jan 17 23:12:29 <_law_> btw. someone boots linux on a dell axim 51v :-) i also has one.. 
Jan 17 23:12:33 <lardman|home> hmm, have you had any issues building module-init-tools-cross-3.2.2-r2?
Jan 17 23:15:24 <XorA> lardman|home: nope, builds fine here
Jan 17 23:15:30 <XorA> lardman|home: I need sleep, shout at me tomorrow
Jan 17 23:16:09 <lardman|home> XorA|gone: Ok, night night
Jan 17 23:44:06 <lardman|home> night
**** ENDING LOGGING AT Thu Jan 18 02:59:57 2007