**** BEGIN LOGGING AT Fri Jun 10 23:59:57 2005 Jun 11 00:00:50 hi ljp I headrd you were using the PDAudio card on a Zaurus Jun 11 00:27:59 hmm.. wll I have one. havent used it yet,. but I suppose that the pxa27x is fast enough to handle it Jun 11 00:28:30 not sure if the driver sources still compile Jun 11 00:30:49 and would need to resurrect my 'high end audio recorder for qtopia' :) Jun 11 00:54:09 good morning all Jun 11 00:59:58 sorry for the newbie question, I just flashed with a custom build opie-image, but when it boots up, it gives warning about kernel version mismatch. Jun 11 01:00:28 where can i find the correct build kernel in the openembedded directories? thanks Jun 11 01:02:47 it should be in the same dir as the images Jun 11 01:03:28 assuming you are building for a zaurus Jun 11 01:03:29 how would it be called? Jun 11 01:03:38 yes i am. Jun 11 01:03:51 zImage* or kernel* Jun 11 01:04:10 thanks. i might have accidentally deleted it. Jun 11 01:32:15 03pb 07 * r1.3539 10openembedded/ (4 files in 3 dirs): adjust some glibc patches Jun 11 01:36:36 morning all Jun 11 01:36:49 hi rp Jun 11 01:38:36 hey RP & pb_ Jun 11 01:44:05 hi RP Jun 11 01:44:09 hi pb_ Jun 11 02:13:11 03pb 07 * r1.3540 10openembedded/packages/xserver/xserver-xorg_6.8.99.5.bb: avoid problems with imake and ccache Jun 11 02:32:51 moin Jun 11 02:32:57 hey CoreDump|home Jun 11 02:34:35 * CoreDump|home hugs "noatime" Jun 11 02:34:48 and async? Jun 11 02:35:49 pb_: ping Jun 11 02:35:51 CoreDump|home: http://funroll-loops.org/ features a bit on noatime too Jun 11 02:35:54 moin zecke Jun 11 02:35:54 zecke: at your service Jun 11 02:35:55 that, too. But I was talking about my desktop ATM :) The performence increase is very notable Jun 11 02:36:24 * CoreDump|home looks Jun 11 02:37:00 CoreDump|home, which fs ? Jun 11 02:37:00 pb_: If I've a pipe between two processes and one process writes to it and then exits Jun 11 02:37:36 pb_: will that information be lost when I do waitpid on the process? Jun 11 02:38:01 XFS, I ran some self-made benchmarks yesterday and wondered why they were worse than the same benchmarks on the same disks done a few month ago. I forgot to use noatime :) Jun 11 02:39:17 pb_: and does a true socket (stream) have a different semantic? Jun 11 02:41:17 anyone know the implications of notail on reiserfs ? better performance and less storage efficiency are what the docs say, but I wonder how much in each case Jun 11 02:41:54 zecke: no, the data will sit in the pipe buffer until either you read it, or the reader exits. Jun 11 02:42:14 jacques: not me, sorry. I've been burned by reiserFS in the past and avoid it like the plaque Jun 11 02:42:48 pb_: ok that is what I expected, but I do not get the data :} Jun 11 02:42:56 read on the fd fails Jun 11 02:43:21 oh, hm, odd Jun 11 02:44:23 * zecke needs to look at the errno Jun 11 02:49:23 pb_: OT: did you ever looked at vuftpd? Jun 11 02:49:38 pb_: it is the first app I know passing fd's through processes Jun 11 02:50:12 no, I never looked at that Jun 11 02:51:22 pb_: it is funky. You've 'one' in some way priviledge server. It opens a file on request and passes the fd to the socket Jun 11 02:51:43 pb_: so even if there is a parser bug and something goes wrong in a slave Jun 11 02:51:52 pb_: it can just do what it was supposed to do anyway Jun 11 02:52:39 ah, I see. cute. Jun 11 02:53:35 am I here? o.o Jun 11 02:53:51 Luke-Jr: no, you're imagining it Jun 11 02:54:16 koen: thanks. can you get to http://utopios.org ? o.o Jun 11 02:54:34 Lightning here... IRC is the only thing that seems to be working >.> Jun 11 02:54:47 Luke-Jr: it seems to be loading Jun 11 02:55:03 koen: thanks :) Jun 11 02:55:18 guess I can go back to sleep since the server stuff works Jun 11 02:59:49 03pb 07 * r1.3541 10openembedded/packages/qemu/ (qemu-native_0.7.0.bb qemu_0.7.0.bb): add qemu, a generic and open source processor emulator Jun 11 03:00:09 ah, nice Jun 11 03:04:34 pb_: qemu stuff split into arch pkgs? o.o Jun 11 03:18:58 Morning Jun 11 03:20:53 Compiling qte-2.3.10 using bitbake, I've noticed strange warnings during libqte linking stage Jun 11 03:21:05 A lot of warnings like these: Jun 11 03:21:13 /export/home/oe/tmp/cross/lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld: Warning: size of symbol `QXmlAttributes::~QXmlAttributes()' changed from 848 in allmoc.o to 484 in xml/qxml.o Jun 11 03:21:58 It's only a warning, but that symbol size mismatch seems not sane Jun 11 03:23:26 Could someone look at his log.do_compile.whatever to see if he's experimenting the same warnings? Jun 11 03:29:23 03pb 07 * r1.3542 10openembedded/packages/glibc/ (3 files in 2 dirs): fix up glibc HEAD build Jun 11 03:35:26 morning Jun 11 03:35:43 SirFred: yeah, let me start a build from scratch. That'll take a while Jun 11 03:35:51 mickeyl: Thanks. Jun 11 03:35:52 hi mickey Jun 11 03:36:15 mickeyl: It is just a warning, and perhaps my toolchain is messed up. Jun 11 03:37:54 morning mickeyl Jun 11 03:37:58 morning CoreDump|home Jun 11 03:39:15 ljp: any idea when rc1 will be out for mere mortals ? Jun 11 03:39:38 mickeyl: it is Jun 11 03:39:42 mickeyl: but not for QtE Jun 11 03:39:52 mickeyl: qt*desktop*rc1* Jun 11 03:39:53 fair enough. i'm not interest in the E version Jun 11 03:39:54 :D Jun 11 03:40:03 last nights build failed here with latest bk oe and latest svn bitbake Jun 11 03:40:27 Spyro: that's too bad Jun 11 03:40:37 | /tmp/ccXr0q6K.s: Assembler messages: Jun 11 03:40:37 | /tmp/ccXr0q6K.s:140: Error: bad instruction `stfpls f5,[sp,#0]' Jun 11 03:40:37 | /tmp/ccXr0q6K.s:391: Error: bad instruction `ldfpls f1,[sp,#0]' Jun 11 03:40:37 | make[2]: *** [/home/ian/projects/openembedded/stuff/tmp/work/glibc-2.3.2+cvs20040726-r17/build-arm-linux/math/e_j0f.o] Error 1 Jun 11 03:41:00 * koen sees asm and runs Jun 11 03:43:02 hi Jun 11 03:43:08 hey molivier Jun 11 03:43:21 koen, hi Jun 11 03:43:32 mickeyl: What amazing news could we expect from Qt4 ? Jun 11 03:43:55 i ve got such error when building package: libgcc_s.so uses hardware FP, whereas gpe-edit uses software FP Jun 11 03:44:00 how to solve this ? Jun 11 03:44:39 did you change TARGET_FPU between build? Jun 11 03:44:58 ok i have just see this, i must have target_fpu so tosft Jun 11 03:45:13 s/tosdt/soft/ Jun 11 03:45:13 mickeyl: I've seen that the driver adaptor from SciTech has been added to qte-2.3.10 Jun 11 03:45:15 SirFred: a lot of good things. finally some more sophisticated design patterns Jun 11 03:45:39 SirFred: MVC things, iterators, new rendering architecture Jun 11 03:45:50 yes, scitech has been added in 2.3.8 or 2.3.9 Jun 11 03:46:04 mickeyl: They have no driver for the W100, unfortunately. Jun 11 03:46:15 yeah. Jun 11 03:46:32 koen, so i must suppress TARGET_FPU variable, correct ? Jun 11 03:47:00 SirFred: I personally lost pretty much all interest in Qt/Embedded though, I hope that kdrive gets w100 accelleration soon Jun 11 03:47:41 mickeyl: So, you think the future is a kdriver xserver and qt on X ? Jun 11 03:47:49 mickeyl: the Qt4 licensing model seems to be finalized Jun 11 03:47:54 SirFred: That's what I - again personally - think Jun 11 03:47:57 mickeyl: Qt console, Qt ???, Qt Desktop Jun 11 03:47:58 zecke: oh interesting. Jun 11 03:48:08 zecke: where can i read that? Jun 11 03:48:24 mickeyl: Anyway, what's the difference among the different qt versions? Jun 11 03:48:45 SirFred: you mean E and X11 or 2.x, 3.x, 4.x? Jun 11 03:48:45 mickeyl: The qt/embedded is based on the QWS model and is stripped out of a lot of features. Jun 11 03:48:51 mickeyl: http://www.trolltech.com/newsroom/announcements/00000207.html Jun 11 03:48:54 mickeyl: E and X11. Jun 11 03:48:56 zecke: thanks Jun 11 03:48:57 mickeyl: not too much Jun 11 03:49:22 SirFred: you just answered that question. that's the difference Jun 11 03:49:29 SirFred: it's not missing features though Jun 11 03:49:34 that depends on how you build it Jun 11 03:49:41 mickeyl: Well, I miss some things like QT_TRANSFORMATIONS Jun 11 03:49:56 mickeyl: Well, of course, but if you want it to give a little footprint... Jun 11 03:49:56 yah sure, but if we would like to we could enable them Jun 11 03:50:05 we are no longer compatible with anything else anyway Jun 11 03:50:17 that's what why we have the compat libs Jun 11 03:50:20 s/what// Jun 11 03:50:28 mickeyl: mallum will do the w100 stuff after RP & sirfred finish decoding it Jun 11 03:50:29 mickeyl: I suppose the main reason to disable it is just that, the size. Jun 11 03:50:40 koen: excellent Jun 11 03:50:53 SirFred: yeah size. but the choice was pretty random Jun 11 03:50:54 koen: Well, I'm actually not decoding it. Jun 11 03:51:22 koen: I expected RP to do the dirty work. Jun 11 03:51:27 :) Jun 11 03:51:49 koen: I'm just trying to make the qte driver work. There are still a lot of missing things Jun 11 03:53:25 koen: But I'm basing it on the closed sharp library extracted from their libqte. Jun 11 03:53:42 koen: at the same time, RP is decoding that library. Jun 11 03:54:03 bbl Jun 11 03:55:12 mickeyl: So, you think that a driver for w100 under kdrive will be available soon ? Why? Jun 11 03:56:12 SirFred: i don't think, i hope. Jun 11 03:56:24 mickeyl: I think that the best thing will be a kernel framebuffer accelerated driver. Jun 11 03:56:35 mickeyl: So, both kdriver and qte could use that features. Jun 11 03:56:40 s/kdriver/kdriver/ Jun 11 03:56:42 s/kdriver/kdrive Jun 11 03:56:51 SirFred: don't you think that the framebuffer accelleration API is still pretty limited ? Jun 11 03:57:23 mickeyl: I didn't take a look at it. But I expected to found a good, complete fb API under 2.6 Jun 11 03:57:47 SirFred: it would mean both tweaking kernel and kdrive then Jun 11 03:57:58 *shrug* we'll see who does what :) Jun 11 03:58:29 mickeyl: Anyway, there's a lot of work involved into decoding and understanding w100. Jun 11 03:58:39 i have no doubts about that Jun 11 03:58:46 mickeyl: There's a lot of microcode based functions. I think that that's the worse. Jun 11 03:58:47 reverse engineering at its best Jun 11 04:00:09 mickeyl: I think that an early accelerated qte driver will be good, perhaps more people got involved. Jun 11 04:01:38 mickeyl: Just now, I was able to run an opie session under the accelerated driver, with some minor bugs. Jun 11 04:02:18 mickeyl: If I was able to make a patch and perhaps integrate it under bitbake, do you think that more people will contribute to fix those bugs? Jun 11 04:02:32 mickeyl: fix bugs/improve the driver. Jun 11 04:04:11 SirFred: It doubtful that more people will contribute, because there are no more people interested except us few. A patch would be good anyway to see the current state though. Jun 11 04:04:24 in other words - please do it :) Jun 11 04:05:04 mickeyl: I will need some help with bitbake. Jun 11 04:05:17 mickeyl: I'm porting my work to qte-2.3.10 Jun 11 04:05:31 mickeyl: Well, to the last openzaurus. Jun 11 04:05:40 very good. it's pretty easy to add patches to a program in bb Jun 11 04:06:03 mickeyl: OK. After testing the new libqte, I'll try to integrate it. Jun 11 04:06:18 mickeyl: But first, I will like to know if my toolchain is sane. Jun 11 04:06:38 mickeyl: I'll wait to your libqte build, to see if that warnings are caused by my setup. Jun 11 04:06:51 ya Jun 11 04:06:59 append_kernel24 Jun 11 04:07:07 is KERNEL_VERSION in the OVERRIDES variable? Jun 11 04:07:12 no Jun 11 04:07:21 not in oz builds though Jun 11 04:07:32 i think some familiar builds do that Jun 11 04:07:48 not KERNEL_VERSION, though h3900 does have ${KERNEL} in OVERRIDES. Jun 11 04:07:54 see h3900.conf Jun 11 04:08:39 hmm then the bug report looks valid Jun 11 04:08:51 03pb 07 * r1.3543 10openembedded/packages/dejagnu/ (dejagnu_1.4.4.bb dejagnu-native_1.4.4.bb): add DejaGNU, a framework for testing other programs Jun 11 04:08:57 what's the bug report? Jun 11 04:08:59 yay!!! Jun 11 04:09:16 that means we now have tcl and expect Jun 11 04:09:21 pb_: #77 Jun 11 04:09:30 jacques: ah, not as such. I didn't add them yet. Jun 11 04:09:40 pb_, d`oh :-) Jun 11 04:10:14 zecke: oh, yeah, I remember that one Jun 11 04:10:34 the report seemed to be so confused that I didn't have the strength to untangle it. Jun 11 04:11:25 afaict, his main complaint is that BOOTSTRAP_EXTRA_DEPENDS_append_kernel24 doesn't influence the Depends: field of task-bootstrap.ipk. Jun 11 04:11:39 which, of course, is expected; he would need to set RDEPENDS to achieve that. Jun 11 04:11:51 hehe okay Jun 11 04:12:01 obviously I did not read to carefully either Jun 11 04:12:15 the bit with H3900_MODULES might be a real bug, but it's hard to tell for sure from that report. Jun 11 04:13:41 afternoon Jun 11 04:14:09 jacques: I was just playing with running the gcc testsuite under qemu. Jun 11 04:15:09 pb_, sweet Jun 11 04:15:22 pb_: could you please have a look at bug #47? It affects poodle and collie, maybe all Z's and is caused by a busybox patch. Jun 11 04:15:23 I've messed with qemu a bit since they added armeb support Jun 11 04:15:47 CoreDump|home: assign it to me and I will take a look Jun 11 04:15:57 pb_: thanks :) Jun 11 04:20:47 ~lart bugzilla Jun 11 04:20:47 * ibot decapitates bugzilla conan the destroyer style Jun 11 04:21:00 isn't there a way to list all registered members? Jun 11 04:23:15 is there supposed to be a glibc_2.3.5.bb ? Jun 11 04:23:41 I see a glibc-cvs-2.3.5/ dir but no matching .bb Jun 11 04:24:28 that's for glibc_cvs.bb Jun 11 04:25:13 ah Jun 11 04:25:19 does beep build ok at the moment? Jun 11 04:26:19 oe use on my system /opt/oe/oetmp/cross/lib/gcc/arm-linux/3.4.4/ how can i change this settings to use 2.9 version ? Jun 11 04:26:59 moliver isn't that in the local.conf? Jun 11 04:30:01 darmou, perhaps but i have change nothing in it since months and now , i have error like this : ERROR: /usr/lib/gcc/arm-linux/3.4.4/libgcc_s.so uses hardware FP, whereas gpe-edit uses software FP Jun 11 04:31:09 molivier: That's saying that libgcc_s.so to be in /usr/lib/gcc Jun 11 04:31:25 molivier: Not in /opt/oe/oetmp/cross/lib .. Jun 11 04:32:02 molivier: Perhaps there's another crosscompiler in that machine? Jun 11 04:32:56 SirFred, ok agree with you, so how to buypass the other one crosscompiler and force use the one in /opt/oe/oetmp ? Jun 11 04:33:32 molivier: Do you have some ASSUME_PROVIDED in your local.conf for the compiler? Jun 11 04:33:54 SirFred, i've got this ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95" Jun 11 04:34:38 molivier: Well, on the shell you're using to launch bitbake, what says you Jun 11 04:34:54 which arm-linux-gcc Jun 11 04:35:05 molivier: Perhaps it's just a path problem. Jun 11 04:36:43 i not on the path Jun 11 04:37:45 SirFred, i 've set the good one in my PATH but it's change nothing Jun 11 04:37:59 molivier: So, what do you have in your PREFERRED_PROVIDERS for virtual/${TARGET_PREFIX}gcc ? Jun 11 04:39:30 molivier: I have to say you that I'm a newbie, sure any other one could help you faster and better. Jun 11 04:39:34 SirFred, sorry know it use /opt/oe/oetmp/cross/lib/gcc/arm-linux but i have got 2 versions: 3.4.3 and 3.4.4 Jun 11 04:40:28 molivier: But you only will have a binary arm-linux-gcc, don't you? Jun 11 04:40:44 molivier: Perhaps you've overwritten one compiler with the other. Jun 11 04:41:13 SirFred: i have the same warnings Jun 11 04:41:21 Pretty odd Jun 11 04:41:25 they're kind of new Jun 11 04:41:26 mickeyl: Strange warnings. Jun 11 04:41:47 mickeyl: Yes, they are. I'm not able to understand how the symbol has different size if they're compiled with the same compiler. Jun 11 04:42:15 SirFred, yes and it's 3.4.4 version Jun 11 04:42:24 mickeyl: Anyway, the symbol is only defined once, or should be. Jun 11 04:42:38 mickeyl: So, I don't understand why the symbol is duplicated. Jun 11 04:42:43 mickeyl: I have the latest bb and oe now... Jun 11 04:42:52 mickeyl: glibc doesnt build though Jun 11 04:43:35 mickeyl: Does the compiler changed from the last openzaurus' Jun 11 04:43:36 ? Jun 11 04:44:36 no idea offhand Jun 11 04:44:42 i stay away from toolchain issues Jun 11 04:44:55 mickeyl: I see i have two versions on the cross directory: 3.4.3 and 3.4.4 Jun 11 04:45:18 ah right. IIRC pb_ updated us to 3.4.4 Jun 11 04:45:24 mickeyl: But the binary is for 3.4.4, I think that with 3.4.3 these warnings didn't happen. Jun 11 04:45:36 yeah. seems to be a 3.4.4 thing Jun 11 04:45:42 pb_: any idea what's going on there ? Jun 11 04:45:51 pb_: see http://www.vanille.de/temp/log.do_compile.1397 Jun 11 04:45:59 mickeyl: Perhaps this is a nonsense, but could be related with header precompiling or something so? Jun 11 04:47:07 we don't use that feature Jun 11 04:48:25 mickeyl: sorry, I have no idea. It looks like some crazy moc thing. Jun 11 04:48:36 maybe zecke can help Jun 11 04:49:09 isn't moc part of stdc++? Jun 11 04:49:38 ~herring zecke Jun 11 04:49:39 pb_: I wouldn't blame moc for that Jun 11 04:49:42 * ibot whacks zecke on the side of the head with a large red herring named alfred Jun 11 04:49:59 pb_: it looks like somehow the symbol got truncated or such... Jun 11 04:50:47 mickeyl: I will now leave to the 'long night of science" Jun 11 04:51:17 mickeyl: could you see what happens if you compile Qt/E with gcc3.4.3? Jun 11 04:51:44 It's strange, some symbols are greater on allmoc.o and other are greater on the other file. Jun 11 04:51:47 hmm beep music complies but does not run very well oh well Jun 11 04:52:03 has libpng been fixed yet? Jun 11 04:52:28 different defines are set? Jun 11 04:52:58 pb_, zecke, this might be of interest... Jun 11 04:53:00 http://pastebin.ca/13948 Jun 11 04:53:43 zecke: i can check that. it'll take a while though Jun 11 04:54:52 yeah, that sounds like a good idea. Jun 11 04:55:04 you might also try comparing allmoc.o between the two builds to see if there are any obvious differences. Jun 11 04:55:09 This is a nonsense: Jun 11 04:55:13 /export/home/oe/tmp/cross/lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld: Warning: size of symbol `QIMComposeEvent::~QIMComposeEvent()' changed from 112 in allmoc.o to 60 in kernel/qmime.o Jun 11 04:55:23 /export/home/oe/tmp/cross/lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld: Warning: size of symbol `QIMComposeEvent::~QIMComposeEvent()' changed from 120 in allmoc.o to 68 in kernel/qmime.o Jun 11 04:55:36 A moving target. Jun 11 04:55:53 teach the linker couting Jun 11 04:55:56 mm, that does look a little bit bogus. Jun 11 04:55:56 counting even Jun 11 04:56:01 maybe it is the new binutils that's broken. Jun 11 04:56:04 Going to make a nm of Jun 11 04:56:07 allmoc.o Jun 11 04:56:20 To see if that symbol appears more than once, or what. Jun 11 04:56:22 what version of ld do you have? Jun 11 04:57:38 00000000 T QConnectionList::~QConnectionList() Jun 11 04:57:38 00000000 T QConnectionList::~QConnectionList() Jun 11 04:57:38 00000000 T QIMComposeEvent::~QIMComposeEvent() Jun 11 04:57:38 00000000 T QIMComposeEvent::~QIMComposeEvent() Jun 11 04:57:54 Well, arm-linux-nm says that. Jun 11 04:58:13 There should be only one destructor by class, shouln't it ? Jun 11 04:58:39 But the mangling is different. Jun 11 04:58:49 00000000 T _ZN15QIMComposeEventD0Ev Jun 11 04:58:50 00000000 T _ZN15QIMComposeEventD1Ev Jun 11 04:59:10 arm-linux-ld -v Jun 11 04:59:10 GNU ld version 2.15.91.0.2 20040727 Jun 11 05:00:14 bbl Jun 11 05:00:33 Can you unmangle those two names? I don't have the eleet c++ ski11z to decode them in my head. Jun 11 05:00:42 c++filt Jun 11 05:00:54 pb_: I've pasted the demangling before Jun 11 05:00:58 [13:57] SirFred 00000000 T QConnectionList::~QConnectionList() Jun 11 05:00:58 [13:57] SirFred 00000000 T QConnectionList::~QConnectionList() Jun 11 05:01:13 oh, right, sorry Jun 11 05:01:33 That does seem a bit peculiar. Jun 11 05:02:25 That 00000000 shoulnd't be the symbol location in the object ? Jun 11 05:02:31 Not that I know the difference between D0Ev and D1Ev but I've it on any c++ built object Jun 11 05:02:48 SirFred: right it will be relocated at linking time/runtime Jun 11 05:02:48 Can't have a symbol on the text section and on the 00000000. Jun 11 05:04:42 I've just looked at a allmoc.o compiled with 3.4.3 Jun 11 05:05:03 I thing these symbols should be Undefined. Jun 11 05:05:07 Not in the Text section. Jun 11 05:05:55 okay cya later Jun 11 05:06:07 U QDnsSocket::~QDnsSocket() Jun 11 05:06:09 U QDnsSocket::~QDnsSocket() Jun 11 05:06:21 Something like this. There're also two destructors defined for any object. Jun 11 05:07:44 hm. its definately a toolchain prob - my older toolchain (homebuilt) doesnt cause the problem. Jun 11 05:15:01 sirfred|lunch: can you run allmoc.ii through the two compilers and compare the .s output? Jun 11 05:16:36 I cant see anything wrong with the instructions... Jun 11 05:18:37 03mickeyl 07 * r1.3544 10openembedded/packages/opie-taskbar/opie-taskbar/ (6 files in 6 dirs): opie-taskbar/all models: specify a preferred font in qpe.conf Jun 11 05:19:59 mickeyl: why would bitbake choose one binutils-cross*.bb over another? Jun 11 05:20:31 it appears to be picking some arbitrary CVS version Jun 11 05:20:40 GNU ld version 2.15.96 20050323 Jun 11 05:21:54 bitbake doesn't choose arbitrary Jun 11 05:22:02 it's either the latest or a preferred Jun 11 05:22:18 or a cvs versions specified through CVSDATE Jun 11 05:22:24 ~lart /etc/init.d/checkversion to check for the _date_ the kernel was build Jun 11 05:22:24 * ibot offers /etc/init.d/checkversion to check some herring for the _date_ the kernel was build Jun 11 05:22:26 mickeyl: why would it pick CVS over (say) binutils-cross_2.16.bb Jun 11 05:22:42 Spyro: because cvs is always later than a fixed one Jun 11 05:23:14 mickeyl: is there a 'sub package' I can pick that builds a 'known good' toolchain ? Jun 11 05:23:52 Spyro: for a known good toolchain revert your bb and oe to the state of oz 3.5.3 or familiar 0.8.3 Jun 11 05:23:55 0.8.2 even Jun 11 05:24:03 everything later is not known Jun 11 05:24:32 you mean set DISTRO to familiar-0.8.3 ? Jun 11 05:24:40 that's one part Jun 11 05:24:40 2 even Jun 11 05:24:42 but also revert Jun 11 05:24:50 revert ? Jun 11 05:24:59 i.e. download bb and OE from the day the DISTROs were released Jun 11 05:25:20 then again - you might want to look into setting PREFERRED_VERSION and PREFERRED_PROVIDER instead Jun 11 05:25:22 mickeyl: but I *upgraded* them because of problems... *sigh* ;-) Jun 11 05:26:39 see familiar-0.8.3 conf Jun 11 05:26:44 remove the comments for the PREFERRED_VERSIONS Jun 11 05:26:49 that may give you better results Jun 11 05:27:02 will take a look Jun 11 05:28:58 ok going for a fam-0.8.3 with preferred versions from the conf... Jun 11 05:29:02 here we go... Jun 11 05:45:55 RP: do you have a hint for me how to change the socket order in openzaurus-pxa27x ? Jun 11 05:46:04 i.e. in which file should i do what :)) Jun 11 05:49:55 mickeyl: I'll need to look at it :) Jun 11 05:52:25 mickeyl: Downloading the source now Jun 11 05:55:07 RP: excellent. thanks! Jun 11 05:56:03 I'm afraid b0ti won't be finished with 2.6 at the time we want to release 3.5.4 :) Jun 11 06:00:42 mickeyl: I suspect there is a bit more work in 2.6 than that :) Jun 11 06:03:15 mickeyl: 3.5.4 still planned for "july" ? Jun 11 06:03:28 anyone here in the USA ? Jun 11 06:04:41 koen: I'm not really sure. we still haven't worked out the suspend/resume uglyness on collie and there has been little work for the tosa and spitz being done. Jun 11 06:05:10 a new release should introduce working keys on spitz/akita/tosa and a fixed suspend/resume on collie Jun 11 06:05:20 so i'm kind of tempted to hold it back until these issues are gone Jun 11 06:05:23 what do you think? Jun 11 06:05:31 and a working gpe on spitz+akita Jun 11 06:05:44 right Jun 11 06:05:56 we have some blockers on fmiliar too :( Jun 11 06:07:38 gpe on akita should be straightforward, the initial rotation needs to be changed Jun 11 06:08:01 the person on oesf who fixed *still* hasn't sent a mail to the OE list Jun 11 06:08:03 right. the backlight interface didn't change from 2.4 corgi, so it should also work Jun 11 06:09:21 but first: fix the h3900.conf, which I seem to have broken Jun 11 06:11:56 I guess we also need to make a decision re: which 2.6.x kernel to use. 2.6.12 is better in some ways and more broken in others :-/ Jun 11 06:12:53 RP: that depends on when we release. if it was july, i'm leaning more towards 2.6.11. if later, then we might as well wait until the pcmcia rework has been settled Jun 11 06:13:39 mickeyl: agreed Jun 11 06:14:28 I'm still not sure if I introduced suspend/resume bugs when I fixed the alarm handling :-/ Jun 11 06:15:21 yeah, i've been able to hang it more than once recently Jun 11 06:15:29 when resuming Jun 11 06:15:52 i'm also a bit worried about the battery reporting. it still seems not always correct to me Jun 11 06:16:02 did you change anything based on hrw's results ? Jun 11 06:18:05 mickeyl: no, I didn't. I did tweak the battery handling code when doing the alarms though Jun 11 06:18:25 There was a load of code I didn't like. I think I begin to see why it was there now though :-( Jun 11 06:18:39 03koen 07 * r1.3539.1.1 10openembedded/conf/machine/h3900.conf: h3900.conf: fix h3900 modules confusion Jun 11 06:18:43 In what way does it worry you? Jun 11 06:19:15 i have that odd feeling that it drains faster and more stepwise than it should Jun 11 06:19:28 sorry, it's just a feeling, i can't back it up with facts atm. Jun 11 06:20:13 I have the same problem... Jun 11 06:20:55 I guess I need to look at the code I removed more carefully Jun 11 06:21:25 It was really horrible stuff though... Jun 11 06:21:43 RP: battery stuff typically is Jun 11 06:22:02 ~lart Sharp for saving little by not adding a HW circuit for charging Jun 11 06:22:02 * ibot pulls out a ClueBat (tm) and thwaps Sharp for saving little by not adding a HW circuit for charging Jun 11 06:22:32 one of the few things toshi did right. Jun 11 06:22:37 and siemens Jun 11 06:22:55 * Spyro got a simpad off ebay, will be fun to play with Jun 11 06:23:35 well glibc built... Jun 11 06:24:25 mickeyl: Looking at this 2.4 code, its not going to be easy to reverse the slots. I'd forgotten what Sharp's code is like :-( Jun 11 06:24:38 RP: i was afraid of that when I looked at it Jun 11 06:24:41 RP: don't bother Jun 11 06:24:43 RP: 'reverse' slots ? Jun 11 06:25:02 Spyro: Sharp came with that great idea to make the internal non-removable (!) HD as PCMCIA SLOT 1 Jun 11 06:25:16 i want it to be slot 0 Jun 11 06:25:26 mickeyl: why? Jun 11 06:26:01 uhm, because it seems more logical to me Jun 11 06:26:20 mickeyl: its just a number... let userspace do the coverup job if you dont like it :) Jun 11 06:26:24 also because it makes some things more predictable Jun 11 06:26:31 Spyro: ... how ? Jun 11 06:26:43 write patches :) Jun 11 06:26:51 err Jun 11 06:27:12 seriously - cant you just use the mountpoint ? why is the number even important? Jun 11 06:27:38 because things are unpredictable once the user has a chance to fill slot 0 with a CF Jun 11 06:27:54 hda -> hdb Jun 11 06:28:41 mickeyl: use udev to make that a non-issue Jun 11 06:28:48 Spyro: no go Jun 11 06:28:54 Spitz is far from being 2.6 Jun 11 06:29:00 That's for sure. Jun 11 06:29:01 bah Jun 11 06:29:02 2.4.20-embedix is trump Jun 11 06:31:17 RP: I've put some new patches up with the start of LCD support.. It's pretty hacky, but at least you see something. Jun 11 06:31:32 ~praise BigAl Jun 11 06:31:33 BigAl: what platform? Jun 11 06:31:35 All hail BigAl! Jun 11 06:31:40 Spitz under 2.6 Jun 11 06:31:47 BigAl++ Jun 11 06:31:57 ~BigAl++ Jun 11 06:32:25 ~karma BigAl Jun 11 06:32:25 bigal has karma of 1 Jun 11 06:32:34 ~karma Spyro Jun 11 06:32:34 spyro has karma of 4 Jun 11 06:32:44 heh Jun 11 06:32:46 ~karma CoreDump|home Jun 11 06:32:46 coredump|home has neutral karma Jun 11 06:32:47 RP: We could probably make the ssp stuff common across all the sharpsl variants too, so I've tried to make the ssp patch pretty general. Jun 11 06:37:03 jacques: did you ever get a chance to investigate that ifupdown crash in busybox? Jun 11 06:37:12 the one with the environ patch Jun 11 06:37:52 anyone here having trouble with mtd on hh.org CVS 2.6 kernels ? Jun 11 06:38:55 pb_, no, thanks for reminding me Jun 11 06:39:42 BigAl: That's great! I'll have a look shortly Jun 11 06:39:57 mickeyl: See the email I've just sent you. Its mad enough to maybe work Jun 11 06:41:42 RP: There's still some uglyness with the lcdtg chip, though. I couldn't find an ssp clock divider that made it work. Jun 11 06:45:14 BigAl: I see what you mean about the bit banging code. That was never needed for the c7x0 Jun 11 06:45:46 jacques: ok, no problem. I was just reminded of it because my mythfront build crashed at ifupdown.c again. Jun 11 06:45:48 It *should* be possible to program the ssp port of the pxa port to get around that however it looks like Sharp couldn't do that for some reason... Jun 11 06:46:46 RP: I tried a couple of ssp dividers that should have given a similar clock rate to what it looked like you had for the corgi, but it refused to work. Jun 11 06:47:41 BigAl: I'd also not like to rely on ifdefs in the long run - pxa27x and pxa25x support will get merged and it'd be nice if we were ready for that Jun 11 06:47:55 They're obviously fine whilst you get stuff working Jun 11 06:48:49 RP: any known timeframe for the 25x and 27x merge? Jun 11 06:49:36 koen: As soon as someone perswades me to spend some time on it I expect :) Jun 11 06:49:45 BigAl: You look to be working against mainline rather than the patches in oe Jun 11 06:50:03 BigAl: The lcdtg code has been pulled out of w100fb Jun 11 06:50:11 I'm waiting to merge that with mainline Jun 11 06:50:41 BigAl: Have a look at http://www.rpsys.net/openzaurus/patches/w100_split-r10.patch Jun 11 06:51:44 RP: I just grabbed it from corgi_lcd.c, the stuff in the pxafb code in 2.4 from sharp was the same. Jun 11 06:52:31 BigAl: It was the ATI copyright that threw me. Its changed enough for me to bin that :) Jun 11 06:54:29 * BigAl grins Jun 11 06:55:40 RP: The lcdtg could could probably made common too, if it's worth it. Jun 11 06:56:18 I wish we had a datasheet for that chip, though. Jun 11 06:59:47 BigAl: So do I. I did try and get one... Jun 11 06:59:49 Its internal Sharp only though so no chance ever... Jun 11 07:00:40 yay! bootstrap image built! Jun 11 07:01:15 Spyro: cheers Jun 11 07:02:47 now to add back the eseries bits... Jun 11 07:03:40 RP: does your 770 have the accellerated image viewer? Jun 11 07:04:55 koen: Not sure. How would I tell the difference? Jun 11 07:05:19 RP: Oh well. At least we've got some code to look at. Jun 11 07:05:26 I guess that it doesn't link to libjpeg Jun 11 07:05:44 I've heard rumours the image viewer uses the DSP for that Jun 11 07:06:04 koen: I want to get my hands on THAT code... Jun 11 07:06:16 if the imageon can do iDCT it should be great for jpeg decode Jun 11 07:07:01 Spyro: closed source and you'll need a $5400 compiler Jun 11 07:07:16 koen: yeah... Jun 11 07:07:25 koen: or some decent reverse engineering Jun 11 07:07:36 let's hope the ti-dsp gcc project advances Jun 11 07:07:56 :) Jun 11 07:08:29 what would you reverse engineer? surely the DSP specs are public. Jun 11 07:08:30 the dsp compiler at the uni is too old for the 55x Jun 11 07:08:43 if I change my bitbake machine conf how do I force a rebuild? Jun 11 07:08:43 koen: Mine is linked to libjpeg Jun 11 07:08:57 koen: That doesn't mean it doesn't use the dsp though Jun 11 07:10:27 I dont want to rebuild my toolchain... Jun 11 07:11:40 anyone ? Jun 11 07:12:02 rm -rf tmp Jun 11 07:12:13 Luke-Jr: that'll nuke my toolchain Jun 11 07:12:17 oh... not sure about toolchain Jun 11 07:12:25 individually nuke parts of tmp? Jun 11 07:12:29 03pb 07 * r1.3543.1.1 10openembedded/packages/dejagnu/ (dejagnu-qemu_1.0.bb dejagnu-qemu/arm-qemu.exp): add qemu wrapper for use with dejagnu Jun 11 07:12:34 Luke-Jr: yeah but which ones ? Jun 11 07:12:44 Luke-Jr: its full of stuff... Jun 11 07:12:53 everything not containing -cross and -native ? Jun 11 07:13:14 hm. possibly... Jun 11 07:13:33 but Id prefer to just nuke the one or possibly two things that are causing it to think its already done... Jun 11 07:13:35 not sure the best way to filter such Jun 11 07:13:40 I tried -c clean task-bootstrap Jun 11 07:13:47 that'd be in tmp/stamps Jun 11 07:14:05 but you'll likely get errors without nuking tmp/work of them also Jun 11 07:14:24 *sigh* Jun 11 07:14:35 (which is what -c clean would do) Jun 11 07:14:39 dependency systems that get out of sync get on my tits Jun 11 07:15:21 Spyro: use multimachine.inc and create a conf/machine/eseries.conf Jun 11 07:15:35 koen: I have a conf/machine/eseries.conf Jun 11 07:15:50 but I forgot to copy it across so my bootstrap was done without it Jun 11 07:15:58 now Ive copied it but it doesnt believe in it Jun 11 07:16:53 isnt it a bug that bb could continue despite the fact that the MACHINE variable described a nonexistent machine conf file? Jun 11 07:18:00 probably. patches are welcome. Jun 11 07:18:24 03pb 07 * r1.3547 10openembedded/packages/xt/xt_0.1.5.bb: disable PARALLEL_MAKE for Xt Jun 11 07:20:56 GCC crashes compiling xserver-xorg o.O; Jun 11 07:23:22 * Spyro nukes the toolchain. *sigh* Jun 11 07:36:07 Err, for handhelds-pxa-2.6-cvs, in the run.do_patchcleancmd file, there is a python function without the python keyword before the func name (do_package at line 444) ... and the shell interpreter doesn't seem to like it. How could I fix it ? Jun 11 07:40:23 hi Jun 11 07:46:11 03mickeyl * r250 10bitbake/lib/bb/make.py: Jun 11 07:46:11 collect_bbfiles: Jun 11 07:46:11 - save progress callback in function attribute Jun 11 07:46:11 - remain completely silent when no progress callback is requested Jun 11 07:51:33 mickeyl: Did my email make sense? Jun 11 07:54:11 RP: thanks for that. sounds like a interesting approach, i'll try that asap Jun 11 07:58:29 I need to pop out for a bit - back in a couple of hours... Jun 11 08:01:19 cu Jun 11 08:05:59 hello Jun 11 08:06:31 Hello l-fy Jun 11 08:06:36 Nice to see you here. Jun 11 08:06:41 Laibsch > tell me more about this :) Jun 11 08:06:55 As I said, I think openembedded is the way to go for you. Jun 11 08:06:57 File "/home/stefan/tuxbox/oe/openembedded/packages/quilt/quilt_0.39.bb:base_do_fetch", line 26, in ? Jun 11 08:06:57 File "/home/stefan/tuxbox/oe/openembedded/packages/quilt/quilt_0.39.bb:base_do_fetch", line 4, in base_do_fetch Jun 11 08:06:57 AttributeError: 'module' object has no attribute 'createCopy' Jun 11 08:07:00 also dabei tritt das auf Jun 11 08:07:01 hmpf Jun 11 08:07:33 @everyone: l-fy is the developper for yate, a solution similar but apparently superior to asterisk. Jun 11 08:07:41 is this somehow known? or am i wrong here? ;) Jun 11 08:08:40 @everyone: yate seems to run on arm without a problem. I got l-fy interested in using openembedded as a build-system. Jun 11 08:09:14 l-fy: Take a look at http://oe.handhelds.org/cgi-bin/moin.cgi/GettingStarted. The things you need to set up the tool-chain should be all there. Jun 11 08:09:43 my hp it's an pxa 255 Jun 11 08:12:00 l-fy: You will set the target you build for in local.conf IIRC. Take a look at above URL 3.4 Jun 11 08:12:31 You can easily build for other targets by just changing a single line in the config file. Jun 11 08:12:37 ok Jun 11 08:12:47 let me read more Jun 11 08:12:54 the problem it's that i don't have a zaurus Jun 11 08:12:56 Sure. Come back if you have question. Jun 11 08:13:14 l-fy: openembedded is not just for the Zaurus. Jun 11 08:13:33 It is platform-agnostic. Jun 11 08:13:43 ok Jun 11 08:13:45 thank you Jun 11 08:13:51 np Jun 11 08:14:18 kergoth: Still waiting for that dump of the old wiki Jun 11 08:16:16 ok, which chipset zaurus has? Jun 11 08:17:04 arm Jun 11 08:17:26 chipset not category? Jun 11 08:17:30 SL5500: StrongARM 206MHz Jun 11 08:17:33 a ok Jun 11 08:17:58 Why do you need to know? Jun 11 08:18:28 You should leverage the power of OE and build for ALL supported platforms ;) Jun 11 08:18:55 l-fy: What distro do you use? Jun 11 08:19:29 mandriva :) Jun 11 08:19:41 Wow, never heard of that one. Jun 11 08:20:08 Mandrake-based? Jun 11 08:20:37 it's mandrake new name :) Jun 11 08:20:47 ;-) OK Jun 11 08:22:23 i didn't get far with installing kernel on my pda Jun 11 08:22:41 opie-irc and some fonts on konqueror seem to lack characters. they are showed as squares. Do I need to install something? Jun 11 08:29:34 Is there a VoIP solution in openembedded yet? I heard of minisip once, is it in? Jun 11 08:33:14 Laibsch: do bitbake minisip and see what happens :) Jun 11 08:33:34 Cool. Jun 11 08:35:55 mickeyl: is bitbake almost ready for another release? Jun 11 08:43:22 * koen takes another stab at adding engage to OE Jun 11 09:11:51 03koen 07 * r1.3545.1.1 10openembedded/packages/ecore/ecore_0.9.9.007.inc: ecore_0.9.9.007.inc: evas -> virtual/evas Jun 11 09:53:57 * chouimat is away: buying food and a fan Jun 11 09:54:47 03pb 07 * r1.3547.1.1 10openembedded/packages/xserver/xserver-xorg_6.8.99.5.bb: more xorg build fixes Jun 11 09:57:39 if I add a package to machine/eseries.conf, what do I need to do to get it noticed and built by bitbake ? Jun 11 10:07:44 Spyro: touch conf/local.conf Jun 11 10:08:36 that shouldn't be necessary when editing MACHINE.conf. Jun 11 10:08:40 if it's required, that's a bug. Jun 11 10:11:59 if I have a .bb for compiling a single C file (foo.c) I should simply do something like: Jun 11 10:12:04 do_compile() { Jun 11 10:12:04 ${CC} -o devmem2 devmem2.c ${CFLAGS} ${LDFLAGS} Jun 11 10:12:04 } Jun 11 10:12:07 right ? Jun 11 10:12:21 yes Jun 11 10:12:31 well devmem2 doesnt build Jun 11 10:12:36 that's very sad Jun 11 10:12:44 complains that it cant find arm-linux-gcc Jun 11 10:13:06 (kinda hard to believe following a successful bootstrap image...) Jun 11 10:14:24 * RP is back Jun 11 10:14:39 can I get bb to show me exactly the commands it is running, on the fly ? Jun 11 10:22:01 hrm. the problem *appears* to be that PATH doesnt contain tmp/cross/bin Jun 11 10:22:07 should it do ? Jun 11 10:22:59 yes Jun 11 10:23:25 should the shells PATH contain it or is bb meant to put it there? Jun 11 10:25:17 hm. no, its in the PATH... Jun 11 10:25:45 ahhhhh Jun 11 10:25:49 its in the wrong dir Jun 11 10:26:03 its building in /home/ian/projects/openembedded/stuff/tmp/work/devmem2-1.0-r0/devmem2-1.0 Jun 11 10:26:12 but the source is in the parent of that Jun 11 11:00:50 pb_: it appears the problem is that bb is fetching the devmem2.c file into the wrong directory. perhaps because its a single .c file rather than a tarball. Jun 11 11:01:03 pb_: Im not sure how to fix it though, I dont know python-foo Jun 11 11:01:27 S = ${WORKDIR} Jun 11 11:03:32 koen: pardon? Jun 11 11:03:53 put that in the .bb Jun 11 11:04:08 whats S ? Jun 11 11:05:10 Spyro: http://ewi546.ewi.utwente.nl/tmp/d/keyS.html Jun 11 11:06:41 koen: well it fixed it. Jun 11 11:07:00 I'd commit the fix but I have neither priveliges or the desire to use bk... Jun 11 11:07:19 03koen 07 * r1.3549.1.1 10openembedded/conf/documentation.conf: documentation.conf: add S Jun 11 11:07:22 would it be possible to setup a SVN/BK gateway ? Jun 11 11:07:24 but a patch in bugzilla Jun 11 11:07:34 ok, will do. Jun 11 11:07:50 Bitmover will shoot down such gateways Jun 11 11:07:56 Hi again. Jun 11 11:08:15 Any new about that strange symbol mismatch with the toolchain? Jun 11 11:12:34 koen: thats shitty :( Jun 11 11:14:08 yeah Jun 11 11:14:20 that's what we get for selling our souls to larry Jun 11 11:15:37 Sirfred: We probably need one of the patches linked off http://www.arm.linux.org.uk/developer/toolchain/ Jun 11 11:16:25 RP: So, the problem is located in binutils? Jun 11 11:17:38 GNU binutils now produces mapping symbols "$a" and "$d" which interfere with symbolic decoding. Jun 11 11:18:00 RP: I found those symbols on the allmoc.o object. Jun 11 11:18:11 Going to see if they were there with the old toolchain Jun 11 11:19:00 It seems that they were there yet. Jun 11 11:19:00 Sirfred: You need one of the patches to binutils as linked above Jun 11 11:21:32 pb_: ping Jun 11 11:22:10 pb_: Is there any reason we shouldn't apply http://www.arm.linux.org.uk/developer/toolchain/elf32-arm.h.patch to binutils? Jun 11 11:24:04 * chouimat is back. Jun 11 11:36:54 pb_: Just ignore me... Jun 11 11:37:45 RP: Have you found something? Jun 11 11:38:02 Sirfred: No :-( Jun 11 11:38:19 RP: Your comment sounded as if after further investigation, your question becomed obsoleted. Jun 11 11:38:24 I thought I had, but I haven't... Jun 11 11:38:46 RP: It seems that those patches are necesary, I'm just rebuilding all my toolchain. Jun 11 11:40:24 Sirfred: I think we already apply them Jun 11 11:40:31 Or they've been merged into bintuils... Jun 11 11:40:50 RP: I didn't found something similar in the files subdirectory for binutils. Jun 11 11:42:24 Sirfred the code in the patch I linked to is already in elf32-arm.c Jun 11 11:42:33 RP: :-( Jun 11 11:43:01 RP: Sure this is a dumb question, but... Jun 11 11:43:18 RP: Are binutils really involved while creating a .o from a .cpp ? Jun 11 11:43:50 RP: Is the compiler using binutils for something at this stage? Jun 11 11:44:25 Sirfred: I'm not entirely sure to be honest Jun 11 11:45:07 RP: Perhaps is something easy to see. Jun 11 11:45:25 RP: I'm going to invoke it, and strace to see what is it exec'ing. Jun 11 11:48:34 RP: It seems that binutils are not involved: Jun 11 11:48:35 mteira@maleficio ~ $ strace -f g++ -c test.cc 2>&1 | grep ^exec Jun 11 11:48:37 execve("/usr/bin/g++", ["g++", "-c", "test.cc"], [/* 27 vars */]) = 0 Jun 11 11:49:41 RP: I think that the problem is related with gcc and not binutils. Jun 11 11:50:07 Sirfred: Ok, I suspect it was a concious effort on gcc's part to add the symbols for some reason though Jun 11 11:50:57 RP: About those $a and $d symbols, perhaps they get stripped out when linking the final library/executable. Jun 11 11:51:36 Sirfred: I'd thought the linker was supposed to deal with them (hence the above bintuils patch) Jun 11 11:51:59 RP: The real problem is that symbols that I think should be emitted as Undefined, are emitted as Text Jun 11 11:52:22 I think that it's what is causing the warning. Jun 11 11:53:35 Ciao all Jun 11 11:54:54 I have a problem compiling libaudiofile with oe using DISTRO=familiar-0.8.3. Jun 11 11:54:54 hi Pigi Jun 11 11:54:58 /tmp/ccytAfmb.s: Assembler messages: Jun 11 11:54:58 /tmp/ccytAfmb.s:2906: Error: bad instruction `stfpls f2,[sp,#-4]!' Jun 11 11:55:00 hi RP Jun 11 11:55:54 Pigi: Does familar-0.8.4 work any better? Jun 11 11:56:20 has it been released a new conf file for familiar 0.8.4 ? Jun 11 11:56:54 Its not released but the 0.8.4 file is updated regularly to keep things working Jun 11 11:57:02 Its the file which will become 0.8.4 if you see what I mean Jun 11 11:57:23 Pigi: it looks like there is a bug in the latest version of gas. Jun 11 11:57:24 really it should be called familiar-current :) Jun 11 11:57:49 Try going back to the older binutils snapshot (the one from 200504mumble). I think that will clear it up. Jun 11 11:58:05 so I'm supposed to bk pull before trying to use familiar-0.8.4 ? Jun 11 11:58:37 pb_ do you mean I should revert to binutils-200504 and recompile everithing ? Jun 11 11:58:54 Pigi: You probably have a familiar-0.9.0 in your tree - koen renamed it recently back to 0.8.4 Jun 11 11:58:56 you don't need to recompile everything, just retry the audiofile build. Jun 11 11:59:34 ok, I'll try. I was scared as I started a new compile yesterday nite, and finished today :) Jun 11 11:59:42 heh Jun 11 12:00:13 so, the procedure could be: bk pull, then change DISTRO and then restart the libaudiofile ? Jun 11 12:00:44 I'm not sure that bk pull is necessary, and I don't know that changing DISTRO will help. Jun 11 12:01:21 so ( apologize ) how I'm supposed to use the old binutil ? Jun 11 12:01:55 I would recommend that you manually build the older binutils with bitbake -b, set PREFERRED_VERSION_binutils-cross in your local.conf to stop the new one getting compiled again by mistake, then rerun whatever you were previously trying to build. Jun 11 12:02:08 ok. Thx Jun 11 12:02:12 I'll try Jun 11 12:02:30 I'll temporarily disable the new binutils anyway, until this problem is resolved. Jun 11 12:02:40 cool Jun 11 12:04:30 pb_ apologize again. Could it be binutils-cross_csl-arm-20050416.bb what I do need ? Jun 11 12:05:51 right, yeah, that's the one you need Jun 11 12:05:58 ok, thx Jun 11 12:10:45 03pb 07 * r1.3550.1.1 10openembedded/packages/binutils/binutils_csl-arm-20050603.bb: remove preference for binutils_csl-arm-20050603 due to "stfpls" problem Jun 11 12:12:46 03pb 07 * r1.3553 10openembedded/packages/linux/linux-epia_2.6.11.bb: set KERNEL_CCSUFFIX to 3.3.4 for epia, pending availability of gcc-cross-kernel 3.4.4 Jun 11 12:24:53 if I want xserver-kdrive_20050207 what do I put in PREFERRED_VERSION ? Jun 11 12:31:39 you mean the 20050207 CVS version? Jun 11 12:33:25 03pb 07 * r1.3554 10openembedded/packages/pciutils/pciutils_2.1.11.bb: suppress PARALLEL_MAKE for pciutils Jun 11 12:34:15 Spyro: ah... it's a frozen snapshot... try 0.0cvs20050207 Jun 11 12:36:51 Luke-Jr: ta Jun 11 12:37:31 ta? O.o Jun 11 12:37:41 Luke-Jr: == thankyou Jun 11 12:38:05 ah. yw Jun 11 12:43:59 kdrive has a new snapshot Jun 11 12:44:03 20050610 Jun 11 12:44:28 hi koen Jun 11 12:44:36 hey pi Jun 11 12:44:45 Pigi even Jun 11 12:44:48 eheh Jun 11 12:45:03 koen: how reliable is it ? Jun 11 12:45:16 it works on my zaurus Jun 11 12:45:50 mallum fixed the tslib code the day before Jun 11 12:46:05 it should get built by default Jun 11 12:46:43 koen: how do I force kdrive to rebuild now? I changed the PREFERRED_VERSION to 0.0cvs20050207 but it refuses to rebuild. I tried deleting the kdrive stamps... Jun 11 12:47:38 bitbake -c clean -b path/to/file.bb ; bitbake -b path/to/gile.bb Jun 11 12:47:54 or bitbake -i and 'rebuild xserver-kdrive' Jun 11 12:53:03 why is it that rebuilding the whatever it is that takes bb so long parsing the bb files sometimes goes quick and sometimes REALLY slow ? Jun 11 12:56:39 it caches them after it parses the first time. but if you change a .conf file, the whole cache gets invalidated, and it has to reparse them all. Jun 11 12:57:13 keturn: ah. Jun 11 12:57:30 keturn: its confusing since it says its 'using cache from...' regardless Jun 11 13:08:28 odd. permission denied error in do_unpack in base-files. Jun 11 13:15:00 koen: the 20050610 snapshot seems prone to segfaults Jun 11 13:15:11 koen: it starts OK Jun 11 13:15:42 but if I run a remote application on my desktop with the display onthe PDA, and then quit it, the server crashes. Jun 11 13:15:50 its 100% repeatable Jun 11 13:26:09 keturn: that does sound odd. are you trying to unpack over an existing tree? Jun 11 13:28:09 looks like it was trying to move one of the files/ over something unpacked from the tarball Jun 11 13:30:00 ah, that's no good. Jun 11 13:30:28 do_unpack doesn't do any moving, though, so you wouldn't expect to see that failure until later. Jun 11 13:31:13 if there are loose files in the SRC_URI, do_unpack just dumps them in ${WORKDIR}. generally, they get moved into ${S} by a do_configure_prepend() or some such. Jun 11 13:32:31 Unpacking /oe/packages/base-files/base-files/nsswitch.conf to /oebuild/xxs1500-tmp/work/base-files-3.0.14-r33/ Jun 11 13:32:31 cp: cannot create regular file `/oebuild/xxs1500-tmp/work/base-files-3.0.14-r33/./nsswitch.conf': Permission denied Jun 11 13:33:29 the tarball will have gotten unpacked in /oebuild/xxs1500-tmp/work/base-files-3.0.14-r33/base-files-3.0.14/. Jun 11 13:33:40 so, whatever that file is colliding with, it didn't come from the tarball Jun 11 13:34:03 pb_ somtetimes I got some similar troubles Jun 11 13:34:31 well, looks like koen's bumped it to r34, so we'll see if that goes okay. Jun 11 13:34:35 it seems that sometimes, some cvs tarball has some stranges permissions Jun 11 13:35:15 keturn: righto, good luck Jun 11 13:35:22 Pigi: yah, I think that's a different problem. Jun 11 13:36:03 ok Jun 11 13:37:53 yeahhhhh after 24 hours of compile_and_fix_and_compile I got "NOTE: package gpe-image-1.0-r17: task do_rootfs: started" Jun 11 13:37:54 bbiab, going to watch some tv Jun 11 13:38:02 * pb_ now known as mickeyl Jun 11 13:49:56 Ah. I think in my meddling with bitbake, I broke stamping. Jun 11 14:16:18 hm. I *think* I have a suspend/resumable server... Jun 11 14:16:37 looks like kdrive segfaults once it has no remaining clients Jun 11 14:16:55 so since its only clients here were via USBnet, which dies on suspend Jun 11 14:17:21 it appeared that kdrive was dying on suspend, where in reality its dying any time it has no clients Jun 11 14:17:39 * Spyro builds gpe-terminal in order to test this theory... Jun 11 14:19:28 Spyro: I guess you want rxvt-unicode Jun 11 14:19:39 Spyro: there is not gpe-terminal Jun 11 14:19:45 s/not/no/ Jun 11 14:20:08 reenoo_: there isnt ? Jun 11 14:20:21 * Spyro looks funny at gpe-terminal_1.1.bb Jun 11 14:24:01 heh. never seen that before. but anyways.. all it contains is a .desktop and a .png Jun 11 14:27:38 heh. yeah, how odd :) Jun 11 14:33:26 ~bugzilla Jun 11 14:33:27 somebody said bugzilla was http://www.handhelds.org/bugzilla/ Jun 11 14:40:29 Crofton: OE bugzilla? see /topic Jun 11 14:41:43 heh Jun 11 14:41:56 no was playing with bugzilla feature on a bot Jun 11 14:42:06 but the bot is in another channel :) Jun 11 14:48:59 * chouimat is away: grocery store Jun 11 15:13:38 * chouimat is back. Jun 11 15:16:05 anyone know about this? http://jw.dyndns.org/initng/ Jun 11 15:20:24 ljp: mickeyl was asking if anyone had tried it :) Jun 11 15:20:40 * RP plays with his new gps receiver Jun 11 15:23:06 i am going to try it on my laptop Jun 11 15:23:20 is it possible to build a gpe-image with NO kernel ? Jun 11 15:24:24 Spyro: Yes, the Zaurii do that Jun 11 15:24:48 RP: I was looking in the c7x0 conf... hows it done ? Jun 11 15:26:24 Spyro: See packages/linux/linux-openzaurus_2.6.12*.bb Jun 11 15:26:36 Spyro: the line FILES_kernel-image is the key (I think) Jun 11 15:27:00 You still compile the kernel as that gives headers etc. You just don't install it to the image Jun 11 15:37:55 first initng boot didn't work.. might need to tweak it Jun 11 15:43:09 morning ljp Jun 11 15:43:15 hi Jun 11 15:54:19 pb_ you around yet ? Jun 11 15:57:53 ~seen pb_ Jun 11 15:57:54 pb_ <~pb@2002:5168:d38c:1:a00:1fff:fe06:93c> was last seen on IRC in channel #gpe, 4d 9m 38s ago, saying: 'later all'. Jun 11 16:14:02 hi people Jun 11 16:14:34 I have a problem. I just folowed the recipe from GettingStarted and started to build opie for instance Jun 11 16:14:53 aris@darkside /mnt/usb/aris/opn/build $ bitbake opie-image Jun 11 16:14:55 ... Jun 11 16:15:31 it downloads quilt-native-0.39 then fails in the do_configure Jun 11 16:15:44 | /mnt/usb/aris/opn/build/tmp/work/quilt-native-0.39-r0/temp/run.do_configure.3842: /mnt/usb/aris/opn/build/tmp/work/quilt-native-0.39-r0/quilt/configure: /bin/sh: bad interpreter: Permission non accordée Jun 11 16:15:44 | FATAL: oe_runconf failed Jun 11 16:15:44 NOTE: Task failed: /mnt/usb/aris/opn/build/tmp/work/quilt-native-0.39-r0/temp/log.do_configure.3842 Jun 11 17:09:24 initng seems to take longer booting. seems to get stuck at coldplug Jun 11 17:09:48 coldplug is a gentoo-ism. probably need to remove it. Jun 11 17:09:59 when its actually running services, it does ruin them faster Jun 11 17:10:09 run them Jun 11 17:10:22 worth more investigation Jun 11 17:11:14 coldplug starts the hotplug services Jun 11 17:11:59 takes a while to start running the services from the time initng is run, though Jun 11 17:13:31 does it calculate dependencies at startup time? Jun 11 17:13:32 installation messed up pcmcia/network, and I had to revert it Jun 11 17:13:53 perhaps... I didnt look at the source Jun 11 17:18:45 well. that's why the old gentoo init scripts system sucked. I guess they've made the same mistake again ;) Jun 11 17:25:14 eesch.. its too gentoo specific Jun 11 17:26:24 would need to rewrite these scripts Jun 11 17:42:25 I have a bitbake build fail on me - if i rerun bitbake, is it starting over again? Jun 11 17:42:32 s/have/had/ Jun 11 17:48:46 synth: no Jun 11 17:53:03 it failed on something in X, now that i run it again it went on to other things it looks Jun 11 17:54:52 rasterman? Jun 11 17:55:57 heh, i remember when i was hanging out in #e alll those years ago. Jun 11 17:56:45 hey kergoth Jun 11 18:06:08 How do I add specific files to an image? For instance if I wanted to add a working kismet.conf to my image.... Jun 11 18:19:44 'night all Jun 11 18:51:19 bitbake says "build 200506111831: completed", but the rootfs image is stamped with 200506111612. and no, it didn't take two hours to build. Jun 11 19:02:04 hmmmm xserver-xorg wont compile under bitbake, imake fails on a Makefile saying it can't execute binary file Jun 11 19:02:47 i dont see anything in xorg's bug list, google shows someone else had this problem http://pastebin.ca/13649 Jun 11 19:04:10 out of curiosity why would you look in xorg's bug list? Jun 11 19:04:29 they dont normally use bb to build it Jun 11 19:04:50 well, its in their tree, and it looked like imake said the error Jun 11 19:04:54 xc/include/ Jun 11 19:05:02 i was just covering my bases :D Jun 11 20:01:33 synth2, I noticed a changeset go by in the last two days dealing with x.org, imake, and ccache bad interactions Jun 11 20:01:38 when did you pull last? Jun 11 20:03:36 I'm up to date and still have problems Jun 11 20:03:40 | xf86Bus.c:3128: internal compiler error: Segmentation fault Jun 11 20:05:48 you try clearing your .ccache ? Jun 11 20:06:01 what arch? Jun 11 20:06:03 oh really? Jun 11 20:06:08 collie/strongarm Jun 11 20:06:11 openzaurus Jun 11 20:06:25 which compiler is it using? arm-csl ? Jun 11 20:06:41 an old 2.95.3 gcc toolchain i had to dl Jun 11 20:06:51 it failed on issuing makes to xserver-xorg Jun 11 20:07:08 im going through the log, doing things by hand, they seem to work from the cmdline Jun 11 20:07:09 i dont get it Jun 11 20:09:49 * Luke-Jr clears ccache Jun 11 20:10:21 synth2: I don't think GCC 2.95 is used for anything but old kernels anymore Jun 11 20:10:37 shouldn't be, anyway-- 2.95 doesn't even support my build system =p Jun 11 20:13:44 yeah, you certainly don't need gcc2 to build x.org Jun 11 20:14:20 * Luke-Jr ponders if gcc2 would even work with x.org Jun 11 20:14:36 well it calls that compiler specifically as gcc-arm-blah-2.95.3 .. i hope it isnt using that for anything aside the kernel Jun 11 20:14:58 synth2: I think he was asking what compiler for x.org Jun 11 20:15:04 dunno what it is tho, I just use the default Jun 11 20:15:11 so did I.. weird.. Jun 11 20:15:37 so, when making zaurus stuff, i need to bitbake a kernel and then bitbake an image? Jun 11 20:15:55 maybe do away with the arm gcc stuff when i try to do gpe-image ? Jun 11 20:16:52 synth2: bitbake the image, it will depend on a kernel Jun 11 20:17:07 you'll need *some* ARM GCC for an ARM image Jun 11 20:17:13 yeah i know Jun 11 20:17:26 it didnt even fail on something gcc related Jun 11 20:17:35 it failed on imake stuff in xc/ Jun 11 20:20:45 pb did the changeset Jun 11 20:20:54 he might know more about the problem Jun 11 20:21:18 if its in there i'll just get new source Jun 11 20:22:23 ohwell Jun 11 20:22:27 i will play w/it later Jun 11 20:22:29 thanks for the help Jun 11 22:19:10 Can someone help me with a little problem I'm having while building a custom image? Jun 11 22:20:20 I guess asking for support at 1:20am EST is not going to get me very far.... anyone here in Italy waking up early that wants to help :-) Jun 11 22:26:55 ~emulate ash Jun 11 22:27:00 aw, ibot Jun 11 22:27:49 it's been a bit on and off lately I notice Jun 11 22:28:08 kergoth: Can you tell me, when an ipk gets split (kismet kismet-sounds kismet-docs), how do I add kismet-sounds to my image, bitbake says it cannot find a buildable provider.... Jun 11 22:28:08 perhaps Tim's net connection isn't as good as it once was Jun 11 22:28:55 Zero_Chaos: sounds like you tried to add it to the _DEPENDS variable instead of _RDEPENDS. DEPENDS is build time, RDEPENDS is run time. Jun 11 22:29:39 kergoth: wow, I learn something new every day, I knew asking you would yeild a viable response. Now, if I want to put my own kismet.conf into the image, do you know how I would do that? Jun 11 22:30:16 that depends. does our kismet package provide an /etc/kismet.conf at all? Jun 11 22:30:57 kergoth: as a matter of fact it does. It provdies the standard (needs to be edited) version. Jun 11 22:31:09 kergoth: it puts it in /etc Jun 11 22:31:30 is the kismet.conf it provides in the oe repo, or does it come from upstream? (poke around in its dir int he package repo) Jun 11 22:33:51 kergoth: oe seems to download the source for the kismet main site, and pull the .conf from the ${WORKDIR} Jun 11 22:34:18 kergoth: can I just override it there? change ${WORKDIR} to /whateverIwant Jun 11 22:34:19 ? Jun 11 22:35:20 is there a file://kismet.conf in SRC_URI? Jun 11 22:37:39 nope, but the full .tar.gz from kismetwireless.net is in there.... Jun 11 22:52:59 Can anyone tell me how to override a file in an ipk? For instance when building kismet I want my own "kismet" script and not the one that comes from the sources.... Jun 11 22:59:53 kergoth: well thanks as usual, I appreciate the guidance but I'm going to sleep. **** ENDING LOGGING AT Sat Jun 11 23:59:56 2005