irclog2html for #oe on 20050611

00:03.49*** join/#oe treke|home (~ggilbert@68-66-243-62.ventca.adelphia.net)
00:06.50*** join/#oe mithro (~tim@ppp226-233.lns3.adl2.internode.on.net)
00:30.26*** join/#oe BigAl (~bigal@220-253-116-144.ACT.netspace.net.au)
00:39.02jjg_anyone know how to resolve the "no rule to make clean" problem with xserver-xorg ?
00:53.21*** join/#oe darkschneider (~gab@213-140-6-96.fastres.net)
01:26.14*** join/#oe bluelightning (~bluelight@203-173-244-226.akl.ihugultra.co.nz)
01:42.45*** join/#oe Timelord (~TL@66.209.31.29)
02:02.59*** join/#oe ideal_ (~idealm_@218.82.60.191)
02:21.00*** join/#oe kergoth (~kergoth@c-24-118-222-11.hsd1.mn.comcast.net)
02:21.08*** join/#oe hufnus (~slonsiki@m7f1636d0.tmodns.net)
02:54.47*** join/#oe zecke|toothache (~ich@83-169-170-199-dynip.superkabel.de)
02:55.31Luke-Jrhmm
02:55.42Luke-Jrtmp/work uses lots of space if not emptied ;)
02:57.48*** join/#oe offroadgeek (~offroadge@offroadgeek.sustaining.supporter.pdpc)
03:05.41Luke-JrHas there been any consideration into splitting openembedded? eg OE base (stuff that applies to all targets), OE opie, OE gpe, etc?
03:13.34ljpbusybox doesnt like me
03:15.20bluelightningljp: how so?
03:16.51ljptry to login (first boot as root) 'login: cannot run /bin/sh: No such file or directory
03:21.05bluelightninghmm... :(
03:24.08*** join/#oe Timelord (~TL@66.84.189.72)
03:26.15*** join/#oe chouimat (~dieu@chouinard.developer.kde)
03:40.12ljpweird
03:53.04Luke-Jr| /bin/sh: /home/luke-jr/src/oe2005/build.alt/tmp/cross/arm-linux/bin/ccache: No such file or directory
03:53.10Luke-JrWhat would provide a cross-ccache?
03:53.23Luke-Jror is the problem that xorg-x11 wants to use it?
03:54.36Luke-Jrerr... xserver-xorg
04:32.29*** join/#oe bluelightning (~bluelight@203-173-245-62.akl.ihugultra.co.nz)
05:13.56*** join/#oe aphistic (~aph@c-24-12-111-46.hsd1.in.comcast.net)
05:27.04*** join/#oe bluelightning_ (~bluelight@203-173-245-212.akl.ihugultra.co.nz)
05:48.56*** join/#oe aph (~aph@c-24-12-111-46.hsd1.il.comcast.net)
05:56.14*** join/#oe noclouds (~mhfan@60.166.164.202)
06:22.03*** join/#oe aphistic (~aph@c-24-12-111-46.hsd1.il.comcast.net)
06:41.07ljphmm.. anyone have knights.tar.gz ?
06:49.22ljpawol
06:57.23ljp;(
07:00.48jacqueshi ljp I headrd you were using the PDAudio card on a Zaurus
07:02.29*** join/#oe exastra (~go@c-24-21-152-246.hsd1.or.comcast.net)
07:05.12*** join/#oe jason (~enlighten@cpe-70-112-216-41.austin.res.rr.com)
07:08.42*** join/#oe maisheri (~hiteshm@rasbtnlChn-static-252.184.145.203.touchtelindia.net)
07:15.22*** join/#oe treke|laptop (~ggilbert@68-66-243-62.ventca.adelphia.net)
07:27.58ljphmm.. wll I have one. havent used it yet,. but I suppose that the pxa27x is fast enough to handle it
07:28.28ljpnot sure if the driver sources still compile
07:30.48ljpand would need to resurrect my 'high end audio recorder for qtopia' :)
07:34.03*** join/#oe zap (~zap@217.170.93.9)
07:37.13*** join/#oe pH5 (~ph5@p5485ECB0.dip.t-dialin.net)
07:47.03*** join/#oe ar_ (~ar@port-ip-213-211-231-98.reverse.mdcc-fun.de)
07:53.33*** join/#oe koen (~koen@cl-148.ams-05.nl.sixxs.net)
07:54.08koengood morning all
07:59.56jasonsorry 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.
08:00.26jasonwhere can i find the correct build kernel in the openembedded directories?  thanks
08:02.45koenit should be in the same dir as the images
08:03.26koenassuming you are building for a zaurus
08:03.27jasonhow would it be called?  
08:03.36jasonyes i am.
08:03.51koenzImage* or kernel*
08:04.10jasonthanks.  i might have accidentally deleted it.
08:11.22*** join/#oe pb_ (~pb@2002:5168:d38c:1:a00:1fff:fe06:93c)
08:32.15CIA-403pb 07 * r1.3539 10openembedded/ (4 files in 3 dirs): adjust some glibc patches
08:36.36RPmorning all
08:36.49pb_hi rp
08:38.36koenhey RP & pb_
08:43.36*** join/#oe cedric__ (~cedric@voulx.bluebugs.org)
08:44.05bluelightninghi RP
08:44.08bluelightninghi pb_
08:45.56*** join/#oe moa (~cedric@freeway.rd.francetelecom.com)
08:46.55*** join/#oe aph (~aph@c-24-12-111-46.hsd1.il.comcast.net)
08:49.30*** join/#oe erikd (~aph@c-24-12-111-46.hsd1.in.comcast.net)
08:51.15*** join/#oe __law__ (~law@213.173.86.202)
08:55.24*** join/#oe zecke (~ich@83-169-170-199-dynip.superkabel.de)
09:08.41*** join/#oe Snoogie (~Snoogie@gob75-5-82-231-180-13.fbx.proxad.net)
09:10.15*** join/#oe Ken|JLime (~Ken@h79n2fls31o1105.telia.com)
09:13.09CIA-403pb 07 * r1.3540 10openembedded/packages/xserver/xserver-xorg_6.8.99.5.bb: avoid problems with imake and ccache
09:32.01*** join/#oe tomimo (~kurre@a84-231-39-238.elisa-laajakaista.fi)
09:32.50CoreDump|homemoin
09:32.56koenhey CoreDump|home
09:34.48koenand async?
09:35.48zeckepb_: ping
09:35.51koenCoreDump|home: http://funroll-loops.org/ features a bit on noatime too
09:35.53koenmoin zecke
09:35.53pb_zecke: at your service
09:35.55CoreDump|homethat, too. But I was talking about my desktop ATM :) The performence increase is very notable
09:36.59jacquesCoreDump|home, which fs ?
09:36.59zeckepb_: If I've a pipe between two processes and one process writes to it and then exits
09:37.35zeckepb_: will that information be lost when I do waitpid on the process?
09:38.01CoreDump|homeXFS, 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 :)
09:38.58*** join/#oe ar_ (~ar@port-ip-213-211-231-98.reverse.mdcc-fun.de)
09:39.16zeckepb_: and does a true socket (stream) have a different semantic?
09:41.16jacquesanyone 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
09:41.53pb_zecke: no, the data will sit in the pipe buffer until either you read it, or the reader exits.
09:42.13CoreDump|homejacques: not me, sorry. I've been burned by reiserFS in the past and avoid it like the plaque
09:42.47zeckepb_: ok that is what I expected, but I do not get the data :}
09:42.55zeckeread on the fd fails
09:43.20pb_oh, hm, odd
09:49.21zeckepb_: OT: did you ever looked at vuftpd?
09:49.36zeckepb_: it is the first app I know passing fd's through processes
09:50.10pb_no, I never looked at that
09:51.21zeckepb_: it is funky. You've 'one' in some way priviledge server. It opens a file on request and passes the fd to the socket
09:51.42zeckepb_: so even if there is a parser bug and something goes wrong in a slave
09:51.50zeckepb_: it can just do what it was supposed to do anyway
09:52.10*** join/#oe Luke-Jr (~luke-jr@207.192.219.246)
09:52.38pb_ah, I see.  cute.
09:53.33Luke-Jram I here? o.o
09:53.49koenLuke-Jr: no, you're imagining it
09:54.14Luke-Jrkoen: thanks. can you get to http://utopios.org ? o.o
09:54.26*** join/#oe chris144 (~chris@195.234.128.72)
09:54.33Luke-JrLightning here... IRC is the only thing that seems to be working >.>
09:54.45koenLuke-Jr: it seems to be loading
09:55.01Luke-Jrkoen: thanks :)
09:55.17Luke-Jrguess I can go back to sleep since the server stuff works
09:55.49*** join/#oe jamesm_ (jamesm_@82-133-68-68.dyn.gotadsl.co.uk)
09:59.47CIA-403pb 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
10:00.08koenah, nice
10:01.11*** join/#oe man-di (~man-di@dyndsl-080-228-199-148.ewe-ip-backbone.de)
10:04.33Luke-Jrpb_: qemu stuff split into arch pkgs? o.o
10:18.52*** join/#oe SirFred (~mteira@253.Red-81-35-59.pooles.rima-tde.net)
10:18.56SirFredMorning
10:20.51SirFredCompiling qte-2.3.10 using bitbake, I've noticed strange warnings during libqte linking stage
10:21.03SirFredA lot of warnings like these:
10:21.11SirFred/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
10:21.57SirFredIt's only a warning, but that symbol size mismatch seems not sane
10:23.26SirFredCould someone look at his log.do_compile.whatever to see if he's experimenting the same warnings?
10:27.31*** join/#oe darkschneider (~gab@213-140-6-96.fastres.net)
10:29.23CIA-403pb 07 * r1.3542 10openembedded/packages/glibc/ (3 files in 2 dirs): fix up glibc HEAD build
10:35.26mickeylmorning
10:35.42mickeylSirFred: yeah, let me start a build from scratch. That'll take a while
10:35.51SirFredmickeyl: Thanks.
10:35.51pb_hi mickey
10:36.14SirFredmickeyl: It is just a warning, and perhaps my toolchain is messed up.
10:37.53CoreDump|homemorning mickeyl
10:37.57mickeylmorning CoreDump|home
10:39.14mickeylljp: any idea when rc1 will be out for mere mortals ?
10:39.31*** join/#oe molivier (~mac@195.36.170.165)
10:39.37zeckemickeyl: it is
10:39.41zeckemickeyl: but not for QtE
10:39.51zeckemickeyl: qt*desktop*rc1*
10:39.52mickeylfair enough. i'm not interest in the E version
10:39.53mickeyl:D
10:40.02Spyrolast nights build failed here with latest bk oe and latest svn bitbake
10:40.26koenSpyro: that's too bad
10:40.35Spyro| /tmp/ccXr0q6K.s: Assembler messages:
10:40.36Spyro| /tmp/ccXr0q6K.s:140: Error: bad instruction `stfpls f5,[sp,#0]'
10:40.36Spyro| /tmp/ccXr0q6K.s:391: Error: bad instruction `ldfpls f1,[sp,#0]'
10:40.36Spyro| make[2]: *** [/home/ian/projects/openembedded/stuff/tmp/work/glibc-2.3.2+cvs20040726-r17/build-arm-linux/math/e_j0f.o] Error 1
10:43.01molivierhi
10:43.07koenhey molivier
10:43.20molivierkoen, hi
10:43.30SirFredmickeyl: What amazing news could we expect from Qt4 ?
10:43.55molivieri ve got such error when building package: libgcc_s.so uses hardware FP, whereas gpe-edit uses software FP
10:44.00molivierhow to solve this ?
10:44.39koendid you change TARGET_FPU between build?
10:44.58molivierok i have just see this, i must have target_fpu so tosft
10:45.12moliviers/tosdt/soft/
10:45.13SirFredmickeyl: I've seen that the driver adaptor from SciTech has been added to qte-2.3.10
10:45.14mickeylSirFred: a lot of good things. finally some more sophisticated design patterns
10:45.38mickeylSirFred: MVC things, iterators, new rendering architecture
10:45.50mickeylyes, scitech has been added in 2.3.8 or 2.3.9
10:46.03SirFredmickeyl: They have no driver for the W100, unfortunately.
10:46.15mickeylyeah.
10:46.31molivierkoen, so  i must suppress TARGET_FPU variable, correct ?
10:46.59mickeylSirFred: I personally lost pretty much all interest in Qt/Embedded though, I hope that kdrive gets w100 accelleration soon
10:47.41SirFredmickeyl: So, you think the future is a kdriver xserver and qt on X ?
10:47.49zeckemickeyl: the Qt4 licensing model seems to be finalized
10:47.53mickeylSirFred: That's what I - again personally - think
10:47.56zeckemickeyl: Qt console, Qt ???, Qt Desktop
10:47.57mickeylzecke: oh interesting.
10:48.07mickeylzecke: where can i read that?
10:48.23SirFredmickeyl: Anyway, what's the difference among the different qt versions?
10:48.44mickeylSirFred: you mean E and X11 or 2.x, 3.x, 4.x?
10:48.44SirFredmickeyl: The qt/embedded is based on the QWS model and is stripped out of a lot of features.
10:48.51zeckemickeyl: http://www.trolltech.com/newsroom/announcements/00000207.html
10:48.54SirFredmickeyl: E and X11.
10:48.55mickeylzecke: thanks
10:48.56zeckemickeyl: not too much
10:49.21mickeylSirFred: you just answered that question. that's the difference
10:49.28mickeylSirFred: it's not missing features though
10:49.33mickeylthat depends on how you build it
10:49.40SirFredmickeyl: Well, I miss some things like QT_TRANSFORMATIONS
10:49.55SirFredmickeyl: Well, of course, but if you want it to give a little footprint...
10:49.55mickeylyah sure, but if we would like to we could enable them
10:50.05mickeylwe are no longer compatible with anything else anyway
10:50.16mickeylthat's what why we have the compat libs
10:50.19mickeyls/what//
10:50.27koenmickeyl: mallum will do the w100 stuff after RP & sirfred finish decoding it
10:50.28SirFredmickeyl: I suppose the main reason to disable it is just that, the size.
10:50.39mickeylkoen: excellent
10:50.52mickeylSirFred: yeah size. but the choice was pretty random
10:50.53SirFredkoen: Well, I'm actually not decoding it.
10:51.21SirFredkoen: I expected RP to do the dirty work.
10:51.26koen:)
10:51.48SirFredkoen: I'm just trying to make the qte driver work. There are still a lot of missing things
10:53.24SirFredkoen: But I'm basing it on the closed sharp library extracted from their libqte.
10:53.41SirFredkoen: at the same time, RP is decoding that library.
10:54.02koenbbl
10:55.11SirFredmickeyl: So, you think that a driver for w100 under kdrive will be available soon ? Why?
10:56.11mickeylSirFred: i don't think, i hope.
10:56.22SirFredmickeyl: I think that the best thing will be a kernel framebuffer accelerated driver.
10:56.33SirFredmickeyl: So, both kdriver and qte could use that features.
10:56.38SirFreds/kdriver/kdriver/
10:56.41SirFreds/kdriver/kdrive
10:56.50mickeylSirFred: don't you think that the framebuffer accelleration API is still pretty limited ?
10:57.22SirFredmickeyl: I didn't take a look at it. But I expected to found a good, complete fb API under 2.6
10:57.45mickeylSirFred: it would mean both tweaking kernel and kdrive then
10:57.57mickeyl*shrug* we'll see who does what :)
10:58.28SirFredmickeyl: Anyway, there's a lot of work involved into decoding and understanding w100.
10:58.38mickeyli have no doubts about that
10:58.45SirFredmickeyl: There's a lot of microcode based functions. I think that that's the worse.
10:58.46mickeylreverse engineering at its best
11:00.07SirFredmickeyl: I think that an early accelerated qte driver will be good, perhaps more people got involved.
11:01.36SirFredmickeyl: Just now, I was able to run an opie session under the accelerated driver, with some minor bugs.
11:02.17SirFredmickeyl: 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?
11:02.31SirFredmickeyl: fix bugs/improve the driver.
11:04.11mickeylSirFred: 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.
11:04.24mickeylin other words - please do it :)
11:05.03SirFredmickeyl: I will need some help with bitbake.
11:05.16SirFredmickeyl: I'm porting my work to qte-2.3.10
11:05.30SirFredmickeyl: Well, to the last openzaurus.
11:05.39mickeylvery good. it's pretty easy to add patches to a program in bb
11:06.02SirFredmickeyl: OK. After testing the new libqte, I'll try to integrate it.
11:06.17SirFredmickeyl: But first, I will like to know if my toolchain is sane.
11:06.38SirFredmickeyl: I'll wait to your libqte build, to see if that warnings are caused by my setup.
11:06.50mickeylya
11:06.58zeckeappend_kernel24
11:07.06zeckeis KERNEL_VERSION in the OVERRIDES variable?
11:07.11mickeylno
11:07.21mickeylnot in oz builds though
11:07.31mickeyli think some familiar builds do that
11:07.47pb_not KERNEL_VERSION, though h3900 does have ${KERNEL} in OVERRIDES.
11:07.53pb_see h3900.conf
11:08.39zeckehmm then the bug report looks valid
11:08.50CIA-403pb 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
11:08.56pb_what's the bug report?
11:08.58jacquesyay!!!
11:09.15jacquesthat means we now have tcl and expect
11:09.20zeckepb_: #77
11:09.29pb_jacques: ah, not as such.  I didn't add them yet.
11:09.39jacquespb_, d`oh :-)
11:10.12pb_zecke: oh, yeah, I remember that one
11:10.46pb_the report seemed to be so confused that I didn't have the strength to untangle it.
11:11.24pb_afaict, his main complaint is that BOOTSTRAP_EXTRA_DEPENDS_append_kernel24 doesn't influence the Depends: field of task-bootstrap.ipk.
11:11.37pb_which, of course, is expected; he would need to set RDEPENDS to achieve that.
11:11.50zeckehehe okay
11:11.59zeckeobviously I did not read to carefully either
11:12.14pb_the bit with H3900_MODULES might be a real bug, but it's hard to tell for sure from that report.
11:13.23*** join/#oe reenoo_ (~r@p5489F167.dip.t-dialin.net)
11:13.40reenoo_afternoon
11:14.08pb_jacques: I was just playing with running the gcc testsuite under qemu.
11:15.08jacquespb_, sweet
11:15.20*** join/#oe [g2] (~g2@g2.nslu2-linux)
11:15.21CoreDump|homepb_: 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.
11:15.21jacquesI've messed with qemu a bit since they added armeb support
11:15.46pb_CoreDump|home: assign it to me and I will take a look
11:15.56CoreDump|homepb_: thanks :)
11:20.46CoreDump|home~lart bugzilla
11:20.58CoreDump|homeisn't there a way to list all registered members?
11:23.13jacquesis there supposed to be a glibc_2.3.5.bb ?
11:23.29*** join/#oe darmou (~darmou@dsl-220-235-95-160.vic.westnet.com.au)
11:23.39jacquesI see a glibc-cvs-2.3.5/ dir but no matching .bb
11:24.26pb_that's for glibc_cvs.bb
11:25.11jacquesah
11:25.17darmoudoes beep build ok at the moment?
11:26.17molivieroe 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 ?
11:26.57darmoumoliver isn't that in the local.conf?
11:30.00molivierdarmou, 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
11:31.09SirFredmolivier: That's saying that libgcc_s.so to be in /usr/lib/gcc
11:31.25SirFredmolivier: Not in /opt/oe/oetmp/cross/lib ..
11:32.01SirFredmolivier: Perhaps there's another crosscompiler in that machine?
11:32.55molivierSirFred, ok agree with you, so how to buypass the other one crosscompiler and force use the one in /opt/oe/oetmp ?
11:33.31SirFredmolivier: Do you have some ASSUME_PROVIDED in your local.conf for the compiler?
11:33.53molivierSirFred, i've got this ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95"
11:34.37SirFredmolivier: Well, on the shell you're using to launch bitbake, what says you
11:34.53SirFredwhich arm-linux-gcc
11:35.04SirFredmolivier: Perhaps it's just a path problem.
11:36.42molivieri not on the path
11:36.51*** part/#oe molivier (~mac@195.36.170.165)
11:37.00*** join/#oe molivier (~mac@195.36.170.165)
11:37.44molivierSirFred, i 've set the good one in my PATH but it's change nothing
11:37.58SirFredmolivier: So, what do you have in your PREFERRED_PROVIDERS for virtual/${TARGET_PREFIX}gcc ?
11:39.29SirFredmolivier: I have to say you that I'm a newbie, sure any other one could help you faster and better.
11:39.32molivierSirFred, 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
11:40.26SirFredmolivier: But you only will have a binary arm-linux-gcc, don't you?
11:40.43SirFredmolivier: Perhaps you've overwritten one compiler with the other.
11:41.11mickeylSirFred: i have the same warnings
11:41.19mickeylPretty odd
11:41.23mickeylthey're kind of new
11:41.25SirFredmickeyl: Strange warnings.
11:41.46SirFredmickeyl: Yes, they are. I'm not able to understand how the symbol has different size if they're compiled with the same compiler.
11:42.13molivierSirFred, yes and it's 3.4.4 version
11:42.23SirFredmickeyl: Anyway, the symbol is only defined once, or should be.
11:42.37SirFredmickeyl: So, I don't understand why the symbol is duplicated.
11:42.42Spyromickeyl: I have the latest bb and oe now...
11:42.51Spyromickeyl: glibc doesnt build though
11:43.33SirFredmickeyl: Does the compiler changed from the last openzaurus'
11:43.34SirFred?
11:44.35mickeylno idea offhand
11:44.40mickeyli stay away from toolchain issues
11:44.53SirFredmickeyl: I see i have two versions on the cross directory: 3.4.3 and 3.4.4
11:45.16mickeylah right. IIRC pb_ updated us to 3.4.4
11:45.22SirFredmickeyl: But the binary is for 3.4.4, I think that with 3.4.3 these warnings didn't happen.
11:45.35mickeylyeah. seems to be a 3.4.4 thing
11:45.41mickeylpb_: any idea what's going on there ?
11:45.50mickeylpb_: see http://www.vanille.de/temp/log.do_compile.1397
11:45.57SirFredmickeyl: Perhaps this is a nonsense, but could be related with header precompiling or something so?
11:47.05mickeylwe don't use that feature
11:48.25pb_mickeyl: sorry, I have no idea.  It looks like some crazy moc thing.
11:48.36pb_maybe zecke can help
11:49.09zeckeisn't moc part of stdc++?
11:49.37pb_~herring zecke
11:49.42ibotACTION whacks zecke on the side of the head with a large red herring named alfred
11:49.42zeckepb_: I wouldn't blame moc for that
11:49.58zeckepb_: it looks like somehow the symbol got truncated or such...
11:50.46zeckemickeyl: I will now leave to the 'long night of science"
11:51.11*** part/#oe chris144|home (~chris@195.234.128.72)
11:51.16zeckemickeyl: could you see what happens if you compile Qt/E with gcc3.4.3?
11:51.43SirFredIt's strange, some symbols are greater on allmoc.o and other are greater on the other file.
11:51.46darmouhmm beep music complies but does not run very well oh well
11:52.02darmouhas libpng been fixed yet?
11:52.28zeckedifferent defines are set?
11:52.57Spyropb_, zecke, this might be of interest...
11:52.59Spyrohttp://pastebin.ca/13948
11:53.42mickeylzecke: i can check that. it'll take a while though
11:54.51pb_yeah, that sounds like a good idea.
11:55.04pb_you might also try comparing allmoc.o between the two builds to see if there are any obvious differences.
11:55.08SirFredThis is a nonsense:
11:55.13SirFred/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
11:55.23SirFred/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
11:55.35SirFredA moving target.
11:55.52zecketeach the linker couting
11:55.55pb_mm, that does look a little bit bogus.
11:55.55zeckecounting even
11:56.00pb_maybe it is the new binutils that's broken.
11:56.03SirFredGoing to make a nm of
11:56.06SirFredallmoc.o
11:56.19SirFredTo see if that symbol appears more than once, or what.
11:56.21pb_what version of ld do you have?
11:57.37SirFred00000000 T QConnectionList::~QConnectionList()
11:57.37SirFred00000000 T QIMComposeEvent::~QIMComposeEvent()
11:57.53SirFredWell, arm-linux-nm says that.
11:58.12SirFredThere should be only one destructor by class, shouln't it ?
11:58.38SirFredBut the mangling is different.
11:58.48SirFred00000000 T _ZN15QIMComposeEventD0Ev
11:58.49SirFred00000000 T _ZN15QIMComposeEventD1Ev
11:59.09SirFred<PROTECTED>
11:59.09SirFredGNU ld version 2.15.91.0.2 20040727
12:00.13SirFredbbl
12:00.32pb_Can you unmangle those two names?  I don't have the eleet c++ ski11z to decode them in my head.
12:00.41zeckec++filt
12:00.52SirFredpb_: I've pasted the demangling before
12:00.57SirFred[13:57] SirFred 00000000 T QConnectionList::~QConnectionList()
12:01.12pb_oh, right, sorry
12:01.31pb_That does seem a bit peculiar.
12:02.24SirFredThat 00000000 shoulnd't be the symbol location in the object ?
12:02.30zeckeNot that I know the difference between D0Ev and D1Ev but I've it on any c++ built object
12:02.46zeckeSirFred: right it will be relocated at linking time/runtime
12:02.47SirFredCan't have a symbol on the text section and on the 00000000.
12:04.40SirFredI've just looked at a allmoc.o compiled with 3.4.3
12:05.01SirFredI thing these symbols should be Undefined.
12:05.05SirFredNot in the Text section.
12:05.54zeckeokay cya later
12:06.06SirFred<PROTECTED>
12:06.19SirFredSomething like this. There're also two destructors defined for any object.
12:07.44Spyrohm. its definately a toolchain prob - my older toolchain (homebuilt) doesnt cause the problem.
12:15.00pb_sirfred|lunch: can you run allmoc.ii through the two compilers and compare the .s output?
12:16.35SpyroI cant see anything wrong with the instructions...
12:18.36CIA-403mickeyl 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
12:19.58Spyromickeyl: why would bitbake choose one binutils-cross*.bb over another?
12:19.59*** join/#oe Timelord (~TL@66.209.31.29)
12:20.30Spyroit appears to be picking some arbitrary CVS version
12:20.39SpyroGNU ld version 2.15.96 20050323
12:21.53mickeylbitbake doesn't choose arbitrary
12:22.01mickeylit's either the latest or a preferred
12:22.16mickeylor a cvs versions specified through CVSDATE
12:22.23CoreDump|home~lart /etc/init.d/checkversion to check for the _date_ the kernel was build
12:22.25Spyromickeyl: why would it pick CVS over (say) binutils-cross_2.16.bb
12:22.41mickeylSpyro: because cvs is always later than a fixed one
12:23.12Spyromickeyl: is there a 'sub package' I can pick that builds a 'known good' toolchain ?
12:23.51mickeylSpyro: for a known good toolchain revert your bb and oe to the state of oz 3.5.3 or familiar 0.8.3
12:23.53mickeyl0.8.2 even
12:24.02mickeyleverything later is not known
12:24.30Spyroyou mean set DISTRO to familiar-0.8.3 ?
12:24.38mickeylthat's one part
12:24.38Spyro2 even
12:24.41mickeylbut also revert
12:24.49Spyrorevert ?
12:24.58mickeyli.e. download bb and OE from the day the DISTROs were released
12:25.18mickeylthen again - you might want to look into setting PREFERRED_VERSION and PREFERRED_PROVIDER instead
12:25.21Spyromickeyl: but I *upgraded* them because of problems... *sigh* ;-)
12:26.37mickeylsee familiar-0.8.3 conf
12:26.42mickeylremove the comments for the PREFERRED_VERSIONS
12:26.48mickeylthat may give you better results
12:27.00Spyrowill take a look
12:28.58Spyrook going for a fam-0.8.3 with preferred versions from the conf...
12:29.01Spyrohere we go...
12:35.31*** join/#oe man-di_ (~man-di@dyndsl-080-228-196-183.ewe-ip-backbone.de)
12:45.53mickeylRP: do you have a hint for me how to change the socket order in openzaurus-pxa27x ?
12:46.02mickeyli.e. in which file should i do what :))
12:49.53RPmickeyl: I'll need to look at it :)
12:52.23RPmickeyl: Downloading the source now
12:55.07mickeylRP: excellent. thanks!
12:56.03mickeylI'm afraid b0ti won't be finished with 2.6 at the time we want to release 3.5.4 :)
13:00.41RPmickeyl: I suspect there is a bit more work in 2.6 than that :)
13:03.13koenmickeyl: 3.5.4 still planned for "july" ?
13:03.27Spyroanyone here in the USA ?
13:04.40mickeylkoen: 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.
13:05.08mickeyla new release should introduce working keys on spitz/akita/tosa and a fixed suspend/resume on collie
13:05.19mickeylso i'm kind of tempted to hold it back until these issues are gone
13:05.22mickeylwhat do you think?
13:05.29koenand a working gpe on spitz+akita
13:05.43mickeylright
13:05.54koenwe have some blockers on fmiliar too :(
13:07.26*** join/#oe marcan (1337@80-26-156-179.adsl.nuria.telefonica-data.net)
13:07.36koengpe on akita should be straightforward, the initial rotation needs to be changed
13:07.59koenthe person on oesf who fixed *still* hasn't sent a mail to the OE list
13:08.02mickeylright. the backlight interface didn't change from 2.4 corgi, so it should also work
13:09.20koenbut first: fix the h3900.conf, which I seem to have broken
13:11.55RPI 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 :-/
13:12.51mickeylRP: 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
13:13.38RPmickeyl: agreed
13:14.26RPI'm still not sure if I introduced suspend/resume bugs when I fixed the alarm handling :-/
13:15.20mickeylyeah, i've been able to hang it more than once recently
13:15.28mickeylwhen resuming
13:15.51mickeyli'm also a bit worried about the battery reporting. it still seems not always correct to me
13:16.02mickeyldid you change anything based on hrw's results ?
13:18.04RPmickeyl: no, I didn't. I did tweak the battery handling code when doing the alarms though
13:18.24RPThere was a load of code I didn't like. I think I begin to see why it was there now though :-(
13:18.38CIA-403koen 07 * r1.3539.1.1 10openembedded/conf/machine/h3900.conf: h3900.conf: fix h3900 modules confusion
13:18.43RPIn what way does it worry you?
13:19.15mickeyli have that odd feeling that it drains faster and more stepwise than it should
13:19.27mickeylsorry, it's just a feeling, i can't back it up with facts atm.
13:20.13RPI have the same problem...
13:20.54RPI guess I need to look at the code I removed more carefully
13:21.24RPIt was really horrible stuff though...
13:21.42SpyroRP: battery stuff typically is
13:22.01mickeyl~lart Sharp for saving little by not adding a HW circuit for charging
13:22.31Spyroone of the few things toshi did right.
13:22.36mickeyland siemens
13:23.34Spyrowell glibc built...
13:24.24RPmickeyl: 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 :-(
13:24.37mickeylRP: i was afraid of that when I looked at it
13:24.40mickeylRP: don't bother
13:24.41SpyroRP: 'reverse' slots ?
13:25.01mickeylSpyro: Sharp came with that great idea to make the internal non-removable (!) HD as PCMCIA SLOT 1
13:25.15mickeyli want it to be slot 0
13:25.25Spyromickeyl: why?
13:25.59mickeyluhm, because it seems more logical to me
13:26.19Spyromickeyl: its just a number... let userspace do the coverup job if you dont like it :)
13:26.23mickeylalso because it makes some things more predictable
13:26.30mickeylSpyro: ... how ?
13:26.42Spyrowrite patches :)
13:26.50mickeylerr
13:27.11Spyroseriously - cant you just use the mountpoint ? why is the number even important?
13:27.37mickeylbecause things are unpredictable once the user has a chance to fill slot 0 with a CF
13:27.53koenhda -> hdb
13:28.40Spyromickeyl: use udev to make that a non-issue
13:28.46mickeylSpyro: no go
13:28.53mickeylSpitz is far from being 2.6
13:28.59BigAlThat's for sure.
13:29.00Spyrobah
13:29.01mickeyl2.4.20-embedix is trump
13:31.16BigAlRP: I've put some new patches up with the start of LCD support.. It's pretty hacky, but at least you see something.
13:31.30mickeyl~praise BigAl
13:31.34ibotAll hail BigAl!
13:31.34SpyroBigAl: what platform?
13:31.39BigAlSpitz under 2.6
13:31.45SpyroBigAl++
13:31.55Spyro~BigAl++
13:32.24Spyro~karma BigAl
13:32.24ibotbigal has karma of 1
13:32.33Spyro~karma Spyro
13:32.33ibotspyro has karma of 4
13:32.43mickeylheh
13:32.44CoreDump|home~karma CoreDump|home
13:32.44ibotcoredump|home has neutral karma
13:32.45BigAlRP: 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.
13:36.56*** join/#oe linuxwhore (~johnh@65-103-24-140.mpls.qwest.net)
13:37.01pb_jacques: did you ever get a chance to investigate that ifupdown crash in busybox?
13:37.10pb_the one with the environ patch
13:37.50Spyroanyone here having trouble with mtd on hh.org CVS 2.6 kernels ?
13:38.23*** join/#oe Luke-Jr (~luke-jr@207.192.221.172)
13:38.55jacquespb_, no, thanks for reminding me
13:39.02*** join/#oe dkey| (~dkey@193.170.48.234)
13:39.42RPBigAl: That's great! I'll have a look shortly
13:39.57RPmickeyl: See the email I've just sent you. Its mad enough to maybe work
13:41.41BigAlRP: There's still some uglyness with the lcdtg chip, though. I couldn't find an ssp clock divider that made it work.
13:45.13RPBigAl: I see what you mean about the bit banging code. That was never needed for the c7x0
13:45.46pb_jacques: ok, no problem.  I was just reminded of it because my mythfront build crashed at ifupdown.c again.
13:45.47RPIt *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...
13:46.46BigAlRP: 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.
13:47.41RPBigAl: 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
13:47.54RPThey're obviously fine whilst you get stuff working
13:48.49koenRP: any known timeframe for the 25x and 27x merge?
13:49.36RPkoen: As soon as someone perswades me to spend some time on it I expect :)
13:49.44RPBigAl: You look to be working against mainline rather than the patches in oe
13:50.03RPBigAl: The lcdtg code has been pulled out of w100fb
13:50.11RPI'm waiting to merge that with mainline
13:50.41RPBigAl: Have a look at http://www.rpsys.net/openzaurus/patches/w100_split-r10.patch
13:51.44BigAlRP: I just grabbed it from corgi_lcd.c, the stuff in the pxafb code in 2.4 from sharp was the same.
13:52.30RPBigAl: It was the ATI copyright that threw me. Its changed enough for me to bin that :)
13:55.39BigAlRP: The lcdtg could could probably made common too, if it's worth it.
13:56.17BigAlI wish we had a datasheet for that chip, though.
13:59.47RPBigAl: So do I. I did try and get one...
13:59.49RPIts internal Sharp only though so no chance ever...
14:00.40Spyroyay! bootstrap image built!
14:01.15koenSpyro: cheers
14:02.47Spyronow to add back the eseries bits...
14:03.40koenRP: does your 770 have the accellerated image viewer?
14:04.54RPkoen: Not sure. How would I tell the difference?
14:05.19BigAlRP: Oh well. At least we've got some code to look at.
14:05.26koenI guess that it doesn't link to libjpeg
14:05.43koenI've heard rumours the image viewer uses the DSP for that
14:05.48*** join/#oe [cc]smart (~smart@gw.ptr-62-65-149-158.customer.ch.netstream.com)
14:06.03Spyrokoen: I want to get my hands on THAT code...
14:06.15Spyroif the imageon can do iDCT it should be great for jpeg decode
14:07.00koenSpyro: closed source and you'll need a $5400 compiler
14:07.15Spyrokoen: yeah...
14:07.24Spyrokoen: or some decent reverse engineering
14:07.35koenlet's hope the ti-dsp gcc project advances
14:07.55Spyro:)
14:08.28pb_what would you reverse engineer?  surely the DSP specs are public.
14:08.29koenthe dsp compiler at the uni is too old for the 55x
14:08.42Spyroif I change my bitbake machine conf how do I force a rebuild?
14:08.42RPkoen: Mine is linked to libjpeg
14:08.57RPkoen: That doesn't mean it doesn't use the dsp though
14:10.26SpyroI dont want to rebuild my toolchain...
14:11.39Spyroanyone ?
14:12.02Luke-Jrrm -rf tmp
14:12.13SpyroLuke-Jr: that'll nuke my toolchain
14:12.16Luke-Jroh... not sure about toolchain
14:12.24Luke-Jrindividually nuke parts of tmp?
14:12.28CIA-403pb 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
14:12.33SpyroLuke-Jr: yeah but which ones ?
14:12.43SpyroLuke-Jr: its full of stuff...
14:12.52Luke-Jreverything not containing -cross and -native ?
14:13.13Spyrohm. possibly...
14:13.32Spyrobut Id prefer to just nuke the one or possibly two things that are causing it to think its already done...
14:13.34Luke-Jrnot sure the best way to filter such
14:13.39SpyroI tried -c clean task-bootstrap
14:13.46Luke-Jrthat'd be in tmp/stamps
14:14.05Luke-Jrbut you'll likely get errors without nuking tmp/work of them also
14:14.23Spyro*sigh*
14:14.34Luke-Jr(which is what -c clean would do)
14:14.38Spyrodependency systems that get out of sync get on my tits
14:15.20koenSpyro: use multimachine.inc and create a conf/machine/eseries.conf
14:15.34Spyrokoen: I have a conf/machine/eseries.conf
14:15.49Spyrobut I forgot to copy it across so my bootstrap was done without it
14:15.57Spyronow Ive copied it but it doesnt believe in it
14:16.52Spyroisnt it a bug that bb could continue despite the fact that the MACHINE variable described a nonexistent machine conf file?
14:17.59pb_probably.  patches are welcome.
14:18.23CIA-403pb 07 * r1.3547 10openembedded/packages/xt/xt_0.1.5.bb: disable PARALLEL_MAKE for Xt
14:18.52*** join/#oe dkey| (~dkey@193.170.48.234)
14:20.55Luke-JrGCC crashes compiling xserver-xorg o.O;
14:22.47*** join/#oe [cc]smart (~smart@gw.ptr-62-65-149-158.customer.ch.netstream.com)
14:27.34*** join/#oe Snoogie (~Snoogie@gob75-5-82-231-180-13.fbx.proxad.net)
14:36.06aboeglinErr, 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 ?
14:39.24*** join/#oe mteira (~mteira@253.Red-81-35-59.pooles.rima-tde.net)
14:40.13*** join/#oe TheDOC (~TheDOC@home.baer.RWTH-Aachen.DE)
14:40.21TheDOChi
14:42.00*** join/#oe dkey| (~dkey@193.170.48.234)
14:46.11CIA-403mickeyl * r250 10bitbake/lib/bb/make.py:
14:46.11CIA-4collect_bbfiles:
14:46.11CIA-4- save progress callback in function attribute
14:46.11CIA-4- remain completely silent when no progress callback is requested
14:47.47*** join/#oe Laibsch (~Laibsch@G1dfb.g.pppool.de)
14:51.32RPmickeyl: Did my email make sense?
14:54.10mickeylRP: thanks for that. sounds like a interesting approach, i'll try that asap
14:58.27RPI need to pop out for a bit - back in a couple of hours...
15:01.18mickeylcu
15:05.57*** join/#oe l-fy (~diana@diana.null.ro)
15:05.59l-fyhello
15:06.30LaibschHello l-fy
15:06.35LaibschNice to see you here.
15:06.40l-fyLaibsch > tell me more about this :)
15:06.54LaibschAs I said, I think openembedded is the way to go for you.
15:06.56TheDOC<PROTECTED>
15:06.56TheDOC<PROTECTED>
15:06.56TheDOCAttributeError: 'module' object has no attribute 'createCopy'
15:06.59TheDOCalso dabei tritt das auf
15:07.00TheDOChmpf
15:07.46Laibsch@everyone: l-fy is the developper for yate, a solution similar but apparently superior to asterisk.
15:07.46TheDOCis this somehow known? or am i wrong here? ;)
15:08.39Laibsch@everyone: yate seems to run on arm without a problem.  I got l-fy interested in using openembedded as a build-system.
15:09.13Laibschl-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.
15:09.42l-fymy hp it's an pxa 255
15:11.59Laibschl-fy: You will set the target you build for in local.conf IIRC.  Take a look at above URL 3.4
15:12.30LaibschYou can easily build for other targets by just changing a single line in the config file.
15:12.36l-fyok
15:12.45l-fylet me read more
15:12.53l-fythe problem it's that i don't have a zaurus
15:12.55LaibschSure.  Come back if you have question.
15:13.13Laibschl-fy: openembedded is not just for the Zaurus.
15:13.32LaibschIt is platform-agnostic.
15:13.41l-fyok
15:13.44l-fythank you
15:13.50Laibschnp
15:14.16Laibschkergoth: Still waiting for that dump of the old wiki
15:16.15l-fyok, which chipset zaurus has?
15:17.03Laibscharm
15:17.25l-fychipset not category?
15:17.28LaibschSL5500: StrongARM 206MHz
15:17.32l-fya ok
15:17.57LaibschWhy do you need to know?
15:18.27LaibschYou should leverage the power of OE and build for ALL supported platforms ;)
15:18.55Laibschl-fy: What distro do you use?
15:19.29l-fymandriva :)
15:19.40LaibschWow, never heard of that one.
15:20.08LaibschMandrake-based?
15:20.37l-fyit's mandrake new name :)
15:20.46Laibsch;-) OK
15:21.09*** join/#oe mteira (~mteira@253.Red-81-35-59.pooles.rima-tde.net)
15:22.16*** join/#oe dkey| (~dkey@193.170.48.234)
15:22.23l-fyi didn't get far with installing kernel on my pda
15:22.40mteiraopie-irc and some fonts on konqueror seem to lack characters. they are showed as squares. Do I need to install something?
15:27.27*** join/#oe Kompo (~kimmo@sk2-38.tky.hut.fi)
15:29.33LaibschIs there a VoIP solution in openembedded yet?  I heard of minisip once, is it in?
15:33.13koenLaibsch: do bitbake minisip and see what happens :)
15:33.33LaibschCool.
15:35.54koenmickeyl: is bitbake almost ready for another release?
15:50.20*** join/#oe do13 (~dirk@p213.54.8.98.tisdip.tiscali.de)
15:50.20*** join/#oe dkey| (~dkey@193.170.48.234) [NETSPLIT VICTIM]
15:50.20*** join/#oe l-fy (~diana@diana.null.ro) [NETSPLIT VICTIM]
15:50.20*** join/#oe Timelord (~TL@66.209.31.29)
15:50.21*** join/#oe sirfred|lunch (~mteira@253.Red-81-35-59.pooles.rima-tde.net) [NETSPLIT VICTIM]
15:50.21*** join/#oe jamesm_ (jamesm_@82-133-68-68.dyn.gotadsl.co.uk)
15:50.21*** join/#oe moa (~cedric@freeway.rd.francetelecom.com) [NETSPLIT VICTIM]
15:50.21*** join/#oe cedric (~cedric@voulx.bluebugs.org) [NETSPLIT VICTIM]
15:50.21*** join/#oe exastra (~go@c-24-21-152-246.hsd1.or.comcast.net)
15:50.21*** join/#oe treke|home (~ggilbert@68-66-243-62.ventca.adelphia.net)
15:50.21*** join/#oe dustpuppy (~chris@62.141.36.81)
15:50.21*** join/#oe mickeyl (~mickey@deneb.tm.informatik.uni-frankfurt.de)
15:50.21*** join/#oe CoreDump|home (~mhentges@hentges.net)
15:50.22*** join/#oe robtaylor (~robtaylor@217.204.121.82)
15:50.22*** join/#oe cvs_ (cvs@crash48.student.utwente.nl)
15:50.22*** join/#oe Cwiiis[away] (~cwiiis@user-214-207-151-83.e7even.com)
15:50.22*** join/#oe webmind (~webmind@217-195-236-172.dsl.esined.net) [NETSPLIT VICTIM]
15:50.22*** join/#oe Pendalar (Pendalar@h18.114.140.67.ip.alltel.net)
15:50.22*** join/#oe codders (~codders@82.70.217.41) [NETSPLIT VICTIM]
15:50.22*** join/#oe hrw|gone (szczepan@195.205.148.100)
15:50.22*** join/#oe zwi (~zwi@216.88.131.43)
15:51.28*** part/#oe Laibsch (~Laibsch@G1dfb.g.pppool.de)
15:53.58*** join/#oe do13 (~dirk@p213.54.8.98.tisdip.tiscali.de) [NETSPLIT VICTIM]
15:53.58*** join/#oe dkey| (~dkey@193.170.48.234) [NETSPLIT VICTIM]
15:53.58*** join/#oe l-fy (~diana@diana.null.ro) [NETSPLIT VICTIM]
15:53.58*** join/#oe Timelord (~TL@66.209.31.29)
15:53.58*** join/#oe sirfred|lunch (~mteira@253.Red-81-35-59.pooles.rima-tde.net) [NETSPLIT VICTIM]
15:53.58*** join/#oe jamesm_ (jamesm_@82-133-68-68.dyn.gotadsl.co.uk)
15:53.58*** join/#oe moa (~cedric@freeway.rd.francetelecom.com) [NETSPLIT VICTIM]
15:53.58*** join/#oe cedric (~cedric@voulx.bluebugs.org) [NETSPLIT VICTIM]
15:53.58*** join/#oe exastra (~go@c-24-21-152-246.hsd1.or.comcast.net)
15:53.58*** join/#oe treke|home (~ggilbert@68-66-243-62.ventca.adelphia.net)
15:53.58*** join/#oe dustpuppy (~chris@62.141.36.81)
15:53.58*** join/#oe mickeyl (~mickey@deneb.tm.informatik.uni-frankfurt.de)
15:53.58*** join/#oe CoreDump|home (~mhentges@hentges.net)
15:53.58*** join/#oe robtaylor (~robtaylor@217.204.121.82)
15:53.59*** join/#oe cvs_ (cvs@crash48.student.utwente.nl)
15:53.59*** join/#oe Cwiiis[away] (~cwiiis@user-214-207-151-83.e7even.com)
15:54.00*** join/#oe webmind (~webmind@217-195-236-172.dsl.esined.net) [NETSPLIT VICTIM]
15:54.00*** join/#oe Pendalar (Pendalar@h18.114.140.67.ip.alltel.net)
15:54.00*** join/#oe codders (~codders@82.70.217.41) [NETSPLIT VICTIM]
15:54.00*** join/#oe hrw|gone (szczepan@195.205.148.100)
15:54.00*** join/#oe zwi (~zwi@216.88.131.43)
15:54.18*** join/#oe UdontKno1 (udontknow@udontknow.staff.freenode)
15:54.34*** join/#oe cdbot (~cdbot@hentges.net)
15:56.31*** join/#oe hufnus (~slonsiki@m878936d0.tmodns.net)
16:01.10*** join/#oe pb_ (~pb@2002:5168:d38c:1:a00:1fff:fe06:93c)
16:01.10*** join/#oe nhorlock (~neil@spc2-ashf1-3-0-cust73.asfd.broadband.ntl.com) [NETSPLIT VICTIM]
16:01.10*** join/#oe ascent (ascent@ascent.student.utwente.nl) [NETSPLIT VICTIM]
16:01.10*** join/#oe emte (emte@d64-180-41-158.bchsia.telus.net) [NETSPLIT VICTIM]
16:11.10*** join/#oe pH5 (~ph5@p5485F121.dip.t-dialin.net)
16:11.50CIA-403koen 07 * r1.3545.1.1 10openembedded/packages/ecore/ecore_0.9.9.007.inc: ecore_0.9.9.007.inc: evas -> virtual/evas
16:17.50*** join/#oe aoe (aoe@mac1-bluebox-winf.oeh.univie.ac.at) [NETSPLIT VICTIM]
16:18.28*** join/#oe diana (~diana@diana.null.ro)
16:18.34*** part/#oe diana (~diana@diana.null.ro)
16:35.33*** join/#oe Laibsch (~Laibsch@G1dfb.g.pppool.de)
16:47.11*** join/#oe Snoogie (~Snoogie@gob75-5-82-231-180-13.fbx.proxad.net)
16:54.46CIA-403pb 07 * r1.3547.1.1 10openembedded/packages/xserver/xserver-xorg_6.8.99.5.bb: more xorg build fixes
16:57.38Spyroif I add a package to machine/eseries.conf, what do I need to do to get it noticed and built by bitbake ?
17:06.41*** join/#oe anomaly_ (~anomaly@dsl-202-173-142-209.sa.westnet.com.au)
17:07.44koen|afkSpyro: touch conf/local.conf
17:08.35pb_that shouldn't be necessary when editing MACHINE.conf.
17:08.39pb_if it's required, that's a bug.
17:11.58Spyroif I have a .bb for compiling a single C file (foo.c) I should simply do something like:
17:12.03Spyrodo_compile() {
17:12.03Spyro<PROTECTED>
17:12.03Spyro}
17:12.06Spyroright ?
17:12.20pb_yes
17:12.30Spyrowell devmem2 doesnt build
17:12.35pb_that's very sad
17:12.43Spyrocomplains that it cant find arm-linux-gcc
17:13.05Spyro(kinda hard to believe following a successful bootstrap image...)
17:14.38Spyrocan I get bb to show me exactly the commands it is running, on the fly ?
17:21.59Spyrohrm. the problem *appears* to be that PATH doesnt contain tmp/cross/bin
17:22.06Spyroshould it do ?
17:22.57pb_yes
17:23.23Spyroshould the shells PATH contain it or is bb meant to put it there?
17:25.16Spyrohm. no, its in the PATH...
17:25.43Spyroahhhhh
17:25.47Spyroits in the wrong dir
17:26.02Spyroits building in /home/ian/projects/openembedded/stuff/tmp/work/devmem2-1.0-r0/devmem2-1.0
17:26.10Spyrobut the source is in the parent of that
17:32.39*** join/#oe [g2] (~g2@g2.nslu2-linux)
17:45.51*** join/#oe _alwin_ (alwin@cable-195-14-254-128.netcologne.de)
17:54.36*** join/#oe hue (~hue@219.136.132.144)
18:00.49Spyropb_: 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.
18:01.03Spyropb_: Im not sure how to fix it though, I dont know python-foo
18:01.27koenS = ${WORKDIR}
18:01.39*** join/#oe mteira (~mteira@253.Red-81-35-59.pooles.rima-tde.net)
18:03.31Spyrokoen: pardon?
18:03.53koenput that in the .bb
18:04.07Spyrowhats S ?
18:05.09koenSpyro: http://ewi546.ewi.utwente.nl/tmp/d/keyS.html
18:06.40Spyrokoen: well it fixed it.
18:06.59SpyroI'd commit the fix but I have neither priveliges or the desire to use bk...
18:07.18CIA-403koen 07 * r1.3549.1.1 10openembedded/conf/documentation.conf: documentation.conf: add S
18:07.21Spyrowould it be possible to setup a SVN/BK gateway ?
18:07.23koenbut a patch in bugzilla
18:07.33Spyrook, will do.
18:07.50koenBitmover will shoot down such gateways
18:07.55SirfredHi again.
18:08.14SirfredAny new about that strange symbol mismatch with the toolchain?
18:12.33Spyrokoen: thats shitty :(
18:14.07koenyeah
18:14.20koenthat's what we get for selling our souls to larry
18:15.37RPSirfred: We probably need one of the patches linked off http://www.arm.linux.org.uk/developer/toolchain/
18:16.25SirfredRP: So, the problem is located in binutils?
18:17.38Sirfred<PROTECTED>
18:17.59SirfredRP: I found those symbols on the allmoc.o object.
18:18.11SirfredGoing to see if they were there with the old toolchain
18:19.00SirfredIt seems that they were there yet.
18:19.00RPSirfred: You need one of the patches to binutils as linked above
18:21.32RPpb_: ping
18:22.10RPpb_: Is there any reason we shouldn't apply http://www.arm.linux.org.uk/developer/toolchain/elf32-arm.h.patch to binutils?
18:36.53RPpb_: Just ignore me...
18:37.44SirfredRP: Have you found something?
18:37.52*** part/#oe Laibsch (~Laibsch@G1dfb.g.pppool.de)
18:38.01RPSirfred: No :-(
18:38.19SirfredRP: Your comment sounded as if after further investigation, your question becomed obsoleted.
18:38.23RPI thought I had, but I haven't...
18:38.45SirfredRP: It seems that those patches are necesary, I'm just rebuilding all my toolchain.
18:40.23RPSirfred: I think we already apply them
18:40.30RPOr they've been merged into bintuils...
18:40.49SirfredRP: I didn't found something similar in the files subdirectory for binutils.
18:42.23RPSirfred the code in the patch I linked to is already in elf32-arm.c
18:42.32SirfredRP: :-(
18:43.00SirfredRP: Sure this is a dumb question, but...
18:43.17SirfredRP: Are binutils really involved while creating a .o from a .cpp ?
18:43.49SirfredRP: Is the compiler using binutils for something at this stage?
18:44.24RPSirfred: I'm not entirely sure to be honest
18:45.06SirfredRP: Perhaps is something easy to see.
18:45.24SirfredRP: I'm going to invoke it, and strace to see what is it exec'ing.
18:48.32SirfredRP: It seems that binutils are not involved:
18:48.34Sirfredmteira@maleficio ~ $ strace -f g++ -c test.cc 2>&1 | grep ^exec
18:48.35Sirfredexecve("/usr/bin/g++", ["g++", "-c", "test.cc"], [/* 27 vars */]) = 0
18:49.40SirfredRP: I think that the problem is related with gcc and not binutils.
18:50.06RPSirfred: Ok, I suspect it was a concious effort on gcc's part to add the symbols for some reason though
18:50.55SirfredRP: About those $a and $d symbols, perhaps they get stripped out when linking the final library/executable.
18:51.34RPSirfred: I'd thought the linker was supposed to deal with them (hence the above bintuils patch)
18:51.58SirfredRP: The real problem is that symbols that I think should be emitted as Undefined, are emitted as Text
18:52.22SirfredI think that it's what is causing the warning.
18:53.24*** join/#oe Pigi (~NoOne@host163-45.pool80180.interbusiness.it)
18:53.34PigiCiao all
18:54.54PigiI have a problem compiling libaudiofile with oe using DISTRO=familiar-0.8.3.
18:54.54RPhi Pigi
18:54.57Pigi/tmp/ccytAfmb.s: Assembler messages:
18:54.57Pigi/tmp/ccytAfmb.s:2906: Error: bad instruction `stfpls f2,[sp,#-4]!'
18:55.00Pigihi RP
18:55.53RPPigi: Does familar-0.8.4 work any better?
18:56.20Pigihas it been released a new conf file for familiar 0.8.4 ?
18:56.53RPIts not released but the 0.8.4 file is updated regularly to keep things working
18:57.02RPIts the file which will become 0.8.4 if you see what I mean
18:57.22pb_Pigi: it looks like there is a bug in the latest version of gas.
18:57.23RPreally it should be called familiar-current :)
18:57.48pb_Try going back to the older binutils snapshot (the one from 200504mumble).  I think that will clear it up.
18:58.04Pigiso I'm supposed to bk pull before trying to use familiar-0.8.4 ?
18:58.36Pigipb_ do you mean I should revert to binutils-200504 and recompile everithing ?
18:58.53RPPigi: You probably have a familiar-0.9.0 in your tree - koen renamed it recently back to 0.8.4
18:58.55pb_you don't need to recompile everything, just retry the audiofile build.
18:59.33Pigiok, I'll try. I was scared as I started a new compile yesterday nite, and finished today :)
18:59.41pb_heh
19:00.12Pigiso, the procedure could be: bk pull, then change DISTRO and then restart the libaudiofile ?
19:00.44pb_I'm not sure that bk pull is necessary, and I don't know that changing DISTRO will help.
19:01.20Pigiso ( apologize ) how I'm supposed to use the old binutil ?
19:01.53pb_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.
19:02.07Pigiok. Thx
19:02.11PigiI'll try
19:02.29pb_I'll temporarily disable the new binutils anyway, until this problem is resolved.
19:02.38Pigicool
19:04.29Pigipb_ apologize again. Could it be binutils-cross_csl-arm-20050416.bb what I do need ?
19:05.49pb_right, yeah, that's the one you need
19:05.57Pigiok, thx
19:10.00*** join/#oe do13 (~dirk@p213.54.8.98.tisdip.tiscali.de)
19:10.43CIA-403pb 07 * r1.3550.1.1 10openembedded/packages/binutils/binutils_csl-arm-20050603.bb: remove preference for binutils_csl-arm-20050603 due to "stfpls" problem
19:12.44CIA-403pb 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
19:24.52Spyroif I want xserver-kdrive_20050207 what do I put in PREFERRED_VERSION ?
19:31.38Luke-Jryou mean the 20050207 CVS version?
19:33.23CIA-403pb 07 * r1.3554 10openembedded/packages/pciutils/pciutils_2.1.11.bb: suppress PARALLEL_MAKE for pciutils
19:34.14Luke-JrSpyro: ah... it's a frozen snapshot... try 0.0cvs20050207
19:36.49SpyroLuke-Jr: ta
19:37.30Luke-Jrta? O.o
19:37.39SpyroLuke-Jr: == thankyou
19:38.03Luke-Jrah. yw
19:43.58koenkdrive has a new snapshot
19:44.02koen20050610
19:44.27Pigihi koen
19:44.35koenhey pi
19:44.45koenPigi even
19:44.48Pigieheh
19:45.03Spyrokoen: how reliable is it ?
19:45.16koenit works on my zaurus
19:45.50koenmallum fixed the tslib code the day before
19:46.05koenit should get built by default
19:46.42Spyrokoen: 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...
19:47.37koenbitbake -c clean -b path/to/file.bb ; bitbake -b path/to/gile.bb
19:47.53koenor bitbake -i and 'rebuild xserver-kdrive'
19:53.02Spyrowhy is it that rebuilding the whatever it is that takes bb so long parsing the bb files sometimes goes quick and sometimes REALLY slow ?
19:56.37keturnit 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.
19:57.12Spyroketurn: ah.
19:57.29Spyroketurn: its confusing since it says its 'using cache from...' regardless
20:08.28keturnodd.  permission denied error in do_unpack in base-files.
20:11.26*** join/#oe Timelord (~TL@66.209.15.235)
20:15.00Spyrokoen: the 20050610 snapshot seems prone to segfaults
20:15.11Spyrokoen: it starts OK
20:15.42Spyrobut if I run a remote application on my desktop with the display onthe PDA, and then quit it, the server crashes.
20:15.49Spyroits 100% repeatable
20:26.07pb_keturn: that does sound odd.  are you trying to unpack over an existing tree?
20:28.09keturnlooks like it was trying to move one of the files/ over something unpacked from the tarball
20:35.00*** join/#oe ibot (ibot@apt.bot.TimRiker.active.supporter.pdpc)
20:35.00*** topic/#oe is OpenEmbedded Developer Lounge | http://bugs.openembedded.org/ (l/p guest/guest) | This is not a distribution support channel | The OE mailing list is back, but everyone needs to resubscribe. | We have a bitbake-dev mailing list for discussions on the core. If you're interested in BitBake-Ng, please subscribe. | LCA 2005 Embedded Miniconf - http://www.openembedded.org/miniconf
20:35.14pb_keturn: righto, good luck
20:35.21pb_Pigi: yah, I think that's a different problem.
20:36.02Pigiok
20:37.52Pigiyeahhhhh after 24 hours of compile_and_fix_and_compile I got "NOTE: package gpe-image-1.0-r17: task do_rootfs: started"
20:37.53pb_bbiab, going to watch some tv
20:49.56keturnAh.  I think in my meddling with bitbake, I broke stamping.  
21:03.56*** join/#oe mteira (~mteira@253.Red-81-35-59.pooles.rima-tde.net)
21:08.33*** join/#oe _alwin_ (alwin@cable-195-14-198-60.netcologne.de)
21:16.17Spyrohm. I *think* I have a suspend/resumable server...
21:16.36Spyrolooks like kdrive segfaults once it has no remaining clients
21:16.46*** join/#oe Crofton (~balister@jhr-476-5192.mprg.ee.vt.edu)
21:16.54Spyroso since its only clients here were via USBnet, which dies on suspend
21:17.20Spyroit appeared that kdrive was dying on suspend, where in reality its dying any time it has no clients
21:19.27reenoo_Spyro: I guess you want rxvt-unicode
21:19.38reenoo_Spyro: there is not gpe-terminal
21:19.43reenoo_s/not/no/
21:20.06Spyroreenoo_: there isnt ?
21:23.59reenoo_heh. never seen that before. but anyways.. all it contains is a .desktop and a .png
21:27.36Spyroheh. yeah, how odd :)
21:33.24Crofton~bugzilla
21:33.25ibotsomebody said bugzilla was http://www.handhelds.org/bugzilla/
21:40.28reenoo_Crofton: OE bugzilla? see /topic
21:41.42Croftonheh
21:41.55Croftonno was playing with bugzilla feature on a bot
21:42.05Croftonbut the bot is in another channel :)
21:49.24*** join/#oe dkey| (~dkey@193.170.48.234)
22:16.04ljpanyone know about this? http://jw.dyndns.org/initng/
22:20.22RPljp: mickeyl was asking if anyone had tried it :)
22:23.04ljpi am going to try it on my laptop
22:23.18Spyrois it possible to build a gpe-image with NO kernel ?
22:24.23RPSpyro: Yes, the Zaurii do that
22:24.47SpyroRP: I was looking in the c7x0 conf... hows it done ?
22:26.23RPSpyro: See packages/linux/linux-openzaurus_2.6.12*.bb
22:26.35RPSpyro: the line FILES_kernel-image is the key (I think)
22:27.00RPYou still compile the kernel as that gives headers etc. You just don't install it to the image
22:37.54ljpfirst initng boot didn't work.. might need to tweak it
22:43.08pb_morning ljp
22:43.14ljphi
22:51.24*** join/#oe Pigi (~NoOne@host163-45.pool80180.interbusiness.it)
22:54.10*** join/#oe Pigi (~NoOne@host163-45.pool80180.interbusiness.it)
22:54.18Pigipb_ you around yet ?
22:57.52Pigi~seen pb_
22:57.53ibotpb_ <~pb@2002:5168:d38c:1:a00:1fff:fe06:93c> was last seen on IRC in channel #gpe, 4d 9m 38s ago, saying: 'later all'.
23:01.23*** join/#oe Snoogie_ (~Snoogie@gob75-5-82-231-180-13.fbx.proxad.net)
23:01.37*** join/#oe offroadgeek (~offroadge@offroadgeek.sustaining.supporter.pdpc)
23:13.48*** join/#oe aris (~aris@83-134-1-34.Paille.GoPlus.FastDSL.tiscali.be)
23:14.00arishi people
23:14.50arisI have a problem. I just folowed the recipe from GettingStarted and started to build opie for instance
23:14.52arisaris@darkside /mnt/usb/aris/opn/build $ bitbake opie-image
23:14.53aris...
23:15.29arisit downloads quilt-native-0.39 then fails in the do_configure
23:15.43aris| /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
23:15.43aris| FATAL: oe_runconf failed
23:15.43arisNOTE: Task failed: /mnt/usb/aris/opn/build/tmp/work/quilt-native-0.39-r0/temp/log.do_configure.3842
23:22.17*** part/#oe How_long_can_be_ (~Snoogie@gob75-5-82-231-180-13.fbx.proxad.net)
23:49.08*** join/#oe Timelord (~TL@66.84.189.72)
23:55.20*** join/#oe Crofton|laptop (~balister@66-207-66-26.black.dmt.ntelos.net)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.